Эта статья предназначена для краткого обзора книги Разработка приложений, интенсивно использующих данные », написанной Мартином Клеппманном. Профессионалы в области высоких технологий могут воспринимать важность разработки устойчивых и надежных приложений как должное; тем не менее, давайте начнем разговор с некоторого контекста для всех читателей, не разбирающихся в технике.

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

Более того, программное обеспечение с открытым исходным кодом стало очень успешным и предпочтительным по сравнению с другими альтернативами. Инфраструктура как услуга (IaaS) также играет ключевую роль в этом развитии, поскольку позволяет небольшим командам создавать распределенные системы на многих машинах и в разных странах. Синергия, созданная нынешней технологической экосистемой, привела к тому, что в нашей реальности приложения с очень высоким уровнем работоспособности стали нормой, а перерывы в обслуживании практически недопустимы.

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

Каждая часть программного обеспечения уникальна и должна рассматриваться как таковая, но также верно и то, что есть основы, общие для большинства программных систем. Основы могут быть сокращены до надежности, масштабируемости и ремонтопригодности.

Надежность

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

По словам Клеппманна, надежная система:
• Выполняет функции, которые ожидает пользователь.
• Может терпеть ошибки пользователя или использование программного обеспечения неожиданными способами.
• Хорошая производительность достаточно для требуемого варианта использования при ожидаемой нагрузке и объеме данных.
• Предотвращает любой несанкционированный доступ и злоупотребления.

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

Аппаратные ошибки

Несмотря на то, что аппаратные ошибки не актуальны в небольших сетях, они могут чаще возникать в крупных центрах обработки данных с большим количеством машин. Документально подтверждено, что средняя наработка жестких дисков до отказа составляет от 10 до 50 лет. Если рассматривать это в перспективе, это будет эквивалентно выходу одного диска из строя в день в кластере хранения с 10 000 дисков.

К распространенным аппаратным ошибкам относятся:
• Неисправность ОЗУ
• Отключение электросети
• Сбои жесткого диска
• Отсоединение неправильного сетевого кабеля.

Программные ошибки

Вероятно, самая «сложная» неисправность связана с программным обеспечением. Если код не протестирован должным образом, программные ошибки могут присутствовать внутри нашего кода в течение длительного времени, не вызывая особых проблем. Это, конечно, до тех пор, пока они не будут вызваны набором необычных обстоятельств. В таких случаях проблема могла быть обнаружена, потому что программное обеспечение делало некоторые обычно верные предположения, но в конечном итоге по какой-то причине они перестали быть верными.

Вот несколько сценариев, при которых ошибка может внезапно стать очевидной и по очереди вызвать у инженеров как удивление, так и головную боль:

• Когда сервер приложений выходит из строя из-за неправильного ввода из-за ошибки программного обеспечения. Хорошо известный случай произошел 30 июня 2012 г., когда из-за ошибки в ядре Linux дополнительная секунда вызвала одновременное зависание нескольких приложений.

• Неуправляемый процесс, который использует некоторые общие ресурсы - время ЦП, память, дисковое пространство или пропускную способность сети.

• Важная служба для системы, которая замедляется, перестает отвечать или начинает возвращать поврежденные ответы.

• Каскадные сбои, когда незначительный дефект в одном компоненте вызывает ошибку в другом компоненте, что, в свою очередь, вызывает дальнейшие сбои ».

Масштабируемость

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

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

«Люди часто говорят о дихотомии между масштабированием (вертикальное масштабирование, переход на мощную машину) и масштабированием (горизонтальное масштабирование, распределение нагрузки между несколькими меньшими машинами)».

- Кепплеман, 2017 г.

Основная цель рассмотрения масштабируемости при разработке приложения - поддерживать производительность независимо от увеличения числа пользователей. Загрузка приложения может быть описана с помощью параметров загрузки. Чтобы выбрать лучшее, нужно учесть:

  • Количество запросов к веб-серверу в секунду.
  • Отношение чтения к записи в базе данных
  • Количество одновременно активных пользователей в чате
  • Частота попаданий в кеш.

Ремонтопригодность

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

«Мы можем и должны разрабатывать программное обеспечение таким образом, чтобы оно, как мы надеемся, сводило к минимуму боль во время обслуживания и, таким образом, не создавало унаследованное программное обеспечение самим».

- Кепплеман, 2017.

Фактически, есть принципы пунктуального проектирования, на которых мы можем сосредоточиться, чтобы упростить обслуживание системы и избежать создания устаревшего программного обеспечения:

  • Работоспособность. Операционные группы должны обеспечивать бесперебойную работу системы.
  • Простота: новые инженеры должны понимать систему, удаляя как можно больше информации. Это не то же самое, что упрощение пользовательского интерфейса.
  • Эволюционируемость: помогает инженерам вносить изменения в систему в будущем, адаптируясь к неожиданным вариантам использования по мере изменения требований. Некоторые синонимы - расширяемость и пластичность.

Почему инженеры-программисты всегда нужны, несмотря на достижения в области автоматизации и искусственного интеллекта? Потому что (к сожалению) не существует простых и фиксированных решений для обеспечения надежности, масштабируемости и поддержки приложений. Однако десятилетия разработки программных продуктов показали нам, что определенные шаблоны и методы продолжают появляться в приложениях, даже когда их цель и использование совершенно разные.

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