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 で変わる 人とシステムの関わりかた

664 views

Published on

2018年6月8日に京都でお話した資料です。

Published in: Software
  • Be the first to comment

  • Be the first to like this

NoOps で変わる 人とシステムの関わりかた

  1. 1. NoOps で変わる 人とシステムの関わりかた
  2. 2. 岡 大勝 @okahiromasa 株式会社ゼンアーキテクツ 代表取締役CEO アーキテクト DKIS ⇒ DEC ⇒ HP ⇒ Rational Software 金融SE ⇒ オブジェクト指向&RUP の導入支援 2003年にゼンアーキテクツを設立 先端技術による”企業のIT投資の最適化”がミッション 2013年 日経BP「日本のトップITアーキテクト」の 一人として選出
  3. 3. NoOps
  4. 4. NoOps = No Operations システム運用がなくなる?
  5. 5. 完全自動化? 無人運用?
  6. 6. NoOps = No Operations ?
  7. 7. Uncomfortable
  8. 8. システム運用の “嬉しくない” ことをなくそう
  9. 9. そして、みんなハッピーに!
  10. 10. NoOps とは? 1. ユーザーの体験を妨げないシステム運用保守の実現 • 障害時のダウン、計画停止、負荷集中時の性能低下、etc.. 2. システム運用保守で発生する「トイル」の最小化 • リリース手続き、パッチの適用、リソース監視、待機、etc.. 3. システム運用保守コストの最適化 • 余剰資源を持たない、適正品質、時間外勤務、人材活用、etc.. システム運用保守に関する「嬉しくないもの」を取り除く活動 BE HAPPY !!
  11. 11. Google “Site Reliability Engineering”より
  12. 12. 障害発生 初期対応 切り分けと 原因究明 サービス停止期間 不具合修正 正常稼働 復旧作業 一般的な障害発生時の作業 NoOps で目指すシステム運用保守の姿 人間による 作業
  13. 13. 人間は以下に専念 • 障害の原因究明 • システムの改善、手作業の削減 • より良いサービスに向けた活動 障害発生 初期対応 切り分けと 原因究明 サービス停止期間 不具合修正 正常稼働 復旧作業 正常稼働 障害発生 システムが 障害検知 回復処理 サービス無停止 一般的な障害発生時の作業 NoOpsで目指すシステム運用保守 NoOps で目指すシステム運用保守の姿 システムが 自律的に行う 人間による 作業
  14. 14. テクノロジの進化で 「できない」 ことが 「できる」 ようになった
  15. 15. 実現できるようになった NoOps の3つの能力 • 「障害からの自己修復」 • 「無停止メンテナンス」 • 「自律的リソース調整」
  16. 16. 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へのアップグレード Azureの二度の大規模ホストVMメンテナンス
  17. 17. https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/accelerated-maintenance
  18. 18. 「高い復元力」 実現の鍵は
  19. 19. “取り回しの軽さ”
  20. 20. Robustness から Resiliency への 価値観の転換 「壊れない」 「いつでも回復できる」
  21. 21. 「復元力」 壊れても、動き続けるための能力
  22. 22. 復元力 (Resiliencability) 高 低 なし (秒単位で回復) (数十分~数時間で回復) (回復不能)
  23. 23. 復元力 (Resiliencability) 高 低 なし サーバレス コンテナ 仮想マシン(VM) 非冗長物理構成 物理機器 秒単位 数分~ 数時間 復旧不能
  24. 24. しかも、それだけじゃない。
  25. 25. 「高い回復性」を持つことによる可能性の広がり
  26. 26. 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日分)
  27. 27. 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 東日本リージョン
  28. 28. 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 空きノードへの コンテナのデプロイと構成 エンドポイントの切替 東日本リージョン 東日本リージョン
  29. 29. 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 空きノードへの コンテナのデプロイと構成 エンドポイントの切替 東日本リージョン 東日本リージョン
  30. 30. NoOps へ向かう最もシンプルなソリューション
  31. 31. でも、NoOps ってクラウドが前提なんでしょ? https://www.slideshare.net/yokawasa/kubernetes-x-paas-noops
  32. 32. しかし、ミドルウェアだけでは不十分
  33. 33. アプリケーションにも回復力を持たせる必要がある
  34. 34. データベース アプリサーバ アプリアプリ アプリ メッセージングサービ ス アプリケーション プラットフォーム Monitor Monitor Automation Automation Monitor Automation Monitor Automation システム全体のNoOpsを実現するには、プラットフォームだけでなく アプリケーションの回復性も必要 システム利用者 アプリケーションの 「復元力(Resiliencability)」は 設計指針によって実装される アプリケーション向けの カスタム回復メカニズム 復元力 Monitor Automation プラットフォーム向けのカスタム 回復メカニズム プラットフォームの 「復元力」は、主にHA機構として既に 有していることが多い。 復元力 プラットフォームの備える 回復メカニズム
  35. 35. 回復性のためのアプリケーション設計原則 1回の大きな処理よりも複数の小さな処理を選ぶ 処理はステートレスで設計する 非同期処理を前提に設計する 処理の冪等(べきとう)性を担保する 全ての処理結果を記録する
  36. 36. ① 処理データの リクエスト ③注文ステータス更新処理 10万回ループ Database 仮想マシン ④ 処理結果の書き込み ② 10万件のデータ取得
  37. 37. ① 処理データの リクエスト Database Serverless ② 10万件のデータ ④ Jobを1件ずつ キューに投入 ⑤(可能であれば) Jobの並列実行 Serverless ファーム Monitor Automation カスタム回復メカニズム Jobとキューの監視と回復処理 ③ 10万件の個別処理に分離 ⑥ 処理結果の書き込み
  38. 38. https://github.com/NoOps-jp/functions-batch-handson https://github.com/zenarchitects/functions-batchapps ハンズオンマテリアル サンプルコード Share on
  39. 39. NoOps を実現するチーム
  40. 40. DevOps 伝統的運用保守 (ITIL型) Design for Robustness (堅牢さを前提とした設計) Design for Failure (故障を前提とした設計) NoOps Design for Resiliency (回復性設計) SRE (信頼性エンジニアリング) アジャイルによる 価値観の転換 クラウドによる 価値観の転換 しっかりと計画され、厳密に 管理された運用保守業務。 正常稼働していることが通常状態。 故障や不具合は例外処理として設計。 故障や不具合も通常状態として扱い、 発生時を想定して設計する。 開発と運用保守を一体として扱い、 状況の変化に柔軟に対応できる組織。 1990年代~ 2008年 運用保守アプローチ 運用保守もエンジニアリング業務として扱う。 ヒューマンエラーを最小化し、システムの信頼性 を維持するための継続的改善活動。 復旧作業時のヒューマンエラーを最小化する ため、障害の発生から正常稼働状態への復旧 まで想定して設計する。 システム設計アプローチ 2014年 現在
  41. 41. Design for Resiliency SRE NoOps = DevOps
  42. 42. NoOpsの活動ライフサイクル 回復性設計 アーキテクト システム エンジニアリング 基本設計 NoOps活動 自律運用 手動運用 システム 運用保守 エンジニアリング 自律運用 システム SREチーム開発チーム 非機能要求 「人間による運用保守作業を最小化する」 アーキテクチャの変更 システムに回復性を後から備えさせることは困難 基本設計時点で回復性を持たせることが重要 システムは変化し続ける前提で 継続的に運用保守を改善する活動機能の追加・変更 自動化の促進 手動運用の 増加 システムの初期開発時
  43. 43. 「障害が発生してもサービス無停止で復旧する」
  44. 44. 「OSやミドルウェアのメンテナンスは サービス無停止で行う」
  45. 45. 「OSやミドルウェアのメンテナンスは サービス無停止で行う」 「ハードウェアの交換も、もちろんサービス無停止」
  46. 46. 「OSやミドルウェアのメンテナンスは サービス無停止で行う」 「ハードウェアの交換も、もちろんサービス無停止」
  47. 47. 「回復性」のレベルは、後から変更できない 技術の進化とともに、 「要求」も「設計」も進化しなければならない
  48. 48. システム運用の “嬉しくない” ことをなくそう
  49. 49. みんなハッピーに!
  50. 50. http://tech.nikkeibp.co.jp/atcl/nxt/column/18/00263/041900001/ https://www.slideshare.net/hiromasaoka/noops-88082246 https://noops.connpass.com https://www.slideshare.net/hiromasaoka/noops-98595318

×