パターン名

API Forwarding Gateway

分類

信頼性デザインパターン？

シーズナリティ性のある業種のシステムなど、ピーク時のアクセス数が読めないシステムがオンプレ環境で稼働しており、そのAPIを外部に公開する場合、あらかじめピーク時のアクセス数に耐えられるだけのリソースを用意しておくには以下のデメリットが考えられます。

セールやキャンペーン等の日程や時間が決まっているもので、あらかじめアクセス増が予測される場合においては直前にスケールアウトしておく事も考えられますが、その予測を超えた瞬間的なアクセス増には耐えられない場合もあります。また、アクセス増のタイミングが予測できないシステムにおいても同様となります。

API Gateway
ピーク時におけるAPサーバの負荷軽減を想定した際にスケールアウトとは別に、API Gatewayを使用することによってスロットリングによるトラフィックの管理やAPI呼び出しに対する出力のキャッシュを図ります。また、APIキー認証を利用し特定のアクセス元からのみに制限することにより、不正なAPIコールのブロックやマネタイズを図ります。 APIコール先のシステムが複数あり、それぞれが返してくるデータ形式が違う場合にはモデルとマッピングテンプレートを使用することによって、結果のデータ形式を例えばJSONに統一するなどといった標準化もできます。
使用する機能
- Integration ResponseでHTTP Proxyを指定
- スロットリング
- レスポンスのキャッシング
- APIキー認証
- モデルとマッピングテンプレート
  デザインパターンの内容

画像を貼ったら良いでしょうか・・？

標準時とバースト時のスロットリング設定によるスパイクアクセスへの対策
各HTTPメソッドに対する個別スロットリングによる負荷標準化
レスポンスのキャッシングによるレイテンシ減
バックエンドへのトラフィック軽減
APIキー認証を利用してリソースのアクセス制限をすることにより、許諾していないアクセス元からのAPIコールをブロック。あるいはマネタイズへの布石
モデルとマッピングテンプレートの使用により、受け取る結果のデータ形式を標準化
注意点 (デメリット)
キャッシュのTTL(GETなどの取得結果の値にリアルタイム性があるものは注意)
クライアントSDKを生成しない場合の429HTTPレスポンス対策の実装
備考

このデザインパターンの課題、発展について
VPCエンドポイントが実装されたら
- API Gatewayをハブにし、VPC内およびDirectConnectやVPNで接続している各社内システム同士の連携が可能となる(API Connection Hubパターン)