פריסת הכלי למידרוג אוטומטי בפונקציות Cloud Run

הכלי Autoscaler נועד לספק גמישות, והוא יכול להתאים להפרדה הקיימת של האחריות בין צוותי התפעול והאפליקציות. אפשר לרכז את האחריות להגדרת התאמה אוטומטית לעומס (automatic scaling) של מופעי Spanner בצוות תפעול יחיד, או לחלק אותה בין הצוותים שקרובים יותר לאפליקציות שמוגשות על ידי מופעי Spanner האלה.

המסמך הזה הוא חלק מסדרה שכוללת גם:

הסדרה הזו מיועדת לצוותי IT, צוותי תפעול וצוותי Site Reliability Engineering‏ (SRE) שרוצים לצמצם את התקורה התפעולית ולבצע אופטימיזציה של העלות של פריסות Spanner.

בדף הזה מוצגות שלוש דרכים לפריסת Autoscaler בפונקציות Cloud Run, בהתאם לדרישות שלכם:

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

ללא שרת (serverless) כדי להקל על הפריסה והניהול

במודל הזה, הכלי Autoscaler מבוסס רק על כלים ללא שרת (serverless) וכלים עם ניהול נמוך Google Cloud , כמו פונקציות Cloud Run,‏ Pub/Sub,‏ Cloud Scheduler ו-Firestore. הגישה הזו מצמצמת את העלות ואת התקורה התפעולית של הפעלת הכלי Autoscaler.

באמצעות כלים מובנים Google Cloud , המידרוג האוטומטי יכול לנצל באופן מלא את ניהול זהויות והרשאות גישה (IAM) לאימות והרשאה.

הגדרות אישיות

הכלי Autoscaler מנהל את מופעי Spanner באמצעות ההגדרה שמוגדרת ב-Cloud Scheduler. אם צריך לבצע סקר של כמה מופעי Spanner באותו מרווח זמן, מומלץ להגדיר אותם באותה משימה של Cloud Scheduler. ההגדרה של כל מופע מיוצגת כאובייקט JSON. הדוגמה הבאה מציגה הגדרה שבה שני מופעי Spanner מנוהלים באמצעות משימה אחת של Cloud Scheduler:

[
  {
    "projectId": "my-spanner-project",
    "instanceId": "my-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "NODES",
    "minSize": 1,
    "maxSize": 3
  },
  {
    "projectId": "different-project",
    "instanceId": "another-spanner",
    "scalerPubSubTopic": "projects/my-spanner-project/topics/spanner-scaling",
    "units": "PROCESSING_UNITS",
    "minSize": 500,
    "maxSize": 3000,
    "scalingMethod": "DIRECT"
  }
]

למופעי Spanner יכולות להיות כמה הגדרות במשימות שונות של Cloud Scheduler. לדוגמה, למופע יכולה להיות הגדרה אחת של Autoscaler עם השיטה הליניארית לפעולות רגילות, אבל יכולה להיות לו גם הגדרה אחרת של Autoscaler עם השיטה הישירה לעומסי עבודה מתוכננים של אצווה.

כשמשימת Cloud Scheduler מופעלת, היא שולחת הודעת Pub/Sub לנושא Pub/Sub של הסקר. המטען הייעודי (payload) של ההודעה הזו הוא מערך JSON של אובייקטי התצורה של כל המופעים שהוגדרו באותו ג'וב. רשימת האפשרויות המלאה להגדרות מופיעה בקובץ Poller README.

טופולוגיה לכל פרויקט

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

בתרשים הבא מוצגת תצוגה קונספטואלית כללית של פריסה לכל פרויקט.

פריסה קונספטואלית לכל פרויקט.

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

  • שתי אפליקציות, Application 1 ו-Application 2, כל אחת משתמשת במופעי Spanner משלה.
  • מכונות Spanner‏ (A) נמצאות בפרויקטים המתאימים של אפליקציה 1 ואפליקציה 2.
  • בכל פרויקט נפרס מידרוג אוטומטי עצמאי (B) כדי לשלוט בהתאמה האוטומטית לעומס של המכונות בפרויקט.

לפריסה בכל פרויקט יש את היתרונות והחסרונות הבאים.

יתרונות:

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

חסרונות:

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

במדריך המפורט לפריסה לפי פרויקט מוסבר איך להגדיר את Autoscaler באמצעות טופולוגיה לפי פרויקט.

טופולוגיה מרכזית

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

התרשים הבא מציג תצוגה קונספטואלית כללית של פריסת פרויקט מרכזי:

פריסת פרויקט מרכזית קונספטואלית.

המאפיינים של הפריסה המרכזית שמוצגת בתרשים שלמעלה:

  • שתי אפליקציות, Application 1 ו-Application 2, כל אחת משתמשת במופעי Spanner משלה.
  • מכונות Spanner‏ (A) נמצאות בפרויקטים המתאימים של אפליקציה 1 ואפליקציה 2.
  • המידרוג האוטומטי (B) נפרס בפרויקט נפרד כדי לשלוט בהתאמה האוטומטית לעומס של מופעי Spanner בפרויקטים Application 1 ו-Application 2.

לפריסה מרכזית יש את היתרונות והחסרונות הבאים.

יתרונות:

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

חסרונות:

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

כדי ללמוד איך להגדיר את Autoscaler באמצעות טופולוגיה מרכזית, אפשר לעיין במדריך המפורט לפריסה מרכזית.

טופולוגיה מבוזרת

בפריסה של טופולוגיה מבוזרת, מופעי Cloud Scheduler ו-Spanner שצריך להפעיל עבורם שינוי גודל אוטומטי נמצאים באותו פרויקט. שאר הרכיבים של הכלי Autoscaler נמצאים בפרויקט שמנוהל באופן מרכזי. הפריסה הזו היא פריסה היברידית. צוותים שהם הבעלים של מופעי Spanner מנהלים רק את הפרמטרים של הגדרת התאמה לעומס (Autoscaler) עבור המופעים שלהם, וצוות מרכזי מנהל את שאר התשתית של התאמה לעומס.

בתרשים הבא מוצגת תצוגה מושגית כללית של פריסת פרויקט מבוזר.

פריסה קונספטואלית של פרויקט מבוזר.

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

  • שתי אפליקציות, אפליקציה 1 ואפליקציה 2, משתמשות במופעי Spanner משלהן.
  • מכונות Spanner‏ (A) נמצאות בפרויקטים של אפליקציה 1 ואפליקציה 2.
  • רכיב עצמאי של Cloud Scheduler‏ (C) נפרס בכל פרויקט: אפליקציה 1 ואפליקציה 2.
  • שאר הרכיבים של מידרוג אוטומטי‏ (B) נפרסים בפרויקט נפרד.
  • הכלי Autoscaler משנה את גודל המכונות של Spanner באופן אוטומטי בפרויקטים Application 1 ו-Application 2 באמצעות ההגדרות שנשלחות על ידי רכיבי Cloud Scheduler העצמאיים בכל פרויקט.

פונקציית העברה

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

פונקציית ההעברה מקבלת הודעות שפורסמו ב-Pub/Sub מ-Cloud Scheduler, בודקת את תחביר ה-JSON שלהן ומעבירה אותן לנושא Pub/Sub של פונקציית הבדיקה. הנושא יכול להיות שייך לפרויקט נפרד מ-Cloud Scheduler.

בתרשים הבא מוצגים הרכיבים שמשמשים למנגנון ההעברה:

מנגנון העברה.

כפי שמוצג בתרשים הקודם, מופעי Spanner נמצאים בפרויקטים בשם Application 1 ו-Application 2:

  1. פרויקט Cloud Scheduler הוא אותו פרויקט כמו מכונות Spanner.

  2. ‫(2א) Cloud Scheduler מפרסם את ההודעות שלו בנושא Forwarder בפרויקטים Application 1 ו-Application 2.

    ‫(2ב) הפונקציה Forwarder קוראת הודעות מהנושא Forwarder.

    ‫(2ג) הפונקציה Forwarder מעבירה הודעות לנושא Polling שנמצא בפרויקט Autoscaler.

  3. הפונקציה Poller קוראת את ההודעות מהנושא של הסקר, והתהליך ממשיך כמו שמתואר בקטע Poller.

לפריסה מבוזרת יש את היתרונות והחסרונות הבאים.

יתרונות:

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

חסרונות:

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

כדי ללמוד איך להגדיר את Autoscaler באמצעות טופולוגיה מבוזרת, אפשר לעיין במדריך המפורט לפריסה מבוזרת.

המאמרים הבאים