# HighLoad Siberia++ 2019
## Доклады на которых я был
### Автоматизация управления Clickhouse-кластерами в Kubernetes
#### Конспект
Рассказ о собственной разработке ClickHouse оператор, для управления Clickhouse-кластерами в Kubernetes.
Altinity ClickHouse operator for Kubernetes.
ClickHouse - столбцовая СУБД для OLAP.
#### Понравилось
#### Не понравилось
Похоже на рекламу собственного решения.
#### А еще
Поскольку я не знаком с Kubernetes, то сложно оценить полезность предложенного ClickHouse оператор.
### Как создать высоконагруженную систему отправки уведомлений по событиям
#### Конспект
Apache Kafka.
#### Понравилось
#### Не понравилось
#### А еще
### Реализация геораспределенной персистентной очереди сообщений на примере Yandex Message Queue
#### Конспект
Для чего нужно:
* доставка логов до хранилища;
* массово считать;
* обработка событий;
* обмен между микросервисами.

Комбинация гарантий(AAE):
1. at-most-once - максимум 1 раз, например физическая почта, доставка;
1. at-least-once - минимум 1 раз, используется повсеместно;
1. exactly-once - ровно 1 раз, важно для финансов, требует затрат не только в реализации очереди, но и в consumer, producer.

#### RabbitMQ & Apache Kafka
Apache Kafka:
producer1 -> message queue1 -> consumer1
...
producerN -> message queueN -> consumerN

RabbitMQ:
producer -> message queue -> consumer1
...
-> consumerN

##### fsync
AK - fsync по таймеру.
RMQ - "честный" fsync.

#### Yandex Message Queue
Тезисы:
* consumer -> pull
* persistent
* at-least-once
* standard & FIFO

Message can be:
* visible;
* hidden;
* deleted.

API:
* CreateQueue
* SendMessage
* ReceiveMessage
* DeleteMessage

Работает на Yandex Database.

#### Понравилось
#### Не понравилось
#### А еще
### Устойчивость GraphQL к нагрузке по сравнению с REST
#### Конспект
#### Понравилось
#### Не понравилось
#### А еще
### Как мы разбили клиент miro.com на ленивые модули, чтобы ускорить его загрузку и масштабировать разработку
#### Конспект
SPA:
Dashboard + board => Complex UI.
Проблемы:
* низкая скорость
* высокая связанность (неочевидно как правки в одном модуле могут повлиять на систему в целом)

Как измеряли:
* Google Chrome Coverage
* speedtracker.org

Основные технологии:
* AngularJs
* Typescript
* Webpack

Направления решения проблем:
* портянка -> components;
* lazy loading modules.

Итого:
* проверка импортов из других модулей;
* проверки размеров модуля;
* шардинг между вкладками;
* асинхронное взаимодействие между модулями;
* загрузка минимального количества данных с сервера первично;
* в ядро кладется не всё, только то, что используется ВСЕМИ модулями.

Потребовалось 2ч * 4 мес.

#### Понравилось
#### Не понравилось
#### А еще
### Shardman - постгрес для кластеров. Что есть сейчас, что будет завтра
#### Конспект
Сравнительный обзор имеющихся решений.
Как работает Shardman.
Что уже есть (SELECT, JOIN), что будет.
#### Понравилось
#### Не понравилось
#### А еще
### Почему мы быстро считаем в банке
#### Конспект
Нет.
#### Понравилось
#### Не понравилось
Быстро считаем, потому что - финансы => надо быстро считать! НИкакой конкретики.
#### А еще
### Не очень большие данные
#### Конспект
Сравнение секционирования между версиями <10, 10, 11, 12, известных методик и проблем.
* INSERT -> RETURNING NULL
* INSERT ON CONFLICT
* TRIGGER for INSERT
* TRIGGER for UPDATE
* postgres_fdw (foreign data wrapper - например любая другая таблица)
#### Понравилось
Я знаю PostgreSQL лучше, чем остальные технологии, о которых шла речь, поэтому мне понятно. Проблемы секционирования в версиях до 10 - мне знакомы.
#### Не понравилось
#### А еще
### Time series данные в реляционной СУБД. Расширения TimescaleDB и PipelineDB для PostgreSQL
#### Конспект
Time series - собранный в разные моменты времени статистический материал о значении каких-либо параметров (в простейшем случае одного) исследуемого процесса. Каждая единица статистического материала называется измерением или отсчётом, также допустимо называть его уровнем на указанный с ним момент времени.
Где это нужно:
* мониторинг автотрафика;
* мониторинг инфрастуктуры;
* мониторинг фронтенда;
* мониторинг оборудования.
В общем - разного рода телеметрия.
Что чаще всего используется:
* InfluxDB;
* Prometheus.
Что использует компания-докладчик: PostgreSQL+PostGIS+TimescaleDB

|Параметр| TimescaleDB | PipelineDB |
|------| -------- | -------- |
|Появилась| 2015 | 2013 |
|Релиз|2018|2018|
|Основной тезис|Хранит данные|Хранит результаты вычислений (потоковая обработка)|
|Расширение для Postgres|Да|Да|
|Сущность|Hypertables, секционирование|CONTINIOUS VIEW, STREAM, потоковая обработка, real-time|
|Интеграция в планировщик|Да|Да|
|SQL|JOIN, aggregate, CTE, etc|JOIN, aggregate, CTE, etc|
|Экосистема|HA, replication backup/restore|HA, replication backup/restore|
|Особенности|Time bucketing, histograms, gap filling|поддержка вероятностных структур данных и алгоритмов|
|Интегрируется|Zabbix, Prometheus, Grafana|Apache Kafka|

#### Понравилось
Я знаю PostgreSQL лучше, чем остальные технологии, о которых шла речь, поэтому мне понятно.
#### Не понравилось
#### А еще
### Самый лучший GEODIST() к западу от Рио-Гранде
#### Конспект
1. Использовать упрощение формул.
1. Использовать Lookup Table.
1. Использовать Linear Interpolation.
1. Использовать Ряд Тейлора.
#### Понравилось
1. Понятно, наглядно
1. Измеримые метрики
1. Сравнение подходов в цифрах
#### Не понравилось
Нет.
#### А еще
### Применение микросервисов в высоконагруженном билинге
#### Конспект
#### Понравилось
#### Не понравилось
#### А еще
### В единстве сила: как мы пишем тесты всей командой
#### Конспект
#### Понравилось
#### Не понравилось
#### А еще
### Инфрастуктура поиска в Яндекс.Маркете
#### Конспект
#### Понравилось
#### Не понравилось
#### А еще
### Бэкенд на NodeJS. Опыт Bolt
#### Конспект
Базовые технологии:
* AWS: EC2, Redshift
* NodeJS, PHP, Nginx, MySQL

Используется Typescript, потому что типизация.
Используются async/await вместо callback.
NodeJS - оптимален для I/O.
Микросервисы. ~200.
Микросервисы обмениваются данными через
* API;
* Очередь.

Разработка:
* Git;
* Docker;
* Jenkins.

Тестирование:
* Компонентные тесты;
* Системные тесты;
* Юнит-тесты.

Тесты пишут программисты. Приоритетные тесты - компонентные.

Мониторинг:
1. Доступность логов (nginx/NodeJS)
* Elasticsearch + Kibana
2. Доступность метрик
* Prometheus + Grafana
3. Активный мониторинг
* Kibalert
* Grafana alerts

#### Понравилось
Используются знакомые технологии.
#### Не понравилось
Где часть про HighLoad? В чем он состоит?
#### А еще
### Зеркалирование трафика в Рекламной Платформе
#### Конспект
Передкомандой тестировщиков стояла задача: зеркалировать входящий трафик для целей тестирования.
Ограничения: решение должно быть пригодным к использованию тестировщиками на продакшене с минимальными затратами со стороны DevOps
Было испробовано 8 решений - от них отказались по причене того, что решения не проходят через ограничения. В итоге:
* выбрали ScaPy,
* дописали Traffic Reply.
#### Понравилось
Объяснение проблематики, есть критерии сравнения решений.
#### Не понравилось
Почему этим занимаются тестировщики, почему нельзя привлечь DevOps, если в итоге к ним и обратились.
#### А еще
## Вывод
1. Нужны метрики.
1. Нужны системы для получения метрик.
1. Нужно делать Proof of concept.
1. Построение презентации: начальные показатели -> меры -> результат в цифрах.
1. Использование очередей Apache Kafka, RabbitMQ, Redis, YMQ.
2. Нужны логи.

## Про что можно почитать, посмотреть
* OLAP, OLTP, шардинг, кластеризация мониторинг систем
* Prometheus
* Grafana
* Elasticsearch
* Kibana
* ClickHouse
* ApacheKafka
* RabbitMQ