Peak Traffic در زیرساخت پیامکی؛ گلوگاه‌ها را چگونه پیدا کنیم؟
وقتی پیامک‌ها در ترافیک اوج دیر می‌رسند، نخست محل تشکیل تأخیر را پیدا کنید: زمان ورود درخواست، انتظار در صف، پردازش و مسیریابی، پذیرش درگاه و دریافت گزارش تحویل را جداگانه ثبت کنید. بالا رفتن نرخ درخواست به‌تنهایی ثابت نمی‌کند سرور کم‌ظرفیت است؛ محدودیت مسیر ارسال یا انباشته شدن صف هم می‌تواند همان نشانه را بسازد.
این راهنما برای CTO، مدیر زیرساخت و تیم عملیات ارائه‌دهندهٔ خدمات پیامکی نوشته شده است. هدف، پیدا کردن گلوگاه در یک رخداد واقعی و تصمیم‌گیری دربارهٔ ظرفیت است. اگر با معماری چند سامانه و چند مسیر روبه‌رو هستید، صفحهٔ SMS Gateway سازمانی تلیرکو اجزای لایهٔ API، صف، مسیریابی و پایش را نشان می‌دهد.
«تأخیر پیامک» را دقیقاً از کجا تا کجا بسنجیم؟
در یک رخداد فرضی، حجم درخواست‌های ارسال در یک بازهٔ کوتاه چند برابر می‌شود. API همچنان پاسخ موفق می‌دهد، اما کاربران از دیر رسیدن کد یک‌بارمصرف شکایت دارند. پاسخ موفق API ممکن است فقط به معنی پذیرش درخواست باشد؛ همان پیام بعداً در صف بماند، به مسیر بالادستی ارسال شود و سپس وضعیت تحویل بگیرد. در راهنمای وضعیت پیام Twilio نیز حالت‌های queued، sent و delivered مراحل جداگانه‌اند؛ این مثال برای تفکیک مفهومی است و نام‌گذاری دقیق وضعیت‌ها در هر زیرساخت باید از مستندات همان سرویس بررسی شود.
برای هر پیام، یک شناسهٔ پیگیری و زمان‌های ورود، پذیرش، خروج از صف، تحویل به مسیر و دریافت DLR ثبت کنید. سپس تأخیر هر مرحله و کل مسیر را به تفکیک نوع پیام، مشتری، اپراتور، مسیر و بازهٔ زمانی گزارش دهید. شاخص‌هایی مانند میانه و صدک ۹۵ از میانگین تنها مفیدترند، چون مشکل ممکن است فقط بخشی از پیام‌ها را درگیر کند. ساعت سامانه‌ها نیز باید همگام باشد؛ وگرنه اختلاف زمانِ ساختگی مسیر را گمراه‌کننده نشان می‌دهد.
پنج نقطه‌ای که در Peak Traffic می‌توانند پیام را کند کنند
در هر مرحله، نشانهٔ قابل مشاهده را به پرسش عملی تبدیل کنید. تصویر زیر محل‌های بررسی را خلاصه می‌کند؛ توضیح متنی آن نیز در جدول آمده است.
| نقطه | نشانه‌ای که باید ببینید | پرسش تشخیصی |
|---|---|---|
| ۱. ورودی API و کنترل نرخ | افزایش زمان پاسخ، timeout یا خطاهای محدودیت نرخ | آیا درخواست اصلاً پذیرفته شده، یا پیش از ورود به صف رد/کند شده است؟ |
| ۲. صف و پردازش‌گرها | رشد عمق صف و عمر قدیمی‌ترین پیام، بدون افزایش متناسب نرخ خروج | آیا سرعت ورود از ظرفیت پردازش پایدار بیشتر شده است؟ |
| ۳. مسیریابی و تلاش دوباره | افزایش زمان انتخاب مسیر، خطا یا retry برای بعضی مسیرها | آیا قواعد مسیر و رفتار هنگام خطا تأخیر را تشدید می‌کنند؟ |
| ۴. درگاه ارائه‌دهنده و اپراتور | افزایش زمان پذیرش بالادستی یا صفِ محدود به یک مسیر | آیا نرخ خروجی از ظرفیت یا محدودیت قراردادی مسیر عبور کرده است؟ |
| ۵. وضعیت تحویل | فاصلهٔ زیاد میان sent و delivered یا تأخیر DLR | آیا تأخیر پس از واگذاری پیام رخ می‌دهد یا گزارش وضعیت دیر می‌رسد؟ |
پایش صف باید فقط به «تعداد پیام» محدود نماند. مستندات Amazon SQS، عمر قدیمی‌ترین پیامِ پردازش‌نشده را شاخصی مستقل برای دیدن عقب‌ماندگی معرفی می‌کند. از این اصل می‌توان در هر سامانهٔ صف‌محور استفاده کرد، اما تعریف دقیق شاخص و رفتار پیام‌های خطادار به فناوری صف شما وابسته است.
۱. آیا API زیر بار ورودی متوقف می‌شود؟
زمان پاسخ API، نسبت درخواست‌های موفق و ناموفق، timeout، اشباع اتصال و خطاهای کنترل نرخ را کنار نرخ ورود قرار دهید. اگر تأخیر پیش از ثبت پیام شروع می‌شود، افزایش تعداد workerهای صف اثری بر آن ندارد. محدودیت نرخ را هم با خطای زیرساخت یکی نگیرید: کنترل نرخ می‌تواند آگاهانه از ورود باری بیشتر از ظرفیت پایدار جلوگیری کند.
۲. آیا صف زودتر از پردازش‌گرها رشد می‌کند؟
نرخ ورود و خروج را در بازه‌های کوتاه مقایسه کنید. وقتی نرخ ورود برای مدتی از نرخ سرویس‌دهی بیشتر بماند، backlog رشد می‌کند و پیام تازه پشت پیام‌های قبلی منتظر می‌ماند. عمق صف، عمر قدیمی‌ترین پیام، زمان پردازش worker و تعداد پیام‌های درحال‌پردازش را هم‌زمان ببینید. صف خالی همراه با تأخیر زیاد، نشانهٔ جست‌وجو در مرحله‌ای دیگر است.
۳. آیا مسیریابی و retry زمان را می‌بلعند؟
مدت انتخاب مسیر، نرخ خطا به تفکیک مسیر، تعداد تلاش برای هر پیام و زمان انتظار پیش از retry را ثبت کنید. تلاش دوبارهٔ هم‌زمان در چند لایه می‌تواند هنگام اختلال بار بیشتری تولید کند. راهنمای AWS برای خطاهای گذرا، محدودکردن دفعات retry و استفاده از backoff همراه با jitter را توصیه می‌کند؛ برای پیامک، سیاست retry باید با مهلت اعتبار پیام و جلوگیری از ارسال تکراری هماهنگ شود.
۴. آیا محدودیت در مسیر ارائه‌دهنده یا اپراتور است؟
نرخ پذیرش، خطای ظرفیت و زمان پاسخ را برای هر اتصال و اپراتور جدا کنید. اگر فقط یک مسیر کند شده، اضافه کردن سرور داخلی الزاماً نرخ پذیرش آن مسیر را بالا نمی‌برد. ظرفیت مجاز، نوع فرستنده، توافق عملیاتی و امکان مسیر جایگزین را با ارائه‌دهنده بررسی کنید. تجربهٔ عمومی Twilio نیز نشان می‌دهد صف شدن پیام‌ها پشت محدودیت نرخ فرستنده یا حساب، به تأخیر منجر می‌شود؛ این اعداد و محدودیت‌ها را نباید به مسیرهای تلیرکو یا بازار ایران تعمیم داد.
۵. آیا «ارسال‌شده» را با «تحویل‌شده» اشتباه گرفته‌ایم؟
پذیرش پیام توسط مسیر بالادستی پایان تجربهٔ کاربر نیست. اختلاف زمان sent تا delivered و سهم پیام‌های بدون گزارش وضعیت را جدا گزارش کنید. وضعیت تحویل ممکن است به بازخورد اپراتور و قابلیت گزارش‌دهی مسیر وابسته باشد. اگر بخش عمدهٔ تأخیر پس از خروج از زیرساخت شما رخ می‌دهد، داشبورد داخلی باید این مرز را روشن کند، نه اینکه همهٔ تأخیر را به صف داخلی نسبت دهد.
چک‌لیست تشخیص گلوگاه، پیش از خرید یا افزایش ظرفیت
- بازهٔ رخداد را مشخص کنید: زمان آغاز، پایان و نوع پیام‌های آسیب‌دیده را ثبت کنید؛ OTP را با ارسال انبوه در یک نمودار ادغام نکنید.
- یک مسیر نمونه را بازسازی کنید: برای چند پیام با شناسهٔ پیگیری، زمان هر مرحله و وضعیت نهایی را کنار هم بگذارید.
- نرخ‌ها را مقایسه کنید: درخواست ورودی، پیام پذیرفته‌شده، خروج از صف و پذیرش مسیر را در بازه‌های یکسان ببینید.
- صف را از دو زاویه بسنجید: عمق صف و عمر قدیمی‌ترین پیام؛ افزایش یکی بدون دیگری ممکن است علت متفاوتی داشته باشد.
- تفکیک مسیر انجام دهید: نمودار را بر اساس مشتری، نوع پیام، خط/فرستنده، اپراتور و مسیر خروجی بشکنید.
- retry و خطا را بررسی کنید: جهش تلاش‌های دوباره، timeout و خطاهای محدودیت نرخ را هم‌زمان با رشد تأخیر ببینید.
- مرز تحویل را روشن کنید: زمان واگذاری به مسیر و زمان گزارش تحویل را جدا بگذارید.
- تنها سپس ظرفیت را تغییر دهید: تغییر را با آزمون کنترل‌شده و شاخصِ قبل و بعد ارزیابی کنید.
بعد از تشخیص، چه تغییری واقعاً کمک می‌کند؟
راهکار را به همان مرحلهٔ کند وصل کنید. برای ورودی ناپایدار، کنترل نرخ و backpressure می‌تواند بار را قابل‌مدیریت کند. برای صف داخلی، افزایش پردازش‌گر فقط وقتی مؤثر است که وابستگی‌های بعدی نیز ظرفیت کافی داشته باشند. برای مسیر بیرونی، مذاکره دربارهٔ ظرفیت، تنظیم نرخ خروج، بازبینی قواعد مسیریابی یا failover سنجیده مهم‌تر از ارتقای CPU است. برای پیام‌های حساس به زمان، جداکردن سیاست و ظرفیت OTP از ارسال انبوه می‌تواند از پشت صف ماندن آن‌ها جلوگیری کند، به شرطی که محدودیت مسیر خروجی نیز در طراحی لحاظ شود.
صف، مسیریابی چندمسیره، کنترل نرخ و پایش لایه‌ای از اجزایی هستند که در معرفی معماری SMS Gateway تلیرکو آمده‌اند. اگر نیاز شما بیشتر مدیریت سرویس پیامکی و کاربران است، SMS Platform تلیرکو را هم مقایسه کنید. انتخاب نهایی باید بر اساس معماری و دادهٔ ترافیک خودتان باشد.
پرسش‌های رایج دربارهٔ ترافیک اوج پیامک
آیا پاسخ موفق API یعنی پیامک به کاربر رسیده است؟
خیر. پاسخ API معمولاً پذیرش درخواست را نشان می‌دهد. وضعیت‌های ارسال و تحویل در مراحل بعدی ثبت می‌شوند و باید جدا بررسی شوند.
اولین شاخص صف که باید ببینیم چیست؟
عمق صف و عمر قدیمی‌ترین پیام را با هم ببینید و نرخ ورود و خروج را کنار آن‌ها بگذارید. یک عدد به‌تنهایی محل مشکل را مشخص نمی‌کند.
آیا سرور قوی‌تر مشکل Peak Traffic را حل می‌کند؟
فقط اگر گلوگاه واقعاً در منابع و پردازش داخلی باشد. محدودیت نرخ اپراتور، خطای مسیر، retry نامناسب یا تأخیر گزارش تحویل با ارتقای سرور داخلی برطرف نمی‌شود.
برای پیام OTP و پیام انبوه یک صف کافی است؟
به نیاز زمانی و معماری بستگی دارد. اگر ترافیک انبوه، پیام حساس به زمان را پشت صف نگه می‌دارد، جداسازی اولویت یا ظرفیت را بررسی کنید؛ سیاست خروجی و محدودیت اپراتور همچنان باید رعایت شود.
گلوگاه معماری پیام‌رسانی خود را پیدا کنید
اگر در ساعات اوج، زمان رسیدن پیام افزایش می‌یابد، مسیر پیام، نمودار ترافیک و وضعیت صف‌ها را با تیم تلیرکو بررسی کنید تا نقطهٔ کندی و اقدام مناسب مشخص شود.
منابع فنی: Twilio، صف و تأخیر پیام‌رسانی؛ Twilio، وضعیت‌های پیام خروجی؛ AWS، شاخص‌های پایش صف؛ AWS، کنترل retry. این منابع اصول عمومی را توضیح می‌دهند؛ رفتار دقیق هر اتصال پیامکی باید در همان زیرساخت سنجیده شود.