mcpField
S
scalability-playbook

scalability-playbook

github.com/patricio0312rev開発63344 回インストール41 週間前に更新
リポジトリ

scalability-playbook について

システムのスケーラビリティ上のボトルネックを特定し、解消するための段階的なガイドです。測定、拡張策、実行条件、負荷テスト、コスト計画を扱います。

主な機能

  1. 01ボトルネックの測定と影響評価
  2. 02工数順に並べた拡張策
  3. 03指標のしきい値と実行条件
  4. 04段階的なスケーリング計画
  5. 05負荷テストとコスト分析

活用シーン

  1. 01データベースクエリの遅延診断
  2. 02単一サーバーから水平拡張への計画
  3. 03システム指標に基づく拡張アラート設定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/patricio0312rev/skills --skill scalability-playbook

インストール後、Claude Code で/scalability-playbookを入力して読み込まれたか確認します。

詳細

スケーラビリティのプレイブック

スケーラビリティのボトルネックを特定し、解消するための体系的なアプローチです。

ボトルネックの分析

現在のシステムプロファイル
Traffic: 1,000 req/min
Users: 10,000 active
Data: 100GB database
Response time: p95 = 500ms
特定されたボトルネック
1. データベースクエリ

症状： ページの読み込みが遅い（2～3秒） 測定値： クエリ時間の p95 = 800ms 影響： 高 — すべての読み取りに影響します トリガー： p95 が 500ms を超えたとき

2. 単一サーバー

症状： CPU 使用率が高い（80% 超） 測定値： ロードアベレージ >4 影響： 中 — 時折、処理が遅くなります トリガー： CPU 使用率が 70% を超えたとき

3. キャッシュなし

症状： 同じ DB クエリの繰り返し 測定値： キャッシュヒット率 = 0% 影響： 中 — 不要な負荷が発生します トリガー： クエリ数が 10k/分を超えたとき

スケーリング戦略（順序付き）

レベル 1：すぐにできる改善（数日）
1.1 データベースインデックスの追加

問題： クエリが遅い 解決策：

CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_orders_user_created ON orders(user_id, created_at);

期待される効果： クエリが 80% 高速化 コスト： $0 作業期間： 1日

1.2 クエリキャッシュの有効化

問題： クエリが繰り返し実行される 解決策： Redis キャッシュ層

const cached = await redis.get(`user:${userId}`);
if (cached) return JSON.parse(cached);

const user = await db.users.findById(userId);
await redis.setex(`user:${userId}`, 3600, JSON.stringify(user));

期待される効果： DB 負荷を 60% 削減 コスト： $50/月 作業期間： 2日

レベル 2：水平スケーリング（数週間）
2.1 読み取りレプリカの追加

問題： 読み取り中心のワークロード 解決策： 読み取りをレプリカにルーティング

Write Load: Primary DB
Read Load: 3x Read Replicas

期待される効果： 読み取り容量が 3 倍 コスト： $300/月 作業期間： 1週間

2.2 ロードバランサーと複数のサーバー

問題： 単一障害点 解決策：

ALB
 ├── Server 1
 ├── Server 2
 └── Server 3

期待される効果： スループットが 3 倍 コスト： $400/月 作業期間： 1週間

レベル 3：アーキテクチャの変更（数か月）
3.1 静的アセット用 CDN

問題： アセットの配信が遅い 解決策： CloudFront CDN 期待される効果： アセットの読み込みが 90% 高速化 コスト： $100/月 作業期間： 1週間

3.2 非同期処理

問題： 同期処理が遅い 解決策： バックグラウンドジョブキュー

// Before: Sync
await sendEmail(user);
await processPayment(order);
await updateAnalytics(event);
return response; // Waits 5+ seconds

// After: Async
await queue.add("send-email", { userId });
await queue.add("process-payment", { orderId });
await queue.add("update-analytics", { event });
return response; // Returns immediately

期待される効果： 応答が 80% 高速化 コスト： $50/月（SQS） 作業期間： 2週間

レベル 4：データ層の最適化（数か月）
4.1 データベースシャーディング

問題： 単一の DB が大きすぎる 解決策： user_id でシャーディング

Shard 1: user_id 0-24999
Shard 2: user_id 25000-49999
Shard 3: user_id 50000-74999
Shard 4: user_id 75000-99999

期待される効果： 容量が 4 倍 コスト： $1,200/月 作業期間： 2か月

4.2 イベント駆動型アーキテクチャ

問題： 密結合、連鎖的な障害 解決策： メッセージブローカー（Kafka）

Service A → Kafka → Service B
          ↘        ↗ Service C

期待される効果： 分離性と回復力の向上 コスト： $500/月 作業期間： 3か月

スケーリングのトリガー

| Metric           | Current | Warning | Critical | Action                  |
| ---------------- | ------- | ------- | -------- | ----------------------- |
| CPU              | 40%     | 70%     | 85%      | Add servers             |
| Memory           | 50%     | 75%     | 90%      | Upgrade instances       |
| DB Connections   | 20      | 40      | 50       | Add read replicas       |
| Query Time (p95) | 200ms   | 500ms   | 1000ms   | Add indexes             |
| Queue Depth      | 100     | 1000    | 5000     | Add workers             |
| Error Rate       | 0.1%    | 1%      | 5%       | Investigate immediately |

段階的なスケーリング計画

フェーズ 1：現状から 10 倍へ（0～3か月）

目標： 10,000 req/min、ユーザー数 100K

実施項目：

  1. データベースインデックスを追加（第 1 週）
  2. Redis キャッシュを実装（第 2 週）
  3. 読み取りレプリカを 3 台追加（第 4 週）
  4. アプリケーションサーバーを水平スケーリング（第 6 週）
  5. 静的アセット用 CDN を導入（第 8 週）

コスト： $500 → $1,000/月

フェーズ 2：10 倍から 100 倍へ（3～12か月）

目標： 100,000 req/min、ユーザー数 1M

実施項目：

  1. データベースシャーディング（4～6か月目）
  2. マルチリージョン展開（6～8か月目）
  3. マイクロサービスの切り出し（8～12か月目）
  4. イベント駆動型アーキテクチャ（10～12か月目）

コスト： $1,000 → $10,000/月

フェーズ 3：100 倍から 1000 倍へ（12～24か月）

目標： 1M req/min、ユーザー数 10M

実施項目：

  1. グローバル CDN（13か月目）
  2. 高度なキャッシュ（L1/L2）（14～15か月目）
  3. カスタム DB ソリューション（16～18か月目）
  4. エッジコンピューティング（18～20か月目）

コスト： $10,000 → $100,000/月

負荷テスト計画

# Current baseline
hey -n 10000 -c 100 https://api.example.com/users

# Target 10x
hey -n 100000 -c 1000 https://api.example.com/users

# Measure:
# - Requests/sec
# - p50, p95, p99 latency
# - Error rate
# - Resource utilization

費用対効果分析

| Strategy      | Cost/Month | Expected Impact    | ROI | Priority |
| ------------- | ---------- | ------------------ | --- | -------- |
| DB Indexes    | $0         | 80% faster queries | ∞   | HIGH     |
| Redis Cache   | $50        | 60% less DB load   | 12x | HIGH     |
| Read Replicas | $300       | 3x capacity        | 10x | MEDIUM   |
| Load Balancer | $400       | 3x throughput      | 7x  | MEDIUM   |
| DB Sharding   | $1,200     | 4x capacity        | 3x  | LOW      |

ベストプラクティス

  1. まず測定する：やみくもに最適化しないでください
  2. 手軽にできる改善から始める：簡単にできることから取り組みます
  3. 負荷テストを行う：本番環境への導入前に検証します
  4. 継続的に監視する：アラートを設定します
  5. 先を見越して計画する：限界に達する前にスケーリングします
  6. コストを意識する：ROI に基づいて判断します
  7. 段階的に進める：小さく安全な変更を行います

出力チェックリスト

  • 現在のシステムプロファイル
  • ボトルネックの特定と測定
  • スケーリング戦略を労力の少ない順に整理
  • 各アクションの実行条件を定義
  • 段階的な計画（1x → 10x → 100x）
  • 各フェーズのコスト見積もり
  • 負荷テスト計画
  • 監視ダッシュボード
  • ロールバック手順

コメント

Markdown 対応