Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

【R&D DevOps通信】CloudSQL(MySQL)で定期的にテーブル洗い替えをするシステムを構築したら思ったよりストレージが必要だった話

研究開発部 Architectグループ ML PlatformチームのKAZYこと新井です。ちなみに名古屋にある中部支店に勤務しています。

今回はCloudSQL(MySQL)で定期的にテーブル洗い替えをするシステムを構築したら思ったよりストレージが必要でしたというテーマです。

結論

まずはじめに結論からをお伝えすると、CloudSQL(MySQL)を複数ゾーン(高可用性)に配置するためにはポイントインタイムリカバリの有効化が必要です。そしてポインイトインタイムリカバリを有効化するとバイナリログが有効化されます。そのためテーブルの洗い替えのような書き込み操作を大量にすることで生まれるバイナリログがストレージ容量圧迫の原因でした。

背景

先日とあるデータソースにあるデータを定期実行でCloudSQLで構築したMySQLに同期するというシステムを構築しました。同期の方法として各テーブルのデータをすべて洗い替えるという方針を取っておりました。

ざっくりとしたアーキテクチャ

データ同期のパイプラインをGCP Workflowsで構築した時の話はこちらで記事にしているのでぜひご覧ください。

buildersbox.corp-sansan.com

今回は開発環境での開発を済ませ、実データを運用する環境でデータベースを構築する段階での話です。

データベースを構築するためにはvCPUやメモリ、ストレージ容量といったインスタンスのスペックを決めなければいけません。vCPUやメモリは後から増減変更ができるのですが、ストレージ容量についてはドキュメントに以下のように記載があり減らすことはできません。

インスタンスの作成後は、インスタンス構成を編集して手動でストレージ容量を増やすことができますが、減らすことはできません。

cloud.google.com

そのため使用量に適したストレージ容量を設定したいと思っていました。

運用に乗せる前に同期予定のデータ量+αの容量でインスタンスを建てて実データで同期してみました。そこで必要だった容量がわかったので、そこに多少の余裕を持たせた値をストレージ容量として設定しました。

問題

次は想定している運用と同様に定期実行で同期をしてみました。すると同期しているデータ量は大きく変わっていないのに容量が足り無くなってしまいインスタンスが止まってしまいました。

原因

バイナリログが原因でした。それなりにレコード数のあるテーブルを定期的に洗い替えているため書き込みログが積み重なって結構な容量になっていました。

mysql> SHOW BINARY LOGS;
+------------------+-----------+
| Log_name         | File_size | 
+------------------+-----------+
| mysql-bin.000000 | XXXXXXXXX |
| mysql-bin.000001 | XXXXXXXXX |
| mysql-bin.000002 | XXXXXXXXX |
| mysql-bin.000003 | XXXXXXXXX |
︙
︙

検討

テーブルに格納しているデータの何倍もの容量をバイナリログが占めている状態ですのでいくつか削減するための検討を行いました。

ログの保存をやめられるか

CloudSQLではバックアップを有効にするとポイントインタイムリカバリというデータ復元機能が使えるようになるのですが、利用するためには1日以上のトランザクションログ(バイナリログ)の保存が必要です。

ポイントインタイム リカバリを使用する  |  Cloud SQL for MySQL  |  Google Cloud

こちらの機能を無効にして定期実行数回分のログだけ保持しておけば良さそうかなと考えました。しかしバックアップやポイントインタイムリカバリ機能は、複数のゾーンで高可用性を実現するために必要な機能でした。本番環境でのシングルゾーン運用は当然推奨されておらず対応候補から外しました。

バイナリログを小さくできないか

現在の同期システムではテーブルを洗い替えているため書き込み量が増えてバイナリログが増えています。差分だけを取ればバイナリログを減らすことができそうだと考えました。差分で更新は同期元のデータから削除された情報の取り扱いが洗い替えより複雑になるため今回は見送りましたが、非常に効果的なので今後取り組んでいきたいと思います。

対応

以下の対応を行うことで無事運用できるようになりました。

  • 複数ゾーンを有効化するためにバックアップとポイントインタイムリカバリを有効化
  • ログの保存期間をデフォルトで入っていた7日から1日に設定
  • ログの削除周期(約24時間~48時間)に耐えられるだけのストレージ容量に設定

おわりに

私個人としては、MySQLのストレージやCloudSQLについてあまり詳しくなかったのですが今回の調査を通して理解が進みました。Cloud SQLにはストレージの自動増量機能があるのでそちらを利用すればストレージが満タンになって落ちるようなことはなさそうですが、原因を理解することでコスト面でも安心できたので良かったです。vCPUやメモリに比べてストレージ容量はコスト最適化という点では寄与は少ないかもしれないですがこの記事がお役に立てば幸いです。

アナウンス

求人情報

私の所属するML Platformチームを含む、研究開発部Architectグループでは一緒に働く仲間を募集しています。最近募集の給与レンジが上がりました。私の所属する中部支社勤務も上がりましたのでオススメです。是非一緒に働きましょう。

hrmos.co

hrmos.co

© Sansan, Inc.