負荷テストは、多くの点で、民間防衛および緊急事態での演習に似ています。 パニックに陥ろうとするよりも、この状況やその状況がどのように見えるかを事前に理解しておく方がよいでしょう。 生産時に収集された独自のテストと問題に加えて、業界の同僚の経験から学ぶことができます。 特に「テスターカレンダー」プロジェクトでは、大規模IT企業のPEの例に基づいて、KonturテスターのDmitry Vorotnikovが、サービスをテストするためのいくつかの単純だが重要なルールを提示しました。

負荷プロファイルの変更

彼らがストレステストについて話すとき、彼らは通常、容量テストを意味します。 オンラインストアにはブラックフライデーとサイバーマンデーがあります。販売時間とすべてのサービスの負荷の極端な増加です。 サーキットでは、規制当局への報告の最後の日にトラフィックの同様のジャンプが発生します。 何らかの理由で訪問者の数が増えた場合、操作、エラー、または応答時間の増加にアクセスできなくなります。 サービスの容量をテストすることにより、ユーザーが悪意を持ってマウスを動かしたり、競合他社に行ったりすることなく、快適かつ生産的に作業できることを確認します。

先月、1年、または2年に典型的な負荷プロファイルを繰り返す負荷プロファイルでテストすると、2008年2月15日にAmazon Simple Storage Serviceで発生したような問題が発生する可能性があります。 S3のデータへのアクセスは、AWS認証サービスによって規制されています。 それに対する要求は暗号化されており、処理するには大きな処理リソースが必要です。 Amazonは、過去2年間の負荷を処理するために必要な数のサーバーをサポートしました。 報告日の午前3時30分に、エンジニアは認証要求の数が増えていることに気付きました。 これにより、AWSインフラストラクチャが過負荷になり、すべてのリクエストを処理できなくなりました。 増加した負荷を処理するには、追加の容量を導入する必要がありました。 6:48まで、S3を使用するすべてのプロジェクトは利用できませんでした。

サービスキャパシティを計画するとき、および負荷テスト中に、負荷プロファイルの可能な変更を検討します。

不規則性

負荷プロファイルの変更の可能性を考慮しても、単一のテストまたは不定期のテストを実行するだけでは十分ではありません。 特に、ユーザー数または新しい統合を絶えず増やしている場合。

2010年12月22日水曜日に、 Skypeメッセンジャーはエラーで動作し始めました。 接続を確立するには、最終的にサービスが完全に機能しなくなるまで、より多くの時間が必要でした。 この問題は、インスタントメッセージを処理する多数のサーバーが過負荷になることによって引き起こされました。 それらの処理には著しく時間がかかり始めました。 この速度低下により、Windowsクライアントでバグが発生し、クラッシュが発生しました。 クライアントの大部分（スーパーノード）は、他のクライアント間のP2P交換をサポートしていました。 スーパーノードの25〜30％の障害により、残りのノードは過負荷になり、障害が発生し、負荷がさらに増加し​​ました。 このような連鎖的な障害の結果として、Skypeネットワークは約1日間利用できませんでした。

サービスを定期的にテストおよび確認します。

副作用

定期的なテストを計画し、そのスクリプトを開発する場合、不可抗力により負荷が増大する可能性があることに留意してください。 サービスを複数のデータセンターに分割しても、1つが失敗してもフォールトトレランスは追加されず、残りはその負荷を処理できません。 キャパシティプランニングでは、このようなシナリオを考慮する必要があります。 負荷を増やすもう1つのオプションは、ソフトウェアの更新や作業など、システムに意図的に変更を加えることです。

2009年2月24日、新しい機能によりGMailで問題が発生し、地理的に送信者に近い場所に文字を保存できるようになりました。 技術的な作業中、あるデータセンターのユーザーは別のデータセンターにリダイレクトされ、過負荷になりました。 これにより、データセンターからデータセンターへのカスケード障害が発生し、それぞれの負荷が増加し続けました。 サービスは2時間半利用できませんでした。 この物語はGfailと呼ばれています 。

この事後分析から、2つの関連する結論を引き出すことができます。 1つは、サービスとその環境が絶えず変化していることです。つまり、技術的な作業のシナリオをテストするか、サービスとサーバーを切断する必要があります。 2番目-作業時にテスト結果を考慮し、変更や停止の前にテスト結果を更新します。

失敗に対する準備不足

ダウンタイムを回避し、可用性メトリックに9を追加するには、サービスが耐えられる負荷の種類を知り、この知識を定期的に更新し、可用性を維持し、さまざまな変更を加えるときに使用する必要があります。 サービスを設計および開発する際には、過負荷、カスケード障害、停電、機器障害、データ損失に対する保護を提供する多くの手段を適用します。 残念ながら、この多様性は、実装、構成、および人的要因のエラーに対する万能薬ではありません。

2010年7月19日に、主要なアメリカのオンライン小売店American Eagle Outfittersのサイトは、メインストレージの障害により利用できなくなりました。 関係ありません、バックアップがあります！ ただし、バックアップストレージに切り替えると失敗しました。 磁気テープにまだバックアップがあったので、怖くない。 彼らは長い間復元された後、予備のサイトでサイトを立ち上げようとしましたが、失敗しました。 予備サイトは準備ができていませんでしたが、事前に準備しておくべきでした。 幅広い保護対策にもかかわらず、4日間で注文を取り戻す能力を回復することができました。 完全に回復するには、さらに4日間が必要でした。

ストレステストを実施し、サービスの機能を特定したら、防御メカニズム、フェールオーバー、およびバックアップのテストを忘れないでください。

そして最後に、サービスのすべてのクラッシュ、クラッシュの年表、およびその原因の分析に関する情報をアクセス可能な場所に保管します。 これは、開発者とテスターのチーム全体がファイルをよりよく研究し、それを解決するための新しいアプローチを見つけるのに役立ちます。

カレンダー記事のリスト：

別のアプローチを試してください

合理的なペアテスト

フィードバック：発生方法

テストを最適化する

本を読む

分析テスト

テスターはバグをキャッチし、Canerを読み、移動を整理する必要があります。

ロードサービス

QAサービスメトリック

セキュリティをテストする

顧客を知る

バックログを取る