migration story 2: داستان مهاجرت (۲) فیدیبو

در مجموعه پست‌های داستان مهاجرت، در این پست به بررسی مهاجرت پلتفرم کتابخوانی فیدیبو، خواهیم پرداخت. داستان این مهاجرت مربوط به سال ۱۳۹۶ شمسی است، زمانی که تیم فنی و مدیریتی فیدبو دچار نوعی پوست اندازی شد و تیم فنی جدید، مسیولیت سخت انتشار نسخه بعد از حدود چهارسال را داشت. نقطه عطف این داستان برای مهندسین نرم افزار، مهاجرت به معماری میکروسرویس، برای اولین بار در مقیاس تجاری در فیدیبو و از اولین‌ها در اکوسیستم ایران، می‌باشد. 

این روایت بر اساس تجربه شخصی نویسنده و بر اساس داده‌های واقعی ایجاد شده است

اگر تمایل دارید، مطالب بیشتری در حوزه مهاجرت نرم افزاری و تغییر معماری، مطالعه کنید، لطفا از داستان مهاجرت ۱ بازدید نمایید.

حال و هوای فیدیبو ۱۳۹۶

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

این تغییرات مدیریتی، همراه با رویکردهای خاص مدیر تازه‌وارد، باعث شد که از تیم پیشین فیدیبو تنها سه نفر در شرکت باقی بمانند؛ آن هم افرادی که هیچ‌یک تجربهٔ مدیریتی نداشتند. مابقی مدیران یا کاملاً کناره گرفته بودند یا همکاری با آنها ادامه نیافته بود.

این اوضاع، در کنار عدم انتشار نسخهٔ جدید اپلیکیشن فیدیبو، شرایط را برای مدیریت جدید بسیار دشوار کرده بود؛ چراکه مسئولیت پروژه‌های ناتمام مدیران قبلی و وظایف افرادی که دیگر در تیم حضور نداشتند، بر دوش ایشان افتاده بود.

در این مطلب عامدانه از نام بردن، افراد پرهیز شده تا بیشتر تمرکز روی موضوعات آموزشی باشد

لازم به توضیح است که تیم فیدیبو اصولا تیم کوچک ولی کارآمدی بود که با تغییرات مدیریتی، بزرگتر شده و محل فعالیت سنتی این تیم که دفتر یکی از شهر کتاب‌های معروف بود، به گاندی تغییر پیدا کرد. علاوه بر این دست مدیر جدید، در بودجه بازتر شده بود و این سبب شده بود تا بتواند افراد دارای توانمندی بالاتر را جذب کرده و در تیم از همکاری با ایشان بهره برد.

معماری نرم افزار فیدیبو در آن زمان موارد زیر را شامل می‌شد:

در آن زمان فرآیندهای مربوط به devops به شیوه امروزی متداول نبود و بیشتر اپلیکیشن‌ها به صورت بومی و در سیستم ‌عامل سرو می‌شدند. با این حال بخش عمده زیرساخت فیدیبو، در docker بود اما بدون پایپ‌لاین و سایر فرآیندهای devop

بررسی نیازمندی و شرایط

1. یکی از ایرادات وارد بر معماری تشریح شده فیدیبو، قدیمی بودن استک‌های آن بود. به عنوان مثال فریم ورک phalcon در آن زمان منسوخ شده بود و بیشتر laravel جایگزین آن گردیده بود.
2. خیلی از کتابخانه‌های بروز و کاربردی، قابل استفاده در استک قدیمی نبود، زبان golang تغییرات زیادی کرده بود و امکان بروزآوری بیشتر بخش‌ها وجود نداشت.
3. عدم تناسب مقیاس به لحاظ حجم کاربر و حجم محتواهای پلتفرم با برنامه ریزی‌های پیشرو.
4. دشواری جذب نیرو برای تسلط بر اپلیکیشن موجود به علت منسوخ شدن تکنولوژی

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

صورت مساله جدید کسب و کار

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

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

راهکار برای فیدی پلاس

برای پیاده سازی این سرویس، دو راهکار وجود داشت: 

۱) توسعه بر مبنای پلتفرم قدیمی و اضافه کردن این قابلیت، در اپلیکیشن‌های موجود اندروید و اپل

۲) توسعه بر مبنای سرویس جدید (میکروسرویس) خارج پلتفرم موجود و اتصال پلتفرم قدیمی (legacy)

لازم به توضیح‌است که هرکدام از راهکارهای فوق دارای معایب و مزایای مخصوص خود هستند ولی به عنوان کسی که ادامه کسب و کار، دغدقه اصلی شما است احتمالا راهکار اول دارای ریسک پایین‌تری می‌باشد

با وجود دلایل گفته شده و بنا به اصرار تیم جدید فنی و تشخیص مدیریت وقت، تصمیم بر اجرای راهکار دوم یعنی حرکت به سمت معماری میکروسرویس، گرفته شد. مهم‌ترین دلیل این تصمیم را می‌توان در بروز بودن تکنولوژی و امکان استفاده از کتابخانه‌های روزآمد، در نظر گرفت. علاوه بر این موضوع جذب نیرو، در این تکنولوژی‌های جدیدتر به مراتب، راحت‌تر بود

بر مبنای تصمیم اتحاذ شده، قرار شد، تا پیاده سازی میکروسرویس جدید، با تکنولوژی زیر صورت پذیرد:

بعد از پیاده سازی نسخه بک‌اند اولیه با تکنولوژی‌های فوق، بنا بر تست MVP روی اپلیکیشن اندروید و iOS فیدیبو شد. در تست اولیه سناریوی فنی موفق بود اما بنا به ملاحظات تیم فروش mvp باید دچار تغییراتی می‌شد تا قابل رقابت با سایر رقبای بازار داخلی باشد.

چالش‌های انتشار نسخه اصلی

فرایند تدوین و توسعهٔ محصول حدود شش ماه به طول انجامید؛ اما پیش از انتشار، بر اساس تشخیص مدیر فنی، مقرر شد تست‌های بار (load test) و نقطهٔ شکست (crash point) انجام شود تا حداکثر ظرفیت سرویس و آستانهٔ ازکارافتادگی آن مشخص گردد.
نتایج تست‌های اولیه کاملاً شوک‌آور بود؛ سرویس با تنها ۱۰۰۰ کاربر همزمان از دسترس خارج می‌شد، در حالی که در آن دوره، حداقل ترافیک پیش‌بینی‌شده سه برابر این رقم برآورد می‌گردید. برای آگاهی از جزئیات فنی این موضوع، میتوانید به مطلب «انتقال تجربهٔ الاستیک‌سرچ» مراجعه کنید.

با اجرای تمهیدات لازم و کلاستر کردن پایگاه دادهٔ الاستیک‌سرچ، این نارسایی تا حد قابل قبولی برطرف شد و برای نخستین بار در فیدیبو، ظرفیت پذیرش چندبرابری کاربران همزمان فراهم گردید.

آخرین تمهیدات و ضروریات روز انتشار

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

علت این کندی، ناهماهنگی در مقدار timeout میان PHP نسخهٔ ۵ در اپلیکیشن قدیمی (legacy) و PHP نسخهٔ ۷.۳ در میکروسرویس فیدی‌پلاس بود. شناسایی ریشهٔ این مشکل نزدیک به چند ساعت زمان برد، اما در نهایت تیم اجرایی موفق شد بر این چالش غلبه کند.

امیدوارم این مطلب برای شما مفید و جذاب بوده باشد؛ خوشحال می‌شویم اگر آن را با دیگران نیز به اشتراک بگذارید.