AWS API Gateway מקצה לקצה: REST מול HTTP, JWT, הגבלת קצב, ניטור

הגדרת AWS API Gateway: היכן נשבר הפרודקשן

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

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

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

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

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

האפקט של העברת תעבורה לשער מנוהל

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

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

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

נראות בקשות סוגרת סוג נוסף של תקלות: רואים השהיה בכל נתיב, שיעור תשובות עם שגיאה ואת נתיב הבקשה המלא. ירידת ביצועים נתפסת בשלב שבו ההשהיות עולות, ולא אחרי פניות משתמשים — התרחיש «השירות קרס בגלל לקוח כבד אחד» מפסיק להיות אפשרי.

REST, HTTP ושערים פרטיים: מה לבחור

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

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

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

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

במה המצבים נבדלים בפועל

הגדרה ובדיקה: שלבי הטמעת השער

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

1. ביקורת תשתית API. עורכים מלאי של כתובות ולקוחות, מנתחים סכמות הרשאה קיימות, מצלמים פרופיל תעבורה יומי. בפלט — מפת נתיבים ורשימת צווארי בקבוק: כפילויות נתיבים, בדיקת טוקן בתוך כל שירות, פורמט שגיאות שונה.
2. תכנון סכמת ניתוב. לכל קו בוחרים מצב שער, כללי התאמת נתיבים וגרסאות, כדי שלקוחות ישנים לא יישברו עם יציאת גרסה חדשה של השירות.
3. תצורה. מגבלות קצב בקשות לפי לקוחות, מאמתים, המרת בקשות ותשובות, פורמט שגיאות אחיד, טיפול ב-timeouts עד ל-backend.
4. בדיקה בסביבת בדיקות. תרחישים פונקציונליים ותקלות: אי-זמינות שירות, טוקן שפג, מגבלה שהוצתה. מתעדים קוד תשובה צפוי לכל מקרה.
5. בדיקת עומס לשער. משחזרים פרופיל פרודקשן, בודקים השהיה, שיעור שגיאות והיכן נתקלים קודם — במגבלות, ב-backend או בשער.
6. מסירה לתפעול. התצורה נשמרת כקוד, מדדים והתראות מוגדרים, למשמרת התורן יש הוראות לתקלות אופייניות וסדר שחזור.

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

חבילת מסירה: סכמות, מדיניות, נהלים

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

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

מקרה בוחן: איך השער הסיר עומס שיא מהשירותים

לפני: נקודת כניסה בכל שירות

השירותים קיבלו תעבורה חיצונית ישירות — כל אחד בדק טוקנים בעצמו, ספר מגבלות בקשות בעצמו, ואף הגיב בעצמו לקפיצות. בשעות שיא, כשנשלחה תפוצה או שהחל מבצע, העומס בכניסה גדל פי 8-12: בקשות עמדו בתורים, ושיעור התשובות עם שגיאה עמד על כ-4%.

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

מה ארגנו מחדש

את נקודת הכניסה העברנו אל AWS API Gateway: בדיקת JWT, הגבלת קצב וניתוב מתרחשים כעת לפני קריאה ל-backend, ולכן בקשות לא תקינות לא מגיעות לשירותים בכלל.

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

מה השתנה במדדים

אחרי העברת התעבורה שיעור שגיאות 5xx ירד מכ-4% ל-0.3%, זמן התגובה באחוזון ה-95 התקצר בכשליש בערך. שיא גבוה פי 12 מהממוצע השער מחזיק בלי הרחבת שירותים: רק נקודת הכניסה מתרחבת, וה-backend עובד במצב יציב.

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

במה מכסות שונות מהגבלת קצב?

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

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

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

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

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

ספקות טכניים נפוצים לפני הטמעה

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

מה יקרה בעלייה חדה בבקשות?

הגדרת AWS API Gateway בנויה סביב מגבלות: הגבלת קצב ברמת המתודות, תוכניות שימוש נפרדות לצרכנים חיצוניים, ספים לפי מפתח גישה. קפיצה מעל המגבלה מוחזרת כ-429 עם כותרת על זמן ניסיון חוזר, ולא מפילה את ה-backend. התראות על שיעור 4xx ו-5xx ועל התקרבות לתקרה מגיעות לפני שירידת הביצועים נעשית מורגשת ללקוחות.

אפשר להחליף סכמת הרשאה בלי לשכתב לקוחות?

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

מה נשאר לצוות אחרי המסירה?

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

נדבר על המשימה: נחזור עם הערכה ותוכנית

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

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

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

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

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