Azure App Serviceと組み合わせて移行する認証、データベース、可用性、バッチ：.NET 5モダナイズ入門（5）

既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する連載。今回は、Azure App Serviceと組み合わせて移行する認証、データベース、可用性、バッチについて紹介します。

[鈴木友宏，NTTデータ先端技術株式会社]

　既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する本連載「.NET 5モダナイズ入門」。今回は、前回の続きとして、「Microsoft Azure」上で「Azure App Service」を中心に、その他の機能をどのように組み合わせてモダナイゼーションを進めていくかを考える際の、認証、データベース、可用性、バッチの移行を紹介します。

独自のアプリケーション独自の認証を使用していればIDaaSに乗り換えを検討する

　社内システムなどの小中規模のシステムにおいて、認証に関して最も重要なのは「可能な限り認証機能を独自実装しない」ことです。アプリケーション独自の認証機能で、例えば、「Azure Active Directory」（Azure AD）のような認証プラットフォームを独自実装するのは時間も費用もかかります。また、独自実装で既存のサービスと同様のセキュリティを保証するのも困難です。従って、古い社内システムなどでそのアプリケーション固有のIDとパスワードで認証しているような場合は、モダナイゼーション時にオンプレミスの認証プラットフォームや、Azure ADのようなIDaaS（Identity as a Service）の認証サービスへの乗り換えの検討をお勧めします。

　例えば、オンプレミス上の社内システムのASP.NETアプリケーションをAzureでモダナイゼーションする場合、既に、社内でActive Directoryによるシングルサインオンが導入されているなら、「Azure AD Connect」の導入を検討するとよいでしょう。

　なお、システムが大規模なECサイトなどの場合、要件上、独自認証がフィットしますが、そのようなシステムならそのECサイト自体が大規模なサービスの一部として存在しており、既に独自の高機能な認証プラットフォームが存在し、それを利用するようになっていると考えられます。

　Azure AD Connectの詳細は下記の参考情報をご覧ください。

• 参考情報：Azure AD Connectとは

　Azure AD Connectを導入すると、ユーザーはクラウドとオンプレミス両方のリソースに同じパスワードを使用してサインインできます。また、MFA（Multi-Factor Authentication：多要素認証）も利用できます。MFAでは例えば、PCの他にiPhoneやAndroidのスマートフォンの認証を必須にできます。

　なお、下記の参考情報にも記述があるように、MFAはアカウントの保護にとても効果的です。

• 参考情報：条件付きアクセス:すべてのユーザーに対してMFAを必須にする

　クラウドとオンプレミスのIDを統合する場合、さらにMFAを導入する場合でも、既存のアプリケーションの設計にもよりますが、たいていの場合、簡単な設定だけで複雑な実装はおおむね不要であり、軽微なコード修正でマイグレーション可能です。これらの認証をASP.NETアプリケーションで利用するためのSDKやサンプルコードも提供されています。

• 参考情報：Microsoft IDプラットフォームのコードサンプル（v2.0 エンドポイント）

　また、オンプレミスとクラウドのIDを統合する場合、IDの連携が確実に動作し、セキュリティを強化することが求められますが、ADFS（Active Directory Federation Services）サーバを監視するツールとして、「Azure AD Connect Health」が提供されています。

• 参考情報：Azure AD Connect Healthとは

データベースに関する留意事項

Azure SQL Databaseへの認証情報の取り扱い

　「Azure SQL Database」への接続文字列の格納には「Azure Key Vault」を使用します。この場合のVaultは「金庫」や「貴重品保管庫」というような意味です。つまり、シークレットやキー、証明書といった重要なリソースを安全に管理するためのサービスです。

　Azure Key Vaultを使うことで、アプリケーションコードや設定ファイル、Azure App Serviceの設定からでも認証情報を分離できるので、アプリケーションのセキュリティを強化できると同時に、その情報にアクセスするための環境依存のパラメーターも分離できるので、デプロイ時の取り扱いも簡単になります。

　具体的には、ポータルから設定できるAzure App Serviceのアプリケーション設定の設定値をAzure Key Vaultに格納したシークレットを参照するように設定した上で、アプリケーションコードからAzure App Serviceのアプリケーション設定の設定値を読むようにします。

参考情報：App ServiceとAzure FunctionsのKey Vault参照を使用する

データベース上の日時の扱い

　オンプレミスで運用されている比較的古いシステムでは、日時データに「DateTime」が使用されていることも多いでしょう。その場合、データベース上のタイムゾーンはJST（日本標準時）の場合がほとんどです。ですが、Azure SQL Databaseでは、タイムゾーンはUTC（協定世界時）固定で変更できません。

　なお「Azure SQL Database Managed Instance」の場合、リソース作成時にのみですがタイムゾーンを設定できますが規定値はUTCとなります。

　従って、オンプレミス上のJSTのタイムゾーンにおけるデータをAzureにそのままマイグレーションすると、時差の違いで面倒が発生してしまいます。解決策としては、AzureのデータベースサービスのタイムゾーンはUTCのままにして、.NETアプリケーション上では、DateTimeの代わりに「DateTimeOffset」を使用することを推奨します。

※注意：Azure SQL Databaseの「Managed Instance」は高価なので、お試しの際は料金にご注意ください。

クラウドにおける冗長性の考え方

　Azure上の冗長性の確保に関しては、サービスによっては「可用性セット」「可用性ゾーン」といった機能があります（サービスによっては対応していないものもあります）。それらの内容を理解する前に、オンプレミスとクラウドにおける、それぞれの冗長性のイメージの違いをシンプルに理解しておいた方が、可用性ゾーンと可用性セットについて理解しやすくなります。

　オンプレミスでは、ハードウェアの障害やOSの更新などに備えてハードウェア自体を冗長化すると思いますが、クラウド上では、Azure App Serviceや「Azure Virtual Machines」などのリソースは論理的な概念であり、物理的なハードウェアと1対1になっているわけではありません。そのため、単に同じリージョン上でクラウド上のリソースを冗長化すること自体には意味がありません。

　例えば、Azure App Service上でハードウェア障害やOSの更新が発生した場合は、Azure App Service上のアプリケーションは別のインスタンスに自動的に移動されます。Azure App Serviceで使用されるアウトバウンドIPが複数あるのはそのためです。アプリケーションのコールドスタートが適切に構成されている場合は、ダウンタイムも発生しません。よって、既定の状態で、ある程度のハードウェア障害やOSなどの更新によるダウンタイムを回避するための機能が存在するので、その対策として、単純に同じリージョン上でAzure App Serviceのリソースを冗長化したとしても可用性は向上しません。

　このようなクラウド特有の構成において、現実的に効果のある冗長性を確保するための手段として可用性セットと可用性ゾーンがあります。

　Azureの可用性セットでは、ディスクやネットワークスイッチの障害など、局所的なハードウェア障害に対して保護されます。

　Azure Virtual Machinesの場合の説明となりますが、可用性セットついて詳しくは以下の参考情報をご覧ください。

• 参考情報：可用性セットの概要

　Azureの可用性ゾーンとは、独立した電源、冷却手段、ネットワークを備えたリージョン内の一意の物理的な場所を表します。1つのリージョン内には最低3つの可用性ゾーンが存在しています。また可用性ゾーンは、リージョン内で物理的に分離されているので、1つのゾーンが障害を起こした場合でも、サービスが継続できます。

　こちらもAzure Virtual Machinesの場合の説明となりますが、可用性ゾーンついて詳しくは以下の参考情報をご覧ください。

• 参考情報：AzureのリージョンとAvailability Zones

　なお、Azure App Serviceは下記の2つの参考情報から、「ゾーンの回復性があるサービス」には含まれておらず、「Upgrade Domain」内に配置されていることが分かります。そのため、そう明言された公式情報がないのですが、Azure App Serviceは可用性セットに配置されていますが、可用性ゾーンには非対応と考えられます（なお、「App Service Environment」は可用性ゾーン対応です）。

• 参考情報：Demystifying the magic behind App Service OS updates
• 参考情報：ゾーンの回復性があるサービス

　このことから、Azure App Serviceはデータセンター内でのディスクやスイッチの障害など、局所的なハードウェア障害からは保護されますが、データセンター全体の障害からは保護されません。

　よって、Azure App Serviceで可用性を向上させたい場合は、ペアリージョン（後述）を利用してアプリケーションを冗長化する必要があります。例えば、日本国内では、東日本リージョンと西日本リージョンがペアになっています。複数リージョンで実行する高可用性の構成について詳しくは下記参考情報をご覧ください。

• 参考情報：可用性の高い複数リージョンのWebアプリケーション

　なお、ペアリージョンには次の特徴があります。

1. 東日本リージョンで、計画メンテナンスの間は、西日本リージョンでは計画メンテナンスは行われない。その逆もしかり
2. 停止によって東日本リージョンと西日本リージョンの両方に影響がある場合、東日本リージョンと西日本リージョンのどちらか一方が優先的に復旧される。従って、ペアリージョンで冗長化することで、可用性を向上させることができる

　ペアリージョンについて詳しくは下記の参考情報をご覧ください。

• 参考情報：ペアになっているリージョンとは

関数アプリ（Azure Functions）やWebJobsによる小規模ツールの置き換え

　関数アプリはマイクロサービスのプラットフォームとして注目されがちです。もちろんその目的で利用するのも、とても効果的ですが、既存アプリケーションのモダナイゼーション時には、オンプレミス上の各種バッチやタスクの代替として利用するととても便利です。関数アプリには、さまざまな数多くのトリガーがあります。バッチやタスクの代替として利用する場合は、「HTTP trigger」「Timer trigger」を利用する場面が多いと考えられます。

　トリガーの種類の詳細は下記の参考情報をご覧ください。

• 参考情報：サポートされるバインディング

　注意点として、関数アプリは長時間実行するようなバッチやタスクには使用できません。関数アプリは、Azure App Service上で稼働するので、Azure App Serviceと同様にHTTPトリガーの関数では230秒のタイムアウトが存在します。また、利用者がコントロールできないメンテナンスによる再起動も発生します。一応、再起動時には実行中の関数がある場合、一定時間待ってくれますが、いつ再起動されても問題ないように「CancellationToken」を利用して「Graceful Shutdown」する構成とし、関数はべき等になるように構成する必要があります。

• 参考情報：実行時間の長い関数を使用しない
• 参考情報：（Graceful Shutdownのための）キャンセルトークン
• 参考情報：同一入力のためのAzure Functionsの設計（べき等性に関する説明）

　時間がかかる処理はAzure App Service（Windows）のみのサポートとなりますが、「WebJobs」を利用します。

　なお、Azure App Serviceは規定で、Webアプリケーション上で20分間アクティビティーがないとタイムアウトする可能性があります。そのため、ポータルなどで「常時接続（Always on）」設定を有効にして、Azure App Service自体のタイムアウトを防ぎ、ジョブが確実に実行されるようにする必要があります。

　なおWebJobsでも、Graceful Shutdownで再起動するときに一定の猶予時間待機し、超過したらプロセスが強制的に終了されます。

• 参考情報：WebJobのGraceful Shutdown

最後に

　これまで見てきたように、.NETのWebアプリケーションのプラットフォームとして考えた場合、オンプレミスの「Windows Server」と比べると、Azure App Serviceや組み合わせて使うサービスには、オンプレミスにはないさまざまな機能が存在します。またIaaSと比べてPaaSの機能には、それらをPaaSとして成立させるための要件に起因するさまざまな「クセ」があることも分かります。慣れないといろいろとつまずいてしまうこともありますが、使いこなせばとても便利です。

　Azureの機能は紹介し切れないほどたくさんあり、日進月歩で機能のアップデートや新機能がリリースされています。アプリケーションのモダナイゼーションはアプリケーション自体とデプロイ環境の両面を一体として進めることで効果が最大化されます。今まさに.NETアプリケーションのモダナイゼーションを進めている方も、今後の課題として検討している方も、今のところクラウドの利用を検討していない方も、まずは一度Azureに触ってみていただければと思います。その「機能」や「クセ」を体感して、より良いアプリケーションの構築と運用の参考としてもらえると幸いです。

筆者紹介

鈴木友宏

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

Microsoft MVP for Developer Technologies