چگونه ما در CIAN ترابایت سیاههها را رام کردیم

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

از کجا شروع کردیم؟

در چند سال گذشته، بار در cian.ru بسیار سریع افزایش یافته است و تا سه ماهه سوم سال 2018، ترافیک منابع به 11.2 میلیون کاربر منحصر به فرد در ماه رسیده است. در آن زمان در لحظات حساس تا 40 درصد از لاگ ها را از دست دادیم، به همین دلیل نتوانستیم به سرعت با حوادث مقابله کنیم و زمان و تلاش زیادی را برای حل آنها صرف کردیم. همچنین اغلب نمی‌توانستیم علت مشکل را پیدا کنیم و پس از مدتی عود می‌کردیم. این جهنم بود و باید کاری برای آن انجام می شد.

در آن زمان، ما از خوشه‌ای متشکل از 10 گره داده با ElasticSearch نسخه 5.5.2 با تنظیمات شاخص استاندارد برای ذخیره گزارش‌ها استفاده کردیم. بیش از یک سال پیش به عنوان یک راه حل محبوب و مقرون به صرفه معرفی شد: پس از آن جریان سیاهههای مربوط چندان زیاد نبود، هیچ فایده ای برای ارائه تنظیمات غیر استاندارد وجود نداشت. 

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

چالش های رشد سریع

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

این مقیاس بود که ما را به نقطه ای رساند که خوشه عملاً غیرقابل مدیریت شد. هنگامی که گزارش‌ها شروع به رسیدن با نرخ 20 هزار پیام در ثانیه کردند، چرخش مکرر بی‌فایده تعداد خرده‌ها را به 6 هزار افزایش داد و بیش از 600 قطعه در هر گره وجود داشت. 

این منجر به مشکلاتی در تخصیص RAM شد و زمانی که یک گره از کار افتاد، همه خرده‌ها به طور همزمان شروع به حرکت کردند، ترافیک را چند برابر کرد و گره‌های دیگر را بارگیری کرد، که نوشتن داده در خوشه را تقریبا غیرممکن کرد. و در این مدت ما بدون الوار ماندیم. و اگر مشکلی در سرور وجود داشت، ما اساساً 1/10 خوشه را از دست دادیم. تعداد زیادی از نمایه های کوچک پیچیدگی را اضافه کردند.

بدون گزارش، ما دلایل حادثه را درک نکردیم و دیر یا زود می توانستیم دوباره روی همان چنگک بزنیم، و از نظر ایدئولوژی تیم ما این غیرقابل قبول بود، زیرا همه مکانیسم های کاری ما دقیقاً برعکس طراحی شده اند - هرگز تکرار نشوند. همان مشکلات برای انجام این کار، ما به حجم کامل گزارش‌ها و تحویل آنها تقریباً در زمان واقعی نیاز داشتیم، زیرا تیمی از مهندسان وظیفه هشدارها را نه تنها از معیارها، بلکه از لاگ‌ها نیز نظارت می‌کردند. برای درک مقیاس مشکل، در آن زمان حجم کل لاگ ها حدود 2 ترابایت در روز بود. 

هدف ما حذف کامل از دست رفتن سیاههها و کاهش زمان تحویل آنها به خوشه ELK به حداکثر 15 دقیقه در زمان فورس ماژور است (ما بعداً به این رقم به عنوان KPI داخلی تکیه کردیم).

مکانیسم چرخش جدید و گره های گرم گرم

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

بزرگ‌ترین تحول در این مرحله، پیاده‌سازی آپاچی کافکا بر روی سه گره با هماهنگ‌کننده به‌عنوان بافر میانی بود. کارگزار پیام ما را از از دست دادن گزارش‌ها در طول مشکلات ElasticSearch نجات داد. در همان زمان، ما 2 گره را به خوشه اضافه کردیم و به یک معماری گرم-گرم با سه گره "داغ" که در رک های مختلف در مرکز داده قرار دارند تغییر دادیم. ما لاگ‌ها را با استفاده از ماسکی که تحت هیچ شرایطی نباید گم شود - nginx و همچنین گزارش‌های خطای برنامه، به آنها هدایت کردیم. لاگ های جزئی به گره های باقی مانده ارسال شد - اشکال زدایی، هشدار و غیره، و پس از 24 ساعت، گزارش های "مهم" از گره های "داغ" منتقل شدند.

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

بهینه سازی خوشه

با این حال هنوز به طور کامل از شر مشکلات خلاص نشده ایم. متأسفانه، نمایه های کوچک هنوز ظاهر می شوند: آنها به حجم مشخص شده نرسیدند، چرخانده نشدند، و با تمیز کردن جهانی شاخص های قدیمی تر از سه روز حذف شدند، زیرا چرخش بر اساس تاریخ را حذف کردیم. این منجر به از دست رفتن داده‌ها شد زیرا ایندکس از خوشه به طور کامل ناپدید شد و تلاش برای نوشتن به یک نمایه ناموجود منطق متصدی را که برای مدیریت استفاده می‌کردیم شکست. نام مستعار برای نوشتن به ایندکس تبدیل شد و منطق rollover را شکست و باعث رشد کنترل نشده برخی از ایندکس ها تا 600 گیگابایت شد. 

به عنوان مثال، برای پیکربندی چرخش:

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

اگر نام مستعار rollover وجود نداشت، خطایی رخ می دهد:

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

ما راه حل این مشکل را برای تکرار بعدی گذاشتیم و موضوع دیگری را در نظر گرفتیم: به منطق کشش Logstash تغییر مکان دادیم که لاگ های دریافتی را پردازش می کند (حذف اطلاعات غیر ضروری و غنی سازی). ما آن را در docker قرار دادیم، که از طریق docker-compose راه‌اندازی می‌کنیم، و همچنین logstash-exporter را در آنجا قرار دادیم، که معیارها را برای نظارت عملیاتی جریان گزارش به Prometheus ارسال می‌کند. به این ترتیب ما به خودمان این فرصت را دادیم که به آرامی تعداد نمونه های logstash را که مسئول پردازش هر نوع گزارش هستند تغییر دهیم.

در حالی که ما در حال بهبود خوشه بودیم، ترافیک cian.ru به 12,8 میلیون کاربر منحصر به فرد در ماه افزایش یافت. در نتیجه، معلوم شد که تحولات ما کمی از تغییرات تولید عقب مانده است و ما با این واقعیت مواجه شدیم که گره های "گرم" نمی توانند با بار مقابله کنند و کل تحویل سیاهه ها را کند می کنند. ما داده‌های "گرم" را بدون شکست دریافت کردیم، اما مجبور شدیم در تحویل بقیه مداخله کنیم و برای توزیع یکنواخت شاخص‌ها یک جابجایی دستی انجام دهیم. 

در همان زمان، مقیاس‌بندی و تغییر تنظیمات نمونه‌های logstash در خوشه به دلیل این واقعیت که یک docker-compose محلی بود، پیچیده بود و همه اقدامات به صورت دستی انجام می‌شد (برای افزودن انتهای جدید، لازم بود که به صورت دستی همه موارد را طی کنید. سرورها و docker-compose up -d را در همه جا انجام دهید).

توزیع مجدد گزارش

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

ما تکرار بعدی را با به روز رسانی سخت افزاری شروع کردیم. ما از پنج هماهنگ کننده به سه هماهنگ کننده تبدیل شدیم، گره های داده را جایگزین کردیم و از نظر پول و فضای ذخیره سازی برنده شدیم. برای گره ها از دو پیکربندی استفاده می کنیم: 

• برای گره های «هات»: E3-1270 v6 / 960 گیگابایت SSD / 32 گیگابایت x 3 x 2 (3 برای Hot1 و 3 برای Hot2).
• برای گره های "گرم": E3-1230 v6 / 4Tb SSD / 32 Gb x 4.

در این تکرار، ایندکس را با لاگ‌های دسترسی میکروسرویس‌ها، که همان فضای لاگ‌های خط مقدم nginx را اشغال می‌کند، به گروه دوم از سه گره «هات» منتقل کردیم. اکنون داده ها را به مدت 20 ساعت در گره های "گرم" ذخیره می کنیم و سپس آنها را به گره های "گرم" به بقیه گزارش ها منتقل می کنیم. 

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

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

این تکرار همچنین مشکل عدم مقیاس بندی نیمه اتوماتیک را برطرف کرد. برای انجام این کار، ما یک زیرساخت خوشه Nomad را مستقر کردیم - مشابه آنچه قبلاً در تولید مستقر کرده ایم. در حال حاضر، مقدار Logstash به طور خودکار بسته به بار تغییر نمی کند، اما به این می رسیم.

برنامه های آینده

پیکربندی پیاده‌سازی شده کاملاً مقیاس می‌شود، و اکنون ما 13,3 ترابایت داده را ذخیره می‌کنیم - همه گزارش‌ها به مدت 4 روز، که برای تجزیه و تحلیل اضطراری هشدارها ضروری است. برخی از لاگ ها را به متریک تبدیل می کنیم که به Graphite اضافه می کنیم. برای سهولت کار مهندسان، معیارهایی برای خوشه زیرساخت و اسکریپت هایی برای تعمیر نیمه خودکار مشکلات رایج داریم. پس از افزایش تعداد گره های داده که برای سال آینده برنامه ریزی شده است، از 4 به 7 روز به ذخیره سازی داده ها خواهیم رفت. این برای کار عملیاتی کافی خواهد بود، زیرا ما همیشه سعی می کنیم حوادث را در اسرع وقت بررسی کنیم و برای تحقیقات طولانی مدت داده های تله متری وجود دارد. 

در اکتبر 2019، ترافیک به cian.ru در حال حاضر به 15,3 میلیون کاربر منحصر به فرد در ماه افزایش یافته است. این یک آزمایش جدی برای راه حل معماری برای تحویل سیاهههای مربوط شد. 

اکنون ما در حال آماده سازی برای به روز رسانی ElasticSearch به نسخه 7 هستیم. با این حال، برای این کار باید نگاشت بسیاری از ایندکس ها را در ElasticSearch به روز کنیم، زیرا آنها از نسخه 5.5 نقل مکان کردند و در نسخه 6 منسوخ اعلام شدند (آنها به سادگی در نسخه وجود ندارند. 7). این به این معنی است که در طول فرآیند به روز رسانی قطعاً نوعی فورس ماژور وجود خواهد داشت که تا زمانی که مشکل حل شود، ما را بدون گزارش رها می کند. از نسخه 7، ما بیشتر منتظر Kibana با رابط کاربری بهبود یافته و فیلترهای جدید هستیم. 

ما به هدف اصلی خود دست یافتیم: از دست دادن گزارش ها جلوگیری کردیم و زمان خرابی خوشه زیرساخت را از 2-3 خرابی در هفته به چند ساعت کار تعمیر و نگهداری در ماه کاهش دادیم. تمام این کار در تولید تقریباً نامرئی است. با این حال، اکنون می‌توانیم دقیقاً تعیین کنیم که چه اتفاقی با سرویس ما می‌افتد، می‌توانیم به سرعت آن را در حالت بی‌صدا انجام دهیم و نگران گم شدن گزارش‌ها نباشیم. به طور کلی ما راضی، خوشحال و آماده برای اکسپلویت های جدید هستیم که بعداً در مورد آنها صحبت خواهیم کرد.

منبع: www.habr.com