こんにちは。
今回は、MIcrosoft Azure の障害情報についてです。
Microsoft Azure のサービスでは一般公開(GA)されているサービスは SLA がついています。
ただ、Azure もデータセンターがあり物理的な HW があってその上でサービスが展開されているので、SLA が 100% とはどうしてもなれません。
物理的な HW は必ず故障があるので。。。
ですが、Azure で障害が発生してしまうとその上で展開されているサービスにも影響があるため、サービスの復旧計画は運用側で考える必要がどうしてもでてきてしまいます。
また、システムアーキテクチャーで、SLA を 100% に近づけるということはできますが、どうしてもコストとの相談となってしまい、冗長構成をとらずに別環境に再デプロイをする復旧計画をとる場合も少なくないと思います。
ということで、今回は、Azure の障害をいち早く知るための手段についてまとめてみました。
ちなみに、Microsoft Azure の SLA については、以下のサイトで確認することができます。
Microsoft Azure の障害情報を確認する手段
Microsoft Azure の障害を確認する手段は以下の 3 つがあります。
それぞれ、ドキュメントの Overview のリンクを貼っておきます
Azure Status Page
Microsoft Azure のリージョン別に各サービスの稼働状況を見ることができるサイトです。
特に、Azure ポータルとかにログインせずに見ることができます。
現時点だとこんな感じで、オールグリーンっすな♪
ドキュメントにも書いてありますが、すでに Microsoft Azure を利用している方には、Azure Service Health を見ることが強く推奨されています。
多分、ここを障害とするのは、そのリージョンにおける障害ってなっちゃうから、それなりにハードルが高いんだと思うっす(ぼそっ
Service Health
Service Health は、リージョン単位で発生する障害やメンテナンス情報を確認することができます。
確認できるのは、こんな感じ。
- サービスの問題
- 定期的なメンテナンス
- 正常性に関する勧告
- セキュリティに関する勧告
これらの情報を表示するダッシュボードを作ったり、Health Alerts を作って管理者に通知をあげるなんてことができます。
運用で使っているリージョンやサービスに絞って情報を得ることができるってところと、Azure Status のページみたいに自分から見にいかなくていいのが、いいところかな？
Resource Health
Resource Health は、リソース単位でリソースに問題を起こしているサービスの診断などを行います。
ドキュメントでも、以下のようにありますので、SLA 違反を検出するために設定をしておいた方がいいサービスとなります。
Azure サービスの問題によってリソースが利用できなかったすべての時間を示します。 このデータにより、SLA 違反が発生したかどうかを簡単に確認できます。
で、Resource Health は、Service Health のメニューの中にあります。
(ちょっとわかりづらい)
Alert はこんな感じで設定できます。
SLA を下回った場合
SLA を下回った場合でも、自動的には「返金」はされません。
この辺は、各サービスの SLA に記載されています。
例えば、App Service だとこんな感じ
申し立て
申し立ての項目があり、記載内容の抜粋ですが、こんな感じで書いてあります。
マイクロソフトが申し立てを検討するためには、お客様はその申し立てを、マイクロソフトが当該申し立てを検証するために必要なすべての情報と共に Microsoft Corporation のカスタマー サポートに提出しなければなりません。この情報には、(i) インシデントの詳細な説明、(ii) ダウンタイムの発生日時および継続期間に関する情報、(iii) 影響を受けたユーザー (該当する場合) の数および所在地、ならびに (iv) インシデント発生時にお客様がインシデント解決のために講じた措置の説明、を含みますが、これらに限定されません。
ってことで、SR が必要となります。
ですので、この場合は、「返金の要求」をする必要があります。
ひとまず、これは、Azure ポータルの SR から「返金の要求」ができます。
ただ、CSP 契約のサブスクリプションの場合、CSP プロバイダーとの契約がありますので SLA についての補償は CSP プロバイダー側の契約によってしまう可能性があるので、購入元にご確認いただくのがいいと思います。(そもそも、CSP プロバイダーしか、SR を投げられない契約だし)
サービスクレジット
SAL を下回った時の要求を「返金の要求」ですので、お金が返ってくるって思ってる方も多いのですが、実際は「サービスクレジット」という形で処理されます。
サービスクレジットの項を抜粋すると、以下の記載があります。
サービス クレジットは、本契約および本 SLA に基づく本サービスのパフォーマンス上の問題または可用性の問題に対するお客様の唯一かつ排他的な権利です。お客様は、パフォーマンス上の問題または可用性の問題について、当該月間サービス料金を一方的に相殺することはできません。
サービス クレジットは、サービス レベルが満たされなかった特定の本サービス、サービス リソース、またはサービス層について支払われた料金にのみ適用されます。サービス レベルが個々のサービス リソースまたは別個のサービス層に適用される場合、サービス クレジットは、適宜影響を受けたサービス リソースまたはサービス層について支払われた料金にのみ適用されます。特定の本サービスまたはサービス リソースについて 1 請求月に付与されるサービス クレジットは、いかなる場合も、その請求月における当該本サービスまたはサービス リソースについてのお客様の月額サービス料金を超えることはありません。
つまり、影響をを受けた範囲だけの Azure のサービスリソースで請求した額を、翌月に対象のサービスリソースに適用できるサービスクレジットという形で付与して割引しますよってことですね。
まぁー、普通の運用環境であれば、翌月にそのサービスをまったく使わないってことはないので、割引を受けて相殺されるってことになると思います。
逆に、なにかの検証などで一時的に使っていたサービスの場合、ちょっと微妙になっちゃうんですよね。。。
(過去に、自分も 1 度ありました。。。)
まとめ
今回は、Azure のサービスに対しての障害検知の手段をまとめました。
もちろん、Azure のサービスの上では、ビジネスのサービスが動いていて、アプリケーションが動いてってなるわけですので、そのレイアの監視は、Azure Monitor であったり、Application Insights だったり、Log Analytics で監視をした方がいいですし、セキュリティのアラートであれば、Azure Sentinel といったサービスもありますので、これらを組み合わせ監視が必要となります。
サービスも変わるし、アプリも変わるので、監視の設定も日々見直しが必要となりますが、まずは最初に監視を始めないと問題があったときの初動が遅れますので、是非設定してくださいね。
あと、今回の記事では、SLA 違反のケースについても触れましたので、ただサービスを作るだけだったらあまり考えないことかもしれないですけど、その後運用をしていくってことを念頭にご検討ください。
コメント