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

# AWS アプリケーション設計と移行戦略
<a name="aws-application-design-and-migration-strategy"></a>

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

設計プロセスの重要性に加えて、よりブロックされ、移行速度に影響を与える可能性もあります。これは、オンプレミスシステム用に考案された従来のアーキテクチャレビュープロセスが原因で発生します。アーキテクチャのレビューと承認プロセスを確認し、事前承認できるアーキテクチャパターンやタイプの確立に集中することをお勧めします。数百または数千のアプリケーションのアーキテクチャを確認する労力を過小評価せず、プロセスをモダナイズする機会を得てください。

次のリストには、設計プロセスに役立つリソースが含まれています。
+ [AWS アーキテクチャセンター](https://aws.amazon.com/architecture/)は、 AWS Well-Architected フレームワークなどのツールとガイダンスを組み合わせています。また、アプリケーションに使用できるリファレンスアーキテクチャも提供します。
+ [Amazon Builders' Library ](https://aws.amazon.com/builders-library/)には、Amazon がソフトウェアを構築および運用する方法に関するいくつかのリソースが含まれています。
+ [AWS ソリューションライブラリ](https://aws.amazon.com/solutions/)は、AWS が検証したクラウドベースのソリューションを多数提供しています。これには、リファレンスアーキテクチャの大規模なコレクションが含まれています。
+ [AWS 規範ガイダンス](https://aws.amazon.com/prescriptive-guidance/)は、設計プロセスと移行のベストプラクティスに役立つ戦略、ガイド、パターンを提供します。
+ [AWS Documentation](https://docs.aws.amazon.com/) には、 ユーザーガイドや API リファレンスなどの AWS サービスに関する情報が含まれています。
+ [入門リソースセンター](https://aws.amazon.com/getting-started/)には、基礎を学習するための実践的なチュートリアルと詳細な演習がいくつか用意されています AWS。

クラウドジャーニーのどの段階にあるかに応じて、 AWS 基盤が既に存在している可能性があります。これらの AWS 基盤には以下が含まれます。
+ AWS リージョン が特定されました。
+ アカウントが作成されているか、オンデマンドで取得できます。
+ 一般的なネットワークが実装されました。
+ 基本 AWS サービスは アカウント内にデプロイされています。 

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

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

## アプリケーションの将来の状態
<a name="application-future-state"></a>

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

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

次に、コンテキストと問題を文書化し、現在の状態を定義する既存のアーティファクトをリンクします。
+ このアプリケーションが移行される理由 
+ 提案された変更は何ですか? 
+ 利点は何ですか? 
+ 重大なリスクやブロック要因はありますか? 
+ 現在の欠点は何ですか? 
+ スコープ内とスコープ外のものは何ですか? 

## 再現性
<a name="repeatability"></a>

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

## 要件
<a name="requirements"></a>

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

## To-Be アーキテクチャ
<a name="to-be-architecture"></a>

このアプリケーションの将来のアーキテクチャについて説明します。ソース環境 (オンプレミス) とターゲット 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 エンドポイントなど) はありますか?

## アーキテクチャ上の意思決定
<a name="architectural-decisions"></a>

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

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

## ソフトウェアライフサイクル環境
<a name="software-lifecycle-environments"></a>

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

## Tagging
<a name="tagging"></a>

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

## 移行戦略
<a name="migration-strategy"></a>

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

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

6 R の決定の詳細については、[AWS Migration Hub 「戦略の推奨事項](https://aws.amazon.com/blogs/aws/new-strategy-recommendations-service-helps-streamline-aws-cloud-migration-and-modernization/)」を参照してください。

## 移行パターンとツール
<a name="migration-patterns-tools"></a>

アプリケーションおよびインフラストラクチャコンポーネントの移行戦略を定義することで、特定の技術パターンを探索できるようになりました。たとえば、リホスト戦略は、 などの移行ツールで実装できます[AWS Transform MGN](https://aws.amazon.com/application-migration-service/)。状態やデータをレプリケートする必要がない場合は、Amazon マシンイメージ (AMI) とアプリケーションデプロイパイプラインを使用してアプリケーションを再デプロイすることで、同じ結果を得ることができます。 

同様に、アプリケーションをリプラットフォームまたはリファクタリング (リアーキテクト) するには、[AWS App2Container](https://aws.amazon.com/app2container/)、 [AWS Database Migration Service (AWS DMS)](https://aws.amazon.com/dms/)、 [AWS Schema Conversion Tool(AWS SCT)](https://aws.amazon.com/dms/schema-conversion-tool/)、 などのツールを使用できます[AWS DataSync](https://aws.amazon.com/datasync/)。コンテナ化には、[Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/)、[Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/)、または を使用できます[AWS Fargate](https://aws.amazon.com/fargate/)。再購入するときは、特定の製品または の Software as a Service (SaaS) ソリューションに AMI を使用できます[AWS Marketplace](https://aws.amazon.com/marketplace/)。

目標を達成するために利用できるさまざまなパターンとオプションを評価します。長所と短所、および移行の運用準備を検討してください。分析に役立てるには、次の質問を使用します。
+ 移行チームはこれらのパターンをサポートできますか?
+ コストと利点のバランスはどれくらいですか?
+ このアプリケーション、サービス、またはコンポーネントをマネージドサービスに移動できますか?
+ このパターンを実装する労力は何ですか?
+ 特定のパターンの使用を妨げる規制やコンプライアンスポリシーはありますか?
+ このパターンは再利用できますか? 再利用可能なパターンが推奨されます。ただし、パターンが 1 回だけ使用される場合があります。代替の再利用可能なパターンよりも、シングルユースパターンの労力のバランスを検討してください。

[AWS 規範ガイダンス](https://aws.amazon.com/prescriptive-guidance/)には、さまざまな移行パターンと手法が含まれています。

## サービス管理とオペレーション
<a name="service-management-and-operations"></a>

への移行のためのアプリケーション設計を作成するときは AWS、運用準備を検討してください。アプリケーションチームとインフラストラクチャチームで準備状況要件を評価するときは、次の質問を考慮してください。
+ 運用する準備はできていますか? 
+ インシデント対応手順は定義されていますか? 
+ 予想されるサービスレベルアグリーメント (SLA) とは何ですか? 
+ 職務の分離は必要ですか? 
+ さまざまなチームがサポートアクションを調整する準備ができていますか? 
+ 誰が何を担当しますか?

## カットオーバーに関する考慮事項
<a name="cutover-considerations"></a>

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

## リスク、前提、問題、依存関係
<a name="risks-assumptions-issues-dependencies"></a>

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

## 実行コストの見積もり
<a name="estimating-run-cost"></a>

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