Хабрахабр

Pizza as a service: как Amazon на Redshift мигрировал

Теперь мы регулярно проводим у себя облачные митапы. Привет, меня зовут Виктория, и я отвечаю за маркетинг в КРОК Облачные сервисы. Я недавно попала на крутейшее выступление Дмитрия Аношина, который сейчас работает в Amazon, и хочу им поделиться.

С одной стороны, это выливается в продвинутую аналитику, повышение продаж и привлекательность продуктов. У меня появилось стойкое ощущение, что крупные коммерческие компании решили собрать вообще все возможные данные в мире, до которых могут дотянуться. С другой — данные стали настолько жирными и всеобъемлющими, что анекдоты про грузовики с CD-дисками уже давно обыденность.

Разберём разницу между концепциями SMP и MPP, ETL и ELT и попробуем понять, зачем нужны облака для больших данных. Посмотрим, зачем может понадобиться миграция в облако, и что получила Amazon от переезда внутренней инфраструктуры на Redshift и NoSQL DynamoDB.

Заходите под кат, я подготовила конспект основных моментов выступления. Ну а если вы в курсе того, что происходило в индустрии в последние годы, то листайте сразу к конкретному кейсу.

Телеметрия из каждой лампочки

То есть ты проснулся, пошёл чистить зубы и параллельно проглядываешь новости в мультимедийном зеркале. Есть очень заметный тренд у крупных компаний на формирование комплексных экосистем вокруг своих пользователей. Тут же ты заказываешь свежий кофе с доставкой на дом, так как старый уже на исходе. Колонка Alexa включает бодрую музыку с утра и напоминает про сегодняшние встречи. Плюс смарт-браслет, наушники, приложения в телефоне и тысячи других источников информации. Садишься в машину, а там — снова Alexa, которая интегрирована с автомобильной мультимедийной системой и продолжает сопровождать в дороге.

Согласитесь, круто, когда, например, по программе от Amazon «Key In-Car» ваши покупки вам доставят прямо в багажник автомобиля на стоянке. Это одновременно и немного пугающее будущее, которое стремительно наступает со всех сторон, попытка создать дополнительную ценность для конечного потребителя со стороны компаний. Для компании это тоже очень ценные данные с точки зрения таргетирования продаж, прогнозирования спроса, оптимизации логистики и прочего. Я сейчас живу в Канаде, и подобные интеграции делают жизнь намного комфортнее. Win-win.

Как я уже говорил, есть стойкое ощущение, что компании часто собирают данные в избыточных масштабах в надежде монетизировать их в будущем. Одна проблема. Реально терабайты плохо структурированной информации, которая непрерывно льётся на серверы компании, пожирая сетевые, вычислительные и storage-ресурсы. А это терабайты. А ещё нужно дать бизнес-аналитикам нормальный интерфейс, который не потребует от них экспертных знаний в области построения облачной инфраструктуры. Именно поэтому столь важной является проблема оптимальной утилизации ресурсов и обеспечения скорости вычислений. Поэтому многие крупные компании двинулись в сторону облаков.

There is no cloud

Нет, спору нет, он солидно выглядит в финансовых отчётах компании и на официальных презентациях. Облачные технологии — это тот ещё buzz-word, который всех изрядно достал. Однако для «облачности» нужно нечто большее, чем просто удобная консоль виртуализации. Тем не менее на уровне железа это всё те же старые добрые серверы, расположенные в дата-центрах по всему миру. Основная фишка облаков — полностью динамическое управление ресурсами и их автоматическое масштабирование при необходимости:

  • Вычисление.
  • Хранение.
  • Сетевые ресурсы и транспорт.
  • База данных.

Когда у вас есть подобная инфраструктура, вы намного более полно утилизируете имеющиеся у вас ресурсы, что при крупномасштабных бизнес-кейсах может выливаться в значительную экономию.

Представьте, что вы планируете приобретение нового железа для своей инфраструктуры на будущий год. Для небольших компаний подобный подход тоже может быть очень привлекателен. Например, ваш продукт совершенно внезапно становится дико популярным из-за удачной публикации на Хабре, на вас набегает целая толпа клиентов и дико разочаровывается, потому что вы не планировали такие пиковые нагрузки. При этом вам очень сложно прогнозировать точную нагрузку, которая может колебаться от множества факторов. Ставка исключительно на покупку железных мощностей — это почти всегда крайне инертный процесс, и он заведомо проигрывает в адаптивности на быстро меняющемся рынке. А может быть и обратная ситуация, когда вы переоцениваете спрос, закупаете избыточные мощности и в итоге получаете простаивающее оборудование, которое фактически изымает из оборота компании столь необходимые деньги.

Или вообще полностью обеспечивает вас инфраструктурой. Именно для таких ситуаций подходит частичная или полная миграция в облако, которое служит чем-то вроде конденсатора, сглаживающего пиковые всплески потребления.

Виды облаков

Небольшой бизнес обычно использует публичные облака и экономит на соответствующих специалистах, сосредотачиваясь на своём продукте. По сути, в зависимости от своей бизнес-модели компании обычно приходят к одной из трёх форм построения облачных систем. Поэтому часто они строят приватные облака, достигая оптимальной утилизации ресурсов. Особо крупные сами по себе похожи на множество отдельных компаний, связанных общей целью и брендом. Pizza as a service: Часть использует гибридные модели, которые позволяют обрабатывать особо чувствительные, защищённые законодательно данные локально и выносить на внешние облака второстепенные задачи.

Мне всегда очень нравилась эта иллюстрация, которая хорошо показывает степень делегирования инфраструктурных задач вашей компании вендору.

Идеально! Традиционный On-Premises-вариант — это пойти купить продуктов, разогреть духовку и приготовить пиццу самому. Но нужно иметь всё оборудование, ингредиенты и прочее.

Вы арендовали кухню со всем оборудованием, принесли свои продукты и приготовили отличную пиццу. IaaS — это вариант аренды инфраструктуры. Отмывать духовку от жира будут специально обученные люди, а вам не нужно беспокоиться об остроте ножей и прочих мелочах.

Сервис предоставляет вам какие-то дополнительные плюшки помимо голой инфраструктуры. PaaS — платформа как сервис. В нашем примере с пиццей это может быть, например, готовое сформованное тесто, которое остаётся только разморозить, намазать ароматным соусом, посыпать шампиньонами, ломтиками нежного бекона и тёртым пармезаном. Например, Amazon Redshift — как хранилище данных, что позволяет экономить на DBA и сосредоточиться на продукте.

В этом случае вы получаете максимально готовый продукт, на базе которого вы строите свой бизнес. Финальный вариант — SaaS. В нашем примере это будет самый дорогой, но простой вариант заказа готовой пиццы на дом. Например, ведёте блог на базе чужой публичной платформы.

Данные на грузовиках. Snow-Mobile

Есть старый бородатый анекдот времён «нулевых» годов: «Бригада водителей многотоннажных грузовиков смогла доставить за ночь 100 000 компакт-дисков из Одессы в Киев. Тем самым они достигли скорости передачи данных в 2.43 терабайт в секунду на расстояние больше 500 км без применения дорогих кабелей».

Однако с современными объёмами непрерывного потока фоточек с каждого мобильника, аудио-, видео- и прочей телеметрии она становится совсем несмешной и превращается в реальную проблему. На тот момент это было просто шуткой. Тут на помощь приходят такие сервисы, как Snowball от Amazon. Когда у вас нет прямого арендованного толстого оптического линка до дата-центра, переезд больших объёмов данных в облако может стать огромной проблемой.

Вам привозят такой вот брутальный защищённый чемоданчик, забитый 50 терабайтами скоростных дисков и 10-гигабитными сетевыми интерфейсами. Дальше вы подключаете его непосредственно к своему стораджу и сливаете все данные с максимальной скоростью. На случай кражи или других неприятностей данные покидают вашу серверную только в зашифрованном виде. В чемоданчике есть модуль TPM, а управление ключами шифрования происходит с помощью сервиса AWS Key Management Service (KMS). Ключи шифрования не хранятся на самом устройстве.

В особо запущенных случая можно вызвать Snowball Truck — мобильный дата-центр с ёмкостью в 100 петабайт. Когда масштабы данных приближаются к эксабайту, обычный 10-гигабитный коннект потребует 26 лет на трансфер данных. А такие белые грузовички смогут перетащить данные за шесть месяцев.

Переход Amazon с Oracle на Redshift


Что у нас было

У таких крупных торговых платформ, как Amazon, есть очень болезненный участок работы — Prime Days. Расскажу немного про тот кейс, с которым я работал в Amazon. В этот момент серверы плавятся под нагрузкой, склады переполнены погрузчиками, а логистика захлёбывается под непрерывным потоком товаров. Это пиковые дни продаж в Чёрную пятницу и рождественскую распродажу. Это очень важное время с точки зрения продаж, и каждый час простоя или недоступности сервиса обходится в колоссальные суммы убытков.

База данных просто перестала вывозить такой объём одновременных запросов, испытывая проблемы с масштабированием. Проблема пришла со стороны Oracle DB. Сайт практически складывался под натиском покупателей, а база данных становилась проблемой с точки зрения масштабирования.

Плюс Oracle ещё и крайне дорогой в плане лицензий и поддержки. После тщательной аналитики пришли к выводу, что традиционные SQL-базы не подходят в качестве бекэнда торговой площадки такого масштаба. В итоге было принято решение мигрировать на свою облачную платформу, в основе которой лежали Redshift и NoSQL DynamoDB.

Очень важной фичей был Auto Scaling — динамический скейлинг БД под требуемый объём данных. DynamoDB был внутренней разработкой c синхронной репликацией между дата-центрами и крайне эффективным механизмом снижения избыточности данных, что позволило значительно сэкономить на их хранении. Также была проработана отличная интеграция с Hadoop.

В чём же основная проблема традиционной БД?

То есть у вас есть мощная машина с определённой памятью, кучей быстрого стораджа, и все запросы так или иначе стекаются к ней. Проблема в том, что старый вариант с Oracle относится к SMP-архитектуре, которая предполагает только вертикальное масштабирование. При этом в компании особо не верили в облака, и параллельные вычисления не считались перспективным решением. Это классическая модель Oracle, которая сфокусирована на поставке своих мощных отдельно стоящих серверов. А нам был нужен MPP — параллельная архитектура, которая позволяет размазать запрос на множество отдельных машин и быстрее обработать данные.

Есть ещё один важный момент — ETL vs ELT-подход к внесению данных в БД.

То есть мы вначале получаем данные из наших источников, тщательно структурируем их и только после этого заливаем в наше хранилище. ETL — Extract -> Transform -> Load. В принципе RedShift поддерживает оба подхода, но у ELT есть преимущество: обращение к отфильтрованным данным происходит быстрее, ими проще манипулировать. ELT-подход подразумевает заливку сырых шумных данных в хранилище и обработку уже на его стороне. Есть ещё один неочевидный момент. Хотя при этом тратится больше ресурсов на первичный разбор сырой информации. Это снижает риски несанкционированного доступа к данным. ETL снижает риски с точки зрения GDPR в европейском законодательстве, заблаговременно фильтруя чувствительную информацию до того, как она попадёт в общее хранилище. Там уже есть приятный GUI, он отлично конфигурируется и уже поставляется в варианте, заточенном на Amazon RedShift. Основным инструментом для первичной обработки данных в новую архитектуру стал Matillion. Теперь продакт-менеджеры могут сами в форме визуального конструктора конфигурировать входящие потоки данных без помощи наших дата-инженеров. Благодаря ему получилось снизить порог входа.

Например, смогли решить задачу разгребания 50 ГБ логов веб-сервера в сутки для прогнозирования поведения посетителей. В итоге мы получили нужную нам гибкость, масштабирование и сглаживание пиковых нагрузок.

А ещё мы внедрили Tableau, что позволило перейти от плохо связанных таблиц в Excel к единым дашбордам, удобным для руководства.

Проект был нацелен на обе вещи, но я рассказываю конкретно про Oracle DW! И поясню ещё на всякий случай: есть Oracle OLTP (бекэнд) у магазина, есть Oracle DW — аналитическое хранилище данных. То же самое — про Tableau. То есть приведённые диаграмма и описание — локальные, они касаются одной лишь команды Амазон. Когда я говорю «мы внедрили Табло», имеется в виду локальный проект, так как в Амазоне всё разбито по командам, и каждый сам выбирает, что делать и что внедрять и использовать.

Скорее всего, большинство бизнес-проектов так или иначе будет строиться вокруг подобной инфраструктуры. Облака, несмотря на несколько нездоровый хайп вокруг них, — уже текущая реальность. Но планировать дальнейшее развитие стоит уже сейчас, иначе будет сложно быстро реагировать на стремительно меняющиеся параметры рынка и жёсткую конкуренцию. Да, возможно, не каждой компании подойдут такие решения.

Я скидываю туда полезный контент. Если кому интересна тема облачной аналитики и современных решений, заходите сюда.

Приходите к нам на митапы

На следующий год мы запланировали еще несколько ивентов, о них будем рассказывать подробно. У КРОК Облачные сервисы уже прошла целая серия выступлений отличных спикеров, например, темой одного митапа стало практическое использование сервисов AWS в жизни. Следите за событиями.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»