ادغام SQ های آمازون با AWS Lambda – درک جنبه های اصلی این ادغام

در این مقاله ، ایده این است که همه جنبه هایی را که شامل این است که یکی از اصلی ترین ادغام ها در دنیای بدون سرور است ، کشف کنیم: یک لامبدا پیام هایی از سرویس SQS مصرف می کند. اگرچه برای ایجاد ساده است ، این ادغام جنبه های مهمی دارد (برخی از ناشناخته ها برای توسعه دهندگان) که به طور مستقیم بر قابلیت اطمینان راه حل آن تأثیر می گذارد.

مفاهیم اساسی

آمازون SQS (سرویس صف ساده) (AWS Lambda) یک مدل پردازش مبتنی بر رای گیری را از طریق مکانیسم به نام نقشه برداری منبع رویداد برای ایجاد یک جریان پردازش پیاده سازی می کند. نقشه برداری منبع رویداد وظیفه برقراری تماس در API SQS را بر عهده دارد ، و نتایج را به تعداد زیادی و احضار گروه بندی می کند همگام لامبدا همانطور که در تصویر زیر مشاهده می کنیم:

مکانیسم پردازش

لامبدا جریان پردازش زیر را پیاده سازی می کند:

1. نظرسنجی پیام ها
   همانطور که دیدیم ، لامبدا مشاوره های دوره ای را به خط SQS برگزار می کند و پیام ها در تعداد زیادی بازیابی می شوند. هر قطعه یک دعوت واحد از عملکرد Lambda ایجاد می کند.

2. چرخه دید
   از اینجا جنبه مهمی از ادغام ، چرخه دید پیام آمده است. پیام ها در هنگام پردازش لامبدا در صف قرار می گیرند ، اما به طور پنهان مطابق با مدت زمان دید پیکربندی شده در خط. به عنوان مثال ، هنگامی که ما یک زمان دیدنی 30 ثانیه ای را تعریف می کنیم ، پیام هایی که توسط لامبدا پردازش می شود برای این دوره نامرئی خواهد بود ، بنابراین از سایر مصرف کنندگان جلوگیری می کند که همزمان آنها را پردازش کنند.

3. مدیریت نتیجه گیری
   اگر پردازش موفقیت آمیز باشد ، Lambda به طور خودکار خطوط را از خط خارج می کند. اگر Lambda دارای خرابی پردازش باشد ، پیام ها پس از بازدم های زمان دیدنی به خط باز می گردند.

تنظیمات پردازش زیادی

Lambda Trigger SQS تنظیمات بهینه سازی پردازش خاصی را ارائه می دهد:

• اندازه: به طور پیش فرض ، 10 پیام را در یک اجرای واحد گروه بندی می کند ، اما می تواند تا 10،000 پیام برای صف های استاندارد و 10 برای صف های پنجم افزایش یابد.
• پنجره دسته دسته: به شما امکان می دهد تا قبل از احضار پردازش لامبدا ، تا 5 دقیقه پیام ها را جمع کنید.

هنگامی که یکی از این دو معیار حاصل می شود ، لامبدا اجرا می شود.

ضمانت های پردازش

مکانیسم نقشه برداری منبع رویداد ، پردازش “حداقل یک بار” را تضمین می کند ، به این معنی که یک پیام حداقل یک بار پردازش می شود ، ممکن است پردازش تکراری رخ دهد. برای مدیریت این ویژگی ، برای لامبدا مکانیسم IDEpotence مهم است.

مکانیسم های تصفیه خطا

Lambda به طور خودکار یک مکانیسم تصفیه خطا را اجرا می کند که به تدریج مقیاس پذیری را کاهش می دهد (لامبدهایی که به طور موازی در حال اجرا هستند) در طی مصرف خط SQS ، بنابراین جلوگیری از خطاها در مقیاس بزرگ در کاربرد آنها رخ می دهد.

در موارد پرتاب (هنگامی که لامبدا خطای 429 درخواست های زیادی را برمی گرداند) ، لامبدا سعی می کند دوباره پردازش کند یکسان پیام تا زمان دیدنی در خط منقضی. پس از این دوره ، اگر پردازش موفقیت آمیز نبود ، پیام دور ریخته می شود. 😱😱😱

پاسخ های جزئی جزئی

به طور پیش فرض ، هنگامی که عملکرد Lambda آن هنگام پردازش زیاد خطایی پیدا می کند ، تمام پیام های موجود در آن تعداد زیادی از جمله مواردی که با موفقیت پردازش می شوند ، قابل مشاهده می شوند. این می تواند به دو مشکل منجر شود:

• اگر Lambda شما با IDEPotence رفتار نمی کند ، می توانید داده های تکراری ایجاد کنید.
• حتی اگر لامبدا با idempotence رفتار کند ، پردازش غیر ضروری پیام هایی که قبلاً تحت پیگرد قانونی قرار گرفته اند وجود خواهد داشت.

برای حل این مشکل می توانیم پاسخ های جزئی را اجرا کنیم ، جایی که لامبدا با موفقیت انجام می دهد اما جزئی است. در عمل ، لامبدا پیامهایی را که با موفقیت پردازش شده اند حذف می کند و مواردی که با خطا پردازش شده اند ، در صف بندی مجدد هستند تا دوباره پردازش شوند.

برای اجرای موفقیت جزئی لازم است که به آن تغییر دهید true ارزش ملک Report batch item failures در Trigger SQS Lambda و همچنین با بیان شناسه پیام هایی که با خطا پردازش شده اند ، بازگشت لامبدا را تغییر دهید:

{ 
  "batchItemFailures": [ 
        {
            "itemIdentifier": "id2"
        },
        {
            "itemIdentifier": "id4"
        }
    ]
}

توجه: برای برخی از زبانها ، کتابخانه های AWS وجود دارد که این کلاس بازگشت را برای تسهیل توسعه پیاده سازی می کنند.

نکات مهم در مورد پاسخ های جزئی:

• پیش از این مکانیسم تصفیه خطای Lambda که مانع از بروز خطاها در مقیاس بزرگ در کاربرد آن می شود ، خوب ، خوب ، Report batch item failures فعال شده ، لامبدا دیگر از این مکانیسم استفاده نمی کند زیرا اعدام ها همیشه موفق خواهند بود (حتی جزئی).
• اگر Lambda شما یک استثناء نشده را راه اندازی کند ، کل قطعه به عنوان یک شکست کامل در نظر گرفته می شود.
• برای صف های FIFO ، Lambda شما باید پردازش را پس از اولین شکست قطع کند و در پاسخ به تمام پیام هایی که شکست خورده اند یا پردازش نشده اند برای حفظ سفارش پیام ها بازگردند.

درک چگونگی نقشه برداری منبع رویداد ، لامبدها را مقیاس می کند

صف های استاندارد (پیش فرض)

با شروع مصرف یک خط استاندارد SQS ، نمونه نقشه برداری منبع رویداد 5 لامبدا به طور موازی ، هر یک از پیام ها را مصرف می کنند ، اگر صف با پیام های موجود ادامه یابد ، لامبدا همچنان به 300 نمونه جدید در دقیقه صعود می کند. حداکثر تعداد تعداد زیادی که به طور همزمان پردازش می شوند 1000 است.

رده های فیفا

در صف های FIFO ، لامبدا پیامهایی را به ترتیب دریافت آنها پردازش می کند. هنگام ارسال پیام به یک خط FIFO ، شما را مشخص می کنید MessageGroupIdبشر آمازون SQS تضمین می کند که پیام های همان گروه به ترتیب به لامبدا تحویل داده می شوند. هنگامی که نقشه برداری منبع رویداد پیام های توطئه را گروه بندی می کند ، هر قطعه می تواند حاوی پیام های گروه های مختلف باشد ، اما همیشه ترتیب پیام های یکسان را نگه می دارد MessageGroupIdبشر اگر عملکرد شما خطایی را برمی گرداند ، تمام تلاش برای پردازش پیام های آسیب دیده قبل از دریافت Lambda پیام های اضافی از همان گروه انجام می شود ، بنابراین خطاها در صف های FIFO ممکن است به طور قابل توجهی مقیاس لامبدا را به خطر بیاندازد.

حداکثر پیکربندی رقابت

دو دلیل وجود دارد که می تواند شما را در نظر بگیرید که چه میزان لامبدا می تواند هنگام مصرف یک خط SQS صعود کند:

1. محدودیت نمونه های لامبدا را که به طور موازی در منطقه اجرا می شوند ، اگزوز کنید و ممکن است بر سایر لامبدهایی که در حساب AWS شما نیز اجرا می شوند ، تأثیر بگذارد. این امر به این دلیل است که به طور پیش فرض یک حساب AWS محدودیت 1000 نمونه Lambda را به طور همزمان توسط منطقه اجرا می کند (این حد برای همه لامبدا های منطقه اعمال می شود ، نه برای هر).

2. Lambda آن ممکن است برخی از API ، بانک یا هر سرویس دیگری را درخواست کند که ممکن است از قله های استفاده بالا پشتیبانی نکند.

برای این کار Lambda Trigger SQS دارای خاصیت است Maximum concurrency جایی که می توانید سقف مقیاس لامبدا را محدود کنید.

برخی از نکات مهم در مورد این پیکربندی:

• Maximum concurrency اشمیه Reserve concurrency اینها پیکربندی های مشخصی هستند.
• Maximum concurrency نباید بالاتر از Reserve concurrency و بره روشن
• اگر Lambda چندین محرک SQS داشته باشد ، پیکربندی Reserve concurrency باید بیشتر یا برابر با جمع باشد Maximum concurrency از همه محرک ها.
• اگر هیچ یک از این نکات فوق رعایت نشود ، اجرای لامبدا ممکن است منجر به پرتاب شود.

در صف های FIFO ، اعدام های همزمان با کمترین ارزش بین:

• تعداد شناسه های گروه پیام رسانی (messageGroupId).
• حداکثر پیکربندی رقابت (Maximum concurrency).

به عنوان مثال ، با شش شناسه گروه پیام رسانی و حداکثر رقابت برای 10 پیکربندی شده ، عملکرد آن حداکثر شش اعدام همزمان خواهد داشت.

ملاحظات نهایی

درک جنبه های این ادغام برای اجرای یک لامبدا قوی ، اطمینان از پردازش قابل اعتماد پیام ها و یک خواب آرام در شب های شما بسیار مهم است.

اگر شروع به استفاده از سرویس Amazon SQS کرده اید ، توصیه می کنم این مقاله را در مورد رایج ترین خطاها هنگام استفاده از SQS بخوانید.

کلیه نکات تحت پوشش این مقاله در مستندات رسمی AWS موجود است که می توانید در لینک های مرجع زیر پیدا کنید.

منابع

با استفاده از لامبدا با آمازون SQS
پیکربندی رفتار مقیاس گذاری برای نقشه های منبع SQS
رسیدگی به خطاهای یک منبع رویداد SQS در لامبدا