3 مهر 1402
تهران، خیابان آزادی، تقاطع قریب
برنامه نویسی وب

انتقال به کافکا چندخوشه‌ای مدیریت شده بدون زمان توقف

انتقال به کافکای چندخوشه‌ای مدیریت شده بدون زمان توقف

در سال 2021، تیم من با روشی یکپارچه، بر روی انتقال 2000 مایکروسرویس Wix از خوشه‌های کافکای خود-میزبان به یک پلتفرم ابری مدیریت شده‌ی چند خوشه‌ای (Confluent Cloud) کار کرد که نیازی به دخالت صاحبان این سرویس‌ها نداشت. این انتقال طی یک ترافیک معمولی و بدون هیچ گونه توقفی انجام شد.

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

تقسیم خوشه‌های سربارگذاری شده

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

مقیاس خوشه (Cluster)‌ خود-میزبان ما از 5هزار تاپیک با کمتر از 45هزار پارتیشن در سال 2019، به 20هزار تاپیک با بیش از 200هزار پارتیشن افزایش یافته است.

همچنین ترافیک ما در هر خوشه، از 450 میلیون رکورد تولید شده در روز به بیش از 2.5 میلیارد رکورد تولید شده در روز افزایش یافته است.

تقسیم خوشه ها

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

برای جلوگیری از این بی‌ثباتی در خوشه‌های کافکا در تولید، ما تصمیم گرفتیم خوشه‌های کافکای خود-میزبان خود را به Confluent Cloud منتقل کنیم و تک‌ خوشه‌ی در مرکز داده را به چند خوشه تقسیم کنیم.

چرا کافکای مدیریت شده؟

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

در بخش زیر 4 مزیت استفاده از پلتفرم ابری مدیریت شده کافکا، و به طور اخص  Confluent Cloud آورده شده است:

انعطاف پذیری و عملکرد بهتر خوشه

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

ارتقاء نسخه شفاف (Transparent)

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

افزودن آسانِ یک خوشه جدید

در صورت نیاز به یک خوشه جدید، راه اندازی آن بسیار ساده است.

ذخیره سازی لایه‌ای

Confluent Platform یک فضای ذخیره‌سازی لایه‌ای ارائه می‌کند. این فضا به شما این امکان را می‌دهد تا با انتقال رکوردهای قدیمی‌تر به فضای ذخیره‌سازی بسیار ارزان‌تر S3، بدون افزودن تأخیر به آخرین مصرف رکوردهای offest، مدت زمان نگهداری از رکوردهای کافکا را بدون پرداخت هزینه‌های آن‌چنانی برای هارد دیسک‌های گران، به‌طور چشمگیری افزایش دهید.

تغییر 2000 مایکروسرویس به معماری چند خوشه‌ای کافکا

در Wix ما یک کتابخانه استاندارد JVM و یک سرویس پروکسی به نام Greyhound داریم که برای تعامل با کافکا مورد استفاده قرار می‌گیرد. این یک SDK منبع باز سطح بالا برای آپاچی کافکا است که برخی ویژگی‌های اضافی مانند پردازش پیام همزمان، پردازش دسته‌ای، تلاش مجدد و غیره را ارائه می‌دهد.

تغییر مایکروسرویس ها به معماری کافکا

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

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

تعریف نام منطقی خوشه کافکا

چگونه تقسیم بندی کنیم

ما تصمیم گرفتیم که خوشه های کافکا را بر اساس SLA های مختلف تقسیم بندی کنیم. به عنوان مثال، خطوط لوله CI/CD و موارد استفاده انتقال داده دارای SLA متفاوتی نسبت به خدمات تولیدی هستند. به این نکته توجه کنید: همه مراکز داده دارای تعداد یکسانی از خوشه های کافکا نیستند، زیرا هر مرکز داده هدف متفاوتی دارد.

Greyhound (Kafka SDK تحت مالکیت Wix) می‌داند که چگونه به این مشکل رسیدگی کند و در صورتی که یک خوشه‌ در مرکز داده‌ای که نمونه سرویس در آن در حال اجرا است در دسترس نباشد، از خراب شدن آن جلوگیری کند.

خوشه کافکا

مرکز داده تخلیه شده از ترافیک انتقال پیدا می‌کند؟

دیزاین اولیه ابتدا به تخلیه کامل هر مرکز داده (DC) از ترافیک متکی بود. چرا که انتقال تولیدکنندگان و مصرف‌کنندگانِ دو هزار مایکروسرویس به خوشه‌های مدیریت‌شده کافکا آسان‌تر می‌شد.

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

با وجودی که این طرح ساده بود، متاسفانه امکان پیاده‌سازی و اجرای آن وجود نداشت.

این موضوع چند دلیل داشت:

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

در عوض، یک طرح جدید شامل انتقال در طول ترافیک زنده برنامه ریزی شد.

انتقال با ترافیک

انجام انتقال در طول ترافیک زنده به این معنی بود که یک برنامه‌ریزی دقیق برای اجرا ضروری است.

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

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

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

همانندسازی

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

همانندسازی در کافکا

انتقال مصرف‌کننده

به منظور آسان سازی انتقال مصرف‌کننده، Replicator نقشه‌برداری Offset را برای هر پارتیشن ادامه داد. به طوری که مصرف کننده Greyhound می‌تواند پردازش سوابق در خوشه ابری را از Offset صحیحی شروع کند که از اولین Offset غیرمتعهد در خوشه خود-میزبان نقشه برداری شده بود.

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

انتقال مصرف کننده

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

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

انتقال تولید کننده

هنگامی که همه مصرف کنندگان یک تاپیک خاص منتقل شدند، انتقال تولید کننده آن نیز ممکن شد.

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

بعداً به دیزاین ساده‌تری رسیدیم که بر فرآیند استقرار تدریجی Kubernetes Wix تکیه داشت. هر پاد (غلاف) جدید تنها زمانی شروع به پذیرش درخواست‌های دریافتی می‌کند که تمام بررسی‌های امنیتی آن، از جمله اتصال به کافکا، درست باشد. از آنجایی که این فرآیند تدریجی است، همیشه پادهای «قدیمی‌تری» وجود دارند که به‌گونه‌ای در حال اجرا هستند که سرویس دائماً برای درخواست‌های دریافتی در دسترس باشد.

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

گلوگاه تکرار

توقف تکرار موضوع تنها زمانی قابل قبول بود که تولیدکننده منتقل می‌شد. اما برای انتقال یک تولید کننده، ابتدا باید تمام مصرف‌کنندگان تاپیک آن منتقل می‌شدند.

مشخص شد که بسیاری از موضوعات دارای چندین مصرف کننده از سرویس های مختلف هستند، که به این معنی است که مصرف کننده Replicator ترافیک بیشتری برای پردازش و تکرار دارد.

نسخه نسبتاً قدیمی رابط‌های کافکا که خود-میزبان بودند، دارای محدودیت‌های فنی متعددی بودند. این مسئله باعث شد که برای تعداد تاپیک‌هایی که مصرف‌کننده می‌توانست ایجاد کند، محدودیت ایجاد شود. پس از تلاش‌های متعدد برای افزایش message.max.bytes، نتیجه معکوسی به دست آمد. (به باگ KAFKA-9254 مراجعه کنید) و یک مشکل جدی ایجاد شد. در نتیجه ما تصمیم گرفتیم مصرف کنندگان Replicator بیشتری را اضافه کنیم و موضوعات را برای تکرار در میان آنها تقسیم کنیم.

گلوگاه تکرار

پشت صحنه انتقال – کنترل مصرف کننده خارجی

این دیزاین انتقال «دارای ترافیک» امکانات جدید زیادی را برای تغییر داینامیک پیکربندی یا وضعیت مصرف کنندگان Greyhound بدون نیاز به GA برای تولید نسخه جدید باز کرد.

همانطور که در حال حاضر ما زیرساختی را برای مصرف کنندگان Greyhound و به منظور گوش دادن به دستورات دریافتی برای تغییر وضعیت یا پیکربندی در اختیار داریم، چنین دستوراتی می تواند شامل موارد زیر باشد:

  • تغییر خوشه: لغو اشتراک از خوشه فعلی و مشترک شدن در خوشه دیگر.
  • اسکیپ کردن رکوردها: اسکیپ کردن رکوردهایی که قابل پردازش نیستند.
  • تغییر ریت پردازش: افزایش یا کاهش داینامیک مقدار پردازش موازی یا اضافه کردن تأخیر برای فشار و فشار برگشتی
  • توزیع مجدد رکوردها: توان توزیع رکوردها بین همه پارتیشن‌ها در صورت وجود تأخیر در حال افزایش (و صرف نظر از پارتیشن‌های قدیمی)

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

بهترین روش‌ها و نکات انتقال موفق

در لیست زیر می‌توانید بهترین شیوه‌ها و نکاتِ انتقال موفق خوشه های کافکا را مطالعه کنید:

یک اسکریپت ایجاد کنید که به خودی خود حالت را بررسی کند و در صورت نرسیدن به حالت مورد انتظار، متوقف شود

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

یک بازگشت آماده در دسترس خود داشته باشید

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

با تاپیک‌های test/relay و بدون تایپک‌های impact شروع کنید

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

داشبوردهایی با متریک‌هایی سفارشی ایجاد کنید که هم وضعیت فعلی و هم وضعیت در حال تغییر را نشان بدهند

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

در نمودار زیر می‌توانیم ببینیم که چگونه یک تولیدکننده با موفقیت از خوشه میزبان خود به خوشه مدیریت شده منتقل می‌شود. (با راه‌اندازی مجدد و خواندن پیکربندی جدید پادهای بیشتری کاهش می‌یابند.)

مطمئن شوید که در آخرین نسخه پچ شده خود-میزبان رابط کافکا هستید

از آنجایی که کارگزاران کافکای خود-میزبان ما در آخرین نسخه پچ قرار نداشتند، هنگامی که سعی کردیم ارزش message.max.bytes را چندین بار افزایش دهیم، با یک حادثه تولید مواجه شدیم. توصیه من این است که ابتدا ورژن خود-میزبان خوشه کافکایتان را ارتقاء دهید. اگر هم به آخرین نسخه آپدیت نمی‌کنید، حداقل به آخرین پچ آپدیت کنید.

آخرین پچ کافکا

خلاصه

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

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

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

فلوچارت زیر درک گزینه‌های مختلف را برای شما آسان می کند:

فلوچارت انتقال با کافکا

توسعه دهنده زیرساخت بک‌اند در wix.com

نویسنده: ناتان سیلنیتسکی

منبع: مدیوم

Leave feedback about this

  • کیفیت
  • قیمت
  • خدمات

PROS

+
Add Field

CONS

+
Add Field
Choose Image
Choose Video
X