عملیات فناوری اطلاعات — قابلیت اطمینان سایت مدل زنده

شما برای یک سرویس وب آنکال هستید: یک توزیع‌کننده بار جلوی ناوگانی از نمونه‌ها، یک کش جلوی یک پایگاه داده، و هدف دسترس‌پذیری ۹۹٫۹ %. مدل هر دقیقه تأخیر صف، مهلت‌های تمام‌شده، برخوردهای کش و بار پایگاه داده را از فرمول‌های کتاب درسی حساب می‌کند — و اینکه تصمیم‌های شما چه هزینه‌ای دارند.

چه چیزی یاد می‌گیرید

شبیه‌ساز

زمان 0 min
درخواست‌ها 1125 · نرخ خطا 0.00% · تأخیر p99 342 ms · نمونه‌های در حال سرویس 10 (+0) · نرخ برخورد کش 77% · بهره‌برداری پایگاه داده 19% · بودجه خطای باقی‌مانده (۳۰ روز) 50.0%⇉1125 req/s▶▶▶▶▶▶▶▶▶▶······························▶ 10 · ⚙ 0 · 52% · p99 342 msبهره‌برداری ناوگان 52%نرخ برخورد کش 77%بهره‌برداری پایگاه داده 19%⚠ 0.00% · 🔥 0.0×50%$ 4.00/h · Σ $0.00
  • نمونه در حال سرویس
  • نمونه در حال بوت
  • نمونه روی ساخت بد
  • جای خالی
  • درخواست‌های ورودی

کنترل‌ها

کف ناوگان. بالا بردنش نمونه‌ها را فوراً راه می‌اندازد — اما پیش از سرویس‌دهی هنوز به تأخیر بوت نیاز دارند.

ردیابی هدف بهره‌برداری؛ تا وقتی نمونه‌ها هنوز در حال بوت‌اند مقیاس‌گذاری جدید رو به بالا انجام نمی‌شود. خاموش = دقیقاً کمینه.

کمتر = حاشیه بیشتر و هزینه بیشتر. بهره‌برداری اندازه‌گیری‌شده نمی‌تواند از ۱۰۰ % بیشتر شود، پس ناوگان اشباع فقط گام‌به‌گام رشد می‌کند.

TTL بلندتر = برخورد بیشتر، اما پاسخ‌ها می‌توانند قدیمی‌تر باشند (میانگین سن ≈ TTL/2).

کلیدهای پرتکرار را ۶ دقیقه بارگذاری می‌کند (۱۲+ % کش در دقیقه) به بهای ۶۰۰ پرس‌وجوی اضافه پایگاه داده در ثانیه.

سهمی از ۳۰ % کم‌اولویت (پیش‌واکشی، دسته‌ای، خزنده‌ها) که در توزیع‌کننده بار با «بعداً دوباره تلاش کنید» رد می‌شود.

ویژگی سنگین ۲۰ ms پردازنده و یک پرس‌وجوی پایگاه داده به ازای هر درخواست اضافه می‌کند. خاموش = تنزل ملایم.

آخرین نسخه سالم را روی ناوگانی تازه دوباره مستقر می‌کند (5 min، دو بار هزینه) و سپس ترافیک را جابه‌جا می‌کند. فشار دوباره آماده‌سازی را از نو شروع می‌کند؛ وقتی هیچ نسخه بدی در حال اجرا نیست فقط هزینه دارد.

شاخص‌ها

نرخ خطا
0.00%
عادی
تأخیر p99
342ms
عادی
بودجه خطای باقی‌مانده (۳۰ روز)
50.0%
عادی
بهره‌برداری ناوگان
52%
عادی
نرخ سوزاندن (۱ h)0.0 ×
درخواست‌ها1125 req/s
نمونه‌های در حال سرویس10
نمونه‌های در حال بوت0
نرخ برخورد کش77 %
بهره‌برداری پایگاه داده19 %
ترافیک ردشده0 %
هزینه ناوگان4.00 $/h
هزینه تاکنون0.00 $
میانگین سن پاسخ‌های کش30 s
ترافیک روی ساخت بد0 %
پیشنهادها در دسترس100 %

روند

نرخ خطا: — %20.000.00

سناریوهای بحران

سطح 1 · انتشار بد

یک ساخت جدید ساعت ۰۹:۱۰ منتشر می‌شود. ماه از قبل سخت بوده: فقط ۲۰ % بودجه خطا مانده است. دقایقی پس از استقرار، هشدار نرخ سوزاندن به صدا درمی‌آید. از بودجه محافظت کنید.

  • بودجه خطای باقی‌مانده در پایان ≥ 18.5 %
  • میانگین نرخ خطا ≤ 0.65 % پس از استقرار
  • هزینه ناوگان ≤ $9.50

سطح 2 · هجوم ناگهانی جمعیت

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

  • میانگین نرخ خطا ≤ 0.2 %
  • میانگین تأخیر p99 ≤ 400 ms
  • میانگین ترافیک ردشده ≤ 5 %
  • هزینه کل ≤ $21
  • پیشنهادها ≥ 85 % زمان در دسترس

سطح 3 · کش سرد

در اوج ظهر یک اسکریپت نگهداری کل کش را پاک می‌کند. اکنون هر درخواست به پایگاه داده می‌رود که برای نرخ برخورد معمول ۸۵ % اندازه شده بود. سرویس را بدون اضافه‌بار پایگاه داده بازگردانید.

  • میانگین نرخ خطا ≤ 1.5 %
  • بهره‌برداری پایگاه داده پس از دقیقه اول هرگز بالای 90 %
  • میانگین سن پاسخ‌های کش ≤ 90 s به‌طور میانگین
  • هزینه کل ≤ $9
  • پیشنهادها ≥ 80 % زمان در دسترس
  • میانگین ترافیک ردشده ≤ 5 %

مبنا — مدل پشت اعداد

هر رابطه‌ای که شبیه‌ساز به کار می‌برد، با منبعش. ثابت‌هایی که به‌عنوان فرض علامت خورده‌اند کالیبراسیون‌های نمونه‌ای‌اند.

درخواست‌ها از یک منحنی روزانه به‌علاوه اختلال‌ها پیروی می‌کنند؛ تعداد در دقیقه تصادفی است (پواسون، تقریب نرمال) با کمی انفجاری‌بودن.
λ(t) = base × (1 + 0.25·sin(2π(t + clock − 6 h)/24 h)) × surge(t), clock = time of day at the start (peak at 12:00); count/min ≈ N(60λ, √(60λ)) × (1 + N(0, 0.02))[6]فرض: تعداد workerها، زمان‌های سرویس، ظرفیت پایگاه داده، اندازه کش، سرعت پر شدن، قیمت‌ها و نرخ خطای ساخت بد مقادیر نمایشی برای یک سرویس وب متوسط‌اند.
Erlang C: احتمال اینکه یک درخواست در یک سیستم M/M/N باید منتظر یک worker آزاد بماند.
N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]
دنباله زمان انتظار: احتمال انتظار بیش از t به‌صورت نمایی کم می‌شود؛ درخواست‌هایی که در مهلت ۲ s هنوز منتظرند شکست می‌خورند. فراتر از ظرفیت، مازاد شکست می‌خورد.
P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]
تأخیر p99 از چندک‌های زمان سرویس و زمان انتظار.
p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]تقریب: جمع کردن چندک‌های سرویس و انتظار، p99 دقیق مجموع آن‌ها نیست (ممکن است کمی بالا یا پایین باشد)؛ صف در هر دقیقه پایدار فرض می‌شود چون درخواست‌ها میلی‌ثانیه طول می‌کشند.
قانون لیتل: workerهای مشغول = نرخ ورود × زمان در سرویس.
busy workers L = λ·S ⇒ utilization = λ·S / N[4]
کش با TTL: با درخواست‌های تصادفی، هر خطا یک دوره TTL را شروع می‌کند که در آن درخواست‌ها برخورد می‌کنند.
hit = warm × rT/(1 + rT), r = λ / 20,000 objects; mean age of a cached answer ≈ T/2[5]
خطاهای کش پایگاه داده را بار می‌کنند؛ تأخیر صف آن هر درخواستی را که به آن می‌رسد کند می‌کند و این workerهای برنامه را هم پر می‌کند.
DB load = λ·q·(1 − hit); query time = 5 ms/(1 − ρ_db) (≤ 250 ms); S = S_app + (1 − hit)·q·query time[6]فرض: تعداد workerها، زمان‌های سرویس، ظرفیت پایگاه داده، اندازه کش، سرعت پر شدن، قیمت‌ها و نرخ خطای ساخت بد مقادیر نمایشی برای یک سرویس وب متوسط‌اند.
SLO و بودجه خطا: نرخ سوزاندن می‌گوید بودجه چند برابر سریع‌تر از مجاز مصرف می‌شود.
budget = 1 − SLO = 0.1 %; burn = error rate / 0.1 %; Δbudget per min = burn / 43,200; burn (1 h) = mean error rate over the last 60 min / 0.1 % (window pre-filled with the opening minute)[1][2]
مقیاس‌گذار خودکار با ردیابی هدف، با تأخیر بوت و زمان خنک‌شدن.
desired = ⌈serving × utilization / target⌉ (utilization saturates at 100 %); new instances serve after the boot delay[6]فرض: تعداد workerها، زمان‌های سرویس، ظرفیت پایگاه داده، اندازه کش، سرعت پر شدن، قیمت‌ها و نرخ خطای ساخت بد مقادیر نمایشی برای یک سرویس وب متوسط‌اند.
سایر ثابت‌های عملیاتی مورد استفاده در مدل.
16 workers/instance · app time 50 ms (+20 ms and +1 query with the feature on) · 2 queries/request · DB 4,000 queries/s · 20,000 hot objects · cache refill τ = 30 min (slower while the DB is saturated) · warm-up job +12 %/min for 6 min, +600 queries/s · timeout 2 s · 30 % low-priority traffic · bad build +5 % errors, ×1.25 CPU · rollback 5 min · $0.40 per instance-hour · scale-in by ≤ 20 % of the fleet after 10 quiet minutes · up to 40 instancesفرض: تعداد workerها، زمان‌های سرویس، ظرفیت پایگاه داده، اندازه کش، سرعت پر شدن، قیمت‌ها و نرخ خطای ساخت بد مقادیر نمایشی برای یک سرویس وب متوسط‌اند.

تصادفی‌بودن: یک مولد mulberry32 با seed؛ توزیع‌های به‌کاررفته — یکنواخت، نمایی (وارون CDF)، نرمال (Box–Muller)، پواسون (Knuth). seed نمایش داده می‌شود و قابل اشتراک است.

منابع

  1. Site Reliability Engineering — Ch. 3 Embracing Risk (error budgets), Ch. 4 Service Level Objectives — Beyer, Jones, Petoff, Murphy (eds.), O'Reilly, 2016
  2. The Site Reliability Workbook — Ch. 5 Alerting on SLOs (burn rate; 14.4× over 1 h = 2 % of a 30-day budget) — Beyer, Murphy, Rensin, Kawahara, Thorne (eds.), O'Reilly, 2018
  3. Teletraffic Engineering Handbook — Erlang C formula; waiting-time distribution for M/M/n, FCFS — ITU-D Study Group 2 Question 16/2 (V. B. Iversen), 2005
  4. J. D. C. Little — A Proof for the Queuing Formula: L = λW — Operations Research 9(3):383–387, 1961
  5. J. Jung, A. W. Berger, H. Balakrishnan — Modeling TTL-based Internet Caches — IEEE INFOCOM 2003, 2003
  6. M. Harchol-Balter — Performance Modeling and Design of Computer Systems: Queueing Theory in Action (M/M/k, server farms, capacity provisioning) — Cambridge University Press, 2013

چه کسی این کار را حرفه‌ای انجام می‌دهد

مدل آموزشی — برای تصمیم‌های عملیاتی نیست. سایت‌های واقعی هر ثابت را با تجهیزات و داده‌های خودشان کالیبره می‌کنند.