사례7건

7건 중 6~7번째

1. IL-0202 갑자기 몰린 쿼리와 데이터베이스 쓰기로 Honeycomb 수집 호스트가 메모리 부족으로 죽었고, 쿠버네티스 CrashLoopBackOff 가 용량 회복을 막아 US1 이벤트 수집이 한 시간 넘게 불안정했다

   Honeycomb2023sev1

   증상

   02:15 UTC 무렵부터 API 수집 엔드포인트의 이벤트 처리가 느려졌다. 실패는 났다가 멎기를 되풀이했고, 끝내 몇 분 동안 수집이 완전히 멈췄다. 기본으로 걸어 둔 알림이 수집 성능과 안정성 문제를 온콜 엔지니어에게 알렸다. 상태 페이지 첫 공지는 수집 서비스의 오류율과 응답 시간이 평소보다 높다는 알림을 조사하고 있다는 내용이었다.

   오류율 상승지연 시간 증가컨테이너 재시작 반복서비스 중단데이터베이스 과부하

   촉발

   몇 분 사이에 여러 곳에 흩어진 연결에서 비정상적으로 많은 쿼리가 들어왔다.

   원인

   용량 한계

   구성 요소

   데이터베이스인메모리 캐시

   기여 요인

   재시도 폭주자동화 증폭

   감지

   기본으로 걸어 둔 알림이 수집 성능과 안정성 문제를 온콜 엔지니어에게 알렸다. 자동 로드 셰딩 장치도 작동하면서 알림을 더 보냈다. 상태 페이지 첫 공지는 18:28 PST 에 올라왔다.

   조치

   • 엔지니어들이 용량을 확보하려고 수집 호스트 수를 수동으로 크게 늘렸다.
   • 몇 분 동안 수집 트래픽 대부분을 끊고 수집 호스트 용량을 다시 확보했다.
   • 가장 공격적으로 트래픽을 보내던 발신처의 속도 제한을 트래픽이 가라앉을 때까지 임시로 낮춰 클러스터를 안정시켰다.

   후속 조치

   • 장기 해결책을 마련하는 동안 같은 장애가 반복되지 않도록 수집 호스트 수를 늘려 두었다.
   • 이번 장애 경로를 막을 프로젝트를 정하는 일에 집중한다.

   교훈

   Honeycomb 은 이번 장애를 이미 대비책이 있던 장애의 변형으로 보았다. 이번 장애는 그 대비책 일부를 비켜 가는 방식으로 일어났다. 실패했던 호스트들이 쿠버네티스의 CrashLoopBackOff 상태에 걸려 오프라인으로 남으면서 급하게 늘린 용량을 깎아 먹었다. OTel 처럼 배치 단위로 성공과 실패를 알리는 프로토콜에서는 서버가 일부만 버려도 클라이언트가 배치 전체를 다시 보내 트래픽이 크게 불어날 수 있다.

   사례 보기
2. IL-0386 Google Cloud 로 옮긴 뒤 GKE 노드에서 Postgres 연결 타임아웃과 memcached i/o timeout 이 간헐적으로 튀었다

   incident.io2023

   증상

   인프라를 Google Cloud 로 모두 옮긴 뒤 Postgres 연결 타임아웃이 평소보다 많이 나서 인시던트를 선언했다. 초당 새로 여는 연결 수가 수백 개 수준에서 크게 오르내렸다.

   간헐적 타임아웃패킷 손실

   촉발

   노드에서 짧게 열고 닫는 TCP 연결이 대량으로 생겼다. 연결 풀이 초당 수백 개씩 새 연결을 열었고, 실수로 들어간 데이터베이스 join 때문에 외부 제3자 서비스로 가는 중복 호출 수천 번이 한꺼번에 나갔다.

   원인

   용량 한계

   구성 요소

   CNI 플러그인데이터베이스인메모리 캐시

   기여 요인

   기본 설정 방치장애 중첩

   감지

   Postgres 연결 타임아웃이 평소보다 많이 나는 것을 보고 인시던트를 선언했다.

   조치

   • Postgres 연결의 최대 수명을 15m 에서 30m 로 두 배 늘렸다.
   • 연결 풀을 늘 N개의 연결을 열어 두는 고정 크기로 바꿨다.
   • memcache 클라이언트의 MaxIdleConns 를 2 에서 20 으로 올렸다.
   • 변수를 줄이려고 Google 이 운영하는 memcached 대신 쿠버네티스 클러스터 안에서 직접 돌리는 memcached 로 옮겼다. 이 전환으로는 거의 달라지지 않았다.
   • 실수로 들어간 데이터베이스 join 때문에 외부 제3자 서비스로 중복 호출을 수천 번 보내던 문제의 수정을 운영에 배포했다. 그 뒤 데이터베이스 연결 문제와 캐시 문제가 거의 사라졌다.

   후속 조치

   • 외부로 나가는 네트워크 호출에 더 알맞은 동시성 한도를 둔다. 공급자의 rate limit 안에 있어도 노드에 영향을 줄 수 있기 때문이다.

   교훈

   가설을 너무 빨리 좁히지 않는다. 이런 네트워크 타임아웃을 보면 같은 파드만이 아니라 같은 노드에서 도는 모든 것을 포함해 시스템 전체의 활동을 봐야 한다. 오류와 그 영향은 대개 요청 하나에 머물지만 늘 그렇지는 않다. 외부로 나가는 네트워크 호출의 동시성도 제한해야 한다. 이전에는 공급자의 rate limit 이 주된 제약이었지만, rate limit 안에 있어도 노드에 영향을 줄 수 있다.

   사례 보기

원인별3