Category: Amazon API Gateway*


AWS Lambda と Amazon API Gateway で Express アプリケーションを実行

ExpressNode.js のウェブフレームワークです。これを使用すると、「サーバーレス」ウェブサイトやウェブアプリケーション、API を簡単にデプロイできます。サーバーレス環境では、大方またはすべてのバックエンドロジックがステートレスのオンデマンドで実行します (詳細情報については Mike Roberts によるブログ「Serverless Architectures」をご覧ください)。今月初旬に公開したブログ (「API Gateway の更新 – API 開発を簡素化する新機能」) で紹介した新しい Amazon API Gateway 機能と AWS Lambda を併せて使用した場合、既存の Express アプリケーションをサーバーレスで実行することができます。API Gateway を使用すると API を中心に開発者のエコシステム構築を可能にする使用量プランなど追加機能を利用したり、キャッシュにより応答性と費用対効果に優れたアプリケーション構築を行うこともできます。

AWS は aws-serverless-express パッケージを提供することで Express アプリケーションから LambdaAPI Gateway への移行をお手伝いしています。このパッケージには実例が含まれています、ぜひご活用ください。

Express コードとアプリケーションを API GatewayLambda に移行する場合に利用できる 2 つのリソースをご紹介します。

Jeff;

API Gateway のアップデート – API 開発を簡素化する新機能

Amazon API Gateway で、堅牢でスケーラブルなアプリケーションバックエンドの構築と実行を簡単に素早く最近追加された使用プランで、API に関与するパートナー開発者のエコシステムを作成することができます。では、いくつかの用語を確認しながら始めましょう。

エンドポイント – HTTP リクエストに応答する URL (API Gateway によって提供される) です。これらのリクエストは、GET、PUT、POST などの HTTP メソッドを使用します。

リソース – エンドポイント内にある名前の付いたエンティティで、階層パスと呼ばれます。

動作 – 特定のリソース上で、HTTP リクエストに対応してコードが HTTP メソッドを使用して実行するアクションです。

統合 – エンドポイント、リソース、および HTTP メソッドと実際のアクションとの間でやり取りされる API Gateway マッピングです。

現在、API Gateway が提供する統合モデルを拡張して、新しい API エンドポイントの構築と既存のアプリケーションの移植を容易にするための複数の新しい機能をサポートしています。

greedy パス変数 – 一般的なパス ( /store/ など) に分類されるリクエストのグループのパスと動作を個別に指定する代わりに、パスへのすべてのリクエストを傍受してそれらを同じ機能にルーティングする、「greedy」ルートを指定できるようになりました。たとえば、単一の greedy パス (/store/{proxy+}) は、 /store/list-products, /store/add-product、および /store/delete-product) に対するリクエストを傍受します

ANY メソッド – それぞれの HTTP メソッド (GET、POST、PUT など) に個別の動作を指定する代わりに、catch-all ANY メソッドを使用して、すべてのリクエストに対して同じ統合動作を定義できるようになりました。

Lambda 関数統合 – 新しいデフォルトのマッピングテンプレートで、すべてのリクエストを Lambda 関数に送信し、戻り値を HTTP 応答に変換します。

HTTP エンドポイント統合 – もう 1 つの新しいデフォルトマッピングテンプレートで、すべてのリクエストを HTTP エンドポイントに送信し、その応答を変更せずに返します。これにより、わずかのセットアップ作業を行うだけで API Gateway を HTTP プロキシとして使用できます。

詳しい内容を見てみましょう。

Greedy パス変数
新しい e-コマース API を作成しているところだとしましょう。次のように開始します。

次に、 /store リソースを作成します。

次に、greedy パス変数を使用して、 /store 内のリソースに対するすべてのリクエストを傍受します (プロキシリソースとして設定されていることも確認する必要があります)。

なぜなら、 {proxy+} がサブリソースのリクエストを実際のリソースにルーティングするため、リソースパスの最終要素として使用される必要があるからです。これ以外の場所で使用するのは無意味です。 {proxy+} はあらゆる深さのパスに一致させることができます。上記の例は、 /store/us/clothing, /store/us/clothing/children などにも一致します。

プロキシは Lambda 関数または HTTP エンドポイントに接続できます。

ANY メソッド
HTTP メソッドでリソースとメソッドを定義するときに、それぞれの HTTP メソッドに対して個別の動作を指定する必要はなくなりました。

代わりに、ANY を選択して、リソース上のすべてのメソッドに対して同じ統合動作を使用することができます。

これにより、セットアップがより明確でシンプルかつ容易なものになります。お使いのコード (リソース上のすべてのメソッドに対する統合ポイント) は、メソッド名を調べて適切なアクションを実行します。

ANY メソッドは、上記のように greedy パス変数を使用すると自動的に作成されます。これは個別のリソースにも使用できます。メソッドを作成してその設定を変更するだけで、個別のメソッドの設定を上書きすることができます (DELETE を別の方法で使用するなど)。

Lambda 関数統合
Lambda 関数を使用して動作を実装するのがこれまでになく簡単になりました。新しい組み込みの Lambda 統合テンプレートは、HTTP リクエスト要素 (ヘッダー、クエリーパラメーター、ペイロード) を関数が直接使用できる形式にマップします。テンプレートは、関数の戻り値 (ステータスコード、ヘッダー、本文要素) を適切に構造化された HTTP 応答にマップします。

ドキュメントからコピーしたシンプルな関数を次に示します (「プロキシ統合のための Lambda 関数」を参照)。

この関数を次のように /store に接続します。

次に、それをデプロイして (デプロイに関する説明は示しません)、次のようにテストします。

関数が予想通りに実行され、コンソールに応答の本文、ヘッダーが表示され、ログファイルが作成されます。これが最初の部分です。

次に Lambda コンソールに移動して、使用した関数の CloudWatch ログを調べます。

ここにあるとおり、関数の 10 行目に黄色で強調表示したメッセージがあります。

このように、マッピングや変換の設定に時間をかけずに、API リソースで HTTP リクエストに応答する Lambda 関数を作成することができるようになります。事実、Lambda コンソールに新機能を追加したことで、このプロセスがいっそう簡単になりました。新しい Lambda 関数作成の最初のステップの 1 つとして、API Gateway エンドポイントを設定できるようになりました。

HTTP 関数統合
また、EC2 インスタンスまたはオンプレミスで実行されている HTTP エンドポイントに API リクエストを送信できるようにもなりました。もう一度繰り返しますが、マッピングや変換を設定する手間はもう必要なくなりました。代わりに、統合タイプHTTP を選択して HTTP プロキシ統合をクリックし、エンドポイントの名前を入力するだけです。

HTTP メソッドANY を選択すると、受信されたリクエストのメソッドがエンドポイントにそのまま送信されます。ANY を選択しなかった場合は、呼び出しの一部として示される値にメソッドが設定されます。

今すぐ利用可能
上記の機能は今すぐご利用いただけます。無料で今日からお使いいただけます。

Jeff;

Amazon API Gatewayのための利用プラン

昨年、開発者がモバイル、web、エンタープライズそしてIoTアプリケーション向けバックエンドWebサービスを構築できるようにするため、 Amazon API Gateway を紹介しました( Amazon API Gateway – Build and Run Scalable Application Backend to learn more を参照)。そのときから、AWSの顧客は  AWS LambdaAmazon Elastic Compute Cloud (EC2)、そしてAWSの外で稼働するサーバ上で実行されるAPIの実装を行ってきました。多くの場合、我々の顧客は彼らのAPIの上でアプリケーションを開発するパートナー開発者のエコシステムを作ることを計画しています。API Gateway を利用することで、我々の顧客は彼らの顧客それぞれにAPIキーを作成することが可能です。
これらのキーはAPIの各ユーザを特定し、キーの所有者がアクセス可能なサービスのセットとサービスのステージ(テスト、ベータそして本番といった環境)をAPI開発者がコントロールすることが可能です。APIはしばしばビジネス価値の代わりとして提供されるため、我々の顧客はAPIを構築し、それらへのアクセスを規制し、使用量に基づいて課金することによって、それらを収益化したいと我々に教えてくれました。
新しい利用プラン
このユースケースをサポートするため、API GatewayのUsage Planをご紹介します。この新機能により、開発者はAPIを構築、収益化することと、彼らの周りでエコシステムを作ることが可能になります。異なるレベルのアクセス(Bronze、Silver、Gold)、異なるカテゴリのユーザ(学生、個人、プロフェッショナルもしくはエンタープライズ)などに対して利用プランを作成することができます。プランは名前が付けられ、APIに対するアクセスの以下の面をコントロールします。

  • スロットリング – リクエストレート全体(平均秒間リクエスト)とバーストキャパシティ
  • クオータ – 一日あたり、週あたり、もしくは月あたりに可能なリクエストの数
  • API / ステージ – アクセス可能なAPIとAPIのステージ

仮に利用プランを使うことを選択するならば、あなたのAPIそれぞれがプランと紐付けられなければなりません。幸い、API Gatewayはデフォルトプランを作成し、それらにAPIを紐付けることができます。あなたがやろうとすることを確認するだけです。

デフォルトプランはスロットリングもクオータもありませんし、APIの挙動を変更しません。

利用プランの作成
Let’s step through the process of creating a Usage Plan.  利用プランの作成プロセスを一つずつ見ていきましょう。API Gatewayのコンソールを開き、Usage Plans、に移動しCreateをクリックしてください。 名前、説明を入力し、それからスロットリングとクオータのオプションを必要に応じて設定します。

スロットリングはToken Bucket モデルを使って実装されています。バケットはバースト値により示されるトークン数を保持するのに十分な大きさで、指定レートで新規トークンを取得します。各APIリクエストはバケットから1つのトークンを削除します。Token Bucketを使うことで、時折のバーストに対応するケイパビリティを持った安定したリクエストのストリームをサポートするAPIを持つことが可能になります。 2つの異なる方法でスロットリングを利用したり考えたりできます。ビジネス的な観点からは、それにより各顧客が生成可能なリクエストがどの程度かコントロールするために利用プランを使うことができます。技術的な観点からは、APIとして実装するために使われているサービスを過度なリクエストから遮断することができます。もし、それらのサービスがAWSの外で実装されていて、要求に合うようスケールできないならば、これは特に重要なことです。

Nextをクリックし、そしてそれから利用プランを通じてアクセスされるAPIとAPIステージを選択します。

プラン作成のために Next をクリックし、それからいくつかのAPIキーを追加します。既存のキーを追加する、もしくは新しいものを作成することが可能です。

料金プランを既存のAPIキーにアタッチすることを計画しているならば、キーは同じステージに関連する複数のプランを参照できないので最初にキーからデフォルトプランを削除しなければなりません。2つ目のブラウザタブ内でAPIキーを開き、デフォルトプランの右にある”x”をクリックすることでこれができます。

(プランにキーを追加しているタブ上で)1つもしくは複数のAPIキー(APIのサブスクライバを示す)を選択し、Doneをクリックします。

あなたのユーザ(サブスクライバ)がAPIキーを使ってAPIコールを開始したら間もなく、プランで指定された通りに彼らの利用量はスロットルされ、制限されます。Usageをクリックすることでいつでも彼らの利用量を見ることができます。

クオータはリアルタイムに適用され守られます。利用量のデータは最大30分遅れます。

Export Usage Dataをクリックすることで利用量のデータはダウンロード可能です。

その後、望み通りにデータを処理し、分析することが可能です。例えば、コールごとベースでサブスクライバに請求書発行することが可能です。

サブスクライバの一つがAPIを非常によく利用していて、期間内のクオータに近づきつつある場合、利用プランを変更することなく彼らに利用を増やすことを許可することができます。Extensionをクリックして、期間内の残りを用意するために許可するリクエスト数を入力するだけです。

利用プランを使用する
先だって言及したように、利用量に対する請求書発行やAPIを中心としたエコシステムを作るのに利用プランを使えます。

アクセスをコントロールしたり、監視することができ、必要に応じて選択的に特別なアクセスを個別のサブスクライバに許可することができます。例えば、特定のAPIステージに対するアクセスを許可するAPIキーと利用プランを作成することができます。多くのサブスクライバは本番ステージへのアクセスが必要です。少しのサブスクライバは開発もしくはベータテストのステージへのアクセスが必要です。

まとめの前に、APIキーは識別のためであり、認証のためではないことを指摘しておきます。キーはリクエストの署名のためには使われず、セキュリティ機構として使うべきではありません(これは完全に Cognito Your User Poolsのユースケースです)。

今すぐ利用可能
この機能は今すぐ利用可能で、本日より使う始められます。


Jeff;(翻訳はSA西谷が担当しました。原文:New – Usage Plans for Amazon API Gateway