Azure サポートチームの現場からお届けする落ちないサービスのために

「バグが生まれないように頑張ります」
「壊れないハードウェアを作ります」
「ミスをしないように頑張ります」

ソフトウェアにはバグある
厳密な変更管理、安全な展開、監視、検知と影響軽減
ハードウェアは壊れる
問題を防ぐソフトウェアの設計
人はミスをする
自動化への継続的な投資
Cloud
サービスの
現実

「バグがある前提でシステムを構成する」
「壊れる前提でシステムを構成する」
「ミスが発生する前提でシステムを構成する」

では今の Azure でのソリューションは何か

◇高可用性 (High Availability)
ハードウェアやソフトウェアでトラブルが発生しても
業務を継続できるようにする
◇バックアップ
データが消失または破損したとき、それを復旧できるようにする
◇災害対策 (Disaster Recovery)
大規模災害でデーターセンターが稼働できなくなったとき
早期に業務を再開できるようにする
高可用性・バックアップ・災害対策の違い

これらを理解しないことで生じる悲劇
リストアしても丸1日かかりますが・・・
壊れるとは聞いていなかった(怒) 誰が直すんだ！？
夜間の障害で災対フェールオーバーすべきか判断できず・・・

仮想マシンはそれ自体が高可用性
ある程度は

Azure 仮想マシンの仕組み
仮想マシン用ホストとストレージを分離

物理マシンは使い捨て – ホスト障害の例

ストレージは標準で三重化

ホストが故障した場合

Azure IaaS 基盤が約束できること
サービスヒーリング
と呼んでいます

突然のVMダウンで困ること

ユーザーができること

お客様「Azure の基盤の不具合に対応するためだけにコストがかかるの
は嫌だ」
システムが止まる理由は
基盤側だけでは無いんです！！

IaaS の責任分布
Azure 仮想マシンにおける可用性の考え方
https://blogs.msdn.microsoft.com/ainaba-
csa/2017/05/31/availability-of-azure-virtual-machines/

IaaS の責任分布
どの部分が落ちてもシステムは
止まる！
Azure 仮想マシンにおける可用性の考え方
https://blogs.msdn.microsoft.com/ainaba-
csa/2017/05/31/availability-of-azure-virtual-machines/

放っておいても動き続けるというのは神話

仮想マシンやサービスが止まる理由
※ “想定外” ではない！

余談ですが、ここで再起動に慣れてしまっては？
https://www.slideshare.net/ToruMakabe/ss-74056379

よくある誤解
A. それって SLA 100% ですよねえ
事実: VM はいつ落ちるかわからない

Azure の可用性セット + 管理ディスクを使う

可用性セット・可用性ゾーン＋管理ディスク
構成自体は比較的簡単
リージョンの大規模障害に弱い
アプリケーションが対応していなければならない
構成は可用性セットと似たレベルで簡単
リージョンの大規模障害にも強い
自然災害 (地震)など、リージョン全体が脅かされる場合はダウンに繋がる

複数の VM で高可用構成を
高可用性のロール
可用性セットを構成したデザインパターン

可用性セットの注意点
https://blogs.msdn.microsoft.com/ainaba-csa/2017/05/31/availability-of-azure-
virtual-machines/

いざという時に頼りになる「管理ディスク」とは

Azure 仮想マシンの仕組み
仮想マシン用ホストとストレージを分離
ストレージの障害はスケールユニット単位で起きる

Scale Unit 2
可用性セット
管理ディスクを使ってストレージ側の可用性アップ
Scale Unit 1
管理ディスク無しの環境

Scale Unit 2
可用性セット
Scale Unit 1
管理ディスク無しの環境
大規模障害

Scale Unit 2
可用性セット
Scale Unit 1
管理ディスクの環境

Scale Unit 2
可用性セット
Scale Unit 1
管理ディスクの環境
大規模障害

Scale Unit 2
可用性セット
可用性ゾーンで建屋が別れる (近い将来に実装予定)
Scale Unit 1
ゾーン1 ゾーン2

高可用性 <マイクロソフトとユーザー>

よくある誤解
「データプライバシー、お客様のデータはお客様が管理する」
無断で Azure 側からお客様のバックアップを複製するということはない。
お客様が複製していないデータは複製されていないし、消したデータはすぐに消されることを保証する。
消えた・壊れたデータは戻らない。

泣き寝入りをしないためにバックアップを

Azure Backup
設定が簡単
VM が稼働状態のままバックアップ可能
「過去の正常な時点」に戻す事ができる唯一の方法
バックアップ・リストアともに時間がかかる
RA-GRS に非対応であるため、Azure Backup の保存先に障害が起き
たときに即時のリストアができない

アプリケーション別のバックアップも捨てたものではない
アプリケーションのバックアップは任意のタイミングで行える。
任意の場所に保存できる。(別リージョンも選択肢)

Azure Backup + アプリケーションのバックアップ

バックアップ <マイクロソフトとユーザー>

大規模障害は何故おきるか

大規模障害を想定した構成

Azure Site Recovery (Azure to Azure)
設定が簡単、フェールオーバーも高速
直近複数世代の確保が行える

ストレージ GRS/RA-GRS
設定が簡単、メンテナンス不要
VM のディスク、つまり VHD には向いていない
フェールオーバーのタイミングは自分で決められない

GRS で注意すべきこと
① VM の VHD (ディスク) の複製には不向き。
GRS はストレージ上のデータのバックアップに過ぎず、秒間何回も変更されている VHD のどこからどこまでが複製されて
いるのか全く分からない。書き込み途中で障害がおきた時点のデータは破損している可能性が・・・
VM の複製には必ず Site Recovery を使う。
② GRS のフェールオーバーはお客様のタイミングでは決められない。
障害の状況によっては何日も判断されない場合も・・・
ストレージサービスの地理冗長 (GRS) の障害時の挙動について
https://blogs.technet.microsoft.com/jpaztech/2016/08/09/storage-service-grs-failover/
→ 過信は禁物、保険的な考えとしておくことがベター

自前でリージョン冗長を構成
RTO/RPO の定義についてお客様がコントロール可能
お客様のタイミングでフェールオーバーが可能
場合によるがハイコスト
アプリケーション自体が複製やフェールオーバーに対応している必要がある

災対のフローを確立しておく！

まとめ: スケール別のソリューション
シングル VM
クラスタ構成
マルチリージョン構成
マルチ AZ 構成
Azure VM の Service Healing
ストレージ
+ Azure Backup
可用性セット
各種 PaaS 化
ペアリージョン
Traffic Manager
Site Recovery
ストレージ GRS
可用性ゾーン
Geo
Region
Primary
Region
Secondary
Region

冗長化構成可用性セット
Azure Backup
Azure
Site Recovery
まとめ: Azure を安心・安全に使うために

Azure サポート チームの現場からお届けする落ちないサービスのために

More Related Content

What's hot

Similar to Azure サポート チームの現場からお届けする落ちないサービスのために