5 خدمات AWS أصلية يمكنها بناء نظام أساسي بدون خادم من البداية إلى النهاية

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

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

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

للحفاظ على أفضل أداء بمرور الوقت ، أنت بحاجة إلى حل قياس تلقائي يقوم تلقائيًا بقياس موارد الخادم.

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

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

إن أتمتة العمليات من خلال الخدمات السحابية بدون خادم هو ما يجعل الهندسة التي لا تحتاج إلى خادم تبرز. يربط الخدمات وينتج نتائج مشابهة لخوادم المجموعة التقليدية.

هذا مثال على بناء مثل هذه البنية باستخدام خدمات AWS الأصلية فقط.

انتقاء تدفق الخدمات بدون خادم

تخيل أنك ترغب في إنشاء نظام أساسي لجمع البيانات والصور (أو الصور) المختلفة للبنية التحتية لبعض الأصول الملموسة (يمكن أن يكون هذا أي أصل تصنيع أو مرفق).

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

دعونا نفحص أي مكونات معمارية يمكن أن تتضمنها.

حاويات AWS S3

المصدر: aws.amazon.com

تُعد حاويات Amazon S3 طريقة رائعة لتخزين الملفات أو الصور في سحابة AWS. سعر التخزين على دلو S3 منخفض بشكل ملحوظ. علاوة على ذلك ، يؤدي تقديم سياسة دورة حياة حاوية S3 إلى خفض هذا السعر بشكل أكبر.

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

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

دلو S3 ليس خادمًا حسب التصميم. إنها ببساطة مساحة تخزين لبياناتك.

قاعدة بيانات AWS Athena

المصدر: aws.amazon.com

تجعل أثينا من السهل إنشاء بحيرة بيانات أساسية من AWS. إنها قاعدة بيانات بدون خوادم تستخدم حاوية S3 لتخزين بياناتها. يتم الحفاظ على تنظيم البيانات من خلال تنسيقات ملفات منظمة مثل ملفات باركيه أو ملفات قيم مفصولة بفواصل (CSV). يحتفظ دلو S3 بالملفات ، وتشير أثينا إليها كلما حددت العمليات البيانات من قاعدة البيانات.

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

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

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

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

قاعدة بيانات AWS Aurora

المصدر: aws.amazon.com

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

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

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

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

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

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

تتم إدارة Aurora بدون خادم بالكامل بواسطة AWS ولا تتطلب مشرفًا.

AWS Amplify

يوفر Amplify نظامًا أساسيًا بدون خادم للنشر السريع للتطبيقات الأمامية المصممة باستخدام مكتبات JavaScript و React. ليست هناك حاجة لإعداد خوادم الكتلة. استخدم وحدة تحكم AWS لنشر الكود مباشرةً ، أو استخدم خط أنابيب DevOps الآلي.

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

وظائف خطوة AWS

المصدر: aws.amazon.com

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

توفر وظائف AWS Step أفضل حل على سحابة AWS. تشكل القائمة المتصلة بوظائف AWS Lambda وظيفة الخطوة. تعمل هذه الوظائف على إنشاء مخطط انسيابي له حالات بداية ونهاية واضحة. تُعد وظيفة lambda ، التي تُكتب عادةً بلغات Python أو Node JS ، جزءًا قابلاً للتنفيذ من التعليمات البرمجية التي تعالج كل ما هو مطلوب.

فيما يلي مثال على كيفية تنفيذ دالة خطوة:

تقوم AWS بتشغيل وظيفة lambda تلقائيًا عندما يأتي ملف جديد في مجلد S3. بعد تحليل الملف ، تقوم lambda بتحميله في أثينا. يخزن lambda نتائجه إما بتنسيق CSV في حاوية S3 (أو في جدول تتبع قاعدة البيانات) قبل الإغلاق.

ثم يتم استخدام هذه النتيجة بواسطة لامدا التالية لتنفيذ الخطوات التالية. قد يشمل ذلك استدعاء نموذج التعلم الآلي وتحويل مجموعة فرعية من البيانات الجديدة إلى جداول موحدة. يمكن أن تكون الخطوة الأخيرة هي تحميل البيانات إلى قاعدة بيانات Aurora.

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

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

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

الكلمات الأخيرة

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

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

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

بعد ذلك ، تحقق من أفضل قواعد البيانات بدون خادم للتطبيقات الحديثة.