優先度A: 本番相当性能検証
機能が動くかではなく、体感性能（p50/p95/p99）と失敗率を確認するため。
- PostgreSQL相当の再負荷試験（mode/pool/concurrency行列）
- ラボ解析APIの内訳計測（parse/auth/validation/db_write/rust_exec等）
- service poolサイズ最適化（1,2,4,8の比較）
テスト手法と判断理由ガイド
このページは、実プロジェクトで再利用できる「テスト設計の考え方」を学ぶための教材です。個別の実測値ではなく、どう計画し、何を見て、どう判断するかを整理しています。
待機中
優先度別テスト手法
優先度B: 競合・安定性検証
高並列時のDB競合、ロック、再試行の有効性を確認するため。
- 保存API競合試験（同一file/別file/別project）
- ロックエラー件数とdb_write_p95の計測
- フォールバック設計の確認（service/subprocess）
優先度C: 運用性検証
実運用での継続稼働と回帰監視を可能にするため。
- 長時間連続実行時の劣化確認
- レスポンスサイズ別の分布確認
- 障害注入時の復旧可否と通知確認
テスト設計の進め方（学習フロー）
- 1. 目的を定義: 何を保証したいテストかを1文で固定
- 2. 計測項目を固定: success/error, throughput, p50/p95/p99, timeout
- 3. 条件を固定: DB種別, concurrency, iterations, call mode
- 4. ベースライン取得: 改修前を必ず保存
- 5. 改修後比較: 同条件で再測定し差分だけを見る
- 6. 判断を記録: 採用/保留/再設計を根拠付きで残す
主要メトリクスの意味
| 指標 | 読み方 |
|---|---|
| p50 | 通常時の中心的な体感速度 |
| p95 | 遅い側5%を含む現実的な体感 |
| p99 | 障害前兆を含むテイル遅延 |
| error_rate | 失敗率。まず0に近づける対象 |
| throughput | 単位時間あたりの処理量 |
| timeout_count | サービス劣化時の重要アラート指標 |
失敗しやすいアンチパターン
- 1回の計測で速い/遅いを断定する
- 平均値だけで結論を出してp95/p99を見ない
- 改修前のベースラインを残さない
- SQLite結果だけで本番DBの結論を出す
- 性能改善と障害率のトレードオフを記録しない
なぜこの手法が必要か
- 失敗率だけでなく p95/p99 を同時に確認しないと、体感劣化を見逃すため。
- Rust化は経路ごとに効果が異なるため、機能単位で比較が必要なため。
- SQLiteとPostgreSQLはロック特性が異なるため、本番判断にはDB別計測が必要なため。
- テストをドキュメント化しておくことで、次回改修時の回帰検知が早くなるため。
AWSコンソール課題（EC2 / VPC / IAM / 監視）
課題1: EC2 作成とヘルスチェック
到達目標: インスタンスを作成し、疎通と監視の最小セットを自力で確認する。
操作手順
- EC2でAmazon Linuxを1台起動し、Security GroupでSSH(22)のみ許可する。
- Elastic IPを割り当て、接続先IPを固定化する。
- CloudWatchでCPUUtilizationメトリクスを確認し、しきい値80%のアラームを追加する。
確認観点
- インスタンス状態チェックが2/2であること。
- SSH接続に成功し、`uname -a`が取得できること。
- CloudWatchアラームが作成済みで、評価期間が設定されていること。
課題2: VPC とサブネット設計
到達目標: 公開/非公開の分離を理解し、通信経路を説明できるようにする。
操作手順
- 新規VPCを作成し、Public SubnetとPrivate Subnetを1つずつ配置する。
- Public SubnetにInternet Gateway経由のデフォルトルートを設定する。
- Private SubnetはNAT Gateway経由で外向き通信できるルートに設定する。
確認観点
- Public Subnet内EC2へ外部からアクセスできること。
- Private Subnet内EC2は外向き通信のみ可能であること。
- ルートテーブルの関連付けを図で説明できること。
課題3: IAM 最小権限
到達目標: 管理者権限を避け、用途に応じた権限分離を実施する。
操作手順
- EC2閲覧専用ポリシーを持つIAMユーザーを作成する。
- S3読み取り専用ロールを作成し、必要なサービスにのみ付与する。
- MFA必須ポリシーを適用し、コンソールログインの保護を強化する。
確認観点
- 閲覧専用ユーザーでEC2停止ができないこと。
- S3読み取り以外の操作が拒否されること。
- MFA未設定時に制限が有効なこと。
課題4: ALB 配下の可用性検証
到達目標: 単一障害点を避ける構成を構築し、障害時の動きを確認する。
操作手順
- 2つのAZにEC2を配置し、ALBのターゲットグループへ登録する。
- ALBヘルスチェックパスを`/health`に設定する。
- 片系EC2を停止し、ALBが残存系へルーティングすることを確認する。
確認観点
- 停止後もALB経由のHTTP応答が継続すること。
- Unhealthy/Healthyの遷移がCloudWatchで確認できること。
- 復旧後にターゲットが再登録されること。
仮想コンソール演習（操作の流れ / 成功判定 / 改善解説）
下の演習を選び、次のコマンド実行を押すと疑似ログが流れます。完了後に「何が改善したか」を確認してください。