昨年のおさらい

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
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 レベルのキャッシュ
Web・ネットワークレベルのキャッシュ
アプリケーション・データベースレベルのキャッシュ

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