클라우드종류 고를 때 서버 사양부터 계산하는 방법

얼마 전 월 방문자 3만 명인 사이트가 클라우드 서버를 세 대 쓰고 있다는 이야기를 들었다. 접속 기록을 보니 가장 바쁜 시간에도 초당 요청은 한 자릿수였다. 장애 원인은 서버 성능이 아니라 백업 저장 공간이 꽉 차서 데이터베이스가 멈춘 것이었다. 클라우드종류를 고를 때는 이름보다 운영 범위와 실제 부하부터 확인하는 편이 낫다.

먼저 누가 서버를 관리하는지 구분한다

클라우드 서비스는 관리 책임에 따라 IaaS, PaaS, SaaS로 나눠 볼 수 있다. IaaS는 가상 서버와 저장소, 네트워크를 빌리는 방식이다. 운영체제 업데이트, 웹서버 설정, 방화벽, 백업은 대체로 이용자가 맡는다. 익숙한 VPS를 운영하는 일과 비슷하다. 설정 자유도가 높지만 새벽 장애도 직접 처리해야 한다.

PaaS는 애플리케이션 실행 환경을 제공한다. 코드를 올리면 배포와 실행 환경의 상당 부분을 서비스가 관리한다. 개발 인력이 적고 서버 관리 시간을 줄이고 싶다면 편하다. 다만 지원 언어, 실행 시간, 데이터베이스 연결 방식에 제약이 있을 수 있다. SaaS는 메일이나 협업 도구처럼 완성된 소프트웨어를 사용하는 형태다. 웹사이트의 서버를 직접 구성하려는 사람에게는 보통 비교 대상이 아니다.

일반 웹호스팅도 빼놓을 이유가 없다. 워드프레스나 작은 회사 소개 사이트라면 공유 호스팅에서 시작해도 충분한 경우가 많다. 운영체제에 손댈 필요가 없고, 제공 범위 안에서 백업과 보안 업데이트를 처리할 수 있다면 관리 부담도 작다. 반대로 특정 확장 모듈이나 상주 프로세스가 필요하면 VPS나 IaaS가 맞는다. 월 요금만 비교하지 말고 관리에 쓰는 시간도 비용으로 넣어야 한다.

퍼블릭·프라이빗·하이브리드는 다른 구분이다

퍼블릭 클라우드는 사업자의 공용 인프라에서 필요한 자원을 빌려 쓴다. 작은 서버 한 대로 시작해 저장소나 데이터베이스를 따로 붙일 수 있다. 프라이빗 클라우드는 특정 조직이 전용으로 쓰는 환경이다. 장비와 운영 인력을 확보해야 해서 작은 블로그나 쇼핑몰에는 대개 과하다. 하이브리드는 자체 환경과 퍼블릭 클라우드를 연결해 함께 운영하는 방식이다.

이 구분을 IaaS·PaaS와 섞으면 선택이 흐려진다. 퍼블릭 클라우드에서도 가상 서버를 직접 관리할 수 있고, 관리형 실행 환경을 쓸 수도 있다. 서버 한 대를 다른 회사 장비로 옮겼다고 자동으로 장애 대응이 쉬워지는 것도 아니다. 데이터베이스와 파일 저장 위치, 장애 때 담당할 사람까지 정해져 있어야 운영 방식이 완성된다.

트래픽은 월 방문자보다 바쁜 시간으로 계산한다

사양을 잡을 때 월 방문자 수만 보면 쉽게 과하게 산다. 예를 들어 하루 1만 페이지 조회에 페이지당 전송량이 2MB라면 하루 약 20GB, 30일 기준 약 600GB다. 이미지 최적화와 캐시 적용 여부에 따라 실제 전송량은 크게 달라진다. 먼저 접속 기록에서 가장 바쁜 한 시간의 요청 수, 데이터 전송량, 응답 시간을 확인한다.

초당 요청 수와 동시접속 수도 구분해야 한다. 방문자 100명이 페이지를 열어 두었다고 서버가 요청 100개를 계속 처리하는 것은 아니다. 반대로 한 페이지가 여러 이미지와 API를 동시에 부르면 짧은 순간에 요청이 몰린다. 웹서버의 활성 요청 수, CPU 사용률, 메모리 잔량, 데이터베이스의 느린 질의를 함께 봐야 한다.

작은 콘텐츠 사이트라면 캐시를 켠 1~2 vCPU, 메모리 1~2GB부터 검증할 수 있다. 어디까지나 출발점이다. 워드프레스의 무거운 플러그인이나 이미지 변환 작업이 있으면 메모리가 먼저 부족해질 수 있다. 주문·로그인처럼 캐시하기 어려운 요청이 많다면 CPU보다 데이터베이스 연결 수와 질의 시간이 먼저 한계에 닿기도 한다. 서버를 키우기 전 실제 병목을 확인하는 이유다.

이전과 백업 절차가 요금제보다 먼저다

서버를 옮길 때는 새 서버를 만든 뒤 데이터베이스와 업로드 파일을 복사하고, 테스트 환경에서 기능을 확인한다. 게시글이나 주문이 계속 들어오는 사이트라면 마지막 동기화 시점을 따로 잡아야 한다. 이전 중에 원본과 새 서버 양쪽에 쓰기가 발생하면 데이터가 갈라진다. 전환 직전에는 쓰기를 잠시 멈추거나, 복제 상태를 확인한 뒤 한쪽만 쓰도록 바꾼다.

백업은 파일이 생성됐다는 알림만으로 끝나지 않는다. 데이터베이스와 업로드 파일을 같은 시점에 복원할 수 있어야 하고, 서버와 다른 저장 위치에 사본이 있어야 한다. 적어도 한 번은 별도 환경에서 복원해 로그인과 주요 기능을 확인한다. 복원에 두 시간이 걸린다면 장애 복구 목표를 10분으로 잡을 수는 없다.

장애가 나면 먼저 서비스 전체가 죽었는지, 특정 기능만 실패하는지 나눈다. 이어 최근 배포와 설정 변경, 저장 공간, 메모리, 웹서버·데이터베이스 기록 순서로 확인한다. 새 클라우드종류로 옮긴 직후라면 방화벽 규칙과 저장소 권한도 살핀다. 제 경험상 서버를 한 단계 올리는 일보다 이 확인 순서와 복원 절차를 문서로 남기는 일이 사이트를 더 오래 살린다.