イオンが失敗の経験から行き着いたAKSアップグレードの実施方法 | AEON TECH HUB開催レポート Session#3

イオンが失敗の経験から行き着いたAKSアップグレードの実施方法 | AEON TECH HUB開催レポート Session#3

2024/3/26

Share

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

齋藤 光

Hikaru Saito

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

    イオンにおける技術(テック)の中継地(ハブ)を目指す「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#2:エーピーコミュニケーションズ 吉川 俊甫さんの記事はこちら
    https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-22

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

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

    【目次】

    Session#3 イオンスマートテクノロジーで実践しているAKSアップグレード戦略

    イオンスマートテクノロジー株式会社
    CTO室SREチーム
    齋藤 光

    齋藤のセッション全体の資料と本文はこちら

    2020年10月に設立したイオンスマートテクノロジーは、お客さまの買い物体験向上と店舗DXを進めるイオンのデジタルシフト戦略を担う会社です。

    主なプロダクトとしては、イオングループ内の多数の事業会社が持つ顧客IDと購買データを集約したアプリ「iAEON」を開発しています。私は2022年5月に同社へ入社し、SREチームの立ち上げに関わってきました。

    AKSのアップグレードではMicrosoft社の推奨に従うことを重要視している

    それではまず、AKSのアップグレード戦略についてお話します。弊社が運営しているKubernetesの規模は図のようになります。アップグレード戦略のバージョンについて、原則的にマネージドサービスを提供いただいているMicrosoft社の推奨に従うことを重要視しています。

    マイナーバージョン(x.y.zのy)のn-2がサポート対象であり、必然的に約半年に1回アップグレードを実施している状況で、現在はv1.27で稼働中です。改善の結果として、最近はpatch(x.y.zのz)のアップグレードも実施しています。ここは自動アップグレードを採用しています。

    最近Long Term Supportの提供が開始されましたが、オブザーバビリティツールなどへの影響を考える必要があること、Long Term Supportを利用すると1回のアップグレードでの差分も大きくなるなどの理由でLong Term Supportは利用しない予定です。また、新バージョンが出てくれば新機能も追加されていくため、わざわざバージョンを固定してLong Term Supportを採用すると、そのメリットを享受できないと考えています。

    色々な失敗を経験し、“ツラミ”を乗り越えた先に見出したアップグレードの実施方法

    アップグレードの実施方法を説明します。基本的には「当たり前のことを、当たり前にやる」のをスタンスに据えており、検証環境で試す前にまずはバージョン差分の事前確認を行います。

    一番しっかりとやらなくてはならないのは、ChangeLogにてAPI廃止などがないかチェックすることです。AKSの情報が一元化されているGitHubをチェックしたり、Zennで公開されているMicrosoft MVPの方が翻訳したAKSのリリースノートを見たりして、普段からキャッチアップしておくのがおすすめです。

    その後、テスト環境やステージング環境で動作確認し、最終的に本番環境で切り替えを実施していきます。切り替えに際しては、インプレース型とBlue/Green型の2つの方式があり、イオンスマートテクノロジーはクラスタによって両方をうまく使い分けています。会社が立ち上がった当初は、基本的にBlue/Green方式を前提とした切り替えを考えていました。

    ですが、作業コストやリスクコントールの観点でインプレース型を一部で採用しています。インプレース型とBlue/Green型にはそれぞれメリット・デメリットがあるわけですが、主な比較軸としては図のようになります。

    しかし、SREチームによるオペレーション改善以前では、色々な失敗も経験したりと、さまざまな改善を繰り返してきました。お恥ずかしい話ですが、Blue/Greenでの切り替えを行う際に、古いクラスタからアプリを削除せずに停止したことで、意図せず古いクラスタ起動した際に、古いバージョンおアプリケーションが起動してしまい障害の原因になったこともありました。

    また、デフォルトで1台ずつサージするため、Nodeが20台、30台と増えてくると非常に時間がかかってしまったり、PDB(Pod Disruption Budget)の設定がなされていないためにエラーが多発したり。そのほかにもグレースフルシャットダウンをしていなかったためにエラーが出たことや、使われていないアプリケーションがアップグレードを阻害するなど、数えきれないほどの苦労を経験し改善を積み重ねてきました。こうした課題を乗り越えるために、自信を持ってアップグレードを実施するための準備を愚直にやってきました。

    最大サージ数の設定に関しては、Microsoftの推奨は33%でしたが、最初は安全性を考慮して10%に設定し、今後は徐々に上げていければと考えています。イオンスマートテクノロジーではTerraformで設定していますが、最大サージ数の設定はポータルからは設定できずに見逃しがちなので、注意が必要です。また、PDBについてはmaxUnavailable:10%で設定しており、Podが安全に停止するようにグレースフルシャットダウンやpreStopフックの設定も行っています。

    「アップグレードを安心し、自信を持って実施するための準備」

    Cluster/Pod設定
    ・max surge sizeの設定(ノード サージ アップグレードのカスタマイズ)
     ・Microsoftの推奨は33%だが、慎重めに10%で設定。今後徐々に上げていきたい
     ・ポータルからは設定できないので見落としがち。ASTではTerraformで設定
    ・pdbの設定
     ・maxUnavailable:10%で設定
    ・graceful shutdown/prestop hookの設定

    弊社ではアップグレードの失敗や異常時の検知、リカバリー対応を早くするため、平日日中帯に設定していますが、1日のピーク時間や繁忙日を避けるように意識しています。

    一方で、パッチバージョンの自動アップグレード設定の注意点もいくつかあります。細かい拒否設定ができない、最低4hの枠を設定する必要があるといった一定の制約があるほか、設定した枠の間にメンテナンスが完了するのではなく、その枠のどこかで、事前の通知なくアップデートが開始されることを理解しておかなければなりません。

    イオンのような小売業界ではお買い物が盛んとなるお昼と夕方がピークの時間帯です。最低4hの枠だと厳しい部分がありますが、メンテナンスのスケジュールは条件を満たすように毎月特定の曜日の午前中をに設定しています。AKSというマネージドサービスの恩恵があるからこそ、アップデートのオペレーション自体はそこまで大変ではないものだと感じています。それでも、AKSのアップデートに対してリスクを恐れたりトラウマを抱えたりする方もいるわけですが、そこに立ち向かっていくためには、焦らずに練度を高めていくことが何より大切になります。

    「AKSのアップデートは怖くない」。練度を高めるために失敗時のリカバリも考えておく

    練度を上げていくには、安心して失敗できる状況を作ることが大事です。そのために、まずはオブザーバビリティを向上させ、失敗、問題を検知できるような体制を作るようにしましょう。

    また、失敗時のリカバリも考えておくことです。クラスタをいつでもIaCで作り直せる、アプリケーションや追加ツールをCI/CDパイプラインでいつでもデプロイし直せる準備をし、“大人の余裕”を持って対応していくことが肝になるでしょう。

    さらに付け加えるならば、Azure Kubernetes Serviceのトラブルシューティングに関するドキュメントをチェックすること、AKSのアップグレードのリトライ方法を把握しておくこともおすすめです。最も強調して言いたいこととして、AKSのアップデートのために何か特別に頑張るというよりも、大切なことは普段の運用のブラッシュアップと重なることが多く、そちらを頑張る意識を持つことが大切だということです。それは、オブザーバビリティの獲得やIaC化などです。

    最後にまとめると、「AKSのアップデートは怖くない」ということです。

    Microsoftの推奨を参考に、実践を積み重ねていくことが何よりも必要です。もちろん、Kubernetesは難しい部分もありますが、だからと言って触らないともっとリスクが大きくなってしまいます。ブラッシュアップするためには、AKSそのものよりもIaCやCI/CDパイプライン、オブザーバビリティツールなど、SREやPlatform Enginneringの文脈で、周辺の整備の方が大事だと言えるでしょう。


    イオンが主催する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#2:エーピーコミュニケーションズ 吉川 俊甫さんの記事はこちら
    https://engineer-recuruiting.aeon.info/aeon-tech-hub/event-reportATH-22

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

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

    ※掲載している所属・役職・肩書きおよび各種情報は、記事公開時点のものです。

    Share

    JOIN US

    AEONで働きたい人は、採用サイトもチェック

    カジュアル
    面談

    に申し込む