스푼라디오 S3 비용 최적화

Published in

Spoonlabs

11 min readDec 29, 2023

안녕하세요.
Spoonradio에서 SRE팀을 Lead하고 있는 Martin(최상기)입니다. 지난 2년 동안 진행하고 있는 S3 비용 최적화에 대해서 이야기 하고자 합니다.

클라우드 비용은 PAYG(Pay-as-you-go) 모델 입니다. 이것은 원하는 만큼 먼저 사용하고 비용을 나중에 지불하는 방식이기 때문에 비즈니스에 필요한 리소스를 계획하거나 예측할 필요가 없고, 기술 미비로 인한 비즈니스 중단 리스크 또한 사라집니다. 이는 분명 클라우드 매력입니다.

모든 것이 그렇듯 PAYG 방식 또한 단점이 있습니다. 클라우드 사용 전략을 적절히 수립하지 못 한 채 비즈니스 성장만 보고 달라다 보면, 비용이 눈덩이 처럼 크게 불어나 있게 됩니다.

특히, Amazon S3(이하 S3)는 서비스 초기 그 비용이 타 AWS 서비스 대비 높지 않아, 시간이 꽤 지나야 비용이 많이 발생되고 있다는 것을 확인하게 됩니다.

Why not?

Amazon S3는 99.99999999%(9가 11개)의 데이터 내구성을 가지고 있습니다.

S3 Standard의 경우 처음 50TB까지 월에 GB당 $ 0.025 밖에 들지 않는 매우 매력적인 서비스이고, AWS에서 서비스 중 가장 기본이 되는 서비스는 중 하나입니다.

이런 장점으로 서비스 초기에 아래와 같은 이유로 모든 데이터를 저장 합니다.

고객 데이터 이니 잘 보관 해야 하며,
나중에 데이터 분석해야 하니 보관하고,
그리고 유실이 되면 안되니,
9가 11개인 기본 Stand Type Object 형태로
Versioning까지 사용하여 보관합니다.

이렇게만 보면 정말 잘 보관하고 있는 것입니다.

S3 비용은 저렴하며, 서비스 초기 AWS 비용을 보면 S3 비용은 타 서비스에 비해 낮아 이렇게 하지 않을 이유가 없습니다.

그리고 “클라우드의 주요 장점은 비용 절감이 아니라, 서비스 제공과 혁신 속도를 통한 비즈니스 성장이지 비용이 아니다”라는 생각 아래 계속 저장 합니다.

티끌모아 태산

서비스 성장 속도나 데이터를 얼마나 S3에 저장 하느냐에 따라 다르겠지만, 제 경우에는 보통 서비스 시작 이후 대략 3~4년 정도가 지나면, 전체 AWS 비용 중 Top5안에 S3가 위치 되어 비용 최적화를 위해 S3를 들여다 보게 됩니다.

S3 기본 비용 구조

Amazon S3 비용은 스토리지 요금, 요청 및 데이터 검색 요금, 데이터 전송 및 전송 가속화 요금, 데이터 관리 및 인사이트 기능 요금, 복제 요금, 변환 및 쿼리 기능 요금으로 구성됩니다.

보통 스토리지 요금을 주로 확인하는데, S3 비용 최적화를 위해서는 위에 나열한 사항 모두 함께 고려 해야 합니다. 비용 구조에 대한 이해가 부족한 상태에서 최적화를 진행하게 될 경우 생각지도 못 한 비용이 발생할 수도 있기 때문 입니다.

S3 비용 최적화 방법

AWS에서 제시하는 S3 비용 최적화 방법은 아래와 같습니다.

불완전한 멀티파트 업로드 정리
필요 없는 객체의 이전 버전 삭제
스토리지 클래스 전환 비용 검토
데이터 검색 비용 검토
버킷에 대한 요청 추척
버킷 크기 변경 사항 확인
각 버킷의 비용 검토
사용량과 요금이 어떤 관계인지 이해

최적화 방법은 이미 나와 있고, 이를 실제 상황에 적용을 하기 위해 검토하다 아래와 같은 현실을 확인하였습니다.

데이터의 식별

비용 최적화를 위해서 먼저 해야 할 것은 S3 어느 부분에서 비용이 발생되고 있는지 식별화하는 것입니다. 이 때 유용하게 사용할 수 있는 도구가 바로 Amazon S3 Lens나 Amazon S3 analytics — Storage Class Analysis 입니다.

특히, Amazon S3 Lens로 Bucket 별 전체 용량이 얼마인지, Object 개수는 몇 개인지, Object의 검색 빈도 등등 여러가지 정보 확인해 볼 수 있습니다. 결과를 살펴 보면 저장만 하고 사용하지 않는 Object 사이즈와 개수가 대략 어느 정도 인지 가늠할 수 있습니다. 제가 확인한 결과는 아래와 같았습니다.

Object가 수천만개 혹은 수억개가 저장되어 있다는 사실에 놀라고, 다시 PB 사이즈에 놀라게 놀랍니다. ⇒ 정말 많이 저장해 두었구나, 그리고 S3에 모두 저장이 가능구나…., S3 정말 대단하구나…
데이터 분석을 위해 저장하였으나, 분석을 위한 Tagging 혹은 DB나 기타 다른 데이터와 연계 정보가 없어 분석이 어려워 활용 빈도가 매우 낮다는 사실을 확인 했습니다.
서비스를 운영 하면서 생산되는 2~3차 데이터(예로, 이미지 사이즈를 기기 해상도 별로 저장하는 경우)가 많다는 사실을 확인 했습니다.
S3에 저장된 Object를 삭제했는 데, Versioning을 고려하지 못해 완전히 삭제되지 않았다는 것과 이 용량이 꽤 된다는 사실을 확인 했습니다.
S3 Lifecycle rule로 오래된 파일 일괄 삭제를 검토 하던 중, 초창기 S3 성능(지금은 아닌 것으로 알고 있습니다.)을 위해 prefix를 hash로 만들어 의미 식별이 불가능하여 prefix를 기준으로 S3 Lifecycle rule을 설정할 수 없었습니다.
AWS에서는 이야기 하는 S3 Lifecycle rule 옵션을 통해 Object Type을 좀 더 저렴한 Type으로 변경하려고 해도, Object Type 별 용량 제한(예, Glacier Instant Retrieval 128k)으로 변경 불가능 하였습니다.
마지막으로 데이터 삭제를 통해 비용을 줄이는 것을 검토하게 되는 데, 데이터에 대한 식별화가 되어 있지 않아 삭제를 해도 될지 알 수가 없어 삭제가 불가능 하였습니다.

제가 경험한 사실이며, 상황에 따라 다를 수 있습니다. 결과적으로 S3 운영 관리를 제대로 하지 못 하고 있는 사실을 인지하고 반성하는 계기가 되었습니다.

비용 최적화를 위해 시도한 사항들

1. Object Type 변경을 통한 비용 최적화

저장만 되어 있고, 검색 되지 않는 Object는 Glacier Deep Archive Object Type으로 변경을 고려 하였습니다. 그러나 저장 데이터 식별화가 되어 있지 않아 혹시 모를 이유로 검색이 이루어 질 수 있을 수도 있어, 복원에 시간이 걸리는 Object Type으로는 변경 할 수 없었습니다.

여러 Object Type 중 Glacier Instant Retrieval(이하 GIR)을 검토 하였습니다. GIR Object Type은 Standard Type 대비 최대 68% 저장 비용 절감, 밀리초 단위의 검색을 지원하며, 다른 Glacier Object Type보다 복원에 필요한 시간과 비용이 가장 저렴한 특징을 가지고 있습니다. 결과적으로 비 식별된 데이터에 부합하는 Object Type이었습니다.

다만, 최소 Object가 사이즈가 128 KB이상이여야 하며, 변경후 90일 동안은 비용이 부과 된다는 점에 유의 해야 합니다. 아래 링크를 보면 Object Type별 제약 사항이 있으니, 참고할 필요가 있습니다.

Using Amazon S3 storage classes

Choose from a range of high-durability storage classes for the objects that you store in Amazon S3, depending on your…

docs.aws.amazon.com

또 한가지 고려해야 될 사항은 한번에 많은 Object를 S3 Lifecycle rule로 변경시 S3 Request 비용이 일시적으로 증가한다는 점도 고려 되어야 합니다.

2. 삭제

S3 Lens로 검색이 거의 발생지 않고, 저장만 되어 있는 Object를 확인할 수 있습니다. 저장만 되어 있고 검색이 되지 않는 Object는 활용빈도가 매우 낮은 것으로 볼 수 있습니다.

이런 경우는 삭제가 비용 절감에 효과적이라 생각하였으나, 정말로 삭제가 가능한지 S3 Inventory를 통해서 Object 상태를 좀 더 살펴 보았습니다. 평균 Object 사이즈, 생성 시점, 버전 정보 등등을 고려하였습니다.

2. 1 만료된 Object 삭제

Inventory Report로 Versioning이 활성화되어 있는 Bucket Object가 만료만 되고, 이전 버전이 남아 있는 상태를 확인 할 수 있었습니다. 이전 버전에 대한 영구적 삭제 처리를 진행하지 않았기 때문이었습니다. 이것을 S3 Lifecycle rule을 통해 Object가 최신버전이 아닌 상태로 존재한지 1개월이 넘는 Object는 이전 버전 영구 삭제를 진행하였습니다.

2.2 쌓여만 있고 사용하지 않고 있는 Object 삭제

5~6년 전부터 Object가 계속 저장되어 왔으며, 대부분의 객체가 이전 버전이 없었으며, 검색 빈도가 5% 미만 이었습니다.
즉, Versioning 된 Bucket에 최신 Object 버전만 저장되어 있습니다.
대부분 Object 평균 사이즈는 100kb 이하 입니다.

100kb 이하라, GIR로 변경은 불가 하였고, Object Type 변경도 비용이 발생되므로, Glacier Deep Archive Type으로 변경하는 것도 비용 낭비로 보였습니다.

위 Object는 죽은 상태로 판단하였고, 삭제 검토는 여러 유관 부서와 함께 결정을 하였는 데, 몇 가지 기준을 두고 논의 하였습니다.

현재 기준으로 이 데이터가 보관을 해야할 가치가 있는 것인지
꼭 장기간 보관을 해야 한다면 얼마나 보관하고 파기를 하면 되는지
분석을 위해 저장을 했다면 연관 데이터에 대한 접점이 있는지

데이터에 대한 식별화가 되어 있지 않았기 때문에 위 기준에 부합하는 Object라 하더라도 모두 한번에 삭제 하기 보다는 최근 1년치는 남겨 두고, 그 이외 Object 삭제 부터 진행하는 것으로 결정 하였습니다.

또한, 앞으로 이런 Object가 무의미하게 적재되지 않기 위해

내부 프로젝트 시작 시점시 데이터에 대한 Lifecycle 논의를 하기로 합의 하였고,
분석이 필요하고, 분석이 가능한 데이터만 적재하기로 하였고,
2, 3차 가공 파일에 대한 보관 주기를 어떻게 하면 될지 설정하고,
분석을 요하는 데이터는 DB나 다른 정보와의 연계성을 고려해 저장하기로 협의 하였습니다.

몇 가지 예 이지만, 비즈니스 상황에 따라 여러 기준이 있을 수 있으며 부서간 합의 하고 이를 꾸준히 지켜 나가는게 더 중요 합니다.

결과

약 2년간 지속적인 S3 최적화로 최적화 이전 대비 S3 비용을 대략 30% 정도 절감 할 수 있었습니다. 정말 티끌모아 태산이라는 것에 대해서 체감할 수 있었던 기회 였습니다.

정리 정돈의 기본은 버리는 것이라는 말이 있습니다. 반기 혹은 년에 한번씩 불필요 Object를 식별화하여 삭제를 꾸준히 진행하고 있습니다.
불필요한 데이터가 계속 적재되지 않도록 프로젝트를 시작하면서 Object Lifecycle 을 정의하여, 이것을 S3에 적용하고 있습니다.
이전 비용을 포함한 Object Type 성격과 제약 사항을 검토해 S3 Lifecycle rule을 통해 적절히 Type을 변경을 하고 있습니다.
마지막으로 제일 중요한 것은 프로젝트 시작이나 회고 시점에 데이터에 정리 까지 고려하기 시작했고, 이것이 바로 우리 스푼만의 개발 문화적 관행으로서의 첫 발걸음을 내 딛게 되었다는 것입니다.

또한 아래와 같은 절차로 지속적으로 S3 비용 최적화를 진행하고 있습니다.