모두
모두콘텐츠
얼마 전 하루 방문자가 200명쯤 되는 사이트의 서버 이전을 도왔는데, 운영 중인 VPS 사양이 8코어에 메모리 16GB였습니다. 느린 원인은 서버 성능이 아니었습니다. 이미지가 너무 컸고, 백업 작업이 영업시간에 데이터베이스를 오래 붙잡고 있었죠. 웹사이트개발 단계에서 서버를 고를 때는 방문자 수만 보지 말고, 페이지가 어떻게 만들어지고 언제 요청이 몰리는지부터 확인하는 편이 낫습니다.
방문자 수를 서버 부하로 바꾸는 방법
월 방문자 1만 명이라는 숫자만으로는 서버 사양을 정하기 어렵습니다. 한 사람이 페이지를 몇 번 보는지, 페이지를 열 때 서버가 몇 번 일하는지, 그 요청이 어느 시간대에 몰리는지가 더 중요합니다. 운영 중인 사이트라면 일주일 정도 접속 기록에서 시간당 최대 페이지 조회수와 응답 시간을 봅니다. 새 사이트라면 예상치를 적고 출시 후 실측값으로 바꿔야 합니다.
예를 들어 하루 1만 페이지 조회가 있고, 가장 바쁜 한 시간에 그중 10%가 몰린다고 가정해 봅시다. 그 시간에는 1,000페이지 조회, 초당 평균 약 0.28회입니다. 페이지 하나가 서버에 동적 요청 6개를 보낸다면 평균 약 1.7요청/초가 됩니다. 여기에 순간 유입을 고려해 5배를 잡으면 약 8.5요청/초입니다. 이 정도 수치라면 먼저 캐시 설정과 요청당 처리 시간을 확인할 일이지, 곧바로 큰 서버를 계약할 이유는 없습니다.
동시접속자도 구분해서 봐야 합니다. 화면을 읽고 있는 사람 100명과 서버가 동시에 처리 중인 요청 100개는 전혀 다른 부하입니다. 응답에 0.5초가 걸리는 요청이 초당 8개 들어오면, 단순 계산으로 동시에 처리 중인 요청은 평균 4개 안팎입니다. 다만 결제, 검색, 대용량 업로드처럼 처리 시간이 긴 기능은 평균값에서 튀어나옵니다. 이런 기능은 별도로 시험해야 합니다.
호스팅 종류는 사이트가 하는 일에 맞춘다
회사 소개나 문서처럼 내용이 자주 바뀌지 않는 사이트라면 정적 호스팅의 무료 또는 저가 구간으로도 충분한 경우가 많습니다. 서버에서 페이지를 매번 만들 필요가 없으니 운영할 프로세스도 적습니다. 블로그나 소규모 예약 사이트는 공유 웹호스팅으로 시작할 수 있습니다. 관리 화면이 있고 데이터베이스 백업도 제공된다면, 직접 VPS를 운영하는 것보다 손이 덜 갑니다.
VPS는 서버 설정을 직접 제어해야 하거나 상시 실행되는 작업이 있을 때 의미가 있습니다. 작은 동적 사이트라면 2가상 CPU와 메모리 2~4GB를 시험 출발점으로 삼을 수 있지만, 데이터베이스와 웹서버를 한 대에 올리고 플러그인까지 많다면 2GB는 금방 빠듯해집니다. 요금표의 CPU 숫자보다 실제 접속 기록, 메모리 사용량, 디스크 입출력 대기 시간을 보고 올리는 게 정확합니다. 관리형 서비스를 쓰면 운영 시간을 줄일 수 있지만, 그 비용도 요금제 비교에 넣어야 합니다.
전송량은 별도로 계산합니다. 페이지당 내려가는 파일이 평균 2MB이고 하루 1,000페이지 조회라면 방문자에게 전달되는 데이터는 하루 약 2GB, 한 달 약 60GB입니다. 이미지를 절반으로 줄이면 이 수치도 크게 줄어듭니다. 캐시나 콘텐츠 전송망을 쓰면 원본 서버의 전송량은 달라지지만 방문자가 받는 파일 크기 자체가 사라지는 것은 아닙니다. 계약 전에는 저장 공간뿐 아니라 전송량 초과 시 속도 제한이나 추가 요금이 어떻게 붙는지 확인해야 합니다.
이전보다 복구 절차를 먼저 만든다
웹사이트개발이 끝나갈 때 가장 자주 빠지는 게 복구 시험입니다. 파일만 복사해 두고 데이터베이스, 업로드 파일, 환경 설정, 인증서 갱신 방법을 빠뜨리면 장애 때 복원이 안 됩니다. 백업은 최소한 데이터베이스와 사용자 업로드를 포함하고, 서버와 다른 저장 위치에 보관합니다. 서버 내부 스냅샷은 빠른 되돌리기에 유용하지만 같은 계정이나 저장소에 문제가 생기면 함께 영향을 받을 수 있습니다.
백업 주기는 잃어도 되는 데이터의 양으로 정합니다. 하루치 주문을 잃으면 안 되는 서비스에 하루 한 번 백업은 부족합니다. 반면 한 달에 한 번 수정하는 소개 페이지는 매시간 데이터베이스 백업이 필요하지 않을 수 있습니다. 복구에 허용되는 시간도 적어 둡니다. 백업 파일이 있어도 새 서버에서 복원하는 데 반나절이 걸린다면, 1시간 안에 서비스를 다시 열겠다는 목표와 맞지 않습니다. 분기마다 한 번은 별도 환경에 실제로 복원해 보는 편이 안전합니다.
서버를 옮길 때는 새 환경에서 기능을 먼저 확인하고, 변경이 잦은 데이터는 마지막 동기화 시점을 정해야 합니다. 전환 전에 DNS 기록의 유효 시간을 낮추고, 전환 후에는 옛 서버를 바로 지우지 않습니다. 접속 경로에 따라 잠시 옛 서버로 들어오는 이용자가 있을 수 있기 때문입니다. 이 기간에 양쪽에서 주문이나 게시글이 따로 쌓이면 데이터가 갈라집니다. 쓰기 중지 시간이나 단일 데이터베이스 사용 계획을 미리 잡아야 합니다.
사이트가 멈추면 확인할 순서
장애가 나면 서버부터 재시작하고 싶은 마음이 듭니다. 근데 재시작은 원인을 보여 주던 기록을 흐리게 만들 수 있습니다. 먼저 여러 접속 환경에서 같은 증상인지 확인합니다. 그다음 도메인 연결, 인증서 유효 기간, 웹서버 응답, 애플리케이션 기록, 데이터베이스 연결, 디스크 여유 공간 순으로 좁혀 갑니다. 접속 자체가 안 되는 문제와 접속은 되지만 화면이 느린 문제는 출발점이 다릅니다.
느려졌다면 CPU 사용률 하나만 보지 않습니다. 메모리 부족으로 저장장치를 임시 메모리처럼 쓰는지, 데이터베이스 쿼리가 오래 걸리는지, 디스크가 가득 차 로그를 쓰지 못하는지 확인합니다. 특정 배포 직후라면 변경 사항을 되돌릴 수 있는지도 봅니다. 평소 응답 시간과 오류율을 기록해 두면 장애 때 어느 지점부터 달라졌는지 금방 보입니다.
서버 비용은 사양을 낮출 때보다 운영을 예측할 수 있을 때 잘 줄어듭니다. 처음에는 감당할 수 있는 작은 구성으로 시작하고, 트래픽 기록과 복구 시험 결과를 근거로 필요한 부분만 늘리는 방식이 오래 갑니다.
