지난 3월에 Datadog이 와전복구하기까지 2일이 걸린 대규모 장애가 있었습니다. Datadog이 옵저버빌리티 도구이므로 모니터링, 매트릭, 로그 등을 Datadog에 의존해서 사용할 가능성이 높

지난 3월에 Datadog이 와전복구하기까지 2일이 걸린 대규모 장애가 있었습니다. Datadog이 옵저버빌리티 도구이므로 모니터링, 매트릭, 로그 등을 Datadog에 의존해서 사용할 가능성이 높으므로 Datadog의 장애는 다른 서비스에 꽤 치명적이었습니다. 서비스 장애로 연결되는 것은 아니지만 Datadog만 사용하고 있다면 지금 서비스의 상태가 어떠한지 파악하기 어려울 정도로 눈이 가려진 기분이 들었을 것입니다. 꽤 큰 장애였기 때문에 포스트모텀을 기다리고 있었는데 안올라와서 아쉬워 하고 있던차에 마침 생각나서 검색해 봤다가 최근에 드디어 포스트 모텀이 올라온 것을 알게 되었습니다. 흥미로운 부분이 많이 있습니다. - 장애 대응팀이 선임 엔지니어링 리더 10명, 70명의 현지 장애 지휘관, 450~750명의 장애 대응자로 구성되어서 비상 운영 센터를 구축했고 해결할때까지 4교대로 근무했다고 합니다. 전사급 장애이긴 합니다만 5000명 규모의 회사에서 이정도 규모로 장애 대응팀을 운영한건 꽤 흥미로워서 장애 대응 절차에 대해서도 궁금해졌을 정도입니다. 2일간 다들 밤샐수는 없으므로 아마 글로벌에 걸쳐서 4교대로 대응한 거 같은데 장애 대응 인수인계등 시스템이 궁금해 졌습니다. - Datadog의 특성상 고객의 서비스 모니터링에 큰 영향을 미치기 때문에 먼저 데이터 수집과 처리를 할 수 있게 복구하는데 먼저 집중하고 누락된 데이터 복구를 나중에 처리합니다. 그래서 2일간의 장애이지만 서비스 모니터링 기능은 1일 정도 지난 시점에(이것도 길긴 하지만) 복구하게 됩니다. - 장애 원인은 systemd의 보안업데이트가 적용되어 리스타트되면서 라우팅 테이블을 리셋하면서 Kubernetes 클러스터내 통신 문제가 생긴것이 원인이었습니다. 여러 리전으로 운영하는 Datadog의 모든 리전이 설계상 연결하지 않았음에도 모두다 장애가 발생한 것은 이 때문이었습니다. 자세한 장애 원인은 별도의 포스트가 있어서 글이 길어져서 자세한 내용은 다음 글에 이어서 정리해 보겠습니다. https://www.datadoghq.com/blog/2023-03-08-multiregion-infrastructure-connectivity-issue/