Открытый вебинар
Тестирование отказоустойчивости

Производительность индексов. 1) Сгенерировать любым способ 1,000,000 анкет. Имена и Фамилии должны быть реальными, чтобы учитывать селективность индекса. Так же можно воспользовать [уже готовым списком](https://raw.githubusercontent.com/OtusTeam/highload/master/homework/people.v2.csv) как основой.
2) Реализовать функционал поиска анкет по префиксу имени и фамилии (одновременно) в вашей социальной сети (реализовать метод [/user/search из спецификации](https://github.com/OtusTeam/highload/blob/master/homework/openapi.json#L165)) (запрос в форме firstName LIKE ? and secondName LIKE ?). Сортировать вывод по id анкеты.
3) Провести нагрузочные тесты этого метода. Поиграть с количеством одновременных запросов. 1/10/100/1000.
4) Построить графики и сохранить их в отчет
5) Сделать подходящий индекс.
6) Повторить пункт 3 и 4.
7) В качестве результата предоставить отчет в котором должны быть:
- графики latency до индекса;
- графики throughput до индекса;
- графики latency после индекса;
- графики throughput после индекса;
- запрос добавления индекса;
- explain запросов после индекса;
- объяснение почему индекс именно такой;


ДЗ принимается в виде отчета по выполненной работе.

Репликация. Инструкция к ДЗ доступна также по [ссылке](https://otusmetodist.yonote.ru/share/269b787b-4c2a-461c-8049-e4b693b841cd/doc/homework-3-replikaciya-JnhvFGijD6)

-----

1) Выбираем 2 запроса на чтение ([/user/get/{id}](https://github.com/OtusTeam/highload/blob/master/homework/openapi.json#L127) и [/user/search](https://github.com/OtusTeam/highload/blob/master/homework/openapi.json#L167) из [спецификации](https://github.com/OtusTeam/highload/blob/master/homework/openapi.json)).
Составить план нагрузочного тестирования, который шлет запросы на эти api.

2) Создаем нагрузку на чтение с помощью составленного на предыдущем шаге плана, делаем замеры.

3) Настроить 2 слейва и 1 мастер. Включить потоковую репликацию.

4) Добавить в проект replicated datasource:
Можно рассмотреть несколько несколько вариантов:
- Использование [MaxScale](https://github.com/mariadb-corporation/MaxScale) и [MySql Replication JDBC Driver](http://dev.mysql.com/doc/connector-j/en/connector-j-master-slave-replication-connection.html)
- Использование Database Proxy server like [MySQL Proxy](http://dev.mysql.com/doc/mysql-proxy/en/)
- Использование Replication DataSource: [kwon37xi/replication-datasource-boot](https://github.com/kwon37xi/replication-datasource-boot).

Рекомендуется последний вариант: написать `ReplicationRoutingDataSource`, который выбирает использовать master или slave в зависимости от типа транзакции.

Данное решение работает с [TransactionSynchronizationManager](http://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/support/TransactionSynchronizationManager.html).

При использовании [Spring framework](http://spring.io/) достаточно установить `@Transactional(readOnly = true|false)`

Переносим запросы на чтение (transaction == read only) на чтение со слейва.

5) Создаем нагрузку на чтение с помощью составленного на предыдущем шаге плана, делаем замеры. Добавить сравнение результатов в отчет.

8) Настроить кворумную синхронную репликацию.
(Опционально) воспользоваться одним из кластерных расширения Postgres (например patroni).
9) Создать нагрузку на запись в любую тестовую таблицу. На стороне, которой нагружаем считать, сколько строк мы успешно записали.
Например, API.
Пример: [Дашборды для Grafana](https://grafana.com/grafana/dashboards/893)

10) Убиваем одну из реплик (`kill -9`, `docker stop`)

11) Заканчиваем нагрузку на запись.

12) Выбираем самый свежий слейв. Промоутим его до мастера. Переключаем на него второй слейв.
13) Проверяем, есть ли потери транзакций.


**Форма сдачи ДЗ**
- Предоставить ссылку на исходный код (github, gitlab, etc)
- Предоставить докеризированное приложение, которое можно запустить при помощи docker-compose (может лежать рядом с исходным кодом) ИЛИ развернутое приложение, доступное извне ИЛИ инструкция по запуску
- Предоставить отчет в свободной форме о проделанное работе

Лента постов от друзей. **1) Реализовать API (синхронный rest)**
- (опционально) Добавление/удаление друга (методы */friend/add*, */friend/delete* из [спецификации](https://github.com/OtusTeam/highload/blob/master/homework/openapi.json))
- (опционально) CRUD для постов пользователей (методы */post/create*, */post/update*, */post/delete*, */post/get* из [спецификации](https://github.com/OtusTeam/highload/blob/master/homework/openapi.json))
- Лента постов друзей (метод */post/feed* из [спецификации](https://github.com/OtusTeam/highload/blob/master/homework/openapi.json))

----------
**2) Разработать структуру БД для хранения постов пользователей.**

Наполнить БД тестовыми данными.

ссылка на сгенерированные тексты постов: https://github.com/OtusTeam/highload/blob/master/homework/posts.txt
(опционально, можно сгенерировать самостоятельно)

----------
**3) Реализовать кэширование ленты.**

Требования:
- Лента постов друзей формируется на уровне кешей
- В ленте держать последние 1000 обновлений друзей
- Лента должна кешироваться

----------

**
Дополнительные материалы**

Инструкция к ДЗ также доступна по [ссылке](https://otusmetodist.yonote.ru/share/94ee610e-2e76-4e80-93fc-ad74fe04e8d4/doc/homework-4-lenta-postov-ot-druzej-taoWO1XJvF).

----------
**
Форма сдачи ДЗ**
1. Предоставить ссылку на исходный код (github, gitlab, etc)
2. Предоставить докеризированное приложение, которое можно запустить при помощи docker-compose (может лежать рядом с исходным кодом) ИЛИ развернутое приложение, доступное извне

Масштабируемая подсистема диалогов. **Реализовать функционал:**
- Отправка сообщения пользователю (метод ```/dialog/{user_id}/send``` из [спецификации](https://github.com/OtusTeam/highload/blob/master/homework/openapi.json))
- Получение диалога между двумя пользователями (метод ```/dialog/{user_id}/list``` из [спецификации](https://github.com/OtusTeam/highload/blob/master/homework/openapi.json))
----------
**
Требования**
- Обеспечить горизонтальное масштабирование хранилищ на запись с помощью шардинга.
- Предусмотреть:
- Возможность решардинга
- (опционально) “Эффект Леди Гаги” (один пользователь пишет сильно больше среднего)
- Наиболее эффективную схему.
----------

**Форма сдачи ДЗ**
- Предоставить ссылку на исходный код (github, gitlab, etc)
- Предоставить докеризированное приложение, которое можно запустить при помощи docker-compose (может лежать рядом с исходным кодом) ИЛИ развернутое приложение, доступное извне ИЛИ инструкция по запуску

Онлайн обновление ленты новостей. Инструкция к ДЗ доступна также по [ссылке](https://otusmetodist.yonote.ru/share/c459499e-8afb-430f-b86b-d3b08f3d2f2b/doc/homework-6-onlajn-obnovlenie-lenty-novostej-LmD0upnUDk)

---------

**1) Реализовать REST API:**
- Создание поста (метод ```/post/create``` из [спецификации](https://github.com/OtusTeam/highload/blob/master/homework/openapi.json))

**2) Реализовать асинхронное API с websocket:**
- https://github.com/OtusTeam/highload/blob/master/homework/asyncapi.json (example.zip в материалах занятия)
- Реализовать отправку сообщений в канал ```/post/feed/posted``` через websocket согласно [спецификации](https://github.com/OtusTeam/highload/blob/master/homework/asyncapi.json)
- **Требования**: при добавлении нового поста друга подписчику websocket'а должно приходить событие о новом посте, тем самым обеспечивая обновление ленты в реальном времени

**4) Реализовать отложенную материализацию ленты:**
Требования
- Формирование лент работает через очередь (отложено)
- при реализации обязательно обеспечить отправку только целевым пользователям это событие (можно применить Routing Key из RabbitMQ)

**5) (Опционально) Формирование ленты производить через постановку задачи в очередь на часть друзей, чтобы избежать "эффекта Леди Гаги"/celebrity** (один пользователь пишет сильно больше среднего)

----------
**Что такое "эффект Леди Гаги"?**
Когда один пользователь пишет сильно больше среднего (поэтому такое название). На примере twitter, есть селебрити, посты которых читает огромное кол-во человек. можно взять подход twitter - пользователи делятся на селебрити и обычных. Для селебрити они просто добавляют посты, для обычных - добавляют посты и обновляют ленту

----------

**Форма сдачи ДЗ**
- Предоставить ссылку на исходный код (github, gitlab, etc)
- Предоставить докеризированное приложение, которое можно запустить при помощи docker-compose (может лежать рядом с исходным кодом) ИЛИ развернутое приложение, доступное извне ИЛИ инструкция по запуску

Применение In-Memory СУБД. **Инструкция:**

Для выполнения ДЗ понадобится In-Memory СУБД с поддержкой функциональности application server (возможность выполнять UDF над данными) - Tarantool. Redis, Apache Ignite, Hazelcast, …

1) Выбрать один из модулей приложения: например диалоги

2) Провести нагрузочное тестирование этого модуля для дальнейшего сравнения

3) Вынести хранение данных из SQL БД в In-Memory СУБД. Перенести логику из модуля в UDF в In-Memory СУБД.
Например: для общения с tarantool'ом использовать процедуры (функции lua), не использовать прямые запросы в space'ы при помощи драйвера.

4) Провести нагрузочное тестирование снова

5) Сравнить результаты нагрузочного тестирования

----------

**Форма сдачи ДЗ**
- Предоставить ссылку на исходный код (github, gitlab, etc)
- Предоставить докеризированное приложение, которое можно запустить при помощи docker-compose (может лежать рядом с исходным кодом) ИЛИ развернутое приложение, доступное извне ИЛИ инструкция по запуску

Разделение монолита на сервисы. **Реализовать функционал:**
- Вынести систему диалогов в отдельный сервис.
----------

**Требования**
- Взаимодействия монолитного сервиса и сервиса чатов реализовать на REST API или gRPC.
- Организовать сквозное логирование запросов (x-request-id).
- Предусмотреть то, что не все клиенты обновляют приложение быстро и кто-то может ходить через старое API (сохранение обратной совместимости).
----------

**Форма сдачи ДЗ**
- Предоставить ссылку на исходный код (github, gitlab, etc)
- Предоставить докеризированное приложение, которое можно запустить при помощи docker-compose (может лежать рядом с исходным кодом) ИЛИ развернутое приложение, доступное извне ИЛИ инструкция по запуску

Отказоустойчивость приложений. - Поднять несколько слейвов PostgreSQL.
- Реализовать соединение со слейвами PostgreSQL через haproxy.
- Поднять несколько приложений и обеспечить их балансировку через nginx.
- Воспроизвести нагрузку.
- Под нагрузкой с помощью "kill -9" отключить один из слейвов PostgreSQL. Убедится, что система осталась работоспособной.
- Под нагрузкой с помощью "kill -9" отключить один из инстансов бэкенда. Убедится, что система осталась работоспособной.
----------
**
Форма сдачи ДЗ**

ДЗ принимается в виде отчета по выполненным пунктам.

Сервис счетчиков. **Реализовать функционал:**

**Вариант 1**
1. Разработайте сервис счетчиков.
2. Учтите то, что на этот сервис будет большая нагрузка, особенно на чтение.
3. Продумайте, как обеспечить консистентность между счетчиком и реальным числом непрочитанных сообщений. Например, используйте паттерн SAGA.
4. Внедрите сервис для отображения счетчиков.

**Вариант 2**
Разработайте и внедрите функционал, в котором будет необходимость применения паттерна SAGA, этот функционал должны быть потенциально нагруженным.

---------
**Требования**
- обеспечение консистентности (SAGA в приоритете)
----------

**Форма сдачи ДЗ**
- Предоставить ссылку на исходный код (github, gitlab, etc)
- Предоставить докеризированное приложение, которое можно запустить при помощи docker-compose (может лежать рядом с исходным кодом) ИЛИ развернутое приложение, доступное извне ИЛИ инструкция по запуску
- Предоставить отчет об архитектуре (схема, словесное описание)

Мониторинг. **Необходимо:**
- развернуть [zabbix](https://www.zabbix.com/);
- развернуть [prometheus](https://prometheus.io/);
- развернуть [grafana](https://grafana.com/);
- начать писать в [prometheus](https://prometheus.io/) бизнес-метрики сервиса чатов по принципу RED;
- начать писать в [zabbix](https://www.zabbix.com/) технические метрики сервера с сервисом чатов;
- организовать дашборд в [grafana](https://grafana.com/);

**
Форма сдачи ДЗ**

Отчет со скриншотами

Построение архитектуры системы. Создать документ описывающий архитектуру выбранной системы (в свободной форме, draw.io, arc42, c4).
- В начале проекта необходимо с наставником согласовать требования.
- Итогом будет защита архитектуры в очном или заочном формате.