Elasticsearch가 처음이신가요? Elasticsearch 입문용 웨비나에 참여하세요. 지금 무료 클라우드 체험을 시작하거나, 내 기기에서 Elastic을 사용해 볼 수 있습니다.
Elasticsearch는 확장성과 내결함성 문제를 해결하는 분산 시스템을 그 위에 구축하여 Lucene의 성능을 향상시킵니다. 또한 JSON 기반 REST API를 노출하여 다른 시스템과의 상호 운용성이 매우 간단합니다.
Elasticsearch와 같은 분산 시스템은 매우 복잡할 수 있으며, 성능과 안정성에 영향을 미칠 수 있는 많은 요인들이 존재합니다. 샤드는 Elasticsearch에서 가장 기본적인 개념 중 하나이며, 샤드의 작동 원리를 이해하면 Elasticsearch 클러스터를 효과적으로 관리할 수 있습니다.
이 문서에서는 기본 샤드와 복제 샤드가 무엇이며, Elasticsearch 클러스터에 미치는 영향과 다양한 요구 사항에 맞게 샤드를 조정할 수 있는 도구가 무엇인지 설명합니다.
샤드 이해
Elasticsearch 인덱스의 데이터는 엄청난 비율로 증가할 수 있습니다. 관리하기 쉽도록 모든 데이터는 인덱스에 보관되며, 인덱스는 여러 개의 샤드로 분할된 인덱스입니다. 각 Elasticsearch 샤드는 Apache Lucene 인덱스이며, 각 개별 Lucene 인덱스는 Elasticsearch 인덱스에 있는 문서의 하위 집합을 포함합니다. 이러한 방식으로 인덱스를 분할하면 리소스 사용량을 제어할 수 있습니다. Apache Lucene 인덱스의 문서 수 제한은 2,147,483,519개(2³¹ - 129개)입니다.
때로는 리밸런싱을 위해 노드 간에 인덱스를 이동해야 하는 경우가 있습니다. 이 프로세스는 시간과 리소스가 많이 소요될 수 있으므로 인덱스가 너무 커지지 않아야 복구 시간을 관리할 수 있습니다. 또한 인덱스는 지속적으로 병합해야 하는 Lucene 세그먼트로 구성되므로 세그먼트가 너무 커지지 않도록 하는 것이 중요합니다. 이러한 이유로 Elasticsearch는 인덱스 데이터를 기본 샤드라고 하는 관리하기 쉬운 작은 청크로 분할하여 여러 머신에 더 쉽게 분산할 수 있습니다. 복제 샤드는 단순히 해당 기본 샤드의 정확한 복사본이며, 이 글의 뒷부분에서 복제 샤드의 기능을 살펴보겠습니다.
적절한 수의 샤드를 보유하는 것은 성능에 중요합니다. 따라서 미리 계획을 세우는 것이 현명합니다. 쿼리가 여러 샤드에서 병렬로 실행되는 경우, 단일 샤드로 구성된 인덱스보다 빠르게 실행되지만 각 샤드가 다른 노드에 있고 클러스터에 충분한 노드가 있는 경우에만 실행됩니다. 그러나 동시에 샤드는 인덱싱된 데이터와 클러스터 메타데이터 측면에서 메모리와 디스크 공간을 소비합니다. 샤드가 너무 많으면(오버샤딩이라고도 함) 쿼리, 인덱싱 요청 및 관리 작업 속도가 느려질 수 있으므로 적절한 균형을 유지하는 것이 중요합니다.
기본 샤드 수는 특정 인덱스 인스턴스에 대한 인덱스 생성 시 정의됩니다. 나중에 다른 수의 기본 샤드가 필요한 경우 크기 조정API인 분할(기본 샤드 수 증가), 축소 (기본 샤드 수 감소) 또는 복제 (복제본에 대한 새로운 설정으로 동일한 수의 기본 샤드)를 사용할 수 있습니다. 이러한 작업은 Lucene 세그먼트를 복사하고 모든 문서의 전체 재색인을 피하며, 인덱스를 만들 때 인덱스의 설정으로 기본 및 복제 샤드 수를 설정할 수 있습니다:
(샤드 또는 복제본 수를 지정하지 않으면 Elasticsearch 7.0 기준 기본값은 둘 다 1입니다). 인덱스의 데이터 양에 따라 이상적인 샤드 수를 결정해야 합니다. 일반적으로최적의 샤드에는 10~50GB의 데이터가 저장되어야 하며, 샤드당 문서 수는 2억 개 미만이어야 합니다. 예를 들어, 하루에 약 300GB의 애플리케이션 로그가 누적될 것으로 예상되는 경우, 이를 호스팅할 충분한 양의 노드가 있다면 해당 인덱스에 약 10개의 샤드를 보유하는 것이 합리적입니다.
파편은 수명이 다하는 동안 다음과 같은 여러 상태를 거칠 수 있습니다:
- 초기화 중입니다: 샤드를 사용하기 전 초기 상태입니다.
- 시작됨: 샤드가 활성화되어 요청을 받을 수 있는 상태입니다.
- 재배치 중: 샤드가 다른 노드로 이동하는 중일 때 발생하는 상태입니다. 이는 특정 조건에서 필요할 수 있는데, 예를 들어 해당 노드의 디스크 공간이 부족한 경우입니다.
- 할당되지 않음: 할당되지 않음: 할당되지 않은 샤드의 상태입니다. 예를 들어, 샤드를 호스팅하는 노드가 더 이상 클러스터에 속하지 않거나 (NODE_LEFT) 폐쇄 인덱스로 복원하는 경우 (EXISTING_INDEX_RESTORED)와 같이 이런 상황이 발생하면 사유가 제공됩니다.
모든 샤드, 샤드의 상태 및 기타 메타데이터를 보려면 다음 요청을 사용하면 됩니다:
특정 인덱스의 샤드를 보려면 URL에 인덱스 이름(예: sensor)을 추가하면 됩니다:
이 명령은 다음 예제와 같은 출력을 생성합니다. 기본적으로 표시되는 열에는 인덱스의 이름, 이름(예 번호), 기본 샤드인지 복제본인지 여부, 샤드의 상태, 문서 수, 디스크의 크기, 샤드가 위치한 노드의 IP 주소와 노드 ID를 확인할 수 있습니다.
복제본 이해
각 샤드에는 데이터의 단일 사본이 포함되지만 인덱스에는 여러 개의 샤드 사본이 포함될 수 있습니다. 따라서 샤드에는 기본 샤드와 복제본, 즉 복제본의 두 가지 유형이 있습니다. 기본 샤드의 각 복제본은 항상 다른 노드에 위치하므로 노드 장애 발생 시 데이터의 고가용성을 보장합니다. 복제본은 중복성과 데이터 손실 및 다운타임을 방지하는 역할 외에도 쿼리를 기본 샤드와 병렬로 처리하여 더 빠르게 처리함으로써 검색 성능을 향상시키는 데 도움이 될 수 있습니다.
기본 샤드와 복제본 샤드의 작동 방식에는 몇 가지 중요한 차이점이 있습니다. 둘 다 쿼리를 처리할 수 있지만 인덱싱 요청(예 인덱스에 데이터 추가)는 복제 샤드에 복제되기 전에 먼저 기본 샤드를 거쳐야 합니다. 위에서 언급했듯이 노드 연결이 끊기거나 하드웨어 장애 등으로 인해 기본 샤드를 사용할 수 없게 되면 복제본이 그 역할을 대신하도록 승격됩니다.
복제본은 노드 장애 발생 시 도움이 될 수 있지만, 인덱싱할 때 메모리, 디스크 공간, 컴퓨팅 성능을 소모하므로 복제본을 너무 많이 보유하지 않는 것이 중요합니다. 기본 샤드와 복제본의 또 다른 차이점은 인덱스가 생성된 후에는 기본 샤드의 수를 변경할 수 없지만, 복제본의 수는 인덱스 설정을 업데이트하여 언제든지 동적으로 변경할 수 있다는 점입니다.
복제본에서 고려해야 할 또 다른 요소는 사용 가능한 노드 수입니다. 복제본은 항상 기본 샤드와 다른 노드에 배치되는데, 동일한 노드에 동일한 데이터의 복사본이 두 개 있으면 노드에 장애가 발생할 경우 아무런 보호 기능을 제공하지 못하기 때문입니다. 따라서 시스템에서 n개의 복제본을 지원하려면 클러스터에 최소 n + 1개의 노드가 있어야 합니다. 예를 들어 클러스터에 노드가 2개 있고 인덱스가 6개의 복제본으로 구성된 경우, 복제본은 1개만 할당됩니다. 반면, 7개의 노드가 있는 시스템은 하나의 기본 샤드와 6개의 복제본을 완벽하게 처리할 수 있습니다.
샤드 및 복제본 최적화
기본 샤드와 복제본 샤드의 균형이 적절한 인덱스가 생성된 후에도 시간이 지남에 따라 인덱스 주변의 역학 관계가 변하기 때문에 이를 모니터링해야 합니다. 예를 들어 시계열 데이터를 다룰 때는 일반적으로 최근 데이터가 있는 인덱스가 오래된 데이터보다 더 활성화되어 있습니다. 이러한 인덱스를 조정하지 않으면 요구 사항이 매우 다름에도 불구하고 모두 동일한 양의 리소스를 소비하게 됩니다.
롤오버 인덱스 API는 최신 인덱스와 이전 인덱스를 분리하는 데 사용할 수 있습니다. 특정 임계값(디스크의 인덱스 크기, 문서 수 또는 기간 등)에 도달하면 자동으로 새 인덱스를 생성하도록 설정할 수 있습니다. 이 API는 샤드 크기를 제어하는 데도 유용합니다. 인덱스 생성 후에는 샤드 수를 쉽게 변경할 수 없기 때문에 롤오버 조건이 충족되지 않으면 샤드는 계속해서 데이터를 축적합니다. 자주 액세스하지 않는 오래된 인덱스의 경우, 인덱스 축소와 강제 병합은 메모리와 디스크 공간을 줄이는 두 가지 방법입니다. 전자는 인덱스의 샤드 수를 줄이고, 후자는 Lucene 세그먼트 수를 줄이며 삭제된 문서가 사용하는 공간을 확보합니다.
기본 샤드와 복제본 샤드를 Elasticsearch의 기반으로 사용
Elasticsearch는 방대한 양의 데이터를 위한 분산 저장, 검색 및 분석 플랫폼으로서 강력한 명성을 쌓아왔습니다. 그러나 이러한 규모로 운영할 때는 필연적으로 문제가 발생할 수밖에 없습니다. 따라서 기본 샤드와 복제본 샤드의 작동 방식을 이해하는 것은 플랫폼의 안정성과 성능을 최적화하는 데 도움이 될 수 있기 때문에 Elasticsearch에서 매우 중요하고 기본이 되는 이유입니다.
작동 방식과 최적화 방법을 아는 것은 보다 강력하고 성능이 우수한 Elasticsearch 클러스터를 달성하는 데 매우 중요합니다. 쿼리 응답이 느리거나 서비스 중단이 자주 발생하는 경우 이 지식이 이러한 장애물을 극복하는 열쇠가 될 수 있습니다.
클러스터, 노드 및 샤드, 샤드 크기 조정 방법, 샤드 할당 및 복구에 대해 자세히 알아보려면 Elasticsearch의 공식 설명서를 참조하세요.
이 주제는 Elastic 커뮤니티 YouTube 채널에서입문 과정으로도 제공됩니다.
마지막으로, 노드, 샤드 또는 복제본에 대해 걱정하고 싶지 않으시다면 Elastic Cloud Serverless를 사용해 보세요. 이 Elastic Cloud 제품은 Elastic에서 완전히 관리하며 워크로드에 따라 확장할 수 있도록 자동화되어 있습니다. 무료 평가판을 통해 서버리스 접근 방식의 다른 이점에 대해 알아볼 수 있습니다.




