IDCA 기준으로 호스팅 사양 고르는 방법

얼마 전 서버 이전 상담을 받았는데, 방문자 수가 늘었다는 이유로 VPS를 두 단계 올리려는 상황이었다. 로그를 보니 CPU는 한가했고, 장애 시간에는 데이터베이스 연결 수만 한계에 닿아 있었다. 서버를 키워도 같은 설정으로 옮겼다면 다시 멈췄을 가능성이 컸다. 이런 경우 IDCA의 관점이 꽤 쓸모 있다.

IDCA 기준을 호스팅에 어떻게 적용할까

IDCA는 국제 데이터센터 기관의 약자다. 이 기관의 평가 체계는 데이터센터 건물만 따로 보지 않는다. 애플리케이션, 플랫폼, 컴퓨팅 자원, IT 인프라, 시설, 부지, 여러 거점의 연결까지 서비스가 전달되는 층을 함께 본다. 가용성, 용량, 복원력, 효율, 운영, 안전과 보안도 평가 항목에 들어간다. 호스팅을 고를 때 시설 등급만 보고 판단하기 어려운 이유가 여기에 있다.

예를 들어 서버가 있는 시설에 예비 전원이 있어도, 웹사이트의 데이터베이스가 한 대뿐이고 백업 복구가 실패한다면 서비스는 오래 멈출 수 있다. 반대로 작은 블로그라면 최고 수준의 시설보다 정상적인 백업과 빠른 복구 절차가 운영에 더 큰 도움이 된다. IDCA 등급은 평가받은 대상과 범위가 중요하다. 업체가 인증을 언급하면 시설의 설계, 구축, 운영 중 무엇을 평가받았는지 확인해야 한다. 그 인증을 고객의 웹사이트 전체에 대한 보증으로 읽으면 곤란하다.

트래픽 숫자를 서버 부하로 바꾸는 순서

월 방문자 수만으로 요금제를 고르면 자주 빗나간다. 먼저 하루 페이지 조회 수, 피크 시간의 집중도, 페이지당 전송량, 캐시되지 않는 요청 수를 적는다. 하루 3만 페이지 조회라면 하루 평균은 초당 약 0.35페이지다. 피크가 평균의 20배라면 초당 약 7페이지다. 한 페이지를 열 때 동적 요청이 5개 발생한다면 피크에는 초당 약 35개 요청을 처리해야 한다. 이 숫자는 서버를 고르는 출발점이고, 실제 부하는 코드와 데이터베이스 질의에 따라 달라진다.

전송량도 따로 계산한다. 페이지당 이미지와 스크립트를 포함해 1MB를 전송하고 하루 3만 페이지가 열리면, 단순 계산으로 한 달 약 900GB다. 이때 캐시가 정적 파일을 처리하면 원본 서버의 전송량은 줄 수 있지만, 호스팅 요금제의 전송량 산정 방식은 업체마다 확인해야 한다. 같은 조회 수라도 텍스트 위주의 블로그와 고화질 사진 사이트에 필요한 대역폭은 다르다.

처음부터 큰 VPS를 계약하기보다 현재 서버의 피크 시간 CPU 사용률, 메모리 여유, 디스크 지연, 데이터베이스 연결 수를 며칠간 보는 편이 정확하다. 공유 호스팅에서 관리가 편하고 제한에도 걸리지 않는다면 그대로 써도 된다. VPS가 필요한 시점은 평균 트래픽이 많아 보일 때가 아니라, 피크에 자원이 실제로 막히거나 필요한 설정을 공유 호스팅에서 바꿀 수 없을 때다. VPS로 옮기면 운영체제 보안 업데이트와 장애 대응도 직접 맡아야 한다.

요금제보다 먼저 확인할 운영 조건

저가 요금제를 비교할 때는 CPU와 메모리 숫자 옆에 복구 조건을 적어둔다. 자동 백업의 주기, 보관 기간, 백업 저장 위치, 복원 비용, 복원에 걸리는 시간을 확인한다. 같은 서버 안의 다른 폴더에만 백업이 있다면 서버나 계정 전체에 문제가 생겼을 때 함께 잃을 수 있다. 백업이 매일 만들어진다는 설명만으로는 부족하다. 파일과 데이터베이스를 함께 복원해 화면과 관리자 기능이 정상인지 직접 확인해야 한다.

이전 작업에는 순서가 있다. 새 서버에 파일과 데이터베이스를 복사하고, 실제 운영 환경에 맞는 설정으로 동작을 확인한다. 그다음 변경이 잦은 게시물이나 주문 데이터의 반영 시점을 정하고 최종 데이터를 옮긴다. 도메인 연결을 바꾼 뒤에도 이전 서버는 일정 기간 유지한다. DNS 변경이 사용자마다 다르게 반영될 수 있기 때문이다. SSL 인증서 자동 갱신, 예약 작업, 메일 발송도 이전 과정에서 빠지기 쉽다. 사이트 첫 화면만 뜬다고 이전이 끝난 것은 아니다.

가용성 수치도 운영 절차와 함께 봐야 한다. 30일을 기준으로 가용성 99.9%는 약 43분의 허용 중단 시간에 해당한다. 업체의 보장 수치가 높아도 애플리케이션 오류나 잘못된 배포까지 모두 책임진다는 뜻은 아니다. 장애 알림을 누가 받고, 몇 분 안에 확인하며, 어떤 백업으로 되돌릴지 정해두는 일이 실제 복구 시간을 좌우한다.

장애가 나면 확인할 순서

사이트가 안 열릴 때 바로 서버를 재시작하면 원인 기록을 놓칠 수 있다. 먼저 외부에서 접속되는지와 관리자만 접속되지 않는지를 나눈다. 다음으로 도메인 설정과 SSL 인증서 상태, 호스팅 업체의 장애 공지, 서버의 CPU·메모리·디스크 사용량을 확인한다. 서버는 정상인데 웹페이지만 느리다면 웹서버 오류 로그와 데이터베이스의 느린 질의를 본다. 디스크가 꽉 찼거나 연결 수가 한계에 걸린 문제는 재시작 후 잠깐 좋아졌다가 다시 나타나는 일이 많다.

복구 조치도 기록으로 남겨야 다음 장애가 빨라진다. 발생 시각, 사용자에게 보인 증상, 확인한 지표, 바꾼 설정, 정상화 시각을 짧게 적으면 된다. 개인 사이트에서는 비싼 이중화보다 백업 복원 연습과 알림 설정이 먼저일 때가 많다. 14년 동안 운영하면서 체감한 차이도 사양표보다 여기서 났다. 필요한 만큼의 서버를 쓰되, 멈췄을 때 어디부터 확인하고 얼마나 빨리 되돌릴 수 있는지는 분명히 해두는 편이 좋다.