昨年のおさらい
Wasm/WASI の最新事情(2025年版)
Wasm 2.0 リリース (2024/12/18)
- Vector instructions: SIMD命令のサポート
- Bulk memory instructions: メモリのブロックを効率的に一括操作する命令のサポート（memmoveやmemsetのような）
- Multi-value results: 命令やブロックや関数が複数の戻り値を直接返せるように
- Reference types: JavaScript等の外部オブジェクトを第一級の値として直接参照可能に
- Non-trapping conversions: 浮動小数点数から整数への安全な変換命令のサポート
- Sign extension instructions: 整数型の符号を拡張する新しい命令セットのサポート
Wasm 3.0 リリース (2025/09/17)
- 64-bit address space
- Multiple memories
- Garbage collection
- Typed references
- Tail calls
- Exception handling
- Relaxed vector instructions
- Deterministic profile
- Custom annotation syntax
あわせて読みたい;
WASI の動向
- WASI 0.1(preview1): 枯れてる仕様。
Viceroyなどで利用 - WASI 0.2(preview2): 2024年1月にローンチ。Component Model に基づく仕様、
wasmtime serveなどで利用 - WASI 0.3(preview3): preview 版が最近リリース。Component model への native での async のサポートが追加。年内にリリース見込み。
言語ツールチェインの WASI に関する動向
- Rust
- 2017: wasm32-unknown-unknown ターゲットが追加
- 2019(1.36): wasm32-wasi ターゲットが安定化（snapshot_preview1）
- 2024(1.78): wasm32-wasip2 対応追加
- Go
- 2018(1.11): Wasm へのコンパイルをサポート開始
- 2023(1.21): WASI p1 対応追加
- TinyGo
- 2020(0.12.x): Wasm 対応追加
- 2024(0.32.x): WASI サポートを wasip1 とリネーム
- 2024(0.33.x): wasip2 対応追加
Cache の話
Cache のはたらき
- 一度処理した結果を短期的に記憶しておく仕組み
- 計算量やメモリ使用量などを節約
- 全体の処理時間短縮に寄与
- 結果的に処理にかかる費用やリソースを抑えられる
様々な Cache（一例）
- ハードウェアや OS レベルのキャッシュ
- CPU キャッシュ(L1, L2, ...)
- OS のファイルキャッシュ（ページキャッシュ）
- GPU キャッシュ（シェーダーキャッシュ等）
- Web・ネットワークレベルのキャッシュ
- DNS キャッシュ
- HTTP キャッシュ(ブラウザキャッシュ)
- CDN キャッシュ
- アプリケーション・データベースレベルのキャッシュ
- Redis や memcache などのアプリケーション用のキャッシュ
- データベースキャッシュ
- PHP の OPcache や Python の .pyc のような VM 用のバイトコードのキャッシュ
- LLM のプロンプトキャッシュ
Cache 起因の不具合の例
- なぜか更新が反映されない
- キャッシュが温まるまで時間がかかる（例：システムメンテナンスの直後、アプリケーションキャッシュが初期化された状態で大量のリクエストを一気に受け付けてシステムが過負荷になる）
一般的な Cache の動作フロー
ブラウザや CDN の Cache の動作フロー
- HTTP Cache の場合、サーバから取得した Cache-Control ヘッダの内容によって Cache の振る舞いが変わる
- システムから見ると、外部から inject された可変の値によって Cache の動作が決まるイメージ
あわせて読みたい;
- RFC 9111: Cache-Control ヘッダなど HTTP Caching にまつわる現行の仕様（旧仕様は RFC 7234)
- Yamagoya 2023 : HTTPが全てを飲み込む 〜 IETF 118の現場から
クイズ: Cache される？されない？
<html>
<body>
<script>
async function runner(){
const url = "https://http-me.fastly.dev/?wait=1000&header=Access-Control-Allow-Origin:*&header=Cache-Control:max-age=30";
await fetch(url);
await fetch(url); // Cache される？されない？
await fetch(url);
}
runner();
</script>
</body>
<html>
Cache は便利、正しく制御さえできれば
-
問題: 意図しないキャッシュがされる
-
対策例: キャッシュバスティング（URLの末尾にランダムな文字列をクエリストリングとして付与するようなやつ）
-
問題: 古くなるなど誤った情報がキャッシュとして残る（が、アクセス数/コストを下げるために TTL は長く取りたい）
-
対策例: CDN であれば高速なパージが可能な CDN を使う
-
問題: サーバ側を別の外部ベンダーが管理していて Cache-Control などのレスポンスヘッダを制御できない
-
対策例: ???
Fastly Compute の HTTP Cache API
Fastly Compute の HTTP Cache API
- 従来の API では処理できなかった、Http request と response を送受信する際の Cache の振る舞いを細かな粒度で制御可能にする API
const backendResp = await fetch(clientReq, {
cacheOverride: new CacheOverride({
afterSend(resp) {
resp.ttl = 300;
resp.headers.set('Cache-Control', 'max-age=86400'); // Rules for browsers
resp.headers.set('Surrogate-Control', 'max-age=31536000'); // Rules for downstream caches
resp.headers.delete('expires');
},
}),
});
あわせて読みたい;
- WHATWG の Fetch API 定義 https://fetch.spec.whatwg.org/#request-class
ブラウザや CDN の Cache の動作フロー（再掲）
Fastly Compute の場合の HTTP Cache API の動作フロー
before-send と after-send のタイミングで任意の処理が inject 可能になる
HTTP Cache API の使い所の例
- 複数のバックエンドから受け取り異なる Cache-Control 等の http ヘッダやボディの内容に対して前処理を行い整合性を取る
- 取得された Content-type 毎に任意の TTL を設定する（画像や動画は TTL 長めにする一方で
application/jsonの場合はキャッシュしない、など）
const backendResp = await fetch(clientReq, {
cacheOverride: new CacheOverride({
afterSend(resp) {
let cache = undefined;
switch (resp.headers.get('content-type')) {
case 'image':
resp.ttl = 67;
break;
case 'text/html':
resp.ttl = 321;
break;
case 'application/json':
cache = false;
break;
default:
resp.ttl = 2;
}
return { cache };
},
}),
});
まとめ
- Wasm の仕様や関係するツールチェインが進化
- Cache は正しく扱えれば武器になる
- Fastly Compute では高速なキャッシュのパージに加えて細かな粒度で CDN 上の Cache 制御が可能
お知らせ
明日ワークショップがあります;
作って学ぶ Fastly Compute ベースのリアルタイムアプリ開発と MCP 入門
(ServerlessDays Tokyo参加者用)登録フォーム:
https://forms.gle/YgdCqW3udbRSWbEm8