レッスン 23: パフォーマンスとスケーリング — CDN、キャッシュ、キュー アーキテクチャ

ファッション デザインとプリント オン デマンド システム アーキテクチャ — ドメイン分析から生産まで

パート 7: 運用、セキュリティ、スケール

xdev.asia

1. POD のパフォーマンス ホットスポット

• 画像を大量に使用するトラフィック (モックアップ、プレビュー、サムネイル)
• 大規模なカタログの検索/フィルタリング
• キャンペーン/シーズン別のバーストトラフィック
• バックグラウンドジョブ: レンダリング、AI、同期チャンネル

2. CDN戦略

Origin (S3/Object Storage)
    -> CDN Edge Cache
       -> Image transformation layer (WebP/AVIF, resize)
          -> Browser cache

資産の種類	TTL	キャッシュキー
不変のモックアップ	30～90日	ハッシュベースの URL
PDP画像	7日間	製品ID+バリアント+サイズ
エディターアセット	1～24時間	ユーザースコープ

3. 多層キャッシュ

L1: CDN edge
L2: API cache (Redis)
L3: Application in-memory cache
L4: DB query cache/materialized views

class ProductReadCache {
  async get(productId: string) {
    const key = `pdp:${productId}`;
    const cached = await redis.get(key);
    if (cached) return JSON.parse(cached);

    const value = await this.repo.getPdpView(productId);
    await redis.set(key, JSON.stringify(value), 'EX', 300);
    return value;
  }
}

4. キューのアーキテクチャ

Queues
  - q.realtime.preview (high priority)
  - q.print.production (high priority)
  - q.mockup.batch (medium)
  - q.channel.sync (medium)
  - q.analytics.enrichment (low)

Use dead-letter queues per domain.

interface QueuePolicy {
  maxRetry: number;
  backoffMs: number[];
  timeoutMs: number;
  concurrency: number;
}

5. データベースのスケーリング

• 製品/検索読み取り用のリードレプリカ
• パーティショニングは次のとおりです `shop_id` または `created_at` 大きなボードで
• 接続プーリング (PgBouncer)
• クエリパターンに応じたインデックス戦略

6. 自動スケーリングポリシー

ワークロード	スケールトリガー	範囲
API ポッド	CPU + P95 レイテンシー	4-60
キューワーカー	キューの深さ + ラグ	2-200
GPU推論	リクエスト/秒 + VRAM	1-20

7. 推奨される SLO

• P95 PDP API レイテンシー < 250ms
• P95 チェックアウト API レイテンシ < 400ms
• 画像の最初のバイト (CDN) < 100ms
• キューラグ (重大) < 30 秒

8. まとめ

• CDN + 画像の最適化 POD の最大のパフォーマンスレバーです

• キューの優先順位 高負荷時の重要なワークフローの保護に役立ちます

• DBスケーリング クエリ/インデックスの規律に従う必要がある

• SLO 主導の自動スケーリング コストとサービス品質のバランスをとるのに役立ちます