تصور کنید سیستمی دارید که در آن سرعت تولید داده‌ها بسیار بیشتر از توان پردازش آن‌هاست؛ در معماری‌های سنتی، این یعنی از دست رفتن دائمی اطلاعات. اگر سرویس‌های پایین‌دستی شما برای لحظاتی از دسترس خارج شوند یا حجم داده‌ها ناگهان جهش کند، رویدادها به‌سادگی حذف می‌شوند.
این مشکل به‌ویژه زمانی بحرانی می‌شود که چندین سرویس مختلف بخواهند یک داده را به‌طور مستقل پردازش کنند؛ مثلاً در یک فروشگاه آنلاین، داده‌های تراکنش باید هم‌زمان توسط سیستم تشخیص کلاهبرداری و سیستم تحلیل داده‌ها خوانده شوند. کلودفلر (Cloudflare) در ۱ اکتبر ۲۰۲۶ با معرفی K2 این گلوگاه را هدف قرار داد. K2 یک ابزار جریان‌دهی رویداد (Event Streaming) سرورلس است که حجم عظیمی از داده‌های ورودی را جذب کرده و به خوانندگان اجازه می‌دهد با سرعت و زمان‌بندی دلخواه خود، داده‌ها را مصرف کنند.
بسیاری از سازمان‌ها برای جداسازی سرویس‌ها به Apache Kafka متکی هستند. اما اجرای کافکا در لبه (Edge) — جایی که سرورها موقتی هستند و منابع سخت‌افزاری محدودند — بسیار دشوار است. کلودفلر برای سرویس Basin Pipelines خود به یک بافر بادوام نیاز داشت تا رویدادها را پیش از تبدیل و ذخیره در R2 نگه دارد. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی زیرساخت‌های توزیع‌شده اشاره کردیم، تضمین عدم حذف داده‌ها در مقیاس جهانی نیازمند بازنگری در معماری‌های سنتی است.
زیرساخت کلودفلر در بیش از ۳۳۵ شهر گسترده شده است. این یعنی آن‌ها نمی‌توانستند صرفاً نرم‌افزارهای توزیع‌شده قدیمی مثل کافکا را نصب کنند و مجبور شدند از «ابر-قدرت» خود، یعنی نزدیکی به کاربران و قابلیت مقیاس‌پذیری افقی، برای ساخت K2 استفاده کنند.
مکانیزم ذخیره‌سازی R2
سرویس K2 برای ثبت لاگ‌های اصلی از دیسک‌های محلی استفاده نمی‌کند، بلکه یک لاگ بادوام و بخش‌بندی‌شده را مستقیماً روی ذخیره‌ساز اشیاء R2 (R2 Object Storage) پیاده کرده است. این انتخاب باعث می‌شود K2 از پایداری خیره‌کننده R2 بهره ببرد. با انتقال مسئولیت تکثیر داده‌ها به لایه ذخیره‌سازی، لایه اپلیکیشن بسیار ساده‌تر و ارزان‌تر شده است.
از آنجا که ذخیره‌سازهای اشیاء از قابلیت Append (افزودن به انتهای فایل) پشتیبانی نمی‌کنند، K2 از یک فرآیند خاص برای مدیریت داده‌ها استفاده می‌کند:
- تجمع در حافظه: داده‌های ورودی ابتدا در حافظه موقت یک سرویس لبه جمع می‌شوند.
- نوشتن قطعه‌ای: پس از مدت کوتاهی، سیستم تمام رویدادها را به‌صورت یک فایل قطعه‌ای (Segment) می‌نویسد تا هزینه‌ی خواندن و نوشتن اشیاء کوچک کاهش یابد.
- هماهنگی اتمیک: ترتیب داده‌ها و آفست‌ها از طریق عملیات اتمیک R2 مدیریت می‌شوند و دیگر نیازی به سرویس‌های هماهنگ‌کننده مجزا نیست.
این جداسازی محاسبات از ذخیره‌سازی اجازه می‌دهد هر بخش به‌طور مستقل مقیاس‌پذیر باشد. طبق گزارش وبلاگ کلودفلر، این معماری باعث می‌شود هزینه ذخیره داده‌های تاریخی کاهش یابد، اما تأخیری (Latency) در حدود ۱ ثانیه در ۹۹ درصد موارد ایجاد می‌کند.
تفاوت K2 با Queues و Pipelines
کلودفلر K2 را بر اساس نوع حجم کاری از سایر ابزارهای خود متمایز می‌کند.
Cloudflare Queues برای ردیابی موارد تکی و زمان‌بر طراحی شده است؛ مثلاً وقتی یک درخواست پردازش تصویر باید در صف قرار بگیرد. این سرویس قابلیت‌هایی مثل تلاش مجدد (Retry) برای هر پیام یا صف‌های Dead-letter را دارد.
در مقابل، K2 برای جابه‌جایی داده در مقیاس بسیار بالا و نگهداری طولانی‌مدت ساخته شده است. K2 پیام‌ها را به‌صورت دسته‌ای (Batch) تولید و مصرف می‌کند. این روش پردازش را بهینه می‌کند اما قابلیت تلاش مجدد در سطح تک‌پیام را حذف می‌کند.
سرویس Basin Pipelines نیز برای جذب داده‌های JSON و تبدیل آن‌ها به جداول Iceberg یا ذخیره‌ساز R2 است. کلودفلر توصیه می‌کند اگر هدف نهایی ذخیره‌سازی است از Pipelines و اگر هدف پردازش سفارشی است از K2 استفاده کنید.
پیاده‌سازی و مصرف داده‌ها
توسعه‌دهندگان می‌توانند از طریق CLI، Wrangler یا داشبورد، جریان‌های داده را ایجاد کنند. برای مثال، با دستور cf k2 streams create --name app_events --http-enabled یک جریان تحلیل محصول ساخته می‌شود که یک شناسه منحصربه‌فرد و یک Worker Binding برمی‌گرداند.
رویدادها به‌صورت بایت ارسال می‌شوند و هر فرمت کدگذاری را می‌پذیرند. در یک Worker، توسعه‌دهنده با دستور env.EVENTS.send() داده‌ها را ارسال می‌کند. اگر عملیات شکست بخورد، یک پرچم retryable مشخص می‌کند که آیا باید خطای ۵۰۳ یا ۵۰۰ بازگردانده شود.
مصرف داده‌ها از طریق اشتراک‌ها (Subscriptions) انجام می‌شود که دو الگوی اصلی دارد:
۱. موازی‌سازی خواندن: یک اشتراک، کار را بین چندین مصرف‌کننده تقسیم می‌کند تا بار پردازشی توزیع شود.
۲. الگوی Pub/Sub: هر مصرف‌کننده اشتراک مجزای خود را دارد تا تمام پیام‌های جریان را دریافت کند.
وقتی کلاینت داده‌ها را می‌خواند، یک دسته رکورد و یک اجاره (Lease) ۵ دقیقه‌ای دریافت می‌کند. سپس باید یکی از سه اقدام زیر را انجام دهد:
- Ack: تأیید پردازش برای عدم ارسال مجدد.
- Nack: اعلام شکست پردازش برای ارسال مجدد دسته.
- Extend: درخواست زمان بیشتر برای تکمیل پردازش.
محدودیت‌های بتا و نقشه راه
سرویس K2 در حال حاضر برای حساب‌های Paid در وضعیت بتای عمومی است. محدودیت‌های فعلی شامل ۱۰ گیگابایت فضای ذخیره‌سازی و سرعت تولید ۳۰ مگابایت بر ثانیه است. قیمت‌گذاری آینده به شرح زیر پیش‌بینی شده است:
- تولید داده: ۰.۰۴ دلار به ازای هر گیگابایت
- مصرف داده: ۰.۰۴ دلار به ازای هر گیگابایت
- نگهداری داده: ۰.۰۲ دلار به ازای هر گیگابایت در ماه
نقشه راه کلودفلر برای خروج از بتا شامل افزایش موازی‌سازی برای پشتیبانی از جریان‌های چند گیگابایتی، معرفی کلیدهای پیام برای تضمین ترتیب، و جایگزینی Polling با سیستم Push-based است. همچنین یک لایه Express برای کاهش تأخیر و پشتیبانی از کلاینت‌های Apache Kafka در دستور کار است.
برای توسعه‌دهندگان، این یعنی لاگ‌های بادوام دیگر یک بار زیرساختی سنگین نیستند، بلکه به یک فراخوانی API ساده تبدیل شده‌اند.
گام بعدی شما
- اگر از حساب Paid کلودفلر استفاده می‌کنید، با دستور
cf k2 streams createاولین لاگ بادوام خود را تست کنید. - معماری اپلیکیشن خود را بررسی کنید تا ببینید کجا می‌توانید جایگزینی Queues با K2 برای جابه‌جایی داده‌های حجیم انجام دهید.
- برای کاهش هزینه‌های زیرساختی، بررسی کنید آیا می‌توانید مدیریت Kafka را به لایه سرورلس K2 منتقل کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو