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

# フェーズ 3: ウェーブベースの実装
<a name="wave-based-implementation-phase"></a>

ウェーブベースの実装フェーズでは、レガシーシステムの特定の機能を置き換える AWS マイクロサービスを選択し、それらのサービスをウェーブで実装することに重点を置いています。以下の推奨事項は、最初にモダナイズする機能に優先順位を付け、本番環境に変更を段階的にロールアウトするのに役立ちます。

**重要**  
以下のいずれかのウェーブグループを実装する前に、主要なステークホルダーに相談し、承認を得てください。これらのグループを作成するときは、機能マトリックスのスコアリング基準のみに依存するのではなく、反復的なアプローチを使用することをお勧めします。

**主な重点項目**
+ 一連の優先順位付け基準を使用して、依存関係の数、ビジネスの優先度、複雑さのレベルに基づいて、機能を 3 つの実装ウェーブに分類する
+ レガシー IT システムと同じ機能を提供できるクラウドネイティブ AWS マイクロサービスの選択
+ 選択した AWS マイクロサービスの設定に必要な基盤 AWS インフラストラクチャの設定
+ 本番環境に変更を段階的にウェーブでロールアウトする

## ステップ 1: 依存関係の数、ビジネスの優先度、複雑さのレベルに基づいて機能を整理する
<a name="organize-capabilities"></a>

主要なステークホルダーからの入力と、機能マトリックスの加重スコアを使用して、レガシーシステムの機能を次の 3 つの主要なグループに整理します。

**注記**  
ほとんどの実装では、多くのサブウェーブグループを使用する必要があります。このガイドでは、あくまで例として、3 つの主要なウェーブグループの概要を説明します。

**ウェーブ 1 の機能**


|  |  | 
| --- |--- |
| **依存関係の数** | なしまたは非常に低い | 
| **ビジネスの優先度** | 低 | 
| **複雑さ** | 低 | 

** **

**ウェーブ 2 の機能**


|  |  | 
| --- |--- |
| **依存関係の数** | 低～中 | 
| **ビジネスの優先度** | 低～中 | 
| **複雑さ** | 中 | 

 

**ウェーブ 3 の機能**


|  |  | 
| --- |--- |
| **依存関係の数** | 高 | 
| **ビジネスの優先度** | 中～高 | 
| **複雑さ** | 中～高 | 

## ステップ 2: レガシー IT システムの機能を置き換える AWS マイクロサービスを選択する
<a name="select-aws-services"></a>

主要なステークホルダーと協力して、モダナイズする機能の順序を確認して確定する反復プロセスを使用します。次に、マイクロサービスを選択して AWS 、レガシー IT システムの機能を置き換えます。

以下は、各ウェーブグループに含まれる機能を置き換えるために頻繁に使用できる AWS マイクロサービスの例です。

**Wave 1 AWS マイクロサービスの例**
+ AWS Lambda
+ Amazon Simple Queue Service (Amazon SQS)
+ Amazon Simple Notification Service (Amazon SNS)
+ Amazon API Gateway

**注記**  
Wave 1 の機能は、ストラングラー移行パターンを使用して最小限の AWS 基本サービスと統合できます。詳細については、 AWS ブログの[「Strangler パターンを使用してオンプレミスのレガシーワークロードをシームレスに移行する](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/)」を参照してください。

**Wave 2 AWS マイクロサービスの例**
+ AWS Step Functions ベースのワークフロー
+ 目的に合ったデータベース (Aurora PostgreSQL への移行)
+ AWS SaaS ファクトリ

**注記**  
ウェーブ 2 の機能には通常、PostgreSQL 互換データベースへの移行など、ある程度のデータベースモダナイズが含まれます。ハイブリッドクラウドソリューションを維持するには、通常、レガシーデータベースと新しいクラウドネイティブデータベースの同期も必要です。

**Wave 3 AWS マイクロサービスの例**
+ AWS Fargate
+ Amazon Textract、Amazon Comprehend、Amazon Rekognition、Amazon SageMaker モデルなどのリアルタイムのレコメンデーションエンジン
+ Amazon Simple Storage Service (Amazon S3) や などのスケーラブルなデータレイク AWS Lake Formation
+ Amazon Athena、Amazon EMR、Amazon OpenSearch Service、Amazon Kinesis、Amazon Redshift などの専用の Amazon 分析サービス
+  AWS Glue や などのシームレスなデータ移動サービス AWS App Mesh

**重要**  
サポート終了通知: 2026 年 9 月 30 日、 AWS は のサポートを終了します AWS App Mesh。2026 年 9 月 30 日以降、 AWS App Mesh コンソールまたは AWS App Mesh リソースにアクセスできなくなります。詳細については、このブログ記事[「 から Amazon ECS Service Connect AWS App Mesh への移行](https://aws.amazon.com/blogs/containers/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect)」を参照してください。

**注記**  
ウェーブ 3 の機能には、一般的に多数の依存関係があり、通常は他のマイクロサービスと統合する必要があります。このような属性から、ウェーブ 3 の機能はコンテナベースのマイクロサービスに置き換えるのに適しています。

## ステップ 3: 選択した AWS マイクロサービスの設定に必要な基盤 AWS インフラストラクチャを設定する
<a name="configure-foundational-aws-infrastructure"></a>

主要な利害関係者とターゲットのクラウドベースのアーキテクチャを確認して確定したら、選択したマイクロサービスの設定 AWS に必要な AWS インフラストラクチャを設定します。

**基盤 AWS インフラストラクチャリソースの例**
+ [AWS Control Tower](https://aws.amazon.com/controltower/) とランディングゾーン
+ [AWS Organizations](https://aws.amazon.com/organizations/) 組織単位とサービスコントロールポリシー (SCPs)
+ [AWS Identity and Access Management (IAM)](https://aws.amazon.com/iam/) ポリシー
+ [Amazon API Gateway](https://aws.amazon.com/api-gateway/) API
+ [AWS Lambda](https://aws.amazon.com/lambda/) 関数
+ AWS [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) などの データベースサービス
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) のダッシュボードとアラーム
+ [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) キュー
+ [Amazon Simple Notification Service (Amazon SNS)](https://aws.amazon.com/sns/) のトピックとサブスクリプション
+ [Amazon Cognito](https://aws.amazon.com/cognito/) とユーザープール

## ステップ 4: 変更をウェーブで実装する
<a name="implement-the-changes-in-waves"></a>

各ウェーブグループをテスト環境に順次実装します。各ウェーブグループが本番環境の準備が整ったら、テスト環境でシステムの機能をテストし、問題をデバッグします。次に、変更を本番環境に段階的に切り替えます。

以下は、各ウェーブグループの実装に通常関連するタスクのタイプの概要です。

**ウェーブ 1 の実装**
+ サーバーレス Lambda 関数を作成する
+ Lambda 関数を API Gateway サービスと統合する
+ Amazon Cognito、IAM、Okta、Ping Identity などのツールを使用して、認証および認可システムを設定する
+ ハイブリッドクラウドアーキテクチャの場合は、 などのサービスメッシュを使用してプロキシレイヤーを設定します[AWS App Mesh](https://aws.amazon.com/app-mesh/)。

**ウェーブ 2 の実装**
+ サービスメッシュ AWS App Mesh、仮想サービス、ノード、ルート、プロキシを含む を設定する
+  AWS Fargate または Amazon Elastic Kubernetes Service (Amazon EKS) でコンテナを設定する
+ プロキシレイヤーをフロントエンドシステムと統合する

**ウェーブ 3 の実装**
+ 複雑なデータ移行と統合を完了する
+ 複数のマイクロサービスを含む最も複雑なワークフローを実装する