2023년 3월 8일 Datadog의 글로벌 장애 당시 인시던트 대응을 시간대별로 되짚고, 절차와 커뮤니케이션, 확장 전략, 그리고 배운 점을 공유합니다.
Laura de Vesine
3월에 Datadog은 글로벌 장애를 겪었습니다. 전례가 없는 규모였고, 수백 명의 엔지니어가 교대로 참여해 대응했으며, 그와 동시에 수많은 화상 회의, 채팅, 워크스트림, 고객 대응이 진행되었습니다. 며칠 만에 수백 페이지에 달하는 내부 심층 분석과 애프터 액션 리포트를 정리했습니다.
여러분 중 많은 분들과 마찬가지로, 대규모 복잡한 시스템의 관리자로서 우리는 언젠가 큰 장애가 발생할 것이라는 현실적인 기대와 함께 살아왔습니다. 그것은 ‘만약(if)’이 아니라 ‘언제(when)’의 문제였습니다. 우리는 이를 대비하기 위해 최선을 다했고, 재난에 정면으로 맞설 수 있도록 인시던트 대응을 꾸준히 개선해 왔습니다. 2023년 3월 8일, 그 날이 왔고 우리는 시험대에 올랐습니다.
이 글은 평소 우리의 인시던트 대응이 어떻게 이루어지는지, 3월 8일에 무엇이 잘 되었고 어디서 비틀거렸는지, 그리고 그 과정에서 무엇을 배웠는지를 설명합니다.
Datadog은 “you build it, you own it” 모델로 운영과 인시던트를 관리하며, 대규모 플랫폼이 요구하는 업계 표준 관행을 따릅니다. 고객 경험에 직접적인 영향을 주지 않는 시스템이라도 모두 계측되어 다양한 원격 측정 데이터를 팀에 제공합니다. 팀은 자신들이 구축·운영하는 서비스에서 24/7 데이터를 추적하도록 모니터를 구성하며, 문제가 발생하면 알림을 받게 됩니다. 대부분의 엔지니어링 팀은 몇 분 내로 이러한 알림에 대응할 수 있어야 합니다.
자사 Datadog 기반 모니터링 외에도, 우리 인프라와 완전히 분리되어 동작하는 기본적인 아웃오브밴드 모니터링을 보유하고 있습니다. 이 모니터링은 플랫폼의 내부 구조를 전혀 가정하지 않고, 사용자와 똑같이 우리의 API를 소비합니다. 이것이 우리가 모니터를 모니터링하는 방식이며, 플랫폼이 크게 가용하지 않게 되는 드문 상황(3월 8일처럼)에도 알림을 받을 수 있도록 보장합니다.
우리는 엔지니어링 전반에서 진행 중인 인시던트에 대한 상황 인식을 지원하기 위해 Slack을 사용합니다. Datadog 인시던트 앱은 각 인시던트를 조정하기 위한 Slack 채널을 자동으로 생성합니다. 모든 인시던트는 언제든 쉽게 볼 수 있으며, 직접 호출을 받지 않았더라도 도움이 될 수 있는 엔지니어가 참여하도록 권장합니다.
팀별 온콜 로테이션 외에도, 고객 영향이 크거나 다수 팀의 관여가 필요한 고심각도 인시던트를 위해 숙련된 시니어 엔지니어들의 온콜 로테이션을 운영합니다. 이 로테이션 구성원 중 한 명이 페이지를 받으면 인시던트에 참여해 인시던트 커맨더 역할을 맡습니다.
인시던트 커맨더는 내부 대응자 간 커뮤니케이션과 상태 업데이트를 직접 관리하거나, 종종 고심각도 인시던트 로테이션의 세컨더리 온콜에게 그 역할을 위임할 수 있습니다(도표의 ‘커뮤니케이션 리드’). 가장 높은 심각도의 인시던트에서는 엔지니어링 임원과 고객 지원팀의 매니저(도표의 ‘고객 담당’)도 호출해 고객 대상 커뮤니케이션을 작성·조율하고 필요한 비즈니스 맥락을 제공합니다. 인시던트 커맨더는 인시던트 전반 대응에 대한 책임을 계속 집니다.
우리(와 고객) 모두 가용성에 대한 기대가 높기 때문에, 인시던트를 선언하는 임계값을 비교적 낮게 설정합니다. 그 결과로 우리는 정기적으로 인시던트 관리 프로세스를 경험하며, 이는 엔지니어들이 도구와 인시던트 대응에 대해 최신 상태를 유지하는 데 도움이 됩니다. 또한 모든 엔지니어가 온콜에 들어가기 전에 포괄적인 교육을 이수하고, 6개월마다 리프레셔 교육을 받도록 요구합니다. 이 교육은 온콜의 기대 사항, 인시던트 대응 프로세스와 팀의 구조, 비난 없는(blameless) 철저한 인시던트 조사 및 시정 조치에 대한 기대를 다룹니다.
또한 재발 방지를 위해 시스템을 강화하고 개선하는 모범 관행을 따릅니다. 이는 각 장애(특히 큰 장애일수록)가 고유하고 전례 없다는 뜻이며, 성공적인 대응에는 유연성과 창의성이 핵심 요소가 됩니다. 모든 고심각도 인시던트에 대해 엔지니어들은 앞으로 동일(또는 유사) 인시던트를 방지할 방법을 탐구하는 상세한 포스트모템을 작성합니다. 자동화는 인시던트에 관여한 엔지니어들에게 인시던트가 아직 기억에 생생할 때 초안을 작성하도록 상기시키며, 필요한 지원이 있으면 언제든 도움을 요청하도록 권합니다.
대부분의 대규모 시스템과 마찬가지로, 우리는 기능 추가와 스케일 확대로 인해 시스템이 끊임없이 변화합니다. 그 결과 사전에 만들어 둔 복구 절차를 최신 상태로 유지하는 것은 사실상 불가능합니다. 세부적이고(본질적으로 경직된) 절차를 구현하는 대신, 엔지니어가 자신이 잘 아는 서비스에 대해 최선의 경로를 판단할 수 있도록 권한을 부여합니다. 애자일 관점에서 이는 ‘프로세스보다 사람’에 방점을 찍는 것이며, 궁극적으로 우리의 오너십 철학을 실천하는 데 도움이 됩니다.
우리는 비난 없는 인시던트 문화를 소중히 여기며, 이는 엔지니어가 인시던트 대응 시 창의적인 해결책을 찾을 수 있도록 힘을 실어줍니다. 복잡한 시스템이 실패할 때 그것은 개인이 실수했기 때문이 아니라, 시스템 자체가 실패를 방지하지 못했기 때문임을 알고 있습니다. 이는 개인 엔지니어가 인시던트에 대해 비난받지 않는 것에서부터, 심각한 장애 대응 시 임원들이 지원과 격려를 제공하는 것에 이르기까지 모든 수준에서 드러납니다. 비난 없음은 고심각도 인시던트처럼 스트레스가 큰 상황에서 특히 중요합니다.
인시던트의 초기 몇 분, 몇 시간은 매우 중요합니다. 이 소중한 시간은 이후 대응의 많은 부분—무엇이 일어났다고 생각하는지, 어디서 트리거를 찾아야 할지, 대외적으로 처음 어떤 메시지를 전해야 할지, 더 많은 사람들이 합류해 트러블슈팅할 때 그룹의 분위기까지—을 좌우합니다. 그래서 우리는 인시던트의 시작에 주의를 기울이고 마찰을 최대한 제거하려고 노력합니다. 3월 8일의 타임라인은 다음과 같습니다.
2023년 3월 8일 06:08 UTC경(첫 대응 팀의 현지 시간으로 새벽 1시 8분경), 두 개의 엔지니어링 팀이 이 인시던트로 페이지를 받았습니다.
첫 번째 팀은 당시 컴퓨트 인프라 문제에 대한 대규모 인시던트가 선언되지 않았기 때문에, 문제가 자신들의 서비스에 국한된 것이라고 가정했습니다.
한편 두 번째 팀은 우리의 여러 제품에 걸쳐 중대한 문제가 있음을 빠르게 판단하고 고심각도 인시던트를 호출했습니다. 다만 인시던트 관리 도구가 인시던트 관련 간헐적 실패를 겪으면서 방해를 받았습니다. 그 결과, 고심각도 인시던트를 진단한 뒤 오픈하는 데 약 10분(평소보다 길었습니다)이 걸렸습니다.1
고심각도 인시던트 온콜 대응자가 접속해 이것이 극도로 심각한 인시던트임을 재빨리 진단했습니다. 그는 인시던트 커맨더 역할을 맡고 즉시 다음을 수행했습니다.
이 시점에서 인시던트 커맨더의 최우선 과제는 고객에게 상태를 알리는 것과 시스템 실패의 진단 및 완화 조치를 이끄는 것이었습니다.
복잡한 시스템의 실패에서는 먼저 커뮤니케이션을 해야 할지, 먼저 진단과 완화를 해야 할지 결정하기 어렵습니다. “시스템이 다운됐다” 이상의 내용을 전하려면 초기 진단과 조기 해결 경로가 필요합니다. 반대로 시의적절하고 의미 있는 업데이트가 부족하면 고객은 자체 대응을 계획할 수 없어 답답합니다. 수년간의 경험으로, 30분 업데이트 주기가 합리적인 균형이며, 대응팀이 진단·완화·시정 조치에 집중할 시간을 준다는 것을 알게 되었습니다.
초기에 인시던트 커맨더는 가능한 한 빨리 고객에게 알리기 위해 상태 페이지를 올릴 필요가 있음을 명확히 인지했습니다. 그러나 정확한 상태 페이지 공지를 신속히 게시하는 데에는 도전 과제가 있었습니다. 지역별로 영향이 달랐기 때문입니다. 일부 리전은 웹페이지 로딩 문제가 있었고 다른 리전은 그렇지 않았기 때문에, 고객과 가능한 빨리 소통하기 위해 “최악의 동작” 메시지(로딩 이슈를 가장 두드러진 증상으로 지목하는 메시지)를 선택했습니다.
진단과 완화도 이례적으로 까다로웠습니다. Datadog의 각 리전은 여러 클라우드 제공업체에 걸친 완전히 격리된 소프트웨어 스택입니다. 초기 수 분 동안, 클라우드 제공업체별 상이한 동작을 분리해 정확히 식별하는 일과, 우리 자체 모니터링이 영향을 받은 사실이 맞물리면서, 정확히 무엇이 어떻게 영향을 받는지 명확한 그림을 얻기 어려웠습니다. 이는 인시던트 초기 시간 내내 과제로 남았습니다. 리전별로 고객 영향의 범위와 깊이를 정확히 파악하고(리전마다 달랐습니다), 트러블슈팅과 완화를 시작하는 데에도 어려움이 있었습니다. 완전히 격리된 스택으로 점진적·단계적 롤아웃을 하다 보니, 멀티 리전 장애에 대한 기대도, 경험도 거의 없었습니다.
커뮤니케이션과 고객 영향 종식을 모두 달성하기 위해, 인시던트 커맨더는 두 개의 병렬 워크스트림을 시작했습니다. 초점은 다음과 같았습니다.
첫 번째 워크스트림을 위해 우리는 많은 엔지니어링 팀의 대응자를 호출해 각 제품이 고객에게 어떻게, 그리고 정상적으로 동작하고 있는지 평가했습니다. 이 작업은 장애의 다변적인 양상과 우리 모니터링의 상당 부분 상실 때문에 방해를 받았고, 인테이크 시스템의 상태를 파악하는 데 이때부터 수십 분이 소요되었습니다. 이는 부분적으로 원인 실패가 컴퓨트 및 Kubernetes 인프라에 기반함을 깨닫는 데 달려 있었습니다.
실패를 진단하려면 상상력과 불신의 유예가 필요했습니다. 당시 대응자들은 Datadog 전체에 동시에 업데이트를 가할 수 있는 채널이 있다는 사실을 알지 못했으며, 서로 다른 리전이 어떤 인프라도 공유하지 않는다는 점을 알고 있었습니다. 우리는 ‘그래야 마땅한 상태(ought)’가 아니라 ‘현장에서 확인되는 사실(is)’을 식별하도록 스스로를 강제해야 했고, 평소 데이터를 보던 지점(우리 모니터링이 영향을 받았기 때문에)을 찾아가려는 본능을 억눌러야 했습니다.
인시던트의 원인을 찾기 위해, 대형 인시던트를 선언한 지 몇 분 후 다음 세 팀을 합류시켰습니다.
이들 팀이 06:40 UTC경 대응에 합류한 후, 근본 문제가 Kubernetes 노드 전반의 실패라는 것을 식별하는 데 약 3040분이 걸렸고, 그 문제가 더 이상 추가 노드나 신규 노드에서 발생하지 않음을 검증하는 데 또 3040분이 걸렸습니다.
이 기간 동안, 미국과 유럽의 많은 온콜 엔지니어들이 고심각도 인시던트를 알리는 공유 Slack 채널의 활동을 확인했습니다. 근무 시간 외였음에도 불구하고, 이들은 직접 페이지를 받지 않았더라도 자발적으로 대응에 합류하기 시작했습니다. 이는 우리 조직의 선제적 인시던트 대응 문화가 실제로 작동하고 있음을 잘 보여줍니다. 이 엔지니어들은 우리가 도그푸딩 중이던 Incident Management 제품의 새 기능을 이용해(대부분) 제품 기반의 대응 워크스트림으로 스스로 조직화했습니다. 관리형 워크스트림은 대응 상황을 추적하고 모든 대응자가 우선순위에 대해 동일한 인식을 갖도록 하는 데 큰 도움이 되었습니다.
첫 한 시간 안에 50명 이상의 엔지니어가 대응에 참여했습니다. 최종적으로 우리는 거의 100개의 워크스트림을 열었고, 500~750명의 엔지니어가 교대로 참여해 모든 제품과 서비스를 복구했습니다.
컴퓨트 인프라 팀은 약 08:30 UTC에 EU1 리전에 대한 동작하는 완화책을 식별할 수 있었습니다. 이 시점에서 인시던트 커맨더는 전반적인 복구 계획을 제시하고 관련 팀의 엔지니어를 호출했습니다. 인시던트 내내, 대응자들은(일반적으로 고객이 사용 가능한 라이브 데이터에 접근할 수 있도록 하는 전략을 우선시하며) 조율되어 일했고, 다른 팀의 완화 작업과 요구 사항에 압도되거나 산만해지지 않았습니다. 이는 우리의 우선순위가 여러 차례 전환되는 동안에도 유지되었습니다(예: AWS 리전이 실제로 다른 리전보다 훨씬 큰 영향을 받았다는 사실을 파악했을 때. 이는 AWS의 스테이트리스 서비스가 스스로 복구된 것처럼 보였다는 사실 때문에 초기에는 가려졌었습니다).
대응 규모가 커지면서, 우리는 워크스트림 리드를 지명해 인시던트 부지휘관으로 역할하게 할 필요가 있음을 확인했습니다. 이는 전반적으로 잘 작동했고 메인 인시던트 커맨더의 오버헤드를 줄이는 데 도움이 되었습니다. 다만(이 과정을 적극적으로 트레이닝하지는 않기 때문에) 모든 부지휘관이 자신의 책임을 완전히 이해한 것은 아니었습니다. 그럼에도, 팀 범위의 소규모 인시던트 경험 및 대규모 인시던트 대응을 관찰한 경험이 일반적으로 역할 정의에 도움이 되었습니다.
인프라를 복구하는 우리의 능력은 글로벌 제어 인터페이스의 부재로 인해 영향을 받았습니다. 스택이 분리되어 있었기 때문에, 단일 일련의 작업으로 모든 것을 복구하는 대신 각 리전을 개별적으로 고쳐야 했습니다. EU1 리전의 손상이 가장 명확했고 유럽의 근무 시간이 시작되었기 때문에, 처음에는 그곳의 완화를 우선시했고 엔지니어링 역량이 확보되자 US1을 포함하도록 확장했습니다.
11:00 UTC(미국 기반 대응자 현지 시간 오전 5시)경, 우리는 이것이 장기 복구가 될 것임을 알았습니다. 각 팀이 자신의 서비스에 대해 온콜 상태였고, 인시던트 로테이션에 충분한 인력이 있었기 때문에, 핸드오프가 복구 소요 시간을 크게 늘리지 않을 것이라 확신했습니다. 메인 인시던트 커맨더는 핸드오프를 시작했고, 인시던트 내내 유지되었습니다.
우리는 거의 48시간 동안 회사 전체 차원에서 연속 대응했지만, 인시던트 커맨더들은 어떤 대응자도 한 번에 8시간 이상 활동하지 않도록 했습니다. 이는 비난 없는 인시던트 문화 및 임원진의 지원과 더불어, 복구 작업 전반에 걸쳐 새롭게 발생하는 문제를 계속 해결할 수 있게 해주었습니다.
이 인시던트 내내 여러 커뮤니케이션 도전을 겪었습니다. 우리는 충분한 확신이 생기는 즉시 아는 바를 공유하려 했지만, 때로는 적절한 사람들에게 충분한 세부 정보를 명확히 전달하는 데 어려움을 겪었습니다.
모든 SaaS 제공업체와 마찬가지로, 고객 대상 대규모 커뮤니케이션의 1차 수단은 공개 상태 페이지입니다. 안타깝게도 상태 페이지는 고객 기능을 복원하는 데 필요한 작업량이 미지수일 때 정보를 전달하기에 적합한 도구가 아닙니다. 또한 멀티 테넌트 플랫폼의 영향을 설명하기에도 매우 둔한 도구입니다. 어떤 고객이 마주할 수 있는 최악의 경우, 평균적인 경우, 최선의 경우 중 무엇을 묘사하는 것이 더 나을까요? 제품 내 개별 인포 배너에서 상태 페이지 업데이트로 전환하는 기준은 무엇일까요? 이 질문은 인시던트마다 답을 내려야 하며, 그 답은 항상 자명하지 않습니다.
수년에 걸쳐 우리는 각 제품별 휴리스틱과 초기 상태 페이지 업데이트 문구를 마련해 왔습니다. 그러나 이번은 달랐습니다. 한편으로는 문제가 얼마나 광범위한지에 대해 오해의 여지가 없었습니다. 다른 한편으로는 준비된 문구가 없었고, 해소를 향해 진전을 이루고 있었음에도 업데이트가 복구의 미묘한 차이를 충분히 전달하지 못했습니다.
마지막으로, 제품별 상태 페이지 업데이트 커뮤니케이션은 인시던트 내내 어려움이 있었습니다. 여러 리전에 걸친 거의 20여 개 제품에 대한 업데이트를 공유해야 했습니다. 이러한 업데이트를 얻으려면 각 제품을 대응 중인 팀에 연락해야 했고, 영향이 항상 정의하기 쉬운 것도 아니었으며(자체 시스템이 여전히 영향을 받는 동안에는 모니터링이 불가능한 경우도 있었습니다), 그 결과 장애 동안 고객이 정확히 어떤 영향을 받는지에 대해 시의적절한 업데이트를 제공하지 못하는 경우가 있었습니다.
많은 고객이 자연스럽게 답을 찾기 위해 지원팀에 문의했습니다. 고객이 시간을 내어 우리에게 연락한다면, 우리는 시간을 들여 응답하는 것을 기본적인 예의로 여기며, 각 티켓이 구체적이고 관련성 있는 답변을 받도록 최선을 다합니다.
이번 예외적인 인시던트는 우리가 초기에는 상상하지 못했던 방식으로 대응을 가중시켰습니다. 인시던트 초기 12시간 동안 평소보다 약 25배 많은 티켓을 받았습니다. 방대한 규모의 대응 때문에 평소보다 훨씬 많은 지원 엔지니어가 관여해야 했고, 동일한 목소리로, 동일한 페이지를 공유해야 했으며, 나머지 대응팀에 같은 질문을 여러 번 하지 않고도 정보를 얻을 수 있어야 했습니다.
우리는 모든 지원 엔지니어에게 고객이 어떤 영향을 받았는지, 복구가 어느 정도 진행되었는지 이해하는 데 필요한 정보를 제공하는 데—적어도 초기에는—항상 성공적이지 못했습니다. 여기서도, 대응에 관여한 사람들에게 부여한 자율성은 곧 다양한 복구 진행 상황을 이해 가능한 방식으로 내부 팀에 전파하기 위한 스프레드시트와 문서를 즉석에서 만들어내는 결과로 이어졌고, 내부 팀은 이를 고객에게 전달했습니다.
3월 8일 인시던트 초기 12시간 동안 평소의 약 25배에 달하는 티켓을 수신했습니다. 그래프에서 일반적인 시간당 티켓 수는 1배(1x)로 표시됩니다.
3월 8일 인시던트 초기 12시간 동안 평소의 약 25배에 달하는 티켓을 수신했습니다. 그래프에서 일반적인 시간당 티켓 수는 1배(1x)로 표시됩니다.
우리는 인시던트 커맨더에게 최소한 매시간 영향도를 재평가하고 고객을 업데이트하도록 교육합니다. 인시던트의 시작에는 전체 그림이 나올 때까지 기다리는 것보다 대응이 더 중요하기에 특히 그렇습니다. 다만 이번처럼 전사적이고 심각한 장애의 경우, 사실상 대부분 동일하고 짧은 업데이트(“우리가 대응 중입니다.”)가 길게 이어졌습니다. 돌아보면, 그때 더 유익한 메시지를 공유할 수 있었으면 좋았을 것 같습니다.
인시던트가 진행되어 서비스를 복구하기 시작하면서, 우리는 전반적인 고객 커뮤니케이션을 개선하기 위해 여러 정기 체커인을 마련했습니다. 매시간 커뮤니케이션 리드는 엔지니어링 워크스트림 리드들과 체크인해 상태 페이지 커뮤니케이션을 업데이트할 수 있도록 했습니다. 약 40분마다 온콜 임원은 우리가 알고 있는 것과 엔지니어링 측에서 복구한 사항을 공유해, 지원 엔지니어와 CSM이 그 정보를 고객에게 전달할 수 있도록 했습니다. 이 임원들은 인시던트 전반에 걸쳐 이런 커뮤니케이션 주기가 유지되도록 보장하고 지원하는 책임도 졌습니다.
우리는 문제를 가능한 한 신속히 해결하기 위해 최선을 다했습니다. 인시던트의 규모, 첫 글로벌 장애였다는 사실, 커뮤니케이션해야 했던 사람 수를 고려할 때, 우리의 대응이 인시던트의 규모에 걸맞게 확장되었다는 점에 긍정적인 놀라움을 느꼈습니다.
돌아보면, 다음과 같은 요인들이 도움이 되었습니다.
그렇다고 모든 것이 바라던 만큼 잘 풀린 것은 아닙니다. 개선하고 싶은 영역이 여러 가지 보입니다.
내부 대응을 다음과 같이 개선하겠습니다.
또한 고객 커뮤니케이션은 고객이 기대하는 수준에 미치지 못했음을 알고 있으며, 특히 상세함과 구체성 측면에서 그러했습니다. 이를 해결하기 위해 다음과 같은 중대한 개선을 진행하고 있습니다.
2023년 3월 8일은 우리 모두에게 겸허함을 안겨준 날이었고, 동시에 다양한 방식으로 배우고 상황에 부응할 기회이기도 했습니다. 여기서의 각 교훈은, 지속적으로 진화하는 조직에서 대규모 소프트웨어를 운영하고 복구한다는 것이 무엇을 의미하는지에 대한 우리의 이해를 한층 정제해 주었습니다. 우리는 그 배움을 실제에 옮기는 데 전념하겠습니다.
