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

# ベストプラクティス
<a name="best-practices"></a>

アプリケーションの廃止を選択するのは、特に AWS クラウドへの移行中に複雑な決定になる可能性があります。以下のセクションでは、意思決定プロセスで活用できるベストプラクティスを紹介します。

**Topics**
+ [マイグレーション・ファクトリー・アプローチを検討します。](best-practice-1.md)
+ [移行の早い段階でアプリケーションを特定して廃止する](best-practice-2.md)
+ [データに基づき、ディスカバリー・ツールを使って混乱を回避します。](best-practice-3.md)
+ [コントロールストップを予定する](best-practice-4.md)
+ [アプリケーションを移行すべきかどうかを再評価します](best-practice-5.md)
+ [アプリケーションを廃止します。](best-practice-6.md)

# マイグレーション・ファクトリー・アプローチを検討します。
<a name="best-practice-1"></a>

大規模なマイグレーションで重要なのは、最初の試験的ワークロードを移行した後に、マイグレーション・ファクトリーを確立することです。

マイグレーションファクトリは、チーム、ツール、プロセスで構成されます。これらのチームが協力して、これまでのマイグレーションの波から学んだ教訓を取り入れながら、移行を体系的に効率化します。マイグレーション・ファクトリはパターンを適用することで、ワークロードのマイグレーションを加速し、最終的な結果を改善します。

廃止する必要のある IT ポートフォリオの規模を考えると、マイグレーション・ファクトリー・アプローチの導入に価値があるかどうかを検討する価値があります。このガイドで概説されている方法論と原則は、このアプローチを補完するものでもあり、そのメカニズムに組み込むこともできます。

通常、エンタープライズアプリケーションポートフォリオの 20 ～ 50% は、マイグレーションファクトリアプローチを使用して最適化できる繰り返しパターンで構成されています。パターンの例としては、移行チームが実装して移行を調整および自動化できる[「AWS Cloud Migration Factory ソリューション」 ](https://aws.amazon.com//solutions/implementations/cloud-migration-factory-on-aws/)を参照してください。

チームは、ビジネス上の重要性が最も低いアプリケーションから始めて、徐々に重要なシステムに移行する必要があります。チームがビジネスクリティカルなシステムの移行を開始する頃には、数千とは言わないまでも数百のワークロードを移行し、多くの教訓を学んでいるでしょう。

評価フェーズが始まる前に、廃止が決定したアプリケーションの 1 か月分の依存関係データを収集するプロセスを作成できます。準備が整うと、チームに通知され、データにアクセスできるようになります。次に、チームはアプリケーションが影響を与える可能性に基づいてデータにスコアを付けます。アプリケーション所有者は、次のステップを開始する前に、接続の詳細な分析を行う場合があります。

マイグレーションファクトリの方法論について詳しくは、[「 AWS 大規模マイグレーションガイド」 ](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/)を参照してください。

# 移行の早い段階でアプリケーションを特定して廃止する
<a name="best-practice-2"></a>

移行プロセスの早い段階でアプリケーションを特定して廃止することは重要であり、ワークロードの移行中に実行する必要があります。

移行プロジェクトでは、ワークロードの移行が優先されることが多いため、引退する (移行しない) ことが決定しているシステムは、プロジェクトの終盤に焦点を当てられるのが一般的です。ただし、これらのアプリケーションをプロジェクトの終了まで放置しておくと、後でそのアプリケーションが重要であると見なされた場合に、移行に含める時間がほとんど残されないというリスクがあります。

移行プロジェクトの早い段階でワークロードを廃止することで、そのワークロードを管理するチームの作業負荷が軽減されます。たとえば、移行プロジェクトの初期段階でサーバーを廃止すると、オペレーティングシステムチームがパッチ、アップグレード、保守、またはサポートの対象となるサーバーの数が減ります。これらのチームは、移行プロジェクト自体に集中できるようになります。

最後に、このガイドのベストプラクティスの一部は、長期間にわたって実行すると最も効果的です。早期に廃止プロセスを開始しても、後にそのアプリケーションが実際には別のサービスで必要であると判断した場合、移行計画を修正し、将来の移行の波にそのアプリケーションを含めることができます。

# データに基づき、ディスカバリー・ツールを使って混乱を回避します。
<a name="best-practice-3"></a>

アプリケーションの廃止を検討する際には、データ主導型であることが重要です。アーキテクチャ図や制度上の知識は、古くなったり、不完全であったりすることがよくあります。例えば、ブレークフィックス・シナリオのために、別のアプリケーションが正式な関与なしにあなたのシステムに依存するようになるなどです。

データ主導型のアプローチは、意思決定やアプローチの検証を行うための基盤となります。アプリケーションを廃止できるかどうかを評価する際には、移行するワークロードがそのアプリケーションに依存していないことを確認する必要があります。これらのワークロードを移行してから依存関係を廃止すると、サービスが低下したり、最悪の場合はサービスが中断したりする可能性があります。

幸い、廃止が予定されているサーバー上のネットワークのインバウンド接続とアウトバウンド接続をデータを使用して監視することで、これらの依存関係をかなり簡単に理解できます。アプリケーションに接続するアプリケーションなどのネットワークインバウンド接続と、ネットワークファイルシステム (NFS) 共有へのファイルアップロードなどのアウトバウンド接続は、アップストリームに依存する可能性があることを示しています。この依存関係を調査する必要があります。 AWS クラウドに移行する予定のワークロードがアプリケーションに接続すると、後でアプリケーションが廃止されるとサービスが中断される可能性があるためです。このプロセスを深く掘り下げて依存関係の連鎖をたどる必要があるかもしれません。前の例に従い、アプリケーションが NFS 共有にファイルをアップロードする場合、次のステップは、そのファイルを消費するシステムと、そのアプリケーションのステータスを判断することです。

それらの接続を調査し、影響レベルを評価することになるかもしれません。そのためには、検出ツールを使用して、廃止が予定されているサーバに対して開始されている接続を表示します。ほとんどの接続が管理サーバーからのもので、パフォーマンス・メトリクスを収集するツールやシステム管理者のプロキシインスタンスであるため、無視できることに気づくかもしれません。ただし、移行が予定されているサーバーに接続しているアプリケーションがある場合は、さらに詳しく調べて、移行がそのアプリケーションに与える潜在的な影響を確認する必要があります。

 [AWS Application Discovery Service](https://aws.amazon.com/application-discovery/) は、お客様が廃止予定のオンプレミスデータセンターに関する情報を収集することで、移行プロジェクトの計画を支援します。エージェントをサーバーにデプロイすると、Application Discovery Service は、各サーバーのインバウンドおよびアウトバウンドのネットワークアクティビティを他の情報とともに記録します。[Amazon Athena](https://aws.amazon.com/athena/) を使用してこのデータを分析することで、廃止が予定されているサーバーに他のアプリケーションが依存しているかどうかを特定できます。[AWS 「移行コンピテンシーパートナー」 ](https://aws.amazon.com//migration/partner-solutions/)は、詳細な調査と計画のためのツールも提供できます。

**注記**  
Application Discovery Service は新規お客様に公開されなくなりました。または、同様の機能 AWS Transform を提供する を使用します。詳細については、「[AWS Application Discovery Service  可用性の変更](https://docs.aws.amazon.com/application-discovery/latest/userguide/application-discovery-service-availability-change.html)」を参照してください。

たとえば、以下の画面図は、ポート 22 (宛先 = 172.31.1.117) でサーバーに接続する 4 つの送信元 IP アドレスを示しています。

![\[コネクションの分析例。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/migration-retiring-applications/images/best-practices-4.png)


これらはシステム管理者が使用する拠点ホストで、無視してかまいません。この図には、計画的な移行の対象となる、ポート 80 でこのアプリケーションに接続している 2 台のサーバーも示されています。この段階では、接続しているアプリケーションをさらに深く掘り下げて理解する必要があります。この詳細な分析により、退職後に上流部門に何らかの影響があるかどうかを評価できます。

# コントロールストップを予定する
<a name="best-practice-4"></a>

移行計画では、移行プロセス中に管理された停止時間を必ずスケジュールすること。管理された停止は移行プロセスを一時停止し、アプリケーションが廃止された場合に中断される可能性を特定します。アプリケーションの廃止をシミュレートし、その結果を観察できます。制御された停止期間が終了すると、移行を簡単に再開できます。

制御停止の方法は、アプリケーションの種類や、処理している関連プロセスによって異なります。一般的な制御停止パターンには以下が含まれます。
+  ホストベースのファイアウォールを実装してすべてのトラフィックをブロックすることで、廃止をシミュレートします。
+  仮想マシンを一時停止します
+  ホスト上のサービスを停止する
+  外部ファイアウォールを使用してすべてのトラフィックをブロックします。

移行プロジェクトとアプリケーション所有者は、アプリケーションの種類に応じて、制御停止の期間を定義する必要があります。たとえば、月に 1 回または四半期に 1 回しか実行されないバッチベースのワークロードを廃止する場合、1 週間の制御停止を実行するだけでは、他のシステムへの影響を判断するには不十分な場合があります。

前のセクションの例を引き続き使用すると、廃止が予定されていたサーバーに別のアプリケーションが接続していました。最初の評価では、上流のサーバーには影響はないはずだという結論に達しました。これで、制御された停止を実行して影響を把握できるようになりました。

この制御された停止を実現するには、ホストベースのファイアウォールを実装してすべてのトラフィックをブロックし、サーバーをシャットダウンした場合の効果をシミュレートします。これにより、 AWS クラウドへの移行が予定されているアプリケーションのサービスの問題が発生した場合、ファイアウォールルールが追加され、すべてのトラフィックが再開されます。制御停止後は、このサービスの低下または中断によるサーバーの廃止が再検討されます。

# アプリケーションを移行すべきかどうかを再評価します
<a name="best-practice-5"></a>

最後に説明した 2 つのベストプラクティスは、廃止予定のシステムに対するアクションを継続することが適切かどうかを判断するのに役立ちます。これらのベストプラクティスによってアップストリームのビジネスへの潜在的な影響が浮き彫りになった場合は、アプリケーションの移行パターンを再評価することを検討すべきです。アプリケーションの廃止プロセスを早期に開始することで、廃止できないような問題や依存関係に遭遇した場合に、そのアプリケーションを次の移行段階に組み込むのに十分な時間を確保できます。

これらのベストプラクティスに従っても、アプリケーションのリタイアに自信がない場合は、 AWS クラウドにリホストすべきかどうかを検討してください。これは、データセンターのリースの有効期限など、移行の終了日が設定されている場合に特に重要です。

[「AWS アプリケーション移行サービス」 ](https://aws.amazon.com/application-migration-service/)などのサービスは、リホスト移行のアプローチを簡素化します。アプリケーションを に移行すると AWS、Amazon Elastic Block Store (Amazon EBS) ボリュームのスナップショットを毎日作成し、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを終了してコストを削減し、長期間にわたってアプリケーションの廃止をテストできます。影響や問題が発生した場合でも、スナップショットに基づいて EBS ボリュームを作成して EC2 インスタンスを再開できるという安心感があります。

**重要**  
 EC2 インスタンスを終了する前に、このリカバリプロセスをテストします。

# アプリケーションを廃止します。
<a name="best-practice-6"></a>

このガイドの前の 5 つのベストプラクティスに従った結果、アプリケーションを廃止しても安全だと判断したかもしれません。移行ファクトリアプローチを導入し、廃止プロセスを早期に開始し、データと検出ツールを使用して受信接続を監視し、制御された停止を正常に実行し、アプリケーションを廃止すべきかどうかを評価しました。これで、移行戦略の一環としてアプリケーションを廃止できるようになりました。

この時点で、将来役に立つかもしれないデータがアプリケーションに含まれているかどうかをチェックする必要があります。機械学習 (ML) と分析は、データにかつてないほど大きな価値をもたらしました。今は ML アルゴリズムを開発していないかもしれないが、過去のデータは将来有益なものになります。また、アプリケーションが廃止された場合でも、一定期間データを保存するという規制やコンプライアンス要件があるかもしれません。

AWS は、長期保持、コンプライアンス、デジタル保存のための包括的なクラウドストレージサービスを提供します。データアーカイブ用の AWS ストレージソリューションは、無制限のスケール、99.999999999% の耐久性、データの信頼性、データセキュリティを提供します。

コンプライアンスの取り組みを支援するために、 は定期的に何千ものグローバルコンプライアンス要件のサードパーティー検証 AWS を達成します。これらは継続的に監視され、金融、小売、医療、政府などのセキュリティおよびコンプライアンス基準を満たすのに役立ちます。

によるデータアーカイブの詳細については AWS、 AWS ウェブサイトの[「データアーカイブ](https://aws.amazon.com//archive/)」を参照してください。