모두
모두콘텐츠
얼마 전 작은 쇼핑몰 서버를 옮기면서 기존 사양을 봤는데, CPU는 대부분 한가했고 디스크만 거의 차 있었습니다. 더 큰 요금제로 바꿀 일이 아니었죠. 로그 보관 방식과 백업 위치를 고치고 여유 공간을 확보하니 장애 위험이 훨씬 줄었습니다. 윈도우서버를 고를 때도 먼저 볼 것은 업체가 권하는 사양이 아니라 실제 작업량과 복구 방법입니다.
윈도우서버가 필요한 작업부터 확인한다
운영할 프로그램이 IIS, 윈도우 전용 응용 프로그램, 특정 데이터베이스 기능에 의존한다면 윈도우서버를 쓸 이유가 분명합니다. 반면 정적 페이지나 일반적인 블로그만 운영한다면 윈도우 라이선스 비용까지 부담할 필요가 있는지 따져봐야 합니다. 같은 월 요금으로 표시된 상품이라도 운영체제 라이선스, 백업 저장 공간, 데이터 전송량이 포함됐는지는 다를 수 있습니다.
관리형 웹호스팅은 서버 설정을 직접 만질 일이 적을 때 편합니다. VPS는 원격 접속, IIS 설정, 작업 스케줄러, 자체 프로그램 설치가 필요할 때 맞습니다. 여러 서버로 나누거나 장애 시 자동 복구가 필요한 단계라면 클라우드 기능을 검토할 만합니다. 방문자가 적은 사이트에 처음부터 복잡한 구성을 얹으면 비용보다 관리 실수가 먼저 늘어납니다.
방문자 수보다 피크 요청과 메모리를 본다
월 방문자 수만으로 CPU를 고르면 대개 빗나갑니다. 하루 3만 페이지 조회가 있고 한 페이지 전송량이 평균 2MB라면 한 달 전송량은 약 1.8TB입니다. 하루 평균은 초당 0.35페이지 정도지만, 바쁜 시간에 요청이 평균의 10배 몰린다고 가정하면 초당 약 3.5페이지가 됩니다. 이때 전송량은 대략 55Mbps입니다. 이미지가 외부 저장소에서 나가거나 캐시가 잘 작동하면 서버가 직접 처리하는 양은 줄어듭니다. 반대로 한 페이지가 여러 번의 API 호출을 일으키면 요청 수는 더 늘어납니다.
가벼운 IIS 사이트이고 데이터베이스를 별도로 둔다면 2 vCPU와 메모리 4GB에서 측정을 시작할 수 있습니다. 다만 4GB는 응용 프로그램에 따라 금방 좁아집니다. 서버에서 데이터베이스까지 함께 돌리거나 관리 화면의 작업이 무겁다면 8GB 이상을 검토하는 편이 안전합니다. 이 수치는 구매 보증선이 아니라 측정 출발점입니다. 마이크로소프트가 제시하는 설치 최소 사양은 실제 운영 여유분을 뜻하지 않습니다.
첫 주에는 바쁜 시간의 CPU 사용률, 사용 가능한 메모리, 디스크 응답 시간, IIS의 현재 연결과 요청 대기 상태를 기록합니다. CPU가 순간적으로 치솟는 것보다 높은 사용률이 계속되는지가 중요합니다. 메모리가 부족해 페이징이 늘거나 디스크 대기가 길다면 CPU를 추가해도 체감 속도는 거의 안 바뀝니다. 저장 공간도 운영체제와 사이트 파일 크기만 계산하면 부족합니다. 업데이트, 로그, 임시 파일, 데이터베이스 증가분까지 포함해 여유를 남겨야 합니다.
설치 직후에는 접속 경로와 갱신 작업을 점검한다
원격 데스크톱 포트를 인터넷 전체에 열어 둔 채 운영하는 사례를 아직도 봅니다. 관리 접속은 VPN이나 허용한 IP로 제한하고, 관리자 계정은 평소 작업용 계정과 분리하는 편이 낫습니다. 운영체제와 응용 프로그램 업데이트는 일정에 넣되, 재시작이 필요한지 먼저 확인합니다. 자동 업데이트가 새벽 주문 처리나 예약 작업을 끊는 경우가 있기 때문입니다.
웹사이트를 올린 뒤에는 IIS 바인딩, 방화벽의 웹 접속 규칙, 도메인 연결, SSL 인증서의 대상 이름과 만료일을 함께 확인합니다. 인증서 파일만 바꿔 놓고 바인딩이 예전 인증서를 가리키는 일도 있습니다. 자동 갱신을 설정했다면 실제 갱신과 적용이 되는지 시험해야 합니다. 인증서 만료 경고는 서버가 멈췄을 때만큼 빠르게 방문자를 잃게 만듭니다.
백업은 복구 시간을 기준으로 설계한다
스냅샷 한 개를 백업이라고 부르면 곤란합니다. 같은 계정이나 같은 저장소에만 남은 복사본은 계정 문제나 저장소 장애에 함께 영향을 받을 수 있습니다. 사이트 파일, 데이터베이스, IIS 설정, 인증서와 비밀키를 각각 어디서 복구할지 적어 둡니다. 데이터베이스는 파일 복사 시점의 일관성이 중요하므로 사용 중인 제품에 맞는 백업 기능을 써야 합니다. 인증서 비밀키와 백업 접근 권한은 따로 보호합니다.
예를 들어 주문 데이터를 최대 1시간까지만 잃을 수 있다면 백업 또는 변경 기록을 그보다 촘촘하게 확보해야 합니다. 장애 후 2시간 안에 다시 열어야 한다면 새 서버 준비, 데이터 복원, 접속 경로 변경을 실제로 2시간 안에 끝낼 수 있는지도 시험해야 합니다. 백업 성공 알림만 보고 안심하지 말고, 별도 환경에 파일과 데이터베이스를 복원해 화면과 로그인까지 확인합니다. 복구해 본 적 없는 백업은 시간이 얼마나 걸릴지 알 수 없습니다.
서버 이전과 장애 대응은 순서를 정해 둔다
이전할 때는 먼저 현재 서버의 설정과 데이터를 확보하고 새 서버에서 내부 점검을 끝냅니다. 전환 전에는 도메인 연결 정보의 캐시 유지 시간을 줄이고, 쓰기 작업이 있는 사이트라면 데이터가 갈라지지 않도록 마지막 동기화 시점과 잠시 멈출 작업을 정합니다. 새 서버에서 인증서, 로그인, 결제나 문의 저장, 예약 작업을 확인한 뒤 접속 경로를 바꿉니다. 이전 서버는 바로 지우지 말고 되돌릴 수 있는 기간을 둡니다.
사이트가 안 열릴 때는 접속 위치부터 나눠 봅니다. 서버 자체에 접속되는지, IIS 사이트와 응용 프로그램 풀이 살아 있는지, 디스크가 찼는지, 인증서와 방화벽에 문제가 있는지 순서대로 확인합니다. 접속은 되는데 느리다면 바쁜 시간의 CPU·메모리·디스크 수치와 응용 프로그램 로그를 같은 시각에 맞춰 봅니다. 저는 새 서버를 주문하기 전에 이 기록부터 봅니다. 숫자가 병목을 가리킬 때 사양을 올리면 비용을 쓰고도 문제를 못 고치는 일을 줄일 수 있습니다.
