Skip to content

성능 체크

워크로드 기준(TPS)에 따른 구성 사례

예상 TPS 사용 사례 CPU RAM 구성 형태 벤치마크 참고
~10 TPS 내부 PoC, 팀 문서 검색 4 vCPU 8 GB 단일 노드 일반적으로 검색 응답 속도 약 30–100ms이다
10–50 TPS 쇼핑몰, 사내 검색 등 8 vCPU 16 GB 단일 클러스터, 벡터 가능 OpenSearch 3.0에서 벡터 처리 성능 2.5배 향상됨 (OpenSearch)
50–300 TPS 실시간 로그 분석, 실시간 상품 검색 16 vCPU 32 GB 다중 노드 구성 권장 2.17에서 저지연 응답 위해 동시 세그먼트 검색 도입
300+ TPS 실시간 광고 등 초고속 검색 32+ vCPU 64 GB 이상 샤드 분산, ML/GPU 노드 분리 필수 CCR 테스트에서 leader CPU 사용량만 12% 증가

색인 규모 기준 사례

색인 규모 문서 수 구성 추천
< 1 M 수십만 문서 4 vCPU, 8 GB
1–10 M 뉴스·상품 8 vCPU, 16 GB
10–100 M 로그, 대규모 상품 16 vCPU, 64 GB, 복수 노드
> 100 M SIEM, 빅데이터 32+ vCPU, 128 GB+, 완전 분산

벡터 검색 및 엔진 비교 성능

  • OpenSearch 3.0에서 벡터 검색 성능이 2.5배 향상됨 (OpenSearch).

  • Elastic 社 BBQ vs OpenSearch FAISS 비교 결과, Elastic 제품이 최대 5배 빠름 (Elastic).

  • 그러나 독립 벤치마크 결과 OpenSearch 2.17.1이 Elastic 8.15.4 대비 벡터 검색에서 P90 기준 11% 빠름 (The Trail of Bits Blog).

실제 사례 추가

사례 1: Elastic vs OpenSearch 비교 테스트

Trail of Bits 테스트에서 OpenSearch 2.17.1은 Big5 워크로드에서 Elastic 보다 1.6배 빠르고, 벡터 워크로드에서는 11% 더 빠른 성능을 보였다 (The Trail of Bits Blog).

사례 2: CCR(교차 클러스터 복제) 영향

AWS 벤치마크에 따르면, leader 노드의 CPU 사용률이 +12.4%, 90th percentile 인덱싱 지연이 +3.9% 증가했지만 검색 성능은 거의 영향 없었다 (Instaclustr).

사례 3: Disk‑optimized 벡터 엔진 사례

Amazon OpenSearch Service에서 disk 모드 사용 시 메모리 97% 절감, P90 응답 100–200ms로 유지되며 비용 효율적임 (Amazon Web Services, Inc.).

요약: 기준 및 구성 예시 정리

  1. TPS(트래픽)

    • ~10 TPS: 4 vCPU/8GB

    • 50–300 TPS: 16 vCPU/32GB, 다중 노드

    • 300+ TPS: 32+ vCPU/64GB 이상, 클러스터 분리

  2. 색인 규모

    • < 1M: 4 vCPU/8GB

    • 1–10M: 8 vCPU/16GB

    • 10–100M: 16 vCPU/64GB

    • 100M: 32+ vCPU/128GB+, 분산 노드

  3. 검색 유형

    • BM25: 경량 구성 가능

    • 벡터/하이브리드: CPU 중심 2.5배 속도 향상

    • RAG/AI 재랭킹: GPU 포함 ML 서버 별도 구성 추천

  4. 엔진·모드 선택

    • on‑disk 모드로 메모리 최적화 (P90 200ms)

    • concurrent segment search, disk‑optimized vector engine 사용