ストーリー

可用性の定量化

SLA/SLO/SLI

// SLA, SLO, SLI の関係
interface ServiceLevel {
  // SLI (Service Level Indicator): 測定値
  sli: {
    metric: string;     // 例: "成功リクエスト率"
    measurement: string; // 例: "成功レスポンス数 / 全リクエスト数"
  };
  // SLO (Service Level Objective): 目標値
  slo: {
    target: string;     // 例: "99.99%"
    window: string;     // 例: "30日間ローリング"
  };
  // SLA (Service Level Agreement): 契約
  sla: {
    commitment: string; // 例: "99.9%"
    penalty: string;    // 例: "月額の10%返金"
  };
}

可用性とダウンタイム

// 可用性レベルとダウンタイムの関係
const AVAILABILITY_TABLE = {
  "99%":    { yearly: "3日15時間36分", monthly: "7時間18分",  weekly: "1時間41分" },
  "99.9%":  { yearly: "8時間45分36秒", monthly: "43分48秒",  weekly: "10分5秒" },
  "99.95%": { yearly: "4時間22分48秒", monthly: "21分54秒",  weekly: "5分2秒" },
  "99.99%": { yearly: "52分33秒",      monthly: "4分23秒",   weekly: "1分0秒" },
  "99.999%":{ yearly: "5分15秒",       monthly: "26秒",      weekly: "6秒" },
};

// 99.99%を実現するための設計要件
const FOUR_NINES_REQUIREMENTS = {
  redundancy: "全コンポーネントの冗長化が必須",
  failover: "自動フェイルオーバー（数秒以内）",
  deployment: "ゼロダウンタイムデプロイ",
  monitoring: "リアルタイム監視と自動復旧",
  testing: "カオスエンジニアリングによる障害テスト",
};

パフォーマンスの定量化

レイテンシのパーセンタイル

// パーセンタイルによるレイテンシ測定
interface LatencyMetrics {
  p50: number;  // 中央値: 50%のリクエストがこの時間以内
  p90: number;  // 90%のリクエストがこの時間以内
  p95: number;  // 95%のリクエストがこの時間以内
  p99: number;  // 99%のリクエストがこの時間以内
  p999: number; // 99.9%のリクエストがこの時間以内
}

// なぜp99が重要か
const WHY_P99_MATTERS = {
  reason: "平均値は外れ値を隠す",
  example: {
    average: "150ms",  // 問題なさそうに見える
    p50: "50ms",       // 半数は高速
    p99: "3000ms",     // 1%のユーザーは3秒待たされる
    impact: "1000万DAUなら10万人が3秒以上待つ",
  },
};

// p99 < 200ms を達成するための戦略
class LatencyOptimization {
  strategies = [
    { technique: "キャッシュ",         layer: "アプリケーション", effect: "DB問い合わせ削減" },
    { technique: "CDN",               layer: "ネットワーク",     effect: "物理的距離短縮" },
    { technique: "コネクションプール",   layer: "データベース",     effect: "接続オーバーヘッド削減" },
    { technique: "非同期処理",         layer: "アプリケーション", effect: "重い処理のオフロード" },
    { technique: "データローカリティ",  layer: "インフラ",        effect: "データ近接配置" },
  ];
}

スケーラビリティの定量化

// スケーラビリティの指標
interface ScalabilityMetrics {
  currentLoad: {
    qps: number;
    concurrentUsers: number;
    dataVolume: string;
  };
  targetLoad: {
    qps: number;
    concurrentUsers: number;
    dataVolume: string;
    timeline: string; // いつまでに
  };
  growthRate: {
    users: string;   // 例: "月20%成長"
    data: string;    // 例: "日10GB増加"
  };
}

// 容量計画の例
const CAPACITY_PLANNING = {
  current: {
    qps: 1000,
    servers: 4,
    costPerMonth: "$2,000",
  },
  projected_1year: {
    qps: 10000,
    servers: 32,       // 水平スケーリング
    costPerMonth: "$12,000",
  },
  decision: "QPSが5000を超えた時点でシャーディング導入",
};

非機能要件マトリックス

// プロジェクトの非機能要件を整理するテンプレート
interface NFRMatrix {
  category: string;
  metric: string;
  currentValue: string;
  targetValue: string;
  priority: 'P0' | 'P1' | 'P2';
  measurementMethod: string;
}

const EXAMPLE_NFR_MATRIX: NFRMatrix[] = [
  {
    category: "可用性",
    metric: "サービス稼働率",
    currentValue: "99.9%",
    targetValue: "99.99%",
    priority: "P0",
    measurementMethod: "外形監視 (Synthetic Monitoring)",
  },
  {
    category: "パフォーマンス",
    metric: "API応答時間 (p99)",
    currentValue: "500ms",
    targetValue: "< 200ms",
    priority: "P0",
    measurementMethod: "APMツール (Datadog, New Relic)",
  },
  {
    category: "スケーラビリティ",
    metric: "ピーク時QPS",
    currentValue: "5,000",
    targetValue: "50,000",
    priority: "P1",
    measurementMethod: "負荷テスト (k6)",
  },
  {
    category: "セキュリティ",
    metric: "脆弱性対応時間",
    currentValue: "72時間",
    targetValue: "< 24時間 (Critical)",
    priority: "P0",
    measurementMethod: "脆弱性スキャン + インシデント対応SLA",
  },
];

まとめ

チェックリスト

• SLA/SLO/SLIの違いを説明できる
• 可用性レベルとダウンタイムの対応を把握した
• p99レイテンシの重要性を理解した
• 非機能要件を定量化するマトリックスを作成できる

次のステップへ

次は「システム設計面接のフレームワーク」を学びます。限られた時間で効率的にシステムを設計するための構造化されたアプローチを身につけましょう。

推定読了時間: 25分