イオンスマートテクノロジーで実践しているAKSアップグレード戦略
齋藤光氏：「イオンスマートテクノロジーで実践しているAKSアップグレード戦略」ということで、ここまで真壁さんと吉川さんが話されたことに対してのアンサーソング的な発表になるかと思いますが、よろしくお願いします。
自己紹介ですが、あらためまして齋藤と申します。イオンスマートテクノロジーには2022年の5月に入社して、SREチームの立ち上げみたいなところをやってきています。今回の発表の内容にも関わるんですけど、「Kubernetes」アップグレードに失敗しない漢を目指して日々奮闘中です。
2023年にも登壇をしていて、SRE NEXTとかCloudNative Days TokyoでAKSに関する発表をしているので、よろしければご覧ください。
会社紹介としては、AEON TECH HUBの中で自社の紹介をするのもなんなのですが（笑）、イオンのデジタルシフト戦略を担う会社の位置付けとして2020年10月、約3年半前に設立して、お客さまのお買い物体験向上とか、店舗で働く方々の効率を良くしていくということをやっていっています。イオングループのすべてのビジネスをテクノロジーの力で進化させようとしています。
みなさんも使っていらっしゃると信じたいんですが、今、イオンスマートテクノロジーでは「iAEON」という、イオングループのさまざまなサービスを1つにまとめたアプリを運営中です。このバックはほとんどAKSで動いている。つまりAKSが、このiAEONを支えていると言っても過言ではないという状況です。
今日のアジェンダですが、主に3つで、まず最初に弊社で採用しているAKSのアップグレード戦略についてお話します。今はその戦略なんですけど、当然最初からそうであったわけではないので、どんなことがあってどう改善してきて今に至ったのかというところを、2つ目に改善ジャーニーとしてお話をさせていただきます。
また、そこから得たAKSのアップグレードに対して立ち向かっていく。その練度や強度を高めていくために大切だなと思っていることのお話をしていきたいと思います。
AKSのアップグレード戦略
まずはAKSのアップグレード戦略からです。真壁さんとか吉川さんの話とだいぶ被りますので、それに対するアンサーソングです。おさらいですけど、弊社が運用しているKubernetesの規模としてはだいたいこのような数字感になっています。
まず、アップグレード戦略のバージョンについてです。このバージョンに限った話ではないんですけど、当たり前ですが、原則的にマネージドサービスを提供してくださっているMicrosoft社の推奨に従うことが重要だと思います。そのサポートバージョンの対象としてもマイナーバージョンはn-2のサポートまで。マイナーバージョンはだいたい3、4ヶ月に1回リリースされるので、必然的に約半年に1回アップグレードを実施しています。
ASTも実際にできてからアップグレードを必ず継続して実施してきたという、「えらいな」と自分で勝手に言うんですけれども（笑）。ちゃんと運用している部分かなと思っています。現在は1.27で稼働中です。だから次は、1.29が切れるのが7月だから6月あたりにやっていくという状況ですね。
今のはマイナーバージョンのお話ですけど、パッチバージョンですね。x.y.zのzの部分ですけれども、こちらも最近から実施するようになりました。すばらしい！ 勝手に自分で言う（笑）。
（一同笑）
しかも、先ほど吉川さんが推奨したとおり、自動アップグレードを設定しています。実際に自動アップグレードをしています。というかたちで、わりとちゃんとやっているというような感じです。
まさに先ほどの吉川さんの話と被るんですけども、Long Termサポートが2023年に出て、これを利用しているかという点については、これも「利用しない」というアンサーを出しています。いくつか理由を言っておくと、AKSのアドオンもそうなんですけど、他のツールですね。observabilityツールを別に入れていたりして、そういった影響を考えたくないというところ。
実際にどうアップグレードを実施しているか
あとはビッグバンリリースと言うと言い過ぎかもしれないですけど、1回のアップグレードでの差分が大きくなるのでリスクも大きくなる。あと最後の結論にもつながるんですけど、回数をこなさないとうまくいかないんですよ。Kubernetesは別に魔法のツールじゃなくて使いこなす筋力とか、組織の体力もそうだし筋力やスキルが重要です。そこを効果的に考えるとアップグレードの回数を減らすことそのものが組織を弱くするところもあると思います。
あとは普通に1.29とか1.28とかを見ていると新機能がいっぱい出ていて普通に使いたくなって、そこをわざわざ避けてLong Termサポートを採用するメリットはどのくらいあるのかなというところが解です。
実際に、どうアップグレードを実施していますか？ というところをここに書いているんですけれども。基本的に特別なことは特にやっていません。当たり前のことを当たり前にやるという感じですね。まず検証環境などでやる前にバージョン差分の事前確認を、先ほど真壁さんのお話にあったChangeLogを確認して、廃止されたAPIとかを確認する。
そして対応の必要があったら対応を計画して、その後、アップグレードのテスト環境やステージング環境で実施し、動作確認をする。最後に本番切り替えを実施するというような、普通の流れです。実は一番泥臭くやらないといけないのは、（1）のバージョン差分の事前確認で、ChangeLogをちゃんと読みましょうというところですかね。
それは先ほどの週刊 AKS Changelogを読んだりとか。あとはMicrosoft MVPの方が「Zenn」でAKSのリリースノートを日本語版で出していて、先週1.29のリリースノートを翻訳してくださっているというのもあるので、こういうものをふだんから読んでキャッチアップしていくのもおすすめかなと思っています。
どう切り替えているか
「切り替え」と言っていたけど、どう切り替えているんですか？ というところなんですが、大きく分けてインプレース型とBlue/Green型があります。ここは説明不要ですね。散々同じ画像を……3回も全部同じ引用元なので（笑）、ここは飛ばしましょう。イオンスマートテクノロジーでは、インプレース型もBlue/Green型も使い分けているという状況です。
ちょっとあまりかっこいい理由ではないんですけれども、会社ができたのが3年半前で、このアップグレードの設計をするとなったのがまさに2021年なわけです。まさに最初の真壁さんのスライドにあったとおりの2021年の状況なので、基本的にはBlue/Green型を使いましょうというのが方針でした。
まぁ、なんやかんやBlue/Green型の作業コストが大きすぎたりとか、それ自体がツラいみたいな感じになって、インプレース型が一部採用されているところが実はあったりします。ただ、本当はやはりインプレース型もBlue/Green型もメリット、デメリットがあるので、直近ではインプレース型をベースにしてBlue/Greenを採用するというのはあるとは思うんですけれども、比較するとしたらここに書いた表みたいな感じになるのかなと思います。
作業コストでいえばインプレース型のほうが楽ちんですし、切り替え時間でいえばちょっと細かい設定にもよるんですけど、基本的にBlue/Green型のほうが当日切り替えればいいから速いよねというところですね。やりたければ重み付けルーティングで徐々にやればいい。ちなみにASTは、イオンスマートテクノロジーでは重み付けルーティングまではできていなくて、プライベートDNSをバツッと切り替えるという、ちょっとドキドキな作業があったりします。
ただ、事前にクラスタを作っておけばいいとか、事前にアプリケーションをデプロイしておけばいいとか、そういうことができるので、当日の作業時間は本当に5分です。そのうち4分ぐらいは「もう、これは切り替えてもいいんだよね？」という（笑）、みんなに勇気をもらう時間だったりします。
あとは先ほど出てきたロールバックの可否ですね。ちょっとバックアップのことを忘れていて「ロールバックはできない」とインプレース型に書いちゃいましたけど、実際に対策していくしかないかなと思っています。あとは切り替えの制約でインプレース型はマイナーバージョンで1個ずつしか上げられないので、実際に2バージョンを上げましょうとなった場合には、2回アップグレード作業をしなきゃいけないというところがあったりします。
最後は作業時のサービス影響でいうと、インプレース型は同一クラスタ内でPodがDrainによりEvictされるので一時的にキャパシティが落ちる瞬間があるでしょうというかたちになっていて、やはり作業コストが大きな判断ポイントになるかなと思います。そんなかたちでした。
改善ジャーニー
こんなに偉そうに、偉そうじゃないかもしれないけど、偉そうにしゃべっていますけれども、自分が入社した時はけっこう激しめでですね、恥ずかしいことがいっぱい起きていました。まずBlue/Greenですね。先ほども出てきましたけれど、古いクラスタがあるんですが、そこからデプロイメントを削除せずに停止したんですよね。「なにかの拍子」と言っているんですけど、これはあれなんですよね。「Terraform」でAKSにタグを付けるとやったらなぜか起動して、ですね。
（一同笑）
クラスタが起動してですね、そうしたら、そこの上に載っているアプリケーションが起動するわけです。時間が空いているので3バージョン低いアプリケーションが動いちゃうんですね。別にリクエストが入って来なきゃいいんだろうと思うかもしれないんですけど、タイマー起動型のアプリがあるんですね。そいつが動いて、サービスの運営に影響はないんですけど、障害が起きるということがありました。
あとは先ほども出てきたsurgeサイズですね。デフォルトだと1台で、そもそもそのパラメータを知らない人はそんなものだと思ってやるんですけど。クラスタのノードが20台や30台になってくると、メチャクチャ時間がかかるというのはあったりします。あとはpdbが設定されていないので、Podが0になる瞬間があってエラーが出ます。
じゃあpdbを設定しようとしたら、今度はpdbの設定がイマイチで邪魔をしてアップグレードが進まないとか、Gracuful Shutdownをしていないからエラーがポコポコ出ますとか。あとは、これはGitOpsをやっていないからというのはあるんですけれども、使われていないアプリケーションがそのまま放置されているので、アップグレードのタイミングで移るんですけど、メンテされていないので起動しないとか。いろいろあります。
（次回へつづく）
