Будущее балансировки нагрузки зависит от данных

Облачные нативные приложения создаются на хорошем уровне. Хотя они еще не совсем доминируют в портфелях приложений, их количество растет. Интерес к контейнерам тесно связан с облачной архитектурой (на основе микросервисов) из-за внутренней зависимости для инфраструктуры связи и масштаба.

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

Рассматриваемый балансировщик нагрузки часто является компонентом оркестратора контейнеров и по умолчанию использует стандартный алгоритм циклического алгоритма на основе TCP. Это означает, что приходит запрос, и балансировщик нагрузки выбирает для ответа ресурс «следующий в очереди».

Этот метод часто аналогичен линии в банке или DMV. Но это не совсем точно. В истинном циклическом сценарии вы не перенаправлены на «следующий доступный» ресурс. Вы будете перенаправлены на ресурс «следующий в очереди», даже если этот ресурс занят. По иронии судьбы, методы распределения в DMV и вашем местном банке более эффективны, чем настоящий алгоритм циклического перебора.

Это верно и для приложений. Одна и та же служба — даже на функциональном уровне — может быть клонирована, поскольку она обслуживает один и тот же набор запросов. Но эти запросы не всегда равны с точки зрения исполнения, потому что данные. Это верно, данные. Выполнение одного и того же функционального запроса — или вызова API — может занять больше или меньше времени в зависимости от данных, которые отправляются или запрашиваются. В конце концов, для извлечения и сериализации одной записи клиента потребуется меньше времени, чем для извлечения и сериализации десяти или ста записей клиента.

И вот где Round Robin ломается и вносит изменения, которые могут повлиять на производительность. Операционная аксиома № 2 по-прежнему применяется к облачным архитектурам и архитектурам на основе микросервисов: при увеличении нагрузки снижается производительность .

Круглый Робин похож на медового барсука. Не имеет значения, перегружен ли ресурс запросами со значительными наборами данных в качестве ответов. Круглый Робин говорит «ты следующий», готов ли ты или нет. Это может привести к неравномерной производительности для тех пользователей, чьи запросы попадают в очередь на все более загруженном ресурсе.

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

Будущее балансировки нагрузки

Некоторые могут подумать, что когда мы поднимемся по стеку TCP с HTTP на HTTP +, эта проблема решится сама собой. Это совсем не так. Метод распределения — алгоритм балансировки нагрузки — по-прежнему актуален независимо от уровня, на котором вы его основываете. Round Robin не заботится об архитектуре, он заботится о ресурсах и принимает решения на основе доступного пула. Независимо от того, предназначен ли этот пул для масштабирования одного вызова API или всего монолита, алгоритм не имеет значения.

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

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

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

Балансировка нагрузки не уходит. Это наш лучший технический ответ на масштабирование всего от сети до приложений. Но он должен развиваться вместе с остальной инфраструктурой, чтобы быть более динамичным, автономным и интеллектуальным.

(3 оценок, среднее: 3,67 из 5)

Загрузка...