「AKSアップグレードしんどい問題」を解決するための5つの提案 | AEON TECH HUB開催レポート Session#2

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

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

この開催レポートは全4記事でお届けし、今回はエーピーコミュニケーションズ 吉川 俊甫さんのパートとなります。

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

▼ 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#2 「がんばらない」AKSアップグレード方法を考えよう

株式会社エーピーコミュニケーションズ
Microsoft MVP for Microsoft Azure
吉川 俊甫

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

私は現在、テクニカルエバンジェリストとして業務を行っています。2023年6月にMicrosoft MVPを受賞させていただいたほか、Platform Engineering Meetupというコミュニティの運営メンバーにも関わっています。

私が皆さんにお伝えしたいのが「AKSのアップグレードは“しんどく”ないですか？」ということです。3〜5ヶ月に1回の高頻度でバージョンアップが発生したり、バージョンを1つずつ上げる必要があったり、アップグレードの度に夜勤でメンテナンスする必要があったり。さらには、AKSには開発環境、本番環境、ステージングなど、たくさんのクラスタがあり、それら全部をアップデートしていくのは大変であり、一度アップデートするとダウングレードはできません。

このように、AKSのアップグレードではさまざまなツラミを感じるポイントがあります。そうは言っても、セキュリティやサポートは無視するわけにはいきません。そんなバージョンアップ作業を「頑張って乗り越える苦難な作業」ではなく「日常の当たり前な作業」として行うための方法をお話しできればと思います。

第1案 「アップグレードしなくていい」アーキテクチャに移行する

Kubernetesは基本的にバージョンを上げても、自社プロダクトの売上や利益が増えるわけではありません。新バージョンに対応した機能がプロダクトに新たな価値を生み出すことはほとんどない、そうすると往々にして、バージョンアップは“守りの作業”になりがちです。

もし、AKSのアップグレードがしんどいのであれば、手放すことも視野に入れるのも1つの手段です。

幸いにも、AzureにはWeb App for ContainersやAzure Container Instances、Azure Container Appsといったコンテナを扱えるサービスが複数あるため、AKSを試しに使ってみたはいいものの、長期的に運用していくのにしんどさを感じるのであれば、より事業者側に運用をお任せできるマネージドサービスに移行するのもいいのではと考えています。

クラウドの良いところは、いつでもサービスを使い始めたり、止めたりすることができ、かつ自社で資産を持つ必要もない点です。運用面やツラミを鑑みて、AKSのアップグレードにこだわらず、他の代替手段を考えていくのも選択肢として検討していくことが重要なのではないでしょうか。個人的には、AKSから移る最適な選択肢として、KubernetesベースのフルマネージドサービスであるAzure Container Appsがおすすめです。

これは2022年5月にGAした比較的新しいサービスなので、それ以前にAKSを利用していた場合は、システムのアーキテクチャ選定の土俵に載せていない可能性もあると思います。あらためて自社のユースケースに合うかどうかを検討するといいでしょう。

第2案 バージョンアップ作業を楽にする

ネットワークや採用しているソフトウェアなどの諸々の都合によって、アーキテクチャの変更はそう簡単にできるわけではありません。引き続きAKSを使う場合には、バージョンアップ作業そのものを軽減させていくことを考えなくてはならないわけです。

そうしたなか、AKSには利用可能なバージョンがリリースされたら、自動的にアップグレードする「自動アップグレード機能」があります。クラスタを作成する際のデフォルトの設定が、パッチリリースの適用は自動でやるという設定になっていることから、そろそろ自動アップグレードに頼ってもいい頃合いだと、私は考えています。

さらにメンテナンス実行のスケジュールも設定可能なので、年度末やビジネス上の繁忙期などに自動アップデートされないよう、自社の環境や組織体制に合わせて柔軟にスケジューリングできるのもメリットと言えるでしょう。また、Event GridのイベントソースとしてAKSを使用すると、新しいバージョンが利用可能になったときや、現在利用中のバージョンがサポート対象外になった際に通知してくれるので、自動アップデートと併せて使うのがおすすめです。

そして、ノードプールのアップグレード開始や成功、失敗といったイベント発生時に、Azure FunctionsやAzure Logic Appsを組み合わせることで、後続処理の自動化を容易に実現することが可能になります。

とはいえ、自動化が怖いと感じる方もいると思います。そういった場合の方策として、複数のAKSクラスタのアップグレードをまとめて実行可能なサービスのAzure Kubernetes Fleet Managerを使うのがおすすめです。アップグレードの適用順も制御できるため、開発環境からステージング、本番環境と、順を追ってアップグレードを更新できるようになるのです。

特にクラスタ数が多い企業にとっては、こうしたやり方によってアップグレード作業にあたる人手を減らす打ち手にもなりうるでしょう。

第3案 バージョンアップ作業を少なくする

AKSでは2023年4月にLong Term Support（LTS）が発表されました。Kubernetesコミュニティによる特定バージョンのサポートは1年でしたが、その期間が終わってもMicrosoftがさらに1年間の追加サポートを提供するようになったのです。現状、v1.27がLTSバージョンとして設定されており、標準サポートが2024年7月まで、LTSは2025年7月までとなっています。つまり、アップデートしないままでも、サポートが得られる状態でAKSを長期間使うことができるわけです。

ただし、v1.27は現在サポート期間中で、まだLTSがどういう形で提供されるかの詳細は不明となっています。公式ドキュメントには情報がいくつか記載されているので、事前に目を通しておくといいでしょう。今わかっているLTS適用の条件は次の2つです。

• クラスターの価格レベルをPremium以上にする

• AKSLongTermSupportオプションを設定する

Premium価格レベルの費用感は1クラスター1時間あたり約90円と、Freeレベルと比較して1ヶ月に6〜7万円のコスト増となることだけ注意しましょう。

制約事項としては、Kubernetes本体に対しては適用されるものの、AKSで提供されるIstio、KEDA、Dapr、Application Gateway Ingress Controllerなどのアドオンについては対象外になります。要は対象外のアドオンを有効化しているとLTSヘ移動できないわけです。これらの機能が必要な場合はAKSアドオンではなく、OSS版を別途インストールするなどの対処が別途発生してきます。

ちなみに次のLTSバージョンがリリースされたら、現行LTSバージョンから次のLTSバージョンへの更新パスが提供されるそうです。ただ個人的には、高コストかつ制約も多いので、あまり積極的には利用したくないと思っています。

次のLTSバージョンへ移行できると言っても、Kubernetesのマイナーバージョンがいきなり3つ上がることになるので、かなりのインパクトが予想され、相応の手間が生じることは覚悟しておいた方がいいかもしれません。どうしても、アップデートが間に合わないのであればLTSを利用しつつも、できるだけ早くv1.28へ上げるのが得策だと考えています。

第4案 バージョンアップ作業のリスクを減らす

前述したように、AKSのアップグレードは元に戻すことができません。そのため、「アップグレードしても問題ないこと」をどのように確認し、安全性を担保するのかということに対し、頭を抱えている方も多いのではないでしょうか。

よくあるのは開発環境でまず確認して、その次はステージ環境をアップデートし、そこで問題なければ本番環境に反映していくプロセスです。

これを、オンプレミス環境のときと同じような数ヶ月スパンのスピード感でやると、その間にAKSの新バージョンがリリースされ、検証していたバージョンが選べなくなることも起きる可能性もあります。そうなれば、また始めから検証し直す必要が出てくるため、もし複数環境を順番にアップデートしていく際には、速やかに行うことがポイントになります。

安全を期してアップデートを行おうとすれば、Blue/Green方式のデプロイが最良の手段だと言えるでしょう。新バージョンのGreenクラスタを準備して、NW上位側でBlueクラスタからGreenクラスタへ切り替えていけば、何か問題が起きてもBlueクラスタはそのまま残っているので、NWの切り替えのみで切り戻しできるわけです。

一方でBlue/Green方式のデプロイを行うなら、VNetやSubnetの設計を考えたり、Blue/Greenのどちらが本番の運用になっているのかを関係者へ伝達したりと、最初からその前提で構成することが求められます。そうしないと、後から対応するのが難しくなってしまうからです。NW上位側での切り替え方式を検討する際も「100:0」で切り替えたいのか、徐々に切り替えていくのかを定めることや、WAFやCDNの必要性など、要件に合わせたネットワークリソースを検討していくことが大事になります。

また、Blue/Greenの2つのクラスタの設定がずれないようにするために、Bicep やTerraformなどのInfrastructure as Codeを活用することを強く推奨します。

第5案 組織体制でカバーする

ある程度大きな組織だと、プロダクトを持っている複数のチームごとにクラスタをバラバラに管理しているパターンがあります。この管理方法のメリットは独立性が担保されることです。ですが会社全体で見ると、同じような作業をいろんなところで行っていて、かつナレッジが共有されないため、サイロ化の要因になるのがデメリットに挙げられます。

デメリットを解消するために、プラットフォームチームを作り、そのチームがクラスタ管理を行い、各プロダクトのチームはクラスタを利用するといった形で作業を分割することで、全体効率化が図られると思っています。

これは最近注目がされているプラットフォーム・エンジニアリングの考えをもとに考えたアプローチで、興味がある方はプラットフォーム・エンジニアリングについても調べていただけると幸いです。AKSのアップデートに伴う「しんどさ」を軽減するための方法はいくつかあるので、まずは自社の組織にマッチしたやり方を試行錯誤してみて、「しんどい作業」から「当たり前の作業」に変えていければいいのではないでしょうか。

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

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

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

▼ 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

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