Incident Library

IL-0277 Elastic · 2019-02-04databaseaws

Elastic Cloud us-east-1 의 ZooKeeper 조정 계층이 쿼럼을 잃어 Elasticsearch 배포에 6시간 넘게 접속하지 못하고 Kibana 는 18:44 UTC 까지 불안정했다

Elastic Cloud 백엔드는 세 계층으로 이루어진다. allocator 계층은 리전마다 Elasticsearch 와 Kibana 인스턴스를 올린다. 조정 계층은 세 노드짜리 Apache ZooKeeper 앙상블로, 시스템 상태와 각 클러스터 노드의 위치를 담는다. 나머지 하나가 프록시 계층이다. 프록시 계층은 클러스터의 가상 호스트 이름으로 트래픽을 보내는 프록시·라우팅 계층과, 조정 계층의 부하를 덜려고 그 복제본을 두는 ZooKeeper observer 계층으로 나뉜다. Kibana 같은 서비스는 allocator 호스트마다 도는 보조 컨테이너로 TLS 를 써서 Elasticsearch 클러스터와 통신한다.

2월 4일 us-east-1 에서 조정 계층을 정기 패치했다. 다른 12개 리전과 같은 문서화된 절차였다. 서비스 지표도 호스트가 정상이라고 보고했지만, 그 지표로는 개별 호스트와 조정 계층 전체의 상태를 알 수 없었다. 멤버 두 대를 바꾼 뒤 앙상블에 부하가 걸렸고, 02:50 에 리더가 들어오는 연결을 감당하지 못하고 종료되면서 앙상블이 쿼럼을 잃었다. 다른 플랫폼 구성 요소가 조정 계층에 의존하므로 이 일은 큰 서비스 중단으로 번졌다. 팀은 내부 서비스를 일괄 재시작했고, 03:31 에 쿼럼이 안정되자 마지막 멤버 패치를 이어 갔다. 그러나 호스트가 불안정해져 앙상블을 클라이언트 연결에서 떼고 두 멤버를 롤백했다. 이 과정에서 TLS 프록시 컨테이너의 네트워크 네임스페이스에 들어갈 때 runc 가 kernel OOPS 와 CPU softlock 을 일으키는 처음 보는 버그를 만나 호스트를 재부팅해야 했다. 07:10 에 클라이언트 부하와 운영자의 디버깅 작업을 줄여 쿼럼을 안정시키고 07:17 에 트래픽과 고객 컨트롤 플레인을 되살렸다.

그 뒤 외부 재연결이 몰려 프록시 계층과 observer 계층이 불안정해졌다. 팀은 팔로워가 리더에 연결해 동기화할 수 있는 시간을 정하는 initLimit 설정을 늘려 observer 계층을 안정시켰다. 09:19 에는 프록시를 늘려 3배로 늘어난 요청을 받았다. 09:28 에 Elasticsearch 배포 접속이 돌아왔다. Kibana 는 더 오래 망가져 있었다. 내부 TLS 프록시가 요청을 넘기지 못했고, Kibana 가 실패한 소켓을 닫지 않아 nf_conn_track 테이블이 가득 찼다. 12:30 에 내부 프록시 컨테이너와 Kibana 인스턴스를 재시작하고 sysctl 한도를 거는 런북을 만들어 적용했고, 18:44 에 Kibana 접속이 완전히 돌아왔다. 조사에서 Kibana 의 연결 누수와, 로드 밸런싱 계층으로 HTTP 요청을 몇 배로 늘려 보내는 버그들이 새로 드러났다. us-east-1 고객 100% 가 영향을 받았다.

심각도
–
영향 범위
Elastic Cloud in AWS us-east-1: Elasticsearch deployments partially or completely unavailable from 02:50 to 09:28 UTC, cluster create, modify and delete unavailable while ZooKeeper was down from 02:50 to 07:17 UTC, User Console degraded until 07:17 UTC, Kibana disrupted until 18:44 UTC
영향 사용자
100% of customers in us-east-1
지역
us-east-1
감지까지
0m
복구까지
15h 54m

증상

2019년 2월 4일 02:50 UTC 무렵부터 AWS us-east-1 의 Elastic Cloud 고객이 클러스터에 접속하기 어려워졌고, 로드 밸런서에서 HTTP 5xx 오류가 늘었다. 고객 대부분은 Kibana 에도 접속하지 못했고, Elastic Cloud User Console 은 배포 목록을 볼 때 타임아웃이 늘었다.

조정 계층의 ZooKeeper 앙상블 멤버 두 대를 패치한 호스트로 바꾼 직후인 02:45 에 앙상블에 CPU, IO, 메모리 부하가 크게 걸렸고 클라이언트 연결 실패와 재연결이 많이 일어났다. 몇 분 뒤 부하, 미처리 요청 수, 연결 실패가 줄어 안정된 것처럼 보였다.

02:50 에 앙상블이 리더 선출을 했다. 로그에는 리더가 들어오는 연결을 감당하지 못하고 종료됐다고 남았다. 앙상블은 들어오는 요청 부하 때문에 쿼럼을 빨리 다시 세우지도, 유지하지도 못했다. 앙상블 내부의 지연이 늘자 클라이언트가 더 재연결했고 프록시용 ZooKeeper observer 계층도 불안정해졌다.

03:31 에 쿼럼이 안정되자 팀은 마지막 멤버의 패치를 이어 가기로 했지만, 04:15 에 그 멤버가 시스템 수준에서 응답하지 않았다. 05:48 에는 처음 보는 runc 버그로 앙상블 멤버 두 대에 CPU softlock 이 생겨 시스템이 응답하지 않았다. 팀은 06:45 에 TLS 프록시 서비스 컨테이너의 네트워크 네임스페이스에 들어갈 때 runc 가 kernel OOPS 와 몇 분씩 이어지는 CPU softlock 을 일으킨다는 것을 찾았다.

07:17 에 트래픽을 다시 받은 뒤에는 외부 재연결이 몰려 프록시 계층 부하가 높아졌다. 그 때문에 프록시용 ZooKeeper observer 계층이 불안정해져 고객은 여전히 클러스터에 접속하지 못했다. 프록시 계층으로 오는 요청은 3배로 늘었다.

09:28 에 Elasticsearch 배포 접속이 돌아온 뒤에도 Kibana 호스트의 CPU 사용량이 평소보다 훨씬 높았고, 주된 원인은 내부 TLS 프록시 서비스였다. 내부 TLS 프록시가 요청을 프록시 계층으로 넘기지 못해 Kibana 가 Elasticsearch 클러스터에 연결하지 못했다. Kibana 는 연결에 실패한 뒤 소켓을 닫지 않아 열린 소켓이 한없이 늘었다. 그 때문에 nf_conn_track 테이블이 가득 차 내부 프록시 컨테이너에 큰 부담이 됐다.

증상 오류율 상승서비스 중단간헐적 타임아웃노드 커널 패닉

원인

원인 소프트웨어 결함

구성 요소 코디네이션 키-값 저장소컨테이너 런타임리눅스 커널Elasticsearch 와 OpenSearchconntrack 테이블
기여 요인 모니터링 사각지대재시도 폭주의존성에 묶인 헬스 체크장애 중첩수동 조치 악화
촉발
2019년 2월 4일 AWS us-east-1 리전에서 조정 계층의 ZooKeeper 를 정기 패치하면서 02:25~02:45 에 앙상블 멤버 두 대를 패치한 호스트로 바꿨다.

감지

Elastic 은 02:50 UTC 에 로드 밸런서에서 HTTP 5xx 오류가 늘어난 것을 확인했다.

조치

후속 조치

교훈

서비스 지표가 호스트를 정상으로 보고해 유지보수를 이어 가도 된다는 신호를 줬지만, 그 지표로는 개별 호스트와 조정 계층 전체의 상태를 충분히 알 수 없었다. 다른 플랫폼 구성 요소가 조정 계층에 의존해서 조정 계층의 불안정과 쿼럼 상실이 큰 서비스 중단으로 번졌다. 원인을 찾는 동안 관련 없는 문제들을 만나 해결이 더 늦어졌고, 하나하나는 성공한 완화 조치도 장애의 규모 때문에 한동안 효과가 없었다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 코디네이션 키-값 저장소, 컨테이너 런타임, 리눅스 커널. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.