سوالات مصاحبه Load Balancing و شبکه سطح سینیور (50 سوال)

Question 1

۵۰ نود LB مستقل که هرکدام دید محلی و کمی قدیمی از بار دارند، همگی least connections اجرا می‌کنند. چرا power of two choices اغلب بهتر عمل می‌کند؟

Accepted Answer

least connections باعث می‌شود همه نودها همزمان سرور ظاهراً کم‌بار را انتخاب کنند (herding)؛ تصادفی بودن p2c این را می‌شکند

Answer

p2c دید کامل و لحظه‌ای از بار همه سرورها را بین نودها همگام می‌کند

Answer

least connections در محیط توزیع‌شده از نظر فنی قابل پیاده‌سازی نیست

Answer

p2c همه درخواست‌ها را به دو سرور ثابت محدود می‌کند و cache hit را بالا می‌برد

Question 2

برای cache locality درخواست‌ها را با consistent hashing بر اساس `tenant_id` route می‌کنید، اما یک tenant بزرگ یک نود را از کار می‌اندازد. مناسب‌ترین اصلاح؟

Accepted Answer

consistent hashing with bounded loads: سقف بار برای هر نود و سرریز به نود بعدی حلقه

Answer

افزایش تعداد virtual nodeها تا بار آن tenant خودکار تقسیم شود

Answer

جایگزینی با `hash(tenant_id) % N` برای توزیع یکنواخت‌تر

Answer

کاهش TTL رکورد DNS تا کلاینت‌ها سریع‌تر پخش شوند

Question 3

چرا Maglev hashing برای یک لایه L4 load balancer با چندین نود مستقل مناسب است؟

Accepted Answer

توزیع تقریباً یکنواخت با lookup table و حداقل جابه‌جایی، بدون state مشترک بین نودها

Answer

تضمین صفر جابه‌جایی flowها حتی هنگام حذف backendها

Answer

امکان routing بر اساس header و cookie در لایه ۴ را فراهم می‌کند

Answer

نیاز به health check backendها را از بین می‌برد

Question 4

rendezvous hashing (HRW) چگونه کار می‌کند و trade-off آن نسبت به ring-based consistent hashing چیست؟

Accepted Answer

برای هر نود `hash(key, node)` حساب و بیشترین انتخاب می‌شود؛ بدون ring و vnode، اما lookup از `O(N)` است

Answer

کلید روی حلقه hash می‌شود و نود بعدی ساعت‌گرد انتخاب می‌شود؛ lookup از `O(1)` است

Answer

نودها به نوبت کلیدها را می‌گیرند؛ هیچ محاسبه hash لازم نیست

Answer

یک coordinator مرکزی نگاشت کلید به نود را نگه می‌دارد؛ نیاز به شبکه دارد

Question 5

یک سرویس gRPC را از ۳ به ۱۰ پاد scale می‌کنید و client-side LB هم دارید، اما ۷ پاد جدید تقریباً ترافیکی نمی‌گیرند. یک اصلاح سمت سرور مؤثر چیست؟

Accepted Answer

تنظیم `MaxConnectionAge` تا سرور با `GOAWAY` کلاینت‌ها را به reconnect و resolve مجدد وادار کند

Answer

افزایش `MaxConcurrentStreams` تا پادهای قدیمی درخواست بیشتری بپذیرند

Answer

غیرفعال کردن keepalive تا connectionها هرگز بسته نشوند

Answer

افزایش readiness probe delay پادهای جدید

Question 6

در Envoy، اگر درصد hostهای سالم یک cluster زیر panic threshold (پیش‌فرض ۵۰٪) برود چه می‌شود و چرا؟

Accepted Answer

ترافیک بین همه hostها، شامل unhealthyها، پخش می‌شود تا چند host باقی‌مانده زیر بار له نشوند

Answer

همه درخواست‌ها فوراً با `503` رد می‌شوند تا سیستم ریکاوری کند

Answer

Envoy به‌طور خودکار hostهای unhealthy را ری‌استارت می‌کند

Answer

ترافیک فقط به یک host سالم تصادفی فرستاده می‌شود

Question 7

چرا outlier detection معمولاً با `max_ejection_percent` (مثلاً ۱۰٪) محدود می‌شود؟

Accepted Answer

تا یک مشکل سیستمی (مثل خرابی وابستگی مشترک) باعث eject شدن کل fleet و قطعی کامل نشود

Answer

تا مصرف حافظه Envoy برای نگه‌داری لیست hostها کم بماند

Answer

چون Envoy از نظر فنی نمی‌تواند بیش از ۱۰٪ hostها را track کند

Answer

تا hostهای eject‌شده سریع‌تر ری‌استارت شوند

Question 8

در یک spike ترافیک، health check سرورهای پربار timeout می‌شود، LB آن‌ها را خارج می‌کند و بقیه هم پشت سر هم می‌افتند. ریشه‌ای‌ترین اصلاح؟

Accepted Answer

health check سبک و اولویت‌دار، و load shedding با `503` به‌جای fail شدن health check زیر بار

Answer

افزایش interval health check به چند دقیقه

Answer

حذف کامل health check و تکیه بر round robin

Answer

سوییچ از least connections به IP hash

Question 9

مسیر درخواست ۴ لایه دارد و هر لایه تا ۳ تلاش انجام می‌دهد. وقتی پایین‌ترین سرویس کند می‌شود چه اتفاقی می‌افتد و راه‌حل چیست؟

Accepted Answer

بار تا `3^4 = 81` برابر تقویت می‌شود؛ retry فقط در یک لایه همراه با retry budget و backoff

Answer

بار حداکثر ۳ برابر می‌شود؛ مشکلی نیست چون retry همیشه امن است

Answer

بار ۱۲ برابر می‌شود؛ باید timeoutها را در همه لایه‌ها حذف کرد

Answer

هیچ تقویتی رخ نمی‌دهد چون LB درخواست‌های تکراری را حذف می‌کند

Question 10

یک reverse proxy به یک backend با یک IP و پورت، در ترافیک بالا خطای `EADDRNOTAVAIL` می‌دهد. علت و راه‌حل‌های درست؟

Accepted Answer

اتمام ephemeral portها برای tuple مقصد؛ connection pooling، source IPهای بیشتر یا IP/پورت‌های مقصد بیشتر

Answer

پر شدن دیسک proxy؛ پاک کردن لاگ‌ها

Answer

certificate backend منقضی شده؛ تمدید certificate

Answer

DNS قادر به resolve نیست؛ کاهش TTL

Question 11

با وجود graceful shutdown در اپ، هر rolling update در Kubernetes چند ثانیه خطای `502` می‌دهد. محتمل‌ترین علت و اصلاح؟

Accepted Answer

حذف endpoint با تأخیر به kube-proxy/ingress می‌رسد؛ `preStop` sleep چندثانیه‌ای و ادامه سرویس‌دهی پس از `SIGTERM`

Answer

readiness probe خیلی سریع است؛ باید آن را کاملاً غیرفعال کرد

Answer

تعداد replicaها کم است؛ باید `maxSurge` را صفر کرد

Answer

DNS داخلی cluster کند است؛ باید TTL را افزایش داد

Question 12

چرا anycast برای connectionهای TCP طولانی‌مدت (مثل دانلودهای چندساعته) ریسک دارد؟

Accepted Answer

تغییر مسیر BGP وسط connection بسته‌ها را به PoP دیگری می‌برد که state آن TCP را ندارد و RST می‌دهد

Answer

anycast فقط از پروتکل UDP پشتیبانی می‌کند و TCP اصلاً کار نمی‌کند

Answer

anycast به‌طور خودکار connectionها را بعد از ۶۰ ثانیه می‌بندد

Answer

anycast برای هر بسته یک IP مقصد تصادفی انتخاب می‌کند

Question 13

در یک جفت keepalived، لینک heartbeat قطع می‌شود ولی هر دو نود سالم‌اند. چه خطری وجود دارد و چگونه کاهش می‌یابد؟

Accepted Answer

split-brain: هر دو VIP را تصاحب می‌کنند؛ مسیرهای heartbeat چندگانه، fencing یا witness/quorum

Answer

هر دو نود خاموش می‌شوند؛ باید interval را بیشتر کرد

Answer

VIP برای همیشه حذف می‌شود؛ باید DNS را به IP دیگری برد

Answer

هیچ خطری نیست چون VRRP همیشه یک master دارد

Question 14

لایه L4 LB شما پشت router با ECMP است. با اضافه کردن یک نود LB، بخشی از connectionهای جاری reset می‌شوند. چه طراحی‌ای این را کم می‌کند؟

Accepted Answer

همه نودها با consistent hashing (مثل Maglev) backend را انتخاب کنند و connection tracking محلی هم داشته باشند

Answer

هر نود LB از round robin مستقل با شمارنده محلی استفاده کند

Answer

جایگزینی ECMP با DNS round robin بین نودهای LB

Answer

افزایش idle timeout همه connectionها به یک روز

Question 15

در DSR لایه ۲، چرا backendها باید VIP را روی loopback داشته باشند اما به ARP آن پاسخ ندهند؟

Accepted Answer

تا بسته‌های مقصد VIP را بپذیرند و با VIP پاسخ دهند، بدون اینکه ترافیک را از LB بدزدند

Answer

تا ترافیک بین backendها رمزنگاری شود

Answer

تا LB بتواند header‌های HTTP را تغییر دهد

Answer

تا health check از طریق ARP انجام شود

Question 16

نرخ TLS session resumption روی fleet بیست‌نودی L7 شما تقریباً صفر است و CPU handshake بالاست. علت محتمل؟

Accepted Answer

هر نود کلید session ticket جداگانه دارد و کلاینتی که به نود دیگری برسد نمی‌تواند resume کند

Answer

TLS 1.3 از session resumption پشتیبانی نمی‌کند

Answer

certificate از نوع wildcard است و resumption را غیرفعال می‌کند

Answer

HTTP/2 همیشه برای هر درخواست handshake کامل انجام می‌دهد

Question 17

سرورهای WebSocket را از ۴ به ۸ scale کردید، اما ۴ سرور قدیمی هنوز داغ‌اند و جدیدها تقریباً بیکار. چه کاری بار را واقعاً متعادل می‌کند؟

Accepted Answer

سرورهای داغ به‌تدریج و با jitter بخشی از connectionها را ببندند تا کلاینت‌ها روی سرورهای جدید reconnect کنند

Answer

تغییر الگوریتم LB به round robin برای connectionهای موجود

Answer

کاهش TTL رکورد DNS به ۵ ثانیه

Answer

فعال کردن cross-zone load balancing روی LB

Question 18

یک اپ legacy به sticky session متکی است و autoscaling دارد. کدام مشکل‌ها انتظار می‌رود؟

Accepted Answer

instanceهای جدید فقط sessionهای جدید می‌گیرند و scale-in sessionهای کاربران را از بین می‌برد

Answer

autoscaling به‌طور کامل غیرفعال می‌شود چون LB اجازه نمی‌دهد

Answer

همه کاربران در هر درخواست به سرور تصادفی جدیدی می‌روند

Answer

sticky session باعث می‌شود همه instanceها یک session مشترک داشته باشند

Question 19

hedged requests برای کاهش tail latency چگونه کار می‌کنند و چه محدودیتی دارند؟

Accepted Answer

اگر پاسخ تا حدود p95 نرسید، درخواست دوم به replica دیگر می‌رود؛ فقط برای عملیات idempotent و با سقف بار اضافه

Answer

همه درخواست‌ها از ابتدا به سه replica فرستاده می‌شوند؛ برای همه عملیات‌ها امن است

Answer

درخواست‌های کند در صف نگه داشته می‌شوند تا سرور خلوت شود

Answer

timeout همه لایه‌ها به p50 کاهش می‌یابد

Question 20

در یک flash sale ظرفیت ۳ برابر کم است. بهترین رفتار لایه edge/LB چیست؟

Accepted Answer

load shedding بر اساس اولویت: رد سریع ترافیک کم‌اهمیت با `503` و `Retry-After` و حفظ checkout

Answer

پذیرفتن همه درخواست‌ها و صف کردن آن‌ها تا هر وقت پردازش شوند

Answer

رد تصادفی ۶۶٪ درخواست‌ها بدون توجه به نوع آن‌ها

Answer

خاموش کردن health checkها تا سرورها از rotation خارج نشوند

Question 21

zone-aware routing (مثل Envoy) ترافیک را ترجیحاً در همان AZ نگه می‌دارد. چه زمانی باید به zoneهای دیگر spill کند؟

Accepted Answer

وقتی hostهای سالم zone محلی برای سهم ترافیک آن zone کافی نیستند

Answer

هر بار که latency درخواست از ۱ میلی‌ثانیه بیشتر شود

Answer

هرگز؛ ترافیک باید همیشه در همان zone بماند

Answer

فقط وقتی کل region از کار افتاده است

Question 22

fleet شما ترکیبی از چند نسل instance است و noisy neighbor هم دارید؛ weighted round robin با وزن ثابت نتیجه بدی می‌دهد. رویکرد بهتر؟

Accepted Answer

وزن‌دهی پویا بر اساس بار گزارش‌شده توسط backend (مثل CPU یا QPS از طریق ORCA)

Answer

محاسبه دستی وزن‌ها یک بار در سال بر اساس مشخصات سخت‌افزار

Answer

استفاده از IP hash تا هر کلاینت روی یک instance بماند

Answer

حذف همه instanceهای قدیمی‌تر از یک نسل

Question 23

API gateway شما JWT را اعتبارسنجی می‌کند، پس تیمی پیشنهاد می‌دهد سرویس‌ها هیچ بررسی امنیتی نکنند. مشکل اصلی چیست؟

Accepted Answer

ترافیک داخلی می‌تواند gateway را دور بزند و authorization سطح object فقط در سرویس قابل انجام است

Answer

gateway از نظر فنی نمی‌تواند JWT را اعتبارسنجی کند

Answer

اعتبارسنجی JWT در gateway باعث افزایش TTL DNS می‌شود

Answer

سرویس‌ها بدون بررسی امنیتی همیشه کندتر می‌شوند

Question 24

limit سراسری ۱۰۰۰ درخواست در ثانیه برای هر API key روی ۲۰ نود gateway با autoscaling. کدام رویکرد trade-off معقولی دارد؟

Accepted Answer

token bucket محلی با sync دوره‌ای به store مرکزی؛ دقت تقریبی در ازای latency کم

Answer

limit ثابت ۵۰ در هر نود؛ همیشه دقیق است حتی با تغییر تعداد نودها

Answer

فراخوانی همزمان Redis در هر درخواست؛ بدون هیچ هزینه latency یا وابستگی

Answer

اعمال limit فقط در کلاینت؛ چون کلاینت‌ها همیشه قابل اعتمادند

Question 25

رکورد `A` فعلی TTL برابر ۸۶۴۰۰ دارد و قرار است فردا ساعت ۱۰ به LB جدید مهاجرت کنید. برنامه درست چیست؟

Accepted Answer

حداقل ۲۴ ساعت قبل TTL را به مثلاً ۶۰ کاهش دهید، سپس سوییچ کنید و LB قدیمی را مدتی فعال نگه دارید

Answer

ساعت ۱۰ همزمان TTL را ۶۰ و IP را عوض کنید؛ همه کاربران ظرف یک دقیقه منتقل می‌شوند

Answer

TTL را افزایش دهید تا cacheها پایدارتر شوند و بعد IP را عوض کنید

Answer

LB قدیمی را دقیقاً هنگام تغییر رکورد خاموش کنید

Question 26

کاربران آسیایی که از یک resolver عمومی استفاده می‌کنند، توسط GeoDNS به دیتاسنتر اروپا فرستاده می‌شوند. علت و راه‌حل محتمل؟

Accepted Answer

GeoDNS موقعیت resolver را می‌بیند نه کاربر را؛ پشتیبانی از EDNS Client Subnet یا استفاده از anycast

Answer

پایگاه داده GeoIP کاربران آسیا را اروپا ثبت کرده؛ باید TTL را افزایش داد

Answer

کاربران آسیایی از IPv6 استفاده می‌کنند که GeoDNS پشتیبانی نمی‌کند

Answer

دیتاسنتر آسیا رکورد `MX` ندارد

Question 27

control plane مدیریت LB (API کانفیگ و discovery) یک ساعت قطع می‌شود. طراحی statically stable چه رفتاری از data plane انتظار دارد؟

Accepted Answer

ادامه سرویس‌دهی با آخرین کانفیگ و لیست endpoint معتبر، بدون وابستگی به control plane

Answer

توقف کامل ترافیک تا control plane برگردد و کانفیگ را تأیید کند

Answer

پاک کردن کانفیگ و برگشت به حالت پیش‌فرض کارخانه

Answer

ارسال همه ترافیک به یک backend ثابت تا اطلاعات تازه برسد

Question 28

region A دو ساعت قطع بود و ترافیک به B رفته بود. A دوباره سالم گزارش می‌شود. چرا نباید GSLB فوراً ۱۰۰٪ ترافیک A را برگرداند؟

Accepted Answer

cacheهای A سرد، autoscaling آن کوچک‌شده و poolها خالی‌اند؛ انتقال یک‌باره می‌تواند دوباره آن را بیندازد

Answer

چون DNS اجازه تغییر رکورد را بیش از یک بار در روز نمی‌دهد

Answer

چون ترافیک region B به‌طور خودکار برای همیشه آنجا قفل شده است

Answer

چون health check region A همیشه نتیجه نادرست می‌دهد

Question 29

header دریافتی `X-Forwarded-For: 1.2.3.4, 203.0.113.7, 10.0.0.5` است و فقط LB شما (`10.0.0.5`) مورد اعتماد است. IP واقعی کلاینت کدام است؟

Accepted Answer

`203.0.113.7`، اولین IP از سمت راست که متعلق به proxyهای مورد اعتماد نیست

Answer

`1.2.3.4`، چون چپ‌ترین IP همیشه کلاینت اصلی است

Answer

`10.0.0.5`، چون آخرین IP همیشه کلاینت است

Answer

هیچ‌کدام؛ `X-Forwarded-For` هرگز نباید خوانده شود

Question 30

HTTP request smuggling بین reverse proxy و backend از چه چیزی ناشی می‌شود؟

Accepted Answer

تفسیر متفاوت مرز درخواست‌ها (مثلاً `Content-Length` در برابر `Transfer-Encoding`) روی connection مشترک

Answer

استفاده از certificateهای self-signed بین proxy و backend

Answer

فعال بودن gzip روی پاسخ‌های backend

Answer

تنظیم TTL پایین برای رکورد DNS سرویس

Question 31

چرا برای proxy لایه ۷ که با HTTP/2 به backendها وصل است، «least outstanding requests» از «least connections» معنادارتر است؟

Accepted Answer

با multiplexing، هر backend شاید فقط یک connection داشته باشد و تعداد connection بار را نشان نمی‌دهد

Answer

HTTP/2 اجازه نمی‌دهد proxy تعداد connectionها را بشمارد

Answer

least connections فقط برای ترافیک UDP تعریف شده است

Answer

least outstanding requests نیازی به اطلاعات از backend ندارد ولی least connections دارد

Question 32

GSLB در یک failover منطقه‌ای کاربران را به region B می‌برد که replica دیتابیس آن ۳۰ ثانیه عقب است. کدام پیامد را باید صریحاً طراحی کرد؟

Accepted Answer

از دست رفتن یا دیده نشدن writeهای اخیر (RPO) و شکستن read-your-writes

Answer

افزایش اندازه certificate TLS در region B

Answer

غیرفعال شدن خودکار rate limiting در region B

Answer

تبدیل همه connectionها به UDP

Question 33

shuffle sharding در لایه LB یا worker pool چه مزیتی دارد؟

Accepted Answer

هر مشتری به ترکیب تصادفی کوچکی از نودها می‌رسد، پس یک مشتری مخرب فقط درصد ناچیزی از بقیه را تحت تأثیر قرار می‌دهد

Answer

همه مشتری‌ها بین همه نودها پخش می‌شوند تا بار کاملاً یکنواخت شود

Answer

هر مشتری یک نود اختصاصی دارد و هیچ نودی مشترک نیست

Answer

shardها هر ساعت به‌طور تصادفی جابه‌جا می‌شوند تا امنیت بیشتر شود

Question 34

در Kubernetes، تنظیم `externalTrafficPolicy: Local` روی یک Service از نوع LoadBalancer چه trade-offی دارد؟

Accepted Answer

IP کلاینت حفظ و hop اضافه حذف می‌شود، اما بار بر اساس node پخش می‌شود و ممکن است پادها نامتوازن شوند

Answer

همه پادها در یک node قرار می‌گیرند و availability کم می‌شود

Answer

TLS به‌طور خودکار روی هر node terminate می‌شود

Answer

ترافیک فقط از داخل cluster قابل دسترس می‌شود

Question 35

یک SYN flood گسترده به VIP شما می‌رسد. چرا terminate کردن TCP روی LB یا proxy لبه با SYN cookies کمک می‌کند؟

Accepted Answer

state تا تکمیل handshake نگه داشته نمی‌شود و backendها فقط connectionهای کامل را می‌بینند

Answer

SYN cookies آدرس IP مهاجم را به‌طور خودکار در BGP مسدود می‌کنند

Answer

SYN cookies ترافیک را به UDP تبدیل می‌کنند که flood نمی‌شود

Answer

SYN cookies نیاز به TLS را حذف می‌کنند و CPU آزاد می‌شود

Question 36

چرا یک L4 LB که بر اساس 5-tuple hash می‌کند برای HTTP/3 (QUIC) مشکل دارد؟

Accepted Answer

با connection migration، IP/پورت کلاینت عوض می‌شود؛ LB باید بر اساس Connection ID route کند

Answer

QUIC روی TCP اجرا می‌شود و LB نمی‌تواند پورت را ببیند

Answer

HTTP/3 همیشه از پورت تصادفی استفاده می‌کند که hash را بی‌معنا می‌کند

Answer

QUIC بسته‌ها را به همه سرورها broadcast می‌کند

Question 37

proxyless gRPC با xDS چه trade-offی نسبت به mesh مبتنی بر sidecar دارد؟

Accepted Answer

حذف hop و هزینه sidecar، اما فقط برای کلاینت‌های gRPC پشتیبانی‌شده و با وابستگی به نسخه کتابخانه

Answer

latency بیشتر، اما پشتیبانی از همه پروتکل‌ها مثل Redis و MySQL

Answer

بدون نیاز به control plane، اما بدون load balancing

Answer

امنیت بیشتر، اما ناسازگاری کامل با Kubernetes

Question 38

چرا برای service discovery معمولاً registry با رفتار AP (مثل Eureka) به CP ترجیح داده می‌شود؟

Accepted Answer

در partition، لیست کمی قدیمی endpointها بهتر از نداشتن هیچ پاسخی است و کلاینت‌ها خطا را با retry جبران می‌کنند

Answer

registryهای AP همیشه داده دقیق‌تر و تازه‌تری از CP دارند

Answer

CP registryها از نظر فنی نمی‌توانند heartbeat دریافت کنند

Answer

AP registryها نیازی به replication ندارند

Question 39

پشت یک ALB با idle timeout ۶۰ ثانیه، backend Node.js با `keepAliveTimeout` پیش‌فرض ۵ ثانیه گاه‌به‌گاه `502` می‌دهد. علت و اصلاح؟

Accepted Answer

backend connection بی‌کار را زودتر می‌بندد و LB همزمان روی آن درخواست می‌فرستد؛ keep-alive backend را بیشتر از idle timeout LB کنید

Answer

Node.js از HTTP/1.1 پشتیبانی نمی‌کند؛ باید HTTP/2 را فعال کرد

Answer

idle timeout LB خیلی کوتاه است؛ باید آن را به ۱ ثانیه کاهش داد

Answer

certificate بین ALB و backend منقضی شده است

Question 40

چرا mTLS در service mesh برای authorization بین سرویس‌ها از NetworkPolicy مبتنی بر IP قوی‌تر است؟

Accepted Answer

هویت رمزنگاری‌شده workload (مثل SPIFFE ID) مستقل از IPهای متغیر پادهاست و policy بر اساس سرویس نوشته می‌شود

Answer

mTLS ترافیک را سریع‌تر از ترافیک بدون رمز می‌کند

Answer

mTLS نیاز به certificate را کاملاً حذف می‌کند

Answer

NetworkPolicy در Kubernetes از نظر فنی پشتیبانی نمی‌شود

Question 41

چرا ارائه‌دهندگان بزرگ معمولاً لایه‌ها را به‌صورت anycast/ECMP ← L4 LB ← L7 proxy ← سرویس می‌چینند؟

Accepted Answer

L4 ارزان و stateless-مانند است و لایه گران L7 (TLS، routing) را افقی و مستقل scale می‌کند

Answer

چون هر لایه نسخه پشتیبان کامل لایه قبلی است و همان کار را تکرار می‌کند

Answer

چون L7 proxyها نمی‌توانند هیچ‌گاه بیش از یک instance داشته باشند

Answer

چون anycast فقط با L7 proxy سازگار است و L4 را دور می‌زند

Question 42

با وزن‌های A=5، B=1، C=1، چرا smooth weighted round robin (مثل NGINX) از پیاده‌سازی ساده بهتر است؟

Accepted Answer

به‌جای `AAAAABC` ترتیبی مثل `AABACAA` تولید می‌کند و burst روی A را از بین می‌برد

Answer

وزن‌ها را به‌طور خودکار بر اساس CPU سرورها تنظیم می‌کند

Answer

سهم C را برای عدالت بیشتر به اندازه A افزایش می‌دهد

Answer

فقط زمانی کار می‌کند که همه وزن‌ها برابر باشند

Question 43

هنگام drain کردن یک proxy، چگونه کلاینت‌های HTTP/2 و HTTP/1.1 keep-alive را بدون قطع ناگهانی به instance دیگر منتقل می‌کنید؟

Accepted Answer

برای HTTP/2 فریم `GOAWAY` و برای HTTP/1.1 header `Connection: close` روی پاسخ بعدی

Answer

ارسال RST به همه connectionها تا کلاینت‌ها فوراً reconnect کنند

Answer

تغییر رکورد DNS و انتظار برای انقضای TTL، بدون تغییر در connectionها

Answer

کاهش `MaxConcurrentStreams` به صفر بدون اطلاع به کلاینت

Question 44

یک پخش زنده انتظار دارید که ترافیک را در ۳۰ ثانیه ۲۰ برابر کند. ریسک نادیده‌گرفته‌شده در load balancer مدیریت‌شده ابری چیست؟

Accepted Answer

خود LB به‌تدریج scale می‌شود و ممکن است پیش از scale شدن خطا دهد؛ pre-warming یا load test لازم است

Answer

LB مدیریت‌شده ظرفیت نامحدود و فوری دارد و هیچ ریسکی نیست

Answer

LB در ترافیک بالا به‌طور خودکار HTTPS را غیرفعال می‌کند

Answer

LB در spikeها همه ترافیک را به یک AZ می‌فرستد

Question 45

در یک mesh با ۲۰۰۰ sidecar و سرویسی با ۵۰۰ instance، active health check از هر sidecar چه مشکلی ایجاد می‌کند؟

Accepted Answer

میلیون‌ها probe در هر interval؛ بهتر است به health مرکزی از control plane و outlier detection تکیه شود

Answer

هیچ مشکلی ندارد چون probeها بسیار سبک‌اند

Answer

sidecarها نمی‌توانند به بیش از ۱۰ instance probe بفرستند

Answer

probeها باعث می‌شوند certificateهای mTLS منقضی شوند

Question 46

۵۰۰۰ کلاینت هرکدام به همه ۱۰۰۰ backend connection پایدار دارند و حافظه backendها صرف connectionها می‌شود. تکنیک مناسب؟

Accepted Answer

deterministic subsetting: هر کلاینت فقط به زیرمجموعه متوازنی از backendها وصل شود

Answer

افزایش idle timeout تا connectionها کمتر بسته و باز شوند

Answer

سوییچ همه کلاینت‌ها به IP hash روی یک backend

Answer

حذف keep-alive و باز کردن connection جدید برای هر درخواست

Question 47

الگوریتم peak EWMA (در Finagle و Linkerd) چه ویژگی‌ای نسبت به میانگین ساده latency دارد؟

Accepted Answer

به افزایش latency فوراً واکنش نشان می‌دهد اما در کاهش آن محتاط است، و با p2c ترکیب می‌شود

Answer

فقط بیشترین latency تاریخی هر backend را برای همیشه نگه می‌دارد

Answer

latency را نادیده می‌گیرد و فقط تعداد connectionها را می‌شمارد

Answer

همه backendها را هر ثانیه به ترتیب latency مرتب می‌کند

Question 48

سرویس به‌صورت active-active در ۳ region با ترافیک برابر اجرا می‌شود. برای تحمل از دست رفتن یک region، حداکثر utilization عادی هر region تقریباً چقدر باشد؟

Accepted Answer

حدود ۶۶٪ (منهای headroom)، چون هر region باقی‌مانده باید ۱.۵ برابر بار بگیرد

Answer

حدود ۹۰٪، چون GSLB بار اضافه را مدیریت می‌کند

Answer

حدود ۳۳٪، چون هر region باید کل ترافیک را بگیرد

Answer

حدود ۵۰٪، چون همیشه باید نیمی از ظرفیت خالی باشد

Question 49

LB شما در حالت TLS passthrough بر اساس SNI بین tenantها route می‌کند. با فعال شدن Encrypted Client Hello (ECH) در کلاینت‌ها چه تغییری لازم است؟

Accepted Answer

SNI واقعی رمز است و فقط public name بیرونی دیده می‌شود؛ LB باید کلید ECH را داشته باشد (client-facing server)

Answer

هیچ تغییری لازم نیست چون ECH فقط body درخواست HTTP را رمز می‌کند

Answer

LB باید به‌جای SNI بر اساس IP مقصد هر tenant route کند، بدون نیاز به کلید

Answer

ECH باعث می‌شود اتصال TLS به TCP ساده بدون رمز downgrade شود

Question 50

kube-proxy در حالت iptables چگونه backend را انتخاب می‌کند و حالت IPVS چه چیزی اضافه می‌کند؟

Accepted Answer

iptables به ازای هر connection به‌صورت تصادفی احتمالاتی انتخاب می‌کند؛ IPVS الگوریتم‌هایی مثل least connection و lookup سریع‌تر دارد

Answer

iptables به ازای هر درخواست HTTP با least request انتخاب می‌کند؛ IPVS فقط round robin دارد

Answer

iptables بر اساس header `Host` route می‌کند؛ IPVS بر اساس cookie

Answer

iptables همیشه اولین پاد لیست را انتخاب می‌کند؛ IPVS آخرین پاد را