사이드바
목차
라이트세일로 이사
호스팅을 라이트세일로 옮겼습니다. 이전에 사용하던 호스팅1)은 가격이 한달에 약 3달러 정도로 굉장히 쌌지만 낮은 가격에 따른 제한으로 문제가 심각해지기 직전이었습니다. 일단 스토리지 제한이 30기가인데 백업을 내 스토리지에 직접 해야 했기 때문에 스토리지를 50% 이상 사용하면 백업이 불가능해질 수 있었습니다. 또 별도의 백업 플랜의 월 비용은 호스팅 비용의 몇 배에 달했고요. 또 프로세서와 램 제한이 커 규모가 커진 위키를 감당하기 벅찼습니다. 몇몇 페이지는 로딩에 실패하기도 하고 로딩에 실패하며 사이트 전체 - 아마도 서버를 공유한 모든 사람들의 사이트 전체 - 를 느리게 만들었습니다. 이미지 부하라도 줄여볼까 하고 클라우드플레어2) 설정에서 모든 이미지를 캐싱하는 정책을 사용해 꽤 오래 버텼지만 보안상 문제가 있었습니다. 또 데이터베이스 없이 파일만으로 모든걸 처리하는 도쿠위키 특성 상 파일 수 제한3)에도 빠르게 접근하고 있었습니다. 호스팅 회사를 유지하면서 적당한 상품을 찾아봤습니다만 가격은 지금 지불하는 비용의 10배가 넘었고 자동 백업을 포함하면 20배를 넘었습니다. 빠르게 포기했습니다. 그리고 한 1년쯤 전부터 고려하던 아마존 라이트세일로 옮기기로 결정했습니다.
여기부터는 'tar.gz' 압축 해제 방법을 구글로 검색해야 하는 수준의 사람이 VPS4)서비스로 호스팅을 이전하는 과정입니다. 당황스럽더라도 참으세요.
이사 과정
인스턴스 준비
- 인스턴스 선택: 가장 싼 3.5달러짜리 인스턴스는 기존 AWS 사용자라도 1개월간 무료로 사용할 수 있습니다. 이미 이 인스턴스를 사용하기에는 위키 규모가 커서 이보다 큰 인스턴스를 선택했습니다.
- 인스턴스 생성: 도쿠위키는 인스턴스 블루프린트에 없으므로 LAMP 블루프린트를 선택했습니다.
- 인증서 발급: 인스턴스에 접속한 다음 'Tutorial: Using Let’s Encrypt SSL certificates with your WordPress instance in Amazon Lightsail'를 따라하면 됩니다. 맨 아래쪽의 워드프레스 플러그인 부분만 스킵하면 되고요. 90일 후에 업데이트 해야 합니다.
- 앞단에 클라우드플레어를 붙여놓고서도 인증서를 별도로 발급한 이유는 오리진 서버와 CDN 구간의 보안을 위한 것입니다. 이전에는 클라우드플레어에서 오리진 인증서를 발급해서 사용했는데 새 서버에서는 이 설정을 어떻게 하는지 몰라 남들 하듯 인증서를 직접 발급받았습니다. 여전히 클라우드플레어의 SSL 설정은 'Full (Strict)'로 유지할 수 있습니다.
백업 및 전송
- 백업요청: 기존 호스팅 회사의 웹 인터페이스에서 백업을 실행합니다. 시간이 제법 걸리므로 인스턴스를 생성하기 전에 미리 시작했습니다. 백업파일을 내 홈 디렉토리에 그냥 생성하므로 공간이 50%는 남아있어야 안전합니다.
- 전송: 백업파일을 직접 받아서 새 서버에 올릴 수 있었지만 너무 느렸습니다. 서버끼리 바로 옮길 안전하고 예쁜 방법이 분명 있을테지만 저는 그런 방법을 몰랐고 무식하게 백업파일을 'public_html' 아래에 노출시킨 다음 새 서버의 홈 디렉토리에 'wget'으로 받았습니다. 전송은 백업을 제 컴퓨터로 다운로드하는 속도의 100배로 이루어졌습니다.
- 백업파일을 노출시킬 때 도쿠위키를 도메인 루트디렉토리에 설치하고 있어 '.htaccess mod_rewrite - how to exclude directory from rewrite rule'을 참고해 서브디렉토리를 만들고
RewriteEngine Off로 설정해 백업파일을 노출시켰습니다. - 노출된 백업파일에 접근할 때 클라우드플레어가 방해하지 않을까 걱정했는데 아무 문제도 없었습니다.
복원
- 압축해제: 'What command do I need to unzip/extract a .tar.gz file?'을 참고해 압축을 풀었습니다.
- 디렉토리 비우기: 인스턴스를 생성하면
htdocs디렉토리에 파일이 들어있습니다. 아이피로 접속해보면 기본 페이지를 띄웁니다. 필요 없으니 모든 파일을 삭제했습니다. - 압축해제한 백업 이동: 'Moving folder and subfolder to another path'를 참고해 압축이 풀린 백업을
htdocs디렉토리로 옮겼습니다.
위키 복원
DokuWiki Setup Error
The datadir ('pages') at ./data/pages is not found, isn't accessible or writable. You > should check your config and permission settings. Or maybe you want to run the installer?
- 위키 테스트: 이 상태로 브라우저에서 페이지를 불러보면 위와 같이 도쿠위키가 에러를 냅니다.
- 인스톨러를 재실행해서 문제를 해결할 수 있을 것 같았지만 과거의 제가 인스톨러를 삭제해버렸는지 없었습니다.
- 'The datadir ('pages') at ./data/pages is not found'를 참고해서
data디렉토리의 권한을 조정해서 해결했습니다. 이제 위키가 실행됩니다.
DNS 설정 변경
- 고정아이피 발급: 깜빡했다가 잠깐 당황했는데 처음에 발급된 퍼블릭 아이피는 서버를 재시작하면 바뀌는 임시 아이피입니다. 꼭 고정아이피를 별도로 발급한 다음 라이트세일 인스턴스에 연결해야 합니다.
- DNS 변경: DNS 서비스(제 경우에는 클라우드플레어)에서 도메인 루트의 A레코드를 기존 서버 주소에서 새 서버 주소로 변경합니다.
- 테스트: 브라우저에서 도메인네임을 입력해 접속해봅니다. DNS정보를 변경하면 반영되는데 24시간이 걸린다고 하는데 실제로는 몇 초 안에 테스트할 수 있습니다.
- 클라우드플레어를 사용하는 이유 중 하나는 오리진 서버 주소를 노출하지 않는 것입니다. 만약 지금까지 과정 중에 오리진 서버 주소를 노출한 적이 있다면 인스턴스에서 아이피를 분리하고 재발급해 인스턴스에 연결합니다. 이제부터는 클라우드플레어 DNS 설정에서
Proxy를 끄지 않아야 합니다.
보안 설정
클라우드플레어 화이트리스트
- 클라우드플레어 화이트리스트: 기존에 호스팅서버 앞단에 클라우드플레어를 붙여 사용했습니다. 제가 서버 앞단을 관리할 수 있을 거라고 예상하지 않으므로 CDN을 앞에 두고 저는 제 오리진 서버와 CDN 사이 구간만 신경쓰는 정책입니다.
- 'IP Ranges'를 참고해서
.htaccess파일에 화이트리스트를 추가했습니다. - 테스트: 브라우저에서 아이피를 직접 입력해 접속해봅니다. 접속되지 않으면 됩니다.
주요 디렉토리를 도큐먼트루트 밖으로 이동
Attribute: Configuration item 'store' is not set to a writeable directory.
- 제 경우에는 이동 후 위 메시지가 나타났는데 2팩터 로그인 플러그인의 'attribute' 경로가 바뀌지 않아서 그렇습니다. 도쿠위키의 설정에서
plugin»attribute»store를 변경된 절대경로로 입력해서 해결했습니다.
클라우드플레어 액세스 테스트
- 특정 웹 경로 앞에 클라우드플레어 액세스를 붙여 별도 로그인을 요구하도록 설정해놨었습니다. 설정 변경 없이 그냥 동작합니다.
이사 후 정리
- 인스턴스 정리
- 백업파일 삭제
- 디폴트 패스워드 삭제:
bitnami_application_password파일 내용을 백업하고 삭제. - 'How to Disable from Startup & Stop MySQL on Bitnami AMI'를 참고해서 데이터베이스 서비스를 종료합니다.
- 이전 사이트 정리
- 백업파일 삭제
- 이전 사이트는 서브도메인에 연결해 잠시 유지.
결론
한달에 3달러 내고 간신히 버티다가 기가 단위의 메모리와 독립된 프로세서, 널직한 SSD에서 동작하는 사이트는 바로 느낄 수 있을 정도로 쾌적해졌습니다. 보안 문제를 감수하고 CDN에 모든 이미지를 캐싱하는 꼼수를 쓸 필요도 없어졌습니다. 다만 방화벽 옵션이 대폭 간소화되어 있어 포트만 여닫을 수 있을 뿐입니다. 때문에 초보자의 관리 미숙으로 인한 사고를 줄여줄 안전장치는 부족한 편입니다. 아이노드 제한이 없어졌고 별도로 큰 비용을 요구하던 자동 백업은 스냅샷 기능으로 대체되어 인스턴스 바깥에서 낮은 비용으로 깔끔하게 실행됩니다. 또 기존에는 위키 페이지 하나에 약 420KB까지만 텍스트를 쓸 수 있었는데 그 제한도 훨씬 커져 글을 작성하는데 부담이 줄어들었습니다. (이건 웹서버 설정 어디에 붙어있는지 몰라 정확한 한계를 아직 모릅니다.) 방화벽 설정이 EC2에 비해 허술해보이는데 방화벽을 어떻게 붙이는지 아직 모르겠습니다.
월 비용은 약 2배 조금 안 되게 증가했습니다. 물론 지금 정도 사양과 백업서비스를 이전 호스팅 회사에서 구입하려면 이전의 20배 이상의 비용을 지불해야 했기 때문에 이정도면 나쁘지 않은 것 아닐까 생각하는 중입니다.
