Introduction to Amazon API Gateway (Japanese)

概要

このラボでは、シンプルな FAQ マイクロサービスを作成します。このマイクロサービスでは、AWS Lambda 関数を呼び出す Amazon API Gateway エンドポイントを使用して、ランダムな質問と回答のペアを含む JSON オブジェクトが返されます。このマイクロサービスのアーキテクチャパターンは以下のとおりです。

取り上げるトピック

このラボを修了すると、次のことができるようになります。

• AWS Lambda 関数を作成する
• Amazon API Gateway エンドポイントを作成する
• Amazon CloudWatch で API Gateway と Lambda のデバッグを実行する

前提条件

ラボを実施するうえでプログラミングやアプリケーション開発の経験が役に立つ場合がありますが、必須ではありません。ただし、このラボを受講する前に Introduction to AWS Lambda セルフペースラボを受講しておく必要があります。

AWS のその他のサービス

このラボに必要なサービス以外の AWS のサービスは、このラボへのアクセス中 IAM ポリシーによって無効にされています。また、このラボで使用されるサービスの機能はラボに必要なものに限定されており、場合によってはラボの設計の観点から意図的にさらに制限されています。このラボガイドに指定されていないサービスを使用したりアクションを実行したりすると、エラーが発生することがあります。

テクニカルコンセプト

マイクロサービスアーキテクチャ

_「マイクロサービスアーキテクチャ様式は、1 つのアプリケーションを小規模なサービスのスイートとして開発するアプローチです。各サービスは個別のプロセスで実行され、軽量なメカニズム（多くの場合 HTTP リソース API）で通信を行います。これらのサービスは、ビジネスに必要な機能に合わせて構築され、完全に自動化された仕組みで個別にデプロイできます。さらに、これらのサービスは異なるプログラミング言語で記述され、異なるデータストレージテクノロジーを使用している場合があり、中央集中管理は最小限となります」- James Lewis および Martin Fowler

マイクロサービスアーキテクチャの考え方は、大規模で複雑なシステムを独立、分離した、管理や拡張が簡単なサービスに分割するということです。これにより、開発者は、拡張性、可用性、保守性などの設計上の主要な要件に対応できます。

Amazon API Gateway と AWS Lambda でウェブサービスを組み合わせて使用することにより、複雑なソフトウェアシステムの基盤となるマイクロサービスのスイートを簡単に構築、配信、メンテナンスできます。

このラボでは、より大規模なシステムの一部となるシンプルなマイクロサービスを開発、デプロイ、デバッグする方法を学習します。このラボは 2 つの要素から構成されています。RESTful API と、ユーザーがエンドポイントを使用する際に実行される関数です。

アプリケーションプログラミングインターフェイス (API)

アプリケーションプログラミングインターフェイスは、開発者がアプリケーションとやり取りする方法を定義する命令のセットです。API の背後にある考え方は、アプリケーションによって提供されるさまざまなサービスとやり取りするための、標準化された方法を確立することです。API はソフトウェアデプロイキット (SDK) と合わせて使用されます。SDK は、開発者が API ベースのダウンストリームアプリケーションを簡単に作成できるようにするためのツールの集合です。

API ファーストの戦略

ソフトウェアを開発する多くの組織では API ファーストの戦略を採用しており、スタック内の各サービスが常に優先的に API としてリリースされます。サービスを設計する際に、そのサービスを利用する可能性があるさまざまなアプリケーションをすべて把握することは困難です。例えば、このラボで扱う FAQ サービスは、外部のウェブサイトに FAQ ページを埋め込む場合に便利です。一方で、クラウドを活用した教育プログラムを提供する企業が、フラッシュカードやトレーニングドキュメントなどのトレーニング用資料に FAQ を含めることを検討することも考えられます。単に静的なウェブサイトの場合、このような教育企業が使える取り込みプロセスの構築は非常に困難です。標準化された形式で利用できる API を提供することにより、マイクロサービスによってサービス関連のエコシステムの開発が可能になり、当初は考慮されなかったユースケースを実現できます。

RESTFUL API

Representational State Transfer (REST) のアーキテクチャには、次の 6 つの制約があります。

• クライアント - サーバーモデルを介して課題を分離する
• 状態はクライアントに完全に保存され、クライアントとサーバー間の通信はステートレスである
• クライアントがデータをキャッシュしてネットワークの効率性を向上させる
• サーバーとクライアント間に統一インターフェイス（API 形式）がある
• システムが複雑になるとレイヤーが導入される。RESTful コンポーネントには複数のレイヤーが実装される場合がある
• コードオンデマンドのパターンに従う。コードは即座にダウンロードでき（ここでは Lambda に実装）、クライアントを更新せずに変更できる

このラボは RESTful モデルに従っています。クライアントはバックエンドの Lambda 関数（サーバー）にリクエストを送信します。サービスのロジックは Lambda 関数内にカプセル化され、クライアントが使用できる統一インターフェイスが提供されます。

RESTFUL API を構築するためのベストプラクティス

API を構築する主な目的は、一連のサービスに関連する革新的なエコシステムを確立することです。そのため、API は直感的で使いやすいように作ることが重要です。一般的な命名方法とメソッドのスキームを以下に示します。

オペレーションURL関数GET/questionsすべての質問を返すGET/questions/17質問 17 を返すPOST/questions新しい質問を作成するPUT/questions/17質問 17 を更新するPATCH/questions/17質問 17 を一部更新するDELETE/questions/17質問 17 を削除する

特定の質問を取得する場合、API エンドポイントは /questions/name ではなく、/questions/identifier となります。これにより、API の設計者は、/questions エンドポイントを使用して、複数の質問（すべての質問も可能）を返す機能を提供できます。また、/questions/identifier を使用すると、単一レコードの回答を返すこともできます。詳細については、このラボガイドの最後にある「その他のリソース」のセクションを参照してください。

RESTful API の参考例を挙げます。

• AWS Elemental MediaConvert
• Spotify
• Twitch
• Netflix Genie
• Slack

AMAZON API GATEWAY と AWS LAMBDA

Amazon API Gateway を使用したマイクロサービスは、定義済みリソース、API Gateway の関連メソッド（GET、POST、PUT など）、バックエンドターゲットで構成されます。このラボでは、バックエンドターゲットは Lambda 関数です。ただし、別の HTTP エンドポイント（サードパーティの API またはリッスンしているウェブサーバー）、AWS のサービスプロキシ、Mock 統合のいずれかをバックエンドターゲットにして、プレースホルダーとして使用することもできます。

AMAZON API GATEWAY

API Gateway は AWS が提供するマネージド型サービスで、API の作成、デプロイ、メンテナンスを容易にします。API Gateway には次のような特徴があります。

• 受信する API リクエストの本文とヘッダーを、バックエンドシステムに適合するように変換する
• 送信する API 応答の本文とヘッダーを、API 要件に適合するように変換する
• AWS Identity and Access Management を使用して API アクセスを制御する
• サードパーティによる開発のために API キーを作成および有効化する
• Amazon CloudWatch との統合を有効にして API モニタリングを可能にする
• Amazon CloudFront 経由で API 応答をキャッシュして応答時間を短縮する
• 複数のステージに対して API をデプロイして、開発、テスト、本番環境間の差別化とバージョニングを容易にする
• カスタムドメインを API に接続する
• API リクエストと API 応答の変換を標準化するためのモデルを定義する

AMAZON API GATEWAY と AWS LAMBDA の用語

リソース: URL エンドポイントとパスで表されます（例: api.mysite.com/questions）。HTTP メソッドをリソースと関連付け、各メソッドに異なるバックエンドターゲットを定義できます。マイクロサービスアーキテクチャでは、リソースはシステム内の単一のマイクロサービスを表します。

• メソッド: API Gateway では、メソッドはリソースパスと、GET、POST、DELETE などの HTTP 動詞の組み合わせで識別されます。
• メソッドリクエスト: API Gateway のメソッドリクエスト設定では、メソッドの許可の設定を保存し、クライアントから受信する URL クエリ文字列パラメータと HTTP リクエストヘッダーを定義します。
• 統合リクエスト: 統合リクエスト設定では、メソッドで使用するバックエンドターゲットを定義します。また、マッピングテンプレートを定義して、受信するリクエストをバックエンドターゲットで使用する形に変換することもできます。
• 統合レスポンス: 統合レスポンス設定では、バックエンドターゲットからのレスポンスと API Gateway のメソッドレスポンスとのマッピングを定義します。また、バックエンドターゲットから返されるデータを、エンドユーザーやアプリケーションで使用する形に変換することもできます。
• メソッドレスポンス: メソッドレスポンス設定では、メソッドレスポンスタイプと、そのヘッダーとコンテンツのタイプを定義します。
• モデル: API Gateway では、モデルによって、一部のデータの形式（スキーマまたはシェイプとも呼ばれる）が定義されます。モデルを作成して使用すると、マッピングテンプレートをより簡単に作成できます。API Gateway は、主に JavaScript Object Notation (JSON) 形式のデータと連携するように設計されています。そのため、API Gateway では JSON スキーマを使用して、データの適切なスキーマを定義します。
• ステージ: API Gateway では、ステージによって、API デプロイにアクセスするためのパスが定義されます。これは、バージョン間の区別や、開発環境と本番環境のエンドポイントの区別などのために一般的に使用されています。
• 設計図: Lambda 設計図は、新しい Lambda 関数を作成する基本として使用できる Lambda 関数の例です。