サーバー負荷の軽減

この記事では、サーバーの負荷が増加する理由を詳しく調べ、高負荷プロセスを最適化するさまざまな方法について説明します。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)"

負荷を軽減するための最初の解決策として、インデックス登録する必要のないページにメタタグ「noindex」と「nofollow」を設定する方法があります。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 の機能はインデックス登録のブロックだけにとどまらないことに注意してください。記事でその主な機能について詳しく知ることをお勧めします。

キャッシュ設定の使用

サーバーのキャッシュ設定が不適切だと、負荷が高くなる原因にもなります。このパラメータを最適化するには、設定ファイルまたは.htaccessファイルに適切な変更を加える必要があります。Apacheの場合は後者の方法が、Nginxの場合は前者の方法が推奨されます。

Apacheサーバーでは、 .htaccessファイルを開き、以下のコードを挿入する必要があります。

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

次に、以下のコマンドを使用してExpiresモジュールを有効にします。

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

これらの設定では、AllowおよびDenyディレクティブは無視されることに注意してください。

データ圧縮の使用

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

ApacheでGzipを有効にするには、 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;

Apacheと同様に、ここでは特定の種類のファイルの圧縮パラメータが設定されます。Webサーバーに変更を加えた後は、サービスの再起動が必要です。

sudo service apache2 restart

Or

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または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の設定方法はApacheと似ています。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クエリの最適化

Webサーバー上でMySQLデータベースクエリを最適化する方法はいくつかありますが、その一つが設定ファイルの適切な設定です。通常、このファイルはmy.cnfまたはmy.iniという名前で、 /etc/または/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

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

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

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

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

mailq

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

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

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

結論

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