PlanetScaleの制限と採用しなかったはなし
はじめに
新規プロダクトの技術選定においてPlanetScaleが候補に挙がりましたが、最終的に採用を見送りました。本稿ではこれまでの調査結果を供養するとともに、PlanetScaleの採用を検討されている方に向けて多少参考になればと思い記しております。
新規プロダクトの要件
新規プロダクトの要件として大きく以下が挙げられます。
- 開発スピード（狙った時期にローンチしたい）
- ローンチ後の想定会員数の増加はゆっくりめ。いきなり百万人は目指さない。
- 開発者体験の良さ。具体的には運用に手間がかからず、デプロイを自動化する
不採用の理由
上記要件を踏まえて調査を進めた結果、以下の理由で不採用となりました
- 分散DB特有の制限によりアプリ側の開発ボリュームが増加する
- 想定会員数に対してオーバースペックすぎる
- 一部のデータに求められる整合性要件が満たせるか調査しきれなかった
PlanetScaleとは
PlanetScaleは、MySQL互換のサーバレス分散データベースです。Vitessを基盤とし、高いスケーラビリティと可用性、ブランチ開発のようなスキーマ管理を提供します。
Vitessとは
Vitessは、Googleが開発しOSS化したMySQL用のスケーリングミドルウェアです。シャーディングやレプリケーションを自動で管理することで、MySQLに可用性とスケーラビリティを提供します。GoogleではYouTubeのデータ基盤として使われていました。
PlanetScaleの制限
前述した通り、PlanetScaleには単一インスタンスによるDBでは考えられないようないくつかの制限があります。
外部キー使用不可
PlanetScaleはデフォルトで外部キーを使用することができません。外部キーの使用を許可することは可能ですが、シャーディング等Vitessが提供する機能の一部が使用できなくなります。
シャードキーの管理が必要
各テーブルへのINDEX管理に加えて、シャードキーを適切に設定する必要があります。シャードキーとは、設定されたカラムの値が同じもの同士を同一シャードへまとめておくことにより、データ取得の際に複数シャードを参照しないようにするためのキーです。
複数シャードにまたがる結合のパフォーマンス低下
結合するテーブルが複数のシャードにまたがる場合、パフォーマンスが著しく低下するとされています。この制限は前述したシャードキーを適切に管理することで影響を軽減できます。
非同期更新に伴う楽観的UI更新が必要
複数のシャードへレプリケーションする際にタイムラグがあることで、画面の見え方が変わる可能性があります。データ登録時に楽観的UI更新を用いて、データの更新が完了した際にDBのデータと差し替えるなどの処理がUIに求められます。
PlanetScaleの良かった点
一方で良かった点もいくつか見つかりました。ここではPlanetScaleの良かった点について説明します。
ブランチ単位でのスキーマ管理
スキーマをブランチ単位で管理することができます。developブランチ（開発環境）に開発時点でのカラム変更やスキーマ追加をして確認し、問題なければmainブランチ（本番環境）へ変更を反映するということができます。
分散環境としての高い耐障害性
データベースを作成した時点で（内部的に）シャード化された分散環境が構築され、それをVitess（VTGate）が管理するという形になります。特別な設定をすることなく、高い耐障害性を持つ分散環境が利用可能です。
Terraform Ready
Terraformのproviderが用意されているので、PlanetScaleの構成もコードで管理することが可能です。
PlanetScaleがどのようなプロダクト・チームにフィットするか
以下のような要件を満たしたい場合はPlanetScaleがフィットする可能性があります。
マイクロサービスアーキテクチャを採用予定で、テーブル間のデータ整合性が緩やかである場合
テーブル間のデータ整合性や制約が緩い場合、PlanetScaleの制限にとらわれることなく使用できると感じています。
多くのメンバーが開発し、DBの変更が複数発生し得る
ブランチ管理を行うことで一旦開発ブランチにDBの変更は集約されます。ここで衝突の回避や修正を行えるため、DB変更が多岐にわたった場合でも管理しやすいのではないかと思っています。
まとめ
上記を踏まえ、今回はPlanetScaleの採用を見送りました。しかしながらプロダクト自体は素晴らしいものであると感じたので、本記事が遠い誰かの役に立てれば幸いです。
参考URL
Discussion