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を実践できている企業の業績 vs DevOpsを実践できていない企業 8 (C) Recruit Technologies Co.,Ltd. All

    rights reserved. コードのデプロイ頻度 (= 仮説検証の頻度) 46倍 コードをコミットしてから 本番デプロイまでのリードタイム 1/1440 障害からの 平均復旧時間 1/170 変更失敗率 1/5 DevOpsとLeanの科学から抜粋
  7. なぜDevとOpsの軋轢があるのか DevとOpsでは求められているミッションが異なるため • Devのミッション • 新しい機能を追加してビジネス全体の売り上げを伸ばす • どんどん変更を加えたい • Opsのミッション

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

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

    • 中長期的には ノー • 人のスキルには向き不向きがある • 攻め(Dev)に強い人、守り(Ops)に強い人というのは明らかに存在す る • 角を矯めて牛を殺すといった事態は避けたい 15 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  10. なぜ自動化されたインフラが必要か(3) • 計算機は言われた通りのことを何百万回でも集中力を切 らすことなく正確に実行できる • つまり確実成功 or 失敗※ • 人間のように疲れることは(ほぼ)ない

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

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

    何万回の繰り返し作業でも平気 • 入力と出力が1対1になりやすい • ほぼ、書いたようにしか動かない 30 (C) Recruit Technologies Co.,Ltd. All rights reserved. ※特殊な訓練を受けた人は除きます 適材適所を適切に行うべき つまり、繰り返し作業は計算機に行わせるべき
  13. 共有されたバージョンコントロールがない状況を考える この状況で障害が起きた場合に適切な対応が可能か? 37 (C) Recruit Technologies Co.,Ltd. All rights reserved.

    Aさん Bさん Cさん Dさん 全員持っているコードはばらばら 古かったり新しかったり _人人人人人人人人_ > 約束された死 <  ̄Y^Y^Y^Y^Y^Y^Y  ̄
  14. [補足]インフラコードもリポジトリで管理する 1.自動化されたインフラでも述べている通りインフラはコー ドで記述し、共有されたバージョンコントロールに載せる (仮に手順書ベースとしても、リポジトリまたは文書基盤(Confluence)を通じてそれはDevと共有される) 41 (C) Recruit Technologies Co.,Ltd. All

    rights reserved. Git リポジトリ Ops Dev 情報が共有されないとヘイトが溜まりがち (互いに必要とする情報なんてわからないので勝手に判断しない) 別の共有 されていない 何か あいつら 何やってんの?(怒) Devには 関係ない話だから こっちのやり方で やる
  15. 非難のない文化を作ることを助ける 人間はミスをするので、計算機に仕事をさせる。 計算機に入れる入力(ビルド、デプロイのパイプライン)はD 複数人以上で確認する(できればDevとOpsまたがる形で) 47 (C) Recruit Technologies Co.,Ltd. All

    rights reserved. Dev Ops ①パイプラインを レビューする ②パイプラインを デプロイする ③デプロイ作業を 実施する ④成否の振り返り と確認 Ops Dev 人間が細々とした作業をデプロイ時にしないので、 問題が起きても冷静かつ建設的な議論がしやすい傾向 (コード通りにデプロイは行われていることが確証できるのが大きい)
  16. ワンステップビルドとデプロイがない場合(1/2) ワンステップビルドとデプロイがない場合 49 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

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

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

    今日はリリース作業ですね ですね。デプロイボタン押します (Bさんいないけど自動化されてるのでやれる) できた Aさん うぇーい
  20. フィーチャーフラグとは 特定の機能を有効化したり一部の人にのみ提供するための フラグ。これを提供することで下記を実現できるようにす る。 • プライベートベータ • 一部の”指定したユーザにのみ”機能を公開する • A/Bテスト

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

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

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

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

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

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

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

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

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

    reserved. 小さく始める まずは全体の10% からやっていこうか 失敗 成功 スコープを広げる 次は50%いこうか 傷が浅くて よかったね 振り返って 次の施策を 考えましょ 冷静に振り返って 次に繋げる 被害が小さいので冷静に振り返りができる
  30. よくある話 DevとOpsで違う指標を見ている 67 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

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

    reserved. Ops Dev 同じ情報を見て議論できるので ミスコミュニケーションは減る 集約 or 並存 は要議論 Dev視点の メトリクス Ops視点の メトリクス
  33. DepOps文化の確立を支援するテクノロジーまとめ 75 (C) Recruit Technologies Co.,Ltd. All rights reserved. 安全に仮説検証する仕組み作り

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

    属人性の軽減・排除 コミュニケーションの円滑化 自動化されたインフラ 共有されたバージョンコントロール ワンステップビルドとデプロイ フィーチャーフラグ 共有されたメトリクス 共有されたメトリクス DevとOpsが適切にコミュニケーションしつつ、 互いのヘイトを溜めない仕組みづくりが重要 結果互いの強みを組み合わせてシナジー効果を出す
  35. DevOpsの確立に必要な組織文化 1. リスペクトしあうこと 2. 互いに信頼すること 3. 失敗に対して健全な態度をとること 4. 個人を非難しないこと 80

    (C) Recruit Technologies Co.,Ltd. All rights reserved. もちろんこれは、DevおよびOpsそれぞれの 構成メンバーが、責任を持って全力を尽くすことが前提 & 後段の文化は前段を前提とする (例えば2は1を前提とする)
  36. 先入観を持たない • いつもxxxなのでyyyしようはNG • 時間が経てば人の中身は変わる & 状況も変わる • 人の中身が変わらないというのはその人の成長の可能性を信頼し ていない

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

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

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

    すこと • 拒否する際には依頼に対するWhyも掘り下げること • 掘り下げる中で真の目的を達成する他の方法が提案できるかもし れない 87 (C) Recruit Technologies Co.,Ltd. All rights reserved. 協力の姿勢を崩さないこと (最終目的はDevもOpsも同じ)
  40. (DevはOpsに)依頼する前にやれる事をきちんとやっておく事 • きちんとできることはやり尽くした上で依頼する • 依頼する際にやっておくべきこと 1. 何を変更するか 2. 変更に伴うリスク 3.

    変更の成功・失敗の判断基準と連絡方法 4. 失敗時の対応方針 89 (C) Recruit Technologies Co.,Ltd. All rights reserved. 1, 2 は必須(もちろんOpsに意見を求めるのはWelcome) 3,4は意見を出し合ってすり合わせ
  41. 2. 信頼すること 信頼関係を確立できていない状態では健全な関係は作れな い 91 (C) Recruit Technologies Co.,Ltd. All

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

    (C) Recruit Technologies Co.,Ltd. All rights reserved. 互いにそれぞれの専門領域において リスペクトしあうこと Devでもできる事を無理にOpsがする必要はない DevとOpsは互いに補完しあう関係であり、 互いの長所を活かしあう仕組みにしない生き残れない
  43. 3. 失敗に対する健全な態度 • 失敗は“必ず起きる”ものだという意識を持つ事 • 失敗の確率を下げるために”経済的・工数的に合理的な範囲”で 最善を作ることはもちろん必要 • 失敗を回避する事を考え続けている限り、失敗に対応す る能力は向上しない

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

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

    Recruit Technologies Co.,Ltd. All rights reserved. 失敗は必ず起きるので、 “仕組みとしてどう軽減・回避するか” を対策として考えた方が良い
  46. DevOps導入指南 ~技術編~ 100 (C) Recruit Technologies Co.,Ltd. All rights reserved.

    ITエンジニアリング本部 プロダクティビティエンジニアリング部 クラウドアーキテクトG 藤原 涼馬
  47. CI/CDとはなんぞや? • CI • 継続的インテグレーション, Continuous Integration • CD 1.

    継続的デプロイ, Continuous Deploy 2. 継続的デリバリ, Continuous Delivery 102 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  48. なぜCIが必要か • 常に同じ手順でビルドとテストを繰り返し行えるように するため 106 (C) Recruit Technologies Co.,Ltd. All

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

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

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

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

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

    – リリースまで自動的に行われる 113 (C) Recruit Technologies Co.,Ltd. All rights reserved. https://aws.amazon.com/jp/devops/continuous-integration/ から引用
  54. ダブルチェックで頑張る vs デプロイのコード化 115 (C) Recruit Technologies Co.,Ltd. All rights

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

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

    reserved. デプロイ頻度が高い、かつデプロイ手順 が複雑なものから手をつける
  57. CIを支える技術 CIを支える様々なツールがある(主観による雑な分類です) 120 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

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

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

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

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

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

    テストのやり方もパイプラインのコードを直せばOK 500ケースのテスト結果も プルリクみればいいから楽
  64. テストが安定しない • 過去のビルドにおける副生成物・副作用によってテスト が安定しない(放置された中間ファイルやDBの状態などに起因) 130 (C) Recruit Technologies Co.,Ltd. All

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

    対策 • CIのパフォーマンスを改善する • テストサイズの概念を導入したCIパイプライン構成 134 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  69. 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
  70. CDがない場合 137 (C) Recruit Technologies Co.,Ltd. All rights reserved. 手順書に従って

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

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

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

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

    rights reserved. ※ 環境ごとにスケールは異なっても構成要素は同じにするようにしてください 本番にのみ存在するモジュールなどはなくしましょう Heisei Finalのデプロイパイプラインを ここにはる(dev-stg-prod) アプリケーションと同様に デプロイプロセスの品質向上のための手立てを打つこと
  75. CI/CDの注意点 • CIパイプラインの注意点 • 必要に応じてCIパイプラインそのもののチューニングも必要にな ることを覚悟すること • CIパイプラインの品質がプロダクトの品質に大きな影響を与える ことを自覚すること(信用できないCIパイプラインは無視される) •

    CDの注意点 • アプリケーションコードと同様に品質の磨き込みが必要であるこ とに注意すること • デプロイプロセスの品質が高くない限り高いレートで仮説検証サ イクルを回すことは難しいという事実を理解すること 144 (C) Recruit Technologies Co.,Ltd. All rights reserved.
  76. THE TWELVE-FACTOR APPとは • セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく 加わった開発者が要する時間とコストを最小化する。 • 下層のOSへの

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

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

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

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

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

    Technologies Co.,Ltd. All rights reserved. 環境変数で設定を読み込み (環境変数の投入が別途コード化されているとより良い) 設定ファイルを環境ごとに切り替え (コマンドラインオプションで切り替えられるように作る) 設定ファイルをデプロイ時にサーバ上で書き換え 超えられない壁 Good No Good
  84. V. ビルド・リリース・実行 ビルド・リリース・実行の3プロセスを明確に分ける 156 (C) Recruit Technologies Co.,Ltd. All rights

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

    reserved. コード 0101110 実行可能な バイナリ 設定 (ファイル or 環境変数) 設定 (ファイル or 環境変数) 0101110 実行可能な バイナリ ビルド リリース 実行 不具合検知 or 新機能要求 コード修正 ・追加 このサイクルが逆に回ること がないようにする (問題が起きた場合はサーバ上で対処ではなく、ローカルでコードを修正した上で対処する)
  86. IX. 廃棄容易性 1. SIGTERMシグナルを受け取った時にグレースフルに シャットダウン*できるようにする – 停止の際に複雑な手続きが要らないようにする 2. 起動時間を最小化する –

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

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

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

    rights reserved. 数十〜数百のサーバー 数十〜数百のサーバー 集約 ログの集約をしていない場合 ログの集約をしている場合 全員で同じものを見て議論を することも容易にする
  90. 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をその場で実行するなどの複雑な作業は させないようにすること
  91. DevOpsって美味しいの?どんか効果があるの? DevOpsを実践できている企業の業績 vs DevOpsを実践できていない企業 167 (C) Recruit Technologies Co.,Ltd. All

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

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

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

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

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

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

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

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