1000万ユーザーへのプッシュ配信を3倍高速化 - iAEONアプリの大規模配信基盤改善の舞台裏

2024年に1000万ダウンロードを突破したiAEONアプリ。全国のイオングループの情報をユーザーに届けるプッシュ配信は、アプリの重要な機能の1つとなっている。全国各店舗の最新クーポンやキャンペーン情報、さらにはAEON Payでの決済通知など、日々さまざまな情報がユーザーのスマートフォンに届けられている。

特に、アプリに実装されているお気に入り店舗機能と連携したプッシュ配信は、ユーザーにとって重要な情報チャネルとなっている。また、各事業会社が独自に作成したiAEON会員リストに基づく配信など、きめ細かな情報提供も行われている。

しかし、この大規模なプッシュ配信システムには課題があったという。イオンスマートテクノロジー（AST）のフロントエンド開発チーム（iAEON）は、この課題に立ち向かい、大幅な改善を実現した。このプロジェクトを担当した仙波と墨谷のインタビューから、その開発の舞台裏に迫る。

【目次】

100万人へのプッシュ配信に4時間 - タイムリーな情報提供の壁

「イオン◯◯店では今日こんなタイムセールを行っています」

このようなプッシュ通知が届いてユーザーが店頭に到着したとき、すでにタイムセールは終了していた——。実は、技術的な理由によって、こうした顧客満足度の低下につながるリスクが拭いきれていなかった。仙波は、改善前のシステムの課題をこう説明する。

改善前のプッシュ配信サーバーは、配信に大変な時間がかかっていました。たとえば100万人への配信に3時間半から4時間ほどかかっていたのです。（仙波）

この遅さの背景には2つの大きな理由が存在した。

まず1つ目は、インフラへの負荷対策である。プッシュ通知を受け取ったユーザーが一斉にアプリを開くことで、バックエンドシステムに大きな負荷がかかることが懸念されていた。

2つ目は、配信システム自体の制約だ。プッシュ配信サーバーの仕組み自体が、高速な配信に対応できない構造となっていた。

改善前のプッシュ配信基盤は、端末識別用トークン管理サーバー、プッシュ配信サーバー、そしてFirebase Cloud Messaging（FCM）との連携部分で構成されていた。配信先の各端末は固有のトークンを持ち、このトークンを使用してプッシュ通知が配信される。1000万以上の端末に対して、地域や店舗などのカテゴリーに基づいて適切に配信を振り分ける必要があり、その管理も重要な課題であった。

チームが掲げた目標は段階的なものであった。まず短期的にはプッシュ配信サーバーの改善により既存の1.5倍の配信速度を実現し、中期的にはバックエンドシステムとの連携を見直し3倍の速度向上を目指す。そして、最終的な長期目標として、1分間で100万件の配信を実現することを設定した。

これに加えて、アプリ起動時のAPI呼び出し最適化やシステムのスケーラビリティ確保など、バックエンドシステムへの負荷対策も重要な目標として掲げられた。さらに、将来的なユーザー数の増加や新機能追加にも柔軟に対応できる拡張性の確保も視野に入れられた。

高速化への処方箋は、実績あるプッシュ通知エンジンとクラウドネイティブな基盤

解決策として採用されたのは、フェンリル社の「BoltzEngine」である。NHK紅白歌合戦でもプッシュ配信基盤として採用された実績を持つこのプッシュ通知エンジンは、大規模な同時配信に強みを持つ。採用に至るまでには約半年の評価期間が設けられ、その間に大規模配信時のパフォーマンス評価、既存システムとの整合性確認、コスト評価、そして運用面での実現可能性の確認が綿密に行われた。

そして、新しいシステムは、Microsoft AzureのマネージドKubernetesサービスであるAKS（Azure Kubernetes Service）上に構築された。システムアーキテクチャは、機能ごとに分割された6つのコンテナで構成されている。まずプッシュ配信リクエストの受け付けと検証を行うAPI受付コンテナ、次にリクエストの順次処理と配信管理を担当するバッチ処理用コンテナが2種類、そして実際の配信処理やFCMとの連携、配信状況の監視を行うBoltzEngine用コンテナが3種類という構成である。

当初BoltzEngineは、VM（仮想マシン）環境での運用を前提としていたが、チームはこれをコンテナ化することを決断した。この判断により、スケーラビリティの向上やデプロイメントの容易化、運用管理の効率化が実現された。また、既存のKubernetes運用ノウハウを活用できたことも大きな利点になったという。

もともとiAEONアプリで利用していたKubernetesを採用したので、今まで使ってきたノウハウをそのまま転用できました。これがスムーズにプロジェクトを進められた1つのポイントだったように思います。（仙波）

1回構築してしまえば、VM環境で運用するよりはアップグレードなども容易になります。（墨谷）

配信の仕組みとしては、FCMを利用し、AndroidとiOS両方のデバイスに対応している。iOS向けにはApple Push Notification service（APNs）を経由して配信される仕組みが採用されている。

100万件規模のテストに挑む - FCMの特性を活かしたテスト設計

大規模なテストの実施は、プロジェクトの大きな課題の1つであった。仙波は、「100万件のプッシュを送って検証する必要がありましたが、実際に100万件の端末を用意するのは現実的ではありません」と話す。

この課題に対して、チームは独創的な解決策を見出した。ダミーのトークンを使用した大規模配信テストを実施することで、FCMの仕様上、無効なトークンへの送信も許容される特性を活用したのである。ただ、ここで問題となったのが、パフォーマンスの評価だ。

パフォーマンスは、iAEONアプリ全体で導入しているNew Relicを使用し、ログ管理を行う形で評価していたが、FCMトークンへの配信エラーが発生するたびに個別のエラーログが出力され、結果として通常のログよりも警告ログの方が圧倒的に多くなるという状況に陥っていた。仙波は「従来は100万件送信したら、1エラーごとに1エラーメッセージを出しているような状況でした」と振り返る。

そこで、チームはエラーを必要な単位でまとめて1回のメッセージとして出力するよう改善を実施。これにより、ログ量を適切にコントロールしながら、必要な情報は確実に把握できる運用体制が確立された。

言語の壁を超えた技術連携 - 高速化を支えた開発体制とは

プロジェクトでは、iAEONのバックエンドシステムであるASPB（ASPB: Aeon Smart Platform for Business）の開発を担う中国のチームとの協業も重要な要素となった。

というのも、プッシュ配信の実行主体はASPBであり、そこからプッシュ配信サーバーへのリクエストが送られる仕組みとなっているためである。いくら配信基盤側で同時に1000万、3000万件の配信性能を実現しても、呼び出し側の処理が遅ければ意味がない。「呼ぶ側の仕組みも解明しないと実際には高速化できません」と仙波は説明する。

この課題に対し、チームは開発者同士での直接的なコミュニケーションを重視した。ASPBのシステムがどのようにプッシュ配信サーバーを呼び出しているのか、数万件単位でのリクエストをどう処理しているのかなど、技術的な詳細にまで踏み込んだ議論が必要だったためである。言語の壁を越えるため、チーム内の中国語ネイティブメンバーを活用し、情報共有を行ったという。仙波は、今回のプロジェクトを通じて構築された協力体制に手応えを示している。

『100万件を1分で配信する』という今後の目標を達成するには、さらに密な連携をとっていく必要があります。今回のプロジェクトで、そのためのコミュニケーションの土台ができたと感じています。（仙波）

3倍の高速化を実現、そして次なる挑戦へ

配信基盤の改善とバックエンドシステムとの連携を進めたことで、配信速度は3倍に向上し、システムの安定性と運用効率も大きく改善された。さらに、スケーラビリティの確保により、将来的な拡張にも対応可能な基盤が整備された。

また、分析基盤との連携強化やパーソナライズされた配信の実現により、開封率の向上も図る予定だ。さらに、ライブ配信との連携やリアルタイムイベント通知の実装など、新機能の追加も計画されている。

最後に仙波は「このプロジェクトを通じて、プッシュ配信の可能性がまだまだあることを実感しました。より多くの仲間とともに、さらなる改善を進めていきたい」と展望を語った。「プッシュ配信の仕組みを一緒に作りたいという仲間が増えたら」と墨谷は続ける。

1分間100万件のプッシュ配信という大きな目標に向けて、またiAEONアプリ全体の改善に向けて、フロントエンド、バックエンド、インフラと領域を超えてともに挑戦する仲間を待っているという。技術的なチャレンジを楽しみながら、ユーザー体験の向上に貢献できる——そんな機会がASTにはある。

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

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