過負荷状態のサーバーを修正する

サーバーのボトルネックを特定する方法、ボトルネックを迅速に解決する方法、サーバーのパフォーマンスを向上させる方法、回帰を防ぐ方法。

Katie Hempenius
Katie Hempenius
X

概要

このガイドでは、サーバーの過負荷を 4 つのステップで解決する方法を説明します。

  1. 評価: サーバーのボトルネックを判断します。
  2. 安定化: 影響を軽減するためにクイック修正を実装します。
  3. 改善: サーバー機能を強化し、最適化します。
  4. モニタリング: 自動化ツールを使用して今後の問題が発生しないようにします。

評価

トラフィックがサーバーに過負荷になると、CPU、ネットワーク、メモリ、ディスク I/O のうち 1 つ以上がボトルネックになる可能性があります。これらのうちどれがボトルネックであるかを特定すると、最も影響の大きい緩和策に重点を置くことができます。

  • CPU: CPU 使用率が常に 80% を超えている場合は、調査して修正する必要があります。サーバーのパフォーマンスは、CPU 使用率が 80 ～ 90% に達すると低下することが多く、使用率が 100% に近づくにつれて顕著になります。1 つのリクエストを処理する場合の CPU 使用率はごくわずかですが、トラフィックの急増時に発生した規模でこれを実行すると、サーバーに負荷がかかる可能性があります。他のインフラストラクチャへのサービス提供のオフロード、コストの高いオペレーションの削減、リクエストの量の制限により、CPU 使用率は低下します。
  • ネットワーク: トラフィックが多い期間中、ユーザー リクエストの処理に必要なネットワーク スループットが容量を超えることがあります。ホスティング プロバイダによっては、累積データ転送に関する上限に達するサイトもあります。サーバーとの間で送受信されるデータのサイズと量を減らすことで、このボトルネックを解消できます。
  • メモリ: システムに十分なメモリがない場合、データはストレージのためにディスクにオフロードする必要があります。ディスクはメモリよりもアクセスがかなり遅く、アプリケーション全体の速度が低下する可能性があります。メモリが枯渇すると、メモリ不足（OOM）エラーが発生する可能性があります。メモリ割り当ての調整、メモリリークの修正、メモリのアップグレードを行うことで、このボトルネックを解消できます。
  • ディスク I/O: ディスクのデータの読み取りと書き込みが可能なレートは、ディスク自体によって制約されます。ディスク I/O がボトルネックの場合、メモリにキャッシュされるデータの量を増やすと、この問題を軽減できます（メモリ使用率が増加します）。それでも問題が解決しない場合は、ディスクのアップグレードが必要になることがあります。

このガイドでは、CPU とネットワークのボトルネックへの対処に焦点を当てています。ほとんどのサイトでは、トラフィックの急増時に最も関連性の高いボトルネックが CPU とネットワークになります。

ボトルネックを調査するには、影響を受けるサーバーで top を実行することをおすすめします。可能な場合は、ホスティング プロバイダやモニタリング ツールの過去のデータで補完します。

P-MAX 導入済み部門の

サーバーが過負荷になると、すぐにシステムの他の場所でカスケード障害につながる可能性があります。そのため、大きな変更を加える前にサーバーを安定させることが重要です。

レート制限

レート制限は、受信リクエスト数を制限することでインフラストラクチャを保護します。これは、サーバーのパフォーマンスが低下するほど重要になります。応答時間が長くなるにつれ、ユーザーは頻繁にページを更新する傾向があり、サーバーの負荷はさらに高くなります。

解決方法

リクエストを拒否することは比較的低コストですが、サーバーを保護する最善の方法は、ロードバランサ、リバース プロキシ、CDN などを使用して、その上流側でレート制限を処理することです。

手順:

その他の情報:

HTTP キャッシュ

コンテンツをより積極的にキャッシュする方法を検討します。リソースを HTTP キャッシュ（ブラウザ キャッシュまたは CDN）から提供できる場合は、送信元サーバーからリクエストする必要がないため、サーバーの負荷が軽減されます。

Cache-Control、Expires、ETag などの HTTP ヘッダーは、HTTP キャッシュによってリソースがキャッシュに保存される方法を示しています。これらのヘッダーを監査して修正すると、キャッシュ保存が改善されます。

Service Worker はキャッシュ保存にも使用できますが、別のキャッシュを利用します。これは、適切な HTTP キャッシュに代わるものではなく、補足的なものです。このため、過負荷のサーバーを処理するときは、HTTP キャッシュの最適化に重点を置く必要があります。

診断

Lighthouse を実行し、効率的なキャッシュ ポリシーを使用して静的アセットを提供する監査で、有効期間（TTL）が短いリソースのリストを表示します。リストされたリソースごとに、TTL を増やす必要があるかどうかを検討します。大まかなガイドラインは次のとおりです。

  • 静的リソースは、長い TTL（1 年）でキャッシュに保存する必要があります。
  • 動的リソースは短い TTL（3 時間）でキャッシュに保存する必要があります。

解決方法

Cache-Control ヘッダーの max-age ディレクティブを適切な秒数に設定します。

手順:

グレースフル デグラデーション

グレースフル デグラデーションとは、システムの過剰な負荷を軽減するために一時的に機能を制限する戦略です。この概念は、フル機能のアプリケーションの代わりに静的なテキストページを表示する、検索を無効にする、検索結果を減らす、特定の高価な機能や必須ではない機能を無効にするなど、さまざまな方法で適用できます。ビジネスへの影響を最小限に抑えながら安全かつ簡単に削除できる機能を削除することに重点を置くべきです。

改善

コンテンツ配信ネットワーク（CDN）を使用する

静的アセットの提供をサーバーからコンテンツ配信ネットワーク（CDN）にオフロードすることで、負荷を軽減できます。

CDN の主な機能は、ユーザーの近くに配置されたサーバーからなる大規模なネットワークを提供することで、ユーザーにコンテンツを迅速に配信することです。ただし、ほとんどの CDN は、圧縮、ロード バランシング、メディア最適化など、パフォーマンス関連の追加機能も提供しています。

CDN を設定する

CDN はスケールの恩恵を受けるため、独自の CDN を運用することはほとんど意味がありません。基本的な CDN 構成は、かなり短時間で（約 30 分）設定でき、CDN を指すように DNS レコードを更新することで構成されます。

CDN の使用状況を最適化する

診断

WebPageTest を実行して、CDN から配信されていない（必要であるものの）リソースを特定します。結果ページで、[CDN の効果的な使用] の上にある正方形をクリックして、CDN から提供する必要があるリソースのリストを表示します。

[CDN の効果的な利用] ボタンを指す矢印
WebPageTest の結果

解決方法

リソースが CDN によってキャッシュに保存されていない場合は、次の条件が満たされていることを確認します。

コンピューティング リソースのスケーリング

コンピューティング リソースのスケーリングは慎重に判断する必要があります。多くの場合、コンピューティング リソースのスケーリングが必要ですが、それより早くこれを行うと、アーキテクチャが不必要に複雑になり、財務コストがかかる可能性があります。

診断

最初のバイトまでの時間（TTFB）が高い場合は、サーバーの処理能力が上限に近づいている可能性があります。この情報は、Lighthouse のサーバー応答時間の短縮（TTFB）の監査で確認できます。

さらに調査するには、モニタリング ツールを使用して CPU 使用率を評価します。現在または予想される CPU 使用率が 80% を超える場合は、サーバーを増やすことを検討してください。

解決方法

ロードバランサを追加すると、トラフィックを複数のサーバーに分散できます。ロードバランサはサーバープールの前面に配置され、トラフィックを適切なサーバーにルーティングします。クラウド プロバイダは独自のロードバランサ（GCP、AWS、Azure）を提供するか、HAProxy または NGINX を使用して独自のロードバランサを設定できます。ロードバランサを設定すると、サーバーを追加できます。

ほとんどのクラウド プロバイダは、ロード バランシングの他にも自動スケーリング（GCP、AWS、Azure）を提供しています。自動スケーリングはロード バランシングと連携して機能します。自動スケーリングは、特定の期間の需要に応じてコンピューティング リソースを自動的にスケールアップまたはスケールダウンします。とはいえ、自動スケーリングは魔法のようなものではありません。新しいインスタンスがオンラインになるまでには時間がかかり、かなりの構成が必要です。自動スケーリングでは複雑さが増すため、まず、より簡単なロードバランサ ベースの設定を検討する必要があります。

圧縮を有効にする

テキストベースのリソースは、gzip または brotli を使用して圧縮する必要があります。Gzip を使用すると、これらのリソースの転送サイズを最大 70% 削減できます。

診断

Lighthouse の「テキスト圧縮を有効にする」監査を使用して、圧縮が必要なリソースを特定します。

解決方法

サーバー設定を更新して圧縮を有効にします。手順:

画像とメディアを最適化する

ほとんどのウェブサイトでは、ファイルサイズの大部分を画像で占めます。画像を最適化すると、サイトのサイズをすばやく大幅に削減できます。

診断

Lighthouse には、画像の最適化の余地があることを示すさまざまな監査機能があります。あるいは、DevTools を使用して最も大きな画像ファイルを特定するという方法もあります。このような画像は最適化の候補として適している可能性があります。

関連する Lighthouse の監査:

Chrome DevTools のワークフロー:

解決方法

時間が限られている場合...

Squoosh などのツールを使って、サイズの大きい画像や頻繁に読み込まれる画像を特定して手動で最適化することに集中しましょう。多くの場合、ヒーロー画像は最適化に適しています。

注意事項:

  • サイズ: 必要以下のサイズにしてください。
  • 圧縮：一般的に、品質レベルが 80 ～ 85 の場合、画質への影響は最小限に抑えられ、ファイルサイズは 30 ～ 40% 削減されます。
  • 形式: 写真には PNG ではなく JPEG を使用します。アニメーション コンテンツには GIF ではなく MP4 を使用します。

時間があれば...

画像によってサイトの大部分が構成されている場合は、画像 CDN の設定を検討してください。Image CDN は画像の配信と最適化を目的として設計されており、配信元サーバーからの画像配信をオフロードします。画像 CDN の設定は簡単ですが、画像 CDN を指すように既存の画像 URL を更新する必要があります。

その他の情報:

JS と CSS を圧縮する

圧縮すると、JavaScript と CSS から不要な文字が削除されます。

診断

Lighthouse の監査項目として CSS の圧縮と Minify JavaScript を使用して、圧縮が必要なリソースを特定します。

解決方法

時間が限られている場合は、JavaScript の圧縮に集中しましょう。ほとんどのサイトには CSS よりも JavaScript の比率が高いため、こちらの方が効果は大きくなります。

モニタリング

サーバー モニタリング ツールは、サーバーのパフォーマンスに関するデータ収集、ダッシュボード、アラート機能を提供します。これらのリソースを使用することで、今後のサーバー パフォーマンスの問題を防止し、軽減できます。

モニタリングの設定は、できるだけシンプルにする必要があります。過剰なデータの収集とアラートには代償が伴います。データ収集の範囲や頻度が高いほど、収集と保存のコストが高くなります。過剰なアラートは必然的に無視されてしまいます。

アラートでは、問題を一貫して正確に検出する指標を使用する必要があります。サーバーの応答時間（レイテンシ）は、この状況で特に有効な指標です。さまざまな問題を検出でき、ユーザー エクスペリエンスに直接関係します。CPU 使用率などの下位レベルの指標に基づくアラートを補足すると便利ですが、捕捉できる問題はそれほど多くありません。また、アラートは、平均ではなく、テール（95 パーセンタイルまたは 99 パーセンタイル）で観測されるパフォーマンスに基づいている必要があります。そうしないと、すべてのユーザーに影響するとは限らない問題が平均値で見にくくなります。

解決方法

主要なクラウド プロバイダはすべて、独自のモニタリング ツールを提供しています（GCP、AWS、Azure）。さらに、Netdata は無料のオープンソースの優れた代替手段です。どのツールを選択する場合でも、モニタリング対象の各サーバーにツールのモニタリング エージェントをインストールする必要があります。完了したら、アラートを設定します。

手順: