[CNDT2023]イオンがKubernetesを採用してどうなった?

CloudNativeDays Tokyo 2023のキーノートセッションです。
https://cloudnativedays.jp/cndt2023/talks/2078

Transcript

1. イオンがKubernetesを採用してどうなった？ イオンスマートテクノロジー株式会社
4. 様々な事業会社でインフラエンジニア・SREとしてキャリアを重ねる。 CloudNative Days Tokyoは2022年以来1年ぶりの登壇。昨年はAWSネタで 登壇し、今年はAzureネタ(?)で登壇するチャレンジャー。 Azure、Kubernetes（マジで）何もわからん。 SIer2社を経た後、事業会社でインフラ/運用部門責任者やプロダクトマ ネージャーを経験した後、現職でSREチームの立ち上げ業務に挑戦中。 CloudNative Days Tokyoは2019年以来4年ぶりの登壇。本業は猫の下僕。 @Tocyuki @hikkie13
5. • イオンのデジタルシフト戦略を担う会社の位置付けで2020年10月に設立 • お客様のお買い物体験向上と店舗DXを進める
6. 膨大なIDと購買データを集約したアプリ「iAEON」 iAEONはイオングループが提供する決済機能やポイントプログラムを1つにまとめたアプリです。 イオングループ内の多数の事業会社がもつ顧客IDを一つのアプリに統合しています。 提供開始から約3年で、iAEONは500万人以上の会員を抱え、独自のコード決済サービス「イオンペイ」は836万人（23年5月時点）が利用しています。
7. • イオンとKubernetesの歴史 • Kubernetes環境とオブザーバビリティの改善 • 今後の改善とチャレンジ
8. イオンと の歴史
9. 今の時代、内製でマイクロサービスで開発が主流だ。 Kubernetesで開発だ！ わかりました。 (Kubernetes...聞いたことはあるけどやったことないぞ...) 2020/10 設立 AKSを採用し開発開始 2021/8 iAEONアプリ ローンチ 2022/5 齋藤入社 2023/8 香西入社 NOW
10. • 何やかんやで無事にローンチ • 様々なアンチパターンが内在するも、ユーザがまだ少ないので顕在化していない状況 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
12. 改善やっていき開始〜今まで • ユーザの増加に伴い、顕在化するトラブルと戦う日々 • 運用課題を一つ一つ解消していくことに注力し、改善を進めている（現在進行形） 2020/10 設立 AKSを採用し開発開始 2021/8 iAEONアプリ ローンチ 2022/5 齋藤入社 2023/8 香西入社 NOW
14. • 学習コスト • 有識者の不足 • 運用で直面する課題 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は内部的にはkubectlapplyなので、リソース削除には対応できていない • クラスタ全体としては宣言型になっていない。 • 既存のものから引っ張り出したmanifest fileなのでtemplate化できていない
19. • 学習コスト • 有識者の不足 • 運用で直面する課題 o 定期的なアップグレード o リソースやスケール設定 o モニタリング/オブザーバビリティ 組織的課題 技術的課題 • 組織体制、プロセス、フローは利点 を活かせるようになっているのか？ • 銀の弾丸だと思っている謎の勢力 o 瞬間風速に耐える o 無限のスケーラビリティ
21. • 対象コンポーネント/リソースの多さ • 刻一刻と変わる状況 o Podのノード移動、スケールアウト/スケールイン • 障害発生時の調査の難しさ • アプリケーション/インフラリソースの監視と組み合わせて観たい • クラスタの状況やPod全体の状況を俯瞰的に観たい
22. • 作るより買うことを選択 o コストはかかる（observabilityは高い）が、よりビジネスに寄与するところにリソースを集 中したい • ユーザに近いところから一気通貫で観測したい o 1つのプラットフォームで全てを見る o "looking for a needle in a hay stack（干し草の山から針を見つける）"の実現
24. オブザーバビリティの向上、組織文化変革の一端に寄与 • 分散トレーシングにより、mobile〜backend application〜infrastructureまで一気通貫でト レース可能に。 o 障害調査の短縮化 o アプリケーションの可視化 • 運用のオーナシップを開発チームに意識させるトリガーに o 定点観測会の実施やトレーニング開催など働きかけは必要
26. • 内部的にはkubectl applyを実行しているだけなのでリソース削除等に対応できていない • 肥大化するマニフェストファイルや管理手法と設計の共通化に課題 肥大化するマニフェストファイル 手続き的なデプロイ マニフェストの変更やレビューﾂﾗｲ
27. • GitOpsの思想に基づいたArgoCDなどを導入し、宣言的なデリバリー手法へ • HelmやKustomize導入によるマニフェスト管理の改善と設計の共通化 or GitOpsによる宣言的なデリバリー CI 効率的で柔軟なマニフェスト管理ができる！
28. • 定期的なローテーション • ユーザー毎の細かな権限管理 • 監査や暗号化 • ハードコーディング
29. • • •
30. • DBのシャーディングによる開発、運用のツラミ • マイクロサービス導入による組織課題へのソリューションとしてのTiDB Microservice A Microservice B Microservice C Microservice A Microservice B Microservice C
31. • 弊社のSREチームはPlatformerとしての側面も持ち合わせている • Terraform as a Serviceのような形でセルフサービス化を推進 • 開発チームのTerraform習熟度などにもかなりの差があり課題がある • より開発者が使いやすいPlatformの提供が求められている • 開発チームへ貢献し、信頼を醸成しながらPlatform構築と活用を推進していきたい • 引き続き足元の自動化、効率化を推進しながらゴールデンパスの整理と拡充を実施 • Internal Developer Portalを作成し改善のサイクルを回す
32. Internal Developer Portal Software catalog API catalog Dashboard Knowledge Observerbillity Internal Developer Portal Other System Service Platform Developer Platform Operation Platform 要求 提供 開発者 Platform Platform Team 修正・改善 要望 ※構想段階のため具体的なアーキテクチャや利用サービスは今後要検討
34. 改善の途中だが、後から振り返って正解だったと言えるように頑張ります。 • 現実的に、技術にbetしてから組織が追いつくしかない。 o betが失敗しないような努力は必要（経営・現場両面で） o 失敗を経験しながら触っていかないとわからない。失敗の許容はDXの文脈でも技術の 文脈でも必要。 ▪ リスクを下げるために、本来は小さいところから始めるべきだったかも。 • ツール/技術に合わせて組織を変えていくことが、組織文化の変革に繋がる
35. 結局どうなった？② • 当たり前だが、Kubernetesは銀の弾丸ではない • 現状Kubernetes導入による恩恵よりも課題の方が多い状況 • しかしKubernetesをはじめとしたCloud Native技術の導入や取り組みはゆっくりだが確 実に組織へ変革をもたらしている • 素晴らしい技術を扱えるようになりたいというモチベーションは大事 • 弊社も道半ばだが、Cloud Nativeな技術スタックを中心に添え、よりレベルの高いSREや Platform Engineeringへのチャレンジをしていきたい
36. 採用情報 AEONテックブログ