Embed Size (px)
Citation preview
Build, Deploy & Manage your APIsAmazon API Gateway概要
Amazon Data Service Japan K.K.
Solutions Architect
Keisuke Nishitani(@Keisuke69)
2015.08.25 update
自己紹介{
"Name" : "西谷圭介",
"Twitter" : "@Keisuke69",
"Profile" : {
"Role" : "Solution Architect",
"Customers": [
"Web Services",
"Start-up"
],
"Services" : [
"AWS Lambda",
"Amazon API Gateway",
"All Mobile Services"
]
}
}
Look Back API, again
API
• Application Programming Interface
• アプリケーションから利用する処理のためのインターフェース
• WebAPI– Webベースのシステムで用意される
– HTTPをベースにデータをやり取りする
– SOAP、REST
急速に増えるAPI
2418
10302
0
2000
4000
6000
8000
10000
12000
6-0
5
10
-05
2-0
6
6-0
6
10
-06
2-0
7
6-0
7
10
-07
2-0
8
6-0
8
10
-08
2-0
9
6-0
9
10
-09
2-1
0
6-1
0
10
-10
2-1
1
6-1
1
10
-11
2-1
2
6-1
2
10
-12
2-1
3
6-1
3
10
-13
*Data from ProgrammableWeb
http://www.programmableweb.com/
APIの重要性
• エコシステムを形成できる• システム間連携
– 外部サービスとの連携– その逆も
• 疎結合（マイクロサービス）– フロントエンドとバックエンドのデカップリング
• フロントエンドの多様化– HTML5/JS– モバイルアプリ
• IoTによる接続されるデバイスの多様化
AWSには数多くのAPI
AWS自身がAPIを提供する中で多くの教訓を得ている
API管理の課題
API管理の課題
提供するAPIのバージョン管理
API利用状況のモニタ、管理とマネタイズ
APIに対する認証とアクセス権の管理
トラフィック管理とAPIエンドポイントのアタックからの保護
インフラのセットアップおよび管理とメンテナンス
クラウドネイティブ世代のAPI管理サービス
Amazon API Gateway
Amazon API Gateway
提供するAPIのバージョン管理
API利用状況のモニタ、管理とマネタイズ
APIに対する認証とアクセス権の管理
トラフィック管理とAPIエンドポイントのアタックからの保護
インフラのセットアップおよび管理とメンテナンス
Amazon API Gateway
複数バージョンとステージ
API利用状況のモニタ、管理とマネタイズ
APIに対する認証とアクセス権の管理
トラフィック管理とAPIエンドポイントのアタックからの保護
インフラのセットアップおよび管理とメンテナンス
Amazon API Gateway
複数バージョンとステージ
APIキーの作成と配布
APIに対する認証とアクセス権の管理
トラフィック管理とAPIエンドポイントのアタックからの保護
インフラのセットアップおよび管理とメンテナンス
Amazon API Gateway
複数バージョンとステージ
APIキーの作成と配布
リクエスト時におけるAWS SigV4の利用
トラフィック管理とAPIエンドポイントのアタックからの保護
インフラのセットアップおよび管理とメンテナンス
Amazon API Gateway
複数バージョンとステージ
APIキーの作成と配布
リクエスト時におけるAWS SigV4の利用
リクエストのスロットリングとモニタリング
インフラのセットアップおよび管理とメンテナンス
Amazon API Gateway
複数バージョンとステージ
APIキーの作成と配布
リクエスト時におけるAWS SigV4の利用
リクエストのスロットリングとモニタリング
バックエンドとしてAWS Lambdaが利用可能
AWS Lambda
AWS Lambda
• インフラを一切気にすることなくアプリケーションコードを実行できるコンピュートサービス– 実行基盤は全てAWSが管理
– AWSサービスと連携させることで簡単にイベントドリブンなアプリケーションを実装可能
– コード実行時間に対しての課金でありコスト効率が非常に高い
Amazon API Gateway
レスポンスをキャッシュ可能
CloudFrontを利用したレイテンシの軽減とDDoS対策
iOS、AndroidとJavaScript向けSDKの自動生成
Swaggerのサポート
Request / Responseにおけるデータ変換
従来のアーキテクチャ
・認証API
・データ保存API
Web DB
LB
クラウドネイティブなアーキテクチャ
Lambda（ロジック）
API GatewayDynamoDB（データ保存）
サーバレスで全部できます
サーバレスで全部できます
やりたいことだけに集中できる
サーバレスで全部できます
ビジネスロジックだけに集中できる
クラウドファーストからクラウドネイティブへ
REST APIについて
RESTとは
• Representational State Transfer
• Roy Fieldingが提唱したWebのソフトウェアアーキテクチャの1つ
• RESTの原則に則ったAPIをRESTfulという
RESTの特徴
• リソース指向
• URIによるリソースの識別
• ステートレス
• HTTPメソッドを利用した操作
リソース指向
• リソースとは名前を持つあらゆる情報のこと– 東京の天気– 今日のニュース– Amazonの株価
• 全てのリソースはURIで表現する– URIがリソースそのものを示す– URIとは1対1の関係
• 時間、条件によって「状態」は変わり得るが、その「意味」は変わることはない
URI
• Uniform Resource Identifier
• リソースを特定するもの– 例）https://api.example.com/resouces/1234
• 名詞で構成– 表現するのはあくまでもリソースでありアクションではない
– URIのパス内に動詞が存在しないのが基本（名詞のみ）
ステートレス
• クライアントとサーバ間の接続に状態を持たない
• （理想は）リクエストの1つ1つにそれを処理するにあたって必要な情報を全て含むこと
• 状態を持たないのでスケーラビリティの確保が容易になる
例：ステートフルなやり取り
いらっしゃいませ。○○バーガーへようこそ
ハンバーガーセットをください
サイドメニューはいかがなさいますか？
ポテトをください
ドリンクはいかがなさいますか？
はい
コーラをお願いします
以上でよろしいですか？
お会計は◯◯円になります
例：ステートレスなやり取り
いらっしゃいませ。○○バーガーへようこそ
ハンバーガーセットをください
サイドメニューはいかがなさいますか？
ハンバーガーセットをポテトでお願いします
ドリンクはいかがなさいますか？
ハンバーガーセットをポテトとコーラでお願いします
ハンバーガーセットをポテトとコーラでお願いします
以上でよろしいですか？
お会計は◯◯円になります
HTTPメソッド
• URIで示すリソースに対して何を行うかで利用するメソッドを選択する
• HTTPで定義されているメソッドを利用• GET/POST/PUT/DELETEおよびPATCHを主に利用する
HTTPメソッド 意味 CRUDとの対応
GET リソースの取得 READ
POST 子リソースの作成 CREATE
PUT リソースの更新（既存URI）リソースの作成（新規URI）
UPDATE
CREATE
DELETE リソースの削除 DELETE
PATCH リソースの部分更新 UPDATE
POST、PUTそしてPATCH
• POSTとPUTはともにリソースの作成が行える– リソースの作成には一般的にはPOSTを利用
– PUT• クライアントが指定したURIのリソースを作成
• クライアント側でリソース名を作成する
• サーバ側の命名規則等を知っている必要がある（密結合と言える）
• 冪等
– POST• リソース名はサーバによって作成される
• クライアントが指定するURIはあくまでも親リソース
• サーバによって子リソースのURIが作成される
• PUTとPATCH– PUTは指定したリソース全体を更新、PATCHはリソースの一部を更新
HTTPステータスコード
• 処理の実行結果はHTTPステータスコードで表現– HTTPステータスコードに意図を込める
• 400系はクライアント系のエラー– クライアントのリクエストに問題がある場合
– 指定されたリソースが見つからない、など
• 500系はサーバサイドのエラー– サーバがリクエストの処理を失敗した場合
HTTPステータスコードHTTPステータスコード 意味 例
200 OK リクエストに成功し、情報とともにレスポンスを返す場合 GETによるリソース情報の参照
201 CREATED リクエストは成功し、新しく作成されたリソースが返される POSTによるリソース作成
204 NO CONTENT リクエストに成功したが、レスポンスのエンティティが何もない場合
DELETEによる削除
400 BAD REQUEST リクエスト不正。クライアントのリクエストがおかしい場合 定義されていないメソッドを使用した場合、リクエストボディのJSONフォーマットがおかしい場合
401 UNAUTHORIZED 認証が必要 認証が必要なURLに対して、未認証でアクセスした場合
403 FORBIDDEN リソースへのアクセスが拒否された アクセス権のないリソースにアクセスした場合
404 NOT FOUND リソースが見つからなかった場合 存在しないリソースへのGET
409 CONFRICT 現在のリソースと競合する場合 作成・更新しようとしたデータがユニーク制約等でエラーになる場合
500 INTERNAL
SERVER ERROR
サーバ内部エラー 処理中の例外などサーバ側エラー全般
Amazon API Gatewayの動作
APIコールの流れ
Internet
Mobile Apps
Websites
Services
API
Gateway
AWS Lambda
functions
AWS
API Gateway
Cache
Endpoints on
Amazon EC2 /
Amazon
Elastic
Beanstalk
Any other publicly
accessible endpointAmazon
CloudWatch
Monitoring
API作成の流れ
1. 新規APIセットを作成
2. リソースおよびメソッドを定義– メソッドを作成した時点でテスト可能となる– 外部に公開はまだされていない状態
3. ステージへのデプロイ– ステージは本番、開発といったデプロイ環境の管理を楽にしてくれる概念– 各ステージごとにロギング、スロットリング、モニタリング、キャッシュの設定が可能
4. クローン– 既存のものをクローンして新規バージョンとしてデプロイすることが可能
5. ロールバック– 各ステージごとに300回分のデプロイ履歴を保持しており、いつでも過去バージョンに戻すことが可能
API詳細
• API自身を最上位とした階層構造になっている
• API内にリソースを定義– 複数定義
– リソース名がURLのパスの一部となる
– ネストすることも可能 ex) /pets/{petId}
• 各リソースにメソッドを定義– メソッドはリソース＋HTTPメソッドで構成される
– スタンダードな7つのHTTPメソッドをサポート
Pet Store
/pets
/pets/{petId}
• GET
• POST
• PUT
APIのデプロイ
• APIはステージにデプロイされる
• ステージはそれぞれ個別の環境を表す
• ステージ名はURIの一部となる– 例:
Dev (e.g. awsapigateway.com/dev)
Beta (e.g. awsapigateway.com/beta)
Prod (e.g. awsapigateway.com/prod)
Pet Store
dev
beta
gamma
prod
APIの複数バージョンとステージ
API 1 (v1)
Stage (dev)
Stage (prod)
API 2 (v2)
Stage (dev)
APIの呼び出し
• デプロイ後から呼び出し可能– 呼び出したいメソッドにも寄るがシンプルなGETなどの場合ブラウザ上からも可能
• my-api-id– API作成時に払い出される識別子
• region-id– APIが作成されたリージョン
• stage-name– 呼び出したいAPIがデプロイされているステージ
https://my-api-id.execute-api.region-id.amazonaws.com/stage-name/{resourcePath}
独自ドメイン
• エンドポイントとして独自ドメインを利用可能– 独自ドメインでAPI提供が可能
– SSL証明書を用意し、API Gatewayにアップロードする
– 利用しているDNSにDistribution Domain Nameに対するCNAMEとして登録する
• API全体だけでなく、特定環境（ステージ）のみを独自ドメインで
提供することも可能
• 全ステージにアクセス可能なAPIの指定– Beta (e.g. yourapi.com/beta)
– Prod (e.g. yourapi.com/prod)
• “prod”ステージを直接指定– Prod (e.g. yourapi.com/)
ダッシュボード
• API Calls– 呼び出し回数
• Latency– リクエストを受け取ってから応答するまでの時間（ミリ秒）
• 4xx Error– 4xxを返した回数
• 5xx Error– 5xxを返した回数
メソッド設定
メソッド設定
Method Request
Method Request
• Authorization type– NONEもしくはAWS_IAMを選択– AWS_IAMの場合、正しいIAMロールがセットされているIAMユーザのみがメソッド実行可能とな
り、リクエストに署名が必要となる
• API Key Required– API Keyが必要かどうかをtrue/falseで選択
• URL Query String Parameters– 受け付けるクエリストリングを指定
• HTTP Request Headers– 受け付けるヘッダを指定
• Request Models– GET以外の場合は利用するモデルを選択し、content-typeを指定する
URL Query String Parametersの例
• この場合、/<resource>?hoge=fugaといったリクエストを受け付ける
IAMロール
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"apigateway:method-type"
],
"Resource": [
"resource-statement"
]
}
]
}
• method-type
• メソッドのタイプ（GET/POSTなど）を指定• resource-statement
• Authorization Settings内に表示されているARNを指定
Integration Request
Integration Request
• バックエンドとのやり取りに関する設定• Integration Type
– 利用するバックエンドの種別と関連する情報を設定
• Integration TypeがLambda以外の場合は以下の設定も可能– URL Path Parameters– URL Query String Parameters– HTTP Headers– それぞれMethodRequestで指定したパラメータとマッピングする
• Mapping Templates– Content-Typeを設定した上で、Input passthroughもしくはマッピングテンプレート（後述）を指定
– Input passthroughを選択すると受け取ったデータをそのままバックエンドに渡す
– 標準ではapplication/jsonでInput passthroughとなっている
Integration Request（Integration Type）
• Lambdaファンクション
• HTTP Proxy– EC2上で構築したWebAPIなどを利用する場合– 外部のWebサービスを呼び出すことも可能– エンドポイントとして呼び出し先のURLとHTTPメソッドを指定– 現時点ではアクセス先はPublic IPを持っている必要あり
• AWS Service Proxy– AWSのサービスを直接呼び出すことが可能– 各サービスで用意されているアクションを実行可能
Method Response
Method Response
• 返すHTTPステータスコードごとにカスタムヘッダやカスタムデータを返すことが可能
• シンプルに200だけをOutput passthoroughで返すのであれば設定しなくても問題ない
Integration Response
Integration Response
• バックエンドの結果を元に特定のHTTPステータスコードを返すための設定– 標準ではステータスコード200についてのみ設定されている– バックエンドがLambdaファンクションの場合、エラーメッセージの正規表現で指定する。– HTTP Proxyの場合はバックエンドが返すHTTPステータスコードを正規表現で指定
• 以下の設定も可能– Header Mappings– Mapping Template– それぞれMethod Responseで設定した値を指定する
• Mapping Templates– Content-Typeを設定した上で、Output passthroughもしくはマッピングテンプレート（後述）を指定
– Output passthroughを選択するとバックエンドから受け取ったデータをそのままレスポンスする
– 標準ではapplication/jsonでOutput passthroughとなっている
Integration Response（Lambdaの場合）
Integration Response（HTTP Proxyの場合）
APIキーの使用
APIキー
• APIキーを有効にすることでAPI Gatewayが払い出すAPIキーを使用した
メータリングが可能– 正しいAPIキーを含まないリクエストはエラーになる
– API/ステージレベルで設定可能
• リクエストのヘッダにAPIキーを含める
x-api-key: bkayZOMvuy8aZOhIgxq94K9Oe7Y70Hw55
• CloudWatchによりAPIキーごとの使用量を計測可能
• 認可のために用いないこと– あくまで計測目的として用意されている
– 認可はAPI Signature Version 4もしくは自前でOauth等のメカニズムを用意して行う
認可
AWS Sigv4の活用、もしくはカスタムヘッダの利用
• APIコールの署名と認可にAWS Sigv4を利用可能
– Amazon CognitoとAWS Security Token Service(STS)のようなテンポラリ
クレデンシャルを利用
– IAMロールと紐づく形で認証・認可が行われる
– 生成されたクライアントSDKを利用することで自動的に利用可能
• OAuthもしくはその他の認可メカニズムはカスタムヘッ
ダを用いて対応
– バックエンドに対してカスタムヘッダをフォワードするよう構成
スロットリングとキャッシュ
スロットリング
• メソッド単位でのスロットリングを提供– ステージ単位で全体的に同一設定にすることも、個々のメソッドに対して個別
に設定することも可能
– スロットリングによりバックエンドのパフォーマンスと可用性を維持
– 許容するリクエスト/秒を指定
– バーストを許容する設定も可能
– トークンバケットアルゴリズムによる実装
• リミットを超えたリクエストがスロットリングされる– HTTPステータス429をレスポンス
– 生成したSDKを使う場合、自動でリトライする
レスポンスのキャッシング
• レイテンシ減とバックエンドへのトラフィック軽減
– キャッシュがあった場合、バックエンドを呼び出すことなくレスポンス
• ステージ単位のキャッシュプロビジョニング
– 0.5GBから最大237GBの間でプロビジョニング
• 細やかな設定
– メソッド単位で暗号化とTTLを設定
– クエリパラメータ、ヘッダ、パスパラメータ単位でキャッシュ有無を設定
• キャッシュアルゴリズムはLRU（Least Recently Used）
リクエストの処理フロー
Receive incoming request
•Check for item in dedicated cache
• If found return cached item
Check throttling configuration
•Check current RPS rate
• If above allowed rate return 429
Execute backend call
モデル
• リクエスト/レスポンスで扱われるデータのスキー
マを定義したもの
– テンプレートとマッピングして使う
– JSON形式で定義
• モデルの情報を元にSDKを生成
• API内で複数メソッドをまたがってモデルを再利用
可
モデル例：元データ{"department": "produce","categories": ["fruit","vegetables"
],"bins": [{"category": "fruit","type": "apples","price": 1.99,"unit": "pound","quantity": 232
},{"category": "fruit","type": "bananas","price": 0.19,"unit": "each","quantity": 112
},{"category": "vegetables","type": "carrots","price": 1.29,"unit": "bag","quantity": 57
}]
}
• トップレベル• department（string）• categories（配列）• bins（配列）
• categoriesにはstringのコレクションが含まれる
• binsはオブジェクトのコレクションを含む• 各オブジェクトは以下の要素を持つ
• category（string）• type（string）• price（number）• unit（string）• quantity（number）
モデル例
{"$schema": "http://json-schema.org/draft-04/schema#","title": "GroceryStoreInputModel","type": "object","properties": {"department": { "type": "string" },"categories": {
"type": "array","items": { "type": "string" }
},"bins": {
"type": "array","items": {"type": "object","properties": {"category": { "type": "string" },"type": { "type": "string" },"price": { "type": "number" },"unit": { "type": "string" },"quantity": { "type": "integer" }
}}
}}
}
• title – モデルの識別子
• トップレベルのdepartment、categories、binsをpropertiesとして指定• それぞれの型をtypeで指定
• Categories、binsに含まれるオブジェクトをitemsとして定義• 各項目ごとにtypeを指定
マッピングテンプレート
• あるデータを別の形式に変換することが可能
• インプットとアウトプットそれぞれのマッピングテンプレートを作成
• マッピングテンプレートはVelocity Template Language (VTL) およびJSONPathで定義
• 以下のようなユースケースで利用する– レガシーなバックエンドからのレスポンスをフィルタ
• プライベートなものや不必要なデータを削除
– GETリクエストのクエリストリングを元にPOSTのボディを生成し、バックエンドをPOSTで呼び出し• バックエンドがRPC形式でPOSTのリクエストしか受け付けない場合
– LambdaファンクションからJSONを受け取り、XMLに変換
変換例: JSONからXMLに
API Gateway Backend
GET - /peoples/1234Lambda fn
get_people
/peoples/1234
{
“name” : “John”
}
<xml>
<name>
John
</name>
</xml>
#set($root = $input.path('$'))
<xml>
<name>
$root.name
</name>
</xml>
マッピングテンプレート
SDKの生成
クライアントSDKの自動生成
• ステージごとに生成可能
• API設定を元に自動生成
– モデルの設定を元にIn/Outのマーシャリングに関する処理も含ま
れる
• スロットリング時のリトライやリクエストの署名
に関する処理を含む
• Android、iOS、JavaScriptをサポート
価格
• 100万リクエストあたり$3.50
• AWS無料枠に含まれる– 100万リクエスト/月を12ヶ月間
• 外向きデータ転送量(AWSの標準価格)– 10TBまで$0.09/GB
– 次の40TBまで$0.085/GB
– 次の100TBまで$0.07/GB
– 次の350TBまで$0.05/GB
価格 – キャッシュ
Cache Memory
Size (GB)
Price per Hour
(USD)
0.5 $0.020
1.6 $0.038
6 $0.200
13 $0.250
28 $0.500
58 $1.000
118 $1.900
237 $3.800
制限事項
• 利用可能なリージョン– US East (N. Virginia)
– US West (Oregon)
– EU West (Dublin)
• アカウントあたり最大で60APIまで
• APIあたり300リソースまで
• APIあたり10ステージまで
Amazon API Gateway
http://aws.amazon.com/apigateway/
Build, Deploy & Manage your APIs NOW
参考文献
• Developer Guidehttp://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html
• AWS Lambdahttp://docs.aws.amazon.com/lambda/latest/dg/welcome.html
• Roy Fieldingの博士論文「Architectural Styles and the Design of Network-based Software Architectures」第5章http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
