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

# でのシンプルなマイクロサービスアーキテクチャ AWS
<a name="simple-microservices-architecture-on-aws"></a>

 一般的なモノリシックアプリケーション は、プレゼンテーションレイヤー、アプリケーションレイヤー、データレイヤーのさまざまなレイヤーで構成されます。一方、 マイクロサービスアーキテクチャは、技術レイヤーではなく、特定のドメインに応じて機能をまとまりのある*垂直*方向に分離します。図 1 は、 の一般的なマイクロサービスアプリケーションのリファレンスアーキテクチャ を示しています AWS。

![\[の一般的なマイクロサービスアプリケーションを示す図 AWS\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/microservices-on-aws/images/typical-microservices-application.png)


# [ユーザーインターフェイス]
<a name="user-interface"></a>

 最新のウェブアプリケーションは、多くの場合、JavaScript フレームワークを使用して、バックエンド APIs。これらの APIsは通常、表現状態転送 (REST) または RESTful APIs、または GraphQL APIs。静的ウェブコンテンツは、Amazon Simple Storage Service ([Amazon S3](https://aws.amazon.com/s3/)) と Amazon CloudFront を使用して提供できます。 [Amazon CloudFront](https://aws.amazon.com/cloudfront/) 

# マイクロサービス
<a name="microservices"></a>

 APIsはアプリケーションロジックのエントリポイントであるため、マイクロサービスの*フロントドア*と見なされます。通常、RESTful ウェブサービス API または GraphQL APIsが使用されます。これらの APIs、クライアント呼び出しを管理および処理し、トラフィック管理、リクエストフィルタリング、ルーティング、キャッシュ、認証、認可などの機能を処理します。

## マイクロサービス実装
<a name="microservices-implementations"></a>

 AWS は、コンテナオーケストレーションエンジンの選択肢として Amazon ECS や Amazon EKS、ホスティングオプションとして AWS Fargate EC2 など、マイクロサービスを開発するための構成要素を提供します。 AWS Lambda は、マイクロサービスを構築するもう 1 つのサーバーレス方法です AWS。これらのホスティングオプションの選択は、基盤となるインフラストラクチャを管理するためのお客様の要件によって異なります。

 AWS Lambda を使用すると、コードをアップロードし、その実行を高可用性で自動的にスケーリングおよび管理できます。これにより、インフラストラクチャ管理が不要になるため、迅速に移行し、ビジネスロジックに集中できます。Lambda は[複数のプログラミング言語](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)をサポートしており、他の AWS サービスによってトリガーすることも、ウェブやモバイルアプリケーションから直接呼び出すこともできます。

 コンテナベースのアプリケーションは、移植性、生産性、効率性により人気が高まっています。 AWS は、コンテナを構築、デプロイ、管理するためのいくつかのサービスを提供します。
+  [App2Container](https://aws.amazon.com/app2container/) は、Java および .NET ウェブアプリケーションをコンテナ形式に移行およびモダナイズするためのコマンドラインツールです。 AWS A2C は、ベアメタル、仮想マシン、Amazon Elastic Compute Cloud (EC2) インスタンス、またはクラウドで実行されているアプリケーションのインベントリを分析して構築します。
+  Amazon Elastic Container Service ([Amazon ECS](https://aws.amazon.com/ecs/)) と Amazon Elastic Kubernetes Service ([Amazon EKS](https://aws.amazon.com/eks/)) はコンテナインフラストラクチャ を管理し、コンテナ化されたアプリケーションの起動と保守を容易にします。  
  +  Amazon EKS は、 AWS クラウドおよびオンプレミスのデータセンター ([Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/)) で Kubernetes を実行するためのマネージド Kubernetes サービスです。これにより、クラウドサービスがオンプレミス環境に拡張され、低レイテンシー、ローカルデータ処理、高データ転送コスト、またはデータレジデンシー要件に対応できるようになります ([Amazon EKS Anywhere によるハイブリッドコンテナワークロードの実行](https://d1.awsstatic.com/kubernetes-pmm/eks-a/getting-started/AWS_Whitepaper_Running_Hybrid_Container_Workloads_with_Amazon_EKS_Anywhere.pdf)」に関するホワイトペーパーを参照）。EKS では、Kubernetes コミュニティのすべての既存のプラグインとツールを使用できます。
  +  Amazon Elastic Container Service (Amazon ECS) は、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを簡素化するフルマネージドコンテナオーケストレーションサービスです。お客様は、シンプルさと AWS サービスとの深い統合のために ECS を選択します。

 詳細については、ブログ[「Amazon ECS vs Amazon EKS: AWS コンテナサービスの理解](https://aws.amazon.com/blogs/containers/amazon-ecs-vs-amazon-eks-making-sense-of-aws-container-services/)」を参照してください。
+  [AWS App Runner](https://aws.amazon.com/apprunner/) はフルマネージド型のコンテナアプリケーションサービスであり、コンテナ化されたウェブアプリケーションと API サービスを構築、デプロイ、実行できます。インフラストラクチャやコンテナの経験は必要ありません。
+  [AWS Fargate](https://aws.amazon.com/fargate/)サーバーレスコンピューティングエンジンである は、Amazon ECS と Amazon EKS の両方と連携して、コンテナアプリケーションのコンピューティングリソースを自動的に管理します。
+  [Amazon ECR](https://aws.amazon.com/ecr/) は、高性能ホスティングを提供するフルマネージドコンテナレジストリであるため、アプリケーションイメージとアーティファクトをどこにでも確実にデプロイできます。

# 継続的インテグレーションと継続的デプロイ (CI/CD)
<a name="continuous-integration-and-continuous-deployment-cicd"></a>

 継続的インテグレーションと継続的デリバリー (CI/CD) は、迅速なソフトウェア変更のための DevOps イニシアチブ の重要な部分です。 は、マイクロサービス用の CI/CD を実装するためのサービス AWS を提供しますが、詳細な説明は本書の範囲外です。詳細については、ホワイトペーパーの[「継続的インテグレーションと継続的デリバリーの実践 AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)」を参照してください。

# プライベートネットワーク設定
<a name="private-networking"></a>

AWS PrivateLink は、仮想プライベートクラウド (VPC) とサポートされているサービス間のプライベート接続を許可することで、マイクロ AWS サービスのセキュリティを強化するテクノロジーです。マイクロサービストラフィックを分離して保護し、パブリックインターネットを経由しないようにします。これは、PCI や HIPAA などの規制に準拠するために特に役立ちます。

# データストア
<a name="data-store"></a>

 データストアは、マイクロサービスに必要なデータを永続化するために使用します。セッションデータの一般的なストアは、Memcached や Redis. AWS offers などのインメモリキャッシュであり、両方のテクノロジーをマネージド [Amazon ElastiCache](https://aws.amazon.com/elasticache/) サービスの一部として提供します。

 アプリケーションサーバーとデータベース間にキャッシュを配置することは、データベースの読み取り負荷を軽減するための一般的なメカニズムです。これにより、より多くの書き込みをサポートするためにリソースを使用できるようになります。キャッシュはレイテンシーを改善することもできます。

 リレーショナルデータベースは、構造化データとビジネスオブジェクトを保存するために依然として非常に人気があります。 は、 [Amazon Relational Database Service](https://aws.amazon.com/rds/) (Amazon RDS) を介してマネージドサービスとして 6 つのデータベースエンジン (Microsoft SQL Server、Oracle、MySQL、MariaDB、PostgreSQL、Amazon [Aurora](https://aws.amazon.com/rds/aurora/)) AWS を提供しています。

 ただし、リレーショナルデータベースは無限スケール用に設計されていないため、多数のクエリをサポートする手法を適用するのが難しく、時間がかかります。

 NoSQL データベースは、リレーショナルデータベースの一貫性よりもスケーラビリティ、パフォーマンス、可用性を優先するように設計されています。NoSQL データベースの重要な要素の 1 つは、通常、厳密なスキーマを適用しないことです。データは、水平方向にスケーリングできるパーティションに分散され、パーティションキーを使用して取得されます。

 個々のマイクロサービスは 1 つのことをうまく実行するように設計されているため、通常、NoSQL の永続性に適したシンプルなデータモデルがあります。NoSQL データベースにはリレーショナルデータベースとは異なるアクセスパターンがあることを理解することが重要です。たとえば、テーブルを結合することはできません。これが必要な場合は、ロジックをアプリケーションに実装する必要があります。 [Amazon DynamoDB ](https://aws.amazon.com/dynamodb/) を使用して、任意の量のデータを保存および取得し、任意のレベルのリクエストトラフィックを処理できるデータベーステーブルを作成できます。DynamoDB は 1 桁ミリ秒のパフォーマンスを提供しますが、マイクロ秒単位の応答時間を必要とする特定のユースケースがあります。 [DynamoDB Accelerator](https://aws.amazon.com/dynamodb/dax/) (DAX) は、データにアクセスするためのキャッシュ機能を提供します。

 DynamoDB には、実際のトラフィックに応じてスループット容量を動的に調整する自動スケーリング機能も用意されています。ただし、アプリケーションのアクティビティの急増が短いため、キャパシティプランニングが困難または不可能な場合があります。このような状況では、DynamoDB はオンデマンドオプションを提供し、pay-per-requestを提供します。DynamoDB オンデマンドは、キャパシティプランニングなしで 1 秒あたり数千件のリクエストを即座に処理できます。

 詳細については、[分散データ管理](distributed-data-management.md)「」および[「データベースの選択方法](https://aws.amazon.com/startups/learn/maximizing-performance-with-aws-databases)」を参照してください。

# オペレーションの簡素化
<a name="simplyfing-operations"></a>

 マイクロサービスの実行、保守、モニタリングに必要な運用作業をさらに簡素化するために、 完全なサーバーレスアーキテクチャを使用できます。

## Lambda ベースのアプリケーションのデプロイ
<a name="deploying-lambda-based-applications"></a>

 Lambda コードをデプロイするには、`zip`ファイルアーカイブをアップロードするか、有効な Amazon ECR イメージ URI を使用してコンソール UI を介してコンテナイメージを作成してアップロードします。ただし、Lambda 関数が複雑になった場合、つまりレイヤー、依存関係、およびアクセス許可がある場合、UI を介したアップロードはコード変更では扱いにくくなる可能性があります。

AWS CloudFormation と  AWS Serverless Application Model ([AWS SAM](https://github.com/awslabs/serverless-application-model)) AWS Cloud Development Kit (AWS CDK)、または Terraform を使用すると、サーバーレスアプリケーションを定義するプロセスが効率化されます。CloudFormation でネイティブにサポートされている AWS SAM は、サーバーレスリソースを指定するためのシンプルな構文を提供します。 AWS Lambda レイヤー は、複数の Lambda 関数間で共有ライブラリを管理し、関数フットプリントを最小限に抑え、テナント対応ライブラリを一元化して、開発者エクスペリエンスを向上させます。Lambda SnapStart for Java は、レイテンシーの影響を受けやすいアプリケーションの起動パフォーマンスを向上させます。

 デプロイするには、CloudFormation テンプレートでリソースとアクセス許可ポリシーを指定し、デプロイアーティファクトをパッケージ化し、テンプレートをデプロイします。 AWS CLI ツールである SAM Local では、Lambda にアップロードする前にサーバーレスアプリケーションの開発、テスト、分析をローカルで行うことができます。

 IDE、 AWS CodeBuild、 AWS CodePipeline などのツールとの統合により AWS CodeDeploy、SAM AWS Cloud9 ベースのアプリケーションの作成、テスト、デバッグ、デプロイが効率化されます。

 次の図は、CloudFormation および AWS CI/CD ツールを使用した AWS Serverless Application Model リソースのデプロイを示しています。

![\[AWS Serverless Application Model (AWS SAM) を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/microservices-on-aws/images/aws-sam.png)


## マルチテナンシーの複雑さの抽象化
<a name="abstracting-multi-tenancy-complexities"></a>

 SaaS プラットフォームなどのマルチテナント環境では、マルチテナンシーに関連する複雑さを合理化し、開発者が機能と機能の開発に集中できるようにすることが重要です。これは、クロスカットの問題に対処するための共有ライブラリを提供する [AWS Lambda Layers](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) などのツールを使用して実現できます。このアプローチの理論的根拠は、共有ライブラリとツールを正しく使用すると、テナントコンテキストを効率的に管理することです。  

 ただし、複雑でリスクがあるため、ビジネスロジックのカプセル化にまで拡張すべきではありません。共有ライブラリの根本的な問題は、更新に伴う複雑さが増し、標準コードの重複に比べて管理が困難になることです。したがって、最も効果的な抽象化を求めるには、共有ライブラリの使用と重複のバランスを取ることが重要です。

## API 管理
<a name="api-management"></a>

 APIs の管理には時間がかかる場合があります。特に、複数のバージョン、開発サイクルのステージ、認可、スロットリングやキャッシュなどのその他の機能を検討する場合は、時間がかかります。[API Gateway](https://aws.amazon.com/api-gateway/) とは別に、API 管理に ALB (Application Load Balancer) または NLB (Network Load Balancer) を使用するお客様もいます。Amazon API Gateway は、RESTful APIs。これにより、プログラムで APIs を作成し、バックエンドサービス、認可とアクセスコントロール、レート制限、キャッシュ、モニタリング、トラフィック管理からデータ、ビジネスロジック、機能にアクセスするための「フロントドア」として機能し、サーバーを管理することなく APIsを実行できます。

 図 3 は、API Gateway が API コールを処理し、他のコンポーネントとやり取りする方法を示しています。モバイルデバイス、ウェブサイト、またはその他のバックエンドサービスからのリクエストは、レイテンシ ー を短縮し 、最適な ユーザーエクスペリエンスを提供するために、最も近い CloudFront Point of Presence (PoP) にルーティングされます。

![\[API Gateway コールフローを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/microservices-on-aws/images/api-gateway-call-flow.png)