audit-performance

パフォーマンスの監査

有用な上限なく増え続ける処理や、進展なく繰り返される処理を見つけます。根拠に基づく台帳またはレポートを作成し、復旧可能性を保つ最小限の修正を優先します。

ワークフロー

1. ホットパスを追跡します。 繰り返し実行される同期、ポーリング、ストリーム、再試行、キュー、スケジュール済みジョブ、ファイルシステムの走査、リクエスト時の読み取りを見つけます。それぞれを本番環境の呼び出し元までたどり、テスト専用のパスは対象外にします。
2. 処理の増幅度を算出します。 トリガーと最悪時の処理量を、行数、クエリ数、ページ数、エントリー数、バイト数、ジョブ数、再試行回数、全ファイルの書き換えなど、具体的な単位で示します。上限のある大きな定数と、履歴、テナント、パス、停止期間に応じて増える処理を区別します。
3. 前進できることを確認します。 各再試行、固定プレフィックスのバッチ、カットオフ、移行中のポーリングについて、次の試行までに何が変わるかを特定します。何も変わらない場合、永久にループしたり、処理を停滞させたりする可能性があります。部分的な修正が、同じ処理を先送りするだけになっていないか確認します。
4. 深刻度を検証します。 既存の上限、インデックス、バックオフ、期限、修復の担当者、呼び出し頻度を調べます。すでに十分低コストで上限が設けられている問題や、継続的に修復される問題は対象外とします。
5. 修正前に記録します。 プロジェクトにパフォーマンス台帳がある場合は、裏付けのあるすべての所見と重要な対象外判断を、既存の規約に従って追記します。ない場合は、簡潔なレポートを作成します。優先度、トリガー、影響、現在の担当者、受け入れ確認箇所、根拠を含めます。
6. 以下の方針に従って優先順位を付けます。 実装が許可されている場合は、プロジェクトのテスト作成ワークフローを実行し、実用上もっとも外側の境界で従来の動作が失敗することを確認します。修正してレビューし、検証結果の根拠とともに台帳またはレポートを更新します。

優先順位の方針

ユーザーに見えるフリーズやエラー、メモリーやディスクの増大、リクエスト処理の停滞、データ損失、システム全体に及ぶ処理の増幅、後続の処理を妨げる不正なアイテムにつながる問題を最優先します。

既存処理に上限を設ける、リスクの低い修正を優先します。ページ単位でストリーミングする、バックプレッシャーに従う、スケジュールを集約する、不正な行を別の場所に移す、何も変わらないと証明できる場合は処理をスキップする、網羅的な検索を最終判定で確実に終了させる、といった方法があります。安全上の上限は異常動作への対策であり、通常の製品上限ではありません。正当な大規模ワークロードを上回る値に設定し、上限に達した際は対処に役立つテレメトリーを出力し、その後どうするかを定めます。

数の大きさだけを見て優先順位を決めないでください。

• ポーリング対象の状態に実際の復旧担当者がいて、最終的に変化しうる場合、ポーリングはいつまでも続くことがあります。単に長時間続くタイマーではなく、復旧しえない状態を修正します。
• 本番環境で問題を示す根拠がなければ、低コストで上限のあるデータベース処理は許容されます。控えめな固定数のクエリを減らすだけのために、プロジェクション、キャッシュ、カーソル状態マシン、代替読み取りモデルを構築しないでください。
• 製品の UI や動作で近いうちに活用する可能性がある情報を、最適化のために削除しないでください。

ガードレール

• 回復性を維持します。キャッシュや何もしないショートカットにも低コストの回復シグナルを残し、ドリフト、不確実な状態、再起動、または以前の失敗があれば、通常の調整処理にフォールバックさせます。
• 回復スキャンは完了するか、前進した進捗を永続化する必要があります。ローカルでプルーニング可能な名前空間では、通常の大規模プロジェクトではなく異常の兆候を示すのに十分な上限を設けて、1回の完全なパスを優先します。正当に巨大な名前空間では、カーソルを永続化してその位置から再開します。対象が見つかった場合は識別情報を更新し、網羅的に調べても見つからなかった場合、または異常な上限に達した場合は、そのドメインの終端判定を行います。同じ未完了の先頭部分をいつまでも再開しないでください。
• 再試行可能な失敗と終端的な失敗を分けます。恒久的な拒否がキューの先頭や固定された先頭部分にいつまでも滞留しないようにします。
• トランスポートの両側と、永続キューおよびメモリー内キューのすべてに上限を設けます。あふれた場合の動作を明示し、受け付け済みの永続データを黙って破棄してはいけません。
• キャッシュ、インデックス、差分プロトコルは、静穏時の平均ではなく、最悪の編集操作を基準に評価します。保持コレクションへの挿入、アクティブビューから離れた箇所の変更、移動、削除を確認します。正確な結果と併せて、処理量が上限内であることも検証します。
• 測定値を信頼する前に、測定対象のワークロードが説明どおりに動作することを確認します。力が作用し合っていること、経路を移動していること、失敗側の処理が実行されることを確認します。失敗側の処理も測定します。
• コスト測定を、プロセス内で実行中のほかのすべてから分離します。
• 互換性対応を製品のライフサイクルに合わせます。リリース前のコードでは、直接的な変更を優先し、実際に永続化されたデータで必要とされない限り、レガシー分岐や移行処理を追加しないでください。
• 導入または変更するすべての上限について、上限の種類、設定値、影響を受ける所有者、過負荷時の動作を示すログまたはメトリクスを確認できるようにします。

完了条件

監査が完了したといえるのは、すべての指摘事項に本番環境での発生条件、定量化された増幅度、優先順位の根拠、受け入れ確認箇所、記録された処置がそろい、却下された候補には、その候補を許容できる根拠となる上限または回復機構が示されている場合に限ります。実装が完了したといえるのは、レッド／グリーンの検証で、処理量が上限内であることと回復が継続することの両方が示された場合に限ります。