Блог Amazon Web Services

Apache Spark – за рамками MapReduce

Виталий Федоренко (Vitalii Fedorenko), AWS Big Data Cloud Architect
Author: Vitalii Fedorenko

Данная статья это вольный перевод одного из наиболее популярных AWS постов об Apache Spark Джона Фрица.

Как многим из Вас уже известно, веб-сервис Amazon EMR упрощает обработку и анализ больших объемов данных используя такие библиотеки как Hadoop, Hive, HBase, Presto, Impala и Spark. В то время как Hadoop MapReduce все еще популярен для обработки больших объёмов данных, анализа неструктурированных данных и машинного обучения, Apache Spark стал вытеснять его, обеспечивая лучшую производительность кластера и скорость разработки. Используя движок на основе направленного ациклического графа (DAG), Spark создает более эффективный план выполнения запросов преобразования данных. Кроме того, Spark использует отказоустойчивые распределенные наборы данных (RDD), сохраняя промежуточные, входные и выходные данные в памяти, а не на диске. Эти элементы функциональности повышают производительность определенных программ по сравнению с Hadoop (к примеру, машинное обучение), так как MapReduce выполняет задачи по последовательной схеме и затрачивает большее количество ресурсов на ввод-вывод промежуточных данных на диск.

Spark поддерживает такие языки программирования как Scala, Python, Java, и SQL API, популярные алгоритмы машинного обучения, обработку графов и потоков данных. В Spark есть множество параметров которые упрощают разработку по сравнению с различными абстракциями, обернутыми вокруг Hadoop MapReduce API.

Spark на Amazon EMR

Вы можете создавать масштабируемые Spark кластера с различными типами EC2 инстансов непосредственно из консоли Amazon EMR, CLI или API. Работая в контейнере EMR, Spark может читать данные через EMRFS напрямую из S3, пересылать логи в хранилище данных S3, использовать Spot EC2 для снижения затрат, а также интегрироваться с такими функциями безопасности AWS как IAM роли, группы безопасности EC2 и шифрование S3 в состоянии покоя (на стороне сервера или клиента). Одним из основных достоинств является то, что нет никакой дополнительной платы за Spark на AWS EMR.

Читать дальше

Разворачиваем GridGain кластер на AWS через AWS Marketplace: Часть I

Денис Баталов, архитектор AWS, @dbatalov
Author: Denis V. Batalov

Друзья, рад представить вашему вниманию первую часть из серии гостевых постов от коллег из компании GridGain! Платформа GridGain – это современное и технически интересное решение по созданию сверх-производительных распределённых баз данных с реляционным интерфейсом, работающих в основном в оперативной памяти.

Для справки немного о самой компании. GridGain Systems – калифорнийский стартап, который дорос до серьезной и быстрорастущей международной компании с клиентами по всему миру. Среди клиентов GridGain можно встретить таких именитых мастодонтов, как Сбербанк, Barclays, American Express, Microsoft, IBM, Huawei, RingCentral и Workday. Все они тем или иным образом используют GridGain In-Memory Data Fabric – платформу и фреймворк, который представляет из себя распределенное memory-first хранилище и вычислительную систему, масштабируемую горизонтально и дающую колоссальный прирост производительности, благодаря своей архитектуре.

Платформа находит применение во всех отраслях и секторах, начиная от финансового, заканчивая cферой Интернета Вещей. Такая широкая область применения обусловлена обилием компонент, работающих поверх распределенного хранилища данных (таких как распределенный ANSI-99 SQL движок), поддержкой распределенных ACID транзакции, real-time streaming, machine learning и многим другим.

В этой серии статей Денис Магда расскажет о том, как начать работу с GridGain кластером на AWS и доходчиво объяснит, как этот зверь работает “под капотом”.


 

Денис Магда, GridGain Product Manager
Author: Denis Magda

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

Данный вызов нашего времени породил определенное число распределенных реляционных баз данных, NoSQL хранилищ и Data Grids, которые воплощают в жизнь концепцию горизонтального масштабирования: хранение и обработка данных происходит в кластере состоящего из N-го кол-ва машин, и, если необходимо увеличить производительность при возросшем объеме данных, то достаточно добавить новый узел в кластер, работающий на обычном железе.

Читать дальше

Реализация защищенной корпоративной системы резервного копирования и восстановления в AWS

Андрей Зайчиков, Архитектор AWS

Всем привет!

Сегодня мы поговорим о том, как реализовать защищенную корпоративную систему резервного копирования и восстановления с использованием сервисов AWS.

Для начала – пара слов о проблематике.

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

Очевидно, что системы резервного копирования и восстановления стоят денег, однако выделять деньги на подобные системы компании не спешат, т.к. стоимость данных решений в общем ИТ портфеле компании нередко довольно высока. Кроме того, для подобных систем характерны классические «железные» проблемы – неэффективное использование ресурсов, необходимость планировать ресурсы сильно заранее, сложность внедрения и сопровождения. В итоге, системы внедряются в ограниченном объеме (если вообще внедряются), что приводит к очевидным потерям в случае возникновения непредвиденных ситуаций.

Преимущества облачных технологий для данного класса систем кажутся очевидными, среди них можно отметить:

  • Практически неограниченный объем доступных ресурсов;
  • Использование ресурсов по pay-as-you-go модели;
  • Высочайший SLA по надежности и доступности;
  • Широкие возможности оптимизации хранения данных.

Однако, возникают резонные вопросы. Можно ли сохранить высокую степень конфиденциальности данных в облаке AWS? Можем ли мы быть уверенными, что данные не попадут в чужие руки / не будут повреждены / уничтожены? Можем ли мы гарантировать, что соединение нашей корпоративной сети с AWS безопасно? Насколько высока степень доступности, которую можно обеспечить? Насколько сильно удаленность региона повлияет на нашу работу? Получится ли выполнить архивирование / восстановление в заданный временной интервал? Насколько эффективно мы сможем использовать облачные ресурсы?

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

(more…)

Миграция кластеров NoSQL DB между регионами AWS

Андрей Зайчиков, Архитектор AWS

Роман Скваж, CTO FunCorp

Александр Домнин, SysOps Engineer FunCorp

Всем привет!

Сегодня у нас в гостях замечательные специалисты и просто хорошие люди из компании FunCorp – Роман Скваж (CTO) и Александр Домнин (SysOps). Мы расскажем вам об одном интересном проекте по миграции больших кластеров нереляционных баз данных между регионами AWS (из Европы в США).

Что мигрировать?

По словам Романа Скважа: «Флагманский продукт компании – iFunny (https://ifunny.co/) одно из наиболее популярных развлекательных приложений среди американской молодежи. За 5 лет сервис обзавелся внушительной аудиторией: мобильные приложения обслуживают более 3,5 миллионов активных пользователей в день и работают во всех часовых поясах.  Backend приложения полностью реализован на Amazon Web Services и его масштаб впечатляет:

  • Кластер Apache Cassandra – 25 узлов, 18 TB данных;
  • Кластер Apache Cassandra – 18 узлов, 16 TB данных;
  • Кластер MongoDB – 5TB данных, распределенных по 8 shard’ам, каждый shard – ReplicaSet из Master и двух Slave;
  • Кластер MongoDB – 150GB данных, распределенных по 4 shard’ам, каждый shard – ReplicaSet из Master и двух Slave;
  • Кластер Elasticsearch – поисковый индекс объемом 1 TB;
  • 3 ReplicaSet Redis – Master + 2 Slave с 15 GB, 10 GB и 1 GB данных и крайне высокой скоростью записи.

Силами наших DevOps и Backend команд, нам предстояло перенести все это из одного региона AWS в другой без downtime и крупных изменений в приложении. При этом желательно было не задействовать сторонние приложения и платные сервисы».

(more…)

Как мониторить состояние AWS инфраструктуры и вовремя получать важные алерты через Corezoid Process Engine?

Денис Баталов, архитектор AWS, @dbatalov
Author: Denis V. Batalov

Друзья, рад представить вам гостевой пост от коллег из ПриватБанка (Украина) – 13-ого по величине банка в Восточной Европе. Из более чем 25 миллионов клиентов банка, 10 миллионов регулярно пользуются онлайн платформой Приват24, и более 5,5 миллионов пользуются его мобильной версией.

 

Недавно ПриватБанк заменил многие из своих систем обработки бизнес-логики на гибкий облачный бэкенд названный Corezoid и созданный отделом R&D банка. В Corezoid всё построено на основе API, а сам он работает на AWS. ПриватБанк также запустил Sender – мобильный мессенджер для бизнеса, который позволяет ПриватБанку общаться со своими клиентами, а также клиентам – общаться с другими компаниями предоставляющими услуги. Sender спроектирован с учётом мобильного образа жизни, а его функционал реализован на основе Corezoid. О преимуществах использования Corezoid для банковских нужд вы можете прочитать здесь, а в нашем посте речь пойдёт об интересном примере использования Corezoid для мониторинга состояния инфраструктуры AWS. Далее текст коллеги из ПриватБанка.


 

Павел Шахман, руководитель команды DevOps, Corezoid
Author: Pavel Shakhman

Для полного контроля за всеми изменениями в вашей AWS инфраструктуре есть замечательный веб-сервис CloudTrail.

 

С помощью CloudTrail можно получить историю вызовов API AWS, сделанных в вашем аккаунте, включая вызовы API, сделанные из Консоли управления AWS или с помощью пакетов AWS SDK, инструментов командной строки и сервисов AWS более высокого уровня (таких как AWS CloudFormation). История вызовов API AWS в CloudTrail делает возможным проведение анализа безопасности, отслеживание изменения ресурсов и аудит соответствия, т.к. включает в себя идентификацию источника, совершившего вызов API, время вызова API, IP-адрес источника, совершившего вызов API, параметры запроса, а также элементы ответа, возвращенные сервисом AWS.

Читать дальше

Основные способы оптимизации стоимости на AWS

Андрей Зайчиков, архитектор AWS

Всем привет!

Сегодня мы поговорим об основных и наиболее часто используемых возможностях оптимизации затрат на сервисы AWS.

Основные варианты оптимизации затрат
К таким вариантам относятся в первую очередь:

  • Зарезервированные инстансы (Reserved Instances) – для постоянных нагрузок;
  • Scheduled Reserved Instances – для нагрузок, постоянно возникающих в четко определенные моменты времени;
  • Спотовые инстансы (Spot Instances) – ­ для получения во временное пользование простаивающих серверов на сотовом рынке (с существенной скидкой);
  • Оптимизация времени использования ресурсов;
  • Оптимизация объема использования ресурсов;
  • Контроль неиспользуемых ресурсов.

Читать дальше

AWS для разработчиков. Типовые сценарии использования AWS

Андрей Зайчиков, Архитектор AWS

Всем привет!

Этим постом мы открываем серию публикаций по использованию Amazon Web Services для создания и управления средами разработки и тестирования. Это будет серия постов, отражающих разные аспекты создания, управления и использования сред разработки и тестирования на AWS.

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

Если вы когда-нибудь начинали работать над ИТ проектом с нуля – вы точно знаете, что Аристотель был прав. Это как раз тот случай, когда начало – это, как минимум, половина дела.

Читать дальше

Всем привет!

Денис Баталов, архитектор AWS, @dbatalov
Author: Denis V. Batalov

Друзья, сегодня мы запускаем русскоязычный блог Amazon Web Services!

Мы планируем прежде всего фокусироваться на темах которые будут интересны русскоговорящим пользователям AWS.  Собираемся публиковать как глубоко технические посты на узкие темы, так и обзорные посты по новым сервисам и функционалу, или по новым преимуществам использования облака AWS с точки зрения организации и трансформации бизнеса.

Пользуясь случаем, хочу напомнить что основные страницы сайта AWS уже доступны на русском языке, а для пользователей Twitter мы ведём русско-язычный микроблог @awsoblako. Кроме этого вам доступны следующие материалы на русском (вебинары доступны после бесплатной регистрации на сайте BrightTalk):

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

Например, в 2011 году мы осуществили 80 релизов значимых сервисов и возможностей. В 2012 – уже почти 160, в 2013 – 280, а в 2014 мы произвели уже 516 релизов. В прошлом 2015 году мы запустили 722 возможности и сервиса, что на 40% выше предыдущего года. В качестве иллюстрации ниже привожу список важных релизов 2016 года.

Как видите, новостей много, так что читайте, подписывайтесь, следите за объявлениями!

Основные релизы 2016 года, начиная с самых последних: