קנה מידה אוטומטי של Milvus ב-Kubernetes עם אחסון עמיד מבוסס EC2 ו-S3
פלטפורמת AI עם נתוני וקטור גדלים במהירות (הטמעות לחיפוש, המלצות ו-RAG) נזקקה למסד הנתונים הווקטורי Milvus שלה לקנה מידה אוטומטי בהתבסס על עומס שאילתות ונפח נתונים — עם אחסון עמיד וחסכוני שלא יאבד במקרה של הפעלה מחדש של pods או החלפת nodes.
דון בפרויקט שלך
האתגר
הפעלת Milvus בקנה מידה רחב בפרודקשן הציגה מספר אתגרי תשתית:
- קיבולת קבועה — פריסות Milvus סטטיות לא יכלו לטפל בזינוקים של פי 10 בעומס שאילתות בשעות שיא
- סיכון לאובדן נתונים — הפעלה מחדש של Pods על אחסון נדיף גרמה לבנייה מחדש של אינדקסים שנמשכה שעות באוספים גדולים
- חוסר יעילות בעלויות — הקצאת יתר לעומס שיא משמעה תשלום עבור כוח חישוב סרק ב-70% מהזמן
- עלויות אחסון — נפחי אחסון בלוקים המקושרים ל-instances היו יקרים עבור מערכי נתונים וקטוריים של מספר טרה-בייט
- בנייה מחדש של אינדקסים — בנייה מחדש של אינדקסים עבור מיליוני וקטורים לאחר החלפת node ארכה שעות של השבתה
- עמידות מרובת אזורי זמינות (AZ) — אחסון באזור זמינות (AZ) יחיד לא יכול היה לשרוד כשלים באזור זמינות
הפתרון שלנו
פרסנו Milvus ב-Kubernetes (EKS) עם Horizontal Pod Autoscaling עבור nodes של שאילתות, Cluster Autoscaler עבור כוח חישוב, ו-Amazon S3 כקצה אחורי לאחסון עמיד — מה שהעלים את הסיכון לאובדן נתונים והפחית את עלויות האחסון בכ-80%.
ארכיטקטורה
- תזמור: Amazon EKS (Elastic Kubernetes Service)
- חישוב: EC2 instances (סוגי instance מעורבים) מנוהלים על ידי Cluster Autoscaler
- מסד נתונים וקטורי: Milvus פרוס באמצעות Helm chart במצב מבוזר
- אחסון אובייקטים: Amazon S3 עבור קובצי מקטעים (segment files), קובצי אינדקסים, ועמידות binlog
- מטא-דאטה: etcd cluster לתיאום ומטא-דאטה של Milvus
- תור הודעות: הזרמת הודעות עבור Milvus log pipeline
- ניטור: Prometheus + Grafana עבור מדדי Milvus ואותות קנה מידה אוטומטי
ארכיטקטורת Milvus מבוזרת ב-Kubernetes
פריסת רכיבים
Milvus פועלת במצב מבוזר עם סוגי node ייעודיים, כל אחד פרוס כעומס עבודה של Kubernetes עם קנה מידה עצמאי:
- Proxy Nodes — מטפלים בחיבורי לקוח ובניתוב בקשות
- Query Nodes — מבצעים חיפושי וקטורים וטוענים מקטעים לזיכרון
- Data Nodes — מטפלים בנתיבי כתיבה ושולפים מקטעים ל-S3
- Index Nodes — בונים אינדקסים וקטוריים וכותבים ל-S3
- Coordinator — תיאום cluster והקצאת חותמות זמן
- etcd — אחסון מטא-דאטה וגילוי שירותים
- תור הודעות — הזרמת לוגים ו-write-ahead log
קנה מידה אוטומטי אופקי של Pods (HPA)
קנה מידה אוטומטי של Query Node
Query nodes הם יעד הקנה מידה העיקרי — הם טוענים מקטעים וקטוריים לזיכרון ומבצעים חיפושים. קנה המידה מונע על ידי מספר מדדים הכוללים ניצול CPU, ניצול זיכרון, עומק תור שאילתות, ו-P99 query latency. ה-HPA מוגדר עם min/max replicas מתאימים, scale-up מהיר לטיפול בזינוקים, ו-scale-down הדרגתי כדי למנוע תנודתיות.
קנה מידה אוטומטי של Index Node
Index nodes מתאימים את קנה המידה שלהם בהתבסס על משימות בניית אינדקסים ממתינות — מתרחבים כאשר לתור הבנייה יש פריטים ממתינים וחוזרים לקנה מידה קטן יותר כשהם לא פעילים.
EC2 Cluster Autoscaler
אסטרטגיית Instance
- קבוצות Node: מספר קבוצות node עם סוגי instance שונים לאופטימיזציה של עלויות
- עומס עבודה של שאילתות: instances ממוטבי זיכרון עבור מקטעים וקטוריים בזיכרון
- עומס עבודה של אינדקסים: instances ממוטבי חישוב עבור בניית אינדקסים עתירת CPU
- Spot Instances: Index nodes ו-data nodes שאינם קריטיים פועלים על Spot Instances לחסכון משמעותי
- On-Demand: Query nodes ו-coordinators על on-demand instances ליציבות
התנהגות קנה מידה
כאשר HPA יוצר pods חדשים שלא ניתן לתזמן, ה-Cluster Autoscaler מספק EC2 instances חדשים בקבוצת ה-node המתאימה. לאחר מכן, ה-query nodes החדשים טוענים את המקטעים שהוקצו להם מ-S3 לזיכרון ומתחילים לשרת שאילתות, כאשר תהליך ה-scale-up כולו מסתיים תוך דקות.
אחסון עמיד מבוסס S3
מדוע S3 במקום Block Storage
S3 מספק יתרונות משמעותיים על פני Block Storage עבור Milvus:
- עלות אחסון נמוכה בכ-80% עבור מערכי נתונים גדולים
- עמידות של 11 תשיעיות (11-nines durability) עם שכפול מרובה אזורי זמינות (multi-AZ) מובנה
- קנה מידה בלתי מוגבל ללא שינוי ידני של גודל נפח
- בלתי תלוי ב-Pod — נתונים זמינים תמיד ללא קשר למחזור החיים של ה-pod או ה-node
- ללא נעילת AZ — נתונים נגישים מכל אזור זמינות
זרימת נתונים עם S3
- נתיב כתיבה: Data nodes חוצצים הכנסות בזיכרון, ואז שולפים מקטעים אטומים ל-S3
- בניית אינדקס: Index nodes קוראים מקטעים מ-S3, בונים אינדקסים, וכותבים קובצי אינדקסים בחזרה ל-S3
- נתיב שאילתות: Query nodes מורידים מקטעים ואינדקסים מ-S3, טוענים אותם לזיכרון, ומשרתים שאילתות
- שחזור: בהפעלה מחדש של pod, ה-query nodes מורידים מחדש מקטעים שהוקצו מ-S3 (ללא אובדן נתונים)
אופטימיזציית ביצועי S3
- כוונון גודל מקטע מאזן בין עלויות בקשות S3 לרעננות נתונים
- אחסון SSD מקומי בזיכרון מטמון על אחסון instance מסוג NVMe מונע קריאות S3 חוזרות ונשנות למקטעים חמים
- הורדות מקבילות מאפשרות הפעלה מהירה של query node
- מדיניות מחזור חיים מארכבות נתונים ישנים לשכבות אחסון זולות יותר
ניטור ויכולת תצפית (Observability)
הפריסה כוללת ניטור מקיף באמצעות Prometheus ו-Grafana:
- ביצועי שאילתות — התפלגות השהיה, QPS, שיעור פגיעות מטמון
- סקירת Cluster — ספירת Node, סטטוס pod, ניצול משאבים
- תקינות אחסון — שימוש ב-S3, ספירת מקטעים, קצבי פליטה (flush rates)
- אירועי קנה מידה אוטומטי — אירועי HPA, קנה מידה של node, השהיית תזמון pod
- התראות — התראות אוטומטיות על השהיה גבוהה, סיכון OOM, כשלים בפליטה (flush failures) ומגבלות קיבולת
תכונות עיקריות
- HPA של Query Node — קנה מידה אוטומטי המבוסס על CPU, זיכרון, השהיה ועומק תור
- EC2 Cluster Autoscaler — הקצאת node דינמית עם סוגי instance מעורבים
- עמידות S3 — עמידות של 11 תשיעיות (11-nines durability), זול יותר בכ-80% מאחסון בלוקים, שורד כשלים ב-AZ
- Spot Instances — Index nodes ו-data nodes על Spot לחסכון משמעותי בכוח חישוב
- מטמון SSD מקומי — שמירה במטמון NVMe מבטלת קריאות S3 חוזרות למקטעים חמים
- שחזור ללא השבתה — הפעלה מחדש של Pods טוענת מחדש מקטעים מ-S3 ללא אובדן נתונים
- Multi-AZ — אחסון S3 + קבוצות node מרובות AZ לסבילות מלאה לכשלי AZ
- יכולת תצפית (Observability) — Prometheus + Grafana עם מדדים ספציפיים ל-Milvus ונראות קנה מידה אוטומטי
תוצאות
מחסנית טכנולוגית
caseStudyDetail.more מקרי בוחן
גלה עוד מהיישומים הטכניים שלנו
עיבוד חשבוניות מבוסס AI עם OCR ושילוב QuickBooks
עסק בגודל בינוני שעיבד מאות חשבוניות ספק בחודש נזקק לביטול הזנת נתונים ידנית על ידי חילוץ אוטומטי של נתוני חשבוניות באמצעות AI/OCR וסנכרונם ישירות ל-QuickBooks לצורך הנהלת חשבונות ומעקב תשלומים.
הזרקת פרסומות בצד הלקוח (CSAI) עם ניתוח סמני SCTE-35 ושילוב נגן מרובה פלטפורמות
פלטפורמת הזרמת וידאו נזקקה ליישם הזרקת פרסומות בצד הלקוח (CSAI) על פני יישומי אינטרנט, מובייל וטלוויזיות חכמות — המאפשרת חוויות פרסום מותאמות אישית ברמת המכשיר עם תמיכה מלאה באינטראקציה עם פרסומות (שכבות-על ניתנות ללחיצה, באנרים נלווים, כפתורי דילוג) שאותן הזרקה בצד השרת אינה יכולה לספק.
שאלות נפוצות
MicrocosmWorks הגדירה horizontal pod autoscaling עם מדדים מותאמים אישית מ-exporter מובנה לשימוש בזיכרון של Milvus, המפעיל אירועי scale-out כאשר כל צומת שאילתה עולה על 75% ניצול זיכרון. סגמנטים של אוספים מופצים מחדש אוטומטית על פני צמתים חדשים באמצעות מנהל הסגמנטים של Milvus, מונע מצומת בודד להפוך לצוואר בקבוק.
MicrocosmWorks בחרה ב-S3-backed storage תוך שימוש ב-MinIO כשכבת ה-object storage, מכיוון שהוא מפריד את ה-storage מה-compute, ומאפשר ל-query nodes להתרחב באופן עצמאי ללא provisioning של EBS volumes חדשים. ארכיטקטורה זו מפחיתה את עלויות ה-storage בכ-60% בהשוואה ל-gp3 EBS volumes, תוך שמירה על זמני segment load times מ-S3 הקצרים מ-100 מילישניות.
MicrocosmWorks הגדירה את הפריסה עם replica sets עבור כל רכיב Milvus, כולל query nodes, index nodes, ו-data nodes, עם pod disruption budgets המבטיחים זמינות מינימלית במהלך rolling updates. מכיוון שכל ה-persistent data שוכנים ב-S3, התחליף של צומת כושל יכול לגשת מיידית לכל ה-segments ללא data migration.
MicrocosmWorks מצאה כי r6i.2xlarge instances מספקות את יחס העלות-ביצועים האופטימלי עבור Milvus query workloads, המציעות זיכרון בנפח 64GB עבור in-memory segment caching במחיר Spot תחרותי. עבור GPU-accelerated index building, g5.xlarge instances עם NVIDIA A10G GPUs הפחיתו את זמני בניית האינדקס פי 8 בהשוואה לבנייה מבוססת CPU בלבד.
MicrocosmWorks מספקת פרויקטי תשתית ל-Kubernetes בתעריפים של 30-50 דולר לשעה. פריסת Milvus עם קנה מידה אוטומטי (autoscaling), הכוללת התאמה אישית של Helm chart, הגדרת HPA, אינטגרציה עם S3 והגדרת ניטור, דורשת בדרך כלל 150-250 שעות עבודה. תמיכה מנוהלת שוטפת לאופטימיזציה ושדרוגים של האשכול זמינה באותם תעריפים שעתיים.
מוכן לשנות את העסק שלך?
בואו נדון כיצד נוכל ליישם פתרונות דומים לאתגרים שלך.