הגדרת Fly.io: מדוע זמן התגובה נפג� אצל חלק מהלקוחות
תמונה אופיינית: האפליקציה פרוסה באזור אחד, ושם גם נמצאים בסיס הנתונים והמטמון. משתמש מאזור מרוחק עובר דרך רשתות מעבר — ומשלם על כך במרחק בכל בקשה, ובשיא חלק מהחיבורים נשברים כבר בלחיצת היד ובבייטים הראשונים של התגובה.
המדדים במקרים כאלה נראים לעיתים קרובות תקינים: זמן התגובה הממוצע בטווח הנורמה, כי עיקר הבקשות מגיע מהאזור ה"ביתי" ומטשטש את הזנב. צוואר הבקבוק ניכר רק באחוזון ה-95 וה-99 ובפילוח לפי גיאוגרפיה — ומשם מגיעות התקלות אצל חלק מהמשתמשים, שאיש אינו מצליח לשחזר בסביבת הבדיקה.
הסיבה השנייה — נקודת כשל יחידה. כל עוד האפליקציה יושבת באתר אחד, השחתה אצל הספק, עבודות מתוכננות או פגיעה בתקרת החיבורים מוציאות הכל מכלל פעולה בבת אחת. הרחבה בתוך אזור אחד מורידה עומס, אך לא מקצרת את המרחק למשתמש, ולכן זמן התגובה אצל לקוחות מרוחקים נשאר כשהיה.
הגדרת Fly.io סוגרת את שתי המשימות: מופעי האפליקציה עולים בכמה אזורים, מסלול הבקשה מפנה את התעבורה לאתר התקין הקרוב, ואתרים לא תקינים מוצאים מאיזון העומס אוטומטית. בנפרד מתוארת ההתנהגות בעת אובדן אזור — הבקשה אינה ממתינה לפסק זמן, אלא עוברת לאתר הבא.
נפרק כיצד זה נסגר: מבחירת הרכב האזורים וכללי הניתוב ועד למדיניות הכשלים ובדיקות התקינות של המופעים.
מה נותנת סכמת פריסה נכונה של האפליקציה
סכמת פריסה היא לא "להדליק עוד אזור". זו החלטה היכן יושבים עותקי האפליקציה, כיצד מתחלק ביניהם התעבורה, מה נחשב כשל של צומת ולפי איזה כלל העומס עובר לאתר השכן.
סכמה מחודשת משנה ארבעה דברים מדידים: זמן תגובה, זמן התאוששות לאחר תקלה, שיעור הבקשות שנכשלו וסוג הכשלים שבכלל מגיעים למשתמש.
כאשר עותקי האפליקציה פרוסים באזורים סמוכים למשתמשים, הבקשה מגיעה לאתר הקרוב ולא חוצה חצי עולם — ההשהיה מפסיקה להיות הגרלה. שיעור הבקשות שנכשלו יורד גם משום שבעת כשל של אזור התעבורה מפסיקה לזרום לשם בעקבות בדיקת מצב, ולא בעקבות תלונות.
זה ההבדל בין "חלק מהבקשות נופלות עד שהבחנו בכך" לבין "כשל של צומת אינו נראה ללקוח".
זמן ההתאוששות לאחר כשל של צומת מפסיק להיות תלוי בפעולות ידניות: העותק עולה לפי כלל שהוגדר מראש, והעומס עובר אוטומטית. כך נעלם סוג שלם של כשלים — לא "השרת נפל", אלא "השרת נפל, ואיש לא ידע על כך חצי שעה". את עלות זמן ההשבתה אנחנו מודדים לא בכסף, אלא בשיעור ההפעלות וההזמנות שלא זכו לתגובה.
כלים כמו Fly.io מספקים אזורי פריסה ומנגנון מעבר, אך את התוצאה קובע לא עצם הפעלתם, אלא השילוב: אילו אזורים נבחרו, כמה עותקים מחזיקים חמים, כיצד מוגדרות בדיקות המצב ומה נחשב מספיק כדי להחזיר אתר לפעולה.
השוואה בין מצבי הרצה: אזור אחד או כמה
מצב ההרצה קובע מה יקרה לאפליקציה בעת כשל של אזור ואיזו השהיה יראו משתמשים מערים שונות. ב-Fly.io הוא נקבע לא במפסק אחד, אלא בשילוב: כמה אזורים פעילים, היכן יושבים כרכים קבועים וכיצד מתחלקת התעבורה בין מכונות האפליקציה. אזור אחד פשוט יותר לתחזוקה, אך כל השירות תלוי בנקודה אחת — נבחן את החלופות.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| אזור אחד, אזור פעיל אחד | שירותים פנימיים, קהל צפוי, עומסי פיילוט | כשל באזור מפסיק את השירות כולו; ההשהיה גדלה עם המרחק למשתמש |
| כמה אזורים פעילים (מצב פעיל בכמה אזורים) | שירותים ציבוריים עם פריסה גיאוגרפית רחבה, דרישות לזמינות | נדרשים שכפול נתונים והוצאת המצב ממכונות האפליקציה; מספר נקודות הניטור גדל |
| סכמה היברידית: צמתי קצה בתוספת קונטור עצמאי | חילופי נתונים עם מערכות פנימיות, דרישות למיקום אחסון הנתונים | הקונטור העצמאי הופך לנקודת כשל יחידה ולצוואר בקבוק בהשהיית הכתיבה |
| אזור פעיל אחד עם מעבר ידני | מהדורות נדירות, חלון השבתה מותר, מינימום תחזוקה | המעבר בעת כשל תלוי בזמן התגובה של התורן; החזרת התעבורה נבדקת ידנית |
בפועל, מגבלות הפלטפורמה מתגלות בנתונים ולא בקוד: כרך קבוע קשור לאזור מסוים ואינו עובר מעצמו בעת מעבר, ולכן את בסיס הנתונים והקבצים מוציאים לשכפול עם כלל ברור לבחירת הצומת המוביל. את ההפעלות מחזיקים מחוץ למכונות האפליקציה, אחרת המשתמש מנותק מהחשבון לאחר מעבר בעת כשל.
ובודקים את שני הכיוונים — לא רק יציאת התעבורה מהאזור שנפל, אלא גם את החזרה אליו, כי דווקא החזרה יוצרת לעיתים קרובות אי-התאמה בנתונים.
סדר ההגדרה של Fly.io: מהאודיט ועד למסירה
Fly.io מוריד חלק מהשגרה התשתיתית, אך פריסה מבוזרת מניבה רווח רק כאשר האזורים, כללי ניתוב הבקשות והעבודה עם המצב מתואמים ביניהם. לכן את ההגדרה מובילים לפי סדר קבוע: תחילה אודיט של התשתית ותכנון, אחר כך השקה — כל שינוי ניתן לבדיקה בשלב שלו וניתן לחזרה בנפרד.
- אודיט תשתית. מרכיבים מפה של השירותים והתלויות שלהם, בוחנים היכן נמצאים המשתמשים בפועל, ומודדים את ההשהיות הנוכחיות ואת שיעור הכשלים. התוצר — רשימה של מה שמעבירים ומה שנשאר במקום.
- תכנון הפריסה. קובעים כמה אזורים באמת דרושים, כמה מופעי אפליקציה להחזיק בכל אחד, והיכן יושבים בסיס הנתונים, המטמון והתורים. את פרמטרי הפריסה ואת כללי ההרחבה האוטומטית מתעדים בקונפיגורציה במאגר הקוד, ולא בפאנל.
- ניתוב וכללי רשת. מגדירים קירוב של הבקשה לאזור הקרוב, בדיקות תקינות, התנהגות בעת אי-זמינות של אזור ומגבלות על מספר החיבורים. בודקים בסביבת בדיקה עם זרם סינתטי, ולא על משתמשים חיים.
- מצב ומיגרציות. ממקמים שכפולי בסיס נתונים לצד האפליקציה, מכינים סכמת מיגרציות ללא השבתה ותאימות לאחור בזמן ההשקה.
- בדיקת עומס. מריצים פרופיל של תעבורה אמיתית עם זינוק פי שלושה, מכבים אזור בכוח, מפעילים מחדש מופעים. בוחנים את זמן ההתאוששות ואת שיעור הבקשות המוצלחות.
- השקה וחזרה לאחור. השקה קנרית על חלק מהמופעים, קריטריונים לחזרה אוטומטית לתמונה הקודמת, וניתוח התרעות שווא.
- מסירה לתפעול. מעבירים גישות, התרעות, סכמות ונוהל פעולה בעת תקלה, מקיימים הדרכת צוות וניתוח משותף של האירוע הראשון.
כל שלב נסגר בתוצר: קונפיגורציה במאגר הקוד, סכמת פריסה, דוח בדיקה, הוראות. המסירה נחשבת שלמה כאשר הצוות שלכם מרים אזור ומחזיר מהדורה לאחור בעצמו, ללא עזרתנו.
מה נשאר אצלכם: קונפיגורציות, סכמות, נהלים
איננו משאירים אתכם עם סיכומים בעל פה וגישה לפאנל: כל מה שהוגדר מתואר בכתב ומונח במאגר הקוד שלכם. מהנדס שיגיע אחרינו — פנימי או חיצוני — פורס את הסביבה לפי הקבצים האלה, בלי התכתבות איתנו ובלי לפענח את הקונסולה דרך הלוגים.
- קובצי קונפיגורציה במאגר הקוד. תיאור האפליקציה ב-Fly.io, המכונות, האזורים, בדיקות הזמינות ומשתני הסביבה — בצורה שעוברת ריוויו ונפרסת בפקודה אחת, ולא ידנית בפאנל.
- סכמות תשתית. הקשרים בין אפליקציות, בסיסי נתונים, מטמון, תורים ושירותים חיצוניים: מה תלוי במה, היכן נקודות הכניסה ומה יורד יחד עם מה.
- מדיניות גישה. תפקידים וטוקנים, גבולות בין סביבות, מי ומה יכול לשנות בפרודקשן, היכן מאוחסנים סודות, כיצד מסובבים אותם ומה עושים בעת דליפה.
- תיעוד תפעול. לאן להסתכל בעת השחתה, היכן המדדים והלוגים, אילו התרעות הוגדרו ומה לעשות בכל אחת, כיצד לבצע פעולות שגרתיות — הרחבה, הוספת אזור, העברת תעבורה.
- נוהל עדכון וחזרה לאחור. סדר ההשקה, קריטריונים לעצירה, סדר החזרה לגרסה הקודמת והזמן שבו מתבצעת חזרה כזו.
- צ'ק-ליסט קבלה ומסירת גישות. מה לבדוק לפני הקבלה, אילו הרשאות נרשמות על שמכם ומה נשלל מאיתנו.
הרשאות אדמין ומפתחות — גם הם תוצר: מתעדים את ההעברה אליכם, ולא שומרים אצלנו "ליתר ביטחון". לאחר הקבלה התשתית עובדת ומתפתחת ללא מעורבותנו.
ניתוח ההטמעה: מדדים לפני ואחרי
את הגרסה הראשונה של השירות פרסו באזור אחד: בסיס הנתונים והאפליקציה ישבו באשכול אחד, והמשתמשים הגיעו מעשרה מדינות. בשיא, כשהעומס היומי גדל פי שלושה, זמן התגובה p95 חצה שנייה וחצי, שיעור התגובות עם שגיאה הגיע ל-4%, וצומת שנפל הרימו ידנית — כארבעים דקות השבתה לאירוע.
מה שינו בסכמה
את האפליקציה פיזרו לצמתי קצה סמוכים למשתמשים, ואת הניתוב עברו לבחירת האתר הקרוב עם העברת תעבורה אוטומטית בעת השחתה של השכן. את המצב הוציאו לאחסון חיצוני משוכפל, ולכן הצמתים נשארו ברי-החלפה: אפשר לאבד כל מכונה בלי לאבד נתונים.
Fly.io סיפק ניהול מכונות דרך קונפיגורציה דקלרטיבית: מספר המופעים מתואר בקובץ, וההרחבה כרוכה למדדים. בדיקות חיות והפעלה-מחדש אוטומטית החליפו תורנויות ידניות — צומת תקול מוצא מהרוטציה ועולה מחדש ללא מעורבות מהנדס.
תיקוני הסכמה עוברים דרך אותה קונפיגורציה, ולכן הגדרות הסביבות כבר אינן נבדלות בין סביבת הבדיקה לקונטור העבודה.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| תגובה p95 בשיא | 1.4 ש' | 300–400 מ"ש |
| שיעור תגובות עם שגיאה | 3–4% | 0.3% |
| זמן התאוששות צומת | ~40 דק' | 20–30 ש' |
| עתודת עומס בשיא | התור גדל | מחזיק פי שלושה יותר בקשות |
זמן ההתאוששות של צומת הצטמצם בזכות כך שהשחתה מזוהה לפי בדיקות ולא לפי תלונות משתמשים, והתעבורה עוברת לאתר השכן עוד לפני עלייתו המלאה. שיעור השגיאות ירד לא רק בגלל המעבר לסמיכות למשתמשים, אלא גם משום שכשל של צומת אחד חדל להיות כשל של השירות.
במה נבדלת הרצה באזור אחד מהרצה בכמה
התשובה תלויה במה שאתם מייעלים: זמן התגובה אצל המשתמש או פשטות התפעול.
באתר אחד את כל הבקשות משרתים צומת אפליקציה אחד ובסיס נתונים אחד — ההשהיה נקבעת כולה לפי מרחק המשתמש מהנקודה הזו, והעקביות בנתונים מושגת "בחינם": כתיבה וקריאה הולכות לאותו אחסון, ואין מרוצים בין שכפולים.
כל עוד הקהל יושב באזור אחד, סכמה כזו זולה יותר לתחזוקה ופשוטה יותר לדיבוג: מערכת לוגים אחת, סכמה אחת, תרחיש התאוששות אחד.
עם הופעת האזור השני, להשהיה מתווספת לא מהירות אלא קואורדינציה. Fly.io מנתב את התעבורה לאתר הקרוב, וזה חוסך זמן רק בקריאה מהעותק המקומי: הכתיבה בכל מקרה עוברת לשם נמצא בסיס הנתונים המוביל, ולכן המשתמש מהאזור המרוחק משלם עליה כשהיה.
גיבוי צמתים משנה את סוג הכשלים. שני אתרים הופכים נפילה של אזור מהשבתה להשחתה: בדיקת החיות מוציאה את הצומת מהרוטציה, והתעבורה עוברת לשכן. אך יש להחליט מראש לאן עוברת הכתיבה, כמה נתונים מותר לאבד וכיצד תתנהג האפליקציה בעת המעבר.
עקביות היא המחיר העיקרי של הפיזור. המשתמש צריך לראות את הרשומה שלו עצמו מיד לאחר יצירתה, ולכן מצמידים את ההפעלה לצומת, הופכים בקשות חוזרות לאידמפוטנטיות, ומיישמים מיגרציות סכמה באופן עוקב בכל האתרים.
אם הקהל מפוזר באופן לא אחיד, האתר השני לעיתים קרובות מסבך את התפעול יותר משמעותית מאשר מאיץ את עבודת המשתמשים.
ספקות טכניים נפוצים לפני ההתחלה
הספקות בשלב הזה הם בדרך כלל אותם ספקות: מה לעשות עם אפליקציה שכבר עובדת, כיצד להבין היכן בדיוק הולך לאיבוד זמן התגובה, ומה יישאר אם נצטרך להחליף פלטפורמה. להלן תשובות קצרות וענייניות.
אצלנו כבר פרוסה אפליקציה — נצטרך לכתוב אותה מחדש?
בדרך כלל לא. האפליקציה נבנית לתמונה ומתוארת בקובץ קונפיגורציה, ולכן עוברת יחד עם הלוגיקה; משתנים נקודות כניסה, משתני הסביבה וכללי הוצאת הגרסאות. תחילה מרימים עותק בקונטור בדיקה, משווים התנהגות, ורק אחר כך מעבירים את תעבורת העבודה.
כיצד להבחין בין בעיה בסכמת הפריסה לבעיה בקוד?
מסתכלים על פילוח זמן התגובה: אם הבקשה אורכת זמן רב עד האפליקציה ובחזרה, אך בתוך העיבוד הזמן אינו גדל, צוואר הבקבוק הוא במסלול ובסמיכות למשתמש. אם לעומת זאת המטפל עצמו מתארך, הבעיה בקוד, בבקשות לבסיס הנתונים או במשימות רקע. אנחנו לוקחים מדידות בשני הקטעים ומראים היכן בדיוק הולכות לאיבוד המילישניות.
כיצד לוודא שזמן התגובה באמת השתפר?
משווים תרחישים זהים לפני ואחרי: זמן עד הבייט הראשון, שיעור הבקשות שנכנסו לסף היעד, וההתנהגות בעומס שיא. המדידות מגיעות מכמה נקודות גיאוגרפיות, כדי שהתמונה לא תהיה ממוצעת. את התוצאה מתעדים בדוח — לפני ואחרי, לפי אותם מדדים.
מה יקרה אם נחליט לעבור לספק אחר?
האפליקציה נשארת שלכם: התמונה, הקונפיגורציה וכללי ההוצאה מונחים במאגר הקוד שלכם, בלי תוספות סגורות. מעבר לספק אחר אורך ימים ולא חודשים, ואנחנו מלווים אותו כעבודה נפרדת. כבילה אלינו בארכיטקטורה אינה נשארת — רק תיעוד וגישות, שאותם אנחנו מעבירים לכם.
נדון במשימה שלכם ונחזור עם תוכנית עבודה
כדי שההערכה ותוכנית העבודה יתבססו על עובדות ולא על הנחות, דרושים לפחות נתוני בסיס. אספו את מה שכבר יש בהישג יד: חלק מהמידע בוודאי נמצא בניטור ובמאגר הקוד, ואת השאר נבהיר בשיחה. זה מספיק כדי לדון במשימת ההגדרה באופן ענייני ולציין לוחות זמנים ריאליים.
- סכמת הקונטור הנוכחי: אילו אזורים מעורבים, היכן יושבים בסיס הנתונים, המטמון והתורים, כיצד התעבורה מגיעה לאפליקציה ומה כבר פרוס ב-Fly.io.
- פרופיל עומס: תנועה בשיא ובממוצע, יחס קריאה-כתיבה, זינוקים עונתיים והמשרעת שלהם.
- דרישות לזמן תגובה: אילו פעולות קריטיות, מאילו מדינות מגיעים המשתמשים, איזה זמן תגובה נחשב קביל ואיזה — סיבה לדאגה.
- מגבלות: כללי אחסון נתונים אישיים, דרישות להפרדת סביבות, חלון מותר לתחזוקה ולעדכונים.
- כשלים נוכחיים: ייצוא מהניטור והלוגים, ניתוח אירועים מהחודשים האחרונים, מה כבר ניסיתם ומדוע הפתרון לא התאים.
- צוות וגישות: מי אחראי על התשתית, אילו תפקידים דרושים בפאנל הניהול, כיצד בנויה הגישה למאגר הקוד ולסודות.
- תוכניות צמיחה: הגידול הצפוי בעומס, אזורים חדשים, מהדורות כרוכות ותאריכי השקה קשיחים.
בהמשך אנחנו עוברים על החומרים האלה, מסמנים חסרים ונקודות שנויות במחלוקת, ושואלים שאלות הבהרה ענייניות. התוצר — הערכה ותוכנית עבודה: שלבים, סדר ההשקה, תחומי אחריות ונקודות בקרה שבהן אתם רואים תוצאה.
אם חלק מהנתונים חסר — לא נורא, נרכיב את התמונה יחד ונאמר בכנות מה אפשר לעשות עכשיו ומה דורש שלב נפרד.