クラウド移行でアプリ独自のSLAとクラウドの各機能を深く理解することの重要性とは：.NET 5モダナイズ入門（4）

既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する連載。今回は、SLAの重要性およびAzure App Serviceと組み合わせる機能における注意点を紹介します。

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

　既存の.NET Frameworkアプリの.NET 5への移行に関する考慮事項やレガシーアプリのモダナイゼーションについて解説する本連載「.NET 5モダナイズ入門」。今回は、「Microsoft Azure」のPaaS「Azure App Service」（以下、App Service）を中心に「その他の機能をどのように組み合わせてモダナイゼーションを進めていくか」を考える際に、アプリ独自のSLA（Service Level Agreement）と各サービスを深く理解することの重要性について説明します。

アプリケーション独自のSLAを締結することの重要性

　「アプリケーションをデプロイする環境としてクラウドサービスを利用し、その機能をどのように組み合わせるか」を決める上で、最初に決めなければいけないことは、ビジネス要件から導き出し、定量化した「アプリケーションが目標とするサービスレベル」と「そのサービスを実装するために投入してもよいコスト」です。別のいい方をすると「コスト、人的リソースから考え“何を諦め”、“どんな時にどれくらいの時間サービスが止まるのか”を決める」ことです。

　社内／社外向けにかかわらず、（特に小規模、中規模の）アプリケーションは、有事に担当者が頑張ることを前提に明確な根拠や定量化された数字の裏付けがないまま「常に稼働していて当たり前」という「あるべき論」に基づいて運用されていることが多く、「有事の際の緊急連絡先が決まっているだけ」といった「数値の裏付けのない稼働前提の規定」も多く見られます。この前提だと、有事に安易な徹夜作業などが発生して、昨今の働き方改革の流れに逆行するだけではなくコストも増大するので、残念ながら誰も幸せになれません。おそらくユーザーへの悪影響も最小化できない可能性が高いでしょう。

　ですが、クラウドを利用する場合、そもそもクラウドサービス自体にSLAが設定されており、最初から「必ず一定の割合で止まる」ことが想定内とされています。そして、その部分は利用者がコントロールできません。そのため、社内でクラウド移行の決裁を取る際に、具体的な数値で稼働保証に対する合意を取り付けられないと、その点を指摘されてクラウド移行が頓挫してしまう可能性があります。また、一定の値以上に稼働率を上げようとすると指数関数的にコストが増大するので、コストパフォーマンスについても数値に基づいた合理的な説明が難しくなります。

　従って、（本来レガシーアプリケーションでもそうあるべきですが）アプリケーションのモダナイゼーションを進めてクラウドへのデプロイを検討する場合、たとえ社内システムでも、規模の大小にかかわらず提供部門と利用部門の間でSLAを結ぶ前提で進め、「必ず一定の割合でアプリケーションは落ちる」ことを明文化してユーザーに認識していただくことお勧めします。

　提供するサービスと、それに要するコストについて、定量的に合意する前提とすることで、クラウドのコストとSLAを根拠に「選択した機能の組み合わせで、アプリケーションとして、どのくらいのコストで、どのレベルのサービスが提供できるか」を数値化しながら設計できるので、費用対効果のバランスや、ユーザーの利用シナリオに沿った設計になっているかどうかを現実的な目線で判断できます。

　例えば、App ServiceのSLAでは月間稼働率が保証されています。その裏付けの下で社内向けのアプリケーションのSLAを設定する場合、月間稼働率の他に「予想されるアプリケーションが稼働できなくなってしまうトラブルの一覧」と「それぞれの場合の予想される復旧に要する標準的な時間の見込み」などを具体的にユーザーに提示して、要件定義の段階でユーザーと合意したトラブル時の具体的な対処プロセスまで決めておくのが理想的です。

　なおApp ServiceのSLAについては、参考情報として「App ServiceのSLA」をご確認ください。

開発終盤でクラウドの構成に変更が入る可能性を想定内とする

　ここまで述べたように、アプリケーションのサービスレベルと運用コストを定義した上で、それを満たせるような機能の組み合わせを考えていくには、そのクラウドサービスにかなり詳しくない限り、最初に構成を決めたとしても使ってみないと分からないことがたくさんあります。例えば、具体例を後述しますが、App Service一つとってもさまざまなハマりどころがあるので、思い通りに使いこなすにはかなり細かいレベルで仕様や機能を理解することが必要となります。

　開発最終段階のプロセスでこのような仕様に関わる問題が判明して、決定しているクラウドの構成で既にユーザーと約束している機能が実装できなくなると、技術面、営業面のどちらにおいても調整が非常に厄介になってしまいます。そのような状況において、クラウドの構成を変更すれば解決できる方法があったとしても、今さら構成変更ができない（言い出せない）という理由で、無理筋な方法で突き進まざるを得なくなり非常に苦しんでしまうケースを何度か見聞きしています。

　そのような事態を防ぐには、ドキュメントをしっかり読んだ上で、アプリケーションに適合する構成を決めて、PoCによる検証で動作の裏付けを確認する必要があります。それでも取りこぼしが発生した場合に備えて、開発終盤でクラウドの構成に変更が入った場合のアプリケーションコード変更の作業も含めたリスクを見込んでおき、規模の大小はあるとして最初から関係各所と合意しておくことを強くお勧めします。

　このような仕様に関わる問題については、オンプレミスの場合は、開発部門でコントロールできる範囲が広く、さまざまな対処方法を適用できるので、最終的にどうにかできてしまう可能性が高いでしょう。一方クラウドの場合（特にPaaSでは）、コントロールできる範囲がオンプレミスより確実に狭いので、対処方法も限られており「できないものはできない」としかならない可能性が高いことに十分にご留意ください。

それぞれのサービスや機能の詳しい仕組みを細かく理解する

　では、AzureでApp Serviceを中心に構成を検討して利用する場合、どの粒度での理解が必要となるのでしょうか。それを肌感覚で感じるために具体的な注意点を幾つか紹介します。

　中には、最初から知識として知っていないと、後から問題が起きて気付いてもリソースを作り直すしか手段がないものもあるので、十分な注意が必要です。

　また、表面的にはアプリケーションコード自体に影響がない注意点も多くありますが、「どのようなプラットフォームにアプリケーションがデプロイされるのか」を理解しながらアプリケーションを設計したり、実装したりすることで、思わぬ落とし穴にハマることを防ぐことができます。その意味で、モダナイゼーションやモダンアプリケーションの開発においては、アプリケーションコードを書く開発者でもプラットフォームの情報にもかなり詳しくなる必要があると考えられます。

　以下、具体例を紹介します。

Azureを含むMicrosoftのサービス間のトラフィックはパブリックIPでの通信でもMicrosoftのネットワークの外に出ない

• 参考情報：マイクロソフトのグローバルネットワーク

　Azureの構成を考える場合、それぞれの機能に関わるトラフィックには、インターネットに出るもの、Microsoftのネットワーク内にとどまるパブリックIPベースのもの、プライベートなものの3つがあります。

　自分の構成の各リソース間は「どのトラフィックなのか」を正しく把握して、要件に応じて適切な対応策を講じることで、よりセキュアな構成となります。特に、「Microsoftのネットワーク内にとどまるパブリックIPベースのトラフィック」は知識として知っておかないと認識できないので、ご注意ください。

App Service作成時には必ず「Premium V3」プランで作成した後、「Standard」など自分の目的のプランに変更する

　この操作によって、必ず最新の「スケールユニット」（説明は後述）にアプリケーションが作成されます。なお、スケールユニットには3つの世代があり、一番古いスケールユニットでは「リージョンVNet統合」が使えないなどの制限があります。

　なお、古いスケールユニットを新しいスケールユニットに変更することはできません。よって、新規にリソースグループを作成した上で、Premium V3プランのApp Serviceを作成して、自分の目的のプランに変更する作業をやり直す必要があります。

　リージョンVNet統合はそこそこの頻度で使いたくなる機能です。最新のスケールユニット上に自分のアプリケーションを作ることをお勧めします。

　これは知識として知らないと絶対に想像もつかないポイントです。事前の調査がとても重要であることが分かります。

　スケールユニットとは下記参考情報にある通り、アプリケーションをホストし実行させるサーバをセットにしたものです。

• 参考情報：What Is an App Service Scale Unit?

App Serviceにデプロイしたアプリケーションは230秒のタイムアウトがあり、タイムアウト時間は変更できない

　App Serviceの「フロントエンド」（説明は後述）には、「Azure Load Balancer」の230秒のタイムアウトがあります。フロントエンドは複数の利用者で共用されており、長時間タイムアウトしないセッションは、共用環境では他の利用者に影響を与えてしまうので、タイムアウト時間を変更できません。

　これは、App ServiceがPaaSであり、複数の利用者でリソースを共用することでリーズナブルなコストで提供されている以上、仕方がありません。

• 参考情報：230秒後に要求がタイムアウトになるのはなぜですか？

　どうしても長時間のバックグラウンド処理が必要な場合は、Windowsだけの対応となりますが、「Azure Webジョブ」を使用します。

• 参考情報：Azure App ServiceでWebジョブを使用してバックグラウンドタスクを実行する

　フロントエンドは下記参考情報にある通り、プロキシとして機能して、着信したHTTPリクエストをスケールユニット内のアプリケーションとそれぞれの「ワーカー」間に分配します。フロントエンドは共用で、ワーカーはアプリケーション専用のものが与えられます。

• 参考情報：Front End
• 参考情報：Web Workers（ワーカー）

App Serviceにおいて規定で与えられる「xxxxx.azurewebsite.net」のURLは無効にできない

　App Serviceで作成したアプリケーションには既定で、「xxxxx.azurewebsite.net」（xxxxxは作成時に設定したWebアプリ名）というURLが設定されますが、独自ドメインを設定した場合、xxxxx.azurewebsite.netは不要となり、無効にしたくなります。

　xxxxx.azurewebsite.netへのアクセスは、「web.config」の設定で独自ドメインにリダイレクトさせたり、<defaultDocument enabled="false">を設定してエラーにしたりできますが、web.configで設定する限り、HTTPリクエストはワーカーに着信してしまっています。

　なお、「Application Gateway Standard_v2 SKU」を使って、App Serviceのアクセス制限機能でApplication Gatewayの静的VIPに設定された静的パブリックIPからのアクセスのみを許可することで、xxxxx.azurewebsite.netへの着信リクエストをフロントエンドで拒否することができ、xxxxx.azurewebsite.netへのHTTPリクエストがワーカーに着信しなくなるようにすることができます。

• 参考情報：Azure App Serviceのアクセス制限を設定する
• 参考情報：Azure Application Gatewayの機能

　Webアプリケーションを運用する場合、WAF（Webアプリケーションファイアウォール）の導入はほぼ必須です。「Application Gateway WAF_v2 SKU」を使用すればxxxxx.azurewebsite.netへのHTTPリクエストの拒否とWAFの導入ができるので、お勧めの設定です。

App ServiceではPort 80へのHTTPリクエストの着信は拒否できない

　TLS/SSLの設定に「HTTPSのみ」という設定がありますが、これは動作としてはリダイレクトです。リダイレクトしているフロントエンドは共用なので特定ポートを拒否できません。

　通常はリダイレクトで問題ないはずですが、どうしてもPort 80へのリクエストを拒否してPort 443へのリクエストのみを許可したい場合には、下記の公式ドキュメントにあるように「App Service Environment」（ASE）で「ネットワークセキュリティグループ」（NSG）のポート拒否を利用する必要がありますが、ASEは通常のプランより高額なので想定していたコストをオーバーしてしまう可能性が高くなります。

　Port 80へのHTTPリクエストをリダイレクトすることと、拒否することは意味が違うので、この辺りも正確に把握して、要件に反映しておかないと落とし穴にハマってしまいます。

• 参考情報：App Service Web アプリ内のポートをブロックする方法は？

次回は、Webアプリケーション用の構成について、最後のまとめ

　ここまで紹介したApp Serviceの注意すべきポイントは、それぞれの説明で公式ドキュメントへのリンクを案内していることからも分かる通り、全てMicrosoftの公式ドキュメントに記載があります。既にAzureに慣れている方なら基本的な内容かもしれませんが、Azureに不慣れな場合、膨大なドキュメント全てに目を通して初見でこのようなポイントを適切に把握して理解するのは至難の業です。

　ですが、スケールユニットの世代に関するポイント以外はPoCで細かく検証すれば洗い出せる内容となっています。そういう意味でも、ドキュメントベースの調査だけではなくPoCによる検証がとても重要です。

　今回説明したSLAやApp Serviceとその周辺機能の詳細については、一昔前であればプロジェクトマネジャーやプロダクトオーナー、インフラ担当などのカバー範囲であり、アプリケーションコードを書く開発者の方から見ると、自分のカバー範囲外の内容に受け取れます。

　繰り返しになりますが、モダンアプリケーションの開発では、アプリケーションコードを書く開発者であっても製品設計やサービスプラットフォームの技術情報にも明るいことで完成度に大きく寄与できるので、今後もさらに広い視点が重要になります。

　次回はデータベースや認証も含めて、Webアプリケーション用の構成について、最後のまとめを説明します。

筆者紹介

鈴木友宏

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

Microsoft MVP for Developer Technologies