DevOps と並び、技術者の注目を集める SRE。このセッションでは Azure の「中」の SRE と、Azure 上でシステムを動かすユーザーの SRE、2 つの視点で解説します。システムの信頼性は気合でも手作業でもなく、エンジニアリングで高める時代です。障害に耐える組織と仕組みづくりとは? エモい話から黒い画面のデモまで、Azure における SRE の「いま」をお伝えします。 製品/テクノロジ: DevOps/Linux/Microsoft Azure/OSS/Windows Server/アーキテクチャ/クラウド/運用/事業継続 真壁 徹 日本マイクロソフト株式会社 クラウド & ソリューション ビジネス統括本部 クラウド ソリューション アーキテクト

2. {
“名前” : “真壁 徹(まかべ とおる)”,
“所属” : “日本マイクロソフト株式会社”,
“役割” : “クラウド ソリューションアーキテクト”,
“経歴” : “大和総研  HP Enterprise”,
“特技” : “クラウド & オープンソース”
}

11. Azure Regionオンプレミス(ユーザー占有型)
User User
User User
Storage
Cluster
Storage
Cluster
Server
Cluster
Server
Cluster
共用部分が大きい

12. Azure Regionオンプレミス(ユーザー占有型)
User User
User User
Storage
Cluster
Storage
Cluster
Server
Cluster
Server
Cluster
影響範囲
ストレージクラスターが故障した場合
影響範囲が大きい

13. Azure Regionオンプレミス(ユーザー占有型)
User User
User User
Storage
Cluster
Storage
Cluster
Server
Cluster
Server
Cluster
データセンター全体で共有している設備の障害影響は、
オンプレもAzureも同様

14. どれも冗長化、自己回復機能を有するが、不具合や作業ミスの可能性はゼロではない
ユーザーがそれに対処するにはマルチリージョン構成が有効

15. Azure
Storage
Cluster
Storage
Cluster
Server
Cluster
Server
Cluster

17. Traditional on-premises Modern cloud
Monolithic, centralized
Design for predictable scalability
Relational database
Strong consistency
Serial and synchronized processing
Design to avoid failures (MTBF)
Occasional big updates
Manual management
Snowflake servers
Decomposed, de-centralized
Design for elastic scale
Polyglot persistence (mix of storage technologies)
Eventual consistency
Parallel and asynchronous processing
Design for failure (MTTR)
Frequent small updates
Automated self-management
Immutable infrastructure
Azure Application Architecture Guide
https://docs.microsoft.com/ja-jp/azure/architecture/guide/

19. • 2008 Azure 発表
• 2008 – 2014 様々なDevOpsアプローチ
• 2014 SREチームのパイロット運用開始
• 2015 SREチームを正式に組織化

20. https://azure.microsoft.com/ja-jp/support/legal/sla/

21. インフラチーム
SRE
(Proactive)
Operation
(Reactive)
仕組みづくりに
集中

22. 認知までの時間を
最小化
エスカレーション、
アサインの自動化
高速なロールバック、
フェイルオーバー、
再構築、増強
SREが仕組みを作る

23. 相互理解

30. 可用性
Error Budget
(年間)
Error Budget
(月間)
99% 3.65 日 7.2 時間
99.9% 8.76 時間 43.2 分
99.95% 4.38 時間 21.6 分
99.99% 52.56 分 4.32 分
99.999% 5.26 分 25.9 秒

31. 可用性
Error Budget
(年間)
Error Budget
(月間)
例
< 99% 3.65 日 7.2 時間
バックアップ & 迅速・確実なリカ
バリ (Infrastructure as Code)
99.9% 8.76 時間 43.2 分
シングルリージョンHA
99.95% 4.38 時間 21.6 分
99.99% 52.56 分 4.32 分 マルチリージョン (Act/Stb)
99.999% 5.26 分 25.9 秒 マルチリージョン (Act/Act)

33. 認知までの時間を
最小化
エスカレーション、
アサインの自動化
高速なロールバック、
フェイルオーバー、
再構築、増強
SREは全体設計、検証、
訓練と最適化を行う

35. 0.9994
(99.94%/月)
-> Error Budget 25.92分/月
https://docs.microsoft.com/ja-jp/azure/architecture/resiliency/
2592000秒)とすると

37. 発生年 発生日 リージョン 復旧までの
時間
概要と原因
2015 (特になし)
2016 9/15 複数 約2時間 • ネットワークの輻輳と名前解決機能不全
• ネットワーク制御ソフトの不具合
2017 3/8 東日本 約2時間 • ストレージクラスター停止
• ストレージクラスター制御ソフトの不具合
3/28 西日本 約3時間 • サービス間通信不全
• 増設時のネットワーク設定プロセスでのミス
3/31 東日本 約9時間 • データセンター収容設備の強制シャットダウン
• 冗長化UPSの障害復旧プロセスでのミス

39. 12.88ミリ秒18.92ミリ秒
9.00ミリ秒

40. App Service
Cosmos
DB
SQL
Database
Redis
Cache
Storage
(Contents)
Storage
(Log, Config, etc)
CDN
App Service
Cosmos
DB
SQL
Database
Redis
Cache
Storage
(Contents)
Storage
(Log, Config, etc)
Traffic
Manager
Active Region Standby Region
https://docs.microsoft.com/ja-jp/azure/architecture/reference-architectures/managed-web-app/multi-region-web-app

41. Traffic Manager
マニュアル切り替え可能
(優先度変更)
SQL Database
マニュアル切り替え可能
(Failover Group内でスイッチ)
Storage
マニュアル切り替え不可
Cosmos DB
マニュアル切り替え可能
(Write Region変更)
Azure Storageで同期するのは、対抗リージョンでの即時回復、書き込みが不要な
静的データ(ログや構成ファイル、バックアップデータなど)に限定する。
即時読み取りが必要な場合は、RA-GRSでセカンダリを読めるようにしておく。

42. App Service
Cosmos
DB
SQL
Database
Redis
Cache
Storage
(Contents)
Storage
(Log, Config, etc)
App Service
Cosmos
DB
SQL
Database
Redis
Cache
Storage
(Contents)
Storage
(Log, Config, etc)
Traffic
Manager
Active Region Standby Region
CDN

43. (青色)ユーザーが明示的に分離できる要素
Managed Disk

44. https://docs.microsoft.com/ja-jp/azure/architecture/resiliency/
0.99989
(99.989%/月)
-> Error Budget
4.75分/月

46. https://docs.microsoft.com/ja-jp/azure/traffic-manager/traffic-manager-monitoring
https://docs.microsoft.com/ja-jp/azure/sql-database/sql-database-business-continuity
Traffic Manager
判定時間(最長のケースで130秒) + DNS TTL(設定下限30秒)
(補足)30秒毎にエンドポイントを監視し、10秒以内に応答がない状態が4回続くと、エンドポイント障害と判断する
SQL Database
判定時間(*) + 時間(30秒以内)
Traffic Managerを使う場合、160秒は見込むべき。 (99.994%/月)
判定/切換時間のさらなる短縮には、他で検知->マニュアル切換、Act/Act化を検討。
+ ユーザー環境要因
(*)Automatic Failoverは
Preview中にて値の公開待ち

47. Demo
Multi Region Active/Standby Architecture

48. App Service App Service
Traffic
Manager
Active Region
(Japan East)
Standby Region
(US West 2)
Failover Group
SQL Database SQL Database
ARM
Template

49. https://github.com/ToruMakabe/decode2017

52. 別の機会で
もっと詳しく！
レベル500でもOK！
合わせて読みたい
“DI13ダウンタイムを最小に!
〜 Azure における障害/災害に耐えうるアーキテクチャ設計のポイント 〜”

54. © 2017 Microsoft Corporation. All rights reserved.
本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

55. セッションアンケートにご協力ください
 専用アプリからご回答いただけます。
decode 2017
 スケジュールビルダーで受講セッションを
登録後、アンケート画面からご回答ください。
 アンケートの回答時間はたったの 15 秒です!

56. Ask the Speaker のご案内
本セッションの詳細は『Ask the Speaker Room』各コーナーカウンタにて
ご説明させていただきます。是非、お立ち寄りください。