こんにちは！広報の池田です。
2026年7月30日(木)・31日(金)に東京ビッグサイトで開催された「Google Cloud Next Tokyo 26」に参加してきました！
KDDIアイレットはダイヤモンドスポンサーとして出展し、オーケー株式会社様（以下、オーケー様）と共に、ネットスーパーや店舗業務を支えるデータベース基盤の刷新をテーマとしたセッションを実施しました。
オーケー様の事業を支えているのが、ネットスーパーのお客様体験を担う「ネットスーパー DB」と、店舗業務を支える「生鮮 DB」です。
しかし、事業拡大に伴う処理量の増加や運用コスト、データのサイロ化、オンプレミスの Oracle Database からの脱却など、2つのデータベースにはそれぞれ課題がありました。
さらに、日々の業務に欠かせないシステムであるため、長時間停止して一斉に移行することもできません。
今回のセッションでは、移行先として AlloyDB for PostgreSQL を選択した理由や、Database Migration Service（以下、DMS）を活用してダウンタイムを極小化した方法、その先に描くデータ・AI 活用の展望が紹介されました。
「AlloyDB で築くネットスーパーの未来！DMS によるダウンタイム極小化移行」
オーケー株式会社における、オンプレミスおよびクラウド上の DB から AlloyDB への移行事例を詳解します。なぜ Google Cloud が選ばれたのか、その背景から Database Migration Service (DMS) を活用したダウンタイム極小化の舞台裏までを公開。高可用性とマルチクラウドを見据え、ネットスーパーの成長を支える基盤をいかに構築したのか、その全容に迫ります。
【登壇者】
荒川 健児 氏（オーケー株式会社 IT本部 副本部長）
齋藤 寛隆（KDDIアイレット株式会社 グループリーダー）
「高品質・Everyday Low Price」を IT で支えるオーケー様
セッションの前半では、オーケー株式会社の荒川様から、同社の事業とデータベース基盤の役割についてご説明いただきました。
オーケー様は、「高品質・Everyday Low Price」を経営方針に掲げるディスカウント・スーパーマーケットです。
首都圏と関西に170店舗以上を展開し、年商は7,500億円を超える規模へ成長。現在も年5〜10店舗のペースで出店を続けています。
同社では、「小売 × IT」の最先端の仕組みづくりに向け、データ分析とデジタル領域での顧客体験の向上を進めています。
2020年には、オンプレミスで運用していたデータウェアハウスを BigQuery へ刷新。2021年には「オーケーネットスーパー」を開始し、Firebase を活用した会員向けスマートフォンアプリも構築しました。
こうした取り組みを根幹から支えているのが、今回のプロジェクトの対象となった「ネットスーパー DB」と「生鮮 DB」の2つのデータベースです。
事業成長と店舗業務を支える2つのデータベース
「ネットスーパー DB」は、店舗の商品をデジタル領域でもお客様へ届け、顧客体験を向上させるための基盤です。
将来的には法人向けの利用も視野に入れており、顧客層の拡大や新たな事業成長を支える重要な役割を担っています。
一方、「生鮮 DB」は、既存のデータベースと連携し、全店舗からのデータ参照を担うデータハブです。
マスタ情報や原価、棚卸、販売実績といった総菜のコアデータを蓄積・提供し、店舗で使用する帳票の出力など、日々の業務を支えています。
ネットスーパー DB は「事業の成長」、生鮮 DB は「日々の業務継続」を支える基盤であり、それぞれ異なる課題を抱えていました。
2つのデータベースが抱えていた課題
ネットスーパー DB では、今後の事業拡大に伴うトランザクションの増加に対応できる処理性能と拡張性に加え、インフラの運用コストを適正化できる基盤が求められていました。
また、各システムにデータが分散していたため、分析基盤や AI との連携が難しく、お客様一人ひとりに合わせた商品の提案など、新たなデータ活用を進める上で障壁となっていました。
一方、生鮮 DB では、長年稼働してきたオンプレミスの Oracle Database からの脱却が大きな目標でした。
しかし、業務アプリケーション基盤を完全にクラウド化するには数年規模の期間を要するため、新しいクラウド環境と既存環境の長期的な並存が前提となります。
さらに、帳票出力などの店舗業務と密接に結びついており、システムを一斉に停止して全面移行することはできません。
既存業務への影響を抑え、新旧のデータベースでデータの一貫性を維持しながら、段階的に移行する必要がありました。
5つの理由から AlloyDB を選択
ここからは、KDDIアイレットの齋藤が登壇し、移行先として AlloyDB を選択した理由を解説しました。
理由は大きく5つです。
- トランザクション処理性能 (PostgreSQL 比最大4倍)
- AlloyDB 特有の機能による効率的な運用
- Google Cloud のエコシステムによる分析サービスとの連携
- 高可用性（99.99%の SLA・約15秒のフェイルオーバー）によるダウンタイム極小化
- PostgreSQL 互換
単にデータベースを置き換えるのではなく、今後の事業成長やデータ・AI 活用まで見据えた選択です。
今回の構成では、オンプレミスの Oracle Database 上で稼働していた生鮮 DB と、他クラウドで稼働していたネットスーパー DB を AlloyDB へ集約しました。
プライベート通信によるセキュアな移行
移行するデータには機密情報も含まれるため、インターネットを経由せず、オンプレミスや他クラウドから Google Cloud までプライベート通信で接続することが要件となりました。
オンプレミスや他クラウドと Google Cloud の間は、Partner Interconnect を利用した専用線で接続しています。
Google Cloud 内では、ネットワーク用プロジェクトをハブとして Network Connectivity Center を配置。専用線からの通信と各プロジェクトの VPC を接続し、相互にプライベート通信できる構成としました。
AlloyDB や DMS などのマネージドサービスとの接続には、Private Service Connect を利用しています。
これらのサービスを組み合わせ、オンプレミス、他クラウド、Google Cloud の各プロジェクト、マネージドサービスをプライベートに接続しました。
DB の特性に合わせて2つの移行方式を採用
2つのデータベースは、役割や既存環境が異なるため、それぞれに適した移行方式を採用しました。
ネットスーパー DB は、今回の対象が一部データの移行であり、対象範囲について静止点を確保できる状態でした。
そのため、既存の PostgreSQL から対象データをエクスポートし、Cloud Run を利用して AlloyDB へインポートしました。
一方、生鮮 DB は Oracle Database からの異種データベース移行であり、既存業務を継続しながら新旧のデータベースを並行稼働させる必要があります。
そこで採用したのが DMS です。
DMS でダウンタイムを極小化
DMS は、移行元の Oracle Database に記録されたトランザクションログを読み取り、変更された差分データを継続的に AlloyDB へ反映します。
データベース全体へ繰り返しクエリを実行するのではなく、トランザクションログから変更内容を取得するため、移行元への負荷を抑えられます。
また、差分データのみを転送することで、新旧のデータベースをデータの遅延を抑えながら並行稼働できます。
既存業務を続けながらデータを同期し、業務への影響が少ないタイミングで切り替えられることが、ダウンタイム極小化の大きなポイントです。
Oracle から AlloyDB への異種 DB 移行
Oracle Database と AlloyDB では、データベースの構造や SQL の記述方法が異なります。
そのため、移行は次の3つのフェーズで進めました。
- スキーマ変換
- データ移行
- 移行後の検証
スキーマ変換には、DMS の Conversion Workspace を利用しました。
標準的な構文は変換できますが、複雑な処理には個別の修正が必要です。
Conversion Workspace の Assist 機能では、Gemini による修正案を確認できるため、担当者がコードを書き直すよりも効率的に作業を進められます。
ただし、提案には不要な変更が含まれる場合もあるため、最終的には人による確認が必要です。
また、日本語を含むカラム名は DMS の移行対象外だったため、英数字の仮テーブルを作成してデータを移行し、移行先で本来の日本語名へ戻す個別対応を行ないました。
Data Validation Tool で移行結果を検証
移行後は、Google Cloud が提供する Data Validation Tool を利用し、移行元と移行先のデータを比較しました。
レコード件数や行単位のデータを機械的に突き合わせ、正しく移行できているかを確認できます。
数千万件規模のテーブルでも件数比較を実施できましたが、複合主キーを持つ大規模なテーブルでは、比較時に多くのメモリを消費する場合がありました。
こうした場合は、主キーの範囲ごとにデータを分割して検証することが有効です。
移行方法だけでなく、「正しく移行できたことをどのように確かめるか」まで設計することが、信頼性の高い移行には欠かせません。
移行の先に描くデータ・AI 活用
今回のプロジェクトでは、データベースの移行そのものをゴールとしていません。
AlloyDB への集約後は、BigQuery と外部データを組み合わせた分析の高度化や、AI を活用した商品検索を検討しています。
BigQuery と外部データを組み合わせた分析
生鮮部門の店舗では現在、担当者が既存の Oracle Database からデータを抽出し、Excel で集計や状況確認を行なっています。
今後は、Datastream を利用して AlloyDB のデータを BigQuery へニアリアルタイムに連携する予定です。
BigQuery 上で生鮮商品の実績と、天気情報、人流データ、客数予測、POS システムの販売実績などを組み合わせることで、発注や値引きのタイミングを、より精緻なデータに基づいて判断できるようになります。
廃棄ロスの最小化や利益率の向上につながる、データドリブンな意思決定基盤としての活用が期待されています。
自然な言葉から商品を探せるネットスーパーへ
ネットスーパーでは、AlloyDB AI を活用した自然言語による商品検索を検討しています。
従来のキーワード検索では、検索した言葉と商品名や説明文が一致しなければ、条件に合う商品を見つけられないことがあります。
AlloyDB AI のベクトル検索を活用することで、例えば、
「コレステロールが気になる人向けの油はある？」
といった自然な質問に対しても、意味や文脈が近い商品を探せるようになります。
価格などの条件と組み合わせたハイブリッド検索や、将来的には自然言語の指示だけでデータを検索する AlloyDB AI natural language の活用も期待されています。
このプロジェクトから見えた3つのポイント
今回の移行プロジェクトは、次の3つのポイントに整理できます。
① データ活用の将来像から移行先を選ぶ
古いデータベースを置き換えるだけではなく、BigQuery との連携や AI 検索など、移行後のデータ活用まで見据えて AlloyDB へ集約しました。
移行完了をゴールではなく、新たなデータ活用の出発点として設計しています。
② DMS で新旧環境を並行稼働させる
DMS の継続レプリケーションによって、既存業務を続けながらデータを移行し、任意のタイミングで切り替えられる環境を構築しました。
止められないシステムでも、ダウンタイムを極小化しながら移行できることを示しています。
③ ネットワーク構成を今後の共通基盤にする
Partner Interconnect、Network Connectivity Center、Private Service Connect による構成は、今回の移行だけでなく、今後他のシステムを移行する場合や、他クラウド・オンプレミスと接続する場合にも展開できます。
データベースの移行にとどまらず、その後のクラウド活用を支える土台まで構築したプロジェクトとなりました。
最後に
今回のセッションを通じて、「止められないシステムを移す」というプロジェクトの難しさと、それを支える技術設計の奥深さを実感しました。
既存業務を継続しながら、新旧環境のデータの一貫性を保ち、セキュアな通信経路を構築した上で、正しくデータが移行されたことを検証する。
単純に新しいデータベースを用意して入れ替えるだけではない、様々な工夫が盛り込まれていました。
また、AlloyDB への移行は、BigQuery と外部データを組み合わせた分析や、AI を活用した自然な商品検索を実現するための第一歩でもあります。
事業の成長と日々の店舗業務、その両方をデータとクラウドで支える未来を感じるセッションでした！
なお、KDDIアイレットでは、今年もたくさんの「Google Cloud Next Tokyo 26」レポート記事を公開しています。
ぜひ、他の記事もチェックしてくださいね！
それでは、最後までお読みいただきありがとうございました！
企業の生成 AI 活用を、KDDIアイレットが支援します！
業務効率化・AI 導入支援について、お気軽にご相談ください。
簡単30秒