로드 밸런싱·오토스케일링·Prometheus를 하나의 SLO 폐루프로 묶는 법

로드 밸런서가 트래픽을 고르게 나누고 오토스케일러가 인스턴스를 늘려도, 둘이 같은 목표를 보고 움직이지 않으면 문제가 생긴다. 로드 밸런서는 이미 들어온 요청을 분산할 뿐이고, 오토스케일러는 별도의 메트릭 임계값에 따라 뒤늦게 반응한다. Load Balancing, Auto-Scaling, Prometheus 기반 모니터링을 SLO 하나로 묶어 폐루프로 만들어야 하는 이유가 여기 있다.

로드 밸런싱: L4와 L7을 어디에 쓰나

L4 로드 밸런싱은 전송 계층에서 동작해 고성능·저오버헤드가 강점이고, L7은 애플리케이션 계층의 컨텍스트를 보고 라우팅·WAF·캐싱까지 처리할 수 있다. 서비스 특성에 따라 둘을 혼용하는 편이 일반적이다 — 코어 데이터 경로는 L4로 두고, 도메인·보안·경로 분기가 필요한 지점만 L7로 배치해 이중 처리로 인한 지연 증가를 최소화한다. 이때 keep-alive와 커넥션 재사용이 함께 있어야 L7 오버헤드가 누적되지 않는다.

분산 알고리즘은 라운드 로빈, 최소 연결, 가중치, 일관 해시 중에서 지연시간·세션 특성·캐시 적중률을 기준으로 고른다. 여기에 헬스 체크, 커넥션 드레이닝, 스티키 세션, 서킷 브레이커 같은 운용 요소가 붙고, 제한 조건 아래서는 백프레셔와 로드 쉬딩으로 과부하를 흡수한다.

항목	성능	확장성	일관성	안정성	운영 편의
L4 로드 밸런싱	매우 높음	매우 높음	중간	높음	높음
L7 로드 밸런싱	높음	높음	높음	중간	중간
클라이언트 사이드 LB	중간	매우 높음	낮음(클라이언트 구현 영향)	중간	낮음(라이브러리 관리)

오토스케일링은 어떤 신호를 보는가

Kubernetes 환경에서는 HPA(수평), VPA(자원 권장치), Cluster Autoscaler(노드 규모)가 각각 다른 층을 맡고, 스케일 단계마다 쿨다운으로 보호한다. 메트릭 원천은 CPU·메모리 같은 리소스 지표부터 애플리케이션 RPS·큐 길이·지연시간(p95/p99)까지 걸쳐 있는데, Prometheus Adapter를 쓰면 이런 애플리케이션 메트릭을 External metric으로 노출해 HPA에 바로 연결할 수 있다. 예약 이벤트나 시간대 패턴을 반영해 미리 스케일 아웃하는 예측형 스케일링도 가능하지만, 과도한 선제 확장은 그만큼 비용으로 돌아온다는 트레이드오프가 있다. 이런 신호 기반 오토스케일링으로 초당 요청 처리량은 1.5~~3배 확장되고, 트래픽 급증 시 오류율은 40~~80% 줄어든다.

Prometheus가 신호를 만드는 파이프라인

스크레이프 타깃, relabeling, 샘플링·보존 정책을 구성해 데이터를 모으는 수집 단계에서는 고카디널리티 라벨 관리가 특히 중요하다. 분석은 PromQL로 SLI를 계산하는데, 예를 들어 p95 지연시간은 이렇게 구한다.

histogram_quantile(0.95, rate(http_request_duration_seconds_bucket{job="web"}[5m]))

여기서 만든 신호는 Alertmanager 라우팅을 거쳐 슬랙·온콜로 연결되고, 자동 실행 Runbook·스크립트까지 이어질 수 있다. 억제·그룹화 설계를 함께 넣지 않으면 알림 소음이 그대로 팀을 지치게 만든다. 이 설계를 갖추면 알림 소음이 30~~60% 줄고 MTTR이 20~~40% 단축된다.

폐루프: 입력에서 행동까지

로드 밸런싱·오토스케일링·모니터링을 각자 따로 두지 않고 하나의 제어 루프로 묶는 게 핵심이다. 메트릭·로그가 입력으로 들어오면 SLO 기반 정책이 판단하고, 그 결과로 스케일·셰이딩·격리 같은 행동이 실행된다. 여기에 스로틀링, 큐잉, 타임아웃, 재시도 예산 같은 보호 기법을 더해 장애 격리와 캐스케이드 실패 방지를 노린다. 이 루프가 실제로 안전한지는 부하·혼합 트래픽 테스트와 카나리 스케일 정책 검증으로 확인하고, 문제가 생겼을 때 되돌아갈 수 있는 롤백 경로를 항상 남겨둬야 한다.

⤢✕

왜 단일 목표 함수인가

이 루프를 설계할 때 가장 자주 부딪히는 함정은 지표를 여러 개 동시에 최적화하려는 시도다. p95 지연시간이든 에러율이든 단일 SLO 기준으로 의사결정을 내리는 편이 권장되는데, 다중 KPI를 동시에 잡으려 하면 정책끼리 상충할 위험이 커지기 때문이다. 이렇게 SLO 하나로 폐루프를 운영하면 p95 지연시간이 20~~50%, 스파이크 시 꼬리 지연(p99)은 30~~60% 개선되고, 오류예산 소모율은 3070% 개선된다. 비용과 성능 사이에서도 마찬가지 절충이 필요하다 — 선제 스케일 아웃은 지연을 안정시키지만 비용을 늘리므로, 예약 스케일링에 HPA를 결합해 평상시 비용과 이벤트 시 안정성의 균형을 맞추는 식이 현실적이다. 이 조합을 스케일 인·예약 기준으로 운용하면 인프라 단위 비용이 1535% 절감된다.

실무에서는 이렇게 조합한다

전자상거래 피크 트래픽 대응은 L7 경로 기반 라우팅과 캐시를 두고 RPS 기반 HPA에 사전 예약 스케일 아웃을 얹는다. p95 300ms를 SLO로 정하고 부하 테스트로 초기 리플리카 수를 산정한 뒤, 블랙프라이데이 전에는 2배로 선제 확장하고 이벤트 기간에는 HPA 민감도를 올린다. 결제와 상품상세는 별도로 스케일한다.

실시간 스트리밍·게임은 L4 UDP 로드 밸런싱에 최소 연결과 연결 지속성을 조합하고, 지연 예산을 기준으로 로드 쉬딩을 건다. 지연 임계를 넘으면 가까운 리전을 우선하는 지역별 GSLB로 레이턴시를 관리하고, 큐 길이가 오르면 HPA가 트리거되되 스케일 인 보호로 세션이 끊기지 않게 한다.

B2B API 플랫폼의 멀티리전 DR은 헬스 체크 기반 GSLB로 액티브-액티브 구성을 두고, 리전별로 HPA/CA를 독립 운영하며 글로벌 레이트 리밋을 건다. 리전 장애가 감지되면 30초 안에 트래픽을 전이하고, 이후 백필·리밸런싱을 거쳐 점진적으로 복귀한다.

구현: Kubernetes HPA + Prometheus 커스텀 메트릭

전제조건은 Kubernetes v1.26+(최신 정보 확인 필요), Metrics Server 설치, Prometheus Operator·Prometheus Adapter 설치, 그리고 web이라는 이름의 Deployment 존재다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 3
  maxReplicas: 50
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 30
          periodSeconds: 60
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: External
      external:
        metric:
          name: http_requests_per_second
          selector:
            matchLabels:
              service: web
        target:
          type: AverageValue
          averageValue: "100"

커스텀 메트릭 노출은 Prometheus Adapter에서 RPS 메트릭을 External metric(http_requests_per_second)으로 매핑하는 식으로 이뤄진다. 지연시간 기반 제어까지 더하고 싶다면 p95 지표를 SLA 임계로 변환해 레이트 리밋·로드 쉬딩 정책에 연동하면 된다.