Tweet
Tweet

Slide 1

Slide 1 text

イオンがKubernetesを採⽤してどうなった？ イオンスマートテクノロジー株式会社

Slide 2

Slide 2 text

This session is sponsored by

Slide 3

Slide 3 text

New Relic

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

• イオンのデジタルシフト戦略を担う会社の位置付けで2020年10⽉に設⽴ • お客様のお買い物体験向上と店舗DXを進める

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Agenda • イオンとKubernetesの歴史 • Kubernetes環境とオブザーバビリティの改善 • 今後の改善とチャレンジ

Slide 8

Slide 8 text

イオンとKubernetesの歴史

Slide 9

Slide 9 text

Kubernetes 今の時代、内製でマイクロサービスで開発が主流だ。 Kubernetesで開発だ！ わかりました。 (Kubernetes...聞いたことはあるけどやったことないぞ...) 2020/10 設立 AKSを採用し開発開始 2021/8 iAEONアプリ ローンチ 2022/5 齋藤入社 2023/8 香西入社 NOW 🔥🔥🔥🔥 🎉 🔥🔥🔥 🔥🔥 🔥

Slide 10

Slide 10 text

Kubernetes • 何やかんやで無事にローンチ • 様々なアンチパターンが内在するも、ユーザがまだ少ないので顕在化していない状況 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 🔥🔥🔥🔥 🎉 🔥🔥🔥 🔥🔥 🔥 Kubernetes

Slide 12

Slide 12 text

Kubernetes 改善やっていき開始〜今まで • ユーザの増加に伴い、顕在化するトラブルと戦う⽇々 • 運⽤課題を⼀つ⼀つ解消していくことに注⼒し、改善を進めている（現在進⾏形） 2020/10 設立 AKSを採用し開発開始 2021/8 iAEONアプリ ローンチ 2022/5 齋藤入社 2023/8 香西入社 NOW 🔥🔥🔥🔥 🎉 🔥🔥🔥 🔥🔥 🔥

Slide 13

Slide 13 text

Kubernetes 4clusters 100+ deployments 500+ pods 5developer teams

Slide 14

Slide 14 text

Kubernetes • 学習コスト • 有識者の不⾜ • 運⽤で直⾯する課題 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は内部的にはkubectl applyなので、リソース削除には対応できていない • クラスタ全体としては宣⾔型になっていない。 • 既存のものから引っ張り出したmanifest fileなのでtemplate化できていない

Slide 19

Slide 19 text

• 学習コスト • 有識者の不⾜ • 運⽤で直⾯する課題 o 定期的なアップグレード o リソースやスケール設定 o モニタリング/オブザーバビリティ 組織的課題 技術的課題 • 組織体制、プロセス、フローは利点 を活かせるようになっているのか？ • 銀の弾丸だと思っている謎の勢⼒ o 瞬間⾵速に耐える o 無限のスケーラビリティ

Slide 20

Slide 20 text

Kubernetes

Slide 21

Slide 21 text

Kubernetes • 対象コンポーネント/リソースの多さ • 刻⼀刻と変わる状況 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

New Relic

Slide 24

Slide 24 text

New Relic オブザーバビリティの向上、組織⽂化変⾰の⼀端に寄与 • 分散トレーシングにより、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

Secret • 定期的なローテーション • ユーザー毎の細かな権限管理 • 監査や暗号化 • ハードコーディング

Slide 29

Slide 29 text

Secret • HCP Vault • Kubernetes Secret HCP Vault • PoC

Slide 30

Slide 30 text

• DBのシャーディングによる開発、運⽤のツラミ • マイクロサービス導⼊による組織課題へのソリューションとしてのTiDB TiDB Microservice A Microservice B Microservice C Microservice A Microservice B Microservice C

Slide 31

Slide 31 text

Platform Engineering • 弊社のSREチームはPlatformerとしての側⾯も持ち合わせている • Terraform as a Serviceのような形でセルフサービス化を推進 • 開発チームのTerraform習熟度などにもかなりの差があり課題がある • より開発者が使いやすいPlatformの提供が求められている • 開発チームへ貢献し、信頼を醸成しながらPlatform構築と活⽤を推進していきたい • 引き続き⾜元の⾃動化、効率化を推進しながらゴールデンパスの整理と拡充を実施 • Internal Developer Portalを作成し改善のサイクルを回す

Slide 32

Slide 32 text

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 修正‧改善 要望 ※構想段階のため具体的なアーキテクチャや利⽤サービスは今後要検討

Slide 33

Slide 33 text

Kubernetes

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

We are hiring !! 採⽤情報 AEONテックブログ