사례3건
3건 중 1~3번째
- 증상
04시 34분에 모니터링 시스템이 첫 노드의 DNS 이름 해석 문제를 잡아 pager duty 알림을 울렸다. 첫 노드가 DNS 레코드를 해석하지 못하면서 인프라 전체의 가용성에 영향이 갔다.
- 촉발
Octez Connect 가 쓰는 하나뿐인 DNS 공급사 MetaNet 에서 장애가 났다. 공급사의 긴급 전화, 상태 페이지, 티켓 시스템도 함께 멈췄다.
- 원인
- 구성 요소
- 기여 요인
- 감지
04시 34분에 모니터링 시스템이 DNS 이름 해석 문제를 잡았다. 첫 노드가 DNS 를 해석하지 못해 pager duty 알림이 울렸다.
- 조치
- 04시 34분에 DNS 이름 해석 문제를 감지하고 pager duty 호출을 걸었다.
- 공급사의 긴급 전화를 계속 걸고 상태 페이지를 지켜보며 공급사에 광범위한 장애가 났음을 확인했다.
- 08시 20분에 [email protected] 에서 공급사가 문제를 살펴보고 있다는 답을 받았다.
- 08시 30분에 시험해서 DNS 가 다시 돌기 시작한 것을 확인했다.
- 08시 40분에 Slack 과 Twitter 에 복구를 알리는 공개 공지를 올렸다.
- 후속 조치
- DNS 공급사를 둘로 쓰는 구성을 만든다.
- 장애 정보를 실시간으로 알리는 공개 상태 페이지를 만든다.
- 외부 공급사 장애 때의 내부 에스컬레이션 절차를 다시 살피고 고친다.
- 교훈
DNS 공급사 하나에만 기대면 그 공급사가 단일 장애 지점이 되어 연결된 서비스가 모두 멈출 수 있다. 이번 DNS 장애는 가용성만이 아니라 공급사와의 소통도 늦춰 중단을 키웠다. 몇 시간 안에 복구됐지만, 공급사 하나가 장애를 겪어도 서비스가 계속 돌도록 DNS 공급사를 둘로 두어야 한다.
- 증상
Facebook 데이터 센터 사이의 서버 연결과 데이터 센터와 인터넷 사이의 서버 연결이 한꺼번에 완전히 끊겼다. DNS 서버는 동작하고 있었지만 인터넷에서 닿지 않아 누구도 Facebook 서버를 찾을 수 없었다. 백본이 통째로 빠지자 DNS 서버가 있는 작은 시설들이 스스로 비정상이라고 판단해 BGP 광고를 거둬들였기 때문이다.
- 촉발
일상적인 유지보수 작업 중에 전 세계 백본 용량의 가용성을 평가하려고 내린 명령이 의도치 않게 백본 네트워크의 모든 연결을 끊었다. 이런 명령을 검사해 실수를 막는 감사 도구가 버그 때문에 이 명령을 멈추지 못했다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 주 네트워크 접근과 out-of-band 접근이 모두 끊겨, 팀은 엔지니어를 데이터 센터 현장에 보내 문제를 디버깅하고 시스템을 다시 시작하게 했다.
- 보안 접근 절차를 거쳐 현장 인력이 서버를 다룰 수 있게 된 뒤 문제를 확인하고 백본을 다시 온라인으로 올렸다.
- storm 훈련에서 얻은 경험을 살려 서비스를 다시 켜면서 늘어나는 부하를 조심스럽게 관리했다.
- 후속 조치
- 전 세계 백본이 끊기는 상황을 storm 훈련으로 시뮬레이션할 방법을 찾는다.
- 테스트와 훈련, 전반적인 복원력을 강화해 이런 사고가 최대한 드물게 일어나게 한다.
- 교훈
무단 접근을 막으려고 강화한 보안이, 공격이 아니라 스스로 낸 실수에서 비롯된 장애의 복구를 늦췄다. Meta 는 드문 사고에서 복구가 느려지더라도 평소의 보안을 크게 높이는 편이 낫다고 봤다. 서비스, 데이터 센터, 리전 전체를 내리는 storm 훈련이 부하를 다시 올리는 데 도움이 됐지만, 전 세계 백본이 끊기는 상황은 훈련해 본 적이 없었다.
IL-0250slack.com 에 DNSSEC 를 켠 뒤 일부 재귀 리졸버에서 slack.com 이름이 풀리지 않아 일부 사용자가 24시간 동안 Slack 에 접속하지 못했다Slack2021- 증상
2021년 9월 30일 slack.com 의 DS 레코드를 DNS 등록 기관에 올린 직후 Customer Experience 팀에 사용자 신고가 들어왔다. Slack 클라이언트에 "ERR_NAME_NOT_RESOLVED" 오류가 뜬다는 신고였다. 그런데 DNSSEC 검증을 강제하는 이름 해석 모니터링과 DNSSEC 프로브는 모두 정상으로 나왔다.
- 촉발
2021년 9월 30일 Traffic Engineering 팀이 세 번째 시도로 slack.com 의 Route53 영역과 NS1 하위 위임 영역에 DNSSEC 서명을 켜고, 세 시간 뒤 DNS 등록 기관에 slack.com 의 DS 레코드를 올렸다.
- 원인
- 구성 요소
- 기여 요인
- 감지
DS 레코드를 올린 직후 Customer Experience 팀이 ERR_NAME_NOT_RESOLVED 를 본다는 사용자 신고를 받았다. 이때 DNSSEC 프로브는 정상으로 나왔다. 서명을 되돌린 뒤에는 외부 DNS·DNSSEC 해석 프로브가 여러 리졸버의 해석 실패를 알려 Traffic 팀이 호출됐다.
- 조치
- 등록 기관에서 slack.com 의 DS 레코드를 내려 .com 영역에서 지웠다.
- slack.com 권한 영역과 위임 영역의 DNSSEC 서명을 되돌려 마지막 정상 설정으로 돌렸다.
- 주요 ISP 와 공개 DNS 리졸버 운영자에게 연락해 slack.com 의 캐시 레코드를 모두 비워 달라고 요청했다.
- Google 8.8.8.8 과 Cloudflare 1.1.1.1 처럼 캐시 비우기 사이트를 둔 리졸버는 팀이 직접 캐시를 비웠다.
- 교훈
Slack 은 와일드카드 레코드가 있는 도메인을 slack.com 보다 먼저 시험하지 않은 것을 실수로 꼽았다. .com 영역의 DS 레코드는 리졸버에 최대 24시간 캐시되므로, DS 레코드를 내린 뒤에도 그 시간 동안은 권한 영역에서 DNSKEY 를 지우면 안 된다. 영역에 서명을 다시 켜도 DS 레코드의 TTL 에는 영향이 없다. Terraform 으로 DNS 를 관리하면 Route53 콘솔이 서명을 끌 때 띄우는 경고를 보지 못한다. 리졸버마다 NSEC 응답을 다르게 해석해도 규격에 맞을 수 있으므로, 권한 이름 서버가 실제로 있는 레코드 타입을 NSEC 타입 비트맵에 정확히 담는 것만이 이 모호함을 피하는 길이다.
이 3건에서 가장 많이 나오는 구성 요소: DNS 서버와 레코드, 백본망. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.