Amazon Web Services *

Прим. перев.: Эта статья, написанная Galo Navarro, что занимает должность Principal Software Engineer в европейской компании Adevinta, — увлекательное и поучительное «расследование» в области эксплуатации инфраструктуры. Её оригинальное название было немного дополнено в переводе по причине, которую объясняет автор в самом начале.



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

Пару недель назад моя команда занималась миграцией одного микросервиса на основную платформу, включающую CI/CD, рабочую среду на основе Kubernetes, метрики и другие полезности. Переезд носил пробный характер: мы планировали взять его за основу и перенести еще примерно 150 сервисов в ближайшие месяцы. Все они отвечают за работу некоторых из крупнейших онлайн-площадок Испании (Infojobs, Fotocasa и др.).

29-30 октября в Санкт-Петербурге прошла конференция DevOops. В этой статье я поделюсь впечатлениями и инсайтами, а также краткими заметками о прослушанных докладах. Небольшой disclaimer: поскольку я разработчик, то некоторые мысли и комментарии могут быть с уклоном в Dev, нежели в Ops, но я постараюсь быть как можно объективнее.

DevOops входит в число мероприятий, которые проводит JUG Ru Group. И нужно признать, организация и уровень докладов были на уровне. Конференция длилась два дня, в три потока. Помимо этого, были дискуссионные зоны для общения со спикерами, мастер-классы, а также lightning talks — более лёгкие и короткие доклады, в том числе для тех, кто ранее не выступал и хочет попробовать себя в качестве спикера.

Тематическая канва DevOops 2019 — cloud native. Бо́льшая часть докладов была прямо или косвенно посвящена облакам. Тема давно уже не новая, однако есть множество неочевидных сложностей, которые возникают в процессе использования облачных технологий. И многие пришли специально, чтобы найти ответы. Это было особенно заметно на QA-сессиях после докладов. Спикерам задавали практические вопросы, которые действительно волнуют людей. Почти на каждый вопрос следовали реплики других участников «У нас такая же проблема!» и начиналась оживлённая дискуссия.

Юрий Дзюбан, разработчик программного обеспечения, более семи лет назад переехал работать в Польшу, а после этого релоцировался в Германию по предложению от Scalors. Сейчас он уже около полугода занимает должность Java Middle программиста в компании Amazon, в Мюнхене.



— Откуда ты? Где учился и с чего начал карьеру?

— Я родом из Запорожья. Закончил магистратуру в КПИ, факультет ФИОТ. Любовь к компьютерным играм в пятом классе повлияла на мой выбор профессии. Мне казалось, что вся разработка сводится к написанию компьютерных игр. Уже будучи немного старше, пришло осознание насколько широка эта область, и как далеко переходит за границы написания игр. Частично также повлияла сестра, которая первой начала протаптывать этот путь.

Перевод статьи Nick Price

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

Масштаб сети Amazon Web Services — это 69 зон по всему миру в 22 регионах: США, Европа, Азия, Африка и Австралия. В каждой зоне находится до 8 ЦОД — Центров Обработки Данных. В каждом ЦОД тысячи или сотни тысяч серверов. Сеть построена так, что все маловероятные сценарии перебоев в работе принимаются в расчет. Например, все регионы изолированы друг от друга, а зоны доступности разнесены на расстояния в несколько километров. Даже если перерубить кабель, то система перейдет на резервные каналы, а потери информации составят единицы пакетов данных. О том, на каких еще принципах построена сеть и как она устроена, расскажет Василий Пантюхин.



Василий Пантюхин начинал Unix-админом в .ru-компаниях, 6 лет занимался большими железками Sun Microsystem, 11 лет проповедовал дата-центричность мира в EMC. Естественным путем эволюционировал в приватные облака, потом подался в публичные. Сейчас, как архитектор Amazon Web Services, техническими советами помогает жить и развиваться в облаке AWS.

В предыдущей части трилогии об устройстве AWS Василий углубился в устройство физических серверов и масштабирование базы данных. Nitro-карты, кастомный гипервизор на базе KVM, база данных Amazon Aurora — обо всем этом в материале «Как AWS «варит» свои эластичные сервисы. Масштабирование серверов и базы данных». Прочитайте, чтобы погрузиться в контекст, или посмотрите видеозапись выступления.

В этой части речь пойдет о масштабировании сети — одной из сложнейших систем в AWS. Эволюция от плоской сети к Virtual Private Cloud и ее устройство, внутренние сервисы Blackfoot и HyperPlane, проблема шумного соседа, а в конце — масштабы сети, backbone и физические кабели. Обо всем этом под катом.

Дисклеймер: всё, что ниже — личное мнение Василия, и оно может не совпадать с позицией Amazon Web Services.

В конце августа Imperva оповестила клиентов сервиса Cloud WAF (бывш. Incapsula) об утечке конфиденциальной информации и инициировала сброс паролей учетных записей. Оказалось, что посторонние получили доступ к хешам паролей, ключам API и SSL-сертификатам.

10 октября исполнительный директор компании Крис Хайлен (Chris Hylen) и технический директор Кунаи Ананд (Kunal Anand) изложили post mortem с деталями инцидента. Как такое могло произойти у компании, которая специализируется на защите данных и приложений?

Если резюмировать, проблема возникла из-за некорректной миграции БД с собственного хостинга на Amazon Web Services.

В своем сообщении Крис Хайлен перечисляет ряд ошибок, сделанных во время миграции. Все вместе, они позволили неизвестным украсть админский ключ API к одному из аккаунтов в продакшне на Amazon Web Services. Расследование показало, что неавторизованный доступ произошёл ещё в октябре 2018 года.

Админский ключ дал злоумышленнику доступ к снимку БД с различными сведениями о клиентах, которые зарегистрировались до 15 сентября 2017 года. Информация включала адреса электронной почты, хэшированные и солёные пароли, а для некоторого количества клиентов — ключи API и предоставленные клиентами SSL-сертификаты.

Начать разбираться с IoT (Internet of Things) платформами меня останавливало отсутствие IoT устройства, которое было бы совместимо по протоколам и способам доступа. Но когда я понял, что в качестве устройства можно использовать обыкновенный смартфон, то реализация работающей цепочки заняла один день.

Возьмем смартфон, который будет эмулировать IoT устройство c датчиками температуры, влажности и давления и отсылать показания на Amazon IoT платформу. На платформе заведем правило, которое при поступлении данных от нашего устройства будет вызывать сервис нотификаций, который в свою очередь будет отсылать e-mail с полученными данными.

Такая система, конечно, несет мало практической ценности, но позволяет разобраться, как все устроено:



Почему именно IoT платформа от Amazon? И зачем вообще нужно понимать, как работают IoT платформы?

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



Облако AWS это мегасуперсложная система, которая эволюционно развивается с 2006 года. Часть этого развития застал Василий Пантюхин — архитектор Amazon Web Services. Как архитектор он видит изнутри не только конечный результат, но и сложности, которые преодолевает AWS. Чем больше понимания работы системы, тем больше доверия. Поэтому Василий поделится секретами облачных сервисов AWS. Под катом устройство физических серверов AWS, эластичная масштабируемость БД, кастомная база данных Amazon и методы повышения производительности виртуальных машин с одновременным уменьшением их цены. Знание архитектурных подходов Amazon поможет эффективнее использовать сервисы AWS и, возможно, даст новые идеи по построению собственных решений.

Добрый день, хочу поделиться с вами своим опытом по настройке и использованию сервиса AWS EKS (Elastic Kubernetes Service) для Windows контейнеров, а точнее о невозможности его использования, и найденном баге в системном контейнере AWS, тем кому интересен этот сервис для Windows контейнеров, просьба под кат.

Начинайте с простого, но не в ущерб дальнейшему росту.



Начав свою карьеру как инженер-программист, впоследствии я стал технологическим предпринимателем и основал две SaaS компании, которые привлекли более 100 миллионов долларов венчурного капитала Силиконовой долины.

Проблема заключалась в том, что эти компании требовали огромных вложений, для того чтобы создать сложные, мультитенантные программные системы, которыми они являлись, которые к тому же требовали, чтобы специалисты по продажам и внедрению постоянно продвигали и поддерживали их работу. Поэтому в 2017 году я основал 8base.

Написанной мной инструмент командной строки Sloc Cloc and Code (scc), который теперь доработан и поддерживается многими отличными людьми, подсчитывает строки кода, комментарии и оценивает сложность файлов внутри каталога. Здесь нужна хорошая выборка. Инструмент подсчитывает в коде операторы ветвления. Но что такое сложность? Например, заявление «У этого файла сложность 10» не очень полезно без контекста. Чтобы решить эту проблему, я запустил scc на всех исходниках в интернете. Это также позволит найти какие-то крайние случаи, которые я не рассматривал в самом инструменте. Мощное испытание методом грубой силы.

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

Короче говоря, я загрузил и обработал много исходников.

Голые цифры:

• 9 985 051 репозиториев всего
  
• 9 100 083 репозитория хотя бы с одним файлом
  
• 884 968 пустых репозиториев (без файлов)
  
• 3 500 000 000 файлов во всех репозиториях
  
• Обработано 40 736 530 379 778 байт (40 ТБ)
  
• Идентифицировано 1 086 723 618 560 строк
  
• Распознано 816 822 273 469 строк с кодом
  
• 124 382 152 510 пустых строк
  
• 145 519 192 581 строк комментариев
  
• Общая сложность по правилам scc: 71 884 867 919
  
• 2 новые ошибки, найденные в scc

У нас было 4 Amazon-аккаунта, 9 VPC и 30 мощнейших девелоперских окружений, стейджей, регрессий — всего более 1000 EC2 instance всех цветов и оттенков. Раз уж начал коллекционировать облачные решения для бизнеса, то надо идти в своем увлечении до конца и продумать, как все это автоматизировать.

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

Статья длинная, поэтому запаситесь попкорном чаем и вперед!

И еще один нюанс — статья писалась на основе версии 0.11, в свежей 0.12 многое изменилось но основные практики и советы по прежнему актуальны. Вопрос миграции с 0.11 на 0.12 заслуживает отдельной статьи!

Публикуем любые сервисы, расположенные в домашнем гипервизоре через сервис EC2 Amazon Web Services через бесплатный инстанс под Amazon Linux AMI 2018 с помощью libreswan, xl2tpd и с небольшой толикой извращения…

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

Текущая конфигурация

CardGames.io работает на AWS. Все html-страницы, CSS, JavaScript и изображения хранятся на S3. У нас есть API на C#, размещённый на Elastic Beanstalk, он работает на серверах Linux под управлением .NET Core с Docker. Наконец, мы используем CloudFront CDN перед статикой на S3 и API. Ниже приведён счёт EC2 за август 2019 года. У нас есть несколько других инстансов, но API работают на m1.small (да, вероятно, t2.small лучше подходит) с классической балансировкой нагрузки. Если суммировать выделенное красным, то выходит $164,21 в месяц, неплохо. Я даже включил туда EBS, поскольку не уверен, как разбить эти расходы, у нас ведь несколько проектов на EC2.

Привет, Хабр! Представляю вашему вниманию перевод статьи «How to reduce your AWS costs? Save up to $500k with these guidelines!» автора George Batschinski.



В этой статье мы в подробностях расскажем, как Back4App уменьшила свои расходы в AWS с $55,492 в месяц до $20,074 в месяц и сэкономила $500.000 за год. Мы опишем практические шаги, основанные на собственном опыте снижения затрат в AWS и поделимся советами, которые были полезны и нам.

Поисковая выдача на ListenNotes.com

Listen Notes — это поисковая система и база данных подкастов. Технология на самом деле очень скучная. Никакого ИИ, глубокого обучения или блокчейна. «Если вы должны объявлять о внедрении ИИ, то вы не используете Настоящий ИИ» :)

После прочтения этой статьи вы сможете повторить мой проект или легко сделать нечто подобное. Не придётся нанимать много разработчиков. Помните, когда Instagram привлёк $57,5 млн и отошёл к Facebook за $1 млрд, у них было всего 13 сотрудников — и это не только разработчики. Покупка Instagram произошла в начале 2012-го. Сейчас 2019 год, и сегодня как никогда просто создать что-то значимое с крошечной инженерной командой — даже из одного человека.

Перевод статьи подготовлен специально для студентов курса «Облачные сервисы». Интересно развиваться в данном направлении? Смотрите мастер-класс Егора Зуева (TeamLead в компании InBit) «AWS EC2 сервис» и присоединяйтесь к ближайшей группе курса: старт 26 сентября.

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

Глаза боятся, а руки чешутся!

В прошлых статьях мы разобрались с технологиями, на которых строятся блокчейны (Что нам стоит блокчейн построить?) и кейсами, которые можно с их помощью реализовать (Что нам стоит кейс построить?). Настало время поработать руками! Для реализации пилотов и PoC (Proof of Concept) я предпочитаю использовать облака, т.к. к ним есть доступ из любой точки мира и, зачастую, не надо тратить время на нудную установку окружения, т.к. есть предустановленные конфигурации. Итак, давайте сделаем что-нибудь простое, например, сеть для перевода монет между участниками и назовем ее скромно Сitcoin. Для этого будем использовать облако IBM и универсальный блокчейн Hyperledger Fabric. Для начала разберемся, почему Hyperledger Fabric называют универсальным блокчейном?

Запись об этом появилась в блоге AWS в начале августа. Эталонная реализация выложена на GitHub.

Почему это важно?

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

19 июля 2019 года банк Capital One получил сообщение, которого боится каждая современная компания — произошла утечка данных. Она затронула более 106 миллионов человек. 140 000 номеров социального страхования США, один миллион номеров социального страхования Канады. 80 000 банковских счетов. Неприятно, согласитесь?

К сожалению, взлом произошёл совсем не 19 июля. Как выяснилось, Пейдж Томпсон, она же Erratic, совершила его между 22 марта и 23 марта 2019 года. То есть почти четыре месяца назад. На самом деле, только с помощью внешних консультантов Capital One сумела узнать, что нечто произошло.