클라우드플레어, DNS 빌드 속도 2배 단축하고 메모리 85% 절감
원제 We halved DNS build delay and cut memory use by 85%
110 포인트댓글 32

Key Point
DNS 변경이 전 세계 엣지 서버에 도달하는 속도가 반으로 줄었고 메모리 사용량이 극적으로 감소했으므로, 대규모 존 운영 환경에서의 성능 개선 사례를 알아야 한다.
핵심 요약
- 클라우드플레어의 Zone Builder는 초당 700개의 DNS 변경과 100개의 다른 이벤트를 처리하며, 2,000만 개 이상의 레코드를 가진 대규모 존도 지원해야 한다.
- 기존 방식은 단일 레코드 변경 시에도 전체 존을 메모리에 로드해 비교·변환하는 풀 빌드를 수행해 메모리와 시간을 낭비했다.
- 타겟 빌드 플래너를 구현해 어떤 변경이 발생했는지 파악하고, 변경 영역에만 필요한 5가지 빌드 유형 중 하나를 선택한다: 리소스만, 리소스+메타데이터, 정점+메타데이터, 삭제, 풀 존.
- 한 도메인에 여러 클라우드플레어 존이 있을 때 공유 메타데이터 키를 관리하는 로직을 추가해 안전하게 타겟 빌드를 실행한다.
- 이벤트 발생 시 보수적 계획을 세우고, 실행 직전 데이터베이스를 다시 읽어 풀 빌드가 필요한지 재검증한다.
- 통합 스케줄러로 같은 존의 이벤트들을 결합하되, Kafka 메시지 손실을 방지하기 위해 완료 상태를 메모리에서 추적하고 커밋은 순서대로 진행한다.
- 프로덕션 환경과 동일한 미러 환경에서 20% 샘플 존을 비교해 타겟 빌드가 풀 빌드와 동일한 DNS 데이터를 생성함을 검증했다.
- 24시간 측정 결과 92.95%의 빌드가 풀 존 재구성을 피했으며, 풀 빌드는 40% 감소했다.
- p99 빌드 완료 지연은 14.6분에서 1.21분으로 12배 단축되었고, 워킹셋 메모리는 평균 49GB에서 7GB로 85% 감소했다.
- 스케줄러 최적화 후 재구성 간격을 단축하고 Kafka Aggregator 대기 시간을 줄여 중앙값 완료 지연을 7.7초에서 3.3초로 반으로 단축했다.
- Kafka 생산 속도(초당 600~800개)와 소비 속도가 일치하게 되어 피크 1,550개/초의 폭발적 처리 필요가 없어졌다.
- 처음 발행되는 존이나 모든 레코드에 영향을 미치는 변경 등 일부 경우 풀 빌드가 여전히 필요하지만, 이들은 대부분 새로운 소규모 존에만 영향을 준다.