AKSのアップグレード、しんどくない？
吉川俊甫氏（以下、吉川）：エーピーコミュニケーションズの吉川です。「『がんばらない』AKSアップグレード方法を考えよう」というセッションをお話ししたいと思います。
正直、テクニカルなところは、もう全部真壁さんがしゃべってしまったので、私は、AKSのアップグレードに苦しんでいるみなさんの気持ちに寄り添うエモーショナルな、エモい感じのお話をしようかなと思っています。よろしくお願いします。
ということで、自己紹介です。吉川と申します。先ほどご紹介があったとおり、株式会社エーピーコミュニケーションズに所属していまして、今は、テクニカルエバンジェリストという職種で仕事をしています。
マイクロソフトさんから「Microsoft MVP」というアワードを2023年の6月にいただいていまして、今日、カメラに絶対映らないぐらいの大きさなのですけど、MVPのロゴがついたパーカーを着て、お話をしているわけです。ノートパソコンのせいで映っていないんですけどね。そんな制服を着ています。
仕事以外にコミュニティ活動として、「Platform Engineering Meetup」という、最近話題のPlatform Engineeringの勉強会をやっている運営のメンバーとしても活動しています。
好きなAzureサービスは、コンテナ系全般というところで、そんなご縁もあって今日この場に出させていただいている次第です。
タイトルにも書いたのですが、今日ご参加いただいているみなさん、きっとAKSのアップグレードとかを経験されているみなさんが集っているのかなと思うのですが、「AKSのアップグレード、しんどくないでしょうか？」という問題提起をしています。
「何がしんどいのか？」。いろいろしんどいポイントはあると思うのですが、バージョンアップが高頻度、先ほどの真壁さんの話にもありましたけど、だいたい3ヶ月から5ヶ月に1回ぐらいは、マイナーバージョンが上がっていくので、それについていくのが大変だというのが1つ。
それが、なんらかの都合でバージョンを上げられなかった時にも、AKSのバージョンは、マイナーバージョンを1個ずつ上げていかなきゃいけないんですね。なので、1個飛ばして新しい最新のバージョンにしようと思っても、1個1個上げていかないといけないので大変だよねというのもあります。
アップグレードをするというメンテナンスをやる時には、「昼間はまかりならん。必ず夜にやりなさい」というような会社さんもあると思うので、アップグレードのたびにメンバーが夜勤にされてシフトを組んだりするのとか大変だよねというのもあります。
それに、AKSのクラスターは開発環境、Staging環境、本番環境みたいなかたちでたくさんあるので、それらを全部バージョンアップしていくのは大変だよ、アップグレードはできるけどダウングレードできないので、慎重にやらなきゃいけないよねというところで、気持ち的にもしんどい部分があるかなと思います。
そうは言っても、バージョンアップはやらなきゃいけない作業なので、やらないとセキュリティの問題が出たり、あるいはマイクロソフトさんのサポートを得られなくなっちゃうというのもあるので、無視するわけにはいかないです。
私のお話は、そんなバージョンアップ作業を「がんばって乗り越えなきゃいけないようなつらい苦難な作業」というようなかたちで向かっていくのではなくて、「日常の当たり前な作業」としてみなさんの気持ちを軽減させるようなお話ができたらいいなというふうに考えて、いくつかの方策というのを持ってきた次第です。
そんなわけで、さっそく1つ目の話からいきたいと思います。
「アップグレードしなくていい」アーキテクチャに移行する
まず1つ目、「『アップグレードしなくていい』アーキテクチャに移行する」という話です。
そもそも、「Kubernetes」のバージョンアップはどんな価値を生むかというと、基本的にKubernetesのバージョンを上げたところで、みなさんの自社のプロダクト、サービスの売上や利益というのが増えるわけではないですよね。
昔の、初期の頃のKubernetesだったら、新しいバージョンが出たことによってなにか機能が使えるようになって、それがプロダクトにマッチするからすごく良くなるよね、というのはあったかもしれないですけど、おそらく今、最新のバージョンだと、あまり革新的な機能が入るということはないと思います。
なので、やはりバージョンを上げたところで自社プロダクトの価値向上につながるわけじゃないよねというところから、えてしてバージョンアップは守りの作業になりがちかなと思っています。なにか価値を上げるための作業ではなくて、価値を損なわないための作業という位置付けにされていきがちです。
こういうのは、成功して当たり前みたいに捉えられて、かといってなにか問題が起きるとすごく責められるんですよね。非常につらい作業です。
我々がクラウドを使い始めた時、これは、AKSがというのではなくて、クラウドサービス全般を使い始めた時に求めていたことは、自社でやっていたインフラの管理とかをクラウド事業者側にお任せをして、プロダクトの価値向上という部分に集中したかったというのが、クラウドを使い始めた、初めのきっかけなんじゃないかなと思っています。
今日はオンライン配信しかないので、「Zoom」の向こうのみなさん、ぜひリアクションなどで反応してくれるとうれしいです。
そんな話をしながら、ではそのプロダクト部分に集中したかったという気持ちをもう一度考えてみると、「本当にAKSが、自分たちにマッチしているのか？」というところも、あらためて考え直してもいいかなと思うんですね。
本当に「AKSのバージョンアップについていくのは、しんどい」と思うのであれば、あらためて、本当にAKSが自社のサービスにマッチしているのかというところは、考え直したほうがいいと思っています。
Azureには、幸いにしてコンテナを扱えるサービスは複数あるので、AKSを使ってみたのはいいんだけど、やはり長期的に運用するのはしんどいよねと感じるのであれば、より事業者側にお任せできる、マネージドのサービスに移るというのは、ぜんぜんありだと思っています。
クラウドのいいところは、いつでもサービスを使い始めることができるし、いつでもやめることができる。自社に資産を持つ必要はないというところが1つメリットなので、あらためて、しんどいというふうに思ったのであれば、考え直すというのも1つの手かなと思います。
代表的なコンテナを扱えるサービスでいくと、「Web App for Containers」であったり、「Azure Container Instances」や「Azure Container Apps」といったようなものがあります。
個人的にはAzure Container Appsが、けっこうお勧めです。Kubernetesベースで作られた、かつフルマネージドなサービスなので、もしAKSがしんどくてほかのサービスに移りたいよというのであれば、最適な選択肢になるかなと思っています。
これは2022年の5月にGAしたサービスなので、それより前からAKSを使われていたお客さまにとってはアーキテクチャ選定の土俵に乗っていない可能性があるかなと思っています。
Container Appsの仕様などを調べていただいて、自社のユースケースに合うかどうかを、あらためて検討の土俵に乗せてみてもいいのかなと思っています。
幸いにして、Azure Container Appsには、日本語の書籍があるんですね。ここにいらっしゃる真壁さんを含めた、マイクロソフトの方、5名の方が共著で、『Azureコンテナアプリケーション開発』という本を出されています。
この中でいくつかのAzureサービスの紹介もされているのですが、その中にContainer Appsが入っているというものになります。2023年の2月に発売した約1年ぐらい前の本ですね。
内容は、今のAzure Container Appsと変わっている部分もあると思うのですが、今でもぜんぜん使える内容の本だと思うので、ぜひこういったものも参考にしながら、アーキテクチャについてあらためて思いを馳せてみるといいのではないでしょうか。
今日みなさん、AKSの話を期待されていて、場合によっては、これ、石を投げられるかなと思っているのですが、わりと冗談抜きで真面目にお話をしています。「ちょっとしんどい」というところを乗り越えるのが本当につらいのであれば、ぜひこれを検討してみてください。
バージョンアップ作業をラクにする
ここからはAKSの話に移ります。ちゃんとAKSの話をします。ということで、第2案としては、「バージョンアップ作業をラクにする」という方式を考えてみましょうというところです。
先ほど、「アーキテクチャ、変えてみたら？」という話をしましたけど、そんな簡単にできるもんじゃないというのは、もちろん私も理解はしています。
ネットワークの都合やSubnetの最小範囲、それによってスケーラビリティがどうなるかというところで、AKSとAzure Container Appsはけっこう違ったりします。
あとは、いわゆるCNCFでリリースされているようなコンテナアーキテクチャのエコシステムを採用しているケースだと、Azure Container Appsでは対応できないケースというのもままあります。
よくあるケースで言うと、「GitOps」とかを使われていると、そう簡単に移行できないよねというのはけっこうあります。
じゃあ、そんなAKSを使わなきゃいけないというところで、バージョンアップの作業そのものをいかに楽にしていくかというところで考えていく。
先ほど真壁さんのセッションでも紹介されていたので、あらためてお話しするのも、というのもあるのですが、やはり自動アップグレード機能をそろそろ使ってみてもいいかなと私も思っているところです。
真壁さんの紹介でもありましたけど、クラスターを作る時のデフォルトの設定が、パッチリリースはもう自動でやりましょうというふうになっているぐらいなので、そろそろ自動アップグレード機能に頼ってもいい頃合いが来ていると私も思っています。
4つあるレベルのどのレベルを採用するかというのは、それぞれ検討はあると思うのですが、パッチリリースぐらいは、もうやってもいいかなと思っていますし、最新GAバージョンのマイナス1ぐらいというのも、よりサービスレベルが低いもの、ある程度夜間とかでの停止を伴っても問題ないのであれば、対応してもいいかなと、個人的には思っています。
これも真壁さんのセッションの中で紹介されていましたが、メンテナンスウィンドウというのが設定できるので、「自動で勝手にアップグレードされても困るよ」というものを、ある程度スケジュールを調整できます。毎週第何曜日の何時から何時までみたいなかたちの指定もできますし、ある程度期間を取って、「この間はアップグレードさせない」というようなことも指定できます。
よくあるのが、「年度末とかに障害を起こしたくないから、この期間やめてくれ」、「株主総会の期間は、なにかあると困る」。あとは、ビジネス上の大事なポイント、小売業とかであれば、やはりセールの時期などにはやってほしくないよというのはもちろんあると思うので、そういうのを除外するということも指定できます。なので、そのへんは柔軟に設定することができるというところは覚えておいてください。
自動アップグレードだけではないのですが、自動アップグレードと併せて使うと便利な機能としては、「Event Grid」のイベントソースとしてAKSのイベントというのが使用できます。
AKSとして「新しいバージョンがリリースされた時にイベント発生する」というのもありますし、「今利用中のバージョンがもうサポート対象外になっちゃうよ」というのもお知らせしてくれます。ノードプールのアップグレードの開始と成功、失敗というのは、それぞれイベントとして通知可能になっています。
なので、これらのイベントを利用して、後続の処理、例えば「Azure Functions」を使うとか、「Azure Logic Apps」を組み合わせることによって、処理の自動化というのが比較的容易にできるように、今はなっているんですね。
アップグレード成功したら、「成功したよ」というのを「Slack」に通知するということもできますし、失敗した時にもリカバリープランを自動化できるのであれば、そういったものを自動でキックするということもできるので、こういったものを組み合わせることによって、アップグレードに伴う前後の作業というのも全般的に自動化するという意味で、がんばればできます。
こういったものを組み合わせて自動アップグレードを使ってみるというのは、メンテナンスそのものは、人が張りつかなくてよくなるということになるので、楽になる。ぜひ、積極的に使ってほしいなと思っています。
「Fleet Manager」を使う
とはいっても、「やはり自動は、怖いよね」という方は、まだまだいらっしゃると思うので、そういった方の楽にするための方策としては、これも真壁さんのセッションでもありましたが、「Fleet Manager」というサービスがあります。これを使うと、複数のAKSクラスターのアップグレードをまとめて実行可能になっています。
アップグレードの適用順っていうのも制御できるので、開発のクラスター入れて、Stagingのクラスター入れて、Productionのクラスター入れて、というようなかたちで順番にアップグレードさせることもできます。
Stagingのアップグレードが終わってからProductionのアップグレードまでに、少し間を空ける、そういったような柔軟な制御も可能になっています。
特にクラスター数が多い会社さんで運用されている方は、こういったものを使って、まとめてアップグレードして人手を減らすというのは、工夫の余地があるかなみたいに思っています。わりと最近GAされたサービスなので、ぜひ使っていただけるといいのかなと思っています。
こういったものを使ってアップグレードの作業そのものを楽にしていきましょうというのが第2の提案です。
（次回へつづく）
