모두
모두콘텐츠
얼마 전 작은 쇼핑몰의 서버 이전을 도왔는데, 기존 서버는 CPU와 메모리가 넉넉한데도 자주 멈췄다. 원인은 사양 부족이 아니었다. 디스크가 가득 찬 상태에서 데이터베이스 백업이 같은 서버에 쌓이고 있었다. vps 서버 구축은 요금제를 고르는 일보다 필요한 크기를 계산하고, 고장 났을 때 돌아올 길을 만드는 일이 먼저다.
접속 수와 전송량부터 계산한다
월 방문자 수만 보고 서버를 고르면 대개 과하게 산다. 먼저 한 달 페이지 조회 수, 페이지당 전송량, 가장 바쁜 시간의 요청 수를 적는다. 월 3만 페이지 조회에 페이지당 전송량이 1.5MB라면 월 전송량은 대략 45GB다. 이미지가 외부 저장소나 캐시에서 나가면 VPS가 직접 보내는 양은 더 적다. 반대로 이미지가 많은 게시판이나 파일 다운로드 사이트는 방문자가 적어도 전송량이 커진다.
동시 접속은 월간 조회 수를 30일로 나눈 값이 아니다. 특정 시간에 방문자가 몰리고, 한 요청이 얼마나 오래 서버를 붙잡는지가 중요하다. 초당 요청 5건이 들어오고 응답에 평균 0.2초가 걸린다면 동시에 처리 중인 요청은 평균 1건 수준이다. 다만 로그인, 검색, 결제처럼 데이터베이스를 쓰는 요청은 오래 걸릴 수 있다. 평균값으로만 판단하지 말고 운영 화면에서 바쁜 시간대의 CPU, 메모리, 응답 시간을 확인해야 한다.
작게 시작할 수 있는 구간
정적 페이지나 캐시가 잘 되는 소규모 사이트라면 1 vCPU와 메모리 1GB부터 시험할 수 있다. 웹서버와 데이터베이스를 한 대에서 돌리는 워드프레스 사이트는 2 vCPU, 메모리 2GB를 출발점으로 잡는 편이 운영하기 수월했다. 플러그인이 많거나 관리자 작업이 잦으면 더 필요할 수 있다. 이 숫자는 구매 기준이 아니라 측정을 시작할 기준이다. 기존 공유 호스팅에서 속도와 기능에 문제가 없다면 굳이 VPS로 옮길 이유도 없다.
서버를 열기 전에 접근 경로를 만든다
서버를 만들 때는 방문자가 많은 지역과 가까운 위치, 장기 지원을 받는 운영체제, 충분한 저장 공간을 고른다. 저장 공간에는 사이트 파일만 들어가는 게 아니다. 운영체제, 로그, 데이터베이스 임시 파일, 업데이트 여유분도 필요하다. 현재 데이터가 12GB라면 20GB 디스크를 꽉 채워 시작하기보다 여유를 두는 게 안전하다.
첫 접속 후에는 일반 관리자 계정을 만들고 공개키 방식으로 접속을 확인한다. 새 계정으로 다시 로그인되는 것을 확인한 뒤 관리자 계정의 비밀번호 로그인과 직접 접속을 제한한다. 방화벽은 실제로 쓸 포트만 열고, 관리용 접속은 가능하면 접속할 수 있는 출발지 주소를 좁힌다. 이 순서를 거꾸로 하면 본인이 서버 밖에 갇힐 수 있다. 콘솔 접속 수단이 있는지도 미리 확인한다.
- 운영체제 보안 업데이트와 시간 동기화를 설정한다.
- 웹 요청에 필요한 포트와 관리용 포트만 연다.
- 서비스를 실행할 계정과 파일 권한을 확인한다.
- 디스크 사용량, 메모리 부족, 서비스 중단 알림을 건다.
웹서버를 설치한 뒤에는 애플리케이션과 데이터베이스를 붙이고 SSL 인증서를 적용한다. 인증서는 발급만 해두면 끝이 아니다. 자동 갱신 작업이 실행되는지, 갱신 뒤 웹서버가 새 인증서를 읽는지 확인해야 한다. 설정 파일에 비밀번호를 직접 적거나 저장소에 올리는 실수도 이 단계에서 자주 나온다. 비밀 값은 권한을 제한한 별도 설정으로 관리한다.
백업을 만든 뒤 이전한다
VPS 업체의 스냅샷은 빠른 복구에 편하지만 백업을 전부 대신하지는 못한다. 같은 계정의 서버와 스냅샷을 함께 잃는 상황을 생각해야 한다. 데이터베이스와 업로드 파일은 별도 저장 위치에 자동으로 복사하고, 보관 기간을 정한다. 하루 한 번 백업하면 장애 직전 최대 하루치 변경분을 잃을 수 있다. 주문이나 예약 데이터가 그만큼 중요하다면 백업 주기를 더 짧게 잡아야 한다.
백업 성공 알림보다 중요한 건 복원 시험이다. 빈 서버나 임시 환경에 파일과 데이터베이스를 되돌리고, 실제 화면과 로그인까지 확인한다. 14년 동안 운영하면서 백업 파일은 있었지만 복원에 필요한 암호나 설정이 빠진 경우를 여러 번 봤다. 복원 절차와 담당자가 접근할 수 있는 위치도 함께 기록해 둔다.
기존 사이트를 옮긴다면 새 서버에서 먼저 동작을 확인한다. 데이터베이스와 파일을 복사하고, 쓰기가 계속 발생하는 사이트는 전환 직전에 마지막 변경분을 다시 맞춘다. DNS 전환 전에 기존 주소의 TTL을 낮춰 두면 전환 대기 시간을 줄이는 데 도움이 된다. 다만 이용자마다 반영 시점은 다를 수 있으니 기존 서버를 즉시 지우지 않는다. 새 서버에서 로그인, 글쓰기, 결제, 메일 발송처럼 실제 운영에 필요한 기능을 점검한 뒤 전환한다.
장애가 나면 확인할 순서를 정해 둔다
사이트가 느려지거나 열리지 않으면 먼저 장애 범위를 본다. 전체 이용자에게 같은지, 특정 지역이나 네트워크에서만 그런지 확인한다. 다음은 도메인 연결 상태, 서버 접속 가능 여부, 웹서버와 애플리케이션 상태, 데이터베이스 순서로 좁힌다. 이때 CPU 사용률 하나만 보고 사양을 올리면 원인을 놓친다. 디스크가 가득 찼는지, 메모리 부족으로 프로세스가 종료됐는지, 최근 배포와 인증서 갱신이 있었는지도 로그에서 확인한다.
평소 CPU가 낮은데 짧은 순간만 튄다면 상위 요금제보다 캐시나 느린 요청 개선이 먼저일 수 있다. 반대로 바쁜 시간마다 CPU가 오래 꽉 차고 응답 시간도 함께 늘어난다면 증설 근거가 된다. 메모리는 남은 숫자만 보지 말고 스왑 사용과 강제 종료 기록을 같이 봐야 한다. 변경 전후 수치를 남기면 요금을 올린 만큼 실제로 나아졌는지도 판단할 수 있다.
처음에는 필요한 만큼만 쓰고, 장애 때 확인할 기록과 복원할 백업을 갖춰 두는 편이 낫다. 서버 크기는 운영하면서 바꿀 수 있지만, 잃어버린 데이터와 준비 없이 끊긴 서비스는 돈을 더 내도 바로 되돌리기 어렵다.
