چگونه ابر FaaS را در داخل Kubernetes ساختیم و در هکاتون Tinkoff برنده شدیم

از سال گذشته، شرکت ما شروع به سازماندهی هکاتون ها کرد. اولین مسابقه از این دست بسیار موفق بود، ما در مورد آن نوشتیم مقاله. دومین هکاتون در فوریه 2019 برگزار شد و موفقیت کمتری نداشت. در مورد اهداف برگزاری دومی نه چندان دور نوشت تنظیم کننده.

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

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

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

چه چیزی گل می زند

Tinkoff.ru، مانند بسیاری از شرکت های مدرن، امتیازدهی مشتری دارد. امتیازدهی یک سیستم ارزیابی مشتری بر اساس روش های آماری تجزیه و تحلیل داده ها است.

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

مبنای اتخاذ چنین تصمیماتی مدل های ریاضی هستند که هم داده های خود برنامه و هم داده های ذخیره سازی ما را تجزیه و تحلیل می کنند. علاوه بر امتیاز دهی، از روش های آماری مشابه نیز می توان در خدمت ایجاد توصیه های فردی برای محصولات جدید برای مشتریان خود استفاده کرد.

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

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

برای کار در دست، ما در حال حاضر از یک سیستم تصمیم گیری تخصصی استفاده می کنیم IBM WebSphere ILOG JRules BRMS، که بر اساس قوانین تعیین شده توسط تحلیلگران، فناوران و توسعه دهندگان، تصمیم می گیرد که آیا یک محصول بانکی خاص را به مشتری تایید یا رد کند.

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

وظیفه

هکاتون در 23 فوریه برگزار شد. به شرکت کنندگان یک وظیفه رزمی پیشنهاد شد: ایجاد یک سیستم تصمیم گیری که باید تعدادی از شرایط را برآورده کند.

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

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

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

راه حل ما

پس از کمی طوفان فکری، تصمیم گرفتیم که راه حل FaaS برای تکمیل کار ایده آل است.

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

برای یافتن موثرترین راه حل، محصول در حال توسعه را از دید کاربران آن بررسی کردیم. کاربران اصلی سیستم ما تحلیلگرانی هستند که در توسعه قوانین نقش دارند. قوانین باید در سرور مستقر شوند، یا مانند مورد ما، برای تصمیم گیری بعدی در فضای ابری مستقر شوند. از دیدگاه یک تحلیلگر، گردش کار به این صورت است:

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

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

حتی قبل از هکاتون، ما در مورد چارچوب بدون سرور تصمیم گرفتیم که از آن استفاده کنیم. امروزه فناوری های زیادی در بازار وجود دارد که این رویکرد را اجرا می کنند. محبوب ترین راه حل ها در معماری Kubernetes Fission، Open FaaS و Kubeless هستند. حتی وجود دارد مقاله خوبی با توصیف و تحلیل تطبیقی ​​آنها.

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

برای کار با Fission، باید دو مفهوم اساسی را بدانید: عملکرد و محیط. تابع قطعه ای از کد نوشته شده به یکی از زبان هایی است که برای آن محیط Fission وجود دارد. لیست محیط های پیاده سازی شده در این چارچوب شامل Python، JS، Go، JVM و بسیاری از زبان ها و فن آوری های محبوب دیگر است.

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

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

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

آنچه به دست آوردیم

از آنجایی که ما با یک راه حل آماده (در خیالاتمان) به هکاتون آمدیم، تنها کاری که باید انجام می دادیم این بود که تمام افکارمان را به خطوط کد تبدیل کنیم.

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

معماری پروژه ما به شرح زیر بود:

این نمودار دو نقطه ورود، تحلیلگر (کاربر اصلی سیستم ما) و مشتری را نشان می دهد.

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

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

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

بنابراین، ما XNUMX ساعت فرصت داشتیم تا پلتفرم را پیاده سازی کنیم. ما نقش ها را با موفقیت توزیع کردیم؛ هر یک از اعضای تیم مسئولیت خود را در پروژه ما داشت:

1. پنل‌های مدیریتی جلویی برای کار تحلیلگر، که از طریق آن‌ها می‌توانست قوانین را از سیستم کنترل نسخه اسکریپت‌های نوشته شده دانلود کند، گزینه‌هایی را برای غنی‌سازی داده‌های ورودی انتخاب کند و اسکریپت‌های قوانین را به صورت آنلاین ویرایش کند.
2. مدیر Backend، از جمله REST API برای جلو و ادغام با VCS.
3. راه اندازی زیرساخت در Google Cloud و توسعه سرویسی برای غنی سازی داده های منبع.
4. ماژولی برای ادغام برنامه مدیریت با چارچوب بدون سرور برای استقرار بعدی قوانین.
5. اسکریپت قوانین برای آزمایش عملکرد کل سیستم و تجمیع تجزیه و تحلیل در برنامه های ورودی (تصمیمات اتخاذ شده) برای نمایش نهایی.

بیایید شروع کنیم.

ظاهر ما در Angular 7 با استفاده از کیت UI بانکی نوشته شده است. نسخه نهایی پنل مدیریت به صورت زیر بود:

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

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

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

باطن پلتفرم به زبان جاوا نوشته شده و به عنوان یک اپلیکیشن Spring Boot پیاده سازی شده است. ما در ابتدا قصد داشتیم از Postgres برای ذخیره داده های مدیریت استفاده کنیم، اما، به عنوان بخشی از هکاتون، تصمیم گرفتیم برای صرفه جویی در زمان خود را به یک H2 ساده محدود کنیم. در باطن، ادغام با Bitbucket برای نسخه‌سازی توابع غنی‌سازی پرس و جو و اسکریپت‌های قانون پیاده‌سازی شد. برای ادغام با مخازن Git راه دور، ما استفاده کردیم کتابخانه JGit، که نوعی پوشش بر روی دستورات CLI است و به شما امکان می دهد هر دستورالعمل git را با استفاده از یک رابط نرم افزاری مناسب اجرا کنید. بنابراین ما دو مخزن جداگانه برای توابع و قوانین غنی سازی داشتیم و همه اسکریپت ها به دایرکتوری ها تقسیم شدند. از طریق UI امکان انتخاب آخرین commit یک اسکریپت از شاخه دلخواه مخزن وجود داشت. هنگام ایجاد تغییرات در کد از طریق پنل مدیریت، commit های کد تغییر یافته در مخازن راه دور ایجاد می شوند.

برای اجرای ایده خود به زیرساخت های مناسب نیاز داشتیم. ما تصمیم گرفتیم که خوشه Kubernetes خود را در فضای ابری مستقر کنیم. انتخاب ما Google Cloud Platform بود. چارچوب بدون سرور Fission بر روی یک خوشه Kubernetes نصب شده بود که ما آن را در Gcloud مستقر کردیم. در ابتدا، سرویس غنی‌سازی منبع داده به‌عنوان یک برنامه جاوا جداگانه که در یک Pod در داخل خوشه k8s پیچیده شده بود، پیاده‌سازی شد. اما پس از نمایش اولیه پروژه ما در اواسط هکاتون، به ما توصیه شد که سرویس Enrichment را انعطاف‌پذیرتر کنیم تا فرصت انتخاب نحوه غنی‌سازی داده‌های خام برنامه‌های ورودی را فراهم کنیم. و ما چاره ای نداشتیم جز اینکه سرویس غنی سازی را نیز بدون سرور کنیم.

برای کار با Fission از Fission CLI استفاده کردیم که باید بالای Kubernetes CLI نصب شود. استقرار توابع در یک خوشه k8s بسیار ساده است؛ فقط باید یک مسیر داخلی و ورودی به تابع اختصاص دهید تا در صورت نیاز به دسترسی به خارج از خوشه، به ترافیک ورودی اجازه دهید. استقرار یک تابع معمولاً بیش از 10 ثانیه طول نمی کشد.

ارائه نهایی پروژه و جمع بندی

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

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

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

در مجموع 3 محصول ساختگی بانکی موجود بود:

• اعتبار.
• اسباب بازی
• رهن.

در طول نمایش، ما توابع آماده و اسکریپت های غنی سازی را برای هر سرویس مستقر کردیم.

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

ما سعی کردیم تظاهرات خود را جالب و تعاملی کنیم، همه حاضران می توانستند به فرم ما مراجعه کنند و در دسترس بودن خدمات داستانی ما برای آنها را بررسی کنند. و در پایان ارائه، تجزیه و تحلیل برنامه های دریافتی را نشان دادیم که نشان می داد چند نفر از خدمات ما، تعداد تأییدها و امتناع ها استفاده می کنند.

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

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

منبع: www.habr.com