佐藤CTOからの指令：「新しいECサイトのリリースが3週間後に迫っている。負荷テストの計画から容量見積もり、CI/CDへの組み込みまで、パフォーマンスエンジニアリングの全工程を設計してほしい。」
| # | ミッション | 難易度 | 目安時間 |
|---|---|---|---|
| 1 | 負荷テストシナリオ設計 | ★★☆ | 15分 |
| 2 | キャパシティプランニング | ★★★ | 15分 |
| 3 | オートスケーリング設計 | ★★☆ | 15分 |
| 4 | パフォーマンスCI/CD設計 | ★★★ | 15分 |
Mission 1: 負荷テストシナリオ設計
以下のシステムに対して、k6の負荷テストシナリオを設計せよ。
システム: ECサイト
想定ユーザー: 月間100万MAU
ピーク: セール時に通常の5倍
主要フロー:
- 商品閲覧 (60%)
- 検索 (20%)
- カート操作 (12%)
- 決済 (8%)
SLA: p95 < 500ms, エラー率 < 0.1%解答例
export const options = {
scenarios: {
browsing: {
executor: 'ramping-vus',
stages: [
{ duration: '3m', target: 180 },
{ duration: '10m', target: 180 },
{ duration: '2m', target: 0 },
],
exec: 'browsingFlow',
},
searching: {
executor: 'ramping-vus',
stages: [
{ duration: '3m', target: 60 },
{ duration: '10m', target: 60 },
{ duration: '2m', target: 0 },
],
exec: 'searchFlow',
},
cart: {
executor: 'ramping-vus',
stages: [
{ duration: '3m', target: 36 },
{ duration: '10m', target: 36 },
{ duration: '2m', target: 0 },
],
exec: 'cartFlow',
},
checkout: {
executor: 'ramping-vus',
stages: [
{ duration: '3m', target: 24 },
{ duration: '10m', target: 24 },
{ duration: '2m', target: 0 },
],
exec: 'checkoutFlow',
},
spike: {
executor: 'ramping-arrival-rate',
startRate: 0,
timeUnit: '1s',
preAllocatedVUs: 1000,
maxVUs: 2000,
stages: [
{ duration: '5m', target: 100 },
{ duration: '1m', target: 500 },
{ duration: '5m', target: 100 },
],
exec: 'browsingFlow',
startTime: '16m',
},
},
thresholds: {
'http_req_duration{scenario:browsing}': ['p(95)<500'],
'http_req_duration{scenario:searching}': ['p(95)<500'],
'http_req_duration{scenario:checkout}': ['p(95)<800'],
http_req_failed: ['rate<0.001'],
},
};Mission 2: キャパシティプランニング
以下のデータを基に、6ヶ月先までの容量計画を策定せよ。
現在の指標:
- 平均 RPS: 2,000
- ピーク RPS: 5,000
- 月間成長率: 20%
- 現在のインフラ上限: 8,000 RPS
- インスタンス: c5.xlarge × 10台
- 1台あたり処理能力: 800 RPS
- DB: RDS r6g.2xlarge（max_connections=500）設計すべき項目: スケーリングが必要になるタイミング、具体的なアクション計画
解答例
Month 1: 平均2400, ピーク6000 → 8000でカバー可（余裕25%）
Month 2: 平均2880, ピーク7200 → 8000でカバー可（余裕10%）→ 準備開始
Month 3: 平均3456, ピーク8640 → 8000超過！→ スケールアウト必要
Month 4: 平均4147, ピーク10368 → 13台必要
Month 5: 平均4977, ピーク12442 → 16台必要
Month 6: 平均5972, ピーク14930 → 19台必要
アクション計画:
- Month 1: リードレプリカ追加、コネクションプーリング導入
- Month 2: オートスケーリング設定（max=20）、負荷テスト実施
- Month 3: スケールアウト実行（10→15台）
- Month 4: DB を r6g.4xlarge にスケールアップ
- Month 6: アーキテクチャレビュー（キャッシュ層追加検討）Mission 3: オートスケーリング設計
以下の要件に対してオートスケーリングポリシーを設計せよ。
要件:
- 平日昼間のピーク（11-14時）と夕方ピーク（19-22時）がある
- 月初にセールイベントがあり通常の3倍のトラフィック
- アプリケーション起動に約90秒かかる
- コスト最適化も重視（深夜帯は最小構成）解答例
const policy = {
minInstances: 3,
maxInstances: 30,
metrics: [
{ name: 'CPUUtilization', scaleOut: 65, scaleIn: 25, period: 60, datapoints: 3 },
{ name: 'TargetResponseTime', scaleOut: 400, scaleIn: 100, period: 60, datapoints: 2 },
],
cooldown: { scaleOut: 120, scaleIn: 300, warmup: 120 },
scheduledActions: [
{ name: 'morning_scaleup', cron: '0 10 * * MON-FRI', min: 8 },
{ name: 'evening_scaleup', cron: '0 18 * * *', min: 10 },
{ name: 'night_scaledown', cron: '0 23 * * *', min: 3 },
{ name: 'sale_prep', cron: '0 8 1 * *', min: 25 },
{ name: 'sale_end', cron: '0 0 2 * *', min: 3 },
],
};
// ポイント: warmup=120秒 > 起動90秒（バッファ含む）
// スケールインはスケールアウトより慎重に（300秒クールダウン）Mission 4: パフォーマンスCI/CD設計
開発チーム（10名）のCI/CDパイプラインにパフォーマンスチェックを組み込む設計をせよ。
制約:
- GitHub Actions を使用
- PRごとの実行時間は10分以内
- 本番相当の負荷テストは夜間バッチで実施
- バンドルサイズとLighthouseスコアもチェック
解答例
■ PRパイプライン（10分以内）
1. ビルド＆ユニットテスト (3分)
2. Lighthouse CI - 主要3ページ (2分)
3. Bundle Size Check - size-limit (1分)
4. k6 Smoke Test - 10VU × 1分 (2分)
5. 結果をPRコメントに投稿 (1分)
→ 合計 9分
■ main マージ後パイプライン
1. ステージング環境にデプロイ
2. k6 Load Test - 100VU × 10分
3. 結果をSlack通知
■ 夜間バッチ（毎日 AM 2:00）
1. k6 Full Load Test - 300VU × 30分
2. Soak Test - 50VU × 2時間
3. 結果をダッシュボード更新
4. 前日比10%以上劣化でアラート
■ パフォーマンスバジェット
- p95 < 500ms
- バンドルサイズ < 300KB (gzip)
- Lighthouse Performance > 90
- エラー率 < 0.1%