Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

NoOpsへ舵を切れ

4,084 views

Published on

Microsoft de:code 2018 AD15 の講演資料です #NoOpsJP

Published in: Technology
  • Be the first to comment

NoOpsへ舵を切れ

  1. 1. NoOps へ舵を切れ - Azure で実践するサーバレス自律運用システム AD15
  2. 2. 岡 大勝 @okahiromasa 株式会社ゼンアーキテクツ 代表取締役CEO アーキテクト DKIS ⇒ DEC ⇒ HP ⇒ Rational Software 金融SE ⇒ オブジェクト指向&RUP の導入支援 2003年にゼンアーキテクツを設立 先端技術による”企業のIT投資の最適化”がミッション 2013年 日経BP「日本のトップITアーキテクト」の 一人として選出
  3. 3. https://www.slideshare.net/decode2017/ac08-76587003 http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00263/041900001/ https://www.slideshare.net/hiromasaoka/noops-88082246 https://noops.connpass.com
  4. 4. NoOps
  5. 5. NoOps = No Operations
  6. 6. 完全自動化? 無人運用?
  7. 7. NoOps = No Operations ?
  8. 8. Uncomfortable
  9. 9. システム運用の “嬉しくない” ことをなくそう
  10. 10. そして、みんなハッピーに!
  11. 11. NoOps とは? 1. 利用者の体験を妨げないシステム運用保守の実現 • 障害時のダウン、計画停止、負荷集中時の性能低下、etc.. 2. システム運用保守で発生する「トイル」の最小化 • リリース手続き、パッチの適用、リソース監視、待機、etc.. 3. システム運用保守コストの最適化 • 余剰資源を持たない、適正品質、人材活用、働き方改革、etc.. システム運用保守に関する「嬉しくないもの」を取り除く活動 BE HAPPY !!
  12. 12. Google “Site Reliability Engineering”より
  13. 13. 障害発生 初期対応 切り分けと 原因究明 サービス停止期間 不具合修正 正常稼働 復旧作業 一般的な障害発生時の作業 NoOps で目指すシステム運用保守の姿 人間による 作業
  14. 14. 人間は以下に専念 • 障害の原因究明 • システムの「設計」改善 • より良いサービスに向けた活動 障害発生 初期対応 切り分けと 原因究明 サービス停止期間 不具合修正 正常稼働 復旧作業 正常稼働 障害発生 システムが 障害検知 回復処理 サービス無停止 一般的な障害発生時の作業 NoOpsで目指すシステム運用保守 NoOps で目指すシステム運用保守の姿 システムが 自律的に行う 人間による 作業
  15. 15. テクノロジの進化で 「できない」 ことが 「できる」 ようになった
  16. 16. 実現できるようになった NoOps の3つの能力
  17. 17. Securing Azure customers from CPU vulnerability CPU の脆弱性から Azure のお客様を保護するために Azure App Service upgrade to Windows Server 2016 #63 Azure App Service、Azure FunctionsのWindows Server 2016へのアップグレード
  18. 18. https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/accelerated-maintenance
  19. 19. 「高い復元力」 実現の鍵は
  20. 20. “取り回しの軽さ”
  21. 21. Robustness から Resiliency への 価値観の転換 「壊れない」 「いつでも回復できる」
  22. 22. 復元力 構成要素の一部が一時的に利用できない状態に なったとしても、サービスの稼働に影響を与えること なく元の状態に回復できる能力。 オートヒーリングやスロットリングなどの回復性設計 パターンによって実装される。 Monitor Automation 回復メカニズム 故障や過負荷などのイベントを識別するための監 視(Monitor)と、イベント発生時にリトライなど の回復処理を実行する自動化スクリプト (Automation)によって構成され、復元力を持 つサービスを正常な状態に回復させる役割を担う。 (Resiliencability) (Mechanism of resilience) 「回復性」 (Resiliency) サービスに影響を 与えそうな事象 サービスは 問題なく稼働継続
  23. 23. 復元力 (Resiliencability) 高 低 なし (秒単位) (分単位) (回復不能)
  24. 24. 回復性パターン(Resiliency Patterns) 【復元力のパターン】  リトライ  スワップ  フェールオーバー  オートヒーリング  デグレード  バルクヘッド  サーキットブレーカー  スロットリング  スケールアウト  キューによる負荷平準化(QLL)  補償トランザクション  リーダー選択 【回復メカニズムのパターン】  イベント通知  正常性モニター  ログ検知 https://docs.microsoft.com/ja-jp/azure/architecture/resiliency/ 【参考】 回復性に優れた Azure 用アプリケーションの設計 「高い復元力」を持つサービスのみ可能
  25. 25. App Service Functions Azure DB for MySQL SQL Database Azure DB for PostgreSQL SQL Data Warehouse Azure Data Factory Event Hub Service Fabric Azure Kubernetes Service (AKS) Azure Container Instances Virtual Machine Virtual Network Blob Storage Search Redis HD Insight Service Bus Media Service Application Gateway Load Balancer Managed Disks Cosmos DB
  26. 26. App Service Functions Azure DB for MySQL SQL Database Azure DB for PostgreSQL Cosmos DB SQL Data Warehouse Azure Data Factory Event Hub Service Fabric Azure Kubernetes Service (AKS) Azure Container Instances Virtual Machine Virtual Network Blob Storage Search Redis HD Insight Service Bus Media Service Application Gateway Load Balancer Managed Disks コンテナ上で稼働コンテナエンジン VM上で稼働
  27. 27. 復元力 (Resiliencability) 高 低 なし (秒単位) (分単位) サーバレス コンテナ VM 非冗長物理構成
  28. 28.  RTO と ターンアラウンドタイム の違いは?  分散保持により データ復旧の必要がないなら?
  29. 29. 「高い回復性」を持つことによる可能性の広がり
  30. 30. https://www.slideshare.net/hiromasaoka/noops-88082246
  31. 31. Azure Regions Datacenters (Zone) … Scale Units (Stamps) …
  32. 32. https://msdn.microsoft.com/en-us/magazine/mt793270.aspx 世界中のScale Unit (SU)に関する情報を保持しリソースコント ロールを行う • アプリ作成時にその要件に基づいてGeo Masterが最適なSUを選択肢し、そのSU に処理をフォワード
  33. 33. Scale Unit … Upgrade Domain(UD) x 20 1 UDはSU全体の約5% のVMに相当 Container Registry CRUD API Publishing HTTP
  34. 34. • 3インスタンス
  35. 35. In-Flight Renewing 1. アップグレード対象UDのアプリをHot Poolの空きVMに 移動させ、移動後アプリをサービス管理下に投入。全て のアプリを他にオフロード 2. 対象UDでアップグレードを実行 • 3インスタンス• 3インスタンス
  36. 36. Self Healing 1. 監視システムが障害ロールを検知し、サービス管理下よ り障害ロールを切り離す 2. Appサービスプランに基づき足りないロールをHot Poolよ り割り当て、サービス管理下に投入 • 3インスタンス
  37. 37. Adaptive Scale 1. メータリングシステムが負荷を測定し、ユーザ指定のメト リックが閾値を超えたことを検知 2. プランに基づきHot Poolよりスケール用のVMを割り当て、 サービス管理下に投入 • 通常3インスタンス • 最大5インスタンス
  38. 38. Data Azure Storage LRS ペアリージョン(西日本) プライマリリージョン(東日本) GEOバックアップ 接続エンドポイント VM Service Fabric Azure Database Service Platform コンテナ化された MySQL/PostgreSQL エンジン MySQL /PgSQL GEOリストア Service Fabric クラスター 選択した価格レベルの クラスターのノードを確保し コンテナ化されたデータベースエンジン をデプロイ Gateway node node MySQL /PgSQL ノード障害を検出すると クラスタ上の別ノードに 再デプロイして処理を継続 ストレージはLRS冗長構成 (ローカル(同一DC)三重化) バックアップデータは ペアリージョンへの GEO冗長構成とともに ペアリージョン上への リストア(GEOリストア)も可能 Backup 5分間隔で自動バックアップ (最大35日分)
  39. 39. Service Fabric クラスター MySQLコンテナMy PG SQL PostgreSQLコンテナ SQL Databaseコンテナ My PG SQL MySQLなどのAzure Databaseのインスタンスは、 Service Fabricクラスター上の軽量コンテナとして稼働する。 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5 東日本リージョン
  40. 40. Service Fabric クラスター MySQLコンテナMy PG SQL PostgreSQLコンテナ SQL Databaseコンテナ My PG SQL My PG SQL My ノード障害が発生すると、Service Fabricクラスター上の 別ノードにコンテナをデプロイし、フェールオーバーを行う。 MySQLなどのAzure Databaseのインスタンスは、 Service Fabricクラスター上の軽量コンテナとして稼働する。 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5 Service Fabric クラスター GP-Gen5 空きノードへの コンテナのデプロイと構成 エンドポイントの切替 東日本リージョン 東日本リージョン
  41. 41. Service Fabric クラスター MySQLコンテナMy PG SQL PostgreSQLコンテナ SQL Databaseコンテナ My PG SQL My PG SQL My ノード障害が発生すると、Service Fabricクラスター上の 別ノードにコンテナをデプロイし、フェールオーバーを行う。 MySQLなどのAzure Databaseのインスタンスは、 Service Fabricクラスター上の軽量コンテナとして稼働する。 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5GP-Gen5 GP-Gen5 GP-Gen5 Service Fabric クラスター GP-Gen5 空きノードへの コンテナのデプロイと構成 エンドポイントの切替 東日本リージョン 東日本リージョン
  42. 42. NoOps へ向かう最もシンプルなソリューション
  43. 43. でも、NoOps ってクラウドが前提なんでしょ? https://www.slideshare.net/yokawasa/kubernetes-x-paas-noops
  44. 44. しかし、ミドルウェアだけでは不十分
  45. 45. アプリケーションにも回復力を持たせる必要がある
  46. 46. データベース アプリサーバ アプリアプリ アプリ メッセージングサービ ス アプリケーション プラットフォーム Monitor Monitor Automation Automation Monitor Automation Monitor Automation システム全体のNoOpsを実現するには、プラットフォームだけでなく アプリケーションの回復性も必要 システム利用者 アプリケーションの 「復元力(Resiliencability)」は 設計指針によって実装される アプリケーション向けの カスタム回復メカニズム 復元力 Monitor Automation プラットフォーム向けのカスタム 回復メカニズム プラットフォームの 「復元力」は、主にHA機構として既に 有していることが多い。 復元力 プラットフォームの備える 回復メカニズム
  47. 47. 回復性のためのアプリケーション設計原則 1回の大きな処理よりも複数の小さな処理を選ぶ 処理はステートレスで設計する 非同期処理を前提に設計する 処理の冪等(べきとう)性を担保する 全ての処理結果を記録する
  48. 48. ① 処理データの リクエスト ③注文ステータス更新処理 10万回ループ Database 仮想マシン ④ 処理結果の書き込み ② 10万件のデータ取得
  49. 49. ① 処理データの リクエスト Database Serverless ② 100万件のデータ ④ Jobを1件ずつ キューに投入 ⑤(可能であれば) Jobの並列実行 Serverless ファーム Monitor Automation カスタム回復メカニズム Jobとキューの監視と回復処理 ③ 10万件の個別処理に分離 ⑥ 処理結果の書き込み
  50. 50. https://github.com/NoOps-jp/functions-batch-handson https://github.com/zenarchitects/functions-batchapps ハンズオンマテリアル サンプルコード Share on
  51. 51. Blob1 Akamai SE1 SE2 SE3 SEN Blob2 Blob3 BlobN State Monitor AMS Blob1 SE1 SE2 SE3 SEN Blob2 Blob3 BlobN AMS State Monitor Japan East Region Japan West Region State Monitor 1. 自律動作するスケジュール実行アプリケーション 2. 動画配信サービス内の各構成要素(Storageなど)の正常性を確認 3. 東西+国外リージョンの3箇所に配置。等間隔(1〜5分)でローテーション実行 4. モニタリング結果は、同様に3箇所に分散配置されたCosmosDBにState Logと して格納 5. 障害を検知した時点でTMのAPIより該当リージョンへのルーティングを切断。同時 にState Logに「リージョン切断」を記録 6. Logの切断を確認した以降のモニターは、モニタリングは継続するが、該当リージョ ンの障害によるアクションは行わない。 7. 障害回復によるリージョンの再接続(フェールバック)は手動で実施 Routing Change Request State Monitor State Log Cosmos DB State Log Cosmos DB Southeast Region (Singapore) その他 • Traffic ManagerのProbeも有効。Monitorの動作との整合性を保つため、 TMの状態もMonitorが監視する。 • 障害検知時は、Event Grid経由でリアルタイム通知 • State Logの内容を常時確認できるようなフロントエンドを用意 State Log Cosmos DB API Call Traffic Manager failure Failure Message メール SMS Chat DNS TTL < 10s SGP JP-E JP-W  3リージョンに分散配置された State Monitorが数分間隔で巡回監視  監視結果のステートはGlobal GEO Replされた Cosmos DBで一元保持  障害発生時はAPIからTMをスケールイン 実装方式 Event Grid
  52. 52. NoOps を実現するチーム
  53. 53. DevOps 伝統的運用保守 (ITIL型) Design for Robustness (堅牢さを前提とした設計) Design for Failure (故障を前提とした設計) NoOps Design for Resiliency (回復性設計) SRE (信頼性エンジニアリング) アジャイルによる 価値観の転換 クラウドによる 価値観の転換 しっかりと計画され、厳密に 管理された運用保守業務。 正常稼働していることが通常状態。 故障や不具合は例外処理として設計。 故障や不具合も通常状態として扱い、 発生時を想定して設計する。 開発と運用保守を一体として扱い、 状況の変化に柔軟に対応できる組織。 1990年代~ 2008年 運用保守アプローチ 運用保守もエンジニアリング業務として扱う。 ヒューマンエラーを最小化し、システムの信頼性 を維持するための継続的改善活動。 復旧作業時のヒューマンエラーを最小化する ため、障害の発生から正常稼働状態への復旧 まで想定して設計する。 システム設計アプローチ 2014年 現在
  54. 54. Design for Resiliency SRE NoOps = DevOps
  55. 55. NoOpsの活動ライフサイクル 回復性設計 アーキテクト システム エンジニアリング 基本設計 NoOps活動 自律運用 手動運用 システム 運用保守 エンジニアリング 自律運用 システム SREチーム開発チーム 非機能要求 「人間による運用保守作業を最小化する」 アーキテクチャの変更 システムに回復性を後から備えさせることは困難 基本設計時点で回復性を持たせることが重要 システムは変化し続ける前提で 継続的に運用保守を改善する活動機能の追加・変更 自動化の促進 手動運用の 増加 システムの初期開発時
  56. 56. 「回復性」のレベルは、後から変更できない
  57. 57. NoOps
  58. 58. ものづくりが、 また、楽しくなってきた
  59. 59. 本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。 L♥VE to CODE https://zenarchitects.co.jp https://noops.connpass.com NoOps Japan Community

×