[Post Mortem] 데이터독 장애 포스트모템(2023-03-08 Incident: Infrastructure connectivity issue affecting multiple regions)

2023년 3월, 데이터독(Datadog)에 완전 복구까지 2일 걸린 대규모 장애가 있었습니다. 데이터독에서 관련 내용을 정리하여 블로그에 올려주었는데, 이번에는 해당 내용을 살펴보도록 하겠습니다.

 

 

 

1. Impact, chronology, and response(영향, 연대순 정리, 대응)

---

[ Incident and Impact(장애와 영향) ]

2023년 3월 8일 06:03(UTC)부터 US1, EU1, US3, US4 그리고 US5에 걸쳐 모든 데이터독 서비스 가동이 중단되었습니다. 장애가 시작되었을 때, 사용자는 브라우저나 API를 통해 데이터독 플랫폼이나 서비스에 접근할 수 없었으며, 모니터링도 불가능했고 알람 역시 오지 않았습니다. 데이터 수집을 위한 다양한 서비스들도 중단 초기에 영향을 받았습니다.

 

 

 

[ Chronology(연대순 정리) ]

즉각적인 조사를 시작하여 06:31(UTC)에 문제를 알리는 첫 상태 페이지 업데이트가 이루어졌고, 07:23(UTC)에 데이터 수집 및 모니터링에 잠재적인 영향을 미칠 수 있음을 알리는 첫 업데이트가 이루어졌습니다.

09:13(UTC)에 초기 복구 징후가 보이기 시작했고(웹 접속 복구), 16:44(UTC)에 첫 번째 주요 서비스 운영을 선언했습니다. 이후에도 복구 작업을 계속하여 다음날인 2023년 3월 9일 08:58(UTC), 모든 지역에서 전체 서비스 운영을 선언했습니다. 그 다음날인 2023년 3월 10일 06:25(UTC)에는 과거 데이터를 다시 채운 후, 이 장애는 완전히 해결되었습니다.

 

 

 

[ Response(대응) ]

2023년 3월 8일 06:00(UTC), 보안 결함을 위한 패치가 시작된 지 3분 후에, 내부 모니터링을 통해 문제를 처음 인지하게 되었습니다. 조사 18분 후에는 내부적으로 심각도가 높은 장애임을 선언했고, 그 직후인 06:31(UTC)에는 공개 장애로 전환했습니다.

데이터독의 장애 대응팀은 대략 선임 엔지니어링 리더 10명, 70명의 장애 지휘관, 450~750 명의 장애 대응자로 구성되어 비상 운영 센터를 구축했고, 해결할 때까지 4교대로 근무했습니다. 커뮤니케이션 책임자는 4개 지역에 걸쳐 약 200건의 상태 업데이트를 조율했으며, 수백 명의 서포트 엔지니어가 24시간 내내 고객과 지속적으로 소통했습니다.

장애를 완화시키고 수정하는 작업은 다음과 같이 진행되었습니다.

1. 고객이 과거 데이터에 제한적으로 접근 가능할지라도 플랫폼을 사용할 수 있도록 실시간 텔레메트리 데이터의 정상적인 수집과 처리를 복구하는데 초기 노력을 집중했습니다.
2. 실시간 데이터를 사용할 수 있게 되자, 가동 중단 초기에 수집되었지만 처리되지 않은 데이터로 복구 작업을 전환했습니다.
3. 동시에 고객에게 상황을 알리기 위해 상태 페이지에서 진행 상황에 대한 업데이트를 자주 제공하기 시작했습니다.

 

 

 

2. Root Cause, Recovery(근본적인 원인과 복구)

---

[ Root Cause(근본적인 원인) ]

우리는 서비스 중단에 대한 원인을 찾았습니다(이후에는 비활성화했습니다). 2023년 3월 8일 06:00(UTC)에 systemd에 대한 보안 업데이트가 여러 VM에 자동 적용되었고, 이로 인해 Ubuntu 22.04의 systemd v249를 통해 systemd-networkd 재시작 시에 systemd에 부정적인 상호 작용이 발생했음을 확인했습니다. 즉, systemd-networkd가 컨테이너 간의 통신에 사용하는 컨테이너 네트워크 인터페이스(Container Network Interface, CNI) 플러그인(Cilium)이 관리하는 경로를 강제로 삭제했습니다. 이로 인해 영향을 받은 노드가 오프라인 상태가 되었습니다.

 

상황을 악화시킨 요인은 새로운 노드나 재부팅된 노드 모두 이 현상이 나타나지 않는다는 점인데, 정상적인 부팅 과정에서는 systemd-networkd가 항상 CNI 플러그인에 의해 라우팅 규칙이 설치되기 전에 시작되기 때문입니다. 즉, 실행 중인 노드에서 systemd-networkd 업데이트 시나리오를 제외하고는 정확한 과정을 재현하는 명확한 테스트가 없습니다.

 

이것이 즉각적으로 어떤 영향을 미쳤나요? 이는 06:00~07:00 사이에 수만 개의 노드에 영향을 미쳤으며, 06:31(UTC)에는 고객들이 서비스 중단을 확인할 수 있을 정도의 노드가 오프라인 상태가 되었습니다.

 

5개의 서로 다른 region은 수십 개의 가용 영역에 걸쳐 있고, 3개의 서로 다른 클라우드 제공 업체에서 실행되는데, 그럼에도 불구하고 모두 자동 패치된 이유가 무엇인가요? 새로운 코드, 보안 패치 또는 구성 변경 사항을 플랫폼에 푸시할 때마다 지역별로, 클러스터별로, 노드별로 푸시합니다. 프로세스상 변경 사항을 제자리에 적용하는 것이 아니라 노드와 컨테이너를 Blue/Green 방식으로 교체합니다. 변경이 실패하면 자동 롤백이 트리거됩니다. 이러한 변경 관리 도구는 하루에 수십 번씩 대규모로 실행되기 때문에 자신있게 사용할 수 있습니다. 하지만 k8s 실행을 위한 기본 OS 이미지에는 레거시 보안 업데이트 채널(legacy security update channel)이 활성화되어 있어 업데이트가 자동 적용되었습니다. 설계상 우리는 매우 최소한의 기본 OS 이미지를 사용하므로 이러한 업데이트는 빈번하지 않으며 그날까지 중단된 적이 없었습니다.

 

문제를 더욱 복잡하게 만든 것은 자동 업데이트 시간이 OS 수준에서 기본적으로 06:00~07:00(UTC) 사이로 설정되어 있다는 점입니다. 따라서 지역 간에 직접적인 네트워크 연결이나 결함이 없는데도 여러 지역에 동시에 영향을 미쳤습니다. 이로 인해 영향의 규모가 현저히 커졌고, 우리처럼 지역 간 동작이 간접적으로 연결되는 것을 알지 못했던 초기 대응자들은 당황했습니다.

 

이런 일이 다시 발생하나요? 아니요. 영향을 받는 모든 지역에서 이 레거시 보안 업데이트 채널을 비활성화하여 재발하지 않도록 했습니다. 또한 재시작 시 라우팅 테이블을 변경하지 않고 그대로 두도록 systemd-networkd의 구성을 변경했습니다. 마지막으로, 유사한 레거시 업데이트 채널이 있는지 감사했습니다. 이 레거시 보안 업데이트 채널을 비활성화하더라도, 앞서 언급한 변경 관리 도구를 통해 처리되는 현재의 보안 업데이트 적용 방식과 중복되므로 보안 상에 부정적인 영향을 미치지 않습니다.

 

 

 

[ Recovery(복구) ]

컴퓨팅 능력의 감소가 상당했기 때문에 높은 수준의 복구 단계를 순차적으로 진행해야 했습니다.

1. 먼저, 각 리전에 충분한 컴퓨팅 용량을 복구함으로써 들어오는 데이터를 정상 속도로 처리하는 데 필요한 수준으로 확장할 수 있도록 했습니다. 실제로 각 클라우드 제공업체와 협력하여 실시간 데이터와 과거 데이터를 동시에 처리할 수 있도록 컴퓨팅 용량을 평소보다 더 높은 수준으로 확장했습니다.
2. 컴퓨팅 용량이 준비되면 각 서비스를 병렬적으로 복구하여 모든 서비스를 최대한 빨리 복구할 수 있도록 했습니다.

 

 

Compute capacity(컴퓨팅 용량)

네트워크 스택 손실에 의한 영향은 클라우드 제공업체마다 다르게 느껴졌고, 이로 인해 복구 작업이 복잡해졌습니다.

일부 클라우드 제공업체의 오토 스케일 로직은 영향받은 노드를 비정상으로 올바르게 식별했지만 노드를 즉각적으로 폐기하지는 않습니다. 즉, 영향을 받은 인스턴스를 재부팅하는 것이 올바른 복구 단계였고, 데이터가 그대로 유지되는 stateful한 워크로드의 경우 훨씬 더 빠르며 전반적으로 더 빠른 복구로 이어집니다.

다른 클라우드 제공업체의 오토 스케일 로직은 비정상 상태의 노드를 즉시 새 노드로 교체합니다. 해당 노드의 데이터는 손실되어 복구해야 하므로 작업의 복잡성이 가중됩니다. 또한 한 번에 수만 개의 노드가 교체되는 규모에 의해 클라우드 제공업체의 지역별 속도 제한을 다방면으로 테스트하는 거대 무리가 생겼으며, 어느것도 분명한 것이 없었습니다.

날것의 컴퓨팅 용량을 마음대로 사용할 수 있게 된 후에는 복구 순서에 주의를 기울여야 했습니다. 모든 k8s 클러스터를 정상적으로 유지시켜주는 각 지역의 Internal Control Plane이 복구되어야 플랫폼을 구동하는 수백 개의 k8s 클러스터를 복구할 수 있었습니다. 각 지역의 Control Plane이 완전히 복구되면 여러 컴퓨팅 팀이 분산되어 각 클러스터가 다른 팀에서 실행 중인 서비스를 복구할 수 있을 만큼 충분히 정상인지 확인할 수 있었습니다.

 

 

Service Recovery(서비스 복구)

각 서비스의 복구 단계는 다르지만 여기에 소개할 만큼 충분한 유사점은 있었습니다. 모든 상황의 최우선 순위는 실시간 데이터 처리를 복구하는 것이었습니다. 대부분의 서비스는 한 시스템으로 실시간 데이터(제품에 따라 최근 15분 또는 24시간)를 수집하여 서비스하고, 분리된 시스템에서 과거 데이터를 서비스합니다. 모든 시스템이 각기 다른 정도의 영향을 받았지만, 이러한 분리 덕분에 복구 프로세스 초기에 제품을 정상 작동 상태로 되돌릴 수 있었습니다.

서비스 복구 과정에서 모든 팀이 직면한 또 다른 공통 주제는 공유없는(distributed, shared-nothing) 분산형 데이터 저장소가 quorum 기반의 control plane을 필요로 하는 대부분의 분산형 데이터 저장소보다 장애를 훨씬 잘 처리한다는 사실이었습니다. 예를 들어 정적 샤드 할당(static shard assignment)을 사용하는 독립적인 데이터 노드군은 노드 수가 감소함에 따라 성능이 거의 선형적으로 저하됩니다. 반면에 quorum으로 함께 묶인 동일한 데이터 노드군은 quorum이 충족되는 한 성능 저하 없이 작동하지만, quorum이 충족되지 않으면 작동을 거부합니다. 물론 quorum 기반 제품군이 일상적으로 관리하기가 훨씬 쉽기 때문에 어느 한 쪽을 선택하는 것이 당연한 결정은 아니지만, 이번 서비스 중단은 과거의 선택을 재검토할 필요성을 강조했습니다.

일반적으로, 우리의 기본 텔레메트리 데이터 저장소(포인트값과 원시 로그 데이터 등을 저장함)는 정적 샤드 할당을 사용하는 반면, 다양한 메타데이터(태그를 색인하고 확인하는 저장소)는 작동을 위해 quorum 기반의 시스템에 저장됩니다. 따라서 복구의 대부분은 이러한 메타데이터 저장소를 라이브 데이터에 대한 새로운 쓰기를 허용할 수 있는 수준으로 복구하는 데 중점을 두었으며, 소규모 팀은 라이브 데이터를 인덱싱하고 저장하는 독립적인 정적 샤드를 동시에 복구할 수 있었습니다.

 

 

 

 

3. Lessons learned, In closing(배운 교훈과 끝으로)

---

[ Lessons learned(배운 교훈) ]

아래의 내용은 이번 사건으로 알게 된 모든 내용을 총망라한 것이 아니라 전체 플랫폼과 관련된 중요한 주제를 다룹니다.

이것은 우리의 첫 번째 글로벌 장애였습니다. 우리는 각 로컬 장애에 대해 자동적이고 복원력을 갖춘다는 명확한 설계 목표를 가지고 데이터독 리전을 구축했습니다. 그렇기 때문에 여러 영역에 걸쳐 서로 직접 연결되지 않고 완전히 독립적인 클라우드 제공업체를 통해 구축되었습니다. 또한 이것은 전역적이고 공유되는(global, shared) control plane이 없는 이유이기도 합니다. 또한 각 서비스는 각 지역 별로 장애 조치, 가용 영역 전반에 걸친 active-active 설정, 복구시 급증하는 트래픽을 처리할 수 있는 추가 용량이 있습니다. 그럼에도 불구하고 이러한 서비스들이 어떻게 간접적으로 연관될 수 있는지 예상하지 못했으며, 이러한 미스가 근본적인 인프라를 지속적으로 강화하는데 도움이 될 것입니다.

 

고객을 대신해 처리하는 데이터에는 명확한 계층이 있다는 이야기를 여러 번 들었습니다. 가장 중요한 것은, 사용 가능한 실시간 데이터와 알림이 과거 데이터에 대한 접근보다 훨씬 더 가치있다는 것입니다. 그리고 모든 실시간 데이터 중에서도 대시보드에서 활발하게 모니터링되거나 표시되는 데이터가 나머지 실시간 데이터보다 더 가치있습니다. 이러한 명확한 계층 구조를 고려하여 성능 저하 상태에서 데이터를 처리하고 접근하는 방법을 고려할 것입니다.

 

저희는 카오스 테스트(chaos test)를 실행하고 클라우드 제공업체로부터 어느 정도의 카오스를 지속적으로 받고 있지만, 테스트에서 고려해야 할 성능 규호 저하 규모를 고려하는 데는 부족했습니다. 앞으로는 이번에 경험한 인프라 중단 수준을 활용하여 플랫폼이 완전히 다운되지 않고도 성능이 저하된 수준에서 운영될 수 있음을 증명할 것입니다. 앞서 언급한 사항과 함께, 성능 저하 모드에서 긴급한 데이터만 접근하고 처리하는 형태를 취할 수도 있습니다.

 

이전의 데이터에 접근할 수 없는 경우 실시간 데이터를 제공하는 별도의 시스템(APM의 실시간 검색 및 로그 관리의 Live Tail)이 있음에도 불구하고, 광범위한 장애가 아직 해결되는 동안에도 고객이 시스템에 접근할 수 있는, 즉시 접근할 수 있는 방법에 대한 명확한 지침을 제공하지 못했습니다. 앞으로는 사용 가능한 서비스 및 데이터와 이에 대해 접근하는 방법에 대한 지침을 고객과 우선적으로 공유하겠습니다.

 

장애 기간 동안의 커뮤니케이션은 시간이 지남에 따라 정확성과 깊이가 향상되었지만, 미묘한 제품 상태를 전달하기에는 상태 페이지가 부적절함을 깨달았습니다. 성능 저하 모드로 플랫폼을 실행하는 경우에도 각 제품에 대한 자세한 상태를 실시간으로 전달할 수 있는 방법을 고안해 보겠습니다.

 

 

 

[ In closing(끝으로) ]

이번 서비스 중단은 데이터독의 모든 관계자에게 있어 겸손함을 배울 수 있는 경험이였습니다. 우리 모두는 무중단 서비스가 고객에게 얼마나 중요한지 잘 알고 있으며, 이번 중단 기간과 그 이후에 배운 모든 것들을 바탕으로 서비스 복원력을 확실히 개선하기 위해 최선을 다하고 있습니다.

 

 

 

 

 

Summary(요약)

---

[ Summary(요약) ]

• 장애 원인
  • 자동 적용된 systemd 보안 업데이트에 의해 systemd-networkd가 재시작 됨
  • 이때 컨테이너 간의 통신을 위한 라우팅 정보가 초기화되면서 노드가 오프라인 상태가 됨
  • 리전 별로 독립되었음에도 불구하고(클라우드 서비스까지 다름) 사용중인 기본 OS 이미지의 OS에서 자동 업데이트 시간이 06:00~07:00으로 설정됨에 따라 전체 장애가 발생함
• 복구 작업
  • 각 리전에 충분한 컴퓨팅 용량을 복구함, 실시간 데이터와 과거 데이터를 동시에 처리할 수 있도록 컴퓨팅 용량을 평소보다 더 높은 수준으로 확장함
  • 컴퓨팅 용량이 준비되면 각 병렬적으로 최대한 빨리 복구하도록 함
• 복구 시의 고려 사항
  • 가장 중요한 실시간 데이터의 정상적인 수집과 처리를 복구하는데 초기 노력을 집중함
  • 이후에 수집되었지만 처리되지 않은 기록된 데이터로 복구 작업 진행
  • 상태 페이지를 통해 업데이트를 자주 제공하도록 함

 

 

 

 

참고 자료

• https://www.datadoghq.com/blog/2023-03-08-multiregion-infrastructure-connectivity-issue/