Мы рассмотрим важные особенности построения архитектуры распреденных кластеров NoSQL с использованием ресурсов Amazon Web Services, мы затронем такие аспекты как: архитектура гео распределенных кластеров, оптимизация производительности, выбор основных опций для деплоймента и ряд других аспектов. В докладе мы сконцентрируемся на таких популярных базах данных, как Cassandra, MongoDB и некоторых других.

2. Architecture of NoSQL
distributed clusters on AWS
Andrey Zaychikov
Solutions Architect,
Amazon Web Services,
Luxembourg

3. Программа и цели презентации
• Рассмотрим основные проблемы, связанные с проектированием глобально
распределенных кластеров NoSQL и опишем подход к проектированию подобных
систем
• Посмотрим, как этот подход может быть использован на примере построения
глобально распределенных кластеров Cassandra и MongoDB
• Разберемся в отличиях и особенностях проектирования в зависимости от типа БД и её
реализации

4. Почему появились распределенные NoSQL БД?
Сложность
схем данных
Объем данных Uptime

5. Характерные черты распределенных систем
Сложное поведение Сложная структура

6. CAP теорема?

7. NoSQL как технология

8. Экосистема NoSQL

9. Значение Cloud Computing для NoSQL
Скорость
масштабирования
Простота организации
глобального
присутствия
On-demand pricing

10. Решения NoSQL на платформе AWS
DynamoDB S3 + Athena NoSQL on EC2 (+ EBS)
Полностью управляемый сервис
баз данных NoSQL,
обеспечивающий прогнозируемую
высокую производительность с
эффективной масштабируемостью.
Amazon DynamoDB дает клиентам
возможность переложить на AWS
административную нагрузку, по
управлению распределенными
базами данных и их
масштабированием.
Amazon Athena – это
интерактивный сервис
запросов, позволяющий легко
анализировать данные в
хранилище Amazon S3 с
помощью стандартных
средств SQL. У Athena –нет
инфраструктуры, требующей
настройки или управления,
поэтому можно сразу же
приступить к анализу данных.
Вычислительное облако Amazon
Elastic Compute Cloud (Amazon
EC2) – это веб-сервис,
предоставляющий безопасные
масштабируемые вычислительные
ресурсы в облаке. Он помогает
разработчикам, облегчая
проведение крупномасштабных
вычислений в облаке.

11. Подход к проектированию глобально
распределенных NoSQL БД
• Оценка необходимости создания
распределенной системы и
применимости NoSQL
• Проектирование сценария
использования
• Выбор технологии NoSQL
• Проектирование приложений
• Проектирование технической
реализации
• Проектирование и организация
операционной деятельности

12. Нужны ли в вашем проекте распределенные NoSQL
решения
• Высокая нагрузка существенно изменяющая
во времени
• Отсутствие существенных требований к
консистентности данных
• Парадоксально высокий uptime
• Относительно простая схема без наличия
существенного количества связей
• Отсутствие необходимости моментально
строить отчетность по всему объему данных
• Высокие требования к latency со стороны
клиентских приложений
• Высокие требования к консистентности данных
• Стабильная нагрузка без существенных
изменений в течение времени
• Относительно редко меняющаяся схема в
хорошо определенной предметной области
• Отсутствие сверх высоких требований по
доступности и latency по запросам со стороны
приложений
• Необходимость строить отчетность / анализ с
использованием полного функционала SQL

13. Проектирование сценария использования

14. Выбор технологии
• Специфика приложений
• Сценарий
использования
• Модель развертывания
• Собственная экспертиза
• Необходимость тюнинга
• Схема данных
• Показатели
производительности
• Показатели надежности
• Специфика развития
продукта
• Модель обслуживания
DynamoDB
Cloud-based Self-managed (EC2)
Key-value Document-oriented
Graph
Mixed

15. Изучение технологии

16. Crush course: Cassandra

17. Crush course: MongoDB

18. Проектирование схемы данных
• Наборы данных (keyspaces,
collections)
• Идентификационные ключи
и ключи распределения
данных
• Структура индексов
• Структура коллекций
• Структура запросов
• Структура связей
Проектирование схемы данных существенно различается в зависимости от класса
БД (document-oriented, key-value, graph, etc.) и в большой степени зависит от
особенностей реализации конкретной БД.

19. Проектирование взаимодействия приложений с БД

20. Проектирование взаимодействия
приложений с БД

21. Проектирование взаимодействия
приложений с БД

22. Выбор географии развертывания

23. Проектирование архитектуры развертывания

24. Проектирование архитектуры
развертывания

25. Проектирование архитектуры
развертывания

26. Выбор типов вычислительных ресурсов и хранилищ
Всегда базируется на специфике базы данных, специфике схемы и паттернов
доступа. Тип вычислительных ресурсов и хранилищ должен адаптироваться под
конкретные нужды.
Cassandra MongoDB

27. Планирование HA & DR

28. Пример: Планирование HA & DR

29. Пример: Планирование HA & DR

30. Планирование вычислительных сетей
• Топология сети
• Конфигурация сети
• Высокая доступность сети /
каналов
• Маршрутизация
• Правила firewall’ов
• MTU
• Оптимизация трафика

31. Планирование ИБ

32. Планирование мониторинга
• Мониторинг вычислительных
ресурсов
• CPU
• RAM
• Disk IO, saturation
• Network throughput, saturation
• Мониторинг системных
процессов
• Write Logs
• Garbage Collection
• Locks
• Queueing
• Мониторинг узлов кластера БД
• Read / Write IO
• Read / Write Latency
• Internal tasks
• Мониторинг запросов
приложений
• Unavailable Errors
• Timeout Errors
• Other types of exceptions
• Мониторинг состояния кластера
• Nodes status
• Replication status / lag
Сильно зависит от специфики реализации конкретной базы данных на
уровне узла (чтение / запись данных) и на уровне кластера (репликация).

33. Пример: Планирование мониторинга

34. Пример: Планирование
мониторинга

35. Планирование обслуживания
• Уведомления и реагирование на
инциденты
• Alarms & notifications (правильные
метрики
• RCA
• Playbook
• Настройка и контроль выполнения
рутинных операций на уровне
кластера
• Anti-entropy operations
• Cluster-wide clean-ups
• Cluster-wide / Shard-wide backups
• Other
• Настройка и контроль выполнения
рутинных операций на уровне
узлов кластера
• Defragmentation
• Compression / Compaction
• Encryption
• Incremental and Full Backup
• Index re-build

36. Пример: Планирование обслуживания
• Regular cluster / partition wide
repair of data (depends on
gc_grace_period)
• Cluster wide time sync
• Per node compactions
procedures
• Manual split of SSTables to
avoid appearance of HUGE
SSTables
• Rotate log files
• Per node data defragmentation

37. Вместо заключения
• Не существует одного решения на
все случаи жизни
• Контекст имеет значение и
решение должно изменяться вслед
за изменением контекста
• Приложение и код должны быть
адаптированы к БД
• Наилучший способ проверить ваш
выбор БД для применения в
вашем решении – провести Proof-
of-Concept

38. Спасибо за внимание!