Azure の VM は落ちる？受け入れがたい真実を知ることから始まる。Azure の様々なサービスを使い本当に落ちないサービスを目指すノウハウを説明します。

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

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

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

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

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

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

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

12. 12

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

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

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

16. ホストが故障した場合

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

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

19. ユーザーができること

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

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

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

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

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

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

26. Azure Virtual Machine の SLA

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

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

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

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

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

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

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

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

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

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

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

39. Scale Unit 2
可用性セット
管理ディスクを使ってストレージ側の可用性アップ
Scale Unit 1
管理ディスクの環境
大規模障害

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

61. PaaS を利用する

62. IaaS か PaaS か

63. 災害対策のまとめ

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

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