استخدام الذكاء الصناعي في مسابقة حملة تسويقية – سيناريوهات سحابية

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

الجائزة كانت مشاهدة مباراة كرة قدم في أحد المقاهي مع خصم بقيمة 100 درهم على الطعام، مع مكافآت اخرى!

وبالفعل قمت بالاشتراك وفعلاً ربحت المكافأة، فأنا شخص محظوظ بالمجمل 🙂

يتم الاشتراك بالمسابقة عن طريق مسح باركود يقوم بتحويل الزائر لصفحة ويب، حيث قمت بإدخال المعلومات التالية:

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

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

وبالفعل قمت بإرسال المعلومات المطلوبة وتلقيت رسالة بأنه سيتم التحقق من المعلومات وصحتها ثم التواصل معي في حال أني ربحت.

وبالفعل ربحت الجائزة كما أسلفت ولكن !

كان لدي فضول، كيف تمت عملية التحقق من الصور؟ 🤔

هل كانت عملية التحقق بطريقة يدوية أو بشرية بالأحرى؟

هل قامور باستخدام تقنية ذكاء صناعي ما ليتحققوا من محتوى الصور؟

في حال كانت الطريقة بشرية، ماذا لو اشترك آلاف المتسابقين ؟! وأرسلوا آلاف الصور؟

هل تم أخذ ذلك بالحسبان من قبل الشركة صاحبة الحملة التسويقية؟

هل تم التخطيط لتخزين كل هذا الكم من المعلومات النصية والصور ثم التحقق من صحتها، ومن ثم الاستجابة بسرعة للمشتركين ؟

لذا قررت أن أقوم بمحاكاة وبناء برمجية سحابية على Azure لتلبية هذه المتطلبات.

هذا هو السيناريو السحابي على Azure من أجل دعم حملة تسويقية وإنجاحها على مستوى عدد كبير من المشتركين بالاستفادة من نمائج الذكاء الصناعي.

أريد من خلال بناء هذا الحل السحابي زيادة رشاقة الأعمال (Business Agility) و وقت الوصول للسوق (Time to Market)! ومساعدة فريق التسويق بالوصول للهدف المنشود من هذه الحملة التسويقية

يمكن الاطلاع على مزيد من السيناريوهات السحابية هنا.

لبناء هذا السيناريو، قمت أولاً بصياغة المتطلبات مستلهماً مماجرى معي في المسابقة التي اشتركت بها.

المتطلبات (Business Requirements)

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

الزبون يجب أن يرسل المعلومات التالية:

• صورة للمنتج الذي قام بشرائه
• صورة لإيصال الشراء
• اسم الشخص ومعلومات التواصل كالبريد الالكتروني ورقم الهاتف المحمول

البرمجية ستقوم بالتحقق من الصور المرسلة كالتالي:

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

في حال نجاح عملية التحقق، الزبون سيصبح مشترك في المسابقة ومؤهل للفوز بالجائزة.

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

إذن يلزمنا بناء بنية تقنية تلبي المتطلبات (business requirements) وتتميز بتحقيق المتطلبات غير الوظيفية :

• الموثوقية (Reliable)
• قابلية التوسع (Scalable)
• الأمان (Secur)
• محسنة بالنسبة للتكلفة (Cost Optimized)

فهذا النظام متوقع أن يعمل خلال الحملة التسويقية بدون فشل ويلبي الزيارات الكثيرة المتوقع حصولها.

الأقسام القادمة في هذه المقالة تهدف لمناقشة البنية التقنية للحل السحابي المنشود من جوانب مختلفة، وبعد ذلك سأوضح كيف يتم بناء بعض أقسامه وخاصة الجزء المتعلق بالذكاء الصنعي.

إذن هيا بنا نقوم بماقشة الأجزاء الرئيسة للبنية التقنية (main components and services) لنتمكن من بناء هذا السيناريو السحابي!

الأجزاء الرئيسة

الأجزاء الرئيسة المتوقعة هي:

• صفحة ويب تتيح للمستخدم الزائر أن يشترك بالمسابقة عن طريق تحميل الصور المطلوبة و معلومات التواصل
• Backend endpoint لاستلام الملفات المرسلة والمعلومات وتخزينها
• مخزن خاص بالملفات التي سيتم رفعها كصور
• خدمة نموذج ذكاء صناعي يقوم بتحديد عبوات المياه و شعار الشركة (اللوغو) ضمن الصور المحملة
• خدمة نموذج ذكاء صنعي لاستخراج النص من إيصالات الشراء المحملة على شكل صور
• قاعدة بيانات لتخزين معلومات التواصل الخاصة بالمشتركين بالمسابقة ونتائج التحقق من الصور التي قاموا بتحميلها
• خدمة سحابية تتيح لنا تطبيق Event-Driven architecture للقيام بتوليد واستقبال عدة أحداث أثناء تواصل خدمات النظام فيما بينها داخلياً لكي نضمن موثوقية النظام

لنقم برسم المخطط الأولي للبنية البرمجية التي نحاول تصميمها :

هذه هي العناصر الرئيسة للبنية البرمجية مبدئياً، سأناقش كل عنصر أو خدمة :

صفحة الويب

وهي تمثل الـ (Frontend) في هذه البنية البرمجية، سيتم تطوير الصفحة بعد طرق لتتيح للزائر إرسال المعلومات إلى المخدم:

1- صفحة ويب تقليدية بسيطة ترسل المعلومات إلى المخدم

وهي صفحة يتم عمل (Render) لها على المخدم أو هي صفحة من نوع Single Page Application وتقوم بمايلي :

1. التحقق من مدخلات الزائر كصحة صيغة رقم الهاتف والبريد الالكتروني والتأكد من ملء كل الحقول المطلوبة
2. ترسل معلومات إلى المخدم
3. تتيح إمكانية تحميل الصور إلى المخدم

هذا كل شيء ببساطة! ثم سيقوم المخدم وهي الجزء الثاني بالتحقق مرة ثانية من المدخلات وتخزين كل المعلومات في مخزن الملفات، قاعدة البيانات.

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

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

2- صفحة الويب ستقوم بتحميل الصور بشكل مباشر لمخزن الملفات

وهي صفحة يتم عمل (Render) لها على المخدم أو هي صفحة من نوع Single Page Application وتقوم بمايلي :

1. التحقق من المدخلات
2. إرسال معلومات التواصل إلى المخدم
3. تحميل الصور بشكل مباشرر إلى مخزن الملفات

بهذه الحالة يجب أن نطلب من المخدم token خاصة لنحصل على سماحية مؤقتة تمكننا من تحميل الملفات على المخزن مباشرة.

هذه الحالة تتميز بأداء وسرعة أفضل من سابقتها لأن البيانات ستحمل فوراً على المخزن الخاص بها دون وجود مخدم وسيط (proxy server) لتعبر من خلاله إلى المخزن.

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

3- صفحة ويب تقوم بالتحقق من محتوى الصور باستخدام نماذج ذكاء صنعي

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

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

وبهذا يمكن توفير تكلفة المعالجة والتحقق والزمن اللازم لها أيضاً

الجزء الخاص بالـ Backend

يوجد العديد من الخيارات المتنوعة لطريقة بناء الـ Backend.

هل نستخدم مخدمات افتراضية Azure Virtual Machines ونقوم باستخدامها كمخدمات ويب لاستقبال طلبات الـ HTTP?

هل نستخدم خدمة Azure App Service الجاهزة والتي لا تستلزم التعامل مع الـVM ?

أو ربما نستخدم Azure functions ?

لماذا لا نفكر باستخدام Kubernetes?

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

سأوضح هذه الفكرة:

• عندما نستخدم خيار من نوعIaaS (Infrastructure as a Service) مثل Azure Virtual Machines، فإننا نحصل على خدمات سحابية أساسية مثل المعالجة، التخزين، الشبكة، الأمان. أما إدارة البنية التحتية ومواردها ورخصات البرمجيات (license) كل ذلك يقع على عاتق مشتري الخدمة.
• عندما نستخدم خيار من نوع PaaS (Platform as a Service) مثل Azure App Service، فإننا نحصل على البنية التحتية مدارة من قبل مزود الخدمة، فالميزات السحابية كقابلية التوسع و التوفر فهي تكون متضمنة، وبالتالي سيركز الزبون ومطوريه على تطوير التطبيق فوق هذه الخدمات.
• في حال استخدمنا الـ Serverless مثل Azure Functions، فإننا نحصل على بنية تحتية جاهزة وميزات سحابية بشكل كامي مضمنة ومدارة من قبل مزود الخدمة السحابية ولا يقوم مشتري الخدمة إلا بكتابة الشفرة البرمجية.

سأعتمد في بناء البنية التقنية على PaaS و Serverless في هذا السيناريو، لأن شركة المياه المعدنية لديها الظروف التالية:

• ليس عند الشركة الإمكانيات التقنية والفريق المتفرغ لإدارة وتشغيل البنية التحتية للخدمات السحابية
• الشركة بحاجة إلى تقليل الزمن اللازم للوصول إلى السوق (time to market) ولابد من تقليل العمليات التشغيلية و زيادة رشاقة فريق التطوير.
• لدنيا بحسب السيناريو شهرين فقط لتطوير الحل قبل بداية الحملة التسويقية والمسابقة

الخلاصة: سيتم التركيز على استثمار خدمات ال PaaS و الـ Serverless functions في كتابة الشفرة البرمجية في الـ Backend

مخزن الملفات

خدمة Azure Blob Storage هي من نوع PaaS تمكن من تخزين البيانات غير المهيكلة (unstructured data) مثل الملفات النصية والثنائية (binary data). في هذا السيناريو من المتوقع أن يكون لدينا مليون مشارك في المسابقة، وكل متسابق سيقوم بتحميل صورتين، لذلك نحن بحاجة لتخزين مليوني صورة ومن ثم التحقق من محتواها.

خدمة Azure Blob storage مهيأة لتخزين كميات هائلة وضخمة من البيانات.

لكن لازال لدينا حاجة لتخزين معلومات الاتصال الخاصة بالمتسابقين أيضاً، والطريقة التقليدية هي بالطبع وجود قاعدة بيانات.

هل يوجد طريقة لتخزين معلومات الاتصال إلى جانب الصور ضمن نفس مخزن الملفات؟

لحسن الحظ! خدمة Azure blob storage لديها ميزة رائعة تدعى “Index Tag”، وهي تمكن من إضافة معلومات مرفقة مع الصورة على شكل key/value.

كذلك نستطيع الاستعلام عن الملفات بحسب القيمة المرفقة معه، ولكن قبل أن يتم البت باستخدام الميزة يجب أن تحقق من عدة أمور:

• يجب أن التأكد أن الميزة متوفرة ضمن الـ Azure Region الذي نفكر باستخدامه، يمكن التحقق عن طريق الرابط هنا.
• يجب التأكد ان ميزة Index-Tag توفر إمكانية التحكم بالوصول للمعلومات لأن معلومات التواصل هي معلومات لها خصوصية

سنتحقق من توفر هذه الشروط لاحقاً، وفي حال توفرها سنقوم بتخزين القيم التالية مع كل صورة:

• اسم المشترك name
• رقم هاتف الجوال phone-number
• قيمة بوليانية تدل على حالة التحقق من الصورة is-verified

الخلاصة سيتم النظر باستخدام خدمة Azure Blob Storage لتخزين ملفات الصور المحملة من المشتركين.

تحديد الأشياء ضمن الصور

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

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

خدمة Azure Custom Vision هي خدمة سحابية تستخدم لإنشاء نموذج مخصص لتحديد الأشياء ضمن الصور. ستفيدنا هذه الخدمة في تحليل صور المنتجات التي تحوي:

• عبوة المياه المعدنية كما هو موضح في الصورة
• شعار الشركة الموجود على العبوة (اللوغو)

سنوقم باستخدام خدمة Custom Vision على مرحلتين: 

• تدريب النموذج حتى يتمكن من تحديد التصنيفات الي نحتاجها عن طريق تزويده ببعض الصور.
• نشر الخدمة البرمجية (API) التي سيتم استخدامها ضمن البنية البرمجية

الخلاصة سيتم النظر في استخدام خدمة Custom Vision لتحديد عبوات المياه والشعار الخاص بالشركة ضمن الصور

استخراج النص من إيصال الشراء

خدمة Form Recognizer في Azure هي خدمة سحابية تتيح إمكانية استخراج النص من صورة إيصال الشراء.

يلزم أن نتحقق من المعلومات التالية بعد استخراجها:

• تاريخ الإيصال
• وجود عنصر واحد من القائمة الشراء يعبر عن أحد منتجات شركة المياه

الخلاصة سيتم النظر باستخدام خدمة Form Recognizer لاستخراج تاريخ الشراء من صورة إيصال الشراء.

قاعدة بيانات لتخزين معلومات الزبائن المشتركين

أعتقد أن الجزء الخاص بالبيانات في هذا السيناريو هو بسيطة نسبياً، لدينا ثلاثة خطوات رئيسية وهي: تخزين البيانات، ثم إرسالها لخدمات الـ AI للتحليل، ثم تخزين النتيجة.

ليس علينا أن نقوم ببناء نظام بينات متقدم للأرشفة أو التقارير المتقدمة، على الأقل في هذه المرحلة.

البيانات الناتجة عن تحليل نماذج الذكاء الصناعي ستكون على شكل JSON لذلك من المفيد التفكير باستخدام قاعدة بيانات non-relational.

الخلاصة سيتم استخدام قاعدة بيانات non-relational أو ميزة الـ Index-Tag في خدمة Azure Account Storage

خدمة Event-Driven

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

إذن ثلاثة خطوات ولكن :

هل على المستخدم النهائي أو المشترك بالمسابقة أن ينتظر حتى تنتهي خطوة التحقق؟

بمعنى آخر هل يجب أن تتأخر استجابة الـ HTTP response حتى تنتهي كل الخطوات ؟

لما لا نقوم بتحميل الصور ثم نعيد رسالة تعبر عن نجاح عملية التحميل ونشرح للمستخدم النهائي أننا سنقوم بتفحص البيانات ونتواصل معك لاحقاً؟

ماذا لو نجحت عملية تحميل الصور ولكن فشلت عملية استدعاء خدمة AI للتحقق ?

هل يجب بهذه الحالة أن تفشل كل العملية؟ ماذا لو تمكننا من استئناف الخطوة الفاشلة فقط؟

لنتمكن من تصميم نظام موثوق وقادر على التعامل مع الأخطاء وتجاوزها نستطيع استخدام أسلوب Event-Driven والذي سيساعد على :

• التعامل بالأحداث (Events)
• فصل أجزاء النظام عن بعضها بحيث لا تكون معتمدة على بعضها بشكل مباشر (Decoupling)
• تمكين أجزاء النظام من التواصل عن طريق الرسائل
• فلترة الأحداث وتوجيهها من مصدر ما إلى خدمة أخرى مهتمة بمعالجة الحدث
• إرسال نفس الرسالة لأكثر من مستقبل
• إمكانية الدمج مع خدمات سحابية متعددة لكي تتعامل مع أحداثها: مثلاً خدمة التخزين سوف تكون مصدر لحدث عندما يتم تحميل صورة ما.

خدمة Event Grid هي خدمة سحابية ذات موثوقية عالية وقادرة علىالتوسع (scalable). وهي تعتبر وسيط لتبادل الأحداث (Serverless event broker) وتمتلك الميزات المذكورة بالقائمة أعلاه.

الخلاصة سيتم استخدام خدمة Event Grid لتطبيق أسلوب Event-Driven Architecture

الآن لنطلع على مخطط البنية التقنية مرة أخرى بعد المناقشة المبدئية لـ event-driven :

اختيار Azure Regions المناسب

لاختيار المنطقة السحابية Azure Region المناسبة يجب أخذ عدة عوامل بعين الاعتبار

• زمن الطلب إلى المخدم أو ما يعرف بمصطلح (Latency)
• توفر الخدمات السحابية التي نفكر باستخدامها (Service Availability)
• الامتثال (Compliance and data residency)
• التكلفة (Pricing)

زمن الطلب إلى المخدم أو ما يعرف بمصطلح (Latency)

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

يمكن معرفة زمن التأخر (Latency) عن طريق الموقع التالي:

https://www.azurespeed.com/Azure/Latency 

كوني في إمارة أبو ظبي قمت بقياس قيمة التأخر بيني وبين عدة مناطق سحابية Regions وبالطبع كانت أقل زمناً بالنسبة لـ UAE North (Dubai).

توفر الخدمات السحابية التي نفكر باستخدامها (Service Availability)

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

https://azure.microsoft.com/en-us/explore/global-infrastructure/products-by-region.

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

ولكن متوفرة في مكان قريب جغرافياً وهو Central India Region وهو بحسب الصورة السابقة لديه زمن (Latency) جيد أيضاً.

أما بقية الخدمات التي أفكر باستخدامها متواجدة بالكامل ضمن الإمارات العربية المتحدة.

الامتثال (Compliance and data residency)

يوجد عدة جوانب يجب الاهتمام بها في هذا المجال:

• سيتم تخزين البيانات بشكل رئيسي في المنطقة UAE North، أما الصور سيتم معالجتها في منقطة Central India كون خدمة Custom Vision ليست متوفرة في UAE regions.
• تخزين معلومات التواصل الخاصة بالزبائن يجب أن يذكر ضمن سياسة الخصوصية وسياسة الاستخدام.

النقاط أعلاه يجب أن تناقش مع الفريق المسؤول عن الجوانب القانونية لتحديث سياسة الخصوصية إن لزم الأمر و كذلك التأكد أنه من المسموح استخدام خدمات سحابية خارج الإمارات العربية المتحدة.

الجدول التالي يلخص الخدمات والمناطق السحابية التي ستسخدم:

Service	UAE North	Central India
Custom Vision	غير متوفرة	متوفرة
Form Recognizer	متوفرة
Account Storage	متوفرة
Azure Function	متوفرة
Event Grid	متوفرة
App Service	متوفرة

تهانينا! لقد انتهينا للتو من البحث الأولي حول الخدمات السحابية التي تناسب السيناريو الذي نحاول تصميمه، فيما يلي المخطط الأولي للبنية التقنية:

نعم ! هذا هو المخطط الأولي، لأن الجزء القادم من هذه التدوينة ستساهم في تحسين كفاءة التصميم وإنضاجه ليناسب السيناريو المستهدف:

Azure Well-Architected إطار العمل

إطار عمل Azure Well-Architected هو عبارة عن مجموعة من المبادئ وأفضل الإجراءات مجمعة ضمن خمس ركائز رئيسة.

هذه الركائز ستساعد على بناء وصيانة حلول سحابية بجودة عالية، لذا سأطبق إطار العمل على البنية التقنية التي أحاول بنائها:

الركائز الخمسة:

• الموثوقية (Reliability)
• الأمان (Security)
• تحسين التكلفة (Cost Optimization)
• تميز العمليات التشغيلية (Operational Excellence)
• كفاءة الأداء (Performance Efficiency)

الموثوقية (Reliability)

يمكن تطبيق الموثوقية بشكل مختلف بناء على نوعية الخدمات السحابية التي تكون البنية التقنية للنظام الذي نحاول بنائه.

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

علينا أن نتأكد من خيارات مستوى الخدمة SLA لكل خدمة سحابية ننوي استخدامها:

الخدمة السحابية	مستوى الخدمة (SLA)
Custom Vision	99.9% SLA link
Form Recognizer	99.9% SLA link Note: I didn’t find a specific SLA for Form Recognizer, but it’s one of Azure Applied AI Services.
Account Storage	99.9% for LRS (locally redundant storage) SLA link
Azure Function (Serverless)	99.95% for consumption plan SLA link
Event Grid (Serverless)	99.99% SLA link
App Service	99.95% SLA link

بناءً على الجدول أعلاه نستطيع القول أن النظام بالمجمل سيتمتع بـ (Availability) 99.9% على مدار العام.

بمعنى آخر يوجد احتمالية فشل للنظام بما يقدر 8.76 ساعات على مدار العام. وكون الحملة التسويقية ستكون لمدة شهر فقط يجب أن نتوقع احتمالية فشل أو توقف النظام لمدة 43.8 دقائق شهرياً.

أعتقد أن هذا الأمر يناسب السيناريو الحالي بشكل كافي.

الأمان (Security)

يمكن تناول مسألة الأمان من 5 جوانب:

الحوكمة و الامتثال (Governance and Compliance)

يمكن الاستفادة من الـ(Built-In Azure Policies) الجاهزة والتي تساعد في جعل البنية التقنية ممتثلة ومتوافقة مع قواعد الأمان المتبعة من قبل الشركة.

الجدول التالي يحوي بعض هذه السياسات الجاهزة والتي يمكن تفعيلها بسهولة في الخدمة السحابية:

سياسات جاهزة (Built-in Azure Policy)	التوصيف
App Service apps should have remote debugging turned off	عادة ما تكون ميزة الـ remote debugging متعلقة ببيئة التطوير البرمجي فقط، لأنها تعتمد على فتح بعض المنافذ التي يجب أن تكون مغلقة على البيئة الحية (production)
App Service app slots should have resource logs enabled	يجب تفعيل كتابة السجلات (logs) لأنها هامة للتقصي عند اللزوم.
App Service app slots should only be accessible over HTTPS	فقط بروتوكول الـ https الآمن مسموح أن يستخدم على البيئة الحية (production) لحماية البيانات أثناء الانتقال بين المخدم والمستخدم النهائي.
Cognitive Services accounts should disable public network access	خدمة Custom Vision و خدمة Form Recognizer يجب منع الوصول لهم عن طريق الانترنت وأن (public access) فهما خدمات داخلية للنظام ويتم استدعائهم بشكل داخلي.
Azure Event Grid domains should disable public network access	خدمة Event Grid يجب منع الوصول لها عن طريق الانترنت أيضاً

يمكن إضافة سياسات أخرى ومخصصة بحسب كل شركة.

إدارة الهوية والوصول (Identity and Access Management)

• سيتم استخدام خدمة Azure Active Directory لإدارة كل ما يتعلق بالهوية و الوصول للموارد

حماية المعلومات والتخزين (Information Protection and Storage)

• يوجد ميزة حماية البيانات (Data Protection at rest) المفعلة بشكل تلقائي.
• سيتم استخدام خدمة Key Vault لتخزين المفاتيح وكلمات المرور وأي نصوص سرية تستخدم للتواصل ضمن النظام.
• استخدام ميزة SAS (Shared Access Signature) مع سماحية القراءة فقط عند تمرير الصور إلى خدمة التحقق (AI APIs).
• التحكم بمن له سماحية الوصول إلى معلومات الـ (Index Tag) المخزنة في ملفات الصور، لأنها معلومات تواصل ولها خصوصية عالية ويجب حمايتها.

أمن الشبكات واحتواء الموارد ضمنها (Network Security and Containment)

• استخدام خدمة الشبكة (Virtual Network) و الشبكات الفرعية (subnets) لفصل الموارد عن بعضها والتحكم في الوصول لها عن طريق مجموعات أمان الشبكة NSGs (Network Security Groups)
• تجنب كشف طبقة الواجهات (frontend layer) للانترنت بشكل مباشر واستخدام بوابة عوضاً عن ذلك (Application Gateway) لأنه يوفر طبقة من الحماية و القدرة على توسع scalability لاحقاً.
• تفعيل خدمة الجدار الناري الخاص بالويب WAF (Web Application Firewall) المتوفر كجزء من Application Gateway للحماية من كل الهجمات التقليدية على الويب
• خدمة DDOS الأساسية أيضاً مفعلة بشكل تلقائي في الخدمة السحابية

العمليات التشغيلية للأمان (Security Operations)

• استخدام خدمة (Azure Advisor)
• إجراء التقييم الخاص بإطار العمل Azure Well-Architected Framework Assessment

تحسين التكلفة (Cost Optimization)

تقدير التكلفة باستخدام Azure Calculator

التكلفة الابتدائية والتي تحوي الموارد الأساسية للنظام متوفرة على الرابط التالي this link.

قمت بالاعتماد على كون الحملة التسويقية تستهدف مليون مستخدم في حساب عدد الملفات المتوقعة :

• أو مليون طلب http request بالنسبة لخدمة Azure Function تكون مجانية وبدون تكلفة، وهذا هو سبب أن القيمة في الصورة أعلاه هي صفر لأننا من غير المحتمل أن يتجاوز النظام هذا العدد.
• خدمة Custom Vision ستكلف 2100 دولار تقريباً من أجل معالجة مليون صورة، يمكن أن نقلل التكلفة هنا بشكل جيد من خلال تصدير نموذج الخدمة ليتم استخدامه ضمن صفحة الويب بدلاً من استخدامه ضمن المخدم، الرابط التالي يشرح تفاصيل أكثر.
• خدمة Form Recognizer ستكلف 10 آلاف دولار وهو الرقم الأعلى من أجل قراءة مليون إيصال شراء، يمكن مناقشة ذلك أيضاً والتأكد أن التكلفة ضمن الميزانية، ويمكن استبدال الخدمة ببدائل أقل تكلفة، الرابط التالي يعطي بعض البدائل.

لازال التقدير الابتدائي للتكلفة لايحو كافة الخدمات التي يجب أن نستخدمها من أجل توفير الأمان، لذلك يجب إضافة الموارد التالية :

• Application Gateway
• Azure Policies
• Key Vault
• Virtual Network
• Private Endpoints

التقدير التالي يحوي تقريباً كل الخدمات التي سيتم استخدامها :

تعريف الميزانية و التنبيهات (Define Budget and Alert)

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

تميز العمليات التشغيلية (Operational Excellence)

لا شك أن العمليات الشتغيلية جزء هام من أي بنية تقنية، سأذكر هنا للاختصار جانب واحد منها فقط، يمكن استخدام خدمة Azure DevOps من أجل توفير :

• CI/CD pipelines
• إدارة المشروع
• تخزين الشفرة البرمجية

كفاءة الأداء (Performance Efficiency)

تم أخذ الكفاءة بعين الاعتبار أثناء تصميم النظام وفيمايلي بعض الأمثلة:

• تم استخدام stateless instances من دون الحفاظ على affinity حيث تقوم خدمة azure functions بالتوسع بناء على كمية الطلبات القادمة.
• تفعيل ميزة التوسع التلقائي في خدمة app service بناء على مدى استخدام المعالج (CPU usage)
• نقل الحمل المتعلق بالعمليات التي تستهلك وقتاً إلى خدمة azure functions تعمل في الخلفية، الأمر الذي سيجعل زمن تسجيل المشتركين زمناً أقصر متعلقاً فقط بزمن تحميل ملفات الصور، أما معالجة وتحليل الصور فسيتم لاحقاً.
• استخدام خدمة Event Grid التي ستمكن من تطبيق أسلوب النظام المقاد بالأحداث (Event-Driven)

الخلاصة

توفر الخدمة ضمن المناطق السحابية

Service	UAE North	Central India
Custom Vision	غير متوفر	متوفر
Form Recognizer	متوفر
Account Storage	متوفر
Azure Function	متوفر
Event Grid	متوفر
App Service	متوفر
Application Gateway	متوفر
Key Vault	متوفر
Application Insight	متوفر

مستوى الخدمة السحابية في Azure

Services	SLA
Custom Vision	99.9% SLA link
Form Recognizer	99.9% SLA link Note: I didn’t find a specific SLA for Form Recognizer, but it’s one of Azure Applied AI Services.
Account Storage	99.9% for LRS (locally redundant storage) SLA link
Azure Function (Serverless)	99.95% for consumption plan SLA link
Event Grid (Serverless)	99.99% SLA link
App Service	99.95% SLA link
Application Gateway	99.95% SLA link
Key Vault	99.99% SLA link

تقدير التكلفة باستخدام الحاسبة

مجمل التكلفة الشهرية تصل إلى $12,812.89، والملاحظ أن خدمات الذكاء الصناعي هي ذات التكلفة الأعلى.

يمكن تحسين التكلفة من خلال الإجراءات التالية:

1. استخدام نموذج الذكاء الصناعي الخاص بتحليل صور العبوات كجزء من صفحة الويب وتوفير تكلفة المعالجة في المخدم : https://feras.blog/using-custom-vision-service-to-detect-objects-in-images
2. البحث عن بديل آخر لخدمة قراءة صور إيصالات الشراء : https://feras.blog/using-form-recognizer-service-to-extract-data-from-receipts

مخطط تصميم البنية التقنية على Azure

الخلاصة:

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