Cloudflareの低コストとサービス全体像
こんにちは、AI駆動開発部の日常へようこそ。このポッドキャストは、日々AI駆動開発を行う企業家の山本とエンジニアの阿部が、AI駆動開発のリアルを緩く語り合う番組です。
はい、じゃあよろしくお願いします。
お願いします。
じゃあ今回は、ちょっと僕の疑問というか、気になっていることについて、ちょっと阿部ちゃんに答えてもらう回になればなというふうに思っているんですけれども、
最近クラウドフレアがね、すごい最近どころじゃないけど、最近に始まった話ではないけど、結構話題に上がることが増えているなというふうに思っているんですけど、
うちもサービスでいろいろ使ったりとかしていると思うんですけれども、実際何が便利なのかとか、どういう時に何が使えるのかみたいな話を聞けたらいいかなというふうに思っております。
あんまりちゃんと分かってないっていうのが前提としてあって、何となく分かっているのは、激安です。激安で、デュアラブルオブジェクトっていうのがどうやらすごい仕組みらしいっていうのと、
あと、環境的に動かせるプログラムにすごい制約がある。昔はもっと制約があったけど、最近ちょっとある程度実用できるぐらいまでになってきたみたいなのと、
あとはAIエージェントを動かすのにすごく優れた仕組みであるっていう、その辺はふわっと走ってるみたいな感じなんですけど、全体感と詳細を教えてくれるといいのかな、デュアラブルオブジェクトって何だろうっていうのと、
あとワーカーとかD1とか、R2って何だろうみたいなとか、その辺の話とか、クラウドフレアドメイン取るの簡単とかって言われてたりするけど、
ドットJP系は取れないから辛いよみたいな話とかもいろいろあると思うんですけど、クラウドフレアのちょっとした便利機能みたいな話とか、その辺の話が聞けると嬉しいかなと思っております。ちょっと全体感から聞きたいかな、イメージ。
全体感か。クラウドフレアね、まさに最初に山ちゃんが言ってた印象の部分で言うとその通りだなっていうのは、とにかく安いんですよ。もうあり得ないぐらい安くて。
これまでってやっぱりサーバーを立ててユーザーが見れるウェブ画面を配信するってなると、どんなに安いクラウドでも10ドルとか20ドルとかは当然のようにかかるようなものがあって、
例えばAWSとかでサーバーを立てようとすると、安い構成にしても30ドルぐらいはかかるよねとか、あとはXサーバーとかお名前ドットコムとかでもレンタルサーバーっていってサーバー借りることができるんだけど、あれも安くても1500円とかまさにかかるっていう大前提がある中で、
クラウドフレアって基本的にサービスの全体を使うにあたって、無料でもまずだいたい個人利用ぐらいだったら全然余裕で、本番サービスとして稼働するにあたってもだいたい5ドルぐらいで、5ドルのペイドプランっていうのがあって、それの支払いさえしてしまえば割と何でもできちゃうよっていうところがまずあるっていうところがあるので。
そこで言うとあれかな、15ドル20ドルって安いから、インパクト的にスケールした結果も安いのか、始めは個人開発レベルでそういうの安いよねみたいな、けど15ドルか5ドルだったらそんなだなみたいな印象を受けたんですよね。
なるほどね。
それっていうのはやっぱりデータベースが非常に高価であったりとか、あとはAWSだと特にネットワークの利用料金が結構高かったりして、転送料料金みたいなところで、それだけで数万いったりするんですけど、クラウドフレアって結構転送料課金っていうのがほぼないっていうのが多くて、
例えばR2だとストレージに画像とかファイルとか置いたとしても、それを読み出したりして、転送料っていってデータ転送をするときに発生する課金額っていうのがゼロで済むっていうのがあって、
これをAWSでやろうとすると安いクラウドフロントっていうのを使ったとしても転送料課金がかかって結構コスト被害するんですけど、そういうスケールしたときにも常に基本的に5ドルで収まるっていうところも結構メリットっちゃメリットですよね。
10万とか揃うくらい、サービスによっては数十万とかクラスでいくこともあると思うけど、5ドルっていうのを行き地としてもっと超えていくみたいなのってある?次の段階ってある?
あるっちゃあると思ってて、より高トラフィックというか、例えばだけど1日に数千人が乗用しているようなサービスとかと、やっぱりクラウドフレアの単一のワーカーだけだと抱えきれないので、分散する仕組みを作ったりとかっていうのはどうしても必要になってくるっていうのはあるかな。
だからスタート時点で、例えばスタートアップで何かプロダクトを立ち上げて、いきなり数千人数万人が使わない前提のシステムとかだと全然5ドルの中に収まるけど、それが数千の広範規模とか、毎日も数万人が使えますよっていうシステムだとちょっと抱えきれないよねっていうぐらいのはありますけど、
でも逆に言うとそれまでは全然5ドルで済むっていうのがクラウドフレアっていう感じかな。
なるほど。それを超えたらいきなり高くなるみたいなのはあるのかな?
そうなると重量課金になるので、結構多分コストはかかってくることにはなってくるとは思うから、そうなった時には分散する仕組みをもうちょっとチューニングしていくとか、それこそインフラは移動するとかっていうのは考えていったほうがいいんですよね。
めちゃくちゃ利用者が多いシステムに関しては、今っていわゆるサーバレスで結構安いよねっていうので、ラムダとかそれこそクラウドフレアのワーカーズとか、あとはクラウドランっていうのが結構選択肢として上がってきていて、
既存のAWS EC2みたいな常駐サーバーを建てるっていうのはやっぱり高いからサーバレスで時間課金のやつを使った方が安いよねっていう話になりがちで、実際にそうなんですけど、
利用者が増えていったりとか、もう24時間ずっと使われっぱなしのシステムとかを作るのであれば、EC2の方が逆に安くなるっていうケースも出てくるんですよ。
なのでそこはもう利用者とか、どれだけ常にプロセスが稼働するシステムなのかにも寄ってくるっていうのは。
ただですね、クラウドフレアじゃなんでそういうところはありつつも、クラウドフレア嬉しいのは、
例えば社内システムを作るとか、スタートアップでPOCだったりMVPを回そうっていう、小規模のプロダクトをポンポン立ち上げるタイミングにおいては、
クラウドフレアが通り一遍できるものは欲しいものは用意してくれていて、
かつ低コストっていうところが結構嬉しいのかなって思ってて。
例えばクラウドフレアだと、もともとはCDN屋さん、ネットワーク屋さんだったので、
ドメインをクラウドフレアでそのまま購入できる。
しかもドメインはサービス運営調整費みたいな上乗せ課金みたいなのはなくて、
ドメインの原価分で購入できるっていう、かなりお得に購入できるっていう部分と、
まずはドメインを用意できるじゃないですか。
ドメインを用意したら、そのままそれをホスティングするっていうワーカーズっていうのを使えて、
それがさっき言ってた毎日数千人使うぐらいだったら全然余裕で耐えれるよねみたいなシステムを立てれて、
そのワーカーズを立てたときに、やっぱり単純にサーバーだけがあればいいわけではなくて、
サーバーを使うためにはデータベースが必要だよねとか、クラウドストレージが必要になるよねとか、
より高速化するためにはKVキャッシュの機構が必要だよねとか、いろいろあるんですけど、
そういったものも全部一個一個独立して提供していてくれて、
さっき言ったデータベースはクラウドフレアD1、ストレージサーバーはクラウドフレアR2とか、
あとはバッジ処理っていうのもシステムを作るときに地味に必要になるんですけど、
バッジ処理っていうことかっていうと、
普段ユーザーがページアクセスして何かボタンポチポチ操作するだけじゃなくて、
日々に集計処理とかデータ処理を走らせたくなることって運営してるってことがあるんですけど、
それをやるためにはバッジのジョブ給っていう仕組みが必要だと思うんですけども、
それはクラウドフレアワークフローっていうので用意されていてとか、
そういう感じで、とりあえずプロジェクトを立ち上げてサービスを提供するために、
何か必要になるようなみたいなものは全部揃っていて、
しかもそれらが5ドルぐらいでっていうのがかなり大きい価値になってるんじゃないかなっていうところで、
クラウドフレアの全体感としてはこんな感じですよねっていうところ。
Cloudflareを選ぶ事業上のメリット
なるほど。もうちょっと聞きたいことが2つあって、
まずクラウドフレアを、今コストの話がメインだったと思うんですけど、
技術的にクラウドフレアを選定したときの、ちゃんと事業戦略に乗せれるメリットが享受できるとかもあるのかなっていうのが1つあって、
コストとかは正直、用意の1つではあるけど、別に完全にその事業のサービス価値を決定づけるものにはなんないかなみたいなところも何となく思っていて、
それがしかもある程度、重量課金とは言えば最終的にはEC2の方が安い可能性もあるみたいなのは別に、あえてクラウドフレアを選ぶ必要は別にいいみたいな感じに思っちゃうなっていうのをちょっと思っていて、
むしろ今全部まるっとやれるっていうことは逆に言うと依存度がすごく高くなり安いのかなみたいなデメリットのようにも聞こえるなっていうのがあるので、
クラウドフレアを選ぶってなった時の、普通だったらこういう戦略取れないけど取れるようになるみたいなものがあったりすんのかなみたいな、あればというか思いついたらみたいなところで、それ1つ聞きたいのと、
あともう1つが、とはいえうちもクラウドフレアで動かしてるやつと、それこそクラウドランにしてるとかもあるし、AIエージェントを動かすのだけクラウドフレアのワーカーにしてて、
実際の本体はクラウドランにしてるみたいなのがあったかなと思ってて、その辺のクラウドフレアで使う、こういう時あんま向いてないかもなみたいなのというか、選んでないことも多い印象はあるんだよね、
だからどっちかというと2つちょっと繋がるけど、あえて選ぶ理由とこういう時ちょっと微妙だよねみたいなところとっていう
いやでもなんかね、結局のところクラウドフレアのいいところ、さっきそのコストっていうところで、結局のところみたいなところはあったと思うけど、やっぱりどこまで行ってもコストはクラウドフレアの価値というか、
別にコスト気にしなくていいよねぐらいとか、大規模なサービスになっていったって場合においては、もう明確にそれこそAWS選択した方がよりセキュリティロールの仕組み上とかでもAWSの方が管理しやすいとかで選択したくなるよねっていうのが出てくると思うので、
どっちかというとやっぱり初期フェーズにアプリケーション立ち上げが、ウェブアプリケーションの立ち上げが容易にできるっていうところがクラウドフレアの価値になってるのかなと思っていて。
なるほど。
あとは、これは単純にサービスを提供するだけじゃなくて、今ってAIによって社内の効率化っていうのをやるインセンティブって結構増してきているかなと思っていて。
要はAIにクラウドコードとか使って、今までは手作業していたものをスプレッドシートの管理をAIにしてもらおうとか、そういうのが結構いろんなところで起きてると思うんですけど。
スプレッドシートだけじゃ管理、結局どこまで行っても面倒くさくなるよねみたいな問題が起きた時に、やっぱり社内のダッシュボードを作りたいなとか管理用のシステムを作りたいなみたいな話。
どこそこかでいろいろ出てくると思うんですけど、じゃあそれをどこに置くかみたいな。
ウェブサービスみたいな感じでダッシュボードを作るけど、じゃあそれをチームメンバー全員でどうやって使おうかみたいな話になった時に、それこそクラウドフレアっていうのが選択肢に上がりやすいのかなっていう風に思ってまして。
それこそバイブコーディングとかで従業員の人がいろいろシステムを作るじゃないですか。
で、そうなった時に結構セキュリティ的なリスクもあるから、認証認可とかログインの仕組み作りたいよねとか言って多分作ったりすると思うんですけど、
それ自体も本当にセキュアなのかどうかって正直本当のエンジニアじゃないとちょっとチェック難しいなとか、
一末の不安を抱えながら公開するのかなみたいな、ホスティングするのかなみたいなことになると思うんですけど、
そこで結構ありがたいのがクラウドフレアにはクラウドフレアアクセスっていう、
クラウドフレア側が認証と認可を受け持ってくれる仕組みが用意されていて、
これはサイトとかに例えばワードプレスとかを立ち上げてベーシック認証を入れて、
テスト期間中はベーシック認証でみんなiPathでログインできるよねみたいな仕組みと似ているんですけど、
このクラウドフレアに立てたウェブアプリケーションの前段に認証認可の仕組み、クラウドフレアアクセスが間に挟まるっていう仕組みを設けることができて、
これを入れるだけでメールアドレスログインだったり、マルチファクターオースを入れたりとか、
そもそも社内で作ったシステムにアクセスできなくするっていうような仕組みを前段に構えることができるので、
開発をするときに認証認可について考えなきゃいけないよねっていう話ではなくて、
前段にブロッカーを1個くっつければOKになるっていうので、
とりあえず開発してもらって業務効率化をして、それをチーム全体に共有するにはクラウドフレアにポンと上げれば済むよねみたいな仕組みも作りやすい。
それによって業務の効率化が加速するよねっていうのは1個大きなポイントなんじゃないかなっていう風に個人的には思いますね。
それを作るにあたって、これは開発体験的な部分、人間的な開発体験の良さっていうところは、
すなわちAIにとっての開発体験の良さにつながってくるかなと思っているんですけど、
クラウドフレアが提供している、ちょうど先週ぐらいに配信になるよねみたいな話が上がってきてるんですけど、
ラングラーっていうCLIがクラウドフレアを開発するためにツールキットとして提供されていて、
あれをパソコンにインストールしているだけで、ほとんどのリソースを作成したり設定をすることができるようになっていて、
AIに対してこういうシステムを作りたいんだけどっていう話をするだけでも、
ワーカーとか用意してデプロイまで一気通貫でやってくれるっていうところも結構ありがたいのかなっていうふうに思ってますね。
その辺がやっぱりクラウドフレアの強みであって、価値になるのかなっていう。
Durable Objectsと状態を持つサーバレス
なるほど。ちなみにあとデュアラブルオブジェクトはすごいよねみたいな話、前安部ちゃん知ってたと思うけど、それは何がすごいと思ってるのかなっていう。
あれはね、今までのサーバレスの仕組みのちょっと延長っぽいのがデュアラブルオブジェクトなんですけど、
それでいて、もう今までのサーバレスではできなかったことをちゃんとやりきってくれてるのがデュアラブルオブジェクトかなっていうふうに思ってて。
なんかこれって、僕がデュアラブルオブジェクトすごいなって思ったのが、
AIエージェントをクラウドで動かすためにどういう風なアーキテクチャ設計すればいいのかなっていうのをいろいろ考えた末に行き着いたのがデュアラブルオブジェクトで、それですごいなっていうふうに思ってたんですけど。
まず、そもそもなんですけど、さっきも話したようにコスト的な部分を考えると、サーバレスを選択するのが基本的な立ち上げ機における戦略になってて、いきなりEC2とかVPSを契約して、
共有サーバー契約して立てるってなると、めちゃくちゃコストかかるよねっていうので、あんまり取りにくいんですけど、であればまずはサーバレスを選択してやろうっていう話になるんですけど、サーバレスって安くて便利なんですけど、いろんな課題がありますと。
その課題っていうのが、やっぱりサーバーが常駐していないので、必ずプロセスっていうのがユーザーがアクセスしてるときにしか動いてくれない。要はユーザーがリクエストを投げて、投げっぱなしにして切断したとしても、裏で動いてくれるみたいなものはないんですよ。
なのでリクエスト1サーバーみたいな感じになって、ポンポンサーバーが複数ユーザーごととかリクエストごとに起動して処理して返して終わりっていうのが、でシャットダウン。厳密に言うとシャットダウンのタイミングとかはいろいろ遅れてやることもできたりとか、いろいろあるんですけど、
サーバレスの基本的なものっていうのは、そういう1リクエスト1プロセスでレスポンス返したら終了っていう仕組みになっているんですけど、デュアラブルオブジェクトは全くそういうものとはちょっと近くて、一見サーバレスなんですけど、状態を持つことができるっていうのと、
その状態に固定でアクセスできるっていう、このEC2みたいなずっと立ち続けてそこにユーザーがアクセスしてやり取りするみたいなものと、サーバレスの合いのこみたいな感じになっていて、それは結構嬉しいっていうような話なんですよね。
今までのサーバレスとかにすると何が辛いかっていうと、やっぱりさっき言ったように1回立ち上がって1リクエストごとにショットダウンされてしまうので、例えばAIエージェントをクラウドで動かそうみたいな話になったときに、ユーザーが例えば今日の天気は?って聞いて、そのままタブを閉じちゃうと、
AIがその天気について、例えばウェザーニュースに検索をかけに行ったりとか、いろいろ作業をしているのにユーザーがタブを閉じてリクエストを遮断されたことによって、プロセスごと落ちて、AIが急停止しちゃうっていうことが起きてしまうんですよ。
それが、デュアラブルオブジェクトはユーザーの切断があったとしてもずっと稼働して続けてくるっていうのがあって、裏側では。なので、またアクセスしてあげれば、さっき今日の天気は?って聞いた結果を最後まで走り切って見に行くことができるんですよね。
しかも、ただ常駐しているだけではなくて、今まではクラウドフレアワーカーとかラムダとかクラウドランというサーバレスっていうのは、あくまでもプロセスしか提供してくれない。サーバーのプロセスしか提供してくれないので、状態も維持してくれないんですよ。
リクエストして切断されたらデータは吹き飛ぶしっていう状態があるので、サーバレスはサーバーとデータベースは常に分離していて、アクセスが途絶えたらちゃんとデータベースを保存しないと、そのデータすら揮発してしまうみたいな課題があるので、必ずデータベースとセットで提供してあげる必要があったんですけど、デュアラブルオブジェクトはサーバーの中にデータベースも一緒に共存してくれるんですよ。
状態もちゃんと持っておいてくれるっていうところがあって、なのでアクセスして一回閉じたとしても状態は維持してくれてるので、再度アクセスしたらさっきの状態をちゃんと保存しておいてくれているみたいな。
その状態がデータベースに同期されてるというか、みたいな状態をもう勝手にやってくれてるみたいな感じってこと?それは書かないといけない?
データベース、そうだね。状態を保持してくれる機能を提供してくれるんだけど、どうやって状態を保持するかはもちろんこっちで書かなきゃいけない。
例えばデータベースの定義は何ですかとか、書き込むタイミングはどうですかっていうのは、もちろんこっちがアプリケーションとして実装しなきゃいけないんだけど、
それをあまり検出せずとも、一応保持はしてくれているし、あとはSQLiteっていうのがそのデュアラブルオブジェクトの中に内蔵されていて、保存するとそこに永続化されるっていうところがあるっていうのと、
あとはそれとは違うインメモリ、いわゆる起発性の高いインメモリとしても保存してくれているので、インスタンスが閉じない限りはインメモリにそのまま残り続けることもできるっていうところがありますね。
だから例えばだけど、今インメモリって言ったのはどういうことかっていうと、デュアラブルオブジェクトの中で単純なデータベース的な保存っていうのはSQLiteに読み書きすればいいんですけど、
例えばファイルを読み書きしたいってなったときに、デュアラブルオブジェクト内でファイルの読み書きをして一時保存みたいなこともできるような感じになって、あとはそれはインスタンスを閉じるとファイルは起発しちゃうのであれなんですけど、一応そういう形で保持してくれているっていう。
インスタンスが維持されていれば、そのDBのD1、SQLiteの情報とともにユーザーが再接続できるようになっているみたいな状態っていうことなのかな。
なるほど。で、けど本来、他のサーバーレスとかだったら、もう一回ユーザーとの接続が切れたら、データの海の木材と消えていくみたいな感じの状態だから、処理だけを預けるみたいなのが今までのサーバーレスの実装のイメージというか任せられるもののイメージだったけど、
もう一回ユーザーが再接続できることを考えると、もうちょっとなんかやれること増えたよねみたいな。で、それがちょうどAIエージェントを動かす仕組みとうまくマッチしているみたいな状況ですみたいな感じの。
まさにそうで、今ではそうプロセスしかサーバーレスには任せることができなかった。だからプロセス、処理とデータベースというのはかなり独立した存在だったんだけど、それを一緒に。
やろうとしたらできるけどっていう感じだったけどっていう感じか。それはけどあれなのかな、そのD1っていう、それぞれ隔離でエスキューライトを個別に持てるみたいな。
なんかそれを多分クラウドフレア側がビジネスモデル上、そうしてもまあ大丈夫だよねみたいな感じにしてくれてるがゆえになり立ってるみたいな感じなのかな。
順番としてはデュアラブルオブジェクトがあって、その仕組みを使ってD1が動いてるんだよね。
だからデュアラブルオブジェクトがすごいっていうのはあるんだけど、それはクラウドフレアがV8アイソレートっていうJavaScriptを動かすランタイムをチューニングしていて、
それを世界のエッジサーバーで超軽量に超高速に動かせるっていう、まずCDN屋さんをやっていたことによる大規模なインフラを持っていて、
そこにJavaScriptだけとにかく動かせる、そしてそれを最適にするっていう、選択と集中による尖り切った仕組みを作ったことによって、
多分デュアラブルオブジェクトっていうものを作れるようになって。
それはどういうことかっていうと、デュアラブルオブジェクトっていうのは常駐サーバー的なんだけど、
状態を保持できるっていう、エッジサーバーとかではキャッシュとか状態保持するような仕組みとかを作る必要があるんだけど、
それの多分上に乗っかっている仕組みでデュアラブルオブジェクトっていうのを展開できるようになっていて、
デュアラブルオブジェクトって今までできなかったサーバーレスと状態保持っていうのを掛け合わせたことによって、
D1っていうデータベースのレイヤーを新しく、データベースっていうのは常に状態維持しなきゃいけないものなんだけど、
D1自体SQLiteで超軽量で作られていて、その立ち上げコストが低くなっているっていうところ。
そのデュアラブルオブジェクトを基盤にしているからD1が作れるようになったよねっていうところがあるんだと思うね。
デュアラブルオブジェクトっていうその仕組みがあることによって、D1だけじゃなくて、さっき言ったそのワークフロー、
ジョブ級的なサーバーの裏側で別で処理するような仕組みとか、
あとはアプリケーション側で使うキャッシュ機構みたいなキーバリューキャッシュっていう仕組みとか、
あとは最近だとクラウドフレアでGoとかPythonを動かすためにはクラウドフレアコンテナーズっていうアプリケーションが用意されていて、
それはドッカーコンテナーみたいな形に、要はイメージとして焼き付けたGoのアプリケーションとかPythonを動かす仕組みがあるんだけど、
それもデュアラブルオブジェクトの仕組みを使っていて、デュアラブルオブジェクトの中に一旦コンテナを置いてそこで動かせばいいよねみたいな、
そういう仕組みで動いてて、全ての最近のクラウドフレアが出してくるサービスの中核にいるのがデュアラブルオブジェクトみたいな感じになっている。
仮想環境に似てる感じ?
マイクロVMみたいな感じと割と違って、サーバーを維持できるっていうところがまさに仮想環境的なものだと思うんだけど、
それがこの低コストで展開できているっていうところ。
だからクラウドフレアとかで、それこそAWSでやろうとした時に結構構成複雑になるなっていうところがあって、
要はサーバーを常駐させなきゃいけないとか、
サーバーを常駐させなきゃいけないってなった時に取れる選択肢ってEC2とかAWSのEC2、ECSみたいな感じになる。
結局ユーザーがたくさんアクセスをしたいけど、
一つのEC2インスタンス、要はサーバー1個に対して立ち上げて、
そのサーバー1個だけで数千円の運用コストがかかるのに、
その1個のサーバー、パソコンに対して全員がアクセスしたら普通にパンクしちゃうじゃないですか、パソコンが。
そこでAIエージェントを回そうとか、そういうことをすること自体が結構無理筋に近くて。
じゃあそうなってくるとやっぱりサーバーレスみたいなので、
1人が1つの小さなサーバーにアクセスして、それと上手く状態を維持してくれていて、
動き続けてくれるっていうのがもし叶うんであれば、もしラムダとかで動かせるならば、
そうすることでAIエージェントを多数作ったりして、
大分全体像がつかめてきて、今までのVC2とかいわゆるサーバーを1つ立ててみんながアクセスしようとすると、
さっき言ったみたいにアクセス負荷があるから、それなりに高性能なサーバーを用意するか、
もしくはロードバランサーみたいなので、分散処理するみたいなで言っても数台とかに分けてみたいな感じになるから、
しかもそれをいわゆる借り続けないといけないから、ずっと常駐コストというか管理費的な、
家賃を払ってるみたいな状態でしかできなかったんだけど、そこからサーバーレスみたいなのが出てきて、
その動くタイミングだけ瞬間的に立ち上がって、借りた分の利用料課金みたいな感じになってきて、
しかもさらにそれが分散されてるみたいな感じになって、コスト最適化されるようになったんだけど、
起発性が非常に高いみたいな状態になっていて、それとさらに解決策みたいな感じで、今のデュアラブルオブジェクト的な、
サーバーレスで使用したタイミングだけの課金なんだけど、ちゃんと情報が起発性も抑えられていて、
維持できるし、何だったら再接続も可能になっているみたいな感じの、そういう変遷をたどってきているみたいな感じのイメージ。
Cloud Runとの使い分け
なるほど。一方で、うちが作っているサービスとかだと、クラウドランを選択したじゃないですか、阿部ちゃんは。
そうだね。
AIエージェントを動かすところでいうと、クラウドフレアを選択してて、多分それのおかげで、例えばLINEからAIエージェントにアクセスして、
LINEを閉じてても、てかそもそも多分LINEからやろうとしたらその接続を維持できるってことすらできなくなる可能性があるから、
むしろそれがちゃんとLINEを切ってても、もう一回立ち上げ直しても動くような感じになっているとか、
Webページを閉じても、ちゃんと変身がきているみたいな状態を維持できている。それをまたユーザーが閲覧できるみたいな感じになっている。
っていうのはクラウドフレアのさっき言ったメリットだと思うんですけど、なんで本体はクラウドランにしたんだろう。
クラウドランはサーバレスなんですよね。
クラウドランはサーバレスですが、ちょっとね、これがクラウドフレアだと若干不安な要素があるなっていうところがあって、
最近改善されてるんですけど、まず一つがサポートできるランタイムがかなり制限があるっていうところがまずクラウドフレアのネックですよね。
選択と集中をすることによってポストパフォーマンスを上げたり速度を上げたりとか、そういう仕組みを作ってるんですけど、
結果的にやっぱりクラウドフレアでは、クラウドフレアワーカーズとか、いわゆる僕たちがサービスを提供するときに使うサーバレス環境として使える言語っていうのは、
もうJavaScript一択なんですよ。
しかもJavaScriptって言っても、これランタイムがまた複数ありまして、
クラウドフレアがサポートしてるのはV8アイソレートベースの仕組みで、これってJavaScriptの中には大まかに言うとブラウザで動かすためのJavaScriptと、
サーバーで動かすことができるJavaScriptっていうものがあって、
本来はサーバーで使うためのJavaScriptであるNode.jsっていうのを使いたいんですよ。
サーバーで動かすので。
けど、クラウドフレアがサポートするのは基本的にはV8ランタイムって言って、
ブラウザで動かすため、つまり皆さんが今普段使ってるようなChromeとかアパリで動くためのJavaScriptを使ってるんですよ。
なるほど。
そのランタイムの違いによって、僕たちは普段、要はサーバー向けに開発をしてるときに、
クラウドフレアにアップロードして動かそうとかに動かないみたいな問題が多発する。
しかもやっぱりブラウザで動かすためには、より軽量化とか最適化を図るために機能を添えてたりしていて、
要はいろんなファイルの読み書きをしたいよねとか、何か処理を高速化したいよねとか、
こういうモジュールを使いたいよねっていうときに、クラウドフレアだと動かないっていう場合が当時は多くて、1年前とかですね。
そういうところもあって、ちゃんとNode.jsが動くサーバーレスを選択したときに、クラウドランをまずは選択したっていうのが1個ありますね。
技術的な制約というか処理として動かないものが、発生する可能性があるっていうのが、今のシステムとかだと、
僕がわけもわからず開発を始めたものがベースとなって、そこからしっかりちょっと集めていってもらってみたいな感じの、
KFを辿ってるから余計みたいな感じなのかな。
そういうのもありそうだね。それで結構、最初本当はクラウドフレアに置こうとしたりとか、実際に置いたんだけど動かないみたいなのが起きて、
それでしゃあないからっていうのでクラウドランに移動したっていうのが大きいところだよね。
なるほどね。けどそこの依存は絶対マストで必要だから、引き離すのも結構大変だなみたいな感じになって。
結構大きいのはやっぱ認証認可なんだよね。認証認可で使うための暗号化の、暗号化だってハッシュのモジュールっていうのはノードでしかサポートしていなくて、みたいなのがあって。
なるほどね。
そういう仕組みを自前で、さっきクラウドフレアアクセスって認証認可のシステム前段に持ってこれるよ、だからいいよねみたいな話したんだけど、
それなんかやっぱり社内システム専用っぽいところがあって、一般公開するときには内部でちゃんとセキュリティを担保する仕組み作る必要があって、
それやろうとするとちょっとまかないきれないなっていうところもあったので、クラウドフェアから脱却したっていうのはあったんですけど、
実は6月ぐらいかな、クラウドフェアが発表してたのが、ノードJSのサポート、ノードモジュールのサポートが98%ぐらいまでカバーできましたみたいな話をした。
なるほどね。
割とね、カバー率一気にグッと広がってるんで、もしかすると今このタイミングでクラウドフレアで動かすことができるかもしれないぐらいにはなってる。
あと今のそのサービスはリリースタイミングでさ、ちょうど東京リージョンがなくて、なんかDBの書き込みがクソ遅いみたいな感じになってたよね。
それがリリースして1ヶ月後ぐらいに東京リージョンできたみたいな感じになってた。
厳密に言うとクラウドフレアってリージョンはもう全世界にあって、だけどそれを固定化することができないっていうのが。
ランダムで地球の裏側に行っちゃう可能性もあるみたいな感じになっちゃってて、遅い時があって、これ遅すぎて使えないよねみたいな感じになっちゃってっていうのもあったのか。
結構これびっくりするのがやっぱりデータベースとサーバーの位置ってすごく重要で、ちょっと離れてる。
ちょっとって言っても東京とアメリカとかで離れてるだけで、データベースとやり取りするのに200msぐらいかかるので。
スキュエルって1回発行する、ステージを表示するのに10回とか20回ぐらい叩いてる。
もうそれだけで往復してると片道200msなんで往復400ms、それが10回リクエストで4秒かかるみたいな。
そういうのもあって、クラウドフレアでスマートプレスメントっていう機能が最近、最近って言っても半年前ぐらいに公開されて使えるようになったけど、
やっぱりそのリージョン固定できないことによって地球の裏側にリクエスト飛んじゃったみたいな。
まさにそういうのもあってやっぱりクラウドフレアではなくてクラウドラン選択してたのはあってね。
なるほど。そういう意味では今うちのサービスだとクラウドフレアを今例えばリリースするみたいな感じで、
今から開発していくんですみたいな感じだと全部クラウドフレアっていう選択もあったはあったってことなのかな。
そうだね、あったかもしれないかな。
あとね、結構あとうちの会社だとあまりない、うちの今作ってるシステムだとあまりないかもしれないけど、
結構こう処理系が重いか外部接続が多いかっていうので結構まあ変わってくる。
外部との接続が多いよね、でも内部の処理としてはそんなに重くないよねっていうものはそれこそクラウドフレアに置くのめちゃくちゃ適してるんですけど、
例えばアルゴリズムで予定を自動算出しますみたいな、結構重たい処理実は最適化処理で必要ですみたいな、
CPUいっぱい使いますとかっていうのになるとクラウドフレアのCPUってそんなに優秀じゃないというか、
まあすごいライトに作られているので重たい処理はできないんですよね。
なのでだったらクラウドランで動かした方がいいよねみたいな選択肢になったりすると思うんですけど。
なるほどね。
だからマシンのパワーが必要だよねってなったときはやっぱクラウドラン、
あとはそれを安定的に供給したいよねってなるとクラウドランが選択肢に上がるんですけど、
ライトなウェブアプリケーションを作ってライトに配信するとクラウドフレアが一択な状態になる。
なるほど。逆にいわゆるSaaS的な仕組みで仕組みというかサービスを提供するみたいな感じになって、
DBを立ててみたいな感じになるんだとしたらクラウドランでもクラウドフレアでも、
クラウドフレアはDBと一体化しているとはいえSQLiteなので、
どっちかというと本当に瞬間的に使う状態を維持するためのDBのやり取りみたいなのが、
クラウドフレアとデュアルオブジェクトセットにあるDWANとかそういうのの使い道みたいな感じで、
逆に言うとクラウドランは別にDBというかSQLiteとかっぽいのがなくても、
ちゃんとDBサーバー用意してソースするっていう前提に立ったときに、
別にそのデュアルオブジェクトってある必要がないというか、むしろない方がいいみたいな感じの使い分けというか。
大体そんな感じだね。
コールドスタートとコスト比較
あと結構大きいのが、クラウドフレアのワーカードもそうだし、デュアルオブジェクトもそうなんだけど、
コールドスタート問題がかなり少ないっていうところも、的には嬉しいなと思ってて。
コールドスタート問題って何っていう話なんだけど、
これはサーバーレスであるからこそ起きる問題なんですけど、
常駐サーバーとかだと起きない話なんですけど、
コールドスタートって言って、要はサーバーレス、リクエスト来たときに立ち上がって処理してレスポンスを返すっていう仕組みなんで、
立ち上がりがどれだけ早く行えるかによってデュアルに対するレスポンス速度は相当変わるんですけど、
立ち上がるときにどう立ち上がるかなんですけど、
基本的にそもそもアプリケーションを起動する、
要は僕らが開発したアプリケーションを起動する前にPCを起動するみたいな、PC環境を起動するみたいな処理が前段に入ったりするので、
それの立ち上げが複雑になれば複雑になるほど重たくなると。
AWS Lambdaとかって、PythonだったりGoだったりNode.jsだったり何でも起動できるようになってるんですよ。
そういうところもあってなんかわかんないんですけど、やっぱりコールドスタートすっごい遅いんですよね。
コールドスタートするだけに、起動するだけに10秒とか15秒くらいかかったりして、
そこから一人始まって帰ってくるんで、ユーザーがアクセスをずっとしなかったりして、
なんか5分くらい放置してて、次にリクエストが起こると全然レスポンス返ってこないみたいな。
クラウドフレアはコールドスタートがほとんどなくて、
それこそV8で数ミリ秒とかで起動するようになってる。
内部的には数ミリ秒とかで起動するような仕組みになってるので、
本当にサッと起動して帰ってくるっていうところが結構ある。
クラウドランとかはサーバレスでコールドスタートにならないように起こし続けてくれるみたいな仕組みもあって、
それはちょっと課金額が上がるので、コストが上中サーバー的にちょっとかかるよねみたいな。
っていうのはあったりするんですけど、クラウドランはそういうふうなサポートはしてくれてるんですけど、
ラムダとかはなくて、やろうと思えばできるんだけど、それでもやっぱり遅くていくっていう問題もあったりしますね。
そういう嬉しさもクラウドフレアにはある。
クラウドランとクラウドフレアだとクラウドフレアのほうが安い?
クラウドフレアのほうが圧倒的に安いですね。
同じサーバレスでもクラウドフレアのほうが安いんだ。
そうだね。
予約システムとAIエージェントの共有状態
あとさっき話してたデータベースがクラウド、デュアラブルオブジェクトの中に内蔵されているので、
という意味で言うと、本体のマスターのデータベースはどこかD1とかそれこそ別にちゃんとしたものを置いといて、
ある処理だけをデュアラブルオブジェクトに一回処理が始まるタイミングで切り出して、
そこの中でデータをまずは溜め込んで、後でマスターに書き込むみたいな構成も作ることはできるかなと思って、
例えば予約システムを作りたいですみたいな。
お客さんの予約システムを作りたいときに、よくあるのが一つの席を複数のユーザーが奪い合ってしまって競合しちゃう。
それを例えばその日のレストランの予約状況をデータベースからポンと出して、
誰かが処理を開始しようとしたときにポンと出してきてデュアラブルオブジェクトに配置して、
そのレストランのその日の予約アクセスに関しては、全員そこに行くように振り分けておけば、
何人がアクセスしていて、誰が予約を確定しようとしているかを、状態を全員が共有できるようになるんですよ。
それは同期できるってこと?
マスターのデータベースからうまく同期的にすでに?
それはそういう仕組みが用意されているってこと?
デュアラブルオブジェクトには起動するときのイニシャライズの処理とかもあるんですけど、その状態を全員が共有で見れるような仕組みがあって、
ウェブソケットでまず中身を見れるっていうのはそうなんですけど、それを全員が共有するってなると、
じゃあどうやってその変更をみんなが認識するのかっていう話なんですけど、
それはウェブソケットをデュアラブルオブジェクトに複数のユーザー、しかも数百人単位で同時に接続できるようになってて。
要するにAIエージェントとサービスとかでいうと、サブエージェントをバーって立てて、
そのやってるタスクとかをデータベースで共有、それぞれの状態を共有し合えるみたいな状況が作れるっていうのにも認識としてあっている。
たとえばAIだと、僕がセッション開始して、チャットGPTとかでポンって投げたときに、
ヤマダちゃんも同じアカウントにログインしてるけど、別のブラウドとか別のタブでアクセスしてても、
その調査の流れはずっと僕と同じ状態で見れるっていう。
共有してあってるからってことね。
僕らが開発者としてシステムの努力をしなくてもできるようにしてくれてるっていうのがめちゃくちゃすごくて。
サーバーだったらほとんどできない。
なるほど。それはすごいね。
そう。っていうのを全部やりきってくれてるがゆえに、
AIエージェント基盤としてのCloudflare
AIエージェントを動かす基盤としてマッチしているんですよね。
プロセスを開始して、それこそさっき言ったVMのように立ち上がって、
ファイルの読み書きができたりするし、データベースの読み書きができるし。
それをみんなで共有して見れるっていうところがあって。
だからAIエージェントを動かす環境としてもすごく適しているし、
クラウドフレアが最近出したAISDKっていう、AIエージェントを動かす仕組みの開発ツールがあるんですけど、
それも開発してデプロイすると結局デュアラブルオブジェクトに配信されてみたいな。
AIと接続できるようにみたいな。そういう仕組み。
なるほど。ありがとうございます。かなり知見が深まりました。
そうですね。デュアラブルオブジェクトまだまだすごい人がいっぱいあるんですけど。
アイディア次第では、さっきのサブエージェントとか、そういうオーケストレーション的なところも含めて、
いろんなことができそうだなって思ったので。
あと、1個のデュアラブルオブジェクトのインスタンスは10ギガのデータベースをサポートしてるんで、
それこそマルチテナントっていって、組織ごとにサーバーを立てて、
その中で全部やり切って、システムとしてやり切って、データ分離も完全に行って、
セキュアな状態でワークさせるっていうのも作れそうだっていうところで。
多層的なやつね。
そうだね。多層の、もう全部あります版が作れるみたいな。サーバーもあるしみたいな。
なるほど。
そういうすごさもあるって感じ。
ありがとうございます。じゃあ今日は結構長くなっちゃいましたが、こんな感じですかね。
はい。
はい。じゃあまた技術的にわからないことあったら聞けたらと思いますので、よろしくお願いします。ありがとうございました。
ありがとうございました。
本日もAI駆動開発部の事情をお聞きいただきありがとうございました。いかがでしたでしょうか。
今回はクラウドフレア、実際何がすごいんだろうっていうのをちょっと僕が、
ふわっとはすごさわかってるんですけれども、具体的なことはあんまりわかってないんで、
ちょっと聞いてみた回になりました。
こんな感じで、AIで開発するみたいなのに関わることをいつも話しているので、
このPodcast気に入ってくれた方は、いいねやフォロー、高評価ぜひお願いいたします。
それではまた次回もお楽しみください。バイバイ。