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

مشکلاتی که قصد حل آن را داریم چیست؟

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

خودروهای سریع حرکت

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

محاسبه مسافت مسیری

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

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

جستجو برای K نزدیکترین رانندگان نسبت به یک POI (Point of Interest) مسئله ای است که برای تمام شرکت های حمل و نقل سواری مطالعه شده است و می توان آن را به عنوان مسئله همسایگی نزدیکترین همسایه (KNN) در نظر گرفت. نسل قبلی ما، Sextant ، با فاصله haversine از موقعیت مکانی رانندگان تا نقطه پیکاپ ، رانندگان نزدیک را جستجو می کند. با تقسیم منطقه به شبکه ها و ذخیره آنها به صورت توزیع شده ، Sextant می تواند با ضریب فشار کم ، حجم بالا از درخواست ها را با تاخیر پایین پردازش کند. با این حال ، در نزدیکترین راننده هایی که توسط مسافت هوایی پیدا می شوند ممکن است مسافت رانندگی و ETA طولانی رخ دهد ، همانطور که در شکل ۲ نشان داده شده است. برای کسب اطلاعات بیشتر در مورد Sextant ، لطفا به مقاله Sextant: Grab’s Scalable In-Memory Spatial Data Store for Real-Time K-Nearest Neighbour Search مراجعه کنید.

برای رفع بهتر چالش های فوق، ما یک راه حل نسل بعدی به نام Pharos ارائه می‌دهیم.

Pharos چیست؟

Pharos به مفهوم چراغدار در یونانی است. در Grab ، این یک راه حل در حافظه مقیاسپذیر است که جستجوی نزدیکترین K حجم بزرگ ، زمان واقعی را با فاصله رانندگی یا ETA با فرکانس بالا از مکان‌های شی را پشتیبانی می‌کند.

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

Pharos گراف‌های بخش‌های را در زمان شروع سرویس بارگیری می‌کند و داده‌های فضایی رانندگان را به صورت توزیع شده در حافظه ذخیره می‌کند تا مشکل مقیاس‌پذیری را در صورت رشد گراف یا تعداد رانندگان رفع کند. این داده‌ها به چندین نمونه (یعنی ماشین‌ها) با تکثیر برای استقرار بالا استفاده می‌شود. Pharos از درخت‌های Adaptive Radix Trees (ART) برای ذخیره مکان اشیا همراه با متادیتا استفاده می‌کند.

برای پاسخ به پرس و جوی KNN بر اساس مسافت مسیری یا ETA ، Pharos از Incremental Network Expansion (INE) استفاده می‌کند که با شروع از بخش جاده نقطه پرس و جو آغاز می‌شود. در طول گسترش ، رانندگانی که در سگمنت‌های جاده ذخیره شده‌اند به صورت تدریجی به عنوان نامزدها بازیابی می‌شوند و در نتایج قرار می‌گیرند. چون گسترش در واقع نقشه ایزوکرون را تولید می‌کند ، می تواند با رسیدن به شعاع قابل تعریفی از فاصله یا ETA و یا حتی تعداد حداکثر نامزدها خاتمه یابد.

اکنون که یک نمای کلی از Pharos دارید ، ما می‌خواهیم به جزئیات طراحی آن بپردازیم ، با شروع از معماری آن.

معماری Pharos

به عنوان یک میکرو سرویس ، Pharos درخواست ها را از اپ استریم دریافت می کند ، عملیات مربوطه را انجام می دهد و سپس نتیجه را باز می گرداند. همانطور که در شکل ۴ نشان داده شده است ، معماری Pharos می تواند به سه لایه تقسیم شود: Proxy ، Node و Model.

لایه Proxy. این لایه در گذراندن درخواست به نود مناسب کمک می کند ، به ویژه وقتی که نود بر روی یک ماشین دیگر است.Node لایه. این لایه شاخص راهنمایی برای شناسه نقشه به مدل ها ذخیره می کند و درخواست را برای اجرا به مدل مناسب ارسال می کند.Model لایه. این لایه ، جایی است که منطق تجاری پیاده سازی شده است ، عملیات را اجرا می کند و نتیجه را باز می گرداند.

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

با توجه به شکل ۴ به عنوان مثال ، Pharos از سه نمونه تشکیل شده است. هر نمونه به تنهایی قادر به پاسخگویی به هر درخواست از اپ استریم است. هرگاه درخواستی از اپ استریم داشته باشیم آن درخواست در یکی از سه نمونه توزیع می‌شود ، که منجر به توازن بار می‌شود.

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

با توجه به معماری Pharos ، بیایید به ذخیره‌سازی اطلاعات راننده نگاهی بیندازیم.

ذخیره اطلاعات راننده

Pharos به عنوان یک ذخیره کننده راننده عمل می‌کند و در عوض از ذخیره سازی درون حافظه استفاده می کند که سریعتر و مناسب تر برای پردازش مکان به روز رسانی های مکان راننده ها و بازیابی مکان راننده ها برای پرس و جوهای نزدیک به راننده است. بدون از دست دادن کلیت مساله ، فرض می شود که رانندگان در ورودی ها قرار دارند ، یعنی گره های مبتنی بر لبه (EBN) از یک گراف مبتنی بر لبه.

مدل مسئول ذخیره سازی راننده در Pharos است. اشیای راننده از لایه های بالا وارد لایه مدل جهت ذخیره شده و هر اشیا راننده شامل چندین فیلد مانند شناسه راننده و متادیتا است که شامل اطلاعات تجاری مربوط به راننده (مانند وضعیت راننده و ترجیحات تخصیص خاص) است.

همچنین زوج Latitude و Longitude (LatLon) همراه با اشیا قرار دارد که موقعیت فعلی راننده را نشان می‌دهد. اغلب این زوج LatLon ارسال شده توسط راننده خارج از جاده (بر روی هیچ جاده موجودی نیست). محاسبه مسافت مسیری بین نقطه پرس و جو و راننده بر اساس شبکه جاده است. بنابراین ، باید استنتاج کنیم که راننده بیشترین احتمالاً در کدام بخش جاده (EBN) باید باشد.

تبدیل زوج Latitude و Longitude (LatLon) به موقعیت دقیقی در جاده به اسنپینگ گفته می شود. مدل با یافتن EBN هایی که به موقعیت راننده نزدیک هستند شروع می کند. پس از آن ، همانطور که در شکل ۵ نشان داده شده است ، موقعیت راننده به این EBN ها نیز پرتاب می شود ، با کشیدن خطوط عمودی از موقعیت به EBN ها. نقطه پرتاب به عنوان یک نقطه سرگرمی نشان داده می شود. همانطور که از نام پیداست ، این گره ها در گراف وجود ندارند. آنها فقط تجسم حافظه ای از موقعیت راننده اشباع شده است.

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

برای شاخص‌گذاری بهینه‌تر رانندگان از گراف ، Pharos از ART برای ذخیره کردن راننده استفاده می ‌کند. هر مدل دو ART را حفظ می کند: ART راننده و ART EBN.

ART راننده برای ذخیره سازی شاخص شناسه راننده به اشیا راننده مربوطه استفاده می شود ، در حالی که ART EBN برای ذخیره شاخص شناسه EBN به ریشه ART استفاده می شود که رانندگان را در آن EBN ذخیره می کند.

شاخص‌گذاری دوطرفه بین EBN ها و راننده ها ایجاد می‌شود زیرا نیاز به بازیابی کارآمد از راننده به EBN به دلیل به روز رسانی مداوم مکان راننده ها وجود دارد. در عمل ، به عنوان کلیدهای شاخص ، شناسه راننده و شناسه EBN هر دو عددی هستند. ART دارای یک

یک مقاله تحقیقاتی نوشته شده توسط Tenindra Abeywickrama (Grab) ، Victor Liang (Grab) و Kian-Lee Tan (NUS) بر اساس کارشان که به عنوان بهترین مقاله داده های علمی بزرگ قابل اندازه برای سال 2021 انتخاب شد.

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

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

یک مثال واقعی

بیایید یک الگوریتم مطابقت ساده را همانطور که در شکل 1 نشان داده شده است در نظر بگیریم ، که مسافران و رانندگان شریک بر اساس زمان سفر مطابقت داده می شوند. در این شکل ، سه راننده شریک (D1 ، D2 و D3) و سه مسافر (P1 ، P2 و P3) داریم.

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

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

یافتن تخصیص بهینه به عنوان حل مسئله مطابقت دوقسمتی با وزن حداقل (همچنین شناخته شده به عنوان مسئله اختصاص) است. این مسئله معمولاً با استفاده از یک تکنیک به نام الگوریتم Kuhn-Munkres (همچنین شناخته شده به عنوان روش مجارستانی) حل می شود.

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

تأثیر ماتریس هزینه

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

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

اگر m تعداد رانندگان شریک / مسافرانی که سعی در مطابقت انجام می دهیم باشد ، الگوریتم KM معمولاً در O(m ^ 3) اجرا می شود. اگر n تعداد گره های شبکه جاده باشد ، زمان محاسبه ماتریس هزینه در O(m x n log n) با استفاده از الگوریتم دیکستراست.

می دانیم که n برای شبکه جاده سنگاپور در حدود 400،000 است (و برای شهرهای بزرگتر از این بزرگتر است) ، بنابراین می توانیم انتظار داشته باشیم O(m x n log n) مسلط بر O(m^3) برای m <1500 باشد ، که از این نوع سناریوی مورد انتظار در جهان واقعی است. برای تأیید این موضوع ، آزمایشات را روی شبکه جاده سنگاپور انجام دادیم که در شکل 2 نشان داده شده است.

در شکل 2a می توانیم ببینیم که m باید بیش از 2500 باشد تا زمان تخصیص زمان محاسبه ماتریس را فراتر بگیرد. حتی اگر از یک تکنیک مدرن و پیشرفته مانند سلسله مراتب تقلیلی3 برای محاسبه مسیر سریعتر استفاده کنیم ، مشاهده می شود که این امر صحیح است ، همانطور که در شکل 2b نشان داده شده است. این نشان می دهد که می توانیم عملکرد کلی مطابقت را به طور قابل توجهی بهبود بخشیم اگر بتوانیم زمان محاسبه ماتریس را کاهش دهیم.

یک بصیرت خارج کننده: محلیت فضایی مطابقت

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

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

اکنون سوال این است که آیا ما حتی باید سایر هزینه ها را محاسبه کنیم تا تطابق بهینه را پیدا کنیم؟ به عنوان مثال ، می توانیم هزینه از D3 به P1 را که بسیار دور از هم و احتمالاً تطابق نخواهند یافت ، محاسبه نکنیم؟

الگوریتم Kuhn-Munkres تکمیلی

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

بازیابی شیء نزدیکترین به نقطه پرس و جستجو با سرعت بالاتر برای مسئله مطالعۀ شده ای است (معمولاً به عنوان جستجوی k-Nearest Neighbour شناخته می شود). ما این مفهوم را برای پیاده سازی یک صف اولویت Q برای هر راننده ui به کار می بریم ، همانطور که در شکل 4 نشان داده شده است. این صف های اولویت امکان بازیابی نزدیکترین مسافران را به منظور حداقل جستجوی زمان یک مسافر را با استفاده از یک کمینه به عنوان یک کمینه شود. پایینی اولویت این صف به عنوان یک هزینه حداقلی برای کل یال های دوقسمتی مرتبط با آن راننده شریک که هنوز دقیقاً هزینه را محاسبه نکرده ایم ، استفاده کنید.

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

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

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

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

تحقیقات تجربی

رقابت

ما یک بررسی تجربی دقیق را برای تأیید عملکرد عملی تکنیک های پیشنهادی انجام دادیم. ما دو نسخه از تکنیک KM تکمیلی خود را پیاده سازی کردیم که در پیاده سازی صف اولویت و تکنیک کوتاهترین مسیر استفاده شده متفاوت بودند.

IKM-DIJK: از الگوریتم دیکسترا برای محاسبه مسیرهای کوتاه استفاده می کند. صف های اولویت به سادگی صف اولویت جستجوی دیکسترا از هر راننده شریک است. این هیچ هزینه اضافی نسبت به

معرفی

تیم پلتفرم داده زمان واقعی Grab یا همان Coban، به عنوان یکی از بزرگترین خوشه های Kafka در تمام عموده های مختلف فعالیت داشته است و تمرکز قوی بر روی ارائه عملکرد برتر و 99.99٪ در دسترس بودن داشته است.

امنیت همیشه یکی از اولویت های اصلی Grab بوده است و به محض اینکه متقلبان ادامه می دهند، نیاز به تقویت امنیت پلتفرم جریان داده هایمان افزایش یافته است. یکی از راه های انجام این کار، انتقال از یک کنترل دسترسی مبتنی بر شبکه به امنیت و حفاظت به شکل حالت صفر اعتماد است، مانند:

تأیید هویت: اولین موردی که برای هر سیستم از راه دور - مشتریان و سرورها - تأیید و تعیین می شود، تأکید بر پیام رسان است که پیش از هر ارتباط بعدی صورت می گیرد.مجوز دهی: به Kafka بر اساس اصل کمترین امتیاز دسترسی دسترسی داده می شود؛ هیچ دسترسی به طور پیش فرض داده نمی شود. مشتریان Kafka با موضوعات Kafka سفیدلیست شده و مجوزها - مصرف یا تولید - که به طور دقیق نیاز دارند ، مرتبط هستند. همچنین، دسترسی اعطا شده قابل بررسی است.محرمانگی: تمام ترافیک در حالت انتقال رمزگذاری می شود.

راه حل

ما تصمیم گرفتیم که برای تأیید هویت و رمزگذاری از امنیت Layers Transport لزومیتا استفاده کنیم. این لایه به مشتریان امکان می دهد تا سرورها را تأیید و مشتریان جهت تأیید هویت را برعکس جواب دهد.

Kafka از سایر مکانیزم های تأیید هویت مانند OAuth یا مکانیزم احراز هویت سالت چالش پاسخ (SCRAM) پشتیبانی می کند ، اما ما به ماژول Transport Layer Security موتور OpenSSL تسلط پیدا کرده ایم زیرا قادر است هویت همتای خود را آفلاین تأیید کند. این توانایی تأیید به این معنی است که سیستم ها نیازی به اتصال فعال به یک سرور تأیید هویت ندارند تا هویت همتای خود را تعیین کنند. این امکان را فراهم می کند که در محیط های شبکه متفاوت عمل کرد که همه طرف ها به یک مرکز اصلی دسترسی ندارند.

ما برای تولید گواهی نامه های کاربران و سرورها، از Vault Hashicorp و موتور PKI آن استفاده می کنیم. این به ما امکان می دهد استفاده از گواهی نامه های با مدت زمان کوتاه برای مشتریان را مورد اجبار قرار دهیم که این یک راه برای کاهش تأثیر بالقوه یک گواهی نامه کاربر در صورت تخلف یا به اشتراک گذاری مخرب است. ما درست گفتیم صفر اعتماد؟

برای مجوز دهی، ما روی Control دسترسی الموعات مبتنی بر سیاست (PBAC) که یک راه حل قابل مقیاس می باشد نسبت به کنترل دسترسی مبتنی بر نقش (RBAC) تمرکز کردیم و OPA را به عنوان پلتفرم سیاست های ما انتخاب کردیم. از پشتیبانی گسترده انجمن OPA نیز بهره بردیم.

برای ادغام mTLS و OPA با Kafka، ما از Strimzi به عنوان اپراتور Kafka در Kubernetes استفاده کردیم. در یک مقاله پیشین، ما به Strimzi اشاره کرده و به اینکه چگونه می تواند با قابلیت مقیاس پذیری و بی طرفیت ابر کمک کند. امنیت داخلی بدون شک یکی از دلایل اصلی وجود Strimzi بود.

تأیید هویت سرور

ما ابتدا برای هر محیط (مرحله، تولید، و غیره) یک موجودیت گواهی معتبر راهبردی را تعریف می کنیم. این CA روت، که در طرح به رنگ آبی است، توسط خوشه Vault Hashicorp مدیریت می شود. باید توجه کنید که رنگ گواهی نامه ها، کلیدها، پشتیبانی بر روی پیام رسان ها و امضاها در طول این مقاله یکسان است.

برای امن کردن ارتباطات داخلی خوشه، مانند ارتباطات بین بروکر Kafka و پالایه های Zookeeper، Strimzi یک CA خوشه تنظیم می کند که توسط CA روت امضا می شود (مرحله 1). CA خوشه سپس برای امضای گواهی های کاربران و zookeeper فراداده ها استفاده می شود (مرحله 2). در نهایت، گواهی عمومی CA روت به truststore بروکر Kafka و Zookeeper داخلی استخراج می شود (مرحله 3)، بنابراین تمام پالایه ها می توانند گواهی های خود را با استفاده از هویت خود به صورت نیز معتبر کنند.

CA خوشه تعبیه شده StrimziCertificates هنگام ایجاد جدید Kafka و Zookeeper pods، چهارپایه معتبر تولید می کند. عملیات امضا کردن (مرحله 2) به صورت خودکار توسط Strimzi انجام می شود.

برای دسترسی کاربر به بروکرهای Kafka، Strimzi یک مجموعه مختلف از CA می سازد و گواهی های سرور را، همانطور که در نمودار بعدی نشان داده شده است، طبقه بندی می کند.

همان CA روت در شکل 1، یک CA میانی متفاوت طبقه بندی می کند، که جامعه Strimzi آن را CA مشتری می نامد (مرحله 1). این نامگذاری گمراه کننده است چرا که در واقع هیچ گواهی کاربری امضا نمی شود، بلکه تنها گواهی های سرور (مرحله 2) که در گوشی های جانبی بروکر Kafka قرار می گیرند. این گواهی های سرور برای مشتریان Kafka برای تأیید هویت سرور هستند. در این مرحله، گواهی عمومی CA روت در truststore کاربر Kafka وارد می شود (مرحله 3).

تأیید هویت مشتری

برای تأیید هویت مشتری، ابتدا کلاینت Kafka باید به Hashicorp Vault تأیید هویت کند و درخواستی برای گواهی گذرا از موتور PKI Vault داشته باشد (مرحله 1). Vault یک گواهی صادر کرده و آن را با استفاده از CA روت خود امضا می کند (مرحله 2). با این گواهی، کلاینت می تواند به بروکرهای Kafka تأیید هویت کند که از گواهی عمومی CA روت قبلاً در truststore خود استفاده می کنند، همانطور که قبلاً توضیح داده شد (مرحله 3).

درخت CA

اضافه کردن سه فرآیند متفاوت تأیید هویت که تازه توضیح دادیم، درخت CA هم اکنون به این شکل است. توجه کنید که این یک نمای ساده شده برای یک محیط تنها، یک خوشه تنها و دو مشتری است.

همانطور که از قبل اشاره شد، هر محیط (مرحله، تولید، و غیره) دارای CA روت خود است. در هر محیط، هر خوشه Strimzi دارای جفتی از CA های متوسطی خود است: CA خوشه و CA کاربر. در سطح برگ، pods Zookeeper و بروکر Kafka هر کدام گواهی های جداگانه ای دارند.

در سمت راست نمودار، هر کلاینت Kafka هرگاه نیاز به اتصال به Kafka داشته باشد، می تواند یک گواهی گذرا از Hashicorp Vault دریافت کند. هر تیم یا برنامه ای نقش PKI استفاده شده در Hashicorp Vault را دارا است، که محدود کننده آنچه می توان به گواهی خود درخواست کرد (مانند موضوعات، TTL و غیره) است.

مستند سازی Strimzi

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

زیر پوشش ، استقرار Kafka Strimzi یک استقرار Kubernetes است. برای افزایش عملکرد و قابلیت اطمینان خوشه Kafka ، به ازای هر بروکر Kafka Strimzi و هر پالایه Zookeeper ، از پالایه های کوبرنتیز اختصاصی استفاده می کنیم با تراشه ها و قابلیت تحمل. این اطمینان حاصل می کند که تمام منابع یک پالایه تنها به طور انحصاری به یک بروکر Kafka تنها یا یک پالایه Zookeeper تنها اختصاص داده می شوند.

همچنین تصمیم گرفتیم تنها با یک خوشه Kafka توسط خوشه Kubernetes راه بیوفتیم تا مدیریت آن را آسانتر کنیم.

راه اندازی کاربر

Coban یک SDK محبوب Kafka است که به تیم های میکروسرویس های پشتیبانی شده توسط verticals Grab ارائه می دهد ، برای استانداردسازی نحوه استفاده تیم ها از خوشه های Kafka Coban. افزودن پشتیبانی mTLS در حدود آپگرید کردن SDK ما می افتد.

SDK ارتقاء یافته ما یک پیکربندی mTLS پیش فرض را فراهم می کند که برای بیشتر تیم ها به صورت آماده بکار می آید، در عین حال امکان سفارشی سازی را نیز می دهد، به عنوان مثال برای تیم هایی که به دلایل تطابق خاص خود برای Hashicorp Vault زیرساخت دارند. به طور مشابه، مشتریان می توانند از روش های اعتبارسنجی مختلف Vault مانندAWSیاKubernetesبرای تأیید هویت به Hashicorp Vault عمل کنند، یا حتی منطق خود را برای دریافت گواهی معتبر کاربر پیاده سازی کنند.

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

در مورد ما، Vault Hashicorp یک وابستگی است. برای جلوگیری از کاهش در دسترسی بالقوه پلتفرم جریان داده هایمان، دو قابلیت به SDK ما اضافه کرده ایم - یک مکانیسم تکرار تنظیم شده و تجدید خودکار گواهی های کوتاه مدت مشتریان هنگامی که دو سوم مدت زمان باقیمانده TTL آنها رسیده است. SDK ارتقا یافته همچنین معیار های جدیدی را درمورد این فرایند تجدید گواهی تولید می کند، که باعث می شود مانیتورینگ و الارم بهتری فراهم شود.

مجوز دهی

برای مجوز دهی، OPA را به عنوان یک اجرای مستقل در خوشه Kubernetes پیکربندی کرده و Strimzi را برای ادغام بروکرهای Kafka با آن پیکربندی کرده ایم.

سیاست های OPA - نوشته شده به زبان Rego - منطق مجوز را توصیف می کنند. آنها به همراه قوانین مجوزها که منابع داده ای نامیده می شوند در یک مخزن GitLab ایجاد می شوند (مرحله 1). هر بار که یک تغییر رخ دهد، pipeline CI GitLab به طور خودکار یک باندل از سیاست ها و منابع داده را ایجاد می کند و به یک Bucket S3 فشرده می کند (مرحله 2). از آنجا، آن توسط OPA فراخوانی می شود (مرحله 3).

هنگامی که یک مشتری - با شناسایی شده توسط موضوع گواهی TLS خود - سعی در مصرف یا تولید یک رکورد Kafka دارد (مرحله 4)، ابتدا pod بروکر Kafka درخواست مجوز را به OPA صادر می کند (مرحله 5) قبل از پردازش درخواست مشتری توسط بروکر. نتیجه درخواست مجوز سپس توسط pod بروکر Kafka کش می شود تا عملکرد بهتری ارائه شود.

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