פיתוח צד שרת: היכן המערכת נשברת תחת עומס
צד שרת לעיתים רחוקות נופל מיד — לרוב הוא מדרדר תחת עומס בשלבים: תחילה זמן התגובה עולה בשעות שיא, אחר כך פעולות מסוימות מתחילות ליפול בפסק זמן, ורק לבסוף המערכת הופכת ללא זמינה לחלוטין. בין המצבים האלה אפשר לחיות חודשים, ולתלות את התלונות בחיבור איטי אצל הלקוח.
מקום הכשל הראשון — שאילתות כבדות למאגר הנתונים. שליפה לפי שדה לא מאונדקס, אגרגציה על כל הטבלה או השלמת ישויות קשורות אחת-אחת בלולאה, כשהתעבורה גדלה פי עשרה, הופכים מעשרות מילישניות לשניות, ומאגר החיבורים נגמר מהר יותר משהוא מספיק להתפנות.
השני — נעילות במסד הנתונים. טרנזקציה ארוכה שמעדכנת שורות שנדרשות לשאילתות אחרות אוספת תור של ממתינים; אם לתוך הטרנזקציה נכנסת קריאה לשירות חיצוני, התור גדל ביחס לזמן התגובה שלו. חלק מהשאילתות נופלות, הלקוח חוזר עליהן, והחזרות מוסיפות עומס על תור שכבר עמוס.
השלישי — תורים וכפילות לוגיקה. תור בלי הגבלת גודל ובלי בקרת חזרות גדל מהר יותר מכפי שהמעבד מספיק לפרק אותו, וכל ניסיון חוזר מכפיל את העומס על אותם צמתים.
תרחיש המשוכפל בבקר, בפקודת מסוף ובמעבד, עם הזמן מתפצל: תיקון במקום אחד שובר התנהגות בשני מקומות אחרים, וזה עולה לפני השטח רק באירוע.
עבור המוצר כל זה מתבטא בעלייה בזמן התגובה בשעות שיא, כשלים בחלק מהפעולות וחוסר יכולת להצביע על צוואר הבקבוק של האפליקציה בלי פרופיילינג. להלן כיצד זה נסגר.
השפעה יישומית: מהירות תגובה, כשלים, השבתה
החלטות ארכיטקטוניות נראות לא בתרשימים אלא בגדלים מדידים: כמה המערכת מחזיקה תחת שיא, איזה חלק מהפעולות מסתיים בהצלחה, תוך כמה דקות היא עולה לאחר תקלה. פרופיילינג ותורים על Symfony מספקים את המספרים האלה לפני הוצאה לאור, ולא אחרי אירוע. להלן ארבעה אפקטים שהלקוח בודק לפי המדדים שלו.
זמן תגובה תחת עומס
מפרידים בין קריאה לכתיבה, מוציאים פעולות כבדות לעיבוד ברקע, שמים במטמון את מה שנקרא לעיתים קרובות יותר משמשתנה. זמן התגובה של התרחיש הראשי נשאר בטווח העבודה גם כשמספר הפניות גדל פי כמה: הדרדור מתחיל מאוחר יותר ונראה במדדים לפני שהוא נראה בתלונות.
יכולת חיזוי המערכת וסוג הכשלים
שירות חיצוני מגיב באיחור או שותק — זה לא אמור להפיל את ביצוע ההזמנה. הגבלת ניסיונות חוזרים, בידוד תקלות ופעולות אידמפוטנטיות מעבירים חלק מהשגיאות לסוג של תקלות שמתקנות את עצמן: התור משלים עיבוד, המשתמש מקבל אישור. נעלם סוג כשלים שבעבר דרש תיקון ידני של נתונים.
זמן התאוששות ועלות השבתה
פריסה ללא עצירת השירות, מיגרציות בנפרד מהקוד, חזרה לגרסה קודמת בפקודה אחת — ההתאוששות נמדדת בדקות, לא בשעות של תיאומים. ככל שחלון ההשבתה קצר יותר, כך יש פחות הזמנות שהוחמצו ופניות לתמיכה.
פורמטים של פיתוח צד שרת: מונוליט, מודולים, שירותים
ארכיטקטורת צד השרת קובעת כמה עולה לחבר צוות שני וכמה מהר אפשר לכתוב מחדש פונקציה אחת בלי לפגוע באחרות. ב-Symfony ניתנים למימוש כל שלושת הווריאנטים; ההבדל אינו בכלים אלא היכן עוברים גבולות המודולים וכמה חזק הקוד תלוי זה בזה.
לכן בחירת הארכיטקטורה היא תשובה לשאלות "כמה אנשים עובדים על הפרויקט בו-זמנית" ו"האם חלקיו עמוסים באופן שונה".
| אפשרות | מתי מתאים | מגבלות |
|---|---|---|
| מונוליט יחיד | צוות אחד, התחום עוד מתבהר, חשובה מהירות הגרסה הראשונה | גבולות המודולים מיטשטשים, הצימוד בקוד גדל, תיקון אחד דורש הרצה מלאה של בדיקות והוצאה מלאה של גרסה |
| מונוליט מודולרי | 2–4 צוותים, התחום ברור, חלקי המערכת מתפתחים בקצב שונה | נדרשת משמעת: כללי התלויות בין המודולים נבדקים אוטומטית, אחרת הגבולות נעלמים תוך חודשיים |
| ארכיטקטורת שירותים | חלקי המערכת עמוסים בצורה לא אחידה או דורשים סקיילינג נפרד ומחזור הוצאה משלהם | התפעול יקר יותר: עקביות נתונים בין שירותים, כשלי רשת, סביבות נפרדות ונראות לכל אחד |
ברוב המקרים אנחנו מתחילים ממונוליט מודולרי: הוא נותן גבולות ברורים בין מודולים ותלות נמוכה בין חלקי הקוד, אך נשאר אפליקציה אחת לפריסה — זה זול יותר גם בפיתוח וגם בתמיכה.
הפרדת שירותים היא המשך האבולוציה, לא החלטת פתיחה: כשהעומס על חלק מסוים גדל פי כמה, המודול מוציאים בנפרד, ושאר הקוד לא נכתב מחדש.
סדר היישום: מביקורת קוד ועד מסירה לתפעול
את העבודה מנהלים בשלבים, וכל שלב מסתיים בארטיפקט שניתן לבדוק, לא בדוח על מה שנעשה. את הסדר מקבעים לפני ההתחלה: קודם מבינים מה כבר עובד, אחר כך משנים את סכימת הנתונים והתצורה, לאחר מכן בודקים התנהגות תחת עומס — ורק אחרי זה מוסרים לתפעול עם נהלים.
- ביקורת קוד ותשתיות. בוחנים את מבנה הפרויקט, כפילות של לוגיקה עסקית, אזורים בלי בדיקות, תלויות סמויות בין מודולים. בתוצר — רשימת צווארי בקבוק עם הערכת סיכון וסדר עדיפות לתיקונים.
- סכימת נתונים וגבולות אחריות. קובעים היכן מקור האמת, אילו קשרים הכרחיים, אילו אינדקסים נדרשים לשליפות אמיתיות. את הגבולות בין המודולים מתארים בסכימה ובכללי החלפה — זה מסיר חצי מהתיקונים השנויים במחלוקת בעתיד.
- הגדרת סביבות ותצורה. מביאים את הסביבה המקומית, סביבת הבדיקות וסביבת העבודה לצורה אחת, מוציאים סודות מהקוד, מתארים מיגרציות כך שיעברו בלי צעדים ידניים ולא יחסמו את הפריסה.
- בדיקה תחת עומס. מצלמים פרופיל של בקשות אמיתיות, משחזרים תרחיש שיא, בודקים היכן זמן התגובה גדל וכיצד המערכת מדרדרת — בתורים, בכשלים או בפעולות נדחות.
- תיקונים לפי צווארי בקבוק. שליפות כבדות, אחסון ביניים של תשובות תכופות, הוצאת משימות רקע — משנים את מה שאושר במדידות, לא את מה ש"בדרך כלל איטי".
- מסירה לתפעול. מוסרים את הפרויקט יחד עם נהלי עדכונים: סדר הפריסה, תנאי חזרה לגרסה קודמת, הרשאות, נקודות בקרה וסדר פעולות באירוע.
מה נשאר בפרויקט לאחר המסירה: תרשימים, מדיניות, נהלים
מסירת קוד בלי תיעוד משמעה שהמערכת חיה עד התקלה הרצינית הראשונה או עד החלפת ספק. לכן המסירה היא אוסף ארטיפקטים שלפיהם מהנדס שלא ראה את הפרויקט פורש את המערכת, משחזר אותה ומשנה הרשאות גישה. הכול נשמר לצד הקוד ומתעדכן יחד איתו, ולא בתיקייה נפרדת.
- תיאור ארכיטקטורה: גבולות השירותים, זרימות נתונים, תורים, מטמון, אינטגרציות חיצוניות ונקודות כשל — עם תרשים אינטראקציה.
- סכימות נתונים: מודל ישויות וקשרים, היסטוריית מיגרציות, כללי אחסון ומחיקה של נתונים אישיים.
- מדיניות גישה ותפקידים: מטריצת "תפקיד — פעולה — משאב", סדר הענקה ושלילה של גישות, מקום אחסון הסודות.
- סכימת פריסה: הרכב הסביבות, תצורה ומשתני סביבה, סדר הפריסה וחזרה לגרסה קודמת.
- נהלי גיבוי: מה ובאיזו תדירות מגבים, תקופת שמירה, פרוטוקול בדיקת שחזור בסביבה נקייה.
- נהלי עדכונים: סדר התקנת עדכוני פלטפורמה ותלויות, חלונות עבודה, בדיקת תאימות.
- העברת ידע לצוות: סקירות עם מהנדסי הלקוח, הקלטות מפגשים, רשימת פעולות טיפוסיות ומגבלות ידועות.
התוצאה — אפשר לפתח את המערכת עם צוות משלכם או להעביר לספק אחר בלי לפרק את הקוד. בצד שרת על Symfony חבילה כזו נאספת באופן סטנדרטי: תצורה, מיגרציות ומדיניות כבר מתוארות בפרויקט — נותר לתעד אותן במסמך.
מקרה בוחן: קיצרנו את זמן התגובה והסרנו סוג שלם של כשלים
שירות עם חשבונות אישיים ותעבורה בשיא: בדקות של עומס הבוקר מספר הפניות גדל פי כמה. צד השרת על Symfony החזיק בצומת אפליקציה אחת, ובשיא זמן התגובה הגיע לשניות, וחלק מהבקשות נקטעו בפסק זמן.
המקרה של הפרויקט מאלף בכך שהמדדים נלקחו לפני התיקונים, ואת העבודה מחדש על צד השרת הובלנו לפי צווארי בקבוק, לא לפי תחושות.
היכן היו ההפסדים
בכל בקשת רשימה או כרטיס בוצעו פעולות סינכרוניות כבדות — חישוב אגרגטים מחדש ופניות לשירותים חיצוניים ישירות במעבד. לזה נוספו בקשות מרובות למסד הנתונים לשליפת ישויות קשורות והיעדר מוחלט של מטמון לנתונים חמים: צוואר הבקבוק היה מסד הנתונים, לא המעבד.
בשיא הצטברו נעילות, עובדי התור לא הספיקו לפרק משימות, ואי-זמינות של שירות חיצוני אחד גררה אחריה פסקי זמן של כל חשבון המשתמש.
מה השתנה
חישובים מחדש וקריאות חיצוניות הועברו לתור עם הגבלת מקביליות ומאגרים נפרדים לפי סוגי משימות. שליפות חמות נסגרו במטמון עם ביטול תוקף לפי ישויות קשורות, שאילתות כבדות נכתבו מחדש וחוזקו באינדקסים מורכבים.
לתלויות חיצוניות הוגדרו פסקי זמן קשיחים והתדרדרות מבוקרת: החשבון האישי מחזיר את הנתונים השמורים האחרונים במקום שגיאה.
את המדדים לקחו באותו פרופיל עומס. לפני: זמן תגובה באחוזון 95 — שניות, שיעור התשובות עם שגיאת שרת — אחוזים בודדים, בשיא השירות הדרדר. אחרי: זמן התגובה התקצר פי שבעה, שיעור כשלי השרת — שברי אחוז, תפוקה על אותה חוות שרתים גדלה פי שלושה.
הסרת הכשלים אומתה בבדיקות עומס: מחזיקים שיא של פי ארבעה מהעומס הרגיל בערב, זמן התגובה עולה באופן ליניארי, בלי קריסה והתערבות ידנית.
מה לעשות אם המערכת כבר עובדת ואסור לעצור אותה?
אין צורך לעצור את השירות — העבודה מחדש מתבצעת לצד המערכת הפועלת. קוד חדש עולה על אותם נתונים ובהדרגה מקבל עומס, בעוד שהמסלול הישן ממשיך לשרת בקשות. מצב כזה דורש משמעת: פיצול הלוגיקה במקביל, העברה מדורגת ותאימות לאחור בכל שלב.
בגבול האפליקציה מופיע שכבת התאמה: היא מפנה בקשה או למימוש הנוכחי או לחדש. שני המסלולים עובדים עם אותו מאגר נתונים — הכתיבה נכנסת תחילה לישן, והשינויים משוכפלים, פערים מתועדים ביומן ומטופלים לפני שהענף החדש הופך לראשי.
החוזים מתרחבים ולא נשברים: שדות חדשים הם אופציונליים, צורת התשובות הקודמת נשמרת, ולכן צרכנים חיצוניים לא מבחינים במעבר.
המעבר מתבצע בחלקים — לפי פעולות בודדות, קבוצות משתמשים או פלחי תעבורה. אפשר להעלות את החלק בהדרגה ובכל שלב להחזיר חזרה באמצעות דגל ניהולי, בלי פריסה והשבתה. בכך ההבדל מכתיבה מלאה מחדש: הסיכון מרוכז באזור אחד, ולא מפוזר על פני כל הגרסה.
עבור אפליקציות על Symfony שכבה כזו מתיישבת על ניתוב סטנדרטי ומכיל שירותים — אין צורך בפלטפורמה נפרדת לעבודה במקביל. לפני ההתחלה מקבעים חוזים, סכימת התאמת נתונים, סט מדדים וסדר חזרה: מכאן ההעברה מתבצעת בצעדים צפויים, והמערכת כל הזמן הזה נשארת פעילה.
ספקות טכניים לפני תחילת העבודה
לפני תחילת העבודה הלקוח בודק לא את מהירות הצוות אלא את הסיכונים: מי מחזיק בקוד, מה עם ההרשאות ומה יישאר לאחר עזיבת הספק. הספקות האלה מוסרים לא בהבטחות אלא בסכימת העבודה. להלן תשובות למה ששואלים לרוב.
יש לנו צוות פיתוח משלנו — לשם מה צוות חיצוני?
בדרך כלל זהו מודל משולב: המהנדסים שלנו מכסים את צד השרת על Symfony ואת התשתית, והצוות שלכם — לוגיקה עסקית וממשקים. את הגבולות מקבעים לפי מודולים, כדי שתיקונים לא יתנגשו באותו קוד, ושהמפתחים שלכם יראו כל שינוי.
למי שייכות ההרשאות לקוד ולסביבות?
המאגר, השרתים והדומיינים רשומים על שמכם מהיום הראשון. אנחנו עובדים תחת חשבונות המשתמש שלכם עם הרשאות מוגבלות, ואתם יכולים לשלול אותן בכל רגע. מסירת הפרויקט היא רקע קבוע של העבודה, לא שלב נפרד בסוף.
יש לנו פתרון מיושן — האם תיקחו על זה?
תחילה מפרקים את המצב בפועל: בדיקות, מיגרציות, תלויות, שאילתות חמות. לאחר מכן או החלפה מדורגת במודולים בלי לעצור את המוצר, או בידוד של אזורים בעייתיים והוצאה הדרגתית. את ההערכה נותנים אחרי הניתוח, לא לפניו.
מה עם נפח הנתונים והביצועים?
בוחנים פרופיל עומס: יחס קריאה לכתיבה, גידול טבלאות, השאילתות הכבדות ביותר. בהתאם לכך מגדירים אינדקסים, מטמון ותורים, ואת הדיווח מוציאים מהמסלול הראשי. ריצת עומס חוזרת לפני כל גרסה גדולה.
איך מתבצעת מסירת הפרויקט לצוות אחר?
תיעוד, סכימות נתונים, הגדרות סביבה ונהלי פריסה חיים במאגר יחד עם הקוד. מסירה היא ליווי של הספק החדש בזמן הכניסה, לא תיקייה עם קבצים לפי דרישה.
נדון במשימה: מה דרוש להערכה ותוכנית
הערכת עבודות צד השרת נשענת על נתוני הקלט של הפרויקט, לא על משאלות כלליות. ככל שהתרחישים והמדדים הנוכחיים מתוארים מדויק יותר, כך יש פחות הנחות בתוכנית העבודה, והמועדים של השלבים ומרווח העומס המובנה בארכיטקטורה ריאליסטיים יותר.
כדי לדון במשימה באופן ענייני, מספיק מה שכבר קיים: תיאורי תהליכים, גישות למאגר ולסביבות, נתוני ניטור. לא מחכים למסמכים אידיאליים — אם משהו חסר, נקבע הנחה בתוכנית העבודה ונדקדק אותה בשלב הראשון, בלי להזיז את המועד הכולל.
- תרחישים ותפקידים: אילו פעולות מבצעים משתמשים, מנהלים ומערכות חיצוניות, אילו פעולות קריטיות לזמן התגובה.
- פרופיל עומס: תקופות שיא, יחס קריאה לכתיבה, עונתיות, גידול צפוי במספר הפניות.
- קוד נוכחי: גישה למאגר, ענף עם מצב עדכני, מיגרציות, תלויות, דרישות לסביבת ההרצה.
- אינטגרציות: רשימת שירותים חיצוניים, פרוטוקול החלפה, הצד שאחראי לזמינותם ולשינויים שלהם.
- תשתית והרשאות: סכימת סביבות, גישה ליומנים ולמערכות ניטור, הרשאות להרצת בדיקות עומס.
- מגבלות: דרישות אבטחה, עבודה עם נתונים אישיים, ביקורת פעולות, נהלי הוצאת עדכונים.
- מדדים נוכחיים: זמן תגובה של פעולות קריטיות, תדירות אירועים, צווארי בקבוק ידועים ופתרונות עוקפים.
- קריטריוני קבלה: איזו תוצאה נחשבת מושגת ולפי אילו מדדים נבדוק אותה יחד.
מהסט הזה מרכיבים תוכנית עבודה: חלוקה לשלבים, המועדים שלהם, הרכב הצוות ונקודות בדיקה ביניים שבהן הלקוח רואה תוצאה לפני המסירה הסופית.
