Рубрика «Amazon Web Services» - 20

По мере роста количества доменов, размещённых на моём сервера на Hetzner, меня всё чаще стала посещать мысль об использовании своего собственного dns-сервера вместо серверов имён провайдера.

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

Ну а поскольку на сервере кроме dns работает ещё стопицот разных сервисов, да и руки у меня растут хотя и выше одного места, но всё же не слишком уж высоко, то сервер у меня ложится пару раз в год точно. :( Выход, разумеется, в организации физически отдельного вторичного сервера имён (что собственно и предусмотрено технологией dns).

В этой статье я хочу рассмотреть организацию такого сервера на базе облачного сервиса Amazon EC2, учитывая что всем новым аккаунтам Amazon позволяет год работать бесплатно (для micro-экземпляров):

Установка вторичного сервера имён на Amazon EC2 бесплатно

Поехали!

Читать полностью »

image Не так давно AWS Amazon представил сервис, именуемый AWS Test Drive. Мне повезло, в рамках совместной программы AWS Amazon и нашей компании я смог познакомиться с этим сервисом поближе и опробовать его функционал. Для начала хочу вкратце рассказать, что же это такое и зачем оно надо.Читать полностью »

В сети уже есть несколько обзоров производительности этого решения от Amazon, в этой статье я не преследовал цели проверки уже полученных результатов, меня интересовали некоторые особенности, не рассматриваемые в других источниках, а именно:

  1. в документации сказано, что Amazon старается сохранять порядок сообщений, на сколько хорошо он сохраняется?
  2. как быстро происходит получение сообщения при использовании Long Polling?
  3. насколько ускоряет процесс пакетная обработка?

Читать полностью »

Добрый день всем, кто нашел в себе силы для того, чтобы заглянуть на Хабр в последнюю рабочую неделю этого года! На этот раз я хотел бы поделиться с вами опытом использования сервисов для работы с мультимедиа контентом, предоставляемого облачными провайдерами. Чтобы процесс был более интересным мы рассмотрим два облачных провайдера: Windows Azure Media Services и Amazon Elastic Transcoder. После этого конечно же не забудем их сравнить! Итак, поехали!

Входные данные

Пусть входными данными для нас будет являться видео файл снятый с помощью мобильного устройства в формате 720p (Android). Его длительность равна 24 секундам, а размер 13 Мб. Мы хотим его конвертировать в формат 480p.

Базовый интерфейс

Итак, будем создавать новый Solution в Visual Studio. Предположим, что клиент для работы с каждым облачным провайдером должен реализовывать какую-то базовую функциональность. Чтобы, к примеру, мы могли легко заменить использование Windows Azure Media Services на Amazon Elastic Transcoder. Поэтому объявим базовый интерфейс:
public interface IVideoConverter
{
void Convert(string sourceFile, string destinationFile);

void UploadFile(string localFile);

void DownloadFile(string localFile);

void WaitForConversionToComplete();
}

Каждый клиент, реализующий этот интерфейс, должен уметь:

  • UploadFile – загружать файл с локального хранилища в облако;
  • DownloadFile – скачивать перекодированный файл из облачного хранилища в локальное;
  • Convert – собственно уметь перекодировать файл из одного формата в другой;
  • WaitForConversionToComplete – ожидать результатов выполнения операции кодирования.

Общий принцип работы с клиентом будет выглядеть следующим образом:
IVideoConverter client = new КлассРеализующийIVideoConverter();
client.Convert(“путь_к_исходному_файлу”, “путь_к_результирующему_файлу”);

Соответственно метод Convert в псевдокоде будет выглядеть так:
public void Convert(string sourceFile, string destinationFile)
{
// Загрузить файл
UploadFile(sourceFile);

// Начать кодирование
ПерекодироватьВидео();

// Дождаться результатов
WaitForConversionToComplete();

// Скачать перекодированный файл
DownloadFile(destinationFile);
}
Читать полностью »

Только что получил анонс, что на AWS стали доступны новое поколение Amazon EC2 High I/O инстансов. Данные типы инстансов базируются на новом поколении процессоров Intel Ivy Bridge. Каждый виртуальный CPU (vCPU) соответствует одному аппаратную потоку исполнения (hyperthread) процессора Intel Xeon E5-2670 v2 (Ivy Bridge).

Вот табличка:
Читать полностью »

Топ 7 случаев даунтайма известных сервисов и ресурсов в 2013 году

Несмотря на то, что информационные технологии развиваются весьма стремительно, проблемы еще есть. В частности, пока еще никому не удалось добиться стопроцентной защиты от аварийных ситуаций. Тайфуны, отключения электричества, человеческий фактор — все это приводит к простоям оборудования и неработоспособности сайтов/сервисов. О самых значительных проблемах 2013 года стоит вспомнить перед началом нового, 2014, года.

Читать полностью »

Добрый день, читатель!

Есть у нас задача связывать различные сервисы и существующие системы в управляемые процессы. Скорость нужна не космическая (т.е. не по биржевым котировкам отклик создавать), но зато процессов много и компонент (систем) которые нужно использовать тоже порядочно вырисовывается. Не хочется делать p2p связывание. Хочется чего-то красивого и управляемого.

Просмотрев рынок, было принято решение сделать реплику по мотивам Amazon Simple Workflow, так как использовать его напрямую мы не можем. Свойства фреймворка которые нам подходят:
Читать полностью »

Joe Masters Emison опубликовал очередное исследование в котором сравнил относительную стоимость разных типов маши GCE и AWS. Основные на мой взгляд выводы его исследования:

  • Производительность машин в обеих зонах GCE одинакова для всех видов VM
  • Наилучшее сочетание цены и производительности у f1-micro (но у нее возможны сильные изменения характеристик). g1-small и n1-standard-1 очень близки по цене за единицу производительности к f1-micro
  • Если вам нужны однопроцессорные машины по требованию, то GCE сильно дешевле AWS

Статья на английском доступна на Читать полностью »

В очередной раз понадобилось примерно прикинуть стоимость серверов при переносе проекта в облако Amazon. Не удалось найти толкового инструмента, а то, что предлагает сам Amazon слишком сложно для моего понимания. Заодно сделал возможность сравнивать и подбирать сервера на Digital Ocean, RackSpace, Google Compute Engine и Microsoft Azure.

http://jagermesh.github.io/cloudhostingcalculator/

image

Проект на гитхабе — https://github.com/jagermesh/cloudhostingcalculator. Желающие могут дополнить ценами и типами инстанов. Все данные в data/instances.json.

Читать полностью »

Тема высоконагруженных приложений у всех на слуху. Тоже решил вставить свои 5 копеек и поделиться опытом создания высоконагруженного приложения на инфраструктуре AWS.

Сначала, буду банален и повторю всем известные истины. Есть 2 пути масштабирования приложения:
1) вертикальное масштабирование — это увеличение производительности каждого компонента системы (процессор, оперативная память, прочие компоненты);
2) горизонтальное, когда соединяют несколько элементов воедино, а система в целом состоит из множества вычислительных узлов, решающих общую задачу, тем самым увеличивая общую надежность и доступность системы. А увеличение производительности достигается добавлением в систему дополнительных узлов.

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

Недавно мы в очередной раз постигали все прелести горизонтального масштабирования на практике: строили высоконадежный социальный сервис для болельщиков американского футбола, выдерживающий пиковую нагрузку в 200 000 запросов в минуту. Поэтому хочу рассказать о нашем опыте создания высокомасштабируемой системы на инфраструктуре Amazon Web Services.

Обычно, архитектура веб приложения выглядит следующим образом:
Кластеризация веб приложений на хостинге Amazon Web Services
Рис. 1. Типичная архитектура веб приложения

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

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

  • development language and core framework — java 7 and rest jersey
  • application server — tomcat 7
  • database — MongoDB (NoSQL)
  • cache system — memcached

Как это было, или через тернии к high load

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js