사례2건

2건 중 1~2번째

1. IL-0544 Wasabi 전 리전의 S3 와 사용자 서비스에 이틀에 걸쳐 세 차례 장애가 났다

   Wasabi2024

   증상

   2024년 8월 6일 10:32 UTC 부터 Wasabi 전 리전에서 S3 와 사용자 서비스에 오류가 났다. 상태 페이지에는 10:56 UTC 에 Web Console 로그인 문제와 Wasabi 리전의 오류를 조사한다는 글이 올라왔다.

   서비스 중단장애 조치 실패간헐적 타임아웃

   촉발

   2024년 8월 6일 10:32 UTC 에 큐 서비스가 가득 찬 상태가 됐다.

   원인

   용량 한계

   구성 요소

   메시지 브로커인메모리 캐시데이터베이스

   기여 요인

   –

   조치

   • 운영팀이 데이터베이스에 남은 오래된 연결을 정리하려고 주 데이터베이스를 재시작했고, 동시에 큐 서비스의 큐를 비웠다. 이 조치로는 데이터베이스가 완전히 돌아오지 않았다.
   • 보조 데이터베이스 인스턴스를 주 인스턴스로 승격했고, 11:20 UTC 에 S3 서비스가 다시 정상이 됐다.
   • 8월 6일 13:17 UTC 부터 13:23 UTC 까지 큐 서비스 라이브러리를 데이터베이스에 완전히 반영하려고 데이터베이스를 한 번 더 재시작했다.
   • 8월 7일 두 번째 사건에서 원래의 주 데이터베이스를 다시 운영에 올려 사용자 서비스의 타임아웃을 풀었다.
   • 8월 7일 세 번째 사건에서 자동화 서비스가 보지 못하던 자동화 클러스터를 다시 만들어 배포했고, S3 서비스가 완전히 돌아왔다.

   사례 보기
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 안에 있어도 노드에 영향을 줄 수 있다.

   사례 보기

원인별1