Hetzner 서버는 껐는데 자리값은 계속 나간다

요약

• Hetzner Cloud 서버는 생성이 완료된 뒤 존재하는 동안 과금된다. 전원을 꺼도 배정된 자원이 남으며, 서버 삭제가 해당 자원의 과금 종료를 결정한다.
• 서버에 묶인 자동 백업은 서버와 함께 삭제된다. 별도로 보관하는 스냅샷은 남길 수 있지만, 연결된 별도 볼륨의 데이터까지 담지는 않는다.
• 비수기에 살 것은 ‘꺼진 서버’라는 상태가 아니라 다음 개장 때 필요한 준비다. 기존 자원 유지와 사본 보관은 비용도, 다시 시작하는 조건도 다르다.

내년에도 행사를 하겠다는 고객의 말은 계약서보다 오래 살아남는다. 가상의 작은 제작사를 떠올려 보자. 올해 행사 사이트를 납품했고, 참가 신청은 닫혔다. 담당자는 내년 예산을 아직 모른다. 개발자는 서버를 끈다. 일단 돈도 덜 들겠지 싶다. 다음 청구서를 보는 회계 담당자에게만 행사가 끝나지 않았다.

Hetzner Cloud의 과금 FAQ는 생성된 서버가 존재하는 동안, 전원이 꺼져 있어도 요금을 청구한다고 명시한다. 공급자는 계속 자원을 배정해 두기 때문에 빠르게 다시 켤 수 있다고 설명한다. 사용자가 멈춘 것은 실행 중인 작업이다. 보유한 자리까지 반납한 것은 아니다.

클라우드의 탄력성을 ‘일이 없으면 자동으로 비용도 사라진다’고 이해하면 이 차이를 놓친다. 여기서 고객이 갖고 있는 것은 계산을 수행한 시간만이 아니라 자원을 계속 점유할 선택이다. 꺼진 서버가 결함처럼 보이는 순간에도, 공급자의 장부에는 제공 중인 자원이 남는다.

사진을 남길 것인가, 방을 계속 빌릴 것인가

Hetzner가 장기간 전원을 끌 때 제시하는 방법은 스냅샷을 만든 뒤 서버를 삭제하고, 나중에 그 사본으로 새 서버를 만드는 것이다. 스냅샷 저장에도 비용은 든다. 다만 전체 서버를 유지하는 대신 디스크 상태를 보관하는 쪽이 더 저렴할 수 있다.

작은 제작사에는 매력적인 거래다. 고객이 내년에 돌아올지 모르는데 현장을 통째로 유지할 필요는 없어 보인다. 문제는 무엇을 현장으로 생각하느냐다. 화면 몇 장만 보이는 사이트라도 운영에 필요한 파일과 설정, 외부 연결은 여러 곳에 흩어질 수 있다. 보관할 대상을 정하는 일은 전원을 끄는 일보다 귀찮다. 그래서 종종 다음 달로 밀린다.

백업과 스냅샷 FAQ에는 그 귀찮음을 생략할 수 없게 만드는 차이가 있다. 자동 백업은 서버에 묶여 있어서 서버를 지우면 함께 지워진다. 스냅샷은 서버가 없어져도 남는다. 기존 자동 백업을 보존하려면 스냅샷으로 변환하는 선택이 가능하다.

‘백업이 있으니 지워도 된다’는 말에서 중요한 부분은 백업이라는 단어가 아니다. 삭제 뒤에도 남도록 선택한 사본이 실제로 무엇이냐는 것이다. 행사 마지막 날 수정한 자료가 오래된 사본에 들어갈 리도 없다. 보관은 과거의 특정 시점을 선택하는 행위다.

그 선택은 서버 디스크에서 한 번 더 끝난다. 공식 기능 개요에 따르면 연결된 Volumes는 백업과 스냅샷에 포함되지 않는다. 운영체제가 들어 있는 디스크를 보관했다고, 별도 볼륨에 넣어 둔 행사 자료까지 보관한 것은 아니다. 비용 절감 계획은 데이터가 어디 있는지 아는 사람의 시간을 먼저 요구한다.

주소는 살아남을 수 있다. 주소 요금도 그렇다

고객이 다음 행사 때 같은 주소를 원한다면 서버만 보아서는 답이 안 나온다. Hetzner의 Primary IP는 서버와 별개의 자원이다. Primary IP 안내는 보호되지 않은 주소의 자동 삭제 설정에 따라 서버 삭제 때 주소가 함께 없어지거나 남는다고 설명한다.

남겨 둔 Primary IPv4는 어느 서버에도 배정하지 않았더라도 과금 대상이다. Primary IPv6는 과금 FAQ상 무료다. 서버를 지운 뒤에도 청구서에 주소가 남아 있다면 먼저 보존 의도를 확인할 일이다. 잊힌 비용일 수도 있고, 고객의 다음 접속을 위해 일부러 산 선택권일 수도 있다.

그 선택권에는 지리적 범위가 있다. Primary IP는 같은 위치의 서버에만 배정할 수 있다. 주소 하나를 남겨 두었다고 아무 지역의 새 서버에 가져다 붙일 수는 없다. 고객이 옛 주소를 고집하면, 제작사는 그 주소가 있는 곳에서 다시 자원을 확보해야 한다.

볼륨도 별도로 판단해야 한다. 취소 절차는 볼륨 연결 해제와 삭제를 다른 단계로 다룬다. 연결을 끊어 둔 저장 공간은 반납한 저장 공간과 다르다. 서버 한 개를 지웠다는 완료 보고가 프로젝트 전체의 정산 보고를 대신할 수 없는 이유다.

사본은 다음 서버의 예약권이 아니다

고객에게 ‘필요하면 다시 켜 드립니다’라고 말하기 전에 동사를 골라야 한다. 기존 서버를 다시 켜는 일과 새 서버를 확보해 사본으로 구성하는 일은 다른 작업이다. 후자는 자리가 있어야 시작된다.

일반 Cloud FAQ는 계정 한도, 특정 위치의 자원 부족, 고객별 임시 공급 제한 등을 신규 생성이 되지 않는 이유로 든다. 문서에 설명된 임시 제한에서 기존 서버는 프로젝트에 남는다. 디스크 사본을 가지고 있다는 사실만으로 새 용량까지 보장되지는 않는다.

다른 위치를 택하면 해결될 수도 있지만 기존 Primary IP의 위치 조건을 다시 맞춰야 한다. 위치 안내에 나오는 지역별 가격 차이도 새 선택의 일부다. 이전 구성의 사본과 이전 구성의 경제적 조건은 함께 저장되는 파일이 아니다.

잠깐 만든 시연 사이트라면 이 불편을 받아들이고 서버를 삭제하는 편이 합리적일 수 있다. 개장 시간을 이미 광고한 행사라면 계산이 달라진다. 몇 달의 보유 비용과 재구축 시간, 일정에 쫓길 위험을 함께 놓아야 한다. 컴퓨터가 놀고 있다는 관찰만으로 어느 쪽이 싼지는 결정되지 않는다.

청구서가 도착한 날보다 서비스 기간이 중요하다

Hetzner의 청구 제도는 사용한 뒤 정산하는 방식이다. 서버를 삭제한 다음에 오는 마지막 청구서는 과거의 자원 보유 기간에 대한 것일 수 있다. 삭제 후 이메일이 왔다는 이유만으로 계속 과금 중이라고 판단하면 이미 끝난 일을 다시 조사하게 된다.

반대로 남아 있는 IPv4나 볼륨 요금을 모두 ‘마지막 청구서겠지’ 하고 넘기면 실제 보유 비용이 계속 쌓인다. 자원별 소비 내역에서 어떤 항목이 어느 기간을 덮는지 확인해야 프로젝트가 정말 얼마나 남아 있는지 알 수 있다.

이 가상 제작사의 보관 기간과 자원 목록, 복구 인건비가 없으므로 며칠부터 삭제가 유리한지 계산할 수 없다. 그 세 가지를 채우면 판단은 선명해진다.

고객에게는 세 가지를 구별해 팔면 된다. 현장을 유지하는 서비스, 자료를 보관하고 다시 만드는 서비스, 완전히 종료하는 서비스다. 마지막 가격을 받고 첫 번째 약속을 해 버리면 서버가 꺼져 있는 동안에도 손해 보는 쪽은 생긴다. 그 손해는 전원 표시등에 나타나지 않는다.