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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© NTT Communications Corporation All Rights Reserved. つくったもの：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

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© NTT Communications Corporation All Rights Reserved. Cloud Native Adapter Qmonus Value Stream独自のCUE言語を用いたInfrastructure as Code (IaC) 実装 Cloud Native Adapterは「インフラストラクチャ構成」と「ワークフロー」をまとめて統一的なインターフェースで記載が可能 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

Slide 15

Slide 15 text

© NTT Communications Corporation All Rights Reserved. Cloud Native Adapter 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

Slide 16

Slide 16 text

© NTT Communications Corporation All Rights Reserved. インフラストラクチャ構成アプリケーションを稼働させるクラウドアーキテクチャの構成 Public API Adapter Deployment Adapter Cloud Armor Cloud Load Balancing Cloud Armor Cloud Load Balancing Google Kubernetes Engine composite composite compile 16

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

© NTT Communications Corporation All Rights Reserved. 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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

© NTT Communications Corporation All Rights Reserved. 採用している技術スタックの紹介 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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

© NTT Communications Corporation All Rights Reserved. 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

Slide 24

Slide 24 text

© NTT Communications Corporation All Rights Reserved. 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

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

© NTT Communications Corporation All Rights Reserved. こだわり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を使用

Slide 32

Slide 32 text

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

© NTT Communications Corporation All Rights Reserved. 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

Slide 36

Slide 36 text

© NTT Communications Corporation All Rights Reserved. 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を組み順番に処理できる

Slide 37

Slide 37 text

© NTT Communications Corporation All Rights Reserved. 2-1: k8sカスタムオペレータでTektonを拡張 ● AssemblyLine： Pipeline・Taskの2層では足りないので、もう一層追加 ○ Build、Deploy、Releaseの単位で再利用可能なブロックを作りたい => Pipelineをブロックに Adapterから生成されたPipelineを AssemblyLineを作るビルディングブロックとして使用し複雑なCI/CDパイプラインが構成できる 37 Cloud Native Adapter

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

© NTT Communications Corporation All Rights Reserved. 2-2: k8sカスタムオペレータでTektonを拡張 ● 複数環境へのデプロイで必須なリトライ機能を、 AssemblyLine Operatorで実装 ○ Tektonの”Pipeline/PipelineRun”の設計を参考にしつつ、状態保持の層を追加 PipelineRunを作ることで、 Pipelineに定義されたTaskを実行 AssemblyLineFactoryを作ることで、 AssemblyLineに定義された Pipelineを実行 AssemblyLineFactoryは、初回 orリトライの都度、AssemblyLineRunを生成実行済のTaskはWhenExpressionでSkipし、状態を引き継ぎつつ未完了のところから再開 39

Slide 40

Slide 40 text

© NTT Communications Corporation All Rights Reserved. 2-3: k8sカスタムオペレータでTektonを拡張 ● パラメータの問題 ○ 複数のPipelineを束ねてCDも行うAssemblyLineは、パラメータが膨大 ○ Pipeline・Taskのレイヤでマッピングと注入ができるので、値の追跡が大変 AssemblyLine マッピング注入 Pipeline マッピング注入 AssemblyLine・Pipeline・Taskの定義を全て確認しないと最終的に使われる値がわからない（データマッパーが多段で、透明性が低い） Pipeline マッピング注入すべてのPipeline・Taskのパラメータの指定が必要なため、パラメータが膨大 Task Task Task 注入 Task Task Task 注入 40

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

© NTT Communications Corporation All Rights Reserved. 2-3: k8sカスタムオペレータでTektonを拡張 ● AssemblyLineにパラメータバインディングを集約 => 透明性・保守性を向上 ○ Pipeline・Taskは自動生成されるため、 Pipelineインターフェースが一意に決定する ○ アプリケーション x 環境の単位でパラメータセットを配置 ○ AssemblyLineは、パラメータセットと Pipelineの紐付けだけを行う 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

Slide 43

Slide 43 text

© NTT Communications Corporation All Rights Reserved. 2-3: k8sカスタムオペレータでTektonを拡張 ● AssemblyLineにパラメータバインディングを集約 => 透明性・保守性を向上 ○ Pipeline・Taskは自動生成されるため、 Pipelineインターフェースが一意に決定する ○ アプリケーション x 環境の単位でパラメータセットを配置 ○ AssemblyLineは、パラメータセットと Pipelineの紐付けだけを行う 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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Slide 46

Slide 46 text

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