• 戻る（Azure、Microsoft Azure Active Directory）
  • Azureの評価環境を入手する
  • AzureのPoC環境を契約する
  • AzureのPoC環境を構築する
  • Azure上に素早く環境を構築する
  • AzADのテナント作成方法
  • Azure Subscriptionの管理@エンプラ
    ＞ Azure Subscriptionの管理手順@エンプラ
    • Azureによる基盤開発法
    • Azureの高可用性設計
      ・Azureの冗長化
      ・Azureの障害復旧
      ・AzureのDDoS対策
      ・Azure上でのリトライ設計・実装
    • Azureの監視と管理
    • Azureのアクセス制御と権限

以下が含まれる。

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

高可用性

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

セキュリティ

高可用性

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

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

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

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

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

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

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

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

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

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

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

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

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

• Microsoft Docs
  • Azure コンピューティング サービスの選択 - Azure Architecture Center
    https://docs.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/compute-decision-tree
    • App Service
    • Azure Kubernetes Service (AKS)
    • Azure Batch
    • Container Instances
    • Functions
    • Service Fabric
    • 仮想マシン（仮想マシン スケール セット）
  • Azure SQL Database の機能の比較
    https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-features

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

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

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

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

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

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

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

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

ロード・バランサ

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

• AlwaysOn
• 可用性グループ

• 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 に対応したクラスタ ソフトが必要

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

• 原則としてホストの更新は "保持メンテナンス（Preserving Maintenance）" で随時実施される。
• 一部の更新のみ "再起動メンテナンス（Restarting Maintenance）" で実施される。
• 参考
  • Azure での Windows VM のメンテナンスと更新 | Microsoft Docs
    https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/maintenance-and-updates
  • 再起動を伴う仮想マシン メンテナンスへの新しいエクスペリエンス – Japan Azure Technical Support Engineers' Blog
    https://blogs.technet.microsoft.com/jpaztech/2017/12/20/new_maintenance_experience/

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

• 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