사례3건

3건 중 1~3번째

1. IL-0502 새 와일드카드 DNS 레코드 때문에 temple.2i2c.cloud 가 조회되지 않아 JupyterHub 에 접속할 수 없었다

   2i2c2025

   증상

   temple.2i2c.cloud 의 JupyterHub 에 접속할 수 없었고 업타임 체크 경보가 울렸다. 커뮤니티가 데모를 하기 직전이었다.

   DNS 조회 실패서비스 중단

   촉발

   Temple 의 새 클러스터를 준비하면서 *.temple.2i2c.cloud 와일드카드 레코드를 더해 새 클러스터의 Ingress IP 를 가리키게 했다.

   원인

   설정 변경

   구성 요소

   DNS 서버와 레코드

   기여 요인

   미검증 가정캐시로 가려진 장애기본 설정 방치

   감지

   오전 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 를 고칠 권한이 있는 사람이 마침 자리에 있었던 것이 운이 좋았다고 적었다.

   사례 보기
2. IL-0533 Azure China 의 핵심 시스템 도메인 chinacloudapp.cn 과 chinacloudsites.cn 의 이름 해석이 실패해 여러 서비스에 연결할 수 없었다

   Microsoft Azure2024

   증상

   Azure China 리전에서 고객이 여러 Azure 서비스에 연결하지 못했다. Azure Portal 인 portal.azure.cn 과 API 로도 리소스를 보거나 관리하기 어려웠다. chinacloudapp.cn 과 chinacloudsites.cn 도메인 안의 FQDN 을 해석하지 못한 것이 원인이었다.

   DNS 조회 실패오류율 상승모니터링 중단

   촉발

   도메인 등록 기관을 거친 설정 변경으로 2024-04-23 03:45 CST 에 chinacloudapp.cn 과 chinacloudsites.cn 의 네임서버가 비활성 서버 묶음으로 바뀌었다.

   원인

   설정 변경

   구성 요소

   DNS 서버와 레코드

   기여 요인

   미검증 가정캐시로 가려진 장애

   감지

   04:37 CST 에 내부 모니터가 Azure China Cloud 의 서비스 저하를 알리고 인시던트를 만들었다. 04:39 CST 에 엔지니어링 팀이 인시던트를 확인했다.

   조치

   • 04:59 CST 에 두 도메인의 네임서버를 이전의 정상 네임서버로 되돌렸고, 05:13 CST 에 되돌리기를 마쳤다.

   후속 조치

   • Azure China 의 관리 도구의 수정이 끝날 때까지 이 도메인 수명 주기 절차의 실행을 모두 멈췄다.
   • 도메인 수명 주기 관리의 검증 절차를 고쳐 모든 클라우드 리전의 신호가 들어가게 한다. 2024년 6월에 마칠 예정이다.
   • 인터넷에서 영역을 직접 조회해 네임서버 정보를 얻는 검증을 더한다. 2024년 7월에 마칠 예정이다.

   사례 보기
3. IL-0549 Atlassian 의 us-west-1 리전에서 미디어, 첨부 파일, Git LFS, 빌드 아티팩트의 저장과 조회가 실패했다

   Atlassian2023

   증상

   2023년 5월 15일 02:36 UTC 부터 us-west-1 리전에 서비스를 둔 Atlassian 고객에게 미디어, 첨부 파일, 빌드 아티팩트 같은 데이터 자산의 저장과 조회가 실패했다. 자동 모니터링이 3분 안에 감지했다.

   오류율 상승오래된 엔드포인트 라우팅

   촉발

   네트워크 세그먼트 사이의 분리를 강화해 보안을 높이는 작업의 하나로 내부 서비스를 새 네트워크 세그먼트로 옮겼다.

   원인

   설정 변경

   구성 요소

   DNS 서버와 레코드

   기여 요인

   미검증 가정스테이징 불일치

   감지

   자동 모니터링이 3분 안에 감지했다.

   조치

   • 네트워크 이전 변경을 롤백해 Atlassian 시스템을 정상이던 상태로 되돌렸다.

   후속 조치

   • 서비스 스택을 내리는 시스템을 검토하고, 스택을 내리기 전에 그 스택이 더는 고객 트래픽을 받지 않는지 확인하는 검사를 넣는다.
   • 서비스 네트워크 이전 절차에 함께 손봐야 할 DNS 레코드가 있는지 찾는 단계를 더한다.

   교훈

   Atlassian 은 기존 테스트와 예방 절차가 이 문제를 잡지 못했다고 밝혔다. 서비스를 네트워크 세그먼트 사이로 옮기는 일은 자주 하는 작업이 아니고, 테스트 환경에서 정확히 재현하기도 어렵기 때문이라고 설명했다. 이런 문제를 막으려고 블루/그린 배포 방식을 썼지만, 옛 스택을 내리기 전에 충분한 검증 단계를 돌리지 않았다고 적었다.

   사례 보기

원인별1