기업용클라우드 필요한 사양부터 고르는 방법

얼마 전 직원 30명 규모의 회사에서 서버를 옮기며 상담을 받았다. 현재 서버가 느리니 기업용클라우드에서 가장 큰 요금제를 써야 하느냐는 질문이었다. 확인해 보니 평소 CPU 사용률은 15% 안팎이었다. 느려진 시간에는 데이터베이스 연결이 쌓여 있었고, 원인은 응용 프로그램의 설정이었다. 서버를 키웠다면 비용은 늘고 장애 원인은 그대로 남았을 것이다.

월 방문자보다 바쁜 시간의 동시 작업을 본다

기업용클라우드 사양을 고를 때 월 방문자 수만 보면 오차가 크다. 같은 월 10만 방문이라도 하루 종일 고르게 들어오는 사이트와 점심시간 20분에 주문이 몰리는 사이트는 필요한 자원이 다르다. 먼저 접속 기록에서 가장 바쁜 5분의 요청 수를 확인한다. 그다음 로그인, 검색, 주문처럼 서버와 데이터베이스를 실제로 쓰는 요청이 몇 개인지 나눈다. 이미지나 정적 파일 요청까지 모두 같은 무게로 계산하면 사양이 부풀려진다.

예를 들어 바쁜 5분에 동적 요청이 3,000건이면 평균 초당 10건이다. 다만 평균만으로는 부족하다. 짧은 순간에 요청이 몰릴 수 있으니 그 구간의 최고치와 응답 시간도 함께 본다. 처리 시간이 0.5초인 요청이 초당 20건 들어오면 단순 계산으로 약 10개가 동시에 처리 중이다. 이 값은 출발점일 뿐이다. 느린 데이터베이스 조회 하나가 연결을 오래 붙잡으면 동시 처리량이 금세 떨어진다.

기존 서버가 있다면 바쁜 시간의 CPU, 메모리, 디스크 사용량과 응답 시간을 먼저 기록한다. CPU가 계속 80%를 넘는지, 메모리 부족으로 프로세스가 종료되는지, 디스크 읽기·쓰기를 기다리는 시간이 긴지에 따라 필요한 조치가 달라진다. CPU는 한가한데 응답만 느리다면 무작정 코어를 늘리기 전에 느린 조회와 외부 연동을 확인하는 편이 낫다.

처음부터 큰 서버를 살 필요가 있는지 계산한다

업무용 웹사이트라도 이용자가 적고 배치 작업이 가볍다면 소형 가상 서버 한 대로 시작할 수 있다. 예를 들어 회사 소개 사이트나 소규모 예약 시스템은 실제 부하를 확인한 뒤 확장해도 늦지 않은 경우가 많다. 반대로 주문 중단이 매출에 바로 영향을 주거나 특정 시간에 접속이 몰리면 서버 두 대와 부하 분산, 데이터베이스 복구 구성을 검토할 이유가 생긴다. 서버가 두 대라고 자동으로 안전해지는 건 아니다. 두 대가 같은 저장소와 같은 데이터베이스에 의존하면 그 지점에서 함께 멈출 수 있다.

비용도 월 서버 요금만 비교하면 틀리기 쉽다. 저장 공간, 백업 보관량, 외부로 나가는 데이터 양, 부하 분산 장치, 고정 주소, 운영 지원 비용을 한 달 단위로 더해야 한다. 특히 이미지나 다운로드 파일이 많은 서비스는 서버 성능보다 데이터 전송 비용이 더 크게 변할 수 있다. 무료 또는 저가 구간에서 요구 성능과 복구 시간을 충족한다면 비싼 기업용 요금제를 고집할 이유는 없다.

• 평소 사용량과 가장 바쁜 시간의 사용량을 따로 기록한다.
• 한 단계 작은 사양에서 실제 업무 흐름으로 부하를 측정한다.
• 확장에 걸리는 시간과 확장 중 서비스 중단 여부를 확인한다.
• 서버 외 비용까지 합쳐 월 예상액과 급증 시 예상액을 만든다.

이전 계획에는 되돌리는 절차까지 넣는다

서버 이전에서 자주 사고가 나는 곳은 파일 복사보다 데이터와 설정이다. 이전 전에 프로그램 실행 환경, 데이터베이스 버전, 예약 작업, 메일 발송, SSL 인증서 갱신 방식, 접근 권한을 목록으로 적는다. 새 서버에서 화면이 열린다는 이유만으로 이전을 끝내면 주문 알림이나 야간 배치가 뒤늦게 빠진 것을 발견할 수 있다.

전환 전에는 데이터베이스와 업로드 파일을 함께 백업하고 복구 시험을 한다. 백업 파일이 있다는 사실과 복구할 수 있다는 사실은 다르다. 복구에 3시간이 걸리는데 업무가 30분 이상 멈추면 안 되는 회사라면 백업 주기와 구성을 다시 잡아야 한다. 마지막 백업 이후 몇 분의 데이터를 잃어도 되는지, 서비스를 몇 시간 안에 되살려야 하는지를 담당자와 먼저 정하면 필요한 비용도 명확해진다.

전환 당일에는 새 환경에서 로그인, 조회, 등록, 결제 같은 주요 동작을 확인한다. 기존 환경을 즉시 지우지 말고 문제가 생겼을 때 트래픽을 돌리는 순서와 데이터 처리 방법을 정해 둔다. 전환 후 새 환경에 쌓인 데이터가 있다면 단순히 이전 서버로 접속만 돌려서는 안 된다. 이 부분을 빼먹으면 서비스는 열려도 거래 기록이 갈라진다.

장애가 나면 증상부터 좁혀 간다

서비스가 멈췄을 때는 서버 재시작부터 누르기 쉽다. 하지만 재시작은 원인을 보여 줄 기록까지 지울 수 있다. 먼저 전체 이용자에게 같은 증상이 있는지, 특정 기능에서만 실패하는지 확인한다. 이어 최근 배포와 설정 변경, CPU·메모리·디스크 사용량, 응용 프로그램 오류, 데이터베이스 연결 상태를 차례로 본다. 디스크가 꽉 찼다면 서버 크기보다 로그나 백업 파일의 보관 설정이 문제일 수 있다.

제가 운영할 때도 장애 대응 순서는 문서 한 장으로 남겨 둔다. 누가 경보를 받고, 어떤 화면과 기록을 먼저 확인하며, 언제 이전 상태로 되돌릴지 적어 두는 것이다. 기업용클라우드의 값어치는 큰 사양을 사는 데서 나오지 않는다. 필요한 용량을 측정하고, 복구가 실제로 되는지 확인하고, 장애 순간에 같은 순서로 움직일 수 있을 때 비로소 운영이 편해진다.