В статье рассматривается экономически-обоснованный подход к построению эффективной малозатратной высокоуровневой архитектуры горизонтально масштабируемых географически-распределенных систем, и преимущества использования распределенного кэширования оперативной памяти (in-memory distributed caching) на примере использования технологий Ehcache, Apache Cassandra, Apache Kafka.
Согласно исследованию ведущей консалтинговой компании McKinsey, big data – следующий шаг для инноваций, повышения производительности и конкурентоспособности. Все больше компаний вкладывают свои ресурсы в технологии обработки больших объемов данных. McKinsey прогнозирует не просто экспоненциальный рост big data технологий в краткосрочной перспективе, но неизбежное тотальное распространение практически во всех отраслях экономики. Для технологических компаний это откроет широчайшие возможности развития и роста. И вместе с тем, бросит вызов их экспертизе и опыту.
Во-первых, при обработке больших объемов данных необходимо обеспечить их непрерывный приток. Для этого, система на входе, которая принимает запросы от клиентов, должна обеспечивать прием, хранение и выдачу данных 24х7, 365 дней в году, без задержек и сбоев, и быть максимально толерантной к проблемам с аппаратным обеспечением и электропитанием.
Во-вторых, система должна уметь обрабатывать большое количество запросов в единицу времени, так как очевидно, что скорость обработки каждого запроса непосредственно влияет на общее количество принятых данных.
В-третьих, система должна быть готова к обслуживанию не только существующих вычислительных ресурсов, но и к подключению новых вычислительных мощностей «на лету», без временных задержек и сбоев.
В-четвертых, такая система должна иметь архитектурную базу для построения географически распределенной вычислительной сети.
Цель любой технологической компании, которая проектирует подобные системы – обеспечить все эти параметры. Но, помимо задач, связанных с технологическими проблемами больших объемов данных, при построении систем big data необходимо учитывать интересы бизнеса, а именно: увеличение эффективности сложных «mission critical» систем, при относительно небольшом изменении издержек на поддержку и обслуживание инфраструктуры. Общеизвестно, что оперативная память является более «быстрым» и оптимальным, хотя и дорогим хранилищем данных по сравнению с жестким диском. Таким образом, организация быстрого недорогого хранилища становится краеугольным камнем многих проектируемых систем, и технологии in-memory distributed caching также помогают решать подобные задачи.
На рынке существует ряд проприетарных решений, предоставляющих предконфигурированные решения для обработки больших данных, со своими преимуществами и ограничениями. Я попробую рассмотреть модель построения архитектуры такой системы, базируясь на решениях свободного программного обеспечения (далее – СПО). Выбор СПО обоснован их достаточно широким распространением, доступностью (отсутствием или малой стоимостью лицензий) и достаточно широкой поддержкой профессионального коммьюнити, обеспечивающей своевременное выявление и устранение дефектов, консультирование и выход обновлений.
Архитектура
Для начала рассмотрим типовые высокоуровневые компоненты системы обработки big data.
Кластер организации, состоящий из нескольких географически-распределенных центров обработки данных, принимает запросы от пользователей через балансировщик нагрузки. На основании данных о загруженности/доступности дата центров, географической принадлежности запроса или другой совокупности настраиваемых признаков, балансировщик принимает решение о том, в какой дата центр лучше перенаправить полученный запрос. Таким образом, на этом этапе балансировка помогает решить задачу максимально эффективного использования имеющихся вычислительных ресурсов.
Теперь рассмотрим высокоуровневую архитектуру дата центров кластера, которые обычно содержат узлы следующих систем:
Для системы, построенной на СПО решениях, я предлагаю использование следующий технологий:
Распределенная очередь сообщений
Для распределенной очереди сообщений я предлагаю использовать систему Apache Kafka. Это распределенная система передачи сообщений, разработанная компанией LinkedIn, и впоследствии переданная в Apache Incubator.
[pullquote]
Apache Kafka — распределённый программный брокер сообщений, проект с открытым исходным кодом, разработанный в рамках Apache Software Foundation. Одной из особенностей реализации инструмента является применение техники, сходной с журналами транзакций, используемыми в системах управления базами данных.
Wikipedia
[/pullquote]
Основные преимущества Apache Kafka:
- Изначально проектировалась для работы в распределенных средах и поэтому решения на ее базе довольно просто масштабируются.
- Обеспечивает высокую пропускную способность для сообщений.
- Автоматически балансирует подписчиков во время аварии.
- Сообщения хранятся на диске и могут быть использованы для пакетной обработки.
- Сообщения синхронизируются между дата центрами, так что обработка сообщений продолжается даже в случае отключения одного из узлов.
Использования Apache Kafka как брокера сообщений позволяет нам гарантировать доставку сообщения, пока есть хотя бы один рабочий сервер во всем кластере организации. Это важно для обеспечения работы 24×7 и гарантированной сохранности данных.
Распределенный кеш
Система распределенного кеширования очень важна для обеспечения высокой скорости обработки пользовательских запросов. Правильное кеширование данных в распределенной системе позволяет улучшить показатели эффективности срабатывания кеша, и тем самым сокращает время обработки запросов.
[pullquote]
Ehcache — это широко используемое решение для построения Java distributed cache. Решение предоставляет возможность хранения данных на диске и в памяти. Ehcache распространяется по лицензии Apache open source license и активно поддерживается сообществом разработчиков. Ehcache был разработан Грегом Лаком в 2003 году. В 2009 году проект был приобретен компанией Terracota.
Wikipedia[/pullquote]
Например, на Дата центр «Альфа» пришел запрос от пользователя 1 из города М. на получение списка всех движений материальных активов условной категории А за январь 2014 года. Дата центр «Альфа» формирует данные, помещает их в распределенный кеш и отправляет пользователю. Время выполнения данного запроса – 30 секунд. Через некоторое время, пользователь 2 из города Н отправляет тот же самый запрос на Дата центр «Бета». Если бы, кеш не был распределенным, то пользователь 2 должен был ждать те же 30 секунд пока система формирует данные и уже после этого получить их. Но так как наша система кеширования уже имеет данные, сформированые по критерию «категория А, январь 2014», то она просто отдает их пользователю без вызова хранилища для формирования сводки. В этом случае пользователь 2 ждет всего 0.5 секунды до получения запрошенных данных.
На данном слое я предлагаю использовать продукт Ehcache от компании Terracota. Данный продукт позволяет организовать распределенное хранение кешированных данных в кластере с простым подключением новых узлов. Мой выбор в данном случае обосновывается:
- хорошей масштабируемостью и стабильностью решения
- достаточной гибкостью и простотой настройки
- наличием полноценной технической поддержки от компании-владельца Terracota
Распределенное NoSQL хранилище
Распределенное NoSQL хранилище кеширует данные из реляционного хранилища и выполняет простые выборки данных по критериям. Также NoSQL решение позволяет обеспечить быстрое добавление данных в хранилище.
[pullquote]
Apache Cassandra — распределённая система управления базами данных, относящаяся к классу noSQL-систем и рассчитанная на создание высокомасштабируемых и надёжных хранилищ огромных массивов данных, представленных в виде хэша. Изначально проект был разработан в недрах Facebook и в 2009 году передан под крыло фонда Apache Software Foundation, эта организация продолжает развитие проекта. Промышленные решения на базе Cassandra развёрнуты для обеспечения сервисов таких компаний, как Cisco, IBM, Cloudkick, Reddit, Digg, Rackspace и Twitter. В 2011 году крупнейший кластер серверов, обслуживающий единую БД Cassandra, насчитывает более 400 машин и содержит данные размером более 300 Тб.
Wikipedia[/pullquote]
В качестве решения для этого узла дата центра я предлагаю использовать Apache Cassandra. Данный продукт предлагает широкие возможности для построения географически распределенных высоко доступных и масштабируемых систем. Достаточно сказать, что такие всемирно известные сервисы как Netflix (согласно данным 2013 года – около 3.14 petabytes данных) и eBay (ежедневная нагрузка на 15 000 серверов — около 2 petabytes) уже используют это решение в своих системах.
Если мы посмотрим на тесты производительности, то мы увидим, что производительность Cassandra при увеличении количества узлов растет почти по экспоненте, что является, в том числе, экономическим обоснованием для ее применения. Помимо этого, Cassandra отличают:
- Эластичная масштабируемость
- Гибкая система хранения данных
- Поддержка равноправных систем (peer-to-peer architecture)
- Колоночное решение СУБД (column-oriented DBMS)
- Линейная (горизонтальная) высокая производительность
- Простое и надежное распределение данных
- Высокие показатели компрессии данных (до 80% в некоторых случаях)
Таким образом, основные компоненты нашей распределенной системы отвечают выдвинутым требованиям к системе в целом, а именно:
- Поддержка географически распределенных кластеров
- Обеспечение надежности (failover)
- Очень высокие показатели производительности
Практический опыт
Для иллюстрации эффективности применения вышеупомянутых решений и продуктов, я приведу данные из реального проекта, разработанного в соответствии с вышеописанной архитектурой. Система была разработана компанией «Аурига» в рамках проекта по созданию распределенной платежной внутриконтинентальной системы для быстрорастущей финансовой организации.
Перед разработчиками стояла задача реализации системы процессинга электронных платежей и управления платежными киосками в соответствии со следующими требованиями:
- Обработка до 10 000 запросов в секунду.
- Устойчивость к отключению не только отдельных серверов, но и целого дата центра.
- Возможность оперативной аналитики данных о состоянии киосков и о платежных транзакциях.
В результате исследования технологий для построения подобных масштабных систем, инженерами «Ауриги» был сделан вывод о том, что оптимальным решением будет система, базирующаяся на принципах распределенного кеширования оперативной памяти (in-memory distributed caching) с использованием NoSQL хранилища для поддержки запрошенной скорости операций. Показатели реализованной системы приведены в таблице ниже.
| Показатель | Значение |
| Количество дата центров | 3 |
| Количество узлов во всем кластере | 18 |
| Количество запросов в секунду | 15 000 |
| Количество обрабатываемых данных в день | 40 Тб |
Ввод в эксплуатацию данной системы происходил постепенно, с пошаговым вводом новых узлов в кластер и переводом отдельных категорий клиентов на новую технологию процессинга.
Таким образом, применение технологий распределенного кеширования оперативной памяти (in-memory distributed caching) и распределенной очереди сообщений на базе решений Ehcache, Apache Cassandra, Apache Kafka позволило нам построить устойчивую, доступную 24х7, географически-распределенную систему с высоким потенциалом к горизонтальному масштабированию.
