イオンスマートテクノロジーで実践している AKSアップグレード戦略 イオンスマートテクノロジー株式会社 CTO室 SREチーム 齋藤光 AEON TECH HUB #2 2024年3⽉26⽇

自己紹介

⾃⼰紹介 齋藤光( @hikkie13 ) イオンスマートテクノロジー株式会社 CTO室 SREチーム所属 (2022/5⼊社） Kubernetesアップグレードに失敗しない漢 を⽬指している 趣味：ヨガ 直近の登壇： SRE NEXT 2023 「エンタープライズ企業でのSRE⽴ち上げ挑戦の際に 意識した事と気付き、現在地とこれから」 CloudNative Days Tokyo 2023 「イオンがKubernetesを採⽤してどうなった？」

会社紹介

会社紹介

会社紹介

iAEONアプリについて 膨⼤なIDと購買データを集約したアプリ「iAEON」 iAEONはイオングループが提供する決済機能やポイントプログラムを1つにまとめたアプリです。 イオングループ内の多数の事業会社がもつ顧客IDを⼀つのアプリに統合しています。 提供開始から約3年で、iAEONは500万⼈以上の会員を抱え、独⾃のコード決済サービス「イオンペイ」は836万⼈（23年5⽉時点）が利⽤しています。

Agenda • AKSアップグレード戦略 • 改善ジャーニー • AKSアップグレードの練度を⾼めていくために⼤切なこと

AKSアップグレード戦略

kubernetesの規模 4clusters 100+ deployments 500+ pods 5developer teams

基本的なアップグレード戦略（バージョン） • minorバージョン(x.y.zのy)のn-2 がサポート対象 o つまり約半年に1回アップグレードを実施している o ASTは有史以来アップグレードを継続して実施してきた（えらい） • 現在は、1.27で稼働中 • ※AKSとkubernetesのバージョンの サポート期間は⼀致していないことに注意 原則的にMicorsoft社の推奨に従う。 Azure Kubernetes Service (AKS) でサポートされている Kubernetes のバージョン

基本的なアップグレード戦略（バージョン） • patch(x.y.zのz)のアップグレードも原則実施 o ここは⾃動アップグレード(aksManagedAutoUpgradeSchedule: patch) • Long Term Supportを利⽤しているか？ https://learn.microsoft.com/ja-jp/azure/aks/long-term-support o 利⽤しない⽅針 o ツール(observabilityツールなど）への影響を考えたくない o 1回のアップグレードでの差分が⼤きくなるのでリスクが⼤きくなる o 普通に新機能を使いたい

アップグレードの実施⽅法（流れ） (1) バージョン差分の事前確認 • ChangLogにて、API廃⽌などを確認 • https://github.com/Azure/AKS/blob/master/CHANGELOG.md • zennでAKSのリリースノートが翻訳されているのでcatch upするのもオススメ • https://zenn.dev/08thse/books/aks-release-notes (2) テスト環境やステージング環境で動作確認 • ⼀通りの動作確認 (3) 本番切替 • 原則⽇中帯に実施

• ⼀般的に、in-placeとblue/greenの2つの⽅式がある。 o in-place § 同⼀クラスタ内でRolling Upgradeをする § ノードの作成、削除が発⽣する。その際にpodなどがdrainされる。 o blue/green § 新しいバージョンのクラスタを 作成しトラフィックを切り替え アップグレードの実施⽅法（切替） https://learn.microsoft.com/ja-jp/azure/architecture/guide/aks/blue-green-deployment-for-aks

• ASTでは、クラスタによって実施⽅法を分けている。 in-placeとblue/greenの選択するための⽐較軸 アップグレードの実施⽅法（切替） ⽅式 In-place blue/green 作業コスト ○ ×（クラスタの構築、トラフィック切替の準備） 切替時間 △（アプリケーションの起動時間や クラスタの設定次第） ○（当⽇切り替えるだけ。重みづけルー ティングの場合は設定次第だが、in- placeよりは短いのでは） Rollbackの可否 × ○ 切り替えの制約 ×（1バージョンずつ） ○ 作業時の サービス影響 △（drain時に一時的にキャパシティが 落ちる） ○

改善ジャーニー

いろんな失敗を経て今に⾄る • Blue/greenで古いクラスタからアプリを削除せず停⽌ →何かの拍⼦で起動した際に、アプリケーションも起動して障害に😇 • デフォルトで1台ずつsurgeするためnodeの台数が多いと時間が⾮常にかかる。 • pdbの設定がされていないのでエラーポコポコ • 設定したpdbが邪魔をしてアップグレード進まない • graceful shutdownしていないのでエラーポコポコ • 使われていないアプリケーションが放置されているため起動せず、アップグレード失敗 • patchバージョン？固定でしょ • アプリのFrameworkが古いままAKSアップグレードしたらリソース使⽤量爆増

アップグレードを安⼼し、⾃信を持って実施するための準備 Cluster/pod設定 • max surge sizeの設定 (ノード サージ アップグレードのカスタマイズ) o Microsoftの推奨は33%だが、慎重めに10%で設定。今後徐々に上げていきたい o ポータルからは設定できないので⾒落としがち。ASTではTerraformで設定 • pdbの設定 o maxUnavailable:10%で設定 • graceful shutdown/prestop hookの設定

アップグレードを安⼼し、⾃信を持ってやるための準備 patchバージョンの⾃動アップグレード設定 • 「aksManagedClusterAutoUpgradeSchedule」の設定⽅針 o 失敗、異常時に検知‧リカバリ対応を早くするため、平⽇⽇中帯に設定 o 1⽇のピーク時間を避ける。 o 繁忙⽇‧繁忙曜⽇を避ける https://learn.microsoft.com/ja-jp/azure/aks/planned-maintenance

アップグレードを安⼼し、⾃信を持ってやるための準備 patchバージョンの⾃動アップグレード設定の注意点 • 細かい拒否設定ができない • 最低4hの枠を設定しなければならない。 • 設定した枠の間にメンテナンスが完了するわけではなく、その枠のどこかでアップグレー ドが開始される • 事前のメンテナンス通知はない。 • ベストエフォートのため、緊急で適⽤されてしまう可能性はあり。 https://learn.microsoft.com/ja-jp/azure/aks/planned-maintenance

AKSアップグレードの練度を⾼めていくために⼤切なこと

AKSのアップグレードは本当に⼤変なのか？ • オペレーション⾃体は⼤したことない o AKSというマネージドサービスの恩恵 • ⼤変だと思ったり、リスクを恐れるのは本当にアップグレードに対してなのか？ 必要なのは‧‧‧ • 焦らず練度を上げていく • 練度を上げていくには JUST DO IT

AKS運⽤の練度を上げていくために‧‧‧ 安⼼して失敗できる状況を作ることが⼤切 • 失敗、問題を検知できること o observabilityの向上 • 失敗時のリカバリ o クラスタをいつでもIaCで作り直せる⼤⼈の余裕 o アプリケーションをCI/CDパイプラインでいつでもデプロイし直せる⼤⼈の余裕 o 追加ツールをCI/CDパイプラインでいつでもデプロイし直せる⼤⼈の余裕 ⼤切なことは、普段の運⽤のブラッシュアップと重なることが多い

AKS運⽤の練度を上げていくために‧‧‧ 安⼼して失敗できる状況を作ることが⼤切 • Azure Kubernetes Services のトラブルシューティング に関するドキュメント • AKSのアップグレードのリトライ⽅法を把握しておく o ポータルからはリトライできないので初めて遭遇すると焦る。 • リトライコマンド（原因を解決させた上で実⾏） ※SR起票しようとすると、このコマンドを提案された。この体験は👍

まとめ

• Microsoftの推奨を参考に、実践を積み重ねる。 • 怖くないと⾔いつつも、kubernetesは難しい。ただ、触らないともっとリスクが⼤きく なる。 • ブラッシュアップするためには、実はAKSそのものよりも周辺の整備の⽅が⼤事 o IaC, CI/CDパイプライン, observability AKSのアップグレードは怖くない

告知

告知 https://aeon.connpass.com/event/310105/

募集しています！