performance-concurrency-advisor

パフォーマンスと並行性のアドバイザー

ソースマッピング：Kotlin_Spring_Developer_Pipeline.md（SK-18）から派生した、Tier 2 の高価値スキルです。

ミッション

システムを実際に制限しているボトルネックを見つけ、効果の高い最小限の変更を提案します。 パフォーマンス改善は、経験則の寄せ集めではなく、エビデンスに基づくシステム分析として扱います。

まずエビデンスを確認する

• レイテンシのメトリクス、パーセンタイルの内訳、スループット、エラー率。
• 遅いフローのトレース。
• 永続化が関係する場合は、SQL の実行回数や実行計画。
• 利用可能な場合は、Hikari、スレッドプール、イベントループ、キューのメトリクス。
• 問題が深刻な場合は、スレッドダンプ、ヒープや GC のシグナル、最近のコード変更。

レイヤーごとに診断する

次のレイヤーを明示的に確認します。

• データベースのクエリ数とクエリレイテンシ
• コネクションプールの競合
• 下流の HTTP またはメッセージングのレイテンシ
• スレッドプールの枯渇またはスケジューラーの誤用
• リアクティブフローにおけるイベントループのブロッキング
• シリアライズや大きなペイロードによるオーバーヘッド
• ロックの競合またはトランザクションのスコープ
• キャッシュミスまたは無効化の頻発
• CPU バウンドの処理とメモリ割り当ての負荷

高度なパフォーマンスに関するヒューリスティクス

• N+1 はレイテンシのバグであると同時に、負荷を増幅させます。修正すると、コネクションプールの圧迫と下流の CPU 負荷を同時に軽減できることがよくあります。
• プールを大きくすればよいとは限りません。データベースが遅い場合、並行性を高めるとテールレイテンシが悪化することがよくあります。
• Hikari のチューニングは、CPU 数だけでなく、データベースの処理能力とワークロードのパターンに基づいて行う必要があります。
• WebFlux やコルーチンのイベントループ内でブロッキング呼び出しを行うと、平均レイテンシが許容範囲に見えても、壊滅的な影響を及ぼします。
• Dispatchers.IO は、無料で使えるパフォーマンス向上の手段ではありません。ブロッキング処理を移動できますが、アーキテクチャ上の不整合を隠し、コンテキスト切り替えを増やすこともあります。
• 下流の呼び出しを並列化すると、平均レイテンシを短縮できる一方、負荷時の飽和やタイムアウトを悪化させることがあります。
• キャッシュには、無効化、ウォームアップ、カーディナリティの適切な管理が必要です。不適切なキャッシュは、ベンチマークを改善しても、本番環境での正しさを損なうことがあります。
• データベースをすでに最適化した後は、大きなオブジェクトグラフ、冗長な JSON、繰り返し行われるマッピングがレイテンシの主因になることがあります。
• ロックの競合や長時間のトランザクションは、コネクションプールの飽和やリトライと関連付けるまでは、ランダムなレイテンシの急増に見えることがよくあります。
• GC のチューニングは、メモリ割り当てのパターンを踏まえて行うものです。オブジェクトの大量生成を理解する前に、JVM フラグに手を出さないでください。

測定上の注意点

• 平均レイテンシでは、テールの問題が隠れてしまいます。ユーザーへの影響が突発的に発生する場合は、パーセンタイルと飽和状態との相関を優先してください。
• 協調的欠落により、負荷テストでは本番環境より健全に見えることがあります。ベンチマークツールの前提もエビデンスの一部として扱ってください。
• コンテナの CPU 制限、メモリ制限、JDK のコンテナ認識機能は、ローカルのプロファイリングで問題がなくても、実行時の挙動を大きく左右することがあります。
• ウォームアップの状態、JIT コンパイル、キャッシュの充填、コネクションプールの初期化が重要です。コールドスタート時の挙動と定常状態の挙動は分けて評価してください。
• 経路のどこかにキューイングが存在する場合、利用率がわずかに上がるだけで、レイテンシが非線形に増加することがあります。CPU 使用率だけでなく、キューイングの観点で考えてください。

エキスパート向けヒューリスティクス

• 既存の処理を並列化する前に、不要な処理をなくすことを優先してください。
• ある最適化によってスループットが向上しても、テールレイテンシや運用時の明瞭さが悪化する場合は、そのトレードオフを明示してください。
• リアクティブコードやコルーチンコードがブロッキングコードより遅い場合は、そのパラダイムを原因と決めつける前に、隠れたブロッキング境界やコンテキスト切り替えを確認してください。
• 依存先が原因ですでにサービスの SLO が制約されている場合は、ローカルコードのマイクロ最適化よりも、分離とグレースフルデグラデーションを優先してください。

並行処理のルール

• 非同期実行や並列実行を推奨する前に、I/O バウンドの処理と CPU バウンドの処理を区別します。
• ロックや接続の使用が関わる場合は、トランザクションのスコープを短く保ちます。
• 水平スケールするサービスでは、共有される変更可能なインメモリ状態を設計上の問題として扱います。
• コルーチンやリアクティブフローでは、デバッグやトレーシングが問題の一部である場合、トランザクション、セキュリティ、MDC のコンテキスト伝播を確認します。
• 無制限の並列処理を行う前に、バックプレッシャー、バルクヘッド、または有界キューを使用します。

出力仕様

以下のセクションを返します。

• Observed bottleneck：最も可能性の高い制約リソースまたは競合箇所。
• Evidence：その結論を裏付けるメトリクス、トレース、コードパス、または SQL の証拠。
• Recommended change：影響が大きく、変更範囲が最小の最適化。
• Tradeoffs：改善される点と、新たに生じるリスク。
• Verification：改善が見込まれるベンチマーク、メトリクス、または負荷テストのシグナル。

ガードレール

• 測定せずに最適化しないでください。
• 反射的にキャッシュ、非同期処理、または大きなプールを推奨しないでください。
• スループットの最適化とレイテンシの最適化を混同しないでください。両者が逆方向に動くこともあります。
• 高い並行性や I/O 負荷の高い処理では、ローカルのベンチマークだけを信用しないでください。

品質基準

このスキルの適切な実行では、真の制約を特定し、測定可能な改善計画を提示します。 不適切な実行では、証拠もトレードオフも成功を確認する方法も示さず、汎用的な調整項目を提案します。