Fault-Tolerant Architecture: איך מתכננים מערכת שממשיכה לרוץ גם כשחלקים ממנה נופלים

מאת צוות מדיה דיל · 03.08.2026 · DevOps · 6 דק׳

מדריך טכני ל-Fault-Tolerant Architecture: redundancy, replication, consensus, ו-failover אוטומטי — עם דוגמאות אמיתיות מבסיסי נתונים ומערכות מבוזרות.

הבעיה: single point of failure שאף אחד לא ראה עד שהוא נפל

כל צוות תשתית מכיר את הרגע הזה: node יחיד שאף אחד לא חשב עליו כ"קריטי" — אולי load balancer, אולי DNS resolver פנימי, אולי replica יחיד של Redis — נופל, ופתאום כל המערכת עומדת. Fault Tolerance היא היכולת הארכיטקטונית של מערכת להמשיך לתפקד נכון גם כשרכיב בתוכה נכשל, לא רק "לשרוד" אלא להמשיך לספק את הפונקציונליות המובטחת. זה שונה מ-resilience הרחב יותר (איך המערכת מתדרדרת) — fault tolerance מתמקד ספציפית במנגנוני redundancy שמונעים מכשל בודד להשפיע על התוצאה הסופית.

העיקרון המרכזי: אין No Single Point of Failure בלי Redundancy אמיתי

redundancy נשמע פשוט — "פשוט תריצו 2 instances" — אבל redundancy מזויף הוא נפוץ מאוד. שני instances שרצים על אותו availability zone, מאחורי אותו load balancer יחיד, עם אותו DB connection string — לא redundant באמת, כי כשל ב-AZ שלם מפיל את שניהם יחד. fault tolerance אמיתי דורש לזהות את שרשרת התלויות המלאה ולוודא שאין נקודת כשל משותפת (shared failure domain) בשום שלב: compute, network, storage, DNS, ואפילו power/cooling ברמת data center.

המודל הסטנדרטי בענן הוא N+1 או N+2 redundancy פרוס על פני Availability Zones שונים בתוך region, עם load balancer שמבצע health checks אקטיביים (לא רק פסיביים) ומוציא instance כושל מהרוטציה תוך שניות.

Replication: הבסיס ל-Fault Tolerance ברמת הדאטה

compute redundancy קל יחסית — instances stateless אפשר להכפיל בלי מחשבה רבה. הקושי האמיתי הוא ב-state: מסדי נתונים, caches, ותורים. כאן נכנסת replication, עם כמה גישות עיקריות:

Synchronous Replication — כתיבה מאושרת רק אחרי שכל (או רוב) ה-replicas אישרו אותה. מבטיח strong consistency ו-zero data loss (RPO=0), אבל מוסיף latency לכל כתיבה ופוגע בזמינות אם replica לא מגיב.
Asynchronous Replication — כתיבה מאושרת מיד, replicas מתעדכנים ברקע. latency נמוך יותר, אבל יש חלון סיכון לאובדן דאטה (RPO > 0) אם ה-primary נופל לפני שה-replica הספיק להתעדכן.
Quorum-based (Semi-sync) — פשרה: כתיבה מאושרת אחרי שרוב ה-replicas (למשל 2 מתוך 3) אישרו. זה הבסיס ל-Raft ו-Paxos, ומשמש במסדי נתונים מודרניים כמו CockroachDB, etcd, ו-Cassandra (עם quorum consistency levels).

הבחירה בין השלוש היא ליבת ה-trade-off של fault tolerance: כמה latency אתם מוכנים לשלם תמורת כמה בטחון באי-אובדן דאטה.

Consensus Protocols: איך מסכימים כשחלק מהצמתים לא זמינים

ברגע שיש יותר מ-replica אחד, עולה שאלה קשה: מי ה-source of truth כשיש מחלוקת (למשל אחרי network partition)? כאן נכנסים אלגוריתמי consensus כמו Raft ו-Paxos. הרעיון המרכזי של Raft (הפופולרי יותר כי הוא קריא יותר מ-Paxos): leader נבחר בהצבעה בין הצמתים, כל כתיבה עוברת דרכו ומשוכפלת ל-followers, ואם ה-leader נופל, מתבצעת בחירת leader חדש תוך שניות, מבוססת על quorum majority.

המשפט המכריע שכל מהנדס תשתית חייב להכיר הוא CAP Theorem: במצב של network partition, המערכת חייבת לבחור בין Consistency ל-Availability — אי אפשר את שניהם במלואם. מערכות כמו etcd ו-ZooKeeper בוחרות CP (עקביות על חשבון זמינות בזמן partition) כי הן משמשות כ-source of truth לקונפיגורציה. מערכות כמו Cassandra וDynamoDB בברירת מחדל בוחרות AP (זמינות על חשבון עקביות זמנית) כי הן משרתות תעבורת משתמשים שמעדיפה תשובה-כלשהי על פני שום תשובה.

Failover אוטומטי: מה קורה בפועל כש-Primary נופל

fault tolerance תיאורטי בלי failover אוטומטי הוא חסר תועלת — אם צריך בן אדם שיריץ סקריפט ידני ב-3 בלילה, ה-MTTR נמדד בעשרות דקות במקום שניות. ארכיטקטורת failover טובה כוללת:

Health Checking — בדיקה אקטיבית ותכופה (לא רק "process רץ" אלא "process עונה נכון לשאילתה אמיתית").
Leader Election אוטומטי — דרך consensus protocol (Raft) או service כמו ZooKeeper/etcd שמנהל leadership lease.
Client Redirection — client library שיודעת לזהות leader חדש ולהפנות אליו אוטומטית, בלי restart של האפליקציה.
Split-brain Prevention — מנגנון (fencing token, lease עם TTL) שמונע מצב שבו שני nodes חושבים ששניהם ה-leader בו-זמנית — אחד התרחישים המסוכנים ביותר בפרודקשן, כי הוא יכול לגרום לכתיבות סותרות.

Trade-offs: כמה Redundancy זה מספיק

redundancy עולה כסף ליניארית (כל replica נוסף = עלות תשתית נוספת) אבל מקטין הסתברות כשל אקספוננציאלית עד נקודה מסוימת. N=2 מקטין סיכון משמעותית מ-N=1. N=3 (quorum minimum ל-consensus) מוסיף הרבה ערך. מעבר ל-N=5 התועלת השולית קטנה משמעותית ביחס לעלות. רוב הארכיטקטורות המבוזרות הבשלות מתכנסות ל-3 או 5 replicas בדיוק בגלל זה — מספר אי-זוגי (למניעת תיקו בהצבעה) שמאזן עלות מול אמינות.

בדיקת Fault Tolerance בפועל: מעבר לתיאוריה

הדרך היחידה לדעת אם ארכיטקטורת fault-tolerant אכן עובדת היא לבדוק אותה תחת תנאים ריאליים — לא רק לקרוא את התיעוד של ה-DB או ה-orchestrator ולהניח שהכול "אמור לעבוד". זה כולל בדיקות ממוקדות: כיבוי node בפועל ומדידת זמן ה-failover בפועל (לא התיאורטי מהתיעוד), הדמיית network partition בין replicas ובדיקה שאין split-brain, ומעקב אחרי consistency בפועל אחרי failover — האם דאטה שנכתב ממש לפני הכשל אכן נשמר, או אבד בפועל בניגוד להנחות?

בדיקות אלה חופפות ישירות לתחום ה-chaos engineering (מפורט במאמר הייעודי), אבל ראוי להדגיש: fault tolerance ברמת consensus ו-replication היא בדיוק סוג הרכיב שהכי משתלם לבדוק אותו באופן שיטתי, כי הכשל בו נדיר יחסית (ולכן קל "לשכוח" שהוא בכלל צריך בדיקה) אבל ההשלכות שלו כשהוא נכשל הן הקשות ביותר — אובדן דאטה או אי-זמינות ברמת המערכת כולה, לא רק endpoint בודד.

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

Redundancy באותו failure domain — 2 instances באותו AZ, אותו rack פיזי, או מאחורי אותו network switch.
Split-brain בלי fencing — במיוחד נפוץ במימושים ידניים או ישנים של HA בלי consensus protocol אמיתי.
Failover נבדק רק בתיאוריה — אף פעם לא נבדק בפועל עד שהוא קורה באמת ומגלים שהוא לא עובד (למשל DNS TTL ארוך מדי שמעכב את ה-failover בפועל בדקות).
Async replication נחשב "בטוח כמו sync" — הבנה שגויה של סיכון אובדן הדאטה בזמן failover.

ניהול Schema Migrations בסביבה Fault-Tolerant

היבט מעשי שלרוב נשכח בתכנון fault tolerance: מה קורה כשצריך לשנות schema (הוספת עמודה, שינוי טיפוס) במערכת עם replicas מרובים ו-failover אוטומטי? migration שלא תוכנן נכון עלול לשבור compatibility בין replicas בזמן ה-rollout עצמו — replica ישן עדיין מריץ קוד שמצפה לschema הקודם, בזמן שreplica אחר כבר עודכן, ואם failover קורה באמצע, יש חוסר עקביות. הפתרון הסטנדרטי הוא expand-contract migration: קודם מוסיפים את השדה/העמודה החדשה בלי להסיר את הישנה (expand), פורסים קוד שיודע לעבוד עם שניהם, ורק אחרי שכל ה-replicas וכל גרסאות הקוד תואמות, מסירים את הישן (contract) — כל שלב עצמאי ו-backward compatible.

עיקרון זה חשוב במיוחד במערכות עם consensus protocol, כי failover יכול לקרות בכל רגע במהלך migration, ואי אפשר להניח "שהmigration תמיד תסתיים לפני שfailover קורה" — התכנון חייב לתמוך בכל שלב ביניים כמצב legit ולא רגעי.

מתי כן ומתי לא

fault tolerance ברמת consensus מלאה (Raft/Paxos) מוצדק במערכות core כמו databases, service discovery, ותורים קריטיים — אבל בניית consensus protocol מאפס כמעט אף פעם לא מוצדקת; עדיף להשתמש במערכות בנויות (etcd, Consul, CockroachDB) שכבר פתרו את הבעיה הקשה הזו. לרוב שירותי האפליקציה מספיק redundancy פשוט ברמת compute עם load balancing, בלי consensus מורכב.

מקרה בוחן קצר: כשל DNS פנימי שהפיל מערכת "redundant" לגמרי

דוגמה מייצגת שממחישה למה fault tolerance צריך לחשוב על שרשרת התלויות המלאה: ארגון בנה שירות עם 3 instances ב-3 availability zones שונים, מאחורי load balancer עם health checks תקינים — לכאורה fault tolerant לגמרי. אבל כל 3 ה-instances הסתמכו על DNS resolver פנימי יחיד (לא redundant) לפתרון שם ה-database. כשה-resolver הזה נפל, כל 3 ה-instances "בריאים" מבחינת ה-load balancer (הם עדיין עונים ל-health check), אבל אף אחד מהם לא הצליח להתחבר ל-DB בפועל. redundancy ברמת compute לא הגן על נקודת כשל שהייתה ברמת רשת נמוכה יותר.

הלקח הארכיטקטוני: fault tolerance אמיתי דורש מיפוי כל שרשרת התלויות — כולל רכיבים "משעממים" כמו DNS, NTP, certificate authorities פנימיים, ו-service discovery — לא רק הרכיבים ה"מעניינים" כמו compute ו-database. תרגיל שימושי הוא לצייר diagram מלא של כל dependency (כולל תשתית, לא רק קוד אפליקציה) ולשאול לכל אחד "מה קורה אם זה נופל" — לא רק לרכיבים שנראים קריטיים באופן אינטואיטיבי.

סיכום

Fault-Tolerant Architecture אמיתית נבנית על שלוש רגליים: redundancy אמיתי (לא רק מספר instances אלא failure domains נפרדים), replication מודעת trade-off (sync/async/quorum), ו-failover אוטומטי עם הגנה מ-split-brain. הבנה עמוקה של CAP theorem והחלטה מודעת בין Consistency ל-Availability לכל רכיב היא מה שמבדיל ארכיטקטורה שנשארת עומדת מארכיטקטורה שנראית טוב רק על הנייר.

תגיות: Fault Tolerance · Redundancy · Replication · Consensus · Raft · CAP Theorem · Failover

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