Architecture of NoSQL distributed clusters on AWS presentation from AWS User Group Kiev Meetup #3

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

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

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

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

5. CAP теорема?

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

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

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

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

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

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

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

13. Выбор технологии: Обзор

14. Пример подхода к выбору технологии

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

16. Crash course: Cassandra

17. Crash course: MongoDB

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

19. Проектирование схемы данных

20. Проектирование схемы данных
• Правильный выбор
PRIMARY_KEY
• Корректное разделение на
keyspaces и column families
• Массовое дублирование
данных
• Структура запросов
• Пред процессинг данных
для формирования
отчетности и read-intensive
workloads

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

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

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

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

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

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

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

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

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

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

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

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

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

34. Планирование мониторинга
• Мониторинг вычислительных
ресурсов
• 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
Сильно зависит от специфики реализации конкретной базы данных на
уровне узла (чтение / запись данных) и на уровне кластера (репликация).

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

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

37. Планирование обслуживания
• Уведомления и реагирование на
инциденты
• 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

38. Пример: Планирование обслуживания
• 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

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

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