https://virgool.io/feed/@alidoostnia علاقمند به فناوری، استادیار دانشگاه شهید بهشتی و دانش‌آموخته دانشگاه تهران fa 2026-04-15 08:17:04 https://files.virgool.io/upload/users/1220488/avatar/3ijPX2.png?height=120&width=120 https://virgool.io/@alidoostnia https://virgool.io/mehran/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-netflix-va3n7tsl9caz نتفلیکس یک شرکت رسانه‌ای آمریکایی است که خدمات استریم فیلم و سریال را به صورت آنلاین ارائه می‌دهد. این شرکت در سال 1997 تأسیس شده و در حال حاضر بیش از 222 میلیون مشترک در سراسر جهان دارد. نتفلیکس طیف وسیعی از فیلم‌ها و سریال‌ها را در ژانرهای مختلف ارائه می‌دهد، از جمله فیلم‌های سینمایی، سریال‌های تلویزیونی، مستندها و برنامه‌های کودکان. این شرکت همچنین محتوای اصلی خود را نیز تولید می‌کند؛ یعنی در فرآیند تولید فیلم و سریال نیز مشارکت فعال دارد. نتفلیکس با مدل اشتراک کار می‌کند و کاربران برای دسترسی به محتوای آن باید به صورت ماهانه هزینه اشتراک را پرداخت کنند. این شرکت همچنین امکان دانلود فیلم‌ها و سریال‌ها را برای تماشای آفلاین فراهم می‌کند.نتفلیکس به یکی از محبوب‌ترین پلتفرم‌های استریم فیلم و سریال در جهان تبدیل شده است و به طور مداوم در حال رشد و توسعه است. این شرکت که به غول استریمینگ (جریانی) شهرت دارد، به دلیل معماری ابری پیچیده خود که قابلیت اطمینان، مقیاس‌پذیری و عملکرد را برای کاربران در سراسر جهان تضمین می‌کند، شناخته شده است. یک عنصر کلیدی این معماری، ابر خارجی است که از ترکیبی از سرویس‌های ابری آمازون Amazon Web Services (AWS) و یک شبکه تحویل محتوا (CDN) تشکیل شده است. AWS برای فرآیندهای غیرجریانی و Open Connect (OC) یا همان CDN اختصاصی Netflix برای تحویل محتوای ویدیویی کاربرد دارد.اجزای اصلی در معماری Netflixشکل ۱ معماری سطح بالای Netflix را نشان می‌دهد که در ادامه این مطلب، به جزئیات بخش‌های مختلف آن می‌پردازیم.شکل ۱- معماری سطح بالای Netflix لف) کلاینت: دستگاه‌هایی مانند تلویزیون، ایکس‌باکس، لپ‌تاپ و غیره که کاربران برای مرور و پخش فیلم‌های نتفلیکس استفاده می‌کنند.ب) زیرساخت اختصاصی OC (Open Connect) یا CDN نتفلیکس: سیستم شبکه تحویل محتوا (CDN)، شبکه‌ای از سرورهای توزیع شده در نقاط مختلف جهان است. در واقع OC همان CDN اختصاصی خود نتفلیکس است که همه امور مربوط به پخش ویدئو را مدیریت می‌کند. سرورهای Open Connect در سراسر جهان توزیع شده‌اند و هنگامی که روی دکمه پخش کلیک می‌کنید، جریان ویدئو از نزدیک‌ترین سرور بر روی دستگاه شما نمایش داده می‌شود. به این ترتیب، اگر در آمریکای شمالی هستید، ویدئو از نزدیک‌ترین سرور Open Connect به جای سرور اصلی (که ممکن است دورتر باشد) پخش می‌شود تا زمان پاسخ‌دهی کاهش یافته و فیلم سریع‌تر برای شما بارگذاری شود.پ) زیرساخت و توسعه بک‌اند: این بخش همه کارهایی که مربوط به پخش ویدئویی نباشد را انجام می‌دهد (مثلاً قبل از اینکه روی دکمه پخش کلیک کنید). وظایف این بخش شامل اضافه کردن محتواهای جدید، پردازش ویدئوها، توزیع آن‌ها روی سرورهای سراسر جهان و مدیریت ترافیک شبکه است. بیشتر این فرآیندها توسط سرویس‌های وب آمازون (AWS) مدیریت می‌شوند. به عبارت دیگر، وقتی شما یک فیلم یا سریال را در نتفلیکس انتخاب می‌کنید، ابتدا "بک‌اند" کارهای لازم برای آماده‌سازی آن را انجام می‌دهد. سپس ویدئو بر روی شبکه CDN توزیع می‌شود و نزدیک‌ترین سرور Open Connect آن را با بالاترین کیفیت و سرعت ممکن برای شما پخش می‌کند. این همکاری بین دو ابر و سه بخش اصلی نتفلیکس به شما تجربه‌ای لذت‌بخش و بدون وقفه از تماشای فیلم‌ها و سریال‌ها می‌دهد.ت) رابط کاربری نتفلیکس: نتفلیکس رابط کاربری خود (frontend) را به سه دلیل اصلی با ReactJS ساخته است:سرعت راه‌اندازی: ReactJS به توسعه‌دهندگان اجازه می‌دهد اجزای مستقل بسازند که می‌توان آن‌ها را به راحتی تست و به‌روزرسانی کرد. این امر به راه‌اندازی سریع ویژگی‌های جدید و بهبود تجربه کاربری کمک می‌کند.کارایی در زمان اجرا: ReactJS از یک DOM مجازی استفاده می‌کند که کارآیی رندر را بهبود می‌بخشد و منجر به تجربه روان‌تری برای کاربران می‌شود، به خصوص روی دستگاه‌های کم‌توان.ماژولار بودن: اجزای ReactJS کاملاً مستقل هستند که باعث می‌شود کد تمیزتر، سازمان‌یافته‌تر و قابل نگهداری‌تر شود. این امر به همکاری تیمی مؤثر و توسعه سریع نرم‌افزار کمک می‌کند.نتفلیکس از طیف وسیعی از خدمات AWS برای پشتیبانی از عملیات خود استفاده می کند، از جمله:سرویس Amazon EC2 برای میزبانی مایکروسرویس‌ها و سایر برنامه‌های کاربردی.سرویس Amazon S3 برای ذخیره سازی محتوای ویدیویی.سرویس Amazon DynamoDB برای ذخیره‌سازی داده‌های متا و داده‌های کاربر.سرویس Amazon CloudFront برای توزیع محتوای استاتیک مانند تصاویر و کد جاوا اسکریپت.سرویس ELB که به تنظیم بار کاربران روی نمونه‌های مختلف نرم‌افزاری و محتوای ویدئویی کمک می‌کند.سناریوی اجراییشکل ۲ معماری ارتباطی OCها و مراحل درخواست کاربران به سایت Netflix از طریق CDNهای اختصاصی آن را نشان می‌دهد که در ادامه این مراحل به طور ساده تشریح می‌شوند.کاربر درخواستی برای یک ویدیو به وب سایت یا برنامه نتفلیکس ارسال می کند.درخواست به CDN مسیریابی می شود.سرویس CDN بررسی می‌کند که آیا نسخه ذخیره شده محلی از ویدیو در دسترس است یا خیر.اگر نسخه محلی موجود باشد، CDN آن را به کاربر تحویل می دهد.اگر نسخه محلی در دسترس نباشد، CDN درخواست را به یکی از سرورهای اصلی هدایت می کند.سرور اصلی پس از مسیریابی، نسخه‌ای از ویدیو را برای CDN ارسال می کند.سرویس CDN، نسخه درخواستی را برای کاربر ارسال می‌کند، همچنین آن را در لبه شبکه خود برای درخواست‌های بعدی ذخیره می‌کند.کاربر ویدیو را تماشا می‌کند و به همین شکل سایر درخواست‌ها نیز مدیریت می‌شوند.شکل 2- معماری OC و مراحل درخواست کاربران به وب‌سایت Netflix مزایای استفاده از ابر خارجی با استفاده از AWS و CDN:مقیاس‌پذیری AWS و CDN: به نتفلیکس اجازه می‌دهند تا به راحتی با افزایش تقاضا برای خدمات خود سازگار شود.عملکرد بهتر: CDN با کاهش زمان تاخیر و بهبود کیفیت پخش، تجربه بهتری برای کاربران ایجاد می‌کند.کاهش هزینه: استفاده از خدمات ابری به نتفلیکس اجازه می‌دهد تا هزینه‌های زیرساخت را به صورت متغیر پرداخت کند، که می‌تواند به صرفه‌جویی در هزینه‌های کلی منجر شود.قابلیت اطمینان: استفاده از چندین منطقه AWS و CDN به نتفلیکس امکان می‌دهد تا در صورت خرابی در یک منطقه، به ارائه خدمات خود ادامه دهد.روند تولید و استقرار ویدئوها در Neflixتصور کنید قفسه‌های غول‌آسای فیلم که پر از آثار باکیفیت هستند. اینجاست که ماجرای نتفلیکس آغاز می‌شود. ویدیوهایی با کیفیت بالا از شرکت‌های فیلمسازی دریافت می‌شوند، اما پیش از آنکه بر صفحه نمایش‌ شما ظاهر شوند، سفری را طی می‌کنند که نیاز به چندین مرحله آماده‌سازی دارد.نتفلیکس از بیش از 2200 دستگاه پشتیبانی می‌کند و هرکدام از آن‌ها وضوح و فرمت متفاوتی را می‌طلبند. برای برآوردن این نیاز، فرآیند کدگذاری ویدئو وارد صحنه می‌شود. همانند آشپزی که بهترین مواد اولیه را به غذایی خوشمزه تبدیل می‌کند، مهندسان نتفلیکس نیز دست به کار می‌شوند. آن‌ها ابتدا خطاهای موجود را یافته و سپس ویدیوی اصلی را به فرمت‌ها و وضوح‌های مختلفی تقسیم می‌کنند. اما قصه به همین سادگی نیست. سرعت اینترنت نیز در کیفیت تماشا نقش مهمی دارد. به همین دلیل، برای هر فیلم، نتفلیکس حدود 1100 تا 1200 نسخه با وضوح متفاوت (مانند 4k و 1080p) ایجاد می‌کند. این حجم انبوه نیازمند کدگذاری و پردازش پیشرفته‌ است.شکل3- ساختار تولید و استقرار فیلم‌ها در Netflixفکرش را بکنید! ویدیوی اصلی به تکه‌های کوچک‌تر تقسیم می‌شود و سپس این تکه‌ها توسط پردازش‌های موازی در دنیای ابری آمازون، به فرمت‌ها و وضوح‌های مختلفی تبدیل می‌شوند. پس از کدگذاری و با داشتن نسخه‌های متعدد، آن‌ها به سرورهای Open Connect در سراسر جهان ارسال می‌شوند. این سرورها همانند انبارهای مخفی هستند که در نقاط مختف پراکنده شده‌اند تا به شما نزدیک‌تر باشند.وقتی برنامه نتفلیکس را باز می‌کنید و وارد سرورهای آمازون می‌شوید، آن‌ها مسئول ورود، پیشنهادات، جستجو، سابقه تماشا، صفحه اصلی، پرداخت، پشتیبانی و سایر موارد هستند. اما با زدن دکمه پخش، جادوی دیگری رخ می‌دهد. نتفلیکس سرعت و ثبات اینترنت شما را تحلیل می‌کند و بهترین سرور Open Connect نزدیک به شما را انتخاب می‌کند. سپس، با توجه به دستگاه و اندازه صفحه نمایش، مناسب‌ترین فرمت ویدیو را برای شما ارسال می‌کند. شاید متوجه شده باشید که گاهی ویدیو برای لحظاتی کیفیت خود را از دست می‌دهد و مجدداً به کیفیت بالا برمی‌گردد. این به خاطر همان انتخاب بهترین سرور است که برای تجربه بهتر، بین فرمت‌های مختلف جابه‌جا می‌شود. به این قابلیت Netflix، پخش تطبیقی (Adaptive) ویدئو گفته می‌شود.اما داستان در اینجا تمام نمی‌شود. نتفلیکس باهوش است! جستجوها، تماشاها، موقعیت مکانی، دستگاه، نظرات و لایک‌های شما را در سرورهای AWS ذخیره می‌کند تا با استفاده از یادگیری ماشینی و Hadoop، بهترین فیلم‌ها را به شما پیشنهاد دهد. پشت صحنه هر نمایش باشکوهی، تلاشی بی‌پایان نهفته است. این ماجرای کوتاه، گوشه‌ای از تلاش‌های مهندسان و الگوریتم‌های هوشمند نتفلیکس بود تا شما هر فیلم را با بهترین کیفیت و بدون دردسر تماشا کنید. پس دفعه بعدی که فیلم روی صفحه نمایش‌تان ظاهر شد، به یاد این سفر پیچیده و پر از هوش مصنوعی بیفتید.معمار هوشمند: ELB توزیع‌کننده‌ ترافیک در دنیای فیلم‌های بی‌پایاندر نتفلیکس، جایی که میلیون‌ها کاربر تشنه‌ تماشای فیلم و سریال هستند، ترافیک عظیمی جریان دارد. اما عبور بی‌دردسر این سیل تماشاگران از میان انبوهی از سرورها و نمایشگرها، نیازمند یک استراتژی مدبرانه است. اینجاست که قهرمان داستان ما وارد می‌شود: ELB یا همان متعادل‌کننده بار الاستیک که معماری سطح بالای آن در شکل 4 نمایش داده شده است.شکل4- معماری سطح بالای سرویس کنترل بار ELB آمازونسرویس ELB همانند یک رهبر ارکستر، وظیفه‌ هدایت ترافیک به سوی سرویس‌های نمایشی را بر عهده دارد. اما این رهبری، ساده و ابتدایی نیست، بلکه از دو مرحله‌ی هوشمندانه تشکیل شده است:تعادل در پهنه‌ وسیع: تصور کنید نتفلیکس به بخش‌های متعددی تقسیم شده است. ELB ابتدا ترافیک ورودی را در میان این بخش‌ها یا همان Zones به صورت چرخشی و منصفانه توزیع می‌کند. به این ترتیب، هیچ بخشی بیش از حد شلوغ نمی‌شود و کاربران در هر گوشه‌ای از این قلمرو به سرعت به محتوا دسترسی پیدا می‌کنند.تعادل در میان سربازان خط مقدم: هر بخش (Zone) خود به تعدادی سرور تقسیم می‌شود که همانند سربازان خط مقدم، مستقیماً به درخواست‌های کاربران پاسخ می‌دهند. ELB در این مرحله نیز وارد عمل می‌شود و درخواست‌های ورودی را به صورت چرخشی میان این سرورها توزیع می‌کند. به این ترتیب، بار بیش از اندازه روی هیچ سروری توزیع نمی‌شود و کاربران تجربه‌ای روان و بدون وقفه دارند.با این ترتیب، ELB همانند رهبری خردمند، ترافیک عظیم کاربران را در دو سطح مدیریت می‌کند و اطمینان می‌دهد که هر فرد، در هر زمان و با هر سرعتی، بتواند به سادگی وارد قلمروی جادویی فیلم‌های نتفلیکس شود. پس دفعه بعدی که به راحتی فیلم خود را آغاز می‌کنید، به یاد داشته باشید که این جادو حاصل کار ELB و هوشمندی‌های آن در توزیع عادلانه ترافیک است. بدون شک، تماشای یک فیلم خوب، سفری لذت‌بخش است، اما پشت این سفر، داستان‌های دیگری نهفته است که هر کدام نقشی در خلق تجربه‌ای به یاد ماندنی دارند.سرویس اختصاصی ZUUL: دروازه‌بان باهوش سرزمین محتوازول یک سرویس Gateway یا همان دروازه مرکزی است که مسیریابی پویا، مانیتورینگ، انعطاف‌پذیری و امنیت را برای ترافیک سرویس‌های نتفلیکس فراهم می‌کند. این سرویس امکان مسیریابی آسان بر اساس پارامترهای کوئری، URL و مسیر را می‌دهد. برای درک بهتر نحوه کار زول، اجزای مختلف آن را بررسی می‌کنیم: مسیریابی پویا: تصور کنید کاربری درخواستی برای تماشای فیلمی ارسال می‌کند. زول همانند راهنمایی هوشمند، ابتدا درخواست را تجزیه و تحلیل می‌کند. او می‌تواند مسیر را بر اساس کلمات کلیدی، آدرس اینترنتی یا مسیر مشخص شده انتخاب کند. به این ترتیب، کاربران به سرعت به مقصد خود (فیلم مورد نظر) می‌رسند، بدون اینکه در پیچ‌وخم‌های سرورها و مسیرهای اشتباه سرگردان شوند.نظارت و پایداری: زول همانند ناظری دقیق، همواره بر عملکرد سیستم نظارت می‌کند. او سلامت سرورها را بررسی می‌کند و در صورت لزوم، ترافیک را به مسیرهای جایگزین هدایت می‌کند تا هیچ‌گاه وقفه‌ای در تماشای فیلم‌ها رخ ندهد. به این ترتیب، پایداری و دسترسی مداوم برای کاربران تضمین می‌شود.امنیت و حفاظت: زول همچون نگهبانی هوشیار، امنیت دروازه‌های سرزمین محتوا را بر عهده دارد. او با فیلتر کردن درخواست‌های غیرمجاز و مشکوک، از نفوذها و حملات سایبری جلوگیری می‌کند. به این ترتیب، اطلاعات کاربران و محتوای ارزشمند نتفلیکس در امنیت کامل قرار می‌گیرند.انعطاف و کارایی: زول قابلیت‌های ویژه‌ای نیز در اختیار توسعه‌دهندگان قرار می‌دهد. آن‌ها می‌توانند با استفاده از زول، ترافیک ورودی را تقسیم‌بندی کنند و عملکرد سرورهای جدید را آزمایش نمایند. همچنین، می‌توانند بدون ایجاد اختلال در سیستم، سرویس‌های جدید را به صورت آزمایشی به کاربران منتخب نشان دهند. این قابلیت‌ها به بهبود عملکرد و توسعه‌ی سریع‌تر نتفلیکس کمک می‌کنند.فیلتر هوشمند: زول همچون سدی مستحکم، می‌تواند درخواست‌های نامناسب را شناسایی و فیلتر کند. این موضوع با ایجاد محیطی امن و مطلوب برای کاربران، تجربه‌ای لذت‌بخش‌تر را برای همه رقم می‌زند.شکل 5- نمایش سطح بالا از معماری سرویس Gateway مرکزی و اختصاصی ZUULدر دنیای وسیع نتفلیکس، زول نقشی کلیدی در هدایت هوشمندانه‌ کاربران به سمت محتوای مورد نظر خود دارد. زول با مجموعه‌ای از قابلیت‌ها، نه تنها سرعت و دسترسی را تضمین می‌کند، بلکه بر امنیت، پایداری و تطبیق‌پذیری این سرزمین جادویی نیز می‌افزاید. پس دروازه‌بان زول با هوشمندی خود، نقش مهمی در نتفلیکس ایفا می‌کند. سرویس Hystrix: سپر دفاعی سیستم‌های توزیع‌شدهدر نتفلیکس سرورهای متعددی وجود دارند که هر کدام نقشی حیاتی در ارائه‌ی خدمات ایفا می‌کنند. در این سازماندهی ظریف داده‌ها، اشتباه یک سرور می‌تواند به سرعت در سراسر شبکه منتشر شده و کل سیستم را فلج کند. اما نگران نباشید، زیرا هیستریکس وجود دارد. کتابخانه‌ای شجاع که برای محافظت در برابر چنین شکست‌های زنجیره‌ای طراحی شده است. هیستریکس به خوبی آسیب‌پذیری‌های ذاتی یک سیستم توزیع‌شده را درک می‌کند. جایی که وابستگی‌ها می‌توانند تأخیر ایجاد کرده و نقاط شکست واحدی را به وجود آورند، با عزمی راسخ، هیستریکس به شما امکانات زیر را عرضه می‌دارد:غلبه بر شکست‌های زنجیره‌ای: دیگر لازم نیست اثر دومینویی بر سیستم شما حاکم باشد. هیستریکس به سرعت خرابی‌ها را شناسایی و کنترل می‌کند و از گسترش آن‌ها مانند آتش‌سوزی جلوگیری می‌کند.کنترل تأخیرها: تأخیر و کندی از بین خواهد رفت. هیستریکس تأخیر ناشی از وابستگی‌های خارجی را مهار می‌کند و تعاملات روان و پاسخگو را تضمین می‌کند.بزیابی سریع: در صورت خرابی، هیستریکس یک بازیابی سریع را سازماندهی می‌کند و به سیستم شما اجازه می‌دهد با اختلال کم به حالت عادی بازگردد.ایجاد قابلیت تنزل (downgrade) سرویس: هنگامی که با چالش‌های غیرقابل عبور مواجه می‌شوید، هیستریکس با فعال کردن مکانیزم‌های پشتیبان‌گیری به شیوه‌ای مناسب، حتی در مواجهه با مشکلات، تجربه‌ای مداوم را برای کاربر تضمین می‌کند.هوشیاری بالا: هیستریکس به عنوان نگهبان هوشیار شما عمل می‌کند و نظارت تقریباً بی‌درنگ، هشدارهای تشریحی و کنترل عملیاتی عمیق را ارائه می‌دهد، بنابراین می‌توانید از تهدیدهای بالقوه پیشگیری کنید.ذخیره‌سازی هوشمندانه: هیستریکس از ذخیره‌سازی هوشمندانه درخواست‌ها استفاده می‌کند و تعاملات گذشته را به خاطر می‌سپارد تا عملکرد را بهینه کند و منابع ارزشمند را حفظ کند.دسته‌بندی خودکار برای افزایش کارایی: هیستریکس درخواست‌های مشابه را با هم گروه می‌کند و از قدرت پردازش دسته‌ای برای ساده‌سازی عملیات و افزایش کارایی استفاده می‌کند.با داشتن هیستریکس در کنار خود، می‌توانید با اطمینان در پیچیدگی‌های سیستم‌های توزیع‌شده حرکت کنید. انعطاف‌پذیری استوار آن تضمین می‌کند که برنامه‌های شما حتی در مواجهه با مشکلات، قوی، پاسخگو و همیشه آماده ارائه تجربیات استثنایی به کاربران باشند. معماری مایکروسرویس‌های نتفلیکسنتفلیکس در دنیای سرگرمی، سرزمینی وسیع از خدمات است که با معماری مایکروسرویس‌ها بنا شده است. این یعنی کل سیستم به تعدادی سرویس کوچک و مستقل تقسیم شده که با هم همکاری می‌کنند تا APIهای مورد نیاز را برای اپلیکیشن‌ها و وب‌سایت‌ها تامین کنند. هر زمان که درخواستی به این سیستم ارسال می‌شود، به سراغ مایکروسرویس‌های دیگر رفته تا داده‌های مورد نیاز را جمع‌آوری کند و در نهایت پاسخ کاملی برای کاربر ارسال شود.شکل 6- ساختار سطح بالای معماری مایکروسرویس در نتفلیکسنکته کلیدی در این معماری، استقلال این مایکروسرویس‌ها از یکدیگر است. مثلاً سرویس ذخیره‌سازی ویدیوها کاملاً از سرویس تبدیل فرمت آن‌ها جداست. اما چطور می‌توان اطمینان داشت که چنین سیستمی همیشه قابل اعتماد و در دسترس است؟راهکارهای کلیدی:هیستریکس: با این کتابخانه می‌توانید تحمل تأخیر و خطا در تعاملات بین سرویس‌ها را افزایش دهید.جدا کردن مایکروسرویس‌های حیاتی: برخی از سرویس‌ها به دلیل اهمیت آن‌ها، بهتر است از سایرین کمتر وابسته باشند. می‌توانید این سرویس‌های حیاتی را تنها به دیگر سرویس‌های قابل اعتماد متصل کنید. در انتخاب این سرویس‌ها، موارد ضروری مانند جستجوی ویدیو، انتخاب و پخش آن‌ها را در نظر بگیرید. به این ترتیب حتی در بدترین شرایط هم کاربران می‌توانند کارهای ابتدایی را انجام دهند.بی‌حالت (stateless) بودن سرورها: شاید عجیب به نظر برسد، اما تصور کنید سرورهایتان گله‌ای از گاوها هستند و شما به میزان شیر روزانه آن‌ها اهمیت می‌دهید. اگر یک روز دیدید که شیری که از یک گاو می‌گیرید کم شده، آن را با گاو دیگری جایگزین می‌کنید. نیازی نیست برای دریافت شیر به همان گاو خاص وابسته باشید. این مثال را می‌توان به نرم‌افزار هم ربط داد. هدف این است که اگر سرور اصلی با مشکل مواجه شد یا به موقع پاسخ نداد، بتوانید به سراغ سرور دیگری بروید و کارتان را پیش ببرید. به جای تکیه بر یک سرور خاص و حفظ حالت در آن، می‌توانید درخواست را به نمونه دیگری از همان سرویس هدایت کنید یا به صورت خودکار یک گره جدید راه اندازی کنید تا جایگزین آن شود. اگر یک سرور از کار افتاد، دیگری جایگزینش می‌شود.با رعایت این نکات، معماری مایکروسرویس‌های شما همواره قابل اعتماد و آماده‌ی پاسخگویی به کاربران خواهد بود. به یاد داشته باشید که این تنها گزیده‌ای از راهکارهای کلیدی است و پیچیدگی‌های دنیای واقعی نیازمند بررسی و تحلیل دقیق‌تری است.گنجینه‌ پنهان در قلب نتفلیکس: سفری به دنیای EV Cacheدر دنیای پرشتاب امروز، سرعت حرف اول را می‌زند. در دنیای برنامه‌های کاربردی نیز، کاربران خواهان تجربه‌ای روان و پاسخگویی سریع هستند. برای تحقق این امر، توسعه‌دهندگان به دنبال راهکارهایی خلاقانه برای ذخیره‌سازی و بازیابی داده‌ها هستند.یکی از این راه‌حل‌های هوشمندانه، EV Cache نام دارد. گنجینه‌ای پنهان در قلب نتفلیکس که نقشی کلیدی در سرعت و عملکرد بی‌نظیر این پلتفرم ایفا می‌کند. EV Cache درواقع لایه‌ای سفارشی از حافظه موقت است که بر پایه‌ی Memcached بنا شده و به عنوان پوششی بر روی آن عمل می‌کند.انواع EV Cache:شکل ۷- ساختار EVCache سادهسرویس EVCache ساده: این نوع EVCache شامل یک خوشه Memcached با چندین گره است که در یک منطقه (Zone) در دسترس هستند. این نوع EVCache برای برنامه‌هایی که به پایداری بالا نیاز ندارند مناسب هستند.شکل 8- ساختار Multi-Zone در EVCache سرویس استقرار Multi-Zone: این نوع EVCache شامل چندین خوشه Memcached در چندین منطقه (Zone) است. داده‌ها در تمام خوشه‌ها به طور همزمان ذخیره می‌شوند و در صورت خرابی یک منطقه، داده‌ها در مناطق دیگر همچنان در دسترس خواهند بود. این نوع EVCache برای برنامه‌هایی که به پایداری بالا نیاز دارند مناسب است.مراحل استفاده از EVCache:برنامه EVCache یک درخواست برای خواندن یا نوشتن داده ارسال می‌کند.سرویس EVCache درخواست را به خوشه Memcached مناسب هدایت می‌کند.اگر درخواست برای خواندن باشد، گره Memcached داده‌ها را به EVCache برمی‌گرداند.سرویس EVCache داده‌ها را به برنامه برمی‌گرداند.اگر درخواست برای نوشتن باشد، EVCache، داده‌ها را به تمام خوشه‌های Memcached در تمام مناطق ارسال می‌کند.گره‌های Memcached داده‌ها را ذخیره می‌کنند.مزایای EV Cache:افزایش سرعت: با ذخیره‌سازی داده‌ها در حافظه موقت، زمان پاسخگویی به درخواست‌ها به طور قابل توجهی کاهش می‌یابد.افزایش پایداری: ذخیره‌سازی چندگانه داده‌ها در گره‌های مختلف، سیستم را در برابر خرابی‌ها و ناپایداری‌ها مقاوم می‌کند.افزایش دسترسی‌پذیری: انتخاب نزدیک‌ترین گنجینه برای ذخیره‌سازی و بازیابی داده‌ها، دسترسی به اطلاعات را برای کاربران در هر نقطه از جهان آسان می‌کند.نکاتی برای انتخاب نوع EVCache:میزان پایداری مورد نیاز: اگر برنامه شما به پایداری بالا نیاز دارد، می‌توانید از Multi-Zone EVCache Deployment استفاده کنید.تعداد کاربران: اگر برنامه شما تعداد زیادی کاربر از نقاط مختلف جغرافیایی دارد، می‌توانید از Multi-Zone EVCache Deployment استفاده کنید تا بتوانید بار را بین چندین منطقه توزیع کنید.هزینه Multi-Zone EVCache Deployment گران‌تر از EVCache ساده است.سرویس EV Cache فقط یک نمونه از خلاقیت‌ها و نوآوری‌های نتفلیکس در زمینه‌ی ذخیره‌سازی و مدیریت داده‌ها است. با الهام از این ایده‌ها، توسعه‌دهندگان می‌توانند گنجینه‌های پنهان در برنامه‌های خود را کشف و با استفاده از راه‌حل‌های خلاقانه، سرعت و کارایی آن‌ها را به طور چشمگیری ارتقا دهند.خزانه‌های دیجیتالی نتفلیکس: سفری به دنیای پایگاه‌های دادهنتفلیکس، برای ذخیره‌سازی داده‌های متنوع خود، از دو پایگاه داده‌ مجزا و قدرتمند بهره می‌گیرد: MySQL و Cassandra. هر یک از این پایگاه‌ها، ویژگی‌های منحصر به فردی دارند و برای مقاصد خاصی به کار گرفته می‌شوند.سرویس MySQL:حافظه‌ امن و مانابرای حفاظت از اطلاعات حیاتی مانند جزئیات صورت‌حساب‌ها، پروفایل کاربران و تراکنش‌های مالی، نتفلیکس به پایگاه داده‌ای با قابلیت انطباق ACID نیاز دارد. در این میان، MySQL با داشتن ساختاری مستحکم و امکان راه‌اندازی چندین سرور اصلی همزمان (Master-Master Setup)، گزینه‌ای ایده‌آل به شمار می‌رود. این سرورهای اصلی بر روی نمونه‌های قدرتمند EC2 آمازون و با استفاده از موتور ذخیره‌سازی InnoDB مستقر شده‌اند.یکی از ویژگی‌های بارز این پیکربندی، بهره‌گیری از «پروتکل تکثیر همزمان» است. بدین معنی که هر گونه نوشته‌ای که روی سرور اصلی اولیه انجام می‌شود، به‌طور همزمان بر روی سرور اصلی دیگر نیز تکثیر می‌گردد. تأیید نهایی تنها زمانی صادر می‌شود که صحت نوشتن اطلاعات در هر دو سرور اصلی تأیید شده باشد. این امر، سطح بالایی از دسترسی‌پذیری داده‌ها را تضمین می‌کند.شکل ۹- معماری سطح بالای MySQL در Netflixنتفلیکس برای هر گره (چه محلی و چه منطقه‌ای)، یک کپی خواندنی (Read Replica) نیز راه‌اندازی کرده است. این کار، دسترس‌پذیری و مقیاس‌پذیری بالایی را به ارمغان می‌آورد. به این ترتیب، تمامی پرس‌وجوهای خواندنی به سمت کپی‌های خواندنی هدایت می‌شوند و تنها پرس‌وجوهای نوشتنی به سمت سرورهای اصلی هدایت می شوند.در صورت بروز خطا در سرور اصلی اولیه‌ی MySQL، سرور اصلی ثانویه به‌سرعت نقش اصلی را بر عهده می‌گیرد و ورودی DNS متعلق به پایگاه داده (Route53) به این سرور جدید تغییر مسیر داده می‌شود. بدین ترتیب، پرس‌وجوهای نوشتنی نیز به سمت این سرور اصلی جدید هدایت خواهند شد.سرویس Cassandra: انعطاف‌پذیری در برابر سیل داده‌هاسرویس Cassandra یک پایگاه داده‌ NoSQL است که توانایی مدیریت حجم عظیمی از داده‌ها را دارد و به خوبی از پسِ عملیات سنگین خواندن و نوشتن برمی‌آید. با افزایش روزافزون کاربران نتفلیکس، حجم داده‌های مربوط به سابقه‌ی تماشای هر عضو نیز به طرز چشمگیری افزایش یافت. این حجم عظیم داده، مدیریت آن‌ها را به چالشی جدی تبدیل کرده است. شکل 10- معماری سطح بالای Cassandra در Netflixنتفلیکس با در نظر گرفتن دو هدف اصلی، اقدام به مقیاس‌گذاری ذخیره‌سازی داده‌های سابقه‌ تماشا نموده است:کاهش اشغال فضای ذخیره‌سازیحفظ کارایی ثابت خواندن/نوشتن با افزایش داده‌های تماشای هر عضو(نسبت نوشتن به خواندن داده‌های سابقه‌ی تماشا در Cassandra حدود 9:1 است)مدل داده‌ای کاملاً غیر عادی‌شده:بیش از 50 خوشه Cassandraبیش از 500 گرهبیش از 30 ترابایت پشتیبان‌گیری روزانهبزرگ‌ترین خوشه: 72 گرهیک خوشه: بیش از 250 هزار نوشتن در ثانیهاز تک‌ردیفی تا فشرده‌سازی:در ابتدا، سابقه‌ تماشا در Cassandra تنها در یک ردیف (Row) ذخیره می‌شد. با افزایش کاربران نتفلیکس، اندازه‌ی ردیف‌ها و به تبع آن کل حجم داده‌ها نیز افزایش یافت. این امر منجر به افزایش مصرف فضای ذخیره‌سازی، هزینه‌های عملیاتی بیشتر و کاهش سرعت عملکرد برنامه شد. برای حل این مشکل، نتفلیکس اقدام به فشرده‌سازی ردیف‌های قدیمی نمود.بدین منظور، داده‌ها به دو بخش تقسیم شدند:سابقه‌ی تماشای زنده: (Live Viewing History - LiveVH) این بخش شامل تعداد محدودی از داده‌های اخیر سابقه‌ی تماشا با به‌روزرسانی‌های مکرر است. این داده‌ها که به وفور برای وظایف ETL مورد استفاده قرار می‌گیرند، به صورت فشرده‌نشده ذخیره می‌شوند.سابقه‌ی تماشای فشرده‌شده: (Compressed Viewing History - CompressedVH) حجم عظیمی از سابقه‌های تماشای قدیمی با به‌روزرسانی‌های نادر در این بخش، داده‌ها در یک ستون واحد برای هر کلید ردیف (Row Key) و به صورت فشرده ذخیره می‌شوند تا فضای ذخیره‌سازی اشغال‌شده به حداقل برسد.پردازش داده‌ها در نتفلیکس: با کافکا و چوکوا در دنیای داده‌های بزرگ غوطه‌ور شویدهنگامی که بر روی یک ویدیو در نتفلیکس کلیک می‌کنید، انبوهی از داده‌ها ظرف کسری از ثانیه پردازش می‌شوند. اما این جادو چگونه رخ می‌دهد؟ در این بخش، سفری به دل خط لوله تکامل داده‌های نتفلیکس خواهیم داشت و راز چابکی و کارایی خیره‌کننده‌ی این پلتفرم را کشف خواهیم کرد.نتفلیکس برای پردازش اطلاعات از دو قهرمان قدرتمند دنیای داده‌های بزرگ بهره می‌گیرد: کافکا و چوکوا. آن‌ها روزانه چیزی حدود 500 میلیارد رویداد داده‌، معادل 1.3پتابایت و در ساعات اوج 8 میلیون رویداد به ازای 24 گیگابایت در ثانیه را هضم می‌کنند. این رویدادها شامل طیف گسترده‌ای از اطلاعات هستند، از جمله:گزارش‌های خطافعالیت‌های رابط کاربریرویدادهای عملکردفعالیت‌های تماشای ویدیورویدادهای عیب‌یابی و تشخیصچوکوا، قهرمان نخست ما، سیستمی متن‌باز برای گردآوری داده‌های سیستم‌های توزیع‌شده است. او بر روی شانه‌های غول‌هایی به نام HDFS و چارچوب MapReduce سوار شده و از مقیاس‌پذیری و استحکام آن‌ها بهره می‌برد. چوکوا با انبوهی از ابزارهای نیرومند و انعطاف‌پذیر، امکان به نمایش درآوردن، نظارت و تحلیل نتایج را نیز فراهم می‌کند. چوکوا، رویدادها را از گوشه و کنار سیستم جمع‌آوری می‌کند و به شما این امکان را می‌دهد تا آن‌ها را رصد و تحلیل کنید یا از طریق داشبورد به تماشای‌ آنها بنشینید. چوکوا، با دقت تمام، رویدادها را در قالب توالی پرونده‌های HDFS (ذخیره‌ساز شیء آمازون S3) ثبت می‌کند. سپس، تیم کارآزموده‌ی داده‌های بزرگ، دست به کار شده و این پرونده‌های S3 را در قالب Parquet در هاو و هایو پردازش می‌کنند. این فرآیند، پردازش دسته‌ای نام دارد که عموماً به صورت ساعتی یا روزانه انجام می‌شود و کل مجموعه داده‌ها را مورد بررسی قرار می‌دهد.اما ماجرا به اینجا ختم نمی‌شود.چوکوا، علاوه بر ارسال اطلاعات به S3، سیلی از داده‌ها را به سمت قهرمان دوم ما، کافکا، دروازه‌بان اصلی پردازش داده‌های لحظه‌ای، روانه می‌کند. کافکا وظیفه دارد داده‌ها را از ورودی خود به مقصدهای مختلفی همچون S3، الاستیک‌سرچ و کافکای ثانویه منتقل کند. هدایت و مسیریابی این پیام‌ها بر عهده چارچوب قدرتمند آپاچی سامجا است. ترافیک ارسالی توسط چوکوا می‌تواند شامل جریان‌های کامل یا فیلتر شده باشد. بنابراین، گاهی نیاز است فیلترهای بیشتری روی جریان‌های کافکا اعمال شود. در واقع، به همین دلیل است که از یک مسیریاب استفاده می‌کنیم تا داده‌ها را از یک موضوع کافکا به موضوعی دیگر منتقل کند.این سفر شگفت‌انگیز داده‌ها در قلب نتفلیکس، نمونه‌ای درخشان از نوآوری و خلاقیت در حین هوهر داده‌های بزرگ است. با الهام از این قهرمانان قدرتمند، هر توسعه‌دهنده‌ای می‌تواند گنجینه‌های پنهان در برنامه‌های خود را کشف کند و با راه‌حل‌های خلاقانه، سرعت و کارایی آن‌ها را به طرز چشمگیری ارتقا دهد.کاربرد Elastic Search در نتفلیکسدر سال‌های اخیر، شاهد رشد چشمگیری در استفاده از Elastic Search در نتفلیکس بوده‌ایم. این شرکت در حال حاضر حدود 150 خوشه و 3500 هاست با نمونه‌های این موتور جستجو را اجرا می‌کندسرویس Elastic Search ابزاری قدرتمند است که در نتفلیکس برای سه کارکرد اصلی به کار می‌رود:تجسم داده: Elastic Search به عنوان یک ابزار تجسم داده، به نتفلیکس امکان می‌دهد تا اطلاعات انبوه خود را به تصویر بکشد و روندها و الگوها را با سهولت بیشتری درک کند. این ابزار به مثابه یک نقشه راه عمل می‌کند که به آن‌ها کمک می‌کند تا پیچیدگی‌های سیستم خود را به شکلی واضح ببینند.پشتیبانی مشتری: زمانی که کاربری با مشکلی در پخش ویدیو مواجه می‌شود، تیم پشتیبانی با استفاده از Elastic Search به کمک او می‌آید. آن‌ها با جستجوی اطلاعات کاربر، می‌توانند به سرعت دلیل مشکل را بیابند و آن را برطرف کنند. به این ترتیب، Elastic Search به عنوان ابزاری کارآمد در حل مشکلات و جلب رضایت مشتریان عمل می‌کند.تشخیص خطا: Elastic Search به عنوان یک ابزار تشخیص خطا نیز عمل می‌کند. این ابزار باهوش، به‌طور مداوم فعالیت‌های سیستم را زیر نظر دارد و هر گونه مشکل یا خطایی را شناسایی می‌کند. به این ترتیب، تیم‌های فنی می‌توانند به سرعت به مشکلات رسیدگی کنند و از بروز اختلالات گسترده جلوگیری نمایند. Elastic Search به مثابه یک نگهبان هوشیار، از سلامت و عملکرد روان سیستم نتفلیکس محافظت می‌کند.جادوی انتخاب فیلم در نتفلیکس: راز الگوریتم و اسپارکنتفلیکس، پادشاه بلامنازع فیلم و سریال، از فناوری‌های پیچیده‌ای برای شخصی‌سازی پیشنهادات خود استفاده می‌کند. اگر تا به حال متوجه شده‌اید که صف فیلم‌های پیشنهادی‌تان با دوستتان بسیار متفاوت است، دلیلش همین است! اما چگونه نتفلیکس به این حد از درک عمیق از سلایق شخصی می‌رسد؟پاسخ این معما در دو فناوری قدرتمند نهفته است: یادگیری ماشین و اسپارک.بیایید با مثالی کار را شروع کنیم. زمانی که وارد صفحه اصلی نتفلیکس می‌شوید، با ردیف‌های متنوعی از فیلم‌های مختلف روبرو می‌شوید. آیا هر کاربری این ردیف‌ها را به یک شکل می‌بیند؟ قطعا خیر! نتفلیکس با استفاده از داده‌های گذشته و ترجیحات شما، این ردیف‌ها را شخصی‌سازی می‌کند و بهترین‌ گزینه‌ها را برایتان به نمایش می‌گذارد. به عبارتی، نتفلیکس برای هر کاربر، فیلم‌ها را مرتب‌سازی کرده و میزان جذابیت آن‌ها را با توجه به سلیقه کاربر محاسبه می‌کند.در این جادوگری مدرن، دو عنصر کلیدی نقش آفرینی می‌کنند:یادگیری ماشین: نتفلیکس از الگوریتم‌های هوشمند یادگیری ماشین استفاده می‌کند تا اطلاعات شما را تحلیل کند. این الگوریتم‌ها با بررسی سوابق تماشای فیلم‌هایتان، امتیازدهی‌های شما و حتی عادت‌های تماشایی ‌شما (زمان تماشا، مدت زمان تماشا و ...) ترجیحات و الگوهای رفتاری شما را درک می‌کنند.اسپارک: اما حجم عظیم داده‌های نتفلیکس، تحلیل آن‌ها را با روش‌های سنتی غیرممکن کرده است. اینجا نوبت اسپارک، قهرمان دنیای پردازش داده‌های بزرگ، می‌رسد. اسپارک با موازی‌سازی محاسبات، تحلیل این حجم انبوه از اطلاعات را با سرعت و دقت بالایی انجام می‌دهد و به الگوریتم‌های یادگیری ماشین امکان می‌دهد تا به سرعت، سلایق کاربران را کشف کرده و بهترین پیشنهادات را ارائه دهند.بنابراین، زمانی که با ردیف‌های فیلم‌های جذاب و به مذاق خودتان در نتفلیکس مواجه می‌شوید، باید از این ترکیب جادویی یادگیری ماشین و اسپارک قدردانی کنید. به لطف این فناوری‌ها، نتفلیکس موفق شده است تا تجربه‌ای شخصی‌سازی‌شده و لذت‌بخش از تماشای فیلم برای میلیون‌ها کاربر خود به ارمغان بیاورد.با تشکر از آقای امیرارشیا ادیبان (دانشجوی کارشناسی مهندسی کامپیوتر) که در گردآوری این مقاله مشارکت جدی داشتند.برخی منابع:https://dev.to/gbengelebs/netflix-system-design-backend-architecture-10i3 https://www.geeksforgeeks.org/system-design-netflix-a-complete-architecture/https://medium.com/@nidhiupreti99/understanding-system-design-of-netflix-backend-architecture-and-cloud-services-b077162e45bc مهران علیدوست نیا | Mehran Alidoost Nia مهران علیدوست نیا | Mehran Alidoost Nia Sat, 03 Aug 2024 22:39:50 +0330 https://virgool.io/software-AI/%D9%BE%D8%B1%D8%AF%D8%A7%D8%B2%D8%B4-%D8%B3%D8%B1%DB%8C%D8%B9-%D8%AF%D8%A7%D8%AF%D9%87-%D9%87%D8%A7-%D8%A8%D8%A7-%D8%A7%D8%B3%D8%AA%D9%81%D8%A7%D8%AF%D9%87-%D8%A7%D8%B2-%D9%81%D9%86%D8%A7%D9%88%D8%B1%DB%8C-gpudirect-%D8%B4%D8%B1%DA%A9%D8%AA-nvidia-vc1crab1mu9l فناوری GPU-Direct که توسط NVIDIA توسعه یافته است به GPUها این امکان را می‌دهد تا به طور مستقیم با یکدیگر و با سایر بخش‌های سیستم ارتباط برقرار کنند بدون آنکه نیاز به عبور از کانال CPU وجود داشته باشد. این تکنولوژی با کاهش تاخیر و افزایش سرعت انتقال داده‌ها، بهره‌وری را در برنامه‌های محاسباتی با عملکرد بالا، یادگیری عمیق و هوش مصنوعی به طور قابل توجهی افزایش می‌دهد. با استفاده از GPU-Direct، داده‌ها می‌توانند مستقیماً بین حافظه‌های GPU و سایر دستگاه‌های ورودی/خروجی منتقل شوند که منجر به بهبود کارایی و کاهش مصرف منابع سیستمی می‌شود. این فناوری به خصوص در محیط‌های محاسباتی بزرگ و پیچیده که نیاز به پردازش همزمان حجم عظیمی از داده‌ها وجود دارد، مزایای بسیاری به همراه دارد. در ادامه معماری سطح بالا و عناصر مهم در استفاده از این فناوری را مرور می کنیم.معماری سطح بالای GPUDirect شامل دو کاربرد مختلف است. یکی ارتباط مستقیم از استوریج به GPU بوده و دیگری ارتباط مستقیم از واسط شبکه به GPU است. همانطور که در شکل 1 نمایش داده شده است، با استفاده از فناوری GPUDirect دیگر نیازی به استفاده از حافظه اصلی سیستم و درگیر کردن CPU در خواندن/نوشتن روی استوریج نیست. بلکه این کار به صورت مستقیم و از طریق سوییچ PCIe به طور مستقیم انجام می گیرد (شکل سمت راست). اگر دسترسی به GPUDirect وجود نداشته باشد، لازم است تا اطلاعات ابتدا از استوریج به حافظه اصلی سیستم منتقل شده و سپس از طریق CPU در اختیار GPU قرار گیرند که در نتیجه سرعت و پهنای باند انتقال اطلاعات از طریق CPU خود گلوگاه شده و باعث می شود از ظرفیت پردازش بالا و موازی GPU نتوانیم به درستی بهره برداری کنیم (شکل سمت چپ).شکل 1- معماری GPUDirect در ارتباط بین GPU و استوریجمدل دوم که در دنیای واقعی مسائل بیشتری را حل می کند خواندن مستقیم اطلاعات از روی واسط شبکه است. همانطور که در شکل 2 نشان داده شده، دو کامپیوتر که هر کدام دارای GPU هستند، می توانند از طریق واسط شبکه با یکدیگر و به طور مستقیم ارتباط داشته باشند. به این صورت که هر کدام از GPUها از طریق سوییچ PCIe به کارت شبکه متصل شده و از طریق فناوری GPUDirect می توانند به صورت مستقیم اطلاعات تبادل کنند. این کار باعث می شود تا با افزایش پهنای باند ورودی بتوان اطلاعات را به طور مستقیم، بدون واسطه و با سرعت بالا روی GPUها پردازش کرد. در این مدل، فناوری GPUDirect به قابلیت RDMA یا همان Remote Direct Memory Access وابسته است. این فناوری توسط کارت های شبکه از خانواده ConnectX ارائه می شود.شکل 2- معماری GPUDirect در اراتباط بین GPU و کارت شبکه با فناوری ConnectXدقت شود که در هر دو مدل معماری GPUDirect، لازم است تا GPUها از قابلیت GPUDirect که توسط NVIDIA ارائه شده، پشتیبانی نمایند. در ادامه لیستی از GPUهایی که این فناوری را پشتیبانی می کنند، ارائه می گردد:RTX A6000, A5500, A5000, A4500, A4000Quadro RTX 8000, 6000, 5000, 4000Quadro GV100, GP100, P6000, P5000, P4000Quadro M6000, M5000, M4000Quadro K4000, K4200, K5000, K5200 and K6000Quadro 4000, 5000, and 6000Quadro M5000M equipped mobile workstationsQuadro K5100M equipped mobile workstationsA2, A10, A30, A16, A40, A100GRID K1 and K2Tesla T4Tesla V100, P100, K10, K20, K20X, K40Tesla C2075 and M2070Qجهت بهره برداری از قابلیت GPUDirect، لازم است تا وابستگی های سخت افزاری و نرم افزاری مورد نیاز بررسی شود. در ادامه این وابستگی ها تشریح می شود:اجزای سخت‌افزاری:واحدهای پردازش گرافیکی (GPUs): پردازش‌های سنگین محاسباتی و موازی‌سازی داده‌ها توسط GPUها انجام می‌شود. دو مدل از GPUهای متداول NVIDIA Tesla V100 و A100 هستند که معمولاً برای کاربردهای هوش مصنوعی و یادگیری عمیق استفاده می‌شوند.کارت شبکه با پشتیبانی از RDMA: کارت‌های شبکه InfiniBand یا Ethernet با قابلیت RDMA به انتقال سریع داده‌ها کمک می‌کنند. این کارت‌ها، داده‌ها را مستقیماً به حافظه GPU منتقل می‌کنند که در آن نیازی به استفاده از CPU و حافظه اصلی سیستم نیست.سرور میزبان: سرورهای قدرتمند مانند HP ProLiant DL580 Gen10 که قابلیت پشتیبانی از چندین GPU و کارت شبکه با پهنای باند بالا را دارند. البته بسته به پهنای باند مورد نیاز و همچنین استفاده از قابلیت PCIe نسل 4 و 5 ممکن است نیاز به نسل های جدید سرورهای HP یا سرورهای تخصصی هوش مصنوعی داشته باشید.حافظه سیستم: حافظه رم (RAM) سرور برای ذخیره و مدیریت داده‌ها قبل و بعد از پردازش توسط GPUها قابل استفاده است.استوریج با سرعت بالا: استوریج های با فناوری NVMe SSD برای دسترسی سریع به داده‌ها الزامی است در غیر این صورت، استوریج خود گلوگاه می شود.اجزای نرم‌افزاری:درایورهای NVIDIA: درایورهای مناسب برای کارت‌های گرافیک و بسته نرم‌افزاری CUDA که امکان برنامه‌نویسی روی GPU را فراهم می‌کند.کتابخانه‌های نرم‌افزاری: کتابخانه‌های cuDNN و NCCL برای بهینه‌سازی پردازش‌ یادگیری عمیق و ارتباط بین GPUها به طور متداول مورد استفاده قرار می گیرد.سیستم‌عامل: سیستم‌عامل بر مبنای لینوکس (مثل Ubuntu یا CentOS) که برای اجرای نرم‌افزارهای هوش مصنوعی و مدیریت منابع سخت‌افزاری بهینه شده است، توصیه می شود.نرم‌افزارهای مدیریت و نظارت: نرم‌افزارهای مدیریت منابع مانند NVIDIA Management Library یا همان NVML و ابزارهای مانیتورینگ مانند Prometheus و Grafana.شکل 3- مدل ارتباطی مبتنی بر RDMA بین GPU و سایر ابزارها از طریق پورت استاندارد PCIeشکل 3 نمای کلی از ارتباطات مبتنی بر RDMA بین GPU و ابزارهای استوریج و شبکه را نمایش می دهد که عموما از طریق PCIe انجام می شود. فناوری ConnectX مبتنی بر همین ارتباطات توسعه یافته است. انواع واسط های شبکه مورد استفاده از این خانواده در ادامه می آید. سری کارت‌های شبکه ConnectX شرکت NVIDIA برای ارائه عملکرد بالا، تأخیر کم و ویژگی‌های پیشرفته در برنامه‌های مختلفی از جمله رایانش ابری، مراکز داده، هوش مصنوعی، یادگیری ماشین و محاسبات با عملکرد بالا (HPC) طراحی شده‌اند. همه این کارت‌ها از قابلیت GPUDirect پشتیبانی می‌کنند اما در سرعت، عملکرد و پهنای باند متفاوت هستند:کارت شبکه ConnectX-4 Lx: سرعت تا 25 گیگابیت بر ثانیه، پشتیبانی از Remote Direct Memory Access بر روی Ethernet، مناسب برای ارتباطات با تاخیر کم، مناسب برای ذخیره‌سازی، مراکز داده و محیط‌های ابری.کارت شبکه ConnectX-5: سرعت تا 100 گیگابیت بر ثانیه، پشتیبانی از قابلیت‌های پیشرفته RDMA و GPUDirect، بهبود پشتیبانی از مجازی‌سازی و آفلودهای سخت‌افزاری برای NVMe over Fabric یا همان NVMe-oF و سایر پروتکل‌های ذخیره‌سازی.کارت شبکه ConnectX-6 Lx: سرعت تا 25 گیگابیت بر ثانیه (25G) و 50 گیگابیت بر ثانیه (50G)، پشتیبانی از RDMA و امنیت پیشرفته شامل ویژگی‌های امنیتی مانند Secure Boot و رمزگذاری داده‌ها برای محافظت از داده‌ها در حین انتقال.کارت شبکه ConnectX-6 Dx: سرعت تا 200 گیگابیت بر ثانیه، دارای ویژگی‌های امنیتی پیشرفته از جمله آفلودهای IPsec و TLS، عملکرد بهبود یافته RoCE و پشتیبانی پیشرفته از برنامه‌های ابری و مراکز داده.کارت شبکه ConnectX-7: سرعت تا 400 گیگابیت بر ثانیه، آخرین مدل در این سری، با عملکرد برتر، تسریع NVMe بر روی TCP، قابلیت‌های پیشرفته GPUDirect و ویژگی‌های امنیتی قوی برای مراکز داده مدرن و بارهای کاری هوش مصنوعی.برای استفاده از فناوری GPUDirect با بهره‌گیری از کتابخانه‌های CUDA، می‌توان از زبان‌های برنامه‌نویسی پایتون یا C استفاده کرد. در اینجا یک مثال ساده با هر دو زبان برای آشنایی بیشتر، تشریح می‌شود:مثال زیر نحوه استفاده از GPUDirect RDMA را با زبان C نشان می‌دهد. این کد اجازه می‌دهد تا داده‌ها به صورت مستقیم بین حافظه GPU و دستگاه‌های دیگر انتقال یابند. در کد C یک آرایه از داده‌ها به اندازه 1024 عنصر در حافظه میزبان ایجاد و مقداردهی اولیه می‌شود. سپس حافظه‌ای در GPU برای این داده‌ها تخصیص داده شده و داده‌ها از حافظه میزبان به GPU انتقال داده می‌شوند. یک کرنل CUDA به نام kernel روی داده‌های GPU اجرا شده که در این کرنل، هر عنصر از آرایه دو برابر می‌شود. پس از اتمام محاسبات، داده‌های تغییر یافته از GPU به حافظه میزبان برمی‌گردند. در نهایت، حافظه تخصیص داده شده در GPU آزاد و حافظه میزبان نیز آزاد می‌شود.شکل 4- پیاده‌سازی GPUDirect با استفاده از کد C و کتابخانه‌های CUDAمثال زیر کد مشابهی را به زبان پایتون نشان می‌دهد که از کتابخانه Numba استفاده کرده و یک محیط برنامه‌نویسی مبتنی بر CUDA فراهم می‌کند. در کد پایتون زیر از کتابخانه Numba برای برنامه‌نویسی CUDA استفاده شده است. ابتدا یک آرایه از داده‌ها به اندازه 1024 عنصر در حافظه میزبان (host) ایجاد و مقداردهی اولیه می‌شود. سپس این آرایه به حافظه دستگاه (device) یعنی GPU انتقال داده می‌شود. کرنل CUDA که به نام kernel تعریف شده، داده‌ها را دو برابر می‌کند. این کرنل با استفاده از تعداد مشخصی از بلوک‌ها و نخ‌ها اجرا می‌شود. در نهایت، داده‌های تغییر یافته از GPU به حافظه میزبان برگردانده و چاپ می‌شوند.شکل 5- پیاده‌سازی GPUDirect با استفاده از کد پایتون و کتابخانه‌های Numpyمنابع:https://developer.nvidia.com/gpudirecthttps://docs.nvidia.com/cuda/gpudirect-rdma/https://www.nvidia.com/en-us/networking/ethernet-adapters/https://developer.nvidia.com/gpudirectforvideo مهران علیدوست نیا | Mehran Alidoost Nia مهران علیدوست نیا | Mehran Alidoost Nia Sat, 08 Jun 2024 22:42:08 +0330 https://virgool.io/mehran/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%85%D8%A7%DB%8C%DA%A9%D8%B1%D9%88%D8%B3%D8%B1%D9%88%DB%8C%D8%B3-es4v6fbi0jel در دنیای امروز به دلیل گستردگی نیاز به سرویس‌های مستقل و کارآمد، بسیاری از توسعه‌دهندگان نرم‌افزار بر روی توسعه مبتنی بر مایکروسرویس تمرکز می‌کنند. این توسعه، علاوه بر مستقل‌سازی و توسعه چابک سرویس‌ها، قابلیت تنظیم میزان منابع و نمونه‌های مورد نیاز از آنها در زمان استقرار را نیز به مهندسین نرم‌افزار ارائه می‌دهد. اما سوال اساسی در توسعه مبتنی بر مایکروسرویس همواره این است که تا چه اندازه لازم است یک سرویس ریزدانه یا درشت‌دانه باشد. به بیان ساده‌تر، اندازه مایکروسرویس‌ها چقدر باشند تا به قدرت توسعه و کارایی سرویس مناسب دست یابیم؟ یکی از راهکارهای حرفه‌ای در جهت پاسخ به این نیاز، استفاده از مدل طراحی مبتنی بر دامنه (DDD) یا همان Domain-Driven Design است. DDD یک روش طراحی مشترک با افکار بیزنسی است که زبان مشترکی (Ubiquitous Language) بین لایه‌های مختلف کسب‌وکار و فنی ایجاد می‌کند. البته که DDD یک روش مهم در مهندسی نیازمندی و مدیریت فرآیندهای مهندسی نرم‌افزار به شمار می‌رود که در عین حال به طراحی هدفمند و منظم معماری مبتنی بر مایکروسرویس‌ها نیز کمک می‌کند. در ادامه به تعریف و ساختار طراحی مبتنی بر دامنه می‌پردازیم. این مطلب در وبلاگ در روزهای آینده با موردهای مطالعاتی تطبیقی ادامه خواهد یافت. دامنه چیست؟در فرآیندهای مهندسی نرم‌افزار، دامنه به طور مستقیم و غیرمستقیم به بخش‌های مختلف کسب‌وکار اشاره دارد. بخش‌های منطقی کسب‌وکار در واقع دامنه‌هایی هستند که منطق توسعه حول آن شکل می‌گیرد. طبق تعریف کلاسیک، دامنه مجموعه‌ای از دانش، تاثیرهای مرتبط و فعالیت‌هاست که در راستای اهداف مشخصی در کنار یکدیگر قرار می‌گیرند. دامنه‌های اغلب در قالب سگمنت‌های بیزنسی نمایش داده می‌شوند که قابلیت تفکر، توسعه و ارزیابی مستقل هر بخش به صورت جداگانه فراهم است هر چند ارتباطات بین دامنه‌ها همچنان امکان‌پذیر باشد. به طور خلاصه، جامعه مهندسی نرم‌افزار با این تعریف بیشتر همراه هستند که دامنه آن بخش از بیزنس است که هدف برنامه تولیدی، ساختن آن است. اریک ایونز در کتاب معروف خود در خصوص طراحی مبتنی بر دامنه، دامنه را به شکل زیر تعریف می‌کند:"A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software."همانطور که در شکل 1 نمایش داده شده، در ساختار چندلایه توسعه، دامنه‌ها به عنوان قلب اصلی مهندسی نرم‌افزار در نظر گرفته می‌شوند. دامنه اصلی سیستم آن بخشی است که بیانگر هسته اصلی کسب‌وکار بوده و برنامه تولیدی، قرار است انعکاس‌دهنده آن باشد. بر اساس تصویر، برنامه کاربردی تولیدی روی دامنه شکل می‌گیرد و زیرساخت نیز متناسب با آن پیکربندی می‌شود. در نتیجه درک درست از دامنه بسیار مهم بوده و به همین جهت است که طراحی مبتنی بر دامنه در تعیین و تطبیق نیازهای کسب‌وکار و فنی موفق عمل خواهد کرد.شکل 1- ساختار چندلایه طراحی مبتنی بر دامنهطراحی مبتنی بر دامنهیک متدولوژی طراحی نرم‌افزار است که در آن مهندسین نرم‌افزار برای درک بهتر نیازمندی‌های یک دامنه از کسب‌وکار، اقدام به مدلسازی آن دامنه می‌کنند. همانطور که در روش‌های مرسوم مهندسی نرم‌افزار نیز دیده‌ایم، ابزارها و نمودارهای تحلیلی مبتنی بر UML نیز از روش مدلسازی تبعیت می‌کنند. همواره سعی بر آن است تا با مدلسازی از دنیای واقعی، به سطحی از انتزاع دست پیدا کنیم که قابلیت پیاده‌سازی بدون ابهام یا با حداقل ابهام ممکن را داشته باشد. DDD نیز از این قاعده مستثناء نیست و در تحلیل و توصیف دامنه‌ها از یک مجموعه روش‌های مدلسازی بهره می‌گیرد. در واقع وقتی که اطلاعات کافی از کسب‌وکار (دامنه) دریافت شد، نوبت به توسعه مدل DDD می‌رسد. در این بخش به اجزای اصلی این مدلسازی می‌پردازیم.همانطور که در شکل 2 نمایش داده شده، هسته اصلی طراحی مبتنی بر دامنه، زبان مشترک است. زبان مشترک بر پایه اصطلاحات و دانش پایه کسب‌وکار (دامنه) تدوین می‌شود. بر این اساس که دامنه قابل توسعه مربوط به چه صنعت و کاربردی است، اصطلاحات و نیازمندی‌های اولیه در قالب زبان مشترک گردآوری شده و توافقی اولیه بین تیم‌های فنی و کسب‌وکار شکل می‌گیرد. افراد از جمله متخصص دامنه (Domain Expert)، تحلیلگر کسب‌وکار، مدیران محصول و توسعه‌دهندگان عضو تیم DDD خواهند بود. متخصص دامنه فردی است که بر ابعاد بیزنسی مورد مطالعه تسلط کافی دارد. برای مثال اگر دامنه مورد مطالعه یک دامنه فینتکی باشد، لازم است تا فرد انتخاب شده اطلاعات کافی در مورد صنعت فینتک را داشته باشد و بتواند در همه مسائل تخصصی کسب‌وکار اظهارنظر یا تحقیق نماید. شکل 2- مولفه‌های اصلی طراحی مبتنی بر دامنهبخش مهمی از خروجی‌های DDD، نیازمندی‌های عملکردی و مشخصه‌های محصول نهایی است؛ آنچه که در شکل 2 با Functional Requirements نمایش داده شده است. دامنه‌ها در جلسات تخصصی شناسایی شده و هر یک می‌توانند دارای زیردامنه (Sub-Domain) باشند. در مدلسازی دامنه‌ها/زیردامنه‌ها لازم است تا عناصری مانند Bounded Context (BC) و Context Map مشخص شوند که در ادامه به جزئیات این عناصر و شیوه مدلسازی می‌پردازیم. علاوه بر آن، شیوه ارتباط بین این عناصر بیزنسی و نحوه نگاشت آنها به عناصر فنی باید مشخص شود. برنامه‌ریزی توسعه محصول، تولید کد و مستندات فنی/تحلیلی مورد نیاز هم متناسب با خروجی DDD انجام می‌گیرد.متون محدودشده (Bounded Context) و مدل نگاشت BCهابسته به دامنه مورد استفاده، هر کدام از مفاهیم و کلمات می‌توانند معنای خاص خود را داشته باشند. برای مثال یک سیستم فروشگاهی کتاب آنلاین را در نظر بگیرید که در آن یک عنصر به نام book وجود دارد. این مفهوم هم می‌تواند به معنای کتاب باشد و هم به معنای رزرو کردن. Bounded Context یا همان BC به مفاهیم و متون محدودشده اطلاق می‌گردد که به طور شفاف و بدون ابهام وظیفه تعریف مشخصی از مفاهیم کسب‌وکار را بر عهده دارند. در مثال فوق لازم است تا معنای دقیق book مشخص شده و به عنوان یک عنصر محدود شده از این پس در DDD مورد استفاده قرار گیرد. دلیل عمده استفاده از BCها در DDD این است که در مهندسی نرم‌افزار همه چیز باید دقیق باشد. علاوه بر رفع ابهام، در توسعه زبان مشترک بین توسعه‌دهنده‌ها و متخصصین دامنه کمک می‌کند. پس از تعیین BCها در یک دامنه، لازم است تا مسیر و نحوه ارتباطات بین آنها مشخص شود. نقشه ارتباط بین BCها که از آن به Context Map نیز یاد می‌شود، ارتباط بین BCها در داخل دامنه/زیردامنه‌ها و بین دامنه/زیردامنه‌ها را تعیین می‌کند. برای مثال اگر در دامنه کسب‌وکار تجارت الکترونیکی هستیم، فروشنده‌ها لازم است تا پیش از فروش محصول، موجودی انبار خود را بررسی نمایند. به همین ترتیب، وقتی کالایی به فروش رسید، توسط واحد پستی باید به آدرس تعیین‌شده توسط مشتری، تحویل داده شود. همانطور که در شکل 3 نمایش داده شده، در DDD رابطه بین BCها در یک دامنه/زیردامنه با Context Map نمایش داده می‌شود.شکل 3- نمونه‌ای از روابط بین BCها با ساختار Context Map (مثالی از یک فروشگاه آنلاین کتاب)الگوهای طراحی مبتنی بر دامنه: راهبردی و تاکتیکیدر DDD دو نوع الگوی طراحی وجود دارد که بسته به سطح بیزنسی و عمق فنی دامنه/زیردامنه‌ها از آنها استفاده می‌شود. هدف الگوی راهبردی (Strategic) تعیین BCها و تولید Context Map است در حالی که الگوی طراحی تاکتیکی (Tactical) بر روی مدلسازی فنی هر یک از BCها بر اساس قواعد کسب‌وکار و زیردامنه‌های مرتبط تمرکز دارد. در ادامه علاوه بر بررسی هر یک از این دو فاز، به نقش تعیین‌کننده آنها در معماری سرویس‌های مبتنی بر مایکروسرویس می‌پردازیم.فاز راهبردی، با مشارکت افراد کسب‌وکار، فنی و محصول به صورت مشترک اجرا می‌شود. لازمه این همکاری، برگزاری جلسات طوفان رویداد (Event Storming) است. در این جلسات، مدلسازی بالا به پایین و راهبردی انجام می‌گیرد و نیازمندی‌های کسب‌وکار بر اساس رویدادهای مهم دامنه به صورت دقیق تعیین می‌شود. انتظار می‌رود تا پس از برگزاری این جلسات، به لیست دقیقی از BCها برسیم. مراحل این فاز به این ترتیب است که ابتدا تحلیل دامنه کسب‌وکار به صورت کامل انجام می‌گیرد و همه اعضا از جزئیات کسب‌وکار مطلع می‌شوند. سپس BCها مشخص شده و از روی BCها و روابط بین آنها، نگاشتی به تعداد و کیفیت مایکروسرویس‌ها مشخص می‌گردد. در واقع هر BC فرصتی برای پیاده‌سازی یک مایکروسرویس را منعکس می‌کند. پس از آن، نوبت به تعیین روابط بین BCها می‌رسد که بسته به نوع و کارایی آنها، می‌توانیم انتخاب‌های متنوعی داشته باشیم از پروتکل‌های باز گرفته تا محدود که انواع این روابط در این سند آنلاین قابل مشاهده است.فاز تاکتیکی به تشریح فنی BCها می‌پردازد و مدلسازی تحلیلی/فنی در این بخش صورت می‌پذیرد. مهمترین عنصر در این مسیر، مدلسازی دقیق‌تر از فضای واقعی کسب‌وکار است. از آنجایی که مدلسازی خود مبنایی برای تولید کدهای متناظر است، لازم است تا این فرآیند با دقت بیشتری انجام شود. مدلسازی‌ها فارغ از فناوری مورد استفاده در تولید محصول نرم‌افزاری خواهد بود. بدون توجه به استک و فناوری‌های قابل استفاده، بیشتر روی مدلسازی زیردامنه‌ها و تحلیل دقیق‌تر BCها تمرکز خواهیم داشت. هفت عنصر زیر به عنوان نقاط اساسی مدلسازی در این فاز قابل بیان هستند:موجودیت‌ها (Entities): اشیائی هستند که دارای شناسه بوده و در طول زمان پایدار هستند. برای مثال یک سفارش خرید را در نظر بگیرید که دارای یک شناسه مشخص بوده و در طول زمان خرید تا تحویل، وجود دارد.اشیا دارای مقدار (Value Objects): مقادیر غیرقابل تغییر که اصول اولیه مدل مانند زمان، واحد پول و … را می‌سازند.مصالح (Aggregates): روابط بین موجودیت‌ها و اشیا دارای مقدار را مشخص می‌کند. در واقع مجموعه‌ای از اشیا را شامل می‌شود که می‌توانند به عنوان یک واحد مشخص در نظر گرفته شده و در یک حالت مشخص باشند. برای مثال یک مشتری را در نظر بگیرید که صاحب یک کتاب است و سفارشی را نیز ثبت کرده است. در نتیجه همه این موارد می‌توانند در یک Aggregate باشند. سرویس‌های دامنه: یک مجموعه سرویس stateless بوده که بخشی از منطق یا عملکرد سیستم را پیاده‌سازی می‌کنند و می‌تواند دربرگیرنده چند موجودیت باشد.رویدادهای دامنه: آنچه که در معماری مایکروسرویس بیش از همه عناصر دیگر اهمیت پیدا می‌کند، رویدادهای دامنه هستند. باید مشخص شود تا در صورت رخداد یک رویداد، کدامیک از سرویس‌ها باید مطلع شوند. برای مثال وقتی پرداخت سفارش خرید کاربر با موفقیت انجام شود، باید مشخص شود که این رویداد به چه سرویس‌ها دیگری باید اطلاع‌رسانی شود.مخازن (Repositories): در اصل نگهدارنده پایداری برای Aggregateها به حساب می‎‌آیند که معمولا در فرم پایگاه داده‌ها ظاهر می‌شوند.کارخانه‌ها (Factories): کارخانه مسئول تولید Aggregateهای جدید هستند. شکل 4- نمونه‌ای از مدلسازی Aggregate در ثبت سفارش در فروشگاه آنلایناندازه مایکروسرویس‌ها در DDDسوال اساسی این است که در طراحی مبتنی بر دامنه، سایز مایکروسرویس‌ها باید تا چه اندازه باشد. متر و معیار استانداردی که بر اساس تحقیقات علمی و تحلیل فنی ارائه شده، بر اساس شکل 5 است. در صورتی که تحلیل و مدلسازی DDD به درستی انجام شده باشد، بهتر است سایز یک مایکروسرویس از یک BC بزرگتر نباشد و از یک Aggregate نیز کوچکتر طراحی نشود. البته با توجه به بررسی بهترین الگوهای طراحی، BC اندازه مناسبی برای پیاده‌سازی مایکروسرویس در نظر گرفته شده است.شکل 5- معیار تعیین اندازه مایکروسرویس‌ها در طراحی DDDالبته اکثر پروژه‌های نرم‌افزاری در ابتدا با ساختار Monolithic توسعه می‌یابند و در ادامه با توجه به کیفیت سرویس‌ها، نیازمندی‌های پروژه و بودجه، به سمت مایکروسرویس‌های کارآمد تغییر مسیر می‌دهند. البته که این روند در شروع کار استارتاپ‌ها منطقی به نظر می‌رسد و در بسیاری از نمونه‌های داخلی و خارجی نیز موفقیت‌آمیز بوده است؛ اما اگر از پیش مسیر تحلیل و مدلسازی هموار باشد، استفاده از روش DDD، به سازماندهی بهتر و دقیق‌تر پروژه‌های نرم‌افزاری بزرگ منجر می‌شود. همانطور که در شکل 6 نمایش داده شده است، طراحی مبتنی بر DDD و مشخص کردن مایکروسرویس‌ها، همانند ساخت یک شهر با برنامه از پیش‌ تعیین‌شده است. وقتی برنامه‌ریزی توسعه یک محصول نرم‌افزاری پیچیده در میان است، DDD یک متدولوژی هدفمند و کارا ارائه می‌دهد که تمامی تغییرات از این پس در ساختار آن جای می‌گیرد.شکل 6- مثالی از مقایسه طراحی برنامه‌ریزی‌شده و بدون برنامه قبلی با DDD که منجر به سازماندهی هدفمند دامنه‌ها و اجزای نرم‌افزاری محصول می‌شود.جمع‌بندیدر روش مبتی بر DDD، مایکروسرویس‌ها و روابط بین آنها با الگوی طراحی راهبردی DDD قابل اجرا است و متعاقب آن، هر مایکروسرویس با استفاده از الگوی تاکتیکی DDD مدلسازی می‌شود. اینکه فناوری مورد استفاده در هر مایکروسرویس چه باشد و یا از چه روش توسعه‌ای استفاده شود (مثلا BDD یا TDD)، در ساختار DDD به صورت صریح تعیین نمی‌گردد. از آنجایی که تیم‌های توسعه در یک مایکروسرویس یا مجموعه‌ای از آنها به صورت خودمختار عمل می‌کنند، می‌توان فناوری و روش‌های توسعه مستقلی را در هر مایکروسرویس متناسب با نیازهای دامنه به کار گرفت. همانطور که در این مقاله تشریح شد، استفاده از DDD در توسعه محصول‌های نرم‌افزار بزرگ و پیچیده کمک شایانی می‌کند و علاوه بر مدیریت فرآیندهای مهندسی نرم‌افزار و توسعه هدفمند، به یکپارچگی دیدگاه‌های بین واحدهای فنی و کسب‌وکار می‌انجامد که نتیجه‌ای از شکل‌گیری زبان مشترک بین افراد متخصص دامنه و توسعه‌دهندگان است.سخن پایانیقلب اصلی یک سیستم نرم‌افزاری در واقع توانایی حل مسائل مربوط به دامنه‌ای از کسب‌وکار است که قرار است کاربر از آن بهره بگیرد. اریک ایونز در کتاب خود (رفرنس شماره 1) به این نکته اشاره دارد:"The heart of software is its ability to solve domain-related problems for its user."بازدید از ویدئوی مرتبطپیش از این در رویداد کافه تکنولوژی، ارائه‌ای در همین خصوص با جزئیات بیشتر و با شکل‌گیری مباحثی بین افراد متخصص توسط نویسنده انجام شده است. برای دیدن ویدئو، می‌توانید از طریق لینک آپارات زیر اقدام نمایید:https://www.aparat.com/v/VGuTKمنابع[1] Eric Evan, "Domain-Driven Design: Tackling Complexity in the Heart of Software," Addison-Wesley Professional; 1st edition (August 20, 2003), 2003.[2] Vladik Khononov, "What Is Domain-Driven Design?," O'Reilly Media, Inc., ISBN: 9781492057796, October 2019, Access via this link.[3] Tomas Fernandez, "Domain-Driven Design Principles for Microservices," 8 Jul 2022, Access via this link.[4] HiBit open articles, "Domain Driven Design: Layers," July 2021, Access via this link. مهران علیدوست نیا | Mehran Alidoost Nia مهران علیدوست نیا | Mehran Alidoost Nia Mon, 04 Sep 2023 21:34:19 +0330 https://virgool.io/mehran/%D9%85%D8%B9%D8%B1%D9%81%DB%8C-%D9%86%D9%82%D8%B4-vp-of-engineering-%D9%88-%D9%85%D9%82%D8%A7%DB%8C%D8%B3%D9%87-%D8%A2%D9%86-%D8%A8%D8%A7-cto-%D8%AF%D8%B1-%D8%B4%D8%B1%DA%A9%D8%AA-%D9%87%D8%A7%DB%8C-%D9%81%D9%86%D8%A7%D9%88%D8%B1-eymyccnwqhsy تشریح نقش VP of Engineering (VPE) را از شرکت‌های ایرانی شروع می‌کنیم که از آن به معاونت فنی یا معاونت مهندسی هم یاد می‌شود. معمولا شرکت‌های ایرانی به محض بزرگتر شدن و توسعه بدنه تیم فنی، به دنبال تقویت بدنه مدیریت فنی شرکت هستند. این تصمیم در نگاه کلی ضروری است و به صورت منطقی، درست و معقول به نظر می‌رسد. اما بایدها و نبایدهایی دارد که اکثر مدیران ارشد نسبت به آن بی‌خبر هستند و لازم است پیش از تصمیم‌گیری در خصوص اضافه کردن VPE در کنار سایر جایگاه‌های فنی مثل CTO، از فرصت‌ها و چالش‌هایی که می‌تواند به همراه داشته باشد، مطلع باشند. در این مقاله به تعریف علمی، فنی و کاربردی نقش VPE می‌پردازیم و این جایگاه را از نقطه‌نظر وظایف با نقش متداول CTO مقایسه می‌کنیم. به صورت کلی، توجه اصلی CTO روی تدوین و بروزرسانی چشم‌انداز و راهبردهای فنی سازمان متمرکز است در حالی که VPE باید روی جنبه‌های عملیاتی و اجرایی سمت کسب‌وکار از نقطه‌نظر فناوری تمرکز داشته باشد. در کنار دانش فنی، هر دو نقش نیاز به مهارت‌های رهبری خوب، دید راهبردی و همچنین اشراف کافی نسبت به اصول بنیادی سازمان دارند. CTO راهبری فناوری و سیاست‌های فنی در سطح سازمان را بر عهده خواهد داشت و مسئولیت مدیریت و راهبری تیم‌های بزرگ مهندسی (فنی) و عملیات توسعه با VPE خواهد بود. پیش از اینکه به جزئیات وظایف بپردازیم، سوال اصلی مرتبط با جایگاه VPE در سازمان است. در سازمان‌های ساخت‌یافته، VPE یک نقش اجرایی و راهبردی است که به عنوان معاون مدیرعامل شناخته می‌شود. در کنار تعامل نزدیک با CTO، مسیر گزارش‌دهی وی مدیرعامل است. چنانچه در سطح بالای اجرایی نیازی به اضافه شدن مدیر ارشد نباشد، مسلما با گزینه‌هایی مانند راهبر فنی تیم (Technical Team Lead) یا مدیر مهندسی (Head of Engineering) که مدیران میانی محسوب می‌شوند، می‌توان ساختار سلسله‌مراتبی بهتری خلق کرد. شکل 1 جایگاه VPE و CTO را در شرکت‌های ساخت‌یافته نشان می‌دهد. با توجه به اینکه در بازار ایران هنوز درک درستی از جایگاه VPE وجود ندارد، دقت بیشتر به سلسله مراتب پیشنهادی و همچنین شرح وظایف VPE پیش از اقدام به جذب، بسیار اهمیت دارد. لذا توضیه می‌شود تا کارشناس‌های جذب و استخدام و همچنین مدیران ارشد فنی پیش از اقدام به جذب VPE، ابعاد تغییرات سازمانی پس از جذب را بررسی نمایند. شکل 1- جایگاه سازمانی CTO و VPE در شرکت‌های فناوربرخی افراد جایگاه VPE را زیرمجموعه‌ای از CTO در نظر می‌گیرند. معمولا استدلال این افراد و سازمان‌ها این است که تصمیم‌گیرنده فنی تنها یک نفر باشد و بقیه مدیران فنی، هر چند با مسئولیت اجرایی، به همان یک نفر کمک کنند. اتفاقا این شرایط هیچ کمکی به توسعه و رشد فناوری سازمان نمی‌کند. چرا که در سازمان‌های بزرگ معمولا مدیر ارشد فنی از اعضای هیئت مدیره و یا سهام‌داران است و در صورت عدم مشورت وی با سایر اعضای فنی، می‌تواند به تصمیم‌گیری‌های یکطرفه منجر شود. در صورتی که جایگاه VPE به عنوان یک مدیر ارشد و اجرایی در سازمان می‌تواند منجر به الزام در تصمیم‌گیری‌های مشترک فنی شود. البته که همروند بودن و ایجاد تعامل سازنده بین VPE و CTO یکی از پیش‌نیازهای هم‌افزایی مثبت در تصمیم‌گیری‌های فنی سازمان خواهد بود.وظایف اصلی VPEمعاون فنی؟ معاون مهندسی؟ یا معاون مهندسی نرم‌افزار؟ آنچه که نقش VPE برای آن شکل گرفته، توسعه نرم‌افزار است و لذا تیم‌های مهندسی که وی با آنها کار خواهد کرد به تولید نرم‌افزار مشغول هستند. VPE در واقع روی تمامی مراحل چرخه تولید نرم‌افزار (SDLC) مشارکت دارد. از مرحله مهندسی نیازمندی گرفته تا مراحل تحلیل فنی، معماری نرم‌افزار، فناوری‌ها و روش‌های توسعه تا تست و استقرار نرم‌افزار. در نتیجه تمرکز ویژه VPE نه تنها روی فناوری، بلکه بر روی تمامی مراحل چرخه تولید نرم‌افزار است. علاوه بر این، فرآیندهای ارزیابی کارایی نیروهای فنی و جذب افراد جدید نیز می‌تواند در زمره وظایف مشخص VPE قرار بگیرد. بهینه‌سازی فرآیندهای مهندسی از مرحله تحلیل تا مرحله استقرار نیز جز وظایف VPE به شمار می‌رود. مجموعه‌ای از وظایف VPE می‌تواند شامل موارد زیر باشد:سرپرستی و مدیریت مستقیم اعضای تیم‌های فنی و مهندسین تولید محصول.تدوین راهبردها و نظارت بر اجرای کلیه فرآیندهای چرخه توسعه نرم‌افزاری SDLC.اطمینان از اجرای فرآیندهای درست توسعه نرم‌افزاری در تعامل با دپارتمان‌های همکار.نظارت بر فرآیندهای جذب و استخدام نیروهای فنی.تعامل و همکاری در اجرای تحقیقات بازار و محصول‌های فناور.تولید راهبردهای فنی سازمان از جمله تنظیم نقشه راه فنی در تعامل با CTO.ایفای نقش معمار سطح بالای نرم‌افزار و نظارت بر معماری نرم‌افزار توسط افراد فنی.نظارت بر اجرای وظایف تیم‌های فنی و تضمین خروجی‌ها در ددلاین تعیین شده.تضمین کیفیت نرم‌افزار با ارائه فرآیندها و چرخه تست استاندارد STLC.مدیریت بودجه دپارتمان فنی با تکیه بر توسعه نرم‌افزار و زیرساخت.تعامل با همکاران ارشد سایر دپارتمان‌ها در جهت تدوین نیازمندی‌های فنی سمت محصول.مقایسه با CTOاز منظر مدیریت افراد، CTO معمولا تیم‌های کوچکتری از توسعه‌دهندگان را مدیریت می‌کند و بیشتر تمرکز وی بر روی تحقیق و توسعه فنی، تدوین راهبردهای فنی و پیشنهادات در خصوص استفاده از فناوری‌های جدید در سطح راهبردی است. تولید فرم‌های جدیدی از فناوری در جهت تامین نیازهای کسب‌وکار و بهبود فرآیندها یکی از عمده وظایف CTO به شمار می‌رود. همچنین مدیریت و نظارت بر فرآیندهای زیرساخت نیز به عهده CTO خواهد بود. CTO باید سعی داشته باشد تا فناوری را به همه بخش‌های سازمان و محصول‌های فنی تزریق نماید. علاوه بر تامین فناوری‌های مورد نیاز، دریافت بازخورد در خصوص بهبود مستمر فناوری‌ها در محصول‌ها و بخش‌های سازمان از اهمیت زیادی برخوردار است که بر عهده CTO خواهد بود. علاوه بر این، وقتی تغییری در راستای یک فناوری خاص به وجود بیاید، لازم است این تغییرات در محل‌های مناسب تطبیق داده شده و با افراد مرتبط در میان گذاشته شود و راهکارهای خلاقانه‌ای جهت گذار از آن تغییرات ارائه شود. به صورت کلی، تفاوت‌های محسوس بین VPE و CTO در حوزه‌های زیر خواهد بود: اندازه تیم‌ها: معمولا VPE تجربه و مسئولیت مدیریت تیم‌های با سایز بزرگتر را دارد در حالی که CTO تیم‌های فنی کوچکتری را مدیریت می‌کند.عملکرد در تولید محصول: VPE بر روی تمام مراحل ساخت و ارائه یک محصول باکیفیت به تیم محصول تمرکز دارد در حالی که CTO بیشتر بر روی چشم‌انداز فناوری و بهبود زیرساخت آن متمرکز است.مدیریت افراد: مدیریت افراد تیم‌های فنی و راهبران فنی به عهده VPE است در حالی که CTO روی مدیریت افراد تیم‌های توسعه فناوری، R&D و زیرساخت تمرکز دارد.بررسی عملکرد: ارزیابی عملکرد فنی افراد و فرآیندهای ارزیابی کیفیت محصول با VPE است. در مقابل CTO ارزیابی فناوری‌های مورد استفاده در محصول‌ها، زیرساخت و امنیت نرم‌افزاری را بر عهده دارد.راهبرد: VPE بیشتر روی تدوین راهبردها و فرآیندهای تیم‌های فنی که به تولید محصول فناور منجر می‌شوند، کار می‌کند در حالی که CTO روی تدوین راهبردهای کلان فناوری مانند راهبردهای بکارگیری هوش مصنوعی تمرکز دارد. فرهنگ: VPE بیشتر روی فرهنگ توسعه فنی در تیم‌های مهندسی تمرکز دارد در حالی که CTO روی فرهنگ فناوری در کل سازمان و در همه ابعاد کسب‌وکار، محصول، مالی، مشتریان و بازاریابی تمرکز خواهد کرد.جمع‌بندینقش VPE در شرکت‌های ساخت‌یافته و گذر کرده از مرحله startup می‌تواند مورد استفاده قرار گیرد. این نقش به عنوان مکملی برای CTO، به صورت مشخص روی فرآیندها و عملیات بخش مهندسی نرم‌افزار در توسعه محصول‌های فناور تمرکز دارد. VPE یک نقش راهبردی و ارشد در سازمان به شمار می‌رود و تفکیک وظایف آن به صورت قراردادی ولی کارا، با هماهنگی بین CTO و مدیرعامل تدوین می‌شود. در این مقاله به عمده وظایف متداول VPE و تفکیک آن با وظایف CTO پرداختیم. البته که تمامی وظایف می‌تواند به یک نفر هم برسد همانطور که در بیشتر سازمان‌های کوچک و متوسط این چنین است. اضافه شدن یک عنصر فناور در لایه مدیریتی ارشد اول از همه به بلوغ سازمان مرتبط است و در وهله دوم به تدوین درست فرآیندها ارتباط دارد. در صورت موفقیت‌آمیز بودن این چرخه، حضور VPE می‌تواند به مقیاس‌پذیری در تیم‌های توسعه و افزایش کیفیت در خروجی محصول‌های فنی کمک کند. منابعElaine Chen, "The difference between a CTO and a VP Engineering," June 15, 2014, Last Access August 5, 2023, Access via this link.Indeed Editorial Team, "CTO vs VP of engineering: What's the difference?," Updated January 22, 2023, Access via this link.Editorial Team, "What Does a VP of Engineering Do?," February 14, 2022, Access via this link. مهران علیدوست نیا | Mehran Alidoost Nia مهران علیدوست نیا | Mehran Alidoost Nia Mon, 07 Aug 2023 18:52:48 +0330