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

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

בגישת ה-Token Bucket, כל משתמש מקבל הקצאת קיבולת "אסימונים" (צילום: Dreamstime)

מאת יוליה זרובינסקי, מהנדסת תוכנה, Intuit Israel

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

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

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

מה זה Throttling ואיך זה עובד?

ויסות קצב השימוש (Throttling) הוא תהליך שבו מגבילים את מספר הפעולות אותן המשתמש יכול לבצע בזמן נתון, וזהו נוהג חשוב ומקובל באפליקציות המספקות שירותים למשתמשים רבים ומגוונים. לאפליקציות אלה יש כמות משאבים קצובה (כגון חיבורים ל-Database ולזיכרון אפליקציה) אותה חולקים כל המשתמשים.

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

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

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

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

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

לגישה זו יש שני יתרונות:

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

כך עשינו זאת אצלנו

במקרה שלנו, רצינו להגביל את מספר הבקשות המגיעות תוך שנייה ל-Database. כמו כן, היה חשוב שנוכל לכוונן את המגבלות עבור כל משתמש כדי לתמוך ב-Use Cases ייחודיים. בחרנו באלגוריתם ויסות מסוג Token Bucket המיושם על ידי ספריית Go בשם ratelimit, שמאפשר לקבוע את מגבלת הקצב לכל לקוח וניתן לכוונן אותו במקרים אינדיבידואליים.

בגישת ה-Token Bucket, כל משתמש מקבל הקצאת קיבולת "אסימונים". הדלי מתמלא באסימונים לכדי מקסימום שהגדרנו, במועדים קבועים מראש. אם הדלי מלא, האסימונים המיותרים נזרקים. בכל בקשה של משתמש יוצא אסימון מהדלי שלו, ובקשה לא תאושר כשהדלי מרוקן.

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

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

השלב הבא: לתקשר את השינוי ללקוחות

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

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

יש כמה שאלות שחשוב להתעכב עליהן כאשר מכניסים Breaking Changes למערכת:

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

אם תענו על השאלות האלה בעת תכנון יישום של Breaking Changes, התשובות יהפכו את התהליך לפחות מלחיץ וישאירו אותו בשליטתכם.

הכתבה בחסות Intuit

חברת Intuit היא ענקית פינטק אמריקאית, שפתרונותיה הטכנולוגיים משפרים את התנהלותם הפיננסית של עסקים ואנשים פרטיים ברחבי העולם. מוצרי הדגל שלה – TurboTax, Quickbooks, Mint, Credit Karma ו-Mailchimp – מדגימים את היותה חברה הממוקדת בלקוחותיה (כ-100 מיליון) ומוכוונת עיצוב, המחויבת לביצוע מהפך בדרך שבה אנשים מנהלים את החשבונות האישיים שלהם, מפעילים עסקים קטנים ומשלמים לעובדיהם. מרכז הפיתוח של אינטואיט בישראל הוא המרכז השני של החברה מחוץ לארה”ב, והוא נחשב למוביל עולמי בחדשנות בתחומי המובייל, האבטחה וה-machine learning, וקיימות בו קבוצות מחקר ופיתוח בטכנולוגיות מתקדמות, בייחוד בתחומי הדאטה. במרכז, הממוקם בפתח תקווה, מועסקים מעל 300 עובדים ובשנה הקרובה צפויה גדילה משמעותית.

כתבת אורחת

הגב

2 תגובות על "איך מוסיפים מנגנון ויסות לאפליקציה בלי לפגוע בחוויית המשתמש"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
ג.ב.
Guest

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

Julia Zarubinsky
Member

למרות שהservice מבוזר, לא ממשנו את הbuckets בצורה מבוזרת, הbuckets בין הinstances הם בלתי תלוים, והסכום של הקיבלות של הbuckets של כל לקוח (על פני הinstaces) הוא המגבלה שבחרנו עבורו. במקרה שלנו קיבלנו קירוב טוב מספיק.
אם חשוב שהמגבלה תיהיה מדוייקת, אפשר לתחזק את הbuckets במקום אחד שזמין לכל הinstaces של האפליקציה, בדומה לdeistributed cache.

wpDiscuz

תגיות לכתבה: