Kubernetes導入に不可欠なアップグレード戦略
今回Kubernetes導入に課題を感じている現場の開発者向けに、Kubernetes導入におけるアップデート戦略やCI/CDの実践を紹介してくれたのは、Chatworkプロダクト本部SRE部の坂本諒氏と佐々木真也氏。そして聞き手はアマゾンウェブサービスジャパン ソリューションアーキテクトの濱真一氏が務めた。
最初のテーマは、Kubernetesを運用するにあたって、避けることができないアップグレード戦略について。既存のクラスタをどんどん更新していくインプレースアップグレードと、新しいバージョンを稼働させながら古いクラスタを置き換えるマイグレーションアップグレードという二つの方法が一般的だが、Chatworkは後者を採用している。
マイグレーションアップグレードは毎回環境を作ることになるため、Chatworkでは可能な限り自動化して、クラスタ自体を非常にImmutableに扱えるようにしている。まずはこのEKSでのImmutable Clusterによる運用に至るまでの経緯と、どのようにアップデートを行っているかについて、坂本氏が紹介を行った。
Chatworkでは2016年12月からKubernetesを採用しているが、当時はまだEKSがなかったため、kube-awsをしていた。年に1回のアップデートだったため差分も多く、ローリングアップデートが不可能だったため、この頃からImmutable Clusterによる運用は行っていた。
「クラスタアップデートにおける問題は、アプリケーション側の移行に時間がかかること。Kubernetesの変更箇所が多く、その差分を反映していくのは大きな負担です。またデプロイツールもクラスタ依存の部分が多く、負担が大きいものでした。Kubernetesの新しい機能が使えないことも問題になっていましたね」
そこでEKSが出たタイミングで、ある程度ツールが揃ってきたこともあり、ChatworkはEKSに移行することを決める。EKSの強みを活かす構築ツールとして、eksctlを採用。ニッチなツールは減らすことで、クラスタ構築の負荷を減らした。
「どのタイミングでアップデートしていくかは結構重要な問題でしたが、1年に1回では変更差分が多くて大変だったので、常に変更に追従していく方針にしました」
アプリケーション側のデプロイの負荷を減らすために、後述するHelmfileというツールとGitOpsを採用している。
最終的に当初の目標であった3か月に1回のアップデートを行っている。アップデートする回数は多くなったものの、変更箇所が少ないので、結果的に負荷は少なくなった。これにより、現在は最新バージョンの1.19まで常に追従してきている状態だという。
クラスタアップデートの流れは、下記の図のようになる。SREがバージョンごとのクラスタを作成し、クラスタに準備ができた段階でアプリケーションチームが移行する。
クラスタアップデートの流れ（クラスタ作成）
クラスタのアップデートの流れは、下記の図のように重要なコンポーネントが2つあり、AWS Load Balancer ControllerはAWSのアプリケーションロードバランサーを境界にして切り替えている。もう一つ重要なのはExternal DNSで、Route53の加重レコードを切り替えて、重みづけによってそれぞれのクラスターのリクエストを振り分けにしている。
「最初は新しいクラスター外の重みをゼロにして切り替え、徐々に割合を上げていって問題がなければ、古いほうをゼロにしてもそのままアプリケーションを落とすという切り替えを実施しています」
クラスタアップデートの流れ（アプリケーションの移行）
ここまでの内容に関して濱氏は、SREのインフラチームが管理ツール自体を管理しつつも、Kubernetesのクラスター管理が必要なアドオンは、いわゆるKubernetesのマニフェストを開発者に委ねられている点をポイントに挙げたうえで、チーム全体のクラスタとして共有する体制をどう浸透させたのか質問が投げかけた。
「DevOpsでやっていきたいという方針が最初に決まっていたこともあったが、なるべく開発側の負荷を減らすことを一番に重要視しました。変更する箇所をできるだけ減らしたり、質問にすぐ答えられる環境を作ったりするなどですね。結果的には、開発側から『こういう機能できませんか』という提案が来るなど、全体としては良い流れになっています。組織全体のコミットは重要ですね。押し付け合って不満をためるよりも、お互いの最適作業を考えながら行うほうが更新作業も早く終わります」
