مشکل: ترافیک رسانه origin را در هم میکوبد
وقتی عکسهای محصول، ویدئوهای hero، PDF ها و آپلودهای کاربر روی همان سروری قرار دارند که صفحات شما را رندر میکند، هر درخواست تصویر با کار واقعی اپلیکیشن بر سر CPU، ورودی/خروجی دیسک و پهنای باند رقابت میکند. یک صفحه پرطرفدار واحد با سی تصویر، ترافیک را در برابر یک origin سی برابر میکند، و یک جهش ترافیک یا یک دانلود بزرگ ویدئو میتواند اپلیکیشن را از منابعی که برای پاسخ نیاز دارد محروم کند. ذخیرهسازی روی یک سرور اپلیکیشن مقیاسدهی سختی هم دارد: سرانجام دیسک تمام میشود، و پشتیبانگیری از یک فایلسیستم چاق کند و شکننده میشود. جدا کردن بایتها از منطق نخستین اصلاح ساختاری است، و همان چیزی است که این سناریو تحویل میدهد.
cdn.com.tr چگونه آن را حل میکند: bucket ها بهعلاوه edge cache
هر دارایی را در یک bucket از نوع Object Storage سازگار با S3 ذخیره میکنید، که به شما ظرفیتی عملاً کشسان و یک endpoint میدهد که اپلیکیشنها با ابزار استاندارد S3 با آن صحبت میکنند. جلوی آن bucket، CDN شبکه cdn.com.tr را قرار میدهید، بنابراین تحویل واقعی به مرورگرها از مکانهای edge انجام میشود، نه از bucket و هرگز از سرور اپلیکیشن شما. اولین درخواست برای یک فایل، edge cache را پُر میکند؛ هر درخواست بعدی برای آن فایل از edge ارائه میشود بدون آنکه دوباره به Object Storage دست بزند. نتیجه این است که origin شما تقریباً هیچیک از ترافیک بایت را رسیدگی نمیکند، لایه ذخیرهسازی شما مستقل از محاسبات مقیاس مییابد، و کاربران داراییها را از یک edge node نزدیک میگیرند بهجای یک سرور دور واحد.
access key ها، داراییهای عمومی و فایلهای خصوصی
هر bucket با جفتهای access key و secret که از پنل میسازید، میچرخانید و باطل میکنید کنترل میشود. برای رسانه عمومی مانند تصاویر کاتالوگ از طریق دامنه CDN تحویل میدهید و endpoint خام bucket را از markup خود بیرون نگه میدارید. برای مواد خصوصی مانند دانلودهای پولی یا پشتیبانهای داخلی، اشیا را غیرعمومی نگه میدارید و signed URL های کوتاهعمر تولیدشده با access key را در اختیار میگذارید، تا یک لینک منقضی شود بهجای اینکه برای همیشه زندگی کند. چون هر یکپارچهسازی کلید خودش را میگیرد، یک آپلودر بهخطرافتاده یا یک پیمانکار در حال ترک، یک باطلسازی تککلیکی است نه یک بازنشانی password در سطح کل پلتفرم.
cache-control و purge بدون مسموم کردن cache خودتان
cache تنها بهاندازه هدرهایی که روی اشیای خود تنظیم میکنید خوب است. به داراییهای طولانیعمر و نسخهدار یک Cache-Control با آینده دور همراه با immutable بدهید، و به چیزهایی که واقعاً اغلب تغییر میکنند یک TTL کوتاهتر. تمیزترین الگو نامفایلهای محتوا-هششده است: وقتی یک تصویر تغییر میکند URL آن تغییر میکند، بنابراین edge بهطور طبیعی فایل جدید را ارائه میدهد و شما هرگز با cache کهنه نمیجنگید. وقتی مجبورید یک فایل را در همان URL بازنویسی کنید — تعویض یک لوگو، یک PDF اصلاحشده — یک purge هدفمند از پنل یا cdnctl آن شیء را از هر مکان edge رها میکند تا درخواست بعدی آن را دوباره از bucket بکشد. این باطلسازیها را نادر، دقیق و ایمن نگه میدارد.
مقیاسدهی از چند تصویر تا یک کتابخانه کامل رسانه
همان راهاندازیای که مشتی لوگو را ارائه میدهد به یک کاتالوگ از صدها هزار عکس محصول، یک کتابخانه ویدئوی درخواستی یا یک بایگانی چرخشی از پشتیبانهای شبانه مقیاس مییابد، چون Object Storage بدون آنکه شما دیسک تأمین کنید رشد میکند و edge ترافیک خواندن را جذب میکند. سایتهای پُررسانه تیزترین دستاوردها را میبینند: صفحات با جریان یافتن تصاویر از edge های نزدیک سبکتر و سریعتر میشوند، و پهنای باند origin — که اغلب گرانترین و شکنندهترین منبع است — بهشدت کاهش مییابد. پشتیبانها هم یک خانه تمیز میگیرند، مجزا در bucket خصوصی خود با access key خود، دور از مسیر تحویل عمومی.
جای آن در کنار بقیه پلتفرم
این سناریو عمداً بر ذخیرهسازی و تحویل متمرکز است، اما با هر چیز دیگر روی حساب جور درمیآید. یک اپلیکیشن WordPress یا PHP میتواند دایرکتوری آپلودهای خود را به یک bucket منتقل کند و همچنان سایت را از طریق همان edge ارائه دهد. یک اپلیکیشن container میتواند bucket را بهعنوان متغیرهای محیطی bind کند و اشیا را مستقیماً بخواند یا بنویسد. DNS و Auto SSL دامنه تحویل را رسیدگی میکنند، و purge، لاگها و وضعیت دید عملیاتی میدهند تا تأیید کنید داراییها از cache جریان مییابند و در هر درخواست بیصدا به origin miss نمیکنند.
راهاندازی گامبهگام
یک bucket بسازید
در پنل بخش Object Storage را باز و یک bucket برای رسانه خود بسازید (برای مثال media-prod). یک endpoint سازگار با S3، region و نام bucket میگیرید. bucket های جداگانه برای داراییهای عمومی و پشتیبانهای خصوصی نگه دارید تا سیاستهای دسترسی آنها هرگز با هم همپوشانی نکنند.
یک access key محدود تولید کنید
یک جفت access key / secret برای bucket بسازید و آن را در آپلودر، CMS یا SDK از نوع S3 خود بچسبانید. از یک کلید بهازای هر اپلیکیشن استفاده کنید تا بتوانید یک یکپارچهسازی واحد را بدون خراب کردن بقیه بچرخانید یا باطل کنید. کلیدها را میتوان هر زمان که یکی نشت کند از پنل چرخاند.
با هدرهای درست آپلود کنید
داراییها را با کلاینت S3، aws-cli یا پلاگین موجود خود push کنید و روی فایلهایی که هرگز تغییر نمیکنند Content-Type و یک Cache-Control طولانی (برای مثال max-age=31536000, immutable) تنظیم کنید. از نامفایلهای محتوا-هششده مانند logo.a1b2c3.png استفاده کنید تا یک نسخه جدید یک URL جدید باشد و هرگز به باطلسازی نیاز نداشته باشد.
CDN را جلوی آن قرار دهید
یک دامنه تحویل (برای مثال cdn.example.com) به CDN متصل و origin آن را به endpoint مربوط به bucket اشاره دهید. اکنون درخواستها ابتدا به edge میزنند، در مکانهای مختلف cache میشوند و تنها در اولین درخواست بهازای هر دارایی به Object Storage miss میکنند. Auto SSL گواهی را برای دامنه تحویل بهصورت خودکار صادر میکند.
رفتار cache را راستیآزمایی کنید
یک دارایی را دو بار بارگذاری و هدرهای پاسخ را برای یک HIT در درخواست دوم بررسی کنید. تأیید کنید که Cache-Control شما رعایت میشود و نوعهای MIME تصویر/ویدئو درست هستند تا مرورگرها و edge cache آنها را بهدرستی cache کنند.
purge را سیمکشی کنید
وقتی یک فایل را در همان URL بازنویسی میکنید، یک purge از پنل یا از طریق cdnctl صادر کنید تا edge نسخه کهنه را رها کند. برای داراییهایی که با نامفایل نسخهبندی میکنید بهندرت به این نیاز دارید، که دقیقاً دلیل توصیه نامهای محتوا-هششده برای رسانههای پُرتغییر است.
نمونه سناریوها
هزاران عکس محصول در یک bucket زندگی میکنند و از edge جریان مییابند، بنابراین صفحات فهرست و جزئیات در کمپینها سریع میمانند بدون بار انداختن بر سرور اپلیکیشن فروشگاه.
ویدئوی درخواستی و فایلهای نصبکننده یکبار ذخیره و از cache تحویل میشوند، و پهنای باند origin را حتی وقتی یک فایل ناگهان وایرال میشود ثابت نگه میدارند.
پشتیبانهای شبانه دیتابیس و فایل به یک bucket خصوصی با یک access key اختصاصی میروند، بهکلی خارج از مسیر تحویل عمومی نگه داشته میشوند و در صورت نیاز قابلچرخشاند.
پرسشهای پرتکرار
آیا ذخیرهسازی واقعاً با ابزارهای موجود من سازگار با S3 است؟
بله. bucket ها یک endpoint سازگار با S3 در معرض دید میگذارند، بنابراین aws-cli، s3cmd، rclone و AWS SDK ها با اشاره دادن آنها به endpoint همراه با access key و secret شما کار میکنند. بیشتر پلاگینهای آپلود CMS و فریمورک که از S3 پشتیبانی میکنند به همان روش کار میکنند.
آیا کاربران مستقیماً به bucket میزنند یا به CDN؟
برای تحویل عمومی، یک دامنه CDN را به endpoint مربوط به bucket اشاره میدهید و آن دامنه را در markup خود منتشر میکنید، بنابراین کاربران همیشه به edge cache میزنند. endpoint خام bucket پشت CDN میماند و آن چیزی نیست که صفحات شما به آن ارجاع میدهند.
چگونه فایلهای خصوصی را بدون عمومی کردن bucket ارائه دهم؟
اشیا را خصوصی نگه دارید و signed URL های کوتاهعمر را با access key خود تولید کنید. لینک دسترسی محدود به زمان میدهد و سپس منقضی میشود، که الگوی درست برای دانلودهای پولی، فاکتورها یا هر چیزی است که نباید برای همیشه عمومی باشد.
اگر یک تصویر را با همان نامفایل جایگزین کنم، چرا نسخه قدیمی همچنان نمایش داده میشود؟
چون edge نسخه قبلی را زیر آن URL کش کرده است. یک purge برای آن شیء از پنل یا cdnctl صادر کنید، یا نامفایلهای محتوا-هششده را بپذیرید تا هر نسخه جدید یک URL جدید داشته باشد و هرگز به purge نیاز نداشته باشد.
چه Cache-Control ای باید روی رسانه تنظیم کنم؟
داراییهای طولانیعمر و نسخهدار باید از یک max-age با آینده دور همراه با immutable استفاده کنند؛ فایلهای پُرتغییر باید از یک TTL کوتاهتر استفاده کنند. تنظیم هدر در زمان آپلود همان چیزی است که به edge امکان میدهد فایل را نگه دارد بهجای دریافت مجدد آن از bucket.
اگر یک کلید نشت کند میتوانم دسترسی را باطل کنم؟
بله. access key ها بهازای هر یکپارچهسازی از پنل چرخانده و باطل میشوند. چون یک کلید بهازای هر اپلیکیشن صادر میکنید، باطل کردن یک کلید نشتکرده تنها بر همان یکپارچهسازی اثر میگذارد نه هر سرویسی که bucket را میخواند.