기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
의 WordPress 인스턴스에 대한 팁 및 모범 사례 Amazon Lightsail
이 가이드에서는 WordPress 인스턴스를 Amazon Lightsail 빠르고 안정적이며 안전하게 유지하기 위한 실용적인 팁을 수집합니다.
사이트를 안전하게 최신 상태로 유지
WordPress, 테마 및 플러그인 업데이트 유지
-
WordPress 코어, 테마 및 플러그인 업데이트를 즉시 적용합니다. 업데이트에는 성능 및 보안 수정이 포함되는 경우가 많습니다. 자세한 내용은 업데이트 관리를 통한 Lightsail 인스턴스 및 컨테이너 보안 유지를 참조하세요.
-
사용하지 않는 플러그인과 테마를 제거합니다. 비활성 플러그인은 여전히 유지 관리 오버헤드와 보안 표면을 추가하며 잘못 작성된 플러그인은 높은 메모리 사용량의 빈번한 원인입니다.
-
라이브 사이트에 적용하기 전에 스냅샷에서 시작한 인스턴스 사본에 대한 주요 업데이트를 테스트합니다.
변경하기 전에 백업
구성 파일을 편집하거나 플러그인을 설치하기 전에 인스턴스의 스냅샷을 생성하여 문제가 발생할 경우 스냅샷에서 애플리케이션을 쉽게 복원할 수 있습니다.
-
Lightsail 콘솔에서 수동 스냅샷을 생성하거나
-
자동 스냅샷을 활성화합니다.
지침은 스냅샷으로 Linux/Unix Lightsail 인스턴스 백업 및 자동 스냅샷 구성을 참조하세요.
모니터링 및 문제 해결
인스턴스의 메모리 부족 여부를 어떻게 알 수 있나요?
일반적인 증상은 다음과 같습니다.
-
사이트에 "데이터베이스 연결 설정 오류"(퍼블릭 사이트와 관리자 패널 모두)가 표시됩니다. 이는 일반적으로 MariaDB가 중지되었음을 의미합니다.
-
사이트는 적당한 트래픽에서 느리게 로드되거나 시간 초과됩니다.
확인하려면 SSH를 통해 인스턴스에 연결하고 현재 메모리 사용을 확인합니다.
free -m
아래의 available 열을 살펴봅니다Mem:. 인스턴스가 여전히 사용할 수 있는 메모리의 양입니다. available가 50MB 미만인 경우 인스턴스의 메모리 부담이 높아지고 OOM 킬링 프로세스가 발생할 위험이 있습니다.
커널이 메모리 부족 프로세스("OOM kill")를 종료했는지 확인할 수도 있습니다.
sudo dmesg | grep -i "out of memory"
mariadbd 또는를 언급하는 항목이 표시되면 메모리 압력으로 mysqld데이터베이스가 종료되고 메모리 성능 개선의 단계가 도움이 될 것입니다.
인스턴스에 이미 자동 메모리 튜닝이 있습니까?
최신 Lightsail WordPress 블루프린트에는 인스턴스의 메모리 크기를 감지하고 시작 또는 재부팅 후를 포함하여 인스턴스가 시작될 때마다이 가이드에 설명된 스왑, MariaDB 및 Apache/PHP 설정을 자동으로 적용하는 서비스가 포함되어 있습니다. 인스턴스에 인스턴스가 있는지 확인하려면 SSH를 통해 연결하고 다음을 실행합니다.
systemctl status lightsail-memory-config
서비스가 있는 경우 인스턴스가 이미 이러한 설정을 자동으로 관리하므로 수동으로 적용할 필요가 없습니다. 명령을 통해 단위를 찾을 수 없다고 보고되면 메모리 성능 개선의 단계를 따릅니다.
성능 최적화
워크로드에 적합한 번들 선택
WordPress 성능을 개선하는 가장 효과적인 방법은 워크로드에 충분한 메모리가 있는 인스턴스 번들에서를 실행하는 것입니다. WordPress 자체는 가볍지만 플러그인, 테마 및 데이터베이스는 상당한 메모리를 소비할 수 있습니다.
-
512MB – 1GB RAM(Lightsail나노 및 마이크로 인스턴스 번들): 최소한의 플러그인 세트로 소규모 블로그 및 트래픽이 적은 사이트에 적합합니다. 이러한 인스턴스는 메모리 압력을 경험할 가능성이 가장 높으며 아래 튜닝을 통해 가장 많은 이점을 얻을 수 있습니다.
-
2GB RAM 이상: 페이지 빌더(예: Elementor 또는 Divi), WooCommerce 또는 많은 활성 플러그인을 실행하는 경우 권장됩니다.
사이트가 확장되고 더 많은 리소스가 필요해지면 스냅샷을 생성하고 더 큰 새 인스턴스를 시작하여 더 큰 번들로 업그레이드할 수 있습니다.
메모리 성능 향상
참고
최신 Lightsail WordPress 블루프린트는 인스턴스가 시작될 때마다 크기 인식 메모리 튜닝을 자동으로 적용하므로 새 Lightsail WordPress 인스턴스를 생성하는 경우이 섹션의 대부분의 수동 단계가 처리됩니다.
사용자(또는 방문자)가 페이지를 로드하려고 할 때 사이트에 “데이터베이스 연결 설정 오류”가 표시되거나 메모리 부족으로 인해 MariaDB가 종료되었음을 나타내는 로그 메시지가 표시되는 경우(예: 시스템 로그) 인스턴스Out of memory: Killed process ... (mariadbd)의 메모리가 부족할 가능성이 높습니다. 더 작은 인스턴스에서는 메모리가 소진될 때 Linux 커널이 MariaDB 데이터베이스 프로세스("OOM 종료")를 종료할 수 있습니다.
아래 세 단계는 스왑 공간을 추가하고 데이터베이스와 웹 서버가 사용할 수 있는 메모리의 양을 제한하여 메모리 압력을 줄입니다. 각 단계는 저절로 도움이 되므로 필요한 단계만 적용하거나 효과를 극대화하기 위해 세 단계를 모두 적용할 수 있습니다. 시작하기 전에 인스턴스의 최신 스냅샷이 있는지 확인합니다. 자세한 내용은 변경하기 전에 백업을 참조하세요.
중요
이 단계에서는 SSH를 통해 인스턴스에 연결하고를 사용하여 명령을 실행해야 합니다sudo. 데이터베이스와 웹 서버를 다시 시작하면 사이트가 잠시 중단되므로(몇 초) 트래픽이 적은 기간 동안 변경합니다.
인스턴스에 연결하려면 Lightsail 콘솔에서 브라우저 기반 SSH 클라이언트를 사용하거나 Linux 또는 Unix 인스턴스에 연결을 참조하세요.
1단계: 스왑 파일 추가
스왑 파일은 운영 체제에 비활성 메모리를 디스크로 오프로드할 수 있는 공간을 제공하므로 약 1.5GB 미만의 RAM이 있는 인스턴스에서 out-of-memory 충돌을 방지하는 데 도움이 됩니다. 나노 또는 마이크로 번들에서 스왑을 추가하는 것이 좋습니다. 일반적으로 더 큰 번들에서는 필요하지 않습니다.
먼저 스왑이 이미 활성 상태인지 확인합니다.
cat /proc/swaps
인쇄된 유일한 줄이 헤더(스왑 항목이 나열되지 않음)인 경우 스왑이 구성되지 않습니다.
Filename Type Size Used Priority
650MB 스왑 파일을 생성합니다.
sudo dd if=/dev/zero of=/mnt/.lightsail.swap bs=1K count=665600 status=progress sudo chmod 600 /mnt/.lightsail.swap sudo mkswap /mnt/.lightsail.swap sudo swapon /mnt/.lightsail.swap
재부팅 후에도 스왑 파일을 유지하려면 /etc/fstab에 추가합니다.
echo '/mnt/.lightsail.swap none swap sw 0 0' | sudo tee -a /etc/fstab
이제 스왑이 활성 상태인지 확인합니다.
cat /proc/swaps
이제 출력에 스왑 파일이 나타납니다.
Filename Type Size Used Priority /mnt/.lightsail.swap file 665596 0 -2
2단계: MariaDB 데이터베이스 튜닝
innodb_buffer_pool_size는 MariaDB에서 가장 큰 단일 메모리 소비자입니다. 기본 풀 크기가 인스턴스 메모리에 비해 너무 크면 out-of-memory 충돌이 발생할 수 있습니다.
권장 구성 테이블에서 인스턴스innodb_buffer_pool_size에 권장되는를 찾은 다음 해당 값으로 전용 구성 파일을 생성합니다(이 예제16M에서 해당 값으로 대체).
sudo tee /etc/mysql/mariadb.conf.d/90-lightsail-memory.cnf > /dev/null <<'EOF' [mysqld] innodb_buffer_pool_size = 16M EOF
변경을 실행하려면 데이터베이스를 다시 시작하는 다음 명령을 실행합니다.
sudo systemctl restart mariadb
3단계: Apache 및 PHP 튜닝
Apache는 WordPress 사이트에 대한 수신 요청을 처리하는 웹 서버입니다. 기본적으로 최대 150개의 동시 작업자 프로세스(MaxRequestWorkers)를 허용합니다. 작은 인스턴스에서 각 PHP 작업자는 수십 메가바이트를 사용할 수 있으며, 이로 인해 로드 시 메모리가 소진될 수 있습니다. 인스턴스와 일치하는 작업자 수를 제한하고 단일 PHP 요청에서 사용할 수 있는 메모리 양을 제한하려면 Apache mpm_prefork 제한을 설정합니다(표시된 값은 마이크로 인스턴스의 경우 , 인스턴스의 권장 구성 테이블 확인).
sudo tee /etc/apache2/mods-available/mpm_prefork.conf > /dev/null <<'EOF' <IfModule mpm_prefork_module> StartServers 1 MinSpareServers 1 MaxSpareServers 3 MaxRequestWorkers 5 MaxConnectionsPerChild 5000 </IfModule> EOF
PHP를 설정합니다memory_limit(512MB는 모든 크기에 대해 안전한 상한임). 먼저 PHP 버전을 감지한 다음 구성 파일을 작성합니다.
PHP_VERSION=$(php -r 'echo PHP_MAJOR_VERSION.".".PHP_MINOR_VERSION;') sudo mkdir -p /etc/php/${PHP_VERSION}/apache2/conf.d sudo tee /etc/php/${PHP_VERSION}/apache2/conf.d/90-lightsail-memory.ini > /dev/null <<'EOF' memory_limit = 512M EOF
Apache를 다시 시작하여 두 변경 사항을 모두 적용합니다.
sudo systemctl restart apache2
인스턴스 메모리별 권장 값
인스턴스의 총 RAM을 기반으로 아래 값을 사용합니다. 인스턴스의 메모리를 확인하려면를 실행free -m하여 total 열을 보거나 Lightsail 콘솔에서 번들 크기를 참조하세요.
|
인스턴스 메모리(RAM) |
MariaDB |
Apache |
PHP |
파일 스왑 |
|---|---|---|---|---|
최대 ~1.5GB |
16M |
5 |
512M |
예(650MB) |
~1.5~3GB |
256M |
10 |
512M |
아니요 |
~3~6GB |
256M |
25 |
512M |
아니요 |
~6~13GB |
2048M |
50 |
512M |
아니요 |
~13~26GB |
2048M |
125 |
512M |
아니요 |
~26GB 초과 |
4096M |
250 |
512M |
아니요 |
캐싱을 사용하여 로드 감소
캐싱은 WordPress가 데이터베이스를 쿼리하고 PHP를 실행하는 빈도를 줄여 CPU 및 메모리 사용량을 모두 줄입니다.
-
페이지 캐싱: W3 Total Cache 또는 WP Super Cache와 같은 캐싱 플러그인을 설치하여 페이지의 정적 사본을 제공합니다.
-
객체 캐싱: 사이트에 로그인한 사용자가 많거나 WooCommerce를 실행하거나 자주 변경되는 동적 콘텐츠(예: 포럼 또는 멤버십 영역)를 사용하는 경우 객체 캐시 플러그인(예: Redis 객체 캐시
또는 APCu 기반 캐시)은 자주 사용되는 쿼리 결과를 메모리에 저장하고 반복되는 데이터베이스 조회를 줄입니다. -
콘텐츠 전송 네트워크(CDN): 정적 자산(이미지, CSS, JavaScript)을 Lightsail 배포와 같은 CDN으로 오프로드하여 인스턴스에서 제공하지 않도록 합니다.