Kubernetesの導入と運用で「組織変革」を促進。クラウドネイティブ時代に向けたイオンスマートテクノロジーの取り組み

Kubernetesの導入と運用で「組織変革」を促進。クラウドネイティブ時代に向けたイオンスマートテクノロジーの取り組み

2024/1/30

Share

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

齋藤 光

Hikaru Saito

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

クラウド技術を最大限活用し、柔軟かつスケーラブルな開発アプローチの指針となる「クラウドネイティブ」。DXが叫ばれる近年では、多くの開発組織がクラウドネイティブ化に取り組んでおり、イオンスマートテクノロジーでもクラウドインフラにAzure、コンテナ基盤にAzure Kubernetes Serviceを採用しています。

しかし、Kubernetesやパブリッククラウドを採用すれば、クラウドネイティブの実現に結びつくわけではないため、さまざまな課題に直面する企業は少なくありません。

クラウドネイティブ時代に合わせ、イオンスマートテクノロジーはどのように組織変革に挑んでいるのか。Kubernetesの運用を開始してから顕在化した幾多の課題を、どのように対処してきたのか。

イオンスマートテクノロジー CTO室SREチーム所属の香西俊幸と齋藤光が、国内最大級のテックカンファレンス「CloudNative Days Tokyo 2023」に登壇し、Kubernetesをはじめとしたクラウドネイティブ技術の導入背景や、目指す開発組織のあり方について語りました。

※本記事はイベント登壇内容を書き起こしたものです

▼イベント詳細ページ(動画もご覧いただけます)

2023年12月11・12日開催 CloudNative Days Tokyo 2023

【目次】

開発の内製化やマイクロサービス化を図るためにKubernetesを採用

香西:イオンスマートテクノロジー(以下、AST)は、イオンのデジタルシフト戦略を担う会社として2020年10月に設立されました。

グループ全体のビジネスをテクノロジーの力で進化させ、お客さまのお買い物体験の向上と店舗DXを進めるために日々尽力しています。

弊社の主要なプロダクトのひとつである「iAEON」は、膨大な顧客IDと購買データを集約したアプリで、イオングループが提供するコード決済や電子マネーといった決済機能や、ポイントプログラムを1つにまとめたサービスとなっています。

提供開始から約3年で、iAEONの登録ユーザー数は500万人を超え、さらに独自のコード決済サービス「イオンペイ」は、2023年5月末時点で836万人の利用者を誇っています。

齋藤:私からは、なぜイオンがKubernetesを採用したのか。その理由や背景についてお話していきたいと思います。

2020年10月にAzure Kubernetes Service (AKS)を導入し、iAEONの開発をスタートしました。内製化によるマイクロサービス開発が主流の時代に、Kubernetesを採用した方が適切だと判断し、現場の開発者もキャッチアップしながらアプリ開発を進めていきました。

そして、 2021年8月にiAEONをローンチできたのですが、その時点ではさまざまなアンチパターンが内在していました。ですが、ユーザーがまだ少ない頃だったので、アンチパターンは顕在化されていない状況でした。

齋藤:そんななか、SREチームの立ち上げやKubernetesによる開発の経験ができるという動機から、2022年5月に私がASTへジョインし、iAEONのサービス改善に取り組み始めたのです。

私が入社したタイミングは、ちょうどユーザー数の増加に伴って、リスクが顕在化するトラブルと日々向き合わなければならない時期でした。

運用課題を一つひとつ解消していくことに注力し、現在も継続して改善を進めています。

SREチームが改善に取り組んだ「組織的課題」と「技術的課題」

齋藤:Kubernetes導入時における課題は「組織的課題」と「技術的課題」の2つに大別されます。

最初の頃は、マイクロサービス開発の内製に見合った組織体制や、機能ごとにシステムを細分化していく開発プロセスが整っていなかったのに加え、Kubernetesの適切な扱い方も理解していませんでした。

Kubernetesの有識者も不在だったため、学習コストの増大や運用で直面する課題への対応に苦労しました。

齋藤:私がジョインした当時は、マニフェストファイルが構成管理されておらず、リリース作業もExcel手順書に沿って行っていたくらい、Kubernetesを正しく活用できていなかったのです。

幸いにも定期的なアップグレード対応や、マネージドサービスの選定による運用不可の軽減はなされていたため、ちゃんとKubernetesの運用をマスターすれば、“伸び代しか感じない”ような状況でした。

しかし、改善には泥臭い作業を地道に積み上げていくことが大事になります。

マニフェストファイルを作成するために、実機に入って構成管理するところから始めたり、運用上おかしい設定は開発チームに「なぜダメなのか?」を一つひとつ説明しながら改善したりと、ステップバイステップで進めてきました。

温かみのある手動作業は、SREチームでパイプライン化し提供することで撲滅していったのです。

新しいツールや技術の導入は「組織文化の変革」につながる

齋藤:次に、Kubernetes環境とオブザーバビリティの改善についてご説明します。

まず一般論として、Kubernetesは対象となるコンポーネントやリソースの多さはもとより、さまざまな要因によって刻一刻と状況が変わったり、障害発生時の原因調査が難しかったりと「Kubernetes環境での監視」は難しいとされています。

そうしたなか、ASTでは「作ることより買うこと」を選択しています。

齋藤:特に、立ち上げ間もない会社ゆえにリソースが限られるなか、よりビジネスへ寄与することに集中したいという思いがあったからです。

さらにユーザーに近いところで、モバイルアプリからバックエンドのインフラまでを1つのプラットフォームを使って一気通貫で観測するという方針を掲げたことから、New Relicの導入に至りました。

New Relicの分散トレーシングにより、オブザーバビリティの向上や障害調査の短縮化、アプリケーションの可視化を実現することができました。

一方、New Relicを入れたことで、「障害発生時だけダッシュボードを見ればいい」という意識から、開発チーム自身が「運用のオーナーシップを持つ」という意識変革のトリガーになったのもいい影響だったと感じています。

SREチームとしては、定点観測会の実地やトレーニング開催などのイネーブラー活動を行い、開発チームへの定期的な働きかけを心がけてきました。

Kubernetesを導入し、まだまだ改善の途中ではありますが、後から振り返って正解だったと言えるようにSREチームは日々頑張っています。

やはり先に技術へbetし、後から組織が追いついていくしかないと思っていて、現場のエンジニアリング力でbetが失敗しないような努力が必要不可欠になってきます。

そのなかで、当然ながら失敗も経験するわけですが、失敗の許容はDXや技術の文脈でも大事だと考えています。

何より、KubernetesやNew Relicといった新しいツールや技術の導入に合わせて、開発組織を変えていくことが、ひいては「組織文化の変革」につながっていくと捉えています。

Platform Engineeringを通じて開発者体験の向上を目指す

香西:最後に私から今後の改善とチャレンジについて発表したいと思います。現状としてはKubernetes導入による恩恵よりも課題の方が多い状況です。

内部的にはkubectl applyを実行しているだけなので、リソース削除等に対応が追いついていないのと、肥大化するマニフェストファイルや管理手法と設計の共通化に課題を感じています。

今後の課題解決としては、GitOpsの思想に基づいたArgoCDなどを導入し、宣言的なデリバリー手法へと改善していき、マニフェスト管理や設計の共通化はHelmやKustomizeを導入し改善を図っていく予定です。

加えて、定期的なローテーションやユーザーごとの細かな権限管理、監査や暗号化といったSecret管理の課題も抱えています。

それについては、HCP Vaultの導入によって改善していきつつ、将来的にはKubernetes以外のSecretもHCP Vaultで中央管理できるように適用範囲の拡大も視野に入れています。

Kubernetesをはじめとしたクラウドネイティブ技術の導入や取り組みはまだ道半ばですが、確実に組織変革の兆しが見えてきており、今後はクラウドネイティブな技術スタックを中心に添えて、よりレベルの高いSREやPlatform Engineeringにも挑戦していきたいと考えています。

香西:弊社のSREチームは、「Terraform as a Service」のような形でセルフサービス化を推進しているものの、開発チームのメンバーによってTerraform習熟度に差があり、開発者が使いやすいPlatformが求められている状況です。

引き続き、自動化や効率化を追求しながらPlatformの構築も推進していき、最終的には「 Internal Developer Portal」を作成し、改善サイクルを回せる体制を作れたらと思っています。

Platform Engineeringへの挑戦を通して、ASTがイオングループの店舗DXだけでなく、開発者体験(Developer Experience​​)の向上に寄与できるような会社の立ち位置にしていきたいですね。

ありがとうございました。

今回のイベント登壇資料はこちら

イオンではエンジニアを中心としたデジタル人材の採用に注力しています。今回の記事で、イオンスマートテクノロジーの取り組みやSREチームにご興味を持たれた方は、ぜひカジュアル面談でお話しましょう。お気軽にお申し込みください。

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

Share

JOIN US

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

カジュアル
面談

に申し込む