모두
모두콘텐츠
얼마 전 기업홈페이지 이전을 도왔는데, 기존 서버는 월 트래픽에 비해 꽤 큰 사양이었습니다. 그런데도 문의가 몰리는 날이면 화면이 멈췄습니다. 원인은 서버 크기가 아니라 이미지 처리 방식과 데이터베이스 설정이었습니다. 기업홈페이지를 운영할 때는 요금제부터 고르기보다 방문량, 페이지 무게, 장애 시 복구 시간을 먼저 적어보는 편이 정확합니다.
방문자 수보다 몰리는 시간을 먼저 계산한다
월 페이지 조회 수가 3만 회라면 하루 평균은 약 1천 회입니다. 하루 조회 수의 30%가 가장 바쁜 한 시간에 몰린다고 잡아도 시간당 300회, 초당 약 0.08회입니다. 이 정도의 회사 소개 사이트라면 정적 페이지나 캐시가 적용된 웹호스팅으로도 충분한 경우가 많습니다. 월 조회 수만 보고 고사양 VPS를 계약할 이유는 적습니다.
다만 페이지 조회 수와 동시접속자는 같은 숫자가 아닙니다. 서버가 실제로 처리하는 요청 수는 한 페이지를 열 때 발생하는 요청 개수와 응답 시간에 따라 달라집니다. 예를 들어 서버가 처리해야 하는 요청이 초당 10개이고 평균 응답 시간이 0.5초라면, 동시에 처리 중인 요청은 대략 5개입니다. 이미지와 문서가 별도 저장 공간이나 캐시에서 제공되면 원본 서버의 부담은 더 줄어듭니다.
트래픽 비용도 페이지 무게로 계산해야 합니다. 평균 전송량이 페이지당 1MB이고 월 조회 수가 3만 회라면 단순 계산으로 약 30GB입니다. 4MB짜리 이미지 중심 페이지라면 같은 조회 수에서도 약 120GB가 됩니다. 실제 청구량은 캐시, 검색 로봇, 파일 다운로드에 따라 달라지므로 운영 중 전송량 기록을 한 달은 확인하는 게 좋습니다. 행사 공지나 채용 접수처럼 짧은 시간에 방문이 몰리는 일정도 따로 표시해 둡니다.
웹호스팅과 VPS는 운영할 사람까지 보고 고른다
회사 소개, 제품 안내, 문의 양식 정도가 중심이라면 관리형 웹호스팅부터 검토합니다. 서버 보안 업데이트와 기본 웹서버 관리에 쓰는 시간이 적습니다. 대신 실행 환경을 바꾸기 어렵고, CPU 사용량이나 동시 처리 수에 제한이 있을 수 있습니다. 계약 전에는 월 전송량뿐 아니라 자원 제한, 자동 백업 범위, 복구 요청 비용을 확인해야 합니다.
VPS는 특정 프로그램을 설치해야 하거나 배포 과정과 서버 설정을 직접 제어해야 할 때 적합합니다. 관리 책임도 함께 넘어옵니다. 운영체제 패치, 방화벽, 로그, 인증서 갱신, 백업 실패 알림을 맡을 사람이 없다면 월 이용료가 저렴해 보여도 실제 비용은 커집니다. 콘텐츠 관리 시스템과 데이터베이스를 한 서버에서 운영한다면 메모리 사용량을 먼저 측정하고 여유를 둡니다. 방문량이 적어도 플러그인이 많거나 이미지 변환 작업이 잦으면 작은 서버에서 메모리가 먼저 부족해질 수 있습니다.
클라우드 서버도 이름만으로 자동 확장되는 것은 아닙니다. 서버 한 대를 클라우드에서 빌렸다면 그 한 대가 멈출 때 서비스도 멈춥니다. 여러 대로 나누려면 세션, 파일 저장, 데이터베이스 연결 방식까지 맞춰야 합니다. 초기 기업홈페이지에는 이런 구성이 과할 수 있습니다. 먼저 현재 요금제에서 CPU, 메모리, 응답 시간 중 무엇이 한계인지 확인한 뒤 확장을 결정하는 편이 낫습니다.
이전 전에 복구 가능한 백업을 만든다
홈페이지 이전에서 가장 자주 빠지는 것은 파일 이외의 데이터입니다. 게시물과 문의 내역이 담긴 데이터베이스, 업로드 파일, 환경 설정, 예약 작업, 메일 수신 설정을 목록으로 적습니다. 문의 양식이 메일만 보내는 구조라면 이전 직후 실제 수신까지 시험해야 합니다. 화면이 정상으로 보여도 문의가 유실되는 사고는 뒤늦게 발견되기 쉽습니다.
백업 파일은 운영 서버 밖에도 보관합니다. 같은 서버의 다른 폴더에만 두면 디스크 장애나 계정 침해 때 함께 잃을 수 있습니다. 파일과 데이터베이스를 같은 시점에 확보하고, 별도 환경에서 한 번 복원해 봅니다. 복원 시험을 해야 누락된 업로드 파일이나 오래된 데이터베이스 백업을 발견할 수 있습니다. 백업이 있다는 표시보다 복원에 성공한 날짜가 더 유용합니다.
이전 당일에는 기존 사이트의 변경을 잠시 멈추고 최종 데이터를 복사합니다. 새 서버에서 화면, 관리자 로그인, 문의 전송, 인증서 적용을 확인한 뒤 접속 대상을 바꿉니다. DNS 설정의 TTL을 미리 낮춰 둘 수는 있지만, 모든 방문자의 전환 시각이 정확히 같아지지는 않습니다. 그래서 기존 서버를 즉시 지우지 않고 접속 기록을 보며 일정 기간 유지합니다. 다시 이전 서버로 돌려야 할 때 어떤 데이터까지 되돌릴지 역시 작업 전에 정해야 합니다.
장애가 나면 접속 경로를 순서대로 확인한다
접속이 안 된다는 연락을 받으면 우선 모든 방문자에게 같은 증상인지 확인합니다. 한 사무실에서만 안 된다면 내부 네트워크나 DNS 캐시 문제일 수 있습니다. 여러 곳에서 접속이 안 되면 도메인 만료 여부, DNS 응답, 인증서 상태, 서버 연결, 웹서버와 애플리케이션 로그 순서로 범위를 좁힙니다. 화면에 오류가 표시되는지, 연결 자체가 실패하는지에 따라 시작점이 달라집니다.
- 연결 자체가 안 되면 DNS, 방화벽, 서버 상태를 확인합니다.
- 보안 경고가 뜨면 인증서 유효기간과 적용 대상을 확인합니다.
- 화면은 열리는데 느리면 응답 시간, CPU, 메모리, 데이터베이스의 느린 쿼리를 봅니다.
- 일부 기능만 실패하면 최근 배포 내용과 해당 기능의 오류 로그를 확인합니다.
장애 중에는 무작정 서버를 재시작하기보다 발생 시각과 최근 변경 사항을 먼저 기록하는 편이 좋습니다. 재시작으로 잠시 살아나도 원인이 남아 있으면 같은 일이 반복됩니다. 기업홈페이지는 큰 서버보다 현재 규모에 맞는 사양, 검증된 복원 절차, 연락이 왔을 때 바로 볼 수 있는 기록이 운영을 훨씬 편하게 만듭니다.
