چطوری زیرساخت موری رو با تیم فنی کوچیک مدیریت کردیم؟!

* به دلیل این که در این پست از ادبیات فنی استفاده شده‌است، ممکن است کلماتی باشند که فینگلیش نوشته‌ شده‌باشند.

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

تیم فنی موری در حال حاضر از ۲نفر -رضا و اکبر- تشکیل شده. کارهای این تیم کوچک عبارت‌اند از:

• پیاده‌سازی و نگه‌داری میکروسرویس‌هایی که ۴۰۰هزار محصول موری بر روی آن‌ها ذخیره و آپدیت می‌شوند
• نگه‌داری و پیشرفت‌های مختلف سرچ اِی‌آی موری
• پیاده‌سازی فیچرهای جدید سایت
• پیشرفت مدل‌های هوش مصنوعی

با توجه به پیچیدگی ذاتی که محصول موری داره، شاید یکی از اصلی‌ترین تصمیم‌های فنی ما این باشه که «زیرساخت‌مون رو چطور مدیریت کنیم؟». این مساله اولش خیلی آسون به نظر میاد ولی هرچقدر بیشتر بگذره و کارها جدی‌تر بشه اهمیتش بیشتر و جابجایی سخت‌تر میشه؛ پس مهم‌ه که یه تیم تکنولوژی‌محور از همون اول به مساله‌ی زیرساخت خوب فکر کنه. راه‌حلی که ما انتخاب کردیم استفاده از ساختار میکروسرویسی بر روی زیرساخت هم‌روش است.

مساله‌هایی که ما در طول این چند ماه به اون‌ها برخوردیم و کاری که برای اون‌ها می‌کنیم این‌هاست:

• توی هم‌روش ما تونستیم یه ساختار میکروسرویسی ترتمیز شکل بدیم. امکان این که بتونیم هر سرویس رو به شکل جدا بالا بیاریم، هر سرویس ریسورس، کانفیگ و لاگ‌‌های خودش رو داشته باشه.
• سرویس مانیتورینگ
• سناریویی رو در نظر بگیرید که یه روز می‌بینید بله سایت کند شده. شما احتمالا تو ذهن‌تون این میاد که «یاخدا، من ۵۰تا سرویس دارم که هرکدوم یه کار می‌کنن و از هفته پیش ۱۰تا دیپلوی داشتم، چطوری بفهمم چه اتفاقی افتاده؟». چیزی که تو این سناریو نیاز دارید چیه؟ احتمالا این‌هاست:
• احتمالا نیاز به تِرَک کردن حالت‌های خاص دارید. برای این کار احتمالا نیاز به این دارید که بدونید هرسرویس چیه، کجاست، و لاگ‌سرویسی داشته‌باشید که ببینید چی میگه.
• احتمالا تو قدم بعد می‌فهمید یه جایی باتِلنک شده، برای این که مشکل باتلنک رو پیدا کنید نیاز به سرویس مانیتورینگ دارید؛‌ سرویسی که لودی که روی رم، سی‌پی‌یو و نِتوُرک هرکدوم از سرویس‌ها افتاده رو چک بکنه، شاید تراتل کرده باشید یا رم کم آورده باشید.
• سرویس آلرتینگ: یه ضرب‌المثل هست که میگه یه تیم فنی بدون سیستم مانیتورینگ و آلرتینگ شب یه خواب راحت هم نمی‌تونه داشته باشه. دو مدل آلرتینگ باید داشته باشیم: ۱- یکی وقتی لود روی یه سرویس از یه حدی بالاتر میره. ۲- وقتی یه جای سیستم در حال ارور خوردن‌ه. برای حالت اول نیاز داریم روی هر سرویس با توجه به کاربرد اون سرویس پالیسی تعریف کنیم. و برای حالت دوم نیاز به سرویس سنتری برای گرفتن آلرتینگ‌ها.
• امکان تغییر ریسورس راحت هر سرویس: تغییر دادن مقدار ریسورس هر سرویس کاری‌ه که ممکن‌ه هرروز براتون پییش بیاد. ما با استفاده از سرویس دارکوب هم‌روش این کار رو به ۲ شکل انجام میدیم.
• تغییر دادن استاتیک ریسورس سرویس‌ها
• اسکیل هوریزنتال سرویس زیر لود: هر محصول فنی احتمالا چند تا سرویس داره که عملیات‌هایی با لود محاساباتی زیاد دارند، برای این سرویس‌ها ما از سرویس HPA هم‌روش استفاده می‌کنیم. این سرویس به این شکل کار می‌کنه که اگر لود سرویس از حدی بیشتر بشه، زیرساخت یک instance از سرویس به سرویس قبلی اضافه می‌کنه و لودبالانسینگ روی instanceها اتفاق میفته.
• ما از ۲دسته امکانات دیگه هم استفاده می‌کنیم که برای طولانی‌تر نشدن متن، خلاصه بهشون اشاره می‌کنیم.
• اولی: سرویس CI/CD و رجیستری. از این سرویس برای دیپلویمنت‌های سرویس‌ها استفاده می‌کنیم.
• دوم: مساله‌ی اِستِیبِلیتی، بَکاپ و امنیت سرویس‌ها.

ما تو این پست تلاش کردیم به شکل کلی اما دقیق، همه‌ی بخش‌های مختلفی رو که در طی ساختن موری تا به امروز برامون مساله بود و مدل حل آن‌ها رو توضیح بدیم. امیدواریم این پست به تیم‌های استارتاپی دیگه هم کمک کنه تا بتونن محصول خوبی توسعه بدهند. و: با تشکر دوستان کاردرست‌مون در هم‌روش!