אסטרטגיות לניהול פרטי הכניסה

שיתוף פרטי הכניסה בין בקשות ה-API משפר את הביצועים ומונע תקורה מוגזמת שעלולה לגרום לשגיאות של הגבלת קצב. במדריך הזה מוסבר איך לבצע אופטימיזציה של ניהול פרטי הכניסה של OAuth2 כדי שהאפליקציה תוכל ליצור אינטראקציה יעילה עם Google Ads API.

האסטרטגיה לשיתוף פרטי הכניסה תהיה תלויה בסוג האפליקציה: multithreaded או מרובת-תהליכים (או מבוזרת). אפליקציה שהיא גם מרובת תהליכים וגם מרובת הליכים בכל תהליך צריכה להשתמש בשתי האסטרטגיות. אפשר גם להתאים את השיטות האלה לכמה חשבונות Google Ads.

Multithreaded

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

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

מרובה תהליכים או מבוזר

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

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

רענון המשימה

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

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

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

מאגר נתונים

אתם יכולים להשתמש במאגר נתונים קיים או לפרוס מאגר נתונים שספציפי לשיתוף של פרטי כניסה בין שרתים. פתרונות אפשריים כוללים שרתי מטמון, כמו Memcached או Infinispan, או מאגרי נתונים מסוג NoSQL, כמו MongoDB.

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

כשמאחסנים את פרטי הכניסה, צריך לאחסן את הערך המחושב של expiry_time (הזמן הנוכחי + expires_in) ואת refresh_token לצד access_token. הערך של expiry_time מחושב כזמן של בקשת הרענון של access_token בתוספת הזמן של expires_in.

מאגר שרתים

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

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

ניהול פרטי כניסה לכמה חשבונות

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

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

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

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