تقنيات الـ Serverless تخدعك بشأن قابلية التوسع
تَعِدُ الحوسبة غير الخادمة (Serverless computing) بقابلية توسع غير محدودة وبدون أي أعباء إضافية. تقوم منصات مثل AWS Lambda أو Google Cloud Run بتوسيع طبقات الحوسبة الخاصة بك فوراً.
ولكن لا تزال الواجهة الخلفية (backend) الخاصة بك تتعرض للانهيار.
المشكلة ليست في الحوسبة، بل المشكلة في قاعدة البيانات الخاصة بك.
عندما تتوسع وظائفك (functions)، فإنها تسبب "عاصفة من الاتصالات" (connection storm). تحاول كل نسخة جديدة من الوظيفة فتح اتصال جديد بقاعدة البيانات. إذا كان لديك 1,000 وظيفة، فسيكون لديك 1,000 طلب اتصال يضرب مثيل Postgres أو MySQL الخاص بك في وقت واحد.
قواعد البيانات العلاقية (Relational databases) لها حدود قصوى. وبمجرد وصولك إلى هذا الحد، ستفشل الاتصالات الجديدة، مما يؤدي إلى زمن وصول عالٍ (high latency) وأخطاء من نوع 5xx. تكون قدرات الحوسبة لديك جاهزة، لكن قاعدة البيانات تنهار تحت الضغط.
يمكنك إصلاح ذلك باستخدام ثلاث استراتيجيات:
استخدم وسيط اتصال (Connection Proxy) لا تقم بتوصيل الوظائف مباشرة بقاعدة البيانات. استخدم وسيطاً مثل AWS RDS Proxy أو Google Cloud SQL Proxy. تعمل هذه الطبقة كفاصل بين وظائفك وقاعدة بياناتك، حيث تدير مجموعة صغيرة من الاتصالات المستمرة وتشاركها بين وظائفك المتعددة.
تنفيذ طبقات وسيطة للبيانات (Data Proxy Layers) تقوم الوسائط المتقدمة بأكثر من مجرد إدارة الاتصالات، حيث يمكنها:
- تقسيم عمليات القراءة والكتابة إلى مثيلات قواعد بيانات مختلفة.
- تخزين الاستعلامات المتكررة مؤقتاً (Cache) لتقليل الحمل على قاعدة البيانات.
- تحسين الاستعلامات قبل وصولها إلى قاعدة البيانات.
- الانتقال إلى عمليات الكتابة غير المتزامنة (Asynchronous Writes) توقف عن جعل كل إجراء يقوم به المستخدم عملية كتابة متزامنة في قاعدة البيانات. فالعديد من المهام لا تتطلب اتساقاً فورياً (instant consistency).
بدلاً من هذا: إجراء المستخدم -> الوظيفة -> كتابة متزامنة في قاعدة البيانات -> الاستجابة
جرب هذا: إجراء المستخدم -> الوظيفة -> دفع الحدث إلى الطابور (Queue) -> استجابة سريعة
يمكن لوظيفة منفصلة بعد ذلك التقاط ذلك الحدث والكتابة في قاعدة البيانات لاحقاً. هذا يحمي قاعدة البيانات الخاصة بك من طفرات حركة المرور المفاجئة.
تتطلب قابلية التوسع الحقيقية ما هو أكثر من مجرد توسيع الحوسبة. يجب عليك التصميم من أجل وصول مرن للبيانات (elastic data access). توقف عن التجهيز بناءً على الحد الأقصى النظري، وابدأ في بناء مخازن مؤقتة (buffers) بين وظائفك التي تشهد طفرات مفاجئة وبياناتك.
المصدر: https://dev.to/prabashanadev/your-serverless-is-lying-to-you-about-scale-4cga