プロに教わるAzure設計運用のベストプラクティス 第1回

仮想マシン単体のSLAから、高可用性、災害復旧（DR）構成やバックアップの要点まで

Azureで実現する高可用性の“勘どころ”と構築のポイント

第2章：高可用性と災害復旧のベストプラクティスを学ぼう

　ここからは、いよいよ本題である「高可用性（HA：High Availability）」と「災害復旧（DR：Disaster Recovery）」について解説していく。まず、Azureにおいてこの2つの言葉の意味はどう違うのだろうか。マイクロソフトの公式ドキュメント上では、それぞれ次のように定義されている。

●高可用性：ITの中断を最小限に抑える一連のテクノロジーを表し、“同じ”データセンター内の冗長性、フォールト トレランス、またはフェールオーバーで保護されたコンポーネントを通じてITサービスのビジネス継続性を提供することで実現されます。ここの例では、データセンターは1つのAzureリージョン内にあります。

●災害復旧：互いに数百マイル離れているような“さまざまな”データセンター間で、ITサービスの中断と復旧を最小にすることも表します。ここの例では、データセンターは同じ地理的リージョン内のさまざまなAzureリージョンや顧客が設定した場所に存在している可能性があります。

※出典：https://docs.microsoft.com/ja-jp/azure/virtual-machines/workloads/sap/sap-high-availability-architecture-scenarios

　わかりづらい表現だが、筆者はそれぞれ次のように解釈している。

・高可用性とは、1つのAzureリージョン内で構成される、ビジネス継続性（冗長性）を高めるシステム構成。

・災害復旧（DR）とは、ビジネス継続に必要なシステムやデータを、遠隔地にある複数のデータセンターに分散保管しておくことで、災害など有事の際にビジネスをすばやく復旧させることを目的としたシステム構成。

高可用性：仮想マシンの冗長化（可用性セット、可用性ゾーン）

　高可用性設計を考えるうえで重要な言葉が「SLA（Service Level Agreement）」だ。一般的な言葉なので詳細な説明は省くが、ここでは「Azureサービスの稼働時間の保証（率）」だと思ってほしい。そして、読者の皆さんがシステムを構築するうえでは、どの程度のSLAを求めるのかによって、とるべき対策が変わってくる。

　まずはシステムの中心的存在となる仮想マシンのSLAについて見てみよう。

Azure VM仮想マシンの可用性設計とSLA（2022年1月現在）

　上の図では、左から右に行くにつれてSLAの数値、すなわち可用性が高まっている。このように、Azureでは仮想マシンに対して4種類のSLAを定義している。左から順に説明する。

①仮想マシン単体：仮想マシン単体でも99.9％のSLAが保証される。現在は、どのタイプの管理ディスクを選択しても仮想マシン単体でのSLAが保証されるようになっている。

②可用性セット：同じデータセンター内でユーザーの仮想マシンを冗長化することで、99.95％のSLAを保証する（詳細は後述する）。可用性セットは、必ず同一のデータセンター内に配置される。

③可用性ゾーン：AZ（Availability Zone）とも呼ばれ、99.99%のSLAを保証する。同一リージョン内にある複数のデータセンターにまたがって仮想マシンを冗長化することで、データセンターレベルでの障害も回避できる。2021年4月現在、日本ではまだ東日本リージョンのみのサービス提供となっている。

④リージョンペア：上述した同一リージョン内のデータセンター群は、比較的近いエリアに配置されているため、広域災害などで同時に障害が発生することも考えられる。そこで、同じ国内や近隣国内にある複数リージョンを“ペア”と考え、災害復旧構成を組むことが推奨されている。日本の場合は東日本リージョンと西日本リージョンがリージョンペアだ。ここではSLAは定義されていない。

可用性セット：障害ドメインと更新ドメイン

　上述した可用性セットについて、もう少し詳しく説明していこう。

　公式ドキュメントの説明を読むと、「可用性セットに追加された仮想マシンは、別の『障害ドメイン』に分散して配置され、少なくとも1つ以上の仮想マシンの稼働を保持する」となっている。この「障害ドメイン」は、「更新ドメイン」と合わせて可用性セットを説明する際に重要な言葉だ。

障害ドメインと更新ドメインの概要

●障害ドメイン（FD：Fault Domain）：上の図は、データセンター内でラック（グレーの四角）内に多数のサーバー（青や紫の箱）が設置されている状態を示しており、この各サーバー上で多数の仮想マシンが立ち上がっている。

　ただし、電源やネットワークスイッチはラック単位で供給されているため、そこに障害が発生すると、同じラック内で稼働するすべてのサーバー、そして仮想マシンの稼働に影響が及ぶことになる。この影響範囲を障害ドメインと呼ぶが、たとえ仮想マシンを冗長化していても、それらが同じ障害ドメインに配置されていれば、電源やスイッチが単一障害源（SPOF）になってしまう。

　そこで前述のとおり、可用性セットを設定すると、複数の仮想マシンを異なる障害ドメインへ自動的に分散配置し、ラック単位の障害が発生した場合でも稼働し続けられるようにしてくれるわけだ。なお、構成できる障害ドメインの個数はリージョンによって制限があり、東日本／西日本リージョンの場合は2つまでとなっている。

●更新ドメイン（UD：Update Domain）：Azureのサービス提供インフラはマイクロソフトが管理しており、サーバーのハードウェア／ソフトウェアは定期的に更新（アップデート）作業が行われる。マイクロソフトでは大量のサーバーを管理しているので、たとえば1000台など、大量のサーバーを一度に再起動させることになる。同時に再起動がかかるこのサーバーのまとまりを、更新ドメインと呼ぶ。

　たとえユーザーが仮想マシンを冗長化していても、それらが同じ更新ドメイン内で稼働していれば、再起動のタイミングですべての仮想マシンがダウンしてしまうことになる。そこで、可用性セットではこの更新ドメインも考慮して、仮想マシンが別の更新ドメインに分散配置されるように自動設定を行う。

　このように、可用性セットでは「障害ドメインと更新ドメインのマトリクス（掛け合わせ）で仮想マシンの配置が決まる」ことを理解するのが重要なポイントだ。別の言い方をすれば、可用性セットを使わず仮想マシンを冗長化しても、障害ドメインや更新ドメインが考慮されないのでそのぶん可用性は低下することになる。

可用性セットとロードバランサー

　可用性セットで仮想マシンを冗長化した際に、一緒に必要となるのがロードバランサーだ。

　その1つであるAzure Load Balancerは、レイヤー4の負荷分散を行うロードバランサーだ。無償で利用できる「Basic」と有償の「Standard」という2種類のサービスがある。Basic Load Balancerの場合、可用性セット内の仮想マシンにトラフィックをルーティングできるが、可用性ゾーンには対応していない。

可用性セットで仮想マシンを冗長構成にした場合、トラフィックを振り分けるロードバランサーも必要となる

Azure Load Balancerには2種類のサービス（SKU）がある

　なお、SSLオフロードやHTTPリクエストの処理といったレイヤー7の負荷分散機能が必要な場合は、Azure Load BalancerではなくAzure Application Gatewayを利用することになる。