Supabaseが管理するFly Postgres
(supabase.com)- SupabaseとFly.ioによるマネージドPostgresの協業は、Flyのインフラ上でSupabaseのデータベース機能を使えるようにする試みだったが、現在は廃止されている
- このサービスは、Fly.ioの37以上のロケーションで稼働するエッジコンピューティング環境にPostgresを配置し、Flyアプリケーションとデータベースをより近くに置く構成を目指していた
- 機能範囲には、40以上の拡張機能、pgvector、Supavisor、日次バックアップ、ポイントインタイムリカバリ、ブランチング、可観測性、マイグレーション、ダッシュボード、REST・GraphQLの自動生成APIまで含まれる
- 初期展開は段階的に進められ、課金・サポート移管・社内トレーニングなどの企業間統合作業と、初期テスターからのバグ修正が残っていた
- Flyの既存Postgresがユーザー自身で運用責任を負うアンマネージド型である一方、Fly PostgresはSupabaseがスケーリング・バックアップ・レプリケーション・アップグレードを担うマネージドサービスだった
リリース状況とサービス範囲
- Fly Postgresは現在廃止されており、詳細は廃止告知で確認できる
- SupabaseとFly.ioは、Flyインフラ上で動作するマネージドPostgresサービスとしてFly Postgresをリリースした
- データベースはFly.ioのエッジコンピューティングプラットフォーム上で実行され、Fly.ioの37以上のロケーションから選んで開始できる
- Flyにデプロイされたデータ集約型アプリケーションは、データベースを同じインフラ内に置くことで、より低いレイテンシを期待できる
SupabaseマネージドPostgresの機能
- Fly Postgresは、Supabaseのマネージドデータベースに期待される主要機能をFly環境に提供する
- Supabase Postgresの40以上の拡張機能
- pgvectorベースのVector/AIワークロード対応
- SupabaseのPostgresコネクションプーラーであるSupavisor
- 日次バックアップとポイントインタイムリカバリ
- ブランチング、可観測性、マイグレーション
- データベース管理用ダッシュボード
- 自動生成Data API
- PostgRESTを使うREST API
- pg_graphqlを使うGraphQL API
段階的ロールアウトと初期テスト
- リリースは段階的ロールアウトとして進められた
- 企業間統合には、課金、サポート移管、Supabase社員のトレーニングなどの作業が含まれる
- 一部の初期テスターと検証中で、修正すべきバグが残っていた
- テスト参加希望者はwaitlistに登録できた
- 翌月にはより多くのテスターを受け入れる予定で、データ安全性に確信を持った後で追加のリリース日程を共有する予定だった
マネージドPostgresとアンマネージドPostgresの違い
- Flyの既存のPostgres提供方式はアンマネージドである
- ユーザーがスケーリング、ポイントインタイムバックアップ、レプリケーション、メジャーバージョンアップグレードなどを自分で処理する必要がある
- Supabaseが運用するFlyのマネージドPostgresでは、ユーザーはアプリケーション構築により集中できる
- マネージドサービスはFly extension APIで作られている
- 同じAPIはFly Redisにも使われている
- テスターは
fly extensionsコマンドでPostgresデータベースを作成できたfly extensions supabase create
- サービスが安定すれば、
postgres名前空間に置き換えられる予定だったfly postgres create
Fly Machinesベースの実装
- Fly PostgresはFly machines上に構築されている
- Machinesは軽量なFirecracker VMであり、Machines APIはアプリケーションのライフサイクルを細かく制御する
- Machinesは非アクティブ状態で停止でき、新しいリクエストが来ると数秒以内に再開できる
- SupabaseはFly APIとのやり取りを単純化するため、fly-adminというTypeScriptラッパーを作成した
- SupabaseはPostgresにいくつかの追加サービスをバンドルするため、Fly Machines APIに渡せる単一のDockerイメージを用意した
- 既存のビルドプロセスではPackerでAWS用AMIを作成しており、このパイプラインの一部を再利用してAll In One Imageをビルドした
- All In One Imageは、単一のDockerコンテナ内にSupabaseプロジェクトの実行に必要なすべてのサービスを含む
マルチクラウドへの移行
- このリリースにより、Supabaseは正式にマルチクラウドになった
- Supabaseはマルチクラウド移行を単純化するため、AWSのマネージドサービスを意図的に避けている
- クラウドプロバイダーごとに基本プリミティブが大きく異なるため、移行は単純ではない
- Fly Machinesは、使われていないVMを停止し、数秒以内に透過的に再開する方式を提供する
- 非アクティブなデータベースを一時停止するプロセスが単純になる
- AWSにはこれを直接実現するプリミティブがない
- 逆にFlyにはAWSが提供する一部のプリミティブがなく、回避策が必要になる
- Fly Machinesにはネットワーク接続ストレージがない
- SupabaseはFly volumes上のデータを一時データとして扱う
- Flyで実行されるすべてのプロジェクトについて、WAL-Gで物理バックアップを実行する
- データベースの変更はS3へ継続的にストリーミングされる
- ホストやボリュームの破損が発生した場合、最新のS3データを使って新しいFlyホストにプロジェクトを復元する
運用の可観測性とイメージ配布
- AWSではホストの問題を検知するためにAWS Health eventsを受信する
- FlyではMachineログをfly-log-shipper経由でLogflareへ送る
- SupabaseはAWSコンテナレジストリだけでなく、Fly DockerレジストリにもAll In Oneイメージを公開する
- Fly Dockerレジストリへの公開により、Flyでプロジェクトを起動する際の信頼性と性能が向上する
Fly拡張と認証統合
- Flyはプラットフォーム拡張のためのExtensions APIを提供している
- Supabaseはユーザーとプロジェクトをプロビジョニングするため、APIにいくつかのルートを追加した
- Flyユーザーは既存のFly認証情報でSupabaseダッシュボードにアクセスできる
- Supabase APIはユーザー認証のためにFlyとのOAuthフローを開始する
- Supabase AuthチームはAPI統合を容易にするため、Fly OAuth providerを作成した
残された課題
- SupabaseはFlyチームとともに、いくつかの運用課題に引き続き対応中だった
-
ネットワーク制限のサポート
- ネットワーク制限機能は、コンテナが接続クライアントの正しいIPを受け取る必要がある
- 現在の構成では、コンテナはクライアントIPではなくFly proxy IPを見る
- 接続はProxy protocolを公開するFly proxyを通過する
- Postgresはこの情報を直接利用できず、SupabaseはSupavisorにproxy-protocolを認識させる方法を検討中である
-
Fly内部バックアップ
- FlyはまだマネージドBlobストレージを提供していないため、FlyプロジェクトのバックアップはAWS S3に対して行われる
- この方式はクラウド間の帯域幅コストを発生させる
- FlyはBlob Storageに取り組んでいる
始め方と価格
- プレビュー申請はpreview formから行えた
- 組織が許可リストに追加されると、ドキュメントのQuickstartから始められた
- Fly組織は無料プロジェクトを1つ受け取れる
- 課金に関する詳細はまだ作業中だったが、価格は現在のSupabase価格と比べて大きく変わらない予定だった
1件のコメント
Hacker Newsの意見
SupabaseのCEOです。Flyの現在のPostgresは非マネージドなので、Flyと一緒にマネージドサービスを運用できるよう作業中です。
これはFly RedisでUpstashチームとやっているモデルと同じです: https://fly.io/docs/reference/redis/
まだテスター向けに高可用性機能を展開している最中で、確定した日程はありませんが、Flyチームとできるだけ早く進めます
他社の非ホスティングサービスをホスティング版として管理するために、外部企業が入って協業する例はあまり聞いたことがありません
以前Supabaseを見てみたのですが、基本のREST APIをどう作るのかが分かりづらかったです。
テーブルを作るとやり取り用のAPIを自動生成してくれるのはよさそうですが、ではビジネスロジックはどこに置けばいいのか分かりませんでした。
Edge Functionsも見ましたが、例がジョブ処理寄りで、その用途で使えということなのかが明確ではなく、何か単純なことを見落としている気がします
REST APIはJOINのようなデータ集約にはかなり便利ですが、トランザクションのようなものが必要になった瞬間に行き詰まり始めました。
ロールベースアクセス制御のための行レベルセキュリティ(RLS) も煩雑で、開発者体験はいまひとつでした。
DB要件が単純ならREST APIは非常に便利ですが、複雑なものを想定しているなら、PL/pgSQLを学ぶか通常のDB接続を使うほうがよいです
たいていは1番で十分で、2番と3番は必要なときに使う追加ツールに近いです
多くのユースケースではロジックをSQLストアドプロシージャに入れられますし、PostgreSQLではJSやPythonのストアドプロシージャも可能です。
ただし、ロジックコードは通常のCI/CDコンテナや関数としてデプロイするほうが開発者体験は良く、コストとのトレードオフ次第で両方よく使われます。
SupabaseはDenoサーバーレス関数を推していますが、Webプロジェクトなら大半はCloudflareにNode関数をデプロイするほうを好む気がします。
結局のところ、対象顧客はロジックの99%をJSフロントエンドに置き、バックエンドではCRUDと認証だけを処理したい層に見えます
その部分はPostgres WALベースのイベントシステムを作って、コールバックシステムのように処理しました。
もともとSupabase Realtimeをforkして始めた、Elixir向けの小さなライブラリも作りました: https://github.com/cpursley/walex
最近は、Elixirを知らなくても済むように、WalExがイベントをWebhookやEventRelayに配信するよう設定できる機能を追加しました
Next.jsを使っているので、DB呼び出しのかなりの部分はNextのサーバーレス関数内にあります。
ただ、できるだけDBに近づけるために、一部のロジックをSupabase関数へ移すことも検討するつもりですが、まだDenoへ移したいとは思っていません。
サーバーからSupabaseへアクセスするときは、Supabaseクライアントが使うPostgREST機能を使うか、一般的な
pgライブラリでPostgresへ直接アクセスすればよいですこれへ移行できるのを楽しみにしています。Fly.ioとFly Postgres上でBookletを構築しながら、アプリを分散型に設計してきました: https://www.contraption.co/essays/booklet-architecture/
最大の問題はFly Postgresの設定でした。特にFlyがPostgresの前段にHAProxyを置き、30分の接続制限をかけて接続を切り続ける点です: https://community.fly.io/t/postgresql-connection-issues-have...
管理可能であるべき問題ですが、接続終了の挙動がドキュメントと一致しない妙な点があり、ずっと不安定でした。
新しいPostgresでも前段に同じHAProxyを置くのか気になります
https://supabase.com/blog/supavisor-postgres-connection-pool...
https://postgrest.org/
今日Flyのドキュメントでこれを見て、HNで見落としたのかと思いましたが、新しく出たものだったようです。
次に思ったのは、サイドバーにPostgres by FlyとPostgres by Supabaseが並んでいるのが奇妙だという点です。
目立つ比較もないので、FlyにアプリをデプロイしてPostgresが必要な場合に何を使うべきか分かりづらいです。
個人的には、FlyでDBMSが必要ならLiteFSの分散SQLiteを使うと思いますし、Postgresが必要ならFlyとSupabaseの違いは実質的に非マネージドかマネージドかだと見ています
とても良い。Supabaseのネットワーク制限設定はあまり好きではなかった: https://supabase.com/docs/guides/platform/network-restrictio...
以前見たときは、FlyアプリのIPをSupabaseに公開してSupabaseをそのIPでロックするのに妙な問題があったように記憶している
Supabaseが実際にFlyネットワーク内に入ってくるのは素晴らしい
Fly.ioのネットワーキング文書にも書かれている
Supabaseはプロトタイプを超えるとスケーラビリティの問題があると聞いたが、プロダクション経験のある人が話してくれるとありがたい
具体的にはどんな問題のこと？
Fly.io側のJoshuaです。この統合について質問があれば答えます
サイドプロジェクトいくつかでは使っているが、まだ大きなプロジェクトでは使っていない
次に欲しいのはBlobストレージだが、状態を持つものは基本的にマネージドで使いたいので、その作業も進んでいると聞けてうれしい
新しいPostgres提供の価格について詳細があるのか気になる
現在Flyで大きなDBを動かしていて、マネージドPostgreSQLを探しているので、この知らせはとても歓迎
私たちは完全なElixirチームなので、これ以上ないタイミング
“Fly machines don't have network-attached storage, so we treat any data in Fly volumes as ephemeral.”
AWSを使ったことがなく、ネットワーク接続ストレージもあまり分からないので、Flyボリュームと他のプロバイダのネットワーク接続ストレージが正確にどう違うのか気になる
Flyボリュームを作ると、同じリージョンの別のサーバーへ移せた気がするが、だとすると技術的にはネットワーク接続ストレージではないのか？
内部的には、ボリュームをある物理ホストから別の物理ホストへ移すことはでき、その仕組みはかなり興味深いが、まだ公開にはあまり出していない
今年はそれをもっと表に出していく予定
Fly Volumesは定期的にオフネットワークのブロックストレージへバックアップしており、これに関する発表も近いうちにさらにある予定
基本的に理解すべきなのは、Fly VolumesはSANストレージではなく、S3のように本質的に信頼性の高いストレージでもないということ
Fly Machinesの中では単なるext4ファイルシステムとして見え、信頼性・耐久性・レプリケーションが必要ならアプリケーション層で提供しなければならない
Fly Postgresは読み取りレプリカのクラスターとして動作し、必要であればどのレプリカでも書き込みリーダーの役割を引き継げるので、そのやり方が適している
単一ノードのPostgresクラスターを作ろうとするとコンソールに大きな赤い警告を出すのもこのため
今後数四半期のうちに、信頼性と性能のスペクトラム上で新しい選択肢を出してくると思うが、iSCSIのような方式でブロックデバイスだけを公開するSANドライブを自前で運用する形にはならないだろう
この2社の価格モデルは本当に嫌い
一方の端にはSupabaseがあり、Vercelのような開発者プラットフォーム式の階層型商品で、実際の使用量より多く払わせる構造になっている
もう一方の端にはFlyがあり、Lambdaのように秒単位・メモリ単位・CPU単位で過度に細かい価格設定なので、おそらく払う額が少なすぎて性能低下を受ける可能性がある
Cloudflare Workersのようなものがあるのに、なぜそのどちらかを選ぶのかよく分からない。なぜまだスケールを心配したいのか？
Cloudflareが本物のPostgresを提供する可能性も低そう。Cloudflareの哲学は、デプロイするものはすべて世界中に配備されるという方向だが、リレーショナルデータベースは単一サーバーを真実の源として強制するから
もちろん間違いだと証明されるなら歓迎
Flyの月額料金はかなり直感的で、Lambdaとはまったく似ていない。むしろその2つの中ではCloudflare Workersの価格モデルのほうがLambdaに近い