00:06
7月29日月曜日、時刻は朝9時になりました。
今日は東京いい時ですね。おはようございます。kkeeth徳原です。
では本日は、朝活を始めていきたいなと思います。
本日はですね、タイトルにあるとおりですけど、
Weekly Frontend Roundup from Tokyo っていうところですね、の、出されている、
結構10個ずつ、記事をピックアップしたものを毎週出しているんですけど、
そこを読みつつ、もう1個ですね、
先日水地さんが発表されていた、LTEですかね、スライドを、
Edge Side Frontend という新領域っていうタイトルがあって、
そのスライドなんですけど、ちょっと見てなかったんで、
ついでにそれもちょっと見ていこうかなと思います。
順番的に悩ましいですけど、先にちょっとこっち、
Edge Side Frontend から読んでいこうかなと思っています。
すでにご覧になられている方からすると重複するので、
申し訳ないんですけど、すいませんっていうところで、
早速読んでいきたいと思います。
Edge Side Frontend という新領域ですね。
多分タイトル的にフロントエンドの今の話は、
CDN Edge の話だと思いますね。
が主流で、基本的にはそれを使いましょうとか、
そこをフロントエンドとしても強くしていきましょう、
みたいな話じゃないかと勝手に予測をしています。
はい、いきましょう。
最初は About Me は水地さんのことですね。
もう皆さんご存知だと思います。
一応フロントエンドの方で、
ノードディスエンジニアというのも一応名乗っているそうです。
最近はサードパーティースクリプトから
パフォーマンス結構中心に動いているそうですね。
アウトラインですけど、フロントエンドとしての正解、
これまでの CDN Edge ワーカーの何が正しいのか、
クラウドフレアワーカーとしてできることという
4つについてのお話をされたそうですね。
じゃあ行ってみましょう。
フロントエンドの正解からです。
近年のゲームチェンジャーとして
Core Web Vitals というものがあります。
Google が出されたやつですね。
ページ速度が Google Search SEO に
関与するようになったようなところですね。
Google がやっぱりパフォーマンスが悪いサイトというのは
検索結果上位に上げるのは違うんじゃないかというところを
発表していて、それが結構ニュースになりましたね。
僕も覚えています。
ページスピードが非機能要件から
SEO という純機能要件になってきたようなところですね。
Core Web Vitals のパフォーマンスの指標として
数値化するものとして
3つのカテゴリーで評価をしていると。
それが LCP と CLS と TTI です。
何の略だったかすみません。
僕もちょっと覚えてないんですけど
LCP というのは最大コンテンツの確定時間ですね。
CLS とは累積のレイアウトです。
TTI というのは操作可能のタイミングですよというところですね。
基本的には確かレンダリングから
ユーザーが操作できるまでのところに
フォーカスを置いた時間だったような記憶がありますね。
すみません、ちょっと僕の記憶も曖昧なので
03:01
詳しくは実際に Core Web Vitals で
調べていただけると出てくるので見てみてください。
多分 WebDev っていうドメインの記事が出てくると思います。
Core Web Vitals への個人的な見解です。
これみずちさんご自身の見解ですけども
ページ特性次第で常に正しい指標とは言えないと。
これも僕もそうですね。
Core Web Vitals が絶対正解だというわけではない。
絶対解ではないということですね。
また Core Web Vitals は
Web を高速化したかというような別の記事があるそうですね。
Postedの記事があるのでそこも結構面白そうなので
一応紹介されています。
見たことないですけど。
こういうものがあるんですけど
ベースラインとしては
良いコンテンツイコール高速っていうのは個人的に納得感もあります。
これは僕も一緒ですね。
一応ユーザーの時間を奪うものっていうのを
良いコンテンツっていう風に言えるかというと
ちょっと悩ましいですよね。
体感としても
あんまり認めたくはないなっていう感じがあるので
やっぱり良いコンテンツ
まず高速ってのは確かにセットになるんだろうな
っていうのはなんとなく思いました。
何よりもパフォーマンスをゲームフィケーションできて楽しいと。
なるほどですね。
ゲームフィケーションできて楽しいのは
なかなか捉え方がすごくポジティブだなと思いました。
実際でもパフォーマンス改善楽しいですよね。
続けていきましょう。
LCPの最適化ですね。
ライトハーツプレフで100点を出すには
TTFBから約450ミリ秒経験的な間隔以内に
LCPを確定する必要があるよと言ってます。
TTFBってのは初期応答時間のことで
LCPはそのページ内で最大レイアウト要素を確定したタイミングだと言ってます。
雑な肌感でいくと
DNSルックアップで20から80ミリ秒ぐらいがいいと。
限界まで絞ったJSCSSのエバリエーションでも
CPUタイムは大体80から40ミリ秒ぐらいですね。
残りのUで使えるRTDN×Nはほとんどないので
現実にはブロッキングウォーターフォールが発生するので
もっともっと厳しくなるよと言ってます。
20から80ミリ秒はきついんじゃないですか。
JSCSSのところで解析とか処理をしなきゃいけないので
80ミリ秒より大きくいくかと言いますけど
なんだかんだ現実的には100から300ミリ秒ぐらい
結局いっちゃう気がしますけどね。
ただ100点を出すには450ミリ秒ぐらいが
伊達さんの経験的な感覚だそうですね。
450ミリ秒くらい出せれば全然早いと思いますけど。
続いて正解のところです。
CDNHから全部返してしまいましょうと。
アプリケーションサーバーに到達させたら負けだと。
かなり強い言葉を使われてますね。
つまりアプリケーションからHTMLを返す伝統的なスタイルは
すでに不利だと言ってます。
我々が考えることは何がどこまで
静的コンテンツとして実践に確定するか
考えるところでそれが正解だと言ってます。
06:01
そうですね。
アプリケーションからHTMLを返す伝統的なスタイルは
すでに不利だよと言ってます。
結局CDNから返すのが早いのはもちろんその通りだと思いますし
サーバーまで来てるのですでに距離が長いですよね。
その時点で確かにスピードを負けてるのは事実としてあります。
一応右に図があって
ブラウザーからCDN間が10から20ミリ秒で
CDNからアプリケーションサーバーが80から120ミリ秒ぐらいだと。
アプリケーションサーバーからデータベースを表現みたいなところですね。
割と時間かかるので
エッジから返せるんだったら
それをCDNエッジから返したいですよねって話でした。
JAMstackの最高というところですね。
構成要素が更新される度に
静的なアセットをCDNに巻くだけだと言ってます。
ビルド後は静的なアセットなので
運用が楽だし閲覧も高速ですよね。
そりゃそうですよね。
コンテンツが肥大化するにつれて
リリース時間を増大するのもそれもそうだと思います。
更新が低頻度でアクセスが多い場合には向いてますよね。
JAMstackの適正です。
もちろんこれは人によって定義がぶれますと言ってますけど
更新が低頻度でアクセスが多い場合に向いているというところですね。
まあまあ確かに閲覧が
運用は楽だし閲覧も高速だから
それはまあまあJAMstackっていうのは適正的してるかもしれないですね。
ただ一方で低頻度でアクセスが多い場合と言ってますけど
更新はそんなに低頻度じゃない場合も多かったりするので
違いは言えないですね。
いわゆるそのECサイトみたいなところとか
だとJAMstack向いてるか向いてないか結構そこも
ECサイトだから向いてるかというと難しい話ではありますしね。
お客さんによっては全然商品バラバラ肥大化するものもあるし
売ってる商品そのものが結構高頻度で変わったりするもの
更新がバンバン起こるものだったりするっていうものも
今までやったことが僕もありますので
そんな多いと言っても1、2週間では変わるのかって
言われるわけじゃないですけど。
あるので、とはいえECサイトでJAMstackやるかって
ちょっと悩ましいところがありますけどね。
というところです。
一応そのJAMstackをもう一回考えてみようというところでした。
一応右の図にもあってレベロッパーから
フロー図が書いてあるんですけど
Azureに2本置かれていてAPIもしくはCIですね。
っていうのがデプロイでありますと。
CIはAPIをコールしますよね。
APIのところはAdminとかAPIとかWebとか
っていうところからどんどん叩かれますよ
っていう矢印が書かれてます。
CIはリリースされるときにCDNにリリースをしますよと。
ブラウザーもCDNのビューいますよね。
参照しますねってところでした。
インクリメンタルスタティックリジェネレーションですね。
ISRって言われるものでした。
Next.jsのISRっていうところを持ってきてますけど
アセット生成サーバーをデプロイするっていうところですね。
デプロイしないときに生成して期限付きキャッシュをしますよってことですね。
Jamstackより設計が難しいがコンテンツ増加に強いというところで
09:00
さっきのJamstackよりもやるものの更新が低頻度ってところを解決してるというところですね。
その代わりちょっと設計難しかったりしますし
別の考慮しなきゃいけないものはなんにもいけないんですけど
でもこっちを使うことでよりコンテンツが多くなったり
変更が多くなっても耐え得るというところですね。
また右のフローズがありますけど
CIがデプロイしてISRサーバーってところにデプロイしますと。
ISRサーバーがリジェネレートしますよねってところです。
リジェネレートしたものをCNに置きますよって言ってます。
ブラウザーはもちろんCNのビュー参照するんですけど
Stale while Revalidateってところですね。
ここが重要だという感じだと思います。
ISRのNext.jsExampleっていうのがコード一応書いてますけども
Export Async Function Get Static Propsみたいな関数がありますね。
Get Static PropsはNext.js固有の組み込みの関数ですね。
いわゆる静的にビルドするようなものっていうところですね。
っていうのを明示的に分けてますよってことですね。
これの逆にSSR用のGet Server Side Propsっていうものを
一応あったりしますと。
紹介まででした。
Get Static Propsの中でとりあえずawaitフェッチをしてます。
なんか的なところからフェッチをして
当然でres.jsonでレスポンスを返してあげますと。
それを一応Postsっていう変数にとりあえず置いていて
ReturnでPropsコロン、さっき言ったPostsですね。
データをオブジェクトをPostsで返してあげますと。
もう一個返すReturnの中にRevalidate60ということで
60秒ごとにキャッシュを破棄して静的コンテンツを再生成する
っていうような設定で返してあげてます。
いいところですね。
初回リクエストっていうのは遅延を許容して
訂正しながら返してます。
再生成中は一つ前のコンテンツを返します。
返すかどうかを一応制御できますよってことを言ってますね。
こうでした。
僕実はISRのコードを書いたことがなかったので
今紹介されて初めて見たんですけど。
普通にGetStaticPropsでそのままな感じはしますけど
あそこにRevalidateっていうオプションを付けてあげることで
簡単に設定できるんですね。
この辺はすごいな。さすがと思いましたね。
問題はJAMstackとISRの課題のところに行きますけど
ビルドですね。
CDN Cache、PARGEっていうのは
そんなのやってる間は古いコンテンツがもちろん表示されますよ。
基本的にユーザーに弱整合を納得してもらうのは
結構困難ですよねって言ってます。
まあそうだよね。整合性が弱いところを
わざわざユーザーが納得してくれるかって
そんなことはないですよね。
技術的な敗北じゃないですけど
こっちの原因になったりするので。
ISRっていうのはバーセル以外のネイティブサポートがない。
もしくは難しいと言ってますね。
バーセルはそりゃネクストのために作ってるから
いろいろサポートあってそりゃ強いよねってあるし
ネクストのアプリケーションをバーセルにアップするっていうのは
やっぱり選択肢出てきますし
もうここまでくるとビジネス的なお話で
バーセルを選択するっていうのは
12:01
もうそろそろ最高の余地は全然あるのかなと思いましたね。
なかなか僕の現場では使ったことがないので
難しいかはどうなんでしょうね。
提案するのは全然アリなんですけどね。
いろんなものを加味すると結局AWS使うみたいな話が出てくるかもしれないですね。
ISRでも再生成時間を短くするとコストが増えしますよってところですね。
そりゃそうでね。再生成時間がそんなに頻度
スパン短く頻度高くするとそもそもの
サーバーコストであったりとか
どんどんどんどんやってくれっていう
リクエスト処理が増えるのでそりゃそうでしょうね。
コスト増えるんでそんなに多すぎても良くないってところで
この辺はバランス取らなきゃいけないから結構難しいと思いますね。
続いてZENのキャッシュ整合性ファクトっていうのがあるそうですね。
ZENのキャットノートさんの書かれた記事ですね。
ありますけどZENでは著者本人の場合のみ
最新のデータをリクエストするようにしていますと書かれてます。
そうなのに。
著者本人が最新のデータをリクエストするようにしているのみですね。
こんなことやってるんですね。
例えばそのサンプルコードがあって
current.id==props.article.user.idを見て
それがイコールだったらIsMineっていう変数に出してあげますと。
トゥルーポルスが入ってきて
IsMineがトゥルーだった場合ですね。
ユーズエフェクトをやってます。
ユーズエフェクトで第2引数はIsMineって今言ったあれですね。
現在のユーザーIDっていうのが
自分自身かどうですかっていうのを変数に受け持っておく
IsMineという変数を第2引数にセットしてあげてますと。
それだけですね。
ユーズエフェクトの中で
if IsMineがびっくりついてるからフォルスですね。
フォルスになったりだった場合はそのままリターンをしてあげますと。
そうじゃない場合はGetArticleっていうメソッドをコールして
スラッグでプロップするとスラッグというのを取ります。
では.ZENのSetArticleを書けばいいみたいな感じで
処理をしてるという感じですね。
ZENってそんなことやってたんですね。知らなかった。
その処理を見てZENのハックをどう解釈するかっていうところですね。
美術館的にはどう解釈されたのかっていうと
仮説として人間は自分が更新したら
反映されるという予想から外れると
強い拒否感を示すというふうに受け取っているんですね。
自分もしくは自社以外のコンテンツに対して
キャッチの成功の興味が実はないんじゃない?
みたいなところを仮説として持ってみましたと。
なるほどね。
で、キャッシュ成功性のアドバンス戦略として
弱成功性的コンテンツと強成功APIの2系統を用意しておきますと。
認証フラグ等で強成功APIを選択的に有効化すると
面白いんじゃないの?って言ってました。
はあ、考えたことなかったですね。
そういうことをやってみるのは
一つ、この仮説が正しいのであれば
この戦略は少し面白そうですね。
今やったことはないですけど、なるほどって感じです。
キャッシュ設計は納得感との繋がりだというふうに言いますと
キャッシュしたら早くて安いことはエンジニアは知っています。
そりゃそうですよ。
でも自分もしくは自社の納得感のために
15:01
強成功を要求する、もしくはされるっていうのも
なんとなくどうなんだろうっていうのがありますね。
で、ツラン社っていうのは多少の遅延を許容しても
ツランが早いほうがもちろん嬉しいし
提供側にとっても安いはずだと。
まあまあ。
最初のその実装とか環境周り整備は大変かもしれないし
そこは安くない気がしますけど
その最初だけコスト払ったときは
あと運用は安いはずだと言ってますね。
全体最適のためにコンテンツオーナーだけ
ハックするのは立派な戦略なんじゃないの?
っていう風に言ってます。
もちろんコンテンツの性質次第だとは思いますけど
とは注意がされてますね。
はい。
全体最適のためにコンテンツオーナーだけ
ハックするのはなかなか考えたことなかったですね。
そっかそっか。
えー。
ちょっとなんですかね。
興味深い仮説だなと思いました。
キャッシュハッキーをアプリケーションに織り込む
っていうところです。
本当のアーキテクチャっていうのが
これ見たことありますね。
同じ水口さんのスピーカーデックの記事ですね。
はい。
光を超えるための本当のアーキテクチャですね。
全キャッシュを前提として
APIによるリソース更新にキャッシュハッキーを仕込むと。
ISRの時間経過以外をトリガーに
コンテンツ再生性を実現できるはずだと
いう風に言ってます。
頭の中でできそうだなっていうのを
水口さんは思ってるらしいですね。
ただし関連速度っていうのは
CDNのキャッシュパージュ速度に依存しますので
浸透率とか言葉がありましたけど
そんな感じのものですよね。
この言葉は結構危険なワードで
皆さん使わない方がいいと思います。
この点、現時点で最強なのは
ファストリーのインスタントパージュ
ってやつらしいですね。
これはだいたいかかっても
150ミリ秒ぐらいまでしかいかないというところですね。
すごいね。ファストリーさすがですね。
名前のところにファストっていうのが
付くぐらい早いです。さすがです。
続いてキャッシュ線によるところですね。
ちょっと図が書いてありまして
さっきのようなCIとかサーバーとかディベロッパーというところの
フロー図がありますけど
これちょっと説明すると大変そうなので
端折ります。
見ていくとリリースごとにキャッシュ戦略
キャッシュを発揮します。
これは結構任意ですよと言ってますね。
リリースごとにキャッシュを発揮は
ありかしらありじゃないですか。
リリースしてる時点でキャッシュを更新するのは
正しい話だと僕は思ってますね。
更新系で依存するキャッシュを
発揮しましょうと。
もしくはクライアントはURLをキーに
各レイヤーのキャッシュを問い合わせます。
キャッシュがなければ動的に生成します。
これが一応キャッシュ戦略だと言ってますね。
いいんじゃないですかね。
リリースごとにキャッシュを発揮します。
更新系で依存するキャッシュを発揮します。
クライアントはもちろんURLをキーに
各レイヤーのキャッシュを問い合わせます。
キャッシュがなければ動的に作ってあげて
それは普通に開始します。
その時だけはCDNじゃなくて
そのままアプリケーションサーバーまで
移動させてあげるということじゃないですかね。
か、エッジサーバー上で改めて再生成するのとかね。
インストラルってそういうことをするようなものなのかな。
実際ビルドしてるけど
ソースコード自体をCDNに置いておけば
同じことをCDNがするので
エッジサーバー上でキャッシュがなければ
動的に作れるのであれば作るのは素晴らしいなと思いましたね。
18:00
ISR JAMSTACKでさらにできるといいなという思うこと。
キャッシュ不整合状態を短くした上で
多くのキャッシュをヒットさせたい。
それはそうです。
ハイパフォーマンスのフロントエンドの責務も
負担をさせないためのキャッシュ制御が
主になってきます。
キャッシュ制御というのはCDNエッジ上から細かくやれると
嬉しいよねって言ってます。
というのがフリで、そろそろCDNエッジワーカーが
欲しくなってきませんか。
前置きとフリがすげえ長かったんですけど
いわゆる最近話題のエッジワーカーですよね。
クラウドフレアワーカーズの話が出てくるのかな。
違いますね。
ここからやっとCDN最高の話が来るそうですね。
というところです。
今日のタイトル記事に
Weekly Frontend Roundup from Tokyo
って書いてるくせに多分今日これ読めない気がしますし
みずさんのこの記事だけで
もう30分くらいかかりそうです。
今読んでるんですけど、まだ3分の1
いってないぐらいなので
明日までに続きたいと思います。
ごめんなさい。
じゃあ行きましょう。
これまでのCDNの最高というところです。
CDNの復習ですけども
リクエスト元から地理的に近い場所で
レスポンスをキャッシュし
返却する仕組みだよと言ってます。
api.twitter.comと
skypack.devで比較しましたよという
下の比較記事は
pingですね。
pingの時間をざっくりと
比較をしてみましたと。
api.twitter.comにpingを送ってみましたとすると
56データバイト
返ってくるんですけど
だいたい
ICMPシーケンスは
投げる回数ごとに
カウントされるので
そこは無視して
タイムは
183.429ミリ秒かかってます。
すごいかかってますね。
とはいえやっぱりAPIなんで
すごいと言っても全然早いんですけど
それでもやっぱりAPIコールからレスポンスだけで
183ミリ秒かかると言うと
そこからフロントエンド側が
それを受け取ってデータを受け取って処理して
わちゃわちゃっていう連打力しなきゃいけないんで
ちょっと時間かかりますよね。
逆にpingのほうですね。
skypack.devというところを見ましょうと。
そこを見てみると
タイムは1回目6.695
2回目10.566というところで
1回かかっても
10ミリ秒単位ぐらいしかいかないと。
これは全然早いですね。
さすがやっぱりCDNだと思いましたね。
この差はでかすぎる。
実に何か数十倍の差が出てくる
っていうのはそれはやっぱり違いますね。
なのでやっぱりCDNでいいなと思いました。
がんばればそのCDN
それのIP最適化っていうのは
自分でも作れますよと言ってます。
Dev2のMegajacobさんという方の
How to build your own CDN IO1
っていう記事があるそうですね。
これを見る限り
要約しますと
GEDNSですね。
あとGEYP技術を使って
地理的に近いエンドポイントに
リクエストを振り分けることができるよ
と言ってますね。
クラウドDNSとか
Amazonルート53とか
GoogleクラウドDNSとか
クラウドフレア等がサービスして
21:00
支援してますよと言ってます。
ルート53ってそんなことできるのか。
IP制御とか
IPを作ったやつとか
これドメインの話だと
思いましたけど
自分で作れるようになるんですね。
ルート53知らんかったわ。
実際難しいのは
ここから先の分散ファイルシステムの
実装のところが本当は難しいよと言ってますね。
そういうサービス使えば
エンドポイントリクエスト振り分けるまでは
そんなに難しくないというところなんですね。
これまでのCDNの役割として
赤前だったりクラウドフロントだったり
クラウドフレアだったりファストリーだったり
いわゆるそのCDNのエッジサーバーを提供している
サービス会社ですね。
お金に余裕があるんだったら
赤前を使うのがやっぱりいいと思います。
赤前高いんですよ。
それだけの性能とかパフォーマンスが出るの。
あとなんだかんだ言って
AWSのクラウドフロントを使うのも
全然いいんじゃないかと思いますね。
あといろんな設定ゴリゴリやったり
バックエンド側の知識とか
本気でやりたいという方は
ファストリーが良さそうな気がしますね。
クラウドフロントは全然触ったことがないので
問題感です。
では行きましょう。
主に静的アセット配信の最適化をするというところが
CDNの役割です。
L4スイッチ相当のところですね。
主にTCP、HTTPヘッダーを見て
ネットワークを振り分けますと。
CDNを利用する開発者にできるのは
ヘッダーを付与して
発揮間隔を指定する程度ですね。
フロントエンドができるのはそういうことです。
キャッシュコントロールの
SMAXエイジを300とか
MAXエイジ180とか
そんな風に設定すること
ぐらいですね。
ファストリーVCLによる
動的なエッジ処理というのがあるそうです。
大体2011年ぐらいからかな
みたいなのをざっくり
追ってみたらしいですね。
CDNっていうのはある程度
決め打ちだったんですけど
ファストリーではCDN利用者でも
バーニッシュVCLでリクエストコントロール
できるようになったらしいです。
バーニッシュVCLっていうのは
よくわかってないんですけど
そういうものがあるらしいです。
例として一応オリジンで
フィーチャーフラグというのを
切り替えるような処理を
下に書いてますけども。
ifのrequest.restartっていうのが
==0だった場合は
リクドットバックエンド
==forigin0にしてます。
また次にセットで
リクドットhttp.tmporigin
originURLか。
をreq.urlにしてあげます。
さらにreq.urlを
そこにセットしてあげておいて
req.urlを上書きしますと。
ResponseHeaders
questionの
flags="groupenewheader
○○○みたいなので付けてあげます。
req.restartが0じゃない場合
elseの場合は
setのreq.backend="forigin1
またisDisabled
thisEnablesIt
thisEnablesIt
これコメントか。
req.http.
fastlyForceShield
っていうのを1にしてあげますと。
リターンルックアップしてあげます。
24:01
みたいな書き方ができるそうですね。
割と本当にあれですね。
fastlyってがっつりちゃんと設定できたり書きたりするんですけど
これすごい。
なるほど。
このふうにやれば動的な処理のところが
できますよって言ってました。
fastlyVCLの問題がでもありますと言ってまして
VCL自体が
fastlyVarnish前提でほぼ
fastly専用言語だと。
なるほどね。
アプリケーション設計の全体が
fastlyVCLありきになり
強いロックインが発生しました。
そりゃちょっと
導入したくないというか
使わなければ使わなくてもいいかもしれないですけど
そしたら別にfastlyVCL使う
メリットもあんまないなっていう感じに
聞こえました。
自分は
これを懸念して
新規プロダクトや転職先で
fastlyを選択できる保証がないので。
そこはやっぱりそうですよね。
逆に言うとロックインを
許容してそれでもやっぱり
スピードに注力するっていうところに
倒してるんであればそれはそれでって感じですけど
なんか大変そうな気がしますね。
fastlyVCL
ありきなアプリケーション設計を
しなきゃいけないっていうのは
後々不細だらけになる気がしてて
それもなんか怖いなと思うんですよ。
仮に採用したとして
より良い選択肢が出てきたときに乗り換えられるかって言うと
それもかなり大変だと思います。
ほぼ作り直しになると思いますので。
ビジネス的なインパクトが
かなり大きいんじゃないかというので
なんとも言えないですね。
本当にfastlyVCLと
骨を埋めるというか、共に死ぬみたいなところまで
覚悟を決めるんであればいいんだと思いますけど
それを我々エンジニアとして
意思決定できるかというとしたくはないなと思いました。
続いて
クラウドフレアワーカーズの登場です。
クラウドフレアワーカーズの
リンク一応貼ってますけど
クラウドフレアCDN上で動く
JavaScriptのV8エンジンの
実行環境というのができましたよと。
汎用言語JSWASMで動く
CDN Edgeワーカーというのを各社も追従してきましたよと。
fastlyでは
コンピューティットアッドエッジ
というウェブアセンブリのところですね。
AWSはクラウドフロントファンクションですね。
ES5ってところです。
あとはDenoですね。Denoデプロイというのがあって。
そういうものがあると。
クラウドフレアワーカーズに
フォーカスされてますけど
各社も汎用言語で動くような
CDN Edgeワーカーというのを一応
追従してるよということは
ご紹介されてますよということでした。
今回はクラウドフレアワーカーズに
フォーカスされるところですね。
まだ半分いかないのか。
この記事すごいなスライド。
何百ページくんだろう。
CDN Edgeワーカーの特徴ですね。
ユーザーから地理的に近いCDN上で応答するので
もちろん低遅延ですよと。
メモリーフットプリントの小さいランタイムを
世界中のDCで実行する以上は
強いマシンとは仕込めなさそう。
強めのCPU制約ですね。
実行制限とかをすると。
これが特徴になります。
クラウドフレアワーカーズに見る
CPU制約1
その記事のリンクも貼ってますね。
developers.cloudflare.com
というところにブログがあるっぽいので
27:00
そこも見てもらってもいいと思います。
課金すること制約がよくなりますと。
CPUタイムとコストというところを
図表にしてますね。
CPUタイムとコスト、縦軸にフリーと
バンドルド、アンバウンドというところで
やってますと。
CPUタイムはフリーの得意だと
1リクエストごとに10ミリ秒かかりますと。
バンドルドだと1リクエストごとに
50ミリ秒かかりますと。
アンバウンドだと1リクエストごとに
3万ミリ秒ですね。30秒かかると。
それはだるいですね。
課金したほうがいいなと感じますけどね。
CPU制約。
逆か。1リクエストごとに
3万ミリ秒までいけるってことかこれ。
課金するほど高い
コストが出るんじゃないかと感じます。
コストのところですね。
フリーの場合だと1デイに
10万って言ってますけど
単位は何だ?円なのかドルなのか
まだ円だと思いますけども
1デイごとに10万。
これ円ですか?
分かんないけど単位は知りたいですね。
バンドルドのほうは
1マンスで
10ミリオンプラス
1ミリオンの
1ミリオンごとに0.5ドルだと言ってますね。
1ミリオンごとに
0.5ドルなので
プラスか。プラスですね。
基本的には
1ヶ月で10ミリオンだと
言ってますけど
これコスト円とかドルとか
そういうわけじゃない。
プラスだって。
それをオーバーしたときに
バンドルドの場合は
1ヶ月10ミリオンになってて
それプラスオーバーした場合は
1ミリオンがありますと言ってますね。
お金の話だって。
最後ですね。
アンバウンドのところですね。
ときは1ヶ月に1ミリオンで
プラスオーバーしたら
1ミリオンごとに0.15ドルだと言ってます。
あれ全然安いじゃん。
あーん。
というところです。
この辺の比較はちゃんと単位とか
見れてないのでやっぱり本基準
見た方が良さそうですね。
クラウドフレアワーカーズに見える
かっこいいとかでいきますけども
ここからガチャガチャ見ていくのは
ちょっと中途半端すぎるので
一旦CDN Edgeワーカーの特徴まで
読んだので続きはまた明日にしようかなと思います。
一応30分も超えましたので。
というところで今日の朝活はこちらで以上にしたいな
と思います。
というわけで明日も続いて
エッジサイドフロントエイドという新領域の記事ですね。
記事というかスライドですけど見ていこうかなと思います。
なかなか本当は
多分登壇自体は見た方が良かった
と思うんですけど僕は全然その登壇は知らなかったので
後からツイッターで
スライドをみずきさんが流されているのを
見て初めて知ったので。
仕方ないですね。
一応見ながら勉強していこうなと思いますので
また明日もご用意いただければ嬉しいなと思います。
というわけで今日もこちらで以上にしたいと思います。
月曜日ですね。
今日からまた1週間
最終
今月7月の最終週ですね。
皆さん頑張っていければと思います。
お疲れ様です。
