Incident Library

IL-0575 Sonicmoov · 2026-08-31 (게시일)databaseaws

OpenSearch 의 힙 사용률이 치솟아 클러스터가 red 상태가 되고 관리 화면의 고객 목록이 열리지 않았다

서비스 규모가 커지면서 데이터 양이 늘었고, 고객 데이터 인덱스는 샤드 2개에 문서 약 8,000만 건을 담고 있었다. 샤드 수가 적어 샤드 하나에 들어가는 데이터가 많아졌고, 그 때문에 OpenSearch 의 힙 사용률이 치솟았다. 어느 날 관리 화면의 고객 목록이 열리지 않는다는 신고와 고객 문의가 들어왔고, OpenSearch 는 red 상태였다.

OpenSearch 노드를 재시작하자 30분쯤 만에 장애가 일시적으로 풀렸다. 글쓴이는 샤드 부족이라는 근본 원인을 풀지 않으면 다시 날 가능성이 높다고 보고 샤드를 나누는 작업을 했다. 노드 수 9에 맞춰 샤드 9개짜리 새 인덱스를 만들고, reindex 로 옛 인덱스의 데이터를 복사한 뒤 문서 건수를 맞춰 봤다. 이어서 레플리카 수를 1 로, refresh_interval 을 1s 로 바꾸고, 애플리케이션이 접속하는 별칭을 새 인덱스로 옮겼다. 마지막으로 그사이 옛 인덱스에 들어온 데이터를 한 번 더 reindex 로 가져왔다.

심각도
–
영향 범위
The customer list in the admin screen could not be opened; the author describes the impact as service-wide
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

정기 회의 도중 고객 성공 팀이 관리 화면의 고객 목록이 열리지 않는다고 알렸고, 곧이어 고객 문의도 들어왔다. AWS 를 살펴보니 OpenSearch 가 red 상태였다.

글쓴이는 고객 문의까지 들어온 것을 보고 서비스 전체에 영향을 준 장애로 판단했다.

OpenSearch 의 힙 사용률이 크게 올라 있었다. 고객 데이터 인덱스는 샤드 2개에 문서 약 8,000만 건을 담고 있어서, 샤드 하나에 들어간 데이터가 많았다.

증상 서비스 중단메모리 압박

원인

촉발
–

감지

정기 회의 도중 고객 성공 팀이 관리 화면의 고객 목록이 열리지 않는다고 알렸고, 이어서 고객 문의가 들어왔다. 엔지니어가 AWS 를 살펴보고 OpenSearch 가 red 상태인 것을 확인했다.

조치

후속 조치

–

교훈

글쓴이는 서비스가 커지면서 비기능 요건을 갖추는 일이 필요해졌다고 보고, 문제가 생기기 전에 미리 알맞게 대처하겠다고 했다. 인프라를 구축한 담당자가 이미 회사에 없어 인프라에 손대기가 부담스러웠다는 점도 함께 적었다.

출처

참고 문서

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: Elasticsearch 와 OpenSearch. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

AI 도구와 스크립트용

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