Skip to content

MS_AzureHighAvailability

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azureの高可用性設計

概要

以下が含まれる。

  • 高可用性
  • バックアップ
  • 災害対策（DR）
  • セキュリティ
  • 移行容易性
  • 保守性

Azureの冗長化

高可用性

Azureの障害復旧

バックアップ、災害対策（DR）

AzureのDDoS対策

セキュリティ

Azure上でのリトライ設計・実装

高可用性

補足（「高可用性」が 2 か所に出てくる意味）: 冒頭の分類で
冗長化とリトライの両方が「高可用性」に割り当てられている点が要点である。
これは、可用性がインフラだけでは達成できないことを示している。

層 手段 守れるもの
インフラ層 冗長化（AS / AZ / リージョン） ノードが落ちても代わりが動く
アプリ層 リトライ／サーキット ブレーカー／冪等性 切り替えの瞬間に発生する一過性の失敗

フェイル オーバーは瞬時ではない（数秒〜数十秒）。
その間、アプリから見れば接続が切れる／タイムアウトする。
ここでアプリが例外を投げて落ちてしまえば、
いくらインフラを冗長化しても
利用者から見た可用性は上がらない。

クラウドでは一過性の障害（transient fault）が
正常な運用の一部として発生するという前提に立ち、
両方を設計する必要がある
（クラウド設計パターン、
Polly、
クラウド アプリケーション アーキテクチャ ガイド）。

XaaS

クラウドサービス提供形態毎

PaaS

トレードオフ

利便性とカスタマイズの自由度にトレードオフがある。

  • ユーザはアプリケーション、データの管理に集中できる。
  • IaaS と比べて制限事項が多い。
    • OS へのリモートアクセス
    • カスタム MSI のインストール
    • スタートアップ タスクの定義と実行 など

移行メモ（体裁）: 原典の「アプリケション」「IaaSと比べる制限事項」は
それぞれ「アプリケーション」「IaaS と比べて制限事項」の誤りであるため修正した。

ランタイムより...

  • 上位はユーザが責任をもって管理
    仮想マシンの OS > ミドル > ランタイム > アプリケーションの
    ランタイムより上をユーザが責任をもって管理する。
  • 下位はクラウドベンダが責任
    仮想マシンの OS > ミドル > ランタイム > アプリケーションの
    ランタイムより下をクラウドベンダが責任をもって管理

補足（責任分界点の一覧）: 本文の「ランタイムより上／下」を
他の形態も含めて並べると、責任分界の移り変わりが見える。

管理対象 オンプレ IaaS PaaS SaaS
アプリケーション 自社 自社 自社 ベンダ
データ 自社 自社 自社 自社（※）
ランタイム 自社 自社 ベンダ ベンダ
ミドルウェア 自社 自社 ベンダ ベンダ
OS 自社 自社 ベンダ ベンダ
仮想化 自社 ベンダ ベンダ ベンダ
物理 自社 ベンダ ベンダ ベンダ

※ データの保護責任は、どの形態でも常に利用者側に残る。
　 これが「SaaS だからバックアップ不要」が成り立たない理由である
　 （SharePoint のバックアップ）。

実務上の要点は、
「ベンダ管理＝考えなくてよい」ではないという点である。
ランタイムのバージョン更新はベンダが行うが、
その更新に自社アプリが追随できるかは自社の責任になる
（PaaS でのランタイム廃止予告への対応など）。

参考

IaaS

仮想マシンの OS より上

仮想マシンの OS より上をユーザが責任をもって管理する。

仮想化レイヤーより下

クラウドベンダが責任をもって管理

  • Azureの仮想マシン
    • Azure の仮想化ホスト基盤は、すべて冗長化されている。
    • 仮想マシンが稼働する仮想化ホストで障害が発生したとき、
      その Azure 仮想マシンは自動的に別の仮想化ホストで再起動する。
  • Azureのストレージ
    • 常に同時 3 つのディスクへデータが書き込まれる。
    • 最大で同時に 2 つのディスクが壊れても、データ損失なく稼働。
    • ジオ冗長で別のデータセンタに複製 = 3 * 2 = 6 重化。
  • Azureのディスク ストレージ
    • データディスク：不揮発
    • 一時ディスク：揮発性（VM の再デプロイで消失）
    • 非管理ディスクと管理ディスク
      • 非管理ディスク：可用性セットを適用しても、同じストレージ・アカウントを使用。
      • 管理ディスク：可用性セットを適用すると、ストレージ・アカウントを分散する。
  • 構成
    ただし、構成（コンフィグ）は必要になる。

移行メモ（体裁）: 原典の「冗長されている」「稼働する化ホスト」
「別の化ホストで再起する」は、それぞれ
「冗長化されている」「稼働する仮想化ホスト」
「別の仮想化ホストで再起動する」の脱字であるため補った。

補足（一時ディスクの罠）: 「一時ディスク：揮発性」は
一行だが、実際の障害でよく問題になる点である。

  • Windows では既定で D: ドライブ、Linux では /mnt が一時ディスク。
  • VM の再デプロイ・ホストのメンテナンス・サイズ変更で
    中身が消える（再起動だけなら通常は残るが、保証されない）。
  • 高速なローカル SSD であるため、
    SQL Server の tempdb やスワップ、キャッシュの置き場として推奨される。
  • 逆に、アプリのデータやログを置いてはいけない。

「D: に置いたファイルが消えた」という障害は
ほぼこれが原因である。

なお、管理ディスクを使うべき理由も本文が的確に示している。
非管理ディスクでは可用性セットに入れても
同一ストレージ アカウントに置かれてしまい、
ストレージ アカウントが単一障害点になる。
管理ディスクはこれを自動的に分散する。
現在は管理ディスクが既定であり、
非管理ディスク（クラシック）は廃止済みである。

サーバ構成

サーバ種類

Webサーバー

ロード・バランサ

ドメイン・コントローラー

分散システムなのでソレ自身が冗長化機能を持っている。

SQL Server

, etc.

クラスタリング

共有ディスク型クラスタ

  • Azure の VM では共有ディスク型クラスタを構成できない。
    記憶域スペースダイレクト (S2D：Storage Spaces Direct) で、
    共有ディスク型クラスタを構成可能だが難易度が高い。
  • レプリケーション型クラスタにシフトしてきている。

レプリケーション型クラスタ

  • SQL Server のAlwaysOn。
  • その他、3rd パーティのソリューション。

補足（クラウドでクラスタの形が変わった理由）: オンプレミスの
Windows Server フェールオーバー クラスター（MSCS/WSFC）は
**共有ストレージ（SAN）**を前提としていた。
クラウドでこれが成立しにくいのは、

  • SAN に相当する共有ブロック ストレージが標準では提供されない、
  • ノードが別の物理ホスト・別のゾーンに散るため、
    低遅延の共有ディスクという前提自体が置けない

ためである。
結果として、データを各ノードが持ち、
レプリケーションで同期する方式（Shared Nothing）に移行した。

方式 データ 代表例
共有ディスク型 1 つを共有 従来の WSFC + SAN
レプリケーション型 各ノードが持つ SQL Server AlwaysOn 可用性グループ

なお、本文が「難易度が高い」とする S2D のほかに、
現在は Azure 共有ディスク（マネージド ディスクの共有機能）が
提供されており、共有ディスク型クラスタも構成可能になっている。
ただし、

  • Premium SSD 以上が必要、
  • SCSI Persistent Reservation に対応したクラスタ ソフトが必要

といった条件があり、
可能な限りレプリケーション型を選ぶという方針は変わらない。

冗長化構成

構成変更（メンテナンス）

非計画メンテナンス

計画メンテナンス

移行メモ（体裁）: 原典の「保持メンテナ」「再起動メンテナス」
「一部 の更新み」は、それぞれ
「保持メンテナンス」「再起動メンテナンス」
「一部の更新のみ」の脱字であるため補った。

メモリ保護更新（VMPHU）

  • Azure では仮想化ゲストの再起動を伴わず仮想化ホストのメンテナンスが可能。
    • 仮想化ゲスト（VM）が 30 秒未満フリーズ
    • その間に仮想化ホストがメンテナンスされる。
    • その後に仮想化ゲスト（VM）の実行が再開される。
  • Hot Patch のみ適用可能。Hot Patch の範囲は拡大されている。
  • 高頻度のメンテナンスが可能であるため、常に最新かつセキュアな状態を維持できる。

移行メモ（体裁）: 原典の「メンテナナンス」「高頻度のメンテナス」は
それぞれ「メンテナンス」の誤りであるため修正した。

補足（「30 秒未満フリーズ」がアプリに与える影響）: VMPHU
（VM Preserving Host Update、現在は メモリ保持更新 と呼ばれる）は
再起動を伴わない点で優れているが、
VM が数秒〜30 秒フリーズするという事実は
アプリ設計に影響する。

影響 対処
TCP 接続がタイムアウトする 接続プールの検証、リトライ（Polly）
クラスタのハートビートが途切れる フェイル オーバーの閾値を 30 秒より長く設定
分散ロックのリース失効 リース期間の見直し
監視のアラート誤検知 短時間の断は無視する閾値設定

「原因不明の瞬断が定期的に起きる」という事象は、
しばしばこのホスト メンテナンスである。
Scheduled Events（VM 内から 169.254.169.254 で取得できる
メタデータ サービス）を監視すれば、
メンテナンスの予告を事前に受け取れるため、
事前にノードを切り離すといった対処ができる。

セルフサービス再デプロイ

スケジュールされたメンテナンス

補足: この 2 つは見出しのみで本文が無い。要点を補っておく。

機能 内容
セルフサービス再デプロイ VM を別の仮想化ホストに移して再起動する操作。ホスト側の問題が疑われる場合（起動しない、性能が出ない）の切り分け・復旧に使う。一時ディスクの内容は失われる
スケジュールされたメンテナンス 再起動を伴う更新が予定された際、利用者側が実施タイミングを選べる期間（セルフ サービス期間）。放置すると Azure 側が任意のタイミングで実施する

後者は、業務時間を避けて自分で再起動するための仕組みである。
通知を無視すると、都合の悪い時刻に再起動される可能性がある。

参考

高信頼性設計のポイント

Tags: 移行, インフラストラクチャ, クラウド, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally