애틀라시안의 실시간 데이터 플랫폼 스트림허브(StreamHub)가 하루 220억 건에서 1,500억 건 이상의 이벤트를 처리하는 거대 시스템으로 성장하면서, 데이터 처리 아키텍처에 대대적인 변화를 줬습니다. 기존에 사용하던 아마존 키네시스(Amazon Kinesis)가 하루 200~300억 건 규모까지는 잘 작동했지만, 약 5배에 달하는 트래픽 증가를 앞두고 장기 보관 비용 효율성, 소비자 확장성, 멀티클라우드 지원을 위해 AWS MSK(Managed Streaming for Apache Kafka) 기반의 아파치 카프카(Apache Kafka)로 전환했습니다.
카프카 전환의 핵심은 티어드 스토리지(Tiered Storage) 도입이었습니다. 이는 실시간 데이터는 브로커(broker)의 로컬 디스크에 저장하고, 오래된 데이터는 아마존 S3로 비동기 복사하여 보관하는 방식입니다. 이를 통해 고성능 EBS에 데이터를 장기간 보관하는 비용을 크게 줄이고, 대규모 과거 데이터 조회가 실시간 소비자(consumer)의 IOPS(초당 입출력 연산)를 잠식하는 문제를 분리할 수 있었습니다. 하지만 하루 1,500억 건 규모의 트래픽에서는 매니지드 카프카도 무한히 확장되지 않았으며, 브로커 네트워크와 EBS의 한계, S3 요청 폭증, 티어드 스토리지 오프로드(offload) 지연, 스토리지 확장 쿨다운(cooldown), 가용 영역(AZ) 장애 시 컨트롤 플레인(control plane) 의존성 등 예상치 못한 운영 문제가 발생했습니다.
애틀라시안은 이러한 장애를 겪은 후 시스템 운영 전략을 재정비했습니다. 클러스터 평균 사용률 대신 가장 트래픽이 많은 브로커를 기준으로 용량을 계획하고, 네트워크와 로컬 디스크를 의도적으로 여유 있게 확보하는 '과잉 프로비저닝(over-provisioning)'을 도입했습니다. 또한, 레이트 리밋(rate limit), 카프카 쿼터(quota), 격리(quarantine) 기능을 활용해 특정 워크로드(workload)가 전체 클러스터를 마비시키지 않도록 방지했습니다. 대형 클러스터를 여러 샤드(shard)로 나누고 별도의 장애 조치(failover) 클러스터와 규정 준수(compliance)를 위한 보조 리전(companion region)을 마련하여, 매니지드 서비스의 컨트롤 플레인 자체에 의존하지 않고도 복구할 수 있는 경로를 구축했습니다. 이는 매니지드 서비스가 제공하는 편리함에도 불구하고, 대규모 미션 크리티컬 시스템에서는 여전히 세심한 설계와 운영 전략이 필요함을 보여주는 사례입니다.