統計ベストプラクティス
このガイドでは、統計データを分析し、実用的な決定を下す方法を説明します。進入許容を設定する方法や容量を計画する方法などの実用的なトピックを扱います。
定期的なモニタリングチェックリスト
週次レビュー:
- 完了率(%)の確認(80%以上である必要がある)
- ピーク時間中の待機者と待機時間の確認
- 通常時間とピーク時間間の処理時間の比較
月次レビュー:
- 先月のピーク進入リクエストパターンのレビュー
- 進入許容活用率の分析(待機者/待機時間が増加した期間の識別)
- 統合状態の確認(持続的に低い完了率(%)を持つセグメントの識別)
進入許容変更計画時:
- 3-6ヶ月の過去データ分析(月表示を使用)
- ピーク期間の識別とサーバーリソースの確認(APM記録を参照)
- 変更後1-2週間のモニタリング(日表示を使用)
最適な進入許容の決定
ステップ1: 通常期間とピーク期間の理解
確認事項:
- 進入リクエストの確認: 通常時間とピーク時間中に入ってくる初期リクエスト(進入リクエスト)の速度を確認
- 待機者条件の確認: その時間に何人のユーザーが待機中か(待機者)および平均待機時間(待機時間)を確認
例示パターン:
時間 進入リクエスト (TPS) 待機者 待機時間 進入許容 解釈
09:00 80 20 3秒 100 通常時間
10:00 120 50 8秒 100 ピーク開始
11:00 150 200 20秒 100 ピーク(待機発生)
12:00 130 180 18秒 100 ピーク継続
ステップ2: ピーク中の進入許容の適切性評価
評価基準:
- サーバーリソースの確認: APM記録を参照して、ピーク時間中のWASサーバーCPUおよびその他のコンピューティングリソース使用率を確認
- 決定:
- サーバーに利用可能な進入許容があるが待機時間が長い場合 → 進入許容の増加を検討
- サーバーが過負荷状態で待機時間が長い場合 → 進入許容を維持または減少
- サーバーに利用可能な進入許容があり待機時間が低い場合 → 現在の設定を維持
確認事項:
- ピーク時間中の待機者と待機時間
- ピーク時間中のサーバーCPU使用率(APM記録を参照)
- サーバーに利用可能な進入許容があるか、または過負荷状態かどうか
例示評価:
ピーク時間の状況:
- 進入リクエスト: 150 TPS
- 待機者: 200名
- 待機時間: 20秒
- サーバーCPU使用率: 50%(APM記録)
決定: サーバーに利用可能な進入許容があるが待機時間が長い場合 → 進入許容の増加を検討
ステップ3: 処理時間によるパフォーマンス低下の確認
重要な原則:
- 理想的な状況: 基本セグメントの場合、通常時間の処理時間(処理時間)とピーク時間の処理時間がほぼ同じである必要があります。
パターン分析:
-
通常時間とピーク時間の処理時間が類似しているか?
- 類似している → 正常、待機者/待機時間およびサーバーリソースに基づいて進入許容を調整
-
ピーク時間にのみ処理時間が増加したか?
- 増加している → サーバーが遅く応答している可能性がある
- サーバーリソースがまだ利用可能な場合(APM記録を確認)、待機者が増加しても進入許容の増加を検討
- サーバーが過負荷状態の場合、進入許容を増加させず、まずパフォーマンス問題を調査して修正
例示パターン:
時間 処理時間 待機者 解釈
09:00 2.5秒 20 通常時間(正常)
10:00 2.6秒 50 ピーク開始(正常)
11:00 4.5秒 200 ピーク - 処理時間増加(サーバー応答遅延)
12:00 4.2秒 180 ピーク継続 - 処理時間増加
決定: ピーク時間にのみ処理時間が増加している → サーバー応答遅延の可能性
→ サーバーリソースが利用可能な場合(APM確認)、待機者が増加しても進入許容の増加を検討
対応:
- ピーク時間の処理時間が通常時間に比べて大幅に増加した場合、サーバーパフォーマンス問題を示す可能性がある
- まずサーバーリソースを確認してください(APM記録によるCPU、メモリ):
- サーバーに利用可能な進入許容がある場合: より多くの同時リクエストを許可するために進入許容の増加を検討、遅延がサーバー過負荷ではなく待機者によるものである可能性があるため、役立つ可能性がある
- サーバーが過負荷状態の場合: 進入許容を増加させず、まずパフォーマンスボトルネックを調査して解決
- 同時にサーバーログまたはAPMを通じてサーバー応答遅延の原因を調査
統合問題の検出
パターン: 進入リクエスト vs 処理完了量の分岐
意味:
- 進入リクエストが処理完了量より持続的に高い = ユーザーが進入するがサービスを適切に完了しない
- 低い完了率(%)(<80%) =
nfStop()呼び出しの欠落または統合問題
例示パターン:
時間 進入リクエスト (TPS) 処理完了量 (TPS) 完了率(%) 解釈
09:00 100 95 95% 健全
10:00 100 80 80% 健全
11:00 100 60 60% 問題 - 終了呼び出しの欠落
12:00 100 55 55% 問題 - コードレビューが必要
対応:
- 即座: 低い完了率(%)を持つセグメントを確認(セグメント表示を使用)
- 一時的な対応: キーが返却されない場合、キー返却タイムアウトを調整して自動キー返却を強制
- タイムアウトを下げる(例: 最小6秒 → 3-4秒)ことで、自動返却がより迅速に発生するようにする
- これは完了率(%)に反映されないが、進入許容がより迅速に解放され、他のユーザーが進入できるようになる
- タイムアウト設定はセグメント高度な設定 - タイミング(基本制御)または高度な設定 - タイミング(区間制御)で調整できます
- 根本原因の調査: 最近のコード変更のレビュー、欠落している
nfStop()呼び出しの検索 - 根本原因の修正: すべてのコードパスに明示的な終了を追加、エラー処理にキー返却が含まれるように保証
進入許容変更時の重要な考慮事項
変更後のモニタリング
進入許容を変更した後、常にモニタリングしてください:
- 変更直後: 日表示を使用して1-2週間モニタリング
- 確認事項:
- 待機者/待機時間が改善されたかどうか
- 期待される効果が現れたかどうか
- 調整: 実際の結果に基づいて追加の調整を実行
段階的な変更の原則
- 増加: 一度に10-20%増加、モニタリング、その後繰り返し
- 減少: サーバー保護が緊急の場合、即座に40-50%減少; そうでない場合は段階的に減少