إنترنت الأشياء في Yandex.Cloud: كيف يتم ترتيب خدمات وظائف Yandex IoT Core و Yandex Cloud



في أكتوبر من العام الماضي ، تم عقد أول مؤتمر سحابة Yandex Yandex Scale. أعلنت عن إطلاق العديد من الخدمات الجديدة ، بما في ذلك Yandex IoT Core ، والذي يسمح لك بتبادل البيانات مع ملايين أجهزة إنترنت الأشياء.

في هذه المقالة ، سأتحدث عن سبب الحاجة إلى Yandex IoT Core وكيف تعمل ، وكذلك كيفية التفاعل مع خدمات Yandex.Cloud الأخرى. سوف تتعلم عن الهندسة ، وتعقيدات تفاعل المكونات وميزات تنفيذ الوظائف - كل هذا سيساعدك على تحسين استخدام هذه الخدمات.

أولاً ، دعنا نتذكر المزايا الرئيسية للسحب العامة و PaaS - تقليل وقت التطوير وتكاليفه ، بالإضافة إلى تكاليف الدعم والبنية التحتية ، والتي تعتبر ذات صلة أيضًا بمشاريع إنترنت الأشياء. ولكن هناك بعض الميزات المفيدة الأقل وضوحًا التي يمكنك الحصول عليها في السحابة. يعد هذا التحجيم الفعال والتسامح مع الأخطاء جوانب مهمة عند العمل مع الأجهزة ، خاصة في مشاريع البنية التحتية الحيوية للمعلومات.

التحجيم الفعال هو القدرة على زيادة أو تقليل عدد الأجهزة بحرية دون مواجهة مشاكل فنية ورؤية تغيير يمكن التنبؤ به في تكلفة النظام بعد التغييرات.

التسامح مع الأخطاء هو الثقة في أن الخدمات مصممة ومنتشرة بطريقة تضمن أعلى أداء ممكن حتى في حالة فشل بعض الموارد.

الآن دعنا ندخل في التفاصيل.

معمارية IoT Script


أولاً ، دعنا نرى كيف تبدو البنية العامة للنص البرمجي لإنترنت الأشياء.



يمكن تمييز قسمين كبيرين فيه:

  • الأول هو تسليم البيانات إلى التخزين وتسليم الأوامر إلى الأجهزة. عند إنشاء نظام إنترنت الأشياء ، يجب حل هذه المهمة في أي حال ، بغض النظر عن المشروع الذي تقوم به.
  • والثاني يعمل مع البيانات المستلمة. كل شيء مشابه لأي مشروع آخر يعتمد على تحليل وتصور مجموعات البيانات. لديك مستودع يحتوي على مجموعة أولية من المعلومات ، وسيتيح لك العمل معه تحقيق مهمتك.

الجزء الأول هو نفسه تقريبًا في جميع أنظمة إنترنت الأشياء: فهو مبني على المبادئ العامة ويتناسب مع سيناريو مشترك مناسب لمعظم أنظمة إنترنت الأشياء.

الجزء الثاني دائمًا ما يكون فريدًا من حيث الوظائف المنجزة ، على الرغم من أنه مبني على المكونات القياسية. في الوقت نفسه ، من دون نظام تفاعل عالي الجودة ومتسامح مع الأخطاء وقابل للتطوير مع الأجهزة ، يتم تقليل فعالية الجزء التحليلي من البنية إلى الصفر تقريبًا ، لأنه ببساطة لا يوجد شيء لتحليله.

هذا هو السبب في أن فريق Yandex.Cloud قرر أولاً التركيز على بناء نظام بيئي ملائم للخدمات التي من شأنها توصيل البيانات من الأجهزة إلى المخازن بسرعة وكفاءة وموثوقية ، والعكس صحيح - إرسال الأوامر إلى الأجهزة.



لحل هذه المشاكل ، نحن نعمل على وظائف وتكامل Yandex IoT Core و Yandex Functions وخدمات تخزين البيانات في السحابة:

  • خدمة Yandex IoT Core هي وسيط MQTT قابل للتطوير وآمن متعدد المستأجرين مع مجموعة من الوظائف المفيدة الإضافية.
  • خدمة Yandex Cloud Functions هي ممثل للاتجاه الواعد بدون خادم وتسمح لك بتشغيل التعليمات البرمجية الخاصة بك كوظيفة في بيئة آمنة ومتسامحة مع الأخطاء وقابلة للتوسيع تلقائيًا دون إنشاء وصيانة الأجهزة الافتراضية.
  • تخزين كائن Yandex هو تخزين فعال لمصفوفات البيانات الكبيرة وهو مناسب جدًا لسجلات الأرشيف "التاريخية".
  • , , Yandex Managed Service for ClickHouse, «» . «» , , , .

إذا كانت خدمات تخزين البيانات وتحليلها هي خدمات "للأغراض العامة" تمت كتابتها بالفعل حول الكثير ، فإن Yandex IoT Core وتفاعلها مع وظائف Yandex Cloud عادة ما يتسببان في الكثير من الأسئلة ، خاصة للأشخاص الذين بدأوا للتو في فهم إنترنت الأشياء وتقنيات السحابة. ونظرًا لأن هذه الخدمات توفر التسامح مع الخطأ وتوسيع نطاق العمل مع الأجهزة ، سنرى أولاً ما لديهم تحت غطاء المحرك.

كيف يعمل Yandex IoT Core


Yandex IoT Core هي خدمة منصة متخصصة لتبادل البيانات في اتجاهين بين السحابة والأجهزة التي تشغل بروتوكول MQTT. في الواقع ، أصبح هذا البروتوكول هو المعيار لنقل البيانات إلى إنترنت الأشياء. يستخدم مفهوم قوائم الانتظار المسماة (المواضيع) ، حيث يمكنك من ناحية كتابة البيانات ، ومن ناحية أخرى ، استقبالها بشكل غير متزامن من خلال الاشتراك في أحداث قائمة الانتظار هذه.

خدمة Yandex IoT Core متعددة المستأجرين ، مما يعني كيانًا واحدًا يمكن لجميع المستخدمين الوصول إليه. أي أن جميع الأجهزة وجميع المستخدمين يتفاعلون مع مثيل الخدمة نفسه.

يسمح هذا ، من جهة ، بضمان توحيد العمل لجميع المستخدمين ، من ناحية أخرى ، التحجيم الفعال والتسامح مع الخطأ ، من أجل الحفاظ على الاتصال بعدد غير محدود من الأجهزة ومعالجة كمية غير محدودة من البيانات والحجم.

ويترتب على ذلك أن الخدمة يجب أن يكون لها آليات التكرار والقدرة على إدارة الموارد المستخدمة بمرونة - من أجل الاستجابة لتغييرات الحمل.

بالإضافة إلى ذلك ، يتطلب تعدد الإيجارات منطقًا خاصًا لمشاركة حقوق الوصول إلى مواضيع MQTT.

دعونا نرى كيف يتم تنفيذ ذلك.

مثل العديد من خدمات Yandex.Cloud الأخرى ، ينقسم Yandex IoT Core منطقيًا إلى قسمين - طائرة التحكم وطائرة البيانات:



تعتبر Data Data هي المسؤولة عن منطق العملية بموجب بروتوكول MQTT ، و Plane Control هي المسؤولة عن تحديد حقوق الوصول إلى موضوعات معينة وتستخدم الكيانات المنطقية Register and Device لهذا الغرض.



يمكن لكل مستخدم في Yandex.Cloud أن يكون لديه عدة سجلات ، يمكن أن يحتوي كل منها على مجموعة فرعية خاصة به من الأجهزة.

يتم توفير الوصول إلى المواضيع على النحو التالي:



يمكن للأجهزة إرسال البيانات فقط إلى موضوع الأحداث وموضوع أحداث التسجيل:

$devices/<Device1 ID>/events
$registries/<Registry ID>/events

والاشتراك في الرسائل فقط من موضوع الأوامر الخاص بك وموضوع أوامر التسجيل:

$devices/<Device1 ID>/commands
$registries/<Registry ID>/commands

يمكن للسجل إرسال البيانات إلى كافة مواضيع أوامر الجهاز وإلى موضوع أوامر التسجيل:

$devices/<Device1 ID>/commands
$devices/<Device2 ID>/commands
$registries/<Registry ID>/commands

والاشتراك في الرسائل من جميع مواضيع أحداث الجهاز وموضوع أحداث التسجيل:

$devices/<Device1 ID>/events
$devices/<Device2 ID>/events
$registries/<Registry ID>/events

للعمل مع جميع الكيانات الموصوفة أعلاه ، تحتوي Data Plane على بروتوكول gRPC وبروتوكول REST ، بناءً على ذلك يتم تنفيذ الوصول من خلال وحدة التحكم GUI لـ Yandex.Cloud وواجهة سطر الأوامر CLI.

أما بالنسبة لمستوى البيانات ، فهو يدعم إصدار بروتوكول MQTT 3.1.1. ومع ذلك ، هناك العديد من الميزات:

  1. عند الاتصال ، تأكد من استخدام TLS.
  2. يتم دعم اتصال TCP فقط. WebSocket ليست متاحة بعد.
  3. يتوفر التفويض من خلال تسجيل الدخول وكلمة المرور (حيث يكون تسجيل الدخول هو معرف الجهاز أو السجل ، ويتم تعيين كلمات المرور بواسطة المستخدم) ، واستخدام الشهادات.
  4. علامة الاحتفاظ غير مدعومة ، عند استخدامها يقوم الوسيط MQTT بحفظ الرسالة المميزة بالعلامة ويرسلها في المرة التالية التي تشترك فيها في الموضوع.
  5. الجلسة المستمرة غير مدعومة ، حيث يحفظ وسيط MQTT معلومات حول العميل (الجهاز أو السجل) لتسهيل إعادة الاتصال.
  6. مع الاشتراك والنشر ، يتم دعم أول مستويين من الخدمة فقط:
    1. QoS0 - مرة واحدة على الأكثر. لا يوجد ضمان تسليم ، ولكن لا توجد إعادة تسليم لنفس الرسالة.
    2. QoS1 - مرة واحدة على الأقل. التسليم مضمون ، ولكن هناك فرصة لإعادة تلقي نفس الرسالة.

لتبسيط الاتصال بـ Yandex IoT Core ، نضيف بانتظام أمثلة جديدة لمنصات ولغات مختلفة إلى مستودعنا على GitHub ، ونصف أيضًا النصوص في الوثائق.

تبدو بنية الخدمة كما يلي: يتضمن



منطق الأعمال الخاص بالخدمة أربعة أجزاء:

  1. Device management — . Control Plane.
  2. MQTT Broker — MQTT-. Data Plane.
  3. Triggers — Yandex Cloud Functions. Data Plane.
  4. Shards — MQTT- . Data Plane.

كل التفاعل مع "العالم الخارجي" يمر عبر موازنات الحمل. علاوة على ذلك ، وفقًا لفلسفة التطبيق التجريبي ، يتم استخدام Yandex Load Balancer ، وهو متاح لجميع مستخدمي Yandex.Cloud.

يتكون كل جزء من منطق الأعمال من عدة مجموعات من ثلاثة أجهزة افتراضية - واحدة في كل منطقة توفر (في المخطط أ ، ب ، ج). الأجهزة الافتراضية هي نفسها تمامًا مثل جميع مستخدمي Yandex.Cloud. عندما يزيد الحمل ، يحدث القياس بمساعدة المجموعة بأكملها - تتم إضافة ثلاث آلات في وقت واحد في إطار جزء واحد من منطق الأعمال. هذا يعني أنه إذا لم تتمكن مجموعة واحدة من ثلاثة آلات MQTT Broker من معالجة الحمل ، فستتم إضافة مجموعة أخرى من ثلاث آلات MQTT Broker ، بينما سيظل تكوين الأجزاء الأخرى من منطق الأعمال كما هو.

وفقط Logbroker غير متاح للجمهور. إنها خدمة للتشغيل الفعال الآمن للفشل مع تدفقات البيانات. يعتمد على Apache Kafka ، ولكن لديه العديد من الوظائف المفيدة الأخرى: فهو ينفذ عمليات استعادة البيانات بعد الكوارث (بما في ذلك مرة واحدة بالضبط دلالات عندما يكون لديك ضمان تسليم الرسائل بدون تكرار) وعمليات الخدمة (مثل النسخ المتماثل عبر المركز ، وتوزيع البيانات على مجموعات الحساب) ، ولديه أيضًا آلية للتوزيع الموحد غير المكرر للبيانات بين المشتركين في التدفق - وهو نوع من موازنة الحمل.

يتم وصف ميزات إدارة الجهاز في "لوحة التحكم" أعلاه. ولكن مع Data Data ، يصبح كل شيء أكثر إثارة للاهتمام.

يعمل كل مثيل لـ MQTT Broker بشكل مستقل ولا يعرف شيئًا عن المثيلات الأخرى. يتم إرسال جميع البيانات المستلمة (التي يتم نشرها من العملاء) بواسطة الوسطاء إلى Logbroker ، حيث يتم استلامها من قبل Shards و Triggers. ويحدث في أجزاء من التزامن بين حالات السماسرة. تعرف Shards جميع عملاء MQTT وتوزيع اشتراكاتهم (الاشتراك) عبر مثيلات وسطاء MQTT وتحديد مكان إرسال البيانات المستلمة.

على سبيل المثال ، عميل MQTT A مشترك في الموضوع من وسيط A ، وعميل MQTT B مشترك في نفس الموضوع من وسيط B. إذا قام عميل MQTT C بنشره إلى نفس الموضوع ، ولكن إلى وسيط C ، عندئذٍ ينقل جزء البيانات البيانات من وسيط C للوسطاء A و B ، ونتيجة لذلك سيتم استلام البيانات من قبل كل من عميل MQTT A وعميل MQTT B.



كما يتلقى الجزء الأخير من منطق الأعمال ، Triggers ، جميع البيانات المستلمة من عملاء MQTT ، وإذا تم تكوينها من قبل المستخدم ، فإنها تنقلها إلى مشغلات خدمة وظائف Yandex Cloud.

كما ترون ، فإن Yandex IoT Core له بنية معقدة إلى حد ما ومنطق العمل ، والذي يصعب تكراره في التركيبات المحلية. هذا يسمح له بتحمل فقدان حتى اثنين من مناطق التوافر الثلاث ، والعمل على عدد غير محدود من الاتصالات وأحجام البيانات غير المحدودة.

علاوة على ذلك ، يتم إخفاء كل هذا المنطق عن المستخدم "تحت غطاء المحرك" ، ولكن من الخارج يبدو كل شيء بسيطًا جدًا - كما لو كنت تعمل مع وسيط MQTT واحد.

مشغلات ووظائف سحابة ياندكس


وظائف Yandex Cloud هي ممثل لما يسمى بخدمات "بدون خادم" (بدون خادم) في Yandex.Cloud. الجوهر الرئيسي لهذه الخدمات هو أن المستخدم لا يقضي وقته في إعداد البيئة ونشرها وتوسيع نطاقها لتنفيذ التعليمات البرمجية ، ولكنه يتعامل فقط مع الشيء الأكثر قيمة بالنسبة له - كتابة التعليمات البرمجية نفسها التي تؤدي المهمة الضرورية. في حالة الوظائف ، هذا هو ما يسمى الكود الذري عديم الجنسية الذي يمكن تشغيله بواسطة حدث ما. تعني كلمة "Atomic" و "stateless" أن هذه الشفرة يجب أن تؤدي بعض المهام الصغيرة نسبيًا ولكنها متكاملة ، بينما يجب ألا تستخدم الشفرة أي متغيرات لتخزين القيم بين المكالمات.

هناك عدة طرق لاستدعاء الوظائف: مكالمة HTTP مباشرة ، مكالمة مؤقت (cron) ، أو اشتراك حدث. بصفتها الأخيرة ، تدعم الخدمة بالفعل الاشتراك في قوائم انتظار الرسائل (قائمة انتظار رسائل Yandex) ، والأحداث التي تم إنشاؤها بواسطة خدمة تخزين الكائن ، و (الأكثر قيمة لسيناريو إنترنت الأشياء) للاشتراك في الرسائل في Yandex IoT Core.

على الرغم من حقيقة أنه يمكنك العمل مع Yandex IoT Core باستخدام أي عميل متوافق مع MQTT ، فإن Yandex Cloud Functions هي واحدة من أكثر الطرق الأمثل والملاءمة لاستلام البيانات ومعالجتها. والسبب في ذلك بسيط جدا. يمكن استدعاء وظيفة في كل رسالة واردة من أي جهاز ، وسيتم تنفيذ الوظائف بالتوازي مع بعضها البعض (بسبب الأسلوب الذري ونهج انعدام الجنسية) ، وسيتغير عدد مكالماتهم بشكل طبيعي مع تغير عدد الرسائل الواردة من الأجهزة. وبالتالي ، يمكن للمستخدم تجاهل مشاكل إعداد البنية التحتية تمامًا ، علاوة على ذلك ، على عكس الأجهزة الافتراضية نفسها ، لن يتم الدفع إلا مقابل العمل الذي تم إجراؤه بالفعل.سيسمح لك هذا بتوفير كبير في حمل منخفض والحصول على تكلفة واضحة ويمكن التنبؤ بها مع النمو.

تسمى آلية استدعاء الوظائف في الأحداث (الاشتراك في الأحداث) مشغل (Trigger). يتم توضيح جوهرها في الرسم التخطيطي:



الخدمة التي تولد أحداث لدالات الاستدعاء تضعها في قائمة انتظار في Logbroker. في حالة Yandex IoT Core ، تقوم المشغلات من Data Data Plane بذلك. علاوة على ذلك ، يتم أخذ هذه الأحداث بواسطة المعالج المسبق ، الذي يبحث عن سجل في قاعدة البيانات لهذا الحدث يشير إلى الوظيفة التي سيتم استدعاؤها. إذا تم العثور على مثل هذا الإدخال ، يضع المعالج المسبق معلومات حول استدعاء الوظيفة (معرف الوظيفة ومعلمات الاستدعاء) في قائمة الانتظار في خدمة Yandex Message Queue ، حيث يلتقطها معالج المكالمة. يقوم المعالج ، بدوره ، بإرسال طلب HTTP لاستدعاء الوظيفة إلى خدمة Yandex Cloud Functions.

في الوقت نفسه ، مرة أخرى ، وفقًا لفلسفة التطبيق التجريبي ، يتم استخدام خدمة Yandex Message Queue ، التي يمكن الوصول إليها من قبل جميع المستخدمين ، ويتم استدعاء الوظائف بنفس الطريقة تمامًا التي يمكن بها لأي مستخدمين آخرين استدعاء وظائفهم.

دعنا نقول بضع كلمات حول قائمة انتظار رسائل Yandex. على الرغم من حقيقة أن هذه ، مثل Logbroker ، هي خدمة قائمة انتظار ، إلا أن هناك فرقًا كبيرًا بينها. عند معالجة الرسائل من قوائم الانتظار ، يقوم المعالج بإبلاغ قائمة الانتظار التي تم الانتهاء منها ويمكن حذف الرسالة. هذه آلية موثوقية مهمة في مثل هذه الخدمات ، لكنها تعقد منطق العمل مع الرسائل.

يتيح لك Yandex Message Queue "موازاة" معالجة كل رسالة ضمن قائمة الانتظار. بمعنى آخر ، لا تمنع الرسالة من قائمة الانتظار التي تتم معالجتها حاليًا إمكانية وجود "مؤشر ترابط" آخر لالتقاط الحدث التالي من قائمة الانتظار للمعالجة. وهذا ما يسمى التزامن على مستوى الرسائل.

ويعمل LogBroker على مجموعات الرسائل ، وحتى يتم معالجة المجموعة بأكملها ، لا يمكن اختيار المجموعة التالية للمعالجة. يسمى هذا النهج التزامن على مستوى القسم.

وهو بالتحديد استخدام Yandex Message Queue الذي يسمح لك بمعالجة الكثير من الطلبات بسرعة وكفاءة بالتوازي مع العديد من الطلبات لاستدعاء الوظائف في الأحداث من خدمة معينة.

على الرغم من حقيقة أن المشغلات هي وحدة مستقلة منفصلة ، فهي جزء من خدمة وظائف Yandex Cloud. علينا فقط معرفة كيفية استدعاء الوظائف بالضبط.



تقع جميع طلبات استدعاء الوظائف (الخارجية والداخلية) في موازن التحميل ، الذي يوزعها على أجهزة التوجيه في مناطق الوصول المختلفة (AZ) ، ويتم نشر عدة قطع في كل منطقة. عند تلقي طلب ، ينتقل جهاز التوجيه أولاً إلى خدمة إدارة الهوية والوصول (IAM) للتأكد من أن مصدر الطلب لديه حقوق استدعاء هذه الوظيفة. ثم يتحول إلى المجدول ويسأل أي عامل لتشغيل الوظيفة. العامل عبارة عن آلة افتراضية مع وقت تشغيل مخصص للوظائف المعزولة. علاوة على ذلك ، فإن جهاز التوجيه ، بعد أن تلقى من المجدول عنوان العامل الذي سيتم تنفيذ الوظيفة عليه ، يرسل أمرًا إلى هذا العامل لبدء الوظيفة بمعلمات معينة.

من أين أتى العامل؟ هذا هو المكان الذي يحدث فيه كل السحر بدون خادم. تقوم الجدولة ، وتحليل الحمل (عدد الوظائف ومدتها) ، بإدارة (تشغيل وإيقاف) الأجهزة الافتراضية بوقت تشغيل معين. يتم دعم NodeJS و Python الآن. وهنا معلمة واحدة مهمة للغاية - سرعة وظائف الإطلاق. قام فريق تطوير الخدمة بعمل رائع ، والآن تبدأ الآلة الافتراضية بحد أقصى 250 مللي ثانية ، بينما تستخدم البيئة الأكثر أمانًا لعزل الوظائف عن بعضها البعض - QEMU virtualization ، التي تعمل على جميع Yandex. Cloud. في الوقت نفسه ، إذا كان هناك بالفعل عامل عامل للطلب الوارد ، فستبدأ الوظيفة على الفور تقريبًا.
ووفقًا لنفس نهج التطبيق التجريبي ، يستخدم Load Balancer خدمة عامة في متناول جميع المستخدمين ، والعامل والجدولة والموجه أجهزة افتراضية عادية ، مثل جميع المستخدمين.

وبالتالي ، يتم تنفيذ التسامح مع الخطأ للخدمة على مستوى موازن التحميل والتكرار لمكونات النظام الرئيسية (جهاز التوجيه والجدولة) ، ويحدث التحجيم بسبب نشر أو تقليل عدد العاملين. علاوة على ذلك ، تعمل كل منطقة وصول بشكل مستقل ، مما يسمح بالنجاة من فقدان حتى اثنتين من المناطق الثلاث.

روابط مفيدة


في الختام ، أود أن أعطي بعض الروابط التي تسمح لك بدراسة الخدمات بمزيد من التفصيل:


All Articles