トラフィック急増に備えてPHPアプリケーションを準備することは、通常の訪問数に任意の係数を掛けることではありません。必要な容量は、同時に発生するリクエスト数、各リクエストの処理時間、実行する処理によって変わります。キャッシュされたページと、複数の外部サービスを呼び出す処理では、消費するリソースが異なります。
運用上の目標は、代表的な負荷の下でサービスを制限するコンポーネント、その余力、そして余力が尽きたときの対応を把握することです。負荷テストは意思決定の根拠となる証拠を提供しますが、普遍的な処理能力を保証するものではありません。結果はコード、インフラ、データ、実際の利用パターンに左右されます。
同時実行数と処理の種類から負荷を見積もる
日次や月次のリクエスト数だけでは、容量を見積もるには不十分です。多くのアクセスが数時間に分散すれば余裕をもって動作するアプリケーションでも、数分間にリクエストが集中すれば飽和することがあります。負荷の目安をつかむには、リクエストの到着率、処理時間、同時実行される処理の割合を確認します。
目安として、到着率が変わらないまま処理時間が長くなると、同時に処理中となるリクエストが増えます。そのため、受信トラフィックに変化がなくても、依存先の遅延によって同時実行数が増える場合があります。また、トラフィックは均等とは限りません。キャンペーンで商品ページや検索が急増する一方、期間終了時には認証、エクスポート、書き込みが集中することがあります。
まず、ビジネス目標に影響するルートと処理を特定します。たとえば、公開ページの閲覧、検索、ログイン、注文作成、重要な管理タスクなどを含めます。読み取りと書き込み、キャッシュ可能なリクエストと不可能なリクエスト、同期リクエストとキューで処理できるジョブを区別します。全体の平均値で、遅いルートや重要なルートを見えなくしないでください。
代表性があり安全なテストを設計する
利用可能なテレメトリー、アクセスログ、既知のイベント予定をもとに、1つ以上のシナリオを定義します。各処理が占めるリクエストの割合、到着率の変化、各フェーズの継続時間を記録します。持続的な負荷と急激な負荷上昇の両方をテストするとよいでしょう。前者はリソースの段階的な枯渇、後者はピークへの急激な反応という異なる挙動を明らかにします。
テストは、結果を有用なものにできる程度に本番環境の構成を再現した環境で実行します。プロセス数、接続上限、キャッシュ、データ量、依存先の違いを確認してください。テーブルが小さい隔離マシンでテストしても、本番環境の応答を示すことにはなりません。明示的な計画と許可なしに、実ユーザーに対して負荷を発生させないでください。
シナリオの設計段階からデータを保護します。合成データまたは匿名化データを使い、専用の認証情報と最小限の権限を適用してください。適切な根拠と管理策なしに、個人データを負荷テストツールへコピーしないでください。テストによってメール送信、決済、取り消せない影響が発生しないようにします。外部処理にはテスト環境または管理された代替手段を使います。ただし、代替手段では実際のサービスのレイテンシや制限が必ずしも再現されない点に注意してください。
レイテンシ、エラー、飽和を同時に測定する
ルートごとにレイテンシを記録し、p50、p95、p99などのパーセンタイルを確認します。一部のリクエストが非常に遅くなっても、平均値は安定したままの場合があります。パーセンタイルのほうが遅延の裾を把握しやすくなります。エラー率、タイムアウト、単位時間あたりの完了リクエスト数も測定してください。リクエスト数が多くてもエラーも多いテストでは、有効な処理能力を証明できません。
これらの指標をリソースやキューと関連付けます。PHPでは、リクエストを処理するプロセスの使用率とキューに加え、CPU、メモリ、再起動を確認します。PHP-FPMを使用している場合は、そのプロセスとWebサーバーの設定および指標を確認してください。利用可能な指標名は計測方法によって異なります。データベースでは、アクティブな接続数、接続取得待ち、遅いクエリ、ロック、CPUまたはディスクの使用率を測定します。キャッシュ、キュー、外部依存先も確認してください。
CPU使用率だけでなく、ユーザー体験と業務に結び付いたしきい値を設定します。たとえば、購入ルートには合意済みの最大レイテンシとエラー率が必要な一方、重要度の低いエクスポートでは待機や非同期処理が許容される場合があります。時計と観測期間が比較可能であること、またレイテンシの増加と飽和したコンポーネントを関連付けられることを確認してください。
スケールアップの前に最初のボトルネックを特定する
負荷を段階的に増やしたとき、最初に悪化する兆候を探します。Webプロセスのキューが増え、PHPのCPU使用率が高いままなら、リクエストごとの処理が重いか、利用可能なプロセスが不足している可能性があります。プロセスが接続待ちで、データベースには余力があるなら、接続プールの上限や接続設定を確認します。データベースで遅いクエリ、ロック、飽和が見られる場合、PHPプロセスを増やすと負荷が高まり、問題が悪化する可能性があります。
外部依存先もプロセスを占有し続けることがあります。接続時間と応答時間、レート制限、エラー時の挙動を確認します。タイムアウトが長すぎるとリソースが占有され、上限のない再試行は負荷を何倍にもするおそれがあります。適切な場合は段階的な待機を取り入れたうえで、上限のあるタイムアウトと対象を絞った再試行ポリシーを定めます。また、保護策なしに非冪等な処理を自動で繰り返さないでください。
容量不足と非効率を区別します。過剰な行を走査するクエリ、同じサービスへの繰り返しの呼び出し、冗長な計算は、サーバーを追加しても高コストのままです。代表的なルートをプロファイルし、リクエストごとの処理を減らします。根拠に基づいてクエリとインデックスを最適化し、返却件数を制限し、不要な呼び出しをなくし、一貫性とプライバシーが許す範囲でキャッシュを活用します。その後、負荷下でも改善が維持されることを確かめるため、テストを再実行します。
順序立てて対処し、制御された縮退を計画する
まず、リクエストごとの処理コストを減らし、制約となっているクエリや依存先を改善します。次に、同時実行数の上限、Webプロセス、接続プールを見直します。プロセスの増加は並列性を高められますが、CPU、メモリ、データベースが飽和するまでです。データベースが処理できる数を超える接続を設定しても、キューの場所が移るだけです。一度に変更する変数は1つにし、その都度測定し直してください。
垂直スケーリング（インスタンスのリソース増強）は、コンポーネントに拡張余地があり、構造上の上限がなければ、簡単な対処になり得ます。水平スケーリング（インスタンスの追加）では、デプロイ、セッション、ファイル、タスク、データベースが分散に対応している必要があります。該当する場合は、ロードバランシング、共有または外部ストレージ、インスタンスのヘルス、データベース接続などの共通上限を確認してください。どちらの方法も、非効率なクエリを単独で修正するものではありません。
容量が不足したときに何を維持するかを定めます。製品に応じて、認証、重要な処理、トランザクションの確定を優先します。レポートを後回しにし、コストの高い検索を制限し、不可欠ではない機能を一時的に無効にします。後から完了できる処理にはキューを使い、状況をユーザーに伝えてください。レート制限や過負荷時の応答は、慎重な再試行の仕組みとともに明示的に適用します。制御された縮退では、確定済みの処理を失わず、実際には成功していないのに成功を装うことなく、理解しやすい代替手段を提示する必要があります。
テストを運用上の判断につなげるため、シナリオ、構成、ルート別の結果、最初に確認した制約、実施した変更、合格基準を記録します。コード、インフラ、データ、重要な依存先を変更した後は、テストを再実行してください。予測されるピークの前に、アラート、利用可能な容量、ロールバック手順、判断責任者を確認します。
ピーク前のチェックリスト
- シナリオ：ルート、比率、到着ペース、継続時間が現実的で、急激な増加と持続的な負荷の両方を含んでいる。
- 安全性：適切なデータと認証情報を使用し、意図しない実際の影響を防ぎ、テスト先を管理している。
- 可観測性：p95/p99レイテンシ、エラー、スループットをPHPプロセス、データベース、キャッシュ、依存先と関連付けている。
- 診断：最初の制約を特定し、飽和、クエリ、同時実行数、外部待ちのどれが原因かを確認している。
- 変更：一度に1つの原因に対処し、結果を比較し、飽和が別の層へ移っていないことを確認している。
- レジリエンス：確定済みの処理を失わないための制限、優先順位、縮退、通知、復旧を定めている。
- 再テスト：合格基準を定め、重要な変更の後と予測可能なイベントの前に再テストしている。
厳密な容量設計とは、抽象的なユーザー数を追い求めるのではなく、具体的なシナリオでのアプリケーションの応答を把握し、余裕を持って判断することです。測定によって、最適化、同時実行数の調整、容量の追加、重要な機能を有用な状態に保つ縮退ポリシーのうち、どこに投資すべきかが明らかになります。
