- Simple Notification Service (בקיצור: SNS)
- Simple Queue Service (בקיצור: SQS)
- Simple Workflow Service (בקיצור: SWF)
- Simple Email Service (בקיצור: SES)
Simple Notification Service
![]() |
מקור: אמזון |
![]() |
ניתן לשלוח בהודעת ה SNS טקסט שונה לכל פרוטוקול של מנוי |
- Apple Push Notification Service (בקיצור: APNS)
- Amazon Device Messaging (בקיצור: ADM)
- Google Cloud Messaging for Android (בקיצור GCM)
- וכמו כן, לשירותי ההודעות של מייקרוסופט (NPNS ו WNS), ושל Baidu (ענק החיפוש הסיני).
אמינות ההודעות
מה קורה כאשר נשלחה הודעת SNS ללקוח HTTP שכרגע אינו זמין? אולי השרת בדיוק נפל, או שהייתה תקלת רשת ששיבשה את ההודעה? במובייל ייתכן מצב זמני של ביטול הודעות push / הסרה והתקנה של האפליקציה (“Endpoint is disabled”).
עבור חלק מהודעות SNS (למשל SMS, או אימייל), איבוד של הודעה אחת מתוך אלף היא לא בעיה גדולה. במקרים מסוימים – זו דווקא כן בעיה, ואז נרצה לטפל בה.
ל SNS יש מדיניות שליחה מחדש (“Delivery Retry Policies”), המאפשרת להעלות את רף האמינות של ההודעות שנשלחות. לצורך עניין זה אתמקד בהודעות HTTP/S.
מבחינת SNS, הודעה נכשלה אם:
- הנמען החזיר קוד HTTP מסדרת 5xx. (כאשר יש 404 או 403, זו לא ממש הצלחה, אבל אין כנראה טעם לנסות לשלוח מחדש את ההודעה).
- עבר timeout של 15 שניות ללא תגובה מה endpoint.
- תקלת תקשורת ברורה (תקלה בשליחת ההודעה, SSL certificate לא מתאים, וכו’).
Simple Queue Service
ההודעה נשלחת ל Queue, והשירות שמקבל את ההודעה שולף אותה ביזמתו מה Queue. לאחר שסיים לטפל בה – מוחק אותה (סדר זה נקבע בכדי לשמור על Data שלא יאבד). למבנה ה Queue יש כמה יתרונות:
- איזון עומסים בין חלקים שונים של המערכת: כאשר קצב ההודעות מה Producer מגיע ב peaks – ה Queue יאזן אותם. השירות הצורך את ההודעות קובע את קצב העבודה לו הוא מסוגל להגיב – ולכן לא ייפגע מ Self Denial of Service.
- מבנה ה Queue מאפשר לנתק, במידה מסוימת, בין זמן שליחת ההודעה – לזמן הטיפול בה. למשל: לשלוח הודעות ל Queue במשך כל היום אך להעלות ה Service שמטפל בהן, רק למשך שעות הלילה – ואז לטפל בכל ההודעות באצווה.
לצורך שיתוף Queue בין כמה צרכנים (בד”כ מספר instances של אותו ה service) – לכל Queue מוגדר Visibility Timeout (ברירת מחדל = 30 שניות). אם הודעה נשלפה, היא נחשבת ל “in flight” ואז יש לשירות שאסף אותה 30 שניות למחוק אותה, או לבקש הארכה. אם לא עשה זאת – ההנחה היא שהוא “נכשל” בטיפול בה (למשל: קרס, איבד אותה, וכו’) ולאחר 30 שניות היא תהיה זמינה לאיסוף ע”י instance אחר.
ניתן לבצע חלוקת עבודה בין כמה instances, פשוט ע”י שיתוף של Queue ביניהם:
- ניתן להאזין ל Alert על עומק ה Queue, ואם נראה שהשירות לא עומד בקצב – לייצר לו עוד instances. אם תרצו – אמזון תנהל התנהגות זו עבורכם בעזרת SQS Based Scaling.
- בכדי לא לבזבז זמן על Polling, ה API של SQS תומך ב “Long Polling”. כלומר: קריאה ש”תתקע” למספר שניות שהוגדר, בהמתנה להודעה שאולי תגיע בזמן הזה – במקום לנסות שוב ושוב לבדוק האם ההודעה הגיעה.
SQS תוכנן להיות אמין, זמין, ולא לאבד הודעות. החלטות התכנון הללו גרמו להעדיף שליחה של הודעה פעמיים, על פני איבוד הודעה. במקרים נדירים הודעה תתקבל מה Queue פעמיים, ועליכם לתכנן את המערכת שלכם שתוכל להתמודד עם מצב שכזה בצורה… חיננית – נקרא לזה.
עבור השגה של ה Scalability, אמזון מציע Soft-FIFO בלבד. כלומר: הודעות יהיו “בערך” First In-First Out, הסבירות שהודעה a תשלף מה Queue לפני הודעה b גדלה ככל שהודעה a נשלחה זמן גדול יותר לפני הודעה b. ערבוב בין הודעות שנשלחו בזמן קרוב מאוד – הוא יחסית צפוי. ערבוב בין פרקי זמן ארוכים יותר (מספר שניות) – הולך והופך נדיר.
גודל ההודעה האפשרי הוא של 256KB.
![]() |
ההגדרות של Queue, ב SQS |
SQS הוא לא שירות יקר, אבל ניתן לחסוך עוד בעלויות ע”י שליחה של אצוות של עד עשר הודעות, במחיר של שליחת הודעה אחת – כל עוד הגודל הכולל של ההודעות באצווה לא גדול ממחסום ה 64KB.
אמזון מספקת ספרייה בשם AmazonSQSBufferedAsync client שמסייעת לנהל את האצוות, כמעט לבד, עבורכם. כרגע היא זמינה (ככל הידוע לי) רק בSDK לג’אווה.
אמזון מציעה מיליון בקשות ל SQS בחודש (לחשבון, בעת כתיבת פוסט זה), קריאה, כתיבה או מחיקה – בחינם. המחיר של כל מליון בקשות נוספות ל SQS הוא כחצי דולר.
אמנם גודל ההודעה המרבי הוא 256KB, אולם אמזון מחשיבה בקשות הגדולות מ 64KB, לצורכי תמחור, כבקשות נוספות. למשל: קבלת הודעה בגודל של 150KB – תחשב בתמחור כ 3 בקשות, למרות שנעשתה קריאת HTTP יחידה.
SQS vs. Kinesis
אמזון הציגה לאחרונה שירות נוסף בשם קינסיס (פירוש השם: “תנועה”) – שגם הוא מספק ניהול Queues, אמין, זמין, היכול לתמוך ב Scale גבוה. קינסיס הוא “חיקוי” של Apache Kafka, עם כמה שינויים קלים.
מצד אחד – באמזון טוענים ש “SQS יכול לעמוד בכל Scale”.
מצד שני – בעוד SQS הוא מנוהל לחלוטין יש לו כמה “כאבי ראש” שיש להתמודד איתם:
- עליכם לנהל את ה shards אליהם מחולק ה Queue – בכדי להגיע Scale. כל shard מוגבל לטיפול של אלף הודעות בשנייה.
- קינסיס הוא “פחות realtime-י”: הוא לא יאפשר לתשאל על הודעות חדשות (לכל shard) יותר מ5 פעמים בשנייה (כן, הוא סופר).
- הנתונים נשמרים על קינסיס כ 24 שעות (מול 14 ימים של SQS).
-
גודל הודעה בקינסיס מוגבל ל 50KB (מול 256KB של SQS),
למה, אם כן, להשתמש בקינסיס ולא SQS?!
על הבדל מהותי אחד, ניתן ללמוד מתוך התמחור של קינסיס:
- כ 2 סנט לכל שעה בו השירות פעיל, ולכל ~7GB של הודעות שנשלח. כלומר: ~10GB כל שעה, לאורך 24 שעות = 24*2*2 = בערך 1$.
- כ 3 סנט לכל מיליון פעולות כתיבה ל Queue. כלומר: ~10GB כל שעה, לאורך 24 שעות = בין 15 סנט ל ~7 דולר, תלוי בגודל ההודעות.
- שימוש ב SQS לתעבורה דומה יעלה בין 10$ ל 360$ (חישוב אצבע, תלוי בגודל ההודעות, שימוש באצוות, וכו’).
סיכום
בחנו שני שירותים פשוטים, אך חשובים מאוד של AWS: שירות ההודעות, ושירות ניהול התורים.
בפוסט הבא נבחן את שני השירותים האחרים: שירות הדואר האלקטרוני, ושירות ה workflows.
שיהיה בהצלחה!
You have a small typo\”מחיר של כל מליון בקשות נוספות ל SQS הוא כחצי דולק\”Great blog by the way!
!Thanks… and thanks:)
הי ליאור, בלוג מעולה, אני קוראת בו מלא לאחרונה. שאלה, האם ה SQS יכול להחליף את ה RabbitMQ?
היי ענת, טוב לשמוע ממך!תודה רבה!SQS מכסה תחום דומה ל RabbitMQ אם כי הוא פשוט, ויש לו אולי עשירית מהיכולות של RabbitMQ.במקרים רבים זה ייתרון – הוא פשוט וממוקד, וקשה ללכת איתו לאיבוד. בקיצור: אם כל מה שאתם צריכים נמצא ב SQS – אז כן.