IL-0192 Grafana Labs · 2025-02-18kubernetesnetworking
한 엔지니어가 메트릭과 로그 수집을 포함한 여러 서비스가 쓰는 로드 밸런서의 TLS 정책 버전을 올리고 있었다. 개발 환경에서 설정을 바꾸고 손으로 시험해, 로드 밸런서를 다시 배포하지 않고도 바꿀 수 있다는 것을 확인했다. Grafana Labs 는 클라우드 리소스 상당수를 쿠버네티스 위의 Crossplane 으로 관리한다. 엔지니어는 기본 TLS 정책을 덮어쓸 수 있도록 Crossplane 컴포지션의 병합 정책을 바꿨고, Crossplane 이 설정을 다시 맞춘 뒤에도 덮어쓴 값이 남아 있는 것을 보고 충분히 시험했다고 판단했다. 원래는 개발 환경에서 전체 재배포와 시험을 했어야 했다.
이 변경은 기본 설정에 있던 기본값 하나까지 의도치 않게 덮어썼다. 그 결과 쿠버네티스 Service 여러 개의 타입이 LoadBalancer 에서 ClusterIP 로 바뀌었고 쿠버네티스가 그 로드 밸런서를 지웠다. Grafana Labs 는 평소 변경을 웨이브라고 부르는 단계로 나눠 개발, 스테이징, 운영 카나리, 운영 전체 순으로 배포하고, 웨이브마다 보통 24시간 이상 지켜본다. 이번 변경도 PR 리뷰를 거쳤지만, 웨이브를 고르는 플래그 없이 나가면 웨이브 없이 배포되는 구조였다. 개발 환경 적용도 자동화 절차가 아니라 손으로 했기 때문에 Crossplane 오퍼레이터가 Service 를 바꾸는 동작을 미리 보지 못했다. 시스템은 개발, 스테이징, 운영 환경을 한꺼번에 바꾸는 것을 막지 않았다.
팀은 코드 변경을 롤백하고 영향받은 Service 를 다시 만들어 쿠버네티스가 로드 밸런서를 새로 만들게 했고, 11:10 UTC 에 대부분의 애플리케이션을 복구했다. 장애는 약 150분 이어졌다. 보안 사고는 아니었고 고객 데이터가 새거나 노출되지 않았다.
2025년 2월 18일 08:41 UTC, Grafana Labs 의 애플리케이션 팀 여러 곳이 자기 엔드포인트 일부에 접속이 되지 않는 것을 알아챘다.
조사해 보니 그 엔드포인트 앞에 있던 로드 밸런서가 사라져 있었다. 쿠버네티스 Service 여러 개의 타입이 LoadBalancer 에서 ClusterIP 로 바뀌어 있었고, 쿠버네티스가 그에 딸린 클라우드 로드 밸런서를 지운 것이었다. 메트릭과 로그 수집 엔드포인트를 포함해 Grafana Cloud 서비스의 약 25%가 영향을 받았다.
Crossplane 리소스는 지워지지 않고 그대로 남아 있었다. 그래서 Crossplane 수준에 걸어 둔 삭제 보호도 막지 못했다. 리소스는 남은 채 그 아래의 객체만 잘못된 상태로 바뀌었다.
장애 동안 데이터를 버퍼에 쌓아 두지 못하는 에이전트를 쓰던 고객은 수집되기 전의 메트릭이나 로그 일부를 잃었을 수 있다.
원인 ? 설정 변경
08:41 UTC 에 애플리케이션 팀 여러 곳이 자기 엔드포인트 일부에 접속이 되지 않는 것을 알아챘다. 조사해 보니 최근의 TLS 정책 설정 변경 때문에 그 엔드포인트의 로드 밸런서가 사라져 있었다.
작은 변경이라 위험이 낮다고 가정하고 충분한 시험과 영향 범위 줄이기를 건너뛴 것이 장애로 이어졌다. 웨이브 배포는 절차로 기대하는 데 그치지 않고 시스템이 강제해야 한다. 비상 예외는 웨이브를 고르지 않았을 때의 기본 동작이 아니라 말 그대로 예외여야 한다. 이번 변경은 시험을 안 한 것이 아니라 시험한 범위가 충분하지 않았다. 클라우드 로드 밸런서 컨트롤러와 자체 도구까지 처음부터 끝까지 돌려 봐야 의도한 작은 변화만 일어나는지 알 수 있었다. 개발 웨이브부터만 적용하도록 강제했다면 제대로 시험할 수밖에 없었을 것이다.
같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 설정 템플릿
같은 원인 · 공통 설정 템플릿
같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 설정 템플릿
같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 클라우드 로드 밸런서