アップグレードはアプリケーションの回復性を確かめる機会　AKSをヘルシーに運用するための、それぞれの役割

環境や設定による、AKSアップデートの失敗例

真壁徹氏：ここからは、どうやって（AKSを）アップデートしていくかという戦略を考えましょう。今日のメインですね。

（スライドを示して）このスライドが、たぶん今日の私のセッションの中で一番価値がある気がします。私の知見です。アップデートに関するトラブルの原因の代表例をまとめてきました。

カテゴリは3つあります。まず、環境や設定に起因するトラブルはけっこうあります。例えば、アップデートする時にNodeを追加していくという話をしました。その時に、max-surgeという、どのくらいNodeを追加するか。ローリングアップグレードのいわゆる派手さ加減を決められるパラメーターがあるのですが、それを大胆に広げることで、Nodeがバーンッと増えます。そしてCPUの必要な数が増えます。

AKSを運用されるお客さまだと、CPUの「これ以上使えませんよ」という、「クォータ」の値をけっこう上げていると思います。

ですが「まずは検証環境でAKSを試しに使ってみようかな」というお客さまのサブスクリプションは、CPUのクォータの上限がすごく低かったりするんですよね。そうすると、「CPUのクォータに達したぞ」といってアップグレードがこけるケースが過去にかなりありました。最近では少ないですが、（アップデートが失敗する）典型的なところですね。

2つ目。これは意外と多いんですね。PodDisruptionBudgetというPodの設定です。DisruptionBudgetなので、メンテナンスをする時に使えなくなるPodの予算、Budgetですね。「このくらいは、このタイミングで使えなくなっていいよ」みたいな設定ができます。maxUnavailableは使えない最大数を設定するパラメーターですが、これを0にすると「1個もDisruptionするな」という設定になります。

先ほど話したとおり、アップグレードの時にDrainして、Evictionをします。そうすると、1個は必ずDisruptするわけですね。ということで、アップグレードプロセスが固まります。固まってタイムアウトしてアップグレードがfaileする。これもけっこうあります。

あとはAKSのネットワークまわりですね。ユーザーの作った仮想ネットワークに入れられるので、けっこうカスタマイズできます。ネットワークのルールに厳しいユーザーだと、かなり細かくNSG（Azure Network Security Group）、セキュリティルールを後から差し込んでいて、アップグレードに必要なソフトウェアを取ってくるネットワークにアクセスできなかった、止まるみたいなケースもけっこうあります。これが環境や設定にまつわる代表的なトラブルです。

アップデート内容による、環境や設定によるAKSアップデートの失敗例

2つ目のカテゴリはアップデート内容ですね。これは特にKubernetesのマイナーバージョンのアップグレードに起因するものです。廃止対象のAPIを使っていて、バージョンアップしたらアプリケーションが期待どおりに構成されなかった。これはみなさんが一番怖いと思っているケースだと思います。

ただ、これは実はあまり多くないですね。ビビるほど多くない。ただ「あると怖いね」というトラブルです。

次は、これは相当ありました。1.25（Kubernetes 1.25）かな？　1.25の時にcgroupsというリソース管理の機能がv2に上がりました。.netやJavaはcgroupsを見てリソースコントロールしていたりしたので、1.25に上げたらCPUやメモリの使用量が増加してしまうというトラブルがありました。

3つ目はマイナーバージョンアップではないのですが、NodeOSのイメージを上げたら、UbuntuのDNSの設定が変わって、DNSが機能しなくなったという問題がありました。これはKubernetesではなく、Nodeイメージのバージョンアップの内容に起因するトラブルです。

アプリケーションの安全でない停止・起動よる、環境や設定によるAKSアップデートの失敗例

最後のカテゴリは、アプリケーションの安全でない停止と起動です。繰り返しになりますが、アップグレードをする時にPodのEvictionが走って、Podを消すんですよね。なので、安全に止めていない、止めることを意識しないアプリケーションでは、そのタイミングでコネクションをパカパカ切って、ゲートウェイからHTTP 50Xエラーが返るというのがものすごく典型的な不具合です。

あとは、Podを消すのと同時に新しいPodを作りますが、そのPodの起動に時間がかかって、まだ準備ができていないPodにパケットが送られてエラーが出たというケースもけっこうあります。

プラットフォーム技術者の役割

ということで、プラットフォーム技術者とアプリケーション開発者のそれぞれがやらなければいけないことがあります。まずはクラスタの面倒を見るとか、うまく回る仕組みを作るプラットフォーム技術者の方が、アップデートの戦略と仕組みの仕組み作りをリードするべきかなと思います。戦略と方針を決めて、実装していく。

ところで最近便利な仕組みがAKSに加わりました。例えば先ほど話したPodDisruptionBudgetなどで、アップグレードに差し支えがある設定がされているものは作れないようにするDeployment Safeguardsという機能が最近追加されています。

このようにアップデートを妨げるようなリソースを仕組みとして作れないようにすることができるようになりました。こういうものをクラスタに仕組むのは、プラットフォーム技術者の役割かなと思います。

あとは事前に「Sli.do」にも質問があったと思いますが、廃止されるAPIや非推奨のAPIがアップグレードするバージョンで使えなくなったとかのチェックもできるようになっています。AKSには問題の診断と解決機能というメニューがあって、この中を見ると、1.26以降であればアップグレードする前に「これが廃止されるよ」というチェックができるようになりました。

かつ、これはデフォルトですが、それに気づかずにアップグレードを走らせても、1.26以降であればアップグレードを事前に止め（ることができ）ます。「非推奨のAPIを使っているからアップグレードを止めますね」という仕組みが入っているので、1.26以降はけっこう安全にアップグレードができるようになります。

アプリケーション開発者の役割

次がアプリケーション開発者の役割です。これは強くお願いしたいのですが、アプリケーションのグレースフルシャットダウンですね。Evictionが起きるとPodがDeleteされるので、安全に止まって消せるような仕組みをアプリケーション側で考慮してください。「これはアプリケーション開発者の仕事だ」と、強くお願いします。

そして、新しいPodに準備ができていないのにトラフィックを送っちゃうという話をしましたが、これもReadiness Probeで「ちゃんと準備できているか」というチェックができるようになっているので、アプリケーション開発者の方が気をつけて設定してください。

それから、「準備できているよ」という返事ができる正常性エンドポイントも、アプリケーション側で作ってください。

あとは可能であれば、そのKubernetesのアップグレード対象のクラスタのAPIなり何なりを呼び出す、呼び出し側がいると思うんですね。ゲートウェイとかでクライアントアプリケーションがあると思うのですが、そういったアプリケーションは、例えば一瞬50Xエラーが返ってきたとしても「もう1回聞いてみるか」とリトライしてほしいです。

それが長く続くようであれば潔くタイムアウトして、クライアントには「すみません、今は使えません」と丁寧にエラーを返す。こういう考慮もしてほしいなと思います。

アプリケーションが問題なく動いているということは、回復性を常に確かめているということと同じ

思想家の“トール・マカベッチ”（真壁徹氏）が、今日もいいコメントをくれました。「アップデートは、実は理解を得やすいカオスエンジニアリングです。アプリケーションの回復性を確かめる絶好の機会である」と。この人はいいことを言いますね。さすが21世紀を代表する思想家、コンピューターサイエンティストです。

カオスエンジニアリングはみなさん「やりたい」と思っていますよね。自分たちの面倒見ているシステムやアプリケーションの強さを常に確認する取り組みです。何かエラーを注入して常に確認することをやりたいと思っていると思います。しかし、ビジネス、経営側の「うん」はだいたいもらえません。「そんなことやるんじゃねえよ」「本番システムで障害注入というのはまかりならん」と言われるケースが多いと思うんです。

だけど、アップデートであればいかがでしょう。脆弱性をちゃんと防ぐ。パッチをあてる。あとは「健全に使い続けられるようにアップグレードするんです」という口実があれば、障害を注入しているわけじゃないですが、Kubernetesのアップグレードは壊して作ってを繰り返しているので、ある意味カオスなんですよね。

なので、アップグレードをきっちりするというのは、カオスエンジニアリングがある意味しっかりできているということなんじゃないかと私は思います。

なので、そういうコメントをもらったとしても、アプリケーションが問題なく動いているということは、回復性を確かめているのと同じだと、“トール・マカベッチ”さんは言っています。

アプリケーション開発者の役割、プラットフォーム技術者の役割以外の「みんなの役割」

今、アプリケーション開発者とプラットフォーム技術者の役割を分けましたが、みんなの役割もあります。プラットフォームを作って、アプリケーションを動かした上で、やはりテストをしてください。先ほど話したようなトラブルは、だいたいはテストしていれば防げるんですよ。なので、テストをどれだけ楽にするかがポイントだと思います。

よく「机上で事前に確認すべきだ」みたいなことを言われます。ごもっともですが、まぁ漏れます。Kubernetesは構成要素が非常に多いし、どんどん新しい考え方が入ってきて、人間の認知を超えています。事前に机上で認知できる、確認できるレベルを越えているので、やはり動かして試す。チェックしたほうが早くて確実です。

アプリケーションを動かして、プラットフォーム技術者の方とアプリケーション開発者の方が話し合って、それができる仕組みを作ってほしいなと思います。

あとはトレードオフがけっこうあります。アップデートを早く終わらせたい人と、影響範囲を小さくじわじわ進めたい人。これはどっちも設定でできます。できるので、答えはないです。なので、アプリケーション開発者の方とプラットフォーム技術者の方と、あとはビジネスサイドで話し合ってどちらでするかを決めてください。

あとはそのタイミングですね。業務影響の小さな夜間とか休日にしたい人もいれば、「いやいや、対応できる人は日中の昼間にいるんだから、昼間にやっちゃおうぜ」みたいな（人がいたり）「アプリケーションはどんと来い！」という環境であれば、昼間にやったほうがいいですよね。このあたりはトレードオフなので、これもみんなで話し合ってくださいね。

最後。これはけっこう大事です。「監視ってプラットフォーム技術者がやるべきだ」とよく言われますが、そうじゃなくて、アプリケーション視点、言ってみればユーザー視点でちゃんと動いているかという、サービスレベルの監視の仕組みもしっかり作ってください。

Kubernetesのアップグレード、AKSのアップグレードが途中でこけてもアプリケーションは普通に動くケースは多いです。これは裏を返せば、ユーザーに影響が出ていないのが監視でわかっていれば、アップグレードの対処に余裕ができるということです。余裕ができるので、ユーザーレベルでのサービスレベルの監視を確立していくのは、ヘルシーに運用する上でけっこう大事なポイントです。

最近だとユーザー監視や合成監視、Synthetic Monitoringとか、手軽に、簡単にできるツールも出てきているので、ぜひ考えてください。

（次回につづく）