Cloudflare снова сэкономила 100 ТБ ОЗУ, на этот раз оптимизировав свой алгоритм хэш-отображения. Одно из основных направлений бизнеса Cloudflare — кэширование данных, а именно выдача URL напрямую из памяти или с диска вместо обращения к живому сайту, что может занять значительное время. Компания использует собственную open-source платформу Pingora для сопоставления произвольного URL с одним из своих кэширующих серверов с помощью алгоритма Ketama. Эта задача проста по концепции, но может стать довольно сложной в среде, где серверы то появляются, то исчезают, и еще сложнее при масштабах Cloudflare. «Маршрутизация на бэкенд» или сопоставление URL с одним из множества кэширующих серверов требует большого количества таблиц в памяти. Входящий URL хэшируется (как файлы с помощью CRC-32), и полученное число отправляется на сервер. Первое, что приходит в голову, — делать это последовательно, по одному URL на сервер, но тут возникает первая проблема: одни и те же URL не будут попадать на одни и те же серверы. Поэтому создается хэш, соответствующий серверу, например, с его IP-адресом и именем, и оба хэша сопоставляются по числовой близости. Это звучит просто и работает нормально, поскольку распределение хэшей URL будет практически случайным, и запросы будут перенаправляться на один и тот же сервер на эгалитарной основе. Но затем вы сталкиваетесь со второй проблемой: предположим, у вас есть четыре сервера, каждый из которых обрабатывает 25% запросов, и сервер №2 исчезает, потому что кто-то споткнулся о кабель питания. Вы будете вынуждены перенаправить обрабатываемые им запросы на ближайшие в хэш-карте, что приведет к перегрузке сервера №3, следующего по соседству, в то время как серверы №1 и №4 останутся почти без нагрузки. Решение этой проблемы — добавить больше хэшей на сервер и перемешать их случайным образом. Теперь многочисленные хэши ваших четырех серверов будут иметь случайное распределение, и если один из них выйдет из строя, входящие запросы должны равномерно распределиться между оставшимися. Это требует много памяти, и еще больше, когда вы настраиваете уровни с правилами веса (чтобы более крупные серверы обрабатывали больше запросов), и тот факт, что из-за ограничений контента и архитектурных регионов не все серверы могут обслуживать все запросы. В общей сложности Cloudflare использовала до 100 000 хэшей серверов на машину, что значительно увеличивало требования к ОЗУ. После разумного применения алгебры и базовой статистики инженеры Cloudflare пришли к выводу, что использование этих 100 000 хэшей далеко превзошло точку убывающей отдачи. Команда подсчитала, что всего 10% от этого количества было достаточно для почти таких же результатов, поскольку частота ошибок едва ли снижается с каждым порядком величины сверх 10 000. После некоторого разумного манипулирования структурами данных Rust для экономии 2 байт на запись в карте хэш-сервер. Это кажется мелочью, но быстро складывается при миллиардах записей. Учитывая все обстоятельства, команда Cloudflare сэкономила около 100 ТБ ОЗУ благодаря этой оптимизации. На всякий случай команда добавила этот алгоритм «v2» отдельным путем выполнения, а не заменила код полностью, что позволило бы просто вернуться к исходному, если что-то пойдет не так. Теперь бы только все современное программное обеспечение было так же разумно в использовании ресурсов.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Bruno Ferreira
