バッチETLからリアルタイムへ：金融・製造業が採用する次世代データ基盤

従来型のデータパイプラインでは、トランザクションシステム（OLTP）から分析用の別ウェアハウス（OLAP）へ、通常は夜間のバッチETLジョブによってデータを移送いたします。経営判断が24時間待てた時代には、この方式で十分でした。しかし、不正検知システムが疑わしい取引を50ミリ秒以内に検出しなければならない場合や、リアルタイムパーソナライゼーションエンジンが直近5秒間のユーザー行動を必要とする場合には、もはや成り立ちません。バッチウィンドウ、ステージングデータベース、変換ロジック、ウェアハウスへのロードと、レガシースタックを構成する各層のすべてが、レイテンシと運用調整の複雑さを積み上げていきます。分析が実行される頃には、データはすでに鮮度を失っているのです。

これに代わる現代的な構成では、変更データキャプチャ（CDC）を用いて、ソースデータベース上のすべてのトランザクションを、ソース側の性能に影響を与えることなく、サブセカンドのレイテンシで統合分析エンジンへストリーミングいたします。StriimはOracle、SQL Server、PostgreSQLをはじめとするエンタープライズデータベースのトランザクションログを読み取り、変更データを転送中（インフライト）の変換パイプラインに通した上で、ターゲットへリアルタイムに配信いたします。その配信先となるのがSingleStoreです。SingleStoreはトランザクションクエリと分析クエリの両方を単一のエンジンで処理する分散SQLデータベースであり、OLTP/OLAPの分断そのものを解消いたします。

不正検知を例に、日本の銀行のケースを見てまいります。レガシー構成では、取引データがOracleに書き込まれ、夜間のETLがそのデータをTeradataのウェアハウスへ移送し、不正分析は前日分のデータに対して実行されます。つまり不正の発覚は、発生から数時間後、場合によっては数日後になります。一方、現代的な構成では、StriimがOracleのトランザクションログをキャプチャし、各取引を顧客コンテキストと過去の行動パターンで転送中にエンリッチした上で、サブセカンドのレイテンシでSingleStoreに書き込みます。不正検知クエリはライブデータに対して常時実行され、疑わしい取引は完了する前の段階で検出されます。検出まで24時間かかるのか、それとも50ミリ秒で済むのか。この差は、損失が確定してから気づくのか、詐欺を未然に止められるのかの差にほかなりません。

このアーキテクチャが日本のエンタープライズワークロードに特に適している背景には、2つの要因がございます。第一に、日本のトランザクション量は世界でも最高水準にあり、日本の金融サービス企業では、一般的なデータベースであれば処理しきれないスループットが日常的に求められます。SingleStoreとStriimは、いずれもこの規模での実運用に耐えてきた実績を持っております。これは机上のベンチマークではありません。Dellは在庫レポートを30分から1分へと短縮し、Siemensは10万人の同時ユーザーに対し数十億行を100ミリ秒未満でクエリし、通信キャリアのOptusはこのアーキテクチャへの移行後に1,000万ドルを超える収益漏れを発見いたしました。第二に、日本企業には、オンプレミスまたはプライベートクラウドでの運用を前提とする厳格なデータレジデンシー（国内データ保管）要件がございます。両プラットフォームとも、クラウド版と完全に同等の機能を備えたオンプレミス展開に対応しており、これは近年のデータ製品の多くが備えていない特長です。

このアーキテクチャは、AIにおいても再び効果を発揮いたします。統合エンジンはすでにライブの業務データを保持しているため、別のベクトルデータベースへデータをコピーすることなく、同じ場所からベクトル検索とリトリーバルを提供できます。SingleStoreは、SQL、JSON、全文、そしてベクトルを1つのエンジンに格納し、トランザクションクエリと並行してベクトル検索を実行いたします。これにより、夜間スナップショットに頼ることなく、現在のデータ上で検索拡張生成（RAG）が現実的に機能いたします。データ基盤を標準化する日本のエンタープライズにとって、これはリアルタイム分析のスタックとAIアプリケーションのスタックを1つのシステムに束ねることを意味し、データエンジニアリングの意思決定とAI対応の意思決定が、いまや同一の意思決定であることの理由でもございます。