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

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

# 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 を多くの一般的な言語で提供し、統合オーバーヘッドを削減します。