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

2018/12/4 Japan Container Daysでの、藤原・伊藤・宮地の講演資料になります

Transcript

1. JapanContainerDays v1812資料 改めて見直すコンテナベース で作るメリット 〜安心して開発を回す技術的ポイント〜 1 (C) Recruit Technologies Co.,Ltd. All rights reserved. 株式会社リクルートテクノロジーズ 藤原 涼馬・伊藤 瑛・宮地 克弥
2. 会社紹介: リクルート 2 (C) Recruit Technologies Co.,Ltd. All rights reserved.
3. 事業内容の紹介 3 (C) Recruit Technologies Co.,Ltd. All rights reserved.
4. 所属組織の紹介:リクルートテクノロジーズ 4 (C) Recruit Technologies Co.,Ltd. All rights reserved. リクルートグループのビジネス・サービス リクルートテクノロジーズ IT・マーケティング ソリューション ビジネス視点の ITマネジメント 横断的にソリューションを提供 上記は対象企業・サービスの一部抜粋です。
5. 注意 5 (C) Recruit Technologies Co.,Ltd. All rights reserved. 本発表内容は特定プロジェクトにおける 成果と今後取り組みたい事柄について プロジェクトのメンバーが技術的観点から 整理したものであり、 所属組織としての全体方針を 表すものではありません
6. 自己紹介 (藤原 涼馬) 藤原 涼馬 株式会社リクルートテクノロジーズ 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.
7. 自己紹介(伊藤 瑛) 伊藤 瑛 株式会社リクルートテクノロジーズ ITｴﾝｼﾞﾆｱﾘﾝｸﾞ本部ﾌﾟﾛﾀﾞｸﾄｴﾝｼﾞﾆｱﾘﾝｸﾞ部 アプリケーションソリューションG 経歴 2015年 入社 主な活動 • フロントエンド・サーバサイドの先進テクノロジ装着 • アプリケーションアーキテクティング 7 (C) Recruit Technologies Co.,Ltd. All rights reserved.
8. 自己紹介(宮地 克弥) 宮地 克弥 株式会社リクルートテクノロジーズ ITｴﾝｼﾞﾆｱﾘﾝｸﾞ本部ｻｰﾋﾞｽｵﾍﾟﾚｰｼｮﾝｴﾝｼﾞﾆｱﾘﾝｸﾞ部 プロジェクト基盤G 経歴 2017年 入社 主な活動 • クラウド等先進アーキテクチャの事業への装着 • 社内ISUCON, 勉強会運営コアメンバー 8 (C) Recruit Technologies Co.,Ltd. All rights reserved.
9. 本日のアジェンダ 事例となるサービス インフラアーキテクト視点 アプリケーションエンジニア視点 インフラ・運用エンジニア視点 9 (C) Recruit Technologies Co.,Ltd. All rights reserved.
10. 事例となるサービスの説明(ジョブオプLite) 10 (C) Recruit Technologies Co.,Ltd. All rights reserved. 無償の応募管理 & 採用ホームページ作成サービス
11. 11 (C) Recruit Technologies Co.,Ltd. All rights reserved. インフラアーキテクト観点
12. 前提 12 (C) Recruit Technologies Co.,Ltd. All rights reserved. コンテナベースで作る (一般的なコンテナ活用のメリット等については、 先行事例に学ぶKubernetes企業活用の現実*を参照) * http://www.atmarkit.co.jp/ait/series/9283/
13. 新規技術に取り組む際の留意事項 いきなり全部盛りは事故のもと 13 (C) Recruit Technologies Co.,Ltd. All rights reserved.
14. CLOUD NATIVE TRAIL MAP 14 (C) Recruit Technologies Co.,Ltd. All rights reserved.
15. CLOUD NATIVE TRAIL MAP 15 (C) Recruit Technologies Co.,Ltd. All rights reserved.
16. CLOUD NATIVE TRAIL MAP 16 (C) Recruit Technologies Co.,Ltd. All rights reserved. マイルストーンを定める 1. コンテナ化 2. 継続的インテグレーション/デプロイ・デリバリ 3. オーケストレーション& アプリケーション定義 4. 観測性 & 分析
17. CLOUD NATIVE TRAIL MAP 17 (C) Recruit Technologies Co.,Ltd. All rights reserved. 判断ポイント ①既存の技術スタック(どこまで経験・知見があるか) ②メンバーの数と習熟度 ③開発期間
18. ① 既存の技術スタック 18 (C) Recruit Technologies Co.,Ltd. All rights reserved. Dockerは経験あり CIはJenkinsなら… Swarm, Cattleは経験あり Datadogの利用実績あり
19. インフラアーキテクト視点 インフラ面の要件 1. 短時間で必要な構成・計算リソースの確保 2. ロックインをできる限り回避 3. “中期的視点”での運用コストの削減 19 (C) Recruit Technologies Co.,Ltd. All rights reserved.
20. インフラアーキテクト視点 インフラ面の要件 1. 短時間で必要な構成・計算リソースの確保 20 (C) Recruit Technologies Co.,Ltd. All rights reserved. インフラの提供が アプリケーション開発の 足かせにならないようにする
21. インフラアーキテクト視点 インフラ面の要件 2. ロックインをできる限り回避 21 (C) Recruit Technologies Co.,Ltd. All rights reserved. なにかあってもアプリケーションを 他の環境で動かせるようにする
22. インフラアーキテクト視点 インフラ面の要件 3. “中期的視点”での運用コストの削減 22 (C) Recruit Technologies Co.,Ltd. All rights reserved. サービスの発展に 本質的ではないものに 手間はかけない
23. 1. 短時間で必要な構成・計算リソースの確保 23 (C) Recruit Technologies Co.,Ltd. All rights reserved. オンプレミス パブリック クラウド or
24. 1. 短時間で必要な構成・計算リソースの確保 24 (C) Recruit Technologies Co.,Ltd. All rights reserved. オンプレミス パブリック クラウド or
25. 2. ロックインをできる限り回避 25 (C) Recruit Technologies Co.,Ltd. All rights reserved. or
26. 2. ロックインをできる限り回避 26 (C) Recruit Technologies Co.,Ltd. All rights reserved. or • Kubernetesを活用してロックインを回避 • 他のクラウド環境でも知見が可能な限り活かせるように • デファクトスタンダード • AWS 東京リージョンにEKSがなかったのでk8s on EC2
27. 3. 中期視点でのコスト削減 27 (C) Recruit Technologies Co.,Ltd. All rights reserved. Concourse 監視・モニタリング CI/CD
28. 3. 中期視点でのコスト削減(監視・モニタリング) 28 (C) Recruit Technologies Co.,Ltd. All rights reserved. Prometheus 選定ポイント • 既存サービスの利用実績 • 監視・モニタリング基盤の運用コスト
29. 3. 中期視点でのコスト削減(CI/CD) 29 (C) Recruit Technologies Co.,Ltd. All rights reserved. Concourse
30. 3. 中期視点でのコスト削減(CI/CD) 30 (C) Recruit Technologies Co.,Ltd. All rights reserved. Concourse
31. Why not Circle CI • 1.x → 2.xへの過渡期 • 当時ドキュメント等が不足(2017年末時点) • ライセンスコスト • Enterprise版の価格感がプロジェクト予算と見合わなかった 31 (C) Recruit Technologies Co.,Ltd. All rights reserved.
32. Why not Jenkins • Jenkinsのバージョンアップの辛さからの解放 • アドオンを追加した結果バージョンアップできなくなる課題感が あった • コンテナネイティブなCI/CDパイプライン • コンテナ環境を前提としたCI/CDパイプラインが欲しかった 32 (C) Recruit Technologies Co.,Ltd. All rights reserved.
33. Why Concourse? • コンテナベースを前提としたアーキテクチャ • 多様な機能 • 既存時点で公式、コミュニティ含めて多様な機能が提供されている • 各機能の実装もシンプルなため機能の追加も可能 • アドホックな入力の排除 • どの環境でも同じ手順でのCI/CDを強制 • リリース時の事故を排除(人間に都度判断させない仕組み) 33 (C) Recruit Technologies Co.,Ltd. All rights reserved. Concourse
34. システム全体構成 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
35. システム全体構成 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)
36. システム全体構成 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 リスクとして受容)
37. システム全体構成 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 リスクとして受容) あくまでも目的は ビジネス目標の達成 技術リスク回避がより大きなビジネスリスク (リリースの遅延など)を呼び込んではいけない
38. インフラアーキテクト視点のまとめ • いきなり全部盛りはNG • 組織内のアセットなどをベースにマイルストーンを定める • 要件を満たしつつ適切な落としどころを見つける • 技術リスクを絶対視しない 38 (C) Recruit Technologies Co.,Ltd. All rights reserved.
39. インフラアーキテクト視点のまとめ • いきなり全部盛りはNG • 組織内のアセットなどをベースにマイルストーンを定める • 組織の成熟度に応じて最適な技術スタックは異なる • 要件を満たしつつ適切な落としどころを見つける • 技術リスクを絶対視しない • 特定のリスクの回避がより大きなリスクを呼び込まないかを判断 39 (C) Recruit Technologies Co.,Ltd. All rights reserved.
40. 40 (C) Recruit Technologies Co.,Ltd. All rights reserved. アプリケーション エンジニア視点
41. 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 修 正 コ ス ト （ 工 数 ・ お 金 ） 欠陥混入からの経過時間
42. 割れ窓理論 • 「長期間修理されることのない割れた窓が１枚でもある と、ビルの住人に投げやりな感覚--ビルのことなど気に もかけない感覚が植え付けられていくのです。そして次 の窓が割れるのです。…」（達人プログラマーより） • 「割れた窓」（悪い設計・質の悪いコード）をそのまま にしてはいけない。 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
43. CI x 割れ窓理論 • ソースコードがpushされた瞬間に行われる各種のビルド プロセスで、「最初に窓が割れる瞬間」を検出すること ができる 43 (C) Recruit Technologies Co.,Ltd. All rights reserved. テスト実行 のトリガー イメージ のビルド テスト1 テスト2 テスト3 テスト結果 通知 NG 変更のリポジトリ へのpush CIパイプライン
44. CI x 割れ窓理論 • ソースコードがpushされた瞬間に行われる各種のビルド プロセスで、「最初に窓が割れる瞬間」を検出すること ができる 44 (C) Recruit Technologies Co.,Ltd. All rights reserved. テスト実行 のトリガー イメージ のビルド テスト1 テスト2 テスト3 テスト結果 通知 NG 変更のリポジトリ へのpush CIパイプライン 継続的インテグレーション プロダクトコードを健全に保つにはなくてはならない仕組み (ソースコードレビューなどは行っている前提で）
45. CIに求めること • 信頼性(=意図した通りにビルド・テストが実行されること) • 環境依存で失敗するようなビルド/テストがない （特にローカルでは成功するけどCIでは失敗するようなテスト） • 短時間で実行できること • 一つのビルドに時間がかかりすぎると、FBが即座に受けられない 45 (C) Recruit Technologies Co.,Ltd. All rights reserved.
46. CIに求めること • 信頼性(=意図した通りにビルド・テストが実行されること) • 環境依存で失敗するようなビルド/テストがない （特にローカルでは成功するけどCIでは失敗するようなテスト） • 短時間で実行できること • 一つのビルドに時間がかかりすぎると、FBが即座に受けられない 46 (C) Recruit Technologies Co.,Ltd. All rights reserved. 上記の２つが欠けると、CIを信じないような状況が生まれる
47. CIの信頼性を下げる主な要因 環境差分 47 (C) Recruit Technologies Co.,Ltd. All rights reserved.
48. CIの信頼性を下げる主な要因 環境差分 48 (C) Recruit Technologies Co.,Ltd. All rights reserved. • ローカル環境 - CI環境の差分
49. 環境差分で失敗するようなビルド • 環境差分の原因になりやすいもの • モジュールの初期化順に依存 • 並列数に依存 • 外界（I/O・NW通信等）に依存している • ローカルのキャッシュに依存 • 共用環境で一緒に走っているタスクに影響される • このようなビルドは環境の再現・調査が難しい • Developers Experience (= DX) の悪化要因 49 (C) Recruit Technologies Co.,Ltd. All rights reserved.
50. CIの信頼性が失われるとおこること • よくある例 • 「このテストはローカルでは通過するが、 CIだと落ちてしまう。」 • この状況が長く続くと、CIの実行結果を誰も信じなくなる • CIにおける割れ窓の検出が難しくなる 50 (C) Recruit Technologies Co.,Ltd. All rights reserved.
51. CIの信頼性が失われるとおこること • よくある例 • 「このテストはローカルでは通過するが、 CIだと落ちてしまう。」 • この状況が長く続くと、CIの実行結果を誰も信じなくなる • CIにおける割れ窓の検出が難しくなる 51 (C) Recruit Technologies Co.,Ltd. All rights reserved. プロジェクトのソースコードの健全性が損なわれる
52. コンテナ技術とCIの親和性 • ビルド毎に隔離された環境を構築できる • 外界に影響されにくい環境を作る • 環境差分を極小化する • 必要に応じてCI時と同じ構成の環境を逆にローカル環境 に構築することができ、調査が容易にできるようになる • DX*が圧倒的に良い 52 (C) Recruit Technologies Co.,Ltd. All rights reserved. *DX(Developmer eXperiense)… 開発者の開発プロセスにおける体感
53. コンテナ技術とCIの親和性 • ビルド毎に隔離された環境を構築できる • 外界に影響されにくい環境を作る • 環境差分を極小化する • 必要に応じてCI時と同じ構成の環境を逆にローカル環境 に構築することができ、調査が容易にできるようになる • DX*が圧倒的に良い 53 (C) Recruit Technologies Co.,Ltd. All rights reserved. *DX(Developmer eXperiense)… 開発者の開発プロセスにおける体感 コンテナベースで作られたCIの機運
54. コンテナベースのCIの構築 • すべてのビルド・テストをコンテナ上で実行 • ビルド・テストに必要な依存middlewareなどもコンテナでその ビルド専用に立ち上げる • 各種ビルド時に使ったコンテナ都度レジストリにPushし て状態を保持 • PRごとにビルド・テスト実行
55. CIパイプラインの模式図 Pull Requestの作成 テスト実行 のトリガー イメージ のビルド イメージ のプッシュ Lintと テスト テスト結果 通知
56. コンテナベースのCIパイプラインを導入した効果 ① コンテナベースにしたのでそもそも環境依存でビルドが 失敗することが少なくなった ② 環境依存のテストに関してもイメージリポジトリから pullしてくればよいので、原因調査が容易になった – ex) linuxとmacのpathの解決の問題など ③ 高いDX CIの信頼性は大幅に高まった
57. ビルド実行時間の問題 • テストの実行のたびにdocker build & push & pullが複 数走るので、時間がかかりすぎる • パイプラインの並列度が上がるたびに実行時間は悪化 • 2時間程度かかることも
58. CIに求めること(再掲) • 信頼性(=意図した通りにビルド・テストが実行されること) • 環境依存で失敗するようなビルド/テストがない （特にローカルでは成功するけどCIでは失敗するようなテスト） • 短時間で実行できること • 一つのビルドに時間がかかりすぎると、FBが即座に受けられない 58 (C) Recruit Technologies Co.,Ltd. All rights reserved.
59. CIの健全化への取り組み(2つの対処) CIの改善に向けて2つの方針を定めた ① 失敗させるべきテストを早期に失敗させる – 無駄なテストを実行しないようにする ② CIパイプラインの実行速度改善 – パイプライン自体が高速で動作するようにする
60. CIの健全化への取り組み(2つの対処) CIの改善に向けて2つの方針を定めた ① 失敗させるべきテストを早期に失敗させる – 無駄なテストを実行しないようにする ② CIパイプラインの実行速度改善(あとで宮地が説明) – パイプライン時代が高速で動作するようにする
61. CIでテストが失敗する原因 • Lintや単純ミスが多い • 環境に依存しない問題 • 環境起因で落ちるテストは本当に稀 • コンテナで調査したいのはこちら
62. ビルドをできるだけ早く失敗させる • Lintや外界に依存のないテストはdocker buildで失敗さ せ、後続の処理の実行を不要にする(push / pull / テスト依存モジュー ルのビルドなど) • Test Sizesの概念を導入
63. 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
64. Test Sizesの考え方を導入 • Small (外界に依存なし) → Medium / Large (依存あり)の 順に実行するように • テストの起動をSmall / Mediumで分けられるようにする • ex) Goの場合、MediumのテストはTestM_で始まるなどのprefixをつけ る • テストが失敗する要因の大多数を占める単純ミスはSmallで見つけ ることができるものが多い • docker buildと同じタイミングでsmall testを回してしま う
65. CIパイプラインの修正結果 65 (C) Recruit Technologies Co.,Ltd. All rights reserved. テスト 実行の トリガー medium テスト1 medium テスト2 medium テスト2 medium テスト 結果通知 イメージ のビルド & small テスト イメージ のpush medium 依存モ ジュール build
66. CIパイプラインの修正結果 66 (C) Recruit Technologies Co.,Ltd. All rights reserved. テスト 実行の トリガー medium テスト1 medium テスト2 medium テスト2 medium テスト 結果通知 イメージ のビルド & small テスト イメージ のpush medium 依存モ ジュール build 可能な限り早い段階で欠陥の検出を狙う & 余分なテストを実行させない
67. アプリケーションエンジニア視点のまとめ ① CIが実際の開発に果たす役割とコンテナ環境と の親和性 ② Test Sizesの導入と、段階的なテスト実行によ るパイプラインの最適化 ③ 高いDXの実現
68. アプリケーションエンジニア視点のまとめ ① CIが実際の開発に果たす役割とコンテナ環境と の親和性 ② Test Sizesの導入と、段階的なテスト実行によ るパイプラインの最適化 ③ 高いDXの実現 CIのさらなる改善・DXの改善に向けての取り組み については宮地が解説
69. 69 (C) Recruit Technologies Co.,Ltd. All rights reserved. インフラエンジニア視点
70. アジェンダ(インフラエンジニア視点) • CI改善への取り組み • 更に安心して開発を回すために 70 (C) Recruit Technologies Co.,Ltd. All rights reserved.
71. 71 (C) Recruit Technologies Co.,Ltd. All rights reserved. CI改善への取り組み
72. CI/CDアーキテクチャ概要
73. CI/CD・ワンボタンでのデプロイ環境を実現したが… 機能面ではモダンな環境 非機能面で課題があった 73 (C) Recruit Technologies Co.,Ltd. All rights reserved.
74. CI/CDアーキテクチャ概要 ここが律速プロセス
75. 非機能面の課題 CIサイクルの長さ • 1回のPRのテスト完了までに2時間以上かかる ケースが発生 75 (C) Recruit Technologies Co.,Ltd. All rights reserved.
76. CIサイクルの長期化の悪影響 • 開発効率の低下 • 大量のPRが処理されることなく滞留 • masterブランチが壊れる • (急ぎの場合などに)CIの実行完了を待たずしてマージ 76 (C) Recruit Technologies Co.,Ltd. All rights reserved.
77. CIサイクルの長期化の悪影響 • 開発効率の低下 • 大量のPRが処理されることなく滞留 • masterブランチが壊れる • (急ぎの場合などに)CIの実行完了を待たずしてマージ 77 (C) Recruit Technologies Co.,Ltd. All rights reserved. 抜本的な対策が必要なため 改善活動を実施
78. CIパイプラインの模式図(再掲) Pull Requestの作成 テスト実行 のトリガー イメージ のビルド イメージ のプッシュ Lintと テスト テスト結果 通知
79. CIパイプラインの模式図(再掲) Pull Requestの作成 テスト実行 のトリガー イメージ のビルド イメージ のプッシュ Lintと テスト テスト結果 通知 ビルド速度に配慮のないDockerfile (モノレポ*構成・レイヤーキャッシュへの配慮の不足) 毎回全てのテストを実行 開発の速度が想定よりも早い (常時複数のPRを処理・単純なスペック不足) *システムを構成する全てのコードを単一のリポジトリで管理すること
80. ビルド速度に配慮のない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回目
81. ビルド速度に配慮のない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を利用する
82. ビルド速度に配慮のない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回目 １つでもファイルに変更がある場合 以降のキャッシュは使われない
83. ビルド速度に配慮のない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] 依存パッケージのインストール等、 変更が極力少ないものを上に持ってくる
84. ビルド速度に配慮のない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
85. CIパイプラインの修正(再掲) 85 (C) Recruit Technologies Co.,Ltd. All rights reserved. テスト 実行の トリガー medium テスト1 medium テスト2 medium テスト2 medium テスト 結果通知 イメージ のビルド & small テスト イメージ のpush medium 依存モ ジュール build
86. CI/CD環境の計算資源の最適化・増強 86 (C) Recruit Technologies Co.,Ltd. All rights reserved. 質的改善: ビルドに適したファイルシステムの選択 Dockerのストレージドライバは用途によって推奨されいてるものが 変わるので適切なものを選択 垂直増強: IO・CPU性能が高いインスタンスの活用 Buildやtest実行はCPU,IOバウンドになりやすいので i3系instanceを採用 水平増強: CIワーカーの数をふやす コアタイム等PRが頻繁に発生する時間ではワーカー自体を増やす
87. 87 (C) Recruit Technologies Co.,Ltd. All rights reserved. 1回のPRテスト時間 2時間以上 -> 10分程度に
88. 88 (C) Recruit Technologies Co.,Ltd. All rights reserved. 更に安心して開発を回すために -安全・確実なリリース-
89. ２つの要点 ① アプリ - インフラ間のコミュニケーション ② 継続的デプロイ 89 (C) Recruit Technologies Co.,Ltd. All rights reserved.
90. コンテナ外との接続(アプリ-インフラ間のコミュニケーション) コミュニケーションのインタフェースを明確化する コンテナと外部サービスの接続情報*は、環境変数などを用 いて後から差し込める形にコミュニケーションをとる 90 (C) Recruit Technologies Co.,Ltd. All rights reserved. 環境変数の設定をインタフェースとして 詳細を詰めることで、手戻りを削減しつつ変更への アジリティを確保する(PRごとの環境やCI上テストが行いやすく) • 接続先ホスト名 • 各種機密パスワード • 外部接続先情報 • など 環境変数で注入
91. デプロイ手順の統一 (継続的デプロイ) ① 環境問わず同じ手順でデプロイできるように ② 手順を簡略化することで誰でもデプロイできるように 91 (C) Recruit Technologies Co.,Ltd. All rights reserved.
92. デプロイ手順の統一 (継続的デプロイ) ① 環境問わず同じ手順でデプロイできるように ② 手順を簡略化することで誰でもデプロイできるように 92 (C) Recruit Technologies Co.,Ltd. All rights reserved. 開発環境でデプロイプロセスを磨き込む 自信をもって本番環境にデプロイ
93. デプロイ手順の統一 (継続的デプロイ) ① 環境問わず同じ手順でデプロイできるように ② 手順を簡略化することで誰でもデプロイできるように 93 (C) Recruit Technologies Co.,Ltd. All rights reserved. 属人性を排除して安定した開発・リリース効率を実現 開発環境でデプロイプロセスを磨き込む 自信をもって本番環境にデプロイ
94. インフラエンジニア観点のまとめ • サービス開発で最初に運用するのはCI/CDサーバ • CI/CDサーバの安定かつ効率的な動作がモダンな開発ではプロダ クト品質のカギになる • コンテナだからこそ気にする部分もある • CIサーバの各種メトリクスの取得も行い、常に計測を怠らないよ うに • コンテナの各種特性を把握することで、安心して快適な 開発環境を！ 94 (C) Recruit Technologies Co.,Ltd. All rights reserved.
95. 95 (C) Recruit Technologies Co.,Ltd. All rights reserved. まとめ・これから・残課題
96. ここまでとこれから ここまでは2つに絞った話 96 (C) Recruit Technologies Co.,Ltd. All rights reserved. コンテナの利点を生かして ①プロダクトコードの品質向上 ②アプリ-インフラ間のコミュニケーション をいかに向上するかという話
97. ここまでとこれから ここまでは2つに絞った話 97 (C) Recruit Technologies Co.,Ltd. All rights reserved. コンテナの利点を生かして ①プロダクトコードの品質向上 ②アプリ-インフラ間のコミュニケーション をいかに向上するかという話 さらに推し進める スコープを拡大
98. ① プロダクトコードの品質向上への取り組み CIのパイプラインに工学的なコード分析・計測の仕組みを追 加したい 98 (C) Recruit Technologies Co.,Ltd. All rights reserved. 不要テストコード検出
99. ① プロダクトコードの品質向上への取り組み CIのパイプラインに工学的なコード分析・計測の仕組みを追 加したい 99 (C) Recruit Technologies Co.,Ltd. All rights reserved. 不要テストコード検出 CIおよび環境のコード化を推し進めたからこそトライできる (間違っていてもすぐにCIや環境をロールバックできるためチャレンジの土台ができた)
100. ② アプリ-インフラ間のコミュニケーション スコープ拡大への取り組み コミュニケーションのスコープを拡大する 100 (C) Recruit Technologies Co.,Ltd. All rights reserved. 現在 エンジニア間 コミュニケーション これから エンジニア ー非エンジニア間 コミュニケーション
101. ② アプリ-インフラ間のコミュニケーション スコープ拡大への取り組み アジリティを生かしてプロダクト内のプロジェクト・チーム・個人に 本番と同等の動作環境をオンデマンド&超ハイアジリティで提供 101 (C) Recruit Technologies Co.,Ltd. All rights reserved. 経営層と デザイナーと プロデューサーと 大量プロジェクトの並行推進に対応 実際にデプロイされ、 動く成果物をベースに議論
102. 残された課題 システムはスケールするがこの仕組みを 作る人の数がスケールしづらい問題… 102 (C) Recruit Technologies Co.,Ltd. All rights reserved. 経営層と デザイナーと プロデューサーと 大量プロジェクトの並行推進に対応 実際にデプロイされ、 動く成果物をベースに議論
103. 残された課題 システムはスケールするがこの仕組みを 作る人の数がスケールしづらい問題… 103 (C) Recruit Technologies Co.,Ltd. All rights reserved. 経営層と デザイナーと プロデューサーと 大量プロジェクトの並行推進に対応 実際にデプロイされ、 動く成果物をベースに議論 このあたり、議論していただけるかたいらっしゃれば Ask the speakerブースまで是非!
104. 全体まとめ • コンテナベースで高品質なCI/CDを実現した • 高いDXを実現 • エンジニアリング効率の向上 • プロダクト品質の改善 • ただし、継続的かつ地道なCI改善はずっと必要 • アプリ-インフラ間のコミュニケーションインタフェースの 統一 • アプリ-インフラ間のコミュニケーション効率の改善 • 手戻りの減少・アジリティの向上 • サービス開発品質・アジリティの向上を継続して推進 • (CI改善) 工学的な手法を導入しての品質改善 • (コミュニケーション改善)非エンジニアとのコミュニケーション改善 104 (C) Recruit Technologies Co.,Ltd. All rights reserved.
105. 105 (C) Recruit Technologies Co.,Ltd. All rights reserved. ご清聴ありがとうございました! 時間の都合上、説明しきれなかったことは Ask the speakerブースまたは、 後日公開する予定の資料のAppendixにおいて補足予定です