注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

レプリカのステータスを使用してデバッグする

Compute Module をデバッグする際は、まず概要タブのレプリカのステータスセクションを確認します。レプリカのステータスセクションには、各レプリカとその現在のステータスが表示され、デプロイの状態を大まかに把握できます。個々のレプリカを選択すると、そのレプリカに含まれるイメージを表示でき、レプリカ診断のコールアウトを選択すると、より詳細な診断情報を表示できます。デバッグできず、Compute Module のインフラストラクチャに問題があると思われる場合は、Issue を作成して Palantir サポートにお問い合わせください。

レプリカのステータス

レプリカのステータスセクションには、現在アクティブでデプロイの一部となっているレプリカと、アーカイブ済みのレプリカが表示されます。アーカイブ済みのレプリカはもう実行されていませんが、過去に発生した問題のデバッグには引き続き使用できます。各レプリカには独自のライフサイクルがあり、以下に記載するいずれかの状態になります。

デプロイで表示される可能性があるレプリカのさまざまなステータス。

  • 開始中: レプリカの初期段階です。ホストの確保、イメージのプル、コンテナの起動などが行われている可能性があります。レプリカがこの状態に長時間とどまっている場合は、イメージが大きい(>5 GB)、リソース要求が大きい、または設定した Readiness Probe が準備完了を報告するまでに時間がかかっている可能性があります。ログが表示されている場合は、少なくともコンテナは起動できており、コードを調査できます。生成されるはずのログが生成されていない場合は、インフラストラクチャに問題がある可能性があります。
  • 開始されました: この段階では、レプリカは起動済みです。つまり、ホストを確保し、イメージをプルし、コンテナを起動しています。この段階で、レプリカは応答ありまたは応答なしの状態になることがあります。これは通常の動作とみなされます。ただし、この段階に長時間とどまるのは通常の動作ではなく、その場合はインフラストラクチャに問題がある可能性があります。
  • 応答あり: この段階では、レプリカが応答可能であり、クエリに応答できると判断されています。これは通常の動作とみなされます。この段階のレプリカで問題が発生した場合は、まずログを確認してデバッグしてください。
  • 応答なし: レプリカがリクエストに応答できない場合、または準備完了の報告に失敗した場合は、応答なしと指定されます。この状態では、そのレプリカにリクエストはルーティングされず、応答なしの状態が十分に長く続くと、レプリカが終了される可能性があります。レプリカは一時的に応答なしになることがあり、このステータスへの切り替わりと復帰を繰り返すこともあります。応答なしのレプリカで問題が発生している場合は、ログを確認するか、レプリカの削除後に診断パネルを確認してください。
  • 廃止: レプリカの削除時には、まず廃止され、その後に最終的に削除されるという2段階の削除プロセスを経る場合があります。これは、進行中のリクエストの処理をレプリカが完了できるように時間を確保するためです。個々のレプリカの最大 TTL は24時間より短いため、これは通常の動作である場合があります。
  • 開始エラー: レプリカは、さまざまな理由で起動に失敗することがあります。インフラストラクチャの問題、イメージの不具合、または設定の問題を示している可能性があります。この段階ではログが存在しないため、レプリカを選択して診断情報を確認してください。
  • 削除済み: すべてのレプリカは最終的に削除されます。これは、レプリカのライフサイクルの一部として通常どおりに行われることも、例外的に行われることもあります。デプロイに問題が見られる場合は、レプリカのステータスセクションをアーカイブ済みに切り替えて、削除済みの特定のレプリカの診断情報を表示できます。削除済みレプリカの診断情報は、1時間のみアーカイブされます。

レプリカ診断

レプリカ診断では、性能が低下したデプロイについて、より深いインサイトを得られます。基盤となるインフラストラクチャ、Compute Module サービス、またはその両方から、ステータスとその理由が直接提供されます。レプリカ診断パネルでは、個々のイメージを選択して、さらにデバッグすることもできます。

特定のレプリカの診断情報を表示するには、まずレプリカを表す四角を選択する必要があります。レプリカによってはアーカイブされている場合があり、アーカイブ表示に切り替える必要があります。

以下は、ライブ状態への移行に失敗しているデプロイの診断パネルの例です。

「応答なし」エラーを示すレプリカ診断。

レプリカ診断パネルに表示された CrashLoopBackOff エラー。

上の画像では、コンテナで CrashLoopBackOff が発生しています。ログと指定したコードを確認して、さらにデバッグを進められます。

アップグレードをデバッグする

Compute Module は、可能な場合は安全なアップグレードを試みます。つまり、アクティブなデプロイがある状態で設定をアップグレードすると、アクティブなデプロイと並行して新しいデプロイが起動し、新しいデプロイが応答ありになると切り替わります。新しいジョブは更新されたデプロイにルーティングされ、既存のジョブは古いデプロイで完了します。

アップグレードプロセス

Compute Module のアップグレードは、以下の一連のステップで進行します。

  1. 実行中の Compute Module の設定が変更されます。たとえば、設定済みのイメージのバージョンを変更した場合です。一部の設定は適用にダウンタイムが必要になる場合があり、保存前にそのことを了承するよう求められます。
  2. Compute Module サービスが、変更を反映した2つ目のデプロイを作成します。
  3. Compute Module サービスは、新しいデプロイに応答ありのレプリカができるまで待機します。
  4. 新しいデプロイに応答ありのレプリカができ、新しいリクエストが新しいデプロイにルーティングされます。古いデプロイは廃止処理中となり、完全に削除される前に、既存のリクエストを完了するための猶予期間が与えられます。

新しいデプロイが応答ありにならない場合、現在のデプロイは変更されません。アップグレードが成功しなかった場合も、ダウンタイムは発生しません。応答なしのアップグレードを終了するには、設定の変更を元に戻すか、レプリカが応答ありになるように追加の変更を行います。

アップグレードが応答なしになっている

アクティブなレプリカのステータスセクションと同様に、アップグレードされたデプロイのレプリカのステータスは、概要タブ内のセクションに表示されます。

セクションを展開すると、アップグレードされたデプロイのイメージが表示されます。レプリカを表す四角を選択すると、レプリカのより詳細な診断情報が表示されます。

アップグレードされたデプロイのレプリカのステータスを示す、アップグレードデプロイのステータスセクション。