הרחבת תשתית בלוקצ'יין: היכן היא נשברת תחת עומס
תחת עומס, תשתית נשברת לא במקום שבו מחפשים אותה בדרך כלל. הראשון שנכנע הוא לא הדיסק ולא המעבד, אלא תור הבקשות: צומת JSON-RPC מקבל אותן למאגר מוגבל, ובשיא הפעילות התור גדל מהר יותר משמספיקים לעבד אותו.
לאחר מכן מופעלת הידרדרות בתגובת הצומת — זמן התגובה לקריאה גדל באופן לא ליניארי, כי הבקשות מתחרות על אותם מצבים.
צוואר הבקבוק השני של רשת בלוקצ'יין — חוסר סנכרון. צומת אחד מתקדם בגובה, השני מפגר בכמה בלוקים, והיתרה הנקראת מהצומת המפגר אינה תואמת את מה שהלקוח רואה. בארגון מחדש של השרשרת זה בולט יותר: המטמון מחזיר מצב מיושן, והאינדקס שנבנה מהלוגים מפגר אחרי ראש השרשרת.
השלישי — מצב ומינויים. בקשה לנתונים היסטוריים בצומת ארכיוני קוראת אלפי מפתחות, וקריאה כזו מחזיקה תהליך בזמן שאחרים ממתינים. מינויים קבועים דרך WebSocket מעתיקים את העומס אחרת: כל מאזין חדש לא מוסיף משתמשים, אבל מוסיף חיבורים שצריך להחזיק פתוחים ולחבר מחדש בעת ניתוק.
לכל אחת מהנקודות האלה יש גבול, שמעבר לו התגובה נופלת במדרגה, ולא באופן חלק. העומס על צמתי הרשת גדל ממספר המינויים יותר מאשר ממספר המשתמשים — לכן הרחבת תשתית בלוקצ'יין מתחילה בניתוח היכן בדיוק נגמר המאגר ומה קורה אחר כך. נבחן איך זה נסגר.
מה נותנת התארגנות מחדש של הרשת: מהירות ועמידות לתקלות
צומת אחד, שבמקביל מחזיר היסטוריה, מקבל עסקאות ומשדר אירועים, הוא צוואר הבקבוק הנפוץ ביותר. כל עוד העומס גדל, תפוקת הצמתים נתקלת בתהליך אחד: זמן התגובה לקריאה גדל מהר יותר ממספר הלקוחות, וזרם האירועים מתחיל לפגר אחרי מצב הרשת.
לכן מפרידים תפקידים — מאמתים, ארכיוניים ומשרתי בקשות — וכל קבוצה מתרחבת בנפרד, לפי פרופיל העומס שלה.
עמידות לתקלות של רשת בלוקצ'יין היא לא "צומת בשני עותקים". הגיבוי נשמר חם, בפיגור של בלוק אחד, ומאזן העומסים בודק את החיות של כל צומת ומסיר תעבורה מזה שהפסיק להגיב. ההעברה אורכת שניות, והשבתת השירות נמדדת כבר לא בדקות, אלא בזמן המיתוג.
סיפור נפרד — מינויים. חיבור WebSocket קשור לצומת מסוים, לכן בנפילתו הלקוח מאבד בשקט את זרם האירועים. אנחנו מחזיקים סשנים עם הצמדה לצומת ומאגר עם סמן של הבלוק האחרון שעובד: אחרי ניתוק הלקוח מדביק את מה שהחסיר, ולא מתחיל מדף חלק. שיעור המינויים האבודים יורד לאפס.
ברשת Ethereum וברשתות תואמות, שכבה כזו נותנת מדדים צפויים: זמן התגובה לקריאה נשמר בגבולות שהוגדרו על ידי פרופיל העומס, ההתאוששות לאחר כשל של צומת מסתכמת בשניות, וסוג הכשל "שירות לא זמין בגלל צומת אחד" נעלם מהסטטיסטיקה. מה בדיוק משנים ברשת מסוימת — קובע המדידה לפני הארגון מחדש, ולא תבנית כללית.
מצבים: צמיחה אנכית, פיזור, סכימה היברידית
שלושת המצבים נבדלים לא ברזרבה של כוח, אלא במקום שבו נוצר הגבול. הרחבה אנכית — זה צומת בעל ביצועים גבוהים יותר: המצב ותור העסקאות שאינן מאושרות נמצאים כולו על מכונה אחת, לכן התגובה לבקשות צפויה, וההיגיון של עקביות אינו מסתבך.
משלמים בתקרת החומרה ובסנכרון ארוך: בנייה מחדש מלאה של אינדקסים אורכת שעות, וכל תחזוקה — זה חלון השבתה.
פיזור אופקי של צמתים בנוי אחרת: כמה העתקים מאחורי מאזן עומסים, קריאות ומינויים עוברים אליהם, כתיבה וחתימה נשארות על הצומת המוביל. סכימה היברידית מחברת את שתי הגישות — צומת מחוזק לכתיבה בתוספת מאגר העתקים לזרם הקריאות ומינויים ב-WebSocket.
| מצב | מתי מתאים | במה משלמים |
|---|---|---|
| הרחבה אנכית | העומס גדל באופן מתון, מספר הלקוחות צפוי, חשוב סכימה פשוטה | תקרת חומרה, שעות לסנכרון, השבתה בתחזוקה, גידול מואץ בנפח האינדקסים |
| פיזור אופקי של צמתים | הרבה קריאות ומינויים במקביל, בקשות מאפשרות פיגור קטן בנתונים | העתקים מפגרים: חלק מהתשובות מחזירות מצב מיושן, צריך בקרת פיגור והעברה זהירה של לקוחות בין צמתים |
| סכימה היברידית | פרופיל משולב: כתיבה כבדה וקריאות המוניות בו-זמנית | יקר יותר בתחזוקה: שני מעגלים, כללים נפרדים לעדכון ולעמידות לתקלות, יותר נקודות כשל |
הבחירה נקבעת לא לפי האפשרות "החזקה ביותר", אלא לפי זו שהגבול שלה נמצא מעבר לפרופיל העומס שלכם. מחשבים את חלק הקריאות, מספר המינויים בו-זמנית ודרישות לרעננות הנתונים — ורק אחר כך קובעים את מצב הפעולה של הצמתים.
סדר העבודות: מסקר ועד מסירה לתפעול
הרחבה מתחילה לא בפריסה, אלא במדידת הגבולות הנוכחיים: כמה מינויים בו-זמנית מחזיק השער, באיזה נפח קריאות נתקל שכבת קריאת הנתונים, איך מתנהג הסנכרון כשהצומת מפגר. להלן סדר העבודות, שבו כל שלב מסתיים בתוצאה שמתקבלת לפני המעבר לשלב הבא.
שבעה שלבים עם תוצאה מדידה
- סקר תשתית. מסירים פרופיל עומס: מינויים בו-זמנית, הרכב ותדירות קריאות, מרווחי שיא, רזרבה בדיסק וברשת. בפלט — דוח עם גבולות בפועל, ולא הערכות בעין.
- סכימת פריסת צמתים. מפזרים תפקידים — מאמתים, צמתי קריאה, ארכיוניים, שערי מינויים — וקובעים קשרים ונקודות כשל. הטופולוגיה מסוכמת לפני ההגדרה.
- הגדרת צמתים. תצורה לפי הפרופיל שנמדד: מגבלות חיבורים, פסקי זמן, עומק אחסון, הפרדת קריאה וכתיבה, העתקים. כל שינוי מנוהל בגרסאות והפיך.
- בדיקת עומס. משחזרים שיא ורזרבה מעליו, בודקים התנהגות בעת כשל של צומת אחד: הידרדרות חלקה או נפילה. מתקנים את התצורה לפי מדדים.
- תפעול ניסיוני. תעבורה אמיתית עם ניטור מורחב: משווים תחזית למצב בפועל ומכווננים את מה שמתנהג אחרת.
- נראות ותקנונים. לוחות בקרה, התראות, נהלי אבחון וחזרה לאחור — כדי לתפוס תקלה לפני שהמשתמשים מבחינים בה.
- מסירה לתפעול. הרשאות גישה, הוראות התאוששות והדרכת משמרת תורנית: את המערכת מרימים ומתקנים בלי השתתפותנו.
מה נשאר אצלכם: תצורות, סכימות, תקנונים
תשתית בלי תיעוד חיה בדיוק עד העזיבה הראשונה של מהנדס או עד תקלה. לכן כל מה שאנחנו מגדירים נמסר כארטיפקטים עובדים: אפשר לבדוק אותם, לפרוס מחדש בסביבה נקייה ולמסור לצוות שלכם בלי לספר מחדש "בעל פה". להלן — סט שנשאר אצלכם לאחר המסירה.
- תצורות צמתים — פרמטרי סנכרון, מגבלות חיבורים, פסקי זמן, מדיניות ניסיונות חוזרים, נפחי מטמון; לצדם הסבר למה נבחר דווקא הערך הזה ומה משתנה עם גידול העומס.
- סכימות טופולוגיה — פיזור צמתים לפי אזורים, נתיבי גיבוי, מקטעים משוכפלים ונקודות שכשל בהן יפיל את כל המעגל.
- כללי גישה — תפקידים, מפתחות, גבולות הרשאות לקריאה ולכתיבה, סדר הנפקה ושלילה, יומן פעולות.
- הגדרות פיזור זרימה — איך בקשות מתפזרות בין צמתים ומה קורה כשאחד מהם כושל.
- תקנוני תחזוקה — עבודות מתוכננות, סדר עדכונים, בדיקת מצב, ספי התראות ופעולות תורניות.
- תקנוני התאוששות — גיבויים, זמן יעד לחזרה לפעולה, חזרה למצב קודם, תרגול תרחיש.
- תיעוד תשתית — מפת שירותים, תלויות, אחראים, הוראות למהנדס תורן.
כל סעיף — לא תיאור, אלא קובץ עובד או תרחיש בדוק: אפשר למסור אותו לצוות חדש, והוא ירִים את המעגל בלעדינו.
מקרה בוחן: גידול פי שלושה בעומס בלי הידרדרות בתגובה
לפני הארגון מחדש, התשתית נשענה על צומת אחד עם נקודת קצה ציבורית משותפת. האפליקציה גדלה, מספר הבקשות שולש ברבעון, ובשעות השיא מינויים לבלוקים חדשים נשברו בעשרות: לקוחות ראו חוסרים באירועים, והתאוששות של צומת שנפל ארכה כארבעים דקות של עבודה ידנית של מהנדס.
התחלנו בבדיקות עומס — שחזרנו שיא משולש על סטנד ומצאנו את נקודת הכשל: לא הרשת התמלאה, אלא תור המינויים בתוך תהליך הצומת.
אחר כך הפרדנו תפקידים: הקריאה עברה למאגר צמתים מאחורי מאזן עומסים, הכתיבה והפצת האירועים — לשכבת מינויים נפרדת עם מאגר וניסיון חוזר, והתזמור עם Kubernetes החליף הרמה ידנית של צמתים בהפעלה מחדש אוטומטית עם בדיקות מצב.
מדדים לפני ואחרי
- נפח בקשות — מ-1.2 ל-3.6 אלף בדקה על אותו מצאי מכונות;
- תגובה בשיא — האחוזון ה-95 הצטמצם מ-4 ל-1.1 שניות;
- ניתוקי מינויים — מ-60–80 בשעת שיא לאפס במשך חודש תצפיות;
- התאוששות צומת — מ-40 דקות ידנית ל-90 שניות אוטומטית.
רזרבה לעומס נשארה: הגידול המשולש הבא נתקל כבר לא בצמתים, אלא באחסון היסטוריית האירועים — זו הנקודה הבאה שנשמור עליה במעקב. בנפרד עיגנו תקנון חזרה לאחור: שכבת המינויים נפרסת בנפרד מהצמתים, לכן עדכון כושל מוחזר בלי אובדן של זרם האירועים.
מה לעשות אם תשתית בלוקצ'יין כבר פרוסה?
צמתים שכבר פרוסים לעתים רחוקות דורשים עצירה מלאה של השירות — השבתה נוצרת במקום שיש עותק יחיד ונתיב אחד לנתונים. תחילה ספירת מלאי של תשתית בלוקצ'יין: אילו מופעים משרתים קריאה וכתיבה, היכן עומד מאזן העומסים, מי מחזיק מינויים לאירועים. אחר כך מרימים צומת מקביל ומסנכרנים אותו עם הרשת.
העברת צמתים מתבצעת דרך השוואה, ולא מיתוג "בכוח". מופע חדש מושווה לישן על טווחי בלוקים לבקרה — פער במצב עוצר את העבודה עד לבירור הסיבה. אם תאם: הצומת מופעל כהעתק לקריאה בלבד, בודקים בו פיגור אחרי הרשת ושיעור תשובות שגויות.
על הדרך משתנה כל מה שנמצא מעל שכבת האחסון: נקודות קצה RPC, מאזן עומסים, מכסות, מטמון תשובות, הרכב העתקי קריאה. האינדקסר נבנה מחדש במקביל — החדש כותב את מסד הנתונים שלו, הישן ממשיך להחזיר נתונים. מינויים לאירועים מועברים עם חפיפה, כדי שהלקוח לא יאבד בלוק במעבר.
חלון תחזוקה קצר נדרש במקום שבו משתנה פורמט האחסון או תפקיד הצומת ברשת. החלפת סכימת מסד נתונים, העברת צומת הכתיבה הראשי, סבב מפתחות של מאמת והכנה לעדכון רשת של הקונצנזוס — מסונכרנים לפי גובה הבלוק. בזמן הזה השירות מועבר להעתקים: הקריאה לא נפגעת, נעצרת רק הכתיבה.
החלון נבחר לפי פעילות רשת מינימלית, ובמיתוג תמיד נשאר נתיב חזרה: הצומת הישן מכובה לא מיד, אלא אחרי שהחדש עבד בלי שגיאות לאורך כל תקופת התצפית. כך מודרניזציה בלי עצירה הופכת לתקנון — סדר מובן, נקודות בדיקות והתנהגות צפויה בעת תקלה.
ספקות טכניים נפוצים לפני תחילת העבודות
קשיים בעבודה עם צמתים קשורים לעתים רחוקות לקוד — הם מתגלים במפגש שבין עומס, חומרה וגבולות אחריות. אספנו חמש שאלות ברמת הנדסה, שנשאלות לרוב לפני ההתחלה.
מה לעשות אם דרישות החומרה יגדלו אחרי ההשקה?
מקצים רזרבה בדיסק ובזיכרון ומתארים ספים, שאחריהם נדרש סוג אחר של מכונות. הצומת ושירותי הגישה מתרחבים בנפרד, לכן לא צריך לשנות את כל הסכימה בבת אחת.
מי אחראי לתקלה אחרי מסירת הצמתים?
אנחנו מוסרים תצורות, סכימות רשת ותקנונים, שלפיהם צוות תורן משחזר כל מצב. בנפרד קובעים את אזור האחריות: מה מכסה הניטור שלנו, ומה נשאר בצד שלכם.
איך להבין היכן צוואר הבקבוק — צומת, רשת או גישת לקוח?
מחשבים לפי חלקים: זמן עיבוד בצומת, השהיית הערוץ והתנהגות שירות הגישה תחת עומס. נראה מה להרחיב — אחסון, רוחב פס או נקודות חיבור.
מה קורה בעומס שיא ובניתוקי קשר?
מגבילים את מספר החיבורים לצומת, מוסיפים העתקים וחיבור מחדש עם הדבקת בלוקים. הלקוח לא מאבד נתונים, והצומת נכנס לעומס יתר לא כולו, אלא בגבול של העתק אחד.
האם צריך להרים כמה צמתים מיד?
מתחילים מאחד, מסירים פרופיל עומס ומוסיפים העתקים לפי מדדים. יתירות מופיעה כשבאמת צריך אותה, ולא "ליתר ביטחון".
נדון במשימה: איך נבנה תוכנית עבודה
תוכנית עבודה להרחבת תשתית בלוקצ'יין נבנית לא על ניחושים, אלא על מדידות: בלי הבנה של הטופולוגיה הנוכחית קל לייעל לא את המקום שבו באמת הולך לאיבוד רוחב פס. כדי לדון במשימה לעניין ולחזור עם הערכת זמנים כנה, אנחנו צריכים נתוני מקור — הנה ממה מורכב הדיון.
- טופולוגיה נוכחית: כמה צמתים במעגל, אילו תפקידים הם נושאים (מאמתים, קריאה, ארכיוניים, אינדקסרים), איך ממוקמים ומה מחבר ביניהם.
- פרופיל עומס: בקשות שיא בשנייה, חלק המינויים בזמן אמת, קצב יומי ושבועי, התנהגות המערכת ברגעי שיא.
- מה כואב עכשיו: פיגור הצומת אחרי הרשת, ניתוקי חיבורים, גידול הדיסק, חוסר סנכרון של האינדקס, כשלים בהחזרת נתונים.
- דרישות לזמינות: זמן יעד להתאוששות אחרי תקלה, הידרדרות מותרת, האם נדרשת חזרה למצב קודם.
- מגבלות: היכן מותר למקם צמתים, אילו פלטפורמות ענן ותחומי שיפוט מותרים, איך מונפקות הרשאות גישה ומי אחראי לתורנות.
- קריטריוני קבלה: לפי אילו מדדים נחשיב שהמצב השתפר — השהיית תגובה, שיעור מינויים אבודים, זמן טעינה מחדש לאחר הפעלה מחדש.
בתגובה אתם מקבלים סכימת טופולוגיה עם נקודות כשל מסומנות, תוכנית עבודה מחולקת לשלבים, הערכת זמנים עם תלויות ורצף שינויים שבו השירות נשאר זמין בכל שלב. אם אין עדיין נתונים — נציע אילו מדידות לבצע כדי שהתמונה תהיה מלאה.
תארו את המשימה בצורה חופשית: מצב נוכחי, מה הפסיק להסתדר ואיזו התנהגות תרצו להשיג. נחזור עם הערכה, תוכנית ושאלות שכדאי לסגור לפני ההתחלה.