Что такое высоконагруженные системы
MSA и не только: как мы создаем высоконагруженные сервисы для банка
Проектирование высоконагруженных сервисов уже не является таинственным мастерством, которым владеют лишь просвещенные сэнсеи. Сегодня для этого существуют вполне устоявшиеся практики, которые комбинируются и видоизменяются в зависимости от особенностей компании и ее бизнеса. Мы хотим рассказать о наших лучших методиках и инструментах создания высоконагруженных сервисов.
Сразу оговоримся, что речь пойдет о заказной разработке. Как завещал нам здравый смысл, проектирование мы начинаем с постановки бизнес-задач. И в том числе определяем, будет ли система высоконагруженной. Понятно, что со временем она будет меняться (например, изменится профиль нагрузки), поэтому при описании бизнес-логики мы закладываем вероятные пути развития там, где это возможно. Скажем, если это какой-то сервис по обслуживанию клиентов, то можно спрогнозировать изменение размера аудитории. Иногда бывает сразу понятно, как система будет меняться со временем, а некоторые контрольные точки трудно поддаются прогнозу.
На начальном этапе мы можем посчитать объемы данных, которые нам нужны для хранения, посчитать начальную нагрузку на наш абстрактный сервис и скорость ее роста. Также можно классифицировать данные по виду работы с ними: хранение, запись или чтение, и в зависимости от этого оптимизировать процессы.
У нас есть KPI по работе системы, на основании которых определяется допустимая степень ее деградации. Для большинства систем критичным является время отклика. В некоторых случаях оно может достигать нескольких секунд, а в других счёт идёт на миллисекунды. Также на этом этапе определяется степень доступности системы. Как правило, мы разрабатываем высокодоступные системы или системы непрерывного режима работы: с уровнем доступности от 99,9% до 99,999%.
Определившись с бизнес-логикой, допустимыми объемами данных и поведением системы, начинаем строить диаграммы движения данных. Это необходимо для того, чтобы понять, какой шаблон проектирования лучше всего выбрать. И после построения диаграмм приступаем к самому проектированию.
Микросервисы — buzzword нашего времени
В последнее время при создании высоконагруженных систем мы предпочитаем сервис-ориентированную архитектуру. В частности, столь модную в последние годы микросервисную: берем функциональность системы и разбиваем её на небольшие кусочки — сервисы, каждый из которых выполняет какую-то маленькую задачу. Сервисов может быть очень много, сотни или тысячи. Такая архитектура облегчает поддержку системы, а вносимые в отдельные сервисы изменения гораздо меньше влияют на систему в целом.
Также ещё одна важная плюшка микросервисной архитектуры — хорошая масштабируемость.
Но кроме весомых достоинств у микросервисной архитектуры есть и существенный недостаток: не всегда возможно разделить бизнес-логику на достаточно маленькие функциональные кусочки.
Задача эта сложная, и, как правило, решается на этапе проектирования. Обратной стороной медали является межсервисное взаимодействие. Необходимо следить за тем, чтобы накладные расходы на обмен сообщениями были не слишком большими. Достигается это в основном за счёт выбора эффективных методов сериализации/десериализации данных (об этом чуть ниже), перемещения взаимодействующих сервисов «поближе» друг к другу или объединения их в один микросервис. Зато если удается успешно разделить логику на мелкие задачи, то к вашим услугам будут все преимущества микросервисной архитектуры.
Микросервисная архитектура позволяет разместить сервисы на большом количестве узлов и заложить необходимое резервирование на случай выхода каких-то узлов из строя (тьфу-тьфу-тьфу). Схема резервирования во многом зависит от исходных задач. Где-то нельзя допускать пауз и требуется моментальное восстановление сервиса — в этом случае используется схема Active/Active, когда балансировщик мгновенно отключает вышедший из строя узел. В других случаях допустим небольшой простой на время восстановления сервиса, и тогда используется схема Active/Standby, когда резервный узел становится доступен не сразу, а через небольшой промежуток времени, пока сервис автоматически переносится на резервный узел.
Очевидными примерами необходимости использования вариантов схем Active/Active могут служить сервисы удаленного банковского обслуживания – интернет- и мобильный банкинг.
Если говорить точнее, то новые системы в банке проектируются как набор микросервисов на платформе Spring Boot. Основные причины выбора Spring Framework были ее широкое распространенность на рынке ИТ-услуг, а также относительная простота ее использования при разработке сервисов и микросервисов.
Для взаимодействия с пользователем, как правило, используется веб-интерфейс, разработанный с использованием React или Angular, взаимодействующий с серверными компонентами через Rest API.
Отдельная тема — взаимодействие компонентов MSA между собой, а также их интеграция с существующей ИТ-экосистемой. Наряду с традиционными подходами, такими как очереди MQ, мы активно внедряем новые паттерны взаимодействия на основе слабой связанности и платформы Apache Kafka.
Языки и фреймворки
Сейчас достаточно много технологий, позволяющих строить высоконагруженные системы с небольшим временем отклика. Но их состав постоянно меняется: постоянно приходит что-то из мира Open Source, разрабатываются новые внутренние проекты, часть из которых тоже переходят в стан открытого исходного кода. Однако мы предпочитаем проверенные решения известных вендоров. Наша задача — наращивать компетенции в использовании подобного рода систем.
Трудно представить себе высоконагруженную систему, не использующую кэширование данных. Хотя здесь на рынке большой выбор инструментов, обычно мы придерживаемся проверенной «классики» — Memcached и Redis. Но в последнее время стали поглядывать в сторону Apache Ignite, на некоторых проектах он хорошо зарекомендовал себя в роли распределённого кэша.
Что касается выбора языков программирования, то многое зависит от задачи. Как правило, выбор падает на Java — тут и большое количество фреймворков, позволяющих быстро и качественно реализовывать необходимую функциональность, и большое количество настроек самой JVM, позволяющих добиться необходимых показателей производительности.
При проектировании MSA мы тоже придерживаемся стека технологий Java. Помимо унификации это позволяет нам легко интегрироваться с уже работающими в банке приложениями через традиционные механизмы интеграции — очереди MQ, веб-сервисы, многочисленные API на основе Java. Также это позволяет использовать имеющийся на данной платформе развитый инструментарий разработки и управления микросервисами.
Немаловажно и то, что на российском рынке уже довольно много специалистов по разработке MSA-приложений с использованием технологического стека на основе JVM.
Хранение данных
Что касается хранения данных, то в первую очередь при проектировании возникает вопрос: какую модель данных должна использовать СУБД — реляционную или какую-то другую? От выбора зависят дальнейшие методики повышения эффективности обработки запросов к базе данных, ведь высоконагруженные сервисы априори должны обладать маленьким временем отклика. Если мы говорим о реляционных СУБД, то их использование в высоконагруженных проектах требует решать задачи повышения эффективности запросов. Начинается всё с анализа плана запросов.
Как правило, по его результатам мы меняем сами запросы, добавляем индексы. Можно применять партиционирование к таблицам, сокращая объемы данных при выборках с помощью ограничения их рамками одной или нескольких партиций. Также часто приходится использовать денормализацию данных, внося некую избыточность — так можно повысить эффективность запросов.
А с нереляционными СУБД приходится использовать практически индивидуальные подходы в зависимости от конкретного продукта, от бизнес-сценариев. Из общих подходов можно выделить разве что отложенную обработку трудоёмких вычислений.
Безусловно, всё зависит от конкретной задачи, но если есть возможность, то мы используем Oracle, потому что написание эффективных запросов и настройка занимает у наших инженеров меньше времени. Также в последнее время мы часто смотрим в сторону Apache Ignite.
Масштабирование
Как говорилось выше, мы не всегда можем предсказать, какую нагрузку будет испытывать создаваемая система через полгода или год. И если не заложить возможность масштабирования, то система очень быстро перестанет справляться с растущей нагрузкой. В зависимости от конкретного проекта применяется вертикальное или горизонтальное масштабирование. Вертикальное — увеличение производительности отдельных компонентов за счёт добавления ресурсов в рамках одного компонента/узла; горизонтальное — увеличение количества компонентов/узлов, чтобы распределить по ним нагрузку.
Масштабировать сервис или компонент гораздо проще, если он использует stateless-парадигму, то есть не хранит в себе контекст между запросами. В таком случае мы можем запросто развернуть в системе несколько копий этого компонента или сервиса, сбалансировав нагрузку между ними. В случае stateful-парадигмы нужно позаботиться о том, чтобы балансировка учитывала наличие состояний у компонентов/сервисов.
Физический мир
Тесты, тесты, и ещё раз тесты
Запуск высоконагруженной системы немыслим без нагрузочного тестирования. Под нагрузочным тестированием понимается проверка достижения определённых KPI на входе. Из нашего опыта, большая длительность обработки запросов чаще всего связана с неэффективностью алгоритма. Также росту производительности способствует кэширование данных при большом количестве однотипных запросов.
Тесты позволяют выявить узкие места, которые мы могли упустить из виду при проектировании. Веб-сервис, реализованный в рамках одного из проектов, при нагрузочном тестировании работал с низкой производительностью, несмотря на свою простоту. Профилирование показало, что большую часть времени занимала сериализация-десериализация данных, то есть в основном мы перегоняли структуры данных в битовое представление и обратно. Решение нашлось достаточно быстро — характер данных был таков, что они изменялись крайне редко. Мы смогли реализовать предсериализацию данных (заранее подготовив сериализованное представление), и сильно сократили время отклика.
Оптимизация сериализации для внешнего API (предсериализация)
Наряду с нагрузочным тестированием, в рамках которого мы проверяем систему на соответствие предъявляемым требованиям, мы также проводим нагрузочные испытания. Цель таких тестов — узнать предельную возможную нагрузку, которую способна выдерживать система.
Мониторинг
Метрики выполняют роль датчиков, ими густо усыпана любая серьезная система, в особенности высоконагруженная. Без метрик любая программа превращается в черный ящик со входами и выходами, непонятно как работающая внутри. При проектировании в архитектуру закладываются измерители, генерирующие информацию для системы мониторинга.
В некоторых проектах для визуализации активности системы и ее мониторинга использовался ELK (Elastick Search Kibana). У этого фреймворка гибкий интерфейс, позволяющий просто и быстро настроить необходимую форму отчетности.
Мониторинг Kibana
Высоконагруженные системы: решение основных проблем
Сегодня я хочу рассказать о некоторых решениях проблем, которые возникают во время использования высоконагруженных систем. Все, о чем пойдет речь в этом материале, проверено на собственном опыте: я – Social Games Server Team Lead в компании Plarium, которая занимается разработкой социальных, мобильных, браузерных игр.
Для начала немного статистики. Plarium занимается разработкой игр с 2009 года. На данный момент наши проекты запущены во всех наиболее популярных социальных сетях («Вконтакте», «Мой мир», «Одноклассники», Facebook), несколько игр интегрированы в крупные игровые порталы: games.mail.ru, Kabam. Отдельно существует браузерная и мобильная (iOS) версии стратегии «Правила войны». В базах числятся более 80 миллионов пользователей (5 игр, локализация на 7 языках, 3 миллиона уникальных игроков в день), в итоге все наши серверы получают в среднем около 6500 запросов в секунду и 561 миллион запросов в сутки.
Учитывая специфику нашей работы, необходимо не только обеспечить стабильное функционирование систем, но и гарантировать, что они смогут выдержать большой скачок нагрузки. Увы, многие популярные подходы и технологии не выдерживают проверку высокой нагрузкой и быстро становятся узким местом в системе. Поэтому, проанализировав множество проблем, мы нашли оптимальные для нас (как мне кажется) пути их решения. Я расскажу, какие технологии мы выбрали, от каких отказались, и объясню, почему.
NoSQL vs. Relational
В этом сражении чистый NoSQL показал себя слабым бойцом: существовавшие на тот момент решения не поддерживали вменяемую консистентность данных и не обладали достаточной устойчивостью к падениям, что давало о себе знать в процессе работы. Хотя в итоге выбор пал на реляционные СУБД, которые позволяли использовать транзакционность в необходимых местах, в целом в качестве основного подхода используется NoSQL. В частности, таблицы зачастую имеют очень простую структуру типа ключ-значение, где данные представлены в виде JSON, который хранится в упакованном виде в колонке BLOB. В результате схема остается простой и стабильной, при этом структура поля данных может легко расширяться и изменяться. Как ни странно, это дает очень хороший результат – в нашем решении мы объединили преимущества обоих миров.
Учитывая тот факт, что чистый ADO.NET имеет минимальный оверхед, а все запросы созданы вручную, знакомы и греют душу, он отправляет любые ORM в глубокий нокаут. А всё потому, что объектно-реляционное отображение имеет в нашем случае ряд минусов, таких как низкая производительность и низкий контроль запросов (или его отсутствие). При использовании многих решений ORM приходится долго и часто бороться с библиотекой и терять главное – скорость. А уж если речь заходит о хитром флаге для правильной обработки тайм-аутов клиентской библиотеки или о чем-то аналогичном, то попытки представить установку такого флага с использованием ORM окончательно расстраивают.
Distributed transactions vs. Own Eventual Consistency
Основная задача транзакций – обеспечить согласованность данных после завершения операции. Изменения либо успешно сохраняются, либо полностью откатываются, если что-то пошло не так. И если в случае одной базы мы были рады использовать этот, без сомнения, важный механизм, то распределенные транзакции при высоких нагрузках показали себя не с лучшей стороны. Результат использования – увеличенное время ожидания, усложнение логики (здесь вспоминаем еще про необходимость обновления кэшей в памяти экземпляров приложений, возможность возникновения мертвых блокировок, слабую устойчивость к физическим сбоям).
В итоге мы разработали свой вариант механизма для обеспечения Eventual Consistency, построенный на очередях сообщений. В результате мы получили: масштабируемость, устойчивость к сбоям, подходящее время наступления согласованности, отсутствие мертвых блокировок.
SOAP, WCF, etc. vs. JSON over HTTP
MVC.NET, Spring.NET vs. Naked ASP.NET
Опираясь на опыт работы, могу сказать, что MVC.NET, Spring.NET и им подобные фреймворки создают лишние промежуточные конструкции, которые мешают выжимать максимальную производительность. Наше решение построено на самых базовых возможностях, предоставляемых ASP.NET. Фактически точкой входа являются несколько обычных хендлеров. Мы не используем ни одного стандартного модуля, в приложении нет ни одной активной сессии ASP.NET. Всё понятно и просто.
Немного о велосипедах
Если ни один из существующих методов решения проблемы не подходит, приходится становиться немного изобретателем и заново искать ответы на вопросы. И пусть иногда ты изобретаешь велосипед, если этот велосипед критически важен для проекта – оно того стоит.
JSON сериализация
Чуть больше трети используемого нами времени CPU тратится на сериализацию/десериализацию больших объемов данных в формате JSON, поэтому вопрос эффективности данной задачи является очень важным в контексте производительности системы в целом.
Изначально в работе мы использовали Newtonsoft JSON.NET, но в определенный момент пришли к выводу, что его скорости недостаточно, и мы можем реализовать нужное нам подможество фич более быстрым способом, без необходимости поддержки слишком большого количества вариантов десериализации и «замечательных» фич вроде валидации схем JSON, десериализации в JObject и т.д.
Поэтому мы самостоятельно написали сериализацию с учетом специфики своих данных. При этом на тестах получившееся решение оказалось в 10 раз быстрее JSON.Net и в 3 раза быстрее fastJSON.
Критически важной для нас была совместимость с уже существующими данными, сериализованными с помощью Newtonsoft. Чтобы убедиться в совместимости, перед включением нашей сериализации в продакшн мы провели тестирование на нескольких крупных базах: вычитывали данные в формате JSON, десериализовали с помощью нашей библиотеки, снова выполняли сериализацию и проверяли исходный и конечный JSON на равенство.
Из-за нашего подхода к организации данных мы получили отрицательный эффект в виде слишком большого размера кучи больших объектов (large object heap). Для сравнения, ее размер в среднем составлял порядка 8 гигабайт против 400—500 мегабайт в объектах второго поколения. В итоге эту проблему решили путем разбивки больших блоков данных на блоки меньшего размера с использованием пула ранее выделенных блоков. Благодаря такой схеме куча больших объектов значительно уменьшилась, сборки мусора стали происходить реже и легче. Пользователи довольны, а это главное.
Работая с памятью, мы используем несколько кэшей разных размеров с различными политиками устаревания и обновления, при этом конструкция некоторых кэшей предельно проста, без всяческих излишеств. В результате показатель эффективности всех кэшей – не ниже 90—95%.
Опробовав Memcached, мы решили отложить его на будущее, т.к. пока что в нем нет необходимости. В целом результаты были неплохие, но общий выигрыш по производительности не превысил стоимость дополнительной сериализации/десериализации при помещении данных в кэш.
• Профилировщик
Так как привычные профилировщики значительно замедляют скорость работы приложения при подключении к нему, фактически делая невозможным профилировку достаточно нагруженных приложений, мы используем свою систему счетчиков производительности:
На этом тестовом примере видно, что мы оборачиваем основные операции в счетчики с именами. Статистика накапливается в памяти и собирается с серверов вместе с другой полезной информацией. Поддерживаются иерархии счетчиков для анализа цепочек вызовов. В результате можно получить подобный отчет:
Среди положительных сторон:
— счетчики всегда включены;
— минимальные издержки (менее 0,5% ресурса используемого CPU);
— простой и гибкий подход к указанию профилируемых участков;
— автоматическая генерация счетчиков для точек входа (сетевых запросов, методов);
— возможность просмотра и агрегации по принципу parent—child;
— можно оценивать не только real-time данные, но и сохранять значения измерений счетчиков по времени с возможностью дальнейшего просмотра и анализа.
• Логирование
Зачастую это единственный способ диагностики ошибок. В работе мы используем два формата: human readable и JSON, при этом пишем всё, что можно писать, пока хватает места на диске. Собираем логи с серверов и используем для анализа. Всё сделано на базе log4net, поэтому не используется ничего лишнего, решения максимально просты.
• Администрирование
В дополнение к богатому графическому веб-интерфейсу нашей админки мы разработали веб-консоль, в которую можно добавлять команды прямо на игровом сервере, при этом не внося изменения в админку. Также с помощью консоли можно очень просто и быстро добавить новую команду для диагностики, получения технических данных в режиме онлайн или возможности подстройки системы без перезагрузки.
• Развертывание
С увеличением количества серверов выливать что-либо вручную стало невозможно. Поэтому всего за неделю работы одного программиста мы разработали простейшую систему для автоматизированного обновления серверов. Скрипты были написаны на C#, что позволяло достаточно гибко модифицировать и поддерживать логику развертывания. В результате мы получили очень надежный и простой инструмент, который в критических ситуациях позволяет обновить все продакшн-серверы (порядка 50) за несколько минут.
Для того чтобы добиться скорости при высокой нагрузке на серверы, необходимо использовать более простой и тонкий стек технологий, все инструменты должны быть знакомы и предсказуемы. Конструкции должны быть одновременно простыми, достаточными для решения текущих проблем и иметь запас прочности. Оптимально использовать горизонтальное масштабирование, производить кэш-контроль производительности. Логирование и мониторинг состояния системы – must have для жизнеобеспечения любого серьезного проекта. А система развертывания значительно упростит жизнь, поможет сэкономить нервы и время.
ITSource
Высоконагруженные системы: введение в highload
Высоконагруженные системы (highload) стали трендом еще в 2012-ом году. По крайней мере, мы занялись ими именно тогда=) Но вот незадача – четкого определения термина нет до сих пор. Где проходят границы высоких нагрузок? 10 запросов с секунду – это уже хайлоад или еще нет? А 100, 1000? Мы вас удивим, но дело здесь совсем не в цифрах.
Высокая нагрузка – это сколько?
Для начала нужно понять одну простую аксиому: высокие нагрузки – понятие относительное. Их нельзя измерить количеством запросов, которые поступают на сервер, или скоростью работы веб-сайта. Ведь некого «среднего» количества запросов, как и «среднего» сайта, не существует. Один веб-ресурс сможет нормально обрабатывать тысячу запросов в секунду, а другой обвалится на сотом коннекте. Так что дело тут вовсе не в количественных показателях.
Мы собрали самые популярные определения highload от IT-специалистов и просто разбиравшихся в этой теме пользователей:
Хайлоад – это когда IT-система перестает справляться с текущей нагрузкой.
Хайлоад – это когда традиционных подходов к работе IT-инфраструктуры уже не хватает.
Хайлоад – это когда одного сервера становится мало для обслуживания клиентов.
Хайлоад – это когда железо не справляется с выросшими нагрузками.
Хайлоад – это когда возникающие проблемы нельзя решить имеющимися средствами.
Хайлоад – это когда инфраструктуру нужно срочно масштабировать.
Последнее определение позволяет посмотреть на определение highload под новым углом:
Это система, которая постоянно масштабируется и ресурсов которой хватает для работы с текущими нагрузками.
Таким образом, из описания состояния мы переходим к описанию качеств системы, которая растет вместе с потребностями бизнеса.
5 качеств высоконагруженной системы
Это система с огромной аудиторией
Если говорить о веб-приложениях (а именно их большинство специалистов относят к категории highload), то это тысячи, а иногда и сотни тысяч человек. Конечно, конкретную цифру назвать нельзя. Но понятно, что интернет-магазин, обрабатывающий 10 заявок в день, хайлоадом не назовешь. А вот Facebook, Amazon, Flickr, MySpace или Youtube – да, конечно.
Это распределенная система
Если приложению приходится обрабатывать огромные объемы данных, которые еще и постоянно растут, одного сервера не хватит. Самые крупные хайлоады (например, Google или тот же Facebook) работают на сотнях серверов.
Но огромное количество машин обусловлено не только высокими нагрузками. Точнее, не только большим количеством запросов, которые приходится обрабатывать в режиме нон-стоп. При таки темпах сервера быстро выходят из строя, поэтому чем их больше, тем выше вероятность, что система быстро восстановится после сбоя.
Это система с позитивной динамикой
Если интернет-предложение представляет ценность для пользователей, его аудитория растет. Поэтому хайлоад – это не просто система с большим количеством пользователей, а система, которая интенсивно наращивает аудиторию.
Это интерактивная система
Если человек вводит поисковый запрос в Google, загружает ролик на YouTube или оформляет покупку на eBay, он ожидает, что мгновенно получит результат. Если система будет долго отвечать, скорее всего, он найдет себе другое занятие. Поэтому мгновенный отклик – отличительная и очень важная черта хайлоад-системы.
Это высокоресурсная система
Этот пункт напрямую связан с предыдущим. Чтобы давать мгновенный отклик, системе проходится задействовать много ресурсов – CPU, оперативную память, место на диске и т.д. А для этого нужно, чтобы ресурсы: а) были свободными и б) были в достаточном количестве (лучше даже с запасом).
Здесь мы подходим к парадоксу высоконагруженных систем: чем стремительнее они растут, тем жестче приходится контролировать ресурсы. Когда приложение наращивает аудиторию, закономерно растет и количество запросов. А с ними – объемы ресурсов, которые нужно тратить для поддержания интерактивности.
То есть, хайлоад – это система, которую нужно постоянно масштабировать. Настроить ее работу таким образом довольно сложно, но с точки зрения бизнеса оно того стоит.