🖥️

Azure Virtual MachineのSLAを享受するための構成とは

2021/09/07に公開

はじめに

Azure Virtual Machine（Azure VM）の構成要素として、可用性セットがどうとか、可用性ゾーンがどうとかいうアーキテクト目線の情報はよく目にします。
一方で、SLAがどうか、それを満たすためにどういう構成にするのか？という観点の情報、つまりサービスマネージャー目線でAzure VMが語られているシーンをあまり見ない気がしています。
今回はそこを橋渡しする記事を書きたいと思います。

SLA

Virtual MachineのSLAは下記のページで説明されています。

引用すると下記の通りです。

説明
すべての仮想マシンに、同じ Azure リージョン内の 2 つ以上の可用性ゾーンにまたがりデプロイした 2 つ以上のインスタンスがある場合、マイクロソフトは、99.99% 以上の時間において少なくとも 1 つのインスタンスに対する仮想マシン接続が確保されることを保証します。
すべての仮想マシンに、同じ可用性セットまたは同じ専用ホストグループにデプロイした 2 つ以上のインスタンスがある場合、マイクロソフトは、99.95% 以上の時間において少なくとも 1 つのインスタンスに対する仮想マシン接続が確保されることを保証します。
すべてのオペレーティングシステムディスクおよびデータディスクについて Premium SSD または Ultra ディスクを使用する単一インスタンス仮想マシンについては、マイクロソフトは 99.9% 以上の時間において仮想マシン接続が確保されることを保証します。
オペレーティングシステムディスクおよびデータディスクについて Standard SSD Managed Disks を使用する単一インスタンス仮想マシンについては、マイクロソフトは 99.5% 以上の時間において仮想マシン接続が確保されることを保証します。
オペレーティングシステムディスクおよびデータディスクについて Standard HDD Managed Disks を使用する単一インスタンス仮想マシンについては、マイクロソフトは 95% 以上の時間において仮想マシン接続が確保されることを保証します。

SLA未達成（約束通り稼働できなかったとき）は、劣後した度合いに応じてサービスクレジットを払い出しますよ、という整理になっているのですが、今回はお金については論点外です。
SLAで示された稼働率を享受するために、どういう構成にすればよいのか？という目線で考えていきます。

アーキテクチャ

まず、SLAの内容を考えていくうえで、最低限知っておくべき２種類の観点（構成・配置）を考えます。

仮想マシンの構成について

AzureVMのインスタンス単体で見た場合、稼働率に影響する要素は「ディスクの種別」です。
マネージドディスクにはUltraディスク、Premium SSD、Standard SSD、Standard HDDの4通り存在しますが、このディスクの種類によってSLAで謳われる稼働率が変わってきます。

Disk種別	稼働率
Ultra	99.9%
Premium SSD	99.9%
Standard SSD	99.5%
Standard HDD	95%

ディスクの種別は、性能（I/O性能）で語られることが多いのですが、「I/O性能は低くてもいい」「けど可用性が低いのは困る」と言った場合に、Stanadr HDDを選んでしまうと違った面で制約を受ける可能性があるので、気を付けましょう。

なお、稼働率は、年に直すと以下のオーダーになります。0.1％分の停止許容時間でも、結構長いと感じるのではないでしょうか？特にStandard HDDだと、1月（30日）の間に1.5日停止してても文句は言えない、ということです。

停止許容時間(/月)	稼働率
43分	99.9%
3時間36分	99.5%
36時間	95%

なお、Azure VMが複数種類のディスクを使用している場合は、一番低いskuのディスクのサービスレベルでSLAが計算されますので、ご注意ください。
※バックアップ用に1つだけStandar HDDを混ぜる…というような使い方をすると…！？

仮想マシンの配置について

可用性セット

可用性セットを正しく構成することで、99.95%の稼働率が保証されます。
可用性セットは「障害ドメイン」と「更新ドメイン」を組み合わせた概念で、以下のような設定画面で作成します。

○○ドメイン、何て呼ぶと分かりづらいのですが、概念は以下の通りです。

障害ドメイン

共通のコンポーネントで同時に障害を受ける単位、という概念です。
公式ドキュメントによれば「同じ電源やネットワークスイッチに接続されている範囲」とのことですので、データセンターの物理環境をイメージすると「ラック」の単位のような概念と言えます。
可用性セットの中で、この障害ドメインいくつに跨って仮想マシンをデプロイするかを指定します。上のスクリーンショットの例で言えば、「2」が指定されているので、電源やネットワークが別れた2か所にVMが分散されて配置されるようになります。

更新ドメイン

共通の物理ハードウェアで、（その上で動くVMが）同時に影響を受ける単位、という概念です。
AzureではHyper-Vの技術でVMを動かしていると言われていますので、このHyper-Vを動かしているホストの単位とイコールと言って良いでしょう。ホスト側のサーバーOSのメンテナンス（パッチあてなど）や障害による再起動などにより、その上で動くVMが同時に影響を受ける…ということです。

この障害ドメインと更新ドメインをセットで定義したものが「可用性セット」で、まとめると下記の図のように示されます。

（公式ドキュメントより引用）

可用性セットを作成したら、Azure VMを作成する際に下記のように指定しますが、指定したから「SLA99.95%」となるわけではありません。少なくとも2台以上のVMを作成し、同じ可用性セットを指定することで初めて分散されて配置されますので、コレも注意が必要です。

以上から分かることとして、1台のVMで何か処理をするようなアプリケーションだと、可用性セットのメリットは受けられない、ということです。

すなわち、この仕組みでメリットがあるのは、「小さいサイズのVMを複数台にして分散処理をさせるような方式」であり、「1台の大きいVMでバッチ処理を長時間動かす」…みたいなパターンには向かないということです。

可用性ゾーン

可用性ゾーンを正しく利用することで99.99%の稼働率が保証されます。
可用性ゾーンは概ね「データセンター」の同じ単位の概念で、データセンターレベルの障害に対応するために使用します。
2021年現在、東日本リージョンには3つの可用性ゾーンが存在すると説明されておりますので、おそらく千葉、埼玉、東京、神奈川…のどこかに、DCが分散されて建設されているものと思われます。また、西日本リージョンには可用性ゾーンはありません。
まとめると概念としては↓のようになります。

Azure VMの作成時、下記のように可用性ゾーンを指定することができます。

例えば3台のVMを可用性ゾーン1～3で分散して配置することで、1つのデータセンターでの障害から2台のVMは逃れることができるようになります。

ちなみに、可用性ゾーンの識別番号はサブスクリプションによってバラバラに付けられているそうですので、私に取ってのゾーン1と、これを読んでる方にとってのゾーン1は別の場所である可能性があります。
（参考）

以上の通り、可用性セットと同じく1台のVMでは可用性ゾーンのメリットは受けられません。こちらも、複数台のVMを使わない限り（例えばLoad BalancerやApplication Gateway背後のWebサーバー…といった使い方をしない限り）特にメリットは無い、ということになります。

構成選定について

SLAでうたわれている可用性の条件を享受するためには、正しく設計されたVirtual Machineを利用する必要があります。改めて要点を抜き出すと下記の通りです。

構成ポイント	稼働率
可用性ゾーンを使う（複数VM）	99.99%
可用性セットを使う（複数VM）	99.95%
Ultra・Premium SSDを使う（VM単体）	99.9%
Standard SSDを使う（VM単体）	99.5%
Standard HDDを使う（VM単体）	95%

上位を目指すと（お値段的に）高い構成になって来ますので、「どれくらいの稼働率を目指すか」という観点で折り合いを付ける必要があります。
稼働率の目標をどこに持ってくるかというのは、稼働率がN％下がった場合の（金額換算した）デメリットと、N%向上させるのに必要なコストのバランスを見ることになるかと思います。
具体的に利用されるシステムにおいて、上記を参考にぜひ比較してみてください。

おわりに

情報の中身としては世の中にあふれかえってると思いますが、SLAを主軸に再構成してみました。目新しいことは書いてないですが、たどり着いた方の役に立てば幸いです。