모두
모두콘텐츠
얼마 전 작은 쇼핑몰의 서버가 밤새 멈췄다는 연락을 받았다. 방문자가 갑자기 늘어난 줄 알았는데, 원인은 디스크를 가득 채운 백업 파일이었다. 운영하면서 자주 보는 장면이다. 서버관리에서 먼저 챙길 것은 더 큰 요금제가 아니라 현재 상태를 볼 수 있는 지표와 복구할 수 있는 절차다.
요금제보다 실제 사용량을 먼저 확인한다
서버 사양을 고를 때 월 방문자 수만 보면 판단이 흔들린다. 같은 3만 명이 들어와도 이미지 위주의 소개 사이트와 검색·주문이 많은 쇼핑몰은 서버가 처리하는 일이 다르다. 최근 2~4주의 CPU 사용률, 메모리 여유, 디스크 사용량과 초당 요청 수를 먼저 본다. 가능하면 가장 바쁜 시간대의 수치를 따로 확인한다.
예를 들어 하루 페이지 조회가 3만 회이고, 한 페이지를 열 때 서버가 동적으로 처리하는 요청이 평균 3개라면 하루 약 9만 건이다. 하루 평균은 초당 약 1건이지만 실제 부하는 특정 시간에 몰린다. 바쁜 시간에 평균의 10배가 들어온다고 가정하면 초당 약 10건을 처리할 수 있는지 확인해야 한다. 이 숫자는 구매할 사양을 바로 뜻하지 않는다. 같은 10건이라도 요청마다 실행하는 쿼리와 응답 시간이 다르기 때문이다.
이미지와 파일 전송량은 따로 계산한다. 페이지 한 번에 내려가는 데이터가 2MB라면 하루 3만 회 조회에서 약 60GB, 30일이면 약 1.8TB다. 이미지가 캐시에 저장되어 전송되는지, 원본 서버가 매번 보내는지에 따라 필요한 대역폭과 비용은 달라진다. 저가 웹호스팅에서도 안정적으로 돌아가는 사이트가 많은 이유가 여기에 있다. 실제 병목이 확인되기 전에는 VPS나 클라우드 서버로 옮기는 비용에 운영 부담까지 더할 필요가 없다.
서버 상태는 다섯 가지 숫자로 본다
운영 화면에는 지표가 많지만 처음에는 CPU, 메모리, 디스크 사용량, 응답 시간, 오류율을 꾸준히 보면 된다. CPU가 잠깐 90%까지 오르는 것보다 바쁜 시간 내내 높은 상태로 유지되는지가 중요하다. 메모리는 남은 양만 보지 말고 스왑 사용과 프로세스 종료 기록을 함께 확인한다. 디스크는 전체 용량뿐 아니라 로그와 백업이 얼마나 빨리 늘어나는지도 봐야 한다.
응답 시간은 평균보다 느린 요청 쪽을 살핀다. 대부분의 페이지가 빨라도 일부 결제·로그인 요청이 몇 초씩 걸리면 사용자는 장애로 느낀다. 오류율도 마찬가지다. 방문자가 줄어서 CPU가 조용한데 오류가 늘었다면 서버가 건강하다고 볼 수 없다. 평소 수치를 기록해 두면 이상을 발견했을 때 비교 기준이 생긴다.
알림은 조치할 수 있는 수준으로 설정한다. 예를 들어 디스크 사용량이 80%를 넘으면 증가 원인을 확인하고, 90%에 가까워지기 전에 공간을 확보한다. 단, 숫자 하나만으로 자동 재시작하도록 만들면 원인이 가려질 수 있다. 알림을 받은 사람이 무엇을 확인하고 누구에게 연락할지까지 적어 두어야 실제로 쓸 수 있다.
백업은 파일 생성보다 복원 시험이 중요하다
백업 작업이 매일 성공했다고 표시돼도 복원할 수 있다는 뜻은 아니다. 웹 파일만 있고 데이터베이스가 빠졌거나, 같은 서버의 다른 폴더에만 백업을 둔 경우를 여러 번 봤다. 서버 디스크가 고장 나거나 계정이 잠기면 원본과 백업에 함께 접근하지 못한다.
먼저 복구 기준을 정한다. 주문 데이터가 최대 1시간 전까지만 남아도 되는지, 장애 후 4시간 안에 서비스를 열어야 하는지처럼 허용 가능한 데이터 손실과 중단 시간을 숫자로 적는다. 그 기준에 맞춰 데이터베이스 백업 주기와 보관 장소를 고른다. 변경이 드문 소개 사이트와 주문이 계속 들어오는 쇼핑몰에 같은 백업 주기를 적용할 수는 없다.
- 웹 파일, 데이터베이스, 업로드 파일, 서버 설정 중 무엇을 백업하는지 목록으로 남긴다.
- 백업 사본 하나 이상은 운영 서버와 다른 계정이나 저장소에 둔다.
- 새 서버나 별도 환경에 직접 복원해 로그인, 주요 페이지, 주문 흐름을 확인한다.
- 복원에 걸린 시간과 빠진 데이터를 기록해 복구 기준과 비교한다.
서버를 이전할 때도 이 순서를 그대로 쓴다. 새 환경에서 먼저 복원을 끝내고 기능을 확인한 뒤 접속 경로를 바꾼다. 이전 직전에는 변경되는 데이터의 처리 계획을 세워야 한다. 데이터베이스 복사 후에도 기존 서버에서 주문을 계속 받으면 두 서버의 내용이 달라질 수 있다.
장애가 나면 변경 이력부터 확인한다
사이트가 열리지 않을 때 재부팅부터 하는 습관은 위험하다. 일시적으로 살아날 수는 있지만 원인을 찾을 단서가 사라질 수 있다. 먼저 장애가 시작된 시각을 적고, 그 직전에 배포나 설정 변경, 인증서 교체, 백업 작업이 있었는지 확인한다. 다음으로 서버 접속 가능 여부, 웹서버와 애플리케이션 상태, 데이터베이스 연결, 디스크 여유, 오류 로그 순서로 범위를 좁힌다.
한 화면만 실패하면 해당 기능과 최근 변경을, 전체가 실패하면 공통 구성 요소를 먼저 의심한다. 서버는 정상인데 외부에서만 접속이 안 된다면 도메인 설정이나 네트워크 경로도 확인해야 한다. 원인을 모른 채 여러 설정을 한꺼번에 바꾸면 어느 조치가 효과가 있었는지 알기 어려워진다. 한 번에 하나씩 바꾸고 시각과 결과를 기록하는 편이 빠르다.
내가 작은 사이트를 맡을 때 가장 먼저 만드는 문서는 화려한 구성도가 아니다. 현재 사양과 평소 사용량, 백업 위치, 복원 순서, 장애 시 연락할 사람을 적은 한 장짜리 운영 메모다. 사람이 바뀌거나 새벽에 문제가 생겨도 그 문서가 있으면 첫 판단을 훨씬 침착하게 할 수 있다.
