"인프라가 멈추면 범인은 늘 DNS"라는 농담은 운영 현장에서 거의 격언에 가깝다. 클라우드·서버 하드웨어 업체 Oxide의 엔지니어 데이브 파체코는 자사 제어 평면(control plane)의 DNS 전파 시스템을 만든 경험을 통해, 이 문제를 바라보는 조금 다른 관점을 제시한다. 핵심은 '어떻게 하면 DNS가 고장 나지 않게 할까'가 아니라 '고장 났을 때 어디가 왜 깨졌는지를 몇 초 만에 알 수 있게 만들려면 어떻게 설계해야 하는가'이다. 그는 이를 '디버깅을 위한 개발(developing for debugging)'이라고 부른다.
두 개의 DNS와 비동기 전파 구조
Oxide 시스템은 동일한 스택을 두 벌 배포해 두 종류의 DNS를 운영한다. 하나는 고객에게 노출되어 외부 API와 웹 콘솔의 위치를 알려주는 외부 DNS, 다른 하나는 시스템 내부 네트워크에서만 동작하며 제어 평면 구성 요소 간 서비스 디스커버리를 담당하는 내부 DNS다. DNS 데이터의 진실의 원천(source of truth)은 제어 평면 데이터베이스로, 강한 일관성을 보장하는 분산 데이터베이스인 CockroachDB가 쓰인다.
제어 평면의 중심에는 Nexus라는 구성 요소가 있다. 서비스를 제공하던 컴포넌트가 추가·제거되는 등 DNS 변경이 필요한 사건이 생기면, Nexus는 먼저 데이터베이스의 DNS 설정을 갱신한다. 그 뒤 Nexus 내부의 여러 백그라운드 작업이 갱신된 설정을 운영 중인 모든 DNS 서버로 전파한다. 이 작업들은 변경 이벤트에 반응해 실행될 뿐 아니라, 일시적 실패나 누락된 깨우기 신호에 대비해 주기적으로도 실행된다. 전체 흐름은 트리거 이벤트와 비동기적으로 진행되지만, 정상적인 시스템에서는 대개 몇 초 안에 완료된다.
고장 날 수 있는 모든 지점을 미리 헤아리다
파체코가 강조하는 출발점은 질문의 전환이다. 고객이 '있어야 할 DNS 이름이 조회되지 않는다'고 신고했다고 가정하자. 무엇이 잘못됐을 수 있는가. 데이터베이스의 DNS 데이터 자체가 틀렸을 수도 있고, 전파 과정이 깨졌을 수도 있다. 전파 과정 안에서도 Nexus가 데이터 변경을 감지하지 못했거나, DNS 서버 목록이 잘못되어(예컨대 새로 추가된 서버가 전파 대상에 포함되지 않아) 일부 서버로 전달되지 못했거나, 전파 자체가 실패했을 수 있다. 끝으로 DNS 서버가 자신이 받은 설정과 다른 데이터를 서빙하고 있을 가능성도 있다.
이처럼 실패 가능 지점을 먼저 나열하고 나면, 필요한 도구의 모습이 자연스럽게 드러난다. DNS 설정에 어떤 이름들이 포함돼 있는지, 언제·어느 Nexus가·왜 마지막으로 갱신했는지, 각 Nexus 인스턴스가 마지막 전파 시도에서 어떤 버전을 어떤 서버들에 보내려 했고 그 서버 목록을 언제 파악했는지, 그리고 각 DNS 서버가 실제로 어느 버전의 데이터로 동작 중인지를 한눈에 보여주는 도구다. 이 구체적 요구가 바로 Omicron 디버거, 줄여서 omdb를 만든 계기가 됐다. Omicron은 Oxide 제어 평면의 내부 명칭이며, 'DNS 디버거'가 아니라 'Omicron 디버거'로 이름 붙인 것은 런타임 관측이 필요한 서브시스템이 DNS 하나로 끝나지 않으리라 봤기 때문이다.
추상화에 투자하면 관측은 거의 공짜가 된다
주목할 점은 이 관측성이 거창한 별도 구축물이 아니라는 것이다. DNS 전파는 '백그라운드 작업'이라는 새 추상화 위에 구현됐는데, 이 추상화에는 기본적인 관측 기능이 처음부터 내장돼 있다. 백그라운드 작업은 특정 이벤트에 반응해 호출(활성화)될 수 있고, 항상 일정 주기로도 활성화되며, 전체 집합이 정적으로 정의되고, 임의의 상태 페이로드(현재는 스키마 없는 JSON 객체)를 반환할 수 있는 비동기 Rust 함수에 가깝다. 이런 공통 토대 덕분에 omdb는 DNS 전파의 내부를 깊이 알지 못해도 유용한 요약 보고서를 생성할 수 있다. 추상화에 한 번 투자해 두니, 전파 로직을 조각내 상태 보고를 얻어내는 데 드는 추가 작업은 매우 적었다는 것이 저자의 설명이다.
여기서 파체코가 던지는 더 날카로운 통찰은 보고의 '질'에 관한 것이다. 많은 시스템은 "문제 0건", "최신 상태" 같은 메시지를 출력한다. 그러나 '문제 0건'은 '이 프로그램이 아는 문제가 0건'일 뿐이고, '최신 상태'라는 말은 화면에 뜨는 순간 이미 틀렸을 수 있을 만큼 모호하다. 반면 omdb는 긍정적이고 검증 가능한 증거를 내놓는다. 예컨대 "특정 시각에 발견한 DNS 버전 18을, 같은 시각에 파악한 세 대의 DNS 서버에 전파했고, 모든 전파가 조금 뒤 특정 시각까지 완료됐다"고 보고한다. 이 정도 정보면 대개 'DNS는 범인이 아니다'라고 바로 가려낼 수 있고, 설령 다른 원인이라도 사건의 타임라인을 재구성하는 실마리가 된다. 사용자가 전파가 끝나기 전에 조회한 것은 아닌지 같은 가설도 세울 수 있다.
디버깅 도구가 바꾸는 개발과 운영의 결
이렇게 만든 도구의 �임새는 장애 대응에 그치지 않는다. 자동화 테스트를 작성하기 전에 omdb로 시스템을 조작하며 동작을 확인할 수 있고(이른바 디버거 주도 개발), 기존 시스템에서 일부 DNS 서버를 내렸을 때 무슨 일이 벌어지는지 관찰하며 거동을 이해할 수도 있다. 나아가 신규 구성원 온보딩이나 변경 사항 공유의 매개가 되기도 한다. DNS 변경이 '전파됐다'는 사실뿐 아니라 '어떻게' 전파됐고 고장 났을 때 무엇이 보이는지까지, 10분짜리 심층 데모로 설명할 수 있기 때문이다. 저자의 표현을 빌리면 이 수준의 데모 한 번은 다이어그램 천 장의 가치가 있다.
파체코는 이런 방식이 팀 전체로 확산될 때 지원 통화를 다루는 정서적 분위기 자체가 달라진다고 말한다. 많은 이들이 디버깅을 고통스러운 방해로 여기고, 고객이 수정을 기다리는 압박 속에서는 더 큰 스트레스를 받는다. 그 스트레스의 상당 부분은 공포와 불확실성에서 온다. 원인을 빠르게, 그리고 확신을 가지고 짚어낼 수 있는 도구가 갖춰지면 고객이 겪는 고통이 가벼워지지는 않더라도 대응하는 사람의 두려움은 크게 줄어든다. 다만 저자 스스로 밝히듯, 이런 방식으로 만든 소프트웨어가 런타임 문제를 덜 일으킨다는 느낌은 개발 과정에서 자연스럽게 실패 지점을 떠올리게 되기 때문이라는 직관일 뿐 뒷받침할 데이터는 없다. 또한 이 사례는 강한 일관성 데이터베이스와 정적으로 정의된 백그라운드 작업이라는 특정 아키텍처 위에서 성립한 이야기이므로, 다른 환경에서는 동일한 추상화를 먼저 마련하는 선행 투자가 전제된다는 점도 함께 읽어야 할 한계다.