הגדרת AWS SQS / SNS לתורים והתראות
כאשר תור הודעות מוגדר בצורה שגויה, אובדן נתונים וכפילויות הופכים לשגרה. בפרויקט אחד, תור Standard עם VisibilityTimeout של 30 שניות עיבד סרטונים שנמשכו 5 דקות — ההודעה נקראה מחדש 10 פעמים, סתמה לוגים ושילשה עלויות. אנחנו מתקנים תצורות כאלה כבר למעלה מחמש שנים: אנחנו מתכננים SQS ו-SNS כך שהעומס לא יגדל והודעות יסופקו בדיוק פעם אחת.
אילו בעיות אנחנו פותרים?
Standard או FIFO?
Standard Queue — לפחות פעם אחת, סדר לא מובטח, תפוקה כמעט בלתי מוגבלת. מתאים למיילים, עיבוד תמונות, אינדוקס. כפילויות אפשריות — הצרכן חייב להיות אידמפוטנטי.
FIFO Queue — בדיוק פעם אחת, סדר בתוך קבוצת הודעות. תפוקה: 300 TPS ללא בatching, 3000 TPS עם batching (גודל batch 10). השם מסתיים ב-.fifo. דורש MessageGroupId בעת שליחה. אל תשתמשו ב-FIFO במקום שבו Standard מספיק — זה מטיל אילוצים מיותרים. בפועל, Standard מהיר פי 2 מ-FIFO תחת אותו עומס CPU.
| פרמטר | Standard | FIFO |
|---|---|---|
| מסירה | לפחות פעם אחת | בדיוק פעם אחת |
| סדר | לא מובטח | מובטח בתוך קבוצה |
| תפוקה | בלתי מוגבלת | 300/3000 TPS |
| כפילויות | אפשריות | לא נכללות |
איך להימנע מכפילויות עם VisibilityTimeout?
לאחר ReceiveMessage, ההודעה מוסתרת למשך VisibilityTimeout (ברירת מחדל 30 שניות). אם הצרכן לא קורא ל-DeleteMessage, היא הופכת לזמינה לעיבוד חוזר. טעות אופיינית: timeout קצר יותר מזמן העיבוד. לדוגמה, עיבוד וידאו לוקח 5 דקות, timeout של 30 שניות — המשימה רצה עשרות פעמים במקביל. כלל: timeout ≥ מקסימום זמן עיבוד * 1.5. למשימות לא צפויות, השתמשו ב-ChangeMessageVisibility להארכה.
Long Polling (WaitTimeSeconds: 20) הוא חובה. Short polling בודק רק תת-קבוצה של שרתים — מחזיר תשובות ריקות גם כשהתור לא ריק. לפי תיעוד AWS, Long Polling מפחית קריאות API ב-30–40%.
איך להגדיר Dead-Letter Queue?
DLQ — תור נפרד להודעות לאחר N ניסיונות כושלים. maxReceiveCount = 3–5. ללא DLQ, הודעה שבורה תסתובב ללא הגבלת זמן, תחסום FIFO או תבזבז משאבים. יש לנטר את Dead-Letter Queue: CloudWatch Alarm על ApproximateNumberOfMessagesVisible > 0 מאותת על בעיות צרכן. קבלו ייעוץ על הגדרת DLQ מהמהנדסים שלנו.
איך Long Polling עובד ולמה להפעיל אותו?
Long Polling מפחית זמן השהיה ותשובות ריקות. עם WaitTimeSeconds = 20, הבקשה תלויה עד 20 שניות עד שהודעה מופיעה. זה מוריד עומס רשת ועלויות קריאות API. הפעילו דרך הקונסולה או SDK — QueueAttributeName: 'ReceiveMessageWaitTimeSeconds'. ללא Long Polling, תשובות ריקות יכולות להוות עד 90% מהבקשות — בזבוז עלויות.
Fan-out דרך SNS: שידור אירועים למספר צרכנים
SNS topic → מספר תורי SQS: אירוע order.created אחד מעובד במקביל על ידי חיוב, התראות, מלאי. כל שירות פועל בקצב שלו. חשוב: SQS Access Policy חייב לאפשר sns:SendMessage. סינון הודעות — מנוי מקבל רק אירועים רלוונטיים, למשל לפי אזור. זה מפחית עומס ללא קוד נוסף.
{ "FilterPolicy": {
"event_type": ["order.created", "order.cancelled"],
"priority": [{"numeric": [">=", 5]}]
}
}Lambda כצרכן SQS
Event Source Mapping מנהל polling וסקיילינג. גודל batch מקסימלי: 10000 ל-Standard, 10 ל-FIFO. ReportBatchItemFailures — השתמשו תמיד. כשהודעה אחת נכשלת, רק אלה שנכשלו מוחזרות; השאר לא משוכפלים.
def handler(event, context):
failed_items = []
for record in event['Records']:
try:
process(record['body'])
except Exception:
failed_items.append({"itemIdentifier": record['messageId']})
return {"batchItemFailures": failed_items}ניטור ומדדים אופייניים
| מדד | התראה | משמעות |
|---|---|---|
{ "FilterPolicy": { "event_type": ["order.created", "order.cancelled"], "priority": [{"numeric": [">=", 5]}] } } | > מקסימום TTL * 0.7 | הצרכן מפגר |
def handler(event, context): failed_items = [] for record in event['Records']: try: process(record['body']) except Exception: failed_items.append({"itemIdentifier": record['messageId']}) return {"batchItemFailures": failed_items} | קפיצה פתאומית | צרכנים תפסו הודעות אבל לא מעבדים |
ApproximateAgeOfOldestMessage לעומת ApproximateNumberOfMessagesNotVisible | פער | עומס מצטבר |
התהליך שלנו
- ניתוח: לימוד הארכיטקטורה הנוכחית שלכם, עומס, SLA. זיהוי צווארי בקבוק: כפילויות, אובדן, עיכובים.
- עיצוב: בחירת סוגי תורים, פרמטרים (VisibilityTimeout, Long Polling), עיצוב DLQ ו-Fan-out.
- יישום: הגדרת מדיניות IAM, פריסה דרך Terraform או CloudFormation, אינטגרציה עם Lambda ו-EventBridge.
- בדיקות: בדיקות עומס, בדיקות סובלנות לתקלות, תרחישי שגיאה.
- פריסה וניטור: פריסה, הגדרת התראות CloudWatch, דשבורדים.
שלבים מרכזיים להגדרת SQS ו-SNS
1. קבעו את סוג התור הנדרש: Standard או FIFO. 2. הגדירו VisibilityTimeout: מדדו זמן עיבוד מקסימלי, הכפילו ב-1.5. 3. צרו DLQ עם maxReceiveCount = 3. 4. הפעילו Long Polling (WaitTimeSeconds = 20). 5. הגדירו תפקידי IAM: אפשרו ל-SNS לכתוב ל-SQS, ול-Lambda לקרוא מ-SQS. 6. בדקו תרחיש שגיאה — ההודעה צריכה להגיע ל-DLQ. 7. הגדירו התראות CloudWatch על גיל הודעה וגודל DLQ.מה כלול
- ביקורת על הארכיטקטורת אירועים הנוכחית
- עיצוב SQS/SNS בהתחשב בעומס והבטחות
- הגדרת DLQ, Long Polling, מדיניות IAM
- אינטגרציה עם Lambda, EventBridge, CloudWatch
- ניטור והתראות (CloudWatch, SNS->Slack/PagerDuty)
- תיעוד והדרכת צוות
- תמיכה ל-30 יום לאחר הפריסה
לוח זמנים ותמחור
הגדרת SQS + SNS בסיסית עם Fan-out — 1–2 ימים. ארכיטקטורת אירועים מורכבת עם סינון, DLQ, Lambda וניטור — 3–5 ימים. התמחור נקבע באופן אישי — צרו קשר להערכה. קבלו ייעוץ והגדרה תוך יום אחד.
למהנדסים שלנו ניסיון של שנים והסמכת AWS Solutions Architect. SLA לתקלות — 99.9%. פנו אלינו להערכת הפרויקט שלכם.