클라우드플레어가 DNS 변경 사항을 전 세계 서버에 반영하는 '존 빌더' 파이프라인을 손봐 반영 지연을 절반 가까이 줄이고 메모리 사용량을 85% 낮췄다고 2일 블로그에서 밝혔다. 레코드가 2천만 개를 넘는 대형 존이 늘면서 기존 방식이 한계에 부딪혔다는 설명이다.
존 빌더가 처리하는 이벤트는 2022년 초당 약 250건에서 현재 레코드 변경 약 700건과 기타 이벤트 약 100건으로 늘었다. 문제는 건수보다 일의 종류였다. 존 설정이 바뀌면 어떤 레코드가 영향을 받는지 알 수 없어 존 전체를 다시 만들었고, 이 방식은 존이 클수록 시간과 메모리를 많이 썼다.
클라우드플레어는 이벤트에 바뀐 항목과 이전·새 값을 담도록 하고, 변경 내용을 보고 안전하다고 입증되는 가장 작은 작업을 고르는 계획기를 도입했다. 작업은 리소스만, 리소스와 메타데이터, 최상위 도메인과 메타데이터, 삭제, 전체 재구성의 다섯 종류다. 판단이 모호하면 전체 재구성을 택하고, 레코드 수가 기준을 넘는 존은 전체 재구성 대신 필요한 부분만 다시 만든다.
같은 존에 대한 요청은 하나의 스케줄러가 합치며, 카프카 오프셋은 앞선 메시지가 모두 끝난 뒤에만 넘긴다. 재시작하면 일이 반복될 수는 있어도 변경이 사라지지는 않는다. 실행 전에는 복제 데이터베이스의 최신 상태를 다시 확인한다.
결과를 보면 24시간 동안 빌드의 92.95%가 전체 재구성을 피했다. 전체 빌드 비중은 약 11.88%에서 7.04%로 줄었다. 평균 메모리는 49GiB에서 7GiB로, 최대치는 79GiB에서 12GiB로 내려갔다. 가장 큰 p99 지연 급증은 14.6분에서 1.21분으로 약 12배 줄었고, 중앙값 지연은 약 7.7초에서 3.3초로 줄었다.
검증도 거쳤다. 타깃 빌드와 전체 빌드의 결과를 바이트 단위로 비교하는 동등성 테스트를 했고, 실제 트래픽을 받는 미러 빌더를 운영 환경과 비교한 결과 일치하지 않은 비율은 23만 4,313개 존 중 0.31%였으며 대부분 시점 차이였다. 배포는 존 이름 해시 기준으로 단계적으로 진행했다.
원문: Cloudflare Blog
이 글은 원문에 담긴 사실을 바탕으로 Raon Community가 새로 작성한 기사입니다. 원문의 저작권은 원저작자에게 있으며, 자세한 내용은 원문에서 확인해 주세요.