Ошибки масштабирования систем | OTUS
🔥 Начинаем BLACK FRIDAY!
Максимальная скидка -25% на всё. Успейте начать обучение по самой выгодной цене.
Выбрать курс

Курсы

Программирование
iOS Developer. Basic
-25%
Python Developer. Professional
-25%
Разработчик на Spring Framework
-25%
Golang Developer. Professional
-25%
Python Developer. Basic
-25%
iOS Developer. Professional
-25%
Highload Architect
-25%
JavaScript Developer. Basic
-25%
Kotlin Backend Developer
-25%
JavaScript Developer. Professional
-25%
Android Developer. Basic
-25%
Unity Game Developer. Basic
-25%
Разработчик C#
-25%
Программист С Web-разработчик на Python Алгоритмы и структуры данных Framework Laravel PostgreSQL Reverse-Engineering. Professional CI/CD Vue.js разработчик VOIP инженер Программист 1С Flutter Mobile Developer Супер - интенсив по Kubernetes Symfony Framework Advanced Fullstack JavaScript developer Супер-интенсив "Azure для разработчиков"
Инфраструктура
Мониторинг и логирование: Zabbix, Prometheus, ELK
-25%
DevOps практики и инструменты
-25%
Архитектор сетей
-25%
Инфраструктурная платформа на основе Kubernetes
-25%
Супер-интенсив «IaC Ansible»
-16%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-25%
Administrator Linux. Professional MS SQL Server Developer Безопасность Linux PostgreSQL Reverse-Engineering. Professional CI/CD VOIP инженер Супер-практикум по работе с протоколом BGP Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Administrator Linux.Basic Супер-интенсив «ELK»
Специализации Курсы в разработке Подготовительные курсы
+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 комментариев
Для комментирования необходимо авторизоваться
🎁 Максимальная скидка!
Черная пятница уже в OTUS! Скидка -25% на всё!