Cloud Operator Days Tokyo 2020

1. ミッション:
メガクラウドを安全にアップデートせよ！
「何もしてないのに壊れた」が許されない世界で
真壁 徹
日本マイクロソフト株式会社
2020/07/29
Cloud Operator Days Tokyo 2020

2. 自己紹介
apiVersion: selfIntroduction/v1
name: “真壁 徹(まかべ とおる)”
company:
name: “日本マイクロソフト株式会社”
role: “クラウド ソリューションアーキテクト”
education:
name: “国立大学法人 北陸先端科学技術大学
院大学 先端科学技術研究科 先端科学技術専攻
情報科学系 セキュリティ・ネットワーク領域 博士前期
課程 東京社会人コース (在学中)”
displayName: “JAIST M2 篠田研”

3. お伝えしたいこと
Azureの信頼性を向上する取り組みと仕組み
メガクラウドが止まる時
安全にアップデート/アップグレードするための技術と運用
最新の論文を交え

4. 信頼性向上の取り組みと仕組み
Azure

7. Foundation & Features
Azure Resiliency

8. 60+ 130K+ 160+ 200+
Regions
worldwide
Miles of fiber
and subsea cable
Edge
sites
ExpressRoute
partners

10. 可用性向上の選択肢 （仮想マシンの例）
Single VM
別サーバーで再起動
VM SLA
99.9%
(with Premium Storage)
Availability sets
配置サーバーのラックや共有シャーシ
を分離
Availability zones
配置サーバーのデータセンターを分
離
Region pairs
東日本/西日本など十分な距離のペア
地域災害にも耐えうる
VM SLA
99.95%
VM SLA
99.99%
Regions
60+

12. Project Tardigrade

13. ホストのクラッシュからもVMを保護する
Host platform Host platformHost platform
従来 Tardigrade
VM 1 VM 2 VM 3 VM 1 VM 2 VM 3
Host platform
VM 1 VM 2 VM 3
https://www.youtube.com/watch?v=S2zguwKvlQk (12:00～)

14. With Your Application
Azure Resiliency

15. Daily active users
75M+
daily active
users
200M+
daily meeting
participants
4.1B
daily meeting
minutes
Jul 2019 Nov 2019 Mar 2020 Apr 2020
13M
20M
32M
44M
75M

16. IC3 Office Azure Teams
Microsoft Teams architecture on Azure
SMTPEmail
Clients
Teams graph service Exchange Search Push notifications Notifications Feeds Cache writer
Information
protectionGraph webhook
OneNote
WAC
OneDrive
SharePoint
Experimentation
MRU
Exchange
Calling and
meeting services
Chat and presence
services
Publish and subscribe Stream recording
Core team
services

17. Teamsの回復性を高める取り組み
回復性を高めるアーキテクチャーとアプリケーション設計
グローバル アクティブ/アクティブ負荷分散と冗長化
回復性最適化キャッシュ
(Time To LiveとTime To Refreshのバランス)
クラウドデザインパターンの適用
(サーキットブレイカー、バルクヘッド隔離、APIレート制限、指数
バックオフ再試行など)
意図的な機能縮退
(過負荷時にチャットの”入力しています…”表示は無効にする、など)
Advancing Microsoft Teams on Azure—operating at pandemic scale

18. 高い回復性を持つシステムの設計を助ける情報源
Azure アーキテクチャセンター
https://docs.microsoft.com/ja-jp/azure/architecture/

19. メガクラウドの
主要な停止要因

20. CloudHarmony CloudSquare Service Status [2020/06/24]

21. サービス停止は印象に残りやすいが
メガクラウドのSLA(*)は99.9X%/月の水準
かつ、通常は SLA < 実績値
客観的に評価、判断を
(*)仮想マシンやコンテナーなど
Compute系サービス

22. とはいえサービス停止がないわけではない
では、主な要因は？

23. Why does the cloud stop
computing? Lessons from
hundreds of service outages
Proceedings of the 7th ACM Symposium on Cloud Computing,
SoCC 2016

24. 変化・変更

25. Azureの1日あたりのロールアウトタスク数
ロールアウト = 新機能追加、設定変更、パッチ適用などの変更作業
(2019/6～8)

26. いかに変更管理を行うか？

28. 最新の技術的挑戦
NSDI ‘20での発表論文から
Gandalf: An Intelligent, End-To-End Analytics Service for Safe
Deployment in Large-Scale Cloud Infrastructure
Rex: Preventing Bugs and Misconfiguration in Large Services Using
Correlated Change Analysis
SelfStarter: Finding Network Misconfigurations by Automatic
Template Inference

29. Gandalf
ロールアウト中の問題を検知し、影響を局所化する

30. 段階的ロールアウトだけでは不十分
慎重、段階的にロールアウトしても、本番で見つかる問題がある
インフラストラクチャの多様性
（ハードウェアの供給者、世代、規模、組み合わせなど）
ユーザーワークロードの多様性
（ユーザーのアプリケーションと利用リソース）
時間の経過やタイミング
（メモリ割当/開放やリソース競合など）

31. ロールアウト中に問題を検知し、止める
機械学習を活用した異常(アノマリー)検知
テスト環境での検証
段階的ロールアウト戦略
個々のコンポーネントでの
不具合検知
環境全体でのアノマリー検知
(Gandalf)
個々のコンポーネント
も監視しているが、相
関なしではアラーム量
が膨大になる（APIの一
時的な遅延など）

32. Gandalf

33. Gandalfの相関/判断プロセス

34. Gandalfの効果
Azureでの適用結果
論文公開時18か月運用、分析対象データは8か月分
コントロールプレーンのロールアウトにおいて
高影響インシデント(重大度0-2)につながる不具合を
94.9%の精度で検出し、99.8%に対処できた
(2件の誤アラート、2件の見逃しはあった)

35. Rex
設定ファイルのプルリク時に漏れを指摘する

36. 設定ファイルはひとつとは限らない
サービスの追加や変更において、複数の設定ファイルの編集が必要になりがち
existingservice1-rule
existingservice2-rule
existingservice3-rule
newservice-rule
existingservice1-rule
existingservice2-rule
existingservice3-rule
newservice-rule
existingservice1
existingservice2
existingservice3
acl load-balancing role-assignment
やってもうた…

37. Rex
過去の設定変更を学習し、関連する確率の高いファイルの変更確認を提案する

38. プルリクに対するRexのコメント
このファイルを変更した時は、以
下に挙げたファイルも変更される
ことが多いよ！検討してみて！
学習のためのフィードバック

39. Rexの評価方法
モデルとデプロイの精度を分けて評価する
検出、提案: 100
True Positive: 80 False Positive: 20
関連ファイルを
変更済み: 72
うっかり
変更漏れ！: 8
モデルの精度
= 80/(80 + 20) = 80%
デプロイの精度
= 8/(8 + 20) = 28.5%
多くの場合、プルリク時には変更者が気づき変更している
そこでモデルの精度の他に、デプロイの精度も算出する

40. Rexの効果
AzureとO365などマイクロソフトのオンラインサービスでの適用結果
論文公開時14か月運用、対象レポジトリ数は360
対象全体で4926件の設定漏れを指摘
Azureではモデル精度91.25%、デプロイ精度15.38%
False Positiveが含まれる分、デプロイ精度は低く見えがち
精度面では改善の余地は大きいが、事故防止に大きく貢献

41. SelfStarter
ルーターの誤設定を検証で洗い出す

42. ルーター設定の検証が難しい理由
「規模が大きく複雑」だけが理由ではない
従来から形式手法への期待があるが、厳密な形式モデルにもとづいた
仕様を作り、維持することはルーター設定の現場では難しい
設定ファイルの単純比較が難しい
(例: IPアドレス)

43. SelfStarter
役割別にルーターのメタテンプレートを作り、外れ値を検出する
ルーターには役割がある
(コアルーター、集約ルーター、アクセスルーター、etc)
役割別に設定ファイルを汎化してメタテンプレートを作る
メタテンプレートを元に設定ファイルをグループ化し、外れ値を持つ
グループの設定ミスを疑う

44. SelfStarter (ACL検証の例)

45. SelfStarter (ACL検証の例)
設定ファイルを汎化、生成した
メタテンプレート
間違ったルールを
持っている可能性が
ある
メタテンプレート
でグループ化

46. SelfStarterの効果
マイクロソフトのWAN/データセンターネットワークで評価

47. SelfStarterの効果
既存ネットワークで評価して得られた知見
WANで未知の不要/誤設定が40件検出された
WAN設定はスクリプトと手作業で設定されているが、スクリプトのバ
グと手作業ミスが主な直接的原因
データセンターでは630件検出されたが、問題のない設定
評価対象のデータセンタールーターはソフトウェアによる設定自動化
を徹底しており、段階的設定変更によるタイミング差で外れ値が検出
された

48. まとめ

49. お伝えしたかったこと
Azureの信頼性を向上する取り組みと仕組み
メガクラウドの主要な停止要因は故障ではなく変化
安全にアップデート/アップグレードするための技術的挑戦
様々な挑戦が論文で公開されています、ぜひご参考に

50. © Copyright Microsoft Corporation. All rights reserved.