00:04
7月26日火曜日ですね。 遅刻は朝9時を回りました。
はい、今日の東京はあいにくの雨ですね。 おはようございます。
夢見のkeeth孤独ははるです。 では本日の朝活を始めていきたいとおもいます。
本日はですね、昨日に引き続いて水内さんが先日お話しされていた Edge Side Frontend という新領域という
タイトルのスライドの続きを読んでいこうと思います。 昨日も読んでいったんですけど、昨日はですね
えーとなんだっけ まああのー
なんだっけ 大きなばっかりで言葉が出てこないんですけど
目次の2つ目のところですね。 要はCDNワーカーズのところか
の話が出てきますね。これまでのCDN最高というところから入っていって、 まあいろいろCDNの話をしてきたんですけども
クラウドプレイワーカーズの登場というところから入っていって、 CDN Edgeワーカーの特徴というところを読んできました。
そこが中途半端に終わってしまったので、今日はそこからまた改めてやって 続き入っていきたいと思います。はい、じゃあいきます。
CDN Edgeワーカーの特徴というところで、ユーザーから地理的に近いCDN上でするので 低遅延ですよねと。メモリフットボリーの実際ランタイムを要求しますと。
世界中のDGで実行する以上強いマシンは仕込めないというのはそうでしょうねと思います。 強めのCPU制約というのがありまして、それは実行時間の制限というのがあるそうです。
クラウドプレイワーカーズによるCPU制約、 課金するほど制約が緩くなるよというところでした。
この辺は他のCDNとかもだいたい似てるし、 だいたいクラウドサービス的なもので行くとそうなるだろうなという感じはあります。
一応下にグラフと、グラフじゃないですね、図表があるんですけど、 あとリンクですね、お金回りのところにリンクが書いてあるんですけど、そこは見てみてくださいってところです。
続いてクラウドプレイワーカーズに見るCPU制約課金ですけど、 メモリ上限は128MB、コード上限は1MBというところです。
ちょっと不合的なノードアプリは動かない水準だと思います。 不合的なノードアプリって何かよくわからないですけど、大きめだというか重めなやつは動かないみたいなところですね。
コードの上限が1MBって言ってるので、まあそうでしょうね。 メモリ上限が128MBというところなので、
まあまあそういうところもありますからね。がっつりメモリ使うようなアプリケーションっていうのはやっぱり動かないよね。
あくまでやっぱりCDNなので、キャッシュ化をして高速に返すってところが目的なので、 そもそもそんな重いアプリケーションの時点でそんなに高速化というのは悩ましいところですよね。
実際ノードモジュールがそのまま現実的には不可能なので、 フロントエンドと同等のバンドルプラスオプテマイズっていうのがやっぱり必要になりますよねっていうところでした。
クラウドプレイワーカーズの制約をどう解釈するかっていうところですけど、 ネットワークエンジニアの発想ですね。
03:02
既存の延長の発想なんですけど、CDNで働く、動くですね。 L7 Pro機種をJavaScriptで技術的にできるようになったというところですね。
これが一応既存の延長の発想ですけど、ノードJSエンジニアの発想をすると、 アンバウンドを有効にすればサーバサイドJSとして十分なんじゃないかというところですね。
いずれにせよそのハイCPUなワークロードっていうのはおまかせない前提だという。
それはそうでしょうね。
あとJamstackもしくはISRのリソース再生成っていうのは、 ほぼほぼ外部APIを生み出して外にパスしているだけだと考えると、
実際エッジワーカー内でコンテンツ再生成は任せられるんじゃないかというところも言及されていました。
それはそうかもしれないですよね。
はい、はい、はい、はい。
Jamstack ISRのところですよね。
しっかりAPIのところを外出しできていればってことですよね。
JamstackがISRだから、それはAPIっていうのは外部にちゃんと切り出してあるっていうのは前提だと思いますね。
そうじゃなければそもそもJamstackがISRって言わないと思いますしね。
はい。
なのでアンバウンドを有効にすればサーバサイドJSとして十分なのよっていう話ですね。
はい。
またクラウドフレームワーカーは誰のためのものっていうところですね。
一つはネットワークエンジニアですね。
CDNHOの不合的なエルダープロ機種っていうのをやるもの。
基礎のネットワークの間に挟んでプロトコルの最適化ができるようというところですね。
もう一つはノードエンジニアでCPU制約を受けられれば高応答性のアプリケーションサーバーにもできるというふうにお期待できる。
クラウドフレームワークもワークアウトが真のサーバーレスだとアピールできると。
はっはっは。
なるほどね。真のサーバーレスのワークアウトだと。
なかなか面白いですね。
ノードエンジニアとしてはやっぱりそうですよね。
CPU制約を受けられればエッジサーバーがCDNHOのサーバー。
ノードのアプリケーションとして動くことができたら確かに高応答性のアプリケーションサーバーにできるというのはかなり魅力的ですよね。
やっぱり本体となるアプリケーションサーバーまで行かなくてもエッジサーバーのところで処理をして返してくれるというのはかなり魅力的ですよね。
はい。
で、えっと、ノードプラスフロントエンジニアの発想というか、
ところですけど、これはかっこみずちって書いてあるんで、このフィッシャーのご意見だというところですけど、
ついにアプリにCDNキャッシュ破棄を織り込む設計ができるぞというところを書かれてます。
これは同じ発想にやっぱりたどり着きますけども、魅力的ですし、これはいいよなと思ってます。
僕はそのクラウドフレーバーワークアウトをちゃんと使ってるんですけど、今このスライド見ながらそんなこともできるし、
こんな期待値が上がるんであれば、それはクラウドフレーバーワークアウトに傾倒するじゃないですけど、
ちょっと期待をしたくなるのもちょっと分かるなという感じがしました。
はい。
で、続きいきます。
あれ、お前が嫌ってたロックイン問題は?っていうところですけど、
はい、そうですね。
昨日読んでいたところの中で、クラウドCDNを使う中でロックイン問題がやっぱり起きるんじゃないの?というところが嫌だったから、
06:06
どうしようかってほやほやみたいな話をしてたわけですけど、
はい、現在WinterCGというグループで、ブラウザ外JavaScriptの相互運用性について使用策定中だそうです。
ほう。
WinterCGですね。
.orgというところと、あとGitHub.comのスラッシュ、WinterCGというリポジトリというオーガニゼーションがあるそうですね。
その議論もちゃんとGitHubで公開してるのかな?
はい。
ブラウザ外JavaScriptの相互運用性について使用策定中という、なかなか面白いというか魅力的な話題ですね。
ブラウザ以外で動くJavaScriptの標準を決めるためのグループ、だからつまりnode.jsのところもそうですよね。
Cloudflare、Vercel、Eddyのショピファイ、あとなんだ、バイトダンスか。
バイトダンス、これIgaliaって読むんですかね。
はい、っていうのが参加していると。
自分のスタンスとしては現状ある程度のロックインを許容せず、Cloudflareに学習・コクソと全振り中だと言ってます。
はあ、すげえな。
Cloudflareに全振りしてるの?今水内さんって。
いや、それだけCloudflareワーカーズに期待をしているのと、やっぱり本当はパフォーマンスが速度に対する興味っていうのが強いんですね。
はい、でもなかなかすごいですね、このWinterCGというグループ。
Cloudflare、Vercel、Eddyのショピファイ、バイトダンス、Igalia。
ちょっと最後のIgaliaだけ分からなかったんですけど、それ以外はもうやっぱり名残る企業というか、サービス運営している会社がそこにグループとして参画しているのはかなりすごいなと思いました。
この辺について、ブラウザかJavaScriptって言うんであればなんとなく、Fastlyとかも入ってくるかと思いましたけど、
FastlyはFastly固有言語みたいな書き方をしなきゃいけないっていうのを前回昨日読んだところにも書いてあったので、
その理由もあって参画したいんだろうなという感じがしましたね。
はい、では続けていきましょう。
では続いて、Cloudflareワーカーズがどう動いているかってところですね。
cdn Edgeワーカーというのはスケールするのかというところですけど、
なんでJSなんかの高水準言語でスケールさせようと思ったのか調べてみましたというところですね。
mizuchi.devっていうドメインの中で、9月12日ですね。
2020年の9月12日に出された記事があってですね、
その中でCloudflareワーカーズっていうところのことを言及しているそうですけど、
一応そこの記事見てみてくださいと。
なんでスケールすると思ったのかというのを調べてみたそうです。
で、Howワーカーズワークスっていうところですね。
ワーカーズワークスはどのように動いているのかというところですけど、
developers.cloudflare.comというクラウドフレアのブログですね。
その中にワーカーズディレクトリ切ってあるので、ワーカーズ専用のブログがあるのかなと思いました。
その中にHowワーカーズワークスっていうタイトルの記事があります。
それも見てみたと。
あとはセキュリティーモデルのところですね。
09:01
これもクラウドフレアのワーカーズブログの中にあります。
セキュリティーモデルっていう記事があるので、その辺も見てみてくださいと言った感じですね。
一応リンクがあったので。
もう完全に僕も速度が結構好きなので、この辺の記事はちょっと読んでみたくなりましたので、
明日以降多分読むと思います。
一応ざっくりとピックアップしたものがありますね。
Howワーカーズワークスですね。
クラウドフレアのブログの2つ目ですね。
ですけど、V8っていうのはアイソレイトをオーケストレートしますと。
変数をグループ化してその変数を変質させることが許された行動を含む軽量なコンテキストですと。
アイソレイトは関数を実行するためのサンドボックスと考えることもできます。
サンドボックスと考えることもできるわ、なるほど。
そういう意味でいくと、確かにV8用はアイソレイトをオーケストレートしますと。
なるほどね。
ざっくり、ざっくりじゃないですね。
僕半分ぐらいしか理解できないけど、なるほど感はありますし、
半分、何言ってるんだろう、どういうことだろうという感じはします。
もう一個、アイソレイトのメモリーっていうのは完全に分離されているので、
各コードはランタイム上の他の信頼されていないコードやユーザーが書いたコードから保護されていますと。
またアイソレイトは非常に迅速に起動できるように設計されています。
各関数のために仮想マシンを作成するのではなく、既存の環境内にアイソレイトを作成します。
このモデルは仮想マシンモデルのコールドスタートを排除しますと言っています。
各関数のために仮想マシンを作成するのではなく、いわゆるラムダみたいな話ですかね。
とかグラウドファンクションズみたいな話かな。
みたいなような仮想マシンではなく、既存の環境内のすでにあるものの中でアイソレイトを作成しておいて、
このモデル、いわゆる仮想マシンモデルのコールドスタートというのは排除してくれるというところですよね。
それは魅力的ですね。
クラウドフレアワーカーズの中身はそんな風な感じで動かしているところなんですね。
それは素晴らしいと思いますし、ちゃんと侵略されていないとか、ユーザーが書いたコードを取ってからも保護されているっていうのがすごいですね。
メモリ自体が完全に分離されているところがかなりしっかり設計されているなという感じがしました。
あとV8アイソレイトオンクラウドフレアワーカーズのところですね。
大雑把に言うとCPU128MBに割り当てたV8アイソレイトを仮想コンテナとして決め打ちして大量にスケールさせるっていう。
今読んでいるところでは図が載っているんですけど、なるほどって感じですね。
本当満パワーで、アイソレイトを無理矢理ガッと作って、そこに128MBのメモリをフルにうまいこと分割して活用して、それをガンガンにぶん回しているというところですね。
なるほどですけど、なかなかパワフルなことをやっているなと思いつつ、笑ったけどでもやっぱりすごいなと思いましたね。
ここでちょっとV8の復習をしましょうと。
12:02
V8というのはGoogle ChromeのJavaScriptエンジンのことですよね。
V8はコンテキストというと、V8アイソレイトを動かすためのサンドボクサーというところですね。
復習というかワードの説明かな。
V8アイソレイトというのは実行単位のことです。
V8のスナップショットに実行状態をダンプできると言っていますね。
V8スナップショットですけど、V8スナップショットというのはバイナリーシリアライズされたアイソレイトの中間状態。
例えばChromeならDOM APIがバインドされたスナップショットとか、Node.jsで言うのだったらその環境のAPIが構築済みのスナップショットとか。
クラウドフレアワーカーズもおそらく同様のスナップショットがあると水谷さんは睨んでいると。
はい、でも極論NodeやDenoのコードを読むと理解できません。
はははは。まあまあ、なるほどって感じですけど。
興味ある方というか、そこまで技術を深めたい方は読んでみてくださいってことですけどね。
はい、水谷さんは読んだらしいです。
すげえな、なるほど。
ああ、でもこの域に達するには読むしかないんだろうなぁという感じはしてず、
ちょっと時間がないなぁと思いつつですね。
はい、まあでも一旦V8の復習でした。
えー、どなたですかね、これは。
リアンダーダヒルっていうのかな。
はい、いわくV8はコンテナーというふうにおっしゃってますと。
はい、tinycloud.orgっていうドメインの中のJavascript Containersっていう
これはサイトかそれとも記事かっていうものがあって、
はい、まあそのリンクが貼ってあるんですけど、
その中でおっしゃっていたところに、
Linux OSとかDockerに続くコンテナーこそがV8アイソレートであるという主張をされているそうですね。
あー、Linux OSとかDockerに続くコンテナーですね。
のV8アイソレートであるという主張。
はい、V8アイソレートというのはあくまで実行単位の話ですね。
はい、Snapchatネットに実行状態をダンプできるという、
アイソレートだというところを言ってます。
はいはいはいはい。
で、市の主張の括弧1ですけど、
Javascriptってのは世界共通のスクリプト言語です。
Javascriptの普遍性のためにサーバーを単純化する新しいコンテナーのような中小化が実現しています。
私はLinuxコンテナーがなくなると主張しているわけではありません。
はい、その中小化のレベルは非常に常に有用です。
ただ人々が書くビジネスロジックの多くにはむしろ低レベルすぎますと。
あー、なるほどね。
レイヤー低いと。
で、ウェブサイトを作るとき、
Systemdのコンフィギュレーションなどは定型的なものでついています。
まあまあ確かにね。
もちろんそのサイトごとによってまあ最適化したりとかはしますし、
特別な設定するかもしれませんが、
だいたい同じような感じで基本的にはコンフィギュレーションにするものだと思います。
定型的になるのはまあそうだよねって感じです。
まあなので、はい。
ちょっとその辺レベルすぎると低レベルになってしまいがちなので、
まあアイソレートのところで、はい。
やったほうがいいんじゃないかと思います。
で、そのアイソレートには、
V8アイソレートのコンテナーというのがいいんじゃないかという話をしていますね。
はいはいはい。
15:02
まあ確かにそもそもJsundarは世界共通のスクリプト言語というのはかなりデカいですよね。
はい、まあフロントエンドは絶対Javascriptで書きますしね。
まあ一応今はTSで書くかもしれないですけど、
結局TSでなくてJsに変換をしますしね。
はい、フロントエンドの世界共通の言語というのはもちろんJavascriptになりますし、
まあノード是正ですよね。
まあサーバーサイドのところは言語がたくさんありますけど、
サーバーサイドもJavascriptで書けるというので、
まあフロント、バックも一貫してJavascriptというところで書けるのはかなり大きい。
まあその上でV8エンジンというのはEUですよねって感じです。
まあブラウザーの方だとV8エンジンだとプロミウムになってしまいますけどね。
まあとはいえです。
で、それを普遍性のためにサーバーを単純化する新しいコンテナのような抽象化が出現しているというのはすごく面白いと思いました。
はい、で詩の主張2つ目ですね。
ウェブサービスの大部分というのはLinuxコンテナでなく、
Javascriptコンテナの観点から考えることで簡略化できるもしれませんという予想をしています。
ウェブは人間のためのものであり、実行環境がスクリプティング原稿であることは理にかなっていますと。
はい、なるほどね。
これなかなか面白い視点というか。
うーん、あとちょっといわゆるインフラとかその低レイヤーらへんのところまで来ても、
それをJavascriptのコンテナという観点から考えるっていうのはなかなか興味深いですよね。
まあ人間にとって良いというものはそうだし、
まあそもそもウェブはやっぱり人間のためのものであると、それもそうですよね。
なので実行環境がスクリプティング原稿であることは理にかなっているのはそれはそうだよなという感じもしますが、
まあ一方でやっぱりシステムにはシステムの要求であったりとか、
なんかいろんな制約だったりするので、
そこをJavascriptという原稿がどこまで親和性がいいとか歩み寄りができるかっていうのが気になりますけどね。
まあそれをさっきから述べているV8のアイソレートっていうところですかね。
が解決してくれるんだらいいなと思いますけど。
はい。
で、真の意見はどう取れるかっていうところですね。
V8がコンテナというのには同意ですけど、まあ技術的中立性を欠くと言ってます。
同コンセプト実行モデルを持つ他の言語、例えばダートでも同様なことができそうと言います。
ああ、ダートでもできそうか。
まあ同じGoogleが作っているともありますし。
これはそうですけど、まあ中立性を欠くっていうのはどうなんだろうな。
逆に中立性がどこまで必要なのかっていうのはちょっとわからないし、
まあ水谷さんがおっしゃっている技術的中立性って何を意味しているのかっていうのが、
すみません、僕は追いつけてないです。
ごめんなさい。
ここで続いて、ハイCPU処理を切り分けるためにファストレイコンピュートアップエッジのように
ウェブアセンブリーランタイムを選択肢として欲しい。
ああ、まあそうね。
JavaScriptを基本的に主軸に据えて、そこから物事を見ていくっていうので、
JSは見るますけど、ウェブアセンブリーランタイムなんて欲しいな、それは確かにそうかもしれないですね。
はい。
ウェブアセンブリーが欠けるんであれば、それはそっちに倒せるに越したことはないですからね。
はい。
だが、まあ、リーの言うように、リー、リーって言うんですかね、リアンって言うんですかね、これは。
リャンさんかな、リャンダヒルさん、読むのが正しいのかわからないですけど。
はい、リーの言うように、人間の生産性を注力するならV8の選択肢はまだ妥当だというふうにおっしゃってますね。
18:04
はい、なるほどね。
まあ人間の生産性を注力するっていうところが重要かもしれないですね。
人が、僕ら、そもそもウェブアセンブリーをちゃんとやっているフロントエンドエンジニアってどれだけいるかもちょっとわからないですし、
フロントエンジニアがそこまでガッツリ、クラウドフレアワーカーズとかV8のアイソレートというところですね。
JavaScriptのコンテナというところまで興味を持ってガリガリやる人とかエッジサーバーに対して知見を持ってガーッとやる人ってそんな多くはない気もしてますしね。
まあでもそこをできるようにするのであれば、やっぱりJavaScriptでやるV8の選択肢なら結構いいんじゃないかなと思っておりました。
はい、クラウドフレアワーカーズがどう動くかというのをまとめですけど、
V8アイソレートっていうのはセキュリティサウンドボックス付きのJS実行モデルだよということですね。
はい、もうこの一言だけでだいぶまとまっているんですけど、いや魅力的だよなやっぱりっていうのはやっぱり変わらないですね。
クラウドフレアワーカーズはV8アイソレーションをコンテナとして記名打ちして、CDNHでユーザーコードを評価しますと。
で、リーもV8はウェブと人間のためのコンテナと主張されてますってことでした。
はい、結局CDNHのエッジサーバーがノードのAPI、アプリケーションサーバーとしてぶっちゃけると期待できるようになるっていうのは、
魅力だっていうのは変わらないですね。
はい、では続いて、クラウドフレアワーカーズで何ができるの?というところですけど、
自分のエッジワーカーを評価する視点でいきます。
ジャムスタックISRを進行させられるか、部分的にノードを置き換えられることができるか、
運用を楽にできるか、コストが安くつくかっていうところですね。
この辺がやっぱり評価する視点だというところですけど、
まあやっぱりビジネス観点も重要なのでその辺ですよね。
はい、というところでした。
で、クラウドフレアワーカーズの周辺の機能群ってところですね。
手元の玉をちょっと把握してみましょうってことでしたけど、
まずはデュアラブルオブジェクトですね。
強制号のCDNH状のステートマシンです。
だとワーカーズKVですね。
リージョナルキャッシュを押しますと。
あとクラウドフレアR2ですね。
Amazon S3互換のオブジェクトストレージ。
S3の互換性があるオブジェクトストレージですね。
クラウドフレアR2。
最後クラウドフレアD1ですね。
これが一番話題になったやつだと思います。
クラウドフレアワーカーズがやばいぞってところのD1です。
これ、CDNH上で動くSQLiteってやつですね。
まさかのエッジサーバー上でSQLite動いてくれるっていう、
もうすさまじいことが起きますね。
これができるからこそ、そのエッジ上でノードのアプリケーションが動くみたいなことになってくるので、
それがしかもエッジサーバーっていろんなところに点在してやってくれるから、
アプリケーションサーバーに行く前に高速に処理して返してくれたりするっていうので、
かなりやばいなと思いましたけど。
一方で、ちゃんとデータの整合性とかキャッシュするのは結構ですけど、
そのアプリケーションサーバーとの整合性とか同期っていうのをやらないと、
エッジサーバーごとに持っているものが変わってくるみたいな話が出てきたりする可能性もあるので、
それはどうなんだろうっていうのが今ちょっと気になりました。
はい。
で、一個一個見ていくらしいですけど、
ワーカーズKVですね。
弱整合で高速なキーバリューストアのことですね。
ワーカーズKVです。
インバリテーションは実測5秒程度だけど、ワーストで60秒ぐらいかかるらしいですね。
21:04
あくまでらしいと言っています。
awaitのkv.putっていう関数を読んでおいて、
第1筆数にキーで、第2筆数バリューで、第3筆数にメタデータの何たらかんたらみたいなのを設定します。
そんな風に使うことができるんですね。
はい。
本当にJavaScriptで書けると結構面白いなと思いました。
続いて、DurableObjectsってやつですね。
これもクラウドフレアのブログがありますけど、
日本語に翻訳されたブログがありますね。
その中に、Introducing Worker's DurableObjects.jpっていう記事があるそうですね。
その辺を見てみてください。
クラウドフレアのエッジワーカーズの、なんだっけ、
DurableObjectsってところですね。
を書いてます。
で、これ何かっていうと、CTM上で動く強制語のアクターモデルだと。
あー。
強制語のアクターモデルだと。
現在のコネクションに応じて地理的にエッジロケーションが再配置される。
で、各ドキュメントを読む限り、DurableObjectsが他を成立させるための機関プロダクトっぽいやつか。
そんな感じだね。
完全に勘だけど、R2やD1もこの中で動いてそうだって言ってます。
はい、勘だって言ってるからどこまであるか分かんないですけどね。
はい、というところでした。
で、一応コード例でガーッとコード書いてますけど、
ざっくりコードを音読するので、分からないかもしれないですけど、ふーんと思ってください。
エクスポートのクラスで、カウンターっていう例のクラスが設定されてます。
で、中身見ていくと、最初はやっぱりコンストラクターですね。
コンストラクターがあって、引数にはStateとEnvを取っていますと。
で、this.stateにStateを入れといて、
this.state.blockConcurrencyFileっていう関数があって、
中身ですね、コールバック関数が引数によってされていますと。
で、asyncの無名関数でredStoredAwaitのthis.stateStoredGetっていうので、
バリューを取りときます。
これ多分さっきの、なんだっけ、ワークハウスKVのアクセスの話かな?
this.state、ストレージの、そうですね。
で、this.valueでStoredもしくはゼロみたいなのを初期値からイニシャライズをとりあえずしておくと。
で、続いてasyncでフェッチをするみたいな感じですね。
これがDurableObjectsのコード例だと言ってます。
はい。
コード例見てますけど、これだけだとやっぱりなんとなく分かったんで、うん分からんって感じがしますね。
はい。
で、続いてCloudflareのD1ですね。
CDN Edge上でリード、レプリカがばらまかれるSQLiteだと言ってます。
はい。
いやすごいよな、やっぱりエッジ上でSQLite動いてくれちゃうが、
もうなんかパワーでしかないんだよな。
だけどやっぱりアプリケーションの本体の方のデータベースとか、あとSQLite。
普通にアプリケーション本体をするとSQLiteを使ってるとは限らないですけど、
SQLiteがCDN Edge上でリードやレプリカとしてばらまかれてるっていうのは
かなり、いやほんまかよっていうとにわかに信じ難いような設計だなと思いますけど。
はい。
おそらく強制号ではないですけど、SQLiteを同級するようになってますと。
強制号じゃないんだったらしたらどうなんだろうかはありますけど、
24:01
でもちゃんとリードレプリカとして動いてくれるんであれば、
データの整合性ってところは多分ある程度はちゃんとしてくれるかなと思いますね。
やっぱりSQLiteを使うってことはやっぱりデータの同級っていうのはかなり大きな問題になってきますので、
そこがちょっと気になられます。
はい。
で、あとなんだこれ。
lightstream.ioとかGitHub.comのRQliteっていうののライブラリのリポジトリがあるそうですね。
その辺にいた技術をCDN間で行っていると予想されますと。
はい。
lightstreamとRQliteっていうものを僕は全然知らないんで、
どういう技術なんかはちょっと後で軽く見てみようかなと思いました。
時間は多分許さないと思いますけど。
では参考でクラウドフリアD1がやばいっていうのを水口さんが前で書いてるので、
その辺も見てもらってもいいんじゃないかなっていうところですね。
はい。
で、そもそもエッジで何がやりたいんだっけっていうところですけど、
静的アセットをCDNに当てたいということでした。
R2プラスKVで実装は一応可能だと言ってますね。
はいはいはい。
で、この辺もGitHubのリポジトリでワーカーテンプレートスタティックっていうのがあるので、
その辺を参考にしてもらうといいんじゃないのって話でした。
で、CDNエッジ内で処理を完結して高速に応答したいと。
で、参照型APIをD1で完結して構築することができるのか?
疑問みたいな感じですけど、
それもまたできるんであればなかなか面白いって感じですけどね。
はい。
結局エッジサーバーをノードJSとかのアプリケーションサーバーとして
完結するようになってくれるんでは、
やっぱり高速で処理をして返しますみたいなところがエッジ上でできてしまうので、
参照型APIをその辺で完結して構築することができるんであれば、
まあまあまあ今よりもっともっと早くなれますし、
すげえ話だなと思いますね。
しつこいですけど、結局データの成功性とキャッシュの成功性みたいなところがやっぱり気になりますってことですね。
あとは動的コンテンツの不成功の時間はやっぱり最初にしたいということですよね。
kv.deleteみたいなメソッドがあって、
それはやっぱりアプリケーションロジックに入れていかなきゃいけないのねってことですね。
この辺が本当にそれを本格的にクラウドフレアワーカーズを使うんであれば、
ちょっとロックインしてしまうっていうところのソースコードになってくると思います。
ただまあ、その恩恵を受けるためにはそれは何かしらの制約を受けるみたいな、
あれですね。それは仕方ないと思うので。
トレードオフでどこまで使うかっていうのは、
それぞれのプロジェクトでやってもらえればと思いますけど。
エッジワーカー用のフレームワーク位置を考えてみようというところでした。
一応右に図があるんですけど、これフロー図ですね。
ちょっとこの図は口頭で説明するとわけわからんと思うので、
皆さんのほうで見てみてくださいってことですね。
一応考えてみました。
フロントエンドの表示に関わるデータをとりあえずD1に集約しましょうと。
SQLiteがあるのでそのD1にとりあえずデータってところを集約します。
更新系APIはそのD1に書き込みつつ、選択肢的にkv.deleteをしますと。
はいはいはい。
書き込み、更新系APIは基本的に書き込みつつ、
しっかり選択的にkv.deleteしてしっかりリフレッシュをしましょうと。
で、キャッシュがないときですね。
動的な静的アセットと、静的アセットの再生成と再キャッシュですね。
いわゆるISRのところです。
をやりましょうというところですね。
27:00
キャッシュがあるんだったらそのままキャッシュを返してしまえばOKですよってことですね。
いわゆるブラウザの方はAPIをポストしておいて、
APIの方がR2とかSQLiteとかkvのところにライトをしていくと。
もしくはインバリデートしていくってところですね。
で、ワーカーの方はSQLiteとかkvとかR2とかそれぞれをリードしに行って、
そこからブラウザの方にレスポンションして返してあげますよっていうような感じですね。
はい。
で、Next.js風APIのなんとなくのコードが、この例が出てきますね。
はい、えーと、気づいたら時間が30分になったのと気づいたら3名の方が参加されていました。
すいません、全然反応してるわけで申し訳なかったです。
ご参加ありがとうございます。
えーと、みずしさんのエッジサイドフロントエンドっていう新領域っていうような、
この前のLT東壇のスライドをたらたらたらたらたら読んでました。
はい。
僕も全然そのクラウドフレアワーカーズがどんだけすごいかってみずしさんの記事読んだんですけど、
実際使ったことないですし、
不運しか持ってなかったんですけど、ここまでしっかり説明されてるのを読むとめちゃめちゃ気になったので、
僕もたぶんクラウドフレアワーカーズ、今後たぶん技術、リソースを振っていくかなと思っております。
はい。
で、明日もそのいろんな、このスライドの中に出てきたクラウドフレアワーカーズのブログとかの記事が載ってたので、
その辺を読んでいくかなと一応思います。
で、えーと、戻ってきて、
このスライドですけど、本当にもうちょっとなので、
30分超えたんですけど、今日はもう終わるまでエンドレス読んでいこうと思ってきますので、
お時間が悪くなればその辺で全然抜けていただいてくださいってことです。
じゃあ戻りますね。
Next.js風のAPIってところです。
サンプルソースコードが出てきてて、ざっくり音読するのでまた不運っていう感じで聞いてください。
まずAPIのupdatePost.tsみたいなやつがあるとしましょう。
で、そのupdatePost.tsの中身で、
exportdefaultで無名関数ですね。
引数としてはリクエストですね。
まあやっぱノード.js、バックエンド側のコードなのでリクエストが引数に受け取られます。
で、awaitしてenv.db.execでまずとりあえず実行しますと。
execしておいて、kvですね。
kv.deleteでリクエストのパラモンIDみたいなのを一回、
IDごとのものを消しにかかると。
これがいわゆる選択的な削除ってやつですね。
で、.catchして、catchは単純にエラーのところですね。
はい、しますと。
で、コンソールエラーをとりあえず出してエラーハンドリングしてみましょうと。
で、うまくいけばリクエスト.jsonでOKと了解してあげればOKですよというところです。
で、続いてpages.posts.nantara.tsxというところですね。
今回はuuidをセットしますけど。
はい、みたいないわゆる動的なページの書き方ですね、処理の書き方ですけど、
中身はexportconstのgetstaticpropsですね。
はいはい、やっぱりエッジを使うんだからstaticpropsのほうですね。
で、それをasyncで無名関数をセットしてあげて、
今回のほうはもちろん引数はctxですね。
はい、コンテキストですね。
を受け取ります。
で、中身のほうでIDをctx.params.uuidでIDを受け取ります。
30:00
で、constのpostsってやつですね。
postsのほうはawaitでm.dp.getで、
データベースからデータを受け取るようにgetを走らせると。
で、SQLiteが走るんで、クエリ文が書ける感じですね。
はい、第一引数にクエリ文って感じです。
例えばこのselect aster from posts where id="$id",みたいなことですね。
で、その$idのところの中身を第二引数のほうでオブジェクト的にセットできますよと。
はい、ところですね。
いやー、なんか懐かしいな。
マイスケールで一応ガリガリ書いた記憶があるので、
すごいSQLで見た瞬間、
フロントエンドでSQLを書くみたいなところは違和感もありつつ、
なんか見たことなくて、この新世界に来た感が面白いですね。
そうやって一応データをADminから取れますと。
で、awaitしてるのでPOST受け取ってデータを受け取ります。
で、最後にreturnで、キャッシュキーとかで何かキーを渡してあげますと。
一応なんかこのページを破棄するタグっていうふうにコメント書いてますね。
で、propsで今受け取ったPOSTデータっていうのを
リターンして返してあげますよってことですね。
まだgetStaticPropsなんで、
それをね、まずデータを受け取る処理をしといて、
実際にその受け取った、リターンしたものを本体のページコンポーネントに渡してあげるっていう感じですね。
こんなふうに一応Next.js風なAPIを書くこともできますよってことでした。
割とこれ見る限り本当に今のアプリケーションにもどんどん組み込むことも全然できそうなという感じがしましたね。
で、誰がエッジサーバーをおさわり必要があるかっていうところですね。
担当者誰ですかってことですけど、
Webアプリケーションっていうのはエッジファーストで考える時代が来るでしょうと。
ここは僕も今日のこのスライド読んできた感じ、大納得ですね。
エッジファーストは多分本当に来るだろうなと思いますね。
やっぱり僕らフロントエンドはどうアプリケーションを作ってるかっていう議論もありますけど、
そもそもやっぱりユーザーファーストのことを考えると、
速度っていうのとかパフォーマンスっていうのは絶対に譲れないというか逃れられないので、
早いにしたことは本当にないんですよね。
という意味でエッジファーストの考えはやっぱり出ますね。
エコシステムの枯れ具合だけが問題で、まだまだ未成熟だっていうところもあるので、
時代は来るけどそんなに早く来るかっていうのをまだもうちょっと観測する必要はあるかなって感じですね。
パフォーマンスとコストという分かりやすいメリットがあるので、
普段は、普及は時間とリソース投資の問題だというふうな話はあります。
なので本当にこれが来るかどうかっていうのを見越して最初からリソースを投資するっていうのは、
できるならもちろんやっておいて損はないかもしれないですけど、
本当に来るのかっていうのもまだまだ分からないので、
もしかしたら単純に投資して何もリターンない可能性はありますけどね。
水執さんは来ると思っているので、全然投資していいんじゃないかというところでした。
エッジバーカーは既存のクラウドを置き換えるものではもちろんないよっていう話もしてますね。
ここ重要ですね。
あくまでユーザーと直接通信する全くの最適化で、今までのスタックが不要という話では全然ないですよというところですね。
その上に乗っかるようなものって感じです。
とはいえ高コストなクラウドリソースをエッジキャッシュでアクセスして、
頻度を避けるみたいな発想がやっぱり主になるので、この辺は魅力ですよねというところでした。
33:05
エッジサイドエンジニアという職域のところですね。
フロントエンドエンジニアから派生してエッジサイドエンジニアという職域が発生するんじゃないの?という見込みをされています。
ここまでいくかちょっと僕は分からないですけど、僕の中の観点でいくとフロントエンドってちょっと前に話題になったバックオブフロントエンドとフロントオブフロントエンドという区切りがあるんですけど、
それに新しくエッジサイドフロントエンドというのができるんじゃないの?というのが僕の見立てですね。
別にエッジサイドエンジニアという、いわゆるインフルエンジニアの中のさらにエッジサイド専門のエンジニアができるという考え方の人も全然いらっしゃると思います。
ただ僕は多分文脈的にこれフロントエンドの人が主に求めるものなので、
フロントエンドの人が結局でもNode.jsとか触るような人っていうのがここを担当するので、
僕はフロントエンドの人なんじゃないかなという感覚はありますが、
フロントの人でそんなにガリガリSQLiteのクエリ書いたりとか、
バックエンドNode.jsをガリガリ書きたいっていう人がどれだけいるかというのは謎ではあるので、
サーバーサイドがあってもサーバーだけの話でも全然ないので、
結局エッジサイドエンジニアという職域に集約する感はありますけど、
僕はフロントの人というふうに思っています。
というかそうなってほしいという期待値ですね、僕としては。
すいません、余談が過ぎました。戻ります。
既存のフロントエンドの延長というよりも、
フロントエンドOpsとNode.jsのサーバーサイド技術の組み合わせだという、
そうですね、水口さんがおっしゃっていることは全然僕もその通りだと思います。
SQL職員の頃と同じで、最初は高級品扱いだけど、
Next.jsのように時代とともに陳腐化するというところですね。
というふうな見立てをされているそうです。
最後、おまけですね。
Cloudflare以外のエッジワーカーへの気持ちというところです。
まずはやっぱりファストリですね。
CDNのスピードが一番速いというか、
やっぱり速度というところを見ると、
ファストリコンピューティッドアッドエッジですよね。
ファストリさんだと思いますけど、
やっぱりWasmに全フリしているというところがかなり特殊すぎるというのもありますね。
面白いんだけど、やっぱりCloudflareのV8の方がやっぱり好きだというのも分かります。
僕らはやっぱりV8エンジン大好きですからね。
で、Cloudflareと比較してやっぱり開発者支援というのが貧弱だというところですよね。
ファストリの方ですけど。
前半、昨日読んだところにも入ってましたけど、
やっぱりファストリはファストリ専用の言語っぽいものを覚えなきゃいけなくて、
なおかつそれにロックインしたアプリケーションの設計をしなきゃいけないというのがかなり強いですね。
もちろんそれに全フリして、
とにかくユーザーファーストに早く返せるようなアプリケーションを作るんだというのであれば、
別にファストリに系統してもいいと思いますけど、
Wasm全フリはちょっとさすがにエンジニアとして選択肢の幅が狭すぎるので何とも言えない感じがしますね。
続いてDのデプロイですね。
Dのはすみません。僕全くDのノータッチなんでわかんないですけど、そういうものがあるんですね。
Dのデプロイというのがあるそうです。
これは簡易なキャッシュがなく、ダイナモとかファイアベース使えと言われてもみたいなところが出るので、
ダイナモとかファイアベース使うならDのデプロイ使わなくてよくない感がすごいです。
なるほど。
で最後、クラウドフロントファンクションですね。
36:01
AWSのところですかね。
ES5水準であり、CPU制約が多すぎて本当にL7のプロ機種ですよね。
純粋にね。
順次機能開放されると思いますけど、
今のところどうなのかわかんないし、
現時点では純粋なL7プロ機種なので何とも言えないよというところですね。
その辺を考えると、確かにクラウドフレアワーカーズはかなりその辺を担保しているので魅力的だなというか、
選択肢としてまず真っ先に上がるのはクラウドフレアだよなというのはわかります。
では最後まとめです。
キャッシュしたら早くてうまい。
人間の納得感のためにはキャッシュバージの速度が必要だというところで、
このスライドは終わっています。
では今日はこんなところで朝方以上にしたいと思いますが、
いやーすごい長いスライドでしたね。
一応でもページ的には55ページしかなかったんですけど、
なかなか情報量と技術的な密度が高かったんで、
まさかこの55ページのスライドを2日に分けて読むとは思わなかったんですけど、
まあでも完全に未実さんの魔術にかかって、
クラウドフレアワーカーズに僕も傾倒してしまおうと思っちゃいました。
ちょっと今年あれですね、
今年学ぶ技術っていう、
僕毎回ノーションで一覧化してるんですけど、
今年3,4回見直してるんですよ。
それくらい今年面白い技術がたくさん行われててですね、
何学ぶかっていうのをバンバン見直しをしてるんで、
まあいいです。
その時やりたいものが僕にとってのベストな技術だと思うので、
それでいいと思ってます。
じゃあ明日はこのスライドに載っていた、
いくつかのクラウドフレアワーカーズさんのブログですね。
ワーカーズブログっていうのがあるので、その辺を読んでいこうと思います。
どれを読むかっていうと、
僕の読みたいものを読みます。
というところで、
もしお付き合いいただけたらすごく嬉しいなと思います。
じゃあ本日は朝勝以上にしたいと思います。
また明日もゆるりと読んでいくので、
のんびり参加いただけて嬉しいなと思います。
では今日も一日頑張っていきましょう。
お疲れ様です。
