OpenSearch에서의 Sharding

간단하게 얘기하면 "HashMap의 동작 원리"를 떠올리면 이해가 가장 빠르다

OpenSearch의 샤딩은 단순히 데이터를 쪼개는 것이 아니라, 결정론적 알고리즘을 통해 데이터를 분산하고 다시 찾아낸다. 데이터가 어떤 샤드에 저장될지 결정하는 메커니즘인 라우팅 과정을 중심으로 설명해보자.

1. 핵심 공식: 라우팅 알고리즘

OpenSearch가 "이 문서를 0번 샤드에 넣을지, 1번 샤드에 넣을지" 결정하는 방법은 아주 간단한 모듈러 연산 공식에 따른다.

shard_num = hash(_routing) (mod num_primary_shards)

• _routing: 기본적으로 문서의 _id 값이 사용된다. (개발자가 임의로 지정 가능)
• hash: Murmur3 해시 함수를 사용하여 문서를 균일하게 분산시킨다.
• num_primary_shards: 인덱스 생성 시 설정한 프라이머리 샤드 개수이다.
• modulo: 해시 값을 샤드 개수로 나눈 나머지를 구하여, 데이터를 담을 샤드 번호를 결정한다.

이 공식 때문에 데이터가 들어올 떄 랜덤하게 저장되는 것이 아니라, 특정 값(_id)에 대해 항상 같은 샤드로 배정됨이 보장된다.

2. 논리적 구조 vs 물리적 배치

샤딩은 논리적인 인덱스를 물리적인 파일 덩어리로 쪼개는 과정이다.

• Index (논리적 개념): 개발자가 바라보는 데이터의 집합
• Shard (물리적 개념):
  • 실제 데이터가 저장되는 Lucene 인스턴스.
  • 각 샤드는 독립적인 검색 엔진이며 CPU, 메모리, 디스크 자원을 소비한다.
• Node (서버):
  • OpenSearch 프로세스가 실행되는 물리적 서버.
  • 여러 샤드가 여러 노드에 분산 배치된다.

데이터 분산 예시 (샤드 3개, 레플리카 1개, 노드 3개)

• 프라이 머리 샤드(P0, P1, P2)는 노드 1, 2, 3에 골고루 퍼진다.
• 레플리카 샤드(R0, R1, R2)는 자신의 원본과 절대 같은 노드에 배치되지 않는다
• P0가 있는 노드 1이 죽으면, 다른 노드에 있는 R0가 즉시 P0으로 승격된다.

3. 왜 프라이머리 샤드 개수를 나중에 못 바꿀까?

OpenSearch를 운영하다 보면 "처음에 샤드 5개로 잡았는데, 데이터가 너무 많으니 10개로 늘리고 싶어"라는 상황이온다.
하지만 이미 생성된 인덱스의 프라이머리 샤드 개수는 변경 불가능하다.

이유는 1번의 공식 떄문이다. 데이터를 저장할 때 5로 나눈 나머지로 위치를 정했다. 그런데 나중에 샤드 개수를 10으로 바꿔버리면, 조회할 떄 엉뚱한 샤드를 뒤지게 되어 데이터가 증발한 것 처럼 보이게 된다

그래서 샤드 개수를 바꾸려면 **Reindex(새로운 인덱스를 만들고 데이터 이관)**가 유일한 방법이다.