1. 15分でわかる NoOps
～ テクノロジの進化と価値観の変化を知る ～
NoOps Meetup Tokyo #1 2018.09.12

2. 1. NoOps の目指すもの
2. なぜ今 NoOps なのか
3. NoOps のつくりかた
 ミドルウェア / アプリケーション / 組織
[付録] NoOpsを支える技術
Agenda

3. システム運用の “嬉しくない” ことをなくそう

4. NoOps の目指すもの
1. ユーザーの体験を妨げないシステム運用保守の実現
• 障害時のダウン、計画停止、負荷集中時の性能低下、etc..
2. 運用保守の現場で発生する「トイル」の最小化
• リリース手続き、パッチの適用、リソース監視、待機、etc..
3. システム運用保守のリソースとコストの最適化
• 余剰資源を持たない、適正品質、時間外勤務、人材活用、etc..
システム運用保守に関する「嬉しくないもの」を取り除く活動

5. そこに立ちはだかる
Ops改善のジレンマ

6. コスト増（人・設備）現場の負担増
and/or

7. サービス低下
and/or
コスト増
（設備・アウトソース）

8. サービス低下
現場の負担激増
and/or

10. NoOps の目指すもの
1. ユーザーの体験を妨げないシステム運用保守の実現
• 障害時のダウン、計画停止、負荷集中時の性能低下、etc..
2. 運用保守の現場で発生する「トイル」の最小化
• リリース手続き、パッチの適用、リソース監視、待機、etc..
3. システム運用保守のリソースとコストの最適化
• 余剰資源を持たない、適正品質、時間外勤務、人材活用、etc..
システム運用保守に関する「嬉しくないもの」を取り除く活動

12. いまから10年前、「堅牢さ＝信頼性」だった
商用 UNIX Server

14. 進化

15. 「高い復元力」
実現の鍵は
回復性 ＝ 障害から回復して動作を続行するシステムの能力
障害の回避が目的ではなく、ダウンタイムやデータ損失を回避すべく障害に対応することを目指す。
回復性設計の目的は、障害発生時にもアプリケーションが完全に機能している状態を維持することである。

16. “取り回しの軽さ”

17. Robustness から Resiliency への
価値観の転換
「壊れない」 「いつでも回復できる」

18. 「復元力」
壊れても、動き続けるための能力

19. 高
低
なし
(秒単位で回復)
(数十分～数時間で回復)
(回復不能)
復元力
(Resiliencability)

20. 復元力
(Resiliencability)
サーバレス
コンテナ
仮想マシン(VM)
非冗長物理構成
物理機器
秒単位
数分～
数時間
～数日
復旧不能
高
低
なし

22. しかも、それだけじゃない。

23. - Self Healing
- In-Flight Renewing
– Adaptive Scale
「高い回復性」を持つことによる可能性の広がり

25. NoOps システムが備えるべき 3つの能力
NoOps
Failure

26. NoOps へ向かう最もシンプルなソリューション
仕様には書かれていない。
目利きが必要

27. でも、NoOps ってクラウドが前提なんでしょ？
https://www.slideshare.net/yokawasa/kubernetes-x-paas-noops

28. しかしミドルウェアだけでは不十分

29. アプリケーションにも回復力を持たせる必要がある

30. データベース
アプリサーバ
アプリアプリ アプリ
メッセージングサービ
ス
アプリケーション
プラットフォーム
Monitor
Monitor
Automation
Automation
Monitor
Automation
Monitor
Automation
システム全体のNoOpsを実現するには、プラットフォームだけでなく
アプリケーションの回復性も必要
システム利用者
アプリケーションの
「復元力（Resiliencability）」は
設計指針によって実装される
アプリケーション向けの
カスタム回復メカニズム
復元力
Monitor
Automation
プラットフォーム向けのカスタム
回復メカニズム
プラットフォームの
「復元力」は、主にHA機構として既に
有していることが多い。
復元力
プラットフォームの備える
回復メカニズム

31. 回復性のためのアプリケーション設計原則
1回の大きな処理よりも複数の小さな処理を選ぶ
処理はステートレスで設計する
非同期処理を前提に設計する
処理の冪等（べきとう）性を担保する
全ての処理結果を記録する

32. ① 処理データの
リクエスト
③注文ステータス更新処理
10万回ループ
Database
仮想マシン
④ 処理結果の書き込み
② 10万件のデータ取得

33. ① 処理データの
リクエスト
Database
Serverless
② 10万件のデータ
④ Jobを1件ずつ
キューに投入
⑤（可能であれば）
Jobの並列実行
Serverless ファーム
Monitor
Automation
カスタム回復メカニズム
Jobとキューの監視と回復処理
③ 10万件の個別処理に分離
⑥ 処理結果の書き込み

34. https://github.com/NoOps-jp/functions-batch-handson
https://github.com/zenarchitects/functions-batchapps
ハンズオンマテリアル
サンプルコード
Share on

35. NoOps を実現するチーム

36. DevOps
伝統的運用保守
（ITIL型）
Design for Robustness
（堅牢さを前提とした設計）
Design for Failure
（故障を前提とした設計）
NoOps
Design for Resiliency
（回復性設計）
SRE
（信頼性エンジニアリング）
アジャイルによる
価値観の転換
クラウドによる
価値観の転換
しっかりと計画され、厳密に
管理された運用保守業務。
正常稼働していることが通常状態。
故障や不具合は例外処理として設計。
故障や不具合も通常状態として扱い、
発生時を想定して設計する。
開発と運用保守を一体として扱い、
状況の変化に柔軟に対応できる組織。
1990年代～ 2008年
運用保守アプローチ
運用保守もエンジニアリング業務として扱う。
ヒューマンエラーを最小化し、システムの信頼性
を維持するための継続的改善活動。
復旧作業時のヒューマンエラーを最小化する
ため、障害の発生から正常稼働状態への復旧
まで想定して設計する。
システム設計アプローチ
2014年 現在

37. Design for Resiliency
SRE
NoOps =
DevOps

38. NoOpsの活動ライフサイクル
回復性設計
アーキテクト
システム
エンジニアリング
基本設計
NoOps活動
自律運用
手動運用
システム
運用保守
エンジニアリング
自律運用
システム
SREチーム開発チーム
非機能要求
「人間による運用保守作業を最小化する」
アーキテクチャの変更
システムに回復性を後から備えさせることは困難
基本設計時点で回復性を持たせることが重要
システムは変化し続ける前提で
継続的に運用保守を改善する活動機能の追加・変更
自動化の促進
手動運用の
増加
システムの初期開発時

39. 「OSやミドルウェアのメンテナンスは
サービス無停止で行う」
「ハードウェアの交換も、もちろんサービス無停止」

40. 「OSやミドルウェアのメンテナンスは
サービス無停止で行う」
「ハードウェアの交換も、もちろんサービス無停止」

43. 「回復性」のレベルは、後から変更できない
技術の進化とともに、
「要求」も「設計」も進化しなければならない

44. システム運用の “嬉しくない” ことをなくそう
システムに関わる全ての人が
ハッピーになるために。

45. 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

46. Thank You!

48. NoOps システムが備えるべき 3つの能力
NoOps
Failure

49. Resiliencability
ConfigurabilityObservability
NoOps Landscape
NoOps Ready Solutions
Application Platform
Database
Messaging
Container Serverless
Runbook
CI/CD
Image Build/Repository
Coordination
Monitor
Log
Azure
Web Apps
Azure
Functions
Azure Monitor
Log Analytics
Azure
Automation
Cosmos DB
Azure DB for
MySQL/PostgreSQL
Service
Fabric
AKS
Data Analysis
AWS
Lambda
GKE
Google
Cloud Functions
AWS
Cloudwatch
Google
AppEngine
Container Based Solution with
- Self Healing
- In-Flight Renewing
- Adaptive Scale
and API Based
Configration/Provisioning ability.
Platform with High Resiliency.
Azure
Event Grid
NoOps Landscape
絶賛定義中
でも、自分たちの視野ではぜんぜん足りない

50. こんな感じに
できるといいなあ

51. 一緒に考えてもいいよ、という方は ＠okahiromasa までお声がけください