۵ نکته برای ساخت اپلیکیشن های بومی ابری بسیار مقیاس پذیر

استفاده از انتزاعات برای یکسان سازی تجربه چند ابری

برای هر سرویسی که قصد دارد روی ابرهای متعدد کار کند، ارائه یک تجربه مشتری یکپارچه و ثابت در سراسر ابرها ضروری است، و دستیابی به آن به دلایل متعددی چالش برانگیز است. سرویس‌های ابری پیچیده هستند و حتی زمانی که استانداردها را رعایت می‌کنند، همچنان تغییراتی در ابرها و نمونه‌ها وجود دارد. انواع نمونه، در دسترس بودن نمونه، و حتی مدل صورت‌حساب برای سرویس‌های ابری مشابه می‌تواند به روش‌های ظریف اما تاثیرگذار متفاوت باشد. به عنوان مثال، ذخیره‌سازی بلوک Azure اجازه پیکربندی مستقل توان دیسک/IOPS را نمی‌دهد و بنابراین نیاز به تهیه یک دیسک بزرگ برای افزایش مقیاس IOPS دارد. در مقابل، AWS و GCP به شما این امکان را می دهند که این متغیرها را به طور مستقل تنظیم کنید.

بسیاری از ارائه دهندگان SaaS به این پیچیدگی توجه می کنند و مشتریان را در مورد جزئیات پیکربندی مورد نیاز برای دستیابی به عملکرد ثابت نگران می کند. واضح است که این ایده‌آل نیست، بنابراین ما برای کورا راه‌هایی برای حذف تفاوت‌ها ایجاد کردیم.

ما سه انتزاع را معرفی کردیم که به مشتریان اجازه می‌دهد از جزئیات پیاده‌سازی فاصله بگیرند و روی ویژگی‌های برنامه سطح بالاتر تمرکز کنند. این انتزاعات می تواند به ساده سازی چشمگیر خدمات و محدود کردن سؤالاتی که مشتریان باید خودشان به آنها پاسخ دهند کمک کند.

1. خوشه منطقی کافکا واحد کنترل دسترسی و امنیت است. این همان نهادی است که مشتریان آن را مدیریت می کنند، چه در یک محیط چند مستاجر یا اختصاصی.
2. واحدهای کافکا (CCU) واحدهای ظرفیت (و در نتیجه هزینه) برای مشتریان Confluent هستند. یک CKU بر حسب معیارهای قابل مشاهده مشتری مانند خروجی ورودی و خروجی، و برخی محدودیت‌های بالاتر برای نرخ درخواست، اتصالات و غیره بیان می‌شود.
3. در نهایت، بار روی یک خوشه را در یک متریک واحد به نام بار خوشه ای انتزاع می کنیم. این به مشتریان کمک می‌کند تصمیم بگیرند که آیا می‌خواهند خوشه خود را افزایش دهند یا کوچک کنند.

با وجود چنین انتزاعی‌هایی، مشتریان شما نیازی به نگرانی در مورد جزئیات پیاده‌سازی سطح پایین ندارند و شما به‌عنوان ارائه‌دهنده خدمات می‌توانید با در دسترس قرار گرفتن گزینه‌های سخت‌افزار و نرم‌افزار جدید، عملکرد و هزینه را به طور مداوم بهینه کنید.< /p>

حلقه های کاهش خودکار برای مبارزه با تخریب

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

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

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

ما چندین حلقه بازخورد را پیاده‌سازی کردیم که عملکرد یک کارگزار را ردیابی می‌کند و در صورت نیاز اقداماتی را انجام می‌دهد. هنگامی که یک مشکل شناسایی می شود، با یک وضعیت سلامت کارگزار مشخص مشخص می شود، که هر کدام با استراتژی کاهش مربوطه خود درمان می شوند. سه مورد از این حلقه‌های بازخورد به مشکلات دیسک محلی، مشکلات اتصال خارجی و تخریب کارگزار می‌پردازند:

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

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

تعادل کردن سرویس های حالت دار برای عملکرد و کارایی

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

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

تعادل مجدد تکالیف باید با احتیاط انجام شود. تعادل مجدد بیش از حد تهاجمی می تواند عملکرد را مختل کند و هزینه را به دلیل کار اضافی ایجاد کند. تعادل بیش از حد آهسته می تواند به سیستم اجازه دهد تا قبل از رفع عدم تعادل به میزان قابل توجهی تخریب شود. ما مجبور شدیم اکتشافی های زیادی را آزمایش کنیم تا در سطح مناسبی از واکنش پذیری همگرا شویم که برای طیف متنوعی از بارهای کاری کار می کند.

تأثیر تعادل مؤثر می تواند قابل توجه باشد. یکی از مشتریان ما زمانی که تعادل مجدد برای آنها فعال شد، تقریباً ۲۵٪ کاهش در بار خود مشاهده کرد. به طور مشابه، یکی دیگر از مشتریان کاهش قابل توجهی در تاخیر به دلیل تعادل مجدد مشاهده کرد.

مزایای یک سرویس بومی ابری با طراحی خوب

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

برای آزمایش عملکرد کورا، یک مقیاس کوچک انجام دادیم آزمایش روی سخت افزار یکسانی که کورا و پلتفرم ابری کامل ما را با کافکا منبع باز مقایسه می کند. ما متوجه شدیم که کورا با پوسته‌گذاری ۳۰ برابر سریع‌تر، خاصیت ارتجاعی بیشتری ارائه می‌کند. بیش از ۱۰ برابر در دسترس بودن بیشتر در مقایسه با میزان خطای مشتریان خود مدیریت یا سایر خدمات ابری. و تأخیر قابل توجهی کمتر از کافکای خودگردان. در حالی که کافکا هنوز بهترین گزینه برای اجرای یک سیستم جریان داده منبع باز است، Kora یک انتخاب عالی برای کسانی است که به دنبال یک تجربه بومی ابری هستند.

ما فوق‌العاده به کاری که برای کورا انجام شد و نتایجی که به دست آورده‌ایم افتخار می‌کنیم. سیستم‌های Cloud-Native می‌توانند برای ساخت و مدیریت بسیار پیچیده باشند، اما آنها طیف وسیعی از برنامه‌های کاربردی مدرن SaaS را فعال کرده‌اند که بخش عمده‌ای از تجارت امروزی را تامین می‌کنند. امیدواریم پروژه‌های زیرساخت ابری شما به این مسیر موفقیت ادامه دهند.

پرنس ماهاجان مهندس اصلی در Confluent است.

—

انجمن فناوری جدید مکانی را برای رهبران فناوری – از جمله فروشندگان و سایر مشارکت‌کنندگان خارجی – فراهم می‌کند تا فناوری سازمانی نوظهور را در عمق و وسعت بی‌سابقه بررسی و بحث کنند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه پرس و جوها را به doug_dineley@foundryco.com.