クラウド移行でアプリ独自の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を中心に構成を検討して利用する場合、どの粒度での理解が必要となるのでしょうか。それを肌感覚で感じるために具体的な注意点を幾つか紹介します。

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

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

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