بوت فيديو بُني بالبرمجة بالذكاء الاصطناعي تعثّر عند المستخدم الثاني: كيف وصل إلى ستة خوادم VPS

تنجح البرمجة بالذكاء الاصطناعي، أو vibe coding، ما دام للمشروع مستخدم واحد، وهذا المستخدم هو أنت. روى أحد مطوري UNIQ على Habr كيف تحوّل بوت Telegram أنشأه صديق بمساعدة الذكاء الاصطناعي إلى خدمة يمكن بيعها بثقة. والخلاصة الأساسية: كتابة الكود سريعة، لكن تحديد السلوك الصحيح للنظام مسؤوليتك أنت.

كيف بدأ المشروع وأين تعطّل

يستقبل UNIQ فيديو وينتج منه نسخة واحدة إلى عشر نسخ لإعادة النشر: يغيّر FFmpeg إعدادات الإطار والإيقاع والألوان والصوت. كُتب النموذج الأولي بلغة Python مع SQLite، وكان يعمل على جهاز Mac الخاص بمنشئه. ظهرت المشكلة الأولى في مساحة القرص: فالطلب الواحد يحتفظ في الوقت نفسه بالملف الأصلي والملفات المؤقتة والنسخ النهائية. لذلك أضاف المطورون حدًا أقصى للرفع يبلغ 150 ميغابايت، وميزانية لمساحة القرص، وآلية تنظيف.

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

طابور مهام يصمد أمام الأعطال

لتوزيع المهام على عدة خوادم، اختاروا PostgreSQL: قاعدة بيانات مشتركة، ومعاملات، وأقفال على الصفوف باستخدام FOR UPDATE SKIP LOCKED. تُسنَد المهمة إلى عملية تنفيذ بموجب مهلة تأجير. وإذا علقت العملية، تتولى أخرى الطلب بعد انتهاء المهلة. ولمنع العملية الأولى من الكتابة فوق النتيجة إذا استعادت نشاطها، يُنشأ رمز ملكية جديد عند كل إسناد، ويُتحقق منه عند كل كتابة لحالة المهمة.

تُحفَظ خطة التأثيرات مسبقًا، وتُسجَّل النسخ المكتملة في نقطة استئناف، أو checkpoint، كي تواصل عملية التنفيذ الثانية من موضع التعطل. وإذا تكرر طلب بالمعرّف نفسه، يعيد النظام إيصال التنفيذ المحفوظ بدلًا من إجراء العملية من جديد. ويوضح المطورون حدود هذه الآلية بصراحة: إذا أُرسل الملف إلى Telegram ولم يُحفَظ سجل الإرسال في الوقت المناسب، فقد تصل النسخة مرتين. فضمان عدم تكرار الأثر داخل النظام لا يمنح واجهة API خارجية ضمان التنفيذ مرة واحدة بالضبط، أو exactly-once.

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

جاء التحسن الملموس للمستخدم من إعادة تنظيم العمل: فُصل الترميز عن التسليم، وأصبحت النسخ تُرسل واحدة تلو الأخرى. في تجربة على بيئة اختبار محلية، وصلت النسخ بعد 40 و70 و105 و136 و171 ثانية، أي إن النسخة الأولى ظهرت قبل اكتمال الطلب بـ131 ثانية.

أرقام الأحمال وحدود دلالتها

بعد نقل الفيديوهات إلى S3 وإضافة PgBouncer، بما يصل إلى 2000 اتصال من العملاء مقابل 10 اتصالات بالخادم، بدأ المطورون قياس مواطن الاختناق. استغرقت دفعة من 1000 تأكيد للطلبات 5.9 ثانية، فيما بلغ مجموع أزمنة الانتظار على قفل SQL واحد نحو أربعين ثانية. استُبدل القفل الحصري العام بأقفال لكل مستخدم، فانخفض زمن الدفعة إلى 3.2 ثانية.

لم تؤدِّ زيادة مجمّع اتصالات التطبيق من 8 إلى 16 اتصالًا، مع بقاء حد PgBouncer عند 10، إلى أي تسريع؛ بل انتقل طابور الانتظار إلى موضع آخر فحسب. وبلغ ترميز 20 فيديو قصيرًا بدقة 720×1280 على 5 وحدات CPU سقف الأداء عند 4–5 عمليات تنفيذ، بنحو 29 مهمة في الدقيقة. أما تشغيل اثنتي عشرة عملية فاستهلك 3133 ميبيبايت من الذاكرة، وكان أبطأ من تشغيل خمس عمليات.

عولجت أول 10 000 مرة استدعاء للقائمة بلا أخطاء، لكن زمن الاستجابة عند المئين الخامس والتسعين، p95، بلغ نحو 30 ثانية. ويشير المطورون بحق إلى أن قبول الطلب والرد السريع على المستخدم أمران مختلفان.

ما الذي يمكن الاستفادة منه

قِيست هذه الأرقام باستخدام فيديوهات قصيرة وعلى بيئة اختبار محددة، ولا يمكن تعميمها على فيديوهات طويلة بدقة 1080p أو استنتاج عدد المستخدمين منها. لكن الأسئلة التي تطرحها تصلح لكل مشروع: من يحجب من؟ أين تُحفَظ الحالة؟ ماذا يحدث إذا تعطلت عملية التنفيذ في منتصف الطلب؟ وماذا يحدث عند تكرار حدث دفع؟ يكتب الذكاء الاصطناعي الكود بسرعة، لكن عليك أن تصوغ إجابات هذه الأسئلة وتتحقق منها بالاختبارات، ويفضل أن تفعل ذلك قبل وصول المستخدم الثاني.