프록시와 안정적인 트래픽

최종 수정: 2025.06.15

프록시와 안정적인 트래픽

개발자는 클라이언트보다 서버를 만들고 다루는 일이 더 많다. 서버를 다루는 개발자는 한 번에 수많은 클라이언트와 메시지를 주고받아야 한다.

---

■ 오리진 서버와 중간서버: 포워드 프록시와 리버스 프록시

클라이언트와 단일한 서버가 한 네트워크 내에 존재하거나 나란히 위치하는 경우는 거의 없다. 클라이언트와 서버 사이에는 수많은 네트워크 장비들이 있을 수 있고, 서버를 보완하는 수많은 중간 서버들도 있을 수 있다. 게다가 어느 한 서버에 문제가 생기더라도 문제없이 동작할 수 있도록 서버를 다중화하여 운영하는 경우가 많다. 수많은 네트워크 장비과 중간 서버들 사이에서 클라이언트가 최종적으로 메시지를 주고받는 대상을 오리진 서버(origin server)라고 한다.

 

대표적인 HTTP 중간 서버의 유형에는 프록시와 게이트웨이가 있다. 프록시는 포워드 프록시, 게이트웨이는 리버스 프록시라고도 부른다. 프록시(proxy)란 클라이언트가 선택한 메시지 전달의 대리자로, 주로 캐시 저장, 클라이언트 암호화 및 접근 제한 등의 기능을 제공한다. '클라이언트의 심부름꾼 또는 대리인이다'로 생각하면 된다.

 

반면, 게이트웨이(gateway)는 오리진 서버(들)을 향하는 요청 메시지를 먼저 받아서 오리진 서버(들)에 전달하는 문지기, 경비 역할을 수행한다. 클라이언트 시각에서 보면 마치 오리진 서버처럼 보인다. 게이트웨이에는 캐시를 저장할 수도 있고, 부하를 분산하는 로드 밸런서로도 동작할 수 있다.

---

■ 고가용성: 로드 밸런싱과 스케일링

가용성과 부하 분산은 서버를 설계할 때 안정성과 관련한 중요 고래 대상이다.

 

가용성

주어진 특정 기능을 실제로 수행할 수 있는 시간의 비율을 가용성이라고 한다. 고가용성은 다음의 수식 값이 높은 성질을 말한다.

가용성 = 업타입 / 업타임 + 다운타임

 

• 업타임(uptime): 정상적인 사용 시간
• 다운타임(downtime): 모종의 이유로 인해 정상적인 사용이 불가능한 시간

 

다운타임이 발생하는 이유는 무엇일까? 다운 타임은 과도한 트래픽으로 인한 서비스 다운, 예기치 못한 소프트웨어 상의 오류 또는 하드웨어 장애가 원인일 수도 있고, 때로는 보안 공격이나 자연재해로 인해 발생할 수도 있다. 따라서 다운타임의 발생 원인을 모두 찾아 원천 차단하기는 현실적으로 어렵다. 결국, 고가용성을 유지하는 것의 핵심은 '문제가 발생하더라도 계속 기능할 수 있도록 설계하는 것'에 가깝다. 이처럼 문제가 발생하더라도 기능할 수 있도록 하는 능력을 결합 감내(fault tolerance)라고 한다. 이를 위한 대표적인 기술이 바로 다중화이다. 서버를 다중화하면 특정 서버에 문제가 발생하더라도 다른 예비 서버가 이를 대신해 동작할 수 있기 때문이다.

동작하는 시스템에 문제가 생겼을 때 예비된 시스템으로 자동 전환하는 기능을 페일오버(failover)라고 한다.

헬스 체크와 하트비트
다중화된 서버 환경에서는 현재 문제가 있는 서버가 있는지, 현재 요청에 대해 올바른 응답을 할 수 있는 상태인지를 주기적으로 검사하는 경우가 많다. 이러한 검사를 헬스 체크(health check)라고 한다. 주로 로드 밸런서에 의해 이루어지는 경우가 많으며, HTTP나 ICMP 등 다양한 프로토콜을 활용할 수 있다.

하트비트(heartbeat)는 서버 간에 주기적으로 하트비트 메시지를 주고 받다가 주고받는 메시지가 끊겼을 때 문제의 발생을 감지하는 방법이다.

 

로드 밸런싱 (load balanceing)

서버를 다중화했다고 해서 반드시 고가용성이 보장되는 것이 아니다. 서버의 가용성에 가장 큰 영향을 끼치는 대표적인 요소는 감당하기 어려울 정도의 트래픽이다. 서버를 다중화하더라도 특정 서버에만 트래픽이 몰린다면, 가용성은 떨어질 수 있다.

 

따라서 트래픽의 고른 분배를 위해 사용되는 기술이 바로 로드 밸런싱이다. 이는 로드 밸런서(load balancer)에 의해 수행되는데, 로드 밸런서는 다중화된 서버와 클라이언트 사이에 위치하며 클라이언트의 요청(들)을 각 서버에 균등하게 분배하는 역할을 한다. 로드 밸런싱 기능을 제공하는 소프트웨어를 설치하면 일반 호스트도 로드 밸런서로 사용할 수 있다. 대표적인 로드 밸런싱 소프트웨어로는 HAProxy, Envoy 등이 있으며, 대표적인 웹 서버 소프트웨어인 Nginx에도 로드 밸런싱 기능이 내장되어 있다.

 

이처럼, 부하가 균등하게 분산되도록 요청을 전달할 서버를 선택하는 방법을 로드 밸런싱 알고리즘이라 한다. 다양한 종류가 있지만 라운드 로빈 알고리즘과 최소 연결 알고리즘이 대표적이다.

• 라운드 로빈 알고리즘(round robin algorithm): 단순히 서버를 돌아가며 부하는 전달
• 최소 연결 알고리즘(least connection algorithm): 연결이 적은 서버부터 우선적으로 부하는 전달

 

로드 밸런싱에 있어 중요하게 고려해야 할 점은 단순히 '다중화된 모든 서버에 균일한 부하를 부여하는' 전략은 모든 서버의 성능이 동일하다는 전제가 있을 때만 유효하다는 것이다. 로드 밸런싱 알고리즘에는 이를 반영해 가중치가 부여될 수 있다. 거의 대부분 로드 밸런서는 이러한 가중치 알고리즘을 지원한다.

 

스케일링: 스케일 업 스케일 아웃 오토스케일링

웹 서버나 네트워크 장비만 하더라도 성능이 좋은 경우 가용성이 더 높다. 다만, 꼭 비싼 장비를 구비하는 것만이 정답은 아니다. 이와 관련해 스케일 업, 스케일 아웃이라는 용어가 있다.

• 스케일 업(scale-up): 기존 부품을 더 나은 사양으로 교체하는 방법이고, 수직적 확장(vertical scaling)이라 부른다.
• 스케일 아웃(scale-out): 기존 부품을 여러 개로 두는 방법이고, 수평적 확장(horizontal scaling)이라 부른다.

 

각 방식만의 장단점은 명확하다. 스케일 업의 가장 큰 장점은 설치와 구성의 단순함이다. 대신 스케일 아웃에 비해 유연하지는 않다. 하나의 스케일 업 장비의 성능에 한계가 있을 경우, 스케일 아웃을 하지 않는 이상 계속해서 더 비싸고 성능 좋은 장비를 구비해야 하기 때문이다.

 

반면, 스케일 아웃은 유연한 확장 및 축소 가능하다는 게 장점이다. 설치와 구성이 단순하지는 않을 수 있지만, 설치 및 구성 방법만 알면 장비의 확장과 축소가 매우 쉬워질 것이다. 필요하다면 증설하고, 필요하지 않다면 빼면 그만이기 때문이다. 무엇보다 스케일 아웃으로 확장할 경우, 결함을 감내하기가 더 용이하다. 부하가 분산되도록 설계하기가 용이하기 때문에 뱡목이 생길 우려가 적어지므로 더욱 안정적인 운용이 가능하다.

오토스케일링 (autoscaling)
티켓팅이나 수강신청과 같이 특정 시점에 트래픽이 급증하는 상황이 있다. 또한, 특정 기간 동안 트래픽이 급증하는 상황도 있다. 그렇다고 모든 자원을 트래픽 급증 시점을 기준으로 스케일 업/스케일 아웃하는 것은 경제적이지 않다. 이럴 때 사용 가능한 기능이 바로 오토스케일링이다. 필요할 때마다 시스템을 동적으로 확장하고 축소할 수 잇는 기능을 의미하는데, 자원을 더욱 경제적이고, 탄력적으로 이용할 수 있다.

---

■ 웹 서버와 웹 애플리케이션 서버

'웹 서버'라는 용어는 서버의 역할을 수행하는 하드웨어만 의미하는 것이 아니라 서버 역할의 소프트웨어를 의미하기도 한다. 소프트웨어라는 맥락에서 대표적으로 사용되는 웹 서버에는 Nginx, 아파치 HTTP 서버, 마이크로소프트 IIS 등이 있다.

 

웹 서버는 기본적으로 정적인 정보를 응답한다. 정적인 정보란 송수신 과정에서 수정과 처리가 필요하지 않은 정보를 말한다. 언제, 어디서, 누가 봐도 변하지 않을 정보를 의미한다.

 

하지만 웹 서비스가 정적인 정보만을 응답하지는 않는다. 데이터베이스에 저장된 값을 다양하게 조회하거나 데이터를 다양하게 전처리해야 하는 동적인 정보도 응답한다. 즉, 동적인 정보는 정적인 정보와는 반대로 송수신 과정에서 수정과 처리가 필요한 정보와 언제, 어디서, 누가 보는지에 따라 변할 수 있는 정보를 말한다. 이러한 동적인 정보의 생성 응답을 위해 활용하는 것이 웹 애플리케이션 서버(WAS, Web Application Server)이다.

 

웹 서비스에는 웹 서버와 웹 애플리케이션 서버가 함께 사용되는 경우가 많다. 웹 서비스가 수신하는 요청 중 정적인 정보는 웹 서버가 응답하고, 동적인 정보는 웹 애플리케이션 서버가 응답하도록 설계하면 과도한 부하를 줄일 수 있고, 여러 웹 애플리케이션을 연동하여 확장하는 데에도 유리하다. 우베 애플리케이션 서버는 미들웨의 일종으로도 불린다. 미들웨어(middleware)란 운영체제와 응용 프로그램 사이를 조정하고 중개하는 중간 다리 역할의 소프트웨어를 말한다. 이때 서버 개발의 맥락에서 '응용 프로그램'의 대표적인 예시로는 각종 웹 프레임워크로 만든 프로그램을 꼽을 수 있다.

---

■ 소켓 프로그래밍

네트워크 소켓(이하 소켓, socket)은 택배를 보관할 수 있는 우체통과도 같다. 소켓은 프로세스가 주고받는 데이터읮 ㅗㅇ착점과도 같다. 종착점을 영어로는 엔드포인트(endpoint)라고 한다. 그래서 소켓을 프로세스 간 네트워크 통신의 엔드포인트라고 정의하기도 한다.

 

실제로 소켓은 많은 운영체에서 '파일'처럼 간주된다. 보내고자 하는 메시지를 쓰면 네트워크를 통해 송신되고, 때로는 수신한 메시지를 읽어 들일 수 있는 특별한 파일로 간주된다. 소켓을 향한 출력은 네워크를 통한 송신, 소켓으로부터의 입력은 네트워크를 통한 수신과도 같다.

 

소켓 입출력과 관련해 다양한 시스템 콜이 존재한다. 소켓을 이용하면 네트워크 송수신을 수행하는 프로세스들은 이러한 시스템 콜을 활용해 동작한다.

---

참고 도서

이것이 컴퓨터 과학이다.