こんにちは！新人エンジニアの皆さん、日々の開発やインフラの勉強、本当にお疲れ様です。
セキュリティの世界って、なんだか難解な専門用語ばかり飛び交っていて、「どこから手をつければいいんだろう…」と不安になりますよね。でも、安心してください。どんなにすごいサイバー攻撃の防御も、基本は私たちが普段やっている「身の回りの防犯」とまったく同じなんです。
今回は、APIを守るための「レート制限（スロットリング）とDDoS対策」について、身近な例えを交えながら、一歩ずつ優しく紐解いていきましょう！
—
1. なぜAPIを守る必要があるの？（身近な例えで考える）
皆さんのWebサービスやスマホアプリは、裏側で「API」という仕組みを使ってデータをやり取りしています。例えば、お天気アプリがサーバーに「今日の天気は？」と聞いて、答えをもらうようなイメージですね。
ここで、こんなシチュエーションを想像してみてください。
あなたが人気ラーメン店の店主だとします。カウンター席が10席しかない小さなお店です。そこへ、ある一人の客（あるいはロボット）がやってきて、こう叫びました。
「おい！私に1秒間に1万杯のラーメンを作れ！！それが無理なら、ずっとカウンターを占領してやる！」
…こんなことされたら、他のお客さんは一切ラーメンを食べられなくなっちゃいますよね。そして、あなたのお店（サーバー）は、あまりの注文の嵐に耐えきれず、プツンと電源が落ちて（ダウンして）しまいます。
これが、APIを狙ったDDoS攻撃（分散型サービス拒否攻撃）や、悪意ある過剰アクセスの正体です。攻撃者は、正当なユーザーのフリをして、あるいは大量のボットを使って、サーバーをパンクさせようと狙ってくるんです。
—
2. 「レート制限」と「クォータ管理」で暴走を防ぐ
じゃあ、この迷惑なお客さんからお店を守るにはどうすればいいでしょうか？
そう、「ルールを作る」んです。
- 「1人のお客さんが注文できるのは、1分間にせいぜい10杯まで！」（これがレート制限 / スロットリングです）
- 「1日全体でも、合計100杯までね！」（これがクォータ管理です）
API Gateway（APIの玄関口）は、まさにこの「受付の用心棒」の役割をしてくれます。怪しいやつが来たら、「ちょっとペースが速すぎます！少し落ち着いてください！」と門前払い（HTTPステータスコード 429 Too Many Requests を返す）してくれるのです。
—
3. 防御の要！レスポンスヘッダーの意味を知ろう
API Gatewayが制限をかけたとき、実はクライアント（アプリ側）に対して「今どういう状態なのか」をこっそり教えてあげる親切な目印（HTTPヘッダー）があります。
実務でよく見かける代表的な3つのヘッダーを見てみましょう。難しく考えず、「遊園地のアトラクションの待ち時間表示」みたいなものだと思ってください。
X-RateLimit-Limit: 「この時間内に許可されている最大のリクエスト数」（例: 100回）X-RateLimit-Remaining: 「あと何回リクエストできるか」（例: あと3回！）X-RateLimit-Reset: 「あと何秒待てば制限がリセットされるか」（例: あと45秒でゼロから復活！）
フロントエンドを開発するエンジニアさんは、これらのヘッダーを読み取って、「おっと、あと少しで制限に引っかかるから、少し処理をゆっくりにしよう」といった優しい制御（クライアント側のスロットリング）を実装することが大切になります。
—
4. 実践！API Gatewayでの設定イメージ
言葉だけだとイメージしにくいと思うので、AWS API GatewayやNginxなどのリバースプロキシでよく使われる、レート制限の設定の雰囲気を見てみましょう。
以下の設定例は、「1秒間に最大5回までリクエストを許可し、急なバースト（一時的な集中）は10回まで許容する」というバケットアルゴリズム（漏れバケツの原理）に基づいた設定のイメージです。
{
"api_name": "user-profile-api",
"throttling_settings": {
"rate_limit": 5.0, // 1秒間に許可する平均リクエスト数
"burst_limit": 10 // 瞬間的に耐えられる最大のリクエスト数（バースト許容量）
},
"quota_settings": {
"limit": 10000, // 1日（または1ヶ月）あたりの総リクエスト上限
"period": "DAY" // 期間の単位（DAY または MONTH）
}
}このように、玄関口であるAPI Gatewayに「ここまでしか通しちゃダメだよ」とルールをあらかじめ仕込んでおくことで、万が一バックエンドのデータベースやマイクロサービスに負荷がかかりそうな攻撃が来ても、玄関の段階で綺麗にブロックできるのです。
—
5. まとめ：一歩ずつ、確実な防犯を
いかがでしたでしょうか？
「API Gatewayにおけるレート制限とDDoS対策」と聞くと、なんだか冷徹で複雑なサイバー空間の技術のように感じますが、本質は「お店のキャパシティを守るための入場制限」です。
1. APIの玄関口（API Gateway）でしっかり門番を置くこと。
2. レート制限（1秒あたりの回数）とクォータ（期間あたりの総量）を適切に設定すること。
3. エラーが起きたときは 429 や専用のヘッダーで優しく状況を伝えること。
これらを意識するだけで、あなたの作るAPIの安全性はぐっと高まります。セキュリティは一日にして成らず。まずは身近な例えを思い出しながら、自分のプロジェクトの玄関口を見直すことから始めてみましょう！
コメント