عکس فوری

چالش

توسعه دهندگان نرم افزار و مدیران فناوری اطلاعات به ابزار دقیق و معیارهایی برای اندازه گیری رفتار نرم افزار نیاز دارند. وقتی توسعه دهندگان و متخصصان DevOps فرض می کنند که نرم افزار بر روی یک معماری سخت افزاری اجرا می شود، ممکن است رفتار خاص معماری را نادیده بگیرند. سرورهای مبتنی بر Arm64، از جمله خانواده پردازنده‌های Ampere Altra، بهبود عملکرد و صرفه‌جویی در مصرف انرژی را نسبت به x86 ارائه می‌کنند، اما معماری زیربنایی Arm64 است که در سطح بسیار پایین با معماری x86 رفتار متفاوتی دارد.

در آن زمان، اواسط سال 2023، OpenTelemetry به طور رسمی از استقرار Arm64 پشتیبانی نمی کرد. از آنجایی که محبوبیت نمونه های Arm64 به دلیل قیمت رقابتی آنها افزایش یافت، نظارت بر این سیستم ها برای فروشندگان قابلیت مشاهده بسیار مهم بود.

راه حل

برای کمک به اصلاح این وضعیت، Ampere Computing سرورهای مجهز به Ampere Altra را به تیم OpenTelemetry اهدا کرد. با استفاده از این پردازنده‌ها، تیم می‌تواند به‌روزرسانی ابزارهای تله‌متری خود را برای Arm64 و تطبیق کد Node.js، جاوا و پایتون برای معماری Arm64 آغاز کند.

Antoine Toulmé که پروژه OpenTelemetry Collector را در حین خدمت به عنوان مدیر ارشد مهندسی در Splunk حفظ می کند، اظهار داشت: «Ampere به ما کمک کرد تا بفهمیم چگونه کد را به بهترین شکل ابزارسازی کنیم و آن را در آن تنظیمات اجرا کنیم. "این یک تجربه جالب بود زیرا واقعا سخت افزار قدرتمندی است."

برای اینکه تیم OpenTelemetry پشتیبانی CI/CD خود را برای Arm64 به برابری با x86 برساند، از Actuated استفاده کردند. Actuated به تیم OpenTelemetry این امکان را داد تا یک محیط GitHub Actions خود میزبانی را ایجاد کنند که در آن بتوانند خطوط لوله ای بسازند که کد را در هر دو معماری برای شرایط یکسان آزمایش کند.

به این ترتیب، پروژه می تواند مجموعه آزمایشی کامل خود را برای همه معماری ها اجرا کند، بدون اینکه توسعه دهندگان پروژه را مجبور به انتخاب تست های مختلف برای هر معماری کند. در نتیجه، پشتیبانی پروژه از Arm64 به برابری با x86 نزدیک می شود.

نتایج

OpenTelemetry اکنون به توسعه دهندگان Arm64 و x86 و مدیران IT ابزار دقیق و معیارهای مورد نیاز خود را داده است. در نتیجه، مشتریانی که OpenTelemetry را در تولید اجرا می کنند، کد قابل اعتمادتر و پایدارتری را تجربه می کنند.

این نه تنها برای همه معماری‌های پردازنده، بلکه برای همه سیستم‌های عامل صدق می‌کند: شناسایی و رفع اشکال‌هایی مانند شرایط مسابقه، که راه‌اندازی آن‌ها در Arm64 آسان‌تر است، این مزیت را دارد که پروژه را برای هر معماری و سیستم عاملی بهتر می‌کند. Toulmé از OpenTelemetry می گوید که تیم او پس از انتقال از x86 به Arm64، تنها با کاهش مقدار، اندازه، مقیاس و تخصیص حافظه نمونه های استقرار، 15 درصد صرفه جویی در هزینه داشته است.

داستان توسعه دهنده

یکی از دسته‌های نرم‌افزاری که ویژگی‌های عملکرد آن به احتمال زیاد در معماری‌های پردازنده متفاوت است، پلتفرم مشاهده‌پذیری است. در اینجا آمده است که چگونه OpenTelemetry با قوی‌تر کردن تست یکپارچه‌سازی آن برای Arm، قابلیت مشاهده را برای همه بهتر کرد.

تا چند سال پیش، توسعه‌دهندگان نرم‌افزار و اپراتورهای فناوری اطلاعات در مورد اینکه کدام جنبه از یک برنامه بیشتر نیاز به اندازه‌گیری دارد، اختلاف نظر داشتند. در آن زمان به آن "مشاهده پذیری" نمی گفتند، بلکه "مدیریت عملکرد برنامه (APM) نامیده می شد که به جای "نظارت عملکرد تجاری" (BPM) استفاده می شد.

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

OpenTelemetry (OTel) به هر دو گروه ابزار دقیق و معیارهای مورد نیاز یا حداقل ابزارهایی را برای ابداع این معیارها ارائه کرده است. این یک جلویی را ارائه می دهد که می تواند با سیستم های مشاهده و ابزار دقیق مدرن که جایگزین سیستم های APM قدیمی شده اند، از جمله فروشندگان قدیمی مانند Dynatrace و New Relic، اما همچنین ارائه دهندگان خدمات جدید مانند Honeycomb، Splunk، و Datadog و سیستم نظارت متن باز Prometheus استفاده شود. OpenTelemetry پس از Kubernetes به دومین پروژه بزرگ Cloud Native Computing Foundation (CNCF) از نظر تعداد مشارکت کنندگان تبدیل شده است.

برای اینکه ابزار دقیق OpenTelemetry قوی و قابل اعتماد باشد، توسعه دهندگان CNCF باید آن را بر روی تمام پلتفرم های سروری که قادر به اجرای آن هستند آزمایش کنند. سرورهای مبتنی بر Arm64، از جمله خانواده پردازنده های Ampere Altra، بهبود عملکرد و صرفه جویی در انرژی را ارائه می دهند. اما معماری زیربنایی این پردازنده ها Arm64 است که رفتاری متفاوت با معماری x86 (AMD64) در سطح بسیار پایین دارد. آزمایش OpenTelemetry برای Arm64 دارای مزیت دیگری است که می‌تواند مشکلات احتمالی را آشکار کند که در مجموعه‌های آزمایشی پروژه تنها در x86 آزمایش نشده بودند.

متعادل کردن ترازو

در اواسط سال 2023، توسعه دهندگان مشارکت کننده CNCF با فشار فزاینده ای از جانب کاربران برای پشتیبانی از نظارت بر سرورهای مبتنی بر Arm64 مواجه بودند. از آنجایی که محبوبیت نمونه های Arm64 به دلیل قیمت رقابتی آنها افزایش یافت، نظارت بر این سیستم ها برای فروشندگان قابلیت مشاهده بسیار مهم بود. از آنجایی که OpenTelemetry یک رابط مشترک برای توسعه دهندگان برنامه Kubernetes فراهم می کند، فشار جامعه برای افزودن پشتیبانی به OpenTelemetry برای پردازنده های Arm64 با حداکثر 128 هسته مانند Ampere Altra وجود داشت.

در آن زمان، OpenTelemetry به طور رسمی از استقرار Arm64 پشتیبانی نمی کرد. برای کمک به اصلاح این وضعیت، Ampere سرورهای مجهز به Ampere Altra را به تیم OpenTelemetry اهدا کرد. با استفاده از این پردازنده‌ها، تیم می‌تواند به‌روزرسانی ابزارهای تله‌متری خود را برای Arm64 و تطبیق کد Node.js، جاوا و پایتون برای معماری Arm64 آغاز کند.

Antoine Toulmé که پروژه OpenTelemetry Collector را در حین خدمت به عنوان مدیر ارشد مهندسی در Splunk حفظ می کند، اظهار داشت: «Ampere به ما کمک کرد تا بفهمیم چگونه کد را به بهترین شکل ابزارسازی کنیم و آن را در آن تنظیمات اجرا کنیم. "این یک تجربه جالب بود زیرا واقعا سخت افزار قدرتمندی است."

تولمه خاطرنشان کرد که تیم او در پذیرش معماری Arm و اکوسیستم از نقطه نظر توسعه کد مشکل کمی داشتند. آزمایش بزرگترین چالش ها را به همراه داشت، به ویژه هنگام ادغام کد با چارچوب ها، برنامه ها و کتابخانه های شخص ثالث.

تولمه ادامه داد: «برای مثال، تصاویر Docker را می‌بینیم که ادعا می‌کردند با Arm سازگار هستند، و وقتی آنها را در یک محیط CI/CD اجرا می‌کنید و در واقع قصد دارید آن‌ها را روی سرور Arm اجرا کنید، متوجه می‌شوید که آنها فقط کد amd64 را دوباره بسته‌بندی کرده‌اند، و آن‌ها آن را طوری اجرا می‌کنند که گویی Arm است. این کمی ناامیدکننده بود.»

وقتی توسعه دهندگان و متخصصان DevOps فرض می کنند که نرم افزار بر روی یک معماری سخت افزاری اجرا می شود، ممکن است رفتار خاص معماری را نادیده بگیرند. همچنین ممکن است مشکلات مربوط به کد را که اغلب در آن معماری نشان داده نمی شود، از دست بدهند.

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

جایگزین OpenTelemetry برای عوامل APM که در پشت حافظه مانند پرزهای روی یک قلم مو جمع می‌شدند، جزء Collector است. Collector که در Golang نوشته شده است، عاملی است که به عنوان نقطه مقصد برای کتابخانه های ابزار دقیق برای صدور داده های تله متری خود عمل می کند.

تولمه به یاد می‌آورد که وقتی Collector برای اولین بار برای Arm64 کامپایل شد، چندین مشکل در شرایط مسابقه کشف شد، به دلیل روش متفاوتی که خطوط لوله پردازنده x86 و Arm64 مدیریت می‌شوند و تعداد هسته‌های موجود در CPU. این اولین نشانگر تیم OTel بود که معماری Arm شرایط مسابقه را به روشی بسیار متفاوت مدیریت می کند.

ما بازخورد اولیه‌ای از مشتریان داشتیم مبنی بر اینکه برخی از ابزارهای OpenTelemetry روی Arm به خوبی کار نمی‌کنند، زیرا هسته‌های بسیار زیادی وجود دارد. شما گاهی اوقات از چهار هسته به ۱۲۸، ۲۵۶ می‌رسید.»

نگهدارندگان پروژه این مشکلات را با استفاده از سرورهای Ampere برای همه کدهای Node.js، جاوا و پایتون خود آزمایش و حل کردند. تولمه گفت: "در دو سال گذشته، ما شاهد پیشرفت بزرگی در پشتیبانی از Arm بوده ایم."

راه حل microVM

برای اینکه تیم OpenTelemetry پشتیبانی CI/CD خود را از Arm64 به برابر با x86 برساند، با توسعه دهنده اصلی Actuated الکس الیس همکاری کردند. Actuated پلتفرمی است که برای یکی از رایج ترین سیستم های CI/CD، GitHub Actions، با استفاده از معماری های پردازنده انتخاب شده، اجراهای میزبانی شده را فراهم می کند. این امر ساخت و آزمایش پروژه ها در محیط های سرور ناهمگن را آسان تر می کند. Actuated این کار را با اجرای فرآیندهایی در microVMهایی انجام می دهد که از بارهای کاری دیگر که روی همان میزبان اجرا می شوند جدا شده اند.

الیس که همچنین خالق چارچوب OpenFaaS میکروسرویس های بدون سرور است، می گوید: «ما این را از مشتریانی که اپراتور Kubernetes GitHub را امتحان کرده اند دیده ایم. تا زمانی که یک کانتینر را بسازید یا اجرا کنید اشکالی ندارد، و سپس به امتیازات آنقدر بالا نیاز دارید که بتوانید هر گره را در کل خوشه به خطر بیندازید.

الیس ادامه داد: «این چیزی است که Actuated درباره آن است. در عوض، میکرو وی‌ام‌هایی استفاده می‌شوند که نمونه‌های Docker خود را دارند، که کاملاً ایزوله هستند و فقط برای طول عمر ساخت وجود دارند - سپس کاملاً از بین می‌روند. استفاده از microVM مقداری هزینه دارد، اما عمدتاً CI بیشتر به سرعت CPU و داشتن رم کافی برای جا دادن برنامه‌های شما نسبت به I/O خام مربوط می‌شود.

قرار دادن تمام اجزای کد برنامه در داخل بسته های مجازی، آنها را از شبکه های گسترده تر، به ویژه اینترنت عمومی، با حداقل یک لایه انتزاعی جدا می کند. این منجر به محیط اجرای ایمن تر برای اجزای نرم افزار برای تمام معماری های پردازنده، از جمله x86 و Arm64 می شود.

سود

اکنون تیم OpenTelemetry می‌تواند مشکلات رفتاری را که در آزمایش‌های x86 از قلم افتاده است، شناسایی کند. در نتیجه، مشتریانی که OpenTelemetry را در تولید اجرا می کنند، کد قابل اعتمادتر و پایدارتری را تجربه می کنند. این نه تنها برای همه معماری‌های پردازنده، بلکه برای همه سیستم‌های عامل صدق می‌کند: شناسایی و رفع اشکال‌هایی مانند شرایط مسابقه، که راه‌اندازی آن‌ها در Arm64 آسان‌تر است، این مزیت را دارد که پروژه را برای هر معماری و سیستم عاملی بهتر می‌کند.

Toulmé از OpenTelemetry می گوید که تیم او پس از انتقال از x86 به Arm64، تنها با کاهش مقدار، اندازه، مقیاس و تخصیص حافظه نمونه های استقرار، 15 درصد صرفه جویی در هزینه داشته است. اکنون، تیم می‌تواند به سمت وضعیتی کار کند که بتواند با همان دقت و توجهی که به مسائل مشتری مبتنی بر x86 می‌کند، به مسائل مشتریان مبتنی بر Arm64 پاسخ دهد. این هدف OpenTelemetry است: پشتیبانی از سطح 1 تا پایان سال 2025.

تولمه گفت: "ما از نتایج بسیار خوشحالیم." ما می‌بینیم که عملکرد Arm بسیار بالاتر از آن چیزی است که با سرورهای قدیمی x86 دریافت می‌کنیم. برای مشتریانمان، تصاویر Docker را منتشر کرده‌ایم که از Linux/AMD64 و همچنین همه انواع Arm64 پشتیبانی می‌کنند. ما شاهد جذب عالی از نظر دانلود Arm64 هستیم. ما شاهد کاهش پانزده درصدی هزینه‌ها در کل هستیم. می‌توانم بگویم، بدون یک تبدیل.

خبرکاو