Kafka Streams를 k8s로 옮기며 얻은 스케일링 설계: 비용 80% 절감까지

안녕하세요. 기술본부 데이터엔지니어링셀 김태완입니다. 이 글에서는 AWS EC2 기반으로 운영되던 Log Transformer(Kafka Streams 애플리케이션)를 Kubernetes(이하 k8s)로 마이그레이션하면서, Kafka consumer 워크로드에 맞는 스케일링 정책을 설계한 과정과 그 결과를 공유합니다. 이 글에서 다루는 내용은 다음과 같습니다. CPU 기반 HPA가 Kafka consumer 워크로드에 부적합한 이유 KEDA와 consumer lag을 활용한 도메인 메트릭 기반 스케일링 설계 자정 트래픽 급증에 cron trigger로 선제 대응하는 방법 pod당 thread 다중화로 JVM 오버헤드와 rebalance 이벤트를 줄이는 방법 그 결과로 얻은 EC2 대비 80% 이상의 인프라 비용 절감 #배경: EC2 기반 Log Transformer의 한계 Log Transformer는 여러 Kafka topic에서 원본 로그를 읽어 검증·변환한 뒤, 게임별 Kafka topic으로 다시 produce하는 Kafka Streams 애플리케이션입니다. 여러 source topic의 원본 로그를 게임·용도별 topic으로 분기시키므로, 후속 파이프라인은 필요한 topic만 골라 소비할 수 있습니다. 기존에는 c6g.2xlarge 인스턴스 72대 위에서 운영되고 있었으며, 다음과 같은 한계를 안고 있었습니다. 트래픽 패턴과 어긋나는 인스턴스 운영: ASG(Auto Scaling Group)에 cron 기반 스케줄을 걸어 시간대별로 인스턴스 수를 조정하고 있었지만, 미리 정해둔 일정에 따라 일괄적으로 인스턴스 수를 늘리고 줄이는 방식이라 실제 트래픽 변화에 즉각 반응하기는 어려웠습니다. 스케일링의 경직성: 예상치 못한 트래픽 변화에는 수동으로 ASG 설정을 바꾸거나 cron 스케줄을 다시 손봐야 했습니다. 배포 파이프라인의 복잡성: Spinnaker 기반 EC2 배포는 단계가 많고 반영까지 오래 걸려 단순한 설정 변경에도 부담이 컸습니다. 이 한계들은 결국 트래픽에 실시간으로 반응하는 자동 스케일링과 빠르고 단순한 배포가 없다는 데서 비롯됐습니다. k8s는 HPA, KEDA 같은 오토스케일러로 트래픽 변화에 자동으로 반응할 수 있고, 선언형 매니페스트와 GitOps 배포로 설정 변경 부담도 줄일 수 있습니다. 그래서 저희는 Log Transformer를 k8s 기반으로 전환하기로 결정했습니다. 마이그레...