From inevitable overprovisioning to the “on-demand” tax: why DynamoDB is bloody hard to cost-control 최근에 잠재적 인 ScyllaDB 고객이 DynamoDB를 실행하는 진정한 비용을 이해하도록 돕는 특정 목표로 지금, 당신이 한 걸음 뒤로 내 목표를보고, 그것은 많은 의미가 없습니다, 그렇지 않습니까? DynamoDB 비용 계산기 순진하게도, 처음에는 저도 그렇게 생각했지만, 그때는 DynamoDB 비용 계산의 내부 작동을 뒤집기 시작했습니다.그때, 팀이 DynamoDB를 규모로 실행하기 위해 수십만 달러 (만약 수백만 달러가 아니라면)를 지불하는 이유가 많다는 것을 깨달았습니다. 가장 중요한 것은 DynamoDB가 채택하기 쉽지만 비용 조절이 어렵다는 것입니다. 나의 직장 동료 Guilherme and I 그러나 당신이 볼 시간이 없다면, 주요 발견을 발견하기 위해 계속 읽으십시오. 이 라인들에 따라 Webinar를 진행했습니다. 첫 번째 일반적인 오해는 정확히 DynamoDB가 당신에게 청구하는 것입니다.당신은 아마도 이미 읽기 용량 단위와 쓰기 용량 단위와 같은 용어를 들었으며, 읽기와 쓰기 수의 관점에서 "당신은 당신이 사용하는 것에 대해 지불합니다. DynamoDB 글쓰기는 비싸다. 만약 당신이 쳐다보면 , 당신은 읽기 요청 단위 (RRU)는 백만 단위 당 $ 0.125 비용, 그리고 쓰기 요청 단위 (WRU)는 백만 단위 당 $ 0.625 비용을 보게 될 것입니다. 그래서, 쓰기는 읽기보다 5 배 더 비싸다. 나는 정확한 기술적 인 이유를 모른다, 그러나 그것은 의심 할 여지없이 쓰기 경로가 더 무겁다는 것과 관련이있다 (내구성, 일관성, 인덱싱 등) 그리고 아마도 일부 헤드룸. 5x는 데이터베이스에 대한 급격한 측면과 비용 관점에서 첫 번째 함정 중 하나 인 것 같습니다. On-Demand 용량의 가격 그것에 대해 말하면 ... 다른 모드가 있습니다 : 이름에서 알 수 있듯이, 이것은 당신이 얼마나 많이 사용할 것인지를 지정할 수 있음을 의미합니다 (당신이 그것을 사용하지 않더라도), 그리고 희망적으로 조금 더 적은 비용을 지불 할 수 있습니다. 비록 비율을 확인하자. 읽기 용량 단위 (RCU)는 RCU 당 $0,00013의 비용과 쓰기 용량 단위 (WCU)는 $0,00065의 비용을 지불합니다.그래서 쓰기는 읽기보다 놀랍게도 5 배 더 비싸다. 제공된 능력 당신은 요청을 제공하지 않습니다, 당신은 요금을 제공하고 있습니다 ... 예비 용량 단위는 수백만 개의 요청에 따라 달라지지 않고 초당 측정됩니다.그것은 처음에 나를 끌어들였습니다.왜 단순히 요청의 총 수를 제공하지 않습니까?그러나 AWS의 관점에서 보면 완벽한 비즈니스 의미가 있습니다. 1초당 N 작업, 그 용량을 사용하든 그렇지 않든. 관리할 수 있는 능력 따라서 트래픽이 폭발하거나 요청의 흔들림을 피하기 위해 예산을 넘어선 경우 (그것에 대해 조금 더), 당신은 기본적으로 빈번한 용량을 지불하고 있습니다. 간단히 말해서, 당신은 지속 가능한 용량을 구입하고 있습니다. 예비 능력... 그래서 여기 거래가 있습니다 : 당신이 용량을 예약하는 경우, 당신은 조금 나중에 절약 할 수 있기를 희망하기 위해 큰 미리 베팅하고 있습니다. 기본 사용에 대한 확신이 있다면, AWS는 EC2 또는 RDS와 마찬가지로 DynamoDB 용량을 예약할 수 있는 옵션을 제공합니다.이 약속은 1년 또는 3년의 사전 지불 약속으로 초당 고정된 읽기 및 쓰기 비율을 잠그고 있습니다. 1 개의 고치 : 부분적인 사전 옵션이 없습니다; 그것은 전체를 지불하거나 멀리 이동합니다. 가격 모델을 비교하기위한 간단한 사용 사례를 살펴보자... 한 시간 동안 작업량 평균 10,000 개의 읽기 / 초 및 10,000 개의 쓰기 / 초라고 가정하십시오. On Demand 가격 : 글쓰기: $22.50/hr ... 10,000 * 3600 * 0.625 / 1M 읽기: $ 4.50 / 시간 ... 10,000 * 3600 * 0.125 / 1M (일반적으로 쓰는 것보다 5배 저렴) 예비 가격 (비 예약) : 글쓰기: $6.50/hr ... 10,000 * $0.00065 읽기: $1.30/hr ... 10,000 * $0.00013 1 년 예약을 제공 : 글쓰기 : ~ $ 2.99/hr 읽기: ~$0.59 / 시간 “헤이, 예비 수학은 어디에 있습니까?”나는 당신을 듣습니다. 당신은 100 WCU ($0.0128/hr) 및 RCU ($0.0025/hr)에 대한 예비 가격을 가져, 한 달에 730 시간으로 나누어, 1 년에 12 개월로 나누어, 100 단위로 다시 나누어, 필요한 비율로 곱합니다 ... 그 다음 그것을 돌리십시오, 약간 울고 "수학 여인"메메메에 붙여 넣으십시오. 내 점은 : Provisioned는 ~3.4x on-demand보다 저렴합니다 예약은 ~7.5x on-demand보다 저렴합니다 On-demand는 과도한 지불을 좋아하거나 예측을 싫어하는 사람들을위한 것입니다. BTW 는, 에 대한 : AWS는 On Demand를 추천합니다. 시간이 지남에 따라 진화하는 교통 패턴 Spiky 또는 batchy workloads 낮은 사용량 (최고의 0 % 또는 30% 이하로 떨어지는) ScyllaDB의 고객에게 적어도 모든 실제 작업량입니다.그래서 그렇습니다.당신의 트래픽이 교과서의 파도처럼 보이지 않는 한 그 유연성에 대한 프리미엄을 지불 할 것으로 예상됩니다. 그것은 항목의 크기가 아니지만 그것은 ... 이것은 실제 응용 프로그램 데이터를 사용할 때까지 당신이 만날 수없는 함정입니다 ...이 시점에서 당신은 즉시 그것을 놓치고 후회 할 것입니다. DynamoDB에서, 당신은 단지 작업 당 지불하지 않습니다; 당신은 전송 된 데이터의 조각 당 지불합니다.그리고 조각 크기는 읽기와 쓰기 사이에 다릅니다: Writes는 1KB(Write Request Units 또는 WRUs)에 의해 청구됩니다. 4KB (Read Request Units 또는 RRUs) 따라서 1.1KB 항목을 작성하면 2 WRU입니다. 3KB 항목을 작성합니까? 여전히 3 WRU, 각 1KB (또는 그 일부)가 계산됩니다. Reads는 4KB 경계에서만 동일한 방식으로 작동합니다. 1KB 항목을 읽으십시오? 1 RRU 항목을 읽으십시오. 4.1KB 항목을 읽으십시오. 이러한 경계에 대한 강력한 기술적 이유가 있을 것이라고 확신합니다. 여기서 함정을 볼 수 있습니다. 읽는 것에 비해 쓰기 비용의 5배와 이것을 결합하고, 특히 항목 크기가 그 경계를 극복하지 않는 경우, 물건 크기가 빨리 나빠질 수 있습니다. 당신이 당신의 계획에 고정된 항목 크기가있는 경우 아마도 괜찮지만, 확실히 ScyllaDB에서 볼 수있는 사용 사례의 유형과 함께 괜찮지 않습니다. 예를 들어, 고객은 사용과 함께 줄거나 성장할 수있는 JSON 또는 blob 필드를 삽입했을 수 있습니다. 그리고 기억하십시오. 과도한 공급, 왜냐하면 당신은 ... AWS의 자신의 계산기에서 또 다른 고통스러운 점은 예비 용량을 사용할 때 과도한 예비의 필요성입니다.이것은 직관적이지만, 당신이 원하기 때문에가 아니라 DynamoDB가 그렇지 않으면 당신을 처벌하기 때문에 과도한 예비에 강요됩니다. 제공된 용량을 초과하면 충돌할 수 있습니다.If you slip past the provided capacity, you will hit 나는이 유형의 예외 메시지의 명확성을 좋아한다.나는 그것이 실제로 무엇을하는지 좋아하지 않는다, 그러나 : 요청 throttling. 그것은 사용되지 않은 읽기 및 쓰기 용량을 유지합니다.하지만 그 이상, 앱은 단순히 실패합니다. 예외예외예외예외 300s 창 폭발 능력 따라서, 이것을 방해하는 가장 좋은 방법은 과도한 공급입니다. 얼마에 의해? 그것은 "그것은 달라집니다"응답을 보장합니다. 그러나 그것은 당신의 워크로드 유형에 따라 달라집니다. 우리는 우리의 계산기에이 기능을 추가하므로 당신은 역동적으로 과도한 공급을 비율로 할 수 있습니다, 당신의 워크로드에 추가 비용을 계산하기 위하여. 분명히, 이러한 비용은 빠르게 증가 할 수 있습니다, 왜냐하면 실제로, 당신은 당신이 에서 작동하는 경우에도, 당신은 비용을 지불하고 있습니다.당신이 충분히 높은 용량을 공급하지 않는 경우, 당신의 은 최악의 시간에 고객을 향한 실패를 줄 수 있습니다. 우리가 움직이기 전에... 여기에 반복적인 테마가 있다면 이것은 다음과 같습니다 : DynamoDB의 가격은 본질적으로 잘못된 것이 아닙니다. 당신은 당신이 사용하는 것에 대해 지불합니다. 그것이 무엇이든간에 : 5x Writing Cost Multiplier 사용하기 7.5x On-Demand Cost Multiplier 사용하기 Opaque Per-Second Provisioned Rates에 대한 리뷰 보기 Punitive rounding and artificial boundaries of item sizes 부품 크기의 인공 경계 또는 피크로드 중에 얼굴을 심는 것을 피하기 위해 과도한 공급의 필요성 당신은 끊임없이 당신의 건축을 두 번째로 추측해야만 비용 폭발을 앞두고있다. 아이러니하게도 DynamoDB는 “서버없는” 및 “완전히 관리”으로 브랜드화되었지만, 당신은 용량 수학, throttling 오류, 아케인 가격 계층 및 끝없는 통과 체조를 관리하는 데 끝납니다. DynamoDB에 대한 고객의 많은 태블릿 예측 (및 AWS Cost Explorer 수출)을 관찰 한 후, 대규모 시스템을 실행하는 성숙한 팀조차도 비용이 무엇인지 알지 못합니다 ... 너무 늦을 때까지. 따라서 비용을 고정하는 첫 번째 단계는 비용이 어디에서 왔는지 이해하기 때문입니다.This is why we built a calculator that models real workloads, not just averages. 에서 , 나는 트래픽 패턴, 항목 크기, 캐시 및 다중 지역 토폴로그의 진정한 영향을 보여주기 위해 DynamoDB에서 ScyllaDB로 전환 한 고객의 실제 사례를 살펴보고 있습니다. 에 . 내 다음 블로그 포스팅 앞으로 뛰어 내리고 자신의 워크로드를 모델링 마이너리스트.scylladb.com 우리의 새로운 비용 계산기에서 자신의 DynamoDB 워크로드를 모델 Tim Koopmans에 관해 Tim은 신뢰성과 보안에 대한 열망으로 지난 수십 년 동안 모든 형태의 엔지니어링에 손을 잡았습니다.2013 년에 그는 분산 성능 테스트 플랫폼 인 Flood IO를 설립했습니다.이를 인수 한 후, 그는 다른 성능 관련 노력으로 전환하기 전에 제품, 비즈니스 및 팀을 확장하는 것을 즐겼습니다.
