사례3건
3건 중 1~3번째
- 증상
정기 회의 도중 고객 성공 팀이 관리 화면의 고객 목록이 열리지 않는다고 알렸고, 곧이어 고객 문의도 들어왔다. AWS 를 살펴보니 OpenSearch 가 red 상태였다.
- 원인
- 구성 요소
- 기여 요인
- 감지
정기 회의 도중 고객 성공 팀이 관리 화면의 고객 목록이 열리지 않는다고 알렸고, 이어서 고객 문의가 들어왔다. 엔지니어가 AWS 를 살펴보고 OpenSearch 가 red 상태인 것을 확인했다.
- 조치
- OpenSearch 노드를 재시작해 30분쯤 만에 장애를 일시적으로 풀었다.
- 노드 9개에 맞춰 이름에 날짜를 넣은 새 인덱스를 만들고, 샤드 9개, 레플리카 0개, refresh_interval -1 로 설정했다.
- reindex 로 옛 인덱스의 데이터를 새 인덱스에 복사하고, 끝난 뒤 두 인덱스의 문서 건수를 맞춰 보며 제대로 옮겨졌는지 확인했다.
- 복사가 끝난 뒤 number_of_replicas 를 1 로, refresh_interval 을 1s 로 바꿨다.
- 애플리케이션이 접속하는 별칭 customer_data 를 옛 인덱스에서 떼어 새 인덱스에 붙였다.
- 별칭을 바꾸기 전까지 옛 인덱스에 들어온 데이터를 가져오려고, 첫 reindex 작업을 실행한 시각 이후의 event.at 값만 고르는 조건을 걸어 reindex 를 한 번 더 실행했다.
- 교훈
글쓴이는 서비스가 커지면서 비기능 요건을 갖추는 일이 필요해졌다고 보고, 문제가 생기기 전에 미리 알맞게 대처하겠다고 했다. 인프라를 구축한 담당자가 이미 회사에 없어 인프라에 손대기가 부담스러웠다는 점도 함께 적었다.
IL-0277Elastic Cloud us-east-1 의 ZooKeeper 조정 계층이 쿼럼을 잃어 Elasticsearch 배포에 6시간 넘게 접속하지 못하고 Kibana 는 18:44 UTC 까지 불안정했다Elastic2019- 증상
2019년 2월 4일 02:50 UTC 무렵부터 AWS us-east-1 의 Elastic Cloud 고객이 클러스터에 접속하기 어려워졌고, 로드 밸런서에서 HTTP 5xx 오류가 늘었다. 고객 대부분은 Kibana 에도 접속하지 못했고, Elastic Cloud User Console 은 배포 목록을 볼 때 타임아웃이 늘었다.
- 촉발
2019년 2월 4일 AWS us-east-1 리전에서 조정 계층의 ZooKeeper 를 정기 패치하면서 02:25~02:45 에 앙상블 멤버 두 대를 패치한 호스트로 바꿨다.
- 원인
- 구성 요소
- 기여 요인
- 감지
Elastic 은 02:50 UTC 에 로드 밸런서에서 HTTP 5xx 오류가 늘어난 것을 확인했다.
- 조치
- 03:22 와 06:00 에 클라이언트 연결 문제를 줄이려고 내부 서비스를 일괄 재시작했다.
- 04:39 에 클라이언트 연결을 끊어 앙상블을 떼어 놓고 시스템을 안정시켰다.
- 04:46 에 호스트가 불안정해지자 남은 앙상블 멤버의 롤백을 시작했다.
- 05:25 에 호스트가 불안정해 두 번째 앙상블 멤버도 롤백하기 시작했다.
- runc 버그로 응답하지 않게 된 ZooKeeper 앙상블 멤버 두 대를 재부팅했다.
- 가능한 곳에서 클라이언트 부하를 걷어 내 앙상블이 안정될 시간을 준 뒤, 클라이언트 부하를 조금씩 다시 들여 쿼럼을 다시 세웠다.
- 프록시가 쓰는 ZooKeeper observer 계층의 initLimit 설정을 늘려 observer 계층을 안정시켰다.
- 늘어난 Elasticsearch 클러스터 트래픽을 받도록 프록시를 키우고 대수를 늘렸다.
- 내부 프록시 컨테이너와 Kibana 인스턴스를 재시작하고 sysctl 한도를 거는 런북을 만들어 적용했다.
- 후속 조치
- ZooKeeper 앙상블이 담는 데이터셋을 60% 넘게 줄였다.
- 정상으로 표시된 프록시 노드가 로드 밸런싱 대상에 들어가는 데 필요한 헬스 체크 횟수와 간격을 줄였다.
- 프록시 헬스 체크에서 ZooKeeper 연결 여부를 빼, 초기화를 마친 프록시가 ZooKeeper 상태 때문에 비정상이 되지 않게 한다.
- 프록시 서비스를 ZooKeeper 상태에서 떼어 낸 v2 구조의 프록시 계층을 운영 리전에서 카나리로 시험한다.
- 내부 로깅을 늘리고 ZooKeeper 프로세스, JVM, 컨테이너와 호스트 시스템의 지표를 더해 ZooKeeper 의 관측성을 높인다.
- Kibana 의 경로 탐색 방식을 더 튼튼하게 만든다.
- 가용성 사고 중에 Kibana 가 내부 HTTP 요청을 몇 배로 늘려 보내는 문제를 찾아 고친다.
- Kibana 의 연결 누수 문제를 찾아 고친다.
- 내부 모니터링 에이전트가 지터를 넣은 백오프를 제대로 쓰지 않던 문제를 찾아 완화했다.
- 문제가 생겨도 덜 중요한 시간대에 드러나도록, 유지보수 일정표를 정식으로 만들어 리전마다 정한 시간대에만 작업하게 했다.
- 조정 계층의 정기 유지보수를 다루는 런북에 더 나은 판단 기준표를 넣는다.
- 지원 창구와 상태 페이지로 나가는 안내를 두고 지원 리더십 팀과 피드백 루프를 만들었다.
- 교훈
서비스 지표가 호스트를 정상으로 보고해 유지보수를 이어 가도 된다는 신호를 줬지만, 그 지표로는 개별 호스트와 조정 계층 전체의 상태를 충분히 알 수 없었다. 다른 플랫폼 구성 요소가 조정 계층에 의존해서 조정 계층의 불안정과 쿼럼 상실이 큰 서비스 중단으로 번졌다. 원인을 찾는 동안 관련 없는 문제들을 만나 해결이 더 늦어졌고, 하나하나는 성공한 완화 조치도 장애의 규모 때문에 한동안 효과가 없었다.
- 증상
미국 동부 시각 2016년 7월 5일 오후 7시 12분, cloud.gov 의 로그 검색 서비스 logs.cloud.gov 에서 로그인 리디렉션 루프가 발견됐다. 사용자는 서비스에 로그인할 수 없었다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- logsearch 서비스의 Redis 를 훨씬 큰 메모리 인스턴스로 바꿔, Elasticsearch 클러스터가 내려가 있는 동안에도 로그를 계속 받아 두게 했다.
- Elasticsearch 설정에서 메모리 설정과 하드닝 스크립트 문제를 고치고 클러스터를 다시 배포했다.
- 클러스터 배포가 끝난 뒤 Kibana 인스턴스를 다시 배포하고 로그를 확인해 서비스를 되살렸다.
- 후속 조치
- 로그가 계속 들어오고 있는지 확인하고, 끊기면 울리는 장애 알림을 만든다.
- Redis 에 오토스케일링이나 고가용성을 갖춰, Redis 다음 단계에 있는 더 취약한 구성 요소가 실패해도 데이터를 잃지 않게 한다.
- 보안 사고가 아닌 사건도 다루도록 사고 대응 계획을 넓힌다.
- logs.cloud.gov 서비스에 카오스 봇을 만든다.
이 3건에서 가장 많이 나오는 구성 요소: Elasticsearch 와 OpenSearch, 인메모리 캐시. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.