はじめに

こんにちは。私はRSSでデータ分析基盤のエンジニアをしているY.R.です。

私の所属するチームではデータ分析基盤を運用しています。
チームとしては2024年10月に以下の記事を出しています。

データ分析基盤チームの紹介と取り組み内容

データ分析基盤チームの紹介と取り組み内容

この記事の最後に以下のような記述があります。

「Cloud Composer」をETLプロセスの実行ツールとして活用しているものがあります。これは学習コストを最小限に抑えることを重視した結果ですが、Cloud Composerはあくまでもオーケストレーションツールであり、本来はETLジョブを構成するタスクを管理するのに適したサービスであるため、当該用途での使用は適切ではありません。」

今回はこの技術的負債解消のお話です。

課題

改修に至った背景には、いくつかの理由があります。主な課題として、以下の3点が挙げられます。

1. 運用負荷が高い
2. 利用頻度と依存関係の単純さの割には高いコスト
3. スケーラビリティへの備えが難しい

課題1. 運用負荷が高い

従来はスパイク状の負荷の発生によってAirflowサーバーがダウンすることがあり、その復旧に手間がかかるため、処理を安心して任せられない状態でした。
Cloud Composerは、裏側で複数のGoogle Cloudサービスが連携しています。
具体的にはGKE、Cloud SQL、App Engineなどが利用されています。それゆえ、エラーの原因特定と復旧が毎回困難でした。
復旧するまで、Cloud Composerによる200を超えるデータ処理がすべて停止しました。

課題2. 利用頻度と依存関係の単純さの割には高コスト

Cloud Composerはデータパイプライン用途でのみ使用していました。
しかし、BigQuery全体のコストとCloud Composer単体のコストは同程度でした。
Composerで管理するテーブルは300前後です。
一方、BigQuery全体のテーブル数は6000以上でした。この差を考慮すると、局所的にコストがかかりすぎていることがわかります。
複雑なパイプライン処理や高い利用頻度であれば許容できます。しかし、私たちの利用状況はそこまでではありませんでした。
にもかかわらず、インスタンスを常時起動する必要があり、費用が高止まりしていました。