چالش
در سال 2020، در طول همه گیری COVID-19، تقاضا برای سرویس کنفرانس ویدیویی رمزگذاری شده 8×8 به طور تصاعدی در سراسر جهان افزایش یافت – از 20 سرور مجازی به 8000 در عرض چند هفته افزایش یافت. اگرچه کاری که یک روتر ویدیویی 8×8 انجام می دهد به اندازه کافی ساده است، اما در واقع کاملاً CPU فشرده است. مقیاس بندی این سیستم به معنای استقرار سرورهای بیشتری در فضای ابری است. سرورهای 8×8 در چند ساعت با همان تعداد گلوگاه عملکرد شبکه مواجه شدند که مهندسان آنها انتظار داشتند در طول یک سال تمام با آن مقابله کنند.
Emil Ivov از 8×8 توضیح داد: “معمولاً هنگامی که مشکلی پیش می آید، دستگاه بیش از حد بارگذاری می شود، تقاضای زیادی برای CPU وجود دارد و کار کافی برای برداشتن بسته ها از صف ها به محض رسیدن آنها وجود نخواهد داشت.”
نتیجه این مشکلات افزایش تأخیر بود که برای کاربران قابل مشاهده شد و به طور فوری، افزایش بسیار زیادی در هزینه سرویس ابری.
راه حل
برای کاهش هزینه‌ها، 8×8 روی Oracle Cloud Infrastructure (OCI) سرمایه‌گذاری کرد. OCI یک نمونه Arm64 OCI 8×8 با هزینه کمتر ارائه می دهد که توسط پردازنده های Ampere® Altra® قدرت می گیرد. با زمان کمی که داشت، 8×8 یک قمار را انجام داد و شروع به بازسازی Jitsi برای تغییر به ریزمعماری Arm64 کرد، حرکتی که او می‌ترسید سخت و مملو از تصادف باشد. بیشتر کدهای حیاتی برای Jitsi در جاوا نوشته شده بود، که به رابط های JNI برای کدهای ماشین بومی کتابخانه های کدگذاری و سایر کتابخانه هایی که باید دوباره کامپایل می شدند، نیاز داشت. خوشبختانه برای 8×8، به دلیل کتابخانه های Arm64 از قبل موجود، انتقال تمام کدهای Jitsi به Arm64 به حداقل کار توسعه دهنده نیاز داشت و همه در یک روز تکمیل شدند. علاوه بر این، اسکریپت‌های اتوماسیون برای راه‌اندازی نمونه‌های ماشین مجازی جدید باید برای نمونه‌های Arm64 پیکربندی مجدد می‌شد که معادل چندین روز دیگر بود.
نتایج
پس از انتقال به نمونه های مبتنی بر Ampere Arm64، 8×8 به هدف Jitsi خود یعنی رسیدن یا فراتر از P95 1ms دست یافت. این بدان معناست که عملکرد روزانه باید تراکنش‌های دسته‌ای را نشان دهد که کمتر از ۱ میلی‌ثانیه طول می‌کشد و P99 ۵ میلی‌ثانیه است. از منظر هزینه، نمونه‌های Arm64 OCI در هر نمونه تا 30 درصد ارزان‌تر از نمونه‌هایی بودند که قبلاً استفاده می‌کردند. علاوه بر این، نمونه‌های Arm64 مبتنی بر Ampere تا 30 درصد عملکرد بالاتری را ارائه می‌دهند، دوباره به گفته ایووف، “یک پیشرفت بسیار قابل توجه”. هر نمونه آمپر در مقایسه با قبل از مهاجرت، 20 تا 30 درصد کار بیشتری را با همان اندازه انجام می داد. ایووف گفت: “هیچ مانعی برای پذیرش نمونه های آمپر وجود ندارد. آنها همیشه اولین گزینه ای هستند که ما به آنها نگاه می کنیم.”
پس از اینکه COVID تقاضا برای ابزارهای ارتباط آنلاین را به حد غیرقابل تصوری افزایش داد، یکی از بزرگترین پروژه های مخابراتی منبع باز جهان خدمات خود را به نمونه های OCI مجهز به Ampere Arm64 منتقل کرد. این تصمیم سود بزرگی را به همراه دارد. در سال 2020، زمانی که همه‌گیری کووید-19 فرهنگ کاری را در سراسر جهان متحول کرد، ارائه‌دهنده راه‌حل کنفرانس ویدیویی 8×8 جهش عظیمی در ترافیک برای سرویس ارتباط ویدیویی رمزگذاری‌شده خود تجربه کرد. قبل از شروع همه‌گیری، روترهای ویدیویی برای خدمات کنفرانس ویدیویی ۸×۸ روی ۲۰ سرور مجازی کار می‌کردند. یک هفته بعد 80 نمونه مصرف کردند. شش هفته بعد، این تعداد به 8000 افزایش یافت. با تکان خوردن اقتصاد جهانی، 8×8 ناگهان خود را در نقش یک ستون فقرات مخابراتی جهانی یافت. در مرکز خدمات ویدئو کنفرانس 8×8 یک پروژه منبع باز بود که بر روی داربست پروژه دانشجویی دانشگاه استراسبورگ به نام SIP Communicator ساخته شده بود. از آن زمان به بعد از کلمه بلغاری “سیم” به جیتسی تغییر نام داد. جیتسی اکنون به اندازه کافی منابع محاسبات ابری پر انرژی را جذب می کند تا یک شهر کوچک را تامین کند.
آناتومی اضافه بار
اگرچه کاری که یک روتر ویدیویی 8×8 انجام می دهد به اندازه کافی ساده است، اما در واقع کاملاً CPU فشرده است. مانند یک مرکز تلفن، سرور بسته های داده را از یک سوکت می خواند، آنها را رمزگشایی می کند، آنها را دوباره رمزگذاری می کند و بسته های رمزگذاری شده را برای ارسال آنها به سوکت های دیگر کپی می کند. مقیاس بندی این سیستم به معنای استقرار سرورهای بیشتری در فضای ابری است. حداقل در ابتدا این یک طرح به اندازه کافی ساده برای مقیاس پذیری به نظر می رسید
هر هفته زیرساخت های لازم را دو برابر می کردیم [to host Jitsi]Emil Ivov، خالق Jitsi و معاون محصولات 8×8، گفت: “و این احمقانه است که وقتی چیزها به صورت تصاعدی هستند، چقدر سریع رشد می کنند.”
سرورهای 8×8 در چند ساعت با همان تعداد گلوگاه عملکرد شبکه مواجه شدند که مهندسان آنها انتظار داشتند در طول یک سال تمام با آن مقابله کنند. ایووف این حس را به حضور در یک فیلم نبرد زیردریایی تشبیه می کند که در آن تمام بارهای عمقی به یکباره می آیند و تمام دریچه های روی پل کشتی شروع به انفجار و پرتاب آب می کنند.
ایووف توضیح داد: «معمولاً وقتی مشکلی پیش می‌آید، دستگاه بیش از حد بارگذاری می‌شود، تقاضای زیادی برای CPU وجود خواهد داشت و کار کافی برای حذف بسته‌ها در زمان رسیدن انجام نمی‌شود. این صف‌ها طولانی‌تر می‌شوند. طول می‌کشد تا یک بسته از صف خارج شود، پردازش شود، در یک صف خروجی قرار گیرد و ارسال شود. این زمان افزایش می‌یابد و این افزایش برای کاربران قابل مشاهده است. آن زمان به‌عنوان تأخیر نشان داده می‌شود. [and then] از دست دادن بسته به این دلیل که وقتی شروع به ارسال بسته‌های زیادی در طول مسیر می‌کنید، می‌توانید صف‌های دستگاه‌های مختلف را در مسیر رسیدن به دستگاه نهایی خود از بین ببرید. ممکن است ویدیو یا نویز ضعیفی را در صدای خود مشاهده کنید، که ترک تحصیل کنید. این نه تنها در نمودارهای شاخص ها، بلکه برای کاربران نیز بسیار قابل مشاهده است.
در برخی مواقع، متعادل کننده بار HAProxy هنگام تفویض thread ها با بن بست مواجه می شود. سپس، از آنجایی که HAProxy به جای نوشتن گزارش برای خود، به syslog برای تولید فایل‌های گزارش متکی است، سیستم گزارش‌گیری بیش از حد بارگذاری می‌شود. اما چالش های تکنولوژیکی حتی بزرگترین مشکل نبودند. “یک چالش مالی بزرگ وجود داشت. صورت حساب ما دو مرتبه بزرگ شد و به میلیون ها در ماه رسید.”
پرداخت صدک 99
8×8 مجبور شد بلافاصله هزینه ها را کاهش دهد. ابتدا روی Oracle Cloud Infrastructure (OCI) سرمایه گذاری کرد. سپس توسعه‌دهندگان آن بهینه‌سازی‌هایی را ارائه کردند که به بارهای کاری اجازه می‌داد نمونه‌های سرور OCI کمتری مصرف کنند. سپس اوراکل با این خبر که یک نمونه Arm64 OCI کم‌هزینه را با پردازنده‌های Ampere® Altra® عرضه می‌کند، به ۸×۸ نزدیک شد. 8×8 با زمان کمی برای فرصت دادن، ریسک کرد و شروع به طراحی مجدد Jitsi برای انتقال به یک ریزمعماری کاملاً متفاوت کرد، حرکتی که می‌ترسید سخت و مملو از حوادث باشد. بیشتر کدهای حیاتی برای Jitsi در جاوا نوشته شده بود، که به رابط های JNI برای کدهای ماشین بومی کتابخانه های کدگذاری و سایر کتابخانه هایی که باید دوباره کامپایل می شدند، نیاز داشت. با این حال، خود کتابخانه ها قبلاً نسخه های Arm64 را داشتند.
ایووف از 8×8 خاطرنشان کرد: این معماری فوق العاده به خوبی حفظ شده است. هر پروژه معنی‌داری که وجود دارد قبلاً دارای باینری‌های Arm64 است، بنابراین ما هرگز با آن مشکلی نداشتیم.
طبق برآورد Ivov، نمونه‌های Arm64 OCI در هر نمونه تا 30 درصد ارزان‌تر از نمونه‌هایی بودند که قبلاً استفاده می‌کردند. علاوه بر این، نمونه‌های Arm64 مبتنی بر Ampere تا 30 درصد عملکرد بالاتری را ارائه می‌دهند، دوباره به گفته ایووف، “یک پیشرفت بسیار قابل توجه”. هر نمونه آمپر در مقایسه با قبل از مهاجرت، 20 تا 30 درصد کار بیشتری را با همان اندازه انجام می داد.
تأخیر در شبکه های مخابراتی با تنظیم زمان پاسخ برای همه تراکنش ها با هم در یک نمودار اندازه گیری می شود. معیاری که میانگین تأخیر مورد انتظار برای صدک 95 همه تراکنش ها را منعکس می کند، P95 نامیده می شود که ترجیحاً باید بسیار کم باشد. در صدک 99 (P99)، انتظار می‌رود میانگین تأخیر برآوردها بیشتر باشد، زیرا چهار درصد معاملات بین صدک‌های 95 و 99 احتمالاً شامل معاملات کندتر می‌شوند. پس از انتقال به نمونه های مبتنی بر Ampere Arm64، 8×8 به هدف Jitsi خود یعنی رسیدن یا فراتر از P95 1ms دست یافت. این بدان معناست که در عملکرد روزمره تراکنش های دسته ای باید کمتر از 1 میلی ثانیه و P99 5 میلی ثانیه طول بکشد.
انتقال تمام Jitsi به Arm64 به حداقل کار از سوی توسعه دهندگان نیاز داشت که همه در یک روز تکمیل شدند. علاوه بر این، اسکریپت‌های اتوماسیون برای راه‌اندازی نمونه‌های ماشین مجازی جدید باید برای نمونه‌های Arm64 پیکربندی مجدد می‌شد که معادل چندین روز دیگر بود. مهندسان Jitsi در تطبیق ابزارهای نظارتی موجود خود برای جمع‌آوری معیارهای عملکرد برای Arm64، و همچنین پیکربندی مجدد پلتفرم‌های ارکستراسیون، مشکل عمده‌ای گزارش نمی‌کنند.
سود ارزان و آسان
امیل ایووف از 8×8 اعتراف می کند که او و تیمش در مورد آنچه که فکر می کردند خروج از x86 به آمپر است، ترس داشتند. آیا جیتسی از موفقیت‌های عملکردی رنج میبرد، و آیا هزینه کاهش آن ضربه‌ها بیشتر از پس‌اندازی است که از اجرای روی پلتفرم‌های کم‌هزینه به دست می‌آورد؟ آیا 8×8 در نهایت به وسط تقسیم می‌شود و پلتفرم ارتباطی با معماری کاملاً متفاوتی نسبت به پلتفرم CX پشتیبانی می‌شود؟
ایووف خاطرنشان کرد: «ابتدا فکر کردم، خدای من، چه کسی می‌داند این چه چیز عجیب و غریبی است، و چقدر چیزها در آن معماری پایه Arm64 کار نمی‌کنند. می‌ترسیدم که اتفاقات غیرقابل پیش‌بینی رخ دهد. اما بعد پرداخت پول کمتر انگیزه بزرگی برای رفتن و امتحان کردن چیزها است.»
در کمال تعجب، کل مسیر مهاجرت جیتسی از x86 به Arm64 با استفاده از OCI مبتنی بر آمپر تنها دو هفته طول کشید. مرحله بعدی حرکت از صحنه سازی به تولید بود و نتایج فراتر از انتظارات همه بود.
ایووف گفت: «ما آن را روشن کردیم و ماشین‌هایی که حدود 20 تا 30 درصد ارزان‌تر بودند، 20 تا 30 درصد عملکرد بهتری به ما دادند. Ivov در پاسخ به این سوال که برنامه های 8×8 برای انتقال سایر پلتفرم ها به Ampere و OCI چیست، اظهار داشت که این ساده ترین راه برای کاهش هزینه ها است. او گفت: “هیچ مانعی برای پذیرش نمونه های آمپر وجود ندارد.” آنها همیشه اولین گزینه ای هستند که ما به آنها نگاه می کنیم.”
کامل را ببینید مجموعه ای از مقالات Ampere در اینجا.
