Microservices Engine:グレースフル起動とシャットダウンに関するよくある質問

高度な機能

以前のバージョンのグレースフル起動とシャットダウンのコンソールでは、高度な機能が提供されていました。これらの機能には複雑なマイクロサービスの概念が含まれるため、新しいインターフェイスでは簡潔さのために非表示になっています。以前のバージョンの高度な機能には、次の 2 つのサブ機能が含まれていました。

• readiness 前のサービス登録

  この機能は引き続き利用可能で、デフォルトで有効になっています。以前にアプリケーションで無効にしていた場合、コンソールの [グレースフルオンライン/オフライン] ページでグレースフル起動を有効にすると、自動的に有効になります。すでにこの機能を有効にしている場合は、無効にすることは推奨しません。デフォルトで有効になっている場合、この機能には悪影響はなく、リリース中にトラフィックがゼロになるのを防ぐのに役立ちます。詳細については、「55199/readiness の役割と、それがない場合にトラフィックがゼロになるリスク」をご参照ください。

• readiness 前のサービスプリフェッチ

  この機能は、新しい構成では利用できなくなりました。元の目的は、サービスプリフェッチが期待どおりの結果を確実に達成することと、QPS 曲線の急激な上昇を防ぐことでした。これは、Kubernetes の readiness プローブを遅延させて全体的なリリース時間を延長することで機能しました。これにより、新しいノードはサービスプリフェッチのための十分な時間を確保でき、古いノードはトラフィックの処理を継続できるため、QPS が段階的に増加します。新しいノードがまだプリフェッチ中に古いノードがオフラインになると、新しいノードはすべての受信トラフィックを処理する必要があり、低トラフィックサービスプリフェッチの目的が損なわれます。以前にこの機能を有効にしていたアプリケーションは影響を受けませんが、新しいアプリケーションでは有効にできません。以前にこの機能を有効にしていた場合、悪影響はないため、無効にすることは推奨しません。新しいバージョンで低トラフィックサービスプリフェッチの最良の結果を得るには、「低トラフィックサービスプリフェッチのベストプラクティス」をご参照ください。

低トラフィックサービスプリフェッチの原則

コンシューマーがサービスを呼び出すとき、プロバイダーを選択します。プロバイダーアプリケーションで低トラフィックサービスプリフェッチが有効になっている場合、マイクロサービスガバナンスはこの選択プロセスを強化します。コンシューマーがプロバイダーを選択すると、各プロバイダーに対して 0% から 100% の重みを計算します。重みが大きいほど、そのプロバイダーが選択される確率が高くなります。低トラフィックサービスプリフェッチが有効になっているプロバイダーが起動すると、コンシューマーはそれに低い重みを割り当てます。これは、新しいノードが選択される確率が低いことを意味します。時間が経つにつれて、計算された重みは増加し、最終的に 100% に達します。この時点で、プリフェッチプロセスは完了し、ノードは通常のノードのようにトラフィックを受信し始めます。プロバイダーは、サービス登録メタデータに起動時間を含め、コンシューマーはこれを使用して重みを計算します。このプロセスでは、プロバイダーとコンシューマーの両方でマイクロサービスガバナンスが有効になっている必要があります。

予期しないプリフェッチ QPS 曲線

通常の状況では、低トラフィックサービスプリフェッチ中のアプリケーションの QPS 曲線は次のようになります。

ただし、サポートされていないユースケースや不適切な構成により、低トラフィックサービスプリフェッチ中のアプリケーションの QPS 曲線が段階的に増加しない場合があります。以下は、2 つの一般的な予期しないパターンです。

• QPS 曲線の急上昇

  

  これは通常、サービスデプロイ中に発生します。新しいノードがプリフェッチ期間を完了する前に古いノードがオフラインになると、コンシューマーは新しいノードに対して低確率のルーティングを適用できなくなります。その結果、新しいノードの QPS 曲線は最初は段階的に増加しますが、すべての古いノードがオフラインになった後、突然急上昇します。この問題を解決するには、「低トラフィックサービスプリフェッチのベストプラクティス」をご参照ください。

• QPS の段階的な増加の欠如

  

  この問題は、リクエスト元のコンシューマーアプリケーションがマイクロサービスガバナンスに接続されていないことを示唆しています。これを解決するには、コンシューマーを接続します。低トラフィックサービスプリフェッチは、Java ゲートウェイなどの外部ソースからのトラフィックにはサポートされていません。これらは接続されたコンシューマーではないためです。

低トラフィックサービスプリフェッチのベストプラクティス

ローリングデプロイでは、サービスプリフェッチが不完全になることがよくあります。以下のプラクティスに従うことで、サービスプリフェッチが期待どおりの結果を達成するようにできます。

• minReadySeconds の設定 (推奨)：ワークロードの .spec.minReadySeconds パラメーターを設定して、Pod が準備完了になってから利用可能と見なされるまでの時間間隔を制御できます。このパラメーターを Pod の低トラフィックサービスプリフェッチ持続時間よりも大きい値に設定します。これにより、Kubernetes はローリングデプロイを続行する前に、Pod がプリフェッチを完了するのを待つようになります。ACK を使用している場合は、コンテナプラットフォームでアプリケーションを見つけ、[その他] > [アップグレードポリシー] > [ローリングアップグレード] > [最小準備時間 (minReadySeconds)] に移動してこのパラメーターを設定できます。minReadySeconds を設定すると、Kubernetes がローリングデプロイを続行する前に、新しい Pod が指定された期間、準備完了状態を維持することが保証されます。

• バッチデプロイの使用 (推奨)：OpenKruise などのツールを使用して、ワークロードのバッチデプロイを実装することを検討してください。各バッチ間の時間間隔を、低トラフィックサービスプリフェッチ持続時間よりも長く設定します。これにより、次のバッチがデプロイされる前に、バッチ内の新しいノードが完全にプリフェッチされることが保証されます。

readiness プローブの初期遅延の増加 (非推奨)：もう 1 つの方法は、ワークロードの readiness プローブの初期プローブ遅延 (initialDelaySeconds) を、低トラフィックサービスプリフェッチ持続時間、登録遅延、およびアプリケーション起動時間の合計よりも大きい値に増やすことです。アプリケーションの起動時間はログ出力を観察して決定する必要があり、ビジネスの進化に伴って変化する可能性があることに注意してください。さらに、readiness プローブを遅延させると、新しく起動したノードが Kubernetes サービスエンドポイントに迅速に追加されるのを妨げる可能性があります。したがって、最適なプリフェッチ結果を得るためにこの方法は推奨しません。

55199/readiness エンドポイント

55199/readiness エンドポイントは、MSE マイクロサービスガバナンスが提供する組み込みの HTTP readiness プローブポートです。アプリケーションの Kubernetes readiness プローブが 55199/readiness を使用するように設定されている場合、readiness プローブは、新しいノードがサービス登録を完了していない場合は 500 を返し、完了している場合は 200 を返します。

デフォルトの Kubernetes デプロイ戦略によれば、新しいノードが準備完了になるまで、古いノードは終了されません。55199/readiness で readiness プローブを設定すると、新しいノードはサービス登録を完了した後にのみ準備完了になります。これにより、新しいノードが登録された後にのみ古いノードが終了されることが保証され、サービスレジストリには常にサービスで利用可能なノードが存在することが保証されます。55199/readiness を設定しない場合、サービスデプロイ中に新しいノードが登録される前に古いノードが終了される可能性があります。これにより、サービスレジストリに利用可能なノードがなくなり、すべてのコンシューマー呼び出しが失敗し、サービスのトラフィックがゼロになる可能性があります。したがって、アプリケーションに対してグレースフル起動を有効にし、55199/readiness readiness プローブを設定することを強く推奨します。

アプリケーションが 4.1.10 より前のプローブバージョンを使用している場合、readiness プローブのパスを /readiness の代わりに /health として設定する必要があります。 プローブバージョンを確認するには、MSE コンソールに移動し、管理センター > アプリケーションガバナンスの順に選択して、対象のアプリケーションをクリックしてから、ノード詳細をクリックします。 プローブバージョンは右側に表示されます。

サービス登録前のプリフェッチイベント

現在のバージョンでは、サービスが最初の外部リクエストを受信すると、プリフェッチプロセスが開始され、プリフェッチ開始イベントが報告されます。ただし、アプリケーションが受信する最初のリクエストはマイクロサービス呼び出しではない場合があり、そのためビジネスロジックでプリフェッチをトリガーしない場合があります。たとえば、アプリケーションのワークロードが Kubernetes liveness プローブで設定されている場合、Kubernetes が liveness チェックを実行するとすぐにプリフェッチプロセスが開始されます。これは、サービス登録がまだ行われていない場合でも同様です。

これを回避するには、プロバイダーアプリケーションのワークロードの環境変数に次のパラメーターを設定して、プリフェッチロジックがこれらのリクエストを無視するようにします。

# パス /xxx および /yyy/zz へのリクエストをプリフェッチプロセスのトリガーから除外します
profile_micro_service_record_warmup_ignored_path="/xxx,/yyy/zz"

プロアクティブ通知

プロアクティブ通知は、グレースフルシャットダウンモジュールの高度な機能です。これにより、Spring Cloud プロバイダーはシャットダウン時にコンシューマーにネットワークリクエストを送信し、オフラインになることを通知できます。通知を受け取った後、コンシューマーはそのノードを呼び出さなくなります。通常、プロバイダーとコンシューマーの両方が Spring Cloud フレームワークを使用している場合、コンシューマーはプロバイダーノードのリストをローカルにキャッシュします。一部のシナリオでは、サービスレジストリから通知を受け取った後でも、コンシューマーがローカルキャッシュを時間内にリフレッシュできず、オフラインノードへの呼び出しが発生する可能性があります。プロアクティブ通知は、この問題を効果的に解決します。

プロアクティブ通知はデフォルトで無効になっています。マイクロサービスガバナンスが有効になっている場合、デフォルトのグレースフルシャットダウンソリューションでは、シャットダウン中のプロバイダーがレスポンスに特別な header を追加します。コンシューマーがレスポンスを受信すると、この header を識別し、そのプロバイダーノードの呼び出しを停止します。したがって、コンシューマーからシャットダウン中のプロバイダーへのトラフィックがある限り、コンシューマーはプロバイダーがオフラインであることを認識し、自動的にブラックリストに登録します。ただし、シャットダウン期間中 (通常は約 30 秒) にコンシューマーがシャットダウン中のプロバイダーにリクエストを送信しない場合、プロバイダーがオフラインであることを認識できない可能性があります。プロバイダーがシャットダウンする直前にリクエストが到着し、エラーが発生する可能性があります。このシナリオでは、プロアクティブ通知を有効にする必要があります。つまり、コンシューマーのトラフィックが非常に少ない場合は、プロバイダーでプロアクティブ通知を有効にすることを推奨します。

シャットダウン後のトラフィック低下の遅延

通常、グレースフルシャットダウンイベントの直後にトラフィックはゼロに低下します。そうでない場合は、次の理由と解決策が考えられます。

• マイクロサービス以外の呼び出し

  現在、グレースフル起動とシャットダウンは、内部マイクロサービス呼び出しからのトラフィックのみを管理します。これらのシナリオは、この機能の範囲外です。インフラストラクチャとフレームワークが提供するグレースフルシャットダウン機能に基づいて、カスタムソリューションを作成することを推奨します。

• プロアクティブ通知が有効になっていない

  プロアクティブ通知を有効にしてから、シャットダウン曲線が期待どおりになるかどうかを確認することを推奨します。

• サポートされていないフレームワークバージョン

  アプリケーションがサポートされていないフレームワークバージョンを使用していることがわかった場合は、アップグレードを検討してください。

長いリリース時間

次の手順に従って、アプリケーションで「readiness プローブをパスする前にサービスプリフェッチを完了する」機能が有効になっているかどうかを確認します。

1. MSE コンソールにログインし、トップメニューバーでリージョンを選択します。

2. 左側のナビゲーションウィンドウで、Microservices Governance > Application Governance を選択します。

3. Applications ページで、対象のアプリケーションをクリックし、[トラフィックガバナンス] > Graceful Start and Shutdown タブに移動します。

4. [グレースフルオンライン/オフライン] タブで、F12 キーを押してブラウザの開発者ツールを開きます。[ネットワーク] タブで、GetLosslessRuleByApp リクエストを検索します。表示されない場合は、ページを更新してください。レスポンスボディで、Data の下の Related フィールドの値が true であるかどうかを確認します。true の場合、アプリケーションは以前に「readiness プローブをパスする前にサービスプリフェッチを完了する」機能が有効になっていました。この機能は現在非推奨であり、リリース時間が長くなる可能性があります。この機能を無効にするには、チケットを送信することを推奨します。

55199/readiness エンドポイントとプローブの失敗

Kubernetes は、startup プローブ、liveness プローブ、readiness プローブの 3 つのオプションのプローブを提供します。

• startup プローブ：アプリケーションが正常に起動したかどうかを確認します。Pod の起動フェーズでのみ実行されます。起動中にプローブが複数回失敗し、設定された失敗しきい値に達した場合、Pod の再起動をトリガーします。

• liveness プローブ：アプリケーションが現在生存しているかどうかを確認します。startup プローブが成功した後にプロービングを開始し、Pod のライフサイクル全体で継続します。プローブが複数回失敗し、設定された失敗しきい値に達した場合、Pod の再起動をトリガーします。

• readiness プローブ：アプリケーションがトラフィックを受け入れる準備ができているかどうかを確認します。startup プローブが成功した後にプロービングを開始し、Pod のライフサイクル全体で継続します。プローブが複数回失敗し、設定された失敗しきい値に達した場合、Kubernetes は Pod のステータスを準備ができていない状態に設定しますが、Pod は再起動しません。デプロイメント中、readiness プローブはデプロイメントのペースを制御することもできます。デフォルトのデプロイメント戦略によれば、新しい Pod が準備完了にならない場合、Kubernetes は準備完了になるまでデプロイメントプロセスを一時停止します。

サービスを MSE マイクロサービスガバナンスに接続した後、その組み込みの 55199/readiness エンドポイントをサービスの readiness プローブ構成に使用できます。この構成では、Kubernetes の readiness プローブは、アプリケーションがサービス登録を完了した後にのみパスします。これにより、デプロイメント中に、古い Pod が Kubernetes によって終了および登録解除される前に、新しい Pod がマイクロサービスレジストリに登録されることが保証されます。これにより、呼び出し元は常に利用可能なノードを持つことができ、「利用可能なサービスがない」という例外を回避できます。MSE readiness プローブを設定する必要がある理由の詳細については、「サービス登録ステータスチェック」をご参照ください。

MSE readiness プローブが一貫して失敗する場合、考えられる理由は 3 つあります。

1. 現在のサービスでグレースフル起動が有効になっていません。グレースフル起動が無効になっている場合、MSE 55199/readiness API は公開されず、readiness プローブはパスしません。

2. 現在のアプリケーションはマイクロサービスガバナンスに接続されていません。マイクロサービスガバナンスのプローブディレクトリにプローブのログが存在するかどうかを確認できます。Kubernetes 環境では、デフォルトのプローブディレクトリは /home/admin/.opt/AliyunJavaAgent または /home/admin/.opt/ArmsAgent です。このディレクトリにログディレクトリが存在しない場合、アプリケーションがマイクロサービスガバナンスへの接続に失敗したことを意味します。お手数ですがしてご連絡ください。

3. startup または liveness プローブが失敗しきい値に達したため、現在のアプリケーションは継続的に再起動しています。アプリケーションの起動に失敗するため、MSE readiness プローブはパスしません。Pod の Kubernetes イベントで、startup または liveness プローブの失敗に関連するイベントがないか確認してください。