사례3건

3건 중 1~3번째

1. IL-0141 Workload Identity 를 쓰는 GKE 클러스터에서 gke-metadata-server 가 "Unable to sync sandbox" 디버그 로그를 대량으로 내 Cloud Logging 할당량을 소모하고 추가 요금이 나왔다

   Google Cloud2023

   증상

   Workload Identity 를 켠 GKE 클러스터에서 애플리케이션 로그 양이 크게 늘었다. 늘어난 로그는 "Unable to sync sandbox" 문자열이 든 디버그 로그였고, Cloud Logging 으로 수집돼 수집 할당량을 소모했다. 월 무료 사용량을 넘긴 고객에게는 추가 요금이 나왔다.

   로그 폭증지연 시간 증가

   촉발

   gke-metadata-server 0.4.272 부터 0.4.280 까지의 버전에 잘못된 설정이 들어 있어 디버그 로그를 높은 빈도로 냈다. 11-02 공지는 이것을 버그라고 불렀다.

   원인

   소프트웨어 결함

   구성 요소

   파드용 자격 증명 중개자

   기여 요인

   –

   감지

   상태 페이지의 첫 공지는 2023-11-02 13:32 PDT 에 조사 중이라는 내용으로 올라왔다. 고객은 gke-metadata-server 데몬셋의 components.gke.io/component-version 어노테이션을 보고 자기 클러스터가 영향받는지 확인할 수 있었다.

   조치

   • 과도한 로그를 더 이상 Cloud Logging 으로 수집하지 않게 하는 수정을 GKE 전체 플릿에 배포했다.
   • Rapid 채널 고객에게 우회 방법으로 컨트롤 플레인을 1.28.2-gke.1157000 이상 또는 1.27.7-gke.1038000 이상으로 올리도록 안내했다.

   사례 보기
2. IL-0189 KIAM 이 준 15분짜리 AWS 자격 증명 때문에 쿠버네티스로 옮긴 Java 서비스가 요청마다 메타데이터 API 를 불러 지연이 최대 10배 늘었다.

   Adevinta2019

   증상

   마이크로서비스 하나를 쿠버네티스 기반 중앙 플랫폼에 배포하고 운영 트래픽 일부를 보내자 요청 지연이 EC2 보다 최대 10배 높게 나왔다. 백엔드 응답 시간이 EC2 에서는 약 20ms 였는데 쿠버네티스에서는 100~200ms 였다.

   지연 시간 증가

   촉발

   쿠버네티스로 옮긴 서비스가 KIAM 을 거쳐 받은 AWS 임시 자격 증명의 만료 시간이 정확히 15분이었다. AWS Java SDK 는 만료까지 15분 이내로 남은 자격 증명을 곧바로 새로 받는다.

   원인

   설정 변경

   구성 요소

   파드용 자격 증명 중개자

   기여 요인

   기본 설정 방치

   감지

   서비스를 쿠버네티스에 배포하고 운영 트래픽 일부를 보낸 뒤, 요청 지연이 EC2 보다 최대 10배 높게 나오는 것을 보고 알았다.

   조치

   • KIAM 이 더 긴 만료 시간으로 자격 증명을 요청하도록 설정을 바꿨다.

   교훈

   이번 지연은 쿠버네티스, KIAM, AWS Java SDK, 서비스 어느 쪽의 버그도 아니었다. 자격 증명을 일찍 갱신하는 SDK 의 정책과 짧은 만료 시간을 주는 KIAM 의 기본값은 따로 보면 둘 다 타당하지만, 함께 쓰면 요청마다 갱신이 일어난다. 마이그레이션에서 생기는 문제는 대개 처음 함께 붙여 본 구성 요소들이 만나는 지점에서 나온다. 따로따로 타당한 두 결정이 함께 쓰여도 타당하다는 보장은 없다.

   사례 보기
3. IL-0073 Kafka 연결이 끊기자 로깅 사이드카가 Docker 데몬에 부하를 주어 노드가 줄줄이 비정상이 되었고, 재스케줄링으로 생긴 노드 약 41,000개가 Consul gossip 메시를 오염시켜 Vault 와 배포 엔진까지 멈췄다

   Target2019sev1

   증상

   어느 저녁 데이터센터 OpenStack 의 네트워크 하위 시스템을 업그레이드한 뒤 Kafka 연결이 몇 시간 동안 간헐적으로 끊겼다. 개발 환경 워크로드 약 2,000개를 올린 큰 쿠버네티스 클러스터에서 노드들이 쿠버네티스에 비정상이라고 보고하기 시작했다.

   노드 NotReady부하 불균형지연 시간 증가자격 증명 획득 실패

   촉발

   OpenStack 의 네트워크 하위 시스템을 업그레이드하다가 예상과 달리 네트워크가 몇 시간 동안 끊겼고, Kafka 에는 간헐적으로만 닿았다. 그러자 모든 워크로드에 딸린 로깅 사이드카가 한꺼번에 깨어나 노드의 Docker 데몬에 높은 부하를 주었다.

   원인

   의존성 장애

   구성 요소

   컨테이너 런타임서비스 디스커버리텔레메트리 에이전트파드용 자격 증명 중개자

   기여 요인

   과도한 영향 범위자동화 증폭단일 장애점미패치 알려진 버그

   조치

   • Consul 의 gossip 암호화를 켜서 오염된 gossip 메시에서 오는 메시지를 바로 거부하게 했고, 이것으로 Consul 과 Vault 를 되살렸다.
   • 배포 엔진을 안정시킨 뒤 암호화 설정을 반영하려고 개발 환경 전체를 다시 배포했고, 암호화가 설정되지 않은 인스턴스는 종료했다.
   • 큰 클러스터를 다루는 수정이 들어간 Consul 1.2.3 으로 제자리 업그레이드했고, UI 버그 때문에 최종적으로 1.3.0 으로 올렸다. 운영 환경의 오염된 gossip 메시도 이 업그레이드로 빠르게 정리됐다.

   후속 조치

   • 노드의 워크로드가 함께 쓰는 Docker 데몬은 깨지기 쉬운 장애 지점이므로, 데몬 하나의 장애가 미치는 범위를 줄이는 데 더 힘쓴다. 작은 클러스터를 여러 개 두는 방침과 같은 방향이다.

   교훈

   글쓴이는 작은 클러스터를 여러 개 두라는 자신의 원칙이 옳았다고 확인했다. 더 작은 개발 클러스터와 운영 클러스터의 워크로드는 큰 클러스터처럼 영향을 받지 않았고, 개발과 운영이 한 클러스터에 있었다면 훨씬 큰 일이 났을 것이다. 노드의 워크로드가 함께 쓰는 Docker 데몬은 깨지기 쉬운 장애 지점이다. 워크로드마다 자기 로깅 사이드카와 메트릭 사이드카를 두는 방식이 옳다고도 확신하게 됐다. 이것들이 클러스터 공용 자원이었다면 문제가 거의 틀림없이 더 커졌고 고치기도 훨씬 어려웠을 것이다.

   사례 보기

원인별3