reliability-strategy-builder

信頼性戦略ビルダー

適切な障害処理と SLO で、レジリエントなシステムを構築します。

信頼性パターン

1. サーキットブレーカー

障害が発生しているサービスへのリクエストを停止し、障害の連鎖を防ぎます。

class CircuitBreaker {
  private state: "closed" | "open" | "half-open" = "closed";
  private failureCount = 0;
  private lastFailureTime?: Date;

  async execute<T>(operation: () => Promise<T>): Promise<T> {
    if (this.state === "open") {
      if (this.shouldAttemptReset()) {
        this.state = "half-open";
      } else {
        throw new Error("Circuit breaker is OPEN");
      }
    }

    try {
      const result = await operation();
      this.onSuccess();
      return result;
    } catch (error) {
      this.onFailure();
      throw error;
    }
  }

  private onSuccess() {
    this.failureCount = 0;
    this.state = "closed";
  }

  private onFailure() {
    this.failureCount++;
    this.lastFailureTime = new Date();

    if (this.failureCount >= 5) {
      this.state = "open";
    }
  }

  private shouldAttemptReset(): boolean {
    if (!this.lastFailureTime) return false;
    const now = Date.now();
    const elapsed = now - this.lastFailureTime.getTime();
    return elapsed > 60000; // 1 minute
  }
}

2. バックオフ付きリトライ

指数バックオフで一時的な障害に対処します。

async function retryWithBackoff<T>(
  operation: () => Promise<T>,
  maxRetries = 3,
  baseDelay = 1000
): Promise<T> {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    try {
      return await operation();
    } catch (error) {
      if (attempt === maxRetries) throw error;

      // Exponential backoff: 1s, 2s, 4s
      const delay = baseDelay * Math.pow(2, attempt);
      await sleep(delay);
    }
  }
  throw new Error("Max retries exceeded");
}

3. フォールバックパターン

プライマリが失敗した場合に、機能を縮退して提供します。

async function getUserWithFallback(userId: string): Promise<User> {
  try {
    // Try primary database
    return await primaryDb.users.findById(userId);
  } catch (error) {
    logger.warn("Primary DB failed, using cache");

    // Fallback to cache
    const cached = await cache.get(`user:${userId}`);
    if (cached) return cached;

    // Final fallback: return minimal user object
    return {
      id: userId,
      name: "Unknown User",
      email: "unavailable",
    };
  }
}

4. バルクヘッドパターン

障害を分離し、リソースの枯渇を防ぎます。

class ThreadPool {
  private pools = new Map<string, Semaphore>();

  constructor() {
    // Separate pools for different operations
    this.pools.set("critical", new Semaphore(100));
    this.pools.set("standard", new Semaphore(50));
    this.pools.set("background", new Semaphore(10));
  }

  async execute(priority: string, operation: () => Promise<any>) {
    const pool = this.pools.get(priority);
    await pool.acquire();

    try {
      return await operation();
    } finally {
      pool.release();
    }
  }
}

SLO の定義

SLO テンプレート

service: user-api
slos:
  - name: Availability
    description: API should be available for successful requests
    target: 99.9%
    measurement:
      type: ratio
      success: status_code < 500
      total: all_requests
    window: 30 days

  - name: Latency
    description: 95% of requests complete within 500ms
    target: 95%
    measurement:
      type: percentile
      metric: request_duration_ms
      threshold: 500
      percentile: 95
    window: 7 days

  - name: Error Rate
    description: Less than 1% of requests result in errors
    target: 99%
    measurement:
      type: ratio
      success: status_code < 400 OR status_code IN [401, 403, 404]
      total: all_requests
    window: 24 hours

エラーバジェット

Error Budget = 100% - SLO

Example:
SLO: 99.9% availability
Error Budget: 0.1% = 43.2 minutes/month downtime allowed

障害モード分析

| Component   | Failure Mode | Impact | Probability | Detection               | Mitigation                     |
| ----------- | ------------ | ------ | ----------- | ----------------------- | ------------------------------ |
| Database    | Unresponsive | HIGH   | Medium      | Health checks every 10s | Circuit breaker, read replicas |
| API Gateway | Overload     | HIGH   | Low         | Request queue depth     | Rate limiting, auto-scaling    |
| Cache       | Eviction     | MEDIUM | High        | Cache hit rate          | Fallback to DB, larger cache   |
| Queue       | Backed up    | LOW    | Medium      | Queue depth metric      | Add workers, DLQ               |

信頼性チェックリスト

インフラストラクチャ

• ヘルスチェック機能付きロードバランサー
• 複数のアベイラビリティゾーン
• オートスケーリングの設定
• データベースのレプリケーション
• 定期的なバックアップ（テスト済み！）

アプリケーション

• 外部呼び出しにサーキットブレーカーを設定
• バックオフ付きリトライロジック
• すべての I/O にタイムアウトを設定
• フォールバックの仕組み
• グレースフルデグラデーション

モニタリング

• SLO ダッシュボード
• エラーバジェットの追跡
• SLO 違反時のアラート
• レイテンシのパーセンタイル（p50、p95、p99）
• 依存関係のヘルスチェック

運用

• インシデント対応ランブック
• オンコールのローテーション
• ポストモーテムのテンプレート
• 災害復旧計画
• カオスエンジニアリングのテスト

インシデント対応計画

重大度レベル

SEV1 (Critical): Complete service outage, data loss
  - Response time: <15 minutes
  - Page on-call immediately

SEV2 (High): Partial outage, degraded performance
  - Response time: <1 hour
  - Alert on-call

SEV3 (Medium): Minor issues, workarounds available
  - Response time: <4 hours
  - Create ticket

SEV4 (Low): Cosmetic issues, no user impact
  - Response time: Next business day
  - Backlog

インシデント対応の手順

1. 受領確認：SLA 以内に受領を確認します
2. 評価：重大度と影響を判断します
3. 連絡：ステータスページを更新します
4. 緩和：被害の拡大を止めます（ロールバック、スケール、無効化）
5. 解決：根本原因を修正します
6. 記録：ポストモーテムを作成します

ベストプラクティス

1. 障害を想定して設計する：コンポーネントは障害を起こすものと想定します
2. 速やかに失敗させる：遅い障害を連鎖させないようにします
3. 障害を分離する：バルクヘッドパターンを使用します
4. グレースフルデグラデーション：クラッシュさせず、機能を制限します
5. SLO を監視する：エラーバジェットを追跡します
6. 障害モードをテストする：カオスエンジニアリングを実施します
7. ランブックを文書化する：明確なインシデント対応手順を用意します

出力チェックリスト

• サーキットブレーカーを実装済み
• バックオフ付きリトライロジック
• フォールバックの仕組み
• バルクヘッドによる分離
• SLO を定義済み（可用性、レイテンシ、エラー）
• エラーバジェットを算出済み
• 障害モード分析
• モニタリングダッシュボード
• インシデント対応計画
• ランブックを文書化済み