From inevitable overprovisioning to the “on-demand” tax: why DynamoDB is bloody hard to cost-control সম্প্রতি সম্ভাব্য ScyllaDB গ্রাহকদের DynamoDB চালানোর প্রকৃত খরচ বুঝতে সাহায্য করার নির্দিষ্ট লক্ষ্য সঙ্গে. এখন, যদি আপনি পিছিয়ে যান এবং আমার লক্ষ্যের দিকে তাকান, এটি অনেক অর্থহীন, তাই না? যদি কেউ ইতিমধ্যে DynamoDB ব্যবহার করে, তারা ইতিমধ্যে DynamoDB চালানোর জন্য কত খরচ জানত? DynamoDB খরচ ক্যালকুলেটর কিন্তু তারপর, আমি DynamoDB খরচ হিসাবের অভ্যন্তরীণ কার্যকারিতা পুনরুদ্ধার করতে শুরু করেছি. সেই মুহূর্তে, আমি বুঝতে পেরেছি যে অনেক কারণ আছে কেন টিমগুলি শত শত হাজার (যদি মিলিয়ন না) ডলার পরিশোধ করতে DynamoDB মাত্রায় চালান। প্রধান জিনিস আমি খুঁজে পেয়েছি: DynamoDB গ্রহণ করা সহজ, কিন্তু খরচ নিয়ন্ত্রণ করা রক্তাক্ত কঠিন। আমার সহকর্মী Guilherme এবং আমি , কিন্তু যদি আপনি দেখার জন্য সময় না থাকে, তাহলে প্রধান ফলাফলগুলি খুঁজে বের করার জন্য পড়ুন। এই লাইনগুলিতে একটি ওয়েবিনার আপনি সম্ভবত ইতিমধ্যে পড়া ক্ষমতা ইউনিট এবং লিখা ক্ষমতা ইউনিট মত শব্দ শুনেছেন, এবং পড়া এবং লিখা সংখ্যা হিসাবে "আপনি যা ব্যবহার করেন তার জন্য অর্থ প্রদান করেন" এর শব্দটি পেতে পারেন। ডায়াবেটিসের দাম বেশি... আপনি যদি দেখেন , আপনি দেখতে পাবেন যে একটি পড়া অনুরোধ ইউনিট (RRU) প্রতি মিলিয়ন ইউনিটের জন্য $ 0.125 খরচ করে, এবং একটি লিখা অনুরোধ ইউনিট (WRU) প্রতি মিলিয়ন ইউনিটের জন্য $ 0.625 খরচ করে। সুতরাং, লিখা পড়ার চেয়ে 5 গুণ বেশি ব্যয়বহুল। আমি সঠিক প্রযুক্তিগত কারণ জানি না, কিন্তু কোনও সন্দেহ নেই যে লিখা পথটি আরও ভারী (দৈর্ঘ্য, সংক্ষিপ্ততা, ইনডেক্সিং ইত্যাদি) এবং সম্ভবত কিছু headroom হয়। 5x ডাটাবেসের জন্য একটু উঁচু দিক এবং খরচের দিক থেকে প্রথম ফাঁদগুলির মধ্যে একটি। অনুরোধযোগ্য ক্ষমতা জন্য মূল্য যার কথা বলতে... এখানে আরেকটি মোড আছে: . যেমনটি নামে বলা হয়, এটি মানে আপনি নির্দিষ্ট করতে পারেন যে আপনি কতটুকু ব্যবহার করতে যাচ্ছেন (যদি আপনি এটি ব্যবহার না করেন) এবং আশা করি একটু কম অর্থ প্রদান করবেন। যাইহোক, অনুপাতটি চেক করুন. একটি পড়া ক্ষমতা ইউনিট (RCU) RCU প্রতি $0.00013 খরচ করে এবং একটি লিখা ক্ষমতা ইউনিট (WCU) $0.00065 খরচ করে, তাই লিখা পড়ার চেয়ে বিস্ময়করভাবে 5 গুণ বেশি ব্যয়বহুল। প্রত্যাশিত ক্ষমতা আপনি অনুরোধ সরবরাহ করছেন না, আপনি হার সরবরাহ করছেন ... এখানে ধরা যাক: প্রদানযোগ্য ক্ষমতা ইউনিটগুলি প্রতি সেকেন্ডে পরিমাপ করা হয়, অনুরোধের জন্য এক মিলিয়ন অনুরোধের মতো নয়। যা আমাকে প্রথমে আঘাত করেছে। কেন শুধু অনুরোধগুলির মোট সংখ্যা প্রদান করবেন না? প্রতি সেকেন্ডে N অপারেশন, আপনি সেই ক্ষমতা ব্যবহার করছেন কিনা। আচরণ করার ক্ষমতা সুতরাং যদি আপনার ট্র্যাফিক বিস্ফোরিত হয়, অথবা আপনি অনুরোধগুলি হ্রাস করার জন্য সরবরাহ করার চেষ্টা করছেন (এটা সম্পর্কে একটু বেশি), আপনি মূলত বহিরাগত ক্ষমতা জন্য অর্থ প্রদান করছেন। ক্ষমতা সংরক্ষণ... সুতরাং এখানে চুক্তি: যদি আপনি ক্ষমতা সংরক্ষণ করেন, তবে আপনি আশা করি একটু পরে সংরক্ষণ করতে বড় অগ্রিম বাজি ধরছেন। আপনি যদি আপনার বেসলাইন ব্যবহারে আত্মবিশ্বাসী হন তবে AWS আপনাকে ডাইনামোডিবি ক্ষমতা রিজার্ভ করার বিকল্প দেয়, ঠিক যেমনটি EC2 বা RDS এর সাথে। একটি গাচা: কোনও আংশিক অগ্রিম বিকল্প নেই; এটি সম্পূর্ণরূপে অর্থ প্রদান করে অথবা চলে যায়। দামের মডেলগুলি তুলনা করার জন্য একটি সহজ ব্যবহার ক্ষেত্রে দেখুন ... বলুন আপনার ওয়ার্ক লোডের গড় 10,000 পাঠ / সেকেন্ড এবং 10,000 লিখা / সেকেন্ড এক ঘন্টায়। অনুরোধের দাম: চিঠি: $ 22.50 / ঘন্টা ... 10,000 * 3600 * 0.625 / 1M পড়া: $ 4.50 / ঘন্টা ... 10,000 * 3600 * 0.125 / 1M (দৈনন্দিন হিসাবে লেখা চেয়ে 5x সস্তা) মূল্য নির্ধারিত (নির্ধারিত) : চিঠি: $ 6.50 / ঘন্টা ... 10,000 * $ 0.00065 পড়া: $1.30 / ঘন্টা ... 10,000 * $0.00013 1 বছরের জন্য সংরক্ষিত: লিখিত: ~ $ 2.99 / ঘন্টা পড়া: ~$ 0.59 / ঘন্টা “হ্যালো, সংরক্ষিত গণিত কোথায়? “আমি আপনাকে শুনি। আপনি 100 WCUs (0,0128 / ঘন্টা) এবং RCUs (0,0025 / ঘন্টা) জন্য সংরক্ষিত মূল্য গ্রহণ করুন, একটি মাসে 730 ঘন্টা দ্বারা বিভক্ত করুন, একটি বছরের 12 মাস দ্বারা বিভক্ত করুন, আবার 100 ইউনিট দ্বারা বিভক্ত করুন, আপনার প্রয়োজনীয় হার দ্বারা সংখ্যা করুন ... তারপর এটি ঘুরে দাঁড়ান, একটু কাঁদুন এবং "ম্যাটালি লেডি" মেমে স্থাপন করুন। আমার পয়েন্ট হল: সরবরাহ করা ~3.4x অনুরোধের তুলনায় সস্তা রিজার্ভ করা হয় ~7.5x on-demand তুলনায় সস্তা অনুরোধে, যারা অতিরিক্ত অর্থ প্রদান করতে পছন্দ করে, বা পূর্বাভাস করতে ঘৃণা করে বিপিএল জন্য : AWS On-Demand পরামর্শ ট্রাফিক প্যাটার্ন যা সময়ের সাথে সাথে বিবর্তিত হয় Spiky বা ব্যাচি ওয়ার্কলোড নিম্ন ব্যবহারযোগ্যতা (শূন্য বা সর্বোচ্চ 30% এর নিচে পতন) যা মূলত প্রতিটি বাস্তব জীবনের কাজের লোড - অন্তত ScyllaDB এর গ্রাহকদের জন্য। এটি আইটেমের আকারের নয়, কিন্তু এটি ... এটি এমন একটি ফাঁদ যা আপনি বাস্তব অ্যাপ্লিকেশন ডেটা ব্যবহার না হওয়া পর্যন্ত আঘাত করতে পারবেন না ... যে মুহূর্তে আপনি অবিলম্বে এটি অবহেলা করার জন্য দুঃখিত হবেন। ডাইনামোডিবিতে, আপনি শুধুমাত্র অপারেশন প্রতি পরিশোধ করেন না; আপনি স্থানান্তরিত ডেটা প্রতি টুকরো পরিশোধ করেন. এবং টুকরো আকার পড়া এবং লিখা মধ্যে পার্থক্য: Writes প্রতি 1KB (Write Request Units বা WRUs) হিসাব করা হয়। 4KB (Read Request Units বা RRUs) সুতরাং যদি আপনি 1.1KB আইটেম লিখেন, তাহলে 2 WRUs। 3KB আইটেম লিখুন? এখনও 3 WRUs, প্রতি 1KB (বা এর অংশ) হিসাব করা হয়। Reads একইভাবে কাজ করে, কেবলমাত্র 4KB সীমান্তে. 1KB আইটেম পড়ুন? 1 RRU পড়ুন. 4.1KB আইটেম পড়ুন? আমি নিশ্চিত যে এই সীমানাগুলির জন্য শক্তিশালী প্রযুক্তিগত কারণ রয়েছে. আপনি এখানে ফাঁদটি দেখতে পারেন. একটি পড়ার তুলনায় একটি লিখার 5x খরচের সাথে এটি সংযুক্ত করুন, এবং জিনিসগুলি দ্রুত খারাপ হতে পারে, বিশেষ করে যদি আপনার আইটেমের আকার আপনি বুঝতে না পারলে এই সীমানাগুলি ঘুরে বেড়ায়। এটি সম্ভবত ঠিক আছে যদি আপনার পরিকল্পনায় একটি স্থিতিশীল আইটেমের আকার থাকে, তবে অবশ্যই ScyllaDB এ আমরা দেখি এমন ধরনের ব্যবহারের ক্ষেত্রে ঠিক নয়। অতিরিক্ত পরিমাণে, কারণ আপনাকে ... আরেকটি ব্যথা পয়েন্ট, এবং AWS এর নিজস্ব ক্যালকুলেটর থেকে বিপরীত অনুপস্থিতি, প্রদানযোগ্য ক্ষমতা ব্যবহার করার সময় অতিরিক্ত প্রদান করার প্রয়োজন। এটি অনাক্রম্য মনে হয়, কিন্তু আপনি অতিরিক্ত প্রদান করতে বাধ্য হন - কারণ আপনি চান না, কিন্তু কারণ DynamoDB আপনাকে শাস্তি দেয় যদি আপনি না করেন। যদি আপনি প্রস্তাবিত ক্ষমতা অতিক্রম করেন তবে আপনি আঘাত পাবেন . আমি এই ধরনের ব্যতিক্রম বার্তা স্পষ্টতা ভালবাসি. আমি আসলে কি ভালবাসি না, যদিও: অনুরোধ throttling. যা অব্যবহৃত পড়া এবং লিখা ক্ষমতা বজায় রাখে. কিন্তু এর বাইরে, আপনার অ্যাপ্লিকেশন শুধু ব্যর্থ হয়. অতিরিক্ত অতিরিক্ত অর্ডার 300s উইন্ডো বিস্ফোরণ ক্ষমতা সুতরাং, এটি প্রতিরোধ করার সর্বোত্তম উপায় হল অতিরিক্ত সরবরাহ। কত? এটি একটি "এটা নির্ভর করে" উত্তর নিশ্চিত করে. কিন্তু এটি আপনার কাজের লোডের ধরনের উপর নির্ভর করে. আমরা আমাদের ক্যালকুলেটর এ এই কার্যকারিতা যোগ করেছি যাতে আপনি শুধুমাত্র আপনার কাজের লোডের অতিরিক্ত খরচ হিসাব করার জন্য শতকরা দ্বারা অতিরিক্ত সরবরাহ করতে পারেন. অবশ্যই, এই খরচগুলি দ্রুত যোগ করতে পারে কারণ বাস্তবতাতে, আপনি যদি তাড়াতাড়াতাড়ি কাজ করছেন তবুও আপনি যথেষ্ট উচ্চ ক্ষমতা সরবরাহ করছেন না, তাহলে আপনার তাড়াতাড়ি ঝুঁকিপূর্ণ হওয়ার ঝুঁকি রয়েছে, এগিয়ে যাওয়ার আগে... যদি এখানে একটি পুনরাবৃত্তি থিম থাকে, তাহলে এটি এই: ডাইনামোডিবি এর মূল্যায়ন অভ্যন্তরীণভাবে ভুল নয়. আপনি যা ব্যবহার করেন তার জন্য অর্থ প্রদান করেন. যাইহোক, এটি কোনও কাজের লোডের জন্য অসহায়ভাবে ক্ষমাশীল যা একটি নিখুঁত, পূর্বাভাসযোগ্য সিনিয়াল হিসাবে দেখায় না। এটা যাই হোক না কেন: 5x লিখতে খরচ multiplier 7.5x on-demand খরচ multiplier প্রতি সেকেন্ডে প্রত্যাশিত হার শাস্তিমূলক আর্দ্রতা এবং আইটেম আকারের শিল্পী সীমানা অথবা শুধু পিক লোডের সময় মুখ-পাটিং এড়ানোর জন্য অতিরিক্ত সরবরাহের প্রয়োজন ...আপনি ক্রমাগত আপনার আর্কিটেকচারটি দ্বিতীয় ধারণা করতে হবে শুধুমাত্র খরচের বিস্ফোরণের সামনে থাকার জন্য। ডাইনামোডিবিকে "সার্ভারহীন" এবং "পূর্ণরূপে পরিচালিত" হিসাবে ব্র্যান্ড করা হয়, কিন্তু আপনি ক্ষমতা গণিত, গ্লটলিং ত্রুটিগুলি, আর্কান মূল্য স্তরগুলি, এবং অবিশ্বাস্য গতিশীলতা পরিচালনা করেন। ডাইনামোডিবিের জন্য আমাদের গ্রাহকদের অনেকগুলি ট্যাবলেটের পূর্বাভাস (এবং AWS Cost Explorer রপ্তানি) পর্যবেক্ষণ করে, এমনকি বড় আকারের সিস্টেমগুলি পরিচালনা করে পরিপক্ক টিমগুলিরও কোন ধারণা নেই ... যতক্ষণ না এটি খুব দেরি হয়। এজন্য আমরা একটি ক্যালকুলেটর তৈরি করেছি যা বাস্তব ওয়ার্ক লোডগুলি মডেল করে, শুধু গড় নয় কারণ খরচগুলি সংশোধনের প্রথম পদক্ষেপটি বুঝতে হবে যে তারা কোথা থেকে আসে। এতে , আমি কয়েকটি বাস্তব বিশ্বের উদাহরণগুলির মাধ্যমে হাঁটছি যে গ্রাহকরা ডাইনামোডিবি থেকে ScyllaDB-এ চলে গেছেন যাতে ট্র্যাফিক প্যাটার্ন, আইটেম আকার, ক্যাশ এবং মাল্টি-রাজ্য টোপোলজিগুলির বাস্তব প্রভাব দেখায়। এতে . আমার পরবর্তী ব্লগ পোস্ট এগিয়ে যান এবং আপনার নিজস্ব ওয়ার্ক লোড মডেল ক্যালকুলেটর.scylladb.com আমাদের নতুন খরচ ক্যালকুলেটর উপর আপনার নিজস্ব DynamoDB ওয়ার্ক লোড মডেল টাইম কোপম্যানস টাইম গত কয়েক দশক ধরে নির্ভরযোগ্যতা এবং নিরাপত্তা নিয়ে সব ধরনের প্রকৌশল নিয়ে কাজ করেছেন। ২০১৩ সালে তিনি একটি বিতরণযোগ্য পারফরম্যান্স টেস্টিং প্ল্যাটফর্ম, ফ্লোড আইও প্রতিষ্ঠা করেছিলেন।
