Кластер Elasticsearch на 200 ТБ+. Опыт компании Одноклассники

С Elasticsearch сталкиваются многие. Но что происходит, когда хочешь с его помощью хранить логи «в особо крупном объёме»? Да ещё и безболезненно переживать отказ любого из нескольких дата-центров? Какой стоит делать архитектуру, и на какие подводные камни наткнёшься? В Одноклассниках решили при помощи elasticsearch решить вопрос лог-менеджмента.

Требования к системе были сформулированы следующим образом:

  • В качестве фронтенда должен был использоваться Graylog. Потому что в компании уже был опыт использования этого продукта, программисты и тестировщики его знали, он им был привычен и удобен.
  • Объём данных: в среднем 50-80 тысяч сообщений в секунду, но если что-то ломается, то трафик ничем не ограничен, это может быть 2-3 миллиона строк в секунду.
  • Обсудив с заказчиками требования по скорости обработки поисковых запросов, мы поняли, что типичный паттерн использования подобной системы такой: люди ищут логи своего приложения за последние два дня и не хотят ждать результата на сформулированный запрос больше секунды.
  • Админы настаивали на том, чтобы система при необходимости легко масштабировалась, не требуя от них глубокого вникания в то, как она устроена.
  • Чтобы единственная задача по обслуживанию, которая этим системам требовалась периодически — это менять какое-то железо.
  • Кроме того, в Одноклассниках есть прекрасная техническая традиция: любой сервис, который мы запускаем, должен переживать отказ дата-центра (внезапный, незапланированный и абсолютно в любое время).

Подробнее о реализации требований проекта можно прочитать, пройдя по ссылке в источнике.




Добавить комментарий