Written by Google Gemini 2.5 Pro

• Deep Research 정리 문서: https://docs.google.com/document/d/1Bwx6voatv_vBj-aGnSgc7PJZmKLdmLi7Ll5-xGqgZ9s/edit?tab=t.0

📌 1. 로드밸런싱의 개념과 필요성

가. 로드밸런싱이란?

• 로드밸런싱은 애플리케이션에 가해지는 트래픽 부하(Load)를 여러 대의 서버에 효율적으로 분산(Balancing)하는 기술이다.
• 이 작업을 수행하는 하드웨어 또는 소프트웨어를 로드밸런서(Load Balancer)라고 하며, 클라이언트와 서버 그룹 사이에 위치하여 '교통 경찰' 역할을 수행한다.

나. 로드밸런싱의 핵심 이점

1. 고가용성: 일부 서버에 장애가 발생해도 정상 작동하는 다른 서버로 트래픽을 자동 전환하여 서비스 중단을 방지한다.
2. 확장성: 트래픽 증감에 따라 서버를 유연하게 추가하거나 제거하여 시스템 규모를 손쉽게 조정할 수 있다.
3. 성능 향상: 특정 서버의 과부하를 막고 자원을 최적으로 활용하여 전체적인 응답 속도를 개선할 수 있다.
4. 보안 강화: DDoS와 같은 공격 트래픽을 분산시키고, 웹 방화벽(WAF)과 연동하여 보안 위협을 완화한다.

다. 로드밸런싱의 필요성: Scale-Up vs Scale-Out

• 과거에는 서버 성능을 높이는 스케일업(Scale-Up) 방식으로 트래픽 증가에 대응했지만, 비용이 비싸고 성능 향상에 한계가 있으며, 서버 자체가 단일 장애점(SPOF, Single Point of Failure)이 되는 치명적 단점이 있었다.
• 이를 극복하기 위해 여러 대의 서버를 추가하는 스케일아웃(Scale-Out) 방식이 등장했으며, 이 방식의 이점을 극대화하기 위해 여러 서버에 트래픽을 지능적으로 분배하는 로드밸런싱이 필수 기술이 되었다.

라. L4 vs L7 로드밸런서

특징	L4 (전송 계층)	L7 (애플리케이션 계층)
분산 기준	IP 주소, 포트 번호	HTTP 헤더, 쿠키, URL 등 콘텐츠 정보
장점	패킷 내용 미확인으로 처리 속도 빠름, 비용 저렴	콘텐츠 기반의 정교하고 지능적인 라우팅 가능
단점	단순 IP/포트 기반 분산만 가능, 세밀한 제어 불가	패킷 내용 분석으로 인한 부하 및 비용 증가

---

📌 2. 로드밸런싱 알고리즘과 기술 원리

가. 정적 알고리즘

서버의 현재 상태와 무관하게, 사전에 정의된 규칙에 따라 요청을 분배한다.

1. 라운드 로빈 (Round Robin): 요청을 서버 목록에 따라 순차적으로 분배하는 가장 기본적인 방식
2. 가중 라운드 로빈 (Weighted Round Robin): 서버의 처리 성능에 따라 가중치를 부여하고, 가중치가 높은 서버에 더 많은 요청을 할당하는 방식
3. IP 해시 (IP Hash): 클라이언트의 IP 주소를 해싱하여 특정 서버로만 요청을 보내 세션 유지를 도움

나. 동적 알고리즘

서버의 실시간 부하 상태를 확인하여 최적의 서버로 요청을 분배한다.

1. 최소 연결 (Least Connection): 현재 연결 수가 가장 적은 서버로 요청을 보내, 세션이 길어지는 서비스에 유리하다.
2. 최소 응답 시간 (Least Response Time): 연결이 가장 적으면서 응답 시간도 가장 빠른 서버로 요청을 보내 사용자 경험을 극대화한다.

다. 로드밸런서 이전의 부하 분산: DNS 라운드 로빈

• 전용 로드밸런서가 보편화되기 전에는, 하나의 도메인에 여러 서버의 IP를 등록하고 DNS 서버가 이를 순차적으로 응답해주는 DNS 라운드 로빈 방식을 사용했다.
• 하지만 이 방식은 서버의 장애 여부를 감지하지 못하고, DNS 캐시 문제로 인해 부하가 균등하게 분산되지 않는 명확한 한계가 있었다.

---

📌 3. 장애 대응 및 고가용성

가. 장애 감지: 헬스 체크 (Health Check)

• 로드밸런서는 주기적으로 백엔드 서버의 상태를 점검(헬스 체크)하여 장애 여부를 판단한다.
• L4 헬스 체크는 포트 활성화 여부를, L7 헬스 체크는 실제 애플리케이션의 정상 응답(예: HTTP 200 OK) 여부를 확인하여 더 정확한 장애 감지가 가능하다.

나. 자동화된 장애 처리 (Failover)

• 헬스 체크를 통해 특정 서버에 장애가 감지되면, 로드밸런서는 해당 서버를 트래픽 분배 대상에서 즉시 제외하고 나머지 정상 서버로만 요청을 자동 전환한다.
• 장애가 복구되면 다시 트래픽 분배 대상에 포함시켜 서비스 연속성을 보장한다.

다. 단일 장애점(SPOF) 제거: 이중화 구성

• 로드밸런서 자체의 장애에 대비하기 위해, 두 대 이상의 로드밸런서를 클러스터로 구성하여 이중화한다.
  1. Active-Standby: 한 대(Active)가 동작하고 다른 한 대(Standby)는 대기하다가, 장애 발생 시 Standby 장비가 즉시 역할을 이어받는 방식이다.
  2. Active-Active: 두 대 이상의 장비가 동시에 트래픽을 처리하여 자원 효율성을 높이고 장애 발생 시에도 중단 없이 서비스를 운영하는 방식이다.

---

📌 4. 클라우드 플랫폼별 로드밸런서 비교: AWS vs NCP

기능	AWS (Elastic Load Balancing)	NCP (Load Balancer)
L7 (Application)	Application Load Balancer (ALB): 경로, 헤더 등 정교한 L7 라우팅 규칙 제공. 대상 그룹에 EC2, 컨테이너, Lambda 등 다양한 리소스 지정 가능.	Application Load Balancer: 고정 IP 제공, URL 경로 및 호스트 헤더 기반 라우팅 지원.
L4 (Network)	Network Load Balancer (NLB): 초저지연, 고성능 L4 처리. 고정 IP(Elastic IP) 할당 가능.	Network LB: DSR(Direct Server Return) 모드 지원으로 응답 성능 극대화.
알고리즘	ALB: 라운드 로빈, 최소 미결 요청NLB: 플로우 해시	라운드 로빈, 최소 연결, 소스 IP 해시
요금 정책	시간당 요금 + LCU(처리 용량 단위) 기반의 복잡한 종량제	성능 등급(Small/Medium/Large)에 따른 고정 시간당 요금 + 아웃바운드 트래픽 기반으로 예측 용이

---

📌 5. 핵심 과제: 세션 유지(Session Persistence) 문제와 해결 방안

• 로드밸런싱 환경에서는 클라이언트의 요청이 매번 다른 서버로 전달될 수 있어, 로그인 정보와 같은 세션 데이터가 유지되지 않는 문제가 발생한다.
• 이를 '세션 불일치' 문제라고 하며, 해결을 위해 특정 사용자의 요청을 하나의 서버로 고정시키는 '세션 유지' 기술이 필요하다.

가. IP 해시 방식 (IP Hash Method)

동작 원리

• 클라이언트의 출발지 IP 주소를 해시 함수에 입력하여 그 결과값에 따라 특정 서버를 고정적으로 할당한다.
• 클라이언트의 IP가 바뀌지 않는 한, 모든 요청은 항상 같은 서버로 전달된다.

장점

• 별도의 설정 없이 간단하게 세션 유지를 구현할 수 있다.

단점

• 여러 사용자가 하나의 공인 IP를 공유하는 환경(예: 대기업, 공공기관의 NAT)에서는 모든 요청이 단 하나의 서버에만 집중되어 로드밸런싱의 의미가 퇴색된다.
• 또한, 모바일 환경처럼 사용자의 IP가 자주 바뀌면 세션이 끊어지는 문제가 발생한다.

나. 스티키 세션 (Sticky Session / 쿠키 기반)

동작 원리

• 클라이언트의 첫 요청 시, 로드밸런서나 애플리케이션 서버가 클라이언트의 브라우저에 특정 서버 정보를 담은 쿠키를 심는다.
• 이후 클라이언트가 요청을 보낼 때마다 로드밸런서는 이 쿠키를 확인하여 지정된 서버로 요청을 전달함으로써 세션을 고정시킨다.

장점

• IP 주소 대신 고유한 쿠키를 사용하므로, NAT 환경의 IP 중복 문제를 해결할 수 있다.

단점

• 특정 서버에 사용자가 몰릴 경우 부하가 불균등해질 수 있으며, 가장 큰 문제는 세션이 고정된 서버에 장애가 발생하면 해당 서버에 저장된 모든 세션 정보가 유실된다는 점이다.

다. 세션 스토리지 분리

• IP 해시와 스티키 세션은 구현이 간단하지만 근본적인 한계를 가진다. 이 때문에 현대적인 아키텍처에서는 세션 스토리지 분리 방식을 선호한다.
• 이는 세션 데이터를 각 서버의 메모리가 아닌, 모든 서버가 접근할 수 있는 별도의 외부 저장소(예: Redis, Memcached와 같은 인메모리 데이터베이스)에 저장하는 방식이다.
• 이 방식을 사용하면 사용자의 요청이 어떤 서버로 전달되든 동일한 세션 데이터에 접근할 수 있어 로드밸런싱과 고가용성을 동시에 달성할 수 있다.
  • 다만, 세션 저장소 자체가 또 다른 단일 장애점이 되지 않도록 이중화 구성이 필요하다.

---

🛎️ 퀴즈

https://g.co/gemini/share/75695c6e3b05