Система не работает? Спроектируйте свои корпоративные приложения для обеспечения высокой доступности

Некоторые из крупнейших веб-сайтов отличаются высокой доступностью. Одно посещение updown.io показывает отличную статистику времени безотказной работы таких сайтов, как Google, Facebook и GitHub. Они достигли этой точки, оптимизировав и доведя каждую часть своего технологического стека до высокой доступности. Они стремятся устранить каждую точку отказа и повысить производительность, масштабируемость, обслуживание и безопасность. Для большинства других организаций потеря дохода из-за простоя может быть наказанием, и им приходится бороться каждый раз, когда возникает всплеск запросов. Но для этих организаций, с чего они начинают? На чем они сосредоточены, чтобы улучшить время безотказной работы и свести время простоя практически к нулю? Давайте обсудим.

Используйте облако

Поставщики облачных услуг гарантируют доступность «пять девять» — время безотказной работы 99,999 % — с бесконечными возможностями при выборе правильного облака для правильной рабочей нагрузки. Этого трудно достичь, если вы управляете собственной локальной инфраструктурой. Так как ты это делаешь? Используя облачные вычисления. Поставщики облачных услуг могут легко создавать резервные копии своих серверов и обеспечивать доступность «пять девяток» — и они могут делать это автоматически, без вашего участия. Это не только удобно, но и безопасно.

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

Облако не стирает время простоя полностью. Бывают случаи, когда поставщики облачных услуг сами становятся причиной простоев. Snapchat — отличный пример стартапа, который обязан своим успехом своей зависимости от Google Cloud, особенно от App Engine. Тем не менее, Snap предприняла осторожный шаг, чтобы инвестировать в AWS в качестве резервного облака в течение следующих нескольких лет. Такой подход к резервному копированию даже в облаке поможет организациям сократить время простоя в экстремальных случаях. А поскольку облако намного дешевле, чем покупать локальные серверы, вы можете пользоваться таким крупномасштабным резервным копированием, не разоряя банк.

Облачное хранилище данных

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

Иногда ваши данные могут быть представлены в нескольких форматах и должны храниться в нескольких местах. При проектировании данных вашего приложения необходимо задать следующие ключевые вопросы: Насколько гранулированным будет ваше хранилище данных? Как вы будете разделять свои данные? Будет ли у каждой службы своя база данных? При создании приложений микрослужб рекомендуется предоставить каждой службе собственную базу данных. Как обсуждалось ранее, важно иметь резервные копии баз данных и томов хранения данных. Таким образом, в случае сбоя базы данных ее можно быстро заменить резервной копией, и можно избежать связанного с этим простоя.

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

Контейнеры помогают с высокой доступностью

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

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

Работа с сетью как сервисной сеткой

По мере усложнения связи и во время пиковой активности сеть может стать узким местом. Это особенно верно для веб-приложений микросервисов. С помощью технологий Service Mesh и таких инструментов, как Istio и Linkerd, вы можете справляться с нагрузкой на сеть в больших масштабах.

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

Уменьшите задержку данных между интерфейсом и сервером

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

Используйте хаос-инженерию

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

Высокая доступность: здесь для принятия

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