「教科書通りの設計では動かない」巨大組織のクリティカルシステム解体新書-アーキテクチャConference 2024登壇レポート-

イオングループ全体の業務を支える基幹システムのリアーキテクチャにおいては、レガシーシステムからの脱却やクラウドネイティブへの移行、マイクロサービス化の挑戦など、戦略的なアーキテクチャ設計が不可欠な状況でした。巨大流通グループだからこそ、多岐にわたる「クリティカルシステム」をどのように構築し、デジタル変革を進めてきたのか。

2024年11月26日(火) に開催された「アーキテクチャConference 2024」では、イオン株式会社／イオンスマートテクノロジー株式会社CTOの山﨑 賢が登壇し、イオングループの会員システムやPOSシステム、iAEONアプリといった大規模システムのアーキテクチャの変遷や、リアーキテクチャの歴史を語りました。

本記事では、ヤフー出身のEMである株式会社ZINE 取締役CTO 池田 健人氏による解説を交えて、セッションの内容をお届けします。

【目次】

このセッションの見どころ

イオングループという超巨大組織にもかかわらず、“内製”と“技術力”を軸に構造改革を進めようとしているリアルなプロセスが丁寧に語られたセッションだった。ASP/Bのスケーラビリティ対応、iAEONアプリの信頼性向上、可観測性の文化的定着、そして組織体制の再構築。どれも「理想を掲げる」ではなく、「現場で本当に必要だったからやった」重みがある。立場が上がるほど見えにくくなる現場の真実を、CTO自らの言葉で正面から伝えている点に深く共感でき、夢物語ではない地に足のついたDXストーリーを見ることができた。（池田）

Aeon Smart Platform for Business（ASP/B）*

*Aeon Smart Platform for Business（ASP/B）：イオンが扱う様々な業務システムの基盤となるプラットフォーム。EC・ネットスーパー・iAEONアプリ等のイオンが展開するお客さま向けサービスに対しクーポン・注文・在庫・商品などの情報をAPIで提供する仕組み。

見どころ解説

Spring BootとAzureを基盤としたスケーラブルなシステム設計で、550以上のPodを運用する国内トップクラスのAKS環境を構築。さらに、DB分割やTiDB導入による超高速処理の実現や、マイクロサービス細分化によるリファクタリング手法は、ミッションクリティカルなシステムの技術的挑戦として参考になる。

標準的な構成では到底支えきれない、トラフィックとデータ量であるイオン規模におけるスケーラビリティ対応の厳しさが、設計の一つひとつに滲んでいる。DB分割、シャーディング、パーティショニングの話はどれも「もうやりたくない」というエンジニアなら共感できる話もあり、決して他人事ではない共感できる痛みとして響く。
そこからTiDB導入に踏み出す意思決定には、“もう一度やる”ではなく“もっと良い解に踏み込む”勇気を感じた。巨大な既存構造に手を入れ続ける胆力、それを持って技術に挑む姿勢に学ぶことは多い。（池田）

イオングループのデジタルシフト戦略を担うイオンスマートテクノロジーでは、取引総額9兆円のトランザクション量と、カード会員数4,800万人超のユーザーベースを抱えるデータ基盤・会員基盤を構築しています。

会員基盤は個人情報や認証を扱うミッションクリティカルなシステムで、中長期的なシステム開発・運用の観点からシステム全体のリファクタリングおよびアーキテクチャの再設計を推進しています。

イオングループ内のさまざまなアプリケーションが連携する横断基盤のASP/Bは、Azure上に構築されています。イオングループのクラウドインフラにおいて、Azureの活用率が高いのは、次の理由が挙げられます。

• 「小売だからAWSは使わない」という業界の“不文律”があったから

• 日本のPOS／レジの半分以上はWindowsベースのものを使っているから

• エンタープライズ企業はMicrosoftのソリューションを導入しているケースが非常に多いから

現在もイオングループでは、Azureが主な業務基盤として活用されていますが、広告やリテールメディアといった分野ではGoogleが非常に強いため、GCP（Google Cloud Platform）を活用するケースも増えています。また、AWSを導入するなど、過去の前提に捕らわれず、領域ごとに最適なクラウドを選択するアプローチにシフトしています。

大規模システムのアーキテクチャ設計

アプリケーションはJavaのSpring Bootで実装しており、内製のエンジニアチームによってスクラッチで開発されています。OSにはRHEL（Red Hat Enterprise Linux）を採用し、検索とキャッシュにはElasticsearchを広範に利用しているほか、非構造的なデータのキャッシュにもDBを活用しています。

Azure Flexible ServerというMySQLベースで冗長性に優れたAzureのデータベースサービスを用いており、ASP/B全体で50以上のインスタンスが稼働しています。そのため、DB関連の費用だけで年間数億円に上る規模で運用されています。

iAEONなどユーザー向けアプリケーションの機能は、すべてREST APIを通じて提供されており、アプリケーションはAKS（Azure Kubernetes Service）上で稼働しているため、システム全体として非常にスケーラブルな構成になっています。現在稼働中のPod数は550以上、Deploymentsも100以上に上るなど、日本国内のAzure基盤を使ったサービスの中でも、トップ10に入るレベルの大規模な環境だと言えるかもしれません。

アーキテクチャの最上位には、REST APIのエンドポイントとなるAPI Gatewayがあり、Spring Bootで実装されています。ここでは、ゲートウェイ機能や各種ACLや流入を制御する役割を担っています。API Gatewayでリクエストを受け取ると、サービスディスカバリーの仕組みを通じて、中間層であるミドルエンドに処理が渡されます。

ミドルエンドは、主にJava Spring Bootで実装されており、ビジネスロジックの全てがここに記載されています。図では直列に処理が流れるように簡略化していますが、実際には、ミドルエンドの各サービス同士がサービスディスカバリーを通じて連携する処理も存在します。

永続化レイヤーについては、「オーダーDB」「メッセージDB」「マーケティングDB」といったように、各ドメインごとに完全に縦割りで分離した構成になっています。直近では、一部リファクタリングの必要性が出てきているので、今後見直していくことが求められています。

リアーキテクチャの肝になった「DB分割」

はじめは内製化で進めていたのですが、当初の設計通りにはほぼ動きませんでした。イオンという大規模なトラフィックを前提にした場合に、一般的な教科書通りの設計ではデータ処理が全く追いつかないという課題に直面したのです。

そこで、イオン規模のトラフィックとスケールに見合ったアーキテクチャにリビルドする目的で、「Re: Architectプロジェクト」をASP/B領域で立ち上げ、あらためてアーキテクチャを見直し、マイクロサービスのさらなる細分化や実装の最適化に取り組みました。そのなかでも、特に大きな改善がDB分割でした。先ほど触れたように、オーダーDBやプロダクトDBといった単純な区切りだけではなく、実際には数百のテーブルが存在していて、そこにはコードベースでのシャーディングやパーティショニングが施されています。

たとえば、オーダーDBには300近いテーブルがあり、アプリケーション側でユーザーIDや注文IDなどに基づいて、アクセスすべきDBが特定され、その中でシャーディングとパーティショニングが行われる複雑な構成となっています。そこで将来的な再分割を避けるため、MySQLのデータをTiDBに置き換える試験的な取り組みを進めています。検証作業が順調に進めば、2025年度から順次TiDBへの移行を開始する予定です。

iAEON Native App*

*iAEON：イオングループが提供する公式スマートフォンアプリ。決済・ポイント・店舗情報などがひとつになったトータルアプリであり、イオンのDX戦略の要と位置付けられている。

見どころ解説

リリース当初は障害が頻発し、顧客体験を大きく損ねたiAEONアプリ。そこで、社内で「信頼性向上プロジェクト」を立ち上げ、キャッシュ活用や機能単位のサービスレベル分割、最重要機能である会員証と決済の独立稼働により安定運用を実現。その具体的なアプローチが詳細に語られている。

レジ前で“アプリが開かない”というUXリスクに正面から向き合った構成であり、技術的な工夫の連続が体験の質を守るために積み重ねられていた。初期は障害が多発し、そこからキャッシュ前提の構成や機能ごとのサービスレベル分離へと再設計された経緯は、どの現場にも通じる教訓だろう。特に、決済や会員証部分をASPBと切り離してでも“死守する”という割り切り方には、ユーザー体験を第一に置いた設計思想を感じた。技術選定における理屈だけでなく、サービス提供者としての責任感が反映された実装方針が印象的だった。（池田）

イオングループでは、グループ全体のDX戦略の要としてiAEONアプリを位置付けています。2024年9月にローンチから3周年を迎え、ダウンロード数は1,300万を超えました。アプリの顧客向け機能は継続的に拡充しており、レジにて会員証提示と同時にクーポンが自動適用される「自動適用型クーポン」や、キャッシュレス決済機能の「AEON Pay」、株主優待の自動適用機能、ネットスーパー機能、レシートレス機能などを搭載しています。

現在、iAEONアプリはIonicを用いたハイブリッド開発を採用しています。最近ではネイティブ実装への移行の議論も出ていますが、現状はHTMLに近い描画部分はAngularベースのTypeScriptとSCSSで構築されています。

SPAの実現を支えるバックエンド側はC#で実装されており、その裏側にはBFFレイヤーが存在しています。これはASP/B領域の各マイクロサービス（クーポン、店舗情報、ネットスーパーなど）がドメイン単位でAPIを提供しているため、iAEONアプリの画面表示に必要な複数のAPIを効率的に連携・集約させ、高速化を図る役割を果たしています。また、BFFレイヤー内では一部キャッシュ機能も担っています。

プッシュ通知の配信には、フェンリル社が開発したBoltzEngineを導入し、そこからFirebase経由でユーザーに通知を飛ばすアーキテクチャになっています。

今でこそ、iAEONアプリはさまざまな機能が実装され、順調に利用されていますが、リリース当初から2023年の夏頃まではシステム障害が多発しており、社内でも問題視されていました。特にiAEONアプリの主な利用シーンが、会計時の会員証提示やAEON Payでの決済であるため、アプリが利用できなければ顧客体験を著しく損なってしまい、ブランド毀損の影響が大きいという特性があるのです。

にもかかわらず、当初はそのリスクを十分に考慮されないままアプリを構築・リリースしてしまっていたため、DBが高負荷に耐えられずにシステムが停止する、Podが応答しなくなるといった問題が頻発していました。現在は改善されていますが、当時はアプリの構造自体に大きな問題があったというよりも、「設計段階でサービスの特性を深く理解していなかった」ことが根本原因だったという反省があります。

度重なる障害発生で、お客さまに多大なご迷惑をおかけした反省から、iAEONアプリの信頼性向上を最重要課題としてとらえた社内横断プロジェクトを立ち上げました。その中で実施した代表的な取り組みをいくつかご紹介します。

キャッシュを活用して、通信が切れても動く仕組みへ

まず、アプリの起動時の挙動を根本的に見直しました。従来のアプリは、起動と同時にサーバーとの通信を試み、失敗すると即座にエラーポップアップを表示して終了していました。これでは、サーバーサイドに障害が発生した場合、アプリが全く利用できない状態に陥ってしまいます。

そこで、極力データをキャッシュし、通信エラーが発生した際にはキャッシュからデータを復旧するロジックに全面的に作り替えました。これにより、通信環境が悪くても最低限の操作ができるようになっています。その結果、通信環境が不安定な状況でもiAEONアプリが起動し、一部機能が利用できるようになったのです。

機能ごとにサービスレベルを分割

次に、画面を構成するパーツごとにサービスレベルを分離するという対策を講じました。以前は、1つの画面を表示するために複数のAPIを一括で呼び出していて、どれか1つのAPIがダウンすると画面全体が表示されなくなるという問題がありました。

この問題を解消するため、速度とのバランスを考慮しつつ、「クーポン表示」や「店舗情報」といった各機能をそれぞれ個別のAPIで処理するように分割したのです。例えば、クーポン機能に障害が発生した場合でも、店舗情報は正常に表示されるようにして、部分的な障害は許容しつつ、全体的なサービス停止を防ぐことを目指しました。

会員証と決済は最優先で確保

最も重要な取り組みとして、お客さまがレジ前で頻繁に利用する会員証機能とAEON Pay決済機能を、極めて高いサービスレベルで保証するための実装を行いました。これらの機能は、どんな障害が起きても動くことが絶対条件ですので、基盤となるASP/B全体が完全にダウンした場合でも、独立して動作するような仕組みを構築しています。たとえば、iAEONアプリ起動時の会員コード表示といった基本的な導線は静的に確保されており、その後のAEON Pay決済の表示処理も、ASP/Bに一切依存しないロジックで実装されています。

一部、広告バナーのような機能はASP/Bに依存していますが、たとえバナーが表示されなくても、会員証とAEON Payは必ず表示されるようになっています。この安定性を実現するために、「会員基盤」と呼ばれるシステムの信頼性を最優先で高めており、この部分だけは絶対に落とさないように構築されています。

実は2024年にも同様のシステム障害が発生しましたが、信頼性向上プロジェクトで耐障害性の強化に取り組んでいたことで、システム的な被害は最小限に抑えられ、ユーザー側ではまったく問題が表面化せずに済みました。よく言われる「銀の弾丸は存在しない」という中でも、信頼性向上プロジェクトが“銀の弾丸”のように機能したと感じています。

現在は、内製チームがスクラム体制で「ミニプログラム対応」の開発を進めているところです。ミニプログラムのSDKを作り、外部ストレージに配置されたミニプログラムを動的にダウンロードしてiAEONアプリ内で実行できる機能を実現しようとしています。

イオングループは多様な業態が存在し、それぞれ独自のアプリを展開しているという実情があります。それらを強制的にiAEONアプリに統合することは、お客さまにとって利便性を損なう可能性があり、さらには各事業会社にとっても、これまで培ってきた顧客資産をリセットすることになりかねません。

そのため、既存のアプリは存続させつつ、iAEONアプリ内でもミニプログラムとして利用できるようにすることで、各事業会社はこれまでの資産を守りながら、iAEONアプリの顧客基盤を活用していける仕組みを構築していく予定です。

現時点ではサードパーティへの公開は未定ですが、将来的にはイオンの経済圏の中で、イオングループ以外の企業とも連携できるような仕組みに発展させていきたいと考えています。

iAEONアプリを支える「New Relic」の有用性

見どころ解説

現場のボトムアップで導入となったNew Relicを全面的に活用し、KubernetesからJavaアプリ、フロントエンドまで一元監視。その結果、年間で億単位のコスト削減を実現した。さらに、開発チームが自主的にダッシュボードを構築し、DevOps文化の定着に貢献するなど、監視ツールの導入がシステムの「高信頼化」と「コスト最適化」を両立させた好例となっている。

New RelicやPagerDutyの導入は、“監視が不足していた”という単純な話ではなく、一部の人に頼っていた“職人芸”を、組織全体で再現可能にするための仕組みと文化をどう整えるか、そして、単に数値を可視化するのではなく、それを「見ることが当たり前」とする文化の形成。それがSREチームから始まり、開発現場へ浸透していったプロセスに、DevOpsの本質を見た気がする。現場の“思考習慣”を少しずつ変えていくことが、技術投資の一番難しいところでもあり、最も報われるところでもあるのだろう。（池田）

iAEONアプリを支える仕組みとして、New Relicを活用しています。全体の仕組みを網羅的に紹介すると長くなるので、ここでは「コスト最適化の成果」に絞ってお話します。

New Relicの稼働状況は、Kubernetes環境への統合はもちろん、Javaのアプリケーション領域でもNew Relic APMをほぼ全てのサービスで導入しています。その結果、インフラからアプリケーションレイヤーに至るまで、広範囲のメトリクスを一元的に取得できる状態が整っています。

さらに、フロントエンドにもNew Relicのプラグインを組み込んでいるため、アプリ側のクラッシュレポートなどの情報もすべてNew Relic経由で収集しています。New Relicでの監視が困難なVM上で稼働している一部のミドルウェアについては、Prometheusのエージェントなどを活用してカバーしています。

年間で億単位のコスト削減を実現

このように、New RelicはASP/Bを含むシステム全体において欠かせない存在になっており、とても重要な役割を果たしています。もちろん相応のコストはかかりますが、New Relicのようなモニタリングツールを活用することで、さまざまな問題を早期に発見し、障害を未然に防ぐことが可能になることから、費用対効果は非常に高いと考えています。

New Relicのメトリクスを詳細に分析することで、不要なリソースの特定や効率的なリソース構成への最適化などを通じて、Azureのクラウドコストを大幅に削減することに成功し、年間で億単位のコスト削減を実現しています。

こちらはNew Relicのダッシュボード画面です。ASP/Bの環境では、Deployments数632、KubernetesのPod数2831といった具合に、New Relicを徹底的に活用しています。New Relic APMをはじめとするさまざまな機能を使い倒し、あらゆるメトリクスをNew Relic上で一元的に監視できる体制を構築しています。

また、各メトリクスに対して閾値を設定し、異常を検知した際には自動でSlackにアラートを通知する仕組みも導入しています。

New Relicの本格導入は、SREチームにツールへの知見があるメンバーがいて、その人の提案から全社的にNew Relicへの切り替えが始まったものでした。このNew Relicの活用は、まさにDevOpsの理想形だと考えています。今では開発チームのメンバーが自分たちに必要なメトリクスを定義し、それぞれのチームで独自のダッシュボードを構築・運用するなど、積極的にNew Relicを利用しています。

監視ツールの導入がDevOps文化の浸透を促進

New RelicやDatadogのような監視ツールの導入は、単なるシステム状況の可視化やコスト削減だけでなく、DevOps文化の浸透や自律的な運用の促進が非常に大きいと考えています。当社のSREチームが中心となって教育やサポートを行うことで、開発チームだけでなく業務委託の方々を含めた関係者全員がNew Relicの同じ画面を見ながら、改善策の議論や新たなメトリクス追加の検討などを日常的に行えるようになりました。

ログに関しても、もともとはJavaが出力したログをKibana（Elasticsearch）に保存し、それを分析するという状態でした。しかし、分析するだけで能動的な対応には繋がりにくかったため、現在ではほぼ全てのログをNew Relicに集約しています。ログの量は膨大ですが、New Relicで一元管理することでインシデントの未然防止や早期検知が可能になりました。

さらに、検知したインシデントの通知方法として、Slackだけでは限界があると考え、約3ヶ月前からNew RelicにPagerDutyをインテグレーションさせたアラートの自動発報の仕組みを本格的に稼働しています。

この仕組みの導入により、それまで24時間365日体制でエラーログを監視していた専任の運用チームが不要となりました。こうした変革は、単にコストメリットがあるだけではなく、「やればできる」という実感と自信をチームにもたらした点でも大きな意義がありました。

リアーキテクチャを実行する組織

見どころ解説

従来のベンダー依存型開発から脱却し、2024年に大胆な組織改革を実施。専門性を重視した「職能別組織」を採用し、エンジニアの市場価値向上と成長機会の創出を目指した環境づくりに挑む組織戦略が語られている。

エンジニアにとって居心地の良い、エンジニアらしく働ける場所を作りたい、そこへ向かった組織づくりが、着実に始まっていた。発注型からの脱却、機能組織制の導入、職能別の学習と成長機会の確保。それぞれが「育てる文化」を浸透させるための地道な取り組みだと伝わってきた。
特に印象に残ったのは、『イオンにいて「ここで自分の技術力が磨けて市場価値が上がったね」と言えるようになりたい』と、エンジニアに対してイオンで腕を磨き、価値を上げ、どこに行っても通用する人になってほしいと明言していた点。その誠実さに、技術責任者としての覚悟を感じた。（池田）

最後にリアーキテクチャを実行する組織の組織のあり方についてお伝えします。この部分については、会社の状況や経営者の判断によって「機能別組織」と「事業別組織」のどちらの組織構造を採用するかが変わってきます。それぞれ長所・短所があるため、唯一の正解はないと言えるでしょう。

左側の機能別組織は専門性の高い人材が集まるので、チームとしての成長が促進され、特定の分野で高度な専門性を深めやすいというメリットがあります。しかし、ビジネスサイドとの距離が生まれやすく、開発の方向性が事業から乖離するリスクもあります。

その一方で、右側の事業部別組織ではビジネスの目的や顧客のニーズに重点を置く職能横断型のチームを作りやすいため、一つのプロダクトチームの中にフロントエンド、サーバーサイド、データ分析など多様なスキルを持つ人材が集まります。ただし、アーキテクチャなどの技術的な側面は、そのプロダクト内に閉鎖的になる傾向があるというデメリットも考えられます。

どちらの組織構造が優れているということはなく、それぞれの企業の状況や成長段階に応じて適切な組織形態を選択することが重要です。

イオンはもともと、システム開発を内製化しておらず、外部のベンダーや業務委託の方々に発注して作ってもらうというスタイルが一般的でした。プロパー社員はその発注や管理を担当するPM的な立場が中心で、要件定義をまとめて発注し、納品された成果物を検収して支払い処理をするというものでした。

私が2023年にイオンに参画した際に思ったのは、今の環境のままでは専門性の高いエンジニアが力を発揮しにくく、成長機会も限られるということでした。せっかくイオンの開発に興味を持って入社したエンジニアが、いきなりベンダーコントロール業務を担当するのはモチベーションも下がりますし、非常にもったいないと感じたのです。

そこで、組織構造そのものを見直す必要があると判断し、2024年に大きく組織改編を行いました。

ビジネスサイド

Product Owner制を導入し、企画職としてプロダクトバックログの優先順位付けや、各事業会社および顧客からの課題の集約・整理を担うチームを構成しています。

開発サイド

プロジェクトマネジメントやSE的役割を担うチームをはじめ、フロントエンド、バックエンド、QA、SREなどの職能ごとにチームを分け、それぞれの専門性を高める職能別機能組織を採用しています。まだこの体制は過渡期にありますが、職能間での横断的な情報共有を促しつつ、エンジニア個々が専門性を深め、継続的に成長できる組織を目指しています。

エンジニアは、常に成長を求めて転職も視野に入れている職種だからこそ、イオンに在籍することで技術力が向上し、市場価値が高まったと実感できるような環境を作りたいと考えています。

イオングループでは一緒に変革に挑んでくれる方を募集中です。

どんなことをしているのか気になる方は、お気軽にご連絡ください。カジュアル面談も実施しておりますので、まずはざっくばらんにお話しましょう！