تصور کنید هزینه نظارت بر سیستمهای شما، از هزینه خودِ سرویسهایی که ارائه میدهید بیشتر شود. این پارادوکس مقیاسپذیری، همان نقطهای است که Grammarly با استقرار آزمایشی VictoriaMetrics توانست صورتحساب AWS خود را ۱۰ برابر کاهش دهد. این نتیجه ثابت میکند که قابلیت مشاهده (Observability) لزوماً نباید محرک اصلی هزینههای ابری باشد.
طبق گزارشهای فنی، این دستاورد حاصل تغییری بنیادین در نحوه فشردهسازی و ذخیرهسازی دادههای عملیاتی است؛ گذاری از پایگاهدادههای چندمنظوره به موتورهای تخصصی سری زمانی (Time-Series) — شبیه به تبدیل یک دفترچه یادداشت عمومی به یک جدول حسابداری دقیق که فقط اعداد و زمان را ثبت میکند.
در حال حاضر زیرساختهای مدرن در تلهای افتادهاند. هرچه شرکتها سرویسها، پادهای کوبرنتیز و برچسبهای (Labels) بیشتری به محیطهای خود اضافه میکنند، سیستمهایی که قرار است این رشد را نظارت کنند، اغلب گرانتر و پیچیدهتر از خودِ محیطهای تولید (Production) میشوند. دیمیتری لازرکا (Dzmitry Lazerka)، همبنیانگذار VictoriaMetrics، پس از سالها تجربه در ساخت سیستمهای دادهای مقیاسبزرگ، برای پر کردن این شکاف وارد میدان شد.
زمینه حرفهای و سوابق
لازرکا یک مهندس نرمافزار باسابقه و رهبر تکنولوژی است که تخصص عمیقی در یادگیری ماشین، سیستمهای دادهای مقیاسبزرگ و زیرساخت دارد. مسیر شغلی او محیطهای بسیار حساس و پرفشاری را در بر گرفته است:
- Lyft: او به عنوان مهندس یادگیری ماشین در بخش خودروهای خودران Level 5 فعالیت میکرد و سیستمهایی را برای شناسایی و تحلیل سناریوهای رانندگی در دنیای واقعی توسعه داد.
- Spire Global: در این شرکت، او پروژههای زیرساخت داده و یادگیری ماشین را با تمرکز بر پیشبینیهای دریایی رهبری کرد.
- Google: او از طریق شرکت EPAM Systems روی سیستمهای داده و تحلیل (Analytics) کار کرد.
- پروژههای اولیه: او به عنوان همبنیانگذار مهندسی در Bellgram فعالیت داشت و در Duetto Research کار کرد.
در تمام این نقشها، لازرکا پروژههایی در زمینههای جستجو، تحلیل، پردازش توزیعشده دادهها و سیستمهای بکاند با مقیاسپذیری بالا ساخت. او متوجه یک الگوی تکرار شونده شد: سیستمهایی که در یک مقیاس خاص به خوبی کار میکنند، اغلب در مقیاسهای دیگر بهشدت گران یا از نظر عملیاتی دشوار میشوند.
این درک، در کنار تجربیات همبنیانگذاران دیگر، یعنی الکساندر والیاکین و رومن خاوروننکو — که مستقیماً با محدودیتهای حافظه در Prometheus دست و پنجه نرم کرده بودند — منجر به تأسیس VictoriaMetrics در سال ۲۰۱۸ شد. والیاکین و خاوروننکو دریافتند که اگرچه اضافه کردن سیستمهایی مانند Thanos برخی مشکلات مقیاسپذیری را حل میکند، اما در مقابل، اجزای بیشتر و پیچیدگیهای عملیاتی جدیدی را به سیستم تحمیل میکند. علاوه بر این، تیم مشاهده کرد که چگونه تغییرات در لایسنس شرکتهایی مانند InfluxDB میتواند تصمیمات مهندسی را پس از سرمایهگذاری سنگین تیمها در آن فناوری، مختل کند.
فلسفه تأسیس
پروژه VictoriaMetrics در ابتدا با برنامهای برای ساخت یک شرکت بزرگ در حوزه Observability آغاز نشد. در عوض، این پروژه به عنوان یک تلاش عملی برای حل یک مشکل مهندسی خاص شروع شد: ساخت یک پایگاهداده سری زمانی که همان وظایف ابزارهای موجود را انجام دهد، اما با منابع بسیار کمتر و عملیات سادهتر.
تصمیم برای متنباز (Open Source) کردن پروژه یک تصمیم استراتژیک بود. لازرکا معتقد است بهترین راه برای ساخت نرمافزارهای زیرساختی این است که اجازه دهیم مهندسان خودشان فناوری را اثبات کنند. با اجازه دادن به کاربران برای دانلود نرمافزار و اجرای بارهای کاری واقعی تولید روی آن، VictoriaMetrics از نیاز به ادعاهای بازاریابی اجتناب کرد؛ مهندسان میتوانستند به سادگی سرعت و کارایی را برای خود اندازه بگیرند.
به نقل از مصاحبه با unite.ai، لازرکا استدلال میکند که قابلیت مشاهده (Observability) یک مسئله مهندسی است، نه یک مسئله خرید. بسیاری از تیمها نظارت را مانند یک اشتراک SaaS میبینند و ناکارآمدیهای معماری زیربنایی را که باعث رشد تصاعدی هزینهها با افزایش حجم تلهمتری میشود، نادیده میگیرند.
تله کاردینالیتی و اتلاف منابع
لازرکا «کاردینالیتی» (Cardinality) را محرک اصلی هزینههای سرسامآور شناسایی میکند. این اتفاق زمانی رخ میدهد که یک معیار (Metric) واحد توسط برچسبهایی با هزاران یا میلیونها مقدار منحصربهفرد گسترش یابد و سیستم را مجبور کند حجم عظیمی از سریهای زمانی منحصربهفرد را جذب، ایندکس و ذخیره کند.
- رشد تدریجی هزینهها: مشکلات کاردینالیتی بهندرت از یک تصمیم اشتباه واحد ناشی میشوند؛ بلکه با اضافه شدن سرویسها، پادهای K8s، مشتریان و برچسبهای بیشتر انباشته میشوند. هزینه زمانی چند برابر میشود که سیستم برای مدیریت ایندکس به CPU، حافظه و فضای ذخیرهسازی بیشتری نیاز پیدا میکند.
- عدم تطابق رزولوشن: بسیاری از شرکتها تمام دادهها را با یک رزولوشن (دقت) یکسان و برای یک بازه زمانی مشابه ذخیره میکنند. لازرکا اشاره میکند که معیارهای مورد نیاز برای یک هشدار (Alert) یا یک SLO، اساساً با تلهمتریهای تشخیصی با حجم بالا که فقط یکبار در طول یک حادثه استفاده میشوند، متفاوت هستند.
- هزینه ناکارآمدی: برخورد یکسان با تمام دادهها منجر به پرداخت قیمتهای گزاف زیرساختی یا SaaS برای دادههایی میشود که اصلاً به چنین منابعی نیاز ندارند.
- راهکار: لازرکا پیشنهاد میکند از تجمیع جریانی (Streaming Aggregation) استفاده شود — یعنی پردازش معیارها پیش از رسیدن به حافظه ذخیرهسازی، بهجای ذخیره هر سری زمانی خام — و همچنین اجرای سیاستهای لایهبندی شده برای نگهداری (Retention) و رزولوشن بر اساس ارزش واقعی دادهها.
لازرکا پیشنهاد میکند که تیمها بهجای پرسیدن این سؤال که «کدام پلتفرم راحتتر مستقر میشود»، بپرسند: «وقتی مقدار تلهمتری ۱۰ برابر شود چه اتفاقی میافتد؟ چه بلایی سر کاردینالیتی میآید؟ چه چیزی را ذخیره میکنیم؟ برای چه مدت؟ و چه اتفاقی برای هزینهها میافتد؟»
کارایی معماری در مقابل پیچیدگی عملیاتی
در حالی که Prometheus استاندارد صنعت برای جمعآوری دادهها در تکگره (Single-node scraping) است، با رشد کاردینالیتی اغلب به «دیوار حافظه» برخورد میکند. برای حل این مشکل، تیمها مکرراً اجزایی مانند Thanos یا Cortex را اضافه میکنند که لازرکا آنها را عامل ایجاد دردهای عملیاتی قابل توجه میداند.
- مشکل «پنج جزء»: تبدیل یک فایل باینری ساده به یک سیستم توزیعشده با یک Compactor، یک Querier، یک Store Gateway و سایر قطعات متحرک، احتمال خرابیهای ساعت ۳ صبح را افزایش میدهد. این پیچیدگی عملیاتی در واقع یک هزینه «پنهان» در قالب ساعتهای کاری مهندسان است که اغلب در صورتحسابهای ابری محاسبه نمیشود.
- جایگزین مستقیم (Drop-in Replacement): VictoriaMetrics خود را به عنوان یک تغییر در پیکربندی (Configuration) معرفی میکند، نه یک بازطراحی معماری. این سیستم به تیمها اجازه میدهد تنظیمات اسکرپ Prometheus خود را به VictoriaMetrics تغییر دهند و تمام داشبوردهای Grafana، هشدارها و قوانین ضبط (Recording rules) قبلی خود را حفظ کنند.
- ردپای منابع: این پلتفرم از فشردهسازی اختصاصی برای دادههای سری زمانی استفاده میکند. در نرخهای جذب مشابه، ۴ تا ۵ برابر کمتر از Prometheus رم مصرف میکند و تا ۱۰ برابر فضای دیسک کمتری اشغال میکند.
با کاهش تعداد نمونهها (Instances) و اندازه آنها، شرکتها میتوانند تأثیر مستقیمی روی صورتحسابهای ابری خود ببینند. هدف، ساخت پایگاهدادهای بود که همان کار ابزارهای موجود را انجام دهد اما با منابع بهمراتب کمتر و عملیات سادهتر.
قابلیت مشاهده برای عصر هوش مصنوعی
زیرساختهای AI یک متغیر جدید و گرانقیمت را معرفی میکنند: GPU. لازرکا هشدار میدهد که معیارهای پایه بهرهوری GPU گمراهکننده هستند؛ داشبوردی که بهرهوری ۹۰٪ را نشان میدهد، فاش نمیکند که آیا GPU واقعاً در حال انجام کار مفید است یا صرفاً در انتظار دریافت دادههاست.
- دید عمیق: نظارت مؤثر در AI نیازمند ردیابی هستههای CUDA، تخصیص حافظه GPU و استفاده از Tensor Core است. مهندسان باید بدانند چه مقدار زمان صرف جابجایی حافظه در مقابل انجام محاسبات میشود.
- شناسایی گلوگاهها: اگر یک خط لوله داده (Data Pipeline) نتواند با سرعت کافی GPU را تغذیه کند، اضافه کردن سختافزار بیشتر اتلاف سرمایه است. دید بهتر به مهندسان اجازه میدهد اندازه دستهها (Batch sizes) را تنظیم کنند یا بارهای کاری بیشتری را روی همان سختافزار اجرا کنند.
- پارادوکس نظارت: GPUها تلهمتری با کاردینالیتی بالا تولید میکنند. لازرکا نسبت به «بهینهسازی بد» هشدار میدهد؛ یعنی کاهش هزینههای GPU اما صرف آن پساندازها برای یک پلتفرم SaaS گرانقیمت جهت ذخیره دادههای نظارتی.
- چالشهای عاملهای هوشمند (Agentic Challenges): عاملهای AI مسیرهای درخواست غیرخطی ایجاد میکنند. یک عامل واحد ممکن است یک مدل را فراخوانی کند، از یک ابزار استفاده کند و چندین بار تلاش مجدد (Retry) انجام دهد که تلهمتری با کاردینالیتی بالایی را ایجاد میکند که به کاربران، پرامپتها و فراخوانیهای ابزار خاص گره خورده است. حلقههای بازگشتی (Recursion loops) که در آن یک برنامهریز مکرراً یک ابزار را فراخوانی میکند، میتواند منحنی هزینه را عمودی کند.
برای مقابله با این موضوع، VictoriaMetrics با OpenTelemetry و پروژههایی مانند OpenLIT ادغام شده تا دید عمیقتری به بارهای کاری GPU داشته باشد. سیستم سپس دادهها را تجمیع کرده و ابعاد بیفایده را حذف میکند تا فقط آنچه مهندسان واقعاً نیاز دارند باقی بماند. سؤال کلیدی این نیست که «GPUهای من چقدر درگیر هستند؟» بلکه این است که «از GPUهایی که برایشان هزینه میپردازم، چه کار مفیدی دریافت میکنم؟»
مدل کسبوکار متنباز
برخلاف استارتاپهای سرمایهپذیر (Venture-backed)، VictoriaMetrics به صورت خودگردان و با بودجه مشتریان اداره میشود. این ساختار به شرکت اجازه میدهد موتور اصلی خود را تحت لایسنس Apache 2.0 نگه دارد، بدون اینکه تحت فشار باشد تا نسخه متنباز را برای ترغیب کاربران به ارتقای سازمانی «ناقص» کند.
- اجتناب از تغییرات لایسنس: لازرکا تغییرات لایسنس در InfluxDB و HashiCorp را به عنوان نمونههایی ذکر میکند که در آنها فشار برای کسب درآمد میتواند منجر به تغییراتی شود که بر تصمیمات مهندسی تأثیر منفی میگذارد.
- هسته در مقابل سازمانی: موتور اصلی برای جلب اعتماد مهندسان باز میماند. شرکت برای نیازهای خاص مقیاسپذیری هزینه دریافت میکند: چندمستاجری (Multi-tenancy)، احراز هویت سازمانی، پشتیبانی از انطباق (Compliance)، SLA برای CVEها و دسترسی مستقیم به مهندسانی که کد را نوشتهاند.
- محرک نقشه راه: توسعه محصول توسط شکستهای واقعی در محیط تولید و نیازهای مشتریان هدایت میشود، نه بر اساس آنچه در یک «دک ارائهی سرمایهگذاری» (Pitch deck) قابل جذب سرمایه به نظر میرسد.
با متنباز کردن فناوری، VictoriaMetrics به مهندسان اجازه میدهد نرمافزار را دانلود کرده و بارهای کاری واقعی تولید را روی آن تست کنند. این امر اجازه میدهد فناوری کارایی خود را از طریق اندازهگیری ثابت کند، نه ادعاهای بازاریابی.
آینده استک قابلیت مشاهده
لازرکا پیشبینی میکند که معیارها (Metrics)، لاگها (Logs) و ردپاها (Traces) تحت یک مدل عملیاتی واحد همگرا شوند، هرچند لزوماً نه در قالب یک محصول تکسنگی (Monolithic). VictoriaMetrics به استکی گستردهتر تبدیل شده که شامل VictoriaLogs و VictoriaTraces است و از OpenTelemetry، جریانهای کاری سازگار با Prometheus و کوبرنتیز پشتیبانی میکند.
- همگرایی عملیاتی: اکثر تیمها نمیخواهند یک رابط کاربری (UI) واحد همه چیز را قفل کند. در عوض، آنها میخواهند سه سیگنال اصلی از یک موتور و ویژگیهای کارایی یکسان بهرهمند شوند تا اضافه کردن یک سیگنال جدید، سردرد عملیاتی جدیدی ایجاد نکند.
- نظارت به کمک AI: VictoriaMetrics از یادگیری ماشین برای تشخیص ناهنجاریها (Anomaly Detection) استفاده میکند تا نقاط پرت و روندهایی را که آستانههای دستی (Manual thresholds) نادیده میگیرند، شناسایی کند. با این حال، لازرکا بر حضور «انسان در حلقه» (Person in the loop) برای تأیید نتایج و هدایت اجرا تأکید دارد. سیاست داخلی AI در VictoriaMetrics این است که کارکنان میتوانند جریانهای کاری را خودکار کنند، اما مسئول نهایی نتیجه هستند.
- تغییر بازار: تیمهای مهندسی بهطور فزایندهای از مدلهای قیمتگذاری بر اساس تعداد میزبان (Per-host) یا هر معیار (Per-metric) فاصله میگیرند؛ مدلی که لازرکا آن را مخالف منافع مشتری در هنگام رشد کسبوکار میداند. تغییر به سمت استکهای متنباز و میزبانی شخصی (Self-hosted) یک تغییر ساختاری در بازار است، نه یک واکنش موقت به بودجه.
پلتفرمهایی که مرتبط باقی میمانند، آنهایی خواهند بود که بتوانند تلهمتری AI و نظارت GPU را بدون شکستن منحنی هزینه جذب کنند. تیمهای مهندسی انتظار دارند پلتفرمها این حجم از داده را همانطور مدیریت کنند که انتظار دارند هر زیرساخت دیگری مقیاس شود، بدون نیاز به بازطراحی مداوم یا مذاکره مجدد روی قراردادها.
برای بهینهسازی استک فعلی خود، باید برچسبهای با کاردینالیتی بالا را بازرسی کنید و ارزیابی کنید که آیا ابزار نظارتی فعلی شما، هزینه عملیاتی بیشتری نسبت به سرویسهایی که نظارت میکند، دارد یا خیر.
گام بعدی شما
- برچسبهای با کاردینالیتی بالا در سیستم نظارتی خود را شناسایی و حذف کنید.
- بررسی کنید آیا هزینه عملیاتی ابزار نظارت شما از هزینه سرویسهایی که نظارت میکند بیشتر است یا خیر.
- برای کاهش هزینههای ابری، استقرار آزمایشی یک موتور سری زمانی تخصصی را جایگزین مدلهای SaaS کنید.
اما داستان سختافزاری این تحول در مدیریت GPUها حتی پیچیدهتر است — به تحلیل ما دربارهی بهینهسازی مصرف حافظه در مدلهای زبانی بزرگ مراجعه کنید.
گفتگو