모두
모두콘텐츠
얼마 전 방문자가 하루 3천 명인 사이트에서 서버를 두 배 큰 요금제로 올렸는데도 장애가 반복됐습니다. 원인은 서버 성능이 아니라 저장 공간을 가득 채운 백업 파일이었습니다. 클라우드로 옮기거나 사양을 높이기 전에, 지금 무엇이 부족한지부터 확인해야 돈도 덜 쓰고 장애도 줄일 수 있습니다.
클라우드가 필요한 상황부터 구분합니다
클라우드라는 이름만으로 사이트가 빨라지거나 장애에 강해지지는 않습니다. 작은 회사 소개 사이트처럼 방문이 일정하고 서버 설정을 직접 만질 일이 없다면 저가 웹호스팅으로 충분한 경우가 많습니다. 반면 프로그램 설치 권한이 필요하거나, 배포 방식을 직접 관리해야 하거나, 특정 시간에 사용량이 크게 뛰면 가상 서버나 클라우드 서버가 편합니다.
운영 책임도 함께 바뀝니다. 웹호스팅은 서버 운영의 상당 부분을 업체가 맡지만, 가상 서버를 빌리면 운영체제 보안 업데이트, 방화벽, 백업, 장애 대응을 직접 챙겨야 합니다. 관리형 상품은 이 일을 일부 대신해 주는 만큼 비용이 올라갑니다. 월 요금만 비교하면 빠뜨리기 쉬운 차이입니다.
서버 한 대를 클라우드에 올렸다고 자동으로 고가용성이 생기는 것도 아닙니다. 같은 서버에 웹 프로그램과 데이터베이스를 넣어 두면 그 서버가 멈출 때 둘 다 멈춥니다. 장애 대비가 필요하다면 복구 가능한 백업을 먼저 만들고, 실제 중단 허용 시간을 확인한 뒤 서버를 분리하는 편이 순서에 맞습니다.
방문자 수보다 피크 사용량을 봅니다
사양을 고를 때 월 방문자 수 하나만 보지는 않습니다. 하루 1만 페이지 조회가 있어도 24시간 고르게 들어오는 사이트와 점심시간 10분에 몰리는 사이트는 필요한 자원이 다릅니다. 접속 로그에서 가장 바쁜 5분과 1시간의 요청 수를 보고, 그때 CPU·메모리·데이터베이스 사용량이 얼마나 올랐는지 같이 봅니다.
예를 들어 한 페이지를 내려보내는 데 평균 1MB가 들고 하루 3만 페이지가 열리면, 전송량은 단순 계산으로 하루 약 30GB입니다. 30일이면 약 900GB입니다. 이미지 캐시나 별도 정적 파일 전송 서비스를 쓰면 원본 서버의 전송량은 줄 수 있지만, 서비스 전체에서 나가는 데이터가 사라지는 것은 아닙니다. 클라우드 요금표에서는 서버 가격과 함께 외부 전송량의 포함 범위와 초과 요금을 확인해야 합니다.
동시접속자 100명이라는 숫자도 그대로 서버 부하로 바꾸기 어렵습니다. 페이지를 읽고 있는 사람 100명과 매초 검색·주문 요청을 보내는 사람 100명은 전혀 다릅니다. 실제 병목은 요청 하나가 CPU를 얼마나 쓰는지, 데이터베이스 조회가 얼마나 오래 걸리는지, 캐시가 얼마나 맞는지에 따라 달라집니다.
처음부터 넉넉한 사양을 살 필요는 없습니다. 캐시가 적용된 작은 사이트라면 1~2개 가상 CPU와 2GB 안팎의 메모리에서 시작할 수도 있습니다. 다만 같은 서버에서 데이터베이스와 여러 작업 프로그램까지 돌린다면 메모리가 빨리 부족해질 수 있습니다. 배포 후 피크 시간의 메모리 여유, 저장 공간, 응답 시간을 확인하고 한 단계씩 늘리는 편이 정확합니다.
요금표에는 빠진 비용이 있습니다
월 서버 요금이 2만 원이어도 실제 청구액은 다를 수 있습니다. 디스크 용량, 스냅샷 보관량, 외부 전송량, 고정 주소, 관리형 데이터베이스 비용이 따로 붙는 상품이 있습니다. 특히 사진과 파일을 많이 내려주는 사이트는 CPU보다 전송량이 비용을 더 크게 좌우할 수 있습니다.
요금제를 비교할 때는 같은 조건으로 한 달 비용을 적어 봅니다. 서버 기본료에 예상 전송량, 백업 보관량, 추가 디스크 비용을 더하고, 업체가 맡아 주는 운영 작업도 확인합니다. 24시간 장애 대응이 필요한 서비스라면 서버를 직접 관리하는 데 드는 시간도 비용입니다. 반대로 개인 블로그나 초기 서비스에 여러 서버와 관리형 데이터베이스를 한꺼번에 붙이면 사용하지 않는 여유분에 계속 돈을 내게 됩니다.
자동 확장 기능 역시 조건을 봐야 합니다. 서버 대수를 늘려도 세션이나 업로드 파일이 한 서버에만 저장되면 사용자가 서버를 옮겨 갈 때 문제가 생깁니다. 부하가 늘어날 때 새 서버가 실제 요청을 받을 수 있는 구조인지 먼저 확인해야 합니다.
이전과 백업은 복구 기준으로 준비합니다
클라우드 이전에서 가장 조심할 부분은 파일 복사보다 데이터가 바뀌는 순간입니다. 새 서버를 준비해 프로그램 버전과 설정을 맞추고, 파일과 데이터베이스를 복사한 뒤 실제 화면과 로그인·주문 같은 쓰기 기능을 시험합니다. 최종 전환 직전에는 변경 작업을 잠시 멈추거나 데이터 동기화 방법을 정해 두어야 이전 중 들어온 기록을 잃지 않습니다.
도메인의 DNS 설정을 바꾸기 전에는 기존 서버로 돌아갈 방법을 남겨 둡니다. DNS 반영에는 사용자 환경에 따라 시간이 걸릴 수 있으므로, 전환 직후 기존 서버를 바로 끄면 일부 방문자는 오류를 볼 수 있습니다. 전환 당일에는 새 서버와 기존 서버의 접속 로그, 오류율, 데이터 증가량을 함께 확인하는 게 안전합니다.
백업 파일이 있다는 사실만으로는 안심하기 어렵습니다. 같은 서버의 같은 디스크에만 저장했다면 디스크 장애나 계정 문제 때 원본과 함께 사라질 수 있습니다. 데이터베이스와 업로드 파일을 각각 얼마나 자주 백업할지 정하고, 별도 위치에 보관한 뒤 복원 시험까지 해야 합니다. 하루에 한 번 백업하면 최악에는 하루치 변경 내용을 잃을 수 있습니다. 이 손실을 감당할 수 없다면 백업 간격을 줄여야 합니다.
장애가 나면 먼저 접속이 전부 끊겼는지, 특정 기능만 느린지 구분합니다. 이어서 최근 배포, CPU와 메모리, 디스크 사용량, 데이터베이스 연결 수, 오류 로그를 확인합니다. 서버 크기를 올리는 건 병목이 확인된 다음입니다. 14년 운영하면서 가장 자주 본 낭비는 작은 서버를 쓰는 일이 아니라, 원인을 모른 채 큰 서버로 옮기는 일이었습니다.
