Segment replication

출처: 문서

본문

세그먼트 복제

세그먼트 복제는 각 샤드 복제본에서 문서를 색인하는 대신 샤드 간에 세그먼트 파일을 복사하는 방식이에요. 이 방식은 색인 처리량을 높이고 리소스 사용률을 줄여 주지만, 네트워크 사용률은 증가시켜요. 세그먼트 복제는 컴퓨팅 비용을 낮추기 위해 읽기와 쓰기를 분리하도록 설계된 일련의 기능 중 첫 번째 기능이에요.

프라이머리 샤드가 refresh 시점에 레플리카 샤드로 체크포인트를 전송하면, 레플리카 샤드에서 새로운 세그먼트 복제 이벤트가 트리거돼요. 이는 다음 경우에 발생해요:

• 클러스터에 새 레플리카 샤드가 추가될 때.
• 프라이머리 샤드 refresh 시 세그먼트 파일에 변경 사항이 있을 때.
• 레플리카 샤드 복구 및 샤드 재배치(move 할당 커맨드를 사용한 명시적 할당 또는 자동 샤드 리밸런싱)와 같은 피어 복구가 진행되는 동안.

사용 사례

세그먼트 복제는 다음을 포함해 다양한 시나리오에 적용할 수 있어요:

• 검색 요구 사항은 높지 않고 refresh 간격이 긴, 높은 쓰기 부하 환경.
• 매우 높은 부하를 겪는 상황에서 새 노드를 추가하고 싶지만 모든 데이터를 즉시 색인하고 싶지 않을 때.
• 로그 분석용으로 사용되는 것과 같은, 레플리카 수가 적은 OpenSearch 클러스터 배포.

Remote-backed storage

세그먼트 복제에는 두 가지 방식을 사용할 수 있어요:

• Remote-backed storage, 영구 저장소 솔루션: 프라이머리 샤드가 세그먼트 파일을 remote-backed storage로 전송하면, 레플리카 샤드는 같은 스토어에서 복사본을 가져와요. remote-backed storage 사용에 대한 자세한 내용은 Remote-backed storage를 참고하세요.
• 노드 간 통신: 프라이머리 샤드가 노드 간 통신을 사용해 세그먼트 파일을 레플리카 샤드에 직접 전송해요.

세그먼트 복제 설정

클러스터의 기본 복제 타입을 설정하면 새로 생성되는 모든 인덱스에 영향을 줘요. 다만 인덱스를 생성할 때 다른 복제 타입을 지정할 수도 있어요. 인덱스 레벨 설정이 클러스터 레벨 설정보다 우선해요.

세그먼트 복제를 사용하는 인덱스 생성하기

인덱스의 복제 전략으로 세그먼트 복제를 사용하려면, 다음과 같이 replication.type 파라미터를 SEGMENT로 설정해서 인덱스를 생성하세요:

PUT /my-index1
{
  "settings": {
    "index": {
      "replication.type": "SEGMENT" 
    }
  }
}

{% include copy-curl.html %}

remote-backed storage를 사용한다면 인덱스 요청 본문에 remote_store 속성을 추가하세요.

노드 간 복제를 사용하면 프라이머리 샤드가 모든 레플리카 샤드로 세그먼트 파일을 푸시하기 때문에 더 많은 네트워크 대역폭을 소모해요. 따라서 프라이머리 샤드를 노드 간에 균등하게 분산하는 것이 유리해요. 프라이머리 샤드가 균형 있게 분산되도록 하려면 동적 설정인 cluster.routing.allocation.balance.prefer_primary를 true로 설정하세요. 자세한 내용은 클러스터 설정을 참고하세요.

최상의 성능을 위해서는 다음 설정을 활성화하는 것이 권장돼요:

1. 세그먼트 복제 백프레셔
2. 다음 커맨드를 사용한 균형 잡힌 프라이머리 샤드 할당:

PUT /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.balance.prefer_primary": true,
    "segrep.pressure.enabled": true
  }
}

{% include copy-curl.html %}

클러스터의 복제 타입 설정하기

opensearch.yml 파일에서 다음과 같이 새로 생성되는 클러스터 인덱스의 기본 복제 타입을 설정할 수 있어요:

cluster.indices.replication.strategy: 'SEGMENT'

{% include copy.html %}

클러스터 레벨 복제 타입 강제하기

활성화하면 cluster.index.restrict.replication.type 설정에 의해 새로 생성되는 인덱스가 클러스터 설정 cluster.indices.replication.strategy에 지정된 복제 타입을 갖도록 요구돼요. 다른 복제 타입을 지정하는 요청은 거부돼요. cluster.index restrict.replication.type가 비활성화되어 있다면, index.replication.type 설정에 복제 타입을 지정하는 방식으로 인덱스별로 복제 타입을 선택할 수 있어요.

cluster.index.restrict.replication.type 설정은 opensearch.yml 파일에서 다음과 같이 정의할 수 있어요:

cluster.index.restrict.replication.type: true

{% include copy.html %}

문서 복제를 사용하는 인덱스 생성하기

기본 복제 타입이 세그먼트 복제로 설정되어 있더라도, 다음과 같이 replication.type을 DOCUMENT로 설정하면 문서 복제를 사용하는 인덱스를 만들 수 있어요:

PUT /my-index1
{
  "settings": {
    "index": {
      "replication.type": "DOCUMENT" 
    }
  }
}

{% include copy-curl.html %}

고려 사항

세그먼트 복제를 사용할 때는 다음 사항을 고려하세요:

1. 기존 인덱스에 세그먼트 복제를 활성화하려면 재색인이 필요해요.
2. 크로스 클러스터 복제는 현재 클러스터 간 복사에 세그먼트 복제를 사용하지 않아요.
3. 세그먼트 복제에서는 레플리카 샤드가 프라이머리 샤드로부터 업데이트를 가져오기 때문에, 노드 간 복제를 사용하는 프라이머리 샤드의 네트워크 혼잡이 증가해요. remote-backed storage를 사용하면 프라이머리 샤드는 세그먼트를 remote-backed storage로 업로드할 수 있고, 레플리카는 remote-backed storage에서 업데이트를 가져올 수 있어요. 이를 통해 프라이머리 샤드의 책임 일부를 remote-backed storage로 분산할 수 있어요.
4. 쓰기 후 읽기 보장: 세그먼트 복제는 refresh 정책을 wait_for 또는 true로 설정하는 것을 지원하지 않아요. refresh 쿼리 파라미터를 wait_for 또는 true로 설정한 뒤 문서를 색인하면, 프라이머리 노드가 refresh를 완료하고 해당 문서들을 검색 가능한 상태로 만든 후에야 응답을 받게 돼요. 레플리카 샤드는 로컬 translog에 기록을 마친 후에야 응답해요. 실시간 읽기가 필요하다면 get 또는 mget API 오퍼레이션 사용을 고려해 보세요.
5. 시스템 인덱스는 세그먼트 복제를 지원해요.
6. Get, MultiGet, TermVector, MultiTermVector 요청은 요청을 프라이머리 샤드로 라우팅해서 강한 읽기를 제공해요. 요청을 프라이머리 샤드와 레플리카 샤드에 분산하는 경우보다 프라이머리 샤드로 더 많은 요청을 라우팅하면 성능이 저하될 수 있어요. 읽기가 많은 클러스터에서 성능을 개선하려면 이러한 요청에서 realtime 파라미터를 false로 설정하는 것을 권장해요. 자세한 내용은 Issue #8700을 참고하세요.

벤치마크

초기 벤치마크에서 세그먼트 복제(segment replication) 사용자들은 같은 클러스터 설정에서 문서 복제(document replication)를 사용할 때보다 처리량이 40% 더 높다고 보고했어요.

다음 벤치마크는 OpenSearch-benchmark를 사용해 stackoverflow 및 nyc_taxi 데이터셋으로 수집했어요.

이 벤치마크는 다음 구성이 세그먼트 복제에 미치는 영향을 보여 줘요:

• 워크로드 크기
• 프라이머리 샤드 수
• 레플리카 수

클러스터 토폴로지, 사용하는 하드웨어, 샤드 개수, 머지 설정에 따라 결과는 달라질 수 있어요. {: .note }

워크로드 크기 늘리기

다음 표는 다음 구성에서 nyc_taxi 데이터셋에 대해 측정한 벤치마크 결과를 보여 줘요:

• m5.xlarge 데이터 노드 10개
• 프라이머리 샤드 40개, 각각 레플리카 1개(총 샤드 80개)
• 노드당 프라이머리 샤드 4개와 레플리카 샤드 4개

		40 GB 프라이머리 샤드, 총 80 GB			240 GB 프라이머리 샤드, 총 480 GB
		문서 복제	세그먼트 복제	백분율 차이	문서 복제	세그먼트 복제	백분율 차이
스토어 크기		85.2781	91.2268	N/A	515.726	558.039	N/A
인덱싱 처리량(초당 요청 수)	최솟값	148,134	185,092	24.95%	100,140	168,335	68.10%
	중앙값	160,110	189,799	18.54%	106,642	170,573	59.95%
	최댓값	175,196	190,757	8.88%	108,583	172,507	58.87%
오류율		0.00%	0.00%	0.00%	0.00%	0.00%	0.00%

워크로드 크기가 커질수록 레플리카가 더 큰 데이터셋을 인덱싱할 필요가 없기 때문에 세그먼트 복제의 이점은 더욱 커져요. 일반적으로 복제 지연을 고려하지 않는다면, 세그먼트 복제는 모든 클러스터 구성에서 문서 복제보다 더 낮은 리소스 비용으로 더 높은 처리량을 제공해요.

프라이머리 샤드 수 늘리기

다음 표는 nyc_taxi 데이터셋에 대해 프라이머리 샤드 40개와 100개인 경우의 벤치마크 결과를 보여 줘요.

{::nomarkdown}

		프라이머리 샤드 40개, 레플리카 1개			프라이머리 샤드 100개, 레플리카 1개
		문서 복제	세그먼트 복제	백분율 차이	문서 복제	세그먼트 복제	백분율 차이
인덱싱 처리량(초당 요청 수)	최솟값	148,134	185,092	24.95%	151,404	167,391	9.55%
	중앙값	160,110	189,799	18.54%	154,796	172,995	10.52%
	최댓값	175,196	190,757	8.88%	166,173	174,655	4.86%
오류율		0.00%	0.00%	0.00%	0.00%	0.00%	0.00%

{:/}

프라이머리 샤드 수가 늘어날수록 문서 복제 대비 세그먼트 복제의 이점은 줄어들어요. 프라이머리 샤드가 더 많을 때도 세그먼트 복제는 여전히 유익하지만, 노드마다 클러스터 전체에 세그먼트 파일을 복사해야 하는 프라이머리 샤드가 더 많아지기 때문에 성능 차이는 그만큼 두드러지지 않아요.

레플리카 수 늘리기

다음 표는 stackoverflow 데이터셋에 대해 레플리카 1개와 9개인 경우의 벤치마크 결과를 보여 줘요.

{::nomarkdown}

		프라이머리 샤드 10개, 레플리카 1개			프라이머리 샤드 10개, 레플리카 9개
		문서 복제	세그먼트 복제	백분율 차이	문서 복제	세그먼트 복제	백분율 차이
인덱싱 처리량(초당 요청 수)	중앙값	72,598.10	90,776.10	25.04%	16,537.00	14,429.80	−12.74%
	최댓값	86,130.80	96,471.00	12.01%	21,472.40	38,235.00	78.07%
CPU 사용률(%)	p50	17	18.857	10.92%	69.857	8.833	−87.36%
	p90	76	82.133	8.07%	99	86.4	−12.73%
	p99	100	100	0%	100	100	0%
	p100	100	100	0%	100	100	0%
메모리 사용률(%)	p50	35	23	−34.29%	42	40	−4.76%
	p90	59	57	−3.39%	59	63	6.78%
	p99	69	61	−11.59%	66	70	6.06%
	p100	72	62	−13.89%	69	72	4.35%
오류율		0.00%	0.00%	0.00%	0.00%	2.30%	2.30%

{:/}

레플리카 수가 늘어나면 프라이머리 샤드가 레플리카를 최신 상태로 유지하는 데 필요한 시간, 이른바 복제 지연(replication lag)도 늘어나요. 그 이유는 세그먼트 복제가 세그먼트 파일을 프라이머리 샤드에서 레플리카로 직접 복사하기 때문이에요.

벤치마크 결과를 보면 레플리카 수가 늘어날수록 0이 아닌 오류율이 나타나요. 이 오류율은 레플리카가 프라이머리 샤드를 따라가지 못할 때 세그먼트 복제 백프레셔 메커니즘이 시작된다는 뜻이에요. 하지만 이 오류율은 세그먼트 복제가 제공하는 상당한 CPU와 메모리 절감 효과로 상쇄돼요.

다음 단계

1. 세그먼트 복제의 향후 개선 사항을 추적해 보세요.
2. 세그먼트 복제에 관한 이 블로그 포스트를 읽어 보세요.

더 알아보기 (Learn more)

• 원문 전체: https://docs.opensearch.org/latest/tuning-your-cluster/availability-and-recovery/segment-replication/index/