הגדרת Azure SQL Database: היכן התשתית נשברת
ההגדרה של Azure SQL Database מתחילה לא בבחירת שכבת השירות, אלא בתשובות על פרופיל העומס: מי קורא, מי כותב ומה יקרה בעת כשל של צומת. העברת בסיס הנתונים לענן עוברת בשקט, אבל צווארי הבקבוק בעומס מתגלים מאוחר יותר — כשדיווחים ומשימות רקע מתחילים להתחרות בטרנזקציות על אותם משאבים.
הכשל הראשון — גידול בעומס הקריאה. שאילתות אנליטיות כבדות עוברות לאותו מופע שמשרת את הכתיבה, והראשונות להיפגע הן פעולות השלמת ההזמנה. זה לא מטופל רק בהעלאת שכבה: חלק מהקריאה מועבר לרפליקות לקריאה בלבד, הדיווחים — לעותק נפרד או למאגר אלסטי, ושאילתות חמות מקבלות אינדקסים מכסים.
המקור השני — נעילות. טרנזקציה ארוכה מחזיקה שורות, האפליקציה ממתינה, ופסקי הזמן גדלים במפל. בודקים את מצב הבידוד מבוסס התמונות, את משך החיים של טרנזקציות, תוכניות שאילתה וסטטיסטיקת המתנות: לרוב הסיבה היא בהמרות טיפוסים מרומזות ובהיעדר אינדקס לסינון מסוים, ולא במחסור בכוח מחשוב.
השלישי — עמידות בסיס הנתונים בפני כשל בלי תוכנית מעבר. רפליקה גאוגרפית או קבוצת מעבר כשל מוגדרות, אבל אף אחד לא בדק תוך כמה זמן האפליקציה תעלה אחרי תקלה והאם הדרייבר יודע להתחבר מחדש. סיכון נפרד — עריכות ידניות: התיאור ב-Terraform סוטה מהמצב בפועל, והפריסה הבאה מבטלת את ההגדרות.
הרביעי — גיבויים שלא נבדקו: משך השמירה, נקודת השחזור והפריסה לשרת נפרד לא תורגלו על ידי איש. גיבוי שממנו לא הועלה בסיס נתונים ולו פעם אחת אינו מהווה ערובה. נבחן כיצד ארבעת המקומות האלה נסגרים באמצעות הגדרה, נוהל והרצות תרגול.
מה משתנה אחרי ההטמעה: זמן השבתה, שחזור, כשלים
אחרי ההגדרה Azure SQL Database הקונטור מתואר בקוד ומתנהג באופן זהה בכל הסביבות: רפליקות באזורי זמינות שונים, מעבר אוטומטי ואפליקציה שעוברת אותו בלי התערבות ידנית.
חלון אי-הזמינות בעבודות מתוכננות ובכשל צומת מתקצר משעות לדקות, וזמן השחזור הופך לכמות צפויה מראש ולא לתוצאה של חיפוש הסיבה.
מה נעלם לתמיד
מחלקה שלמה של כשלים נסגרת ברמת התצורה: אובדן נתונים בגלל היעדר גיבויים, השבתה בהמתנה למנהל מערכת, פערים בהגדרות בין סביבות בגלל עריכות ידניות.
שחזור לנקודת זמן נבחרת הוא הליך שגרתי: הנקודה נבחרת לפי יומן הטרנזקציות, מדיניות שמירת הגיבויים מתועדת ונבדקת בסביבת בדיקות, ולכן זמן החזרה למצב עבודה ידוע מראש.
עומס ונפח צפויים מראש
העומס הופך לצפוי מראש כשמוגבלים המקביליות, גודל מאגרי החיבורים ופרופיל השירות לשיאי שאילתות. יומן ההמתנות וסטטיסטיקת השאילתות מראים את ההידרדרות לפני שהמשתמשים מבחינים בה.
נפח הנתונים לא גורר אחריו עלויות: נתונים חמים נשארים בחלק הפעיל, היסטוריים עוברים לארכיון עם דחיסה וחלוקה למחיצות, ותמונות ישנות נמחקות לפי מדיניות השמירה. עלויות האחסון מפסיקות לגדול, ומרשם הגיבויים מצטמצם פי כמה.
השוואה בין מודלי פריסה ושכבות שירות
ב-Azure SQL Database הבחירה מורכבת משני צירים: מודל הפריסה — בסיס נתונים בודד, מאגר אלסטי, מופע מנוהל — ושכבת השירות בתוכו.
בסיס נתונים בודד נותן בידוד והתנהגות צפויה של האפליקציה, המאגר אוסף רזרבה משותפת לעשרות בסיסי נתונים עם שיאים במועדים שונים, והמופע המנוהל פותח יכולות ברמת השרת.
שכבת השירות קובעת מה עובר לפלטפורמה: ב-General Purpose האחסון נמצא מחוץ לצומת המחשוב, ולכן זמן התגובה רגיש להשהיית קלט/פלט; ב-Business Critical נוספו שכבה מקומית ורפליקה שנייה לקריאה; Hyperscale מרחיב את האחסון במהירות ומשחזר מתמונות.
לוגיקה בזיכרון, שאילתות בין-בסיסיות וסוכן המשימות אינם זמינים בכל מקום — ואלה בדיוק מגבלות התאימות שנבדקות לפני ההעברה.
| אפשרות | מתי מתאימה | מגבלות התצורה |
|---|---|---|
| בסיס נתונים בודד | מוצר אחד, עומס ידוע, נדרש בידוד | רזרבה לשיא נשמרת בכל בסיס נתונים, אין שאילתות בין-בסיסיות |
| מאגר אלסטי | 5+ בסיסי נתונים עם שיאים במועדים שונים, רזרבת משאבים משותפת | אי אפשר להבטיח לבסיס נתונים בודד נתח משאבים, יש תקרה למספר בסיסי הנתונים |
| מופע מנוהל | נדרשים סוכן משימות, שאילתות בין-בסיסיות ושירותים ברמת המופע | חלק מיכולות השירות חסומות, ההרחבה אורכת יותר, ומעבר חזרה — רק במיגרציה |
| Business Critical | זמן התגובה קריטי, נדרשת רפליקה שנייה לקריאה | מגבלות על חלק מפעולות האחסון |
| Hyperscale | גידול מהיר בנפח, שמירת היסטוריה לאורך זמן | חלק מפונקציות התחזוקה אינן זמינות |
החלפת מודל הפריסה היא כמעט תמיד חד-כיוונית, ולכן את התצורה מקבעים לפני המיגרציה: איפה נדרש מאגר, איפה שכבת שירות עם רפליקה מקומית, ואיפה אי אפשר בלי מופע מנוהל. קוד האפליקציה נשאר בלי שינוי — משתנים רק פרמטרים של הפלטפורמה.
הגדרה והטמעה: שלבים מהאודיט עד המסירה
העבודה מתנהלת באותו סדר גם עבור בסיס נתונים חדש וגם עבור העברה של קיים: קודם מתעדים עובדות על העומס, אחר כך מתכננים, מגדירים ורק אחרי בדיקה מוסרים לתפעול. כך נחסך התרחיש הטיפוסי שבו עמידות בפני כשל נבנתה לפי תבנית ומתפוררת מול פרופיל השאילתות האמיתי של Azure SQL Database.
- אודיט עומס. אוספים סטטיסטיקה של המתנות, נעילות, גידול נתונים ושיאים לפי שעות, מנתחים תוכניות שאילתה כבדות — שכבת השירות נבחרת לפי הפרופיל, לא לפי הערכה.
- סכימת עמידות בפני כשל. קובעים מה בדיוק צריך לשרוד כשל: אזור, רגיון, אובדן רפליקה. בוחרים טופולוגיית רפליקות, מודל גיבויים וזמן שחזור יעד.
- הגדרה ותשתית כקוד. שרת, בסיס נתונים, כללי גישה וחיבורים פרטיים מתוארים ב-Terraform: הפריסה משוחזרת מאפס, שינויים עוברים ביקורת, ולא נשארות עריכות ידניות בקונסולה.
- בדיקה תחת כשל. לפני העלייה לייצור מריצים מעבר כפוי, כשל אזור והידרדרות תחת עומס, ומתעדים את זמן השחזור בפועל ואת התנהגות האפליקציה.
- תוכנית מעבר. מנסחים סדר פעולות עם תפקידים ונקודות קבלת החלטות: מה מבצעת האוטומציה, ומה מאשר התורן לפי חישוב פרטניבדיקה לאחר ההטמעה ומסירה. אוספים מדדים על תעבורה בייצור, משווים ליעדים ומוסרים את הסכימה, התצורה, נוהל המעבר וצ'ק-ליסט התפעול.
תצורות, סכימות עמידות בפני כשל ונוהלים
אחרי מסירת הפרויקט נשאר לצוות שלכם לא אוסף של סיכומים בעל פה, אלא תיעוד שלפיו אפשר לתפעל את התשתית, להרחיב אותה ולהעביר אותה למהנדס אחר. את מצב בסיס הנתונים Azure SQL Database אנחנו מקבעים כקוד ומצרפים אליו סכימות, מדיניות ונוהלים — הכול במאגר שלכם, עם היסטוריית שינויים וביקורת.
- תיאור התשתית ב-Terraform: שרתים, בסיסי נתונים, מאגרים, כללי רשת ופרמטרים של שכבת השירות — התצורה ניתנת לשחזור, שינויים עוברים ביקורת ולא עריכות ידניות בקונסולה.
- סכימות תשתית: טופולוגיית הפריסה, רפליקציה, מעבר לרגיון גיבוי, נקודות כניסה של האפליקציות, קישורים לרשתות פרטיות ולניטור.
- מדיניות גיבוי: עומק השמירה של גיבויים מלאים ודיפרנציאליים, לוח זמנים, בדיקה תקופתית של שחזור בסביבת בדיקות עם מדידת זמן.
- נוהל גישה: מטריצת תפקידים, הפרדה בין הרשאות ניהול להרשאות קריאה, סדר הקצאה ושלילה, חיבור רק דרך שער מאובטח.
- תיעוד תפעול: תחזוקה מתוכננת, שינוי שכבת השירות והרחבה, ניתוח כשלים טיפוסיים וסדר הפעולות בעת הידרדרות.
- תרחיש התאוששות מאסון: חזרה לנקודת שחזור, מעבר לרפליקה וקריטריונים שלפיהם התורן מקבל החלטה.
- נוהל שינוי סכימה: כללים להרצת מיגרציות, בדיקות בסביבת בדיקות, סדר חזרה אחורה של גרסה שנכשלה.
מקרה בוחן: זמן שחזור ועומס שיא לפני ואחרי
שירות עם שיאים קצרים: העומס התרכז בכמה חלונות ביממה, ובסיס הנתונים בתעריף הכללי נכנס בשעות האלה לתור המתנה. זמן התגובה צנח, חלק מהשאילתות נקטעו בגלל חריגה מזמן ההמתנה, וכשל בצומת טופל ידנית — השחזור נמשך שעות.
העברנו את בסיס הנתונים לשירות המנוהל Azure SQL Database ותיארנו את הטופולוגיה בקוד: שכבת התעריף, רפליקות קריאה, כללי הגיבוי וסדר הטיפול בכשלים משוחזרים כעת מהתיאור ולא נבנים ביד. סביבות הבנייה והייצור הפסיקו להיות שונות — פערי תצורה גרמו למחצית מהחקירות הליליות.
מה השתנה במספרים
| מדד | לפני | אחרי |
|---|---|---|
| עומס שיא | שאילתות בתור, חלקן לא עוברות | השיא עובר בלי הידרדרות, מרווח לגידול כפול |
| זמן שחזור | שעות של פעולות ידניות | דקות לפי נוהל מתורגל |
| אירועים בחודש | קבועים, עם חקירות ליליות | בודדים, הסיבה מאותרת לפי היומן |
| פעולות ידניות | עריכות בפורטל לכל גרסה | פריסה מהתיאור, חזרה אחורה בפקודה אחת |
מה זה נתן לצוות
התורן הפסיק להיות צוואר בקבוק: כשל טיפוסי נסגר לפי הנחיות ולא בחיפוש אחר החוליה האשמה. הזמן שהתפנה עבר לפיתוח המוצר, ולא לכיבוי שיאים ולעריכות תצורה ידניות.
במה מופע מנוהל שונה מבסיס נתונים בודד?
מופע מנוהל הוא כמעט SQL Server מלא בתת-רשת פרטית: עובדים שאילתות בין-בסיסיות לפי שמות תלת-חלקיים, משימות סוכן, שרתים מקושרים, גיבוי ושחזור סטנדרטיים.
בסיס נתונים בודד הוא שירות לסכימה אחת: הוא לא רואה בסיסי נתונים שכנים, והניהול מצטמצם להגדרות של בסיס הנתונים עצמו ושל שכבת השירות שלו.
הקריטריון הראשון לבחירה — תאימות האפליקציה. אם הקוד צמח ממונוליט ופונה לבסיס נתונים שכן בשם תלת-חלקי, והעיבוד הלילי תלוי במשימות סוכן, העברה לבסיס נתונים בודד תחייב לכתוב מחדש את הפניות האלה ולהוציא את המשימות החוצה.
למעבר בכיוון ההפוך אין מגבלות כאלה: בסיס נתונים ממופע מנוהל מוציאים לשירות נפרד בלי שינויי קוד, ולכן בטוח יותר להתחיל מהמופע.
הקריטריון השני — רשת. המופע המנוהל חי ברשת הווירטואלית שלכם, אין לו כתובת ציבורית, והתעבורה מגיעה רק מכתובות פרטיות. אם נוהל האבטחה דורש קונטור סגור, זה מיד פוסל תרחישים עם חיבור חיצוני של בסיס נתונים בודד.
הקריטריון השלישי — מודל התחזוקה. המופע שומר משאבים לעצמו, ובסיסי נתונים שכנים לא משפיעים על העומס שלכם; בסיס נתונים בודד גמיש יותר בשכבת השירות ונכנס להשהיה בזמן חוסר פעילות, אבל חולק כוח מחשוב עם אחרים. Terraform מתאר את שני המודלים באופן הצהרתי — שכבת שירות, אזור רזרבה, קבוצת מעבר כשל.
מכאן כלל עבודה: מערכת עם קשרים מוצלבות מעבירים למופע מנוהל, ושירות חדש עם סכימה אחת מרימים על בסיס נתונים בודד. את ההחלטה מקבלים לפי דרישות האפליקציה ונוהל האבטחה, ולא מתוך הרגל.
ספקות טכניים נפוצים וגבולות הישימות
את גבולות הישימות מקבעים לפני ההתחלה: האם בסיס נתונים ייעודי מתאים לפרופיל העומס או שמאגר אלסטי משתלם יותר, איזו רמת יתירות נדרשת, ואיך תתנהג האפליקציה על רפליקות לקריאה בלבד. להלן תשובות לשאלות שצפות לרוב בשלב ההערכה.
תאימות האפליקציה — האם יהיה צורך לכתוב משהו מחדש?
בדרך כלל לא, אם האפליקציה עובדת דרך דרייבר סטנדרטי ולא נשענת על נתיבי קבצים בשרת, טריגרים בין-בסיסיים ודרכי אימות מיושנות. אנחנו מריצים את מערך השאילתות האמיתי ואת פרופיל הטרנזקציות בסביבת בדיקות לפני ההעברה: פערים בתוכניות ההרצה ובנעילות נראים מראש, ולא אחרי העברת התעבורה.
איך מתבצע המעבר והאם אפשר לחזור אחורה?
המעבר מנוהל: עוצרים את הכתיבה, מרוקנים את תור הרפליקציה, משווים סכומי ביקורת, מחליפים את מחרוזת החיבור ומחזירים את התעבורה. חזרה אחורה נשארת אפשרית כל עוד סביבת המקור לא הוצאה משימוש — את נקודת האל-חזור מתעדים בנוהל מראש.
מה עם גישה, עדכונים ובדיקת עמידות בפני כשל?
הרשאות גישה מחולקות לפי תפקידים דרך ספרייה מרכזית, חשבונות שירות — רק למשימות מוגדרות, סודות נשמרים במאגר מאובטח ולא בקבצי תצורה. התחזוקה מתבצעת בחלון מוסכם; נוהל העדכונים מתאר את הסדר ואת מועד ההודעה.
בדיקת העמידות בפני כשל נערכת לפני המסירה: מדמים כשל של צומת ושל רגיון, מודדים את זמן השחזור ואת שלמות הנתונים, ומתעדים את התוצאה בפרוטוקול. אם התרחיש לא עומד ביעדים — משנים את התצורה לפני הקבלה, ולא אחריה.
נדבר על המשימה: מה ייכלל בתוכנית השלב הראשון
כדי שהערכת לוחות הזמנים תישען על עובדות, את השלב הראשון מתחילים בניתוח המצב הנוכחי: איזו שכבה ומודל רכישה משמשים, איך מתחלק העומס בין קריאה לכתיבה, איפה צווארי הבקבוק בקלט/פלט ובנעילות, ואיך התשתית נפרסת כיום.
אחר כך בוחנים אפשרויות לתצורת היעד ורק לאחר מכן נוקבים בלוחות זמנים — אחרת המספר נלקח מהאוויר ומתפורר בשינוי העומס הראשון.
עם ההערכה ותוכנית העבודה אנחנו חוזרים עם מערך מוגדר של ארטיפקטים:
- סכימת תצורת היעד: שכבה לפי פרופיל העומס, מודל רכישה, פרמטרי הרחבה ותקרות שבהן בסיס הנתונים יתחיל להיתקע;
- מודולי Terraform לפריסת בסיס הנתונים, כללי הגישה והמשאבים המקושרים — עם ניהול גרסאות ודרך ברורה להעביר תצורה בין סביבות;
- מדיניות גיבוי ושחזור: תקופות שמירת הגיבויים, שחזור לנקודת זמן, ובדיקה שהגיבוי אכן נפרס;
- סכימת עמידות בפני כשל: רפליקציה, סדר המעבר בכשל רגיון, זמן אי-הזמינות הצפוי ונקודת אובדן הנתונים;
- ניטור והתראות: מדדי צריכה, המתנות, נעילות הדדיות, גידול ביומני טרנזקציות — עם ספים שבהם מגיע אות ולא ניתוח בדיעבד;
- תוכנית עבודה לפי שלבים עם הערכת לוחות זמנים, תפקידים ונקודות קבלה בכל שלב;
- סדר תפעול לצוות שלכם: פעולות שגרתיות, חזרה אחורה, ומה עושים בעת הידרדרות.
תארו את המשימה — התצורה הנוכחית, המגבלות ומה כואב ביותר. נחזור עם הערכת לוחות זמנים ותוכנית עבודה לשלב הראשון.