※この記事は、Speee Advent Calendar2日目の記事です。
昨日の記事はこちら

お疲れさまです、インフラとCICDを愛するデジタルトランスフォーメーション事業本部開発基盤グループの西田和史(@k_bigwheel)です。最近AzureADのTerraform化を検討しています。

先日、Kubernetes Meetup Tokyo #54というイベントがオンライン上でありました。

k8sjp.connpass.com

この回はKubeConとCNCon North America 2022という海外のKubernetesに関係したイベントのRecap(発表の意訳・日本語解説)がメインで、ここ数回で最も多いメイン発表者6人というとても注目度の高い回になりました。
個人的に面白かったのは巣立健太郎さんのKubeCon + CNCon Europe 2022 Recap ~ Istio Today and Tomorrow: Sidecars and Beyond - Speaker Deckで、以前からistioに関心のある人にとっては一番の?トピックであるAmbient Meshの実際の動作を紹介していました。

さて、このRecapとは異なるのですが、実は同じ回のLT枠で私も発表してきました。この記事ではLTで説明しきれなかったところを補足したり、そもそもの背景をもう少し丁寧に掘り下げようと思います。

そもそもなぜ無限検証環境が必要なのか

そもそもなぜこの仕組みが必要なのかというと、開発効率を上げるためです。なぜ無限検証環境があると開発効率が上がるかというと、人が増えるにつれ開発者間で検証環境の奪い合いが起きるためです。PMやディレクターへの確認のため、普段より長い間専有されることもあります。
これは開発体験を損ねるだけではなく、開発効率が下がります。
DevOpsチームの指標であるFour Keysのうちの特に 変更のリードタイム を大きく損ね、本来のチームの開発パフォーマンスを割り引いてしまうだけではなく、事実上の生産性の上限すら設定してしまいます。
もし、検証環境を無限に、かつ動的に増やしたり減らしたりすることができれば誰かが環境を使用し終わるまで待つ必要がありません。それだけはなく、検証環境を使用していいか、だれかが使用しているか、今どのブランチがデプロイされているかなどのコミュニケーションもまるごと不要になります。
そして、新たな環境を素早く動的に作る仕組みはKubernetesでこそ可能で、k8sの利点を生かした仕組みとして各社で実装されてきました。

弊社での~2020年までの無限検証環境

SpeeeのDX事業本部でも2020年頃までブランチデプロイを試験していましたが、結局定着することはありませんでした。
LT内ではCloudFrontと併用することができなかったことを理由として挙げていましたが、別の理由としてブランチデプロイでKubernetesクラスタを運用できる自信(キャパシティ)がチームになかったことが挙げられます。当時はまだArgo CDを導入しておらず、ブランチデプロイは動的なmanifestの生成と terraform apply で行っていました。
これがKubernetesクラスタ内のブラックボックス化を加速させ、Kubernetesクラスタの運用を難しくさせていました。それに加えて当時はまだ開発者とPMの数がそれほど多くなく、検証環境1つや2つでもなんとかなっていたため、思い切って一度ブランチデプロイをやめたのです。

2020~2021年

しかし、2020, 2021年と時間がたつに連れ開発者が増加し開発速度も段々加速していきました。その結果、手動で構築された検証環境の数は2, 3と段々増えていき、今一番多いシステムでは4環境あります。

こうなってくるとやはりブランチデプロイ、PRデプロイはやりたくなってきます。しかしCloudFrontの問題がある、どうしよう、と考えていたのが2021~2022年頃でした。

2022年

2022年の前半にはおそらくこうやればできるだろうという脳内設計は終わっていました。

最近仕事で従来無理めだと思っていたことを真面目に議論していたためか、一年ぐらいずっと無理だと思っていたことを再検証していたんだけど、解決の糸口が見つかったかもしれない。
— 西田和史(k.bigwheel) 開発基盤 / SRE ⌨️🖊️ (@k_bigwheel) February 22, 2022

あとは9月に検証環境を増やしてほしいという要望が来たので、そこに合わせて実際に実装して確かめてみた形です。2年前の時点では動的にmanifestを作成、kubectl apply していたことが問題でしたが、今はArgo CDでmanifestをすべてGit管理していて認識外のpodやnamespaceができることもありません。
その検証が成功し、自在に環境を増減できるようになったのはLT発表の通りです。