Cloudflare D1とデータベース選びの前提
こんにちは、AI駆動開発部の日常へようこそ。 このポッドキャストは、日々AI駆動開発を行う
企業家の山本とエンジニアの阿部が、 AI駆動開発のリアルを緩く語り合う番組です。
はい、じゃあ本日もよろしくお願いします。 よろしくお願いします。
はい、ちょっと前にね、Cloudflareについて、何が便利なのかみたいな話を
阿部ちゃんにしていただきまして、それが結構 聞かれていてありがたいことにというところで、なので
Cloudflare関連第2弾ということで、 僕は聞くだけなんですけれども、
はい、ちょっと次のCloudflare関連に 行ってみたいと思っております。
じゃあお題としては、そうですね。 Cloudflareを使うとしましたと。
そうなった時のデータベース、何を選んだらいいのかっていうと、 それは何なのかみたいなところとか、
なぜなのかみたいなところとか、いろいろと 実際にCloudflareを阿部ちゃん使ってるっていうところも
あるからこそ、教えてくれるところが あるのかなというふうに思っておりますので、
期待しております。
期待してます。ハードル上げますね。
ハードルを。はい、そんな感じで、 そもそもCloudflareを使うにあたって、
なんでデータベース選びに悩むのか みたいなところとか、その前提の話から
ちょっとしてもらえるとありがたいな というふうに思ってます。
はい。Cloudflare、前回も話したように、 より少数のチームとかとスモールに立ち上げて、
かつそれなりの業務システムとか ウェブサービスを簡単に作れて
運用に乗せることができるような、 しかもそれがかなり低コストで、
5ドルのペイドプランとかに入れば 十分に運用可能なものになるので
めちゃくちゃ便利だよみたいな話を してたと思うんですけど、
じゃあなんでデータベースが結構 大事になるのかなっていうと、
Cloudflareってサーバーをまず提供してくれる っていうのはやってくれてるんですけど、
それ単体だとデータベースって本当にプリミティブに、 最小単位でサーバー立ち上げると
データベースって当然ないので、 例えば業務システムで普段作業している
情報を記録したりとか、それこそ 簡単な管理画面作るときにデータの保存先が
必要になると。そうなったときに データベースを用意する必要があるんですけど、
Cloudflare自体も、実は聞いてる人は よく知ってる人も多いと思うんですけど、
データベース自体用意してくれてます。 それがCloudflare D1っていう名前のサービス
になっていて、基本的にはサーバーと D1っていうのをくっつければ、それっぽい
業務システムとかは簡単に立ち上げる ことができるっていうのが大前提として
ありますが、なんかあれなんですよね。 CloudflareのD1、便利だし安いしいいけど
っていうところはありつつ、やっぱり制約 っていうのもいくつかあって、ユーザーに
サービスを提供するにあたっては、 本当にそのD1って採用していいの?
みたいなのは、エンジニア視点としては 疑問に思うところがちょいちょいある
っていう感じなんですよね。 D1、何がいいところいっぱいあるんですけど、
SQLite・MySQL・Postgresの違い
気になるポイントとして、やっぱり SQLiteっていう軽量なデータベースになっているので、
データベースの種類でいうと、 ざっくり大まかに言うとSQLiteっていうものとか
PostgresっていうものとかSQLっていう、 SQLとかよく聞いたことのある人も
多いと思うんですけど、そういうデータベース の種類があって、すごい誤解を恐れずに
ザクッと言うなら、SQLiteって割と 検証環境向けだったりとか、あとは
趣味プロジェクトとかで使う軽量なデータベース。 SQLとかは使い勝手が良くて、
本番運用にも耐えられるようなデータベースで、 Postgresっていうもう一個のやつは、
割とカッチリとした業務システムにも使えて、 柔軟性とか拡張性も高いデータベースみたいな、
そういうイメージになってるんですよ。 結局、Cloudflareって一番小規模なSQLiteっていうものの
データベースが前提になっているので、 ちょっとそれだとサービス展開するのには厳しいな
みたいな感覚を受けることがいろいろあって、 そのってくると、じゃあデータベース選びどうするか
みたいなのがCloudflareでちゃんとサービス作ろうとすると、 結構ぶち当たる問題なのかなっていうところが前提にしてありますよね。
なるほど。ちなみに、MySQLとPostgresは何が違うっていうか、 SQLiteはなんか俺のイメージ、ローカルでもサクッと使えるみたいな感じ。
テキストファイルに近いイメージなのかなっていう印象を受けてるんですけど、 それって理解あってるのかな、ちょっと俺も全然わかってない。
なんかSQLiteはなんかファイル、なんかすごい雑に言うとCSVとすごい近くて、 ファイルベースでデータを入れて、そこに読み書きをできるような仕組みを作ってあげたっていう、
そういうデータベースになってるので、なんかファイルサーバーさえあれば簡単に動く。 だからローカル、手元のパソコンとかでも当然ファイルで読み書きができるから、
環境とか作り込まなくても使いやすいっていうのがSQLiteの特徴で。
じゃあMySQLとPostgres何が違うのかっていうと、2つとも共通してるっていう意味で言うと、やっぱりサーバー、データベースの専用サーバーを起動して、
そこに専用のアプリケーションを導入して、 しかもデータベースのコネクションとかしっかり張る仕組みを作った上で、
なんか疎通する必要があるとかで、結構立ち上げ自体が専用サーバー起動しなきゃいけないっていうので、 めんどくさいといったあれですけど、やっぱりひと手間かかるようなものになって。
じゃあMySQLとPostgres、具体的にどのくらい違うの?みたいな話で言うと、 やっぱり権限の管理とか、あとは関数の定義のしやすさ、あとはサポートしてるデータモデルの違いとかで、
結構Postgresのほうがいろんな設定を細かくできて、 あとはチューニングとかも細かくできるっていうので、やっぱクロート向けな感じがあるんですよ。
で、かたやMySQLっていうのは、そういった複雑なものはもちろんサポート増えてきてはいるんですけども、 まだまだPostgresには追いついていない部分もあって、
実際に運用してるとちょっと困ったなみたいなことに割と遭遇しやすいものではあるなっていう感覚がありますね。
ただ、MySQLがだからといって使いにくいかって言われると、そうでもなくて、 Wordpressのサーバーとかは基本的にみなさんMySQLで使っていたりとか、
小規模なウェブサービスだったりブログシステムでは、すごい採用事例が多いようなデータベースになっているイメージ。
Postgresが一番メジャーって感じなんですか?
メジャーですよね。例えばですけど、MySQLにない機能で言うとGeolocationっていう位置情報とかをデータベースに登録しておいて、
その地点と地点の近さを一瞬で計算できる機能があったりとか、
あとはベクトルデータベースを標準でサポートしていて、それこそ最近AIのラグっていう仕組みとかが結構話題になっていたりとかしたと思うんだけど、
そういうのもデフォルトで作りやすいように組み込みで機能があるとか、そういう違いがあって、便利っちゃ便利っていう感じですね。
なるほど。使う用途に合わせて結構拡張というかしやすいみたいな感じなのがPostgresってことね。
Postgres。
はいはいはいはい。
D1の容量とスケール上の不安
クラウドフレアでSQLite使うっていう判断も、業務システムとかちょっとした小さなアプリ使うにはいいんですけど、
例えばユーザー向けの業務システムを作って、それこそSaaSっぽく展開していきたいなとか、それこそ課金モデルを作って稼いでいきたいなみたいな。
そういうことを考えたときに、D1で果たしてどこまで耐え切れるんだろうみたいなのはちょっとやっぱり不安になるところはあって、
もちろんスモールスターとして拡張していけばいいよね。必要になったときに乗り換えればいいよねって話もあると思うんですけど、
意外とそう乗り換えて結構大変なので、だったら最初から将来の不責も踏まえて、小さいながらも拡張性のあるデータベースを選択していったほうが嬉しいなっていうところがあって、
D1以外の道を結構模索したりするっていうのが、ここ1年ぐらいいろいろ考えているところではあったんですよね。
耐えられなさそうっていうのはパフォーマンス的にとかっていう、データ量が多くなったときにみたいな話?
そういうのもあるね。例えばだけど、クラウドフレアのD1って、1つのデータベースで賄える保存容量っていうのが10ギガなんですよ。
10ギガバイトをデータベースでってやると、結構それなりにデータ量保存できるっちゃできるんですよ。
例えばですけど、100万レコードとかそういうのが1年に100万レコードずつ増えるような業務システムって、
一社が活発にタスクの記録とかを行っていると、結構1年間に100万とか200万レコードぐらい増えるんですけど、
それでも増えるよって正直1ギガバイトぐらいなんで、それを考えると到達するには1社10年ぐらいで行っちゃうよねみたいな考えではあるんですけど、
じゃあそれってサービス展開するときに1社だけに展開するわけではないよねって考えると、スケールした瞬間に10ギガ一瞬で突破するなみたいなという不安があったりとか、
クラウドフレアのD1ってSQLiteを採用しているがゆえなのか、僕もここは詳しくわかんないんですけど、書き込みが単一レットで書き込みになるので、
一気にリクエストが来たときにやっぱり待機列ができてしまうんですよね。
なので処理としての負荷の耐性の高さみたいなところで言うと、やっぱりちゃんとしたポストグレースとかを採用している方がトラフィックにも耐えやすいとかっていうのがあったりとかして、
ちょっとD1、SQLiteだと心もとないのかなというのはあります。
そういうのもあって、じゃあ実際問題D1以外に何がいいのみたいなところはあって、
D1のいいところって5ドルのペイドプラに入っていれば、ワーカーズと一緒にD1も一緒に使えて、
なのでサーバーとデータベース含めて5ドルで完了するみたいな世界線なのでめちゃくちゃ安くて嬉しいなっていうところありつつ、
じゃあ他のデータベースって世の中見てると、AWSのAURORA DBとか、あとはGCPとかもそれぞれデータベースサーバーを用意してくれていたりとか、
あとはレンタルサーバーにデータベースをホスティングしてやる、この派とかXサーバーとかデータベース用意してくれる、
あとはネオンとかスーパーベースとか、あとはプラネットスケールみたいな、バースっていうSaaSのバックエンド版みたいなのがあったりして、
そういうのをザーッと見たときに、やっぱお金がかなりボトルネックになるんですよ、データベースって。
データベースなんでそんなにお金かかるのかっていうところなんですけど、やっぱりなんかウェブサーバーみたいにリクエストが来たらレスポンスするみたいな形で、
サーバレスで来たときにサーバー起動してレスポンス返すみたいな仕組みじゃなくて、基本的にデータベースって常駐サーバーってここにポンと置いて、
常駐サーバーが起動して、いつリクエストが来てもすぐ返せるようにみたいな構成が割と一般的なんですよね。
そうなるとサーバーの利用料っていうのがフルフル、月の1ヶ月間フルフルでかかるので、
安くても5000円とか普通に使って1万円とか割と切り抜くとそんぐらいお金かかりがちなものにはなっていて、
特にAWSとかGCPとかで作ると一瞬で1万円とか数万円いくようなものにはなってるっていう感じなんですよね。
Supabaseを選んだ理由
なので結構いろいろ何がいいのかなって探してきたときに、まずそもそも選択の仕方みたいなのがあって、
例えばお金、コストの部分もそうだし、あとはリージョンの設定っていう話。
リージョンってどういうことかっていうと、データベースを世界中のどこに配置できるかっていうのをどれぐらい選択肢があるかっていう話があって、
なるべく東京とか、僕たちが日本でサービス展開するならデータベースのサーバーを東京に置いておきたいよねっていう話があったりとか、
あとはバックアップがどれぐらいの頻度で取れるのかとか、どれぐらい遡れるのかとか、
あとはサーバーがスケールしていったときにどれだけ増強できる余地があるのかって、
だいたいそれぐらいの4つ5つぐらいの強化軸があって、
D1含めてどういうのがいいのかなっていうのを結構探していた時期がありました。
なんか候補として挙がったのがやっぱりAWSとかGCPみたいなエンプラ向けのデータベースサーバーとかと、
あとはVerseっていうSaaSのバックエンド版であるようなスーパーベースとかネオンとかプラネットスケールとか、
あとPaaSとかもちょっと比較してもいいのかなと思って見たりしていたんですけど、
AWSとGCPは基本的に高いし、
こっちを使うんだったらサーバーも完全にAWSとかGCPに寄せた方がいいので、
あんまり採用するのは難しいなと。
プラネットスケールとネオンとスーパーベースぐらいが比較対象、
どれもPostgresが使えるようなVerseになってて、
ネオンがそもそも東京リージョンってサーバーを、データベースサーバーを東京に置けないって、
一番近いのは確かシンガポールとかで、
シンガポールぐらいだったら若干共有できるかなっていうのがあるんですけど、
例えばウェブサーバーが東京にあって、データベースのサーバーがシンガポールにあると、
そのデータのやり取りがめっちゃ時間かかる。
1回のリクエストにあたり、シンガポールぐらいだったら50msぐらいかな。
何も障害がない前提で、経路に障害がない前提で、
単純に光の速度として50msぐらいかかって、
それだと往復で100msかかるわけ。
ってことはデータベースの問い合わせを10回しただけで1秒かかっちゃうとか、
そういうのがあるので、結構遠いからネオンは採用できないなって。
X見てたら代表の人が東京リージョンそろそろ作るよみたいなのを、
1年前ぐらいに話してたりしてたんですけど、
結局まだまだできそうな雰囲気ないので採用難しい。
で、あとプラネットスケールっていうのも最近で、
クラウドフレアと互換性高いよみたいな話があって、
結構いいなとは思ってたけど、やっぱり価格の面で少し高いっていうのがあって、
スーパーベースってもう一つの候補とクラフト的にちょっと高かったっていうところがあって、
最終的にスーパーベースっていうのが東京リージョンがあって、
値段も他と比べると安くて、
他のスケールだったりバックアップの柔軟性みたいなのが一番あったので、
最終的に選んだのがスーパーベースって感じになってますね。
個人的にはDBとしてどうかみたいなのはちょっとよくわかんないけど、
Supabaseの利便性とセキュリティ
管理画面が使いやすい。
もちろんスーパーベースのMCP経由でSQL流すみたいなこともできるし、
AIにこういうの確認したいからSQLを教えてって言って、
スーパーベースの管理画面で自分でSQL流すよみたいなことを言ってもできるしっていう、
今まで使ってたDBクライアントっていうのかな。
よりよっぽど見やすい。ログインもしやすいし、
ネットハブでログインできたり。
確かに。
管理画面を見やすいみたいなところは個人的にかなりいいなっていう風に。
そうだよね。
スーパーベース、これバース系は割とサポートしてるかもしれないんだけど、
データベースのSQLを実際に流したり、
テーブルをスプレッドシートみたいに眺めることができるっていうのは、
テーブルのデータのレコードをスプレッドシートみたいに眺めることができるっていうのは、
結構バースのいいところかなと思ってて。
例えばAWSとかGCPとか、ちゃんとしたエンプラ向けのデータベースサーバーを使ってると、
あんまりデータベースと一緒に見ることがやりにくいかっていうのがあったりして、
結局それを見るために接続したりとか、踏み台サーバーを用意したりとか必要だったりとか。
あとは、テーブルプラスでしたっけ?
ポストグレープ用のアプリを、データベースを見るためのアプリをダウンロードして、
パスワードとかホストの設定とか諸々細かくしてようやく接続できたみたいな感じだけど、
スーパーベースとかってログインすれば簡単に見れて嬉しいよねみたいなのがあるよね。
あとあれなのかな、それこそ簡易的に作りたいんだったらね、ログインとかその辺の機能もあるし、
使わないっていう判断もできるしみたいな。
そうだね、スーパーベースは、ファイヤーベースとだからかなり思想というか近いのかなと思って、
ファイヤーベースっていう、Googleが出してる、
そういうバースっぽいものがあるんですけど、あれはファイヤーストアでしたっけ?
ドキュメント志向のデータベースを作るのに特化していて、
かつ認証とかストレージサーバーとかリアルタイムなデータのやり取りとかをサポートしていて、
ちょっとしたアプリケーションを作るのに便利であるっていうのがあるんですけど、
それのドキュメント志向版じゃなくて、リレーショナルデータベース版がスーパーベースかなと思って、
スーパーベースも認証系を持ってますよね。
かなりサポート広くて、当然SNS系はログインできるような仕組み簡単に作れるし、
パッドアップとか、ちょっとしたチャットアプリの認証系を使わせたりとか、
GitHubみたいなアカウントでのログインとか、リンクトインとかでのログインができたりとか、
結構便利だなって思う。
いつつも僕は採用しない方向で基本的に動かしてたりはするんですよね。
なるほど。
ちなみにポストグレスをラップしてるみたいな感じ?
スーパーベースは完全にそうで、ポストグレスをラップして認証をくっつけられるようにしたり、
あとはストレージサーバーを抱き合わせたりとか、そういうのを使ってるようなイメージかな。
なので本当に根本は他のポストグレスがベースとなってるようなサービスなのかなと思います。
なので僕はクラウドフレアでシステムをちゃんと立ち上げるってなったときは、
スーパーベースを割と採用することが多くて、
使うときも本当に将来のスケールしたときにやっぱりAWSにポストグレスサーバー移行したいなとかって話が出てきても、
移行しやすいようにとかっていうところを踏まえて、
認証系とかはなるべくスーパーベースでは使わないようにしているっていうのはちょっとあるんですよ。
スーパーベースのエメリットって何なのかな?料金?
料金もあれなんですよね。
普通にAWSとか他のデータベースとか使うのと比較すると、
やっぱ普通に使ってる限りはスーパーベースの方が安いんですよ。
なので科学的にはかなりメリットがある。
デメリットがあるとすると、やっぱりプライベートネットワークに囲い込めないっていうところは、
結構リスクの一つではあるかなと思っていて、
要はエンタープライズメーカー系の業務サービスとか、
個人情報を守らなきゃいけないようなデータをデータベースに保存している状況で、
スーパーベースってあくまで他のサービスがあって、
そこにデータベースが欲しいから取手付けでできるようになっている仕組みではあるので、
そこのもとあるシステムからスーパーベースとのネットワークのやり取りは、
もう普通にHTTPのリクエストでやり取りするようなものになってるんですよ。
なのでそうなると公開ネットワークにデータが乗っかってくるので、
若干リスクがあるよねっていうところで、
例えばAWSとかだとそういうのをセキュアにするたびに、
プライベートのVPCネットワークっていう外部からデータベースには、
アプリケーションサーバーを経由してからじゃないと絶対にアクセスできないようにして、
そこで安全性を保ったりとか、経路をとにかくなるべくは塞いでいくっていう対応を取ったりするんですけど、
そういうのがスーパーベースはやれないっていうのがデメリットなんですかね。
これもまたメリットなのかもしれないところはありつつも、
リスクになるポイントでもあるっていうところかな。
あと簡単に構築ができるが故に、
結構1年前ぐらいとかはスーパーベース経由で情報漏洩しまくってる事件が起きてたっていうのはあったりしますよね。
スーパーベースってそもそもあれなんですよ。
これもファイアベースと思想は割と近い。
フロントエンドから気軽にデータベースにアクセスして、
サーバーを使わなくても、サーバー必要としないでも、
フロントエンドのアプリケーションとデータベースだけで成立する、
ちょっとしたアプリを作れるようなこともできるようになってるんですよ。
それをやるためにはフロントエンド、要はWebブラウザからデータベースのテーブルに対して、
直接セレクト文を流すとか、アップデート文を流すっていうのができるようになってて、
これデータAPIっていうんです。
それを使うときに権限の設定を間違っていたりとか、
あとは認証のトークンがうっかり漏れたりすると、
その他の人の全員のデータとかを、悪意のある攻撃者が全部見れたりして、
それでデータローエーをしちゃうみたいなことが結構起きていたりしたっていう、
ちょうど1年前ぐらいですかね、Viveコーディングが流行ったときとかに起きてて、
マジで結構簡単にシステムのデータベースのテーブルが何があるのかっていうのを実際に見れちゃうんですよ。
この話をするのに。
Firestoreと一緒だね。
そうそう、Firestoreと一緒で、ちょっと権限の設定を甘くしただけで、
全部お漏らししちゃうみたいな。
今日ちょうどこの話をするのに、スーパーペースを使っているサービスをたまたま見つけたので、
どうなのかなと思ってソースコードを眺めてたら、
やっぱりそのサービスで作ってある内部のテーブル構造が全部、
見えるというかわかるようになってて、
こういうデータベースの構成になっているんだっていうのを実際に見れたりもしていたので、
そこのサービスはもちろんちゃんと権限設定しているので、それ以上のデータは見れないっていうのはあるんですけど、
そこをとっかかりに脆弱性を突かれるっていうリスクはやっぱりあるなって感じますよね。
それは設定次第だけど、アクセスするIPアドレスを制限したりとかはできる?
これは、例えばフロントエンドからのデータアクセスを受け付けるんであれば、
RLSっていう業レベルセキュリティとかっていったりするんですけど、
ああいうのをしっかり作り込むことで安全性を担保したりとかできるし、
僕たちがスーパーベースを使うときは基本的にフロントエンドからデータベースにアクセスするっていうのは禁止して、
必ずサーバー経由であるっていう前提条件を設けてセキュアにしていくようにしているので、
フロントエンドからのリクエストは完全に遮断する設定がスーパーベースにあるので、
それを設定しておいて、そもそも全く見れないようにしておくっていう対策を行ったりしますね。
なるほどね。それがデータAPIとかってやつか。
そうそう、データAPI。
そのサーバー側から、バックエンド側からアクセスするみたいなのも特定のIPからとかでも絞れるみたいなの?
それは絞ることはできる。
なるほど。
RLS過剰適用からの大規模改修
だからスーパーベースはそういうフロントエンドからアクセスされることを前提にしているが故に、
結構RLSについてすごい口うるさくて、Xとかドキュメントとかにも書いてて、
AIがそればっかり正直にRLSを設定しますっていろんな制約をどんどん盛り込むみたいなことが起きたりして、
逆にシステムとして複雑というか動きにくいシステムが出来上がっちゃうみたいなデメリットも若干あったりするんですよね。
なるほどね。
フロントからっていう前提だからっていう思想の下、RLSでガチハシに。
そう?
使い方次第っていうところなのか。
そう、使い方次第。だからRLS結構重要だよねみたいな話も一時期かなりあったけど、
僕が知る限り業務でRLSをちゃんと使ってるシステムそんなに見たことないっていうところもあって、
大きな業務システムでも。
RLS前提で組み込んでいくとどんどん厳しくなって、アプリケーションの柔軟性厳しくなるなみたいな課題感もあって、
スーパーベースを使ってAI駆動開発するときは注意しなきゃいけないポイントかなって思ったんですね。
スーパーベースなので、料金安いよねとかが一番のメリットかなと僕は思っているんですけど、
実際そのお金の部分で言うと25ドルで1ヶ月サーバー、データベースサーバー1台使いどこを代みたいな感じの価格になるんです。
25ドルって言うと日本円にしてだいたい4,000円くらいですかね。
高いね。4,000円って言われると高いじゃんかと思うけど、
普通に他のデータベースサーバーとか使うとすると40ドルとか80ドルとか平気でかかってくるんで、
十分安いのかなっていうふうに思ってるって感じですね。
けどあれなのか、1スリーのアクティブユーザー数が10万人、それ以降は1人当たりでお金がかかってくる。
それは多分認証券使ってる時とかかな。
そういうことか。認証券を自前で実装してる場合はその限りではありませんってことか。
あくまでデータの数だけなんで、データのストレージ量になる。
結構ね、その認証券を乗っかることが実装すごい楽になるしメリット多いんですけど、
引っ越すときに厄介になるっていうのがあって、
ポストグレスの1個のデータベースに、ポストグレスってスキーマっていうふうに言って、
同じデータベースの中に複数のデータ領域を作ることができるんですよ。
それはテーブルを分けるとかじゃなくて、テーブルよりもより上位のグルーピングみたいな、テーブルグループみたいなのを作ることができる。
認証券を使ってると、オーススキーマっていうのが自動で作成されて、
そこにボコボコデータが放り込まれて、ユーザーの認証情報とか入ってくるんですよ。
そうなってくると、ユーザーの認証情報を引っ越し、
例えばポストグレスがかなりデカくなって、コストパフォーマンス的に見合わなくなってきたから、
スケールしたタイミングでAWSに引っ越しますっていうときに、
業務アプリとして作ってたデータベースと、それとは全く別の認証券のデータベースが引っ付いてくるんですよ。
けど、その認証券を制御するアプリケーションはスーパーベースが持ってるので、
このデータベースが一緒に引っ越されても、認証券を使われるアプリケーションがスーパーベース側にあるから、
動かすのがちょっと大変だなみたいな問題にぶち当たってしまうなと思っていて、
でなるとスーパーベースで実装されていた認証券を自分らでコピーして使って動かすのかみたいな問題が出てくるので、
なるべくスーパーベースの認証券には乗っからないで、
自前の認証を作って1個のデータベースの中で完結するように最初から作っていた方がいいんじゃないのかなと思ってるんですよね。
なるほどなるほど。逆にそこを意図せずやると後で大変みたいなのはありそうってことか。
そうだね、後で大変になってくる。
ここはもうどういうサービスを作って、どれくらいのスケールを考えていく、
あと移行の技術塞いではないですけど、返済計画、移行する時にこういう風にやればいいよねみたいなのを考えておけば良いと思うんですけど、
あまり考えずに売ってしまうとちょっと苦労するかな。
まあRLSとかもそうだね。
まあそうだね。
うちの失敗というか結構改善できたからまあまあまあって感じなんだけど、
RLSでガチガチで作ってて、僕が結構手動で作り始めて、それでRLSでガチガチになってて、
その結果、業務システム系のSaaSみたいなもので、もちろんセキュアなんだけれども、権限設定細かくお客さん側でできないみたいな。
さっき言ったみたいな、システムとしての柔軟性に欠けるみたいな感じの問題があって、
それに引きずられるのは結構困るよね。
今多分聞いてる人的にちょっと分かりづらかったかもしれないですけど、
例えばですけど、その社内のメンバーで全然これお互い見せててもいいじゃんみたいな情報を、
RLSとかで遮断してるみたいな感じで、過剰にやりすぎてるみたいな。
その過剰が故に迂回するためのバイパス経路みたいなのが生成されたりして、
業務システムの方で複雑になるとかっていうのが起きてたりしてたよね。
でも立ち上げた当時さ、僕もあまり立ち上げのところ見れなくて、
スーパーベースのドキュメントとかで、RLSとにかく設定しろって言われるし、
スーパーベースの管理画面に入るとさ、
RLSが何件設定されてませんみたいな警告がめっちゃ出てくるじゃん。
はいはい、そうそうそう。
俺はだって幾度となく阿部ちゃんにこれ大丈夫なのかなって聞いてた。
すごいね、スーパーベース側が脅してくれるんですよね。
RLSがないことに。
メールも来るしね。
お前ら何件のテーブルあるのにそのうちの何十件はRLSの設定されてねえぞとかって言われて。
言われるがままに追加していったら、
データベースに権限があるし、アプリケーション側にも権限のレイヤーがあるし、
どんどんどんどん複雑になるみたいな感じになってた。
結果的に超大規模回収を経て、今すごく綺麗になったっていう。
本当に最低限のRLSとアプリケーション側でしっかり権限設定できる仕組みに切り替えて、
柔軟性とセキュアな部分を両立していくという方針にようやく慣れたかなと思ってます。
Cloudflare Hyperdriveと接続数の設計
クラウドフレアというかほぼスーパーベースの話になってたけど、
クラウドフレアでスーパーベース運用してて、
つまづいたポイントというか失敗ポイントもあって、
コネクションプーラーっていう仕組みがありますと、
それの設定を結構何も考えてないと事故りますよっていう話があって、
そもそもコネクションプーラーって何ぞやって話なんだけど、
データベースにサーバーとかアプリケーションから問い合わせをするときって、
当然接続を確立する必要があるんですよ、ネットワークの接続。
普通のサービス、いわゆる常駐サーバーがあって、
常駐のデータベースが1台ずつあるようなサーバーっていうのは、
もう常に起動してるので、接続をずっと維持して、
1本とか例えば10本ぐらいで固めておくっていうような形で運用するんですよ。
けどクラウドフレアって常駐サーバーがなくて、
いわゆるサーバーレスっていう技術になってるんで、
サーバーの数がユーザーのアクセスに従って、
いくらでも増減するような仕組みになってるんですよ。
ユーザーがアクセスしたらサーバーが起動して、
そこでデータベースに接続して始まって、
終わったらサーバーが閉じる。
例えば極端な話で100人のユーザーが一気にアクセスしたら、
一気に100台がボンと立ち上がって、
そうすると100個のサーバーが一気にデータベースに接続かけようとすると、
データベースって接続できる本数っていうのがそんなに多くないですよ。
例えばスーパーベースってだいたい60本ぐらいまでが上限になってて、
そうなった時に一気にユーザーが増えると、
データベースに接続できる人とできない人がいっぱい発生するっていう問題が起きてしまう。
だいぶ問題だね、それ。
結構安易に起きるんですよ。
何でかっていうと、使ってるユーザーの数だけじゃなくて、
例えばクロームのクローラーが探索しに来たとか、
それこそAIがチャッピーとかで質問したら、
AIがそのサイトにアクセスしてくるとかで、
結構アクセスが発生してデータベースの接続が発生するので、
容易に枯渇しやすい。
それを解決するのがコネクションプーラーっていう仕組みになって、
これ何かっていうと間に中間サーバーが、安い中間サーバーを起動して、
そこで受け口になってデータベースと接続する本数を制御する、
中間の役割がある、必要っていうのがあって。
このコネクションプーラーっていう機能自体、
クラウドフレアが提供してくれてるし、
スーパーベースもスーパーベースで提供してくれてるんですよ。
なのでスーパーベース使い始めて、
クラウドフレアからデータベースに接続したいなと思ったときに、
どっちのコネクションプーラー使えばいいんだっていうような、
まずその疑問にぶち当たるんですね。
これに関してはもう回答は明確で、
クラウドフレア側のコネクションプーラーを使うべきっていうのがあります。
クラウドフレアのコネクションプーラーって、
ハイパードライブっていう名前がついてるんですけど、
それは何でかっていうと、
コネクションプーラーの役割と、
プラス負荷分散の役割も、
ハイパードライバーになってくれていて、
機能がスーパーベースよりちょっとリッチなんですよね。
柔軟性があるっていうところが一つと、
結局アプリケーションサーバーからデータベースのサーバーに、
どれだけ近く起動するときに、
それぞれが近いところでサーバーが起動するかっていうのは結構重要で、
スーパーベースはリージョンを設定できるので、
東京リージョンっていうので、東京にサーバーを用意することができるんです。
けどクラウドフレアって、
一応設定できるように最近になったんですけど、
基本的には世界のどこでもサーバーが起動するようになってて、
そのサーバーはユーザーがアクセスしたネットワークの中で、
一番近そうなサーバーを検知してそこに立つっていう仕組みになる。
なので、例えば私がアメリカにいて、
データベースが東京にあったときに、
サーバーがアメリカのサーバーで起動すると、
データベースへの接続に行くために、
わざわざアメリカから東京のサーバーとデータベース間の通信をやり取りしないといけないんですけど、
このクラウドフレアのハイパードライブを使うと、
その接続先をなるべくデータベースの近くに寄せてくれるようになるんです。
そういう機能があるので、コネクションプーラーの役割がありつつ、
データベースもなるべく近くに寄せてくれて、
ネットワークの経路としての最適化を図ってくれるっていうのがメリットになるので、
これは絶対にクラウドフレアのコネクションプーラー、
ハイパードライブを使うべきだというところになっている感じですね。
ハイパードライブにはキャッシュとかの機能もあるので、
例えば60秒間同じリクエストがあったら、
同じ結果を自動で返すみたいな仕組みがあるので、
データベースにリクエストが飛びすぎないみたいな。
キャッシュがあることによって逆に業務システムだと、
せっかくデータ更新したのに反映されないんだけどみたいな問題になるので、
それはアプリケーションの特性によりけり、
使うか使わないかを判断するべきだと思うんですけど、
ブログサイトとかだと特にそういうのを使っておいた方が、
めっちゃバズっていっぱい人がアクセスしてきて、
もう落ちにくくなって作りやすくなりますよねっていう感じですね。
ちなみに、スパベースとクラウドフレアワーカーズの構成が、
相性が悪かったみたいな。
そうなんだ。
記事があって、
それがワーカーズは固定IPを持たないので、
スパベース側でIP制限をかけられないからですっていう。
はいはいはい。
解決策とか、だいたいその選択肢とか書いてるみたいなけど、
その辺って実際どうなんかというか。
しかも、ちょっと思ったんやけど、
例えばうちのシステムとかだと、
エアーエージェントをクラウドフレアワーカー上で動かしてるじゃないですか。
で、サーバーレスでポポポポポと立つみたいな、
それが60個のDBの接続だけで枯渇するだと 結構なんか少ないなみたいな感じ
はいはいはいはいはい
スーパーベースは安い分 やっぱり まずIPの話は置いといて
接続の枯渇に関しては 60が上限なんですよ 接続可能なカード
だからそこに関してはハイパードライブっていうのが 間に中間に入って
うまく接続本数とかリクエストを制御するっていうので
流量制限したりとか 接続の効率化を図るみたいなのをして
対策を取るしかないっていうのがあって
プランを1個あげると 接続本数を60から90とか120に増やすことも一応できるんですよ
そのぐらいでも接続ってかなりスパイク的に 例えば1分間に3000リクエストきますとか
5000リクエストきますみたいな かなり流量の多いようなシステムになってて
それぐらいの規模ってそもそももう そういうちょっとスーパーベースじゃなくて
AWSとかエンプラ向けのシステム使ったほうがいいよね みたいな話になってくるので
ちょうど60ぐらいで枯渇するんだったら もう履行したほうがいいんじゃないみたいなのは若干あったりは
ちなみにAIエージェントを 今のうちのサービスでもAIエージェントを
60人が一気に一緒にタイミングで使ってる みたいなことは全然想定できるなと思って
今の段階ですらって感じで思ってるけど それはそんなことはないというか
でもどれぐらい 人数が多いとダメかどうかで言うと
それはハイパードライブ側で 結構クッションになってくるので
まとめてくれるみたいなのある
例えば1000ぐらいガーッと来ても ハイパードライブで一旦受け口になって
そこで接続をスーパーベースと 確立するのを上限60として
さばき切りますっていうのをやってくれるのが ハイパードライブなので
そういうことね 1対1じゃないのか
1対1ではないので それが問題だから そういうコネクションプーラーが
絶対的に必要になるっていうのが前提になる
それで枯渇するようなものって もはや普通に常駐サーバーがあって
常駐のデータベースがあって ちゃんとしたシステム作っても
枯渇するようなものなので 花からっていうような感じではある
仮に600人一斉でアクセスしてます みたいな状態になっても
超単純計算で言うと 10人とかにある程度吸収して
10人ごとのグルーピングみたいなのをして スーパーベースにアクセスする
みたいな形になるみたいなイメージ
あとIPに関しても 確かに不安とすることはよく分かる
不安だなっていう気持ちもある ただそれやるんだったら
それこそプライベートVPCのネットワークに ちゃんと安全な
通信網としても隔離された環境で データベースを動かすっていう前提にして
AWSとかGCPに動かしたほうがいいんじゃないの IP制限とかをするよりかはいいんじゃないの
ってかあれなのか うちの仕組みだと基本的に
アプリ本体のほうのクラウドランで構築してるじゃないですか
なんか業務データはそっち経由でしか取らない みたいなのがあるから
そもそもスーパーベースとの疎通って何をしてる 認証だけみたいな感じ
何をしてるの
AIエージェントがスーパーベースと どういうふうに疎通するかってこと
うちの会社の
そもそも疎通する意味があるのか みたいなイメージなのかな
というのも本体側のアプリケーションを介して 業務システムにアクセスしてるじゃないですか
AIとかってなったときに 会話だけか 会話履歴がスーパーベースってこと
でもそれもクラウドラン経由で通してるから うちはクラウドクリアのAI実行基盤から
スーパーベースにアクセスを直接することって ないんじゃないかな
確かなかったと思うんですけどね うちはだからそういう意味ではそこは
手前ミスだけどちゃんと作ってるというか
それでもコネクションプーラーは必要なの
えっとね それはね必要ないかな
うちはだからそもそも接続はクラウドランから行う スーパーベースへの接続はクラウドランから行う前提なので
今日この話はうちのAIエージェントの話とは あんまり関係ないというか
あ そういうこと
そうそう 一般的なクラウドフレアで 例えばワークハウスでウェブシステム作るとか
そういうときには
そういうことね
そうそう スーパーベースが必要になるし そこから直スーパーベースで行くっていうのは前提だと思うけど
うちはちょっと作りが特殊なんよね なぜに見ると
クラウドランっていう実行基盤があって
で それをそこの周囲にクラウドフレアの
エージェントだけね
そう エージェントだけがいたりとか
よりデュアラブルオブジェクトっていう仕組みを使って 利便性を向上する仕組みを作ってるだけだよね
なるほど
けど それでいうと その構成が一番いいのかなっていう
特殊なのかなと思いつつも わかんないけど
結局 サースとしての基盤というか お客さんの大事なデータみたいなのは
クラウドランからスーパーベースに サーバーからアクセスするみたいな感じで
ここはだからIPは一本化されますみたいな感じ
クラウドランもサーバレス?
クラウドランはサーバレスにも作れるし 常駐サーバー的にも使える
最低起動インスタンスっていう考え方があって
それをゼロからNある数まで設定できて
ゼロだったらサーバレスなんですよ リクエストだったらっていう
だけど1とかに設定しとくと そのインスタンス サーバーの数を常に1に維持しますなので
ほぼ常駐サーバー的になる
そういうことね
AWSのラムダとかは基本的にサーバレスなんだけど
クラウドランはちょうど中間にいるみたいな そういうイメージなのかなと
今の僕らが作ってるサービスの仕組みが
スタートアップ的な小回りの利きやすさと 情報を守りつつ
セキュアにしつつ 拡張性も考えてるみたいな構成なんじゃないかなとは
一応やってるって感じ
けど結局 ある程度スケールしてきたときに
1個の常駐サーバーだけだと
ロードバランサーみたいな感じで割り振りたいな 複数のサーバーみたいな
そういうのが出てきたときにはできないみたいな感じだから
そのときはある程度スケールしてきたタイミングに
移行は考えないといけないかもな みたいな感じっていうイメージ
データベースのトラフィックがあまりにも大きくなったら 移行は考えておいたほうがいい
特にはストレージだったりとか お客さんのデータより機密の情報というか
失ったら困る情報が増えてきたときに バックアップの仕組みを整えないといけないように
こういう系ってバックアップでお金を取ってたりするんで
バックアップの機能を有効にした瞬間 AWSよりも一気に値段が跳ね上がるとかある
なのでそういうときになってきたら AWSとかGCPに移行して
ちゃんとデータ保全も含めて安全に運用しようねみたいな話が出てきたりとかあるかな
確かスーパーベースは1日1回のバックアップはデフォでやってて
なんか踏ん刻み的な 結構リアルタイムでやってくれる 踏ん刻みどころじゃないのかな
みたいな設定をオンにするとバカ高くなるみたいな感じ
バカ高くなる
なるほど だいぶ理解ができてきましたね
接続上限60の落とし穴
あれだよね さっきの話に戻るけどハマりポイントで
さっきのコネクションプールの話なんだけど
スーパーベースのコネクション数60がさっき上限って言ったと思うんですけど
ハイパードライブで初期設定すると
接続本数を増やす上限値に60ってデフォルトで設定されるんですよ
なのでハイパードライブが最大で接続する本数が60で
スーパーベース側も受けれる最大数が60って書いてあるから
なんかちょうどいいじゃんと思って
一回60、60で設定して運用してたんですよ
そしたらある時データベース止まった時があって
接続が完全に死んだ時があって
これ何でかっていうと
この問題起きて調べて初めて知ったんですけど
まずスーパーベース60って言ってるくせに
内部で状態監視したりとか管理画面にアクセスしたら
さっきダッシュボード見れて嬉しいよねって話したんですけど
ダッシュボードからデータベースにアクセスする時とかも
この60の中から接続を確立してたんで
実際に常時5本ぐらいは使われてるみたいな
60本のうち5本ぐらいはスーパーベースを動かすために使われてて
だからアプリケーションから使えるのって55本ぐらいだよねみたいな感じになってて
ハイパードライブ側で60って行こうとすると
足りないってことが起きると
しかもハイパードライブ側も設定を60ってできるんですけど
これがソフトリミットっていって
スパイク起きた時は吉田にちょっと超過するよみたいな仕組みになってるので
60って設定してたら65とかで接続しようとしたりするんですよ
っていうのがあって60でデフォルトになってるからそのままだと死ぬので
ハイパードライブ側の設定を40とか30とかにしておかないと危ないっすよっていうような
ちょっと心配談がありますね
ちょっと焦ったねあれは
なんかそう難しいなと考えるとね
使いどころがなんか今の話を聞くと
何だろいつというかいつ使うかみたいな結構難しい
アブちゃんが色々工夫してみたみたいなのは
社内ツール的なみたいな意味
社内ツール的なみたいな意味なのかな
工夫っていうのは色んなサービスを比較したとかではなくて
コネクションプーラーの話とかってなんかでしたのかなと思ってて
これはもう実際に社内のツールもそうだし実際に自宅とかでやってる中で
こういう技術選定してみましょうかみたいな話になって
実際に使ってる中で検証する中でってことか
そうそうそうやってる中で気づくみたいな
なるほどね
今のっていうのはドキュメントとかに載ってないわけではないんですけど
クラウドフレアのドキュメントには載ってるし
スーパーベースのドキュメントには載ってるしで
どっちを見てちゃんと一個一個付け合わせてみると
ここにそこが生まれそうだなみたいなのが見つけられるんですけど
そういうのって起きないと分かりにくいってところがあって
これはある意味ノウハウなのかなっていう
なるほどね
なのでスーパーベース自体が悪いってわけでも
クラウドフレアのハイパードライブの仕組みが悪いってわけでもないのかな
はいはいはいはい
そういう意味でだからそういうことかそんなになんだろう
めっちゃ良くないよねみたいな感じではない
そうあくまで設定ミスってたよね
結局言うと設定ミスってたよねみたいな話ではあるんですけど
こういう接続が増えてデータベース落ちちゃいましたというか
ウェブからアプリケーションからデータベースに接続できなくなっちゃいましたっていうのは
運用してると結構言うても起きるんですよ
他の会社さんとかでも業務システムで月末月初の請求業務とかが
一気にみんなこう業務システムに登録とかすると
ターバー落ちるとかデータベースに接続できなくなるっていうのが起きたり
スパイク的に上がった時にってことね
そういうだから本当にピンポイントで
HKS的に落ちるみたいなのが起こることもあるのは
運用してて日常茶飯事ではあるので
一個一個問題を解決していく
解決するときにノウハウとして蓄積されていくもの
思ってますね
どういうことか
なんかその設定の話は
分かってたらいけるっていう話な気がしてて
60とかっていうのがどれくらいのあれなのかが分からないっていうのもあって
実際それって実用的なのかとか
結構さっき言った業務システムでスパイク的になるようなシステムの接続本数が
32本だったりするんです
これは本数が重要ではないんですよね実は
データベースがどれだけ高速にデータを処理できるかの方がやっぱり重要で
要は本数少なくても高速にレスポンス返せるんだったら問題にならない
要はその60本の中でパンパンパンパンリクエストとレスポンス返してれば
渋滞は起きない
だから60本を1000人が使おうとして
その1000人が使おうとしたときに
待機になるだけなのか
だからデータベース究極的に言うと言い過ぎかもしれないけど
1本でも捌ける量はそれなりにあるみたいな感じなのか
簡単なリクエストであればみたいな
全然あるなので1本とか本当に5本とかのときもあると思うし
それがどうやったらスピードが早く捌けるかっていうと
データベースの単純なインスタンス 要はパソコンとしてのスペックを上げるとか
あとはデータベースを複数用意するとか
あとはアプリケーションとかデータベースに登録するデータ設計的に
高速に検索できるようにするとか
いろんな方法があって
なるほど
なので接続本数が全てではなくて
チューニングをやっていかないと
どんなにいいデータベース使ってたりとか
どんなに本数儲けても死ぬときは死ぬみたいな感じなの
そういうことね
はいはい
そういうことか
わかりました
なんかだいぶ理解できましたね
本当になので
D1とSupabaseの使い分け
小さな業務システムとか作るんだったらD1でもいいと思うけど
ちょっと将来的なところも考えようかなと思ったときは
スーパーベースはかなりいい選択肢になるんじゃないかなと
僕は思ってますね
なるほどね
ついでにストレージサーバーが使えたりとか
リアルタイムの
ウェブソケットみたいな通信を作ることもできたりして
なんか付随的な便利機能があったりするので
使ってみてもいいと思う
ちょっとそっち側使おうとすると追加課金入って高いなとか
気持ちになったりするんですけど
そのIPアドレスの問題ってさ
どれくらい重要なんだろうみたいな
重要というか
結局通信するものの問題みたいな感じなのかな
なんかそう
業務の作るシステムの性質によりけりで
本当に機微のあるデータを扱うとかに来ると
やっぱりそこは抑えておいた方がいいとか
最近だとやっぱりセキュリティの話題というか
脆弱性をつかれる問題が多いので
絞れるなら絶対絞っておいた方がいいなって思うし
はいはい
けど完全にその事業が何を大事にするかというか
セキュリティは大事にしていないって話ではないんですけど
やっぱりスピードとかコストとかとの兼ね合いなのかなとは思ってます
何とも言えない回答になってますけど
うんうんうん
けどそれなるほどね
そっか思ったけど
クラウドフレアワーカーでエージェントが立ってて
うちのシステムとかだとクラウドランが間に挟まって
データベースにアクセスしてるみたいな
けど結局そのクラウドラン側は
いろんなクライアントからアクセスがあるから
結局IPアドレス制限かけれないっていう領域は
同であれあるもんね
そこにデータベースに直通してるのかぐらいの差でしかない
それはそうなんだけど
クラウドランに関してはそれこそロードバランサーとかを経由してるので
IPアドレスをクラウドラン自体固定できるので
例えばクラウドランからデータベースへのアクセスは
IP制限かけるとかもできるし
それはそうかもしれないけど
どこかしらにその口はあるというか
それはねどのシステムもそうなんだけどね
その辺がセキュリティ周りのいつも思うところだね
結局ユーザーが利用しようとするとどこかには口があるから
できるだけ複雑化してるように見えちゃうというか
セキュリティって本当に難しくて
口は絶対あるというか
ユーザーがサービスを使うという意味合いでは
100%どこかに1個穴はあって
戦いとしては100個ある穴を僕らは全部防いで
1個だけに集約していくとかにして
セキュリティを担保するとかにしていかなきゃいけないし
穴が1個でもあってどこかそこ突っつけそうなものがあったら
攻撃する人はそこだけ突っついてればいけちゃうからっていうのもあるので
そういうどこに穴があるのかっていうのは認識しながら
防げるのは防ぐし
危ないものだったらちゃんと監視する体制とか
危ない穴が例えば開けるしかないってなった時も
そこ穴が監視するとか
気づける状態を作るとかして
対策していくしかないんだなって思いますけど
だから結局
例えばですけど
クラウドフレアワーカーみたいに
クラウドフレアワーカーとスーパーベースの相性が悪いって書いてた人のように考える場合は
スーパーベース側にきつめのRLSをかけておいて
結局認証とかはするっていう前提だから
これって要するに例えば僕がパスワードを
他のサービスとか経由で漏えいしました
それでアカウントの取りみたいなのがされた時に
どの影響範囲になるか
その人が乗っ取られて
その人のアカウントの分だけに
被害が収まるのか
もしくはRLSガチガチにしておいて
ガチガチというか緩めになってたらもちろんきついよねみたいなのが
スーパーベースが結構よく注意書きとして挙げてるところで
それだからスーパーベースが
クライアントからアクセスする前提であるからみたいな感じも
ありって感じなのかな
逆にうちの構成みたいな感じで
一回違うサーバー経由して
それでIPアドレス口制限してるみたいなのだったら
業務レベルセキュリティを
RLSをある程度可用性の高い状態に
設定しておいてもいいよねみたいな感じの
本当にそう
っていういいところの塩梅というか
構成によって結構変わりそうだねそういう意味では
相当変わる
そういう技術ブログとか見てても
これが対象悪かったから微妙だった
ユースケースとして当てはまらなかった
構成として当てはまらなかったっていうのも結構あったりするし
そこが設計のしところというか
最近思ったのがAIにいて無所得になるなと思ったけど
そういう包括的に考えて
塩梅をつけるっていうのは
AIにまだ難しい領域だし
ギリギリエンジニアとして
価値を立てるポイントなのかなって思ったりするけど
そういうことやね
この記事を書いた方は多分
多分スーパーベースのクライアントから
アクセスできるよみたいな特性とは違う
もうちょっとガチガチの
データベースとしての価値を求めてたから
こういう感じもあるのかな
結構スーパーベースとか使ってて分かったけど
そのサービスの思想みたいなのもあるから
そこの思想に同意できるかっていうのも結構大事だなって思って
ということやな
解決策この人も書いてるね
解決策としてクラウドフレアワーカーズ×クラウドフレアD1を使うっていうパターンか
固定IPを持つサーバー×スーパーベースを使うっていう
このどちらかですよね
それはそうだよなって感じ
あとはプロキシサーバーをどっかに用意するっていうのも
一個やり方あるかもしれないね
固定IPのサーバーを中間サーバーとして設けて
もしかしたらあるかもしれない
なるほどね
それで言うとクラウドフレアワーカーズ×クラウドフレアとスーパーベースが
相性が良いか悪いかはちょっと何か
場合によるっていう
場合による
主題というか
でも何かね場合によるのはもちろんなんだけど
じゃあそれってSQLiteを採用しますか
それ以外のRDBを使いますかっていう選択肢を取るときには
もう何か他のRDB
SQLとかPostgresを使うんだったら
一番その中で相性が良いのはスーパーベースかなって感じの話かな
なるほどね
他のデータベースのサービスは
やっぱりそういう意味で言うとコストとかスケーラビリティとか
あとはリージョンの選択肢とか
そういうところでスーパーベースに勝てない部分があるなって感じてるので
そういうことやねてかそもそもクラウドフレアワーカーズを
使うみたいな前提に立ったときに
ほとんどのケースでだからこのIPアドレスを禁じ始めたら
無理みたいな話
無理っすよだからそもそも
そういうことやね別にスーパーベースとかそういう話じゃない
そうじゃないですよだから
だから何を求めてるかによってそもそも思想として合致しないじゃんみたいな話が起きてるんでこれは
そういうことやね
なかなかいい記事をありがとうございます
言いたい気持ちはわかる
気持ちはわかる
難しいなけどいい勉強になりましたありがとうございます
スーパーベースデータベースの
スーパーベースだとデータベースの容量が8ギガが
まず25ドルのプランで使えるのが
8ギガまでなんですよ
そこを超えると1ギガあたり0.0125ドルぐらい
かかる
1ギガあたりでそれぐらいなんで全然安いかな
AWSとかよりもちょっと安い他のデータベースサーバーとかちょっとだけ安いんですよ
なのでそこをそういう風にストレージを増やしていくことも今後できるんで
データがどんどん蓄積してたまっていく系のサービスとかでも
割と長期で運用できるんじゃないかなっていう風に思ってますよね
結構でかいんだそれは
だってねやっぱストレージってお金かかりますからデータがたまってくるとお金どんどんかかってくる
それがしかも何ギガあったら毎月からみたいな
っていうよりはこの8ギガのディスクサイズっていうのが
さっき話したように
例えば100万レコードとかが入ってくるような
一つのテーブルに100万レコードが入ってくるような業務システムを1年間運用すると1ギガとか2ギガが増えるよねみたいな話なので
大きいなって思う場合もあれば
サービスの性質によっては小っちゃいなって思うかもしれない
僕がスタートアップとして立ち上げて
初期運用する上では12分なのかなって思ってるし
あとは増やせるっていう
余地が残されてるから安心
ただD1とかは10ギガで頭打ちなので
そもそもデータベースを分散的に構築しなきゃいけないよねって別の難易度が生まれるようなとか
そういうのもあったり
なるほどね
D1とかターソとかはどっちかというと
ユーザーが自分でシステムを作って
こちら側でどうするみたいなというよりはユーザーに委ねるような
クラウドフレアOSとか
ちょっと違うかもしれないけど
クラウドデザインにデータベースを追加しようみたいなときの戦略
サービスのコアから離れたところでユーザーが自分で使うためのデータベースとして
用意してあげるみたいなユースケースっぽいよね
それこそノーコードサービスとして
僕らがサービス提供するときのデータベースとして
ユーザーが自由に書き換えできるデータベースとして提供してあげるとか
そっち向けだとかなり有望ですよね
だって中央集権的にこういうテーブル定義でみたいなやったら結構大変そうやもんね
それはもう無理だと思うね
基本的な業務システムとかSaaSを提供しようとかってなると
中央集権的なものにはなるからちょっと耐えにくいなみたいなのは生まれやすい感じで
あとはサービスの性質とかコンセプトとして
分散型として捉えてクラウドフレアOS的な使い方だよねみたいなイメージだとすると
結構有望というかさっき言ってた許容量とかも含めて
別に一社で使うぐらい業務システムに使うぐらいだったら
めっちゃデータ増えてもみたいなところもあるよなとか
もし店舗がめちゃくちゃ多いんですだったら店舗ごとに用意したらいいかみたいなとかかもしれないしみたいな
そのくらいで済みそうやもんね
データベース分散させてそういう作りをすると
横断的に分析したいねみたいな要件が降ってきたときに積むみたいなのもあって
なかなか辛い気持ちにもなったりするんだけど
結構サービスを作り出すと意外といろんな当初想定しなかったものが欲しくなったりするもんで
そこをどこまで予測しつくるかっていうのが開発の難しさでもありますよね
ありがとうございますある程度僕も理解が進みました
こんなもんですかね今日は
ありがとうございました
本日もAI駆動開発部の日常をお聞きいただきありがとうございました
いかがでしたでしょうか今回はデータベースの選定についての話だったんですけれども
僕自身も結構知らないことも多くてすごく学びがあったので
参考になる方もいるんじゃないかなというふうに思っております
こんな感じでいつもAI駆動開発をする上で
必要な知識知見を阿部ちゃんに聞いたりとか
あとは最近のAI何がいいよねみたいな話とかですね
そういった話をしております
このPodcastを気に入ってくれた方はいいねやフォロー高評価ぜひお願いいたします
それではまた次回もお楽しみくださいバイバイ
