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

אתם צופים במסמכי התיעוד של Apigee ושל Apigee Hybrid.
לעיון במסמכי התיעוד של Apigee Edge.

ההגדרה של TargetEndpoint מגדירה את האופן שבו Apigee מתחבר לשירות לקצה העורפי או ל-API. הוא שולח את הבקשות ומקבל את התשובות משירות לקצה העורפי. שירות לקצה העורפי יכול להיות שרת HTTP/HTTPS או שרת NodeJS.

אפשר להפעיל את שירות ה-Backend ב-TargetEndpoint באחת מהדרכים הבאות:

  • כתובת URL ישירה לשרת HTTP או HTTPS
  • הגדרת TargetServer

באופן דומה, אפשר להשתמש במדיניות ServiceCallout כדי לבצע קריאה לכל שירות חיצוני מתוך זרימת ה-API Proxy. המדיניות הזו תומכת בהגדרת כתובות URL של יעד HTTP/HTTPS ישירות במדיניות עצמה או באמצעות הגדרת TargetServer.

הגדרת TargetServer

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

הנה דוגמה להגדרת TargetServer:

<TargetServer name="target1">
  <Host>www.mybackendservice.com</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>

ה-TargetServer מאפשר לכם להגדיר תצורות שונות לכל סביבה. אפשר להגדיר מדיניות TargetEndpoint/Service Callout עם שרת יעד אחד או יותר שנקראים באמצעות LoadBalancer. התמיכה המובנית באיזון עומסים משפרת את הזמינות של ממשקי ה-API ואת המעבר האוטומטי בין מופעים מוגדרים של שרתים בעורף המערכת.

הנה דוגמה להגדרת TargetEndpoint באמצעות TargetServers:

<TargetEndpoint name="default">
    <HTTPTargetConnection>>
      <LoadBalancer>
        <Server name="target1"/>
        <Server name="target2"/>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

MaxFailures

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

הגדרה לדוגמה עם MaxFailures:

<TargetEndpoint name="default">
    <HTTPTargetConnection>
      <LoadBalancer>
        <Server name="target1"/>
        <Server name="target2"/>
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

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

תבנית אנטי

לא מומלץ להגדיר TargetServer יחיד בהגדרת LoadBalancer של מדיניות TargetEndpoint או Service Callout עם MaxFailures שמוגדר לערך שאינו אפס, כי זה עלול להוביל לתוצאות לא רצויות.

לדוגמה, שימו לב להגדרה הבאה עם TargetServer יחיד בשם target1, שבו MaxFailures מוגדר ל-5 (ערך שאינו אפס): 

<TargetEndpoint name="default">
  <HTTPTargetConnection>
      <LoadBalancer>
        <Algorithm>RoundRobin</Algorithm>
        <Server name="target1" />
        <MaxFailures>5</MaxFailures>
      </LoadBalancer>
  </HTTPTargetConnection>

אם הבקשות ל-TargetServer ‏target1 נכשלות חמש פעמים (המספר שצוין ב-MaxFailures),‏ TargetServer מוסר מהרוטציה. מכיוון שאין TargetServers אחרים שאפשר לבצע אליהם מעבר לגיבוי, כל הבקשות הבאות ל-API Proxy עם ההגדרה הזו ייכשלו עם השגיאה 503 Service Unavailable.

גם אם שרת היעד target1 חוזר למצב הרגיל שלו ויכול לשלוח תגובות מוצלחות, הבקשות ל-API Proxy ימשיכו להחזיר שגיאות 503. הסיבה לכך היא ש-Apigee לא מחזיר אוטומטית את TargetServer לרוטציה גם אחרי שהיעד חוזר לפעולה. כדי לפתור את הבעיה, צריך לפרוס מחדש את ה-API Proxy כדי שמערכת Apigee תחזיר את TargetServer לרוטציה.

אם משתמשים באותה הגדרה במדיניות Service Callout, בקשות ה-API יקבלו שגיאת 500 אחרי שהבקשות ל-TargetServer ‏target1 ייכשלו 5 פעמים.

השפעה

שימוש ב-TargetServer יחיד בהגדרה LoadBalancer של מדיניות TargetEndpoint או Service Callout עם MaxFailures שמוגדר לערך שאינו אפס גורם ל:

  • בקשות API נכשלות עם שגיאות 503/500 באופן רציף (אחרי שהבקשות נכשלות מספר פעמים ששווה ל-MaxFailures) עד לפריסה מחדש של ה-API Proxy.
  • הפסקה זמנית בשירות תהיה ארוכה יותר כי קשה לאבחן את הסיבה לבעיה הזו (ללא ידע מוקדם על האנטי-תבנית הזו), והאבחון עשוי לקחת יותר זמן.

שיטה מומלצת

  1. כדי להשיג זמינות גבוהה יותר, כדאי להגדיר יותר מ-TargetServer אחד בהגדרות של LoadBalancer.

  2. תמיד צריך להגדיר את Health Monitor כשמגדירים את MaxFailures לערך שאינו אפס. שרת יעד יוסר מהרוטציה כשמספר הכשלים יגיע למספר שצוין ב-MaxFailures. הוספת HealthMonitor מבטיחה שה-TargetServer יוחזר לרוטציה ברגע ששרת היעד יהיה זמין שוב, כלומר אין צורך לפרוס מחדש את ה-proxy.

    כדי לוודא שבדיקת תקינות מתבצעת באותו מספר יציאה שבו Apigee משתמש כדי להתחבר לשרתי היעד, מומלץ להשמיט את רכיב הצאצא <Port> מתחת ל-<TCPMonitor>, אלא אם הוא שונה מהיציאה של TargetServer. כברירת מחדל, <Port> זהה ליציאה של TargetServer.

    דוגמה להגדרה עם HealthMonitor:

    <TargetEndpoint name="default">
  <HTTPTargetConnection>
    <LoadBalancer>
      <Algorithm>RoundRobin</Algorithm>
      <Server name="target1" />
      <Server name="target2" />
      <MaxFailures>5</MaxFailures>
    </LoadBalancer>
    <Path>/test</Path>
    <HealthMonitor>
      <IsEnabled>true</IsEnabled>
      <IntervalInSec>5</IntervalInSec>
      <TCPMonitor>
        <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      </TCPMonitor>
    </HealthMonitor>
  </HTTPTargetConnection>
</TargetEndpoint>

  3. אם יש מגבלה כלשהי שמאפשרת שימוש רק ב-TargetServer אחד, ואם לא נעשה שימוש ב-HealthMonitor, אל תציינו את MaxFailures בהגדרה של LoadBalancer.

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

קריאה נוספת