Ошибки масштабирования систем | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
C++ Developer. Professional
-5%
Scala-разработчик
-8%
Backend-разработчик на PHP
-9%
Алгоритмы и структуры данных
-9%
Team Lead
-6%
Архитектура и шаблоны проектирования Golang Developer. Professional
-5%
HTML/CSS
-11%
C# ASP.NET Core разработчик
-5%
Kotlin Backend Developer
-8%
iOS Developer. Professional
-8%
Java Developer. Professional Web-разработчик на Python MS SQL Server Developer Android Developer. Basic Разработчик программных роботов (RPA) на базе UiPath и PIX Microservice Architecture Unity Game Developer. Basic Разработчик голосовых ассистентов и чат-ботов React.js Developer Node.js Developer Интенсив «Оптимизация в Java» Супер-практикум по использованию и настройке GIT Symfony Framework Java Developer. Basic Unity Game Developer. Professional Супер-интенсив Azure
Инфраструктура
Инфраструктурная платформа на основе Kubernetes
-6%
Экспресс-курс «IaC Ansible»
-10%
Administrator Linux.Basic
-10%
Мониторинг и логирование: Zabbix, Prometheus, ELK
-10%
Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes»
-30%
Administrator Linux. Professional
-6%
Экcпресс-курс «ELK»
-10%
Экспресс-курс по управлению миграциями (DBVC)
-10%
Базы данных Network engineer Cloud Solution Architecture Highload Architect Разработчик голосовых ассистентов и чат-ботов VOIP инженер Супер-практикум по работе с протоколом BGP Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Супер-интенсив "Tarantool"
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Ошибки масштабирования систем

Arhitec_PO_Deep_11.11-5020-02839c.png

Предлагаем вашему вниманию обзор некоторых ошибок, которые возникают при масштабировании ИТ-систем. Речь идёт об архитектурных, организационных и технологических просчётах, которые приводят к проблемам масштабирования в product-группах. Перечень сформирован Мартином Эбботом и Майклом Фишером, авторами книги «Искусство масштабируемости».

Основываясь на собственном опыте, инженеры рекомендуют обращать внимание на следующие ошибки:

1. Отсутствие поиска архитектурного решения

Вместо этого нередко происходит описание реализации с перечислением главных компонентов (БД, ОС, языка программирования, аппаратного обеспечения и т. п.). Однако данный подход не решает проблему масштабирования. Сравните два варианта:

а) Java-платформа, работающая на Apache Felix с MySQL, GlassFish и MongoDB; б) платформа с 3-уровневой архитектурой с изолированными зонами и отсутствием синхронной коммуникации между зонами. При хранении данных использовано сочетание реляционной и нереляционной БД с применением горизонтального шардинга и встроенной репликации.

Разумеется, правильным будет второй подход.

2. В проектировании не заложена вероятность ошибки

Ломается всё: оборудование, процессы и особенно люди. Но если основные службы, компоненты и потребительские сервисы правильно спроектированы и изолированы друг от друга, последствия сбоя незначительны. В обратном случае мы получаем «Титаник», печальный пример которого демонстрирует нам неправильное проектирование: отсутствие изоляции между отсеками кормовой части привело к тому, что вода банальным образом переливалась через переборки. Итог мы все помним.

3. Вместо распределения нагрузки — вертикальное масштабирование

Многие крупные компании по-прежнему выбирают высокопроизводительное и дорогое оборудование при масштабировании монолитной системы вместо того, чтобы обеспечить сегментирование клиентов по множеству небольших БД.

1-20219-2cbc29.png

Такое решение в архитектуре не только приводит к повышению расходов на транзакции, но и может принести существенный ущерб в случае сбоя. В конечном итоге, либо система будет слишком громоздкой и станет частично простаивать, что поставит под вопрос эффективность ваших капиталовложений, либо система окажется недостаточно крупной при росте проекта. Как бы там ни было, это всё равно закончится проблемами для вашего продукта. Достаточно вспомнить PayPal в 2004 г. и eBay в 1999 г.

4. Выбор неверных инструментов

Если вы позовёте столяра починить кран, он придёт с молотком и, скорее всего, вы останетесь недовольны результатом ремонта. Почему же в реальной жизни мы нередко просим помочь с архитектурой продукта, например, специалиста по базам данных? Да, реляционная БД до сих пор основная и нередко оптимально подходит, но мы сейчас располагаем массой других вариантов по организации распределённого хранения с учётом типа данных. Но что бы вы не выбрали, помните, что хранение данных всегда должно коррелировать с дополнительными затратами на внедрение и поддержку используемых технологий.

Статья написана по материалам «Top 10 Architectural, Organizational and Process Related Failures».

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться