Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

[DO05] システムの信頼性を上げるための新しい考え方 SRE ( Site Reliability Engineering ) in Azure, on Azure

3 262 vues

Publié le

DevOps と並び、技術者の注目を集める SRE。このセッションでは Azure の「中」の SRE と、Azure 上でシステムを動かすユーザーの SRE、2 つの視点で解説します。システムの信頼性は気合でも手作業でもなく、エンジニアリングで高める時代です。障害に耐える組織と仕組みづくりとは? エモい話から黒い画面のデモまで、Azure における SRE の「いま」をお伝えします。

製品/テクノロジ: DevOps/Linux/Microsoft Azure/OSS/Windows Server/アーキテクチャ/クラウド/運用/事業継続

真壁 徹
日本マイクロソフト株式会社
クラウド & ソリューション ビジネス統括本部
クラウド ソリューション アーキテクト

Publié dans : Technologie
  • Soyez le premier à commenter

[DO05] システムの信頼性を上げるための新しい考え方 SRE ( Site Reliability Engineering ) in Azure, on Azure

  1. 1. { “名前” : “真壁 徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研  HP Enterprise”, “特技” : “クラウド & オープンソース” }
  2. 2. Azure Regionオンプレミス(ユーザー占有型) User User User User Storage Cluster Storage Cluster Server Cluster Server Cluster 共用部分が大きい
  3. 3. Azure Regionオンプレミス(ユーザー占有型) User User User User Storage Cluster Storage Cluster Server Cluster Server Cluster 影響範囲 ストレージクラスターが故障した場合 影響範囲が大きい
  4. 4. Azure Regionオンプレミス(ユーザー占有型) User User User User Storage Cluster Storage Cluster Server Cluster Server Cluster データセンター全体で共有している設備の障害影響は、 オンプレもAzureも同様
  5. 5. どれも冗長化、自己回復機能を有するが、不具合や作業ミスの可能性はゼロではない ユーザーがそれに対処するにはマルチリージョン構成が有効
  6. 6. Azure Storage Cluster Storage Cluster Server Cluster Server Cluster
  7. 7. 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/
  8. 8. • 2008 Azure 発表 • 2008 – 2014 様々なDevOpsアプローチ • 2014 SREチームのパイロット運用開始 • 2015 SREチームを正式に組織化
  9. 9. https://azure.microsoft.com/ja-jp/support/legal/sla/
  10. 10. インフラチーム SRE (Proactive) Operation (Reactive) 仕組みづくりに 集中
  11. 11. 認知までの時間を 最小化 エスカレーション、 アサインの自動化 高速なロールバック、 フェイルオーバー、 再構築、増強 SREが仕組みを作る
  12. 12. 相互理解
  13. 13. 可用性 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 秒
  14. 14. 可用性 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)
  15. 15. 認知までの時間を 最小化 エスカレーション、 アサインの自動化 高速なロールバック、 フェイルオーバー、 再構築、増強 SREは全体設計、検証、 訓練と最適化を行う
  16. 16. 0.9994 (99.94%/月) -> Error Budget 25.92分/月 https://docs.microsoft.com/ja-jp/azure/architecture/resiliency/ 2592000秒)とすると
  17. 17. 発生年 発生日 リージョン 復旧までの 時間 概要と原因 2015 (特になし) 2016 9/15 複数 約2時間 • ネットワークの輻輳と名前解決機能不全 • ネットワーク制御ソフトの不具合 2017 3/8 東日本 約2時間 • ストレージクラスター停止 • ストレージクラスター制御ソフトの不具合 3/28 西日本 約3時間 • サービス間通信不全 • 増設時のネットワーク設定プロセスでのミス 3/31 東日本 約9時間 • データセンター収容設備の強制シャットダウン • 冗長化UPSの障害復旧プロセスでのミス
  18. 18. 12.88ミリ秒18.92ミリ秒 9.00ミリ秒
  19. 19. 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
  20. 20. Traffic Manager マニュアル切り替え可能 (優先度変更) SQL Database マニュアル切り替え可能 (Failover Group内でスイッチ) Storage マニュアル切り替え不可 Cosmos DB マニュアル切り替え可能 (Write Region変更) Azure Storageで同期するのは、対抗リージョンでの即時回復、書き込みが不要な 静的データ(ログや構成ファイル、バックアップデータなど)に限定する。 即時読み取りが必要な場合は、RA-GRSでセカンダリを読めるようにしておく。
  21. 21. 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
  22. 22. (青色)ユーザーが明示的に分離できる要素 Managed Disk
  23. 23. https://docs.microsoft.com/ja-jp/azure/architecture/resiliency/ 0.99989 (99.989%/月) -> Error Budget 4.75分/月
  24. 24. 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中にて値の公開待ち
  25. 25. Demo Multi Region Active/Standby Architecture
  26. 26. App Service App Service Traffic Manager Active Region (Japan East) Standby Region (US West 2) Failover Group SQL Database SQL Database ARM Template
  27. 27. https://github.com/ToruMakabe/decode2017
  28. 28. 別の機会で もっと詳しく! レベル500でもOK! 合わせて読みたい “DI13ダウンタイムを最小に! 〜 Azure における障害/災害に耐えうるアーキテクチャ設計のポイント 〜”
  29. 29. © 2017 Microsoft Corporation. All rights reserved. 本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。
  30. 30. セッションアンケートにご協力ください  専用アプリからご回答いただけます。 decode 2017  スケジュールビルダーで受講セッションを 登録後、アンケート画面からご回答ください。  アンケートの回答時間はたったの 15 秒です!
  31. 31. Ask the Speaker のご案内 本セッションの詳細は『Ask the Speaker Room』各コーナーカウンタにて ご説明させていただきます。是非、お立ち寄りください。

×