はじめに

こちらはバイセルテクノロジーズAdvent Calendar 2023の7日目の記事です。

前日のバイセルアドベントカレンダー2023は小松山さんの「Cloud RunのDirect VPC Egressを使おうとして断念した」でした。

こんにちは。テクノロジー戦略本部、開発一部に所属している那仁です。 2023年に新卒入社し、買取管理システムGYROというサービスを開発・運用しています。

私は2023年の夏頃、GYROで利用されていたDataflowをBigQueryサブスクリプションに移行するプロジェクトを進めていました。

今回は、その過程や移行してみてどうだったかの話を書きます。同様の移行を検討しているエンジニアの方々に役立つ情報を提供できれば幸いです。

はじめに
背景
BigQueryサブスクリプション
移行方法
結果
まとめと感想

背景

GYROはバイセルの買取管理システムとして日々稼働しているサービスです。バックエンドにはRuby on Rails、インフラはGoogle Cloudを利用しています。

GYROではどのユーザーがどのAPIをいつ実行したのか？のようなユーザーデータをBigQueryに保存しています。 BigQueryにデータを取り込むためにDataflowを利用しており、Pub/Sub → Dataflow → BigQueryの構成を取っていました。

今回このDataflowのSDKバージョンがEOLになってしまうことが分かったので、対処する必要がありました。また、DataflowのSDKはEOLになる頻度が高い上に、動作が不安定だったりしたこともあり代替案を検討することになりました。

そこで調査したところ、Pub/Subに代替機能としてBigQueryサブスクリプションが追加されていることが分かりました。

これは、Dataflowを介さずにPub/Subから直接BigQueryにデータをエクスポートできる機能です。

思い切ってBigQueryサブスクリプションに移行できるのでは？と調査を進め、移行に向けて動き出したことが背景となります。

BigQueryサブスクリプション

Pub/SubのBigQueryサブスクリプションは2022年7月に発表された新しい機能です。

従来、Pub/SubからデータをBigQueryに取り込むためには間にDataflowを挟む必要がありました。

BigQueryサブスクリプションを活用することで、Pub/SubからBigQueryにメッセージを直接書き込めるようになります。これを利用するには、BigQueryのテーブルのスキーマとPub/SubのTopicのスキーマが、一致している必要があります。

幸い、GYROは両者が同じスキーマ構成だったためBigQueryサブスクリプションを利用できます。

ただし、BigQueryにデータが保存されるまでにデータ変換などの追加の処理が必要な場合は、Dataflowが推奨されています。

DataflowからBigQueryサブスクリプションに移行することで、Dataflowの管理コストを無くすことができ、構成がシンプルになります。また、移行後の方が費用を抑えられます。

これらのメリットを享受できるので、移行する価値は大いにあると判断しました。

移行方法

実際に移行するにあたって、GYROは運用プロダクトでもあるので現状の仕様の調査から入りました。その後、BigQueryサブスクリプションを実際に触りながら本番環境での移行作業のための手順書を作っていきました。

（1）GYROでPub/Subトピックに保存している処理を見つける

バックエンドの全APIの前処理の部分で、Pub/Subにユーザーデータを送信している処理がありました。 Pub/SubのTopic名は環境変数として設定されています。移行するにあたって新しいTopicを作成し、環境変数を切り替える方針を取りました。

（2）Google Cloudの練習環境でBigQueryサブスクリプションを触ってみる

BigQueryサブスクリプションがどのようなものかを理解するために、Google Cloudの練習環境でとりあえず触ってみることにしました。バイセルにはGoogle Cloudの練習用アカウントがあります。

BigQueryサブスクリプションの公式ドキュメントがあり、これに沿ってGoogle Cloudコンソール上で作業を進めます。スキーマはGYROのBigQueryで実際利用しているユーザーデータと同じスキーマでBigQueryのデータセットとテーブルを用意しました。 Google Cloudコンソール上でテストメッセージを配信できるので、配信したところ確かにBigQueryサブスクリプションからBigQueryにデータが保存されることを確認できました。

また、色々と触ってみたことでBigQueryサブスクリプションやその周辺知識の理解を深めることもできました。

（3）GYROの開発環境でBigQueryサブスクリプション移行を試してみる

練習環境での検証と経験を踏まえ、GYROで移行する方法を検討していきます。

GYROの開発環境では、本番環境と同様のPub/Sub → Dataflow → BigQueryの構成になっています。先ほどの練習環境での経験を踏まえて、仮の手順書を作成し移行を試してみます。ここでの目的は本番環境における移行のための手順書を確立することです。 GYROは運用プロダクトであるので、可用性を損なうリスクを減らす必要があります。そのため、移行手順書をしっかり作りそれに従って移行作業を実施します。

その際、インフラエンジニアの方とペアプロしながら進めました。実際に画面共有しながらGoogle Cloudコンソールを触りつつ、手順書を一緒に作っていきました。

そして、開発環境において作った手順書で移行できたことを確認し、本番環境で移行のための手順書を完成させました。

以下画像はその手順書の一部になります。

（4）本番環境で移行

いよいよ本番環境での移行に入ります。 BigQueryサブスクリプションを利用する新しいPub/SubのTopicを作成し、アプリケーション側で新Topicを利用するように変更します。 GYROは日々稼働している運用プロダクトであるので、まずは一部ユーザーのみ新Topicにユーザーデータを流すようにしました。その後、問題なく動いていることを確認して全ユーザー対象に移行します。

手順書の流れは大まかに以下のようになりました。

1) 事前にアプリケーションコードで一部開発者ユーザーのみ新トピックを利用する改修のPRを出し、Approveを貰っておく。また、ログから新Topicが利用されたことを分かるようにする。

2) IAM設定: Pub/Subサービスアカウントにbigquery.dataEditorロールを割り当てる。

3) BigQueryサブスクリプション用に新しいTopicを作成する。

4) ユーザーデータのスキーマに従ってトピックスキーマを作成する。

5) 新TopicにBigQueryサブスクリプションを作成する。上で作成したトピックスキーマを指定する。

6) Google Cloudコンソール上でテストメッセージを配信し、BigQueryに保存されていることを検証する。

7) アプリケーションに新Topicの環境変数設定を追加する。

8) アプリケーションコードをマージしてリリースする。

9) GYROの本番環境を適当に操作し、新Topicを経由してBigQueryにユーザーデータが入ってくることを確認する。

10) アプリケーションコードを元に戻して全ユーザーが新Topicを利用するようにする。

11) 実際のユーザーの操作にてBigQueryに新Topicからユーザーデータが入っていることを確認する。

12) アプリケーションに、Dataflowで利用していた古いTopicの環境変数設定を削除する。

この流れに従って移行作業を実施し、無事完了させることができました。

結果

後に2023年の10月時点での料金を計測したところ、BigQueryサブスクリプションに移行したことで月のコストがおよそ$600ほど削減されたことが分かりました。

まず、Dataflowの利用料金が元々月$700ほどかかっていたのが完全に無くなりました。

BigQueryサブスクリプションの料金は、$50/TiBです。 GYROのPub/Sub利用量を踏まえると、差し引き１ヶ月あたり$600費用を削減できたことが分かりました。日本円にして、１ヶ月あたりおよそ10万円の費用削減です。

これには、エンジニアリングマネージャーの方からも激励の言葉を頂きました。

移行後は一度も不具合を出さずに問題なく動いています。 Dataflowをもう見なくても良くなったので、インフラ構成がスッキリしました。

まとめと感想

BigQueryサブスクリプションに移行することで、Dataflowを利用しなくて済むようになります。その分のコストが削減でき、管理も楽になったので移行する価値は大いにあると感じました。

BigQueryのテーブルとPub/SubのTopicのスキーマ定義が同じであれば、簡単にBigQueryサブスクリプションの設定を追加できます。

また、このプロジェクトを通してエンジニア1年目からインフラをがっつり触れる良い経験を積むことができました。

BigQueryサブスクリプションが新しい機能だったこともあり、社内に知見が無く調査して共有するところから始めました。 BigQueryサブスクリプションとはそもそも何かを自分で調べ先輩方に説明するのは大変な仕事でしたが、オーナーシップを持って取り組めた分、非常に良い勉強となりました。

GYROは大きなプロダクトなので、移行するにあたり慎重に進める必要がありました。まず一部ユーザーのみで使用開始するようなカナリアデプロイの方針を取ったり、手順書を複数のエンジニアから手厚くレビューいただきました。実際のエンジニア業務は、本当に多くの観点と人々の協力で成り立っていることを実感しました。

最後に、プロジェクト開始当初からインフラエンジニアの方にはペアプロ等を通して多くのアドバイスを頂きました。改めて感謝申しあげます。