非アクティブな期間中にコンテナー アプリがゼロにスケーリングされると、次の受信要求によって コールド スタートがトリガーされます。 コールド スタートは、コンテナー イメージのプル、リソースのプロビジョニング、アプリケーション コードの開始に時間がかかるプロセスです。
この遅延は、特に応答時間が速いアプリケーションの場合に、ユーザー エクスペリエンスに影響します。 コールド スタートは、多くの場合、大規模なコンテナー イメージ、複雑なアプリケーションの初期化、または ML/AI ワークロードを含むシナリオで最も顕著です。
このガイドは、Azure Container Apps のコールド スタート時間を軽減するのに役立ちます。
コンテナー イメージのサイズを最適化する
機械学習と AI 負荷の高いワークロードは、多くの場合、大規模なコンテナー イメージに関連付けられています。 可能な限り、これらのイメージのサイズをできるだけ小さくし、不要なライブラリを使用しないようにします。
多くの場合、イメージはトレーニングから推論に利用されるようになり、その過程で最低限の調整だけが必要です。 推論用にコンテナーを準備するときに、必ずコンテナーを監査して、モデル開発にのみ必要な開発ツールと依存関係を削除してください。
距離のあるイメージレジストリを避ける
Container Apps 環境の近くにコンテナー レジストリを使用します。 通常、これは、環境と同じリージョンにデプロイされた Azure Container Registry、またはグローバル分散を備えた Premium レジストリを使用することを意味します。
大規模なダウンロードを管理する
ストレージ マウントを使用して、特にファイル サイズが大きい場合 に、重要なデータをコンテナー アプリの近くに保持します。 たとえば、アプリで大規模な言語モデルが必要な場合は、モデルをストレージ アカウントに事前にダウンロードできます。 ストレージ アカウントから大きなファイルを読み取ることで、インターネット経由でファイルをプルする待機時間を回避できます。
AI ワークロード用のストレージ マウントを作成する場合は、ニーズに最適な マウント オプション を使用してください。
カスタム liveness 正常性プローブを実装するか、早期にリッスンを開始する
Azure Container Apps では、イングレスが有効になると 、ライブネス プローブ が自動的に設定されます。 イメージの起動後にイメージとアプリケーションの起動に時間がかかると、コンテナーに問題が発生する可能性があります。 Container Apps では、起動中のアプリケーションがライブネス プローブに失敗するため、強制終了する可能性があります。
Container Apps がイメージを本来より早く終了してしまうのを防ぐため、より長いスタートアップを可能にするカスタム liveness プローブを実装します。 または、スタートアップ サイクルの早い段階で専用のターゲット ポートで単純な接続をリッスンして、ポートを開いた後にアプリケーションを初期化することもできます。
クライアント側の宿泊施設
コールド スタート時間は、アプリケーションによって異なります。 この時間の影響を可能な限り少なくするには、遅延に対応するようにクライアントを微調整します。
特定の要求に時間がかかる可能性があることをユーザーに通知し、再試行を実装することが不可欠です。 また、アプリケーションで適切に処理できる時間を超える予期しないタイムアウトを回避するために、コードを強化することもできます。
アプリケーション側のインストルメンテーション
パフォーマンスの問題のトラブルシューティングを行うには、アプリケーション ライフサイクルのすべてのステージに対してアプリケーション側のパフォーマンス メトリックとログを実装します。
アプリを事前に起動する
上記の推奨事項で目的のパフォーマンスが得られない場合は、実際の使用に先立ってアプリを起動します。 たとえば、従業員が稼働日を開始する前にアプリケーションをウェイクアップするために、午前 9 時にジョブを設定することを検討してください。 この方法では、アプリが使用されていない場合でも、長いコールド スタートを排除しながら、コストをゼロにスケーリングできます。