DXが叫ばれている今、多くの企業がレガシー資産の改修に課題意識を感じています。しかし、どのような手法を用いてレガシー資産をモダナイズ化すればよいのか、詳しく把握していないケースがほとんどでしょう。そこで本記事では、.NETにおけるレガシー資産のモダナイズ化の方法やポイントについて詳しく解説していきます。
.NETのレガシー資産をモダナイズ化する5つの方法
今も利用している古いシステムのOSやサーバーの保守が切れており、リプレイスが必要だと認識しているものの、システムのモダナイズ化の方法が解らない、という話をよく聞きます。
レガシー資産をモダナイズ化する方法として、リホスト、リファクター、リアーキテクト、リビルド、リプレイスの5つの方法が挙げられます。モダナイズ化するシステムに合わせて、いずれかの方法の利用を検討してください。
次から5つのレガシー資産のモダナイズ化方法について紹介します。
リホスト
Microsoft Azureは2010年にサービスを開始しており、当初から.NET Framework 4をサポートしていました。さらに2015年にはAzureでの稼働を前提に.NETを利用したシステムも開発されています。そのため、2015年以降に開発されたシステムであれば、ソースコードを修正することなく既存のシステムをAzureに移せるかもしれません。
このようにソースコードをそのままオンプレミスからAzureに移行するのがリホストです。レガシー資産のモダナイズ化ではもっとも簡単な方法です。とはいえこの方法では.NETの新機能を利用できず、近い将来に.NETのサポート切れに伴う改修が必要です。今後のサポートを考慮し、.NETの新バージョンへの対応も必要と言えるでしょう。
リファクター
リファクターとは、アプリケーション（以下アプリ）の再パッケージ化により、PaaSもしくはIaaSに移行する方法です。外部から見たプログラムの動作を変えずにソースコードを修正し、最新のパッケージを利用することで、Azureでサポートしている.NETを利用した環境に移行します。
例えばサポートが切れている古いバージョンのSQLServerに接続するためのパッケージを、Azureでサポートしている最新パッケージに変更するために、ソースコードを修正して移行するといったケースが該当します。
この方法でモダナイズ化するメリットは、アプリのスケールを最大化できる点です。そのため、外部向けWebサイトのレガシー資産をモダナイズ化する際には、特に有効です。
リアーキテクト
Azureがスタートした2010年以前の.NET Frameworkを利用にしたレガシーシステムは、そのままではAzureに移行できません。利用するにはアプリのソースコードをクラウドでの利用を前提とした最新の.NETに合わせて修正し、アプリを作り直すリアーキテクトで移行します。
この方法では、開発当時には実現できなかった機能もソースコードを修正することで実現できるケースが幾つもあります。アプリをアーキテクチャレベルから見直し、最新化したのちに個別にデプロイしてアーキテクチャを分散することも可能です。
そのため、この方法は大規模分散アプリを対象としたレガシー資産のモダナイズ化におすすめします。
リビルド
レガシーなシステムが昨今のビジネスのやり方に合っているとは限りません。システムからはみ出した処理をExcelなどで個別に管理しているケースもあります。そのように今の時代に合わなくなったレガシーなシステムは、いつかは作り直さなければなりません。
そのように時代に合わなくなったレガシーなシステムをそのままクラウドでも利用するのはなく、最初からクラウドの利用を前提にゼロから作り直すレガシー資産のモダナイズ化がリビルドです。
この方法では、プラットフォームとなるサーバーとOSなどをAzureのフルマネージドサービスに任せられることからインフラコストの削減が可能です。またAzureの既存のサービスを組み合わせることで、アプリの開発期間を短縮できます。
このようにゼロからシステムを再構築するのであれば、現状の業務を整理して既存のシステムがカバーしきれていない業務を洗い出し、それらを再構築するシステムに組み込むことが可能です。さらにクラウドの利用を前提にしておけば、ほかのシステムとの連携や拡張が可能などメリットの多い方法です。
リプレイス
今のクラウドで利用できるサービスは、データセンターに用意された物理的なサーバーや仮想的なサーバーを借りて利用するだけではありません。クラウド上のアプリやサービスを時間単位で借りることが可能です。そしてこの方法は、SaaS（Software as a Service）と呼ばれています。
SaaSのメリットは、クラウドを運営する企業にアプリやサービスに必要な機器やソフトウェアの管理をすべて任せられる点です。そのため、安い費用で常に最新のテクノロジーを利用できます。また提供されるサービスを組み合わせてシステムを構築できるので、短期間でシステムを開発できる点もメリットと言えます。
そして問題を抱えているシステムやハードウェア、ソフトウェアなどのレガシー資産のモダナイズ化方法としても有効な方法です。
.NETアプリ移行設計におけるポイント
.NETを利用したレガシー資産のモダナイズ化では、IISのバージョン対応が必要です。特にIIS6.0以前から稼働しているシステムでは、最新のIISに対応できないことが多いので事前チェックが必要です。
もしチェックでNGになれば、そのままではクラウドに移行できず、リファクターやリビルドを検討しなければなりません。次から最新のIISでの稼働が可能かを見極めるための2つのポイントについて解説します。
ワーカープロセスの分離管理
Webサーバーとして長く利用されているIISは、セキュリティ強化と堅牢性向上を目的にバージョンを繰り返してきました。その中でも大きな変更があったのがIIS6.0です。ワーカープロセスの分離管理は、IIS6.0から導入された技術です。このため、IIS6.0より前に作られた.NETのアプリは、ワーカープロセスの分離管理への対応が求められます。
なおワーカープロセスの分離管理とは、Webサーバーで動作するアプリのプロセスをWebサーバーから独立させて運用する仕組みです。これにより、アプリに障害が発生してもWebサーバーをダウンさせずに運用できます。
そしてワーカープロセスの分離管理では、アプリケーションプールを利用します。そのためアプリケーションプールに対応した.NETの利用が必要です。レガシー資産のモダナイズ化を検討する際にチェックしてください。
パイプラインの確認
IISのバージョンの違いで重要な要素がパイプラインです。パイプラインとは、IISからプロセスが分離しているアプリとIISを接続するための仕組みです。統合パイプラインとクラシックパイプラインの2つを選択できます。そしてIIS6.0以前から使われている古い仕組みがクラシックパイプラインで、IIS7.0から導入された仕組みが統合パイプラインです。
統合パイプラインでは、IISとアプリが密接に結びつくことから、アプリは必要なすべての要求を確認し、実行した結果を即座に書き出すことが可能です。しかしクラシックパイプラインは、ブラックボックスのように動作するので、IISの書き出し要求に応じて実行した結果を書き出します。
IIS7.0に開発されたアプリでは統合パイプラインが使われています。もし、古いアプリが動作していない場合は、クラシックパイプラインに切り替えてチェックしてください。
