✅ 압박면접 대응 시리즈 30편: 로드 밸런싱(Load Balancing) 구조 설계와 트래픽 분산 전략

✅ 압박면접 대응 시리즈 30편: 로드 밸런싱(Load Balancing) 구조 설계와 트래픽 분산 전략

압박면접에서 “트래픽이 몰리면 어떻게 대응하시나요?”라는 질문은
단순히 “서버를 늘립니다”로 끝내면 바로 후속 질문이 들어옵니다.

“어떻게 늘리나요?”
“로드밸런서가 어떤 방식으로 요청을 분산하죠?”
“Sticky Session이 필요한 상황은요?”

즉, 면접관은 **“트래픽을 분산시키는 아키텍처 사고력”**을 평가합니다.

이번 글에서는 로드 밸런싱의 원리, 알고리즘별 특성, 실제 인프라 구성,
그리고 면접에서 설득력 있게 설명할 수 있는 사례를 정리했습니다.

---

📌 1. 로드 밸런싱(Load Balancing)이란?

여러 서버(노드)에 요청을 분산시켜 시스템 부하를 균등하게 유지하는 기술

즉, 모든 요청이 한 서버로 몰리지 않도록 분산함으로써 가용성(Availability) 과 확장성(Scalability) 을 보장합니다.

계층 예시 역할

L4 로드밸런서	AWS ELB, Nginx Stream, HAProxy	TCP/UDP 레벨 분산
L7 로드밸런서	Nginx, Envoy, API Gateway	HTTP 헤더·URL 기반 분산

📌 핵심 포인트:

“L4는 속도 중심, L7은 지능형 라우팅 중심.”

---

📌 2. 주요 로드 밸런싱 알고리즘

알고리즘 설명 특징

Round Robin	순차적으로 서버에 분배	기본 방식, 단순·균등
Least Connections	연결 수가 적은 서버로 전송	실시간 트래픽 균형
IP Hash	클라이언트 IP로 분배	세션 유지에 유리
Weighted Round Robin	서버별 가중치 설정	이기종 서버 환경 적합
Consistent Hashing	동일 사용자를 동일 서버로 유지	캐시 서버 등에서 사용

📌 면접 포인트:

“세션 유지가 필요한 로그인 서비스에는 IP Hash,
단순 API 트래픽은 Round Robin을 사용했습니다.”

---

📌 3. Nginx 기반 로드 밸런서 예시

http {
  upstream app_cluster {
    least_conn;
    server app1.example.com weight=3;
    server app2.example.com weight=2;
  }

  server {
    listen 80;
    location / {
      proxy_pass http://app_cluster;
    }
  }
}

📌 해석:

• least_conn: 연결 수가 적은 서버에 우선 배정
• weight: 서버별 가중치 부여
• proxy_pass: 요청을 백엔드 클러스터로 전달

---

📌 4. 로드 밸런싱 + 세션 관리 전략

반응형

✅ (1) Sticky Session (고정 세션)

사용자의 세션이 항상 동일 서버로 연결되도록 함

• 장점: 로그인 정보 유지
• 단점: 특정 서버에 부하 집중

ip_hash;

📌 면접 포인트:

“Sticky Session은 로그인 서비스에서는 필요하지만,
Stateless JWT 인증 환경에서는 불필요합니다.”

---

✅ (2) Stateless 인증 구조 (JWT 기반)

• 서버 간 세션 공유 불필요
• 어느 서버로 분배돼도 정상 응답 가능

📌 면접 포인트:

“JWT 기반 인증으로 Sticky Session을 제거해 확장성을 확보했습니다.”

---

📌 5. 트래픽 분산 아키텍처 설계

graph TD
U[User] --> L7[Load Balancer]
L7 --> A1[App Server 1]
L7 --> A2[App Server 2]
L7 --> A3[App Server 3]
A1 --> DB[(Database)]
A2 --> DB
A3 --> DB

• 클라이언트 요청 → L7 LB → Application 서버 다중 분산
• 서버 상태 감시(Health Check)로 장애 서버 자동 제외

---

📌 6. 실무 적용 사례

상황:
트래픽 급증 이벤트(최대 RPS 15,000) 중 서버 다운 발생

해결 과정:

1. HAProxy로 L4 로드밸런싱 구조 설계
2. Nginx L7 레이어 추가로 요청 라우팅 분리
3. JWT 기반 Stateless 인증 구조로 Sticky Session 제거
4. Prometheus로 서버별 요청량 모니터링

📈 결과:

• 서버 다운 0건
• CPU 사용률 85% → 58% 감소
• 트래픽 급증 구간 RPS 2배 처리 가능

---

📌 7. 압박면접 예상 질문 & 답변 포인트

• ❓ Q. L4와 L7 로드밸런서의 차이는?
  → “L4는 전송 계층(TCP/UDP), L7은 애플리케이션 계층(HTTP)에서 동작합니다.”
• ❓ Q. 세션 유지가 필요한 서비스에서 확장성을 확보하려면?
  → “Redis 세션 스토어를 사용하거나, JWT 기반으로 전환합니다.”
• ❓ Q. 장애 서버 감지는 어떻게 처리하나요?
  → “Health Check 엔드포인트(/health)를 주기적으로 호출해 비정상 노드를 제외했습니다.”

---

📌 8. 면접에서 활용할 한 줄 정리

“L4 + L7 로드밸런싱 구조를 구축해
트래픽 급증 시에도 서버 안정성을 확보했습니다.
Sticky Session을 제거하고 JWT 기반 인증으로 확장성을 높였습니다.”

---

압박면접,로드밸런싱,LoadBalancer,Nginx,HAProxy,트래픽분산,StickySession,JWT,DevOps,고가용성

---