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

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

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

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

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

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

ネットワーク遅延を考慮した負荷テスト:ベストプラクティスと戦略

多くの負荷テストは、真空状態でパフォーマンスを測定しています。テスト対象のサーバーから数ミリ秒の距離にある、クリーンなクラウドネットワーク内で実行されるため、数値は見栄えがします。しかし、ユーザーが実際のデバイスで、現実のネットワークから接続すると、すべてが遅くなります。...

Playwrightによる負荷テスト:大規模に実ユーザーをシミュレートする方法

長年、負荷テストとは API を叩きまくることを意味していました。JMeter のようなツールは、スループットとレイテンシを測るために数千もの軽量な HTTP リクエストを送信していました。そしてそれは機能していました—アプリケーションが単純なリクエスト/レスポンスの仕組みであることをやめるまでは。 現代のウェブアプリは、JavaScript...

製品ローンチ前に負荷テストを行う方法(そしてその理由)

製品ローンチは、デジタルサービスのライフサイクルで最も容赦のない瞬間です。機能の設計に数か月、ユーザー体験の磨き込みに数週間、マーケティングに何千ドルも費やしても、ローンチ後最初の30分でインフラが崩れれば結末は同じです。ダウンタイム、怒れるユーザー、無駄になった費用。日々の運用とは異なり、ローンチはトラフィックを単一で予測不能なスパイクへと圧縮します。だからこそ製品ローンチに向けた負荷テストは「任意」ではありません——シームレスに感じられるローンチと、自らの話題性に押し潰されて崩れるローンチを分ける分水嶺なのです。...