모두
모두콘텐츠
얼마 전 방문자가 조금 늘었다는 이유로 서버를 두 단계 올린 사이트를 봤습니다. 그런데 느려진 원인은 사양이 아니라 쌓여 있던 백업 파일이었습니다. 디스크를 비우고 백업 저장 위치를 바꾸자 응답 속도가 돌아왔습니다. 서버를 고를 때는 요금제보다 먼저 병목이 어디서 생길지 계산해야 합니다.
월 방문자보다 바쁜 시간의 요청을 본다
월간 페이지 조회 수만으로 서버를 고르면 과하게 사기 쉽습니다. 예를 들어 하루 3천 페이지를 읽는 사이트라면 평균은 초당 약 0.035페이지입니다. 가장 바쁜 시간에 평균보다 20배 몰린다고 잡아도 초당 약 0.7페이지입니다. 페이지 처리에 2초가 걸린다면 동시에 처리 중인 페이지 요청은 대략 1~2개입니다. 물론 한 페이지가 이미지나 스크립트 요청을 여러 개 만들고, 검색 로봇이나 예약 작업도 들어옵니다. 그래서 이 숫자는 구매 사양이 아니라 출발점입니다.
전송량도 따로 계산합니다. 방문자가 받는 페이지 한 건이 평균 1메가바이트이고 한 달에 9만 건을 읽는다면 약 90기가바이트입니다. 이미지가 큰 사이트는 이 값이 금방 늘고, 캐시가 잘 잡힌 사이트는 원본 서버가 처리하는 양이 줄어듭니다. 요금제의 월 전송량과 순간 대역폭 제한을 함께 봐야 하는 이유입니다. 월 전송량이 넉넉해도 짧은 시간의 요청 수를 제한하는 상품이 있습니다.
실제 운영 중이라면 일주일 정도 CPU 사용률, 메모리 부족 기록, 디스크 사용량, 응답 시간을 시간대별로 남기는 편이 정확합니다. 방문자가 적은데 응답이 느리다면 사양을 올리기 전에 느린 데이터베이스 질의, 캐시 누락, 외부 서비스 응답 대기를 먼저 확인합니다.
웹호스팅과 VPS는 운영 방식으로 고른다
개인 블로그나 작은 회사 소개 사이트는 공유 웹호스팅으로 충분한 경우가 많습니다. 서버 업데이트와 기본 관리 부담이 적고 비용도 낮습니다. 다만 실행 시간, 작업 예약, 서버 설정을 직접 바꿔야 한다면 제약을 먼저 확인해야 합니다. 특정 프로그램을 상시 실행하거나 웹서버 설정을 세밀하게 조정해야 할 때 VPS가 편해집니다.
VPS에서 메모리는 특히 빠듯해지기 쉽습니다. 운영체제, 웹서버, 데이터베이스가 기본으로 메모리를 쓰고, 동적 페이지를 처리하는 작업자가 늘 때마다 사용량이 더 붙습니다. 작업자 하나가 100메가바이트를 쓰고 여덟 개가 뜨면 그것만 약 800메가바이트입니다. 데이터베이스까지 같은 서버에 둔다면 메모리 2기가바이트는 구성을 꽤 절제해야 하고, 4기가바이트부터 운영 여유를 잡기 쉽습니다. 프로그램과 데이터 크기에 따라 달라지므로 이 수치를 보장된 기준으로 받아들이면 곤란합니다.
클라우드 서버의 장점은 필요할 때 자원을 늘리고 구성을 나누기 쉽다는 점입니다. 하지만 작은 사이트에서 자동 확장, 별도 데이터베이스, 여러 서버를 처음부터 묶으면 관리할 항목과 비용이 함께 늘어납니다. 트래픽이 일정하고 서버 한 대로 충분하다면 저가 VPS나 웹호스팅이 더 실용적일 수 있습니다. 사양을 올릴 시점은 CPU가 바쁜 시간에 지속해서 포화되거나, 메모리 부족으로 작업이 종료되거나, 저장 장치 대기 때문에 응답이 밀린다는 기록이 쌓였을 때입니다.
서버 이전은 복구 순서까지 적어 둔다
이전 작업에서 가장 자주 빠지는 것은 파일보다 데이터베이스와 설정입니다. 웹 파일, 데이터베이스, 업로드 파일, 작업 예약, 환경 설정, SSL 인증서의 발급 방식까지 목록으로 만들어야 합니다. 새 서버에는 먼저 같은 실행 환경을 구성하고, 데이터를 복사한 뒤 접속 대상을 바꾸기 전에 내부 테스트를 합니다. 화면 한 장이 뜬다고 끝난 게 아닙니다. 로그인, 글 작성, 파일 업로드, 메일 발송처럼 실제로 데이터를 바꾸는 기능을 확인해야 합니다.
접속 대상을 바꾸는 날에는 이전 서버를 바로 지우지 않는 편이 안전합니다. 주소 변경 정보가 각 사용자 환경에 반영되는 시간은 다를 수 있습니다. 변경 직전 데이터베이스를 다시 복사하고, 두 서버에 동시에 글이 쓰이지 않도록 쓰기 경로를 정해야 합니다. 되돌릴 조건과 담당자도 작업 전에 적어 둡니다. 이전 후 오류가 나서야 복귀 절차를 생각하면 데이터가 어느 쪽에 남았는지부터 다시 확인해야 합니다.
백업은 서버 안에 파일 하나 더 두는 것으로 끝나지 않습니다. 서버 디스크가 손상되거나 계정이 잠기면 그 파일도 함께 잃을 수 있습니다. 데이터베이스는 변경 빈도에 맞춰 매일 또는 더 자주 저장하고, 업로드 파일과 설정은 별도 저장소에도 보관합니다. 보관 기간은 실수로 삭제한 사실을 알아차리는 데 걸리는 시간보다 길어야 합니다. 한 달에 한 번은 백업으로 시험 서버를 복원해 로그인과 주요 기능까지 확인합니다. 복원해 본 적 없는 백업은 소요 시간도, 빠진 데이터도 알 수 없습니다.
장애가 나면 확인 순서를 고정한다
사이트가 열리지 않을 때 무작정 서버부터 재시작하면 원인을 가리는 경우가 있습니다. 먼저 이용자 모두에게 같은 증상인지 확인하고, 도메인 설정과 SSL 인증서 상태를 봅니다. 그다음 서버 접속 가능 여부, 웹서버 상태, 애플리케이션 오류 기록, 데이터베이스 연결을 차례로 확인합니다. 디스크가 가득 찼는지, 메모리 부족으로 프로세스가 종료됐는지, 직전 배포나 설정 변경이 있었는지도 함께 봅니다.
- 접속 자체가 안 되면 도메인 설정, 네트워크, 서버 상태를 확인한다.
- 접속은 되지만 오류 화면이 나오면 웹서버와 애플리케이션 기록을 확인한다.
- 화면은 뜨지만 느리면 응답 시간, 데이터베이스 질의, 저장 장치 대기를 확인한다.
- 일부 기능만 실패하면 최근 변경 사항과 해당 기능의 기록을 확인한다.
서버 사양은 운영하면서 조정할 수 있습니다. 반면 복구 절차가 없는 상태에서 잃어버린 데이터는 사양을 올려도 돌아오지 않습니다. 저는 처음 서버를 고를 때 남는 CPU 한 칸보다, 백업을 어디에 두고 얼마나 빨리 복원할 수 있는지를 먼저 묻습니다.
