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

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

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

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

自己紹介 (藤原涼馬) 藤原涼馬株式会社リクルートテクノロジーズ 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.

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

自己紹介(宮地克弥) 宮地克弥株式会社リクルートテクノロジーズ ITｴﾝｼﾞﾆｱﾘﾝｸﾞ本部ｻｰﾋﾞｽｵﾍﾟﾚｰｼｮﾝｴﾝｼﾞﾆｱﾘﾝｸﾞ部プロジェクト基盤G 経歴 2017年入社
主な活動 • クラウド等先進アーキテクチャの事業への装着 • 社内ISUCON, 勉強会運営コアメンバー 8 (C) Recruit Technologies Co.,Ltd. All rights reserved.

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

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

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

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

rights reserved.

rights reserved. マイルストーンを定める 1. コンテナ化 2. 継続的インテグレーション/デプロイ・デリバリ 3. オーケストレーション& アプリケーション定義 4. 観測性 & 分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

システム全体構成 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

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)

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

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

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

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

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
(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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ビルド速度に配慮のない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回目

のーど: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を利用する

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

のーど:alpine RUN apk add curl COPY package* ./ RUN npm i COPY . ./ CMD [“npm”,”start] 依存パッケージのインストール等、変更が極力少ないものを上に持ってくる

ビルド速度に配慮のない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

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

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

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

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

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

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

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

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

More Decks by Recruit Technologies

Other Decks in Technology

Featured

Transcript