CI/CD Conference 2023から、GMOペパボのSREがVM/Kubernetes混在環境でのCI/CDについて解説

CI/CDに特化したカンファレンスCI/CD Conference 2023から、GMOペパボ株式会社のSREが解説する仮想マシンとKubernetesが混在した環境でのCI/CDの改善について解説するセッションを紹介する。プレゼンテーションを担当したのは2021年にGMOペパボに中途で入社したSREの渡部龍一氏だ。

●動画：インフラCI/CDの継続的改善の道のり

セッション開始から約8分は自己紹介と自社紹介に使われており、実質的なシステムの解説は以下のスライドから始まった。今回はスライドが別資料として公開されており、そこから引用している。

●参考（発表資料）：インフラCI/CD継続的改善の道のり

プライベートクラウドはOpenStack上の仮想マシンとコンテナの混在系

最初に、ペパボのシステムはOpenStackをベースにしたプライベートクラウドとAWS上のデータベースサービスなどで構成されているというシステムの構成を紹介した。アプリケーション自体は仮想マシンで実装されているものとKubernetes上のコンテナで実装されているものが混在していると説明した。実数としては仮想マシン上のワークロードがコンテナのワークロードを上回っている。なおオンプレ環境とAWS環境は専用線で接続されているという。

インフラストラクチャーの構成要素は以下の通りだ。

OpenStack、AWS、Kubernetesの上にGoやRubyでアプリが開発されている

またCI/CDについてはPuppetとServerspecを紹介し、Puppetについてはメインで使っている構成管理ツール、Serverspecについてはサーバー構成のテストを行うツールであると解説した。

仮想マシンの場合のCI/CDを説明。VMをデベロッパーがローカルに起動してテスト

このスライドでは、仮想マシンのワークロードについてはデベロッパーが個々のPCでVagrantを使って仮想マシンを起動してテストを行い、仮想マシンを収めたコンテナをDockerで作成、Puppetを使ってデプロイし、Serverspecがテストを行うという内容だ。仮想マシンなのにコンテナを使ってという部分はこの後で「CIは実際の仮想マシンではなくコンテナを使ってエミュレートしている」という説明が出てくるため、仮想マシンは実際にはコンテナの中で実行されているという意味だろうか。少し説明が足らない気がした。

KubernetesのCI/CDの説明。kubectlは使わずにGitからのPushでArgoCDが実行される

ここでKubernetes上のCI/CDを説明しているが、コマンドで直接Kubernetesを操作せずにGitOpsでGitへの構成情報の更新をトリガーにCI/CDが実行され、最終的にArgoCDがデプロイメントを行うということのようだ。

ここからペパボのCI/CDの問題点についての解説に移った。

CI/CDの問題点を列挙

具体的な問題の説明を行った渡部氏だが、問題点の依存関係や根本的な原因の解説がないため、多種多様な問題が頻発しているように見えるのが残念だ。

テストに時間がかかり過ぎる問題の解説。理解するのが難しい記述だ

テストに時間がかかる問題もローカルに仮想マシンを立ち上げてテスト、結果を確認した後にGitHubに変更をプッシュしてCIが実行されるという説明からは、テストの前後に必要な準備に時間がかかっているように読めてしまう。

テストのメインテナンスについても多くの現象が列挙されている

このスライドでの問題点もさまざまな不具合の現象が列挙されているが、それらを引き起こす根本原因についての解説がないために、ここから改善点を想定するのが難しいだろう。実際にテストに関する問題点の解決策が提示されているが、この問題点を抜本的に解決しているとは読み取れないのが残念だ。

構成情報と実際のサーバーで差分がある問題の紹介

ここのスライドに、ペパボの仮想マシン環境の特徴が言い表されていると言える。仮想マシンは可変（ミュータブル）であるという記述からサーバー構成がさまざまな経路で変更できてしまうことが想像できる。このような環境では構成情報を一元管理し、その変更方法をドキュメント化しても陳腐化するのは速いだろうし、変更を実施するのがSREではなくデベロッパーであるというのはそもそも無理があるだろう。

他にもインフラストラクチャーアズコードのためのツールがPuppet、Ansible、Chef、Terraformなどが存在し、運用のためのツールもスクリプトからPerl、Ruby、Python、Goなどで書かれていると紹介し、カオスな状況であることが理解できる。

それらの問題点を解決するための解説が次のスライドから始まっている。

さまざまな問題を解決する策を紹介

ここでは9つのポイントについて解説を行っているが、問題点の解説と同様に解決のためのポリシーや戦略が開示されてないため、パッチワーク的な解決策に見えてしまう。

CIの高速化、インフラテストの拡充、開発環境の整備、構成情報と実際のサーバーの相違が発生してしまう問題、仮想マシンとKubernetesの混在問題、パッケージの脆弱性検知などについて解説している。ここでも原因は何で、それに対して誰が何をしたのか？ その効果の定量的なデータは？ これらの点が外部からはわかりづらいと感じた。

仮想マシンからKubernetesへの移行も道半ば

このスライドでも仮想マシンのワークロードはなくならないという前提で、Kubernetes上ではなく仮想マシンの上でコンテナを実行するということが解決策であると説明されているが、新たに発生する「デプロイフローが複雑化する」という問題についての解決策が提示されていない。

改善の計測とイミュータブルなインフラの構築、そしてツールのアップデート

ここでは将来の計画を紹介。生産性の計測、イミュータブルなインフラストラクチャーの推進、CI/CDツールの継続的なアップデートが挙げられている。ミュータブルなサーバー環境になってしまったのはどうしてか、CI/CDツールが多過ぎることを解消する予定があるのか、などについての言及はなく、山積みの問題点を解消できるようには感じられなかったのは残念に思った。

まとめ。SRE以外が扱えるCI/CDを目指した結果、SREへの権限集中が発生したという

最後のまとめとしてもSRE以外のデベロッパーが触れるCI/CDを目指したが、ドキュメントが陳腐化することは解消されずコンテナと仮想マシン混在も解決されそうにないと総括されている。またSRE以外がCI/CDを触れるようにしたというが、結果としてSREに作業依頼が来ることはほぼなくなったにも関わらず、権限が集中してしまったという。問題点と解決の整理と何を目指して改善するのか？ をシンプルに書き起こした上で、この継続するチャレンジのアップデートを聞いてみたいと思える内容であった。