はじめに
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 インスタンスで効率よく複数テナントにサービスを提供し、管理コストを抑えながら各テナントの要件に応えることができます。
次回は、検索システムのスケール戦略について扱います。