클라우드 비용 최적화 로드맵 #4 - 스토리지의 단가를 최적화하는 법

여는 말

안녕하세요. SK텔레콤 최준승입니다. 오늘은 연재 네 번째 시간입니다. 지난 회차에서는 컴퓨팅의 단가를 최적화하는 법을 알아봤고요. 오늘은 스토리지의 단가를 최적화하는 법을 알아보도록 하겠습니다. 사실 클라우드 서비스들은 대부분 컴퓨팅 / 스토리지 / 네트워크 영역을 복합적으로 갖고 있어서, 이런 식의 기계적인 영역 구분이 좀 부자연스럽다고 생각하실 수도 있는데요. 이것은 어디까지나 설명을 직관적으로 하기 위한 분류입니다. 따라서 독자 여러분들도 각 서비스마다 복수 영역의 과금 요소가 있다는 것을 염두에 두고 글을 읽으시면 좋을 것 같네요.

비용 최적화를 정의하는 다양한 문장이 있는데요. AWS의 표현 중 하나를 빌리면 다음과 같습니다.

여기서 스토리지는 시스템의 한 구성 요소로서 데이터를 저장하고 읽기/쓰기를 지원하는 등의 기능적인 역할을 합니다. 그리고 이것을 가장 낮은 비용으로 실현하면 스토리지 영역의 비용 최적화가 됩니다. 오늘은 단위 비용을 구성하는 2가지 요소 - 단가와 사용량 - 중에서 스토리지의 단가를 최적화하는 법에 집중해 보도록 하겠습니다.

오늘의 메인 주제를 미리 말씀드리자면, 스토리지의 단가 최적화 전략은 적합한 타입(또는 클래스)을 선정하는 것이라 할 수 있습니다. 3회차에서는 컴퓨팅 영역의 단가를 낮추는 3가지 방법론을 따로따로 설명했었는데요. 이번 편에서는 스토리지 서비스를 크게 3가지 유형(Block Storage, Object Storage, File Storage)으로 나눈 다음, 블록 타입은 올바른 타입 선정, 객체 타입은 Tiering을 위주로 내용을 전개하겠습니다. 추가적으로, 관리 측면에서 Tiering의 자동화 관리 영역도 함께 다뤄보겠습니다.

스토리지 자원을 빌려 쓰는 사용자 입장에서 클라우드 환경은 레거시 환경에 비해 자유도가 높은 편입니다. 제공하는 스토리지 유형이 다양하고, 스토리지 유형 및 성능 요소를 변경할 수 있는 여지가 많습니다. 스토리지 유형 및 성능 요소는 곧 단가를 결정하는 기준점이기 때문에, 해당 설정을 기민하게 정의하는 것이 곧 스토리지의 단가를 최적화하는 방안이 됩니다.

스토리지 유형별 과금 특성부터 알아보자

본론에 들어가기에 앞서 한 가지 알아두어야 할 것이 있습니다. 바로 클라우드에서 제공하는 스토리지 서비스의 유형인데요. 클라우드는 다양한 스토리지 유형을 제공합니다. VM 자원에 붙여 쓰는 Block Storage, NFS 같은 프로토콜 기반으로 공유 스토리지 등으로 활용하는 File Storage가 있고요. 그리고 일반적인 파일시스템 구조에서 벗어나 높은 내구성과 낮은 저장 요금을 제공하는 Object Storage도 있습니다.

기본적인 용도부터 통신 인터페이스, 과금 구조까지 다른 점들이 많지만 오늘은 비용 관점에서 각 서비스의 과금 구조가 어떻게 다른지부터 확인해 보려고 합니다. 각 서비스 유형별로 단가와 사용량을 정의하는 요소를 알고 있어야, 2가지 변수의 조정을 통해 비용을 제어하는 방식을 이해할 수 있기 때문입니다. 참고로 오늘 예시도 모두 AWS 서비스 기준으로 진행합니다.

AWS는 EBS라고 부르는 블록 스토리지 서비스를 제공합니다. EBS의 단가는 볼륨 유형이 결정하고, 사용량은 Provisioning 한 볼륨 크기로 산정됩니다. 그 위 계층의 파일 시스템에서 파일이 몇 개고 얼마큼의 데이터를 저장하는지는 과금 관점의 사용량에 영향을 끼치지 않습니다. 말 그대로 EBS는 블록 레벨의 스토리지이기 때문이죠. 예를 들어 내가 특정 SSD 타입의 볼륨을 100GB 크기로 만들었다면, 100GB 내에 데이터를 10GB를 저장하든 20GB를 저장하든 과금은 사용량 100GB 기준으로 계산됩니다. 반면 단가는 볼륨의 물리적인 특성(HDD / SSD)과 부가적인 성능 특성(Throughput 등)에 따라 정해집니다.

S3는 AWS에서 제공하는 객체 스토리지 서비스입니다. 객체 스토리지는 블록 스토리지와 개념부터 좀 다릅니다. 일단 내가 어느 정도 용량을 점유해서 쓰겠다고 미리 정의할 필요가 없습니다. (적어도 사용자 관점에서는) 용량 제한이 없는 무제한의 스토리지 공간이고, 내가 원하는 만큼의 데이터를 자유롭게 읽고 쓰고 지울 수 있습니다. 저장 단위는 객체(Object)이며 객체별로 Storage Class를 정의할 수 있습니다. 그리고 이 Storage Class가 객체 스토리지의 각종 단가를 결정합니다. 사용량(저장요금 기준)은 각 Storage Class별로 저장한 객체 크기의 총합이 됩니다. 예를 들어 내가 1GB짜리 객체를 A Class로 10개 저장하고, 10GB짜리 객체를 B Class로 10개 저장했다면 전체 요금은 다음과 같습니다.

• 전체 요금 = (A Class 단가) x 10GB + (B Class 단가) x 100GB + α

여기서 α는 각 Object별로 GET, PUT 등의 Operation을 수행했을 때 부과되는 등의 부대 비용입니다. 이 비용 역시 각 Storage Class별로 단가가 다르게 설정되어 있습니다. 블록 스토리지와 비교해 보면 단가를 결정하는 단위나 사용량을 집계하는 방식이 다른 것을 확인할 수 있습니다.

마지막으로 AWS에서 제공하는 파일 스토리지 서비스는 EFS, FSx 등이 있습니다. 이건 셈법이 좀 복잡한데요. 일단 EFS 기준으로 예시를 들어보겠습니다. 일단 EFS에서 파일 시스템을 처음 만들 때 몇 가지 속성을 선택하게 됩니다. 성능 구조는 어떻게 할지(Elastic Throughput vs Legacy Throughtput), 데이터는 어느 범위에 저장할지(Multi-AZ vs Single-AZ)를 정합니다. 그리고 여기서 선택한 결과에 따라 각기 다른 단가 테이블이 적용됩니다. 이 단가 테이블에는 각 파일의 Class(Standard / IA / Archive 등)별로 각기 다른 저장 단가가 정의되어 있습니다. 한편 파일 스토리지에서 Class를 운용하는 방식은 객체 스토리지의 방식과 좀 다른데 이건 너무 복잡해서 뒤에서 다시 언급하겠습니다.

핵심을 요약하면 각 스토리지 서비스 유형별로 고유한 특성이 있습니다. 스토리지를 연결하고 데이터를 읽고 쓰는 방식뿐만 아니라, Type(또는 Class)을 지정하는 단위나 사용량을 집계하는 기준이 각기 다릅니다. 그리고 이 기준에 따라 각 스토리지의 단가와 사용량이 집계되고, 계산된 복수의 비용 항목을 합쳐서 스토리지 전체 비용이 산출됩니다. 오늘은 스토리지의 단가를 최적화하는 특집이니 각 스토리지의 단가를 결정하는 요소에 집중하시면 되고요. 앞서 말씀드린 것처럼 단가를 결정짓는 요소들은 고정적인 것이 아니라 대부분 "변경 가능한 것"입니다. 따라서 변경 기준점을 잡기 위해 현재 사용중인 스토리지의 데이터 특성(가용성 / 엑세스 패턴 / 수명 주기 등)을 파악할 필요가 있습니다.

첫 번째, Block Storage 조정 전략

지금부터 각 스토리지 유형별로 단가 최적화 전략을 살펴보도록 하겠습니다. 첫 순서는 블록 스토리지입니다. 블록 스토리지의 단가 최적화 전략은 단순합니다. 단가가 낮은 볼륨 유형을 사용하면 됩니다. 아 물론 무조건 낮은 단가의 볼륨 유형을 사용하라는 말은 아니고요. 스토리지 사용 패턴에 맞추되 그중 가장 낮은 단가의 선택지를 고르면 됩니다. 직관적인 설명을 위해 개략적인 EBS의 요금표를 같이 한번 보시겠습니다.

위 그림을 보시면 EBS의 단가는 2가지로 결정되는 것을 알 수 있습니다. 하나는 Volume Type(GP2 / GP3 / IO1 / IO2 / ST1 / SC1), 다른 하나는 성능값(IOPS, Throughput)입니다. 모든 볼륨 타입에는 (GB당) 저장 단가가 있고요. 특정 볼륨 타입(GP3, IO1, IO2)에는 설정한 성능값에 따른 추가 비용이 있습니다. 물론 EBS 사용자가 지불하는 금액은 저장 비용 + 추가 비용입니다. 서로 다른 타입의 볼륨을 비교할 때는 이 전체 금액을 기준으로 해야 합니다.

대부분의 EBS 사용 패턴을 커버하는 정답은 "최신 세대"의 "일반 SSD 타입"을 "필요한 성능값에 맞춰" 사용하는 것입니다. 24년 6월 기준으로는 GP3를 적절한 성능값으로 사용하면 됩니다. 사실 GP3 타입은 기본 성능값(125MB/s, 3000 IOPS)이 있어서, 이 수준으로도 특별한 성능 이슈가 없다면 추가적인 성능값을 정의할 필요도 없습니다. 이 경우는 GP3의 저장 단가만 적용된다고 생각하셔도 됩니다.

물론 HDD 계열의 타입(ST1 / SC1)이 단가 최적화 측면에서 유리한 경우도 있습니다. 절대적인 저장 단가는 GP3 타입에 비해 적게는 45%에서 크게는 80%까지 저렴하기 때문입니다. (SSD가 상대적으로 유리한) Random 읽기/쓰기 작업이 거의 없고 성능을 크게 고려할 필요 없는 저장소의 경우, HDD 계열의 타입을 고려할 수 있지만 일반적으로 사용 빈도는 그리 높지 않습니다.

최신 세대를 추천하는 이유, 즉 GP2보다 GP3 타입을 권장하는 이유는 GP3의 저장 단가가 GP2의 단가보다 20% 정도 저렴하기 때문입니다. 2가지 타입의 성능 특성을 들여다보면 좀 복잡한데(성능 Bursting 유무, IOPS Baseline 값이 결정되는 기준), 결과적으로 GP3가 유리한 경우가 대부분입니다. 특히 볼륨 크기가 그리 크지 않은 일반적인 환경(1TB 미만)에서는 GP3 타입의 전체적인 성능 밸런스가 더 좋습니다.

그리고 마지막으로 Provisioned IOPS 계열(IO1 / IO2)을 고려하는 경우가 있습니다. DB와 같이 안정적으로 높은 성능의 읽기/쓰기를 수행해야 하는 경우, 이 계열의 타입이 필요할 수 있는데요. 물론 설정값에 따라 다르겠지만 Provisioned IOPS 계열은 계산기를 돌려보면 예상보다 큰 비용이 산출되는 경우가 많기 때문에 주의해야 합니다. 실제 필요한 성능값에 비해 너무 높은 값을 설정한 경우 불필요하게 높은 단가를 지불해야 하므로 해당 값을 재조정할 필요성도 있습니다. 그리고 이 평가 과정에서 일부는 GP3 같은 범용 SSD 타입으로 전환하는 것이 유리한 경우도 있습니다. 논외로 정말 고성능의 I/O가 필요한 환경이라면 EBS 볼륨을 Instance Store같은 Local Storage로 전환하는 것도 고려해 볼 수 있습니다.

*출처: https://turbot.com/guardrails/blog/2020/12/aws-ebs-cost-savings

사실 블록 스토리지의 단가 측면에서 어떤 타입이 어떤 타입보다 유리하다는 기준은 각자의 상황에 따라, 또 새로운 타입의 출시에 따라 계속 바뀌는 것이기 때문에 큰 의미가 없습니다. 여러분들이 기억하셔야 할 부분은 2가지인데요. 첫 번째, 내가 필요한 스토리지의 성능 특성을 뒷받침한다는 가정하에 가장 합리적인 단가의 볼륨 유형을 선정한다. 두 번째, 볼륨 유형 및 성능값은 추후 실시간으로 변경이 가능하므로 CloudWatch 등에서 확인된 지표를 바탕으로 볼륨 유형 또는 성능값을 재조정한다. 이것이 블록 스토리지의 단가를 최적화하는 가장 단순하고 직관적인 정답입니다.

두 번째, Object Storage 조정 전략

이번엔 객체 스토리지의 단가 최적화 전략을 다뤄보도록 하겠습니다. 단가 측면에서 블록 스토리지와 가장 큰 차이점은 단가를 결정짓는 단위가 볼륨이 아닌 객체(Object)라는 것입니다. 그렇기 때문에 각 객체별로 Class를 어떤 기준에 따라 어떤 방식으로 관리할지를 정하는 표준 정책이 필요합니다. 먼저 Tiering의 개념부터 보시죠.

Tiering의 개념은 어떤 기준에 따라, 예를 들면 객체의 Access Pattern에 따라 Hot한 객체와 Cold한 객체 등으로 계층화하는 것입니다. 접근이 빈번한 객체는 Hot, 접근이 드물고 보관 개념에 가까운 객체는 Cold로 분류합니다. 일반적으로 Hot 계열에서 Cold 계열로 갈수록 저장 단가는 낮아지고 Access 단가는 높아지는 특성이 있습니다. 즉시 접근이 불필요하고 극단적인 Cold 계열로 진행하면 아카이빙 계열의 Class로 저장하거나 영구 삭제하는 방식의 접근이 될 수도 있습니다.

객체 스토리지의 단가를 최적화하는 방법은 이 Tiering 정책을 정교하게 설계하는 것입니다. 참고로 AWS의 S3 서비스는 Tiering 개념으로 다양한 종류의 Storage Class를 제공하는데요. Class별 과금 구조에 맞춰서 각 객체에 적합한 Storage Class를 정의하면 됩니다. 말은 참 쉬운데요. 그렇게 하려면 어떤 기준이 필요합니다. 그 기준에 따라 Class를 자동 조정하는 전략도 필요한데 이건 뒤에서 다시 다루겠습니다.

S3의 경우 저장 단가만 고려한다면 액세스 빈도가 적으면 적을수록 Cold 계열의 Storage Class로 저장하는 것이 유리합니다. 즉 총합 1TB 데이터를 Standard Class로만 저장하면, 저장 요금은 대략 월 24$, 같은 양의 데이터를 Standard-IA로 저장하면 월 12$입니다. 극단적으로 Glacier Instant Retrieval로 저장하면 월 4$입니다. 즉시 접근이 필요 없고 Restore 시간까지 감수할 수 있다면, Glacier Deep Archive로 저장 요금을 월 1$까지 떨어뜨릴 수도 있습니다.

그렇다면 단순히 저장 요금만 고려해서 되도록 Cold 계열의 Storage Class를 더 많이 사용하면 되는 것일까요? 물론 아닙니다. 저장 요금 외에 요청 요금이나 복원 요금을 추가적으로 고려해야 합니다. 일종의 다차원 1차 함수처럼 생각하면 되는데요. 추상화하면 다음과 같습니다.

• 전체 요금 = aX + bY + cZ
• 전체 요금 = (저장단가=a) x (저장량=X) + (요청단가=b) x (요청수=Y) + (복원단가=c) x (복원량=Z)

변수 a / b / c의 경우 S3 요금표에 적혀 있는 값이고요. 동시에 Storage Class에 따라 달라지는 값이기도 합니다. 한편 변수 X / Y / Z의 경우 사용자 패턴에 따라 달라지는 값입니다. 얼마큼의 데이터를 저장하고, 외부 요청(GET/PUT 등)의 패턴은 어떻고, 복원이 필요한 경우 복원량이 얼마인지에 따라 X / Y / Z 값이 정해집니다. 이 값을 기반으로 Storage Class에 따라 a / b / c 값을 바꿔가면서 전체 요금이 가장 낮게 산정되는 Storage Class로 저장하면 됩니다. 적어도 이론상으로는 그렇습니다.

이 계산을 더욱 복잡하게 만드는 부가 조건들도 있습니다. 예를 들어 Standard-IA 계열의 Class는 최소 과금 단위(크기)가 128KB입니다. 따라서 크기가 10KB든 100KB든 해당 계열로 저장하면 사용량을 128KB 기준으로 과금합니다. 또한 최소 과금 기간 개념도 있는데요. Standard-IA의 최소 과금 기간은 30일로, 30일 이내에 삭제하더라도 30일치 비용이 부과됩니다. 여기에 특정 Class에 따라 추가되는 index나 metadata 용량까지 고려하면 계산은 더욱 복잡해집니다.

다시 원점으로 돌아와서 S3 같은 객체 스토리지에 데이터를 저장할 때 전체적인 단가를 최적화하려면 어떻게 해야 할까요? 경우의 수가 너무 많아서 한 번에 정리하기 어렵지만 3가지 원칙을 정하면 다음과 같습니다.

• 각 Storage Class별 과금 특성 및 제약사항을 이해한다
• Standard를 기준으로 하되, 저장 단가가 상대적으로 낮은 Cold 계열의 Storage Class를 순차적으로 고려한다
• 객체 크기 / 액세스 패턴 / 보관 기간 등을 감안하여, Cold 계열의 Class로 전환 시 늘어나는(상쇄되는) 비용을 종합적으로 비교한다.

그럼에도 불구하고 객체 스토리지의 (비용을 고려한) 관리 정책은 매우 난해한 영역입니다. 이 고민을 좀 더 단순하게 만드는 방법은 관리 자동화 편에서 다시 살펴보겠습니다.

세 번째, 기타 스토리지 서비스 조정 전략

앞서 블록 / 객체 스토리지의 단가 조정 전략을 살펴봤으니, 이번에는 기타 스토리지 단가에 영향을 미치는 요소들을 서비스별로 간략하게 다뤄보겠습니다.

AWS의 파일 스토리지 서비스인 EFS는 크게 3가지의 Class를 제공하고 있습니다. Standard / Infrequent Access(=IA) / Archive입니다. 3가지 모두 즉시 Access 가능한 형태의 계층이고 후자로 갈수록 낮은 저장 단가를 제공합니다. 성능 관점에서 First Byte Read Latency는 Standard가 가장 빠르며, IA나 Archive 계층은 Standard와 달리 최소 과금 단위나 최소 과금 기간 등의 제약조건이 있습니다.

EFS의 과금 정책에서 재밌는 부분은 위 3가지 계층의 단가표가 파일 시스템의 속성에 따라 다르다는 것인데요. 예를 들어 데이터를 Single-AZ에 저장할지, Multi-AZ에 저장할지, 또는 성능 모드를 (On-Demand 기반의) Elastic 모드로 할지, (미리 정의한 값의) Provisioned 모드로 할지에 따라 저장 단가와 전체적인 과금 체계가 달라집니다. 따라서 데이터가 저장되는 범위나 성능 특성, 단가 구조를 종합적으로 고려하여 EFS의 파일 시스템을 생성해야 합니다.

한편 EFS에서 Storage Class를 관리하는 방식은 S3와 다소 차이가 있습니다. S3는 처음 객체(파일)을 생성할 때 Standard-IA 같은 Cold 계열의 계층을 정의할 수 있는데요. EFS는 "Standard 기준 마지막 Access 30일 이후 IA로 전환"과 같이 자동화된 방식으로만 Cold 계열의 계층을 활용할 수 있습니다. 따라서 이런 Lifecycle 정책을 통해 액세스 패턴에 따라 Cold 계열의 계층으로 전환함으로써 전체적인 저장 비용을 최적화할 수 있습니다. 참고로 파일시스템 내 Storage Class별 사용량은 파일시스템의 요약정보에서 확인할 수 있습니다.

다음으로 AWS에서 제공하는 관리형 DB 서비스(Aurora, DynamoDB 등)의 예를 들어 보겠습니다. 이쪽 서비스 군은 엄밀히 말하면 그 자체가 스토리지 서비스는 아니고 스토리지의 과금 요소를 포함하고 있는 것들인데요. 이때 지불하는 스토리지의 단가가 사용자 선택에 따라 (성능 구조의 변경 없이) 달라지는 특성을 갖고 있습니다. 예를 들어 EBS나 S3, EFS 등은 지정한 볼륨 타입이나 Storage Class에 따라 저장 단가뿐만 아니라 성능 특성도 동시에 달라집니다. 반면 Aurora나 DynamoDB의 경우 스토리지를 어떤 과금 모드로 지정하느냐에 따라 요금을 계산하는 식만 달라질 뿐, 성능 특성에 아무런 영향을 끼치지 않습니다. 애초에 성능 구조가 달라지지 않기 때문에 과금 모드 변경에 따른 기술적인 임팩트도 없습니다.

Aurora 서비스의 경우 클러스터별로 Aurora Standard와 Aurora I/O-Optimized 모드를 선택할 수 있습니다. 일단 Aurora Standard의 노드 단가를 A, 스토리지 저장 단가를 B, 스토리지 I/O 단가를 C라고 해봅시다. 이때 Aurora I/O-Optimized의 노드 단가는 약 A * 1.3, 스토리지 저장 단가는 B * 2.2, 스토리지 I/O 단가는 무료입니다. 즉 Aurora I/O-Optimized 모드는 스토리지의 I/O 비용을 받지 않는 대신에, 더 높은 노드 단가와 저장 단가를 적용받는 요금제입니다. 그렇기 때문에 스토리지의 I/O 발생량이 매우 많은데요. 따라서 해당 비용이 전체 Aurora 비용의 25%가 넘는 경우 일반적으로 Aurora I/O-Optimized 모드가 유리하고, 반대로 그 외의 경우에는 Aurora Standard 모드가 비용상 유리합니다.

DynamoDB 서비스도 유사합니다. DynamoDB에서는 데이터 속성을 정의하고 입출력하는 저장소로 테이블이란 단위를 사용하는데요. 이 테이블 단위로 Standard 또는 Standard-IA로 테이블 클래스를 정의할 수 있습니다. 우선 Standard의 저장 단가를 A, 입출력에 따른 처리 비용(또는 성능값 설정치)을 B라고 해봅시다. 그렇다면 Standard-IA의 저장 단가는 약 A * 0.4, 입출력에 따른 처리 비용은 B * 1.3 정도 됩니다. 그렇기 때문에 상대적으로 데이터 입출력이 적고 저장하는 데이터량이 많은 경우에는 Standard-IA가 유리합니다. 반대로 데이터 입출력이 잦고 저장하는 데이터 총량이 적은 경우에는 Standard가 유리하게 됩니다.

정리하면 스토리지 서비스의 단가 측면에서 전체 비용을 최적화하기 위해서는 먼저 서비스별 단가 구조를 명확히 이해할 수 있어야 합니다. 복수의 계층을 제공하는 스토리지 서비스의 경우, 보통 Standard 같은 계층을 기본으로 하고 이후에 Standard-IA 같은 계층이 순차적으로 출시되곤 하는데요. 보통 이렇게 새로운 계층은 낮은 저장 단가를 제공하는 반면 다른 과금 요소에 비싼 단가를 매기는 경우가 많습니다. 따라서 단가 구조에 대한 이해를 바탕으로 여러분의 사용 패턴에 맞춰 신규 계층의 유불리를 판단해야 합니다. 별도의 사용자 정의가 없으면 기본값인 Standard 계열로 운용할 확률이 높기 때문에, 전체적인 데이터량이 커지고 액세스 패턴이 파악되는 시점이 오면 신규 계층으로의 전환을 더욱 적극적으로 고려할 필요가 있습니다.

자, 여기까지 AWS 스토리지 서비스의 단가 구조를 몇몇 예시 기반으로 살펴보았는데요. 구체적인 예시 없이는 직관적으로 설명하기가 쉽지 않아서 내용이 좀 어려우셨을지도 모르겠습니다. 그럼 과금 관점에서 단가 최적화는 이 정도 수준에서 정리하고, 이어서 일종의 부록 편으로 관리 자동화와 백업 비용 최적화를 다루고 마무리하도록 하겠습니다.

비용 최적화 Level UP을 위한 추가 Point 1! 관리 자동화

클라우드에서 관리형 서비스를 광고할 때 자주 등장하는 레퍼토리가 "사람이 관리하는 것도 비용이다"라는 명제입니다. 맞는 말이죠. 단순히 AWS 청구서에 찍힌 사용료만 비용이 아닙니다. MSP 같은 운영 서비스 사용 시 결국 사람이 개입하고 별도의 비용을 부과하기 때문에, 사람이 관리하는 것도 비용이 맞습니다.

그럼 스토리지의 단가 최적화라는 관점에서는 어떨까요? 위에서 설명한 내용들을 기준으로 표준 관리 정책을 수립하고 매번 사람이 개입해서 객체나 볼륨 단위로 계층을 재조정할 수 있을까요? 현실적으로 어렵습니다. 그렇기 때문에 최소한의 관리 정책은 사람이 수립할 수 있지만 그 기준에 따른 조정 작업은 자동화된 방식으로 운용할 필요가 있습니다. 다행히도 그런 자동화된 방식을 클라우드에서는 일종의 기능(Feature)으로 제공하고 있는데요. 오늘은 S3 서비스를 기준으로 자동화된 관리 방식이 어떤 것들이 있는지, 더불어 표준 정책을 수립하기 위한 분석 도우미 서비스는 어떤 게 있는지 함께 살펴보도록 하겠습니다.

S3 환경에서 객체의 Storage Class를 자동화된 방식으로 조정하는 대표적인 기능으로 Lifecycle Rule을 활용할 수 있습니다. Lifecycle Rule은 객체 생성 시점 기준으로 지정일이 지난 객체를 특정 Class로 전환하는 기능입니다. 예를 들어 내가 제공하는 뉴스 서비스의 이미지 저장소로 S3를 사용하고 있다고 해봅시다. 이때 1) 최초 30일간은 호출이 빈번하고 2) 그 이후 180일간은 아주 제한적으로 호출되며 3) 180일 이후에는 이미지를 제공할 의무가 없다면, 이런 Lifecycle Rule 기능을 통해 다음과 같이 객체의 생로병사를 정의할 수 있습니다.

• 생성일 기준 30일 이후에는 Standard-IA로 전환
• 생성일 기준 180일 이후에는 Expire (삭제)

다만 이런 형태의 자동화된 구성을 할 때는 해당 과정에서 발생하는 부대비용을 고려해야 합니다. S3 객체의 경우 다른 Class로 전환하는 작업은 사실 속성-변경 개념이라기보다는 신규-생성에 가깝습니다. 따라서, Lifecycle Rule에 따라 새로운 Class로 전환되는 과정에서 Put Request 요금이 추가로 발생합니다. 만일 이런 전환 비용(?) 조차 감수할 수 없다면, 처음부터 원하는 Storage Class로 정의해서 객체를 업로드하는 것도 하나의 방법입니다.

참고로 이런 Lifecycle 정책은 특정 Bucket 또는 특정 Bucket의 Prefix 단위로 설정할 수 있는데요. 해당 Bucket 내 객체의 특성이나 액세스 패턴을 모른다면 어떻게 할까요? 이런 가시성을 확보하기 위해 S3가 제공하는 분석 서비스를 활용하면 됩니다. 예를 들어 S3 Storage Lens는 Bucket별 Object count, 평균 Object Size, Storage Class별 사용량 및 트렌드를 확인할 수 있습니다. S3 Storage Class Analysis 기능은 좀 더 구체적으로 특정 Bucket (+Prefix) 단위로 ObjectAge나 RequestCount를 구분해서 볼 수 있습니다. 이렇게 분석된 객체 패턴을 반영하여 효율적인 Lifecycle 정책을 수립할 수 있습니다. 역발상으로 이런 정책을 더욱 효율적으로 적용할 수 있도록, 액세스 패턴이나 수명 주기가 동질적인 객체들을 같은 Prefix로 관리하는 방법도 좋은 접근입니다.

만약 패턴 분석도 싫고, Lifecycle 전환 정책도 생성일 기준으로 정의가 어려운 환경이라면 어떨까요? 이럴 때는 S3 Intelligent-Tiering이라고 부르는 Storage Class를 활용하는 방법이 있습니다. 해당 Storage Class로 객체를 정의하면 실제 Access 패턴에 따라 적합한 Class의 "평가 작업"과 "전환 작업"을 알아서 수행해 줍니다. ‘그럼 무조건 S3 Intelligent-Tiering으로 지정하면 되겠네?’라고 생각하실 수 있는데요. 아닙니다. S3 Intelligent Tiering의 경우 Monitoring and Automation 작업에 대한 과금이 별도로 그리고 반복적으로 부과됩니다. 따라서 1) 평가해야 할 객체수가 매우 많고 2) 액세스 패턴이 명확한 경우 (전환 비용이 1회만 부과되는) Lifecycle Rule이 더 유리한 경우도 있습니다.

보통 EBS 같은 블록 스토리지나 관리형 DB 서비스의 스토리지 영역은 자동화된 방식의 관리가 꼭 필요하지는 않습니다. 비정기적으로 사용 패턴을 분석하고, 해당 패턴을 기준으로 1-2회 수준의 조정 작업을 수행하는 것으로 충분합니다. 반면 S3나 EFS처럼 계층이 정의되는 단위(Object, File 등)가 작고, 자동화된 방식의 계층 관리를 풍부하게 제공하는 서비스의 경우에는 이런 기능을 보다 적극적으로 검토할 필요가 있습니다. 물론 이 과정에서도 자동화 기능에 대한 부대 비용을 통합적으로 고려하고, 비용 관점에서 또 성능 관점에서 가장 합리적인 판단 기준을 만드는 작업이 병행되어야 합니다.

비용 최적화 Level UP을 위한 추가 Point 2! 비용을 고려한 백업 전략

자, 이제 마지막 주제입니다. 백업도 일종의 스토리지 영역을 사용하고 일부는 계층별로 다른 단가를 제공하기 때문에, 백업 전략 또한 단가나 비용을 고려할 필요가 있습니다. 일단 백업은 RTO나 RPO같이 백업 정책을 구성하는 기본 지표들이 있는데, 이 부분에 대한 것들은 가급적 제외하고 이야기를 전개하겠습니다.

먼저 EBS 백업을 살펴보겠습니다. EBS 볼륨을 백업하면 무엇이 될까요? 네 맞습니다. EBS Snapshot이 됩니다. 그럼 EBS Snapshot에 복수의 계층이 있다는 건 알고 계셨나요? 아셨다고요? 네, EBS Snapshot에는 Standard와 Archive 계층이 있습니다. 참고로 Snapshot의 GB당 단가는 Archive가 Standard에 비해 75% 정도 저렴합니다. 그럼 무조건 Archive 계층으로 백업하면 되겠네요? 물론 아닙니다.

Snapshot의 Archive 계층은 Standard 계층에 비해 3가지 단점이 있습니다. 첫 번째, EBS 볼륨에 대한 복원 비용이 있습니다. Standard의 경우는 무료인데, Archive 계층은 GB당 $0.03 수준의 추가 비용이 발생합니다. 두 번째, 90일의 최소 보관 기간이 있습니다. Archive 계층의 경우 90일 미만의 기간 동안 보관하더라도 90일간의 비용이 과금됩니다. 세 번째, Archive 계층은 백업 방식이 Full-Backup입니다. 증분 백업 방식을 사용하는 Standard의 경우 실제 변경분만큼의 용량만 과금하기 때문에 상대적으로 사용자에게 유리하고, 이를 Archive 계층으로 변경하는 과정에서 백업본의 크기가 크게 증가할 수 있습니다. 결국 이 3가지 단점을 수용함에도 불구하고 낮은 저장 단가로부터 그 이상의 효과를 뽑을 수 있다면 Archive 계층을 활용하면 됩니다.

이어서 Aurora의 백업에 대해서도 짧게 살펴보겠습니다. Aurora의 경우 백업본에 복수의 계층을 제공하는 것은 아닙니다. 먼저 자동화된 방식의 백업은 증분 방식이며, 변경된 영역에 대한 용량을 누적 계산하여 과금합니다. 다만 수동으로 생성하는 Snapshot에 대해 과금할 때는 Backup Retention Period 기간 내의 백업본에 대해서는 별도 비용을 부과하지 않습니다. 예를 들어 자동화된 방식의 백업인 Backup Retention Period를 최근 30일로 설정한 경우, 최근 30일 내에 생성한 수동 Snapshot에 대해서는 추가 비용이 발생하지 않습니다. 30일이 넘은 시점부터는 물론 GB당 단위로 추가 비용이 발생합니다. 이 과금 메커니즘을 바탕으로 Backup Retention Period를 벗어난 수동 Snapshot을 최소화(삭제 등) 하거나, 반대로 Backup Retention Period를 적절하게 재조정하여 전체 백업(자동 백업 + 수동 백업) 비용을 최소화하는 전략을 수립할 수 있습니다.

마치며

이제 정리할 시간입니다. 오늘의 주제는 스토리지의 단가 최적화 전략이었는데요. 생각보다 설명할 것이 많아서 난이도나 편의상 생략한 주제들이 많았음에도 불구하고 전체적인 분량이 크게 늘어나 버려서 아쉽습니다. 결국 이 글에서 전달하고자 했던 주제를 요약하면 다음과 같습니다.

• 스토리지의 단가를 최적화하기 위해서, 서비스별로 고유한 과금 정책을 이해할 필요가 있다. 일부는 과금 모드 변경만으로도 비용을 낮출 수 있다.
• 낮은 저장 단가의 계층에는 항상 Trade-off 요소가 있으며, 전체적인 비용 또는 성능 요구사항 관점에서 해당 요소를 어디까지 감수할지를 판단해야 한다.
• 최적화 관점에서 서비스가 Native 하게 제공하는 분석 또는 자동화 관리 기능을 적극적으로 활용한다. 이 경우에도 해당 기능의 추가 비용을 감안해야 한다.

사실 스토리지의 단가 구조를 그대로 해석하고 받아들이는 수준에서 벗어나, 작은 아이디어를 발전시켜 더 낮은 비용을 구현하는 경우의 수도 생각해 볼 수 있습니다. 예를 들어 S3에서 10KB 크기의 로그 객체가 다수 존재하는 경우, 최소 과금 단위(크기) 이슈를 회피하고자 보통 Standard 계층으로 운영하는데요. 일 단위의 로그를 단일 파일로 압축해서 128KB 이상의 크기로 객체를 재구성하여 낮은 저장 단가의 Storage Class로 전환하는 방법도 있습니다. 물론 압축 작업을 Lambda 함수 등에서 수행한다면, Lambda 실행 시 발생하는 부대비용을 고려해야 합니다.

조금 더 시야를 넓혀서 AWS의 자체 서비스 외에도 AWS 외 환경에서 제공하는 스토리지 서비스를 고려해 볼 수도 있습니다. AWS 환경과 밀접하게 연계되어 있는 3rd Party 스토리지 서비스 같은 것들 말인데요. 아마 GB당 저장 단가는 AWS 서비스에 비해 크게 낮을 수 있겠지만 이때에도 좀 더 넓은 관점에서 전체 비용을 고려할 필요가 있습니다. 예를 들어 서비스 연동망에서 발생하는 트래픽 요금이 추가적으로 발생한다거나, AWS 환경에서는 필요 없는 모니터링 영역이나 관리 작업이 추가될 수도 있습니다. 어떤 대안이든 전체적인 관리 비용을 정교하게 시뮬레이션 할 필요가 있습니다.

비슷한 발상으로 AWS 내에서 상대적으로 저렴한 스토리지 단가를 제공하는 Region을 고려해 볼 수도 있습니다. 예를 들어 US West 기준으로 Northern California Region에서 제공하는 S3 Standard Class의 저장 단가는 GB당 26센트인데 반해, Oregon Region의 단가는 23센트입니다. 한편, S3에 저장하는 데이터를 읽고 쓰고 Processing 하는 자원들이 Northern California Region에 있다고 해봅시다. 이 경우에는 트래픽이나 전체적인 부대 비용을 고려했을 때, Oregon Region의 낮은 저장 단가가 큰 의미가 없을 수 있습니다. 하지만 그런 로직이 크게 없다면? 사용자 다운로드도 CloudFront 같은 CDN 계층을 통해 Edge 기반으로 전송된다면? Oregon Region가 제공하는 낮은 저장 단가가 의미 있는 케이스가 아주 희박하게 있을 수도 있습니다. 결국 같은 메시지인데요. 다양한 경우의 수를 고려하되 전체적인 비용을 고려할 필요가 있습니다.

다음 5회차에는 네트워크의 단가를 최적화하는 법을 살펴볼 예정입니다. 더불어 7회차에는 스토리지의 사용량을 최적화하는 법을 다룹니다. 오늘 4회차에서는 스토리지의 단가를 최적화하는 내용을 다루었으니 단가 관점에서는 3회차와 5회차, 스토리지 관점에서는 7회차의 전략을 비교해서 읽어보시는 것도 좋겠네요. 긴 글 읽어주셔서 감사합니다. 끝.

 

▶ 더 읽어보기

• 클라우드 비용 최적화 로드맵 #1 - 연재를 시작하며
• 클라우드 비용 최적화 로드맵 #2 - 비용을 자세히 보기 위한 준비
• 클라우드 비용 최적화 로드맵 #3 - 컴퓨팅의 단가를 최적화하는 법

▶ 최준승 님 / Cloud Architect 팀 / jsch@sk.com