AWS アプリケーション設計と移行戦略 - AWS 規範ガイダンス
アプリケーションの将来の状態再現性要件To-Be アーキテクチャアーキテクチャ上の意思決定ソフトウェアライフサイクル環境Tagging移行戦略移行パターンとツールサービスの管理と運用カットオーバーに関する考慮事項リスク、前提、問題、依存関係実行コストの見積もり

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

AWS アプリケーション設計と移行戦略

アプリケーションの将来の状態を設計および文書化することは、移行の成功の重要な要素です。シンプルでも複雑でも、あらゆる種類の移行戦略の設計を作成することをお勧めします。設計を作成すると、アーキテクチャが変更されることが予想されない場合でも、潜在的なブロック要因、依存関係、アプリケーションを最適化する機会が明らかになります。

また、移行戦略レンズ AWS を使用して、 でのアプリケーションの将来の状態に近づくことをお勧めします。この段階では、この移行 AWS の結果としてアプリケーションが でどのように表示されるかを必ず定義してください。結果として得られる設計は、移行後のさらなる進化の基盤となります。

次のリストには、設計プロセスに役立つリソースが含まれています。

  • AWS アーキテクチャセンターは、 AWS Well-Architected フレームワークなどのツールとガイダンスを組み合わせています。また、アプリケーションに使用できるリファレンスアーキテクチャも提供します。

  • Amazon Builders' Library には、Amazon がソフトウェアを構築および運用する方法に関するいくつかのリソースが含まれています。

  • AWS ソリューションライブラリは、数十の技術的およびビジネス上の問題に対して AWS、 によって検証されたクラウドベースのソリューションのコレクションを提供します。これには、リファレンスアーキテクチャの大規模なコレクションが含まれています。

  • AWS 規範ガイダンスは、設計プロセスと移行のベストプラクティスに役立つ戦略、ガイド、パターンを提供します。

  • AWS Documentation には、ユーザーガイドや API リファレンスなどの AWS サービスに関する情報が含まれています。

  • 入門ガイドリソースセンターでは、基礎を学習するための実践的なチュートリアルとディープダイブをいくつか提供しています AWS。

クラウドジャーニーのどの段階にあるかに応じて、 AWS 基盤が既に存在する可能性があります。これらの AWS 基盤には以下が含まれます。

  • AWS リージョン が識別されました。

  • アカウントが作成されているか、オンデマンドで取得できます。

  • 一般的なネットワークが実装されました。

  • 基本的な AWS サービスは アカウント内にデプロイされています。

逆に、プロセスの早い段階で基盤がまだ確立 AWS されていない可能性があります。基盤が確立されていないと、アプリケーション設計の範囲が制限されたり、定義のためにさらなる作業が必要になる可能性があります。このような場合は、ランディングゾーンの基本的な設計をアプリケーション設計作業と並行して定義して実装することをお勧めします。アプリケーション設計は、 AWS アカウント 構造、ネットワーク、仮想プライベートクラウド (VPCs)、クラスレスドメイン間ルーティング (CIDR) 範囲、共有サービス、セキュリティ、クラウド運用などの要件を特定するのに役立ちます。

AWS Control Tower は、ランディングゾーンと呼ばれる安全なマルチアカウント AWS 環境をセットアップして管理するための最も簡単な方法を提供します。 は、 を使用してランディングゾーン AWS Control Tower を作成します。これにより AWS Organizations、何千人もの顧客とクラウドに移行する際に、 AWS ベストプラクティスベースのエクスペリエンスを継続的に管理、ガバナンス、実装できます。

アプリケーションの将来の状態

まず、このアプリケーションの初期移行戦略を確立します。この時点で、戦略は将来の状態設計の一部として変更され、潜在的な制限を明らかにする可能性があるため、初期と見なされます。初期の前提条件を検証するには、6 Rs 決定ツリーを参照してください。また、潜在的な移行フェーズを文書化します。たとえば、このアプリケーションは 1 つのイベントに移行されますか (すべてのコンポーネントが同時に移行されますか）。または、これは段階的な移行ですか (一部のコンポーネントは後で移行されます)?

特定のアプリケーションの移行戦略は一意ではない場合があることに注意してください。これは、複数の R タイプを使用してアプリケーションコンポーネントを移行できるためです。例えば、最初のアプローチは、変更なしでアプリケーションをリフトアンドシフトすることです。ただし、アプリケーションのコンポーネントは、さまざまな処理を必要とするさまざまなインフラストラクチャアセットに存在する場合があります。たとえば、アプリケーションは 3 つのコンポーネントで構成され、それぞれが別のサーバーで実行され、いずれかのサーバーはクラウドでサポートされていないレガシーオペレーティングシステムを実行します。そのコンポーネントにはリプラットフォームアプローチが必要ですが、サポートされているサーバーバージョンで実行されている他の 2 つのコンポーネントはリホストできます。移行する各アプリケーションコンポーネントおよび関連するインフラストラクチャに移行戦略を割り当てることが重要です。

次に、コンテキストと問題を文書化し、現在の状態を定義する既存のアーティファクトをリンクします。

  • このアプリケーションが移行される理由

  • 提案された変更は何ですか？

  • どのような利点がありますか？

  • 重大なリスクやブロック要因はありますか？

  • 現在の欠点は何ですか？

  • スコープ内とスコープ外のものは何ですか？

再現性

設計作業全体を通して、このアプリケーションのソリューションとアーキテクチャを他のアプリケーションに再利用する方法を検討してください。このソリューションは一般化できますか？

要件

セキュリティを含め、このアプリケーションの機能要件と非機能要件を文書化します。これには、選択した移行戦略に応じて、現在および将来の状態の要件が含まれます。詳細なアプリケーション評価で収集された情報を使用して、このプロセスをガイドします。

To-Be アーキテクチャ

このアプリケーションの将来のアーキテクチャについて説明します。ソース環境 (オンプレミス) とターゲット AWS 環境 (ターゲット、アカウント AWS リージョン、VPCs、アベイラビリティーゾーンなど) の構成要素を含む再利用可能な図テンプレートを作成することを検討してください。

移行するコンポーネントと新しいコンポーネントのテーブルを作成します。このアプリケーションとやり取りする他のアプリケーションとサービス (オンプレミスまたはクラウド内) を含めます。

次の表に、コンポーネントの例を示します。これは、リファレンスアーキテクチャや入念な設定を表すものではありません。

名前

説明

詳細

アプリケーション

外部サービス (インバウンド接続）

サービスは、公開された API からのデータを消費します。

DNS

名前解決 (内部）

ベースラインアカウント設定の一部としてデプロイされた Amazon Route 53

Application Load Balancer

バックエンドサービス間でトラフィックを分散する

オンプレミスのロードバランサーを置き換えます。プール A を移行します。

アプリケーションのセキュリティ

DdoS 保護

を使用して実装 AWS Shield

セキュリティグループ

仮想ファイアウォール

ポート 443 (インバウンド) のアプリケーションインスタンスへのアクセスを制限します。

サーバー A

フロントエンド

Amazon Elastic Compute Cloud (Amazon EC2) を使用してリホストします。

サーバー B

フロントエンド

Amazon EC2 を使用してリホストします。

サーバー C

アプリケーションロジック

Amazon EC2 を使用してリホストします。

サーバー D

アプリケーションロジック

Amazon EC2 を使用してリホストします。

Amazon Relational Database Service (Amazon RDS) – Amazon Aurora

データベース

サーバー E と F を置き換えます

モニタリングとアラート

変更管理

Amazon CloudWatch

監査ログ

変更管理

AWS CloudTrail

パッチ適用とリモートアクセス

メンテナンス

AWS Systems Manager

リソースアクセス

安全なアクセスコントロール

AWS Identity and Access Management (IAM)

認証

ユーザーアクセス

Amazon Cognito

証明書

SSL/TLS

AWS Certificate Manager

API 1

外部 API

Amazon API Gateway

オブジェクトストレージ

イメージホスティング

Amazon Simple Storage Service (Amazon S3)

認証情報

認証情報の管理とホスティング

AWS Secrets Manager

AWS Lambda 関数

データベース認証情報と API キーの取得

AWS Lambda

インターネットゲートウェイ

アウトバウンドインターネットアクセス

VPC へのインターネットゲートウェイ

プライベートサブネット 1

バックエンドと DB

アベイラビリティーゾーン 1 – VPC 1

プライベートサブネット 2

バックエンドと DB

アベイラビリティーゾーン 2 – VPC 1

パブリックサブネット 1

フロントエンド

アベイラビリティーゾーン 1 – VPC 1

パブリックサブネット 2

フロントエンド

アベイラビリティーゾーン 2 – VPC 1

バックアップサービス

データベースと EC2 インスタンスのバックアップ

AWS Backup

DR

Amazon EC2 の耐障害性

AWS Elastic Disaster Recovery

コンポーネントを特定したら、任意のツールを使用してそれらを図にプロットします。初期設計を、アプリケーション所有者、エンタープライズアーキテクト、プラットフォームチーム、移行チームなど、主要なアプリケーションステークホルダーと共有します。次の質問をすることを検討してください。

  • チームは通常、設計に同意していますか？

  • 運用チームはそれをサポートできますか？

  • 設計を進化させることはできますか？

  • 他にオプションはありますか？

  • 設計はアーキテクチャ標準とセキュリティポリシーに準拠していますか？

  • 不足しているコンポーネント (コードリポジトリ、CI/CD ツール、VPC エンドポイントなど) はありますか？

アーキテクチャ上の意思決定

設計プロセスの一環として、アーキテクチャ全体またはその特定の部分に対して、より多くのオプションが見つかる可能性があります。これらのオプションを、優先または選択したオプションの理論的根拠とともに文書化します。これらの決定は、アーキテクチャ上の決定として文書化できます。

メインオプションがリストされ、新しいリーダーが、あるオプションを別のオプションで使用する決定の背後にあるオプションと理由を理解できるように、十分な詳細で説明されていることを確認します。

ソフトウェアライフサイクル環境

現在の環境への変更を文書化します。たとえば、テスト環境と開発環境は で再作成され AWS 、移行されません。

Tagging

各インフラストラクチャコンポーネントの必須および推奨されるタグ付けと、この設計のタグ付け値について説明します。

移行戦略

設計のこの時点で、移行戦略に関する最初の前提を検証する必要があります。選択した R 戦略にコンセンサスがあることを確認します。全体的なアプリケーション移行戦略と個々のアプリケーションコンポーネントの戦略を文書化します。前述のように、アプリケーションコンポーネントが異なる場合、移行に異なる R タイプが必要になることがあります。

さらに、移行戦略を主要なビジネス推進要因と成果に合わせます。また、さまざまな移行イベントでのコンポーネントの移動など、移行への段階的なアプローチについても説明します。

6 R の決定の詳細については、AWS Migration Hub 「戦略の推奨事項」を参照してください。

移行パターンとツール

アプリケーションとインフラストラクチャコンポーネントに対して定義された移行戦略を使用して、特定の技術パターンを探索できるようになりました。例えば、リホスト戦略は、 などの移行ツールで実装できますAWS Application Migration Service。状態やデータをレプリケートする必要がない場合は、Amazon マシンイメージ (AMI) とアプリケーションデプロイパイプラインを使用してアプリケーションを再デプロイすることで、同じ結果を得ることができます。

同様に、アプリケーションをリプラットフォームまたはリファクタリング (リアーキテクト) するには、AWS App2Container、 AWS Database Migration Service （AWS DMS）、 AWS Schema Conversion Tool (AWS SCT）、 などのツールを使用できますAWS DataSync。コンテナ化には、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、または を使用できますAWS Fargate。再購入するときは、特定の製品または の Software as a Service (SaaS) ソリューションに AMI を使用できますAWS Marketplace。

目標を達成するために利用できるさまざまなパターンとオプションを評価します。長所と短所、および移行の運用準備を検討します。分析に役立てるには、次の質問を使用します。

  • 移行チームはこれらのパターンをサポートできますか？

  • コストと利点のバランスはどれくらいですか？

  • このアプリケーション、サービス、またはコンポーネントをマネージドサービスに移動できますか？

  • このパターンを実装する労力は何ですか？

  • 特定のパターンの使用を妨げる規制やコンプライアンスポリシーはありますか？

  • このパターンは再利用できますか？ 再利用可能なパターンが推奨されます。ただし、パターンが 1 回だけ使用される場合があります。代替の再利用可能なパターンよりも、シングルユースパターンの労力のバランスを検討してください。

AWS 規範ガイダンスには、さまざまな移行パターンと手法が含まれています。

サービスの管理と運用

に移行するためのアプリケーション設計を作成するときは AWS、運用準備を検討してください。アプリケーションチームとインフラストラクチャチームで準備状況要件を評価するときは、次の質問を考慮してください。

  • 運用する準備はできていますか？

  • インシデント対応手順は定義されていますか？

  • 予想されるサービスレベルアグリーメント (SLA) とは

  • 職務の分離は必要ですか？

  • さまざまなチームがサポートアクションを調整する準備ができていますか？

  • 誰が何を担当しますか？

カットオーバーに関する考慮事項

移行戦略とパターンを考慮すると、アプリケーションが移行された時点で知っておくべき重要なことは何ですか？ カットオーバー計画は、設計後のアクティビティです。ただし、予想されるアクティビティと要件に関する考慮事項があれば文書化します。例えば、該当する場合は概念実証を実行する要件を文書化し、テスト、監査、または検証の要件の概要を説明します。

リスク、前提、問題、依存関係

未解決の未解決のリスク、前提、潜在的な問題を文書化します。これらの項目に明確な所有権を割り当て、全体的な設計と戦略の実装を承認できるように進捗状況を追跡します。さらに、この設計を実装するための主要な依存関係を文書化します。

実行コストの見積もり

ターゲット AWS アーキテクチャのコストを見積もるには、 AWS 料金計算ツールを使用します。設計で定義されているインフラストラクチャコンポーネントを追加し、推定実行コストを取得します。アプリケーションコンポーネントに必要であり、使用する AWS サービスにまだ含まれていないソフトウェアライセンスを考慮します。