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

}

Azure Regionオンプレミス(ユーザー占有型)

User User

User User

StorageCluster

StorageCluster

ServerCluster

ServerCluster

共用部分が大きい

Azure Regionオンプレミス(ユーザー占有型)

User User

User User

StorageCluster

StorageCluster

ServerCluster

ServerCluster

影響範囲ストレージクラスターが故障した場合

影響範囲が大きい

Azure Regionオンプレミス(ユーザー占有型)

User User

User User

StorageCluster

StorageCluster

ServerCluster

ServerCluster

データセンター全体で共有している設備の障害影響は、オンプレもAzureも同様

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

Azure

StorageCluster

StorageCluster

ServerCluster

ServerCluster

Traditional on-premises Modern cloud

Monolithic, centralizedDesign for predictable scalabilityRelational databaseStrong consistencySerial and synchronized processingDesign to avoid failures (MTBF)Occasional big updatesManual managementSnowflake servers

Decomposed, de-centralizedDesign for elastic scalePolyglot persistence (mix of storage technologies)Eventual consistencyParallel and asynchronous processingDesign for failure (MTTR)Frequent small updatesAutomated self-managementImmutable infrastructure

Azure Application Architecture Guidehttps://docs.microsoft.com/ja-jp/azure/architecture/guide/

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

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

インフラチーム

SRE(Proactive)

Operation(Reactive)

仕組みづくりに集中

認知までの時間を最小化

エスカレーション、アサインの自動化

高速なロールバック、フェイルオーバー、再構築、増強

SREが仕組みを作る

相互理解

可用性 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 秒

可用性 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)

認知までの時間を最小化

エスカレーション、アサインの自動化

高速なロールバック、フェイルオーバー、再構築、増強

SREは全体設計、検証、訓練と最適化を行う

0.9994(99.94%/月)

-> Error Budget 25.92分/月

https://docs.microsoft.com/ja-jp/azure/architecture/resiliency/

2592000秒)とすると

発生年 発生日 リージョン 復旧までの時間

概要と原因

2015 (特になし)2016 9/15 複数 約2時間 • ネットワークの輻輳と名前解決機能不全

• ネットワーク制御ソフトの不具合2017 3/8 東日本 約2時間 • ストレージクラスター停止

• ストレージクラスター制御ソフトの不具合3/28 西日本 約3時間 • サービス間通信不全

• 増設時のネットワーク設定プロセスでのミス3/31 東日本 約9時間 • データセンター収容設備の強制シャットダウン

• 冗長化UPSの障害復旧プロセスでのミス

12.88ミリ秒18.92ミリ秒

9.00ミリ秒

App Service

CosmosDB

SQLDatabase

RedisCache

Storage(Contents)

Storage(Log, Config, etc)

CDN

App Service

CosmosDB

SQLDatabase

RedisCache

Storage(Contents)

Storage(Log, Config, etc)

TrafficManager

Active Region Standby Regionhttps://docs.microsoft.com/ja-jp/azure/architecture/reference-architectures/managed-web-app/multi-region-web-app

Traffic Managerマニュアル切り替え可能(優先度変更)

SQL Databaseマニュアル切り替え可能(Failover Group内でスイッチ)

Storageマニュアル切り替え不可

Cosmos DBマニュアル切り替え可能(Write Region変更)

Azure Storageで同期するのは、対抗リージョンでの即時回復、書き込みが不要な静的データ(ログや構成ファイル、バックアップデータなど)に限定する。即時読み取りが必要な場合は、RA-GRSでセカンダリを読めるようにしておく。

App Service

CosmosDB

SQLDatabase

RedisCache

Storage(Contents)

Storage(Log, Config, etc)

App Service

CosmosDB

SQLDatabase

RedisCache

Storage(Contents)

Storage(Log, Config, etc)

TrafficManager

Active Region Standby Region

CDN

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

Managed Disk

https://docs.microsoft.com/ja-jp/azure/architecture/resiliency/

0.99989(99.989%/月)

-> Error Budget 4.75分/月

https://docs.microsoft.com/ja-jp/azure/traffic-manager/traffic-manager-monitoringhttps://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中にて値の公開待ち

Demo

Multi Region Active/Standby Architecture

App Service App Service

TrafficManager

Active Region(Japan East)

Standby Region(US West 2)

Failover GroupSQL Database SQL Database

ARM Template

https://github.com/ToruMakabe/decode2017

別の機会でもっと詳しく！

レベル500でもOK！

合わせて読みたい“DI13ダウンタイムを最小に! 〜 Azure における障害/災害に耐えうるアーキテクチャ設計のポイント 〜”

© 2017 Microsoft Corporation. All rights reserved.

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

セッションアンケートにご協力ください

専用アプリからご回答いただけます。

decode 2017

スケジュールビルダーで受講セッションを登録後、アンケート画面からご回答ください。

アンケートの回答時間はたったの 15 秒です!

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