API Gateway設計 — REST・HTTP・WebSocket APIの違い
API種別ごとの機能差、スロットリングとキャッシュ、プライベートAPI(VPCエンドポイント経由)の設計を解説します。
サーバーレスアーキテクチャの玄関口となるのがAmazon API Gatewayです。 3つのAPIタイプがあり、それぞれ機能とコストが異なります。
SAA レベル:基礎概念
3種類のAPIタイプ
| タイプ | 用途 | 特徴 |
|---|---|---|
| REST API | 高機能なAPI管理が必要な場合 | リクエスト検証、APIキー管理、キャッシュなど機能が豊富 |
| HTTP API | シンプルなプロキシ用途 | REST APIよりも低レイテンシ・低コスト、機能はやや限定的 |
| WebSocket API | 双方向のリアルタイム通信 | チャットアプリ、リアルタイム通知等 |
SAA 試験のポイント
機能要件がシンプルなLambdaプロキシ統合だけで十分な場合、HTTP APIの方がコストと性能の両面で有利です。REST APIの豊富な機能(使用量プラン、リクエストバリデーション等)が必要な場合にのみREST APIを選択する、という判断がSAAで問われます。
スロットリングの基本
- API Gatewayにはアカウント全体・APIステージ単位でリクエストレート制限(バースト・定常レート)が設定できる
- バックエンド(Lambda等)を過負荷から保護する役割を果たす
SAP レベル:高度な設計シナリオ
使用量プランとAPIキーによる顧客別レート制御
SAP 試験のポイント
複数の外部顧客にAPIを提供するB2B SaaSのシナリオでは、使用量プラン (Usage Plan) とAPIキーを組み合わせ、顧客ごとに異なるスロットリング上限とクォータ(1日あたりのリクエスト数上限等)を設定できます。これはREST APIのみでサポートされる機能であり、HTTP APIでは実現できない点がSAPの選定基準として問われます。
キャッシュによるバックエンド保護
- REST APIではAPI Gateway自体にキャッシュを設定でき、頻繁に参照される(かつ更新頻度の低い)エンドポイントの応答をキャッシュしてバックエンドの呼び出し回数を削減できる
- キャッシュのTTLとキャッシュキー(クエリパラメータ、ヘッダー等)の設計次第で、キャッシュヒット率が大きく変わる
プライベートAPI(VPCエンドポイント経由)
SAP 試験のポイント
社内向けAPIをインターネットに公開せず、VPC内からのみアクセス可能にしたい場合、API GatewayをプライベートAPIとして構成し、VPCエンドポイント(インターフェース型)経由でのみアクセスさせる設計が使われます。リソースポリシーで特定のVPCエンドポイントからのアクセスのみを許可することで、ネットワークレベルとポリシーレベルの二重の統制を実現できます。
設計上の落とし穴
「プライベートAPIにすればセキュリティは万全」という判断は不十分です。SAPレベルでは、プライベートAPI自体はネットワークレベルの到達性を制限するだけであり、認証・認可(IAM認証、Lambda Authorizer、Cognito Authorizer等)は別途アプリケーションレベルで実装する必要がある、という多層防御の考え方が問われます。
WebSocket APIによるリアルタイム双方向通信
- 接続の確立・切断・メッセージ送受信をそれぞれ異なるルートとして定義し、Lambdaと連携させる
- 接続管理には接続IDをDynamoDBに保存し、サーバー側から特定のクライアントへプッシュ通知する際に利用する、という設計パターンが定番
まとめ
- SAA: REST/HTTP/WebSocket APIの用途の違い、シンプルな用途にはHTTP APIが有利であることを理解する。
- SAP: 使用量プランによる顧客別レート制御(REST API限定機能)、プライベートAPIの設計と多層防御の必要性を踏まえた判断ができる。
次は **マイクロサービス間通信パターン(Saga、Choreography vs Orchestration)**を見ていきましょう。