사례13건

13건 중 3~7번째

1. IL-0192 Crossplane 컴포지션의 병합 정책 변경이 Service 타입을 ClusterIP 로 바꿔 클라우드 로드 밸런서가 지워지고 Grafana Cloud 서비스의 약 25%가 끊겼다.

   Grafana Labs2025

   증상

   2025년 2월 18일 08:41 UTC, Grafana Labs 의 애플리케이션 팀 여러 곳이 자기 엔드포인트 일부에 접속이 되지 않는 것을 알아챘다.

   서비스 중단리소스 삭제

   촉발

   로드 밸런서의 TLS 정책 버전을 올리면서, 기본 TLS 정책을 덮어쓸 수 있도록 Crossplane 컴포지션의 병합 정책을 바꾼 변경이 개발, 스테이징, 운영 환경에 동시에 적용됐다.

   원인

   설정 변경

   구성 요소

   설정 템플릿클라우드 로드 밸런서

   기여 요인

   미검증 가정단계적 배포 부재과도한 영향 범위파괴적 변경 보호 장치 부재

   감지

   08:41 UTC 에 애플리케이션 팀 여러 곳이 자기 엔드포인트 일부에 접속이 되지 않는 것을 알아챘다. 조사해 보니 최근의 TLS 정책 설정 변경 때문에 그 엔드포인트의 로드 밸런서가 사라져 있었다.

   조치

   • 문제의 코드 변경을 롤백했다.
   • 영향받은 쿠버네티스 Service 를 다시 만들어 쿠버네티스가 로드 밸런서를 새로 만들게 했다.

   후속 조치

   • 한 번에 두 개 이상의 웨이브로 배포하는 것을 막는 CI 검사를 넣어, 개발에서 스테이징, 카나리, 운영으로 이어지는 순서를 벗어나는 배포를 잡아내게 했다.
   • 논의만 하던 더 정교한 웨이브 설계의 우선순위를 올려 개선안을 합의하고 구현한다.
   • 실수로 지워지지 않도록 로드 밸런서에 삭제 보호를 켜기 시작했다. Crossplane 수준의 삭제 보호보다 한 층 아래에서 막는다.
   • 로드 밸런서 말고도 중요한 클라우드 리소스를 하나씩 살펴 필요한 곳에 삭제 보호를 켠다.
   • 변경 검증과 가시성을 높이려고 만든 Crossplane Managed Resources exporter 를 플랫폼 엔지니어링 안에서 베타로 시험하고 있다. 이번 장애를 일으킨 변경에 적용해 보면 차이가 분명히 드러난다.
   • TLS 정책을 다시 설정하는 기능을 제대로 완성하고 시험해, 애플리케이션 팀이 배포할 수 있게 했다.

   교훈

   작은 변경이라 위험이 낮다고 가정하고 충분한 시험과 영향 범위 줄이기를 건너뛴 것이 장애로 이어졌다. 웨이브 배포는 절차로 기대하는 데 그치지 않고 시스템이 강제해야 한다. 비상 예외는 웨이브를 고르지 않았을 때의 기본 동작이 아니라 말 그대로 예외여야 한다. 이번 변경은 시험을 안 한 것이 아니라 시험한 범위가 충분하지 않았다. 클라우드 로드 밸런서 컨트롤러와 자체 도구까지 처음부터 끝까지 돌려 봐야 의도한 작은 변화만 일어나는지 알 수 있었다. 개발 웨이브부터만 적용하도록 강제했다면 제대로 시험할 수밖에 없었을 것이다.

   사례 보기
2. IL-0244 EKS 서브넷의 라우팅 테이블 연결이 사라져 live 클러스터의 Cloud Platform 서비스에 접근할 수 없었다

   UK Ministry of Justice2024

   증상

   2024년 9월 20일 11:24 에 live 클러스터 서비스를 감시하는 Pingdom 에서 우선순위 높은 알림이 울렸고, 사용자들은 서비스 주소를 찾을 수 없다고 알려 왔다.

   서비스 중단네트워크 도달 불가리소스 삭제

   촉발

   11:21 에 infrastructure-vpc-live-1 파이프라인의 일시 정지를 풀자, 팀이 미처 알아보지 못한 채 대기열에 있던 PR 이 자동으로 실행돼 EKS 서브넷 라우팅 테이블 연결을 지웠다.

   원인

   운영 실수

   구성 요소

   TerraformCI 시스템VPC 라우팅 테이블과 방화벽 규칙

   기여 요인

   파괴적 변경 보호 장치 부재

   감지

   11:24 에 live 클러스터 서비스를 감시하는 Pingdom 이 Cloud Platform 팀에 우선순위 높은 알림을 보냈다. 11:26 부터는 사용자들이 #ask 채널에 서비스를 쓸 수 없다고 알려 왔다.

   조치

   • 11:32 에 Cloud Platform 팀이 로컬에서 terraform apply 를 다시 실행해 서브넷 라우팅 테이블 연결을 다시 만들었고, 서비스를 쓸 수 있게 됐다.

   후속 조치

   • 인프라 파이프라인을 멈추고 다시 켜는 절차를 검토하고 고쳐, 팀원 모두가 파이프라인을 멈추고 다시 켰을 때의 영향을 알게 한다.
   • 인프라를 손으로 고치는 동안 대기열의 PR 실행을 멈출 방법을 찾는다.
   • 인프라 파이프라인의 plan 작업과 apply 작업을 더 잘 격리할 방법을 찾는다.

   사례 보기
3. IL-0152 정비 작업 중 FRA1 내부 인프라 클러스터에 잘못된 설정이 들어가 그 위에서 돌던 DOKS 클러스터 200개의 컨트롤 플레인이 자동으로 삭제됐다.

   DigitalOcean2024

   증상

   2024-01-23 13:02 UTC 에 DigitalOcean 은 12:18 UTC 부터 FRA1 리전의 쿠버네티스 클러스터 문제를 조사하고 있다고 공지했다. 사용자는 FRA1 클러스터와 통신할 때 오류를 겪을 수 있었다.

   리소스 삭제컨트롤 플레인 무응답

   촉발

   정비 작업 중 FRA1 내부 인프라 클러스터에 잘못된 설정 변경이 실수로 적용됐다.

   원인

   설정 변경

   구성 요소

   etcd쿠버네티스 API 서버

   기여 요인

   자동화 증폭파괴적 변경 보호 장치 부재과도한 영향 범위

   감지

   13:02 UTC 의 첫 상태 페이지 공지는 12:18 UTC 부터 조사 중이라고 했다. 사후 보고서의 타임라인에서는 12:36 에 잘못된 설정을 원인으로 확인했다.

   조치

   • 영향받은 클러스터마다 가장 최근 백업으로 etcd 클러스터를 되살렸다.
   • etcd 를 되살린 뒤 상태가 없는 컨트롤 플레인 컴포넌트를 다시 올려 컨트롤 플레인 복구를 마쳤다.
   • 13:00 에 복구 중 예상하지 못한 문제가 생기자 복구 메커니즘을 추가로 패치했고, 15:00 에 문제를 모두 해결했다.
   • 복구 도중 추가로 발견한 작은 버그를 고쳤다.
   • 고객지원팀이 영향받은 고객에게 직접 연락해 다음 조치를 안내했다.

   후속 조치

   • 운영 환경에서 어떤 경우에도 인프라 클러스터 자원이 자동으로 삭제되지 않게 막는 수정을 배포했다.

   교훈

   컨트롤 플레인을 받치는 인프라 클러스터의 설정 변경 하나가 한 리전의 DOKS 클러스터 200개의 컨트롤 플레인을 한꺼번에 지웠다. 하루 두 번 받아 둔 etcd 백업으로 클러스터를 되살릴 수 있었지만, 컨트롤 플레인 데이터는 백업 주기만큼, 최대 12시간 전 상태로 돌아갔다. 컨트롤 플레인이 사라진 동안에도 노드의 워크로드는 계속 돌았다.

   사례 보기
4. 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시간 안에 복구할 수 있다는 것을 이번에 확인했다. 그 바탕은 여러 해 동안 함께 해 온 아키텍처 정의, 인프라 구축, 데이터 백업 작업이라고 했다.

   사례 보기
5. IL-0207 로컬 개발 환경에서 돌린 작업이 운영 컨텍스트로 넘어가 Kubernetes 클러스터의 Consul 릴리스를 통째로 지웠고, Patroni 가 무너져 GitLab.com 전체가 5XX 오류를 냈다.

   GitLab2022

   증상

   모니터링과 알림이 곧바로 울렸다. 알림 하나는 Patroni 페일오버를 가리켰다. GitLab.com 으로 가는 트래픽은 모두 5XX 오류로 끝났다.

   서비스 중단오류율 상승리소스 삭제

   촉발

   엔지니어가 로컬 개발 환경에서 사내 도구로 일상적인 작업을 돌렸다. 로컬 배포나 롤백 도중 컨텍스트가 로컬 개발에서 운영으로 바뀌었고, 이때 잘 알려진 오픈소스 도구가 예상하지 못한 동작을 해 운영 환경에 변경이 들어갔다.

   원인

   운영 실수

   구성 요소

   데이터베이스

   기여 요인

   파괴적 변경 보호 장치 부재

   감지

   모니터링과 알림 인프라가 곧바로 경보를 보냈다. 팀은 Consul 클러스터가 내려가 Patroni 클러스터에 영향을 주자마자 큰 장애가 난 것을 알았고, 근본 원인도 몇 분 안에 찾았다.

   조치

   • 지워진 Consul 릴리스를 운영에 다시 적용했다. Consul 클러스터가 올라오자 데이터베이스 클러스터가 회복했다.

   후속 조치

   • Kubernetes 배포 방식을 개선해 로컬 환경에서 운영 환경을 대상으로 위험한 배포 작업이 돌아갈 가능성을 줄인다. 개념 검증은 reliability 이슈 16875 에서 진행한다.
   • Teleport 를 Kubernetes 클러스터와 연동한다. 이렇게 하면 SRE 에게 기본으로 읽기 전용 역할을 줄 수 있어 실수로 운영 환경을 바꿀 위험이 줄어든다.

   교훈

   로컬 개발 환경에서 운영 클러스터에 접근할 수 있으면 도구가 컨텍스트를 예상과 다르게 바꾸는 순간 일상 작업이 운영 장애가 된다. GitLab 은 Kubernetes 배포 방식을 개선하고, Teleport 로 SRE 의 기본 권한을 읽기 전용으로 둘 수 있게 하면 이런 위험이 크게 줄어든다고 봤다. 알림과 원인 파악은 빨랐다. 지워진 릴리스를 다시 배포하는 데는 손으로 해야 할 일이 있었지만 비교적 빨리 끝났다.

   사례 보기

원인별3