הגדרת API Gateway לאפליקציה ניידת: היכן נשבר התעבורה
לקוח נייד הוא המקור הפחות יציב מכל מקורות התעבורה שהבקאנד רואה. הטלפון נכנס למטרו, עובר מ-Wi-Fi ל-LTE, האפליקציה עוברת לרקע וחוזרת כעבור שעה — וכל אירוע כזה קורע את החיבור הקיים באמצע הדרך.
השרת באותו רגע כבר ביצע את העבודה, אבל אין למי להשיב: הלקוח נעלם, והבקשה הבאה שלו מגיעה כחדשה. כך מתחילה הגדרת API Gateway לא מהקונפיגורציה, אלא מפירוק של היכן בדיוק נשברת התעבורה.
מכאן נכנס לתוקף אפקט המפולת. הלקוח לא קיבל תשובה — כלומר, הוא חוזר על הבקשה, לעתים קרובות עם אותו מפתח פעולה. בלי דה-דופליקציה בכניסה, תשלום אחד הופך לשלושה, ופרץ החזרות לאחר התחברות מחדש המונית מפיל את צוואר הבקבוק — בדרך כלל את מסד הנתונים — בדיוק ברגע שבו הוא נחוץ ביותר.
שער לאפליקציה ניידת מחויב לכבות זאת בכניסה: לשמור על אידמפוטנטיות לפי מפתח הבקשה, להגביל את הקצב לפי לקוח ולא לפי IP, ולא להעביר חזרה הלאה אם הראשונה עדיין בעבודה.
המקור השלישי לתקלות הוא חוסר סנכרון בין גרסאות. המשתמש לא עדכן מיד, build ישן שולח בקשות בפורמט שהבקאנד כבר לא מבין, ובמקום שגיאה מובנת הוא מקבל ניתוק.
כאן עוזרת גרסאות של מסלולים וחוזה מפורש: השער עצמו מחליט איזו גרסת בקאנד להחזיר עבור כותרת לקוח מסוימת, ומסנן בקשות לא תואמות לפני שהן מגיעות לשירותים.
ניתוקי חיבורים, פרצי חזרות וחוסר סנכרון בין גרסאות — שלושה סוגים שונים של כשלים, אבל הם מטופלים בנקודה אחת. בהמשך נפרק כיצד זה נסגר ברמת הקונפיגורציה של השער: timeouts, retries, אידמפוטנטיות וניתוב לפי גרסאות.
מה נותן שער API מוגדר היטב למוצר מובייל
אפליקציית מובייל פועלת בתנאים שאין לאינטרנט: הרשת מתנתקת במעלית וברכב התחתית, המכשיר נכנס למצב שינה באמצע בקשה, ועדכון גרסה בצד הלקוח נמשך שבועות — build ישן ממשיך לפנות ל-backend עד שהמשתמשים מתעדכנים.
אם כל בקשה כזו הולכת ישירות לשירותים, כל חוסר יציבות בתקשורת הופך לעומס על ה-backend: חיבורים שנקטעו, ניסיונות חוזרים, כפילויות בפעולות. הגדרת API Gateway מוציאה את כל תעבורת המובייל לנקודת כניסה אחת, ומשם הבעיות הללו נפתרות ברמה אחת, ולא בכל שירות בנפרד.
יציבות הסשנים נשענת על כך שהשער לוקח על עצמו את אימות ורענון הטוקנים, ולא מוסר זאת לאפליקציה. הלקוח מאריך גישה באמצעות refresh-טוקן דרך השער, בלי לבנות מחדש בקשה לכל שירות; בעת ניתוק החיבור הניסיון החוזר מתבצע עם אותו מזהה, והפעולה אינה מוכפלת. עבור המשתמש זה נראה פשוט: האפליקציה לא משליכה למסך הכניסה לאחר החלפת רשת.
העומס על ה-backend הופך לצפוי כאשר השער מגביל את קצב הבקשות לפי משתמש ומכשיר, חוסם ניסיונות חוזרים מיותרים ומחזיק תור בזמן התפרצות. ההגבלות מוגדרות כמדיניות על המסלול, ולא כקוד בתוך השירות, ולכן הסף משתנה בלי release.
התפרצות לאחר תפוצה או תקלת רשת כבר אינה מגיעה לבסיס הנתונים במלואה — אליו מגיע רק מה שעבר את הבדיקה.
ניהול ה-releases נשען על אותה נקודה: ניתוב לפי גרסת האפליקציה, הוצאה הדרגתית של build חדש לחלק מהמשתמשים, rollback מיידי על ידי החלפת כלל. גרסאות ישנות ממשיכות לעבוד לפי המסלולים שלהן, עד שחלקן מתאפס — וזה מסיר את הצורך להחזיק תאימות בכל השירותים בבת אחת.
נקודת כניסה אחת מספקת גם observability: השהיות, קודי תגובה ושיעור שגיאות נראים לפי כל מסלול וגרסת לקוח, ולא מפוזרים בלוגים של עשרה שירותים.
מפרקים כיצד זה נסגר: אילו מסלולים ומדיניות מוגדרים לפרופיל התעבורה שלכם, כיצד מועברת ההרשאה הנוכחית ומה קורה לגרסאות האפליקציה שכבר הופצו.
אפשרויות שער: מאזן עומסים מובנה, Kong, Traefik, שירות ענן
הבחירה בנקודת כניסה ל-API של המובייל אינה עניין של טעם, אלא תוצאה של היכן האפליקציה נמצאת, מי מנהל את האישורים ובאיזו תדירות משתנות כללי הניתוב. להלן ארבע אפשרויות ממשיות, שביניהן בוחרים בתחילת הפרויקט.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מאזן עומסים מובנה | אשכול אחד, כללים פשוטים, אין צרכני API חיצוניים | אין ניתוב עדין לפי כותרות, מגבלות והרשאה נעשות בתוך האפליקציה עצמה |
| Kong | נדרשים תוספים: מגבלות, מפתחות, טרנספורמציה של בקשות, אנליטיקה | דורש קו מתאר נפרד ותחזוקה, תצורה דקלרטיבית מורכבת יותר לצוותים קטנים |
| Traefik | ניתוב דינמי, שחרורים תכופים, כמה סביבות | פחות תוספים מוכנים, חלק מהלוגיקה של ההרשאה נכתב באופן עצמאי |
| שער ענן | אין תשתית משלך, נדרשים אישורים מנוהלים והתאמה אוטומטית | תלות בספק, שליטה מוגבלת בהתנהגות ברמת הרשת |
מאזן עומסים מובנה מכסה את התרחיש הבסיסי: אפליקציה מאחורי אשכול אחד, סט יציב של נתיבים, מינימום אינטגרציות חיצוניות. ברגע שמופיעות גרסאות API עבור בניות ישנות של לקוח המובייל, מגבלות לפי מכשירים או כללים שונים לשותפים, הוא מפסיק להתמודד — הלוגיקה מתפזרת על פני קוד האפליקציה.
Kong ו-Traefik פותרים זאת ברמת השער: נתיבים, מגבלות, בדיקת טוקנים ושחרורים בסגנון קנרית מתוארים בתצורה, ולא בעריכות בשירותים. שער ענן מסיר שאלות של תפעול, אך כובל לספק.
בפועל הבחירה מצטמצמת לשאלה אם אתם מוכנים להחזיק קו מתאר משלכם למען גמישות — או שמעדיפים שירות מנוהל בתמורה לשליטה פחותה.
שלבי הגדרת שער לתעבורת מובייל
הגדרת API Gateway לאפליקציית מובייל מתחילה לא בקונפיגורציה, אלא במיפוי מלאי: אילו נקודות קצה הלקוח באמת קורא להן, אילו גרסאות מערכת הפעלה ובניינים עדיין בשימוש, והיכן התעבורה עוברת ישירות ל-backend בעקיפת השער.
בלי שלב זה, כללי הניתוב נכתבים "לפי העין" ונשברים כבר בשחרור הראשון. להלן הרצף שלפיו אנו מנהלים את העבודה.
- ביקורת נקודות קצה. אוספים מפת קריאות מהלוגים והטראסות: מתודה, תדירות, גודל תגובה, תלות בגרסת האפליקציה. מסמנים מסלולים מיושנים שאנו מחזיקים רק למען בניינים ישנים, ונקודות שבהן לקוח המובייל פונה לשירותים ישירות.
- תכנון סכימת הניתוב. מפרקים את המסלולים לפי קידומות וגרסאות, קובעים מה עובר לשער ומה נשאר פנימי. מקבעים כללי שכתוב נתיבים וכותרות, כדי שלא יהיה צורך לשנות את ה-backend עבור כל שחרור של הלקוח.
- הגדרת כללים. מגבלות קצב בקשות לפי מכשיר ולפי משתמש, פסקי זמן, ניסיונות חוזרים, מטמון תגובות שאינן משתנות בין קריאות. בנפרד — כללי אימות: בדיקת טוקן בכניסה, כדי שבקשה לא מורשית לא תגיע לשירותים.
- בדיקת עמידות לתקלות. מריצים תרחישי דגרדציה: אי-זמינות של שירות אחד, פרץ תעבורה בעת עדכון המוני של האפליקציה, ניתוק חיבור ברשת מובייל. בודקים מה השער מחזיר ללקוח במקום שגיאה וכמה מהר הוא מתאושש לאחר הסרת העומס.
- נצפות. מגדירים מטריקות לפי מסלולים, שיעור שגיאות והשהיות לפי כל נקודת קצה, טראסה של בקשה מהלקוח עד השירות. בלי זה התקרית הבאה מתגלה בעיוורון.
- מסירה לתפעול. הקונפיגורציה עוברת לריפוזיטורי, שינויים — דרך סקירה ופריסה אוטומטית, ולא ידנית בפרודקשן. כותבים נוהל: כיצד להוסיף מסלול, כיצד להחזיר כלל אחורה, מי תורן.
הסדר חשוב: כללים שנכתבו לפני הביקורת נאלצים לשכתב, ועמידות לתקלות שנבדקה אחרי השחרור עולה ביוקר. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית עבודה.
תצורות, סכמות ותקנות שנשארות אצל הצוות
העבודה על השער אינה מסתיימת בהפעלה, אלא בהעברת ארטיפקטים שלפיהם צוות הלקוח יוכל להמשיך לתפקד בלעדינו. להלן מה שנשאר בפועל במאגר ובמסמכים.
- תצורת השער בצורת מניפסטים דקלרטיביים: מסלולים, אפסטרימים, בדיקות תקינות (health-check), זמני המתנה ומגבלות — הכול במערכת בקרת גרסאות, ולא בממשק ווב. שינוי עובר סקירה ומופץ כמו מהדורה רגילה.
- סכמת ניתוב עם מפת שירותים: איזה נתיב מוביל לאיזה בקאנד, היכן ניהול גרסאות, היכן ענפי קנרית, וכיצד נפתרים קונפליקטים בין כללים.
- מדיניות גישה: סכמות אימות, הנפקה וסבב מפתחות, הגבלת קצב בקשות לפי לקוחות ונקודות קצה, כללי חסימה של תעבורה חשודה.
- תצורת עמידות: ניסיונות חוזרים, מפסקי זרם, דגרדציה בעת אי-זמינות בקאנד — עם ציון אילו תרחישים עוברים דגרדציה ואילו מחזירים שגיאה.
- מערך בדיקות תקינות: readiness/liveness עבור השער עצמו ושאילתות סינתטיות במסלולים קריטיים, שתופסות תקלה לפני המשתמשים.
- תקנת תפעול: סדר הפצת שינויים, חזרה לתצורה קודמת, תגובה לאירועים, נקודות בקרה של מדדים והתראות.
- תיעוד: תיאור הארכיטקטורה, סכמת זרימות בקשות, הוראות להוספת שירות חדש וצ'ק-ליסט לקליטת שינויים.
כל ארטיפקט אנחנו עוברים יחד עם צוות הלקוח — לא מוסרים אותו כארכיון, אלא עוברים עליו בשינוי אמיתי: להוסיף מסלול, להנפיק מפתח, לחזור לתצורה קודמת. כך תקנת התפעול הופכת לכלי עבודה אמיתי, ולא לתיקייה שאף אחד לא פותח.
מקרה בוחן: כיצד שער מבוסס Kong ביטל ניתוקי סשנים באפליקציית מובייל
הלקוח — שירות משלוחים עם אפליקציית מובייל ל-iOS ו-Android, כ-400 אלף משתמשים פעילים. ה-Backend — אוסף שירותים מאחורי מאזן עומסים, אימות באמצעות JWT, סשנים קצרי מועד.
בעומסי שיא (שעות ערב, מבצעים) שיעור הבקשות המוצלחות ירד ל-91%: חלק מהבקשות נותקו בשלב בדיקת הטוקן, הלקוחות קיבלו שגיאה וחזרו למסך התחברות מחדש. התמיכה תיעדה זינוק בפניות "זורק אותי מהאפליקציה" — עד 1,800 קריאות בשבוע, וזאת מבלי לספור את אלה שפשוט מחקו את האפליקציה.
מה שינו
פרסו Kong כנקודת כניסה אחודה לתעבורת המובייל.
הגדרות מרכזיות: בדיקת JWT הועברה לרמת השער, כדי לא להעביר כל בקשה דרך שירות האימות; מגבלות בקשות מחושבות לפי משתמש ולא לפי IP — אחרת לקוחות תחת אותו מפעיל סלולרי חסמו זה את זה; health-check ל-Backends עם הוצאה אוטומטית של צומת שנפל מהרוטציה; ניסיונות חוזרים על מתודות אידמפוטנטיות עם הגבלה על מספר הניסיונות.
בנפרד הוגדרו timeouts: קודם לכן בקשה יכלה להיתקע עד שהלקוח ינתק את החיבור בעצמו. כעת השער מחזיר שגיאה ברורה בזמן קצוב, והאפליקציה מציגה מסך ניסיון חוזר במקום קפיאה "לבנה".
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור בקשות מוצלחות | 91% | 99.6% |
| זמן התאוששות לאחר כשל צומת | 4-6 דקות | 20-30 שניות |
| פניות לתמיכה בנושא סשנים | ~1,800/שבוע | ~120/שבוע |
| עומס על שירות האימות | שיא | ירד פי 3 |
זמן ההתאוששות הצטמצם הודות להוצאה אוטומטית של הצומת מהרוטציה: קודם לכן התורן נודע על הבעיה מהקריאות והעביר את התעבורה ידנית, כעת השער עושה זאת בעצמו, והצוות מקבל התראה בדיעבד.
חודש לאחר ההשקה פניות התמיכה בנושא ניתוקי סשנים ירדו ביותר מפי עשרה — הדבר פינה את הקו הראשון למשימות שאכן דורשות אדם.
במה שונה שער ל-API נייד מפרוקסי אינטרנט רגיל
פרוקסי אינטרנט רגיל פועל בהנחה שהלקוח הוא דפדפן על ערוץ יציב: החיבור נשמר זמן רב, הגרסה אחת, וניתן להחזיר את התשובה כולה. API נייד פועל בתנאים הפוכים. המכשיר נכנס לרכבת התחתית, מאבד את הרשת באמצע הבקשה, עובר בין רשתות וחוזר עם אותו מזהה בקשה.
שער ל-API נייד מחויב לשרוד ניתוק חיבור ולא ליצור כפילויות: אידמפוטנטיות לפי מפתח בקשה, חציצת התשובה והחזרה חוזרת ללא ביצוע חוזר של הפעולה בבקאנד.
ההבדל השני — גרסאות הלקוח. באינטרנט אתם מפרסמים build חדש וכולם מקבלים אותו מיד, בעוד שבאפליקציה ניידת חיות בו-זמנית כמה גרסאות: חלק מהמשתמשים לא עדכנו, חלק נשארו על build ישן בגלל מדיניות החנות.
השער מנתב בקשות לפי גרסת הלקוח וכותרות תאימות, מחזיר סכמות תשובה שונות ויודע לכבות בעדינות שדות מיושנים מבלי לשבור builds ישנים. זו לא "פיצ'ר לעתיד", אלא תנאי שבו שחרור גרסה חדשה לא הופך לשגיאות המוניות אצל אלה שעדיין לא עדכנו.
השלישי — חיסכון במשאבי הלקוח. המכשיר הנייד מוגבל בזיכרון, בסוללה ובתעבורה, ולכן השער עוסק בדחיסת תשובות, בהחזרת שדות שהשתנו בלבד ובאיגוד כמה בקשות של מסך לקריאה אחת. כאן גם נפתרת ההרשאה: הטוקן מתחדש בשער, ולא בכל לקוח, ומדיניות הגישה משתנה באופן מרוכז, ללא הוצאת build חדש.
הרביעי — נראות. בתעבורה ניידת צריך לראות לא רק קודי תשובה, אלא גם את שיעור הבקשות עם רשת גרועה, את ההתפלגות לפי גרסת הלקוח ואת הזמן עד לבית הראשון בערוץ חלש. בלי זה אי אפשר להבין אם הדגרדציה היא בעיה בבקאנד או בגרסה מסוימת של האפליקציה אצל חלק מהמשתמשים.
בדיוק משום כך הגדרת API Gateway למוצר נייד היא משימה הנדסית נפרדת, ולא העתקה של תצורת פרוקסי אינטרנט. אנו מנתחים את פרופיל התעבורה של האפליקציה הספציפית ומרכיבים עבורה מדיניויות ניתוב, חזרות ו-versioning.
ספקות טכניים לפני תחילת העבודה
ספקות בדרך כלל אינם נוגעים לשאלה "האם השער עובד", אלא לאופן שבו הוא משתלב במערך הקיים: מה יישבר במהלך המיגרציה, מי מחזיק בתצורה, ומה יקרה בעת כשל. להלן תשובות לשאלות שעולות לרוב בשלב ההערכה.
האם ניתן לחבר את השער לבקאנד קיים ללא כתיבה מחדש של השירותים?
כן. השער מותקן לפני השירותים הנוכחיים ומנתב תעבורה לפי כללים — השירותים עצמם אינם משתנים. משתנות רק הכתובות שדרכן האפליקציה הסלולרית פונה אליהם. אם לשירותים כבר יש ניהול גרסאות, המסלולים מתוארים באופן דקלרטיבי ומועברים ללא שינוי בקוד.
כיצד מתבצעת המיגרציה והאם קיימת אפשרות חזרה?
אנחנו מעבירים את התעבורה בהדרגה: תחילה חלק מהמשתמשים, לאחר מכן את השאר. המערך הישן נשאר פעיל עד לאישור היציבות, ולכן החזרה לסכמה הקודמת אורכת דקות. תצורת השער נשמרת במאגר — החזרה מתבצעת על ידי שחזור המצב הקודם, ולא על ידי עריכה ידנית.
מה עם תאימות לגרסאות ישנות של האפליקציה?
משתמשים מתעדכנים לא באופן מיידי, ולכן אנחנו שומרים על מסלולים תואמים לגרסאות קודמות של הלקוח. קריאות מיושנות מסומנות ומוצאות משימוש לפי לוח זמנים, כאשר חלקן יורד לרמה זניחה. כך עדכון האפליקציה אינו הופך לחובה עבור כולם בבת אחת.
מי אחראי על התפעול לאחר ההשקה?
התצורה, כללי הניתוב ומדיניות המגבלות מועברים לצוות שלכם עם תיעוד וניתוח של תרחישים טיפוסיים. אנחנו יכולים להישאר בתמיכה — ואז שינויים במסלולים וטיפול באירועים עוברים דרכנו לפי נוהל מוסכם.
מה קורה בעת כשל של השער עצמו?
השער נפרס במספר עותקים, ובדיקת חיות מוציאה את הצומת שנכשל מהאיזון באופן אוטומטי. מגבלות וזמני המתנה מוגדרים כך ששירות איטי לא גוזל משאבים מהאחרים. זה מעביר את הכשל מסוג "כל האפליקציה מושבתת" לסוג "פגיעה במסלול אחד".
תארו את המערך שלכם — נחזור עם הערכה ותוכנית עבודה.
נדון במשימה שלכם ונחזור עם הערכה ותוכנית
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו זקוקים להקשר על התשתית שלכם. שער (Gateway) הוא הנקודה שדרכה עובר כל התעבורה של האפליקציה, ולכן החלטות בנוגע לניתוב, מגבלות והרשאה תלויות באופן שבו השירותים בנויים כיום, היכן נשמרים המפתחות ואילו דרישות עומס קיימות. ככל שהנתונים הראשוניים מדויקים יותר, כך יש פחות הנחות בהערכה.
מה שמועיל לקבל מכם כבר בהתחלה:
- תרשים של השירותים הנוכחיים: אילו שירותים נמצאים מאחורי השער, כיצד הם מתקשרים ביניהם, והאם קיימת כבר נקודת כניסה ללקוחות מובייל.
- דרישות עומס: מספר חיבורים בו-זמניים בשיא, פרופיל התעבורה, קפיצות עונתיות.
- מודל הרשאה: כיצד מונפקים ונבדקים טוקנים, האם נדרשים ספקים חיצוניים, תפקידים והרשאות גישה.
- מגבלות תשתית: היכן נפרס השער, אילו סביבות (dev/stage/prod), דרישות לבידוד ולגישות.
- בעיות נוכחיות: מה אינו מספק בפתרון הקיים — השהיות, הגדרה ידנית של נתיבים, היעדר נראות (observability).
- תקנות: דרישות אבטחה, לוגים, שמירת נתונים אישיים, תקנים ענפיים.
בתגובה אנחנו מכינים תוכנית עבודה עם שלבים, לוחות זמנים ותחומי אחריות, תרשים של ארכיטקטורת השער היעד עם נימוק לבחירה בין Kong ל-Traefik עבור המשימה שלכם, וכן רשימת סיכונים ודרכי rollback בכל שלב. ההערכה מבוססת על היקף אמיתי, ולא על תבנית ממוצעת.
תארו את המשימה בפורמט נוח — שיחת ועידה, התכתבות או תיאור קצר של הנתונים הראשוניים. נחזור עם הערכה ותוכנית שאפשר להתחיל לפיה.