Основные принципы построения масштабируемых решений хранения данных в облаке Алексей Халяко SQL CAT, Microsoft

Уменьшение стоимости Закон Мура: скорость роста вычислительных мощностей растет, но только в параллельных вычислениях Скорость CPU «застыла»… Вычислительные мощности

«Горячие точки» Потребность в сокращении расходов на системы и их гибкость А так же время на установку, конфигурации, время на введение системы в эксплуатацию. Startup модель Небольшая и нацеленная на определенную функциональность разработка. Неизвестны масштабы использования Одни человек – одна идея Эластичность решений Использовать ресурсы тогда, когда они необходимы

Канонические сценарии

Приложения и нагрузка Приложения Социальные и Меди веб-приложения. Мобильные приложения Pottermore, Viddy, Bender Пользователи e-Commerce платформ Easyjet, Transmediterranea Многопользовательские (multi-tenant) бизнес- приложения (бухгалтерия, управление Retail POS management, инвестиционная аналитика) Bedin Shops Systems, Системы мониторинга мобильных приложений, данные, сгенерированные «машинами» Bugsense, GE Нагрузка Логгирование Мониторинг активности пользователей Мониторинг системы Информация с датчиков OLTP, поиск по ключу, joins Реляционная нагрузка Транзакционное поведение Real-time и аналитическая нагрузка Статус на конец дня Как чувствует себя мое хранилище/база данных? Какая бизнес модель и ожидания роста? Сначала функционал или масштабируемость? Выбор технологии и архитектуры прямиком зависит от ответов на эти вопросы

Сценарий: Нагрузка приложения социальной сети Доставка контента Доступно на всем сайте, переходный процесс (уровень сессии) Просмотр На уровне пользователя Социальные графы Презентация на уровне пользователя (комментарии, like и т.д.), глобально доступны. Слабо связаны/обновляются асинхронно N пользователями. Интерактивные игры Представление на уровне N-пользователей (сессии, статус, действия), доступно глобально global reach (any user can reach any other user). Interactive state updates shared amongst N players.

Типичные нагрузки ПроисхождениеНагрузкаХарактеристики On-premises OLTP Высокая частота транзакций Транзакции короткие Реальное время, низкие задержки Data Warehouse Ad hoc запросы или большие запланированные отчеты Агрегации BI – OLAP Многомерные Cloud-born Cloud DB Реляционный сервис в облаке Data hub, aggregator Сбор данных, перенос Big Data Распределенные, неструктурированные данные BI in the Cloud Легкие отчеты и аналитика End user driven analysis

Варианты платформ в Облаке

Основные понятия и концепции Характеристики единицы масштабирования Какими ресурсами обладает единица масштабирования? (VM, Azure Storage Account,..?) Как достичь максимального использования этих ресурсов? Масштабирование путем объединения ресурсов Как это вообще работает? Какие проблемы, рекомендации, узкие места? Доступность через архитектуру Как гарантировать доступность через избыточность и комбинирование на уровне архитектуры? Опять же: Какие проблемы, рекомендации, узкие места? Но уже на уровне архитектуры

Основные архитектурные принципы Горизонтальное масштабирование в разделяемом окружении Использовать избыточность Уметь реагировать недоступность сервисов Отказ сети Trotelling Минимизация связей между компонентами Понимать ограничения компонент, чтобы успешно объединять их (роли, storage accounts, центры обработки данных) Предсказуемая доступность Строить с избыточностью Уметь реагировать недоступность сервисов Отказ сети Trotelling Если уж отказ – то части функциональности или workload, но не целиком приложение Понимать SLA и строить исходя из понимания этих требований

Platform as a Service Azure SQL Database Это не SQL Server! Publish and run Разделяемое окружение Infrastructure as a Service SQL Server, работающий в Windows Azure VM Да, это - SQL Server! Полный контроль Выше административная нагрузка Azure Storage Таблицы Blobs Очереди Не реляционная Очень дешевая стоимость Оптимизация для массивного использования

Хранилище Azure Azure Storage Account Blob и Table Storage

Azure Storage account Данные автоматически реплицируются между 3мя узлами Гео-репликация выполняется автоматически SLA:99,9% доступность для запросов и gateway подсоединений Доступ контролируется ключами

Azure Storage Account - BLOB

Пример: BLOB 30 тысяч мест, из которых происходит загрузка данных в Azure Storage

Azure Storage Account - Таблицы

Пример - Таблицы

Table Storage Windows Azure Table Storage is a fault-tolerant, ISO certified NoSQL key-value store. Windows Azure Table Storage can be useful for applications that must store large amounts of nonrelational data, and need additional structure for that data. Tables offer key-based access to unschematized data at a low cost for applications with simplified data-access patterns. While Windows Azure Table Storage stores structured data without schemas, it does not provide any way to represent relationships between the data.

Табличное хранилище Применимо: Необходимо хранить огромные массивы данных «Вычитывается» огромное количество данных Никаких сложных индексов Нет схемы Дешевая и эффективная гео-репликация Необходимо достичь высокий уровень масштабируемости без ручного «шардинга» данных.

SQL Azure Database

SQL Databases работает в многопользовательской среде Другие пользователи могут «загрузить» ключевые ресурсы (worker threads, transaction log, IOPS) и повлиять на производительность вашей базы Плохо предсказываемая производительность для высоконагруженных систем, особенно базирующихся на одиночных больших базах Для больших приложений основная проблема в производительности - количество транзакций в секунду, а не размер!

Пример: SQL Database

Оценка масштабируемости и доступности Узкие места масштабируемости Можно достаточно просто добавить web и узлы баз данных – на сколько эффективно они коммуницируют? Нагрузка и throttling одной базы SQL Azure database Throttling базы данных «положит» web сайт (серверы доступны, но данные - нет) Проблемы доступности Большое количество точек вероятного сбоя. (множество экземпляров web/worker, разнесены по множеству доменов) База данных SQL Azure автоматически fail over на реплики Throttling базы данных «положит» web сайт (серверы доступны, но данные - нет)

Управление подсоединением …или как автоматически реагировать на потерю связи

Как работает доступ к данным в облаке? Обратить внимание на: Проблемы управления подсоединением Соединение менее стабильно из-за необходимости прохождения через несколько уровней архитектуры Обязательность включения логики восстановления соединения между приложением и базой данных Более высокие задержки между приложением и данными Firewall, load balancers, gateways Это усиливается при «болтливом» поведении системы

Факторы масштабируемости облака FactorWhy it matters Сетевые задержки -Выше, чем в классической инфраструктуре -Непостоянный фактор – величина может варьироваться. Установление соединения – дорогое удовольствие - Логин через gateway, который перенаправляет к primary Многопользо вательская среда на недорогом железе -Непредсказуемость, связанная с тем, чем занимаются другие -Soft throttling (убивается SPID) -Hard throttling (убиваются все SPIDs на сервере) -Общий log, -Максимальный размер транзакций

Управление подсоединением Использование канала подсоединения 1 Gbit канал утилизация поднялась с 25% до 50% х3 раза быстрее загрузка данных

Управление подсоединением Потеря соединения Соединения «бездельники» отключаются через 30 минут Транзакции отключаются, если выполняются больше 24 часов. Error code Denial of Service attacks: высокое количество неудачных логинов с определенного IP, SQL Azure блокирует этот IP на определенное время Failover Load balancer, error code Worker cap (180), error codes 10928, Throttling

WA SQL DB имеет ограничения на использование ресурсами (соединения, worker threads, память, etc.) Меньшие, чем выделенные SQL Server экземпляры (многопользовательский сервис) WA SQL DB определяет min и max для используемых ресурсов Гарантия, что получите минимум Гарантия, что не получите больше максимума Наблюдается «средняя» утилизация. Microsoft постоянно улучшает изоляцию сервисов Бывают времена, когда все разом активизируется на определённом узле…

Throttling WA SQL Database может иногда throttle соединения во время ре-балансировки нагрузки на кластере Soft throttling укажет на необходимость перезапуска задачи Hard throttling убьет подсоединение и заставит установить его заново Более детально в Windows Azure SQL Database Performance and Elasticity Guide Throttling выражается как ошибка подсоединения The service is currently busy. Retry the request after 10 seconds. Code: %d. Для лучшего понимания, что произошло – декодируйте код ошибки

Примеры кодов ошибки Error numberSeverityDescription The service has encountered an error processing your request. Please try again. Error code %d The service is currently busy. Retry the request after 10 seconds. Code: %d The database has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions. Code: %d Session is terminated because you have a long-running transaction. Try shortening your transaction.. (20 sec) The session has been terminated because it has acquired too many locks. Try reading or modifying fewer rows in a single transaction The session has been terminated because of excessive TEMPDB usage. Try modifying your query to reduce the temporary table space usage. (5Gb) The session has been terminated because of excessive transaction log space usage. Try modifying fewer rows in a single transaction. (LSN distance cannot exceed 20% of the size of the log file or >1Gb) The session has been terminated because of excessive memory usage. Try modifying your query to process fewer rows. (16Mb for more than 20 sec) Database '%.*ls' on server '%.*ls' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them the session tracing ID of '%.*ls'.

Transient Fault Handling Ключевые элементы архитектуры

Handling Transient и управление ошибками Использовать fault handling frameworks для определения ошибок Выполнять «на заднем фоне» и фильтровать нужные события Регламент восстановления соединения и реакции на ошибки

Handling Transient и «длительные» сбои

SQL in Windows Azure VM

SQL Server в Windows Azure VMs Известный подход и опции контроля Совместимость приложений, работает со всеми существующими нагрузками Гибкость в схеме хранения данных, trace flags, etc. Windows Azure Blobs представленные как NTFS тома Различные размеры До 8 ядер, 56 Gb памяти RAM до 16 Data Disks (каждый 1TB, 16 TBs вместе) Может быть использован в HA/DR сценарии в конфигурации AlwaysON Однако требуется планирование обслуживания и абсолютно облачной «infrastructure design» Масштабируется, если большая VM в наличии Требуется адекватно планирование масштабирования (можно использовать AlwaysON) Если требуется «эластичность» -необходимы дополнительные усилия (например – оптимизация стоимости, основанная на пиковых нагрузках) С аккуратным планированием, можно достичь впечатляющих результатов, но это не сравнимо с on- premise решением

Вычислительные ресурсы в облаке IaaS Лучше больше, да меньше Масштабируемость небольшими шагами Размещение и фрагментация вычислительных ресурсов: VM может иметь до 8 ядер Физический сервер может иметь тоже до 8 ядер Однако может не хватать неиспользуемых физических узлов для размещения XL VM XL VM хороши для приложений, активно использующих память Кэш

Архитектура приложений в обоаке

Традиционная архитектура

Проблема с горизонтальным масштабированием приложения в облаке Если горизонтально масштабировать приложение с SQL,.. Может получиться так, что приложение спровоцирует N*M соединений Горизонтальное масштабирование должно «выровнять» уровень доступа к данным с базами Front-End маршрутизация на Web роли, которая понимает секционирование Разделить сервисы уровня приложения Аффинитизировать с базами данных

Варианты секционирования

Горизонтальное секционирование

Вертикальное секционрование

Гибридное секционирование

Как секционировать для масштабирования 1)Выбор ключа 2)Ключ определяет значение ключа секционирования (опционально) 3)Связать логическую секцию с величиной ключа 4)Связать логическую секцию с физической (шард)

Секционирование (Range Based) 1)Пользователь (user ID) натуральный ключ секционирования; все нагрузки – вокруг пользовательского ID 2)Переводим ID в Int 3)Связать ID (int) с номеров шарда 4)Связать номер шарда со строкой подсоединения к физической базе

Выоды

SQL AzureSQL Server in WA VMsAzure Tables Целевые проекты Startup-проекты Гибкость Совместимость с приложением Существующие enterprise customers Традиционные нагрузки Dev-ориентированные компании Сохранил и забыл Простые запросы Operations + Management Автоматически администрируемы Минимальное влияние/понимание что происходит Одна база данных Требуются усилия для нескольких баз Storage analytics Продукты 3х компаний Availability 99.9% доступность Дополнительные усилия, если нужно больше (Почти) как в «on-premise» Требуется соответствующая инфраструктура для HA Несколько копий данных Никаких oops восстановлений Performance + Scalability Разделяемые ресурсы Требует горизонтального масштабирования «Ожидаемая» производительность Ограничена «железными» ресурсами Обеспечивается секционированием Throttling Migration effort from on premises Минимальные проблемы совместимости Scale out через дополнительные усилия Прозрачно Может быть непросто. Если ресурсов одной VM недостаточно Может принести измерение модели и кода, если «унаследовано» от реляционного приложения Costs Оптимизированно для невысокой стоимости Лицензирование и стоимость VM – очень интересная тема Дешево Может потребовать дополнительных вычислительных ресурсов

© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Range Based Partitioning Range based partitioning Hash (MurMur3) against Upper() 5 shards, evenly distributed Shard: :

Logical Bucket Based Partitioning Range based partitioning Hash (MurMur3) against Upper() 5 shards, evenly distributed Shard: 27 Logical buckets mapped to physical databases

Lookup Bucket Based Partitioning Range based partitioning Hash (MurMur3) against Upper() 5 shards, evenly distributed Shard: 2 Lookup records map each partition value to a logical/physical resource