スーパーのオーケーが購買データ基盤をクラウド移行、ほぼリアルタイムの分析へ

容量の制約がなく、しかもフルマネージド（運用や保守を提供側に任せられる形態）で使えることを条件に置いた基盤選定が、この取り組みの土台になっています。蓄積量の頭打ち、処理性能、保守運用の負荷という三つの課題は、本来それぞれ別の対処が必要なものですが、運用の責任ごと外部に預ける選び方をしたことで、まとめて解ける形に整理されました。製品の機能比較ではなく、自分たちが持ち続けたくない負担は何かという観点から絞り込んだ判断が効いていると見ています。

データが届くと自動的にBigQueryへ読み込まれる、イベント起点の連携の作り込みも見逃せません。基幹システムのリプレースに合わせて連携部分を改修中とされていますが、Cloud Functionsで受け渡しの部分を薄く独立させておく構成なら、周辺システムが入れ替わっても手を入れる範囲が連携部分にとどまります。分析基盤は一度作って終わりではなく、上流の業務システムの都合で何度も揺さぶられるもの。その前提を織り込んだ設計だからこそ、外部環境の変化に大きな手間なく対応できているのでしょう。

アプリ開発では、開発からテスト配信までを一つの環境で完結させる方針が全体を貫いています。テスト配信を自動化できるFirebase App Distributionを使い、UI開発にはGoogleがオープンソースで提供するFlutterを採用して、扱う技術やリソースが際限なく増えないよう抑えている。顧客情報を扱う以上セキュリティは避けて通れませんが、ここもCloud NATやCloud Armor、Identity Platformといったフルマネージドの機能を推奨構成に沿って組み込むことで、独自に作り込むほど脆弱性が生まれやすくなるという構造を回避しています。オーケー側が何を実現したいかを決め、開発パートナーのアイレットが技術選定と実装を担うという役割分担も、この身軽さを支えた要素です。