Workers Tech Talkに参加してきました。
コロナ禍でエンジニアになったので今まで参加してきたイベントはオンラインが多くオフラインのイベントは初めて、たぶん。
Cloudflareもフロントもにわかな私が感想言うのもあれなんですがいろいろ考えることも多かったのでせっかくなので簡単な感想を書いておきます。
classmethodさんのおしゃれなオフィスが会場でした。オフィスビル慣れてなさすぎて26階に辿り着けなくて泣きそうになりました。
chimameさんのお話です。
Cloud Runで動かしていたGraphQLサーバーをCloudflareに移したよというお話。
Cloudflareというより初手でCloud Run採用されること多いんだなーみたいなこと考えてしまった。
インフラ周り0から作り込むのそれなりに大変だと思っているのでCloud Runでそこを全部いい感じにやってくれるのはやっぱり強いんだろうな。
Cloudflareに移した理由として挙げていたコールドスタートについては運用した人しかわからない辛みなんだろうけど、パフォーマンス追求していくと無視できないんだろうか。
結局Cloud Runはコンテナ実行なのでJavaのSpring初動遅くてコンテナと相性悪い問題と同じような話なのか。
Goがコンテナと相性いいのはこういうところでシングルバイナリで最小コンテナイメージに乗せられるのが相性良すぎるんだろうな。改めてGoの良さを知る。
ん、最大5秒前後のコールドスタートが200ms程度になったのか。めちゃくちゃ改善されてる...!!
ビルド時間も短縮、コストも削減。
いいことしかない。
最初からめちゃくちゃ学びになりました
公開していただいていた資料
画像の直リンクを開いた時にgyazo.comにたどり着けないのをWorkerを使って解決したよというユースケース。
サーバー目線だとCloudflareによるパフォーマンス改善よりもCloudflareを使用した何かしらのユースケースがあったら使いたいなという気持ちでCloudflareを追っているのでこういったユースケースの発表はありがたいなと思い聞いておりました。
半分くらいの理解で聞いていたけど画像の直リンクはバイナリを返しているだけなのでリンクがない。ので、何の画像なのかわからないという話らしい。
それをWorkerで直リンクのときはHTMLを返すようにしてそれ以外はバイナリ返すみたいにしたらしい。
その判別どうやってるんだろうと思ったらリクエストヘッダーのいろんな情報見て判断してるそうです。
なるほどー
DEMO失敗した時用に用意されていた画像が面白かったです
公開していただいていた資料
https://scrapbox.io/helpfeel-dev-careers/Workers_Tech_Talks_%231_-Gyazo%E3%81%AE%E7%B4%A0%E6%9C%B4%E3%81%AA_Workers
Cloud Front + S3による画像配信をCloudflare + R2に置き換えた話。この話めちゃくちゃ具体的で作業工程がイメージできてめっちゃ学びになった。
R2はアクセス制御とかバージョニングとかS3と比較して使えない機能もあるけどそこが問題でないならR2で問題ないそう。
複雑なことしてなければWorkersすらいらないそうです。
S3からR2に完全移行する必要があるのでS3とR2に最初は両方書き込むダブルライト方式を採用したそうです。
実際に半角スペースとか//みたいなkeyが紛れていてうまくいっていなかったケースがあるそうでこういう保険大事だなーと思った。
移行時の整合性チェックもちゃんとしていて、なるほどなあと
こういう本番環境のデータを完全移行する作業精神負荷も高いしシンプルに大変だしやりきったのがすごいなと。。
コスト削減のインパクトもかなりデカかったそうです。
公開していただいていた資料
mizchiさんの話。振り落とされないように気合い入れました
本当にフロントのパフォーマンスに対しての姿勢というか考え方が全然違くてサーバーエンジニアはにわかでフロントを語ってはいけないなと思ってしまう。
JSのパフォーマンスがビルドサイズに比例するっていう話も「だからあんなにビルドサイズにこだわるのか」くらいで聞いてました。
「Dockerイメージサイズの前ではJSのバンドルサイズは誤差」というのを聞いてDockerイメージのサイズすらそんなに気にしてないのやばいなと思いました。。
あと、パフォーマンスバジェットという用語が出てきててチームでどこまでバンドルサイズ大きくしていいかみたいなのを予算として持つという考え方らしくて、なるほどなーーーーとなりました
あとは前からCloudflareでできること増えてきたことによるサーバーサイド不要説を気にしてるのだけど「10MのNodeフルスタックサーバーサイドはきつい」ということだったので安心？しました。
やっぱりスクリプトサイズやメモリサイズの制限だったり、Nodeのライブラリが動かないことだったりCloudflareは制限的なものが現時点ではまだ多いのでごりごりのサーバー実装に置き換わるものではないんだなという感じ。
wasmもスクリプトサイズの話が絡んでくるなら最適解ではなさそうなので、ただ実際はどうなのかわかんないし今後どう変わっていくかとかもあるけどサーバーが不要になる未来はまだこなそう。
公開していただいていた資料
沖縄から来られたそうです！Not A Hotel!おしゃれでかっこいい！
最初の発表のときに「gRPC動くならBFF実装できるんじゃね？」という疑問が解消された発表でした。
ダッシュボードの設定で有効にするだけでgRPCリクエストは受け入れられるそうです。
gRPCレスポンスを返すにはbufのライブラリを使うそうです。ここでbuf聞くと思わなかった。以前フューチャーさんのテックブログで知ったので気になってなけどCloudflareで利用できるんか！！
みなさんCloudflareでいろんなものを動かしててすごいな...
公開していただいていた資料
どの発表も大変学びになりとても良いイベントでした！！
最後にサーバーサイドのわたしがCloudflare気になっている理由ですが何度も言っていますがサーバーいらなくなるんじゃないかと思って追っていました。
今日の発表を聞いた上でフロント側でパフォーマンス最適化を追求するにはCloudflareを使いたくなるんだろうなという感想でサーバーの複雑な処理を持ってくるのはやりすぎなんだろうなと感じました。
サーバー目線としてはR2移行のお話やGyazoの話のようなユースケースを見つけて使えるところで使ってくことだなとざっくり思いました。
いやーでもCloudflare可能性しかなくて面白いなー
🐼