Как разработчику обеспечить низкие задержки сложной системы при высоких нагрузках? Ведущий эксперт IT_ONE Максим Юнусов делится методологией для решения этой задачи, на примере реального проекта: модернизации Подсистемы обеспечения доступа к данным федеральной государственной информационной системы «Единая система межведомственного электронного взаимодействия» (ПОДД СМЭВ 4).

Постановка задачи

СМЭВ – это система, обеспечивающая электронное взаимодействие различных органов государственной власти. Предполагается, что в дальнейшем к ней могут быть подключены в качестве поставщиков и другие участники: коммерческие организации и частные лица. Доступ пользователей (потребителей данных) к информации поставщиков данных внутри системы осуществляется в формате Витрин данных – специализированных наборов структурированных данных. Соответственно, ПОДД СМЭВ – это компонент транспортной подсистемы СМЭВ, обеспечивающий доступ к данным, размещенным на Витринах данных. Предполагается, что ПОДД должна исполнять различные сложные запросы.

Итак, архитектурно ПОДД до трансформации – распределенная система из множества связанных между собой компонентов. Ее ядром является планировщик запросов на базе Apache Calcite, а основной протокол взаимодействия компонентов – журнал на базе Apache Pulsar, обеспечивающий гарантированность доставки. Механизм ограничения нагрузки (Rate Limiting) защищает систему от DoS-атак. Обработка запроса включает разбор запроса, производимый при каждом вызове. С целью обеспечить гарантированную доставку все сообщения сохраняются на диск.

До трансформации система поддерживала 1000 активных пользователей одновременно, время отклика 1 секунду (в 99% случаев) и мощность (пропускную способность) 5000 запросов в секунду. В соответствии с ТЗ заказчика, нам необходимо было получить следующие характеристики: 25000 активных пользователей, мощность 30000 запросов в секунду и время отклика не более 0,5 секунд на 99%.

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

Этап 1: сдвигаем «бутылочное горлышко»

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

Классический алгоритм действий для решения этой задачи – принцип центрирования. Находим «бутылочное горлышко» по симптомам: максимальная утилизация ресурса, максимальная потребность в ресурсе (время пребывания в ресурсе за один запрос), максимальная очередь к ресурсу. В нашем случае оно было очевидным: Apache Calcite. Обработчик запросов и тормозил систему больше всего. Для уменьшения потребности в этом ресурсе мы последовательно рассмотрели несколько тактик.

Полный текст на сайте Tproger