۲۹ شهریور ۱۴۰۳

Techboy

اخبار و اطلاعات روز تکنولوژی

کورا: طراحی مجدد ابری موتور آپاچی کافکا

پنج نوآوری کلیدی که عملکرد، در دسترس بودن و کارایی موتور را در مرکز سرویس آپاچی کافکا مدیریت شده Confluent افزایش داد.

پنج نوآوری کلیدی که عملکرد، در دسترس بودن و کارایی موتور را در مرکز سرویس آپاچی کافکا مدیریت شده Confluent افزایش داد.

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

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

ملاحظات کلیدی برای طراحی مجدد موتور کافکا

هدف‌های سطح بالای ما احتمالاً مشابه اهدافی بودند که برای سیستم‌های مبتنی بر ابر خود خواهید داشت: بهبود عملکرد و کشش، افزایش کارایی هزینه هم برای خود و هم برای مشتریانمان، و ارائه یک تجربه ثابت در چندین ابر عمومی . ما همچنین شرایط اضافی سازگار ماندن ۱۰۰٪ با نسخه های فعلی پروتکل کافکا را داشتیم.

موتور کافکا بازطراحی شده ما به نام کورا ، یک پلتفرم جریان‌سازی رویداد است که ده‌ها هزار کلاستر را در بیش از ۷۰ منطقه در سراسر AWS، Google Cloud، و Azure اجرا می‌کند. ممکن است فوراً در این مقیاس عمل نکنید، اما بسیاری از تکنیک های شرح داده شده در زیر همچنان قابل اجرا خواهند بود.

در اینجا پنج نوآوری کلیدی وجود دارد که در طراحی جدید Kora خود پیاده‌سازی کرده‌ایم. اگر می‌خواهید در مورد هر یک از این موارد عمیق‌تر شوید، ما یک کاغذ سفید< منتشر کردیم. /a> در مورد موضوعی که برنده بهترین مقاله صنعت در کنفرانس بین المللی پایگاه های داده بسیار بزرگ شد. (VLDB) 2023.

استفاده از سلول‌های منطقی برای مقیاس‌پذیری و جداسازی

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

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

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

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

داده های من پروژه ابری من را کشت!

برای سنجش اثربخشی این راه‌حل، ما یک خوشه ۲۴ کارگزار تجربی با شش سلول کارگزار راه‌اندازی کردیم (جزئیات کامل پیکربندی را در کاغذ سفید). وقتی معیار را اجرا کردیم، بار خوشه‌ای—یک معیار سفارشی که برای اندازه‌گیری بار در خوشه کافکا ابداع کردیم، با سلول‌ها ۵۳ درصد بود، در مقایسه با ۷۳ درصد بدون سلول.

تعادل انواع ذخیره سازی برای بهینه سازی داده های گرم و سرد

یک مزیت کلیدی ابر این است که انواع مختلفی از ذخیره سازی را با ویژگی های هزینه و عملکرد متفاوت ارائه می دهد. ما از این انواع مختلف ذخیره‌سازی برای ارائه بهینه‌ترین مبادلات با عملکرد هزینه در معماری خود استفاده می‌کنیم.

ذخیره‌سازی بلوک هم دوام و هم انعطاف‌پذیری را برای کنترل ابعاد مختلف عملکرد، مانند IOPS (عملیات ورودی/خروجی در هر ثانیه) و تأخیر فراهم می‌کند. با این حال، دیسک‌های با تأخیر کم با افزایش اندازه گران می‌شوند و آنها را برای داده‌های سرد مناسب نمی‌سازد. در مقابل، سرویس‌های ذخیره‌سازی اشیا مانند Amazon S3، Microsoft Azure Blob Storage و Google GCS هزینه پایینی دارند و بسیار مقیاس‌پذیر هستند، اما تأخیر بالاتری نسبت به ذخیره‌سازی بلوک دارند. همچنین اگر بخواهید تعداد زیادی رایتینگ کوچک انجام دهید، به سرعت گران می شوند.

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

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

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

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

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

چگونه با میکروسرویس های رویداد محور شروع کنیم

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

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

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

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

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

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

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

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

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

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

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

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

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

داخل AWS جدید

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

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

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

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

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

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

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

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

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