CNDT 2022、NTTコムのエンジニアがマニフェストレスを実現したIaCのためのSaaSを解説

CNDT 2022から、NTTコミュニケーションズ株式会社のエンジニア2名によるマニフェストレスのインフラストラクチャーアズコード（IaC）を実現した社内向けのSaaSプラットフォーム実装の技術的な解説を行うセッションを紹介する。プレゼンテーションを行ったのはイノベーションセンター所属の浅井孝太氏と奥井寛樹氏だ。セッションは2つのパートに分けて前半を浅井氏が、後半を奥井氏が担当する形で行われた。

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

プレゼンテーションを行う浅井氏（左）と奥井氏（右）

前半はSaaS開発の概略と苦労話

セッションは「マニフェストレスで使えるIaC・CI/CDのSaaSプロダクト化への挑戦」と題されているように、アプリケーション開発者が必要とするプラットフォームの準備とアプリケーションリリースまでの段階（ビルド、テスト、デプロイ）をアプリケーション開発者自身で個別に実行しなければならない点が大きな負担になるということを解消するために、インフラストラクチャーの定義、それからビルド、テスト、デプロイという作業を一気通貫に行うためのプラットフォーム開発の苦労話という内容となった。

アプリケーション開発者の負担が大きいことが問題

タイトルには特定の名称が登場していないが、このプラットフォームはQmonus Value Streamと呼ばれるNTTグループ向けのSaaSを指しており、そこを最初に理解しておく必要があるだろう。

Qmonus Value Streamについては2022年6月に公開されたブログ記事の参照をお勧めする。

●参考：Qmonus Value Streamに関するイントロダクション

そこでそれぞれのアプリケーションの特性に合わせてテンプレートを予め用意しておき、それを再利用することでシステム構成の定義、ビルド、デプロイまでの各段階も自動化しようと言うのが目的だ。

アプリケーションのパターンに合わせてテンプレート化

その発想からSaaSとして開発されたのが、Qmonus Value Streamだ。

テストからリリース、モニタリングを素早く回すのがQmonus Value Streamのカバーする範囲

そのためにCUE言語を使ってIaCを実現したのが、Cloud Native Adapterと呼ばれるソフトウェアになる。これはアプリケーション実行のためのインフラストラクチャー定義とビルド、テスト、デプロイのワークフローをCUE言語で記述することで、インフラストラクチャーの構成ファイルとパイプライン定義ファイルを生成する機能を持つ。アプリケーション開発者は必要と思われる構成やパイプラインを選択するだけで済み、構成定義を手動で記述する必要はない。

Cloud Native Adapterの特徴はインフラ定義とワークフローを同時に生成する部分

この例ではインフラストラクチャーの定義に関してはKubernetesの構成情報、そして外部に対するIP公開のための定義を選択することでGoogle Kubernetes Engine（GKE）上の設定が生成されることを示している。

Public API AdapterとDeployment Adapterを組み合わせてGKEの実装定義を生成

ワークフローについての例では、BuildKit Build AdapterとSimple Deploy Adapterを使ってビルド、デプロイ、リリースまでを実現している。ビルドのプロセスはBuildKit Build Adapterが担当し、デプロイの部分をSimple Deploy Adapterが担当するわけだが、アプリケーション開発者はそれぞれを選択するだけで自動化されるということだろう。

ワークフローもビルドからリリースまでを一気に生成する

Cloud Native Adapterについては、Tektonを用いてインフラストラクチャーの構成定義とパイプライン定義をまとめて生成するという部分が最も特徴的な機能だろう。

使われているソフトウェアについてまとめたのが次のスライドだ。

マニフェストレスを実現したテクノロジースタックの説明

ここではTektonとCUEが主役として紹介されているが、実際にはPulumiも利用されていることが後半の説明で明らかになる。

Tektonについては簡単に紹介した後で、CUEについても選択した背景などを解説した。CUEについてはこれもNTTコミュニケーションズのエンジニアによる解説ブログが公開されているので、以下を参考にして欲しい。

●参考：CUEに関するNTTコミュニケーションズのブログ

後半はSaaSに関する詳細な説明

後半は奥井氏にバトンタッチしてより詳細な解説が行われた。

IaCとCI/CDをSaaS化した背景の説明

奥井氏は「マニフェストレスになっただけでは、ソフトウェアデリバリのサイクルの一部が自動化されただけで開発サイクルの速度を上げるためには足らない」ことを説明。独自のIaCを提供するなら、デリバリについてもセットで提供するべきという意見だ。

そしてCI/CDについてはTektonをCIとCDの両方で利用することの利点を解説。ツールが減り、シンプルになること、そしてKubernetes以外にも対応できることなどを理由として挙げた。

Tektonだけを使ってArgoCDやFluxなどを使わないことでシンプルに

またアプリケーション開発者がセルフサービスで利用できることを実現するために、グラフィカルなユーザーインターフェースが必要であることなどを挙げて解説を行ったが、当然、利点だけではなく課題も存在することにも言及し、その解決方法についても解説を行った。

セルフサービスのためのインターフェースが必要

ここから、こだわりとして挙げたTektonでCI/CDをカバーすること、セルフサービスについての課題について解説された。特にTektonを拡張するカスタムオペレータを使った実装によって、CDにおけるリトライ機能、大量に発生するパラメータの対応について集中的に解説を行った。

TektonとCUEの採用によって発生した課題の解説

奥井氏は「CIではエラーが起こってパイプラインの実行が失敗しても再度実行すれば良いが、CDにおいてはエラーが起こったところで止まってしまうことも単純に頭から再実行することも許されない」点を強調し、標準のTektonのパイプライン、タスク、ステップにAssemblyLineという上のレイヤーを追加することで状態保持や管理を行う仕組みを追加したことを説明。

Tektonに新しいレイヤーを追加して課題を解決

これはKubernetesのカスタムオペレータを追加することで拡張したとして、パイプラインを構成するタスクの上位にAssemblyLineが追加されて実行されるという仕組みになる。

より複雑な制御を可能にするAssemblyLine

これはKubernetesのオペレータで実装されたカスタマイズによって、リトライ機能を実装するために利用されている。

リトライをCDプロセスで実装するために開発されたオペレータ

通常のTektonのパイプラインに1階層上の制御を実施するAssemblyLine

ただこれだけではパラメータがアプリケーション、パイプラインのステージ、そして実装する環境の乗算的に増えてしまう問題は解決できないことも示し、AssemblyLineはパラメータとパイプラインの紐付けだけを行うと解説。ここはもう少し深い解説が必要だろうが、今回は割愛された。

パラメータ爆発の問題は役割を整理することで解決？

最後のアプリケーションを使うユーザーに対する機能改善を素早く回すための仕組みについては、マイクロサービス化は行わず、モジュラーモノリスで開発するという指針に従っていること、そしてTektonを汎用スケジューラとして活用することなどを解説した。

UX改善を素早く回すための指針を解説

まとめとしてCUEの活用とTektonをカスタマイズしてインフラストラクチャー構成からワークフローまでカバーすることで、SaaSとしてアプリケーション開発者の負担を減らすことを目的に開発が進められていることを説明してセッションを終えた。マニフェストを手動で書くことをなくすこと、そしてTektonをカスタマイズすることでCI/CDを一つのツールで可能にしたQmonus Value Streamの背景を解説したセッションとなった。UpstreamのTektonとの整合性が若干心配になる内容だが、ぜひ、CD Foundationの主催するカンファレンスで発表してもらって、コミュニティの反応を知りたくなる内容となった。2023年度には社外向けにもサービス提供が可能になる可能性もあるということで、今後も注視していきたい。