負荷テストとストレスプロファイル
概要
負荷テストは、現実的で極端なシナリオでのパフォーマンスと回復力のシステムテストです。成功の基礎：正しいトラフィックモデル（オープンとクローズ）、固定SLO、純粋なメトリック（レイテンシ/スループット/エラー/彩度）、代表的なデータ、自動化と再現性。結果は「RPS図」ではなく、解決策です。ボトルネックはどこにあり、パフォーマンスのコストはいくらですか、障害のしきい値はどこにあり、どのように動かすかです。
SLO/SLIとターゲットメトリック
SLO（例）：p95 API ≤ 250 ms、 p99 ≤ 600 ms；エラー≤ 0。3％/30日。
SLI：レイテンシー（p50/p95/p99）、スループット（RPS/CPS/QPS）、飽和（CPU/ヒープ/GC/FD/conn）、 оarimиzo （5xx、 timeouts）、 DB（ロック、遅いクエリ）、кэш（ヒット比）。
エラーと彩度トリガ（例えば、CPU> 75％またはキューの深さ>X→劣化）。
テストの種類
1.ベースライン/ベンチマーク-単一のサービス/エンドポイント、「理想的な」条件。
2.ロード-現実的な「作業日」+ランプアップ/ランプダウン。
3.応力-劣化とブレークポイント固定への負荷を増加させます。
4.スパイク-シャープジャンプ（秒/分でx2-x10）。
5.浸漬/耐久性-ロングラン（8-72 h）：メモリリーク、レイテンシードリフト。
6.容量-パフォーマンス曲線と容量計画のステップ負荷。
7.Degradation/Chaos-mix-load+partial failures（遅いデータベース、キャッシュドロップ、「collapsed」 applink）。
トラフィックモデル： OpenとClosed
オープンモデル（インターネットではより現実的）：ユーザーはλ強度（Poissonのようなストリーム）を持っています。システムが遅くなると、要求は「凍結」ではなく、蓄積されます。
クローズドモデル-think-timeを使用した仮想ユーザー（VU）の固定数。遅延が増加すると、RPSは人工的に低下します。
推奨事項：フロントエンドAPIではオープンモデル（k6 'arrival-rate'）を使用し、内部同期スクリプトでは-クローズと結合します。
プロファイルの読み込み（テンプレート）
「通常の日」：ベースラインの背景+毎日の変動。
「ピークイベント」：開始（ウォームアップ）、開始時に鋭いスパイク、高原、尾の10〜30分前。
「トーナメント/ストリーム」：はしごのステップ、間隔で繰り返されるピーク。
「インフラストラクチャの劣化」：キャッシュの半分が空で、1つのリージョンがオフになり、PSPのレイテンシーが増加します。
「フェイルオーバー」：トラフィックは1〜5分間で保護されます。オートスケール/HPA/Retryの嵐を点検します。
環境データと準備
テストデータ：現実的なカーディナリティ（プロバイダ、通貨、国）、汚れたフィールド、クエリ分布（Pareto/Zipf）。
秘密/PII：匿名化；keys/PSP-サンドボックス。
環境：専用perfスタンド、統合からの分離（モック/スタブ）、固定バージョン。
観測可能性：メトリック（Prometheus）、ログ（Loki/ELK）、トレース（OTel）。レスポンスでbuild-idを記録します。
反stormリトレイとidempotence
Retraiはidempotent操作のみを対象としています。再試行予算を設定します（例：トラフィックの10％ ≤）。
指数関数バックオフ+ジッタ；「折りたたみ」同一のGET。
支払いの場合-idempotentキーと明示的なステータス。
雷の群れに対する保護：キャッシュロック、SWR、ローカルセマフォ。
ツールとパターン
k6（スクリプティング、オープンモデル、良いレポート）、Locust （Pythonスクリプト）、Gatling （Scala）、 JMeter（幅広いプロトコル）。
プロトコル：HTTP/1。1/2/3、 gRPC、 WebSocket、 TCP/UDP；プッシュサーバーは「as GET」をテストしません。
トラフィック生成：ジェネレータの水平スケーリング、ネットワークボトルネックの制御。
プロファイルの削除：負荷下でのpprof/async-profiler/ebpf、 OTelルート。
javascript import http from 'k6/http';
import {check, sleep} from 'k6';
export const options = {
scenarios: {
warmup: { executor: 'ramping-arrival-rate', startRate: 50, timeUnit: '1s',
preAllocatedVUs: 200, stages: [ { target: 200, duration: '5m' } ] },
spike: { executor: 'constant-arrival-rate', rate: 1200, timeUnit: '1s',
preAllocatedVUs: 2000, startTime: '6m', duration: '3m' }
},
thresholds: {
http_req_failed: ['rate<0. 3%'],
http_req_duration: ['p(95)<250', 'p(99)<600']
}
};
export default function () {
const res = http. get(`${__ENV. BASE_URL}/api/v1/catalog? c=${Math. floor(Math. random()1000)}`);
check(res, { 'status is 200': (r) => r. status === 200 });
sleep(Math. random()0. 9) ;//think time (for closed parts of the script)
}プロシージャ
1.仮説→どのボトルネックが発生するか（CPU、 DB、キャッシュ、ネットワーク、TLS、 GC）。
2.プロファイル→シナリオ/ルート、トラフィックシェア、モデル（オープン/クローズ）、データ。
3.ウォームアップ→キャッシュ/接続/TLS/インタプリタ。
4.目標の強度に→ステージの増加。
5.高原→安定した指標とトレースのコレクション。
6.応力/衰退→ブレークポイントを見つけ、オートスケールを観察します。
7.分析→メトリクス、フラメグラフ、レポート、変更計画を関連付けます。
8.Repruf→CI （Region Perf）パイプラインを繰り返します。
結果の分析
ロード→ディレイ/エラーカーブ：肘（容量）を探します。
内訳レイテンシ：ネットワーク（DNS/TLS/connect）、プロキシ、アプリケーション、データベース、外部コール。
飽和：CPU> 75-85％、 GC pause> p95、 I/O待機、タスクキュー。
弾性：オートスケール反応時間（HPA/KEDA）、コールドスタート、キャッシュのウォームアップ。
コスト：目標SLOで$/1000 RPS、ピーク予算予測。
エンジニアリングプラクティス
劣化の指標：「尾」p99、キューの成長、ヒット比の低下、リトレイ試行の成長。
コンファウンダを除外：ファイル記述子の制限、sysctl、 conn-pool、 'reuseport'、 TLSチェーン、OCSP。
DB：インデックス/プラン/クエリキャッシュ、接続プール、バッチ操作、生産者のバックプレッシャー。
キャッシュ：サイズ/回避ポリシー、ホットキー、レプリケーション。
ネットワーク/エッジ：HTTP/2/3、再開≥ 70％、 Brotli、 CDNキャッシュキー、階層キャッシュ。
荷重下での観測性
メトリクス：システム（CPU/mem/IO）、ランタイム（GC/ヒープ）、ネットワーク（RTT/loss/ECN）、 L7 （p95/99、 5xx/429）、キュー、データベースクラスタ/キャッシュ。
トレイル：「尾」（テールベース）、ビルドID/カナリアマークのサンプリングが含まれます。
ログ：ボリューム制限のあるエラーの集計（「forDOSor」 log-pipeline）。
実験：feature-flagsとconfigsはレポートに記録する必要があります。
オートメーションとCI/CD
CIのPerf-jobs（煙3-5分、毎晩30-60分、毎週浸る）。
許容限界：遅延/エラー/リソース→回帰中の"break build'。
アーティファクト：グラフ、フラメグラフ、プロファイル、JSONレポート（k6/jtl）。
データとスクリプトのバージョニング、perfスクリプトのPRレビュー。
iGaming/fintech固有の
トーナメント/試合：スパイク+高原；TLS/DNS/CDNウォーミングアップ、プール制限の増加、ボット用のグレールート。
支払い/PSP：サンドボックスの制限、idempotency、厳格なタイムアウト。degrade-mode（ディレクトリキャッシュ、キュー）をチェックしています。
ジャックポット/イベント：原子性と一貫性、テイクなし、RNG/リードボードへのロード。
不正防止/AML： ルール/MLスコアリング、バックプレッシャー、イベント重複排除への負荷。
規制：ピーク時のメトリクスとバージョンの記録、監査レポート。
チェックリストの起動
- SLO/SLIと赤線（エラー/レイテンシー/彩度）を修正。
- ロードシナリオとプロファイルが承認されます（オープン/クローズ、スパイク/ソーク/ストレス）。
- データリアリスティック、PIIマスク、統合サンドボックス/モック。
- Observability ready：メトリック/トレイル/ログ、リリースタグ。
- システム構成（ulimit/sysctl/pools）がドキュメント化されています。
- ウォームアッププランとロールバック基準の自動スケール/キャッシュ。
- しきい値アラートとオンコールプラン。
- レポートテンプレート（チャート、結論、アクション）が用意されています。
よくあるエラー
クローズドモデルテストは「緑」の結果を生成し、製品は低下します（オープンモデルを無視することはできません）。
表現不可能なデータ（1通貨/1プロバイダ）→誤った結論。
準備なし：コールドキャッシュ/TLS/接続→開始時に過剰なレイテンシ。
限界のないレトライ→嵐とカスケードの滝。
すべてのサービスで同じプロファイル→実際の「ホットスポット」をスキップします。
ソークランがない→メモリリークやドリフトが見えない。
不透明な結果：トレース/フラメグラフがない→ボトルネックが見つかりません。
ミニプレイブック
ブレークポイントの定義
1.5-10分ごとの負荷の10-20％のステップ。2） p95が急激に上昇する瞬間とエラー>SLOを修正します。3） CPU/DB/キャッシュプロファイルを削除します。4）最適化の計画および繰り返し。
リトレイの嵐に巻き込まれる
1.再試行予算を制限し、バックオフ+ジッタを有効にします。2）リクエスト折りたたみ/SWRを入力します。3） 「degrad mode」（限られた機能）を許可して下さい。4） idempotencyをダブルチェックします。
ピークイベント（トーナメント）-事前計画
1.CDN/DNS/TLS/プールをウォームアップします。2）目標HPAを増やし、予備を準備する。3）ボットのための別の料金制限。4）ピークモードダッシュボード、通話中の通信ブリッジ。
ソークナイト
1.安定した負荷の8-12時間。2） モニターヒープ/FD/conn/GC-pauses。3） p95デルタとヒット比を確認します。4）漏出および漂流を修理して下さい。
［結果］
負荷テストはエンジニアリングの意思決定プロセスであり、RPSのためのレースではありません。"モデルの実際のプロファイル（特にオープンモデル）、SLOのキャプチャ、メトリクスとトレースの取得、パフォーマンスの膝を探し、パフォーマンスのコストをカウントします。このようにプラットフォームは、最もストレスの多い瞬間に予測可能で安定した状態になります。