پویا ثابتی - سپهر اویسی
با گسترش روزافزون صنعت نرم‌افزار، دیگر روش‌ها و سبک‌های سنتی تولید نرم‌افزار، پاسخگوی این نیازمندی‌ها نبوده‌اند. در صنعت تولید نرم‌افزار یکی از دلایل کلیدی موفقیت، معماری استفاده شده برای تولید نرم‌افزار می‌باشد. امروزه می‌بینیم که بسیاری از نرم‌افزارهای تولید شده با وجود داشتن ایده‌های نوین با شکست روبرو می‌شوند. در مقابل نرم‌افزارهایی نیز وجود دارند که ایدهای نسبتا تکراری داشته ولی به علت داشتن معماری نرم‌افزاری قدرتمند به موفقیت‌های بزرگی دست یافته‌اند. دنیای نرم‌افزار هر روزه در حالا تغییر بوده و با توجه به نیازهای جدید، تیم‌های نرم‌افزاری خصوصیت‌های جدیدی را برای نرم‌افزار ایجاد می‌کنند. خصیصه جدید در این صنعت اکثر اوقات نیازمند بهره بردن از روشی است که در گذشته استفاده شده و یا به عنوان یک شرکت پرچم دار یک راه حل جدید برای مشکل به دست آورد. یکی از اقداماتی که میتواند به خوبی در این روند کمک کند بهره بردن از معماری‌های نرم افزارهای مرسوم و پیشرو و یا معماری‌های استفاده شده توسط شرکت‌هایی باشد که تجربیات زیاد در رضایت کاربران داشته‌اند.
در این پست، چند نرم‌افزار و سرویس که توسط شرکت‌های بزرگ تولید شده و توسعه یافته‌اند و همچنین دارای موفقیت‌های بزرگی در حوزه‌های فعالیت خود می‌باشند را بررسی می‌کنیم. متأسفانه تمامی جنبه‌های معماری این شرکت‌ها را نمی‌توان در یک مقاله خلاصه کرد ولی میتوان نقاط قوت هر نرم‌افزار را در پیادهسازی معماری زیر ذره‌بین قرار داد. همچنین برای افزایش دقت بررسی و داشتن فاکتوری برای مقایسه نرم‌افزارها را بر اساس صنعت فعالیت به دسته‌های دوتایی تقسیم کرده تا بتوان در کنار هم برخی چالش‌ها و راه حل‌های به کار گرفته شده در آن نرم‌افزارها را مورد مطالعه قرار داد.
نرم‌افزارها و ابزارهای بسیار زیادی هستند که قطعا بررسی معماری آنها دید جدیدی در مورد سیستم‌های کامپیوتری در اختیار می‌گذارد. در این مقاله 6 مورد از آنها انتخاب شده و در 3 دسته دوتایی مورد بررسی قرار داده می‌شود. این دسته بندی‌ها به شرح زیر می‌باشد:
۱ - سیستم‌های استریم فیلم: Netflix و Amazon Prime Video
۲- سیستم‌های پخش موسیقی: Spotify و Apple Music
۳- سیستم‌های شبکه‌های اجتماعی: Facebook و Twitter
به ترتیب در بخش اصلی به بررسی برخی نکاتی که این نرم‌افزارهای داشته اند میپردازیم.
نتفلیکس سال‌هاست که یکی از بهترین سرویسهای پخش ویدئو مبتنی بر اشتراک آنلاین در جهان است و بیش از 15 درصد از ظرفیت پهنای باند اینترنت جهان را به خود اختصاص داده است. در سال 2019، نتفلیکس در حال حاضر بیش از 167 میلیون مشترک با بیش از 5 میلیون مشترک جدید در هر سه ماهه است و در بیش از 200 کشور فعالیت میکند. به طور خاص، مشترکین نتفلیکس بیش از 165 میلیون ساعت را صرف تماشای بیش از 4000 فیلم و 47000 قسمت در روز می‌کنند. این آمار چشمگیر به ما نشان میدهد که از دیدگاه مهندسی، تیم‌های فنی نتفلیکس چنین سیستم پخش ویدیویی شگفت انگیزی را با در دسترس بودن و مقیاس پذیری بسیار بالا طراحی کرده‌اند تا به مشتریان خود در سطح جهانی خدمات ارائه دهند.
با این حال، تیم‌های فنی نتفلیکس بیش از 8 سال طول کشید تا سیستم‌های فناوری اطلاعات خود را مانند الان داشته باشند. در واقع، دگرگونی زیرساخت در نتفلیکس در آگوست 2008 پس از قطع شدن خدمات در مراکز داده خودش که کل خدمات اجاره DVD را به مدت سه روز متوقف کرد، آغاز شد. نتفلیکس متوجه شد که به زیرساخت قابل اعتماد تری نیاز دارد که هیچ نقطه شکستی ندارد. بنابراین، دو تصمیم مهم گرفته است: انتقال زیرساخت فناوری اطلاعات از مراکز داده خود به یک ابر عمومی و جایگزینی برنامه‌های یکپارچه با اجزای نرم افزاری کوچک قابل مدیریت توسط معماری میکروسرویس‌ها. هر دو تصمیم مستقیماً موفقیت امروز نتفلیکس را شکل داده اند.
نتفلیکس ابر AWS را برای انتقال زیرساخت‌های فناوری اطلاعات خود انتخاب کرده بود زیرا AWSمی‌توانست پایگاه‌های داده بسیار قابل اعتماد، فضای ذخیره‌سازی ابری در مقیاس بزرگ و مراکز داده متعدد در سراسر جهان ارائه دهد. نتفلیکس با استفاده از زیرساخت ابری که توسط AWS ساخته و نگهداری می‌شود، کارهای سنگین غیرمتمایز ساخت مراکز داده را انجام نداد، بلکه بیشتر بر کسب‌وکار اصلی خود یعنی ارائه تجربه کاربر پخش ویدئو با کیفیت بالا تمرکز کرد.
نتفلیکس همچنین یکی از اولین محرک های اصلی معماری میکروسرویس ها است. Microservices مشکلات طراحی نرم‌افزار یکپارچه را با تشویق جداسازی نگرانی‌ها هدف قرار میدهد که در آن برنامه‌های بزرگ توسط ماژولار بودن با کپسوله‌سازی داده‌ها به تنهایی به اجزای نرم‌افزار کوچک‌تر تقسیم می‌شوند. Microservices همچنین به افزایش مقیاس پذیری از طریق مقیاس افقی و پارتیشن بندی حجم کار کمک میکند. مهندسان نتفلیکس با پذیرش میکروسرویس‌ها به راحتی هر سرویسی را تغییر میدهند که منجر به استقرار سریعتر می‌شود. مهمتر از آن، آنها میتوانند عملکرد هر سرویس را ردیابی کنند و به سرعت مشکلات آن را از سایر سرویس های در حال اجرا جدا کنند.
نتفلیکس در معماری خود از خدمات محاسبات ابری آمازون (AWS) و Open Connectاستفاده میکند. هر دو سیستم باید به طور یکپارچه با هم کار کنند تا خدمات پخش ویدیو با کیفیت بالا را در سطح جهانی ارائه دهند. از نقطه نظر معماری نرم افزار، نتفلیکس شامل سه بخش اصلی است: Client، Backend و Content Delivery Network (CDN).
در نتفلیکس Client هر مرورگر پشتیبانی شده در لپ تاپ یا دسکتاپ یا برنامه Netflix در تلفن های هوشمند یا تلویزیون های هوشمند است. نتفلیکس برنامه های iOS و Android خود را توسعه می دهد تا بهترین تجربه مشاهده را برای هر مشتری و دستگاه ارائه دهد. نتفلیکس با کنترل برنامه‌ها و سایر دستگاه‌های خود از طریق SDK خود، میتواند خدمات استریم خود را تحت شرایط خاصی مانند شبکه‌های کند یا سرورهای پربار، به طور شفاف تطبیق دهد.
در قسمت بعدی یعنی Backend شامل سرویسها، پایگاه‌های داده، سیستم‌های ذخیره‌سازی است که به طور کامل بر روی ابر AWS اجرا می‌شوند. Backend اساساً همه چیزهایی را که شامل پخش ویدیوها نمی شود کنترل می کند. برخی از اجزای Backendبا خدمات AWS مربوطه خود به شرح زیر فهرست شده اند:
در قسمت بعدی یعنی Open Connect CDN شبکه‌ای از سرورها به نام Open Connect Appliances (OCAs) است که برای ذخیره و پخش ویدیوهای بزرگ بهینه شده است. این سرورهای OCA در شبکه‌های ارائه دهندگان خدمات اینترنتی (ISP) و مکان‌های تبادل اینترنتی (IXP) در سراسر جهان قرار می‌گیرند. OCAها مسئول پخش مستقیم ویدیوها به مشتریان هستند.
وقتی مشترکین روی دکمه Play در برنامه‌ها یا دستگاه‌های خود کلیک می‌کنند، Client با Backend در AWSو OCAs در Netflix CDN ارتباط برقرار میکند تا ویدیوها را پخش کند نمودار زیر نحوه عملکرد فرآیند پخش را نشان میدهد:
۱- بخش OCAها به طور مداوم گزارش‌های سلامتی در مورد وضعیت بار کاری، مسیریابی و ویدیوهای موجود خود را به سرویس Cache Control در حال اجرا در AWS EC2 ارسال می‌کنند تا برنامه‌های Playback آخرین OCAهای سالم را به مشتریان به روز کنند.
۲- یک درخواست Play از دستگاه مشتری به سرویس Playback Apps Netflix که روی AWS EC2 اجرا می‌شود ارسال می‌شود تا آدرس‌هایی را برای پخش ویدیوها دریافت کند.
۳- سرویس Playback Apps باید مشخص کند که درخواست Play برای مشاهده ویدیوی خاص معتبر است. چنین اعتبار سنجی‌هایی طرح مشترک، مجوز ویدیو در کشورهای مختلف و غیره را بررسی میکند.
۴- سرویس Playback Apps با سرویس Steering نیز در AWS EC2 اجرا می‌شود تا لیست سرورهای OCA مناسب ویدیوی درخواستی را دریافت کند. سرویس فرمان از آدرس IP مشتری و اطلاعات ISPها برای شناسایی مجموعه‌ای از OCAهای مناسب برای آن مشتری استفاده میکند.
۵- از لیست چندین سرور OCA مختلف که توسط سرویس Playback Apps برگردانده شده است، مشتری کیفیت اتصالات شبکه به این OCAها را آزمایش میکند و سریع‌ترین و مطمئن‌ترین OCA را برای درخواست فایلهای ویدئویی برای پخش انتخاب میکند.
۶- سرور OCA انتخاب شده درخواست‌های مشتری را می‌پذیرد و شروع به پخش فیلم میکند.
همانطور که در بخش‌های قبلی توضیح داده‌ام، Backend تقریباً همه چیز را کنترل میکند، از ثبت‌نام، ورود به سیستم، صورت‌حساب گرفته تا وظایف پردازشی پیچیده‌تر مانند رمزگذاری ویدیو و توصیه‌های شخصی‌شده. نتفلیکس به منظور پشتیبانی از حجم کاری سبک و سنگین که بر روی یک زیرساخت اساسی اجرا می شود، معماری میکروسرویس‌ها را برای سیستم مبتنی بر ابر خود انتخاب کرده است. در شکل زیر یک معماری میکروسرویس‌های احتمالی در Netflix را نشان میدهد که از چندین منبع آنلاین استخراج شده است.
۱- یک Client یک درخواست Play به Backend در حال اجرا در AWSارسال میکند. این درخواست توسط متعادل کننده بار AWS (ELB) رسیدگی می‌شود.
۲- سرویس AWS ELB آن درخواست را به API Gateway Service در حال اجرا در نمونه‌های AWS EC2 ارسال میکند. این مؤلفه که Zuul نام دارد توسط تیم نتفلیکس ساخته شده است تا امکان مسیریابی پویا، نظارت بر ترافیک و امنیت، انعطاف پذیری در برابر خرابی‌ها در لبه استقرار ابر را فراهم کند. این درخواست برای برخی از فیلترهای از پیش تعریف شده مربوط به منطق تجاری اعمال می‌شود، سپس برای رسیدگی بیشتر به API Application ارسال می‌شود.
۳- جزء API Application منطق اصلی کسب و کار پشت عملیات نتفلیکس است. انواع مختلفی از API مربوط به فعالیت‌های مختلف کاربر مانند Signup API، Recommendation API برای بازیابی توصیه‌های ویدئویی وجود دارد. در این سناریو، درخواست ارسال شده از API Gateway Service توسط Play API مدیریت می‌شود.
۴-رابط Play API یک میکروسرویس یا دنباله ای از میکروسرویس‌ها را برای انجام درخواست فراخوانی میکند. سرویس Playback Apps، سرویس Steering و سرویس Cache Control به عنوان یک میکروسرویس دیده می‌شود.
۵- میکروسرویس‌ها اکثرا برنامه‌های کوچک بدون تابعیت هستند و میتوانند با هم در ارتباط باشند. برای کنترل خرابی آبشاری و فعال کردن انعطافپذیری، هر میکروسرویس توسط Hystrix از فرآیندهای تماس گیرنده جدا می‌شود. نتیجه آن پس از اجرا میتواند در یک کش مبتنی بر حافظه ذخیره شود تا امکان دسترسی سریعتر برای درخواست‌های با تأخیر کم حیاتی فراهم شود.
۶- میکروسرویس‌ها می توانند داده‌ها را در یک فروشگاه داده در طول فرآیند خود ذخیره یا از آن دریافت کنند.
۷- میکروسرویس‌ها میتوانند رویدادهایی را برای ردیابی فعالیت‌های کاربر یا سایر داده‌ها به خط لوله پردازش جریان برای پردازش بلادرنگ توصیه‌های شخصی یا پردازش دسته‌ای وظایف هوش تجاری ارسال کنند.
۸- داده‌هایی که از خط لوله پردازش جریان خارج می‌شوند میتوانند برای سایر فروشگاه‌های داده مانند AWS S3، Hadoop HDFS، Cassandra و غیره پایدار باشند.
معماری‌های توصیف‌شده به ما کمک می‌کنند تا درکی کلی از نحوه سازماندهی و کار با هم قطعات مختلف برای پخش جریانی ویدیوها به دست آوریم. با این حال، برای تجزیه و تحلیل در دسترس بودن و مقیاس پذیری معماری ها، باید بیشتر به هر جزء مهم بپردازیم تا ببینیم که چگونه تحت بارهای کاری مختلف عمل می کند. که در بخش بعدی به آن پرداخته خواهد شد.
۱ . در دسترس بودن بالا
طبق تعریف، قابلیت دسترسی یا دسترس پذیری در اصطلاح یعنی داده و سرویسها در هر زمانی که نیاز به آن داریم در دسترس باشند. میتوان به گونه‌های دیگر هم این عبارت را معنی کرد و این است که یک سیستم اطلاعاتی همواره در دسترس باشد و بتواند کار خودش را به بهترین شکل ممکن انجام دهد. در طراحی سیستم نتفلیکس، در دسترس بودن سرویسهای استریم بستگی به در دسترس بودن سرویسهای Backend و سرورهای OCA دارد که فایلهای ویدئویی را نگه می‌دارند. هدف خدمات Backend دریافت لیستی از نزدیکترین OCAهای سالم به یک کلاینت خاص است. بنابراین، در دسترس بودن آن به مؤلفههای مختلف مربوط به درخواست پخش بستگی دارد.
۲ . تاخیر کم
تأخیر سرویسهای پخش بیشتر به این بستگی دارد که Play API چقدر میتواند فهرست OCAهای سالم را حل کند و ارتباط مشتری با سرور OCA انتخابی چقدر است. Play API برای همیشه منتظر اجرای میکروسرویس نمی‌ماند، زیرا از دستورات Hystrix برای کنترل مدت زمانی استفاده میکند. با استفاده از حافظه پنهان، انجام این کار میتواند تأخیر قابل قبول را کنترل کند و همچنین خرابی‌های آبشاری برای خدمات بعدی را متوقف کند.
اگر شبکه سرور OCA انتخابی فعلی خراب شود یا سرور بیش از حد بارگیری شود، کلاینت بلافاصله به سایر سرورهای OCA نزدیک با قابل اطمینان‌ترین اتصال شبکه سوئیچ میکند. همچنین میتواند کیفیت ویدیو را برای مطابقت با کیفیت شبکه کاهش دهد تا در صورت مشاهده کاهش در اتصال شبکه کاربر به مشکل نخورد.
۳ . انعطافپذیری
طراحی یک سیستم ابری با قابلیت بازیابی خود از خرابی‌ها یا قطعی‌ها، هدف اصلی نتفلیکس از روز شروع مهاجرت به ابرAWS بوده است. برای شناسایی و رفع خرابی‌ها، API Gateway Service Zuul دارای ویژگی‌های داخلی مانند تلاشهای مجدد تطبیقی است که تماسهای همزمان را بهAPI Application محدود میکند. در عوض، Application API از دستورات Hystrix برای قطع کردن تماسهای میکروسرویس‌ها، توقف خرابی‌های آبشاری و جداسازی نقاط خرابی از دیگران استفاده میکند.
تیم‌های فنی نتفلیکس نیز بهخاطر شیوه‌های مهندسی آشفتگی خود مشهور هستند. ایده این است که خطاهای شبه تصادفی را به محیط‌های تولید تزریق کنیم و راه حل‌هایی برای شناسایی، جداسازی و بازیابی خودکار چنین خرابی‌هایی ایجاد کنیم. خطاها میتوانند تاخیر در پاسخهای اجرای میکروسرویس‌ها، از بین بردن سرویسها، توقف سرورها یا نمونه‌ها و حتی از بین بردن کل زیرساخت یک منطقه باشد. نتفلیکس با معرفی هدفمند شکست‌های واقعی در یک محیط نظارت شده با ابزارهایی برای شناسایی و رفع چنین خرابی‌هایی، میتواند چنین ضعف‌هایی را قبل از ایجاد مشکلات بزرگتر به سرعت کشف کند.
۴ . مقیاس پذیری
مقیاسپذیری افقی نمونه‌های EC2 در Netflix توسط AWS Auto Scaling Service ارائه می‌شود. اگر حجم درخواست افزایش یابد، این سرویس AWS به طور خودکار فعال می‌شود. به طور خاص، نتفلیکس از Titus، یک پلتفرم مدیریت کانتینر منبع باز، برای اجرای حدود 3 میلیون کانتینر در هفته استفاده میکند. علاوه بر این، Titus اجازه میدهد تا کانتینرها در چند منطقه در سراسر قاره‌های مختلف در سراسر جهان حرکت کنند. روش دیگری که استفاده میکند، پیادهسازی microservice است که با اجازه دادن به اجرای موازی وظایف، مقیاسپذیری را افزایش میدهد. در نهایت، با استفاده از ابزارهایی مانند Cassandra و ElasticSearch نیز در دسترس بودن و مقیاسپذیری بالا را بدون هیچ نقطه شکستی ارائه میدهند.
فناوری در چند سال گذشته تغییرات عظیمی را در هر صنعتی ایجاد کرده است، از جمله نحوه گوش دادن به موسیقی. طبق آمار Statista، انتظار می‌رود تعداد کاربران صنعت پخش موسیقی تا سال 2025 به 913.2 میلیون کاربر افزایش یابد. بنابراین، اگر ایدهای برای یک برنامه موسیقی نوآورانه دارید، ممکن است یک فرصت تجاری عالی برای کاوش در موسیقی امروزی باشد.
پلتفرم‌های پخش موسیقی زیادی مانند Spotify، Apple Music، Soundcloudو Tidal وجود دارد. در این بخش ما در مورد Spotify و Apple Musicبیشتر توضیح خواهیم داد. هر دو پلتفرم یک سرویس پخش موسیقی یکپارچه است که امکان دسترسی به میلیون‌ها آهنگ از هنرمندان سراسر جهان را فراهم میکند.
دزدی محتوا به طور جدی صنعت هنرهای نمایشی و موسیقی را تحت تأثیر قرار داده است. Spotifyو Apple Music با هدف اصلی حذف توزیع غیرقانونی، از طریق دادن بستری به اجراکنندگان برای میزبانی آثارشان و دریافت حق امتیاز برای آن، تأسیس شد.
ژوئن 2017، Spotify، 144 میلیون کاربر فعال ماهانه داشت. تا سه ماهه دوم سال 2019 تقریباً دو برابر شد و به 232 میلیون کاربر فعال ماهانه رسید. از این تعداد، کل مشترکین پریمیوم Spotifyبه 100 میلیون یا بیشتر
میرسد. در زمان نگارش این تحقیق، Spotify، ۴۰ درصد از صنعت پخش موسیقی جهانی را در اختیار دارد.
همچنین علاقه‌ی شرکت اپل به صنعت موسیقی از دیرباز با ارائه‌ی برند iPod و سرویس موسیقی اپل در قالبiTunes، مشخص بوده است. اپل یکی از اولین شرکت‌هایی بود که وارد این صنعت پرسود با پتانسیل بالا شد. اما با افول خرید iPod و کاهش استقبال از سرویس موسیقی اپل که در قالب iTunes ارائه می‌شود، در مقابل محبوبیت سرویسهای استریم موسیقی چون اسپاتیفای، سال گذشته اپل را واداشت تا کمپانی بیتس را از آن خود کند.
در مورد این سوال که "چند آهنگ در Spotify وجود دارد؟" ، برنامه Spotifyمیزبان 50 میلیون آهنگ است و شنوندگان به طور متوسط 25 ساعت در ماه در برنامه صرف می‌کنند. ارزش کل تجارت Spotify به 26.5 میلیارد دلار رسیده است. حداقل میتوان گفت، ارزش خالص Spotifyخیره کننده است و میتوان گفت اسپاتیفای پرچمدار این صنعت است.
هر دو برنامه‌ی Spotifyو Apple Music موسیقی خود را در چندین سرور ذخیره می‌کنند. بنابراین وقتی کاربر می‌خواهد به آهنگی گوش دهد، برنامه تلفن همراه از پشتیبان درخواست میکند تا داده‌ها را واکشی کند. و بک‌اند تمام کارهای سنگین را برای یافتن آهنگ‌ها از سرورها و ارسال آنها به دستگاه انجام میدهد. منطق سرور همچنین تمامی وظایف دیگر مانند کار با پایگاه داده‌ها، احراز هویت کاربر، جستجو، پیشنهاد هنرمندان/آلبوم‌ها و به روز رسانی کتابخانه را انجام میدهد.
این روش استریم نیازی به بارگیری فایل‌ها در دستگاه‌ها ندارد. در عوض، موسیقی در بسته‌های کوچک از طریق اینترنت تحویل داده می‌شود و در بافر دستگاه ذخیره می‌شود. بسته‌ها برای جلوگیری از تأخیر بین رویدادهای ارسال و دریافت کوچک نگه داشته می‌شوند، بنابراین موسیقی فوراً پخش می‌شود. در زیر اساسی ترین معماری برنامه پخش موسیقی آورده شده است:
در اینجا چند ویژگی پیشرفته وجود دارد که می‌توانید برای برجسته‌تر کردن برنامه پخش موسیقی اضافه کرد: (که برنامه Spotify همه این کارها را انجام داده است)
یک روش علمی برای اندازه‌گیری همان امتیاز خالص پروموتر (NPS) است. تمایل مشتریان به ارجاع بیشتر خدمات را ارزیابی میکند.
از این آمار درک می‌کنیم که در این صنعت Spotify کارایی خوبی دارد و با تحقیق برای علت آن به این تنیجه رسیدیم که دلیل بزرگ این اختلاف، توانایی Spotify برای سفارشی کردن لیست پخش به دلخواه هر کاربر است. با اینکه این «کشف لیست‌های پخش» یکی از محبوب‌ترین طرفداران است. آنها قبلاً به صورت هفتگی برای هر کاربر ارسال می شدند، اما به لطف محبوبیت آنها،Spotify سرمایه گذاری زیادی کرد و شروع به اشتراک گذاری منظم لیست کشف لیست‌های پخش با کاربران Spotify کرد.
اما Spotify چگونه می‌داند که کدام آهنگ‌ها را به شما ارائه دهد؟ اینجاست که الگوریتم‌ها وارد می‌شوند. از دو مدل زیر برای تنظیم آهنگ‌ها استفاده میکند.
بسیاری از سیستم‌های آنلاین که نیازهای روزانه انسان‌ها را برآورده می‌کنند، نیاز به مطالعه رفتار کاربر دارند. به عنوان مثال، یک سایت خبری یا یک سایت موسیقی باید رفتار کاربر را در مقایسه با یک بانک یا یک سایت مسافرتی با انتقاد بیشتری بداند. کاربر ممکن است بخواهد در طول صبح زود هنگام رانندگی به محل کار به اخبار یا موسیقی مورد علاقه گوش دهد، یا بخواهد در طول تمرین بعد از ظهر خود ویدیوهای مورد علاقه خود را پخش کند. خلق و خو کاربر چندین بار در روز تغییر میکند و از این رو سیستم باید به گونه‌ای طراحی شود که به همان حالت پاسخ دهد. دانستن این اطلاعات به پخش کننده موسیقی کمک میکند تا تجربه را شخصی کند.
در دنیای امروزی، مردم در هر سنی، به موسیقی نیاز دارند. پلتفرم‌های پخش موسیقی می‌خواهند مفید باشد، استفاده از آن آسان باشد، مجموعه‌ای از آهنگ‌ها را داشته باشد، به سرعت چیزی را که کاربر می‌خواهد گوش دهد را پیشنهاد دهد، به سلیقه و خلق و خوی کاربر حساس باشد و موسیقی مناسبی پخش کند.
برنامه‌های پخش موسیقی در قالب‌های مختلف وجود دارند و گزینه‌های مختلف گوش دادن را ارائه میدهند. با این حال، محبوب ترین سرویسهای موسیقی به سه دسته رایج تقسیم می‌شوند:
برنامه‌های محبوب پخش موسیقی مانند Spotify و Apple Music در این دسته قرار می‌گیرند. در اینجا، موسیقی در کتابخانه‌های مبتنی بر سرور ذخیره می‌شود و کاربران دسترسی نامحدودی به موسیقی دارند، اما تحت شرایط مالک برنامه.
این دسته از برنامه‌ها فضای ابری را برای ذخیره، سازماندهی و مدیریت موسیقی خود به کاربران ارائه میدهند. کاربران میتوانند موسیقی را از هر کجا و هر زمان که دوست دارند پخش کنند. AudioBox یک نمونه محبوب از پخش کننده موسیقی ابری است.
برنامه‌های رادیویی موسیقی به کاربران امکان میدهند ایستگاه‌های رادیویی آنلاین مختلفی را که بر اساس مضامین خاصی مانند ژانرها، فهرست‌های پخش هنرمند محور، حالات و موارد دیگر مرتب شده‌اند، پخش کنند. چنین برنامه‌هایی همچنین نتایج جستجو را بر اساس نیازهای شما فیلتر می‌کنند، ایستگاه‌های رادیویی را پیشنهاد می‌کنند که ممکن است دوست داشته باشید، و راهی عالی برای کشف موسیقی جدید هستند.
طراحی UI/UX برنامه یکی از عوامل مهم موفقیت در این صنعت است. طراحی کاربرپسند، جذاب و مدرن به جذب و حفظ کاربران کمک میکند. بنابراین، طراحان UI/UX نقش بسیار مهمی در این برنامه‌ها دارند. برای مثال حقوق سالیانه برای هر طراح در Spotify برابر با ۱۳۵هزار دلار است. این نکته پیشرفت شرکت Spotify نسبت به سایر رقبا است از این رو در ادامه تمرکز ما هم به نحوه طراحی و نحوه مدیریت این تیم‌ها است.
بازبینی سیستم‌های طراحی در Spotify
در نوامبر ۲۰۲۱، تیم Spotify، رویکرد جدید برای طراحی سیستم‌ها را معرفی کرده است که به Encore مشهور است. نکته جالب در مورد Encore این است که فقط یک چیز نیست: در واقع یک خانواده از سیستم‌های طراحی است که توسط تیم‌های توزیع شده مدیریت می‌شود. در این بخش، انگیزه ایجاد Encore، نحوه ساختار آن و تفاوت آن با آنچه قبلاً امتحان شده است را به اشتراک می‌گذاریم.
چگونه باید طراحی سیستم‌ها را در اسپاتیفای انجام دهیم؟ این سوالی است که اسپاتیفای چندین بار از طریق رویکردهای مختلف سعی کرده به آن پاسخ دهد. در روزهای اولیه اسپاتیفای، طراحی خاصی برای سیستم وجود نداشت- برای اولین بار همه چیز را می‌ساختند. هنگامی که در سال 2009 برنامه تلفن همراه را راه اندازی کردند، استانداردها یا الگوهای مشترک کمی وجود داشت، و تجربه کاربری اسپاتیفای به طور فزاینده‌ای ناسازگار شد. این رانش تا سال 2013 ادامه یافت، زمانی که اسپاتیفای اولین تلاش واقعی خود را برای تراز کردن طراحی بصری در سراسر پلتفرم‌های خود آغاز کرد. این یک تلاش بزرگ بود، و تاثیر زیادی داشت. سپس در سال‌های 2014-2015، تیم برند و خلاق هویت برند اسپاتیفای را به‌طور عمده‌ای تازه کردند. برای انجام این کار، اسپاتیفای یک تیم با طراحان ماهر راه اندازی کرد تا یک سیستم طراحی برای اسپاتیفای ایجاد کنند، نه اینکه با آن مانند یک پروژه یکباره رفتار کنند. خروجی این تیم، سیستم طراحی GLUE نامیده شد که با نام Global Language Unified Experience شناخته می‌شود.
سیستم طراحی GLUE از بسیاری جهات موفقیت آمیز بود. تیم ظاهر و احساس برنامه را تازه کرد، بسیاری از اجزا را در تلفن همراه و دسکتاپ استاندارد کرد و از تعداد انگشت شماری از افراد به بیش از 30 مهندس و طراح تمام وقت تبدیل شد. اما یک نکته وجود داشت GLUE یک تیم واحد و متمرکز بود. همچنین این تیم تبدیل به به یک گلوگاه شد. در سال 2018، اسپاتیفای به رشد و سرعت خود ادامه داد. در سال 2018، اسپاتیفای به رشد خود ادامه داد و به سرعت ما 200 طراح داشتیم. 2000 مهندس و 45 پلتفرم مختلف. اکنون اسپاتیفای برای اتومبیل‌ها، ساعت‌های هوشمند، بلندگوها و حتی یخچال‌های هوشمند نیز طراحی شده است. این تا حدی به دلیل یک استراتژی جدید شرکت بود. اسپاتیفای این امکان را برای شنوندگان فراهم کرده تا در هر کجا دسترسی داشته باشند.
مسئله این بود که تیم GLUE تا این لحظه منحل شده بود و هیچ کس به طور فعال سیستم طراحی GLUE را به جلو سوق نداد. این زمانی بود که ما وارد همان فاز اولیه سیستم‌های طراحی اسپاتیفای شدیم. به عنوان مثال، تیمی در نیویورک شروع به کار بر روی یک سیستم طراحی برای وب کردند. همچنین تیمی در استکهلم سیستم متفاوتی را برای خود طراحی کردند، و این یعنی مشکل در یکپارچه‌سازی رخ خواهد افتاد. اسپاتیفای کارهای بزرگ زیادی رویGLUE انجام داده است، و هنوز در بخش‌هایی از این سیستم‌ها استفاده می‌کنند. اما این رویکرد بسیار غیرمتمرکز و ناپایدار بود. در یک نقطه، اسپاتیفای 22 سیستم طراحی مختلف را که در اطراف شناور بودند داشتند.
اسپاتیفای واقعاً به یک سیستم طراحی یکپارچه و مفید نیاز داشت - اما ما می دانستیم که تیم متمرکزی مانند GLUE احتمالاً کار نخواهد کرد. بنابراین، در سال 2018، تلاش جدیدی را برای ایجاد یک سیستم طراحی برای شرکت آغاز شد.
این بار، می‌خواستند سیستم طراحی خود را طراحی کنند، مهمتر از همه، سیستمی می‌خواستند که با فرهنگ خودمختاری اسپاتیفای مطابقت داشته باشد - سیستمی که بتواند در چندین پلتفرم مقیاس‌پذیر باشد و از موارد استفاده کند. که خروجی این تلاش به Encore رسید. چیزی که در مورد Encore متفاوت است این است که یک چیز یکپارچه نیست. این چارچوبی است که سیستم‌های طراحی موجود اسپاتیفای را تحت یک نام تجاری قرار میدهد.
چندین سیستم طراحی در داخلEncore وجود دارد که هر کدام توسط تیم متفاوتی در اطراف شرکت مدیریت می‌شوند. و در حالی که این تیم‌ها سیستم‌های مختلف را حفظ می‌کنند، هر کسی که محصولاتی را در اسپاتیفای بسازد میتواند مشارکت داشته باشد.
سیستم‌های مختلف با هم متصل هستند زیرا همگی با استفاده از نشانه‌های طراحی ساخته شده‌اند و در یک محیطی زندگی می‌کنند و ساختار مشابهی که توسط چارچوب Encore تعریف شده است را دنبال می‌کنند. قبلاً 22 سیستم طراحی به هم پصل نشده داشتیم. اکنون، ما هنوز چندین سیستم داریم، اما همه آنها به هم متصل هستند و زیر یک چتر قرار دارند.
در مرکز، ما Encore Foundationرا داریم. اینجا جایی است که چیزهایی مانند رنگ، سبک‌ها، حرکت، فاصله، به‌علاوه دستورالعمل‌هایی برای نوشتن و دسترسی را نگه می‌داریم. همچنین جایی است که نشانه‌های طراحی ما زندگی می‌کنند. اینها چیزهایی هستند که همه باید از آن استفاده کنند - این چیزی است که اسپاتیفای را نسبت به سایر رقبا قویتر میکند.
در مرحله بعد، Encore Web را داریم. این همه چیزهایی را که در سیستم‌های طراحی وب یافت می‌شود ارائه میدهد: دکمه‌ها، دیالوگ‌ها، کنترل‌های فرم‌ها و موارد دیگر. این مؤلفه‌ها را میتوان در هر چیزی که با استفاده از فناوری وب ساخته شده است استفاده کرد. این مرحله دارای منابع مشترک برای پلتفرم‌های مبتنی بر وب است، اما شامل همه چیز از Foundation نیز می‌شود. کامپوننت‌ها با استفاده از توکن‌ها ساخته می‌شوند و از الگوها و دستورالعمل‌های تعریف شده در Foundation پیروی می‌کنند. بنابراین سیستم‌ها چیزهای مستقلی نیستند: آنها به هم متصل هستند.
مرحله بعد، Encore Mobile است که مشابه Encore Webاست و این مکان، مکانی برای اجزای مشترکی است که در طراحی برنامه تلفن همراه به اشتراک گذاشته می‌شود.
در این لایه بعدی، Encoreهمچنین حاوی چیزی است که ما آن را " local design systems" می‌نامیم. سیستم‌های محلی مکانی برای نگهداری عناصر طراحی هستند که برای محصولات یا مخاطبان خاص طراحی شده‌اند. برخی از اجزای وب فقط در تجربیات هنرمندان یا پادکست‌ها استفاده می‌شوند. با چارچوب Encore، می‌توانیم عناصر طراحی سفارشی را در یک سیستم محلی نگه داریم تا همه تیم‌هایی که روی Spotify for Artists کار می‌کنند بتوانند آنها را به اشتراک بگذارند. این یک ایده مشابه در سمت تلفن همراه نیز است. تیم‌های زیادی روی برنامه اصلی Spotify کار می‌کنند، بنابراین نیاز زیادی به اجزا و الگوهای مشترک تلفن همراه وجود دارد.
به طور خلاصه، هر یک از دایره‌های کوچک بالا یک سیستم طراحی کامل است که:
دیدیم که با تکامل زبان بصری و استراتژی محصولSpotify، سیستم‌های طراحی نیز باید تغییر می‌کردند. همچنین فهمیدیم که چگونه یک سیستم طراحی برای همه یک‌اندازه نیست و باید متناسب با نیازهای شرکت تنظیم شود.
بخش مهمی از موفقیت Spotify ناشی از رویکرد منحصر به فرد این شرکت برای سازماندهی حول کار برای افزایش چابکی تیم است. همانطور که تیم‌های مهندسی Spotify در مسیر پیشرفت چابکی حرکت کردند، تجربیات خود را مستند کردند، آن را با جهان به اشتراک گذاشتند و در نهایت بر نحوه سازماندهی بسیاری از شرکت‌های فناوری در اطراف کار تأثیر گذاشتند. اکنون به عنوان مدل Spotify شناخته می‌شود. افراد تصمیم‌گیرنده در کمپانی اسپاتیفای می‌خواستند تیم‌ها را سریعتر کنند و توسعه محصول نرم‌افزاری خود را سرعت ببخشند و البته لازم داشتند تا همه این دستاوردها را با حداقل آسیب و هزینه به دست بیاورند. مدل Spotify یک رویکرد مردم محور و مستقل برای مقیاس‌بندی چابک است که بر اهمیت فرهنگ و شبکه تأکید دارد. این به Spotify و سایر سازمان‌ها کمک کرده تا با تمرکز بر استقلال، ارتباطات، مسئولیت‌پذیری و کیفیت، نوآوری و بهره‌وری را افزایش دهند. مدل Spotify یک چارچوب نیست، زیرا نمایانگر دیدگاه Spotify در مورد مقیاس‌بندی از منظر فنی و فرهنگی است. این نمونه‌ای از سازماندهی چندین تیم در یک سازمان توسعه محصول است و بر نیاز به فرهنگ و شبکه تاکید میکند.
مدل Spotify برای اولین بار در سال 2012 به دنیا معرفی شد، زمانی که هنریک کنیبرگ و آندرس ایوارسون وایت پیپر Scaling Agile @ Spotify را منتشر کردند. از آن زمان، مدل Spotify سر و صدای زیادی ایجاد کرد و در فضای چابک به بحث داغی تبدیل شد. بخشی از جذابیت آن این است که به جای پیروی از یک مجموعه خاص از شیوه‌ها، بر سازماندهی حول کار متمرکز است. در چارچوب‌های مقیاس‌بندی سنتی، شیوه‌های خاص (مثلاً استندآپ‌های روزانه) نحوه اجرای چارچوب است، در حالی که مدل Spotify بر نحوه ساختار سازمانی برای فعال کردن چابکی تمرکز دارد. مدل Spotify استقلال تیم را تقویت میکند، به طوری که هر تیم چارچوب خود را انتخاب میکند (به عنوان مثال Scrum، Kanban، Scrumban و غیره).
این مدل همراه با خود دو موفقیت همراه داشت:
توجه داشته باشید که بسیاری از سازمان‌ها و شرکت‌ها هم در پی آن هستند تا مزایا و ویژگی‌هایی مدل اسپاتیفای را در سازمان خود داشته باشند اما در این مسیر برخی از سازمان‌ها موفق شدند و برخی نیز نتوانستند بهبودی در نتایج کاری خود احساس کنند. چون مانند هر روش دیگری، این مدل هم علاوه بر دستورالعمل‌ها و قوانین به فرهنگ و ساختار خاص خودش نیاز دارد. مدل اسپاتیفای ساده است، اما محیطی که در آن پیادهسازی می‌شود پیچیدگی‌های زیادی دارد.
مدل Spotify حول محور سادگی است. هنگامی که Spotify شروع به سازماندهی پیرامون کار خود کرد، تعدادی از عناصر مهم را در مورد نحوه ساختار افراد و تیم‌ها شناسایی کردند.
جوخه‌ها (Squads)
مشابه تیم اسکرام، جوخه‌ها تیم‌هایی با عملکرد متقابل و مستقل هستند (معمولاً 6 تا 12 نفر) که بر روی یک ویژگی تمرکز می‌کنند. هر تیم یک ماموریت منحصر به فرد دارد که کار آنها را هدایت میکند، یک مربی چابک برای پشتیبانی و یک مالک محصول برای راهنمایی.
قبایل (Tribes)
هنگامی که چندین جوخه در یک منطقه ویژگی با یکدیگر هماهنگ می‌شوند، یک قبیله را تشکیل میدهند. قبیله‌ها به ایجاد هم‌ترازی در میان جوخه‌ها کمک می‌کنند و معمولاً از 40 تا 150 نفر تشکیل می‌شوند تا هم‌ترازی را حفظ کنند. هر قبیله یک رهبر قبیله دارد که مسئول کمک به هماهنگی بین جوخه‌ها و تشویق همکاری است.
فصل (Chapter)
حتی اگر جوخه‌ها مستقل هستند، مهم است که متخصصان با بهترین شیوه‌ها هماهنگ شوند. فصل‌ها خانواده‌ای هستند که هر متخصص دارد و به حفظ استانداردهای مهندسی در یک رشته کمک میکند. فصل‌ها معمولا توسط یک رهبر ارشد فناوری هدایت می‌شوند، که ممکن است مدیر اعضای تیم در آن فصل نیز باشد.
انجمن صنفی (Guild)
اعضای تیمی که به یک موضوع علاقه‌مند هستند میتوانند یک انجمن را تشکیل دهند که اساساً یک جامعه مورد علاقه است. هر کسی میتواند به یک انجمن بپیوندد و آنها کاملاً داوطلبانه هستند. در حالی که فصل‌ها به یک قبیله تعلق دارند، اصناف میتوانند از قبیله‌های مختلف عبور کنند. هیچ رهبر رسمی یک انجمن وجود ندارد. در عوض، کسی دست خود را بلند میکند تا هماهنگ کننده صنف باشد و به گرد هم آوردن مردم کمک کند.
هیئت سه نفره (Trio)
کلمه Trio معروف به TPD Trio ترکیبی از Tribe Lead، Product lead و Design lead است. هر قبیله دارای یک Trio است تا اطمینان حاصل شود که هنگام کار بر روی مناطق ویژگی، همسویی مداوم بین این سه دیدگاه وجود دارد.
اتحاد (Alliance)
همانطور که سازمان‌ها مقیاس می‌شوند، گاهی اوقات چندین قبیله نیاز دارند تا برای دستیابی به یک هدف از نزدیک با یکدیگر همکاری کنند. اتحادها ترکیبی از سه قبیله (معمولاً سه یا بیشتر) هستند که با هم کار می‌کنند تا به قبیله‌های خود کمک کنند تا در هدفی بزرگتر از هر قبیله همکاری کنند.
این بخش به معماری شبکه‌های اجتماعی اختصاص یافته است که در آن، معماری دو نرم افزار Twitter و Facebook که هر کدام به سبک خود نوآوری‌های بسیاری برای این صنعت داشته اند بررسی می‌شود. قسمت هایی از معماری‌های این دو نرم افزار می تواند مانند یکدیگر پیاده سازی شود زیرا که هر دو تا حدودی در یک دسته بندی قرار دارند. ولی در عین حال هر کدام شامل ایده‌های جدیدی هستند که برای پیاده سازی این ایده‌ها نیاز به استفاده از تکنیک‌های معماری به خصوصی است که برخی از آن ترفندها خود یک ایده‌ی نوین در معماری نرم‌افزار به حساب می‌آیند.
یکی خصیصه‌های شبکه‌های اجتماعی مانند Facebook که معماری آنها را نیز تحت تاثیر قرار میدهد رشد همیشگی آنها است. به خصوص در سال‌های ابتدایی این نرم‌افزار با مورد توجه قرار گرفتن؛ تعداد کاربران با سرعت بسیار قابل توجهی افزایش می‌یابد و این مسئله نیازمند گرفتن تصمیمات مهمی در معماری می‌باشد. یکی از دلایل این موضوع این است که معمار نرم افزار باید در ابتدای توسعه نرم‌افزار که حتی محبوب شدن آن قطعی نیست، این سرعت رشد را در نظر داشته باشد و بسترهایی را برای مقیاس های وسیع تر آماده کند. همچنین در ابتدا باید با در نظر گرفتن هزینه‌ی پیاده سازی از تکنیک‌های ارزان تر استفاده کند و با افزایش تعداد کاربران آن، خلاقیت‌هایی به خرج داده تا بتواند نیازهای سیستم را در مقیاس وسیع‌تر پاسخ دهد؛ به طور مثال در ابتدای توسعه استفاده ازStack LAMP برای چنین برنامه‌هایی بسیار معمول می‌باشد. با توضیحات مطرح شده در معرفی قسمت‌های مهم این معماری به برخی تصمیمات که بعضا ممکن است قدیمی باشند ولی در مسیر پیشرفت Facebook نقش کلیدی داشتند نیز پرداخته می‌شود.
یکی از ایده‌های متفاوت Facebook که از دلایل محبوبیت آن می‌باشد پیشنهاد دادن کاربرانی است که دوست مشترک دارند، زیرا که احتمال این که دو نفر که دوست مشترک دارند، خود با یکدیگر دوست باشند زیاد است. این الگوریتم و مشکلی که برای Facebook در ابتدا ایجاد شد در ادامه توضیح داده خواهد شد. لازم به ذکر است که در ابتدا Facebook فقط مخصوص به دانشگاه ها و مدارس بوده و در سال‌های اول برای کنترل میزان مقیاس که خود از تصمیمات کسب‌وکار حساب می‌شود.
الگوریتم پیدا کردن دوست مشترک به این صورت عمل میکند که اگر دو نفر که با یکدیگر در این برنامه دوست نیستند دوست‌هایشان با یکدیگر مقایسه می‌شود که اگر یکی بودند به آن دو نفر پیشنهاد دوستی میدهد. با چشم پوشی از جزئیات الگوریتم اگر بخواهد دوست ها را تا یک سطح بررسی کند، پیچیدگی آن از درجه O(n) خواهد بود و اگر بخواهیم تا سطح دوم این مسئله مورد بررسی قرار گرفته شود، با در نظر گرفتن این که تعداد دوست‌های هر کاربر n می‌باشد، پیچیدگی O(n^2) خواهد بود. قابل مشاهده است که میزان محاسبات این الگوریتم برای تعداد کاربران بالا بسیار زیاد خواهد بود.
راه حلی که برای این مشکل گرفته شد این بود که در ابتدا به جای استفاده از یک پایگاه داده برای تمامی کاربران، از پایگاه داده‌های متفاوتی برای هر مدرسه استفاده شود. این راه حل باعث می‌شود که تعداد دوست‌هایی که هر کاربر میتواند داشته باشد به درون یک مدرسه محدود شده و همچنین زمان محاسبه این الگوریتم نیاز نباشد برای تمامی کاربران برنامه این موضوع مورد محاسبه قرار گیرد. این تکنیک باعث به وجود آمدن محدودیت ارتباط بین مدارس می‌شود، اما میزان کارایی را به شدت افزایش میدهد. این یکی از مهمترین مشکلاتی بود که این برنامه در ابتدا برای حل آن نیاز به گرفتن تصمیمی در معماری پایگاه‌های داده شد.
امروزه Facebook معماری‌های بسیار پیچیده‌تری برای مدیریت میزان اطلاعاتی که هر کاربر تولید میکند استفاده میکند، زیرا هر کاربر تولید کننده میزان قابل توجهی داده می‌باشد و تعداد کاربران فعال Facebook به چندصد میلیون نفر میرسد. کاربران اطلاعاتی مانند پست‌ها، کامنت‌ها، محل‌هایی که شما یا دوستانتان در واقعیت رفتید و ... را هر لحظه تولید می‌کنند که از چالش‌های اصلی Facebook ذخیره و مدیریت این داده‌ها می‌باشد. در ادامه به بررسی تکنیک‌ها و معماری‌هایی که در ذخیره و مدیریت این داده‌ها مورد استفاده قرار میگرید میپردازیم.
در توضیح ساده به سیستمی چندزبانه پایدار گفته می‌شود که از پایگاه‌های داده‌ی متفاوتی استفاده میکند که هر یک شامل مدل‌های متفاوت و ویژگی‌های مختلف خود می‌باشند که هر کدام نیازمندی‌های متفاوتی از کسب و کار را پاسخ میدهند.
به طور مثال Casandra و Memcache به نیازهای متفاوتی در مقابل پایگاه‌های داده‌ی سنتی مانند Mysql Db پاسخ میدهند. اگر اولویت ما صرفا داشتن خواص ACID برای تراکنش‌ها باشد، پایگاه‌های داده سنتی بهترین گزینه هستند ولی به طور مثال اگر دسترسی به داده اولویت سیستم باشد، Cache ها بهتر به این نیاز پاسخ میدهند ولی در عین حال ممکن است در به وجود آوردن پایداری و جلوگیری از داده‌های تکراری ضعیف‌تر عمل کنند. که اگر در سیستم ما این موضوع اولویت نداشته باشد قطعا پایگاه‌های داده‌ی NoSql گزینه بهتری خواهند بود.
به همین منظور Facebook برای براورده کردن نیازهای متفاوت کسب‌وکار از چندین پایگاه داده‌ی متفاوت با مدل‌های مختلف استفاده میکند.
پایگاه‌داده MySql تکنولوژی اصلی است که Facebook با موتورهای مختلف از آن استفاده میکند. Facebook برای مدیریت اطلاعات اجتماعی کاربران از گراف‌های اجتماعی استفاده میکند. در ابتدا تیم توسعه از موتور MySql-InnoDb برای ذخیره داده‌ها استفاده کردند که پس از فشرده سازی و ذخیره‌ی داده‌ها، همچنان حجم آنها بسیار زیاد بود و هزینه‌ی ذخیره سازی آن داده‌ها به شدت زیاد می‌شد. شکل 1 سرورهای Facebook را در زمان استفاده از این موتور نمایش میدهد.
معماری استفاده از موتور InnoDb در شکل 2 نمایش داده شده است.
برای حل مشکل فضای ذخیره‌سازی اطلاعات اجتماعی تیم توسعه Facebook یک موتور پایگاه داده جدید MySql به نام MyRocks تولید کرد. با استفاده از این موتور جدید فضای ذخیره‌سازی مورد نیاز اطلاعات به میزان 50% کاهش پیدا کرد و باعث افزایش بازدهی در ذخیره اطلاعات شد. به مرور زمان Facebook پایگاه داده اطلاعات کاربران را از InnoDb به MyRocks انتقال داد. به علت یکی بودن هسته این دو پایگاه داده، این انتقال امری ساده بود. پس از انجام مهاجرت پایگاه داده تیم توسعه لازم بود که تست‌های ماندگاری داده انجام دهند تا از بدون خطا اجرا شدن تمامی کارایی‌ها اطمینان حاصل کنند. پس از انجام چندین ارزیابی کارای روی این مهاجرت پایگاه‌داده‌ای نتایج حاصل نشان می‌داده که به میزان 5/3 برابر میزان هر نسخه‌ها نسبت به داده‌های فشرده نشده اولیه در موتور جدید کاهش فضا داشته اند.
پایگاه داده MySql بزرگترین تکنولوژی در زمینه ذخیره داده بوده و هر روزه توسط شرکت‌ها بسیار قدرتمندی مانند Google،Twitter ،Alibaba و LinkedIn در حال به پیشرفت می‌باشد. تیم‌های این شرکت‌ها بر روی پیشرفت الگوریتم‌های ذخیره‌سازی این تکنولوژی تحقیقات انجام میدهند. از آنجا که فیسبوک نیز یکی از بزرگترین توسعه‌های MySql را دارد، در یک مخزن مشترک با این شرکت‌های بزرگ در تحقیقات WebScale MySql شریک است و به توسعه آن کمک میکند.
در ابتدا در Facebook از یک دخیره‌سازی داده به نام RocksDB که به صورت کلید مقدار عمل میکند استفاده شد. این حالت از ذخیره سازی در مقابل MySql فوایدی داشت که از روی LevelDB که پیشتر توسط Google تولید شده است الهام گرفته شد. این پایگاه داده از سرعت بالایی برخوردار بود ولی امکان استفاده از replication و یا لایه ای از Sql در آن وجود نداشت، در حالی که تیم توسعه Facebook نیاز داشتند از این ویژگی‌ها در RocksDB استفاده کنند. این موضوع در نهایت منجر شد که پایگاه داده‌ی MyRocks را توسعه دهند. این پایگاه داده متن‌باز بوده و RocksDB را به عنوان یک موتور برای MySql در خود داشت. یکی از نقاط قوت و دلایل استفاده از این تکنولوژی به علت نیاز به ذخیره میزان زیادی داده در یک پایگاه داده واحد می‌باشد.
چند مورد از Use Case های این پایگاه داده به شرح زیر می‌باشد.
تکنولوژی Memcache از روزهای ابتدایی در Facebook مورد استفاده قرار گرفته است. این تکنولوژی حافظه‌ای غیر متمرکز است که به عنوان پوسته‌ای برای پایگاه‌داده عمل میکند که با داشتن سرعت پردازش بالاتر، به صورت میانگین پاسخهای کاربران را بسیار سریعتر پاسخ میدهد که باعث بهبود چشمگیر تجربه کاربری می‌شود.
این تکنولوژی توسط تمامی شرکت‌های بزرگ دنیا از جمله Google مورد استفاده قرار گرفته است. در ادامه، مدل مورد استفاده در معماری Facebook را بررسی می‌کنیم.
زمانی که کاربر مقدار یک متغیر را تغییر میدهد مقدار از Memcache پاک شده و در پایگاه داده ذخیره می‌شود. و اگر کاربر آن مقدار را درخواست کند بار اول از پایگاه داده داده را بدست آورده و در Memcache ذخیره میکند. در نتیجه دفعات بعدی فراخوانی‌ها همگی از Memcache خواهند بود. این رویکرد تا زمانی که پایگاه داده متمرکز باشد بسیار خوب و مطمئن کار خواهد کرد. اما زمانی که پایگاه داده غیر متمرکز باشد با مشکل eventual consistency مواجه خواهیم شد.
1 . تعریف Eventual consistency: در حالتی که پایگاه داده غیر متمرکز است، به طور مثال یک نسخه در آسیا و یک نسخه در اروپا قرار دارد، وقتی مقدار داده در یک نسخه به روز رسانی می‌شود باید سلسله‌وار در همان لحظه پایگاه داده در نسخه‌های مناطق دیگر به‌روزرسانی شود. این فرایند نیازمند زمان کوتاهی خواهد بود تا تمامی نسخه‌ها در مناطق مختلف به مقدار واحد به‌روزرسانی شوند. به این اتفاق Eventual consistency گفته می‌شود.
سیستم Twitter یک سیستم شبکه اجتماعی آنلاین می‌باشد که کاربران میتوانند پیام‌های کوتاهی را به اشتراک گذاشته و بخوانند که اصطلاحا به آن “Tweet” گفته می‌شود. در مفهوم و نگاه کردن به دید یک پروژه ساده به Twitter ممکن است آن را به صورت یکپارچه پیاده سازی کنند. اما با حجم داده این سیستم و نیازمندی‌های آن پیادهسازی به صورت یکپارچه ممکن نیست و پیچیدگی‌های بسیار زیادی ایجاد میکند. به همین دلیل Twitter به صورت میکروسرویس پیادهسازی می‌شود. در ادامه به برخی از نیازمندی‌های کارکردی و غیرکاکردی آن میپردازیم تا به تکنولوژی‌های به کار رفته و ایده‌هایی که پشت معماری آن بوده است برسیم.
۱- کاربران میتوانند Tweet های جدیدی بسازند یا آنها را به اشتراک بگذارند.
۲- حداکثر اندازه هر Tweet نمی‌تواند از 140 کاراکتر بیشتر باشد.
۳- کاربر میتواند Tweet خود را پاک کند ولی نمی‌تواند آن را تغییر دهد یا اصلاح کند.
۴- کاربر میتواند Tweet ها محبوب خود را علامت‌گذاری کند.
۵- کاربر میتواند کاربر دیگری را دنبال و یا آن را غیرفعال کنند.
۶- کاربران میتوانند حساب کاربری خود را بسازند و یا پاک کنند.
۷- پیام‌های tweet میتوانند عکس و یا فیلم باشند.
۸- سیستم ماینتورینگ باید بتواند بار، وضعیت سلامت و کارایی سیستم را تحت نظارت داشته باشد.
۱- نیازمندی مهم سیستم این است که بتواند به میزان خوبی در دسترس باشد. به این معنی که کاربر هر زمان که بخواهد بر روی سیستم خود بتواند پیام‌ها را بخواند.
۲- ساختن Timeline برای کاربرها بدون در نظر گرفتن زمان کاربر باید حداکثر نیم ثانیه به طول انجامد.
۳- سیستم به یکپارچگی بسیار بالایی نیاز ندارد. Eventual consistency قابل قبول است.
۴- سیستم باید بتواند با افزایش تعداد کاربران و tweetها مقیاس‌پذیر باشد.
۵- اطلاعات کاربر باید ماندگار باشد.
میزان کاربران سیستم Twitter تا سال 2017 در شکل 6 قابل مشاهده است که با این آمار میزان مقیاس نیازمندی‌های ذکر شده به دست می‌آید.
در بررسی با دقت پایین و انتزاع بالا میتوان سیستم را به 6 سرویس اصلی تقسیم کرد که هر کدام شامل چندین مایکروسرویس خواهند بود.
۱- سرویس Tweet
۲- سرویس User Timeline
۳- سرویس Fanout
۴- سرویس Home Timeline
۵- سرویس گراف اجتماعی
۶- سرویس جست‌وجو
در شکل زیر معماری سیستم با سرویسهای ذکر شده قابل مشاهده است.
سرویس tweet به این صورت عمل میکند که در ابتدا tweet مورد نظر را از کاربر دریافت کرده و آن را به سرویس جستجو و timeline دنبال کنندگان ارسال میکند. اطلاعات tweet مانند اطلاعات کاربر، اطلاعات tweet که شامل زمان و غیره می‌باشد را ذخیره میکند. براین این سرویس از چندین سرور در مسیر داده که به صورت توزیع شده قرار دارند استفاده می‌شود. در تصویر این سرویس قابل مشاهده می‌باشد.
این سرویس اولین سرویس از 6 موردی می‌باشد که پیشتر ذکر شده است. اغلب سرویسهای دیگر نیز از ساختاری مانند سرویس اول پیروی می‌کنند. که هر کدام پایگاه داده مخصوص به خود و چند سرور را شامل می‌شوند.
در نرم‌افزارها و سرویسهای شبکه‌های اجتماعی معمولا تعداد کاربران فراوانی وجود دارد و روزبه‌روز رو به افزایش می‌باشند. همچنین در این شبکه‌ها موجودیت‌هایی مانند پیام‌ها، پست‌ها و رابطه‌هایی مانند دنبال کردن و دوستی وجود دارد. این روابط میان کاربران باعث به وجود آمدن گراف اجتماعی می‌شود که این گراف در شبکه‌های اجتماعی در لحظه در حال رشد و بزرگ شدن خواهد بود. و به طور معمول کار کردن و استفاده از شبکه‌های اجتماعی محدود به زمان خاص، مکان خاص و محدودیت مدت استفاده یا تعداد محتوایی که تولید می‌شود ندارد. از این جهت هر کاربر به یک ماشین مولد تولید موجودیت تبدیل خواهد شد.
موجودیت‌هایی که کاربر تولید میکند همگی به صورت داده در می‌باشند، حال این داده ممکن است نیاز به ذخیره شدن و ایجاد موجودیت جدید داشته باشد و یا ممکن است نیاز به خواندن مقدار داشته باشد که در حالت دوم میزان زمان پاسخدهی اهمیت بالایی برای تجربه‌ی کاربری خواهد داشت.
با وجود حجم بالای داده‌ای که در لحظه در این سیستم ذخیره می‌شود، جریان‌های داده و حجم درخواست‌ها به سیستم بسیار زیاد خواهد بود و باید برای حفظ کارایی سیستم راه حل‌های معماری برای این نیازمندی به وجود آید. در Facebook وTwitter بسیار بالایی به بهینه سازی پایگاه‌های داده و استفاده از ابزارها و برنامه‌هایی برای مدیریت جریان‌های مختلف داده می‌باشد. همچنین در کنار براورده کردن نیازهای کاربران، لازم است نیازهای بیزینسی مانند گرفتن لاگ و تحلیل اطلاعات کاربران نیز انجام شود. از این رو این برنامه‌ها نیاز دارند در قسمت پایگاه داده از معماری بسیار قوی‌ای استفاده کنند و تمرکزی بیشتری بر روی این بخش از نرم‌افزار داشته باشند. پیش تر به برخی بخش‌های پایگاه داده Facebook پرداخته شد و در ادامه نیز به روش‌ها و ابزارهایی که در حل مشکلات ازدیاد داده‌ها و مقیاس بالای این برنامه‌ها به کار گرفته شده است میپردازیم.
به وضوح Facebook شامل میزان بسیار زیادی داده می‌باشد که در هر لحظه با سرعت بالایی در حال افزایش می‌باشند. مدیریت این داده‌ها نیاز به زیرساخت منحصربه‌فردی دارد. Facebook برای مدیریت چنین جریانی از داده‌ها از Apache Hadoop استفاده میکند؛ که ابزاری متن‌باز برای ذخیره، مدیریت و به دست آوردن داده‌های آماری از پایگاه داده‌های غیر متمرکز Facebook مورد استفاده قرار گرفته است. در کنار آن ابزارهای دیگری مانند Appache Hive، HBase و Apache Thrift می‌باشند که میتوانند در کنترل داده مورد استفاده قرار بگیرند.
مانند تکنولوژی های دیگر Facebook این مورد نیز نسخه‌ی انحصاری خود را در این شرکت دارد و میتوان گفت که Facebook بزرگترین خوشه از این تکنولوژی را پیادهسازی کرده است که حدود 2 پتابایت داده در آن دارد. برای پیام Facebook از یک پایگاه‌داده غیر متمرکز به نام HBase استفاده میکند که جریان داده را در نهایت به Hadoop انتقال میدهد.
ابزار HBase یک پایگاه داده متن‌باز می‌باشد که به خودی خود غیر رابطه‌ای حساب می‌شود و توسط شرکت Google توسعه داده شده است.در بخش ارسال پیام در ابتدا از HBase استفاده شده است که روی یک لایه از HDFS سوار می‌باشد. این تکنولوژی به علت داشتن سرعت بالا در گذردهی پیام‌ها و تاخیر پایین توسط تیم معماری Facebook انتخاب شده است. از ویژگی‌های دیگر آن میتوان به دسترس‌پذیری بالا، مقیاس پذیری و ماندگاری بالا اشاره کرد. در حال حاضر سیستم پیامرسانی از RocksDB که پیشتر معرفی شد برای ذخیره پیام‌ها استفاده میکند.
همچنین از HBase در سرویسهای دیگری مانند سیستم مانیتورینگ داخلی، ایندکس کردن جستجو، جریان داده و data scraping استفاده می‌شود. ساختار کلی این سرویس در شکل 3 نمایش داده شده است.
مهاجرت پایگاه داده سرویس پیامرسان از HBase به RocksDB باعث شد بتواند زیرساخت بهتری برای افزایش بهره‌وری استفاده حافظه‌های فلش برقرار شود و در مقابل حافظه‌های دیسکی سرعت ذخیره اطلاعات برای کاربران افزایش یابد. همچنین توپولوژی ساخته شده به دست Facebook با نحوه عملکرد مراکز داده و ذخیره داده در آنها مناسب تر از پیش می‌باشد.
سیستم Apache Cassandra یک مرکز ذخیره داده توزیع شده در Facebook برای سرویس جستجوی درون پیام‌های ورودی می‌باشد. Cassandra نوشته شده است تا داده ساختاریافته را مدیریت کند و آن را به صورتی که هیچ تک‌نقطه خرابی برای آن وجود نداشته باشد و آن را تا مقیاس‌های بسیار بالاتری در سرورهای مختلف توزیع شده گسترش دهد.
این برنامه یک نرم‌افزار برای کنترل مراکز داده از جهت درخواست داده و محاسبات آن است که بر روی یک لایه از Hadoop سوار می‌باشد. در Facebook برای انجام محاسبات و تحلیل‌ها بر روی پتابایت‌ها داده مورد استفاده قرار می‌گیرد. ای محاسبات به منظور به دست آوردن یک براورد از رفتارهای کاربر انجام می‌شود. به شرکت کمک میکند تا بتواند سرویسهای جدیدی توسعه داده و رفتار کاربر را برای شبکه تبلیغات Facebook به دست آورد.
این تکنولوژی درون Facebook کوئری‌های Sql را تبدیل به ترتیبی برای مدل Map-reduce میکند و سپس بر روی Hadoop اجرا می‌شوند. از ویژگی‌های دیگر آن میتوان به رابط کاربری قابل برنامه نویسی و پیاده سازی و استفاده فرمت‌های عمومی داده‌ها برای ذخیره داده‌های کنترلی (Metadata) نام برد.
نرم‌افزار PrestoDB یک نرم‌افزار متن‌باز مدیریت پایگاه‌داده رابطه‌ای می‌باشد. که هدف اصلی استفاده از آن اجرای کوئری‌های Sql برای حجم بسیار بالای داده می‌باشد. یک کوئری Presto میتواند شامل داده ترکیب شده از چندین منبع مختلف باشد و قابلیت تحلیل بر روی داده‌های عظیم از منابع مختلف را فراهم کند.
در Facebook از PrestoDB برای پردازش داده‌ها به واسطه یک پایپلاین عظیم با حجم کار بالا در مرکز Hive استفاده می‌شود. همچنین از آن برای انجام تحلیل‌های دستی با تاخیر کم و گذردهی بالا استفاده می‌شود. از این نرم‌افزار به جز Facebook در شرکت‌های بزرگ دیگری مانند Netflix و Walmart نیز استفاده می‌شود. شکل 4 نشان دهنده معماری پیاده سازی PrestoDB می‌باشد.
نرم‌افزار Gorilla پایگاه داده سری زمانی Facebook می‌باشد که هدف استفاده از آن مانیتور کردن و تحلیل زیرساخت‌ها و سخت‌افزار می‌باشد. این برنامه به حد کافی هوشمند می‌باشد که بتواند خرابی‌های که در یک نقطه و یا در یک منطقه رخ میدهد را بدون سربار زیادی مدیریت کند. شکل5 نشان میدهد که این نرم‌افزار چگونه در زیرساخت فعالیت میکند.
از زمان پیاده سازی نرم‌افزار Gorilla، مقیاس آن حدودا در بازه هر 18 ماه بدون تلاشهای زیادی دو برابر شده و این موضوع نشان‌دهنده مقیاس پذیری بالای این نرم‌افزار می‌باشد. این برنامه به عنوان یک Cache برای سیستم مانیتورینگ Facebook برای تمامی سیستم‌های آن عمل میکند. Gorilla میزان تاخیر تولید Facebook را به میزان 70 برابر نسبت به آمار برنامه‌های گذشته کاهش داده است و سبب افزایش کارایی چشمگیری در مانیتورینگ آن شده است.
لاگ‌ها در سیستم از اصلی ترین روش‌ها برای پیگیری خطاها در تولید برنامه به حساب می‌آیند، به کمک لاگ‌ها میتوان محتوا و علت به وجود آمدن خرابی را به دست آورد و در نتیجه راه حلی برای آن اتخاذ کرد. هیچ سیستمی نمی‌تواند بدون لاگ کار کند و سیستمی مانند Facebook که شامل چندین جزء مجزا بوده که به یکدیگر متصل شده اند، در هر لحظه به میزان قابل توجهی لاگ تولید میکند. برای ذخیره و مدیریت این داده‌ها Facebook از یک پایگاه داده توزیع شده به نام LogDevice استفاده میکند.
این برنامه یک برنامه مدیریت لاگ مقیاس‌پذیر و مقاوم در برابر خطا می‌باشد. در مقابل یک فایل سیستم که داده را به عنوان فایل ذخیره میکند LogDevice داده را به عنوان یک لاگ ذخیره میکند. لاگ‌ها بر اساس رکورد ثبت می‌شوند. این پروژه از پایه نوشته شده است تا چندین نوع لاگ را با میزان کارایی و بهره‌وری بالا در مقیاس‌های بالا ذخیره کند. انوع کارهایی که توسط LogDevice قابل پیاده سازی اند شامل لاگ کردن رخداد‌ها، پایپلاین‌های یادگیری ماشین، لاگ کردن تراکنش‌ها و غیره می‌باشد.
در این پست ما با سیستم‌های استریم فیلم، سیستم‌های پخش موسیقی، سیستم‌های شبکه‌های اجتماعی آشنا شده‌ایم و از ۶ سیستم انتخابی ما ۳ سیستم دارای معماری‌های مؤثری داشتند و هر ۳ پرچمدار زمینه خود هستند. همانطور که در بخش‌های قبلی به خوبی نقات قوت توضیح داده شده است در این بخش ما ۳ سیستم برتر انتخابی خود یعنی نتفلیکس، اسپاتیفای و فیسبوک است.
در نتفلیکس ما شاهد این بودیم که نسبت به رقبای خود دو تصمیم زود هنگام را گرفت که این دو تصمیم یعنی انتقال زیرساخت فناوری اطلاعات از مراکز داده خود به یک ابر عمومی و دیگری جایگزینی برنامه‌های یکپارچه با اجزای نرم افزاری کوچک قابل مدیریت توسط معماری میکروسرویس‌ها بود. که با اجرای این تصمیمات و مهندسی آشفتگی تیم‌های فنی نتفلیکس ابتدا پاسخگوی الزامات غیر عملکردی سیستم که شامل در دسترس بودن بالا، تاخیر کم، انعطافپذیری بالا و مقیاس پذیری شد و همچنین با شناسایی هدفمند شکست‌های واقعی و با استفاده از ابزارهای برای شناسایی و رفع خرابی‌های، میتواند چنین ضعف‌هایی را قبل از ایجاد مشکلات بزرگتر به سرعت کشف کند.
در اسپاتیفای ما شاهد این بودیم که با اینکه apple music هم ساختار و معماری مشابه با اسپاتیفای داشت ولی پیروز این رقابت با اختلاف اسپاتیفای بود. در تحقیقات متوجه شده‌ایم که این اختلاف به دلیل تیم طراحی UI/UX است و متوجه شده‌ایم که برای این سیستم طراحی در نوامبر ۲۰۲۱، تیم Spotify، رویکرد جدید برای طراحی سیستم‌ها را معرفی کرده است که به Encore مشهور است. همچنین برای مدیریت تیم‌های خود از مدل Spotify استفاده میکند که موجب سریعتر شدن تیم‌ها می‌شود و همچنین به توسعه محصول نرم‌افزاری را سرعت ببخشند. مدل Spotify یک رویکرد مردم محور و مستقل برای مقیاس‌بندی چابک است که بر اهمیت فرهنگ و شبکه تأکید دارد.
در بخش شبکه‌های اجتماعی Facebook و Twitter را مورد بررسی قرار دادیم. شبکه اجتماعی Facebook اولین نرم‌افزار عمومی بوده است که در مقیاسی به این عظمت وجود داشته است و در نتیجه بزرگترین چالش معماری آن مدیریت، ذخیره و تحلیل داده‌های آن می‌باشد. در آن بخش به توضیح در مورد چالش‌هایی که برای مقیاس بالای داده‌های Facebook به وجود آمده و مدیریت داده‌ها با پایگاه داده‌های مختلف پرداخته شد. دو نرم‌افزار Facebook و Twitter هر دو با مدل ساده LAMP شروع به کار کرده اند و هنوز هم میتوان آنها را از این سبک معماری حساب کرد ولی هر دو شامل تغییرات بنیادی در سال‌ها شده اند و عملا تکنولوژی‌های منحصربه‌فردی برای حل مشکلات استفاده کرده اند.
معماری‌های Facebook و Twitter را میتوان در سال‌های ابتدایی یک سیستم یکپارچه تصور کرد که از مایکروسرویس استفاده نمی‌کرده اند. اما با گذشت زمان و مقیاس بالاتر به مرور به معماری کاملا مایکروسرویس تبدیل شده اند تا بتوانند نیازمندی‌های سیستم را در سرویسها پاسخ دهند.
سیستم Twitter را میتوان به 6 سرویس اصلی تقسیم کرد که در آنها نیازهای اصلی سیستم از جمله مدیریت tweet ها، جستجو، گراف اجتماعی و مواردی دیگر خلاصه می‌شود. در ادامه نتیجه گیری شد که سیستم‌های شبکه‌های اجتماعی تمرکز اصلیشان به علت وجود عنصرهای همیشه در گسترشی مانند گراف اجتماعی و ارتباطات فراوان میان موجودیت‌هایشان باید تمرکز بسیار بالایی بر روی مدیریت داده‌ها و پایگاه داده خود داشته باشند. در درجه اول به نیازمندی‌های غیرکارکردی پاسخ داده می‌شود و در ادامه نیز داده‌هایی با این مقیاس بسیار ارزشمند بوده و باید تحلیل شوند تا خصوصیت کاربرهای سیستم و عملا خصوصیاتی از مردم جهان به دست آید تا بهبودهای آینده بسیار کارآمد تر باشد. در نهایت نیز برای تمرکز بیشتر بر روی به‌روش‌های به کار رفته شده در پیاده سازی پایگاه‌های داده در مقیاس شبکه‌های اجتماعی به معرفی چند مورد دیگر از تکنولوژی‌های مربوط به پایگاه داده که در Facebook مورد توسعه و استفاده قرار گرفته شده است پرداختیم.
«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»
