Пример задачи Devops-инженера по стабилизации/оптимизации/ускорению приложения

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

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

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

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

В видео обсуждается разница между монолитной архитектурой и архитектурой микросервисов. В нем объясняется, что, хотя инженер DevOps может и не отвечать за реализацию этих архитектур, важно понимать, как организовать рабочие нагрузки приложений и инфраструктуру. Спикер приводит пример отправки запроса на проверку наличия билетов на сервисе РЖД, где есть код-посредник, который взаимодействует с внешними базами данных. Они также упоминают важность записи транзакций в их локальной базе данных и периодических задач, выполняемых планировщиком.

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

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

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

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

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

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

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

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

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

Создание кластеризованной базы данных Postgres Кластер "Post Gaisin" обладает рядом преимуществ: он позволяет нам распределять рабочую нагрузку между несколькими машинами в разных зонах доступности; у каждой машины есть определенные роли для чтения или записи данных; репликация обеспечивает согласованное обновление на всех машинах, позволяя пользователям читать с любой из них. Это решение обеспечивает лучшую масштабируемость и отказоустойчивость, но может быть более дорогостоящим в зависимости от наших требований.

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

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

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

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

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

Мы внедрили архитектуру автоматического масштабирования, которая является гибкой и визуально привлекательной. У нас есть отдельные виртуальные машины и серверы для различных компонентов, таких как механизм монетизации, сервис bandana, предложения по сиропу, кластерный кэш, центры обработки данных тренеров. Эти центры обработки данных физически расположены в разных местах, между ними установлена связь, но настройка может быть сложной, если они находятся далеко друг от друга. Наша инфраструктура размещена на Amazon Web Services (AWS), что обеспечивает высокую доступность, а синхронизация между базами данных может быть невозможна из-за ограничений Postgres.

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