IL-0064 Moonlight · 2019-01-18kubernetesgcp
Moonlight 의 웹사이트와 API 가 1월 18일부터 22일까지 간헐적으로 멈췄다. 처음에는 가끔 나는 API 오류였지만 22일에는 서비스가 완전히 내려간 시간이 있었다. Moonlight 는 Google Cloud 의 관리형 쿠버네티스 클러스터를 쓴다.
팀은 처음에 Redis 연결 문제와 Google Cloud 의 네트워크 장애를 의심했다. 실제 패턴은 Google Cloud 지원팀이 찾아냈다. 노드 CPU 사용률이 100% 로 오래 이어지면 VM 이 커널 패닉으로 죽었다.
장애는 이렇게 되풀이됐다. 스케줄러가 CPU 를 많이 쓰는 파드 여러 개를 한 노드에 배치했다. 파드들이 노드 CPU 를 100% 썼고, 노드는 커널 패닉으로 한동안 스케줄러에 응답하지 않았다. 스케줄러는 죽은 파드를 모두 새 노드에 다시 배치했고, 그 노드에서 같은 일이 되풀이되며 피해가 커졌다.
Moonlight 는 노드 세 대에 웹 서비스마다 복제본 세 개를 돌렸다. 노드마다 하나씩 놓아 노드 두 대가 죽어도 버티게 하려는 의도였다. 그러나 쿠버네티스가 웹사이트 파드 세 개를 모두 한 노드에 배치하는 일이 있었고, 그 노드가 단일 장애점이 됐다. 서버 사이드 렌더링처럼 CPU 를 많이 쓰는 다른 애플리케이션도 같은 노드에 몰렸다. 팀은 주요 배포 전부에 안티 어피니티 규칙을 넣어 파드를 여러 노드로 흩었고, 웹사이트가 다시 살아났다. 노드 커널 패닉의 근본 원인은 Google 과 함께 계속 찾고 있다.
1월 18일 금요일, Moonlight API 가 가끔 오류를 냈다. 처음 오류는 Redis 데이터베이스와 연결이 안 되는 문제로 보였다. Moonlight API 는 인증된 요청마다 Redis 에서 세션을 확인한다.
쿠버네티스 모니터링은 일부 노드와 파드가 응답하지 않는다고 보고했다. 같은 시기에 Google Cloud 가 네트워크 서비스 장애를 알렸고, 팀은 그 장애가 원인이라고 생각했다.
주말에 트래픽이 줄자 오류는 가끔만 났다. 1월 22일 화요일 아침에는 웹사이트가 내려가 클러스터에 외부 트래픽이 하나도 들어오지 않았다. 팀은 트위터에서 비슷한 증상을 겪는 사람을 찾고는 Google 쪽 네트워크 장애라고 믿었고, Google Cloud 지원팀에 연락했다.
처음에는 Redis 파드만 죽었다. 시간이 지나면서 웹 트래픽을 받는 파드가 모두 내려가 서비스 전체가 멈췄다. 지수 백오프 규칙 때문에 다운타임은 갈수록 길어졌다.
원인 ? 용량 한계
API 오류가 가끔 나면서 문제가 드러났다. 쿠버네티스 모니터링이 일부 노드와 파드가 응답하지 않는다고 보고했다. 노드가 CPU 100% 상태에서 커널 패닉으로 죽는다는 패턴은 Google Cloud 지원팀이 찾아냈다.
복제본을 세 개 두어도 스케줄러가 한 노드에 몰아 놓으면 그 노드가 단일 장애점이 된다. 사용자에게 응답하는 서비스에는 안티 어피니티 규칙을 넣어 파드를 여러 노드에 나눠 놓아야 한다. 팀은 처음에 클라우드 업체의 네트워크 장애를 원인으로 짐작했지만 실제 원인은 노드의 CPU 포화와 커널 패닉이었다.
같은 원인 · 공통 파드 스케줄링과 배치, 애플리케이션 데이터베이스
같은 원인 · 공통 파드 스케줄링과 배치
같은 원인 · 공통 애플리케이션 데이터베이스
같은 원인 · 공통 애플리케이션 데이터베이스
같은 원인 · 공통 애플리케이션 데이터베이스
같은 원인 · 공통 리눅스 커널
같은 원인 · 공통 애플리케이션 데이터베이스
같은 원인 · 공통 파드 스케줄링과 배치