GKEのアップグレード運用の効率化

本稿はJCB Advent Calendar 2023の１２月２５日の記事です。

PFチームの平松です。

我々の部門で運営しているJDEPの最重要構成要素である、Google Kubernetes Engine (GKE) のアップグレードに関する取り組みを紹介したいと思います。

アップグレードサイクル

GKEの元となるOSSは知っての通りKubernetesですが、こちらのアップグレードサイクルはご存知でしょうか。

公式サイトに記載の通り、Kubernetesは4ヶ月ごとにマイナーバージョンがアップグレードされています。
Google CloudによるマネージドKubernetesであるGKEもこのアップグレードサイクルを基本的に踏襲しており、大体OSSの新バージョンがリリースされて1ヶ月の間にGKEの対応バージョンがRapidチャネルにリリースされ始め、その後徐々にRegularチャネル、Stableチャネルへとリリースしていきます。
なお、GKEはサポートされるマイナーバージョンをRegularチャネルでのリリース後の12ヶ月を含む14ヶ月間維持することとしており、エンタープライズでの安定な運用を維持するためには計画的にアップグレードを遂行する必要があります。

チャネルを設定しておくと、チャネル別に定められたサイクルでGKEのアップグレードが自動で実施されます。
各チャネルの大まかな説明は以下の通りです。より詳しく確認したい場合は公式サイトをご参照ください。

チャネル	説明
Rapid	Kubernetesの最新リリースをいち早く取り込む場合に利用する。ただし安定版ではないため、GKEのSLAは適用されない。
Regular	安定版として扱われるため、新機能の利用と可用性のバランスを保ちたい場合に有効。
Stable	新規性よりも安定に重きを置いたバージョン。

JDEPでは極力安定したバージョンによる運用を行うことを目指しており、かつバージョンアップコントロールは自分たちで行うこととしているため、チャネルの利用はしていません。
バージョンアップ方針としては、Rapidチャネルにリリースされた最新版をすぐに取り込むことはせず、Regularチャネルにリリースされてしばらく経った後の安定したと見込めるバージョンをターゲットに、原則Kubernetesと同様の4ヶ月周期でのバージョンアップサイクルにて更新を行っています。

JDEPのアップグレード方式

当初はJDEP上で運用されるアプリケーションの数も少なく、GKEのアップグレードもPFチーム主体で各アプリメンバーと調整の上実施できていましたが、JDEPの初期構築からしばらく経過して2桁を超えるアプリが運用されてきており、従来通りPF主体で各アプリの要望を受け付けた上でのアップグレードを進めることが徐々に困難になってきました。
そうした背景もあり、さらに今後もJDEPで運用するアプリ数の増加傾向が見込まれるため、アプリチームが増加しても工数が単純増しないアップグレードプロセスの構築は必要不可欠なものとなってきていました。

従来のアップグレードプロセス

JDEPにおいてGKEのアップグレード作業を実施し始めた2021年の段階では、GKEのノードプールアップグレードはサージ方式のアップグレードしか存在しなかったので、以下のプロセスにて実質的に手動でBlue/Greenアップグレードとなるように作業を実施していました。

クラスタのコントロールプレーンのアップグレードを実施する
アップグレード先バージョンのノードプールを新たに作成する
旧ノードプールのノードを1つCordonする
新ノードプールのノードに、3. でCordonしたノードで動作しているPodをDrainする
3,4の処理により、旧ノードプールで動作していたPodを1つずつ順番に新ノードプールに載せ替えます。
基本的に業務アプリはレプリカ数2以上の設定なので、極力ダウンタイムを抑えた状態での載せ替えプロセスとなります。
3,4を全てのノードに対して実施する
全ノード移行が完了したら、旧ノードプールを削除する

なお、1〜6の工程実施中の間、アプリのSLOを監視することでアップグレード時のトラブル有無を判断しています。

問題へのアプローチ

上記で記載した通り、運用アプリの数が増えていき、アプリごとの特性もオンラインアプリからバッチ処理・決済に関わるミッションクリティカル処理など多岐に渡る中で、双方の要望を合わせたスケジュール調整を行うことが近年では必須となってきていました。しかし、従来のプロセスは運用アプリが増えれば増えるほどアップグレードにかかる工数・監視コストも肥大化していくため、このままでは作業者の負荷増加によるオペミス・コミュニケーションロスの懸念が日に日に増していく状況でした。
そこで、アプリが増えても作業者の負荷が単純増しないアップグレードプロセスの構築に取り組んできました。

ポイントは以下2点です。

GKEノードプールのBlue/Greenアップグレードの適用
Google Workflowを用いたアップグレードコマンド実行とアプリチーム事前準備のオートメーション化

GKEノードプールのBlue/Greenアップグレードの適用

こちらについては技術的な背景があります。

2022年7月に、GKEの新機能としてノードプールのBlue/Greenアップグレードに対応いたしました。（公式ドキュメント：Blue/Green アップグレード）
Blue/Greenアップグレードを試行してみたところ、ほぼ我々が従来行なっていたノードプールアップグレードとほとんど同じ動き方でアップグレードが進行することが確認でき、オートメーション化に利用できると判断しました。

さらに、同じく2022年にこれまではノードプールのアップグレードコマンドが一度実行したら成功 or 失敗するまで止められなかったものが、任意のタイミングで停止可能となったことです。 (公式ドキュメント：ノードプールのアップグレードをキャンセルする)
これにより、上記Blue/Greenアップグレードをコマンドで実行している最中にSLOに問題があればすぐにアップグレードを停止してロールバックすることが可能となり、手作業と同様のきめ細やかなロールバック判断・実行ができるようになりました。

上記2点のGKE側の機能追加により、アップグレードプロセスとしての既存のサービスレベルを満たした上でのオートメーション化の土台が整ったといえます。

アップグレードコマンド実行と事前準備のオートメーション化

上記の技術的背景を元に、Google Workflowを用いてアップグレード当日作業のオートメーション化を実現することができました。ただしこれだけでは運用対象となるアプリの増加によるアップグレードタイミングの調整コストの肥大化は防ぐことができません。

これを解決するため、以下のようなアップグレードプロセスを考案しました。

アップグレードの日付に関するスケジュールを事前に決めておき、周知を行う
当日、準備フェーズとして1時間程度のまとまった時間を定め、各アプリチームごとに必要な準備（アップグレード作業対象時間にバッチ処理を予定しているアプリは、開始時間をずらす等の対応）を実施してもらい、準備完了したら指定したCallback URLにレスポンスを返してもらう
以上をGoogle Workflowによりオートメーション化し、アップグレードの自動化と連動する

この仕組みを実装することで、全てのアプリチームの準備が完了したら、Workflowの次のステップ＝Blue/Greenアップグレードコマンドを実行する動作を実現することができました。

取り組み実践

以上の仕組みを構築し、GKEのアップグレードプロセスの変革を行いました。結果的にアップグレードにかかる作業手番を21手番→7手番と大幅に削減することができ、現場の声としても以下のようなフィードバックを得ることができました。

操作手番が削減され、オペミスも大分予防できると感じた。
途中のログインし直しや状態確認等の細かい作業手番が削減でき、作業に対して心の余裕ができた。

事前準備フェーズ導入による作業時のコミュニケーションコスト削減もStage環境での試行を経て本番環境アップグレード時に適用し、大きな混乱もなく当日はスムーズに実施することができました。

終わりに

今回はJDEPで実現したGKEのアップグレードプロセス改善についてご説明いたしました。

なお、JDEPのもう一つの重要構成要素であるAnthos Service Meshについても改善策の適用を実施しておりまして、こちらについては別の機会にて紹介したいと思います。

また、有志によるJCBアドベントカレンダー投稿はこれにて閉幕となります。
いかがでしたでしょうか。少しでも我々の活動に興味を持っていただけたら幸いです。

最後になりますが、JCBでは我々と一緒に働きたいという人材を募集しています。詳しい募集要項等については採用ページをご覧下さい。

ではでは、Merry Christmas!!

本文および図表中では、「™」、「®」を明記しておりません。 Google Cloud, GCPならびにすべてのGoogleの商標およびロゴはGoogle LLCの商標または登録商標です。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。