Ошибки масштабирования систем
Предлагаем вашему вниманию обзор некоторых ошибок, которые возникают при масштабировании ИТ-систем. Речь идёт об архитектурных, организационных и технологических просчётах, которые приводят к проблемам масштабирования в product-группах.
Основываясь на собственном опыте, инженеры рекомендуют обращать внимание на следующие ошибки:
1. Отсутствие поиска архитектурного решения
Вместо этого нередко происходит описание реализации с перечислением главных компонентов (БД, ОС, языка программирования, аппаратного обеспечения и т. п.). Однако данный подход не решает проблему масштабирования. Сравните два варианта:
а) Java-платформа, работающая на Apache Felix с MySQL, GlassFish и MongoDB; б) платформа с 3-уровневой архитектурой с изолированными зонами и отсутствием синхронной коммуникации между зонами. При хранении данных использовано сочетание реляционной и нереляционной БД с применением горизонтального шардинга и встроенной репликации.
Разумеется, правильным будет второй подход.
2. В проектировании не заложена вероятность ошибки
Ломается всё: оборудование, процессы и особенно люди. Но если основные службы, компоненты и потребительские сервисы правильно спроектированы и изолированы друг от друга, последствия сбоя незначительны. В обратном случае мы получаем «Титаник», печальный пример которого демонстрирует нам неправильное проектирование: отсутствие изоляции между отсеками кормовой части привело к тому, что вода банальным образом переливалась через переборки. Итог мы все помним.
3. Вместо распределения нагрузки — вертикальное масштабирование
Многие крупные компании по-прежнему выбирают высокопроизводительное и дорогое оборудование при масштабировании монолитной системы вместо того, чтобы обеспечить сегментирование клиентов по множеству небольших БД.
Такое решение в архитектуре не только приводит к повышению расходов на транзакции, но и может принести существенный ущерб в случае сбоя. В конечном итоге, либо система будет слишком громоздкой и станет частично простаивать, что поставит под вопрос эффективность ваших капиталовложений, либо система окажется недостаточно крупной при росте проекта. Как бы там ни было, это всё равно закончится проблемами для вашего продукта. Достаточно вспомнить PayPal в 2004 г. и eBay в 1999 г.
4. Выбор неверных инструментов
Если вы позовёте столяра починить кран, он придёт с молотком и, скорее всего, вы останетесь недовольны результатом ремонта. Почему же в реальной жизни мы нередко просим помочь с архитектурой продукта, например, специалиста по базам данных? Да, реляционная БД до сих пор основная и нередко оптимально подходит, но мы сейчас располагаем массой других вариантов по организации распределённого хранения с учётом типа данных. Но что бы вы не выбрали, помните, что хранение данных всегда должно коррелировать с дополнительными затратами на внедрение и поддержку используемых технологий.
Статья написана по материалам «Top 10 Architectural, Organizational and Process Related Failures».
