#!/bin/sh
# 백업 위치는 /backup, 백업 시간은 년-월-일 형식으로 지정
DATE=`date +"%Y%m%d%H%M%S"`
# 사용자 계정과 비밀번호
USERNAME="MySQL계정"
PASSWORD="비밀번호"
# 백업할 데이타베이스
DATABASE="wp"
# 백업 작업
mysqldump -u$USERNAME -p$PASSWORD $DATABASE > /backup/wp_bak_${DATE}.sql
자동 백업 Shell 프로그램의 권한 부여
자동 백업 Shell 프로그램이 제대로 작동하도록 700권한을 부여합니다.
chmod +x /backup/wpbackup2.sh
크론탭에서 자동 실행 명령
일정 시간에 자동 백업되도록 크론(cron)을 만듭니다.
매일 5시 30분에 자동실행되도록 crontab을 수정합니다.
cd /etc/crontab
vi /etc/crontab
30 5 * * * root /backup/wpbackup2.sh # 매일 5시 30분 실행 명령어 입력
/etc/init.d/cron restart # 크론 데몬을 재 실행토록 합니다.
시스템 재시작 시 스크립트가 실행되도록 설정
시스템이 재시작은 중요한 액션이 시작되는 것이므로 백업을 실행하도록 합니다.
vi /etc/rc.local
/backup/wpbackup2.sh
5. 마치며
서버를 운영하다보면 생각보다도 많이 DB를 백업받아야 할 일들이 발생합니다. 그냥 방치하면 모르겠지만 끊임없이 새로운 것을 시도해보고 개선을 시도해 본다면 DB 백업 및 복원은 일상적으로 일어나는 일들이 될 것입니다.
그리고 서버 운영에서 가장 중요한 일중의 하나가 만일의 사태에 대비한 백업과 복원이라고 할 수 있죠. 솔직히 어떤일이 일어날지 모르잖아요. 군대에 빗대어 서버 복원에 실패한 서버 전문가는 용서할 수 있어도 백업에 실패한(백업하지 않은) 서버 전문가는 용서할 수 없다는 이야기도 있더군요.
이렇게 중요한 서버 백업 및 복원에 대해서 전문가도 아니면서도 서버를 어쩔 수 없이사용해야하는 저와 같은 초보에게 도움이 될길 바라면서 이해하는 범위내에서 공유했습니다. 아무쪼록 도움이 될길 바라고 차후에는 좀더 업그레이든 내용을 공유해 보도록 하겟습니다.
참고로 자동백업 스크립트등은 우성군의 NAS에서 제안한 내용을 많이 반영했습니다. 이 자리를 빌어 감사드립니다.
VPS로 사이트를 옮기로나서 여러가지 시행착오을 격었는데 여기서 정리하는 썸네일이미지를 생성하지 못하는 경우도 그것이다.
VULTR로 옮기고나서 해킹도 당해보고 여러번 서버 설치도 해보면서 정말 이 동네 일이라는게 어렵다는 생각을 절로 하게된다. 그렇다고 중간에 중단할 수도 없어서 초보로선 어쩔 수 없이 많은 시간을 투여할 수 밖에 없었다.
조금 지나면 여유롭게 운영할 수 있는 시기가 올리라는 희망을 가지고서…
1. 문제 제기 – 서버 세팅 후 워드프레스에서 썸네일이 생성되지 않는다.
제목을 거창하게 문제제기라 썼지만 문제점 발견이라고해야 겠다.
지난주에 내 사이트가 해킹이 되었다는 Matthew님의 연락을 받고 사이트를 우서 며칠전에 백업한 상태로 되돌리고 이번 주말과 연휴에 사이트를 다시 세팅하였다.
OS를 새로 설치히고 (이는 VULTR dashboard에서 간단히 할 수 있는 일이다.) Nginx, PHP7.0-FPM, MARIADB 등 기본 프로그램을 설치하고 pageSpeed, SSL 등을 설치하고 최종 Wordpress를 설치 복원하였다..
그리고 이번 기회에 워드프레스테마를 무겁고 VC 빌더를 사용해 다소 무겁다는 newspaper 7에서 EXTRA로 변경해 보았다,
그런데 이 EXTRA를 설치하고 최적화하는 과정에서 도대체 썸네일이 매칭이 않되는 것이었다.
도대체 뭐가 문제일까?
2. 문제 해결 과정과 문제 해결 방법
이 문제를 해결하기 위해서 아래와 같은 몇가지 단계를 거쳤다. 어쩌면 이 문제를 해결하기 위한 삽질 순서라고 해야할 듯…
2.1. 테마간 썸네일이 중복되어 생성이 않되는 것일까?
혹시 테마별로 필요한 썸네일 사이즈가 있으므로 혹 테마간 충돌로 제대로 썸네일이 생성되지 않을 수도 있겠다 싶어서 EXTRA만 제외하고 모든 테마를 지우고 테스트를 해보있다.
여전히 제대로 working하지 않는다. 썸네일 자체가 전혀 생성되지 않는다. 미디어라이브러리에 이미지는 올라가는 것 같다. 처음 서버를 설치 시 이미지 자체가 보이지않고 올라가지 않아서 고생했던 기억이 있었는데 이는 아니어서 다행…
2.2. 썸네일 생성 플러그인이 문제가 아닐까?
예전부터 썸네일 관련해서는 Thumbnail Cleaner라는 플러그인과 Regenerate Thumbnails라는 플러그인을 사용했는데 제대로 작동하지 않았다. 기존 썸네일지우는 동안에 많은 에러를 내고 생성한다고 메세지는 나오는데 섬네일은 생성되지 않았다. 이는 플러그인이 오래되어서 그러나보다며 플러그인을 의심했다.
이 플러그인을 다 지우고 인터넷을 검색해보니 Force Regenerate Thumbnails을 추천하는 포스팅이 많아서 또 설치… 이 플러그인도 마찬가지 – 멋있게 작업 진행 상황을 보여주긴 하는데 섬네일이 생성된다는 메세지는 없다. — 삭제
그러면 강제로 Thumbnails size를 지정해 만들어보면 어떻할까는 생각이 들었다. 이런 작업을 해줄 수 있는 플러그인은 무엇일까? 검색에 검색을 거듭해서 AJAX Thumbnail Rebuild라는 플러그인을 발견해 설치했다.
AJAX Thumbnail Rebuild는 원하는대로 사이즈를 지정할 수 는없지만 테마에서 필요로하는 모든 사이즈 리스트를 보여주고 여기서 선택을 할 수 있게 해준다. 작업 시 이미지들을 보여주면셔 작업을 진행하는데 이번에는 뭐가 제대로되는 느낌..
작업이 완료된 후 FTP로 점검해보니 왠걸 AJAX Thumbnail Rebuild도 마찬가지로 아무런 썸네일도 생성되지 않았다..
도대체 뭐가 문제야?
2.3. 파일 권한의 문제가 아닐까?
구글링! 구글링! 이번에는 wordpress cannot create thumbnails라는 영어로 질문을 던졌다. 그랬더니 이와 관련된 질문이 여러가지가 보인다.
어떤 사람이 이는 당연히 파일 권한 문제라고 한다. 그러면서 아래와 같이 퍼미션을 주라고 한다.
전체 wp-content 폴더는 777로 세팅한다.
나머지 폴더(wp-admin, wp-includes)는 755로 설정하고 파일들은 644로 세팅한다.
이렇게 세팅하고 예전 기억이 있어서 사용자를 www-data로 지정도 했다.
이 방법도 실패!!
2.4. 기본 프로그램 설치의 문제 – PHP7.0-GD 미설치 시 나타나는 문제
구글링을 계속하니 PHP5-GD 설치하지 않아서 발생했다는 글이 있었다.
그러면 혹시 PHP7.0-GD도 있는 것 아닌가? 이를 실마리로 PHP7.0-GD와 thumbnails로 검색하니 PHP7으로 업그레이드하고나서 Post Thumbnail Editor가 작동하지 않는다는 질문이 꽤 있다.
Since I migrate my webserver to PHP7, Post Thumbnail Editor is not working… It doesn’t show up the image in the crop window and don’t generate automatically those thumbnails.
Any one facing this too?
I had to revert to PHP 5.6 and now it’s working again.
이에 대한 해결책은 PHP7.0-GD를 설치하는 것. 워드프세스는 GD라고 불리우는 PHP 확장 기능을 사용해 이미지를 조작하므로 워드프레스에서 이미지관련 작업을 하려면 서버에서 PHP 버젼에 따라 PHP5-GD나 PHP7.0-GD가 설치되어 있어야 한다고 한다.
Ubuntu 16.04 등 최근 OS에서는 별도의 인증서 저장없이 바로 설치 할 수 있다.
apt-get update
sudo apt-get install php7.0-gd
PHP7.0-GD 설치
Nginx 재시작(service nginx restart)
PHP 재시작(service php7.0-fpm restart)
PHP7.0-GD를 설치, nginx 및 PHP를 재가동시키고 나니 언제 그랬나는듯 아무 문제없이 썸네일이 생성된다.
무식하면 손발이 엄청 고생한다는 게 이번 교훈!!
3. 마치며
원인을 알고나면 참으로 간단한 해결 방안이고 허망할 정도로 단순 문제인데 원인을 모르면 이런 저런 갑질을 하게 된다.
이런 원인들을 잘 모르니 서버 운영자들이 PHP 업그레등 기능 업그레이드를 망서리게 되는 원인이 되지 않을까 싶다.
위에서 인용한 사람도 PHP7로 업그레이드 했지만 썸네일 문제를 해결하지 못해서 다시 PHP5.6으로 다운그레이드한 경우처럼..
관련 분야에 폭넓은 지식을 가지고 있다면 해결책을 빨리 발견할 수 있겠지만 그렇지않으면 엄청난 삽질을 해야하므로 비지니스 측면에서 그런 삽질를 감당할 수없으니 소비자들에게잔소리말고 낡은 프로그램을 쓰라고 윽박지르는 것이 아닐까??
오늘 마지막으로 Memcached를 설치해보고 워드프레스 속도 최적화 프로젝트(?)는 종료하면서 초보가 보기에 의미가 있는 cache 이야기해 보려고 합니다.
이 포스팅은 공유 목적도 있지만 제 자신의 기록과 나중에 참고할 자료 성격이 더 강합니다. 아무래도 이 포스팅을 위해서 고민을 많이하다보니 자료가 어디있지라는 생각에 제일 먼저 떠오르는 곳이 이 곳이기 때문에 저는 여기에 올린 포스팅을 종종 참조하곤 합니다. 그리고 저라도 활용을 해야 할 듯 싶기도 합니다.
다만 이 포스팅의 한계는 분명합니다. 미래를 앞서가는 개발자에게 어떤 인사이트를 제공하고 개발자분들에게 명확한 가이드가 되는 포스팅은 아닙니다. 먼저 고민을 하고 구글링한 결과를 한글로 정리한 것에 불과할 수도 있습니다. 이런 고민을 하는 초심자들에게는 조금 도움은 될 수 있지 않을까 합니다.
오늘 서버 성능을 개선해보고자 cache 부분을 어떻게 개선할까 고민했습니다.
2. 고민의 계기 – newspaper 7 테마에서 APC 를 추천하다.
그 고민의 시작은 newspaper 7 테마 제작사에서 테마의 속도를 올리는 방법으로 APC full page cache를 사용하라고 조언을 하더군요. 그래서 이게 대단한 것 같아서 자료를 찾아보고 설치를 해보았습니다.
아래는 newspaper 7 테마 제작사에서 권유하는 내용입니다.
we recommend that you use WP Super cache with default settings.
you can also use the APC full page cache if you have a lot of ram on your server
구글링으로 알아본 cache에 대해서 간략히 정리해 봅니다.
APC는 매우 낡은 기술로 더 이상 잘 사용하지 않는 기술이라고 합니다. 이렇게 낡은 기술을 newspaper 7과 같은 최신 테마에서 사용하라고 가이드 한다는 점에서 굉장히 실망하게 되었습니다.
그러면서 이 테마는 최근에 최신 기술을 기반으로 만들어진 테마라기보다는 오래전에 나온 테마를 계속 업데이트 해온 것이 아닐까 하는 생각이 들었습니다.
알고보니 이 테마가 처음 등장한 것은 2014년 경으로 이 당시는 APC가 그 낡은 기술은 아니었던 것으로 보입니다.
아마 예전에 만들었던 마케팅 커뮤니케이션 자료들이 최신 기술등으로 업데이트되고 있지 않다는 게 최종 결론입니다.
3. Cache 프로그램에 대해서
Cache에 대해서 구글링을 하다보면 만나는 단어들이 있습니다. APC, XCache , Opcache, Memcache, Memcached 그리고 Tarantool (HASH), Tarantool (TREE), Redis, Azure Redis Cache, CouchBase Redis등등이 그것입니다.
굉장히 많은 종류의 Cache가 있지만 워드프레스를 운영하는 초보 입장에서는 APC, Opcache, Memcache, Memcached가 많은 접하는 수준의 단어들인 것 같습니다. 그런데 이 cache관련 내용은 들어도 잘 모르는 알송달송한 내용이 대부분인듯… 역시 전문 분야는 다른 것 같다는 생각입니다.
Nginx서버에서의 Cache 관련 구글링을 통해서 얻은 내용을 아래와 같이 간략히 정리해 봅니다.
Cache에는 Full page cache, PHP Script 결과를 모아 두는 cache, 데이타베이스 Query 결과를 모아두는 cache로 나눌 수 있다.
Full page cache는 PHP를 통해서 HTML 형태로 page를 구성한 결과를 보관했다가 요청이 오면 바로 보여주어 속도를 높이는 기법으로 Nginx에서는 FastCGI가 가장 좋은 성과를 보여 준다,
PHP Script Cache는 말 그대로 PHP Script를 컴파일한 결과를 공유 메모리에 저장하고 있다가 필요 시 사용하는 cache로 요즘 OPcache가 가장 성능이 좋다고 알려 있다.
APC는 PHP Script 결과를 모아 두는 cache + 데이타베이스 Query 결과를 모아두는 cache 모두 커버하는 기술이었다.(아래 개발군님의 댓글 참조)
xcache, wincache, eAccelerator 등등은 구닥다리 기술로 쳐다볼 필요조차 없다
APC의 PHP 관련 기능은를 대신해서 PHP 5.5이상에서는 자체 OPcache로 대체되었고, PHP 5.5이하에서 Opcache를 사용하려면 별도 프로그램을 깔아야 한다.
PHP 5.5이상에서 APC의 기능 중 데이타베이스 쿼리(query) Cache 부분은 APCu라는 php 확장 모듈을 사용 할 수 있다.
데이타베이스 쿼리(query) Cache에는 APCu나 Memcached가 있다. 이중에서 단독 머신에서 사용하기에는 APCu가 빠르며, 머신 3개이상을 운영한다면 Mencached가 낫다는 평가가 있다.
OPcache와 Memcached의 차이는 OPcache는 위에서 설명한 대로 PHP Script 결과를 모아 두는 cache이고, Memcached는 주로 데이타베이스 쿼리(query) 결과를 보관하는 cache라는 차이가 있다.
Opcache나 APCu가 Redis 또는 Memcached 보다 속도면에서 유리한 이유는 Redis나 Memcached는 별도 서버와 통신을 통해서 작동하는 방식이라 규모가 작은 시스템에서는 상대적으로 느맇 수 있다. 반면 OPcache나 APCu는 연결할 필요없이 바로 서버 공유메모리에 바로 Caching하기 때문에 빠르고 메모리도 절약된다, Memcached와 Redis의 작동 방식은 같다.
Opcache와 Memcached를 같이 쓰는 것에 대해서 OPcache는 PHP Script Cache이고 Memcached는 데이타베이스 Query Cache이므로 같이써도 무방하다. 이를 같이 쓰는 경우를 많이 발견할 수 있다. 특히 사용자가 많은 경우 시스템을 효율적으로 공유할 수 있는 유용성때문에 같이 사용한다.
아래에서는 비교적 최신 기술이고 PHP 5.5이상에서 내장되어 사용되는 OPcache에 대해서 살펴보도록 하겟습니다.
4. OPcache 의미와 설정법
OPcache는 byte코드로 컴파일된 명령문(PHP Script)으로 공유된 메모리에서 PHP 문서 해석 시간을 줄여 성능을 개선시킵니다. Opcache는 낮은 CPU 자원을 사용하면서 빠른 해석으로 개벌적 접속자가 상대적으로 빠른 속도감을 느낄 수 있습니다.
아래는 PHP Script를 처리하는 과정에 대한 플로우 차트인데 Cache와 PHP Script 컴파일이 잔행되는 프로세스를 살펴볼 수 있습니다. 이 플로우 차트는 Basics of PHP opcode cache 에서 가져왔습니다.
Opcache는 PHP 5.5부터 내장되어 설치되며 5.4이하에서는 PECL 방식으로 사용이 가능합니다.
Opcache는 PHP.ini 파일에서 환경 설정을 효율적 세팅함으로써 효울을 더 높힐 수 있습니다.
4.1. OPcache 적용 여부 확인
우선 OPcache가 작동하고 있는지 확인하는 방법은
첫째, php.ini 설정을 살펴보면 됩니다. ubuntu 계열에서 php.ini 파일은 /etc/php/7.2/fpm/ 폴더에 있습니다. (PHP Version만 달라짐)
vi /etc/php/7.2/fpm/php.ini
여기에서 OPcache 관련 항목이 있으면 설치되어 작동하고 있는 것입니다.
또한 일반적으로 많이 사용하는 php-info.php를 활용해서 확인 할 수 있습니다.
먼저 아래와 같은 내용의 php-info.php 파일을 만들어 계정의 루트에 올립니다.
그 다음 인터넷 브라우저에서 (yourdomain)/php-info.php를 치면 php의 관련 내용이 나오는데요.. 여기서 opcache 관련 내용을 확인하면 됩니다.
<?php
phpinfo();
?>
4.2. php.ini에서 OPcache 설정
php.ini 파일을 열어보면 OPcache 관련해 앞에 주석 처리된 명령문들이 많이 있습니다. 이 명령문 중에서 상호 관련이 있는 변수는 opcache.memory_consumption, pcache.max_accelerated_files, opcache.max_wasted_percentage의 3가지로 서로 충돌이 나지 않토록 설정하는 게 관건으로 보입니다.
opcache.memory_consumption은 기본값이 64MB로 되어 있는데요. 메모리의 여유가 있다면 늘려주는 게 좋을 것 같습니다. 원래 256MB를 설정했는데, OPcache 모니터링 프로그램으로 며칠 살펴보니 70MB이하로 사용되고 있어서 96MB로 최종 설정했습니다.
opcache.max_accelerated_files은 한번에 처리하는 캐시 파일 수 인데요. 이는 200에서 1,000,000사이의 값을 넣게 되어 있고 기본값은 2000입니다. 램에 여우가 있다면 기본보다 높이는게 좋겠죠. 저는 100,000으로 설정했습니다만 실제로 1,300개 정도 사용되고 있는 것으로 보아 개인 사이트라면 10,000정도면 충분할 것 같습니다.
opcache.max_wasted_percentage는 Opcache가 재시작을 해야할 시 버려야하는 비율을 정하는 것입니다. 기본값은 5%로 되어 있습니다. 일반적으로 기본보다 더 높여주는 것 같습니다.
opcache.revalidate_freq는 php소스 변경 확인 간격을 말하는데요. 개발자라면 이를 0으로 놓아 바로 바로 확인토록 하고, 일반인이라면 60 또는 180으로 설정합니다.
그외 일반적으로 꼭 하는 설정들은 아래에 적어 보았습니다.
opcache.enable=1 ; Opcache 사용여부 설정, 1일때 활성화 됨
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=100,000 ; 최대 파일갯수 설정
opcache.revalidate_freq=180 ; php 소스 변경확인시간 60sec
opcache.validate_timestamps=2 ;php 소스 수정 확인
opcache.fast_shutdown=1
opcache.enable_cli=0 ; 명령행 버전의 PHP에서도 opcache적용할지 여부
opcache.use_cwd=1 ;같은 이름을 가진 파일들사이에서 가능한 충돌 제거
4.3. OPcache 모니터링
이렇게 OPcache를 설정했으면 이 OPcache가 어떻게 작동하고 있는지 모니터링하고 혹시 수정할게 있는지 확인하는 게 좋을 것 같습니다.
즉 SSD와 PHP 7을 적용해도 서버 사양이나 서버 세팅에 따라 성능 및 속도가 달라질 수 있다는 사실을 HDD와 PHP 5.5를 적용한 루아틱이 오히려 더 나은 속도 및 퍼포먼스를 보여줌으로써 증명되었습니다.
그리고 아이비호스팅을 이용하면서 한국업체이므로 서비스가좋고 편하다는 느낌을 받을 수 없었고 모든 문제를 내가 알아서 해결해야하므로 한국 업체의 서비스가 무의미했습니다. 대부분 문제를 구글링을 통해 해결해야하는 실정이라면 그냥 해외업체를 쓰는게 속편하겠다는 생각을 했습니다.
그래서 서버 사양이나 세팅을 어느정도 자유롭게 할 수 있는 VPS 가상서버호스팅을 고민하기 시작했습니다.
그렇지만 VPS 가상서버호스팅이 자유롭게 서버등을 최적화 할 수 는 있지만 (국내업체는 너무 비싸므로) 가격 경쟁력을 갖춘 해외업체를 사용해야 하므로 해외 가상서버호스팅이 과연 만족할만한 속도를 내줄 것인지가 의문이었습니다.
최소한 현재 shared hosting인 아이비호스팅보다는 빨라야 옮길 수 있는 명분이 있는게 아닐까 싶었습니다.
그래서 VPS 가상서버호스팅과 아이비호스팅을 비교해 보기로 했습니다. 이의 결과에 따라 VPS 서버호스팅이 대안이 될 수 있을지를 결정하기로 했습니다.
1. VPS(가상서버호스팅 ) 선정
인터넷 검색 결과 속도 및 가격을 고려해 VULTR.com을 선정했습니다.
VULTR을 선정한 이유는
하지만 Let’s Encrypt 사용을 아래 그래프에서 보듯 매우 빠르게 증가 (개인적인 생각으로는 무료이기 때문에 테스트로 중복 인증도 많다고 생각)
Let’s Encrypt SSL 인증서 사용 증가 추이, Graph by Let’s Encrypt
Let’s Encrypt의 정책은 독특합니다. 앞에서 HTTPS의 확산을 위한 비영리단체로 소개했듯이 Let’s Encrypt은 서버운영자들이 인증 관리를 철저히 하지 못한다는 점을 염려(?)해 인증서 설치부터 재발행(갱신)까지 다 책임진다는 자세로 인증관련 업무를 진행하고 있습니다.
인증기간이 90일로 상대적으로 짧은 것은 보안 상황이 계속 변동되므로 이를 반영해 갱신할 수 있도록 짧게 잡았으며 대신 자동으로 인증서가 연장(재발행)되는 기능을 사용하도록 권장하고 있습니다.
자동으로 연장(재발행)된다면 오히려 안심하고 사용할 수 있는 것이 아닌가 싶습니다.
HTTPS Everywhere 를 추구하는 비영리 프로젝트
스폰서 : Mozilla, Akamai, Cisco, eff, Identrust
IdenTrust cross-sign됨
SSL 인증서 100% 무료화
인증기간 연장 및인증서 재발급 무료
사용편리성 : 콘솔상에서 인증서 발급/갱신/설치/세팅 자동화.
멀티도메인 지원, SAN 기능(여러 도메인을 한 인증서로 묶어주는 기능) 지원
2. Let’s Encrypt SSL 인증서 발급 방법 4가지
Let’s Encrypt SSL 인증서 발급 방법은 webroot와 Standalone, DNS의 3가지 방식이 있습니다. 인증서 발급은 사이트에서 인증기관인 Let’s Encrypt에 접속해 이 사이트의 유효성을 검증하는 과정을 거치며 이 과정을 아래 3가지 방법 중 하나를 선택해 진행할 수 있습니다.
webroot : 사이트 디렉토리 내에 인증서 유효성을 확인할 수 있는 파일을 업로드하여 인증서를 발급하는 방법 . 실제 작동하고 있는 웹서버의 특정 데렉토리의 특정 파일 쓰기 작업을 통해서 인증 . 이 방식의 장점은 nginx를 중단시킬 필요가 없음. . 이 방법의 단점은 인증 명령에 하나의 도메인 인증서만 발급 가능
웹서버 . Nginx나 아파치와 같은 웹서버에서 직접 SSL 인증을 실시하고 웹서버에 맞는 SSL세팅값을 부여 . 발급이나 갱신을 위해 웹서버를 중단시킬 필요가 없음 . 인증서 갱신 시 상황에 맞게 세팅을 자동으로 업데이트 . 사용자가 세팅을 변경할 수 있지만 자동 업데이트 시 반영되지는 않음
Standalone : 사이트 작동을 멈추고 이 사이트의 네크워킹을 이용해 사이트 유효성을 확인해 Let’s Encrypt SSL 인증서를 발급하는 방식 . 80포트로 가상 staandalone 웹서버를 띄워 인증서를 발급 . 이 방식은 동시에 여러 도메인을 발급 받을 수 있음 . 그렇지만 인증서 발급 전에 Nginx를 중단하고 발급 완료 후 다시 Nginx를 시작해야 함
DNS : 도메인을 쿼리해 확인되는 TXT 레코드로 사이트 유효성을 확인하는 방법 . 와일드 카드 방식으로 인증서를 발급 가능 . 이 방법은 당연하게도 서버 관리자가 도메인 DNS를 관리/수정할 수 있어야 하며 . 인증서 갱신 시마다 DNS에서 TXT값을 변경해야 하므로 외부에서 TXT 레코드를 입력할 수 있도록 DNS가 API를 제공하는 경우만 갱신 과정을 자동으로 처리(클라우두플레어 API가 대표적인 사례)
여기에서는 가장 안정적인 방식인 standalone 방식으로 SSL 인증서를 발급하는 방법에 대해서 알아보도록 하겠습니다. 보다 자세한 내용을 아래 글을 참조하시면 좋을 것 같습니다.
그러면 아래와 질문들이 나오면서 인증이 진행됩니다. 첫번째로은 이메일 주소를 입력하라고 나옵니다. 이메일을 입력해야 다음 단계로 넘어갈 수 있으니 연락을 받을 수 있는 이메일을 입력합니다.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel)
:Code language:PHP(php)
그 다음 단계는 서비스 약관에 동의하느냐고 묻습니다. 모든 서비스가 그러하듯이 Y를 누르지 않으면 서비스를 이용할 수 없기 때문에 A를 누릅니다.
Please read the Terms of Service at
https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory
(A)gree/(C)ancel: ACode language:PHP(php)
마지막 질문은 재단에 이메일 주소를 공유할 것인지를 질문 합니다 간혹 귀찮게 하는 경우도 있어 N를 선택하라는 조언도 많은데 저는 이 비영리기관에 도움이 될 수 있다면 이라는 긍정적인 생각으로 Y를 눌렀습니다.
Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom.
(Y)es/(N)o: YCode language:PHP(php)
그러면 다음과 같이 진행되고 인증을 축하다는 메세지가 나옵니다.
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Waiting for verification…
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/example.com/privkey.pem
Your cert will expire on 2021-03-25. To obtain a newor tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew <em>all</em> of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donateDonating to EFF: https://eff.org/donate-le Code language:PHP(php)
인증이 완료되면 웹서버를 다시 가동시킵니다.
service nginx restartCode language:PHP(php)
2.3. 여러개 도메인을 한번에 인증받기
이 standalone 옵션은 또한 한꺼번에 여러 개의 사이트를 인증 받을 수 있는데요. 아래와 같은 명령을 사용할 수 있습니다. 이는 연속해서 사이트명을 나열해주면 가능합니다.
단 이렇게 여러개 사이트를 인증 받을 시 인증서 존재 위치가 맨앞 사이트명으로 통일되게 됩니다. 나중에 사이트를 없앨 때 난감할 수도 있습니다.
2.4. DH Param 생성, 적용하기
여기가지 진행하면 SSL 인증서 설치는 끝나지만 보다 보안을 강화하기 위해서 DH Param 생성을 합니다.
DH Param은 일부 암호화 알고리듬에 사용되는 커다란 난수 하나를 미리 생성해 두어서 암호화 성능을 향상시키고 보안을 높이는 방법입니다.
실제로 DH Param을 비적용시와 적용 시 보안 점수를 측정해보니 한등급 차이가 날 정도로 Gap이 컷습니다. DH Param를 적용시는 A+ 보안등급이 나오고 DH Param를 비적용시는 A-가 나오네요.
mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
openssl dhparam -out dhparams.pem 4096# 2048비트로 하려면 4096대신 2048로 대체 한다.
openssl rand 48
session_ticket.key # 세션 티켓키도 생성 이는 시간이 거의 걸리지 않는다.Code language:PHP(php)
3. 암호화 알고리즘 설정하기
XE 분야에서 탁월한 식견을 자랑하는 가지곰님이 Xpress Engine 공홈에 올린 SSL의 정석 (아파치 & nginx) 라는 글에 의하면 실제로 보안을 제공하는 것은 인증서가 아니라 암호화 알고리즘이라고 이야기 하고 있습니다.
인증서를 획득하는게 중요한게 아니고 얼마나 철저한 암호화 설정을 하느냐가 중요하다는 것입니다.
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Processing /etc/letsencrypt/renewal/example.com.conf
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator standalone, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for example.com
http-01 challenge for www.example.com
Waiting for verification…
Cleaning up challenges
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/example.com/fullchain.pem
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates below have not been saved.)
Congratulations, all renewals succeeded. The following certs have been renewed:
/etc/letsencrypt/live/example.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
** (The test certificates above have not been saved.)
IMPORTANT NOTES:
Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates andprivate keys obtained by Certbot so
making regular backups of this folder is ideal.
Code language:PHP(php)
5. SSL 사용을 위한 워드프레스 설정하기
워드프레스에서는 별로 할것은 없습니다. 워드프레스 어드민의 설정 – 일반으로 가서 워드프레스 주소와 사이트주소에 S를 붙여줍니다.
일반적으로 인터넷은 HTTP(Hypertext Transfer Protocol의 약자)로 데이타를 전송해왔습니다. 이는 암호화되지 않은 방식으로 데이타를 전송하므로 메세지를 감청하는것이 매우 쉬워 보안에는 취약합니다. 로그인을 위해 비밀번호를 전송시 쉽게 비밀번호를 가로챌 수 있다는 의미이죠.
그래서 보다 보안을 강화한 방식이 HTTPS입니다. 마지막의 S는 Over Secure Socket Layer의 약자로 보안이 강화된 HTTP라고 이해하면 될 것 같습니다.
1.2. SSL이란
SSL protocol은 Secure Socket Layer protocol의 약자로 (지금은 사라진 브라우져회사인)Netscape사에서 처음으로 웹서버와 브라우저 사이의 보안을 위해 만들었다고 합니다. .
[웹브라우저] 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문서를 복호화하고, 화면에 정보를 뿌려준다.
위 SSL작동방식에서 설명한 것처럼 클라이언트가 서버에 접속한 직후에 서버는 클라이언트에게 이 인증서 정보를 전달하며 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를 검증 한 후에 자료 전송 등등의 작업을 진행합니다.
이 SSL 인증서을 사용하면 서버와 클라인언트간 통신 내용이 공격자에게 노출되는 것을 막을 수 있고, 클라이언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지를 판단할 수 있으며 공격자에 의해서 서버와 크라인언트간 통신 내용의 악의적인 변경을 방지할 수 있다고 합니다.
2. 웹보안의 강제적 적용과 구글의 정책
위에서 설명한것처럼 웹에서 보안을 위해서는 HTTPS 적용이 기본적으로 필요합니다.
이런 저런 이유로 우리나라는 2012년 8월 18일부터 시행된 정보통신망 이용촉진 및 정보보호 등에 관한 법률에 따라 개인정보호를 위해서 보안서버(SSL)를 구축해야합니다. 개인사이트, 커뮤니티를 포함해 회원가입을 받는 국내 모든 웹사이트가 해당된다는 해석입니다. (이에 대해서 불필요한 규제라는 많은 불만이 있는 것은 사실입니다.)
제28조(개인정보의 보호조치) ① 정보통신서비스 제공자등이 개인정보를 취급할 때에는 개인정보의 분실·도난·누출·변조 또는 훼손을 방지하기 위하여 대통령령으로 정하는 기준에 따라 다음 각 호의 기술적·관리적 조치를 하여야 한다.
개인정보를 안전하게 취급하기 위한 내부관리계획의 수립·시행
개인정보에 대한 불법적인 접근을 차단하기 위한 침입차단시스템 등 접근 통제장치의 설치·운영
접속기록의 위조·변조 방지를 위한 조치
개인정보를 안전하게 저장·전송할 수 있는 암호화기술 등을 이용한 보안조치
백신 소프트웨어의 설치·운영 등 컴퓨터바이러스에 의한 침해 방지조치
그 밖에 개인정보의 안전성 확보를 위하여 필요한 보호조치
② 정보통신서비스 제공자등은 이용자의 개인정보를 취급하는 자를 최소한으로 제한하여야 한다.
또한 구글에서도 2014년부터 HTTPS를 지원 여부를 사이트의 신뢰할 수 있다는 척도로 판단하고 검색 순위에서 올리겠다고 발표했습니다.
Security is a top priority for Google. We invest a lot in making sure that our services use industry-leading security, like strong HTTPS encryption by default. That means that people using Search, Gmail and Google Drive, for example, automatically have a secure connection to Google. ~ 중략~ For these reasons, over the past few months we’ve been running tests taking into account whether sites use secure, encrypted connections as a signal in our search ranking algorithms. We've seen positive results, so we're starting to use HTTPS as a ranking signal. For now it's only a very lightweight signal — affecting fewer than 1% of global queries, and carrying less weight than other signals such as high-quality content — while we give webmasters time to switch to HTTPS. But over time, we may decide to strengthen it, because we’d like to encourage all website owners to switch from HTTP to HTTPS to keep everyone safe on the web.
3. 무료 SSL인증서에 대해서
그러면 이처럼 보안을 강화하기위해 보안서버(SSL)를 구축하려면 SSL인증이 필요합니다.
그동안 SSL인증에는 일정정도 비용을 수반했기때문에 HTTPS 프로토콜을 적용하는 사이트가 적었지만 HTTPS 확산을 위해서 무료로 발급해주는 곳이 증가하고 잇습니다.
이러한 무료 인증서가 유료 인증서보다 보안에 약하지않을까하는 염려가 있을 수 있는데이는 전혀 걱정할 필요가 없다고 합니다.
무료인증서나 유료인증서나 인증에는 별 차이가 없습니다만 유료인증서에는 사고가나면 배상받을 수 있는 조검이 걸려있습니다. 쉽게 말해서 일종의 보험이 포함되어 비싼진 게 유료인증서라고 보면 될 것 같습니다.
이처럼 무료로 SSL인증서를 발급해주는 곳으로는 Let’s Encrypt, Wosign, StartSSL이 널리 알려져 있습니다. 아래에서 각 업체별 특징을 간략히 알아보겟습니다.
Let’s Encrypt은 HTTPS의 확산이 늦어지는 것은 SSL인증서에 있다고 보고 무료 인증서 보급을 통해 HTTPS의 확산을 늘리겠다는 취지로 시작된 비영리 프로젝트입니다.
Mozilla, Akamai, Cisco, eff, Identrust등이 스폰서로 참여해서 HTTPS Everywhere를 모토로 100% 무료 SSL 인증서를 발급 해주고 있습니다.
Let’s Encrypt의 정책은 독특합니다. 앞에서 HTTPS의 확산을 위한 비영리단체로 소개했듯이 Let’s Encrypt은 서버운영자들이 인증 관리를 철저히 하지 못한다는 점을 염려(?)해 인증서 설치부터 재발행(갱신)까지 다 책임진다는 자세로 인증고나련 업무를 진행하고 있습니다.
인증기간이 90일로 상대적으로 짧은 것은 보안 상황이 계속 변동되므로 이를 반영해 갱신할 수 있도록 짧게 잡았으며 대신 자동으로 인증서가 연장(재발행)되는 기능을 사용하도록 권장하고 있습니다.
Wosign은 중국의 인증업체 상당히 공격적인 조건으로 사용자를 확보하고 있는 인증업체입니다. 여기서 발급하는 인증서의 브라우저 호환성은 StartSSL과 같은 수준이라고 합니다. (StartSSL cross-sign)
이곳의 장점은
최초 발급이 무료이고 더우기 Revoke/Reissue가 무료 임 (StarSSL은 상당 비용($25)을 받음, Let’s Encrypt는 무료임)
멀티도메인 지원 및 발급 도메인수가 많다. ( Wosig에서는 한 인증서당 SAN 100개까지 지원할정도로(도메인 + 서브도메인 포함해 100개) 많은 도메인을 등록할 수 있었으나 스팸성 도메인들의 증가로 도메인을 5개까지 무료 지원 + 그 이상은 도메인당 1.99달러 가격으로 이용 가능)
인증기간을 3년까지 선택할 수 있음
Wosign의 단점을 꼽자면
중국 인증업체로 신뢰성이 떨어진다는 점
서비스에의 의구심(뚜렸한 사유없이 인증이 취소되었다는 케이스 등등 사례가 있음)
3.3 StarSSL
StarSSL은 이스라엘 보안업체가 운영하는 인증서 발급업체로 비교적 신뢰도가 높은곳으로 알려지고 있습니다.
다만 위 Wosign이나 Let’s Encrypt에서 당연시되는 사항들이 여기에서는 무료로 지원되지 않고 있습니다.
계정당 인증서 1개만 가능
인증서 연장은 무료지만 유효기간이 지나 재발급받을 시 상당한 비용을 받습니다. (25$ of Revoke fee)
3. 어떤 무료인증서를 이용해야 할까?
위에서 무료 SSL 발급업체인 Let’s Encrypt, Wosign, StartSSL의 간략한 특징을 살펴보았는데요.
그러면 이중 어디를 써야할까요?
아마 관리가 귀찮은 분들은 인증기가닝 가장 긴 Wosign의 3년짜리를 쓴 것이 답이 아닐까도 싶구요. 보다 믿을 수 있는 곳을 서야겠어하시는 분은 그래고 권위(?)있는 StarSSL을 쓰시는게 마음 편할 듯 합니다.
저는 여러 조건을 고려해 볼 시 자동으로 연장되는 기능을 사용하는 조건으로 Let’s Encrypt가 가장 경쟁력있다고 판단되었습니다.
원래는 SrarSSL을 사용하려고 인증서까지 받고 서버에 설치하는 중이었는데요. Let’s Encrypt로 바꿔보기로 했습니다.
다음 포스팅에는 Let’s Encrypt 인증서를 적용하고 자동 연장토록 구성하는 방법에 대해서 알아보도록 하겠습니다.
기존 아이비호스팅에서 VULTR이라는 해외 VPS(가상서버호스팅)로 이전하면서 어떻게하면 더 속도를 높일 수 있을까 고민하다 찾아낸 게 구글 페이지스피드모듈을 적용하자는 것이었습니다.
어떤 사이트에서는 10배까지 성능이 좋아진다고하는데 과연 어느 정도 성능을 뽑아줄지 기대가 되지 않을 수 없습니다.
1. 구글 모드 페이지스피드’(mod_pagespeed) 소개
잘 알다시피 Google PageSpeed는 웹사이트의 성능을 분석하고 최적화 방법을 알려주는 분석도구로 이와 관련 툴로는 가장 대중적이라 할 수 있습니다. PageSpeed Insights는 PageSpeed Insights Rules에 따라서 웹 사이트를 분석해주고 점수로 보여주는데 이를 잘 이용하면 어떻게 이트의 성능을 개선해야 하는지를 알 수 있습니다.
이러한 웹사이트에서 사이트를 분석하는 서비스 외 구글은 2010년에 발표한 모드 페이지스피드라는 프로젝트를 토대로 2014년 2월 ‘모드 페이지스피드’(mod_pagespeed)’라는 웹페이지 가속 기술을 발표했습니다.
구글의 설명에 의하면 서버단에서 사이트의 속도를 높이기 위해 페이지 로드 시간을 줄이고 웹 페이지 호출시간과 대역폭 사용을 효율화하는 방식을 적용했다고 합니다. 그것은 캐싱 극대화, 검색 최소화, 단위 요청 오버헤드 최소화, 데이터 크기 최소화 및 브라우저 렌더링 최적화라는 5가지 카테고리로 나누어 구현되었다고 하는데요.
그간 shared hosting 시절에는 생각도 못한 방법인데 이제는 서버를 마음대로 조정할 수 있으니 이러한 기술을 적용해 사이트 속도를 높여보고자 합니다.
2. NGGINX 서버에 모드 페이지스피드’(mod_pagespeed) 설치하기
NGINX 서버에 모드 페이지스피드’(mod_pagespeed)를 설치하는 방법은 주로 아래 내용을 참조하였습니다.
2.1. Nginx 설정 파일 백업 (Back up Nginx Configuration Files)
작업하다보면 무슨 문제가 있을지 모르므로 Nginx 설정 파일을 백업받아 놓습니다.
저는 FTP로 관련 파일을 내려받아 놓았습니다. 백업 받을 파일은 /etc/nginx/nginx.conf과 /etc/nginx/conf.n/default.conf의 파일 2개입니다.
그리고 서버 자체를 백업받아 놓는게 좋을 것 같네요. vultr에서는 Snapshot 기능을 제공하고 있으므로 본격적인 작업에 들어가기 전에 서버 자체를 백업받아 놓을 수 있었습니다.
2.2. Installing nginx with ngx_pagespeed
리눅스에서는 새로운 모듈을 설치하면 연관된 프로그램도 다시 설치하도록 가이드 하는 것 같습니다. 여기에서도 구글 모드 페이지스피드를 설치하기위해 Nginx 최신 버젼을 같이 설치하고 있습니다.
2.2.1. Add the nginx repository
이 단계는 Nginx 최신버젼을 받을 수 있도록 Nginx 최신 버젼이 있는 위치를 등록하는 것입니다.
여기에서는 아마 앞서 nginx를 설치하면서 설치 위치를 등록했을 것인데(저는 라엘님의 가이드에 따라 Nginx와 maria db 위치를 /etc/apt/sources.list에 업데이트 했는데요.) 이 페이지 스피드 설치 시는 조금 위치에 등록하라고 가이드하고 있습니다. 추가로 nginx repository를 만들어 등록합니다.
이 등록은 nginx.list 파일을 만들고 nginx repository를 등록하는 것입니다.
vi /etc/apt/sources.list.d/nginx.list
# 위 명령은 vi 편집기로 nginx.lst 파일을 편집하라는 명령입니다.
nginx.list에 아래 내용 추가합니다.
deb http://nginx.org/packages/ubuntu/ xenial nginx
deb-src http://nginx.org/packages/ubuntu/ xenial nginx
파일을 내려받을 수 있는 키를 등록하고 업데이트 진행합니다.
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ABF5BD827BD9BF62 # 저장소 키를 등록
apt-get update # 저장소 위치를 업데이트
2.2.2. Nginx 최신 버젼을 다운로드, Download nginx 1.10 from ubuntu repository
이번에는 Nginx 최신 버젼을 다운로드 받을 수 있는 폴더를 만들고 여기에 최신 버젼을 다운로드 받습니다.
cd ~ # 루트 디렉토리로 이동
mkdir -p ~/home/nginx/ # 다운받을 디렉토리 생성
chmod -R 744 ~/home/nginx/ # 뒷부분에서 권한 문제로 안되는 경우가 발생하므로 일정 권한
cd ~/home/nginx/ # 디렉토리로 이동
apt-get source nginx # Nginx 최신버젼을 다운받음
tar -xzvf nginx_1.13.0.orig.tar.gz # Nginx 최신버젼 수치를 확인 필요, 압축을 풀어 준다
Nginx 패키지를 만들기 위해서 모든 관련 프로그램을 설치합니다.
apt-get build-dep nginx
2.2.3. 페이지스피드 다운로드, Download Pagespeed
여기에서는 페이지스피드를 다운받을 폴더를 만들고, 최신 페이지스피드 파일을 다운 받습니다.
mkdir -p ~/home/ngx_pagespeed/ # 페이지스피드를 다운받을 디렉토리 생성
chmod -R 744 ~/home/ngx_pagespeed/ # 뒷부분에서 권한 문제로 안되는 경우가 발생하므로 일정 권한 줌
cd ~/home/ngx_pagespeed/ # 생성한 디렉토리로 이동
wget https://github.com/pagespeed/ngx_pagespeed/archive/latest-stable.zip
# 최신 버젼의 링크 주소로 최신 안정 버젼을 다운 받음
unzip latest-stable.zip # 압축을 풀어줍니다.
cd ~/home/ngx_pagespeed/ngx_pagespeed-latest-stable
# 압축을 풀고 생성된 디렉토리로 이동, 이 디렉토리 주소는 조금씩 바뀌니 ls 명력어로 확인이 필요합니다.
wget https://dl.google.com/dl/page-speed/psol/1.11.33.4.tar.gz
# latest-stable 버젼이 1.11.33.4.라서 PSOL libraries 파일을 받았습니다.
tar -xzvf 1.11.33.4.tar.gz
ls
2.2.4. 페이지스피드를 생성하기 위한 Nginx 환경 설정
페이지스피드를 생성하기 위헤서 Nginx 환경 설정을 합니다. 이는 Nginx가 다운 받아진 디렉토리로 이동해 debian 폴더의 rules라는 파일 내용을 수정합니다.
cd ~/home/nginx/nginx-1.13.0/debian/ # debian 디렉토리로 이동
vi rules # vi라는 편집기로 rules 파일을 수정
rules에 아래 내용을 추가하고 저장합니다. 내용 중 config.status.nginx and config.status.nginx_debug 부분에 각각 이 파라메터를 추가합니다.
2.2.5. Nginx Ubuntu 패키지를 만들고 설치, Build the nginx Ubuntu package and install it
Nginx를 받아 놓은 디렉토리(/root/nginx/nginx-1.13.0)로 이동합니다.
그리고 Nginx Ubuntu 패키지를 만듭니다.
cd ~/home/nginx/nginx-1.13.0/ # Nginx를 받아 놓은 디렉토리로 이동
servicr nginx stop # 서버 가동중이라면 nginx를 중단시킨다. 서버 세팅 초기에 설치한다면 문제가 없다.
dpkg-buildpackage -b # 패키지를 만듭니다.
이때 만들어진 Nginx Ubuntu 패키지는 /root/nginx/ 디렉토리에 저장됩니다. 이 디렉토리에 가보면 관련 여러가지의 파일이 형성되어 있음을 볼 수 있습니다.
다음으로 dpkg 명령어를 사용해 nginx와 페이지스피드 모듈을 설치합니다.
cd ~/home/nginx/ # 앞에서 수행한 dpkg-buildpackage -b 로 만들어진 파일은 ~/home/nginx 폴더에 만들어지므로 이 폴더로 이동한다.
dpkg -i *.deb
여기서 deb 확장자를 가진 전체를 실행시키지 읺고 dpkg -i nginx_1.11.10-1~xenial_amd64.deb(또는 dpkg -i nginx_1.11.10-1~xenial_i386.deb)라는 파일만 실행 시키라는 가이드도 있네요.
저는 그냥 *.deb 명령어를 사용했습니다.
3. 페이지스피드 환경 설정 및 테스트
위 단계가 무사히 끝나면 설치는 완료된 것입니다. 이후는 nginx 환경 설정에 페이지스피드 모듈 부분을 반영하고 테스트 해주는 것입니다.
3.1. Nginx 환경 설정에 반영
환경에 설정에 반영은 두곳에서 설정해야 합니다.
첫째는 Nginx관 관련된 환경을 설정해주는 nginx.conf 에 반영해주는 것인데 여기서는 사용자, HTTP, Module 등을 정의해 줍니다. 둘째는 서버 전체 환경을 제어해주는 default.conf 에서 적용하는 것으로 여기서는 Server, location 등의 정보를 정의해줍니다.
아래는 Nginx 환경 설정에 반영된 내용입니다.
3.1.1. nginx.conf 반영
여기서는 페이지스피드를 작동시키고 (pagespeed on;), 파일 캐시 경로를 지정합니다. 이 캐시 파일 경로 FileCachePath도 필수값으로 반드시 이를 저장할 위치를 반영해야 합니다.
페이지스피드에는 많은 필터가 기본으로 작동하지만 이중에서 성능에 영향을 미찬다고 여겨지는 자바스크립트 지연 실행(pagespeed EnableFilters defer_javascript;) 등을 추가하였습니다.
자바스크립트 지연실행은 자바스크립트가 헤더나 본문 등에 섞여 있는 경우 자바스크립트가 렌더링을 막기 때문에 렌더링 후에 자바 스크립트를 실행토록 명령을 주는 것입니다.
pagespeed on; # enable pagespeed module on this server block
pagespeed RespectVary on; # Respecting Vary Headers
pagespeed CreateSharedMemoryMetadataCache "/var/cache/pagespeed/" 51200;
pagespeed FileCachePath /var/ngx_pagespeed_cache; # Needs to exist and be writable by nginx. Use tmpfs for best performance.
pagespeed FileCacheSizeKb 102400000; # 이 용량만큼 cache를 적용 후 다 차면 비운다
pagespeed FileCacheCleanIntervalMs 3600000; # 이 시간마다 체크 아마 허용 용량을 따르는 듯
pagespeed FileCacheInodeLimit 50000000;
pagespeed CssFlattenMaxBytes 5120;
pagespeed LRUCacheKbPerProcess 8192;
pagespeed LRUCacheByteLimit 16384;
pagespeed JpegRecompressionQuality 70;
pagespeed RewriteLevel CoreFilters;
# enable additional filters selectively
pagespeed EnableFilters prioritize_critical_css;
pagespeed EnableFilters defer_javascript;
pagespeed EnableFilters combine_css,combine_javascript;
pagespeed EnableFilters add_head,combine_heads;
pagespeed EnableFilters collapse_whitespace;
pagespeed EnableFilters insert_dns_prefetch;
pagespeed EnableFilters move_css_above_scripts;
pagespeed EnableFilters move_css_to_head;
pagespeed EnableFilters sprite_images;
pagespeed EnableFilters recompress_png;
pagespeed EnableFilters convert_png_to_jpeg,convert_jpeg_to_webp;
pagespeed EnableFilters inline_preview_images;
pagespeed EnableFilters collapse_whitespace,remove_comments;
pagespeed EnableFilters make_google_analytics_async,make_show_ads_async;
pagespeed EnableFilters rewrite_images,rewrite_css,rewrite_javascript; # enable image optimization
pagespeed EnableFilters responsive_images; # defer the loading of images which are not visible to the client
pagespeed EnableFilters resize_mobile_images;
pagespeed EnableFilters lazyload_images;
pagespeed EnableFilters defer_iframe;
pagespeed EnableFilters defer_javascript;
pagespeed EnableFilters collapse_whitespace; # enable collapse whitespace filter
pagespeed EnableFilters canonicalize_javascript_libraries; # enable JavaScript library offload
pagespeed EnableFilters elide_attributes; # remove tags with default attributes
pagespeed EnableFilters extend_cache; # improve resource cacheability
pagespeed EnableFilters flatten_css_imports; # flatten CSS files by replacing @import with the imported file
pagespeed EnableFilters prioritize_critical_css; # rewrite CSS to load page-rendering CSS rules first.
pagespeed MapOriginDomain "http://localhost" "https://www.happist.com"; # Map the origin domain
pagespeed LoadFromFile "https://www.happist.com" "/home/happist/static/"; # Load static files(Image, CSS, Script파일과 같이 그 내용이 고정되어 응답을 할 때 별도의 처리 없이 파일 내용을 그대로 보내주면 되는 파일을 의미) from disk
# Configuring SSL Certificates
pagespeed SslCertDirectory directory;
pagespeed SslCertFile file;
3.1.2. default.conf 반영
여기에서는 PageSpeed 관련 위치 정보를 설정해 줍니다. 어던 경우는 이 위치 정보도 nginx.conf에 반영해도 무리가 없었는데 먹히지 않은 경우도 있습니다.
location 정보는 default.conf에서 정의해주고 있으므로 여기에 반영해 줍니다.
# Ensure requests for pagespeed optimized resources go to the pagespeed handler
# and no extraneous headers get set.
location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" {
add_header "" "";
}
location ~ "^/pagespeed_static/" { }
location ~ "^/ngx_pagespeed_beacon$" { }
3.2. Nginx 페이지스피드 테스트
Nginx 환경 설정에 적용된 항목들이 문제는 없는지 테스트 점검해 보고 문제가 없으면 nginx를 재실행 시킵니다. 마지막으로 curl 명령어로 웹서버 상태를 점검해 봅니다.
nginx -t
# Nginx를 테스트 해봅니다. 환경 설정에 문제가 있으면 문제점을 출력해주고 없으면 아무 메세지없이 다음 명령을 기다리는 명령 프롬프트로 이동합니다.
systemctl restart nginx # 시스템을 재시작
curl -I 192.168.1.6
4. 페이지스피드 설치과정에서 만난 오류 및 대처
이 페이지스피드를 설치하면서 몇가지 오류을 만났는데요. 이 오류 및 해결 내용을 간략히 소개합니다.
4.1. internal compiler error
설치중 internal compiler error랄 만났습니다. 이 문제에 봉착하고나서 인터넷을 뒤지다보니 메모리의 문제가 아니냐는 지적이 있었습니다. 거기에서는 4GB 메모리로 업그레이드했다는이야기가 있어서 768MB 메모리를 쓴 저로서는 감당이 안되겠다는 생각에 절망에 빠졌는데요..
혹시 일반 PC처럼 서버를 다시 가동시키면 필요한 메모리가 확보되지 않을까하는 생각이 들어서 서버를 restart시켰습니다.
그랬더니 (필요한 메모리가 확보되었는지) 제대로 작동을 하더군요.
결론 – internal compiler error시 메모리확보를 위해 서버를 재가동해보자.
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc directive
cc: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
4.2. 테스트는 루트사용자로 해보자
설정이 제대로 이루어졌는지 계속 체크하고 있는데 환경 설정 문구를 조금만 바꾸어도 게속 에러가 나더군요.
인터넷등에서 확실한 옵션이라고 주장을 해도 제 사이트에서 적용 후 테스트를 해보면 바로 에러가 뜹니다.
아래 그 생생한 예입니다.
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2016/09/16 02:55:29 [warn] 14896#14896: the "user" directive makes sense only if the master process runs with super-user privileges, ignored in /etc/nginx/nginx.conf:2
2016/09/16 02:55:29 [info] 14896#14896: [ngx_pagespeed 1.11.33.3-0] No threading detected. Own threads: 1 Rewrite, 1 Expensive Rewrite.
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
2016/09/16 02:55:29 [emerg] 14896#14896: open() "/var/run/nginx.pid" failed (13: Permission denied)
nginx: configuration file /etc/nginx/nginx.conf test failed
여러번 삽질을 하다가 일반 사용자가 sudo 명령으로 점검하지말고 그냥 루트사용자로 테스트해보자고 루트 권한으로 들어와 테스트를 해보니 아무 문제없이 통과되더군요..
결론 – 환경 설정 시는 가능하면 루트사용자로 테스트 하자
5. 모드 페이지스피드(mode PageSpeed) 적용 결말
마찬가지로 많은 삽질을 거쳐 페이지스피드를 적용했습니다. 어디에선가 적용하기 전후 차이가 거의 10배나 차이가 난다는 글을 본적이 있는데 저의 경우는 로딩 스피드가 2초이상 빨리진것 같습니다.
유감스럽게 로딩스피드가 5초~6초대로 상당히 늦은 편이었는데 모드 페이지스피드를 설치하고는 3~4초대로 빨라졌습니다. 이러한 속도 개선에는 매우 만족스러웠고 현재 사용하고 있는 WP Rocket 플러그인을 사용하지 않아도 되지 않을까하는 생각이 들었습니다. WP Rocket을 적용하는 것과 비적용하는것의 차이가 크진 않았습니다.
Ticket.om 광고를 보고나서 여행 관련 광고를 찾아보았습니다. 가슴을 뛰게하고 여행을 떠나고싶게 유혹하는 광고가 무엇이 있을까?
나름 의미를 담은 여행광고를 모아 공유해봅니다. 문득 여행이 떠나고 싶어지는 시간네요.
1. 루이비통 Life is Journey – 매니페스토(Manifesto) 영상
루이비통은 럭셔리 브랜드 최초로 동영상을 이용한 브랜드 이미지 광고를 만들었습니다. Long Version은 2분 48초 분량이고 많이 알려진 Short Version은 1분 36초 분량으로 ‘인생 그 자체가 여행’이라고 규정하면서 여행이란 단순 히 관광이나 휴가가 아니라 자아를 발견하는 과정이라고 이야기 하고 있습니다.
그저 여행을 떠나세요. 그 매 순간이 바로 인생입니다.
Long Version
Short Version
Directed by Bruno Aveillan, this beautiful film won several awards like Gold Clio Award, Gold London International Award, Epica Award, Mobius Award, World Medal at New York Festival, Top Com d’or, Grand Prix Stratégie, …
what is a journey ? 여행은 무엇일까요 ? a journey is not a trip. 여행은 단순한 소풍이 아닙니다. it’s not a vacation. 휴가도 아닙니다. it’s a process , a discovery . 여행은 과정이며 발견입니다. it’s a process of self-discovery. 여행은 자아발견의 과정입니다. a journey brings us face to face with ourselves. 여행은 우리를 우리 자신과 마주보게 합니다. a journey shows us not only the world , but how we fit in it . 여행은 세상을 보여줄뿐만 아니라 어떻게 우리가 살아가고 있는지도 보여주지요 does the person create the journey ? 인간이 그런 여행을 만드는것일까요 ? or does the journey create the person ? 아니면 여행이 그런 인간을 만드는것일까요 ? the journey is life itself. 여행은 인생, 그자체 입니다. WHERE WILL LIFE TAKE YOU ? 인생은 당신을 어디로 데려갈까요 ?
2. 샘소나이트 – Travel Lighter To Go Further – Samsonite
여행 가방 판매를 주요 비지니스로하는 샘소나이트 광고입니다.
샘소나이트는 아름다운 여행 사진을 정렬하는 것에 비해서 계량할 수 없는 여행의 짐들의 의미를 추억과 모험에 비유하고 있습니다.
샘소나이트에게 있어서 여행의 짐들이란 여행의 경험의 매개자로 포지션되어 스토리를 풀어나가고 있습니다.
3. Corona Extra : A Journey by Taylor Steele – From Where You’d Rather Be
코로나 호주법인에서 공유한 코로나 광고입니다. 자유로운 히피 정신을 엿볼 수 있는 자유로움, 여유 그리고 간간히 비추는 코로나 맥주 한잔!! 그리고 마음을 동하게하는 음악!!
분위기가 다소 옛날처럼 느껴지는 데 1976년 몇몇 친구들과 맥시코 서해안을 따라 떠난 여행을 전설적인 surf 감독인 Taylor Steele이 이를 필름으로 담았다고..
그래서 한편의 영화같은 광고가 태어났나 보네요..
절로 떠나고픈 생각이 듭니다. 그 전에 맥주한잔 해야겠습니다.
2010년 광고인데 HD 파일이 올려져 있네요..
4. Watchtower of Turkey
이탈리안 영화감독 Leonardo Dalessandri가 20일동안 3500km를 여행하면서 담은 이미지를 토대로 작업한 터키에 대한 이야기.
영화감독이 만들어서 그런지 일반 홍보 광고와는 차원이 다른 듯..
5 호주의 여행사 STA Travel Australia의 Move, Eat, Learn series 광고
한국에도 많이 소개된 2011년 온에어된 호주 여행사 STA Travel의 광고입니다.
STA Travel Australia는 이 광고를 위해서 3명(Rick Mereki, Andrew Lees and Tim White)이 세계의 환상적인 여행지를 6주 동안 여행하면서 그 영상을 담아 광고를 제작했다고 합니다.
44일
11개국
18번의 비행
38,000 마일
1테라바이트의 영상
광고는 세계 유명 여행지 사진을 경쾌한 음악과 함께 보여주는 Move 편, 셰게 여행지의 다얄한 음식과 먹는 모습을 보여주면서 여행의 즐거움을 이야기하는 EAT편, 세계를 여행하면서 다양한 기술이나 학습을 통해서 하나씩 배워난가는 과정을 담은 Learn편의 3가지 영상으로 구성되어 있습니다.
아무래도 대표적인 광고이고 가장 흥미있게 편집된 Move편이 가장 인기가 좋네요. (2016년 09.04 현재)
Move 조회수 1.6백만
EAT 조회수 0.6백만
Learn 조회수 0.5백만
6. Travel Alberta, Canada
Rremember to breathe!!
캐나다 앨버타를 홍보하기 위한 광고 영상, 너무 아름다운 풍광의 연속이라 입을 다물 수 없네요. 조회수도 5.5백만을 기록하고 있구요.
아래는 Summer in Alberta라는 동영상입니다. 이 역시 볼만합니다.
7. 호주관광청 There’s Nothing Like Australia
관광대국답게 호주는 호주 관광에 대한 광고 커뮤니케이션을 활발히 하고 있는데요.
호주관광청에서 There’s Nothing Like Australia라는 주제로 호주를 홍보했던 TVC를 소개합니다.
호주의 아름다운 자연을 배경과 경쾌한 음악을 통해서 호주로의 여행을 이야기하고 있습니다.
아래는 There’s Nothing Like Australia라는 주제로 3분짜리 영상입니다. 조용한 음악과 함께 호주의 아름다움을 잔잔하게 그리고 설득력있게 보여주고 있습니다.
아래는 2016년 온에어 된 신규 광고인데요. Tourism Australia and Chris Hemsworth를 제목으로 온에어되어 2.5백만이상 조회수를 기록하고 있습니다.
How can the colour blue be a feeling? Well, it’s hard to describe. But it is. You see, it’s different down here. The air just has more life in it. Sounds touch you. And the light fills you up somehow. Yeah, it’s a place that stays with you. And sometimes, if you’re lucky, it stays forever. Because Australia isn’t just a place you see… It’s a place you feel.
8. Incredible India
인도관광청에서 제작하는 Incredible India는 해마다 버젼을 달리하면서 인도를 세계에 소개해 오고 있는데요.
2010년도 버젼이 가장 매력적으로 알려진 것 같습니다. 아래 Incredible India 2010를 HD로 리마스터링한 버젼인데 조금 어색하긴 합니다.
인도 관광청에서 제작한 Incredible India 2013의 감독판이라고 합니다. 무슨 광고가 감독판이 있는지 모르지만 반응이 좋으니 Director’s Cut도 나오는 것이겠지요.
directed by Prakash Varma produced by Nirvana Films
9. ESTRELLA DAMM
이 역시 ESTRELLA DAMM이라는 맥주회사에서 만든 고아고입니다.
나선곳으로 여행 그리고 만남 한잔의 맥주와 즐기는 즐거운을 겨쾌한 음악과 함게 표현해 내었습니다. 앞에서 소개한 코로나와 같은 컨셉이라고나 할까요..
ESTRELLA DAMM는 해마다 여행이라는 컨셉으로 광고를 제작하고 있습니다. 그 중에서 가장 경쾌한게 여기서 소개하는 2009년 광고로 보여지네요.
아래는 2012년도 버젼… 아주 조금 수위가 있네요.
10. Expedia – Expedia technology connecting you to what matters
이 번에는 Expedia라는 여행사(?) 광고입니다.
테크날러지를 이용해 여행의 모든 것을 누구나 쉽게 이용할 수 있도록한다는 점을 이야기 하고 있습니다.
2015년 온에어 되어 2백만이상 조회된 Zoo편과 2016년 4월 온에어 된 goodby 편을 소개해 봅니다.
Making connections with people and places is why we travel.
Expedia technology connecting you to what matters
2016년 4월에 온에어 한 Goodbye
11. Silja Line: Project Rediscovery
이 Project Rediscovery는 TVC 광고가 아니라 Project Rediscovery라는 프로모션 이벤트에 대한 내용입니다.
발틱해를 주무대로 크루즈 여행에 집중하는 Silja Line에서 핀란드와 스웨덴의 아름다움의 재발견을 목표로 Project Rediscovery를 진행하면서 만든 동영상입니다.
핀란드와 스웨덴이 면해있는 발틱해의 아름다움을 재발견하고자 Silja Line은 아르젠티나와 일본과 미국에서온 3명의 사진가를 보내 발틱해를 크루즈하면서 그 아름다움을 담아 site에 올려 누가 더 많은 호응을 얻어내고 네티즌의 동참을 이끌어내는 이벤트를 통해서 발틱해의 아름다움을 널리 알리려는 캠페인입니다.