트래픽이 증가하면 자동으로 확장된다.
이 문장만 보면 Kubernetes 오토스케일링은 완벽한 해결책처럼 보인다.
CPU 사용률이 일정 기준을 넘으면 Pod가 늘어나고, 트래픽이 줄어들면 다시 축소된다. 인프라는 유연해지고 비용은 최적화된다. 이론적으로는 이상적인 구조다.
하지만 실제 운영 환경에서는 오토스케일링이 오히려 장애를 증폭시키는 순간이 있다.
오토스케일링은 “지표”에 반응할 뿐이다
Kubernetes의 HPA(Horizontal Pod Autoscaler)는 기본적으로 메트릭 기반으로 동작한다. CPU 사용률이나 메모리 사용량이 설정한 임계값을 넘으면 Pod 수를 늘린다.
문제는 이 지표가 항상 서비스의 실제 상태를 정확히 반영하지 않는다는 점이다.
예를 들어, 외부 API 지연으로 응답 속도가 느려졌다고 가정해보자. 요청은 쌓이고 CPU 사용률이 증가한다. HPA는 이를 트래픽 증가로 인식하고 Pod를 늘린다. 하지만 병목은 외부 API에 있다. Pod를 아무리 늘려도 문제는 해결되지 않는다.
결과적으로 리소스는 급격히 증가하고, 클러스터 전체에 부하가 전이될 수 있다.
오토스케일링은 원인을 이해하지 않는다. 단지 숫자에 반응할 뿐이다.
확장은 또 다른 병목을 만든다
Pod가 늘어나면 모든 것이 자동으로 해결될 것 같지만, 실제로는 그렇지 않다.
데이터베이스 연결 수는 그대로인데 애플리케이션 인스턴스만 늘어나면 커넥션 풀이 고갈될 수 있다. 캐시 서버의 처리 한계를 넘어서면 응답 지연이 발생한다. 네트워크 대역폭도 무한하지 않다.
즉, 애플리케이션 레이어만 확장하면 하위 레이어에서 새로운 병목이 생길 수 있다.
특히 상태 저장 애플리케이션이나 세션 기반 구조에서는 확장이 더 복잡하다. 세션 공유, 데이터 일관성, 동기화 비용이 추가되면서 확장이 오히려 시스템 안정성을 떨어뜨릴 수 있다.
오토스케일링은 인프라를 늘려주지만, 아키텍처의 한계를 해결해주지는 않는다.
스케일링보다 중요한 것은 안정성 설계다
진짜 문제는 스케일링이 아니라 안정성 설계다.
오토스케일링은 부하를 흡수하는 도구일 뿐, 근본적인 병목을 제거하는 수단이 아니다. 서킷 브레이커, 백프레셔, 적절한 타임아웃 설정 같은 보호 장치가 없다면 트래픽 급증 상황에서 시스템은 연쇄적으로 무너질 수 있다.
또한 스케일 아웃 속도와 스케일 인 속도를 신중하게 조정해야 한다. 너무 빠른 확장은 리소스 낭비와 비용 폭증을 초래하고, 너무 느린 축소는 불필요한 자원 점유를 만든다.
오토스케일링은 자동이지만, 전략 없이 맡겨둘 수는 없다.
결국 중요한 질문은 이것이다.
우리는 단순히 늘릴 준비가 되어 있는가, 아니면 버틸 준비가 되어 있는가.
확장은 쉬워 보이지만, 안정성은 설계에서 시작된다.