複雑なCI/CDから脱却したアーキテクチャ：NTTグループの内製プラットフォーム事例を通して / An Architecture Achieving Simplified CI/CD: Insights from NTT Group's In-House Platform Case Study

by NTT Communications

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

© NTT Communications Corporation All Rights Reserved. 4 NTT コミュニケーションズ株式会社イノベーションセンター中井悠人略歴 ⚫ 2014〜2017 (旧称：クラウドサービス部) ⚫ クラウドのIaaS開発・運用や監視・運用システムの内製開発に従事 ⚫ 2017〜現在 (イノベーションセンター) ⚫ 内製フレームワークを使った社内のプロダクト開発支援の担当者 (アプリ開発、インフラ構築のどちらも経験) ⚫ インフラ構築の自動化、プラットフォーム化のリード兼開発者 ⚫ (現在) プラットフォームのプロダクトマネージャー自己紹介

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© NTT Communications Corporation All Rights Reserved. 7 クラウドが主流になってきて、DevOpsだ、CI/CDだ、と言われていますが、今、みなさんの組織ではこんな境界はありませんか？はじめにアプリケーションコードフレームワーク／ミドルウェアデプロイスクリプト境界よく語られるソフトウェアアーキテクチャ Owned by アプリ開発者完成したソフトウェア / アーキテクチャを引き継いでデプロイするスクリプト Owned by インフラ担当者

Slide 8

Slide 8 text

© NTT Communications Corporation All Rights Reserved. 8 本発表で伝えたいこと ⚫ アーキテクチャを考える際の重要な特性の一つ「デプロイ容易性」 ⚫ 本当の「デプロイ容易性」は、アプリとデプロイパイプラインの泥臭い協調の先にあるものである ◼ コンテナ化やマイクロサービス化だけじゃない ⚫ NTTグループの内製開発支援をしているチームの中で、インフラ担当だったエンジニアが、アプリ開発チームと協調・協力することで一緒にアーキテクチャを変えて、デプロイパイプラインをシンプル化してきた実例を紹介

Slide 9

Slide 9 text

© NTT Communications Corporation All Rights Reserved. 9 本日の話の流れ ⚫ アプリ開発者とインフラ担当者の協調・協力の重要性 ◼ デプロイのバリエーションを減らす ◆クラウドネイティブアーキテクチャへの改善 ◆ブルーグリーンデプロイメントの導入によるデリバリフローの改善 ◼ デプロイの主役をアプリ開発者にする ◆一貫性のあるデプロイを強制する ◆開発者でも簡単に操作ができる、という体験を与える ⚫ プラクティスを水平展開するための取り組み ◼ 内製プラットフォーム「Qmonus Value Stream」

Slide 10

Slide 10 text

© NTT Communications Corporation All Rights Reserved. 10 今日は、この境界があったことで起きたことの話が中心改めて、この境界だと何が起こるか？アプリケーションコードフレームワーク／ミドルウェアデプロイスクリプト境界よく語られるソフトウェアアーキテクチャ Owned by アプリ開発者完成したソフトウェア / アーキテクチャを引き継いでデプロイするスクリプト Owned by インフラ担当者私

Slide 11

Slide 11 text

© NTT Communications Corporation All Rights Reserved. 11 過去の事例のリリースの一例デプロイを簡単にするために主にデプロイ自動化を進めていたアプリ開発者 1.アプリのリリースバージョンをFix 2.インフラ担当にリリース内容とバージョンについて共有インフラ担当 (私) 1.リリース内容を加味して、リリース設計 2.リリース手順の作成 → デプロイ自動化は主にここ 3.検証環境の準備 4.検証環境にリリース 5.検証環境にて、機能・非機能試験を実施 6.商用向けパラメータの作成 7.商用環境にリリース

Slide 12

Slide 12 text

Slide 13

Slide 13 text

© NTT Communications Corporation All Rights Reserved. 13 サービス/ビジネスにも影響が出始める ⚫ Ansibleで自動化しているはずだが、毎回違う自動化スクリプト (Playbook)を書いている気がする ⚫ スクリプトは溜まっていくので、組み合わせるだけでいい状況も増えていくしかし ⚫ スクリプトの依存関係などが生まれ、ピタゴラスイッチのように... ◼ リリース準備や試験などのリードタイムを十分に取らないといけなくなり、リリース間隔が伸びる ⚫ 組み合わせ方が属人化していき、秘伝のタレに... ◼ 担当が変わると再現できない状況に

Slide 14

Slide 14 text

© NTT Communications Corporation All Rights Reserved. 14 デプロイバリエーションによるリリース手順確立の負荷デプロイバリエーションが多くなり、デプロイが複雑にデータベースロードバランサアプリよくある構成でも... デプロイのバリエーション例： ⚫ メンテナンスのためのサービス停止の有無 ⚫ アプリのコードの更新 ⚫ アプリに関連するパッケージの導入 ⚫ プロセスの再起動の有無 ⚫ アプリのLeader/Followerの切替の有無 ⚫ ミドルウェアのバージョン更新や設定変更 ⚫ データベースのスキーマ変更

Slide 15

Slide 15 text

© NTT Communications Corporation All Rights Reserved. 15 デプロイが複雑になることの弊害リリースフローを重く感じる商用の設定ドリフトがおきる負のスパイラル検証環境の準備に時間がかかり、手順も複雑になるトラブルなどが起きると、開発者はそのフローでリリースできず... 例： ⚫ パッケージに差分がある ⚫ パッチが当たっている例： ⚫ 手順の準備 ⚫ 検証環境の準備 ⚫ 検証環境での試験

Slide 16

Slide 16 text

© NTT Communications Corporation All Rights Reserved. 16 デプロイが複雑になることの弊害リリースフローを重く感じる商用の設定ドリフトがおきる負のスパイラルトラブルなどが起きると、開発者はそのフローでリリースできず... 例： ⚫ 手順の準備 ⚫ 検証環境の準備 ⚫ 検証環境での試験この負のスパイラルから早急に脱却しないと、サービス/ビジネス影響が甚大に例： ⚫ パッケージに差分がある ⚫ パッチが当たっている検証環境の準備に時間がかかり、手順も複雑になる

Slide 17

Slide 17 text

© NTT Communications Corporation All Rights Reserved. 17 (再掲)過去の事例のリリースの一例何がおかしい？アプリ開発者 1.アプリのリリースバージョンをFix 2.インフラ担当にリリース内容とバージョンについて共有インフラ担当 (私) 1.リリース内容を加味して、リリース設計 2.リリース手順の作成 → デプロイ自動化は主にここ 3.検証環境の準備 4.検証環境にリリース 5.検証環境にて、機能・非機能試験を実施 6.商用向けパラメータの作成 7.商用環境にリリース

Slide 18

Slide 18 text

© NTT Communications Corporation All Rights Reserved. 18 アプリ開発者とインフラ担当者の境界の不和アプリ開発者 1.アプリのリリースバージョンをFix 2.インフラ担当にリリース内容とバージョンについて共有インフラ担当 (私) 1.リリース内容を加味して、リリース設計 2.リリース手順の作成 → デプロイ自動化は主にここ … ⚫ 開発者側はデリバリフローを意識して作っていないし、逆にインフラ担当もアプリの設計がどうなっているかはわからない(お互いにブラックボックス) ◼ 完成したアーキテクチャやソフトウェアを引き継ぐという思考この境界での関わり方が課題

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© NTT Communications Corporation All Rights Reserved. 20 1.デプロイのバリエーションを減らす a.クラウドネイティブアーキテクチャへの改善 b.ブルーグリーンデプロイメントの導入よるデリバリフローの改善【考え方】越境とアジャイル思考 2. デプロイの主役をアプリ開発者に a.一貫性のあるデプロイを強制する b.開発者でも簡単に操作ができる、という体験を与える【考え方】できるだけシンプルに協調・協力における2つの重点ポイント

Slide 21

Slide 21 text

© NTT Communications Corporation All Rights Reserved. 21 1.デプロイのバリエーションを減らす a.クラウドネイティブアーキテクチャへの改善 b.ブルーグリーンデプロイメントの導入よるデリバリフローの改善【考え方】越境とアジャイル思考 2. デプロイの主役をアプリ開発者に a.一貫性のあるデプロイを強制する b.開発者でも簡単に操作ができる、という体験を与える【考え方】できるだけシンプルに協調・協力における2つの重点ポイント

Slide 22

Slide 22 text

© NTT Communications Corporation All Rights Reserved. 22 1. デプロイのバリエーションを減らす〜考え方〜 ⚫ お互いのドメインに踏み込んで議論する（越境） ◼ 自身もソースコードを読み、解像度を上げてから、アプリ開発者と対話し、理解を深める ⚫ ゴール思考で小さく進める(アジャイル思考） ◼ 改善案(例：コンテナ化・k8s化)のメリットや導入時の課題を説明し、議論・検証を繰り返し、最適な実装を一緒に探す個人との対話動くソフトウェア顧客との協調変化への対応アジャイル思考

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© NTT Communications Corporation All Rights Reserved. 24 1-a. クラウドネイティブアーキテクチャへの改善コードベースを開発者と一緒に理解し、アプリ/プラットフォームの両側面での実装や試験の難易度のトレードオフを判断しながらの改善の積み上げ実装例： ⚫ アプリのLeader/Followerの切り替え機能 → 切り替えタスクの削減 ◼ 元はアプリが稼働しているVMの即時復旧ができないことに起因しての実装 ◼ k8s側の自動復旧機能で代替できるため、なくすことでシンプル化 ⚫ Init System(Supervisord, systemd等)によるプロセス管理 → プロセスの起動・停止タスクの削減 ◼ 代替機能をコンテナ + k8sで実装 ◆起動/停止時の処理 → PostStart/PreStop ◆起動時の依存関係処理 → Init Container

Slide 25

Slide 25 text

© NTT Communications Corporation All Rights Reserved. 25 1-b. B/G デプロイメントの導入によるデリバリフローの改善ブルーグリーンデプロイメント(B/Gデプロイメント)とは？ ⚫ 現行の稼働中の環境(ブルー/Blue)と、新バージョンがデプロイされた環境 (グリーン/Green)の２系用意して、安全にリリースする手法 ◼ 最小限のダウンタイム ◼ 迅速なロールバック ◼ 切り替え前に試験が可能 Green (新系) Blue (現系) ロードバランサ Green (新系) Blue (現系) ロードバランサ

Slide 26

Slide 26 text

© NTT Communications Corporation All Rights Reserved. 26 1-b. B/G デプロイメントの導入によるデリバリフローの改善 B/G デプロイメントの実装において、合わない仕組みや機能はソフトウェア側の改善も推進実装例： ⚫ アプリのクラスタディスカバリをPull型からPush型に ◼ IPアドレスでのPull型から、各アプリからのPush型に ◆k8sになってIPが不定に ◆特に、2系ある場合に、現系と新系でクラスタ組まれると不都合 ⚫ 現系→新系への切替時にソフトウェア側にもリダイレクト機能を実装 ◼ クラウドのロードバランサーの仕様上、完全な切り替りに数十秒要する ◼ 現系にリクエストが来ると新系にリダイレクト

Slide 27

Slide 27 text

© NTT Communications Corporation All Rights Reserved. 27 1. デプロイのバリエーションを減らす〜結果〜バリエーション例 ⚫ メンテナンスのためのサービス停止の有無 ⚫ アプリのコードの更新 ⚫ アプリに関連するパッケージの導入 ⚫ プロセスの再起動の有無 ⚫ アプリのLeader/Followerの切替の有無 ⚫ ミドルウェアのバージョン更新や設定変更 ⚫ データベースのスキーマ変更コンテナ化 + B/G デプロイメント導入により、同一のデプロイフローに統一マネージドサービスにより、概ね不要に

Slide 28

Slide 28 text

© NTT Communications Corporation All Rights Reserved. 28 1.デプロイのバリエーションを減らす a.クラウドネイティブアーキテクチャへの改善 b.ブルーグリーンデプロイメントの導入よるデリバリフローの改善【考え方】越境とアジャイル思考 2. デプロイの主役をアプリ開発者に a.一貫性のあるデプロイを強制する b.開発者でも簡単に操作ができる、という体験を与える【考え方】できるだけシンプルに協調・協力における2つの重点ポイント

Slide 29

Slide 29 text

© NTT Communications Corporation All Rights Reserved. 29 2. デプロイの主役をアプリ開発者に〜考え方〜【考え方】できるだけシンプルに ⚫ 過去からの学び ◼ シンプルかつ簡易的なインターフェースを提供することで、セルフマネージドでの実行を促進できる ◼ 例：開発者各自の開発環境におけるメンテナンス 1. xxx 2. yyy 3. zzz xxx.sh 手順書スクリプト ChatOps インフラ担当に依頼 20% 50% 100%

Slide 30

Slide 30 text

Slide 31

Slide 31 text

© NTT Communications Corporation All Rights Reserved. 31 ⚫ 検証環境での試験が通らないと商用環境にデプロイできないように CI/CDパイプラインで制限 ⚫ コンテナイメージやCI/CDパイプラインを検証環境と商用環境で同じものを使うようにパイプラインを実装、共通化(テンプレート化) 2-a. 一貫性のあるデプロイを強制する Build Deploy Test Build Deploy Test Build Deploy Test テンプレート検証環境商用環境

Slide 32

Slide 32 text

© NTT Communications Corporation All Rights Reserved. 32 ⚫ 内製プラットフォーム「Qmonus Value Stream」で、ボタン１つで検証環境から商用環境へのデプロイ（通称：Promotion)をできるように ◼ 試験済みのバージョンを選んで押すだけという体験 (容易さ) ◼ トラブル時にはダッシュボードで詳細なログを見れる (運用性) 2-b. 開発者でも簡単に操作ができる、という体験を与える Build Deploy Test Build Deploy Test 検証環境商用環境 Promotion

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© NTT Communications Corporation All Rights Reserved. 34 ここまでのまとめ ⚫ 本当の「デプロイ容易性」はアプリとデプロイパイプラインの泥臭い協調の先にあるものである協調・協力における2つの重点ポイント 1.デプロイのバリエーションを減らす (越境とアジャイル思考) a.クラウドネイティブアーキテクチャへの改善 b.ブルーグリーンデプロイメントの導入よるデリバリフローの改善 2.デプロイの主役をアプリ開発者に (できるだけシンプルに) a.一貫性のあるデプロイを強制する b.開発者でも簡単に操作ができる、という体験を与える

Slide 35

Slide 35 text

© NTT Communications Corporation All Rights Reserved. 35 第二部チームのミッションの変化 ⚫ ミッションの変化 ◼ 特定のサービス開発を担う立場から、開発で培ったノウハウを水平展開することに (１サービス→組織→全社→NTTグループ) ⚫ 前半の話の振り返り ◼ アーキテクチャやCI/CDパイプラインの改善には、アプリ開発側にもインフラ担当側にも、かなりのスキル・経験と適切に協力できる環境が必要 ◼ 一方で、両者と環境が揃ったチーム編成を組成・維持するのは難しい

Slide 36

Slide 36 text

© NTT Communications Corporation All Rights Reserved. 36 ⚫ クラウドの普及と急成長で、インフラ担当者のクラウドの学習コストが急増 ◼ チーム編成への供給が追いつかないため、少数精鋭のインフラ担当者で複数の開発チームを支えられる体制が必要 ⚫ DevOpsやアジャイルなどの文脈で、アプリ開発者にもクラウドを含む様々な技術領域への一定の学習を求める風潮も ◼ 顧客に価値を届けることが最優先 ◼ アプリ開発者に過度な認知負荷をかけないことも重要背景：クラウドの学習コストの急増と認知負荷の拡大

Slide 37

Slide 37 text

© NTT Communications Corporation All Rights Reserved. 37 ノウハウの水平展開の課題とプラットフォーム化 ⚫ 今までやってきたことをそのまま取り組んでもスケールはしない ⚫ プラットフォーム・エンジニアリングを進めることに ◼ ”プラットフォーム・エンジニアリングとは、ソフトウェアの開発とデリバリを目的とした、セルフサービス型の開発者プラットフォームの構築と運用に関する専門分野です。” ◼ ”開発者のエクスペリエンスを最適化し、プロダクト・チームによる顧客価値のデリバリを加速させることが期待できるため、大きく注目されています。” https://www.gartner.co.jp/ja/articles/what-is-platform-engineering より引用

Slide 38

Slide 38 text

© NTT Communications Corporation All Rights Reserved. 38 「アプリケーションセントリック」なプラットフォーム ⚫ クラウドインフラとCI/CDパイプラインのプラクティスをパッケージ化して提供する仕組みをプラットフォーム(as a Service)として提供 ◼ 特徴は「アプリ x インフラ x デリバリ」を一緒に扱うこと ⚫ 重視したことは「アプリケーションセントリック」な考え方 ◼ アプリ/インフラ x デリバリ → 環境の一貫性を担保 ◆例：ツールが分かれると独自の管理ルールが生まれ、環境にズレが生じる ◼ アプリ x インフラ → パラメータ管理の煩雑さの削減 ◆例：ライフサイクルの違う２種類のリソース間でのパラメータの受渡しコストの削減

Slide 39

Slide 39 text

© NTT Communications Corporation All Rights Reserved. 39 Container Image Build Test App Deploy Infra Deploy Image Scan お客様管理のクラウド ※ 3大クラウド対応お客様管理のアプリのソースコードリポジトリ ※ GitLab / Bitbucket / Backlogも対応 1.アプリに必要なビルドインされたインフラ要件を選択 3.最適なクラウドアーキテクチャとアプリをクラウドにデプロイ詳細はランディングページ (https://www.valuestream.qmonus.net/) 2.要件に沿ったデリバリフローを自動生成アプリ開発者ビルド元のソースはユーザリポジトリより取得 (クモナスバリューストリーム）アプリ開発者自身で簡単にデプロイし続けられるクラウドアーキテクチャとCI/CDパイプラインを獲得

Slide 40

Slide 40 text

Slide 41

Slide 41 text

© NTT Communications Corporation All Rights Reserved. 41 プラットフォームのいま ⚫ 特徴 ◼ クラウド構成とCI/CDパイプラインをセットでパッケージ化可能 ◼ 「アプリ x インフラ x デプロイ」をプラットフォーム1つに集約 ◆IaCとCI/CDのツールがセットになったイメージ ◆環境管理での一貫性の担保やパラメータ管理での煩雑さの削減に貢献 ⚫ 課題 ◼ プラットフォームでのアプリ開発者とインフラ担当の境界は未だ模索中 ◆例：それぞれがどういう単位での管理し、情報の受け渡しをすればいいのか ◼ アプリ開発者の学習と認知負荷のトレードオフも未だ模索中 ◆例：DevOpsするために必要な情報とは

Slide 42

Slide 42 text

© NTT Communications Corporation All Rights Reserved. 42 プラットフォームのこれから ⚫ アプリ開発者向けのインターフェースについて磨いていく ⚫ アプリ開発者がデプロイまでを見据えながら、ソフトウェア改善まで踏み込んで行ける世界を目指したい ⚫ アプリ開発者・インフラ担当者の両側面から、この世界を一緒に築き上げてくれる仲間やユーザをNTTグループに限らず広く募っている

Slide 43

Slide 43 text

© NTT Communications Corporation All Rights Reserved. 43 おわりに ⚫ 本当の「デプロイ容易性」はアプリとデプロイパイプラインの泥臭い協調の先にあるものである ⚫ さらには、アプリ開発者がデプロイまでを見据えながら、ソフトウェア改善まで踏み込んで行ける世界を目指したい ⚫ そのために、アプリ開発者・インフラ担当者も一丸となれる、より良い境界を見つけていきたい