Amazon API Gateway の設計パターン - REST API と HTTP API の選定基準
HTTP API と REST API の選定基準を明確にし、Cognito・Lambda オーソライザーの認証パターンとスロットリング設計の実践手法を紹介します。
REST API と HTTP API の選定基準
API Gateway は REST API と HTTP API の 2 種類を提供しています。HTTP API は 2019 年に登場した新しいタイプで、REST API の主要機能をカバーしつつ、料金が最大 71% 安く、レイテンシも低く設計されています。Lambda 関数や HTTP エンドポイントへのプロキシが主な用途であれば HTTP API を選択すべきです。REST API を選ぶべきケースは、API キーと使用量プランによるサードパーティ向け API の公開、リクエスト/レスポンスの変換 (マッピングテンプレート)、WAF との統合、エッジ最適化エンドポイント、リクエストバリデーション機能が必要な場合です。新規プロジェクトでは HTTP API をデフォルトとし、HTTP API にない機能が必要な場合にのみ REST API を検討するアプローチを推奨します。
認証・認可パターン
API Gateway は複数の認証方式をサポートしています。Cognito ユーザープールオーソライザーは、Cognito が発行する JWT トークンを API Gateway が自動検証する方式です。トークンの検証ロジックを自前で実装する必要がなく、最も手軽に認証を導入できます。Lambda オーソライザーは、カスタムの認証ロジックを Lambda 関数で実装する方式です。独自のトークン形式、外部 IdP との連携、IP アドレスベースの制御など、柔軟な認可ロジックが必要な場合に使用します。Lambda オーソライザーの結果はキャッシュ可能で、TTL を設定することで認証リクエストの重複実行を削減できます。IAM 認証は AWS の SigV4 署名でリクエストを認証する方式で、AWS サービス間の内部通信に適しています。
スロットリングと使用量プラン
API Gateway のスロットリングはトークンバケットアルゴリズムで実装されています。アカウントレベルのデフォルト上限はリージョンあたり 10,000 リクエスト/秒で、バーストは 5,000 リクエストです。ステージレベルとメソッドレベルでより細かい制限を設定でき、特定のエンドポイントがバックエンドを過負荷にすることを防止できます。使用量プランは REST API 固有の機能で、 API キーごとに日次・月次のリクエスト上限とスロットリングレートを設定します。外部パートナーに API を公開する場合、パートナーごとに異なるレート制限を適用できます。 429 Too Many Requests レスポンスを受け取ったクライアントは、指数バックオフでリトライする実装が推奨されます。 API 設計のアーキテクチャを網羅的に学ぶなら、技術書 (Amazon)を参照してください。
API Gateway の料金
HTTP API は 100 万リクエストあたり約 1.00 ドルで、REST API の 3.50 ドルと比較して約 71% 安価です。WebSocket API は 100 万メッセージあたり約 1.00 ドルに接続時間の課金 (100 万分あたり約 0.25 ドル) が加算されます。REST API のキャッシュを有効にすると、キャッシュメモリのサイズに応じた時間課金 (0.5 GB で約 0.02 ドル/時) が発生します。Lambda オーソライザーのキャッシュ TTL を適切に設定し、認証リクエストの Lambda 呼び出し回数を削減することもコスト最適化に有効です。無料枠は最初の 12 か月間、HTTP API と REST API それぞれ 100 万リクエスト/月が含まれます。
統合タイプとバックエンド連携
API Gateway は、リクエストをさまざまなバックエンドへ橋渡しできます。Lambda 関数へそのまま渡すプロキシ統合は手軽で、最も一般的です。既存の HTTP サービスへ転送する統合や、VPC 内のプライベートなサービスへ接続する仕組みもあります。バックエンドを介さず、一部の AWS サービスを直接呼び出す統合を使えば、単純な処理では Lambda を省いてコストとレイテンシを抑えられます。公開する API の背後に何を置くか、どう接続するかを設計することで、構成をシンプルに保ちつつ、必要な機能を提供できます。要件に応じて適切な統合タイプを選びます。
リクエストとレスポンスの処理
API Gateway は、リクエストとレスポンスを加工する機能を備えています。入力の形式が正しいかを検証し、不正なリクエストをバックエンドへ届く前に弾くことで、無駄な処理と負荷を防げます。リクエストやレスポンスの構造を変換し、クライアントとバックエンドそれぞれが扱いやすい形に整えることもできます。これにより、バックエンドの仕様を変えずに、外部に公開する API の形を調整できます。入口で検証と変換を行うことで、バックエンドの実装を保護しつつ、利用者には使いやすい一貫した API を提供できます。
WebSocket によるリアルタイム通信
通常の API は、クライアントからのリクエストに応答する一方向のやり取りが基本です。一方、サーバーからクライアントへ随時データを push したい、双方向のリアルタイム通信が必要な場合は、WebSocket に対応した API を構築できます。チャット、通知、ライブの更新表示といった用途に向きます。接続の確立・切断や、メッセージの受信といったイベントごとに処理を定義し、接続中のクライアントへサーバー側から能動的にメッセージを送れます。用途に応じて、リクエスト応答型とリアルタイム型を使い分けることで、多様なアプリケーションの通信要件に対応できます。
監視・キャッシュ・運用
API の運用では、リクエスト数やエラー率、レイテンシを監視し、異常を検知できるようにします。アクセスログを記録すれば、どのような呼び出しが行われたかを追跡し、問題の調査に役立てられます。頻繁に同じ結果を返すエンドポイントには、応答をキャッシュする機能を使い、バックエンドの負荷とレイテンシを下げられます。ステージを使って開発・本番を分け、新バージョンを一部のトラフィックで試すカナリアリリースも行えます。監視・キャッシュ・段階的なリリースを組み合わせることで、安定して運用できる API を提供できます。
まとめ
API Gateway はサーバーレスアーキテクチャの入口として、認証・スロットリング・モニタリングを API レイヤーで一元管理するサービスです。HTTP API をデフォルトの選択肢とし、エンタープライズ機能が必要な場合に REST API を選択する判断基準を持つことで、コストとレイテンシを最適化できます。