Алан Мёрфи, старший продакт-менеджер F5 Networks по сервисной сетке для NGINX, объясняет на портале The New Stack, почему к выбору плоскости данных (data plane) следует подходить с особым вниманием.

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

Так что если вы собираетесь вложить тонну времени и усилий ваших инженеров в сервисную сетку и развертывание Kubernetes, зачем вам покупать эквивалент дешевых шин — в данном случае, более новую и минимально протестированную плоскость данных, написанную на языке, который, возможно, даже не был разработан для обработки высокоскоростного трафика приложений? Потому что фактически плоскость данных — это то место, где резина встречается с дорогой для ваших микросервисов. Плоскость данных — это то, что будет непосредственно влиять на восприятие производительности клиентами. Именно в плоскости данных будут видны проблемы. Плоскость данных первой и наиболее остро почувствует требования к масштабированию. Медленно реагирующая плоскость данных замедлит работу всего движка Kubernetes и снизит производительность системы.

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

Контрольный список для принятия решения о плоскости данных

Если вы строите среду Kubernetes и выбираете сервисную сетку для ее работы, то вот контрольный список, который поможет вам сориентироваться. Он охватывает ключевые вопросы, которые вам следует рассмотреть при выборе плоскости данных (например, контроллера входа или решения для обратного прокси) для включения в Kubernetes и обеспечения необходимой и желаемой производительности. Прежде всего, спросите себя, сможет ли ваша плоскость данных выдержать всю производительность, которую от нее потребуют ваши сервисная сетка и приложения.

1. Сколько лет плоскость данных находится в эксплуатации?

Есть веская причина, по которой такое ПО, как Linux и MySQL, является наиболее надежным для запуска приложений в продакшн. Оно располагает многолетним опытом, обеспечивая работу приложений в огромных масштабах в самых разных сложных условиях. Ваша плоскость данных в идеале должна прослужить уже более десяти лет. Конечно, это означает, что она была создана до большинства развертываний Kubernetes. Однако реальность такова, что ядро плоскости данных выполняет ту же работу, которую балансировщики нагрузки и обратные прокси выполняли годами: обслуживание, формирование и защита HTTP-трафика. Поэтому нет причин не опереться на гигантов и не развернуть основные технологии, которые выдержали испытание временем и которым доверяют крупные организации для запуска в производство наиболее важных приложений.

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

2. Каковы ресурсы плоскости данных?

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

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

3. Есть ли в ней интеграции, которые вам нужны и которые вы хотите получить в будущем?

Ваша сервисная сетка, среда Kubernetes и приложения — это живые, дышащие системы. Кроме того, по мере развития вам, скорее всего, понадобятся различные типы приложений. Разные команды могут выбрать разные языки, хранилища данных, серверы приложений и фреймворки для создания своих приложений. Плоскости данных с небольшим количеством интеграций ограничат этот выбор. Это может сузить возможности ваших команд.

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

4. Как плоскость данных инструментирует и обеспечивает наблюдаемость?

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

5. Может ли плоскость данных динамически восстанавливаться после катастрофических сбоев?

Чтобы быстро восстанавливаться, сервисная сетка должна быть способна динамически реагировать на сбои инфраструктуры и приложений. Динамика — это относительный термин в мире Kubernetes. Мы полагаемся на Kubernetes как на плоскость управления для обеспечения отказоустойчивости, но некоторые вещи не зависят от Kubernetes, например, время доступности пода. В некоторых облаках динамичность может означать перезапуск через пять минут. В других это происходит быстрее. В Kubernetes мы склонны измерять время динамического перезапуска в секундах. Поэтому убедитесь, что вы понимаете фактические возможности вашей сервисной сетки и базового облака для быстрого восстановления после сбоев. Sidecar-прокси, возможно, являются самым важным компонентом в вашей сетке. Возвращаясь к аналогии с шинами: если они выходят из строя, трафик между сервисами останавливается. Все приложения, запущенные в ваших кластерах, перестают работать.

Доверяете ли вы своему Sidecar-прокси обеспечивать отказоустойчивость и восстановления предприятия? Если ответ «я не уверен», вы сильно рискуете с выбором.

Плоскость данных имеет важное значение, поэтому выбирайте ее соответствующим образом

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