[レポート] あなたの知らないAmazon API Gateway #SVS212 #reinvent

2019.12.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは!DA事業本部の大高です!無事、ラスベガスから日本に帰国しました。

本記事はAWS re:Invent 2019のセッションレポートとなります。

概要

This session is an introduction to Amazon API Gateway and the problems it is solving. We walk through the moving parts of API Gateway, giving examples of possible use cases both common and not so common. You come away with a solid understanding of why you should use API Gateway and what it can do.

このセッションは、Amazon API GatewayについてとAPI Gatewayが解決する問題の概要です。API Gatewayを順を追って説明し、一般的なものと、そうではない可能性のあるユースケースの例を示します。 API Gatewayを使用する理由と、API Gatewayで何ができるのかをしっかり理解できます。

本セッションはリピートセッションの「SVS212-R2」となります。

スピーカー

スピーカーは以下の方になります。

  • Eric Johnson - Senior Developer Advocate - Serverless, Amazon Web Services

ちなみに、Ericさんは自己紹介にもある通り、まさにgeekな感じの方で、セッション中にもジョークやメタファーを交えながらのセッションとなっており、聞いているだけでもとても面白いセッションでした。

動画

APIとは何か

Application programming interface (API)

  • APIはビジネスロジックを含まずにサービス間でコミュニケーションを許すもの
  • 同一アプリケーションでも、他アプリケーションともコミュニケーションをとる
  • リクエストがAPIと会話し、APIは背後のサービスと会話を行い、そのレスポンスを返す
    • 背後のサービスが何も返さない場合には、最初にAPI側で返却する
    • この場合には通常はAPI Gatewayを経由しない
      • ここにAPI Gatewayの真実がある

API Gateway

  • さっきの場合だと、Lambdaのプロキシとなっているだけ
    • これだけなら70%安価にできる
  • API Gatewayにはもっとできることがある

APIの存在場所のタイプ

  • エッジ最適化
    • CloudFrontにより、リクエストはクライアントに近い地域で処理される
  • リージョナル
    • 一般的なユースケースでおすすめ
  • プライベート
    • VPC内部の通信として、パブリックにしたくない場合

サポートプロトコル

  • HTTP(REST)
    • リクエスト・レスポンス型
  • Websocket
    • 双方向コミュニケーション

API Gatewayの管理

  • 構築方法、設定のベストプラクティスをよく聞かれる
    • 6つの方法がある
  • 管理コンソール
    • 全てのステップを覚えている必要がある
  • CLI
    • APIで自由に作成できる
  • SAM、AWS CloudFormation
    • APIの管理
    • 多くのAPI Gatewayのシンタックスに対する設定ができる
  • Swagger/OpenAPI
  • AWS CDK

バックエンドサービスの統合

統合タイプ

  • Lambda関数
  • HTTP
  • Mock
  • AWS Service
  • VPC Link

プロキシ経由のラムダ関数

  • リクエストはメタデータでラップされてバックエンドへ送られる
  • レスポンスは何もせずに返される

直接統合経由のラムダ関数

  • VTL(Velocity Template Language)を利用することで、リクエストの修正が可能
  • VTlを利用して、レスポンスも修正が可能

実装フロー

  • メソッドリクエスト
    • 正規表現によるマッチング検証もできる
  • リクエスト統合
  • メソッドレスポンス
  • レスポンス統合

認証

  • オープン
    • 何もしない。 「It works.」のページなど
  • IAM permissions
  • Amazon Cognito authorizer
    • 認証をCognitoに任せる
  • Lambda authorizers
    • Lambdaで検証をする
    • JWT(JSON Web Token)などを利用

キャッシング

  • ホットなデータをキャッシュして高速にレスポンスを返却できる
  • ステージかメソッドで設定

スロットリング

  • リージョン範囲で秒間1万リクエストのスロットリング
  • メソッドレベルで上書き可能
  • APIレベル、または、ステージレベルでの設定
  • メソッドレベルでの設定
  • スロットリング適用は図の順番

VPCリンク

  • VPCリンクを経由することで、API Gatewayからプライベートネットワークへのアクセスが可能
  • この例では、NLB経由でオンプレミスへのアクセスができている

ステージ

  • API Gatewayでは異なるステージを利用することが可能
  • ステージをカスタムドメインに紐づけて、それぞれ違うエンドポイントにすることが可能

  • 同一のAPIで複数のバージョンの本番環境を管理することを考える
  • 各ステージ変数を利用することで、動的にLambdaエイリアスを選択することが可能
  • 例えば、ベータバージョンのAPIが死んだ場合でも、すぐに切り替えることができる

カナリアリリース

  • カナリアリリースでは、APIの例えば20%のトラフィックを次のバージョンに割り当てる
  • しばらく様子をみて、その20%に問題がなければトラフィックを全て次のバージョンに割り当てる
  • 問題があったらトラフィックを全て元のバージョンに戻せばよい

WAF

  • API GatewayへWAFを適用
    • IP, CIDRへのブラックリストによるブロック
    • SQLインジェクションモニタリング

監視とメトリクス

  • Amazon CloudWatch
    • メトリクスの監視
  • AWS X-Ray
    • アプリケーションに何が起きているのかを知る
  • AWS CloudTrail
    • ユーザが実際に何をしているのかを知る
  • AWS Config
    • 要求する設定値になっているか確認できる

ロギング

  • CloudWatch Logs
    • カスタマイズログフォーマットでも対応可能
    • Amazon Kinesis Data Firehoseにログを出力
      • リアルタイムにログを分析

デベロッパーポータル

  • API registration & key generation
    • 顧客毎に異なるAPIキーを提供可能
  • API monitoring and usage
    • APIキー毎に利用しているAPIのモニタリング
  • SDK generation
    • 各種プラットフォーム向けのSDKを生成できる

リソースポリシー

  • VPC IDや組織で制限

クライアント認証

  • クライアントサイドSSL証明書
    • バックエンドへのアクセスがAPI Gatewayからであると検証
    • 365日有効

カスタムドメイン

  • APIに対してカスタムドメインを設定可能
  • マッピングを利用して、APIをマッピング

Swagger/OpenAPI 3 インポート&エクスポート

  • APIをコンソールからSwaggerとしてエクスポートできる
    • Swaggerは古いバージョン(OpenAPI 3のほうが新しい)
    • テンプレートとして再利用可能

まとめ

以上、「あなたの知らないAmazon API Gateway」のレポートでした。

API Gatewayはそれほど触ったことのないサービスで、今回のセッションを受けることでいままで知らなかったVTLや デベロッパーポータルの話など、色々な知識を得ることができたのは、とてもよかったです。

また、スピーカーのEricさんのトークで、会場がとても湧いていたのが印象的なセッションでした。

それでは、また!