Решение Deep Dive: создание высокодоступного веб-приложения с возможностями веб-обработки и хранения с использованием MongoDB и Elk Stack

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

изображение: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/full-diagram.png [Полная диаграмма веб-приложения с высоким уровнем доступности]

Эта установка приложений высокой доступности была разработана как гипотетическое решение, которое потенциально может предложить:

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

изображение: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-1.png [схема шага 1: интерфейсные серверы]

Типичная многоуровневая настройка отделяет уровень представления от логики нашего приложения. Разделение функций приложения на слои упрощает процессы устранения неполадок и масштабирования в долгосрочной перспективе.

При выборе серверов и ресурсов мы можем учитывать следующие факторы:

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

изображение: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-2.png [Схема шага 2: Балансировщики нагрузки]

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

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

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

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-3.png [Схема шага 3: Внутренние серверы]

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

Мониторинг также будет важен на этом уровне для решения таких вопросов, как:

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

изображение: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-4.png [Схема шага 4: HAProxy]

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

изображение: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-5.png [Схема шага 5: Базы данных SQL]

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

Опять же, мы хотим рассмотреть наши метрики: сколько транзакционных или защищенных запросов мы обрабатываем? Если наша нагрузка высока, мы можем рассмотреть возможность использования таких инструментов, как ProxySQL, для балансировки входящих запросов. Мы можем сделать дополнительный шаг для повышения производительности и обеспечения высокой доступности, если настроим репликацию между нашими базами данных SQL. Это также окажется полезным, если нам нужно масштабировать нашу обработку данных.

изображение: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-6.png [Схема шага 6: Базы данных NoSQL]

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

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

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-7.png [Схема шага 7: Блокировка хранилища]

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

изображение: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-8.png [Схема шага 8: стек ELK]

Мониторинг производительности нашего приложения будет информировать о решениях, которые мы принимаем, когда мы масштабируем и улучшаем нашу настройку. Для выполнения этой работы мы можем использовать централизованное решение для ведения журналов, такое как стек Elastic / ELK. Наш стек включает в себя компоненты, которые собирают и визуализируют журналы: Logstash, который обрабатывает журналы; Elasticsearch, который хранит их; и Кибана, которая позволяет их искать и визуально организовывать. Если мы разместим этот стек за плавающим IP-адресом, мы сможем получить к нему удаленный доступ со статического IP-адреса. Кроме того, если мы включим наш стек в нашу общую частную сеть, у нас будет еще одно преимущество в плане безопасности: нашим агентам отчетов не нужно будет передавать информацию в стек через Интернет.

image: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-9.png [Схема шага 9: Хранение объектов]

При хранении статических ресурсов нашего приложения мы хотим обеспечить их доступность при сохранении высокой производительности. Решения для хранения объектов, такие как DigitalOcean Spaces, могут удовлетворить эту потребность. В частности, если мы решим хранить большие объекты в наших базах данных, у них могут возникнуть проблемы с производительностью при притоке данных, что сделает наши резервные копии очень большими. В этом случае мы можем переместить наши данные в хранилище объектов. Сохраняя URL в нашей базе данных, мы можем указывать на наши ресурсы из базы данных, не влияя на ее емкость. Это оптимальное решение для данных, которые, как мы ожидаем, останутся статичными, и предлагает дополнительные опции для масштабирования.

изображение: https: //assets.digitalocean.com/articles/solutions/highly-available-web-app/step-10.png [схема шага 10: записи DNS]

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

Наша стратегия восстановления будет включать в себя инструменты и функции для резервного копирования и восстановления наших данных в случае административных или других сбоев. Для каждой из наших капель мы можем использовать и автоматизировать моментальные снимки DigitalOcean для копирования и хранения изображений капель на серверах DigitalOcean. Кроме того, мы можем использовать специальные инструменты и сервисы, такие как Percona, Restic или Bacula, а также такие устройства хранения, как DigitalOcean Backups и Spaces, для копирования наших данных. Оценивая эти инструменты и создавая нашу стратегию, мы будем думать о данных на каждом уровне нашего приложения и о том, как часто необходимо выполнять резервное копирование, чтобы у нас была разумная точка для восстановления функциональности нашего приложения.

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

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