서버관리자가 사이트를 안정적으로 운영하는 방법

얼마 전 방문자가 늘었다며 서버를 두 배 큰 요금제로 옮긴 사이트를 봤다. 그런데 느려진 원인은 서버 사양이 아니었다. 데이터베이스 연결 수가 꽉 찬 상태에서 백업 작업까지 같은 시간에 돌고 있었다. 서버관리자가 먼저 할 일은 장비를 키우는 게 아니라, 어디에서 한계가 생겼는지 숫자로 확인하는 것이다.

방문자 수를 서버 부하로 바꿔 계산한다

월 방문자나 페이지 조회 수만으로 서버를 고르면 대개 빗나간다. 같은 10만 조회라도 정적 문서 위주의 사이트와 검색·로그인이 많은 사이트의 부담은 다르다. 먼저 한 페이지를 열 때 서버가 처리하는 동적 요청 수, 응답 시간, 가장 붐비는 시간대의 요청 수를 본다.

예를 들어 월 30만 페이지 조회가 있고 페이지마다 동적 요청이 4번 발생한다면 월 동적 요청은 120만 건이다. 이를 한 달 전체로 나눈 평균은 초당 약 0.46건이다. 피크가 평균의 20배라고 가정해도 초당 약 9건이다. 각 요청이 평균 0.3초 동안 처리된다면 동시에 실행되는 요청은 대략 3건이다. 이 수치는 출발점일 뿐이다. 이벤트 직후 몇 분 동안 요청이 몰리거나 느린 검색이 섞이면 실제 최대치는 훨씬 높아진다.

전송량도 따로 계산해야 한다. 페이지당 실제 전송량이 0.8MB라면 월 30만 조회는 약 240GB다. 이미지와 스크립트를 외부 캐시에 두면 원본 서버의 전송량은 줄지만, 서버에서 모든 파일을 직접 내보내면 회선과 요금제 한도가 먼저 걸릴 수 있다. CPU 사용률만 보고 사양을 결정하면 이 부분을 놓치기 쉽다.

서버관리자는 남는 자원까지 사양에 넣는다

사양표에서 메모리 2GB라고 쓰여 있어도 애플리케이션이 2GB를 전부 쓸 수 있는 건 아니다. 운영체제, 웹서버, 데이터베이스, 백업 작업이 함께 쓴다. 평소 사용량을 합산한 뒤 20~30% 정도의 여유를 남겨야 배포나 일시적인 요청 증가를 견딘다. 이 비율은 절대 기준이 아니라 운영할 때 점검할 여유분이다.

작은 소개 사이트나 캐시가 잘 되는 블로그는 저가형 웹호스팅으로도 충분한 경우가 많다. 반대로 회원별 화면을 만들고 검색을 자주 수행한다면 조회 수가 적어도 데이터베이스가 먼저 바빠질 수 있다. VPS로 옮길 시점은 방문자 수 자체보다 현재 환경에서 메모리 부족, 저장장치 대기, 프로세스 제한이 반복되는지로 판단하는 편이 낫다.

서버관리자가 남겨야 할 기본 지표는 CPU 평균보다 조금 더 넓다. 메모리 사용량과 스왑 발생, 저장장치의 남은 용량과 대기 시간, 응답 시간의 상위 구간, 오류 비율, 데이터베이스 연결 수를 함께 본다. 평균 응답 시간이 멀쩡해도 일부 요청만 10초씩 걸리면 이용자는 이미 장애를 겪고 있다.

백업은 파일 생성보다 복원 시간을 확인한다

운영 중 가장 아찔했던 순간은 백업 파일이 없을 때보다 파일은 있는데 복원이 안 될 때였다. 데이터베이스 덤프만 있고 사용자가 올린 파일이 빠졌거나, 백업 파일이 운영 서버의 같은 디스크에 있어서 디스크 장애와 함께 사라진 사례가 있었다.

백업 계획은 두 가지 시간부터 정한다. 마지막 백업 이후 잃어도 되는 데이터가 24시간분인지 1시간분인지, 장애 뒤 서비스를 다시 열 때까지 몇 시간을 허용할지다. 주문이나 예약처럼 손실 비용이 큰 데이터는 매일 한 번 복사하는 방식만으로 부족할 수 있다. 반면 변경이 드문 안내 사이트에 무조건 복잡한 실시간 복제 구성을 붙일 이유도 적다.

데이터베이스와 업로드 파일은 같은 시점의 상태로 복원할 수 있어야 한다. 백업은 운영 서버 밖에도 보관하고, 삭제 사고를 대비해 이전 버전을 일정 기간 남긴다. 월 1회라도 별도 환경에 실제로 복원해 로그인, 주요 화면, 첨부 파일을 확인하면 백업 파일의 크기만 확인할 때보다 훨씬 많은 문제를 발견한다. 복원에 걸린 시간도 기록해 둬야 장애 때 약속할 수 있는 시간을 알 수 있다.

장애가 나면 최근 변경부터 좁혀 본다

사이트가 열리지 않을 때 서버부터 재부팅하면 잠깐 회복될 수는 있다. 하지만 재부팅 전 상태와 오류 기록이 사라져 원인을 놓치기도 한다. 우선 장애 시작 시각과 직전 배포·설정 변경을 확인하고, 한 곳에서만 접속이 안 되는지 여러 지역에서 같은 증상인지 구분한다.

접속 자체가 안 되면 도메인 설정, 인증서 상태, 방화벽, 웹서버 프로세스 순서로 확인한다.
화면은 뜨는데 느리면 응답 시간과 오류 기록을 보고 CPU·메모리·저장장치·데이터베이스 중 대기가 생긴 곳을 찾는다.
변경 직후부터 문제가 시작됐다면 변경 내용을 되돌릴 수 있는지 먼저 확인한다. 데이터 변경이 포함됐다면 되돌리기 전 현재 상태를 보존한다.
복구 뒤에는 장애 시각, 원인, 조치, 재발을 막을 확인 항목을 짧게 남긴다.

서버관리자의 실력은 큰 서버를 고르는 데서 드러나지 않는다. 평소 부하를 측정하고, 복원 시간을 직접 재고, 장애가 났을 때 확인 순서를 지키는 데서 차이가 난다. 그렇게 운영하면 작은 요금제로 충분한 구간도 자신 있게 판단할 수 있다.