Что такое инфраструктура? | Кодементор

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

Лучший способ проиллюстрировать инфраструктуру — это пример. Давайте представим, что мы создаем сервис обмена фотографиями, назовем его Pinstablr. Мы начнем в стандартном режиме запуска с MVP: базовый JS-клиент, REST API и база данных (в данном случае MySQL). Выглядит примерно так:

infra1.png

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

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

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

  • Горизонтально масштабируйте сервер API, имея несколько его экземпляров, установите перед ним балансировщик нагрузки для распределения запросов.
  • Поскольку мы, скорее всего, получим гораздо больше запросов GET, чем что-либо еще, мы можем использовать архитектуру БД ведущий-подчиненный для горизонтального масштабирования операций чтения.
  • Некоторый контент, вероятно, будет использоваться гораздо чаще, чем другие данные (горячий контент), и у нас будет длинный хвост контента, который просматривается не очень часто. Горячий контент может храниться в системе кэширования в памяти, такой как Redis или memcached.

Теперь мы выглядим примерно так:

infra2.png

Теперь у нас есть больше программного обеспечения, которое не влияет на бизнес-логику или пользовательский интерфейс, но необходимо для масштабирования продукта. Это инфраструктура.

Давайте разовьем этот пример немного дальше, так как он может помочь нам понять некоторые новые разработки в инфраструктуре, такие как контейнеризация (также известная как Docker) и оркестрация (также известная как Kubernetes).

Запустив Pinstablr некоторое время и расширив его (текущая архитектура должна обеспечить нам миллионы пользователей), мы начинаем замечать, что стоимость нашей системы растет. Наш текущий подход прост, но нерентабелен: когда дела идут медленно, добавьте больше серверов. Если мы получим экспоненциальный рост, который получают многие компании, наши затраты также будут увеличиваться в геометрической прогрессии. Кроме того, мы можем столкнуться с некоторыми препятствиями, которые потребуют от нас чего-то другого, кроме простого добавления дополнительных серверов.

Допустим, возникают следующие вещи:

  • Выполнив небольшое профилирование и исследование, мы обнаружили, что серверы API тратят 98% процессорного времени на изменение размера и форматирование изображений (поскольку пользователи загружают изображения всех размеров и форматов).
  • Наш недавно созданный отдел маркетинга хочет генерировать отчеты, поэтому они забивают наши базы данных сложными и неоптимизированными SQL-запросами. Это потребляет ресурсы в наших читаемых БД.
  • Наша недавно созданная команда UX хочет провести эксперименты, чтобы попытаться оптимизировать взаимодействие с пользователем на сайте и в мобильных приложениях. Им также необходимо выполнять SQL-запросы и проводить анализ, чтобы увидеть влияние различных экспериментов, но им также необходимо управлять новыми таблицами, которые организуют их эксперименты.

Мы можем решить эти проблемы довольно легко:

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

Теперь мы выглядим так:

infra3.png

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

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

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

Docker помогает упростить этот процесс, упаковывая каждую из этих маленьких коробочек в контейнер. Эти контейнеры можно запускать и создавать локально на компьютере разработчика — даже в Mac/Windows — чтобы убедиться, что они работают, а затем помещать их в реестр контейнеров, где их можно развернуть в рабочей среде. Поскольку они представляют собой небольшие песочницы, которые содержат свою среду (включая ОС), они ограничивают риск того, что что-то сломается при переходе от разработки к производству, с чем сталкиваются другие типы программного обеспечения для развертывания, такие как Chef или Ansible.

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

К сожалению, Docker мало что знает об общей картине и о том, как связаны эти разные компоненты. Вот некоторые проблемы:

  • Как сервер API узнает адрес компонентов, с которыми он взаимодействует, например БД или Redis? Docker может предоставить виртуальную сеть, но он по-прежнему полагается на статические значения, такие как IP-адреса, для соединения вещей.
  • Что происходит, когда что-то ломается? Когда у вас работает много машин, это почти гарантия того, что где-то что-то выйдет из строя, хотя бы из-за аппаратного сбоя.

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

Опять же, если вы хотите узнать больше о Kubernetes, в Google есть много информации для вас, поэтому мне не нужно много писать об этом.

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

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

Похожие записи

Добавить комментарий

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