Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

講師紹介 (藤原 涼馬) 藤原 涼馬 株式会社リクルートテクノロジーズ 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 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

講師紹介(宮地 克弥) 宮地 克弥 株式会社リクルートテクノロジーズ ITｴﾝｼﾞﾆｱﾘﾝｸﾞ本部 ﾌﾟﾛﾀﾞｸﾃｨﾋﾞﾃｨｴﾝｼﾞﾆｱﾘﾝｸﾞ部 ｸﾗｳﾄﾞｱｰｷﾃｸﾄG 所属 経歴 2017年 入社 主な活動 • クラウド等先進アーキテクチャの事業への装着 • 社内ISUCON, 勉強会運営コアメンバー 4 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 5

Slide 5 text

講師紹介(與那城 有) 與那城 有 株式会社リクルートテクノロジーズ ITｴﾝｼﾞﾆｱﾘﾝｸﾞ本部 ﾌﾟﾛﾀﾞｸﾃｨﾋﾞﾃｨｴﾝｼﾞﾆｱﾘﾝｸﾞ部 ｸﾗｳﾄﾞｱｰｷﾃｸﾄG 所属 経歴 2016年 入社 主な活動 • クラウド等先進アーキテクチャの事業への装着 • 社内ISUCON 5 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 6

Slide 6 text

アジェンダ DevOpsって何? DevOpsの歴史 DevOpsとは DevOpsの確立に必要なテクノロジー DevOpsの確立に必要な文化 6 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

課題 DevとOpsは仲が悪い • Devの言い分 • 「俺のコードが動かないのはOpsの準備した環境の品質が低いからだ」 • Opsの言い分 • 「障害が発生するのは、Devの作成したコードの品質が低いからだ」 11 (C) Recruit Technologies Co.,Ltd. All rights reserved. Dev Ops

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

本来はどうあるべきか DevもOpsも根っこの目的は同じ 13 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 14

Slide 14 text

本来はどうあるべきか DevもOpsも根っこの目的は同じ 14 (C) Recruit Technologies Co.,Ltd. All rights reserved. カスタマー&クライアントへの貢献 とそこからもたらされる ビジネスの成功と利益の拡大

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

DevとOpsが協力しあえるようにするには？ 2つの要素が必要 ① 組織としての文化 ② 文化を支えるテクノロジー 16 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 17

Slide 17 text

DevとOpsが協力しあえるようにするには？ 2つの要素が必要 ① 組織としての文化 ② 文化を支えるテクノロジー 17 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 18

Slide 18 text

DevとOpsが協力しあえるようにするには？ 2つの要素が必要 ① 組織としての文化 ② 文化を支えるテクノロジー 18 (C) Recruit Technologies Co.,Ltd. All rights reserved. 説明しやすい方から解説

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

1. 自動化されたインフラ • コードから自動的に環境を構築できるような仕組みを実 現できていること 22 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

なぜ自動化されたインフラが必要か(2) • 人間が作業をするので手順書ベースの作業である • 手順書が正しくても失敗は排除できない • 人間はミスをする生き物である • しかもミスの仕方は予想がつかない 25 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 26

Slide 26 text

なぜ自動化されたインフラが必要か(2) • 人間が作業をするので手順書ベースの作業である • 手順書が正しくても失敗は排除できない • 人間はミスをする生き物である • しかもミスの仕方は予想がつかない 26 (C) Recruit Technologies Co.,Ltd. All rights reserved. 生身の人間の作業は再現性が低い

Slide 27

Slide 27 text

なぜ自動化されたインフラが必要か(2) • 人間が作業をするので手順書ベースの作業である • 手順書が正しくても失敗は排除できない • 人間はミスをする生き物である • しかもミスの仕方は予想がつかない 27 (C) Recruit Technologies Co.,Ltd. All rights reserved. では、計算機にさせるとどうなる？

Slide 28

Slide 28 text

なぜ自動化されたインフラが必要か(3) • 計算機は言われた通りのことを何百万回でも集中力を切 らすことなく正確に実行できる • つまり確実成功 or 失敗※ • 人間のように疲れることは(ほぼ)ない • ちゃんと設定すれば寝落ちもしない 28 (C) Recruit Technologies Co.,Ltd. All rights reserved. ※ 一番厄介なのはうまくいったものと 失敗したものが混ざっている状態です(経験上)

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

2. 共有されたバージョンコントロール • アプリケーションコード・インフラコードは両方とも コードリポジトリで管理すること 32 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 33

Slide 33 text

2. 共有されたバージョンコントロール • アプリケーションコード・インフラコードは両方とも コードリポジトリで管理すること • アプリケーションコード • アプリケーションロジックなどのコード • インフラコード • AnsibleのplaybookやDockerfile, Kubernetesのマニフェストなど 33 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

共有されたバージョンコントロールがない状況を考える この状況で障害が起きた場合に適切な対応が可能か？ 37 (C) Recruit Technologies Co.,Ltd. All rights reserved. Aさん Bさん Cさん Dさん 全員持っているコードはばらばら 古かったり新しかったり ＿人人人人人人人人＿ ＞ 約束された死 ＜ ￣Y^Y^Y^Y^Y^Y^Y ￣

Slide 38

Slide 38 text

共有されたバージョンコントロールがあれば きちんと交通整理ができる 38 (C) Recruit Technologies Co.,Ltd. All rights reserved. Git リポジトリ 変更内容 を集約 デプロイ

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

[補足]インフラコードもリポジトリで管理する 1.自動化されたインフラでも述べている通りインフラはコー ドで記述し、共有されたバージョンコントロールに載せる (仮に手順書ベースとしても、リポジトリまたは文書基盤(Confluence)を通じてそれはDevと共有される) 40 (C) Recruit Technologies Co.,Ltd. All rights reserved. Git リポジトリ Ops Dev 別の共有 されていない 何か あいつら 何やってんの？(怒) Devには 関係ない話だから こっちのやり方で やる

Slide 41

Slide 41 text

[補足]インフラコードもリポジトリで管理する 1.自動化されたインフラでも述べている通りインフラはコー ドで記述し、共有されたバージョンコントロールに載せる (仮に手順書ベースとしても、リポジトリまたは文書基盤(Confluence)を通じてそれはDevと共有される) 41 (C) Recruit Technologies Co.,Ltd. All rights reserved. Git リポジトリ Ops Dev 情報が共有されないとヘイトが溜まりがち (互いに必要とする情報なんてわからないので勝手に判断しない) 別の共有 されていない 何か あいつら 何やってんの？(怒) Devには 関係ない話だから こっちのやり方で やる

Slide 42

Slide 42 text

[補足]インフラコードもリポジトリで管理する 1.自動化されたインフラでも述べている通りインフラはコー ドで記述し、共有されたバージョンコントロールに載せる (仮に手順書ベースとしても、リポジトリまたは文書基盤(Confluence)を通じてそれはDevと共有される) 42 (C) Recruit Technologies Co.,Ltd. All rights reserved. Git リポジトリ Ops Dev 作ったものは必ず共有できるところに置く

Slide 43

Slide 43 text

3. ワンステップビルドとデプロイ アプリケーションのビルドとデプロイについてツールを活 用して ”可能な限りシンプルなプロセス” で自動実行できるようにすること 43 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

ワンステップビルドとデプロイ なぜ必要か？ 1. 非難のない文化を作ることを助ける 2. 事業の継続性を確保する 45 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

ワンステップビルドとデプロイ なぜ必要か？ 1. 非難のない文化を作ることを助ける 2. 事業の継続性を確保する 48 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

ワンステップビルドとデプロイがない場合(2/2) ワンステップビルドとデプロイがない場合 50 (C) Recruit Technologies Co.,Ltd. All rights reserved. じゃあ、それでよろしく はい(…大丈夫かなぁ) Aさん Aさん 手順書通りにやったけど ダメだったわ (暗黙的な手順があるんやろなぁ) ふぁ〜〜〜

Slide 51

Slide 51 text

ワンステップビルドとデプロイがない場合(2/2) ワンステップビルドとデプロイがない場合 51 (C) Recruit Technologies Co.,Ltd. All rights reserved. じゃあ、それでよろしく はい(…大丈夫かなぁ) Aさん Aさん 手順書通りにやったけど ダメだったわ ふぁ〜〜〜 ありがち

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

[補足解説] ダークローンチ ユーザのリクエストを複製して擬似的に処理を行う 58 (C) Recruit Technologies Co.,Ltd. All rights reserved. プロキシ 的な何か 既存機能 ダークローンチ対象 ① ② ② ③ ③ ④ ② 既存機能とダークローンチ対象の両方に リクエストを送る

Slide 59

Slide 59 text

[補足解説] ダークローンチ ユーザのリクエストを複製して擬似的に処理を行う 59 (C) Recruit Technologies Co.,Ltd. All rights reserved. プロキシ 的な何か 既存機能 ダークローンチ対象 ① ② ② ③ ③ ④ ③ 既存機能からのレスポンスをユーザに返す

Slide 60

Slide 60 text

[補足解説] ダークローンチ ユーザのリクエストを複製して擬似的に処理を行う 60 (C) Recruit Technologies Co.,Ltd. All rights reserved. プロキシ 的な何か 既存機能 ダークローンチ対象 ① ② ② ③ ③ ④ ④ ダークローンチ対象からのレスポンスを破棄する

Slide 61

Slide 61 text

[補足解説] ダークローンチ ユーザのリクエストを複製して擬似的に処理を行う 61 (C) Recruit Technologies Co.,Ltd. All rights reserved. プロキシ 的な何か 既存機能 ダークローンチ対象 ① ② ② ③ ③ ④ 新機能が他の機能の挙動に悪影響を与えていないか、 既存機能との性能差異などを確認する

Slide 62

Slide 62 text

フィーチャーフラグがない場合 小さく試して、小さく失敗 が できなくなる 62 (C) Recruit Technologies Co.,Ltd. All rights reserved. うぉぉぉお、 サービス保ってくれ いきなり100%適用だ! いきなり大規模適用 大惨事

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

よくある話 DevとOpsで違う指標を見ている 66 (C) Recruit Technologies Co.,Ltd. All rights reserved. Dev Ops Watch Watch 課題がある ﾅﾆｿﾚ!?

Slide 67

Slide 67 text

よくある話 DevとOpsで違う指標を見ている 67 (C) Recruit Technologies Co.,Ltd. All rights reserved. Dev Ops Watch Watch 課題がある ﾅﾆｿﾚ!? ミスコミュニケーションが 起きるに決まっている

Slide 68

Slide 68 text

DevとOpsで 同じ情報ソースを使ってコミュニケーションをとる 互いのノウハウは集約 68 (C) Recruit Technologies Co.,Ltd. All rights reserved. Ops Dev 集約 or 並存 は要議論 Dev視点の メトリクス Ops視点の メトリクス

Slide 69

Slide 69 text

DevとOpsで 同じ情報ソースを使ってコミュニケーションをとる 互いのノウハウは集約 69 (C) Recruit Technologies Co.,Ltd. All rights reserved. Ops Dev 同じ情報を見て議論できるので ミスコミュニケーションは減る 集約 or 並存 は要議論 Dev視点の メトリクス Ops視点の メトリクス

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

早い話がチャット基盤とチャットボットを積極的に使いましょ CIの結果通知やビジネス上の実績などをチャットボットを 使ってチャット基盤に流しましょう 71 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

まとめ 6つの要素をざっくりと分類する 1. 自動化されたインフラ 2. 共有されたバージョンコントロール 3. ワンステップビルドとデプロイ 4. フィーチャーフラグ 5. 共有されたメトリクス 6. チャットとチャットボット 74 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 75

Slide 75 text

DepOps文化の確立を支援するテクノロジーまとめ 75 (C) Recruit Technologies Co.,Ltd. All rights reserved. 安全に仮説検証する仕組み作り 属人性の軽減・排除 コミュニケーションの円滑化 自動化されたインフラ 共有されたバージョンコントロール ワンステップビルドとデプロイ フィーチャーフラグ 共有されたメトリクス 共有されたメトリクス

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

DevとOpsが協力しあえるようにするには？ 2つの要素が必要 ① 組織としての文化 ② 文化を支えるテクノロジー 77 (C) Recruit Technologies Co.,Ltd. All rights reserved. ある意味本題

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

DevOpsの確立に必要な組織文化 1. リスペクトしあうこと 2. 互いに信頼すること 3. 失敗に対して健全な態度をとること 4. 個人を非難しないこと 80 (C) Recruit Technologies Co.,Ltd. All rights reserved. もちろんこれは、DevおよびOpsそれぞれの 構成メンバーが、責任を持って全力を尽くすことが前提 & 後段の文化は前段を前提とする (例えば2は1を前提とする)

Slide 81

Slide 81 text

DevOpsの確立に必要な組織文化 1. リスペクトしあうこと 2. 互いに信頼すること 3. 失敗に対して健全な態度をとること 4. 個人を非難しないこと 81 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 82

Slide 82 text

1. リスペクトしあうこと • 先入観を持たない • 他人の専門知識・意見・責任を尊重する • ノーというだけのことはしない • 隠し事はしない • 依頼する前にやる事・考える事をちゃんとやる 82 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

他人の専門知識・意見・責任を尊重する • いくら優秀でも全てにおいて優っていることはない • 他人は異なる視点を持っているので • 他人の専門領域 • 他人の抱えている役割 • 上記2つをベースとして意見は尊重すること 85 (C) Recruit Technologies Co.,Ltd. All rights reserved. ただし、Whyを深掘りして尋ねるのはOK (むしろ互いのレベルアップのためにどんどんすべき)

Slide 86

Slide 86 text

他人の専門知識・意見・責任を尊重する • いくら優秀でも全てにおいて優っていることはない • 他人は異なる視点を持っているので • 他人の専門領域 • 他人の抱えている役割 • 上記2つをベースとして意見は尊重すること 86 (C) Recruit Technologies Co.,Ltd. All rights reserved. ただし、Whyを深掘りして尋ねるのはOK 他人の意見を聞いて、施作を磨き込んで 成果が上がったならその成果はあなたの成果

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

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

Slide 89

Slide 89 text

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

Slide 90

Slide 90 text

DevOpsの確立に必要な組織文化 1. リスペクトしあうこと 2. 互いに信頼すること 3. 失敗に対して健全な態度をとること 4. 個人を非難しないこと 90 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 91

Slide 91 text

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

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

2. 信頼関係を気づく上で重要なこと 1. Opsは新機能について議論する際はDevを信頼すること 2. Devはインフラ構成の変更についてはOpsを信頼すること 3. Opsは透明性を以って運用を行い、Devに最大限のアクセ ス権限を渡すこと 93 (C) Recruit Technologies Co.,Ltd. All rights reserved. 互いにそれぞれの専門領域において リスペクトしあうこと Devでもできる事を無理にOpsがする必要はない

Slide 94

Slide 94 text

2. 信頼関係を気づく上で重要なこと 1. Opsは新機能について議論する際はDevを信頼すること 2. Devはインフラ構成の変更についてはOpsを信頼すること 3. Opsは透明性を以って運用を行い、Devに最大限のアクセ ス権限を渡すこと 94 (C) Recruit Technologies Co.,Ltd. All rights reserved. 互いにそれぞれの専門領域において リスペクトしあうこと Devでもできる事を無理にOpsがする必要はない DevとOpsは互いに補完しあう関係であり、 互いの長所を活かしあう仕組みにしない生き残れない

Slide 95

Slide 95 text

DevOpsの確立に必要な組織文化 1. リスペクトしあうこと 2. 互いに信頼すること 3. 失敗に対して健全な態度をとること 4. 個人を非難しないこと 95 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

目的 • CI/CDやモニタリングダッシュボード • AnsibleやTerraform、Docker、Kubernetes • 12 Factor Apps などの考え方について、DevOpsとの関連を交えて解説 101 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 102

Slide 102 text

CI/CDとはなんぞや？ • CI • 継続的インテグレーション, Continuous Integration • CD 1. 継続的デプロイ, Continuous Deploy 2. 継続的デリバリ, Continuous Delivery 102 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

なぜCIが必要か？ 104 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 105

Slide 105 text

なぜCIが必要か • 常に同じ手順でビルドとテストを繰り返し行えるように するため 105 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 106

Slide 106 text

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

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

よくある反論(2) 開発スピードを重視したいのでテストを書くのは嫌だ 108 (C) Recruit Technologies Co.,Ltd. All rights reserved. 君はいなくなるだろうからいいけど、 残された人間はテストのないコードをみてどう思うだろうか？

Slide 109

Slide 109 text

よくある反論(3) 既存コードにテストがない 109 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 110

Slide 110 text

よくある反論(3) 既存コードにテストがない 110 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

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

Slide 113

Slide 113 text

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

Slide 114

Slide 114 text

CDの重要なポイント 継続的デリバリ/デプロイ共に、 程度の差こそあれ”自動”リリースであること 114 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 115

Slide 115 text

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

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

デプロイのコード化に際して考えること 1.デプロイ頻度 2.手順の複雑さ 117 (C) Recruit Technologies Co.,Ltd. All rights reserved. デプロイ頻度が高い、かつデプロイ手順 が複雑なものから手をつける

Slide 118

Slide 118 text

CIとCDを支える技術 118 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 119

Slide 119 text

CIと支える技術と考え方 119 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 120

Slide 120 text

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

Slide 121

Slide 121 text

CIを支える技術 CIを支える様々なツールがある(主観による雑な分類です) 121 (C) Recruit Technologies Co.,Ltd. All rights reserved. CIパイプラインツール ビルドの支援ツール（パッケージ管理ツール含む） テストの支援ツール GNU make go test python -m unittest ビルドとテストの全体フローを自動化する

Slide 122

Slide 122 text

CIを支える技術 CIを支える様々なツールがある(主観による雑な分類です) 122 (C) Recruit Technologies Co.,Ltd. All rights reserved. CIパイプラインツール ビルドの支援ツール（パッケージ管理ツール含む） テストの支援ツール GNU make go test python -m unittest ビルドとテストの全体フローを自動化する (主にアプリケーションの)ビルドフローを自動化する

Slide 123

Slide 123 text

CIを支える技術 CIを支える様々なツールがある(主観による雑な分類です) 123 (C) Recruit Technologies Co.,Ltd. All rights reserved. CIパイプラインツール ビルドの支援ツール（パッケージ管理ツール含む） テストの支援ツール GNU make go test python -m unittest ビルドとテストの全体フローを自動化する (主にアプリケーションの)ビルドフローを自動化する テストフローを自動化する

Slide 124

Slide 124 text

CIを支える技術 CIを支える様々なツールがある(主観による雑な分類です) 124 (C) Recruit Technologies Co.,Ltd. All rights reserved. CIパイプラインツール ビルドの支援ツール（パッケージ管理ツール含む） テストの支援ツール GNU make go test python -m unittest ビルドとテストの全体フローを自動化する (主にアプリケーションの)ビルドフローを自動化する テストフローを自動化する アプリケーションロジック記述以外から 属人性を可能な限り排除するのが目的

Slide 125

Slide 125 text

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

Slide 126

Slide 126 text

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

Slide 127

Slide 127 text

CIでよくある問題 • テストが安定しない • テストの実行時間が長い 127 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 128

Slide 128 text

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

Slide 129

Slide 129 text

テストが安定しない • 過去のビルドにおける副生成物・副作用によってテスト が安定しない(放置された中間ファイルやDBの状態などに起因) 129 (C) Recruit Technologies Co.,Ltd. All rights reserved. ビルドの独立性を高め、環境依存性を 下げることを考える

Slide 130

Slide 130 text

テストが安定しない • 過去のビルドにおける副生成物・副作用によってテスト が安定しない(放置された中間ファイルやDBの状態などに起因) 130 (C) Recruit Technologies Co.,Ltd. All rights reserved. ビルドの独立性を高め、環境依存性を 下げることを考える 例えば、CIではDockerを使って ビルド・テストを実行する。DBも都度作る

Slide 131

Slide 131 text

テストの実行時間が長い • テストサイズの概念を使って効率的にテストをする • テストがこける原因の8割くらいはしょうもないことが原因 • Lintやネットワーク通信の発生しないテストで洗い出せる 131 (C) Recruit Technologies Co.,Ltd. All rights reserved. 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

Slide 132

Slide 132 text

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

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

CIでよくある問題 • テストが安定しない • 対策 • ビルドの独立性をあげる • テストの実行時間が長い • 対策 • CIのパフォーマンスを改善する • テストサイズの概念を導入したCIパイプライン構成 134 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 135

Slide 135 text

CIでよくある問題 • テストが安定しない • 対策 • ビルドの独立性をあげる • テストの実行時間が長い • 対策 • CIのパフォーマンスを改善する • テストサイズの概念を導入したCIパイプライン構成 135 (C) Recruit Technologies Co.,Ltd. All rights reserved. 参考 • 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

Slide 136

Slide 136 text

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

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

CDのよくある問題 どうやってデプロイ品質を磨き込むか? 139 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 140

Slide 140 text

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

Slide 141

Slide 141 text

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

Slide 142

Slide 142 text

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

Slide 143

Slide 143 text

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

Slide 144

Slide 144 text

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

Slide 145

Slide 145 text

時間が余ったので THE TWELVE-FACTOR APP 145 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 146

Slide 146 text

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

Slide 147

Slide 147 text

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

Slide 148

Slide 148 text

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

Slide 149

Slide 149 text

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

Slide 150

Slide 150 text

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

Slide 151

Slide 151 text

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

Slide 152

Slide 152 text

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

Slide 153

Slide 153 text

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

Slide 154

Slide 154 text

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

Slide 155

Slide 155 text

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

Slide 156

Slide 156 text

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

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

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

Slide 159

Slide 159 text

VII. ポートバインディング ポートバインディングを通してサービスを公開する ＝指定されたTCP/UDPポート番号を使ってサービスを公開 する 159 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 160

Slide 160 text

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

Slide 161

Slide 161 text

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

Slide 162

Slide 162 text

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

Slide 163

Slide 163 text

XI. ログ ログはfluentdやlogstashなどのツールを用いて特定の場所 に集約する 163 (C) Recruit Technologies Co.,Ltd. All rights reserved. 数十〜数百のサーバー 数十〜数百のサーバー 集約 ログの集約をしていない場合 ログの集約をしている場合

Slide 164

Slide 164 text

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

Slide 165

Slide 165 text

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

Slide 166

Slide 166 text

まとめ 166 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 167

Slide 167 text

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

Slide 168

Slide 168 text

DevOpsって美味しいの？どんか効果があるの? DevOpsを実践できている企業の業績 vs DevOpsを実践できていない企業 168 (C) Recruit Technologies Co.,Ltd. All rights reserved. コードのデプロイ頻度 (= 仮説検証の頻度) 46倍 コードをコミットしてから 本番デプロイまでのリードタイム 1/1440 障害からの 平均復旧時間 1/170 変更失敗率 1/5 たくさん打席に立つことが ヒットをうつ上で重要 安全に失敗しつつ、 確実に成功に繋げられるようにする

Slide 169

Slide 169 text

なぜDevとOpsの軋轢が生まれたのか？ DevとOpsでは求められているミッションが異なるため • Devのミッション • 新しい機能を追加してビジネス全体の売り上げを伸ばす • どんどん変更を加えたい • Opsのミッション • システムの安定稼働を実現してビジネス全体の売上の逸失を避ける • 変更は障害の原因になりがちなので避けたい 169 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 170

Slide 170 text

なぜDevとOpsの軋轢が生まれたのか？ DevとOpsでは求められているミッションが異なるため • Devのミッション • 新しい機能を追加してビジネス全体の売り上げを伸ばす • どんどん変更を加えたい • Opsのミッション • システムの安定稼働を実現してビジネス全体の売上の逸失を避ける • 変更は障害の原因になりがちなので避けたい 170 (C) Recruit Technologies Co.,Ltd. All rights reserved. ミッションの違いを理解した上で 安全に変更するための方法を考えて磨く いまはそのための道具や磨くための手法はたくさんある

Slide 171

Slide 171 text

DevとOpsで 同じ情報ソースを使ってコミュニケーションをとる 互いのノウハウは集約 171 (C) Recruit Technologies Co.,Ltd. All rights reserved. Ops Dev 同じ情報を見て議論できるので ミスコミュニケーションは減る 集約 or 並存 は要議論 Dev視点の メトリクス Ops視点の メトリクス

Slide 172

Slide 172 text

DevとOpsで 同じ情報ソースを使ってコミュニケーションをとる 互いのノウハウは集約 172 (C) Recruit Technologies Co.,Ltd. All rights reserved. Ops Dev 同じ情報を見て議論できるので ミスコミュニケーションは減る 集約 or 並存 は要議論 Dev視点の メトリクス Ops視点の メトリクス 組織間の情報格差をなくすことが重要 情報の集約と公開

Slide 173

Slide 173 text

本来はどうあるべきか DevもOpsも根っこの目的は同じ 173 (C) Recruit Technologies Co.,Ltd. All rights reserved. カスタマー&クライアントへの貢献 とそこからもたらされる ビジネスの成功と利益の拡大

Slide 174

Slide 174 text

本来はどうあるべきか DevもOpsも根っこの目的は同じ 174 (C) Recruit Technologies Co.,Ltd. All rights reserved. カスタマー&クライアントへの貢献 とそこからもたらされる ビジネスの成功と利益の拡大 そのための取り組みをどんどんやっていきましょう

Slide 175

Slide 175 text

参考になりそうな書籍たち 175 (C) Recruit Technologies Co.,Ltd. All rights reserved.