AI Service Mesh: כשעשרות מיקרו-שירותים צריכים לדבר עם AI בבטחה

מאת צוות מדיה דיל · 04.08.2026 · Enterprise AI · 7 דק׳

כשמיקרו-שירותים רבים קוראים למודלי AI - זה מזה ומול ספקים חיצוניים - צריך יותר מגייטוויי מרכזי אחד. מדריך לבניית service mesh שמנהל תעבורת AI מבוזרת עם sidecars ומדיניות מבוזרת.

גייטוויי מרכזי פותר יפה את הבעיה של "עשרות צוותים קוראים למודל חיצוני". אבל בארגונים עם ארכיטקטורת מיקרו-שירותים עמוקה - מאות שירותים, חלקם קוראים למודלים ישירות, חלקם קוראים לשירותי AI פנימיים שבעצמם קוראים למודלים אחרים - נקודת כניסה יחידה (single gateway) הופכת לצוואר בקבוק וגם לנקודת כשל בודדת. AI Service Mesh לוקח את העקרונות שהפכו פופולריים דרך Istio ו-Linkerd בעולם המיקרו-שירותים הכללי - sidecar proxies, mTLS מבוזר, traffic shaping - ומיישם אותם ספציפית על תעבורת AI, כך שהמדיניות נאכפת ליד כל שירות, לא רק בשער כניסה מרכזי אחד.

ההבדל המהותי מ-Enterprise Model Gateway הוא טופולוגי: גייטוויי הוא נקודת כניסה יחידה (hub-and-spoke) שכל תעבורה עוברת דרכה; מש (mesh) הוא רשת מבוזרת שבה כל שירות מקבל sidecar משלו שאוכף מדיניות מקומית, ותקשורת בין שירותים (כולל שירותי AI פנימיים שקוראים זה לזה) גם היא עטופה במדיניות - לא רק תעבורה שיוצאת אל ספק חיצוני.

הבעיה: תעבורת AI פנימית שאף גייטוויי מרכזי לא רואה

בארכיטקטורת מיקרו-שירותים בשלה, לא כל קריאת AI יוצאת ישירות לספק חיצוני - הרבה קריאות הן פנימיות: שירות A קורא לשירות B שמנהל embeddings, ששירות C קורא כדי לבצע חיפוש סמנטי, שמזין תוצאה לשירות D שקורא בפועל למודל השפה. אם המדיניות (אבטחה, ניטור, rate limiting) נאכפת רק בשער כניסה יחיד מול הספק החיצוני, כל התעבורה הפנימית בין השירותים האלה נשארת בלתי-מבוקרת ובלתי-נראית - בדיוק המקום שבו יכולות לקרות דליפות מידע או כשלים שקטים שאף dashboard מרכזי לא תופס.

ארכיטקטורת Sidecar: מדיניות שרצה ליד כל שירות

בדפוס ה-sidecar, כל שירות בקלאסטר (למשל ב-Kubernetes) מקבל קונטיינר proxy צמוד משלו שמיירט את כל התעבורה הנכנסת והיוצאת מהשירות - כולל קריאות AI, בין אם הן פנימיות (לשירות AI אחר באותו קלאסטר) או חיצוניות (לספק מודל). ה-sidecar אוכף מדיניות מקומית (מי מורשה לדבר עם מי, אילו נתונים מותר להעביר), מצפין תעבורה בין שירותים אוטומטית (mTLS), ומדווח מטריקות לשכבת ניטור מרכזית - בלי ששום קוד אפליקציה צריך לדעת שהוא בכלל קיים.

# דוגמה למדיניות mesh שמוגדרת ברמת תשתית, לא בקוד השירות
apiVersion: security.mesh/v1
kind: AIPolicy
spec:
  service: recommendation-engine
  allowedUpstreams: ["embedding-service", "external-model-gateway"]
  requireMTLS: true
  maxTokensPerRequest: 4000

היתרון המרכזי של הגישה הזו הוא שהמדיניות מוגדרת פעם אחת ברמת תשתית, ונאכפת בכל מקום שבו יש sidecar - גם אם השירות עצמו נכתב בשפת תכנות אחרת, על ידי צוות אחר, בלי שום קוד ייעודי לאכיפת מדיניות בתוך השירות עצמו. זה מבטל את הצורך בכל שירות "לזכור" ליישם את אותה בדיקת אבטחה שוב ושוב - הבדיקה קורית ברמת הרשת, לא ברמת האפליקציה.

Observability מבוזר: לראות את כל הגרף, לא רק קצוות

ביתרון גדול נוסף של mesh: יכולת לראות trace מלא של בקשה שעוברת דרך כמה שירותי AI ברצף - לא רק "שירות X קרא למודל", אלא את כל שרשרת הקריאות המלאה, כולל זמן שכל שלב לקח ואיפה בדיוק latency הצטבר. distributed tracing (עם כלים כמו OpenTelemetry) הופך קריטי במיוחד כשבקשה בודדת של משתמש קצה מפעילה שרשרת של חמישה או שישה שירותי AI פנימיים לפני שהיא חוזרת עם תשובה - בלי trace מאוחד, איתור הצוואר בקבוק בשרשרת הופך לחיפוש עיוור.

יש כאן גם ערך אבחוני משמעותי בזיהוי כשלים חלקיים. כשבקשה נכשלת בשירות הרביעי בשרשרת מתוך שישה, trace מלא מראה בדיוק היכן ומדוע - קוד שגיאה, זמן תגובה חריג, או timeout - בעוד שבלי tracing מאוחד, כל צוות שאחראי על שירות בשרשרת בודק את הלוגים שלו בנפרד, בלי הקשר לשרשרת המלאה שהובילה לכשל.

Traffic Shaping: ניתוב וניהול עומס מבוזר

מש AI טוב מאפשר גם traffic shaping מתוחכם ברמת כל שירות: canary rollouts לגרסת מודל חדשה על אחוז קטן מהתעבורה הפנימית, circuit breaking אוטומטי כששירות downstream מתחיל להיכשל (מונע "אפקט דומינו" שבו כשל בשירות אחד מפיל את כל השרשרת), ו-retry policies שמוגדרות ברמת mesh ולא בקוד כל שירות בנפרד. זה מפריד בין לוגיקה עסקית (מה שהקוד אמור לעשות) לבין לוגיקת חוסן (resilience) של התקשורת - הפרדה שמאפשרת לצוות התשתית לכוונן retry ו-timeout policies בלי לגעת בקוד של אף צוות מוצר.

Trade-offs: מורכבות תפעולית משמעותית

service mesh, גם בגרסתו הכללית וגם המותאמת ל-AI, ידוע כמורכב לתפעול. כל sidecar נוסף צורך משאבי compute, מוסיף latency (עוד hop רשת לכל קריאה), ודורש מומחיות ייעודית לתחזוקה - debugging בעיות ברשת mesh הוא מיומנות שונה מ-debugging קוד אפליקציה רגיל. ארגונים רבים שמאמצים mesh מגלים שהם צריכים צוות פלטפורמה ייעודי רק כדי לתחזק אותו. זו לא החלטה שכדאי לקחת בקלות ראש - היא משתלמת רק כשמורכבות התעבורה הפנימית כבר גדולה מספיק שהאלטרנטיבה (מדיניות מפוזרת בקוד כל שירות) גרועה יותר.

עלות Compute של Sidecars בהיקף גדול

כל sidecar נוסף הוא קונטיינר נפרד שצורך CPU וזיכרון, ובקלאסטר עם מאות שירותים, מאות sidecars מצטברים לעלות compute משמעותית שלא הייתה קיימת ללא ה-mesh - לעיתים 10-20% תוספת משאבים על כל הקלאסטר רק עבור תשתית ה-mesh עצמה. מגמה טכנולוגית חדשה יחסית, "ambient mesh" (כמו זו שמיישמת Istio בגרסאותיה החדשות), מנסה לצמצם את התקורה הזו על ידי הרצת פונקציונליות ה-mesh ברמת node משותפת במקום sidecar נפרד לכל pod - טרייד-אוף בין בידוד מלא (sidecar לכל שירות) לבין יעילות משאבים (mesh משותף ברמת node). ארגונים ששוקלים אימוץ AI service mesh בהיקף גדול צריכים לשקלל את העלות הזו מראש כחלק מהחלטת הכדאיות הכוללת, ולא רק את התועלת בנראות ובאבטחה.

השוואה מעשית: מתי Sidecar מלא ומתי גרסה קלה יותר

לא כל ארגון שרוצה יתרונות mesh צריך לאמץ sidecar מלא לכל שירות. גישת ביניים נפוצה היא להטמיע sidecar רק על שירותי AI קריטיים שדורשים בקרה הדוקה (למשל אלו שנוגעים בנתונים רגישים או תעבורה חיצונית משמעותית), בעוד שירותים פנימיים פחות קריטיים ממשיכים לתקשר ישירות בלי שכבת mesh נוספת. זה מפחית את התקורה הכוללת תוך שמירה על הבקרה בדיוק היכן שהיא הכי נחוצה, ומאפשר לארגון "לגדול" בהדרגה לתוך mesh מלא ככל שהצורך מתבהר, במקום לקפוץ ישר להטמעה מקיפה בכל הקלאסטר בבת אחת.

אבטחת תעבורה בין שירותים: Zero Trust ברמת ה-Mesh

עיקרון מרכזי ש-service mesh מממש הלכה למעשה הוא Zero Trust - הנחה שאף שירות לא סומך אוטומטית על שירות אחר רק כי הם באותה רשת פנימית. כל קריאה, גם בין שני שירותים שיושבים באותו קלאסטר, עוברת אימות הדדי (mTLS) ואישור מפורש שהשירות הקורא בכלל מורשה לפנות לשירות היעד עבור המשימה הספציפית הזו. זה שונה מהותית מגישת "ביטחון בהיקף" (perimeter security) המסורתית, שבה כל מה שבתוך הרשת הפנימית נחשב אמין כברירת מחדל - הנחה מסוכנת כשמדובר בתעבורת AI שעלולה לשאת נתונים רגישים בין עשרות שירותים.

היישום המעשי של Zero Trust ב-mesh כולל גם מדיניות "least privilege" ברמת שירות בודד - כל שירות AI מקבל הרשאה מפורשת רק לקרוא לשירותי downstream שהוא באמת צריך, לא גישה גורפת לכל שירותי ה-AI בקלאסטר. כשמתגלה שירות שנפרץ או מתנהג בצורה חריגה, ההיקף שהוא יכול לפגוע בו מוגבל מראש בזכות המדיניות הזו, במקום שהוא יכול לפנות בחופשיות לכל שירות אחר ברשת הפנימית.

תאימות לכלים קיימים: הרחבה ולא החלפה

ארגון שכבר משתמש ב-Istio, Linkerd או כלי mesh דומה לתעבורת מיקרו-שירותים כללית לא צריך לבנות מערכת mesh נפרדת ומקבילה רק עבור AI - הגישה הנכונה היא להרחיב את המדיניות הקיימת כך שתכלול גם את הסמנטיקה הייחודית לתעבורת AI (זיהוי streaming, מדידת טוקנים, מדיניות ספציפית למודלים). בניית שכבת mesh נפרדת רק ל-AI לצד mesh כללי קיים יוצרת כפילות מיותרת ומורכבות תפעולית - שני מנגנוני אבטחה ומדיניות נפרדים שצריך לתחזק, לנטר ולתאם ביניהם לאורך זמן.

טעויות נפוצות בפרודקשן

• אימוץ mesh מלא כשגייטוויי מרכזי פשוט היה מספיק - תקורה תפעולית עצומה ביחס לצורך האמיתי.
• חוסר מומחיות תשתית לתחזוקת ה-mesh - כשאין צוות שמבין sidecar networking לעומק, כל תקלה הופכת לחקירה ארוכה.
• הזנחת overhead ה-latency המצטבר - בשרשרת ארוכה של קריאות פנימיות, כמה מילישניות לכל hop מצטברות למספר משמעותי.
• אי-הגדרת circuit breakers - כשל בשירות בודד מתפשט לכל השרשרת במקום להיעצר מקומית.

מתי mesh מוצדק ומתי גייטוויי מרכזי מספיק

אם רוב תעבורת ה-AI בארגון יוצאת ישירות לספק חיצוני דרך מספר מצומצם של נקודות כניסה, גייטוויי מרכזי פשוט וזול יותר לתחזוקה מספיק לחלוטין. mesh מוצדק כשיש רשת עמוקה של שירותי AI פנימיים שקוראים זה לזה, כשהתעבורה הפנימית הזו דורשת אותה רמת מדיניות ואבטחה כמו התעבורה החיצונית, וכשהארגון כבר מריץ service mesh כללי (לא ספציפי ל-AI) ורק מרחיב אותו לכסות גם תעבורת מודלים.

סימן מעשי טוב לזיהוי הרגע הנכון: כשצוות הפלטפורמה כבר מוצא את עצמו כותב אותה מדיניות אבטחה או ניטור בכמה שירותים שונים בנפרד, וכשעדכון מדיניות אחת דורש שינוי קוד במספר repositories שונים במקום מקום אחד - אלו סימנים ברורים שהזמן להשקיע ב-mesh הגיע, ולא רק תיאוריה ארכיטקטונית מוקדמת מדי.

סיכום

AI Service Mesh הוא הכלי הנכון לבעיה ספציפית - תעבורת AI פנימית מבוזרת שגייטוויי מרכזי אחד לא יכול לראות או לשלוט בה. הוא לא צעד ראשון בבניית תשתית AI ארגונית, אלא הרחבה שמגיעה אחרי שהמורכבות המבוזרת כבר קיימת בפועל. במדיה דיל אנחנו ממליצים על mesh רק לארגונים שכבר חיים בעולם מיקרו-שירותים בוגר עם service mesh כללי קיים - הרחבתו לכסות AI היא תוספת טבעית, לא פרויקט עצמאי שכדאי להתחיל ממנו מאפס. עבור רוב הארגונים, המסלול ההגיוני הוא להתחיל מפרוקסי פשוט, לעבור לגייטוויי מנוהל כשמספר הצוותים גדל, ולהגיע ל-mesh רק כשמתברר בפועל שהתעבורה הפנימית בין שירותי AI כבר מספיק מורכבת ומבוזרת כדי להצדיק את התקורה התפעולית הנוספת.

תגיות: AI Service Mesh · sidecar · mTLS · distributed tracing · microservices · circuit breaker · בינה מלאכותית ארגונית

← חזרה לבלוג · צור קשר