ארכיטקטורת Failover למודלי AI: איך מתכננים מעבר אוטומטי כשמודל נופל

מאת צוות מדיה דיל · 03.08.2026 · Enterprise AI · 11 דק׳

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

התרחיש: כשה-API שאתם תלויים בו מפסיק להגיב

ב-3 בבוקר, ה-endpoint הראשי שלכם מתחיל להחזיר timeouts. אין הודעת status page, אין אזהרה מראש - פשוט latency שמזנק מ-800ms ל-30 שניות ואז ל-connection refused. אם אין לכם ארכיטקטורת Failover מוגדרת, המשתמשים שלכם רואים שגיאות במשך כל הזמן שלוקח למישהו בצוות להתעורר, לאבחן ולתקן ידנית. ארכיטקטורת Failover טובה הופכת את התרחיש הזה מאירוע חירום ללילה שקט - המערכת מזהה את הבעיה, עוברת לחלופה תוך שניות, וממשיכה לתפקד עד שהצוות מטפל בבעיה בבוקר.

אבני היסוד: Health Checks, Circuit Breaker ו-Fallback Chain

ארכיטקטורת Failover בנויה משלושה מרכיבים שפועלים יחד. הראשון הוא Health Checking - ניטור מתמשך שמזהה בעיה לפני שהמשתמש חווה אותה. השני הוא Circuit Breaker - דפוס עיצוב שמונע מהמערכת להמשיך לשלוח בקשות ליעד שכבר נכשל שוב ושוב, ובכך חוסך latency מיותר ומונע החמרת המצב. השלישי הוא Fallback Chain - סדר עדיפויות מוגדר מראש של יעדים חלופיים שהמערכת עוברת ביניהם.

אנטומיה של Circuit Breaker

Circuit Breaker פועל בשלושה מצבים: Closed (מצב תקין, בקשות עוברות רגיל), Open (לאחר שיעור כשלים חורג מסף מסוים, כל הבקשות נדחות מיידית בלי לנסות את היעד הכושל), ו-Half-Open (לאחר פרק זמן קצוב, המערכת שולחת בקשת בדיקה בודדת כדי לבחון אם היעד התאושש). המעבר בין המצבים חייב להיות מבוסס על חלון זמן נע (rolling window) ולא על ספירה מצטברת, אחרת מצב שנפתר לפני זמן רב ימשיך לחסום בקשות עתידיות.

עומק: מה זה בכלל 'נפילה' של מודל

בניגוד לשרת Web שקורס בבירור, מודל AI יכול 'ליפול' במגוון דרכים עדינות יותר: timeout מוחלט, שגיאת rate limit (429), שגיאת שרת (5xx), אבל גם תשובות תקינות טכנית שהן ריקות, חתוכות, או לא עומדות בפורמט הצפוי (למשל JSON שבור כשציפיתם ל-structured output). ארכיטקטורת Failover בשלה חייבת להגדיר את כל המצבים האלה כ'כשל' ולא רק שגיאות HTTP, כולל בדיקת תקינות סכימה (schema validation) על התשובה לפני שהיא נחשבת הצלחה.

החלטות עיצוב: Active-Passive מול Active-Active

ב-Active-Passive, יש יעד ראשי שמטפל בכל התעבורה ויעד משני שנכנס לפעולה רק בכשל. הגישה פשוטה יותר ליישום אבל ה-failover הראשון תמיד איטי יותר כי המערכת המשנית 'קרה' (cold start, ללא cache חם). ב-Active-Active, שני היעדים מקבלים תעבורה כל הזמן ביחס מסוים, כך שבמקרה כשל המעבר חלק לגמרי כי המערכת המשנית כבר 'חמה'. המחיר הוא עלות כפולה של תחזוקת שני integrations פעילים במקביל ומורכבות ניטור גבוהה יותר.

דוגמת קוד: Fallback Chain עם Circuit Breaker

class FailoverRouter:
    def __init__(self, chain):
        self.chain = chain  # רשימת יעדים מסודרת לפי עדיפות
        self.breaker_state = {ep: 'closed' for ep in chain}
        self.fail_count = {ep: 0 for ep in chain}

    async def call(self, request):
        for ep in self.chain:
            if self.breaker_state[ep] == 'open':
                continue
            try:
                result = await ep.send(request)
                self.fail_count[ep] = 0
                return result
            except (TimeoutError, ProviderError):
                self.fail_count[ep] += 1
                if self.fail_count[ep] >= 3:
                    self.breaker_state[ep] = 'open'
                    schedule_half_open(ep, delay=30)
        raise AllProvidersDownError()

שימו לב שהסדר ברשימת ה-chain חייב לשקף לא רק אמינות אלא גם התאמת יכולות - מודל חלופי שלא תומך ב-function calling לא יכול להחליף מודל ראשי שמסתמך על היכולת הזו בלי שכבת תרגום.

שקיפות למשתמש: מה לחשוף וממה להימנע

שאלה שלרוב נשכחת היא כמה מהמעבר לחשוף למשתמש הקצה. אם המודל החלופי נותן איכות תשובה מעט שונה, יש ארגונים שבוחרים להוסיף disclaimer שקוף ('תשובה זו הופקה במצב חירום'), ואחרים מעדיפים שקיפות מלאה בלוגים הפנימיים בלבד. ההחלטה תלויה בהקשר העסקי - במערכות רפואיות או פיננסיות שקיפות מלאה למשתמש היא לרוב חובה רגולטורית.

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

• Fallback Chain שמוביל למודל חלופי שלא נבדק מעולם בתנאי עומס אמיתיים - מתגלה שהוא איטי מדי רק בזמן האירוע.
• סף כשלים קבוע שלא מתחשב בהבדלים בין סוגי שגיאות - timeout וגם 429 נספרים באותו אופן.
• העדר בדיקות תקופתיות (chaos engineering) שמדמות נפילת ספק ומוודאות שה-Failover אכן עובד.
• Circuit Breaker גלובלי במקום per-endpoint, מה שגורם לחסימה מיותרת של יעדים תקינים.
• העדר ניטור והתראה כשמערכת עוברת למצב Fallback - הצוות לא יודע שיש בעיה עד שהמשתמשים מתלוננים.

מתי כדאי ומתי לא

עבור פרויקטים פנימיים בעלי סיבולת תקלות גבוהה, Failover מלא הוא לעיתים over-engineering - מספיק Retry פשוט עם backoff. אבל עבור כל מערכת פונה-לקוח שהעסק תלוי בה, ארכיטקטורת Failover עם Circuit Breaker ו-Fallback Chain היא תשתית בסיסית ולא תוספת. ב-מדיה דיל אנחנו בונים את השכבה הזו כברירת מחדל בכל פרויקט AI בפרודקשן, כי עלות הבנייה נמוכה משמעותית מעלות תקרית זמינות אחת.

Chaos Engineering: הדרך היחידה לדעת שה-Failover באמת עובד

הדרך היחידה לדעת בוודאות שארכיטקטורת Failover עובדת היא לגרום לה לקרות באופן מבוקר, לפני שהיא קורית באמת בלי שליטה. Chaos Engineering במערכות AI פירושו הזרקת כשלים מלאכותיים - חסימת גישה ל-endpoint הראשי לזמן קצוב, הזרקת latency מלאכותי, או החזרת תשובות פגומות בכוונה - ובדיקה שהמערכת מגיבה כמתוכנן. תרגילים כאלה חושפים לרוב פערים שלא היו נראים בבדיקות רגילות: Circuit Breaker שלא מתאפס נכון, לוגים שלא מספיקים לאבחון מהיר, או Fallback Chain שמוביל ליעד שלא הוגדר נכון מבחינת quota.

מדד מרכזי: Time to Detect מול Time to Recover

שני המדדים החשובים ביותר בהערכת Failover הם Time to Detect (כמה זמן עובר מרגע הכשל ועד שהמערכת מזהה אותו) ו-Time to Recover (כמה זמן עובר מהזיהוי ועד לחזרה לתפקוד תקין). ברוב המערכות, Time to Detect הוא הגורם הדומיננטי - Health Check שרץ כל 30 שניות אומר שבמקרה הגרוע ייקח כמעט חצי דקה רק לזהות בעיה, לפני שבכלל מתחילים להגיב. הקטנת תדירות ה-Health Check משפרת את הזמן הזה אך מגדילה עומס על התשתית, ולכן יש למצוא איזון - ולעיתים עדיף Health Check תדיר בשילוב עם זיהוי כשל מיידי מתוך זרם הבקשות עצמו (Passive Health Checking), שבו כל בקשה נכשלת בפועל מעדכנת את מצב ה-Circuit Breaker בזמן אמת, בלי להמתין ל-Health Check הבא.

תיאום בין Failover לשכבות אחרות במערכת

ארכיטקטורת Failover לא פועלת בוואקום - היא חייבת להיות מתואמת עם שכבת ה-Rate Limiting ועם שכבת ה-Caching. כשמעבר Failover מתרחש, כל הבקשות שהיו מיועדות ליעד הראשי מוצפות פתאום ליעד המשני, ואם היעד המשני לא מוגדר עם מכסות מספיקות, הוא עלול להיכשל גם הוא תחת העומס הפתאומי - תרחיש שנקרא Failover Cascade. תכנון נכון מחייב לוודא שליעד המשני יש קיבולת פנויה מספקת לספוג את כל התעבורה, לא רק אחוז ממנה.

תיעוד ולמידה מכל אירוע Failover

כל הפעלה של מנגנון ה-Failover, גם בהצלחה מלאה, צריכה להוליד תחקיר קצר (Postmortem) - מה גרם לכשל הראשוני, כמה זמן לקח לזהות אותו, האם המעבר ליעד החלופי היה חלק, ומה אפשר לשפר. גישה כזו, שמקורה בתרבות ה-SRE (Site Reliability Engineering) של גוגל, הופכת כל תקרית לנקודת שיפור ולא רק לאירוע שחולף. עם הזמן, תיעוד שיטתי כזה בונה מאגר ידע פנימי שמאפשר לצוות לזהות דפוסי כשל חוזרים ולטפל בשורש הבעיה, לא רק בסימפטום.

מקרה בוחן: איך Circuit Breaker מנע קריסה משולבת

נבחן תקרית אמיתית: מערכת המלצות שמבוססת AI חוותה latency גובר בספק הראשי בגלל עומס גלובלי על התשתית של הספק. בלי Circuit Breaker, כל בקשה נכשלת המתינה למלוא ה-timeout (30 שניות) לפני שנכשלה רשמית, מה שגרם לתורי בקשות להתמלא ולזיכרון השרת להיגמר - כשל שהתפשט לכל המערכת תוך דקות, הרבה מעבר לבעיה המקורית והממוקדת בספק. לאחר הטמעת Circuit Breaker עם סף כשלים של 5 שגיאות רצופות ו-timeout מקוצר ל-5 שניות, אותה תקלה בספק גרמה למעבר מהיר ל-Fallback תוך שניות בודדות, ומנעה את אפקט הדומינו לגמרי. ההבדל בין שני התרחישים לא היה בזמינות הספק החיצוני - זה היה בלתי נשלט - אלא אך ורק בעיצוב הפנימי של המערכת.

אינטגרציה עם מערכות Alerting וניהול תקריות

מנגנון Failover חייב להיות מחובר למערכת Alerting שמעדכנת את הצוות המתאים ברגע שהמעבר קורה, גם אם המשתמשים לא חווים כל פגיעה. הודעה שנשלחת ל-Slack או PagerDuty ברגע שה-Circuit Breaker עובר למצב Open מאפשרת לצוות ההנדסה לחקור את הבעיה בזמן אמת, במקום לגלות אותה רק בסקירת עלויות בסוף החודש כשמבינים שהמערכת עבדה על ספק חלופי יקר יותר במשך ימים. שילוב עם כלי ניהול תקריות (Incident Management) כמו PagerDuty או Opsgenie גם מאפשר לתעד אוטומטית את משך הזמן שהמערכת פעלה במצב Fallback, נתון שחשוב הן לניתוח תקריות והן לדיווח SLA ללקוחות. חשוב לזכור שהמטרה הסופית של הארכיטקטורה הזו היא לא רק לשרוד תקלות, אלא לתת לצוות ההנדסה שקט נפשי - ידיעה שהמערכת תתמודד עם רוב התקלות הנפוצות באופן אוטומטי, בלי צורך בהתערבות ידנית בשעות הלילה. מומלץ גם לתעד את כל שרשרת ההחלטות של ה-Fallback Chain במסמך פנימי נגיש, כך שכל חבר צוות חדש יוכל להבין תוך דקות מה סדר העדיפויות בין היעדים ומדוע נבחר דווקא הסדר הזה, בלי צורך לחפור בקוד. כדאי גם להימנע מהנחה שגויה נפוצה - שברגע שנבנתה פעם אחת, ארכיטקטורת ה-Failover תמשיך לעבוד ללא תחזוקה. שינויים בממשקי API של ספקים, עדכוני גרסאות מודל ושינויים במבנה הארגוני של הצוות דורשים כולם בדיקה מחודשת של השרשרת. זו בדיוק הסיבה שתחזוקה שוטפת חשובה לא פחות מהבנייה הראשונית עצמה. בטווח הארוך, זו ההשקעה שמונעת את רוב שיחות הטלפון בשעה שלוש לפנות בוקר.

סיכום

ארכיטקטורת Failover טובה היא שילוב של Health Checks מדויקים, Circuit Breaker שמונע נזק מצטבר, ו-Fallback Chain מתוכנן היטב. ההשקעה בה משתלמת ברגע הראשון שספק חיצוני נופל - וזה תמיד קורה, השאלה היא רק מתי.

תגיות: Failover · Circuit Breaker · High Availability · AI Infrastructure · Fallback Chain · Health Checks · Resilience Engineering

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