https://workers-tech.connpass.com/event/287490/
GraphQL Server on Edge
- GraphQL server をコンテナでやるとして、初手 Cloudrun を選ぶとして、
- cloudfrare workers という選択肢
- 許容しなければならないこと
- cloudfrare にロックイン、多少は依存コードは入る
- v8 isolate なので nodejs の資産は使えないhttps://www.publickey1.jp/blog/18/vmv8isolatecloudflareworkers.html
- 前までは http しか接続できなかったが、tcp が可能になったので RDS につなげられるようになった
- gcp 主体から cloudfrare 主体に書き換えることができた
- (kysely, SQL builder. schema から型を生成する. DB migration のために prisma と合わせて使う)
- メリット
- デプロイが8分から1分
- コールドスタート 5秒から200ミリ
- コンピュータリソースあたりの単価は高め(起動時間が減ることで結果的にサーバ費用は1/10に減ったとのこと)
- デメリット
- nodejsが必要な場合は別途サービス作らないといけない
- tcp はリクエスト処理しているときだけ接続可能
- まとめ
- API サーバとしては実用的な状況
- cloud frareにロックインするが、メリットはある
- ユースケースを見極めれば十分に使えるという事例だった
Gyazo の素朴な Workers
- Gyazo のユーザは北米に多いので gcp us-central に origin
- 素朴だけど明日から真似できる例として発表
- 画像をキャプチャ、画像は png として url でアクセスできるが、
- 再度アクセスすると上に gyazo と表示される
- 解決したい課題
- 画像直リンシェアされると gyazo.com に辿り着けない
- Cloudfalre proxy を CDN として使う
- 「人間が見てそう」なら画像バイナリの代わりに html を返す
- 100行ぐらいの素朴な実装
- cloudfrare worker proxy mode で使えるなら簡単に使える
- 従来アーキテクチャでの nginx/lua で持っていた logic をなくせるのはメリットとして大きそうだった
Cloudflare Workers + R2で低コストで画像配信を移行した話
- Cloudfront + S3 に対するソリューションの1つとして Cloudfrare Workers + R2 ケースの紹介
- r2
- s3互換
- s3に劣る部分はある、当てはまらない場合は検討できる
- IAM/トークン単位でのアクセス制御できない
- バケットのバージョニングできない
- S3 Glacier のようなストレージクラス概念ない
- 円安でのコスト増加への対策
- これまでの構成
- cloudfrontの後ろにnginx、basic auth、s3の構成だった
- そもそもr2配信でworkers必要？
- public buckets機能がでたのでシンプルな配信なら不要
- workers を使うとpath mappingなど複雑な処理がedgeでできる
- キャッシュは？
- kv を検討したが、従量課金でコストかかる
- cache api を使った
- コストより柔軟な画像リサイズなどやりたいなら cloudfrare imagesを使うと良い
- 移行の際はトラフィック料金がシビア
- s3とr2はダブルライトした
- 他スピード早くメモが追いつかず。移行のtipsがめっちゃ詰まってた
- ペインを移行によって解決できていてすごい
- コスト削減含め
Server Side JavaScript のためのバンドル最適化
- (前提破壊)制限が5MBから10MBになった
- サーバサイドでバンドルするメリット
- 起動高速化
- CI
- セキュリティ
- デメリット
- sourcemap で複雑化
- v8 isolate で120MBのメモリを割り当ててスクリプトを実行
- chrome のタブ1つに相当
- パフォーマンスバジェットという考え方
- バンドルサイズの上限をチームで合意しようね
gRPC Client on Cloudfrare Workers
- gRPC を cf-worker で動かす事例
まとめ
Cloudfrare Workers が何かもわからない状態で行ったので豊富な事例を聞いて活用方法はいろいろあることがわかった
