هزینه‌ی Object Storage اختصاصی در برابر فضای ابری: چطور محاسبه کنیم؟

بیشتر مقایسه‌های هزینه‌ی Object Storage با یک اشتباه شروع می‌شوند: قیمت هر ترابایت دیسک را با قیمت هر ترابایت فضای ابری مقایسه می‌کنند. این مقایسه تقریباً همیشه گمراه‌کننده است. یک ترابایت دیسک خام، یک ترابایت فضای قابل استفاده نیست؛ و یک ترابایت فضای ابری هم فقط هزینه‌ی نگه‌داری ندارد، هزینه‌ی خواندن و خارج کردن داده هم دارد.

در این مقاله یاد می‌گیرید هزینه‌ی هر دو طرف را چطور جزءبه‌جزء حساب کنید، با یک مثال فرضی که فقط از نسبت‌ها و فرمول‌ها استفاده می‌کند. اعداد واقعی را باید خودتان از پیش‌فاکتور سخت‌افزار، قرارداد دیتاسنتر و تعرفه‌ی سرویس ابری بگذارید. اگر هنوز درباره‌ی خود مفهوم Object Storage مطمئن نیستید، اول مقاله‌ی تفاوت Object Storage با File و Block Storage را بخوانید.

بخش اول: هزینه‌ی Object Storage اختصاصی

۱. ظرفیت خام در برابر ظرفیت قابل استفاده

هیچ Object Storage جدی‌ای داده را فقط یک بار ذخیره نمی‌کند. دو روش اصلی برای افزونگی وجود دارد و هر کدام بخشی از ظرفیت خام را مصرف می‌کند:

Replication (تکثیر): هر شیء در N نسخه نگه‌داری می‌شود. با سه نسخه (پیش‌فرض رایج در Ceph)، فقط یک‌سوم ظرفیت خام قابل استفاده است.
Erasure Coding: داده به k تکه‌ی داده و m تکه‌ی توازن (Parity) تقسیم می‌شود. بهره‌وری برابر است با k/(k+m). مثلاً با 4+2، دوسوم ظرفیت خام قابل استفاده است و خرابی هم‌زمان دو دیسک یا دو نود (بسته به طراحی) را تحمل می‌کند.

عامل دوم، سقف پر شدن است. هیچ کلاستری را نباید تا ۱۰۰٪ پر کرد. Ceph به‌طور پیش‌فرض در حدود ۸۵٪ هشدار می‌دهد و باید همیشه فضای کافی برای بازسازی داده بعد از خرابی یک نود وجود داشته باشد. در عمل، بسیاری از تیم‌ها برنامه‌ریزی را با سقف ۷۰ تا ۸۰ درصد انجام می‌دهند.

فرمول ظرفیت مؤثر:

ظرفیت مؤثر = ظرفیت خام × بهره‌وری افزونگی × سقف پر شدن

Replication سه‌نسخه‌ای:  بهره‌وری = 1/3
Erasure Coding k+m:      بهره‌وری = k / (k+m)

یادتان باشد که Erasure Coding به حداقل تعداد نود بیشتری نیاز دارد (برای 4+2 با تحمل خرابی در سطح نود، حداقل شش نود) و برای فایل‌های بسیار کوچک یا بار کاری با نوشتن‌های پرتعداد، سربار پردازشی بیشتری دارد. یعنی انتخاب روش افزونگی فقط یک تصمیم مالی نیست. مقایسه‌ی ابزارها را در مقایسه‌ی MinIO، Ceph و Garage ببینید.

۲. استهلاک سخت‌افزار

سخت‌افزار را یک‌جا می‌خرید، اما باید هزینه‌اش را روی عمر مفیدش پخش کنید. عمر مفید رایج برای محاسبه سه تا پنج سال است:

هزینه‌ی ماهانه‌ی سخت‌افزار = (سرورها + دیسک‌ها + سوئیچ و کابل + دیسک‌های یدکی) ÷ (تعداد ماه‌های عمر مفید)

دو نکته که معمولاً فراموش می‌شود:

دیسک‌های یدکی و جایگزینی: در یک کلاستر بزرگ، خرابی دیسک رویدادی عادی است، نه استثنا. یک ذخیره‌ی دیسک یدکی را در بودجه بگذارید.
ظرفیت خالی سال‌های اول: شما ظرفیت را برای رشد سه‌ساله می‌خرید، اما در سال اول شاید فقط بخشی از آن پر باشد. هزینه‌ی واقعی هر ترابایت مصرف‌شده در سال‌های اول بسیار بالاتر از عدد اسمی است. خرید مرحله‌ای (اضافه کردن نود با رشد داده) این مشکل را کمتر می‌کند.

۳. محل استقرار: کولوکیشن، برق و پهنای باند

اگر سرورها را در کولوکیشن قرار می‌دهید، هزینه‌ها معمولاً بر اساس فضای رک (تعداد یونیت)، مصرف برق و پهنای باند یا ترافیک محاسبه می‌شود. سرورهای ذخیره‌سازی با دیسک‌های زیاد، برق قابل توجهی مصرف می‌کنند؛ مصرف واقعی را از مشخصات سازنده یا اندازه‌گیری به دست بیاورید، نه از حدس. اگر نودها به هم شبکه‌ی ۱۰ گیگابیت یا بیشتر نیاز دارند، هزینه‌ی سوئیچ و پورت را هم اضافه کنید.

۴. زمان نیروی انسانی

این بزرگ‌ترین قلمی است که در محاسبه‌ها حذف می‌شود. یک Object Storage اختصاصی به این کارها نیاز دارد:

راه‌اندازی و طراحی اولیه (یک‌باره)
مانیتورینگ، رسیدگی به هشدارها و تعویض دیسک
ارتقای نسخه و وصله‌های امنیتی
آماده‌باش برای خرابی‌های خارج از ساعت کاری
تست دوره‌ای بکاپ و بازیابی

هزینه‌ی ماهانه‌ی نیروی انسانی = ساعت کار ماهانه × هزینه‌ی هر ساعت متخصص
                              + (هزینه‌ی راه‌اندازی ÷ عمر مفید به ماه)

اگر تیم شما متخصص Ceph یا ذخیره‌سازی توزیع‌شده ندارد، این عدد یا به استخدام تبدیل می‌شود یا به قرارداد پشتیبانی. هر دو را باید حساب کرد.

بخش دوم: هزینه‌ی فضای ابری

تعرفه‌ی سرویس‌های ابری S3-سازگار معمولاً از چند جزء ساخته می‌شود. قبل از مقایسه، تعرفه‌ی سرویس مورد نظر را دقیق بخوانید، چون ساختار آن بین ارائه‌دهندگان متفاوت است:

ذخیره‌سازی: بر اساس گیگابایت در ماه، گاهی با کلاس‌های مختلف (Standard، Infrequent Access، Archive).
ترافیک خروجی (Egress): هزینه‌ی هر گیگابایتی که از سرویس خارج می‌شود. برای سایت‌هایی که فایل رسانه سرو می‌کنند، این جزء می‌تواند از خود ذخیره‌سازی گران‌تر شود.
درخواست‌ها: هزینه به‌ازای هر هزار درخواست PUT/LIST یا GET. برای میلیون‌ها فایل کوچک، این عدد کوچک نیست.
هزینه‌های جانبی: حداقل مدت نگه‌داری در کلاس‌های ارزان، هزینه‌ی بازیابی از آرشیو، و هزینه‌ی انتقال بین مناطق.

هزینه‌ی ماهانه‌ی ابری = (حجم ذخیره‌شده × نرخ ذخیره‌سازی)
                       + (حجم خروجی × نرخ Egress)
                       + (تعداد درخواست‌ها ÷ 1000 × نرخ درخواست)
                       + هزینه‌های جانبی

و یک هزینه‌ی پنهان دیگر: خروج از سرویس. اگر روزی بخواهید همه‌ی داده را به جای دیگری منتقل کنید، باید Egress کل حجم را یک‌جا بپردازید.

مثال فرضی: مقایسه با نسبت‌ها، نه مبلغ

فرض کنید یک کلاستر شش‌نودی دارید و هر نود ۱۲ دیسک ۱۶ ترابایتی دارد. ظرفیت خام ۱۱۵۲ ترابایت است. حالا دو روش افزونگی را با سقف پر شدن ۸۰٪ مقایسه کنید:

روش افزونگی	بهره‌وری	ظرفیت قابل استفاده	ظرفیت مؤثر (۸۰٪)
Replication سه‌نسخه‌ای	۳۳٪	۳۸۴ ترابایت	حدود ۳۰۷ ترابایت
Erasure Coding 4+2	۶۷٪	۷۶۸ ترابایت	حدود ۶۱۴ ترابایت

با همان سخت‌افزار و همان هزینه، هزینه‌ی هر ترابایت مؤثر در حالت Replication دو برابر حالت Erasure Coding است. پس اولین سؤال در هر برآورد این است: «هزینه به‌ازای کدام ترابایت؟»

حالا فرض کنید هزینه‌ی کل ماهانه‌ی حالت اختصاصی را با M نشان دهیم:

M = (سخت‌افزار ÷ ماه‌های عمر) + کولوکیشن و برق + پهنای باند + نیروی انسانی

هزینه‌ی هر ترابایت مصرف‌شده = M ÷ ترابایت واقعاً پرشده

فرض کنید در سال اول فقط ۲۰۰ ترابایت داده دارید. در حالت Erasure Coding، تقسیم M بر ۲۰۰ انجام می‌شود، نه بر ۶۱۴؛ یعنی هزینه‌ی هر ترابایت مصرفی حدود سه برابر حالتی است که کلاستر به سقف برنامه‌ریزی‌شده برسد. همین عدد را با هزینه‌ی ابری همان ۲۰۰ ترابایت مقایسه کنید.

طرف ابری هم یک فرض دیگر لازم دارد: نسبت خروجی به ذخیره‌سازی. فرض کنید هر ماه معادل نیمی از حجم ذخیره‌شده از سرویس خارج می‌شود (مثلاً فایل‌هایی که کاربران دانلود می‌کنند). در این حالت قبض ماهانه از دو بخش هم‌وزن تشکیل می‌شود و با رشد ترافیک، بخش Egress سریع‌تر از بخش ذخیره‌سازی رشد می‌کند. در مقابل، اگر داده‌ی شما بکاپ است که تقریباً هیچ‌وقت خوانده نمی‌شود، نسبت خروجی نزدیک صفر است و قبض تقریباً فقط هزینه‌ی ذخیره‌سازی است.

نقطه‌ی سربه‌سر جایی است که:

M  =  هزینه‌ی ماهانه‌ی ابری برای همان حجم و همان الگوی دسترسی

این معادله را برای سال اول، سوم و پنجم جداگانه حل کنید، چون حجم داده رشد می‌کند اما M تا زمان خرید نود بعدی تقریباً ثابت می‌ماند.

چه زمانی کدام گزینه برنده است؟

شرایط	گزینه‌ی معمولاً به‌صرفه‌تر
حجم کم (چند ترابایت) و رشد نامعلوم	ابری
حجم زیاد و رشد قابل پیش‌بینی (ده‌ها تا صدها ترابایت)	اختصاصی
ترافیک خروجی بالا (سرو رسانه، دانلود فایل)	اختصاصی، یا ابری با Egress ارزان
داده‌ی آرشیوی و بکاپ با خواندن نادر	ابری با کلاس ارزان، مگر حجم خیلی زیاد باشد
تیم بدون تجربه‌ی ذخیره‌سازی توزیع‌شده و بدون بودجه‌ی پشتیبانی	ابری
الزام قانونی به نگه‌داری داده روی زیرساخت خودتان یا داخل ایران	اختصاصی یا ابر داخلی

عوامل مخصوص ایران

دسترسی و پرداخت: سرویس‌های ابری بین‌المللی بزرگ معمولاً از ایران قابل خرید نیستند و استفاده از آن‌ها ریسک قطع حساب دارد. گزینه‌های واقعی، ابرهای داخلی یا زیرساخت اختصاصی است.
نوسان ارزی: قیمت سخت‌افزار وارداتی به نرخ ارز وابسته است. در برآورد، زمان خرید نودهای بعدی را هم در نظر بگیرید.
ترافیک داخلی و خارجی: اگر کاربران شما داخل ایران هستند، محل نگه‌داری داده روی هزینه‌ی پهنای باند و سرعت دسترسی اثر مستقیم دارد.

یک چک‌لیست برای برآورد خودتان

حجم فعلی داده و نرخ رشد ماهانه را اندازه بگیرید.
نسبت خروجی ماهانه به حجم ذخیره‌شده و تعداد تقریبی درخواست‌ها را از لاگ‌ها دربیاورید.
روش افزونگی و سقف پر شدن را مشخص کنید و ظرفیت مؤثر را حساب کنید.
هزینه‌ی ماهانه‌ی M را با همه‌ی اجزا (از جمله نیروی انسانی) بسازید.
هزینه‌ی ابری را با تعرفه‌ی واقعی برای همان الگو حساب کنید.
مقایسه را برای چند نقطه‌ی زمانی تکرار کنید، نه فقط امروز.

برای نگاه کلی‌تر به مدیریت هزینه‌ی زیرساخت، صفحه‌ی FinOps و بهینه‌سازی هزینه‌ی زیرساخت را هم ببینید.

جمع‌بندی

Object Storage اختصاصی وقتی برنده است که حجم داده زیاد و قابل پیش‌بینی باشد، ترافیک خروجی قابل توجه باشد و کسی برای نگه‌داری آن وجود داشته باشد. فضای ابری وقتی برنده است که حجم کم یا نامعلوم است و نمی‌خواهید درگیر سخت‌افزار و عملیات شوید. در هر دو حالت، مقایسه را با ترابایت مؤثر و با همه‌ی اجزای هزینه انجام دهید، نه با قیمت دیسک.

نمی‌خواهید این محاسبه و پیاده‌سازی را خودتان انجام دهید؟ تیم مروانت نیاز شما را بررسی می‌کند، معماری و ظرفیت مناسب را طراحی می‌کند و Object Storage را روی سرورهای شما یا در دیتاسنتر مروانت راه‌اندازی می‌کند. صفحه‌ی راه‌اندازی Object Storage اختصاصی را ببینید.