مقدمه

تیم پلتفرم جریان داده در زمان واقعی Coban، اکوسیستمی را پیرامون Kafka در حوزه های عمودی خدمات مشتری شرکت Grab ایجاد کرده است. به همراه پایداری و عملکرد، یکی از اولویت های ما همچنین کارایی هزینه است.

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

بیانیه مسئله

پلتفرم مجله زیبایی و درمانی آذروت در حد اصلی بر روی ابر AWS میزبانی می شود و در یک منطقه قرار دارد که سه منطقه قابلیت اطمینان (AZ) را در بر می گیرد. زمانی که به جریان داده می رسد، هر دو کارگزار Kafka و مشتریان Kafka در این سه AZ اجرا می شوند.

شکل 1 نشان می دهد که طراحی اولیه پلتفرم جریان داده ما چگونه است. برای اطمینان از در دسترس بودن بالا و انعطاف پذیری، هر بخش Kafka را برای داشتن سه نسخه یکسان تنظیم کرده ایم. همچنین کلاسترهای Kafka خود را رک-آگاه (یعنی 1 رک = 1 AZ) تنظیم کرده ایم تا سه نسخه در سه AZ متفاوت قرار داشته باشند.

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

این یک نگرانی است زیرا ما برای ترافیک تقاطع AZ براساس مدل قیمت گذاری ترافیک شبکه AWS هزینه می پردازیم. با این طرح، ترافیک تقاطع AZ ما نصف هزینه کل پلتفرم Kafka ما را تشکیل می داد.

ترافیک تقاطع AZ Kafka برای این طراحی را می توان به سه بخش تقسیم کرد که در شکل 1 نشان داده شده است:

تولید (مرحله 1): به طور معمول، یک سرویس تکی داده ها را به یک موضوع Kafka داده می کند. ترافیک تقاطع AZ رخ می دهد زمانی که تولید کننده در همان AZ با رهبری بخش که داده ها را تولید می کند مستقر نیست. هزینه ترافیک تقاطع AZ بسیار کم است زیرا داده ها حداکثر یک بار (بدون سعی مجدد) به AZ دیگر منتقل می شوند.تکثیر (مرحله 2): داده های دریافت شده از رهبری بخش به دو پیروند بخش که در دو AZ دیگر مستقر هستند تکثیر می شوند. هزینه این کار نسبتاً کم است زیرا داده ها فقط دو بار به AZ دیگر منتقل می شوند.مصرف (مرحله 3): بیشتر ترافیک تقاطع AZ در اینجا رخ می دهد زیرا برای یک موضوع Kafka تعداد زیادی مصرف کننده وجود دارد. مشابه تولید کنندگان، مصرف کنندگان هزینه ترافیک تقاطع AZ را پرداخت می کنند زمانی که در همان AZ با رهبری بخش مستقر نیستند. با این حال، در سمت مصرف کننده، ترافیک تقاطع AZ ممکن است به تعداد مصرف کنندگان وقوع کند (میانگیناً دو سوم تعداد مصرف کننده ها). راه حلی که در این مقاله توضیح داده شده است، به این جزئیات خاص ترافیک تقاطع AZ در طراحی اولیه پاسخ می دهد.

راه حل

Kafka 2.3 امکان مصرف کنندگان برای بازیافت از نسخه های بخش را معرفی کرده است. این امکان راهی را برای طراحی هزینه مؤثرتر باز می کند.

مرحله 3 شکل 2 نشان می دهد که مصرف کنندگان اکنون می توانند داده ها را از نسخه نزدیک خود مصرف کنند. برای پیاده سازی این ویژگی، نیاز به آگاهی از رک (1 رک = 1 AZ) و پیکربندی های اضافی در کارگزارها و مصرف کنندگان Kafka است. در بخش های زیر این موضوع را توضیح خواهیم داد.

سفر Coban

ارتقای Kafka

سفر ما با ارتقای کلاسترهای قدیمی Kafka آغاز شد. ما تصمیم گرفتیم آنها را به طور مستقیم به نسخه 3.1 ارتقا دهیم ، بهره بردن از رفع اشکالات و بهینه سازی ها نسبت به نسخه 2.3. این حرکت ایمن به عنوان یک حرکت است، زیرا نسخه 3.1 به مدت تقریباً یک سال پایدار تلقی می شد و ما هزینه عملیاتی اضافی برای این ارتقا را پیش بینی نکردیم.

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

مرحله 1: ارتقای Zookeeper. تمام نسخه های Kafka توسط جامعه با یک نسخه خاص از Zookeeper تست می شوند. برای اطمینان از پایداری، ما همین فرآیند را دنبال کردیم. Zookeeper ارتقا یافته به طور سازگاری به عقب با نسخه قبلی Kafka که هنوز در این مرحله از عملیات استفاده می شود.مرحله 2: راه اندازی ارتقای Kafka به نسخه 3.1 با یک نسخه پروتکل بین کارگزارها واضح و سازگار بازگشت (inter.broker.protocol.version). در طول این ارتقا تدریجی، کلاستر Kafka به طور موقت از کارگزارهای با نسخه های متفاوت Kafka تشکیل شده است ، اما می توانند با یکدیگر ارتباط برقرار کنند زیرا به طور صریح تنظیم شده اند تا از همان نسخه پروتکل بین کارگزارها استفاده کنند. در این مرحله، ما همچنین Cruise Control را به یک نسخه سازگار ارتقا دادیم و Kafka را تنظیم کردیم تا پرونده updatedcruise-control-metrics-reporterJAR را در زمان راه اندازی وارد کند.مرحله 3: ارتقای نسخه پروتکل بین کارگزارها. این آخرین مرحله باعث می شود تا تمام کارگزارها از جدیدترین نسخه پروتکل بین کارگزارها استفاده کنند. در طول ارتقای تدریجی این تغییر، کارگزارهای با نسخه پروتکل جدید همچنان می توانند با کارگزارهای با نسخه پروتکل قدیمی ارتباط برقرار کنند.

پیکربندی

فعال کردن توانایی مصرف کنندگان Kafka برای بازیافت از نسخه نزدیکتر نیازمند تغییرات پیکربندی در هر دو کارگزاره ها و مصرف کنندگان Kafka است. همچنین آنها باید از AZ خود آگاه شوند که با استفاده از رک-آگاهی Kafka امکان پذیر است (1 رک = 1 AZ).

کارگزاران

در پیکربندی کارگزارهای Kafka ما ، ما قبلاًbroker.rackرا برای توزیع نسخه های در AZ های مختلف برای ایجاد انعطاف پذیری تعیین کرده بودیم. نقشه کاری Ansible ما برای Kafka به طور خودکار آن را با شناسه AZ که در زمان استقرار از منابع متادیتای نمونه EC2 به طور پویا دریافت می شود ، تنظیم می کند.

- نام: دریافت شناسه منطقه در دسترسی
  uri:
    url: http://169.254.169.254/latest/meta-data/placement/availability-zone-id
    method: GET
    return_content: yes
  register: ec2_instance_az_id

توجه کنید که ما از شناسه AZ های AWS (به شکل az1 ، az2 ، az3) به جای نام های معمول AZ های AWS (به شکل 1a ، 1b ، 1c) استفاده می کنیم زیرا نگاشت آنها در سراسر حساب های AWS یکپارچه نیست.

علاوه بر این، پارامتر جدید replica.selector.classرا با مقدارorg.apache.kafka.common.replica.RackAwareReplicaSelectorبر روی سمت سرور فعال کرده ایم تا این ویژگی جدید فعال شود.

مصرف کنندگان

در سمت مصرف کننده Kafka، اصولاً بر روی کتابخانه داخلی Golang شرکت Coban برای Kafka که نحوه استفاده تیم های سرویس در تمام عمودهای مجله زیبایی و درمانی آذروت را تسهیل می کند، تکیه می کنیم. ما SDK را برای پشتیبانی از بازیابی از نزدیکترین نسخه به روز کرده ایم.

کاربران ما فقط باید یک متغیر محیطی را برای فعال سازی این ویژگی جدید صادر کنند. سپس SDK بر روی آن اطلاعات رک میزبان مربوطه را به طور پویا از متادیتای میزبان در هنگام راه اندازی بازیابی و تنظیم می کند. بسته به زمان استقرار کارگزارهای Kafka همین کار را انجام می دهند.

همچنین ما همین منطق را برای مصرف کنندگان غیر-SDK خود، به ویژه Flinkpipelines و Kafka Connectconnectors پیاده سازی کرده ایم.

تأثیر

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

شکل 3 نشان می دهد که تأثیر نسبی این تغییر بر روی ترافیک تقاطع AZ ما است، همانطور که توسط AWS Cost Explorer گزارش شده است. AWS هزینه ترافیک تقاطع AZ را در هر دو سر انتقال داده ها تحمل می کند، بنابراین دو سری داده ها وجود دارد. در سمت کارگزارهای Kafka، ترافیک تقاطع AZ کمتری وجود دارد