AWS Black Belt Tech シリーズ 2015 - Amazon API Gateway
•
82 likes•69,526 views
AWS Black Belt Tech Webinar 2015 Amazon API Gateway 次回のWebinarは、下記よりご確認ください。 http://aws.amazon.com/jp/about-aws/events/#webinar
![自己紹介
{
"Name" : "西谷圭介",
"Twitter" : "@Keisuke69",
"Profile" : {
"Role" : "Solution Architect",
"Customers": [
"Web Services",
"Start-up"
],
"Services" : [
"AWS Lambda",
"Amazon API Gateway",
"All Mobile Services"
]
}
}](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to AWS Black Belt Tech シリーズ 2015 - Amazon API Gateway
Similar to AWS Black Belt Tech シリーズ 2015 - Amazon API Gateway (20)
More from Amazon Web Services Japan
More from Amazon Web Services Japan (20)
Recently uploaded
Recently uploaded (11)
AWS Black Belt Tech シリーズ 2015 - Amazon API Gateway
- 1. Build, Deploy & Manage your APIs Amazon API Gateway概要 Amazon Data Service Japan K.K. Solutions Architect Keisuke Nishitani(@Keisuke69) 2015.08.25 update
- 2. 自己紹介 { "Name" : "西谷圭介", "Twitter" : "@Keisuke69", "Profile" : { "Role" : "Solution Architect", "Customers": [ "Web Services", "Start-up" ], "Services" : [ "AWS Lambda", "Amazon API Gateway", "All Mobile Services" ] } }
- 3. Look Back API, again
- 4. API • Application Programming Interface • アプリケーションから利用する処理のためのイン ターフェース • WebAPI – Webベースのシステムで用意される – HTTPをベースにデータをやり取りする – SOAP、REST
- 6. APIの重要性 • エコシステムを形成できる • システム間連携 – 外部サービスとの連携 – その逆も • 疎結合（マイクロサービス） – フロントエンドとバックエンドのデカップリング • フロントエンドの多様化 – HTML5/JS – モバイルアプリ • IoTによる接続されるデバイスの多様化
- 8. API管理の課題
- 15. Amazon API Gateway 複数バージョンとステージ APIキーの作成と配布 リクエスト時におけるAWS SigV4の利用 トラフィック管理とAPIエンドポイントのアタックからの保護 インフラのセットアップおよび管理とメンテナンス
- 16. Amazon API Gateway 複数バージョンとステージ APIキーの作成と配布 リクエスト時におけるAWS SigV4の利用 リクエストのスロットリングとモニタリング インフラのセットアップおよび管理とメンテナンス
- 17. Amazon API Gateway 複数バージョンとステージ APIキーの作成と配布 リクエスト時におけるAWS SigV4の利用 リクエストのスロットリングとモニタリング バックエンドとしてAWS Lambdaが利用可能
- 18. AWS Lambda
- 19. AWS Lambda • インフラを一切気にすることなくアプリケー ションコードを実行できるコンピュートサービ ス – 実行基盤は全てAWSが管理 – AWSサービスと連携させることで簡単にイベントドリブンなア プリケーションを実装可能 – コード実行時間に対しての課金でありコスト効率が非常に高い
- 20. Amazon API Gateway レスポンスをキャッシュ可能 CloudFrontを利用したレイテンシの軽減とDDoS対策 iOS、AndroidとJavaScript向けSDKの自動生成 Swaggerのサポート Request / Responseにおけるデータ変換
- 23. サーバレスで 全部できます
- 28. REST APIについて
- 29. RESTとは • Representational State Transfer • Roy Fieldingが提唱したWebのソフトウェア アーキテクチャの1つ • RESTの原則に則ったAPIをRESTfulという
- 30. RESTの特徴 • リソース指向 • URIによるリソースの識別 • ステートレス • HTTPメソッドを利用した操作
- 31. リソース指向 • リソースとは名前を持つあらゆる情報のこと – 東京の天気 – 今日のニュース – Amazonの株価 • 全てのリソースはURIで表現する – URIがリソースそのものを示す – URIとは1対1の関係 • 時間、条件によって「状態」は変わり得るが、その 「意味」は変わることはない
- 32. URI • Uniform Resource Identifier • リソースを特定するもの – 例）https://api.example.com/resouces/1234 • 名詞で構成 – 表現するのはあくまでもリソースでありアクションではない – URIのパス内に動詞が存在しないのが基本（名詞のみ）
- 33. ステートレス • クライアントとサーバ間の接続に状態を持たな い • （理想は）リクエストの1つ1つにそれを処理す るにあたって必要な情報を全て含むこと • 状態を持たないのでスケーラビリティの確保が 容易になる
- 36. HTTPメソッド • URIで示すリソースに対して何を行うかで利用するメ ソッドを選択する • HTTPで定義されているメソッドを利用 • GET/POST/PUT/DELETEおよびPATCHを主に利用する HTTPメソッド 意味 CRUDとの対応 GET リソースの取得 READ POST 子リソースの作成 CREATE PUT リソースの更新（既存URI） リソースの作成（新規URI） UPDATE CREATE DELETE リソースの削除 DELETE PATCH リソースの部分更新 UPDATE
- 37. POST、PUTそしてPATCH • POSTとPUTはともにリソースの作成が行える – リソースの作成には一般的にはPOSTを利用 – PUT • クライアントが指定したURIのリソースを作成 • クライアント側でリソース名を作成する • サーバ側の命名規則等を知っている必要がある（密結合と言える） • 冪等 – POST • リソース名はサーバによって作成される • クライアントが指定するURIはあくまでも親リソース • サーバによって子リソースのURIが作成される • PUTとPATCH – PUTは指定したリソース全体を更新、PATCHはリソースの一部を更新
- 38. HTTPステータスコード • 処理の実行結果はHTTPステータスコードで表 現 – HTTPステータスコードに意図を込める • 400系はクライアント系のエラー – クライアントのリクエストに問題がある場合 – 指定されたリソースが見つからない、など • 500系はサーバサイドのエラー – サーバがリクエストの処理を失敗した場合
- 39. 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 サーバ内部エラー 処理中の例外などサーバ側エラー全 般
- 41. 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 endpoint Amazon CloudWatch Monitoring
- 42. API作成の流れ 1. 新規APIセットを作成 2. リソースおよびメソッドを定義 – メソッドを作成した時点でテスト可能となる – 外部に公開はまだされていない状態 3. ステージへのデプロイ – ステージは本番、開発といったデプロイ環境の管理を楽にしてくれる概念 – 各ステージごとにロギング、スロットリング、モニタリング、キャッシュの設定が可能 4. クローン – 既存のものをクローンして新規バージョンとしてデプロイすることが可能 5. ロールバック – 各ステージごとに300回分のデプロイ履歴を保持しており、いつでも過去バージョンに戻す ことが可能
- 43. API詳細 • API自身を最上位とした階層構造になっている • API内にリソースを定義 – 複数定義 – リソース名がURLのパスの一部となる – ネストすることも可能 ex) /pets/{petId} • 各リソースにメソッドを定義 – メソッドはリソース＋HTTPメソッドで構成される – スタンダードな7つのHTTPメソッドをサポート Pet Store /pets /pets/{petId} • GET • POST • PUT
- 44. 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
- 45. APIの複数バージョンとステージ API 1 (v1) Stage (dev) Stage (prod) API 2 (v2) Stage (dev)
- 46. 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}
- 47. 独自ドメイン • エンドポイントとして独自ドメインを利用可能 – 独自ドメインで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/)
- 48. ダッシュボード • API Calls – 呼び出し回数 • Latency – リクエストを受け取ってから応答 するまでの時間（ミリ秒） • 4xx Error – 4xxを返した回数 • 5xx Error – 5xxを返した回数
- 49. メソッド設定
- 50. メソッド設定
- 51. Method Request
- 52. 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を指定する
- 53. URL Query String Parametersの例 • この場合、/<resource>?hoge=fugaといった リクエストを受け付ける
- 54. IAMロール { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "apigateway:method-type" ], "Resource": [ "resource-statement" ] } ] } • method-type • メソッドのタイプ（GET/POSTなど）を指定 • resource-statement • Authorization Settings内に表示されているARNを指定
- 56. 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となっている
- 57. Integration Request（Integration Type） • Lambdaファンクション • HTTP Proxy – EC2上で構築したWebAPIなどを利用する場合 – 外部のWebサービスを呼び出すことも可能 – エンドポイントとして呼び出し先のURLとHTTPメソッドを指定 – 現時点ではアクセス先はPublic IPを持っている必要あり • AWS Service Proxy – AWSのサービスを直接呼び出すことが可能 – 各サービスで用意されているアクションを実行可能
- 58. Method Response
- 59. Method Response • 返すHTTPステータスコードごとにカスタムヘッダやカスタムデータを返すことが可 能 • シンプルに200だけをOutput passthoroughで返すのであれば設定しなくても問題 ない
- 61. 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となっている
- 64. APIキーの使用
- 65. APIキー • APIキーを有効にすることでAPI Gatewayが払い出すAPIキーを使用した メータリングが可能 – 正しいAPIキーを含まないリクエストはエラーになる – API/ステージレベルで設定可能 • リクエストのヘッダにAPIキーを含める x-api-key: bkayZOMvuy8aZOhIgxq94K9Oe7Y70Hw55 • CloudWatchによりAPIキーごとの使用量を計測可能 • 認可のために用いないこと – あくまで計測目的として用意されている – 認可はAPI Signature Version 4もしくは自前でOauth等のメカニズムを用意して行う
- 66. 認可
- 67. AWS Sigv4の活用、もしくはカスタムヘッダの利用 • APIコールの署名と認可にAWS Sigv4を利用可能 – Amazon CognitoとAWS Security Token Service(STS)のようなテンポラリ クレデンシャルを利用 – IAMロールと紐づく形で認証・認可が行われる – 生成されたクライアントSDKを利用することで自動的に利用可能 • OAuthもしくはその他の認可メカニズムはカスタムヘッ ダを用いて対応 – バックエンドに対してカスタムヘッダをフォワードするよう構成
- 68. スロットリングとキャッシュ
- 69. スロットリング • メソッド単位でのスロットリングを提供 – ステージ単位で全体的に同一設定にすることも、個々のメソッドに対して個別 に設定することも可能 – スロットリングによりバックエンドのパフォーマンスと可用性を維持 – 許容するリクエスト/秒を指定 – バーストを許容する設定も可能 – トークンバケットアルゴリズムによる実装 • リミットを超えたリクエストがスロットリングされる – HTTPステータス429をレスポンス – 生成したSDKを使う場合、自動でリトライする
- 70. レスポンスのキャッシング • レイテンシ減とバックエンドへのトラフィック軽減 – キャッシュがあった場合、バックエンドを呼び出すことなくレスポンス • ステージ単位のキャッシュプロビジョニング – 0.5GBから最大237GBの間でプロビジョニング • 細やかな設定 – メソッド単位で暗号化とTTLを設定 – クエリパラメータ、ヘッダ、パスパラメータ単位でキャッシュ有無を設定 • キャッシュアルゴリズムはLRU（Least Recently Used）
- 71. リクエストの処理フロー 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
- 72. モデル • リクエスト/レスポンスで扱われるデータのスキー マを定義したもの – テンプレートとマッピングして使う – JSON形式で定義 • モデルの情報を元にSDKを生成 • API内で複数メソッドをまたがってモデルを再利用 可
- 73. モデル例：元データ { "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）
- 74. モデル例 { "$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を指定
- 75. マッピングテンプレート • あるデータを別の形式に変換することが可能 • インプットとアウトプットそれぞれのマッピングテンプレートを作 成 • マッピングテンプレートはVelocity Template Language (VTL) お よびJSONPathで定義 • 以下のようなユースケースで利用する – レガシーなバックエンドからのレスポンスをフィルタ • プライベートなものや不必要なデータを削除 – GETリクエストのクエリストリングを元にPOSTのボディを生成し、バックエンドをPOST で呼び出し • バックエンドがRPC形式でPOSTのリクエストしか受け付けない場合 – LambdaファンクションからJSONを受け取り、XMLに変換
- 76. 変換例: JSONからXMLに API Gateway Backend GET - /peoples/1234 Lambda fn get_people /peoples/1234 { “name” : “John” } <xml> <name> John </name> </xml> #set($root = $input.path('$')) <xml> <name> $root.name </name> </xml> マッピングテンプレート
- 77. SDKの生成
- 78. クライアントSDKの自動生成 • ステージごとに生成可能 • API設定を元に自動生成 – モデルの設定を元にIn/Outのマーシャリングに関する処理も含ま れる • スロットリング時のリトライやリクエストの署名 に関する処理を含む • Android、iOS、JavaScriptをサポート
- 79. 価格 • 100万リクエストあたり$3.50 • AWS無料枠に含まれる – 100万リクエスト/月を12ヶ月間 • 外向きデータ転送量(AWSの標準価格) – 10TBまで$0.09/GB – 次の40TBまで$0.085/GB – 次の100TBまで$0.07/GB – 次の350TBまで$0.05/GB
- 80. 価格 – キャッシュ 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
- 81. 制限事項 • 利用可能なリージョン – US East (N. Virginia) – US West (Oregon) – EU West (Dublin) • アカウントあたり最大で60APIまで • APIあたり300リソースまで • APIあたり10ステージまで
- 82. Amazon API Gateway http://aws.amazon.com/apigateway/ Build, Deploy & Manage your APIs NOW
- 83. 参考文献 • Developer Guide http://docs.aws.amazon.com/apigateway/latest/developergu ide/welcome.html • AWS Lambda http://docs.aws.amazon.com/lambda/latest/dg/welcome.ht ml • Roy Fieldingの博士論文「Architectural Styles and the Design of Network-based Software Architectures」第5章 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc h_style.htm