아마존클라우드 서버 사양과 비용 계산하는 방법

얼마 전 작은 쇼핑몰의 서버 이전을 도왔는데, 월 방문자는 많지 않은데도 고사양 인스턴스를 쓰고 있었다. 이유를 물으니 행사 때 접속이 몰릴까 봐서라고 했다. 로그를 보니 병목은 CPU가 아니라 이미지 용량과 느린 데이터베이스 쿼리였다. 서버를 키우기 전에 사용량부터 재는 편이 돈도 아끼고 장애 원인도 빨리 찾는다.

월 방문자보다 최대 요청량을 먼저 본다

아마존클라우드에서 웹사이트를 운영한다면 월 방문자 수만으로 서버 크기를 고르기 어렵다. 하루 1만 명이 고르게 들어오는 사이트와 10분 동안 5천 명이 몰리는 사이트는 필요한 사양이 다르다. 웹서버 로그에서 가장 바쁜 5분의 초당 요청 수, 응답 시간, CPU와 메모리 사용량을 함께 봐야 한다.

예를 들어 가장 바쁜 시간에 초당 요청이 5개이고 서버 처리 시간이 평균 0.3초라면, 동시에 처리 중인 요청은 대략 1.5개다. 여기에 관리 화면, 검색, 주문처럼 오래 걸리는 요청이 섞이면 순간 동시 처리량은 더 높아진다. 이 계산은 출발점일 뿐이다. 이미지와 파일을 서버가 직접 보내는지, 캐시가 얼마나 맞는지에 따라 필요한 자원은 크게 달라진다.

새 사이트라 로그가 없다면 작은 구성에서 시작해 실제 수치를 모으는 게 낫다. 정적 페이지 위주라면 저가형 호스팅이나 정적 사이트 서비스로 충분할 수 있다. 워드프레스와 데이터베이스를 한 서버에 올린다면 메모리 2GB 안팎을 첫 검토 대상으로 삼되, 플러그인과 작업 프로그램까지 띄운 뒤 남는 메모리를 확인해야 한다. 2GB가 모든 사이트의 권장 사양이라는 뜻은 아니다. 메모리가 계속 부족해 디스크 교환이 발생하면 그때 증설 근거가 생긴다.

인스턴스 값에 저장소와 전송량을 더한다

EC2 화면에 보이는 시간당 요금만 730시간 곱해서 월 비용으로 잡으면 실제 청구액과 차이가 난다. EBS 저장소, 스냅샷, 인터넷으로 나가는 데이터, 공인 IPv4 주소도 함께 계산해야 한다. 도메인과 유료 관리 서비스까지 쓴다면 별도 항목으로 넣는다. 리전과 운영체제, 구매 방식에 따라 단가가 달라지므로 견적을 낼 때 같은 조건으로 맞춰 비교한다.

전송량은 방문자가 아니라 페이지 크기로 가늠한다. 한 번 열 때 평균 2MB가 내려가는 페이지가 월 10만 번 조회되면 단순 계산으로 약 200GB다. 이미지가 대부분이라면 압축과 캐시 적용만으로 서버 부담과 전송량을 함께 줄일 수 있다. 반대로 동영상 파일을 직접 제공한다면 서버 CPU가 한가해 보여도 전송 비용이 커질 수 있다. 무료 사용 범위가 있는 계정이라도 그 범위가 영구적이거나 모든 항목에 적용된다고 가정하면 안 된다.

AWS 문서 기준으로 T 계열 인스턴스는 CPU 사용량이 낮을 때 크레딧을 쌓고, 일시적으로 바쁠 때 이를 사용한다. 짧은 피크가 있는 블로그에는 잘 맞지만 배치 작업이나 이미지 변환으로 CPU가 오래 높은 상태라면 크레딧과 추가 요금을 살펴야 한다. 서버를 중지하면 인스턴스 사용 요금은 멈춰도 EBS 저장소 비용은 계속 발생한다. 테스트 서버를 껐으니 비용도 0원일 거라고 생각하기 쉬운 지점이다.

백업은 생성보다 복구 시간을 확인한다

운영 중 가장 자주 보는 실수는 스냅샷 하나를 만든 뒤 백업이 끝났다고 여기는 것이다. AWS는 EBS 데이터를 사용자가 직접 주기적으로 백업하거나 자동화해야 한다고 안내한다. 스냅샷은 디스크의 특정 시점을 담지만, 데이터베이스가 쓰기 작업 중이었다면 애플리케이션 수준에서 일관된 상태로 복원된다는 보장은 없다. 데이터베이스 백업을 따로 만들거나 쓰기 작업을 잠시 멈춘 상태에서 스냅샷을 떠야 한다.

운영 절차에는 백업 주기와 보관 기간뿐 아니라 복구 목표도 적는다. 하루 한 번 백업하면 최악의 경우 하루치 변경분을 잃을 수 있다. 주문이나 회원 데이터처럼 손실 허용 범위가 짧다면 그에 맞춰 백업 간격을 줄여야 한다. 매달 한 번은 별도 서버에 복원해 로그인, 주요 화면, 데이터베이스 연결을 확인한다. 백업 파일이 있다는 사실보다 실제로 몇 분 안에 서비스를 다시 열 수 있는지가 더 중요하다.

이전과 장애 대응은 순서를 정해 둔다

서버를 옮길 때는 새 환경에 웹서버 설정과 SSL 인증서를 먼저 준비하고, 파일과 데이터베이스를 복사한 뒤 임시 접속 경로에서 기능을 검사한다. 전환 직전에는 기존 사이트의 쓰기 작업을 멈추고 마지막 변경분을 옮긴다. 그다음 DNS를 변경한다. 이전 서버는 곧바로 지우지 말고 일정 기간 로그와 데이터 차이를 확인한다. DNS 변경만으로 데이터가 새 서버에 동기화되지는 않는다.

장애가 나면 무작정 인스턴스 크기부터 올리지 않는다. 먼저 접속 자체가 안 되는지, 접속은 되지만 화면이 느린지 구분한다. 전자라면 DNS, 방화벽 규칙, 인스턴스 상태, 웹서버 실행 여부를 순서대로 확인한다. 후자라면 CPU와 남은 메모리, 디스크 여유, 데이터베이스 연결 수, 최근 배포와 오류 로그를 본다. CPU가 낮은데 응답이 느리다면 쿼리 대기나 외부 서비스 지연일 수도 있다.

아마존클라우드는 필요한 만큼 조절할 수 있어 편하지만, 그만큼 비용과 복구 절차를 직접 챙겨야 한다. 작은 사이트라면 처음부터 큰 구성을 살 이유가 드물다. 사용량을 기록하고 백업을 실제로 복원해 본 다음, 부족하다는 수치가 나올 때 서버를 키우는 방식이 운영하기에도 편했다.