들어가며
Fess를 사내 여러 부서에 제공하거나 MSP(매니지드 서비스 프로바이더)로서 여러 고객에게 제공하려는 경우, 테넌트마다 Fess를 개별적으로 구축하는 것은 비효율적입니다.
본 기사에서는 하나의 Fess 인스턴스로 여러 테넌트(조직, 부서, 고객)에 서비스를 제공하는 멀티테넌트 설계를 설명합니다.
대상 독자
여러 조직이나 부서에 검색 서비스를 제공하려는 분
Fess의 멀티테넌트 설계에 관심이 있는 분
가상 호스트 기능의 활용 방법을 알고 싶은 분
시나리오
그룹 기업의 IT 부서가 3개의 자회사에 검색 서비스를 제공하는 사례를 가정합니다.
| 테넌트 | 도메인 | 검색 대상 |
|---|---|---|
| A사 (제조업) | search-a.example.com | 제품 사양서, 품질 관리 문서 |
| B사 (소매업) | search-b.example.com | 매장 매뉴얼, 상품 정보 |
| C사 (서비스업) | search-c.example.com | 고객 대응 매뉴얼, FAQ |
각 테넌트에는 다음과 같은 요건이 있습니다.
테넌트 간에 데이터가 보여서는 안 됨 (데이터 격리)
테넌트마다 다른 디자인 (브랜딩)
테넌트마다 독립된 크롤 설정
가상 호스트 기능
Fess의 가상 호스트 기능을 사용하면 접속하는 호스트명에 따라 다른 검색 경험을 제공할 수 있습니다.
가상 호스트 설정
관리 화면에서 가상 호스트의 값을 설정합니다. 이 값을 크롤 설정이나 라벨에 연결함으로써 테넌트별 데이터 격리를 실현합니다.
설계 포인트
DNS / 로드 밸런서 설정
각 테넌트의 도메인이 동일한 Fess 서버를 가리키도록 DNS를 설정합니다.
search-a.example.com → Fess 서버 (192.168.1.100)
search-b.example.com → Fess 서버 (192.168.1.100)
search-c.example.com → Fess 서버 (192.168.1.100)
Fess는 요청의 HTTP 헤더를 확인하여 어떤 가상 호스트에 대한 접속인지를 판별합니다. 기본적으로 Host 헤더가 사용되지만, virtual.host.headers 설정으로 임의의 헤더를 지정할 수 있습니다. 설정 형식은 헤더명:값=가상호스트키 입니다 (예: Host:search-a.example.com=tenant-a).
테넌트 격리 설계
데이터 격리
테넌트 간의 데이터 격리는 가상 호스트 기능에 의한 문서의 virtual_host 필드로 실현합니다.
가상 호스트에 의한 격리
크롤 설정의 “가상 호스트” 필드에 가상 호스트 키를 설정하면, 크롤된 문서에 virtual_host 필드가 부여됩니다. 검색 시에는 이 필드로 자동 필터링되어, 각 테넌트의 도메인으로 접속한 사용자에게는 해당 테넌트의 문서만 검색 결과에 표시됩니다.
tenant-a: A사의 문서tenant-b: B사의 문서tenant-c: C사의 문서
또한 라벨의 “가상 호스트” 필드도 설정하면 테넌트별로 표시하는 라벨도 분리할 수 있습니다.
역할에 의한 격리
더 엄격한 격리가 필요한 경우에는 역할 기반 검색(제5회 참조)을 조합합니다. 테넌트별 역할을 생성하고 크롤 설정과 사용자에 할당합니다.
크롤 설정의 분리
각 테넌트의 크롤 설정은 독립적으로 관리합니다.
| 테넌트 | 크롤 대상 | 스케줄 | 라벨 |
|---|---|---|---|
| A사 | smb://fs-a/docs/ | 매일 1:00 | tenant-a |
| B사 | https://portal-b.example.com/ | 매일 2:00 | tenant-b |
| C사 | smb://fs-c/manuals/ | 매일 3:00 | tenant-c |
테넌트별 테마
Fess의 테마 기능을 사용하면 테넌트마다 다른 디자인을 제공할 수 있습니다.
테마 설계
각 테넌트의 브랜드 컬러와 로고에 맞는 테마를 준비합니다.
A사: 제조업다운 견실한 디자인 (청색 계열)
B사: 소매업의 밝은 디자인 (녹색 계열)
C사: 서비스업의 친근한 디자인 (오렌지색 계열)
가상 호스트와 테마의 연동
가상 호스트별로 테마를 전환함으로써 각 테넌트의 사용자에게는 자사 브랜드의 검색 화면이 표시됩니다.
Fess는 simple, docsearch, codesearch 등의 내장 테마 외에 커스텀 테마도 사용할 수 있습니다.
API 접근의 격리
테넌트별 API 접근 토큰
각 테넌트에 개별 접근 토큰을 발행합니다. 토큰에 역할을 연결함으로써 API를 통한 접근에도 테넌트 격리가 적용됩니다.
| 테넌트 | 토큰명 | 할당 역할 |
|---|---|---|
| A사 | tenant-a-api-token | tenant-a-role |
| B사 | tenant-b-api-token | tenant-b-role |
| C사 | tenant-c-api-token | tenant-c-role |
각 테넌트의 시스템이 API 연동하는 경우(제11회 참조), 테넌트 고유의 토큰을 사용함으로써 다른 테넌트의 데이터에 접근할 수 없음이 보장됩니다.
운용상의 고려 사항
리소스 관리
하나의 Fess 인스턴스로 여러 테넌트에 서비스하므로 리소스 배분에 주의가 필요합니다.
크롤 부하 분산: 테넌트의 크롤 스케줄을 분산시켜 동시 실행을 피함
인덱스 크기: 테넌트 전체의 인덱스 크기를 모니터링
메모리: 테넌트 수와 문서 수에 따라 JVM 힙을 조정
테넌트의 추가 및 삭제
새로운 테넌트를 추가할 때의 절차를 표준화해 둡니다.
라벨 생성
역할 생성
크롤 설정 등록
가상 호스트 설정
접근 토큰 발행
DNS 설정 추가
테넌트를 삭제할 때는 관련 인덱스 데이터의 삭제도 잊지 않고 수행합니다.
스케일링 판단 기준
다음과 같은 징후가 보이면 Fess 인스턴스의 분할이나 스케일링(제14회 참조)을 검토합니다.
검색 응답 시간의 악화
크롤이 스케줄 내에 완료되지 않음
메모리 부족 오류가 빈발
테넌트 수가 10을 초과
정리
본 기사에서는 Fess의 가상 호스트 기능을 활용한 멀티테넌트 설계를 설명했습니다.
가상 호스트에 의한 테넌트별 접근 실현
라벨과 역할에 의한 데이터 격리
테넌트별 테마에 의한 브랜딩
API 접근 토큰에 의한 테넌트 격리
리소스 관리와 스케일링 판단 기준
하나의 Fess 인스턴스로 효율적으로 여러 테넌트에 서비스를 제공하고, 관리 비용을 줄이면서 각 테넌트의 요건에 대응할 수 있습니다.
다음 회에서는 검색 시스템의 스케일 전략에 대해 다룹니다.