Elasticsearch 샤드 설계 실전: shard/replica 개수와 검색 성능을 같이 보는 기준

Elasticsearch 샤드 설계 실전: shard/replica 개수와 검색 성능을 같이 보는 기준

Elasticsearch는 샤드를 많이 쪼갠다고 빨라지지 않는다. 작은 샤드가 많아질수록 메타데이터, merge, relocation 비용이 눈에 띄게 커진다.

중급 운영에서는 인덱스 설계를 데이터 크기와 검색 패턴이 아니라, 장애 복구 시간과 운영 인력까지 포함해 봐야 한다.

왜 지금 이 주제가 중요한가

• 샤드 수는 성능뿐 아니라 장애 복구 시간과 노드 증설 전략에 직접 영향을 준다.
• replica는 가용성 도구이면서 검색 처리량 레버이기도 하다.
• hot shard를 방치하면 특정 노드만 포화되고 클러스터 전체 성능이 흔들린다.

핵심 설계 포인트

• 인덱스당 샤드 수는 예상 총 데이터와 일 단위 증가량, 보관 정책으로 산정한다.
• 샤드 크기는 너무 작지도, 너무 크지도 않게 유지해야 merge와 relocation이 감당 가능하다.
• 시간 기반 데이터는 rollover와 ILM으로 관리하고, 고정 도메인 데이터는 검색 패턴 중심으로 나눈다.
• replica는 읽기 분산과 장애 복구 목표를 기준으로 결정한다.

예시 구성

{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1,
    "index.lifecycle.name": "logs-hot-warm"
  }
}

적용 순서(실무 플로우)

설계 자체보다도 '작게 도입하고 관측하면서 확장하는 순서'가 운영 성공률을 좌우한다.

1. 현재 인덱스별 데이터 크기와 일일 증가량을 측정한다.
2. 읽기/쓰기 비율과 장애 시 복구 목표 시간을 기준으로 샤드 목표 크기를 정한다.
3. rollover, index template, ILM 정책을 함께 설계한다.
4. hot shard 여부를 대시보드로 추적하고 재인덱싱 기준을 문서화한다.
5. 운영 중 샤드 증감은 비용이 크므로 초반에 작은 PoC로 검증한다.

운영 체크포인트

• 샤드 재배치가 잦은 시간대에는 롤오버와 대규모 배포를 겹치지 않는다.
• template 변경 전후로 새 인덱스에만 반영되는지 확인한다.
• 검색 latency와 인덱싱 throughput을 분리해서 본다. 둘은 자주 충돌한다.

운영 지표/알람 추천

• 검색 지연(p95/p99)과 timeout 비율
• shard size, segment merge, relocation 횟수
• refresh/replication 지연과 인덱싱 처리량
• hot shard 여부와 노드별 디스크 사용률

빠른 점검 명령/쿼리

curl -s http://localhost:9200/_cat/shards?v
curl -s http://localhost:9200/_cluster/health?pretty
curl -s http://localhost:9200/index/_stats?pretty

구조화 로그 필드 추천

• traceId/requestId/eventId처럼 흐름을 이어주는 키를 남긴다.
• endpoint/topic/flag/version 등 주제별 핵심 차원을 구조화한다.
• 실패 이유(reasonCode)와 재시도 횟수(retryAttempt)를 분리한다.
• 민감정보는 마스킹하고, payload는 샘플링 또는 요약 저장한다.

{
  "level": "INFO",
  "message": "request completed",
  "traceId": "4bf92f...",
  "requestId": "req_123",
  "path": "/api/example",
  "status": 200,
  "latencyMs": 123,
  "reasonCode": null
}

테스트 케이스 샘플

테스트 케이스(최소 3종):
1) 정상: 기대한 성공 경로와 상태 전이가 유지되는지
2) 실패: 다운스트림 오류/잘못된 입력이 예측 가능한 에러로 떨어지는지
3) 동시성/재시도: 같은 요청 또는 이벤트가 반복돼도 부작용이 없는지

추가(가능하면):
- 장애 복구: 프로세스 재시작 후 중간 상태를 정상 회복하는지
- 부하: p95/p99와 queue/pool saturation이 임계값 안에 드는지

트레이드오프/대안

• 운영 복잡도를 줄이면 기능 유연성이 떨어질 수 있고, 반대도 마찬가지다.
• 기본값은 출발점일 뿐이다. 실제 트래픽과 실패 패턴을 보고 다시 조정해야 한다.
• 관측 없이 최적화하면 체감 개선과 회귀를 구분하기 어렵다.
• 팀 경계가 많은 시스템일수록 인터페이스 계약과 문서가 코드만큼 중요하다.

성공 기준(SLO) 예시

• 핵심 경로 에러율: 0.1% 이하
• 핵심 요청/이벤트 p95 지연: 서비스 목표 내 유지
• 중복 실행 또는 데이터 유실: 0건
• 장애 감지 후 임시 조치까지 걸리는 시간: 10분 이내

자주 터지는 실수/트러블슈팅

1. 작게 쪼개면 무조건 빠를 거라 믿는다: 오히려 관리 비용이 급증한다.
2. replica를 0으로 두고 운영한다: 노드 장애가 곧 서비스 장애가 된다.
3. hot shard를 애플리케이션 키 설계 탓으로만 본다: 실제로는 인덱스 전략이 원인인 경우가 많다.

바로 적용 템플릿

샤드 설계 체크리스트:
총 데이터 크기 / 일 증가량 / 보관 기간
목표 샤드 크기 / replica 수 / rollover 기준
장애 복구 시간 목표(RTO)와 재인덱싱 허용 여부

검증 방법

• 샤드 재배치 또는 노드 장애를 가정해 클러스터가 목표 시간 안에 회복되는지 확인한다.
• 실제 검색 쿼리 상위 10개로 p95 지연이 목표 범위인지 측정한다.

장애 대응 Runbook(초안)

• 현상: 어떤 사용자/서비스/플랫폼에서 무엇이 깨졌는지 한 문장으로 정리한다.
• 범위: 언제부터 시작됐고, 영향받은 비율과 핵심 경로를 적는다.
• 증거: 로그 3줄, 지표 1개, 최근 배포/설정 변경 1개를 먼저 모은다.
• 임시 조치: 차단, 롤백, 스위치 전환, 재시도 제한 중 무엇을 할지 결정한다.
• 근본 원인: 계약, 타임아웃, 락, 캐시, 버전, 운영 절차 중 어디가 깨졌는지 좁힌다.
• 재발 방지: 테스트, 알람, 문서, 기본값을 함께 수정한다.

리뷰 체크리스트

1. 실패 시나리오가 문서와 코드에서 같은 의미로 정의돼 있다.
2. 타임아웃/재시도/락/캐시 같은 보호 장치가 상호 충돌하지 않는다.
3. 관측 지표와 상관관계 키가 있어 운영 중 재현이 가능하다.
4. 롤백 또는 비상 스위치가 준비돼 있다.
5. 최소 1개 이상의 동시성/부하/중간 실패 테스트가 자동화돼 있다.
6. 공식 문서 링크와 팀 의사결정 근거가 남아 있다.

팀 문서 템플릿

팀 문서 템플릿(복붙용):
1) 목표/배경: 어떤 운영 비용 또는 장애를 줄이려는가
2) 범위: API/잡/토픽/디바이스/리전 중 어디까지 적용하는가
3) 규칙: 키, 상태, 버전, TTL, timeout, retry 기본값
4) 예외: 허용하지 않는 상황과 에러 코드/조치 기준
5) 운영: 대시보드, 알람, 소유 팀, 점검 주기
6) 장애 대응: 임시 조치, 롤백, 후속 공지 절차
7) 변경 이력: 언제 누가 왜 기본값을 바꿨는가

FAQ(자주 묻는 질문)

Q. 처음부터 완벽하게 설계해야 하나요?
A. 아니다. 핵심 경로 1개부터 적용하고, 운영 지표를 보며 기본값을 보정하는 편이 실제로 더 안전하다.

Q. "Elasticsearch 샤드 설계 실전: shard/replica 개수와 검색 성능을 같이 보는 기준"를 도입했는데도 문제가 남아 있습니다. 어디부터 봐야 하나요?
A. 먼저 상관관계 키가 있는 로그와 지표로 실패 범위를 좁히고, 최근 배포/설정 차이를 확인한다. 대부분은 기본값보다 경계 조건에서 터진다.

Q. 팀 합의가 자꾸 흔들립니다. 무엇을 문서로 남겨야 하나요?
A. 상태 전이, 기본값, 예외 처리, 롤백 기준 네 가지는 반드시 남겨야 한다. 이 네 가지가 없으면 장애 때 판단이 흔들린다.

참고/출처

• Elastic: Size your shards
• Elastic: Index lifecycle management