Elasticsearch 리드·아키텍트 기술면접

샤드 수 결정 시 가장 중요한 원칙은 샤드당 크기를 10~50GB로 유지하고, 노드당 샤드 수를 힙 메모리 1GB당 20개 이하로 제한하는 것입니다. Over-sharding은 각 샤드의 메타데이터가 마스터 노드의 힙 메모리를 과도하게 사용하고, 검색 시 많은 샤드를 조회해야 하므로 오버헤드가 증가합니다. Under-sharding은 개별 샤드가 너무 커져서 복구 시간이 길어지고, 장애 시 영향 범위가 커지며, 리밸런싱의 유연성이 떨어집니다. 일반적으로 데이터 증가율을 고려하여 6개월~1년 후 예상 크기를 기준으로 샤드 수를 결정하며, 시계열 데이터의 경우 ILM을 통해 주기적으로 새 인덱스를 생성하여 샤드 크기를 관리합니다. 프로덕션 환경에서는 모니터링을 통해 샤드당 평균 검색 시간, 인덱싱 처리량, 힙 사용률을 지속적으로 추적하고 필요시 reindex를 통해 샤드 구조를 재조정합니다.

검색은 Query Phase와 Fetch Phase 두 단계로 진행됩니다. Query Phase에서는 coordinate 노드가 모든 관련 샤드에 쿼리를 보내고, 각 샤드는 매칭된 문서의 ID와 정렬 값만 반환합니다. Coordinate 노드는 이를 병합하여 상위 N개를 선정한 후, Fetch Phase에서 해당 문서의 실제 내용을 가져옵니다. Deep Pagination 문제는 from+size가 클 때 각 샤드가 그만큼의 결과를 메모리에 유지해야 하므로, 10,000번째 페이지를 요청하면 모든 샤드에서 10,000개씩 정렬해야 하는 문제입니다. 해결 방법으로 Search After는 이전 결과의 정렬 값을 기준으로 다음 페이지를 가져오므로 메모리 효율적이며 실시간 검색에 적합합니다. Scroll API는 스냅샷을 생성하여 일관된 결과를 보장하지만 컨텍스트를 유지해야 하므로 대량 배치 작업에 적합하고, Point in Time API는 Scroll의 개선 버전으로 더 유연한 컨텍스트 관리를 제공합니다. 일반 사용자 페이징에는 Search After를, 전체 데이터 추출에는 PIT + Search After 조합을 권장합니다.

Refresh는 메모리의 인덱스 버퍼를 디스크의 새로운 Lucene 세그먼트로 작성하여 검색 가능하게 만드는 작업으로, 기본 1초마다 실행되며 실시간 검색성을 제공하지만 빈번한 실행은 성능을 저하시킵니다. Flush는 메모리의 세그먼트를 디스크에 fsync하고 트랜잭션 로그를 비우는 작업으로, 장애 복구 시점을 확정하며 기본 30분 또는 translog 크기 기준으로 실행됩니다. Merge는 작은 세그먼트들을 큰 세그먼트로 병합하여 검색 효율을 높이고 삭제된 문서를 물리적으로 제거하는 백그라운드 작업입니다. 대량 인덱싱 최적화를 위해서는 refresh_interval을 -1로 설정하여 비활성화하고, replica 수를 0으로 줄인 후 인덱싱 완료 후 복구하며, bulk API의 크기를 5~15MB로 조정하고, translog durability를 async로 설정합니다. 또한 index.merge.scheduler.max_thread_count를 조정하여 merge 성능을 최적화하고, 인덱싱 완료 후 force merge로 세그먼트를 통합하여 검색 성능을 향상시킵니다.

Dynamic Mapping은 개발 초기 단계에서 빠른 프로토타이핑이 가능하지만, 의도하지 않은 타입으로 필드가 생성되거나 mapping explosion이 발생할 위험이 있습니다. Explicit Mapping은 스키마를 명확히 정의하여 데이터 품질을 보장하고 성능을 최적화할 수 있으며, 프로덕션 환경에서 필수적입니다. Mapping explosion은 동적으로 생성되는 필드가 무제한 증가하여 클러스터 상태 크기가 비대해지고 성능이 저하되는 문제로, index.mapping.total_fields.limit(기본 1000)을 적절히 설정하여 예방합니다. 예방 전략으로는 dynamic을 strict로 설정하여 정의되지 않은 필드를 거부하거나, dynamic templates를 활용하여 패턴 기반으로 타입을 제어하고, 가변적인 키-값 데이터는 flattened 타입이나 nested 타입을 사용하여 필드 수를 제한합니다. 또한 불필요한 필드는 enabled: false로 인덱싱을 비활성화하고, 검색이 필요없는 필드는 index: false로 설정하여 리소스를 절약합니다.

Split Brain은 네트워크 파티션으로 클러스터가 분리되어 각각 독립적인 마스터를 선출하고 서로 다른 상태로 동작하는 문제로, 데이터 불일치와 손실을 초래합니다. 이는 마스터 선출 시 과반수 합의 없이 진행될 때 발생하며, 각 파티션이 독립적으로 인덱스를 수정하면 나중에 병합이 불가능합니다. 7.x 이전 버전에서는 discovery.zen.minimum_master_nodes를 (master_eligible_nodes / 2) + 1로 설정하여 과반수 쿼럼을 강제했으며, 이 값 미만의 노드만 있는 파티션은 마스터를 선출할 수 없어 Split Brain을 예방했습니다. 7.x 이후에는 cluster.initial_master_nodes로 초기 부트스트랩 시 마스터 후보를 명시하고, 이후에는 자동으로 쿼럼 기반 선출이 적용되어 설정 관리가 단순해졌습니다. 프로덕션에서는 마스터 전용 노드를 3개 또는 5개의 홀수로 구성하고, 네트워크 안정성을 확보하며, 정기적인 클러스터 상태 모니터링을 통해 파티션 징후를 조기 감지해야 합니다.

Query Context는 문서가 쿼리와 얼마나 잘 매칭되는지 relevance score를 계산하며, match, term 등의 쿼리가 bool의 must, should 절에서 실행될 때 적용됩니다. Filter Context는 문서의 포함 여부만 판단하고 스코어를 계산하지 않으며, bool의 filter, must_not 절이나 constant_score 내부에서 실행됩니다. Filter Context는 스코어 계산이 없어 더 빠르고, 결과가 자동으로 캐싱되어 반복 쿼리 시 성능이 크게 향상됩니다. 실무에서는 정확한 매칭 조건(날짜 범위, 상태값, 카테고리 등)은 filter로 처리하여 캐싱 효과를 얻고, 텍스트 검색이나 관련도가 중요한 부분만 query로 처리합니다. 예를 들어 상품 검색 시 재고 있음, 가격 범위, 카테고리는 filter로, 검색 키워드는 must로 구성하여 성능과 정확도를 동시에 확보합니다. Query cache는 샤드 레벨에서 동작하며 전체 쿼리 결과가 아닌 각 세그먼트별 비트셋을 캐싱하므로, 자주 사용되는 필터 조건일수록 효과가 큽니다.

용량 계획의 핵심 요소는 데이터 볼륨, 인덱싱 처리량, 쿼리 복잡도, 보관 기간, SLA 요구사항이며, 이를 기반으로 필요한 노드 수와 스펙을 산정합니다. 데이터 노드는 힙 메모리를 최대 31GB(compressed oops 한계)로 제한하고 전체 메모리의 50%를 힙에, 나머지를 OS 파일 캐시에 할당하며, 디스크는 SSD를 권장하고 전체 용량의 85%를 임계치로 설정합니다. 마스터 노드는 CPU와 메모리가 중요하며 디스크는 최소한으로, 코디네이팅 노드는 집계 쿼리가 많으면 메모리를 크게 할당합니다. 스케일 아웃은 처리량과 가용성이 중요할 때 적합하며 샤드를 분산하여 병렬 처리를 높이고, 스케일 업은 개별 쿼리 성능과 대용량 집계가 중요할 때 적합하지만 단일 장애점 위험이 있습니다. 일반적으로 Elasticsearch는 스케일 아웃에 최적화되어 있으므로, 중간 스펙의 노드를 여러 대 구성하는 것을 권장하며, 핫 데이터는 고성능 노드에, 웜/콜드 데이터는 저사양 노드에 배치하는 티어드 아키텍처를 적용합니다. 모니터링을 통해 CPU 80%, 힙 75%, 디스크 70% 도달 시 확장을 고려해야 합니다.