要約：RPCのレート制限とは、所定の時間枠内でアプリケーションがブロックチェーン ノードに送信できるリクエスト数を制限する仕組みです。制限を超えると、その時間枠がリセットされるまで、それ以降のリクエストは拒否されます（通常はHTTP 429エラーが返されます）。レート制限は、共有インフラストラクチャを悪用から保護し、すべてのユーザー に対して公平なアクセスを確保するために設けられています。レート制限を理解し、適切に管理することは、負荷がかかっても正常に動作する信頼性の高いブロックチェーン アプリケーションを構築するために不可欠です。
わかりやすい説明
1時間に100食を調理できるレストランの厨房を想像してみてください。50人の客がそれぞれ3品ずつ注文した場合、厨房はフル稼働状態になります。もし1人の客が50品も注文しようとした場合、他の客全員が食事を楽しめるように、厨房はその客の注文を断らざるを得ません。レート制限もこれと同じ仕組みで機能します。ブロックチェーン のノードには有限の処理能力があり、レート制限を設けることで、同じインフラストラクチャを利用する他のすべてのユーザーの犠牲の上に、単一のアプリケーションがその処理能力を独占することを防ぎます。
アプリケーションが短時間に過剰な数のRPCリクエストを送信すると、ノードは要求したデータではなくエラーを返します。ほとんどのプロバイダでは、これはHTTP 429「Too Many Requests」ステータスコードとして返され、多くの場合、by のようなJSON-RPCエラーボディが添付されます。このボディには、許可されているリクエスト数、実際に試行したリクエスト数、および再試行までの待機時間が記載されています。 アプリケーションがこれらのシグナルを無視してリクエストを送り続けると、プロバイダーは一時的にIPアドレスをブロックしたり、APIキーの使用を完全に停止したりする場合があります。
レート制限は通常、1秒あたりのリクエスト数（RPS）、1分あたりのリクエスト数、あるいはその両方の組み合わせで表されます。 プロバイダーによっては、無料プランで25 RPS、成長プランで300 RPS、エンタープライズプランで1,000 RPS以上を許可する場合があります。また、一部のプロバイダーではメソッドごとの制限を設けており、debug_traceTransactionや、大規模なブロック範囲を扱うeth_getLogsといった計算負荷の高いメソッドは、eth_blockNumberのような軽量なメソッドに比べて個別の制限が低くなる場合があります。
レート制限が存在する理由
レート制限には、主に3つの目的があります。第一に、インフラの安定性を保護することです。ブロックチェーン ノードは、ブロックチェーン のデータ全体を保持し、EVM呼び出しや状態の検索といった複雑な操作を実行するステートフルなシステムです。制限のないリクエストの集中は、ノードのCPU、メモリ、ディスクI/O、またはネットワーク帯域幅に過大な負荷をかけ、すべてのユーザー のパフォーマンスを低下させたり、ノードを完全にクラッシュさせたりする可能性があります。レート制限は、単一のクライアントが連鎖的な障害を引き起こすのを防ぐサーキットブレーカーとしての役割を果たします。
第二に、レート制限はリソースの公平な配分を保証します。共有インフラストラクチャ（開発者 の多くがこれを利用しています）では、数百から数千ものアプリケーションが同じノードプールを共有しています。レート制限がなければ、過度なインデックス作成スクリプトを実行しているアプリケーションや、設定ミスによるポーリングループが、利用可能な容量の大部分を消費してしまい、他のアプリケーションが必要なリソースを確保できなくなる可能性があります。レート制限は、すべてのアプリケーションが妥当な割合のリソースを確実に得られるよう保証する、フェアユースポリシーを徹底するものです。
第三に、レート制限は悪用を防ぐための対策です。意図的か偶発的かを問わず、サービス拒否攻撃（DoS攻撃）は、多くのアプリケーションが依存しているインフラをダウンさせる可能性があります。レート制限を設けることで、悪意のある攻撃者が公開エンドポイントを攻撃手段として悪用することを防ぐだけでなく、善意の開発者 が制御不能になったスクリプトによって誤ってノードにDDoS攻撃を仕掛けてしまう事態も防ぐことができます。
レート制限がアプリケーションに与える影響
アプリケーションがレート制限に対応するように設計されていない場合、本番環境で動作しなくなります。最も一般的な障害の原因mode は、ブロックチェーン に対して過度に頻繁にクエリを送信するポーリングループです。新しいブロックの有無を確認するために 100 ミリ秒ごとに「eth_blockNumber」を呼び出すアプリケーションは、このメソッドだけで 1 分間に 600 回のリクエストを送信することになります。さらに、残高の確認、ログの照会、およびアクティブなユーザー ごとにトランザクションステータスのポーリングを加えると、たとえ寛大なレート制限であっても、簡単に上限を超えてしまうことになります。
WebSocketのサブスクリプションもレート制限の対象となる場合があります。最初のサブスクリプションリクエストは1回の呼び出しとしてカウントされますが、サーバーからの受信メッセージ（新しいブロックの通知や保留中のトランザクションのアラートなど）は、プロバイダーによっては使用量にカウントされる場合があります。アプリケーションが複数のコントラクトにわたって高頻度のイベントstreams をサブスクライブしている場合、受信メッセージの量は急速に増加する可能性があります。
レート制限によってリクエストが失敗すると、波及効果が生じます。アプリが要求したデータを受け取れない場合、リクエストを再試行し、負荷をさらに増大させる可能性があります。再試行に指数関数的なバックオフが実装されていないと、レート制限されたリクエストがさらなるリクエストを生み出し、それがさらなるレート制限を招くというフィードバックループが発生します。このパターンにより、レート制限の制限枠がリセットされるまで、アプリケーションが事実上RPCから締め出されてしまう可能性があります エンドポイント 。
レート制限を管理するための戦略
最も効果的な戦略は、アプリケーションが行う必要のあるリクエストの数を減らすことです。キャッシュはこのアプローチの基盤となります。アプリでETHの価格、トークンのメタデータ、またはその他の変化の緩やかなデータを表示する場合は、ページが読み込まれるたびに、あるいはユーザー アクションが行われるたびにノードにクエリを送信するのではなく、それらの結果をローカルにキャッシュし、適切な間隔で更新するようにしてください。ブロックごとに変化するデータについては、HTTPによるポーリングではなくWebSocket経由でサブスクライブしてください。1回のサブスクライブで、何千もの個別のポーリングリクエストを置き換えることができるからです。
リクエストをバッチ処理することで、HTTPのオーバーヘッドを軽減し、レート制限内に収めることができます。10種類のウォレット残高を取得するために10回の個別の呼び出しを行う代わりに、それらを1つのJSON-RPC配列リクエストにまとめてください。ノードはそれぞれを個別に処理しますが、それらすべてを送信するのに必要なHTTPリクエストは1回だけです。なお、一部のプロバイダーでは、HTTPリクエスト自体だけでなく、バッチ内の各メソッド呼び出しもレート制限の対象としてカウントされる点に注意してください。
クライアント側でのレート制限の実施は、防御的なベストプラクティスです。サーバーがリクエストを拒否するのを待つのではなく、送信されるリクエストのレートを追跡し、既定の制限を超える可能性のあるリクエストをキューに格納するか、遅延させるようにします。これにより、アプリケーションを先手を打って許容範囲内に収めることができ、リクエストが拒否されることによるレイテンシーの増加を回避できます。bottleneck（Node.js）やratelimit（Python）などのライブラリを使用すれば、これを簡単に実装できます。
利用状況に適したインフラストラクチャ・ティアを選択することが、結局のところ最も信頼性の高い解決策となります。アプリケーションが常にレート制限に引っかかってしまう場合は、さらなる最適化の手法ではなく、より多くの容量が必要です。より高いティアにアップグレードするか、専用インフラストラクチャに移行することで、レート制限に関する懸念を完全に解消することができます。
HTTP 429 エラーとはどういう意味ですか？
HTTP 429「Too Many Requests」というレスポンスは、現在の時間枠における許可されたリクエストレートを超過したことを意味します。ノードに不具合があるわけではなく、通常は認証情報にも問題はありません。単に、プランで許可されている速度よりも速くリクエストを送信しているだけです。対処法としては、レスポンスを確認し（多くの場合、待機時間が指定されています）、その遅延時間が経過した後、指数関数的なバックオフを用いて再試行してください。これにより、繰り返し失敗することでさらなる負荷がかかるのを防ぐことができます。 429エラーが繰り返し発生する場合は、無理に再試行するのではなく、リクエストの量を減らすか、より大容量のティアに移行する必要があります。RPCリクエストの仕組みや、RPCエンドポイントが呼び出しをどのように処理するかを理解しておけば、なぜ特定のメソッドが他のメソッドよりも早く制限に達してしまうのかが分かりやすくなります。
RPCのレート制限に引っかからないようにするにはどうすればよいでしょうか？
レート制限を回避するには、主に、リクエストの数を減らし、コストを抑え、リクエストを分散させることが重要です。以下の表では、最も効果的な手法と、それぞれが最も適している場面をまとめています。
テクニック | 機能の説明 | こんな方に最適 |
|---|---|---|
キャッシュ | 変化の緩やかなデータについては、結果を再利用する | 価格、メタデータ、残高 |
ポーリングによるストリーミング | 繰り返し行われるポーリングをプッシュ型データに置き換える | ブロックごとの更新とインデックス作成 |
バッチ処理 | 複数の呼び出しを1つのリクエストにまとめる | バルクは、多くの残高と同様に読み取られます |
ポーリングからストリーミングへの切り替えは、多くの場合、リクエスト数を削減する上で最も効果的な手段となります。最適化だけでは不十分になった場合、どの程度の処理能力と信頼性 を自社で保有するかという観点から、「自社開発か外部調達か」という判断が求められます。
レート制限とスロットリングの違いは何ですか？
これらの用語はしばしば同じ意味で使われますが、過大な負荷に対する対応は異なります。レート制限は厳格な上限を課すもので、一度その上限を超えると、リクエストは即座に拒否されます（通常は429エラーが返されます）。スロットリングはより柔軟な対応です。リクエストを拒否するのではなく、システムが処理速度を落とすか、キューに格納することで、処理自体は完了しますが、完了までに時間がかかります。どちらも共有インフラを保護する目的ですが、クライアントの視点から見ると、その失敗の仕方は異なります。
アスペクト | レート制限 | スロットリング |
|---|---|---|
過剰に対する対応 | リクエストを拒否します | リクエストの処理が遅くなったり、キューに蓄積されたりします |
典型的な信号 | HTTP 429 エラー | レイテンシの増加 |
顧客への影響 | 失敗した通話の再試行 | 遅延したが完了した通話 |
どちらも、アプリケーションの観点からはRPCの遅延が悪化したように見える可能性があり、どちらもインフラストラクチャにおける全体的なスループットと遅延のトレードオフと密接に関連しています。
よくある質問
RPCのレート制限として妥当な値はどれくらいでしょうか？
これは、ワークロードやプランによって異なります。無料プランでは1秒あたり約25リクエストまで許容される場合がありますが、GrowthプランやEnterpriseプランでは数百～数千リクエストに達します。適切な上限値とは、キャッシュ、バッチ処理、ストリーミングを適用した後に、ピーク時のリクエストレートを余裕を持って上回る値のことです。
429レスポンスにはどのように対処すればよいでしょうか？
ひたすらリクエストを送り続けるのではなく、一旦距離を置いてから再試行してください エンドポイント。ジッター付きの指数関数的バックオフを採用し、レスポンスに含まれる「再試行までの待機時間」の指定を遵守し、再試行回数を制限してください。429エラーが継続する場合は、再試行の頻度を増やすのではなく、リクエスト量を減らすか、容量を拡張してください。
一括リクエストは1つのリクエストとしてカウントされますか？
必ずしもそうとは限りません。バッチは単一のHTTPリクエストとして送信されますが、多くのプロバイダーでは、バッチ内の各メソッド呼び出しをレート制限の対象としてカウントします。バッチ処理によってネットワークのオーバーヘッドは軽減されますが、レート制限の対象となる呼び出し回数が必ずしも減るわけではありません。
ストリーミングならレート制限を回避できるのでしょうか？
概して言えば、データ取り込みの目的ではそうです。プッシュ型のストリームでは、新しいブロックチェーン データが生成されるたびに即座に配信されるため、何千回ものポーリング呼び出しを行う必要がなく、そもそもレート制限を引き起こすリクエストの大部分を削減できます。
なぜ一部のメソッドは、より厳しくレート制限がかけられているのでしょうか？
トランザクションの追跡や大規模なログクエリといった計算負荷の高いメソッドは、最新のブロック番号を取得するといった軽量な呼び出しに比べて、はるかに多くのノードリソースを消費します。プロバイダーは、ノード全体の安定性を確保するため、こうした負荷の高い呼び出しに対して、メソッドごとの制限をより厳しく設定しています。
Quicknode におけるレート制限の処理方法
Quicknode 開発者 が使用量を管理する柔軟なレート制限機能を提供します エンドポイント利用状況を管理できるようにします。プランレベルのRPS制限に加え、Quicknode ではメソッドレベルのレート制限機能を提供しており、個々のRPCメソッドに対して正確な制限を設定できます。これは特に、 エンドポイント 制御に特に役立ちます。制限は、ダッシュボードのUIまたはConsole APIを介したプログラム的な方法により、メソッドごとに秒単位、分単位、または日単位で設定できます。
Quicknode また、個々のIPアドレスからのリクエスト総数を制御するためのIPベースのレート制限機能も提供しており、これは エンドポイント リクエスト量を完全に制御できないクライアントサイドのアプリケーションに公開されている場合に役立ちます。Quicknode ダッシュボードのリアルタイム分析では、メソッド呼び出し数、レスポンスステータス、レスポンスタイムが表示され、利用パターンを完全に可視化できるため、レート制限の問題となる前に課題を特定し、対処することができます。
レート制限を完全に回避する必要があるチーム の場合、Quicknode Streams リクエスト・レスポンスのパターンを、プッシュ型のデータ配信モデルに置き換えます。アプリケーションが1分間に数千回もノードをポーリングする代わりに、Streams は新しいブロックが生成されるたびに、ブロックチェーン のデータをWebhook、データベース、またはデータウェアハウスに直接プッシュします。これにより、データ取り込みワークロードにおけるRPCのレート制限が完全に解消されるだけでなく、レイテンシの低減やバックエンドアーキテクチャの簡素化も実現します。
参考資料
メソッドのレート制限の設定方法-Quicknode ガイド
効率的なRPCリクエストのガイド-Quicknode
「Streams 」の入門-Quicknode Docs
Quicknode Core API
