Elasticsearch 신입 트러블슈팅 면접

429 에러는 Elasticsearch의 스레드 풀이 가득 차서 더 이상 요청을 처리할 수 없을 때 발생합니다. 주로 bulk 인덱싱 시 너무 많은 요청을 동시에 보내거나, 클러스터의 리소스가 부족할 때 나타납니다. 해결 방법으로는 bulk 요청의 크기를 줄이거나 배치 간 딜레이를 추가하는 방법이 있습니다. 또한 _cat/thread_pool API로 스레드 풀 상태를 확인하고, 필요시 클러스터 리소스를 증설해야 합니다. 재발 방지를 위해서는 적절한 bulk size와 요청 간격을 설정하고 모니터링을 강화해야 합니다.

먼저 _search API에 profile 파라미터를 추가하여 쿼리의 세부 실행 시간을 분석합니다. 이를 통해 어떤 부분에서 시간이 오래 걸리는지 파악할 수 있습니다. 다음으로 _cat/indices API로 인덱스 크기와 샤드 상태를 확인하고, _cluster/health로 클러스터 전체 상태를 점검합니다. 느린 쿼리 로그(slowlog)를 확인하여 패턴을 분석하고, 필요시 쿼리를 최적화하거나 인덱스 설정을 조정합니다. 캐시 히트율도 _stats API로 확인하여 캐시 효율성을 점검해야 합니다.

yellow 상태는 모든 primary 샤드는 할당되었지만 일부 replica 샤드가 할당되지 않은 상태를 의미합니다. _cat/shards API로 어떤 샤드가 unassigned 상태인지 확인하고, _cluster/allocation/explain API로 샤드가 할당되지 않은 구체적인 이유를 파악합니다. 주요 원인으로는 노드 수 부족, 디스크 공간 부족, 샤드 할당 설정 문제 등이 있습니다. 단일 노드 환경이라면 replica 수를 0으로 조정하거나, 노드를 추가하여 해결할 수 있습니다. 디스크 부족이 원인이라면 오래된 데이터를 삭제하거나 스토리지를 확장해야 합니다.

먼저 Elasticsearch 로그에서 OOM 발생 시점과 힙 메모리 사용량을 확인합니다. _nodes/stats API로 각 노드의 메모리 사용 현황을 분석하고, fielddata, segment 메모리 등 어떤 부분에서 메모리를 많이 사용하는지 파악합니다. 주요 원인으로는 부적절한 힙 크기 설정, 대용량 aggregation 쿼리, fielddata 캐시 과다 사용 등이 있습니다. JVM 힙 크기를 적절히 조정하되 전체 메모리의 50%를 넘지 않도록 설정하고, fielddata 캐시 크기를 제한해야 합니다. 또한 doc_values를 활용하고, 무거운 쿼리는 최적화하거나 제한하여 재발을 방지합니다.

_count API로 인덱스의 전체 문서 수를 확인하여 데이터가 실제로 존재하는지 먼저 파악합니다. 문서가 존재한다면 _get API로 특정 문서 ID를 직접 조회하여 데이터 자체는 있는지 확인합니다. 검색이 안 되는 경우 매핑 설정을 확인하여 필드가 올바르게 인덱싱되었는지 점검하고, _analyze API로 검색어가 어떻게 분석되는지 확인합니다. 실제 데이터가 없다면 삭제 이력을 로그에서 확인하고, refresh 설정이나 bulk 요청 실패 여부를 점검합니다. 재발 방지를 위해서는 snapshot을 정기적으로 생성하고, 중요 작업 시 응답 코드를 반드시 확인해야 합니다.