Contents
色々解り難いAPI Gateway
仕事でAPI Gatewayを使ってシステム構築することになりました。
API GatewayっていうとCDKのWorkShopで扱っている題材で、簡単なんじゃないの？って考えていたんですけど…いざやってみるとそーでもない！というか解り難いです！でした！
延々とAWSのドキュメントや、色々な方のサイトを読んでやっとつかめてきた感じです。
その辺の理解できたことを、忘れんように書いておこうと思います。
まずは、最初に目指すアーキテクト図
今回扱うのはAPI GatewayのうちREST APIになります。HTTPとかWebSocketは扱わないです。
で…最初に構築するアーキテクト図が以下になります。
これを完成させてからカスタム認証や、カスタムＵＲＬなんかもやってみたいと思います。
ただ、今回の回ではAPI Gatewayの理解しにくい用語の説明に終始すると思います。
最初に大枠から
まずは、大枠を押さえないと、まぁ全然何をしたら良いのかが浮かびませんでしたね…
と言うことで…概要書いてある以下の公式サイトを読みました。
公式サイト：API Gateway REST API
今回話すことは、このサイトを上から順に読んで行って理解できた部分です。（正しい理解かはわからないですけど…）
その他、色々な方のサイトも読みましたが、参考になりそうなところは随時リンク張らせてもらいます。
それで、大枠として押さえておいた方が良いと思った概念が以下になります。
押さえる順番的なところも以下の順で行くと良いかと感じます。
・APIエンドポイントタイプ
・API Gateway
・メソッドリクエスト／統合リクエスト
・統合エンドポイント
・メソッドレスポンス／統合レスポンス
・リソース
・デプロイ
・ステージ
概念を理解するのには、以下のサイトが良かったと思います。
イラストで理解するAPI Gateway
API エンドポイントタイプ
API Gatewayを何処に配置するのかを決めましょうというお話です。
API エンドポイントタイプは、以下３種類です。
・エッジ最適化 API エンドポイント
・リージョン API エンドポイント
・プライベート API エンドポイント
公式サイト：API Gateway での REST API の API エンドポイントタイプ
エッジ最適化 API エンドポイント
公式の説明を読んでると外部アクセスはこれを使わないいけないように感じますが、全世界的に公開するようなケースの場合、このエンドポイントを使うと良いかと思います。
このエンドポイントは、API Gateway＋CloudFrontを使って、アクセスポイントが近いところからサービス提供するような仕組みを提供してくれます。
面倒に感じるのは、API Gatewayを構築する際にCloudFrontのエンドポイントも作るのでその権限とかを付ける必要があるところですね。ただ、今回はこのエンドポイントは使わないです。
リージョン API エンドポイント
同じリージョン内のクライアントを対象としています。
と言うのが公式サイトでのこのエンドポイントに対して書いてある最初の説明です。
最初に読んだときに、リージョン内からしかアクセスできなくて、外部からのアクセスができないのかな？と感じましたが！そんなことはないようで、日本国内だけのサービスなんかのケースだとこのエンドポイントタイプで良いみたいです。今回はこのエンドポイントタイプを使います。
プライベート API エンドポイント
読んで字のごとく、プライベートなエンドポイントなので、外部アクセスの無いプライベートな環境下で使うエンドポイントです。
こういうプライベートな環境に提供するサービス系は、実際にはAPI Gatewayがプライベートな環境下に作られるんじゃなくて、API GatewayはAWSが用意するどこかの環境にいて、そのAPI Gatewayとプライベートな環境で接続できるようにVPCエンドポイントで繋いで、あたかもプライベートな環境で動いてる感じに見えるっていうものだと思います。
なので、VPCエンドポイント作って繋いだりする手間が掛かります。今回は外部アクセスできる環境作りたいので、こちらも使わないです。
API Gateway
API Gatewayの本体のお話です。以下３種類あります。
・REST API
・HTTP API
・WebSocket API
今回扱うのは一般的なREST APIです。
HTTPとRESTの違いってなんなの？って思いましたけど、大きな違いってないようで、HTTPの方が機能的に制限されているもので安い！と言う事らしいです。
HTTPを使うつもりなくてあまり詳しく調べてないので、以下の公式サイトを見て頂けたら良いんじゃないかと思います。
公式サイト：REST API と HTTP API のどちらかを選択する
WebSocket APIは、相互通信が必要な場合に使うサービスのようです。こちらも詳しく調べてないので、公式サイトの方を参考して下さい。
公式サイト：API Gateway WebSocket API
RESTとは？って良く思いますけど、プロトコルじゃないんですよねきっと。私の理解だと、ルール的なものだと思っています。なのでプロトコルとしては、HTTPを使って中身のデータがRESTのルールになっているみたいな、REST over HTTPみたいな事なんでしょうかね…
あまり、不正確なこと書くと怒られちゃうんで、この辺にしておきます。
少しCDKの話をしておきます。
このREST APIを作るCDKのL1 Constructは、「CfnRestApi」です。
このConstructを使ってAPI Gatewayを作ることは簡単にできるのですが、API Gatewayを作っただけでは動かないってところが厄介で、動かすのに必要なその他のリソース達を作ってあげないとダメってことになります。
最初作ってみよう！って思ったときに、この周りの関係とか、考え方が紐づかなくて「何したらいいだろう～」となったので、この辺整理しないとね！って思いました！
メソッドリクエスト／統合リクエスト／統合エンドポイント／メソッドレスポンス／統合レスポンス
メソッドリクエスト～統合レスポンスまで、この辺はまとめて理解した方がいいかなと思い一気に書いちゃいます。↓概要がここに書いてあります。
公式サイト：API Gateway で REST API を開発する
以下のような図が書いてあってこれが概要のすべてかな・・・と感じます。
Clientから要求がきて、それをどうやってバックエンド（統合Endpointって書いてあるところ）に伝えるか？っていうことを説明している図です。（もちろん、レスポンス返すところも説明しています。）
上記は、統合EndpointにLambda非プロキシ統合を使う場合の図になります。
統合Endpointに関しては、公式サイトでも「Lambda非プロキシ統合」と「Lambdaプロキシ統合」いう言葉がここで出てきます。
統合Endpointについて、ここで以下の2種類の新しい概念を理解しておく必要があります。
・Lambdaプロキシ統合
・Lambda非プロキシ統合
公式サイト：AWS Lambda 統合を選択するチュートリアル
最後にひと言余計なことを言っておきたいのは「統合」っていう言葉ですね。
英語だと「integration」て言葉で、一般的にこのように訳されるみたいですけど、何かこれが私的には、受け入れ難いという気がします…これは、翻訳あってるんですかね…
(´・ω・)なれるしかないね…
Lambdaプロキシ統合
プロキシ統合は、Clientからのリクエストの全てのデータをそのまま、統合Endpointに渡すパターンです。なので、上の図の「統合リクエスト」と「統合レスポンス」の部分が不要になります。
Lambdaプロキシ統合で、実装する場合の図は以下になります。
Lambda非プロキシ統合
プロキシ非統合は、統合リクエストと統合レスポンスを定義する必要があります。
統合リクエストは、リクエストのパラメータを、Lambdaに渡すeventデータにマッピングして、統合レスポンスはLambda関数の返却パラメータをレスポンスのパラメータにマッピングする必要があります。
どちらにすべき？
どちらでも良いんでしょうけど、実装しやすそうなのは、プロキシ統合の方だと思います。
AWSさんは何故、非プロキシ統合という方法を提供しているのか？ちょっとメリットが思い浮かばないんですけど…とは感じました。
まぁ何かニーズがあったんでしょうね…
リソース
これより上の部分で話したことで、構成の方式みたいのが決定します。後は、それぞれのリソースを紐づけて行くために必要なものになります。
ここで出てくる「リソース」という言葉は、一般的にいうAWSのリソースという言葉と混同してしまって理解がしにくいですよね…なんで、「リソース」っていう表現にしたんですかね…
CDKのL1のConstructは「CfnResource」とメソッドについも関連付けるのに「CfnMethod」を使います。(‘ω’)ノあとで使うよ！
リソースの部分で表現しているのは「APIのパス定義」のように見えます。
example.comとうURLで例えると以下のイメージです。
ユーザー登録のAPI：Method:POST URL:https://example.com/v2/user上記の「/v2/user」って部分の定義をするのがリソースの定義です。でPOSTとか、GETと関連図けるのが、メソッドの定義になりまね。
最初の構成図の以下の部分になりますね。
次回で構築する作るAPI Gatewayだと、Method:POST API:/v2/first/catとMethod:GET API:/v2/first/dogの２つになります。
デプロイ
デプロイ？ん？この部分は実は、全く理解できてないな？！ってこれ書くとき思いました。
公式サイトで書いてるところでは、「ユーザーが使えるようにする」、「ステージと関連付ける」というキーワード出てきますね。
「API Gateway」本体と、「ステージ」を関連付けるのに「デプロイ」というリソースが必要と言う感じに見えました。
あとで、CDKで構築するときに感じますけど、「ステージ」の方には、「API Gateway」のIDも、「デプロイ」のIDもどちらも指定するので、なんで「デプロイ」というリソースが必要なんだろう？って感じました。結局この部分は、良く理解できないまま来てしまましたが、まぁ必要ってことなんんでそうなんでしょうね…
公式サイト：API Gateway で REST API をデプロイする
CDKのL1のConstructは「CfnDeployment」です。
デプロイについては、あまり話すことがないのでこの辺で次のステージの方に行きましょう。
ステージ
「ステージ」は実際に、サービスを提供をコントロールするためのリソースになります。
この「ステージ」もちょっと理解しにくい…。
開発環境って大体、本番環境（良くprod環境って言う）、テスト環境（良くtest環境って言う）、開発環境（良くdev環境って言う）に分かれている場合多いと思います。
これを表現しているのが、「ステージ」というリソースみたいです。
また、本番リリースの時に、ちょっとだけアップデートしたサービスを動かして試しましょう見たいな時に行う Canaryリリースをする場合に使えるようですね。
本番のトラヒックの何パーセントをニューリリースのAPIに置き換える。問題があったらリリースを中止する。みたいなときに使われるようです。
「ステージ」には、まだまだ、関連付けるリソースがあって、例えばロググループとか、WAFなんかもこのリソースに紐づけて、サービス提供するようです。
「ステージ」には名前付けるんですけどこれが、URLに含まれるみたいです。
この部分は、サービス提供するときにちょっと考える必要がありますよね。
「カスタムURL」でサービス固有のURLつけるときなんかどうなるんだろうとか？とかその辺気になりますね。
と言うことで、ゴチャゴチャ色々書きましたけど、「ステージ」というリソースを作ることでサービスが最終的に提供されるというところを理解しとくのが大切なのかと思います。
最後に、CDKのL1のConstructは「CfnStage」です。
と言うことで…
これでこの回で説明することは終わったので、次の構築に進みましょう～
次回は「いちはじCDK第９回 API GateWay②」です～
コメント