삼성 클라우드의 Amazon DynamoDB 비용 최적화 여정

이 블로그 포스트는 삼성전자의 김정훈님과 함께 작성되었습니다.

삼성 클라우드는 전세계 갤럭시 스마트폰을 포함한 삼성의 모든 디바이스를 대상으로 사용자 데이터의 백업/복원 및 동기화, 공유, 기기 인증 등의 서비스를 제공하여 언제 어디서든지 멀티 디바이스 간의 동일한 사용자 경험을 제공하는 클라우드 기반의 서비스 입니다.

이 블로그에서는 삼성 클라우드가 2015년 Apache Cassandra에서 Amazon DynamoDB로 마이그레이션 이후 지속적으로 DynamoDB의 총 소유비용(the total cost of ownership, TCO)을 최적화하고 있는 다섯 가지 접근 방법을 소개합니다.

삼성 클라우드의 스케일과 하이레벨 아키텍처

AWS re:Invent 2017에서 삼성 클라우드는 860TB 데이터를 자체 운영 Cassandra에서 DynamoDB로 마이그레이션 후 40% TCO를 절감한 내용을 발표 했었습니다. 이후 삼성 클라우드의 DynamoDB 워크로드는 3.5PB 데이터와 매일 1,000억개 이상의 읽기/쓰기 요청을 처리하는 규모로 성장했습니다. 모든 규모에서 10밀리초 미만의 성능을 제공하는 서버리스 NoSQL 완전관리형 데이터베이스인 DynamoDB를 통해 삼성 클라우드는 스토리지 및 컴퓨팅 용량을 추가하기 위한 다운타임 없이 워크로드를 확장할 수 있었습니다. DynamoDB에는 버전 업그레이드, 유지 관리 기간(maintenance window), 패치, 다운타임 유지 관리가 없기 때문에 삼성 클라우드는 인스턴스 기반 솔루션을 사용할 때보다 향상된 복원력을 달성했습니다. 마찬가지로 TTL, Auto Scaling 및 Standard-Infrequent Access를 포함하여 새로운 기능들이 가동 중지 시간이나 유지 관리 기간 없이 출시되어 언제든 비용을 최적화하기 위한 기능을 쉽게 도입할 수 있었습니다. 정리해보면 삼성 클라우드는 워크로드에 영향을 주지 않고 DynamoDB의 지속적인 혁신을 활용하며, 새로운 기능이 출시되면 즉시 기존 테이블에 적용할 수 있었습니다.

중단 없이 새로운 DynamoDB 기능을 도입할 수 있는 것은 삼성 클라우드가 지난 9년 동안 DynamoDB 사용 사례를 발전시키고 최적화하는데 도움이 되었습니다. DynamoDB가 Key Value 데이터베이스이기 때문에 한정적인 도메인에서만 사용한다고 생각할 수 있지만, 삼성 클라우드의 Service, User 그리고 Basic 모듈은 서로 다른 요구사항과 스케일을 갖고 있음에도 불구하고 다양한 마이크로서비스에서 DynamoDB를 사용하고 있습니다.

• Service 모듈: 멀티 디바이스 간 데이터 동기화와 사용자 간 데이터 공유를 담당합니다. DynamoDB는 테이블과 로컬 세컨더리 인덱스(local secondary index, LSI)를 통해 항상 최신 데이터를 읽을 수 있도록 보장합니다.
• User 모듈: 디바이스 인증과 다른 데이터베이스의 캐싱 역할 등을 담당합니다. 만료된 데이터를 유지하기 위해선 타겟 데이터를 검색하고 삭제해야 하기 때문에 큰 비용이 듭니다. 하지만, DynamoDB는 이것을 비용 없이 가능하게 합니다.
• Basic 모듈: 삼성 클라우드의 핵심 기능으로 대규모 스케일의 오브젝트를 관리하기 위한 메타 데이터 스토어를 담당합니다. DynamoDB는 모든 규모에서 10밀리초 미만의 성능을 제공합니다.

삼성 클라우드는 대규모 저장공간과 다이나믹한 스케일을 필요로 합니다. 대규모 사용자 트래픽을 예측하기 어렵기 때문에 DynamoDB의 탄력성과 확장성은 삼성 클라우드에 필수적입니다. 또한 필요한 경우 언제든 테이블을 프리워밍 할 수 있습니다.

다음 섹션에서는 삼성 클라우드가 DynamoDB 비용을 최적화하기 위해 사용한 다섯 가지 접근 방식을 공유합니다.

Modeling

삼성 클라우드는 2015년 마이그레이션 당시 860TB 대용량 데이터를 Cassandra에서 이관해야 했고, 당시에는 하나의 엔티티를 하나의 DynamoDB 테이블로 디자인하는 방식을 채택하게 됩니다. 이 방식은 최근까지 서비스적으로 큰 이슈없이 동작하고 있지만, DynamoDB의 모델링 가이드에 맞게 사용하고 싶은 니즈를 항상 갖고 있었고 2022년부터 싱글 테이블 디자인을 적극 도입하게 되었습니다. 2022년 이후 신규 애플리케이션은 대부분 싱글 테이블 디자인을 적용해 서비스에서 동작하고 있습니다.

싱글 테이블 모델링을 도입함으로써 두 가지의 효과를 얻을 수 있습니다.
첫번째, DynamoDB 처리량 비용을 최적화 할 수 있습니다. 서비스 설계를 하면 보통은 다수의 엔티티가 정의되곤 합니다. 예를들어 신규 모듈 구축을 위해 10개의 엔티티가 정의됐을 경우, 기존 방식의 디자인이라면 10개의 테이블 생성해야 하고, 10개의 테이블에 각각 consumed Capacity Units (CU)가 발생하며 이를 위해 각각 provisioned CU를 설정해야만 했습니다. 하지만 이를 싱글 테이블로 디자인 하게 되면, 서로 다른 워크로드가 통합되어 평탄화 되고, 1개의 테이블이기 때문에 1개의 provisioned CU만 필요하게 됩니다. 이는 곧 DynamoDB 처리량 비용이 줄어드는 효과로 이어집니다.

두번째, 운영에 대한 비용이 줄어듭니다. 모델링과 운영은 거리가 멀다고 생각할 수 있지만, 실제 모델링이 운영에 많은 영향을 줍니다. RDBMS에서 모든 테이블이 동일한 용량과 동일한 트래픽을 받는게 아닌 것 처럼, 엔티티 단위로 생성한 DynamoDB에는 고사용 테이블과 저사용 테이블이 모두 존재합니다. 삼성 클라우드에서 고사용 테이블은 비용이 많이 발생하지만 꾸준한 트래픽이 유지되기 때문에 서비스적으로 이슈가 거의 발생하지 않습니다. 반면 저사용 테이블은 이후에 소개될 삼성 클라우드의 DynamoDB 오토 스케일링 정책과 맞물려 비용은 거의 발생하지 않지만 스파이크 트래픽 유입 시 서비스적으로 이슈를 만들어 내기도 합니다. 따라서 저사용 테이블을 위한 모니터링과 알람, 관리정책이 필요하게 되어 추가적인 운영 비용이 발생하게 됩니다. 반면 싱글 테이블로 다지인이 된 경우, 높은 사용량을 가진 엔티티에 의해 크게 설정되어 있는 provisioned CU를 저사용 엔티티는 사용만 하면 되기 때문에 추가적인 모니터링, 알람, 관리정책 뿐만 아니라 서비스적인 이슈도 사라지므로 큰 이점이 발생합니다. 나아가 테이블 개수를 줄일 수 있게 되므로, 모니터링이나 관리해야 하는 대상이 줄어드는 만큼 이 역시 운영 비용이 줄어드는 효과를 가집니다.

DynamoDB Auto Scaling

삼성 클라우드는 2017년 DynamoDB Auto Scaling(오토 스케일링) 기능이 출시 된 이후 모든 테이블에 일괄로 적용했습니다. 오토 스케일링 적용 초기에는 각 테이블의 실제 사용량을 모두 확인하여 오토 스케일링의 최소 용량 단위(Minimum capacity unit, MIN)값을 결정했습니다. 이 방식은 많은 테이블을 개별적으로 진행해야 하기 때문에 많은 공수가 투입되어 비효율적일 수 밖에 없었습니다. 이에 따라 전체 테이블에 공통적으로 적용할 수 있는 삼성 클라우드만의 오토 스케일링 정책이 필요했습니다. 정책을 수립할 당시에, 불균일한 데이터 액세스 패턴과 예상치 못한 스파이크 트래픽을 프로비저닝 용량 모드에서 수용할 수 있도록 하는 Adaptive Capacity(조정 용량)와 Burst 기능을 염두하여 아래처럼 매우 공격적인 수치를 설정하게 됩니다.

• 최소 용량 단위(MIN): 20
• 최대 용량 단위(MAX): 리전 최대값
• 목표 사용량(Target utilization): 88%

비용 관점에서 최소 용량 단위와 목표 사용량의 수치를 주목하면, 테이블 사용이 없을 경우 20 CU를 유지하고 consumed CU가 provisioned CU 값에 매우 근접해야만 증설되는 수치 입니다. 이 수치는 쓰로틀링 발생하더라도 비용을 줄이는 것에 맞춰진 선택이며, 실제 삼성 클라우드 서비스에서는 쓰로틀링이 동반되고 있습니다. 다만, 서비스의 안정성 확보를 위해 각 애플리케이션별 요구사항을 고려하여 애플리케이션 레벨에서 방어로직이나 fail fast 전략, retry 정책 등이 적용되어 있습니다.
추가적으로 운영 환경에서는 프로비저닝 용량 모드와 오토 스케일링을 사용 중이며, 검증이나 테스트의 목적의 스테이징 환경에서는 트래픽이 일정치 않기 때문에 온디맨드 용량 모드를 사용하고 있습니다.

Time to Live

삼성 클라우드가 DynamoDB로 처음 마이그레이션을 한 2015년엔 Time to Live(TTL) 기능이 없어 사용기간 만료된 데이터들은 별도의 배치 잡(batch job)를 수행해 삭제했습니다. DynamoDB TTL 기능이 처음 GA되었을 때는 이미 사용하고 있던 배치 잡이 잘 동작하고 있었기 때문에, 오히려 TTL 전환에 투입되는 노력 대비 얻는 이점이 적다고 판단하게됩니다. 하지만 서비스의 규모가 지속적으로 커짐에 따라 삭제되는 데이터의 양보다 쌓이는 양이 더 많아졌고, 스토리지 사이즈도 기하급수적으로 커지기 시작했습니다. 추가로 별도의 배치 잡을 수행하고 있다는 의미는, 배치 잡 수행을 위한 별도의 Amazon Elastic Compute Cloud(Amazon EC2)와 DynamoDB에서 삭제할 데이터를 찾기 위한 RCU(Read capacity units), 삭제를 위한 WCU(Write capacity units)가 필요합니다. 이는 곧 많은 비용 추가로 이어지게 됩니다.

데이터베이스에서 일반적인 배치 잡을 통해 TTL 만료 데이터를 삭제하는 일은 서비스 규모가 커질수록 이를 위한 비용은 기하급수적으로 증가합니다. 삼성 클라우드는 이 문제를 해결하기 위해 배치 잡을 통해 TTL 만료된 데이터를 삭제하고 있던 DynamoDB 테이블들에 TTL을 적용했고, 그 결과는 매우 극적이었습니다.

• 스토리지 사이즈는 1.2PB에서 74.5TB로 약 94% 감소
• RCU 사용량은 약 60%, WCU 사용량은 약 70% 감소
• 결과적으로 TTL 대상 테이블의 비용을 약 90% 감소

다음 그래프는 삼성 클라우드의 특정 테이블에서 TTL로 삭제된 아이템 수를 나타내며, 피크 시간엔 1분당 약 5백만개 이상의 아이템이 무료로 삭제되고 있음을 보여줍니다. 삼성 클라우드에겐 TTL이 DynamoDB를 사용하고 있는 대표적인 이유 중에 하나가 될 정도로 중요한 기능입니다.

Reserved Capacity

DynamoDB는 예약 용량(Reserved Capacity)을 구매해 최대 77%의 CU 비용을 절감할 수 있는 기능을 갖고 있습니다. 다음 이미지의 빨간선은 삼성 클라우드가 2022년 구매한 예약 용량이고, 초록색 그래프는 실제 CU 사용량으로 1년 전에 구매한 예약 용량의 예측이 잘 되었음을 의미합니다.

삼성 클라우드는 예약 용량 구매량을 결정하기 위해 수집, 예측 그리고 산정의 세 단계를 사용합니다.

• 수집: 수집 단계에서는 리전 별 최근 3-6개월 CU 사용량을 수집하며, 배치 잡이나 이벤트 등의 과사용된 일자들은 제외하고 향후 1년의 삼성 클라우드 서비스 계획에 따른 사용량 증감을 고려합니다.
• 예측: 예측 단계에서는 일별/월별의 최소/최대 CU 값을 도출해 차이를 분석하며, 최소나 최대 CU 사용량을 기준으로 1년 총 CU 사용량을 예측합니다.
• 산정: 산정 단계에서는 리전 별로 예측 사용량의 100%, 90% 혹은 그 이하의 비율로 구매량을 산정합니다. 구매량이 결정되면 전년도 예약 용량 만료 전에 선구매합니다.

구매량이 적용된 이후부터는 구매한 예약 용량의 실제 사용량 커버리지를 모니터링하며, 부족할 경우 다시 한번 추가 물량을 구매하는 방법으로 FinOps를 구현하고 있습니다. 삼성 클라우드는 1년 단위 예약 용량을 구매하여 매년 약 50% 수준의 할인율을 달성하고 있습니다. 또한 실제 사용량보다 좀 더 많은 예약 용량을 구매하더라도 DynamoDB 예약 용량의 높은 할인율을 고려해보면 오히려 이득이 크다는 판단에 공격적으로 구매하고 있습니다.

Standard-Infrequent Access

마지막으로 AWS re:Invent 2021에서 발표된 DynamoDB의 Standard-Infrequent Access (Standard-IA) 스토리지 클래스입니다. 삼성 클라우드는 상하반기에 모든 리소스를 대상으로 비용 최적화 점검 태스크를 수행하고 있으며, Standard-IA 적용 검토도 이 태스크의 일환으로 진행하게 됩니다. 전체 테이블 대상으로 테이블의 비용 구조를 확인해본 결과, 스토리지 비용이 Standard-IA 변경 권장값인 50%를 넘어 80-90% 이상인 테이블들이 다수 존재함을 알게 됩니다. RCU, WCU 사용량 변화에 따라 얼마든지 비용이 역전될 수 있으므로, 비용 시뮬레이션 결과를 기반으로 효과적인 비용 절감을 이끌어내는 테이블만 선정할 수 있는 삼성 클라우드만의 기준을 수립합니다. 그리고 이에 부합하는 50여개의 테이블을 최종 선정하게 됩니다. DynamoDB Standard-IA는 기존과 성능 차이 없이 비용 구조만 변경되는 것이기 때문에 서비스 중에도 언제든 AWS Management Console, AWS CloudFormation 혹은 AWS CLI/SDK로 적용이 가능합니다. 만약 AWS Cost Explorer을 이용해 비용 확인 후 늘었다면, 한달 안에 언제든 다시 Standard로 변경하면 됩니다. 삼성 클라우드는 애플리케이션 코드 수정없이 Standard-IA 적용 후 약 30% 이상의 비용을 절감하는 극적인 결과를 또 한번 만들어냈습니다.

결론

삼성 클라우드는 DynamoDB를 도입한 이후 지속적으로 비용을 최적화하기 위한 다양한 방법과 기능을 찾아 적용하고 있으며, 비용 절감 측면에서 유의미한 절감효과를 만들었던 다섯가지의 방법(Modeling, DynamoDB auto scaling, TTL, Reserved capacity와 Standard-IA)을 소개했습니다. 이외에도 다양한 태스크를 통해 비용을 효율화 할 수 있는 방안을 도출하고 있으며 제시했던 다섯가지의 방법에서도 정교함을 더하기 위해 방법과 절차를 지속적으로 업그레이드 해가고 있습니다. DynamoDB를 처음 접하시는 분들에게는 당연하다고 생각될 오토 스케일링, TTL 그리고 Standard-IA 같은 기능의 시작부터 현재까지, 삼성 클라우드는 비즈니스 성장과 함께 DynamoDB의 역사를 함께 하고 있습니다. DynamoDB 비용 최적화에 대한 내용을 찾고 계시다면, DynamoDB 개발자 가이드의 DynamoDB Well-Architected Lens와 DynamoDB 비용 최적화 블로그 포스트를 참고해보십시오.