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