요약

  • Cold Vault의 최소 과금 크기는 객체당 256 KB, 최소 보관 기간은 90일이다. 4 KB 객체를 가정하면 용량 과금의 기준은 실제 크기의 64배가 된다.
  • 전체 요금은 단가와 기간, 요청, 데이터 읽기 등에 따라 달라진다. 작은 객체를 묶으면 최소 과금의 반복을 줄일 수 있지만 개별 읽기·수정·삭제·복원 방식도 함께 바뀐다.

할인 협상에서 빠진 곱셈

구매팀이 GB당 가격을 깎고 있다. 개발팀은 작은 기록을 각각 별도 객체로 저장하기로 했다. 두 팀 모두 자기 일을 잘했다고 보고할 수 있다. 청구서는 두 결정을 곱한 값을 들고 온다.

IBM Cloud Object Storage의 Cold Vault가 그 접점을 잘 보여준다. IBM은 객체당 최소 과금 크기를 256 KB, 최소 보관 기간을 90일로 명시한다. Vault의 기준은 128 KB와 30일이다. Standard와 Smart Tier에는 최소 크기와 최소 보관 기간이 없고 데이터 검색 요금도 없다. 요청이나 공용 인터넷으로 나가는 전송 비용은 별도 항목이다.저장 클래스 안내

4 KB짜리 객체를 하나 가정해 보자. Cold Vault의 용량 과금 기준은 256 KB이므로 비율은 64배다. Vault라면 32배다. 작은 짐이 큰 방 하나를 통째로 빌리는 셈이다. 여기서 64는 용량 기준의 비율이며, 실제 총요금은 여기에 단가, 시간, 각종 작업을 적용해 계산한다.

모든 객체가 4 KB이고 최소 보관 기간을 이미 채운다는 조건에서는 계산이 더 선명하다. Cold Vault의 용량 비용이 Standard보다 낮으려면 용량 단가가 Standard의 64분의 1보다 낮아야 한다. 그 선을 넘는지는 적용되는 견적이 답한다. 드물게 읽는다는 이유 하나로 저렴한 저장소가 자동으로 결정되지는 않는다.

데이터는 같은데 구매 수량이 다르다

기업의 예산표는 보통 총 데이터양에서 출발한다. 올해 얼마나 쌓였고 내년에 얼마나 늘어날지 적는다. 객체별 최저선이 있는 상품에서는 여기에 객체 수를 반드시 붙여야 한다.

같은 기록들을 하나씩 따로 저장하는 경우와 큰 묶음으로 저장하는 경우를 비교해 보자. 따로 저장하면 작은 객체마다 최저선이 적용된다. 묶으면 묶음마다 적용된다. 보관하는 정보는 그대로여도 과금 용량은 달라질 수 있다. 공급자가 파는 단위를 몇 번 만드는지가 달라졌기 때문이다.

평균 객체 크기도 충분하지 않다. 소수의 큰 객체가 평균을 끌어올리는 동안 수많은 작은 객체가 최저선 아래에 남아 있을 수 있다. 크기 구간별 개수가 필요하다. 각 객체의 실제 크기와 해당 클래스의 최소 크기 중 큰 값을 고른 뒤 모두 더하면, 어떤 객체들이 과금 기준을 키우는지 드러난다.

IBM의 청구 문서는 같은 인스턴스에서 같은 클래스의 사용량을 여러 버킷에 걸쳐 합산한다고 설명한다. 이 합산이 객체별 최저선을 버킷 전체의 공동 한도로 바꾸지는 않는다. 문서는 저장 용량, 요청, 공용 네트워크 전송도 구분한다.청구 방식

압축에서도 차이가 난다. 이미 256 KB보다 작은 객체를 더 줄이면 실제 내용은 작아진다. 그러나 Cold Vault의 최소 과금 크기는 남는다. 압축률이 좋아졌다는 기술 보고와 용량 청구가 그대로라는 재무 보고는 동시에 맞을 수 있다. 줄인 대상이 서로 다르다.

묶음 할인에는 개발 업무가 따라온다

작은 객체를 합치는 방법은 분명 매력적이다. 최소 과금 단위를 반복해서 사는 횟수가 줄어든다. 다만 독립된 객체가 제공하던 편리함도 어디선가 다시 만들어야 한다.

각 기록에는 이름과 접근 경계가 있었다. 하나를 읽고, 하나를 바꾸고, 하나를 지울 수 있었다. 묶음 안으로 들어가면 애플리케이션은 기록의 위치를 아는 색인을 유지해야 한다. 수정과 삭제를 어떻게 반영할지도 정해야 한다. 형식과 읽기 방식에 따라 필요한 부분만 가져올 수도 있고 더 많은 데이터를 옮겨야 할 수도 있다.

자주 바뀌는 작은 기록을 생각하면 대가가 보인다. 작은 수정이 큰 묶음의 재작성으로 이어질 수 있다. 개별 삭제가 필요하면 저장된 내용에서 그 삭제를 어떻게 실현할지 설계해야 한다. 복원할 때는 내용과 색인이 맞는지 확인해야 한다. 용량 비용이 줄어든 만큼 요청, 읽기, 운영 업무가 늘어날 수 있다.

어느 쪽이 합리적인지는 제품이 요구하는 동작에 달려 있다. 개별 조작의 자유가 중요한 데이터에는 그 자유를 살 이유가 있다. 함께 움직이는 기록에는 묶음이 맞을 수 있다. 구매팀이 받아야 할 표는 객체 수 감소뿐 아니라, 같은 서비스를 유지하는 데 필요한 추가 작업까지 담은 표다.

저장 클래스도 기존 버킷의 설정 하나를 바꿔 끝낼 수 있는 선택은 아니다. IBM은 버킷을 만들 때 클래스를 선택하며 기존 버킷의 클래스는 바꿀 수 없다고 명시한다. 원하는 클래스의 다른 버킷으로 객체를 옮기거나 복사해야 한다.클래스 설정 버킷 설명

따라서 나중에 더 싼 클래스로 옮긴다는 계획에는 목적지, 복사 작업, 애플리케이션의 참조 위치, 결과 확인이 들어가야 한다. 선택권의 가치는 크다. 그 권리를 행사할 비용을 빼고 계산하면 가치는 과장된다.

차가운 데이터라는 따뜻한 안심

특정 고객의 절감액을 계산하려면 객체 크기 분포, 보관 기간, 읽기 패턴, 적용 견적이 필요하다.

그 자료를 모으는 순서는 명확하다. 단가보다 객체 집단을 먼저 본다. 오래 남는 작은 객체와 금방 지우는 작은 객체를 구분한다. 거의 읽지 않는다는 특성과, 필요할 때 한 건씩 읽어야 한다는 요구도 따로 본다. 둘을 모두 차가운 데이터라는 말로 덮으면 중요한 비용 차이가 사라진다.

IBM은 최저선을 공개했다. 구매자는 계약 전에 계산할 수 있다. 정작 어려운 일은 회사 안에서 책임을 연결하는 것이다. 개발팀이 만드는 과금 단위의 개수와 구매팀이 협상하는 단가가 같은 의사결정 안에 들어와야 한다. 할인율만 훌륭한 구매는, 빌릴 필요가 없던 방까지 싸게 빌리는 재주가 될 수 있다.

원자료

저장 규칙은 위 IBM 공식 문서에 근거한다. RIPE NCC 회원 기록은 International Business Machines Corporation의 디렉터리 신원 확인에만 사용했다. 4 KB는 계산을 위해 설정한 가정이다.