מדריך

מיקרו-שירותים דורשים תקשורת סינכרונית של בקשה/תגובה ותקשורת אסינכרונית מונחית אירועים.

→השתמש ב-gRPC או HTTP עבור קריאות סינכרוניות. השתמש ב-Pub/Sub עבור טיפול באירועים אסינכרוניים ו-fan-out.

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

מקור↗

שירות חישוב חסר מצב (Cloud Run, Cloud Functions) צריך לעבד קבצים זמניים.

→השתמש ב-Cloud Storage עבור כל פעולות הקלט/פלט של קבצים זמניים.

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

נהל תצורות וסודות ספציפיים לסביבה עבור עומסי עבודה של GKE בהתאם לעקרונות 12-factor.

→השתמש ב-K8s ConfigMaps עבור תצורה לא רגישה. השתמש ב-Secret Manager עבור ערכים רגישים, הנגישים באופן מאובטח באמצעות Workload Identity.

למה: Secret Manager הוא פתרון מאובטח יותר, מנוהל וניתן לביקורת מאשר K8s Secrets. Workload Identity מונע ניהול והפצת מפתחות חשבון שירות.

מקור↗

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

→השתמש ב-Cloud Run עם `min-instances` מוגדר ל-0.

למה: Cloud Run יכול להתרחב לאפס, מה שמבטל את כל עלויות החישוב בתקופות סרק. GKE ו-Compute Engine דורשים מינימום nodes/instances פועלים.

יישם ניסיונות חוזרים, מפסקי זרם (circuit breakers) ו-mTLS באופן עקבי על פני מיקרו-שירותים ללא שינויים בקוד היישום.

→פרוס service mesh (Anthos Service Mesh) על GKE.

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

חשוף שירותי backend לשותפים חיצוניים או אפליקציות מובייל עם הגבלת קצב, מפתחות API וניתוח שימוש.

→השתמש ב-API Gateway לפני שירותי ה-backend (לדוגמה, Cloud Run, GKE).

למה: API Gateway מספק פתרון מנוהל במלואו לדאגות מחזור חיי ה-API (אבטחה, ניטור, ניהול גרסאות), ומפנה אותן משירות ה-backend.

מקור↗

בחר אחסון עמיד, ניתן להרחבה ועקבי חזק עבור יומן אירועים מסוג "הוסף בלבד" (append-only).

→השתמש ב-Cloud Spanner עבור אחסון האירועים.

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

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

→נקודת קצה של API מכניסה משימה לתור ב-Pub/Sub או Cloud Tasks ומחזירה 202 Accepted עם ID של משימה. worker נפרד (Cloud Run, Cloud Function) מעבד את המשימה.

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

שמור על עקביות נתונים על פני מספר מיקרו-שירותים ללא מסד נתונים משותף.

→יישם את תבנית Saga באמצעות orchestrator (Cloud Workflows) או choreography (אירועי Pub/Sub) עם compensating transactions.

למה: נמנע מ-two-phase commits מורכבים ומועדים לנעילות, ומעדיף עקביות בסופו של דבר (eventual consistency) שמתאימה יותר למערכות מבוזרות.

היישום קורא ל-API צד שלישי המוגבל בקצב, שבו הנתונים משתנים לעיתים רחוקות.

→השתמש ב-Memorystore for Redis כ-cache מבוזר. הטמע את תבנית cache-aside עם TTL. השתמש במנעול מבוזר (לדוגמה, Redis SETNX) כדי למנוע cache stampedes.

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

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

→השתמש ב-Cloud Workstations.

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

מקור↗

יישום SaaS דורש שלדיירים יהיו נתונים, מפתחות הצפנה ומגבלות מיקום נתונים מבודדים לחלוטין.

→השתמש במודל של project-per-tenant. נהל הקצאה ותצורה באופן מרכזי באמצעות IaC (Terraform).

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

אכוף שרק תמונות container מהימנות, סרוקות מצינור רשמי, יכולות להיפרס לייצור.

→השתמש ב-Cloud Build כדי לייצר SLSA provenance, ב-Artifact Registry לסריקת פגיעויות, וב-Binary Authorization כדי לאכוף מדיניות פריסה המבוססת על attestations.

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

מקור↗

פרוס גרסה חדשה של שירות Cloud Run, בדוק אותה ללא השפעה על המשתמשים, והחלף תעבורה באופן מיידי.

→פרוס את הגרסה החדשה עם `--no-traffic`. בדוק באמצעות URL הגרסה הייחודי או תג גרסה. העבר 100% מהתעבורה לגרסה החדשה לאחר האימות.

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

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

→השתמש ב-Cloud Deploy עם אסטרטגיית פריסת canary. שלב עם Cloud Monitoring עבור ניתוח מדדים אוטומטי וטריגרים ל-rollback.

למה: Cloud Deploy ממכן את כל תהליך ה-progressive delivery, כולל ניתוח מדדים ובדיקות בטיחות, מפחית מאמץ ידני וסיכון.

נהל Kubernetes manifests עבור סביבות פיתוח, staging ו-prod ללא שכפול קוד.

→השתמש ב-Kustomize או Helm. הגדר תצורת בסיס וצור קבצי overlays או values ספציפיים לסביבה כדי להחיל הבדלים.

למה: עוקב אחר עקרון DRY, הופך את התצורות לקלות יותר לניהול ומפחית את הסיכון לסטייה בין סביבות.

הקטן את גודל תמונת ה-container עבור פריסות מהירות יותר ושטח תקיפה קטן יותר.

→השתמש ב-multi-stage builds. שלב `build` משתמש בתמונת SDK/JDK מלאה; השלב הסופי מעתיק רק את הארטיפקט המקומפל לתמונת בסיס `distroless` מינימלית.

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

פרוס באופן אוטומטי סביבות ארעיות עבור כל pull request לצורך אימות לפני מיזוג.

→השתמש ב-Cloud Build triggers על אירועי PR כדי לפרוס ל-Cloud Run עם revision tag (לדוגמה, `pr-123`). השתמש ב-trigger נוסף בסגירת PR כדי לנקות את ה-revision המתויג.

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

שפר את מהירות ואמינות בניית CI/CD על ידי שמירת תלויות תוכנה ציבוריות ב-cache (לדוגמה, מ-npm, Maven Central).

→השתמש ב-Artifact Registry remote repository, המשמש כ-pull-through cache עבור ה-repository הציבורי.

למה: משפר את ביצועי הבנייה, מגן על הבנייות מפני הפסקות של registries ציבוריים, ומאפשר סריקת פגיעויות על ארטיפקטים שנשמרו ב-cache.

אחסן ונעול באופן מאובטח את מצב Terraform עבור ביצועי CI/CD pipeline במקביל.

→השתמש ב-Cloud Storage backend עבור מצב Terraform, עם IAM מתאים עבור חשבון השירות של Cloud Build.

למה: Cloud Storage מספק backend עמיד, בעל גרסאות וניתן לנעילה, מונע שחיתות מצב מבנייות מקבילות.

שירות Cloud Run או Cloud Function צריך לגשת למשאב (לדוגמה, Cloud SQL, Memorystore) ברשת VPC פרטית.

→הגדר Serverless VPC Access connector.

למה: ה-connector משמש כגשר רשת, מאפשר תעבורת יציאה מסביבת ה-serverless ל-VPC היעד מבלי לחשוף משאבים לציבור.

מקור↗

יישום stateful ב-GKE דורש זהות יציבה ואחסון מתמשך ששורד כשל ב-pod/node.

→השתמש ב-StatefulSet עם Headless Service עבור זהות. השתמש ב-PersistentVolumeClaim (PVC) עם Persistent Disk אזורי עבור אחסון.

למה: זוהי תבנית Kubernetes הקנונית עבור עומסי עבודה stateful, המבטיחה עמידות נתונים, זמינות גבוהה, ושמות/רשתות צפויים ל-pods.

pod ב-GKE צריך לגשת ל-APIs של GCP באופן מאובטח מבלי לנהל מפתחות חשבון שירות סטטיים.

→הגדר והשתמש ב-Workload Identity.

למה: Workload Identity קושר חשבון שירות של Kubernetes לחשבון שירות של Google, מאפשר ל-pods להשתמש באישורי GCP קצרי מועד המתקבלים משרת המטא-נתונים.

הרץ batch job שאורך שעות להשלמה (לדוגמה, עיבוד קובץ גדול, אגרגציית נתונים לילית).

→השתמש ב-Cloud Run jobs, המופעלים על ידי Eventarc או Cloud Scheduler.

למה: Cloud Run jobs מיועדים למשימות ארוכות טווח (עד 24 שעות), מתרחבים לאפס, והם חסכוניים ופשוטים יותר מאשכול GKE ייעודי או VM עבור עומסי עבודה של batch.

פרוס יישום מרובה container-ים ב-Cloud Run שבו container ראשי זקוק ל-sidecar עבור רישום (logging), מדדים, או כ-proxy.

→פרוס את שירות Cloud Run עם מספר תמונות container שצוינו, אחת כ-container ראשי ואחרות כ-sidecars.

למה: תמיכת ה-multi-container המובנית של Cloud Run מאפשרת את תבנית ה-sidecar עבור עומסי עבודה serverless ללא המורכבות של GKE.

העברות מסד נתונים חייבות להסתיים לפני ש-Cloud Run revision חדש מקבל תעבורה.

→הרץ העברות במהלך הפעלת ה-container, והשתמש ב-Cloud Run startup probe שעובר רק לאחר שההעברות הושלמו בהצלחה.

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

יישום GKE צריך להתרחב בהתבסס על מדד מותאם אישית כמו עומק תור מ-Pub/Sub, לא רק CPU/זיכרון.

→השתמש ב-Horizontal Pod Autoscaler (HPA) המוגדר לקרוא מדדים מותאמים אישית מ-Cloud Monitoring.

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

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

→שלב Pub/Sub (עם at-least-once או exactly-once delivery) עם consumer אידמפוטנטי. ה-consumer עוקב אחר IDs של הודעות מעובדות באחסון מתמשך (לדוגמה, Firestore, Memorystore).

למה: Pub/Sub מבטיח אספקה, אך ה-consumer אחראי על אידמפוטנטיות כדי לטפל בניסיונות חוזרים ברמת היישום ולהשיג עיבוד בדיוק פעם אחת אמיתי.

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

→פרסם הודעות ל-Pub/Sub עם `orderingKey`. הפעל סידור הודעות על ה-subscription.

למה: Pub/Sub מבטיח שהודעות עם אותו ordering key נמסרות לפי הסדר, בעוד שהודעות עם מפתחות שונים יכולות להיות מעובדות במקביל עבור סקלאביליות.

מקור↗

ודא שמשימה (לדוגמה, הפקת דוח משתמש יומי) רצה רק פעם אחת, גם אם מגיעים מספר אירועי הפעלה.

→השתמש ב-Cloud Tasks. צור משימות עם שמות מפורשים (לדוגמה, `report-userX-2024-10-26`). Cloud Tasks יבצע deduplication לבקשות ליצירת משימה עם שם קיים.

למה: זה מוריד את לוגיקת ה-deduplication לשירות התורים, מפשט את קוד היישום ומונע עבודה מיותרת.

הודעת Pub/Sub נכשלת בעקביות בעיבוד לאחר ניסיונות חוזרים מרובים וחוסמת את התור.

→הגדר dead-letter topic (DLQ) ב-Pub/Sub subscription וקבע מספר מרבי של ניסיונות אספקה.

למה: Pub/Sub מעביר אוטומטית את הודעת ה"רעל" ל-DLQ, מאפשר עיבוד של הודעות אחרות ושומר את ההודעה הכושלת לניתוח.

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

→השתמש ב-Cloud Workflows כדי להגדיר ולבצע את לוגיקת ה-orchestration.

למה: Cloud Workflows הוא orchestrator serverless המנהל מצב, ניסיונות חוזרים והמתנות ארוכות, ומספק אמינות ונראות טובים יותר מפונקציות משורשרות ידנית.

מקור↗

שירות Cloud Function או Cloud Run צריך להיות מופעל רק על ידי אירועי ענן ספציפיים (לדוגמה, סוגי קבצים מסוימים ב-Cloud Storage).

→השתמש ב-Eventarc trigger עם סינון CEL (Common Expression Language) על תכונות האירוע.

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

הגבל קצב של קריאות יוצאות ל-API צד שלישי משירות מורחב אופקית כמו Cloud Run.

→הכנס קריאות API לתור כמשימות בתור Cloud Tasks עם `rateLimits` מוגדרים (לדוגמה, מספר שליחות מקסימלי לשנייה).

למה: Cloud Tasks מספק הגבלת קצב מרכזית ו-serverless שעובדת על פני כל המופעים המורחבים ללא צורך במוני מבוזרים מורכבים.

אמת באופן מאובטח קריאות בין שני שירותי Cloud Run (או Cloud Functions).

→הענק לחשבון השירות של השירות הקורא את תפקיד `roles/run.invoker` IAM על השירות הנקרא. הקורא שולח Google-signed ID token עם בקשתו.

למה: זוהי שיטת האימות המובנית, המאובטחת ונטולת המפתחות עבור תקשורת שירות לשירות, הממנפת את תשתית הזהויות של Google.

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

→השתמש ב-Datastream (CDC) כדי להזרים שינויים במסד הנתונים ל-Pub/Sub. השתמש ב-Eventarc כדי להפעיל שירות Cloud Run מנושא ה-Pub/Sub.

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

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

→השתמש ב-Cloud Workflows עם callback endpoint. ה-workflow מושהה (למשך עד שנה) עד שיקבל בקשת HTTP ב-URL ה-callback הייחודי שלו.

למה: Callbacks מאפשרים ל-workflows להמתין לאירועים חיצוניים מבלי לצרוך משאבי חישוב, מה שהופך אותם לאידיאליים לתהליכים ארוכי טווח הכוללים מעורבות אנושית.

יישום serverless הרגיש לזמן אחזור חווה תגובות ראשוניות איטיות לאחר תקופות סרק.

→הגדר `min-instances` ל-1 או יותר. עבור cold starts בלתי נמנעים, השתמש ב-`startup-cpu-boost`. בצע גם אופטימיזציה ליישום (תמונה קטנה יותר, אתחול מהיר יותר).

למה: `min-instances` היא הדרך היעילה ביותר למנוע cold starts אך כרוכה בעלות. `startup-cpu-boost` מאיץ את תהליך האתחול עצמו.

מקור↗

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

→השתמש ב-Cloud Trace עם context propagation. בצע אינסטרומנטציה ליישומים כדי להעביר כותרות trace (לדוגמה, W3C Trace Context).

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

מקור↗

יישום רץ לאט בייצור, ולא ברור אם הבעיה היא CPU-bound, דליפת זיכרון, או I/O.

→השתמש ב-Cloud Profiler כדי לנתח באופן רציף שימוש ב-CPU וב-heap בייצור.

למה: Cloud Profiler מזהה צווארי בקבוק בביצועים ברמת הקוד (hot paths, דליפות זיכרון) עם תקורה נמוכה מאוד, ללא צורך לשחזר בעיות בסביבת בדיקה.

עבור מהתראות סף פשוטות (לדוגמה, "latency > 500ms") להתראות משמעותיות יותר המבוססות על Service Level Objectives (SLOs).

→הגדר SLIs ו-SLOs ב-Cloud Monitoring. צור מדיניות התראות המבוססת על "burn rate" של תקציב השגיאות.

למה: התראות burn rate רגישות יותר לשינויים משמעותיים ופחות רועשות מהתראות סף פשוטות, ומאותתות כאשר אתה נמצא במסלול להחמיץ את ה-SLO שלך.

אגד חריגות יישומים משירותים מרובים כדי לעקוב אחר תדירות, לראות stack traces, ולקבל התראות על סוגי שגיאות חדשים.

→השתמש ב-Cloud Error Reporting.

למה: Error Reporting קולט, מקבץ ומנתח אוטומטית חריגות מיומנים מובנים, ומספק לוח מחוונים מרכזי לניהול שגיאות יישומים.

נטר, הדמיין והתריע על מדדים עסקיים מותאמים אישית (לדוגמה, הזמנות לדקה, הרשמות משתמשים).

→בצע אינסטרומנטציה לקוד היישום באמצעות ה-OpenTelemetry SDK. הגדר את ה-exporter לשלוח מדדים ל-Cloud Monitoring.

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