서버 관리하는법은 점검 순서부터 잡으면 된다

얼마 전 접속이 끊긴 사이트를 확인했는데, 서버 성능에는 여유가 있었다. 원인은 가득 찬 디스크였다. 매일 백업 파일을 만들면서 오래된 파일을 지우지 않은 탓이다. 14년간 운영하면서 본 장애도 이런 경우가 많았다. 서버 관리하는법을 묻는다면 사양을 올리기 전에 용량, 설정, 백업, 복구 순서부터 잡으라고 말한다.

요금제보다 먼저 사용량을 계산한다

방문자 수만으로 서버 사양을 고르기는 어렵다. 하루 방문자가 같아도 이미지가 많은 페이지와 캐시되지 않는 게시판은 서버에 주는 부담이 다르다. 우선 하루 페이지 조회 수, 페이지당 전송량, 가장 붐비는 시간의 요청 수를 적는다. 하루 1만 페이지 조회에 페이지당 전송량이 평균 1MB라면 한 달 전송량은 대략 300GB다. 하루 요청의 10%가 한 시간에 몰려도 평균은 초당 약 0.3페이지다. 다만 순간적인 쏠림과 한 페이지에서 발생하는 추가 요청은 따로 봐야 한다.

작은 정보성 사이트라면 저가형 웹호스팅이나 캐시를 적용한 소형 VPS로 충분한 경우가 많다. 반대로 로그인 사용자마다 다른 화면을 만들거나 검색과 주문 처리가 잦으면 페이지 조회 수가 적어도 CPU와 데이터베이스 부담이 커진다. 저는 운영 전후로 CPU 사용률, 메모리 부족 기록, 디스크 입출력 지연, 응답 시간을 함께 본다. CPU가 잠깐 100%를 찍었다는 이유만으로 바로 상위 요금제로 옮기지는 않는다. 느려진 시간에 어떤 요청이 몰렸는지 확인해야 돈을 쓸 지점이 보인다.

접속과 업데이트 설정을 먼저 고정한다

서버를 만들면 관리자 계정부터 점검한다. SSH는 키 기반 접속을 쓰고, 관리자 권한이 필요한 계정과 일반 작업 계정을 나눈다. 방화벽에는 실제 쓰는 포트만 열어 둔다. 웹서버, 데이터베이스, 애플리케이션의 버전도 기록한다. 나중에 장애가 나면 언제 무엇이 바뀌었는지가 가장 먼저 필요하다.

업데이트는 미루지 않되 적용 순서를 정한다. 작은 사이트라도 변경 전 백업을 만들고, 업데이트 후에는 첫 화면뿐 아니라 로그인·글쓰기·결제처럼 중요한 동작을 직접 확인한다. SSL 인증서는 자동 갱신을 설정했더라도 만료일을 감시한다. 자동화 작업은 실패할 수 있다. 실제로 인증서 갱신은 되었는데 웹서버 재시작이 실패해 이전 인증서를 계속 내보내는 경우도 있다.

설정 파일을 손으로 고칠 때는 변경 전 파일을 남기고, 적용 전에 문법 검사를 한다. 배포도 같은 원칙이다. 새 버전을 올리는 절차와 이전 버전으로 되돌리는 절차를 함께 적어 둔다. 장애 중에 처음으로 되돌리는 명령을 찾기 시작하면 복구 시간이 길어진다.

백업은 파일 생성보다 복원 확인이 중요하다

백업 파일이 있다는 말과 복구할 수 있다는 말은 다르다. 웹 파일만 저장하고 데이터베이스를 빠뜨리거나, 같은 서버의 같은 디스크에만 백업을 쌓아두는 사례를 자주 본다. 서버가 삭제되거나 디스크가 손상되면 원본과 백업을 함께 잃는다. 최소한 데이터베이스, 업로드 파일, 설정 파일을 구분해 저장하고 서버 밖에도 사본을 둔다.

백업 주기는 잃어도 되는 데이터 양으로 결정한다. 하루치 글과 주문을 잃어도 되는지에 따라 매일 백업과 더 짧은 간격의 백업 중 선택이 달라진다. 복구에 허용되는 시간도 따져야 한다. 백업이 여러 개 있어도 100GB를 내려받고 복원하는 데 하루가 걸린다면, 몇 시간 안에 서비스를 되살려야 하는 사이트에는 맞지 않는다.

저는 적어도 한 달에 한 번은 별도 환경에 복원해 본다. 데이터베이스가 열리는지, 업로드 이미지가 보이는지, 로그인은 되는지까지 확인한다. 백업 작업의 성공 알림만 믿지 않는다. 파일 크기가 평소보다 갑자기 작아졌거나 오래된 백업만 남아 있어도 경고가 오도록 확인 항목을 둔다. 백업 보관 기간과 삭제 기준도 미리 정해야 앞서 말한 디스크 부족 사고를 피할 수 있다.

장애가 나면 바뀐 것부터 확인한다

사이트가 안 열리면 먼저 외부에서 접속이 안 되는지, 내 접속 환경만 문제인지 구분한다. 그다음 도메인 연결, 서버 접근, 웹서버 응답, 애플리케이션, 데이터베이스 순서로 범위를 좁힌다. 최근에 도메인 설정을 바꿨다면 연결 정보를, 배포 직후라면 애플리케이션 로그를 먼저 보는 식이다. 모든 로그를 한꺼번에 뒤지는 것보다 장애가 시작된 시각과 직전 변경을 맞춰 보는 편이 빠르다.

서버에 접속된다면 디스크 사용량과 서비스 상태를 먼저 확인한다. 디스크가 꽉 차면 데이터베이스 쓰기와 로그 기록이 함께 멈출 수 있다. 서버는 정상인데 오류 화면이 나온다면 웹서버 오류 로그와 애플리케이션 로그를 같은 시각으로 맞춰 본다. 응답이 느릴 때는 CPU뿐 아니라 메모리 부족으로 작업이 종료됐는지, 데이터베이스 연결이 쌓였는지, 외부 서비스 응답을 기다리는지도 확인한다.

장애를 고친 뒤에는 원인, 확인한 증거, 복구에 쓴 명령, 다시 발생했을 때 볼 지표를 짧게 남긴다. 다음 장애에서 시간을 아끼는 문서는 길고 멋진 보고서보다 이런 기록이다.

평소 점검은 짧고 반복 가능해야 한다

매일 몇 시간씩 서버 화면을 볼 필요는 없다. 외부 접속 확인, 오류 응답 증가, 디스크 여유 공간, 백업 실패, 인증서 만료 같은 항목에 알림을 걸어 둔다. 디스크는 80%를 넘었을 때 원인을 확인하고, 증가 속도를 보고 더 이른 경고가 필요한지 조정한다. 숫자 하나만 보고 자동으로 서버를 키우면 로그나 백업 파일이 쌓이는 문제를 놓치기 쉽다.

서버 이전도 평소 운영의 연장선이다. 새 서버에서 기능과 복원을 먼저 확인하고, 데이터가 바뀌는 사이트라면 이전 중 쓰기 작업을 어떻게 처리할지 정한다. 도메인 연결을 바꾸기 전에는 이전 서버를 바로 지우지 않는다. 새 서버의 로그와 실제 사용자 동작을 확인할 시간을 둔다.

서버 운영에서 비싼 요금제보다 값어치가 큰 것은 반복 가능한 절차다. 사용량을 측정하고, 변경을 기록하고, 백업을 복원해 본 사이트는 작은 서버에서도 안정적으로 버틴다. 사양을 늘리는 판단은 그다음에 해도 늦지 않은 경우가 많다.