イオンがKubernetesを採用してどうなった/What happened when AEON adopted Kubernetes

Cloud Native Days Tokyo 2023発表資料
https://cloudnativedays.jp/cndt2023/talks/2078

Transcript

1. イオンがKubernetesを採⽤してどうなった？ イオンスマートテクノロジー株式会社
2. This session is sponsored by
3. New Relic
4. 2023 8 CTO SRE 2022 5 CTO SRE 様々な事業会社でインフラエンジニア‧SREとしてキャリアを重ねる。 CloudNative Days Tokyoは2022年以来1年ぶりの登壇。昨年はAWSネタ で登壇し、今年はAzureネタ(?)で登壇するチャレンジャー。 Azure、Kubernetes（マジで）何もわからん。 SIer2社を経た後、事業会社でインフラ/運⽤部⾨責任者やプロダクトマ ネージャーを経験した後、現職でSREチームの⽴ち上げ業務に挑戦中。 CloudNative Days Tokyoは2019年以来4年ぶりの登壇。本業は猫の下僕。 @Tocyuki @hikkie13
5. • イオンのデジタルシフト戦略を担う会社の位置付けで2020年10⽉に設⽴ • お客様のお買い物体験向上と店舗DXを進める
6. iAEON 膨⼤なIDと購買データを集約したアプリ「iAEON」 iAEONはイオングループが提供する決済機能やポイントプログラムを1つにまとめたアプリです。 イオングループ内の多数の事業会社がもつ顧客IDを⼀つのアプリに統合しています。 提供開始から約3年で、iAEONは500万⼈以上の会員を抱え、独⾃のコード決済サービス「イオンペイ」は836万⼈（23年5⽉時点）が利⽤しています。
7. Agenda • イオンとKubernetesの歴史 • Kubernetes環境とオブザーバビリティの改善 • 今後の改善とチャレンジ
8. イオンとKubernetesの歴史
9. Kubernetes 今の時代、内製でマイクロサービスで開発が主流だ。 Kubernetesで開発だ！ わかりました。 (Kubernetes...聞いたことはあるけどやったことないぞ...) 2020/10 設立 AKSを採用し開発開始 2021/8 iAEONアプリ ローンチ 2022/5 齋藤入社 2023/8 香西入社 NOW 🔥🔥🔥🔥 🎉 🔥🔥🔥 🔥🔥 🔥
10. Kubernetes • 何やかんやで無事にローンチ • 様々なアンチパターンが内在するも、ユーザがまだ少ないので顕在化していない状況 2020/10 設立 AKSを採用し開発開始 2021/8 iAEONアプリ ローンチ 2022/5 齋藤入社 2023/8 香西入社 NOW 🔥🔥🔥🔥 🎉 🔥🔥🔥 🔥🔥 🔥
11. ⾃分の状況とか⼊社動機 • CKA/CKAD/CKSを持っていたが、商⽤経験はない • kubernetes/websiteの翻訳contributeを細々やっていた時期も • SREチーム⽴ち上げやKubernetesができることに惹かれて⼊社 • 改善やっていき開始🔥 2020/10 設立 AKSを採用し開発開始 2021/8 iAEONアプリ ローンチ 2022/5 齋藤入社 2023/8 香西入社 NOW 🔥🔥🔥🔥 🎉 🔥🔥🔥 🔥🔥 🔥 Kubernetes
12. Kubernetes 改善やっていき開始〜今まで • ユーザの増加に伴い、顕在化するトラブルと戦う⽇々 • 運⽤課題を⼀つ⼀つ解消していくことに注⼒し、改善を進めている（現在進⾏形） 2020/10 設立 AKSを採用し開発開始 2021/8 iAEONアプリ ローンチ 2022/5 齋藤入社 2023/8 香西入社 NOW 🔥🔥🔥🔥 🎉 🔥🔥🔥 🔥🔥 🔥
13. Kubernetes 4clusters 100+ deployments 500+ pods 5developer teams
14. Kubernetes • 学習コスト • 有識者の不⾜ • 運⽤で直⾯する課題 o 定期的なアップグレード o リソースやスケール設定 o モニタリング/オブザーバビリティ 組織的課題 技術的課題 • 組織体制、プロセス、フローは利点を 活かせるようになっているのか？ • 銀の弾丸だと思っている謎の勢⼒ o 瞬間⾵速に耐える o 無限のスケーラビリティ
15. • そもそもmanifest fileが構成管理されていないのだが？ • kubectlによる温かみのあるリリース作業。もちろんExcel⼿順書もあった。 • latestタグ • requests/limits設定 • OOM Killed多発 → 開発チーム「再起動するんで⼤丈夫っス」 ⼀⽅で... • 定期的アップグレードはちゃんとやっている（偉い） • マネージドサービスの選択により、運⽤負荷をある程度軽減できている
17. • 実機に⼊ってmanifest file化 • おかしい設定は開発チームに「なぜダメなのか？」を説明しながら⼀つ⼀つ改善 • 温かみのある⼿動作業はSREチームでパイプライン化して提供して撲滅 o Azure Pipelinesを利⽤ o CIにおいて、TrivyによるセキュリティチェックやLinterCheckなどを実装
18. Container Build Container Security Test Linter Check Diff k8s manifest Diff k8s manifest deploy Check after deploy Developer 課題： • deployは内部的にはkubectl applyなので、リソース削除には対応できていない • クラスタ全体としては宣⾔型になっていない。 • 既存のものから引っ張り出したmanifest fileなのでtemplate化できていない
19. • 学習コスト • 有識者の不⾜ • 運⽤で直⾯する課題 o 定期的なアップグレード o リソースやスケール設定 o モニタリング/オブザーバビリティ 組織的課題 技術的課題 • 組織体制、プロセス、フローは利点 を活かせるようになっているのか？ • 銀の弾丸だと思っている謎の勢⼒ o 瞬間⾵速に耐える o 無限のスケーラビリティ
20. Kubernetes
21. Kubernetes • 対象コンポーネント/リソースの多さ • 刻⼀刻と変わる状況 o Podのノード移動、スケールアウト/スケールイン • 障害発⽣時の調査の難しさ • アプリケーション/インフラリソースの監視と組み合わせて観たい • クラスタの状況やPod全体の状況を俯瞰的に観たい
22. • 作るより買うことを選択 o コストはかかる（observabilityは⾼い）が、よりビジネスに寄与するところにリソースを 集中したい • ユーザに近いところから⼀気通貫で観測したい o 1つのプラットフォームで全てを⾒る o "looking for a needle in a hay stack（⼲し草の⼭から針を⾒つける）"の実現
23. New Relic
24. New Relic オブザーバビリティの向上、組織⽂化変⾰の⼀端に寄与 • 分散トレーシングにより、mobile〜backend application〜infrastructureまで⼀気通貫 でトレース可能に。 o 障害調査の短縮化 o アプリケーションの可視化 • 運⽤のオーナシップを開発チームに意識させるトリガーに o 定点観測会の実施やトレーニング開催など働きかけは必要
26. • 内部的にはkubectl applyを実⾏しているだけなのでリソース削除等に対応できていない • 肥⼤化するマニフェストファイルや管理⼿法と設計の共通化に課題 肥⼤化するマニフェストファイル ⼿続き的なデプロイ マニフェストの変更やレビューﾂﾗｲ
27. • GitOpsの思想に基づいたArgoCDなどを導⼊し、宣⾔的なデリバリー⼿法へ • HelmやKustomize導⼊によるマニフェスト管理の改善と設計の共通化 or GitOpsによる宣⾔的なデリバリー CI 効率的で柔軟なマニフェスト管理ができる！
28. Secret • 定期的なローテーション • ユーザー毎の細かな権限管理 • 監査や暗号化 • ハードコーディング
29. Secret • HCP Vault • Kubernetes Secret HCP Vault • PoC
30. • DBのシャーディングによる開発、運⽤のツラミ • マイクロサービス導⼊による組織課題へのソリューションとしてのTiDB TiDB Microservice A Microservice B Microservice C Microservice A Microservice B Microservice C
31. Platform Engineering • 弊社のSREチームはPlatformerとしての側⾯も持ち合わせている • Terraform as a Serviceのような形でセルフサービス化を推進 • 開発チームのTerraform習熟度などにもかなりの差があり課題がある • より開発者が使いやすいPlatformの提供が求められている • 開発チームへ貢献し、信頼を醸成しながらPlatform構築と活⽤を推進していきたい • 引き続き⾜元の⾃動化、効率化を推進しながらゴールデンパスの整理と拡充を実施 • Internal Developer Portalを作成し改善のサイクルを回す
32. Platform Engineering Internal Developer Portal Software catalog API catalog Dashboard Knowledge Observerbillity Internal Developer Portal Other System Service Platform Developer Platform Operation Platform 要求 提供 開発者 Platform Platform Team 修正‧改善 要望 ※構想段階のため具体的なアーキテクチャや利⽤サービスは今後要検討
33. Kubernetes
34. 改善の途中だが、後から振り返って正解だったと⾔えるように頑張ります。 • 現実的に、技術にbetしてから組織が追いつくしかない。 o betが失敗しないような努⼒は必要（経営‧現場両⾯で） o 失敗を経験しながら触っていかないとわからない。失敗の許容はDXの⽂脈でも技術の ⽂脈でも必要。 § リスクを下げるために、本来は⼩さいところから始めるべきだったかも。 • ツール/技術に合わせて組織を変えていくことが、組織⽂化の変⾰に繋がる
35. 結局どうなった？② • 当たり前だが、Kubernetesは銀の弾丸ではない • 現状Kubernetes導⼊による恩恵よりも課題の⽅が多い状況 • しかしKubernetesをはじめとしたCloud Native技術の導⼊や取り組みはゆっくりだが 確実に組織へ変⾰をもたらしている • 素晴らしい技術を扱えるようになりたいというモチベーションは⼤事 • 弊社も道半ばだが、Cloud Nativeな技術スタックを中⼼に添え、よりレベルの⾼いSRE やPlatform Engineeringへのチャレンジをしていきたい
36. We are hiring !! 採⽤情報 AEONテックブログ