hp서버 고를 때 필요한 사양 계산하는 방법

얼마 전 하루 방문자가 3천 명쯤 되는 사이트에서 hp서버 견적을 받았다는 이야기를 들었다. 현재 웹호스팅에서는 별문제가 없는데, 방문자가 늘면 물리 서버가 필요할 거라는 설명을 들었다고 했다. 14년간 서버를 운영하며 이런 경우를 자주 봤다. 장비를 고르기 전에 지금 서버가 얼마나 바쁜지부터 확인하는 편이 돈도 덜 들고 장애도 줄인다.

방문자 수보다 바쁜 시간의 요청을 본다

하루 페이지 조회 수가 10만 회라면 평균은 초당 약 1.2회다. 바쁜 시간에 요청이 평균의 10배 몰린다고 가정해도 초당 약 12회다. 페이지를 만드는 데 0.2초가 걸린다면, 단순 계산으로 동시에 처리 중인 페이지 요청은 약 2.4개다. 이 수치만 보고 hp서버를 들일 이유는 없다.

물론 페이지 조회 수와 서버 요청 수는 같지 않다. 이미지와 스크립트를 웹서버가 직접 보내는지, 검색 페이지가 데이터베이스를 여러 번 조회하는지에 따라 부하는 크게 달라진다. 로그인이나 결제가 몰리는 사이트는 평균 방문자 수보다 피크 시간의 동작이 중요하다. 접속자 수라는 말도 주의해야 한다. 브라우저를 열어 둔 사람 100명과 동시에 무거운 검색을 실행하는 사람 100명은 서버에 주는 부담이 다르다.

운영 중인 사이트라면 일주일 정도 CPU 사용률, 메모리 사용량, 디스크 읽기·쓰기 대기 시간, 피크 시간의 응답 시간을 기록한다. 장애가 있었다면 그 시각의 수치를 따로 본다. CPU가 평소 10%인데 특정 쿼리에서만 응답이 느리다면 코어를 늘리기 전에 쿼리와 인덱스를 확인할 일이다. 메모리가 남아도 디스크 대기 시간이 길면 저장장치가 병목일 수 있다.

hp서버 사양은 현재 사용량에서 계산한다

물리 장비가 필요하다면 먼저 업무별로 CPU, 메모리, 저장공간을 나눈다. 웹서버와 데이터베이스를 한 대에 둘 때는 운영체제와 백업 작업이 쓸 여유도 남겨야 한다. 가상머신을 여러 개 올릴 계획이라면 각 가상머신의 할당 메모리를 단순히 더한 뒤 끝내면 안 된다. 가상화 계층의 사용량과 장애 시 다른 장비로 옮겨 받을 여력까지 계산해야 한다.

• CPU는 피크 시간의 실제 사용률과 요청 처리 시간을 기준으로 잡는다. 짧은 순간의 급등만 보고 코어 수를 두 배로 늘리지는 않는다.
• 메모리는 현재 사용량에 데이터베이스 캐시와 향후 증가분을 더한다. 스왑 사용이 계속 늘면 먼저 원인을 찾는다.
• 저장공간은 현재 데이터, 로그 증가량, 백업 임시 공간을 따로 계산한다. 용량이 충분해도 쓰기 지연이 길면 성능을 확인한다.
• 네트워크는 월 전송량과 피크 시간의 대역폭을 함께 본다. 월 전송량이 적어도 짧은 시간에 다운로드가 몰릴 수 있다.

예를 들어 현재 메모리 사용량이 피크에 12GB이고, 1년 동안 데이터와 서비스가 30% 늘 것으로 예상된다면 16GB는 빠듯하다. 운영체제와 작업 여유를 포함해 32GB 구성을 검토할 만하다. 다만 캐시 때문에 메모리가 차 보이는 경우도 있으니 사용 가능 메모리와 스왑 변화를 함께 확인한다. CPU 역시 사용률 숫자 하나보다 피크 시 응답 시간이 나빠지는지를 같이 봐야 한다.

장비값보다 운영 조건을 먼저 확인한다

hp서버를 중고로 들이면 초기 비용은 낮출 수 있다. 그런데 디스크, 전원공급장치, 팬 같은 소모성 부품의 상태와 교체 가능 여부를 확인하지 않으면 장애가 났을 때 비용이 커진다. 모델 이름과 가격만 비교하지 말고 장착 가능한 메모리, 저장장치 규격, 남은 확장 슬롯을 판매 조건과 함께 확인한다.

전력과 설치 공간도 계산에 넣는다. 서버 한 대의 소비전력이 평균 200W라면 24시간 운영 시 한 달 약 144kWh를 쓴다. 여기에 냉각, 회선, 고정 주소, 원격 접속 환경, 예비 부품 비용이 붙는다. 사무실에 놓을 계획이라면 정전 뒤 자동 부팅 설정과 원격 관리 기능도 확인해야 한다. 현장에 가야만 전원을 켤 수 있다면 작은 장애도 오래 간다.

장비 한 대로 서비스할 때는 전원공급장치를 이중으로 달아도 장비 자체가 멈추면 서비스가 중단된다. 가용성이 중요하다면 서버 두 대와 장애 전환 방식까지 견적에 넣어야 한다. 그 비용이 부담스럽고 현재 부하가 작다면 관리형 웹호스팅이나 작은 VPS가 더 합리적일 수 있다. 물리 서버를 소유하는 것과 서비스를 안정적으로 운영하는 것은 별개의 일이다.

이전 전에는 복구 절차부터 만들어 둔다

새 hp서버로 옮길 때 가장 자주 놓치는 건 백업이 실제로 복구되는지 확인하지 않는 일이다. RAID는 디스크 한 개가 고장 났을 때 버티기 위한 구성이지 백업이 아니다. 파일을 잘못 지우거나 데이터베이스가 손상되면 RAID에도 그 상태가 그대로 반영된다. 서버 밖에 백업을 보관하고, 별도 환경에 한 번 복원해 봐야 한다.

이전 순서는 단순하게 잡는다. 기존 서버의 파일과 데이터베이스를 백업하고, 새 서버에 같은 버전의 실행 환경을 만든다. 새 서버에서 로그인·업로드·결제 같은 주요 기능을 시험한 뒤 짧은 점검 시간을 잡아 변경 데이터를 한 번 더 옮긴다. 접속 경로를 바꾼 다음에도 기존 서버는 바로 지우지 않는다. 문제가 생겼을 때 되돌릴 기준 시각과 담당자를 미리 정해 둔다.

장애가 나면 먼저 서버 전원이 살아 있는지, 원격 관리 화면에 하드웨어 경고가 있는지 확인한다. 그다음 회선과 방화벽, 웹서버 프로세스, 데이터베이스, 디스크 여유 공간 순으로 좁혀 간다. 최근 설정 변경이 있었다면 변경 시각과 장애 시작 시각을 대조한다. 무턱대고 재부팅하면 잠깐 살아날 수는 있지만, 원인을 보여 줄 기록도 사라질 수 있다.

내 기준에서 hp서버 구매 시점은 방문자 수가 커졌을 때가 아니라, 측정한 부하와 운영 조건을 놓고 봐도 물리 장비가 필요한 때다. 작은 요금제로 충분한 구간에서는 그 비용을 백업 점검과 복구 연습에 쓰는 편이 실제 장애를 줄이는 데 더 효과적이다.