

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

# クラウドへの移行パス
<a name="cloud-paths"></a>

このセクションでは、Windows アプリケーションを AWSに移行するためのベストプラクティスを実装するための大まかなアプローチについて説明します。これらの移行戦略とステップの詳細については、このガイドの後続のセクションで説明します。

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

移行戦略とは、ワークロードを AWS クラウドに移行するために使用するアプローチです。アプリケーションをクラウドに移行するには、次の 7 つの移行戦略があります。これらの戦略は 7 Rs と呼ばれ、ガートナーが 2019 年に特定した [7 Rs](https://www.gartner.com/smarterwithgartner/7-options-to-modernize-legacy-systems) に基づいて構築されています。
+ **リホスト (リフトアンドシフト)** — クラウド機能を活用するための変更を加えずに、アプリケーションをクラウドに移行します。
+ **再配置** (ハイパーバイザーレベルのリフトアンドシフト) – 新しいハードウェアを購入したり、アプリケーションを書き換えたり、既存の運用を変更したりすることなく、インフラストラクチャをクラウドに移行できます。
+ **リプラットフォーム (リフトアンドリシェイプ)** – アプリケーションをクラウドに移行し、クラウド機能を活用するためにある程度の最適化を導入します。
+ **再購入 (ドロップアンドショップ)** — 通常、従来のライセンスから Software as a Service (SaaS) モデルに移行して、別の製品に切り替えます。
+ **リファクタリング/アーキテクチャの再設計** — クラウドネイティブ特徴を最大限に活用して、俊敏性、パフォーマンス、スケーラビリティを向上させ、アプリケーションを移動させ、アーキテクチャを変更します。
+ **保持** (再アクセス) – アプリケーションをお客様のソース環境で保持します。これには、主要なリファクタリングを必要とするアプリケーションや、お客様がその作業を後日まで延期したいアプリケーション、およびそれらを移行するためのビジネス上の正当性がないため、お客様が保持するレガシーアプリケーションなどがあります。
+ **廃止** – お客様のソース環境で不要になったアプリケーションを廃止または削除します。

## 主なトランスフォーメーション
<a name="main-transformations"></a>

レガシー Windows アプリケーションとデータベースをモダナイズすると、次の主なトランスフォーメーションが行われます。
+ **リホスト** – 最初のステップは、オンプレミスのインフラストラクチャをクラウドインフラストラクチャに移行することです。この戦略は、多くの場合、「リフトアンドシフト」またはリホストと呼ばれます。リホストとは、既存のアプリケーションとデータベースをクラウドサーバーインスタンスに移行することを意味します。コードを変更する必要はなく、ユーザーはインスタンス設定、ソフトウェアイメージ、その他のリソースを管理する責任を負います。
+ **リプラットフォーム** – クラウド環境への移行後に行う次のトランスフォーメーションは、アプリケーションとデータベースをより自動化されたマネージド環境にリプラットフォームすることです。アプリケーションの観点からは、仮想マシン (VMs) からコンテナまたはマネージドアプリケーションプラットフォームに移行することを意味します。アプリケーションのコンテナ化は、アプリケーションを迅速に開発、保守、デプロイし、移植性を向上させるのに役立ちます。または、 は、容量のプロビジョニング、負荷分散、スケーリングを自動的に処理するマネージドプラットフォーム [AWS Elastic Beanstalk ](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)を提供します。これにより、インフラストラクチャ管理を最小限に抑え、完全にコンテナ化することなく、アプリケーションをリプラットフォームできます。データベース側から見ると、セルフサービスモデルから Amazon RDS for SQL Server などのマネージドデータベースサービスに移行すると、プロビジョニング、パッチ適用、バックアップが不要になります。これにより、組織により多くの価値を追加できるアクティビティのリソースが解放されます。
+ **リファクタリング/アーキテクチャの再設計** – 3 番目のトランスフォーメーション領域は、商用ソフトウェアライセンスからオープンソースのオプションへの移行です。従来の商用ソフトウェアベンダーの多くは、顧客の囲い込みを目的としたソフトウェアライセンス契約に基づき、アップグレードと移行を強制するライセンスの罰則規定を利用してビジネスを構築しています。多くの場合、商用ソフトウェアライセンス料金は、同等のオープンソースのオプションに対してコストが一般的に 20～50% 増加します。コストを削減し、パフォーマンスを向上させ、最新のイノベーションにアクセスできるように、アプリケーションとデータベースをリファクタリングしてオープンソースのオプションを活用することをお勧めします。

これらの主なトランスフォーメーション領域は、アプリケーションおよびモダナイズの全体的な準備状況に応じて、段階的に、または一度にすべて完了できます。

## 移行戦略の選択
<a name="choosing-migration-strategy"></a>

どの移行戦略を選ぶかは、組織のビジネス目標と IT 目標によって異なります。最も一般的なビジネス推進要因には、コストの削減、リスクの軽減、効率の向上、スキルギャップへの対応、イノベーションの加速などがあります。次のガイダンスを使用して、どの推進要因が組織にとって重要かを評価し、組織の推進要因に基づいて移行戦略を選択することをお勧めします。なお、3 つのアプローチはどれも、ジャーニーの各フェーズにおける優先順位に応じて、クラウドモダナイゼーションジャーニーで選択可能なことに注意してください。

### リホストが推奨される状況
<a name="choosing-migration-strategy-rehost"></a>

リホスト (リフトアンドシフト) は通常、アプリケーションでコードやアーキテクチャを変更する必要がないため、よりすばやく簡単に実行できます。また、リホストは、ビジネスのリスクと中断を最小限に抑えます。アプリケーションは変更されないため、運用チームは普段どおり事業運営をけることができます。これは、大規模な移行で、関与するワークロードの数が多いためわずかな変更でも重大な影響を及ぼす場合に特に当てはまります。ただし、リホストではクラウドのメリットを最大限に活用できないことを考慮することが重要です。例えば、既存のプラットフォームの問題があるアプリケーションを移行した場合、その問題は移行後も残ります。最後に、リホストの総保有コスト (TCO) と投資収益率 (ROI) は、他の移行アプローチと比較して低くなることを考慮してください。

### リプラットフォーム/アーキテクチャの再設計が推奨される状況
<a name="choosing-migration-strategy-replatform"></a>

一般的に、リプラットフォームはリホストよりもコスト効率が高くなります。リプラットフォームを使用すると、自動化を強化でき、アプリケーションは自動スケーリング、モニタリング、バックアップの実行などのクラウド機能をさらに活用できるようになりす。リプラットフォームにより、クラウド運用チームの運用上のオーバーヘッドが軽減され、既存のプラットフォームの問題によるリスクが最小限に抑えられます。ただし、リプラットフォームにはリホストによる移行と比べて時間がかかります。また、リプラットフォームには、アプリケーションでコード変更を実行するための自動化を設定し、新しいプラットフォームを運用可能にするための追加スキルが必要です。

### リファクタリングが推奨される状況
<a name="choosing-migration-strategy-refactor"></a>

リファクタリングは通常、最も費用対効果の高い移行アプローチです。リファクタリングは、アプリケーションの耐障害性を向上させるためにアプリケーションコンポーネントをデカップリングすることで、アプリケーションが新しい要件に迅速に適応できるようにするクラウドネイティブなアプローチです。ただし、リファクタリングでは、より高度なコーディングと自動化のスキルが求められます。また、アプリケーションの再構築を伴うため、リファクタリングの実装には時間がかかります。