OpenSearch 3.3 업그레이드로 미리캔버스 검색 성능 60% 향상!

Amazon OpenSearch 3.3으로의 메이저 버전 업그레이드는 stored fields 비대화 문제 해결과 세그먼트 병합 효율 증대라는 두 가지 핵심 목표를 달성했습니다. 특히 derived source 기능은 벡터 데이터를 _source 필드에 중복 저장하지 않고 필요 시 벡터 인덱스에서 재구성하여 스토리지 사용량을 최대 50%까지 줄이는 효과를 가져왔습니다. 또한, Lucene 10.3 기반의 세그먼트 병합 개선은 floor_segment 기본값을 8배 늘리고 maxMergeAtOnce를 증가시켜, 대량 업데이트 후 발생하는 세그먼트 병합 폭증 문제를 완화했습니다. 이로 인해 CPU 사용률은 약 40%, 검색 레이턴시는 60% 감소하는 실질적인 성능 향상을 이루었습니다.

OpenSearch 3.0부터 기본 적용된 concurrent segment search는 샤드 내 여러 세그먼트를 병렬로 탐색하여 세그먼트 수가 많아도 레이턴시를 낮게 유지하는 데 기여했습니다. 이전 버전에서는 세그먼트 수를 줄이기 위한 _forcemerge 작업이 필수적이었으나, 이제는 병렬 탐색 기능 덕분에 세그먼트 수 증가에 대한 부담이 크게 줄었습니다. 또한, 양자화(Quantization) 옵션은 float32 대신 더 작은 데이터 타입으로 벡터를 저장하여 메모리 사용량을 절감할 수 있는 선택지를 제공합니다. 미리디는 향후 FP16 적용을 검토하며 메모리 효율성을 더욱 높일 계획입니다.

서비스 무중단, 안전한 롤백, 충분한 검증 구간 확보라는 세 가지 기준을 충족하기 위해 신규 클러스터 구축 후 도메인 스위칭 방식을 채택했습니다. Rolling Upgrade 방식은 프로덕션 트래픽 영향, 샤드 버전 불일치, 어려운 롤백 등의 리스크가 있어 배제되었습니다. 신규 클러스터에서는 인덱스 설정 재정비와 벡터 인덱스 재빌드를 통해 기술 부채를 해소하고 최신 엔진의 성능을 온전히 활용할 수 있었습니다. 마이그레이션 당일에는 write 배치 중단, 스냅샷 기반 복원, 쿼리 테스트, 버전 업그레이드, 재인덱싱, alias 변경 순서로 진행하여 하루 안에 작업을 완료했습니다.

Derived source 적용으로 stored fields 크기가 크게 줄면서 OS 페이지 캐시 여유 공간이 확보되었고, 이로 인해 페이지 캐시 스래싱 현상이 완화되었습니다. 결과적으로 디스크 I/O가 감소하여 이전 버전에서 심각한 문제였던 IOPS Throttling이 완전히 사라졌습니다. 또한, Read IOPS Microbursting MAX 값이 5,250에서 3,500으로 약 33% 감소하며 I/O 스파이크가 안정화되었습니다. 이는 메모리 부족 → 페이지 캐시 미스 → 디스크 I/O 폭증 → IOPS Throttling으로 이어지던 악순환을 근본적으로 해결한 결과입니다.

페이지 캐시 스래싱 완화와 세그먼트 수 감소는 CPU 사용률 안정화에도 크게 기여했습니다. 이전에는 간헐적으로 80%까지 치솟던 CPU 스파이크가 3.3 버전업 이후 크게 줄었습니다. 프로덕션 환경에서는 평균 레이턴시가 59%, 최대 레이턴시가 85% 감소하는 극적인 개선을 보였습니다. 이는 세그먼트 수가 37% 줄어든 효과와 더불어, 향상된 k-NN 그래프 품질, 페이지 캐시 히트율 증가, Lucene 10.3의 쿼리 처리 최적화 등이 복합적으로 작용한 결과입니다.

안정화된 3.3 환경에서 FP16(Half-Precision) 도입을 검토 중입니다. 벡터 데이터 저장 용량을 절반으로 줄여 메모리 효율성을 높이고, 이를 통해 정확도 높은 HNSW 알고리즘 적용이나 IVF/PQ 파라미터 공격적 조정으로 리콜(Recall)을 향상시킬 수 있습니다. 또한, 정기 재인덱싱을 운영 프로세스로 도입하여 삭제 마킹된 문서 관리, 세그먼트 파편화 해소, 벡터 그래프 최적화 등 기술 부채 누적을 방지하고 꾸준한 성능 유지 기반을 마련할 계획입니다.