1つ目の戦略サンプル AKSの規定・推奨ベースにする
真壁徹氏：（スライドを示して）戦略のサンプルを簡単にまとめてきました。
1個目がAKSの規定や推奨ベースにするということで、これは冒頭で話したKubernetesの推奨、AKSの推奨に従うやり方ですね。AKSだけではなくてKubernetesコミュニティ、あとはまわりのエコシステムが成熟してきて、リスクは下がってきています。
なのですが、このサンプルではマイナーバージョンアップは手動で行います。パッチとか、パッチバージョン、Nodeのイメージのアップグレードは自動でやりましょう。それでスケジュールを工夫します。
夜中にやるとか昼にやるとか、いろいろ工夫できます。こういう戦略です。私は今後はこれがスタンダードになるんだろうなと思っています。
まだ過去のアップグレードの悪い体験、トラブルの体験が残っているお客さまは「Blue/Greenしたいな」と言うかもしれませんが、今後はこれがスタンダードになるんじゃないかなと思います。
実は2023年の秋ぐらいにKubernetesのプロダクトマネージャーが日本に来て、散々議論をして、そのあと私も様子を見ていろいろなお客さまともディスカッションして、実績も見て言っています。これがスタンダードになるんじゃないかなと思います。
ただインプレースアップグレードなので、リカバリー手段はやはり準備しておいたほうがいいだろうと思います。大きく2つのリカバリー手段があります。原因を取り除いてアップグレードを完遂するやり方と、バックアップから戻すやり方です。
私はアップグレードが途中でこけたとしても、その原因を取り除いて、目的のバージョンに上げる、完遂することをおすすめします。そのほうががんばって戻すよりたぶんシンプルです。なぜこけたかはけっこうわかりやすくなっています。先ほど話しましたが、問題の診断と解決機能を見ると、「ここでこけたよ」というものが出ていたりします。
あと最近のAKSのアップグレードツールは、「あ、このエラーが原因だったんじゃないの？」ということを概要画面の一番上に出してくれます。「アップグレードがfaileしたよ。これが原因かもしれませんね」とリンクが出てきて、そのリンクを押すとトラブルシューティングガイドに飛びます。ということもあり、私のおすすめはアップグレードをやりきるというやり方です。このほうがシンプルかなと思います。
（スライドを示して）問題の診断と解決機能を知らない方が多いので、ぜひ使ってみてください。かなり細かく診断してくれます。まだプレビュー（の状態）ですが、最近流行りのCopilot形式というか、チャットで自然言語で問い合わせられるようになるそうです。私もまだ触れていないのですが、今後にご期待ください。
もう1つのインプレースアップグレードのリカバリーは、バックアップから戻すやり方です。ただ、正直これは複雑です。複雑なのであまりおすすめしないのですが、バックアップから戻すほうがいいという方もいると思うので、もしやりたい場合には資料を参考にしてもらえければと思います。
それとBlue/Greenですね。冒頭に話しましたが、これもまだ有力な戦略です。今後これがメインにはならないと思うのですが、いざという時にできるようにしておくのはけっこう大事な戦略です。
なので、Blue/Greenじゃなくて自動アップグレードやインプレースを中心にしていく場合でも、クラスタの前に何らかのゲートウェイなり、リバースプロキシを置いておきたいです。
あとは隣にクラスタを置けるだけのIPアドレスのレンジを持っておくことは、けっこう大事です。あとからインプレースアップグレードができない機能が出てきた時や、Kubernetesのクラスタのネットワークの設計を大きく変えたい時にやはりBlue/Greenをしたくなるので、そういう余裕を持っておくと、後々安心です。
2つ目の戦略サンプル 事前に他のクラスタで十分な検証をする
サンプル2ですね。これはサンプル1と相反するものではないのですが、「事前に他のクラスタで十分な検証をしましょう」というやり方です。Azure KubernetesサービスにFleet Managerという機能があり、クラスタのコントロール、オーケストレーションをしてくれる仕組みがあります。
これはアップグレードの順序制御もしてくれるので、検証環境のステージングに先にアップグレードをあてて、それがOKだったらプロダクション、本番にあてるという順序制御ができるようになります。
なので、検証環境を早めに上げて、1週間とか、十分な検証をできる時間をとっておきます。waitで7日間待つなどの設定ができるので、それがOKだったら本番をアップグレードするなんてことができます。
今のFleet Managerでもできるのですが、将来的には大規模なクラスタ環境を作られても、クラスタ5つとか、3つとか、4つとか、そのぐらいの数で、複数クラスタで1つのシステムを作りたい時には、例えば複数クラスタの順序順序でアップグレードしていくなどのコントロールもできるようになるので、クラスタのカナリアアップグレードも夢としてはあります。
今は単純にはできないですが、仕組みとしてはできます。APIを叩くだけです。
自動テストはけっこう重要です。これは深い話なので今日はしませんが、やはり気づくためにはアプリケーションを動かさないといけないので、アプリケーションの自動テストをどこまで仕組みとして作っておくのかは、けっこう大事な検討ポイントです。
ただ、網羅的なE2Eテストはいらないと思います。GUIを全部気にする必要はなくて、代表的なアプリケーションフローを通した時、Kubernetesのアップグレードがこけていると派手にこけるのでわかります。なので、網羅的なE2Eテストはしなくていいかなと思っています。
本セッションで話した内容におけるマイクロソフトの実績
まとめです。「今日の話は根拠があるのか」みたいな感想があると思うので、大きな実績を話していきます。マイクロソフト自身の実績ですね。「Office 365」や「Teams」、「Bing AI Copilot」や「GitHub Copilot」で使っている方もいます。「Xbox」やOpenAIの「ChatGPT」。これは全部AKSを使っています。24時間365日動いています。
これらのサービスが「アップデートだから」と言って止めるとか、ぽこすかセッションを切るなんてことはみなさんあまり感じていないですよね。うまくできるということです。24時間365日動かしながらアップグレードができるという証明をマイクロソフト自身がしています。
（スライドを示して）最後のまとめです。繰り返しになりますが、今は転換期だと思っています。「アップデートが大変だよ」というイメージをみなさんは持ってしまったというのがこれまでだったと思いますが、できるだけ自動化して楽をすることを考える転換期かなと思っています。コミュニティも、KubernetesとAKSも、成熟してきてツールも整ってきました。
あとは、トラブルシューティングガイド、ナレッジも、インターネット上で公式ドキュメントとして手に入るようになっているので、かなり整ってきているんじゃないかなと思います。
徐々に自動化する対象を広げていけばいい
最後に大事なことを伝えます。自動化は勇気がいると思います。「怖いからできない」という方が多いと思いますが、全部自動化する必要はないと思います。部分的に、段階的に自動化していけばいいと思います。
例えばNodeOSのイメージのバージョンアップだけ先に自動化するなど、徐々に自動化する対象を広げていけばいいと思います。それで経験なり能力を積んで、自信を積んで全体のアップグレードを自動化していくとか、そういうところにいつかたどり着けばいいという進め方でいいんじゃないかなと思います。
私は正直、ここ2年ぐらいアップグレードは失敗していないです。
実は以前に仕事の場で、「私、失敗しないので」と、（その場にいたASTの）齋藤さんに強く言い切りました。言い切れるぐらい自信があります。慣れてしまえばどうってことないです。シャア･（シャア･アズナブル）みたいなことを言いますが、どうということはないので、みなさんも慣れてください。
ということで、私の発表は終わります。ご清聴ありがとうございました。
