DevOps導入指南～基本編～

DevOps導入指南
~基本編~
1
(C) Recruit Technologies Co.,Ltd. All rights reserved.
ITエンジニアリング本部
プロダクティビティエンジニアリング部
クラウドアーキテクトG
藤原涼馬

View Slide

講師紹介 (藤原涼馬)
藤原涼馬
株式会社リクルートテクノロジーズ
ITｴﾝｼﾞﾆｱﾘﾝｸﾞ本部
ﾌﾟﾛﾀﾞｸﾃｨﾋﾞﾃｨｴﾝｼﾞﾆｱﾘﾝｸﾞ部
ｸﾗｳﾄﾞｱｰｷﾃｸﾄG 所属
経歴
2011-2015 ユーザ系SIer にてR&D
2016/1〜リクルートテクノロジーズに入社
主な活動(社外含む)
• コンテナ・クラウド等の先進アーキテクチャの事業への装着
• Rancher JPコアメンバー
• Japan Container Days v18.12スピーカー
• Cloud Native Days Tokyo スピーカー(予定)
• 各種勉強会登壇 (Rancher JP meetup, Docker meetup tokyo)
• 寄稿
• @IT 先行事例に学ぶKubernetes 企業活用の現実, コンテナベースのCI/CD本番事例大解剖
• ThinkIt マルチクラウド時代の最強コンビ RancherによるKubernetes活用ガイド
2

View Slide

講師紹介(伊藤瑛)
伊藤瑛
ITｴﾝｼﾞﾆｱﾘﾝｸﾞ本部ﾌﾟﾛﾀﾞｸﾄｴﾝｼﾞﾆｱﾘﾝｸﾞ部
アプリケーションソリューションG
経歴
2015年入社
主な活動
• フロントエンド・サーバサイドの先進テクノロジ装着
• アプリケーションアーキテクティング
3

View Slide

講師紹介(宮地克弥)
宮地克弥
経歴
2017年入社
主な活動
• クラウド等先進アーキテクチャの事業への装着
• 社内ISUCON, 勉強会運営コアメンバー
4

View Slide

講師紹介(與那城有)
與那城有
経歴
2016年入社
主な活動
• クラウド等先進アーキテクチャの事業への装着
• 社内ISUCON
5

View Slide

アジェンダ
DevOpsって何?
DevOpsの歴史
DevOpsとは
DevOpsの確立に必要なテクノロジー
DevOpsの確立に必要な文化
6

View Slide

DevOpsって何?
システムの開発組織(以降Dev)
と
運用組織(以降Ops)
で対立し合うのではなく、
強調(場合によっては融合)しながらビジネス目的を
達成するための考え方、組織的な文化
7
Dev
Ops
Dev Ops

View Slide

DevOpsって美味しいの？どんか効果があるの?
DevOpsを実践できている企業の業績
vs
DevOpsを実践できていない企業
8
コードのデプロイ頻度
(= 仮説検証の頻度)
46倍
コードをコミットしてから
本番デプロイまでのリードタイム
1/1440
障害からの
平均復旧時間
1/170 変更失敗率 1/5
DevOpsとLeanの科学から抜粋

View Slide

DevOpsを実践できると
DevOpsを実践できている企業とそうでない企業では以下
のような観点で
有意な差があった
1. 商品やサービスの量
2. 作業効率
3. 顧客満足度
4. 製品やサービスの質
5. 組織や任務の目標達成度
9

View Slide

DevOpsの歴史と整理
本格的に語られるようになったのは、
写真共有サービスのflickrがVelocityというイベントの発表以降
10
https://www.slideshare.net/jallspaw/10-deploys-per-day-
dev-and-ops-cooperation-at-flickr

View Slide

課題
DevとOpsは仲が悪い
• Devの言い分
• 「俺のコードが動かないのはOpsの準備した環境の品質が低いからだ」
• Opsの言い分
• 「障害が発生するのは、Devの作成したコードの品質が低いからだ」
11
Dev
Ops

View Slide

なぜDevとOpsの軋轢があるのか
DevとOpsでは求められているミッションが異なるため
• Devのミッション
• 新しい機能を追加してビジネス全体の売り上げを伸ばす
• どんどん変更を加えたい
• Opsのミッション
• システムの安定稼働を実現してビジネス全体の売上の逸失を避ける
• 変更は障害の原因になりがちなので避けたい
12

View Slide

本来はどうあるべきか
DevもOpsも根っこの目的は同じ
13

View Slide

14
カスタマー&クライアントへの貢献
とそこからもたらされる
ビジネスの成功と利益の拡大

View Slide

DevとOpsが協力しあえるようにするには？
• (アイデア) DevとOpsを混ぜてしまえば良いのでは？
• 短期的には
イエス
• リリース初期においては自身のプロダクトの品質などを知る意味でも
運用すべき
• 中長期的には
ノー
• 人のスキルには向き不向きがある
• 攻め(Dev)に強い人、守り(Ops)に強い人というのは明らかに存在す
る
• 角を矯めて牛を殺すといった事態は避けたい
15

View Slide

2つの要素が必要
① 組織としての文化
② 文化を支えるテクノロジー
16

View Slide

17

View Slide

18
説明しやすい方から解説

View Slide

DevOpsにおけるテクノロジーの立ち位置
あくまでも必要なのは組織としての文化であって、テクノ
ロジーはその実現を支援するための仕組み
ただし、テクノロジーがなければ全員がスー
パーマンでなければならない。それは現実的ては
ないのでテクノロジーの力を借りる
19
現実としてありえない組織現実の組織
(スーパーマンはほとんどいない)

View Slide

DepOps文化の確立を支援するテクノロジー
DevOps文化の確立を支援するテクノロジーとして大きく6
つがあると言われている
1. 自動化されたインフラ
2. 共有されたバージョンコントロール
3. ワンステップビルドとデプロイ
4. フィーチャーフラグ
5. 共有されたメトリクス
6. チャットとチャットボット
20

View Slide

21

View Slide

• コードから自動的に環境を構築できるような仕組みを実
現できていること
22

View Slide

なぜ自動化されたインフラが必要か
100台の仮想マシンを手動で構築することを考える
これは効率的に作業をしていると言えるか。
確実に誤りなく実行できるか?
23

View Slide

なぜ自動化されたインフラが必要か(1)
100台の仮想マシンを手動で構築することを考える
これは効率的に作業をしていると言えるか。
確実に誤りなく実行できるか?
24
ムリ

View Slide

• 人間が作業をするので手順書ベースの作業である
• 手順書が正しくても失敗は排除できない
• 人間はミスをする生き物である
• しかもミスの仕方は予想がつかない
25

View Slide

26
生身の人間の作業は再現性が低い

View Slide

27
では、計算機にさせるとどうなる？

View Slide

• 計算機は言われた通りのことを何百万回でも集中力を切
らすことなく正確に実行できる
• つまり確実成功 or 失敗※
• 人間のように疲れることは(ほぼ)ない
• ちゃんと設定すれば寝落ちもしない
28
※ 一番厄介なのはうまくいったものと
失敗したものが混ざっている状態です(経験上)

View Slide

なぜ自動化されたインフラが必要か(まとめ)
• 大量の繰り返しは比較的苦手※
• 入力と出力が1対1になりづらい
• 計算機は繰り返し作業が得意
• 何万回の繰り返し作業でも平気
• 入力と出力が1対1になりやすい
• ほぼ、書いたようにしか動かない
29
※特殊な訓練を受けた人は除きます

View Slide

なぜ自動化されたインフラが必要か(まとめ)
• 大量の繰り返しは比較的苦手※
• 入力と出力が1対1になりづらい
• 計算機は繰り返し作業が得意
• 何万回の繰り返し作業でも平気
• 入力と出力が1対1になりやすい
• ほぼ、書いたようにしか動かない
30
※特殊な訓練を受けた人は除きます
適材適所を適切に行うべき
つまり、繰り返し作業は計算機に行わせるべき

View Slide

31

View Slide

• アプリケーションコード・インフラコードは両方とも
コードリポジトリで管理すること
32

View Slide

• アプリケーションコード・インフラコードは両方とも
コードリポジトリで管理すること
• アプリケーションコード
• アプリケーションロジックなどのコード
• インフラコード
• AnsibleのplaybookやDockerfile, Kubernetesのマニフェストなど
33

View Slide

なぜ共有されたバージョンコントロールが必要か？
• 環境にデプロイされているアプリケーションや構成とし
て何が正なのか事実なのかを明確にするため
34

View Slide

共有されたバージョンコントロールがない状況を考える
この状況で障害が起きた場合に適切な対応が可能か？
35
Aさん Bさん
Cさん Dさん
全員持っているコードはばらばら
古かったり新しかったり

View Slide

36
Aさん Bさん
Cさん Dさん

View Slide

37
Aさん Bさん
Cさん Dさん
＿人人人人人人人人＿
＞約束された死＜
￣Y^Y^Y^Y^Y^Y^Y ￣

View Slide

共有されたバージョンコントロールがあれば
きちんと交通整理ができる
38
Git
リポジトリ
変更内容
を集約
デプロイ

View Slide

[補足]インフラコードもリポジトリで管理する
1.自動化されたインフラでも述べている通りインフラはコー
ドで記述し、共有されたバージョンコントロールに載せる
(仮に手順書ベースとしても、リポジトリまたは文書基盤(Confluence)を通じてそれはDevと共有される)
39
Git
リポジトリ
Ops
Dev
Dev と Ops がバージョンコントロールを
介して何をやっているか見えるようにする
(もちろんJIRAなどのチケット管理システムでも互いに見えるようにする)

View Slide

40
Git
リポジトリ
Ops
Dev
別の共有
されていない
何か
あいつら
何やってんの？(怒)
Devには
関係ない話だから
こっちのやり方で
やる

View Slide

41
Git
リポジトリ
Ops
Dev
情報が共有されないとヘイトが溜まりがち
(互いに必要とする情報なんてわからないので勝手に判断しない)
別の共有
されていない
何か
あいつら
何やってんの？(怒)
Devには
関係ない話だから
こっちのやり方で
やる

View Slide

42
Git
リポジトリ
Ops
Dev
作ったものは必ず共有できるところに置く

View Slide

アプリケーションのビルドとデプロイについてツールを活
用して
”可能な限りシンプルなプロセス”
で自動実行できるようにすること
43

View Slide

44

View Slide

ワンステップビルドとデプロイ
なぜ必要か？
1. 非難のない文化を作ることを助ける
2. 事業の継続性を確保する
45

View Slide

非難のない文化を作ることを助ける
人間はミスをするので、計算機に仕事をさせる。
計算機に入れる入力(ビルド、デプロイのパイプライン)はD
複数人以上で確認する(できればDevとOpsまたがる形で)
46
Dev Ops
①パイプラインを
レビューする
②パイプラインを
デプロイする
③デプロイ作業を
実施する
④成否の振り返り
と確認
Ops Dev

View Slide

非難のない文化を作ることを助ける
人間はミスをするので、計算機に仕事をさせる。
計算機に入れる入力(ビルド、デプロイのパイプライン)はD
複数人以上で確認する(できればDevとOpsまたがる形で)
47
Dev Ops
①パイプラインを
レビューする
②パイプラインを
デプロイする
③デプロイ作業を
実施する
④成否の振り返り
と確認
Ops Dev
人間が細々とした作業をデプロイ時にしないので、
問題が起きても冷静かつ建設的な議論がしやすい傾向
(コード通りにデプロイは行われていることが確証できるのが大きい)

View Slide

なぜ必要か？
1. 非難のない文化を作ることを助ける
2. 事業の継続性を確保する
48

View Slide

ワンステップビルドとデプロイがない場合(1/2)
ワンステップビルドとデプロイがない場合
49
今日はリリース作業ですね
いつも作業担当してる
Bさんが体調不良で
お休みなんですよね
Aさん
まじ?手順書はあるよね?
ありますね
Aさん

View Slide

50
じゃあ、それでよろしく
はい(…大丈夫かなぁ)
Aさん
Aさん
手順書通りにやったけど
ダメだったわ
(暗黙的な手順があるんやろなぁ)
ふぁ〜〜〜

View Slide

51
じゃあ、それでよろしく
はい(…大丈夫かなぁ)
Aさん
Aさん
手順書通りにやったけど
ダメだったわ
ふぁ〜〜〜
ありがち

View Slide

ワンスレップビルドとデプロイがある場合
ワンステップビルドとデプロイがある場合
52
今日はリリース作業ですね
ですね。デプロイボタン押します
(Bさんいないけど自動化されてるのでやれる)
できた
Aさん
うぇーい

View Slide

事業の継続性を確保する
ビルド・デプロイプロセスをシンプルに保ちつつ、
自動化することで事業の継続性を確保しやすくなる
(もちろん限界はある)
53

View Slide

54

View Slide

フィーチャーフラグとは
特定の機能を有効化したり一部の人にのみ提供するための
フラグ。これを提供することで下記を実現できるようにす
る。
• プライベートベータ
• 一部の”指定したユーザにのみ”機能を公開する
• A/Bテスト
• 比率を定めて機能や新UIを公開し、反響を調べる
• ダークローンチ(後ほど補足)
• ユーザのリクエストを複製して擬似的に処理を行う
55

View Slide

リクルートでよく用いる手法
フィーチャーフラグとは
特定の機能を有効化したり一部の人にのみ提供するための
フラグ。これを提供することで下記を実現できるようにす
る。
• プライベートベータ
• 一部の”指定したユーザにのみ”機能を公開する
• A/Bテスト
• 比率を定めて機能や新UIを公開し、反響を調べる
• ダークローンチ(後ほど補足)
• ユーザのリクエストを複製して擬似的に処理を行う
56

View Slide

[補足解説] ダークローンチ
ユーザのリクエストを複製して擬似的に処理を行う
57
プロキシ
的な何か
既存機能
ダークローンチ対象
① ②
②
③
③
④
① ユーザがリクエストを行う

View Slide

58
プロキシ
的な何か
既存機能
①
②
②
③
③
④
② 既存機能とダークローンチ対象の両方に
リクエストを送る

View Slide

59
プロキシ
的な何か
既存機能
①
②
②
③
③
④
③ 既存機能からのレスポンスをユーザに返す

View Slide

60
プロキシ
的な何か
既存機能
①
②
②
③
③
④
④ ダークローンチ対象からのレスポンスを破棄する

View Slide

61
プロキシ
的な何か
既存機能
①
②
②
③
③
④
新機能が他の機能の挙動に悪影響を与えていないか、
既存機能との性能差異などを確認する

View Slide

フィーチャーフラグがない場合
小さく試して、小さく失敗が
できなくなる
62
うぉぉぉお、
サービス保ってくれ
いきなり100%適用だ!
いきなり大規模適用
大惨事

View Slide

フィーチャーフラグがある場合
できる
63
小さく始める
まずは全体の10%
からやっていこうか
失敗
成功
スコープを広げる
次は50%いこうか
傷が浅くて
よかったね
振り返って
次の施策を
考えましょ
冷静に振り返って
次に繋げる

View Slide

フィーチャーフラグがある場合
できる
64
小さく始める
まずは全体の10%
からやっていこうか
失敗
成功
スコープを広げる
次は50%いこうか
傷が浅くて
よかったね
振り返って
次の施策を
考えましょ
冷静に振り返って
次に繋げる
被害が小さいので冷静に振り返りができる

View Slide

65

View Slide

よくある話
DevとOpsで違う指標を見ている
66
Dev Ops
Watch Watch
課題があるﾅﾆｿﾚ!?

View Slide

よくある話
DevとOpsで違う指標を見ている
67
Dev Ops
Watch Watch
課題があるﾅﾆｿﾚ!?
ミスコミュニケーションが
起きるに決まっている

View Slide

DevとOpsで
同じ情報ソースを使ってコミュニケーションをとる
互いのノウハウは集約
68
Ops
Dev
集約 or 並存
は要議論
Dev視点の
メトリクス
Ops視点の
メトリクス

View Slide

DevとOpsで
69
Ops
Dev
同じ情報を見て議論できるので
ミスコミュニケーションは減る
集約 or 並存
は要議論
Dev視点の
メトリクス
Ops視点の
メトリクス

View Slide

70

View Slide

早い話がチャット基盤とチャットボットを積極的に使いましょ
CIの結果通知やビジネス上の実績などをチャットボットを
使ってチャット基盤に流しましょう
71

View Slide

早い話がチャット基盤とチャットボットを積極的に使いましょ
CIの結果通知やビジネス上の実績などをチャットボットを
使ってチャット基盤に流しましょう
72
メールではダメか？

View Slide

メールでも絶対にダメなわけではない
なぜメールだと難しいか
1. そもそもボットを導入するのが難しい
2. 高頻度・低レイテンシのコミュニケーションが難しい
(メールには即時の到達性の保証がない)
73
非同期
コミュニケーション
同期
コミュニケーション
メールチャット対面ミーティング
電話

View Slide

まとめ
6つの要素をざっくりと分類する
74

View Slide

DepOps文化の確立を支援するテクノロジーまとめ
75
安全に仮説検証する仕組み作り
属人性の軽減・排除
コミュニケーションの円滑化
自動化されたインフラ
共有されたバージョンコントロール
フィーチャーフラグ
共有されたメトリクス

View Slide

DepOps文化の確立を支援するテクノロジーまとめ
76
安全に仮説検証する仕組み作り
属人性の軽減・排除
コミュニケーションの円滑化
自動化されたインフラ
共有されたバージョンコントロール
フィーチャーフラグ
DevとOpsが適切にコミュニケーションしつつ、
互いのヘイトを溜めない仕組みづくりが重要
結果互いの強みを組み合わせてシナジー効果を出す

View Slide

77
ある意味本題

View Slide

DevOpsはなぜ組織文化と関連するのか
共通の目的(ビジネスの成功と利益の拡大)を実現するとい
うことに注力するには、結局のところ人と人が円滑に協力
しあえる意識を持つ必要がある。
これはすごく難しい。
一時的にはできても維持することは大変。
78

View Slide

DevOpsの確立に必要な組織文化
1. リスペクトしあうこと
2. 互いに信頼すること
3. 失敗に対して健全な態度をとること
4. 個人を非難しないこと
79

View Slide

80
もちろんこれは、DevおよびOpsそれぞれの
構成メンバーが、責任を持って全力を尽くすことが前提
&
後段の文化は前段を前提とする
(例えば2は1を前提とする)

View Slide

81

View Slide

• 先入観を持たない
• 他人の専門知識・意見・責任を尊重する
• ノーというだけのことはしない
• 隠し事はしない
• 依頼する前にやる事・考える事をちゃんとやる
82

View Slide

先入観を持たない
• いつもxxxなのでyyyしようはNG
• 時間が経てば人の中身は変わる & 状況も変わる
• 人の中身が変わらないというのはその人の成長の可能性を信頼し
ていない
• 簡単でも良いのできちんと確認する
• チャットでもなんでも良いので確認する
• そのためにコミュニケーション基盤(Slack, JIRA/Confluence)が
整備されている
83

View Slide

他人の専門知識・意見・責任を尊重する
• いくら優秀でも全てにおいて優っていることはない
• 他人は異なる視点を持っているので
• 他人の専門領域
• 他人の抱えている役割
• 上記2つをベースとして意見は尊重すること
84

View Slide

85
ただし、Whyを深掘りして尋ねるのはOK
(むしろ互いのレベルアップのためにどんどんすべき)

View Slide

86
ただし、Whyを深掘りして尋ねるのはOK
他人の意見を聞いて、施作を磨き込んで
成果が上がったならその成果はあなたの成果

View Slide

ノーというだけはしない
特にOps側が依頼を受ける際に求められる姿勢
• 拒否する際には客観的な理由を示すこと
• 理由なく拒否されれば納得しない
• どうすれば許容されるのかを示すこと
• ただ拒否するだけではなく、どうすれば依頼に応えられるかを返
すこと
• 拒否する際には依頼に対するWhyも掘り下げること
• 掘り下げる中で真の目的を達成する他の方法が提案できるかもし
れない
87
協力の姿勢を崩さないこと
(最終目的はDevもOpsも同じ)

View Slide

隠し事はしない
• どうせバレる。バレた時に失われる信頼を考えると初め
から伝えておいた方が良い
• ヤバいことほど積極的に伝える
• もちろん聞く側はそれを冷静に受け止めてどうするかを一緒に考
えること
88

View Slide

(DevはOpsに)依頼する前にやれる事をきちんとやっておく事
• きちんとできることはやり尽くした上で依頼する
• 依頼する際にやっておくべきこと
1. 何を変更するか
2. 変更に伴うリスク
3. 変更の成功・失敗の判断基準と連絡方法
4. 失敗時の対応方針
89
1, 2 は必須(もちろんOpsに意見を求めるのはWelcome)
3,4は意見を出し合ってすり合わせ

View Slide

90

View Slide

2. 信頼すること
信頼関係を確立できていない状態では健全な関係は作れな
い
91
(大前提)
DevもOpsもプロフェッショナルとして
自身の仕事に対して最善を尽くしていること

View Slide

2. 信頼関係を気づく上で重要なこと
1. Opsは新機能について議論する際はDevを信頼すること
2. Devはインフラ構成の変更についてはOpsを信頼すること
3. Opsは透明性を以って運用を行い、Devに最大限のアクセ
ス権限を渡すこと
92

View Slide

93
互いにそれぞれの専門領域において
リスペクトしあうこと
Devでもできる事を無理にOpsがする必要はない

View Slide

94
互いにそれぞれの専門領域において
リスペクトしあうこと
Devでもできる事を無理にOpsがする必要はない
DevとOpsは互いに補完しあう関係であり、
互いの長所を活かしあう仕組みにしない生き残れない

View Slide

95

View Slide

3. 失敗に対する健全な態度
• 失敗は“必ず起きる”ものだという意識を持つ事
• 失敗の確率を下げるために”経済的・工数的に合理的な範囲”で
最善を作ることはもちろん必要
• 失敗を回避する事を考え続けている限り、失敗に対応す
る能力は向上しない
• 失敗が起きても大丈夫 or 迅速に復旧できる仕組みを準備してお
くこと
96
きかんしゃトーマスの
「じこはおこるさ」
の精神を持つ

View Slide

3. 失敗に対する健全な態度
• 失敗は“必ず起きる”ものだという意識を持つ事
• 失敗の確率を下げるために”経済的・工数的に合理的な範囲”で
最善を作ることはもちろん必要
• 失敗を回避する事を考え続けている限り、失敗に対応す
る能力は向上しない
• 失敗が起きても大丈夫 or 迅速に復旧できる仕組みを準備してお
くこと
97
きかんしゃトーマスの
「じこはおこるさ」
の精神を持つ

View Slide

4. 非難しない
• 失敗が起きた時に原因を”特定の人”に求めない
• 萎縮効果でその人のパフォーマンスを低下させる
• 自分が失敗した時に跳ね返ってくる
98
失敗は必ず起きるので、
“仕組みとしてどう軽減・回避するか”
を対策として考えた方が良い

View Slide

DevOpsの確立に必要な組織文化まとめ
• 目的の達成のために協力しあうこと
• 互いが能力を最大限発揮できるようにすること
• 個人の能力ではなく仕組みで課題には対処すること
• 特定個人の能力にチーム全体が縛られない仕組みを作ること
99

View Slide

DevOps導入指南
~技術編~
100
ITエンジニアリング本部
プロダクティビティエンジニアリング部
クラウドアーキテクトG
藤原涼馬

View Slide

目的
• CI/CDやモニタリングダッシュボード
• AnsibleやTerraform、Docker、Kubernetes
• 12 Factor Apps
などの考え方について、DevOpsとの関連を交えて解説
101

View Slide

CI/CDとはなんぞや？
• CI
• 継続的インテグレーション, Continuous Integration
• CD
1. 継続的デプロイ, Continuous Deploy
2. 継続的デリバリ, Continuous Delivery
102

View Slide

CI/CDとはなんぞや CIとは
CIとは、共有されたバージョンコントロール(以下、gitリ
ポジトリ)にコミットされたコードに対して以下を行うこと
1. 自動ビルド
2. 自動テスト
103
https://aws.amazon.com/jp/devops/continuous-integration/ から引用

View Slide

なぜCIが必要か？
104

View Slide

なぜCIが必要か
• 常に同じ手順でビルドとテストを繰り返し行えるように
するため
105

View Slide

なぜCIが必要か
• 常に同じ手順でビルドとテストを繰り返し行えるように
するため
106
人間は繰り返し作業が苦手なので、
繰り返し作業が得意な計算機に任せる

View Slide

よくある反論(1)
CIがしょっちゅう壊れるのでその修正コストが高い
107
壊れやすいCIやCIを壊しやすいアプリケーションになっている
ことに問題があるのでそもそもの見直しが必要
(最後はコストとの兼ね合いだが)

View Slide

開発スピードを重視したいのでテストを書くのは嫌だ
108
君はいなくなるだろうからいいけど、
残された人間はテストのないコードをみてどう思うだろうか？

View Slide

既存コードにテストがない
109

View Slide

110

View Slide

111
少しづつテストを追加していき、コードの肥大化に
伴う開発スピードの低下に備える必要がある
(テストのないコードにテストを追加する場合の参考例)
外部に依存したコードをテストで駆動する by 和田卓人
https://speakerdeck.com/twada/test-driven-architecture-aws-dev-day-tokyo-2018

View Slide

不具合は混入してからの時間経過が長くなるほど対応コス
トは増大する
112
大量に不具合を溜め込んでから
一括で解決するよりも
つどつど検知&解消を
測った方が最終的な
総コストは下がる

View Slide

CI/CDとはなんぞや CDとは
CDでは、コード変更に伴って自動的に実稼働環境へのリ
リース準備が実行される
1. 継続的デリバリ
– リリースに際して人による承認が必要
2. 継続的デプロイ
– リリースまで自動的に行われる
113
https://aws.amazon.com/jp/devops/continuous-integration/ から引用

View Slide

CDの重要なポイント
継続的デリバリ/デプロイ共に、
程度の差こそあれ”自動”リリースであること
114

View Slide

ダブルチェックで頑張る vs デプロイのコード化
115
手動作業 + ダブルチェックデプロイのコード化
• 初期コストは低い
• デプロイ頻度と人的コストが
比例するのでその点は注意
• 再現性が低い
• 人間の注意力に起因する失敗
の再現性は低い
• 改善が困難
• 属人性が高いことに起因
• 初期コストが高い
• デプロイ作業をコードに落と
すので初期コストは高くなり
がち
• 再現性が高い
• 計算機が実行するので書いた
ようにしか動かない
• 改善が容易
• 問題があればコードを直す
• 人間だったら……?

View Slide

ダブルチェックで頑張る vs デプロイのコード化
116
手動作業 + ダブルチェックデプロイのコード化
• 初期コストは低い
• デプロイ頻度と人的コストが
比例するのでその点は注意
• 人間の注意力に起因する失敗
の再現性は低い
• 改善が困難
• 属人性が高いことに起因
• 初期コストが高い
• デプロイ作業をコードに落と
すので初期コストは高くなり
がち
• 再現性が高い
• 計算機が実行するので書いた
ようにしか動かない
• 改善が容易
• 問題があればコードを直す
• 人間だったら……?

View Slide

デプロイのコード化に際して考えること
1.デプロイ頻度
2.手順の複雑さ
117
デプロイ頻度が高い、かつデプロイ手順
が複雑なものから手をつける

View Slide

CIとCDを支える技術
118

View Slide

CIと支える技術と考え方
119

View Slide

CIを支える技術
CIを支える様々なツールがある(主観による雑な分類です)
120
CIパイプラインツール
ビルドの支援ツール（パッケージ管理ツール含む）
テストの支援ツール
GNU make
go test
python -m unittest

View Slide

121
GNU make
go test
python -m unittest
ビルドとテストの全体フローを自動化する

View Slide

122
GNU make
go test
python -m unittest
(主にアプリケーションの)ビルドフローを自動化する

View Slide

123
GNU make
go test
python -m unittest
テストフローを自動化する

View Slide

124
GNU make
go test
python -m unittest
テストフローを自動化する
アプリケーションロジック記述以外から
属人性を可能な限り排除するのが目的

View Slide

こういう状況を排除する
125
さん以外、ビルドとテストの
方法知らない。困った……
(しかも彼は先月退職した)
レビューの前にテストをパスする必要がある!?
しかも結果のエビデンスもセット!?
テストケースは500ケースで全部手動！？
そんなん発狂するわ

View Slide

CIでパイプライン化されていれば
126
さんいないけど、テストは実行できる
テストのやり方もパイプラインのコードを直せばOK
500ケースのテスト結果も
プルリクみればいいから楽

View Slide

CIでよくある問題
• テストが安定しない
• テストの実行時間が長い
127

View Slide

テストが安定しない
• 過去のビルドにおける副生成物・副作用によってテスト
が安定しない(放置された中間ファイルやDBの状態などに起因)
128

View Slide

129
ビルドの独立性を高め、環境依存性を
下げることを考える

View Slide

130
ビルドの独立性を高め、環境依存性を
下げることを考える
例えば、CIではDockerを使って
ビルド・テストを実行する。DBも都度作る

View Slide

テストの実行時間が長い
• テストサイズの概念を使って効率的にテストをする
• テストがこける原因の8割くらいはしょうもないことが原因
• Lintやネットワーク通信の発生しないテストで洗い出せる
131
Feature Small Medium Large
Network access No localhost only Yes
Database No Yes Yes
File system access No Yes Yes
Use external systems No Discouraged Yes
Multiple threads No Yes Yes
Sleep statements No Yes Yes
System properties No Yes Yes
Time limit (seconds) 60 300 900+
https://testing.googleblog.com/2010/12/test-sizes.html

View Slide

テストサイズの概念に合わせたCIパイプライン実装
132
テスト
実行の
トリガー
medium
テスト1
medium
テスト2
medium
テスト3
medium
テスト
結果通知
イメージ
のビルド
& small
テスト
イメージ
のpush
medium
依存
モジュール
build
8割は
smallテスト
で落とす
残りのうちの
8割はmediumテスト
で落とす

View Slide

テストサイズの概念に合わせたCIパイプライン実装
133
テスト
実行の
トリガー
medium
テスト1
medium
テスト2
medium
テスト3
medium
テスト
結果通知
イメージ
のビルド
& small
テスト
イメージ
のpush
medium
依存
モジュール
build
8割は
smallテスト
で落とす
残りのうちの
8割はmediumテスト
で落とす
CIのパフォーマンスを改善することで
コードを書いてからフィードバックを
受けるまでの時間を短くする

View Slide

• 対策
• ビルドの独立性をあげる
• 対策
• CIのパフォーマンスを改善する
• テストサイズの概念を導入したCIパイプライン構成
134

View Slide

• 対策
• ビルドの独立性をあげる
• 対策
• CIのパフォーマンスを改善する
• テストサイズの概念を導入したCIパイプライン構成
135
参考
• Kubernetes、コンテナ技術を活用した開発アジリティー向上にインフラアーキテクトはどう貢献したのか
• https://www.atmarkit.co.jp/ait/articles/1902/18/news013.html
• コンテナベースの継続的インテグレーションの利点／課題と、CIパイプライン、Docker Build高速化のコツ
• https://www.atmarkit.co.jp/ait/articles/1903/19/news007.html

View Slide

アプリケーション
構成管理
VM構成管理
環境構成管理
CDを支える技術
CDももちろんそれを支える技術が存在する
(CIとかぶる部分も多々ある & 雑分類なので注意)
136
デプロイツール
構成管理

View Slide

CDがない場合
137
手順書に従ってさんがやった時と
同じ手順でデプロイしたのに上手くいかない
デプロイの手順でステップが50ある!?
間違えずになんてできるか〜！
本当に同じ手順だったのか……?
(調べられるけど高コスト)
無理。
(少なくとも講師の私は)

View Slide

CDがない場合
138
手順書に従ってさんがやった時と
同じ手順でデプロイしたのに上手くいかない
デプロイの手順でステップが50ある!?
間違えずになんてできるか〜！
本当に同じ手順だったのか……?
(調べられるけど高コスト)
無理。
(少なくとも講師の私は)
CDはアプリケーションロジック記述以外から
属人性と不確実性を可能な限り排除する
のが目的

View Slide

CDのよくある問題
どうやってデプロイ品質を磨き込むか?
139

View Slide

CDのよくある問題
どうやってデプロイ品質を磨き込むか?
140
アプリケーションと同様に
開発・ステージング環境を使って磨き込む

View Slide

デプロイ品質の磨き込み
環境構成を可能な限り開発・ステージング・本番で同じものにする※
＆デプロイプロセスを同一にする
141
※ 環境ごとにスケールは異なっても構成要素は同じにするようにしてください
本番にのみ存在するモジュールなどはなくしましょう
開発
ステージング
本番

View Slide

デプロイ品質の磨き込み
環境構成を可能な限り開発・ステージング・本番で同じものにする※
＆
デプロイプロセスを同一にする
142
※ 環境ごとにスケールは異なっても構成要素は同じにするようにしてください
本番にのみ存在するモジュールなどはなくしましょう
Heisei Finalのデプロイパイプラインを
ここにはる(dev-stg-prod)
アプリケーションと同様に
デプロイプロセスの品質向上のための手立てを打つこと

View Slide

CIとCDを支える技術
CIもCDの根本的な目的は主に以下の2つ
1. 人間が苦手なこと(複雑かつ正確性が求められる作業・繰り返し作業)を
計算機に任せる
2. 作業そのものに対する属人性を排除する
結果として高いレートで仮説検証サイクルを回せる
(=ビジネスの成功確率をあげられる)
143

View Slide

CI/CDの注意点
• CIパイプラインの注意点
• 必要に応じてCIパイプラインそのもののチューニングも必要にな
ることを覚悟すること
• CIパイプラインの品質がプロダクトの品質に大きな影響を与える
ことを自覚すること(信用できないCIパイプラインは無視される)
• CDの注意点
• アプリケーションコードと同様に品質の磨き込みが必要であるこ
とに注意すること
• デプロイプロセスの品質が高くない限り高いレートで仮説検証サ
イクルを回すことは難しいという事実を理解すること
144

View Slide

時間が余ったので
THE TWELVE-FACTOR APP
145

View Slide

THE TWELVE-FACTOR APPとは
• セットアップ自動化のために宣言的なフォーマットを使い、プロジェクトに新しく
加わった開発者が要する時間とコストを最小化する。
• 下層のOSへの依存関係を明確化し、実行環境間での移植性を最大化する。
• モダンなクラウドプラットフォーム上へのデプロイに適しており、サーバー管理や
システム管理を不要なものにする。
• 開発環境と本番環境の差異を最小限にし、アジリティを最大化する継続的デプロ
イを可能にする。
• ツール、アーキテクチャ、開発プラクティスを大幅に変更することなくスケールアッ
プできる。
146
https://12factor.net/ja/
下記のようなSoftware as a Service(SaaS)を
作り上げるための方法論

View Slide

The Twelve Factors
I.コードベース
バージョン管理されている1つのコードベースと複
数のデプロイ
II.依存関係
依存関係を明示的に宣言し分離する
III.設定
設定を環境変数に格納する
IV.バックエンドサービス
バックエンドサービスをアタッチされたリソース
として扱う
V.ビルド・リリース・実行
ビルド・リリース・実行の3つのステージを厳密に
分離する
VI.プロセス
アプリケーションを1つもしくは複数のステートレ
スなプロセスとして実行
VII.ポートバインディング
ポートバンディングを通してサービスを公開する
VIII.平行性
プロセスモデルによってスケールアウトする
IX.廃棄容易性
高速な起動とグレースフルシャットダウンで堅牢
性を最大化する
X.開発/本番一致
開発、ステージング、本番環境をできるだけ一致
させた状態を保つ
XI.ログ
ログをイベントストリームとして扱う
XII.管理プロセス
管理タスクを1回限りのプロセスとして実行する

View Slide

The Twelve Factors
数のデプロイ
II.依存関係
III.設定
として扱う
分離する
VI.プロセス
VIII.平行性
IX.廃棄容易性
XI.ログ
現代的なアプリケーションを
作るにあたってDev、Ops関わらず
理解しておくべきプロトコル
くらいに思っておくと良い

View Slide

The Twelve Factors
数のデプロイ
II.依存関係
III.設定
として扱う
分離する
VI.プロセス
VIII.平行性
IX.廃棄容易性
XI.ログ
現代的なアプリケーションを
作るにあたってDev、Ops関わらず
理解しておくべきプロトコル
くらいに思っておくと良い
プロトコル =
組織間コミュニケーションのコストを下げる手段

View Slide

I. コードベース
リポジトリで管理されてないアプリケーションはデプロイ
しない
単一のリポジトリからローカル・開発・ステージング・本
番にデプロイできるようにしておく
150

View Slide

I. コードベース
リポジトリで管理されてないアプリケーションはデプロイ
しない
単一のリポジトリからローカル・開発・ステージング・本
番にデプロイできるようにしておく
151
他の人がコードを確認できないものを
デプロイするのは論外
アプリケーションコードの変更なしに
デプロイできるようにしておく
(デプロイ時にサーバ上でvimやら開いてる = なにかおかしい)

View Slide

II. 依存関係
アプリケーションが動作する上で必要なライブラリなどの
依存関係が明示的に定義されていること。
152
Ruby
Gem → Gemfile
Node.js
→ package.json
Python
Pypi
→ requirements.txt
Java
→ pom.xml
Docker
→ Dockerfile

View Slide

II. 依存関係
アプリケーションが動作する上で必要なライブラリなどの
依存関係が明示的に定義されていること。
153
Ruby
Gem → Gemfile
Node.js
→ package.json
Python
Pypi
→ requirements.txt
Java
→ pom.xml
Docker
→ Dockerfile
ローカル開発の際に追加の手順が発生する場合は
何かしらの問題を抱えていると考えた方が良い
(もちろん言語環境の構築そのものは除く)
e.g. mavenでセットアップした後に何かよくわからないjarファイルを依存関係に入れるなど

View Slide

III. 設定
設定をアプリケーションコードから厳密に分離できるよう
にする
• 単一のコードベースから複数の環境(開発/ステージング/本番)に
デプロイできるようにするため
154
環境変数で設定を読み込み
(環境変数の投入が別途コード化されているとより良い)
設定ファイルを環境ごとに切り替え
(コマンドラインオプションで切り替えられるように作る)
設定ファイルをデプロイ時にサーバ上で書き換え
超えられない壁
Good
No Good

View Slide

IV. バックエンドサービス
アプリケーションがアクセスする先のリソースは場所など
を意識することなくアクセスできるようにすること
アプリケーションコードを変更することなく、接続先のリ
ソースを変更できるようにすること
• 設定変更のみで接続先を変更できるようにする
(本音を言うとDNSなども含めて総合的に対応できるようにしてほしい)
155

View Slide

V. ビルド・リリース・実行
ビルド・リリース・実行の3プロセスを明確に分ける
156
コード
0101110
実行可能な
バイナリ
設定
(ファイル
or 環境変数)
設定
(ファイル
or 環境変数)
0101110
実行可能な
バイナリ
ビルドリリース
実行
不具合検知
or 新機能要求
コード修正
・追加

View Slide

V. ビルド・リリース・実行
ビルド・リリース・実行の3プロセスを明確に分ける
157
コード
0101110
実行可能な
バイナリ
設定
(ファイル
or 環境変数)
設定
(ファイル
or 環境変数)
0101110
実行可能な
バイナリ
ビルドリリース
実行
不具合検知
or 新機能要求
コード修正
・追加
このサイクルが逆に回ること
がないようにする
（問題が起きた場合はサーバ上で対処ではなく、ローカルでコードを修正した上で対処する）

View Slide

VI. プロセス
アプリケーションを1つもしくは複数のステートレスなプロ
セスとして実行する
• アプリケーションプロセスにはステートを持たせない
• ステートを持たせる場合はRedisやMemcached、RDBに
格納する
158

View Slide

VII. ポートバインディング
ポートバインディングを通してサービスを公開する
＝指定されたTCP/UDPポート番号を使ってサービスを公開
する
159

View Slide

VIII. 並行性
スケールアウトはプロセスモデルによって行われること
プロセスがシェアドナッシングかつステートレスであれば
プロセスの増減のみでスケールアウトが実現できる
160

View Slide

IX. 廃棄容易性
1. SIGTERMシグナルを受け取った時にグレースフルに
シャットダウン＊できるようにする
– 停止の際に複雑な手続きが要らないようにする
2. 起動時間を最小化する
– できるだけ短時間(数秒)でリクエストやジョブを受け付けでき
るようにするべき
3. 突然の死に対して堅牢であるべき
161
*新規リクエストの受付を停止し、
処理中のリクエストの処理完了
を待ってからプロセスを停止する

View Slide

X. 開発/本番一致
開発/ステージング/本番をできるだけ一致させた状態を保つ
• 構成要素は揃える
• 本番にしか存在しないコンポーネントがないようにする
• 仮にライセンスなどの都合でそうなっているならそもそも構成を見直すこと
• スケールまで揃えるかは予算と相談
• 負荷試験などの都合上揃えられるようにはしておくべき
• 一致していない部分は容易に確認できるようにしておくべき
• パブリッククラウドであればinternal DNSをうまく活用することで
機能面では全く同じ構成になるようにできる
162

View Slide

XI. ログ
ログはfluentdやlogstashなどのツールを用いて特定の場所
に集約する
163
数十〜数百のサーバー数十〜数百のサーバー
集約
ログの集約をしていない場合ログの集約をしている場合

View Slide

XI. ログ
ログはfluentdやlogstashなどのツールを用いて特定の場所
に集約する
164
数十〜数百のサーバー数十〜数百のサーバー
集約
ログの集約をしていない場合ログの集約をしている場合
全員で同じものを見て議論を
することも容易にする

View Slide

XII. 管理プロセス
管理タスク(DBの設定変更など)を1回限りのプロセスとし
て実行する
例えば、DBのマイグレーションタスクはコードとセットに
なっており、リリース時に実行されるようになっている(ま
たは実行するためのシェルコマンドが準備されている)
165
# python(Django)
$ python manage.py migrate
# Ruby(RoR)
$ rake db:migrate
# go(sqlmigrate)
$ sqlmigrate up
人間はミスをするので可能な限り
SQLをその場で実行するなどの複雑な作業は
させないようにすること

View Slide

まとめ
166

View Slide

vs
167
46倍
1/1440
障害からの
平均復旧時間
1/170 変更失敗率 1/5

View Slide

vs
168
46倍
1/1440
障害からの
平均復旧時間
1/170 変更失敗率 1/5
たくさん打席に立つことが
ヒットをうつ上で重要
安全に失敗しつつ、
確実に成功に繋げられるようにする

View Slide

なぜDevとOpsの軋轢が生まれたのか？
169

View Slide

なぜDevとOpsの軋轢が生まれたのか？
170
ミッションの違いを理解した上で
安全に変更するための方法を考えて磨く
いまはそのための道具や磨くための手法はたくさんある

View Slide

DevとOpsで
171
Ops
Dev
集約 or 並存
は要議論
Dev視点の
メトリクス
Ops視点の
メトリクス

View Slide

DevとOpsで
172
Ops
Dev
集約 or 並存
は要議論
Dev視点の
メトリクス
Ops視点の
メトリクス
組織間の情報格差をなくすことが重要
情報の集約と公開

View Slide

173

View Slide

174
そのための取り組みをどんどんやっていきましょう

View Slide

参考になりそうな書籍たち
175

View Slide

DevOps導入指南～基本編～

DevOps導入指南～基本編～

Recruit Technologies

More Decks by Recruit Technologies

Other Decks in Technology

Featured

Transcript