先日行われた Chatwork Dev Day 2021 で、SRE部からは Immutable Clusterに対する定期Version Upgrade戦略 ということで、EKSのアップグレードへの対応について話しました。
ChatworkではSREだけでなく開発チームも含めて、EKSを導入した1.17以降、1.20までスキップすることなくアップグレードを実施しています。
今回は、技術的な話ではなく、組織としてどのようにEKSのアップグレードに対応していったかを説明したいと思います。
ChatworkのEKS運用
セッションの中でも話しましたが、ChatworkのEKSクラスタはマルチテナントで構成され、EKSのアップグレードについては、Blue/Green方式で行う想定にしています。
(そのへんの詳細、経緯についてはこちら) creators-note.chatwork.com
また、アプリケーションのデプロイについては、開発チームでManifest(helmfileを使用)を作成し、デプロイしてもらっています。
ですので、EKSのアップグレードは、SREのみで完結せず、開発チームに協力してもらいながら進めていく必要があります。
こういうケースでありがちなのが、SREで自分達の常識や理解で進めてしまい、開発チームからはなんのためにやっているのかよく分からない、そこはこちらには関係ない、といった話になり、うまく協力を得られないことがよく起こります。
こういうこと避けるために、協力してもらう人にアップグレードの必要性や実施方法等を共有し、全体像を理解してもらいながらすすめていくことが重要になります。
自分が知っていることを人が知っていると勝手に思い込まない。
大事なことなので2回言います。
自分が知っていることを人が知っていると勝手に思い込まない。
Chatworkで定期的なEKSアップグレードを組織として対応するにあたり、どういったことを共有し、どのようなことを決めていったかをまとめてみました。
1. EKSのバージョンライフサイクルの確認
まずは、SREとEKSアップグレードに関わる開発チームの方に、EKSアップグレードについての前提を説明して、理解してもらいましょう。
- 約3ヶ月おきに新バージョンがリリースされる
- 3世代がサポートされる(1.19以降は12ヶ月サポートに変更)
EKSを日々運用している人からすると、知ってるでしょ？ということかもしれませんが、そうでない人はそんなことは知らないかもしれません。情報を得るソースも違います。
ちゃんと説明して理解してもらうようにしましょう。
2. アップグレード方針
次にアップグレードに関する方針を決めます。
バージョンごとに実施するのか、そうでないのか、想定しているアップグレードの実施方法について、明確にします。
Chatworkでは下記のように決めました。
- バージョンごとにアップグレードする
- 切り替えについては、新バージョンのEKSクラスタを新規に構築し、Blue/Greenによる切り替えを行う
バージョンごとに必ずアップグレードする必要があるのか？
3世代サポートされるのであれば毎回やらなくてもいいのでは？と思う人もいると思います。
確かに必須ではないです。
その上で、なぜバージョンごとに実施しようとしているかを説明し、理解してもらいましょう。
一般的な理由としては、下記のようなものが考えられると思います。
- バージョン差が大きくなると変更箇所が大きくなり、変更コストが大きくなる可能性がある
- EOS(End Of Support)間際になるとスケジュールが逼迫する可能性がある
- 新機能が有用なことが多い
スキップできる数は？
”バージョンごとにアップグレードする” という方針にしましたが、実際にやってみると難しいという判断になるかもしれません。
思ったより作業負荷が大きい、途中で不具合が判明して解決に時間がかかる、別の大きな問題が発生してアップグレード作業にとれる時間がない・・・といった問題で該当バージョンのアップグレードをスキップする必要が出てくるかもしれません。
そういうときのために何バージョンならスキップできるかも把握しておいた方がいいと思います。
下の図は3ヶ月ごとにリリースされた想定で、バージョンをスキップしたときのEOSまでの期間を表したものです。
1月にリリースされたバージョン1を適用したとします。
1バージョンスキップした場合
4月にリリースされたバージョン2をスキップしたとしても、7月のバージョン3を適用すればEOSまでまだ6ヶ月あるので余裕はありそうです。
2バージョンスキップした場合
バージョン2、バージョン3の2つのバージョンをスキップすると、10月のバージョン4を適用することになりますが、リリースからEOSまで3ヶ月になり、このアップグレードで問題が発生すると、かなり余裕がない状態になりそうです。
2バージョンスキップしているので、変更点も多くなり、問題が発生する可能性も高くなると思います。
これを考慮して、Chatworkでは問題があったとしてもスキップするバージョンは1つまでということにしました。
3. アプリケーションの確認
方針が決まれば、移行するアプリケーションについて洗い出しを行います。
マルチテナントで構成されている場合は、クラスタ上で稼働しているアプリケーションの一覧を作成し、どういったアプリケーションが稼働しているのか把握します。
そして、下記の項目を確認します。
- 依存関係
- 二重稼働の可否
まず、アプリケーション間で依存関係があるものを確認します。
前述のとおり、新バージョンへの切り替えは、クラスタをBlue/Greenでアプリケーションごとに切り替えていく想定ですが、 同一クラスタ内で稼働していることが前提になっているアプリケーションがあれば、同時に移行する必要があります。
クラスタ内で名前解決しているものについても注意が必要です。
順番を考慮する必要があるアプリケーションがあるかもしれません。
二重稼働の可否については、新旧のクラスタで同時稼働することになるので、ライセンス的に問題がないか、同時に実行すると問題になるJob等がないかを把握し、ある場合は移行手順を考慮する必要があります。
4. スケジュール確認
移行対象が明らかになったら、次はスケジュールを落とし込んでいきます。
切り替え完了リミット
まず最初に新バージョンリリース日からいつまでに切り替えを完了させるかを決めます。
この日くらいまでに移行のメドがついてない場合は、今回のバージョンについては移行見送りという判断基準とします。
この基準がないと、移行している中で問題も発生したときなどずるずると対応することになり、延々とアップグレードに追われることになったり、対応中に次のバージョンが出てしまったり・・・ということになります。
これは当然リリースサイクルよりも短い期間にする必要があります。
Chatworkではこれをリリース日から2ヶ月としました。
3ヶ月ごとの更新という前提で考えるとから2ヶ月くらいが妥当なのではないかと思います。
クラスタ構築期間
次に、EKSクラスタを構築し、開発チームに引き渡すまでの期間を確保します。
下記のようなタスクが発生します。
- クラスタの構築
- 運用管理系のアプリケーションの構築、動作確認
- 新バージョンの機能の確認、動作検証
開発チームの検証、移行期間をなるべく確保するために、ここはなるべく短くしたいところです。
特に1,2に関しては自動化や手順の明確化などで極力期間を短縮しましょう。
eksctlやterraform等、新バージョンにツールが対応するまでの期間も考慮する必要があります。
Chatworkではeksctlのラッパーツールを自作しており、クラスタの構築、ArgoCDによる管理系アプリケーションのインストールまでをこのツールで完結できるようにしています。
Chatworkではこれを2週間としました。
新バージョンの説明会の実施
開発チームの方にいきなりアップグレードしてくださいといっても、何か変更がいるのか、そのまま移行すればいいのかの判断がつかないと思います。
Chatworkでは、SREにてクラスタの構築、新機能の検証を実施した後、開発チームに対して新バージョンについての説明会を開催しています。
AWSのドキュメント(Amazon EKS Kubernetes versions - Amazon EKS)をもとに新バージョンのトピックを下記の3段階に分けて説明しています。
- Must
- 廃止になるAPI等、今回必須で対応してもらう必要があるもの
- Should
- 必須ではないがいずれ利用できなくなる機能、変更した方が改善が見込めるもの
- Info
- 使ってない機能や特に変更の必要がないもの
アプリケーションの検証、移行期間
残りがアプリケーションの検証、移行期間となります。
ここまでの決定でここに割り振れるのは1.5ヶ月ということになります。
開発チームにアプリケーションごとに検証や、移行作業、必要なタスクをプロットしてもらいましょう。
依存関係がある場合はそれも考慮してもらう必要があります。
この入力の段階で、1.5ヶ月に収まらない場合は、バージョンごとにアップグレードすることは無理です。
バージョンを1つスキップして実施する方向で考えたほうがいいかもしれないです。
1つスキップしても収まらないというものがあれば、そのアプリケーションはもはやKubernetesにのせるべきではないかもしれないので、そこから検討したほうがいいと思います。
5. 実施/振り返り
新しいバージョンがリリースされたら、作成したスケジュールに沿って対応していきます。
そのときに必ず作業工数、時間を計測できるようにしておきましょう。
アップグレードが完了したら、必ず振り返りを行い、かかった工数の妥当性を検証しましょう。
もし、想定よりも多かったのであれば、
- どれくらいの工数が妥当なのか
- 事前準備や慣れの問題で、次回は短くできそうなタスクはあるか
等を検討しましょう。
検討の結果、期間内の実施が難しいということであれば、1つスキップする等、やりかたの見直しを行ったほうがいいと思います。
EKSのアップグレードに追われて開発ができないというようなことは本末転倒です。
まとめ
EKSのアップグレードに組織で対応するには
- 認識を共有する
- ルールを明確にする
- 振り返りをして、アップグレード作業のライフサイクルも回していく
ということが大事という話でした。
ChatworkではSREメンバーを絶賛募集中です！
