自分でテストしたい場合は、下にスクロールしてください!!
1 秒あたり何百万ものリクエストを処理しますか?それは可能ですか？ ?
大規模な分散システムについて話すと、物事が…複雑になることがあります。ご存知のとおり、レート制限は悪用を防ぐために不可欠ですが、多くの場合ボトルネックになります。 1 秒あたり 100 万リクエスト を滞りなく処理できるシステムを設計したと言ったらどうなるでしょうか? Go で書かれたオープンソースの分散レート制限ライブラリである ThrottleX を紹介します。
この投稿では、カーテンを引いて、私たちがこの驚くべき規模をどのように達成したかを正確に説明します。高度な最適化、それをすべて可能にした Go 同時実行モデル、そして途中で遭遇した意外なボトルネックについても説明します。しかし、これは単なる理論ではありません。私たちが達成した実際のベンチマークを共有します。もうすぐ限界を突破するので、しっかりしてください! ?
スケーリングレート制限は、極端なスケールで実行してみるまでは簡単そうに見えるものの 1 つです。ほとんどのシステムは、1 秒あたり数百または数千のリクエストを処理できます。しかし、何百万ものリクエストに達すると、事態は急速に崩壊します:
その秘訣はレートを制限するだけではなく、複数のノードにわたって効率的に実行し、利用可能なリソースをすべて消費することなくすべてのリクエストが超高速で処理されるようにすることです。そこで ThrottleX が登場します。速度を重視して構築され、規模を考慮して設計されており、レート制限アルゴリズムとリアルタイムの最適化を組み合わせて使用して、ゲームの先を行き続けます。
しかし、なぜこれが重要なのでしょうか?実際のシナリオをいくつか見てみましょう:
ThrottleX は単なるレート リミッターではありません。極端な条件向けに設計されており、どのようにして限界まで押し上げたかを正確に説明します。
ThrottleX の中心となるのは、スマートなレート制限アルゴリズムの組み合わせと高度に最適化された同時実行モデルです。しかし、重要なのはアルゴリズムだけではありません。アルゴリズムがどのように実装され、分散環境全体でどのように拡張可能にするかが重要です。すべてを機能させる中核となるアーキテクチャを詳しく見てみましょう。
レート制限に関して言えば、おそらく次のような古典的なものを聞いたことがあるでしょう。
ThrottleX は車輪の再発明はしませんが、これらの実証済みのアルゴリズムを採用し、よりスマートにしました。その方法は次のとおりです:
ThrottleX が Go に組み込まれている理由の 1 つは、その ゴルーチン と チャネル であり、最小限のオーバーヘッドで驚異的な同時実行性を実現します。 Go の同時実行モデルが私たちにとって大きな変革をもたらした理由は次のとおりです:
平たく言えば、超効率的な組立ラインのようなものです。すべてのワーカー (ゴルーチン) は、他の人が終わるのを待たずに自分の仕事をこなします。
分散レート リミッターには 共有状態 が必要です。ここで Redis が活躍します。しかし、Redis を接続してそれで終わりというわけにはいきません。最適化する必要がありました。
スケールアップするために使用したもう 1 つのトリックは、リクエストのバッチ処理です。 ThrottleX は、すべてのリクエストを個別に処理するのではなく、バックグラウンドでまとめてバッチ処理します。これにより、Redis バックエンドにアクセスする操作の数が減り、ラウンド トリップが減り、スループットが高速化されます。
郵便で荷物を送るようなものだと考えてください。手紙ごとに郵便局に行く代わりに、束が揃うまで待って一度にすべて送るので、時間と労力を節約できます。
Go のパワーと最適化された Redis 構成に基づいて構築されたこのアーキテクチャにより、ThrottleX は大量のトラフィック負荷を効率的に処理できるようになりました。そして一番いいところは？すべて最小限の調整で拡張できるように設計されているため、数千または数百万のリクエストを処理するかどうかに関係なく、ThrottleX が対応します。
それでは、実際に ThrottleX をプッシュして、システムをクラッシュさせたりインフラストラクチャを破壊したりすることなく、1 秒あたり数百万のリクエスト を処理できるようにしたのでしょうか?結局のところ、レート制限アルゴリズムと基盤となるシステム アーキテクチャの両方において、一連の慎重に最適化が行われました。秘密のソースはこちらです:
最大の変革要因の 1 つは、リクエストのバッチ処理でした。すべてのリクエストを個別に処理するのではなく、リクエストをバッチにグループ化しました。これにより、バックエンド (Redis) にアクセスする操作の数が大幅に減少し、ラウンドトリップが減少し、レイテンシーが短縮され、スループットが高速化されました。
言い換えると、通常は 10 件のリクエストを処理するのにかかる時間で 100 件のリクエストを処理するようなものです。この最適化だけで、ベンチマークのスループットが 50% 増加しました。
この規模のトラフィックを処理していると、問題が発生する可能性があり、また問題が発生する可能性があります。トラフィック急増時に ThrottleX が圧倒されないようにするために、サーキット ブレーカー パターンを実装しました。
その仕組みは次のとおりです:
この設計は、システムに激しい負荷や一時的な障害が発生した場合でも、高可用性を維持するのに役立ちます。これがないと、Redis レプリケーションに遅れが生じたり、トラフィックが予期せず急増したりした場合に、ThrottleX が機能しなくなります。
同時実行性は諸刃の剣です。 Go のゴルーチンは軽量ですが、それでもメモリ管理が必要です。規模を拡大するにつれて、ガベージ コレクション (GC) プロセスがボトルネックになり、特に高負荷下でパフォーマンスに悪影響を及ぼしました。
私たちの解決策は? リソースのプール:
結果は? メモリ使用量が 30% 削減し、トラフィック バースト時のパフォーマンスが大幅にスムーズになりました。
Redis が大量のリクエスト負荷に確実に対応できるようにするために、パイプライン 機能を微調整しました。各コマンドを一度に 1 つずつ Redis に送信する (これにより遅延が発生します) 代わりに、複数のコマンドを 単一のリクエスト にバンドルしました。これにより、Redis はコマンドのバッチを並行して処理できるようになり、応答時間が大幅に短縮されました。
Redis パイプラインの魅力は、ネットワーク I/O を最小限に抑え、スループットを向上させる方法にあります。この最適化により、Redis は ミリ秒未満のレイテンシ で 1 秒あたり数百万のリクエストを処理できるようになりました。
適応型にすることで、レート制限を次のレベルに引き上げました。全体的に固定レートを使用する代わりに、ThrottleX はリアルタイムの交通状況に基づいてレート制限を動的に調整できます。
想像してみてください。通常のトラフィック中、システムは一貫したリクエスト フローを許可します。ただし、突然のスパイク (e コマース サイトのフラッシュ セールやアプリのバイラル モーメントなど) が発生した場合、ThrottleX は制限を一時的に緩和し、あまりにも積極的にスロットリングすることなく、より多くのトラフィックが通過できるようにします。スパイクが収まると、レートは自動的に元に戻ります。
この適応型アプローチにより、バックエンドを悪用から保護しながら、トラフィックの急増時に正当なユーザーが抑制されることがなくなります。
私たちはレート制限を超えて、大規模に何が起こっているかを可視化したかったのです。これを行うために、リアルタイム監視を Prometheus や Grafana などのツールと統合しました。これにより、主要な指標を追跡できるようになりました。
これらの洞察により、パフォーマンスのボトルネックを早期に発見し、問題になる前にシステムを微調整することができました。ダッシュボードにリアルタイムのトラフィックとシステムの健全性が表示されるため、ピーク負荷時でも ThrottleX のパフォーマンスを監視できます。
これらの最適化が連携することで、1 秒あたり 100 万リクエスト を処理できる機能が解放されました。バッチ処理やパイプライン処理からメモリの最適化や適応型レート制限に至るまで、それぞれの調整により、ThrottleX はハイパースケールの領域にさらに押し上げられました。 ?
本当のことを言いましょう。最適化について話すのは簡単ですが、証拠は常に数字にあります。一連のストレス テスト、ベンチマーク、微調整を経て、ThrottleX で達成した実際の指標を次に示します。
次の構成を使用してテストを実行しました:
ここからは楽しい部分です。 結果は次のとおりです:
ThrottleX は、低遅延と全体的なリソース消費を最小限に抑えながら、この負荷を処理しました。
分散システムを扱う場合、特にこの規模ではレイテンシーが常に懸念されます。ただし、ThrottleX は、極端なトラフィック下でも一貫して ミリ秒未満の応答時間 を実現しました。
Redis のパイプライン処理やリクエストのバッチ処理などの最適化のおかげで、データベースへの往復を最小限に抑え、レイテンシーを 1 ミリ秒未満に抑えることができました。
ゴルーチンとメモリ プーリングを最適化することで、従来のレート リミッタと比較してメモリ使用量の 30% 削減を達成しました。内訳は次のとおりです:
システム内を何百万ものリクエストが飛び交っていても、ThrottleX はメモリ効率を維持し、リソース消費を低く抑えました。
システムがあちこちでエラーをスローする場合、大量のトラフィックを処理する意味はありませんか?幸いなことに、ThrottleX は盤石な信頼性を提供しました:
この信頼性は、システムの過負荷と連鎖的な障害の防止に役立つ適応レート制限とサーキット ブレーカー パターンの有効性の証拠です。
これらのベンチマークは、机上で優れているだけではなく、現実世界のストレス テストによって裏付けられており、ThrottleX がパフォーマンスを損なうことなく極端なトラフィック負荷を処理できることを示しています。
そしてここが一番良いところです: 自分で試してみることができます! ?
これらのベンチマークに使用したすべてのコードと構成は、ThrottleX リポジトリ で入手できます。それをフォークして独自のテストを実行し、さらに進化できるかどうかを確認してください。このプロジェクトはオープンソースであり、コミュニティが何をもたらしてくれるかを見るのがいつも楽しみです。アルゴリズムの改善であっても、さらに高いスループットを実現するための最適化であっても、貢献やアイデアを歓迎します。
このサンプル アプリ、モニタリング コードへのリンク: https://github.com/neelp03/ThrottleX-Test
1 秒あたり 100 万リクエスト を処理できるものを構築するのは大変な作業であり、途中で貴重な教訓を学んだいくつかの予期せぬ課題に遭遇しました。私たちが最も驚いたことと、これらの障害にどのように取り組んだかについて説明します。
最初にスケールアップを開始したとき、トラフィックが多いときに応答時間がランダムに急増することに気づきました。この問題を詳しく調べた結果、Go の ガベージ コレクション (GC) が静かにパフォーマンスの問題を引き起こしていることがわかりました。
教訓: Go のメモリ管理は効率的ですが、大規模な場合は、パフォーマンスのボトルネックを避けるためにメモリを細かく管理する必要があります。
Redis は高速ですが、1 秒あたり数百万のリクエストを処理する場合、レプリケーション ラグ が発生しました。トラフィックが多い状態では、ノード間でデータをレプリケートする Redis の機能が書き込み負荷に追いつくことができませんでした。
学んだ教訓: Redis は猛獣ですが、大規模なスケールでは、パフォーマンスを高く保つために一貫性と可用性の間のトレードオフが必要になります。
分散ノード間でテストを行ったところ、ネットワーク遅延が、特にリクエストがリージョンを越えて送信される必要がある場合に急速に増加していることがわかりました。大規模な場合、数百万のリクエストに数ミリ秒の遅延が重なると、深刻なパフォーマンスの低下を引き起こす可能性があります。
学んだ教訓: ネットワーク呼び出しを最小限に抑えるは、分散システムにとって重要です。外部通信への依存が少なくなるほど、システムの回復力と速度が向上します。
適応レート制限は状況を大きく変えるものでしたが、トラフィックの急増の許容と保護の維持との間のバランスを適切に保つことは、予想よりも困難でした。
学んだ教訓: 適応は強力ですが、過剰な修正を避けるために微調整する必要があります。調整が多すぎることは、調整が少なすぎることと同じくらい危険です。
ThrottleX の構築とスケーリングから、大規模なパフォーマンスは適切なバランスを見つけることがすべてです: メモリ使用量、ネットワーク遅延、レプリケーション、レート制限のバランスをとることがわかりました。すべての最適化にはトレードオフが伴いましたが、それぞれの課題により、より回復力があり、より高速なシステムを構築することが求められました。
ThrottleX は、極端なトラフィック負荷を処理できる、実績のある分散型レート リミッターです。しかし、さらに多くの余地が常にあります。新しい機能を提供したい場合でも、さまざまな条件でテストしたい場合でも、パフォーマンスをさらに向上させるために調整したい場合でも、ThrottleX リポジトリ はオープンしてお待ちしています。
一緒に限界を押し広げて、どこまでできるか試してみましょう。
以上がThrottleX: 苦労せずに 1 秒あたり 100 万件のリクエストに拡張の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
