# 性能・拡張性（Performance & Scalability）

## 性能・拡張性の基本方針

システムが要求されるサービスレベルを安定して提供し、将来的なビジネス成長やユーザー数の増加に柔軟に対応するためのインフラ・ミドルウェア戦略を以下に示す。

### 性能最適化方針
- **インフラ・ミドルウェアの継続的な監視と分析**: ボトルネックを早期に特定し、リソース配分や設定の最適化を実施
- **キャッシュミドルウェアの積極的な活用**: 頻繁にアクセスされるデータやAPI応答をキャッシュし、DB/APIサーバー負荷を軽減
- **DB設定の最適化とチューニング**: インデックス設計、パラメーター調整を徹底し、DBアクセス性能を最大化
- **ネットワーク経路の最適化**: 低遅延・高帯域のネットワーク構成を採用し、通信性能を確保

### 拡張性確保方針
- **水平スケーリングを前提としたインフラアーキテクチャ**: 共有ディスクレス構成とし、サーバー台数の増減に柔軟に対応
- **クラウドネイティブなサービス活用**: オートスケーリング、マネージドデータベース、メッセージキューなどのサービスを積極的に利用
- **容量計画（キャパシティプランニング）**: 定期的な負荷テストと将来予測に基づき、インフラリソース計画を策定

### 運用効率化方針
- **性能監視の自動化**: 主要なインフラ・ミドルウェアの性能指標をリアルタイムで監視し、異常を早期検知
- **リソース自動調整**: オートスケーリングポリシーに基づき、負荷に応じてサーバーリソースを自動増減
- **パフォーマンスレポート**: 定期的にインフラ・ミドルウェアの性能レポートを作成し、リソース最適化や設定改善に繋げる

---

## 5.3.2 性能・拡張性要件の実現方式

### B1. 業務処理量 (Business Processing Volume)

#### B1.1 通常時の業務量 (Normal Business Volume)

##### B1.1.1 ユーザー数
- **要件**: 通常時アクティブユーザー数 5,000人
- **実現方式・仕様**:
  - 認証基盤（IDaaS）は、5,000アクティブユーザーを安定処理可能なプランを選定
  - ロードバランサーの最大同時接続数は、ユーザー数 x 平均セッション数（例: 5,000 x 5 = 25,000）を許容する設定

##### B1.1.2 同時アクセス数
- **要件**: ピーク時同時セッション数 25,000
- **実現方式・仕様**:
  - ロードバランサーの最大同時接続数は25,000以上を確保
  - APサーバーのコネクションプール設定は、各インスタンスあたり200コネクションとし、合計で25,000セッションを処理可能な台数を確保

##### B1.1.3 データ量
- **要件**: データベースデータ総量 1TB、ファイルストレージ容量 5TB
- **実現方式・仕様**:
  - データベースは、1TBのデータ量を格納可能なインスタンスタイプ（例: AWS RDS db.r6g.large）を選定
  - ファイルストレージは、オブジェクトストレージ（例: Amazon S3）を利用し、5TBのデータ保存を前提とした構成

##### B1.1.4 オンラインリクエスト件数
- **要件**: ピーク時 500 TPS (Transactions Per Second)
- **実現方式・仕様**:
  - Webサーバー、APサーバーは、500 TPSを処理可能な台数（例: 各3台）を配置
  - ロードバランサーは、500 TPSのリクエストを均等に分散する設定

##### B1.1.5 バッチ処理件数
- **要件**: 日次バッチ処理レコード数 100万件
- **実現方式・仕様**:
  - バッチ処理専用のVMインスタンス（例: CPU 8vCPU, メモリ 32GB）を確保
  - データベースのバッチ処理用インデックスを最適化し、高速なデータアクセスを可能にする

#### B1.2 業務量増大度 (Business Volume Growth Rate)

##### B1.2.1 ユーザー数増大率
- **要件**: サービス開始後3年間で、ユーザー数が現在の5倍（25,000人）に増加
- **実現方式・仕様**:
  - 認証基盤は、将来的なユーザー数増加に対応可能な上位プランへの変更を想定
  - オートスケーリンググループの最大インスタンス数を、25,000ユーザーに対応可能な台数に設定

##### B1.2.2 同時アクセス数増大率
- **要件**: サービス開始後3年間で、ピーク時同時アクセス数が現在の5倍（125,000セッション）に増加
- **実現方式・仕様**:
  - ロードバランサーは、125,000セッション以上を処理可能なマネージドサービス（例: AWS ALB）を利用
  - APサーバーのオートスケーリングポリシーは、CPU使用率70%を閾値としてインスタンスを自動追加する設定

##### B1.2.3 データ量増大率
- **要件**: 年間データ増加率 50%（3年後には約3.4倍）
- **実現方式・仕様**:
  - データベースは、シャーディングまたはパーティショニング戦略を導入し、データ量増加に対応可能なアーキテクチャとする
  - オブジェクトストレージは、容量無制限の特性を活かし、非構造化データの増加に対応

##### B1.2.4 オンラインリクエスト件数増大率
- **要件**: サービス開始後3年間で、ピーク時オンラインリクエスト件数が現在の5倍（2,500 TPS）に増加
- **実現方式・仕様**:
  - Web/APサーバーのオートスケーリンググループの最大インスタンス数を、2,500 TPSに対応可能な台数に設定
  - データベースは、リードレプリカの追加や、上位インスタンスタイプへの変更を容易に行える構成とする

##### B1.2.5 バッチ処理件数増大率
- **要件**: サービス開始後3年間で、日次バッチ処理レコード数が現在の3倍（300万件）に増加
- **実現方式・仕様**:
  - 分散バッチ処理フレームワーク（例: Apache Sparkクラスタ）を導入し、リソースの柔軟な拡張性を確保
  - バッチ処理用データベースのパーティショニング戦略を強化し、大規模データ処理に対応

#### B1.3 保管期間 (Storage Period)

##### B1.3.1 保管期間
- **要件**: OS/ミドルウェアのログは3ヶ月間オンラインで参照可能、3年間アーカイブ保存
- **実現方式・仕様**:
  - ログ管理基盤（例: ELKスタック）のストレージポリシーを設定し、3ヶ月間は高速アクセス可能なストレージに保存
  - 3ヶ月経過したログは、自動的に低コストのアーカイブストレージ（例: Amazon S3 Glacier）へ移行する設定

### B2. 性能目標値 (Performance Target Values)

#### B2.1 オンラインレスポンス (Online Response)

##### B2.1.1 通常時レスポンス順守率
- **要件**: 主要APIの95%タイル応答時間 200ms以内
- **実現方式・仕様**:
  - CDNのキャッシュヒット率を90%以上とする設定
  - インメモリキャッシュ（Redis）のヒット率を80%以上とする設定
  - データベースのクエリキャッシュを有効化し、適切なサイズを設定

##### B2.1.2 ピーク時レスポンス順守率
- **要件**: ピーク時の主要APIの95%タイル応答時間 500ms以内
- **実現方式・仕様**:
  - オートスケーリングによりAPサーバーインスタンスが自動的に追加され、リソース不足による遅延を防止
  - ロードバランサーのヘルスチェック間隔を短く設定し、異常ノードへのリクエストを迅速に停止

#### B2.2 バッチレスポンス（ターンアラウンドタイム） (Batch Response (Turnaround Time))

##### B2.2.1 通常時レスポンス順守度合い
- **要件**: 日次バッチ処理は午前3時までに完了
- **実現方式・仕様**:
  - バッチ処理専用のVMインスタンスは、午前1時から午前3時まで最大リソースを確保する設定
  - データベースのパーティショニングにより、日次バッチ処理の対象データ範囲を限定し、I/O負荷を軽減

##### B2.2.2 ピーク時レスポンス順守度合い
- **要件**: 月次バッチ処理は毎月1日の午前6時までに完了
- **実現方式・仕様**:
  - 月次バッチ処理実行時のみ、分散バッチ処理クラスタのノード数を一時的に増強する設定
  - データベースのメンテナンスウィンドウを月次バッチ処理に影響しない時間帯に設定

### B3. リソース拡張性 (Resource Scalability)

#### B3.1 CPU拡張性 (CPU Scalability)

##### B3.1.1 CPU利用率
- **要件**: 通常時CPU利用率 50%未満、ピーク時CPU利用率 80%未満
- **実現方式・仕様**:
  - Web/APサーバーのオートスケーリングポリシーは、CPU利用率70%を閾値としてインスタンスを追加する設定
  - データベースインスタンスは、CPUクレジット（バースト可能）ではなく、常にベースライン性能を保証するタイプを選定

##### B3.1.2 CPU拡張性
- **要件**: 物理/仮想的なCPUの拡張上限は、想定最大負荷の1.5倍まで対応可能
- **実現方式・仕様**:
  - クラウドプロバイダーの提供するインスタンスタイプの上限、およびリージョンごとのクォータを確認し、将来的な拡張性を確保
  - Kubernetesクラスタのノードグループは、最大ノード数を設定し、CPUリソースの拡張上限を定義

#### B3.2 メモリ拡張性 (Memory Scalability)

##### B3.2.1 メモリ利用率
- **要件**: 通常時メモリ利用率 60%未満、ピーク時メモリ利用率 90%未満
- **実現方式・仕様**:
  - Web/APサーバーのオートスケーリングポリシーは、メモリ利用率85%を閾値としてインスタンスを追加する設定
  - キャッシュミドルウェア（Redis）の最大メモリ設定は、ピーク時データ量の120%を確保

##### B3.2.2 メモリ拡張性
- **要件**: 物理/仮想的なメモリの拡張上限は、想定最大負荷の1.5倍まで対応可能
- **実現方式・仕様**:
  - クラウドプロバイダーの提供するインスタンスタイプの上限、およびリージョンごとのクォータを確認し、将来的な拡張性を確保
  - Kubernetesクラスタのノードグループは、最大ノード数を設定し、メモリリソースの拡張上限を定義

---

## テスト計画（性能・拡張性関連）

### 負荷テスト（Load Test）
- **実施時期**: 各インフラ環境構築後、および本番リリース前
- **テスト項目**:
  - 想定されるピーク負荷（同時アクセス数、TPS）におけるインフラ・ミドルウェアの応答時間、エラー率
  - データベースのCPU使用率、I/O性能、コネクション数
  - Webサーバー、APサーバーのCPU使用率、メモリ使用率、スレッド数
- **合格基準**:
  - インフラ・ミドルウェアの応答時間が要件値以内であること
  - インフラ・ミドルウェア起因のエラー率が0.1%未満であること
  - 各サーバーリソース使用率が80%を超えないこと

### ストレステスト（Stress Test）
- **実施時期**: 本番リリース前、および大規模なインフラ構成変更時
- **テスト内容**:
  - 想定ピーク負荷の1.5倍～2倍の負荷をかけ、インフラ・ミドルウェアが限界に達するポイントを特定
  - リソース枯渇時のインフラ・ミドルウェアの挙動（応答時間悪化、エラー発生、システムダウン）を確認
- **目的**: インフラ・ミドルウェアの限界性能と、限界を超えた際の挙動を把握し、適切な対策を講じる

### スケーラビリティテスト（Scalability Test）
- **実施時期**: 年に1回、または大規模なインフラアーキテクチャ変更時
- **テスト内容**:
  - サーバー台数を増減させた際の性能変化（リソース追加による性能向上率）を確認
  - オートスケーリングが適切に動作し、負荷に応じてリソースが自動調整されることを検証
- **目的**: 将来の負荷増加に対するインフラの拡張能力を評価し、キャパシティプランニングに役立てる

### 耐久テスト（Endurance Test）
- **実施時期**: 本番リリース前
- **テスト内容**:
  - 想定される通常負荷を長時間（24時間以上）かけ続け、インフラ・ミドルウェアの安定稼働を確認
  - メモリリーク、コネクションリーク、ディスクI/Oの継続的な増加など、長期稼働による性能劣化がないかを確認
- **目的**: 長期的な運用におけるインフラの安定性と性能維持能力を評価

---

## リスクと対策

| No | リスク | 影響 | 発生確率 | 対策 |
|----|--------|------|---------|------|
| 1 | インフラ・ミドルウェアのボトルネックの見落とし | 特定機能の応答時間悪化、システム全体の性能低下 | 中 | 開発初期からの性能テスト環境整備、継続的なインフラ・ミドルウェアの監視と分析 |
| 2 | 将来の負荷予測の誤り | リソース不足によるサービス停止、過剰なリソース確保によるコスト増大 | 中 | 定期的なキャパシティプランニング、柔軟なオートスケーリング設定、トレンド分析 |
| 3 | スケーリングコストの増大 | 運用コストの予算超過 | 中 | コスト監視ツールの導入、リソースの最適化（インスタンスタイプ見直し、予約インスタンス活用） |
| 4 | インフラ・ミドルウェアチューニングによる副作用 | 他機能への性能影響、予期せぬ不具合発生 | 低 | 変更管理プロセスの厳格化、性能テスト環境での十分な検証、ロールバック計画の策定 |
| 5 | データベースの拡張限界 | データ量増加によるDB性能劣化、スケールアウトの困難さ | 中 | DBシャーディング/パーティショニングの早期検討、データアーカイブ戦略の策定 |

---