「システムアーキテクチャ」マイクロサービスサービス劣化

[[238592]]

1. はじめに

サービス低下とは何ですか?サーバーの負荷が急激に高まると、実際の業務状況やトラフィックに応じて、一部のサービスやページは戦略的に処理されないか、より単純な方法で処理され、サーバーのリソースが解放されて、コアトランザクションの正常または効率的な動作が確保されます。

まだ理解できない場合は、例を挙げてみましょう。私に支払いをしたい人はたくさんいるが、私のサーバーでは支払いサービス以外にも、検索、スケジュールされたタスク、詳細などの他のサービスも実行されているとします。しかし、これらの重要でないサービスは、JVM メモリと CPU リソースを大量に消費します。すべてのお金 (お金が目的) を収集するために、これらの重要でないサービスを最外層で直接拒否する動的スイッチを設計しました。このようにして、お金の収集を処理するバックエンド サービスは、お金を集めるためのリソースをより多く持つことになります (お金の収集速度が速くなります)。これは、単純なサービス低下の使用シナリオです。

2. 使用シナリオ

サービス低下は主にどのようなシナリオで使用されますか?マイクロサービス アーキテクチャ全体の負荷が事前に設定された上限しきい値を超えた場合、または今後のトラフィックが事前に設定されたしきい値を超えると予想される場合、重要なサービスまたは基本サービスの正常な動作を確保するために、一部の 重要 でないサービスまたはタスクまたはタスクの 使用を 遅らせたり、一時停止したりできます。

3. コア設計

3.1 分散スイッチ

上記の要件に基づいて、分散スイッチを設定してサービス低下を実現し、スイッチ構成情報を集中管理することができます。具体的な計画は以下のとおりです。

サービスの低下 - 分散スイッチ

3.2 自動ダウングレード

• タイムアウトダウングレード- 主にタイムアウト時間とタイムアウト再試行回数とメカニズムを設定し、非同期メカニズムを使用して回復状況を検出します。
• 障害によるダウングレード- 主に不安定な API の場合。失敗した呼び出しの数が一定のしきい値に達すると、API は自動的にダウングレードされます。応答ステータスを検出するには、非同期メカニズムも使用する必要があります。
• 障害によるダウングレード- 呼び出されるリモートサービスが失敗した場合（ネットワーク障害、DNS障害、HTTPサービスが誤ったステータスコードを返し、RPCサービスが例外をスローした場合）、直接ダウングレードできます。
• 電流制限ダウングレード- 電流制限超過がトリガーされると、一時的なシールドを使用してシステムを一時的にシールドすることができます。

フラッシュセールや限定購入商品の購入に殺到すると、トラフィックが多すぎてシステムがクラッシュする可能性があります。このとき、開発者は電流制限を使用してトラフィックを制限します。電流制限しきい値に達すると、後続のリクエストはダウングレードされます。ダウングレード後の処理ソリューションは、キューページ（ユーザーをキューページに誘導して待機してから再試行する）、在庫切れ（在庫切れをユーザーに直接通知する）、エラーページ（イベントが人気すぎる場合は、後で再試行する）のいずれかになります。

3.3 構成センター

マイクロサービスのダウングレードの構成情報は一元管理され、視覚的なインターフェースを通じてユーザーフレンドリーな操作が実行されます。構成センターとアプリケーションはネットワーク通信を必要とします。そのため、ネットワークの中断やネットワークの再起動などの要因により、構成プッシュ情報が失われたり、再起動やネットワークの回復後に受け入れられなくなったり、変更が遅れたりする可能性があります。そのため、サービスの低下を伴う構成センターでは、構成変更が可能な限りタイムリーになるように、次の機能を実装する必要があります。

サービスの低下 - 構成センター

• アクティブ プル構成の開始- 構成を初期化するために使用されます (最初の時間指定プル サイクルを短縮します)
• パブリッシュおよびサブスクライブ構成- タイムリーな構成変更を実装するために使用されます (構成変更の約 90% を解決できます)
• スケジュールされたプル構成- 公開およびサブスクリプションの失敗または消失の問題を解決するために使用されます (公開およびサブスクリプションの失敗メッセージの変更の約 9% を解決できます)
• オフラインファイルキャッシュ構成- 再起動後に構成センターに接続できない問題を一時的に解決するために使用されます
• 編集可能な構成ドキュメント- 構成定義を実装するためにドキュメントを直接編集するために使用されます
• 構成を変更するためのTelnetコマンドを提供します。構成センターの障害や構成の変更ができないという一般的な問題を解決するために使用されます。

3.4 処理戦略

サービスの低下が引き起こされ、新しいトランザクションが再び到着した場合、これらのリクエストをどのように処理すればよいでしょうか?マイクロサービス アーキテクチャ全体の観点から見ると、通常、次のような一般的な劣化解決策があります。

• ページのダウングレード- ビジュアルインターフェースのクリックボタンを無効にし、静的ページを調整します
• 遅延サービス- スケジュールされたタスクの処理の遅延や、MQ 入力後のメッセージの処理の遅延など
• 書き込みダウングレード- 書き込み操作に関連するサービス要求を直接禁止します
• ダウングレードの読み取り- 関連するサービス要求を直接禁止する
• キャッシュのダウングレード- キャッシュを使用して、頻繁に読み取られるサービス インターフェースをダウングレードします。

バックエンド コード レベルでのダウングレード処理戦略では、通常、ダウングレード処理に次の処理手段を使用します。

• 例外をスローする
• NULLを返します
• モックデータの呼び出し
• フォールバック処理ロジックの呼び出し

4. 高度な機能

各サービスごとにダウングレードスイッチを用意しており、オンラインで検証済みですので全く問題ないと思われます。

シナリオ 1 : ある日、運用チームがイベントを開催したところ、突然、トラフィックが上限に近づいていると言われました。重要でないサービスをすべて一括でダウングレードする方法はありますか?開発者は困惑しながらこれを見て、これは DB 操作ではないのに、どうしてバッチ操作が可能なのだろうかと考えました。

シナリオ 2 : ある日、運用チームがまたトラブルを起こしました。イベントを開催するので、事前に重要でないサービスをすべてダウングレードするようにと言われました。開発チームはまたもや混乱しました。どのサービスをダウングレードすればよいのか、どうすればわかるのでしょうか?

反省点：サービス低下機能は実装されていたが、実装時の経験が考慮されていなかった。サービスが多すぎて、どのサービスをダウングレードすればいいのか分からない。1回の操作でのダウングレード速度が遅すぎる…

4.1 ティアダウングレード

マイクロサービス アーキテクチャでさまざまなレベルの問題が発生した場合、比較に基づいてサービスを選択的に放棄できるため (つまり、ドライバーを救うために車を犠牲にする原則)、コア サービスの正常な動作がさらに保証されます。

オンライン サービスが停止しそうになるまで待ってから、ダウングレードすべきサービスとダウングレードしてはいけないサービスを 1 つ 1 つ選択すると、オンライン サービスが数百、数千ある場合、ダウングレードするには確実に手遅れになり、サービスがダウンすることになります。同時に、大規模なプロモーションやフラッシュセールの前に情報を整理するのは大変な作業になります。そのため、アーキテクトやコア開発者は、開発期間中に、情報をダウングレードできるかどうかの初期評価値、つまり情報をダウングレードできるかどうかのデフォルト値を事前に整理しておくことをお勧めします。

バッチ操作のマイクロサービス アーキテクチャでサービスのダウングレードを容易にするために、全体的な観点からサービスの重要度を評価するモデルを確立できます。条件が許せば、 階層分析プロセス (AHP)の数学的モデリング モデル (または他のモデル) を使用して、定性的および定量的な評価を実行することをお勧めします (ダウングレードするかどうかのアーキテクトによる直接的な決定よりも間違いなく何倍も優れていますが、もちろん、難易度と複雑さははるかに高くなります。つまり、数学的モデリングの才能が必要です)。階層分析プロセスの基本的な考え方は、複雑な意思決定の問題に対する人々の思考と判断のプロセスは一般的に同じであるということです。

以下は個人が提示した最終的な評価モデルであり、サービス劣化の評価の参考モデルとして使用できます。

数学的モデリングやアーキテクトの直接的な思考と、サービスが劣化してもよいかどうかの優先原則を組み合わせて、台風警報（すべて暴風警報に属する）のレベルに基づいてリファレンス設計を作成します。マイクロサービス アーキテクチャのすべてのサービスの障害暴風レベルは、次の 4 つのタイプに分類できます。

モデルを評価する:

• ブルーストーム- 非中核サービスを小規模にダウングレードする必要があることを示す
• イエローストーム- 非中核サービスの中程度のダウングレードを示します
• オレンジストーム- 非コアサービスを大規模にダウングレードする必要があることを示す
• レッドストーム- コアサービス以外のすべてのサービスをダウングレードする必要があることを示します

デザインの説明:

• 障害の重大度は、青 < 黄色 < オレンジ < 赤です。
• 80/20原則に従って、サービスは80%の非コアサービス+20%のコアサービスに分割できると提案されています。

上記のモデルは、マイクロサービス アーキテクチャ全体のサービス劣化評価モデルにすぎません。特定のプロモーションやフラッシュ セールの場合は、特定のテーマを中心に構築することをお勧めします (異なるテーマのアクティビティは異なるサービスに依存するため、異なる劣化方法を使用する方が合理的です)。もちろん、モデルは同じものを使用できますが、データは異なる必要があります。モデル ライブラリを構築し、それを実装するときに、関連するサービスを入力するだけで、最終的なダウングレード プランを出力できます。つまり、この大規模なプロモーションやフラッシュ セール中にブルー ストームが発生したときにダウングレードする必要があるサービスのリストと、イエロー ストームが発生したときにダウングレードする必要があるサービスのリストを出力できます...

4.2 劣化重量

マイクロサービス アーキテクチャにはサービス ウェイトの概念があり、これは主に負荷時のウェイト選択に使用されます。同様に、サービス デグラデーション ウェイトも同様で、 主にサービス デグラデーションを選択する際のきめ細かい優先順位の決定に使用されます。上記の単純な 4 レベルの分割方法を使用して、すべてのサービスが直接均一に処理されますが、これは明らかに粒度が粗すぎます。つまり、同じレベルの複数のサービスをダウングレードする必要がある場合、 ダウングレードの順序はどうすればよいのでしょうか。人工知能による 自動ダウングレードが必要な場合でも、よりきめ細かい制御を行うにはどうすればよいでしょうか?

上記の AI 要件に基づいて、各サービスに劣化重みを割り当て、よりインテリジェントなサービス ガバナンスを実現できます。評価値は、数学モデルを用いて 定性的および 定量的に評価することも、建築家が経験に基づいて決定することもできます。

5. まとめと展望

上記は、半実用的かつ半理論的なサービス劣化ソリューションです。ユーザーは、自社の実際の状況に基づいて適切な選択を行うことができます。完全なソリューションについては、著者はまだ実装されたものを見つけていません。ただし、長期的なサービスガバナンス計画を持つ大企業は、完全なソリューションの研究と実装を行うことをお勧めします。これは、将来の人工知能とインターネットオブエブリシングの時代に優れたガバナンス価値を持つでしょう（個人的な意見）。小規模な工場では、コストと価値を考慮すると、このような複雑なソリューションの使用は推奨されませんが、分散スイッチングと単純な階層的劣化機能を実装することはできます。

この論文では、より理想的なガバナンスマイクロサービスアーキテクチャを開発するために、主にサービス劣化に焦点を当てており、適切な数学モデルを使用して達成することを推奨しています。   定性  そして  定量化  将来に向けたマイクロサービスの合理的な分析とガバナンス  人工知能ガバナンス マイクロ サービス(AIGMS) はソリューション サポートを提供します。