פריסה גלובלית באמצעות Compute Engine ו-Spanner

Last reviewed 2025-08-12 UTC

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

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

ארכיטקטורה

בתרשים הבא מוצגת ארכיטקטורה של אפליקציה שפועלת בתשתית שמפוזרת באופן גלובלי על פני כמה Google Cloudאזורים.

ארכיטקטורת פריסה גלובלית באמצעות Compute Engine ו-Spanner.

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

הארכיטקטורה כוללת את המשאבים הבאים של Google Cloud :

רכיב מטרה
מאזן עומסים גלובלי חיצוני

מאזן העומסים הגלובלי החיצוני מקבל בקשות ממשתמשים ומפיץ אותן לאפליקציה. מאזן העומסים הגלובלי החיצוני מפרסם כתובת IP אחת של anycast, אבל הוא מיושם כמספר גדול של שרתי proxy ב- Google Front Ends (GFE). בקשות של לקוחות מנותבות ל-GFE הקרוב ביותר ללקוח.

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

כדי להגן על האפליקציה מפני איומים כמו מתקפות מניעת שירות מבוזרות (DDoS) ופרצת אבטחה XSS‏ (cross-site scripting), אתם יכולים להשתמש ב מדיניות האבטחה של Google Cloud Armor.

אזורי קבוצות של מופעי מכונה מנוהלים (MIG) לשכבת האינטרנט

שכבת האינטרנט של האפליקציה נפרסת במכונות וירטואליות של Compute Engine ששייכות לקבוצות אזוריות של מכונות מנוהלות (MIG). קבוצות ה-MIG האלה הן שרתי הבק-אנד של מאזן העומסים הגלובלי.

כל קבוצת MIG מכילה מכונות וירטואליות של Compute Engine בשלושה אזורים שונים. כל מכונה וירטואלית מארחת מופע עצמאי של רמת האינטרנט של האפליקציה.

שכבת איזון עומסים פנימית חוצה אזורים

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

בהתאם לדרישות שלכם, אתם יכולים להשתמש ב מאזן עומסים פנימי של אפליקציות (ALB) חוצה אזורים או ב מאזן עומסי רשת פנימי לשרת proxy חוצה אזורים. מידע נוסף זמין במאמר בנושא בחירת מאזן עומסים.

קבוצות אזוריות של מכונות וירטואליות מנוהלות (MIG) לשכבת האפליקציה

שכבת האפליקציה נפרסת במכונות וירטואליות של Compute Engine שהן חלק מקבוצות של מופעי מכונה מנוהלים (MIG) אזוריים. קבוצות ה-MIG האלה הן קצה העורפי (backend) של שכבת איזון העומסים הפנימית.

כל קבוצת MIG מכילה מכונות וירטואליות של Compute Engine בשלושה אזורים שונים. כל מכונה וירטואלית מארחת מופע עצמאי של רמת האפליקציה.

מכונת Spanner במספר אזורים

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

  • ארבעה עותקים לקריאה ולכתיבה באזורים נפרדים בשני אזורים.
  • רפליקת עֵד באזור שלישי.
רשת של ענן וירטואלי פרטי (VPC) ו רשתות משנה

כל המשאבים בארכיטקטורה משתמשים ברשת VPC אחת. ברשת ה-VPC יש את רשתות המשנה הבאות:

  • תת-רשת בכל אזור למכונות וירטואליות של שרת האינטרנט.
  • רשת משנה בכל אזור למכונות וירטואליות של שרת האפליקציות.
  • (לא מוצג בתרשים הארכיטקטורה) רשת משנה של proxy בלבד בכל אזור עבור מאזן העומסים הפנימי בין האזורים.

במקום להשתמש ברשת VPC אחת, אפשר ליצור רשת VPC נפרדת בכל אזור ולחבר את הרשתות באמצעות Network Connectivity Center.

המוצרים שהשתמשו בהם

ארכיטקטורת ההפניה הזו כוללת את המוצרים הבאים Google Cloud :

  • ‫ Compute Engine: שירות מחשוב מאובטח וניתן להתאמה אישית שמאפשר ליצור ולהריץ מכונות וירטואליות בתשתית של Google.
  • ‫ Cloud Load Balancing: חבילה של מאזני עומסים גלובליים ואזוריים בעלי ביצועים גבוהים וניתנים להתאמה.
  • ‫ Spanner: שירות של מסד נתונים רלציוני עם יכולת התאמה רחבה ביותר ועקביות גלובלית.

שיקולים לגבי העיצוב

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

Google Cloud

עיצוב המערכת

בקטע הזה מוסבר איך לבחור Google Cloud אזורים לפריסה גלובלית ואיך לבחור Google Cloud שירותים מתאימים. Google Cloud

בחירת אזור

כשבוחרים את Google Cloud האזורים שבהם צריך לפרוס את האפליקציות, חשוב לקחת בחשבון את הגורמים והדרישות הבאים:

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

תשתית מחשוב

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

  • קונטיינרים: אתם יכולים להריץ אפליקציות בקונטיינרים באשכולות של Google Kubernetes Engine‏ (GKE). ‫GKE הוא מנוע לתזמור קונטיינרים שמבצע אוטומטית פריסה, התאמה לעומס וניהול של אפליקציות בקונטיינרים.
  • Serverless: אם אתם מעדיפים להתמקד בנתונים ובאפליקציות שלכם במקום בהגדרה ובהפעלה של משאבי תשתית, אתם יכולים להשתמש בשירותים serverless כמו Cloud Run.

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

שירותי אחסון

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

‫Google Cloud Hyperdisk מספק ביצועים טובים יותר, גמישות ויעילות בהשוואה ל-Persistent Disk. עם Hyperdisk Balanced, אתם יכולים להקצות IOPS וקצב העברת נתונים בנפרד ובאופן דינמי, וכך להתאים את נפח האחסון למגוון רחב של עומסי עבודה.

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

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

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

אם מסד הנתונים שלכם הוא Microsoft SQL Server, מומלץ להשתמש ב-Cloud SQL ל-SQL Server. בתרחישים שבהם Cloud SQL לא תומך בדרישות ההגדרה שלכם, או אם אתם צריכים גישה למערכת ההפעלה, אתם יכולים לפרוס מכונה של אשכול יתירות כשל (FCI) של Microsoft SQL Server. בתרחיש הזה, אפשר להשתמש ב-Google Cloud NetApp Volumes, שירות מנוהל לחלוטין, כדי לספק אחסון SMB עם זמינות רציפה (CA) למסד הנתונים.

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

שירותי מסדי נתונים

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

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

עיצוב רשת

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

אפשרויות לאיזון עומסים חיצוני

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

אם האפליקציה שלכם דורשת שפרוטוקול Transport Layer Security ‏ (TLS) יופסק באזור ספציפי, או אם אתם צריכים את האפשרות להציג תוכן מאזורים ספציפיים, אתם יכולים להשתמש במאזני עומסים אזוריים עם Cloud DNS כדי לנתב תנועה לאזורים שונים. למידע על ההבדלים בין מאזני עומסים אזוריים לבין מאזני עומסים גלובליים, אפשר לעיין במסמכים הבאים:

אבטחה, פרטיות ותאימות

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

הגנה מפני איומים חיצוניים

כדי להגן על האפליקציה מפני איומים כמו התקפות מניעת שירות מבוזרות (DDoS) ופרצת אבטחה XSS‏ (cross-site scripting), אפשר להשתמש במדיניות אבטחה של Google Cloud Armor. כל מדיניות היא קבוצה של כללים שמציינים תנאים מסוימים שצריך להעריך ופעולות שצריך לבצע כשהתנאים מתקיימים. לדוגמה, כלל יכול לציין שאם כתובת ה-IP של המקור של תעבורת הנתונים הנכנסת תואמת לכתובת IP ספציפית או לטווח CIDR, צריך לדחות את תעבורת הנתונים. אפשר גם להחיל כללים מוגדרים מראש של חומת אש ליישומי אינטרנט (WAF). מידע נוסף זמין במאמר בנושא סקירה כללית של מדיניות אבטחה.

גישה חיצונית למכונות וירטואליות

בארכיטקטורת ההפניה שמתוארת במסמך הזה, המכונות הווירטואליות ב-Compute Engine לא צריכות גישה נכנסת מהאינטרנט. לא מקצים כתובות IP חיצוניות למכונות הווירטואליות. Google Cloud משאבים שיש להם רק כתובת IP פנימית פרטית עדיין יכולים לגשת לשירותים ולממשקי Google API מסוימים באמצעות Private Service Connect או גישה פרטית ל-Google. מידע נוסף זמין במאמר אפשרויות גישה פרטיות לשירותים.

כדי לאפשר חיבורים יוצאים מאובטחים מ Google Cloud משאבים שיש להם רק כתובות IP פרטיות, כמו מכונות וירטואליות של Compute Engine בארכיטקטורת ההפניה הזו, אפשר להשתמש ב-Secure Web Proxy או ב-Cloud NAT.

הרשאות בחשבון שירות

עבור ה-VMs של Compute Engine בארכיטקטורה, במקום להשתמש בחשבונות השירות שמוגדרים כברירת מחדל, מומלץ ליצור חשבונות שירות ייעודיים ולציין את המשאבים שחשבון השירות יכול לגשת אליהם. לחשבון השירות שמוגדר כברירת מחדל יש מגוון רחב של הרשאות, כולל כאלה שאולי לא נחוצות. אתם יכולים להתאים את חשבונות השירות הייעודיים כך שיהיו להם רק ההרשאות החיוניות. למידע נוסף, ראו הגבלת ההרשאות של חשבון שירות.

אבטחת SSH

כדי לשפר את האבטחה של חיבורי SSH למכונות וירטואליות ב-Compute Engine בארכיטקטורה שלכם, כדאי להטמיע את Identity-Aware Proxy‏ (IAP) ואת Cloud OS Login API. ‫IAP מאפשר לכם לשלוט בגישה לרשת על סמך זהות המשתמשים ומדיניות ניהול הזהויות והרשאות הגישה (IAM). ‫Cloud OS Login API מאפשר לכם לשלוט בגישת SSH ל-Linux על סמך זהות המשתמש ומדיניות IAM. מידע נוסף על ניהול גישה לרשת זמין במאמר שיטות מומלצות לשליטה בגישה להתחברות באמצעות SSH.

שיקולי אבטחה נוספים

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

אמינות

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

התאמה אוטומטית לעומס (autoscaling) של MIG

כשמריצים את האפליקציה בכמה קבוצות אזוריות של MIG, האפליקציה נשארת זמינה במהלך הפסקות חשמל באזורים מבודדים או באזורים. היכולת של קבוצות MIG בלי שמירת מצב (stateless) להתאמה אוטומטית לעומס מאפשרת לכם לשמור על זמינות וביצועים של האפליקציה ברמות צפויות.

כדי לשלוט בהתנהגות של התאמה אוטומטית לעומס בקבוצות MIG בלי שמירת מצב, אפשר לציין מדדי ניצול משאבים של יעד, כמו ניצול ממוצע של מעבד (CPU). אפשר גם להגדיר התאמה אוטומטית לעומס שמבוססת על תזמון לקבוצות MIG בלי שמירת מצב. אי אפשר להגדיר התאמה אוטומטית לעומס בקבוצות MIG עם שמירת מצב. למידע נוסף, אפשר לעיין במאמר בנושא התאמה אוטומטית לעומס של קבוצות מופעים.

מגבלת הגודל של MIG

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

תיקון אוטומטי של מכונות וירטואליות

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

מיקום ה-VM

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

כדי לשפר את החוסן של הארכיטקטורה, אפשר ליצור מדיניות מיקום מפוזר ולהחיל אותה על תבנית ה-MIG. כשקבוצת ה-MIG יוצרת מכונות וירטואליות, היא ממקמת אותן בכל אזור בשרתים פיזיים שונים (שנקראים מארחים), כך שהמכונות הווירטואליות עמידות בפני כשלים של מארחים ספציפיים. מידע נוסף זמין במאמר בנושא יצירה והחלה של מדיניות בנושא מיקום מודעות במכונות וירטואליות.

תכנון הקיבולת של מכונות וירטואליות

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

אחסון שומר מצב (Stateful)

שיטה מומלצת בתכנון אפליקציות היא להימנע מהצורך בדיסקים מקומיים עם שמירת מצב. אבל אם הדרישה קיימת, אתם יכולים להגדיר את הדיסקים המתמידים כך שיהיו בעלי מצב כדי להבטיח שהנתונים יישמרו כשמכונות ה-VM יתוקנו או ייצרו מחדש. עם זאת, מומלץ להשאיר את דיסקי האתחול בלי שמירת מצב, כדי שתוכלו לעדכן אותם לתמונות העדכניות ביותר עם גרסאות חדשות ותיקוני אבטחה. מידע נוסף זמין במאמר בנושא הגדרת דיסקים קשיחים מתמידים עם שמירת מצב בקבוצות של מכונות וירטואליות לניהול מופעים (MIG).

עמידות הנתונים

אתם יכולים להשתמש ב-Backup and DR כדי ליצור גיבויים של מכונות וירטואליות ב-Compute Engine, לאחסן אותם ולנהל אותם. שירות Backup and DR מאחסן נתוני גיבוי בפורמט המקורי שניתן לקריאה על ידי האפליקציה. כשנדרש, אתם יכולים לשחזר את עומסי העבודה שלכם לסביבת הייצור באמצעות נתונים מאחסון גיבוי לטווח ארוך, בלי שתצטרכו להכין או להעביר נתונים.

‫Compute Engine מספק את האפשרויות הבאות כדי לעזור לכם לוודא שהנתונים שמאוחסנים בכרכים של Persistent Disk יהיו עמידים:

  • אתם יכולים להשתמש בתמונות מצב כדי לתעד את המצב של נפחי אחסון של דיסקים קשיחים בנקודת זמן מסוימת. תמונות המצב מאוחסנות באופן יתיר באזורים רבים, עם סכומי ביקורת אוטומטיים כדי להבטיח את שלמות הנתונים. כברירת מחדל, תמונות המצב הן מצטברות, כך שהן תופסות פחות נפח אחסון ואתם חוסכים כסף. תמונות המצב מאוחסנות במיקום ב-Cloud Storage שאתם יכולים להגדיר. לקבלת המלצות נוספות לגבי שימוש בתמונות מצב וניהול שלהן, אפשר לעיין במאמר שיטות מומלצות לשימוש בתמונות מצב של דיסקים ב-Compute Engine.
  • כדי לוודא שהנתונים ב-Persistent Disk יישארו זמינים אם תתרחש הפסקה זמנית בשירות באזור, אפשר להשתמש ב-Regional Persistent Disk או ב-Hyperdisk Balanced High Availability. הנתונים בסוגי הדיסקים האלה משוכפלים באופן סינכרוני בין שני אזורים באותו אזור. מידע נוסף זמין במאמר מידע על שכפול סינכרוני של דיסקים.

אמינות מסד הנתונים

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

  • ארבעה עותקים לקריאה ולכתיבה באזורים נפרדים בשני אזורים.
  • רפליקת עֵד באזור שלישי.

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

‫Spanner משתמש באחסון מפורק שבו משאבי החישוב והאחסון מופרדים. כשמוסיפים יכולת חישוב לזמינות גבוהה או להרחבה, לא צריך להעביר נתונים. משאבי המחשוב החדשים מקבלים נתונים כשצריך מצומת Colossus הקרוב ביותר. כך אפשר לבצע מעבר לגיבוי (failover) והרחבה מהר יותר ובסיכון נמוך יותר.

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

שיקולים נוספים בנושא מהימנות

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

הוזלת עלויות

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

סוגי מכונות וירטואליות

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

מודל הקצאת הרשאות ל-VM

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

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

ניצול משאבים של מכונות וירטואליות

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

עלות מסד הנתונים

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

רישוי צד שלישי

כשמעבירים עומסי עבודה של צד שלישי אל Google Cloud, אפשר להקטין את העלויות באמצעות שימוש ברישיונות קיימים (BYOL). לדוגמה, כדי לפרוס מכונות וירטואליות של Microsoft Windows Server, במקום להשתמש בתמונה בתשלום שכוללת עלות נוספת עבור הרישיון של צד שלישי, אפשר ליצור ולהשתמש בתמונה מותאמת אישית של Windows BYOL. לאחר מכן משלמים רק על תשתית המכונות הווירטואליות שבהן משתמשים ב- Google Cloud. האסטרטגיה הזו עוזרת לכם להמשיך ליהנות מהערך של ההשקעות הקיימות ברישיונות של צד שלישי. אם מחליטים להשתמש בגישת BYOL, ההמלצות הבאות יכולות לעזור להקטין את העלויות:

  • כדי להקצות את מספר ליבות המעבד הנדרש באופן עצמאי מהזיכרון, אפשר להשתמש בסוגי מכונות בהתאמה אישית. כך אפשר להגביל את עלות הרישוי של הצד השלישי למספר ליבות המעבד שנדרשות.
  • כדי להקטין את מספר המעבדים הווירטואליים לכל ליבה מ-2 ל-1, משביתים את הריבוי משימות סימולטני (SMT).

אם פורסים מסד נתונים של צד שלישי כמו Microsoft SQL Server במכונות וירטואליות של Compute Engine, צריך לקחת בחשבון את עלויות הרישיון של תוכנת הצד השלישי. כשמשתמשים בשירות מסד נתונים מנוהל כמו Cloud SQL, עלויות הרישיון של מסד הנתונים כלולות בחיובים על השירות.

שיקולי עלות נוספים

כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי גם לעיין בשיטות המומלצות ובהמלצות הכלליות שמופיעות במאמר Google Cloud Well-Architected Framework: הוזלת העלויות.

יעילות תפעולית

בקטע הזה מתוארים הגורמים שכדאי לקחת בחשבון כשמשתמשים בארכיטקטורת ההפניה הזו כדי לתכנן ולבנות טופולוגיה גלובלית Google Cloud שאפשר להפעיל ביעילות.

עדכונים בהגדרות של מכונות וירטואליות

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

תמונות VM

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

תבניות מכונה דטרמיניסטיות

אם תבניות של הגדרות מכונה שבהן אתם משתמשים ב-MIG כוללות סקריפטים לטעינה בזמן ההפעלה כדי להתקין תוכנות של צד שלישי, חשוב לוודא שהסקריפטים מציינים באופן מפורש פרמטרים של התקנת תוכנה, כמו גרסת התוכנה. אחרת, כשקבוצת ה-MIG יוצרת את מכונות ה-VM, יכול להיות שהתוכנה שמותקנת במכונות ה-VM לא תהיה עקבית. לדוגמה, אם תבנית של הגדרות מכונה כוללת סקריפט לטעינה בזמן ההפעלה כדי להתקין את Apache HTTP Server 2.0 (החבילה apache2), צריך לוודא שהסקריפט מציין את הגרסה המדויקת של apache2 שצריך להתקין, כמו גרסה 2.4.53. מידע נוסף זמין במאמר בנושא תבניות מופעים דטרמיניסטיות.

העברה ל-Spanner

אפשר להעביר נתונים ל-Spanner ממסדי נתונים אחרים כמו MySQL,‏ SQL Server ו-Oracle Database. תהליך ההעברה תלוי בגורמים כמו מסד הנתונים של המקור, גודל הנתונים, מגבלות לגבי זמן ההשבתה ומורכבות קוד האפליקציה. כדי לעזור לכם לתכנן ולבצע את המיגרציה ל-Spanner בצורה יעילה, אנחנו מספקים מגוון של Google Cloud וכלים של צד שלישי. מידע נוסף זמין במאמר בנושא סקירה כללית על העברת נתונים.

ניהול מסדי נתונים

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

שיקולים תפעוליים נוספים

כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי לקחת בחשבון את השיטות המומלצות הכלליות ואת ההמלצות ליעילות תפעולית שמתוארות במאמר Google Cloud Well-Architected Framework: Operational excellence.

אופטימיזציה של הביצועים

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

ביצועי הרשת

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

ב-Compute Engine יש מגבלה לכל מכונה וירטואלית על רוחב פס של רשת ליציאה. המגבלה הזו תלויה בסוג המכונה הווירטואלית ובשאלה אם תעבורת הנתונים מנותבת דרך אותה רשת VPC כמו המכונה הווירטואלית של המקור. במכונות וירטואליות עם סוגים מסוימים של מכונות, כדי לשפר את ביצועי הרשת, אפשר להגדיל את רוחב הפס המקסימלי ליציאה על ידי הפעלת רשת Tier_1.

ביצועי מחשוב

‫Compute Engine מציע מגוון רחב של סוגי מכונות מוגדרים מראש וניתנים להתאמה אישית לעומסי העבודה שמופעלים במכונות וירטואליות. כדאי לבחור סוג מכונה מתאים בהתאם לדרישות הביצועים שלכם. למידע נוסף, אפשר לעיין במאמר משפחות של מכונות – משאבים ומדריך השוואה.

ריבוי שרשורים ב-VM

כל מעבד וירטואלי (vCPU) שמוקצה למכונה וירטואלית ב-Compute Engine מיושם כריבוי נימים (multithreading) של חומרה יחידה. כברירת מחדל, שני מעבדים וירטואליים חולקים ליבה פיזית של מעבד. ביישומים שכוללים פעולות מקבילות מאוד או שמבצעים חישובים של נקודה צפה (כמו ניתוח רצפים גנטיים ומודלים של סיכונים פיננסיים), אפשר לשפר את הביצועים על ידי הקטנת מספר השרשורים שפועלים בכל ליבת CPU פיזית. מידע נוסף זמין במאמר בנושא הגדרת מספר השרשורים לכל ליבה.

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

Network Service Tiers

מסלולי שירות הרשת מאפשרים לכם לבצע אופטימיזציה של עלות הרשת והביצועים של עומסי העבודה. אפשר לבחור במסלול פרימיום או במסלול רגיל. במסלול פרימיום, תעבורת הנתונים עוברת דרך רשת הליבה הגלובלית של Google כדי להשיג איבוד מינימלי של מנות וזמן אחזור נמוך. במסלול הרגיל, תעבורת הנתונים מועברת באמצעות קישור בין רשתות שכנות (peering), ספקי אינטרנט (ISP) או רשתות העברה בנקודת קצה PoP שהכי קרובה לאזור שבו פועלת עומס העבודה שלכם Google Cloud . כדי לשפר את הביצועים, מומלץ להשתמש במסלול פרימיום. כדי לבצע אופטימיזציה של העלות, מומלץ להשתמש במסלול הרגיל.

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

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

ביצועים ב-Spanner

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

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

המלצות לאופטימיזציה של הביצועים של מופע ומסדי נתונים של Spanner מופיעות במסמכים הבאים:

שמירה במטמון

אם האפליקציה שלכם מציגה נכסים סטטיים של אתרים, והארכיטקטורה שלכם כוללת מאזן עומסים חיצוני גלובלי של אפליקציות (ALB), אתם יכולים להשתמש ב-Cloud CDN כדי לשמור במטמון תוכן סטטי שמתבצעת אליו גישה באופן קבוע, בקרבת המשתמשים. Cloud CDN יכול לעזור לכם לשפר את הביצועים של המשתמשים, לצמצם את השימוש במשאבי התשתית בבק-אנד ולהפחית את העלויות של העברת נתונים ברשת. מידע נוסף זמין במאמר שיפור הביצועים של אתרים והגנה על אתרים באמצעות איזון עומסים.

שיקולי ביצועים נוספים

כשיוצרים את הארכיטקטורה של עומס העבודה, כדאי לפעול לפי השיטות המומלצות וההמלצות הכלליות שמופיעות במאמר Google Cloud Well-Architected Framework: Performance optimization.

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

שותפים ביצירת התוכן

מחברים:

תורמי תוכן אחרים: