レガシー モダナイゼーションは、アプリケーションのモダナイゼーションの一種で、レガシー システムを新しい最新プラットフォームに移行するものです。これには、多くの場合、アプリケーション アーキテクチャ、インフラストラクチャ、機能の更新が伴います。この変革の主な推進要因は、企業が市場の新たな需要に適応し、ユーザー エクスペリエンスを向上させ、クラウド コンピューティング、データ分析、AI などの最新テクノロジーを活用する必要があることです。

レガシー モダナイゼーション ソフトウェア プロジェクトを実施するには、既存のアプリケーション ポートフォリオを包括的に評価して、モダナイゼーションの候補を特定する必要があります。そこから、組織はアプリケーションを最新のインフラストラクチャに移行するだけの戦略から、クラウドネイティブの原則に従って完全に再構築する戦略まで、さまざまな戦略の中から選択できます。目標は、重要なシステムを進化させ、ビジネスの長期的な戦略目標の達成を妨げるのではなく、サポートできるようにすることです。

レガシー システムを置き換えるか、レガシー アプリケーションをモダナイズすることを選択すると、新しいテクノロジーの導入だけに留まらない明白なビジネス上のメリットが得られます。

モダナイズされたアプリケーションは更新が容易なため、開発チームは新機能をより迅速にリリースし、変化する市場の状況に迅速に対応できます。このアジリティは、競争上の優位性につながります。

多くの場合、レガシー システムの維持には費用がかかり、専門的なスキルや旧式のハードウェアが必要になります。最新のクラウドベースのプラットフォームに移行すると、費用が資本的支出（CapEx）から運用支出（OpEx）に変わり、オーバーヘッドが削減されます。

古いソフトウェアには、パッチが適用されていない脆弱性がある可能性があり、現在のコンプライアンス基準を満たしていないことがあります。レガシー ソフトウェアのモダナイゼーションは、堅牢で最新のセキュリティ管理を組み込み、規制要件を確実に遵守する機会となります。

レガシー アプリケーションでは、最新のトラフィック負荷の処理が困難になることがよくあります。レガシー アプリケーションをクラウドに移行すると、需要に合わせて自動的にスケーリングできる弾力性のあるインフラストラクチャにアクセスできるようになり、信頼性の高いユーザー エクスペリエンスが確保されます。

最新のプラットフォームでは、データ分析、ML、AI の高度なサービスにネイティブにアクセスできます。これにより、企業は古いシステムではアクセスできなかったデータから新しい分析情報や機能を引き出すことができます。

コンテナ化は、従来のアプリのモダナイゼーションを加速する強力なテクノロジーとして登場しました。アプリケーションとその依存関係をコンテナにパッケージ化することで、軽量でポータブルな、一貫性のあるソフトウェア ユニットが作成されます。これは、さまざまなモダナイゼーション戦略においてメリットがあります。「リホスト」または「リプラットフォーム」プロジェクトの場合、以前のアプリケーションをコンテナ化することで、移行プロセスが簡素化され、また新しいクラウド環境でアプリケーションを確実に実行できるようになります。「リファクタリング」プロジェクトの場合、コンテナは、元のモノリスから切り出される新しいマイクロサービスに理想的なデプロイモデルです。

コンテナ化により、レガシー アプリケーションとその依存関係を、あらゆる環境で一貫して実行できる、標準化されたポータブル ユニットであるコンテナにパッケージ化できます。このアプローチでは、基盤となる以前のハードウェアやオペレーティング システムからアプリケーションを効果的に切り離し、最新のクラウド プラットフォームに直接橋渡しします。

レガシー アプリケーションをコンテナ化すると、Google Kubernetes Engine（GKE）や Cloud Run などの Google Cloud のマネージド サービスに簡単にデプロイできる一貫したアーティファクトが作成されます。この最初のステップは、アプリケーションのソースコードをすぐに大規模に変更することなく実行できるため、レガシー アプリケーションを低リスクでクラウドに移行する方法となります。最新の環境で実行されると、アプリケーションを繰り返し改善し、マネージド クラウド サービスに接続して、時間をかけて徐々にリファクタリングできます。

このプロセスでは、コンテナ化をコアテクノロジーとして使用し、モダナイゼーションの取り組みを管理可能な一連のステップに分解します。

まず、レガシー アプリケーションのポートフォリオを分析します。コンテナ化の最初の候補として適しているのは、多くの場合、ステートレス アプリケーションや、外部依存関係が最小限で、よく理解されているサービスです。これにより、初期の複雑さが軽減され、チームはプロセスに対する経験と自信を深めることができます。

次のステップでは、アプリケーションをコンテナとしてパッケージ化する方法を定義します。これを行うには、Dockerfile などの一連の指示を含むシンプルなテキスト ファイルを作成します。このファイルは、ベース オペレーティング システムを指定し、アプリケーションのソースコードをイメージにコピーし、必要なすべてのランタイム、ライブラリ、その他の依存関係をインストールするために必要なコマンドをリストします。

このファイルを使用して、コンテナ イメージをビルドします。これは、デベロッパーのローカルマシンで行うことも、より堅牢なワークフローにするために、Cloud Build などの CI / CD サービスを使用して自動化することもできます。その結果として得られるイメージ（静的なポータブル ファイル）は、Google Cloud の Artifact Registry などの安全な限定公開の Container Registry に push する必要があります。これは、アプリケーション イメージを保存および管理する一元的な場所として機能します。

コンテナ化されたレガシー アプリケーションが Artifact Registry に保存されたので、これを Google Cloud の最新のマネージド プラットフォームにデプロイできます。

• より多くの構成制御が必要なアプリケーションや、より大きなシステムの一部であるアプリケーションには、Google Kubernetes Engine（GKE）が理想的なターゲットです
• よりシンプルなステートレスのウェブ アプリケーションや API の場合、Cloud Run は、すべてのインフラストラクチャ管理を担う、完全にサーバーレスな環境を提供します。

アプリケーションが Google Cloud のコンテナで実行されるようになったら、依存関係を段階的にモダナイズできます。古いオンプレミス データベースに接続する代わりに、Cloud SQL などのマネージド サービスに接続するようにアプリケーションを構成できます。これにより、データベース管理の負担が軽減され、信頼性が向上します。

アプリケーションがクラウドで実行されるようになったので、Google Cloud のオペレーション スイート（Cloud Monitoring、Cloud Logging）を使用して、パフォーマンスに関する詳細な分析情報を取得できます。このデータは、ボトルネックを特定し、モダナイゼーションの次のフェーズを計画するのに役立ちます。次のフェーズでは、アプリケーションの特定の部分を個別のマイクロサービスにリファクタリングし、パフォーマンスとアジリティをさらに最適化するといった処理が考えられます。