클라우드플랫폼 서버 사양 계산하는 방법

얼마 전 월 방문자 10만 명인 사이트에 큰 서버를 권하는 견적을 봤습니다. 방문자 수만으로는 필요한 사양을 알 수 없는데, 메모리와 CPU부터 넉넉하게 올려 잡은 경우였죠. 14년간 서버를 운영하며 본 장애는 트래픽 자체보다 백업 누락, 잘못된 설정, 이전 중 데이터 불일치에서 더 자주 시작됐습니다. 클라우드플랫폼을 고를 때도 요금제 이름보다 실제 부하와 복구 방법을 먼저 봅니다.

월 방문자보다 바쁜 시간의 요청을 계산합니다

월 10만 페이지뷰를 30일로 나누면 하루 약 3,333회입니다. 다시 하루 전체로 나누면 초당 평균 0.04회도 안 됩니다. 그런데 평균값으로 서버를 고르면 출근 시간이나 홍보 직후의 급증을 놓칩니다. 접속 기록에서 가장 바쁜 5분의 페이지 요청 수를 확인하고, 그 구간의 초당 요청 수를 기준으로 잡는 편이 낫습니다.

화면 한 번을 열 때 발생하는 요청도 구분해야 합니다. 이미지와 자바스크립트를 캐시가 처리한다면 서버에 남는 일은 주로 HTML 생성과 API 호출입니다. 반대로 로그인, 검색, 장바구니처럼 매번 데이터베이스를 읽고 쓰는 화면은 같은 페이지뷰라도 부담이 큽니다. 검색 봇이 짧은 시간에 많은 URL을 훑는 경우도 사람 방문자 수와 따로 봐야 합니다.

예를 들어 바쁜 시간에 초당 동적 요청이 5건이고 서버 응답 시간이 0.4초라면, 동시에 처리 중인 요청은 평균 약 2건입니다. 계산식은 ‘초당 요청 수 × 처리 시간’입니다. 다만 평균이 2건이라는 뜻이지 최대 동시 요청이 2건이라는 뜻은 아닙니다. 짧은 순간의 몰림과 응답 지연을 감안해 여유를 남겨야 합니다.

CPU와 메모리는 서로 다른 기준으로 잡습니다

메모리는 프로세스별 사용량을 더하면 대략적인 하한이 나옵니다. 운영체제, 웹서버, 데이터베이스가 평소 1.2GB를 쓰고 요청 처리 프로세스가 하나당 120MB를 쓴다고 해보죠. 동시 처리 프로세스 6개를 허용하면 720MB가 더 필요합니다. 합계 1.92GB에 캐시와 일시적인 증가분을 남기면 2GB 요금제는 빠듯하고 4GB가 현실적인 출발점입니다. 이 숫자는 예시이므로 실제 프로세스 사용량은 운영할 서비스에서 측정해야 합니다.

CPU는 메모리처럼 단순히 더하기 어렵습니다. 이미지 변환, 검색, 압축, 무거운 쿼리는 요청 한 건이 코어를 오래 붙잡습니다. 먼저 작은 사양에서 실제 화면과 API를 대상으로 부하를 걸고, 바쁜 구간의 CPU 사용률과 응답 시간을 함께 봅니다. CPU가 계속 높고 응답 시간이 늘면 코어를 늘릴 근거가 생깁니다. CPU는 한가한데 응답만 늦다면 데이터베이스 쿼리, 외부 API, 디스크 대기를 먼저 확인합니다.

트래픽 요금도 같은 방식으로 계산할 수 있습니다. 페이지당 전송량이 1.5MB이고 월 10만 페이지뷰라면 사용자에게 전달하는 데이터는 약 150GB입니다. 이미지 캐시가 어느 정도 처리하는지에 따라 원본 서버의 전송량은 달라집니다. 월 요금을 비교할 때는 서버 기본료에 저장 공간, 백업 저장량, 외부 전송량, 유료 네트워크 기능을 더해 봅니다. 숫자를 넣어보면 무료나 저가 요금제로 충분한 사이트도 꽤 많습니다.

요금제보다 이전과 백업 절차를 먼저 확인합니다

저렴한 클라우드플랫폼이라도 데이터를 되살릴 수 없다면 운영 비용이 싼 게 아닙니다. 자동 백업이 켜져 있는지, 백업 파일이 서버와 다른 위치에 보관되는지, 몇 시점까지 되돌릴 수 있는지를 확인합니다. ‘백업 성공’ 알림만 믿지 말고 별도 환경에 한 번 복원해 로그인과 주요 데이터까지 확인해야 합니다. 복원에 걸린 시간도 기록해 두면 장애 때 기대할 수 있는 복구 시간을 알 수 있습니다.

이전할 때는 순서가 중요합니다. 기존 서버의 파일과 데이터베이스를 백업하고, 새 서버에서 설정과 SSL 인증서를 확인합니다. 주소 전환 전에 새 서버에서 로그인, 결제, 메일 발송, 파일 업로드를 실제로 시험합니다. 데이터가 계속 바뀌는 서비스라면 전환 직전에 쓰기 작업을 잠시 멈추거나 변경분을 동기화할 방법이 필요합니다. 파일만 복사하고 주소를 바꾸면 주문이나 게시물이 두 서버에 갈라져 남을 수 있습니다.

주소 전환 후에도 기존 서버를 바로 지우지 않습니다. 일부 방문자는 잠시 이전 서버로 접속할 수 있기 때문입니다. 오류율과 새 데이터의 저장 위치를 확인한 뒤 기존 서버를 내립니다. 되돌리는 상황을 대비해 이전 서버를 어느 시점까지 유지할지, 그동안 새로 생긴 데이터를 어떻게 처리할지도 전환 전에 정해 둡니다.

장애가 나면 확인 순서를 고정합니다

사이트가 열리지 않을 때 무작정 서버 사양을 올리면 원인을 가릴 수 있습니다. 저는 먼저 장애 범위를 봅니다. 전체 화면이 안 열리는지, 특정 기능만 실패하는지, 일부 지역이나 사용자에게만 생기는지 확인합니다. 그다음 주소 연결, SSL 인증서 유효기간, 방화벽과 보안 규칙, 웹서버와 애플리케이션 상태, 데이터베이스 연결, 디스크 여유 공간, 최근 배포와 설정 변경을 차례로 확인합니다.

특히 디스크가 꽉 차면 데이터베이스 쓰기와 로그 기록이 함께 멈출 수 있습니다. 백업이 같은 디스크에 쌓여 장애를 만든 사례도 봤습니다. CPU와 메모리 경보만 두지 말고 디스크 사용량, 인증서 만료일, 백업 실패, 복원 가능 여부까지 운영 점검 항목에 넣는 이유입니다.

서버를 고를 때 처음부터 큰 사양을 사는 것보다, 작은 사양에서 실제 부하를 측정하고 늘릴 조건을 정하는 편이 운영하기 쉽습니다. 그 조건 옆에는 백업을 어디서 어떻게 복원할지 적어 둡니다. 용량은 나중에 늘릴 수 있지만, 사라진 데이터는 그때 가서 살 수 없습니다.