تگگذاری سمت سرور: تصمیمها و هزینهها
تصمیم دربارهٔ تگگذاری سمت سرور: کدام شکل پیادهسازی، کدام اقلام هزینه، و کِی نساختن آن انتخاب بهتری است. بدون رقم قیمت.
نوشته Roozbeh Nazari · CEO
در دو سال گذشته تگگذاری سمت سرور برای تیمهای فعال در ترکیه از پرسش «آیا بسازیم» به پرسش «چرا هنوز نساختهایم» جابهجا شده است. این جابهجایی تصمیم را آسانتر نکرده است. ساختن آن یک ترجیح نرمافزاری نیست بلکه یک تعهد عملیاتی است: سروری که دائم روشن است، کسی که مراقبش باشد، و وابستگیای که وقتی خراب شود سنجش شما را متوقف میکند. این نوشته اقلامی را برمیشمارد که هنگام گرفتن این تصمیم باید به آنها نگاه کرد.
چارچوب سنجش را در صفحهٔ خدمت تحلیل داده و استراتژی توضیح دادهایم. نحوهٔ برپایی گزارشگیری در سایتهای چندزبانه را در نوشتهٔ ما دربارهٔ تحلیل قیف بر پایهٔ نسخهٔ زبانی در GA4 آوردهایم؛ تگگذاری سمت سرور همتای همان گزارشگیری در لایهٔ جمعآوری داده است.
ابتدا یک هشدار: این نوشته هیچ رقم قیمتی نمیدهد. قیمتگذاری ارائهدهندگان ابری بر پایهٔ منطقه، الگوی مصرف و گذر زمان تغییر میکند؛ رقمی که امروز نوشته شود شش ماه دیگر نادرست است. در عوض اقلامی را برمیشمارد که هزینه را میسازند و روشی را که با آن میتوانید هر قلم را با ترافیک خودتان محاسبه کنید. رقم را خودتان تولید میکنید، از صفحهٔ قیمت روزآمد ارائهدهندهتان ضربدر حجم ترافیک خودتان.
تگگذاری سمت سرور دقیقاً چه چیزی را تغییر میدهد
در ترتیب کلاسیک، درخواستها از مرورگر مستقیم به پلتفرمهای سنجش میروند. در ترتیب سمت سرور، مرورگر یک درخواست به یک نشانی واحد میفرستد؛ سروری که در آن نشانی است درخواست را دریافت و پردازش میکند و خودش آن را میان پلتفرمهای مربوطه توزیع میکند. آنچه تغییر میکند مقصد داده نیست، بلکه فرستندهٔ آن است.
این جابهجایی سه پیامد دارد. نخست، شمار اسکریپتهایی که در مرورگر اجرا میشوند کم و وزن صفحه سبکتر میشود. دوم، اینکه کدام داده به کدام پلتفرم برود در یک نقطه قابل کنترل میشود. سوم، و در عمل تعیینکنندهترین، طول عمر کوکی و کیفیت داده کمتر به محدودیتهای مرورگر وابسته میشود.
هیچیک از این سه دستاورد خودکار نیست. اگر اشتباه ساخته شود، وزن صفحه کم نمیشود، کنترل یکپارچه نمیگردد و کیفیت داده افت میکند. تگگذاری سمت سرور یک انتخاب معماری سنجش است؛ به این دلیل کار میکند که درست ساخته شده باشد، نه به این دلیل که ساخته شده باشد.
شکل پیادهسازی: سه مسیر، سه وابستگی متفاوت
برای برپا کردن سرور تگگذاری بیش از یک راه وجود دارد و انتخاب باید بر پایهٔ ظرفیت عملیاتی تیم انجام شود.
- تأمین خودکار از طریق یک سرویس ابری مدیریتشده. سریعترین مسیر؛ مقیاسپذیری و مدیریت وصلهها تا حد زیادی بر عهدهٔ ارائهدهنده است. در مقابل، وابستگی به ارائهدهنده و یک خط هزینهٔ مبتنی بر مصرف را میپذیرید.
- نصب دستی روی زیرساخت خودتان. از یک ایمیج داکر نصب میشود و کنترل کامل میدهد. مقیاسپذیری، پایش و بهروزرسانی به شما منتقل میشود.
- اصلاً نساختن آن. این یک گزینهٔ واقعی است و در سایتهای کمترافیک و تکبازاری اغلب گزینهٔ درست است. سروری که اجرایش نمیکنید هزینهٔ عملیاتی صفر دارد.
یک محدودیت فنی که در نصب دستی باید مراقبش بود: توصیه میشود سرورهای تأمینشده حداکثر یک پردازندهٔ مجازی داشته باشند. پردازندههای مجازی اضافی استفاده نمیشوند و بر مقیاسپذیری خودکار اثر منفی میگذارند. پس رویکرد «یک ماشین قویتر» اینجا کمکی نمیکند؛ بهپهنا مقیاس میگیرید، نه بهارتفاع. برای دسترسپذیری و کارایی، خوشهبندی توصیه میشود.
اقلامی که هزینه را میسازند
فروکاستن کل هزینه به یک هزینهٔ سرور رایجترین اشتباه در این تصمیم است. در واقعیت دستکم پنج قلم وجود دارد و سه تای آنها روی صورتحساب ظاهر نمیشوند:
- هزینهٔ نمونههایی که پیوسته در حال اجرا هستند. سرور تگگذاری باید حتی وقتی ترافیکی نیست بالا بماند؛ ترتیبی که با نخستین درخواست از حالت سرد بالا بیاید داده از دست میدهد.
- نمونههای اضافی که با ترافیک مقیاس میگیرند. در دورههای کمپین این قلم میتواند چند برابر خط پایه باشد؛ آن را بر پایهٔ شلوغترین ماهتان محاسبه کنید، نه میانگین سالانه.
- خروج ترافیک از شبکه. ترافیکی که از سرور به سمت پلتفرمها خارج میشود هزینه دارد و در پیکربندیهای چندپلتفرمی یک رویداد واحد به بیش از یک خروج تبدیل میشود.
- مدیریت دامنه و گواهی. سرور تگگذاری باید زیر همان دامنهٔ سایت شما اجرا شود و همین یک قلم نگهداری پیوسته در سمت DNS و گواهی میسازد.
- زمان مهندسی. بزرگترین و نادیدهگرفتهشدهترین قلم. نصب یکبار است؛ پایش و پاسخ به رخداد پیوستهاند.
روش عملی برای پر کردن این اقلام آن است که شمار واقعی رویدادهای یک ماه را بردارید و هر قلم را در آن ضرب کنید. شمار رویداد را میتوانید از گزارشهای موجود GA4 خودتان بخوانید؛ نیازی به تخمین نیست. هر محاسبهٔ هزینهای که بدون دانستن شمار ماهانهٔ رویداد انجام شود، در واقع جا دادن سناریوی نمونهٔ ارائهدهنده روی سایت خودتان است و معمولاً پایینتر از رقم واقعی درمیآید.
قلم آخر همان است که تصمیم را تعیین میکند. اگر هیچ ترتیب هشداردهیای برای متوجه شدن توقف سنجش وجود نداشته باشد و کسی نباشد که پاسخ دهد، تگگذاری سمت سرور سنجش را بهتر نمیکند؛ یک نقطهٔ تازه اضافه میکند که سنجش میتواند در آن بیسروصدا متوقف شود.
کِی نساختن انتخاب درست است
مواردی که نساختن در آنها درست است مشخصاند. در سایتی تکزبانه، تکبازاری و کمحجم، دستاورد ارزش بار عملیاتی را ندارد. اگر ترتیب سنجش از پیش ناسازگار باشد، تغییر لایهٔ جمعآوری داده کاری جز منتقل کردن همان ناسازگاری نمیکند؛ اول شمای رویداد را درست کنید. اگر کسی نباشد که نگهداری فنی را بر عهده بگیرد، پیکربندی پس از مدتی بدون نگهداری میماند، و سرور تگگذاری بدون نگهداری پرخطرتر از نداشتن آن است.
موردی که ساختن در آن آشکارا درست است، پیکربندی چندبازاری و پرحجمی است که سرمایهگذاری تبلیغاتی معناداری دارد. آنجا بهبود کیفیت داده مستقیم به تصمیمهای بودجه خوراک میدهد و هزینهٔ عملیاتی در کنار بودجهٔ تبلیغاتی که صرف اتریبیوشن معیوب میشود ناچیز است.
ترتیب تصمیم چنین است: اول شمای سنجش را درست کنید، سپس حجم و شمار بازارهایتان را بنویسید، بعد پنج قلم هزینه را با اعداد خودتان پر کنید و در پایان نام کسی را که نگهداری را بر عهده میگیرد مشخص کنید. تصمیم «بسازیم» که پیش از نوشته شدن این چهار مورد گرفته شود، تصمیم فنی نیست بلکه یک آرزوست.
پس از نصب: جلوگیری از توقف خاموش سنجش
خطرناکترین حالت خرابی در ترتیب سمت سرور، از کار افتادن کامل سرور نیست؛ سروری که سقوط کند فوراً دیده میشود. ریسک واقعی خرابی جزئی است: سرور بالاست، به درخواستها پاسخ میدهد، اما توزیع به یکی از پلتفرمها خطا میدهد. آنچه در گزارشها ظاهر میشود پیام خطا نیست، فقط دادهٔ کمتر است. تیمها معمولاً هفتهها بعد و وقتی نتیجهٔ یک کمپین پایینتر از انتظار درمیآید متوجه میشوند.
پس سه بررسی هست که باید بخشی از نصب به شمار آید. نخست، پایش نقطهٔ پایانی سلامت سرور از بیرون و هشدار دادن وقتی پاسخ نمیدهد. دوم، ردیابی شمار روزانهٔ رویداد به تفکیک پلتفرم؛ اگر شمار یک پلتفرم افت کند در حالی که بقیه ثابت ماندهاند، مشکل در توزیع است نه روی سایت. سوم، بهروزرسانی منظم ایمیج سرور — نسخهای که در حال اجراست به مرور عقب میافتد و راهاندازی مجدد دورهای توصیه میشود.
برقرار کردن این سه بررسی کمتر از خود نصب وقت میبرد و تصمیم دربارهٔ تگگذاری سمت سرور را به تصمیمی برگشتپذیر تبدیل میکند. در مقابل، ترتیبی که پایش نشود میتواند اعتمادی را که به سنجش شده است با یک خرابی خاموش خرج کند؛ و زمان لازم برای بازپسگیری آن اعتماد بسیار بیشتر از زمانی است که در نصب صرفهجویی شده.