Как мы обновили InvariMatch для работы в кластере
До определенного момента архитектура системы InvariMatch в первоначальном виде, когда вся обработка видео происходила в одной машине, оправдывала себя. Но мы понимали, что с увеличением нагрузки на систему и объемов видео, она даст сбой. Поэтому уже тогда начали задумываться об оптимизации ее работы.
В 2016 году одному из наших клиентов понадобилось установить InvariMatch в кластере из нескольких машин. Тогда мы столкнулись с непредвиденными проблемами, а систему пришлось срочно переделывать. И вот, как мы ее доработали.
Равномерное распределение нагрузки между узлами
Без правильной системы разбора входящих заявок некоторые узлы оказывались перегруженными, потому что на них шли все входящие задания, в то время как остальные узлы простаивали. Это сильно снижало скорость обработки запросов и приводило к неэффективному использованию кластера.
Мы совершенствовали систему обработки заявок таким образом, чтобы загрузка шла равномерно на все узлы. Алгоритм производил автоматические расчеты загруженности узлов и, исходя из этих расчетов, запускал очередную входящую заявку на узле с наименьшей загруженностью. В результате система смогла быстрее обрабатывать больший объем заявок.
Отказ от NFS и переход на раздельное хранение данных в кластере.
Вторая проблема, которую нам надо было решить — это перераспределение хранения данных на несколько кластеров. Раньше входящее видео и видео, загруженное в поисковый индекс, хранились в виде файлов на одном сервере в отдельных папках. А узлы, участвующие в обработке видео, получали доступ к папкам через NFS. С увеличением количества входящих заявок и видео в папках, нагрузка на канал передачи данных получалась слишком большой. Тогда мы приняли решение распределить входящие видео и регистрационные ролики на локальные узлы.
Переход с Multicast на адресные UDP ответы
Изначально запросы к поисковым ядрам и ответы на них шли по multicast. Запросы были одинаковые ко всем ядрам, поэтому multicast был уместен и помогал сэкономить трафик в сети. А вот ответы были разные и направлялись к одному узлу. Поэтому мы начали использовать адресные UDP ответы для каждого типа запроса, что позволило значительно уменьшить нагрузку на сеть внутри системы.
Автоматизация обновления и конфигурирования узлов
Большое количество узлов в поисковой системе было сложно обновлять и конфигурировать вручную. Мы решили автоматизировать этот процесс и сделали так, чтобы файлы конфигурации формировались автоматически с помощью web-интерфейса, а администрирование системы осуществлялось централизованно. Процесс обновления системы удалось оптимизировать на основе глобального сценария RPM.
Автоматическая диагностика узлов
Однажды, несмотря на все защиты, произошла потеря питания в датацентре. Восстановление работы системы после такого сбоя потребовало много времени. Чтобы ускорить ее восстановление в будущем, мы решили сразу после запуска узлов запускать автоматическую диагностику и устранение неполадок. Это позволило выявлять проблемы в работе каждого узла еще до начала работы системы и сократить время на ручной поиск и устранение неполадок.
Хранение результатов поиска в базе данных
В начальной реализации системы InvariMatch результаты поиска хранились в отдельных файлах — это было просто и удобно. Но в кластере оказалось очень сложно получать доступ к файлам, разбросанным по всей системе, чтобы выдать ответ. В итоге мы стали хранить результаты в базе данных MySQL, чтобы в случае необходимости мы могли их легко достать и проанализировать.
Благодаря этим изменениям нам удалось оптимизировать систему под работу в кластере из нескольких узлов и сделать ее стабильной и надежной. InvariMatch научился эффективно обрабатывать большие объемы данных, быстро обновляться и восстанавливаться.