이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 Elasticsearch 클러스터를 직접 구성해 검색 기능을 운영한 경험이 있습니다. 단일 노드로 시작했다가 데이터가 늘어나면서 인덱스 크기와 쿼리 응답 시간의 관계를 처음으로 체감했고, 샤드 수 설정이 성능에 영향을 준다는 것을 실험으로 확인했습니다.
인덱스 매핑을 처음에 느슨하게 설정했다가 나중에 변경하려면 재색인이 필요하다는 것을 경험한 뒤, 초기 설계에 더 신경 쓰는 습관이 생겼습니다. 슬로우 쿼리 로그를 활성화해 응답 시간이 긴 쿼리를 찾아냈고, 불필요한 필드를 포함한 와일드카드 쿼리가 주된 원인이었습니다. 데이터 색인과 검색 쿼리를 분리해 인덱스 부하를 낮췄고, 이후 응답 시간이 안정됐습니다. 검색 클러스터 운영은 설계 단계의 결정이 운영 비용을 크게 좌우한다는 결을 이 경험에서 얻었습니다.
검색엔진 클러스터에서 본인 사례로 닫힌 경험은 인덱스 매핑을 느슨하게 설정했다가 재색인이 필요해진 케이스였습니다. 처음에 인덱스 매핑을 구체적으로 정하지 않고 시작했는데, 데이터가 쌓인 뒤 검색 요구사항이 바뀌면서 필드 타입을 변경해야 하는 상황이 됐습니다.
Elasticsearch에서는 이미 색인된 데이터의 필드 타입을 변경하려면 전체 재색인이 필요하다는 것을 그때 이해했습니다. 이후에는 초기 인덱스 설계를 더 신중하게 하는 방식이 자리 잡았습니다. 검색 클러스터에서 인덱스 설계는 나중에 변경 비용이 크기 때문에 초기에 요구사항을 충분히 검토하는 것이 중요하다는 결이 생겼습니다.
검색엔진 클러스터에서 측정 가능한 결과로 닫힌 경험은 슬로우 쿼리 원인을 찾고 개선 효과를 확인한 케이스였습니다. 응답 시간이 느린 구간이 있었는데, 슬로우 쿼리 로그를 활성화하자 와일드카드 쿼리가 주된 원인이라는 것이 명확해졌습니다.
쿼리 방식을 변경한 뒤 동일한 방식으로 응답 시간을 측정했더니 개선이 수치로 확인됐습니다. 검색 성능 문제는 추측으로 접근하기보다 슬로우 쿼리 로그로 원인을 확인한 뒤 개선해야 효과도 측정할 수 있다는 결이 남아 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.