모두
모두콘텐츠
얼마 전 월 방문자가 3만 명쯤 되는 사이트에서 단독서버 견적을 받아 왔다. 접속자가 늘면 서버 한 대를 통째로 써야 한다는 설명을 들었다고 했다. 로그를 보니 평소 초당 요청은 2건 안팎이었고, 느려진 시간에는 이미지 파일을 서버가 직접 보내느라 회선이 바빴다. 서버를 바꾸기 전에 이미지 크기와 캐시 설정을 손보는 편이 먼저였다.
단독서버는 물리 장비 한 대의 자원을 혼자 쓰는 방식이다. 다른 고객의 부하에 영향을 덜 받고 저장 장치나 네트워크 구성을 직접 정할 수 있다. 대신 장비 장애, 교체 시간, 백업, 운영체제 관리까지 비용과 책임을 함께 따져야 한다. ‘방문자가 많다’는 말만으로 고를 상품은 아니다.
방문자 수보다 요청량과 작업 시간을 본다
먼저 최근 한 달의 최고 부하 시간을 찾는다. 하루 평균 방문자나 월 페이지뷰만 보면 피크가 가려진다. 접속 기록에서 시간대별 요청 수를 보고, 행사나 방송 직후처럼 몰리는 5분 구간도 따로 확인한다. 정적 이미지 요청과 로그인·검색·결제처럼 서버가 계산해야 하는 요청은 나눠서 세는 게 좋다.
예를 들어 하루 페이지뷰가 1만 건이고 페이지마다 2MB를 보낸다면 전송량은 하루 약 20GB, 한 달 약 600GB다. 이 수치만으로 단독서버가 필요하다고 판단할 수는 없다. 이미지와 파일을 캐시에서 보내면 웹서버와 데이터베이스가 처리할 일은 크게 줄어든다. 반대로 페이지뷰가 적어도 검색 한 번에 복잡한 쿼리가 여러 개 실행되면 CPU와 저장 장치가 먼저 막힌다.
‘동시접속 1천 명’이라는 표현도 조심해야 한다. 화면을 읽고 있는 1천 명과 같은 순간에 서버 응답을 기다리는 요청 1천 건은 다르다. 초당 50건을 처리하고 각 요청이 평균 0.2초 걸리면, 평균적으로 처리 중인 요청은 약 10건이다. 다만 평균값만 믿으면 안 된다. 느린 요청이 2초까지 늘어나는 피크에는 대기 요청이 쌓일 수 있으니 최대 응답 시간과 오류율을 함께 봐야 한다.
사양은 병목을 확인한 뒤 한 단계씩 잡는다
기존 서버의 피크 시간 CPU 사용률, 메모리 부족 여부, 디스크 지연, 회선 사용량을 먼저 기록한다. CPU가 바쁘더라도 데이터베이스 쿼리 하나가 대부분을 차지한다면 코어 수를 늘리기 전에 쿼리와 색인을 고쳐야 한다. 메모리가 부족해 디스크 교환 영역을 계속 쓰는 상황이라면 CPU가 남아 있어도 사이트는 느리다.
작은 웹사이트 여러 개나 보통 규모의 기업 사이트라면 가상 서버의 2~4개 가상 CPU와 4~8GB 메모리에서 시작해도 되는 경우가 많다. 이 숫자는 구매 기준이 아니라 측정의 출발점이다. 피크 시간에도 CPU와 메모리에 여유가 있고 응답 시간이 안정적이면 굳이 물리 장비로 옮길 이유가 없다. 반면 일정한 고부하가 오래 지속되거나 큰 메모리, 빠른 로컬 저장 장치, 장비 수준의 격리가 필요하다면 단독서버 견적을 받아볼 만하다.
회선 표기도 실제 사용량으로 바꿔 봐야 한다. 100Mbps 회선을 한 달 내내 가득 쓰면 계산상 약 32TB를 보낼 수 있지만, 운영 계획을 그 한계치에 맞춰 짜면 피크 때 버틸 여지가 없다. 포트 속도와 월 전송량 제한, 초과 요금, 국내외 구간의 품질을 각각 확인한다. 대용량 파일 배포가 목적이라면 계산 자원이 넉넉한 서버 한 대보다 파일 전송 경로를 분리하는 구성이 더 싸게 먹힐 수 있다.
월 요금에는 장애를 복구할 비용도 넣는다
단독서버 견적에서는 CPU와 메모리만 눈에 들어오기 쉽다. 실제 월비용에는 저장 장치 추가, 백업 공간, 회선 초과분, 운영체제 관리, 장애 대응 시간까지 들어간다. 저렴한 장비 한 대가 멈췄을 때 부품 교체에 몇 시간이 걸리는지도 물어봐야 한다. 서비스 중단을 거의 허용할 수 없다면 서버를 한 대 더 두고 전환하는 비용이 생긴다.
저장 장치를 두 개 묶는 RAID는 디스크 하나가 고장 났을 때 운영을 이어가기 위한 장치다. 파일을 잘못 지우거나 침해 사고로 데이터가 바뀌면 그 변경도 함께 반영된다. 백업은 별도 저장소에 두고, 최소한 최근 며칠의 복구 지점을 남긴다. 데이터베이스가 있는 사이트라면 파일만 복사하지 말고 데이터베이스와 업로드 파일이 같은 시점으로 복원되는지도 확인한다.
운영 중인 서버에서 백업 파일이 생성됐다는 표시만 보고 안심하면 위험하다. 시험 환경에 실제로 복원해 로그인, 게시물, 첨부 파일까지 열어 봐야 한다. 복구에 30분이 걸리는지 6시간이 걸리는지 알아야 장애 때 선택할 수 있다. 단독서버의 값어치는 장비의 소유 형태보다, 문제가 났을 때 서비스를 다시 띄울 수 있는 준비에서 갈린다.
이전은 되돌릴 수 있는 순서로 진행한다
가상 서버에서 단독서버로 옮긴다면 먼저 새 장비에 운영체제와 웹서버를 설치하고, 방화벽과 접근 권한을 점검한다. 이후 파일과 데이터베이스를 복사해 시험 접속으로 기능을 확인한다. 기존 서버의 데이터를 계속 받는 동안 새 서버를 공개하면 두 곳의 내용이 달라질 수 있으므로, 최종 동기화 시점과 짧은 쓰기 중단 시간을 정해 둔다.
전환 직전에는 백업을 하나 더 만들고 복원 방법을 적어 둔다. 접속 경로를 바꾼 뒤에는 첫 화면만 보지 말고 로그인, 글쓰기, 결제, 예약 작업, 메일 발송을 차례로 확인한다. 오류율과 응답 시간도 이전 수치와 비교한다. 문제가 생겼을 때 기존 서버로 돌릴 수 있도록 일정 기간 기존 환경을 유지하는 편이 안전하다.
장애가 나면 서버를 재시작하기 전에 범위를 좁힌다. 모든 방문자에게 같은 증상인지, 웹서버만 응답하지 않는지, 데이터베이스 연결이나 저장 공간이 찼는지 순서대로 본다. 재시작은 당장 화면을 살릴 수 있지만 원인을 보여 줄 기록까지 지울 수 있다. 로그와 자원 사용량을 먼저 남겨 두면 다음 장애를 줄이는 데 도움이 된다.
단독서버가 맞는 시점은 방문자 숫자 하나로 정해지지 않는다. 현재 병목이 무엇인지, 가상 서버를 키웠을 때 비용이 얼마나 드는지, 장비 한 대가 멈췄을 때 몇 시간 안에 복구해야 하는지를 함께 놓고 계산해야 한다. 저는 그 계산에서 가상 서버가 충분하면 그대로 쓴다. 장비를 늘리는 일보다 복원 가능한 백업을 갖추는 일이 먼저인 현장을 더 많이 봤다.
