[kt cloud TECH UP] 티켓팅 서버, 오토스케일링(HPA)만 믿으면 망하는 이유

kt cloud TECH UP 실무 통합 프로젝트 멘토링 회고 3편입니다. 이번에는 클라우드 인프라(Infra) 관점에서 경험하게 된 오토스케일링(Auto-Scaling) 트러블슈팅에 대해 이야기해 보겠습니다.)

1. 주니어의 완벽한(?) 인프라 계획

마라톤 티켓팅 플랫폼 아키텍처를 설계하며, 인프라 담당 팀원과 백엔드 팀은 클라우드의 꽃이라 불리는 Kubernetes(K8s) 환경 위에서 완벽한 대응 방안을 마련했다고 자부했습니다.

우리의 계획:

평소에는 리소스 낭비를 막기 위해 최소한의 Pod(컨테이너)만 띄워둡니다.
티켓팅 오픈 시간(예: 오전 10시 정각)에 트래픽이 몰려 CPU 사용량이 70%를 넘어가면?
**HPA(Horizontal Pod Autoscaler)**가 이를 감지하고 자동으로 Pod 개수를 2개, 4개, 10개로 팍팍 늘려줄 것이다! 우리는 클라우드 네이티브의 혜택을 온전히 누릴 것이다!

이론상으로는 완벽한(Textbook) 설계였습니다. 하지만 kt cloud 인프라 멘토님의 소견은 우리의 계획을 정면으로 반박했습니다.

2. 멘토님의 긴급 진단: "Flash Crowd를 얕보지 마세요"

우리의 당찬 스케일링 계획을 들은 멘토님은 가볍게 한숨을 쉬시며 실무의 참혹한 현실을 알려주셨습니다.

멘토님 (kt cloud 클라우드 팀): "쇼핑몰 세일이나 티켓팅 같은 이벤트는 트래픽이 서서히 증가하는 것이 아닙니다. 1초 만에 0에서 15,000으로 수직 상승하는 Flash Crowd(순간 폭증 트래픽) 현상입니다.

HPA가 CPU 부하를 감지하고(수집 딜레이), 새로운 Pod를 띄울 것을 명령하고, 도커 이미지를 받아오고, Spring Boot 애플리케이션이 뜨고 정상 작동(Ready)하기까지 빠르면 수십 초에서 수 분이 걸립니다.

서버가 늘어나는 그 수십 초 동안, 이미 기존에 떠 있던 불쌍한 최소한의 Pod들은 15,000개의 트래픽을 온몸으로 맞고 OutOfMemory(OOM)로 전부 터져(Crash)버립니다. 오토스케일링은 뻗어버린 서버 뒤에서 뒷북만 치게 되는 거죠."

이 설명을 듣고, 우리는 클라우드의 자동화 기능에 주로 신경 쓰느라 시스템의 물리적인 **구동 지연 시간(Cold Start/Warm-up)**을 간과하고 있었음을 깨달았습니다.

3. 실무의 정석: Pre-Provisioning (인프라 예열)

멘토님은 실제 대형 이벤트(명절 KTX 예매, 대기업 공채 접수 등)를 담당하는 인프라 팀의 진짜 비기를 알려주셨습니다. 바로 '예열(Pre-Provisioning)'입니다.

이벤트 오픈 전: 오토스케일링에 의존하지 않습니다. 엔지니어가 이벤트 수 시간 전(혹은 전날 밤)에 수동으로 혹은 스크립트를 통해 Pod 개수를 **예상되는 최대 트래픽(Peak)을 감당할 수 있는 수치(Max Replicas)**로 넉넉하게 강제 고정해 둡니다.
이벤트 진행 중: 최고 성능으로 부스팅 된 서버 군단이 몰려오는 트래픽 폭풍을 평온하게 받아냅니다. 이때 오토스케일링은 혹시 모를 예상치 못한 추가 폭주에 대비하는 '최후의 백업' 용도로만 작동하게 둡니다.
이벤트 종료 후: 트래픽이 썰물처럼 빠져나가면, 그때 다시 서버 개수를 최소 단위로 축소(Scale-in)하여 비용을 절감합니다.

요컨대, 티켓팅 서버에서 오토스케일링은 '총알받이'가 아니라 '안전벨트'로 취급해야 한다는 것입니다.

4. 클라우드를 '아는 것'과 '써보는 것'의 차이

책과 강의에서 "트래픽이 늘어나면 자동으로 늘어나는 마법"이라고 배웠던 오토스케일링. 하지만 현업에서는 그 자동화 이면에 숨겨진 지연율(Latency) 하나 때문에 수만 명의 고객이 접속 장애 화면을 보게 될 수도 있다는 뼈저린 교훈을 얻었습니다.

클라우드 네이티브 기술을 잘 쓴다는 것은 단순히 K8s 설정 파일을 적용할 줄 아는 것이 아니라, 서비스의 트래픽 특성(점진적 증가 vs 순간 폭증)을 정확히 이해하고 그에 맞춰 기술의 한계를 통제하는 것임을 깨달았습니다.

다음 목표는 프론트엔드와 백엔드의 치열한 인증 아키텍처 토론, **"Next.js와 Spring Boot, 누구에게 인증(Auth)의 책임을 맡길 것인가?"**에 대한 이야기입니다.