このページは Cloud Translation API によって翻訳されました。

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

サーバーのボトルネックを特定してすばやく解消し、パフォーマンスを向上させ、問題の発生を防ぐ方法。

Katie Hempenius

概要

このガイドでは、次の 4 つの手順でサーバーのオーバーロードを修正する方法について説明します。

評価: サーバーのボトルネックを特定します。
安定化: 影響の軽減に役立つ簡単な修正を実施します。
改善: サーバー機能を拡張して最適化する。
モニタリング: 自動化ツールを使用して、今後の問題を防ぐことができます。

評価

トラフィックがサーバーを過負荷状態にすると、CPU、ネットワーク、メモリ、ディスク I/O のいずれかまたは複数がボトルネックになる可能性があります。ボトルネックとなっている原因を特定することで、最も効果的な緩和策に集中できます。

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 によってキャッシュに保存されていない場合は、次の条件が満たされていることを確認します。

Cache-Control: public ヘッダーがある。
Cache-Control: s-maxage、Cache-Control: max-age、または Expires ヘッダーがある。
Content-Length、Content-Range、Transfer-Encoding header のいずれかがある。

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

コンピューティングリソースをスケーリングするかどうかは慎重に判断する必要があります。コンピューティングリソースをスケーリングすることが多くの場合必要ですが、早急にスケーリングすると、不要なアーキテクチャの複雑さと費用が発生する可能性があります。

診断

Time To First Byte（TTFB）が高い場合は、サーバーの容量が近づいていることを示している可能性があります。この情報は、Lighthouse のサーバーレスポンス時間（TTFB）を短縮する監査で確認できます。

詳細を調査するには、モニタリングツールを使用して CPU 使用率を評価します。現在の CPU 使用率または予想される CPU 使用率が 80% を超える場合は、サーバーの増加を検討する必要があります。

修正

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

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

圧縮を有効にする

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

診断

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

修正

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

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

ほとんどのウェブサイトのファイルサイズの大部分は画像で占められています。画像を最適化すると、サイトのサイズを迅速かつ大幅に削減できます。

診断

Lighthouse には、画像の最適化の可能性を示すさまざまな監査があります。また、DevTools を使用してサイズの大きい画像ファイルを特定することもできます。これらの画像は最適化の候補として適しています。

修正

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

サイズが大きく頻繁に読み込まれる画像を特定し、Squoosh などのツールで手動で最適化することに時間を割いてください。ヘッダー画像は、多くの場合最適化の対象となります。

注意事項:

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

時間がある場合…

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

その他の情報:

JS と CSS を圧縮する

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

診断

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

修正

時間に余裕がない場合は、JavaScript の圧縮に重点を置きます。ほとんどのサイトでは JavaScript の方が CSS よりも多く、影響は大きくなります。

モニタリング

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

モニタリング設定はできる限りシンプルにする必要があります。データの収集とアラートの過剰にはコストがかかります。データ収集の範囲や頻度が大きいほど、収集と保存にかかる費用は高くなります。アラートを過剰に設定すると、ページが無視されるようになります。

アラートでは、問題を継続的かつ正確に検出する指標を使用する必要があります。サーバー応答時間（レイテンシ）は、この目的に特に適した指標です。さまざまな問題を検出し、ユーザーエクスペリエンスと直接関連しています。CPU 使用率などの下位レベルの指標に基づくアラートは、補足として有用ですが、検出される問題のサブセットは小さくなります。また、アラート設定は平均ではなく、末端（95 パーセンタイルまたは 99 パーセンタイル）で観測されたパフォーマンスに基づく必要があります。平均値では、すべてのユーザーに影響していない問題が簡単に見落とされてしまいます。

修正

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

手順: