翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 移行戦略について
*移行戦略*は、ワークロードを に移行するために使用するアプローチです AWS クラウド。アプリケーションをクラウドに移行するための 7 つの移行戦略があります。これは *7 R *と呼ばれます。
+ [リタイア](#retire)
+ [Retain](#retain)
+ [リホスト](#rehost)
+ [リロケート](#relocate)
+ [再購入](#repurchase)
+ [リプラットフォーム](#replatform)
+ [リファクタリングまたはリアーキテクト](#refactor)
大規模な移行の一般的な戦略には、リホスト、リプラットフォーム、再配置、廃止などがあります。リファクタリングは、移行中にアプリケーションをモダナイズする必要があるため、大規模な移行にはお勧めしません。これは移行戦略の中で最も複雑であり、多数のアプリケーションに対して を管理するのは難しい場合があります。代わりに、アプリケーションのリホスト、再配置、または再プラットフォームを行い、移行の完了後にアプリケーションをモダナイズすることをお勧めします。
大規模な移行には、移行戦略の選択が不可欠です。動員フェーズまたは初期ポートフォリオ評価中に移行戦略を選択している可能性があります。このセクションでは、各移行戦略とその一般的なユースケースについて説明します。
## リタイア
これは、廃止またはアーカイブするアプリケーションの移行戦略です。アプリケーションの廃止は、そのアプリケーションスタック内のサーバーをシャットダウンできることを意味します。廃止戦略の一般的なユースケースは次のとおりです。
+ アプリケーションを保持したり、クラウドに移行したりすることにビジネス価値はありません。
+ アプリケーションのメンテナンスとホスティングにかかるコストを排除したい。
+ サポートされなくなったオペレーティングシステム (OS) バージョンまたはコンポーネントを使用するアプリケーションを運用する際のセキュリティリスクを軽減したいと考えています。
+ アプリケーションのパフォーマンスに基づいてアプリケーションを廃止したい場合があります。たとえば、平均 CPU とメモリの使用率が 5% 未満のアプリケーションを廃止するとします。*これはゾンビアプリケーション*と呼ばれます。また、90 日間の平均 CPU およびメモリ使用率が 5～20% のアプリケーションは、*アイドル*アプリケーションとして廃止することもできます。検出ツールの使用率とパフォーマンスデータを使用して、ゾンビやアイドル状態のアプリケーションを特定できます。
+ 過去 90 日間、アプリケーションへのインバウンド接続がありません。
詳細については、[「 への移行中に廃止されるアプリケーションを評価するためのベストプラクティス AWS クラウド](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-retiring-applications/)」を参照してください。
## Retain
これは、ソース環境に保持するアプリケーションの移行戦略、または移行する準備ができていないアプリケーションの移行戦略です。これらのアプリケーションを将来移行することを選択できます。
保持戦略の一般的なユースケースは次のとおりです。
+ **セキュリティとコンプライアンス** – データレジデンシー要件に準拠し続けるために、アプリケーションを保持したい場合があります。
+ **高リスク** – 移行前に詳細な評価と計画が必要なため、アプリケーションを保持することに決める場合があります。
+ **依存関係** – 最初に 1 つ以上の他のアプリケーションを移行する必要がある場合は、アプリケーションを保持できます。
+ **最近アップグレードされたアプリケーション** – 最近現在のシステムのアップグレードに投資したため、次の技術更新までアプリケーションの移行を延期できます。
+ **移行するビジネス価値がない** – 内部ユーザーが少ないアプリケーションなど、一部のアプリケーションをクラウドに移行するためのビジネス価値はありません。
+ **Software as a Service (SaaS) への移行計画** – ベンダーが SaaS バージョンをリリースするまで、アプリケーションを保持することを選択できます。これは、ベンダーベースのアプリケーションの一般的な戦略です。
+ **未解決の物理的な依存関係** – 製造工場の機械など、クラウドと同等のものを持たない特殊なハードウェアに依存するアプリケーションを保持することもできます。
+ **メインフレームアプリケーションまたはミッドレンジアプリケーションおよび非 x86 Unix アプリケーション** – これらのアプリケーションは、クラウドに移行する前に慎重に評価と計画を行う必要があります。ミッドレンジアプリケーションの例には、IBM AS/400 や Oracle Solaris などがあります。
+ **パフォーマンス** – パフォーマンスに基づいてアプリケーションを保持できます。たとえば、ソース環境にゾンビやアイドル状態のアプリケーションを保持できます。
## リホスト
この戦略は*リフトアンドシフト*とも呼ばれます。この戦略を使用すると、アプリケーションを変更 AWS クラウド せずに、アプリケーションをソース環境から に移動します。たとえば、アプリケーションスタックをオンプレミスから に移行します AWS クラウド。
リホストを使用すると、互換性、パフォーマンスの中断、長いカットオーバーウィンドウ、長距離データレプリケーションを心配 AWS クラウド することなく、多数のマシンを複数のソースプラットフォーム (物理、仮想、または別のクラウド) から に移行できます。
ワークロードの移行中もアプリケーションは引き続きユーザーにサービスを提供しているため、中断やダウンタイムを最小限に抑えることができます。ダウンタイムはカットオーバー戦略によって異なります。
この戦略は、時間やコストを節約できるクラウド最適化を実装することなく、アプリケーションをスケールするのに役立ちます。アプリケーションは、 サービスに統合 AWS してワークロードを管理する方が簡単なため、クラウドですでに実行されている場合、最適化や再設計が容易になります。
リホストを自動化するには、次のサービスを使用します。
+ [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/when-to-choose-aws-mgn/)
+ [AWS クラウド移行ファクトリーソリューション](https://aws.amazon.com/solutions/implementations/aws-cloudendure-migration-factory-solution/)
+ [VM Import/Export](https://aws.amazon.com/ec2/vm-import/)
リホスト移行戦略の移行パターンのリストについては、 AWS 「 規範ガイダンス」ウェブサイトの[「リホスト](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migration-rehost-pattern-list.html)」を参照してください。
## リロケート
この戦略を使用すると、1 つ以上のアプリケーションで構成される多数のサーバーを、特定の時点でオンプレミスプラットフォームからクラウドバージョンのプラットフォームに転送できます。再配置戦略を使用して、インスタンスまたはオブジェクトを別の仮想プライベートクラウド (VPC) AWS リージョン、または に移動することもできます AWS アカウント。例えば、この戦略を使用して Amazon Relational Database Service (Amazon RDS) DB インスタンスを別の VPC または に転送できます AWS アカウント。
再配置戦略では、新しいハードウェアを購入したり、アプリケーションを書き換えたり、既存のオペレーションを変更したりする必要はありません。再配置中、アプリケーションは引き続きユーザーにサービスを提供し、中断とダウンタイムを最小限に抑えます。再配置は、アプリケーションのアーキテクチャ全体に影響しないため、ワークロードをクラウドに移行して運用する最も簡単な方法です。
再配置移行戦略の移行パターンのリストについては、 AWS 「 規範ガイダンス」ウェブサイトの[「再配置](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migration-relocate-pattern-list.html)」を参照してください。
## 再購入
この戦略は、*ドロップアンドショップ*とも呼ばれます。アプリケーションを別のバージョンまたは製品に置き換えます。新しいアプリケーションは、既存のオンプレミスアプリケーションよりも多くのビジネス価値を提供する必要があります。これには、どこからでものアクセシビリティ、維持すべきインフラストラクチャがない、pay-as-you-goモデルなどの機能が含まれます。通常、アプリケーションを購入することで、メンテナンス、インフラストラクチャ、ライセンスに関連するコストを削減できます。
以下は、再購入移行戦略の一般的なユースケースです。
+ **従来のライセンスから SaaS への移行** – これにより、インフラストラクチャの管理と保守の負担が軽減され、ライセンスの問題が軽減されます。
+ **バージョンのアップグレードまたはサードパーティーの同等の**機能 – 既存のオンプレミスアプリケーションをベンダーの最新バージョンまたはクラウド内のサードパーティーの同等の機能に置き換えることで、新機能を活用し、クラウドサービスと統合して、アプリケーションをより簡単に拡張できます。
+ **カスタムアプリケーションの置き換え** – ベンダーベースの SaaS またはクラウドベースのアプリケーションを再購入することで、カスタムアプリケーションのリコードと再設計を回避できます。
購入する前に、ビジネス要件、特にセキュリティとコンプライアンスに従ってアプリケーションを評価する必要があります。
新しいアプリケーションを購入した後、次のステップは次のとおりです。
+ 新しいシステムでチームとユーザーをトレーニングする
+ 新しく購入したアプリケーションへのデータの移行
+ アプリケーションを Microsoft Active Directory などの認証サービスに統合して認証を一元化する
+ 購入したアプリケーション、ユーザー、インフラストラクチャ間の安全な通信に役立つネットワークの設定
通常、アプリケーションベンダーは、スムーズな移行のためにこれらのアクティビティを支援します。
## リプラットフォーム
この戦略は、*リフト、ティンカー、シフト*、*リフトアンドシェイプ*とも呼ばれます。この移行戦略を使用して、アプリケーションをクラウドに移行し、アプリケーションを効率的に運用したり、コストを削減したり、クラウド機能を活用したりするために、ある程度の最適化を導入します。たとえば、Microsoft SQL Server データベースを Amazon RDS for SQL Server にリプラットフォームできます。
この戦略を使用すると、ビジネス目標とターゲットプラットフォームに応じて、アプリケーションにいくつかの変更を加えることができます。
リプラットフォーム移行戦略の一般的なユースケースは次のとおりです。
+ でフルマネージドサービスまたはサーバーレスサービスに移行することで、時間を節約し、コストを削減したいと考えています AWS クラウド。
+ オペレーティングシステムを最新バージョンにアップグレードすることで、セキュリティとコンプライアンスのスタンスを向上させたいと考えています。
+ によって開発されたカスタムビルド[AWS プロセッサである Graviton プロセッサ](https://aws.amazon.com/ec2/graviton/)を使用することで、コストを削減できます AWS。
+ Microsoft Windows オペレーティングシステムから Linux オペレーティングシステムに移行することで、コストを削減できます。.NET Framework アプリケーションを .NET Core に移植できます。.NET Core は Linux オペレーティングシステムで実行できます。[Porting Assistant for .NET](https://aws.amazon.com/porting-assistant-dotnet/) は、アプリケーションを Linux に移植するのに役立つ分析ツールです。
+ コードを変更せずに仮想マシンをコンテナに移行することで、パフォーマンスを向上させることができます。[AWS App2Container 移行ツールを使用して](https://aws.amazon.com/app2container/)、.NET および Java アプリケーションをコンテナ化されたアプリケーションにモダナイズできます。
リプラットフォーム戦略は、セキュリティとコンプライアンスを損なうことなく、レガシーアプリケーションの実行を維持します。
リプラットフォームは、マネージドサービスまたはサーバーレスサービスへの移行、仮想マシンのコンテナへの移行、ライセンス費用の回避により、コストを削減し、パフォーマンスを向上させます。
リプラットフォーム移行戦略の移行パターンのリストについては、 AWS 「 規範ガイダンス」ウェブサイトの[「リプラットフォーム](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migration-replatform-pattern-list.html)」を参照してください。
## リファクタリングまたはリアーキテクト
この戦略を使用して、クラウドネイティブ機能を最大限に活用して俊敏性、パフォーマンス、スケーラビリティを向上させることで、アプリケーションをクラウドに移行し、アーキテクチャを変更します。これは、製品と機能のリリースのスケーリング、高速化、コスト削減を求める強力なビジネス需要によって推進されます。
リファクタリング移行戦略の一般的なユースケースは次のとおりです。
+ レガシーメインフレームアプリケーションは、その制限によりビジネスの需要に対応できなくなり、維持にコストがかかります。
+ モノリスアプリケーションがあり、製品を迅速に提供したり、顧客のニーズや需要に対処したりする作業をすでに妨げています。
+ メンテナンス方法がわからないレガシーアプリケーションがあるか、ソースコードが使用不可です。
+ アプリケーションのテストが困難であるか、テストカバレッジが非常に低い。これは、新しいアプリケーション機能と修正の品質と配信に影響します。クラウド用のアプリケーションを再設計することで、テストカバレッジを増やし、自動テストツールを統合できます。
+ セキュリティおよびコンプライアンス上の理由から、データベースをクラウドに移行するときは、一部のテーブル (顧客情報、患者、患者診断テーブルなど) を抽出し、それらのテーブルをオンプレミスに保持する必要がある場合があります。この場合、移行するテーブルをオンプレミスに保持するテーブルから分離するには、データベースのリファクタリングが必要です。
リファクタリング移行戦略の移行パターンのリストについては、 AWS 「 規範ガイダンス」ウェブサイトの[「リアーキテクト](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migration-rearchitect-pattern-list.html)」を参照してください。