사례7건

7건 중 6~7번째

1. IL-0010 템플릿 중괄호가 빠진 설정 변경으로 ArgoCD 가 전 세계 모든 클러스터의 서비스를 지웠다

   Skyscanner2021

   증상

   2021년 8월 25일 Skyscanner 는 네 시간 반 동안 전 세계에서 완전히 멈췄다. skyscanner.net 웹사이트에 접속할 수 없었고 모바일 앱도 동작하지 않았다. 여행자와 비즈니스 파트너 모두 Skyscanner 를 쓸 수 없었다.

   서비스 중단리소스 삭제

   촉발

   GMT 15:30 무렵 한 엔지니어가 앞으로 할 큰 변경을 준비하면서 템플릿 시스템에 변경을 올렸다. 시스템 동작은 바꾸지 않으려던 변경이었다. 셀 설정 루트 파일의 cell: {{ default $cluster.name $cluster.unique_name }} 줄을 cell: $cluster.name 으로 바꿨다. 변경은 동료 리뷰를 거쳐 master 에 머지됐고 자동으로 배포됐다.

   원인

   설정 변경

   구성 요소

   Argo CD설정 템플릿

   기여 요인

   리뷰 누락단계적 배포 부재설정 테스트 부재미검증 백업자동화 증폭과도한 영향 범위

   조치

   • 클러스터마다 올바른 설정을 되돌려 놓고, GitOps 로 클러스터가 스스로 올바른 상태로 돌아오게 했다.
   • 팀이 익숙하게 다루던 백업과 복원 절차로 서비스를 복원했다.
   • 리전 하나와 핵심 서비스를 먼저 복구해 GMT 20:30 무렵 리전 하나에서 모든 트래픽을 받았다.
   • 목요일과 금요일에 걸쳐 나머지 리전과 핵심이 아닌 서비스를 되살리고 확인했다.

   후속 조치

   • 이번처럼 드물게 쓰이는 변경 경로에서도 설정 변경을 전 세계에 한꺼번에 배포하지 않게 한다.
   • 템플릿과 로직이 들어간 설정을 코드로 다루고, 테스트와 린트를 도입한다.
   • 시나리오와 런북이 최악의 재해 규모까지 다루게 하고, 더 극단적인 상황을 워게임으로 연습한다.
   • 백업과 복원 절차를 검증한다. 필요할 때 백업을 실제로 꺼낼 수 있는지, 리전 하나가 내려간 경우에도 되는지 확인한다.
   • 새벽에 긴장한 엔지니어가 읽어도 맥락과 단계가 분명하고, 필요하면 여러 번 실행해도 결과가 같도록 런북을 고쳐 쓴다.
   • 이 설정을 리전마다 템플릿으로 찍어 낼 필요가 있었는지 다시 따지고, 리전마다 설정이 어긋날 위험과 자동화로 변경이 여러 리전에 한꺼번에 퍼질 위험 사이에서 균형을 찾는다.

   교훈

   설정에 템플릿과 로직을 넣는 순간 그 설정은 코드가 된다. 팀은 설정의 복잡도를 높이면서도 이 파일을 설정으로만 여겨 테스트도 린트도 두지 않았다. 전역 설정 배포를 막으려고 오래 공을 들였지만, 이 경로로 변경이 나가는 일은 아주 드물어서 미처 떠올리지 못했다. 시나리오와 런북은 이 정도 규모의 장애를 상정하지 않았다. 백업은 복원해 보기 전까지 백업이 아니다. 장애 대응을 지휘하는 인시던트 커맨더를 가장 경험 많은 사람이 맡아 누구도 탓하지 않고 상황을 이끈 것이 복구에 큰 도움이 됐다.

   사례 보기
2. IL-0061 Terraform 상태 파일이 리뷰 빌드에서 바뀐 데다 권한 차이까지 겹쳐 Terraform 이 운영 GKE 클러스터 세 개 중 두 개를 삭제했다

   Spotify2019

   증상

   Terraform 이 아시아 운영 GKE 클러스터를 지웠다. 사내 서비스 디스커버리가 사라진 클러스터에 닿지 못하자 클러스터 운영 팀이 호출을 받았다.

   리소스 삭제

   촉발

   클러스터 운영 팀이 아시아 클러스터를 Terraform 상태 파일로 가져오는 PR 을 올렸고, 그 리뷰 빌드가 운영에 쓰이는 전역 상태 파일을 바꿨다. 그런데 이 PR 보다 클러스터 사용자의 PR 이 먼저 머지됐고, 그 PR 에는 아시아 클러스터 정의가 없었다. Terraform 은 정의에 없는 아시아 클러스터를 삭제했다.

   원인

   설정 변경

   구성 요소

   TerraformCI 시스템GKE 컨트롤 플레인

   기여 요인

   파괴적 변경 보호 장치 부재리뷰 누락미검증 가정

   감지

   사내 서비스 디스커버리가 사라진 클러스터에 닿지 못하자 클러스터 운영 팀이 호출을 받았다.

   조치

   • 서비스 디스커버리 설정에서 사라진 클러스터를 빼고 사내 서비스 디스커버리를 재시작해 파드 IP 를 백엔드 목록에서 지웠고, 트래픽을 쿠버네티스 밖 인스턴스로 넘겼다.
   • 쿠버네티스와 VM 에 반씩 나눠 돌던 한 팀이 부하를 받으려고 쿠버네티스 밖 VM 을 더 만들었다.
   • 미리 복원을 시험해 둔 클러스터 백업으로 삭제된 클러스터를 다시 만들었다.
   • 옛 클러스터 마스터 IP 를 하드코딩한 곳을 찾아 모두 새 값으로 고쳤다.

   후속 조치

   • 드라이런 결과를 PR 댓글로 달아 무엇이 바뀔지 바로 보이게 했다.
   • 머지 전에 브랜치가 최신 master 를 반영해야 하는 필수 상태 검사를 켜서, 드라이런이 실제로 일어날 일을 보여 주게 했다.
   • PR 머지에 승인 리뷰를 필수로 했다.
   • destroy 같은 키워드가 보이면 리뷰를 바로 실패시키고, 클러스터 삭제는 이 저장소 밖에서 손으로 하게 했다.
   • 클러스터 설정을 린터와 검증기로 검사하게 했다.
   • 일정을 미리 잡아 널리 알린 뒤, 클러스터가 사라지는 경우와 그보다 작은 실패를 다루는 재해 복구 훈련을 했다.

   교훈

   Terraform 은 상태 파일을 보고 할 일을 정한다. 리뷰 빌드가 운영 상태 파일을 바꾸게 두면 머지 순서 하나로 운영 리소스가 지워질 수 있다. 같은 리소스도 API 를 호출하는 권한에 따라 다른 속성으로 보이므로, 가져올 때와 관리할 때 권한이 다르면 Terraform 이 그 차이를 변경으로 읽는다. 처음부터 실패에 대비하고, 큰 인프라를 서서히 옮기고, 되돌릴 방법을 남겨 둔 덕분에 운영 클러스터 두 개가 사라져도 최종 사용자 영향이 없었다. 복원을 시험해 보지 않은 백업은 백업이 아니다. 실수를 누가 했는지보다 무엇을 배웠고 같은 종류의 실수를 어떻게 막을지가 중요하다.

   사례 보기

원인별1