OpenSearch 최적화: 샤드 구성 및 JVM 힙 메모리 관리 가이드

출처: https://d2908q01vomqb2.cloudfront.net/2a459380709e2fe4ac2dae5733c73225ff6cfee1/2024/04/26/Picture2-3.jpg

📌 개요

OpenSearch(Elasticsearch 포함)는 대규모 데이터를 효율적으로 처리하기 위해 다양한 최적화 전략이 필요합니다. 특히 샤드(shard) 구성과 JVM 힙 메모리 관리는 성능에 직접적으로 영향을 미치는 중요한 요소입니다.

본 글에서는 OpenSearch의 샤드 설정과 JVM 힙 메모리 구성 방법에 대한 실질적인 가이드를 제시합니다.

---

📌 용어 정리

먼저 기본적인 용어부터 정리하겠습니다.

• Index (인덱스): 데이터를 저장하고 관리하는 논리적 공간입니다.
• Shard (샤드): 인덱스를 물리적으로 나눈 데이터 단위로, 복제본(replica)이 아닌 실제 데이터입니다.
• Primary Shard (프라이머리 샤드): CRUD(Create, Read, Update, Delete)를 처리하는 실제 샤드입니다.
• Replica Shard (레플리카 샤드): 장애 복구 및 읽기 부하 분산을 위해 프라이머리 샤드의 복제본으로 사용됩니다.
• 핫노드(Hot Node): 특정 노드에 많은 샤드가 몰려 성능 병목 현상이 발생하는 노드입니다.

---

📌 OpenSearch 및 Elasticsearch 샤드 권장사항

🔹 샤드 크기 및 개수 권장사항

• 일반적으로 샤드당 크기는 10~50GB가 적절합니다.
  • 검색 지연시간 감소가 중요하다면 샤드당 10~30GB
  • 쓰기 작업 중심(로그 분석 등)이라면 샤드당 30~50GB
• 단일 인덱스는 최대 1024개의 샤드를 가질 수 있습니다.
• 한 샤드의 문서 수는 2억 개 이하로 유지하는 것이 좋습니다.
• 전체 샤드당 문서 수는 약 20억 개를 초과하지 않도록 관리해야 합니다.

🔹 샤드 개수 설정 공식

샤드 개수는 다음과 같이 설정됩니다.

• Primary 샤드 개수 × (Replica 개수 + 1)

예를 들어, Primary 샤드가 3개, Replica가 2개인 경우 총 샤드는 다음과 같습니다.

(Primary 3) × (Replica 2 + 1) = 총 9개의 샤드

🔹 샤드 개수에 따른 성능 영향

• Primary 샤드가 많을수록 읽기 성능은 향상되지만, 자원 소모와 마스터 노드 부하가 증가합니다.
• 많은 샤드는 마스터 노드의 메모리 사용량을 증가시켜 전반적인 검색 및 색인 성능 저하를 유발합니다.
• 따라서, 샤드 수를 데이터 노드 수의 짝수 배수로 설정하여 핫노드 현상을 예방하는 것이 권장됩니다.

🔹 마스터 노드 힙 설정

• 마스터 노드는 3000개 인덱스당 최소 1GB 힙 메모리를 설정해야 합니다.

---

📌 JVM 힙 메모리 관리 권장사항

🔹 JVM 힙 사이즈 설정

OpenSearch는 JVM 힙을 인스턴스 RAM의 50%로 제한하여 설정합니다.

예를 들어, c6g.large.search 인스턴스의 경우:

• 인스턴스 메모리: 8GB
• JVM 힙 크기: 4GB(50%)

🔹 JVM 힙 사이즈를 50%로 제한하는 이유

다음의 이유로 JVM 힙 사이즈를 인스턴스 메모리의 50%로 설정합니다.

• OS Page Cache 확보: Lucene 검색 성능을 보장하기 위함
• GC 안정성 확보: 가비지 컬렉션(Garbage Collection)의 효율성 증가
• CompressedOops 최적화 유지: JVM의 메모리 효율적 활용
• 시스템 안정성 확보: 시스템 전체 메모리 관리 안정성 향상

---

📌 OpenSearch 성능 최적화 팁

• 한 노드의 JVM 힙 메모리 1GiB당 권장 샤드 개수:
  • OpenSearch 2.17 이상: 2.15개/GB (최대 4000개)
  • 일반적인 환경에서는 최대 25개 이하로 설정 권장
• 샤드가 많을 경우 마스터 노드의 메모리 부하가 높아지고, 이는 전체 클러스터 성능에 부정적인 영향을 미칠 수 있습니다.
• 따라서 불필요한 샤드를 줄이고, 샤드 크기를 적절히 유지하는 것이 중요합니다.

---

📌 기존 클러스터 사례 분석

기존에 운영중인 OpenSearch Data Node는 현재 아래와 같은 설정 상태입니다.

• 노드 타입: c6g.large.search (JVM 힙 메모리 4GB)
• 최대 샤드 수 설정(max_shards_per_node): 1000개

🔹 기존 클러스터 분석 결론

• 현재 기존 클러스터의 데이터 노드에 인덱스 대비 샤드 수가 많아 자원 소모가 큰 편입니다.
• 인스턴스 타입(c6g.large)을 고려할 때, 프라이머리 샤드를 3개 이상 유지하지 않는 것이 바람직합니다.
• 샤드 수를 현재 상태에서 유지한다면 메모리를 최소 12GB 이상의 인스턴스로 업그레이드하는 것을 권장합니다.
• 다만 현재 상태에서 JVM Pressure 현상은 관찰되지 않았습니다.

---

📌 추가 정보 및 API 예시

🔹 클러스터 할당 정보 확인

GET /_cat/allocation
GET /_cat/allocation/{node_id}

🔹 샤드 및 레플리카 개수 설정 예시

PUT /movie
{
    "settings": {
        "index": {
            "number_of_shards": 4,   // Primary 샤드 수 (일반적으로 Node 수 * n)
            "number_of_replicas": 1  // Replica 샤드 수
        }
    }
}

---

📌 결론

효율적인 OpenSearch 관리의 핵심은 샤드 수 관리와 JVM 힙 메모리 최적화에 달려 있습니다. 권장 가이드라인을 참고하여 클러스터의 성능과 안정성을 확보하시기 바랍니다.

---

📌 참고 자료

• ElasticSearch 샤드 크기 권장사항
• NAVER ElasticSearch 성능 최적화 사례
• AWS OpenSearch 성능 최적화 가이드
• Toss 데이터 샤드 최적화 사례
• OpenSearch 샤드 최적화 블로그
• AWS JVM 메모리 최적화 가이드
• AWS OpenSearch 에러 처리 가이드
• OpenSearch Circuit Breaker 트러블슈팅
• 동작 방식과 함께 알아보는 최적의 Amazon OpenSearch Service 사이징