ホームサーバーにサービスを追加すると、Immichのデプロイアーキテクチャが変わるのはなぜですか？

Immich自体が他のアプリに合わせて設計を変更するわけではありませんが、共有ホームサーバーで競合するサービスが増えると、そのデプロイアーキテクチャはより分割される傾向があります。

シンプルな写真サーバーは、ストレージ、DNS、自動化、メディアストリーミング、バックアップ、実験用サービスと並行してImmichを実行する1台のホストから始められます。これらのワークロードが増えると、CPU、メモリ、ディスクI/O、ネットワーク帯域幅、再起動のタイミング、障害復旧をめぐって競合します。したがって、アーキテクチャの変更は運用者の判断です。共有境界を維持するコストが低い間は役割をまとめ、競合や保守コストを測定できる役割だけを分離します。

Immichにはすでに複数のサービス役割がある

Immichを1台のマシンで実行しているからといって、ワークロードが分割できない単一プロセスという意味ではありません。写真アプリケーションには、Web/API処理、永続データベース処理、キャッシュまたはキューの調整、機械学習による推論、メディアファイル、生成済み派生ファイルがあります。これらの役割を1台のホストに置くのは、多くの場合もっとも簡単な選択です。しかし論理的な分離は重要です。各役割はマシンに異なる負荷をかけ、後から独自の運用境界になり得るためです。

2026年の実践的なデプロイ例では、Immichサーバー、機械学習、PostgreSQL、Redis系の調整処理を含む4つのコンテナが使われています。正確なコンテナイメージの詳細はImmichのリリースによって変わる可能性があるため、長期的に重要なのは、特定バージョンの固定されたスタックではなく、サービス役割の分割です。これらの役割は、1台の物理サーバー上に置いたまま、ローカルストレージを共有することもできます。

このため、デプロイアーキテクチャは自動的に分散化されるのではなく、柔軟に拡張・分割できます。小規模な家庭では、ネットワークや管理の負担を抑えるため、すべてをまとめておくのがよいでしょう。ある役割のコストが不釣り合いに大きくなった場合、たとえば負荷が断続的に高まるMLジョブやデータベースI/Oなどでは、写真プラットフォーム全体を作り直すのではなく、その役割に制限を適用したり、処理スケジュールを変えたり、役割だけを移動したりできます。

サービスが増えると、1台のホストが競合ドメインになる

Immichの設定を何も変えなくても、サービスを追加するとImmichを取り巻く環境は変わります。メディアのトランスコードはCPUを消費し、バックアップはストレージを飽和させ、自動化用データベースはメモリの圧迫を強め、別のコンテナはImmichがサムネイルを生成しているのと同時に大量の書き込みを発生させることがあります。ホストは競合ドメインとなり、無関係なアプリケーションが共有ハードウェアを通じて写真サーバーのレイテンシーを変化させます。

コンテナ化しても、この結合が自動的に解消されるわけではありません。最近のホームラボ向けリソース制御の解説では、意図的に制限を設定しない限り、Dockerではワークロードが競合し続ける可能性があり、CPU、メモリ、ディスクの圧迫によってノイジーネイバーが発生すると説明されています。リソース制限は干渉を減らせますが、物理的なI/Oやメモリを増やすものではありません。割り当てと障害時の挙動を予測しやすくするだけです。

だからこそ、個別のハードウェアを導入する前に、サービススタックが魅力的になります。ZimaSpaceによるサービススタックの分析では、ホームサーバーが複数の連携・競合する役割をホストするようになると、明確な境界によって依存関係とリソースの所有権を把握しやすくなるという、同じアーキテクチャ上の圧力が説明されています。Immichでは、2台目のマシンが必要だと決めつける前に、まず制限と可観測性から始めましょう。

分割すれば、重い役割を異なるハードウェアに合わせられる

Immichのすべての役割が同じハードウェアの恩恵を受けるわけではありません。データベースアクセスでは予測しやすいメモリ容量とストレージレイテンシーが重要です。メディア処理やサムネイル生成ではCPUとI/Oの負荷が急増することがあり、機械学習ではメインのストレージホストにないアクセラレーションが役立つ場合があります。これらの役割をすべて1つのハードウェア構成に固定すると、もっとも負荷の高い役割に合わせて、他の役割にとっては過剰に大きく、または騒がしいサーバーを用意することになりかねません。

最近のセルフホスティング事例では、機械学習サービスに独自のリソース要求、制限、永続的なモデルキャッシュを設定し、アプリケーションサーバーと区別しています。この方法が重要なのは、MLがCPUやGPUリソースを個別に割り当てるのに適している一方、写真ライブラリとデータベースはストレージやバックアップの運用がもっとも簡単な場所に残せるためです。

境界は、測定された不一致を解消するものであるべきです。MLの負荷急増がブラウジングの遅延と重なるなら、MLを分離または再スケジュールすることで干渉を減らせます。一方、通常利用中にMLがすでにアイドル状態なら、移動によってネットワークと保守の依存関係が増えるだけで、応答性は改善しません。ストレージやデータベースの配置にも同じルールが当てはまります。リモートデプロイが可能だからというだけで、すべての役割を分割するのではなく、共有ホストの問題を引き起こしているリソース特性を持つ役割を分割しましょう。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

境界が増えると、障害の起こり方も増える

ワークロードの分割は、無償の信頼性向上ではありません。リモートデータベースには安定したネットワーク接続が必要で、リモートストレージではローカルのファイル操作がネットワーク依存に変わり、別のMLホストを追加すると、管理すべきマシン、アドレス、認証情報、再起動順序が増えます。各境界はある障害を隔離できますが、正常に動作しているImmichサーバーが必要なものにアクセスできなくなる新たな経路を作ることもあります。

ホームラボの運用者がローカルストレージを重視することが多いのは、自己完結型のノードなら別のストレージやネットワーク経路に依存せず稼働でき、障害ドメインを把握しやすくなるためです。Immichではすべての役割をローカルに置く必要はありませんが、追加のボックスを増やせば自動的にレジリエンスが高まると考えるアーキテクチャ図に対して、この原則は有用な反対材料になります。

新たなネットワークまたはサービス依存によって、元のリソース競合よりも多くの障害、復旧手順、設定のずれが発生するようになったとき、障害境界に達したといえます。データベース、キャッシュ、メディアパスを分割する前に、リモートノードが利用できない場合に何が起こるか、バックアップからどのように復元するかを文書化してください。その答えが現在の共有ホストを使い続けるより難しいなら、分割は時期尚早です。

分割するのは、測定された問題を境界によって解決できる場合だけ

CPU、メモリ、ストレージレイテンシー、保守時間が予測可能で、無関係なサービスによる目に見える干渉がない間は、Immichを1台のホストで運用しましょう。別のマシンを購入する前に、コンテナの制限、スケジュール設定、監視を使って問題の原因を特定してください。シングルホスト設計はネットワーク依存が少なく、バックアップ、パッチ適用、復旧も簡単なことが多いため、家族の写真システムにとって実質的なアーキテクチャ上の利点があります。

最終的にホームラボを分割する運用者は、分散設計が本質的に優れているからではなく、共有インフラによって共有ボトルネックや保守時の影響範囲が生じるために分割することが多いのです。同じ記事では、その運用上の痛みが現れるまでは小規模な構成をシンプルに保つことも推奨されています。Immichにとっても、これが有用な判断基準です。アーキテクチャは、診断された制約に従うべきです。

変更は一度に1つだけ行いましょう。MLの負荷急増がAPIレイテンシーを悪化させるなら、MLを分離または再スケジュールして再測定します。バックアップが同じディスクを飽和させるなら、バックアップの時間帯またはストレージパスを分けます。無関係なサービスによって再起動が危険になるなら、ライフサイクルの境界を分けます。測定した問題が改善し、許容できない復旧依存関係も生じない場合にだけ、その変更を維持してください。最良のImmichデプロイとは、観測されたパフォーマンスと障害復旧の要件を満たしながら、もっとも単純なトポロジーです。