리눅스 서버 처음 운영할 때 확인하는 방법

얼마 전 작은 쇼핑몰을 옮기면서 서버 사양보다 백업 파일부터 확인했다. 기존 서버는 CPU와 메모리가 넉넉했지만, 데이터베이스 백업은 몇 달째 실패하고 있었다. 14년 동안 서버를 운영하며 비슷한 일을 여러 번 봤다. 리눅스 서버를 처음 맡았다면 큰 요금제보다 필요한 용량, 접속 방법, 복구 절차를 먼저 잡는 편이 안전하다.

요금제보다 사용량부터 계산한다

월 방문자 수만으로 서버를 고르면 대개 사양이 남는다. 먼저 하루 페이지 조회 수와 페이지당 전송량, 요청 수를 적어본다. 하루 1만 페이지를 보고 페이지 하나가 이미지까지 평균 1MB라면 전송량은 하루 약 10GB, 30일에 약 300GB다. 이미지 크기를 줄이거나 캐시를 쓰면 이 수치는 크게 달라진다. 전송량 제한이 있는 요금제라면 CPU보다 이 항목을 먼저 확인해야 한다.

동시 처리량도 따로 계산한다. 페이지 조회 1건에 서버 요청이 3번 발생한다면 하루 요청은 3만 건, 초당 평균은 약 0.35건이다. 피크가 평균의 10배여도 초당 약 3.5건이다. 이 정도의 캐시된 정적 페이지와 가벼운 웹 애플리케이션은 보통 2 vCPU, 메모리 2GB부터 시험해볼 만하다. 같은 서버에 데이터베이스와 검색, 이미지 변환 작업까지 올린다면 메모리 4GB 이상이 필요할 수 있다. 이 숫자는 구매 기준점일 뿐이다. 응답 시간과 메모리 사용량을 측정한 뒤 올리는 게 정확하다.

디스크는 현재 파일 크기만 보고 정하면 곤란하다. 운영체제와 로그, 데이터베이스 증가분, 배포 중 잠시 필요한 공간을 더해야 한다. 사용 가능한 용량을 끝까지 채우지 말고 최소 20~30%는 남겨둔다. 디스크가 가득 차면 새 로그를 못 쓰는 수준에서 끝나지 않고 데이터베이스 쓰기까지 멈출 수 있다.

설치 직후에는 접속 경로와 권한을 고정한다

리눅스를 설치하고 처음 할 일은 평소 작업에 쓸 일반 계정을 만드는 것이다. 관리자 권한이 필요할 때만 sudo를 사용한다. SSH 키로 새 계정에 로그인할 수 있는지 별도 접속 창에서 확인한 뒤 비밀번호 로그인과 관리자 계정의 직접 로그인을 제한한다. 기존 연결을 먼저 끊었다가 설정이 틀린 걸 발견하면 콘솔 복구부터 해야 한다.

방화벽도 순서가 중요하다. 현재 쓰는 SSH 포트를 허용하고, 웹서비스에 필요한 포트만 추가한 뒤 방화벽을 켠다. 서버 관리 화면에서 제공하는 콘솔 접속 수단이 있다면 작동 여부도 확인한다. 방화벽 규칙과 SSH 설정을 한 번에 여러 개 바꾸면 접속이 끊겼을 때 어느 변경이 원인인지 찾기 어렵다.

보안 업데이트는 설치하되, 서비스 재시작이 필요한 변경은 작업 시간을 정해 적용한다.
웹서버 프로세스에는 필요한 파일만 읽을 권한을 주고, 업로드 폴더에는 실행 권한을 주지 않는다.
관리자 계정과 데이터베이스 비밀번호는 배포 파일이나 공개 저장소에 넣지 않는다.

운영체제를 설치했다고 보안 설정이 끝나는 건 아니다. 실제 사고는 과한 파일 권한, 공개된 관리 포트, 오래된 애플리케이션에서 자주 시작한다. 접속 경로를 줄이고 변경 사항을 기록해두면 점검할 때도 수월하다.

배포 전에는 되돌릴 수 있는 상태를 만든다

서비스 이전은 새 서버에서 화면이 뜨는지만 확인하면 끝나는 작업이 아니다. 현재 서버의 애플리케이션 파일, 데이터베이스, 환경 설정, 예약 작업, 인증서 갱신 방식까지 목록을 만든다. 데이터베이스를 따로 옮긴다면 마지막 복사 시점 이후에 들어온 주문이나 문의가 빠지지 않도록 쓰기 중단 시간도 정해야 한다.

순서는 단순하게 잡는 편이 낫다. 새 서버에 같은 버전의 실행 환경을 마련하고, 복사본으로 먼저 기능을 검사한다. 파일 업로드, 로그인, 메일 발송, 예약 작업은 첫 화면이 정상이어도 빠지기 쉽다. 전환 직전에는 최신 데이터를 다시 옮기고, 전환 후에는 실제 주문이나 문의가 새 데이터베이스에 기록되는지 확인한다. 문제가 생기면 어느 시점까지 이전 서버로 되돌릴 수 있는지도 미리 적어둔다.

설정 파일을 손으로 조금씩 수정하는 방식은 당장은 빠르지만 다음 이전 때 발목을 잡는다. 웹서버 설정과 서비스 실행 방법, 필요한 환경 변수 이름을 문서로 남긴다. 비밀 값 자체는 접근이 제한된 곳에 보관한다. 그래야 담당자가 바뀌거나 새 서버를 띄울 때 빠진 설정을 찾느라 시간을 쓰지 않는다.

백업과 장애 점검은 평소에 한 번 실행한다

백업 작업이 성공했다는 알림만으로는 복구를 보장할 수 없다. 데이터베이스는 일관성 있는 방식으로 덤프하거나 스냅숏을 만들고, 업로드 파일과 설정 파일도 함께 보관한다. 서버 안에만 백업을 두면 디스크 고장이나 계정 침해 때 원본과 같이 잃는다. 별도 저장소에 암호화해 두고, 예를 들어 최근 7일의 일별 백업과 4주의 주별 백업을 남기면 실수로 지운 파일을 발견할 시간도 벌 수 있다.

복구 연습에는 시간 측정이 필요하다. 빈 서버나 분리된 시험 환경에서 백업을 복원하고 로그인, 파일, 데이터베이스 기록까지 확인한다. 마지막 백업 이후 몇 시간의 데이터가 사라질 수 있는지, 복원에 몇 시간이 걸리는지 알게 된다. 사업상 감당할 수 있는 데이터 손실 시간보다 백업 간격이 길다면 횟수를 늘리거나 데이터베이스 복제 방식을 검토해야 한다.

장애가 나면 무작정 재시작하기 전에 범위를 좁힌다. 외부에서만 접속이 안 되는지, 서버 안에서도 웹서비스가 응답하지 않는지 확인한다. 그다음 uptime으로 부하를, free -h로 메모리를, df -h로 디스크를 본다. ss -lntp에서 서비스가 포트를 열었는지 확인하고 journalctl에서 해당 서비스의 최근 오류를 읽는다. 디스크가 찼다면 큰 로그 파일을 바로 지우기 전에 왜 쌓였는지 살펴야 같은 장애가 반복되지 않는다.

리눅스 운영은 명령어를 많이 외우는 것보다 현재 상태를 설명할 수 있게 만드는 일에 가깝다. 사용량을 계산해 작은 사양에서 시작하고, 접속 설정과 백업 복원을 직접 확인해두면 서버가 멈췄을 때도 다음에 볼 곳이 분명해진다.