アプリケーションの移行とは

アプリケーションは通常、特定のネットワーク・アーキテクチャー内の特定のオペレーティング・システムで実行するように構築されるか、単一のクラウド・プラットフォーム用に開発されるため、アプリケーションを新しい環境に移行すると、いくつかの課題が生じる可能性があります。通常、仮想化されたアーキテクチャーまたはサービス・ベースのアーキテクチャーからアプリケーションを移行する方が、ベアメタル・ハードウェアで実行されているアプリケーションを移行するよりも簡単です。

全体的なアプリケーション移行ストラテジーの決定には、個々のアプリケーションの依存関係や技術的要件、さらには企業のセキュリティー、コンプライアンス、コストの制約を考慮する必要があります。

同じテクノロジー環境内であっても、アプリケーションによってクラウドへのパスは異なります。クラウド・コンピューティングの初期の頃から、開発者はこれらのアプリケーション移行パターンを「R」で始まる名前で呼んでいました。

再ホスト： リフト・アンド・シフトとも呼ばれる再ホストは、企業がアプリケーションをオンプレミス・サーバーからクラウド内の仮想マシンに、大きな変更を加えずに移動するための一般的な戦略です。アプリケーションの再ホストは通常、他の移行戦略よりも迅速であり、移行コストを大幅に削減できます。その一方で、欠点は、変更しないと、アプリケーションがクラウドネイティブ・コンピューティング機能のメリットを享受できず、クラウドでアプリケーションを実行する長期的なコストが高くなる可能性があることです。

リファクタリングまたは再構築：リファクタリングとは、クラウド環境でアプリケーションの拡張やパフォーマンスを向上させるために、アプリケーションにかなり大きな変更を加えることを指します。これには、モノリシックなアプリケーションをマイクロサービスのセットに再構築する、データ・ストアをSQLからNoSQLにモダナイズするなど、クラウドネイティブ機能をより有効に活用できるように、アプリケーションの主要部分を再コーディングすることが含まれる場合があります。

リプラットフォーム：アプリケーションのリプラットフォームは、リフト・アンド・シフトとリアーキテクトの中間のようなもので、クラウド・アーキテクチャーのメリットをさらに引き出すために、アプリケーションに小さな変更を加えることが含まれます。例としては、クラウドネイティブのマネージド・データベースで動作するようにアプリケーションをアップグレードすること、連携するオペレーティング・システムやミドルウェアを変更すること、アプリケーションをコンテナ化することなどが挙げられます。

廃止／置き換え：場合によっては、アプリケーションを廃止することが最も理にかなっていることがあります。その理由としては、その価値が限られている、その機能が環境内の他の場所で重複している、またはアプリケーションを移行するよりも新しいサービス（多くの場合、Software-as-a-Service（SaaS） プラットフォーム）に置き換える方がコスト効率が高いなどが挙げられます。

企業独自のIT環境とビジネス・ニーズに最適なアプリケーション移行戦略を策定するには、アプリケーション・ポートフォリオの内容、セキュリティーとコンプライアンスの要件の詳細、現在使用しているクラウド・リソース、オンプレミスのストレージ、コンピューティング、ネットワーク・インフラストラクチャーの状況を正確に把握する必要があります。

クラウド移行を成功させるには、移行の動機となる主要なビジネス推進要因を明確にし、それらの推進要因に合わせて戦略を調整する必要があります。また、クラウドに移行する理由と、移行によって何を達成したいのかを意識しなければなりません。

関係者は、アプリケーションの移行によってビジネスに混乱が生じたり、予期しないコストが発生したりすることを懸念する場合があります。最も一般的なリスクは次のとおりです。

• 予期しない技術的課題：例えば、アプリケーションには非常に多くの依存関係があるため、リファクタリングや再プラットフォーム化が当初考えていたよりもはるかに複雑で時間がかかる可能性があります。
  
  
• 予期しないコスト：適切な計画を立てないと、新しいライセンス料や従業員に新しいツールの使い方を習得させるためのトレーニング費用など、予算に含まれていない予期せぬコストが発生する可能性があります。
  
  
• 予期しないダウンタイム：アプリケーションに大きな変更を加えると、競合や問題が発生し、アプリケーションと接続または依存するシステムの両方で計画外のダウンタイムが発生する可能性があります。
  
  
• 文化的な問題または変更管理の難しさ：組織によってアプリの使用方法は異なり、その違いによって摩擦が生じ、移行プロジェクトの進行が遅くなる可能性があります。

ポートフォリオ内の各アプリケーションのリホスティング、再構築/リプラットフォーム、または廃止に関連するリスクとメリットを慎重かつ詳細に評価することで、アプリケーションの移行に関連する全体的なリスクを軽減できます。特に、部門レベルのコストと企業の総コストを比較し、アプリケーションをオンプレミスに維持するために保守が必要なハードウェアの総所有コスト（TCO）の評価が重要です。

企業はこれまで、クラウド・プロバイダーが提供する柔軟性、拡張性、または予測可能な従量課金制のコスト構造を求めることがほとんどでした。

しかし現在、企業はイノベーションを可能にする環境も求めています。クラウド・テクノロジーにより、次のオプションが可能になります。

• 実験し、新しいアイデアをテストし、「早い段階で失敗しておくこと」
• ディープラーニング・アルゴリズムの強化に必要な高性能プロセッサへのアクセス
• コンテナ化されたアプリケーションへのアクセスにより、開発チームは変更を迅速に実装することで、顧客のデジタル体験を迅速に改善できます。

多くの場合、コンテナ化などのクラウド対応テクノロジーにより、置き換える可能性のある仮想マシンよりも優れたエクスペリエンスをユーザーに提供できるようになります。

一般的に、アプリケーションの移行計画プロセスは3つの段階に分類できます。いずれの場合も、一部のオンプレミス・ワークロードを維持する選択など、考えられるすべての選択肢のコストを比較検討することが非常に重要です。

アプリケーションの特定とアセスメント： この最初の発見フェーズでは、ポートフォリオ内のすべてのアプリケーションの包括的なカタログを確保することから始めます。次に、ビジネス・クリティカルか重要ではないか、その価値が戦略的か非戦略的か、そして、それぞれをクラウドに移行する際の自身の立場に応じて、アプリケーションを分類します。次の特性の観点から、各アプリケーションの価値を理解するよう努める必要があります。

• ビジネスへの影響
  
  
• 重要なビジネス・ニーズを満たす能力
  
  
• データの適時性と重要性
  
  
• サイズ、複雑さ、管理性
  
  
• 保守と開発のコスト
  
  
• クラウドへの移行による価値の向上

次に、移行を検討しているアプリケーションごとにクラウド親和性評価を実施する必要があります。このプロセスでは、どのアプリケーションが現状のままで使用できるか、どのアプリケーションをクラウド対応にする前に大幅な変更が必要なのかを判断します。

また、特定のワークロードを現在の環境外に移行するのが可能かどうかを判断するのに役立つ、アプリケーション依存関係発見ツールを使用することもできます。

総所有コスト（TCO）のアセスメント：クラウド移行プロジェクトの総コストを決定するのは複雑な作業になる可能性があります。アプリケーションとインフラストラクチャーをオンプレミスに維持する場合の「もしも」のシナリオと、それらをクラウドに移行する場合のシナリオを比較します。いずれかのシナリオでオンプレミスで保守するハードウェアの購入、運用、保守のコスト、およびソフトウェアのライセンスのコストを計算します。

どちらのシナリオでもクラウド・プロバイダーから受け取る月額料金と、新しいインフラストラクチャーのテストや更新されたソフトウェアを使用するための従業員のトレーニングなどの移行自体のコストを比較します。オンプレミスに残っているレガシー・アプリケーションの保守コストを考慮することも忘れてはなりません。

全体的なリスクとプロジェクト期間のアセスメント：移行計画の最終段階では、プロジェクトのスケジュールを設定し、遭遇しそうなリスクや障害物を特定します。

一般的に言えば、アプリケーションが古いほど、クラウドへの移行は難しくなります（結果として価値が低くなる可能性があります）。古いソフトウェアはさまざまな点で問題を抱えています。維持に費用がかかることや、パッチが適用されなくなった場合にセキュリティー上の懸念が生じる可能性があること、さらに最新のコンピューティング環境ではパフォーマンスが低下しやすいことなどです。レガシー・アプリケーションの移行を決定する前に、特に徹底的なアセスメントを行ってください。

組織がアプリケーションの実現可能性と移行の優先順位を評価する際には、次の課題を考慮します。

複雑さ： このアプリケーションはどこで開発されましたか。社内の場合、開発者はまだ会社で働いていますか。アプリケーションの関連資料はすぐに入手できますか。アプリケーションが開発されてから何年経過していますか。どれくらい使用していますか。組織内の他のアプリケーションやワークフローのうち、このアプリケーションやワークフローに何らかの形で依存しているものはいくつありますか。

重要度： このアプリケーションを毎日利用しているユーザーは何人ですか。毎週ではどうですか。どの程度のダウンタイムであれば、業務運営を支障を出さずに、許容できるでしょうか。アプリケーションは、運用、開発、テスト、あるいはそのすべてで使用されていますか。社内のITチームによって管理されていますか、それとも外部ベンダーによって管理されていますか。このアプリケーションと同期する必要がある、アップタイム／ダウンタイム要件を持つ他のアプリケーションはありますか。

コンプライアンス：アプリケーションはどの規制要件に準拠しなければならないか。

可用性：アプリケーションはどのアップタイム基準に準拠する必要があるか。たとえば、アップタイム99.99%を規定するサービス・レベル契約（SLA）の対象でしょうか。

テスト

アプリケーションの移行プロセス中にデータや機能が失われないようにするため、移行中にテストを実行して、すべてのデータが存在し、データの整合性が維持され、データが正しいストレージの場所にあることを確認します。

移行完了後にフォローアップ・テストを実施し、アプリケーションの性能をベンチマークし、セキュリティー管理が確実に行われるようにすることも不可欠です。

仮想化は、仮想マシンを新しい物理ハードウェア環境で簡単に実行できるため、多くのクラウド移行戦略の基本的なコンポーネントです。ユーザー・エクスペリエンスを中断することなく、仮想マシン上で実行されているライブ・アプリケーションを物理ホスト・マシン間で移動することも可能です。仮想化されたコンピューティング環境の柔軟性と汎用性により、アプリケーションの移行プロセスが大幅に簡素化されます。

現在利用可能ないくつかのレプリケーションおよび移行ソリューションにより、顧客は仮想マシンを ベアメタル・サーバー、クラウド内の仮想サーバー、さらには ハイパーバイザー間で移行できます。

• VMWareアプリケーションの移行：オペレーションが中断する、ダウンタイムが発生する、またはアプリケーションの再構成が必要になることなく、オンプレミスのVMwareインスタンスで実行されている仮想マシンを、プライベートクラウドで実行されているVMWare VCenter Serverにリフト・アンド・シフトすることが可能です。
  
  
• Red Hatアプリケーションの移行：Red Hatは、IT環境を分析してアプリケーションの相互依存関係を特定する、カスタマイズ可能で拡張可能なソフトウェア・ソリューションであるMigration Toolkitを提供しています。ダッシュボード・スタイルの分析レポートを提供し、移行中に問題が発生する可能性のあるアプリケーションを強調表示します。

企業がクラウド移行を成功させるための戦略立案、計画、実行を支援するサービスは多数あります。

移行の青写真： 包括的な青写真サービスのオファリングでは、ベンダーが移行のストラテジーと目的を明確にし、アプリケーションと環境に関する情報を収集し、ユーザーのニーズとビジネス要件を特定し、お客様の詳細な行動計画の策定を支援します。

移行のデプロイメント：管理されたデプロイメント・オプションを選択した場合、ベンダーは移行の戦略と計画の支援だけでなく、移行自体と関連するテストおよびトラブルシューティングも管理します。これは通常、完全なエンドツーエンドのサポートを含むターンキー・サービスです。

クラウド・マネージド・サービス：マネージド・クラウド・サービスのオファリングには通常、クラウドベースのIT環境の監視と保守が含まれます。マネージド・クラウド・サービス・プロバイダーは、クラウドのセキュリティー管理からベンダーからのas-a-serviceオファリングの調達代行まで、複数の機能を担っています。アプリケーションの移行は、パッケージサービスのオファリングに含めることも、アラカルトで追加することもできます。

アプリケーションのモダナイゼーション： アプリケーションのモダナイゼーション・サービスには、レガシー・アプリケーションを コンテナ または仮想化環境で実行できるように変更することで、クラウドでの使用に備えるカスタム開発サービスが含まれます。