트래픽 증가, 어떻게 해결하지?
데이터 통신이 활발해지며 사람들 사이에서 인터넷 사용량이 급등하게 되었습니다. 이는 트래픽의 폭발적인 증가로 이어졌습니다.
트래픽의 증가로 인해 하나의 서버에서 모든 트래픽을 감당해내기 어려워졌고 결국 인프라를 확장하여 트래픽을 감당하게 됩니다.
크게 Scale-Up 방식과 Scale-Out 방식이 있는데 한번 살펴보도록 하겠습니다.
Scale-Up 방식
스케일 업 방식은 기존 서버의 사양을 업그레이드하여 시스템을 확장하는 것을 뜻합니다.
CPU나 RAM 등을 추가하거나 고성능의 부품, 서버로 교환하는 방법입니다.
하나의 서버 사양을 업그레이드 하기 때문에 수직 스케일로 불리기도 합니다.
단점으로는 한 대의 서버에 부하가 집중되어 장애 영향도가 큽니다. 쉽게 말해, 장애가 났을 때 서버 전체가 마비되는 경우가 발생하기 때문에 장애 발생에 대해 고려해야할 사항이 많습니다.
또한 성능 증가에 따른 비용 증가폭이 크고 성능 확장에 한계가 있습니다.
Scale-Out 방식
스케일 아웃 방식은 서버를 여러 대 추가하여 시스템을 확장하는 것을 뜻합니다.
서버가 여러 대로 나뉘기 때문에 각 서버에 걸리는 부하를 균등하게 해주는 로드 밸런싱이 필수적으로 동반되어야 합니다.
여러 대의 서버로 나눠 시스템을 확장하기 때문에 수평 스케일로 불리기도 합니다.
비교적 저렴한 서버를 사용함으로 비용 부담이 적고 지속적인 확장이 가능합니다.
또한 여러 대의 서버에 분산 처리를 하기 때문에 장애 시 서버 교체 등 전면 장애의 가능성이 적습니다.
하지만 위에서 언급한 바 있듯이 서버가 여러 대로 나뉘기 때문에 각 서버에 트래픽을 분산시켜 주기 위해 로드 밸런싱이 필요하며 다중 서버를 사용하기 때문에 공통적으로 사용되는 세션 정보 등을 다중 서버에서 공유 가능하도록 구현해줘야 합니다.
로드 밸런싱이란?
단순히 다수의 서버를 구축해 운영한다고 해서 모든 클라이언트의 요청에 일관성 있게 응답할 수 있을까요?
쏟아지는 트래픽을 여러 대의 서버로 분산시켜주는 기술이 없다면 한 곳의 서버에 모든 트래픽이 몰리는 상황이 발생할 것입니다.
이를 방지하기 위해 필요한 기술이 바로 로드 밸런싱입니다.
로드 밸런싱이란 서버가 처리해야할 업무 혹은 요청을 여러 대의 서버로 나누어 처리하는 것을 의미합니다
한 대의 서버로 부하가 집중되지 않도록 트래픽을 관리해 각각의 서버가 최적의 퍼포먼스를 보일 수 있도록 하는 것이 목적입니다.
로드밸런싱
가운데에 있는 로드 밸런서에서 서버 문제를 자동으로 감지하고 클라이언트 트래픽을 사용 가능한 서버로 리다이렉션하는 역할을 하게 됩니다.
이를 통해 애플리케이션 가동 중지 없이 서버를 유지할 수 있고 업그레이드하여 실행할 수 있습니다.
로드 밸런싱 기법
로드 밸런싱을 해주기 위한 여러가지 알고리즘이 있습니다. 서버의 능력을 고려하고 상황에 따라 알맞은 방법을 선택하여야 합니다.
라운드로빈 방식(Round Robin Method)
서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식입니다. 클라이언트의 요청을 순서대로 분배하기 때문에 여러 대의 서버가 동일한 스펙을 갖고 있고, 모든 요청이 비슷한 처리 시간을 가질 경우(세션의 길이의 차이가 적을 경우)에 활용하기 적합합니다.
가중 라운드로빈 방식(Weighted Round Robin Method)
각각의 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분합니다. 주로 서버의 트래픽 처리 능력이 상이한 경우 사용되는 부하 분산 방식입니다. 예를 들어 A라는 서버가 5라는 가중치를 갖고 B라는 서버가 2라는 가중치를 갖는다면, 로드 밸런서는 라운드로빈 방식으로 A 서버에 5개 B 서버에 2개의 요청을 전달합니다.
IP 해시 방식(IP Hash Method)
클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식입니다. 사용자의 IP를 해싱해(Hashing, 임의의 길이를 지닌 데이터를 고정된 길이의 데이터로 매핑하는 것, 또는 그러한 함수) 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장합니다.
최소 연결 방식(Least Connection Method)
요청이 들어온 시점에 가장 적은 연결상태를 보이는 서버에 우선적으로 트래픽을 배분합니다. 이 방식은 세션의 길이 차이가 크게 나타날 때 더 적합합니다. 예를 들어, 일부 요청은 매우 짧은 처리 시간을 가지고 있고, 다른 요청은 긴 세션을 필요로 하는 경우, 이 방식은 현재 가장 적은 연결을 가진 서버에 요청을 배분하여 서버 간 부하를 균등하게 관리할 수 있습니다.
최소 응답 시간 방식(Least Response Time Method)
서버의 현재 연결 상태와 응답 시간(Response Time, 서버에 요청을 보내고 최초 응답을 받을 때까지 소요되는 시간)을 모두 고려하여 트래픽을 배분합니다. 가장 적은 연결 상태와 가장 짧은 응답 시간을 보이는 서버에 우선적으로 로드를 배분하는 방식입니다.
서버의 응답 시간은 아래의 방법으로 로드밸런서가 동적으로 측정하거나 관리할 수 있습니다.
액티브 체크(동일 요청에 대한 응답 시간 측정)
이 방식에서는 모든 서버에 동일한 테스트 요청(예: 특정 API 호출)을 보내고 각 서버가 이 요청에 얼마나 빠르게 응답하는지 측정합니다. 이렇게 함으로써 각 서버의 응답 시간을 공정하게 비교할 수 있습니다. 흔히 사용되는 건강 검사(Health Check)가 이 방식을 따릅니다.
예를 들어, 로드밸런서는 모든 서버에 '/example' 같은 경로로 HTTP GET 요청을 보내고, 서버가 응답하는 데 걸리는 시간을 측정할 수 있습니다.
패시브 체크(서로 다른 요청에 대한 응답 시간 측정)
이 방식에서는 실제 클라이언트의 요청에 대한 서버의 응답 시간을 패시브하게 측정합니다. 즉, 클라이언트로부터 서로 다른 요청들이 수신되고, 각 요청에 대해 각 서버가 얼마나 빠르게 응답하는지를 측정하여 데이터를 수집합니다.
이 방법은 각 서버가 다양한 종류의 요청을 처리하는 능력을 반영할 수 있어, 더 정확한 부하 분배가 가능할 수 있습니다. 예를 들어, 서버 A는 이미지 처리 요청에 대해 빠르게 응답할 수 있지만, 복잡한 데이터베이스 쿼리 요청에는 느릴 수 있습니다.
L4 로드 밸런싱과 L7 로드 밸런싱
로드 밸런싱에는 L4 로드 밸런싱과 L7 로드 밸런싱이 가장 많이 활용됩니다.
L4, L7은 각각 Layer 4(전송 계층) 프로토콜과 Layer 7(응용 계층) 프로토콜의 헤더를 부하 분산에 이용하기 때문에 붙은 접두사입니다. 모든 요청을 L4 혹은 L7 로드 밸런서가 받아 서버들에게 적절히 나누어 줍니다.
L4 로드 밸런서는 네트워크 계층(IP, IPX)이나 전송 계층(TCP, UDP)의 정보(IP주소, 포트번호, MAC주소, 전송 프로토콜)를 바탕으로 로드를 분산합니다.
L7 로드 밸런서는 애플리케이션 계층(HTTP, FTP, SMTP)에서 로드를 분산하기 때문에 HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능합니다. 쉽게 말해 패킷의 내용을 확인하고 그 내용에 따라 로드를 특정 서버에 분배하는 것이 가능합니다. URL에 따라 부하를 분산시키거나, HTTP 헤더의 쿠키 값에 따라 부하를 분산하는 등 클라이언트의 요청을 보다 세분화해 서버에 전달할 수 있습니다.
또한 L7 로드 밸런서의 경우 특정한 패턴을 지닌 바이러스를 감지해 네트워크를 보호할 수 있으며, DoS/DDoS와 같은 비정상적인 트래픽을 필터링할 수 있어 네트워크 보안 분야에서도 활용되고 있습니다.
