DevOps導入指南～基本編～

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

講師紹介 (藤原涼馬) 藤原涼馬株式会社リクルートテクノロジーズ 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Aさん Bさん Cさん Dさん全員持っているコードはばらばら古かったり新しかったり

Aさん Bさん Cさん Dさん全員持っているコードはばらばら古かったり新しかったり＿人人人人人人人人＿＞約束された死＜￣Y^Y^Y^Y^Y^Y^Y ￣

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

reserved. プロキシ的な何か既存機能ダークローンチ対象 ① ② ② ③ ③ ④ ③ 既存機能からのレスポンスをユーザに返す

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CIパイプラインツールビルドの支援ツール（パッケージ管理ツール含む）テストの支援ツール GNU make go test python -m unittest ビルドとテストの全体フローを自動化する

CIパイプラインツールビルドの支援ツール（パッケージ管理ツール含む）テストの支援ツール GNU make go test python -m unittest ビルドとテストの全体フローを自動化する (主にアプリケーションの)ビルドフローを自動化する

CIパイプラインツールビルドの支援ツール（パッケージ管理ツール含む）テストの支援ツール GNU make go test python -m unittest ビルドとテストの全体フローを自動化する (主にアプリケーションの)ビルドフローを自動化するテストフローを自動化する

CIパイプラインツールビルドの支援ツール（パッケージ管理ツール含む）テストの支援ツール GNU make go test python -m unittest ビルドとテストの全体フローを自動化する (主にアプリケーションの)ビルドフローを自動化するテストフローを自動化するアプリケーションロジック記述以外から属人性を可能な限り排除するのが目的

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

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

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

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

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

テストの実行時間が長い • テストサイズの概念を使って効率的にテストをする • テストがこける原因の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

テストサイズの概念に合わせた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テストで落とす

テストサイズの概念に合わせた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のパフォーマンスを改善することでコードを書いてからフィードバックを受けるまでの時間を短くする

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

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

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

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

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

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

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

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

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

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

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

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

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ファイルを依存関係に入れるなど

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

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

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

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

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

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

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

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

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

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をその場で実行するなどの複雑な作業はさせないようにすること

rights reserved. コードのデプロイ頻度 (= 仮説検証の頻度) 46倍コードをコミットしてから本番デプロイまでのリードタイム 1/1440 障害からの平均復旧時間 1/170 変更失敗率 1/5

rights reserved. コードのデプロイ頻度 (= 仮説検証の頻度) 46倍コードをコミットしてから本番デプロイまでのリードタイム 1/1440 障害からの平均復旧時間 1/170 変更失敗率 1/5 たくさん打席に立つことがヒットをうつ上で重要安全に失敗しつつ、確実に成功に繋げられるようにする

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

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

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

reserved. Ops Dev 同じ情報を見て議論できるのでミスコミュニケーションは減る集約 or 並存は要議論 Dev視点のメトリクス Ops視点のメトリクス組織間の情報格差をなくすことが重要情報の集約と公開

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

カスタマー&クライアントへの貢献とそこからもたらされるビジネスの成功と利益の拡大そのための取り組みをどんどんやっていきましょう

DevOps導入指南～基本編～

DevOps導入指南～基本編～

More Decks by Recruit Technologies

Other Decks in Technology

Featured

Transcript