نکات کلیدی
-
استفاده از دیتابیسهای رابطهای مدیریتشده در سالهای اخیر بهخاطر مزایایی مثل میزبانی، مقیاسپذیری و هزینه، بهشدت رشد کرده است.
-
کاربر لازم است هزینههای سرویس، شامل هزینههای Egress (خروج داده)، را پایش کند و تنظیمات پیشفرض سرویس را با توجه به بارِ کاری خود بازبینی کند.
-
کاربر باید هزینههای عملیاتی مرتبط با استفاده از یک سرویس مدیریتشده را درک کند.
-
کاربر باید محدودیتهایی مثل کمبود انعطافپذیری، ضعف در مشاهدهپذیری و غیره را بهتر بشناسد.
-
کاربر باید تصمیم آگاهانه بگیرد که چه زمانی استفاده از راهحل دیتابیس مدیریتشده مناسب است و چه زمانی نه.
رایانش ابری همهجا هست، اغلب بدون اینکه متوجه شویم (برای مثال، iCloud و Google Docs). رایانش ابری بهاندازه ابرهای واقعی فراگیر شده است. بسیاری از مزایای رایانش ابری، مانند کشسانی، مقیاسپذیری و سهولت استفاده، در این نقطه بهخوبی شناخته شدهاند. آنها زمان عرضه به بازار را برای محصولات جدید کاهش میدهند و چالشهای مقیاسدهی محصولات موجود را بدون عبور از یک فرایند دشوار برنامهریزی و تدارکات، برطرف میکنند.
بهدلیل این مزایا، ما شاهد تقاضای عظیم برای سرویسهای مدیریتشده برای پایگاههای داده، صفهای پیام، محیط اجرای برنامه و غیره بودهایم. با این حال، این مقاله درباره سمت کمتر بحثشده رایانش ابری است: هزینه پنهان استفاده از سرویسهای مدیریتشده، به طور خاص پایگاههای داده رابطهای مدیریتشده.
بهعنوان یک متخصص پایگاهداده در Cloudflare و در حال ساخت Omnigres، من تجربه توسعه، مدیریت و بهرهبرداری از پایگاههای داده در محیطهایی مانند کاملاً داخلسازمانی، ابر عمومی و ترکیبی را داشتهام. از منظر کسبوکار، هر مدل مزایا و معایب خود را دارد. زمانی که یک شرکت ابر عمومی را میپذیرد، استفاده از هر سرویس مدیریتشدهای نسبتاً ساده است، و پایگاههای داده تنها یک کلیک فاصله دارند.
سهولت استفاده دروازهای است برای کاربران تا شروع به استفاده از یک سرویس کنند. در بیشتر مواقع، فقط کار میکند، پس چرا ادامه ندهیم یا حتی یک قدم جلوتر نرویم؟ چرا نمونههای بیشتری از آن ایجاد نکنیم؟
هزینه – پول واقعی
پایگاههای داده مدیریتشده از طرف ارائهدهندگان رایانش ابری ارزش زیادی ارائه میکنند از نظر اجرای آنها، پشتیبانگیری از آنها و پایش آنها. آنها همچنین مراقبت از دسترسپذیری بالا را انجام میدهند. من در SCaLE20x چالشهای ساخت یک سرویس پایگاهداده مدیریتشده داخلی را ارائه کردم: سپردن آن کار به یک ارائهدهنده، هزینههای عملیاتی و زمان عرضه به بازار را کاهش میدهد و انعطافپذیری بیشتری میآورد. برای ارائه این مزایا، یک ارائهدهنده از کاربران هزینه دریافت میکند.
اول، محاسبه اینکه یک پایگاهداده مدیریتشده چقدر هزینه خواهد داشت، سرراست نیست. هزینه به چندین عامل بستگی دارد، مانند:
- اندازه و کلاس نمونه (کوچک، بزرگ، بسیار بزرگ)
- مدل قیمتگذاری (درخواستمحور، رزروی)
- ذخیرهسازی (عمومی، ذخیرهسازی با IOPS تأمینشده، IOPS واقعی)
- هزینههای انتقال داده (داخل/خارج شبکه خصوصی، بین/درون منطقه)
- موتور پایگاهداده (PostgreSQL، MySQL، SQL Server و غیره)
- بازه زمانی و نگهداشت ذخیرهسازی پشتیبان
- نوع استقرار (تکمنطقهای/چندمنطقهای، بدونسرور)
حتی اگر پیچیده باشد، قابل اندازهگیری است. برخی ابزارهای شخص ثالث محاسبه قیمت را سادهتر میکنند. همچنین، بهینهسازیهای هزینه مانند غیرفعال کردن چندمنطقهای و متوقف کردن نمونهها برای محیطهای توسعه بسیار رایج است. شرکتهایی مانند Walmart شروع به حرکت به سمت ابر ترکیبی کردهاند. همزمان، شرکتهای کوچکتری مانند Basecamp بیشتر سرویسهای خود را عمدتاً به دلایل هزینه از ابر خارج کردهاند.
برای درک اینکه آیا هزینه سرویس مدیریتشده ارزش دارد، فرد باید الگوی استفاده خود را درک کند. مزیت اصلی ابر، انعطافپذیری است؛ اگر کسی به آن نیاز نداشته باشد، بهتر است پایگاههای داده خود را روی سختافزار خودشان اجرا کنند. بیایید به حوزههای دیگری بپردازیم که هزینه در آنها ذهنیتر و تا حدی دشوار برای اندازهگیری است.
Runaway Workload
یکی از پیشنهادهای ارزش منحصربهفرد رایانش ابری مقیاسپذیری است. اگر وبسایت یا محصول یکشبه محبوب شود، نیازی به تهیه زیرساخت برای پشتیبانی از بار کاری نیست. این عالی است، اما نکتهای هم دارد؛ اگر با احتیاط استفاده نشود، میتواند غافلگیرکننده باشد. تصور کنید یک بار کاری رهاشده یا سرکش علیه پایگاهداده اجرا شود، و از آنجا که بسیاری از ارائهدهندگان ابر بر اساس ورودی/خروجی یا زمان پردازنده و غیره هزینه دریافت میکنند، این بارهای کاری میتوانند یک صورتحساب عظیم بدون هیچ استفادهای ایجاد کنند.
هزینههای Egress – وارد کردن داده راحت است، خارج کردنش نه
در یک ساختار چندابری یا ابر ترکیبی، سرویسها باید از طریق شبکه بین ارائهدهندگان مختلف ارتباط برقرار کنند. معمولاً برای آوردن داده (ورود) به یک پایگاهداده مدیریتشده، هزینه انتقال داده وجود ندارد. با این حال، خارج کردن داده (خروج) هزینه دارد. هزینه خروج یک عامل هزینه قابلتوجه برای کسبوکارهایی است که داده را از سرویس پایگاهداده مدیریتشده خود منتقل میکنند. به یک معنا، این موضوع کاربران را تشویق میکند که داده خود را از ارائهدهنده خارج نکنند.
ارائهدهندگانی مانند Cloudflare این چالش را درک کرده و اتحاد پهنایباند را ایجاد کردند؛ اتحادی که تخفیف میدهد یا هزینههای انتقال داده بین ارائهدهندگانی که بخشی از آن هستند را حذف میکند. اخیراً، Google Cloud هزینه انتقال داده برای مهاجرت داده به یک ارائهدهنده ابری دیگر را حذف کرده است. این عمل آنقدر ناعادلانه تلقی شده که نهادهای مقرراتگذار از اتحادیه اروپا و بریتانیا فعالانه در حال بررسی آن هستند.
هزینههای عملیاتی – هنوز کارهایی باقی است
در حالی که ارائهدهنده سرویس مراقبت از عملیات روز صفر را بر عهده میگیرد، همچنان چالشهای روز اول و روز دوم وجود دارند. انتظار اینکه ارائهدهنده همه چالشهای عملیاتی را حل کند، منطقی نیست. با این حال، حداقل خوب است بدانیم این عملیاتها چگونه به نظر میرسند و هزینههای درگیر چیست.
الف) Backupهای ثانویه
داده هسته کسبوکار است. من استدلال میکنم که هر کسبوکار نرمافزاری را میتوان دوباره ساخت اگر دادهها سالم باشند. بهعنوان یک مهندس پایگاهداده، از دست دادن داده بزرگترین کابوس من است. محتاط بودن درباره پشتیبانگیریها کار بدی نیست. اتکا صرف به ارائهدهنده برای پشتیبانگیری مانند گذاشتن همه تخممرغها در یک سبد است. فرض کنید ارائهدهنده یک توافق سطح سرویس ارائه میکند، این یک افزوده خوب است. با این حال، خطر از دست رفتن کامل پشتیبان توسط ارائهدهنده نیز وجود دارد.
برای بیشتر موارد، این مسئولیت کسبوکار است که از داده مشتریان خود محافظت کند. بیشتر سازمانهای بالغ پشتیبانگیریهای ثانویه خارج از ارائهدهنده اصلی دارند. برای انجام این کار، هزینهای وجود دارد از نظر پول واقعی برای ذخیرهسازی و محاسبات، انتقال داده و هزینههای مهندسی.
ب) بازگردانی Backup
کیفیت پشتیبانها با توانایی آنها در بازگردانی موفق تعیین میشود. پشتیبانها چه ارزشی دارند اگر نتوان آنها را بازگردانی کرد؟ متأسفانه بسیاری از ارائهدهندگان در این بخش کاری انجام نمیدهند و این قسمت را به کاربران خود واگذار میکنند. قابلدرک است که این مسئله پیچیده است چون ارائهدهندگان نیازهای هر کسبوکار را نمیدانند. بنابراین کاربران باید بهطور مداوم بازگردانی را، چه بهصورت خودکار یا دستی، آزمایش کنند تا یکپارچگی پشتیبانها و رویه بازگردانی خود را اعتبارسنجی کنند.
سرویسهایی که متوقف میشوند – این اتفاق میافتد
متأسفانه، با تکامل چیزها، برخی سرویسها میتوانند متوقف شوند. سال گذشته، MariaDB روی Azure بازنشسته شد. نسخه اول Aurora Serverless پس از ۲۰۲۴ دیگر پشتیبانی نخواهد شد. اگر پایگاهداده متنبسته باشد، تنها راه خارج شدن، استفاده از هر ابزاری است که ارائهدهنده برای صادر کردن آن به مکان دیگر ارائه میدهد. بدیهی است که مهاجرت داده باید بهگونهای طراحی شود که از دست رفتن داده و زمان از کار افتادن را کاهش دهد. اگر پایگاهداده بر پایه یک پایگاهداده متنباز مانند Postgres یا حتی از طریق یک پروتکل باز پشتیبانی شود، مهاجرت تا حدی آسانتر است. با این وجود، مهاجرت پایگاهداده/داده همیشه دردناک است.
کمبود انعطافپذیری – نمیتوان همه چیز را با هم داشت
از آنجا که سرویسهای مدیریتشده تمایل دارند روی حل مشکلات مشترک تمرکز کنند، گاهی محدودکننده هستند. از آنجا که ارائهدهنده باید بسیاری از سرویسها را برای هزاران مشتری مدیریت کند، فراهم کردن انعطافپذیری کامل دشوار یا غیرممکن است. ممکن است در ابتدا مسئلهساز به نظر نرسد، اما با رشد کسبوکار میتواند شروع به آسیب زدن کند. برای مثال، Postgres یک اکوسیستم بزرگ از افزونهها دارد.
بسیاری از سرویسهای مدیریتشده تنها اجازه نصب مجموعهای از افزونهها را میدهند. برای مثال، افزونههای متنباز مانند نگهداری نمای افزایشی و جستجوی درون پایگاهداده در برخی ارائهدهندگان پشتیبانی نمیشوند، که میتواند بهشدت محدود کند چه قابلیتهایی میتوانید بسازید یا به آنها تکیه کنید.
کمبود دید (Visibility) – چه خبر است؟
بهعنوان یک مهندس، هیچ چیز بیشتر از اینکه نتوانم یک مشکل فنی را حل کنم مرا ناامید نمیکند. تا حدی میتوان پایگاههای داده را جعبهسیاه دانست. بیشتر کاربران پایگاهداده آنها را فقط بهعنوان مکانی برای ذخیره و بازیابی داده استفاده میکنند. آنها لزوماً نگران این نیستند که همیشه چه اتفاقی میافتد. با این حال، وقتی چیزی دچار مشکل میشود، کاربران به ابزارهایی که ارائهدهنده برای عیبیابی فراهم کرده وابسته هستند.
ارائهدهندگان معمولاً پایگاههای داده را روی نوعی مجازیسازی اجرا میکنند و گاهی حتی توسط یک هماهنگکننده اداره میشوند. آنها لزوماً دسترسی کامل به سروری که پایگاهداده روی آن اجرا میشود ارائه نمیدهند. لایههای متعدد انتزاع وضعیت را سادهتر نمیکنند.
در حالی که ارائهدهندگان برای جلوگیری از آسیب زدن کاربران به سیستم، دسترسی کامل را ارائه نمیدهند، یک کاربر پیشرفته احتمالاً به سطح دسترسی بالاتری نیاز دارد تا بفهمد در لایههای مختلف چه اتفاقی میافتد و مشکل را برطرف کند. این عامل اصلیای است که بر انتخاب من برای میزبانی شخصی نرمافزار تأثیر میگذارد، با هدف داشتن حداکثر کنترل.
بحثهای زیادی درباره میزبانی شخصی در مقابل سرویسهای مدیریتشده وجود دارد. یکی از دیدگاهها در این بحث چنین گفته است:
«قطعاً چیزهایی برای در نظر گرفتن اینجا وجود دارد. اما من فکر میکنم بیشتر مردم مقدار کاری را که با میزبانی شخصی درگیر است بیش از حد برآورد میکنند. همچنین آنها تمایل دارند مقدار کاری را که هنگام استفاده از راهحلهای مدیریتشده لازم است، دستکم بگیرند. برای مثال، شما قطعاً باید پشتیبانهای ثانویه داشته باشید و بازگردانیها را حتی برای گزینههای مدیریتشده آزمایش کنید.»
من اثر جانبی دیگری نیز دیدهام: تیمها تمایل دارند پول بیشتری خرج کنند (بزرگتر کردن نمونهها) به این امید که برخی چالشها را حل کند، وقتی که نمیتوانند علت اصلی را شناسایی کنند. طبق گفته برخی متخصصان تنظیم پایگاهداده، حتی افزایش اندازه نمونه بدون تنظیم تخصصی تنظیمات، افزایش عملکرد متناسبی ایجاد نمیکند.
این چالش تقریباً حلنشدنی است، فارغ از سطح مهارت. برای مثال، یک متخصص سیستمهای توزیعشده هنگام آزمودن درستی یک نسخه از MySQL با مشکل تکرار داده مواجه شد و از ارائهدهنده درخواست پشتیبانی کرد.
یک روند رو به رشد شامل ارائهدهندگانی است که برای ارائه راهحلها به سایر ارائهدهندگان مدیریتشده وابستهاند. با این حال، ناامیدی زمانی رخ میدهد که ارائهدهنده پایهای انتظارات را برآورده نمیکند. نکته این است که زیاد کاری از دست کسی برنمیآید، حتی اگر هزینه زیادی پرداخت کند و توافق سطح خدمات داشته باشد.
مصالحهها (Tradeoffs)
چیزی که ممکن است در سراسر این مقاله متوجه شده باشید، موضوع دائمی بدهبستان است. هدف این مقاله بازداشتن کسی از استفاده از رایانش ابری یا سرویسهای مدیریتشده نیست. این مقاله عمدتاً برای آگاهسازی درباره هزینه درگیر، مرز باریک بین باز ماندن و قفلشدن، مجموعه ویژگی محدود، کمبود دید و نیاز به انجام عملیاتهای بعدی است.
اینها برخی از حوزههایی هستند که وقتی من برای اولین بار شروع به استفاده از سرویسهای پایگاهداده مدیریتشده کردم، برایم بدیهی نبودند. امیدوارم این موضوع به توسعهدهندگان و اپراتورها کمک کند تصمیمی آگاهانه بگیرند.
