داستان ما

پی پینگ - payping

اتفاق دوم بحث پی پینگ هست، زمانی که پی پپینگ به ما مراجعه کرد از یک ساختار ابری استفاده می کرد که سرویس دیتابیس رو هم بهشون ارائه می‌داد. اما اون ها بنا به هر دلیلی تصمیم گرفته بودن که سرویسشون رو دیگه استفاده نکنن یعنی دیگه سرویس دهی نکن به نام abar cloud و دنبال جایگزین می گشتن، یک جایگزین پیدا کرده بودن به نام آی ون اون آی ون مشکلش این بود که خارج از کشور بود و به صورت دلاری پول می گرفت و این هم به لحاظ هزینه، هم به لحاظ سختی پرداختش باعث شد که بیان سراغ ما. ما اول از همه بررسی کردیم که اینا به چه دیتابیسی احتیاج دارند سه مدل دیتابیس در واقع نیاز داشتن هم PostgreSQL هم MySQL و هم MongoDB که خب بررسی هایی که داشتیم این بود که واقعا باید از هر سه نوع استفاده کنن. به عنوان مثال سیستمی که خودشون نوشته بودن مناسب بود که با PostgreSQL باشه ولی خب از طرف دیگه سیستم وردپرس رو استفاده می کردن برای بلاگ، پس منطقی بود که از هم MySQL استفاده کنن. برای سیستم لاگینگ چون از معماری میکرو سرویس استفاده می کردن پیشنهاد ما هم این بود که از یک دیتا بیس NoSQL مثل MongoDB استفاده کنند لذا ما چالش اول مون این بود که بتونیم هر سه این ها رو ساپورت کنیم و به عنوان سرویس بتونیم بهشون ارائه بدیم.

اما از اون جایی که این ها، تفاوت خیلی زیادی با هم دارن و هر کدوم نیازمندی های خاص خودشونو دارن، ما شروع کردیم به اینکه اول از همه  یه سری تست خودمون بگیریم روی ساختار پنکیک و بعد از اینکه مطمئن شدیم جواب میده این رو بهشون ارائه دادیم. به علاوه توی زمینه کلاسترینگ برای کلاسترینگ دیتابیس بیشتر پی پینگ از ما سرویس گرفته به دلیل اینکه نیاز داشت که داده ها حتما به صورت reliable ذخیره بشه، یعنی جدا از بحث اسکیل کردن، این که داده ها حتما ذخیره شده باشه و اون بحث HA براشون خیلی مهم بود. ما از سیستم دیفالت PostgreSQL استفاده کردیم برای Replication و این ساپورت اصلی رو خودشون توی نرم افزارشون به وجود آوردن که خب کوئری های read رو می فرستادن سمت اسلو و رایت و فقط سمت مستر ارسال می شد؛ ولی خب ما سیستممون به نحوی داشت کار می کرد که اینا هر زمانی که دوست داشتن می تونستن یک Replica از نوع read به کلاسشون اضافه کنن که در نهایت بتونن اگر نیاز به اسکیل هم باشه از این طریق سیستمشون رو اسکیل کنند.

از طرفی یه معضل اساسی هم که اینا داشتن بحث بکاپ بود داده به صورت واقعا زیادی داشت رشد می کرد دیگه مدل دامپ گرفتن تقریبا جواب نمیداد همون طور که خب خیلی از ما مشتریان دیگه داشتیم که حداقل باهاشون صحبت می کردیم مثلا فرض کن دیگه شده بود شصد یا هفتصد صد گیگ دیتا بعد اینا شب به شب تازه بک آپ می گرفتن و این بک آپ شون تا میومدن آپ لود کنن روی یک سرور که روی یک دیتا سنتر دیگه باشه عملا ده ساعت طول می کشید. خب ما این مشکل رو اومدیم با استفاده از اون زیرساخت خودمون حل کردیم بک هارد رو به صورت یک ساعته بردیم سمت Incremental. داستانی که اتفاق افتاد و تونستیم یک سیستم بک آپ در واقع تایم لاین (حالا ما خودمون اسمشو گذاشتیم) شبیه به همون Point-in-Time Recovery در دیتا بیس، که ما با file system و اسنپ شات ها اومدیم این سیستم رو راه اندازی کردیم به صورت فوق العاده ای جواب می‌داد و کمک دست اینا شد حتی در سیستم دولپشون.

این جور بهتون بگم که این ها برای ساختن دیتابیس های بخش استیجینگ شون خب همیشه مشکل داشتن ولی با این شیوه ای که ما داشتیم و براشون ایجاد کردیم و هم کل سیستم پنکیک رو هم به صورت API در اختیارشون قرار داده بودیم این ها در همون لحظه ای که می خواستن تست بگیرن رو استیجینگ میومدن آخرین ورژن پروداکشن شون رو ازش fork می گرفتن و نهایتا در عرض چند دقیقه شاید بعضی وقتا به دقیقه هم نمی رسید داده های کاملا به روز می شد، بدون ریسک؛ یعنی اینکه هر اتفاقی رو اون دیتا بیس می افتاد دیگه هیچ تاثیری روی پروداکشنشون نداشت و این شد که هزینه آماده سازی یک محیط استیجینگ به شدت از لحاظ زمانی و از لحاظ مالی براشون کاهش پیدا کرد و اینکه خب می تونستن هر موقع هم خواستن باز اون پنکیک رو کلا دلیتش کنن و دیگه هزینه هم بابت resource پرداخت نکنن.

حالا برای جمع بندی بخوام بگم ما به پی پینگ در دو بخش کلی کمک کردیم یک در زمانی که هیچ سرویس مشابه ایرانی برای دیتابیس نداشتن ما اومدیم دیتا بیس رو به عنوان سرویس بهشون ارائه دادیم در سه سطح PostgreSQL و MySQL و MongoDB؛ ضمن اینکه در قسمت بعدی با استفاده از مدل بک آپ گیرمون هم تونستیم مشکل بکاپشون رو حل کنیم که از لحظ حجمی دیگه با دامپ گرفتن و لاجیکال کپی کردن جواب نمی‌داد. از طرفی با استفاده از همون بحث fork، دیتابیس رو به وجود آوردیم که توی ساخت محیط استیجشون هزینه و زمان رو به شدت کاهش داد.

آجیل حسینی

سیستم آجیل حسینی این جوری بود که، زمانی که کمپین می خواستن برن با مشکل کندی سرعت مواجه می شدن و سایت عملا دیگه بالا نمی‌اومد. برای رفع این مشکل resource رو از جهت سخت افزاری چندبار برده بودن بالا ولی جواب نداده بود که با ما تماس گرفتن؛ کاری که ما کردیم این بود که در درجه اول اومدیم سرور دیتابیس رو از سرورPHP جدا کردیم. هدف اصلی این بود که محدودیتی که در دسترسی به هارد اتفاق می افته با این قضیه دو برابر کنیم. چون شما موقعی که داری درخواست های مربوط به خود سایت یا عکس ها رو به همون هاردی ارسال می کنی که دیتابیس روی اون هارد داره سرویس داده می شه، با محدودیت I/O مواجه میشی در نتیجه هر چقدر cpu یا رم رو هم اضافه کنی باز اون نتیجه دلخواهت رو نمی تونی بگیری چون محدودکنندت جای دیگه است.

پس ما در درجه اول این رو جدا کردیم و از اون جایی که خب خودمون سرویس دهنده پایگاه داده ابری بودیم از پنکیک استفاده کردیم که علاوه بر اینکه حالا یک هارد مناسب دیتابیس داره بحث بک آپ رو هم هندل می کنه و دیگه این نگرانی بکاپ شون هم ازشون گرفتیم. تو زمینه خود سرویسشون هم که از پرستاشاپ استفاده می کردن، اومدیم با استفاده از PHP FPM به جای ماژول آپاچی، سعی کردیم که قابلیت تنظیمات رو بیشتر کنیم و اونو tune کنیم. با این کار اون رو تقریبا به نسبت قبل بهتر کردیم؛ اما در نهایت یک ایده دیگه هم به ذهنمون رسید که بیایم قسمت ادمین سایت رو از قسمت مشتری ها جدا کنیم. این کار یکم چالش داشت، هدف این بود که باز هم بتونیم ریکوست ها رو دسته بندی کنیم و تقسیم بندی کنیم روی سرورهای مختلف.

اما دلیل اینکه ادمینشون خیلی ریکوئست داشت این بود که این ها میومدن اون موقعی که می خواستن و حجم فروششون هم چون بالا بود، از حالات سیستم های جدیدتری استفاده می کردن و ریکوئست های زیادی برای زمانی که می خواستند یک سفارش رو جمع کنن سمت بک اند ارسال می کردن. لذا ما اومدیم قسمت ادمین که در واقع همان انبار باشه (مصرف کنندش انبار بود حالا خیلی نگیم ادمین) رو از قسمت مشتری ها جدا کردیم در نتیجه کل ریکوئستی که از سمت مشتریان میومد برای کمپین یا برای خرید، می رفت روی یه سرور، که باز داده ها هم پشت صحنه asset ها و اون عکس ها از روی یه سرور سرویس دهی میشه و دیتابیس روی سرور دیگه. پس در نهایت سه تا کامپوند اصلی یا یک سیستم رو ما به سه قسمت اصلی تقسیم کردیم، یکی ادمین، یکی مشتری ها و یکی هم دیتابیس و تمام. در نهایت تونستیم ارتباطاتی بین اینا برقرار کنیم که چالش هایی توی این زمینه داشتن، از جمله فرض کن حالا file sharing بین این ها که اون دیتا چه جوری به دوتا سرویس بدهیم چالش ها رو هم حل کردیم و نهایت به این رسیدیم که تمام کمپین هاشون که دیگه سخت ترین کمپین هاشون و فروششون در زمان عید نوروز بود رو تونستن به صورت عالی برگزار کنن. ضمن اینکه باید بگم که ما از سخت افزار هم البته کمک گرفتیم یعنی در بعضی موارد، فرض کن پورتی که قبلا یک گیگ بود رو اومدیم با پورت tenG جایگزین کردیم، بعد ارتباطات بین دیتابیس رو اومدیم به نزدیک ترین حالت ممکن در کنار همون سرور PHP قرار دادیم و در نهایت دیگه با مجموعه ای از این کارها تونستیم راهکار نهایی رو پیدا کنیم.