GCP Cloud Load Balancer עם Terraform ו-Cloud Armor: הגדרה מלאה

GCP Cloud Load Balancer: היכן ההגדרה נשברת

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

מאזן העומס Google Cloud מחשיב את ה-backends כבריאים, והמשתמש מקבל 502 — וכך בדיוק עד שמישהו מתקן ידנית ישירות בקונסול.

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

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

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

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

מה נותנת איזון עומסים מנוהל

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

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

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

Terraform מחזיק את ה-state בקוד, ולכן הגרסה התקינה הקודמת תמיד מתוארת ומשוחזרת, ולא משוחזרת מהזיכרון.

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

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

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

מצבי איזון עומסים: השוואת גישות

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

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

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

סדר היישום: ביקורת, הגדרה, בדיקה

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

1. ביקורת התשתית הנוכחית. מתעדים את הסכימה בפועל: נקודות כניסה של תעבורה, שירותי יעד, כללי ניתוב, בדיקות מצב, הגדרות הגנה ומה שמוגדר ידנית ולא מתועד בשום מקום.
2. תיאור התשתית כהגדרה. מאזן העומס, שירותי היעד, בדיקות המצב וכללי Cloud Armor מועברים למודולי Terraform עם הפרדה לפי סביבות. ה-state נשמר מרחוק עם locking, והשינויים עוברים אישור.
3. הגדרת ניתוב והגנה. כללים לפי נתיבים ו-hosts, זמן המתנה לתשובה, שיוך לאזורים, הגבלות קצב בקשות וסינון לפי מאפייני בקשה.
4. החלפת תעבורה. קודם לסכימה החדשה עוברת חלק קטן מהבקשות, המדדים מושווים למעגל הקודם, ואז החלק גדל. גלגול לאחור — החזרת הפיזור בתיקון אחד.
5. בדיקה תחת עומס. הפרופיל חוזר על תרחישי שיא: פרץ בקשות, כשל של אזור אחד, חיבורים ארוכים. בודקים היכן נכנסות בדיקות המצב ואיך מתנהגות המגבלות.
6. יכולת צפייה. מדדי השהיה, שיעור שגיאות ומצב שירותי היעד מרכזים בדשבורד, והתראות משייכים לתסמיני כשל, ולא לצמתים בודדים.
7. מסירת הגדרה. מוסרים repository, סכימת סביבות, סדר שינויים טיפוסיים ותקנון גלגול לאחור, ועוברים על הכול עם הצוות שלכם בתיקון חי.

מה מוסרים: מודולי Terraform, מדיניות, תקנונים

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

• מודולי Terraform — רשת, מאזן עומסים וקבוצות instance מתוארים בקוד עם משתנים לפי מעגלים: סביבת בדיקה וסביבת production נפרסות מאותו סט עם ערכים שונים. ה-state נשמר מרחוק עם locking, ולכן החלות במקביל לא הורסות את התשתית.
• מדיניות Cloud Armor — כללי סינון בפרימטר החיצוני: רשתות מהימנות, הגבלת קצב בקשות, הגנה מפני התקפות טיפוסיות. כללים חדשים פועלים קודם במצב ניטור ועוברים לחסימה רק לפי סטטיסטיקה שנצברה.
• סכימות ארכיטקטורה — זרימות תעבורה, נקודות כניסה, פיזור לפי אזורים, בדיקות זמינות ולאן תעבורה תעבור בכשל של צומת.
• תקנון תפעול — איך מחברים שירות חדש, איך משנים כללי הגנה, באילו חלונות לבצע שינויים ובאיזה סדר לגלגל לאחור.
• תיעוד התשתית — מפת משאבים, תיאור משתנים, מקומות אחסון סודות וסדר הרוטציה שלהם.
• הוראות לאירועים טיפוסיים — עלייה בשיעור שגיאות, זינוק בהשהיות, הפעלה שגויה של הגנה: מה בודקים קודם ואיזה צעד מחזיר למצב תקין.

מקרה בוחן: איך צמצמנו כשלים של מאזן העומס

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

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

מה שינו

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

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

במה שונה מאזן עומסים גלובלי מאזורי?

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

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

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

Cloud Armor מתחבר במדיניות אבטחה לשירות backend: אצל הגלובלי הכללים מופעלים בפרימטר, לפני הכניסה לאזור שלכם, ואצל האזורי — כבר בפנים. המשמעות של פשטות כזו — מורכבות ההגדרה: סכימה אזורית דורשת ניתוב DNS וסנכרון של certificates ו-backends, ואילו כתובת אחת משרתת את כל האזורים.

כלל עבודה: שירות HTTP(S) ציבורי עם משתמשים במדינות שונות — גלובלי; דרישה להחזיק תעבורה באזור אחד או פרוטוקול לא תקני — אזורי.

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

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

האם ההגנה לא תתחיל לחסום משתמשים אמיתיים?

כללי Cloud Armor פועלים קודם במצב preview: התאמות נרשמות בלוגים, אבל בקשות לא נדחות. מהלוגים רואים מי попадает תחת הכללים — לחריגים מוסיפים subnet-ים של משרדים, רובוטים של מנועי חיפוש ופניות של ספק תשלומים. החסימה מופעלת כשמספר ההפעלות השגויות הוא אפס.

מה יישאר לצוות לאחר ההשקה?

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

עד כמה קשה לתחזק את זה בכוחות עצמכם?

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

נדון בסכימת איזון העומסים וההגנה שלכם

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

• סכימת תעבורה: אילו שירותים מקבלים בקשות, מאילו אזורים, לפי אילו פרוטוקולים והאם נדרש מאזן חיצוני או פנימי;
• מצב נוכחי: האיזון נבנה ידנית בקונסול, מתואר חלקית ב-Terraform או עולה מאפס;
• דרישות הגנה: אילו כללי Cloud Armor נדרשים — הגבלת קצב בקשות, רשימות כתובות, סינון לפי מאפייני בקשה;
• גישות וגבולות עבודה: פרויקטים בענן, הרשאות service account, סביבות נפרדות לבדיקות, מי מאשר שינויים;
• מצב תפעול: חלון לעבודה, דרישות לגלגול לאחור להגדרה הקודמת וסדר בדיקה לאחר שינויים;
• ציפיות לזמינות: זמינות יעד, השהיה מותרת, מה נחשב כשל ואיך אתם יודעים עליו.

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