چگونه زیرساخت Roblox را کارآمدتر و انعطاف پذیرتر می کنیم - وبلاگ Roblox

چگونه زیرساخت Roblox را کارآمدتر و انعطاف پذیرتر می کنیم - وبلاگ Roblox

همانطور که Roblox در بیش از 16 سال گذشته رشد کرده است، مقیاس و پیچیدگی زیرساخت های فنی که از میلیون ها تجربه مشترک سه بعدی همهجانبه پشتیبانی می کند نیز افزایش یافته است. تعداد ماشین‌هایی که پشتیبانی می‌کنیم در دو سال گذشته بیش از سه برابر شده است، از تقریباً 3 تا 36,000 ژوئن 30 به نزدیک به 2021 امروز. پشتیبانی از این تجربیات همیشه فعال برای مردم در سراسر جهان به بیش از 145,000 سرویس داخلی نیاز دارد. برای کمک به کنترل هزینه‌ها و تأخیر شبکه، این ماشین‌ها را به عنوان بخشی از یک زیرساخت ابری خصوصی سفارشی و ترکیبی که عمدتاً در محل اجرا می‌شود، مستقر و مدیریت می‌کنیم.  

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

در اکتبر 2021، ما یک قطعی در سراسر سیستم را تجربه کردیم. کار کوچک شروع شد، با مشکل در یک جزء در یک مرکز داده. اما همانطور که ما در حال بررسی بودیم به سرعت گسترش یافت و در نهایت منجر به قطعی 73 ساعته شد. در آن زمان، ما هر دو را به اشتراک گذاشتیم جزئیات در مورد آنچه اتفاق افتاده است و برخی از آموخته های اولیه ما از این موضوع. از آن زمان، ما در حال مطالعه این آموخته‌ها بوده‌ایم و برای افزایش انعطاف‌پذیری زیرساخت‌هایمان در برابر انواع خرابی‌هایی که در همه سیستم‌های مقیاس بزرگ به دلیل عواملی مانند افزایش شدید ترافیک، آب‌وهوا، خرابی سخت‌افزار، باگ‌های نرم‌افزاری یا فقط رخ می‌دهند، کار می‌کنیم. انسان ها اشتباه می کنند وقتی این خرابی‌ها رخ می‌دهند، چگونه می‌توانیم اطمینان حاصل کنیم که یک مشکل در یک مؤلفه یا گروهی از مؤلفه‌ها به کل سیستم سرایت نمی‌کند؟ این سوال در دو سال گذشته مورد توجه ما بوده است و در حالی که کار ادامه دارد، آنچه تاکنون انجام داده‌ایم در حال حاضر نتیجه داده است. به عنوان مثال، در نیمه اول سال 2023، ما 125 میلیون ساعت درگیر در هر ماه در مقایسه با نیمه اول سال 2022 صرفه جویی کردیم. امروز، کارهایی را که قبلا انجام داده ایم و همچنین چشم انداز بلندمدت خود را برای ساختن به اشتراک می گذاریم. یک سیستم زیرساختی انعطاف پذیرتر

ساخت Backstop

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

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

در زمان قطع، ما یک مرکز داده فعال داشتیم (که اجزای درون آن به عنوان پشتیبان عمل می‌کردند). زمانی که مشکلی مرکز داده موجود را از بین می‌برد، به قابلیتی نیاز داشتیم که به صورت دستی به یک مرکز داده جدید وارد شویم. اولویت اول ما اطمینان از استقرار نسخه پشتیبان از Roblox بود، بنابراین ما آن نسخه پشتیبان را در یک مرکز داده جدید، واقع در منطقه جغرافیایی متفاوت ایجاد کردیم. این محافظت اضافی برای بدترین سناریو: قطع به اندازه کافی در یک مرکز داده گسترش می یابد که به طور کامل غیر قابل استفاده می شود. ما اکنون یک مرکز داده داریم که بارهای کاری را مدیریت می کند (فعال) و یکی در حالت آماده به کار که به عنوان پشتیبان (غیرفعال) عمل می کند. هدف بلندمدت ما انتقال از این پیکربندی فعال-غیرفعال به پیکربندی فعال-فعال است که در آن هر دو مرکز داده بارهای کاری را مدیریت می کنند، با یک متعادل کننده بار که درخواست ها را بین آنها بر اساس تأخیر، ظرفیت و سلامت توزیع می کند. هنگامی که این مورد انجام شد، ما انتظار داریم که قابلیت اطمینان بالاتری برای همه Roblox داشته باشیم و بتوانیم تقریباً بلافاصله به جای چند ساعت از کار بیفتیم.

حرکت به یک زیرساخت سلولی

اولویت بعدی ما ایجاد دیوارهای انفجاری قوی در داخل هر مرکز داده بود تا احتمال خرابی کل یک مرکز داده را کاهش دهد. سلول ها (برخی شرکت ها آنها را خوشه می نامند) اساساً مجموعه ای از ماشین ها هستند و نحوه ایجاد این دیوارها هستند. ما خدمات را هم در داخل و هم در بین سلول ها برای افزونگی بیشتر تکرار می کنیم. در نهایت، ما می‌خواهیم همه سرویس‌های Roblox در سلول‌ها اجرا شوند تا بتوانند از دیوارهای انفجاری قوی و افزونگی بهره ببرند. اگر یک سلول دیگر کارایی نداشته باشد، می توان آن را با خیال راحت غیرفعال کرد. همانندسازی در میان سلول‌ها، سرویس را قادر می‌سازد تا زمانی که سلول تعمیر می‌شود، به کار خود ادامه دهد. در برخی موارد، ترمیم سلول ممکن است به معنای بازسازی کامل سلول باشد. در سراسر صنعت، پاک کردن و تجهیز مجدد یک ماشین منفرد، یا مجموعه کوچکی از ماشین‌ها، نسبتاً رایج است، اما انجام این کار برای کل سلول، که شامل 1,400 دستگاه است، اینطور نیست. 

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

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

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

حل چالش های بزرگتر

مشابه روشی که از درهای آتش نشانی برای مهار شعله استفاده می شود، سلول ها به عنوان دیوارهای انفجاری قوی در زیرساخت های ما عمل می کنند تا به مهار هر مشکلی که باعث خرابی یک سلول می شود کمک کنند. در نهایت، تمام سرویس‌هایی که Roblox را تشکیل می‌دهند، به‌طور اضافی در داخل و در بین سلول‌ها مستقر خواهند شد. هنگامی که این کار کامل شد، مسائل همچنان می توانند به اندازه کافی گسترده شوند که کل سلول را غیرقابل استفاده کنند، اما انتشار یک مسئله فراتر از آن سلول بسیار دشوار خواهد بود. و اگر موفق شویم سلول ها را قابل تعویض کنیم، بازیابی به طور قابل توجهی سریعتر خواهد بود زیرا ما قادر خواهیم بود در سلول دیگری شکست بخوریم و مشکل را از تأثیرگذاری بر کاربران نهایی جلوگیری کنیم. 

جایی که این کار دشوار می شود، جداسازی این سلول ها به اندازه کافی برای کاهش فرصت انتشار خطاها و در عین حال کارآمد و عملکردی نگه داشتن چیزها است. در یک سیستم زیرساخت پیچیده، سرویس ها باید با یکدیگر ارتباط برقرار کنند تا پرس و جوها، اطلاعات، بار کاری و غیره را به اشتراک بگذارند. همانطور که این سرویس ها را در سلول ها تکرار می کنیم، باید در مورد نحوه مدیریت ارتباطات متقابل فکر کنیم. در دنیای ایده آل، ما ترافیک را از یک سلول ناسالم به سلول های سالم دیگر هدایت می کنیم. اما چگونه یک "پرسش مرگ" را مدیریت کنیم باعث می شود یک سلول ناسالم باشد؟ اگر آن پرس و جو را به سلول دیگری هدایت کنیم، می تواند باعث شود که آن سلول به همان روشی که ما می خواهیم از آن اجتناب کنیم، ناسالم شود. ما باید مکانیسم‌هایی پیدا کنیم تا ترافیک «خوب» را از سلول‌های ناسالم جابه‌جا کنیم و در عین حال ترافیکی را که باعث ناسالم شدن سلول‌ها می‌شود، شناسایی و مهار کنیم. 

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

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

مهاجرت به یک زیرساخت همیشه روشن

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

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

بخشی از تیم مهندسی زیرساخت ما بر انتقال بارهای کاری موجود از محیط قدیمی یا "پیش سلولی" ما به سلول ها متمرکز شده است. این کار تا زمانی ادامه خواهد داشت که هزاران سرویس زیرساختی مختلف و هزاران سرویس پشتیبان را به سلول‌های جدید منتقل کنیم. ما انتظار داریم که به دلیل برخی عوامل پیچیده، این همه سال آینده و احتمالاً تا سال 2025 طول بکشد. اول، این کار برای ساختن به ابزار قوی نیاز دارد. به عنوان مثال، ما به ابزاری نیاز داریم تا به طور خودکار تعداد زیادی از سرویس‌ها را هنگام استقرار یک سلول جدید متعادل کنیم - بدون اینکه تأثیری بر کاربرانمان بگذاریم. ما همچنین خدماتی را دیده‌ایم که با فرضیاتی درباره زیرساخت‌های ما ساخته شده‌اند. ما باید این سرویس‌ها را بازبینی کنیم تا به چیزهایی که ممکن است در آینده با انتقال به سلول‌ها تغییر کنند، وابسته نباشند. ما همچنین روشی را برای جستجوی الگوهای طراحی شناخته شده که با معماری سلولی به خوبی کار نمی کنند، و همچنین یک فرآیند آزمایش روشمند برای هر سرویسی که مهاجرت کرده است، اجرا کرده ایم. این فرآیندها به ما کمک می‌کنند تا از هرگونه مشکلی که کاربر به دلیل ناسازگاری یک سرویس با سلول‌ها ایجاد می‌کند، جلوگیری کنیم.

امروزه نزدیک به 30,000 دستگاه توسط سلول ها مدیریت می شوند. این تنها کسری از کل ناوگان ما است، اما تا کنون انتقالی بسیار آرام و بدون تاثیر منفی بازیکن بوده است. هدف نهایی ما این است که سیستم‌های ما به 99.99 درصد آپتایم کاربر در هر ماه دست یابند، به این معنی که ما بیش از 0.01 درصد ساعات تعامل را مختل نمی‌کنیم. در کل صنعت، خرابی را نمی توان به طور کامل حذف کرد، اما هدف ما این است که زمان خرابی Roblox را تا حدی کاهش دهیم که تقریباً غیر قابل توجه باشد.

مصون سازی آینده همانطور که مقیاس می کنیم

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

به طور خلاصه، تا به امروز، ما داریم: 

  • یک مرکز داده دوم ساخت و با موفقیت به وضعیت فعال/غیرفعال دست یافت. 
  • سلول‌هایی را در مراکز داده فعال و غیرفعال ما ایجاد کرد و با موفقیت بیش از 70 درصد از ترافیک سرویس پشتیبان ما را به این سلول‌ها منتقل کرد.
  • الزامات و بهترین شیوه‌هایی را که باید دنبال کنیم تا همه سلول‌ها یکنواخت نگه داریم، در حالی که به مهاجرت بقیه زیرساخت‌هایمان ادامه می‌دهیم، تنظیم کنیم. 
  • آغاز روند مستمر ساخت "دیوارهای انفجاری" قوی‌تر بین سلول‌ها. 

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

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

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

تمبر زمان:

بیشتر از Roblox