クラウドがよく分かる！お役立ちコラム

Azure SLAとは？提供サービスが定める品質水準と保証の仕組みを解説

• #自動復旧

この記事でわかること

昨今のシステム開発において、Azureなどのクラウドプラットフォームサービスは利便性や信頼性が高く欠かせない存在となりました。可用性が求められるクリティカルなシステムにおいても充分な性能を発揮し、様々な場面で利用されてきました。とはいえ、物理的な障害やメンテナンスによる一時的な停止の可能性はあり、100%の稼働を保証することは困難です。そのため、サービス提供会社はサービスの品質をSLAと呼ばれる契約事項にまとめています。

この記事ではAzureで定められるSLAの内容を解説し、具体例を交えて紹介していきます。SLAの理解を深め、システム要件に合わせたサービス選定や組み合わせの参考にしてみてください。

×

Azure SLAとは

Azure SLAの概要

SLA（Service Level Agreement）とは、提供するサービスの品質や保証範囲を定量的に示した指標で、サービス契約時に交わされる合意事項です。AzureのSLAでは、保証される稼働率の閾値と、それを下回ったときの返金可能な割合が併せて示されています。返金は申告制となっており、Microsoftに必要な情報を提出することで審査を通して承認される仕組みです。

保証される稼働率は条件によって変動しますが、99.9%以上など高い水準でまとまっており、継続性の高い運用を保証する品質目標が掲げられています。逆にSLAで示された稼働率を下回らない場合は、障害などで停止してもSLAの返金の対象にならないことには注意が必要です。SLAは年に数回の頻度で更新されていますので、常に最新版が出ていないかチェックしておきしましょう。

Azure SLAで定められている項目

AzureのSLAでは、保証範囲となる稼働率の基準値とサービスクレジットが定められています。

• 稼働率
  • サービスの総利用時間に対して実際に利用できた時間の割合
  • 障害や緊急対応などによるサービスのダウンタイムが増えると稼働率が下がる
  • 予定された更新などによるダウンタイムは対象外
• サービスクレジット
  • サービス利用に対して支払った金額のうち、申し立てによって返金可能な割合

なお、これらの項目はAzureのサービスごとに決められています。Azureサービスによって稼働率の根拠は異なり、例えばAzure Virtual Machinesのように常時稼働が求められるインフラサービスであれば稼働時間が基準になりますし、Azure Functionsのようにリクエストに応じて動作するサービスであれば実行回数が基準になります。

また、同じAzureサービスでもプランや条件によって稼働率の算出方法やサービスクレジットは異なります。例えば、Azure FunctionsのPremiumプランは従量課金プランと違って、インスタンスの稼働時間で課金される方式のため、稼働率の考え方が異なります。

保証の適用条件

Azure SLAで定められた稼働率に満たなかった場合、サービスクレジットに応じて利用料金の返還が受けられます。返還される金額は、Azureサービスの利用料金の中から該当するサービスクレジットの割合によって算出されます。そのため、無償のサービスは対象外となっています。

返還にはMicrosoftへの申請が必要で、停止したことを証明するために下記の情報を揃えてからカスタマーサポートに申し出る必要があります。

1. インシデントの詳細な説明
2. ダウンタイムの発生日時および継続期間に関する情報
3. 影響を受けたリソースの名前
4. 影響を受けたユーザーの数および所在地
5. インシデントの間に発生したエラーの説明

なお、申請はインシデントの発生から60日以内に行う必要があるので、予めログの収集方法や申請手順を整理しておきましょう。

Azure SLAの具体例

Azure SLAの稼働率の算出方法はサービスごとに異なりますので、その具体例を紹介していきます。

Azure Virtual Machinesの場合

当該月に稼働した仮想マシンの合計利用時間を100%として、仮想マシンへのネットワーク接続ができなかった時間を差し引いた分の全体に対する割合が稼働率となります。

月間稼働率[%]＝((最大利用時間[分]-ダウンタイム[分])/最大利用時間[分])*100

単一の仮想マシンであれば1台分の利用時間ですが、ゾーン冗長や可用性セットで複数デプロイされている場合はその台数分の累計利用時間で算出されます。

サービスクレジットと保証の条件となる稼働率の組み合わせは下記の通りです。

複数の仮想マシンで冗長化された場合

単一の仮想マシンの場合

冗長化構成では、全ての仮想マシンが停止する可能性が低いため、稼働率の基準が高めに設定されています。一方で単一構成では、利用するディスクによってサービスクレジットが異なり、ディスク性能が高いほど保証される稼働率も高くなっています。

Azure Batchの場合

Azure Batchは要求ごとに実行されるサービスであり、稼働率は下記のように算出されます。

稼働率[%]＝100[%]-平均エラー率[%]
平均エラー率[%]＝各時間のエラー率合計/当該期間の合計時間数
エラー率[%]＝1時間中で失敗した要求数/1時間中での総要求数

失敗した要求とは、エラーコードかHTTP408を返した要求、あるいは5秒超過して成功した要求を指します。なお、要求のなかった時間はエラー率0%としてカウントし、利用がなかった場合でも当該期間の合計時間数に含まれます。

また、サービスクレジットと稼働率の組み合わせは下記の通りです。

Azure Batchでは、要求数と応答結果が根拠となる情報であるため、確認できる態勢を整えておきましょう。

稼働率向上を支えるAzureの仕組み

Azureでは、システムの稼働率を高めるためにインフラの強化や改善が行われています。システムの長期運用において障害やメンテナンスによる一時的な停止は避けらませんが、その影響を極力減らすための対策が採られています。

例えば、従来ではホスト側でソフトウェアの更新を行うと、そこに依存する仮想マシンの再起動が必要でしたが、ホットパッチによって新しいバージョンへのリダイレクトを行うことでダウンタイムを無くしています。さらに、同様のメンテナンスがファームウェアレベルでも行えるようにハードウェアの改善も図られています。

再起動や一時停止が避けられない重要なメンテナンスに関しては、利用者の都合の良いタイミングで更新できるように猶予期間が設けられおり、プロジェクトごとに独立したメンテナンスが可能です。また、仮想マシンごとホスト間を移動するライブマイグレーションを使用することで、数秒程度で更新されたホストに移行することを可能にしました。

また、障害による影響を抑えるために、AIによる障害発生を予測して事前に環境を移行する措置も採られています。Microsoftの持つ膨大な運用実績に基づく確度の高い予測により、兆候を未然に察知して障害時よりも短く安全な移行を実現しています。

SLAとSLOの違い

SLO（Service Level Objective）とは、サービス提供会社が目標とする品質基準を具体化した指標です。目標値と併せて、その達成に向けたサービス改善や態勢作りを公表することで、サービスの安全性の根拠を示すことができます。SLAよりも高い基準で設定され、今後のサービス運営をより良くするための努力目標として掲げられます。そのため、SLOで定められる指標は実際に保証される範囲とは異なり、契約内容には含まれないことには注意が必要です。

一方で、SLAは提供サービスの品質を明確化するもので、サービス提供会社との契約合意を交わすために示されています。また、保証するサービス品質に満たなかった場合におけるサービス提供会社の対応が併せて示されています。例えばAzureでは、サービスの稼働率に応じた利用者への一部返金を補償内容として明記しています。