모두
모두콘텐츠
얼마 전 월 방문자 수만 듣고 서버를 네 배로 키우려는 운영자를 만났다. 그런데 확인해 보니 CPU와 메모리에는 여유가 있었고, 느린 시간대에 데이터베이스 백업이 겹쳐 있었다. 서버 사양을 올리기 전에 병목부터 찾았으면 비용을 아낄 수 있는 경우였다. G클라우드를 검토할 때도 나는 상품 목록보다 현재 사이트의 전송량, 피크 접속, 복구 절차를 먼저 확인한다.
먼저 어떤 G클라우드인지 확인한다
여기서 말하는 G클라우드는 가비아의 클라우드 서비스를 뜻한다. 상품 안내에서 기존 Gen1을 g클라우드로 표기하는 경우가 있어 처음 보면 헷갈린다. 현재 신규 고객은 Gen2로 신청하고, 기존 Gen1 이용자는 해당 환경을 계속 쓸 수 있다. 두 세대는 선택 가능한 사양과 기능이 다르므로 예전 사용 후기에 적힌 서버 이름을 그대로 따라 고르면 곤란하다.
기존 서버를 옮기는 중이라면 운영체제 버전, 데이터베이스 버전, 디스크 사용량부터 적어 둔다. 특히 Gen1에서 Gen2로 옮길 때는 같은 이름의 기능이 있어도 설정과 지원 범위가 같은지 확인해야 한다. 가비아 클라우드 안내에는 Gen2의 스토리지 스냅샷 스케줄러가 Gen1에는 제공되지 않는다고 명시돼 있다. 이전 계획은 상품 이름보다 실제로 쓸 기능을 기준으로 세우는 편이 정확하다.
페이지 조회 수와 동시접속을 나눠 계산한다
트래픽은 먼저 월간 전송량으로 환산한다. 예를 들어 월 30만 페이지 조회이고 한 페이지를 여는 데 평균 1MB가 전송된다면 단순 계산으로 약 300GB다. 이미지 최적화나 캐시 상태에 따라 값이 크게 달라지므로, 가능하면 지난 한 달의 실제 송신량을 사용한다. 국내와 해외 전송량도 따로 기록한다. 가비아 클라우드 요금 계산기는 두 전송량을 구분해 입력받고, 서버 사양별 무료 제공량이 다를 수 있다고 안내한다.
다만 월 300GB라는 숫자만으로 CPU를 고를 수는 없다. 같은 조회 수라도 한 달 내내 고르게 들어오는 사이트와 특정 시간에 몰리는 사이트는 다르다. 월 30만 조회를 30일로 나누면 평균 초당 약 0.12회다. 피크가 평균의 50배라면 초당 약 6회가 된다. 이 숫자는 시작점일 뿐이다. 페이지 하나가 데이터베이스를 여러 번 조회하는지, 검색과 결제가 있는지에 따라 서버 작업량은 달라진다.
동시 처리량은 요청이 머무는 시간도 함께 봐야 한다. 초당 20개 요청이 들어오고 응답에 0.5초가 걸리면, 평균적으로 약 10개 요청이 동시에 처리 중이다. 응답이 3초로 늘면 같은 유입에도 약 60개가 쌓인다. 그래서 접속자가 많아 보일 때는 CPU 사용률과 함께 응답 시간, 데이터베이스 대기, 디스크 입출력을 같은 시간대에 확인한다.
작게 시작하되 비용은 전체로 본다
정적 소개 사이트나 캐시가 잘 잡힌 작은 블로그라면 처음부터 큰 가상 서버가 필요하지 않을 수 있다. 서버 설정과 장애 대응을 직접 할 이유가 없다면 저가 웹호스팅도 비교 대상이다. 직접 운영해야 하고 방문이 적은 사이트라면 리눅스 기준 1~2 vCPU와 메모리 2~4GB를 시험 구성으로 잡을 수 있다. 워드프레스처럼 데이터베이스와 관리 화면이 함께 돌아간다면 메모리 4GB 쪽에서 시작하는 편이 운영하기 수월할 때가 많다. 이 수치는 보장 사양이 아니라 점검을 시작할 기준이다.
캐시를 거치지 않는 요청이 많거나 여러 사이트를 한 서버에 올린다면 2~4 vCPU, 메모리 4~8GB를 놓고 실제 피크를 재현해 본다. CPU가 짧은 시간만 치솟는지, 메모리가 계속 부족해 스왑을 쓰는지에 따라 증설 대상도 달라진다. 이미지 전송이 주된 부담이라면 CPU보다 전송량과 캐시 설정을 먼저 보는 게 맞다. 사양을 올려도 잘못된 쿼리나 무거운 이미지가 사라지지는 않는다.
견적에는 서버 이용료 외에 루트·데이터 스토리지, 공인 IP, 초과 전송량, 백업 비용을 넣는다. 서버를 정지해 CPU와 메모리 요금이 멈춰도 연결된 스토리지와 공인 IP 요금은 계속 청구될 수 있다. 기업 계정의 장기 할인도 서버 요금에 적용되는 범위를 확인해야 한다. 가비아 클라우드 요금제 안내상 스토리지·트래픽·운영체제 라이선스는 할인 대상에서 제외된다. 작은 서버를 오래 쓸수록 이런 별도 항목의 비중이 의외로 커진다.
이전과 백업은 복구까지 시험한다
이전 작업은 새 서버에 파일을 복사하는 것으로 끝나지 않는다. 먼저 현재 서버의 파일과 데이터베이스를 별도로 백업하고, 복구에 필요한 계정과 설정을 기록한다. 새 서버에는 같은 실행 환경을 만든 뒤 파일과 데이터베이스를 복원한다. 내부에서 화면, 로그인, 글쓰기, 첨부파일, 예약 작업을 확인하고 전환 시간을 정한다. 전환 후에는 새 서버의 오류 기록과 데이터베이스 연결 수를 보면서 이전 서버를 잠시 유지한다. 되돌릴 기준과 순서를 미리 적어 두면 장애 중에 판단할 일이 줄어든다.
스냅샷은 복구 시간을 줄이는 수단이지만 그것 하나만 믿으면 위험하다. 가비아 클라우드는 사용 중인 서버에 연결된 스토리지의 스냅샷에 대해 파일 시스템 무결성을 보장하지 않는다고 안내한다. 데이터베이스는 일관된 덤프나 해당 DB의 백업 절차를 따로 마련해야 한다. 원본 스토리지를 지우면 연결된 스냅샷도 삭제될 수 있으므로, 중요한 백업은 별도 저장소에 보관하고 실제 복원 시험까지 해 둔다.
사이트가 느려졌을 때는 먼저 외부에서 접속되는지 확인하고, 이어 서버 상태·디스크 여유·웹서버 오류·데이터베이스 연결을 순서대로 본다. CPU 사용률만 보고 서버를 키우는 판단은 자주 빗나간다. 14년간 운영하면서 비용을 줄여 준 선택은 대개 큰 요금제가 아니라, 사용량을 재고 복구가 되는지 확인한 작은 구성에서 나왔다.
