مسئله را از معماری شروع کنیم
NGINX می‌تواند پاسخ upstream را روی disk نگه دارد و request بعدی را بدون رسیدن به application پاسخ دهد. رفتار صحیح به cache key، freshness، status code، headerها و bypass/no-cache ruleها بستگی دارد.
موضوع‌های زیرساختی زمانی قابل اتکا می‌شوند که مدل ذهنی قبل از command شکل بگیرد. componentها، state پایدار، state runtime، مرز اعتماد و dependency بیرونی را روی یک نقشهٔ ساده مشخص کنید. وقتی failure رخ می‌دهد، از ورودی به خروجی حرکت کنید و در هر مرز evidence جمع کنید؛ log، metric، API state و packet capture باید یک timeline مشترک بسازند.
روش عملی پیاده‌سازی
ابتدا endpointهای public و deterministic را cache کنید. Cache status را در response/log ثبت کنید، TTL را با رفتار business هماهنگ کنید و برای cookie/auth/headerهای شخصی‌ساز مسیر bypass واضح داشته باشید.
برای Production همیشه baseline، canary و rollback داشته باشید. baseline شامل نسخه، config مؤثر، latency یا throughput اصلی و یک test end-to-end سالم است. بعد از تغییر، test مثبت و منفی را تکرار کنید و نتیجه را با همان baseline مقایسه کنید. اگر success criterion از قبل نوشته نشده باشد، هر نتیجه‌ای را می‌توان موفق تفسیر کرد.
ریسک‌ها و خطاهای رایج
Cache کردن صفحهٔ personalized با key ناقص می‌تواند data leak بسازد. TTL طولانی روی محتوای حساس به freshness نیز correctness را قربانی performance می‌کند. purge/invalidations بدون طراحی به stale content منجر می‌شوند.
امنیت عملیاتی یعنی کنترل قابل توضیح و قابل مشاهده. permission، token، secret، network path و audit trail را جدا بررسی کنید. exceptionها باید owner و expiry داشته باشند. اگر کنترل فقط روی کاغذ وجود دارد ولی اثر آن در runtime قابل اثبات نیست، در زمان incident به‌جای کمک به مانع تبدیل می‌شود.
آزمایشگاه پیشنهادی
یک upstream ساده با timestamp بسازید، cache را فعال کنید و HIT/MISS را ثبت کنید. سپس cookie کاربر اضافه کنید و قبل و بعد از bypass بررسی کنید که پاسخ بین sessionها مخلوط نشود.
در Lab یک failure کنترل‌شده هم ایجاد کنید. هدف فقط اثبات happy path نیست؛ باید ببینید alert، log و recovery هنگام خرابی چه رفتاری دارند و آیا تیم می‌تواند بدون حدس علت را پیدا کند.
عیب‌یابی بر اساس Evidence
ابتدا مشخص کنید آخرین مرحله‌ای که رفتار صحیح دیده می‌شود کجاست. سپس فقط یک مرز جلو بروید. اگر request وارد component می‌شود اما state خروجی ساخته نمی‌شود، مسئله در همان component یا dependencyهای نزدیک آن است. تغییر هم‌زمان چند config دامنهٔ مسئله را بزرگ می‌کند.
امنیت و Least Privilege
دسترسی‌ها را براساس operation واقعی workload بدهید، نه براساس راحتی troubleshooting. credentialها را کوتاه‌عمر و قابل revoke نگه دارید، مسیرهای مدیریتی را از data plane جدا کنید و audit را طوری بسازید که بتوانید actor و زمان تغییر را بازسازی کنید.
Performance و ظرفیت
Average به‌تنهایی کافی نیست. p95/p99، saturation، queue depth، retry و resource pressure را ثبت کنید. workload واقعی ممکن است bottleneck متفاوتی از Lab کوچک نشان دهد؛ بنابراین rollout را مرحله‌ای کنید و ظرفیت را با margin طراحی کنید.
Production readiness
owner، blast radius، change window، success metric و rollback trigger را قبل از rollout بنویسید. dependency خارجی را عمداً unavailable کنید، restart واقعی و credential rotation را تست کنید و بعد از deploy چند روز دوباره metric و ticketها را مرور کنید.
Runbook و انتقال دانش
Runbook خوب فقط command نیست. سؤال، فرضیه، evidence مورد انتظار، نتیجه و دلیل تصمیم را ثبت کنید. نفر دیگری باید بتواند با همان ورودی آزمایش را تکرار کند، failure را بازتولید و recovery را انجام دهد. این معیار ساده کیفیت واقعی documentation را نشان می‌دهد.
نگهداری بلندمدت
نسخه، policy، certificate، endpoint و حجم workload تغییر می‌کنند. برای همین review دوره‌ای تعریف کنید: نسخهٔ پشتیبانی‌نشده، exception قدیمی، alert بی‌ارزش و drift را پیدا کنید. recovery را دوباره تمرین کنید و تاریخ review را در مستندات بنویسید.
تصمیم Production را با چه شواهدی بگیریم؟
قبل از اینکه نتیجهٔ Lab را به Production ببرید، یک change record کوتاه بسازید: مسئله‌ای که قرار است حل شود، وضعیت baseline، نسخه و config فعلی، dependencyهای درگیر، owner تغییر و دقیقاً چه metricی موفقیت را ثابت می‌کند. سپس یک canary انتخاب کنید که از نظر workload واقعی باشد اما blast radius محدودی داشته باشد. بعد از اعمال تغییر، فقط دنبال نبودن error نباشید؛ latency، throughput، queue، retry، saturation و تجربهٔ کاربر را با baseline مقایسه کنید. اگر feature امنیتی است، یک test منفی اجرا کنید تا مطمئن شوید مسیر غیرمجاز واقعاً بسته شده است. اگر feature availability است، dependency یا node را عمداً از دسترس خارج کنید و recovery واقعی را ببینید. تصمیم rollout باید براساس این evidence باشد، نه براساس اینکه dashboard سبز است یا command بدون خطا اجرا شده. هر rollout یک trigger صریح برای توقف و rollback داشته باشد. اگر نتیجه مبهم است، بهترین تصمیم معمولاً بزرگ‌تر نکردن دامنه و جمع‌کردن evidence بیشتر است.
ظرفیت، Failure Domain و Recovery
سیستم در حالت سالم فقط نیمی از داستان است. مشخص کنید failure domain واقعی چیست: process، node، rack، zone، storage backend، network path یا provider. اگر چند replica دارید ولی همه روی یک failure domain هستند، redundancy ظاهری دارید نه availability واقعی. برای capacity نیز فقط مصرف فعلی CPU و RAM را نبینید؛ رشد داده، burst، compaction، retry storm و recovery traffic می‌توانند در زمان incident چند برابر حالت عادی منابع بخواهند. RPO و RTO را به عدد تبدیل کنید و recovery را با stopwatch واقعی آزمایش کنید. اگر restore یا failover فقط در سند نوشته شده ولی هیچ‌وقت اجرا نشده، هنوز قابلیت اثبات‌شده‌ای نیست. بعد از هر incident یا تمرین recovery، runbook و thresholdها را بازبینی کنید تا درس واقعی وارد سیستم شود.
Operational Ownership و چرخهٔ تغییر
هر component باید owner مشخص داشته باشد. owner فقط کسی نیست که deploy می‌کند؛ باید بداند alert به چه معناست، چه log یا dashboardی evidence اصلی است، dependencyها کدام‌اند و چه زمانی escalation لازم است. تغییرهای config را در version control نگه دارید، peer review کنید و در صورت امکان validation را در CI قرار دهید. برای credential و certificate، expiry و rotation را قبل از حادثه تمرین کنید. برای سرویس‌های stateful، schema/data migration را از binary rollout جدا ببینید. همچنین بعد از تغییر، یک بازهٔ observation تعریف کنید؛ بعضی failureها فقط پس از restart دوم، rotation token، compaction، cron job یا load واقعی ظاهر می‌شوند. Production readiness یک checkbox لحظه‌ای نیست؛ چرخه‌ای از deploy، observe، learn و اصلاح است.
سناریوی Incident و Recovery
یک سناریوی خرابی واقعی برای همین موضوع طراحی کنید و قبل از وقوع حادثه آن را تمرین کنید. ابتدا شرایط شروع را ثبت کنید: چه سرویس‌هایی سالم‌اند، چه dependencyهایی در دسترس‌اند، چه metric و logی baseline محسوب می‌شود و کاربر چه رفتاری می‌بیند. سپس فقط یک failure ایجاد کنید؛ مثلاً node را از دسترس خارج کنید، credential را revoke کنید، backend را کند کنید یا config ناسازگار deploy کنید. زمان کشف، زمان تشخیص، زمان تصمیم و زمان بازیابی را جدا ثبت کنید. بعد بررسی کنید آیا alert واقعاً actionable بوده یا فقط noise تولید کرده است. آیا log کافی برای یافتن root cause داشتید؟ آیا rollback به state قبلی برگشت یا state/data جدید مانع شد؟ آیا نفر دیگری غیر از سازندهٔ سیستم توانست runbook را اجرا کند؟ در پایان post-incident کوتاهی بنویسید که شامل علت فنی، ضعف فرایند، اقدام اصلاحی و owner باشد. هدف تمرین پیدا کردن مقصر نیست؛ هدف این است که failure بعدی ارزان‌تر، قابل مشاهده‌تر و سریع‌تر قابل بازیابی باشد. همین تمرین ساده معمولاً شکاف‌هایی را نشان می‌دهد که در review معماری یا dashboard سالم دیده نمی‌شوند.
جمع‌بندی IROSG
در موضوع طراحی cache امن و قابل مشاهده در NGINX هدف حفظ چند دستور نیست؛ هدف ساختن مدل ذهنی و evidence است. وقتی معماری را بفهمید و rollout قابل برگشت داشته باشید، ابزار یا نسخه می‌تواند عوض شود اما روش حل مسئله باقی می‌ماند. مرجع اصلی این مطلب مستندات NGINX است.
چک‌لیست سریع
- مسئله را در یک جمله تعریف کن.
- معماری و مرز اعتماد را رسم کن.
- baseline را ذخیره کن.
- test مثبت و منفی بساز.
- canary اجرا کن.
- evidence را timestampدار نگه دار.
- rollback را تمرین کن.
- نتیجه را در runbook ثبت کن.
آزمایش جداسازی کاربران در cache
یک آزمایش مفید را با دو حساب ساختگی انجام دهید. هر حساب باید پاسخ شخصی متفاوتی از همان مسیر دریافت کند. نخست درخواست کاربر اول را بفرستید تا امکان ذخیره پاسخ وجود داشته باشد، سپس همان مسیر را با هویت کاربر دوم و پس از آن بدون هویت درخواست کنید. اگر پاسخ اول در هر سه حالت دیده شود، کلید یا قواعد bypass و عدم ذخیره با قرارداد برنامه سازگار نیست. پاسخ موفق HTTP در این آزمایش نشانه سلامت نیست؛ محتوای پاسخ و هویت صاحب آن معیار اصلی‌اند.
تنها اضافه کردن cookie به کلید نیز نسخه عمومی حل مسئله نیست. cookie ممکن است شناسه‌های متغیر و بی‌اهمیت داشته باشد و تعداد کلیدها را شدیداً افزایش دهد. ابتدا تعیین کنید چه پاسخ‌هایی واقعاً عمومی‌اند و کدام ویژگی درخواست، نمایش معتبر متفاوتی می‌سازد. زبان، میزبان، پارامترهای پرس‌وجو و headerهای مؤثر را آگاهانه بررسی کنید. حذف یک پارامتر از کلید در حالی که backend هنوز بر اساس آن محتوا را عوض می‌کند، امکان آمیختن پاسخ‌ها را ایجاد می‌کند.
انقضا، حذف و تازگی داده
TTL کوتاه با حذف هدفمند یکسان نیست. اگر قیمت یا مجوز دسترسی تغییر کند، حتی مدت کوتاهی ارائه پاسخ قدیمی ممکن است نامطلوب باشد. پیش از فعال‌کردن cache برای چنین مسیری، قرارداد تازگی را با مالک برنامه مشخص کنید. برای فایل‌های عمومی دارای نام نسخه‌دار، نگهداری طولانی معمولاً ساده‌تر است زیرا انتشار فایل جدید نام تازه‌ای دارد. در مقابل مسیری ثابت با محتوای حساس به زمان به سیاست دقیق‌تری نیاز دارد. قابلیت purge نیز به محصول و ماژول‌های نصب‌شده وابسته است و نباید بدون بررسی در همه نصب‌ها فرض شود.
در حالت خطای upstream، ارائه محتوای stale می‌تواند دسترس‌پذیری را بهتر کند، ولی برای هر محتوا درست نیست. صفحه اطلاع‌رسانی عمومی با وضعیت حساب کاربر قرارداد یکسانی ندارد. آزمایش کنید هنگام timeout، خطای برنامه و حذف محتوا کدام پاسخ ارائه می‌شود. در log، وضعیت cache را کنار زمان پاسخ و نتیجه upstream نگه دارید تا درخواست سریع ناشی از پاسخ قدیمی با پردازش سریع backend اشتباه نشود.
موج درخواست و ظرفیت دیسک
وقتی یک کلید محبوب منقضی می‌شود، درخواست‌های هم‌زمان ممکن است همگی به مقصد برسند. سازوکار قفل cache و رفتار به‌روزرسانی پس‌زمینه می‌توانند بخشی از این مسئله را مدیریت کنند، اما انتخاب آن‌ها باید با تأخیر قابل قبول و رفتار خطا آزموده شود. یک آزمایش کوچک بسازید که تعداد زیادی درخواست برای یک کلید و سپس برای کلیدهای متفاوت بفرستد. این دو بار، محدودیت‌های یکسانی را نشان نمی‌دهند.
اندازه cache روی دیسک و حافظه مربوط به کلیدها را جدا پایش کنید. پرشدن دیسک فقط روی نرخ hit اثر ندارد و ممکن است به سرویس‌های دیگری که همان فایل‌سیستم را استفاده می‌کنند آسیب بزند. پوشه cache را با مالکیت محدود و ظرفیت قابل کنترل نگه دارید. اگر نسبت hit پایین است، قبل از افزایش حجم، علت پراکندگی کلیدها و مدت زندگی محتوا را بررسی کنید؛ ذخیره پاسخ‌هایی که هرگز دوباره درخواست نمی‌شوند سودی برای کاربر ایجاد نمی‌کند.
