フェーズ 3: 波ベースの実装 - AWS 規範ガイダンス

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

フェーズ 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 インフラストラクチャリソースの例

ステップ 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 の実装

  • 複雑なデータ移行と統合を完了する

  • 複数のマイクロサービスを含む最も複雑なワークフローを実装する