들어가며
Fess를 소규모로 도입한 후, 이용이 확대됨에 따라 “더 많은 문서를”, “더 많은 사용자에게”, “더 빠른 검색을”이라는 요구가 발생합니다.
본 기사에서는 소규모 싱글 서버 구성부터 대규모 클러스터 구성까지 단계적으로 스케일하는 전략과 판단 기준을 설명합니다.
대상 독자
Fess의 대규모 운용을 계획하고 있는 분
성능 문제에 직면하고 있는 분
OpenSearch 클러스터의 기본 개념을 이해하고 싶은 분
스케일의 단계
Fess의 스케일은 일반적으로 다음 단계로 진행됩니다.
| 단계 | 구성 | 문서 수 기준 | 사용자 수 기준 | 비용 |
|---|---|---|---|---|
| S | 싱글 서버 | ~100만 건 | ~50명 | 낮음 |
| M | 분리 구성 | ~100만 건 | ~500명 | 중간 |
| L | 클러스터 구성 | 100만~1,000만 건 | ~수천 명 | 높음 |
| XL | 멀티 인스턴스 | 1,000만 건~ | 수천 명~ | 최고 |
단계 S: 싱글 서버 구성
제2회에서 구축한 Docker Compose 구성이 이에 해당합니다. Fess와 OpenSearch가 동일한 서버에서 동작합니다.
적용 장면
도입 초기, PoC, 소규모~중규모 조직
문서 수가 100만 건 이하
동시 검색 사용자가 적음
튜닝 포인트
JVM 힙 조정
Fess와 OpenSearch 각각의 JVM 힙 크기를 적절하게 설정합니다.
Fess: 최대 2GB (기본값. 초기 힙은 256MB)
OpenSearch: 물리 메모리의 50% 이하, 단 32GB 이하
스레드 풀
크롤링 시의 스레드 수를 서버의 CPU 코어 수에 맞게 조정합니다.
단계 M: 분리 구성
Fess 서버와 OpenSearch 서버를 물리적으로 분리합니다.
적용 장면
동시 검색 사용자가 증가하고 크롤링 중 검색 성능이 문제가 되는 경우
단계 S에서 메모리나 CPU가 부족해지기 시작한 경우
구성
[Fess 서버] <-> [OpenSearch 서버]
Fess 설정에서 OpenSearch 접속 대상을 외부 서버로 변경합니다.
장점
Fess(크롤링 처리)와 OpenSearch(검색 처리)의 리소스 경합 해소
각 서버에 최적의 리소스(CPU, 메모리) 할당 가능
OpenSearch 서버의 디스크 I/O가 독립적
단계 L: 클러스터 구성
OpenSearch를 클러스터 구성으로 하여 검색의 중복성과 성능을 향상시킵니다.
적용 장면
문서 수가 100만~1,000만 건
고가용성이 요구되는 경우
검색 응답 개선이 필요한 경우
구성 예
[Fess 서버]
|
[OpenSearch 노드 1] (마스터/데이터)
[OpenSearch 노드 2] (데이터)
[OpenSearch 노드 3] (데이터)
OpenSearch 클러스터는 샤드와 레플리카 개념으로 데이터를 분산 및 중복화합니다.
샤드: 인덱스를 분할하여 여러 노드에 분산 배치 (병렬 처리로 고속화)
레플리카: 샤드의 복사본을 다른 노드에 보관 (장애 시 중복성 + 검색 병렬화)
설정 포인트
샤드 수: 문서 수와 검색 성능에 따라 설정 (샤드당 10~50GB가 기준)
레플리카 수: 최소 1 (중복성 확보)
노드 수: 최소 3 (마스터 선출을 위한 쿼럼)
단계 XL: 멀티 인스턴스 구성
Fess 자체도 여러 인스턴스로 구성하여 크롤링과 검색 처리를 분산합니다.
적용 장면
문서 수가 1,000만 건을 초과
대량의 크롤링 작업을 병렬로 실행해야 하는 경우
검색 요청이 고빈도
구성 예
[로드 밸런서]
+-- [Fess 인스턴스 1] (검색 + 관리)
+-- [Fess 인스턴스 2] (검색)
+-- [Fess 인스턴스 3] (크롤링 전용)
|
[OpenSearch 클러스터]
+-- [노드 1] (마스터)
+-- [노드 2] (데이터)
+-- [노드 3] (데이터)
+-- [노드 4] (데이터)
Fess 15.6 이후에는 분산 코디네이터 기능을 통해 여러 Fess 인스턴스 간에 유지보수 작업(인덱스 재구축이나 클리어 등)의 배타 제어가 가능합니다.
스케일 판단 플로차트
성능 문제가 발생한 경우, 다음 순서로 원인을 특정하고 대책을 검토합니다.
1. 검색이 느린 경우
OpenSearch 클러스터 상태 확인
JVM 힙 사용률 확인
인덱스 크기 확인
-> 단계 M(분리) 또는 단계 L(클러스터화) 검토
2. 크롤링이 느리거나 완료되지 않는 경우
크롤링 대상 문서 수 확인
스레드 수와 인터벌 조정
크롤링 중 검색에 대한 영향 확인
-> 단계 M(분리) 또는 단계 XL(크롤링 전용 인스턴스) 검토
3. 동시 접속이 많은 경우
검색 응답 시간 모니터링
Fess 서버의 CPU 사용률 확인
-> 단계 XL(로드 밸런서 + 복수 인스턴스) 검토
JVM 튜닝
어떤 단계에서든 JVM 튜닝은 성능에 큰 영향을 미칩니다.
주요 파라미터
| 파라미터 | 설명 | 권장값 |
|---|---|---|
-Xmx | 최대 힙 크기 | 물리 메모리의 50% 이하 |
-Xms | 초기 힙 크기 | ``-Xmx``와 동일한 값 |
| GC 설정 | 가비지 컬렉션 방식 | G1GC (기본값) |
힙 크기 기준
100만 건 이하: 2~4GB
100만~500만 건: 8GB
500만~1,000만 건: 16GB
1,000만 건 이상: 32GB 이상 (OpenSearch 측)
정리
본 기사에서는 Fess의 단계적 스케일 전략을 설명했습니다.
단계 S: 싱글 서버 (~100만 건)
단계 M: Fess / OpenSearch 분리 (~100만 건, 다수 사용자 대응)
단계 L: OpenSearch 클러스터화 (100만~1,000만 건)
단계 XL: Fess 멀티 인스턴스 (1,000만 건~)
스케일 판단 플로차트와 JVM 튜닝
“작게 시작하여 필요에 따라 크게 키운다”는 접근 방식으로 비용을 억제하면서 요건에 맞는 스케일링이 가능합니다.
다음 회에서는 보안 아키텍처에 대해 다룹니다.