توسيع 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 configured horizontal pod autoscaling with custom metrics from Milvus's built-in memory usage exporter, triggering scale-out events when any query node exceeds 75% memory utilization. Collection segments are automatically redistributed across new nodes using Milvus's segment manager, preventing any single node from becoming a bottleneck.
MicrocosmWorks selected S3-backed storage using MinIO as the object storage layer because it decouples storage from compute, allowing query nodes to scale independently without provisioning new EBS volumes. This architecture reduces storage costs by approximately 60% compared to gp3 EBS volumes while maintaining sub-100ms segment load times from S3.
MicrocosmWorks configured the deployment with replica sets for each Milvus component, including query nodes, index nodes, and data nodes, with pod disruption budgets ensuring minimum availability during rolling updates. Since all persistent data resides in S3, a failed node's replacement can immediately access all segments without data migration.
MicrocosmWorks found that r6i.2xlarge instances provide the optimal cost-to-performance ratio for Milvus query workloads, offering 64GB of memory for in-memory segment caching at a competitive spot price. For GPU-accelerated index building, g5.xlarge instances with NVIDIA A10G GPUs reduced index build times by 8x compared to CPU-only builds.
MicrocosmWorks delivers Kubernetes infrastructure projects at rates of $30-$50/hr, with a Milvus autoscaling deployment including Helm chart customization, HPA configuration, S3 integration, and monitoring setup typically requiring 150-250 hours. Ongoing managed support for cluster optimization and upgrades is available at the same hourly rates.
مستعد لتحويل عملك؟
دعنا نناقش كيف يمكننا تطبيق حلول مشابهة لتحدياتك.