Б Бёрнс - Распределенные системы. Паттерны проектирования

Shard = ShardingFunction ( Req ).

Шардирующая функция часто реализуется с использованием хеш-функции и оператора взятия остатка от деления (%). Хеш-функции преобразуют произвольные цепочки байтов в целые числа фиксированной длины . Хеш-функция имеет две важные с точки зрения шардинга характеристики. ‰ ‰ Детерминированность — одинаковые цепочки байтов на

входе должны порождать одинаковый результат на выходе. ‰ ‰ Равномерность — значения хеш-функции должны иметь

равномерное распределение.

Для шардированного сервиса первостепенное значение имеют детерминированность и равномерность хеш-функции. Детерми-Глава 6. Шардированные сервисы 115

нированность важна, так как обеспечивает то, что определенный запрос R всегда будет попадать на один и тот же шард сервиса. Равномерность хеш-функции обеспечивает равномерное рас-пределение нагрузки между шардами.

К счастью, библиотеки современных языков программирования включают целый ряд качественных хеш-функций. Диапазон зна-чений этих функций зачастую существенно превышает количе-ство шардов в системе. Чтобы сузить этот диапазон, необходимо

воспользоваться оператором взятия остатка от деления. Возвра-щаясь к нашему сервису из десяти шардов, нетрудно догадаться, что функция шардирования будет иметь следующий вид:

Shard = hash ( Req ) / 10.

Оператор взятия остатка от деления не нарушает свойств детер-минированности и равномерности хеш-функции. Выбор ключа

Может показаться заманчивым просто взять встроенную хеш-функцию языка программирования и применить ее ко всему объекту. Однако получившаяся в результате этого функция шардирования не будет идеальной.

Чтобы лучше разобраться в этом, рассмотрим запрос с тремя полями:

‰ ‰ время запроса;

‰ ‰ IP-адрес клиента;

‰ ‰ путь HTTP-запроса (например, /some/page.html ). Очевидно, что при простом хешировании запроса целиком за-просы {12:00, 1.2.3.4, /some/file.html} и {12:01, 5.6.7.8, /some/file.html} будут соответствовать разным шардам. 116Часть II. Паттерны проектирования обслуживающих систем Шардирующая функция выдает разные результаты, поскольку IP-адреса и временные метки запросов не совпадают. Но в боль-шинстве случаев ответ на HTTP-запрос не зависит ни от адре-са клиента, ни от временной метки запроса. Следовательно, намного лучше использовать шардирующую функцию вида shard(request.path) , а не хешировать весь запрос. Если в ка-честве ключа шардирования использовать путь запроса, то оба запроса попадут на один и тот же шард и второй запрос уже будет обслужен из кэша.

Иногда IP-адрес важен для запросов, возвращаемых интерфейс-ной частью. IP-адрес клиента может, скажем, применяться для определения страны, в которой находится пользователь. Это по-зволяет возвращать разный контент (например, на разных языках) разным пользователям. В таких случаях применение шардирую-щей функции от HTTP-пути может приводить к ошибкам — за-прос с французского IP-адреса может быть обслужен из англо-язычного кэша. Такая шардирующая функция будет слишком общей , поскольку группирует запросы с неидентичными ответами. Ставить номер шарда в зависимость одновременно от IP-адреса и HTTP-пути — тоже не лучший подход.

Два запроса с разных французских IP-адресов могут попасть на разные шарды, что снижает эффективность шардирования. Такая функция шардирования слишком специфична , поскольку может распределять запросы с идентичными ответами в разные группы. В таком случае лучше использовать следующую функ-цию шардирования:

shard ( country ( request.ip ), request.path ) Она сначала определяет страну по IP-адресу, затем использует ее в качестве части ключа. Запросы из Франции будут адресо-ваны одному шарду, а запросы из Америки — другому. Глава 6. Шардированные сервисы 117

При проектировании шардированной системы критически важ-но корректно определить ключ шардирования. Для этого нужно хорошо понимать, какие запросы могут быть адресованы вашей системе.

Консистентные хеш-функции

Первоначальная настройка шардов в новой распределенной системе довольно проста — достаточно настроить соответству-ющие шарды и шардированные сервисы. А что случится, если вы захотите изменить количество шардов в шардированной системе? Повторное шардирование — часто довольно затрат-ный процесс.

Чтобы разобраться, почему это так, вернемся к ранее рассмо-тренному примеру с шардированным кэшем. Оркестратор кон-тейнеров позволит без труда увеличить кэш с 10 до 11 экзем-пляров. Но каков будет эффект от изменения шардирующей функции с hash(Req) % 10 на hash(Req) % 11 ? Когда вы приме-ните новую шардирующую функцию, значительная часть за-просов уйдет на другие шарды, нежели те, что были назначены предыдущей функцией. Это существенно увеличит процент кэш-промахов в шардированном кэше до тех пор, пока шарды не заполнятся ответами на вновь сопоставленные с ними за-просы. Применение новой функции шардирования к шарди-рованному кэшу в худшем случае приведет к кэш-промахам в 100 % вариантов.