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

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

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

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

Recruit Technologies

December 04, 2018
Tweet

More Decks by Recruit Technologies

Other Decks in Technology

Transcript

  1. JapanContainerDays v1812資料
    改めて見直すコンテナベース
    で作るメリット
    〜安心して開発を回す技術的ポイント〜
    1
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    株式会社リクルートテクノロジーズ
    藤原 涼馬・伊藤 瑛・宮地 克弥

    View Slide

  2. 会社紹介: リクルート
    2
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  3. 事業内容の紹介
    3
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  4. 所属組織の紹介:リクルートテクノロジーズ
    4
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    リクルートグループのビジネス・サービス
    リクルートテクノロジーズ
    IT・マーケティング
    ソリューション
    ビジネス視点の
    ITマネジメント
    横断的にソリューションを提供
    上記は対象企業・サービスの一部抜粋です。

    View Slide

  5. 注意
    5
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    本発表内容は特定プロジェクトにおける
    成果と今後取り組みたい事柄について
    プロジェクトのメンバーが技術的観点から
    整理したものであり、
    所属組織としての全体方針を
    表すものではありません

    View Slide

  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.

    View Slide

  7. 自己紹介(伊藤 瑛)
    伊藤 瑛
    株式会社リクルートテクノロジーズ
    ITエンジニアリング本部プロダクトエンジニアリング部
    アプリケーションソリューションG
    経歴
    2015年 入社
    主な活動
    • フロントエンド・サーバサイドの先進テクノロジ装着
    • アプリケーションアーキテクティング
    7
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  8. 自己紹介(宮地 克弥)
    宮地 克弥
    株式会社リクルートテクノロジーズ
    ITエンジニアリング本部サービスオペレーションエンジニアリング部
    プロジェクト基盤G
    経歴
    2017年 入社
    主な活動
    • クラウド等先進アーキテクチャの事業への装着
    • 社内ISUCON, 勉強会運営コアメンバー
    8
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  9. 本日のアジェンダ
    事例となるサービス
    インフラアーキテクト視点
    アプリケーションエンジニア視点
    インフラ・運用エンジニア視点
    9
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  10. 事例となるサービスの説明(ジョブオプLite)
    10
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    無償の応募管理 & 採用ホームページ作成サービス

    View Slide

  11. 11
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    インフラアーキテクト観点

    View Slide

  12. 前提
    12
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    コンテナベースで作る
    (一般的なコンテナ活用のメリット等については、
    先行事例に学ぶKubernetes企業活用の現実*を参照)
    * http://www.atmarkit.co.jp/ait/series/9283/

    View Slide

  13. 新規技術に取り組む際の留意事項
    いきなり全部盛りは事故のもと
    13
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  14. CLOUD NATIVE TRAIL MAP
    14
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  15. CLOUD NATIVE TRAIL MAP
    15
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  16. CLOUD NATIVE TRAIL MAP
    16
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    マイルストーンを定める
    1. コンテナ化
    2. 継続的インテグレーション/デプロイ・デリバリ
    3. オーケストレーション& アプリケーション定義
    4. 観測性 & 分析

    View Slide

  17. CLOUD NATIVE TRAIL MAP
    17
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    判断ポイント
    ①既存の技術スタック(どこまで経験・知見があるか)
    ②メンバーの数と習熟度
    ③開発期間

    View Slide

  18. ① 既存の技術スタック
    18
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    Dockerは経験あり
    CIはJenkinsなら…
    Swarm, Cattleは経験あり
    Datadogの利用実績あり

    View Slide

  19. インフラアーキテクト視点
    インフラ面の要件
    1. 短時間で必要な構成・計算リソースの確保
    2. ロックインをできる限り回避
    3. “中期的視点”での運用コストの削減
    19
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  20. インフラアーキテクト視点
    インフラ面の要件
    1. 短時間で必要な構成・計算リソースの確保
    20
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    インフラの提供が
    アプリケーション開発の
    足かせにならないようにする

    View Slide

  21. インフラアーキテクト視点
    インフラ面の要件
    2. ロックインをできる限り回避
    21
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    なにかあってもアプリケーションを
    他の環境で動かせるようにする

    View Slide

  22. インフラアーキテクト視点
    インフラ面の要件
    3. “中期的視点”での運用コストの削減
    22
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    サービスの発展に
    本質的ではないものに
    手間はかけない

    View Slide

  23. 1. 短時間で必要な構成・計算リソースの確保
    23
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    オンプレミス
    パブリック
    クラウド
    or

    View Slide

  24. 1. 短時間で必要な構成・計算リソースの確保
    24
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    オンプレミス
    パブリック
    クラウド
    or

    View Slide

  25. 2. ロックインをできる限り回避
    25
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    or

    View Slide

  26. 2. ロックインをできる限り回避
    26
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    or
    • Kubernetesを活用してロックインを回避
    • 他のクラウド環境でも知見が可能な限り活かせるように
    • デファクトスタンダード
    • AWS 東京リージョンにEKSがなかったのでk8s on EC2

    View Slide

  27. 3. 中期視点でのコスト削減
    27
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    Concourse
    監視・モニタリング CI/CD

    View Slide

  28. 3. 中期視点でのコスト削減(監視・モニタリング)
    28
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    Prometheus
    選定ポイント
    • 既存サービスの利用実績
    • 監視・モニタリング基盤の運用コスト

    View Slide

  29. 3. 中期視点でのコスト削減(CI/CD)
    29
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    Concourse

    View Slide

  30. 3. 中期視点でのコスト削減(CI/CD)
    30
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    Concourse

    View Slide

  31. Why not Circle CI
    • 1.x → 2.xへの過渡期
    • 当時ドキュメント等が不足(2017年末時点)
    • ライセンスコスト
    • Enterprise版の価格感がプロジェクト予算と見合わなかった
    31
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  32. Why not Jenkins
    • Jenkinsのバージョンアップの辛さからの解放
    • アドオンを追加した結果バージョンアップできなくなる課題感が
    あった
    • コンテナネイティブなCI/CDパイプライン
    • コンテナ環境を前提としたCI/CDパイプラインが欲しかった
    32
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

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

    View Slide

  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

    View Slide

  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)

    View Slide

  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 リスクとして受容)

    View Slide

  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 リスクとして受容)
    あくまでも目的は
    ビジネス目標の達成
    技術リスク回避がより大きなビジネスリスク
    (リリースの遅延など)を呼び込んではいけない

    View Slide

  38. インフラアーキテクト視点のまとめ
    • いきなり全部盛りはNG
    • 組織内のアセットなどをベースにマイルストーンを定める
    • 要件を満たしつつ適切な落としどころを見つける
    • 技術リスクを絶対視しない
    38
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

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

    View Slide

  40. 40
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    アプリケーション
    エンジニア視点

    View Slide

  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












    欠陥混入からの経過時間

    View Slide

  42. 割れ窓理論
    • 「長期間修理されることのない割れた窓が1枚でもある
    と、ビルの住人に投げやりな感覚--ビルのことなど気に
    もかけない感覚が植え付けられていくのです。そして次
    の窓が割れるのです。…」(達人プログラマーより)
    • 「割れた窓」(悪い設計・質の悪いコード)をそのまま
    にしてはいけない。
    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

    View Slide

  43. CI x 割れ窓理論
    • ソースコードがpushされた瞬間に行われる各種のビルド
    プロセスで、「最初に窓が割れる瞬間」を検出すること
    ができる
    43
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    テスト実行
    のトリガー
    イメージ
    のビルド
    テスト1
    テスト2
    テスト3
    テスト結果
    通知
    NG
    変更のリポジトリ
    へのpush
    CIパイプライン

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  47. CIの信頼性を下げる主な要因
    環境差分
    47
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  48. CIの信頼性を下げる主な要因
    環境差分
    48
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    • ローカル環境 - CI環境の差分

    View Slide

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

    View Slide

  50. CIの信頼性が失われるとおこること
    • よくある例
    • 「このテストはローカルでは通過するが、 CIだと落ちてしまう。」
    • この状況が長く続くと、CIの実行結果を誰も信じなくなる
    • CIにおける割れ窓の検出が難しくなる
    50
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  51. CIの信頼性が失われるとおこること
    • よくある例
    • 「このテストはローカルでは通過するが、 CIだと落ちてしまう。」
    • この状況が長く続くと、CIの実行結果を誰も信じなくなる
    • CIにおける割れ窓の検出が難しくなる
    51
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    プロジェクトのソースコードの健全性が損なわれる

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  64. Test Sizesの考え方を導入
    • Small (外界に依存なし) → Medium / Large (依存あり)の
    順に実行するように
    • テストの起動をSmall / Mediumで分けられるようにする
    • ex) Goの場合、MediumのテストはTestM_で始まるなどのprefixをつけ

    • テストが失敗する要因の大多数を占める単純ミスはSmallで見つけ
    ることができるものが多い
    • docker buildと同じタイミングでsmall testを回してしま

    View Slide

  65. CIパイプラインの修正結果
    65
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    テスト
    実行の
    トリガー
    medium
    テスト1
    medium
    テスト2
    medium
    テスト2
    medium
    テスト
    結果通知
    イメージ
    のビルド
    & small
    テスト
    イメージ
    のpush
    medium
    依存モ
    ジュール
    build

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  69. 69
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    インフラエンジニア視点

    View Slide

  70. アジェンダ(インフラエンジニア視点)
    • CI改善への取り組み
    • 更に安心して開発を回すために
    70
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  71. 71
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    CI改善への取り組み

    View Slide

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

    View Slide

  73. CI/CD・ワンボタンでのデプロイ環境を実現したが…
    機能面ではモダンな環境
    非機能面で課題があった
    73
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

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

    View Slide

  75. 非機能面の課題
    CIサイクルの長さ
    • 1回のPRのテスト完了までに2時間以上かかる
    ケースが発生
    75
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  76. CIサイクルの長期化の悪影響
    • 開発効率の低下
    • 大量のPRが処理されることなく滞留
    • masterブランチが壊れる
    • (急ぎの場合などに)CIの実行完了を待たずしてマージ
    76
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  77. CIサイクルの長期化の悪影響
    • 開発効率の低下
    • 大量のPRが処理されることなく滞留
    • masterブランチが壊れる
    • (急ぎの場合などに)CIの実行完了を待たずしてマージ
    77
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    抜本的な対策が必要なため
    改善活動を実施

    View Slide

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

    View Slide

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

    View Slide

  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回目

    View Slide

  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を利用する

    View Slide

  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回目
    1つでもファイルに変更がある場合
    以降のキャッシュは使われない

    View Slide

  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]
    依存パッケージのインストール等、
    変更が極力少ないものを上に持ってくる

    View Slide

  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

    View Slide

  85. CIパイプラインの修正(再掲)
    85
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    テスト
    実行の
    トリガー
    medium
    テスト1
    medium
    テスト2
    medium
    テスト2
    medium
    テスト
    結果通知
    イメージ
    のビルド
    & small
    テスト
    イメージ
    のpush
    medium
    依存モ
    ジュール
    build

    View Slide

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

    View Slide

  87. 87
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    1回のPRテスト時間
    2時間以上 -> 10分程度に

    View Slide

  88. 88
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    更に安心して開発を回すために
    -安全・確実なリリース-

    View Slide

  89. 2つの要点
    ① アプリ - インフラ間のコミュニケーション
    ② 継続的デプロイ
    89
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

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

    View Slide

  91. デプロイ手順の統一 (継続的デプロイ)
    ① 環境問わず同じ手順でデプロイできるように
    ② 手順を簡略化することで誰でもデプロイできるように
    91
    (C) Recruit Technologies Co.,Ltd. All rights reserved.

    View Slide

  92. デプロイ手順の統一 (継続的デプロイ)
    ① 環境問わず同じ手順でデプロイできるように
    ② 手順を簡略化することで誰でもデプロイできるように
    92
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    開発環境でデプロイプロセスを磨き込む
    自信をもって本番環境にデプロイ

    View Slide

  93. デプロイ手順の統一 (継続的デプロイ)
    ① 環境問わず同じ手順でデプロイできるように
    ② 手順を簡略化することで誰でもデプロイできるように
    93
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    属人性を排除して安定した開発・リリース効率を実現
    開発環境でデプロイプロセスを磨き込む
    自信をもって本番環境にデプロイ

    View Slide

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

    View Slide

  95. 95
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    まとめ・これから・残課題

    View Slide

  96. ここまでとこれから
    ここまでは2つに絞った話
    96
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    コンテナの利点を生かして
    ①プロダクトコードの品質向上
    ②アプリ-インフラ間のコミュニケーション
    をいかに向上するかという話

    View Slide

  97. ここまでとこれから
    ここまでは2つに絞った話
    97
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    コンテナの利点を生かして
    ①プロダクトコードの品質向上
    ②アプリ-インフラ間のコミュニケーション
    をいかに向上するかという話
    さらに推し進める
    スコープを拡大

    View Slide

  98. ① プロダクトコードの品質向上への取り組み
    CIのパイプラインに工学的なコード分析・計測の仕組みを追
    加したい
    98
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    不要テストコード検出

    View Slide

  99. ① プロダクトコードの品質向上への取り組み
    CIのパイプラインに工学的なコード分析・計測の仕組みを追
    加したい
    99
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    不要テストコード検出
    CIおよび環境のコード化を推し進めたからこそトライできる
    (間違っていてもすぐにCIや環境をロールバックできるためチャレンジの土台ができた)

    View Slide

  100. ② アプリ-インフラ間のコミュニケーション スコープ拡大への取り組み
    コミュニケーションのスコープを拡大する
    100
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    現在
    エンジニア間
    コミュニケーション
    これから
    エンジニア
    ー非エンジニア間
    コミュニケーション

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  105. 105
    (C) Recruit Technologies Co.,Ltd. All rights reserved.
    ご清聴ありがとうございました!
    時間の都合上、説明しきれなかったことは
    Ask the speakerブースまたは、
    後日公開する予定の資料のAppendixにおいて補足予定です

    View Slide