APIレート制限とは（徹底解説）

API（アプリケーション・プログラミング・インターフェース）は、アプリケーションが相互に通信するための手段。APIを使用すれば、アプリケーション間でリソースや権限を共有することができます。

今日、多くのB2B企業がAPIサービスを提供しており、さまざまなプログラミング言語、フレームワークで構築されたアプリケーションで利用することができます。しかしAPIには、DoS攻撃やDDoS攻撃の脆弱性や、ユーザーに配分される帯域幅のばらつきなどの懸念点も。このような問題は、「APIレート制限」という技術を使って解消することができます。レート制限とは、ユーザーがAPIに対して行えるリクエスト数の制限です。

今回は、APIレート制限の概要と設定方法、そしてAPIレート制限のベストプラクティスと使用事例をご紹介します。

APIレート制限とは

APIレート制限とは、APIがユーザーによってアクセスされる回数にしきい値や制限を設けることです。制限する方法はいくつかあります。

1. ユーザーベースの制限

まず1つは、特定のユーザーが与えられた時間枠の中でAPIにアクセスできる回数を減らす、ユーザーベースの制限です。同じAPIキーまたはIPアドレスからのリクエスト数をカウントし、しきい値に達すると、それ以降のリクエストは制限（スロットルとも）または拒否されます。

2. ロケーションベースの制限

APIで利用可能な帯域幅を特定の地域に均等に分配したいこともあります。

ロケーションベースのレート制限の代表例は、ChatGPTの無料プレビュー版。サービス向上のためのより良いサンプルデータを生成するには、世界中のユーザーに幅広く使用してもらうことが望ましく、地域ごとに制限を設けるのが理に適っています。

3. サーバーベースの制限

3つ目は、CPU、メモリ、ディスク容量などのサーバーリソースを均等に分散するため、サーバー側で設定する内部レート制限。デプロイメントのサーバーごとに制限を設定することで実現可能です。

あるサーバーが上限に達すると、それ以降のリクエストは、利用可能な容量を持つ別のサーバーにルーティングされます。すべてのサーバーが容量に達した場合、ユーザーにステータスコード「429 Too Many Requests」を返します。なお、この制限方法は、地理的な場所やアクセス時間などに関わらず、すべてのユーザーに適用されます。

APIレート制限の種類

レート制限の導入方法とは別に、エンドユーザーへの影響に基づいてレート制限を分類することも可能です。主に以下のような種類があります。

• ハード（強制）：上限に達すると、制限が解除されるまでリソースへのアクセスが完全に制限される。
• ソフト（柔軟）：上限に達しても、突然アクセスが遮断されるのではなく、その後数回はリソースにアクセスできる（またはリクエストを制限）。
• 動的：リソースを効率的に使用するため、サーバー負荷、ネットワークトラフィック、ユーザーの場所や行動、トラフィック分布などの複数の要因に基づいてリアルタイムで変動する。
• スロットル：リソースへのアクセスを遮断するのではなく、制限が解除されるまで、リクエストの受信を減速、またはキューに加える。
• 課金：アクセスを制限したり処理速度は調整せず、設定された無料のしきい値を超えると、それ以降のリクエストに対して課金が発生する。

APIレート制限を設定すべき理由

Web APIにレート制限を設定すべき理由はいくつもあります。以下、代表的なものをご紹介します。

1. リソースアクセスの保護

レート制限を行うことで、悪意のあるユーザーによるリソースの過剰利用を阻止することができます。APIには、DDoS攻撃などによってリソースが独占され、利用者のための機能が妨げられる可能性がありますが、レート制限を設けておけば、第三者が容易に攻撃を仕掛けることができなくなります。

2. ユーザーへのリソースの分配

リソースの保護とは別に、APIリソースをユーザーに平等に分配することもできるように。階層化された価格設定を作成し、他のユーザーに影響を与えることなく、動的な需要に対応可能です。

3. コスト効率の向上

ユーザーにリソースを適切に分配することができれば、コスト効率も向上します。分割された構造があれば、システムの保守管理に必要な費用の見積もりも行いやすくなります。適切な量のリソースをプロビジョニング（提供準備）または解除することで、あらゆる変動にもスマートに対処可能です。

4. ワーカー間のフロー管理

多くのAPIは複数のワーカー、スレッド、インスタンスを使って送られてくるリクエストを処理する、分散アーキテクチャに依存しています。このような構造では、レート制限を設けて、各ワーカーノードに渡される負荷を制御することができます。これによって、ワーカーノードが平等かつ持続可能な負荷を受け取れるように。APIゲートウェイ全体を再構築することなく、必要に応じてワーカーを簡単に追加・削除することができます。

バースト制限とは

APIの利用を制御する別の方法として、レート制限の代わりにバースト制限（スロットリングとも）を設定することもできます。バースト制限とは、簡単に言えば、非常に短い間隔（数秒間など）で設定するレート制限です。例えば、月間130万件のリクエストの代わりに、「1秒あたり5件リクエスト」というような制限を設定することができます。どちらも同じ月間トラフィックに相当しますが、後者はクライアントが一度に何千ものリクエストを送信し、サーバーに過負荷がかかるのを防ぎます。

バースト制限の場合、一般にリクエストは拒否されるのではなく、次のインターバルまで待機することになります。トラフィックと使用量を適切に管理するために、レート制限とバースト制限を併用することもよく推奨されています。

APIレート制限を設定する3つの方法

それでは、APIにレート制限を設定する方法を3種類ご紹介します。

1. リクエストキュー

APIアクセスを制限するシンプルで実用的な方法の1つは、リクエストキューを活用するもの。リクエストキューとは、入ってきたリクエストをキュー（日本語で「待ち行列」とも）に格納し、一定の上限まで処理していく仕組みです。

リクエストキューの一般的な使用例としては、無料ユーザーと有料ユーザーからのリクエストの区別。今回は例として、express-queueパッケージを使って、Expressアプリで実行する方法を見ていきます。

const express = require('express')
const expressQueue = require('express-queue');

const app = express()

const freeRequestsQueue = expressQueue({
    activeLimit: 1, // 一度に処理できる最大リクエスト数
    queuedLimit: -1 // キューで許可される最大リクエスト数（-1は無制限を意味する）
});

const paidRequestsQueue = expressQueue({
    activeLimit: 5, // 一度に処理できる最大リクエスト数
    queuedLimit: -1 // キューで許可される最大リクエスト数（-1は無制限を意味する）
});

// リクエストに含まれるAPIトークンの存在に基づいて、適切なキューハンドラを選択するミドルウェア
function queueHandlerMiddleware(req, res, next) {
    // リクエストにAPIトークンが含まれているか確認
    const apiToken = req.headers['api-token'];

    if (apiToken && isValidToken(apiToken)) {
        console.log("Paid request received")
        paidRequestsQueue(req, res, next);
    } else {
        console.log("Free request received")
        freeRequestsQueue(req, res, next);
     }
}

// カスタムミドルウェア関数をルートに追加
app.get('/route', queueHandlerMiddleware, (req, res) => {
    res.status(200).json({ message: "Processed!" })
});

// APIトークンが有効かどうかを確認
const isValidToken = () => {
    return true;
}

app.listen(3000);

2. スロットリング

スロットリングは、APIへのアクセスを制御するために使われる技術です。しきい値に達した後、アクセスを遮断するのではなく、短い時間範囲で小さなしきい値を設定することで、APIトラフィックのスパイクを均等にすることに重点を置いています。月間300万コールというようなレート制限とは異なり、スロットリングは毎秒10件という制限を設定します。クライアントが1秒間に10回以上のコールを送信すると、同じ1秒間の11回目以降のリクエストは、自動的にスロットルされますが、次の1秒で即座にAPIにアクセスすることができます。

スロットリングは、express-throttleパッケージを使ってExpressに実装することができます。以下がその例です。

const express = require('express')
const throttle = require('express-throttle')

const app = express()

const throttleOptions = {
    "rate": "10/s",
    "burst": 5,
    "on_allowed": function (req, res, next, bucket) {
        res.set("X-Rate-Limit-Limit", 10);
        res.set("X-Rate-Limit-Remaining", bucket.tokens);
        next()
    },
    "on_throttled": function (req, res, next, bucket) {
        // クライアントに通知
        res.set("X-Rate-Limit-Limit", 10);
        res.set("X-Rate-Limit-Remaining", 0);
        res.status(503).send("System overloaded, try again after a few seconds.");
    }
}

// カスタムミドルウェア関数をルートに追加
app.get('/route', throttle(throttleOptions), (req, res) => {
    res.status(200).json({ message: "Processed!" })
});

app.listen(3000);

AutoCannonのような負荷テストツールを使って、アプリをテストすることができます。AutoCannonをインストールするには、ターミナルで以下のコマンドを実行してください。

npm install autocannon -g

以下のコマンドでアプリをテストします。

autocannon http://localhost:3000/route

このテストでは、APIにリクエストを送信する10件の同時接続を使用してテストを行います。結果は以下の通り。

Running 10s test @ http://localhost:3000/route

10 connections

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬───────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max   │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼───────┤
│ Latency │ 0 ms │ 0 ms │ 1 ms  │ 1 ms │ 0.04 ms │ 0.24 ms │ 17 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴───────┘
┌───────────┬─────────┬─────────┬────────┬─────────┬────────┬─────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%    │ 97.5%   │ Avg    │ Stdev   │ Min     │
├───────────┼─────────┼─────────┼────────┼─────────┼────────┼─────────┼─────────┤
│ Req/Sec   │ 16591   │ 16591   │ 19695  │ 19903   │ 19144  │ 1044.15 │ 16587   │
├───────────┼─────────┼─────────┼────────┼─────────┼────────┼─────────┼─────────┤
│ Bytes/Sec │ 5.73 MB │ 5.73 MB │ 6.8 MB │ 6.86 MB │ 6.6 MB │ 360 kB  │ 5.72 MB │
└───────────┴─────────┴─────────┴────────┴─────────┴────────┴─────────┴─────────┘

Req/Bytes counts sampled once per second.
# of samples: 11
114 2xx responses, 210455 non 2xx responses
211k requests in 11.01s, 72.6 MB read

1秒間に10件のリクエスト（＋5件のバースト処理）しか許可されないため、APIによって正常に処理されたリクエストは114件のみ。残りのリクエストは503エラーコードが返され、しばらく待つように要求されます。

3. レート制限のアルゴリズム

レート制限は、キューを使って設定できる一見するとシンプルな概念ですが、実際には、さまざまな方法で適用でき、それぞれにメリットがあります。以下、レート制限を設定するために使用される主なアルゴリズムをご紹介します。

固定ウィンドウ

固定ウィンドウは、最もシンプルなレート制限アルゴリズムの1つ。一定の時間間隔で処理できるリクエストの数を制限します。

例えば、1時間にAPIサーバーが処理できるリクエスト数を100とします。101番目のリクエストを受信すると、アルゴリズムがその処理を拒否します。時間間隔がリセットされる（次の時間枠に移る）と、また100件のリクエストの処理が可能になります。

このアルゴリズムは実装が簡単で、（ユーザー間で帯域幅を分配するのとは対照的に）帯域幅を制御するためにサーバー側でのレート制限が必要な場合に適しています。ただし、固定時間間隔の端に向かうにつれて、トラフィックや処理が急増する可能性があるため、注意が必要です。均等な処理が必要になる場合は、次にご紹介するスライディングウィンドウをおすすめします。

スライディングウィンドウ

スライディングウィンドウは、異なるタイプの固定ウィンドウで、あらかじめ定義された時間間隔を使用するのではなく、処理されたリクエストと受信するリクエストを追跡するために、時間をずらしていきます。

0秒から60秒、61秒から120秒といった絶対的な時間間隔（例えば60秒ずつ）を見る代わりに、リクエストが受信された時点から直前の60秒を参照します。例えば、リクエストを82秒目に受信したとします。アルゴリズムは、このリクエストの処理が可能かどうかを判断するために、絶対的な間隔である60秒から120秒ではなく、「22秒から82秒」の間に処理されたリクエストの数をカウントします。これによって、59秒目と61秒目で大量のリクエストが処理され、ある特定の時点でサーバーに過負荷がかかってしまうような状況を回避することができます。

このアルゴリズムは、バーストトラフィックを容易に処理するのに有用ですが、固定ウィンドウと比較して、設定と保守管理がより複雑になる可能性があります。

トークンバケット

トークンバケットは、架空の「バケット（バケツ）」がトークンで満たされ、サーバーがリクエストを処理するたびに、トークンがバケットから取り出される、というような仕組みです。バケットが空になると、サーバーはそれ以上リクエストを処理できなくなります。それ以上のリクエストは、またバケットが満たされるまで待機させられるか、拒否されます。

トークンバケットは一定の割合で補充され（トークン補充レート）、格納できるトークンの最大数（バケット深度）は決まっています。

トークンを補充する速度とバケットの深さを制御することで、APIが許容するトラフィックフローの最大速度を管理することができます。上で見たexpress-throttleパッケージは、トークンバケットのアルゴリズムを使って、APIのトラフィックフローを制限しています。

このアルゴリズムの最大のメリットは、バケット深度に収まる限り、バーストトラフィックをサポートすることができる点です。予測不可能なトラフィックに対しては特に便利になります。

リーキーバケット

リーキーバケットは、トークンバケットのように時間枠の中で処理できるリクエストの数を単純なバケット深度で制御する代わりに、（バケットから溢れて一定間隔で流れ出る水のように）一定のリクエストの流入を許可することができます。

リーキーバケットにも当然深度はあり、流入するリクエストに対する制限となります。キューに格納できるリクエストには上限があり、これを上回るとリクエストは拒否されます。

トークンバケットは異なり、安定したリクエストの流入を確保することができますが、トラフィックの急増には対応できません。

APIレート制限のベストプラクティス

APIレート制限の概要、そしてその設定方法が分かったところで、実際に設定する際に押さえておきたいベストプラクティスをご紹介します。

利用者がサービスを体験できる無料版を提供する

APIレート制限の設定を検討する際、ユーザーがAPIを試すことができる無料版を必ず提供しましょう。無理に寛大なプランを用意する必要はありませんが、開発アプリで快適にAPIをテストできるのに十分なものが理想的です。

APIのレート制限は、利用者向けにAPIエンドポイントの質を維持するのに不可欠ですが、小さなスロットルのない無料版は、新規ユーザーの獲得に効果的です。

レート制限を超えた場合の処理を決める

ユーザーが設定したAPIレート制限を超過した場合、リソースを保護しつつ、より良いユーザー体験を提供するための注意点をいくつかご紹介します。

ユーザーに表示されるエラーコードとメッセージ

まずは、APIレート制限を超えたことをユーザーに通知すること。これを行うには、APIレスポンスでその旨を伝えるメッセージを作成します。なお、このレスポンスのステータスコードは「492 Too Many Requests」であることが重要です。また、以下のようにエラーに関する説明も一緒に表示するのが一般的です。

{
    "error": "Too Many Requests",
    "message": "設定されたAPIレート制限のXリクエスト/分を超過しました。数分後に再試行してください。",
    "retry_after": 60
}

このように、エラー名と説明に加えて、ユーザーがリクエストの送信を再試行できる時間（通常は秒単位）も伝えましょう。このよう説明的なレスポンスボディは、ユーザーにとって、何が間違っていたのか、期待通りのレスポンスを受け取れない理由などを理解するのに役立ちます。また、別のリクエストを送信するのに、どのくらい待てばいいかも把握できます。

制限超過後のリクエストの処理

もう1つの注意点は、設定されたAPIレート制限をユーザーが超過した後に、どのような処理を行うか。通常であれば、上で見たように「429 Too Many Requests」のエラーを返すことで、ユーザーとサーバーのやり取りを制限しますが、スロットリング処理を検討する価値もあります。

スロットリングの場合、サーバリソースへのアクセスを完全に遮断するのではなく、ある時間枠の中でユーザが送信できるリクエストの総数を減らします。これは忠告を与えながらも、リクエスト数を減らせばユーザーが操作を続行できるようにしたい状況に有効です。

キャッシュとサーキットブレーキングを考慮する

APIレート制限は、ユーザーからは好まれません。APIサービスとのやりとりや利用を制限されてしまうことを考えれば当然のことでしょう。週に一度しか更新されない天気予報データセットにアクセスしたり、稀にしか変更のないドロップダウンリストを取得したりなど、似たようなリクエストを何度も行う必要があるユーザーにとっては、特に煩わしいものです。このような場合には、キャッシュを利用するのが賢い判断です。

キャッシュは、データアクセス量は多いものの、あまり頻繁に変更が行われない場合に便利です。複数の内部サービスを呼び出すようなAPIコールを行う代わりに、最も頻繁に使用されるエンドポイントをキャッシュすることで、2回目以降のリクエストでは静的キャッシュから配信されるようになります。

あるいは、特定のユーザーからのリクエストが異常に多いというケースも。レート制限を設定しても、常に上限に達しているような状況は、APIが悪用される可能性があることを示唆しています。

サービスを過負荷から保護し、すべてのユーザーに同等のユーザー体験を提供し続けるには、疑わしいユーザーの利用を完全に制限してしまう手もあります。この手法は、サーキットブレーカーと呼ばれ、レート制限に似ていますが、システムがリクエストの過負荷に直面し、サービスの質を回復するために速度を落とす時間が必要になる場合に使用されます。

設定をよく監視する

APIレート制限には、ユーザー間でリソースを公平に分配する目的がありますが、時にユーザーに不必要な問題を引き起こしたり、不審な動きが見られることもあります。

堅牢な監視ツールを使用すれば、ユーザーによるレート制限の超過頻度や、平均的な負荷を念頭に置きながら、一般的な制限を再検討すべきかどうかを判断し、頻繁に制限を超えるユーザーを監視することができます（状況によっては、すぐに制限を増やす、または不審な行動を監視する必要があることを示している可能性も）。いずれにせよ、定期的な監視を行うことは、APIレート制限の効果をより良く理解することができます。

複数のレイヤーでレート制限を実装する

レート制限は、複数のレベル（ユーザー、アプリケーション、システム）に導入可能です。このいずれかを選んでレート制限を設定すればいいと思っている人は多いのですが、これは間違いです。場合によっては、全く効果を発揮しないこともあります。

受け取ったリクエストがシステムのネットワークインターフェースに過負荷をかけた場合は、アプリケーションレベルのレート制限では負荷を最適化することすらできません。ボトルネックが発生しないよう、できればアーキテクチャの最上層で複数のレベルにレート制限を設けるのがベストです。

APIレート制限の使用事例

続いて、指定されたAPIエンドポイントのAPIレート制限をテストする方法と、リモートAPIの制限を超えないよう、クライアント側で使用量を制限する方法を見ていきます。

APIレート制限のテスト

APIのレート制限の確認には、まず常にAPIドキュメントに目を通し、制限が明確に定義されているかどうかを確かめることが重要です。APIドキュメントには、制限とその設定方法が記載されていることがほとんどです。APIレート制限を確認するテストは、APIドキュメントやサポート、コミュニティなどでそのような情報が見つからない場合に限ります。というのも、APIをテストしてレート制限を特定するには、少なくとも一度はレート制限を超えなければいけないためです。

手作業でレート制限を確認するには、まずPostmanのようなシンプルなAPIテストツールを用いて、APIにリクエストを送り、レート制限に達することができるかどうかを調べましょう。上限に達しない場合は、AutocannonやGatlingのような負荷テストツールを使用し、429ステータスコードが返ってくるまで大量のリクエストを再現して、APIが処理できるリクエスト数を測定します。

別の方法として、AppBrokersのrate-limit-test-toolのようなレート制限チェッカーを使用することもできます。このような専門ツールは、プロセスを自動化し、テスト結果を詳細に分析するためのユーザーインターフェースを提供しています。

APIのレート制限が不明な場合は、常にリクエスト要件を推測して、アプリからのリクエスト数がその数を超えないように、クライアント側で制限を設定してみることもできます。これは次のセクションで詳しくご説明します。

APIコールを制限する方法

コードからAPIを呼び出す場合、誤って呼び出し過ぎてしまい、レート制限に達することのないよう、クライアント側でスロットルを設定したいということも。これにはいくつか方法があり、最も一般的なのは、lodashユーティリティライブラリのthrottleメソッドを使用する手法です。

APIコールの制限を設定する前に、APIを作成します。以下はNode.jsベースのAPIで、1分あたりに受け取るリクエストの平均数をコンソールに表示する例です。

const express = require('express');
const app = express();

// 総リクエスト数を管理
let requestTotalCount = 0;
let startTime = Date.now();

// リクエストを受信するたびにカウントを増やす
app.use((req, res, next) => {
    requestTotalCount++;
    next();
});

// サーバーが起動してから1秒あたりに受け取ったリクエストの平均数を各秒ごとに表示
setInterval(() => {
    const elapsedTime = (Date.now() - startTime) / 1000;
    const averageRequestsPerSecond = requestTotalCount / elapsedTime;
    console.log(`Average requests per second: ${averageRequestsPerSecond.toFixed(2)}`);
}, 1000);

app.get('/', (req, res) => {
    res.send('Hello World!');
});

app.listen(3000, () => {
    console.log('Server listening on port 3000!');
});

このアプリが実行されると、毎秒の平均リクエスト数が表示されます。

Average requests per second: 0
Average requests per second: 0
Average requests per second: 0

次に、「test-throttle.js」という名前のJavaScriptファイルを作成し、以下のコードを貼り付けて保存します。

// function that calls the API and prints the response
const request = () => {
    fetch('http://localhost:3000')
    .then(r => r.text())
    .then(r => console.log(r))
}

// Loop to call the request function once every 100 ms, i.e., 10 times per second
setInterval(request, 100)

このスクリプトを実行すると、サーバーへの平均リクエスト数が10件近くまで跳ね上がることがわかります。

Average requests per second: 9.87
Average requests per second: 9.87
Average requests per second: 9.88

例えば、このAPIが1秒間に6件のリクエストしか許可しないなら、平均リクエスト数はそれ以下に抑えたいもの。ところが、クライアントがボタンのクリックやスクロールのようなユーザーアクティビティに基づいてリクエストを送信する場合は、APIコールがトリガーされる回数を制限できない可能性があります。

そんなときに役立つのが、lodashのthrottle()関数です。まずは、以下のコマンドを実行してライブラリをインストールしましょう。

npm install lodash

次に、test-throttle.jsファイルを更新して、以下のコードを貼り付けます。

//　lodashライブラリをインポート
const { throttle } = require('lodash');

// APIを呼び出し、レスポンスを表示する関数
const request = () => {
    fetch('http://localhost:3000')
    .then(r => r.text())
    .then(r => console.log(r))
}

// 200ミリ秒に1回、つまり1秒に5回だけ呼び出されるスロットル関数を作成
const throttledRequest = throttle(request, 200)

// 100ミリ秒に1回、つまり毎秒10回、このスロットル関数が呼び出されるようにループ
setInterval(throttledRequest, 100)

サーバーのログを見ると、同じような出力があります。

Average requests per second: 4.74
Average requests per second: 4.80
Average requests per second: 4.83

つまり、アプリが毎秒10回request関数を呼び出しても、スロットル関数によって毎秒5回しか呼び出されないようになり、レート制限を上回らないようにすることができます。このように、APIのレート制限を超えないように、クライアント側でスロットルを設定することも可能です。

よくあるAPIレート制限エラー

APIにレート制限を設定していると、レート制限を超過したことを示すさまざまなエラーレスポンスに遭遇することがあります。大抵の場合は、429ステータスコードを受け取り、以下のようなメッセージが表示されます。

• Calls to this API have exceeded the rate limit（API呼び出しの回数制限を超えました）
• API rate limit exceeded（APIのレート制限を超過しました）
• 429 Too Many Requests（リクエストが多過ぎます）

エラーメッセージはAPIによって異なり、APIによっては429ステータスコードを使用していない場合もあります。レート制限を導入しているAPIで表示されるその他のエラーコードとメッセージには、以下のようなものがあります。

• 「403 Forbidden」または「401 Unauthorized」：APIによっては、リクエストを不正なものと認識し、リソースへのアクセスを拒否する場合があります。
• 「503 Service Unavailable」または「500 Internal Server Error」：大量のリクエストで過負荷になった場合、サーバーが健全でないことを示す500番台エラーが返されることがあります。これは通常一時的なもので、サービスプロバイダーによって適切なタイミングで修正されます。

代表的なAPIサービスのレート制限

最後に、代表的なAPIサービスのレート制限を見てみましょう。

• Discord：1秒あたり50件のリクエストというグローバルレート制限、ルートごとのレート制限の2種類を導入（詳しくはこちら）。制限を超えると、429ステータスコードとretry_after値が返される。
• Twitter：ルートベースのレート制限（詳細はこちら）。制限を超えると、x-rate-limit-resetヘッダー値と429ステータスコードが返され、アクセスを再開できる時間を確認できる。
• Reddit：公式のアーカイブAPI wikiによれば、Reddit APIにアクセスする際のレート制限は、毎分60件（OAuth2経由のみ）。各APIコールに対し、X-Ratelimit-Used、X-Ratelimit-Remaining、X-Ratelimit-Resetヘッダー値を返す。このヘッダーでは、制限値といつ解除されるかを確認できる。
• Facebook：ルートベースのレート制限が設定されている。例えば、Facebookベースのアプリからの呼び出しは、1時間あたり、200×（アプリのユーザー数）に制限される（詳細はこちら）。Facebook APIからは、X-App-UsageまたはX-Ad-Account-Usageヘッダーが返され、いつ制限がかかるかを把握できる。

まとめ

APIを構築するにあたって、適切なトラフィック制御の確保は非常に重要です。トラフィックの管理を怠れば、すぐに過負荷状態に陥り、正常に機能しなくなってしまいます。逆にレート制限のあるAPIを扱う場合は、レート制限の仕組みを理解し、最大限の可用性と利用率を確保できるAPIの使用方法を理解することが大切です。

今回の記事では、APIのレート制限の概要と必要性、設定方法、そしてレート制限を設定する際のベストプラクティスを詳しくご紹介しました。

Kinstaのアプリケーションホスティングなら、Node.jsプロジェクトを容易に立ち上げることができます。ぜひ一度お試しください。

レート制限が設定されたAPIを使用していますか？または自社のAPIにレート制限を導入していますか？以下のコメント欄でぜひご意見をお聞かせください。