このトピックでは、Microservices Engine (MSE) のマイクロサービスガバナンスによって提供されるグレースフルスタートとシャットダウンソリューションについてよくある質問への回答を提供します。
高度な機能はどこに行ったのですか？統合アプリケーションへの影響は何ですか？また、どのように有効または無効にできますか？
MSE コンソールでアプリケーションに対して新しいバージョンのマイクロサービスガバナンスを有効にしている場合は、この問題に注意する必要はありません。
グレースフルスタートとシャットダウンソリューションの高度な設定は、MSE コンソールのマイクロサービスガバナンスの旧バージョンで提供されています。ただし、高度な設定には多数のマイクロサービスの概念が含まれており、使いやすさのためにマイクロサービスガバナンスの新バージョンでは非表示になっています。マイクロサービスガバナンスの旧バージョンでは、高度な設定には次の機能が含まれます。
readiness プローブ前のサービス登録の完了
この機能は引き続き利用可能であり、新バージョンではデフォルトで有効になっています。以前にアプリケーションでこの機能が有効になっていなかった場合は、[グレースフルスタートとシャットダウン] ページでグレースフルスタート機能を再度有効にすると、自動的に有効になります。アプリケーションでこの機能が既に有効になっている場合は、無効にしないことをお勧めします。この機能がデフォルトで有効になっている場合、アプリケーションに悪影響を与えることはなく、リリース中の特定のシナリオでトラフィックがゼロに低下するリスクを防ぐことができます。詳細については、「55199/readiness を構成する理由」をご参照ください。
readiness プローブ前のサービスプリフェッチの完了
この機能は、新バージョンでは提供されなくなりました。これはもともと、プリフェッチ効果が期待どおりに確実に満たされるように設計されており、プリフェッチされたサービスのクエリ/秒 (QPS) カーブの急激な増加を防ぎます。この機能の実装原理は、Kubernetes readiness プローブによって実行されるチェックに合格するまでの時間を遅らせることです。これにより、バージョンリリース全体の時間が長くなります。また、これにより、システムは新しいノードがプリフェッチするための十分な時間を提供し、サービスプリフェッチ中に古いノードが特定量のトラフィックを処理できるようにします。これにより、カーブ内のプリフェッチされたサービスの QPS 値が時間の経過とともに徐々に増加します。バージョンリリースプロセスでは、新しいノードのプリフェッチ中にすべての古いノードが無効になっている場合、新しいノードはすべてのオンライントラフィックを処理する必要があります。その結果、低トラフィックサービスプリフェッチを実行できません。この機能が有効になっているアプリケーションは影響を受けません。ただし、ルールを構成するときに、新しいアプリケーションでこの機能を有効にすることはできなくなりました。以前にこの機能を有効にしたことがある場合は、無効にしないことをお勧めします。この機能は、有効になっている場合、アプリケーションに悪影響を与えることはありません。新バージョンで低トラフィックプリフェッチの目的の効果を実現する方法については、「低トラフィックプリフェッチのベストプラクティス」をご参照ください。
低トラフィックサービスプリフェッチ機能はどのように機能しますか。
コンシューマーがサービスを呼び出すと、コンシューマーはそのサービスのプロバイダーを選択します。プロバイダーに対して低トラフィックサービスプリフェッチが有効になっている場合、マイクロサービスガバナンスはプロバイダー選択プロセスを最適化します。コンシューマーがプロバイダーを選択すると、各プロバイダーの重みがパーセント値 (0% ～ 100%) として計算されます。コンシューマーは、重みの高いプロバイダーを優先的に選択して呼び出します。プロバイダーに対して低トラフィックサービスプリフェッチが有効になっている場合、プロバイダーの起動時に、コンシューマーによって計算されたプロバイダーの重みは低くなり、コンシューマーは低い確率でプリフェッチされたノードを呼び出します。計算された重みは時間とともに徐々に増加し、最終的に 100% に達します。計算された重みが 100% に達すると、プリフェッチは完了し、プリフェッチされたノードは通常のノードとしてトラフィックを受信できます。プロバイダーは、サービス登録情報のメタデータに起動時間を含めます。コンシューマーは、起動時間に基づいてプロバイダーの重みを計算します。このプロセスでは、コンシューマーとプロバイダーの両方でマイクロサービスガバナンスが有効になっている必要があります。
低トラフィックサービスプリフェッチは、アプリケーションが最初のリクエストを受信した後に開始し、構成されたプリフェッチ期間が経過した後に終了します。デフォルトのプリフェッチ期間は 120 秒です。アプリケーションが外部リクエストを受信しない場合、プリフェッチはトリガーされません。
低トラフィックプリフェッチをトリガーするには、サービス登録が完了していることを確認する必要があります。アプリケーションが低トラフィックプリフェッチを開始したが、まだサービス登録を完了していないことがわかった場合 (つまり、コンソールでプリフェッチ開始イベントがサービス登録イベントの前に表示されることがわかった場合) は、「アプリケーションのプリフェッチイベントがサービス登録イベントの前に報告されるのはなぜですか？」を参照して、この問題を解決してください。
折れ線グラフの曲線内のプリフェッチデータの傾向が期待どおりではないのはなぜですか。この問題を解決するにはどうすればよいですか。
この質問を読む前に、「低トラフィックサービスプリフェッチの原則」について学習することをお勧めします。
次の折れ線グラフは、通常のケースでの低トラフィックサービスプリフェッチの QPS 曲線の例を示しています。
ただし、場合によっては、低トラフィックサービスプリフェッチが実行されるアプリケーションの曲線の QPS 値が時間とともに徐々に増加しません。次のコンテンツでは、発生する可能性のある 2 つの一般的な状況について説明します。
QPS 値が特定の時点で急増する
ほとんどの場合、この状況はサービスリリース中に発生します。新しいノードが完全にプリフェッチされる前に古いノードがオフラインになると、コンシューマーがプロバイダーを選択するときに新しいノードが頻繁に呼び出されます。その結果、QPS 折れ線グラフは、新しいノードの QPS がゆっくりと増加し、すべての古いノードがオフラインになった後の特定の時点で急上昇することを示しています。この問題を解決するには、「低トラフィックプリフェッチのベストプラクティス」をご参照ください。
QPS 値が徐々に増加しない
この状況が発生した場合は、コンシューマーに対してマイクロサービスガバナンスが有効になっているかどうかを確認することをお勧めします。コンシューマーに対してマイクロサービスガバナンスが有効になっていない場合は、コンシューマーに対してマイクロサービスガバナンスを有効にすることで、この問題を解決できます。プリフェッチする必要があるアプリケーションのトラフィックが、Java ゲートウェイなどの外部サービスから発信されている場合、コンシューマーに対してマイクロサービスガバナンスは有効になっておらず、このシナリオでは低トラフィックサービスプリフェッチはサポートされていません。
低トラフィックサービスプリフェッチのベストプラクティスは何ですか。
不完全なプリフェッチは、ローリングデプロイメント中に頻繁に発生します。サービスプリフェッチが期待どおりに確実に満たされるように、次のプラクティスを参照できます。
最小準備時間の設定 (推奨): ワークロードに
.spec.minReadySecondsを構成して、ポッドが準備完了になってから使用可能になるまでの時間間隔を制御できます。このパラメーターの値をポッドの低トラフィックプリフェッチ期間よりも大きく設定して、K8s がローリングデプロイメントを続行する前にポッドがプリフェッチを完了するのを待つようにします。ACK を使用している場合は、[コンテナー プラットフォーム] でアプリケーションを見つけて、[詳細] > [アップグレード ポリシー] > [ローリングアップグレード] > [最小準備時間 (minReadySeconds)] でこの設定を直接構成できます。(この設定により、新しく起動されたポッドが準備完了になり、指定された期間その状態を維持した後にのみ、デプロイメントが続行されます。)(推奨) バッチデプロイメント方式を使用する: OpenKruise などのメソッドまたはツールを使用して、ワークロードをバッチでデプロイできます。バッチ間のデプロイメント間隔は、低トラフィックサービスプリフェッチ期間よりも長くする必要があります。バッチ内の新しいノードが完全にプリフェッチされたら、次のバッチのノードのリリースを続行できます。
initialDelaySeconds の値を大きくすることで、問題を解決することもできます。しかし、このメソッドを使用しないことを推奨します。initialDelaySeconds パラメーターは、ワークロードの最初の readiness プローブの前に待機する時間を指定します。パラメーター値が、低トラフィックサービスのプリフェッチ期間、遅延登録期間、およびアプリケーションの起動時間の合計よりも大きいことを確認する必要があります。なお、アプリケーションの起動時間は、実際のログ出力から取得できます。アプリケーションの起動時間は、ビジネスの発展に伴って変化します。readiness プローブをパスする時間を遅らせると、新しく開始されたノードのエンドポイントが Kubernetes サービスのエンドポイントに追加されない可能性があります。したがって、最適なプリフェッチ効果を確保したい場合は、このメソッドを使用しないことを推奨します。
ベストプラクティスに従って操作を実行しても、プリフェッチ QPS 曲線が期待どおりにならない場合は、アプリケーションが受信したトラフィックがすべて、Microservices Governance が有効になっているコンシューマーからのトラフィックであるかどうかを確認できます。 特定のコンシューマーに対して Microservices Governance が有効になっていない場合、または外部ロードバランサーによって呼び出されたトラフィックが存在する場合、アプリケーションのプリフェッチ中の QPS 曲線も期待どおりになりません。
55199/readiness とは何ですか？ 55199/readiness を構成しないと、トラフィックがゼロになる可能性があります。なぜですか？
55199/readiness は、MSE マイクロサービスガバナンスによって提供される組み込みの HTTP タイプ readiness プローブポートです。アプリケーションの Kubernetes readiness プローブが 55199/readiness に構成されている場合、起動中に新しいノードがサービス登録を完了していない場合は readiness プローブは 500 状態コードを返し、ノードがサービス登録を完了している場合は 200 状態コードを返します。
デフォルトの Kubernetes デプロイメントポリシーに基づいて、新しいノードの準備ができるまで、古いノードはオフラインになりません。readiness プローブが 55199/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"このパラメーターは、Java 仮想マシン (JVM) 起動パラメーターとしても構成できます。
このパラメーターの値は、正規表現マッチングをサポートしていません。
事前通知とは何ですか。事前通知を有効にする必要があるのはいつですか。
プロアクティブ通知は、グレースフルシャットダウンモジュールによって提供される高度な機能です。この機能により、オフライン状態の Spring Cloud プロバイダーは、ネットワークリクエストをプロアクティブに開始して、コンシューマーにオフライン状態を通知できます。コンシューマーが通知を受信した後、コンシューマーはプロバイダーノードを呼び出しません。通常の場合、プロバイダーとコンシューマーの両方が Spring Cloud フレームワークを使用する場合、コンシューマーはオンプレミス マシン上のプロバイダーノードリストをキャッシュします。特定のシナリオでは、コンシューマーがレジストリから通知を受信した場合でも、ローカルキャッシュがすぐにリフレッシュされない場合があります。その結果、コンシューマーはオフラインノードへの呼び出しを開始し続けます。プロアクティブ通知機能は、この問題を解決するために導入されました。
デフォルトでは、プロアクティブ通知機能は無効になっています。デフォルトのグレースフルシャットダウンソリューションに基づいて、Microservices Governance が有効になっている場合、オフラインになるプロバイダーがリクエストを受信すると、プロバイダーは特別な header を応答に追加し、コンシューマーに応答を返します。コンシューマーが応答を受信した後、コンシューマーは header を識別し、プロバイダーノードを呼び出しません。したがって、コンシューマーがオフラインになるプロバイダーにリクエストを送信すると、コンシューマーはプロバイダーがオフラインになりつつあることを検出し、プロバイダーノードリストからプロバイダーノードを自動的に削除できます。ただし、コンシューマーがプロバイダーがオフラインになる前のサービス停止保護期間 (約 30 秒) 以内にプロバイダーにリクエストを送信しない場合、コンシューマーはプロバイダーノードがオフライン状態であることを検出できず、プロバイダーがオフラインになりつつあるときにリクエストを送信する可能性があります。その結果、リクエストエラーが報告されます。この場合、プロアクティブ通知機能を有効にすることができます。コンシューマーがプロバイダーにリクエストを長い間隔で送信する場合は、プロバイダーに対してプロアクティブ通知機能を有効にすることをお勧めします。
グレースフルシャットダウンイベントが報告された後、トラフィックがすぐにゼロに低下しません。なぜですか。
ほとんどの場合、グレースフルシャットダウンイベントが報告されると、トラフィックはすぐにゼロに低下します。次のコンテンツでは、この問題の考えられる原因と解決策について説明します。
アプリケーションは、外部ロードバランサーなどのマイクロサービス以外のオブジェクトからリクエストを受信します。考えられるもう 1 つの原因は、アプリケーションがローカルスクリプトやスケジュールされたタスクなどの呼び出しメソッドを使用して開始されたリクエストを受信することです。
グレースフルスタートおよびシャットダウンソリューションは、マイクロサービスガバナンスが有効になっているマイクロサービスアプリケーションからのリクエストのみをサポートします。上記のシナリオでは、ソリューションはサポートされていません。インフラストラクチャとフレームワークによって提供されるグレースフルシャットダウン機能に基づいて、カスタムソリューションを構成することをお勧めします。
アプリケーションに対して事前通知機能が有効になっていません。（詳細については、「事前通知とは何ですか？」をご参照ください。）
事前通知機能を有効にした後、折れ線グラフの曲線が期待どおりに満たされるかどうかを確認することをお勧めします。
アプリケーションで使用されているフレームワークのバージョンは、グレースフルスタートおよびシャットダウンソリューションではサポートされていません。マイクロサービス ガバナンスのグレースフルスタートおよびシャットダウンソリューションでサポートされているフレームワークの詳細については、「マイクロサービス ガバナンスでサポートされている Java フレームワーク」をご参照ください。
アプリケーションのフレームワークバージョンがサポートされていない場合は、アプリケーションのフレームワークバージョンをアップグレードできます。
アプリケーションに対してグレースフルスタートおよびシャットダウンソリューションを有効にした後、バージョンリリース時間が長くなります。どうすればよいですか。
次の手順を実行して、readiness プローブ前のサービスプリフェッチが有効になっているかどうかを確認します。
MSE 管理センターコンソール にログインし、トップメニューバーでリージョンを選択します。
左側のナビゲーションウィンドウで、[管理センター] > [アプリケーション管理] を選択します。
[アプリケーションリスト] ページで、ターゲットアプリケーションをクリックし、[トラフィックガバナンス] > [グレースフルオンライン/オフライン] タブを選択します。
グレースフルオンライン/オフラインタブで、F12 キーを押して開発者ツールを開きます。[ネットワーク] タブで、
GetLosslessRuleByAppリクエストを検索します。(リクエストが見つからない場合は、ページをリフレッシュしてください。)[レスポンス] で、[データ] 内の [関連] フィールドの値が true かどうかを確認します。値が true の場合、readiness プローブに合格する前にサービスプリフェッチを完了する機能がアプリケーションでずっと前に有効になっていたことを示します。(この機能は現在利用できません。) この機能が有効になっていると、リリース時間が長くなる可能性があります。チケットを送信 して、この機能を無効にすることをお勧めします。
MSE マイクロサービスガバナンスによって提供される 55199/readiness とは何ですか。MSE readiness プローブの障害が一部のシナリオで持続するのはなぜですか。
Kubernetes は、以下のタイプのプローブを提供します。
スタートアッププローブ: ポッドの起動プロセス中にアプリケーションが正常に起動するかどうかを検出します。 ポッドの起動プロセス中にプローブが複数回失敗し、構成された失敗のしきい値に達した場合、ポッドは再起動されます。
Liveness プローブ: アプリケーションが稼働しているかどうかを検出します。 システムは、スタートアッププローブが成功した後に liveness プローブを開始します。 Liveness プローブは、ポッドのライフサイクル全体にわたって実行されます。 プローブが複数回失敗し、構成された失敗のしきい値に達した場合、ポッドは再起動されます。
Readiness プローブ: アプリケーションの準備ができているかどうかを検出します。 システムは、スタートアッププローブが成功した後に readiness プローブを開始します。 Readiness プローブは、ポッドのライフサイクル全体にわたって実行されます。 プローブが複数回失敗し、構成された失敗のしきい値に達した場合、Kubernetes はポッドを未準備としてマークしますが、ポッドを再起動しません。 アプリケーションがリリースされると、readiness プローブを使用してリリースプロセスを制御できます。 デフォルトのリリースポリシーに基づいて、新しいポッドの準備ができていない場合、Kubernetes は新しいポッドの準備ができるまでリリースプロセスを停止します。
サービスが MSE サービスガバナンスと統合されると、MSE サービスガバナンスの組み込み 55199/readiness エンドポイントを使用して、サービス readiness チェックを構成できます。 構成が完了すると、アプリケーションがサービス登録を完了した後にのみ、K8s readiness プローブは合格します。 これにより、デプロイメントプロセス中に、新しく起動されたポッドがサービスレジストリへの登録を完了してから、古いポッドが K8s によってオフラインになり、サービスレジストリから登録解除されることが保証されます。 このプロセスにより、サービス呼び出し側は常に呼び出しを行うための使用可能なノードを持つことができ、使用できないサービスによって発生するエラーを防ぎます。 MSE readiness プローブを構成する必要がある理由の詳細については、「サービス登録ステータスチェック」をご参照ください。
MSE readiness プローブの障害が持続する場合、この問題は次の理由が原因である可能性があります。
アプリケーションでグレースフルスタートが有効になっておらず、55199/readiness が有効になっていません。 その結果、readiness プローブは失敗します。
現在のアプリケーションはサービスガバナンスに接続されていません。 サービスガバナンスプローブディレクトリにプローブログが存在するかどうかを確認できます。 K8s 環境では、プローブディレクトリはデフォルトで
/home/admin/.opt/AliyunJavaAgentまたは/home/admin/.opt/ArmsAgentです。 ディレクトリに logs ディレクトリが含まれていない場合は、アプリケーションがサービスガバナンスに接続できなかったことを示します。 チケットを送信 して、お問い合わせください。スタートアップまたは liveness プローブの障害が指定されたしきい値に達したため、アプリケーションが繰り返し再起動されます。 この場合、MSE readiness プローブは常に失敗します。 バックグラウンドでポッドの Kubernetes イベントをクエリし、スタートアップまたは liveness プローブの障害に関連するイベントが存在するかどうかを確認できます。