5 советов по созданию высокомасштабируемых облачных нативных приложений

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

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

Основные соображения по поводу редизайна движка Kafka

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

Наш переработанный движок Kafka под названием Kora - это платформа потоковой передачи событий, на которой работают десятки тысяч кластеров в 70 с лишним регионах AWS, Google Cloud и Azure. Возможно, вы не будете сразу работать в таких масштабах, но многие из описанных ниже приемов все равно будут применимы.

Вот пять ключевых инноваций, которые мы реализовали в новом дизайне Kora. Если вы хотите более подробно остановиться на каком-либо из них, мы опубликовали технический документ на эту тему, который стал лучшим отраслевым докладом на Международной конференции по базам очень больших данных (VLDB) 2023.

Использование логических "ячеек" для масштабируемости и изоляции

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

Например, при увеличении размера кластера количество соединений возрастает квадратично, поскольку все клиенты обычно должны общаться со всеми брокерами. Аналогично, накладные расходы на репликацию также возрастают квадратично, поскольку каждый брокер обычно имеет последователей на всех других брокерах. В итоге добавление брокеров приводит к непропорциональному увеличению накладных расходов по сравнению с дополнительными вычислительными мощностями/хранилищами, которые они приносят.

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

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

Чтобы оценить эффективность этого решения, мы создали экспериментальный 24-брокерный кластер с шестью брокерскими ячейками (подробная информация о конфигурации приведена в нашем техническом документе). Когда мы запустили бенчмарк, загрузка кластера - пользовательская метрика, которую мы разработали для измерения нагрузки на кластер Kafka, - составила 53 % с ячейками по сравнению с 73 % без ячеек.

Балансировка типов хранилищ для оптимизации работы с теплыми и холодными данными

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

Блочное хранилище обеспечивает долговечность и гибкость в управлении различными параметрами производительности, такими как IOPS (операции ввода/вывода в секунду) и задержка. Однако диски с низкой задержкой становятся дорогостоящими по мере увеличения размера, что делает их непригодными для холодных данных. В отличие от них, сервисы объектного хранения, такие как Amazon S3, Microsoft Azure Blob Storage и Google GCS, отличаются низкой стоимостью и высокой масштабируемостью, но имеют более высокую задержку, чем блочные хранилища. Кроме того, они быстро дорожают, если вам нужно выполнять много небольших записей.

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

Такая многоуровневая архитектура позволяет нам повысить эластичность - переназначение разделов становится намного проще, когда переназначать нужно только "теплые" данные. Использование томов EBS вместо хранилища экземпляров также повышает долговечность, поскольку время жизни тома хранилища не зависит от времени жизни связанной с ним виртуальной машины.

И самое главное, многоуровневое хранение позволяет значительно повысить стоимость и производительность. Стоимость снижается, поскольку объектное хранилище является более доступным и надежным вариантом для хранения холодных данных. А производительность повышается, потому что после объединения данных в ярусы мы можем поместить теплые данные в высокопроизводительные тома хранения, которые были бы непомерно дорогими без объединения в ярусы.

Использование абстракций для унификации мультиоблачного опыта

Для любого сервиса, который планирует работать в нескольких облаках, очень важно обеспечить единый, согласованный клиентский опыт в разных облаках, а добиться этого непросто по нескольким причинам. Облачные сервисы сложны, и даже при соблюдении стандартов они все равно различаются между облаками и экземплярами. Типы экземпляров, доступность экземпляров и даже модель тарификации для одинаковых облачных сервисов могут отличаться друг от друга едва заметными, но значимыми способами. Например, блочное хранилище Azure не позволяет самостоятельно настраивать пропускную способность диска/IOPS и поэтому требует предоставления большого диска для увеличения IOPS. В отличие от этого, AWS и GCP позволяют настраивать эти переменные независимо друг от друга.

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

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

1. Логический кластер Kafka - это единица контроля доступа и безопасности. Это та самая единица, которой управляют клиенты, будь то многопользовательская или выделенная среда.
2. Единицы Confluent Kafka Units (CKU) - это единицы емкости (и, следовательно, стоимости) для клиентов Confluent. CKU выражается в видимых для клиента метриках, таких как пропускная способность на входе и выходе, а также некоторые верхние пределы для частоты запросов, соединений и т. д.
3. Наконец, мы абстрагируем нагрузку на кластер в единую метрику, называемую нагрузкой кластера. Это помогает клиентам решить, нужно ли им увеличивать или уменьшать масштаб кластера.

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

Автоматизация циклов снижения производительности для борьбы с деградацией

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

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

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

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

1. Монитор: Способ отслеживания производительности каждого брокера с внешней точки зрения. Для отслеживания мы часто проводим зондирование.
2. Агрегирование: В некоторых случаях мы агрегируем метрики, чтобы убедиться, что ухудшение производительности заметно по сравнению с другими брокерами.
3. Реакция: Специфические для Kafka механизмы, позволяющие либо исключить брокера из протокола репликации, либо перевести руководство с него.

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

Балансировка государственных сервисов для повышения производительности и эффективности

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

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

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

Эффективная балансировка может оказать существенное влияние. Один из наших клиентов заметил снижение нагрузки примерно на 25 %, когда для него была включена балансировка. Аналогичным образом, другой клиент заметил резкое снижение задержки благодаря ребалансировке.

Преимущества хорошо спроектированного облачного нативного сервиса

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

Чтобы проверить производительность Kora, мы провели небольшой эксперимент на идентичном оборудовании, сравнив Kora и нашу полную облачную платформу с Kafka с открытым исходным кодом. Мы обнаружили, что Kora обеспечивает гораздо большую эластичность с 30-кратным ускорением масштабирования; более чем в 10 раз более высокую доступность по сравнению с частотой отказов наших самоуправляемых клиентов или других облачных сервисов; и значительно меньшую задержку по сравнению с самоуправляемой Kafka. Хотя Kafka по-прежнему остается лучшим вариантом для запуска системы потоковой передачи данных с открытым исходным кодом, Kora - отличный выбор для тех, кто ищет нативную облачную среду.

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