LoadView

トラフィック急増に対応するオンライン投票システムの負荷テスト

| パフォーマンステスト

オンライン投票は、有権者全体をわずか数分間のトラフィックに集中させます。グラフが急上昇しますが、問題はサイトが耐えられるかどうかです。 投票は午前9時に開始されます。9時04分までにはサポートラインが鳴り響きます。投票ページがぐるぐる回り、ログインは500エラーを返し、郡書記官が電話で「なぜ誰も投票できないのか」と問い合わせてきます。システムはテスト中は問題ありませんでした。昨日も問題ありませんでした。しかし、昨日は18000人が同じ4分間に投票を試みることはありませんでしたので、今は問題があります。...

なぜリアルな負荷テストには複数のIPアドレスが必要なのか

| パフォーマンステスト

本番トラフィックは多くのIPおよび地域から発生し、単一のソースではありません。 要約. 単一IPからの負荷テストは誤解を招く結果を生む可能性があります。なぜなら、CDN、WAF、レートリミッター、およびルーティング層は分散トラフィック下で異なる動作をするためです。現実的な結果を得るためには、複数の地域にわたる複数のIPを使用したテストが必要です。 目次 単一IPテストが問題ないように見える理由 7つの具体的な障害モード クラウドイグレスの罠 現実的なIP分布の様子 単一IP vs 分散IP：それぞれが適切な場合 実世界のシナリオ...

大規模データセットを持つサイトの負荷テスト方法

| パフォーマンステスト

多くのパフォーマンス障害は単なるトラフィックからは現れません。各リクエストがシステム内で引きずるデータの重さから発生します。基盤となるデータセットが小さいとサイトは速く感じられても、本番のデータ量が蓄積されると遅くなったり不安定になったり、最悪応答不能になります。カタログの増加、ダッシュボードの肥大化、インデックスの偏移、ログの膨張、検索クラスターの老朽化、そしてデータアクセスパターンが設計時の前提を徐々に超えるといった現象が起きます。ステージングではアーキテクチャが健全に見えても、本番データセットが臨界に達すると同じコードが異なる挙...

サードパーティスクリプトが負荷テストの結果に与える影響

| パフォーマンステスト

サードパーティスクリプトは、静かに負荷テストにおけるノイズ、歪み、誤検知の最大の原因のひとつになっています。あらゆるマーケティングツール、アナリティクスピクセル、最適化フレームワーク、ウィジェットが、あなたのアプリケーションが制御できないリモート依存をさらに追加します。本番トラフィック下ではそれらの多くは「十分に動く」ことが多いですが、合成負荷では地雷のように振る舞い、その失敗をしばしば「あなたの」失敗として報告します。...

負荷テストにおけるクラウドのスケーリングルール：スケーリングが自動ではないとき

| パフォーマンステスト

自動スケーリングは、キャパシティプランニングの手探りを取り除くことを約束しました。ルールを設定し、メトリクスを定義し、残りはクラウドに任せればよい。少なくともスライドではそう見えます。実際には、スケーリングルールは期待通りに動作することが稀です。遅延したり、過剰に反応したり、トラフィックが急増しても眠ったままになることがあります。...

GraphQL エンドポイントを正しく負荷テストする方法

| パフォーマンステスト

GraphQL はフロントエンドのデータ取得方法を変えました — そしてそれにより、API が負荷下でどのように故障するかも変わりました。 各ルートが返すデータを定義する REST とは異なり、GraphQL は制御を反転させます。クライアントが取得するフィールド、どの深さまで辿るか、リクエストをどのくらいの頻度で繰り返すかを決めます。その柔軟性は開発者にとって解放的ですが、パフォーマンスを予測しにくくします。同じエンドポイントに対する二つのクエリが、まったく異なるサーバーのワークロードを生み出すことがあります。...