ترافیک سرور ابری: شمارش، سقف و IP اضافه

ترافیک سرور ابری چطور محاسبه می‌شود، سقف پهنای باند کجاست و بعد از عبور از آن چه اتفاقی می‌افتد؟ تعریف دقیق ورودی، خروجی و IP اضافه.

۷ دقیقه به‌روزرسانی ۱۷ آبان ۱۴۰۵

صورتحساب ماهانه آمده و عدد ترافیک دو برابر ماه قبل است، ولی شما هیچ سرویس جدیدی راه نینداخته‌اید. یا بدتر: سایت روی سرور ابری ناگهان کند شده و در پنل، ترافیک خروجی روی سقف نشسته است. این دو حالت تقریباً همیشه یک ریشه دارند: کسی دقیقاً نمی‌داند «ترافیک سرور ابری» از کجا شمرده می‌شود و کدام بایت‌ها به حساب می‌آیند.

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

ترافیک ورودی و خروجی؛ کدام یکی شمرده می‌شود

قاعده‌ای که تقریباً همه‌جا ثابت است: ترافیک ورودی (ingress) رایگان است و ترافیک خروجی (egress) شمرده می‌شود. یعنی هر بایتی که از اینترنت به سمت سرور شما می‌آید، از دید مالی بی‌ارزش است؛ هر بایتی که از سرور شما به سمت اینترنت می‌رود، هزینه دارد.

این تعریف ساده است، اما دو استثنا دارد که بیشترین سردرگمی را می‌سازد:

  • ترافیک بین سرورهای همان شبکه خصوصی معمولاً شمرده نمی‌شود. اگر دیتابیس و وب‌سرور روی یک شبکه خصوصی حرف بزنند، آن گیگابایت‌ها از حساب شما کم نمی‌شود. اگر همین ارتباط از IP عمومی رد شود، کامل شمرده می‌شود. تفاوت این دو در عمل می‌تواند ماهی چند صد گیگابایت باشد.
  • ترافیک بین دیتاسنترها یا بین منطقه‌ها (regions) تقریباً همیشه شمرده می‌شود، حتی اگر هر دو سرور مال شما باشند.

پس اولین کاری که باید بکنید این است که بفهمید کدام مسیر در معماری شما از IP عمومی رد می‌شود. یک traceroute ساده این را لو می‌دهد:

traceroute -n db.internal.example.com
# اگر hop اول 10.x.x.x بود، مسیر خصوصی است
# اگر از IP عمومی رد شد، همان ترافیک شمرده می‌شود

ترافیک سرور ابری چطور اندازه‌گیری می‌شود

عدد ترافیکی که در پنل می‌بینید، از شمارنده‌های کارت شبکه روی هایپروایزر می‌آید، نه از لاگ اپلیکیشن شما. این یعنی چند چیز را هرگز نمی‌بینید: ترافیک loopback، ترافیک داخل همان ماشین، و بسته‌هایی که قبل از رسیدن به کارت شبکه drop شده‌اند.

نکته مهم‌تر این است که شمارش در لایه ۳ انجام می‌شود، نه لایه ۷. اگر یک درخواست HTTP با هدرهای ۸۰۰ بایتی و بدنه ۲۰۰ بایتی بفرستید، عدد شمرده‌شده حدود ۱۰۰۰ بایت است، نه ۲۰۰ بایت. برای APIهایی که پاسخ‌های کوچک با هدرهای بزرگ می‌دهند، این اختلاف تا سه برابر هم می‌رسد.

برای دیدن عدد واقعی از داخل خود سرور، vnstat دقیق‌ترین گزینه‌ای است که بدون agent اضافه کار می‌کند:

vnstat -m          # مصرف ماهانه به تفکیک اینترفیس
vnstat -i eth0 -h  # گزارش ساعتی ۲۴ ساعت گذشته
cat /proc/net/dev  # شمارنده خام کرنل، ریست نمی‌شود

اگر عدد vnstat با عدد پنل اختلاف زیاد داشت، احتمالاً ترافیک از اینترفیس دیگری رد می‌شود یا بخشی از ترافیک قبل از رسیدن به ماشین شما در لایه شبکه فیلتر شده است. برای دیدن تصویر کامل، ترکیب این شمارنده‌ها با مانیتورینگ ابری و هشدارهای خودکار لازم است؛ بدون هشدار، اولین باری که متوجه رشد ترافیک می‌شوید روز صورتحساب است.

بعد از عبور از سقف چه اتفاقی می‌افتد

اینجا جایی است که رفتار ارائه‌دهنده‌ها واقعاً فرق می‌کند و باید قبل از انتخاب بدانید کدام مدل را می‌خرید. سه مدل رایج وجود دارد:

مدلرفتار پس از عبور از سقفعلامتی که می‌بینید
سخت‌گیرانهپهنای باند تا ابتدای ماه بعد به چند مگابیت محدود می‌شودسایت باز می‌شود ولی TTFB از ۲۰۰ms به ۳ ثانیه می‌رود
پرداخت به‌ازای مصرفسرویس عادی کار می‌کند، مبلغ اضافه در فاکتور می‌آیدهیچ کندی‌ای حس نمی‌کنید، فقط صورتحساب سنگین می‌شود
ترکیبیتا سقف اول رایگان، بعد از آن نرخ کاهشیهزینه رشد می‌کند ولی نه خطی

مدل اول خطرناک‌تر از چیزی است که به نظر می‌رسد، چون throttle معمولاً روی کل اینترفیس اعمال می‌شود، نه فقط روی ترافیک وب. یعنی SSH شما هم کند می‌شود و اگر بکاپ شبانه از همان اینترفیس رد شود، ممکن است نیمه‌کاره بماند. اگر روی سروری کار می‌کنید که ترافیکش غیرقابل پیش‌بینی است، مدل پرداخت به‌ازای مصرف را انتخاب کنید؛ گران‌تر به نظر می‌رسد ولی قطعی سرویس را نمی‌خرید.

یک عدد واقعی که به کارتان می‌آید: یک سرور وب معمولی با ۵۰ هزار بازدید ماهانه و صفحات ۱.۵ مگابایتی، حدود ۷۵ گیگابایت خروجی تولید می‌کند. اگر همان سایت تصاویر را بدون فشرده‌سازی سرو کند، همین عدد به ۳۰۰ گیگابایت می‌رسد. تفاوت، فقط یک تنظیم است.

IP اضافه؛ کِی واقعاً لازم است

هر سرور ابری با یک IP عمومی می‌آید. IP اضافه در سه سناریو معنا دارد و در بقیه موارد فقط هزینه و پیچیدگی است:

  1. جدا کردن سرویس‌ها روی پورت ۴۴۳. اگر دو سایت با دو گواهی SSL جدا دارید و نمی‌خواهید SNI را درگیر کنید، IP دوم راه‌حل قدیمی و مطمئنی است. البته امروز SNI روی همه مرورگرهای واقعی کار می‌کند و این دلیل کم‌رنگ شده است.
  2. خروجی ثابت برای سرویس‌های بیرونی. اگر API بانکی یا درگاه پرداخت شما IP مبدأ را whitelist می‌کند، IP خروجی ثابت اجباری است. این تنها موردی است که واقعاً چاره‌ای جز IP اضافه ندارید.
  3. جدا کردن ترافیک مدیریت از ترافیک سرویس. SSH و پنل روی یک IP، ترافیک کاربران روی IP دیگر. این کار هم امنیت را بهتر می‌کند و هم تحلیل ترافیک را ساده‌تر.

نکته‌ای که کم دیده می‌شود: IP اضافه روی همان اینترفیس bind می‌شود، پس سقف پهنای باند را بالا نمی‌برد. اگر مشکل شما کمبود پهنای باند است، IP دوم هیچ کمکی نمی‌کند. برای آن باید به سراغ معماری توزیع‌شده بروید.

این‌جا اشتباه می‌کنند

رایج‌ترین اشتباهی که در تیکت‌ها می‌بینم این است: کسی برای کاهش مصرف ترافیک، CDN را روی دامنه اصلی فعال می‌کند ولی رکورد DNS را از A به CNAME تغییر نمی‌دهد. نتیجه این است که CDN هیچ ترافیکی نمی‌گیرد، همه درخواست‌ها مستقیم به سرور می‌آید، و مصرف دقیقاً همان قبلی می‌ماند. علامتش هم این است که در پنل CDN عدد hit ratio نزدیک صفر است ولی ترافیک سرور تغییری نکرده.

اشتباه دوم، و گران‌تر: کسی ترافیک را از روی لاگ Nginx می‌شمارد و به عدد پنل اعتماد نمی‌کند. لاگ Nginx فقط بدنه پاسخ را می‌شمارد و هدرها، handshake مربوط به TLS و بسته‌های retransmit را نمی‌بیند. اختلاف ۱۵ تا ۲۵ درصد بین این دو عدد طبیعی است، نه نشانه اشتباه در محاسبه.

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

کاهش مصرف بدون دست زدن به معماری

قبل از هر تغییر بزرگی، این سه کار را انجام دهید. اول، فشرده‌سازی را روی Nginx روشن کنید؛ برای متن و JSON معمولاً ۷۰ درصد کاهش می‌دهد:

gzip on;
gzip_types application/json text/css application/javascript;
gzip_min_length 1024;

دوم، تصاویر را به WebP تبدیل کنید. سوم، کش مرورگر را برای فایل‌های استاتیک روی بازه طولانی بگذارید تا هر بازدیدکننده دوباره آن‌ها را نگیرد. همین سه مورد در عمل بین ۴۰ تا ۶۰ درصد ترافیک خروجی را کم می‌کند و هیچ تغییری در کد اپلیکیشن لازم ندارد.

اگر بعد از این‌ها هنوز مصرف بالاست، مشکل معماری است نه تنظیمات. در آن حالت سراغ شبکه توزیع محتوا بروید تا فایل‌های استاتیک از لبه سرو شوند، و برای فایل‌های حجیم مثل ویدیو یا بکاپ، فضای ذخیره‌سازی آبجکت انتخاب درست‌تری از دیسک سرور است؛ چون ترافیک خروجی آن جدا حساب می‌شود و می‌توانید دقیقاً ببینید کدام فایل چقدر می‌خورد.

اگر روی زیرساخت ابری سرورنت کار می‌کنید، شمارنده‌های ترافیک در همان پنل و به تفکیک اینترفیس دیده می‌شوند و می‌توانید قبل از هر تغییری، یک هفته baseline بگیرید. عدد پایه را داشته باشید؛ بدون آن، هر بهینه‌سازی‌ای حدس است.

پرسش‌های پرتکرار

ترافیک ورودی سرور ابری هم حساب می‌شود؟

در تقریباً همه ارائه‌دهنده‌های ابری، ترافیک ورودی رایگان است و فقط خروجی شمرده می‌شود. استثنا جایی است که ترافیک بین منطقه‌ها یا بین دیتاسنترها رد شود؛ آن هم معمولاً در هر دو جهت حساب می‌شود.

چرا عدد ترافیک پنل با vnstat فرق دارد؟

چون پنل از شمارنده هایپروایزر می‌خواند و vnstat از کرنل خود ماشین. اختلاف ۵ تا ۱۵ درصد طبیعی است و معمولاً از بسته‌های مدیریتی، ARP و ترافیک قبل از رسیدن به اینترفیس شما می‌آید. اختلاف بیشتر از ۳۰ درصد یعنی یک اینترفیس یا یک مسیر را ندیده‌اید.

بعد از تمام شدن سقف پهنای باند چه اتفاقی می‌افتد؟

بستگی به مدل صورتحساب دارد. در مدل سخت‌گیرانه پهنای باند محدود می‌شود و همه سرویس‌ها از جمله SSH کند می‌شوند. در مدل پرداخت به‌ازای مصرف، سرویس عادی می‌ماند و هزینه در فاکتور اضافه می‌شود. قبل از خرید باید بدانید کدام مدل را می‌خرید.

IP اضافه روی سقف پهنای باند اثر دارد؟

نه. IP اضافه فقط یک آدرس روی همان اینترفیس است و سقف پهنای باند را تغییر نمی‌دهد. کاربرد واقعی‌اش جداسازی سرویس‌ها، خروجی ثابت برای whitelist و جدا کردن ترافیک مدیریت از ترافیک کاربران است.

آیا این مطلب برایتان مفید بود؟