블로그

실제 웹사이트 방문자들이 체감하는 웹사이트 속도에 대개 3가지의 요소로 정리됩니다.
(1) 다운로드 속도
(2) 웹서버 부하 감소
(3) 브라우져의 효율성
입니다.
이중 (3) 브라우져의 효율성은 개별 방문자의 크롬이나 인터넷 익스플로러의 설정과 관련된 것이라 방문객 별로 일일히 통제하기에는 거의 불가능한 상황이므로 논외로 하고 다운 로드 속도와 서버 부하에 대해서 대안을 생각해보도록 하겠습니다.
(1) 다운로드 속도
웹사이트 다운로드 속도란 페이지 로딩 속도라고도 하는데 웹사이트의 이미지 화일을 포함하는 정적인 컨텐츠( Static Contents ) 인 Html, Javascript, Css 화일이 다운 로드되는 속도를 말합니다. 대부분의 웹사이트 측정을 하는 웹사이트는 다운 로드 속도 이상을 측정해주지는 않습니다. 그 이유로서는 웹사이트 다운로드 속도 측정은 웹서버 내부의 Database 엑세스와 Apache 나 NginX와 같은 Php와 같은 동적으로 컨텐츠를 구성하는 과정을 측정해내지는 못하기 때문입니다.
(2) 웹서버 부하 감소.
실제 워드프레스 속도 문제을 100%으로 놓고 보면 다운로드 속도 부분은 20%로 적은 편이고 서버 부하부분이 80% 이상의 문제를 차지하는 편입니다. 이커머스를 활용하는 대부분의 국가들의 인터넷 회선 속도를 감안할 때 대용량 이미지를 잘못 쓰는 경우가 아니라면 큰 무리가 없고 있다하더라도 이미지 최적화를 통하여 해결할 수 있기 때문입니다.
웹서버를 Apache로 쓰고 있는 경우, 워드프레스는 Apache – Php – Mysql 과 연결되는 과정에서 부하를 발생시킵니다. 워드프레스의 서버 부하는 대부분은 설치된 테마와 플러그인들이 발생시키는 Mysql Access 에서 발생한다고 봐도 무방합니다.
이 두가지 내용에 대해 세부적인 진단과 처리 방법에 대해 알아보도록 하겠습니다.
워드플레스는 설정이나 각 플러그인의 동작시에 Mysql DB에 상당히 많은 횟수의 읽기가 시도됩니다. 많은 부분 Mysql 의 데이터 읽기 과정에 많는 부하가 발생하는 경우 입니다.

일단 다운 로드의 경우 속도 측정을 어떤 요소가 속도에 영향을 미치고 있는가가 중요한 요소입니다. 잘 알려진 속도 측정 사이트를 소개합니다.
(1) 핑덤
핑덤은 전 세계적으로 사이트 속도 측정을 위해 가장 많이 이용되는 사이트 중 하나이며, 측정했던 기록이 남기 때문에, 보완 후 다시 측정 했을 때 얼마나 효과가 있었는지도 확인 가능 합니다. (2) 구글 스피트 페이지
웹사이트의 다운 로드 속도를 즉정하는 도구로써는 Google 의 PageSpeed 가 있습니다. 구글 스피드 인사이트는 구글에서 제공하는 측정 사이트로, 속도 측정 결과와 함께 수정 해야할 사항들을 표시해 줍니다. (3) GT 매트릭스
GT 매트릭스는 고정된 위치(IP)가 아닌 국가에서 속도를 측정해줍니다. 즉, 글로벌 유저를 표적고객으로 하는 웹사이트에를 테스트 하기에 적절한 사이트 입니다.
2. https://gtmetrix.com/
일단 속도 측정을 하고 나면 어디에서 속도의 취약점이 발생하는가를 확인할 수 있습니다. 다운 로드 속도는 결국 대부분
(1) 이미지 최적화 (2) 브라우저 캐싱 (3) Static (Html, Javascript, css ) 화일 최적화로 귀결이 됩니다.
그럼 좀 더 세부적인 내용을 살펴 보도록 하겠습니다.
(1) 이미지 최적화 – Image Optimazation ( Image Polishing )
다운로드의 속도의 대부분은 무거운 이미지가 대부분은 차지 합니다.
a. 이미지의 품질 수준은 유지하면 하면서 용량을 최소할 할 수 있는 방법을 찾아 봅니다.
Optimizilla는 기부로 운영되는 뛰어난 온라인 이미지 최적화 사이트입니다. 이미지 최적화는 온라인상 보여지는 이미지의 품질 수준을 유지하면서 용량을 크게 감소시켜 주며 Optimizilla를 사용화면 최대 7배가 넘는 크기를 최적화가 가능하며 한 번에 20개의 이미지를 업로드할 수 있고 직접 압축 품질 변경 가능한 기능을 제공한다. 하지만 이러한 최적화를 제공하는 확장자는 JPG, PNG뿐입니다.
http://optimizilla.com/ko/
이미지 최적화 클라이언트 툴 : https://imageoptim.com/mac
b. 가장 중요한 요소가 갤러리 형태로 보여줄 때 썸네일 방식으로 용량이 최소화된 형태로 자동으로 잘라 줄 수 있는가 입니다. 이 경우 워드프레스 테마에서 제공해주는 경우가 많는데 실제적으로 테마를 사용하면서 확인해보는 것이 가장 좋습니다.
c. 워드프레스 이미지 최적화 플러그인
(2) 브라우저 캐싱은 서버에서 다룰 수 있는 것이 아니므로 일단은 제외하고 넘어 갑니다.
(3) 정적(Static) 화일 Minifying
동적으로 변화 하지 않는 Html 이나 Include되는 Jave script, Css 화일을 압축하는 기능입니다. 미리 압축한 min 화일을 사용할 수 도 있고 캐시에서 압축할 수 도 있습니다. 하지만 다운로드 속도 개선을 위하여 이미지를 제외한 정적 화일의 minifying 이 가져다 주는 효과는 미미합니다.
** 결국 다운로드 속도를 증가 시키기 위한 가장 확실할 방법으로써 CDN ( Contents Delivery Network) 서비스와 Image Polishing 이라는 방법이 있습니다. **
해당 내용은 아래의 독립된 소절에서 상세히 설명하도록 하겠습니다.

웹서버 부하 측정으로 들어가면 이제 양상은 상당이 복잡해지기 시작합니다. 워드프레스 기술 구조중 가장 강점 중에 하나인 유연한 플러그인(Plugin) 개발 기법은 워드프레스를 통한 무한한 기능 확장이 용이하게 될 수 있도록 만들어져서 워드프레스를 전 세계 CMS 툴 분야에서 사실상을 표준을 만들수 있는 일등공신이 되었습니다. 하지만 강점이 있으면 그것으로 인한 약점도 생기는 법이지요. 워드프레스 플러그인에서 주로 사용하는 Calllback 함수 (보통 Hook이라고 부르기도 합니다.)가 특성상 미리 로직을 로딩하여 컴파일 해둔 상태에서 한 페이지가 실행되는 상황에 따라 사용 여부를 결정하는 방식이므로 자연적으로 서버 부하가 상대적으로 많이 발생하는 구조이 되어 있습니다. 사실은 그리고 각 플러그인들은 대부분의 메인 페이지는 웹사이트의 root 폴더의 index.php에 모두 include되어 컴파일되는 방식으로 만들어져 있으므로 플러그인 개발자가 플러그인 개발시 최적화에 공을 들이지 않으면 하나의 플러그인이 웹서버 부하를 크게 발생시켜 버립니다. 또한 개별 웹 페이지가 실행될 때 마다 각 플러그인의 세팅 정보를 읽어 내어야 하는데 그 개별 정보 하나 하나가 wp-options라는 하나의 테이블 한 레코드에 저장되도록 구성되어 있으므로 많은 수의 Mysql Query를 발생시켜 버립니다. 대체적으로 워드프레스에서 한 페이지를 보여줄 때 80~200개 정도의 쿼리가 발생되는데 MySql에서 데이터를 가져오는데 이 숫자가 많을수롤 서버 부하는 증가되는 것입니다. 그래서 워드프레스의 속도는 사실 이 쿼리의 갯수를 최대한 적게하고, 쿼리 속도를 최대한 빠르게 만드는 것이 가장 중요한 관건이 되는 것입니다. 그래서 Mysql를 워드프레스에 적합하도록 튜닝하는 것이 중요한 이슈가 되지만 실제 그럴만한 기술를 가진 사람을 찾기란 힘든 상황입니다. 대체적으로 Php Version 5.x 대에서 Php 7으로 업그레이드 한 경우라도 만족스러운 결과가 나오지 않는 것은 근본적으로 워드프레스가 Mysql을 혹사시키고 있다고 예상되기 때문입니다. 지금까지 다보리에서 워드프레스로 개발된 웹사이트를 호스팅하면서 발견된 재미있는 사항을 서버 사양을 높힌다 하여도 한번 잘못 개발된 플러그인을 사용하고 있는 경우 특별한 개선책이 나오지 않았다는 것입니다. 따라서 가장 고질적인 문제인 서버 부하의 감소인 플러그인과 테마의 효율성을 확보하는 것에 다름아닌 것입니다.
일단 워드프레스 플러그인 문제가 어찌되었던 내 사이트의 문제가 해결되려면 일단 진단은 되어야 하므로 플러그인 속도 진단 플러그인을 소개합니다.
이 플러그인을 가만히 살펴보면 제작사가 GoDaddy라는 미국의 가장 큰 웹호스팅사로 되어 있습니다. 다른 곳도 아닌 웹호스팅사가 뭐가 답답해서 이런 것을 만들었을까요 ? 이것은 웹호스팅사가 워드프레스 호스팅 때문에 많은 골머리를 앓고 있다는 것을 명백히 보여주는 것입니다. 공통으로 사용하는 웹서버에 서버 부하를 심하게 가져가는 워드프레스 웹호스팅이 그렇게 환영받지 못한다는 것입니다. 실제 미국의 내노라하는 웹호스팅사가 워드프레스 전용 웹호스팅 상품을 공격적으로 영업하지 않는 이유가 이런 문제점이 있기 때문이 아닐까 하고 생각해 보았습니다.

실제 대부분의 워드프레스용 캐시를 사용해보았지만 뚜렷한 속도의 개선 효과를 보지는 못했습니다. 역으로 해킹에 대해 더 취약해지고 다른 플러그인과 충돌이 나는 경우가 종종 있었습니다. 하지만 유료로 제공되는 WP-Rocket 이라는 워드프레스 캐시 플러그인은 본사의 한 사용자 분의 주장이 워드프레스 캐시 플러그인 중에서 가장 빠르게 만들 수 있다고 주장하고 있습니다. 그분의 웹사이트에 추가하여 현행 사용 중이며 계속 모니터링 해볼 계획입니다.

특징 중에 하나는 Cloudflare의 CCDN 기능과 아주 잘 연동되고 있는 것으로 확인되었습니다.

CDN (Contents Delivery Network) 서비스는 이미지나 동영상 같은 정적인 컨텐츠들을 서비스하는데, 서버가 있는 데이타 센터에서 서비스를 하게 되면, 네트워크 latency 때문에 성능이 저하가 되기 때문에, 여러 개의 데이타 센터에 서버를 넣고, 클라이언트가 다운로드드에 유리한 서버로 부터 컨텐츠를 제공하는 서비스입니다. 즉, 웹서버와 컨텐츠 서버를 분리하여 웹서버에서는 동적인 HTML 다운로드만 담장하고 CDN은 다운로드될 정적 컨텐츠만들 담당하여 부하 분산과 다운로드 속도를 감소시키는 방법입니다.
아마존의 경우에도 얼마전부터 Cloud Front라는 이름으로 CDN 서비스를 제공하는데, 아마존 인프라와 융합되어 몇 가지 특별한 기능들을 제공합니다.
CDN이 가져다 주는 일반적인 서버 부하 분산과 속도 증가 효과를 한번 살펴보면
(1) 웹서버의 부하 감경 효과
(2) 네트워크 트래픽의 분산 효과
(3) 웹캐쉬의 의한 다운로드 속도의 증가
(4) 이미지 최적화 ( Image Polishing) 울 통한 다운로드 속도 증가
CDN은 부하 분산에는 상당한 효과를 가져오지만 꽤 고가의 비용을 지속적으로 지불해야 한다는 단점도 있습니다.

A. 이전/완성 테스트 서비스
(1) 해킹/악성 코드 테스트
신규 웹사이트 제작 완료 또는 신규 웹호스팅 이전시에 웹사이트를 방역소(Quarantine) 웹사이트로 이전한 후 악성 코드 테스트를 1~3일간 하게 됩니다.
(2) 서버 부하 테스트
신규 웹사이트 제작 완료 또는 신규 웹호스팅 이전시에 웹사이트를 서버 부하와 Performance 테스트를 하게 됩니다.
(3) 다운로드 속도에 대한 보고서를 확인하여 사용자가 그에 따르는 적절한 대책을 강구하게 합니다.
(4) 조치가 완결된 후 정상 웹호스팅 서버로 한번 더 이전합니다.
B. Perfomance 테스트 서비스
방역소 웹사이트에서 이전된 워드프레스 웹사이트에 대하여
===1 단계===
(1) 웹사이트 다운로드 테스트
(2) 플러그인 부하 테스트.
(3) 테마 부하 테스트
===2단계===
(3) 다운로드 최적화 작업 – Image Polishing 가 Static File minify
(4) 플러그인 최적화 작업 – Plugins Optimazaion
===3단계===
(5) MySql 튜닝 – My Sql Tunning
위의 3단계를 거쳐서 워드프레스 웹사이트를 최고 속도로 운영할 수 있도록 준비하고 있습니다.

S3 는 AWS 제품 시리즈중 가장 유용한 서비스중의 하나인데 가장 빈번하게 쓰이는 형태가 백업 시스템과 CDN 서비스를 위하여 구축되는 경우입니다. 오늘은 S3를 이용한 백업 파일 시스템으로 활용하는 것이 주목적입니다. 이 해결책으로 쓰이는 백업 패키지중의 하나가 FUSE 기반의 s3fs 입니다. 하지만 이 3 sfs의 가장 큰 이슈가 “너무 느리다”라는 단점이 있습니다. 그래서 이것보다는 성능이 좋다는 goofys 패키지를 이용하여 백업 화일 시스템을 구축하였습니다. goofys 또한 오픈소스는 아니며 aws에서 정식으로 지원하는 패키지는 아닙니다만 사용해본 결과 s3fs 보다는 훨씬 속도가 빨라서 실행 속도에 큰 불만은 없었습니다. goofys 설치와 운용은 이 블로그의 목적에 너무 벗어나므로 해당 설명을 원하시는 분은 개별적으로 연락하시기 바랍니다.

화일시스템을 구축한 이후 일별로 백업하면서 백업 공간으로 절약하기 위해 최근 일주일 단위의 백업화일만 저장 할 수 있도록 백업 시스템을 정하였습니다. 그리고 혹시라도 사용자의 관리 소홀로 인하여 발생할 수 있는 웹사이트 – 소규모의 기업 웹사이트는 사용자 가 1주일 동안 이상 여부를 점검하지 않는 경우도 많으므로 – 의 복원의 범위를 늘리기 위하여 각 월별 백업을 12개월치를 보관할 수 있도록 하였습니다.
정리해보면 다보리의 웹사이트 백업 시스템은 매일 새벽 2시경에 자동 백업을 하며 이것을 최근 일주일 7일치의 백업을 보관하고 있습니다. 그리고 추가적인 문제를 해결하기 위하여 매월초 백업을 받아서 12개월 간의 보조 백업을 하고 있습니다. 이것은 사용자의 의지와 사용 방법과 무관하게 야간에 자동으로 백업을 받게 되므로 문제가 최소화되고 있습니다.

이제 문제는 어떻게 백업이 받아진 화일 시스템을 랜섬웨어로 부터 방어하느냐 입니다.
다보리에서는 각 개별 S3를 각각분리해서 저장하고 백업과 복원 당시에만 화일 시스템을 복원하는 것으로 이 문제를 해결하였습니다. 즉 랜섬웨어 자체가 화일 시스템으로 마운트 되지 않을 경우에는 어떤 경우라고 백업 화일 시스템을 감염시킬 수 없다는 것을 전제로 하여 백업 시스템을 설계하였습니다.

이후는 아래와 같은 웹사이트 복원 절차로 진행하시면 됩니다.

[워드프레스] 웹호스팅에서 Shell 명령어로 데이터와 DB 백업과 복원하기