先生と生徒の会話形式で理解しよう

生徒

「Azure（アジュール）を使ってシステムを作りたいのですが、サーバーが故障してサービスが止まってしまわないか心配です。何か対策はありますか？」

先生

「それはとても大切な視点ですね。クラウドの世界では『高可用性（こうかようせい）』という考え方があります。これは、トラブルが起きてもサービスを止めずに動かし続ける仕組みのことですよ。」

生徒

「高可用性ですか。難しそうですが、具体的にはどうやって設定するのでしょうか？」

先生

「Azureには『リージョン』や『可用性（かようせい）セット』、『可用性ゾーン』といった、物理的な故障から守るための段階的なメニューが用意されています。今回はその基本を順番に解説しましょう！」

1. 高可用性とは？初心者にもわかる基本概念

高可用性（High Availability、略してHA）とは、一言で言えば「システムが止まりにくい状態」のことです。例えば、あなたがネットショップを運営しているとします。もし深夜にサーバーが1台壊れて、ショップが閉鎖状態になったら大きな損失ですよね。

コンピューターは機械である以上、いつかは必ず壊れます。ハードディスクが動かなくなったり、電源が切れたり、時にはデータセンター自体が停電することもあります。こうした不測の事態が起きても、予備の装置に切り替えて、利用者には何事もなかったかのようにサービスを継続させる設計を高可用性設計と呼びます。Azureはこの高可用性を実現するためのインフラが非常に充実しています。

2. リージョン（Region）の仕組みと重要性

Azureを使い始めるとき、最初に目にするのが「リージョン」という言葉です。リージョンとは、簡単に言うと「データセンターが集まっている地理的なエリア」のことです。

例えば、「東日本リージョン」や「西日本リージョン」があります。これらは単一の建物ではなく、物理的に近い場所にある複数のデータセンターのグループを指します。

なぜリージョンが分かれているかというと、災害対策のためです。もし東日本で大きな地震が起きてデータセンターが被害を受けても、西日本リージョンに予備を置いておけば、サービスを再開できます。これを「リージョンペア」と呼び、通常は数百キロメートル離れた場所にある別のリージョンとペアを組むのが一般的です。

3. 可用性セット（Availability Set）でサーバー故障に備える

次に、もう少し細かい単位の対策を見ていきましょう。それが「可用性セット」です。これは、同じデータセンター内にある複数の仮想サーバー（仮想マシン）が、同時に壊れないように配置する仕組みです。

可用性セットを理解するには、「更新ドメイン（UD）」と「障害ドメイン（FD）」という2つの言葉を知っておく必要があります。

障害ドメイン：電源やネットワークスイッチを共有するグループです。同じ障害ドメインにあるサーバーは、1箇所の電源トラブルで全滅する可能性があります。
更新ドメイン：Azureがメンテナンス（更新作業）を行う単位です。同じ更新ドメインにあるサーバーは、アップデート時に同時に再起動される可能性があります。

可用性セットを使うと、Azureが自動的にサーバーを別々の障害ドメインと更新ドメインにバラバラに配置してくれます。

ここで、仮想マシンの構成を管理するための簡単なJSON設定例を見てみましょう。


{
    "location": "japaneast",
    "properties": {
        "platformFaultDomainCount": 2,
        "platformUpdateDomainCount": 5
    },
    "sku": {
        "name": "Aligned"
    }
}

4. 可用性ゾーン（Availability Zones）でデータセンター障害を回避

「可用性セット」は同じ建物の中での対策でしたが、建物全体が火災や停電になったら防げません。そこで登場するのが「可用性ゾーン（AZ）」です。

1つのリージョンの中には、独立した電源・冷却手段・ネットワークを持つ「ゾーン」が複数（通常は3つ）存在します。可用性ゾーンを利用すると、あなたのサーバーを「ゾーン1」と「ゾーン2」に分けて配置できます。

これにより、仮にゾーン1のデータセンターが完全にダウンしても、ゾーン2のサーバーが生きていれば、サービスは継続可能です。可用性セットよりも強力な保護レベルと言えます。

以下は、Python（パイソン）のSDKを使用して、特定のゾーンに仮想マシンを作成する際のイメージコードです。


# Azure SDK for Python を使用した仮想マシン作成の例
from azure.mgmt.compute import ComputeManagementClient

def create_vm_in_zone(compute_client, group_name, vm_name, zone_number):
    # 仮想マシンの設定。zones パラメータで指定する
    vm_parameters = {
        'location': 'japaneast',
        'zones': [str(zone_number)],  # '1', '2', '3' のいずれかを指定
        'storage_profile': {
            'image_reference': {
                'publisher': 'Canonical',
                'offer': 'UbuntuServer',
                'sku': '18.04-LTS',
                'version': 'latest'
            }
        }
    }
    print(f"{vm_name} を ゾーン {zone_number} に作成します。")

5. SLA（サービスレベル合意書）と稼働率の関係

Azureなどのクラウドサービスには「SLA（エスエルエー）」というものがあります。これは「このサービスはこれくらいの割合で稼働することを保証します」という約束事です。

例えば、1台のサーバーだけだと「99.9%」の稼働率だったものが、可用性セットを使うと「99.95%」、可用性ゾーンを使うと「99.99%」というように、対策を重ねるほど保証される数字が高くなります。

「たった0.01%の差？」と思うかもしれませんが、年間に換算すると、止まってしまう時間が数時間から数分へと劇的に減ることになります。ビジネスの重要度に合わせて、どのレベルの対策を行うか選ぶのがプロの仕事です。

ここで、各構成ごとの期待される稼働率を比較してみましょう。


構成パターン         | 保証される稼働率 (SLA)
---------------------+-----------------------
単体仮想マシン       | 99.9% (Premium SSD使用時)
可用性セット         | 99.95%
可用性ゾーン         | 99.99%
リージョン間冗長     | さらに高い信頼性

6. 実際の構築で役立つ！PowerShellでの確認方法

実際にAzureを操作する際、コマンドラインから設定を確認することがよくあります。ここでは、Azure PowerShell（パワーシェル）を使って、利用可能なリージョンの一覧を取得するコマンドを紹介します。

初心者の方は、まず自分の契約（サブスクリプション）でどこの場所が使えるのかを確認することから始めましょう。


Get-AzLocation | Select-Object Location, DisplayName
japaneast         Japan East
japanwest         Japan West
eastus            East US
southeastasia     Southeast Asia

このように、コマンドひとつで世界中のデータセンターの場所を確認することができます。日本国内であれば「japaneast（東日本）」と「japanwest（西日本）」が基本になります。

7. どの構成を選べばいいの？選択のポイント

「たくさんあって、どれを選べばいいかわからない！」という方のために、選び方の目安をまとめます。

まず、コストを最小限に抑えたい練習用のサーバーなら、対策なし（単体）でも良いでしょう。しかし、会社の業務で使うなら、最低でも「可用性セット」は検討すべきです。

さらに、24時間365日絶対に止めたくないWebサイトや銀行のようなシステムであれば、複数の「可用性ゾーン」にまたがってサーバーを配置し、さらに「ロードバランサー」という装置でアクセスを振り分けるのが鉄板の構成です。

データベースなどの重要なデータを扱う場合、どのような配置になっているかを確認するSQLのようなイメージデータを以下に示します（※これはあくまで管理上のイメージです）。


id | server_name | region    | zone | role
---+-------------+-----------+------+-----------
1  | WEB-VM-01   | japaneast | 1    | Primary
2  | WEB-VM-02   | japaneast | 2    | Secondary
3  | DB-VM-01    | japaneast | 1    | Master
4  | DB-VM-02    | japaneast | 2    | Slave

上記のように、物理的な場所（ゾーン）を分けることで、安全性を高めています。

8. 可用性を高めるための周辺サービス

サーバーを物理的に分けるだけでは不十分です。例えば、ゾーン1のサーバーが止まったときに、自動的にゾーン2へ利用者を誘導する仕組みが必要です。

そこで使われるのが「Azure Load Balancer（ロードバランサー）」や「Azure Traffic Manager（トラフィックマネージャー）」です。これらは、交通整理の警察官のような役割を果たします。

また、万が一データが消えてしまった時のために「Azure Backup（バックアップ）」や、災害時に別のリージョンで復旧させる「Azure Site Recovery（サイトリカバリ）」といったサービスも組み合わせて利用します。これらをパズルのおもちゃのように組み合わせて、最強のシステムを作り上げていくのがAzureの醍醐味です。

まとめ

今回の記事では、Azure（アジュール）における高可用性設計の核心となる「リージョン」「可用性セット」「可用性ゾーン」について詳しく解説してきました。クラウドを活用したシステム運用において、物理的な故障や災害からサービスを守ることは最も重要な課題の一つです。マイクロソフトが提供するAzureのインフラを正しく理解し、適切な冗長化（じょうじょんか）構成を組むことで、予期せぬトラブルが発生してもビジネスを継続できる強固な環境を構築できます。

高可用性を実現する3つの階層

あらためて、Azureで利用できる対策を整理しましょう。まず「リージョン」は、地理的に離れた場所にあるデータセンターの集合体です。広域災害に備えるための強力な手段となります。次に「可用性ゾーン（AZ）」は、一つのリージョン内にある独立した建物（データセンター）ごとにサーバーを分散させる仕組みです。そして「可用性セット」は、同じ建物内にあるラックや電源系統を分けて配置し、部分的なハードウェア故障やメンテナンスによる停止を防ぐための最小単位の対策です。

これらの仕組みを使い分けることで、SLA（サービスレベル合意書）に基づいた高い稼働率を確保できます。単体での運用よりも、可用性セットや可用性ゾーンを組み合わせた方が、数値上の信頼性が格段に向上することを忘れないでください。

実務で使える管理・確認方法

Azureを運用する現場では、作成したリソースが意図した通りに分散されているかを確認する作業が欠かせません。例えば、SQLデータベースなどの重要なリソースがどのゾーンに配置されているかを管理する際、内部的な管理テーブルを参照するようなイメージで現在の状況を把握することが大切です。

以下に、システム構成を管理するためのデータベーステーブルの例を示します。このように情報を整理しておくことで、障害発生時にどのリソースが影響を受けるかを即座に判断できるようになります。


id | resource_name | type       | region      | zone | status
---+---------------+------------+-------------+------+---------
1  | sql-master-01 | SQL DB     | japaneast   | 1    | Running
2  | sql-slave-01  | SQL DB     | japaneast   | 2    | Standby
3  | app-server-01 | VM         | japaneast   | 1    | Running
4  | app-server-02 | VM         | japaneast   | 2    | Running
5  | app-server-03 | VM         | japaneast   | 3    | Running
6  | lb-primary-01 | LoadBal    | japaneast   | Global| Active

また、特定の条件に合致するリソースだけを抽出して確認したい場合には、下記のようなSQLコマンドで状況をチェックする場面を想像してみると、可用性設計の理解がより深まるはずです。


SELECT resource_name, region, zone, status
FROM azure_resources
WHERE type = 'VM' AND region = 'japaneast'
ORDER BY zone ASC;

実行結果のイメージは以下のようになります。


resource_name | region      | zone | status
--------------+-------------+------+---------
app-server-01 | japaneast   | 1    | Running
app-server-02 | japaneast   | 2    | Running
app-server-03 | japaneast   | 3    | Running

このように、物理的な配置場所（ゾーン）が「1、2、3」とバラバラになっていれば、一つの建物が故障しても他のサーバーが動き続けることができるため、非常に安全な設計であると言えます。

これからのステップ

Azureの高可用性設計をマスターした後は、実際に「Azure Load Balancer」などのネットワークサービスを組み合わせて、トラフィックを自動で振り分けるハンズオンに挑戦してみることをおすすめします。理論を学ぶだけでなく、実際に構築してみることで、クラウドエンジニアとしてのスキルは飛躍的に向上します。

もし、より高度な開発や自動化を目指すのであれば、C#（シーシャープ）などのプログラミング言語を使って、Azureのリソースを操作するプログラムを書いてみるのも良いでしょう。

以下に、C#を使用して仮想マシンの状態をコンソールに表示する簡単なプログラムのイメージを紹介します。


using System;

namespace AzureStatusChecker
{
    class Program
    {
        static void Main(string[] args)
        {
            string vmName = "WEB-VM-01";
            string zone = "1";
            bool isHighlyAvailable = true;

            if (isHighlyAvailable)
            {
                Console.WriteLine($"{vmName} は ゾーン {zone} で冗長化されています。");
            }
            else
            {
                Console.WriteLine("警告：このサーバーは冗長化されていません。");
            }
        }
    }
}

実行すると、以下のように結果が表示されます。


WEB-VM-01 は ゾーン 1 で冗長化されています。

このように、プログラムからインフラの状態を確認する手法も、現代のクラウド運用では非常に重要です。この記事が、皆さんのAzure学習の第一歩として役立てば幸いです。

先生と生徒の振り返り会話

生徒

「先生、まとめまで読んで、Azureの守りの固さがよくわかりました！リージョンとかゾーンとか、いろんなレベルで対策ができるんですね。」

先生

「その通りです！単に『サーバーを立てる』だけでなく、『どうやって守るか』を考えるのがプロのエンジニアの仕事なんですよ。」

生徒

「特に『可用性ゾーン』の話が印象的でした。建物ごと分かれているなら、火事や停電が起きても安心ですね。でも、設定が難しそうだと思っていました。」

先生

「実はAzureの管理画面（ポータル）や、さっき紹介したPowerShellなどのツールを使えば、意外と簡単に設定できるんです。まずは小さなシステムから、ゾーンを分けて作る練習をしてみるといいですよ。」

生徒

「はい！C#のプログラムで状態をチェックする方法も面白そうなので、プログラミングも一緒に勉強してみます。あと、SLAの数字も意識して、予算に合わせた最適なプランを考えられるようになりたいです。」

先生

「素晴らしい意気込みですね！SLAの『99.99%』を目指すのはコストもかかりますが、それだけ信頼されるシステムになります。これからも一緒に一歩ずつ学んでいきましょうね！」

生徒

「ありがとうございます！次はロードバランサーを使って、実際に通信を振り分ける仕組みを教えてください！」

Azureの高可用性設計をマスター！リージョン・可用性セット・可用性ゾーンの基礎知識