performance-efficiency

パフォーマンス効率の評価

ステップ 1：コンテキストの収集

ユーザーに次のように尋ねます。

パフォーマンス効率を評価するワークロードを教えてください。次の情報を共有してください。

• ワークロード名と、分析対象のコードパッケージ／ディレクトリ
• パフォーマンス要件（レイテンシーの目標、スループットのニーズ、同時ユーザー数）
• 既知のボトルネック（任意。パフォーマンスが低いと考えられる領域）

コンテキストがすでに提供されている場合、またはコードベース内にいる場合は、そのまま進めます。

ステップ 2：コンピューティングの選定状況の調査

コンピューティングリソースの選定と構成を分析します。

必ず確認する項目：

• EC2 インスタンスタイプとファミリー（汎用、コンピューティング最適化、メモリ最適化、ストレージ最適化）
• Lambda のメモリとタイムアウトの設定
• ECS/Fargate タスクの CPU とメモリの割り当て
• コンテナのベースイメージ（Alpine、distroless、フル OS）
• Graviton（ARM）と x86 のアーキテクチャ選定
• プロビジョニング済み同時実行の設定（Lambda）
• バッチ処理とリアルタイム処理の選定

各コンピューティングリソースについて、次の項目を記録します。

• ファイルパスと行番号
• インスタンスタイプ／サイズ、および適合するかどうかの理由
• ワークロードの種類に対するメモリ／CPU 比率
• コールドスタートへの影響（Lambda、Fargate）

必ず次の項目にフラグを立てます。

• デフォルトのメモリが 128MB の Lambda（メモリ不足の可能性が高く、実行が遅くなります）
• タイムアウトが呼び出し元のタイムアウト以上に設定された Lambda（呼び出し元には必ずタイムアウトとして表示されます）
• コンピューティング負荷またはメモリ負荷の高いワークロードに対する汎用インスタンス
• Graviton のほうが価格性能比に優れているのに x86 を使用しているケース
• シンプルなワークロードに対して CPU／メモリが過剰に大きい Fargate タスク

ステップ 3：ストレージとデータベースのパフォーマンスの調査

ストレージとデータベースのパフォーマンスに関する設定を分析します。

必ず確認する項目：

• データベースエンジンとアクセスパターンの適合性
• リードレプリカの設定
• コネクションプーリング（RDS Proxy、アプリケーションレベルのプーリング）
• DynamoDB テーブル設計（パーティションキーの分散、GSI の設定）
• キャッシュレイヤー（ElastiCache、DAX、CloudFront）
• S3 のアクセスパターンとリクエストレートに関する考慮事項
• EBS ボリュームの種類と IOPS のプロビジョニング
• アプリケーションコード内のデータベースクエリパターン（N+1 クエリ、インデックスの不足）

必ず次の項目にフラグを立てます。

• キーと値のアクセスパターンに対するリレーショナルデータベースの使用（DynamoDB のほうが適しています）
• サーバーレスから RDS に接続するアーキテクチャでコネクションプーリングがないこと
• ホットパーティションを招く DynamoDB のパターン（不適切なキー設計）
• 頻繁に読み取られ、変更頻度の低いデータにキャッシュレイヤーがないこと
• gp2 EBS ボリューム（gp3 はより低コストで優れたベースラインパフォーマンスを提供します）
• DynamoDB の読み取り負荷が高いパターンに対して DAX が不足していること
• N+1 クエリパターンや無制限のクエリを含むアプリケーションコード

ステップ 4：ネットワークとコンテンツ配信の調査

パフォーマンスに関するネットワーク設定を分析します。

必ず確認する項目：

• CloudFront ディストリビューション（または静的コンテンツ／API コンテンツに対して設定がないこと）
• API Gateway のキャッシュ設定
• VPC エンドポイントの使用状況（インターネット経由の経路と比べたレイテンシーの低減）
• レイテンシーに敏感なワークロード向けのプレイスメントグループ
• Global Accelerator の設定
• 接続設定（キープアライブ、HTTP/2、圧縮）
• DNS 解決（Route 53 のレイテンシーベースルーティング）

必ず次の項目にフラグを立てます。

• 静的コンテンツの配信に CDN がないこと
• 圧縮（gzip/brotli）されていない API レスポンス
• キャッシュ可能な GET エンドポイントに API Gateway のキャッシュがないこと
• ローカルエンドポイントを利用できるクロスリージョン呼び出し
• VPC エンドポイントが不足していること（NAT Gateway によるレイテンシーが発生します）

ステップ 5：スケーリングと弾力性の検出

スケーリング設定と応答性を分析します。

必ず確認する項目：

• Auto Scaling ポリシー（ターゲット追跡とステップスケーリングのどちらか）
• 使用するスケーリングメトリクス（CPU のみか、キューの深さやレイテンシなどのカスタムメトリクスも使用するか）
• クールダウン期間とスケーリング速度
• 予測可能なパターンに対するスケジュールされたスケーリング
• レイテンシの影響を受けやすい Lambda 関数に対するプロビジョンドコンカレンシー
• データベースの自動スケーリング（Aurora、DynamoDB）
• スケーリングのボトルネック（接続数の上限、DNS の伝播、コールドスタート）

必ず指摘する項目：

• CPU のみをスケーリングメトリクスに使用している（メモリ、キューの深さ、レイテンシが考慮されない）
• 迅速な応答を妨げる長いクールダウン期間
• レイテンシの影響を受けやすい Lambda 関数にプロビジョンドコンカレンシーが設定されていない
• 負荷パターンが変動するにもかかわらず、データベースの容量が固定されている
• 想定されるピークに対してスケーリングの最大値が低すぎる

ステップ 6：アプリケーションパフォーマンスパターンの検出

アプリケーションコードのパフォーマンスパターンを分析します。

必ず確認する項目：

• 同期処理と非同期処理のパターン
• バッチ処理の機会（一括書き込み、一括 API）
• ページネーションの実装（カーソル方式とオフセット方式）
• データのシリアル化形式（JSON とバイナリプロトコル）
• アプリケーションコードでのキャッシュの使用（ローカルキャッシュ、分散キャッシュ）
• ウォームアップと接続再利用のパターン（ハンドラーの外にある Lambda ハンドラー）
• 独立した処理の並列処理と逐次処理

必ず指摘する項目：

• 非同期処理（SQS、EventBridge）にできる同期処理
• 並列化できる逐次的な API 呼び出し
• 大規模なデータセットに対するオフセット方式のページネーション（カーソル方式は O(1)）
• Lambda のコールドスタートにつながるパターン（モジュールスコープではなくハンドラー内で初期化している）
• バッチ処理の欠如（個別の PutItem を使用し、BatchWriteItem を使用していない）
• ページネーションを行わない、上限のないデータ取得

ステップ 7：モニタリングと最適化の実践

パフォーマンスのモニタリング設定を分析します。

必ず確認する項目：

• CloudWatch のメトリクスとアラーム（レイテンシのパーセンタイル、エラー）
• X-Ray/OpenTelemetry のトレース設定
• パフォーマンスが重要な処理に対するカスタムメトリクス
• パフォーマンス予算とアラート
• レイテンシ／スループットを追跡するダッシュボード定義

必ず指摘する項目：

• p95/p99 レベルのレイテンシモニタリングがない
• サービス境界をまたぐ分散トレースがない
• パフォーマンスアラームがない（エラーアラームのみ）
• 平均値のみのメトリクス（テールレイテンシの問題が隠れる）

---STOP--- チェックポイント：検出完了 — WA フレームワークに照らした評価の準備が整いました

コンピューティングの選択（{X} 個のリソース）、ストレージ／データベース設定、ネットワークパターン、スケーリングポリシー、アプリケーションパフォーマンスパターン、{packages analyzed} 全体のモニタリング設定を検出しました。

これらの検出結果を WA Performance Efficiency ピラーの質問に照らして評価し、リスクレベルを判定してもよろしいですか？

ユーザーが明示的に確認するまで、この時点より先に進んではいけません。

ステップ 8：WA フレームワークの質問に照らして評価する

各質問について、ステータス、根拠（ファイル：行）、ギャップ、リスクを提示します。

PERF 1 — 適切なクラウドリソースをどのように選択していますか？

• 根拠：インスタンスタイプ、コンピューティングファミリー、ストレージ階層、選定理由

PERF 2 — コンピューティングソリューションをどのように選択していますか？

• 根拠：Lambda、ECS、EC2 の選択、メモリ／CPU 設定、コールドスタートへの対処

PERF 3 — ストレージソリューションをどのように選択していますか？

• 根拠：アクセスパターンに合ったストレージタイプ、IOPS 設定、階層化

PERF 4 — データベースソリューションをどのように選択していますか？

• 根拠：エンジンの選択、リードレプリカ、接続プーリング、キャッシュレイヤー

PERF 5 — ネットワーキングソリューションをどのように設定していますか？

• 根拠：CloudFront、VPC エンドポイント、プレイスメントグループ、圧縮

PERF 6 — 新しいリリースを活用するために、ワークロードをどのように進化させていますか？

• 根拠：ランタイムのバージョン、SDK のバージョン、Graviton の採用、最新機能

PERF 7 — リソースが適切に動作していることを確認するため、どのようにモニタリングしていますか？

• 根拠：パーセンタイル別のレイテンシメトリクス、スループットの追跡、パフォーマンスアラーム

PERF 8 — パフォーマンスを向上させるために、トレードオフをどのように活用していますか？

• 根拠：キャッシュ戦略、非同期パターン、結果整合性の選択

Step 9: リスク評価

各指摘事項について、影響度 × 発生可能性で評価します。

影響度：軽微（わずかに最適でないが、ユーザーから見える影響はない） | 中程度（負荷時に遅延が目立ち、エクスペリエンスが低下する） | 深刻（ユーザー向けのタイムアウト、リクエストの消失、SLA 違反）

発生可能性：低（エッジケースまたは極端な負荷の場合のみ発生する） | 中（通常のピーク負荷時に発生する） | 高（定常時のトラフィックで発生する）

影響度	発生可能性	リスクレベル
深刻	高	重大
深刻	中	高
深刻	低	高
中程度	高	高
中程度	中	中程度
中程度	低	中程度
軽微	高	中程度
軽微	中	低
軽微	低	低

---STOP--- チェックポイント：リスク評価が完了しました。最終レポートを作成する準備ができています。

コンピューティングの選定、ストレージ／データベース、ネットワーク、スケーリング、アプリケーションパターン、モニタリングにわたって、{N} 件の指摘事項を評価しました。リスクの内訳：重大 {X} 件、高 {Y} 件、中 {Z} 件、低 {W} 件。主なパフォーマンスのボトルネックを特定し、改善の見込みを算出しました。

優先順位を付けた修正計画を含む、パフォーマンス効率の完全な評価を作成しますか？

ユーザーが明示的に確認するまで、この時点より先に進んではいけません。

Step 10: 指摘事項を作成する

# Performance Efficiency Assessment: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Packages Analyzed**: {list}
- **Performance Target**: {latency/throughput targets if specified}
- **Findings**: {X} Critical, {Y} High, {Z} Medium, {W} Low
- **Overall Performance Maturity**: {1-5} — {one-line justification}

## Performance Scorecard
| Domain | Score (1-5) | Key Strength | Key Gap |
|--------|-------------|--------------|---------|
| Compute Selection | {score} | {strength} | {gap} |
| Storage & Database | {score} | {strength} | {gap} |
| Networking & CDN | {score} | {strength} | {gap} |
| Scaling & Elasticity | {score} | {strength} | {gap} |
| Application Patterns | {score} | {strength} | {gap} |
| Monitoring | {score} | {strength} | {gap} |

## Critical and High Risk Findings
{For each: ID, domain, title, description, evidence (file:line), performance impact, recommendation, expected improvement, effort, AWS services}

## Medium Risk Findings
{Same format, condensed}

## Low Risk Findings
{Summary table: ID | Domain | Title | Recommendation}

## Optimization Opportunities
| Resource | Current Config | Recommended | Expected Improvement | Evidence |
|----------|---------------|-------------|---------------------|----------|
| {resource} | {current} | {optimized} | {improvement} | {file:line} |

## Prioritized Remediation Plan

### Quick Wins (< 1 week)
| Finding | Action | Performance Impact | Effort |
|---------|--------|-------------------|--------|
{Increase Lambda memory, enable compression, add gp3, enable keep-alive}

### Foundation (1-4 weeks)
| Finding | Action | Performance Impact | Effort | Dependencies |
|---------|--------|-------------------|--------|--------------|
{Add caching layer, implement connection pooling, CDN, async patterns}

### Strategic (1-3 months)
| Finding | Action | Performance Impact | Effort | Dependencies |
|---------|--------|-------------------|--------|--------------|
{Database migration, architecture rework, global distribution, Graviton migration}

## Next Steps
{Top 5 concrete performance actions the team should take this week}

Step 11: フォローアップを提案する

評価を提示した後、次の内容を提案します。

次のことを希望されますか？

• 特定のデータフロー向けのキャッシュ戦略を設計する
• パワーチューニングのアプローチで、Lambda のメモリ／タイムアウト設定を最適化する
• サーバーレスから RDS への接続プーリングを実装する
• 目標シナリオを含む負荷テスト計画を作成する
• 同期コードパスをキューを使った非同期処理にリファクタリングする
• API／静的コンテンツ向けの CloudFront ディストリビューションを実装する

評価のガイダンス

• 適切なインスタンスタイプ、キャッシュ、CDN、自動スケーリング、レイテンシモニタリングを備えたワークロードは成熟しています。テールレイテンシ、高度なキャッシュ、アーキテクチャの最適化に重点を置いてください。
• すべての指摘事項には、必ずコード上の根拠が必要です。既存のキャッシュ層を確認せずに「キャッシュがない」と指摘してはいけません。
• パフォーマンスに関する指摘では、改善の見込みを推定してください（例：「接続プーリングを追加すると、通常 p99 レイテンシが 30～50％低下します」）。
• トレードオフを必ず評価してください。パフォーマンス最適化によって、コストや複雑さが増す場合があります。
• 実際のパフォーマンスデータが必要な場合は、「判断できません」が妥当です（例：インスタンスが CPU バウンドかどうかの判断には、CloudWatch メトリクスが必要です）。
• 問題点を列挙する前に、優れたパフォーマンスの実践例を認めてください。