نویسنده (ها): آندری نویتسکی
در ابتدا منتشر شده در به سمت هوش مصنوعیبشر
TL ؛ دکتر در زمان واقعی یادگیری ماشین سیستم ها نه تنها به مدل های کارآمد بلکه زیرساخت های قوی قادر به ارائه ویژگی کم تأخیر در شرایط بار پویا هستند.
در این پست ، ما معیار است ولگا لایه محاسباتی در صورت تقاضا -یک مؤلفه اصلی طراحی شده برای محاسبه ویژگی زمان درخواست-مستقر در Kubernetes (EKS) و با ارکستر شده اشعهبشر برای شبیه سازی الگوهای بار واقعی ، ما استفاده می کنیم ملخ به عنوان چارچوب تست بار ، و به عنوان لایه ذخیره سازی میانی بین جریان و اجزای سرویس دهی.
ما عملکرد سیستم را ارزیابی می کنیم ، ویژگی های تأخیر را تجزیه و تحلیل می کنیم و مقیاس پذیری افقی را در پروفایل های بار مختلف ارزیابی می کنیم ، با تمرکز بر اینکه چگونه گزینه های معماری بر استحکام و کارآیی تأثیر می گذارد.
مطالب:
- پیشینه
- تنظیمات تست
- نتایج و تجزیه و تحلیل
- پایان
پیشینه
ولگا یک سیستم پردازش داده است که برای AI مدرن ساخته شده است/مولکول خطوط لوله ، با تمرکز بر مهندسی ویژگی در زمان واقعی (بیشتر بخوانید در اینجا). در لایه محاسباتی در صورت تقاضا یکی از دو مؤلفه اصلی ولگا است (در کنار آن موتور جریان) ، مسئول محاسبه زمان درخواست-یعنی ، ویژگی خدمت و محاسبه ویژگی در صورت تقاضا.
در هسته آن ، لایه محاسبات در صورت تقاضا یک سرویس بدون تابعیت است که توسط بازیگران، با هر کارگر در حال اجرا سرور Starlette این منطق تعریف شده توسط کاربر را در داده های تولید شده توسط موتور جریان (یا داده های پیش ساخته) اجرا می کند. سیستم پایان به پایان در پشت یک متعادل کننده بار خارجی قرار دارد و از یک لایه ذخیره سازی قابل پلاگین به عنوان واسطه بین موتور جریان و کارگران در صورت تقاضا استفاده می کند.
هدف از این پست ارزیابی استحکام معماری تحت سناریوهای دنیای واقعی ، ارزیابی عملکرد لایه بر روی تقاضا تحت بار و نشان دادن مقیاس پذیری افقی سیستم است.
تنظیمات تست
ما با استفاده از خوشه آمازون EKS تست های بار را اجرا کردیم t2.Medium موارد (2 VCPU ، 4 گیگابایت رم) ، میزبان استقرار ملخ و خوشه ری که Volga را اجرا می کند. برای اطمینان از انزوا در منابع ، هر غلاف پرتوی به یک گره EKS منفرد نقشه برداری شد.
لایه تقاضا ولگا در پشت یک AWS Application Balancer، خدمت به عنوان هدف اصلی کارگران ملخ و درخواست های مسیریابی به گره های EKS که میزبان غلاف های Volga هستند (جایی که سیستم عامل سپس بار را بین کارگران در همان گره/غلاف توزیع می کند).
برای اینکه کد آن را تنظیم کند ، بررسی کنید وابسته به ولگا repo
اندازه منابع
از طریق آزمایش ، ما آن را تعیین کردیم:
- یک کارگر تقاضا می تواند رسیدگی کند حداکثر 1000 rpsبا فرض توابع تعریف شده توسط کاربر (UDF) عملیات مسدود کننده CPU را معرفی نمی کنند.
- یک کارگر ملخ می تواند تولید کند حداکثر 1000 rps بدون اضافه بار یک گره.
از آنجا که کارگران ولگا فرآیندهای سبک وزن پایتون هستند (تک رشته ای ، گیل محدود) ، ما فرض می کنیم 1 کارگر = 1 پردازنده نقشه برداری هنگام تخمین میزان مصرف منابع.
پیکربندی ذخیره سازی
ما انتخاب کردیم مجدداً به عنوان لایه ذخیره سازی بین موتور جریان و لایه بر روی تقاضا برای سادگی و عملکرد بالا.
اگرچه می توان Redis را با تکثیر کارشناسی ارشد تنظیم کرد ، اما به دلیل عدم ضمانت قوام قوی ، محیط های تولیدی باید سیستم های ذخیره سازی مانند SCYLLADB ، CASSANDRA یا DYNAMODB را برای دوام بهتر و قوام در نظر بگیرند.
در معیارهای ما:
- بوها غلاف redis بدون تکثیر یا ترازو ، اولویت بندی سادگی و جداسازی عملکرد محاسبات مستقر شد.
- موتور جریان بود معلول در طول آزمایشات ، با ذخیره سازی یک بار در زمان تنظیم. این رویکرد عملکرد خود Volga را جدا می کند اما می تواند در مقایسه با نویسندگان پویا در دنیای واقعی ، رفتار ذخیره سازی را تحت تأثیر قرار دهد.
ویژگی های محاسبه/خدمت
هر معیار یک خط لوله ویژگی ساده در زمان واقعی را شامل می شود که شامل:
test_feature: یک ویژگی خط لوله (جریان) ، از طریق داده های مسخره دوره ای می نویسد.simple_feature: یک ویژگی زمان درخواست بسته بهtest_feature، استفاده از یک تحول اساسی (ضرب)
# emulates streaming pipeline feature
@source(TestEntity)
def test_feature() -> Connector:
return MockOnlineConnector.with_periodic_items(
items=[...], # sample data
period_s=0
)# emulates simple linear transformation at request time (multiplication) based on data produced by 'test_feature'
@on_demand(dependencies=['test_feature'])
def simple_feature(
dep: TestEntity,
multiplier: float = 1.0
) -> TestEntity:
return TestEntity(
id=dep.id,
value=dep.value * multiplier,
timestamp=datetime.datetime.now()
)
نتایج و تجزیه و تحلیل
در طول هر تست بار ، ما اندازه گیری کردیم:
- کل RPS (تولید شده توسط ملخ و انجام شده توسط Volga)
- تأخیر داخلی در صورت تقاضا
- ذخیره سازی تاخیر بخوانید
- تأخیر درخواست پایان به پایان (از هر دو دیدگاه ولگا و ملخ)
ما همچنین استفاده از CPU کانتینر را از طریق کنترل کردیم بینش های کانتینر AWS برای تأیید حداکثر استفاده از گره.
هر آزمون دنبال کرد افزایش بار گام به گام، با افزایش RP ها به تدریج در هر 20 ثانیه در طی 3 دقیقه اجرا ، تا رسیدن به حداکثر پیکربندی شده. (مکانیسم فشار داخلی ملخ ، اگر تأخیر بیش از آستانه های قابل قبول باشد ، رشد RPS را متوقف می کند.)
تست MAX RPS
در بزرگترین پیکربندی (80 کارگر) ، ما به دست آوردیم:
- 30،000 rps توان اوج
- 50ms P95 تأخیر پایان به پایان
مقیاس پذیری
ما آزمایشات را با 4 ، 10 ، 20 ، 40 ، 60 و 80 کارگر، ردیابی RPS پایدار و معیارهای تأخیر مربوطه.
نتایج نشان داد:
- مقیاس بندی RPS خطی با تعداد کارگران
- تأخیرهای پردازش پایدار در مراحل مقیاس گذاری.
- عملکرد ذخیره سازی تنگنا اصلی برای تأخیر ، تأیید مجدد مقیاس پذیری داخلی و کارآیی ولگا.
پایان
لایه محاسبات بر روی تقاضا Volga یک مؤلفه مهم را برای ساخت خطوط لوله مهندسی ویژگی AI/ML در زمان واقعی ارائه می دهد ، و نیاز به کد چسب سفارشی ، مدل های داده ad-hoc و انتزاع API دستی را به میزان قابل توجهی کاهش می دهد.
معیارهای ما نشان می دهد که لایه بر روی تقاضا:
- مقیاس به صورت افقی با تعداد کارگران (با فرض مقیاس های پشتیبان ذخیره سازی مناسب).
- Sub-50ms P95 را حفظ می کند وت متوسط زیر 10ms تأخیر درخواست پایان به پایان.
- حداقل محاسبات سربار را اضافه می کند، با دسترسی به ذخیره سازی راننده اصلی تأخیر
لایه محاسبات بر روی تقاضا ولگا مقیاس پذیری افقی قوی و قابلیت های خدمت کارآمد در زمان واقعی را نشان می دهد. با حمایت مناسب برای ذخیره سازی مناسب ، خطوط لوله قابل اطمینان با تأخیر را در مقیاس امکان پذیر می کند.
برای کسب اطلاعات بیشتر یا مشارکت ، به مخزن Volga GitHubبشر با تشکر از خواندن!
منتشر شده از طریق به سمت هوش مصنوعی