StreamHub 확장: 하루 1,450억 이벤트 처리를 위해 Kinesis에서 Kafka로 전환

Atlassian의 StreamHub는 하루 220억 건에서 1,500억 건의 이벤트를 수집하는 규모로 성장하면서, 200~300억 건 수준까지 잘 작동했던 Amazon Kinesis를 넘어 장기 보관 비용/소비자 확장성/멀티클라우드를 위해 AWS MSK 기반 Kafka로 전환함 Kafka의 Tiered Storage로 실시간 데이터는 로컬 디스크에서 처리하고 오래된 데이터는 S3로 이동해 비싼 EBS 과잉 할당을 줄였으며, 대규모 과거 데이터 조회가 실시간 소비자의 IOPS를 잠식하는 문제도 분리함 하지만 하루 1,500억 건 규모에서는 Managed Kafka도 무한히 확장되지 않았으며, broker 네트워크/EBS 한계, S3 요청 폭증, tiered storage offload 지연, 스토리지 확장 cooldown, AZ 장애 시 control plane 의존성 등이 실제 장애 원인이 됨 장애를 겪은 뒤 평균 클러스터 사용률 대신 가장 뜨거운 broker를 기준으로 용량을 계획하고, 네트워크/로컬 디스크를 의도적으로 여유 있게 확보하며 rate limit, Kafka quota, quarantine으로 특정 워크로드가 전체 클러스터를 무너뜨리지 못하게 변경함 대형 클러스터를 여러 shard로 나누고 별도 failover cluster와 규정 준수 가능한 companion region을 마련해, 장애가 난 managed service의 control plane 자체에 의존하지 않고 복구할 수 있는 경로를 구축함 하루 220억 건에서 1,500억 건으로 성장한 StreamHub Atlassian의 클릭, 노출, API 호출, CDC 이벤트, telemetry 대부분이 실시간 데이터 플랫폼인 StreamHub를 통과함 과거 하루 약 220억 건을 처리하던 시스템이 사용자 증가와 새로운 실시간 분석 기능으로 크게 성장함 현재 StreamHub는 하루 1,500억 건 이상을 수집/처리함 하루 2,250억 건 이상을 전달함 평균 초당 약 168만 건을 처리함 최대 트래픽은 초당 320만 건 이상임 이 규모에서는 작은 코드 비효율, 클라우드 서비스의 제한, managed service 내부의 미묘한 결함까지 실제 운영 문제로 드러남 Kinesis에서 Managed Kafka로 전환 Amazon Kinesis는 하루 200~300억 건 규모까지 데이터 수집 계층으로 잘 작동했지만, 약 5배 규모 증가를 앞두고 새로운 ...