改めて見直すコンテナベースで作るメリット

by Recruit Technologies

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

自己紹介 (藤原涼馬) 藤原涼馬株式会社リクルートテクノロジーズ ITｴﾝｼﾞﾆｱﾘﾝｸﾞ本部ｻｰﾋﾞｽｵﾍﾟﾚｰｼｮﾝｴﾝｼﾞﾆｱﾘﾝｸﾞ部プロジェクト基盤G 経歴 2011-2015 ユーザ系SIer にてR&D 2016/1〜リクルートテクノロジーズに入社主な活動(社外含む) • コンテナ・クラウド等の先進アーキテクチャの事業への装着 • Rancher JPコアメンバー • 各種勉強会登壇 (Rancher JP meetup, Docker meetup tokyo) • 寄稿(@IT 先行事例に学ぶKubernetes 企業活用の現実) 6 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Why Concourse? • コンテナベースを前提としたアーキテクチャ • 多様な機能 • 既存時点で公式、コミュニティ含めて多様な機能が提供されている • 各機能の実装もシンプルなため機能の追加も可能 • アドホックな入力の排除 • どの環境でも同じ手順でのCI/CDを強制 • リリース時の事故を排除(人間に都度判断させない仕組み) 33 (C) Recruit Technologies Co.,Ltd. All rights reserved. Concourse

Slide 34

Slide 34 text

システム全体構成 34 (C) Recruit Technologies Co.,Ltd. All rights reserved. AWS Cloud AWS Region ap-northeast-1 VPC AZ ap-northeast-1a AZ ap-northeast-1c AZ ap-northeast-1d Public subnet Public subnet Public subnet Private subnet Private subnet Private subnet Kubernetes cluster Internet NAT gateway NAT gateway NAT gateway AWS Region us-east-1

Slide 35

Slide 35 text

システム全体構成 35 (C) Recruit Technologies Co.,Ltd. All rights reserved. AWS Cloud AWS Region ap-northeast-1 VPC AZ ap-northeast-1a AZ ap-northeast-1c AZ ap-northeast-1d Public subnet Public subnet Public subnet Private subnet Private subnet Private subnet Kubernetes cluster Internet NAT gateway NAT gateway NAT gateway AWS Region us-east-1 SQS SNS SES S3 RDS (Aurora for Postgres) Elasticache (Redis)

Slide 36

Slide 36 text

システム全体構成 36 (C) Recruit Technologies Co.,Ltd. All rights reserved. AWS Cloud AWS Region ap-northeast-1 VPC AZ ap-northeast-1a AZ ap-northeast-1c AZ ap-northeast-1d Public subnet Public subnet Public subnet Private subnet Private subnet Private subnet Kubernetes cluster Internet NAT gateway NAT gateway NAT gateway AWS Region us-east-1 SQS SNS SES S3 RDS (Aurora for Postgres) Elasticache (Redis) コンテナが得意でないもの(e.g. 永続化) や実装の手間を省いてくれるものはマネージドサービスを積極利用 (一部のロックインについては代替手段を検討・準備 or リスクとして受容)

Slide 37

Slide 37 text

システム全体構成 37 (C) Recruit Technologies Co.,Ltd. All rights reserved. AWS Cloud AWS Region ap-northeast-1 VPC AZ ap-northeast-1a AZ ap-northeast-1c AZ ap-northeast-1d Public subnet Public subnet Public subnet Private subnet Private subnet Private subnet Kubernetes cluster Internet NAT gateway NAT gateway NAT gateway AWS Region us-east-1 SQS SNS SES S3 RDS (Aurora for Postgres) Elasticache (Redis) コンテナが得意でないもの(e.g. 永続化) や実装の手間を省いてくれるものはマネージドサービスを積極利用 (一部のロックインについては代替手段を検討・準備 or リスクとして受容) あくまでも目的はビジネス目標の達成技術リスク回避がより大きなビジネスリスク (リリースの遅延など)を呼び込んではいけない

Slide 38

Slide 38 text

Slide 39

Slide 39 text

インフラアーキテクト視点のまとめ • いきなり全部盛りはNG • 組織内のアセットなどをベースにマイルストーンを定める • 組織の成熟度に応じて最適な技術スタックは異なる • 要件を満たしつつ適切な落としどころを見つける • 技術リスクを絶対視しない • 特定のリスクの回避がより大きなリスクを呼び込まないかを判断 39 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 40

Slide 40 text

Slide 41

Slide 41 text

CI(Continuous Integration/継続的インテグレーション)の役割 • 高頻度のテスト実行 • ソースコードがチェックインされるたびに自動化されたテスト、各種静的解析、ビルドのプロセスを回す。 • 欠陥の早期検出 • 上記のプロセスでエラーが引き起こされた場合、誰がそのコードをチェックインしたのかを即時に把握し、問題の解決を図ることができる。 41 (C) Recruit Technologies Co.,Ltd. All rights reserved. https://aws.amazon.com/jp/devops/continuous-integration/ http://se.rdy.jp/req_imp.html 修正コスト（工数・お金）欠陥混入からの経過時間

Slide 42

Slide 42 text

割れ窓理論 • 「長期間修理されることのない割れた窓が１枚でもあると、ビルの住人に投げやりな感覚--ビルのことなど気にもかけない感覚が植え付けられていくのです。そして次の窓が割れるのです。…」（達人プログラマーより） • 「割れた窓」（悪い設計・質の悪いコード）をそのままにしてはいけない。 42 (C) Recruit Technologies Co.,Ltd. All rights reserved. https://ja.wikipedia.org/wiki/%E5%89%B2%E3% 82%8C%E7%AA%93%E7%90%86%E8%AB%96

Slide 43

Slide 43 text

Slide 44

Slide 44 text

CI x 割れ窓理論 • ソースコードがpushされた瞬間に行われる各種のビルドプロセスで、「最初に窓が割れる瞬間」を検出することができる 44 (C) Recruit Technologies Co.,Ltd. All rights reserved. テスト実行のトリガーイメージのビルドテスト1 テスト2 テスト3 テスト結果通知 NG 変更のリポジトリへのpush CIパイプライン継続的インテグレーションプロダクトコードを健全に保つにはなくてはならない仕組み (ソースコードレビューなどは行っている前提で）

Slide 45

Slide 45 text

Slide 46

Slide 46 text

CIに求めること • 信頼性(=意図した通りにビルド・テストが実行されること) • 環境依存で失敗するようなビルド/テストがない（特にローカルでは成功するけどCIでは失敗するようなテスト） • 短時間で実行できること • 一つのビルドに時間がかかりすぎると、FBが即座に受けられない 46 (C) Recruit Technologies Co.,Ltd. All rights reserved. 上記の２つが欠けると、CIを信じないような状況が生まれる

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

環境差分で失敗するようなビルド • 環境差分の原因になりやすいもの • モジュールの初期化順に依存 • 並列数に依存 • 外界（I/O・NW通信等）に依存している • ローカルのキャッシュに依存 • 共用環境で一緒に走っているタスクに影響される • このようなビルドは環境の再現・調査が難しい • Developers Experience (= DX) の悪化要因 49 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

コンテナ技術とCIの親和性 • ビルド毎に隔離された環境を構築できる • 外界に影響されにくい環境を作る • 環境差分を極小化する • 必要に応じてCI時と同じ構成の環境を逆にローカル環境に構築することができ、調査が容易にできるようになる • DX*が圧倒的に良い 52 (C) Recruit Technologies Co.,Ltd. All rights reserved. *DX(Developmer eXperiense)… 開発者の開発プロセスにおける体感

Slide 53

Slide 53 text

コンテナ技術とCIの親和性 • ビルド毎に隔離された環境を構築できる • 外界に影響されにくい環境を作る • 環境差分を極小化する • 必要に応じてCI時と同じ構成の環境を逆にローカル環境に構築することができ、調査が容易にできるようになる • DX*が圧倒的に良い 53 (C) Recruit Technologies Co.,Ltd. All rights reserved. *DX(Developmer eXperiense)… 開発者の開発プロセスにおける体感コンテナベースで作られたCIの機運

Slide 54

Slide 54 text

コンテナベースのCIの構築 • すべてのビルド・テストをコンテナ上で実行 • ビルド・テストに必要な依存middlewareなどもコンテナでそのビルド専用に立ち上げる • 各種ビルド時に使ったコンテナ都度レジストリにPushして状態を保持 • PRごとにビルド・テスト実行

Slide 55

Slide 55 text

CIパイプラインの模式図 Pull Requestの作成テスト実行のトリガーイメージのビルドイメージのプッシュ Lintとテストテスト結果通知

Slide 56

Slide 56 text

コンテナベースのCIパイプラインを導入した効果 ① コンテナベースにしたのでそもそも環境依存でビルドが失敗することが少なくなった ② 環境依存のテストに関してもイメージリポジトリから pullしてくればよいので、原因調査が容易になった – ex) linuxとmacのpathの解決の問題など ③ 高いDX CIの信頼性は大幅に高まった

Slide 57

Slide 57 text

ビルド実行時間の問題 • テストの実行のたびにdocker build & push & pullが複数走るので、時間がかかりすぎる • パイプラインの並列度が上がるたびに実行時間は悪化 • 2時間程度かかることも

Slide 58

Slide 58 text

CIに求めること(再掲) • 信頼性(=意図した通りにビルド・テストが実行されること) • 環境依存で失敗するようなビルド/テストがない（特にローカルでは成功するけどCIでは失敗するようなテスト） • 短時間で実行できること • 一つのビルドに時間がかかりすぎると、FBが即座に受けられない 58 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 59

Slide 59 text

CIの健全化への取り組み(2つの対処) CIの改善に向けて2つの方針を定めた ① 失敗させるべきテストを早期に失敗させる – 無駄なテストを実行しないようにする ② CIパイプラインの実行速度改善 – パイプライン自体が高速で動作するようにする

Slide 60

Slide 60 text

CIの健全化への取り組み(2つの対処) CIの改善に向けて2つの方針を定めた ① 失敗させるべきテストを早期に失敗させる – 無駄なテストを実行しないようにする ② CIパイプラインの実行速度改善(あとで宮地が説明) – パイプライン時代が高速で動作するようにする

Slide 61

Slide 61 text

CIでテストが失敗する原因 • Lintや単純ミスが多い • 環境に依存しない問題 • 環境起因で落ちるテストは本当に稀 • コンテナで調査したいのはこちら

Slide 62

Slide 62 text

ビルドをできるだけ早く失敗させる • Lintや外界に依存のないテストはdocker buildで失敗させ、後続の処理の実行を不要にする(push / pull / テスト依存モジュールのビルドなど) • Test Sizesの概念を導入

Slide 63

Slide 63 text

Test Sizes Google Testing Blogより 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 64

Slide 64 text

Test Sizesの考え方を導入 • Small (外界に依存なし) → Medium / Large (依存あり)の順に実行するように • テストの起動をSmall / Mediumで分けられるようにする • ex) Goの場合、MediumのテストはTestM_で始まるなどのprefixをつける • テストが失敗する要因の大多数を占める単純ミスはSmallで見つけることができるものが多い • docker buildと同じタイミングでsmall testを回してしまう

Slide 65

Slide 65 text

Slide 66

Slide 66 text

CIパイプラインの修正結果 66 (C) Recruit Technologies Co.,Ltd. All rights reserved. テスト実行のトリガー medium テスト1 medium テスト2 medium テスト2 medium テスト結果通知イメージのビルド & small テストイメージのpush medium 依存モジュール build 可能な限り早い段階で欠陥の検出を狙う & 余分なテストを実行させない

Slide 67

Slide 67 text

アプリケーションエンジニア視点のまとめ ① CIが実際の開発に果たす役割とコンテナ環境との親和性 ② Test Sizesの導入と、段階的なテスト実行によるパイプラインの最適化 ③ 高いDXの実現

Slide 68

Slide 68 text

アプリケーションエンジニア視点のまとめ ① CIが実際の開発に果たす役割とコンテナ環境との親和性 ② Test Sizesの導入と、段階的なテスト実行によるパイプラインの最適化 ③ 高いDXの実現 CIのさらなる改善・DXの改善に向けての取り組みについては宮地が解説

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Slide 72

Slide 72 text

CI/CDアーキテクチャ概要

Slide 73

Slide 73 text

Slide 74

Slide 74 text

CI/CDアーキテクチャ概要ここが律速プロセス

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Slide 78

Slide 78 text

CIパイプラインの模式図(再掲) Pull Requestの作成テスト実行のトリガーイメージのビルドイメージのプッシュ Lintとテストテスト結果通知

Slide 79

Slide 79 text

CIパイプラインの模式図(再掲) Pull Requestの作成テスト実行のトリガーイメージのビルドイメージのプッシュ Lintとテストテスト結果通知ビルド速度に配慮のないDockerfile (モノレポ*構成・レイヤーキャッシュへの配慮の不足) 毎回全てのテストを実行開発の速度が想定よりも早い (常時複数のPRを処理・単純なスペック不足) *システムを構成する全てのコードを単一のリポジトリで管理すること

Slide 80

Slide 80 text

ビルド速度に配慮のないDockerfile 80 (C) Recruit Technologies Co.,Ltd. All rights reserved. FROM のーど:alpine RUN apk add curl COPY . ./ RUN npm i CMD [“npm”,”start] 1回目 FROM のーど:alpine RUN apk add curl COPY . ./ RUN npm i CMD [“npm”,”start] 2回目

Slide 81

Slide 81 text

ビルド速度に配慮のないDockerfile 81 (C) Recruit Technologies Co.,Ltd. All rights reserved. FROM のーど:alpine RUN apk add curl COPY . ./ RUN npm i CMD [“npm”,”start] 1回目 FROM のーど:alpine RUN apk add curl COPY . ./ RUN npm i CMD [“npm”,”start] 2回目 1回目と変わらないのでcacheを利用する

Slide 82

Slide 82 text

ビルド速度に配慮のないDockerfile 82 (C) Recruit Technologies Co.,Ltd. All rights reserved. FROM のーど:alpine RUN apk add curl COPY . ./ RUN npm i CMD [“npm”,”start] 1回目 FROM のーど:alpine RUN apk add curl COPY . ./ RUN npm i CMD [“npm”,”start] 2回目１つでもファイルに変更がある場合以降のキャッシュは使われない

Slide 83

Slide 83 text

ビルド速度に配慮のないDockerfile 83 (C) Recruit Technologies Co.,Ltd. All rights reserved. FROM のーど:alpine RUN apk add curl COPY package* ./ RUN npm i COPY . ./ CMD [“npm”,”start] 依存パッケージのインストール等、変更が極力少ないものを上に持ってくる

Slide 84

Slide 84 text

ビルド速度に配慮のないDockerfile • CI上でcacheを利用するために • なるべくbuildしたいPRに近いImageをcacheとして使う • Multi stage buildを行っている場合は中間レイヤーもちゃんと持ってくる • さらなる高速化に向けて • BuildContextを最小限に絞る • BuildKit • 各レイヤーの軽量化 84 (C) Recruit Technologies Co.,Ltd. All rights reserved. Pipelineにも修正を加えるより詳しいDocker Buildの高速化は https://speakerdeck.com/orisano/docker-build-battle

Slide 85

Slide 85 text

Slide 86

Slide 86 text

CI/CD環境の計算資源の最適化・増強 86 (C) Recruit Technologies Co.,Ltd. All rights reserved. 質的改善: ビルドに適したファイルシステムの選択 Dockerのストレージドライバは用途によって推奨されいてるものが変わるので適切なものを選択垂直増強: IO・CPU性能が高いインスタンスの活用 Buildやtest実行はCPU,IOバウンドになりやすいので i3系instanceを採用水平増強: CIワーカーの数をふやすコアタイム等PRが頻繁に発生する時間ではワーカー自体を増やす

Slide 87

Slide 87 text

Slide 88

Slide 88 text

Slide 89

Slide 89 text

Slide 90

Slide 90 text

コンテナ外との接続(アプリ-インフラ間のコミュニケーション) コミュニケーションのインタフェースを明確化するコンテナと外部サービスの接続情報*は、環境変数などを用いて後から差し込める形にコミュニケーションをとる 90 (C) Recruit Technologies Co.,Ltd. All rights reserved. 環境変数の設定をインタフェースとして詳細を詰めることで、手戻りを削減しつつ変更へのアジリティを確保する(PRごとの環境やCI上テストが行いやすく) • 接続先ホスト名 • 各種機密パスワード • 外部接続先情報 • など環境変数で注入

Slide 91

Slide 91 text

Slide 92

Slide 92 text

Slide 93

Slide 93 text

Slide 94

Slide 94 text

インフラエンジニア観点のまとめ • サービス開発で最初に運用するのはCI/CDサーバ • CI/CDサーバの安定かつ効率的な動作がモダンな開発ではプロダクト品質のカギになる • コンテナだからこそ気にする部分もある • CIサーバの各種メトリクスの取得も行い、常に計測を怠らないように • コンテナの各種特性を把握することで、安心して快適な開発環境を！ 94 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 95

Slide 95 text

Slide 96

Slide 96 text

Slide 97

Slide 97 text

Slide 98

Slide 98 text

Slide 99

Slide 99 text

Slide 100

Slide 100 text

Slide 101

Slide 101 text

② アプリ-インフラ間のコミュニケーションスコープ拡大への取り組みアジリティを生かしてプロダクト内のプロジェクト・チーム・個人に本番と同等の動作環境をオンデマンド&超ハイアジリティで提供 101 (C) Recruit Technologies Co.,Ltd. All rights reserved. 経営層とデザイナーとプロデューサーと大量プロジェクトの並行推進に対応実際にデプロイされ、動く成果物をベースに議論

Slide 102

Slide 102 text

Slide 103

Slide 103 text

残された課題システムはスケールするがこの仕組みを作る人の数がスケールしづらい問題… 103 (C) Recruit Technologies Co.,Ltd. All rights reserved. 経営層とデザイナーとプロデューサーと大量プロジェクトの並行推進に対応実際にデプロイされ、動く成果物をベースに議論このあたり、議論していただけるかたいらっしゃれば Ask the speakerブースまで是非!

Slide 104

Slide 104 text

全体まとめ • コンテナベースで高品質なCI/CDを実現した • 高いDXを実現 • エンジニアリング効率の向上 • プロダクト品質の改善 • ただし、継続的かつ地道なCI改善はずっと必要 • アプリ-インフラ間のコミュニケーションインタフェースの統一 • アプリ-インフラ間のコミュニケーション効率の改善 • 手戻りの減少・アジリティの向上 • サービス開発品質・アジリティの向上を継続して推進 • (CI改善) 工学的な手法を導入しての品質改善 • (コミュニケーション改善)非エンジニアとのコミュニケーション改善 104 (C) Recruit Technologies Co.,Ltd. All rights reserved.

Slide 105

Slide 105 text