Андрей Зайчиков "Архитектура распределенных кластеров NoSQL на AWS"
Download as PPTX, PDF1 like364 views
Документ рассматривает проектирование глобально распределенных кластеров NoSQL на платформе AWS, подчеркивая важность учета специфики баз данных и сценариев использования. Обсуждаются различные подходы, технологии, особенности проектирования и мониторинга, а также преимущества использования сервисов, таких как Amazon DynamoDB и Amazon S3 с Athena. В конце документа подчеркивается, что одно универсальное решение не существует, и выбор технологии должен уточняться в зависимости от контекста и требований приложения.
Андрей Зайчиков "Архитектура распределенных кластеров NoSQL на AWS"
- 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 теорема?
- 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
- 14. Выбор технологии • Специфика приложений • Сценарий использования • Модель развертывания • Собственная экспертиза • Необходимость тюнинга • Схема данных • Показатели производительности • Показатели надежности • Специфика развития продукта • Модель обслуживания DynamoDB Cloud-based Self-managed (EC2) Key-value Document-oriented Graph Mixed
- 18. Проектирование схемы данных • Наборы данных (keyspaces, collections) • Идентификационные ключи и ключи распределения данных • Структура индексов • Структура коллекций • Структура запросов • Структура связей Проектирование схемы данных существенно различается в зависимости от класса БД (document-oriented, key-value, graph, etc.) и в большой степени зависит от особенностей реализации конкретной БД.
- 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 Сильно зависит от специфики реализации конкретной базы данных на уровне узла (чтение / запись данных) и на уровне кластера (репликация).
- 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