שיטות מומלצות לטיפול בשגיאות ולצמצום זמן האחזור של הבקשות

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

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

הטמעה של לוגיקה לניסיון חוזר ופסק זמן

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

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

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

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

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

טיפול בשגיאות בכמה שכבות

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

למשל, נבחן את התרחיש הבא:

1. תוכנת הביניים מקבלת שגיאה 500 Internal Server Error מ-Cloud Healthcare API כשנשלחת בקשה.
2. שכבת התוכנה העצמאית מנסה לשלוח את הבקשה עוד חמש פעמים, עד שהיא מגיעה למגבלה שלה, ואז היא מפסיקה לנסות.
3. הלקוח מקבל שגיאה סופית 500 Internal Server Error.

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

בתרשים הבא מוצג תרחיש שבו שרת proxy של תוכנת ביניים מקבל שגיאות 500 Internal Server Error כשמעביר בקשה מלקוח אל Cloud Healthcare API. הלקוח והפרוקסי מיישמים טיפול בשגיאות וניסיונות חוזרים.

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

באיור 1 מוצגים השלבים הבאים:

1. הלקוח שולח בקשה תקינה ל-Cloud Healthcare API דרך שרת proxy של תוכנת ביניים.
2. הפרוקסי מעביר את הבקשה אל Cloud Healthcare API.
3. ‫Cloud Healthcare API מחזיר שגיאה 500 Internal Server Error לשרת ה-proxy. הפרוקסי ינסה לשלוח את הבקשה עוד חמש פעמים עד שיגיע למגבלת הניסיונות החוזרים.

4. ה-Proxy מחזיר ללקוח את מצב השגיאה הסופי, 500 Internal Server Error.

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

   Error with underlying FHIR store in Cloud Healthcare API after 5 retries: 500 Internal Server Error

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

לפעמים, הלקוח או ה-proxy מקבלים שגיאות 500 Internal Server Error אחרי שהם חורגים ממגבלות הניסיון החוזר, ולכן הם לא יכולים לנסות שוב. במקרה כזה, יכול להיות שיהיה צורך בהתערבות אנושית כדי לאבחן אם השגיאה הגיעה משרת ה-proxy או מ-Cloud Healthcare API.

בחירת השגיאות לניסיון חוזר

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

• 408 Request Timeout
• 425 Too Early
• 429 Too Many Requests
• 500 Internal Server Error
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Gateway Timeout

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

השפעות של ארכיטקטורת המערכת

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

לדוגמה, בארכיטקטורה של לקוח לשרת ישירות, לקוח שמקבל שגיאה 401 UNAUTHENTICATED מ-Cloud Healthcare API יכול לבצע אימות מחדש ולנסות שוב לשלוח את הבקשה.

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

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

תכנון מצבי שגיאה סופיים

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

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

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

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

תכנון לעלייה בזמן האחזור

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

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

תכנון באמצעות חביון אחוזוני

כדי לתכנן את הגידול בזמן האחזור, אפשר לנתח את אחוזון זמן האחזור של הבקשות. בדוגמאות הבאות מתוארים זמן האחזור באחוזון ה-50 וזמן האחזור באחוזון ה-99:

• החביון באחוזון ה-50 הוא החביון המקסימלי, בשניות, עבור 50% הבקשות המהירות ביותר. לדוגמה, אם זמן האחזור של האחוזון ה-50 הוא 0.5 שניות, אז Cloud Healthcare API עיבד 50% מהבקשות תוך 0.5 שניות. זמן האחזור באחוזון ה-50 נקרא גם 'זמן האחזור החציוני'.
• זמן האחזור באחוזון ה-99 הוא זמן האחזור המקסימלי בשניות, עבור 99% מהבקשות הכי מהירות. לדוגמה, אם חביון האחוזון ה-99 הוא שתי שניות, אז Cloud Healthcare API עיבד 99% מהבקשות תוך שתי שניות.

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

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

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