.NET 5移行前に知らないと損する、アプリモダナイズのための確認事項： .NET 5モダナイズ入門（3）

既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する連載。今回は、.NETアプリケーションのモダナイゼーションを進める前の確認事項を紹介します。

[鈴木友宏，NTTデータ先端技術]

　既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する本連載「.NET 5モダナイズ入門」。前回は、.NET 5世代のアプリケーションライフサイクルマネジメント（ALM）および、.NET Frameworkから.NET 5へ移行する際におけるワークロードごとの方法の概要や参考情報を紹介しました。今回からモダナイゼーションの進め方について解説していきます。

　オンプレミスのアプリケーションのモダナイゼーションを進め、既存の.NETアプリケーションをクラウドにデプロイすることで、DevOpsによる開発の高速化と運用の効率化、セキュリティの強化、ダウンタイムの最小化や運用コストの最小化などさまざまなメリットを享受できます。

　ですが、モダナイゼーションを進める前に、そのアプリケーションがオンプレミスの環境上で“適切に”構成されているかどうかを確認することが必要です。適切に構成されたオンプレミスアプリケーションはモダナイゼーションの難易度も低くなり、改修の手間も軽減されます。従って、モダナイゼーションの前に、対象となるアプリケーションが抱える問題を把握し、改善することが重要です。

アプリケーションのモダナイゼーションの前に確認すること

　アプリケーションのモダナイゼーションを考える場合、まずは、そのアプリケーションが持つ問題について、「モダナイゼーションに起因する問題」「たまたまオンプレミスでは表面化しにくいだけで、単にそのアプリケーション自体に起因する問題」を正しく把握することが重要です。問題を詳しく分析すると、一見モダナイゼーションに起因するように見えても、実は単なるアプリケーション自体の問題であることも多く見受けられるためです。

　そして、アプリケーション自体の問題を解決しないままモダナイゼーションに着手してしまうと、2つの要因に起因する複合した問題が発生し、状況の把握や問題の解決に必要以上に時間がかかってしまいます。

　よって、まずはモダナイゼーションに着手する前に、そのアプリケーションが潜在的に持つさまざまな問題を改善し、アプリケーションの品質を向上させることが重要です。

モダナイゼーションに無関係なアプリケーション自体の問題を改善する

　一見モダナイゼーションに起因する問題に見えるが、実は単なるアプリケーション自体の問題であるケースについて、幾つか具体例を挙げて説明します。

再起動への対応など、運用による問題の回避への対応

　例えば、「ASP.NET」などのWebアプリケーションであれば、理論的には、予期しないサーバの再起動を防ぐことはできません。従って、予期せぬサーバの再起動によってアプリケーションが強制終了してしまった後にアプリケーションが再起動した場合でも、処理途中の処理が正しく継続できることが求められます。

　ですが、このような事象への対処をアプリケーション側で全て対処しようとすると、アプリケーションコードが複雑になり、開発時の工数もかかるため、アプリケーション側で完全には対応せず、再起動時に特定の手順を行う運用で正常な動作を保証しているケースがしばしば見受けられます。これは、オンプレミスのように再起動の発生を運用側の都合でコントロールできる状況では影響をコントロールできますが、クラウドのサービス、例えば、「Azure App Service」にデプロイした場合、再起動の主導権はクラウドのプラットフォーム側にあり、利用者が予測できない再起動は当たり前に発生してしまうので、問題が顕在化してしまいます。

　このように、既存のアプリケーションで「運用による問題の回避」が前提になっている箇所は、そもそもアプリケーションが持つ問題をその場しのぎで回避している可能性があるので、根本的な原因を確認し問題があれば改善することをお勧めします。

外部リソースのハンドリング

　他には、外部リソースの適切なハンドリングも見落としがちです。例えば、「HTTP Client」のような外部リソースへの接続は、インスタンスを毎回生成せず、再利用するのが適切な対応ですが、オンプレミスにおいてOS上で当該のアプリケーションのみが稼働しているような場合には、リソースに余裕があるので、問題が表面化しにくい状況になります。ですが、例えば、Azure App Serviceにデプロイした場合、リソースは共有されているのでSNAT（Source Network Address Translation）ポートの枯渇が発生しアプリケーションがエラーとなってしまう場合があります。

• 参考情報：アウトバウンド接続でのSNATの使用 - ポートの枯渇

　このケースは、クラウドに問題があるわけではなく、そもそも、HTTP Clientのインスタンスを毎回生成してポートを多数消費するような構成になっている時点で、不必要にリソースを消費しており、メモリリークの原因にもなるので、明らかにアプリケーションとして問題があります。ですが、オンプレミスでは問題が表面化しにくいので、クラウドにデプロイして初めて気付くことも多いのです。

認証情報の取り扱い

　Webアプリケーションの構成としては、比較的古い場合、3レイヤーアーキテクチャ、最近の場合、「クリーンアーキテクチャ」などが採用されていますが、どのような構成になっているとしても、セキュリティの観点で見たときにそれぞれの構成におけるレイヤーの境界をまたがないように認証情報が閉じていることが推奨されます。

• 参考情報：一般的なWebアプリケーションアーキテクチャ

　例えば、小規模のASP.NETアプリケーションにおいて、DMZ（DeMilitarized Zone）に配置されるWebフロントエンドアプリケーションの設定ファイルに、RDBMSへの認証情報（接続文字列やログインアカウント、パスワード）が記述されているような構成を例に考えます。このような構成は、大規模なアプリケーションではまず見受けられませんが、小規模のアプリケーションでは普通に見受けられます。

　この構成には、改善すべき点が2つあります。

　まず、データベースのようなインフラストラクチャに関する認証情報をDMZに配置するアプリケーションの構成ファイルに記述しないようにします。WebフロントエンドアプリケーションからはREST APIを呼び出し、プライベートネットワーク上のAPIアプリケーション内でRDBMSへ認証します。

　その上で、REST APIへの認証情報はアプリケーションを構成するファイルから分離し、外部から注入できるように構成します。

　ここまでは、オンプレミスのアプリケーションでも必須の要件です。

　可能であれば、WebフロントエンドアプリケーションはREST APIに対する有効期限付きの認証情報をオンデマンドで取得するような構成が理想です。このような構成は、オンプレミスでも可能ですが、結構な手間がかかってしまいます。一方、クラウドにデプロイすれば、クラウドが提供する機能を利用して比較的容易に実装可能です。このようなアプリケーション自体の問題とモダナイゼーションの境界線上にあるような問題に適切に対処するには、以下で説明するように、クラウドが提供する機能を把握することが効果的です。

クラウドが提供する機能を把握する

　アプリケーション自体に存在する問題が解決されたら、次に考えることは、モダナイゼーションを進めるに当たって、「クラウドがどのような機能を提供しているのか」を把握し、皆さまのアプリケーションで「どうやって効果的にクラウドが提供する機能を利用するか」を検討することです。

　.NETアプリケーションの場合、「Microsoft Azure」との相性が一番良いので、Azureを例に考えてみましょう。Azureを利用する場合、まずは、「IaaSとPaaSどちらを利用するのか」を選択することになりますが、AzureはPaaSの機能が充実しているので、クラウドのメリットを最大限享受したい場合、PaaSの利用がお勧めです。ただし、アプリケーションの改修の作業量は大きめになってしまいます。

　PaaSを利用する場合、Azure App Serviceを中心に構成を検討していきます。Azure App Serviceは下記の公式情報にある通り、Webアプリケーション、REST API、およびモバイルバックエンドをホストするためのHTTPベースのサービスです。

• 参考情報：App Service の概要

　逆に、最低限度のアプリケーション改修でAzureを利用したい場合、IaaSの利用がお勧めです。ですが、Webアプリケーションをデプロイするプラットフォームとして考えた場合、AzureのIaaSは将来的なPaaSの利用を視野に入れ過渡的に利用する側面も大きいことに注意してください。

　IaaSを利用する場合、「Windows Virtual Machines」を中心に構成を検討していきます。Windows Virtual Machinesは、下記の公式情報にある通り、Azureが提供するスケーラブルなオンデマンドコンピューティングリソース、つまり、CPUやメモリなどのスペックを利用状況に合わせて決められた範囲で自由に変更しながら利用できる仮想マシンのサービスです。

• 参考情報：AzureのWindows仮想マシン

　なお、仮想マシンにはもちろんLinuxもあります。.NETのオンプレミスアプリケーションはWindowsで運用されていることがほとんどでしょうから、仮想マシンもWindowsを利用するケースが多くなるので、本連載ではWindows Virtual Machinesを前提として説明します。

　PaaSとIaaSのどちらを利用するかが決まったら、「その他のサービスをどのように組み合わせるか」を検討していきます。なお、下記の公式情報にある通り、AzureにはAzure App ServiceやWindows Virtual Machinesの他にもコンテナを使うサービスなど、幾つかのアプリケーションの実行環境が提供されており、それらを選択する際のガイドラインも提示されています。

• 参考情報：アプリケーションのAzureコンピューティングサービスを選択する

　上記のようにたくさんのサービスが提供されていますが、初めてモダナイズを行うケースでは、Azure App Serviceが難易度と享受できるメリットのバランスが良く、お勧めです。

　次回は、Azure App Serviceを中心として「その他の機能をどのように組み合わせてモダナイゼーションを進めていくか」のポイントを説明します。

筆者紹介

鈴木友宏

NTTデータ先端技術株式会社

Microsoft MVP for Developer Technologies