バージョンアップ作業を少なくする
では続いて第3案というところで、「バージョンアップ作業を少なくする」です。
「これ何？」というと、AKSに詳しい方は、もうご存じかもしれないのですが、Long Term Support、LTSが提供されています。2023年4月にLTSでやりますということで発表がありました。
もともとKubernetesコミュニティによる特定のバージョンのサポートというのは1年間提供されるようなかたちでサポートサイクルになっているのですが、その1年の期間が終了した後に、Microsoftはさらに1年間追加でサポートを提供しますよというのが、このAKSのLTSになっています。
全部のバージョンが提供されるわけではなく、現状だと1.27のマイナーバージョンがLTSバージョンとして設定されています。標準のサポートは、2024年の7月までですが、LTSだと2025年の7月まで提供される。
これを使うことによって、アップグレードしないままでもちゃんとサポートが得られる状態で長期間使うことができるというので、アップグレードの作業そのものを減らすことができます。
とはいえ、現状まだ標準サポート期間内なので、正直まだ「LTSは、どういうかたちで提供されるの？」というのがあまり見えていないところが多いです。
公式ドキュメントの記述はけっこう充実してきています。いくつか情報を広げているので、それらについて少しお話をさせていただきます。
まずLTSは、ただで使えるわけではないです。適用するための条件として、クラスターの価格レベル、Premiumというものが新しくできました。これにする必要があります。その上で、「Azure CLI」などでAKSLongTermSupportというオプションを設定することで、初めてLTSが提供されます。
なおPremiumの価格レベルの費用が、1クラスター1時間あたり約90円。これは、昨日調べた東日本リージョンでの価格です。
もともとは、FreeとStandard。AKSのマスターノード側の冗長性のオプションによって2つの価格プランがあったものの、さらに最上位としてPremiumというのができるのですが、Freeレベル比で考えると、1ヶ月約6万から7万円ぐらいのコスト増になるというところは、注意が必要なものです。
あと制約事項として、LTSはあくまでKubernetesの本体部分に対するサポートの提供になりますので、AKSのアドオンに関しては、一部LTSの対象外になっています。
一部といいながら、けっこうコアな部分が対象外になっています。ドキュメントに列挙されているものでいくと、代表的なものでは「Istio」「KEDA」「Dapr」「Application Gateway Ingress Controller」などといったものが対象外として記述されています。
これらの対象外となるアドオンを有効化していると、LTSに設定できないという話があるので、もしこれらが必要な場合は、AKSのアドオン機能でインストールするのではなくて、OSSとして提供されているものを別途インストールするなど、なにがしかの別立ての対処が必要になります。
あと、これはちょっとびっくりする機能なのですが、先ほど冒頭で、マイナーバージョンは1個ずつしか上げられないよという話をしたのですが、どうもこのLTSに関しては、次のLTSバージョンがリリースされたら、現LTSバージョンから次のLTSバージョンまでの更新パスが提供されるようです。
（スライド上に）ドキュメントの記述を、スクリーンショットで撮って貼っています。小さくて見えないかもしれないのですが、これだと、アップグレード対象のバージョンを1.30.2まで上げるというようなコマンドの例が出ています。
なので、1.27系からいくと、マイナーバージョンを3つ飛ばして上げるというような、かなり大胆な方針になるかなと思っていますが、そんな機能が提供される予定みたいです。まだ1.30系はAKSが出ていないので、このへんは、次のLTSバージョンが出た時にどうなるかなと思っています。
そんな特徴から紹介しておいて、なんですけども、個人的には、あまり積極的にこれ使いたくないなと思っています。
真壁さんもウンと頷いています（笑）。
次のLTSバージョンに移行できるにせよ、いきなりマイナーバージョン3つ上がるのは、たぶんインパクトでかいなと思います。上がるからといって、なにか中で動かしているマニフェストの対応というのが、なんらか必要になるだろうという覚悟が必要だと思っています。コストがかかるというのも、やはりそうですね。
なので、どうしてもアップグレードの作業がサポート切れまでに間に合わないというような事情があれば、LTSを使うというのもありかなと思っているのですが、もし仮に使うにしても、それをずっと使い続けるのではなくて、速やかに1つ上のバージョンに上げて、LTSから離脱する、通常のアップグレードサイクルに戻すという使い方のほうがよいのかなと、個人的には思っています。
バージョンアップ作業のリスクを減らす
では4つ目の案というところで、「バージョンアップ作業のリスクを減らす」という話です。
AKSは、アップグレードはできますがダウングレードはできないです。元に戻すことができないことは、やはり会社の中でけっこう嫌われるというか、問題視されがちかなと思っています。
じゃあ、元に戻す、切り戻し手順がないものをどうやって安全にやるのか。どう安全性を担保するのかといったところで、社内、あるいはステークホルダーの方に説明責任を持っていらっしゃる方も多いかなと思います。
（スライドの）下にキャラクターを持ってきましたけど、よく言われますよね。リリース判定会やメンテナンス共有会というような会自体で、「アップグレードしても、本当にこれ、大丈夫なの？」というのを求められることがあると思います。つらいですよね、これ。私もつらいです。
それを、どうするかというと、なかなか難しい問題かなと思っています。よくあるのは、開発環境からやって、Staging環境をアップグレードして、そこで問題なければ本番環境やりましょう、というのはよくある話かなと思っています。
ただこれは、オンプレミスの時のようなスピード感でやると、その間にAKS側が新しいバージョンをリリースしていて、Stagingまで検証していたバージョンが使えなくて、「あれ？」という、「また検証し直しかな？」というのが出てきてしまうことはあるんですね。
実際に、（スライド）下に一例としてタイムラインを引いていますけど、やはり旧来の歴史ある会社さんだと、開発環境上げて、Staging上げてというところまで1、2ヶ月とかかけていらっしゃる会社さんもあったりすると思います。そうしていると、その検証していたバージョンがもう使えなくなってしまうというのが、ままあるんですね。
なので、もし順番にやるというのであれば、速やかに本番まで持っていくというのは、必要になります。なので、検証する内容は、きちんとまとめられた上で、検証期間というのを極力短くすることが必要かなと思っています。
そうは言っても、「それ、短くできないよね」というパターンもあると思うので、やはりそうなると、クラスターのBlue/Greenデプロイっていうのが最も安全にできる手段かなと思っています。
新しいバージョンのクラスターを隣に作って、それで動作確認をした上で問題がなければネットワークの上位側で切り替える。なにか問題があっても、元のクラスターはそのまま残っているので、上位側のネットワークで切り戻ししてあげれば元に戻せます。
これで安全性、担保できますよというかたちで、非常に説明しやすい、そして実際に安全な策であると思います。コストの問題を除けばというところですね。
ただこの方式を採ろうとすると、ある程度事前に、AKSクラスターを最初から作った時からその前提を取っていないと、後からこれに対応するのはけっこう難しいかなと思っています。
VNetとかSubnetはどうするという問題があったり、けっこう細かい話なんですけど、Blue、Greenのどっちが今、本番の運用を担っているのかというのを関係者に伝達をきちんとしないといけないんですよね。
よくあるのが、BlueからGreenに切り替えて、「じゃあ、もうBlueクラスターは用がなくなったから消しちゃおう」とした時に、それに伴って監視のアラートがドバッと発生して、監視のオペレーターさんがてんやわんやになってしまう。「クラスターの応答がないですけど大丈夫ですか？」「いや、もうそれ使っていないから、消したんだよ」。そこはきちんと、関係者には連絡をしましょう。
旧来はよく、クラウドじゃないオンプレミスの監視などされている方だと、そんな運用中のものが急になくなるのはあまりない概念なので、そこをちゃんと一定の理解をしてもらう必要はあるかなと思っています。
あとは、Blue/Greenの切り替えをどうするかというところも、上位側でどう切り替えるか。100：0で切り替えたいのか、あるいはカナリア的に徐々に切り替えたいのかというような要望によっても、どういったサービスを運用するかが変わってくると思いますし、プラスアルファでWAFとかCDNの機能も要るよねということであれば、それらも加味して決めていく必要があるかなと思っています。
よくあるのが、「Azure Front Door」「Application Gateway」など、DNSレベルでいうなら「Traffic Manager」を使うというのも手かなと思います。
いくつか手段があるので、それらをAKSクラスターを使って、システムを構成する時からあらかじめ考えておかないと、後から追加するのはけっこう大変かなと思います。
あとは、Blue/Greenでやっていく上で2つのクラスターの設定ズレを防がないといけない。Blueでずっと運用していて、「運用中になにか問題があったからパラメーター変えました」というのを、次にGreenを作る時にも同じものを反映しないといけないというのがあるんですね。
そういった時に、やはり設定ズレを防ぐためにもInfrastructure as Codeを活用することを強くお勧めします。代表的なのは「Bicep」や「Terraform」というところですね。どういったツールであってもいいと思うのですが、パラメーターのミスをなくすというような工夫は必要かなと思います。
組織体制でカバーする
最後です。第5案「組織体制でカバーする」。これは、テクニカルな要素は一切入れていないです。
人の話ですね。ある程度大きな会社さんであるパターンなのですが、プロダクトを持っているチームが複数あった時に、各チームがそれぞれバラバラにAKSクラスターを持っていて、バラバラに管理しているというパターンが、まれにあったりします。
これは、悪い話ではないんですね。それぞれのプロダクトの事情に沿ったかたちでクラスターの管理ができるので、悪くはないと思っています。
ただ、それぞれの管理主体やそれぞれのチームに任せることによって、独立性は担保されるものの、会社全体で見ると同じようなことをいろいろなところでやっている、かつ、えてして、それらのチーム間で情報共有がされない、ナレッジが共有されないという、サイロ化というのがよく見られるお話です。
じゃあ、それをどうするかというと、クラスターの管理というところを切り出して、プラットフォームチームを作って、そのチームがクラスターの管理をする。各プロダクトのチームは、クラスターを利用する、アプリケーションを載せるというような使い方で、作業を分割することで全体的な効率化を図れるのかなと思っています。
プロダクトチームの中でプロダクトの価値向上に集中していただいて、そのプロダクトを支えるプラットフォームの部分は、それ専門のチームが担うことで、会社全体として見ると効率化を図れることはあるかなというかたちで、この案を持ってきた次第です。
若干余談になりますけど、この考え方は、Platform Engineeringという最近話題のキーワードに基づいているかたちで少しお話をしています。
Platform Engineeringは、マイクロソフトがガイドを出しています。最近日本語版も出てきているので、ぜひみなさん、ご一読いただければと思います。
別にAKSクラスターを管理し、まとめるチームを作るとかそういう話ではなくて、もう少し広い概念の話なので、ぜひ一度学んでいただければなと思っています。
冒頭の自己紹介でもお話ししましたが、有志のコミュニティで勉強会を開催しています。興味があればぜひご参加いただければと思います。「Platform Engineering Meetup」というキーワードで検索していただければと思います。
自分たちの組織にマッチするやり方をいろいろ試行錯誤しよう
私が話した5案のまとめになりますが、AKSから別サービスに移るもよし、Azure側で準備されているような更新を楽にする自動更新の機能を使うもよし、LTSを活用してアップグレードの回数そのものを減らすもよし、Blue/Greenでリスクを軽減するのもよし、組織のあり方を変えることでその組織の全体の力を使って乗り越えるもよし。
しんどいというところを軽減するための工夫の仕方というのは、いくつもあります。それぞれ、みなさんの、自分たちの組織にマッチするやり方をいろいろ試行錯誤してみて、そのしんどさを乗り越えて、定期的に実行できる当たり前の作業というのに変えていければな、というところで私のセッションは締めたいと思います。
（スライドのQRコード）これは、弊社の広報の「X（旧Twitter）」のアカウントです。よろしければみなさん、フォローしてください。
というところで、私のセッションは終わりとなります。ご清聴ありがとうございました。
