Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOps導入指南~基本編~

 DevOps導入指南~基本編~

2019年度リクルート新人ブートキャンプ エンジニアコースの講義資料です

Recruit Technologies

June 24, 2019
Tweet

More Decks by Recruit Technologies

Other Decks in Technology

Transcript

  1. DevOps導入指南 ~基本編~ 1 (C) Recruit Technologies Co.,Ltd. All rights reserved.

    ITエンジニアリング本部 プロダクティビティエンジニアリング部 クラウドアーキテクトG 藤原 涼馬
  2. 講師紹介 (藤原 涼馬) 藤原 涼馬 株式会社リクルートテクノロジーズ 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.
  3. 講師紹介(伊藤 瑛) 伊藤 瑛 株式会社リクルートテクノロジーズ ITエンジニアリング本部プロダクトエンジニアリング部 アプリケーションソリューションG 経歴 2015年 入社

    主な活動 • フロントエンド・サーバサイドの先進テクノロジ装着 • アプリケーションアーキテクティング 3 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  4. 講師紹介(宮地 克弥) 宮地 克弥 株式会社リクルートテクノロジーズ ITエンジニアリング本部 プロダクティビティエンジニアリング部 クラウドアーキテクトG 所属 経歴

    2017年 入社 主な活動 • クラウド等先進アーキテクチャの事業への装着 • 社内ISUCON, 勉強会運営コアメンバー 4 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  5. 講師紹介(與那城 有) 與那城 有 株式会社リクルートテクノロジーズ ITエンジニアリング本部 プロダクティビティエンジニアリング部 クラウドアーキテクトG 所属 経歴

    2016年 入社 主な活動 • クラウド等先進アーキテクチャの事業への装着 • 社内ISUCON 5 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  6. アジェンダ DevOpsって何? DevOpsの歴史 DevOpsとは DevOpsの確立に必要なテクノロジー DevOpsの確立に必要な文化 6 (C) Recruit Technologies

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

    Technologies Co.,Ltd. All rights reserved. Dev Ops Dev Ops
  8. DevOpsって美味しいの?どんか効果があるの? DevOpsを実践できている企業の業績 vs DevOpsを実践できていない企業 8 (C) Recruit Technologies Co.,Ltd. All

    rights reserved. コードのデプロイ頻度 (= 仮説検証の頻度) 46倍 コードをコミットしてから 本番デプロイまでのリードタイム 1/1440 障害からの 平均復旧時間 1/170 変更失敗率 1/5 DevOpsとLeanの科学から抜粋
  9. DevOpsを実践できると DevOpsを実践できている企業とそうでない企業では以下 のような観点で 有意な差があった 1. 商品やサービスの量 2. 作業効率 3. 顧客満足度

    4. 製品やサービスの質 5. 組織や任務の目標達成度 9 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  10. 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
  11. 課題 DevとOpsは仲が悪い • Devの言い分 • 「俺のコードが動かないのはOpsの準備した環境の品質が低いからだ」 • Opsの言い分 • 「障害が発生するのは、Devの作成したコードの品質が低いからだ」

    11 (C) Recruit Technologies Co.,Ltd. All rights reserved. Dev Ops
  12. なぜDevとOpsの軋轢があるのか DevとOpsでは求められているミッションが異なるため • Devのミッション • 新しい機能を追加してビジネス全体の売り上げを伸ばす • どんどん変更を加えたい • Opsのミッション

    • システムの安定稼働を実現してビジネス全体の売上の逸失を避ける • 変更は障害の原因になりがちなので避けたい 12 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  13. 本来はどうあるべきか DevもOpsも根っこの目的は同じ 13 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

    カスタマー&クライアントへの貢献 とそこからもたらされる ビジネスの成功と利益の拡大
  15. DevとOpsが協力しあえるようにするには? • (アイデア) DevとOpsを混ぜてしまえば良いのでは? • 短期的には イエス • リリース初期においては自身のプロダクトの品質などを知る意味でも 運用すべき

    • 中長期的には ノー • 人のスキルには向き不向きがある • 攻め(Dev)に強い人、守り(Ops)に強い人というのは明らかに存在す る • 角を矯めて牛を殺すといった事態は避けたい 15 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  16. DevとOpsが協力しあえるようにするには? 2つの要素が必要 ① 組織としての文化 ② 文化を支えるテクノロジー 16 (C) Recruit Technologies

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

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

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

    Co.,Ltd. All rights reserved. 現実としてありえない組織 現実の組織 (スーパーマンはほとんどいない)
  20. DepOps文化の確立を支援するテクノロジー DevOps文化の確立を支援するテクノロジーとして大きく6 つがあると言われている 1. 自動化されたインフラ 2. 共有されたバージョンコントロール 3. ワンステップビルドとデプロイ 4.

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

    フィーチャーフラグ 5. 共有されたメトリクス 6. チャットとチャットボット 21 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  22. 1. 自動化されたインフラ • コードから自動的に環境を構築できるような仕組みを実 現できていること 22 (C) Recruit Technologies Co.,Ltd.

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

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

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

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

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

    (C) Recruit Technologies Co.,Ltd. All rights reserved. では、計算機にさせるとどうなる?
  28. なぜ自動化されたインフラが必要か(3) • 計算機は言われた通りのことを何百万回でも集中力を切 らすことなく正確に実行できる • つまり確実成功 or 失敗※ • 人間のように疲れることは(ほぼ)ない

    • ちゃんと設定すれば寝落ちもしない 28 (C) Recruit Technologies Co.,Ltd. All rights reserved. ※ 一番厄介なのはうまくいったものと 失敗したものが混ざっている状態です(経験上)
  29. なぜ自動化されたインフラが必要か(まとめ) • 人間はミスをする生き物である • 大量の繰り返しは比較的苦手※ • 入力と出力が1対1になりづらい • 計算機は繰り返し作業が得意 •

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

    何万回の繰り返し作業でも平気 • 入力と出力が1対1になりやすい • ほぼ、書いたようにしか動かない 30 (C) Recruit Technologies Co.,Ltd. All rights reserved. ※特殊な訓練を受けた人は除きます 適材適所を適切に行うべき つまり、繰り返し作業は計算機に行わせるべき
  31. DepOps文化の確立を支援するテクノロジー DevOps文化の確立を支援するテクノロジーとして大きく6 つがあると言われている 1. 自動化されたインフラ 2. 共有されたバージョンコントロール 3. ワンステップビルドとデプロイ 4.

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

    All rights reserved.
  33. 2. 共有されたバージョンコントロール • アプリケーションコード・インフラコードは両方とも コードリポジトリで管理すること • アプリケーションコード • アプリケーションロジックなどのコード •

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

    rights reserved.
  35. 共有されたバージョンコントロールがない状況を考える この状況で障害が起きた場合に適切な対応が可能か? 35 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

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

    Aさん Bさん Cさん Dさん 全員持っているコードはばらばら 古かったり新しかったり _人人人人人人人人_ > 約束された死 <  ̄Y^Y^Y^Y^Y^Y^Y  ̄
  38. 共有されたバージョンコントロールがあれば きちんと交通整理ができる 38 (C) Recruit Technologies Co.,Ltd. All rights reserved.

    Git リポジトリ 変更内容 を集約 デプロイ
  39. [補足]インフラコードもリポジトリで管理する 1.自動化されたインフラでも述べている通りインフラはコー ドで記述し、共有されたバージョンコントロールに載せる (仮に手順書ベースとしても、リポジトリまたは文書基盤(Confluence)を通じてそれはDevと共有される) 39 (C) Recruit Technologies Co.,Ltd. All

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

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

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

    rights reserved. Git リポジトリ Ops Dev 作ったものは必ず共有できるところに置く
  43. 3. ワンステップビルドとデプロイ アプリケーションのビルドとデプロイについてツールを活 用して ”可能な限りシンプルなプロセス” で自動実行できるようにすること 43 (C) Recruit Technologies

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

    フィーチャーフラグ 5. 共有されたメトリクス 6. チャットとチャットボット 44 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  45. ワンステップビルドとデプロイ なぜ必要か? 1. 非難のない文化を作ることを助ける 2. 事業の継続性を確保する 45 (C) Recruit Technologies

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

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

    rights reserved. Dev Ops ①パイプラインを レビューする ②パイプラインを デプロイする ③デプロイ作業を 実施する ④成否の振り返り と確認 Ops Dev 人間が細々とした作業をデプロイ時にしないので、 問題が起きても冷静かつ建設的な議論がしやすい傾向 (コード通りにデプロイは行われていることが確証できるのが大きい)
  48. ワンステップビルドとデプロイ なぜ必要か? 1. 非難のない文化を作ることを助ける 2. 事業の継続性を確保する 48 (C) Recruit Technologies

    Co.,Ltd. All rights reserved.
  49. ワンステップビルドとデプロイがない場合(1/2) ワンステップビルドとデプロイがない場合 49 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

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

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

    今日はリリース作業ですね ですね。デプロイボタン押します (Bさんいないけど自動化されてるのでやれる) できた Aさん うぇーい
  53. 事業の継続性を確保する ビルド・デプロイプロセスをシンプルに保ちつつ、 自動化することで事業の継続性を確保しやすくなる (もちろん限界はある) 53 (C) Recruit Technologies Co.,Ltd. All

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

    フィーチャーフラグ 5. 共有されたメトリクス 6. チャットとチャットボット 54 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  55. フィーチャーフラグとは 特定の機能を有効化したり一部の人にのみ提供するための フラグ。これを提供することで下記を実現できるようにす る。 • プライベートベータ • 一部の”指定したユーザにのみ”機能を公開する • A/Bテスト

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

    A/Bテスト • 比率を定めて機能や新UIを公開し、反響を調べる • ダークローンチ(後ほど補足) • ユーザのリクエストを複製して擬似的に処理を行う 56 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  57. [補足解説] ダークローンチ ユーザのリクエストを複製して擬似的に処理を行う 57 (C) Recruit Technologies Co.,Ltd. All rights

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

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

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

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

    reserved. プロキシ 的な何か 既存機能 ダークローンチ対象 ① ② ② ③ ③ ④ 新機能が他の機能の挙動に悪影響を与えていないか、 既存機能との性能差異などを確認する
  62. フィーチャーフラグがない場合 小さく試して、小さく失敗 が できなくなる 62 (C) Recruit Technologies Co.,Ltd. All

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

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

    reserved. 小さく始める まずは全体の10% からやっていこうか 失敗 成功 スコープを広げる 次は50%いこうか 傷が浅くて よかったね 振り返って 次の施策を 考えましょ 冷静に振り返って 次に繋げる 被害が小さいので冷静に振り返りができる
  65. DepOps文化の確立を支援するテクノロジー DevOps文化の確立を支援するテクノロジーとして大きく6 つがあると言われている 1. 自動化されたインフラ 2. 共有されたバージョンコントロール 3. ワンステップビルドとデプロイ 4.

    フィーチャーフラグ 5. 共有されたメトリクス 6. チャットとチャットボット 65 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  66. よくある話 DevとOpsで違う指標を見ている 66 (C) Recruit Technologies Co.,Ltd. All rights reserved.

    Dev Ops Watch Watch 課題がある ナニソレ!?
  67. よくある話 DevとOpsで違う指標を見ている 67 (C) Recruit Technologies Co.,Ltd. All rights reserved.

    Dev Ops Watch Watch 課題がある ナニソレ!? ミスコミュニケーションが 起きるに決まっている
  68. DevとOpsで 同じ情報ソースを使ってコミュニケーションをとる 互いのノウハウは集約 68 (C) Recruit Technologies Co.,Ltd. All rights

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

    reserved. Ops Dev 同じ情報を見て議論できるので ミスコミュニケーションは減る 集約 or 並存 は要議論 Dev視点の メトリクス Ops視点の メトリクス
  70. DepOps文化の確立を支援するテクノロジー DevOps文化の確立を支援するテクノロジーとして大きく6 つがあると言われている 1. 自動化されたインフラ 2. 共有されたバージョンコントロール 3. ワンステップビルドとデプロイ 4.

    フィーチャーフラグ 5. 共有されたメトリクス 6. チャットとチャットボット 70 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  71. 早い話がチャット基盤とチャットボットを積極的に使いましょ CIの結果通知やビジネス上の実績などをチャットボットを 使ってチャット基盤に流しましょう 71 (C) Recruit Technologies Co.,Ltd. All rights

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

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

    Technologies Co.,Ltd. All rights reserved. 非同期 コミュニケーション 同期 コミュニケーション メール チャット 対面ミーティング 電話
  74. まとめ 6つの要素をざっくりと分類する 1. 自動化されたインフラ 2. 共有されたバージョンコントロール 3. ワンステップビルドとデプロイ 4. フィーチャーフラグ

    5. 共有されたメトリクス 6. チャットとチャットボット 74 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  75. DepOps文化の確立を支援するテクノロジーまとめ 75 (C) Recruit Technologies Co.,Ltd. All rights reserved. 安全に仮説検証する仕組み作り

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

    属人性の軽減・排除 コミュニケーションの円滑化 自動化されたインフラ 共有されたバージョンコントロール ワンステップビルドとデプロイ フィーチャーフラグ 共有されたメトリクス 共有されたメトリクス DevとOpsが適切にコミュニケーションしつつ、 互いのヘイトを溜めない仕組みづくりが重要 結果互いの強みを組み合わせてシナジー効果を出す
  77. DevとOpsが協力しあえるようにするには? 2つの要素が必要 ① 組織としての文化 ② 文化を支えるテクノロジー 77 (C) Recruit Technologies

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

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

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

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

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

    • 依頼する前にやる事・考える事をちゃんとやる 82 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  83. 先入観を持たない • いつもxxxなのでyyyしようはNG • 時間が経てば人の中身は変わる & 状況も変わる • 人の中身が変わらないというのはその人の成長の可能性を信頼し ていない

    • 簡単でも良いのできちんと確認する • チャットでもなんでも良いので確認する • そのためにコミュニケーション基盤(Slack, JIRA/Confluence)が 整備されている 83 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  84. 他人の専門知識・意見・責任を尊重する • いくら優秀でも全てにおいて優っていることはない • 他人は異なる視点を持っているので • 他人の専門領域 • 他人の抱えている役割 •

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

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

    上記2つをベースとして意見は尊重すること 86 (C) Recruit Technologies Co.,Ltd. All rights reserved. ただし、Whyを深掘りして尋ねるのはOK 他人の意見を聞いて、施作を磨き込んで 成果が上がったならその成果はあなたの成果
  87. ノーというだけはしない 特にOps側が依頼を受ける際に求められる姿勢 • 拒否する際には客観的な理由を示すこと • 理由なく拒否されれば納得しない • どうすれば許容されるのかを示すこと • ただ拒否するだけではなく、どうすれば依頼に応えられるかを返

    すこと • 拒否する際には依頼に対するWhyも掘り下げること • 掘り下げる中で真の目的を達成する他の方法が提案できるかもし れない 87 (C) Recruit Technologies Co.,Ltd. All rights reserved. 協力の姿勢を崩さないこと (最終目的はDevもOpsも同じ)
  88. 隠し事はしない • どうせバレる。バレた時に失われる信頼を考えると初め から伝えておいた方が良い • ヤバいことほど積極的に伝える • もちろん聞く側はそれを冷静に受け止めてどうするかを一緒に考 えること 88

    (C) Recruit Technologies Co.,Ltd. All rights reserved.
  89. (DevはOpsに)依頼する前にやれる事をきちんとやっておく事 • きちんとできることはやり尽くした上で依頼する • 依頼する際にやっておくべきこと 1. 何を変更するか 2. 変更に伴うリスク 3.

    変更の成功・失敗の判断基準と連絡方法 4. 失敗時の対応方針 89 (C) Recruit Technologies Co.,Ltd. All rights reserved. 1, 2 は必須(もちろんOpsに意見を求めるのはWelcome) 3,4は意見を出し合ってすり合わせ
  90. DevOpsの確立に必要な組織文化 1. リスペクトしあうこと 2. 互いに信頼すること 3. 失敗に対して健全な態度をとること 4. 個人を非難しないこと 90

    (C) Recruit Technologies Co.,Ltd. All rights reserved.
  91. 2. 信頼すること 信頼関係を確立できていない状態では健全な関係は作れな い 91 (C) Recruit Technologies Co.,Ltd. All

    rights reserved. (大前提) DevもOpsもプロフェッショナルとして 自身の仕事に対して最善を尽くしていること
  92. 2. 信頼関係を気づく上で重要なこと 1. Opsは新機能について議論する際はDevを信頼すること 2. Devはインフラ構成の変更についてはOpsを信頼すること 3. Opsは透明性を以って運用を行い、Devに最大限のアクセ ス権限を渡すこと 92

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

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

    (C) Recruit Technologies Co.,Ltd. All rights reserved. 互いにそれぞれの専門領域において リスペクトしあうこと Devでもできる事を無理にOpsがする必要はない DevとOpsは互いに補完しあう関係であり、 互いの長所を活かしあう仕組みにしない生き残れない
  95. DevOpsの確立に必要な組織文化 1. リスペクトしあうこと 2. 互いに信頼すること 3. 失敗に対して健全な態度をとること 4. 個人を非難しないこと 95

    (C) Recruit Technologies Co.,Ltd. All rights reserved.
  96. 3. 失敗に対する健全な態度 • 失敗は“必ず起きる”ものだという意識を持つ事 • 失敗の確率を下げるために”経済的・工数的に合理的な範囲”で 最善を作ることはもちろん必要 • 失敗を回避する事を考え続けている限り、失敗に対応す る能力は向上しない

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

    • 失敗が起きても大丈夫 or 迅速に復旧できる仕組みを準備してお くこと 97 (C) Recruit Technologies Co.,Ltd. All rights reserved. きかんしゃトーマスの 「じこはおこるさ」 の精神を持つ
  98. 4. 非難しない • 失敗が起きた時に原因を”特定の人”に求めない • 萎縮効果でその人のパフォーマンスを低下させる • 自分が失敗した時に跳ね返ってくる 98 (C)

    Recruit Technologies Co.,Ltd. All rights reserved. 失敗は必ず起きるので、 “仕組みとしてどう軽減・回避するか” を対策として考えた方が良い
  99. DevOpsの確立に必要な組織文化まとめ • 目的の達成のために協力しあうこと • 互いが能力を最大限発揮できるようにすること • 個人の能力ではなく仕組みで課題には対処すること • 特定個人の能力にチーム全体が縛られない仕組みを作ること 99

    (C) Recruit Technologies Co.,Ltd. All rights reserved.
  100. DevOps導入指南 ~技術編~ 100 (C) Recruit Technologies Co.,Ltd. All rights reserved.

    ITエンジニアリング本部 プロダクティビティエンジニアリング部 クラウドアーキテクトG 藤原 涼馬
  101. 目的 • CI/CDやモニタリングダッシュボード • AnsibleやTerraform、Docker、Kubernetes • 12 Factor Apps などの考え方について、DevOpsとの関連を交えて解説

    101 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  102. CI/CDとはなんぞや? • CI • 継続的インテグレーション, Continuous Integration • CD 1.

    継続的デプロイ, Continuous Deploy 2. 継続的デリバリ, Continuous Delivery 102 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  103. CI/CDとはなんぞや CIとは CIとは、共有されたバージョンコントロール(以下、gitリ ポジトリ)にコミットされたコードに対して以下を行うこと 1. 自動ビルド 2. 自動テスト 103 (C)

    Recruit Technologies Co.,Ltd. All rights reserved. https://aws.amazon.com/jp/devops/continuous-integration/ から引用
  104. なぜCIが必要か? 104 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

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

    rights reserved. 人間は繰り返し作業が苦手なので、 繰り返し作業が得意な計算機に任せる
  107. よくある反論(1) CIがしょっちゅう壊れるのでその修正コストが高い 107 (C) Recruit Technologies Co.,Ltd. All rights reserved.

    壊れやすいCIやCIを壊しやすいアプリケーションになっている ことに問題があるのでそもそもの見直しが必要 (最後はコストとの兼ね合いだが)
  108. よくある反論(2) 開発スピードを重視したいのでテストを書くのは嫌だ 108 (C) Recruit Technologies Co.,Ltd. All rights reserved.

    君はいなくなるだろうからいいけど、 残された人間はテストのないコードをみてどう思うだろうか?
  109. よくある反論(3) 既存コードにテストがない 109 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

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

    少しづつテストを追加していき、コードの肥大化に 伴う開発スピードの低下に備える必要がある (テストのないコードにテストを追加する場合の参考例) 外部に依存したコードをテストで駆動する by 和田卓人 https://speakerdeck.com/twada/test-driven-architecture-aws-dev-day-tokyo-2018
  112. 不具合は混入してからの時間経過が長くなるほど対応コス トは増大する 112 (C) Recruit Technologies Co.,Ltd. All rights reserved.

    大量に不具合を溜め込んでから 一括で解決するよりも つどつど検知&解消を 測った方が最終的な 総コストは下がる
  113. CI/CDとはなんぞや CDとは CDでは、コード変更に伴って自動的に実稼働環境へのリ リース準備が実行される 1. 継続的デリバリ – リリースに際して人による承認が必要 2. 継続的デプロイ

    – リリースまで自動的に行われる 113 (C) Recruit Technologies Co.,Ltd. All rights reserved. https://aws.amazon.com/jp/devops/continuous-integration/ から引用
  114. CDの重要なポイント 継続的デリバリ/デプロイ共に、 程度の差こそあれ”自動”リリースであること 114 (C) Recruit Technologies Co.,Ltd. All rights

    reserved.
  115. ダブルチェックで頑張る vs デプロイのコード化 115 (C) Recruit Technologies Co.,Ltd. All rights

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

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

    reserved. デプロイ頻度が高い、かつデプロイ手順 が複雑なものから手をつける
  118. CIとCDを支える技術 118 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

  120. CIを支える技術 CIを支える様々なツールがある(主観による雑な分類です) 120 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

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

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

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

    CIパイプラインツール ビルドの支援ツール(パッケージ管理ツール含む) テストの支援ツール GNU make go test python -m unittest ビルドとテストの全体フローを自動化する (主にアプリケーションの)ビルドフローを自動化する テストフローを自動化する アプリケーションロジック記述以外から 属人性を可能な限り排除するのが目的
  125. こういう状況を排除する 125 (C) Recruit Technologies Co.,Ltd. All rights reserved. さん以外、ビルドとテストの

    方法知らない。困った…… (しかも彼は先月退職した) レビューの前にテストをパスする必要がある!? しかも結果のエビデンスもセット!? テストケースは500ケースで全部手動!? そんなん発狂するわ
  126. CIでパイプライン化されていれば 126 (C) Recruit Technologies Co.,Ltd. All rights reserved. さんいないけど、テストは実行できる

    テストのやり方もパイプラインのコードを直せばOK 500ケースのテスト結果も プルリクみればいいから楽
  127. CIでよくある問題 • テストが安定しない • テストの実行時間が長い 127 (C) Recruit Technologies Co.,Ltd.

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

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

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

    rights reserved. ビルドの独立性を高め、環境依存性を 下げることを考える 例えば、CIではDockerを使って ビルド・テストを実行する。DBも都度作る
  131. テストの実行時間が長い • テストサイズの概念を使って効率的にテストをする • テストがこける原因の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
  132. テストサイズの概念に合わせた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テスト で落とす
  133. テストサイズの概念に合わせた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のパフォーマンスを改善することで コードを書いてからフィードバックを 受けるまでの時間を短くする
  134. CIでよくある問題 • テストが安定しない • 対策 • ビルドの独立性をあげる • テストの実行時間が長い •

    対策 • CIのパフォーマンスを改善する • テストサイズの概念を導入したCIパイプライン構成 134 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  135. 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
  136. アプリケーション 構成管理 VM構成管理 環境構成管理 CDを支える技術 CDももちろんそれを支える技術が存在する (CIとかぶる部分も多々ある & 雑分類なので注意) 136

    (C) Recruit Technologies Co.,Ltd. All rights reserved. デプロイツール 構成管理
  137. CDがない場合 137 (C) Recruit Technologies Co.,Ltd. All rights reserved. 手順書に従って

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

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

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

    アプリケーションと同様に 開発・ステージング環境を使って磨き込む
  141. デプロイ品質の磨き込み 環境構成を可能な限り開発・ステージング・本番で同じものにする※ &デプロイプロセスを同一にする 141 (C) Recruit Technologies Co.,Ltd. All rights

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

    rights reserved. ※ 環境ごとにスケールは異なっても構成要素は同じにするようにしてください 本番にのみ存在するモジュールなどはなくしましょう Heisei Finalのデプロイパイプラインを ここにはる(dev-stg-prod) アプリケーションと同様に デプロイプロセスの品質向上のための手立てを打つこと
  143. CIとCDを支える技術 CIもCDの根本的な目的は主に以下の2つ 1. 人間が苦手なこと(複雑かつ正確性が求められる作業・繰り返し作業)を 計算機に任せる 2. 作業そのものに対する属人性を排除する 結果として高いレートで仮説検証サイクルを回せる (=ビジネスの成功確率をあげられる) 143

    (C) Recruit Technologies Co.,Ltd. All rights reserved.
  144. CI/CDの注意点 • CIパイプラインの注意点 • 必要に応じてCIパイプラインそのもののチューニングも必要にな ることを覚悟すること • CIパイプラインの品質がプロダクトの品質に大きな影響を与える ことを自覚すること(信用できないCIパイプラインは無視される) •

    CDの注意点 • アプリケーションコードと同様に品質の磨き込みが必要であるこ とに注意すること • デプロイプロセスの品質が高くない限り高いレートで仮説検証サ イクルを回すことは難しいという事実を理解すること 144 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  145. 時間が余ったので THE TWELVE-FACTOR APP 145 (C) Recruit Technologies Co.,Ltd. All

    rights reserved.
  146. THE TWELVE-FACTOR APPとは • セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく 加わった開発者が要する時間とコストを最小化する。 • 下層のOSへの

    依存関係を明確化 し、実行環境間での 移植性を最大化 する。 • モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理や システム管理を不要なものにする。 • 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロ イ を可能にする。 • ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアッ プ できる。 146 (C) Recruit Technologies Co.,Ltd. All rights reserved. https://12factor.net/ja/ 下記のようなSoftware as a Service(SaaS)を 作り上げるための方法論
  147. The Twelve Factors I.コードベース バージョン管理されている1つのコードベースと複 数のデプロイ II.依存関係 依存関係を明示的に宣言し分離する III.設定 設定を環境変数に格納する

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

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

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

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

    Co.,Ltd. All rights reserved. 他の人がコードを確認できないものを デプロイするのは論外 アプリケーションコードの変更なしに デプロイできるようにしておく (デプロイ時にサーバ上でvimやら開いてる = なにかおかしい)
  152. 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
  153. 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ファイルを依存関係に入れるなど
  154. III. 設定 設定をアプリケーションコードから厳密に分離できるよう にする • 単一のコードベースから複数の環境(開発/ステージング/本番)に デプロイできるようにするため 154 (C) Recruit

    Technologies Co.,Ltd. All rights reserved. 環境変数で設定を読み込み (環境変数の投入が別途コード化されているとより良い) 設定ファイルを環境ごとに切り替え (コマンドラインオプションで切り替えられるように作る) 設定ファイルをデプロイ時にサーバ上で書き換え 超えられない壁 Good No Good
  155. IV. バックエンドサービス アプリケーションがアクセスする先のリソースは場所など を意識することなくアクセスできるようにすること アプリケーションコードを変更することなく、接続先のリ ソースを変更できるようにすること • 設定変更のみで接続先を変更できるようにする (本音を言うとDNSなども含めて総合的に対応できるようにしてほしい) 155

    (C) Recruit Technologies Co.,Ltd. All rights reserved.
  156. V. ビルド・リリース・実行 ビルド・リリース・実行の3プロセスを明確に分ける 156 (C) Recruit Technologies Co.,Ltd. All rights

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

    reserved. コード 0101110 実行可能な バイナリ 設定 (ファイル or 環境変数) 設定 (ファイル or 環境変数) 0101110 実行可能な バイナリ ビルド リリース 実行 不具合検知 or 新機能要求 コード修正 ・追加 このサイクルが逆に回ること がないようにする (問題が起きた場合はサーバ上で対処ではなく、ローカルでコードを修正した上で対処する)
  158. VI. プロセス アプリケーションを1つもしくは複数のステートレスなプロ セスとして実行する • アプリケーションプロセスにはステートを持たせない • ステートを持たせる場合はRedisやMemcached、RDBに 格納する 158

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

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

    All rights reserved.
  161. IX. 廃棄容易性 1. SIGTERMシグナルを受け取った時にグレースフルに シャットダウン*できるようにする – 停止の際に複雑な手続きが要らないようにする 2. 起動時間を最小化する –

    できるだけ短時間(数秒)でリクエストやジョブを受け付けでき るようにするべき 3. 突然の死に対して堅牢であるべき 161 (C) Recruit Technologies Co.,Ltd. All rights reserved. *新規リクエストの受付を停止し、 処理中のリクエストの処理完了 を待ってからプロセスを停止する
  162. X. 開発/本番一致 開発/ステージング/本番をできるだけ一致させた状態を保つ • 構成要素は揃える • 本番にしか存在しないコンポーネントがないようにする • 仮にライセンスなどの都合でそうなっているならそもそも構成を見直すこと •

    スケールまで揃えるかは予算と相談 • 負荷試験などの都合上揃えられるようにはしておくべき • 一致していない部分は容易に確認できるようにしておくべき • パブリッククラウドであればinternal DNSをうまく活用することで 機能面では全く同じ構成になるようにできる 162 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  163. XI. ログ ログはfluentdやlogstashなどのツールを用いて特定の場所 に集約する 163 (C) Recruit Technologies Co.,Ltd. All

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

    rights reserved. 数十〜数百のサーバー 数十〜数百のサーバー 集約 ログの集約をしていない場合 ログの集約をしている場合 全員で同じものを見て議論を することも容易にする
  165. 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をその場で実行するなどの複雑な作業は させないようにすること
  166. まとめ 166 (C) Recruit Technologies Co.,Ltd. All rights reserved.

  167. DevOpsって美味しいの?どんか効果があるの? DevOpsを実践できている企業の業績 vs DevOpsを実践できていない企業 167 (C) Recruit Technologies Co.,Ltd. All

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

    rights reserved. コードのデプロイ頻度 (= 仮説検証の頻度) 46倍 コードをコミットしてから 本番デプロイまでのリードタイム 1/1440 障害からの 平均復旧時間 1/170 変更失敗率 1/5 たくさん打席に立つことが ヒットをうつ上で重要 安全に失敗しつつ、 確実に成功に繋げられるようにする
  169. なぜDevとOpsの軋轢が生まれたのか? DevとOpsでは求められているミッションが異なるため • Devのミッション • 新しい機能を追加してビジネス全体の売り上げを伸ばす • どんどん変更を加えたい • Opsのミッション

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

    • システムの安定稼働を実現してビジネス全体の売上の逸失を避ける • 変更は障害の原因になりがちなので避けたい 170 (C) Recruit Technologies Co.,Ltd. All rights reserved. ミッションの違いを理解した上で 安全に変更するための方法を考えて磨く いまはそのための道具や磨くための手法はたくさんある
  171. DevとOpsで 同じ情報ソースを使ってコミュニケーションをとる 互いのノウハウは集約 171 (C) Recruit Technologies Co.,Ltd. All rights

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

    reserved. Ops Dev 同じ情報を見て議論できるので ミスコミュニケーションは減る 集約 or 並存 は要議論 Dev視点の メトリクス Ops視点の メトリクス 組織間の情報格差をなくすことが重要 情報の集約と公開
  173. 本来はどうあるべきか DevもOpsも根っこの目的は同じ 173 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

    カスタマー&クライアントへの貢献 とそこからもたらされる ビジネスの成功と利益の拡大 そのための取り組みをどんどんやっていきましょう
  175. 参考になりそうな書籍たち 175 (C) Recruit Technologies Co.,Ltd. All rights reserved.