توسيع Milvus التلقائي على Kubernetes باستخدام EC2 والتخزين المستمر المدعوم بـ S3
منصة AI ذات بيانات متجهية (embeddings للبحث والتوصيات و RAG) تنمو بسرعة، كانت بحاجة إلى قاعدة بيانات Milvus المتجهية الخاصة بها للتوسع تلقائيًا بناءً على حمل الاستعلام وحجم البيانات — مع تخزين متين وفعال من حيث التكلفة لا يُفقد إذا أعيد تشغيل pods أو استبدلت العُقد.
ناقش مشروعك
التحدي
عرض تشغيل Milvus على نطاق واسع في الإنتاج العديد من تحديات البنية التحتية:
- سعة ثابتة — لم تتمكن عمليات نشر Milvus الثابتة من التعامل مع ارتفاعات حمل الاستعلام بمقدار 10x خلال ساعات الذروة
- خطر فقدان البيانات — تسببت إعادة تشغيل pods على التخزين المؤقت في إعادة بناء الفهارس التي تستغرق ساعات على المجموعات الكبيرة
- عدم كفاءة التكلفة — يعني التزويد الزائد للحمل الأقصى الدفع مقابل الحوسبة الخاملة 70% من الوقت
- تكاليف التخزين — كانت وحدات تخزين block storage المرتبطة بالأنظمة باهظة الثمن لمجموعات بيانات المتجهات متعددة التيرابايت
- إعادة بناء الفهارس — استغرقت إعادة فهرسة ملايين المتجهات بعد استبدال العقدة ساعات من التوقف
- متانة Multi-AZ — لم يتمكن تخزين Single-AZ من النجاة من فشل منطقة التوفر (AZ)
حلنا
قمنا بنشر Milvus على Kubernetes (EKS) مع Horizontal Pod Autoscaling لعُقد الاستعلام، و Cluster Autoscaler للحوسبة، و Amazon S3 كواجهة خلفية للتخزين المستمر — مما يلغي مخاطر فقدان البيانات ويقلل تكاليف التخزين بنسبة ~80%.
البنية
- التنسيق: Amazon EKS (Elastic Kubernetes Service)
- الحوسبة: أنظمة EC2 (أنواع أنظمة مختلطة) تُدار بواسطة Cluster Autoscaler
- قاعدة بيانات المتجهات: Milvus تم نشرها عبر Helm chart في الوضع الموزع
- تخزين الكائنات: Amazon S3 لملفات الأجزاء (segment files) وملفات الفهرس (index files) واستمرارية binlog
- البيانات الوصفية: etcd cluster لتنسيق Milvus والبيانات الوصفية
- قائمة انتظار الرسائل: تدفق الرسائل لخط أنابيب سجل Milvus
- المراقبة: Prometheus + Grafana لمقاييس Milvus وإشارات التوسيع التلقائي
بنية Milvus الموزعة على Kubernetes
نشر المكونات
يعمل Milvus في الوضع الموزع بأنواع عُقد مخصصة، ويتم نشر كل منها كحمل عمل Kubernetes مع توسيع مستقل:
- عُقد الوكيل (Proxy Nodes) — تتعامل مع اتصالات العميل وتوجيه الطلبات
- عُقد الاستعلام (Query Nodes) — تنفذ عمليات البحث المتجهي وتحمل الأجزاء (segments) في الذاكرة
- عُقد البيانات (Data Nodes) — تتعامل مع مسارات الكتابة وتفريغ الأجزاء (segments) إلى S3
- عُقد الفهرسة (Index Nodes) — تبني فهارس المتجهات وتكتب إلى S3
- المنسق (Coordinator) — تنسيق المجموعة وتخصيص الطوابع الزمنية
- etcd — تخزين البيانات الوصفية واكتشاف الخدمات
- قائمة انتظار الرسائل (Message Queue) — تدفق السجلات وسجل الكتابة المسبقة (write-ahead log)
التوسيع التلقائي الأفقي للـ Pods (HPA)
التوسيع التلقائي لعقدة الاستعلام
عُقد الاستعلام هي الهدف الأساسي للتوسيع — فهي تحمل أجزاء المتجهات في الذاكرة وتنفذ عمليات البحث. يتم توجيه التوسيع بواسطة مقاييس متعددة تشمل استخدام وحدة المعالجة المركزية (CPU utilization)، واستخدام الذاكرة (memory utilization)، وعمق قائمة انتظار الاستعلام (query queue depth)، وزمن استجابة الاستعلام P99. يتم تكوين HPA بنسخ متماثلة (replicas) مناسبة للحد الأدنى/الأقصى، وتوسيع سريع للتعامل مع الارتفاعات، وتوسيع تدريجي للأسفل لتجنب التذبذب.
التوسيع التلقائي لعقدة الفهرسة
تتوسع عُقد الفهرسة بناءً على مهام بناء الفهرس المعلقة — تتوسع صعودًا عندما تحتوي قائمة انتظار البناء على عناصر معلقة، وتتراجع عندما تكون خاملة.
EC2 Cluster Autoscaler
استراتيجية الأنظمة
- مجموعات العقد (Node Groups): مجموعات عُقد متعددة بأنواع أنظمة مختلفة لتحسين التكلفة
- حمل عمل الاستعلام: أنظمة محسّنة للذاكرة لأجزاء المتجهات المخزنة في الذاكرة
- حمل عمل الفهرسة: أنظمة محسّنة للحوسبة لبناء الفهارس كثيفة استخدام وحدة المعالجة المركزية (CPU)
- أنظمة Spot (Spot Instances): عُقد الفهرسة وعُقد البيانات غير الحرجة تعمل على أنظمة Spot لتحقيق وفورات كبيرة
- حسب الطلب (On-Demand): عُقد الاستعلام والمنسقون على أنظمة on-demand لتحقيق الاستقرار
سلوك التوسيع
عندما ينشئ HPA وحدات pods جديدة لا يمكن جدولتها، يقوم Cluster Autoscaler بتوفير أنظمة EC2 جديدة في مجموعة العُقد المناسبة. ثم تقوم عُقد الاستعلام الجديدة بتحميل الأجزاء المخصصة لها من S3 إلى الذاكرة وتبدأ في خدمة الاستعلامات، مع اكتمال عملية التوسيع الكلية في دقائق.
التخزين المستمر المدعوم بـ S3
لماذا S3 بدلاً من Block Storage
يوفر S3 مزايا كبيرة على block storage لـ Milvus:
- تكلفة تخزين أقل بنسبة ~80% لمجموعات البيانات الكبيرة
- متانة 11 تسعة (11-nines durability) مع تكرار multi-AZ مدمج
- توسيع غير محدود بدون تغيير حجم الحجم يدويًا
- مستقل عن الـ Pod — البيانات متاحة دائمًا بغض النظر عن دورة حياة الـ pod أو العقدة
- لا يوجد تقييد بالـ AZ — البيانات متاحة من أي منطقة توفر
تدفق البيانات مع S3
- مسار الكتابة (Write Path): عُقد البيانات تخزن عمليات الإدخال مؤقتًا في الذاكرة، ثم تقوم بتفريغ الأجزاء المختومة إلى S3
- بناء الفهرس (Index Build): عُقد الفهرسة تقرأ الأجزاء من S3، تبني الفهارس، وتكتب ملفات الفهرس مرة أخرى إلى S3
- مسار الاستعلام (Query Path): عُقد الاستعلام تحمل الأجزاء والفهارس من S3، تحملها في الذاكرة، وتقدم الاستعلامات
- الاستعادة (Recovery): عند إعادة تشغيل الـ pod، تقوم عُقد الاستعلام بإعادة تحميل الأجزاء المخصصة من S3 (لا يوجد فقدان للبيانات)
تحسين أداء S3
- ضبط حجم الجزء (Segment size tuning) يوازن بين تكاليف طلب S3 ونضارة البيانات
- التخزين المؤقت المحلي SSD على تخزين أنظمة NVMe يتجنب عمليات القراءة المتكررة من S3 للأجزاء النشطة (hot segments)
- التنزيلات المتوازية تُمكّن التشغيل السريع لعقدة الاستعلام
- سياسات دورة الحياة أرشفة البيانات القديمة إلى طبقات تخزين أرخص
المراقبة وإمكانية الملاحظة
يتضمن النشر مراقبة شاملة عبر Prometheus و Grafana:
- أداء الاستعلام — توزيع زمن الاستجابة، QPS، معدل نجاح ذاكرة التخزين المؤقت
- نظرة عامة على المجموعة (Cluster) — عدد العُقد، حالة الـ pod، استخدام الموارد
- صحة التخزين — استخدام S3، عدد الأجزاء، معدلات التفريغ (flush rates)
- أحداث التوسيع التلقائي — أحداث HPA، توسيع العُقد، زمن استجابة جدولة الـ pod
- التنبيهات — تنبيهات آلية لزمن الاستجابة العالي، خطر OOM، فشل التفريغ، وحدود السعة
الميزات الرئيسية
- HPA لعقدة الاستعلام — توسيع تلقائي يعتمد على CPU، الذاكرة، زمن الاستجابة، وعمق قائمة الانتظار
- EC2 Cluster Autoscaler — توفير عُقد ديناميكي بأنواع أنظمة مختلطة
- استمرارية S3 — متانة 11 تسعة، أرخص بحوالي 80% من block storage، ينجو من فشل AZ
- أنظمة Spot (Spot Instances) — عُقد الفهرسة والبيانات على أنظمة Spot لتحقيق وفورات كبيرة في الحوسبة
- التخزين المؤقت المحلي SSD — التخزين المؤقت NVMe يلغي عمليات القراءة المتكررة من S3 للأجزاء النشطة
- استعادة بدون توقف — إعادة تشغيل الـ pods تعيد تحميل الأجزاء من S3 بدون فقدان للبيانات
- Multi-AZ — تخزين S3 + مجموعات عُقد multi-AZ لتحمل كامل لفشل AZ
- إمكانية الملاحظة — Prometheus + Grafana مع مقاييس خاصة بـ Milvus ورؤية التوسيع التلقائي
النتائج
المكدس التقني
caseStudyDetail.more دراسات الحالة
استكشف المزيد من تطبيقاتنا التقنية
معالجة الفواتير المدعومة بـ AI باستخدام OCR ودمج QuickBooks
كانت شركة متوسطة الحجم تعالج مئات فواتير الموردين شهريًا بحاجة إلى التخلص من إدخال البيانات يدويًا عن طريق استخلاص بيانات الفاتورة تلقائيًا باستخدام AI/OCR ومزامنتها مباشرةً مع QuickBooks للمسك الدفتري وتتبع المدفوعات.
إدراج الإعلانات من جانب العميل (CSAI) مع تحليل علامات SCTE-35 وتكامل مشغلات متعددة المنصات
احتاجت منصة بث الفيديو إلى تطبيق إدراج الإعلانات من جانب العميل (CSAI) عبر تطبيقات الويب والجوال والتلفزيون الذكي المتصل – مما يتيح تجارب إعلانية مخصصة على مستوى الجهاز مع دعم كامل لتفاعل الإعلانات (تراكبات قابلة للنقر، إعلانات مصاحبة، أزرار تخطي) التي لا يمكن لتضمين الإعلانات من جانب الخادم توفيرها.
الأسئلة الشائعة
قامت MicrocosmWorks بتهيئة التحجيم التلقائي الأفقي للـ pods باستخدام مقاييس مخصصة من مُصدّر استخدام الذاكرة المدمج في Milvus، مما يؤدي إلى تشغيل أحداث التوسع الخارجي عندما تتجاوز أي عقدة استعلام 75% من استخدام الذاكرة. يتم إعادة توزيع شرائح المجموعات تلقائيًا عبر العقد الجديدة باستخدام مدير شرائح Milvus، مما يمنع أي عقدة واحدة من أن تصبح عنق زجاجة.
اختارت MicrocosmWorks التخزين المدعوم بـ S3 باستخدام MinIO كطبقة لتخزين الكائنات، لأنه يفصل التخزين عن الحوسبة، مما يسمح لعُقد الاستعلام بالتوسع بشكل مستقل دون الحاجة إلى توفير وحدات تخزين EBS جديدة. تقلل هذه البنية تكاليف التخزين بنسبة 60% تقريباً مقارنة بوحدات تخزين gp3 EBS، مع الحفاظ على أوقات تحميل مقاطع البيانات (segments) من S3 بأقل من 100 مللي ثانية.
قامت MicrocosmWorks بتكوين النشر باستخدام replica sets لكل مكون من مكونات Milvus، بما في ذلك query nodes و index nodes و data nodes، مع pod disruption budgets تضمن الحد الأدنى من التوفر أثناء rolling updates. نظرًا لأن جميع البيانات المستمرة تقيم في S3، يمكن لبديل الـ node الفاشلة الوصول فورًا إلى جميع segments دون data migration.
وجدت MicrocosmWorks أن مثيلات r6i.2xlarge توفر أفضل نسبة تكلفة إلى أداء لأعباء عمل استعلام Milvus، حيث توفر 64 جيجابايت من الذاكرة لتخزين المقاطع مؤقتًا في الذاكرة بسعر فوري تنافسي. لبناء الفهارس المُسرّع بواسطة GPU، قللت مثيلات g5.xlarge المزودة بوحدات GPU من نوع NVIDIA A10G أوقات بناء الفهرس بمقدار 8 أضعاف مقارنة بالبنيات التي تعتمد على CPU فقط.
تقدم MicrocosmWorks مشاريع البنية التحتية لـ Kubernetes بمعدلات 30-50 دولارًا/الساعة، مع نشر Milvus ذاتي التوسع الذي يتضمن تخصيص Helm chart، وتكوين HPA، وتكامل S3، وإعداد المراقبة، ويتطلب عادةً من 150 إلى 250 ساعة. يتوفر الدعم المُدار المستمر لتحسين المجموعة والترقيات بنفس المعدلات بالساعة.
مستعد لتحويل عملك؟
دعنا نناقش كيف يمكننا تطبيق حلول مشابهة لتحدياتك.