사례2건

2건 중 1~2번째

1. IL-0374 DigitalOcean 내부 서비스 디스커버리가 전 리전에서 멈춰 생성, 이벤트 처리, 제어판과 API 관리가 실패했다

   DigitalOcean2024

   증상

   2024년 8월 5일 16:30 UTC 부터 DigitalOcean 의 모든 리전에서 이벤트 처리가 실패해 Droplet 이벤트가 실패했고, 리소스 생성과 Cloud Control Panel, API 를 통한 관리가 멈췄다. Droplet 같은 기존 고객 리소스는 계속 온라인이었고 접근할 수 있었다.

   서비스 중단클러스터·노드 생성 정체

   촉발

   새 데이터센터를 더하는 데이터스토어 클러스터 롤아웃에서 잘못된 복제 설정이 배포됐다. 이 설정은 키가 하나도 없는 새 데이터센터에 데이터스토어의 모든 키 소유권 100%를 줬다.

   원인

   설정 변경

   구성 요소

   코디네이션 키-값 저장소서비스 디스커버리데이터베이스 복제

   기여 요인

   과도한 영향 범위

   감지

   16:35 UTC 에 서비스 디스커버리를 쓸 수 없다는 첫 보고가 내부에서 올라왔다. 데이터스토어 클러스터 롤아웃이 시작되고 5분 뒤였다.

   조치

   • 17:16 UTC 에 복제 설정 변경을 되돌리고, 데이터스토어 소유자가 된 리전에 되돌린 설정을 적용했다.
   • 18:25 UTC 부터 되돌린 설정을 알아채거나 적용하지 못한 리전을 찾아, 엔지니어가 그 리전의 노드에 직접 설정을 적용하고 데이터스토어 repair 를 돌렸다.
   • 남은 실패 이벤트를 정리하고, 아직 타임아웃되지 않은 대기 이벤트를 처리했다.

   후속 조치

   • 이런 확장 유지보수는 선언한 유지보수 시간 안에 하고, 고객 영향 가능성은 상태 페이지의 유지보수 공지로 알린다.
   • 이런 배포의 절차 문서를 현재 요구 사항에 맞게 고치고, 새 배포의 단계마다 할 일과 기대하는 결과를 분명하게 적는다.
   • 이번에 손으로 한 과정을 자동화해 사람의 실수 가능성을 줄인다.
   • 여러 팀이 내부 데이터스토어의 현재 토폴로지가 알맞은지, 그리고 내부 서비스 디스커버리의 가용성을 지키도록 리전 단위로 나누거나 여러 계층으로 구성할 방법이 있는지 검토한다.

   사례 보기
2. IL-0473 Azure 공개 쿠버네티스 클러스터의 노드 풀이 모두 지워지고 다시 만들어지지 않아 Jenkins 인프라 서비스가 4시간 넘게 멈췄다

   Jenkins project2023

   증상

   2023-07-07 11:05 UTC 부터 15:25 UTC 까지 Jenkins 인프라의 공개 서비스 여럿이 완전히 멈췄다. accounts.jenkins.io, get.jenkins.io, plugins.jenkins.io 를 비롯해 Azure 의 공개 쿠버네티스 클러스터에서 돌던 서비스가 모두 내려갔다.

   네트워크 도달 불가리소스 삭제클러스터·노드 생성 정체서비스 중단

   촉발

   1.25 업그레이드 뒤 파드의 출발 IP 대역이 바뀌어 LDAP 접근이 막히자, 파드 IP 대역을 지정하는 수정인 Azure PR 431 을 10:55 UTC 에 배포했다. 이 변경으로 노드 풀이 모두 지워졌고 다시 만들어지지 않았다.

   원인

   설정 변경

   구성 요소

   노드 풀CNI 플러그인클라우드 로드 밸런서

   기여 요인

   미검증 가정단계적 배포 부재파괴적 변경 보호 장치 부재

   감지

   10:30 UTC 에 1.25 업그레이드를 마친 뒤 팀이 클러스터 안 서비스가 LDAP 서비스에 닿지 못한다는 것을 알아챘다.

   조치

   • 네트워크 설정을 고쳐 클러스터를 처음부터 다시 만들었다. 11:16 부터 13:16 UTC 까지 두 시간이 걸렸다.
   • 파드 CIDR 을 가상 네트워크와 겹치지 않는 별도 대역으로 지정했다.
   • 서비스의 공개 IP 와 DNS 레코드를 새 주소 20.7.178.24 와 2603:1030:408:5::15a 로 바꿨다.
   • 15:17 UTC 에 IP 설정을 포함해 클러스터를 손으로 다시 만든 작업을 PR 로 올려 코드에 반영했다.

   후속 조치

   • Management Lock 을 걸어 공개 IP 가 지워지지 않게 한다.
   • 공개 IP 를 별도 리소스 그룹에 두고, 쿠버네티스가 관리하는 로드 밸런서가 그 그룹을 쓰도록 service.beta.kubernetes.io/azure-load-balancer-resource-group 애너테이션으로 설정한다.
   • 작업을 준비할 때 네트워크 구성과 대역이 겹칠 가능성을 쉽게 볼 수 있도록 네트워크 다이어그램과 문서를 개선한다.
   • AKS 노드 풀 설정을 한꺼번에 바꾸지 않는다. 첫 노드 풀에서 문제를 잡았다면 전체 장애를 피할 수 있었다. arm64 노드 풀에서 PR-3623 으로 이 작업을 하고 있다.

   교훈

   허용 목록을 둔 회사 방화벽 뒤의 사용자가 있어서 공개 IP 는 되도록 바뀌지 않아야 한다. 그런데 원래 클러스터를 지우면서 노드 리소스 그룹과 함께 공개 IP 가 지워졌다. 노드 풀 설정을 한꺼번에 바꾸지 않았다면 첫 노드 풀에서 문제를 잡아 전체 장애를 피할 수 있었다. 팀은 거의 모든 공개 서비스를 담은 클러스터가 완전히 무너져도 4시간 안에 복구할 수 있다는 것을 이번에 확인했다. 그 바탕은 여러 해 동안 함께 해 온 아키텍처 정의, 인프라 구축, 데이터 백업 작업이라고 했다.

   사례 보기

원인별1