[워드프레스] 속도를 개선하는 방법-종합개요

안녕하세요 ?
국내 유일의 무료 워드프레스 쇼핑몰 “우커머스 교실”에서 사용하고 있는, 워드프레스 속도를 개선하는 방법에 대해 알아보도록 하겠습니다.
기본적으로 쇼핑몰과 같이 영리를 목적으로 하는 웹사이트 속도는 방문객들의 체감하는 웹사이트 속도에 의하여 매출 전환율이 많은 영향을 받습니다. 웹서비스가 1초 느려지면 매출이 3% 떨어진다는 마이크로소프트 빙(BING)의 통계도 있는데, 에버든 그룹(Aberdeen Group)에 보고서에 의하면 온라인 쇼핑몰의 경우 페이지 로딩 시간이 1초 지연될때 마다 페이지 뷰는 11%, 고객 만족도는 16% 감소할 뿐만 판매 전환율도 7%정도 낮아 진다고 합니다. 그리고 웹사이트의 성능에 불만을 느낀 소비자의 79%가 해당 사이트에서 다시 상품을 구매하지 않을 것입니다. 따라서 웹사이트의 속도는 매출 전환율을 높이는 중요한 요소 중에 하나 입니다.

1. 웹사이트 속도를 결정하는 요소
실제 웹사이트 방문자들이 체감하는 웹사이트 속도에 대개 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 의 데이터 읽기 과정에 많는 부하가 발생하는 경우 입니다.
2. 다운 로드 속도
일단 다운 로드의 경우 속도 측정을 어떤 요소가 속도에 영향을 미치고 있는가가 중요한 요소입니다. 잘 알려진 속도 측정 사이트를 소개합니다.
(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 이라는 방법이 있습니다. **
해당 내용은 아래의 독립된 소절에서 상세히 설명하도록 하겠습니다.
병목_현상__Angde
3. 서버 부하 감소
웹서버 부하 측정으로 들어가면 이제 양상은 상당이 복잡해지기 시작합니다. 워드프레스 기술 구조중 가장 강점 중에 하나인 유연한 플러그인(Plugin) 개발 기법은 워드프레스를 통한 무한한 기능 확장이 용이하게 될 수 있도록 만들어져서 워드프레스를 전 세계 CMS 툴 분야에서 사실상을 표준을 만들수 있는 일등공신이 되었습니다. 하지만 강점이 있으면 그것으로 인한 약점도 생기는 법이지요. 워드프레스 플러그인에서 주로 사용하는 Calllback 함수 (보통 Hook이라고 부르기도 합니다.)가 특성상 미리 로직을 로딩하여 컴파일 해둔 상태에서 한 페이지가 실행되는 상황에 따라 사용 여부를 결정하는 방식이므로 자연적으로 서버 부하가 상대적으로 많이 발생하는 구조이 되어 있습니다. 사실은 그리고 각 플러그인들은 대부분의 메인 페이지는 웹사이트의 root 폴더의 index.php에 모두 include되어 컴파일되는 방식으로 만들어져 있으므로 플러그인 개발자가 플러그인 개발시 최적화에 공을 들이지 않으면 하나의 플러그인이 웹서버 부하를 크게 발생시켜 버립니다. 또한 개별 웹 페이지가 실행될 때 마다 각 플러그인의 세팅 정보를 읽어 내어야 하는데 그 개별 정보 하나 하나가 wp-options라는 하나의 테이블 한 레코드에 저장되도록 구성되어 있으므로 많은 수의 Mysql Query를 발생시켜 버립니다. 대체적으로 워드프레스에서 한 페이지를 보여줄 때 80~200개 정도의 쿼리가 발생되는데 MySql에서 데이터를 가져오는데 이 숫자가 많을수롤 서버 부하는 증가되는 것입니다. 그래서 워드프레스의 속도는 사실 이 쿼리의 갯수를 최대한 적게하고, 쿼리 속도를 최대한 빠르게 만드는 것이 가장 중요한 관건이 되는 것입니다. 그래서 Mysql를 워드프레스에 적합하도록 튜닝하는 것이 중요한 이슈가 되지만 실제 그럴만한 기술를 가진 사람을 찾기란 힘든 상황입니다. 대체적으로 Php Version 5.x 대에서 Php 7으로 업그레이드 한 경우라도 만족스러운 결과가 나오지 않는 것은 근본적으로 워드프레스가 Mysql을 혹사시키고 있다고 예상되기 때문입니다. 지금까지 다보리에서 워드프레스로 개발된 웹사이트를 호스팅하면서 발견된 재미있는 사항을 서버 사양을 높힌다 하여도 한번 잘못 개발된 플러그인을 사용하고 있는 경우 특별한 개선책이 나오지 않았다는 것입니다. 따라서 가장 고질적인 문제인 서버 부하의 감소인 플러그인과 테마의 효율성을 확보하는 것에 다름아닌 것입니다.
일단 워드프레스 플러그인 문제가 어찌되었던 내 사이트의 문제가 해결되려면 일단 진단은 되어야 하므로 플러그인 속도 진단 플러그인을 소개합니다.
이 플러그인을 가만히 살펴보면 제작사가 GoDaddy라는 미국의 가장 큰 웹호스팅사로 되어 있습니다. 다른 곳도 아닌 웹호스팅사가 뭐가 답답해서 이런 것을 만들었을까요 ? 이것은 웹호스팅사가 워드프레스 호스팅 때문에 많은 골머리를 앓고 있다는 것을 명백히 보여주는 것입니다. 공통으로 사용하는 웹서버에 서버 부하를 심하게 가져가는 워드프레스 웹호스팅이 그렇게 환영받지 못한다는 것입니다. 실제 미국의 내노라하는 웹호스팅사가 워드프레스 전용 웹호스팅 상품을 공격적으로 영업하지 않는 이유가 이런 문제점이 있기 때문이 아닐까 하고 생각해 보았습니다.
sitegroundfastresponsetime
4. 워드프레스 캐시 플러그인을 통한 서버 부하 감소
실제 대부분의 워드프레스용 캐시를 사용해보았지만 뚜렷한 속도의 개선 효과를 보지는 못했습니다. 역으로 해킹에 대해 더 취약해지고 다른 플러그인과 충돌이 나는 경우가 종종 있었습니다. 하지만 유료로 제공되는 WP-Rocket 이라는 워드프레스 캐시 플러그인은 본사의 한 사용자 분의 주장이 워드프레스 캐시 플러그인 중에서 가장 빠르게 만들 수 있다고 주장하고 있습니다. 그분의 웹사이트에 추가하여 현행 사용 중이며 계속 모니터링 해볼 계획입니다.
wp-rocket-comparison
특징 중에 하나는 Cloudflare의 CCDN 기능과 아주 잘 연동되고 있는 것으로 확인되었습니다.
5. CDN을 통한 서버 부하의 감소
CDN (Contents Delivery Network) 서비스는 이미지나 동영상 같은 정적인 컨텐츠들을 서비스하는데, 서버가 있는 데이타 센터에서 서비스를 하게 되면, 네트워크 latency 때문에 성능이 저하가 되기 때문에, 여러 개의 데이타 센터에 서버를 넣고, 클라이언트가 다운로드드에 유리한 서버로 부터 컨텐츠를 제공하는 서비스입니다. 즉, 웹서버와 컨텐츠 서버를 분리하여 웹서버에서는 동적인 HTML 다운로드만 담장하고 CDN은 다운로드될 정적 컨텐츠만들 담당하여 부하 분산과 다운로드 속도를 감소시키는 방법입니다.
아마존의 경우에도 얼마전부터 Cloud Front라는 이름으로 CDN 서비스를 제공하는데, 아마존 인프라와 융합되어 몇 가지 특별한 기능들을 제공합니다.
CDN이 가져다 주는 일반적인 서버 부하 분산과 속도 증가 효과를 한번 살펴보면
(1) 웹서버의 부하 감경 효과
(2) 네트워크 트래픽의 분산 효과
(3) 웹캐쉬의 의한 다운로드 속도의 증가
(4) 이미지 최적화 ( Image Polishing) 울 통한 다운로드 속도 증가
CDN은 부하 분산에는 상당한 효과를 가져오지만 꽤 고가의 비용을 지속적으로 지불해야 한다는 단점도 있습니다.
L
top_img_05
6. 다보리에서 제공하는 워드프레스 속도 개선 서비스
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단계를 거쳐서 워드프레스 웹사이트를 최고 속도로 운영할 수 있도록 준비하고 있습니다.
wsm_QS-login
워드프레스제작
위의 설명 과정에서 많는 워드프레스 사용자들이 Insight 를 발견했으리라 생각합니다. 사실 다보리 사이트는 1,2,3 단계의 최적화를 커쳐 현행 한국의 PG 결제를 사용 하고 있는 웹사이트 중 가장 빠른 웹사이츠로 만들었다고 자부할 수 있습니다. 좀 더 자세한 내용은 다보리 통합 플러그인과 워드프레스 속도에서 설명할 계획입니다.

[워드프레스]AWS-S3를 이용한 워드프레스 랜섬웨어 프리 자동 백업 시스템 구축

안녕하세요 ?
국내 유일의 무료 워드프레스 쇼핑몰 “우커머스 교실”에서 사용하고 있는, 아마존 웹 서비스 AWS 의 S3의 백업 기능을 이용하여 랜섬웨어 프리형태의 워드프레스 백업 시스템 구현의 실 구축 사례를 살펴보도록 하겠습니다.
지난 6월 국내 중견 웹호스팅사인 (주)인터넷나야나에서 랜섬웨어에 공격당하여 전체가 서버가 다운되고 암호화된 화일을 복원하기위해 해커집단에게 거액의 몸값을 지불한 일이 있었습니다. 상세 내용을 살펴보면 랜섬웨어에 현재 러닝중인 전체 서버 전체가 감염되기도하였지만 해당 서버의 백업을 담당하고 있는 서버도 같이 2차 감염되어 백업된 스냅샷을 이용한 웹사이트를 불완전한 복원조차 할 수 없는 상황에 이르런 것입니다. 즉, 랜섬웨어 감염 이전에 백업해두었던 백업 서버의 화일까지도 2차 감염이 되어서 서비스 중인 서버 DB를 다른 서버에서 복원조차 할 수 없는 상태에 이르게 된 것입니다. 결국 17억원이란 거액의 몸값을 지불한 후 백업 화일의 암호화를 풀수 있었던 결과는 상황의 심각성을 잘 말해주고 있습니다. 그래서 다보리에서는 랜섬웨어에 의한 백업 서버의 2차 감염이 불가능하도록 하기 위한 방법으로 S3를 이용한 백업 서버 시스템을 구축해보았습니다.

goofys를 이용해 AWS - S3를 이용한 백업 스토리지 구축
S3 는 AWS 제품 시리즈중 가장 유용한 서비스중의 하나인데 가장 빈번하게 쓰이는 형태가 백업 시스템과 CDN 서비스를 위하여 구축되는 경우입니다. 오늘은 S3를 이용한 백업 파일 시스템으로 활용하는 것이 주목적입니다. 이 해결책으로 쓰이는 백업 패키지중의 하나가 FUSE 기반의 s3fs 입니다. 하지만 이 3 sfs의 가장 큰 이슈가 “너무 느리다”라는 단점이 있습니다. 그래서 이것보다는 성능이 좋다는 goofys 패키지를 이용하여 백업 화일 시스템을 구축하였습니다. goofys 또한 오픈소스는 아니며 aws에서 정식으로 지원하는 패키지는 아닙니다만 사용해본 결과 s3fs 보다는 훨씬 속도가 빨라서 실행 속도에 큰 불만은 없었습니다. goofys 설치와 운용은 이 블로그의 목적에 너무 벗어나므로 해당 설명을 원하시는 분은 개별적으로 연락하시기 바랍니다.
일별/월별 백업 시스템 스크립트 개발
화일시스템을 구축한 이후 일별로 백업하면서 백업 공간으로 절약하기 위해 최근 일주일 단위의 백업화일만 저장 할 수 있도록 백업 시스템을 정하였습니다. 그리고 혹시라도 사용자의 관리 소홀로 인하여 발생할 수 있는 웹사이트 – 소규모의 기업 웹사이트는 사용자 가 1주일 동안 이상 여부를 점검하지 않는 경우도 많으므로 – 의 복원의 범위를 늘리기 위하여 각 월별 백업을 12개월치를 보관할 수 있도록 하였습니다.
정리해보면 다보리의 웹사이트 백업 시스템은 매일 새벽 2시경에 자동 백업을 하며 이것을 최근 일주일 7일치의 백업을 보관하고 있습니다. 그리고 추가적인 문제를 해결하기 위하여 매월초 백업을 받아서 12개월 간의 보조 백업을 하고 있습니다. 이것은 사용자의 의지와 사용 방법과 무관하게 야간에 자동으로 백업을 받게 되므로 문제가 최소화되고 있습니다.

이제 문제는 어떻게 백업이 받아진 화일 시스템을 랜섬웨어로 부터 방어하느냐 입니다.
다보리에서는 각 개별 S3를 각각분리해서 저장하고 백업과 복원 당시에만 화일 시스템을 복원하는 것으로 이 문제를 해결하였습니다. 즉 랜섬웨어 자체가 화일 시스템으로 마운트 되지 않을 경우에는 어떤 경우라고 백업 화일 시스템을 감염시킬 수 없다는 것을 전제로 하여 백업 시스템을 설계하였습니다.
백업 시스템의 복원 방법
[root@xxx:1 parks]# seedaily [사용자 ID] <<현재 월별 백업 계정의 백업 현황 보기>>
-rw-r--r-- 1 root root 275409 Jul 10 17:28 /xxx/yyy/mytest-170710.sql.gz
-rw-r--r-- 1 root root  35442 Jul 10 17:28 /xxx/yyy/mytest-170710.tar.gz
-rw-r--r-- 1 root root 275408 Jul 11 02:02 /xxx/yyy/mytest-170711.sql.gz
-rw-r--r-- 1 root root  35442 Jul 11 02:02 /xxx/yyy/mytest-170711.tar.gz
-rw-r--r-- 1 root root 275408 Jul 12 02:02 /xxx/yyy/mytest-170712.sql.gz
-rw-r--r-- 1 root root  35442 Jul 12 02:02 /xxx/yyy/mytest-170712.tar.gz
[root@xxx:1 parks]# restoredaily  [사용자 ID]  yymmdd   <<백업된 화일을 가져옴>>
Backup files are restored at  /home/mytest/backups
[root@xxx:1 mytest]# cdz mytest
[root@xxx:1 mytest]# cd backups
[root@xxx:1 backups]# l
total 1884
drwxr-xr-x 2 root   root      4096 Jul 12 18:29 .
drwxr-x--x 3 mytest apache    4096 Jul 12 18:29 ..
-rw-r--r-- 1 mytest apache 1864693 Jul 12 18:29 mytest-170711.sql
-rw-r--r-- 1 mytest apache   51200 Jul 12 18:29 mytest-170711.tar
[root@xxx:1 backups]#

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

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


[워드프레스]다보리 웹호스팅에서 웹사이트 도메인 주소를 변경하는 경우

만약 기존의 www.domain.com를 www.domain2.com로 옮기려고 하면 다음과 같은 절차로 진행하여야 합니다.
(1) www.domain2.com 도메인 주소를 준비 ( 후이즈 등의 도메인 업체에서 도메인 구매 또는 양수)
(2) 네임서버를 현재 웹호스팅 IP주소로 연결
(3) 관리자 모드에서 워드프레스 캐시 “비활성화” 및 캐시 관련 설정 삭제
(4) 현재 호스팅에서 신규 도메인 주소로 호스팅 연결
(5) 워드프레스 홈페이지 DB내에 도메인 주소 링크 일괄 변경
(6) 새로운 도메인으로 웹사이트 작동 테스트 완료
(7) 관리자 모드에서 워드프레스 캐시 “활성화: 및 캐시 관련 설정 후 다시 한번 웹사이트 작동 테스트
을 하셔야 합니다.
(1)은 진행하신 후
(2)는 https://sym-wp.daboryhost.com/connect-webhost-without-changing-nameserver/ 로 진행해주시고 후 내용을 요청 티켓의 답변으로 추가해서 올려주시면
(4)(5) 번은 다보리에서 비용 추가 없이 진행해드립니다.

주의) 워드프레스 캐시를 사용하고 있는 경우
워드프레스에서는 다양한 캐시 플러그인이 지원됩니다. 편리한 점도 있지만 도메인 이전시에 큰 트러블 요소로 작용하는데 이미 캐시가 적용된 임시용 화일들이 이전 전의 도메인 주소와 절대 경로를 지정하고 있으므로 반드시 도메인 이전 이전에 사용중인 캐시를 관리자 모드로 들어가서 “비활성화” 해주시고 캐쉬 관련 설정의 사이트 링크 주소도 모두 삭제 해주시기 바랍니다.
사이트 이전 이후에 해당 도메인 주소에 맞도록 캐시 설정으로 다시 하시고 활성화 하여야 됩니다.

무료 웹호스팅(2) – 웹호스팅 관리 패널과 Kloxo-MR

안녕하세요 ?
오늘은 이전에 포스팅했던 다보리 무료 웹호스팅(1)에 이어서 이미 아마존에 개설된 가상 서버 상에서 이제는 웹호스팅 관리 패널을 설치하여 운영하는 방법에 대해 알아보도록 하겠습니다.
1. 웹호스팅 관리 패널(WHMCS: Web Hosting Management Control System)이란 ?
웹호스팅 관리 패널은 하나의 서버를 여러개의 웹사이트를 공유하여 사용할 수 있도록 서버의 백엔드 작업과 리눅스 명령 작업 시스템을 관리자 모드 형태의 웹사이트에서 웹호스팅 관리자/리셀러/사용자가 각각의 분리된 권한으로 직접 관리할 수 있도록 만든 웹 관리자 시스템입니다. 현재 유료 상용으로 가장 많이 알려진 웹호스팅 관리 콘트롤 패널(WHMCS)은 cPanel 로서 전세계에서 가장 많이 사용되고 있지만 라이센스 비용이 웹호스팅 갯수당 상당한 비용을 지불해야 함으로 중규모 이상의 웹사이트에 많이 적용하고 있습니다.
관리 기능을 보면
(1) 서버 관리자 -이 계정은 리눅스 서버의 루트 사용자와 같으며 서버 관리에 대한 모든 권한이 있습니다. 서버 관리자는 모든 리셀러나 사용자 계정을 생성, 수정, 삭제할 수 있으며 하위 관리 내용을 직접 수행할 수 있습니다. 서버 관리자는 WHMCS 의 백본(Backbone)이리고 할 수 있습니다.
(2) 리셀러 계정 -이 사용자는 리셀러 일반 사용자의 보다 상위 권한을 가진 계정으로 관리자에게 주어진 리셀러 계정의 사용자 계정을 생성, 수정, 삭제할 수 있으며 하위 관리 내용을 직접 수행할 수 있으며 제한된 권한을 가진 WHM에 액세스 할 수 있습니다.
사용자 계정 – 일반 사용자 계정은 웹 호스팅에 대한 실제적인 사용자이며 개별 웹사이트의 도메인과 FTP 계정 그리고 DB 계정을 생성할 수 있습니다. 하지만 사용자는 웹 호스트 관리자에 액세스 할 수 없습니다. 사용자 계정은 웹 호스팅 제공 업체에서 구매한 비용 계획(Price Plan) 에 따라 하나 또는 여러 개의 웹 사이트를 호스팅 할 수 있습니다.
위와 같이 WHMCS는 비전문가도 웹호스팅을 완벽하게 사용할 수 있는 GUI(Graphic User Interface)를 제공하므로 서버관리자의 업무를 대폭 줄여주고 서버 관리의 수준을 한층 강화시킵니다. 기본적으로 현존하는 모든 웹호스팅 업체의 품질은 얼마나 사용자의 편의와 사용자 인터페이스의 업무 동선이 합리적인 가에 의해 결정되며, 이러한 웹호스팅 자동화(WHA – Web Hosting Automation) 도구가 없었다면 서버 관리자의 유지 관리 비용으로 인하여 현재와 같은 저렴한 웹호스팅 비용을 수준을 유지할 수 없습니다.
2. Kloxo-MR (클록소-엠알)
이제는 웹호스팅에서 가장 중요한 기술 영역이라고 할 수 있는 웹 호스팅 자동화(Web Hosting Automation)을 위한 관리 패널에 대해 알아보겠습니다. 상용으로 월별 사용료를 받는 cPanel은 상용 WHA 도구중 가장 널리 알려져 웹호스팅 사업을 위한 사실상의 표준이라고 할 정도로 안정성과 기능을 자랑합니다. 하지만 다보리에서 내세우는 것은 무료 웹호스팅이므로 당연히 무료이며 오픈소스 진영에서 만들어 진 것이여야 하겠지요. 그런 면에서 Kloxo-MR은 여러 다른 WHA 도구와 비교하여 가장 웹호스팅 전문성이 보장되는 즉 수익형 웹호스팅의 기능을 강력하게 지원하는 도구라 할 수 있습니다.
kloxo-mr
그럼 Kloxo-MR는 기능과 특장점을 알아보도록 하겠습니다.
Kloxo-MR 의 특징
(1) 비록 무료이나 웹호스팅에 필요한 전체 기능이 포함되어 있다.
(2) cPanel과 유사한 UI가 지원됨으로써 관리자나 일반 사용자가 친근하게 접근할 수 있다.
(3) 다양한 메뉴와 기능을 제공함으써 여타 무료 WHA와는 달리 사이트 관리에 전문성 있게 접근할 수 있다.
(4) 실제 활용하고 있는 업체의 수가 많고 관련된 포럼이 만들어져 필요한 질의 응답을 할 수 있도록 구성되었다.
(5) 필요한 모든 언어 버젼을 추가하여 사용자별 스킨으로 제공이 가능하므로 국제적인 비즈니스를 창출할 수 있다.
[아래는 한글 구성이 적용된 Kloxo-MR의 메인 화면입니다.] kloxo-mr-panel-mainpage
다보리는 AWS EC-2와 Kloxo-MR를 기반으로 하는 무료 웹호스팅 서버를 제공함으로써 어떤 역할을 제공하게 될까요 ? 먼저 기술적인 경험으로 했다고 자만하지 않고 항상 배우는 자세로 이렇게 좋은 환경을 동종 업무에 종사하는 분들에게 소개하여 문제가 생기는 경우 기술적으로 경험이 부족한 분들에게 트러블 슈팅이나 시스템 확장이나 재구성시에 컨설팅을 제공할 계획입니다.
그러면 다음 블로그에서 아마존 웹서비스를 이용한 무료 웹호스팅이나 웹 호스팅 사업을 하시려고 하는 분들에게 어떻게 도움을 줄 수 있을까에 대해 정리해보도록 하겠습니다.

무료 웹호스팅(1) – 가상서버와 아마존 웹 서비스

안녕하세요 ?
오늘은 아마존 웹서비스와 Kloxo-MR 웹호스팅 관리 패널을 이용한 무료 웹호스팅을 진행하는 방법을 알아보도록 하겠습니다.
웹사이트를 만들때 가장 먼저 고려하는 기술적인 내용은 물리적인 웹서버을 어떻게 구성하는가 입니다. 웹서버에 경험과 지식이 없는 사람들은 처음에는 아주 Cafe24와 같은 저렴한 웹호스팅으로 시작했다가 많은 실망을 하고 웹호스팅을 용량이나 늘리거나 좀 더 나은 프로세스를 사용하는 것으로 옮기는 경우가 많습니다. 대부분 이해할 수 없는 상황으로 시간을 허비하고 비용을 지불하고 난 후 그제서야 웹호스팅의 중요성을 깨닫게 됩니다. 그런 이후 자신만의 웹 서버를 구축하여 좀 더 빠른 시간내에 관리업무를 진행했으면 하지만 그 경우 따로 서버 관리자를 두어 추가적인 인건비와 관리 시간을 투입해야 하므로 기존의 웹호스팅 업체에 불만이 있지만 그대로 주저않고 맙니다. 또한 한번 웹호스팅 업체에 자리를 잡은 후에 동일한 웹사이트를 다른 웹호스팅사에 옮긴다는 것은 리스크가 많습니다. 그런 소비자의 심리를 아주 잘 이용사여 사업을 확장해 나간 업체가 Cafe24 와 같은 웹호스팅 업체라 할 수 있습니다.
이제 웹호스팅의 업계 인프라도 많이 변화되어 미국에는 이미 많은 소규모의 웹호스팅 업체가 자리잡아가고 있습니다. 웹서버의 사용 비용이 파격적으로 인하되었고 웹호스팅을 전문적으로 관리할 수 있는 무료 웹호스팅 패널이 많이 나와 있기 때문입니다. 한편 서버의 비용을 사용하는 지불하는 아마존 웹 서비스(Amazon Web Service)가 나온지 10년이 되어 이미 비지니스 모델의 안전성은 이미 검증되었습니다. 그러한 이러한 상황을 어떻게 잘 조합하여 무료 웹호스팅이 어떤 식으로 구성하는지 기술적인 요소 부터 먼저 알아보도록 하겠습니다.

1. 가상 서버란 ?
가상 서버란 하나의 물리적인 Host 서버에서 여러개의 독립된 Guest 서버 영역으로 분할하여 각각 독립적인 서버처럼 동작하게 만든 서버 체계 입니다.
가상서버(VPS 호스팅/클라우드)와 물리서버(웹호스팅/서버호스팅)는 물리적 IT 자원을 어떻게 사용하는지에 따라 아래와 같이 나눌 수 있습니다.
%ea%b0%80%ec%83%81%ec%84%9c%eb%b2%84-%ec%a0%84%ec%9a%a9%ec%84%9c%eb%b2%84
(1) VPS호스팅/클라우드
물리적 IT 자원과 가상화 기술의 결합으로써 서버 1대에 들어가는 물리적 시스템 자원을 여러 가상서버(VM)로 분할하여 마치 개별 서버처럼 운영될 수 있도록 제공하는 것으로, 사용자가 직접 관리자 권한을 가지고 할당된 자원을 자유롭게 운영할 수 있습니다.
(2) 웹호스팅
물리적 IT 자원을 여러 사용자 나눠 사용하며 서버 1대에 들어가는 물리적 시스템 자원을 여러 사용자가 공용으로 사용하며, CPU/Disk/Memory 등 각 고객이 서로의 사용량에 영향을 받기 때문에 속도가 느려지는 경향이 있습니다. 서버 관리에 대한 독립 권한이 없어 사용에 제한이 있습니다.
(3)서버호스팅
물리적 IT 자원을 한 사용자 단독 사용하므로 서버 1대에 들어가는 물리적 시스템 자원을 한 사용자가 독립적으로 사용하므로 속도와 보안성이 우수합니다. CPU/Disk/Memory 등을 사용자가 관리 권한을 가지고 직접 자유롭게 운영할 수 있습니다.
(4) 가상서버 이해에 필요한 용어
용어 설명
1. 가상화 하나의 물리적 자원을 여러 대의 논리적 시스템으로 활용하는 방안으로, 기존에는 하나의 하드웨어 시스템에 하나의 운영체제(OS)를 동작시켰으나 하드웨어 성능이 발전함에 따라 하나의 하드웨어에 여러 대의 운영체제(OS)를 설치하여 자원(CPU/Memory/disk)을 공유하는 소프트웨어 기술이다.
2. 서버 가상화 한 대의 물리적 서버를 여러 대의 가상 머신으로 나눠 쓰는 것을 말한다. 가상 머신을 만들 때 사용되는 기술을 하이퍼바이저(Hyperviser)라 하고, 주로 Vmware/Xen 등과 같은 가상화프로그램을 통해 이루어진다.
3. 가상 머신 가상 서버 = VM = VDS = VPS = Virture Machine
4. 하이퍼바이저(Hyperviser) 가상 머신의 생성/삭제를 관장하고, 게스트 머신의 운영체제를 활성화시켜주는 일종의 소프트웨어이다. 예를 들면 VMWare나 Vagrant가 그것이다.
5. vCore vCore란 ‘Virture Core’로, 1대의 가상서버에 연결되는 CPU 속 core를 의미한다. CPU가 사람의 ‘뇌’라고 한다면, core는 ‘좌뇌/우뇌’ 등 뇌 안의 구성요소라고
볼 수 있으며, 동시에 몇 가지 일을 수행할 수 있는지를 의미한다. 업체별 상품을 보면 ‘2vCore/4vCore’ 등의 표시를 볼 수 있는데, 결국 1대의 VM에 구성되어 있는 core의 개수를 뜻하는 것이다.예를 들어, 2vCore는 2core가 들어있는 1대의 VM을 임대한다는 것이다. core 개수 많을수록 동시에 해결할 수 있는 능력이 커지므로 2vCore 보다 4vCore가 속도가 더 빠르고 성능이 좋은 것이다.
[하이퍼바이저에 대한 설명 그림] vps_5
2.아마존 웹 서비스(Amazon Web Service)
그럼 여기서 다보리가 무료 웹 호스팅을 제공할 수 있는 원천이 되는 아마존 웹 서비스에 대해 알아보도록 하겠습니다. 가상서버 서비스, 즉 클라우드 서비스로 가장 알려져 있는 아마존 웹서비스는 2006년 3월 14일 그 서막을 연 이후 지금까지 10년 넘게 지속되어 지금은 클라우드 컴퓨터의 대명사로 자리잡았습니다. 그러한 아마존 웹서비스의 장점은
AWS_LOGO_500
(1) 서버에 대한 기초 투자 비용을 사용량에 따른 가변 비용으로 대체할 수 있습니다.
실제 초기 기업이나 소기업이 시작한 서비스이 성장을 미리 예측하기 힘들기 때문에 사용한 만큼 돈을 지불할 수 있다는 것은 꽤 호소력이 있는 제안입니다. 단순히 단독 서버 뿐만 아니라 웹서비스와 관련된 DB서버인 IDS, 네임서버인 Route53, 대용량 저장장치인 S3 그리고 cDN 서비스인 Cloudfront 등 대기업에서만 제공할 수 있는 다양하고 강력한 기능들을 소기업에서도 사용하면서 사용한 만큼만 돈을 지불하는 방식으로 데이터 센터 비스니스에 대하여 완전히 새로운 개념을 정립하였고 이를 바탕으로 전세계에서 AWS 센터를 설립하여 승승장구하고 있습니다.
(2) 가변 비용으로 전환한 비용도 예전 비용보다 적게 들어갑니다.
아마존이 가진 서버나 와이브로 서비스에 대한 구매력은 규모의 경제를 바탕으로 세계 최고를 자랑하고 있습니다. 규모의 경제를 바탕으로 저렴한 가격으로 구매한 장비와 서비스를 구매하여 박리다매 형식으로 고객에 공급하므로써 실제 기존의 IDC센터에서 전용 서버를 임대하는 것 보다 저렴한 가격으로 서비스를 받을 수 있습니다.
(3) 필요한 서비스를 언제든지 확장할 수 있습니다.
AWS가 제공하는 확장선은 일반 웹호스팅 또는 전용 서버 서비스와는 차원이 다른 확장성으로 제공합니다. 필요한 만큼 모든 서비스를 제단하여 적용하므로서 사용자는 기술에 대해 아는 만큼 저렴하게 서비스를 제공 받을 수 있습니다. 따라서 CPU 속도, 저장 공간, 트래픽 등 자신이 원하는 어떤 서비스라도 부페식으로 자유롭게 선택 또는 확장이 즉시 가능하도록 구성되어 있습니다.
(4)소기업을 위한 대기업 품질의 서비스
지금까지 대기업은 항상 소기업보다 IT 기술에 대한 더 많은 혜택을 받았습니다. 하지만 AWS를 이용한다면 이것은 더 이상 사실이 아닙니다. 예를 들면 AWS에서는 소기업을 위해 수십억원의 가치가 있는 세계 표준의 보안 서비스가 무료로 제공됩니다. 이것은 클라우드 서비스를 사용하는 고객으로써는 가장 중요한 장점중의 하나가 되었습니다. 그리고 서버 부하를 줄이고 웹 페이지의 다운로드 속도를 향상 시키기 위한 일반 대기업 이상 수준의 서비스가 매우 저렴한 비용으로 제공되고 있습니다.
(5) 표준화된 AWS 관리 콘솔
AWS 관리 콘솔은 AWS 서비스의 허브입니다. 이는 사용자가 AWS 계정으로 서비스 추가, 비용 확인, 계정 정보 변경, 사용 변경 등 을 확인할 수 있게 해드립니다. 이는 더운 쉽고 간편하게 웹사이트 및 데이터를 변경하게 하며 어디에서도 기술 지식이 없는 사람들이 진행할 수 없는 것을 진행할 수 있게 도와드립니다.
[아마존에서 제공하는 무료 서비스 내용] %ec%95%84%eb%a7%88%ec%a1%b4%ed%94%84%eb%a6%ac%ed%8b%b0%ec%96%b4
다보리는 AWS가 제공하는 이러한 장점을 직관적으로 판단하여 무료 웹호스팅에서 시작하여 협력업체들의 웹 서비스를 초기 비용 부담 없이 점진적으로 확장시켜 나갈 수 있도록 지원하고 있습니다.
그러면 일반 웹사이트 제작자가 서버 기술이 없는데이런 좋은 서비스를 어떻게 활용할 수 있나요 ? 다음 페이지를 보시면 방법이 제시됩니다.

SSL 인증서와 웹 보안

안녕하세요 ?
오늘은 다보리 워드프레스 웹호스팅에서 아마존 웹서비스(AWS)의 AWS Certificate Manager 사용법과 – 무료 SSL/TLS 인증 서비스를 이용하는 방법에 본격적으로 들어가기전에 먼저 SSL과 SSL 인증서에 대하여 상세한 사전 지식을 알아보고 진행할 수 있도록 하겠습니다.

개인정보를 기반으로 웹서비스를 제공하는 사이트는 SSL 인증서 구축이 의무화
왜 SSL 을 워드프레스 쇼핑몰에서 언급하냐구요. 사실은 온라인 쇼핑몰을 운영하거나 개인정보를 기반으로 웹서비스를 제공하는 사이트는 SSL 인증서 구축이 의무화 되어 있기 때문입니다. 그 근거는 정보통신망 이용촉진 및 정보보호 등에 관한 법률(보통 ‘정보통신망법’이라고 함) 제 28조에 있습니다.
​제 1항에서 정보통신서비스 제공자(쇼핑몰, 콘텐츠 제공사이트 등 웹사이트를 통한 서비스 제공자) 등이 개인정보를 처리할 때 개인정보의 보호조치(기술적 관리적 조치)를 규정하고 있습니다. 그 중 하나가 제 4목에 개인정보를 안전하게 저장전송할 수 있는 암호화기술 등을 이용한 보안조치입니다. ​여기서 말하는 안전하게 저장 전송을 위한 암호화 기술 중 하나가 바로 SSL 인증서를 통한 암호화입니다.
SSL 인증서란
우리는 웹브라우저 주소 창에 https://www.google.com 형태처럼 보이는 녹색 열쇠 표시를 다른 여러 웹사이트에서도 볼 수 있습니다. 그러면 웹 브라우저 주소창에 왜 녹색 열쇠를 표시할까요? SSL/TLS 인증서로 알려진 디지털 인증 파일이 있기 때문입니다. 이것은 고객과 웹 사이트 간에 인증과 신뢰를 제공하기 위한 전자 문서입니다. 표면적으로는 단순하지만 그 이면에는 복잡한 구조인 기술이 있습니다! 웹 브라우저에 열쇠 아이콘이 있으면, 웹 사이트 데이터 전송 자체가 암호화되어 있다는 것을 보여줍니다. 즉 https 로 시작하는 웹사이트는 SSL은 Secure Sockets Layer 인증이 되어 있다는 것을 의미하며 이 것은 웹 브라우저와 웹 서버 사이에 암호화된 통신을 구현하는 글로벌 표준 보안 기술입니다. 이를 통하여 웹사이트와 개인들의 중요정보(예: 신용카드 번호, 사용자이름, 암호, 이메일 등)가 해커에 의해 도용되거나 삭제되는 위험을 줄이고 해킹를 파악하는 데 사용하고 있습니다. 요약하자면, SSL은 두 의도된 당사자들만의 사적인 “대화”를 가능하게 해 줍니다.
SSL/TLS는 중요한 정보를 교환 할 때마다 필요합니다. 예를 들어, 사이트가 PCI-DSS, FISMA과 같이 규정 준수를 해야 하는 경우 혹은 의료 데이터 전송을 위한 HIPAA 규정에서도 SSL/TLS를 이용하도록 하고 있습니다.
SSL(Secure Socket Layer) 프로토콜은 처음에 Netscape사에서 웹서버와 브라우저 사이의 보안을 위해 만들어 졌습니다.. SSL은 Certificate Authority(CA)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다. 아래는 SSL이 어떻게 작동하는지에 대한 간단한 과정을 설명합니다.
[웹브라우저] SSL로 암호화된 페이지를 요청하게 된다. (일반적으로 https://가 사용된다)
[웹서버] Public Key를 인증서와 함께 전송한다.
[웹브라우저] 인증서가 자신이 신용있다고 판단한 CA(일반적으로 trusted root CA라고 불림)로부터 서명된 것인지 확인한다. (역주:Internet Explorer나 Netscape와 같은 웹브라우저에는 이미 Verisign, Thawte와 같은 널리 알려진 root CA의 인증서가 설치되어 있다) 또한 날짜가 유효한지, 그리고 인증서가 접속하려는 사이트와 관련되어 있는지 확인한다.
[웹브라우저] Public Key를 사용해서 랜덤 대칭 암호화키(Random symmetric encryption key)를 비릇한 URL, http 데이터들을 암호화해서 전송한다.
[웹서버] Private Key를 이용해서 랜덤 대칭 암호화키와 URL, http 데이터를 복호화한다.
[웹서버] 요청받은 URL에 대한 응답을 웹브라우저로부터 받은 랜덤 대칭 암호화키를 이용하여 암호화해서 브라우저로 전송한다.
[웹브라우저] 대칭 키를 이용해서 http 데이터와 html문서를 복호화하고, 화면에 정보를 뿌려준다.
전문 용어라서 좀 복잡하지만 위의 내용은 웹브라우저 웹서버간에 주고 받는 정보를 Public Key와 Private Key를 이용하여 암호화된 정보로 송수신함으로써 중간에 네트워크 중간에서 해커가 정보를 탈취하더라도 사용할 수 없도록 하자는 것이 작동 원리 입니다.
개인키/공개키(Private Key/Public Key)
Private key/Public Key를 이용한 암호화는 하나의 키로 암호화하고 나머지 다른 하나로 복호화할 수 있도록 되어있습니다. 암호화한 키로만 암호화를 할 수 있는 것이 아니라 반대 방향으로 복호화한 키로도 암호화할 수도 있다. 이러한 키쌍은 소수(prime number)로부터 생성되며, 그 길이(Bit 단위)는 암호화의 강도를 나타냅니다. Private Key/Public Key는 이러한 키쌍을 관리하는 방법으로 한개의 키는 안전한 장소에 자기만 알 수 있도록 보관하고(Private Key) 다른 하나는 모든 사람에게 퍼뜨리는 것(Public Key)이다. 그렇게 하면 그 사람들이 당신에게 메일을 보낼 때 암호화해서 보낼 수 있으며, 보낸 쪽에서만 그 암호를 Private Key를 이용하여 풀 수 있다.
인증서(Certificate)
사용자가 접속을 한 웹 사이트가 믿을 수 있는지 어떻게 판단하기 위해서 해당 사이트의 인증서를 확인하는 방법으로 진행됩니다. 이것은 공적으로 인증할 만한 기관에서 인증서를 웹사이트에 설치하여 신뢰성을 보장하는 방법입니다.
인증서는 여러 부분으로 이루어져있으며 아래는 인증서 속에 들어있는 정보의 종류를 입니다.
1. 인증서 소유자의 e-mail 주소
2. 소유자의 이름
3. 인증서의 용도
4. 인증서 유효기간
5. 발행 장소
6. Distinguished Name (DN)
– Common Name (CN)
– 인증서 정보에 대해 서명한 사람의 디지털 ID
7. Public Key
8. 해쉬(Hash)
SSL의 기본 구조는 당신이 인증서를 서명한 사람을 신뢰한다면, 서명된 인증서도 신뢰할 수 있다는 것이다. 이것은 마치 트리(Tree)와 같은 구조를 이루면서 인증서끼리 서명하게 됩니다. 최상위 인증서에 대해서 이 인증서를 발행한 기관을 Root Certification Authority(줄여서 Root CA)라고 부르며, 유명한 인증 기관(역주:Verisign, Thawte, Entrust, etc)의 Root CA 인증서는 웹브라우저에 기본적으로 설치되어 있습니다. 이러한 인증 기관은 자신들이 서명한 인증서들을 관리할 뿐만 아니라 철회 인증서(Revoked Certificate)들도 관리하고 있으며 모든 Root CA 인증서는 자체 서명(Self Signed)되어 있습니다.
대칭키(The Symmetric key)
Private Key/Public Key 알고리즘은 정말 대단한 알고리즘이지만, 비실용적이라는 단점이 있습니다. 비대칭(Asymmetric)이란 하나의 키로 암호화를 하면 다른 키가 있어야 복호화를 해야 하기 때문에 속도의 문제가 발행합니다. 대안으로써 대칭키(Symmetric Key)는 하나의 키로 암호화/복호화를 할 수 있습니다. 대칭키를 사용하면 비대칭키보다 훨씬 빠르게 암호화/복호화를 할 수 있지만 너무 위험한 방법입니다.
만약 해커가 이 키를 탈취해 버리면 여태까지 암호화된 정보가 모두 무용지물이 되어버리게 됩니다. 일반적으로 사이트와 사이트간에 데이터를 주고 받은 인증키라는 것이 이 대칭키 방식으로 되어 있습니다. 이 대칭키는 서비스를 하는 웹사이트에서 복사해서 서비스 받는 웹사이트에 붙여넣고 저장하는 수작업을 거치는 경우가 대부분입니다. 이런 것에 대한 해결책은 대칭키를 비대칭키로 암호화시켜서 전송하는 방법을 사용하는데 이 경우 자신의 Private Key만 안전하게 관리하면 Public Key로 암호화되어 안전하게 전송할 수 있으며 대칭키를 하나의 접속 세션동안 매번 랜덤으로 생성하면 만약 해당 세션에서 대칭키가 누출되어도 다음세션에서는 다른 키가 사용되기 때문에 안전합니다.
암호화 알고리즘(Encryption Algorithm)
암호화 알고리즘은 대칭이든 비대칭이든 간에 상당히 많은 종류가 있으며 일반적으로 암호화 알고리즘으로 특허를 낼 수 없습니다.
이것은 웹서버와 브라우저가 서로 통신을 하는 동안 서로 어떤 알고리즘을 사용할 수 있는지 확인하며 서로 이해할 수 있는 일반적인 알고리즘을 선택한 후 통신이 이루어지게 된다. OpenSSL은 컴파일해서 삽입할 알고리즘을 택할 수 있으며 이 경우 해당 암호화 알고리즘에 제한을 걸고 있는 국가에서도 사용할 수 있게 됩니다.
해쉬(Hash)
해쉬값는 해쉬 함수에 의해 만들어지는 숫자로써 단방향으로 연산되는 함수입니다. 즉, 한번 해쉬함수로 원본으로부터 해쉬값을 생성했다면, 해쉬값으로부터 원본 메시지를 알아내는 것이 불가능하다. 해쉬의 용도는 단순히 원본 메시지가 손상이 되었는지를 알아내는데 있으며, 해쉬값을 변경시키지 않고 원본을 조작하는 것은 극히 어렵다. 그래서 해쉬 함수는 패스워드 메커니즘이외에도 소프트웨어의 손상 유무(MD5 sum) 확인, 메시지의 손상을 방지하기 위해 널리 쓰이고 있습니다.
서명(Signing)
서명은 특정 메시지를 내가 작성했다는 것을 인증하는 역할을 하며, Text가 될 수도 있고, 인증서 그 자체도 될 수 있습니다. 보내는 메시지에 서명하기 위해서는 아래의 순서를 따라야 한다.
1. 해쉬 생성
2. Private Key로 해쉬 암호화
3. 암호화된 해쉬와 서명된 인증서를 메시지에 추가
4. 받는 사람은 따로 해쉬를 생성
5. 받은 메시지에 포함된 해쉬를 Public Key를 이용해서 복호화
4, 5번 과정에서 생성된 해쉬를 비교
암호문(Pass Phrase)
암호문(Pass Phrase)은 기존의 패스워드(Password)를 확장한 시스템으로 예전의 Unix 시스템의 암호(Password)는 8자가 한계였습니다. 암호문이라는 것은 단순히 암호의 한계가 더 길어졌다는 것을 뜻합니다. 당연히 8자가 한계인 것보다 보안이 강력하며 최근의 Unix 시스템은 MD5를 사용하고 있기 때문에 암호의 길이 제한이 없어졌습니다.
다음 블로그에서는 아마존 웹서비스(AWS)의 AWS Certificate Manager 사용법과 – 무료 SSL/TLS 인증 서비스를 이용하는 방법을 알아보도록 하겠습니다.

아마존 웹서비스(AWS) Route 53의 장점과 네임서버 연결 방법

안녕하세요 ?
국내 유일의 무료 워드프레스 쇼핑몰 “우커머스 교실”에서 오늘은 워드프레스 웹호스팅에서 아마존 웹서비스(AWS)이 네임서버 서비스인 Route 53 서비스이 장점과 그 연결하는 방법을 알아 보겠습니다. 다보리 워드프레스 웹호스팅에서 Route 53 으로 네임서버를 연결하여 바꾸는 것은 의외로 간단합니다.

Route 53의 장점
Amazon Route53의 장점은
(1) 지연시간 기반 연결(Latency Based Routing)
이것은 도메인 하나에 각 지역별로 가장 빠른 곳으로 연결해주는 서비스입니다. 접속자하는 사용자가 전세계 어디서든 가장 반응이 빠른 네임서버로로 연결해주는 아주 훌륭한 서비스입니다.예를들어 사용자의 웹사이트 접속 지점이 대한민국이라면 서울의 리전에 있는 네임 서버로 연결하고 LA에서 접속하면 캘리포니아 리전으로 연결하여 접속 지역에 맞추어 접속 속도를 최상으로 유지할 수 있는 것입니다. 이와 비슷한 서비스로써는 GeoDNS가 있는데 GeoDNS는 접속하는 지역에 따라서 가장 가까운 곳으로 접속 할당을 해주는 것입니다.
(2) 속도가 아주 빠른 유료 DNS 기반
일반적으로 한국의 도메인 주소 서비스 업체에서 무료로 제공하는 네임서버는 대부분 4개 이하로써 고정되어 있습니다. 이로 인하여 해당 호스팅사에서 트래픽이 증가하면 네임서버 연결 단에서 먼저 시간 지체(Latency)가 일어나기 시작합니다. Route 53 에서는 해당 지역 리전의 가용 영역(Avaiable Area)에서 작동되는 수 천대의 네임서버에서 서버로드가 가장 작은 무작위 순서를 정해 할당하므로 네임서버의 동작 속도가 무척 빠릅니다. 즉, 비용을 지불하므로서 빠른 속도가 보장되는 것입니다. 다보리에서는 해당 비용부분을 감수하고 웹사이트 속도를 개선하기 위하여 Route 53 네임 서버를 무료로 제공하고 있습니다.
(3) 헬스 체크와 Fail Over
Route53은 자체적으로 Health check 기능을 가지고 있습니다. 즉, 하나의 DNS 명에 대해서 여러개의 IP 주소를 반환할 수 있는데, 해당 ip의 서버의 상태를 체크해서 장애 상태인 경우에는 네임서버의 리스에서 제외하고 있다가 장애가 복구 되면 다시 리스트에 추가하는 형태이므로 웹서버의 셧 다운타임을 최소로 하고 웹 사이트 반응 속도를 최대로 할 수 있는 기반 기술을 제공합니다.
(4) 속도 증가를 위한 CDN 기능 추가시 속도가 더욱 증가
Route53와 AWS의 CDN 웹서비스인 Cloudfront의 경우 해당 지역의 동일한 가용 영역 내에서는 타 CDN 보다 훨씬 빠르게 동작할 수 있습니다.
도메인 주소 확인
일반적으로 네임서버를 옮기는 경우 그와 관련된 회사 메일 정보인 MX 레코드, TXT 레코드 값이나 서브 도메인 관련된 A 레코드 값이나 CName 값등을 모두 이전하여 기록하여야 하므로 상당히 번거롭고 실수가 나지 않도록 신경을 써야 되는 작업입니다. 그런 부분은 고려하여 Route 53은 고맙게도 Hosted Zone Records 를 그대로 업로드할 수 있도록 되어 있습니다. 네임서버 이전이전에 해당 네임서버를 관리하는 업체(도메인 서비스 업체 또는 웹호스팅 업체)에 의뢰하여 텍스트 화일로 된 호스팅 존 레코드(Hosted Zone Records) 화일을 요청하면 한 후 이것을 이메일로 보내주시면 혼선 없이 그대로 Route 53의 Zone Record로 업로드하여 착오없이 네임서버의 이전을 마무리하게 됩니다.
(1) 변경할 도메인 주소를 다보리에 통보한다. ( 주소 예: daboryhost.com )
(2) 이전의 네임서버 관리 업체에 의뢰하여 받은 호스팅 존 레코드(Hosted Zone Records) 화일을 다보리로 이메일 전송한다.
(3) 다보리에서 네임서버 등록 완료 통보 메일를 받으면 보내준 웹페이지 링크 주소를 보고 도메인 서비스 업체 웹사이트에서 아래와 같이 네임서버 주소를 변경한다.
※ 네임서버 변경시 인터넷 상에서 네임서버 IP 전파가 되는 시기가 웹사이트 접속의 장소마다 조금씩 다르므로 참고 하시고 전세계에 퍼지는 기간은 1일에서 3일정도 소요됩니다.
다보리 Route 53 네임서버
타 업체 도메인의 네임서버를 다보리의 Route 53 네임서버로 변경할때는
현재 사용하고 계신 도메인 등록 업체에 문의 또는 로그인 하여 네임서버를 아래와 같이 변경해주시면 됩니다.
차수 도메인명 IP 번호
1차 네임 서버 메일에 명시된 값 자동입력
2차 네임 서버 메일에 명시된 값 자동입력
3차 네임 서버 메일에 명시된 값 자동입력
4차 네임 서버 메일에 명시된 값 자동입력
* 대부분의 도메인 서비스 업체에서는 네임서버 도메인 주소를 입력하면 IP 주소를 자동을 찾아주므로 입력할 필요가 없습니다.
* 간혹 도메인 서비스 업체가 IP를 입력하게 하는 경우(제대로 시스템을 안 만들어 놓은 경우) 번거롭기는 합니다만 아래의 링크를 이용하여 각 네임서버의 IP 번호를 찾아서 입력해주셔야 합니다.

[AWS] Amazon EC2 – TIMEZONE(시간대) 변경

안녕하세요 ?
국내 최초의 아마존 웹서비스를 이용한 워드프레스 쇼핑몰 웹호스팅을 시작한 다보리의 “아마존 웹서비스 매뉴얼”입니다. 다보리의 아마존 웹서비스 매뉴얼은 이미 아마존 매뉴얼에 있는 내용을 낚시밑밥처럼 만든 것이 아니라 매뉴얼에 나오지 않지만 유용한 팁이나 쓸데없는 노가다를 줄여줄 수 있는 내용들로만 구성하고 있습니다. 오늘은 AWS에 서버를 설정한 후 Timezone 시간대 설정을 추가하는 방법을 알아 보도록 하겠습니다.

Timezone이란 ?
영국의 그리니치 천문대를 기준으로 각국의 시차를 정했습니다. 글로벌 웹서비스인 AWS에서 서버에 리눅스 (AWS EC2 AMI도 Linux와 동일)를 설치하면 그들의 기준에 맞추어 캘리포니아 현지 시간으로 표시됩니다. 이럴 경우 한국 표준시인 KST로 변경해주어야 웹사이트에 표시되는 시간이나 데이터베이스에 자동으로 삽입되는 Timestamp와 같은 필드에 원하는 시간대의 표준시각이 기록이 됩니다.
컴맨드 라인
먼저 ssh EC2의 리눅스로 로그인하여 표준 시간대에 맞추어 시간 수정으로 리부팅하여 반드시 확인해 주세요.
Last login: Fri Jul 22 16:02:30 2016 from 182.228.226.119
[centos@ip-172-31-14-128 ~]$ sudo -i
[root@생물나라:0 ~]# date
Sat Jul 23 04:30:58 UTC 2016
[root@생물나라:0 ~]# cat /etc/localtime
TZif2UTCTZif2UTC
UTC0
[root@생물나라:0 ~]# rm /etc/localtime
rm: remove regular file `/etc/localtime'? y
[root@생물나라:0 ~]# ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime
[root@생물나라:0 ~]# date
Sat Jul 23 13:32:34 KST 2016
[root@생물나라:0 ~]# reboot
Last login: Sat Jul 23 13:30:47 2016 from 182.228.226.119
[centos@ip-172-31-14-128 ~]$ sudo -i
[root@생물나라:0 ~]# date
Sat Jul 23 13:34:39 KST 2016

워드프레스 네이버 신디케이션의 개념과 기술적 내용

안녕하세요 ?
국내 유일의 워드프레스 쇼핑몰 교육 모임인 “우커머스 교실”에서 오늘은 네이버가 새롭게 발표된 비지니스 웹사이트 노출 정책에 맞추어 워드프레스 웹사이트를 어떻게 하면 네이버에 잘 노출시킬 있을까는 연구해 보았습니다. 즉 네이버의 웹사이트 등록 서비스인 ‘네이버 마이 비지니스’가 ‘네이버 웹마스터 도구’로 통합된 것은 이미 웹문서 검색에서 구글에 밀리기 시작하고 있다는 것을 반영하고 있는 것인데 앞으로 국내 검색 광고 시장이 어떻게 변화될지 흥미진진한 관전 포인트가 될 것 같습니다. 이번 통합 노출 정책에 의하여 네이버 신디케이션은 이제 ‘웹문서과 사이트’ 2가지의 항목에 노출되기 시작했고 네이버 신디케이션이 잘되면 가산점을 적용되어 ‘사이트’영역에 더욱 잘 노출됩니다. 오늘은 네이버 신디케이션의 개념부터 네이버 신디케이션을 워드프레스에 어떻게 잘 적용하는가를 알아 보도록 하겠습니다.

신디케이션(syndicaton)이란 ?
미국에서는 ‘조직 폭력 연합’을 신디케이트라고 부르기도 하고 영화 제목으로도 사용된 적이 있습니다만 어떻게 보면 일반 워드프레스 홈페이지 그룹이 네이버의 웹문서와 사이트 영역에 노출되기 위해서 서로 연합하는 것으로 보면 되겠습니다. 기술적인 내용을 구체적으로 설명하면 컨텐스를 보유하고 있는 독립 웹사이트와 컨텐츠를 찾아주는 검색 서비스간의 동기화 규칙을 정의해놓은 신디케이션 API 에서 유래한다고 생각하시면 됩니다. 그러면 구글과 같은 검색엔진이 전적으로 의존하는 사용하는 웹로봇 방식과는 어떻게 다른가요.
1. 웹로봇 방식
크롤링은 무수히 분산된 웹 사이트의 분산된 문서를 검색 대상으로 무작위 방식으로 색인하는 기술로써 일반적으로 웹 크롤러 기술이라고 하는 이것를 수행하는 소프트웨어를 웹로봇이라고 부릅니다. 일반적으로 사이트 전체를 다운로드 받거나 하는데 이때 웹사이트에서 제공되는 XML 문서로 된 사이트 맵이 제공되는 좀더 효율적으로 색인을 할 수가 있습니다.
2. 신디케이션 API 방식
웹로봇 방식으로 웹사이트에 많은 부하화 수집된 데이터의 비정형화로 인하여 검색 서비스를 제공하기 위한 결과를 분석하기가 어렵다는 단점이 있습니다. 즉 검색 결과를 친절하게 정리해주지 못한다는 점입니다. 반면에 신디 케이션 API 방식은 이런 단점으로 보완하기 위하여 웹사이트에서 CRD(등록,수정,삭제)가 발생하는 즉시 검색 서비스 사이트에 Ping 보내서 변화된 것만 수집하도록 규정합니다.
3. 신디케이션 API 방식의 장단점.
신디케이션 API 방식의 장점
(1) 웹사이트와 검색 사이트 모두 서버 부하가 감소.
(2) 컨텐츠의 타이틀, 내용, 태그등 중요 정보가 검색 색인에 정확하게 반영
(3) Ping을 통한 정보 수집으로 웹사이트 소유자가 정한 컨텐츠만 제공.
신디케이션 API 방식의 단점
(1)신디케이션 API를 개발하여 웹사이트에 직접 설치 해주어야 한다.
(2) Ping 방식이므로 검색 서비스가 해킹당할 수도 있다.
(3) 해커에 API Key를 탈취당할 경우 어뷰징으로 Standby혹은 심하면 Block 당할 수 있다.
4. 신디케이션 관련 용어
용어 설명
엔트리(entry) 웹 사이트의 한 페이지
피드(feed) 여러개의 엔트리를 담고 있는 채널(예: 게시판, 카테고리) 정보
신디케이션 문서 네이버에게 웹 사이트의 콘텐츠를 전달할 수 있도록 XML 문서
핑(ping) URL 네이버 신디케이션 문서의 위치를 지정한 URL
신디케이션 기술요소 해설
1. 신디케이션 프로토콜
신디케이션 프로토콜 순서
(1) 요청 웹사이트는 검색 서비스 사이트로 핑(ping)을 보낸다.

이 때 Ping 요청 속에는 “신디케이션 문서 URL”을 함께 전달
(2)검색 서비스는 Ping 요청시 전달된 신디케이션 문서 URL로 접속
(3)신디케이션 문서를 읽어옴
0-k6oo5kkxj76Qr8uH
2. 신디케이션 문서의 예

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://webmastertool.naver.com">
    <id>
        http://www.syndi-example.com/bbs/
    </id>
    <title>Naver Syndication Sample Document</title>
    <author>
        <name>webmaster</name>
        <email>webmaster@donotsend.email</email>
    </author>
    <updated>2014-06-26T20:10:49+09:00</updated>
    <link rel="site"
        href="http://www.syndi-example.com"
        title="Naver Syndication Sample Document" />
    <entry>
        <id>
            http://www.syndi-example.com/bbs/board.php?bo_table=search_info&amp;id=63643
        </id>
        <title><![CDATA[검색 잘되는 웹문서 만들기란?]]></title>
        <author>
            <name>user_name</name>
        </author>
        <updated>2014-06-26T20:10:48+09:00</updated>
        <published>2014-06-26T20:10:48+09:00</published>
        <link rel="via"
            href="http://www.syndi-example.com/bbs/board.php?bo_table=search_info"
            title="검색정보 게시판" />
        <link rel="mobile"
            href="http://m.syndi-example.com/bbs/search_info/63643" />
        <content type="html"><![CDATA[<div class="webguide_area"><h4>검색 잘되는 웹문서 만들기란?</h4><p>검색등록 서비스를 통해 검색반영 신청하신 사이트 내의 모든 URL(페이지)는 기본적으로 검색로봇이 방문할 대상으로 인식하여, 네이버 검색로봇이 주기적으로 방문 후 <br />검색에 함께 자동 반영하고 있습니다.<br />네이버 검색팀에서는 당신이 소중히 관리하는 사이트 및 내부의 좋은 문서들이 네이버 검색 및 여타 검색로봇에 잘 반영되도록 기술적으로 지원하고자 합니다. <br />이를 위해 네이버 및 다른 모든 <strong>검색로봇에 잘 수집-노출되는 웹문서를 만들기 위한 방법</strong>을 가이드페이지로 제작하여 1차 공개합니다. <br />추후 사이트 운영자분들에게 도움이 될 다양한 기능 및 정보를 추가로 제공할 예정이니 많은 관심 부탁드리며,<br />특히 <em>본인이 사이트 운영자이지만 개발자가 아닌 경우, 개발자(웹마스터)에게 꼭 이 페이지를 알려</em>주시고 검색에 잘 나올 수 있도록 고쳐달라고 부탁하시기 바랍니다.<br /><br />(원본 출처 : <a href="https://submit.naver.com/web.nhn" target="_blank" rel="noopener noreferrer">클릭</a>)</p></div>]]></content>
        <summary type="text"><![CDATA[검색 잘되는 웹문서 만들기란? 검색등록 서비스를 통해 검색반영 신청하신 사이트 내의 모든 URL(페이지)는 기본적으로 검색로봇이 방문할 대상으로 인식하여, 네이버 검색로봇이 주기적으로 방문 후 검색에 함께 자동 반영하고 있습니다. 네이버 검색팀에서는 당신이 소중히 관리하는 사이트 및 내부의 좋은 문서들이 네이버 검색 및 여타 검색로봇에 잘 반영되도록 기술적으로 지원하고자 합니다. 이를 위해 네이버 및 다른 모든 검색로봇에 잘 수집-노출되는 웹문서를 만들기 위한 방법을 가이드페이지로 제작하여 1차 공개합니다. 추후 사이트 운영자분들에게 도움이 될 다양한 기능 및 정보를 추가로 제공할 예정이니 많은 관심 부탁드리며, 특히 본인이 사이트 운영자이지만 개발자가 아닌 경우, 개발자(웹마스터)에게 꼭 이 페이지를 알려주시고 검색에 잘 나올 수 있도록 고쳐달라고 부탁하시기 바랍니다. (원본 출처 : 클릭)]]></summary>
        <category term="search_info" label="검색정보" />
    </entry>
    <deleted-entry
        ref="http://www.syndi-example.com/bbs/board.php?bo_table=search_info&amp;id=63642"
        when="2014-06-26T20:10:45+09:00" />
</feed>
그림 출처: http://developer.naver.com/wiki/pages/syndAPIspec
naver_syndication_document_sample.xml hosted with ❤ by GitHub
네이버 신디케이션 개요
이것을 네이버 검색 엔진과 친구를 맺는 것이며 한정적이기는 하지만 워드프레스 블로그와 상품 컨텐츠를 ‘웹문서와 사이트 영역’에 노출이 쉽게 또는 상위 노출이 됩니다. 네이버의 ‘블로그’ 영역은 네이버 자체의 블로그가 노출되므로 그 노출 범위는 한정됩니다. 일반적으로 신디케이션을 하는 경우는 네이버 ‘웹문서와 사이트 영역’에 노출이 반나절밖에 안걸리지만 하지 않는 경우는 하루 정도 걸립니다.
신디케이션_검색반영_프로세스
네이버 신디케이션 사용 시나리오
중요포인트 설명
신디케이션 문서를 실시간으로 생성 콘텐츠의 CRD 가 발생할때 하나의 엔트리에 대해 신디케이션 문서를 작성하고 문서의 위치를 신디케이션 서버의 핑 URL로 실시간 전송
일정 주기로 신디케이션 문서 생성 일정 주기 별로 콘텐츠의 CRD 내용을 모은 신디케이션 URL 다발을 신디케이션 서버의 핑 URL로 전송
주기적으로 문서 생성 내부 API를 호출하는 주소 전송 콘텐츠의 CRD 내용을 내부 Repository에 저장하고 저장된 내용을 신디케이션 문서로 만들어주는 내부 API 작성 한 후 API 주소를 주기적으로 신디케이션 서버에 Ping URL 전송
신디케이션 제한 사항 네이버 신디케이션 문서 하나에 포함되는 엔트리 개수에는 제한이 있슴
인용문서 : http://webmastertool.naver.com/guide/syndi_guide.naver#chapter1.1
신디케이션 API 작성을 위한 좀더 자세한 사항을 상기의 문서를 참조하세요
네이버신디케이션 사용시 주의점
네이버 신디케이션 사용시 주의점
(1) 가끔식 검색 노출 어뷰징으로 오인되어 Standby 가 되기도 함.
(2) 네이버 정책에 따르지 않으면 신디케이션에서 제외되기도 함.
(3) Ping 의 연결 실패시 서버 과부하, 서버 다운 경우 Standby 되기도 함.
워드프레스 신디케이션 플러그인의 사용
1..
위와같은 신디케이션의 개발을 워드프레스의 경우 간단하게 플러그인 설치로 대체할 수 있습니다. 아래의 플러그인 중 하나를 선택하여 설치하시면
됩니다.
(1) Naver Syndication V2 (2) Naver Syndication
신디케이션 Ping을 네이버 서버에 전달하면 네이버 검색엔진이 Ping 요청을 받은 신디케이션 문서를 반나절이내에 방문하여 신디케이션 문서를 수집해 갑니다. 고품질의 신디케이션 문서를 작성하고 그 문서(콘텐츠)의 내용을 지속적으로 네이버 검색에 알리는 것은 해당 컨텐츠를 네이버 검색엔진에 노출시키는데 효과가 있지만 유의할 점은 네이버 검색엔진이 그 콘텐츠를 반드시 검색엔진의 색인에 등록하지는 않습니다. 그리고 색인에 등록되더라도 그 콘텐츠가 네이버의 ‘웹문서와 사이트 영역’의 상위에 노출된다는 보장이 없습니다. 그것을 컨텐츠이 품질과 관련이 있으며 해당 컨텐츠에 이용자가 더 오랫동안 머무르냐인 체류시간과 밀접한 관계가 있기 때문입니다.
다음은 포스팅에서는 Naver Syndication V2와 그 사용법에 대해 설명하도록 하겠습니다.

K-네임서버의 웹캐시(Web Cache) 기능-워드프레스 속도 증가

안녕하세요 ?
국내 유일의 무료 워드프레스 쇼핑몰 “우커머스 교실”에서 사용하고 있는, 사용자의 웹 서핑 속도를 10~20배 정도 비약적으로 증가시키는 K-네임서버의 웹캐쉬 기능에 대해 알아보겠습니다.

웹서핑 속도를 10~20 정도 증가시키는 웹 캐쉬 기능
K-네임 서버는 일반적인 네임서버에서 제공하지 못하는 걸출한 기능을 보유하고 있는데 그것 중 하나가 웹캐쉬 기능입니다. 웹캐쉬는 웹서버에서 발생하는 캐쉬기능을 네임 서버에 옮겨서 웹서버의 부하를 극적으로 감소시키는 역할을 합니다. 즉 이미지나 동영상 화일, HTML 화일과 자바 스크립트와 css화일 정적(static)인 화일들을 네임서버 단에서 미리 다운로드 해두고 사용자측의 브라우저에서 요청이 있을 때 웹서버 요청하지 않고 즉시 보내주는 방식으로 정적 화일의 용량에 따라 사용자의 웹 서핑 속도를 10~20배 정도 비약적으로 증가시킵니다.
cache_array
웹캐쉬 모드와 개발 모드 비교
하지만 서버의 html, Java script, sss화일 등을 서버에서 수정하는 개발 상태에는 어떻게 해야 할까요 ? 이때는 웹캐쉬 모드를 사용하지 않고 웹서버에서 모든 것을 직접 다운로드하는 “개발 모드”로 설정하는데 이 경우 K-네임서버의 웹캐쉬 기능을 pypass하게 됩니다. 그래서 워드프레스 사용자 웹 캐슁 기능을 이용하려면 커스터마이징 작업을 할 때 Child 테마나 Child Css 과 같은 정적 화일을 수정하는 방법을 사용하지 말고 테마의 CSS 수정에 내용에 DB 필드에 직접 기록한 후 동적으로 css 태크을 브라우져에 표현하는 – 즉 테마에 있는 Custom Css 을 활용하는 방식으로 진행하는 것이 바람직합니다. 웹캐쉬 모드의 경우 설정에 따라 2시간에서 48시간에 한번씩 웹캐쉬에 저장된 정적 화일들을 쏟아버리고 웹서버에서 새롭게 정적화일을 가져와 저장하는 기능인 자동 정화(Automatic Purge)하는 기능이 있습니다. 따라서 “웹캐쉬 모드”라도 수정한 내용을 일정 시간이 지나면 웹서버에서 다시 다운로드하여 캐슁하게 됩니다. 실제로 보여지는 현상으로서는 유저가 다보리 웹호스팅 서버에 오랫동안 접근하지 않은 후에 막 다보리 웹호스팅 서버에 접근할 때 다른 웹서버와 동일한 속도가 걸리지만 두번째 부터는 웹캐쉬가 작동되므로 속도가 훨씬 빨리 보여지게 됩니다.
1253_cache1
개발 모드로 설정
부득히 개발 모드로 설정해야 할 경우
로 개발 모드 사용으로 신청해야 하며 이 경우 개발 모드 설정 후 3시간 후면 자동적으로 비개발 모드로 전환되므로 해당 내용을 확인하셔야 됩니다. 개발 모드르 전환될 경우 다보리 웹호스팅이 가지는 웹캐쉬의 장점이 없어지므로 해당 시간 동안은 접근 속도 지연을 감수하셔합니다. 다보리에는 따로 대규모 개발이나 테스트 시점 동안 제 2의 개발 서버를 따로 지원하고 있습니다.
CT845308

문의하기견적의뢰지금 연락 주십시요!