マイクロサービスにおける電流制限ロジックとアルゴリズム

[[341117]]

この記事はWeChatの公開アカウント「Invincible Coder」から転載したもので、著者はInvincible Coderです。この記事を転載する場合は、Wudi Coder の公開アカウントにご連絡ください。

マイクロサービス アーキテクチャでよく言及される概念は、「サービス回路ブレーカーと電流制限」です。この概念が頻繁に言及される理由は、同時実行性の高いシナリオでは、瞬間的なトラフィックのピークがマイクロサービス内の各システムの最大収容能力を簡単に超え、サービス全体の利用不能を引き起こす可能性があるためです。

したがって、高同時実行シナリオ向けのマイクロサービス アーキテクチャを設計する場合は、高同時実行シナリオでのサービスの安定性を確保するために、サービスが耐えられる最大フローに基づいてフロー制限戦略を策定する必要があります。今日の記事では、一般的な電流制限アルゴリズムや現在のマイクロサービス アーキテクチャにおける主要な電流制限フレームワークなど、電流制限について説明します。

電流制限の概念

まず、流動制御とは何かを紹介します。実は、流動制御の場面は日常生活のいたるところで見られます。例えば、北京の地下鉄の朝のラッシュアワーには、毎日たくさんの人が押し寄せます。みんなが一斉に駅に駆け込むと、駅は混雑しやすくなります。そのため、地下鉄の駅は一般的に入り口に迷路のような柵を設け、みんながぐるぐると一団となって駅に入ります。これが典型的な流動制御の場面です。

では、マイクロサービスにおける電流制限とは具体的に何を意味するのでしょうか。文字通り、電流制限はフロー レートを制限します。フロー レートの定義はシナリオによって異なります。QPS (1 秒あたりのリクエスト数)、TPS (1 秒あたりのトランザクション数) の場合もあれば、純粋なネットワーク トラフィック (ネットワーク カードによって渡されるバイト数など) を指す場合もあります。

しかし、通常、現在の制限と呼ばれるものは、システムへの同時要求の数を制限することを指します。これにより、システム自身の能力が許す限り、システムは通常、一部のユーザー要求を処理し、システム自身の処理能力を超えるユーザー要求を拒否して、システムの安定した動作を確保します。

電流制限により、必然的にユーザー リクエストの失敗や速度低下が発生し、ユーザー エクスペリエンスに一定の影響を及ぼします。したがって、電流制限戦略の策定は、システム ストレス テストの結果に基づいて行う必要があり、ユーザー エクスペリエンスとシステムの安定性のバランスを取る必要があります。

電流制限は必要ですか?

先ほど、電流制限の主な目的はシステムの安定性を確保することであると述べました。日常業務では、ダブルイレブンのようなプロモーション活動や、クローラーなどの異常なトラフィックが発生すると、ユーザートラフィックが急増しますが、バックエンドサービスの処理能力には限界があります。突然のトラフィックを効果的に処理できない場合、バックエンドサービスは簡単に圧倒されてしまいます。

次のようなシナリオを想像してみてください。「サービスの 1 つのノードは 1000 QPS に耐えることができ、サービスには合計 5 つのノードがあり、通常の状況でのサービスの QPS は 3000 です。」通常の状況では、サービスに負荷はかかりません。3000/5=600 の負荷分散構成によると、各ノードの 1 日の QPS は約 600 しかありません。

ある日、上司が突然プロモーションを開始し、システム全体の QPS が 8,000 に達しました。この時点で、各ノードの平均 QPS は 1600 です。ノード A は耐えられず、最初にクラッシュします。この時点で、クラスターに残っているノードは 4 つです。各ノードの平均 QPS は 2000 に達します。そのため、残りの 4 つのノードが 1 つずつクラッシュし、サービス全体が崩壊します。

そして、私たちのシステムに有限フローメカニズムがあれば何が起こるでしょうか?

システム全体の QPS は 8,000 に達しますが、クラスター全体のフローは 5,000 に制限されているため、クラスターの許容値を超える 3,000 件のリクエストは拒否され、システムは 5,000 件のユーザー リクエストを正常に処理します。これは、クラスター全体のフロー制限のケースです。各ノードに関しては、私の許容範囲は 1000QPS のみなので、1000 を超える部分も拒否されます。これにより、一部のユーザーからのリクエストは失われますが、システム全体の安定性が確保され、システムを拡張するための開発と運用の時間を確保できます。

電流制限はシステムの自己保護にとって非常に重要であることがわかります。では、具体的にどのように電流を制限するのでしょうか? 次に、一般的な電流制限アルゴリズムをまとめます。

一般的な電流制限アルゴリズム

一般的な電流制限アルゴリズムには、カウンター、固定ウィンドウ、スライディング ウィンドウ、リーキー バケット、トークン バケットなどがあります。次に、これらの電流制限アルゴリズムをそれぞれ紹介します。

<逆電流制限>

カウンター電流制限は、最も単純かつ最も大まかな電流制限アルゴリズムです。たとえば、システムが同時に 100 件のリクエストを処理できる場合、カウンターを保存し、リクエストを処理し、カウンターを 1 つ増やし、リクエストが処理された後にカウンターを 1 つ減らすことができます。リクエストが届くたびに、まずカウンター値を確認します。しきい値を超えると、リクエストは直接拒否されます。

具体的な実装では、カウンターが単一マシンのメモリ内に存在する場合は、単一マシンの電流制限が実装されます。また、カウンターが Redis 内に存在し、クラスター内のすべてのノードが順番に電流制限の基準として使用される場合、クラスターの電流制限アルゴリズムが実装されます。

利点: シンプルな実装。Java の Atomic などのアトミック クラスを使用して単一のマシンに実装でき、Redis の incr 操作を使用してクラスターにすばやく実装できます。

デメリット: 逆流制限では、突然の交通量の増加に対応できません。たとえば、許可するしきい値が 1W で、カウンターの値が 0 の場合、1W のリクエストが一度に届いたときに、サービスが処理できない可能性があります。これは、流量の緩やかな増加と突然の流入によって、システムに異なる圧力が生じるためです。

さらに、電流制限は通常、フルタイム サービスの全体的な処理能力ではなく、指定された時間間隔内の訪問回数を制限するため、カウンター電流制限は、同時実行性の高いシナリオでの電流制限の実装には適していません。

<固定ウィンドウ電流制限>

カウンターと比較すると、固定ウィンドウの電流制限は時間ウィンドウ内の訪問回数に基づいており、カウンターは各時間ウィンドウの後に自動的にリセットされます。ルールは次のとおりです。

• リクエスト数がしきい値より少ない場合、アクセスは許可され、カウンターは 1 増加します。
• リクエスト数がしきい値を超えると、アクセスは拒否されます。
• この時間枠が経過すると、カウンターは自動的にクリアされます。

固定ウィンドウ電流制限は完璧に見えますが、固定ウィンドウの臨界性の問題があります。たとえば、システムでは 1 秒あたり 1000 件のリクエストが許可されます。最初の時間ウィンドウの間隔が 0 ～ 1 秒であるが、0.55 秒で 1000 件のリクエストが受信された場合、カウントは 1 秒後にゼロにリセットされ、その後 1.05 秒で再び 1000 件のリクエストが受信されます。

固定時間枠内のカウントはしきい値を超えていませんが、全体的な観点から見ると、0.55 秒から 1.05 秒までの 0.5 秒間に 2,000 件のリクエストが突然殺到しており、しきい値が 1,000/秒のシステムでは耐えられない状況です。次の図に示すように:

この問題を解決するために、スライディング ウィンドウ電流制限アルゴリズムが導き出されました。

<スライディングウィンドウ電流制限>

スライディング ウィンドウ電流制限は、固定ウィンドウの臨界値の問題を解決し、どの時間ウィンドウでも電流制限しきい値を超えないことを保証します。固定ウィンドウと比較すると、スライディング ウィンドウではカウンターの導入が必要になるだけでなく、各リクエストが時間ウィンドウ内に到着した時点の追加記録も必要になります。

1 秒の時間ウィンドウを例にとると、ルールは次のようになります。

• 各リクエストの時間を記録します。
• 各リクエストごとに 1 秒先の時間ウィンドウ内のリクエスト数をカウントし、1 秒前のデータを削除することができます。
• カウントされたリクエストの数がしきい値より少ない場合、リクエストの時間が記録され、通過が許可されます。それ以外の場合、リクエストは拒否されます。

見た目は問題ないように見えますが、スライディング ウィンドウでは、トラフィックの集中による影響を短期間で解決することはできません。たとえば、制限は 1 秒あたり 1,000 件のリクエストですが、最初の 5 ミリ秒でしきい値に完全に達する可能性があります。理想的には、10 ミリ秒ごとに 100 件のリクエストが受信され、システムがトラフィックをよりスムーズに処理できるようになります。

しかし、実際のシナリオでは、リクエストの頻度を制御することは困難です。そのため、タイム ウィンドウ アルゴリズムの問​​題点を解決するために、リーキー バケット アルゴリズムが登場しました。

<リーキーバケット電流制限>

リーキー バケット アルゴリズムの基本的な考え方は、リーキー バケットにトラフィックが継続的に流入し、下部では一定の速度でリクエストを処理するというものです。トラフィックが流入する速度が下部でリクエストが処理される速度よりも速く、バケット内のトラフィックがバケットのサイズを超えると、トラフィックがオーバーフローします。詳細は、次の図に示されています。

リーキーバケットアルゴリズムは、広い入口と厳格な出口が特徴です。リクエストレートがどれだけ速くても、下部の処理速度は均一です。このアルゴリズムの特性は、メッセージ キューの処理メカニズムと多少似ています。一般的に、リーキー バケット アルゴリズムもキューによって実装されます。

しかし、リーキー バケット アルゴリズムのこの特性は、実際には利点と欠点の両方になります。突然のトラフィックに直面したとき、私たちは、段階的に作業するのではなく、システムの安定性を維持しながらユーザー エクスペリエンスを向上させるために、ユーザー リクエストをより速く処理したいと考えることがよくあります。この場合、トークン バケット アルゴリズムなどの電流制限アルゴリズムが登場し、バースト トラフィックを処理する際にリーキー バケット アルゴリズムよりも積極的になる可能性があります。

<トークンバケットの現在の制限>

トークン バケットの原理はリーキー バケットの原理と似ていますが、リーキー バケットはリクエストを下から均一な速度で処理するのに対し、トークン バケットは一定の速度でトークンをバケットに入れ、トークンが取得された後にのみリクエストがサーバーによって処理されるという点が異なります。具体的なルールは以下のとおりです。

• 一定の速度でトークンをバケツに入れます。
• トークンの数がバケット制限を超えると、トークンは破棄されます。
• リクエストが届くと、まずバケットからトークンを要求します。リクエストが成功した場合は処理され、そうでない場合は拒否されます。

バーストトラフィックを処理する場合、トークンバケットはリーキーバケットのように均一な速度で処理するのではなく、短時間で同時にバケットからリクエストを取り出して、サーバーでタイムリーに処理することがわかります。したがって、トークン バケットはバースト トラフィックの処理において優れたパフォーマンスを発揮します。

電流制限アルゴリズムの概要

上記の説明から、リーキー バケットとトークン バケットはタイム ウィンドウ アルゴリズムよりもはるかに優れていることがわかります。では、タイム ウィンドウ アルゴリズムは役に立たないのでしょうか?

実はそうではありません。リーキー バケット アルゴリズムとトークン バケット アルゴリズムは、タイム ウィンドウ アルゴリズムよりもトラフィック シェーピング効果が優れていますが、それぞれに欠点もあります。たとえば、トークン バケットの場合、システムがオンラインになるときに予熱されていない場合、この時点でバケットにトークンがないため、リクエストが誤って強制終了される可能性があります。リーキー バケットでは、リクエストがバケットに一時的に保存されるため、リクエストを処理できるまでに遅延が発生し、インターネット サービスの低レイテンシ要件を満たしません。

したがって、トークン バケット アルゴリズムとリーキー バケット アルゴリズムは、電流制限シナリオ、つまりバックグラウンド タスクの電流制限をブロックするのに適しています。時間ウィンドウベースのフロー制御は、インターネット上でビジネス フロー制御を実装するシナリオに適しています。つまり、迅速に処理でき、時間内に呼び出し元に応答できないため、要求に対する過度の待機時間を回避できます。

マイクロサービス電流制限コンポーネント

興味があれば、実際に電流制限コンポーネントを自分で実装することもできますが、このホイールはすでに構築されています。現在、市場で人気のある電流制限コンポーネントには、Google Guava が提供する電流制限ツール クラス「RateLimiter」と Alibaba のオープン ソース Sentinel があります。

その中で、Google Guava が提供するレート制限ツールクラス「RateLimiter」はトークンバケットをベースに実装されており、アルゴリズムが拡張されて予熱機能をサポートしています。 Alibaba の Sentinel の均一なレート制限戦略では、リーキー バケット アルゴリズムが使用されます。

オリジナルリンク: https://mp.weixin.qq.com/s/A_iCvZKr1Gq2hUfV8PJ-RA