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

2024年11月26日のアーキテクチャConference 2024で発表した「複雑なCI/CDから脱却したアーキテクチャ：NTTグループの内製プラットフォーム事例を通して」の講演資料です。講演詳細についてはこちらを御覧ください（https://architecture-con.findy-tools.io/2024/sessions?m=2024/mdl/special/cyQ5MG1y)

Transcript

1. © NTT Communications Corporation All Rights Reserved. 複雑なCI/CDから脱却したアーキテクチャ： NTTグループの内製プラットフォーム事例を通して NTTコミュニケーションズ株式会社 中井 悠人
2. © NTT Communications Corporation All Rights Reserved. 2 ドコモビジネス と NTT コミュニケーションズ NTT コミュニケーションズはドコモグループの一員として、エンタープライズ向 けのワンストップ ICT ソリューションを提供
3. © NTT Communications Corporation All Rights Reserved. 3 docomo business RINK クラウド型セキュリティと一体化した統合型ネットワークサービスで ICTのレジリエンスを強化
4. © NTT Communications Corporation All Rights Reserved. 4 NTT コミュニケーションズ株式会社 イノベーションセンター 中井 悠人 略歴 ⚫ 2014〜2017 (旧称：クラウドサービス部) ⚫ クラウドのIaaS開発・運用や監視・運用システムの内製開発に 従事 ⚫ 2017〜現在 (イノベーションセンター) ⚫ 内製フレームワークを使った社内のプロダクト開発支援の担 当者 (アプリ開発、インフラ構築のどちらも経験) ⚫ インフラ構築の自動化、プラットフォーム化のリード兼開発者 ⚫ (現在) プラットフォームのプロダクトマネージャー 自己紹介
5. © NTT Communications Corporation All Rights Reserved. 5 はじめに アプリ開発者のみなさん、デプロイしてますかー？
6. © NTT Communications Corporation All Rights Reserved. 6 はじめに アプリ開発者のみなさん、デプロイしてますかー？ インフラ担当者のみなさん、デプロイしてますかー？
7. © NTT Communications Corporation All Rights Reserved. 7 クラウドが主流になってきて、DevOpsだ、CI/CDだ、と言われていますが、 今、みなさんの組織ではこんな境界はありませんか？ はじめに アプリケーション コード フレームワーク／ ミドルウェア デプロイ スクリプト 境界 よく語られる ソフトウェアアーキテクチャ Owned by アプリ開発者 完成したソフトウェア / アーキテク チャを引き継いでデプロイするスク リプト Owned by インフラ担当者
8. © NTT Communications Corporation All Rights Reserved. 8 本発表で伝えたいこと ⚫ アーキテクチャを考える際の重要な特性の一つ「デプロイ容易性」 ⚫ 本当の「デプロイ容易性」は、アプリとデプロイパイプラインの泥臭い協調の 先にあるものである ◼ コンテナ化やマイクロサービス化だけじゃない ⚫ NTTグループの内製開発支援をしているチームの中で、インフラ担当だった エンジニアが、アプリ開発チームと協調・協力することで一緒にアーキテクチ ャを変えて、デプロイパイプラインをシンプル化してきた実例を紹介
9. © NTT Communications Corporation All Rights Reserved. 9 本日の話の流れ ⚫ アプリ開発者とインフラ担当者の協調・協力の重要性 ◼ デプロイのバリエーションを減らす ◆クラウドネイティブアーキテクチャへの改善 ◆ブルーグリーンデプロイメントの導入によるデリバリフローの改善 ◼ デプロイの主役をアプリ開発者にする ◆一貫性のあるデプロイを強制する ◆開発者でも簡単に操作ができる、という体験を与える ⚫ プラクティスを水平展開するための取り組み ◼ 内製プラットフォーム「Qmonus Value Stream」
10. © NTT Communications Corporation All Rights Reserved. 10 今日は、この境界があったことで起きたことの話が中心 改めて、この境界だと何が起こるか？ アプリケーション コード フレームワーク／ ミドルウェア デプロイ スクリプト 境界 よく語られる ソフトウェアアーキテクチャ Owned by アプリ開発者 完成したソフトウェア / アーキテク チャを引き継いでデプロイするスク リプト Owned by インフラ担当者 私
11. © NTT Communications Corporation All Rights Reserved. 11 過去の事例のリリースの一例 デプロイを簡単にするために主にデプロイ自動化を進めていた アプリ開発者 1.アプリのリリースバージョンをFix 2.インフラ担当にリリース内容とバージョンについて共有 インフラ担当 (私) 1.リリース内容を加味して、リリース設計 2.リリース手順の作成 → デプロイ自動化は主にここ 3.検証環境の準備 4.検証環境にリリース 5.検証環境にて、機能・非機能試験を実施 6.商用向けパラメータの作成 7.商用環境にリリース
12. © NTT Communications Corporation All Rights Reserved. 12 デプロイ自動化を進めても一向にデプロイが楽にならない ⚫ Ansibleで自動化しているはずだが、毎回違う自動化スクリプト (Playbook)を書いている気がする ⚫ スクリプトは溜まっていくので、組み合わせるだけでいい状況も増えていく
13. © NTT Communications Corporation All Rights Reserved. 13 サービス/ビジネスにも影響が出始める ⚫ Ansibleで自動化しているはずだが、毎回違う自動化スクリプト (Playbook)を書いている気がする ⚫ スクリプトは溜まっていくので、組み合わせるだけでいい状況も増えていく しかし ⚫ スクリプトの依存関係などが生まれ、ピタゴラスイッチのように... ◼ リリース準備や試験などのリードタイムを十分に取らないといけなくなり、 リリース間隔が伸びる ⚫ 組み合わせ方が属人化していき、秘伝のタレに... ◼ 担当が変わると再現できない状況に
14. © NTT Communications Corporation All Rights Reserved. 14 デプロイバリエーションによるリリース手順確立の負荷 デプロイバリエーションが多くなり、デプロイが複雑に データベース ロードバランサ アプリ よくある構成でも... デプロイのバリエーション例： ⚫ メンテナンスのためのサービス停止の有無 ⚫ アプリのコードの更新 ⚫ アプリに関連するパッケージの導入 ⚫ プロセスの再起動の有無 ⚫ アプリのLeader/Followerの切替の有無 ⚫ ミドルウェアのバージョン更新や設定変更 ⚫ データベースのスキーマ変更
15. © NTT Communications Corporation All Rights Reserved. 15 デプロイが複雑になることの弊害 リリースフローを 重く感じる 商用の設定 ドリフトがおきる 負のスパイラル 検証環境の準備に時間がかかり、 手順も複雑になる トラブルなどが起きると、 開発者はそのフローでリリースできず... 例： ⚫ パッケージに差分がある ⚫ パッチが当たっている 例： ⚫ 手順の準備 ⚫ 検証環境の準備 ⚫ 検証環境での試験
16. © NTT Communications Corporation All Rights Reserved. 16 デプロイが複雑になることの弊害 リリースフローを 重く感じる 商用の設定 ドリフトがおきる 負のスパイラル トラブルなどが起きると、 開発者はそのフローでリリースできず... 例： ⚫ 手順の準備 ⚫ 検証環境の準備 ⚫ 検証環境での試験 この負のスパイラルから早急に脱却しないと、 サービス/ビジネス影響が甚大に 例： ⚫ パッケージに差分がある ⚫ パッチが当たっている 検証環境の準備に時間がかかり、 手順も複雑になる
17. © NTT Communications Corporation All Rights Reserved. 17 (再掲)過去の事例のリリースの一例 何がおかしい？ アプリ開発者 1.アプリのリリースバージョンをFix 2.インフラ担当にリリース内容とバージョンについて共有 インフラ担当 (私) 1.リリース内容を加味して、リリース設計 2.リリース手順の作成 → デプロイ自動化は主にここ 3.検証環境の準備 4.検証環境にリリース 5.検証環境にて、機能・非機能試験を実施 6.商用向けパラメータの作成 7.商用環境にリリース
18. © NTT Communications Corporation All Rights Reserved. 18 アプリ開発者とインフラ担当者の境界の不和 アプリ開発者 1.アプリのリリースバージョンをFix 2.インフラ担当にリリース内容とバージョンについて共有 インフラ担当 (私) 1.リリース内容を加味して、リリース設計 2.リリース手順の作成 → デプロイ自動化は主にここ … ⚫ 開発者側はデリバリフローを意識して作っていないし、逆にインフラ担当も アプリの設計がどうなっているかはわからない(お互いにブラックボックス) ◼ 完成したアーキテクチャやソフトウェアを引き継ぐという思考 この境界での 関わり方が課題
19. © NTT Communications Corporation All Rights Reserved. 19 アプリ開発者とインフラ担当者の協調・協力が重要 完成したアーキテクチャやソフトウェア を引き継いで、デプロイ手順を考える アプリ開発者 アプリ開発者 インフラ担当者 インフラ担当者 協調・協力してアーキテクチャや ソフトウェア、デプロイ手順を一緒に考える 思考の転換が必要に
20. © NTT Communications Corporation All Rights Reserved. 20 1.デプロイのバリエーションを減らす a.クラウドネイティブアーキテクチャへの改善 b.ブルーグリーンデプロイメントの導入よるデリバリフローの改善 【考え方】 越境とアジャイル思考 2. デプロイの主役をアプリ開発者に a.一貫性のあるデプロイを強制する b.開発者でも簡単に操作ができる、という体験を与える 【考え方】 できるだけシンプルに 協調・協力における2つの重点ポイント
21. © NTT Communications Corporation All Rights Reserved. 21 1.デプロイのバリエーションを減らす a.クラウドネイティブアーキテクチャへの改善 b.ブルーグリーンデプロイメントの導入よるデリバリフローの改善 【考え方】 越境とアジャイル思考 2. デプロイの主役をアプリ開発者に a.一貫性のあるデプロイを強制する b.開発者でも簡単に操作ができる、という体験を与える 【考え方】 できるだけシンプルに 協調・協力における2つの重点ポイント
22. © NTT Communications Corporation All Rights Reserved. 22 1. デプロイのバリエーションを減らす 〜考え方〜 ⚫ お互いのドメインに踏み込んで議論する（越境） ◼ 自身もソースコードを読み、解像度を上げてから、アプリ開発者と対話し、 理解を深める ⚫ ゴール思考で小さく進める(アジャイル思考） ◼ 改善案(例：コンテナ化・k8s化)のメリットや導入時の課題を説明し、議論・ 検証を繰り返し、最適な実装を一緒に探す 個人との対話 動くソフトウェア 顧客との協調 変化への対応 アジャイル思考
23. © NTT Communications Corporation All Rights Reserved. 23 1. デプロイのバリエーションを減らす 〜取り組み〜 a.クラウドネイティブアーキテクチャへの改善 ◼ アプリのコンテナ化 + Kuberntes（k8s)利用 ◼ マネージドサービスの利用 b.ブルーグリーンデプロイメント(以降、B/G デプロイメント)の 導入によるデリバリフローの改善
24. © NTT Communications Corporation All Rights Reserved. 24 1-a. クラウドネイティブアーキテクチャへの改善 コードベースを開発者と一緒に理解し、アプリ/プラットフォームの両側面での 実装や試験の難易度のトレードオフを判断しながらの改善の積み上げ 実装例： ⚫ アプリのLeader/Followerの切り替え機能 → 切り替えタスクの削減 ◼ 元はアプリが稼働しているVMの即時復旧ができないことに起因しての実装 ◼ k8s側の自動復旧機能で代替できるため、なくすことでシンプル化 ⚫ Init System(Supervisord, systemd等)によるプロセス管理 → プロセスの起動・停止タスクの削減 ◼ 代替機能をコンテナ + k8sで実装 ◆起動/停止時の処理 → PostStart/PreStop ◆起動時の依存関係処理 → Init Container
25. © NTT Communications Corporation All Rights Reserved. 25 1-b. B/G デプロイメントの導入によるデリバリフローの改善 ブルーグリーンデプロイメント(B/Gデプロイメント)とは？ ⚫ 現行の稼働中の環境(ブルー/Blue)と、新バージョンがデプロイされた環境 (グリーン/Green)の２系用意して、安全にリリースする手法 ◼ 最小限のダウンタイム ◼ 迅速なロールバック ◼ 切り替え前に試験が可能 Green (新系) Blue (現系) ロードバランサ Green (新系) Blue (現系) ロードバランサ
26. © NTT Communications Corporation All Rights Reserved. 26 1-b. B/G デプロイメントの導入によるデリバリフローの改善 B/G デプロイメントの実装において、 合わない仕組みや機能はソフトウェア側の改善も推進 実装例： ⚫ アプリのクラスタディスカバリをPull型からPush型に ◼ IPアドレスでのPull型から、各アプリからのPush型に ◆k8sになってIPが不定に ◆特に、2系ある場合に、現系と新系でクラスタ組まれると不都合 ⚫ 現系→新系への切替時にソフトウェア側にもリダイレクト機能を実装 ◼ クラウドのロードバランサーの仕様上、完全な切り替りに数十秒要する ◼ 現系にリクエストが来ると新系にリダイレクト
27. © NTT Communications Corporation All Rights Reserved. 27 1. デプロイのバリエーションを減らす 〜結果〜 バリエーション例 ⚫ メンテナンスのためのサービス停止の有無 ⚫ アプリのコードの更新 ⚫ アプリに関連するパッケージの導入 ⚫ プロセスの再起動の有無 ⚫ アプリのLeader/Followerの切替の有無 ⚫ ミドルウェアのバージョン更新や設定変更 ⚫ データベースのスキーマ変更 コンテナ化 + B/G デプロイメント導入 により、同一のデプロイフローに統一 マネージドサービスにより、概ね不要に
28. © NTT Communications Corporation All Rights Reserved. 28 1.デプロイのバリエーションを減らす a.クラウドネイティブアーキテクチャへの改善 b.ブルーグリーンデプロイメントの導入よるデリバリフローの改善 【考え方】 越境とアジャイル思考 2. デプロイの主役をアプリ開発者に a.一貫性のあるデプロイを強制する b.開発者でも簡単に操作ができる、という体験を与える 【考え方】 できるだけシンプルに 協調・協力における2つの重点ポイント
29. © NTT Communications Corporation All Rights Reserved. 29 2. デプロイの主役をアプリ開発者に 〜考え方〜 【考え方】 できるだけシンプルに ⚫ 過去からの学び ◼ シンプルかつ簡易的なインターフェースを提供することで、 セルフマネージドでの実行を促進できる ◼ 例：開発者各自の開発環境におけるメンテナンス 1. xxx 2. yyy 3. zzz xxx.sh 手順書 スクリプト ChatOps インフラ担当に依頼 20% 50% 100%
30. © NTT Communications Corporation All Rights Reserved. 30 2. デプロイの主役をアプリ開発者に 〜取り組み〜 a.一貫性のあるデプロイを強制する ◼ リリースフローに複数のルートを作らない b. 開発者でも簡単に操作ができる、という体験を与える ◼ 内製プラットフォーム「Qmonus Value Stream」
31. © NTT Communications Corporation All Rights Reserved. 31 ⚫ 検証環境での試験が通らないと商用環境にデプロイできないように CI/CDパイプラインで制限 ⚫ コンテナイメージやCI/CDパイプラインを検証環境と商用環境で 同じものを使うようにパイプラインを実装、共通化(テンプレート化) 2-a. 一貫性のあるデプロイを強制する Build Deploy Test Build Deploy Test Build Deploy Test テンプレート 検証環境 商用環境
32. © NTT Communications Corporation All Rights Reserved. 32 ⚫ 内製プラットフォーム「Qmonus Value Stream」で、ボタン１つで検証環 境から商用環境へのデプロイ（通称：Promotion)をできるように ◼ 試験済みのバージョンを選んで押すだけという体験 (容易さ) ◼ トラブル時にはダッシュボードで詳細なログを見れる (運用性) 2-b. 開発者でも簡単に操作ができる、という体験を与える Build Deploy Test Build Deploy Test 検証環境 商用環境 Promotion
33. © NTT Communications Corporation All Rights Reserved. 33 開発者の気持ちに変化が 2. デプロイの主役をアプリ開発者に 〜結果〜 想像より操作が楽 結果的に自分たちの運用負荷を 軽減することを理解 ルールを強制される ことへの抵抗感
34. © NTT Communications Corporation All Rights Reserved. 34 ここまでのまとめ ⚫ 本当の「デプロイ容易性」はアプリとデプロイパイプラインの 泥臭い協調の先にあるものである 協調・協力における2つの重点ポイント 1.デプロイのバリエーションを減らす (越境とアジャイル思考) a.クラウドネイティブアーキテクチャへの改善 b.ブルーグリーンデプロイメントの導入よるデリバリフローの改善 2.デプロイの主役をアプリ開発者に (できるだけシンプルに) a.一貫性のあるデプロイを強制する b.開発者でも簡単に操作ができる、という体験を与える
35. © NTT Communications Corporation All Rights Reserved. 35 第二部 チームのミッションの変化 ⚫ ミッションの変化 ◼ 特定のサービス開発を担う立場から、開発で培ったノウハウを 水平展開することに (１サービス→組織→全社→NTTグループ) ⚫ 前半の話の振り返り ◼ アーキテクチャやCI/CDパイプラインの改善には、アプリ開発側にもインフ ラ担当側にも、かなりのスキル・経験と適切に協力できる環境が必要 ◼ 一方で、両者と環境が揃ったチーム編成を組成・維持するのは難しい
36. © NTT Communications Corporation All Rights Reserved. 36 ⚫ クラウドの普及と急成長で、インフラ担当者のクラウドの学習コストが急増 ◼ チーム編成への供給が追いつかないため、少数精鋭のインフラ担当者で 複数の開発チームを支えられる体制が必要 ⚫ DevOpsやアジャイルなどの文脈で、アプリ開発者にもクラウドを含む様々 な技術領域への一定の学習を求める風潮も ◼ 顧客に価値を届けることが最優先 ◼ アプリ開発者に過度な認知負荷をかけないことも重要 背景：クラウドの学習コストの急増と認知負荷の拡大
37. © NTT Communications Corporation All Rights Reserved. 37 ノウハウの水平展開の課題とプラットフォーム化 ⚫ 今までやってきたことをそのまま取り組んでもスケールはしない ⚫ プラットフォーム・エンジニアリングを進めることに ◼ ”プラットフォーム・エンジニアリングとは、ソフトウェアの開発とデリバリを目的 とした、セルフサービス型の開発者プラットフォームの構築と運用に関する専 門分野です。” ◼ ”開発者のエクスペリエンスを最適化し、プロダクト・チームによる顧客価値の デリバリを加速させることが期待できるため、大きく注目されています。” https://www.gartner.co.jp/ja/articles/what-is-platform-engineering より引用
38. © NTT Communications Corporation All Rights Reserved. 38 「アプリケーションセントリック」なプラットフォーム ⚫ クラウドインフラとCI/CDパイプラインのプラクティスをパッケージ化して 提供する仕組みをプラットフォーム(as a Service)として提供 ◼ 特徴は「アプリ x インフラ x デリバリ」を一緒に扱うこと ⚫ 重視したことは「アプリケーションセントリック」な考え方 ◼ アプリ/インフラ x デリバリ → 環境の一貫性を担保 ◆例：ツールが分かれると独自の管理ルールが生まれ、環境にズレが生じる ◼ アプリ x インフラ → パラメータ管理の煩雑さの削減 ◆例：ライフサイクルの違う２種類のリソース間でのパラメータの受渡しコストの削減
39. © 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パイプラインを獲得
40. © NTT Communications Corporation All Rights Reserved. 40 Qmonus Value Streamの公式パッケージ例
41. © NTT Communications Corporation All Rights Reserved. 41 プラットフォームのいま ⚫ 特徴 ◼ クラウド構成とCI/CDパイプラインをセットでパッケージ化可能 ◼ 「アプリ x インフラ x デプロイ」をプラットフォーム1つに集約 ◆IaCとCI/CDのツールがセットになったイメージ ◆環境管理での一貫性の担保やパラメータ管理での煩雑さの削減に貢献 ⚫ 課題 ◼ プラットフォームでのアプリ開発者とインフラ担当の境界は未だ模索中 ◆例：それぞれがどういう単位での管理し、情報の受け渡しをすればいいのか ◼ アプリ開発者の学習と認知負荷のトレードオフも未だ模索中 ◆例：DevOpsするために必要な情報とは
42. © NTT Communications Corporation All Rights Reserved. 42 プラットフォームのこれから ⚫ アプリ開発者向けのインターフェースについて磨いていく ⚫ アプリ開発者がデプロイまでを見据えながら、ソフトウェア改善まで踏み込 んで行ける世界を目指したい ⚫ アプリ開発者・インフラ担当者の両側面から、この世界を一緒に築き上げて くれる仲間やユーザをNTTグループに限らず広く募っている
43. © NTT Communications Corporation All Rights Reserved. 43 おわりに ⚫ 本当の「デプロイ容易性」はアプリとデプロイパイプラインの泥臭い協調の先 にあるものである ⚫ さらには、アプリ開発者がデプロイまでを見据えながら、ソフトウェア改善ま で踏み込んで行ける世界を目指したい ⚫ そのために、アプリ開発者・インフラ担当者も一丸となれる、より良い境界を 見つけていきたい
44. © NTT Communications Corporation All Rights Reserved. 44 ご清聴ありがとうございました ブースではデモやトライアルの説明もしているので ぜひお立ち寄りください ランディングページ