CNDT2021、NTTComのアーキテクトがDevOpsに繋がるフィードバックループを解説

CNDT2021から、NTTコミュニケーションズ株式会社のプラットフォームアーキテクトがクラウドネイティブなシステムにおけるフィードバックループに関する考察を解説したセッションを紹介する。プレゼンターはイノベーションセンターに所属する牧志純氏だ。

プレゼンテーションを行う牧志氏

動画：クラウドを最大限活用するInfrastructure as Codeを考えよう

タイトルは「クラウドを最大限活用するInfrastructure as Codeを考えよう」となっているが、前半はInfrastructure as Code（IaC）の定義からコード化されたインフラストラクチャーに対する変更のプロセスを分解や、ツールの紹介を交えて考察を行っている。そして後半にNTTComが提供するプラットフォームにおけるIaCの実装について解説するという内容だ。後半はデモを交えてNTTComが採用したオープンソースのプログラミング言語CUEについて解説する盛り沢山のセッションとなった。

IaCに関する考察。単にツールだけでは実現できないと解説

自己紹介に続いてNTTComの提供するサービスについて簡単に触れた後に、今回の本題であるIaCについて解説。競争力を強めるために、アプリケーションだけではなくインフラストラクチャーについても素早く安全に実装できることが求められていると説明しながらも、単にツールを導入するだけでは実現できず、組織や変更に対する意識を変える必要があることを強調した。

IaCを4つのプロセスに分解して解説

ここで注意したいのは、牧志氏がこのスライドで説明する「ユーザーインターフェース」はIaCにおけるコード、つまりインフラに対する設定情報を指していることだろう。一般的な用語の「ユーザーインターフェース」とはかなり違うので留意されたい。User Interfaceがコードの定義、Workflowがインフラへの適用方法、Testがインフラの状態確認、Feedback Loopが定義されたインフラと実体との差異の解消方法という風にIaCを分解しているが、CI/CDの中身を分解していると言えなくもない。インフラの設定情報をコード化するだけではなく、定義と実体の違いをどのように一致させるか？ について、ここからツールを例に挙げて解説が始まった。

TerraformとKubernetesを例にプロセスを解説

TerraformとKubernetesを例にとり、4つのプロセスがどのように実装されているのかを解説することで、それぞれのツールの特徴が現れている。ここからはTerraformとKubernetesについてUser Interface、Workflow、Test、Feedback Loopについて解説を行った。

コードの定義方法の違いを解説

User InterfaceではTerraformがHCL、KubernetesがYAMLによってインフラストラクチャーの定義情報を記述することを説明。言語は違うもののやっていることは同じで、システムの規模が大きくなれば、共通部分と環境依存の部分を分けて管理したくなるという傾向について説明した。この傾向はこの後で解説されるKubernetesのManifestオーバーレイツールであるKustomizeの必要性に繋がる内容だ。

Testはインフラストラクチャーへの設定を確認するためのプロセス

続いてWorkflow、Test、Feedback Loopについても解説し、Testにおいては構成情報を確認するためのサンドボックス機能などが必要となってくるだろうとして、ここでも後半で説明されるCUE言語のための前口上という内容となった。

Feedback Loopの解説。KubernetesはReconciliation Loopだ

ここでこの4つのプロセスをどのツールで実装するのか？ については「対象が何なのか？」「どの程度の速度でFeedback Loopが必要とされているのか？」によって変わってくると説明した。

GCPのインフラとコンテナの設定を行うのでは規模と速度が違うことを説明

しかしインフラストラクチャーの規模が拡大するに従ってコード自体が複雑になってくることから、プログラミング言語によるモジュール化やテンプレート化などが必要になると説明した。

リソースが増大してくるとインフラのためのコードの管理が複雑に

そして、インフラからアプリケーションを格納するコンテナの管理までをひとつのツールで完結することには無理があると説明。ここではサーバーやクラスターなどの設定を行う場合と、アプリケーションに含まれる少数のコンテナを同じツールでライフサイクル管理を行うことが難しいことを示している。

異なるライフサイクルを持つ対象をひとつのツールで管理するのは無理

Kubernetesの例では、ArgoCDをKubernetesの設定情報管理のためのツールとして挙げているが、他にもSpinnakerやこの後でも言及されるTektonなども存在する。

牧志氏が体験したIaCにおける難しさの例

そして牧志氏が個人的に経験したIaCにおける問題点を挙げて、IaCを実装する難しさを解説した。ここから各プロセスにおけるツールを紹介しながら解決策を紹介した。

KubernetesのオーバーレイツールKustomizeの紹介

KustomizeはKubernetesの構成情報を、共通部分と環境依存部分（例えば開発環境と本番環境の違い）とに分けることで、共通部分に対してオーバーレイすることで環境設定をレイヤーとして管理することができるツールだ。Kubernetesの1.14から含まれているツールになる。ただしYAMLによって記述するために表現力が限定的で、内容の検証を行う機能が弱いという。

Pulumiの紹介

次にPulumiを紹介。PulumiはPythonなどのプログラミング言語でIaCを実装することができるツールで、Feedback Loopも実装されていると解説。

Kubernetesを上位から制御するCrossplaneを紹介

Crossplaneは、複数のクラウドにおけるKubernetesをKubernetesによって制御するためのオープンソースソフトウェアだ。Kubernetesをベースとしたシステムに対するIaCのプラットフォームとして、エコシステムが徐々に拡大しており期待していると説明した。

2021年4月にCrossplaneの開発をリードするUpboundのCEOによる解説を紹介しているので、ぜひ参照して欲しい。

Crossplaneの紹介記事：マルチクラウドを制御するユニバーサルなコントロールプレーンCrossplane

またCrossplaneは、Kubernetesを複数のクラウドに跨ったKubernetes-as-a-Serviceとして提供する際の有力な選択肢であるとして、PaaSのベースになり得るソフトウェアであると紹介した。

PaaSのベースになり得るCrossplane

ここで牧志氏は、GoogleのKelsey Hightower氏が提唱するConfiguration as Dataというコンセプトを紹介した。これは設定情報をデータとして扱い、設定情報の生成方法、つまりプログラミング言語＝User Interfaceとは別の物として扱うという、新しい発想のインフラストラクチャー管理の方法だ。

Configuration as Dataとは

そしてここでFeedback Loopについて、DevOpsもFeedback Loopのひとつであり、理想の状態と実態を合致させるという意味では同じであると説明。その上でシステムの特性によってどのような規模、速度にするべきかを考える必要があるとして、CrossplaneのようにすべてをKubernetesに合わせる発想は、分散コンピューティングでは難しさがあることを説明した。

Feedback Loopに関する考察

また設定情報のコード化（User Interface）についても、Config情報をハードコードする方法からパラメータ化、スクリプト化、独自言語に至るまでの段階が、それぞれの組織で発生しうることを解説し、プログラミング言語による柔軟性と、シンプルな設定情報のハードコードという両極端なケースがあることを説明した。ここではどれが良くてどれが悪いというのではなく、そういうことが起こり得る、その上でバランスを取る必要があるというのが牧志氏のポイントだろう。

CUE言語の紹介

以上をふまえて牧志氏が紹介したのは、Googleのエンジニアがゼロから開発を行ったCUE言語だ。CUEの特徴である構成情報の記述に利点があるデータ結合機能、データの検査が事前に行えることなどの利点を解説した。

NTTComが開発するQmonus Value Streamの紹介

ここからはデモを交えて、NTTComが開発したQmonus Value Streamというプラットフォーム上においてCUE言語の利点を解説した。ここではKubernetesの上にRedisを配備し、その後でGCPの中のRedisに置き換え、さらに使用するメモリーサイズを書き換えるという一連の作業を、CUE言語によるコードによって行うというものだ。

CUEを使ってPulumi、TektonなどからKubernetes環境を生成

デモとしてはGCPが提供しているECサイトのデザインパターンを応用して、それに対する変更をCUEから行うというものだ。デモの後半では単に変更を実装するだけではなく、CUEによる検証が可能であることが強調された。セッションの前半で解説された「YAMLでは構成の検証機能が弱い」という部分に対する回答になっていることに注目したい。

GCPのサンプルを使ってデモを実行

ここでFeedback Loopについて単一のツールではすべてのニーズを満たせないという見地から、大きなループではなくKubernetesのリソースだけを書き換えるというCI/CDパイプラインによるFeedback Loopも現実的にはあり得るとして解説を行った。

KubernetesのReconciliation Loopを使う場合も

最後にまとめとして、今後のソフトウェア開発においてはIaCが必須であることを強調し、コードの定義方法そしてFeedback Loopをどのようにして組織やシステムに合わせて選択するべきか、これが最も重要だと説明してセッションを終えた。

CUEに関しては以下の公式サイトを参照されたい。

CUE公式サイト：https://cuelang.org/

またセッション内のデモで使われていたKubernetesの環境の可視化には、VMwareが公開しているOctantというツールが利用されている。こちらも公式サイトで確認して欲しい。

Octant公式GitHub：https://github.com/vmware-tanzu/octant

またNTTComが公開しているPodCastでは、牧志氏によるQmonus Value Streamの紹介、CUEを選択した背景などを語っている。

参考：https://fukabori.fm/episode/50

今回はインフラストラクチャーに関して「設定情報をコードとしてどのように表現するべきか？」という命題に対して、NTTComはCUEを選択したということだろう。実際には、構成情報をどのように管理するべきかというGitOpsに繋がるポイントも必要だろう。牧志氏には、その辺りも踏まえた内容も期待したい。