Azureのインフラを理解して、構築したアプリのSLA（稼働率）を計算してみる

Azureのインフラ構成とサービス可用性を高める仕組み

2020年07月06日 08時00分更新

文● 横田力哉／FIXER　編集● 大塚／TECH.ASCII.jp

ハンズオン：SLA（稼働率）を計算してみる

　このように、Azureでは可用性を高めるための仕組みがインフラレベルで備わっていますが、それでもハードウェア障害、データ破損、電力供給の問題などのさまざまな原因によって、クラウドサービスにはダウンタイムが生じます。クラウドを使用したサービスを提供するうえでは、ダウンタイムが生じうることを理解し、またどれくらいのダウンタイムが想定されているのかを把握しておく必要があります。

　おおよそのダウンタイムは、Azureのサービスごとに定められているSLAから計算できます。ここからは、3つのシナリオに分けてSLAを計算していきます。

単体リソースのシナリオ

　まずはApp Service単体のSLAを調べてみます。Azureの各サービスが定めるSLAは、下記のサイトから検索できます。

Azure各サービスのSLA（サービスレベル契約）検索ページ（https://azure.microsoft.com/ja-jp/support/legal/sla/）

　App ServiceのSLAを確認してみると「99.95％の時間において利用可能であることを保証します」とあります。さらに「SLAの詳細」の項を見ると、この稼働率は1カ月（1請求月間）単位で算出すること、算出基準となる稼働時間は分単位で計測することなどが記されています。先に計算したとおり、99.95％のSLAは1カ月間のダウンタイムをおよそ22分未満に抑えられれば達成できます。

　ただし、クラウドサービス側で大規模な障害が発生した場合などには、SLAで定めた稼働率が達成できないこともあります。Azureの場合は、ユーザーが返金依頼を出すことで利用料の一部がサービスクレジットとして返金されます。App Serviceの場合、月間稼働率が99％未満ならば利用料金の25％、99％以上99.95％未満ならば10％を返金する契約になっています。

App ServiceのSLA定義が書かれたページ（https://azure.microsoft.com/ja-jp/support/legal/sla/app-service/v1_4/）

2つのサービスを繋げたシナリオ

　続いて、App Serviceと「SQL Database」を組み合わせてできたWebアプリを想定してみましょう。

　App ServiceのSLAは99.95％、可用性ゾーンを適用したSQL DatabaseのSLAは99.995％と定められています。この場合、どちらかのサービスが停止したらWebアプリが停止するので、Webアプリ全体のSLAは「99.95％×99.995％≒99.945％」になります。このように、複数のサービスを統合して得られるSLAのことを「複合SLA」と呼びます。

　この複合SLAは組み合わせるサービスが多くなればなるほど下がっていきますが、冗長化することで改善することができます。

2つのリージョンに冗長化したシナリオ

　最後に、先ほどのWebアプリ（複合SLA：99.945％）を東日本リージョンと西日本リージョンに複製して配置し、負荷分散サービスの「Traffic Manager」でアクセスを振り分ける構成を想定してみます。

　この構成では、東日本でWebアプリが停止しても西日本のWebアプリで対応できるので、Webアプリが利用できなくなるのは「東日本と西日本のWebアプリが両方同時に停止した場合」、もしくは「Traffic Managerが停止した場合」になります。少し複雑ですが、この構成の複合SLAを計算してみます。

　まず前出の複合SLAから、1カ月の間にWebアプリが停止する確率は「100％－99.945％＝0.055％」です。さらに、東日本と西日本のWebアプリが両方とも停止する確率は「0.055％×0.055％＝0.003025％」です（厳密に言えば東日本と西日本で「同時刻に」停止する確率はさらに低いのですが、ここでは省きます）。ここから、冗長化したWebアプリの複合SLAは「100％－0.003025％≒99.997％」になります。