日本マイクロソフトの真壁氏が語る、AKSアップデートで考慮すべき3つポイント | AEON TECH HUB開催レポート Session#1

イオンにおける技術（テック）の中継地（ハブ）を目指す「AEON TECH HUB」が主催する第2回目のイベントが2024年3月26日に開催されました。

今回は「【2024年のAKSアップグレードを語る】ベストプラクティスと実践事例」をテーマに、“トール・マカベッチ”こと日本マイクロソフトの真壁 徹さん、エーピーコミュニケーションズの吉川 俊甫さんをゲストに招き、Azure Kubernetes Service（AKS）のアップグレードで考慮すべきポイントやその戦略、仕組みづくりについての知見を共有する場となりました。

この開催レポートは全4記事でお届けし、今回は日本マイクロソフト 真壁 徹さんのパートとなります。

▼ Session#2：エーピーコミュニケーションズ 吉川 俊甫さんの記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-22

▼ Session#3：イオンスマートテクノロジー 齋藤 光の記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-23

▼Q&Aセッションについてはこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-24

▼イベント詳細ページはこちら
https://aeon.connpass.com/event/308120/

【目次】

Session#1 AKSのアップデートを手なずけろ！まず理解 そして実践

日本マイクロソフト株式会社
シニアクラウドソリューションアーキテクト
真壁 徹

真壁氏のセッション全体の資料と本文はこちら

私は日本マイクロソフトで9年ほどソリューションアーキテクトとして従事しています。これまで、さまざまな案件をお手伝いしてきたこともあり、本日は「AKSのアップデート」に関しての知見やノウハウをお話できればと思っています。

最近、ポータルでAKSクラスタを作ると、Kubernetesの新しいパッチバージョンやノードVMの新しいイメージが出たら自動でアップグレードされる設定が既定になりました。ですが、3年くらい前までは「自動アップデートってインプレースですよね。辞めた先輩がインプレースだけはやってはいけないと言っていました」とか、「うちはクラスタのBlue/Green方式でバージョンアップしていて、大変だからやめたいけど、何かあったら怖い」、「怖くて一度もアップグレードしていません」といったネガティブな印象を持つお客さまが多い印象でした。しかし、ポータルの既定値の変更からもわかるように、最近ではこのような状況も少しずつ変わってきています。

AKSのアップデートの最新情報

ここで、AKSのアップデートについて最新情報をおさらいしていきます。
AKSのアップデートは以下の3種類があります。

• AKSメンテナンス（別称：AKSリリース）

• Kubernetesアップグレード（別称：クラスタアップグレード）

• Nodeイメージアップグレード

AKSメンテナンスは、Azureが管理系機能やアドオンなどを更新します。Kubernetesのマイナー/パッチバージョンのアップグレードは、自動もしくはユーザーが手動で行うことができます。Nodeイメージアップグレードは、KubernetesのWorker NodeのOSやソフトウェアの更新が行われ、Linuxの場合は週次、Windowsの場合はおおよそ月次でアップグレードされます。こちらも適用タイミングは自動化もできますし、ユーザー自身が決めることも可能です。

これら全てにおいて、クラスタを動かしながらそのクラスタをアップデートするインプレース方式が採用されています。AKSのアップデート情報はGitHubに網羅的にまとまっています。バグの修正内容や挙動の変更、インパクトの大きい仕様変更からバージョンアップ、機能追加まで、アップデートに関する情報が集約されているので、定期的にGitHubを見にいき、キャッチアップしておくといいでしょう。

Kubernetesのバージョンの見方は図の通りです。
セマンティックバージョニングのように見えますが、通常のセマンティックバージョニングは、APIが使えなくなった(廃止される、互換性がなくなる)段階でメジャーバージョンを上げます。しかし、Kubernetesはマイナーのバージョンを上げます。なので、Kubernetesのセマンティックバージョニングは少し毛色が異なることを覚えておくといいかもしれません。

AKSのKubernetesアップグレードでは、Kubernetesの新しいバージョンが出た際にAzure上にアップロードされ、ユーザーはそのバージョンを選べるようになります。また、定期的にLinuxやWindowsの新しいOSシステムイメージがアップロードされているので、こちらも新しいものが出たタイミングでユーザーは選択できるようになります。Kubernetesアップグレードを実行すると、ユーザーからは見えないAPIサーバーなど、マスターノード上で動くコンポーネントからアップグレードされます。それが終わったら、Worker Nodeのアップグレードへと移行します。Worker Nodeのアップグレードでは、新しいNodeに新しいイメージを追加して、その上に新しくバージョンアップしたKubernetesのNodeのコンポーネントを入れます。

新しいNodeが起動すると、既存のNode上で動いていたPodを動かせるようになるため、起動後は既存のNodeを削除します。これをすべてのNodeで順次行う、つまり「ローリングアップグレード」が、Kubernetesアップグレードの主な流れです。

AKSのアップデートで考慮すべきなのは「自動化するかどうか」を決めること

次に、AKSにおける3つのアップデートで考慮すべきポイントをお伝えしたいと思います。

アップデートの頻度や提供タイミング、強制適用の有無、自動化の可否、Nodeの再作成の必要性など、さまざま切り口がありますが、最も考慮すべきなのは、APIの破壊的変更の可能性のあるKubernetesのマイナーバージョンアップです。自動化しようと思えば全て自動化できます。どのアップデートを自動化するかを決めることが、AKSの運用負担を左右すると言っても過言ではないでしょう。

現在はAKSメンテナンス、Kubernetesアップグレード、Nodeイメージアップグレードの3種類を自動メンテナンス構成として設定できます。また、自動アップデートを適用する曜日や時間帯、頻度（日・週・月）も指定が可能になっています。

例えば、Kubernetesアップグレードは図のようなものになります。デフォルトは自動アップグレードをしないnone（APIの既定）に設定されており、patchは最新のパッチバージョンを自動で適用します。いっぽうでマイナーバージョンは自動でアップグレードされないようになっています。そのほか、stableやrapidは新しいマイナーバージョンで自動で適用するので、若干チャレンジングな設定だと言えるでしょう。

いっぽうで、こちらがNodeイメージアップグレードの詳細です。たとえばLinuxでは、ほぼ毎週新しいNodeイメージが出てきます。毎週Nodeイメージのアップグレードをしたくない場合には、noneやUnmanagedのチャネルを選択します。後者のUnmanagedは、OSの機能を使ってパッチを自動適用する選択肢ですが、いまはこちらを採用しているお客さまが多い印象です。

プラットフォーム技術者とアプリケーション開発者が担う役割

これまでAKSのアップデートの最新事情をお話してきました。ここからはAKSのアップデート戦略について考えていきたいと思います。

アップデートに関するトラブルの代表例としては3つのカテゴリがあります。

1. 環境や設定

2. アップデート内容

3. アプリケーションの安全でない停止と起動

1. 環境や設定

たとえばアップデートの際にNode追加が必要なケースで、準備不足だと起こりえます。「AKSをまずは試しに使ってみたい」という目的で検証用のサブスクリプションを利用するケースにおいて、、CPUクオータが小さい、または仮想ネットワークのIPアドレスレンジが狭いなどで上限に達してしまい、アップデートできないというケースが典型的です。

また、PodDisruptionBudget（使えなくなるPodの予算）のmaxUnavailable（使えない最大数の設定）を0にしてしまうなど、アップグレード時のDrain/Evictを妨げてしまう設定をしてしまうケースもあります。また、AKSはユーザーがカスタマイズした仮想ネットワークに配置できるので、AKSが必要とする通信を意識せずに作ったネットワークセキュリティグループ（NSG）ルールがアップデートを妨げる要因になったりします。

2. アップデート内容

主にKubernetesのマイナーアップグレード時に生じる問題です。廃止対象のKubernetes APIを使っていたことが原因で、バージョンアップした後にアプリケーションが期待通り動かなくなる問題は、経験上、実はあまり多くありません(補足: みなさん事前に対処している、あまり使われていないAPIだった、など、様々な背景がある)。ですが、Kubernetes 1.25へのバージョンアップのとき、APIではなくリソース管理機能（cgroups）が更新され、特定の言語ランタイムでCPUやメモリの消費が急増する、ということがありました。cgroupsがV2に上がったことにより、.NETやJavaなどの言語はCPUやメモリを急激に消費するようになったのです。

あとはKubernetesアップグレードではなく、Nodeイメージアップグレードに付随したトラブルとして、Nodeイメージを上げたことによってUbuntuのDNSの設定が変わってしまい、DNSが機能しなくなるということもありました。

3. アプリケーションの安全でない停止と起動

安全に止めることを意識していないアプリケーションにおいて、 PodをEvictionするタイミングで、処理中のリクエストがあるのにPodが削除されるなどが典型的なトラブルです。これはPodの削除とネットワーク設定が非同期で行われるKubernetesの構造的問題とも言えます。

また、Podの削除とともに新しくPodを起動させるわけですが、まだ準備のできていないPodにパケットが転送されてエラーが起きるトラブルもよく見られます。このようなトラブルが起こると想定した上で、プラットフォーム技術者はアップデートの戦略と仕組みづくりをリードしていくのが望ましいでしょう。

たとえば、AKSにはDeployment Safeguardsといった便利な仕組みが追加されました。アップデートに差し支えのあるリソースをそもそも“作れない”ようにするしくみです。こうしたしくみをクラスタに仕込むのも、プラットフォーム技術者の役割だと考えています。

そして、アップグレードされるバージョンで、廃止/非推奨になるAPIが使われていないかを事前にチェックすることも大切です。このチェックもAKSにある問題の診断と解決機能を使えば、Kubernetes 1.26以降では廃止/非推奨になるAPIが使用されているかどうかを確認できます。また、1.26以降で廃止/非推奨になるAPIの利用が検出されたクラスタでは、アップグレードの指示があっても実行せずに停止できるようになりました。

そして、アプリケーションの開発者がすべきこともあります。アプリケーション開発者はアプリケーションのグレースフルシャットダウンを考慮し、安全に止めて消せるような仕組みを作るようにしましょう。先ほど、新しいPodが準備ができていないのにトラフィックを送ってしまうトラブルに触れましたが、「準備ができた」と確認できるReadiness Probeの設定を行い、正常性を確認できるエンドポイントをチェックすることも大事です。あと可能であれば、アップデートされるクラスタで動いているアプリケーションを"呼び出す"側のエラーハンドリングまで考慮するのが望ましいです。

「アップデートは理解を得やすいカオスエンジニアリングであり、アプリケーションの回復性を確かめる絶好の機会である」

皆さんの中には、自分たちが面倒を見ているシステムアプリケーションの強さを常に確認する「カオスエンジニアリング」をやりたいと思われている方も多いかもしれません。しかし経営、ビジネス側から、本番システムで障害注入を認められないことが多いでしょう。

ところでアップデートには、健全に使い続けるために脆弱性を防いだり、バッチをあてたりといったやるべき理由があります。そしてKubernetesのアップデートは「壊して、作って」を繰り返しているので、ある意味で“カオス”です。私は、しっかりと戦略と仕組みを作ってアップデートを行っていけば、それはある意味、カオスエンジニアリングができていると言えるのではないか、と考えています。

ここまで、プラットフォーム技術者とアプリケーション開発者を分けて話してきましたが、両者がともに担う役割、協力して行うことについても紹介します。

まずは、アプリケーションを動かしてテストすることが重要です。先述したトラブルの大半は事前にテストをしていれば防げるものです。なので、テストは前提です。それをどれだけ楽にするかがポイントになるでしょう。机上でトラブルを事前に把握するべきという意見もありますが、Kubernetesとその周辺要素は多く、かつ変化していくためにどうしても漏れは出てきます。ゆえに、アプリケーションを動かして試した方が早く確実です。

なお、アップデートを早く終わらせるのと、影響範囲を最小限に抑えながら徐々に進めていくことのトレードオフがあります。どちらが正しいかの答えはないので、メンテナンススケジュール含めて関係各所で議論して調整していくのがベターです。そして忘れてはならないのが、ユーザー視点でサービスレベルの監視を確立することです。たとえば、AKSのアップデートが途中で止まっても、アプリケーション自体は問題なく動き続けるケースは多いです。

ユーザーに影響が出ていないことがわかっていれば、アップグレードの対処に余裕ができます。そのため、サービスレベルの監視の確立は大事なポイントのひとつです。

アップデート戦略の具体例に見る最適解

ここで、アップデート戦略のサンプルを2つほど紹介したいと思います。

アップデート戦略サンプル①｜AKSの既定、推奨ベース

まずはAKSの推奨に従うやり方です。
Kubernetesとその周辺のエコシステムが成熟してきた今、自動アップグレードやインプレースアップグレードのリスクは下がってきています。このシナリオでは、マイナーアップデートは手動です。いっぽう、パッチバージョン、Nodeアップグレードは自動です。そのうえで、日中か夜中に実行するのかというスケジュールを工夫するのが、今後のスタンダードになると考えています。

実は去年の秋くらいにKubernetesのプロダクトマネージャーが日本に来て、その際にアップデート戦略について議論を重ねたんです。その後も様子を見ながら色々なお客さまと議論を行い、実績を見てきたなかで、このやり方が主流になっていくのではと思うようになりました。

しかし、インプレースアップグレードを行う際には、リカバリー手段を用意しておいた方がいいでしょう。まずは原因を取り除いてアップデートを再試行する手段です。私としては、次に紹介するバックアップからの戻しではなくアップデートを完遂することをおすすめします。バックアップから戻して作り直すよりも、シンプルでわかりやすいからです。

問題の診断と解決機能の充実や、エラーの原因が推測される際にポータルの概要画面に対処法へのリンクが表示されるようになるなど、比較的スムーズに原因の特定と解決ができるようになっていることが、おすすめの背景にあります。よって、アップデートをやりきるのが良いと私は考えています。

もうひとつはバックアップから戻すやり方ですが、これは意外に複雑(手数が多い)です。もし取り組む場合には参考資料を見ていただくといいでしょう。なお、インプレース方式を選択した場合でも、いざという時のためにBlue/Green方式もできるようにしておくと安心です。

具体的には、クラスタの前に何らかのゲートウェイやリバースプロキシを置いておいたり、追加クラスタを作れるだけのIPアドレスレンジを確保しておいたりします。将来のKubernetesのバージョンで、インプレース方式でのアップグレードのリスクが見つかるかもしれません。また、クラスタのネットワークなどインフラを大きく変えたくなるかもしれません。よって常用手段ではなくとも、Blue/Green方式を代替手段として選べるようにしておくのは、おすすめの戦略です。

アップデート戦略サンプル②｜事前検証の仕組み化

もうひとつは、本番とは別のクラスタで事前検証を仕組み化するアップデート戦略です。
Azure KubernetesにはFleet Managerという、複数のクラスタをオーケストレーションし、アップデートの順序制御を行ってくれる機能があります。この機能を用いれば、検証環境やステージングへ早めにアップデートをあてて、十分な検証できる時間を設け、それが問題なければ本番環境に上げるという順序制御ができるようになります。

将来的には、複数クラスタで一つのシステムを作りたい場合でも、クラスタごとに順序を決めてアップデートさせていく、カナリーリリース的な手段も可能になるのでは、と思っています。(補足: 現在の私見です)そして、アプリケーションの自動テストをどこまで仕組みとして作っておくかは、大事なポイントです。

とはいえ、たとえばUIの網羅的なテストなどは不要と考えます。アプリケーションに影響のあるようなアップグレード失敗であれば、代表的なフローを通せば問題に気付けることがほとんどでしょう。よって網羅的なE2Eテストは不要で、多くは正常性エンドポイントのチェックで事足りると考えています。AKSのアップデートは、「アップデートが大変」から「できるだけ自動化して楽にする」への転換期に差し掛かっていると感じています。知識やドキュメントが整備され、支援機能やツールも充実してきていますし、 Kubernetesコミュニティもバージョンアップ体験を気にかけるようになっています。

自動化は勇気がいると思いますが、いきなり全部自動化する必要はありません。部分的、段階的に取り組んでいけば良くて、徐々に自動化する対象を広げていけばいいでしょう。私自身、ここ2年くらいはアップデートに失敗していません。自信をつけ、慣れてしまえば問題なく自動化に取り組んでいけるのではないでしょうか。

イオンが主催するAEON TECH HUB #2、今回はAKSアップグレードというコアな話題をテーマにさせていただきました！今後も、様々なテーマを取り上げていきますのでAEON TECH HUBをよろしくお願いします。

AEON TECH HUB #2開催レポートのその他記事もございますので、ぜひご覧ください。

▼ Session#2：エーピーコミュニケーションズ 吉川 俊甫さんの記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-22

▼ Session#3：イオンスマートテクノロジー 齋藤 光の記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-23

▼Q&Aセッションについてはこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-24

イオングループでは、一緒に変革に挑んでくれる方を募集中です。カジュアル面談も実施しておりますので、少しでも気になった方はお気軽にご連絡ください。まずはざっくばらんにお話しましょう。