지난 4년간 6번의 무진장 행사를 통해 성장한 DevOps 이야기 | 인프콘2024

예상 트래픽을 받기 위해 AWS에 사전 워밍을 요청하고 애플리케이션 인스턴스, 데이터베이스, ElastiCache, MSK를 서비스별로 스케일 업·아웃했다. 수백 대의 인스턴스와 블루그린 배포가 겹치면 서브넷 IP가 부족할 수 있고, 데이터베이스 연결 풀과 PHP FPM·JVM 힙 설정도 함께 조정해야 한다. 최대치만 보고 과도하게 늘리면 큰 비용이 남으므로 각 병목과 운영 제약을 반영한 용량 계획이 필요하다.

행사 트래픽은 늘었지만 중요하지 않으면서 비용이 큰 기능을 기능 플래그로 끄고 플랫폼과 애플리케이션을 개선해 실제 사용 자원은 오히려 줄였다. 다만 예상치에 고정 비율의 안전 여유를 더하면 첫날 관측 후에도 약 30%의 유휴 자원이 남는 문제가 생긴다. 첫날의 실제 부하로 이후 계획을 보정하면서도 돌발 증가를 견딜 여유를 얼마나 남길지가 아직 풀어야 할 과제다.

장애가 발생하면 채널 생성과 상태 전파를 자동화해 엔지니어가 반복 공지 대신 원인 파악과 복구에 집중하도록 했다. 사고 지휘관은 제한된 정보로 빠르게 우선순위를 결정하고, 커뮤니케이션 담당은 이해관계자에게 상황을 공유하며, 운영 담당은 실제 조치를 조율한다. 정기 훈련으로 역할과 절차를 몸에 익힌 SRE 팀은 큰 행사에서도 당황하지 않고 일관된 방식으로 대응할 수 있었다.

데이터베이스 장애를 줄이려면 스키마·쿼리·캐시를 함께 개선해야 하고, CPU가 오르지 않는 병목에서는 CPU 기반 오토스케일링만으로 대응할 수 없다. K6 Operator로 부하 테스트를 실행하고 Datadog 지표에 임계값을 두어 계획한 용량이 실제 부하를 견디는지 검증했다. 앞으로 약 300개 서비스의 계획과 검증을 자동화하고 개발자가 직접 스케일링 일정을 관리하는 셀프서비스 체계를 만드는 것이 목표다.