שיטות מומלצות לניהול מכסות

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

מכסות ברירת המחדל של Cloud Healthcare API

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

שיטות מומלצות למעקב אחרי מכסת נפח האחסון ולצפייה בה

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

  • אם קיים ביטול מדיניות על ידי אדמין. חשבון משתמש שקיבל את התפקיד Quota Administrator (אדמין של מכסות) בארגון יכול להחיל ביטול של מכסה עלGoogle Cloud פרויקטים בארגון. שינוי מברירת המחדל שהגדיר האדמין מחליף את מגבלות ברירת המחדל ואת השינויים מברירת המחדל שהגדיר הבעלים של השירות המנוהל.

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

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

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

שיטות מומלצות לבקשה להגדלת המכסה

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

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

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

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

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

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

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

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

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

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

הבנת השימוש הכולל בכל מאגרי הנתונים של Cloud Healthcare API, והבנת השימוש הכולל של כל הלקוחות ששולחים בקשות לGoogle Cloud פרויקט.

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

צפי לשימוש בכל אזור

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

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

אם מערך הנתונים שלכם ב-Cloud Healthcare API נמצא במיקום us רב-אזורי, ואתם רוצים לבקש מכסה נוספת, ציינו בבקשת המכסה שהמכסה היא עבור "אזור המטא של ארה"ב". המיקום במספר אזורים us מורכב מאזורי המשנה הבאים:

  • us-central1
  • us-east1
  • us-west1

אם כבר יש לכם תנועה ב-Cloud Healthcare API שמשתמשת במכסה באחד מאזורי המשנה us-, חשוב לוודא שאתם לוקחים בחשבון את התנועה הקיימת באזורי המשנה האלה כשאתם שולחים בקשה להגדלת המכסה באזור המרובה us. לדוגמה, אם יש לכם מערכי נתונים ב-us-central1 וב-us, ואתם מבקשים להגדיל את נפח האחסון ב-us, ציינו בבקשה שיש לכם מערכי נתונים ב-us-central1.

העדפה של עסקאות עם נפח נמוך באופן עקבי

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

נפח התנועה מחושב באמצעות הנוסחה request payload * time = traffic volume. טרנזקציה בהיקף גדול היא בקשה אחת או יותר ל-Cloud Healthcare API במרווח קצר שמכילה מטען ייעודי (payload) גדול. סדרה של בקשות יכולה להיחשב גם כבקשות בהיקף גדול אם נשלחות הרבה בקשות במרווח קצר, ללא קשר לגודל המטען הייעודי (payload).

נניח שלקוח אוסף עסקאות בהיקף גדול ושולח את העסקאות ל-Cloud Healthcare API כל חמש דקות. הפעולות הבאות מתרחשות:

  1. התנועה הראשונית צורכת את המכסה בדקה הראשונה (תלוי במעברים של דקות) עד שהמכסה מוצה.
  2. כל תנועת גולשים שנותרה מקבלת שגיאות 429 RESOURCE_EXHAUSTED. אם ההגדרה מופעלת, כל הבקשות המושפעות נתקלות בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff).
  3. חלק מהבקשות שנתקלו בהשהיה מעריכית לפני ניסיון חוזר (exponential backoff) מתוזמנות מחדש לניסיון חוזר בדקה הבאה. חלק מהבקשות נשלחות כמה פעמים בדקה אחת, ואז נשלחות שוב בדקה הבאה.
  4. אם נפח הבקשות גבוה מספיק, יכול להיות שבקשות חוזרות ייתקלו בשגיאות 429 RESOURCE_EXHAUSTED ויחוו שוב השהיה מעריכית לפני ניסיון חוזר. יכול להיות שחלק מהפרצים של התנועה ייתקלו בנסיגה אקספוננציאלית בזמנים שונים, והניסיונות לשלוח שוב את התנועה יתכנסו לאותה דקה בעתיד.
  5. אם נפח הבקשות עדיין גבוה, המערכת תנסה שוב להעביר חלק מהתנועה כשהפרץ הבא של התנועה יתחיל. הבעיה מחמירה כי יותר תנועה מתווספת למצבור הקיים של בקשות. יכול להיות שלאפליקציה שלך יהיה קשה לשמור את רשימת הבקשות ולשלוח אותן באופן עקבי אל Cloud Healthcare API.

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

בדיקת המכסות של DICOM ו-FHIR

כדי לראות את המכסות של Cloud Healthcare API שמשויכות למאגרי FHIR ו-DICOM ולפעולות, אפשר לעיין במאמר מגבלות מכסה.