Amazon Web Services *

Внимание — это фривольный перевод заметки о том, как именно Jonathan Bouman нашёл публичный AWS S3, который использовался на одном из поддоменнов apple.com. Плюс заметка хороша тем, что наглядно демонстрирует пользу от нескольких маленьких утилит в совокупности с терпением.

Вчера компания Amazon Web Services объявила о полноценном запуске своего облачного сервиса на базе Kubernetes — EKS (Amazon Elastic Container Service for Kubernetes). Впервые он был анонсирован в ноябре прошлого года (вскоре после того, как AWS присоединилась к стоящему за Kubernetes фонду CNCF), но тогда он имел статус предварительного доступа. Что скрывается за EKS?

Не один раз я пробовал использовать сторонние API для получения голоса из текста который мне интересно прочитать — можно переключить чтение на уши когда глаза устали, или слушать во время комьюта. Знаю я такой не один, даже люди далекие от айти бывает загружают куда-то текст и скачивают mp3. И подкасты/аудиокниги становятся все популярнее, и голосовые интерфейсы. Очевидно что аудитория есть, топовые экстеншены в маркете Хрома на эту тематику имеют сотни тысяч пользователей. Но голоса от Амазона обычно у них нет (лучший из доступных, лучше нового от Гугла), а где есть нет чего-то другого, например возможности слушать в экстеншене — а не только добавлять в свой подкаст. Предложил идею проекта внутри компании — был получен апрув — пошла разработка.

Здравствуйте уважаемые пользователи Хабра!

Меня зовут Никита, в текущий момент времени я тружусь backend-разработчиком в стартапе мобильного приложения. Наконец у меня появилась действительно нетривиальная и достаточно интересная задача решением которой хочу поделиться с Вами.

О чем собственно пойдет разговор? В разрабатываемом мобильном приложении имеется работа с изображениями. Как можно нетрудно догадаться: где есть картинки, там скорее всего появятся превьюхи. Еще одно условие, практически первая общая задача которая была мне поставлена: сделать чтобы все это работало и масштабировалось в облаке на Амазоне. Если немного лирики: был телефонный разговор со знакомым партнера по бизнесу в режиме громкой связи, где я получил пачку ценных указаний главная мысль которых звучит просто: уходите от серверного мышления. Ну ок, уходим так уходим.

Генерация изображений это достаточно дорогая операция в плане ресурсов. Этот участок бэкэнда предсказуемо плохо показал себя на таком, своего рода «нагрузочном тестировании», которое я проводил на очень дохлой VDS-ке при практически дефолтных настройках LAMP, по крайней мере без дополнительного тюнинга, где все неоптимизированные места вылезут сразу и гарантированно. По этой причине я принял решение данную задачу убрать подальше от пхп-бэкэнда. Пусть он занимается тем что дает более-менее однородную нагрузку, а именно запросы к БД, логика приложения и JSON-ответы и тому подобная малоинтересная API-шная рутина. Те, кто знаком с Амазоном скажут: а в чем проблема? Почему нельзя настроить масштабирование EC2 инстансов в автоматическом режиме и оставить на PHP эту задачу? Отвечаю: «так микросервиснее». А если серьезно — есть масса нюансов в контексте архитектуры бэкэнда, выходящих за пределы данной статьи, по этому оставлю данный вопрос без ответа. Каждый на него ответит сам в контексте своей архитектуры, если он возникнет. Я всего лишь хочу предложить решение и милости прошу под кат.

Netflix уменьшил время аварийного переключения с 45 до 7 минут без каких-либо затрат

Изображение: Florida Memory. Доработано Opensource.com. CC BY-SA 4.0

Зимой 2012 года Netflix пережил длительный сбой, уйдя в отключку на семь часов из-за проблем с сервисом AWS Elastic Load Balancer в регионе US-East (Netflix работает на AWS — у нас нет собственных дата-центров. Всё ваше взаимодействие с Netflix происходит через AWS, кроме самого потокового видео. Как только вы нажмете Play, начинает загружаться видеопоток из нашей собственной сети CDN). Во время сбоя ни один пакет из региона US-East не доходил до наших серверов.

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

Spot-инстансы — это по сути продажа свободных в данный момент ресурсов со отличной скидкой. При этом инстанс могут в любой момент выключить и забрать обратно. В статье я расскажу о особенностях и практике работы с этим предложением от AWS.

В предыдущей статье я описала как создать простую лямбду на Golang, которая принимает на вход простой объект из двух полей и такой же простой объект отдает на выходе. Теперь немного усложним задачу, подсоединив к лямбде в качестве источника данных Kinesis, а результат обработки записей Kinesis мы будем перекидывать в CloudSearch. Никакой особенной логики в лямбде не будет для упрощения: просто примем запросы от Kinesis, залогируем их в CloudWatch, преобразуем и отправим в CloudSearch.

В середине января этого года Амазон анонсировал поддержку Go в своих лямбдах.
Отличная новость, но сейчас я пишу эти строки, не имея никакого опыта написания кода на Golang, чтобы, проходя через пеньки и ухабы параллельно с написанием статьи, прийти к первой своей работающей лямбде на Go.

Наверняка не все знают, что по нагрузке и числу пользователей iFunny является настоящим highload-сервисом. API обслуживает в пиках порядка 15000 запросов в секунду, система аналитики обрабатывает около 5 миллиардов событий в сутки, а для поддержки полного функционала работает до 400 инстансов EC2. Поэтому для приложения очень важно иметь сильную команду инженеров. Чтобы решать типичные проблемы высоконагруженных систем и улучшать свою работу каждый день, команда iFunny постоянно ищет новые инструменты и решения. И в этот раз невозможно было пройти мимо интервью одного из основных контрибьюторов мирового IT-сообщества — Келси Хайтауэра. Достойно перевода и вашего внимания.

Всем привет! Первый митап в России по технологии Serverless пройдет 1-ого марта в Rambler&Co. Мы поговорим о том, что такое Serverless и почему появился этот подход, а также рассмотрим два практических кейса: построение аналитической системы для мобильного приложения и сбор данных с систем умного дома.

Произошло, пожалуй, самое крупное падение сервиса Битрикс24 за свою историю.В общей сложности на протяжении 3 дней у пользователей Российского сегмента возникали трудности с доступностью www.bitrix24.ru, www.bitrix24.by и www.bitrix24.kz Общее количество зарегистрированных в сервисе компаний составляет около 3 000 000.

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

Самые известные на мировом рынке объектные хранилища — это Amazon S3 (Simple Storage Service), Google Cloud Storage и Microsoft Blobs Storage. Они надежны, доступны через интернет и масштабируются до сотен петабайт. Наиболее популярный способ доступа к объектному хранилищу — S3 RESTful API от компании Amazon. Есть и альтернатива, OpenStack Swift — поддерживает оба API и даже имеет собственное (как у Microsoft или Google, например). Дополнительно предоставляется доступ по другим файловым и блочным протоколам вроде WebDAV, NFS и FTP, но в контексте этой статьи мы тестируем только доступ по протоколу HTTPS через разнообразные API.

Для сравнения возьмем отечественные публичные объектные хранилища. Их не так много, и мы рассмотрим наиболее заметных игроков российского рынка: Mail.Ru Cloud Solutions, servers.ru, Selectel, Техносерв и Ростелеком.

Все мы знаем, как важен SWAP. И как без него бывает плохо. Особенно когда ОЗУ не так много, а на сервере появился "прожорливый" процесс. Да и дискового пространства впритык на сервере. А работоспособность нужно восстановить прямо сейчас...

В данной статье хочу рассмотреть способы добавления SWAP на AWS EC2 серверах "на горячую", без перезагрузки сервера.

Интересно верит ли кто-либо еще что работу разработчика можно измерить количеством строк кода? Попробуем вместе развенчать этот старый, как мир, миф своими красными глазами.


Сложно ли изменить две строчки кода?

Одним из самых необычных проектов нашего осеннего хакатона был Skyeng Haiku: медитативное мультимедийное приложение про сбор слов в строчки. Сегодня его авторы расскажут, что это, зачем оно нужно, почему полезно, как они его сделали, ну и дадут ссылку на рабочую версию.

Всем привет! В этом посте я хочу сделать краткий обзор некоторых плагинов SparrowHub — репозитария пользовательских скриптов для выполнения различных задач. Данные плагины могут быть полезны тому, кто просто хочет запустить с консоли готовые утилиты и решить свою задачу, фактически, не написав ни строчки кода.

Добавление новых плагинов происходит постоянно, если вас заинтересовал проект, вы можете легко и просто добавить свои плагины, поделившись полезными скриптами с сообществом.

Недавно мы рассказали о способах, с помощью которых сэкономили более миллиона долларов на годовом обслуживании AWS. Хотя мы подробно рассказывали о различных проблемах и решениях, всё равно самым популярным вопросом был: «Я знаю, что слишком много трачу на AWS, но как в реальности разбить эти траты на понятные части?»

На первый взгляд, проблема кажется довольно простой.

Вы можете легко разбить свои расходы AWS по месяцам и закончить на этом. Десять тысяч долларов на EC2, одна тысяча на S3, пятьсот долларов на сетевой трафик и т.д. Но здесь отсутствует кое-что важное — на сочетание каких именно продуктов и групп разработки приходится львиная доля расходов.

И учтите, что у вас могут меняться сотни инстансов и миллионы контейнеров. Вскоре то, что поначалу казалось простой аналитической проблемой, становится невообразимо сложным.

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

Пост рассказывает о моем неудачном тесте производительности, а также показывает пару неправильных цифр производительности ARDB c встраиваемой БД LMDB в Amazon EC2 контейнерах.

В конце лета нам пришло сообщение от Google о том, что в Chrome будут появляться предупреждения о возможной опасности при переходе на наш сайт «Я люблю ИП». Это касалось страниц, где есть текстовые формы (<input type="text"> или <input type="email">). Изменения должны были вступить в силу с октября, и мы решили, что наконец пора осуществить переезд на HTTPS, который мы планировали уже давно.

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

Итак, вот краткое содержание статьи:

1) Подготовка сайта к переезду
2) Бесплатный SSL-сертификат от Amazon
3) Установка сертификата
4) Настройка домена
5) Редирект для домена на HTTPS без www
6) Рекомендации по SEO

Здравствуй, уважаемый %user%. Сегодня я расскажу о том, как я написал простую систему позволяющую получать конфигурацию компьютеров и информацию о том, кто залогинился на компьютерах на работе, и как я перенес ее на Amazon AWS, сделав сервис для общего пользования. Данную статью так же можно считать отчасти подробным руководством о том как поднять свой веб сервер, почту, рассылку писем и правильно настроить его на Amazon AWS. И да эту статью можно отнести к категории – я пиарюсь. Кому стало интересно добро пожаловать под кат. Осторожно будет очень много скриншотов.