Immichは速度が低下するまでに何人の同時ユーザーに対応できますか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How Many Concurrent Users Can Immich Handle Before It Slows Down? - Zima Store Online

すべてのホームサーバーが処理できる、同時接続するImmichユーザー数に共通する有用な数字はありません。なぜなら「1ユーザー」が、アイドル状態での閲覧、顔検索、大容量アップロード、動画再生、複数のバックグラウンドジョブの同時実行のいずれを意味するのかによって異なるからです。

容量は、自宅で実際に発生するワークロードのうち、応答時間とエラーに関する自分の基準を満たし続けられる、再現可能な最大負荷として測定すべきです。負荷のない基準値を確立し、現実的な複数アクションを再現し、同時実行数を管理された段階で増やし、最初に飽和するリソースを監視します。こうすれば、根拠のないユーザー上限ではなく、ハードウェアとライブラリに基づく信頼できる容量範囲を得られます。

ユーザー数を数える前に「遅くなる」の定義を決める

自宅で重要な、ユーザーから見えるアクションを少数選びます。タイムラインを開く、古いアルバムを読み込む、検索、動画再生、バッチのアップロードなどです。テスト前に、許容できない遅延、タイムアウト、アップロード失敗、再生の停止、ユーザーが操作をやめた後も増え続けるキューなど、何を失敗とみなすかを決めておきます。

フォアグラウンド作業とバックグラウンド作業を、記録せずに混在させないでください。サムネイル生成、動画のトランスコード、顔認識処理、Smart Search、ライブラリスキャン、データベースのメンテナンス、バックアップは、アクティブユーザーと同じCPU、メモリ、ディスク、ネットワークのリソースを消費します。大規模なインポート中に行う「4ユーザー」のテストは、安定したライブラリを4人が閲覧する場合とは異なるワークロードです。

各結果には、ハードウェア、Immichのバージョン、データベースの配置場所、ストレージの種類、ネットワーク回線、ライブラリのサイズ、実行中のバックグラウンドジョブを記録します。この情報がなければ、アップグレード後や別のホームサーバーとの同時実行数を意味のある形で比較できません。

バックグラウンド作業を管理した状態で1ユーザーの基準値を測定する

システムが既知の状態にあるときに開始し、代表的な1ユーザーの操作手順を測定します。クライアントの応答時間とともに、サーバーのCPU、メモリプレッシャー、ディスクレイテンシまたは使用率、ネットワークスループット、データベースのアクティビティ、確認可能なImmichワーカーのキューを記録します。

容量に関する説明が意味を持つのは、ワークロード、テスト時間、成功基準が明確な場合だけです。ワークロードベースの容量テストを使って1ユーザーの基準値を保存し、その後、同時実行数の増加に伴って遅延、スループット、エラーがどのように変化するかを測定します。

1ユーザーですでに遅い場合は、同時実行テストを中止してください。まず単一ユーザー時のボトルネックを解消します。セッションを増やしても、既存のストレージ、データベース、CPU、ネットワーク、設定の問題が拡大するだけで、サーバー本来のスケーリング特性についてはほとんど分かりません。

現実的な同時実行数を管理された段階で増やす

各段階でアクションの構成を同程度に保ちながら、ユーザーまたはスクリプト化したクライアントセッションを徐々に追加します。家庭内での有用な手順としては、少数の基準値からアクティブセッション数を倍増させる方法がありますが、具体的な数値よりも、同時実行数だけを変え、ワークロードの定義を一定に保つことが重要です。

テスト前に遅延、エラー、スループットの上限を定義し、1つのエンドポイントに負荷を集中させるのではなく、現実的な複数ステップの操作手順を使います。Immich向けの現実的な負荷テスト用ワークロードでは、写真サーバーの容量の代わりとしてログインリクエストを繰り返すのではなく、家庭で実際に行うアクションを組み合わせるべきです。

各段階は、キャッシュ、キュー、データベース接続、ストレージ需要が安定するまで十分な時間継続します。ピーク値と、負荷を取り除いたときにシステムが回復するかどうかの両方を記録します。短時間のバーストでは問題なく見えても、増え続けるジョブキューを残すサーバーは、そのワークロードに対してすでに持続可能な水準を超えています。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

最初に飽和するリソースを特定する

遅延が急増したら、その時刻とリソースの挙動を関連付けます。検索や機械学習中のCPU飽和は計算リソースの圧迫を示します。CPU使用率が中程度なのにディスクレイテンシが高い場合は、データベースまたはメディアストレージが原因である可能性があります。ネットワーク回線が使い切られている場合は、転送またはリモートアクセスの制限が考えられます。データベースの待機時間や接続の圧迫が増えている場合は、データ層が原因です。

バックグラウンドジョブによって結果が変わることがあります。サムネイル作成、トランスコード、機械学習、スキャン、バックアップ、リトライループは、誰もアクティブに閲覧していないときでもリソースを消費する可能性があります。Immichのバックグラウンド負荷の条件を管理した状態でもテストを比較し、スケジュールされた作業をユーザー数の低い上限と取り違えないようにします。

クライアントのタイムアウトを長くしてエラーを隠すことで、容量の問題を「解決」しないでください。重いジョブのスケジュール設定、ストレージ配置の改善、同時トランスコード数の削減、計算リソースの追加など、制限要因またはワークロードのポリシーを変更します。そのうえで、失敗した段階を完全に再実行し、ボトルネックが移動または解消したことを確認します。

実用的な家庭内容量の範囲を設定し、再テストする

実用上の容量とは、必要なすべてのユーザー操作が事前に設定した遅延とエラーの上限内に収まり、テスト後にキューが基準値へ戻り、ホストが通常のバックグラウンド作業に十分な余力を残せる、テスト済み同時実行数の最大値です。Immich全体の最大値ではなく、ワークロード固有の範囲として報告します。

境界となる段階を、比較可能なクリーンな状態から少なくとももう一度実行し、以前に性能低下を引き起こしたアクションを含めます。その後、次に高い段階を短時間だけテストして、制限の境界が同じリソースに現れることを確認します。ただし、制御不能なキューやストレージ圧迫イベントを発生させるほどシステムを追い込まないでください。

Immichの大規模なアップグレード、データベースの移行、ストレージの変更、ハードウェアの変更、またはライブラリサイズの大幅な増加後には、同じテストを再実行します。容量の数値は現在のシステムとワークロードに固有のものです。古いユーザー数を残すよりも、テスト手順を維持するほうが価値があります。