はじめに

こんにちは、FANTECH本部の前田(@arabian9ts)です。
以前、マルチリージョンで稼働する内製Feature Flagsの実装にて内製したFeature Flagsシステムについてご紹介しました。
当時は、SQLite+Litestreamで構成されていましたが、その後の状況変化に応じて、Cloud Storage FUSEとCloud Runを利用した構成へと移行しました。
移行後から半年以上が経過し、安定稼働しているため、どのような構成になったのかを簡単にご紹介したいと思います。

Feature Flagsのシステム特性

Feature Flagsは、ユーザーからのデータ書き込みはなく、プロダクトを運用するエンジニアないしPMのみが変更の書き込みを行います。
つまり、Read Heavyなシステムとなります。そのため、一定の反映ラグを許容できる場合、中央集権的なDBを持つのではなく、分散したキャッシュを持つインスタンスをスケールアウトさせる方がパフォーマンスが上がります。

本記事で共有する構成についても、同様のシステム特性となるため、ユーザーからの書き込みがない前提でのシステム構成を採ります。

以前の構成

以前紹介した旧構成でも、同様の思想でCloud StorageにアップロードされたSQLiteのバックアップをCloud RunインスタンスでRestoreして利用していました。
このFeature Flagsシステム構築後、Litestreamの作者がFly.ioにてLiteFSというプロジェクトを新規にはじめ、Litestreamは新規開発ではなくメンテナンスフェーズへと移行しました。
その後、LiteFSの提供が開始され、Cloudflare D1など分散SQLiteのようなシステムに一時期注目していましたが、残念ながらLiteFSはすぐにサービス終了の意思決定がなされたようです。
https://community.fly.io/t/sunsetting-litefs-cloud/20829

また、Cloud Storage FUSEをCloud Runで利用することで同様のニーズが満たせるようになり、そちらへの移行を決めました。

新しい構成

Litestreamで管理していたSQLiteのバックアップを、シンプルなJSONファイルに変更しました。
また、JSONファイルをCloud Storage FUSEを用いてCloud Runにマウントし、アプリケーション内からJSONファイルをネットワーク越しに読み出すことで、インスタンス内のキャッシュを構成します。
定期的にStatを行い、最終変更日時を取得します。変更日時に変更があった場合は、新しいリビジョンのJSONをネットワーク越しに読み出し、インスタンス内のキャッシュを更新します。

技術的な制約

以下のリポジトリに、Cloud Storage FUSEを利用する場合の技術的な制約についてまとめられています。
https://github.com/GoogleCloudPlatform/gcsfuse/blob/master/docs/semantics.md

特に、Cloud Storage FUSEは、デフォルトでいくつかのキャッシュが有効になっているため、ユースケースに合わせて確認が必要です。
Stat結果のキャッシュはデフォルトで有効になっているため、Feature Flagsの変更を即時反映させたい場合は注意が必要です。
https://cloud.google.com/storage/docs/cloud-storage-fuse/caching#stat-cache-overview