הגדרת NATS עם JetStream ואשכול לסביבת ייצור

למה NATS מאבד הודעות בעומס

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

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

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

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

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

אנו מפרקים איך זה נסגר: אישורים ומסירה חוזרת בזרמי JetStream, מטפלים אידמפוטנטיים, גדלי זרמים ומדיניות אחסון לפי פרופיל עומס אמיתי, חיבור מחדש של לקוחות עם שמירת חוצץ ובדיקות מצב צמתים.

מה נותן אשכול עמיד לתקלות להעברת הודעות

אשכול NATS עמיד לתקלות — זה לא «התקנו שלושה עותקים ושכחנו». ההשפעות שלו נבדקות לפני הפעלה בייצור: מכבים צומת תחת עומס, מסתכלים במדדים ומחליטים אם אנחנו מוכנים לתקלה אמיתית.

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

• אחריות המסירה מוגדרת במפורש. הודעות נשמרות בדיסק עד לאישור עיבוד, ולכן הפעלה מחדש של שירות המקבל לא גורמת לאובדן. עיבודים חוזרים מוגבלים בסינון כפילויות ונראים במדדים, ולא רק בניתוח תקלה.

• עומס שיא לא הופך לכשלים. אם הפרסום מהיר מהעיבוד, הפער שוקע בחוצץ האחסון ולא בשגיאות בכניסה — השירות נשאר זמין בהתפרצות.

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

• גבולות העומס מוגדרים מראש. מגבלות על המקבל והפרדת זרמים לפי ייעוד לא נותנות לשירות אחד לקחת משאבים מהאחרים — הדרדרות נשארת מקומית.

כל סעיף אנחנו מאמתים בתרגיל: מכבים צומת תחת עומס, מעלים תעבורה מעל המתוכנן, מעדכנים את האשכול בזרם חי. התוצאה — השירות שורד כשל מכונה ושיא בלי התערבות ידנית.

מצבי NATS: זרם, תור ואחסון מתמיד

מצבי NATS פותרים משימות שונות, והבחירה ביניהם נקבעת לפי שאלה אחת: מה צריך לקרות להודעה אם המקבל אינו זמין ברגע השליחה. מצב בסיסי מוסר את האירוע לכל המנויים של הנושא מיד ואינו שומר אותו בשום מקום. תור עבודות מפזר את הזרם בין מופעי השירות — ההודעה מגיעה בדיוק למבצע אחד. אחסון מתמיד JetStream כותב את הזרם לדיסק ומאפשר לקרוא אותו מחדש לאחר הפעלה מחדש.

הבחירה מתבקשת מאופי הנתונים עצמם: מה שאובדנו נסבל עובר בנושא בלי תקורה מיותרת; מה שדורש עיבוד חוזר — דרך JetStream עם אישור מסירה. אפשר לשלב מצבים באותה התקנה: מנוי לנושא ותור משתמשים באותו תחבורה, ולכן מעבר ביניהם הוא עריכת הגדרות של המנוי, לא כתיבה מחדש של השירות.

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

איך אנחנו פורסים את האשכול: שלבי העבודה

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

1. ביקורת של תרשים ההעברה. אוספים מי מפרסם ומי נרשם, אילו נושאים כבר בשימוש, היכן ההודעה עוברת שרשרת שירותים. מסמנים זרמים קריטיים לאובדן ולסדר המסירה.

2. תכנון התרשים. קובעים את הרכב האשכול, מספר העתקים לזרמים, מגבלות אחסון ומדיניות ניקוי. התרשים נכנס מיד לקונפיגורציה במאגר, ולא למסמך «לזכרון».

3. הגדרת האשכול. פורסים צמתים, מאחדים לאשכול, מפעילים JetStream, מגדירים קוורום, הרשאות גישה והצפנת תעבורה בין צמתים. מחברים מדדים והתראות לפי פיגור צרכנים.

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

5. מסירה לתפעול. מוסרים קונפיגורציות, הוראות פריסה ושחזור, תיאור התרשים ותרחישי תורנות. המהנדסים שלכם חוזרים על הפריסה בסביבה נקייה בלי רמז.

6. תמיכה. עוקבים אחרי בריאות האשכול, מעדכנים גרסאות באופן מתוכנן, מרחיבים עם גידול העומס, מנתחים תקלות עם הצוות שלכם.

קונפיגורציות, תרשימים ונוהלים בפלט

ארטיפקטים אנחנו מוסרים לא כ«ארכיון לזכרון», אלא כערכה עובדת: כל אחת מהישויות המפורטות הצוות שלכם יוכל לקרוא, לשנות ולפרוס בלעדינו. הכול נמצא במאגר שלכם, מנוהל בגרסאות ועובר בדיקה בסביבת הבדיקות — אנחנו מריצים קונפיגורציות דרך אשכול בדיקות ומוודאים שהן משוחזרות מאפס.

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

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

מקרה בוחן: אשכול NATS במקום תור בעבודת יד

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

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

מה היה לפני

שיעור ההודעות שאבדו בשעות שיא הגיע ל-0.3–0.5% מהזרם, ובאחוזים האלה היו גם אישורי תשלום. שחזור צומת לאחר נפילה ארך כ-40 דקות: העובדים לא חילקו מחדש משימות בעצמם, והתורן הרים אותם ידנית. התערבויות ידניות הצטברו ל-8–12 בחודש — כל אחת ניתקה מהנדס ממשימות מתוכננות ודחתה לוחות זמנים.

מה עשינו

פרסנו אשכול NATS עם JetStream: זרמים עם התמדה בדיסק ושכפול למספר צמתים, צרכנים עם אישור מסירה מפורש ומסירה חוזרת במקרה של שגיאת מטפל. המטפלים נעשו אידמפוטנטיים לפי מפתח אירוע, כדי שחזרה תהיה בטוחה, ואת ניתוח המשימות ה«תקועות» החליפו במסירה חוזרת אוטומטית לפי פסק זמן.

מה נהיה

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

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

במה אשכול NATS שונה מברוקר בודד

צומת NATS בודד — תהליך אחד ואחסון אחד: כל עוד הוא חי, פרסום ומנוי עוברים בהשהיה מינימלית, הקונפיגורציה נקראת מקובץ אחד, והתפעול מצטמצם להפעלה מחדש של השירות. נקודת הכשל היא בדיוק אחת, והיא חופפת לנקודת העצירה של כל ההעברה בין השירותים.

אשכול — שלושה צמתים או יותר, מחוברים במסלולים: הם יוצרים קוורום, בוחרים מנהיג מחדש ושומרים עותקים של זרמי JetStream על צמתים שונים. כשל של צומת אחד לא מפסיק את הפרסום: לקוחות מתחברים מחדש לשרידים, והזרם משוחזר מהעותק. אבל אם ייפלו שני צמתים מתוך שלושה, הכתיבה תיעצר עד חזרת השלישי — מחיר מודע על עקביות הנתונים.

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

ספקות טכניים נפוצים לפני התחלה

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

איך לדעת שהאשכול יעמוד בעומס שלנו?

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

אצלנו כבר פרוסה העברה — האם מעבר בלי השבתה אפשרי?

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

ההגדרות התפזרו בין סביבות — איך מטפלים בזה?

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

מה יקרה אם הקונפיגורציה החדשה תתברר כלא מוצלחת?

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

נדון במשימת העברת ההודעות שלכם

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

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

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