​​Snowflakeの検索最適化でOLTP対応を実現。イオンスマートテクノロジーが実践するデータ基盤開発の"いいとこ取り"戦略-第5回 Snowflake Japan Retail Club 登壇レポート-

イオンスマートテクノロジーが扱うデータ規模は、イオンのトータルアプリ「iAEON」のMAUが（月間アクティブユーザー）500万人、関連会社を含めた店舗数は2万店に上るなど、非常に巨大なものです。こうした膨大なデータをいかに効率よく、かつ安定的に処理していくかがデータ基盤チームの大きなミッションとなっています。

そんなデータ基盤の開発、運用をリードするASPD運用ユニット ASPD運用チーム マネージャーの奥山 淳は、2025年11月13日（木）に行われた「第5回 Snowflake Japan Retail Club」に登壇し、Snowflakeの「検索最適化サービス」を活用して、アーキテクチャの簡素化とリアルタイム性の向上を両立させた取り組みについて語りました。

【目次】

「銀の弾丸はない」。ベタープラクティスを追求するデータ基盤開発

私は前職でシステムエンジニアやITアーキテクトに従事し、イオンリテールに入社後は店舗での販売業務を経験しました。現職ではグループ全体のデータを活用・運用する「イオンスマートプラットフォーム（ASP-D）」の開発を率いています。

イオンが扱うデータ規模は日本における小売業の中でも最大規模になるため、一つのプロダクトですべての要件を満たすことは到底不可能です。

「データ基盤製品に『銀の弾丸』はない」という考えのもと、特定のベンダーや製品に依存するのではなく、各製品の強みを活かして最適なデータ基盤を構築する“いいとこ取り”の発想を大切にしています。

さらに、瞬間風速的なベストプラクティスを選ぶのではなく、中長期的に陳腐化せず流用可能なベタープラクティスの継続的な探求をし続けることで、イオングループ全体のデータに関するあらゆる課題に対応できる体制を整えています。

今回、ご紹介するのは従業員向けのアプリケーションで、店舗に在庫がない場合に「近隣店舗に在庫があるかどうかを検索できる仕組み」を構築した事例です。

従来も売上・在庫データは扱っていましたが、完全なリアルタイムではなく、更新タイミングにラグがある状態でした。お客様の満足度と売上機会にダイレクトに影響するため、よりリアルタイムに近づける対応が必要となっていたのです。

この仕組みを実現する上で、技術的な壁となったのが、データ反映の早期化とデータの検索の画面表示レスポンスというOLTP（オンライン・トランザクション処理）への対応でした。

アーキテクチャを理解し、試してみることを実践

最初はRedisを採用していたものの、データ容量が大きくグループ会社への展開に際してはライセンスコストやパフォーマンスの問題、障害ポイントが増えることによる運用の難しさなどから、なかなか導入ができないという課題がありました。

このような背景から、チームで仮説を立てたのが「データ基盤製品のSnowflakeでOLTP対応できる方策はないか」ということです。チームの方針として「アーキテクチャを理解し、まずは自分たちで試してみる」という文化があるため、Snowflakeの担当者や社内のアーキテクトと議論を重ねながら、その実現可能性を探っていきました。

そこで辿りついたのが、Snowflakeの「検索最適化サービス」です。

これは、大量のデータの中から特定の行を素早く見つけ出すクエリの性能を大幅に向上させ、応答時間を短縮して業務の効率化を実現するものです。マイクロパーティションなどの仕組みを活用し、いかに I/O（インプット/アウトプット） を減らし、不要な領域のデータを読み込まないようにするかという “読み取りの最適化” が検索性能を最大化する鍵になりました。

結果的には「検索最適化サービス」を利用することで、ほぼリアルタイムに近い在庫検索が可能となり、店舗オペレーションの改善に大きく寄与したのです。

試行回数を最小化した検索最適化サービスの検証プロセス

私たちがSnowflakeの「検索最適化サービス」を導入するにあたっては、緻密なチューニングを心がけました。

まずは、テーブル情報の整理やサンプルデータを利用してカーディナリティの調査を実施しました。次いで、「テーブル全体のカラムで検索最適化を有効にするか」、もしくは「特定のカラムだけ検索最適化を有効にするか」を見定めていきました。

最終的には後者を選択し、最適なカラムを見つけるための検証プロセスを慎重に進めたのです。

この過程には細かな工夫がたくさんあり、なかでも「PARTITIONS_SCANNED」（スキャンしたマイクロパーテション数）を重要指標として観測し、最も効果的なキーの組み合わせを探っていきました。特に「必要ないレコードはスキャンしないようにする」ことで、検証に必要な試行回数を少なくすることにこだわりました。

「検索最適化サービス」の導入後における成果について、これまで容量やライセンス制約があるにもかかわらず必要だったRedisや、PostgreSQLなどの従来併用していたPaaSの運用負荷から大きく解放されました。つまり、インフラの構築や監視、パッチ適用といったお守り業務から解放され、インフラ担当者における運用・監視工数の大幅な削減を実現できたのです。

またリアルタイム性が求められるなか、DWHからRedisへデータを転送するという「ワンクッション」が不要になったことで、データが発生してから従業員が検索できるようになるまでのリードタイムが劇的に短縮され、運用工数や障害ポイントの削減にもつながりました。

今後も「銀の弾丸はない」という前提に立ち、アーキテクチャの裏側にある仕組みを深く理解するとともに、自分たちのユースケースに合わせて仮説検証を繰り返すことを大事にしていきたいと思います。

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

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