آپاچی Mesos : چارچوبی برای ساخت سامانه های توزیع شده

در این اپیزود که درآگوست ۲۰۱۵ منتشر شده است، جف میرسون با بنجامین هایندمن مصاحبه می‌کند. بنجامین، همکار در تولید Apache Mesos بوده که یک پروژه متن باز است کهCPU، حافظه، فضای ذخیره‌سازی و دیگر منابع کامپیوتر را از ماشین انتزاع می‌کند و این امکان را فراهم می‌کند که سیستم‌‌های تحمل‌پذیر خطا و توزیع‌شده منعطف، به سادگی تولید شده و به صورت کارا اجرا شوند. بنجامین مدتی را به عنوان مهندس ارشد در توییتر گذرانده و اکنون در Mesosphere مشغول است.

خیلی ممنون که دعوتم کردید.

قطعاً. این سؤال خوبی است. فکر می‌کنم واقعاً جالب باشد زیرا همانطور که در مقاله مارک کویج که شما ارجاع دادید گفته شده است، در حال حاضر تقریباً همه دارند یک سیستم توزیع شده می‌‌سازند. اغلب افراد لزوماً متوجه نیستند که یک سیستم توزیع شده می‌سازند اما جزء ذاتی بیشتر نرم‌افزارهایی است که امروزه می‌سازیم چرا که این نرم‌افزارها یا لازم است حجم خیلی خیلی زیادی از ترافیک را رسیدگی کنند و یا اینکه مجبورید چندین عدد از آن‌ها را اجرا کنید تا خرابی‌ها را تحمل کنید. بنابراین فکر می‌کنم به نوعی همه دارند سیستم‌های توزیع‌شده می‌سازند هرچند شاید متوجهش نباشند.

مطلب واقعاً جالب در این مورد این است که سیستم‌های توزیع‌شده در بیشتر دوره‌های رسمی علوم کامپیوتر دانشگاه‌ها تدریس نمی‌شود. به خاطر دارم که وقتی در مقطع کارشناسی در دانشگاه واشنگتن درس می‌خواندم فقط یک کلاس سیستم‌های توزیع‌شده برای دانشجویان ارشد بود. شاید شروع کرده باشند که کلاسی هم برای دانشجویان کارشناسی بگذارند اما در اغلب مواقع تدریس نمی‌شود. بنابراین اغلب افراد این اطلاعات را یا از همکاران‌شان و یا در کتاب‌ها و صفحات وب و … می‌یابند که البته مبحث پیچیده‌ای است، به نوعی پردازش موازی (Parallel Computing) است با این تفاوت که [انتظار] خرابی‌ها (Failure) هم وجود دارد بنابراین از آن هم سخت‌تر است.

در حال حاضر وقتی که از این سیستم‌ها استفاده می‌کنید باید نوعی از مدیریت حافظه را هم داشته باشید البته منظورم مدیریت حافظه به آن شکلی که در C یا C++ وجود دارد نیست؛ [منظورم این است که] وقتی می‌خواهید انتخاب کنید که کدام بخش از حافظه را می‌خواهید، سیستم‌عامل نوعی انتزاع برای‌تان فراهم می‌کند، سیستم‌عامل برای‌تان VMM (مخفف Virtual Memory Manager) فراهم می‌کند که کارها را خیلی خیلی ساده‌تر می‌کند اما وضعیت امروزی سیستم‌های توزیع‌شده این است که هر کسی مجبور است همه این کارها را دستی انجام دهد و تقریباً همه مجبورند که چرخ را دوباره اختراع کنند که باعث شده سیستم‌های توزیع‌شده تا این حد ناخوشایند‌تر و تولیدشان دشوارتر و احتمال خرابی‌شان بیشتر شود. بنابراین فکر می‌کنم امروزه شرایط سیستم‌های توزیع‌شده این چنین است و خوب هم هست چون فرصت بزرگی برای ساده‌تر کردن چشمگیر سیستم‌های توزیع‌شده مهیا شده است.

قطعاً. فکر می‌کنم در حال حاضر مسائلی وجود داردکه هر سیستم توزیع‌شده‌ای باید آن را حل کند. به عنوان مثال اگر بخواهید به منظور توزیع‌شدگی، برنامه یا پراسسی را بر روی ماشین دیگری راه بیاندازید، بیشترِ آن را خودتان برنامه‌نویسی می‌کنید؛ یا باید کس دیگری نوعی کارگزار (Agent) برای‌تان بر روی آن ماشین قرار داده باشد یا باید خودتان روش راه انداختنش را بیابید. مثال دیگر، انتخاب پیشوا (Leader) است. در اکثر سیستم‌های توزیع‌شده مفهومی هست که مشخص می‌کند اکنون پیشوا یا هماهنگ‌کننده کیست. برای تشخیص اینکه چه کسی می‌تواند پیشوا باشد به الگوریتم‌های پیچیده‌ای نیاز دارید که در صورت [وجود احتمال] خرابی دشوارتر هم خواهد شد. ابزارهایی مانند ZooKeeper و etcd برای این منظور وجود دارند که واقعاً کمک می‌کند و مشکل را خیلی ساده‌تر می‌کند اما همچنان خیلی کارها هست که باید انجام دهید و موارد گمراه‌کننده زیادی وجود دارد که خودتان باید حلش کنید.

مثال دیگر، رسیدگی به خرابی‌ها است. اگر وظایفی (Task) را بر روی ماشین‌های دیگر توزیع کرده باشیم و آن ماشین‌ها خراب شوند چه باید بکنیم؟ بسیار خوب، آن وظیفه را برای اطمینان بر روی ماشین دیگری راه می‌اندازیم اما اگر آن ماشین [خراب‌شده] برگردد آیا به این موضوع توجه کرده‌ایم که وظیفه اولی را کشته‌ایم و آن را بر روی ماشین دیگری راه انداخته‌ایم؟ در سیستم‌های توزیع‌شده، این مشکل کاملاً رایجی است. شما می‌خواهید اطمینان یابید که وقتی پراسسی بر می‌گردد آن را از بین خواهید برد. رسیدگی به این مطلب خودش ماجرای دیگری است.

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

به موضوع مدیریت حافظه مجازی برگردیم. هدف حافظه مجازی، این است که افراد را کارآمدتر کند؛ اینکه افراد بتوانند بر روی اصل کارکرد سیستم توزیع‌شده‌شان متمرکز شوند نه اینکه فقط بر روی زیرساخت‌ها تمرکز کنند البته زیرساخت‌ها هم واقعاً مهم هستند اما نیازی نیست که همه آن‌ها را بسازند. این‌ها همان چیزهایی است که سیستم‌عامل و کرنل فراهم می‌کنند. آن‌ها انتزاع‌هایی فراهم می‌کنند که تولید نرم‌افزار را برای افراد ساده‌تر می‌کند تا لازم نباشد همه افراد چیز دقیقاً یکسانی را بسازند. من فکر می‌کنم مثال مدیر حافظه مجازی از این جهت خیلی جالب است که خیلی‌ها باور نداشتند که VMM هیچ‌گاه موفق شود زیرا فکر نمی‌کردند که چیزی بیاید که چنین امری را انتزاع کند و در عین حال کارایی (Performance) خوبی داشته باشد یا همواره درست عمل کند. خیلی‌ها می‌‌گفتند: نه، ما از VMM استفاده نخواهیم کرد، این به یک چیز واقعی مبدل نخواهد شد. اما دانشمندان کامپیوتر، آن را مطرح کردند و گفتند: نه، این روشی است که ما باید در آینده آن را در نرم‌افزارها انتزاع کنیم. و امروزه این امری است که مزیت واقعی ایجاد کرده است. من فکر می‌کنم در مورد سیستم‌های توزیع‌شده هم مشابهت‌هایی وجود دارد. برخی‌ها با خود فکر می‌کنند که: آیا واقعاً به این حد از انتزاع نیاز داریم؟ آیا چنین‌ چیزی را می‌خواهیم؟ اما من فکر می‌کنم که هر روزه افراد بیشتری، این چیزها را تولید می‌کنند، فکر می‌کنم اگر به گذشته نگاه کنیم می‌بینیم انتزاع‌های زیادی خلق کرده‌ایم که واقعاً کمک‌ کرده‌اند و کارآمدترمان کرده‌اند و موجب شده‌اند که کدها امن‌تر شده، کمتر کرش کنند و مستحکم‌تر باشند.

وقتی ما پروژه را آغاز کردیم، آنچه در آن زمان بر رویش تمرکز داشتیم Hadoop بود. در‌ واقع می‌خواستیم بتوانیم دو کار را انجام دهیم. یکی این بود که بتوانیم چندین Hadoop را همزمان اجرا کنیم که هدف اولیه ما بود چون ما Hadoop های زیادی در برکلی اجرا می‌کردیم و تحقیقات زیادی خاصه تحلیل‌های کلان داده‌ای (Big Data) با Hadoop می‌کردیم که آن زمان و همین حالا هم موضوع پرطرفداری است.

اما چرا می‌خواستیم چندین Hadoop اجرا کنیم؟ چندین دلیل داشت. یکی اینکه می‌خواستیم بین Hadoop هایی که در حال اجرا است، انزوای خطا (Fault Isolation) داشته باشیم. یعنی وقتی که شخصی یک Job جدیدی را وارد می‌کند که موجب خطایی می‌شود به جای اینکه همه Hadoop کرش کند، می‌خواستیم در عوض، یک Hadoop در حال اجرا برای محصول‌مان داشته باشیم که بدانیم Jobهایی که روی آن اجرا شده‌اند برای مدت طولانی در حال اجرا می‌مانند و همواره کار می‌کنند و در عین حال یک Hadoop تجربی هم داشته باشیم که هرکسی در آزمایشگاه بتواند Jobهای MapReduce را در آن، قرار دهد؛ Jobهایی که کسی نمی‌داند چه کاری ممکن است بکند، ممکن است کلاستر را از کار بیاندازد یا منابع را به کلی مصرف کند اما اشکالی ندارد چون آن Hadoop مستقل از دیگری است.

دقیقاً همین‌طور است. ما ۹ ماشین در کلاستر‌مان داشتیم و می‌خواستیم Hadoop مربوط به محصول و Hadoop تجربی را بر روی همان ۹ ماشین داشته باشیم. می‌خواستیم به جای اینکه ۵ ماشین را برای نسخه محصول و ۴ ماشین را برای نسخه تجربی بگذاریم، همه را یک جا داشته باشیم. می‌خواستیم اگر محصول ما به ۵ ماشین نیاز داشت، در اختیارش باشد اما وقتی به آن ۵ تا نیازی نداشت و تنها به دو عدد از آن‌ها نیاز داشت، Hadoop تجربی بتواند از ۷ ماشین دیگر استفاده کند یعنی بتوانیم بصورت پویا و منعطف، منابع را بین Hadoop مربوط به محصول و Hadoop تجربی جابجا کنیم.

کار به این ترتیب آغاز شد و ما ابتدا بر روی یک مدیر کلاستر تمرکز کرده بودیم زیرا پروژه‌های مدیریت کلاستر و مدیریت منابع زیادی وجود داشته است مثلاً PBS (مخفف Portable Batch System) هست که تاریخچه‌اش فکر می‌کنم به سال ۱۹۹۱ برگردد. بنابراین چیز جدیدی نیست و پردازش گرید (Grid Computing) مدت زیادی است که وجود دارد. ما به این ابزارهای مدیریت کلاستر نگاه کردیم و با خود گفتیم می‌توانیم از این ابزارها استفاده کنیم تا به هدف اجرای چندین Hadoop بصورت همزمان برسیم اما متوجه شدیم که فرصت‌های زیادی وجود دارد که ایده مدیریت کلاستر را خیلی خیلی بهتر کنیم و وقتی داشتیم این کار را می‌کردیم متوجه شدیم که اگر یک سطح انتزاع بین ماشین‌هایی که در حال اجرا هستند و سیستم توزیع‌شده‌‌ای که Hadoop بر روی آن اجرا می‌شود، قرار دهیم می‌توانیم تولید سیستم‌های توزیع‌شده جدید را آسان‌تر کنیم. پیدایش کار از اینجا بود. یکی از اولین سیستم‌های توزیع‌شده‌ای که روی Mesos ساختیم، Spark بود. Spark که الان خودش یک پروژه Apache خیلی محبوب در تحلیل‌های بزرگ، شده است در واقع، یک سیستم توزیع‌شده بود که ما در طی حدود یک هفته بر روی Mesos ساختیم و در واقع، به نوعی بچه‌ آن بود و یک مثال در این زمینه که می‌توان خیلی ساده یک سیستم توزیع‌شده را بر روی Mesos ساخت.

حتماً پردازش جریان را انجام می‌دهد اما می‌تواند دسته کارهای مشابه MapReduce را هم انجام دهد. وقتی ما داشتیم Spark را می‌ساختیم گفتیم بگذار همه چیز را در حافظه بگذاریم، این همان نکته جالب در مورد Spark است. وقتی با MapReduce پردازش می‌کنید، وقتی یک چرخه (Iteration) از Job را انجام می‌دهید اغلب، همه چیز را از دیسک می‌خوانید، آن را پردازش کرده و دوباره همه چیز را در دیسک می‌نویسید و وقتی می‌خواهید چرخه دوم آن Job را انجام دهید باید دوباره همه چیز را از دیسک بخوانید. اما در Spark می‌گوییم چرا خروجی‌ها را در حافظه نگه نداریم تا وقتی گام دوم Job را انجام می‌دهیم بتوانیم از حافظه بخوانیم که خیلی خیلی سریع‌تر خواهد بود. به این ترتیب می‌توانیم کارهای چرخه‌ای (Iterative) که در یادگیری ماشین (Machine Learning) بسیار متداول است را نسبت به حالت اجرا بر روی Hadoop، صد برابر سریع‌تر انجام دهیم. اما آن زمان در واقع، این جنبه‌اش برای ما جذاب بود که توانسته‌ایم با حدود ۱۰۰۰ خط کد، یک سیستم توزیع‌شده با ویژگی‌های تحمل‌پذیری خطا و دسترس‌پذیری بالا (Highly Available) بسازیم که می‌تواند بر روی هزارها ماشین اجرا شود. البته از آن روز، Spark تکامل چشمگیری داشته است اما خیلی از عملکردهای اصلی آن و این ایده که خروجی‌ها را در حافظه نگه داریم و دوباره استفاده کنیم، از همان ۱۰۰۰ خط کد اولیه می‌آید.

اما به سئوال شما برگردیم که وقتی روی این پروژه کار می‌کردیم واقعاً می‌خواستیم چه امکان و راه‌حلی را فراهم کنیم. فکر می‌کنم اولین کاری که می‌خواستیم بکنیم استفاده کارآمد از منابع موجود بر روی ماشین‌های یکسان برای چندین سیستم توزیع‌شده بود که همزمان از آن‌ها استفاده می‌کردند. این هدف، خیلی خیلی سریع به آنجا تکامل یافت که اگر بتوانیم نوعی مدیریت کلاستر داشته باشیم که شکل تکامل‌یافته‌تر [ابزارهای] مدیریت کلاستر [قبلی] باشد و در عین حال، یک لایه انتزاعی و یک سری مواد اولیه (Primitive) را برای تولید سیستم‌های توزیع‌شده فراهم کند، در آنصورت می‌توانیم امکانات خیلی گسترده‌تری فراهم کنیم. اینجا بود که فضای جدیدی به روی ما گشوده شد و فهمیدیم که چیزهای خیلی بیشتری می‌توانیم فراهم کنیم و دیگر کاربردش تنها برای اجرای Hadoop و تحلیل‌های دسته‌ای نیست بلکه افراد می‌توانند هر نوع سیستم توزیع‌شده‌ای که بخواهند را بسازند و اجرا کنند. ابتدای کار، ما به کاربردهای تحلیل و MPI (مخفف Meaage Passing Interface) فکر می‌کردیم که هنوز هم در آزمایشگاه‌های ملی و دانشگاه‌ها خیلی کاربرد دارد اما این‌ها گسترش یافت و فهمیدیم که می‌توانیم وب‌سرورها و هر چیز دیگری که در حیطه معماری سرویس‌‌گرا باشد را اجرا کنیم. در‌ واقع آن زمان بود که توییتر Mesos را انتخاب کرد، آن‌ها داشتند نرم‌افزارشان را به سرویس‌هایی می‌شکستند و فهمیدند که می‌توانند از Mesos برای اجرای آن سرویس‌ها استفاده کنند، بعداً [استفاده آن‌ها از Mesos] گسترش یافت و نه تنها برای سرویس‌ها[ی اصلی] بلکه برای Memcached ها و Redis ها و Jenkins ها (به منظور Build، تست و …) هم از آن استفاده کردند. این‌ها گسترش یافت تا اینکه ما امروزه در مورد Mesos این فکر را داریم که شما می‌توانید بوسیله آن هر نوع سیستم توزیع‌شده و برنامه کاربردی را در جایی بر روی مرکز داده‌های خود اجرا کنید.

حتماً. در سال ۲۰۱۰ از من خواسته شد که به توییتر بروم و صحبتی داشته باشم. در آن زمان ما با یک گروه تحقیقاتی در توییتر صحبت کردیم. آنجا دسته‌ای از افراد بودند که از گوگل آمده بودند، آن‌ها در گوگل از تکنولوژی که Borg نامیده می‌شد استفاده می‌کردند که یک سیستم مدیریت کلاستر بود که همه برنامه‌های کاربردی خود را روی آن اجرا می‌کردند. در آن زمان، توییتر یک نرم‌افزار یکپارچه (Monolithic) و عظیم [روی پلتفرم] Rail داشت که مونوریل 🙂 خوانده می‌شد. اشکالزدایی آن نرم‌افزار واقعاً خسته‌کننده بود و کار واقعاً سختی بود، وقتی تغییری می‌دادید باعث می‌شد بخش دیگری از کدها، کرش کند و … .

به دلایل مختلفی، توییتر به این نتیجه رسید که باید از این نرم‌افزار یکپارچه Ruby on Rail به یک سیستم مبتنی بر SOA تکامل یابد و تعداد زیادی سرویس‌های کوچک‌تر -که امروزه خیلی‌ها آن‌ها را ریزسرویس (Microservice)می‌خوانند- داشته باشد که در آن همه سرویس‌ها تحت یک نوا با یکدیگر تعامل کرده تا همان عملکردی که در آن نرم‌افزار عظیم Rail بود را فراهم کنند. پیش از آن هم، در ارتباط با مسأله استقرار، به علت بزرگی مقیاسی که داشتند، کار سخت و چشمگیری داشتند، آن‌ها باید ده‌ها هزار از این سرورهای Ruby را اجرا می‌کردند اما آن زمان تقریباً یک چیز منفرد بود که مستقر می‌کردید، تنها همان یک نرم‌افزار Ruby را مستقر می‌کردید؛ بسته به اینکه چه نسخه‌ای را مستقر می‌کردید پیچیدگی‌هایی وجود داشت اما باز هم یک نرم‌افزار و یک روش استقرار وجود داشت. اما وقتی که به SOA تکامل یافتند، از یک نرم‌افزار به ۵ تا و بعد ده‌ها، صدها و هزارها 🙂 نرم‌افزار رسیدند و مشکل خیلی خیلی سخت‌تر شد. تکامل دیگری که توییتر داشت [در افزایش زبان‌ها بود] که از Ruby به Ruby و جاوا و بعد، Ruby و جاوا و Scala و بعد، Ruby و جاوا و Scala و Python و … گسترش یافت، کدهای C++ زیادی هم آنجا هست. بنابراین برای تیم عملیات، مدیریت و مستقر کردن این همه سرویس مختلف، سخت‌تر شد. مدیریت بزرگ شدن مقیاس این مشکل، برای آدم‌ها کار دشواری است زیرا اگر بخواهید مدیریت این سرویس‌ها را به آدم‌ها بدهید برای هر تیمی نیاز به یک دسته آدم دارید.

بنابراین آن‌ها Mesos را به عنوان یک فرصت دیدند که یک لایه انتزاعی می‌سازد تا تیم‌ها خودشان نرم‌افزارهایشان را در مرکز داده‌شان مستقر کنند. در توییتر یک مرکز داده بود اما در مورد فضای ابری هم همین صادق است؛ مرکز داده‌، مجموعه‌ای از ماشین‌هاست حال چه فیزیکی باشد چه مجازی.

شما در مورد تفاوت رهیافت Mesos با کاری که توییتر در آن زمان انجام می‌داد، پرسیدید. کاری که توییتر در‌واقع در آن زمان انجام می‌داد این بود که از تعداد زیادی Puppet استفاده می‌کردند. از Puppet استفاده می‌کردند تا بگویند بر روی فلان ماشین فلان نرم‌افزار اجرا شود، آنجا کارهای دستی زیادی وجود داشت و پارتیشن‌های کاملاً استاتیکی وجود داشت و همان مشکلی که در مورد Hadoop گفتم وجود داشت: اینکه روی هر ماشین یک نرم‌افزار نصب می‌کردید که به این معناست که باید ماشینی بخرید که دقیقاً متناسب با آن نرم‌افزار باشد اما واقعاً خیلی سخت است زیرا چه کسی می‌داند که یک نرم‌افزار از روزی که آغاز به کار می‌کند -یعنی همان روزی که از شما در مورد منابع مورد نیاز سئوال می‌شود- تا روزی که پایان می‌یابد به چه مقدار منابعی نیاز خواهد داشت؟

خاطرم نیست اما فکر می‌کنم وقتی به توییتر رفتم بین ۱۰ الی ۱۵ نوع صف برای ماشین‌هایی که خریداری می‌شد، وجود داشت که کار عملیات را حتی سخت‌تر هم می‌کرد زیرا انواع ماشین‌های خیلی زیادی وجود داشت و انواع سخت‌افزارهای خیلی زیادی باید مدیریت می‌شد. اگر چیزی خراب می‌شد شما فقط زحمت جایگزین کردن آن را نداشتید و باید می‌رفتید و یک جایگزین خاص برای آن می‌خریدید. بنابراین تیم ما در توییتر متوجه شدند که می‌توانیم این کار را ساده کنیم و صف‌های خرید کمتری داشته باشیم و مسئولیت تیم ظرفیت‌سنجی فقط این باشد که مطمئن شوند که برای اجرای همه نرم‌افزارها به میزان کافی ظرفیت وجود دارد و مسئولیت Mesos و تیم Aurora این باشد که همه این نرم‌افزارها را مستقر کرده و اجرا کند. Aurora عنوان سیستم توزیع‌شده‌ای است که برای این منظور بر روی Mesos ساخته بودیم. مسئولیت آن‌ها این بود که وظایف را برای اجرا روی این ماشین‌ها برنامه‌ریزی کنند و اطمینان یابند که در حالت خطا اجرایشان ادامه می‌یابد. به این ترتیب ماشین‌ها می‌توانستند به سادگی در کلاستر افزوده شوند و وقتی که در کلاستر قرار می‌گرفتند به دام افتاده و در همان لحظه به منابع حاضر تبدیل می‌شدند و می‌توانستیم پردازش‌ها را روی آن‌ها زمانبندی کنیم. تیم عملیات دیگر لازم نداشتند که با همه توسعه‌دهنده‌های نرم‌افزارها، هماهنگ کنند که چه زمانی ماشین‌ها می‌رسند و چه زمانی آماده استفاده هستند و توسعه‌دهنده‌ها می‌توانستند هر جایی که منابع مورد نیازشان در دسترس باشد، نرم‌‌افزارهایشان را راه بیاندازند حتی اگر منابع موجود در ظرفیت‌سنجی‌ها برای آن‌ها تخصیص داده نشده بود؛ البته در‌واقع اغلب اینطور نیست، اغلب به این شکل است که شما برنامه‌ریزی ظرفیت‌ در مورد میزان منابع مورد نیاز نرم‌افزارتان را انجام می‌دهید اما می‌توانید بلافاصله نرم‌افزارتان را اجرا کنید زیرا ظرفیت مورد نیاز را همان موقع در دسترس دارید. این خیلی خوب است زیرا می‌توانید سیستم توزیع‌شده را بلافاصله تست کنید و نیازی نیست که ماه‌ها صبر کنید تا ماشین‌ها برسد و وقتی در نهایت آن ماشین‌ها رسیدند، در واقع به عنوان ظرفیت در دسترس برای تیم بعدی عمل می‌کنند.

مزیت بزرگ دیگر این است که برای انجام تعمیرات، نیازی نیست که با توسعه‌دهنده‌های نرم‌افزار هماهنگ کنیم. در گذشته اینطور بود که از آنجاییکه از Puppet برای استقرار نرم‌افزارها بر روی ماشین‌ها استفاده می‌شد، وقتی می‌خواستید هر نوع تعمیراتی بر روی آن ماشین‌ها داشته باشید باید به سراغ تیمی که بر روی آن ماشین‌ها نرم‌افزار داشتند می‌رفتید و می‌گفتید که می‌خواهید برای آن ماشین‌ها تعمیرات داشته باشید بنابراین ظرفیت کمتری برای نرم‌افزار‌هایشان خواهند داشت. و آنان باید با هر نوع ترفندی این کمبود ظرفیت را جبران می‌کردند اما الان دیگر این کار را نمی‌کنید و در عوض، تیم عملیات می‌تواند برود و هر Job ای را بکُشد؛ آن‌ها به این کار، خالی کردن ماشین (Drain the Machine) می‌گویند. آن‌ها می‌توانند ماشین را خالی کنند چون نرم‌افزار جای دیگری در کلاستر، مجدداً راه‌اندازی خواهد شد. بعد از اینکه ماشین را خالی کردند می‌توانند آن را برداشته و هر نوع تعمیری که بخواهند چه نرم‌افزاری باشد و چه سخت‌افزاری انجام دهند. بنابراین در توییتر چنین تکاملی رخ داده است. علت این تکامل، این حرکت به SOA و مزیت بزرگی است که چنین تکاملی نسبت به استفاده از Puppet یا Chef و ابزارهای اینچنینی دارد.

چند مورد مختلف وجود دارد. این بستگی به نرم‌افزار توییتر دارد اما به اختصار، ما یک سیستم آلارم داریم که مقدار منابعی که توسط هر نرم‌افزار مصرف می‌شود و SLA ای که در واقع برآورده کرده‌اند را می‌گوید. و بسته به اینکه چه نرم‌افزاری باشد ممکن است یک فردی بیاید و بگوید که نمونه‌های بیشتری می‌خواهد و از Aurora برای این منظور استفاده کند. همانطور که گفتم Aurora ابزاری است که در توییتر نوشته شده و برنامه‌ریزی سرویس‌ها را انجام می‌دهد، به نوعی، واسطی است که در گذشته به منظور پلتفرم به عنوان سرویس (Platform as a Service) داشته‌ایم و برنامه‌نویس‌ها در نهایت از آن برای راه‌اندازی نرم‌افزار‌هایشان استفاده می‌کردند.

بنابراین بله، اگر یک هجمه ترافیک وجود داشته باشد که اغلب هنگامی رخ می‌دهد که خبرهای مهمی اعلان می‌شود، در آنصورت یک تیم می‌تواند بلافاصه تعداد نمونه‌های نرم‌افزارش را به مقدار منابع آزاد موجود در هر کجای کلاستر افزایش دهد. روشی که ما تضمین می‌کنیم منابع کافی برای این نرم‌افزارها داریم از طریق مفهوم سهمیه (Quota) است. شما یک سهمیه از محصول عملیاتی دارید که همواره تضمین می‌شود در سیستم، ظرفیت کافی برای رسیدن به آن وجود دارد و اگر لازم باشد که منابع را از نرم‌افزارهای دیگر بازپس‌ بگیریم یا جایگزین کنیم، این‌ کار را می‌کنیم. این کار اشکالی ندارد چون فکر می‌کنم خیلی‌ها متوجه نیستند که هزارها چیز است که ممکن است در این مراکز داده به خطا بخورد و منابع را مصرف کنند و شما می‌توانید به راحتی آن‌ها را بکُشید. موردی که خیلی افراد عموماً در مورد آن فکر می‌کنند تحلیل است اما تحلیل بهترین مثال نیست چون برخی مواقع نمی‌توانید [پردازش‌های مربوط به] تحلیل را بکشید زیرا واقعاً مهم است که تمام شوند زیرا آن‌ها برای کارهایی مانند نمایش آمارها به کاربر هستند که مثلاً چه تعداد از کاربران یک توییت را دوباره توییت کرده‌اند یا چه تعداد از کاربران آن را دنبال کرده‌اند و برای گروه خاصی از افراد چه مقدار مشارکت ایجاد کرده است یا در توییتر، همچنین می‌تواند [تخمین] آمار تعداد افرادی باشد که براساس توییت‌ها، یک برنامه تلویزیونی را شب گذشته دنبال می‌کرده‌اند. برخی از این Jobها، واقعاًJobهای حیاتی محصول عملیاتی هستند اما حجم زیادی از Jobهای اجرا شده در مراکز داده هم هستند که می‌توان منابع را از آن‌ها بازپس‌گرفت، چیزهایی مانند Buildها و تست‌ها و دیگر Jobهای موردی که افراد در حال امتحا‌نش هستند. بنابراین اگر نیاز بود می‌توانیم منابع را از اینگونه Jobها بگیریم تا مطمئن شویم که Jobهای مربوط به محصول عملیاتی، منابع لازمشان را می‌گیرند و می‌توانند حجم ترافیک‌شان را رسیدگی کنند. تأکید می‌کنم اینکه روش آن بصورت خودکار باشد یا اینکه خود تیم توسعه محصول بیایند و تقاضای نمونه‌های جدید بکنند، بستگی به خود نرم‌افزار دارد.

بله، Mesos تجسدی از چیزی است که بصورت سنتی در سیستم‌های توزیع‌شده به آن معماری ارشد/کارگزار (Master/Slave) می‌گوییم که به این معنی است که گره‌های ارشد و گره‌های کارگری وجود دارند که مسئول مدیریت وظایفی (Task) هستند که راه‌اندازی شده‌اند.

دقیقاً درست است. وقتی شما Mesos را اجرا می‌‌کنید بسته به درجه‌ای از خرابی که می‌خواهید بتوانید رسیدگی کنید، معمولاً ۳ تا ۵ ارشد را اجرا می‌کنید و بعد به تعدادی که بخواهید گره‌هایی اجرا می‌کنید که به ارشد متصل شوند. خود ماشین‌هایی که گره‌های Mesos را بر روی آن‌ها اجرا می‌کنید می‌توانند هرچقدر بخواهید همگن (Homogeneous) یا ناهمگن (Heterogeneous) باشند، مثلاً لازم نیست که همه آن‌ها ۸ هسته‌ای با ۱۶ گیگابایت حافظه باشند، می‌تواند برخی از آن‌ها ۳۲ هسته‌ای ۱۲۸ گیگابایتی و برخی ۲ هسته‌ای ۸ گیگابایتی باشند. می‌توانید آن‌ها را در ترکیب با هم استفاده کنید زیرا هدف Mesos تنها این است که این انباره بزرگ منابع را فراهم کند که شما بتوانید همه وظایف خود را در بستر آن اجرا کنید. به این خاطر است که می‌گویم شما می‌توانید به صورت طبیعی کلاستر خود را بزرگ کنید به این ترتیب که هر چند ماشینی که دارید را کنار هم قرار داده و یک کلاستر بسازید و بعداً اگر خواستید آن را به شکل همگن یا ناهمگن تکامل دهید.

همه این ماشین‌ها به گره‌های ارشد متصل می‌شوند، در هسته ارشد، چیزی است که تخصیص‌دهنده (Allocator) نامیده می‌شود. تخصیص‌دهنده باید از همه وظایفی که در سیستم در حال اجرا هستند و همه منابعی که آزاد و در دسترس هستند، باخبر باشد و بتواند آن منابع را به سیستم توزیع‌شده‌ در حال اجرا، تخصیص دهد. آن سیستم توزیع‌شده همانطور که اشاره کردم مثلاً می‌تواند Aurora باشد. ما در Mesosphere چیزی داریم که خیلی مشابه با Aurora است و Merathon نامیده می‌شود که مسئول سرویس‌های بلندمدت بدون حالت (Stateless) است. ما به چنین سیستم‌های توزیع‌شده‌ای (Aurora یا Merathon) که روی کار قرار می‌گیرند، فریم‌ورک می‌گوییم، در‌واقع از عنوان فریم‌ورک به جای سیستم توزیع‌شده استفاده می‌کنیم تا توضیح دهیم که آن‌ها در بالا قرار گرفته‌اند.

در داخل فریم‌ورک چیزی وجود دارد که ما به آن ‌زمان‌بند (Scheduler) می‌گوییم که می‌توانید آن را یک هماهنگ‌کننده سیستم توزیع‌شده در نظر بگیرید. این همان چیزی است که بر اساس منابعی که باید تخصیص یابد تصمیم می‌گیرد چه چیزی و در کجا باید اجرا شود زیرا ما می‌خواهیم با یک دید سیستم‌عاملی تلاش کنیم چیزی بسازیم که سیستم توزیع‌شده بتواند بار کاری و وظایف خود را بوسیله آن برنامه‌ریزی کند. این به نوعی مسئله‌ی دشواری است که در این سیستم‌های توزیع‌شده قرار دارد. به این خاطر است که ما به آن زمان‌بند می‌گوییم. برخی وقتی عنوان زمان‌بند را می‌شنوند فکر می‌کنند برای ساختن یک «زمان‌بند» باید دکترای علوم کام‍پیوتر داشته باشند اما منطق کاری‌اش این است که تصمیم بگیرد چه وظایفی را می‌خواهید اجرا کنید و وقتی خرابی پیش می‌آید چه می‌خواهید بکنید. این کار مؤلفه زمان بند است. این مؤلفه چیزهایی که ما به آن پیشنهاد منبع (Resource Offer) می‌گوییم را دریافت می‌کند که در‌واقع پیشنهاد تخصیص منابعی است که سیستم توزیع‌شده می‌تواند برای اجرای نرم‌افزارش استفاده کند. این تخصیص‌ها از تخصیص‌دهنده‌ای (Allocator) می‌آید که همانطور که اشاره کردم بر روی ارشد اجرا می‌شود. همینطور می‌تواند از درخواست‌ها بیاید و قیودی باشد که برای اجرای نرم‌افزارها یا وظایفش باید برآورده شوند.

بله، فریم‌ورک در‌واقع یک سیستم توزیع‌شده است که بر روی Mesos اجرا می‌شود و زمان‌بند (Scheduler) مؤلفه‌ای است که مستقیماً با Mesos در تعامل است و به آن [پیشنهاد] تخصیص منابع داده می‌شود که از آن استفاده می‌کند تا تصمیم بگیرد که کدام وظایف را می‌خواهد در مرکز داده اجرا کند. بنابراین در Mesos، وظیفه (Task) همان چیزی است که در‌واقع اجرا می‌کنیم، چیزی است که منابعی مصرف می‌کند و همان چیزی است که به ما می‌گوید که به چه ترتیب می‌توان آن را تبدیل به یک برنامه کرد، [یعنی اینکه] آیا یک فایل باینری است یا یک اسکری‍پت Shell است یا یک دستورShell است یا یک تصویر Docker است و … . این‌ها روش‌های مختلفی است که می‌توان یک وظیفه را اجرا نمود. شما چنین چیزی به ما می‌دهید و ما آن را اجرا می‌کنیم. اما مجری (Executer) مؤلفه اختیاری یک فریم‌ورک است. شما می‌توانید اساساً فریم‌ورک را هم به شکل یک زمان‌بندی ببینید که وظایف را راه‌اندازی می‌کند و هم به شکل زمان‌بندی ببینید که راه‌اندازی می‌کند که وظایف بعداً توسط مجری‌ها بر روی ماشین‌های مجزا، اجرا شوند.

بنابراین اگر می‌خواهید که تنها یک باینری یا تصویر Docker به ما بدهید و از ما بخواهید که به همان شکل اجرایش کنیم، می‌توانید به همین شکل ادامه بدهید و ما این وظایف را برای شما اجرا خواهیم کرد اما اگر چیزهای خاصی در مورد نحوه اجرای وظایف‌تان وجود دارد که می‌خواهید انجام دهید و می‌توانید آن را در مدلی که ما فراهم کرده‌ایم، برنامه‌نویسی کنید می‌توانید در عوض، یک مجری داشته باشید که وظیفه به آن داده می‌شود و به او گفته می‌شود که: «این وظیفه‌ای است که ز‌مان‌بند خواسته که اجرا کنی و وظیفه توست که نحوه اجرای آن را بیابی.»

خیلی از سیستم‌های توزیع‌شده هستند که با این مدل مجری تطبیق دارند. مثلاً Hadoop مفهومی با عنوان ردیاب وظیفه (Task Tracker) دارد که فکر می‌کنم چیزی باشد که بر روی همه ماشین‌ها اجرا می‌شود و همه Mapها و Reduceها را اجرا می‌کند و آن‌ها را ردگیری کرده و آمارشان را گزارش می‌کند. این با مدل مجری‌ [که در Mesos وجود دارد] تطبیق می‌کند. همان‌طور که اشاره کردم چیزهای دیگری مانند Spark هم هست که خیلی خوب با مدل مجری مطابقت می‌یابد اما البته همه سیستم‌ها نیازمند مدل مجری نیستند. فقط اگر واقعاً به آن نیاز داشتید، این عمل‌کرد برای‌تان در سیستم فراهم شده است.

این‌ها مؤلفه‌های مرکزی هستند. فریم‌ورک یک زمان‌بند دارد، زمان‌بند وظایف را راه‌اندازی می‌کند و اگر بخواهید که نحوه اجرای وظایف را تعریف کنید، یک مجری هم پیاده‌سازی می‌کنید.

دلیلی که ما یک روش تبادل پیام مبتنی بر Actor را برای سیستم‌مان انتخاب کردیم این است که فردی که سیستم‌ توزیع‌شده را می‌سازد را اجبار کنیم که به شرایط خطا فکر کند، به این فکر کند اگر پیام نرسید، چه می‌شود، برای اینکه واقعاً متوجه شود که نمی‌توان فرض کرد که همواره این طبیعت ساده درخواست/پاسخ رخ می‌دهد. این یک دلیل بوده است. بنابراین درخواست کردن در Mesos یک ارسال یک‌طرفه پیام به گره ارشد است که می‌گوید: «من می‌خواهم فلان کار را بکنم!» و بعد، رخداد، هم پیامی است که از Mesos به زمان‌بند برمی‌گردد که می‌گوید: «فلان چیز رخ داده است.»

دلیل دیگر این بود که رخدادهایی اتفاق می‌افتاد که واقعاً به خاطر درخواست‌ها نبود بلکه مواردی بود که رخ می‌داد و باید به زمان‌بند ارسال می‌شد به عنوان مثال اینکه «وظیفه‌ات به خطا خورد!» یا «ماشینی که تعدادی وظیفه بر روی آن اجرا کرده بودی، مُرد!» یا «منابع جدیدی فراهم شده که می‌خواهیم به تو تخصیص دهیم و می‌توانی از آن‌ها استفاده کنی». بنابراین این‌ها چیزهای ناهمگامی (Asynchronous) هستند که رخ می‌دهند و ما می‌خواهیم آن‌ها را بیرون بفرستیم. در مورد برخی از آن‌ها می‌خواهیم تضمین داشته باشیم که به روش مطمئنی آن‌ها را بیرون می‌فرستیم. مثلاً در مورد بروزرسانی‌ داده‌های آماری وظیفه‌ها می‌خواهیم مطمئن باشیم که همواره داده‌های آماری بروزشده را می‌گیرید. اما موردی که می‌خواهیم فقط به کارآمدترین روش ممکن بیرون بفرستیم، در مورد تخصیص منابع است که می‌خواهیم بگوییم: «ما داریم این تخصیص را به تو می‌دهیم؛ اگر در مدت زمان معینی پاسخت را دریافت کنیم آن را مجدداً به تو تخصیص می‌دهیم در غیر اینصورت، ممکن است آن را به کس دیگری تخصیص دهیم.» این مشکلی ندارد زیرا سیستم توزیع‌شده شما ممکن است هنگامی‌ که ما رخدادها را برایتان می‌فرستیم، پایین آمده باشد چون ممکن است زمان‌بندتان به خطا خورده باشد یا ماشینی که روی آن اجرا شده است کرش کند، این‌ها طبیعی است و رخ می‌دهد. ما اینطور فرض نمی‌کنیم که چون شما کرش کرده‌اید باید همه وظیفه‌هایی که راه‌انداخته‌اید نیز کشته شوند. ما آن‌ها را در حال اجرا نگاه می‌داریم و فرض می‌کنیم این خرابی‌ها رخ می‌دهد.

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

این سئوال خوبی است. سنگ‌بناها چیزهای واقعاً جالبی هستند زیرا ارائه نمونه‌های ثانوی این سنگ‌بناها هم آغاز شده است. ما ZooKeeper را داریم اما در همان حال etcd را هم داریم. ما چندین سیستم تبادل پیام داریم، ActiveMQ و RabbitMQ هستند و برخی جایگزین‌های مدرن‌تر سیستم‌های Pub/Sub مانند Kafka را هم داریم. داریم چیزهای بیشتری پیدا می‌کنیم. من مجبورم به این فرم از سئوال پاسخ دهم که دوست دارم آینده به کجا برود چون آینده‌های ممکن زیادی وجود دارد اما من دوست دارم ببینم که در آینده نوعی واسط POSIX برای همه این انتزاع‌ها و مواد اولیه (Primitive) برای سیستم‌های توزیع‌شده فراهم شود تا بتوانیم نرم‌افزار‌های‌مان را با فرض وجود سرویس‌های مانند سرویسPub/Sub یا سرویس صف پیام یا سرویس هماهنگ‌سازی (Coordination) یا سرویس انتخاب پیشوا (Leader Election) و یا … داشته باشیم. من می‌خواهم سیستم توزیع‌شده‌ام را مبتنی بر این واسط بنویسم و اگر در یک سازمان خواستند که از ZooKeeper استفاده کنند و در جای دیگری خواستند از etcd استفاده کنند، این خیلی عالی است که بتوان نرم‌افزار را در هر دو مکان اجرا کرد. این چیزی است که امروزه نداریم اما فکر می‌کنم برای اینکه حرکت رو به جلو داشته باشیم خیلی حیاتی است که کل صنعت بتواند بصورت مؤثر از سیستم‌ها استفاده مجدد بکند. وقتی در مورد سیستم‌عامل [منطبق با] POSIX فکر می‌کنیم، چیزهای زیادی است که قدرش را نمی‌دانیم. چیزهایی مانند لوله‌‌کشی (Pipe) را داریم که می‌توانیم داده‌ها را از یک برنامه به برنامه دیگر لوله‌کشی کنیم. ما واسط فایل را داریم و می‌توانیم از طریق فایل‌ها، اطلاعات را بین نرم‌افزارها به اشتراک بگذاریم. ما مفاهیم پروسس، نخ‌ها (Thread)، تخصیص حافظه را داریم و خیلی چیزهای دیگر که از آن‌ها استفاده می‌کنیم تا نرم‌افزارها را بسازیم که بیشترین مزیت آن -البته نه همه‌اش- این است که می‌توانیم آن نرم‌افزارها را بر روی هر نوع سیستم POSIX چه یک لپ‌تاپ مک باشد و چه یک سرور لینوکس باشد، اجرا کنیم. البته موارد استثنایی هم وجود دارد که POSIX شکست‌خورده است اما این ایده اصلی که یک واسط داشته باشیم که بتوانیم برایش پیاده‌سازی‌های متفاوت زیادی داشته باشیم به این می‌انجامد که بتوانیم نرم‌افزارهایی بسازیم که قابل حمل و به اشتراک‌گذاری باشد. این تصویری است که واقعاً دوست دارم ببینم تولید و اجرای سیستم‌های توزیع‌شده به آن سمت می‌رود. این خیلی قدرتمند است زیرا امروزه اگر در یک سازمان، یک سیستم توزیع‌شده بسازید (مثلاً یاهو ZooKeeper را می‌سازد) و بعد به سازمان دیگری بروید کار خیلی زیادی دارید تا متوجه شوید که چطور می‌توانید آن‌ چیزها را در ترتیبات دیگری مطابق با روش کاری دیگر افراد راه بیاندازید. منشأ مشکل همین‌جاست که سازمان دیگری می‌گوید: «این به هزینه‌اش نمی‌ارزد، من ترجیح می‌دهم که خودم نمونه خودم را بسازم زیرا اگر بخواهم خودم این چیز واقعاً پیچیده را بسازم، برایم ساده‌تر به نظر می‌رسد تا اینکه بخواهم بفهمم این را چطور در نرم‌افزارم اجرا کنم.» من واقعاً به دنبال چنین آینده‌ای هستم که بتوانید همانطوری که یک نرم‌افزار لینوکسی را در یک شرکت می‌سازید و بعد ساختن آن را در شرکت دیگری آغاز می‌کنید به همان سادگی یک سیستم توزیع‌شده را در یک سازمان بسازید و بتوانید آن را در سازمان دیگری راه بیاندازید.

البته واضح است که من در اینجا بی‌‌طرف نیستم 🙂 اما فکر می‌کنم یکی از مشکلات بزرگ، همین لایه اول انتزاع است که واقعاً ماشین را انتزاع کند و این مواد اولیه را برای خود سیستم‌های توزیع‌شده فراهم کند. این همان هدفی است که امروزه Mesos دارد و می‌خواهد آن لایه انتزاعی باشد که همه سیستم‌های توزیع‌شده را بر روی آن بسازید و بتوانید یک نرم‌افزار کاربردی که در یک سازمان تولید شده است را برداشته و آن را در سازمان دیگری که آن هم از Mesos استفاده می‌کند، اجرا کنید. مثال خوب آن یکی از سیستم‌های توزیع‌شده‌ای است که ما بر روی Mesos ساختیم که Chronos خوانده می‌شود. Chronos همان Chron توزیع‌شده است. یکی از مشکلاتی که امروزه خیلی‌ها با آن مواجه هستند این است که مجبورند که Chron را بر روی چندین ماشین تنظیم کنند و اگر یکی از آن‌ها خراب شد باید ماشین دیگری را تنظیم کنند، این واقعاً مشکل بزرگی است. Chronos یک راه‌حل برای این مشکل است و تنها بر روی Mesos اجرا می‌شود، برای اجرای آن هیچ راهی به غیر از اجرا بر روی Mesos ندارید. اما نکته جالب در مورد آن این است که سازمان دیگری که آن هم Mesos را اجرا می‌کند می‌تواند به راحتی آن را برداشته و بلافاصله بر روی کلاستر خودش اجرا کند، این به همان سادگی دانلود کردن یک نرم‌افزار به روی گوشی آیفون یا اندرویدی و دابل‌کلیک‌ کردن و اجرای آن است.

بله، و من فکر می‌کنم این لایه گمشده و این لایه انتزاعی، به افراد امکان ساختن چنین چیزهایی را می‌دهد تا بتوانند به راحتی در مراکز داده خودشان آن‌ها را اجرا کنند. فوق‌العاده است اگر به چنین جایی برسیم اما برای رسیدن به آن باید بصورت مستمر خلأ چیزهای لازم برای تولید این سیستم‌های توزیع‌شده بر روی Mesos را پر کنیم تا ساختن آنچه در ابتدای مصاحبه گفتم واقعاً خیلی ساده شود. هدف Mesos این است که با انتزاع کردن چیزهای دشواری از قبیل رسیدگی به خطاها، به وظایف توزیع‌شده، انتخاب پیشوا و …، ساختن سیستم‌های توزیع‌شده را ساده‌تر کند. اما صادقانه بگویم که ما ۱۰۰٪ به آن نقطه نرسیده‌ایم؛ درست است که تولید Chronos کاملاً ساده است اما باید آن را باز هم ساده‌تر کنیم. مثالی که می‌توان در اینجا زد این است که خیلی‌ها از نخ‌ها (Thread) استفاده نمی‌کنند زیرا با وجود اینکه انتزاع خوبی است اما سطح پایین است و نیاز است که انتزاع‌های سطح بالاتری بر روی آن داشته باشیم. این همان چیزی است که ما داریم در مورد Mesos انجام می‌دهیم، Mesos با مواد اولیه‌ای که ارائه‌ می‌کند اولین گام برای ساده‌تر کردن تولید سیستم‌های توزیع‌شده است اما ما می‌خواهیم با SDK ها و لایه‌های سطح بالاتری که بر رویش قرار می‌دهیم، استفاده از آن را باز هم ساده‌تر کنیم. من فکر می‌کنم این می‌تواند باعث شود که افراد بیشتری بخواهند سیستم‌های توزیع‌شده را بر روی چیزی شبیه به Mesos بسازند. آن وقت است که می‌توانیم از مزایای آن نیز بهره‌مند شویم، آن زمان می‌توانیم سیستم توزیع‌شده‌ای که اینجا ساخته‌ایم را برداشته و در جای دیگر اجرا کنیم. فکر می‌کنم این برای خیلی‌ها جالب باشد. ما یک جامعه بزرگ شاد هستیم و می‌خواهیم کارهایی که کرده‌ایم را به اشتراک بگذاریم مثلاً می‌خواهیم اگر چیزی ساخته‌ایم دیگران از مزایایش بهره‌مند شوند.

چند جا وجود دارد. می‌توانید به mesos.apache.org بروید که وبسایت پروژه Mesos است. همینطور می‌توانید به mesosphere.com بروید، آنجا ما مستندات زیادی داریم حتی پکیج‌های از پیش‌ساخته زیادی برای Mesos عرضه کرده‌ایم که می‌توانید دانلود کنید. خودم را هم می‌توانید در توییتر بیابید. اگر بخواهید با من گپی بزنید @benh راه خوبی است.

خیلی ممنون که دعوتم کردید، خوش گذشت.