はじめに
株式会社ASSIGN（アサイン）の白井です。
現在、プロダクト改善をよりデータドリブンに進めるため、信頼性と再現性の高いデータ分析基盤の構築を進めています。
その一環として、Cloud SQLに蓄積された業務データを、BigQueryへ安全かつ正確に連携する仕組みを整備しています。
単なるデータ連携にとどまらず、セキュリティ・スケーラビリティ・運用自動化の観点からも最適な構成を目指しています。
この記事では、「安全に・正確に・安定してデータを連携させるための設計と運用の工夫」について紹介します。
本記事で扱う主なテーマ
- 【運用】: Cloud Run FunctionsとDatastreamのハイブリッド構成による「安定性」と「柔軟性」の両立
- 【運用】: 大量データ連携におけるStreaming InsertからLoad Jobへの切り替え判断
- 【セキュリティ】: Secret Manager導入によるDB認証情報の安全な管理
- 【セキュリティ】: Datastream利用時のネットワーク分離（PSC/VPC Peering）
- 【セキュリティ】: BigQueryポリシータグによる列レベルのデータマスキング
プロジェクトの全体像
本プロジェクト始動の背景：非効率かつリスクを伴う手動運用からの脱却
これまで弊社では、Cloud SQLに蓄積された業務データを手動でBigQueryに連携していました。
その際、ユーザーの氏名やメールアドレスなどの個人情報をCSV出力前にSQLで都度マスキングしていたため、単純な連携作業でも多くの工数がかかっていました。
また、手動マスキングはヒューマンエラーのリスクを内包しており、セキュリティ観点からも継続運用が難しい状態でした。
さらに、ビジネス側が分析を行いたい場合もエンジニア依存で、即時性のある分析ができませんでした。
加えて、BigQuery上のクエリ管理はコンソール上で直接行われており、
「どのクエリが最新か」「誰が修正したのか」が不明瞭で、チーム全体の品質管理にも課題がありました。
このような課題を解消するために、「データ連携の自動化 × セキュリティの強化 × クエリ品質の可視化」を軸としたデータ分析基盤再構築プロジェクトを立ち上げました。
本プロジェクトの目的
- データの信頼性とセキュリティを両立させる
- 分析の出発点は「正しいデータが正しく守られていること」であると考えています。
- どれほど高度な分析を行っても、入力データが不正確だったり、情報漏えいのリスクを抱えていては意味がありません。
- そのため本プロジェクトでは、データの正確性（ETL処理の整合性・再現性）とセキュリティ（認証情報・ネットワーク・アクセス権限・マスキング）を両立させる設計を最優先に据えました。
- 誰もが安心してデータを活用できる環境を作る
- 従来は分析やレポート作成がエンジニア依存で、データ抽出や加工に時間がかかりすぎていました
- 現在はBigQueryクエリをGitで管理し、レビュー・履歴管理を可能にすることやAI駆動で非エンジニアであってもクエリを作成できるようにする体制を整えています。
誰もが安心してデータを活用できる環境作りについては、今後、弊社の別プロジェクトであるAI駆動開発チームと連携して進めていく予定です。
この取り組みは、クエリ生成の自動化・レビュー支援・分析知識の民主化を目指した次のフェーズとして、別記事で詳しく紹介します。
Cloud SQLからBigQueryへの自動データ連携の全体像
前提知識：Cloud SQLとBigQuery
本プロジェクトで扱う主なデータサービスは、Cloud SQLとBigQueryの2つです。
| サービス | 役割 | 主な特徴 |
|---|---|---|
| Cloud SQL | アプリケーションデータを保存するリレーショナルDB | 自動バックアップ・フェイルオーバー・VPC接続など、運用をGoogleが管理 |
| BigQuery | 分析用データウェアハウス | サーバーレスで大規模データを高速処理。スキャン量課金モデルを採用 |
要するに：Cloud SQLは業務データの“保管庫”、BigQueryはそのデータを活用する“分析箱”。
参考:
目的
- 分析に利用する基幹データを、正確・安全・自動的に Cloud SQL から BigQueryに連携できる状態を確立すること
- 常に最新かつ信頼性の高いデータを分析に活用できる環境を整備する
- セキュリティ面でも安全にデータが流れる構成（認証・ネットワーク・マスキング）を担保する
実現方法
- 結論として、現状では以下の2つの方法を組み合わせることで、自動連携を実現しています
- Cloud Run Functions + Cloud Schedulerによる定期自動更新
- Datastreamによるリアルタイム自動更新
少し寄り道：なぜ2つの方法を採用したのか？
当初は、Cloud Run Functions だけで自動連携を完結させる構成を検討していました。
Datastreamはスキーマ変更に弱く、互換性のない変更があると連携エラーが発生する可能性があります。
また、導入には VPC PeeringやPrivate Service Connect（PSC）などネットワークの知識が必要で、当時は不確実性が高いと判断していました。
しかし、実際に Cloud Run Functions ベースで運用してみると、次の課題に直面しました。
-
CPUエラーの頻発
- 処理量が増えるにつれ、Cloud Run Functions の CPU リソースが不足し、安定運用が困難になりました。
-
データ不整合の発生
- Cloud DLP を用いたマスキング処理や、Cloud SQL と BigQuery の型差を吸収するための自前変換ロジック、 さらに
updated_atに基づく増分処理の実装などが複雑化し、 結果として Cloud SQL と BigQuery 間で数件〜数十件のデータ差異が発生していました。。
- Cloud DLP を用いたマスキング処理や、Cloud SQL と BigQuery の型差を吸収するための自前変換ロジック、 さらに
データの正確性が担保できないことは、分析基盤の根幹を揺るがす問題です。
そのため、「正確性を最優先に」 方針を転換し、自動連携の仕組みを再検討しました。
結果として、Datastream の仕組みを学び直し、ネットワーク構成や運用方法を一つずつ整理しながら導入まで到達しました。
今では、Cloud Run Functions による安定的な定期処理と、Datastream によるリアルタイム連携のハイブリッド構成が実現できています。
Cloud Run Functions + Cloud Schedulerによる自動連携の仕組み
前提知識：Cloud Run Functions と Cloud Scheduler
データ連携の自動化では、Cloud Run Functions と Cloud Scheduler を組み合わせて利用しています。
どちらも Google Cloud が提供するマネージドサービスで、イベント駆動型の処理や定期実行の自動化を容易に実現できます。
| サービス名 | 役割 | 主な特徴 |
|---|---|---|
| Cloud Run Functions | データ連携処理を実行する関数基盤 | イベント／HTTP トリガーで起動可能なサーバーレス環境。コンテナ化対応でスケーラブル。 |
| Cloud Scheduler | 処理の実行タイミングを制御するスケジューラ | cron形式で定期実行を設定でき、HTTPリクエストやPub/Subトリガーを送信可能。 |
要するに：
Cloud Run Functions は「処理を実行する箱」、Cloud Scheduler は「その箱を決まった時間に押すスイッチ」。
この2つを組み合わせることで、Cloud SQL → BigQuery への定期自動連携をシンプルに実現できます。
処理の流れ
メリット
1. 完全サーバーレスでの運用
- サーバーの起動・停止・スケーリングをすべて自動化でき、常駐処理が不要。
- Cloud Scheduler や Pub/Sub と組み合わせることで「必要なときだけ動くジョブ」を実現。
- 処理が終われば自動でスケールダウンし、コストを最小限に抑えられる。
2. 任意ロジックを柔軟に実装できる
- Datastream のような CDC 専用サービスと異なり、抽出・加工・ロードの全工程を自前で制御可能。
- 例：
- Cloud SQL 側での複雑な JOIN・条件抽出
- 型変換・正規化・NULL／timestamp の補正
- BigQuery 側での MERGE（UPSERT）制御
- Node.js / Python / Go など任意の言語で記述できるため、スキーマ変更やビジネスロジックにも即時対応できる。
3. スケーラブルで再実行性が高い
- データ量やリクエスト数に応じて自動スケールアウト。
- Cloud Logging や Error Reporting に統合されており、失敗時の検知と再実行が容易。
- Cloud Tasks / Scheduler と組み合わせれば、リトライ・アラート・再実行フローをシンプルに構築可能。
4. 運用・監視の一元化
- Cloud Logging / Monitoring / Error Reporting / Trace と連携し、エラー箇所や処理状況を可視化。
- Datastream のようにブラックボックス化しないため、障害時の切り分けが容易。
- Cloud Build を組み合わせれば、CI/CD による自動デプロイ運用も可能。
デメリット
1. 開発・運用コストが高い
- Datastream のように自動で CDC（変更データキャプチャ）してくれるわけではなく、増分検知・型変換・スキーマ対応をすべて自前で実装する必要があります。
- 初期構築だけでなく、スキーマ変更やテーブル追加時にも修正・再デプロイが発生。
- 「作って終わり」ではなく、継続的なメンテナンス前提の運用 になります。
2. トランザクション整合性の保証が難しい
- Cloud SQL の変更をリアルタイムで取得する仕組みがないため、実行タイミング次第で取りこぼし・重複が起こる可能性 があります。
- 特に
updated_atなど時刻カラムの精度・タイムゾーン差異に注意が必要。 - Datastream のような トランザクション単位での整合保証 はできません。
3. 実行時間とメモリの制約
- Cloud Run Functions の実行時間には上限（最大 60 分）があり、大量データバッチではタイムアウトのリスク があります。
- 大規模処理では ジョブ分割や再入可能設計 を自前で実装する必要があります。
4. コールドスタートによるレイテンシ
- リクエストが少ないときはインスタンスが停止し、次回起動時に 数秒〜十数秒の起動遅延 が発生。
- 定期実行ジョブでは問題になりにくいですが、短時間ジョブを頻繁に実行する構成では注意が必要 です。
5. エラーハンドリングの設計が必要
- 通信エラーや API 失敗時に 自動再送や補完は行われません。
- Cloud Tasks / Pub/Sub / Cloud Logging などを組み合わせ、
リトライ制御・監視・アラートの仕組みを自前で設計する必要があります。
例：BigQuery Load Job の失敗時に自動再実行処理を設ける、など。
6. 監査・再現性の確保が難しい
- Datastream のように DML ログが自動で残らないため、
「いつ・どのデータが・どんな条件で転送されたか」を追跡するには
独自のログ保存・メタデータ管理設計 が必要になります。
工夫した点
1. Secret Manager で認証情報を安全に管理
-
課題
- 従来は Cloud Run Functions のデプロイ時に、データベース接続パスワードを引数として直接指定しており、ログや履歴から情報が露出するリスクがありました。
-
改善
- Google Cloud Secret Manager を導入し、パスワードを暗号化した状態で安全に管理。
- 関数実行時に Secret を動的参照する構成としたことで、デプロイ時に秘匿情報を渡す必要がなくなりました。
-
効果
- 機密情報が Cloud Run の環境変数やログに残らず、セキュリティと運用安全性を大幅に向上。
2. 大量データ連携を安定・高速化（Streaming Insert → Load Job へ）
-
課題
- 当初は Cloud Run Functions から BigQuery へ直接データを送る Streaming Insert を利用していました。
- しかし数十万〜数百万件規模のデータを扱う場合、以下の問題が発生していました。
- データを1行ずつ送信するため処理時間が長い
- ネットワークや API 制限により、一部レコードの欠損・重複が発生することがある
- 従量課金のため、バッチ処理では コスト効率が悪い
-
改善
- BigQuery の Load Job 方式に切り替え、Cloud Storage に一度ファイルとして保存してから一括ロードする構成へ変更。
-
効果
- 大量データでも高速・安定的にロード可能
- 一括処理でコストを抑制し、再実行も容易
- 成功／失敗をジョブ単位で管理でき、信頼性の高いバッチ処理 を実現
結果として、性能・コスト・運用安定性のすべてを大幅に改善できました。
Datastreamによる自動連携の仕組み
Datastreamって？
Datastream は、Google Cloud が提供する 変更データキャプチャ（CDC: Change Data Capture） サービスです。
データベースで発生した INSERT / UPDATE / DELETE の変更をリアルタイムに検知し、BigQuery などへ自動で反映 します。
要するに、
「データベースで変更があったら、分析基盤にも即座に反映される」──これをノーコードで実現してくれるのが Datastream です。
仕組みの概要
-
変更の検知（CDC）
- Datastream は MySQL や PostgreSQL が出力するトランザクションログ（Binlog / WAL）を監視します。
- ログには「どのテーブル・どの行が・どう変更されたか」がすべて記録されており、Datastream はこれを読み取り「変更イベント」として取得します。
-
変更データの転送
- 検知した変更は、Datastream が内部的に利用する Cloud Storage（Google 管理の一時ストレージ） に一旦書き出されます。
- この中間層はユーザーから見えませんが、安全性と再処理性を担保するためのバッファ層 として機能しています。
-
BigQuery への反映
- Datastream と連携する BigQuery Data Transfer Service が、この変更データを自動的に取り込み、対応する BigQuery テーブルをリアルタイムに更新します。
- これにより、常に最新のデータを分析やダッシュボードで利用できる状態を保てます。
参考リンク：Datastream の概要（公式ドキュメント）
ネットワークの基礎知識：VPCピアリング、PSCって？
Datastream を理解するうえで欠かせないのが、Google Cloud のネットワーク構成（VPC, Peering, PSC） です。
なぜなら、Datastream は単体で動くサービスではなく、Cloud SQL のようなプライベートネットワーク内にあるデータベースと安全に通信する必要がある からです。
この通信経路をどう確保するかで、セキュリティ・安定性・運用負荷が大きく変わります。
VPC（Virtual Private Cloud）とは？
VPC（Virtual Private Cloud） は、Google Cloud 上で構築できる 論理的に分離された専用ネットワーク空間 です。
クラウド上のリソース（例：Cloud Run、Cloud SQL、BigQueryなど）が、安全に通信できるようにする「社内ネットワーク」のようなものです。
通常のクラウドリソースはインターネットを介して誰からでもアクセス可能ですが、VPC内に配置されたリソースは
特定のIP範囲・ルール・経路を満たす通信のみ許可される よう制御されます。
これにより、セキュリティと制御性を両立 できます。
| 観点 | Public IP接続 | Private IP接続 |
|---|---|---|
| 通信経路 | インターネットを経由（外部公開） | Google Cloud 内のプライベートネットワーク内で完結 |
| 露出範囲 | Cloud SQL にグローバルIPが割り当てられる | Cloud SQL に内部IPのみ割り当て、外部からは見えない |
| 防御手段 | FWルールでアクセス制御 | そもそも外部経路が存在しない（物理的遮断） |
| リスク構造 | 攻撃対象になりうる | 外部からの攻撃対象外 |
| 責任分界点 | 通信経路の安全性は利用者が担保 | Google Cloud内部で完結しクラウド側が保護 |
VPCピアリング (VPC Peering)とは？
VPC Peering は、Google Cloud 上の 異なるVPCネットワーク同士を直接つなぐ仕組み です。
これにより、Datastream（Google管理VPC）と Cloud SQL（自社VPC）が プライベートIPで相互通信 できるようになります。
Peering 接続はインターネットを経由しないため、以下のような特徴があります。
- 通信内容が外部に露出しない
- 高速・低遅延で安定したデータ転送が可能
- 双方向通信（Datastream ⇄ Cloud SQL）が可能
PSC (Private Service Connect)とは？
Private Service Connect（PSC） は、Google Cloud が提供する「サービス単位での安全なプライベート接続」の仕組みです。
VPC Peering が「ネットワーク全体をつなぐ」のに対し、PSC は 特定のサービス（例：Cloud SQL）だけに通路を作る 点が大きく異なります。
以前は Peering しか手段がなかったため、ネットワーク全体が接続されるリスクや管理コストが問題でした。
PSC はそれを解消し、Cloud SQL にだけ安全なアクセスを提供する専用経路 を構築します。
参考リンク：
Datastreamを使った連携の全体像
本プロジェクトでは、Cloud SQL と Datastream の接続に Private Service Connect（PSC）を採用しています。
Google Cloud 公式でも、Cloud SQL の接続方式として VPC Peering は非推奨、PSC が推奨と明記されています。
なぜ VPC Peering ではなく PSC なのか
VPC Peering はネットワーク全体を相互接続してしまうため、到達範囲が広くなりすぎるという構造的な問題を持っています。
一方で Private Service Connect（PSC）は、Cloud SQL など特定サービス単位で閉じたプライベート接続を実現できるため、
セキュリティ・拡張性・運用性の観点でより適した選択肢となります。
| 観点 | VPC Peering | PSC |
|---|---|---|
| 接続範囲 | VPC 全体が接続される（広すぎる） | サービス単位で限定可能 |
| セキュリティ | 最小権限の原則を満たしづらい | Cloud SQL のみに通信経路を限定できる |
| CIDR 制約 | 重複不可、拡張困難 | CIDR の重複を許容 |
| 拡張性 | 非推移性（A–B・B–C間接続でもA–C不可） | マルチVPC構成に対応 |
| 推奨度 | 非推奨 | 公式推奨パス |
Datastreamを使う上での注意点
テーブルの追加について
Datastream では 後から対象テーブルを追加することが可能 ですが、
その際には注意すべきポイントがあります。
-
追加時はストリームの一時停止が必須
- Datastream の設定変更（テーブル追加など）を行う際は、一時的にストリームを停止する必要があります。
- 停止中に発生した変更データは Datastream が内部バッファに保持し、再開時に BigQuery へまとめて反映します。
- ただし、停止時間が長いほど再開時の負荷（CPU・メモリ消費）や反映遅延が大きくなる傾向 があるため、極力短時間での停止・再開を行うことが推奨されます。
✅ 推奨運用
- メンテナンス時間帯など、更新頻度の低い時間に実施
- 追加対象のテーブル数を最小限に絞る
- 追加後は Datastream の状態を必ず確認（「Running」に戻るまで待機）
テーブルデータの入れ替え方法
Datastream は Cloud SQL の 変更履歴（CDC: Change Data Capture） を利用しており、
INSERT / UPDATE / DELETE などの 行単位の変更イベントを検知 して BigQuery に反映します。
そのため、TRUNCATE 文の使用は禁止 です。
-
禁止理由
-
TRUNCATEはテーブルを物理的に削除・再作成する操作であり、CDC イベントを発生させません。 - Datastream から見ると「削除がなかった」ように見えるため、Cloud SQL と BigQuery の内容が不整合になります。
- さらに、TRUNCATE 実行後にテーブルの内部オブジェクトIDが変わり、
Datastream が監視している元テーブルとの対応関係が壊れる可能性があります。
-
❌ NG例
TRUNCATE TABLE users;
✅ OK例
DELETE FROM users;
このように、テーブルを空にしたい場合は必ず DELETE 文を使用 することで、
Datastream の CDC イベントが正しく検知され、BigQuery との同期整合性を維持できます。
Datastreamで連携したデータのセキュリティ対策
Datastreamを利用すると、Cloud SQL に保存されている生データがそのまま BigQuery に複製されます。
そのため、BigQuery 上でも適切な セキュリティ対策（アクセス制御・マスキング） を講じる必要があります。
本プロジェクトでは、主に次の 2 つの方法が検討対象となりました。
- Dataform を用いたデータ変換・マスキング処理
- BigQuery のポリシータグによる列レベルのアクセス制御
採用方針：ポリシータグによる列レベルアクセス制御
今回は ② BigQuery のポリシータグを活用 した列レベルのアクセス制御を採用しました。
理由は以下の通りです。
-
Dataform 導入の知見不足
- Dataform の導入・設計・運用ルールを整備するには一定の準備期間が必要であり、セキュリティ対策として即応できる段階ではありませんでした。
-
セキュリティ対策の緊急性
- Datastream により生データが自動連携されるため、早急な閲覧制御が必要でした。
- そのため、BigQuery 側で即時に対応できる ポリシータグによる制御方式 を採用しました。
BigQueryのポリシータグによる列レベルのアクセス制御とは？
BigQuery には、ポリシータグ（Policy Tag） というセキュリティ機能があります。
これは IAM 権限に基づき、列単位でデータ閲覧を制御できる仕組み です。
具体的には、カラムごとに「この情報は誰が見られるか」を定義し、
機密情報（例：メールアドレス、電話番号、生年月日など）を含む列へのアクセスを制限します。
設定手順（GUI 操作）
-
BigQuery Data Policy API を有効化
- Google Cloud Console にアクセス
- 「APIとサービス」→「ライブラリ」から
BigQuery Data Policy API を検索し、「有効にする」をクリック - API名：
bigquerydatapolicy.googleapis.com
-
ポリシータグを作成
- 左メニューの 「ポリシータグ」 を選択
- 「分類を作成」ボタンをクリック
- 以下を設定
-
リージョン：データセットと同一のリージョンを指定（例：
asia-northeast1） -
分類名 / ポリシータグ名：管理目的がわかる名前（例：
personal_info）
-
リージョン：データセットと同一のリージョンを指定（例：
-
テーブルにポリシータグを付与
- 対象テーブルを開き、「スキーマ」タブを選択
- 編集モードに切り替え、該当カラムにチェックを入れる
- 「Add Policy Tag（ポリシータグを追加）」をクリック
- 適用するポリシータグを選択し保存
-
マスキング設定（任意）
- ポリシータグ管理画面の「ポリシーデータを管理」から
データマスキング（Data Masking Policy） を追加設定可能 - ただし、組織配下のプロジェクトでのみ利用可能 なので注意。
- ポリシータグ管理画面の「ポリシーデータを管理」から
運用上のポイント
- IAMロール（例：
roles/bigquerydatapolicyUser）を使って権限を明確化する - テーブル更新時にスキーマが変更された場合、ポリシータグ再付与が必要
- 機密情報を含むカラムには、付与ルールを事前に定義して統一運用する
Cloud Run Functions + Cloud SchedulerとDatastreamの役割分担
よくある疑問：「なぜ 2 つに分けているの？1 つにまとめた方がシンプルでは？」
この疑問はもっともです。
しかし結論から言うと、分けるべきです（No）。
理由は、Cloud Run Functions + Cloud Scheduler と Datastream が
それぞれ「得意な処理領域」と「苦手な処理領域」を持っており、
両者を組み合わせることで リアルタイム性 × 柔軟性 × 安定性 を両立できるためです。
Datastream の特徴と課題
Datastream は、Cloud SQL → BigQuery 間で変更データをリアルタイムに連携できる強力な CDC（Change Data Capture）ツールです。
しかし以下のような課題を持っています。
| 項目 | 説明 |
|---|---|
| スキーマ変更に弱い | カラム型変更（例：STRING → INT など）など互換性のない変更があると、ストリームが停止してしまう。 |
| データ加工ができない | データはそのまま転送されるため、マスキングや整形、ロジック挿入は不可。 |
| 再同期コストが高い | ストリームが停止した際のリカバリや再構築に手間と時間がかかる。 |
そのため、Datastream ではデータマスキングなどの加工処理は行えず、
まずは BigQuery 上に「生データ」をそのまま連携する必要があります。
Datastream は「リアルタイム転送」に特化しているため、
以下のようなテーブルやデータ構造には不向きです。
| 分類 | 具体例 | 理由 |
|---|---|---|
| スキーマ変更が頻発するテーブル | マスタ系 | カラム追加・型変更が起こりやすく、ストリーム停止のリスクが高い。 |
| 個人情報や機微情報を含むテーブル |
users, user_profiles, accounts など |
Datastream はマスキング処理を行えないため、生データがそのまま転送される。 |
| 一括更新・削除が多いテーブル | 定期メンテナンスで大量更新されるテーブル | binlog が膨大になり、Datastream 側で負荷・遅延が発生する可能性がある。 |
| スナップショット形式の履歴テーブル | 日次・月次で全件更新するテーブル | CDC のメリットが薄く、コスト・パフォーマンスが悪化する。 |
このようなケースでは、
Cloud Run Functions + Cloud Scheduler でのバッチ転送や整形処理の方が適しています。
Cloud Run Functions + Cloud Scheduler の特徴
一方、Cloud Run Functions は「サーバーレスで柔軟にロジックを実行できる関数基盤」であり、
Cloud Scheduler と組み合わせることで、定期・条件付きのデータ処理 が可能になります。
| 項目 | 説明 |
|---|---|
| スキーマ変更に強い | カラム追加や型変更を関数ロジック内で検知し、動的に分岐処理できる。 |
| データ加工が可能 | 取得・変換・マスキング・整形などの自由なロジックを実装できる。 |
| 低頻度データに最適 | 日次・週次など定期バッチで十分なデータに対してコスト効率が高い。 |
この構成を採用することで、マスキング済みの安全なデータを BigQuery に転送できます。
役割分担の考え方
両者の特性を活かし、処理対象を「得意領域」に分けて運用しています。
これにより、リアルタイム性・柔軟性・安定性 のバランスを最適化しています。
| 項目 | Cloud Run Functions + Scheduler | Datastream |
|---|---|---|
| 得意領域 | 柔軟な変換・整形・スキーマ変更対応 | リアルタイム連携・高頻度更新 |
| リアルタイム性 | △（スケジュール実行） | ◎（即時反映） |
| スキーマ変更への耐性 | ◎（動的処理可能） | ×（停止リスクあり） |
| 処理コスト | 低（実行単位課金） | 高（常時稼働） |
| 用途例 | マスタ系・構造が変わるデータ | 行動ログ・頻繁に更新されるデータ |
運用方針
-
Datastream
- Cloud SQL のユーザーデータ・行動ログなど、更新頻度が高くスキーマが安定しているテーブルを対象。
- 変更をリアルタイムに BigQuery の raw 層へストリーミング連携。
-
Cloud Run Functions + Cloud Scheduler
- マスタテーブルやアカウント情報など、更新頻度が低いがスキーマ変更が発生しやすいデータを対象。
- 日次・週次バッチで Load Job を実行し、安全に転送・加工・マスキングを実施。
最後に
今回紹介した Datastream や Cloud Run Functions を中心としたデータ連携基盤の整備は、
単なる技術選定ではなく、プロダクトを継続的に成長させるための「土台づくり」です。
セキュリティやインフラの整備は、一見すると裏方の作業に見えますが、
実際にはプロダクトの信頼性・スケーラビリティ・開発スピードを支える最重要領域です。
脆弱な基盤の上では新しい機能も安心して展開できず、分析の正確性や意思決定のスピードも損なわれます。
だからこそ私たちは、セキュリティ・品質・拡張性のバランスを保ちながら進化し続ける体制を維持することを重視しています。
今後も、技術変化に感度高く対応しながら、より安全で信頼性の高いデータ基盤を磨いていきます。
また、次のフェーズとしては、
「誰もが安心してデータを活用できる環境」の実現を目指しています。
これまで分析やレポート作成はエンジニア依存で、データ抽出や加工に時間を要していましたが、
今後は Dataform によるクエリ管理の体系化 や AI 駆動によるクエリ自動生成・レビュー支援 を進め、
非エンジニアでも自立的に分析できる環境を整えていきます。
この取り組みは、弊社の AI駆動開発チーム と連携しながら進行中であり、
「クエリ生成の自動化」「レビュー支援」「分析知識の民主化」を目指した次のフェーズとして、
別の記事で詳しく紹介していく予定です。
ここまで読んでいただき、ありがとうございます。
本記事が、同じようにデータ基盤やセキュリティ整備に取り組む方々の一助になれば幸いです。
Discussion