모두
모두콘텐츠
얼마 전 작은 쇼핑몰 서버 이전 견적을 봤는데, 방문자가 하루 2천 명인데도 큰 가상 머신과 부하 분산 장치가 들어가 있었습니다. 장애를 줄이겠다는 취지는 이해합니다. 다만 마이크로소프트클라우드에서 웹사이트를 운영할 때는 서버 크기보다 요청량, 전송량, 백업 방식부터 계산해야 월 비용과 장애 위험이 함께 보입니다.
방문자 수를 서버 부하로 바꾸기
여기서 말하는 마이크로소프트클라우드는 웹서버를 올릴 수 있는 애저 중심입니다. 먼저 월 페이지 조회 수와 페이지당 전송량을 기록합니다. 예를 들어 월 10만 페이지 조회, 페이지당 실제 전송량이 1MB라면 단순 계산으로 월 전송량은 약 100GB입니다. 이미지가 별도 저장소나 캐시에서 제공된다면 가상 머신이 직접 내보내는 양은 이보다 적습니다. 반대로 파일 다운로드가 많으면 페이지 조회 수만으로는 전송량을 짐작하기 어렵습니다.
동시접속도 숫자의 뜻을 구분해야 합니다. 접속 중인 사람이 100명이라는 말이 서버가 동시에 요청 100개를 처리한다는 뜻은 아닙니다. 초당 요청 10개가 들어오고 응답에 평균 0.2초가 걸린다면, 그 순간 처리 중인 요청은 평균 약 2개입니다. 다만 평균값만 보면 점심시간 주문이나 행사 시작 직후의 짧은 급증을 놓칩니다. 웹서버 로그에서 가장 바쁜 5분의 초당 요청 수와 응답 시간을 함께 확인하는 편이 낫습니다.
- 정적 페이지 위주인지, 매 요청마다 데이터베이스 조회가 필요한지 구분합니다.
- 평균 CPU 사용률보다 바쁜 시간의 CPU, 메모리, 응답 시간, 디스크 지연을 봅니다.
- 이미지와 첨부파일의 월 전송량을 웹 요청량과 따로 적습니다.
가상 머신 크기는 작게 시작해 측정하기
운영 경험상 방문자가 적은 회사 소개 사이트나 소규모 블로그는 관리형 호스팅이나 저가 상품으로 충분한 경우가 많습니다. 직접 운영할 이유가 없다면 가상 머신을 쓰면서 운영체제 보안 패치, 방화벽, 백업까지 떠안을 필요는 없습니다. 애저가 필요한 경우에도 처음부터 큰 사양을 고르기보다 애플리케이션의 메모리 사용량과 피크 부하를 기준으로 한 단계씩 정하는 게 합리적입니다.
애저의 B 계열 가상 머신은 CPU 사용이 낮을 때 크레딧을 모았다가 짧은 부하에 사용합니다. 간헐적으로 바쁜 웹사이트에는 맞을 수 있지만, CPU를 오래 쓰는 작업이 이어져 크레딧이 떨어지면 기본 성능 수준으로 제한됩니다. 평소 CPU가 낮다고 안심했다가 야간 배치와 낮 시간 트래픽이 겹쳐 사이트가 느려지는 식입니다. B 계열을 쓴다면 CPU 사용률과 함께 남은 크레딧을 경보 항목에 넣어야 합니다.
메모리는 더 단순하게 봅니다. 운영체제와 웹서버, 애플리케이션, 데이터베이스를 한 대에 올릴 계획이라면 각 프로세스의 실제 사용량을 합산하고 여유를 둡니다. 메모리가 모자라 스왑이 늘어나는 서버는 CPU를 늘려도 빨라지지 않습니다. 데이터베이스가 큰 사이트라면 웹서버와 데이터베이스를 분리할 시점도 함께 검토합니다.
월 청구액에서 빠뜨리기 쉬운 항목
가상 머신 화면에 표시되는 시간당 요금만으로 월 예산을 잡으면 틀어집니다. 24시간 가동 서버라면 계산기에서 한 달 약 730시간을 기준으로 놓고, 관리 디스크, 백업 보관, 외부로 나가는 데이터, 공인 IP와 로그 보관 비용을 더해야 합니다. 지역과 운영체제, 디스크 종류에 따라서도 금액이 달라집니다. 가격표의 단일 숫자를 외우기보다 실제 구성으로 월 견적을 다시 뽑는 편이 정확합니다.
특히 서버 안에서 종료한 상태와 애저에서 할당 해제한 상태를 혼동하기 쉽습니다. 전자는 컴퓨팅 요금이 계속 붙을 수 있습니다. 할당을 해제하면 컴퓨팅 과금은 멈추지만 디스크와 일부 네트워크 자원 비용은 남습니다. 개발 서버를 밤에 끄는 자동화를 만들었다면 다음 청구서에서 상태와 과금 항목을 확인해야 절감액을 알 수 있습니다.
월 100GB를 전송하는 사이트와 월 2TB를 전송하는 사이트는 같은 가상 머신을 써도 청구 구조가 다릅니다. 동영상과 대용량 파일을 서비스한다면 서버 CPU보다 전송 비용과 캐시 효과를 먼저 계산합니다. 반면 방문자도 파일도 적은 사이트에 복잡한 분산 구성을 얹으면 운영할 지점만 늘어납니다.
이전과 백업은 복구 순서까지 적기
서버 이전에서 자주 보는 사고는 새 서버가 켜지지 않는 문제가 아닙니다. 접속은 되는데 주문 데이터가 빠졌거나, 인증서 갱신과 메일 설정을 놓치는 경우가 더 까다롭습니다. 이전 전에는 파일과 데이터베이스를 각각 백업하고, 새 환경에 복원해 로그인·주문·메일 발송 같은 핵심 동작을 시험합니다. 도메인 설정을 바꾸기 전에는 기존 서버를 바로 지우지 말고 되돌릴 시간을 확보합니다.
DNS 전환을 앞두고는 바뀔 레코드와 기존 값을 기록합니다. TTL을 미리 낮추면 전환 후 오래된 정보가 남는 시간을 줄이는 데 도움이 되지만, 모든 이용자의 전환 시각이 같아지는 것은 아닙니다. 그래서 전환 직후 일정 기간은 구 서버와 신 서버의 로그를 함께 보고, 쓰기 작업이 두 곳으로 갈라지지 않도록 데이터베이스 경로를 명확히 정해야 합니다.
애저 백업의 복구 지점도 생성 성공 표시만 보고 끝내지 않습니다. 데이터베이스처럼 쓰기 중인 데이터는 백업 시점의 일관성이 중요합니다. 별도 환경에 실제로 복원해 서비스가 시작되는지, 어느 시점까지 데이터가 돌아오는지 확인해야 합니다. 장애가 나면 DNS와 인증서, 서버 상태, 웹서버 로그, 애플리케이션 로그, 데이터베이스 연결, 최근 배포 순서로 확인합니다. 사이트를 오래 운영할수록 큰 서버 한 대보다 검증한 복구 절차 한 장이 더 든든했습니다.
