$30 off During Our Annual Pro Sale. View Details »

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

Hiroki Okui
November 22, 2022

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

Hiroki Okui

November 22, 2022
Tweet

More Decks by Hiroki Okui

Other Decks in Technology

Transcript

  1. © NTT Communications Corporation All Rights Reserved. マニフェストレスで使える IaC・CI/CD のSaaSプロダクト化への挑戦

    NTTコミュニケーションズ イノベーションセンター 奥井 寛樹・浅井 孝太 1
  2. © NTT Communications Corporation All Rights Reserved. 目次 • マニフェストレスなIaC・CI/CD基盤をつくる目的

    • マニフェストレスを実現するための独自のIaC技術 • SaaS化に向けたこだわり • Kubernetesカスタムオペレータを軸にした技術課題解決 2
  3. © NTT Communications Corporation All Rights Reserved. 自己紹介 NTT コミュニケーションズ

    Software Engineer 浅井 孝太 略歴 • 2020年入社 • 伝送システムの在庫可視化システム開発 • DevOpsプラットフォーム開発 3
  4. © NTT Communications Corporation All Rights Reserved. マニフェストレスなIaC・CI/CD基盤を つくる目的 4

  5. © NTT Communications Corporation All Rights Reserved. 課題1: アプリ開発者の負担が大きい 人が足りない...

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

    ハードウェア 仮想マシン OS ストレージ システム構成 DB アプリ ユーザ側で全ての 環境を構築・運用 開発環境 ステージング環境 プロダクション環境 設計 構築 検証 運用 を担当するため、アプリ開発に注力できない ユーザ所有・管理 6
  7. © NTT Communications Corporation All Rights Reserved. 課題1の解決: プラクティスのカタログ化 クラウドにパターン化されたシステム構成を選択するだけで構成を管理できる

    ハードウェア 仮想マシン OS ストレージ システム構成 DB アプリ Qmonus Value Stream ユーザ所有・管理 Qmonus Value Stream ユーザ所有&Qmonus-VSで コントロール サービス開発者 ユーザ持ち込み クラウド サービス利用 サービス開発者がアプリ開発に注力できる ユーザに代わってデ リバリ アプリ開発 7
  8. © NTT Communications Corporation All Rights Reserved. 課題2: サイロ化による局所最適化 プロジェクトや部門単位でアーキテクチャを考えると局所最適化が繰り返される

    プロジェクトA 部門A プロジェクトB プロジェクトC 部門B プロジェクトD プロジェクトE 部門C プロジェクトF ・・・ 組織間でサイロ化が進み、加えて開発人員も不足 8
  9. © NTT Communications Corporation All Rights Reserved. 課題2の解決: ノウハウの共有・再利用 各組織から得たアーキテクチャ構成のノウハウを

    システム構成パターンとして蓄積 プロジェクトA 部門A プロジェクトB 部門B プロジェクトC 部門C ・・・ 蓄積したノウハウをシステム構成パターンとしてまとめて 各プロジェクトへ還元し、サイロ化を防止 Qmonus Value Stream 共通にした方が良いものがたくさんある • Infrastructure as Codeによる構成管理 • WAF / CDN / SSL policy / 証明書戦略.. 9
  10. © NTT Communications Corporation All Rights Reserved. 課題3: CI/CDパイプライン整備が大変 インフラやCI・CDパイプラインを構築するために多くのツールを

    組み合わせて使用する必要がある ツールの選定や構築・保守に多くの時間が掛かってしまう インフラ構成が決まれば CI・CDパイプラインが勝 手に出来上がればいいのに ... 10
  11. © NTT Communications Corporation All Rights Reserved. 課題3の解決: インフラ構成とCI/CDをバンドル システム構成パターンを選択するだけでCI・CDパイプラインのベースも出来上がる

    構成パターンA 構成パターンB 構成パターンC Build Scan Release サービス開発者がアプリ開発に注力できる 11
  12. © 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
  13. © NTT Communications Corporation All Rights Reserved. マニフェストレスを実現するための独自のIaC技術 Cloud Native

    Adapterについて 13
  14. © 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
  15. © 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
  16. © 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
  17. © 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
  18. © 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
  19. © 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
  20. © NTT Communications Corporation All Rights Reserved. 20 Demo -

    Qmonus Value Stream
  21. © 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
  22. © NTT Communications Corporation All Rights Reserved. Tekton • CI/CDシステムを作成するためのKubernetes

    Nativeなオープンソースフレームワーク • 処理の最小単位をContainerで定義できる (= Step) • 複数のContainerをシーケンシャルに実行 することで一連の処理を実現する (= Task) • 一連の処理(Task)の順序関係を指定したり,パラレルに実行 する (= Pipeline) Tektonの特徴 Build Pipeline Task Task Task 22
  23. © NTT Communications Corporation All Rights Reserved. CUE データの検証、configuration、コード生成などを実現するためのデータ記述言語 •

    Types are Values ◦ 値と型を区別しない ◦ 型による制約や検査がシンプルに記述できる • 制約によるデータ生成 ◦ CUEは継承のような仕組みを持たず、 結合の順序に関係なく一貫した結果を生成できる • プログラマビリティ ◦ Templatingやmodule化などが行える ◦ Go APIやProtocol Buffers, 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
  24. © 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
  25. © NTT Communications Corporation All Rights Reserved. CUEでAdapterを実現するための工夫 2/2 インターフェース規約を守ることで

    再帰的なCompositeが可能に より小さな単位でAdapterを作成して再利用性を 高めることが可能に 抽象度の高いより大きな規模の Adapterが作成可能に 25
  26. © NTT Communications Corporation All Rights Reserved. SaaS化に向けたこだわり 26

  27. © NTT Communications Corporation All Rights Reserved. 自己紹介 NTTコミュニケーションズ Software

    Engineer 奥井 寛樹 略歴 • 伝送システムのSDNコントローラ開発 • DevOpsプラットフォーム開発 • IoTデータ収集基盤のモダナイゼーション @HirokiOkui hrk091 27
  28. © NTT Communications Corporation All Rights Reserved. デリバリ基盤のSaaS化の必要性 28 •

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

    1. TektonでCI/CDを両方行う 2. User Self Managed 29
  30. © 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
  31. © 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を使用
  32. © NTT Communications Corporation All Rights Reserved. Kubernetesカスタムオペレータを 軸にした技術課題解決 32

  33. © NTT Communications Corporation All Rights Reserved. こだわりの実現のための技術選定 33 TektonでCI/CDの

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

    両方を実現 User Self Managed デプロイツールどうする マルチクラウドデプロイどうする CI/CDパイプラインのマルチステー ジに跨る再利用性のための汎化 CDのためのリトライ機能 大量のパラメータ管理 CUE x Pulumiによる マルチクラウドデプロイ k8sカスタムオペレータで Tektonを拡張 モジュラーモノリスと マイクロサービスの 複合構成 こだわり 課題 選定技術 UX改善のイテレーションを速く回す アーキテクチャ
  35. © 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
  36. © 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を組み 順番に処理できる
  37. © 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
  38. © 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
  39. © 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
  40. © 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
  41. © 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
  42. © 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
  43. © 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
  44. © 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
  45. © NTT Communications Corporation All Rights Reserved. まとめ 45

  46. © 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
  47. © NTT Communications Corporation All Rights Reserved. We are hiring

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