أعلنت Cloudflare عن التوفر العام (GA) لدعم Hyperdrive لقواعد بيانات MySQL، وذلك بعد عام من إطلاقه في مرحلة البيتا. يمثل هذا الإنجاز خطوة مهمة، فقد استلزم الأمر إصلاح حوالي 20 خطأً للوصول إلى هدف Cloudflare المتمثل في تحقيق توفر بنسبة 99.99% لهذا المنتج.
Hyperdrive هو مجمع اتصالات قواعد بيانات موزع يربط Cloudflare Workers بقواعد بيانات SQL. وظيفته الرئيسية هي الحفاظ على اتصالات SQL دافئة ومفتوحة عبر شبكة Cloudflare العالمية، ومشاركتها بين العديد من طلبات Workers. بالإضافة إلى تجميع الاتصالات، يمكن لـ Hyperdrive أيضًا تخزين الاستعلامات الشائعة مؤقتًا في ذاكرة التخزين المؤقت لشبكة CDN العالمية، مما يقلل من زمن الوصول ويخفف الحمل على قاعدة البيانات الأصلية. هذه الميزة حيوية لمنصات الحوسبة بلا خادم مثل Workers، حيث إن إنشاء اتصال لكل طلب يمكن أن يكون غير عملي بسبب زمن الوصول وتكاليف الموارد.
رحلة إلى الاستقرار
واجه فريق Cloudflare العديد من التحديات خلال مرحلة البيتا. أحد أول المشكلات المبلغ عنها كانت تتعلق بعرض رموز الإيموجي بشكل غير صحيح. تم تحديد المشكلة في ترميز الأحرف، حيث كان Hyperdrive يستخدم «utf8» الذي هو اسم مستعار لـ «utf8mb3» الذي يدعم ما يصل إلى 3 بايتات لكل نقطة ترميز Unicode، بينما يتطلب الدعم الكامل لـ UTF-8 ما يصل إلى 4 بايتات. تم حل ذلك بتغيير بروتوكول المصافحة لاستخدام «utf8mb4».
ظهرت مشكلة أخرى ذات صلة بالترميز عند إضافة وظيفة تنظيف الاتصال عبر أمر «COM_RESET_CONNECTION». هذا الأمر مصمم لمسح أي حالة جلسة في اتصال معين، وهو أمر ضروري لضمان عدم تسرب أي حالة على مستوى الجلسة بين عمليات الاستعارة. ولكن إضافة هذه الخطوة تسببت في مشاكل ترميز مرة أخرى، حيث لم يعد «COM_RESET_CONNECTION» يعيد تعيين حالة الاتصال إلى الترميز المتفاوض عليه عند بدء الاتصال، بل يعيد الاتصال إلى إعدادات الخادم الافتراضية. كان الحل هو تنفيذ أمر لتعيين الترميز دائمًا إلى «utf8mb4» بعد كل إعادة تعيين للاتصال.
تحدي خطأ التخزين المؤقت المعقد
أبلغ أحد عملاء MySQL ذوي الحجم الكبير خلال مرحلة البيتا عن معدل صغير ولكنه ثابت من استجابات الاستعلامات الفارغة، على الرغم من توقع استجابة غير فارغة دائمًا. حدث هذا الخطأ بنسبة 0.001% من الوقت، مما جعله صعب التتبع للغاية. لكن مفتاح الحل كان في أن هذا الخطأ كان يحدث فقط في مثيلات Hyperdrive التي تم تمكين التخزين المؤقت فيها، مما وجه التحقيق نحو مشكلات محتملة في آلية التخزين المؤقت لـ MySQL في Hyperdrive.
يتكون Hyperdrive من بنية مقسمة بعقدتين: العميل (Client) والنقطة النهائية (Endpoint). تعمل عقدة العميل على نفس الجهاز الذي يستضيف Worker الخاص بالمستخدم، وتتولى التخزين المؤقت المحلي (إذا تم تمكينه)، وتقوم بإعادة توجيه الاستعلامات إلى النقطة النهائية إذا لزم الأمر. أما عقدة النقطة النهائية، فتحتوي على مجمع الاتصالات وتوضع في مركز البيانات الأقرب إلى قاعدة البيانات الأصلية. يستخدم كل من العميل والنقطة النهائية ذاكرة التخزين المؤقت لشبكة Cloudflare CDN المحلية لمركز البيانات الذي يعملان فيه. وإذا كانت العقدتان تعملان في نفس مركز البيانات، فإنهما تشتركان في ذاكرة تخزين مؤقت واحدة.
كشف الغوص في بروتوكول MySQL بين العميل والخادم عن بعض التعقيدات. Hyperdrive يعمل كعميل لقاعدة البيانات الأصلية وكخادم لـ Worker، مما يتطلب منه ترجمة إمكانيات البروتوكول. وجد الفريق أن مكتبة عميل MySQL شائعة لـ Node.js تسمى «mysql2» لا تدعم حاليًا خاصية «CLIENT_DEPRECATE_EOF»، التي تغير طريقة إنهاء مجموعات النتائج. يدعم خادم MySQL 5.7.5 والإصدارات الأحدث هذه الخاصية. يقوم Hyperdrive بتعديل سلوكه لدعم الإمكانيات التي يتوقعها برنامج تشغيل MySQL الخاص بـ Worker، وهذا يعني إعادة كتابة مجموعات النتائج لتضمين حزم EOF وترجمة جميع حزم OK إلى EOF عند الضرورة. في النهاية، كان الخطأ ناتجًا عن افتراض خاطئ في رمز التخزين المؤقت للعميل في Hyperdrive، تم تبنيه في الأصل من تنفيذ التخزين المؤقت لـ Postgres، بأن البايتات المخزنة مؤقتًا يمكن إرجاعها تمامًا كما تمت كتابتها.
ماذا يعني هذا للمطورين؟ يعني التوفر العام لدعم MySQL في Cloudflare Hyperdrive أن المطورين يمكنهم الآن الاعتماد على اتصال قواعد بيانات أكثر استقرارًا وموثوقية لتطبيقاتهم المبنية على Workers. بفضل هذه الإصلاحات، يمكن للمطورين الاستفادة من مزايا التخزين المؤقت وتقليل زمن الوصول التي يوفرها Hyperdrive دون القلق بشأن المشكلات المعقدة في ترميز الأحرف أو الأخطاء النادرة في التخزين المؤقت. برأينا، هذه التحسينات تعزز مكانة Cloudflare كمنصة قوية للمطورين، مما يسهل عليهم بناء تطبيقات ويب عالية الأداء.
المصدر: blog.cloudflare.com