XAP (Хреновая Архитектура Разоряет)

Вчера я первый раз написал статью на хабр, не зная местных тонкостей.

Исправляюсь! Теперь понятным языком и с юмором!

Чёрная пятница оказалась воистину чёрной для aмериканского интернет-универмага Kohl's. Все сервера накрылись медным тазом именно в день рождественских распродаж. Привычные 20% годового дохода, добываемые в этот день, обернулись смешным пустяком, а все потому что Боливар не вынес такой нагрузки.

Традиционная архитектура Tomcat + WebLogic + БД облажалась по полной программе! Напрасно бегали по этажам сисадмины, суетились в панике ведущие программисты, а архитекторы выдирали остатки волос… Горлышко бутылки оказалось слишком узким для того, чтобы в него могли протиснуться все потенциальные клиенты и недостаточно эластичным, чтобы за короткое время его можно было успеть расширить. Бутылку разорвало нахрен. И долго еще кровоточили раны, нанесённые ее осколками…

Проблемы трёхуровневой архитектуры

– Сынок, работает – не трогай!
– Папа, оно не работает, оно ТОРМОЗИТ!!!

Всем вам прекрасно известна старая, но далеко не всегда добрая трёхуровневая архитектура.

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

Трудности в управлении

Все уровни имеют различные модели кластеризации. Для управления такой системой требуются знания и опыт работы со всеми из них. Это влечет за собой:

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

Привязка к статическим ресурсам

Таким, как жёсткие диски и имена серверов. Сложности возникают при установке таких приложений в облака, так как те очень динамичны по своей натуре.

Производительность

Почти любой запрос проходит через все три уровня системы и может включать в себя множество сетевых прыжков между уровнями и внутри них, что плохо сказывается на среднем времени отклика. К тому же рано или поздно данные придется сбрасывать на диск. Сетевой и дисковый I/O значительно ограничивает масштабируемость и, опять-таки, приводит к торможению системы.

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

Почему cache и datagrid не решают проблему

Чтобы решить проблемы времени ожидания и масштабируемости обычно ставят in-memory datagrid перед реляционной базой данных. Несомненно, это шаг в правильном направлении, который частично разгрузит систему и, в основном, подходит для кэширования. Стоит обратить внимание, что большинство datagrid’ов ограничены своей возможностью извлекать данные только при помощи уникального ID. Хотя такое решение может быть применено в отдельных случаях, все же оно не идеально по следующим причинам:

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

Пример из реального мира

Рассмотрим реальную многоуровневую архитектуру системы компании Kohl’s из сферы интернет-продаж.

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

В случае Kohl’s WebLogic, Apache и база данных Oracle прекрасно справлялись с задачами, используя 50 физических серверов. 30 000 одновременно подсоединённых пользователей исправно получали ответы на все запросы. Оно бы всё продолжало работать и впредь, если бы, например, компания должна была бы обслуживать определённое фиксированное количество транзакций ежесекундно, и не происходило бы никаких резких изменений в требованиях к системе.

Однако, та самая «черная пятница» (Black Friday, когда миллионы американцев рвутся в магазины, а ритейлеры делают 20, а иногда и 30 процентов от годовой выручки за один день) 2009-го года потребовала, чтобы система справилась с нагрузкой в 500 000 пользователей одновременно. К такому удару трёхуровневая архитектура была не готова…

Результат — потеря десятков миллионов долларов. Отсюда вопрос:

Не пришла ли пора сменить старых героев?

Итак, сформулируем ключевые требования к современной платформе:

• Операции с данными должны быть быстрыми
• Разделение между слоями абстракции не должно бить по производительности
• Добавление новых ресурсов должно линейно (или почти линейно) увеличивать производительность, а также не упираться ни в какие ограничения.
• Диплоймент должен быть одновременно гибким и простым.
• Система должна быть «неубиваемой» и заранее предупреждать об потенциальных проблемах.

Примерно такими требованиями руководствовались инженеры компании Gigaspaces которые 10 лет назад начали разработку новой платформы XAP (eXtreme Application Platform)

Вот как они все придумали

• Все данные хранятся в оперативке, а не на диске. Если что, оперативка сегодня очень дешевая, ни в пример Оракловой БД даже с самым простым саппортом
• Логика приложения сидит в одном контейнере с данными. Это конечно может не понравится университетским преподавателям и прочим любителям классической архитектуры. Инойин даже может решить, что такое решение способствует нездоровому смешиванию данных с логикой. Однако опыт показывает, что настоящих умельцев никакие слои не остановят и при наличии должных навыков, винегрет можно сделать, имея какую угодно «архитектуру»!
• Все данные разбиваются на неограниченное количество партишенов, каждый из которых может сидеть в отдельной машине.
• Диплоймент описывается декларативно! «разбей мне все данные на 100500 кусков, на каждый кусок сделай по 2 бэкапа, не диплой бэкапы в одном дата центре, не используй для диплойменты машины нагруженные больше чем на 146 процентов»
• Специальные диспетчеры пишут данные сразу в несколько мест и в случае сбоя автоматически перенаправляют запросы на другие машины. Паралельно с этим существует удобная система мониторинга, которая уведомляет обо всех потенциальных проблемах, таких как недостаточное количество нодов в кластере, сбои в системе или перегруженность машин.

А вот видео

Компания Kohl воскресла из пепла

После кризиса 2009 года компания Коhl заменила всю старую архитектуру на XAP. В результате, по данным гугла сегодня их сайт занимает одно из первых мест в мире по скорости выдачи страниц

На сегодняшний день платформой XAP пользуется далеко не только Kohl. В списке её клиентов сегодня присутствуют ведущие швейцарские банки (например, UBS), нью-йоркская биржа, компания Avaya и еще сотни других компаний.

Эпилог

Кто-то скажет: «А я использую многоуровневую архитектуру и очень доволен!» И очень хорошо. Но живя в мире, где объём данных растёт экспоненциально, мы должны понимать, что даже если сегодня нет необходимости в in-memory computing platform, то нам стоит хотя бы знать об их существовании и о том, какую пользу они несут. Может, уже в ближайшем будущем вырастут требования к количеству обрабатываемых Вашим приложением данных и тогда, несомненно, in-memory computing platforms могут помочь, не говоря о приложениях, оперирующих в реальном времени огромными объёмами данных, для которых их использование просто необходимо.

Постскриптум

Приходите на JUG в субботу 31 числа, и я расскажу вам о XAP намного более красочно и вживую продемонстрирую его работу.

Автор: EvgenyBorisov

Источник