На сегодняшний день сложились серьезные предпосылки для качественного изменения информационных систем в пользу обработки событий и больших потоков транзакций.
Внешне различие между корпоративными информационными системами сорокалетней давности и современными системами колоссальны, но эти системы сохранили свои базисные врожденные черты. Несмотря на то что изменялись аппаратура и программное обеспечение, связи между системными компонентами оставались жесткими почти все информационные системы оставались изолированными от окружающей среды. Такое положение сохранялось примерно до 2000 года, когда установившиеся представления об информационных системах подверглись влиянию двух основных факторов.
Во-первых, с появлением сервис-ориентированных архитектур (Service-Oriented Architecture, SOA) жестко связанные системы стали понемногу вытесняться системами со слабыми связями. Во-вторых, информационные системы самых разных типов теряют свою изолированность от окружения и все чаще наделяются различного рода связями с внешней средой. Нередко эту тенденцию называют «сенсорной революцией». Во многом именно реакцией на сенсорную революцию стало появление систем со словом «событие» в названии — системы, управляемые событиями EDA (Event Driven System, EDA), обработка сложных событий (Complex Event Processing, CEP) – и других, способных реагировать на происходящее вовне. Продолжают этот ряд системы обработки больших объемов транзакций (eXtended Transaction Processing, XTP). Многочисленные сенсоры передают сведения о событиях из внешней среды, в ответ на это системы, управляемые событиями, оперативно их обрабатывают с помощью систем обработки сложных событий, которые, в свою очередь, приводят к созданию систем для обработки больших объемов транзакций. Сенсорная революция – одна из наиболее важных технологических новаций текущего десятилетия. Речь идет о массовом распространении датчиков, или сенсоров, объединяемых в сети. Наиболее распространенный пример — системы радиочастотной идентификации (RFID).
Качественное отличие современного подхода к сенсорам состоит в том, что предполагается их массовое использование, не единицами или десятками, как в технических системах, а сотнями и тысячами, что означает диалектический переход количества в качество. Объединение большого числа сенсоров в сети позволяет получить обобщенную картину среды, требующей обработки больших объемов данных в реальном времени. На рисунке представлен пример информационной системы, снабженной сенсорной сетью и включающей в себя не только датчики, передающие данные, но и регуляторы, отрабатывающие передаваемые на них управляющие воздействия. Такая сеть заметно отличается от классической локальной сети, служащей для обмена файлами между компьютерами и подключения ограниченной номенклатуры периферии. Среди подключенных устройств могут быть датчики состояния среды, разного рода контроллеры, цифровые камеры, датчики, монтируемые в мобильные устройства, считыватели штрихкодов и т.д.
Все многообразие сенсоров можно разделить на две категории: сложные устройства, имеющие встроенные процессоры и потому обладающие «интеллектом», и простые устройства. В последнем случае для работы с сенсорами требуются специализированные серверы — так называемые «серверы переднего края» (edge server), эти серверы являются основными поставщиками данных для информационных систем, а для обозначения внешней границы локальной сети появился специальный термин — «кромка сети» (edge of the network).
Лет пять назад сенсорным сетям предсказывали фантастическое будущее, но в реальности переход от исследовательской фазы к производственной оказался куда сложнее, чем предполагалось. В отчете Spyglass мы можем найти: «Для полноценного внедрения сенсорных технологий требуется более плотное взаимодействие с софтверными компаниями, которые могли бы создать программное обеспечение промежуточного слоя нового типа, способное объединить все необходимое для обработки больших потоков данных. Сегодня такие системы создаются по индивидуальным заказам, что требует слишком больших инвестиций». Этот вывод поражает тем, что барьером на пути внедрения перспективных технологий оказалось не отсутствие аппаратного обеспечения или приложений, а неготовность программных решений промежуточного слоя, то есть инструментария для CEP и XTP.
Системы в контексте
Отставание функциональных информационных систем от требований сенсорной революции объясняется не столько техническими причинами, сколько методологическими – большинство специалистов не имеет достаточного багажа системных знаний, не знакомо с кибернетическими подходами, не догадывается о существовании общей теории систем и иных дисциплин, формирующих системное мышление. В итоге развитие идет методом проб и ошибок, порождая бесконечные новые аббревиатуры, а целостной картины происходящего все нет.
В совокупности SOA, RTE (Real Time Enterprise), CEP, XTP и т.д. представляют собой отражение чего-то общего, целого, где каждое из этих понятий по-своему отражает то, что называют сейчас Enterprise 2.0. Системы управления бизнесом постепенно приобретают общие черты с системами управления технологическими процессами, обретая датчики, различного рода механизмы оптимизации, панели управления и другие давно знакомые и известные атрибуты АСУТП. Принципиальное же отличие информационных систем нового типа состоит в том, что в дополнение к человеко-машинным коммуникациям в них появляются машинно-машинные коммуникации. Если до сих пор кромкой сети, связывающей систему с внешним миром, были клиенты, то теперь ею становятся устройства.
В качестве обобщающего термина аналитики Gatner ввели в оборот слово «контекст» и предложили еще одну аббревиатуру – CoDA, расшифровываемую как Сontext Delivery Architecture («архитектура доставки контекста») или Context-Driven Architecture («архитектура, управляемая контекстом»). Они определяют CoDA как архитектурный стиль для создания бизнес-приложений, основанных на взаимодействии SOA и EDA, которые способны выделять сведения из контекста и использовать их в реальном времени. Такие приложения называют «способными работать в контексте» (context-aware). Использование CoDA способствует формированию нового направления в ИТ, которое в Gartner назвали context-aware computing.
CEP и XTP
Если бизнес-системы, как системы биологические или технические, станут работать в связи с окружающим их контекстом, то одной из важнейших первичных функций станет обработка событий с последующей передачей необходимых сведений в подсистемы мониторинга бизнеса, бизнес-аналитики и др. «Поставщиками» событий в них будут серверы переднего края, передающие данные в CEP. Между функциями подсистем CEP и систем управления базами данных можно провести параллель: и те и другие нужны для того, чтобы обеспечить работу с данными, но подходы к организации этой работы принципиально разные. В задачу СУБД входит накопление данных и обработка запросов, написанных на каком-либо языке, – работа выполняется в режиме вопрос/ответ, и жестких требований по времени нет. CEP работает иначе – такие системы можно интерпретировать как фильтры, в которых хранятся не данные, а правила, по которым производится работа с потоками данных. Эти правила описываются на языке обработки событий (Event Processing Language, EPL), выполняющем примерно ту же функцию по отношению к событиям, что и SQL для исторических данных. Работу CEP можно интерпретировать как непрерывное выполнение запросов – данные распределяются по подписке или передаются как оповещения о событиях, и время является критическим фактором.
Эта параллель помогает логически обосновать необходимость XTP. Эта разновидность обработки существует в контекстной среде и выполняет примерно ту же функцию по отношению в CEP, какую обычные системы обработки транзакций выполняют по отношению к базам данных. Необходимость в расширении функций по обработке данных в реальном времени вызвана тем, что возможности CEP ограничены выделением нужных данных и применением к ним ограниченного подмножества правил, написанных на EPL. В некоторых приложениях этого бывает достаточно, но иногда требуется дополнительная обработка, в таком случае XTP связывает CEP с SOA и организует необходимую обработку данных непосредственно в памяти, без обращения к базам данных.
Происхождение XTP
В отечественной литературе транзакцию почти всегда понимают в связи с базами данных, что слишком узко. На Западе под транзакциями понимают любые взаимосвязанные операции над данными.
Ускорение в XTP чаще всего обеспечивается за счет распараллеливания, поэтому здесь можно провести аналогию с законом Амдала, который постулирует, что время выполнения задачи на параллельной системе не может быть меньше времени выполнения самого длинного фрагмента. Если модель данных хорошо фрагментируется (скажем, если данные поступают от множества датчиков), то организовать параллельную обработку несложно; в противном случае надо идти классическим путем. Это следует учитывать при сравнении методов аппаратного ускорения: так, zAAP основан на подходе, традиционном для мира мэйнфреймов, а Azul Compute Appliance создан по модели, отличной от модели фон Неймана.
Первым термин XTP в 2006 году использовал известный аналитик из Gartner Массимо Пеццини в отчете The Challenges of Extreme Transaction Processing in a World of Services and Events. Через год вышел более объемный отчет Extreme Transaction Processing: Technologies to Watch, содержащий обзор технологий, которые могут быть использованы для XTP. В нем направление XTP рассматривается как развитие классических систем обработки транзакций, которые должны обладать набором качеств ACID (Atomicity – «атомарность», Consistency – «непротиворечивость», Isolation – «изолированность», Durability – «долговечность»). Как и любая распределенная транзакционная система, XTP должна обладать высокой производительностью, масштабируемостью и готовностью, быть безопасной и управляемой. Но плюс к тому она должна быть способна к обработке больших объемов транзакций в режиме, близком к реальному времени. Основное отличие XTP от классических систем обработки транзакций в том, что последние выполняются в строго заданном порядке и обычно строятся на основе монолитных и жестко контролируемых архитектур,
а XTP работают в более структурно сложных и динамичных средах.
В условиях сервисных архитектур гетерогенные данные могут поступать из разных источников, причем в режиме реального времени, а классические системы обработки транзакций строились в расчете на однородные данные, хранимые в базах. В традиционных системах обработки транзакций чаще всего применяются технологии с вертикальным масштабированием – серверы и мэйнфреймы, а XTP-приложения чаще предполагают использование горизонтального оборудования, стандартных серверов и систем хранения, программных платформ Java, .Net, XML
и Web-сервисов.
Странно, что аналитики Gartner не обратили внимания на родство XTP и CEP. И те и другие служат для обработки больших объемов данных в режиме, близком к реальному времени, но системы класса CEP стоят на входе и служат для сбора и фильтрации данных. Системы CEP делятся на два класса: «вычислительные» (сomputation oriented) и «распознавательные» (detection oriented), но и тот и другой не предполагают выполнения заметных объемов транзакций, их результаты остаются на интерфейсном уровне информационных систем (fron-tend), не переходя в базы данных,
в операционную часть (back-end). Технологии XTP через корпоративную сервисную шину ESB связываются с сервис-ориентированной архитектурой, как это сделано, например, в Oracle Coherence, объединяющем XTP с CEP.
Классическая обработка транзакций начиналась еще на мэйнфреймах, но 10-12 лет назад были предложены серверы корпоративных приложений (Enterprise Application Server, EAS), ставшие одной из составляющих ПО промежуточного слоя в трехзвенной архитектуре. В большинстве своем серверы корпоративных приложений строят на основе Java EE и реже на .net, причем они создавались задолго до появления SOA, ESB, EDA, и уж тем более до XTP. Появление перечисленных технологий не отменяет необходимости в EAS, но, напротив, усиливает ее: поддержка XTP является расширением функций EAS.
Аппаратные ускорители
На данный момент аппаратные ускорители известны для Java-приложений. Специализированные устройства такого рода выпускают IBM и Azul Systems, а применением универсальных серверов для этих целей занимается компания Terracotta. Эта компания предлагает решение для разбиения одной «большой» виртуальной машины Java (JVM) на кластер из серверов стандартной архитектуры.
Специализированный процессор zSeries Application Assist Processor (zAAP) подключается к мэйнфреймам IBM System z, а его функциональные возможности ограничены исключительно выполнением Java-приложений. Такой процессор, по существу, представляет собой усеченный мэйнфрейм, который при стоимости на 70% меньше полноценного мэйнфрейма выполняет Java-приложения с такой же производительностью. Процессор zAAP работает с серверами z990/z890 и стоит в ряду аналогичных спецпроцессоров IBM, предназначенных для оптимизации выполнения Linux-сред (Integrated Facility for Linux), для поддержки СУБД DB2 (Z9 Integrated Information Processor) и др. Процессор работает асинхронно относительно центральных процессоров, выполняя Java-приложения под управлением виртуальной машины Java. Его применение позволяет снизить требования к вычислительной мощности и нагрузку на центральный процессор, который в результате высвобождается для выполнения других работ. Экономия ресурсов процессора общего назначения зависит от доли кода Java-приложений, выполняемого процессором zAAP. Важно отметить, что циклы обработки IBM JVM могут выполняться на zAAP без каких-либо изменений кода приложений Java. Для выполнения обработки JVM на процессоре zAAP требуется инструментарий IBM Software Developer Kit for z/OS, Java 2 Technology Edition, z/OS, а также Processor Resource/Systems Manager.
Основатели компании Azul одними из первых осознали, что собственно выполнение Java-приложений не связано с аппаратной платформой и операционной средой, поэтому можно ограничиться упрощенными специализированными вычислительными устройствами, предназначенными для выполнения платформонезависимых кодов, а все, что в приложениях специфично для платформы, оставить за традиционными серверами. Модель вычислений, которую они развивают, можно по аналогии с Network Attached Storage назвать «сетевыми вычислителями» (Network Attached Processing, NAP). Суть модели в том, что создается централизованный пул процессоров и памяти, предоставляемый приложениям, передаваемым по сети. За семь лет работы у компании не появилось ни одного прямого конкурента, хотя косвенным образом она противостоит производителям и мощных Unix-серверов, и кластеров. За эти годы компания выпустила три поколения многоядерных процессоров, нынешний Vega 3 Series имеет 54 ядра, а специализированный вычислитель на их базе выпускается в двух основных вариантах: 3300 Series (высота 5U, два-четыре процессора, 48-192 Гбайт оперативной памяти) и 7300 Series (14U, 8-16 процессоров, 192-768 Гбайт памяти).
По данным Azul, производительность повышается на порядки, однако важна не только скорость: интеграция аппаратных компонентов с компонентами JVM позволяет уменьшить влияние двух факторов, препятствующих масштабированию Java-приложений. Первый фактор – ограничения, связанные с законом Амдала. Технология Optimistic Thread Concurrency, используя некоторые приемы из CУБД, позволяет не ждать окончания длительных фрагментов, а распараллеливать обработку данных, связанных с этими фрагментами, между несколькими JVM. Второй – мусор, для сборки которого используется технология Pauseless Garbage Collection, позволяющая Java-приложениям задействовать до 100-200 Гбайт памяти, не прерываясь на сборку, что в несколько раз повышает быстродействие.
Наличие этих функций дает Azul функциональные преимущества перед кластерными решениями, предлагаемыми, например, компанией Terracotta, подход к ускорению работы с памятью которой называется Network Attached Memory (NAM). Объединенная память кластера позволяет создать большое количество JVM и распределить между ними потоки. Писать и отлаживать приложение можно на одной такой машине, а затем, введя небольшое дополнение в код (специальные байт-коды, обеспечивающие кластерные возможности), выполнять это приложение на нескольких JVM. Технология NAM представляет собой простой способ увеличения вычислительной мощности путем добавления стандартных серверов.
Общее достоинство любых ускорителей – отсутствие изменений в приложениях. К числу неизбежных «но» следует отнести ограниченность области применения исключительно Java-приложениями и неизбежная привязанность пользователей к одному производителю. Кроме того, специализированные устройства испытывают сегодня сильное давление со стороны стандартных серверов, обеспечивающих горизонтальное масштабирование, и новых подходов, связанные с облачными вычислениями.
Распределенное кэширование
Сервер Terracotta v.3 можно отнести еще к одной категории решений, поддерживающих XTP и называемых «распределенными кэширующими платформами» (Distributed Caching Platform, DCP), обеспечивающими ускорение всех операций с данными за счет их выполнения непосредственно в оперативной памяти. Техническая возможность для появления решений этого типа возникла после удешевления памяти и распространения 64-разрядных процессоров, однако хранение данных в оперативной памяти не столь надежно, как в СУБД. Если распределить кэшируемые данные между множеством серверов, поддерживать технологии кластеризации, восстановления после сбоя, зеркалирования и репликации, то можно достигнуть необходимого уровня безопасности данных. К данным в кэше могут обращаться различные программы, используя несколько интерфейсов: SQLJ, JDO, JMS, XML:DB или JCache. Продукты, поддерживающие распределенный кэш, производят компании Alachisoft, IBM, Red Hat/JBoss, GemStone, GigaSpaces, Progress Software, Tangosol и Terracotta.
В качестве типичного устройства можно назвать решение GemFire Enterprise компании GemStone Systems, представляющее собой платформу управления данными, распределенными по пулу памяти множества серверов. Дополнительно GemFire управляет процессорами, сетью, дисками и служит для поддержки приложений, работающих с большими объемами данных, обладает непрерывной готовностью, высокой производительностью и линейным масштабированием. Ядром служит компонент GemFire Real-Time Events, поддерживающий обработку сложных событий CEP в режиме реального времени и обеспечивающий идентификацию событий в реальном времени, анализ в соответствии с образами и сценариями, распределение информации о событиях между приложениями. Примерно ту же функцию выполняет платформа eXtreme Application Platform от компании GigaSpaces, имеющая в своем составе подсистемуXTP и работающая на серверах HP BladeSystem и HP ProLiant.
Динамическое управление ресурсами
Для обнаружения, организации и последующего мониторинга совокупности ресурсов, предназначенных для выполнения некоторого приложения, применяются брокеры динамических ресурсов (Dynamic Resource Broker, DRB). Если информационная система построена как слабосвязанный кластер, то появляется возможность для динамической группировки и перегруппировки его ресурсов в соответствии с требованиями текущего момента. Например, можно запускать большее число экземпляров серверов приложений, когда нагрузка возрастает, и уменьшать их количество при уменьшении нагрузки. Наиболее известны реализации DRB компаний Cassatt и DataSynapse, но такие крупные производители, как BEA Systems, IBM, Oracle и Fujitsu, тоже развивают этот подход к XTP. В продуктах DataSynapse реализован процесс динамического управления приложениями Dynamic Application Service Management, включающий два начальных этапа: задание характеристик среды и представление приложений, а затем перераспределение ресурсов. В продуктах Cassatt принципы динамического распределения ресурсов распространяются на облака. Нынешнее поколение технологий DRB имеет целый ряд ограничений: сам пул управляемых ресурсов не может быть динамическим, его нельзя изменять в процессе работы, их функциональность ограничена ESB и не распространяется на сетевые ресурсы и на системы хранения данных.
Платформы для EDA
Для поддержки приложений, созданных по событийной (event-centric) программной модели, может быть построена специальная платформа Event-Driven Application Platform (EDAP). Такие приложения могут не только отрабатывать поток входных событий, но и благодаря манипулятору событий (event handler) воспринимать события и генерировать новые, распространяя их по системе. Таким образом, посредством событий воссоздается распределенная модель, где отдельные компоненты не вызывают друг друга по именам, как это делается в классической архитектуре SOA, а взаимодействуют «косвенно», обмениваясь сообщениями о событиях по шине. Манипуляторы не знают друг друга, их задача – получать события и порождать ответные, а задача EDAP-приложений – как можно быстрее реагировать на события.
Благодаря минимальной связи между собой отдельных модулей модель EDAP отличается гибкостью интеграции и расширения приложений, что открывает новые возможности для мониторинга и анализа. С точки зрения повышения производительности систем XTP ее достоинство состоит в возможности разделения независимых манипуляторов на мелкие компоненты, которые можно выполнять на независимых виртуальных машинах Java, связанных между собой сообщениями.
В качестве программой технологии для EDAP может быть использована среда с набором спецификаций Java Service Logic Execution Environment (JSLEE, или JAIN SLEE), изначально созданная сообществом Java Community Process для телекоммуникационных приложений и рассчитанная на обработку больших объемов трафика. Среди производителей, специализирующихся на EDAP, можно отметить компании JNetX, Kabira, Mobicent, OpenCloud, Sybase (iAnyWare) и WareLite. Типичными примерами служат продукты Business Operating Support System (WL BOSS) и Event-Driven Real Time Business Solutions на базе WL BOSS, поставляемые британской компанией WareLite и обеспечивающие XTP в режиме реального времени.
