Проектирование надежности сайта в Starship | Мартин Пихлак | Технология звездолета

Фото Бена Дэвиса, Instagram slovaceck_

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

SRE в Starship отвечает за предоставление облачной инфраструктуры и сервисов платформы для работы этих серверных сервисов. Мы стандартизировали это Kubernetes для наших микросервисов, и мы управляем ими дополнительно AWS. MongoDb является основной базой данных для большинства серверных сервисов, но нам также нравится PostgreSQL, особенно там, где требуется строгая типизация и гарантии транзакций. Для асинхронного обмена сообщениями Кофе — это дополнительная платформа для обмена сообщениями, и мы используем ее практически для всего, кроме отправки видеопотоков от роботов. Мы полагаемся на наблюдаемость Прометей а также Графана, Локи, Linkerd а также Jaeger. CICD процессы Дженкинс.

Большая часть времени SRE посвящена поддержке и улучшению инфраструктуры Kubernetes. Kubernetes — наша основная платформа для развертывания, и всегда есть возможности для улучшения, будь то точная настройка параметров автоматического масштабирования, добавление политик вторжения Pod или оптимизация использования спотовых серверов. Иногда это похоже на кладку кирпичей — просто установите диаграмму Helm, которая предоставляет определенные функции. Но «кирпичики» часто нужно тщательно отбирать и оценивать (Loki подходит для управления журналами, Service Mesh — вещь, а потом уже какая), и иногда эта функция не существует в мире и должна быть написана с нуля. Когда это происходит, мы обычно обращаемся к Python и Golang, но также, если необходимо, к Rust и C.

Еще одна большая часть инфраструктуры, за которую отвечает SRE, — это данные и базы данных. Starship начался с единого монолитного MongoDb — стратегия, которая до сих пор хорошо зарекомендовала себя. Но по мере роста бизнеса нам необходимо пересмотреть эту архитектуру и начать думать о поддержке тысяч роботов. Apache Kafka — это часть истории масштабирования, но нам также необходимо узнать о сегментировании, региональной кластеризации и архитектуре базы данных микросервисов. Кроме того, мы постоянно разрабатываем инструменты и автоматизацию для управления существующей инфраструктурой баз данных. Примеры: Добавьте наблюдаемость MongoDb с помощью собственного прокси-сервера для анализа трафика базы данных, включите поддержку PITR для баз данных, автоматизируйте регулярные тесты аварийного переключения и восстановления, соберите метрики для повторной оценки Kafka, включите сохранение данных.

Наконец, одна из самых важных целей инженерной надёжности сайта — минимизировать простои производства Starship. Хотя SRE иногда требуется для устранения сбоев инфраструктуры, более эффективная работа выполняется для предотвращения сбоев и обеспечения быстрого восстановления. Это может быть очень широкая тема, от фиксированной инфраструктуры K8s до технических процедур и бизнес-процессов. Есть большие возможности влиять!

День из жизни SRE

Прибытие на работу, где-то между 9 и 10 (иногда удаленная работа). Возьмите чашку кофе, проверьте сообщения и электронные письма Slack. Проверьте оповещения, которые сработали ночью, чтобы узнать, есть ли у нас там что-нибудь интересное.

Обнаружьте, что задержки подключения MongoDb увеличились в ночное время. Когда вы просматриваете показатели Prometheus с помощью Grafana, вы обнаружите, что это происходит во время резервного копирования. Почему внезапно возникла проблема, мы уже много лет выполняем эти резервные копии? Мы доказали, что агрессивно сжимаем резервные копии для экономии затрат на сеть и хранилище, и это потребляет все доступные процессоры. Кажется, что нагрузка на базу данных немного увеличилась, чтобы было понятно. Это происходит на резервном узле, что не влияет на работу, хотя это все еще проблема, если основной выходит из строя. Чтобы решить эту проблему, добавьте Wait.

А пока измените код проверки MongoDb (Golang) и добавьте дополнительные сегменты гистограммы, чтобы лучше понять распределение задержки. Запустите канал Jenkins, чтобы запустить новый зонд в производство.

Встреча состоится в 10 часов утра, поделитесь своими обновлениями с командой и узнайте, что сделали другие — настройка мониторинга для VPN-сервера, оснащение Python Prometheus, настройка ServiceMonitors для внешних служб, отладка проблем с подключением MongoDb, пилотирование Canarian. развертывания с Flagger.

После встречи продолжайте работу, запланированную на этот день. Одним из запланированных мною сегодня действий было создание еще одного кластера Kafka в тестовой среде. Мы запускаем Kafka в Kubernetes, поэтому будет легко взять существующие файлы YAML кластера и настроить их для нового кластера. Или, с другой стороны, лучше использовать Helmet, или, может быть, теперь доступен хороший оператор Kafka? Нет, я туда не пойду — слишком много магии, я хочу более четкий контроль над своими наборами статуса. Это сырой YAML. Через полтора часа запускается новый кластер. Настройка была довольно простой; только контейнеры инициализации, которые регистрируют брокеров Kafka в DNS, нуждаются в изменении конфигурации. Для создания учетных данных приложения требовался небольшой сценарий bash для настройки учетных записей в Zookeeper. Один бит, который оставался зависшим, — это настройка Kafka Connect для записи событий журнала изменений базы данных — оказалось, что тестовая база данных не работала в режиме ReplicaSet, и Debezium не мог получить от нее журнал операций. Вырежьте и продолжайте.

Пришло время подготовить сценарий упражнения «Колесо неудач». Мы запускаем их в Starship, чтобы лучше разбираться в системах и делиться методами устранения неполадок. Он работает, ломая часть системы (обычно в тесте), и кто-то недовольный пытается решить и облегчить проблему. В этом случае я установлю нагрузочный тест с помощью Привет перегрузить микросервис для расчета маршрута. Разверните его как задачу Kubernetes, называемую «haymaker», и скройте ее достаточно хорошо, чтобы она не появлялась сразу в сети Linkerd (да, плохо). Позже запустите упражнение «Велосипед» и обратите внимание на все пробелы в руководствах, показателях, предупреждениях и т. Д.

В последние несколько часов дня заблокируйте все прерывания и попробуйте завершить кодирование. Я переопределил анализатор Mongoproxy BSON как потоковый асинхронный (Rust + Tokyo) и хочу узнать, насколько хорошо он работает с реальными данными. Оказалось, что где-то в кишечнике анализатора произошла ошибка, и чтобы выяснить это, мне нужно добавить глубокое логирование. Найдите потрясающую библиотеку слежения за Токио и увлекитесь ею …

Отказ от ответственности: описанные здесь события основаны на реальных событиях. Не все произошло в один день. Были изменены некоторые встречи и взаимодействия с коллегами. Мы ищем.

2 комментария

Add a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *