Автор | Чжоу Синьюй

Так уж получилось, что сегодня я прочитал о недавних частых комментариях лидеров отрасли. облако Винаиздумать《Публичное облако, которое вы используете, не тестировалось.》,Основная мысль статьи - "публичное". облако невозможно протестировать». На самом деле у меня противоположное мнение по этому поводу. Сам облачный сервис тоже такой же. обеспечение,программное развитие разработки программного обеспечения на сегодняшний день средства тестирования разнообразны и богаты, и публично облако Из-за преимущества крупномасштабного производства потока хорошо используйте канареек. / Выпуск в оттенках серого может попытаться обнаружить ошибки, которые ускользнули из других ссылок тестирования, прежде чем новая версия будет выпущена для всей сети. Bug。

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

1. Выберите облачный сервис с наибольшими инвестициями и наибольшим масштабом со стороны поставщиков облачных услуг.

AutoMQ всегда придерживался концепции облачной миграции. Мы широко использовали собственные возможности облака для разработки AutoMQ, который разделяет хранение и вычисления. По сравнению с Apache Kafka мы получили 10-кратное преимущество в стоимости, а также в качественном отношении. Улучшено с точки зрения эффективности и гибкости эксплуатации и технического обслуживания. Поэтому вопрос о том, сможет ли публичное облако работать стабильно, тесно связан с нашим бизнесом, поэтому здесь я хотел бы поговорить о некоторых мыслях по поводу сбоев публичного облака.

Является ли проблема IAM единичным случаем или она широко распространена? Мы можем взглянуть на каталог продуктов поставщиков облачных услуг, включающий сотни самоуправляемых продуктов, и в сочетании с количеством людей, вложенных в исследования и разработки поставщиками облачных услуг, мы можем легко прийти к выводу, что «инвестиции в большом объеме ресурсов для тестирования облачных продуктов недостаточно». Поэтому, когда AutoMQ в первый день выбирал, на какие облачные возможности положиться, он установил два принципа [1]. Один из них заключался в том, чтобы «выбрать облачный сервис с наибольшими инвестициями и наибольшим масштабом со стороны поставщика облачных услуг». Зрелость таких услуг часто бывает самой высокой и в основном сосредоточена на уровне IaaS, например, в сфере вычислений, хранения, сети и других сопутствующих продуктов. Конечно, базы данных также являются полем битвы для поставщиков облачных услуг.

2 Как построить качественную инфраструктуру тестирования для AutoMQ

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

Для программной услуги корпоративного уровня важность полноценной инфраструктуры тестирования очевидна, что отражается как минимум в трех измерениях:

• дляпрограммное обеспечениесам,дапрограммное программное обеспечение Сильное средство обеспечения качества — это программное обеспечение. программное обеспечение может быстро、Стабилизировать、Основы эффективной итерации.
• Для команды это основа для практики культуры отличных инженеров и автоматизации всего, а также ключ к повышению беглости исследований и разработок, уверенности и удовольствия от работы.
• для пользователя - это понять программное обеспечение само обеспечение и важные входы в возможности продукта, некоторые возможности тестирования могут быть преобразованы в продукты (например, внесение ошибок оставлено на усмотрение пользователей), а некоторые возможности тестирования также могут быть преобразованы в продукты. Show Случай, например gRPC Просто обнародуйте его результаты. [2]。

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

Unit Testing

Модульное тестирование является обязательным для всех модулей. Для тестирования модульного тестирования требуется Mock Everything. Зависимые библиотеки компонентов включают JUnit, Mockito, Awaitility[3] и т. д. Если взять в качестве примера основной модуль AutoMQ S3Stream, текущий одиночный тест имеет около 80% покрытия классов и более 60% покрытия строк, и в будущем он будет улучшаться.

Результаты покрытия модульными тестами S3Stream

Integration Testing

Интегрируйте все или часть программных модулей и внешние зависимости для тестирования. Как правило, отличное внешне зависимое программное обеспечение предоставляет интегрированный набор тестов, например Test::RedisServer. После того, как большая часть программного обеспечения была помещена в контейнер, также очень удобно проводить интеграционное тестирование через TestContainer. Он интегрирует большинство программ с отслеживанием состояния. Например, мы использовали компонент S3Mock [4], предоставленный Adobe, для интеграции S3Stream с зависимостями хранилища объектов. тестовых примеров интеграции охватывают уплотнение, параллельное добавление, параллельную выборку, горячее/холодное чтение, динамическую полезную нагрузку, потоковые операции, вытеснение кэша, динамическую настройку и другие сценарии. Каждый запрос на включение, который пытается изменить S3Stream, должен пройти соответствующие модульные и интеграционные тесты.

Результаты интеграционного теста S3Stream по запросу на включение

E2E Testing

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

Благодаря архитектуре разделения хранения и вычислений AutoMQ мы повторно используем весь код вычислительного уровня Apache Kafka. 100% совместимость позволяет AutoMQ в полной мере использовать инфраструктуру тестирования E2E Apache Kafka. Kafka использует метод матричного тестирования, который может поддерживать выполнение тестового примера в кластерах Kafka разных размеров и даже в разных конфигурациях, что может повысить ценность каждого тестового примера. Например, следующий тестовый пример, связанный с пропускной способностью источника, будет выполняться в кластере с 5 узлами. Существует две матрицы. Первая матрица предоставит 4 различные комбинации конфигурации кластера, а вторая матрица — 2. В этом случае используется комбинация. будет работать в общей сложности в 6 сценариях.

Обычный матричный тестовый пример в Apache Kafka

AutoMQ разработан на основе KRaft-версии Kafka, поэтому после исключения тестовых случаев E2E, связанных с режимом Zookeeper, мы прошли оставшиеся более 500 тестовых примеров и будем периодически запускать эти тестовые сценарии для своевременного обнаружения ситуаций сбоев.

Performance Testing

Поскольку программное обеспечение требует больших объемов данных, такие показатели производительности, как пропускная способность и задержка, имеют решающее значение. AutoMQ тестируется с помощью среды OpenMessaging Benchmark [5], а также используется для сравнения технических индикаторов с другими продуктами. На следующем рисунке представлена ​​сравнительная диаграмма индикаторов задержки AutoMQ для конкретной модели трафика. Дополнительные сведения о технических индикаторах AutoMQ см. в разделе. Технический документ по производительности [6].

Сравнение показателей задержки AutoMQ для конкретных моделей трафика

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

Soak Testing

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

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

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

Кластер AutoMQ, который автоматически расширяется и сжимается в зависимости от трафика.

Chaos Testing

Тестирование с внесением сбоев также является обязательным последним шагом для базового программного обеспечения. Может ли AutoMQ завершить аварийное восстановление должным образом в средах сбоями, такими как простой ECS, серьезная потеря сетевых пакетов, зависание EBS и недоступность S3, также требует длительного периода проверки. Мы объединяем тестирование на внесение ошибок и тестирование на выносливость и используем компонент Chaos Mesh [7] для запуска всех вариантов использования теста на выносливость в кластерной среде со случайным и периодическим внедрением ошибок, чтобы проверить, соответствует ли производительность AutoMQ ожиданиям.

Кластер AutoMQ, который регулярно вносит случайные ошибки.

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

3 Заключение

Сбои в общедоступных облаках никогда не закончатся. Если каждый сбой может вызвать у нас некоторые мысли и предупреждения и побудить нас постоянно инвестировать в обеспечение качества программного обеспечения, то каждый сбой будет приносить прогресс. Текущая система тестирования AutoMQ потребляет десятки тысяч облачных ресурсов каждый месяц, чтобы гарантировать, что дефекты программного обеспечения могут быть максимально сохранены в процессе исследований и разработок, чтобы избежать их утечки в Интернет. Конечно, онлайн-сбои неизбежны. AutoMQ использует собственные облачные возможности для инновационного решения многих проблем Kafka. Может ли он также использовать облачные методы для уменьшения онлайн-сбоев в форме продукта BYOC с несколькими облаками и несколькими регионами? Мониторинг? , ссылки обнаружения и восстановления должны быть хорошо управляемы. О практике в этой области мы поговорим в следующей статье.

Наконец, поскольку сбои общедоступного облака неизбежны, даже если AutoMQ полагается только на облачные службы уровня IaaS, как выполнить аварийное восстановление в случае возникновения сбоев. В последующих статьях мы также расскажем, как AutoMQ реагирует на сбои ECS в облачных технологиях. и решения для сбоев EBS, сбоев S3 и сбоев на уровне AZ.

Цитировать

[1]. AutoMQ Интерпретация облачных решений：https://mp.weixin.qq.com/s/rmGoamqBnMPlrylDeSwgEA

[2]. Рынок тестирования производительности gRPC: https://grafana-dot-grpc-testing.appspot.com/.

[3] Инструменты модульного тестирования в параллельных сценариях: https://github.com/awaitility/awaitility.

[4] Компонент S3 Mock https://github.com/adobe/S3Mock.

[5] Платформа тестирования производительности AutoMQ: https://github.com/AutoMQ/openmessaging-benchmark.

[6] Технический документ по производительности AutoMQ: https://docs.automq.com/zh/docs/automq-s3kafka/CYxlwqDBHitThCkxSl2cePxrnBc.

[7] Компонент Chaos Mesh: https://chaos-mesh.org/.