-1.6 C
New York
토요일, 12월 13, 2025

Buy now

[광고] 겨울 사진 촬영 사진가의 최적 방한바지 추천

겨울철 활동성과 방풍/방한 기능을 모두 갖춘 바지를 온라인 쇼핑몰에서 현명하게 비교하여 구매하실 수 있도록, 주요 제품 유형별 특징과 고려해야 할 사항을 비교 분석하여 방한바지...

쿠팡 이용자 개인정보 유출 대응 방법 : 2단계 인증(2FA) 설정과 결제수단 삭제

안녕하세요, 쿠팡과 같은 대형 플랫폼의 개인정보 유출 소식은 언제나 불안함을 안겨줍니다. 현재 특정 시점의 대규모 유출 사건을 염두에 두고 계신지, 아니면 일반적인 보안 우려 때문에...
Home Blog Page 376

[워드프레스 Tips] phpMyAdmin 사용하지 않고 워드프레스 데이타베이스 백업하기

VPS를 운영하다보니 예기치 않은 사태에 직면하곤 합니다.

오늘 백업을 받지 않고 겁없이 새로운 프로그램을 설치하다 인터넷 사이트가 먹통이 되었습니다.

memcached 가능을 추가하기 위해 apt-get install -y php-memcached 명령을 주고 설치까지는 무사히 끝났는데 그 이후 많은 에러를 뿜어내면서 접속 불가가 되네요..

이제는 이런 상황이 와도 당혹스럽지는 않더군요.
어떻게 해결 방법이 있겠지하면서..

1. 인터넷 접속 불가 시 DB 백업 방안을 찾아라

사이트가 먹통이 되고 이게 쉽게 복구될 기미가 보이지 않자 DB를 백업하고 시스템을 복원하기로 했습니다.

  • 시스템은 며칠 전 스냅샷이 있어서 이를 활용하가로 하고

  • 이후 업데이트 내용은 DB 백업을 토대로 복구하기로 한것이죠..

그런데 인터넷 접속불가되면서 phpMyAdmin 접속도 않되더군요.. 예전에 하던 방식이 통하지 않으니 슬슬 겁이나기도하고

인터넷 접속이 안되어 mysql을 사용할 수 없다면 DB를 조작하는 다른 방법이 있지 않을까요?

그래서 또 방법을 찾아보니 서버에 접속해 command line에서 명령어를 입력해 백업받는 방안을 찾아 적용했습니다.

전문가분들에게는 아무것도 아니지만 초보 입장에서 기록하는 기분으로 정리해 봅니다. 제 스스로의 참고자료를 겸해서

아래는 사이트 접속이 되지 않아 phpMyAdmin을 사용하지 않고 서 DB를 백업받는 방안입니다.

2. phpMyAdmin 사용하지 않고 Marian DB나 mysql DB 백업하기

사이트 접속이 않되면 SFTP나 Telnet으로 접속해 방안을 찾아봐야 합니다.

여기에서 사용하는 것은 telnet으로 접속해 먕령어로 DB를 백업받는 방안입니다.

Marian DB(마리안디비)나 mysql DB(마이네스큐엘디비)아직까지는 한가지와 마찬가지로 동일한 명령을 사용할 수 있습니다.

mysql DB 백업은 mysqldump 명령어를 사용합니다.

마리안디비 MarianDB

2.1. 개별 DB 백업 방법

아래는 DB를 개별적으로 백업 시 사용하는 명령어입니다.

mysqldump -u [사용자] -p [백업할 DB명] > [백업 파일명].sql

mysqldump -u root -p pass DBname > /home/mysite/backup.sql
  1. root 에 db계정명을 적습니다.
  2. pass 부분에 mysql 비밀번호를 적습니다. 비밀번호를 적지 않고 넘어가면 mysqldump 명령어 수행시 비밀번호를 물어봅니다.
  3. dbname 부분에 db명을 적습니다,
  4. backup 부분에 백업할 폴더 위치 및 파일명을 적습니다.

2.2. mysql 전체 DB 백업

아래는 DB 전체를 통째로 백업하는 방법입니다.

mysqldump -uroot -p -A > backup.sql
혹은
mysqldump -uroot -p --all-databases > backup.sql

2.3. 특정 db, 특정 테이블 또는 schema 정보만 백업

wp라는 특정 DB만 백업합니다.

mysqldump -uroot -p wp > wp.sql

다음은 wp 데이터베이스의 contents 테이블만 백업합니다.

  1. DB명이 wp인 경우
  2. contents 테이블을 백업하시오
mysqldump -uroot -p wp contents > wpcontents.sql

아래는 mysql schema 정보만 백업하는 경우입니다.

mysqldump -uroot -p --no-data schemainfo > schemainfo.sql

3. 백업받은 DB 복원

백업한 db를 복원하는 방법입니다.

mysql -u [사용자] -p [복구할 DB명] < [백업 파일명].sql

mysql -u root -p wp < wpbackup.sql

4. 자동 백업하도록 만들기

자동 백업할 폴더를 만들거나 지정한다.

backup폴더를 만들자

mkdir /backup
자동 백업할 폴더를 만들거나 지정한다.

/backup폴더에 755 권한을 부여하자

chmod 755 /backup
자동 백업 Shell 프로그램 작성

자동으로 백업이 이루어지도록 sh 프로그램을 만든다.

#!/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에서 제안한 내용을 많이 반영했습니다. 이 자리를 빌어 감사드립니다.

[워드프레스 Tips] 워드프레스에서 썸네일 이미지 생성 불가시 해결 방법

VPS로 사이트를 옮기로나서 여러가지 시행착오을 격었는데 여기서 정리하는 썸네일이미지를 생성하지 못하는 경우도 그것이다.

VULTR로 옮기고나서 해킹도 당해보고 여러번 서버 설치도 해보면서 정말 이 동네 일이라는게 어렵다는 생각을 절로 하게된다. 그렇다고 중간에 중단할 수도 없어서 초보로선 어쩔 수 없이 많은 시간을 투여할 수 밖에 없었다.

조금 지나면 여유롭게 운영할 수 있는 시기가 올리라는 희망을 가지고서…

1. 문제 제기 – 서버 세팅 후 워드프레스에서 썸네일이 생성되지 않는다.

제목을 거창하게 문제제기라 썼지만 문제점 발견이라고해야 겠다.

지난주에 내 사이트가 해킹이 되었다는 Matthew님의 연락을 받고 사이트를 우서 며칠전에 백업한 상태로 되돌리고 이번 주말과 연휴에 사이트를 다시 세팅하였다.

OS를 새로 설치히고 (이는 VULTR dashboard에서 간단히 할 수 있는 일이다.) Nginx, PHP7.0-FPM, MARIADB 등 기본 프로그램을 설치하고 pageSpeed, SSL 등을 설치하고 최종 Wordpress를 설치 복원하였다..

그리고 이번 기회에 워드프레스테마를 무겁고 VC 빌더를 사용해 다소 무겁다는 newspaper 7에서 EXTRA로 변경해 보았다,

그런데 이 EXTRA를 설치하고 최적화하는 과정에서 도대체 썸네일이 매칭이 않되는 것이었다.

도대체 뭐가 문제일까?

EXTRA 테마 정면 이미지 Extra-theme-main-image

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으로 다운그레이드한 경우처럼..

관련 분야에 폭넓은 지식을 가지고 있다면 해결책을 빨리 발견할 수 있겠지만 그렇지않으면 엄청난 삽질을 해야하므로 비지니스 측면에서 그런 삽질를 감당할 수없으니 소비자들에게잔소리말고 낡은 프로그램을 쓰라고 윽박지르는 것이 아닐까??

[워드프레스 최적화] OPcache를 활용한 워드프레스 속도 최적화 방안

1. 초보가 상식으로 정리해보는 cache 이야기

오늘 마지막으로 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로 나눌 수 있다.
    NGINX 서버 작동 플로우차트 Flow chart

  • 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 에서 가져왔습니다.

php opcache flow chart

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();
?>

PHP-info에서-Opcache-확인-화면

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가 어떻게 작동하고 있는지 모니터링하고 혹시 수정할게 있는지 확인하는 게 좋을 것 같습니다.

이 모니터링 프로그램은 PHP’s Zend Opcache Config & Web Viewer 에서 세가지 프로그램을 소개하고 있는데요. 저는 이중에서 Opcache-Status by Rasmus Lerdorf를 설치해 사용하고 있습니다.

cd /var/www/example.com/  # 설치하고 싶은 디렉토리로 이동
wget https://raw.github.com/rlerdorf/opcache-status/master/opcache.php

설치 후 인터넷 브라우저에서 설치주소/opcache.php 명령으로 모니터링 프로그램을 볼 수 있습니다. 아래 이미지가 모니터링 프로그램으로 확인한 내용입니다.

OPcache 모니터링툴 작동 모습

5. 마무리하면서

이상으로 간단히 OPcache에 대해서 살펴보았습니다. 단일 사이트에서 OPcache는 굉장히 효율적인 툴로 보입니다. 더우기 올해 PHP가 7.x에서 8.0으로 업그레이드가 되면 더욱 유용할 것으로 보입니다.

저는 Page Caching은 FastCGI를 적용하고, PHP Script Cache는 여기서 설명한 OPcache를 적용하며, 데이타베이스 관련해 Memcached를 적용해 사용하고 있습니다.
지금까지 성과는 나름 만족스럽습니다.

FastCGI나 Memcached에 대해서는 아래 포스팅을 참조하시기 바랍니다.

6. 관련 포스팅

[워드프레스 최적화] FastCGI cache 적용 워드프레스 반응 속도 및 서버 로드 줄이기

[워드프레스 최적화] 워드프레스에서 Memcached 이용해보기 – Ubuntu 16.04 + Nginx + PHP 7

10$ 제휴 프로모션으로 Vultr 가입하기

[워드프레스 최적화] OPcache를 활용한 워드프레스 속도 최적화 방안 1

[워드프레스 Tips] Nginx서버에서 phpMyAdmin DB 업로드 용량 확대 방법

이번에 사이트를 해외 가상서버호스팅 업체인 VULTR로 옮기다보니 서버 운영에 필요한 여러가지 프로그램을 알아서 설치해야 했습니다.

프로그램 설치는 워낙 가이드들이 잘 되어 있어 커다란 어려움을 없었는데 문제는 실제로 서버를 운영하면서 자잘한 설정문제가 대두되더군요.

별것도 아니지만 문제를 풀지않으면 불편한 것들이 참으로 많은데요. 그중 하나가 phpmyadmin에서 업로드 용량 문제가 아닐까 합니다.

서버에 필요한 프로그램을 다 설치하고, 워드프레스를 설치 이전하려고 phpmyadmin에서 DB를 불러오기를 했는데 기본 허용 용량이 2mb에 불과해 30MB가 넘는 DB 파일을 불러오기가 불가능하다는 겁니다.

이럴 경우는 phpmyadmin에 올릴 수 있는 DB 용량 크기를 늘려 줘야 합니다.

이 DB 용량 크기 조정은 phpmyadmin이라는 이름에서 알 수 있듯이 php 환경 부분과 서버인 Nginx 설정을 수정해 줘야 합니다.

즉 PHP 환경을 정의하는 php.ini 파일과 Nginx 환경을 정의하는 nginx.conf 파일을 수정합니다.

phpMyAdmin-원래위치

1. PHP 환경을 정의하는 php.ini 파일 수정

php.ini 파일은 /etc/php5/fpm/php.ini에 위치하고 있습니다.
이 php.ini 파일을 vi나 nano같은 에디터 프로그렘으로 수정해도되고 아니면 파일질라와 같은 ftp의 기본 편집기를 통해서 수정해도 됩니다.

처음 php.ini 파일을 열면 아래와 같이 기본으로 2mb가 설정 되어 있습니다.

이 2mb를 조금 통 크게 200mb로 변경합니다.

upload_max_filesize = 2M  → 200M으로 변경
post_max_size = 2M    → 200M으로 변경

2. Nginx 환경 설정 파일 nginx.conf 파일 수정

Nginx 환경 설정 파일 nginx.conf 파일을 열어서 내용을 수정합니다.

이파일은 /etc/nginx/nginx.cong에 있습니다.

    ~ 중략
    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;
    client_max_body_size 20m;  → 200M으로 변경
    #gzip  on;
   ~ 하략

3. Nginx와 php를 재시작해 변경 사항을 반영합니다.

설정파일을 변경했다고해서 바로 반영이 되는 게 아니므로 Nginx와 php를 재시작해 변경 사항이 시스템에 반영되도록 합니다.
이들이 재시작하는 시간은 매우 짧으므로 변경한다고해서 문제될 게 거의 없습니다.

service php5-fpm restart
service nginx restart

이런 후 phpMyAdmin에 들어가보면 업 가능한 용량이 200M으로 증가되어 습니다.

phpmyadmin-업용량

해외 가상서버호스팅(VPS)이 국내 호스팅보다 빠르다? – 아이비호스팅과 해외 가상서버호스팅 VULTR간 비교

아이비호스팅을 사용하면서 아이비호스팅에서 제공하는 SSD 사용, PHP7 적용등이 실지로는 기대한만큼 사이트 속도 개선에 별로 도움이 안된다는 판단에 따라 해외가상서버호스팅을 알아봤습니다.

지난번에 포스팅한 SSD와 PHP 7을 적용하면 사이트가 날아다닐까? – 아이비호스팅과 루아틱호스팅 비교기 참조

즉 SSD와 PHP 7을 적용해도 서버 사양이나 서버 세팅에 따라 성능 및 속도가 달라질 수 있다는 사실을 HDD와 PHP 5.5를 적용한 루아틱이 오히려 더 나은 속도 및 퍼포먼스를 보여줌으로써 증명되었습니다.

그리고 아이비호스팅을 이용하면서 한국업체이므로 서비스가좋고 편하다는 느낌을 받을 수 없었고 모든 문제를 내가 알아서 해결해야하므로 한국 업체의 서비스가 무의미했습니다. 대부분 문제를 구글링을 통해 해결해야하는 실정이라면 그냥 해외업체를 쓰는게 속편하겠다는 생각을 했습니다.

그래서 서버 사양이나 세팅을 어느정도 자유롭게 할 수 있는 VPS 가상서버호스팅을 고민하기 시작했습니다.
그렇지만 VPS 가상서버호스팅이 자유롭게 서버등을 최적화 할 수 는 있지만 (국내업체는 너무 비싸므로) 가격 경쟁력을 갖춘 해외업체를 사용해야 하므로 해외 가상서버호스팅이 과연 만족할만한 속도를 내줄 것인지가 의문이었습니다.

최소한 현재 shared hosting인 아이비호스팅보다는 빨라야 옮길 수 있는 명분이 있는게 아닐까 싶었습니다.

그래서 VPS 가상서버호스팅과 아이비호스팅을 비교해 보기로 했습니다. 이의 결과에 따라 VPS 서버호스팅이 대안이 될 수 있을지를 결정하기로 했습니다.

1. VPS(가상서버호스팅 ) 선정

인터넷 검색 결과 속도 및 가격을 고려해 VULTR.com을 선정했습니다.
VULTR을 선정한 이유는

  • VPS를 분석한 Lael님의 추천이 있었고
    국내외 VPS업체에 대해서는 Lael’s World에서 잘 정리되어 있어 이를 주로 참조헸습니다.
    국내 클라우드 서버호스팅 비교(Virtual Private Server Review)

    여기에서 VULTR이 서버 성능 측정시 뛰어났고 속도가 빨라서 추천 1순위로 올려놓았더군요.

  • 가격 및 성능 측면에서 검토 유력 업체중에서 거의 유일하게 768MB 램에 5$부터 시작하고 있어서 가격적인 부담이 가장 적었고
  • Snapshot 지원 등 부가 기능도 경쟁력이 있었습니다.

뭐니뭐니해도 가장 빠르다는 소리에 현혹되었습니다. ping 속도가 34ms까지 나온다고 해서..

국내업체가 10ms이하이므로 35ms정도면 해볼만하겠다는 생각이 들었습니다.

VULTR을 신청하고 집에서 ping test를 해보니 70ms가 나와 실망을 했습니다. 그렇지만 동네 PC방에서 40ms, 대전 처가집 PC방 40ms, 춘천 형네집에서 측정해보니 45ms정도 나와서 어느정도 속도가 나온다고 판단되었습니다.

VULTR-Billing-주문하기

2. VULTR 가상서버호스팅 세팅

VULTR을 등록하고 서버 세팅을 시작했습니다.
상세한 서버세팅 내용은 아래와 같습니다.
VUULTR에서는 운영체제와 일부 Application을 깔 수 있도록 지원하지만 나머지는 알아서 설치해야 합니다.

  • 운영체제 : Ubuntu 16.04 x64
  • 웹서버 : Nginx 1.11.4
  • DB : Mariadb 10.1
  • PHP7-FPM 7.01
  • worpress 4.63

3. 워드프레스 마이그레이션

아아비호스팅에 세팅되어 있는 워드프레스 그대로All In One WP migration 플러그인으로 옮겨와 적용했습니다.

적용 방법은 지난 루아틱과 비교시 사용했던것과 똑같은 방식입니다.

All-in-One WP Migration_임포트 완료 화면

4. 아이비호스팅과 해외가상서버호스팅 VULTR과 비교

비교적 객관적 비교를 위해서 똑같은 워드프레스를 그대로 복제해 VULTR에 마이그레이션시켰으며, Cache 플러그인이 서버 설정이나 운영체제 영향을 받으므로 Cache 플러그인은 적용하지 않고 비교했습니다.

4.1. GTmatrix에서의 비교

첫번째 비교는 GTmatrix상에서 비교해 보았습니다.
여기에서 비교가 가장 Gap 컸는데 이상하게 아이비가 GTmatrix에서 속도가 잘 나오지 않더군요.

GTmatrix에서는 VULTR이 전반적으로 더 빠른 속도를 보여주었습니다.

서버 세팅이 완전하지 않은 상태이므로 점수는 조금 낮게 나옵니다.

결론 – GTmatrix에서는 해외가상호스팅인 VULTR이 상당히 좋게 평가

아이비호스팅과-해외-가상서버호스팅-VULTR과-비교_GTmatrix

아래는 GTmatrix에서 측정한 결과를 일부 캡춰해 봤습니다.

GTmatrix-아이비-WPRocket-제거-01

GTmatrix-VULTR-WPRocket-제거-01

4.2. Pingdom test 결과

이번에는 Pingdom에서 테스트한 결과입니다.
앞의 GTmatrix와 달리 아이비호스팅도 크게 나쁘지 않은 결과를 보여주었습니다.

그렇지만 미세하게나마 해외 가상서버호스팅인 VULTR이 나아 보입니다.

아이비호스팅과-해외-가상서버호스팅-VULTR과-비교_Pingdom-test

아래는 측정 결과를 캡춰한 이미지입니다.

Pongdom_VULTR-WP-Rocket-제거-01

Pongdom_아이비-WP-Rocket-제거-01

4.3. 크롬 개발자도구에서 측정한 결과

앞에서 측정한 GTmatrix나 Pingdom은 해외에서 측정하므로 아무래도 일본에 서버를 둔 VULTR이 유리할 수 있다고 보았습니다.

그래서 크롬의 개발자도구에서 측정한 값을 비교해 보았습니다.
이 크롬에서 측정한 결과도 해외 가상서버호스팅인 VULTR이 전반적으로 우수한 지표를 보였습니다.

아이비호스팅과-해외-가상서버호스팅-VULTR과-비교_크롬-개발자도구

5. 결론 – 해외 가상서버호스팅 VULTR이 전반적으로 우수하고 옮겨도 무방하겠다.

위 세가지 지표로 분석해 본 결과 해외 가상서버호스팅 VULTR이 전반적으로 우수하다고 판단되었습니다.

속도가 국내호스팅보다 나오지 않을까 걱정했는데 그럴 정도는 아니라는 결론에 도달했고 서버를 더욱 더 최적화시킨다면 더 빨라질 수 있다는 희망이 있으므로 해외 가상서버호스팅 VULTR로 이동해도 되겠다는 결론을 얻었습니다.

참고로 가격측면에서도 VULTR은 월 $5 plan을 사용하고 20$ 프로모션에 가입하면 첫해는 연간 40$에 이용가능하므로 아이비호스팅의 연간 66000원(VAT 포함) 비해서 크게 밀리지 않는다고 할 수 있습니다.

더 많은 SDD 용량과 트래픽용량 그리고 서버를 자유롭게 조절할 수 있는 자유로움은 이전할 수 있는 충분한 메리트를 주고 있습니다.

그렇지만 국내도 제대로 된 경쟁이 시작되어 가성비를 쫓아 해외호스팅업체를 기웃거리지않는 시대가 오길 바랍니다.
아무래도 해외업체들은 불편한 점이 있기는 합니다.

광고 – Vultr 25$ 프로모션

Vultr에 관심이 있다면 아래 프로모션으로 Vultr에 가입해 보세요.
물론 그전에 더 좋은 프로모션이 있는지 체크해 봐야 합니다.

Vultr의 좋은 점이 다양한 프로모션이 많아서 초기에 저렴하게 이용할 수 있다는 점이었죠. 최근에는 그런 좋은 조건들이 많이 사라진 것 같긴 합니다.

25$ 프로모션으로 Vultr 가입하기

해외 가상서버호스팅(VPS)이 국내 호스팅보다 빠르다? - 아이비호스팅과 해외 가상서버호스팅 VULTR간 비교 2

Let’s Encrypt SSL 인증서 발급 및 자동 갱신 방법(업데이트)

여기에서는 Let’s Encrypt SSL 인증서 발급 및 자동 갱신 방법에 대해서 살펴 보도록 하겟습니다. 이 글 작성 후 변경 사항 등이 있어 최신 방법으로 업데이트 하였습니다.(2020년 12월 25일)

앞선 포스팅에서 무료 SSL 인증서를 비교해 보았고 그 중 향후 가능성이나 사용편리성을 고려시 Let’s Encrypt가 가장 낫겠다고 판단했고 이를 적용하겠다고 했습니다.

이번 포스팅에서는 Let’s Encrypt를 통해서 무료 SSL인증서 발급받고 자동으로 연장하는 방안에 대해서 살펴보도록 하겟습니다.

1. Let’s Encrypt 간략 소개

SSL-인증기관-lets-encrypt-2

앞 포스팅에서 소개한 내용을 그개로 여기에서도 인용해 봅니다.

Let’s Encrypt은 HTTPS의 확산이 늦어지는 것은 SSL인증서에 있다고 보고 무료 인증서 보급을 통해 HTTPS의 확산을 늘리겠다는 취지로 시작된 비영리 프로젝트입니다.

Mozilla, Akamai, Cisco, eff, Identrust, 지말토(Gemalto)와 HP 엔터프라이즈, 패스틀리(Fastly), 두다(Duda)등이 스폰서로 참여해서 HTTPS Everywhere를 모토로 100% 무료 SSL 인증서를 발급 해주고 있습니다.

2016년 4월 정식 버젼을 출시했으며 2020년 12월 기준 2.34억개의 웹서버 인증이 진행되었습니다. (Let’s Encrypt 홈페이지 통계 기준), 참고로

  1. 인증서 발급 기관, CA(Certificate Authority) 중 점유율이 가장 높은 곳은 IdenTrust로 2020년 12월 기준으로 42%가 넘습니다.(42.3%)
  2. IdenTrust 다음으로는 DigiCert Group(15.7%) > Sectigo(14.1%) > GoDaddy Group(5.4%) > GlobalSign(2.3%
  3. Let’s Encrypt 점유율은 생각보다 낮아서 0.1%에 불과
  4. 하지만 Let’s Encrypt 사용을 아래 그래프에서 보듯 매우 빠르게 증가
    (개인적인 생각으로는 무료이기 때문에 테스트로 중복 인증도 많다고 생각)
Let’s Encrypt SSL 인증서 사용 증가 추이, Graph by 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가지 방법 중 하나를 선택해 진행할 수 있습니다.

  1. webroot : 사이트 디렉토리 내에 인증서 유효성을 확인할 수 있는 파일을 업로드하여 인증서를 발급하는 방법
    . 실제 작동하고 있는 웹서버의 특정 데렉토리의 특정 파일 쓰기 작업을 통해서 인증
    . 이 방식의 장점은 nginx를 중단시킬 필요가 없음.
    . 이 방법의 단점은 인증 명령에 하나의 도메인 인증서만 발급 가능
  2. 웹서버
    . Nginx나 아파치와 같은 웹서버에서 직접 SSL 인증을 실시하고 웹서버에 맞는 SSL세팅값을 부여
    . 발급이나 갱신을 위해 웹서버를 중단시킬 필요가 없음
    . 인증서 갱신 시 상황에 맞게 세팅을 자동으로 업데이트
    . 사용자가 세팅을 변경할 수 있지만 자동 업데이트 시 반영되지는 않음
  3. Standalone : 사이트 작동을 멈추고 이 사이트의 네크워킹을 이용해 사이트 유효성을 확인해 Let’s Encrypt SSL 인증서를 발급하는 방식
    . 80포트로 가상 staandalone 웹서버를 띄워 인증서를 발급
    . 이 방식은 동시에 여러 도메인을 발급 받을 수 있음
    . 그렇지만 인증서 발급 전에 Nginx를 중단하고 발급 완료 후 다시 Nginx를 시작해야 함
  4. DNS : 도메인을 쿼리해 확인되는 TXT 레코드로 사이트 유효성을 확인하는 방법
    . 와일드 카드 방식으로 인증서를 발급 가능
    . 이 방법은 당연하게도 서버 관리자가 도메인 DNS를 관리/수정할 수 있어야 하며
    . 인증서 갱신 시마다 DNS에서 TXT값을 변경해야 하므로
    외부에서 TXT 레코드를 입력할 수 있도록 DNS가 API를 제공하는 경우만 갱신 과정을 자동으로 처리(클라우두플레어 API가 대표적인 사례)

여기에서는 가장 안정적인 방식인 standalone 방식으로 SSL 인증서를 발급하는 방법에 대해서 알아보도록 하겠습니다. 보다 자세한 내용을 아래 글을 참조하시면 좋을 것 같습니다.

3. Let’s Encrypt에서 인증서 생성하기

현재 제 시스템 상황입니다.

  • Ubuntu 20.04
  • Nginx 1.19.64
  • PHP 8.0

Let’s Encrypt에서 제공하는 소프트웨어 클라이언트인 letsencrypt를 사용하면 쉽고 편하게 적용할 수 있습니다.

아파치서버에서는 완전 자동으로 SSL인증을 획득하고 적용할 수 있는 Nginx 서버에서는 이러한 자동화가 조금 늦게 적용되는 것 같습니다. Nginx에서의 자동화 방법은 없는것은 아니므로 이는 뒷부분에서 살펴보도록 하겠습니다.

아무튼 Nginx에서 Let’s Encrypt 인증서 생성에는 몇가지 조건이 있습니다.

  • root 접근 권한을 가지고 있어야 (즉 서버를 운영하고 있어야하므로 일반 웹호스팅은 안된다는 의미)
  • Let’s Encrypt가 아직은 공식적으로 Nginx를 지원하지 않은 상태이므로 아파치보다는 상대적으로 매뉴얼 작업이 필요합니다.

2.1. SSL 인증을 위한 Certbot tool 설치

Let’s Encrypt SSL 인증서 발급은 Certbot을 이용합니다.

Certbot은 우분투 20.04를 설치 후 letsencrypt을 설치했다면 그 안에 포함되어 있기 때문에 별도 Certbot을 설치할 필요가 없습니다.

sudo apt update
sudo apt-get install  letsencrypt -yCode language: PHP (php)

2.2. certbot으로 인증서를 생성

이렇게 Certbot tool이 설치되었다면 SSL 인증을 시작해 보도록 하겠습니다.

우선 웹서버를 중단시킵니다. 이는 80포트를 사용하지 않토록 만들기 위한 것입니다.

아무 디렉토리에서나 가능한 명령이지만 root로 이동해서 진행해 봅니다.

cd /root/
service nginx stopCode language: PHP (php)

이제 certbot 명령을 이용해 SSL 인증을 시작합니다. standalone 명령을 사용하고 도메인 이름만으로 인증이 진행되는 -d 옵션을 적용합니다.

certbot certonly --standalone -d 사이트명.com -d www.사이트명.comCode language: PHP (php)

그러면 아래와 질문들이 나오면서 인증이 진행됩니다. 첫번째로은 이메일 주소를 입력하라고 나옵니다. 이메일을 입력해야 다음 단계로 넘어갈 수 있으니 연락을 받을 수 있는 이메일을 입력합니다.

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 new or 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/donate
Donating to EFF:                    https://eff.org/donate-le 
Code language: PHP (php)

인증이 완료되면 웹서버를 다시 가동시킵니다.

service nginx restartCode language: PHP (php)

2.3. 여러개 도메인을 한번에 인증받기

이 standalone 옵션은 또한 한꺼번에 여러 개의 사이트를 인증 받을 수 있는데요. 아래와 같은 명령을 사용할 수 있습니다. 이는 연속해서 사이트명을 나열해주면 가능합니다.

service nginx stop

certbot certonly --standalone -d 사이트명.com -d www.사이트명.com -d 사이트명2.com -d www.사이트명2.com -d 사이트명3.com -d www.사이트명3.com

service nginx restart
Code language: PHP (php)

단 이렇게 여러개 사이트를 인증 받을 시 인증서 존재 위치가 맨앞 사이트명으로 통일되게 됩니다. 나중에 사이트를 없앨 때 난감할 수도 있습니다.

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) 라는 글에 의하면 실제로 보안을 제공하는 것은 인증서가 아니라 암호화 알고리즘이라고 이야기 하고 있습니다.

인증서를 획득하는게 중요한게 아니고 얼마나 철저한 암호화 설정을 하느냐가 중요하다는 것입니다.

이 중에서 중요한 것은 ssl_ciphers인데요. 이에 대해서는 모질라 재단에서 제공하는 SSL Configuration Generator를 사용하면 좋을 것 같습니다.

여기에서는 nginx 1.17.7을 기준으로 보안 설정을 추천하고 있습니다. 여기서는 NGINX 기준으로 모던 브라우저와 올드 브라오져 중간에 있는 Intermediate를 선택해 설정한 내용을 여기에 옮겨 봅니다.

server {
     listen 443 ssl http2;
     listen [::]:443 ssl http2;

     <code>ssl_certificate /path/to/signed_cert_plus_intermediates; </code>
     <code>ssl_certificate_key /path/to/private_key; </code>
     <code>ssl_session_timeout 1d; </code>
     <code>ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions </code>
     <code>ssl_session_tickets off; </code>

     <code># curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam </code>
     <code>ssl_dhparam /path/to/dhparam; </code>

    <code># intermediate configuration </code>
    <code>ssl_protocols TLSv1.2 TLSv1.3; </code>
    <code>ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384; </code>
    <code>ssl_prefer_server_ciphers off; </code>

    <code># HSTS (ngx_http_headers_module is required) (63072000 seconds) </code>
    <code>add_header Strict-Transport-Security "max-age=63072000" always; </code>

    <code># OCSP stapling ssl_stapling on; </code>
    <code>ssl_stapling_verify on; </code>

    <code># verify chain of trust of OCSP response using Root CA and Intermediate certs</code>
    <code>ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates; </code>

    <code># replace with the IP address of your resolver </code>
    <code>resolver 127.0.0.1;</code>
 }Code language: PHP (php)

nginx 서비스 재시작

세팅이 완료되었으면 ginx 서비스를 재시작 명령을 주어 설정이 반영되도록 합니다.

nginx -t   # 혹 설정에 문제가 없는지 점검
service nginx restart   # nginx 서비스를 재시작해 설정을 반영시킴
Code language: PHP (php)

보안 점수 확인

그리고 Qualys SSL Labs으로 이동해서 보안점수가 어는정도 나오는지 테스트해봅니다.

SSL Server Test

제대로 세팅만하면 A+은 그냥 나옵니다.

A+이 나온 SSL Test 결과

4. Let’s Encrypt 인증서 자동 갱신

Let’s Encrypt 무료 SSL 인증서는 3개월단위로 인증서가 발급됩니다. 3개월마다 수동으로 이를 업데이트 시키려면 엄청 신경을 써야하고 바쁘다보면 그냥 지나칠 경우가 많겠지요.

다행히도 Let’s Encrypt에서는 인증서 자동 갱신 방법을 제공하고 있습니다.

우선 자동 실행 스크립트 파일을 만듭니다. 크론 실행이 가장 안정적으로 작동하는 경우는 /bin 폴더에 자동 실행 파일이 있는 경우라서 이 폴더에 자동 실행 스크립트 파일을 만듭니다.

cd /bin    
nano letsencrypt.shCode language: PHP (php)

여기에 아래와 같은 내용을 추가합니다.

!/bin/sh
/etc/init.d/nginx stop
/usr/local/bin/certbot renew> /var/log/letsencrypt/le-renew.log
fuser -k 80/tcp
/etc/init.d/nginx startCode language: PHP (php)

이 자동 스크립트 파일에 권한을 부여합니다.

chmod +x letsencrypt.shCode language: PHP (php)

이어 크론탭을 열어 편집 상태로 만듭니다.

ceontab eCode language: PHP (php)

아래처럼 일정 시간마다 이를 시행하라고 명령을 줍니다.

30 4 * * 0 letsencrypt.shCode language: PHP (php)

저장하고 나와서는 크론을 다시 실행 시킵니다.

service cron start Code language: PHP (php)

자동 갱신 모의 테스트

Let’s Encrypt 인증서는 자동 갱신이 제대로 작동하는지 모의 테스트 할 수 있는 기능을 제공하는데요. 바로 –dry-run 옵션을 사용할 수 있습니다.

sudo certbot renew --dry-run Code language: PHP (php)

그러면 다음과 같은 메세지를 출력합니다.

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 and private keys obtained by Certbot so
 making regular backups of this folder is ideal. 
Code language: PHP (php)

5. SSL 사용을 위한 워드프레스 설정하기

워드프레스에서는 별로 할것은 없습니다.
워드프레스 어드민의 설정 – 일반으로 가서 워드프레스 주소와 사이트주소에 S를 붙여줍니다.

워드프레스와 사이트 주소에 S를 붙임

SSL 설정 후 속도 개선하기

SSL을 설정하고 인터넷을 실행하면 속도가 떨어졌다고 느낄 수 있습니다.

이를 해결하는 방법은 OCSP Stapling을 적용하는 방법이라고 합니다.

ssl_dhparam /폴더/경로/아까.생성한.dhparam;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /폴더/경로/2~3번.인증서.붙인거.파일명;
resolver 8.8.8.8 8.8.4.4;
Code language: PHP (php)

resolver는 내부적으로 인증서 발급업체와의 통신을 위해 사용하는 네임서버라고 하구요. 일반 서버호스팅은 IDC에서 제공하는 네임서버 성능이 좋지 않아서 구글에서 제공하는 네임서버로 셋팅한다고 합니다.

6. 마치며

이상으로 간단히 SSL 적용 방법을 적어 보았습니다.
이 분야에의 문외한이 겁없이 시작해서 많은 시행착오 끝에 SSL를 적용했습니다. 참 어려운 여정이었습니다.

이제 적용하고 보니 이게 최선인가하는 회의가 듭니다. 왜냐면 SSL 적용후 속도가 만족스럽지 못하기 때문이죠.
다들 속도때문에 SSL은 로그인이나 회원 가입등 일부 부분에서만 사용한다고 하네요. 네이버도 일부분만 적용한다고.

우선 가상호스팅을 사용하고 있으므로 보안 차원이라도 SSL을 적용하는게 좋을 것 같고, 속도 문제는 차후 어떻게 개선할지 고민해 봐야겠습니다.

SSL 인증서 관련 참고

최신 Let’s Encrypt SSL 인증서 발급 방법 4가지 정리

Let’s Encrypt SSL 인증서 발급 및 자동 갱신 방법(업데이트)

최신 보안 트렌드를 반영한 Let’s Encrypt 인증서 세팅 방법

웹, 브라우저, 서버에서 SSL 인증서 정보 확인 방법, SSL 인증서 만료일 확인 등

서버 보안 관련

랜섬웨어 대응, 서버 및 워드프레스 필수 보안 설정 15가지

워드프레스 보안 강화 NGINX 설정 방법 8가지

리눅스 서버 보안을 위한 포트 사용 최적화

리눅스 서버 root 사용 중지로 리눅스 서버 보안 강화하기

우분투 서버 보안 자동 업데이트 및 업데이트 메일 통보 방법

워드프레스 보안 진단 WPScan 사용법 및 이메일로 결과 받아보기

DDoS 취약 기능 XMLRPC 사용 중지로 워드프레스 보안 강화하기

워드프레스 보안 강화를 위한 사용자명 변경 방법

워드프레스 멀웨어 경험에서 배운 워드프레스 보안 가이드

가상서버호스팅 서버 보안 설정 방법 – Nginx +Ubuntu의 경우

[워드프레스 Tips]웹서버 보안을 위한 무료 SSL 인증서 비교

사이트 운영을 기존 일반 호스팅(shared hosting)에서 VPS라고 불리우는 가상호스팅으로 옮기고나서 보안에 대해서 신경을 써야함으로 보안을 강화할 방안을 고민하였습니다.

처음에는 CloudFlare를 적용하면 보안도 좋아지고 속도도 좋아진다는 이야기가 있어서 이의 적용을 심각하게 고민했고, 실제로도 CloudFlare를 적용했습니다.

당시 제가 알았던 정보는 free plan으로 CloudFlare를 적용시 하면

  • 트래픽 분산이 가능하다
  • 회선 가속
  • DDOS 방어가 가능

지금 다시 확인해보니 잘못된 정보네요. CloudFlare은 business plan에서만 DDOS 방어를 지원해주고 있습니다.

클라우드플레어-CloudFlare-로고

그런데 CloudFlare를 적용하니 서버단에서 대기시간이 너무 길어집니다. 무려 2초가까이 나오더군요.

그러다 hackYa님이 쓰신 클라우드플레어 (CloudFlare) 를 쓰지 말아야 하는이유라는 글을 읽고 최종적으로 CloudFlare를 접었습니다.

그래서 대안(대안이 되는지는 모르겠습니다만)으로 무료로 발급해주는 SSL 인증서를 기반으로 서버 보안을 강화해 보자는 생각을 했습니다.

한번 이쪽으로 방향을 틀게되니 이것 저것 신경쓸게 너무 많네요.. 자꾸 어려운 세계로 들어가는 것 같아서 마음이 불편하긴 합니다.
일반인이 하기에는 시간이 너무 부족하고 지식도 너무 부족하고 그냥 전문가에 맡기는게 최선일지도 모르겠습니다.

1. 웹보안 관련해 몇가지 개념 정리

이와 시작했으니 웹보안 관련 몇가지 필수 개몀 정리를 해보겠습니다.

자세한 개념잡기는 생활코딩님이 정리한 HTTPS와 SSL 인증서라는 글을 참조하면 많은 도움이 될것 같습니다.

그리고 가진곰님이 Xpress Engine 공홈에 올린 SSL의 정석 (아파치 & nginx) 라는 글이 이 족 분야를 이해하는데 도움이 될 것 같네요.

1.1. HHTP와 HTTPS의 차이

일반적으로 인터넷은 HTTP(Hypertext Transfer Protocol의 약자)로 데이타를 전송해왔습니다. 이는 암호화되지 않은 방식으로 데이타를 전송하므로 메세지를 감청하는것이 매우 쉬워 보안에는 취약합니다. 로그인을 위해 비밀번호를 전송시 쉽게 비밀번호를 가로챌 수 있다는 의미이죠.

그래서 보다 보안을 강화한 방식이 HTTPS입니다. 마지막의 S는 Over Secure Socket Layer의 약자로 보안이 강화된 HTTP라고 이해하면 될 것 같습니다.

nginx-letsencrypt-https-featured

1.2. SSL이란

SSL protocol은 Secure Socket Layer protocol의 약자로 (지금은 사라진 브라우져회사인)Netscape사에서 처음으로 웹서버와 브라우저 사이의 보안을 위해 만들었다고 합니다. .

SSL 작동방식에 대해서 SSL Certificates HOW TO라는 글에서 아래와 같이 정리해 주고 있습니다.

  1. [웹브라우저] SSL로 암호화된 페이지를 요청하게 된다. (일반적으로 https://가 사용된다)
  2. [웹서버] Public Key를 인증서와 함께 전송한다.
  3. [웹브라우저] 인증서가 자신이 신용있다고 판단한 CA(일반적으로 trusted root CA라고 불림)로부터 서명된 것인지 확인한다. (역주:Internet Explorer나 Netscape와 같은 웹브라우저에는 이미 Verisign, Thawte와 같은 널리 알려진 root CA의 인증서가 설치되어 있다) 또한 날짜가 유효한지, 그리고 인증서가 접속하려는 사이트와 관련되어 있는지 확인한다.
  4. [웹브라우저] Public Key를 사용해서 랜덤 대칭 암호화키(Random symmetric encryption key)를 비릇한 URL, http 데이터들을 암호화해서 전송한다.
  5. [웹서버] Private Key를 이용해서 랜덤 대칭 암호화키와 URL, http 데이터를 복호화한다.
  6. [웹서버] 요청받은 URL에 대한 응답을 웹브라우저로부터 받은 랜덤 대칭 암호화키를 이용하여 암호화해서 브라우저로 전송한다.
  7. [웹브라우저] 대칭 키를 이용해서 http 데이터와 html문서를 복호화하고, 화면에 정보를 뿌려준다.

1.3. SSL인증서란

SSL 인증서는 보안이 강화된 HTTPS 프로토콜로 서버와 클라이언트간 통신을 제3자가 보증해주는 전자화된 문서입니다.

위 SSL작동방식에서 설명한 것처럼 클라이언트가 서버에 접속한 직후에 서버는 클라이언트에게 이 인증서 정보를 전달하며 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를 검증 한 후에 자료 전송 등등의 작업을 진행합니다.

이 SSL 인증서을 사용하면 서버와 클라인언트간 통신 내용이 공격자에게 노출되는 것을 막을 수 있고, 클라이언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지를 판단할 수 있으며 공격자에 의해서 서버와 크라인언트간 통신 내용의 악의적인 변경을 방지할 수 있다고 합니다.

2. 웹보안의 강제적 적용과 구글의 정책

위에서 설명한것처럼 웹에서 보안을 위해서는 HTTPS 적용이 기본적으로 필요합니다.

이런 저런 이유로 우리나라는 2012년 8월 18일부터 시행된 정보통신망 이용촉진 및 정보보호 등에 관한 법률에 따라 개인정보호를 위해서 보안서버(SSL)를 구축해야합니다. 개인사이트, 커뮤니티를 포함해 회원가입을 받는 국내 모든 웹사이트가 해당된다는 해석입니다.
(이에 대해서 불필요한 규제라는 많은 불만이 있는 것은 사실입니다.)

제28조(개인정보의 보호조치)
① 정보통신서비스 제공자등이 개인정보를 취급할 때에는 개인정보의 분실·도난·누출·변조 또는 훼손을 방지하기 위하여 대통령령으로 정하는 기준에 따라 다음 각 호의 기술적·관리적 조치를 하여야 한다.

  1. 개인정보를 안전하게 취급하기 위한 내부관리계획의 수립·시행
  2. 개인정보에 대한 불법적인 접근을 차단하기 위한 침입차단시스템 등 접근 통제장치의 설치·운영
  3. 접속기록의 위조·변조 방지를 위한 조치
  4. 개인정보를 안전하게 저장·전송할 수 있는 암호화기술 등을 이용한 보안조치
  5. 백신 소프트웨어의 설치·운영 등 컴퓨터바이러스에 의한 침해 방지조치
  6. 그 밖에 개인정보의 안전성 확보를 위하여 필요한 보호조치

② 정보통신서비스 제공자등은 이용자의 개인정보를 취급하는 자를 최소한으로 제한하여야 한다.

또한 구글에서도 2014년부터 HTTPS를 지원 여부를 사이트의 신뢰할 수 있다는 척도로 판단하고 검색 순위에서 올리겠다고 발표했습니다.

구글 Webmaster Central Blog에 발표된 HTTPS as a ranking signal 을 참조해 보시기 바랍니다.

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이 널리 알려져 있습니다. 아래에서 각 업체별 특징을 간략히 알아보겟습니다.

3.1. Let’s Encrypt (https://letsencrypt.org)

SSL-인증기관-lets-encrypt-2

Let’s Encrypt은 HTTPS의 확산이 늦어지는 것은 SSL인증서에 있다고 보고 무료 인증서 보급을 통해 HTTPS의 확산을 늘리겠다는 취지로 시작된 비영리 프로젝트입니다.

Mozilla, Akamai, Cisco, eff, Identrust등이 스폰서로 참여해서 HTTPS Everywhere를 모토로 100% 무료 SSL 인증서를 발급
해주고 있습니다.

Let’s Encrypt의 정책은 독특합니다. 앞에서 HTTPS의 확산을 위한 비영리단체로 소개했듯이 Let’s Encrypt은 서버운영자들이 인증 관리를 철저히 하지 못한다는 점을 염려(?)해 인증서 설치부터 재발행(갱신)까지 다 책임진다는 자세로 인증고나련 업무를 진행하고 있습니다.

인증기간이 90일로 상대적으로 짧은 것은 보안 상황이 계속 변동되므로 이를 반영해 갱신할 수 있도록 짧게 잡았으며 대신 자동으로 인증서가 연장(재발행)되는 기능을 사용하도록 권장하고 있습니다.

자동으로 연장(재발행)된다면 오히려 안심하고 사용할 수 있는 것이 아닌가 싶습니다.

  • HTTPS Everywhere 를 추구하는 비영리 프로젝트
  • 스폰서 : Mozilla, Akamai, Cisco, eff, Identrust
  • IdenTrust cross-sign됨
  • SSL 인증서 100% 무료화
  • 인증기간 연장 및인증서 재발급 무료
  • 사용편리성 : 콘솔상에서 인증서 발급/갱신/설치/세팅 자동화.
  • 멀티도메인 지원, SAN 기능(여러 도메인을 한 인증서로 묶어주는 기능) 지원

3.2. Wosign (https://buy.wosign.com/free/)

SSL-인증기관-Wosign-2

Wosign은 중국의 인증업체 상당히 공격적인 조건으로 사용자를 확보하고 있는 인증업체입니다.
여기서 발급하는 인증서의 브라우저 호환성은 StartSSL과 같은 수준이라고 합니다. (StartSSL cross-sign)

이곳의 장점은

  • 최초 발급이 무료이고 더우기 Revoke/Reissue가 무료 임 (StarSSL은 상당 비용($25)을 받음, Let’s Encrypt는 무료임)
  • 멀티도메인 지원 및 발급 도메인수가 많다. ( Wosig에서는 한 인증서당 SAN 100개까지 지원할정도로(도메인 + 서브도메인 포함해 100개) 많은 도메인을 등록할 수 있었으나 스팸성 도메인들의 증가로 도메인을 5개까지 무료 지원 + 그 이상은 도메인당 1.99달러 가격으로 이용 가능)
  • 인증기간을 3년까지 선택할 수 있음

Wosign의 단점을 꼽자면

  • 중국 인증업체로 신뢰성이 떨어진다는 점
  • 서비스에의 의구심(뚜렸한 사유없이 인증이 취소되었다는 케이스 등등 사례가 있음)

3.3 StarSSL

SSL-인증기관-SrarSSL-2

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 인증서를 적용하고 자동 연장토록 구성하는 방법에 대해서 알아보도록 하겠습니다.

[워드프레스 속도 개선] NGINX에 구글 페이지스피드(mod_PageSpeed)로 속도 개선 방법

기존 아이비호스팅에서 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)를 설치하는 방법은 주로 아래 내용을 참조하였습니다.

How to Install nginx and google PageSpeed on Ubuntu 16.04 (Xenial Xerus)

Compile Nginx with ngx_pagespeed Module on Ubuntu 16.04

2.1. Nginx 설정 파일 백업 (Back up Nginx Configuration Files)

작업하다보면 무슨 문제가 있을지 모르므로 Nginx 설정 파일을 백업받아 놓습니다.

저는 FTP로 관련 파일을 내려받아 놓았습니다. 백업 받을 파일은 /etc/nginx/nginx.conf과 /etc/nginx/conf.n/default.conf의 파일 2개입니다.

그리고 서버 자체를 백업받아 놓는게 좋을 것 같네요. vultr에서는 Snapshot 기능을 제공하고 있으므로 본격적인 작업에 들어가기 전에 서버 자체를 백업받아 놓을 수 있었습니다.

VULTR-백업가능한-스냅샷Snapshots

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

여기에서는 페이지스피드를 다운받을 폴더를 만들고, 최신 페이지스피드 파일을 다운 받습니다.

github에서 ngx_pagespeed 최신 버젼 확인 하기

또는

PageSpeed에서 ngx_pagespeed 최신 버젼 확인 하기

으로 이동해서 최신 버젼을 확인하고 링크 주소를 받습니다.
그런데 제가 해본 경험으로는 최신 베타버젼은 PSOL libraries를 구할 방법이 없더군요(제가 못 찾을 수 도 있습니다) 따라서 최신 안정 버젼만 가능했습니다.

github에서는 버젼명에 상관없이 가장 최신 안정 버젼의 pagespeed 주소는https://github.com/pagespeed/ngx_pagespeed/archive/latest-stable.zip로 항상 일정합니다.

이 안정 버젼의 주소를 사용해 진행하면 됩니다.

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 부분에 각각 이 파라메터를 추가합니다.

--add-module=~/ngx_pagespeed/ngx_pagespeed-latest-stable\
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/ 디렉토리에 저장됩니다.
이 디렉토리에 가보면 관련 여러가지의 파일이 형성되어 있음을 볼 수 있습니다.

google-pagespeed-module-%ec%84%a4%ec%b9%983

  • 다음으로 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을 적용하는 것과 비적용하는것의 차이가 크진 않았습니다.

배낭을 매고 여행을 떠나요 – 여행을 부르는 여행 광고 11

2

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에 올려 누가 더 많은 호응을 얻어내고 네티즌의 동참을 이끌어내는 이벤트를 통해서 발틱해의 아름다움을 널리 알리려는 캠페인입니다.

이 캠페인은 특이하게 Vimeo 동영상이 주로 돌아다니더군요.

Silja Line: Project Rediscovery from hasan & partners on Vimeo

Silja Line Project Rediscovery from hasan & partners on Vimeo

하나씩 늘리다보니 어찌하나보니 11개가 되었네요…
그냥 제목은 두려구요..

여행, 파라다이스로 가는 비상구 – Ticket.com 광고

0

빡빡한 현실에 질려서 문득 여행을 떠나고 싶지 않나요?
현실에서 도피해서 안주할 파라다이스를 꿈꾸고 있지 않나요?

많은 사람들이 이런 일상의 탈출을 꿈꿉니다. 이런 일상 탕출의 꿈을 파라다이로 가는 티켓을 구매하라고 속삭이는 광고가 있습니다.

2015년에 인도네시아에서 실행된 Ticket.com의 광고가 그것입니다.

인터넷 서칭중에 발견해 간략히 공유해 봅니다.

Creative Director : Lucy Novita Prasmono
Agency : Hakuhodo
Client : Tiket.Com
Location : Indonesia
Date : Nov,2015

이 방의 주인은 서류 뭉치속에서 파묻혀 죽을 것 같은 사우실 직원 쯤 될까요?

문득 푸른 바다에 파라솔이 있는 한적한 파라다이스로 가는 비상 계단이 나타난다면 바로 탈출하지 않을 이유가 있을까요?

인도네시아 광고 Tiket_com-1-1


여기는 전형적인 주부이 공간이네요..

설겆이, 빨래 등 지치 가사일을 뒤로하고
유럽의 베네치아로 떠나는 것은 어떻할까요?

인도네시아 광고 Tiket_com-2-l


여기는 전형적인 컴퓨터 엔지니어의 공간 같습니다.
도대체 컴퓨터가 몇대입니까?

컴퓨터 CPU작동하면 내는 후꾼후꾼한 열기를 피해서 저 시원한 설원으로 떠나자구요.

인도네시아 광고 Tiket_com-3-l

아래는 최근 들어가 본 Ticket.com입니다. 사이트 주소가 자동으로 ticket.se로 리다이렉트되네요..

아마도 벌써 비지니스를 한계를 느끼고 주인이 바뀌었나 봅니다. 이 쪽 비지니스가 터프하긴 하죠..

ticket.com 메인페이지