모두
모두콘텐츠
얼마 전 작은 예약 사이트를 옮기면서 월 방문자 수만 보고 큰 서버를 계약하려던 운영자를 만났다. 실제 접속 기록을 보니 바쁜 시간에도 동시 요청은 몇 건 수준이었다. 문제는 사양보다 기존 서버의 데이터베이스 백업이 한 번도 복구 검증을 거치지 않았다는 점이었다. JSP호스팅을 고를 때 이런 순서가 자주 뒤집힌다.
먼저 JSP가 실행되는 환경인지 확인한다
JSP 파일은 일반적인 정적 웹호스팅에 올린다고 실행되지 않는다. 자바 웹 애플리케이션을 돌릴 서블릿 컨테이너가 필요하다. 상품 설명에 자바 지원이라고 적혀 있어도 톰캣 사용 가능 여부, 지원 자바 버전, 애플리케이션 배포 방식은 따로 확인해야 한다. 파일만 업로드할 수 있는 상품과 WAR 파일을 배포할 수 있는 상품은 운영 범위가 다르다.
기존 프로젝트라면 사용하는 프레임워크와 라이브러리 버전부터 적어 두는 게 좋다. 오래된 애플리케이션은 새 자바 버전에서 바로 뜨지 않을 수 있고, 반대로 최신 애플리케이션은 호스팅 업체가 제공하는 구형 런타임에서 실행되지 않을 수 있다. 톰캣의 재시작 권한, 로그 접근, 환경 변수 설정, 예약 작업 사용 가능 여부도 장애 대응에 직접 영향을 준다.
공유형 JSP호스팅은 서버 관리 부담이 적지만 설정을 바꿀 수 있는 범위가 좁다. 단순 게시판이나 사내 안내 사이트처럼 요구 사항이 정해져 있다면 충분할 수 있다. 특정 톰캣 설정, 별도 프로세스, 자유로운 배포 절차가 필요하면 VPS가 편하다. 다만 VPS는 운영체제 업데이트와 접근 제어, 백업까지 직접 책임져야 한다.
방문자 수를 요청량과 메모리로 바꿔 본다
월 방문자 수 하나로 CPU를 고르기는 어렵다. 하루 페이지 조회 3만 건인 사이트를 가정해 보자. 페이지마다 서버가 처리하는 동적 요청이 한 번이라면 하루 평균은 초당 약 0.35건이다. 가장 바쁜 시간의 순간 요청량을 평균의 20배로 잡아도 초당 약 7건이다. 이 숫자는 상품의 보장 성능이 아니라 첫 측정을 위한 가정이다.
동시 처리량도 대략 계산할 수 있다. 초당 7건이 들어오고 요청 하나가 평균 0.5초 걸리면 동시에 처리 중인 요청은 약 3.5건이다. 그런데 데이터베이스 조회가 느려져 처리 시간이 3초로 늘면 같은 유입에도 약 21건이 겹친다. 접속자가 늘지 않았는데 서버가 버거워지는 일이 여기서 생긴다. CPU 사용률만 보지 말고 응답 시간과 데이터베이스 연결 대기까지 함께 봐야 한다.
메모리는 자바 프로세스 특성 때문에 더 신중하게 잡는다. JVM에 할당한 최대 힙이 서버 메모리의 전부가 아니다. 톰캣, 스레드, 네이티브 메모리, 운영체제와 파일 캐시도 공간을 쓴다. 작은 사이트라면 1가상 CPU와 메모리 2기가바이트 수준의 VPS에서 시험을 시작할 수 있지만, 데이터베이스까지 같은 서버에 두거나 배치 작업이 무거우면 여유가 부족할 수 있다. 실제 사용량을 며칠 측정한 뒤 늘리는 편이 월 요금을 덜 낭비한다.
전송량도 계산해 두면 요금제를 좁히기 쉽다. 페이지 한 번을 열 때 이미지와 스크립트를 포함해 평균 1메가바이트가 전송되고 하루 3만 번 열린다면 월 전송량은 대략 900기가바이트다. 이미지 캐시가 잘 작동하거나 외부 저장소를 쓰면 줄어들 수 있다. 반대로 큰 파일 다운로드가 많으면 방문자가 적어도 전송량 제한이 먼저 걸린다. 상품의 저장 공간과 월 전송량은 서로 다른 항목이다.
요금표보다 운영 조건을 비교한다
가격을 비교할 때는 CPU와 메모리 옆에 빠진 비용을 붙여야 한다. 데이터베이스가 포함되는지, 백업 보관에 별도 요금이 붙는지, 전송량 초과 시 과금인지 속도 제한인지 확인한다. 무료나 저가 상품으로도 개발용 환경이나 접속이 적은 사이트는 충분히 운영할 수 있다. 다만 무료 상품의 절전 동작이나 프로세스 종료 조건이 있다면 상시 접속이 필요한 서비스에는 맞지 않을 수 있다.
SSL 인증서 제공 여부만 보고 넘어가는 경우도 많다. 실제로는 인증서 갱신이 자동인지, 프록시 뒤의 톰캣이 원래 요청의 보안 연결을 올바르게 인식하는지까지 봐야 한다. 이 설정이 어긋나면 로그인 후 계속 이동하거나 보안 쿠키가 기대와 다르게 동작한다. 관리자 페이지 접근 제한과 로그 보관 기간도 상품 비교표에 넣을 만하다.
업체의 ‘무제한’ 표시는 사용 조건을 읽어야 의미가 있다. 동시 실행 수, CPU 점유 시간, 파일 수, 데이터베이스 연결 수처럼 다른 제한이 있을 수 있기 때문이다. 테스트 배포를 한 번 해 보고 재시작에 걸리는 시간과 오류 로그를 읽을 수 있는 범위를 확인하면 광고 문구보다 운영 현실이 선명해진다.
이전 전에 복구 절차부터 만들어 둔다
서버 이전은 파일 복사로 끝나지 않는다. 데이터베이스 덤프, 업로드 파일, 애플리케이션 설정, 인증서 갱신 방식, 예약 작업 목록을 각각 확인해야 한다. 비밀번호와 접속 정보는 백업 파일 안에 평문으로 흩어두지 않는다. 먼저 새 환경에 복원해 로그인, 글쓰기, 파일 업로드, 메일 발송 같은 주요 기능을 시험한다.
도메인 전환 전에는 기존 서비스의 DNS 캐시 시간을 낮추고, 전환 중에도 옛 서버를 잠시 유지할 계획을 세운다. 쓰기가 발생하는 서비스라면 어느 시점에 새 데이터베이스를 기준으로 삼을지도 정해야 한다. 이 기준 없이 두 서버를 동시에 열면 주문이나 게시글이 서로 다른 곳에 저장될 수 있다. 전환 직후에는 오류율, 응답 시간, 데이터베이스 연결 수를 집중해서 본다.
장애가 나면 먼저 사용자에게 보이는 증상을 확인한다. 도메인 조회가 되는지, SSL 연결이 되는지, 웹서버가 응답하는지, 톰캣 프로세스가 살아 있는지, 데이터베이스 연결이 되는지 순서대로 좁혀 가면 된다. 502 오류가 난다고 무조건 서버를 키우면 원인을 놓친다. 재시작으로 잠깐 회복됐다면 그 시각의 애플리케이션 로그와 메모리 사용량을 남겨 둬야 같은 장애를 줄일 수 있다.
내가 작은 JSP 사이트의 호스팅을 고를 때 가장 먼저 보는 것은 증설 버튼이 아니라 복원 가능한 백업과 읽을 수 있는 로그다. 적은 비용으로 시작해도 이 두 가지가 갖춰져 있으면 트래픽이 늘 때 차분하게 사양을 올릴 수 있다.
