Recap CDN, Edge, WebAssembly | ワインと鍋.js#1

ワインと鍋.js#1 の発表資料です。

Transcript

1. Recap CDN / Edge / WebAssembly ワインと鍋.js#1 @sadnessOjisan
2. ⾃⼰紹介
3. Edge Computing の⾼まり • Cloudflare workers • Fastly Compute@Edge • Deno Deploy • …
4. ⽤語 • FaaS: Cloud Functions, Lambda のようなもの • CDN: Fastly のようなもの • エッジコンピューティング: Fastly Compute@Edge, cloudflare workers のようなもの 例外がついてまわるので、定義を与える前にまずは製品名でニュアンス を共有させてください。
5. What is edge • CDN⽤語集 • https://www.cloudflare.com/ja-jp/learning/cdn/glossary/edge-server/ • edge: For Internet devices, the network edge is where the device, or the local network containing the device, communicates with the Internet. The edge is a bit of a fuzzy term; for example a userʼs computer or the processor inside of an IoT camera can be considered the network edge, but the userʼs router, ISP, or local edge server are also considered the edge. The important takeaway is that the edge of the network is geographically close to the device, unlike origin servers and cloud servers, which can be very far from the devices they communicate with. • データ処理をデバイスに近いところで利⽤すれば性能向上やコスト削減が⾒込め る
6. Edge vs CDN • CDNは Content Delivery Network • インターネットコンテンツを⾼速配信するために連携する地理的に分 散されたサーバーのグループ • https://www.cloudflare.com/ja-jp/learning/cdn/what-is-a- cdn/ • Push型 • コンテンツをデプロイする • Pull型 • CDNサーバーにキャッシュを持たせる • キャッシュは Cache-Control や Surrogate-Control で制御で きる
7. Edge vs FaaS / Severless • FaaS は Function as a Service • サーバープロセスを持たず、関数単位でのデプロイ、実⾏が可能 • Edgeと違い、ロケーションは固定 • Edgeは呼び出し元に近いPOPで実行される
8. Edge Computing の特徴 地理的に近い場所でオリジンサーバ ーに近いことができる • CDN のように使える • Cacheの操作 • req/res の編集 • サーバーレスのようにも使える • ストレージアクセス • SSR
9. とはいえ、Edge の注⽬は過剰な気はする • Cloudflare Workers 注⽬されすぎでは︖ • 国内サービスにおいてはエッジもオリジンも東京では︖ • エッジじゃなくても代⽤⼿段はたくさんある • キャッシュを使いたい、ReqResいじりたい: CDN • 負荷分散したい: スケーリングする系のPaaS • 前段が欲しい: リバースプロキシ • ⼀つ圧倒的な強みはある • VCL以外の⾔語でもコントロールができる
10. EdgeでWasmを動かす
11. Wasm, WASI とは • WebAssemblyは仮想命令セットアーキテクチャあるいはプログラミング⾔語の⼀ 種である。C・Rustなど様々なプログラミング⾔語のコンパイルターゲットとして Wasmバイナリは⽣成され、ウェブブラウザを含む様々な環境内のスタックベー ス仮想マシンにより実⾏される。ネイティブコード相当の⾼速性・隔離環境での メモリ安全な実⾏による安全性・仮想マシンによるハードウェア/プラットフォー ム可搬性・ソースプログラミング⾔語中⽴性などを特徴とする[4]。この命令セッ トはバイナリ形式で定義されており、またアセンブリ⾔語ライクなテキスト形式 も定義されている（その意味で低⽔準プログラミング⾔語といえる）。 (Wikipedia) • ブラウザ以外でも使えるようにするための規格が WASI • 実装: wasmtime, wasmer, (lucet) • https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-intro.md
12. （余談）⾃分の顔のモザイクはWasm製です • DOMの世界はJSで書く • ロジックはWasmで書く • データは Buffer列を使ってやり取りする https://blog.ojisan.io/rust-mosaic-web-app/
13. CDNではWASIが動く • ブラウザではないものの上でWasmを動かす規格がWASI • CDNがWASIをサポートすれば、エッジでWASMが動く
14. ポータビリティに優れる • WASIの実⾏環境を⽤意すれば、本番、開発、テスト、ローカル環境 で実⾏ができるようになる • 書いたロジックのテストも可能になる。VCL時代は準備が⼤変だった • Viceroy (Fastly) • Viceroy provides local testing for developers working with Compute@Edge. • Rustで書こうが、JSで書こうが、Wasmに変換してしまえば⼿元の 検証環境として使える • https://github.com/fastly/Viceroy
15. JSからもWasmを作れる • RustのようなWasmを作る⾔語は、フロントエンドエンジニアにとっ て障壁が少しある。JSを書きたい。JSのようにwasmへのコンパイル 機能を持っていない⾔語をWasmとして動かしたいアプローチ • js-compute-runtime • javy
16. JSをWasmランタイム上で動かすとは • Wasm runtime を持つCDN上でJSを動かすために、JSエンジン⾃体 をWasm化してデプロイする • Wasm 化したエンジン内でJS、もしくはbytecodeを実⾏する https://bytecodealliance.org/articles/making-javascript-run-fast-on-
17. JSをWasmとして実⾏するとは • JSを実⾏したbytecodeをデータとして持つ • それをwasm化してJS実⾏エンジンに流すと、wasm として JS を実 ⾏できる https://bytecodealliance.org/articles/making-javascript-run-fast-on-
18. JSをWasmとして動かす理由はパフォーマンスにある • ハードな環境において採⽤されるJSエンジンの都合、全ての環境で JIT できるとは限らない、JITできなければパフォーマンスが悪い • JSエンジンの起動コスト https://bytecodealliance.org/articles/making-javascript-run-fast-on-
19. セキュリティ⾯にもメリット • 起動コストが少ないなら、リクエストごとに実⾏インスタンスを作れ る • 隣のリクエスト内容を除けないように分離を頑張る必要がない • Wasmの実⾏エンジン⾃体、JS実⾏エンジンに⽐べると遥かに少量で 、検証などがしやすい
20. 起動時間を減らす工夫 • JSエンジンやアプリケーションの起動は時間がかかる • コールドスタートで時間がかかる原因 • Wizer: 事前コンパイル. コードがデプロイされる前に、ビルドステッ プの⼀部として、JS エンジンを使って JS コードを初期化の終わりま で実⾏。JSコードのバイトコードをスナップショットとして扱う。 https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly bytecode
21. wizer • The WebAssembly Pre-initializer • Wasm の init を実⾏し、そのときの wasm instance の状態をスナッ プショットする • ライブラリとしてはRustから使うが、コマンドとしてはC++からも使 える https://github.com/bytecodealliance/wizer
22. 詳しくはここに全部かかれている https://bytecodealliance.org/articles/making-javascript-run-fast-on- webassembly
23. Wasm を使わない環境は危険なのか︖遅いのか︖
24. V8 isolate • 軽量な実⾏環境 • ランタイムごとに数千の isolate を実⾏ 可能 • メモリは分離されている • Nodeのプロセスを⽴てるより、遥かに 少ないメモリと起動時間で実現できる https://developers.cloudfla re.com/workers/learning/ how-workers-works/
25. V8 snapshot • Isolate Context を dump したもの • スナップショットをヒープに直接デシリアライズして、初期化された コンテキストを取得 • コンテキストの作成にかかる時間を40ミリ秒から2ミリ秒未満に短縮 • 初期化の短縮、コールドスタートの時間を短縮できる https://v8.dev/blog/custom-startup-snapshots
26. WasmとV8の⽐較 • セキュリティ • リクエストごとの分離 vs V8 Isolate • パフォーマンス • Wizer vs V8 Snapshot • V8 と Wasm 、どっちが優れているか • 知りません • 計測を考えましたが、ベンチの設計が難しくて挫折しました • 各サービスがそのうち⽐較してくれると思っています
27. Fastly Compute@Edge で婚活ブログ書いた • 来年、いい年になるのでそろそろ 本気で結婚しようと決意 • 友⼈がマッチングアプリ代⾦をくれた • アプリ代⾦くれた⼈やお世話になった⼈のみ多くの情報が⾒れる婚活ご報告サイ トを作った • アイデアはuhyoの⿊塗り履歴書 http://uhy.ooo/jobs/
28. 仕組み
29. PaywallとCache • 記事の有料部分のことをPaywall という • Ex) ⽇本経済新聞、Note • ユーザーの認証状態によって、Paywallのキャッシュを出し分けたい • アクセス権限が弱い⼈が、アクセス権限が強いキャッシュを引き当て てはいけない https://www.nikkei.com/article/DGXZQOUA223TB0S2A72
30. Vary header • キャッシュは、オリジンサーバーからvary header をつけることで出 し分けられる • Vary: Vary HTTP レスポンスヘッダーは、オリジンのサーバーから新 しく要求するのではなく、キャッシュされたレスポンスを使⽤できる かどうかを決定するために将来のリクエストヘッダーをどのように⼀ 致させるかを決定します (MDN)
31. トークンの解読やヘッダの操作をEdgeで • Rust の jwt 解読ライブラリを使って、CDN上で認可情報を取得 • オリジンサーバーへ権限レベルをヘッダーに付与して、request • Paywall を使うサービスとしてはオーソドックスなやり⽅ https://speakerdeck.com/sisidovski/nikkei-inside- frontend?slide=32
32. 詳しくはブログで • ⿊塗り⽤の⾔語を作るところをがんばったり、⾯⽩いポイントがある https://blog.ojisan.io/gohoukoku-backyard-tour/
33. まとめ • Wasm が動く edge サービスが流⾏りつつある • Wasm を採⽤することで速度、セキュリティ⾯においても良い • これまでCDNの操作はVCLほぼ⼀択だったが、Wasm対応によって⾃ 分が⼀番得意な⾔語を使える、Pull型CDNとしても使える