質問の背景:
現代の情報システムは、通常、負荷の下で動作し、ユーザー数とデータ量が増加しています。ビジネスは、製品の高いパフォーマンスとスケーラビリティ、耐障害性、ダウンタイムの最小リスクを要求します。
問題:
パフォーマンス要件は明確に定義されることが少なく、しばしば形式的です：「早く動作する」または「100,000ユーザーにスケーラブルである」。未精緻な基準は、ソリューションの検証、調整、テストが不可能になり、時にはリソースの過剰消費を引き起こすことがあります。
解決策:
重要な特徴:
業界の標準メトリックを製品分析なしに使用することは可能ですか？
標準メトリックは指標として役立ちますが、ビジネスの特性や製品のターゲットオーディエンスに合わせて適応する必要があります。そうしないと、重要なシナリオや負荷を考慮しない可能性があります。
開発中のテストでの負荷が、スケーラビリティを確信するために十分ですか？
いいえ、テスト環境は通常、インフラのパラメータで本番環境と大きく異なります。現実に近い負荷テストを行い、定期的に繰り返す必要があります。
ビジネス機能を損なうことなく最大パフォーマンスを実現することは可能ですか？
ほぼ常に妥協があります：時には安定性と予算への対応のために制限（たとえば、バッチ処理や特定のシナリオに対する制限）が導入されることがあります。
ネガティブケース: 要件仕様書には「高負荷で動作する」と記載されていましたが、メトリックが定義されていませんでした。リリースでは、データのロードに何時間もかかり、ビジネスは顧客を失いました。 利点：迅速な要件の合意。 欠点：負荷の下でのシステムの予測不可能な動作。
ポジティブケース: アナリストはビジネスシナリオを求め、アーキテクトと共同で制限を確認し、負荷テストを実施しました。リリースでは、システムがプロモーションのピーク負荷に耐えました。 利点：予測可能な成長、マーケティングキャンペーンの成功。 欠点：追加のテストのためにリリースが遅延しました。