Высоконагруженные приложения финансовой сферы предъявляют жесткие требования ко всем компонентам и особенно к системе хранения данных.

Что делать, когда высокую нагрузку на MySQL нужно не просто хорошо держать, но держать без даунтайма. Как решать проблемы работы с двумя дата-центрами? Как отслеживать потенциально опасные ситуации и предотвращать простой?

Будем говорить о системном подходе к анализу ситуаций, планированию и управлению нагрузками, а также о методах минимизации даунтайма.

Этот доклад будет интересен инженерам, DBA и архитекторам, только планирующим инфраструктуру приложения или ищущим пути стабилизации существующей системы и увеличения ее производительности.

Стандартно разработчик при поиске проблем в RDBMs подозревает медленные запросы. А что, если дело не в медленных запросах, и на самом деле виноваты совсем другие запросы?

Расскажу о том, какого типа запросы какую нагрузку дают на базу данных и при этом не дают вашему приложению работать так, как вы хотите. Как backend-разработчику определять такие запросы и каким инструментом для этого пользоваться? Особенно, когда необходимо найти проблемы здесь и сейчас на работающей системе, когда дорога каждая минута, а работа приложения с базой данных тормозит.

Думаете, это невозможно? Возможно, и я расскажу, как мы это делаем изо дня в день и какими инструментами для этого пользуемся.

В своём докладе я расскажу про возможности ClickHouse, о которых обычно никто не подозревает. Некоторые из них были разработаны или найдены сообществом, и мы бы сами никогда не догадались, что систему можно использовать столь необычным образом. Рассмотрим, какие фичи нашли применение в продакшне, а о каких стоит ещё тщательно подумать.

Наверное, вы легко перечислите 10 или более web-акселераторов, и список их постоянно растет. Кроме разных функциональных возможностей, web-акселераторы значительно отличаются архитектурно, тем, как они взаимодействуют с операционной системой и реализуют те или иные HTTP-стандарты.

Понимание архитектурных различий и внутренностей конкретных прокси может помочь в выборе решения, наиболее подходящего к конкретному проекту, и разобраться со сложными задачами производительности и аномалиями обслуживания.

В этом докладе мы обсудим следующие вопросы на примере Nginx, Varnish, Apache Traffic Server, HAProxy, H2O и Tempesta FW:
* Как прокси управляют соединениями с клиентом и к бэкенд-серверам;
* Очереди HTTP-сообщений и фейловеринг соединений с бэкендами в стандартах HTTP и реализациях прокси, и как это влияет на безопасность;
* Работа и взаимодействие декодеров и парсеров HTTP/1.x, HTTP/2 и HTTP/3 (QUIC);
* HPACK и QPACK компрессии в HTTP/2 и HTTP/3 (QUIC), соответственно, и как они влияют на производительность;
* Что, как и в каких случаях можно кэшировать;
* Различные архитектуры кэширования: mmap(), файловый кэш и база данных;
* Оптимизации на уровне сетевого I/O и TLS, доступные в некоторых web-акселераторах и современных Linux-ядрах.

Ежедневная проблема крупной службы доставки: как развести 5000 заказов с помощью 200 водителей. Чтобы начать решать такую задачу, нужно за 2 минуты посчитать 300 млн маршрутов. Затем за 10 минут нужно найти оптимальное размещение этих заказов по водителям. Хорошая новость в том, что у вас есть вычислительный кластер. Плохая новость в том, что даже с одним водителем вариантов объехать все заказы 5000! — это число с 16327 знаками. Хорошая новость в том, что самое оптимальное решение искать не нужно, достаточно решить эту задачу лучше человека (логиста). Логист находит решение этой задачи на 1 млн рублей логистических расходов. Если вы найдёте решение на 10% лучше, то сэкономите клиенту 100 тыс. рублей. И это за 12+ минут вы обработали только один запрос.

В докладе будут рассмотрены быстрые алгоритмы поиска оптимального пути на графе и дискретной оптимизации на вычислительном кластере в приложении к логистической задаче, используемые в Яндекс.Маршрутизации.

Сбой даже, казалось бы, второстепенного компонента большой распределенной системы может потенциально привести к выходу из строя всего сервиса. На практике избежать сбоев нельзя, но можно сделать их максимально локальными. Другими словами, элементы архитектуры, которые мы проектируем, должны иметь минимально возможный бласт-радиус. Это задача архисложная, но выполнимая.

На примере EBS, базового продукта облака Amazon, я расскажу о том, как эволюционировала архитектура одного из ключевых компонентов этого сервиса. Основной фокус будет на деталях реализации микро-Ячеистой архитектуры. Вы прочитали правильно, не микро-Сервисы, но микро-Ячейки. Это подход, который позволяет принципиально уменьшить бласт-радиус, не жертвуя характеристиками целостности и доступности распределенных данных. Еще одна тайна архитектуры сервисов облака Amazon будет приоткрыта :)