LoadView

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

| パフォーマンステスト

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

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

| パフォーマンステスト

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

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

| パフォーマンステスト

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

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

| パフォーマンステスト

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

高並列負荷テスト：チケット販売と予約急増の対策

| パフォーマンステスト

午前9時のチケット販売のクラッシュは誰も望みません。それでもよく起きます—コンサートのチケットが消える、航空会社のサイトが止まる、チェックアウト画面がフリーズする。失敗したチケット販売や予約の急増の背後には常に同じ原因があります：高並列に備えていないシステムです。...

AWS Lambda と Azure Functions のサーバーレス負荷テスト

| パフォーマンステスト, 技術のヒント

インフラが消えると、パフォーマンスエンジニアが頼りにしていた前提も消えます。AWS Lambda、Azure Functions、Google Cloud Functions といったサーバーレスコンピューティングは無限のスケーラビリティと運用負荷のゼロ化を約束します。しかし実際には、従来のサーバーの定常負荷モデルを、はるかに動的で予測不可能なものに置き換えてしまいます。...