서버 부하 감소. 서버 과부하를 피하는 이유와 방법

이 글에서는 서버 부하가 증가하는 이유를 자세히 살펴보고 고부하 프로세스를 최적화하는 다양한 방법을 논의합니다. Apache/Nginx와 MySQL의 코드 최적화에 특별히 주의를 기울이고, 보조 도구로서의 캐싱에 대해 이야기하고, DDOS 공격과 같은 가능한 외부 위협과 이를 방지하는 방법을 고려합니다.

서버 부하가 발생하는 이유

서버 최적화를 진행하기 전에 리소스에 대한 현재 부하를 철저히 분석해야 합니다. 여기에는 CPU 부하, RAM 사용량, 네트워크 활동 및 기타 주요 매개변수를 측정하는 것이 포함됩니다. 역학 및 최대 부하를 이해하면 병목 현상을 식별하고 리소스 할당을 최적화하여 서버 인프라의 안정성과 성능을 높일 수 있습니다.

높은 서버 부하의 초기 문제 해결을 위해서는 다음을 수행하는 것이 좋습니다. 일반 서버 진단. 이것이 충분하지 않으면 더 자세한 자원 분석 필요합니다. 보조 도구로서 탐색 리눅스의 로그 문제의 근원은 대부분 서버에서 발견되므로 서버가 도움이 될 수 있습니다.

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)"

부하를 줄이기 위한 첫 번째 해결책으로 메타 태그 설정을 사용할 수 있습니다. "인덱스 없음" 및 "nofollow" 인덱싱할 필요가 없는 페이지에서. 두 번째 솔루션은 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의 경우 전자가 더 바람직합니다.

에 아파치 서버를 열어야 합니다. .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

그 후, 웹 서버를 다시 시작하세요.

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

이러한 설정을 사용하면 허용 및 거부 지시가 무시됩니다.

데이터 압축 사용

데이터 압축을 사용하여 활성화 Gzip Apache 및 Nginx 웹 서버에서는 서버와 클라이언트 간에 전송되는 데이터 양을 줄이는 데 도움이 되며, 이로 인해 성능이 향상되고 웹 페이지 로딩 시간이 단축됩니다.

사용하려면 Gzip on 아파치, 당신은 활성화해야 모드 디플레이트 기준 치수:

sudo a2enmod deflate

그런 다음 웹 서버를 다시 시작합니다.

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;

유사하게 아파치, 여기서 특정 유형의 파일에 대한 압축 매개변수가 설정됩니다. 웹 서버를 변경한 후에는 서비스 재로드가 필요합니다.

sudo service apache2 restart

sudo service nginx restart

서버에 대한 DDOS 공격

DDoS 공격으로 인해 서버 부하가 높아질 수 있습니다. DDoS 공격의 존재를 식별하려면 트래픽의 급격한 증가, 비정상적인 요청, 서버 성능 저하를 모니터링해야 합니다. 한 IP 주소에서 반복되는 요청이나 포트 스캐닝에 대한 로그를 검토하면 DDoS 공격이 있을 가능성이 있음을 나타낼 수도 있습니다. 보호 조치는 많지만 기본적인 사항만 설명하겠습니다.

CDN(Contents Delivery Network) 사용. CDN은 웹 서버와 사용자 사이의 중개자 역할을 하여 트래픽을 분산하고 콘텐츠를 캐싱하여 DDoS 공격의 영향을 완화할 수 있습니다. CDN은 부하 분산 및 트래픽 필터링을 포함한 내장형 DDoS 보호 메커니즘을 가질 수도 있습니다.

방화벽 및 침입 탐지 시스템(IDS/IPS) 구성. 방화벽은 IP 주소 및 포트와 같은 다양한 기준에 따라 트래픽을 필터링하도록 구성할 수 있습니다. IDS/IPS는 비정상적인 트래픽 동작을 감지하고 의심스러운 연결을 차단할 수 있습니다. 이러한 도구는 잠재적으로 악의적인 트래픽을 추적하고 차단하는 데 효과적일 수 있습니다.

DDoS 공격의 영향을 완화하기 위해 Apache 및 Nginx 웹 서버를 구성합니다.

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 데이터베이스 쿼리를 최적화하는 것은 다양한 방법으로 달성할 수 있으며, 그 중 하나는 구성 파일을 적절하게 구성하는 것입니다. 일반적으로 이 파일의 이름은 다음과 같습니다. 내.cnf or my.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 쿼리 전에 명령을 사용하여 실행을 분석합니다. 이를 통해 쿼리에 대한 실행 계획을 얻고 어떤 인덱스를 사용하고 어떤 테이블을 스캔하는지 등을 결정할 수 있습니다.
인덱스는 데이터 검색 속도를 높여 주므로 적절하게 설계된 인덱스는 쿼리 성능을 크게 향상시킬 수 있습니다. 자주 사용되는 열에 주의하세요. WHERE or JOIN 조건.
사용을 피하십시오 고르다 *테이블의 모든 열을 선택하는 대신, 쿼리에 정말 필요한 열만 지정하세요.
함수 사용을 피하세요 WHERE 조건. 함수 사용(예: 보다 낮은, 높은, 왼쪽, 권리) in WHERE 조건은 인덱스를 쓸모없게 만들 수 있습니다. 조건에서 직접 사용하는 것은 피하세요.
내부 결합 가능한 경우, 보통 더 효율적이기 때문입니다. 또한 조인에 해당하는 열에 인덱스가 있는지 확인합니다.
제한 특정 수의 결과만 얻어야 하는 경우 반환되는 행의 수를 제한합니다.
특히 쿼리 결과가 거의 변경되지 않는 경우, 서버 부하를 줄이기 위해 쿼리 결과를 캐싱하는 것을 고려하세요.

메일 서버가 서버에 높은 부하를 발생시킵니다

이 섹션에서는 메일 서버가 높은 부하를 겪고 있는지 확인하는 방법과 메시지 큐를 확인하고 서버 매개변수를 구성하는 것을 포함하여 해당 작업을 최적화하기 위해 취할 수 있는 단계를 살펴보겠습니다. 메시지 큐를 확인하는 것으로 시작합니다. 메일 유틸리티를 사용하면 도움이 될 수 있습니다. 활성화하려면 터미널에 해당 명령을 입력하세요.

mailq

이렇게 하면 대기열에 있는 메시지 목록이 표시됩니다(있는 경우). 각 메시지는 고유 식별자와 전송 상태에 대한 정보와 함께 표시됩니다. 메일 클라이언트 로그를 검토하면 비슷한 결과를 얻을 수 있습니다.

대부분의 경우, 스팸을 보내기 시작할 때 서버가 손상되면 높은 부하가 발생합니다. 그러나 관리자가 확인한 후 서버가 외부에서 공격을 받지 않았고 사용자가 스팸을 무시하지 않는다고 확신하는 경우 메일 서버를 최적화할 때입니다. 도움이 되는 단계는 다음과 같습니다.

도메인의 DNS 레코드가 올바르게 구성되었는지 확인하세요. SPF, 디킴및 DMARC 메일 전달을 개선하고 스팸으로부터 보호하기 위한 기록. 매개변수의 올바른 구성은 다음 문서에서 찾을 수 있습니다. 메일 서버 진단.
방화벽 구성 및 라우팅 규칙을 비롯한 네트워크 설정을 확인하여 차단을 방지하고 메일 배달 속도를 높이세요.
서버 부하에 따라 메시지 큐 매개변수를 구성합니다. 여기에는 최대 큐 크기와 시간 초과 설정이 포함될 수 있습니다.
이 글에서 앞서 논의한 솔루션을 고려해 보세요. 메일 서버 데이터베이스를 주기적으로 최적화하여 성능을 개선하고, 캐싱 메커니즘을 사용하여 DNS 쿼리와 같은 데이터 검색 및 처리 속도를 높입니다.
메일 서버에 지속적으로 높은 부하가 발생하는 경우, 메일 서버 클러스터나 클라우드 솔루션을 사용하는 등의 확장 옵션을 고려하세요.

결론

서버 부하가 증가하면 웹사이트 로딩 속도에 직접적인 영향을 미쳐 궁극적으로 검색 엔진에서 사용자 경험과 평판에 영향을 미칩니다. 따라서 이 부하를 효과적으로 관리하는 것은 리소스의 지속적인 기능을 보장하고 방문자의 접근성을 높이는 데 중요한 역할을 합니다.

❮ 이전 기사 서버 부하 진단

다음 기사 ❯ Certbot: Let's Encrypt 인증서 설치

서버 부하 감소