翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
フェーズ 3: 波ベースの実装
ウェーブベースの実装フェーズでは、レガシーシステムの特定の機能を置き換える AWS マイクロサービスを選択し、それらのサービスをウェーブで実装することに重点を置いています。以下の推奨事項は、最初にモダナイズする機能に優先順位を付け、変更を本番環境に段階的にロールアウトするのに役立ちます。
重要
以下のウェーブグループを実装する前に、主要な利害関係者に相談し、承認を得るようにしてください。これらのグループを作成するときは、機能マトリックスのスコアリング基準のみに頼るのではなく、反復的なアプローチを使用することをお勧めします。
主な重点分野
一連の優先順位付け基準を使用して、依存関係の数、ビジネスの優先順位、複雑さのレベルに基づいて、機能を 3 つの実装ウェーブに分類する
レガシー IT システムと同じ機能を提供できるクラウドネイティブ AWS マイクロサービスの選択
選択した AWS マイクロサービスの設定に必要な基本的な AWS インフラストラクチャの設定
本番環境への変更を段階的にロールアウトする
ステップ 1: 依存関係の数、ビジネスの優先度、複雑さのレベルに基づいて機能を整理する
主要な利害関係者からのインプットと機能マトリックスの加重スコアを使用して、レガシーシステムの機能を次の 3 つの主要なグループに整理します。
注記
ほとんどの実装では、多くのサブウェーブグループを使用する必要があります。このガイドでは、例としてのみ 3 つの主要なウェーブグループの概要を説明します。
Wave 1 の機能
依存関係の数 | なしまたは非常に低い |
ビジネスの優先度 | 低 |
複雑さ | 低 |
Wave 2 の機能
依存関係の数 | 低~中 |
ビジネスの優先度 | 低~中 |
複雑さ | Medium |
Wave 3 の機能
依存関係の数 | 高 |
ビジネスの優先順位 | 中~高 |
複雑さ | 中~高 |
ステップ 2: レガシー IT システムの機能を置き換える AWS マイクロサービスを選択する
主要な利害関係者と連携して、モダナイズする一連の機能を見直して確定する反復プロセスを使用します。次に、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 パターンを使用してオンプレミスのレガシーワークロードをシームレスに移行する
Wave 2 AWS マイクロサービスの例
AWS Step Functions ベースのワークフロー
データベースが目的に適合 (Aurora PostgreSQL への移行)
AWS SaaS ファクトリ
注記
Wave 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 などのシームレスなデータ移動サービス
注記
Wave 3 の機能には通常、多数の依存関係があり、通常は他のマイクロサービスと統合する必要があります。これらの属性により、ウェーブ 3 の機能がコンテナベースのマイクロサービスに置き換えられるようになります。
ステップ 3: 選択した AWS マイクロサービスをセットアップするために必要な基本的な AWS インフラストラクチャを設定する
主要な利害関係者とターゲットのクラウドベースのアーキテクチャを確認して確定したら、選択した AWS マイクロサービスの設定に必要な AWS インフラストラクチャを設定します。
基本的な AWS インフラストラクチャリソースの例
AWS Control Tower
とランディングゾーン AWS Organizations
の組織単位とサービスコントロールポリシー (SCPs) Amazon API Gateway
APIs AWS Lambda
関数 Amazon Relational Database Service (Amazon RDS) などの AWS データベース
サービス Amazon CloudWatch
ダッシュボードとアラーム Amazon Simple Notification Service (Amazon SNS)
のトピックとサブスクリプション Amazon Cognito
とユーザープール
ステップ 4: ウェーブの変更を実装する
各ウェーブグループをテスト環境に順次実装します。各ウェーブグループが本番稼働の準備ができたら、システムの機能をテストし、テスト環境での問題をデバッグします。次に、本番環境への変更を段階的にカットオーバーします。
以下は、各ウェーブグループの実装に通常関連するタスクのタイプの概要です。
Wave 1 の実装
サーバーレス Lambda 関数を作成する
Lambda 関数を API Gateway サービスに統合する
Amazon Cognito、IAM、Okta、Ping Identity などのツールを使用して認証および認可システムを設定する
ハイブリッドクラウドアーキテクチャの場合は、AWS App Mesh
などのサービスメッシュを使用してプロキシレイヤーを設定します。
Wave 2 の実装
サービスメッシュ、仮想サービス、ノード、ルート、プロキシを含む AWS App Mesh を設定する
AWS Fargate または Amazon Elastic Kubernetes Service (Amazon EKS) でコンテナを設定する
プロキシレイヤーをフロントエンドシステムと統合する
Wave 3 の実装
複雑なデータ移行と統合を完了する
複数のマイクロサービスを含む最も複雑なワークフローを実装する