2018年10月26日に行われたNoOps Japan Community主催のイベントNoOps Meetup Tokyo #2での講演「MicroserviceでのNoOps戦略」の資料です。 togetter https://togetter.com/li/1281339

1. MicroserviceでのNoOps戦略
2018/10/26
鈴木雄介
グロースエクスパートナーズ株式会社 執行役員
日本Javaユーザーグループ 会長
NoOps Japan Community
NoOps Meetup Tokyo #2

2. 自己紹介
鈴木雄介
• グロースエクスパートナーズ（株）
» 執行役員/アーキテクチャ事業本部長
» http://www.gxp.co.jp/
• 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/
• SNS
» http://arclamp.hatenablog.com/
» @yusuke_arclamp
1

3. アジェンダ
• NoOpsとは
• サービスを管理せよ
• ありがちな課題の解決
• まとめ
2

4. NoOpsとは
3

5. 何を目指すべきか？
ITサービスのライフサイクルを早くする
• 重要なのは全体を素早く回し続けること
4
利用
企画
実装
運用

6. NoOpsとは
はじまりはアジャイル
• 2001年：アジャイルソフトウェア開発宣言
»プロセスやツールよりも個人と対話を、
»包括的なドキュメントよりも動くソフトウェアを、
»契約交渉よりも顧客との協調を、
»計画に従うことよりも変化への対応を
• 「企画→開発」のスピードアップ
»ウォーターフォールへの批判
5参考：http://www.agilemanifesto.org/iso/ja/
利用
企画
実装
運用

7. NoOpsとは
そしてDevOps
• アジャイルをインフラや運用の仕事にも適用する
• 2009年：DevOps
»Agile 2008：Agile Infrastructure & Operations
▸政府系システム群のデータセンター移行にスクラムを導入した事例
»Velocity 2009：10+ Deploys Per Day
▸Flickrにおける開発と運用の協業について
»Devopsdays Ghent 2009
▸上記の講演を聞いた人が企画してスタート
6
利用
企画
実装
運用
参考：http://www.jedi.be/presentations/agile-infrastructure-agile-2008.pdf
参考：http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr

8. NoOpsとは
NoOpsの登場
• 2011年：NoOps
»Augment DevOps With NoOps
▸A DevOps focus on collaboration evolves into a NoOps focus on
automation
»I Don’t Want DevOps. I Want NoOps.
▸NoOps means that application developers will never have to speak
with an operations professional again.
»「NoOps」という言葉が強かったため炎上
▸運用はいらない？運用担当者はいらない？
7
参考：https://www.forrester.com/report/Augment+DevOps+With+NoOps/-/E-RES59203?objectid=RES59203
参考：https://go.forrester.com/blogs/11-02-07-i_dont_want_devops_i_want_noops/

9. NoOpsとは
その後の議論1
• 2012年：Ops, DevOps and PaaS (NoOps) at Netflix
» ビルド＆デプロイ自動化ツールを開発し、リリース作業は開発者がコ
ンソールを操作するだけ（カナリアリリース）
▸各チームは、それぞれのタイミングでリリースをしている
» アラートは自動収集で開発者に直接通知、ツールでログが見られる
» Cassandra用管理ツールを開発し、開発者が管理できる
» こういうツール開発をDevOps/SREチームがやっている
» 運用をするための組織は存在せず、開発者は運用と話す必要は無い
» 開発者を運用タスクから解放し、セルフサービスツールを提供する
8参考：http://perfcap.blogspot.com/2012/03/ops-devops-and-noops-at-netflix.html

10. NoOpsとは
その後の議論2
• Why 2013 is the year of ‘NoOps’ for programmers
9参考：https://gigaom.com/2012/01/31/why-2013-is-the-year-of-noops-for-programmers-infographic/
»90年代：データセンター集約
»2006年：API（AWS）
▸APIによるサーバ資源の操作＝IaaS
»2011年：SysOps（Puppet/Chef）
»2012年：AppLifecycle（Cloud
Foundry/OpenShift）
»2013年：NoOps（AppFog/Heroku）
▸PaaSによる運用作業の極小化

11. NoOpsとは
NoOpsの総論
• 運用作業の自動化とツール化
»自動化とツール化を担当するエンジニアがいる
▸DevOpsエンジニア or SRE
»PaaSであれば自動化の基盤が提供されていて便利
• 開発者はツールを使って運用作業を行う
»運用周りの作業をするのに運用担当者と会話する必要は無い
»だから、手順に従って作業するレベルのオペレーターは不要
10

12. NoOpsとは
NoOpsが変えたこと
• 「作る」と「動かす」の距離がなくなる
»運用作業がツール化されることで役割分担が変わった
▸インフラ構築、リリース作業、障害通知、復旧作業など
»いまは開発者が「作って動かす」まで管理する
11
成果物 サービス
Dev Ops
成果物 サービス
Dev
SRE
Ops
運用
ﾂｰﾙ

13. Microservices
そしてMicroservicesへ
• 2014年：「Microservices」
»2011年：先端的なウェブサービス企業が似たようなアーキテクチ
ャスタイルを取っていることが議論に
»33rd Degree 2012「Microservices - Java, the Unix Way」
»2014年にmartinfowler.comで記事化
▸9個の特徴をあげて説明（次ページ）
12
参考：http://2012.33degree.org/pdf/JamesLewisMicroServices.pdf
参考：https://martinfowler.com/articles/microservices.html

14. Microservices
Microservicesの特徴
• サービスによるコンポーネント化
• ビジネス視点でのチーム分割
• プロジェクトではなくプロダクト（自ら動かす）
• スマートなエンドポイントと単純なパイプ（API連携）
• 分散ガバナンス（脱標準化）
• 分散データ管理
• インフラの自動化
• 障害のための設計
• 進化的設計
13

15. Microservices
Microservicesは何のためか？
• 目的：サービス全体を止めずに一部を変更する
»前提：それぞれの変更の発生タイミングはバラバラ
• 解決：変更発生単位に”サービス”として分割し、APIで連
携させることで変更時にサービス全体を止めない
14
v1
v2
v1.1
v1
v2
v1.1
v1.2
v1
v2
v1.1
v1.2

16. NoOps
MicroservicesとNoOps
• MicroservicesにNoOpsは織り込み済み
»「運用作業の自動化/ツール化」というのは重要な土台
»「アプリを作る」から「サービスを動かす」へ
• ただ、それをすっ飛ばしている人が多い気がする
»Microservicesというと開発の話だと思う人が多い
• だから、あえての「NoOps」
»全員、Opsに対する意識を変えるべき
15

17. NoOps
NoOpsとは
• 「サービス全体を止めずに一部を変更する」ために、主に
「運用作業の自動化とツール化」を推進すること
»サービスがもたらすビジネス価値を最大化するにはどうするか？
• 「うちはAWSじゃない」「既存のツールが」は思考停止
»逆にAWSだからいい、最新ツールだからいいわけではない
»DevとOpsとかいう立場関係なく真剣に考えるべき
16

18. サービスを管理せよ
17

19. サービスを管理せよ
NoOpsの代表的な取り組み
• 障害からの自動復旧
• ミドルウェアのバージョンアップ自動化
• 日中無停止リリース（アプリとDB）
• 自動的なスケールアウトやスケールアップ
• 夜間バッチサーバ廃止
18

20. NoOpsレベル
この資料の記述レベル
19
Lv 名称 概要
1 全部手動 なにもかも手順書
2 IaaSを手動操作 イメージは作っているが、手動操作
3 サーバ構築の自動化 単体サーバを構築できる自動化
4 継続的デリバリー コードからリリースまでの自動化
5 システム構成の管理 システム構成の構築まで自動化
6 日本の最先端 OSSを改造しながら利用
7 世界の最先端 OSSの開発

21. サービスを管理せよ
アプリとインフラを一体で管理する
• 「インフラを用意して、アプリをインストールする」
»インフラにはミドルウェアやネットワーク設定などが含まれる
»インフラのバージョン管理とアプリのバージョン管理が分離
• そうではなくて「サービスとして管理」する
»案①：PaaSを使う
»案②：コンテナを使う
20

22. サービスを管理せよ
案①：PaaSを使う
• マネージドインフラ＆ミドルウェアを利用する
»そもそも耐障害性や無停止リリース機能を持ったPaaSを利用する
▸サーバレス：AWS Lambda、Azure Functions
▸アプリケーションサービス：AWS Elastic Beanstalk、Azure App Service
▸データベース：AWS RDS、Azure SQL Database
»すごく便利。ただし、PaaSの制約に従う必要がある
▸実現できることと制約が比例するので注意
21

23. サービスを管理せよ
案②：コンテナを使う
• Dockerなど
»ネットワーク/ミドルウェアもふくめた構成のバージョン管理
»ミドルウェアなどに、ほぼ制約なし
»コンテナ対応PaaSを利用すると便利
22
OS
アプリケーション
ネットワーク構成
ミドルウェア設定
git
ネットワーク設定
ミドルウェア設定
OS
アプリケーションgit

24. サービスを管理せよ
発想の転換：動かすときにインフラ調達
• 「インフラを用意してアプリを置く」ではなく「アプリを
動かそうとするときにインフラを調達する」
»PaaSであればインフラがプールされており起動が早い
23
インフラ
サービスアプリ
①
② ③
インフラ
サービスアプリ
②
① ②

25. バッチ
サーバ
バッチ
サーバ
サービスを管理せよ
バッチサーバはいらない
• バッチジョブを起動するタイミングでインフラ調達
»バッチジョブ単位でスケール設計が可能
»一次的にDBをスケールアップできるサービスもある
»PaaSもあり、コンテナもあり
24
バッチ
サーバ
ジョブ ジョブジョブ
ジョブ
ジョブジョブ
バッチ
サーバ
バッチ
サーバ
バッチ
サーバ

26. ありがちな課題の解決
25

27. http://s1.hoge.com
サーバ
ありがちな課題の解決
固定IP/ドメイン前提
• 固定的なIPやドメインがあると重複起動できない
»IPやドメインは動的にする
• 起動タイミングで必要なサービスに登録しに行く
»さらに進むとサービスレポジトリになる
26
監視
サービス
設定：
http://s1.hoge.com
http://012.hoge.com
サーバ
監視
サービス
設定：
http://012.hoge.com
①
②
①
②
③

28. ありがちな課題の解決
エージェントが必要
• 監視やジョブ管理にエージェントが必要
»台数で課金、インストール時に固定ドメインが必要
• エージェントが不要なサービスにしていく
»スケジューラー用エージェントは不要になるはず
»監視は外形監視できるようにする
»今後は、こういったケースで利用できるエージェントも増える
27

29. ありがちな課題の解決
設定ファイルで環境切り替え
• デプロイされる環境が多すぎで設定ファイルが複雑化
• ネットワーク越しに設定をロードする
28
設定
レポジトリ
aaa:123
①
②
aaa:123
アプリ
本番
aaa:123
開発1
aaa:123
開発2
aaa:123
インフラ
サービス
インフラ
サービス
①
②
本番
aaa:123

30. ありがちな課題の解決
データベース関連が手動 1/2
• リリース時にDBへの変更作業が手動
• DBへの変更作業もバージョン管理しアプリと同期
»DB構成の変更クエリをバージョン管理
29参考：https://flywaydb.org/getstarted/how

31. ありがちな課題の解決
データベース関連が手動 2/2
• 後方互換性を維持しながら変更する
»カラム名の変更
▸Step1：新しいカラム名でカラム追加
▸Step2：古いカラムを読み、両方のカラムに書くアプリ
▸Step3：新しいカラムを読み、両方のカラムに書くアプリ
▸Step4：新しいカラムを読み、新しいカラムに書くアプリ
▸Step5：古いカラムを削除
30

32. さらに、その先へ
進化は続いている
• コンテナオーケストレーション＆サービスメッシュ
»KubernetesやIstio
»システム構成全体を管理する
• イベントソーシング
»CQRS
»データベーススキーマの共有を避け、変更のイベントを共有する
31

33. まとめ
32

34. まとめ
NoOpsとは
• 「サービス全体を止めずに一部を変更する」ために、主に
「運用作業の自動化とツール化」を推進すること
»その自動化とツール化を担当するのはDevOpsエンジニア/SRE
• 開発者にとって「作る」から「作って動かす」へ
»運用担当者への引継ぎを不要にする
33

35. まとめ
サービスを管理する
• 「アプリをデプロイするときにインフラを調達する」
»だから、必要なインフラを調達すればいい
»バッチサーバは不要になる
• 進め方
»案①PaaS：とても便利だし早いが制約も大きい
»案②コンテナ：ネットワークやミドルウェア構成もアプリと一緒
にバージョン管理する。制約は少ない
34

36. まとめ
課題を解決する
• 既存の考え方では合わないことは多い
»固定IP/ドメイン、エージェント、設定ファイル、DBマイグレ…
»やりようはあるので取り組んでいく
• さらに、その先へ
»どんどんとツール化は進んでいる
35

37. まとめ
思考停止反対
• DevとかOpsとか関係なく最適解を探すべき
»どうしたら素早くサービスがリリースできるのか？
»どうしたらめんどうな運用作業をなくしていけるのか？
• クラウド使っていればいいわけでもない
»ただのIaaSでは意味なし。必ずシフトを伴う
»逆にクラウドじゃなくてもできる
36