오토스케일링을 설계할 때 어떤 지표를 사용할 수 있나요?

CPU와 메모리뿐 아니라 요청 수, p95 지연 시간, 큐 길이, 처리 지연 같은 워크로드 특화 지표가 더 적합할 수 있습니다.

핵심 개념

핵심 기준은 부하를 잘 대표하는 확장 지표입니다.

오토스케일링은 부하에 맞춰 인스턴스 수를 자동 조정합니다. CPU 기반 확장은 단순하지만 I/O 중심 API나 큐 기반 워커에서는 실제 병목을 잘 반영하지 못할 수 있습니다. 웹 API는 RPS, inflight request, p95 latency가, 워커는 queue depth와 oldest message age가 유용합니다.

동작 흐름

1. 요구사항을 성능, 안정성, 보안, 복구 목표로 나눠 정의합니다.
2. 정상 흐름과 장애 흐름에서 각 구성 요소가 어떻게 동작하는지 확인합니다.
3. 자동화와 관찰 지표로 변경 결과를 검증합니다.
4. 롤백, 복구, 확장, 비용 관리까지 운영 절차로 문서화합니다.

실제 예시

scalePolicy:
  minReplicas: 3
  maxReplicas: 30
  metrics:
    - cpuUtilization: 60
    - p95LatencyMs: 300
    - queueDepthPerWorker: 100

예시는 핵심 구조를 단순화한 것입니다. 실무에서는 운영 환경, 장애 상황, 보안 요구사항에 맞게 세부 설정을 조정해야 합니다.

실무에서 주의할 점

• 자동화가 있어도 롤백과 복구 절차를 실제로 연습하지 않으면 장애 때 동작하지 않을 수 있습니다.
• 관찰 지표가 없으면 장애 원인을 추측에 의존하게 됩니다.
• 확장은 애플리케이션 코드, 데이터베이스, 네트워크, 외부 의존성 한계를 함께 봐야 합니다.

함께 연결해서 보면 좋은 키워드

Autoscaling, Metric, HPA, Capacity

면접에서 짚으면 좋은 포인트

• 정상 동작뿐 아니라 장애, 롤백, 관찰 가능성까지 함께 설명하면 실무적인 답변이 됩니다.
• 설정 예시를 말할 때 보안, 비용, 운영 자동화의 trade-off도 함께 짚는 것이 좋습니다.

정리

한 줄로 정리하면, CPU와 메모리뿐 아니라 요청 수, p95 지연 시간, 큐 길이, 처리 지연 같은 워크로드 특화 지표가 더 적합할 수 있습니다. 개념의 정의뿐 아니라 장애 시 동작, 운영 지표, 자동화와 복구 전략까지 함께 이해하는 것이 중요합니다.