How we scaled fast, reliable configuration distribution to thousands of workload containers (새 탭에서 열림)

데이터독(Datadog)은 초당 수백만 개의 로그를 처리하는 대규모 분산 환경에서 사용자가 설정한 로그 파싱 규칙 등 '컨텍스트 데이터'를 수천 개의 컨테이너에 실시간으로 전파해야 하는 과제에 직면해 있습니다. 단순히 데이터베이스를 조회하거나 짧은 주기의 캐시를 사용하는 방식은 대규모 트래픽 환경에서 DB 부하와 지연 시간 문제를 야기하며, 이를 해결하기 위해 데이터독은 안정성과 확장성을 모두 고려한 독자적인 설정 전파 시스템을 구축했습니다.

실시간 설정 전파의 기술적 도전 과제

• 컨텍스트 데이터의 중요성: 로그 파싱 규칙, 민감 데이터 스캐너 설정, 저장 쿼터 등 사용자별(per-tenant) 설정 데이터는 데이터독 서비스가 고객 데이터를 처리하는 방식의 핵심을 이룹니다.
• 낮은 지연 시간 요구: 사용자가 UI에서 설정을 변경하면 '라이브 테일(Live Tail)'과 같은 실시간 서비스에 즉각 반영되어야 하며, 이는 수천 개의 워크로드 컨테이너가 변경 사항을 거의 동시에 인지해야 함을 의미합니다.
• 고도의 신뢰성: 컨텍스트 데이터는 데이터 처리에 필수적이므로, 이 데이터를 공급하는 시스템은 어떤 장애 상황에서도 견고하게 동작해야 하는 '록 솔리드(rock solid)'한 수준의 안정성이 요구됩니다.

단순 접근 방식의 한계

• 온디맨드 조회의 불가능: 로그가 들어올 때마다 DB에서 설정을 읽어오는 방식은 초당 수십만 건의 읽기 요청을 발생시켜 DB가 감당할 수 없는 수준의 부하를 줍니다.
• 로컬 캐싱의 트레이드오프: 각 컨테이너에 데이터를 캐싱하고 일정 시간마다 갱신하는 방식은 DB 부하를 줄일 수 있지만, 캐시 만료 시간만큼 설정 반영이 늦어져 사용자 경험을 저해합니다. 캐시 기간을 늘릴수록 지연은 심해지고, 줄일수록 DB 부하는 급증하는 딜레마가 발생합니다.

V1 아키텍처: Kafka 기반 캐시 무효화

• 작동 원리: 사용자가 설정을 변경하면 DB에 저장된 후 Kafka를 통해 무효화 알림(invalidation message)이 브로드캐스트됩니다. 이를 수신한 모든 워크로드 컨테이너는 해당 테넌트의 데이터만 DB에서 다시 읽어와 캐시를 갱신합니다.
• 장점: 수년간 잘 작동했으며, 평상시 DB 읽기 횟수를 최소화하면서도 설정 변경 시에만 신속하게 업데이트를 수행할 수 있었습니다.
• 확장성 한계: 데이터독의 규모가 커짐에 따라 한 번의 설정 변경이 수천 개의 컨테이너에서 동시에 DB 조회를 일으키는 '천둥 벌거숭이(thundering herd)' 문제를 야기했습니다. 이는 중앙 DB에 막대한 부하를 주며, DB 장애 시 설정 전파가 완전히 중단되는 취약점을 드러냈습니다.

사용자 설정 변경이 실시간으로 반영되어야 하는 대규모 분산 시스템에서는 중앙 집중식 데이터베이스에 직접 의존하는 구조를 탈피해야 합니다. 워크로드 컨테이너가 DB에 직접 접근하여 데이터를 가져오는 대신, 변경 사항을 안정적으로 밀어넣어 주거나 중간에 완충 역할을 하는 계층을 두어 DB 부하를 격리하고 시스템 전체의 복원력을 높이는 설계가 권장됩니다.