Azure SLA と複合 SLA

Service Level Agreement (SLA)とは、各 Azure サービスの最小稼働時間と接続性を保証する、Microsoft の正式なコミットメントです。SLA は割合で表されます。たとえば、99.9%とは、ある月にサービスが少なくとも 99.9% の時間利用可能であることを意味します。Microsoft が SLA を満たせなかった場合、顧客は補償としてサービス クレジットを受け取る資格があります。

各 Azure サービスには、azure.microsoft.com/en-us/support/legal/sla/で公開されている独自の SLA ドキュメントがあります。SLA を読むときは、稼働率、その稼働率を達成するために必要な条件（2 つ以上のインスタンスにデプロイするなど）、そしてパフォーマンスが基準を下回ったレベルごとに受け取れるクレジット額を示すクレジット表に注目してください。

SLA の割合は、1 か月あたりに許容されるダウンタイムに換算できます。

• 99.9% = 1 か月あたり最大 43.8 分のダウンタイム
• 99.95% = 1 か月あたり最大 21.9 分
• 99.99% = 1 か月あたり最大 4.38 分
• 99.999% = 1 か月あたり最大 26 秒

これらの数値を理解すると、サービスの SLA がビジネス継続性の要件を満たすかどうかを評価しやすくなります。

アプリケーションがそれぞれ独自の SLA を持つ複数の Azure サービスに依存している場合、全体の可用性は個々の SLA をすべて掛け合わせた値になります。これを複合 SLAと呼びます。いずれか 1 つのサービスが利用できなくなるとアプリケーションも利用できなくなるため、複合 SLA は常に、連鎖する個々の SLA のうち最も低い値を下回ります。

Azure App Service (99.95%)、Azure SQL Database (99.99%)、Azure Cache for Redis (99.9%) を使用するアプリケーションを考えます。複合 SLA は次のようになります。0.9995 × 0.9999 × 0.999 = 0.9984 = 99.84%。つまり、各サービス単体の SLA が高くても、アプリケーションは1 か月あたり最大 2.4 時間利用できなくなる可能性があります。連鎖にサービスを追加するほど、このリスクは高まります。

冗長化を追加すると、複合 SLA を向上させることができます。つまり、サービスのインスタンスを並列で実行し、一方が障害を起こしてももう一方が処理を継続できるようにします。サービスを並列に配置する場合、計算式が変わります。合算した利用不能率は、各サービスの利用不能率を掛け合わせた値になります。たとえば、99.95% の App Service インスタンス 2 つを並列に配置すると、次のようになります。1 - (0.0005 × 0.0005) = 99.9997%。

Azure サービスの中には、無料または共有レベルで使用するとSLA がないものがあります。たとえば、Free (F1) または Shared (D1) レベルの Azure App Service には稼働時間の保証がありません。開発やテストでは問題ありませんが、本番ワークロードで SLA の対象となるには有料レベルを使用する必要があります。本番リソースをデプロイする前に、必ず SLA の条件を確認してください。

Azure Virtual Machines の SLA は構成によって異なります。Premium SSD を使用する単一インスタンス VMの SLA は 99.9% です。同じ VM を可用性セットに配置すると 99.95% になります。2 台の VM を可用性ゾーンにまたがって配置すると 99.99% に達します。これは、アーキテクチャの選択が、保証できる SLA と自社の顧客に約束できる SLA に直接影響することを示しています。

Microsoft が SLA を満たせなかった場合、顧客はサービス クレジットを請求できます。これは、今後の請求額に適用される割合割引です。違反の重大度が高いほどクレジット額も増えます。通常、稼働率が 99.0% 以上 99.9% 未満の場合は 10%、99.0% 未満の場合は 25%、場合によっては 100% のクレジットが適用されます。サービス クレジットが唯一の救済措置であり、Microsoft が SLA 違反に対して現金で補償することはありません。

Microsoft の SLA はサービスの可用性に関する保証であり、アプリケーション固有の Recovery Time Objective (RTO) や Recovery Point Objective (RPO) に関する保証ではありません。サービスが SLA を満たしていても、独自のビジネス継続性目標を達成するには、マルチリージョン フェールオーバーや定期的なバックアップなど、追加のアーキテクチャ パターンが必要になる場合があります。SLA は下限であり、上限ではありません。

Azure MonitorとAzure Service Healthを使用して、サービスが SLA を満たしているか追跡します。Azure Service Health は、サービスの停止、計画メンテナンス、リソースに影響する可能性がある正常性に関するアドバイザリの通知を提供します。リージョン内の Azure サービスに問題が発生したときにすぐ通知を受け取れるよう、正常性アラートを設定してください。

このレッスンで扱った Microsoft Azure Fundamentals (AZ-900) の概念について、理解度を確認します。

このレッスンでは、SLAは Microsoft が提供する、割合で表された正式な稼働時間の保証であること、直列に接続されたサービスの複合 SLAは個々の SLA をすべて掛け合わせて計算すること、そして並列構成の冗長化によって複合 SLA を大幅に向上できることを学びました。次は、可用性セットと可用性ゾーンについて学び、VM ワークロードで高い SLA を実現する方法を理解します。