모두
모두콘텐츠
얼마 전 월 방문자 3만 명인 블로그의 서버 견적을 봤는데, 유료 인스턴스 두 대와 관리형 데이터베이스가 들어가 있었습니다. 접속 기록을 보니 가장 바쁜 시간에도 동적 요청은 초당 1건이 채 안 됐습니다. 이런 사이트라면 오라클 클라우드 무료 자원부터 검토할 만합니다. 다만 서버를 무료로 띄우는 것과 장애가 나도 운영을 이어가는 것은 별개입니다.
방문자 수보다 바쁜 시간의 요청을 먼저 계산한다
월간 방문자 수만으로 CPU를 고르면 대개 사양을 크게 잡게 됩니다. 예를 들어 하루 페이지 조회가 5천 회이고 페이지당 실제 전송량이 1MB라면 전송량은 하루 약 5GB, 한 달 약 150GB입니다. 이미지가 캐시에서 제공된다면 서버가 직접 처리하는 양은 더 줄어듭니다. 반대로 페이지 하나가 데이터베이스를 여러 번 조회하고 캐시도 없다면 같은 방문자 수에서도 CPU 사용량이 달라집니다.
동시접속도 따로 봐야 합니다. 하루 5천 회 조회는 평균으로 초당 약 0.06회입니다. 가장 바쁜 시간이 평균의 20배라면 초당 약 1.2회이고, 요청 처리에 0.5초가 걸리면 동시에 처리 중인 동적 요청은 대략 1건 수준입니다. 이 계산은 시작점일 뿐입니다. 배치 작업, 관리자 화면, 검색 기능처럼 오래 걸리는 요청이 있는지도 접속 기록에서 확인해야 합니다.
오라클 문서상 상시 무료 자원에는 AMD 마이크로 인스턴스 최대 2대와 Arm 기반 Ampere A1 자원이 있습니다. A1의 월 무료 한도는 1,500 OCPU 시간과 9,000GB 시간으로, 무료 계정에서 계속 가동하는 구성으로는 총 2 OCPU와 메모리 12GB에 해당합니다. 블록 스토리지는 부팅 볼륨을 포함해 총 200GB, 외부로 나가는 데이터는 월 10TB가 무료 범위입니다. 숫자만 보면 작은 블로그나 개발 서버에는 넉넉하지만, 실제 사용량과 계정의 현재 한도는 생성 전에 콘솔에서 다시 확인하는 편이 안전합니다.
인스턴스를 만들 때 무료 범위부터 확인한다
처음에는 A1 한 대에 1 OCPU와 메모리 6GB 정도를 배정하고 지표를 보는 편이 낫습니다. CPU와 메모리를 처음부터 모두 쓰면 다른 작업을 시험할 여지가 없어집니다. Arm에서는 x86 전용 실행 파일이나 일부 컨테이너 이미지가 동작하지 않으므로, 쓰려는 웹서버·언어 런타임·데이터베이스의 Arm 지원 여부를 먼저 확인해야 합니다. 호환성 확인이 어렵고 서비스가 아주 작다면 AMD 마이크로도 선택지지만, 메모리가 1GB라 여러 서비스를 함께 올리기에는 빠듯합니다.
부팅 볼륨은 기본 크기부터 시작합니다. 오라클 문서에는 인스턴스 생성 시 부팅 볼륨이 약 50GB로 잡히며, 이 용량이 무료 블록 스토리지 200GB에 포함된다고 안내돼 있습니다. 서버를 지웠는데 부팅 볼륨을 남겨두면 새 서버를 만들 때 저장 공간 한도에 걸릴 수 있습니다. 무료 자원은 홈 리전에 만드는 조건도 확인해야 합니다. 특히 다른 리전에 만든 블록 볼륨은 일반 요금이 붙을 수 있습니다.
무료 체험 크레딧으로 만든 자원과 ‘상시 무료’ 표시가 붙은 자원도 구분해야 합니다. 체험 기간에 더 큰 인스턴스를 만들 수 있다고 해서 기간 종료 후에도 계속 무료인 것은 아닙니다. 생성 화면에서 인스턴스 형태, 볼륨, 리전을 각각 확인하고, 유료 계정이라면 예산 알림과 사용량 화면도 함께 설정합니다. 원하는 A1 자원이 없다는 오류는 해당 리전의 일시적인 수용량 부족일 수 있습니다. 이때 급하게 유료 형태로 바꾸기보다 다른 가용 영역을 확인하거나 시간을 두고 다시 시도하는 게 비용 면에서 낫습니다.
접속 설정은 클라우드와 서버 안에서 두 번 확인한다
인스턴스를 만든 뒤 접속이 안 되는 경우는 성능보다 네트워크 설정 문제가 많습니다. 공인 IP가 있는지, 서브넷 경로가 인터넷으로 열려 있는지, 보안 목록이나 네트워크 보안 그룹에서 필요한 포트가 허용됐는지 순서대로 확인합니다. 그다음 운영체제 방화벽과 웹서버의 수신 주소를 봅니다. 클라우드 쪽에서 80번 포트를 열어도 서버 안에서 막고 있으면 브라우저에는 응답이 오지 않습니다.
SSH는 비밀번호 접속보다 키 인증을 쓰고, 관리용 22번 포트는 가능하면 접속할 IP 범위를 좁힙니다. 웹 서비스에 필요한 80번과 443번만 공개하고 데이터베이스 포트는 외부에 열지 않습니다. 도메인을 연결했다면 DNS가 새 서버 IP를 가리키는지 확인한 뒤 인증서를 발급합니다. 무료 인증서도 충분하지만 자동 갱신이 실제로 작동하는지는 별도로 점검해야 합니다. 인증서가 만료돼 접속 경고가 뜨는 사고는 서버 사양을 올려도 막을 수 없습니다.
백업 복원까지 해봐야 운영 준비가 끝난다
무료 서버에서 가장 먼저 챙길 것은 복구 경로입니다. 오라클의 무료 블록 볼륨 백업은 최대 5개까지 제공되지만, 같은 계정 안의 볼륨 백업만으로는 계정 접근 문제나 설정 실수에 대응하기 어렵습니다. 데이터베이스 덤프와 업로드 파일을 주기적으로 별도 저장소에도 보관하고, 최소 한 번은 빈 서버에 복원해 봐야 합니다. 백업 파일이 존재하는 것과 서비스가 다시 뜨는 것은 다릅니다.
장애가 나면 먼저 인스턴스 상태와 CPU·메모리·디스크 사용량을 봅니다. 이어서 공인 IP, 방화벽, 웹서버 프로세스, 데이터베이스 연결, 최근 배포 기록을 확인합니다. 디스크가 가득 찼다면 로그 증가나 실패한 백업 파일이 원인인 경우가 많습니다. 오라클은 7일 동안 CPU 95백분위 사용률, 네트워크 사용률, A1의 메모리 사용률이 모두 20% 미만인 무료 인스턴스를 유휴 상태로 판단해 회수할 수 있다고 안내합니다. 억지로 부하를 만드는 대신 중요한 서비스라면 이 정책까지 감안해 복구 가능한 구성을 갖추는 편이 맞습니다.
작은 사이트에는 오라클 클라우드 무료 자원만으로 충분한 구간이 꽤 넓습니다. 그래도 방문자가 늘었을 때보다 백업을 되살리지 못했을 때 더 오래 멈춥니다. 저는 처음부터 큰 서버를 사기보다 작은 구성으로 측정하고, 복원 절차에 시간을 쓰는 쪽을 권합니다.
