지난 해 6월 나야나 램섬웨어를 계기로 백업에 많은 신경을 써왔는데요. 그럼에도 불구하고 아직도 많이 부족하다는 생각을 지울 수 없었습니다.
▽ 당시 업계를 충격에 빠뜨린 인터넷 나야나 램섬웨어 감염 경로, 이미지 소스 – 미래부
백업에 신경은 쓴다고 하지만 Vultr에서 제공하는 Snapshot, 부정기적으로 PC로 다운 받는 것과 같은 매뉴얼 작업이라 꼭 필요한 시기에 도움이 된다는 확신이 없었죠..
올 들어와 워드프레스 최적화와 가상서버 운영 방법에 대해서 조금 체계적으로 정리하면서 백업에 대해서도 제대로 체계를 세우고, 자동 백업이 제대로 작동하도록 하고(예전에는 자동 백업을 설정했지만 제대로 작동이 되지는 않았습니다.) 추가 백업을 보완했습니다.
프로그래밍 실력이 달리기 때문에 기존에 알려진 방법 및 고수분들께서 한두마디 조언해주신 것을 토대로 나름 체계적인 백업 계획을 세웠고, 기존에 알았던 방식이 제대로 작동하도록 세밀하게 작동 조건들을 적용했습니다.
그 결과 백업 시스템이 나름 톱니바퀴처럼 착착 작동되어, 이제는 어느 정도 안심할 수 있는 수준이 되었습니다. 아래는 이 백업 시스템(?)에 대해서 간략히 설명해 보도록 하겠습니다.
2. 안심이 되는 가상 서버 백업 시스템 구축
백업시스템이라고까지는 할 수 없을지 모르지만 개인 사이트 운영자 입장에서는 엄청 뿌뜻한 내용으로 감히 시스템이라는 단어를 사용해 봅니다.
아래 플로우 차트는 이번에 구성한 백업 체계도입니다. 데이타베이스의 경우 최대 7번 백업이 되도록 여러 단계에 걸쳐 백업이 진행되도록 했습니다.
▽ 서버 및 워드프레스 백업 시스템 플로우 차트 by Happist
① Vultr에서 제공하는 Auto back up 서비스 : 서비스 플랜 비용의 20% 비용 청구(10$ 플랜이면 2$ 소요)
② Vultr Manual Snapshot : 무료
1일 ~ 2일에 한번 Manual Back up
서버 작업 전 Snapshot back up 진행
③ Crontab 활용 Auto Back-up 및 서버 저장(/backup)
Database : 매시간 Backup
④ Dropbox Uploader + Crontab
Database : 3시간 마다
Data : 12시간마다
Full Back up : 1주일마다
⑤ Dropbox → Google DriveⅠ
Database : 3시간 마다
Data : 12시간마다
⑥ Dropbox → Google DriveⅡ
Database : 3시간 마다
Data : 12시간마다
⑦ PC Manual Back up
부정기적
Full Back up
위에서 소개한 7가지 백업 솔류션에 대해서 간략히 살펴 보도록 하겠습니다.
3. 서버 내에서 백업
위의 백업 시스템은 크게 가상 서버 내에서 이루어지는 백업과 가상 서버 외로 백업하는 둑지 종류로 나누오 질 수 있습니다. 이를 각각 나누어 서버내에서 이루어지는 백업에 대한 설명을 하고 이어서 서버 외로 백업하는 방법에 대해서 설명하겠습니다.
3.1. 서버 업체의 정기 백업 서비스 이용(유료)
웹호스팅업체는 기본적으로 자체 백업을 해줍니다. 그러나 점차 백업은 사용자의 소관이라는 인식이 늘어나면서 웹호스팅이라도 본인 스스로 백업을 챙겨야 하는 시대입니다. 예전 스마일서브를 사용하던 시기에 백업데이타로 전일치로 돌려달라고 했더니 자기는 1주일전치만 보관한다며 백업을 사용자 소관이라고 (냉냉하게)이야기하더군요. 그럴바에는 왜 웹 호스팅을 이용하는지?? 그런 의문을 품었습니다. 차라리 서버를 운영하고 말겠다는 생각을 했습니다.
아무튼 가상서버 운영시에는 전부 사용자의 책임이므로 스스로 백업 전체를 챙겨야 합니다. 이런 가상서버에서도 비록 유료이지만 백업 서비스를 이용하는 방법이 있습니다.
Vultr는 매일 백업 서비스는 플랜 가격의 20%를 받습니다. 5$ 플랜는 1$을. 10$ 플랜이라면 2$을 받습니다.
linode를 보니 스탠다드 플랜의 1GB 백업 공간을 제공하는 서비스의 경우 월 2$, 2GB는 2.5$, 4GB는 5$식으로 비용을 받고 있습니다.
3.2. Snapshot 서비스 이용(Vultr 무료)
스냅샷(Snapshot) 백업이란 가상 서버나 리얼 서버의 설치 및 작동 상태 그대로 마치 사진을 찍어 놓듯이 그대로 저장하는 것을 말합니다. 이렇게 찍어 둔 또는 떠놓은 스냅샷(Snapshot) 백업은 필요한 경우 스냅샷 저장 그 순 간 그대로 되돌릴 수 있으므로 문제가 발생 시 간편하게 스냅샷(Snapshot) 저잘 순가능로 되돌아 갈 수 있습니다.
가상 서버 업체 대부분 스냅샷(Snapshot) 기능을 제공하고 있는데요. 대부분 유료로 서비스하지만 Vultr는 11개까지 스냅샷(Snapshot) 백업을 무료로 제공하고 있어 유용합니다. 이 Snapshot을 자동으로 만들 수 있으면 금상첨화이지만 유감스럽게 그런 기능은 없습니다. 아마 자동 스냅샷(Snapshot) 기능이 있다면 업체가 제공하는 백업 서비스가 무력화 될 것 같습니다. 아쉽지만 주요 작업 전에 수작업으로 Snapshot을 만들고 작업을 시작하면 비전문가에게는 큰 도움이 됩니다. 서버 작업은 민감한 부분을 건들일 가능성이 높습니다. 그러다가 가끔 시스템이 죽는 경우가 생기고 전혀 원인을 알 수 없는 경우가 많습니다. 이럴때는 바로 Snapshot으로 복구하면 90%이상은 해결이 됩니다.
제가 vultr을 계속 사용하는 이유중의 하나가 바로 이 Snapshot을 무료로 사용할 수 있어서 입니다. 이게 없었다면 초심자로써 서버 운영이 엄청 힘들었고 과감하게 이런 저런 시도를 해볼 수 없었고 이렇게 성장할 수 도 없었을 것입니다.
▽ Vultr에서 제공하는 스냅샷(Snapshot) 백업 List
3. 3. 서버 내 데이타베이스 및 데이타의 정기 백업
서버 내에 백업데이타를 두는 것이 도움이 될 확율이 반반쯤 되는 것 같습니다. 많은 경우 여러가지 이유로 시스템에 접속이 안되는 경우도 생기는데 이때 서버 안의 내용은 전혀 도움이 안됩니다. 접근할 수 없거든요.
그렇지만 그외 nginx는 멀쩡하게 작동하는데 사이트 자체가 작동하지 않는 경우 등등은 도움이 되는데요. 이때는 가능하면 가장 최근 작업분까지가 포함되 있으면 거의 완벽한 복구가 될 수 있습니다. 그렇기에 서버내에서는 트래픽, 용량 걱정없이 최대한 짧은 기간동안 백업 사이클이 돌 수 있도록 만드는게 필요합니다.
제가 사용하는 Vultr 10# 플랜은 SSD 용량을 40G를 주는데요. 30%도 사용하지 못하고 있습니다. 이렇게 남아 도는 SSD 용량을 백업 데이타 공간으로 활용하는 것은 지극히 타당하겠죠.
데이타베이스가 계속 데이타를 쌓아가기 때문에 백업 디렉토리를 만들고 여기에 매시간 데이타베이스 전체를 백업토록 했습니다.
아래는 서버 내에서 1시간 단위로 백업이 이루어지도록 backup 디렉토리를 만들고 매시간 백업이 되도록 크론탭 설정내용입니다.
서버내에서 백업을 받아 놓는 것도 필요하지만 백업본을 외부에 정기적으로 백업하는게 필요합니다. 서버 자체가 날라가는 경우를 대비해야 하기 때문이죠.
그리고 종종 서버 자체 접속이 안되는 경우도 생깁니다. (어디 설정을 잘못 만졌기 때문이겠지만) 어느 순간 SFTP나 SSH 접속이 불가한 경우 생깁니다. 전문가라면 다른 바법을 찾을 수 있겠지만 이 경우는 Snapshot 또는 업체 백업본으로 되 살리던지 아니면 서버 세팅을 새로하는 불쌍사가 생기기도 하죠. 저는 이런 경우를 두번인가 만났습니다. Vultr에서도 SSH연결등은 자기들도 할 수 없는 거라해서 눈물을 머금고 조금 오래전에 떠논 Snapshot으로 복구하고 한적이 한번 있고, 한번은 Snapshot도 안먹혀서 서버를 새로 설치한 경우도 있습니다.
흔하지는 않지만 외부 백업이 필요한 경우가 있으니 보험 차원에서 백업 시스템을 갖추는 게 필요합니다. 서버 외부에 백업 받는 방법은 많이 있습니다. 외부 백업 서비스 업체도 있고, 워드프레스 사용자라면 백업 플러그인들의 도움을 받을 수 있습니다. 이들 중에는 클라우드로 올려 저장해주는 기능도 있으며 (비록 유료이지만) Dropbox, 구글 클라우드 등 여러 군데로 동시에 백업을 해주는 플러그인도 있습니다.
예를 들어 현재 100만명 이상이 설치했다는 UpdraftPlus WordPress Backup Plugin이 대표적인 것이죠. 이플러그인의 무료 버젼은 구를 드라이브 등 클라우드 한 군데에 저장할 수 있지만 유료인 프리미엄 버젼은 여러 클라우드에 동시에 백업을 받을 수 있고 백업 시간도 매우 정교하게 설정할 수 있습니다.
여기에서는 별도의 비용을 들이지 않고 자동으로 정기적으로 백업을 할 수 있는 드롭박스(Dropbox)의 Uploader 기능을 활용해 서버에서 Dropbox로 백업을 받고, 이를 다시 구글 드라이브로 추가 백업을 하는 방법을 설명하겠습니다.
아래는 위 전체 백업 시스템에소도 소개했지만 서버 외부에서 백업이 이루어지는 Flow chart입니다. 서버 – Dropbox – 구글 드라이브 – 사용자 PC로 이어지는 백업 흐름을 정리한 것입니다.
4.1. 서버 외부로 정기 백업 : 드롭박스(Dropbox)로 백업 받는 방법
먼저 서버에서 Dropbox로 백업하는 방법입니다. 이는 Dropbox에서 제공하는 Uploader 기능을 활용하는 것인데요. 클라우드 서비스중에서도 Dropbox는 서버와의 연동 등 서버 관련 기능들을 잘 구현해 놓았습니다.
4.1.1. Dropbox-Uploader 설치
서버에서 드롭박스로 파일을 올려주는 프로그램인 Dropbox-Uploader를 설치 합니다.
cd /usr/bin
git clone https://github.com/andreafabrizi/Dropbox-Uploader/Code language:PHP(php)
4.1.2. Dropbox-Uploader 설정
이 다음에는 스크립트에 실행 권한을 부여하고 실행합니다. 처음 실행하면 여러분의 드롭박스 계정에 Dropbox-Uploader를 연결하는 작업을 실행하게 됩니다.
cd /usr/bin/Dropbox-Uploader
chmod +x dropbox_uploader.sh
./dropbox_uploader.sh
Code language:PHP(php)
여기에서 더 나아가 Dropbox에 백업받은 파일을 구글 드라이브로 복사해서 한층 더 안전한 백업 시스템을 만들어보기로 했습니다.
워드프레스 사용자는 강력한 워드프레스 백업 플러그인들이 도움이 될 수 있습니다. 이들 중에는 클라우드로 올려 저장해주는 기능도 있으며 (비록 유료이지만) Dropbox, 구글 클라우드 등 여러 군데로 동시에 백업을 해주는 플러그인도 있습니다.
예를 들어 현재 100만명 이상이 설치했다는 UpdraftPlus WordPress Backup Plugin이 대표적인 것이죠. 이플러그인의 무료 버젼은 구를 드라이브 등 클라우드 한 군데에 저장할 수 있지만 유료인 프리미엄 버젼은 여러 클라우드에 동시에 백업을 받을 수 있고 백업 시간도 매우 정교하게 설정할 수 있습니다.
저는 플러그인은 속도에 방해가 된다는 입장이라 가능하면 플러그인을 사용하지 않고, 또한 추가 비용없이 강력한 백업 시스템을 만들고 싶었기 때문에 Dropbox에서 15GB 용량을 주는 구글 드라이브(물론 다른 용량이 큰 클라우드가 있다면 이를 이용해도 됩니다.)로 파일을 보내는 방법을 고민했습니다.
간편하게 Dropbox에서 자동으로 구글 드라이브로 파일을 보내는 방법은 크게 두가지 정도가 있습니다.
첫째는 IFTTT 기능을 이용하는 방법이고
둘째는 클라우드간 파일 전송 서비스를 이용하는 것입니다. 여기에는 zapier이나 multCloud같은 업체가 있습니다.
2. IFTTT 기능 이용 방법
IFTTT는 “If This Then That”의 약자로 인터넷과 컴퓨터를 이용하는 다양한 서비스와 앱 기능들을 연결해 주는 서비스입니다.
IFTTT에 접속하면 정말 다양한 디바이스 기능들을 연결할 수 있는데요. 요즘에는 아마존 알렉사나 구글 홈 스피커를 활용한 다양한 서비스가 많이 개발되어 소개되고 있습니다.
당연하게도 Dropbox에서 구글 드라이브로 파일 전송 기능도 존재하는데요. 원리는 Dropbox에 새로운 파일이 생성되면 이 새로운 파일을 구글드라이브로 보내는 것이죠.
2.1. IFTTT에서 Dropbox이용 서비스
IFTTT에서는 이런 서비스를 Applets라고 불리우는데요. 여기에는 생각할 수 있는 거의 모든 종류의 서비스가 가능합니다. IFTTT Dropbox로 검색한 결과인데요. 아주 다양한 서비스가 존재하고 있습니다.
2.2. Dropbox에서 구글 드라이브로 파일 송부 세팅
여기서 “Automatically sync new files added to Dropbox to your Google Drive”라는 서비스를 선택하고 Turn on을 누르고 Dropbox 계정과 구글 드라이브 계정을 선택해 줍니다.
계정 등록과 세팅이 끝나면 아래와 같은 화면이 나오는데요. 이러면 모든 준비가 끝난 것입니다. 아주 간단하고 짧은 시간에 세탕이 완료됩니다.
2.3. IFTTT 서비스의 한계
이렇게 간단하게 Dropbox에서 구글 드라이브로 파일 자동으로 파일을 보내는 것을 세팅하고 실행시킬 수 있어 아주 편리한 서비스이지만 한계가 있습니다.
바로 보낼 수 있는 파일 크기가 30MB로 한정되어 있다는 점입니다.
데이타베이스 파일들은 압축해서 10% 수준으로 줄어 들기에 충분히 30MB이하로 유지되지만
그 동안 Vultr 가상 서버 호스팅을 이용하면서 주로 사용했던 명령어를 모아 보았습니다.
서버 운영 시 cPanel을 이용하지 않는 경우 대부분의 작업을 터미널에서 작업해야 하는데요. 이 경우 명령어를 알고 있지 않는다면 할 수 있는 것이 거의 없습니다.
그래서 주로 사용하는 명령어를 정리해서 개인적으로도 활용하고 혹 필요하신 분께 도움이 되길 바랍니다.
원래는 가상 서버 입문 방법에서 넣으려고 했던 내용인데 너무 길어져서 별도 포스팅으로 작성했습니다.
내용을 계속해서 보완할 생각입니다.
데이타베이스 백업은 phpMyAdmin으로 접속해 데이타베이스 보내기 기능으로도 할 수 있지만 phpMyAdmin은 보안을 고려 시 좋은 선택이 아니라는 지적이 많으므로 터미널에서 SQL 명령어를 사용하도록 합니다.
DB 백업 및 복구
백업 명령은 mysqldump을 사용하고 복구는 mysql 명령을 사용합니다.
백업 명령에서 InnoDB라면 —opt —single-transaction 옵션 추가하도록 추천되고 있습니다. 업데이트 되고 있는 상태의 데이타베이스가 백업되는 것을 막고, 복원 시 안정성을 높일 수 있습니다.
사이트를 운영하다보면 백업 후 다시 복구할 시 DB 전체를 통째로 바꿔치기 하는 경우도 있지만 백업받은 DB에서 일부 테이블만 복사해 오는 경우가 있습니다. 이 경우는 Inset Into Select From을 사용합니다.
즉
INSERT INTO [복사 받을 DB이름].[DB 접두어].[테이블 이름] SELECT * FROM [원본 DB 이름].[DB 접두어]_[테이블 이름] ;
INSERT INTO wp.wp_postmeta SELECT * FROM wpbackup.wp_postmeta ;
INSERT INTO wp.wp_posts SELECT * FROM wpbackup.wp_posts;
INSERT INTO wp.wp_termmeta SELECT * FROM wpbackup.wp_termmeta ;
INSERT INTO wp.wp_terms SELECT * FROM wpbackup.wp_terms ;
INSERT INTO wp.wp_term_relationships SELECT * FROM wpbackup.wp_term_relationships;
INSERT INTO wp.wp_term_taxonomy SELECT * FROM wpbackup.wp_term_taxonomy;
INSERT INTO wp.wp_analyticbridge_metrics SELECT * FROM wpbackup.wp_analyticbridge_metrics;
INSERT INTO wp.wp_analyticbridge_pages SELECT * FROM wpbackup.wp_analyticbridge_pages;
INSERT INTO wp.wp_et_social_stats SELECT * FROM wpbackup.wp_et_social_stats;
INSERT INTO wp.wp_commentmeta SELECT * FROM wpbackup.wp_commentmeta;
INSERT INTO wp.wp_comments SELECT * FROM wpbackup.wp_comments;
INSERT INTO wp.wp_links SELECT * FROM wpbackup.wp_links;
2. 폴더 및 파일 관리 명령
리눅스에서 파일 이름은 256자까지 사용 가능, 확장자 의미 없으며 소문자와 대문자를 구분합니다. 즉 대, 소문자는 각기 다른 파일이 됩니다.
최근 나이키가 “미친 존재감 Just Do It”캠페인을 시작했네요. 이 캠페인을 런칭하면서 캠페인의 메세지를 담은 곡 ‘런 잇(RUN IT)’과 영상을 발표했는데요.
그냥 가볍게 이 광고를 보면서 느낀 생각 몇가지를 정리해 보았습니다. 논리적인 글을 아니니 감안해서
1. 나이키가 설명하는 #미친 존재감 #Just Do It 캠페인
나이키는 보도 자료를 통해서 이 캠페인에 대해서 아래와 같이 설명하고 있습니다.
나이키 코리아는 15일, 자신을 규정하는 모든 한계와 관습을 극복하고 끊임없는 도전을 통해 놀라운 존재감을 드러내는 모든 이들을 응원하는 미친 존재감 JUST DO IT 캠페인을 공식 런칭했다. 이번 캠페인의 메시지를 담은 노래 “런 잇(RUN IT)”과 그 영상을 공개했다. 대하민국 축구 국가 대표 팀의 전 주장 박지성도 영상에 깜짝 등장해 ‘미친 존재감’을 드러낸다.
나이키는 이번 캠페인을 통해 전통적인 관습에 얽매이지 않고 자신의 목표를 성취하기 위해 본인 스스로의 길을 개척해 나아가는 모든 사람들을 존중하며 이를 기념한다. 특히 이번 미친 존재감 JUST DO IT 캠페인은 새로운 시작을 앞둔 모든 새내기들이 스포츠를 통해 에너지를 얻고, 자신의 미래를 스스로 개척할 수 있도록 독려한다.
본격적인 캠페인의 시작과 함께 공개된 ‘런 잇(RUN IT)’ 영상에는, 지칠 줄 모르는 도전 정신과 남다른 열정으로 최고의 위치에 오른 쇼트트랙 선수 심석희, 국내 최초 혼혈 모델 한현민, 한국 힙합씬의 독보적인 여성 래퍼 제시, 아이스하키 국가 대표팀, 탈북 복서 세계 챔피언 최현미 등이 출연해 그들의 미친 존재감을 드러낸다.
2.1. 리얼리즘이 생각나는 광고
위 유튜브 영상에서 소개하는 미친 존재감 캠페인을 소개한 ‘런 잇(RUN IT)’과 영상은 잘 만들었는지는 잘 모르겠습니다. 다만 미친 존재감을 만들어버린 사람들을 감각적으로 보여주면서도 있는 현실 그대로를 표현하려고 했다는 느낌을 받았습니다.
영상의 장면들도 우리가 주변에서 흔히 볼 수 있는 풍경들입니다. 나온 사람들도 조각같은 외모를 가진 비현실적인 인형들이 아니라 주변에서 흔히 볼 수 있는 그런 사람들 그렇지만 한 우물을 파서 어떤 경지에 오른 사람들
미친 존재감이 이야기하고 싶은 것은 브라운관 너머에는 존재하는 범접할 수 없는 영웅을 이야기하는 것이 아니라 우리 주변의 사람들의 이야기라는 것을 끊임없이 강조하는 듯 싶었습나다. 이제 사람들은 환상같은 것에 속지 않기 때문에 실제를 보여주고 그 속에서 나이키가 전하는 메세지를 전달하는 게 아닐까요?
제목에 리얼리즘이라고 쓴 것처럼 말입니다.
예전에 포스팅한 적이 있는데요. 요즘 밀레니얼들은 열망이나 이상을 이야기하는 것을 별로 좋아하지 않는다고 합니다. 그래서 최근 광고 트렌드는 현실 그대로를 보여주는 리얼리즘이 대세라고 하죠.
2017년 PC 시장은 어떻했을까요? 예전 트렌드에서 벗어나지 못하고 침체를 거듭했을까요? 그러면 2018년은 어찌될까요?
2018년 1월 발표된 2017년 정보는 조사업체별로 조금씩 상이하지만 전체 트렌드를 조망히는 문제는 없어 보입니다.
Executive Summary
2017년 PC 출하량은 전면 비 소폭 하락(IDC 기준 -0.2%, 가트너 -3%)했으나 감소세는 진정되고 있는 것으로 판명
2018년 PC 출하량은 윈도우즈 10, 고성능 CPU 가격의 하락 등등으로 수요 확대 가능성
2017년 HP가 확실하게 레노버를 제치고 1위에 등극함
2017년은 상위 3개사인 HP,레노버, Dell 중 HP 및 Dell의 점유율이 많이 올라감. 반면 레노버는 소폭 하락
2017년 애플이 ASUS, Acer등을 제치고 4위로 올라섬
1. 2017년 PC 출하량 소폭 하락했으나 향후 성장 가능성을 남겨..
2018년 1월 10일 가트너는 2017년 출하량을 2.63억대로 전년 비 -3%% 하락했다고 발표했습니다. 가트너는 이 발표에서 PC가 4분기에 크게 각광을 받지 못했다며, 이는 PC가 더 이상 미국 Holiday 시즌에 인기있는 아이템은 아니라는 것을 반증한다고 적고 있습니다. 그렇지만 PC가 가정에서 사라지는 것이 아니라 보다 특화됙 전문화된 기기로 남을 것이고 이런 관점에서 PC 산업의 미래가 있다고 보았습습니다.
그 다음 날인 11일 IDC는 2017년 PC 출하량을 2.595억대로 전년 비 -0.2% 하락해 예전 추세에 비해서 매우 양호한 수준이라는 평가를 내렸습니다. 또한 신흥 시장에서 PC 수요는 예상보다 강력했다고 평가하고, 크롬북과 같은 새로운 카테고리가 수요를 견인할 가능성이 있다고 보았습니다.
사실 2017년 AMD 라이젠 출시등으로 PC 업그레이드가 활발해지면서 성장세로 전환이 예측되었으나 SSD나 RAM같은 부품 가격이 급격히 상승하면서 수요 확대가 제한 되었다는 평가입니다.
여전히 수요가 살아있기 때문에 2018년 수요가 성장할 것이라는 가트너의 예상은 어느 정도 맞지 않을까 싶습니다.
PC의 수요는 다음과 같은 요인이 있을 것으로 개인적으로 추정합니다.
첫째, 윈도우즈 10의 확산과 함께 PC를 업그레이드 하 기회가 왔는데 오랬동안 이러한 업그레이드가 지연되어 왔으며, 업무용 PC의 업그레이드 할 시기가 도래한지 오래라는 평가가 있습니다.
둘째, 2017년 연말부터 부각된 인텔 CPU를 중심으로한 멜트다운, 스펙터와 같은 보안 이슈는 구 PC를 문제가 해결된 최신 PC로 업그레이드를 가속화할 가능성이 매우 높습니다.
셋째, 2017년 AMD 라인젠 출시부터 고사양 CPU의 대중화가 이루어지고 이에 대항해 인텔도 CPU 가격을 대폭 조정하면서 큰 비용을 들이지 않고 고사양 PC를 구입할 수 있는 기회가 왔기 때문에 이 또한 PC 업그레이드를 촉발할 것으로 보입니다.
▽ PC 츨하량 추이 (00년 ~ ‘17년 실측치, ‘18년 ~ 19년 예측치), 단위 : 백만대 가트너 자료 기반 Graph by Happist
분기별 PC 출하량 데이타를 보면 2017년 4분기는 모처런 전년 비 출하량이 증가하는 모습을 보여주고 있습니다. 2018년 수요가 긍정적일 수 있다는 신호가 아닐까 싶습니다.
▽ 분기별 PC 출하량 추이(단위 : 백만대) IDC 발표 자료를 기반 Graph by Happist
2. 2017년 HP가 확실한 우위를 점하다. – 연도별 시장점율 추이
PC 시장 성장율에 대해서 가트너나 IDC 견해가 조금 다르지만 2017년 HP가 시장을 장악했다는 점에서는 양 조사기관이 모두 일치된 견해를 보이고 있 습니다.
Vultr에서 가상서버 호스팅을 운영하고 있고 이에 대한 경험을 주제로 포스팅을 몇번 올렸는데요. 이를 보고 가상 서버 호스팅 운영에 대해서 문의하는 분들이 있었습니다.
최근 웹서비스 환경이 바뀌면서 가상서버 호스팅에 대한 관심이 높아졌습니다.
심지어 최근 암호화폐 광풍이 몰려오면서 Vultr같은 가상서버 호스팅을 암호 화폐 증식(증식이라는 단어를 사용한 이유는 채굴에는 어마어마한 전기료와 시스템이 소요되기에 가상서버에서는 거의 불가능하고, 일부 화폐의 경우 증식하는데 가상 서버를 사용한다고 해서 이 단어를 골랐습니다.)에 활용되는 사례조차 나오는 것 같습니다.
“가상 서버를 운영하고픈 勇者에게 전하는 가상 서버 운영 입문 노하우 – Vultr 가상서버호스팅(VPS)를 중심으로”라는 제목을 단 이유는 일반 웹호스팅을 이용하다가 가상서버 호스팅(VPS)로 옮기려는 분들에게 도움이 되도록 보다 쉽고 간결하게 가상서버 호스팅에서 워드프레스 등 사이트를 운영하는 방법에 대해 이야기 해보자는 목적이 있습니다.
그래서 그 동안 Vultr에서 가상서버 호스팅을 했던 경험을 토대로 가상 서버로 (워드프레스) 사이트 운영 노하우를 정리, 공유해 보고자 합니다.
[참고] 시간이 지나 내용이 오래된 것 같아서 일부 내용을 계속 업데이트 하고 있습니다. 내용 시기가 서로 다른 것은 업데이트 과정이니 이해해 주세요.
1. 가상 서버 호스팅이란?
여기에서는 가상 서버 호스팅이 다른 웹호스팅 또는 단독 호스팅과 어떻게 다르고 그 자체의 의미를 짚어보고, 관련 업계에 대해 정말 간단하게 살펴 보겠습니다.
1.1. 가상 서버 호스팅 정의
사이트를 운영하려면 사이트를 구축할 장소가 필요한데요. 이 구축 장소에는 wordpress.com과 같이 특정 서비스에 가입하는 방법, 호스팅만 전문으로 해주는 웹호스팅 이용 방법(Shared hosting), 가상 서버 호스팅(VPS, Virtual Private Server), 단독 서버 방식(Dedicated Server)이 있습니다.
이중 서버 호스팅(VPS)은 물리적인 서버를 가상화하여 각각의 가상 서버를 사용자에게 제공하는 방식으로, 물리 서버 한대에 여러 가상 서버를 입주시키게 됩니다.
여기서 물리 서버 한대에 얼마나 많은 가상 서버를 입주시키느냐가 안정적인 성능의 관건이죠.
업체 이익을 생각한다면 한개의 서버당 최대한 많은 가상서버를 입주시키는게 좋겠죠.
그렇지만 입주한 사용자 사이트 성능과 관계가 되므로 성능에 영향를 주지 않으면서도 가장 많은 가상 서버를 입주시킬 수 있는 역량이 중요합니다.
▽ 가상 서버 개념을 아주 거칠게 표현하고 있는 사진, 이미지는 고대디에서 빌려 왔다.
1.2. 가상 서버 호스팅 업체는?
이러한 가상 서버를 제공하는 업체에는 어디가 있을까요?
인터넷이나 IT서비스가 클라우드 방식으로 이동하고 관련 기술이 발전하면서 이에 대한 수요가 증대하면서 관련 업체가 급속히 늘어나고 있습니다.
저눈 2016년 웹호스팅을 운영하다가 가상 서버 호스팅으로 갈아탔는데요. 이 당시 국내는 쓸만한 가상 서버호스팅이 많지는 않았습니다.
성능과 가격 경쟁력이 우수한 업체는 주로 외국에 있습니다. 한국 업체는 상대적으로 비쌌고 자율권도 상당히 부족했었습니다.
가상서버호스팅으로 갈아 타기 위해 엄청난 검색을 통해 내린 결론은 Linode, Vultr, DigitalOcean, 코노하가 쓸만하다는 것이었습니다.
특히 도쿄에 서버가 위치한 Linode와 Vultr가 우수하며 코노하는 매력적이긴 하지만 일정 용량이 넘으면 트래픽 제한을 거는 등 불안 요소가 있어 꺼려진다는 평이 있었습니다.
먼저 Vultr 가상 서버 호스팅을 이용하기 위해서는 가입을 합니다. 가입 시 포로모션 쿠폰을 적용하면 일정 금액을 절약할 수 있는데요.
예전엔 프로모션을 굉장히 많아 20$, 30$ 쿠폰이 많았지만 최근에는 공식적인 10$ 쿠폰조차 없어졌습니다. 다만 기존 사용자의 추천 쿠폰으로 가입하는 경우 10$ 프로모션은 여전히 살아 있습니다.
참고로 프로모션 쿠폰이 필요하면 아래 프로모션 코드 링크를 통해 Vultr에서 서버 구축 후 1달 이상 사용 및 $25이상 결제 時 추가 100$을 주는 프로모션을 진행 中입니다.
아래 이미지를 클릭해 등록할 수 있습니다. 광고라 죄송!!
3. 서버 설치
Vultr에 가입했으면 이제 본격적으로 서버 설치 및 세팅을 해 봅니다. Vultr에서는 개개의 서버를 Instance라고 부릅니다. 서버 세팅, Vultr에서 이야기하는 Deploy New Instance 화면의 Vultr Cloud Compute(VC2)화면에서 세팅을 시작할 수 있습니다.
아래는 간단히 서버 세팅 과정을 보여주고 있습니다.
3.0. 서버 종류 선택
예전 Vultr 서버 종류는 그리 복잡하지는 않았지만 지금은 High Frequency가 추가되어 Cloud Compute, High Frequency, Bere Metal, Dedicated Cloud의 4가지 종류를 선택할 수 있습니다.
우리가 가장 일반적으로 저렴한 버전은 Cloud Compute이구요.
이보다 더 나은 CPU와 NVme라는 고성는 디스크를 사용해 성능을 높인 High Frequency를 선택할 수 있습니다. 다면 가격이 20% 더 비쌉니다.
독립형 서버를 사용하고 싶다면 Dedicated Cloud를 선택할 수 있지만 지원 지역이 많지는 않습니다. 당근 가격도 비싸겠죠.
3.1. 서버 위치 선택
서버 위치는 2020년 12월 6일 현재 18년 1월 현재 글로벌로 17군데가 있는데요. 아시아권에는 서울, 일본 도쿄 그리고 싱가폴에 있습니다.
주요 비즈니스 영역이 한국이라면 당연 서울을 선택하면 될 것 같습니다. 그렇지만 한국과 북미를 비슷한 비중으로 운영한다면 LA 지역도 좋을 것 같습니다.
▽ 서버 위치를 설정 장면
3.2. 서버 운영 체제
이번에는 서버 운영 체제를 선택합니다. 서버를 선택, 설치하는 데에는 여러가지 방법이 있는데요. 아래를 보시면 알겠지만 굉장히 다양한 방법을 제공하고 있습니다.
3.2.1. Vultr에서 제공하는 서버 운영 체제 설치 방법
첫째, 일반 프로그램 설치하듯이 자신에게 맞는 운영 체제를 선택해 설치하고, 이어서 필요한 프로그램을 설치하는 방식
둘째, Application이라고 해서 운영체제 + 제반 프로그램을 일괄 설치하는 방법
셋째, 다른 곳에서 만들어 놓은 ISO 파일을 업로드해서 그대로 사용하는 방법
넷째, Vultr에서 제공하는 ISO 파일을 그대로 사용하는 방법
다섯째, 이미 Vultr을 이용하는 상태라면 유료로 백업 서비스를 받고 있다면 이 백업 파일로부터 서버를 생성하는 방법
여섯째, 이미 Vultr을 이용하는 상태라면 기존에 만들어 놓은 Snapshot으로 그대로 서버를 떠주는 방법
Application 설치 방식은 운영 체제과 관련 프로그램을 한꺼번에 설치해주므로 편하긴 하지만 원하는 프로그램을 선택할 수 없고 최신 프로그램은 지원하지 않은 경우가 많습니다.
예를 들어 20년 12월 현재 wordpress 설치 Application은 우분투 18.04를 설치하도록 되어 있습니다. 센토스를 선택하거나 우분투(Ubuntu) 최신 버젼, 20.04 또는 20.10를 선택하고 싶다면 사용할 수 없지요.
전문가라면 다른 곳에서 만들어 놓은(제대로 잘 세팅된) ISO를 업로드 하는 것도 괜찮을 겁니다. 그렇지만 초심자에게는 너무 먼 이야기이지요.
Vuktr에서 제공하는 ISO는 일반 프로그램 설치와 거의 같은 방식입니다.
따라서 저는 일반 프로그램처럼 설치하는 첫번째 방식을 사용했습니다.
3.2.2. 32비트? 64비트?
윈도우즈도 32비트 64비트가 있듯이 리눅스계열도 32비트와 64비트로 나누어져 있습니다. 그래서 64비트를 설치할 것 인지, 32비트를 설치할 것 인지를 선택해야 합니다.
일반적으로 RAM이 512MB, 765MB 적을 경우 32비트를 설치하는 게 좋다고 하네요. 32비트가 최소 메모리를 사용하기 때문이라고 합니다.
그리고 최소 1GB정도 되어야 64비트가 아주 원활합니다. 실제로 워드프레스 등 운영 시 최소 메모리를 1GB로 권장하고 있습니다.
3.2.3. 어떤 운영 체제, 어떤 버전을 선택할 것인가?
운영체제를 무엇으로 할 것 인지도 고민인데요. 센토스나 우분투등이 일반적으로 많이 사용되므로 둘 중 하나를 고르면 됩니다. 저는 최근 뜨고 있다는 우분투를 선택했습니다.
우분투 버전을 선택해야하는데, 우분투는 16.04, 18.04 그리고 20.04 버젼이 출시 후 5년동안 지원하는 LTS 버젼이므로 가능하면 이를 선택하라고 조언하고 있습니다. 이외에 가장 최근에 나온 20.10을 사용해 볼 수 있습니다.
버젼별로 새로운 기능이 추가되기는 했지만 성능에 큰 영향을 미치지는 않은 것 같습니다. 최신이면서 오랬동안 지원되는 LTS 버젼을 사용하면 될 듯 합니다.
이 글을 업데이튼 하는 20년 12월 현재 저는 20.04 버전을 적용하고 하고 있습니다. Vultr는 항상 최신 버전을 설치할 수 있도록 빠르게 대응하고 있습니다. 국내 서버 업체들을 보면 대부분 최신 버전 지원 시기는 출시 한참 시간이 지낭 후 지원하는 것 같습니다.
최신 버전에 민감하고 이를 빨리 테스트해보고 싶다면 그런 의미에서 Vultr도 좋은 대안이 될 듯 하네요.
서버 운영체제로 우분투 버전 선택 모습
서버 운영체제를 어플리케이션과 함께 선택
▽ 서버 타입 선정 화면 – Application을 중심으로 선택, 설치 할 수 있다. ▽ 서버 타입 선정 화면 – Vultr에서 제공하는 ISO List에서 선택, 설치할 수 있다.
3.3. 플랜 결정 – 서버 크기
이 단계에서는 가장 중요한 가격대를 선택해야 합니다. 국내의 많은 웹호스팅과 마찬가지로 상위 플랜으로 업그레이드는 가능하지만, 다운그레이드는 허용하지 않기 때문에 처음에는 당장 사용할 수준 정도로 시작하고 점차 업그레이들 하면 좋습니다.
나중에 다시 정리하겠지만 상위 플랜으로 업그레이드는 서버를 유지한 채 버튼 하나만 눌러서 몇분 내에 끝납니다. 아주 쉽고 간단합니다.
저는 데이타베이스 크기가 300MB 정도이고 하루 방문객이 5,000명이 안되기 때문에 처음에 5$ 플랜으로 시작했었습니다. 아무래도 워드프레는 램을 비롯한 자원을 많이 사용하는 경향이 있어서 충분한 속도를 내기 위해서 4GB 램과 120GB 스토리지의 월 24$ 플랜으로 업그래이드 하려고 합니다.
▽ 서버 크기를 선정 화면
면서버 설치, 가상서버호스팅 vultr 서버 크기, 플랜 선택 장면
3.4. 추가 기능 설정
이어서 추가 기능을 선택할 수 있습니다.
IPv6를 추가할 수 있고(무료)
자동백업 선택(이는 요금 플랜의 20%가 붙습니다. 위에서 5$ 플랜을 선택 시 1$, 10$ 플랜을 선택 시 2$ 등)
DDOS Protection 항목이 있는데 이는 미국 일부 지역만 현재 가능하다고 함
Private Networking 선택, 이는 Vultr에 여러 개 서버를 운영하는 경우 서버별 내부 IP를 할당 받아 내부 트랜지션을 할 수 있는 기능
저는 혹시 몰라서 IPv6를 사용한다고 선택했습니다.
3.7. 세팅 완료
드디어 서버 세팅이 끝났습니다. 그러면 계정 정보의 Product 섹션에 서버 리스트가 나타납니다.
3.8. 서버 상태 정보
▽ 최종 세팅한 서버의 상태 정보입니다. 보안을 위해서 일부 화면은 지웠습니다.
4. 서버 세팅 및 워드프레스 설치
다음 단계는 서버 세팅 단계입니다. 여기에서는 사이트를 운영하는 데 필요한 여러가지 프로그램을 설치합니다.
웹 서버(Web Server)는 HTTP를 통해 웹 브라우저에서 요청하는 HTML 문서나 오브젝트(이미지 파일 등)을 전송해주는 서비스 프로그램을 말한다. 웹 서버 소프트웨어를 구동하는 하드웨어도 웹 서버라고 해서 혼동하는 경우가 간혹 있다.
이러한 기능을 하는 웹서버에는 아파치(Apache), NGINX, 마이크로소프트 윈도우즈 등이 있는 데요.
NETCRAFT 자료를 보면 2020년 11월 기준, 활성화 되어 있는 웹사이트 기준으로 NGINX 34%로 가장 높은 점유율을 보이고 있으며, 기타 28% 그리고 아파치(Apache) 27%, 마이크로소프트 윈도우즈 8%의 점유율을 보이고 있습니다.
최근몇 년간 NGINX 점유율이 크게 증가했으며, 반대로 아파치나 마이크로소프트 윈도우즈 점유율이 크게 하락했습니다. 그중에서 아파치 점유율 하락은 처참하군요.
웹서버 종류별 점유율 추이( ~2020년 11월), Graph by NETCRAFT
역시 NGINX가 가장 빠르게 성장해 이제는 하고 있는 웹서로 확인되고 있습니다. 위 그래프를 보면 2017년 12월 NGINX가 처음으로 마이크로소프트를 제치고 No 2가 되었고 이어 2020년 4월 아파치를 제치고 가장 많이 사용하는 웹서버가 되었습니다.
“NGINX가 작은 자원을 가지고 효율적으로 운영될 수 있어서 처름 시작하는 소규모 사이트에서 각광을 받고 있으며 아파치(Apache)는 기준 풍부한 운영 경험을 토대로 대규모 사이트에서 선호하고 있다.”고 합니다.
그런 의미에서 저는 참고 자료들이 상대적으로 적지만 자원 효율성이 좋다는 NGINX를 선택했습니다. 물로 아파치(Apache)도 NGINX에 대항하고자 고효율이 가능한 패치를 지속적으로 업데이트하고 있어 성능에서 NGINX가 확실하게 더 좋다고는 할 수 없다고 하네요.
(그동안 주워들은 풍월로 이야기하면) 다만 세팅 등은 확실히 NGINX가 단순합니다. 그래서 초보들에게 더 맞습니다.
4.1.2. 데이타베이스 선택
이제 데이타베이스를 선택할 시간인데요. 우리나라에서는 MySQL이나 MariaDB를 많이 선택하는 것 같습니다.
MySQL 창업자인 마이클 와이드니어는 MySQL이 오라클에 인수되고 오라클에서 제대로 발전하지 못하자 독립해 MariaDB를 제안합니다.
이 MariDB는 MySQL과 호환되면서도 더 많은 운영체제를 지원하고 더 진보된 기능을 넣어 성능을 개선 시키겠다는 목표로 출발했습니다.
사담으로 마이클 와이드니어의 첫째딸이 My이고 막내 딸이 Maria라고 하네요. 그래서 이름을 MySQL과 MariaDB라고 지었다고 합니다.
아무튼 오라클에 인수된 MySQL은 라이센스를 높이는 등 상업성을 강화했음에도 불구하고 강력한 지원에 힘입어 데이타베이스 업계에서 막강한 시장점유율을 유지하고 있습니다.
최근 자료를 찾지 못해 2016년 중반의 데이타베이스 점유율 자료에 따르면 MySQL이 69%로 압도적이 지위를 차지하고 있으며 다른 자료들과 비교해보면 MySQL의 점유율이 더욱 높아지는 추세를 보이고 있습니다.
반면 MariaDB등 다른 데이타베이스 점유율은 점점 낮아지는 추세를 보이고 있구요.
▽ 데이타베이스 시장점유율 Database market share 2016 2Q~3Q
위 그래프에서 두번째로 높은 점유율을 가진 PostgreSQL은 일본 등에서 인기가 높은 데이타베이스라고 하네요.
세번째는 MySQL이 오라클로 넘어가면서 상업화가 짙어지고 이에 반발해 등장한 MariaDB가 10% 점유율로 그 뒤를 따르고 있습니다. MariaDB는 MySQL과 완벽하게 호환되면서 MySQL보다 가볍고 빠르며 라이센스가 비교적 자유롭기 때문에 소규모 사이트에서 선호를 보이고 있다고 합니다.
위키백과에 따르면 MariaDB는 MySQL과 아래처럼 호환된다고 합니다.
데이터와 테이블 정의 파일(.frm) 파일이 바이너리 호환이 된다.
모든 클라이언트 API, 프로토콜 그리고 구조가 동일하다.
모든 파일이름과 바이너리, 경로, 포트, 소켓 그리고 기타 등등이 동일하다.
모든 MySQL 커넥터(PHP, Perl, 파이썬, 자바, .NET, MyODBC, Ruby, MySQL C 코넥터 등)가 마리아 DB와 동일하게 작동한다.
현재는 MySQL과 MariaDB는 호환 되기 때문에 무엇을 선택해도 무방할 것 같습니다. 별 문제없이 마이그레이션 된다고 합니다.
저는 상대적으로 가볍고 빠르다는 말에 현혹되어 MariaDB를 선택했습니다. 아마 본격적인 비지니스를 한다면 라이센스가 비싸지만 지원이 풍부한 MySQL을 선택할 수도 있겠습니다.
4.1.3. PHP 버젼 선택
새롭게 시작한다면 당연 PHP 최신 버젼인 PHP 8.0을 설치하는 게 맞겠죠.
다만 적용해야하는 플러그인들의 호환성을 고려한다면 7.4대를 선택할 수 도 있겠네요. 아직까지 PHP 8 호환성은 썩 뛰어난 편은 아닙니다.
Current default time zone: 'Asia/Seoul'
Local time is now: Sat Oct 1416:24:42 KST 2017.
Universal Time is now: Sat Oct 1407:24:42 UTC 2017.Code language:PHP(php)
4.2.3 APT 소스 리스트 파일에 Nginx, PHP, MariaDB 저장소 추가
sources.list를 열어서 파일 맨 끝에 소스리스트를 추가
# vi /etc/apt/sources.listCode language:PHP(php)
파일 맨 끝에 아래 내용 추가
# Nginx로부터 NGINX 설치# https://www.nginx.com/resources/wiki/start/topics/tutorials/install/
deb http://nginx.org/packages/mainline/ubuntu/ focal nginx
deb-src http://nginx.org/packages/mainline/ubuntu/ focal nginx# MariaDB 10.5 repository list - created 2020-07-10 13:10 UTC# http://downloads.mariadb.org/mariadb/repositories/
deb [arch=amd64] http://mirror.yongbok.net/mariadb/repo/10.5/ubuntu focal main
deb-src http://mirror.yongbok.net/mariadb/repo/10.5/ubuntu focal mainCode language:PHP(php)
add-apt-repository ppa:ondrej/php를 실행하면 여기서 아래와 같은 메세지가 나오면서 엔터를 치라는 메세지가 나오는데요. 고민하지말고 엔터를 치면됩니다.
Co-installable PHP versions: PHP 5.6, PHP 7.x and most requested extensions are included.
You can get more information about the packages at https://deb.sury.org
BUGS&FEATURES: This PPA now has a issue tracker:
https://deb.sury.org/#bug-reporting
CAVEATS:
1.If you are using php-gearman, you need to add ppa:ondrej/pkg-gearman
2.If you are using apache2, you are advised to add ppa:ondrej/apache2
3.If you are using nginx, you are advise to add ppa:ondrej/nginx-mainline
or ppa:ondrej/nginx
PLEASE READ: If you like my work and want to give me a little motivation, please consider donating regularly: https://donate.sury.org/
WARNING: add-apt-repository is broken with non-UTF-8 locales, see
https://github.com/oerdnj/deb.sury.org/issues/56 for workaround:# LC_ALL=C.UTF-8 add-apt-repository ppa:ondrej/php
More info: https://launchpad.net/~ondrej/+archive/ubuntu/php
Press [ENTER] to continueor ctrl-c to cancel adding it
Code language:PHP(php)
여기서 엔터를 눌러주면 된다..
지금까지 작업한 APT 패키지 정보를 업데이트 합니다.
# apt-get updateCode language:PHP(php)
4.3. Nginx 설치
Nginx를 설치하고 nginx를 다시 가동(restart)시킵니다.
# apt-get install nginx# service nginx restart# nginx -v // Version checkCode language:PHP(php)
4.4. PHP 8.0설치
지난 2020년 11월 26일 드디어 PHP 8.0이 발표되었기 때문에 여기에서는 PHP 8.0을 기준으로 설치합니다. PHP 최신 버전은 아래 링크에서 확인해 볼 수 있습니다.
NGINX를 사용한다면 php handler에서 서버 API를 연결하도록 되어 있는데요. 여기서 php 8로 변경 설정해야 합니다.
nginx에서 변경해야 하는 파일은 /etc/nginx/conf.d/default.conf 인데요.
사람에 따라선 이를 다른 이름으로 사용하는 분도 있습니다. 여러 개의 사이트를 운영하는 경우 사이트명을 변경하는 경우도 있습니다. 저도 이를 happist.com.conf라는 이름으로 사용하고 있습니다.
이 파일에서 fastcgi_pass unix:/run/php/php7.4-fpm.sock; 을 fastcgi_pass unix:/run/php/php8.0-fpm.sock;으로 바꾸어줘야 합니다. 그래야 php8.0을 인식하고 php8.0으로 작동합니다.
# Add PHP handler
location ~ \.php$ {
try_files $uri =404; # comment out this line if php-fpm is hosted on a remote machine
include /etc/nginx/fastcgi.conf;
fastcgi_cache WORDPRESS;
# add_header X-Cache $upstream_cache_status;
# fastcgi_pass unix:/run/php/php7.4-fpm.sock; --> 아래로 변경
<span class="highlight">fastcgi_pass unix:/run/php/php8.0-fpm.sock;</span>
fastcgi_no_cache $skip_cache;
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
if (!-f $document_root$fastcgi_script_name) {
return 404;
}
}Code language: HTML, XML (xml)
이는 매우 중요한 세팅으로 반드시 필요합니다. 우분투 18.04부터는 위치가 조금 바뀌었습니다.
예전에는 my.cnf 파일을 직접 편집하도록 되어 있지만 지금은 mariadb.cnf를 편집하면 my.cnf에 그대로 반영됩니다.
nano /etc/mysql/mariadb.cnfCode language:PHP(php)
아래 내용으로 변경한다.
# MariaDB-specific config file.# Read by /etc/mysql/my.cnf
[client]
Default is Latin1, if you need UTF-8 set this (also in server section)
default-character-set = utf8mb4
[mysqld]
#
* Character sets
#Default is Latin1, if you need UTF-8 set all this (also in client section)
#
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
character_set_server = utf8mb4
collation_server = utf8mb4_unicode_ciCode language:PHP(php)
변경 내용을 반영해 DB를 다시 시작합니다.
service mysql restartCode language:PHP(php)
4.5.3. Nginx와 PHP-FPM 연결
nginx는 기본적으로 nginx 사용자 권한으로 실행되고, PHP-FPM 프로그램은 기본적으로 www-data 사용자 권한으로 실행되므로 둘의 사용자 권한을 www-data로 일치시킨다.
nano /etc/nginx/nginx.confCode language:PHP(php)
user nginx; 를 user www-data; 로 변경
worker_processes 1; 를 worker_processes auto; 로 바꾼다. 고사양 서버에서 성능이 더 좋아진다고. 일반적으로 트래픽이 적은면 1을 사용하고 트래픽이 많아지면 auto를 사용한다.
일반적으로 웹 서버 세팅이 끝난 후 보안 설정을 하는 경우가 있는데 그동안에는 무방비 상태이므로 가능하면 SSH에 처음 접속하는 순간부터 바로 보안 설정을 하도록 합니다.
5.1. ssh 포트 변경
일반적으로 ssh포트s는 22번으로 할당됩니다. 그렇기 때문에 너무 잘 알려쟜기 때문에 이를 이용해 공격해오는 경우가 있다고 합니다.
따라서 자기만 아는 포트 번호로 변경 사용하는 게 필요합니다. 이렇게 개인만 아는 포트로 변경하면 서버 공격이 확 줄어듭니다.
특정 서버를 목표로 공략한다면 또 다른 강력한 보안 정책이 더 필요하지만 일반적으로는 22포트를 기반으로 무작위적 공격하는 경우가 많기 때문에 포트 변경 시 상대적으로 공격을 덜 받을 수 있습니다.
22번 포트를 변경하려면 먼저 sshd_config에서 22번대신 사용할 포트 번호로 바꾸어 준다. 즉
/etc/ssh/sshd_config 에서 Port 22 를 찾아서 자기가 사용할 포트 숫자를 기억하기 쉽고 10,000자리이상에서 임의의 숫자를선택한다. 예를 들어 58722, 65322 등등
Port 번호는 1에서 65535 사이의 사용하지 않는 포트를 사용할 수 있습니다. 루트에서만 사용할 수 있는 권한있는 포트 (포트 1-1024)를 선택하는 것이 좋다는 의견이 있습니다만 저의 경우 루트를 10000이상 포트를 사용하는데 별다른 기능 사용 한계를 느낄 수 없었습니다.
nano /etc/ssh/sshd_config Code language:PHP(php)
아래는 ssh 포트로 26977을 사용하겠다고 수정한 경우입ㄴ다.
#Port 22
<span class="highlight">Port 26977</span>
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::Code language: HTML, XML (xml)
이렇게 포트를 변경한 후 ssh 서비스를 재시작 합니다.
service ssh restartCode language:PHP(php)
5.2. ssh 사용자 및 사용 ip 제한
더욱 더 강력한 조치는 ssh 사용자 또는 ip 자체를 제한하는 방법입니다.
특정 ip만 허용
저의 경우는 집에서 사용하는 ip와 태블릿에서 사용할 수 있는 ip만으로 제한했습니다. 다만 태블릿은 LTE 데이타를 사용하는 관계로 일정 ip대를 제한했는데요. 계속 변경되기 때문에 막히기 일수 입니다.
그러면 집에 가서 허용 ip를 변경해 주거나 급하면 vultr.com 계정 터미널 접속해 ip를 변경해 주어야 합니다. 아마 Vultr가 아닌 다른 회사들도 계정을 통해서 현재 접속 ip와 상관없이 서버에 접속할 수 있는 방법이 있을 것으로 보입니다.
항상 태블릿에서 사용할 필요가 없기 때문에 이런식으로 대응할 수 있지만 업무상 항상 접속해야 한다면 문제가 생기면 ip 제한을 푸는 방법도 고려해 볼 수 있습니다.
그리고 나머지 ip는 모두 사용 중지 시킵니다. 이는 /etc/hosts.deny 파일을 수정합니다.
nano /etc/hosts.denyCode language:PHP(php)
여기에서 ALL을 추가합니다. 허용된 ip외는 모두 거부하라는 명령으로 아주 강력합니다.
sshd: ALLCode language: HTTP (http)
5.3. 특정 사용자만 허용 또는 금지
또 sshd_config 파일에서 특정 사용자를 허용하든지 금지시킬 수 있습니다.
nano /etc/ssh/sshd_configCode language:PHP(php)
이 파일에서 아래처럼 AllowUsers 다음에 허용할 사용자를 추가합니다. 예를 들면 daisy 사용자만 추가한다면 다음과 같은 명령을 사용합니다.
AllowUsers daisyCode language:PHP(php)
6. 웹서버 보안 설정
여기에서는 웹서버 보안 설정 방법에 대해서 설명합니다.
우분투에서 기본적으로 사용할 수 있는 ufw를 사용할 수 있고 아니면 조금 더 정교하게 보안을 설정하기 위해서는 iptales을 이용할 수도 있습니다.
6.1. 웹서버 보안 ufw 설정
ufw는 우분투에서 제공하는 방화벽 도구로 아래에서 설명하는 iptales를 간단히 사용할 수 있도록 만든 것입니다.
운영체제별로 이와 같은 간단히 편하게 사용할 수 있는 보안 설정 방법을 제공하고 있습니다.
전는 아래에서 사용하는 iptales를 이용하려고 하기 때문에 기본적인 ufw 설명만 소개하고 넘어가도록 하겠습니다.
ufw enable # 방화벽을 활성화한다.
ufw allow 80/tcp # 일반 웹 정보 관련 입출력 통로
ufw allow 443/tcp # SSL 설치 시 웹 정보 관련 입출력 통로
ufw allow 26977/tcp # ssh용 신규 포트 위에서 개인적으로 설정한 포트 번호Code language: PHP (php)
6.2. 우분투에서 IPtables 사용하기
우분투에서는 기본 방화벽으로 UFW(Uncomplicated Firewall)를 사용하고 있습니다. UFW는 아주 간단하고 명료한 방화벽을 구성할 수 있고, 무엇보다도 쉽기 때문에 초보가 사용하기에 좋습니다.
그러나 UFW는 IPtables를 조금 더 편리하게 사용할 수 있도록 만든 것에 불과하므로 조금 더 복잡하고 디테일한 방화벽을 구성하려면 IPtables를 사용하는 것도 좋습니다.
IPtables 사용전에 UFW 사용 중지
처음 서버 세팅 시라면 UFW를 적용하지말고 바로 IPtables을 설치하면됩니다.
그러나 방화벽으로 UFW를 사용하다가 IPtables로 바꾼다면, 우분투 서버에서 Iptables를 설정하기 전에 먼저 UFW를 사용 중지합니다.
UFW 중지 명령은 아래와 같습니다.
ufw disableCode language:PHP(php)
그리고 UFW를 기반으로 설정되어 있는 방화벽 설정을 모두 초기화 시킵니다. 이는 UFW도 IPtables를 기본으로 활용하므로 아래와 같은 명령을 사용합니다.
iptables -FCode language:PHP(php)
IPtables를 안정적으로 사용하기 위한 패키지 설치
IPtables이나 Fail2Ban과 같은 보안 프로그램들은 다시 시작하면 기존 설정이 초기화됩니다. IPtables도 마찬가지로 시스템을 다시 시작한다든지 다시 시작하게되면 설정이 초기화됩니다.
최신 버전의 우분투(Ubuntu)에서 이는 특히 피할 수 없이 나타는 현상이므로 이를 해소할 수 있는 패키지를 설치합니다.
이러한 패키지로 추천되는 것이 바로 iptables-persistent입니다. 여기서는 이를 사용하도록 합니다.
그리고 netfilter-persistent도 같이 설치합니다. netfilter는 IPtabels를 이용하면서도 이를 뛰어넘을 솔류션으로 인기를 끌고 있다고 하네요.
ignoreip : 절대로 믿을 수 있는 white ip 리스트, 예를들어 관리자가 항상 접속하는 ip 등등 이는 123.123.123.123/32와 같은 형태로 적고 스페이스바로 구분
bantime : 접속을 차단할 시간, 기본은 86400초 영구 접속 차단을 원할 경우 -1을 사용 영구 차단 또는 차단 시간을 길게 주면 재부팅시 fail2ban 다시 ip차단 리스트를 읽어오기 때문에 느려질 수 있다고 합니다. 그러나 요즘 서버 컴퓨터 성능도 좋아지고 있으므로 이는 어느정도 감수할 만한 수준으로 보여집니다.
findtime : 통계를 찾을 시간, 기본 10m
maxretry : 허용 fail 횟수, 기본은 5
banaction : ip 차단 방법 이는 /etc/fail2ban/action.d 폴더에 있는 action을 입력할 수 있습니다. firewalld 을 사용한다면 “firewallcmd-new” 값 입력. iptables 을 사용한다면 “iptables-multiport” 값 입력. 기본은 banaction = iptables-multiport로 설정되어 있음
banaction_allports 기본은 iptables-allports
action : 알림 메일등을 받을 것인지 결정 action에 “%(action_mw)s” 값 입력 시 ip차단하면 알림메일이 전송. 알림메일을 받지않으려면 “%(action_)s” 값으로 변경
[sshd] enabled : sshd를 모니터링 할것인지 결정 fail2Ban에서 가장 중요한 설정으로 설치 시 기본 사용토록 되어 있습니다. 우분투에서는 /etc/fail2ban/jail.d 폴더에 있는 defaults-debian.conf에서 설정되어 있습니다.
7.2. 기본 설정 변경 파일
Fail2Ban의 기본 설정 파일은 /etc/fail2ban/jail.conf 입니다.
대부분 여기서 수정해도 문제가 없지만 몇가지 경우에는 업데이트 시 기본 설정 파일이 초기된다고 합니다. 예를 들어 yum을 사용해서 설치한 경우 yum업데이트 시 자동으로 기본 세팅으로 바뀝니다.
이럴경우 기본설정 파일을 직접 수정하지 않고, 기본 설정파일을 참조하여 새로 생성한 사용자 설정파일에서 설정해주는 방법으로 하면 업데이트가 되는 경우에도 사용자 설정 파일을 덮어쓰지 않게 됩니다.
이 파일은 /etc/fail2ban/jail.d 폴더에 위치하게 됩니다. 보통 local.conf라는 이름으로 많이 사용하네요.
인증서를 획득하는게 중요한게 아니고 얼마나 철저한 암호화 설정을 하느냐가 중요하기에 암호화 알고리즘을 적용합니다.
아래는 시스템에 적용된 암호화 알고리즘들 입니다.
# Letsencrypt 기본 RSA 인증서
ssl_certificate /etc/letsencrypt/live/happist.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/happist.com/privkey.pem;
#OCSP Stapling(인증서가 유효하다는 증명을 미리 받아두어서 사이트에 처음 방문할 때 접속 속도를 높여주는 방법dla)
ssl_trusted_certificate /etc/letsencrypt/live/happist.com/chain.pem;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 10s;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_session_timeout 5m;
ssl_session_cache shared:SSL:50m;
ssl_dhparam /etc/nginx/ssl/dhparams.pem;
ssl_session_tickets on;
ssl_session_ticket_key /etc/nginx/ssl/session_ticket.key;Code language: PHP (php)
참고 Let’s Encrypt SSL인증서 발급 관련 참고 – 1주일에 5번만 발급 가능
서버를 세팅하다보면 본의아니게 서버 설치를 반복하게 됩니다.
이런 저런 문제를 해결하고자 고민하다 문제 원인을 못 잡으면 다시 설치하고 또 다시 설치하고를 반복하게 되죠.
그런데 Let’s Encrypt SSL인증서는 1주일에 5번까지 발급 받을 수 있도록 제한되어 있습니다. 여러번 시행 착오를 통해서 5번이 넘어서면 아래와 같은 메세지가 나오면서 발급이 안됩니다.
An unexpected error occurred:
There were too many requests of a given type :: Error creating new cert :: too many certificates already issued for exact set of domains: test.com www.test.comCode language: JavaScript (javascript)
참고하시기 바랍니다.
9. 워드프레스 설치
이제 워드프레스를 설치합니다. 아래 내용은 아래 포스팅을 참조하여 일정 부분 수정한 것입니다.
나름 제대로 세팅했다고 생각하고 인터넷에서 주소를 입력하면 403에러가 뜨면서 연결이 아예 안되는 경우가 있습니다.
이에 대한 여러 이유가 있는데 그중 하나가 index.php파일 없을 때도 뜬다고 합니다.
워드프레스 파일을 올리는 과정에서 이 파일만 빠지거나 어떤 이유로 삭제되어서 발생하는 경우입니다.
10. 웹서버 모니터링 또는 튜닝
이렇게 웹서버 세팅이 완료되어 본격적으로 사이트 운영이 시작되었다면 사이트가 잘 운영되는지, 효율적인지 볼 필요가 있을 것입니다.
그래서 웹서버 운영시 사용하는 몇가지 모니터링 프로그램을 소개해 봅니다.
10.1. Htop(Linux Process Monitoring)
Htop은 윈도우즈의 작업관리자와 비슷하게 리눅스에서 시스템 사용량 즉 CPU 사용량, 메모리 사용량 등을 어느 정도 비쥬얼적으로 모니터링할 수 있는 프로그램입니다.
리눅스에는 이러한 시스템 자원 상황을 모니터링하는 프로그램에는 Top, Htop, Atop, Nmom, Glances, Saider 등이 있는데요. 최근 Top을 개량한 Htop이 많이 호평을 받고 있습니다.
10.1.1. Htop 설치
Ubuntu에서는 apt-get 명령어를사용해 서버 모니터일 프로그램인 htop을 설치 합니다.
apt-get install htop
Code language:PHP(php)
10.1.2. Htop의 사용
여기에서는 Htop의 사용법을 간략히 설명해 보겠습니다. 기본적으로 Htop은 터미널에서 htop를 쳐서 바로 사용 가능합니다. 너무 간단하죠.
htop
Code language:PHP(php)
그러면 아래와 같은 화면을 보여줍니다. Htop은 기본적으로 하나의 화면에서 모든 정보를 볼 수 있도록 되어 있으며, 상단에는 시스템의 주요 내용을 요약해 보여주고 있고, 그 아래에는 각 프로세스들의 각 활동 내용을 자세하게 보여줍니다. 이 모든 상황은 1초 단위로 업데이트 됩니다.
구체적으로 Htop 화면 상단 왼쪽에 CPU, Swap, Memory 사용량을 총량 비 사용량을 표시해 줍니다. 일CPU가 여러 개일 경우는 CPU 번호별로 사용율을 보여줍니다. 오른쪽에는 테스크 정보와 쓰레드 정보를 보여주고 있습니다.
또한 맨 하단에 각 기능별 단축키가 표시되어 있는데, Htop에서 F1 ~ F10까지 단축키에 각 기능들이 정의 되어 있습니다.
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 파일에서 환경 설정을 효율적 세팅함으로써 효울을 더 높힐 수 있습니다.
9.2.2. OPcache 모니터링 프로그램 – Opcache-Status by Rasmus Lerdorf 설치
여러가지의 OPcache 모니터링 프로그램이 있지만 가장 간단한 OPcache-Status by Rasmus Lerdorf를 설치하고 모니터링하는 방법을 살펴 봅니다.
cd /var/www/example.com/ # 설치하고 싶은 디렉토리로 이동
wget https://raw.github.com/rlerdorf/opcache-status/master/opcache.phpCode language:PHP(php)
설치 후 인터넷 브라우저에서 설치주소/opcache.php 명령으로 모니터링 프로그램을 볼 수 있습니다. 아래 이미지가 모니터링 프로그램으로 확인한 내용입니다.
이 모니터링 프로그램으로 OPcache가 제대로 작동하고 있는지 메모리 설정은 문제가 없는지 확인해 볼 수 있습니다. 저는 처음에 OPcache에 메모리를 256MB를 할당했다가 모니터링을 계속해보니 60~ 70MB 정도를 사용하는 것을 보고 메모리 할당량을 96MB로 낮추었습니다.
cd /var/www/example.com/ # 설치 디렉토리로 이동
wget https://github.com/elijaa/phpmemcachedadmin/archive/1.3.0.tar.gz
tar -xvzf 1.3.0.tar.gz
cd phpmemcachedadmin-1.3.0
chmod +r *
chmod 0777 Config/Memcache.php
Code language:PHP(php)
이 모니터링 프로그램을 사용하다보면 사이트의 데이타베이스에 비해서 지나치게 큰 Memcached 메모리를 할당하는 경우 hit율이 많이 떨어짐을 볼 수 있습니다. 이를 기반으로 적절한 Memcached 메모리를 정할 수 있을 것 같습니다.
운영하는 사이트의 성능을 충분히 개선시키려면 데이타베이스 튜닝이 이루어져야 합니다. 이 부분은 어느 정도 난이도가 있습니다. 그렇지만 데이타베이스 튜닝을 도와주는 툴들이 많이 있고, 이 툴들의 도움을 받아 조금씩 성능을 개선해 볼 수 있습니다.
11.1. 데이타베이스 진단툴 MySQLTuner
데이타베이스 진단툴로 널리 쓰이고 있는 MySQLTuner 활용 방안을 살펴봅니다. 사실 전문가는 아니므로 어느 정도 서버가 가진 물리적인 성능을 제대로 활용할 수 있는 수준 정도로 개선방법을 찾는데 만족해야 할 듯 싶구요. 그 이상을 원한다면 전문가를 찾는 게 좋을 듯 합니다.
10.1.1. MySQLTuner 설치
MySQLTuner 설치는 아래와 같이 진행하면 됩니다. 당연히 터미널에서 아래 명령어를 사용해 설치할 수 있습니다.
웹호스팅업체는 기본적으로 자체 백업을 해줍니다. 그러나 점차 백업은 사용자의 소관이라는 인식이 늘어나면서 웹호스팅이라도 본인 스스로 백업을 챙겨야 하는 시대입니다. 예전 스마일서브를 사용하던 시기에 백업데이타로 전일치로 돌려달라고 했더니 자기는 1주일전치만 보관한다며 백업을 사용자 소관이라고 (냉냉하게)이야기하더군요. 그럴바에는 왜 웹 호스팅을 이용하는지??
아무튼 가상서버 운영시에는 전부 사용자의 책임이므로 스스로 백업 전체를 챙겨야 합니다. 이런 가상서버에서도 비록 유료이지만 백업 서비스를 이용하는 방법이 있습니다.
앞에서도 소개했지만 Vultr는 매일 백업 서비스는 플랜 가격의 20%를 받습니다. 5$ 플랜는 1$을. 10$ 플랜이라면 2$을 받습니다.
linode를 보니 스탠다드 플랜의 1GB 백업 공간을 제공하는 서비스의 경우 월 2$, 2GB는 2.5$, 4GB는 5$식으로 비용을 받고 있습니다.
12.2. Snapshot 서비스 이용
가상서버 업체별로 Shapsho 기능을 제공하고 있는데요. 특히 Vultr는 11개까지 Snapshot 기능을 무료로 사용할 수 있습니다. 이 Snapshot을 자동으로 만들 수 있으면 금상첨화인데 아직 그런 기능은 없어 주요 작업을 한 이후엔 수작업으로 Snapshot을 만들도록 하면 도움이 많이 됩니다. 특시 서버 작업전에 Snapshot을 떠 놓으면 서버 작업 중 문제를 일으킬 시 바로 복구할 수 있어 엄청 도움이 됩니다.
제가 vultr을 계속 사용하는 이유중의 하나가 바로 이 Snapshot을 무료로 사용할 수 있어서 입니다. 유감스럽게도 다른 업체들 중 만은 업체는 일정 비용을 받습니다.
서버내에서 백업을 받아 놓는 것도 필요하지만 백업본을 외부에 정기적으로 백업하는게 필요합니다. 서버 자체가 날라가는 경우를 대비해야 하기 때문이죠. 외부로 백업 받는 방법 중 하나가 드롭박스(Dropbox)를 활용해 여기에 백업 받는 방법이 있습니다. 아래는 그 방법을 간략 설명했습니다.
12.3.1. Dropbox-Uploader 설치
서버에서 드롭박스로 파일을 올려주는 프로그램인 Dropbox-Uploader를 설치 합니다.
cd /usr/bin
git clone https://github.com/andreafabrizi/Dropbox-Uploader/Code language:PHP(php)
12.3.2. Dropbox-Uploader 설정
이 다음에는 스크립트에 실행 권한을 부여하고 실행합니다. 처음 실행하면 여러분의 드롭박스 계정에 Dropbox-Uploader를 연결하는 작업을 실행하게 됩니다.
cd /usr/bin/Dropbox-Uploader
chmod +x dropbox_uploader.sh
./dropbox_uploader.sh
Code language:PHP(php)
crontab 설정 시 실행파일 sh 파일을 기존에 만들어 놓은 것을 FTP로부터 복사해 오는 경우가 있습니다 왜 그런지는 모르지만 이렇게 복사해오는 경우 제대로 작동하지 않습니다. nano 편집기로 바로 만든 실행 파일은 정상적으로 작동하지만, 복사해온 실행 파일은 멀쩡히 해당 디렉토리에 존재하고 파일 권한도 충분하고 소유권도 root로 되어 있어 문제가 없어보이는데 Permission denied, not found같은 메세지를 내 보냅니다.
여러변 테스트를 통해서 내린 결론은 crontab 실행 파일은 서버 세팅 시 새로 만들어야겠다는 결론이었습니다.
조금 귀찮지만 sh 파일을 편지기를 사용해 다시 만들자구요.
13.2. 변경 후 반드시 cron 다시 실행시키기
crontab(크론탭) 명령을 등록 후 반드시 cron을 다시 실행해야 변경 내용에 제대로 반영됩니다.
service cron start # 가동
또는
service cron restart # 재가동Code language:PHP(php)
13.3. 실행 파일은 일반 경로에 위치, path 설정 – not found
cron은 보안때문에 사용자 개인 설정 파일을 참조하지 않습니다. 즉 사용자의 쉘 초기화 파일(.bashrc, .bash_profile)을 읽지 않습니다. 그러므로 실행 프로그램(예를 들어 *.sh)들은 /usr/bin이나 /bin과 같은 일반 경로에 있어야 cron이 제대로 찾아서 실행시킬 수 있습니다. 이런 경로에 없다면 /bin/sh: 1: /bin/dbbackup.sh: not found 같은 메세지가 메일로 보내집니다.
물론 실행 파일을 root에 놓는다면 문제는 없지만 다른 경로에 놓는 경우는 반듯이 참고해야 합니다.
첫째는 crontab -e 명령어를 사용해서 등록하는 것이구요. 이런 방식은 root가 작업하는 것으로 인지하므로 root 주체를 표기할 필요가 없습니다.
40 4 * * * mysqlcheck.sh
둘째는 /etc/crontab 파일에서 직접 등록하는 방법입니다. 이경우는 vi, nano와 같은 편집기로 crontab 파일을 열어서 편집을 합니다. 이는 작업 주체가 다양할 수 있기 때문에 반듯이 root 를 표기해 주어야 합니다.
40 4 * * * root mysqlcheck.sh
여기에서는 crontab -e를 사용하는 방법에서 나타나는 문제점등을 중심으로 설명드리겠습니다.
2. crontab(크론탭) 설정 시 유의 사항 몇가지
지금부터는 crontab(크론탭) 사용 시 주의점과 문제 해결 방법을 적어 봅니다.
2.1. 실행파일 sh는 복사하지 말것
crontab 설정 시 실행파일 sh 파일을 기존에 만들어 놓은 것을 FTP로부터 복사해 오는 경우가 있습니다 왜 그런지는 모르지만 이렇게 복사해오는 경우 제대로 작동하지 않습니다.
nano 편집기로 바로 만든 실행 파일은 정상적으로 작동하지만, 복사해온 실행 파일은 멀쩡히 해당 디렉토리에 존재하고 파일 권한도 충분하고 소유권도 root로 되어 있어 문제가 없어보이는데 Permission denied, not found같은 메세지를 내 보냅니다.
여러변 테스트를 통해서 내린 결론은 crontab 실행 파일은 서버 세팅 시 새로 만들어야겠다는 결론이었습니다.
조금 귀찮지만 sh 파일을 편지기를 사용해 다시 만들자구요.
2.2. 변경 후 반드시 cron 다시 실행시키기
crontab(크론탭) 명령을 등록 후 반드시 cron을 다시 실행해야 변경 내용에 제대로 반영됩니다.
service cron start # 가동
또는
service cron restart # 재가동
2.3. 실행 파일은 일반 경로에 위치, path 설정 – not found
cron은 보안때문에 사용자 개인 설정 파일을 참조하지 않습니다. 즉 사용자의 쉘 초기화 파일(.bashrc, .bash_profile)을 읽지 않습니다.
그러므로 실행 프로그램(예를 들어 *.sh)들은 /usr/bin이나 /bin과 같은 일반 경로에 있어야 cron이 제대로 찾아서 실행시킬 수 있습니다. 이런 경로에 없다면 /bin/sh: 1: /bin/dbbackup.sh: not found 같은 메세지가 메일로 보내집니다.
물론 실행 파일을 root에 놓는다면 문제는 없지만 다른 경로에 놓는 경우는 반듯이 참고해야 합니다.
가끔 실행 파일에 제대로 권한이 성정되지 않았다면 아래와 같은 메세지가 메일로 보내집니다.
/bin/sh: 1: dbit.sh: Permission denied
그렇기 때문에 충분한 권한을 줍니다.
chmod +x dbbackup.sh
2.5. crontab 작동 확인 – service cron status
그리고 crontab이 제대로 작동하는지 확인하기 위해서 service cron status 명령을 사용합니다.
service cron status # checks if cron is running
그러면 아래와 같은 메세지를 보여줍니다.
# service cron status
● cron.service - Regular background program processing daemon
Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2018-01-17 03:17:19 KST; 17h ago
Docs: man:cron(8)
Main PID: 16188 (cron)
Tasks: 3 (limit: 4915)
Memory: 45.9M
CPU: 5min 9.772s
CGroup: /system.slice/cron.service
├─ 5389 /usr/sbin/CRON -f
├─ 5461 /usr/sbin/sendmail -i -FCronDaemon -B8BITMIME -oem root
└─16188 /usr/sbin/cron -f
Jan 17 20:35:03 root sendmail[5293]: w0HBZ3GQ005293: to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:
Jan 17 20:35:03 root CRON[5221]: pam_unix(cron:session): session closed for user root
Jan 17 20:35:03 root sendmail[5380]: My unqualified host name (happist) unknown; sleeping for retry
Jan 17 20:36:01 root CRON[5389]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 17 20:36:01 root CRON[5390]: (root) CMD (dbit.sh)
Jan 17 20:36:03 root sendmail[5380]: unable to qualify my own domain name (happist) -- using short name
Jan 17 20:36:03 root sendmail[5380]: w0HBa3Jw005380: from=root, size=418, class=0, nrcpts=1, msgid=<20180117113
궁금해서 페이스북의 최근 1년간 주가 그래프를 찾아 보았습니다. 1년 전 127.87$이던 주가는 페이스북의 성장에 따라 쉬지 않고 올라서 올라 2018년 1월 12일 하락한 179.37$로 계산해도 40%가 올랐으므로 이런 하락이 어떤 의미를 줄지 두고 봐야겠다는 생각이 들 정도입니다.
2. 페이스북의 정책은 페이스북 브랜드에 어떤 영향을 미칠까?
그러나 페이스북의 이러한 정책의 변화는 장기적 페이스북 브랜드에 긍정적으로 작용할 것으로 보입니다.
2.1. 브랜드 정체성에 더 가까가는 정책이 될 것이다.
그것은 페이스북이 처음 세워졌던 브랜드 정체성에 더 가까이 가는 것이기 때문입니다. 원래 페이스북은 가까운 친구와 가족간의 소통을 목표로 시작한 서비스이고, 이는 소셜 미디어의 가장 큰 목적과도 부합니다.
페이스북 서비스가 점차 커가나면서 페이스북의 정체성은 비지니스적으로 규정되는 경향이 강했습니다. 가장 빠르게 성장하는 광고 플랫폼이라는 정의가 그것인데요. 페이스북 매출이 성장하는데에는 사용자의 증가, 트래픽의 증가에 힘입어 강력한 광고 플랫폼으로 성장이 큰 기여를 했습니다.
이미 페이스북을 떠나는 사람들는 페이스북의 지나치게 자주 등장하는 광고를 꼽는 사람이 많습니다. 그리고 광고와 다른 뉴스 컨텐츠 중심으로 흐르다보니 사람들은 점점 자기 이야기를 올리지 않게 되었습니다. 여전히 아주 일부는 자기 이야기를 유통하는 공간으로 이용하고는 있습니다. 그렇지만 대다수는 방관자처럼 바라만보고 있으며 일부는 뉴스 등 정보꺼리를 올리고 있죠.
이제 페이스북은 초기에 잡았던 가족과 친구들의 소통의 장을 벗어난지 오래되었습니다.
이러한 문제를 Mark Zuckerberg도 잘 알고 있죠. 페북 글에서 그는 아래와 같이 이야기하고 있습니다.
But recently we‘ve gotten feedback from our community that public content — posts from businesses, brands and media — is crowding out the personal moments that lead us to connect more with each other (최근 우리 커뮤니티로부터 이런 피드백을 받고 있습니다. 비즈니스ㆍ상품ㆍ미디어에서 올린 포스트, 즉 ‘퍼블릭 컨텐트’가 서로를 서로에게 연결해 주는 개인적인 순간을 쫓아내고 있다는 것입니다.)
그렇기에 Mark Zuckerberg는 이런 현상을 타개하기 위해서 브랜드나 광고가 제공하는 ‘퍼블릭 컨텐츠’를 줄이고 개인간에 올린 포스트를 더 자주 노출하겠다고 합니다.
The first changes you’ll see will be in News Feed, where you can expect to see more from your friends, family and groups. As we roll this out, you’ll see less public content like posts from businesses, brands, and media(여러분들이 보게 될 첫 번째 변화는 뉴스피드에서 여러분의 친구ㆍ가족 같은 그룹에서 올린 포스트를 더 많이 보게 될 것입니다. 이리되면 여러분들은 앞으로 비즈니스ㆍ상품ㆍ미디어 관련 포스트인 ‘퍼블릭 컨텐트’를 더 적게 보게 될 것입니다.
이러한 페이스북의 정책은 가족과 친구들간의 소통이라는 본래의 목적에 더 부합하기 때문에 장기적으로 긍정적으로 보여집니다.
2.2. 오히려 페이스북 사용시간을 더 늘어날 수 있다.
이마케터가 발표한 자료에 따르면 페이스북에서 소비하는 시간은 2017년까지는 증가하겠지만 2018년부터는 정체 또는 감소할 수 있다고 합니다. 이마케터는 미국인들이 하루에 페이스북에서 보내는 시간은 2013년 18분에서 2017년 23분으로 증가하지만 2018년에도 변동없이 23분을 유지할 것으로 예상하고 있습니다.
페이스북 피로 현상이 강화되면 페이스북 이용 시간은 더 빨리 줄어들 수도 있습니다.
▽ 미국인의 페이스북을 사용하는 시간 추이, 출처 : emarketer
캐니다 소재 Facebook marketing 전문업체인 MavRCK에서 페이스북의 게시물 2,500만건을 분석한 결과를 보면 사람들은 페이스북 사용에 피로를 느낀 사용자들의 이탈이 계속 증가했고, 이에 참여도도 크게 줄고 있으며 페이스북을 이용 방법과 목적이 변화하고 있다고 합니다.
어쩌면 우리가 생각하는 것보다 빠르게 페이스북 브랜드 진부화가 빨리 이루어 질 가능성도 있습니다.
그러나 이번 마크 주크버그의 발표대로 페이스북의 광고 매출을 손해보드라도 가족과 친구 중심의의 컨테츠가 강화되고 본연의 모습을 되찾을 수 있다면 페이스북 사용 시간이 더 늘어나고 집중도가 높아지지 않을까요?
MavRCK의 조사에 의하면 페이스북 포스팅에 대해 좋아요는 7.9% 감소, 댓글 37% 감소 그리고 공유도 28% 감소했고 더 나아가 직접 만들어 올리는 포스팅도 약 39% 감소했다고 합니다.
그렇지만 페이스북 사용자들은 오리지널, 사용자가 직접 만들어 올리는 컨텐츠에 대한 관심은 증가해, UGC(User Generated Contents) 즉 사용자가 직접 만들어 올리는 컨텐츠는 브랜드에서 만드는 포스팅보다 6.9배 더 높은 관심을 받는다고 합니다.
즉 페이스북을 더 활성화하려면 친구나 가족간의 소통이 강조되어야하고 그 가운데 만들어지는 컨텐츠가 높은 관심을 받고 페이스북에 사용 시간을 잡아 둘 수 있는 방업이라는 것입니다.
2.3. 페이스 매출은 어떻게 될까? – 감소는 불가피하지만…
페이스북이 광고 노출을 줄이고 친구 가족간 관련성 높은 글 노출을 강화하면서 광고 매출 감소는 불가피할 것으로 보입니다.
2017년 3분기 기준으로 광고 매출은 10,142M$인데 반해 페이먼트 등 광고 이외 매출은 186M$로 비교가 안될정도로 광고 메출이 절대적입니다. 그렇기 때문에 이번 발표로 시장이 민감하게 반응하며 주가가 급락하는 상황이 연출된 것입니다.
또 한편으로는 페이스북의 의도대로 친구와 가족 중심으로 소통이 강화되면서 커뮤니케이션 질이 좋아진다면 소비자의 몰입도가 높아지고 이에따라 페이스북 광고 효율이 좋아지고 광고 단가도 오를 수 있는 선순환을 기대해 볼 수도 있지 않을까 싶습니다.
그리고 페이스북 광고가 감소하기 때문에 페이스북에 의존하던 기업들이 (이미 광고 시장은 구글과 페이스북의 과점 시장으로 변한지 오래입니다.) 컨텐츠의 질을 높이는 노력을 경주하면서 이 또한 페이스북 컨텐츠를 높여서 선순환이 된다면 매출은 생각보다 줄어들지 않을 수 있습니다.
또한 페이스북은 페이스북과 인스타그램등으로 구성되어 있는데 인스타그램 광고가 급격히 성장하면서 이를 어느정도 상쇄하지 않을까 싶습니다.
3. 마치며
자고로 어떤 서비스든 지나치게 비지니스에 경도된다면 오래 갈 수 없습니다. 한때 우리나라에서는 잘 나갔던 캌오스토리가 지금은 거의 힘을 못쓰고 있는데 그 이유중의 하나가 지나친 상업화입니다. 카카오스토리는 사용자의 허락없이(이는 페이스북도 마찬가지) 사용자들의 포스팅 사이사이 광고성 컨텐츠가 도배되다시피 합니다. 조금 스크롤하다보면 금방 지칠정도입니다.
또한 싸이월드 몰락의 주요한 원인중의 하나는 지난친 상업화에 있습니다. 서비스 개선이나 샐운 소비자 가치를 높여주는 서비스대신 기존 서비스에서 최대한 유료화로 수익을 극대화할 수 있는 쪽으로 운영되었고 사람들은 점차 무료에다 사용 경험도 우수한 페이스북으로 이동해 버린 것이죠.
페이스북이 지나친 광고 중심에서 벗어나 소통이라는 본래의 취지를 강화하는 것은 페이스북 브랜드가 단명하지 않고 오래 갈수 있는 여건을 탄탄하게 만드는 정지 작업으로 보여집니다. 탐욕에 굴하지 않고 본연의 모습을 찾으려는 페이스북의 노력이 어떻게 귀결될지 무척이나 기대가 됩니다.
Vultr 가상서버호스팅에서 워드프레스를 운영하는 방안을 체계적으로 설명하는 일련의 시리즈를 정리하고 있습니다. 이러한 시리즈 중의 하나로 Vultr 서버 상태를 보다 면밀히 살펴보고 문제점을 찾아 개선 방안을 모색해 볼 수 있는 리눅스 시스템 자원 모니터링 프로그램 Htop를 활용하는 방법을 설명하고자 합니다.
물론 이 사용법은 Vultr 뿐만이 아니라 Linode 등 모든 가상서버호스팅 업체에서도 동일하게 적용됩니다,. 즉 리눅스에서 파생된 운영체제라면 모두 사용할 수 있지요.
1. Htop(Linux Process Monitoring)란 무엇일까?
Htop이란 윈도우즈의 작업관리자와 비슷한 개념으로 리눅스에서 시스템 사용량 즉 CPU 사용량, 메모리 사용량 등을 어느 정도 비쥬얼적으로 모니터링할 수 있는 프로그램입니다.
리눅스에는 이러한 시스템 자원 상황을 모니터링하는 프로그램에는 Top, Htop, Atop, Nmom, Glances, Saider 등이 있는데요. 최근 Top을 개량한 Htop이 많이 호평을 받고 있습니다.
2. Htop 설치
아래에서는 간단히 Htop를 설치하는 과정을 설명합니다. 리눅스에 익숙하신 분이라면 진짜 몇분 걸리지 않는 일이지요.
2.1. 시스템 업데이트 및 업그레이드
항상 새로운 프로그램을 설치하기전에는 update 및 upgrade를 합니다.
apt-get update
apt-get upgrade
2.1. Htop 설치
Ubuntu에서는 apt-get 명령어를사용해 서버 모니터일 프로그램인 htop을 설치 합니다.
apt-get install htop
Htop 설치는 리눅스의 다른 프로그램과 마찬가지로 금방 끝납니다. 길어야 1분내외.. Htop설치 시 아래와 같은 메세지를 Xshell 터미널에 뿌려주네요.
@happist:~# apt-get install htop
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
htop
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 76.6 kB of archives.
After this operation, 216 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu artful/universe amd64 htop amd64 2.0.2-1 [76.6 kB]
Fetched 76.6 kB in 0s (85.5 kB/s)
Selecting previously unselected package htop.
(Reading database ... 108849 files and directories currently installed.)
Preparing to unpack .../htop_2.0.2-1_amd64.deb ...
Unpacking htop (2.0.2-1) ...
Processing triggers for mime-support (3.60ubuntu1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up htop (2.0.2-1) ...
3. Htop의 사용
여기에서는 Htop의 사용법을 간략히 설명해 보겠습니다. 기본적으로 Htop은 터미널에서 htop를 쳐서 바로 사용 가능합니다. 너무 간단하죠.
htop
그러면 아래와 같은 화면을 보여줍니다. Htop은 기본적으로 하나의 화면에서 모든 정보를 볼 수 있도록 되어 있으며, 상단에는 시스템의 주요 내용을 요약해 보여주고 있고, 그 아래에는 각 프로세스들의 각 활동 내용을 자세하게 보여줍니다. 이 모든 상황은 1초 단위로 업데이트 됩니다.
구체적으로 Htop 화면 상단 왼쪽에 CPU, Swap, Memory 사용량을 총량 비 사용량을 표시해 줍니다. 일CPU가 여러 개일 경우는 CPU 번호별로 사용율을 보여줍니다. 오른쪽에는 테스크 정보와 쓰레드 정보를 보여주고 있습니다.
또한 맨 하단에 각 기능별 단축키가 표시되어 있는데, Htop에서 F1 ~ F10까지 단축키에 각 기능들이 정의 되어 있습니다.
각 프로세스 정보 내용
위 화면에서 각각의 프로세스 정보는 아래와 같습니다.
프로세스
프로세스 정보 설명
PID
프로세스의 ID 번호
USER
프로세스의 소유자
PR
프로세스의 우선순위
NI
우선순위에 영향을 주는 프로세스의 nice 값
VIRT
프로세스가 사용중인 가상 메모리 양
RES
프로세스가 사용중인 물리 RAM의 양 (단위는 킬로바이트)
SHR
프로세스가 사용중인 공유 메모리 양
S
프로세스의 현재 상태(zombied, sleeping, running, uninterruptedly sleeping, traced)
%CPU
프로세스가 프로세서를 사용한 시간의 사용율
%MEM
프로세스가 사용중인 RAM의 사용율
TIMR+
프로세서를 사용한 시간
COMMAND
프로세스를 시작하도록 한 명령어
단축키 설명
▶ F1(help) : htop 사용법을 알려 줌, 주로 단축기 용도를 설명
▶ F2(Setup) : htop 설정 단축키
▶ F3(Search) : 찾고 싶은 프로세스를 검색
▶ F4(Filter) : 원하는 용어를 입력, 필터링해 볼 수 있음
▶ F5(Tree) : 프로세스의 부모 자식 관계를 트리 형태로 보여주는 기능 F5를 토글해서 기능을 활성화하거나 비활성화 할 수 있다.
▶ F6(Sort) : 프로세스 별로 나누어 보여 준다. CPU, 메모리, 사용자, 우선순위, 프로세스 이름 등으로 정렬하여 쉽게 모니터링 가능.
▶ F7, F8(Nice) : 프로세스의 우선 순위를 바꾸는 단축기, F7은 올리고 F8은 내리는 기능을 함. 즉 해당 프로세스를 선택하여 F7 또는 Ehsms “]” 키를 사용하여 높이며, ‘F8’ 키 또는 ‘]’를 사용하여 우선 순위를 내릴 수 있음.
▶ F9(Kill) : 프로세스를 종료. 해당 프로세스 선택 후 F9 또는 ‘k’키를 입력하여 해당 프로세스를 종료시킴. 만약 여러 프로세스를 한번에 종료시키는 방법은 ‘space’ 키로 다수의 프로세스를 선택 후 ‘F9’ 키를 눌러 프로세스를 종료시킴.
