SEIRO IWAMOTOFUKUOKA 33.59°N / REMOTEREV 2026.07
SHEET FIG.2 — /work/bigdata-saas
CASE STUDY § 01-2

ビッグデータ SaaS 基盤

2023–25 / インフラ / データ基盤エンジニア / Go · Python · GKE · Cloud Composer (Airflow) · Datastream · BigQuery · Spanner · Cloud Run · Workflows
2 年継続
TERM
移行 · 基盤構築 · 運用
SCOPE
GCP (GKE · BigQuery)
PLATFORM

課題

SaaS のデータ基盤は、扱うデータ量とトラフィックが増えるほど運用の手数が増える。クラスタの管理、日次処理の安定運用、分析基盤へのデータ連携が、それぞれ個別の負荷を持つ。

既存の GKE クラスタはノード管理を手動で行う構成で、運用の手間とスケール調整が継続的な負担になっていた。加えて、業務データ (MySQL) を分析基盤 (BigQuery) に届ける経路と、日次処理パイプラインの安定運用が求められていた。

設計判断

  • GKE を Manual 運用から Autopilot へ移行することを検討し、運用負荷とコストの両面を評価した上で実施
  • 業務データの分析基盤への連携は Datastream 経由で MySQL→BigQuery をつなぐ構成とし、連携の遅延と整合性を運用対象に含めた
  • 日次パイプラインは Cloud Composer (Airflow) で構築し、依存関係とリトライを明示的に管理
  • 新規処理の実装前に Workflows・Cloud Run を PoC で評価し、用途への適合を確認してから採用可否を判断
  • 監視は基盤・パイプライン・データ連携の各層で設計
GKE AutopilotMySQLDatastreamBigQueryCloud Composer

ノードにカーソル・フォーカス・タップすると、各要素の設計判断が表示されます。

  1. アプリ実行基盤。Manual 運用から移行し、運用負荷とコストを評価した上で Autopilot 化。
  2. 業務データの源泉。分析基盤への連携元。
  3. MySQL→BigQuery の連携を担う。連携の遅延と整合性を運用対象に含めた。
  4. 分析基盤。連携されたデータの集約先。
  5. 日次パイプライン。依存関係とリトライを Airflow で明示的に管理。
FIG. 2-A — ビッグデータ SaaS 基盤

進め方

  • 移行は検討フェーズで運用・コストの影響を評価し、段階的に実施した
  • 構築した基盤はそのまま運用フェーズへ引き継ぎ、2 年間の継続参画の中で監視と改善を続けた
  • 新規技術は PoC 評価を挟んでから本採用する手順を取った