모두
모두콘텐츠
얼마 전 하루 방문자가 300명쯤 되는 사이트의 서버 이전을 도왔다. 월 요금이 꽤 나가는 클라우드 서버를 쓰고 있었는데, 접속 기록을 보니 CPU가 바쁜 시간은 거의 없었다. 정작 위험한 부분은 사양이 아니라 같은 서버에만 남아 있는 백업 파일이었다. 웹서버를 고를 때는 방문자 수보다 요청량, 메모리 사용량, 복구 방법을 먼저 보는 편이 정확하다.
방문자 수를 요청량으로 바꿔 계산하기
하루 페이지 조회 수가 1만 회인 사이트를 예로 들어보자. 하루 평균은 초당 약 0.12페이지다. 가장 붐비는 시간대가 평균의 5배라면 초당 약 0.6페이지다. 숫자만 보면 작다. 하지만 페이지를 열 때 이미지와 스크립트까지 20개 파일을 요청한다면 순간 요청은 초당 12건 안팎이 될 수 있다. 정적 파일을 캐시로 처리하는지에 따라 웹서버가 실제로 해야 할 일은 크게 달라진다.
동시접속자와 동시에 처리 중인 요청도 구분해야 한다. 100명이 페이지를 읽고 있어도 서버가 100개 요청을 계속 처리하는 것은 아니다. 초당 12건이 들어오고 각 요청이 평균 0.2초 걸린다면 동시에 처리 중인 요청은 대략 2~3건이다. 반대로 느린 데이터베이스 조회가 5초씩 걸리면 같은 요청량에서도 수십 건이 쌓인다. 이때 서버를 키우기 전에 느린 조회부터 확인해야 한다.
전송량도 계산해 둔다. 페이지 한 번을 여는 데 실제로 1MB가 나가고 하루 1만 회 열리면 하루 약 10GB, 30일이면 약 300GB다. 이미지 최적화나 캐시 설정에 따라 이 값은 쉽게 달라진다. 요금제의 저장 공간과 월 전송량은 별개 항목이므로 둘 다 확인해야 한다.
작은 사이트에 맞는 사양과 설정
정적 페이지나 캐시가 잘 되는 작은 블로그라면 저가 웹호스팅으로 충분한 경우가 많다. 서버 설정을 직접 바꿀 필요가 없다면 운영 부담도 적다. 반면 백그라운드 작업을 돌리거나 웹서버 설정을 직접 만져야 한다면 VPS가 맞을 수 있다. 이 경우 트래픽이 적은 정적 사이트는 1개 가상 CPU와 메모리 1GB부터 시험할 수 있다. 데이터베이스와 동적 애플리케이션을 한 서버에 함께 올린다면 메모리 2GB 이상에서 시작해 실제 사용량을 보는 편이 안전하다. 특정 사양을 모든 사이트의 기준으로 삼을 수는 없다.
메모리는 특히 여유를 남겨야 한다. 운영체제, 웹서버, 애플리케이션, 데이터베이스가 각자 메모리를 쓴다. 평소 사용량이 전체의 90%에 붙어 있다면 업데이트나 일시적인 요청 증가 때 프로세스가 종료될 수 있다. 운영 초기에는 CPU 평균보다 메모리 최대 사용량, 저장 공간 증가 속도, 응답 시간의 변화를 더 자주 본다.
설정은 기본값 그대로 두기 쉬운 부분부터 점검한다. 웹서버가 받을 요청과 본문 크기에 제한을 두고, 로그가 디스크를 가득 채우지 않도록 순환 보관한다. 관리자 접속은 필요한 계정으로 제한하고, 보안 업데이트를 적용할 시간을 정한다. SSL 인증서는 설치 여부만 볼 게 아니라 자동 갱신이 실제로 작동하는지 확인한다. 갱신 실패 알림이 없으면 만료 당일에야 문제를 알기 쉽다.
이전 작업은 복구 순서까지 적어두기
서버를 옮길 때는 파일만 복사해서 끝나지 않는다. 데이터베이스, 업로드 파일, 환경 설정, 예약 작업, 인증서 갱신 방식까지 옮겨야 한다. 이전 전에는 원본 사이트의 파일 크기와 데이터베이스 크기를 기록하고, 새 서버에서 같은 버전의 실행 환경을 준비한다. 데이터가 계속 바뀌는 사이트라면 마지막 복사 직전에 쓰기 작업을 잠시 멈추거나 변경분을 다시 반영해야 한다.
백업은 원본 서버 밖에 있어야 한다. 같은 디스크에 둔 압축 파일은 디스크 장애나 계정 침해 때 함께 사라질 수 있다. 파일과 데이터베이스를 각각 백업하고, 보관 기간을 정해 용량이 끝없이 늘지 않게 한다. 중요한 건 백업 성공 메시지보다 복원 경험이다. 별도 환경에서 파일을 풀고 데이터베이스를 불러와 로그인, 게시물, 이미지가 정상인지 주기적으로 확인한다.
이전 당일에는 이전 서버를 바로 지우지 않는다. 새 서버에서 주요 화면과 관리자 기능을 확인하고, 오류 기록과 데이터 변경 상태를 비교한다. 되돌려야 할 때 어느 시점의 데이터로 돌아갈지도 미리 적어둔다. 이 순서가 없으면 장애가 난 뒤 오래된 백업을 덮어쓰는 실수가 생긴다.
사이트가 느리거나 멈췄을 때 보는 순서
장애가 나면 우선 증상을 나눈다. 모든 방문자가 접속하지 못하는지, 특정 페이지에서만 오류가 나는지, 관리자 화면만 느린지 확인한다. 그다음 서버 자체가 살아 있는지, 저장 공간이 찼는지, 웹서버와 애플리케이션 프로세스가 실행 중인지 본다. 최근 설정 변경이나 배포가 있었다면 시간을 맞춰 로그를 읽는다.
- 접속 자체가 안 되면 서버 상태, 네트워크 설정, 도메인 연결 상태, 인증서 만료 여부를 확인한다.
- 오류 화면이 나오면 웹서버와 애플리케이션 오류 기록을 확인하고, 마지막 변경 사항과 대조한다.
- 일부 화면만 느리면 느린 데이터베이스 조회, 외부 서비스 호출, 캐시 상태를 본다.
- 갑자기 저장 공간이 줄었다면 로그, 백업 파일, 업로드 파일의 증가량을 확인한다.
CPU 사용률이 높다는 이유만으로 서버부터 키우면 원인을 놓치기 쉽다. 느린 요청 하나가 쌓이는 경우도 있고, 로그 파일이 디스크를 채워 서비스가 멈추는 경우도 있다. 평소 응답 시간과 자원 사용량을 기록해 두면 장애 때 무엇이 달라졌는지 바로 보인다. 제 경험상 적정 사양을 고르는 일은 시작이고, 백업을 실제로 복원할 수 있는지 확인하는 일이 사이트를 오래 살린다.
