Python Hints

#تجربه

از طرف یک شرکت اومدن، کار استارتاپی داشتند حالا مشتری بین‌المللی پیدا شده براشون می‌خوان uptime, high availability, ... رو بالا ببرند.
چرا ؟
چون توی قرارداد، باید بگن که چه مقدار uptime دارند (معروف‌ترین میزان 99.99% هست که یعنی سالانه ۱ ساعت می‌تونند سرور رو down داشته باشند)
این شامل همه‌ی موارد میشه، آپگرید، جابجایی سرور و ...

این بین که داشتم با نیروها صحبت می‌کردم و مشاوره و همفکری داشتیم، متوجه شدم migration ها یکی از معضلات خواهد بود.

فرض کنید، شما سیستم رو به بهترین شکل چیدید. Load balancer, k8s , ... و برای دپلوی هم rolling update رو گذاشتید.
حالا فرض کنید، قراره برای یک فیچر جدید، یک ستون به جدول user اضافه کنید که به محض لاگین یا اولین استفاده کاربر باید پر بشه ؟

توی rolling update، شما وضعیتی خواهید داشت که هم نسخه قدیمی و هم نسخه جدید همزمان بالا هستند و دارن به کاربر پاسخ می‌دهند :
اگر نسخه قدیمی اجرا باشه models, database با هم نمی‌خونه تازه اگر این ستون not null هم باشه که باید پر بشه ولی منطق این کد توی ورژن قبلی کدها نیست و خطا .‌‌...

اگر نسخه جدید هم اجرا بشه که نیاز به تغییرات دیتابیس داره.

یک راهکار اینه که کلاً نسخه قدیمی رو خاموش کنید (همزمان همش رو) و نسخه جدید رو جایگزین کنید که خب ازون ۱ ساعت downtime با ارزش میزان زیادی رو از دست می‌دید.

یک راهکار multistep migration هست، که مثلاً توی مثال بالا یک ستون nullable تعریف کنید، ولی توی منطق کد مطمئن بشید که هیچوقت null نمونه بعد که ورژن قدیمی کامل از بین رفت، یک migration دیگه بنویسید که دیگه ستون nullable نباشه و مجدد دپلوی کنید.

دیدم بچه‌های این شرکت با این موضوع آشنایی نداشتند گفتم بگم، صرف اینکه HA, K8s, Replica, ... تعریف می‌کنید مشکل downtime شما حل نمی‌شه، فقط بهتر می‌شه.

اضافه کنم، مشکل شما وقتی حادتر می‌شه که ci/cd هم دارید و پروژه توی قدم‌های اولش هست، کلی فیچر و تغییرات هم قراره اضافه بشه


پ.ن:
این موضوع توی مصاحبه‌ها جزو سوالات مهم هست.

👍68❤10✍8🤷‍♀1👏1

www.tgoop.com/pyHints/676

8.38K viewsedited  Nov 11, 2024 at 08:54

#تجربه

از طرف یک شرکت اومدن، کار استارتاپی داشتند حالا مشتری بین‌المللی پیدا شده براشون می‌خوان uptime, high availability, ... رو بالا ببرند.
چرا ؟
چون توی قرارداد، باید بگن که چه مقدار uptime دارند (معروف‌ترین میزان 99.99% هست که یعنی سالانه ۱ ساعت می‌تونند سرور رو down داشته باشند)
این شامل همه‌ی موارد میشه، آپگرید، جابجایی سرور و ...

این بین که داشتم با نیروها صحبت می‌کردم و مشاوره و همفکری داشتیم، متوجه شدم migration ها یکی از معضلات خواهد بود.

فرض کنید، شما سیستم رو به بهترین شکل چیدید. Load balancer, k8s , ... و برای دپلوی هم rolling update رو گذاشتید.
حالا فرض کنید، قراره برای یک فیچر جدید، یک ستون به جدول user اضافه کنید که به محض لاگین یا اولین استفاده کاربر باید پر بشه ؟

توی rolling update، شما وضعیتی خواهید داشت که هم نسخه قدیمی و هم نسخه جدید همزمان بالا هستند و دارن به کاربر پاسخ می‌دهند :
اگر نسخه قدیمی اجرا باشه models, database با هم نمی‌خونه تازه اگر این ستون not null هم باشه که باید پر بشه ولی منطق این کد توی ورژن قبلی کدها نیست و خطا .‌‌...

اگر نسخه جدید هم اجرا بشه که نیاز به تغییرات دیتابیس داره.

یک راهکار اینه که کلاً نسخه قدیمی رو خاموش کنید (همزمان همش رو) و نسخه جدید رو جایگزین کنید که خب ازون ۱ ساعت downtime با ارزش میزان زیادی رو از دست می‌دید.

یک راهکار multistep migration هست، که مثلاً توی مثال بالا یک ستون nullable تعریف کنید، ولی توی منطق کد مطمئن بشید که هیچوقت null نمونه بعد که ورژن قدیمی کامل از بین رفت، یک migration دیگه بنویسید که دیگه ستون nullable نباشه و مجدد دپلوی کنید.

دیدم بچه‌های این شرکت با این موضوع آشنایی نداشتند گفتم بگم، صرف اینکه HA, K8s, Replica, ... تعریف می‌کنید مشکل downtime شما حل نمی‌شه، فقط بهتر می‌شه.

اضافه کنم، مشکل شما وقتی حادتر می‌شه که ci/cd هم دارید و پروژه توی قدم‌های اولش هست، کلی فیچر و تغییرات هم قراره اضافه بشه


پ.ن:
این موضوع توی مصاحبه‌ها جزو سوالات مهم هست.

BY Python Hints