私が使用している Azure SQL Database で SAL 未達の調査と返金要求の申請をする機会がありましたので、その際に実施した内容をまとめておきたいと思います。
Contents
SQL Database の SLA
SQL Database の可用性については Azure SQL Database の高可用性 に記載されており、SLA については、Service Level Agreements (SLA) for Online Services でドキュメントが公開されています。
SQL Database の SLA は次のようになっています。
各稼働率で許容される月間の停止時間は次のようになります。
- 99.995% : 約 2.19 分
- 99.99% : 約 4.38 分
- 99% : 約 438 分
- 95% : 約 2,190 分
SQL Database では、どの環境を使っても最低でも 99.99% or 99.995% の稼働率を目標としており、この稼働率を下回った場合は返金の対象となります。
SQL Database の基盤としての稼働状況の把握
SQL Database の基盤としての稼働状況を把握するには次の二つの方法があります。
サービス正常性は、SQL Database のサービスとして広範囲に問題が発生しているかを確認する方法となります。
サービス正常性でエラーが発生している場合には、自環境以外の他の環境についても障害が発生しおり、使用しているリージョン全体で障害が発生している可能性があります。
リソース正常性は自分が使用している SQL Database について問題が発生しているかを確認する方法となります。
リソース正常性でエラーが発生している場合には、自環境で障害が発生しており、サービス正常性で障害が発生しておらず、リソース正常性で障害が発生している場合は、自環境固有の問題により障害が発生している可能性があります。
どちらの正常性についてもアラートの設定を行うことができ、それぞれで問題が発生した場合にはメール等で自動的に通知を行うことができます。
メールで通知をする設定を行っていた場合には、問題が発生すると次のようなメールが送信され、問題の発生が解消した場合にもメールの送信が行われるようにすることができます。
SQL Database の場合は、内部的なログイン処理によりリソース正常性が確認されており、このログイン処理の時間や成否によってリソースが正常に動作しているかの確認が行われているということでした。
SQL Database はリソースガバナーにより、ユーザーワークロードとシステムワークロードで使用可能なリソースが分離されており、実行されているユーザーワークロードに依存しないような形になっていますので、ユーザーワークロードで負荷が高くなっていても、システムワークロードに対しての影響は抑えられています。
このような環境でシステムワークロードとして実行されている内部処理によるログインが実施できなくなるとリソース正常性としてエラーが発生するという仕組みなのではないでしょうか。
サービス正常性 / リソース正常性のいずれかでエラーが発生した場合、基盤としての稼働状況に問題が発生しているため、SLA の稼働率を達しているかどうかの判断が入るかと思っています。
基盤側で問題が発生しているということはどのような状況か？
サービス正常性
サービス正常性は広範囲に問題が発生しているケースが多く、同一のリージョンを使用している他のユーザーでも問題が発生している場合があり、Azure の状態 や Azure Portal のサービス正常性 で確認することができます。
Azure の状態より、Azure Portal のサービス正常性のほうが障害が公開されるタイミングは早いように思えますが、Azure 全体の障害 / Azure Portal の障害だと、Azure Portal 自体にアクセスすることができないので、そのような場合は Azure の状態から確認することになるかと。
他のユーザーでも問題が発生している場合は、SNS でも同様の事象についての発言が行われていることもありますので広範囲に問題が発生しているかは把握しやすいかと思います。
リソース正常性
リソース正常性は特定の環境のみで問題が発生しているケースがあり、こちらはサービス正常性の方法では確認ができないことがあります。
Azure Portal のリソース正常性 やリソース正常性アラートで確認を行う必要があります。
リソース正常性でエラーが発生した場合、リソース正常性アラートを設定している場合は上述のメールが送信されます。
設定を行っていない場合も、Azure Portal のリソース正常性で確認をすることができ、リソース正常性で問題が発生した場合には次のような情報が出力されます。 
リソース正常性では最大 4 週間分の情報を確認することができ、直近の状況については把握することができるのではないでしょうか。
実際にリソース正常性で問題が発生した状態について
上記のリソース正常性についてはテストで意図的に発生させたものとなるのですが、私の環境で実際にリソース正常性で問題が発生した際には数日間リソース正常性で問題が発生し続けた状態となっていました。
Database Watcher で取得していた情報で、メモリの使用状況が次のようになっていました。
「MEMORYCLERK_SQLTRACE」の使用状況が定期的に上昇しており、ある一定のサイズまで達すると、SQL Database でユーザーワークロードが実行できなくなり、リソース正常性でエラーが発生しているという状態となっていました。
「MEMORYCLERK_SQLTRACE」の内容は sys.dm_os_memory_clerks で確認することができますが、サーバー側のトレースメモリの割り当てが上昇し続けているということが発生していました。
SQL Database の SQL トレースについては拡張イベント / 監査ログ関連で使用されている可能性があると思いますが、これらの設定をすべて無効にしても事象は解決せず、一定の期間稼働しているとリソース正常性でエラーが発生するという状況になっていることが確認できました。
メモリの肥大化が発生し、ある程度のサイズまで肥大化してしまうと、ユーザーワークロードだけでなく、リソース正常性のシステムワークロードからの応答も受け付けなくなり、インスタンスが再起動されメモリがクリアされるまで接続ができないというような状態となっていました。
この状態で、インスタンスサイズ変更によるインスタンスの再起動を行うと制御ができなくなり、長期間 (日単位) リソース正常性のエラーが継続して発生するというような問題が発生してしまいました。(該当日のリソース正常性のエラー発生状況をみると 200 回以上、エラーが発生しているという状態となりました)
SR によるリソース稼働状況の確認と返金の依頼
SR によるリソース稼働状況の確認
サービス正常性 / リソース正常性で問題が発生していることが確認でき、実際のユーザーワークロードでも影響が出ている場合には、サービスリクエスト (SR) で、対象リソースの実際の稼働状況を確認することができます。
- サービス正常性 / リソース正常性でどのような情報が出力されているか
- ユーザーワークロードの影響としてどのような問題が発生しているか
- 上記の例であればメモリの特定領域が上昇を続けておりある一定のサイズまで上昇すると、SQL Database への接続ができなくなるというような情報を連携しました。
- Database Watcher のようなモニタリングを使用していない場合は詳細の連携は省き、どの程度の期間接続ができなかい状態となっていたかを連絡すればよいかと思います。
これにより、ユーザーワークロードで影響が発生していた時間帯は、基盤側の問題だったのか、実行しているユーザーワークロードの問題だったのかを切り分けることができます。
上記の事象であれば、SQL Database の特定の領域でメモリリークが発生しているという基盤側の問題となっており、それによりユーザーワークロードに影響が発生しているということが SR で確認することができました。(この問題は不具合と認識され、不具合に対しての対応をしていただき解決済みであり、現時点では再発はしない状態となっています)
基盤側の問題ということが確認できれば、使用できなかった時間が SLA の稼働目標の範囲になっているかを確認することができ稼働目標の範囲になっておらず、SLA 未達になっている場合は、該当稼働時間に応じて返金の依頼を出すことができます。
今回は SQL Database に対して明らかに接続できない時間があり、「サービスを使用できない時間」が発生したものによる返金となりますが、それ以外でも返金対象となるケースがあります。
- 起動 / 停止を行ことができるサービス
- リソースサイズの変更を行うことができるサービス
については、基盤側の不具合で操作ができなくなっていることがあります。
このような場合は、
- サービスが停止できず、本来、停止によりコストの抑制が期待されていた時間について発生したコスト
- リソースサイズが変更できないことにより、想定していないサイズで稼働せざるをえず、スケールダウン / スケールアウトによる実行が期待されていた時間について発生したコスト
については、返金の対象としてもらえるケースがあります。
なお、必ずしも返金の対象となるわけではないため、このような状況になった場合は SR で状況を確認し、返金対象となるかを確認する必要があります。
返金依頼の方法
返金については、Microsoft Azure インシデント対応 に記載されています。
インシデントの後
Azure Service Health の [正常性の履歴] ウィンドウから (または顧客が構成した Service Health アラート経由で) インシデントの事後レビュー (PIR) を読み、学習した内容を理解します。
パブリックの [状態] ページの条件を満たした重大なインシデントについては、Azure インシデントの振り返りライブストリームに参加して質問の回答を得るか、録画をご覧ください。
SLA クレジットの対象となる可能性があると思われる場合は、問題の種類が「払い戻し要求」の新しいサポート要求を作成し、インシデント追跡 ID を含めます。
SR で基盤側の問題であると認識され、SLA 未達による返金対象となるという可能性を判断してもらえた場合には SR で返金の依頼を行います。
返金の依頼については、課金の SR で「返金の要求」(Credit request) から行うことができます。
この SR で、「SR によるリソース稼働状況の確認」の SR 番号を含めて返金の依頼を行うことで、返金についての調査 / 調整を行ってもらうことができます。
SR 作成時の本文に SR 番号を含めるとクレジットカード番号として認識されてしまう可能性があります。
そのような認識が行われ SR 作成時にエラーが発生してしまった場合は、稼働状況の確認の SR の番号は SR 作成時には記載せず作成し、追加メッセージとして SR 番号を記載することで連携できます。
このような SR を作成し、SLA 未達であると確認ができた場合には、SLA 未達の状況に応じて返金処理が行われます。
使用しているサブスクリプションの種別によって返金処理が行われた場合の通知方法は異なるかと思いますが、私のサブスクリプションでは、返金が完了したことのメール通知が「Microsoft Azure <azure-noreply@microsoft.com>」から届いていました。
どのような返金が行われるか (追加クレジットとしてチャージ / 実際に返金が行われる / 請求が取り消される等) は、状況やサブスクリプションの種別によって異なるかと思います。
問い合わせ内容によっては、技術問い合わせの SR の中で返金までつなげてもらえるケースもありますが、返金処理についての 新規 SR 発行を依頼された場合には、このような対応が必要となります。
EA 契約のサブスクリプションの場合は エンタープライズ契約（EA）のサービスクレジット申請のお手続きについて に記載されている方法となるため、返金要求の提出方法が異なりますが、事前の調査までは同様となるかと。
まとめ
基本的な流れとしては次のようになるのではないでしょうか。
- サービス正常性 / リソース正常性から、該当リソースの起動状況を確認
- 問題が発生している場合には SR で該当リソースの稼働状況を確認
- 基盤側の問題が発生していた場合、「2.」の SR 番号を連携する形で返金の SR を作成
SLA の未達による返金処理は、原則として「ユーザーからの申請」により実施されるものとなり、自動的に実施されるものではありません。
使用しているリソースの稼働状況を把握し、問題が発生している可能性がある場合は問い合わせを行うことが重要なのではないでしょうか。