リージョンと可用性｜クラウドの基本・IAM・責任

このページはプロモーション（広告）を含みます。

クラウドの基本・IAM・責任（中級・読む30分＋演習35分）

この授業のゴール

• リージョンとアベイラビリティゾーンの違いを説明し、遅延・データの置き場所の制約・障害への備えからリージョンを選ぶ理由を書ける
• 可用性（%）を1か月の停止許容時間（分）に換算できる
• 直列構成と冗長（並列）構成の可用性を計算し、どこを冗長化すると効果が大きいか判断できる
• 独立性の仮定が崩れる例（同じゾーンへの集中、複製による削除の伝播）を挙げ、計算の限界を説明できる

仕事でどう使うか

「止まると困るシステムを、どこに、いくつ置くか」を決めるのが可用性の設計です。分析や機械学習の成果物も、毎朝のダッシュボードや予測APIとして使われ始めると、止まったときの影響を説明する必要が出てきます。

この授業の可用性の数値は教材用の仮定です。提供者が公表するSLA（Service Level Agreement：サービス水準の合意）の値・条件・対象は、サービスや時期で異なり変わり得るため、断定せず公式情報で確認してください。計算はすべて端末内の模擬です。

前提

次の言葉と計算を使います。

• 計算・保存・ネットワークの3つの柱、サブネット → 計算・保存・ネットワーク
• 確率の掛け算：2つの出来事が互いに影響しない（独立）とき、両方が起きる確率は、それぞれの確率の積。例：表が出る確率0.5のコインを2回投げて2回とも表になる確率は 0.5×0.5＝0.25。
• パーセントと小数：99.9%＝0.999。

Pythonは、リストと for 文、関数の定義が読めれば十分です。

身近な状況：「同じ建物に2台」は冗長か

みなと商店の予測API（商品のおすすめ）は、仮想サーバー2台で動いています。担当者は「2台あるので1台壊れても大丈夫」と考えていました。

ところがある日、2台が置かれていた同じデータセンターの区画で電源設備の障害が起き、2台とも同時に止まりました。おすすめ欄が3時間表示されず、問い合わせが殺到しました。

もう1つの出来事もありました。顧客データを東京近郊の地域と海外の地域の両方に複製していたところ、法務担当から「この顧客データは契約上、国内に保管すると約束している」と指摘されました。

2つの出来事から分かることは次のとおりです。

1. 台数を増やしても、同じ原因で同時に止まる場所にあれば冗長にならない。
2. 置き場所を分散すればよいとも限らず、データを置いてよい地域の制約がある。
3. 「どれくらい止まってよいか」を数字で決めないと、冗長化にいくら使うべきか判断できない。

この授業では、置き場所の単位（リージョンとゾーン）と、可用性の計算方法を学びます。

直感的な説明：同じ町の別の建物、別の町

• リージョンは「町」です。町の中には、互いに離れた複数の建物（データセンターの集まり）があります。
• アベイラビリティゾーン（ゾーン）は、その町の中の「別々の建物」です。電源・冷房・ネットワークが建物ごとに独立しているので、1つの建物が停電しても、別の建物は動き続けることが期待されます。建物どうしは近いので、通信は速いです。
• 町全体が大災害に遭う可能性に備えるなら、別の町（別リージョン）にも置きます。ただし遠いので通信は遅くなり、費用も増え、データを置いてよい国・地域かの確認も必要です。

可用性の直感は「どれだけの時間、使える状態か」です。

• 部品を一列につなぐ（直列）と、どれか1つ止まれば全体が止まるので、全体の可用性は下がります。
• 同じ部品を並べて代わりを用意する（冗長化、並列）と、全部が同時に止まらない限り動くので、可用性は上がります。ただし「同時に止まらない」が成り立つのは、別々の建物に置くなど原因を共有しない場合だけです。

正確な定義：リージョン・ゾーン・可用性の計算

• リージョン（region）：提供者がデータセンター群を置く地理的な地域。リージョンごとに、提供されるサービス・料金・データの保管場所が異なり得ます。
• アベイラビリティゾーン（availability zone）：1つのリージョン内にある、電源・冷却・ネットワークが独立した施設群。名称や数は提供者ごとに異なります。
• リージョンの選び方の観点：利用者との距離による遅延（通信の往復時間）、契約・法令・社内規程によるデータの保管場所の制約（データレジデンシー）、必要なサービスがそのリージョンで使えるか、費用の違い、障害時の切替先。
• 可用性（availability）$A$：ある期間 $T$ のうち、使える状態だった時間の割合。

$$A = \frac{T - D}{T}$$

ここで $T$ は期間の長さ（分）、$D$ は停止時間（分）です。逆に、可用性 $A$ のとき許される停止時間は $D = (1-A)\,T$ です。30日は $T = 30 \times 24 \times 60 = 43{,}200$ 分なので、$A=0.999$（99.9%）なら $D = 0.001 \times 43{,}200 = 43.2$ 分です。

• 直列構成：部品1〜$n$（可用性 $a_1, \dots, a_n$）がすべて動いていないと全体が止まる。部品の停止が独立なら

$$A_{\text{直列}} = a_1 \times a_2 \times \cdots \times a_n$$

• 並列（冗長）構成：同じ役割の部品 $m$ 個のうち、1つでも動いていれば役割を果たせる。停止が独立なら、全部が同時に止まる確率は $(1-a_1)(1-a_2)\cdots(1-a_m)$ なので

$$A_{\text{並列}} = 1 - (1-a_1)(1-a_2)\cdots(1-a_m)$$

• SLA：提供者が利用者に約束するサービス水準。一般に、下回った場合に料金の一部を返す（クレジット）などの取り決めで、停止しないことの保証ではありません。また、利用者が冗長構成を取っていることを条件にする場合があります。

段階付き例題：APIとDBの構成の可用性を比べる

問題：予測APIは「APIサーバー → DB」の直列構成。各部品の可用性を99.9%と仮定する（教材用の仮定）。(1) 現状、(2) APIサーバーを別ゾーンに2台にした場合の、全体の可用性と30日の停止許容時間を求める。

ステップ1：現状は直列。

$$A = 0.999 \times 0.999 = 0.998001$$

停止許容時間は $(1-0.998001) \times 43{,}200 \approx 86.4$ 分。部品1つなら43.2分だったのが、つなぐだけで約2倍に増えました。

ステップ2：APIサーバーを2台の並列にする。

$$A_{\text{API}} = 1 - (1-0.999)^2 = 1 - 0.000001 = 0.999999$$

ステップ3：全体を直列で合成する。

$$A = 0.999999 \times 0.999 \approx 0.998999$$

停止許容時間は約43.2分。APIを冗長化しても、DBが単独のままなので、全体はDBの可用性でほぼ決まることがわかります。

ステップ4：解釈する。

最後の行は $0.999999 \times 0.999999$ です。ただし、この数字は「停止が独立」「切替が一瞬で成功する」という理想の仮定の上の値です。実際には切替に時間がかかり、設定ミスや共通のソフトウェアの不具合で同時に止まることもあるため、これほど高くはなりません。計算は「どこが弱いか」を見つける道具として使い、結果をそのまま約束しないことが大切です。

操作して理解する：部品を足し、冗長化して変化を見る

次のコードで、直列と並列の可用性を計算します。parts の値を変えたり、台数 m を変えたりして、停止許容時間の変化を予想してから実行してください。

def series(avails):
    # 直列: すべてが動く確率（独立を仮定）
    p = 1.0
    for a in avails:
        p *= a
    return p

def parallel(avails):
    # 並列: 全部が同時に止まる確率を1から引く（独立を仮定）
    q = 1.0
    for a in avails:
        q *= (1 - a)
    return 1 - q

T = 30 * 24 * 60   # 30日（分）
api, db = 0.999, 0.999
for m in [1, 2, 3]:
    A = series([parallel([api] * m), db])
    print(f"API {m}台 + DB 1台: 可用性 {A*100:.4f}%  停止許容 {(1-A)*T:.1f} 分/30日")

A = series([parallel([api] * 2), parallel([db] * 2)])
print(f"API 2台 + DB 2台: 可用性 {A*100:.4f}%  停止許容 {(1-A)*T:.2f} 分/30日")

出力：

API 1台 + DB 1台: 可用性 99.8001%  停止許容 86.4 分/30日
API 2台 + DB 1台: 可用性 99.8999%  停止許容 43.2 分/30日
API 3台 + DB 1台: 可用性 99.9000%  停止許容 43.2 分/30日
API 2台 + DB 2台: 可用性 99.9998%  停止許容 0.09 分/30日

読み取れること：

• APIを2台→3台にしても、ほとんど変わりません。弱い部品（ここではDB）が全体を決めているからです。
• 冗長化の費用は台数に比例して増えます。「停止許容43.2分で業務上問題ないか」を先に決め、必要な部分だけを冗長化します。

発展：独立性が崩れる場面と、複製・バックアップの違い

並列の式は「同時に止まらない（独立）」ことを前提にしています。次の場合、この前提が崩れます。

複製とバックアップは別物です。複製（レプリケーション）はデータを別ゾーンや別リージョンにほぼ同時にコピーするため、故障には強い一方、誤って削除した操作も複製先にすぐ伝わります。誤操作やデータ破損からの復旧には、過去の時点に戻せるバックアップが別に必要です。どの時点まで戻せればよいか（RPO：Recovery Point Objective）、何時間で復旧すべきか（RTO：Recovery Time Objective）の設計は 「バックアップと復元」（有料版）、「RTO・RPOと障害域」（有料版） で扱います。

別リージョンへの複製は、データの保管場所の制約に注意します。個人データの越境移転には法令や契約上の条件があり得るため、社内の法務・情報セキュリティ担当の確認を経て決めます（法令の内容は変わり得るため、最新の公式情報で確認）。

よくある失敗

失敗1：同じゾーンに2台置いて「冗長化済み」とする

誤った見積もり：同じゾーンにAPIサーバー2台を置き、並列の式で 99.9999% と報告した。

a = 0.999
print("独立を仮定した値:", 1 - (1 - a) ** 2)
# ゾーン障害（例：可用性99.95%と仮定）は2台に共通にかかる
zone = 0.9995
print("共通原因を考慮:", zone * (1 - (1 - a) ** 2))

出力は 独立を仮定した値: 0.999999、共通原因を考慮: 0.999499...（約99.95%） です。

なぜ誤りか：2台が同じ電源・ネットワークを共有しているため、ゾーン障害では同時に止まります。共通の原因は直列の部品として掛け算に入れる必要があります。

直し方：冗長化する部品は別ゾーンに置き、構成図に「どのゾーンに何があるか」を明記する。見積もりには共通原因（ゾーン、依存先、認証基盤）を直列の部品として含める。

失敗2：直列の可用性を足し算や最小値で見積もる

誤った計算：「APIが99.9%、DBが99.9%、認証が99.9%なので、全体も99.9%」とした。

parts = [0.999, 0.999, 0.999]
p = 1.0
for a in parts:
    p *= a
print("誤り（最小値）:", min(parts))
print("正しい（積）:", round(p, 6), "停止許容:", round((1 - p) * 43200, 1), "分/30日")

出力：誤り（最小値）: 0.999、正しい（積）: 0.997003 停止許容: 129.5 分/30日。

なぜ誤りか：直列では、どれか1つが止まれば全体が止まります。部品が増えるほど、どれかが止まる機会が増えるので、全体の可用性はどの部品よりも低くなります。

直し方：直列は積で計算する。部品が多いほど下がることを前提に、依存する部品を減らすか、弱い部品を冗長化する。

失敗3：複製があるからバックアップは不要と判断する

誤った判断：DBを別ゾーンに複製しているので、バックアップを取らなかった。ある日、担当者が誤って DELETE FROM orders;（条件なしの全行削除）を実行し、複製先からも同時に全行が消えた。

なぜ誤りか：複製は「今のデータ」を別の場所に保つ仕組みで、削除や破損も忠実にコピーします。故障（機械が壊れる）と誤操作（人が消す）は、別の対策が必要な別のリスクです。

直し方：

まとめ

• リージョンは地理的な地域、ゾーンはその中の独立した施設群。選定では遅延・保管場所の制約・サービス・費用を見る。
• 停止許容時間は (1 − 可用性) × 期間。99.9%は30日で43.2分。
• 直列は積、並列は 1 − (止まる確率の積)。直列では最も弱い部品が全体を決める。
• 並列の式は独立が前提。同じゾーン・同じ依存先・同じ更新は同時停止の原因になる。
• 複製は故障対策、バックアップは誤操作・破損対策。両方が必要。

用語

リージョン（region）

提供者がデータセンター群を置く地理的な地域。

アベイラビリティゾーン（availability zone）

リージョン内の、電源・冷却・ネットワークが独立した施設群。

可用性（availability）

ある期間のうち、サービスが使える状態だった時間の割合。

冗長化（redundancy）

同じ役割の部品を複数用意し、1つが止まっても役割を果たせるようにすること。

SLA（サービス水準の合意）（Service Level Agreement）

提供者と利用者の間で合意するサービス水準と、下回った場合の取り決め。

データレジデンシー（data residency）

データを保管してよい国・地域に関する、契約・法令・規程上の制約。

よくある質問

なぜ可用性を「%」ではなく「分」に直すのですか？

99.9%と99.99%は数字の差が小さく見えますが、30日では43.2分と4.32分で10倍違います。業務への影響（その時間に何件の注文を失うか）を議論するには、時間に直したほうが伝わります。

リージョンとゾーンの違いがまだあいまいです。

リージョンは地理的な地域（町）、ゾーンはその地域内の独立した施設群（町の中の別の建物）です。ゾーンを分けると近距離のまま設備の障害に備えられ、リージョンを分けると地域全体の障害に備えられますが、遅延・費用・保管場所の制約が増えます。

計算した可用性と実際の稼働率がずれるのはなぜですか？

計算は独立・瞬時の切替・部品の可用性が正確、という仮定の上にあります。実際には共通原因の障害、切替の失敗、計画メンテナンス、設定ミス、依存している外部サービスの停止があります。計算は弱い箇所を見つける道具として使い、実績はログ（責任共有とログ）や監視（「SLOとユーザー影響」（有料版））で測ります。

提供者のSLAが99.99%なら、自分のシステムも99.99%になりますか？

なりません。SLAはその1つのサービスについての合意で、自分のシステムはそれと他の部品の直列です。また、SLAは一般に停止時の返金などの取り決めで、停止しない保証ではありません。条件や値は公式情報で確認します。

仕事ではどこまで冗長化すべきか、どう判断しますか？

「止まると1時間あたりいくら・何件の損失か」と「冗長化の追加費用」を比べます。社内向けの月次レポートなら数時間の停止を許容して単純な構成に、注文や決済に関わるAPIなら別ゾーンの冗長化とバックアップを必須に、というように用途で分けます。

確認問題

次に学ぶこと

次は IAMと最小権限 で、「誰がどの資源に何をしてよいか」を決めるIAMと最小権限を、ポリシーの実例と模擬の評価で学びます。

バックアップと復元、RTO・RPOの設計は 「バックアップと復元」（有料版）、「RTO・RPOと障害域」（有料版） で深めます。サービス水準を利用者への影響で定める方法は 「SLOとユーザー影響」（有料版） で扱います。