مقدمه

تیم پلتفرم جریان داده در زمان واقعی 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 کمتری وجود دارد

زمینه

Market-Store یک feature store عمومی است که برای سرویس دادن به ویژگی‌های محاسبه شده در زمان واقعی برای یادگیری ماشین استفاده می‌شود. Market-Store SLA دقیقی درباره تاخیر، ظرفیت و قابلیت دسترسی دارد زیرا مدل‌های یادگیری ماشینی را تقویت می‌کند که در قیمت‌گذاری پویا و تجربه مصرف کننده استفاده می‌شوند.

مشکل

همانطور که مجله زیبایی و درمانی آذروت ادامه می‌یابد و مدل‌های یادگیری ماشینی جدیدی را معرفی و ترافیک افزایش می‌دهد، Market-Store تاخیر بالایی را تجربه کرد. SLA Market-Store بیان می‌کند که ۹۹٪ تراکنش‌ها باید در ۲۰۰ میلی‌ثانیه باشند، اما تاخیر ما به ۲ ثانیه افزایش یافت. این امر بر روی دسترسی و دقت مدل‌های ما که برای ویژگی‌های زمان واقعی از Market-Store استفاده می‌کنند، تأثیر گذاشت.

مشکل تاخیر

ما از معیارها و لاگ‌های مختلف برای رفع مشکل تاخیر استفاده کردیم، اما توانستیم هیچ ناهنجاری را که به طور مستقیم با عملکرد API مرتبط باشد، پیدا نکنیم. ما کشف کردیم که مشکل به طور موقت از بین می‌رود زمانی که سرویس را مجدداً راه‌اندازی می‌کنیم. اما در دوره قله بعدی، سرویس دوباره شروع به مشکل می‌شود و مشکل با افزایش نسبیتاً بیشتر پذیرفته می‌شود زمانی که نرخ درخواست در ثانیه برای Market-Store افزایش می‌یابد.

نمودار زیر نشان دهنده افزایش استفاده از حافظه در طول زمان در ۱۲ ساعت است. حتی با کاهش بار سیستم، مصرف حافظه همچنان ادامه داشت.

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

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

اشکال زدایی با استفاده از ابزارهای Go

PPROF یک ابزار پروفایل سازی است که توسط Golang استفاده می‌شود تا پروفایل‌ها را از برنامه‌های Go نشان دهد و تجزیه و تحلیل کند. یک پروفایل مجموعه‌ای از ردیابی‌های استک است که دنباله تماس‌ها را در برنامه شما نشان می‌دهد که در نهایت منجر به رویدادهای خاصی مانند تخصیص می‌شود. همچنین جزئیاتی مانند اطلاعات هیپ و CPU را فراهم می‌کند که می‌توانند بینش‌هایی درباره موانع برنامه Go ارایه دهند.

بطور پیش‌فرض، PPROF در تمام سرویس‌های Go مجله زیبایی و درمانی آذروت فعال است، بنابراین این ابزار مناسب برای استفاده در سناریو ما است. برای درک این که چگونه حافظه تخصیص داده می‌شود، از PPROF برای تولید پروفایل Heap Market-Store استفاده کردیم که می‌تواند برای درک اینکه چگونه حافظه inuse برنامه تخصیص یافته استفاده شود.

شما می‌توانید با اجرای این دستور، پروفایل Heap را جمع آوری کنید:

go tool pprof 'http://localhost:6060/debug/pprof/heap'

سپس این دستور اطلاعات پروفایل Heap را مانند نمودار زیر نشان می‌دهد:

از این نمودار متوجه شدیم که بعد از انجام وظایف ، حافظه زیادی توسط context فرزند از کتابخانه Async نگهداری شده است.

در Market-Store ما از Async Library، یک کتابخانه متن باز مجله زیبایی و درمانی آذروت، استفاده می‌کنیم که به طور معمول برای اجرای وظایف همزمان استفاده می‌شود. هر context ایجاد شده توسط Async Library باید پس از اتمام وظایف زمینه تمیز شود. به این ترتیب، حافظه به سرویس برگشت داده خواهد شد.

هرچند، همانطور که در نمودار مشاهده می‌شود، حافظه بازگشت داده نشده است، که منجر به نشت حافظه می‌شود و به تبع آن استفاده از حافظه افزایش می‌یابد حتی در صورت کاهش بار سیستم Market-Store.

شناسایی واقعیت مشکل

بنابراین ما می‌دانستیم که تاخیر Market-Store تحت تأثیر قرار گرفته است، اما نمی‌دانستیم چرا. از گراف اول، می‌بینیم که مصرف حافظه حتی با کاهش بار سیستم Market-Store ادامه دارد. سپس، PPROF به ما نشان می‌دهد که حافظه نگهداری شده توسط context ها پاک نمی‌شود، که منجر به نشت حافظه می‌شود.

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

با این حال، هیچ تغییری در سرویس ما اتفاق نیفتاده بود که باعث تأثیری بر روی نحوه ایجاد و تمیز شدن context ها شود. پس چه علتی باعث نشت حافظه شد؟

اشکال زدایی نشت حافظه

باید مطالعه‌ای درباره کتابخانه Async و نحوه عملکرد آن انجام می‌دادیم. برای Market-Store، ما کش را به صورت همزمان برای مکانیزم نوشتن کشینگ write-around به‌روز می‌کنیم. ما از کتابخانه Async برای اجرای وظایف به طور پس‌زمینه استفاده می‌کنیم.

قطعه کد زیر راهکار کارکرد کتابخانه Async را توضیح می‌دهد:

async.Consume(context.Background(),runtime.NumCPU()*4,buffer)// Consume runs the tasks with a specific max concurrencyfuncConsume(ctxcontext.Context,concurrencyint,taskschanTask)Task{// code...returnInvoke(ctx,func(context.Context)(interface{},error){workers:=make(chanint,concurrency)concurrentTasks:=make([]Task,concurrency)// code ...t.Run(ctx).ContinueWith(ctx,func(interface{},error)(interface{},error){// code...})}}funcInvoke(ctxcontext.Context,actionWork)Task{returnNewTask(action).Run(ctx)}func(t*task)Run(ctxcontext.Context)Task{ctx,t.cancel=context.WithCancel(ctx)got.run(ctx)returnt}

ملاحظه: کدی که در این مقاله مربوط نمی‌شود با کد جایگزین شده است.

همانطور که در قطعه کد بالا مشاهده می‌شود، کتابخانه Async متد Consumero بگونه‌ای مقداردهی اولیه کرده است تا یک context زمینه را ایجاد کند و سپس آن را به تمام اجراکننده‌هایی که دارد، منتقل می‌کند. context های زمینه خالی هستند و شناسه یا ارتباطی با context های زیرین که از آن ایجاد شده‌اند ندارند.

در Market-Store، ما از context های زمینه استفاده می‌کنیم زیرا آنها به زنجیره context ثابت نیستند و حتی بعد از تمیز شدن یک context درخواست ادامه خواهد یافت. این بدین معناست که پس از اتمام وظیفه مصرفی، حافظه مصرف شده توسط context فرزند آزاد شده و جلوگیری از بروز نشت حافظه به طور کامل.

شناسایی علت نشت حافظه

با تحقیقات بیشتر، یک MR که در کتابخانه اعمال شده بود وجود داشت که مشکل لغو وظیفه را حل می‌کند. همانطور که در قطعه کد زیر نشان داده می‌شود، متد Consume تغییر داده شده بود به گونه‌ای که context وظیفه به اجراکننده‌ها منتقل می‌شد، به جای context های خالی زمینه.

funcConsume(ctxcontext.Context,concurrencyint,taskschanTask)Task{// code...returnInvoke(ctx,func(taskCtxcontext.Context)(interface{},error){workers:=make(chanint,concurrency)concurrentTasks:=make([]Task,concurrency)// code ...t.Run(taskCtx).ContinueWith(ctx,func(interface{},error)(interface{},error){// code...})}}

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

اهمیت لغو کردن context

وقتی یک context لغو می‌شود، همه context هایی که از آن ایجاد شده‌اند نیز لغو می‌شوند. این بدین معناست که هیچ context یا ارتباط ناشناسی وجود ندارد و می‌تواند توسط ابزار CancelFunc کتابخانه Async به دست آید.

متد CancelFunc کتابخانه Async:

لغو context فرزند ایجاد شده را و لغو وظیفه های زمینه آن حذف می‌کندحذف ارجاع والدین از context فرزندتوقف هر تایمر مرتبط

همیشه باید مطمئن شویم که پس از استفاده از context ها، متد CancelFunc را فراخوانی کنیم تا اطمینان حاصل کنیم که context ها و حافظه نشت نمی‌شوند.

توضیح تأثیر MR

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

همانطوری که با استفاده از context های وظیفه به جای context های زمینه شروع کردیم و آنها را لغو نکردیم، حافظه مصرف شده توسط این context ها هرگز بازگشت داده نشد و در نتیجه نشت حافظه ایجاد شد.

تلاش‌های ما برای اشکال زدایی و بررسی علت اصلی مشکل تاخیر بالای Market-Store زمان بربر و از این رو در این حادثه چندین مورد مهم یاد گرفتیم که به جلوگیری از نشت حافظه در آینده کمک می‌کند.

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