メインコンテンツまでスキップ

パフォーマンス要件

Bazbiiシステムのパフォーマンス目標とベンチマークを説明します。

パフォーマンス要件の概要​

パフォーマンス目標​

システム全体で以下のパフォーマンス目標を設定：

  • レスポンスタイム: P95で200ms以下
  • スループット: 1000 req/s以上
  • 可用性: 99.9%以上（月間43分以下のダウンタイム）

APIレスポンスタイム目標​

目標値​

APIP50P95P99
POST /v1/posts50ms200ms500ms
GET /v1/timeline100ms300ms500ms
GET /v1/heatmap150ms400ms800ms
POST /v1/auth/provision100ms300ms500ms

測定方法​

  • メトリクス: Grafana Cloud Prometheus互換エンドポイントで計測
  • ダッシュボード: Grafana Cloudで可視化
  • アラート: P95が目標値を超過した場合にアラート

スループット目標​

目標値​

  • Gateway: 1000 req/s
  • API Server: 500 req/s（gRPC）
  • データベース: 1000 qps

負荷テスト​

# 負荷テストツール（例: k6）
k6 run load-test.js

# 負荷テストシナリオ
# - レートリミッターを考慮
# - 段階的な負荷増加
# - ピーク時の負荷をシミュレート

リソース使用率​

CPU使用率​

  • 目標: 平均70%以下
  • アラート閾値: 平均80%以上、またはピーク90%以上

メモリ使用率​

  • 目標: 平均70%以下
  • アラート閾値: 平均80%以上

データベース接続数​

  • 目標: 接続プールサイズの70%以下
  • アラート閾値: 接続プールサイズの80%以上

パフォーマンス最適化​

1. データベースクエリ最適化​

インデックス戦略​

-- スコア順取得用インデックス
CREATE INDEX idx_posts_score ON posts(score DESC, id DESC);

-- H3インデックスによる地理空間検索
-- （PostGISまたはH3インデックスを使用）

クエリ最適化​

  • N+1問題の回避: JOINやバッチクエリの使用
  • ページネーション: LIMIT/OFFSETの適切な使用
  • クエリキャッシュ: 頻繁にアクセスされるデータのキャッシュ

2. アプリケーション層の最適化​

並行処理​

// goroutineを使用した並行処理
var wg sync.WaitGroup
for _, item := range items {
    wg.Add(1)
    go func(item Item) {
        defer wg.Done()
        process(item)
    }(item)
}
wg.Wait()

キャッシング​

  • Redis: 頻繁にアクセスされるデータのキャッシュ（将来実装予定）
  • アプリケーションキャッシュ: メモリ内キャッシュ

3. ネットワーク最適化​

gRPCの使用​

  • 内部通信はgRPCで効率的な通信
  • プロトコルバッファによるシリアライゼーション

CDNの活用​

  • Cloudflare CDNによる静的コンテンツの配信
  • エッジキャッシング

ベンチマークテスト​

ベンチマーク環境​

  • 環境: ステージング環境
  • データ量: 本番環境と同等（または縮小版）
  • 負荷: 段階的な負荷増加

ベンチマーク項目​

  1. レイテンシ: レスポンスタイム
  2. スループット: 秒間リクエスト数
  3. リソース使用率: CPU、メモリ、I/O
  4. スケーラビリティ: 水平スケーリング時の性能

ベンチマークツール​

  • k6: HTTP負荷テスト
  • Apache Bench (ab): 簡単な負荷テスト
  • PostgreSQLベンチマーク: pgbench

ベンチマーク実行例​

# k6での負荷テスト
k6 run --vus 100 --duration 30s load-test.js

# 結果の確認
# - レスポンスタイム（P50, P95, P99）
# - スループット
# - エラー率

パフォーマンス監視​

メトリクス収集​

  • Grafana Cloud Prometheus: メトリクス収集（Prometheus互換エンドポイント）
  • Grafana Cloud: 可視化

監視項目​

  • リクエストレイテンシ: ヒストグラム
  • エラー率: カウンター
  • スループット: レート
  • リソース使用率: ゲージ

アラート設定​

  • レスポンスタイム: P95が目標値の1.5倍を超過
  • エラー率: エラー率が1%を超過
  • リソース使用率: CPU/メモリが80%を超過

パフォーマンステスト​

単体パフォーマンステスト​

// Goのベンチマークテスト
func BenchmarkPostService_CreatePost(b *testing.B) {
    service := setupTestService()
    input := createTestInput()
    
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        service.CreatePost(ctx, input)
    }
}

統合パフォーマンステスト​

  • APIのエンドツーエンドテスト: 実際のリクエストフロー
  • データベースクエリのテスト: クエリの実行時間

負荷テスト​

  • 段階的負荷増加: 低負荷から高負荷へ
  • ピーク負荷テスト: 予想される最大負荷
  • 耐久テスト: 長時間の負荷テスト

スケーリング戦略​

水平スケーリング​

  • Gateway: トラフィックに応じてレプリカ数を増減
  • API Server: リクエスト数に応じてレプリカ数を増減

垂直スケーリング​

  • データベース: CPU/メモリの増強
  • アプリケーション: リソース制限の調整

オートスケーリング（将来実装予定）​

# Kubernetes HPA設定例
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: gateway-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: gateway
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

パフォーマンス改善の継続​

定期的なレビュー​

  • 週次: メトリクスのレビュー
  • 月次: パフォーマンストレンドの分析
  • 四半期: ベンチマークテストの実行

改善活動​

  • ボトルネックの特定: プロファイリング
  • 最適化の実施: クエリ最適化、アルゴリズム改善
  • 再測定: 改善後のベンチマーク

ベストプラクティス​

1. 早期のパフォーマンステスト​

  • 開発の早い段階でパフォーマンステスト
  • CI/CDパイプラインに含める（将来）

2. 実測データに基づく判断​

  • 推測ではなく実測データで判断
  • プロファイリングツールの活用

3. 段階的な最適化​

  • ボトルネックから順に最適化
  • 過度な最適化は避ける

関連ドキュメント​