AKSアップグレードにおける具体的な質問に登壇者が回答、Q&Aセッション全公開 | AEON TECH HUB開催レポート Session#4

2024/3/26

イベントレポート

#AKS

#Azure Kubernetes Service

#イオンスマートテクノロジー

#AEON TECH HUB 開催レポート

この記事に登場している人

真壁徹

Toru Makabe

北陸先端科学技術大学院大学修士（情報科学）
株式会社大和総研、日本ヒューレット・パッカード株式会社を経て、日本マイクロソフト株式会社に入社。

吉川俊甫

Shunsuke Yoshikawa

2022年2月に株式会社エーピーコミュニケーションズへ入社。Azure/GitHub導入支援業務に従事する傍ら、テクニカルエバンジェリストとしてAzureやPlatform Engineeringに関する情報発信を行い業界の盛り上げに挑戦中。

齋藤光

Hikaru Saito

イオンスマートテクノロジー株式会社 Developer Enablementディビジョンディレクター
SIer2社を経た後、ネット系金融会社でインフラ/運用部門責任者やプロダクトマネージャーを経験。その後、小売業で全社共通プライベートクラウド基盤の設計・構築・運用に携わった後に2022年5月にイオンスマートテクノロジーへ入社。

真壁徹

Toru Makabe

吉川俊甫

Shunsuke Yoshikawa

齋藤光

Hikaru Saito

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

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

この開催レポートは全4記事でお届けし、今回はQ&Aのセッションパートとなります。

▼ Session#1：日本マイクロソフト真壁徹さんの記事はこちら
https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-21

▼ 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

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

【目次】

Q&Aセッション
Q：コントロールプレーンをパッチ、ノードは手動とした場合、Kubernetesバージョンが異なる場合が起こると思うが、最大いくつまでバージョンが異なっても大丈夫なのか。
Q：Azure Kubernetes Fleet Managerは、Blue/GreenやCanaryでのKubernetesクラスタのアップグレードに利用可能なのか？
Q：アップグレードはインプレース、Blue/Green、Canaryのどの方式をとられているのでしょうか？
Q：Deprecated APIの確認方法はどうしているのか？
Q：本番環境、テスト環境ともに1面しか無い場合、アップグレードの自動化を可能な限り安全に行う方法はあるのか。
Q：アップグレード未経験だが、「アップグレードの失敗」とはどういう状態なのか。経験した事例を踏まえて教えていただきたい。

Q&Aセッション

Q&Aセッションでは、オンラインで参加されている皆さんからの質問に、それぞれが回答していきます。

Q：コントロールプレーンをパッチ、ノードは手動とした場合、Kubernetesバージョンが異なる場合が起こると思うが、最大いくつまでバージョンが異なっても大丈夫なのか。

真壁：（AKSの自動アップグレードチャネルを使う場合）コントロールプレーンとノードは同じKubernetesバージョンに上がります。(補足: 自動アップグレードチャネルを使わず、手動でアップグレードする場合は、コントロールプレーンとノードを分けてバージョンアップできます。AKSでは1.28以降、最大3バージョンまでの違いをサポートしています)

Q：Azure Kubernetes Fleet Managerは、Blue/GreenやCanaryでのKubernetesクラスタのアップグレードに利用可能なのか？

真壁：Fleet Managerはあくまで、クラスタのバージョンアップの順番とタイミングを制御する機能で、アップグレードを意識したトラフィック振り分機能はありません。なので、別途Azure Front Doorなどリバースプロキシが要ります。

また、Fleet Managerの提供機能はアップデートの順番とタイミングの制御なので、Blue/Greenで重要な、切り替え後の戻しはできません。しかし、クラスタの数が増えれば、いろんな順序制御が考えられるため、今後Blue/Greenのような使い方ができるようになる可能性はあります。私が今のところ思いついていないだけで、今後面白い使い方が出てくるかもしれません。

Q：アップグレードはインプレース、Blue/Green、Canaryのどの方式をとられているのでしょうか？

齋藤：インプレースとBlue/Greenを使っていますが、Canaryまではできていません。

香西：これまで対応してきたなかでは、どのようなアップグレード戦略が多いのでしょうか？

真壁：アップグレードのリスクをそれほど重く考えていないユーザーはインプレースが多いですね。一方で、基幹系システムのマイグレーションや可用性の向上を望まれるお客さまはBlue/Greenを選択しています。そのなかで「Blue/Greenはしんどい」という声もよく聞かれます。インプレースのリスクは高いのではという声は多いですが、Blue/Greenの環境構築や切り替え作業で新しいリスクが発生することもあるので、「Blue/Greenの方がリスクが低い」とは一概に言いづらいと思っています。

また、クラスタアップグレードでCanaryという事例はそんなにありません。ただ、Microsoftは膨大な数のAKSクラスタを使ってサービスを提供しているので、それに近いことはやっています。

吉川：私がお手伝いしているお客さまだと、リスクを取りたくないという理由からBlue/Greenを採用する場合が多いです。

Q：Deprecated APIの確認方法はどうしているのか？

真壁：バージョン1.26以降であればAKSの方で弾いてくれます。実際のユーザー目線での意見はいかがですか。

齋藤：最新のAPIのバージョンを教えてくれるオープンソースがあり、それを使って確認を楽にしている部分は多少ありますね。仮に確認漏れが起きたとしても、いきなり本番環境でやる勇気のある人はいないと思うので、検証フェーズで自然に判明するのではないでしょうか。

吉川：機能がリリースされる前に、ChangeLogの確認とKubernetes系のユーザーコミュニティに参加している方々からの情報をキャッチアップするようにしています。

特に破壊的な変更が生じた際はSNSでも話題になるので、そこはチェックしにいくようにしていますね。もちろん、情報の信頼性も含めて精査する必要はあるものの、SNS上で飛び交っている情報は無視できないと私は思っています。

Q：本番環境、テスト環境ともに1面しか無い場合、アップグレードの自動化を可能な限り安全に行う方法はあるのか。

真壁：ツールはかなり充実してきたので、事前に失敗を防げるようになってきていますが、やはりアプリケーションを動かしてテストする、テスト環境でバージョンアップしてみることが重要です。テスト環境でしっかりできているのであれば、本番環境でも自信を持ってバージョンアップに取り組めるでしょう。いっぽう、アプリケーションのテストはいまだに手作業で、エビデンスもスクリーンショットをエクセルに貼る、という現場もあるでしょう。これだと、アップグレードの度に毎回すごく工数がかかってしまいます。今の時代、アプリケーションのテストを機械的に行う「自動テスト」は、今回のアップデートのように、ほかの領域にも影響する大きなテーマだと私は考えています。

齋藤：ひと通りの動作確認は自動でやっています。何を持って安全かはありますが、一つひとつのことを楽にすること、いつでも作り直せる余裕を持たせておくことが大事になるのではないでしょうか。

吉川：テスト環境から本番環境までのリリースを機械的にできるようにすることに加えて、何か問題が起きた場合には速やかにリカバリーできるIaCを取り入れるといいでしょう。あとはBlue/Greenでクラスタそのものを二重化することで、安全性の担保につながります。

真壁：何か起こってしまった場合にまで話を広げると、トラブル対応時の緊張や委縮は事前に解決したい課題です。普段よりも緊張してしまえば、考える幅が狭くなってしまいがちなので、トラブルシューティングガイドを準備しておくのがおすすめです。「何か問題が起きたら、マイクロソフトが公開しているトラブルシューティングガイドを見にいく」というフローを作っておくだけでも効果はあると思います。。

Q：アップグレード未経験だが、「アップグレードの失敗」とはどういう状態なのか。経験した事例を踏まえて教えていただきたい。

真壁：私のセッションでお話した内容に含まれていますが、他にもしあればおふたりからも伺いたいと思います。

吉川：昔のバージョンであった話だと、コンテナのランタイムが変わったことがありました。そのバージョンを境に、コンテナイメージをpullできなくなってしまいました。その原因を色々と調査していくと、イメージのレジストリをAzure Container RegistryではなくVM上にコンテナレジストリのソフトウェアをインストールして使用していました。そこに対する通信は、商用の証明書ではない自己証明書でTLS通信を行っていて、そのルート証明書を各ノードに配置して、イメージのレジストリをpullできるように設定していたのです。ただ、それはあくまでDockerを前提に設定していたため、ランタイムが変わったことで、TLS通信が効かなくなり、全くpullできなくなってしまったわけです。この事例を経験して言えるのは、「あまり変わったことはしない方がいい」ということですね。Azureのマネージドサービスを利用するなど、固い構成をとった方が変な障害を踏まなくて済みます。お作法にしっかりと則った方が、余計な手間はかからないと言えるでしょう。もちろん、さまざまな事情で標準のおすすめされている構成から外れなくてはならないこともあると思います。その場合は、その構成の特性を自分たちでも把握しておくことが大事になります。

齋藤：真壁さんが示した内容はいくつか経験していますが、一番印象的だったのはcgroupsの仕様が変更されて特定の言語ランタイムでメモリ消費が急増したことでした。ただ、どちらかと言えば「アップグレードしないからトラブルになる」ケースが多い気がしています。