‏کلیک‌هاوس چطور پایپلاین OpenTelemetryشو ضدقطعی کرد

تیم کلیک‌هاوس یه پلتفرم مانیتورینگ داخلی به اسم LogHouse داره که برای جمع‌آوری لاگ، متریک و trace از کل سرورها، Kubernetes و زیرساخت کلاود از OpenTelemetry (OTel) به‌عنوان لایه‌ی یکپارچه‌ی جمع‌آوری استفاده می‌کنه. الان این پایپلاین روزی ۵۰ میلیون رویداد رو قبول می‌کنه و ۱۷۷ پتابایت داده‌ی فشرده‌نشده رو نگه داشته.

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

قدم بعدی، اضافه کردن یه write-ahead log دیسکی (قابلیت file_storage خود کالکتور OTel) بود. این بخش حافظه رو حل کرد ولی مشکل تازه ساخت: چون WAL باید روی یه دیسک پایدار (PVC) ذخیره می‌شد، گیت‌وی‌ها باید StatefulSet می‌شدن و آپدیت‌ها سخت‌تر شدن. بدتر از اون، تخلیه‌ی هر ۱ ترابایت بک‌لاگ حدود ۴ ساعت طول می‌کشید و چون صف FIFO بود، داده‌ی تازه پشت سر بک‌لاگ قدیمی گیر می‌کرد؛ کار به جایی رسید که مجبور می‌شدن WAL رو خالی کنن و داده گم می‌شد.

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

راه‌حل نهایی، ترکیب connector فیل‌اُور (failoverconnector) با استوریج ابری S3 بود. تو حالت عادی داده مستقیم میره کلیک‌هاوس؛ وقتی این connector خطای دیتابیس رو تشخیص بده، خودکار میره سمت S3 - بدون اینکه همیشه هزینه‌ی نوشتن روی S3 (تخمینی ۱۰۰ تا ۵۰۰ هزار دلار در سال فقط بابت PUT) رو بدن. یه کالکتور جدا هم با گوش دادن به صف SQS، بلاب‌های S3 رو برمی‌گردونه تو کلیک‌هاوس:

connectors:
  failover/logs:
    priority_levels:
      - [logs/clickhouse]
      - [logs/s3]

برای تست، یه ساعت کامل کلاستر LogHouse تو یه ریجن رو خاموش نگه داشتن (۱۲۰ هزار رویداد در ثانیه) و دیدن داده بدون نقص فیل‌اُور شد روی S3 و بعد از روشن‌شدن، کالکتور جداگانه خودکار بک‌لاگ رو خالی کرد. این معماری الان تا ۵۰ میلیون رویداد در ثانیه اسکیل شده و پایه‌ی سرویس ClickStack Cloud هم هست، هرچند پیچیدگی پیکربندی و زیرساخت هر ریجن رو بیشتر کرده.

نکات کلیدی:

• حجم فعلی: ۵۰ میلیون رویداد در ثانیه، ۱۷۷ پتابایت داده‌ی فشرده‌نشده
• WAL دیسکی تخلیه‌ی هر ۱ ترابایت بک‌لاگ رو حدود ۴ ساعت طول می‌داد
• هزینه‌ی تخمینی نوشتن همیشگی روی S3: سالی ۱۰۰ تا ۵۰۰ هزار دلار فقط بابت PUT
• تست یک‌ساعته‌ی قطعی کامل دیتابیس روی ۱۲۰ هزار رویداد در ثانیه بدون از دست رفتن داده
• بدون Kafka، فقط با failover connector و ذخیره‌سازی S3 و اعلان‌های صف SQS