Upstash Redis読み取り削減の対処案

現状分析

現在の実装では、Cloudflare Workers (workers/src/function.prod.ts) が以下の2つのエンドポイントでUpstash Redisに直接アクセスしています:

• GET /page/{id} - 個別ページのOGP取得
• GET /user/{handle} - ユーザーのページID一覧取得（redis.scan()を使用）

利用が増加し、Upstash Redisの無料利用枠では収まらなくなってきました。

対処案の比較

案	実装コスト	Redis削減率	レイテンシ	追加コスト
1. Cloudflare Cache API	⭐ 小	80-95%	✅ 最速	無料
2. Cloudflare KV	⭐⭐ 中	90-99%	✅ 高速	$0.50/月~
3. Cloudflare R2	⭐⭐⭐ 大	95-99%	⚠️ やや遅	$0.15/月~
4. Durable Objects	⭐⭐⭐ 大	99%+	✅ 最速	$5/月~
5. 組み合わせ案	⭐⭐ 中	95%+	✅ 高速	無料～低

---

✅ 推奨案1: Cloudflare Cache API（最小変更・無料）

概要

Workers内でCache APIを使い、Upstash Redisからの取得結果を一定期間キャッシュ。

メリット

• ✅ 実装コストが最小（30-50行の追加のみ）
• ✅ 完全無料
• ✅ レイテンシが最も低い（エッジキャッシュ）
• ✅ Cloudflare標準機能のみ使用

デメリット

• ⚠️ キャッシュヒット率はアクセスパターンに依存
• ⚠️ TTL管理が必要

実装イメージ

// workers/src/function.prod.ts に追加
const CACHE_TTL = 60 * 60 * 24; // 24時間（調整可能）

const readPagedb = async ({
    request, redis
}: {
    request: Request,
    redis: Redis
}) => {
    const url = new URL(request.url);
    const cacheKey = new Request(url.toString(), request);
    const cache = caches.default;

    // キャッシュ確認
    let response = await cache.match(cacheKey);
    if (response) {
        return await response.json();
    }

    // 既存のRedis読み取りロジック
    const pathArray = url.pathname.split('/');
    let data: response = { /* ... */ }
    
    // ... 既存の処理 ...

    // レスポンスをキャッシュに保存
    const responseToCache = new Response(JSON.stringify(data), {
        headers: {
            'Content-Type': 'application/json',
            'Cache-Control': `public, max-age=${CACHE_TTL}`,
        },
    });
    await cache.put(cacheKey, responseToCache.clone());
    
    return data;
}

削減効果

• 同一ページへの再アクセス: 100%削減
• 人気コンテンツ: 80-95%削減（TTL次第）

---

✅ 推奨案2: Cloudflare KV + Cache API（高効率）

概要

• KVをセカンダリストレージとして使用
• Upstash Redisは書き込み専用（Firebase Functionsから）
• Workersは主にKVから読み取り、Cache APIで更に加速

メリット

• ✅ 90-99%のRedis削減
• ✅ KVの無料枠: 100k reads/day（通常十分）
• ✅ 読み取りレイテンシが安定
• ✅ 容量制限がほぼない

実装概要

1. firebase/functions/src/ogpGenerator/addPagedb.tsでKVへも同時書き込み
2. Workersで優先的にKVから読み取り
3. KV miss時のみRedisにフォールバック
4. Cache APIでさらにキャッシュ

wrangler.toml への追加設定

[[kv_namespaces]]
binding = "PAGEDB_KV"
id = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

[env.prod.kv_namespaces]
binding = "PAGEDB_KV"
id = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

追加コスト

• 無料枠内: 100k reads + 1k writes/day + 1GB storage
• 超過時: $0.50/1M reads, $5/1M writes

---

💡 推奨案3: 組み合わせ案（Cache + TTL戦略）

概要

Cache APIに加え、アクセスパターンに応じたTTL最適化を実施。

実装戦略

1. /page/{id}エンドポイント

• Cache TTL: 24時間（OGPは変更されないため長めに設定可）
• ユーザーがページ削除時にキャッシュパージ

2. /user/{handle}エンドポイント

• Cache TTL: 5-10分（投稿一覧は頻繁に更新される）
• または、初回アクセス時のみRedis、以降はstale-while-revalidate

3. キャッシュパージ機能

• Firebase Functionsからページ削除時、Workers経由でキャッシュ削除

実装例（キャッシュパージ付き）

// workers/src/index.ts に追加
export default {
    async fetch(request: Request, env: Env) {
        const url = new URL(request.url);
        
        // キャッシュパージエンドポイント（認証必要）
        if (url.pathname.startsWith('/purge/') && request.method === 'POST') {
            const cache = caches.default;
            const keyToPurge = url.pathname.replace('/purge/', '/page/');
            await cache.delete(new Request(keyToPurge, request));
            return new Response(JSON.stringify({ result: 'purged' }), {
                status: 200
            });
        }
        
        // 既存の読み取りロジック
        // ...
    }
}

---

🚀 段階的実装プラン（推奨）

Phase 1: Cache API実装（即座に効果）

1. workers/src/function.prod.tsにCache APIを追加
2. /page/エンドポイントのみキャッシュ（24h TTL）
3. デプロイして効果測定

実装時間: 1-2時間
期待効果: Redis読み取り 70-90%削減

Phase 2: TTL最適化

1. /user/エンドポイントにも短いTTLでキャッシュ追加（5-10分）
2. アクセスログを確認してTTLを調整

実装時間: 30分-1時間
期待効果: Redis読み取り 80-95%削減

Phase 3: 必要に応じてKV移行

1. 無料枠を超える場合のみKV導入を検討
2. Firebase Functionsの書き込み先をKVに追加
3. WorkersをKV優先読み取りに変更

実装時間: 4-6時間
期待効果: Redis読み取り 95%+削減

---

📈 効果予測

Cache API のみ（案1）

• 初期実装時間: 1-2時間
• Redis削減率: 70-90%（アクセスパターン次第）
• 追加コスト: 0円

Cache + KV（案2+3）

• 初期実装時間: 4-6時間
• Redis削減率: 95%+
• 追加コスト: 無料枠内なら0円

---

🎯 最終推奨

まずは案1（Cache API）を実装することを推奨します。

理由

1. 最小変更で即座に効果
2. 無料で80-90%のRedis読み取りを削減可能
3. 必要に応じて後からKVを追加できる

実装後の確認

• Upstashダッシュボードで実際の削減率を確認
• 無料枠に収まらない場合のみKV導入を検討
• 段階的アプローチで確実に改善

---

追加の最適化案

キャッシュ戦略の詳細設定

// TTLを内容に応じて動的に設定
const getCacheTTL = (pathArray: string[]): number => {
    const object = pathArray[1];
    
    switch (object) {
        case 'page':
            // 個別ページは24時間（OGPは不変）
            return 60 * 60 * 24;
        case 'user':
            // ユーザー一覧は10分（更新頻度が高い）
            return 60 * 10;
        default:
            return 60 * 5; // デフォルト5分
    }
};

キャッシュヘッダーの最適化

const headers = {
    'Content-Type': 'application/json',
    'Cache-Control': `public, max-age=${ttl}, s-maxage=${ttl}`,
    'CDN-Cache-Control': `max-age=${ttl}`,
    'Cloudflare-CDN-Cache-Control': `max-age=${ttl}`,
};

エラーハンドリング

try {
    // キャッシュからの読み取り
    let response = await cache.match(cacheKey);
    if (response) {
        return await response.json();
    }
} catch (error) {
    // キャッシュエラー時は通常通りRedisから読み取り
    console.error('Cache error:', error);
}

---

監視とメトリクス

実装後、以下の指標を監視:

1. Upstash Redis

   • 日次読み取り回数
   • 無料枠との比較

2. Cloudflare Workers

   • キャッシュヒット率
   • レスポンスタイム

3. ユーザー体験

   • ページ読み込み速度
   • エラー率

---

まとめ

最小の変更で最大の効果を得るため、Phase 1のCache API実装から開始し、効果を測定しながら段階的に最適化していくアプローチを推奨します。