サーバー負荷の軽減。サーバーの過負荷を回避する理由と方法

この記事では、サーバーの負荷が増加する理由を詳しく調べ、高負荷プロセスを最適化するさまざまな方法について説明します。Apache/Nginx と MySQL のコード最適化に特に重点を置き、補助ツールとしてのキャッシュについて説明します。また、DDOS 攻撃などの外部からの脅威の可能性と、それを防ぐ方法についても検討します。

サーバー負荷が発生する理由

サーバーの最適化に進む前に、リソースの現在の負荷を徹底的に分析する必要があります。これには、CPU 負荷、RAM 使用量、ネットワークアクティビティ、その他の重要なパラメータの測定が含まれます。ダイナミクスとピーク負荷を理解することで、ボトルネックを特定し、リソース割り当てを最適化できるため、サーバーインフラストラクチャの安定性とパフォーマンスが向上します。

サーバー負荷が高い場合の初期トラブルシューティングでは、一般的なサーバー診断. これで不十分な場合は、より詳細なリソースの分析補助的なツールとして、 Linuxのログほとんどの場合、問題の原因はサーバー上で見つかるため、サーバーが役に立つことがあります。

Apache/Nginx サーバーの最適化

インデックス作成によるサーバー負荷の増加

たとえば、検索エンジンがサイト上の多数のページをスキャンすると、サーバー上のインデックス作成による負荷の増加が発生する可能性があります。これにより、サーバーリソースの使用が増加し、結果としてサイトのパフォーマンスが低下する可能性があります。原因を特定するのは比較的簡単です。次の場所にあるファイルを開く必要があります。

/var/www/httpd-logs/sitename.access.log

検索エンジンによってインデックスされると、ユーザーには次の性質のエントリが表示されます。

11.22.33.44 - - [Date and Time] "GET /your-page-path HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

負荷を軽減するための最初の解決策として、メタタグの設定を使用することができます。 「インデックスなし」 (NAIST) と 「ノーフォロー」 インデックス登録する必要のないページに。2つ目の解決策は .htaccess ファイルには、たとえば Yandex や Google から非表示にするために、特定の検索エンジンに対応するエントリを追加する必要があります。

SetEnvIfNoCase User-Agent "^Yandex" search_bot
SetEnvIfNoCase User-Agent "^Googlebot" search_bot
Order Allow,Deny
Allow from all
Deny from env=search_bot

同様に、他の検索エンジンでも編集が必要です。.htaccessの機能はインデックス作成をブロックするだけに限定されないことに注意してください。記事.

キャッシュ設定の使用

サーバーのキャッシュ設定が間違っていると、負荷が高くなることもあります。このパラメータを最適化するには、設定ファイルまたは .htaccessApache の場合は後者のオプションが適しており、Nginx の場合は前者のオプションが適しています。

オン アパッチ サーバーを開くには、 .htacess ファイルを開いて次のコードを挿入します。

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

次に、を有効にします期限次のコマンドを使用してモジュールを実行します:

sudo a2enmod expires

その後、Web サーバーを再起動します。

sudo service apache2 restart

次を指定してモジュールをアクティブ化します。

ExpiresActive On

上の nginx サーバーの場合は、構成ファイルに次のコードを追加するだけで十分です。

location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ {
root /var/www/yoursite.com;
}

サービスのリロードを実行します。

sudo service nginx restart

これらの設定では、 許可する (NAIST) と 否定する ディレクティブはバイパスされます。

データ圧縮の使用

データ圧縮を有効にする Gzip Apache および Nginx Web サーバーでは、サーバーとクライアント間で送信されるデータの量が削減されるため、パフォーマンスが向上し、Web ページの読み込み時間が短縮されます。

有効にする Gzip on アパッチ、アクティブ化する必要があります mod_deflate モジュール：

sudo a2enmod deflate

次に、Web サーバーを再起動します。

sudo service apache2 restart

最後に、設定ファイルまたは .htaccess に次のブロックを追加します。

<IfModule mod_deflate.c>
# Configure compression for specified file types
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/json

# If the browser matches the specified pattern, apply compression only to text/html files
BrowserMatch ^Mozilla/4 gzip-only-text/html

# If the browser matches the specified version patterns of Mozilla 4.0.6, 4.0.7, 4.0.8, disable compression
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# If the browser is MSIE (Internet Explorer), disable compression for all files except text/html
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# If the request contains the specified pattern (extensions of image files), disable compression
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
</IfModule>

この構成では、特定の種類のファイルの圧縮が有効になり、画像の圧縮が無効になります。

の場合には nginx、構成は HTTP 構成ファイルのブロック。次のコードを追加する必要があります。

gzip on;
gzip_disable "msie6";

# Adds the Vary header, indicating that the response may change depending on the Accept-Encoding header value
gzip_vary on;

# Enables compression for any proxy servers
gzip_proxied any;

# Sets the compression level. A value of 6 provides a good balance between compression efficiency and resource use
gzip_comp_level 6;

# Sets the size of the buffer for compressed data (16 buffers of 8 kilobytes each)
gzip_buffers 16 8k;

# Specifies that data compression should be used only for HTTP version 1.1 and higher
gzip_http_version 1.1;

# Sets the file types that can be compressed
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

そして アパッチここでは、特定の種類のファイルの圧縮パラメータが設定されます。いずれかの Web サーバーに変更を加えた後は、サービスの再読み込みが必要です。

sudo service apache2 restart

sudo service nginx restart

サーバーへのDDOS攻撃

DDoS 攻撃により、サーバーの高負荷が発生する可能性があります。DDoS 攻撃の存在は、トラフィックの急激な増加、異常なリクエスト、サーバーのパフォーマンス低下を監視することで特定できます。ログを確認して、1 つの IP アドレスからの繰り返しのリクエストやポートスキャンを確認することで、DDoS 攻撃の可能性を示すこともできます。保護対策は多数ありますが、ここでは基本的なものだけを説明します。

CDN（コンテンツ配信ネットワーク）の使用CDN は、Web サーバーとユーザーの間の仲介役として機能し、トラフィックを分散してコンテンツをキャッシュすることで、DDoS 攻撃の影響を軽減します。CDN には、負荷分散やトラフィックフィルタリングなどの DDoS 保護メカニズムも組み込まれています。

ファイアウォールと侵入検知システム (IDS/IPS) の設定ファイアウォールは、IP アドレスやポートなどのさまざまな基準に基づいてトラフィックをフィルタリングするように設定できます。IDS/IPS は、異常なトラフィック動作を検出し、疑わしい接続をブロックできます。これらのツールは、潜在的に悪意のあるトラフィックを追跡してブロックするのに効果的です。

DDoS 攻撃の影響を軽減するために Apache および Nginx Web サーバーを構成します。

Apacheのソリューションとして、 mod_evasive モジュール。これを行うには、次の行をコメント解除するか追加します。 httpd.conf or apache2.conf 設定ファイル：

LoadModule evasive20_module modules/mod_evasive.so

同じファイル内に、設定ブロックを追加する必要があります。

<IfModule mod_evasive20.c>
# Hash table size for storing request information
DOSHashTableSize 3097

# Number of requests to one page before activating protection
DOSPageCount 2
DOSPageInterval 1

# Number of requests to all pages before activating protection
DOSSiteCount 50
DOSSiteInterval 1

# Blocking period in seconds for IP addresses
DOSBlockingPeriod 10
</IfModule>

同様に、 mod_ratelimit モジュール：

LoadModule ratelimit_module modules/mod_ratelimit.so

設定を追加します:

<IfModule mod_ratelimit.c>
# Setting the output filter for rate limiting (Rate Limit)
SetOutputFilter RATE_LIMIT

# Beginning of the settings block for the location "/login"
<Location "/login">

# Setting the environment variable rate-limit with a value of 1
SetEnv rate-limit 1

# Ending of the settings block for the location "/login"
</Location>
</IfModule>

の構成 nginx に似ています アパッチ。の中に nginx.conf 構成ファイルでは、次のディレクティブを使用する必要があります。

http {
...
# Defining a zone for connection limits
limit_conn_zone $binary_remote_addr zone=addr:10m;

# Defining a zone for request limits
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s;

server {
        ...
        # Configuring connection limits
        limit_conn addr 10;

        # Configuring request limits
        limit_req zone=req_zone burst=5;

        ...
    }
}

各サービスに変更を加えた後は、それらを再ロードする必要があります。

sudo systemctl restart apache2

または：

sudo systemctl restart nginx

これらの例は基本的な構成のみを提供しており、特定の要件や攻撃の性質に応じてさらに調整することができます。

MySQLクエリの最適化

ウェブサーバー上のMySQLデータベースクエリを最適化するにはさまざまな方法がありますが、その1つは設定ファイルを適切に設定することです。通常、このファイルの名前は my.cnf or 私の.ini にあります /等/ or /etc/mysql/ ディレクトリを開きます。それを開いて、次の変更を加える必要があります。

[mysqld]
# Location of the file for recording slow queries. Be sure to replace it with your path
log-slow-queries = /var/log/mariadb/slow_queries.log

# Threshold time for considering slow queries (in seconds)
long_query_time = 5

# Enabling recording of queries that do not use indexes
log-queries-not-using-indexes = 1

# Disabling query caching
query_cache_size = 0
query_cache_type = 0
query_cache_limit = 1M

# Size of temporary tables
tmp_table_size = 16M
max_heap_table_size = 16M

# Size of the thread cache
thread_cache_size = 16

# Disabling name resolving
skip-name-resolve = 1

# Size of the InnoDB buffer pool. Set to 50-70% of available RAM
innodb_buffer_pool_size = 800M

# Size of the InnoDB log file
innodb_log_file_size = 200M

サーバーデータベースとのやり取りを容易にする追加の推奨事項も検討しましょう。

説明する SQL クエリの前にコマンドを実行して、その実行を分析します。これにより、クエリの実行プランを取得し、どのインデックスが使用されているか、どのテーブルがスキャンされているかなどを判断できます。
インデックスはデータ検索を高速化するため、適切に設計されたインデックスはクエリのパフォーマンスを大幅に向上させることができます。 NeoCity or 登録条件。
使用を避ける SELECT *テーブル内のすべての列を選択するのではなく、クエリに本当に必要な列のみを指定します。
関数の使用を避ける NeoCity 条件。関数（ LOWER, アッパー, LEFT, RIGHT）in NeoCity 条件によってインデックスが役に立たなくなる可能性があります。条件内で直接使用することは避けてください。
　 INNER JOINは 通常はより効率的であるため、可能な場合はそうしてください。また、結合する対応する列にインデックスがあることを確認してください。
　 LIMIT 特定の数の結果のみを取得する必要がある場合は、返される行の数を制限します。
特にクエリ結果がほとんど変更されない場合は、サーバーの負荷を軽減するために、クエリ結果をキャッシュすることを検討してください。

メールサーバーはサーバーに高い負荷をかける

このセクションでは、メールサーバーの負荷が高いかどうかを判断する方法と、メッセージキューの確認やサーバーパラメータの設定など、メールサーバーの動作を最適化するために実行できる手順について説明します。まずはメッセージキューの確認から始めましょう。 mailq ユーティリティはこれに役立ちます。これを有効にするには、ターミナルで対応するコマンドを入力します。

mailq

キュー内のメッセージがある場合は、そのリストが表示されます。各メッセージは、一意の識別子と送信ステータスに関する情報とともに表示されます。メールクライアントのログを確認することでも同様の結果を得ることができます。

ほとんどの場合、高負荷は、サーバーが侵害されてスパムを送信し始めたときに発生します。ただし、管理者が確認した後、サーバーが外部から攻撃されておらず、ユーザーがスパムを無視していないと確信した場合は、メールサーバーの最適化に進む必要があります。役立つ手順は次のとおりです。

ドメインのDNSレコードが正しく設定されていることを確認してください。 SPF, dkim 拡張子, DMARC メール配信を改善し、スパムから保護するために、レコードを設定します。パラメータの正しい設定については、メールサーバ診断.
ブロックを回避し、メールの配信を高速化するには、ファイアウォールの構成やルーティングルールなどのネットワーク設定を確認します。
サーバーの負荷に応じてメッセージキューパラメータを構成します。これには、最大キューサイズとタイムアウトの設定が含まれる場合があります。
この記事で以前に説明したソリューションを検討してください。メールサーバーのデータベースを定期的に最適化してパフォーマンスを向上させ、キャッシュメカニズムを使用して DNS クエリなどのデータの検索と処理を高速化します。
メールサーバーが引き続き定期的に高負荷に遭遇する場合は、メールサーバーのクラスターやクラウドソリューションの使用などのスケーリングオプションを検討してください。

結論

サーバー負荷の増加はウェブサイトの読み込み速度に直接影響し、最終的にはユーザーエクスペリエンスと検索エンジンでの評判に影響を及ぼします。したがって、この負荷を効果的に管理することは、リソースの継続的な機能性を確保し、訪問者のアクセシビリティを向上させる上で重要な役割を果たします。

❮ 前の記事 Certbot: Let's Encrypt 証明書のインストール

次の記事❯ サーバー負荷診断

サーバー負荷の軽減