Immichのスケーリング
Immichは最新のデプロイメント手法に基づいて構築されており、バックエンドは複数のインスタンスを並列に実行可能な設計になっています。この場合、唯一注意すべき要件は、すべてのインスタンスが共有インフラに接続されている必要がある点です。つまり、すべてのインスタンスが同じPostgresとRedisを利用し、同じファイルがコンテナ内にマウントされている必要があります。
スケーリングはさまざまな理由で役立ちます。例えば、ゲーム用PCを使ってトランスコーディングやサムネイル生成を行いたい場合や、複数の強力なサーバで構成されたKubernetesクラスタを活用したい場合などです。
Immichを実行するための単一のマシンしかない場合、複数のコンテナへのスケーリングは特にメリットをもたらさない可能性があります。Immichコンテナは複数のバックグラウンドタスクを同時に実行し、管理パネルからその数を増やすことができます。
複数のマシン間でスケーリングする方法の詳細は環境によって大きく異なり、設定には一定の知識が必要です。そのため、このガイドでは具体的な指示はありません。場合によっては、Kubernetesデプロイメ ントのレプリカ数を増やすだけで簡単にスケーリングを行えることもありますし、ネットワークトンネルやNFSマウントを構成する必要がある場合もあります。詳細は読者の自由にお任せします ;)
ワーカー
デフォルトでは、実行中の各immich-serverコンテナには複数の内部ワーカーが含まれています。もしバックグラウンドタスクを処理するためだけにスケーリングを行う場合、APIを担当するワーカーを無効にすることができます。詳細についてはワーカーをご覧ください。
スケーリングの縮小
複数のコンテナにスケールアップするのと同様に、スケールダウンを選ぶこともできます。すべての状態はPostgres、Redis、およびファイルシステムに保存されるため、たとえばGPUを使ってゲームをするために実行中のimmich-serverコンテナを停止してもリスクはありません。APIワーカーが稼働している限り、Immichを引き続き閲覧することができ、ジョブはワーカーが利用可能になるまで処理待ち状態になります。