인프라쪽 업무를 하기 때문에 이번 Datadog 장애의 포스트모텀을 꽤 재미있게 읽었고 아무리 준비해도 이렇게 생각 못한 이슈 그리고 문제를 파악하기 어려운 상황이 발생할 수 있다는 생각이 들었습니다. - Datadog은 Ubuntu를 사용하는데 새 LTS인 22.04를 작년부터 테스트해서 작년 11월 부터 점진적으로 적용하기 시작했습니다. 그래서 클러스터에는 Ubuntu 20.04와 Ubuntu 22.04가 섞여있었습니다. - 이는 클러스터를 더 안정적으로 운영하기 위한 조치임에도 뒤에서 더 얘기하겠지만 장애는 Ubuntu 22.04를 사용하는 노드에서 발생합니다. 결과를 알고보면 뻔하지만 당시에는 패턴없이 괜찮은 노드도 있고 문제가 발생하는 노드도 있는것처럼 보여서 더 어려웠을 것 같습니다. - datadog은 무인 업데이트를 위해 Kubernetes의 노드 운영체제는 기본값을 그대로 사용하고 업데이트를 UTC 6시와 18시에 동작하도록 설정해 두고 있고 한번에 되지 않도록 1시간의 윈도우로 랜덤 시간을 주어 업데이트하게 합니다. - 마찬가지로 뒤에서 원인은 더 얘기하겠지만 이번 장애는 이 OS 업데이트가 실행되면서(Ubuntu 22.04인 경우에) 문제가 생겼기 때문에 엔지니어 입장에서는 랜덤으로 여러 리전의 노드가 마구 장애나는 것처럼 보였을 것입니다. 리전당 클러스터는 안정성을 위해서 연결이 전혀 되어 있지 않지만 OS 업데이트로 인해서 여러 리전에 걸쳐서 장애가 낫기 때문에 원인을 파악하기가 더 어려웠을것입니다. - A 리전에서 정애나서 보고 있는데 B 리전도 갑자기 장애나니까 이건 뭐지? 같은 기분이 들었을게 상상이 됩니다. - systemd v248부터 알지 못하는 IP 라우팅 규칙을 플러시하는 동작이 추가되었습니다. Ubuntu 20.04는 v245를 사용하고 Ubuntu 22.04는 v249를 사용합니다. - 3월 7일(datadog 장애는 8일) Ubuntu에 systemd 취약점패치가 등록됩니다. - 이 업데이트가 다음날 적용됩니다. Ubuntu 22.04는 Cilium이 통신에 사용하기 위해 등록해 놓았던 IP 라이팅 규칙이 제거되면서 통신 문제가 생기고 Ubuntu 20.04에서는 업데이트가 적용되었지만 해당 규칙을 플러시하는 기능이 없으므로 문제가 생기지 않습니다. - Datadog의 Infrasturcture as Code로 구성한 노드 설정에서는 systemd를 실행한 뒤에 Kubernetes 통신을 위한 Cilium 설정을 하기 때문에 정상 절차에서는 문제가 생기지 않습니다. 이 문제는 모든 설정이 다 끝난 뒤에 다시 systemd를 리스타트했을 때만 발생하는 문제였습니다. - 장애시에도 노드를 새로 띄울때는 아무런 문제가 발생하지 않았습니다. 이부분도 장애 원인 파악에 어려움을 주었을 것이라고 생각합니다. - Datadog은 안정성을 위해서 AWS, Azure, Google Cloud를 모두 사용하고 있습니다. AWS는 헬스체크가 있어서 인스턴스 연결이 안되자 노드를 제거하고 다시 띄워서 문제가 해결되었지만 Azure와 Google Cloud는 수동으로 리부팅해야 했습니다. - 장애 상황에는 AWS가 더 문제가 없는 것처럼 보였지만 사실 리스타트만 하면 해결되는 문제였기 때문에 오히려 Azure, Google Cloud에서는 리스타트로 문제가 쉽게 해결되었지만 AWS같은 경우는 이미 인스턴스가 제거되었기 때문에 로컬데이터가 없어져서 이부분에 대한 복구가 훨씬더 어려워졌습니다. 글을 아주 재미있게 읽었고 얼마나 힘들었을지도 상상할 수 있었습니다. 흥미롭게 느낌 부분은 대부분의 조치가 안정화를 위해서 한 조치였지만 이 장애 상황에 한해서는 오히려 문제 파악을 어렵게 만들었고 정말 예상하기 어려웠을거라고 생각합니다. 예상 했으면 미리 조치했을테니 이러한 장애가 발생하지 않았을 것입니다. https://www.datadoghq.com/blog/engineering/2023-03-08-deep-dive-into-platform-level-impact/