로드 밸런서

서비스의 사용자가 늘어나면, 하나의 서버로는 모든 요청을 처리할 수 없습니다.

서버를 여러 대로 확장(Scale Out)하면, 들어오는 요청을 어떤 기준으로 어떤 서버에 보낼지 결정해야 합니다.

이 역할을 하는 것이 로드 밸런서(Load Balancer)입니다.

L4 vs L7 로드 밸런서

로드 밸런서는 동작하는 계층에 따라 두 종류로 나뉩니다.

L4 로드 밸런서는 전송 계층(TCP/UDP)에서 동작합니다.

IP 주소, 포트, 프로토콜 같은 연결/흐름 정보를 기준으로 트래픽을 분배하고, HTTP 헤더나 URL 경로는 해석하지 않습니다.

처리가 빠르고 오버헤드가 적습니다.

AWS의 NLB(Network Load Balancer)가 대표적입니다.

L7 로드 밸런서는 애플리케이션 계층(HTTP)에서 동작합니다.

HTTP 헤더, URL 경로, 쿠키 등을 분석하여 라우팅 결정을 내립니다.

/api/* 요청은 API 서버 그룹으로, /static/* 요청은 정적 파일 서버 그룹으로 보내는 것이 가능합니다.

HTTPS 트래픽에서 URL이나 헤더를 기준으로 라우팅하려면 보통 로드 밸런서에서 TLS를 종료하고, 필요하면 백엔드로 다시 TLS를 연결합니다.

AWS의 ALB(Application Load Balancer)가 대표적입니다.

로드 밸런싱 알고리즘

IP 해시는 “같은 IP는 같은 서버로 가게 할 가능성”을 높이지만, NAT나 모바일망처럼 여러 사용자가 같은 공인 IP를 공유하면 특정 서버에 부하가 몰릴 수 있습니다.

쿠키 기반 sticky session도 비슷하게 장애와 불균형을 같이 고려해야 합니다.

헬스 체크

헬스 체크는 보통 HTTP 요청, TCP 연결, gRPC 헬스 체크 같은 방식으로 대상 서버가 트래픽을 받을 수 있는지 확인합니다.

단, 모든 헬스 체크가 같은 의미는 아닙니다.

liveness는 프로세스가 죽었는지 확인하는 얕은 체크에 가깝고, readiness는 지금 트래픽을 받아도 되는지 확인하는 체크입니다.

DB 연결 같은 의존성 검사는 readiness에는 유용하지만, liveness에 과하게 넣으면 일시적인 DB 장애가 전체 서버 재시작으로 번질 수 있습니다.

# Flask 헬스 체크 엔드포인트 예: live와 ready를 분리
from flask import Flask, jsonify
import psycopg2

app = Flask(__name__)

@app.route("/live")
def live():
    return jsonify({"status": "alive"}), 200

@app.route("/ready")
def ready():
    checks = {"status": "ready"}
    try:
        conn = psycopg2.connect("dbname=mydb user=app")
        conn.close()
        checks["database"] = "ok"
    except Exception:
        checks["database"] = "fail"
        checks["status"] = "unhealthy"
        return jsonify(checks), 503

    return jsonify(checks), 200

로드 밸런서는 일정 횟수 이상 실패한 서버를 대상에서 제외하고, 다시 연속 성공하면 트래픽을 보내기 시작합니다.

이 과정이 자동화되어 있으므로 서버 장애가 발생해도 사용자는 다른 정상 서버를 통해 서비스를 계속 이용할 수 있습니다.

실제 운영에서는 timeout, interval, healthy/unhealthy threshold, drain 시간까지 함께 조정합니다.

Sticky Session과 세션 공유

세션 기반 인증에서 사용자의 세션이 서버 A의 메모리에 저장되어 있다면, 다음 요청이 서버 B로 가면 로그인 상태가 유지되지 않습니다.

올바른 해결책은 세션을 외부 저장소에서 공유하거나 JWT 같은 토큰 기반 인증을 사용하는 것입니다.

다만 JWT도 만료 시간, refresh token, 강제 로그아웃, 키 회전, 토큰 탈취 대응까지 설계해야 합니다.

Sticky Session은 간단한 완충책일 수 있지만, 장기적으로는 서버 메모리에 사용자 상태를 묶지 않는 구조가 더 확장에 유리합니다.

로드 밸런서는 단순히 “요청을 나누는 장비”가 아니라, TLS 종료 지점, 장애 감지 기준, 세션 상태, 배포 중 drain 전략까지 함께 결정하는 운영 경계입니다.

로드 밸런서는 분산 방식, 헬스 체크, 세션 유지, 장애 전환 기준으로 점검합니다.

다음 절에서는 로드 밸런서와 함께 자주 등장하는 프록시와 VPN을 다루겠습니다.