태그 보관물: wordpress

Ligthtsail 하위 인스턴스로 되돌리기

Back up script

서버 인증서는 백업하기 보다는 재발급 받는게 나을것 같다고 해서 이것을 제외하고 다른 모든 것들을 백업하는 스크립트를 돌려서 만들어진 파일은 크기가 무려 950MB짜리 초대형 슈퍼 울트라 원 클릭 “full_server_migration_backup.tar.gz”이다.

Restore script

이제 가격이 싼 인스턴스를 생성하고 만들어진 백업 파일과 복원 스크립트를 옮기고 복원 script를 실행시켰더니… 적용하는 중에 EOF 에러가 여기저기에서 떨어지면서 뭔가 동작이 조금 이상했다. 마지막 단계에서는 인증서까지 새로 발급 받으려고 하길래 아직 도메인이 적용되지 않았으니 기다리라고 취소를 눌렀다.

후 폭풍과 뒷 수습

자신감 넘치는 AI들의 속삭임에 속은 게 한 두번이 아니기는 하지만 결과물을 보고는 다시 한 번 놀랄 수 밖에 없었다. 복원했다던 wordpress 폴더는 깔끔하게 비워져 있고 설정된 것이라고는 nginx과 database 그리고 php 환경 정도였다. 실제로는 복원 스크립트라기 보다는 LEMP 설치용 스크립트에 가까웠던 것이다.

wordpress 수동복사

그나마 database는 복원이 되어 있었기 때문에 이전 서버의 /var/www/html/ 경로에 있던 WordPress 파일들을 모두 복사해서 새로운 서버에 올려 주었다.

WordPress 설정파일 임시 설정

백업된 /etc/nginx/conf.d/wordpress.conf에는 HTTPS 관련한 설정이 들어가 있는데, 아직 cert. 업데이트를 하지 않은 상태에서는 이상 동작 하기 때문에 해당 파일을 80번에서 HTTP만 대기 하도록 간단히 임시로 수정한다. 물론 이전 설정 파일은 결국 사용할 것이니까 버리지 않고 백업해 두었다.

Certificate update

사실 인증서 업데이트 항목이 복원용 스크립트에 들어가 있다는게 말이 안된다. Cert update를 한다는 건 도메인을 연결한 상태라는 건데 아직 설정중인 서비스가 어떻게 동작할 지도 모르는 걸 도메인 부터 연결 한다는게 AI 급의 엄청난 자신감이 아니라면 안될말이다.

먼저 HTTP로 서비스가 잘 동작하고 기본적인 복원이 된 것을 확인하고, 그 다음에 도메인을 새로운 인스턴스로 연결해 준 뒤에 certbot을 실행시켜서 인증서를 수동으로 업데이트 했다. Lightsail 인스턴스 페이지에서 HTTPS용 443번 포트를 사용할 수 있도록 방화벽 잊지 않고.

WordPress 설정파일 복원

HTTPS를 위한 인증서를 업데이트 했으니 앞서 백업해 두었던 임시파일을 복원하고 nginx를 재실행 해준다.

Redis설치

Redis에 대한 내용이 백업과 복원에서 완전히 빠져 있어서 웹사이트가 실행되지 못하고 있었다. Redis를 설치하고 실행해 주었다.

Imagick 설치와 메모리 부족

이제 WordPress의 건강상태 화면을 확인했더니 php-pecl-imagick 모듈이 설치되지 않아서 건강하지 못한 상태라고 한다. 문제는 여기에서 터졌는데 512MB의 미약한 RAM 크기로는 이 패키지를 설치하는 중에 요구되는 메모리 피크를 감당하지 못하고 설치에 실패했다. 그러고 보니 애초에 비싼 인스턴스로 옮겨갔던 이유도 백업 프로그램 동작 중에 RAM 피크를 감당하지 못해서 문제가 생겼던 것인데 지금도 똑같은 문제가 생기고 있었다.

Swap 확장

“아! 그때는 왜 이생각을 못했을까.”

AI가 해결책이라고 알려준 이 방법은 사실 예전에 비싼 인스턴스로 옮기기 전에도 시도해 봤어야 했다. 현재 기본적으로 주어지는 400MB의 sawp에 추가로 1GB를 할당하고 설치를 재실행했더니, 시간이 좀 걸리기는 했어도 문제 없이 설치가 되었다. “비싼돈 쓰기 전에 swap 확장 부터!” 값진 교훈을 AI로 부터 의도치 않게 전수 받아 마음에 새겨둔다.

한가지 특이했던 점은 새로 만든 1GB swap 공간을 연결하기전에 swap off를 실행하지 않았더니 기존의 크기와 합쳐서 1.4GB의 swap이 인식되었다는 점이다. Swap 공간을 부팅 이후에도 계속 사용하도록 /etc/fstab에 추가해 두었다.

공격 대비

지난번에 “Lightsail 서버가 자꾸 죽어서” 확인했던 XMLRPC와 search flood attack에 대해 새 서버에 대비가 잘 되어 있는지 확인하는 스크립트를 만들어 달라고 했더니 뚝딱 만들어 주었는데 이것은 별 문제 없이 잘 돌려서 확인할 수 있었다.

그 동안 수고 많았다 비싼 친구야

인스턴스에 변경이 있을 때 마다 올리던 버전이 이제는 어느새 6.0이 되었다. 새로운 인스턴스의 건강 상태와 동작을 최종 확인한 다음 1GB, 40GB 짜리 비쌌던 인스턴스는 이제 은퇴하고 다시 예전의 기본 tier로 돌아 오게 되었다.

WordPress “다른 업데이트가 진행중 입니다” 문제 해결

WordPress Update Lock

Update를 위해 Wrodpress가 설정하는 lock은 wordpress database의 wp_options table에 있다. 업데이트가 진행중이라는 메세지가 오랫동안 없어지지 않는 상태라면 wp_config.php에 적어둔 DB access 정보를 참조해서 해당 테이블에 접근해 core_updater.lock이 설정되어 있는지 확인해 보자.

mysql -u litcoder -p --database wordpress

SELECT * FROM wp_options WHERE option_name = 'core_updater.lock';

이 query에서 결과가 출력된다면 현재 lock이 걸려 있는 상태이다. 참고로 여기에서 option_value의 값은 lock이 설정된 unix time을 의미한다.

Lock 제거

반드시 현재 진행되고 있는 업데이트가 없고 이것이 비 정상적인 상황이라는 확신이 있을 때만 다음의 명령어로 lock을 삭제해 주자.

DELETE FROM wp_options WHERE option_name = 'core_updater.lock';

그리고 나서 재시도 해보면 해당 오류가 없어진 것을 볼 수 있을 것이다.

결론

시대가 시대인 만큼 wp-config.php를 읽어서 자동으로 lock을 해제해 주는 script를 “딸깍”으로 만들어 gist에 올려 두었다. 필요한 경우가 있다면 다음의 명령어를 터미널에 복붙하면 된다. 참고로 실행에 sudo 권한이 필요한 이유는 wp_config.php에 접근하기 위해서이다.

curl -sSL https://gist.githubusercontent.com/litcoder/\
27e0f3538762bfd3b0fcfdeea01d2867/raw/\
d7bb16761d4449408bb1c8dbee55931fccec20e7\
/wp-unlock-update.sh | sudo bash

MAPA: Make All Health-checks Pass Again

건강문제 1: “지속적인 객체 캐시를 사용해야 합니다”

객체 캐시 서비스를 설정하지 않아서 보고되는 내용으로, Redis나 Memcached 같은 캐시 서비스를 설치해서 해결 할 수 있다. 다음의 명령어로 AL2023에서 Redis6를 설치해 준다.

sudo dnf install redis6 -y
sudo systemctl start redis6
sudo systemctl enable redis6

그리고 나서 Redis6와 PHP가 소통할 수 있도록 php-redis도 설치해 준다.

sudo dnf install php-redis -y
sudo systemctl restart php-fpm

Redis6의 설정파일인 /etc/redis6/redis6.conf에 다음 두 줄을 추가해서 메모리 사용량은 128MB로 제한한다. 지금 사용하고 있는 plan의 메모리가 그다지 여유롭지는 않기 때문에 이정도 크기로 제한을 두었다.

maxmemory 128mb
maxmemory-policy allkeys-lru

마지막으로 WordPress에서 Redis Object Cache plugin을 설치하고 활성화 시켜준다.

건강문제 2: “패이지 캐시가 감지되지 않았으나 서버 반응시간이 좋습니다”

매번 페이지가 로드될 때마다 PHP process를 거치지 않아도 되도록 static cache를 설정해 달라는 내용이다. 아주 간단하게는 WordPress plugin을 설치해서 해결할 수도 있는데, 문제는 이러한 plugin들이 대부분 고유주소(permalink) 형식을 다른 것으로 변경하는 것을 요구한다는 것이다.

검색엔진의 상위에 뜨기 위해서라도 이 설정을 "글이름” 형식으로 설정하는게 좋다고는 하는데 검색엔진 상위에 뜨는 건 딱히 관심사도 아닌데다가 무엇보다도 저 형식은 별로 예쁘지 않다.

다행히도 Nginx에서 FastCGI caching을 설정하는 방법으로 static caching을 달성할 수 있다. 먼저 캐시로 사용할 공간을 만들어 준다.

sudo mkdir -p /var/run/nginx-cache
sudo chown nginx:nginx /var/run/nginx-cache
sudo chmod 700 /var/run/nginx-cache

Nginx의 전역 설정파일인 /etc/nginx/nginx.conf의 http 영역에 캐시의 경로와 메모리 사용량(10MB)을 정의한다.

fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=wpcache:10m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

다음으로 server 영역에 관리자 페이지나 포스트 작성 처럼 캐시를 사용하지 않을 경우를 설정한다.

location ~ \.php$ {
...
    # Cache예외 경우 설정
    set $skip_cache 0;
    if ($query_string != "") { set $skip_cache 1; }
    if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") {
        set $skip_cache 1;
    }
    if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in") {
        set $skip_cache 1;
    }
    
...
}

그리고 캐시 사용을 다음과 같이 설정한다. 아래의 "디버깅 목적"에 있는 헤더에 내용을 추가하는 부분은 굳이 넣지 않아도 되지만, WordPress의 건강검사 메뉴에서 캐시적용 여부를 판단하는 부분을 위해서 넣어 주었다. 이 부분을 추가해 주지 않으면 정적 캐시가 동작하고 있어도 캐시 관련 메세지가 계속 뜨게 된다.

location ~ \.php$ {
...
    # Cache
    fastcgi_cache wpcache;
    fastcgi_cache_valid 200 301 302 60m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
        
    # 캐시 적중 여부를 헤더에 표시 (디버깅 목적)
    add_header X-FastCGI-Cache $upstream_cache_status;
    add_header X-Cache-Enabled "True";  # 건강검사 통과용
    add_header X-Proxy-Cache $upstream_cache_status;
...
}

결과

잘했다!

Litcoder

기억은 짧고 불완전 하다