要約: この記事は、Huawei Cloud のクラウドネイティブ サービスを使用したい人向けに、フォールト トレランスを通じてサービスの可用性と安定性を確保する方法に関する優れたガイダンスを提供します。
この記事は、HUAWEI CLOUD コミュニティ「高可用性クラウドネイティブ アプリケーションを構築する際にトラフィックを効果的に管理する方法」から共有されたものです。」、by BreakDawn。
クラウド ネイティブの概念がますます普及するにつれて、サービス アーキテクチャをどのように開発、進化させるべきかが、多くのプログラマーにとって関心のあるテーマとなっています。有名な本「Java 仮想マシンの徹底理解」の著者が 21 年ぶりに出版した新作「Phoenix Architecture」には、最新のテクノロジーや概念が数多く盛り込まれています。
したがって、この記事とフォローアップでは、この本の学習ノートと感想を蓄積して公開し続けます. 詳細な学習のためにこの本を購入することも、本質を理解するためにその後の学習ノートのリリースに注目することも歓迎します内容と要約の考え方。
交通管理
1 サービスフォールトトレランス
1.1 フォールトトレランス戦略
この記事では、フェイルオーバー、高速障害、安全な障害、サイレント障害、障害回復、並列呼び出し、ブロードキャスト呼び出しなど、いくつかのフォールト トレラント戦略を紹介しています。これらの戦略の違いを表の形式で直感的に示します。理解と選択に便利です:
1.2 フォールトトレラント設計パターン
1. サーキットブレーカーモード
つまり、サービス内でリクエストが送信される場所は、
10 秒以内にリクエストの数が 20 に達し、失敗のしきい値が 50% を超えると、サーキット ブレーカー モジュールを介して転送され送信されます (これらのパラメーターは調整可能です) 、問題があると見なされるため、サービスは自動的に中断されます。サーキット ブレーカーが受信したリクエストは自動的にエラーを返し、リモート サービスを呼び出さなくなるため、リクエスト スレッドのさまざまなブロックが回避されます。エラーは時間内に返される可能性があります。
復旧までの途中でリトライがあり、サーキットブレーカーが閉じます。
2. バルクヘッド分離モード
1 つのサービスで 3 つのサービス A\B\C を同時に呼び出すことができますが、それらはスレッド プールを共有します。
C サービスへの呼び出しがタイムアウトし、C サービスへの呼び出しが継続的に行われる場合、C サービスのすべての要求スレッドがブロックされ、スレッド プール全体が直接占有され、A\ への呼び出しに影響します。 Bサービス。
分離対策の 1 つは、呼び出しサービスごとに個別のスレッド プールを維持することです。デメリットとしては、キューイング、スケジューリング、コンテキストスイッチングなどのオーバーヘッドが追加されることであり、Hystrix スレッドプールでサービス分離を有効にすると遅延が 3 ～ 10ms 増加すると言われています。
もう 1 つの分離手段は、3 つのサービスのカウンタを直接定義し、サービス スレッドの数がしきい値に達すると、サービス コールを自動的に制限することです。
3. リトライモード
フェイルオーバーとフェイルバックの 2 つの戦略は通常、再試行モードを使用して処理され、呼び出しが繰り返し行われます。
再試行モードを使用するには、次の条件を満たしている必要があります。
- 重要なサービスではなく、幹線道路コア ロジックの主要なサービスに対してのみ同期再試行を実行します。
- 一時的な障害の場合のみ再試行し、ビジネス障害の場合は再試行しません。
- 冪等なサービスに対してのみ再試行する
再試行モードには、次のような明確な終了条件が必要です。
- タイムアウト終了
- 終了した回数
再試行は慎重に有効にする必要があります。ゲートウェイやロード バランサでデフォルトの再試行が構成されている場合があります。リンクが長くなり再試行が発生すると、システム内の再試行の数が大幅に増加します。
2 フロー制御
フロー制御では以下の3つの問題を解決する必要がある
- どのような指標に従ってフローを制限するか
- 電流を制限する方法
- 過剰なトラフィックに対処する方法
2.1 トラフィック統計指標 (トラフィックを制限するためにどのような指標が使用されるか)
- 1 秒あたりのトランザクション数 TPS: トランザクションは、ビジネス ロジックのアトミック操作によるビジネス操作です。書籍購入インターフェイスの場合、書籍の購入はトランザクションであり、その背後にある他のリクエストは認識されません。
- 1 秒あたりのリクエスト HPS: システムによって 1 秒あたりに処理されるリクエストの数です。1 つのトランザクションにリクエストが 1 つしかない場合は TPS=HPS、それ以外の場合は HPS>TPS となります。
- 1 秒あたりのクエリ ブック QPS:サーバーが応答できるクエリの数です。単一ノード システムの場合は QPS=HPS、分散システムの場合は HPS>TPS
最大 TPS を制限することによって電流が制限される場合、システムの圧力を正確に反映できないため、主流のシステムでは、優先電流制限インジケーターとして HPS を使用する傾向があります。
2.2 電流制限設計モード（電流制限の方法）
フローカウンターモード
1 秒あたりのリクエスト数がしきい値を超えているかどうかをカウントします
。 欠点:
- 1 秒ごとは 1.0 秒～2.0 などの間隔統計に基づいていますが、0.5 ～ 1.5 と 1.5 ～ 2.5 がそれぞれしきい値を超え、1.0 ～ 2.0 がしきい値を超えない場合、問題が発生します。
- 1 秒あたりのリクエストがしきい値を超えても、システムがそれに耐えられず、ペンタキルが発生するわけではありません。
スライディングタイムウィンドウ
スライディング タイム ウィンドウは、フロー カウンター モードの欠点に特に対処します。長さ 10 の配列を準備し、1 秒に 1 回タイマーをトリガーします。
- 配列の最後の要素を破棄し、すべての要素を 1 ビット戻してから、配列の最初の位置に新しい空の要素を挿入します。
- カウンタ内のすべての統計を最初の空の要素に書き込みます。
- 配列内のすべての要素をカウントし、カウンター データをクリアします。呼び出し数を単純に比較するだけで、どの時間セグメントでも制御リクエストの数がしきい値を超えないことを保証できます。
欠点は、拒否タイプの電流制限にしか使用できず、強制的に失敗またはダウングレードする必要があり、ブロックおよび待機の処理ができないことです。
漏れやすいバケツのパターン
リーキーバケットとトークンバケットは、電流制限のブロックと待機に使用できます。リーキー バケットは、リクエスト オブジェクトを要素とする先入れ先出しキューです。キュー レベルはリーキー バケットのサイズと同じです。キューがいっぱいになると、拒否レター付きのリクエストが入力されます。難しい理由は、流路の大きさや水の流量を決めるのが難しく、パラメータを調整するのが非常に難しいためです。
トークンバケットモード
定期的にトークンをバケットに配置します。最大 X 個のトークンを配置でき、リクエストごとに 1 つのトークンが消費されます。
タイマーに頼らずにトークンを投入することも可能ですが、タイムスタンプにより、トークン取得時の条件を満たしていれば、その時点でトークンを投入することができます。
2.3 分散型電流制限
前の 4 つの電流制限モードは、単一マシンの電流制限のみであり、多くの場合、ゲートウェイの入り口に配置されます。これらは、サービス クラスタ全体の複雑な状況には適用できません。たとえば、一部のサービスはより多くの電流を消費し、一部のサービスは消費量が多くなります。それらはすべて電流制限のために入り口に設置されています。
トークン バケットに基づいて、イングレス ゲートウェイでさまざまなサービスにさまざまな消費トークンの重みを追加して、分散クラスターの電流制限の目的を達成できます。
要約する
クラウドネイティブシナリオにおけるトラフィックガバナンステクノロジーの重要性
上記では主に、フェイルオーバー、高速障害、安全な障害、サイレント障害、障害回復、パラレル コール、ブロードキャスト コールなど、さまざまなフォールト トレランス戦略とフォールト トレランス設計パターンを含むサービス フォールト トレランスとフォールト トレランス設計パターンを紹介します。
これら 2 つの設計により、システムの安定性と堅牢性が確保されます。この記事で取り上げるトピックは、クラウド ネイティブ サービスと密接に関連しています。これは、クラウド ネイティブ アプリケーションは頻繁にリクエストして相互にやり取りし、高可用性を確保するにはフォールト トレランスと弾力性が必要であるためです。
したがって、この記事は、HUAWEI CLOUD のクラウドネイティブ サービスを使用したい人向けに、フォールト トレランスを通じてサービスの可用性と安定性を確保する方法に関する優れたガイダンスを提供します。
HUAWEI CLOUDがトラフィックガバナンスにおいてどのような役割を果たすか
HUAWEI CLOUDが提供するAPIGゲートウェイにサービスAPIを登録できれば、上記2つの設計は簡単に実現できそうです。
たとえば、APIG はサーキット ブレーカー戦略をサポートしています。これは、バックエンド サービスにパフォーマンスの問題が発生した場合にシステムを保護する API ゲートウェイの組み込みメカニズムです。API のバックエンド サービスで N 回連続のタイムアウトまたは高い遅延が発生すると、サーキット ブレーカーのダウングレード メカニズムがトリガーされ、API 呼び出し元に固定エラーが返されるか、指定されたダウングレード バックエンドにリクエストが転送されます。バックエンド サービスが通常に戻ると、サーキット ブレーカーが閉じられ、リクエストは通常に戻ります。APIG - サーキットブレーカーポリシー
同時に、APIG はトラフィック制御戦略も提供します。これは、ユーザー、資格情報、期間などのさまざまな側面からの API への呼び出し数の制限と、バックエンド サービスの保護をサポートします。分/秒の粒度レベルでのトラフィック制御をサポートしており、上記のいくつかのトラフィック ポリシーを読んでから、APIG で設定されているトラフィック ポリシーの値を見ると、理解しやすくなります。APIG フロー制御ポリシー
これらの一般的な古典的なサービス設計戦略では、車輪を再発明する必要はなく、既存のクラウド サービスを使用して関連機能を迅速に実装し、製品の発売速度と反復効率を向上させることができることがわかります。
クリックしてフォローして、Huawei Cloudの最新テクノロジーについて初めて学びましょう~