{"id":"IL-0575","org":"Sonicmoov","date":"2026-08-31","docs":["https://www.elastic.co/jp/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster","https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/bp-sharding.html"],"title":{"en":"Amazon OpenSearch cluster went red under high heap usage and the admin screen's customer list would not open","ko":"OpenSearch 의 힙 사용률이 치솟아 클러스터가 red 상태가 되고 관리 화면의 고객 목록이 열리지 않았다"},"domain":["database","aws"],"impact":{"scope":"The customer list in the admin screen could not be opened; the author describes the impact as service-wide","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"As the service scales, its non-functional parts need work, and the author wants to deal with them before they cause trouble.","ko":"글쓴이는 서비스가 커지면서 비기능 요건을 갖추는 일이 필요해졌다고 보고, 문제가 생기기 전에 미리 알맞게 대처하겠다고 했다. 인프라를 구축한 담당자가 이미 회사에 없어 인프라에 손대기가 부담스러웠다는 점도 함께 적었다."},"related":[],"sources":[{"url":"https://zenn.dev/sonicmoov/articles/db9cf58b3eb323","kind":"blog","archived":null}],"summary":{"en":"The service had scaled, and the amount of data in its customer index had grown with it. The old index had only 2 shards for about 80 million documents, so each shard held a large amount of data, and heap usage on the OpenSearch nodes rose sharply until the cluster went red. Restarting the OpenSearch nodes cleared the outage temporarily in about 30 minutes. Because the shortage of shards was likely to bring the outage back, the team then split the data over more shards.\n\nThe team created a new index whose name included the date, with 9 shards to match the 9 OpenSearch nodes, number_of_replicas 0 and refresh_interval \"-1\" during the copy. An asynchronous _reindex copied the old index into the new one, and the team compared document counts to confirm the copy. The team then set number_of_replicas to 1 and refresh_interval back to 1s, moved the customer_data alias that the application uses from the old index to the new one, and ran a second _reindex for the documents that had been written to the old index in the meantime. The person who had set up the infrastructure was no longer there, which made touching it daunting for the author.","ko":"서비스 규모가 커지면서 데이터 양이 늘었고, 고객 데이터 인덱스는 샤드 2개에 문서 약 8,000만 건을 담고 있었다. 샤드 수가 적어 샤드 하나에 들어가는 데이터가 많아졌고, 그 때문에 OpenSearch 의 힙 사용률이 치솟았다. 어느 날 관리 화면의 고객 목록이 열리지 않는다는 신고와 고객 문의가 들어왔고, OpenSearch 는 red 상태였다.\n\nOpenSearch 노드를 재시작하자 30분쯤 만에 장애가 일시적으로 풀렸다. 글쓴이는 샤드 부족이라는 근본 원인을 풀지 않으면 다시 날 가능성이 높다고 보고 샤드를 나누는 작업을 했다. 노드 수 9에 맞춰 샤드 9개짜리 새 인덱스를 만들고, reindex 로 옛 인덱스의 데이터를 복사한 뒤 문서 건수를 맞춰 봤다. 이어서 레플리카 수를 1 로, refresh_interval 을 1s 로 바꾸고, 애플리케이션이 접속하는 별칭을 새 인덱스로 옮겼다. 마지막으로 그사이 옛 인덱스에 들어온 데이터를 한 번 더 reindex 로 가져왔다."},"trigger":null,"severity":"unknown","symptoms":["service-unavailable","memory-pressure"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"Customer success reported that the customer list in the admin screen would not open, customer inquiries followed, and the AWS console showed the OpenSearch cluster red.","ko":"정기 회의 도중 고객 성공 팀이 관리 화면의 고객 목록이 열리지 않는다고 알렸고, 이어서 고객 문의가 들어왔다. 엔지니어가 AWS 를 살펴보고 OpenSearch 가 red 상태인 것을 확인했다."},"components":["elasticsearch-opensearch"],"root_cause":"capacity","remediation":[{"text":{"en":"Restarted the OpenSearch nodes, which cleared the outage temporarily in about 30 minutes","ko":"OpenSearch 노드를 재시작해 30분쯤 만에 장애를 일시적으로 풀었다."}},{"text":{"en":"Created a new index with 9 shards, one per OpenSearch node, with no replicas and refresh turned off during the copy","ko":"노드 9개에 맞춰 이름에 날짜를 넣은 새 인덱스를 만들고, 샤드 9개, 레플리카 0개, refresh_interval -1 로 설정했다."}},{"text":{"en":"Copied the old index into the new one with an asynchronous _reindex and compared document counts","ko":"reindex 로 옛 인덱스의 데이터를 새 인덱스에 복사하고, 끝난 뒤 두 인덱스의 문서 건수를 맞춰 보며 제대로 옮겨졌는지 확인했다."}},{"text":{"en":"Set number_of_replicas to 1 and refresh_interval back to 1s on the new index","ko":"복사가 끝난 뒤 number_of_replicas 를 1 로, refresh_interval 을 1s 로 바꿨다."}},{"text":{"en":"Moved the customer_data alias used by the application to the new index","ko":"애플리케이션이 접속하는 별칭 customer_data 를 옛 인덱스에서 떼어 새 인덱스에 붙였다."}},{"text":{"en":"Ran a second _reindex to copy documents written to the old index after the first copy","ko":"별칭을 바꾸기 전까지 옛 인덱스에 들어온 데이터를 가져오려고, 첫 reindex 작업을 실행한 시각 이후의 event.at 값만 고르는 조건을 걸어 reindex 를 한 번 더 실행했다."}}],"action_items":[],"contributing":["no-capacity-planning"],"recurrence_of":null,"symptoms_text":{"en":"During a regular meeting, Sonicmoov's customer success team reported that the customer list in the admin screen would not open, and customer inquiries arrived soon after. The author judged that the whole service was affected.\n\nIn the AWS console, the Amazon OpenSearch cluster behind the service showed red. Heap usage on the cluster had risen sharply.","ko":"정기 회의 도중 고객 성공 팀이 관리 화면의 고객 목록이 열리지 않는다고 알렸고, 곧이어 고객 문의도 들어왔다. AWS 를 살펴보니 OpenSearch 가 red 상태였다.\n\n글쓴이는 고객 문의까지 들어온 것을 보고 서비스 전체에 영향을 준 장애로 판단했다.\n\nOpenSearch 의 힙 사용률이 크게 올라 있었다. 고객 데이터 인덱스는 샤드 2개에 문서 약 8,000만 건을 담고 있어서, 샤드 하나에 들어간 데이터가 많았다."},"updated_at":"2026-11-14T12:34:22.192726Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0575","org_slug":"sonicmoov"}