서버용컴퓨터 필요한 사양 계산하는 방법

얼마 전 작은 쇼핑몰을 옮기면서 서버 사양부터 물었더니, 운영자는 월 방문자 수 대신 ‘일단 좋은 컴퓨터를 사야 하지 않느냐’고 했다. 14년간 서버를 운영하며 본 장애는 CPU가 부족해서보다 백업이 없거나 설정이 꼬여서 생긴 경우가 많았다. 서버용컴퓨터를 고를 때도 장비 이름보다 실제 부하와 복구 방법을 먼저 적는 편이 낫다.

서버용컴퓨터가 필요한 일부터 구분한다

웹사이트를 운영한다고 모두 직접 장비를 살 필요는 없다. 정적 사이트나 방문이 적은 블로그라면 저가 웹호스팅으로 충분한 경우가 많다. 운영체제 설정을 직접 바꾸거나 여러 서비스를 함께 돌려야 한다면 VPS가 편하다. 사무실 안에서만 쓰는 파일 공유, 개발용 테스트 서버, 특정 장비와 연결되는 프로그램이라면 직접 두는 컴퓨터가 맞을 수 있다.

집이나 사무실에 장비를 두고 외부 방문자에게 웹사이트를 제공하려면 조건이 더 붙는다. 회선의 업로드 속도, 공인 IP 사용 가능 여부, 정전 시간, 공유기 설정까지 확인해야 한다. 일부 회선은 외부에서 들어오는 연결이 제한된다. 이 경우 컴퓨터 성능을 올려도 방문자는 사이트에 접속하지 못한다.

장비 구매 전에는 세 가지만 적어두면 판단이 빨라진다. 하루 중 가장 바쁜 시간에 몇 명이 접속하는지, 장애가 나면 몇 시간 안에 되살려야 하는지, 데이터가 최대 몇 시간치까지 사라져도 되는지다. 마지막 두 값이 엄격하다면 예비 전원과 외부 백업 비용이 장비값보다 중요해진다.

방문자 수를 CPU와 메모리로 바꾸는 방법

월 방문자 수만으로 CPU를 정하면 자주 빗나간다. 같은 10만 페이지뷰라도 이미지를 캐시에서 보내는 블로그와 매 요청마다 상품 검색을 하는 쇼핑몰은 부하가 다르다. 우선 페이지 한 번을 열 때 전송하는 양을 재고, 데이터 전송량을 계산한다. 평균 2MB인 페이지가 월 10만 번 열리면 단순 계산으로 약 200GB다. 여기에 검색 로봇, 관리자 작업, 백업 전송량이 더해진다.

다음은 가장 바쁜 1시간을 본다. 월 10만 페이지뷰를 30일에 고르게 나누면 시간당 약 139회지만 실제 접속은 특정 시간에 몰린다. 피크가 평균의 10배라면 시간당 약 1,390회, 초당 평균 0.4회 수준이다. 이 정도의 캐시가 잘 잡힌 소규모 사이트에 처음부터 고가 장비를 들일 이유는 적다. 다만 접속이 몇 초에 한 번씩 몰리거나 느린 데이터베이스 쿼리가 있으면 순간 부하는 평균보다 훨씬 높다.

시작 사양을 잡는다면 캐시가 있는 단일 사이트는 2코어 CPU와 4GB 메모리를 시험 기준으로 삼을 만하다. 데이터베이스까지 같은 장비에서 돌리고 관리 화면 사용이 잦다면 4코어와 8GB에서 측정하는 편이 여유롭다. 이는 구매 보증 사양이 아니다. 실제 서비스와 비슷한 데이터를 넣고 응답 시간, CPU 사용률, 메모리 부족 여부를 확인해야 한다.

부품을 고를 때 놓치기 쉬운 비용

저장장치는 용량보다 장애 후 복구 시간을 먼저 생각한다. 운영체제와 데이터베이스는 SSD에 두고, 쓰기량과 여유 공간을 확인한다. 저장 공간을 끝까지 채우면 로그나 임시 파일 때문에 서비스가 멈출 수 있다. 메모리도 평상시 사용량만 보고 딱 맞추지 않는다. 업데이트나 백업 작업이 겹칠 때 쓸 여유가 필요하다.

중요한 업무 데이터를 오래 보관한다면 ECC 메모리 지원 여부를 검토할 만하다. 다만 ECC가 백업을 대신하지는 않는다. 디스크 두 개를 묶는 RAID도 한쪽 디스크 고장에는 대응할 수 있지만, 파일을 잘못 지우거나 랜섬웨어에 걸리면 두 디스크의 데이터가 함께 영향을 받는다.

전기료와 장비를 둘 공간도 계산에 넣는다. 예를 들어 평균 소비전력이 40W인 장비를 한 달 내내 켜두면 약 28.8kWh를 쓴다. 실제 요금은 전기 계약과 냉방 환경에 따라 달라진다. 팬 소음, 먼지 청소, 부품 교체 시간까지 감당해야 한다면 저렴한 호스팅이나 VPS가 오히려 운영비를 줄일 수 있다.

구매 전에 백업과 장애 순서를 정한다

서버용컴퓨터를 설치하는 날 백업도 함께 설정한다. 사이트 파일과 데이터베이스를 분리해 백업하고, 장비 밖의 저장소에도 사본을 둔다. 하루 한 번 백업한다면 사고 시 최대 하루치 변경분을 잃을 수 있다. 주문이나 예약처럼 손실을 줄여야 하는 데이터는 더 짧은 간격과 별도 복구 방법이 필요하다.

백업 파일이 만들어졌다는 기록만으로는 부족하다. 빈 서버에 파일을 복사하고 데이터베이스를 복원해 실제로 화면과 주요 기능이 동작하는지 확인해야 한다. 복구에 걸린 시간도 재둔다. 사업상 허용 가능한 중단 시간이 두 시간인데 복원에 여섯 시간이 걸린다면 백업 주기와 별개로 운영 계획을 바꿔야 한다.

사이트가 열리지 않을 때는 전원과 회선, DNS, 웹서버 프로세스, 저장 공간, 데이터베이스 연결, 최근 설정 변경 순서로 확인한다. 변경 직후 장애가 났다면 되돌릴 설정과 담당자를 미리 적어둔 기록이 특히 유용하다. 장비를 사양표만 보고 고르면 이런 준비가 뒤로 밀린다. 저는 먼저 복구할 수 있는 작은 구성으로 시작하고, 측정한 부하가 한계에 닿을 때 사양을 올린다.