모두
모두콘텐츠
얼마 전 접속자가 많지 않은 사이트의 서버를 옮겼는데, 새 서버에서도 같은 시간에 장애가 났습니다. 사양은 두 배로 올렸지만 원인은 디스크를 가득 채운 백업 파일이었습니다. 서버세팅을 맡으면 저는 요금제보다 먼저 접속 패턴, 저장 공간, 복구 방법을 확인합니다.
방문자 수보다 바쁜 시간의 요청을 본다
하루 방문자 1만 명이라는 숫자만으로 CPU와 메모리를 고르기는 어렵습니다. 방문자가 하루에 고르게 들어오는지, 특정 시간에 몰리는지에 따라 필요한 처리량이 달라집니다. 이미지가 캐시에서 나가는 정적 사이트와 요청마다 데이터베이스를 조회하는 사이트도 부담이 다릅니다.
먼저 가장 바쁜 5분의 요청 수를 초당 요청 수로 바꿉니다. 5분 동안 9,000건이면 평균 초당 30건입니다. 이때 서버가 요청 하나를 처리하는 데 평균 0.2초가 걸린다면 동시에 처리 중인 요청은 대략 6건입니다. 접속해 있는 사람 6명이라는 뜻은 아닙니다. 요청이 몰리는 순간과 느린 요청을 감안해 여유를 둬야 하지만, 이 계산만으로도 무작정 큰 요금제를 고르는 일은 줄어듭니다.
캐시가 잘 적용된 소규모 사이트라면 저가 웹호스팅으로 충분한 경우가 많습니다. 서버 설정을 직접 제어해야 하거나 백그라운드 작업이 필요할 때 VPS를 검토합니다. 처음부터 클라우드 서버를 여러 대로 나누기보다, 현재 호스팅에서 CPU 제한·메모리 부족·응답 지연 중 무엇이 실제로 발생하는지 확인하는 편이 정확합니다.
메모리는 실행할 작업을 더해서 잡는다
동적인 사이트는 CPU보다 메모리 계산이 먼저 필요한 때가 많습니다. 예를 들어 운영체제와 기본 프로세스에 400MB, 웹서버에 200MB, 데이터베이스에 600MB, 애플리케이션 작업자 6개에 각각 100MB, 여유 공간에 300MB를 잡으면 합계가 약 2.1GB입니다. 이 조건에서 2GB 서버를 고르면 업데이트나 일시적인 요청 증가만으로도 메모리가 모자랄 수 있습니다. 4GB를 시작점으로 잡고 실제 사용량을 확인하는 쪽이 낫습니다.
이 숫자는 견적을 내는 예시입니다. 작업자 하나가 쓰는 메모리와 데이터베이스 크기는 사이트마다 다릅니다. 현재 서버가 있다면 바쁜 시간의 메모리 사용량, 스왑 사용량, 작업자 수를 먼저 기록합니다. CPU 사용률이 높아 보여도 메모리 부족으로 디스크를 계속 읽고 쓰는 상황이라면 CPU만 늘려서는 응답이 나아지지 않습니다.
디스크는 현재 파일 크기만 보고 고르면 금방 막힙니다. 게시물과 이미지, 데이터베이스, 로그가 한 달에 얼마나 늘어나는지 보고 최소 몇 달치 여유를 둡니다. 전체 용량의 20~30% 정도를 비워 두면 로그 급증이나 데이터베이스 작업에도 대응하기 쉽습니다. 다만 서버 안에 쌓아 둔 백업 파일은 복구 수단이면서 동시에 디스크를 채우는 원인이 될 수 있습니다.
설치 직후에는 접속 경로와 복구 경로를 만든다
새 서버를 받으면 관리자 계정의 비밀번호 접속을 계속 열어 두지 않습니다. 별도 관리 계정과 SSH 키를 준비하고, 필요한 포트만 방화벽에서 허용합니다. 운영체제와 패키지의 보안 업데이트도 확인합니다. 데이터베이스는 외부 접속이 필요하지 않다면 내부에서만 받도록 설정합니다.
도메인을 연결했다면 SSL 인증서 발급뿐 아니라 자동 갱신이 실제로 동작하는지 확인합니다. 인증서는 설치한 날보다 만료되는 날에 사고가 납니다. 서버 시간 동기화, 애플리케이션 재시작 방식, 로그 보관 기간도 이때 정합니다. 담당자가 잠든 사이 프로세스가 종료돼도 다시 올라오는지 점검해야 합니다.
백업은 서버와 분리된 저장소에 보관합니다. 데이터베이스만 저장하고 업로드 파일을 빠뜨리거나, 파일만 남기고 데이터베이스를 빼는 실수가 흔합니다. 하루치 데이터를 잃어도 되는지, 장애 후 몇 시간 안에 다시 열어야 하는지부터 정하면 백업 주기와 보관 방식이 결정됩니다. 백업 완료 알림만 믿지 말고 임시 환경에서 파일과 데이터베이스를 함께 복원해 화면과 관리자 기능까지 확인합니다.
이전과 장애 대응은 순서를 미리 적어 둔다
서버 이전은 새 서버에서 복원 시험을 마친 뒤 진행합니다. 도메인 전환 전에 새 환경의 화면, 로그인, 파일 업로드, 메일 발송 같은 주요 기능을 확인합니다. 전환 직전에는 쓰기 작업을 잠시 멈추고 마지막 데이터베이스 백업을 가져옵니다. 이전 서버는 즉시 지우지 말고 되돌릴 수 있는 기간을 둡니다. 도메인 정보가 바뀌는 동안 일부 방문자는 잠시 이전 서버에 닿을 수 있기 때문입니다.
사이트가 느려지거나 열리지 않으면 먼저 증상을 나눕니다. 서버 자체에 접속이 안 되는지, 웹서버만 응답하지 않는지, 특정 기능만 오류가 나는지 확인합니다. 그다음 디스크 사용량과 메모리, 최근 배포·설정 변경, 웹서버와 애플리케이션 로그를 봅니다. 무작정 재부팅하면 잠깐 살아날 수 있지만 원인을 보여 줄 기록도 놓치기 쉽습니다.
제가 운영하면서 가장 자주 본 장애는 예상 밖의 대규모 트래픽보다 꽉 찬 디스크, 만료된 인증서, 복원해 본 적 없는 백업에서 나왔습니다. 서버세팅에 쓰는 시간도 그 순서에 맞춰 배분하는 편입니다. 처음부터 큰 사양을 사는 것보다 필요한 만큼 계산하고, 고장 났을 때 되돌아갈 길을 확보하는 게 오래 안정적으로 운영하는 방법입니다.
