모두
모두콘텐츠
얼마 전 월 방문이 많지 않은 사이트의 이전 상담을 받았는데, 서버 두 대와 로드 밸런서부터 견적에 들어가 있었다. 접속 기록을 보니 피크 시간에도 요청이 초당 몇 건 수준이었다. 이런 사이트는 장비를 늘리기 전에 실제 사용량과 복구 방법부터 확인하는 편이 낫다. NHN클라우드에서도 순서는 같다.
월 방문자보다 피크 요청을 먼저 계산한다
서버 사양을 정할 때 월 방문자 수만 보면 감이 잘 안 온다. 한 사람이 페이지를 여러 번 열 수도 있고, 이미지 크기에 따라 전송량도 크게 달라진다. 먼저 최근 한 달의 페이지 조회 수, 가장 바쁜 5분의 요청 수, 응답 시간, 데이터베이스 메모리 사용량을 모은다. 기존 서버가 있다면 웹서버 접속 기록과 시스템 지표로 확인할 수 있다.
예를 들어 월 10만 페이지 조회에 페이지당 평균 전송량이 1.5MB라면 단순 계산으로 약 150GB가 나간다. 다만 브라우저 캐시와 이미지 제공 방식에 따라 실제 외부 전송량은 달라진다. 비용을 잡을 때는 추정치 하나만 넣지 말고 100GB, 200GB, 400GB 세 구간으로 계산해 두는 게 편하다.
처리 성능은 피크를 따로 본다. 월 10만 페이지 조회는 하루 평균으로 나누면 초당 약 0.04페이지에 불과하지만, 업무 시간이나 이벤트에 몰리면 순간 요청은 훨씬 많아진다. 특히 페이지 한 번을 열 때 이미지와 스크립트 요청이 함께 발생한다. 로그에서 가장 바쁜 5분의 요청 수를 300으로 확인했다면 평균 초당 1건이다. 여기에 여유를 둔 부하 시험을 해보는 쪽이 방문자 수로 서버를 짐작하는 것보다 정확하다.
작게 시작하되 메모리는 넉넉히 본다
정적 페이지나 캐시가 잘 잡힌 소규모 블로그라면 웹호스팅이나 저가형 VPS로도 충분하다. 관리형 데이터베이스, 로드 밸런서, 서버 여러 대가 처음부터 필요한 구성은 아니다. 반대로 배포 권한, 방화벽 규칙, 백업 위치를 직접 관리해야 한다면 NHN클라우드 인스턴스가 맞을 수 있다. 선택 기준은 업체 이름보다 운영에 필요한 권한과 장애 허용 시간이다.
워드프레스 같은 동적 사이트를 한 대에서 운영한다면 2개 가상 CPU와 메모리 4GB를 시험 출발점으로 잡을 만하다. 확정 사양은 아니다. 운영체제, 웹서버, PHP 작업자, 데이터베이스가 같은 메모리를 쓰기 때문이다. 메모리 2GB에서 평소 사용량이 1.8GB라면 방문자가 조금만 몰려도 스왑이 생기고 응답이 급격히 느려질 수 있다. 반면 CPU가 잠깐 80%에 올랐다는 이유만으로 바로 상위 상품으로 바꿀 필요는 없다. 피크 시간의 지속 사용률과 응답 시간을 같이 본다.
디스크도 용량만 고르면 사고가 난다. 웹 파일 8GB, 데이터베이스 12GB, 로그 5GB, 배포 중 임시 파일 5GB라면 30GB가 이미 필요하다. 여기에 증가분과 작업 여유를 더해야 한다. 데이터베이스가 계속 커지는 사이트라면 남은 용량 20% 아래에서 알림이 오도록 설정해 두는 편이 안전하다.
인스턴스 값 밖의 비용까지 적는다
NHN클라우드 비용을 비교할 때는 인스턴스 한 줄만 보지 않는다. 블록 스토리지, 외부 전송량, 플로팅 IP, 스냅샷이나 백업 저장 공간을 함께 계산해야 한다. NHN클라우드 요금 계산기도 리전과 서비스별 자원을 따로 선택하는 구조다. 실제 청구액은 리전, 사용 시간, 네트워크 사용량에 따라 달라지므로 현재 요금표로 다시 확인해야 한다.
특히 플로팅 IP는 만들어 둔 채 서버에 연결하지 않아도 과금될 수 있다. 테스트 서버를 지웠는데 주소와 저장소가 남아 있으면 다음 달에도 비용이 나온다. 월 예산표에는 서버 사용료뿐 아니라 백업 보관 기간과 예상 외부 전송량을 넣고, 테스트가 끝날 때 삭제할 자원 목록도 적어 둔다.
로드 밸런서는 서버가 두 대 이상이고 한 대가 빠졌을 때도 서비스를 이어가야 할 때 검토한다. 한 대만 연결해 두면 서버 장애를 해결해 주지 못한다. 작은 사이트에서는 그 비용을 먼저 백업 자동화와 복구 연습에 쓰는 편이 실속 있다.
이전과 장애 대응은 순서가 중요하다
이전 작업은 새 서버를 만든 뒤 파일만 복사한다고 끝나지 않는다. 기존 사이트의 파일과 데이터베이스를 각각 백업하고, 새 서버에서 복원한 다음 내부 확인을 한다. 로그인, 글쓰기, 이미지 업로드, 예약 작업, 메일 발송까지 점검해야 한다. 데이터가 계속 바뀌는 사이트라면 최종 이전 직전에 쓰기를 잠시 멈추고 데이터베이스를 다시 옮긴다. 이 단계를 빼면 마지막 몇 분의 주문이나 댓글이 사라질 수 있다.
DNS 전환 전에는 기존 서버를 바로 내리지 않는다. 주소 변경이 퍼지는 동안 두 서버로 접속이 나뉠 수 있어서다. 인증서 적용 상태와 새 서버의 접속 기록을 확인하고, 충분한 관찰 기간을 둔 뒤 기존 서버를 종료한다. 되돌릴 때 사용할 기존 설정과 데이터도 그때까지 보관한다.
백업은 서버와 분리해 보관한다. 같은 인스턴스 안의 압축 파일은 디스크가 손상되거나 인스턴스를 잘못 삭제하면 함께 사라진다. 스냅샷은 빠른 복구에 유용하지만 데이터베이스의 논리 백업을 대신한다고 생각하면 곤란하다. 주기적으로 별도 저장 공간에 백업하고, 적어도 한 번은 새 인스턴스에 복원해 로그인과 데이터 건수를 확인해야 한다. 복원에 걸린 시간이 실제 장애 때의 복구 시간이다.
사이트가 열리지 않을 때는 먼저 외부에서 접속되는지 확인하고, 인스턴스 상태와 보안 그룹, 웹서버 프로세스, 디스크 여유, 데이터베이스 연결 순서로 좁혀 간다. 502 오류라면 웹서버 뒤의 애플리케이션을, 503 오류라면 점검 설정과 연결 대상 상태를 먼저 본다. 모든 장애를 사양 부족으로 돌리면 서버만 커지고 원인은 남는다. 제가 오래 운영하며 더 믿게 된 것은 큰 서버보다 측정 기록, 분리된 백업, 그리고 실제로 해본 복구 절차다.
