このホワイトペーパーは過去の参考用です。一部のコンテンツは古く、一部のリンクは使用できない場合があります。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# サンプルアーキテクチャパターン
<a name="sample-architecture-patterns"></a>

 API Gateway と をロジック層 AWS Lambda として使用して、一般的なアーキテクチャパターンを実装できます。このホワイトペーパーには、 AWS Lambdaベースのロジック層を活用する最も一般的なアーキテクチャパターンが含まれています。
+  **モバイルバックエンド -** モバイルアプリケーションは API Gateway および Lambda と通信してアプリケーションデータにアクセスします。このパターンは、サーバーレス AWS リソースを使用してプレゼンテーション階層リソース (デスクトップクライアント、EC2 で実行されているウェブサーバーなど) をホストしない汎用 HTTPS クライアントに拡張できます。
+  **単一ページアプリケーション **- Amazon S3 および CloudFront でホストされている単一ページアプリケーションは、API Gateway と通信し AWS Lambda 、アプリケーションデータにアクセスします。
+  **ウェブアプリケーション ** – ウェブアプリケーションは、 と AWS Lambda API Gateway をビジネスロジックに使用する、イベント駆動型の汎用ウェブアプリケーションのバックエンドです。また、DynamoDB をデータベースとして使用し、Amazon Cognito をユーザー管理に使用します。すべての静的コンテンツは Amplify を使用してホストされます。

 このホワイトペーパーでは、これら 2 つのパターンに加えて、一般的なマイクロサービスアーキテクチャへの Lambda と API Gateway の適用性について説明します。マイクロサービスアーキテクチャは、標準的な 3 層アーキテクチャではありませんが、アプリケーションコンポーネントを切り離し、相互に通信するステートレスで個々の機能ユニットとしてデプロイする一般的なパターンです。

# モバイルバックエンド
<a name="mobile-backend"></a>

![\[サーバーレスモバイルバックエンドのアーキテクチャパターン\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/arch-pattern-serverless-mobile-backend.png)


* サーバーレスモバイルバックエンドのアーキテクチャパターン *

* 表 1 - モバイルバックエンド階層コンポーネント *


|  Tier  |  コンポーネント  | 
| --- | --- | 
|  プレゼンテーション  |  ユーザーデバイスで実行されているモバイルアプリケーション。 | 
|  [Logic] (ロジック)  |   Amazon API Gateway と AWS Lambda。  このアーキテクチャは、3 つの公開サービス (`/tickets`、`/shows`、) を示しています`/info`。API Gateway エンドポイントは [Amazon Cognito ユーザープール](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)によって保護されます。この方法では、ユーザーは Amazon Cognito ユーザープールにサインインし (必要に応じてフェデレーティッドサードパーティーを使用）、API Gateway コールの認可に使用されるアクセストークンと ID トークンを受け取ります。  各 Lambda 関数には、適切なデータソースへのアクセスを提供する独自の Identity and Access Management (IAM) ロールが割り当てられます。  | 
|  [データ]  |   DynamoDB は `/tickets`および `/shows`サービスに使用されます。  Amazon RDS は `/info`サービスに使用されます。この Lambda 関数は、 AWS Secrets Manager から Amazon RDS 認証情報を取得し、Elastic Network Interface を使用してプライベートサブネットにアクセスします。  | 

# 単一ページアプリケーション
<a name="single-page-application"></a>

![\[AWS architecture diagram showing interactions between services like CloudFront, S3, Lambda, and DynamoDB.\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/single-page-application.png)


* サーバーレスシングルページアプリケーションのアーキテクチャパターン *

* 表 2 - 単一ページのアプリケーションコンポーネント *


|  Tier  |  コンポーネント  | 
| --- | --- | 
|  プレゼンテーション  |   CloudFront によって配信される Amazon S3 でホストされる静的ウェブサイトコンテンツ。  AWS Certificate Manager では、カスタム SSL/TLS 証明書を使用できます。  | 
|  [Logic] (ロジック)  |   API Gateway と AWS Lambda。  このアーキテクチャは、3 つの公開サービス (`/tickets`、`/shows`、) を示しています`/info`。API Gateway エンドポイントは Lambda オーソライザーによって保護されます。この方法では、ユーザーはサードパーティーの ID プロバイダーを介してサインインし、アクセストークンと ID トークンを取得します。これらのトークンは API Gateway 呼び出しに含まれ、Lambda オーソライザーはこれらのトークンを検証し、API 開始アクセス許可を含む IAM ポリシーを生成します。  各 Lambda 関数には、適切なデータソースへのアクセスを提供する独自の IAM ロールが割り当てられます。  | 
|  [データ]  |   Amazon DynamoDB は、 `/tickets`および `/shows`サービスに使用されます。  Amazon ElastiCache は、データベースのパフォーマンスを向上させるために `/shows`サービスによって使用されます。キャッシュミスは DynamoDB に送信されます。  Amazon S3 は、 で使用される静的コンテンツをホストするために使用されます`/info service`。  | 

# ウェブアプリケーション
<a name="web-application"></a>

![\[AWS クラウド architecture diagram showing client interaction with various AWS のサービス.\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/web-application.png)


* ウェブアプリケーションのアーキテクチャパターン *

* 表 3 - ウェブアプリケーションコンポーネント *


|  Tier  |  コンポーネント  | 
| --- | --- | 
|  プレゼンテーション  |   フロントエンドアプリケーションは、create-react-app などの React ユーティリティによって生成されるすべての静的コンテンツ (HTML、CSS、JavaScript、イメージ) です。Amazon CloudFront は、これらのすべてのオブジェクトをホストします。ウェブアプリケーションを使用すると、すべてのリソースがブラウザにダウンロードされ、そこから実行が開始されます。ウェブアプリケーションは、 APIs を呼び出すバックエンドに接続します。  | 
|  [Logic] (ロジック)  |   ロジックレイヤーは、API Gateway REST APIs。  このアーキテクチャは、複数の公開サービスを示しています。アプリケーションの異なる側面を処理する複数の異なる Lambda 関数があります。Lambda 関数は API Gateway の背後にあり、API URL パスを使用してアクセスできます。 ユーザー認証は、Amazon Cognito ユーザープールまたはフェデレーティッドユーザープロバイダーを使用して処理されます。API Gateway はAmazon Cognito とのすぐに使える統合を使用します。ユーザーが認証された後にのみ、クライアントは JSON Web Token (JWT) トークンを受け取り、API コールを行うときに使用する必要があります。 各 Lambda 関数には、適切なデータソースへのアクセスを提供する独自の IAM ロールが割り当てられます。  | 
|  [データ]  |   この例では、DynamoDB がデータストレージに使用されますが、ユースケースと使用シナリオに応じて、他の専用の Amazon データベースまたはストレージサービスを使用できます。  | 

# Lambda を使用したマイクロサービス
<a name="microservices-with-lambda"></a>

![\[AWS クラウド architecture with API Gateways and Lambda functions across two accounts.\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/images/microservices-with-lambda.png)


* Lambda を使用したマイクロサービスのアーキテクチャパターン *

 マイクロサービスアーキテクチャパターンは、一般的な 3 層アーキテクチャに縛られるわけではありませんが、この一般的なパターンは、サーバーレスリソースの使用から大きなメリットを得ることができます。

 このアーキテクチャでは、各アプリケーションコンポーネントが分離され、個別にデプロイおよび運用されます。Amazon API Gateway で作成された API と、その後 によって起動される関数は AWS Lambda、マイクロサービスを構築するために必要なすべてです。チームはこれらのサービスを使用して、必要な粒度レベルまで環境を切り離してフラグメント化できます。

 一般的に、マイクロサービス環境では、新しいマイクロサービスの作成に伴うオーバーヘッドの繰り返し、サーバーの密度と使用率の最適化に関する問題、複数のマイクロサービスの複数のバージョンを同時に実行する複雑さ、多くの個別のサービスと統合するためのクライアント側のコード要件の急増などの問題が発生する可能性があります。

 サーバーレスリソースを使用してマイクロサービスを作成すると、これらの問題は解決しにくくなり、場合によっては単に消えます。サーバーレスマイクロサービスパターンは、後続の各マイクロサービスの作成の障壁を低くします (API Gateway では、既存の APIs、他のアカウントでの Lambda 関数の使用も許可されます）。サーバー使用率の最適化は、このパターンには関係しなくなりました。最後に、Amazon API Gateway はプログラムで生成されたクライアント SDKs を多くの一般的な言語で提供し、統合オーバーヘッドを削減します。