マニフェストレスで使える IaC・CI/CD のSaaSプロダクト化への挑戦

© NTT Communications Corporation All Rights Reserved.
マニフェストレスで使える
IaC・CI/CD のSaaSプロダクト化への挑戦
NTTコミュニケーションズ
イノベーションセンター
奥井寛樹・浅井孝太
1

View Slide

目次
● マニフェストレスなIaC・CI/CD基盤をつくる目的
● マニフェストレスを実現するための独自のIaC技術
● SaaS化に向けたこだわり
● Kubernetesカスタムオペレータを軸にした技術課題解決
2

View Slide

自己紹介
NTT コミュニケーションズ
Software Engineer
浅井孝太
略歴
● 2020年入社
● 伝送システムの在庫可視化システム開発
● DevOpsプラットフォーム開発
3

View Slide

マニフェストレスなIaC・CI/CD基盤を
つくる目的
4

View Slide

課題1: アプリ開発者の負担が大きい
人が足りない...
管理する環境が多いよ...
スモールスタートしたいし
手間なく環境を作りたい...
マイクロサービスにすると管理するマニフェストが多い
...
システムアーキテクチャに関する悩み
5

View Slide

課題1: アプリ開発者の負担が大きい
サービス毎にシステムアーキテクチャ構成の
ハードウェア
仮想マシン
OS
ストレージ
システム構成
DB
アプリ
ユーザ側で全ての
環境を構築・運用
開発環境
ステージング環境
プロダクション環境
設計構築検証運用を担当するため、アプリ開発に注力できない
ユーザ所有・管理
6

View Slide

課題1の解決: プラクティスのカタログ化
クラウドにパターン化されたシステム構成を選択するだけで構成を管理できる
ハードウェア
仮想マシン
OS
ストレージ
システム構成
DB
アプリ
Qmonus Value Stream
ユーザ所有・管理
Qmonus Value
Stream
ユーザ所有＆Qmonus-VSで
コントロール
サービス開発者
ユーザ持ち込み
クラウド
サービス利用
サービス開発者がアプリ開発に注力できる
ユーザに代わってデ
リバリ
アプリ開発
7

View Slide

課題2: サイロ化による局所最適化
プロジェクトや部門単位でアーキテクチャを考えると局所最適化が繰り返される
プロジェクトA
部門A
プロジェクトB
プロジェクトC
部門B
プロジェクトD
プロジェクトE
部門C
プロジェクトF
・・・
組織間でサイロ化が進み、加えて開発人員も不足
8

View Slide

課題2の解決: ノウハウの共有・再利用
各組織から得たアーキテクチャ構成のノウハウを
システム構成パターンとして蓄積
プロジェクトA
部門A
プロジェクトB
部門B
プロジェクトC
部門C
・・・
蓄積したノウハウをシステム構成パターンとしてまとめて
各プロジェクトへ還元し、サイロ化を防止
Qmonus Value Stream
共通にした方が良いものがたくさんある
● Infrastructure as Codeによる構成管理
● WAF / CDN / SSL policy / 証明書戦略..
9

View Slide

課題3: CI/CDパイプライン整備が大変
インフラやCI・CDパイプラインを構築するために多くのツールを
組み合わせて使用する必要がある
ツールの選定や構築・保守に多くの時間が掛かってしまう
インフラ構成が決まれば CI・CDパイプラインが勝
手に出来上がればいいのに ...
10

View Slide

課題3の解決: インフラ構成とCI/CDをバンドル
システム構成パターンを選択するだけでCI・CDパイプラインのベースも出来上がる
構成パターンA
構成パターンB
構成パターンC
Build Scan Release
サービス開発者がアプリ開発に注力できる
11

View Slide

つくったもの：Qmonus Value Stream
アプリ提供までのバリューストリームを最大化する
DevOpsプラットフォーム
● ビジネスに価値を生む開発工程に注力するために、早いフィードバックループを実現
● 基盤に詳しくなくてもプロのように Cloud Nativeアプリケーションをデリバリできる
Test
Monitor
Insights Feedback Loop
Well-Architect
Deployment & Release
Security & Policy
Enforcement
Qmonus -
DevOps
Platform
Release
Code
Analyze
Measure
Plan
Qmonus Value Streamがサポートする範囲
アプリケーション開発者が注力する範囲
12

View Slide

マニフェストレスを実現するための独自のIaC技術
Cloud Native Adapterについて
13

View Slide

Cloud Native Adapter
Qmonus Value Stream独自のCUE言語を用いたInfrastructure as Code (IaC) 実装
Cloud Native Adapterは
「インフラストラクチャ構成」と「ワークフロー」
をまとめて統一的なインターフェースで記載が可能
resources: {
kubernetes: {
deployment: ...
service: ...
}
gcp: {
monitoring: ...
}
}
pipelines: {
deploy: {
tasks: {
applyManifest: ...
testApi: ...
}
}
}
ワークフロー
インフラストラクチャ構成
provider:
kubernetes
apiVersion: apps/v1
kind: Deployment
spec:
minReadySeconds:
60
replicas: 1
...
apiVersion:
tekton.dev/v1beta1
kind: Pipeline
metadata:
name: deploy
spec:
tasks:
...
compile
14

View Slide

Cloud Native AdapterはマニフェストレスなIaC
resources: {
kubernetes: {
deployment: ...
service: ...
}
gcp: {
monitoring: ...
}
}
pipelines: {
deploy: {
tasks: {
applyManifest: ...
testApi: ...
}
}
}
ワークフロー
provider:
kubernetes
apiVersion: apps/v1
kind: Deployment
spec:
minReadySeconds:
60
replicas: 1
...
apiVersion:
tekton.dev/v1beta1
kind: Pipeline
metadata:
name: deploy
spec:
tasks:
...
ユーザは
選択するだけ
マニフェストを自分で書かなくて良い
自動生成される
compile
15

View Slide

アプリケーションを稼働させるクラウドアーキテクチャの構成
Public API
Adapter
Deployment
Adapter
Cloud Armor
Cloud Load
Balancing
Cloud Armor
Cloud Load
Balancing
Google Kubernetes
Engine
composite
composite
compile
16

View Slide

ワークフロー
アプリケーションのビルド・デプロイ・試験を実施するワークフロー
Build Deploy Release
Artifact
Registry
Build
Buildkit
Compile
Infrastructure
Adapter
Infrastructure
manifest
Kubernetes
Deploy
Pulumi
compile
Buildkit Build
Adapter
Simple Deploy
Adapter
17

View Slide

Cloud Native Adapterの全体像
インフラストラクチャ構成とワークフローをまとめてパッケージング
Build Scan Release
ワークフロー
Container Security
Uptime Check
Check
GKE API
Adapterを組み合わせ、
アーキテクチャと
ワークフローの
両方を拡張
18

View Slide

Demo - Qmonus Value Stream
Nginxを立ち上げるアプリケーションをデプロイ
Nginx Sample
Adapter
Google Kubernetes Engine
Deploy
Compile
Nginx Sample
Adapter
Infrastructure
manifest
Kubernetes
Deploy
Pulumi
Resolve IP Adress
type: LoadBalancer
で作成したServiceの
IPアドレスを取得
19

View Slide

© NTT Communications Corporation All Rights Reserved. 20
Demo - Qmonus Value Stream

View Slide

採用している技術スタックの紹介
Nginx Sample
Adapter
Qmonus Value Streamでは
TektonとCUEを特に活用している
Google Kubernetes Engine
Deploy
Compile
Nginx Sample
Adapter
Infrastructure
manifest
Kubernetes
Deploy
Pulumi
Resolve IP Adress
type: LoadBalancer
で作成したServiceの
IPアドレスを取得
21

View Slide

Tekton
● CI/CDシステムを作成するためのKubernetes Nativeなオープンソースフレームワーク
● 処理の最小単位をContainerで定義できる (= Step)
● 複数のContainerをシーケンシャルに実行することで一連の処理を実現する (= Task)
● 一連の処理（Task）の順序関係を指定したり，パラレルに実行する (= Pipeline)
Tektonの特徴
Build Pipeline
Task Task Task
22

View Slide

CUE
データの検証、conﬁguration、コード生成などを実現するためのデータ記述言語
● Types are Values
○ 値と型を区別しない
○ 型による制約や検査がシンプルに記述できる
● 制約によるデータ生成
○ CUEは継承のような仕組みを持たず、
結合の順序に関係なく一貫した結果を生成できる
● プログラマビリティ
○ Templatingやmodule化などが行える
○ Go APIやProtocol Buﬀers, OpenAPI をサポート
// Type
replicas: int
// Constraint
replicas: >2
// Value OK
replicas: 3
—---------------------
// if set an invalid value
replicas: 1
replicas: invalid value 1 (out of bound >2)
Types are Value
23

View Slide

IaC
IaC
IaC
IaC
CUEでAdapterを実現するための工夫 1/2
Cloud Native AdapterではCUE実装でインターフェース規約を導入
統一的なインターフェース導入により
Go APIによるCompile実装が可能に
IaC
Adapter A
IaC
Adapter B
IaC
Adapter C
IaC
Adapter D
Interface
compile
実装されたIaCを利用する
手続き (inputやoutputの利用) が統一される
24

View Slide

CUEでAdapterを実現するための工夫 2/2
インターフェース規約を守ることで
再帰的なCompositeが可能に
より小さな単位でAdapterを作成して再利用性を
高めることが可能に
抽象度の高いより大きな規模の
Adapterが作成可能に
25

View Slide

SaaS化に向けたこだわり
26

View Slide

自己紹介
NTTコミュニケーションズ
Software Engineer
奥井寛樹
略歴
● 伝送システムのSDNコントローラ開発
● DevOpsプラットフォーム開発
● IoTデータ収集基盤のモダナイゼーション
@HirokiOkui
hrk091
27

View Slide

デリバリ基盤のSaaS化の必要性
28
● IaC・CI/CDをつくるマニフェストだけだとデリバリはできない
○ マニフェストに従って、安定してデリバリできる基盤が必要
● デリバリ基盤を維持・運用するのは大変
○ 選択してApplyするだけでデリバリできる世界を実現したい
● マニフェストの設計・維持管理コストは、デリバリサイクル全体の一部でしかない
○ マニフェストだけでは開発サイクルは向上しない
○ デリバリサイクル全体の UX・DXの改善が必要
独自のIaCを提案するなら
デリバリ基盤もセットで必要
IaC・CI/CDのマニフェストは
すぐにできたけど、
どう適用すればいいの？

View Slide

マニフェストレス IaC・CI/CDの
SaaS化に向けたこだわり
1. TektonでCI/CDを両方行う
2. User Self Managed
29

View Slide

こだわり1: TektonでCI/CDを両方行う
● 使用するツールを減らす
○ ユーザ目線：Tektonに限定されて認知負荷が減る
○ 基盤目線：　使用するツールが限定され、構成を simplifyできる
● k8s & マルチクラウドの両方をサポート
○ k8sへのデリバリ前提だと、クラウドインフラがサポートできない
○ Tektonを基底に、Pulumiなど必要なツールを組み込む
● multi stage deploymentを一貫して行う
○ CI/CDでツールを分けると、 IT ➞ ST ➞ Prod と渡り歩く中で両方の作り込みが要る
○ Tektonで作り込んだパイプラインで、環境を問わず同じフローでデリバリできる
IT ST Prod
Dev
30

View Slide

こだわり2: User Self-Managed
● ユーザの敷居を下げるために、
UIが必須
○ manifestで宣言的記述する方式は、認知負荷が高い
● ユーザのObservabilityも重要
○ Tekton Pipeline/Taskの状態・ログの可視化
● パラメータ管理の負荷を下げる
○ アプリ x 環境 x (IaC|CI/CD) ごとにパラメータセットが必要
○ 1つずつ愚直に指定 or 紐付けるのはスケールしない
31
例: Taskあたりパラメータ: 5、AppあたりTask: 5、App: 5、Env: 3
=> 5 x 5 x 5 x 3 = 375こ
ログ（Grafana Loki使用）
Tektonリソース・Podの
Spec・Status・Event
Tektonリソースの
制御
Grafana Lokiを使用

View Slide

Kubernetesカスタムオペレータを
軸にした技術課題解決
32

View Slide

こだわりの実現のための技術選定
33
TektonでCI/CDの
両方を実現
User Self Managed
デプロイツールどうする
マルチクラウドデプロイどうする
CI/CDパイプラインのマルチステー
ジに跨る再利用性のための汎化
CDのためのリトライ機能
大量のパラメータ管理
UX改善のイテレーションを速く回す
アーキテクチャ
こだわり課題選定技術

View Slide

こだわりの実現のための技術選定
34
TektonでCI/CDの
両方を実現
User Self Managed
デプロイツールどうする
マルチクラウドデプロイどうする
CI/CDパイプラインのマルチステー
ジに跨る再利用性のための汎化
CDのためのリトライ機能
大量のパラメータ管理
CUE x Pulumiによる
マルチクラウドデプロイ
k8sカスタムオペレータで
Tektonを拡張
モジュラーモノリスと
マイクロサービスの
複合構成
こだわり課題選定技術
UX改善のイテレーションを速く回す
アーキテクチャ

View Slide

1: CUE x Pulumiによるマルチクラウドデプロイ
● Pulumiの特徴
○ Terraform ProviderからPluginを生成
○ 汎用言語でインフラを制御できる
○ desired stateとcurrent stateを持ち、
Reconciliationを行うことができる（非常駐型）
● CUEと組み合わせる
○ Pluginのgo structからCUE Schemaを生成
○ CUEでYAMLを生成しPulumiにload
○ Pulumi stateを用いて
Delivery & Reconciliation
YAML go struct
PulumiやCUE compilerなどは
標準タスク・コンテナとして提供しています
Task
Step Step Step
Infrastructure
Adapter
Infrastructure
Manifest
35

View Slide

2-1: k8sカスタムオペレータでTektonを拡張
● AssemblyLine： Pipeline・Taskの2層では足りないので、もう一層追加
AssemblyLine
Pipeline
Task Task
Pipeline
Task Task
複数アプリケーション・環境を扱う複雑なワークフローを構成
再利用しやすい単位でワークフローをまとめる
（Build、Deploy、Releaseなど）
再利用しやすい単位で処理をまとめ汎化する
（git checkout、img-build、pushなど）
Tektonには存在しない、独自のレイヤー
36
PipelineをブロックとしてDAGを組み
順番に処理できる

View Slide

● AssemblyLine： Pipeline・Taskの2層では足りないので、もう一層追加
○ Build、Deploy、Releaseの単位で再利用可能なブロックを作りたい => Pipelineをブロックに
Adapterから生成されたPipelineを
AssemblyLineを作るビルディングブロックとして使用し
複雑なCI/CDパイプラインが構成できる
37
Cloud Native
Adapter

View Slide

● 複数環境へのデプロイで必須なリトライ機能を、
AssemblyLine Operatorで実装
○ Tektonには、失敗したPipelineを再開するリトライ機能がない
○ CIなら良いが、複数環境にデプロイする CDの場合は致命的
multisite-release
siteA-release siteB-release siteC-release
AssemblyLine
Pipeline
再実行可能なエラーの場合は、失敗したTaskから同じマニフェスト・パラメータでやり直したい
Task
Tektonに
リトライ機能はない
これが担保されないと、
構成ドリフトで事故につながる
38

View Slide

● 複数環境へのデプロイで必須なリトライ機能を、
AssemblyLine Operatorで実装
○ Tektonの”Pipeline/PipelineRun”の設計を参考にしつつ、状態保持の層を追加
PipelineRunを作ることで、
Pipelineに定義されたTaskを実行
AssemblyLineFactoryを作ることで、
AssemblyLineに定義された
Pipelineを実行
AssemblyLineFactoryは、初回 orリトライの
都度、AssemblyLineRunを生成
実行済のTaskはWhenExpressionでSkipし、
状態を引き継ぎつつ未完了のところから再開
39

View Slide

● パラメータの問題
○ 複数のPipelineを束ねてCDも行うAssemblyLineは、パラメータが膨大
○ Pipeline・Taskのレイヤでマッピングと注入ができるので、値の追跡が大変
AssemblyLine
マッピング注入
Pipeline
AssemblyLine・Pipeline・Taskの定義を全て確認しないと
最終的に使われる値がわからない
（データマッパーが多段で、透明性が低い）
Pipeline
すべてのPipeline・Taskのパラメータの指定が
必要なため、パラメータが膨大
Task
Task
Task
注入
Task
Task
Task
注入
40

View Slide

● AssemblyLineにパラメータバインディングを集約 => 透明性・保守性を向上
○ Pipeline・Taskは自動生成されるため、 Pipelineインターフェースが一意に決定する
○ アプリケーション x 環境の単位でパラメータセットを配置
○ AssemblyLineは、パラメータセットと Pipelineの紐付けだけを行う
Pipeline
Pipeline
Task
Task
Task
注入
Task
Task
Task
注入
Cloud Native
Adapter
生成
AssemblyLine
- Pipeline・Taskが自動生成されマッピング・注入が一意に決定
- メタプログラミングでパラメータを減らす（カリー化）
41

View Slide

Pipeline
Pipeline
Task
Task
Task
注入
Task
Task
Task
注入
Cloud Native
Adapter
生成
Config
AppA x Staging
AppA x Prod
AppB x Staging
パラメータセット
WebUIからの操作で
`1アプリx1環境` ごとに
パラメータセットを作成
AssemblyLine
42

View Slide

Pipeline
Pipeline
Task
Task
Task
注入
Task
Task
Task
注入
Cloud Native
Adapter
生成
AssemblyLine
AppA x Staging
Build pipeline
AppA x Prod
Release pipeline
Config
AppA x Staging
AppA x Prod
AppB x Staging
パラメータセット
WebUIからの操作で
`1アプリx1環境` ごとに
パラメータセットを作成
パラメータセット・Pipelineの紐付けと
パラメータマッピングが責務。
マッピング層がここだけになり透明性向上
43

View Slide

3: モジュラーモノリスとマイクロサービスの複合
● UI/APIはモジュラーモノリスを採用
○ 開発速度を重視
○ 「境界づけられたコンテキスト」で分離可能にしつつ、
必要になるまではやらない
● Tektonを汎用Jobスケジューラとして活用する
○ CI/CD以外のTaskも挿入し、DAG順に処理できる
○ 例：Approval Request、Artifact Upload
● k8sカスタムオペレータがAPIサーバとTektonを橋渡し
○ Pod起動時に、構成情報などのコンテキストも渡す
○ AssemblyLine・Pipelineの状態遷移時（Pod終了時）
に処理をフックする
…
…
44

View Slide

まとめ
45

View Slide

まとめ
● CUEとTektonを活用して、デリバリーパイプラインまで含めて一緒にパッケージし
マニフェスト生成からリリースまで支援する
SaaSプロダクトの実例を紹介
● 様々な技術課題を解決しながら進化を続けています
○ IaCマニフェスト・Tekton Pipelineをまとめてパッケージし、
プラクティスの共有を可能にする独自の Infrastructure as Code
○ CDにも応用できるように Tektonを拡張するk8sカスタムオペレータ
○ User Self-Managedを実現するためのUI/UX改善、Observability向上
○ etc…
● 来年度にはグループ外にも公開して、皆様にお披露目できる。。。かも？
46

View Slide

We are hiring
● プロダクト志向で、DevOpsプラットフォーム = Qmonus Value Streamを一緒に開発してくれるメン
バーを募集しています！
47

View Slide

マニフェストレスで使える IaC・CI/CD のSaaSプロダクト化への挑戦

マニフェストレスで使える IaC・CI/CD のSaaSプロダクト化への挑戦

Hiroki Okui

More Decks by Hiroki Okui

Other Decks in Technology

Featured

Transcript