私はみんなが必要としているシステムの一部としてのインフラストラクチャを考えることが好きですが、取り組むことが好きな人はいません！しばしば、ちゃんとで識別されておらず散らかっており、取り組むことが退屈で、管理することが難しく、それに依存するものはなんでも成功のためには不可欠で、そして一般的には（それが期待通りに動作している限り）当たり前のことです。
我々のカスタマーの多くはモバイル、Web、エンタープライズもしくはIoT（Internet of Things）アプリケーションのためにバックエンドのWebサービスをAWS上でホストしています。これらのサービスはユーザインターフェースを持ちません。その代わり、プログラム、一般的にはRESTスタイルのインターフェースを利用してアクセスされます。正常にアプリケーションバックエンドをホストするために、インフラストラクチャについて考える必要あります。認証、アクセス制御、トラフィック管理、モニタリング、分析そしてバージョン管理です。これらのタスクはどれも簡単ではありませんし、すべてインフラストラクチャとしてカウントされます。多くの場合、ビルド、保守そして一つもしくはそれ以上のプログラミング言語向けにSDK（Software Development Kit、ソフトウェア開発キット）を配布する必要があります。まとめると、Webサービスのためのインフラストラクチャに専念するコードとリソースの量は（頭をかくのはもちろんのこと）サービスの実際の実装を小さく見せます。多くのカスタマーはWebサービスへの投資を行いますが、コストや複雑に関わる物事のためインフラストラクチャの構築や保守にはあまり興味を持っていません。
新しいAPI Gateway
本日、新たにAmazon API Gatewayを紹介します。この新たな従量課金制のサービスにより、皆さんは素早く、簡単に信頼性高くスケーラブルなアプリケーションバックエンドを構築し、実行することが可能になります。インフラストラクチャについて心配する代わりに、自分のサービスに集中できます。
API GatewayはAWS LambdaやAmazon Elastic Compute Cloud (EC2)、もしくはパブリックにアドレス指定可能なAWS外でホストされているサービス上で実行されているAPI実装に対してすべてのアプリケーションを接続することを簡単にします。もしLambdaを利用しているならば（すぐにどうやるかお見せします）、非常にスケーラブルで、すべてサーバレスなAPIを実装可能です。
レガシーシステムをラップし、拡張し、そして効率的にモダン化するAPIを実装することもできます。複数の旧式なRPCスタイルなWebサービスからの結果を単一のレスポンスに集約したり、データのフィルタや処理、組み込みのスロットリング機能を活用することによる過負荷からバックエンドサービスを保護することが可能です。
API Gatewayは以下のような約束事を提供するようデザインされました。
- スケーラブル &効率的 – システムリソースをいかしつつ、あらゆる量の秒あたりリクエスト（RPS）を処理
- セルフサービス &高い利便性 – 簡単なSDK生成も含め、特別な知識やスキルを必要とすることなく数クリックでAPIを定義、変更、デプロイや監視ができる
- 高信頼性 – カスタマイズされたエラー応答を含むエラーハンドリングを完全に制御した状態で非常に信頼性の高いサービスを構築可能
- セキュア – 最新のAWSの認証メカニズム、そしてAPIとAWSリソースを管理するIAMポリシーを活用可能
- 高性能 – AWSネットワークを介したバックエンドへのデータ転送により、低レイテンシなアクセスのために、（CloudFront経由で）グローバルにアクセス可能なサービスを構築可能
- 費用対効果 – 固定費用がなく従量課金制の価格により、実行が経済的なサービスを構築可能
このサービスをデザインした際、多くの時間を開発者のニーズにフォーカスすることに費やしました。例えば、カスタマーの多くは自分たちのAPIを説明するためにSwaggerを使うと教えてくれました。彼らは我々が提供するツールを用いて数分で自分たちの既存の定義をAPI Gatewayにインポートできます。また、それらをすぐさま新規もしくは既存の実装と接続することが可能です。
実装がまだ進行中の間に定義は作成されうるため、APIファーストな開発モデルのサポートもしています。一度APIが定義されれば、数クリックでAPI GatewayがJavaScript、iOS、AndroidのSDKを作成します（将来的にはより多くの言語を追加します）。
テストとデプロイを簡単にするためにデザインされた機能が数多くあります。マネージメントコンソールからHTTPステータスコード、レスポンス（ボディおよびヘッダ）そしてリクエストログへフルアクセス可能な状態でAPIをテストすることができます。
複数環境のAPI（API GatewayではStagesと呼びます）を作成し、そして定義したタグ（dev、beta、prodなど…）の範囲内で選択的にデプロイすることが可能です。繰り返しますが数クリックで、です。各バージョンにおける各操作は個別の実装を持たせることができます（必要ではないですが）。新しいバージョンを作るときがきたら、古いものを廃止するという最終的な目標で既存のものをクローンし、個別のステージにクローンをデプロイし、両方を稼働させ続けることが可能です。各サービスのURLをより制御するためにカスタムドメインネームを使用することも可能です。
最後に、API Gatewayは運用面でのサポートを多く提供します！
APIをデプロイしたのち、API Gatewayは迅速に受け取り、処理し、モニターし、リクエストに応えます。キャッシュされたレスポンスの寿命とリクエストパラメータとキャッシュのキーのマッピングを完全に制御して、各ステージごとにキャッシュを設定することが可能です。APIへのリクエストはAWS CloudTrailへと記録され、詳細なメトリクスはステージ単位、メソッド単位でAmazon CloudWatchに対してレポートされます。APIを作ったり設定したりといった管理上のアクションは監査目的でCloudTrailに記録されます。望んだレートを超えたらリクエストをスロットリングできます。そして、個々のメソッドへのアクセスの認可のためにAWS Identity and Access Management (IAM)、Amazon Cognito、もしくはOAuthを利用できます。
API Gateway in Action
Lambdaファンクションの前にAPI作成のプロセスを見ていきましょう。スペースの都合上、API Gatewayの機能の少しだけをお見せします。また、IAMポリシーに関するいくつかのステップはスキップします。サービスができることをより知るため、必要なポリシーの作り方を学ぶためにAmazon API Gateway Developer Guideを読むことをお奨めします。
API Gatewayのコンソールを開き、APIを作成することから始めます。
コンソールはツリー形式でAPIを表示します。
それからCreate Resourceボタンをクリックし、ルートリソース内に子リソースを作成します。
新しいリソースはツリー内に作成され、表示されます。
ここで、実際のコードが必要です。Lambdaコンソールに切り替え、/dataリソースにおけるメソッドの実装として機能するファンクションのペアを作成します。最初のファンクションはGetHelloWorldと呼ばれます。インプットはなく、とてもシンプルで不変のJSONオブジェクトを返します。こちらがコードです。
二つ目のファンクションはGetHelloWithNameと呼ばれます。これは少しばかり洗練されています。nameというパラメータを渡したら、JSONオブジェクト内でその名前を返します。パラメータが存在しなければ、"No-Name"という文字列を代わりに使用します。こちらがコードです。
2つのファンクションが準備でき、リソース上にメソッドを作成しこれらをコードにアタッチすることができます。API Gateway Consoleに戻り、Create Methodをクリックし、そしてHTTPメソッドを選びます。
複数のメソッド（HTTPメソッドにつき一つ）を自分のいずれかのリソース上に作成できます。GETを選び、そしてIntegration TypeとしてLambdaファンクションを指定します（後ほど他のものについてもお話します）。
APIコールの各フェーズ（メソッドのリクエストとレスポンス、インテグレーションのリクエストとレスポンス）をカスタマイズするためのオプションがあります。
デフォルト設定がうまく動作します！メソッドの実行を見る時間です。TESTアイコン（稲妻です）をクリックし、それからTestボタンをクリックします。API Gatewayはメソッドを呼び出し、レスポンスボディ、レスポンスヘッダと実行ログ（Lambdaファンクションの呼び出しを準備し、発行し、処理するために行われた処理）を提供してくれます。
Lambdaコンソールに移り、そこから自分のファンクションに対するメトリクスを見ることもできます。
自分のAPIに満足したら、他の人がそれを利用できるようにするためそれをデプロイできます。これをするには、Deploy APIボタンを単にクリックし、ステージを選択するだけです。ステージはAPIのURLの一部となり、お互いが隔離され、独立した複数で並行的なデプロイメント（ステージング、ベータ、本番など）を可能にします。
それから、各ステージに対していくつかのオプションをセットする機会があります。APIコールをCloudWatch Logsに記録し、CloudWatchにメトリックごとのメトリクスを送ることを選べます。APIへの全てのコールに対して、それが受け入れられるようにするためにはAPIキーを含まなければいけないように示すこともできます。
ご覧のように、コンソールにはAPIの呼び出しURLが表示されています。SDKを生成するオプションもあります。
カスタムドメイン名を作成し、自分のサービスのための優先的な呼び出しURLとしてそのURLを公開することもできます（これら全てはコンソールを通して行え、CloudFrontを通して実装されます）。
この時点で、インフラストラクチャについて考える必要なく完全にスケーラブルなAPIを作成し、デプロイしました。もし、Hello Worldファンクションがとてもポピュラーになっても、AWSアカウントが十分な数の同時Lambdaリクエストを処理できるよう設定されているかを確認する以上のことはなにもする必要ありません。
レガシーサービスをエンハンスする
あなた（もしくはあなたの組織）はXML-RPCもしくはSOAPといった古いプロトコルに応答するいくつかの既存Webサービスを持っているかもしれません。以下の機能を利用し、ニーズに合わせて必要に応じて選りすぐることでこれらのサービスをモダンなものにするのにAPI Gatewayを利用できます。
- トラフィック管理 – 事前に定義された制限を超えたらリクエストをスロットリングするようAPI Gatewayを構成できます。これにより、既存（そして、おそらくスケーラブルではない）バックエンドシステムの過負荷を避けられます。
- 認可 – 作成したAPIに対して最新のAWSスタイル（AWS Signature v4）の認証を有効にできます（AWSの認証に関する詳細な情報はSigning API Requestsをチェックしてください）。API Gatewayを通して生成したSDKが必要となる署名、暗号化と復号化の全てを処理します。
- データ変換 – もし既存サービスがXMLスタイルのデータを返すならば、API Gatewayを使って、モダン化の一環でアウトプットをJSONに変換することができます。我々の初期のカスタマーの一つは返すファンクションで彼らのサービス実装をJSONデータをLambdaベースのモデルに移行するプロセスの最中です。移行期間中、レガシーサービスのアウトプットをJSONに変換するのに彼らはAPI Gatewayを使っていて、シームレスで無停止な移行ができます。変換は次のようにJSONスキーマを使用することで指定されます
![]()
- RESTからRPC、その逆 – GETリクエストに応答する新しいAPIエンドポイントを作成し、POSTを使ってアクセスされる既存のエンドポイントにマップすることができます。GETパラメータをPOSTのリクエストボディに変換するためにAPI Gatewayを使用できます。
待って、他にもまだまだあります！
まとめの前にあといくつかのAPI Gatewayの機能を見ていきましょう。
リソース定義（リソース名とHTTPメソッド）とコード間の接続はIntegration Requestと呼ばれます。すでに見たように、数クリックでリクエストはLambdaファンクションに送られます。任意のHTTPエンドポイント（EC2上、もしくはあらゆるパブリックにアクセス可能な場所で実行されている）に送ることもできます。リクエストは異なるHTTPメソッド（例えばGETをPOSTに）にマップすることもできます。そして、API Gatewayのモデルがインプットをエンドポイントで実行されているサービスに必要とされる形式に変換するのに使われます。モデルはJSON-Schemaを用いて指定され、コンソールを使ってセットアップできます。
エンドポイントとしてAWSサービスによって提供されているAPIファンクションを使用できます。このオプションはAPI Gatewayに含まれるAWS Service Proxyを使用します。こちらがそのセットアップの方法です。
APIキーについて前述しました。もし、サードパーティ（カスタマー、開発者もしくはインテグレーションパートナー）がAPIへコントロールに基づいてアクセスできるようにしたい場合、APIキーを作成し、APIをコールするのに使用を義務付けることができます。この機能はメータリング用途でデザインされています。APIへのアクセスをコントロールするためにはAWSの認証オプション（もしくはOAuth）のいずれかを使用するのがいいでしょう。
今すぐ利用可能
Amazon API GatewayはUS East (北バージニア)、US West (オレゴン)とEurope (アイルランド)のリージョンで本日から利用可能で、本日から使い始めることができます。
価格モデルはシンプルです。APIへのコールとアウトバウンドのデータ転送（APIが返す情報）に対して支払います。キャッシュは別の値立てとなっていて、価格は構成したキャッシュのサイズによります。
— Jeff（翻訳は西谷が担当しました。原文：Amazon API Gateway – Build and Run Scalable Application Backends）