사례2건
2건 중 1~2번째
- 증상
temple.2i2c.cloud 의 JupyterHub 에 접속할 수 없었고 업타임 체크 경보가 울렸다. 커뮤니티가 데모를 하기 직전이었다.
- 촉발
Temple 의 새 클러스터를 준비하면서 *.temple.2i2c.cloud 와일드카드 레코드를 더해 새 클러스터의 Ingress IP 를 가리키게 했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
오전 10:02 에 Google Cloud 의 업타임 체크 경보가 PagerDuty 로 울렸다. 커뮤니티 신고는 그 뒤인 오전 10:09 에 들어왔다.
- 조치
- NameCheap DNS 에 temple.2i2c.cloud 의 A 레코드를 따로 더했다.
- 기본값이 30분이던 DNS TTL 을 5분으로 바꿨다. 데모가 임박해서 해 본 조치였고, 전파 속도에 실제 효과가 있었는지는 분명하지 않았다.
- 데모를 하려는 커뮤니티 사용자에게 /etc/hosts 항목을 넣는 우회책을 안내했다.
- 후속 조치
- 팀원 모두가 Namecheap 에 들어갈 수 있게 권한을 고친다. 그럴 수 없으면 DNS 사업자를 옮긴다.
- 새로 만드는 모든 DNS 레코드의 TTL 을 30분이 아니라 5분으로 둔다.
- *.X.2i2c.cloud 레코드를 더할 때는 X.2i2c.cloud 레코드도 반드시 같이 더해야 한다고 문서에 적는다.
- 교훈
자동 경보가 커뮤니티 신고보다 먼저 문제를 잡았다. 새 클러스터를 준비한 엔지니어가 DNS 를 관리하는 Namecheap 에 권한이 없어서 다른 사람에게 부탁해 레코드를 만들었다. Namecheap 의 기본 TTL 이 30분이라 고친 값이 전파되는 데 그만큼 걸릴 수 있었다. 2i2c 는 장애가 데모 도중이 아니라 데모 전에 났고, DNS 를 고칠 권한이 있는 사람이 마침 자리에 있었던 것이 운이 좋았다고 적었다.
IL-0533Azure China 의 핵심 시스템 도메인 chinacloudapp.cn 과 chinacloudsites.cn 의 이름 해석이 실패해 여러 서비스에 연결할 수 없었다Microsoft Azure2024- 증상
Azure China 리전에서 고객이 여러 Azure 서비스에 연결하지 못했다. Azure Portal 인 portal.azure.cn 과 API 로도 리소스를 보거나 관리하기 어려웠다. chinacloudapp.cn 과 chinacloudsites.cn 도메인 안의 FQDN 을 해석하지 못한 것이 원인이었다.
- 촉발
도메인 등록 기관을 거친 설정 변경으로 2024-04-23 03:45 CST 에 chinacloudapp.cn 과 chinacloudsites.cn 의 네임서버가 비활성 서버 묶음으로 바뀌었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
04:37 CST 에 내부 모니터가 Azure China Cloud 의 서비스 저하를 알리고 인시던트를 만들었다. 04:39 CST 에 엔지니어링 팀이 인시던트를 확인했다.
- 조치
- 04:59 CST 에 두 도메인의 네임서버를 이전의 정상 네임서버로 되돌렸고, 05:13 CST 에 되돌리기를 마쳤다.
- 후속 조치
- Azure China 의 관리 도구의 수정이 끝날 때까지 이 도메인 수명 주기 절차의 실행을 모두 멈췄다.
- 도메인 수명 주기 관리의 검증 절차를 고쳐 모든 클라우드 리전의 신호가 들어가게 한다. 2024년 6월에 마칠 예정이다.
- 인터넷에서 영역을 직접 조회해 네임서버 정보를 얻는 검증을 더한다. 2024년 7월에 마칠 예정이다.
이 2건에서 가장 많이 나오는 구성 요소: DNS 서버와 레코드. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.