【マイクロサービスシステム設計】システム設計の基礎：レートリミッター

レートリミッターとは何ですか?

レート制限とは、操作の頻度が定義された制限を超えないようにすることを指します。大規模システムでは、基盤となるサービスとリソースを保護するためにレート制限がよく使用されます。レート制限は通常、共有リソースを利用可能な状態に保つための防御メカニズムとして分散システムで使用されます。

レート制限は、一定期間内に API に到達できるリクエストの数を制限することで、API を偶発的または悪意のある過剰使用から保護します。レート制限がなければ、どのユーザーもサーバーにリクエストを大量に送信し、他のユーザーをその急増に耐えられなくなる可能性があります。

職場でのレート制限

なぜ速度制限があるのでしょうか？

• リソース枯渇の防止: レート制限の最も一般的な理由は、リソース枯渇を回避して API ベースのサービスの可用性を向上させることです。レート制限を適用すると、負荷ベースのサービス拒否 (DoS) 攻撃を防ぐことができます。たとえ 1 人のユーザーが API に大量のリクエストを送信したとしても、他のユーザーが飢えることはありません。

• セキュリティ: レート制限により、ブルートフォース ログインやプロモーション コードなどのセキュリティを重視する機能が防止されます。これらの機能に対するリクエストの数はユーザー レベルで制限されているため、これらのシナリオではブルート フォース アルゴリズムは機能しません。

• 運用コストから保護: リソースを自動的に拡張する従量制モデルを使用すると、レート制限によりリソースの拡張に仮想的な上限を設けることで運用コストを制御できます。レート制限が使用されていない場合、リソースが不釣り合いに拡張され、その結果、請求額が急激に増加する可能性があります。

レート制限ポリシー

レート制限は次のパラメータに適用できます。

• ユーザー: 一定期間内にユーザーに許可されるリクエストの数を制限します。ユーザーベースのレート制限は、レート制限の最も一般的で直感的な形式の 1 つです。

• 2. 同時実行性: これにより、特定の時間枠内でユーザーが許可できる並列セッションの数が制限されます。並列接続の数を制限すると、DDOS 攻撃の軽減にも役立ちます。

• 3. 場所/ID: これは、場所ベースまたは人口統計に焦点を当てたキャンペーンの実行に役立ちます。ターゲット層からのリクエスト以外のリクエストを抑制して、ターゲットエリアの可用性を高めることができます

• 4. サーバー: サーバーベースのレート制限はニッチな戦略です。これは通常、特定のサーバーがほとんどのリクエストを必要とする場合、つまりサーバーが特定の機能に強く結合されている場合に使用されます。

レート制限アルゴリズム

漏れのあるバケット:

リーキーバケットはシンプルで直感的なアルゴリズムです。容量が制限されたキューが作成されます。指定された時間枠内でキューの容量を超えるすべてのリクエストはオーバーフローします。

このアルゴリズムの利点は、リクエストのバーストを平滑化し、一定のレートで処理できることです。ロード バランサーへの実装も簡単で、各ユーザーのメモリ効率が高くなります。リクエストの数に関係なく、サーバーへのほぼ均一な一定のフローを維持します。

漏れやすいバケツ

このアルゴリズムの欠点は、リクエストのバーストによってバケットがいっぱいになり、新しいリクエストが枯渇する可能性があることです。また、リクエストが指定された時間内に完了することも保証されません。

2. トークンバケット:

トークン バケットはリーキー バケットに似ています。ここでは、ユーザーレベルでトークンを割り当てます。指定された期間 d に対して、ユーザーが受信できるリクエスト r パケットの数を定義します。新しいリクエストがサーバーに到達するたびに、次の 2 つのアクションが実行されます。

• トークンの取得: このユーザーの現在のトークン数を取得します。定義された制限よりも大きい場合、リクエストはドロップされます。

• トークンの更新: 取得したトークンが期間制限 d 未満の場合、リクエストを受け入れ、トークンを追加します。

このアルゴリズムは、アプリケーションのユーザーごとに保存されるデータ量が少ないため、メモリ効率が高くなります。ここでの問題は、分散環境で競合状態が発生する可能性があることです。これは、2 つの異なるアプリケーション サーバーからの 2 つのリクエストが同時にトークンを取得しようとすると発生します。

トークンバケットアルゴリズム

3. 固定ウィンドウカウンター:

固定ウィンドウは、最も基本的なレート制限メカニズムの 1 つです。カウンターを一定期間保持し、リクエストを受信するたびにカウンターをインクリメントし続けます。制限に達すると、期間がリセットされるまで、それ以降のリクエストはすべてドロップされます。
ここでの利点は、最近のリクエストが確実に処理され、古いリクエストによって枯渇しないことが保証されることです。ただし、スロットルの境界でトラフィックが 1 回バーストすると、現在および次のスロットで使用可能なスロットがすべて蓄えられる可能性があります。消費者は、処理されるリクエストの数を最大化しようとして、エッジのサーバーを攻撃する場合があります。

固定ウィンドウカウンター

4. スワイプログ:

スライディング ログ アルゴリズムには、ユーザー レベルでのリクエストのタイムスタンプ付きログの維持が含まれます。システムは、これらのリクエスト時間をコレクションまたはテーブルに並べ替えます。タイムスタンプがしきい値を超えるすべてのリクエストをドロップします。私たちは毎分古いリクエストを検索し、フィルタリングして除外しています。次に、ログを合計してリクエスト率を決定します。リクエストがしきい値レートを超える場合は予約され、そうでない場合は処理されます。
このアルゴリズムの利点は、固定ウィンドウの境界条件の影響を受けないことです。レート制限の適用は引き続き正確に行われます。システムは各消費者のスワイプ ログを追跡するため、固定ウィンドウに挑戦するようなスタンピード効果はありません。
ただし、リクエストごとに無制限の数のログを保存するとコストがかかる可能性があります。各リクエストでは、場合によってはサーバーのクラスタ全体で、コンシューマの以前のリクエストの合計を計算する必要があるため、計算にもコストがかかります。そのため、大量のトラフィックやサービス拒否攻撃を処理するには十分な拡張性がありません。

5、引き違い窓：

これはスライディング ログ アルゴリズムに似ていますが、メモリ効率が高くなります。これは、固定ウィンドウ アルゴリズムの低い処理コストと、対数的に改善されたスライディング境界条件を組み合わせたものです。
時間順に並べ替えられたエントリのリスト/テーブルが保持され、各エントリにはタイムスタンプとその時点のリクエスト数が混合されます。期間のスライディング ウィンドウを維持し、ウィンドウ内で指定されたレートでのみリクエストを処理します。カウンタの合計がリミッターの指定レートよりも大きい場合、レート制限に等しい最初のエントリの合計のみが取得されます。
スライディング ウィンドウ アプローチは、良好なパフォーマンスを維持しながらレート制限を柔軟に拡張できるため、最適なアプローチです。レート ウィンドウは、レート制限データを API コンシューマーに提示する直感的な方法です。また、リーキーバケットの飢餓問題や固定ウィンドウ実装のバースト問題も回避します。

分散システムにおけるレート制限

上記のアルゴリズムは、単一サーバー アプリケーションに適しています。しかし、分散システムに複数のノードやアプリケーション サーバーが関与する場合、問題は非常に複雑になります。複数のレート制限サービスが異なるサーバー領域に分散している場合、問題はさらに複雑になります。このような状況で遭遇する 2 つの大きな問題は、不整合と競合状態です。

一貫性のない

独自のレート リミッターを持つ複数のアプリケーション サーバーが異なるリージョンに分散されている複雑なシステムの場合は、グローバル レート リミッターを定義する必要があります。
コンシューマが短期間に大量のリクエストを受信すると、個別にグローバル レート リミッタを超える可能性があります。ノードの数が多いほど、ユーザーがグローバル制限を超える可能性が高くなります。
これらの問題を解決するには 2 つの方法があります。

• スティッキー セッション: 各コンシューマーが 1 つのノードにのみ送信されるように、ロード バランサーにスティッキー セッションを設定します。欠点としては、耐障害性の欠如や、ノードが過負荷になった場合のスケーリングの問題などが挙げられます。スティッキーセッションの詳細については、こちらをご覧ください

• 集中型データ ストア: Redis や Cassandra などの集中型データ ストアを使用して、ウィンドウおよびコンシューマーごとのカウントを処理します。追加の遅延が問題になりますが、柔軟性が提供されるため、エレガントなソリューションになります。

競合状態

競合状態は、同時実行性の高い get-then-set メソッドで発生します。各リクエストはカウンターの値を取得し、それをインクリメントしようとします。しかし、書き込み操作が完了すると、他のいくつかのリクエストがすでにカウンターの値を読み取っています (これは正しくありません)。したがって、予想よりも多くのリクエストが送信されます。これは、読み取りおよび書き込み操作にロックを使用してアトミックにすることで軽減できます。ただし、これがボトルネックとなり遅延が増大するため、パフォーマンスが犠牲になります。

スロットリング

スロットリングは、一定期間、顧客による API の使用を制御するプロセスです。制限はアプリケーション レベルおよび/または API レベルで定義できます。スロットル制限を超えると、サーバーは HTTP ステータス「429 - Too Many Requests」を返します。
スロットルタイプ:

• ハード スロットリング: API リクエストの数は制限を超えることはできません。

• ソフト スロットリング: このタイプでは、特定のパーセンテージを超えて API リクエストのスロットルを設定できます。たとえば、レート制限が 1 分あたり 100 メッセージで、その制限を 10% 超える場合、レート リミッターは 1 分あたり最大 110 メッセージを許可します。

• 弾力的または動的制限: 弾力的制限では、システムに利用可能なリソースがある場合、リクエストの数がしきい値を超える可能性があります。たとえば、ユーザーが 1 分あたり 100 メッセージの送信しか許可されていない場合、システムに利用可能なリソースがある場合、そのユーザーに 1 分あたり 100 メッセージを超えるメッセージを送信させることができます。

読んでくれてありがとう！

この記事: https://architect.pub/system-design-basics-rate-limiter
ディスカッション: Knowledge Planet [チーフ アーキテクト サークル] または WeChat トランペット [ca_cto] を追加するか、QQ グループを追加します [792862318]
一般公開なし	【jiagoushipro】 【スーパーアーキテクト】 アーキテクチャの方法論、アーキテクチャの実践、技術原則、技術トレンドについての鮮やかなグラフィックと詳細な説明。 お待ちしておりますので、ぜひスキャンしてご注目ください。
WeChatのトランペット	[ca_cea] エンタープライズ アーキテクチャ、クラウド コンピューティング、ビッグ データ、データ サイエンス、モノのインターネット、人工知能、セキュリティ、フルスタック開発、DevOps、デジタル化について議論する 50,000 人のコミュニティ。
QQグループ	[285069459] エンタープライズ アーキテクチャ、ビジネス アーキテクチャ、アプリケーション アーキテクチャ、データ アーキテクチャ、技術アーキテクチャ、統合アーキテクチャ、セキュリティ アーキテクチャの詳細な交換。そして、ビッグデータ、クラウドコンピューティング、モノのインターネット、人工知能などのさまざまな新興テクノロジー。 QQ グループに参加して、貴重なレポートや乾物を共有してください。
ビデオ番号	【スーパーアーキテクト】 建築に関する基本的な概念、モデル、手法、経験が1分ですぐに理解できます。 1日1分、仕組みはおなじみです。
知識の惑星	[チーフアーキテクトサークル] 著名人に質問したり、連絡を取ったり、プライベートな情報を共有したりしてください。
ヒマラヤ	[スーパーアーキテクト] 最新のブラックテクノロジー情報と建築体験を道路や車の中で学びましょう。	[知的な瞬間、ミスター・アーキテクチャーがブラックテクノロジーについて語ります]
知識の惑星	より多くの友人、職場、技術的なチャットに会いましょう。	ナレッジプラネット【職場とテクノロジー】
リンクトイン	ハリー	https://www.linkedin.com/in/architect-harry/
LinkedInグループ	LinkedIn アーキテクチャ グループ	https://www.linkedin.com/groups/14209750/
微博	【スーパーアーキテクト】	賢い瞬間‍
ビリビリ	【スーパーアーキテクト】
チクタク	【cea_cio】スーパーアーキテクト
早い労働者	【cea_cio_cto】スーパーアーキテクト
小さな赤い本	[cea_csa_cto] スーパーアーキテクト
Webサイト	CIO（最高情報責任者）	https://cio.ceo
Webサイト	CIO、CTO、CDO	https://cioctocdo.com
Webサイト	アーキテクトの実践的な共有	https://architect.pub
Webサイト	プログラマーによるクラウド開発の共有	https://pgmr.cloud
Webサイト	チーフアーキテクトコミュニティ	https://jiagoushi.pro
Webサイト	アプリケーション開発と開発プラットフォーム	https://apaas.dev
Webサイト	開発情報ネットワーク	https://xinxi.dev
Webサイト	スーパーアーキテクト	https://jiagou.dev
Webサイト	企業向け技術トレーニング	https://peixun.dev
Webサイト	プログラマーの本	https://pgmr.pub
Webサイト	開発者チャット	https://ブログ.開発者.チャット
Webサイト	CPOコレクション	https://cpo.work
Webサイト	最高セキュリティ責任者	https://cso.pub ‍
Webサイト	CIOクール	https://cio.cool
Webサイト	CDO情報	https://cdo.fyi
Webサイト	CXO情報	https://cxo.pub

ご清聴、転送、いいね、ご視聴ありがとうございます。