第14回 検索システムのスケール戦略 -- 小規模から大規模への段階的拡張

はじめに

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 のクラスターは、シャードとレプリカの概念でデータを分散・冗長化します。

シャード: インデックスを分割して複数のノードに分散配置（並列処理で高速化）

レプリカ: シャードのコピーを別のノードに保持（障害時の冗長性 + 検索の並列化）

設定のポイント

  • シャード数: ドキュメント数と検索パフォーマンスに応じて設定（1シャードあたり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 のチューニングはパフォーマンスに大きく影響します。

主要なパラメータ

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 チューニング

「小さく始めて、必要に応じて大きく育てる」アプローチで、コストを抑えながら要件に応じたスケーリングが可能です。

次回は、セキュリティアーキテクチャについて扱います。

参考資料