Рубрика «AWS»

Наступает эпоха ARM-серверов? - 1


Материнcкая плата SynQuacer E-Series для 24-ядерного ARM-сервера на процессоре ARM Cortex A53 с 32 ГБ оперативной памяти, декабрь 2018 года

Много лет процессоры ARM с сокращённым набором команд (RISC) доминируют на рынке мобильных устройств. Но им так и не удалось пробиться в дата-центры, где по-прежнему властвуют Intel и AMD с набором инструкций x86. Периодически появляются отдельные экзотические решения, такие как 24-ядерный ARM-сервер на платформе Banana Pi, но серьёзных предложений пока нет. Точнее, не было до этой недели.

На этой неделе AWS запустила в облаке собственные 64-ядерные ARM-процессоры Graviton2 — это система-на-кристалле с ядром ARM Neoverse N1. Компания утверждает, что Graviton2 намного быстрее, чем ARM-процессоры предыдущего поколения в инстансах EC2 A1, а вот и первые независимые тесты.
Читать полностью »

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

«Kubernetes увеличил задержку в 10 раз»: кто же в этом виноват? - 1

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

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

image

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

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

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

Представлять инфраструктуру в виде кода в повторяемом текстовом формате — простая лучшая практика для систем, с которой не нужно мышевозить. За этой практикой закрепилось название — Infrastructure as Code, и пока что для ее осуществления, особенно в AWS, есть два популярных инструмента: Terraform и CloudFormation.

Перешел с Terraform на CloudFormation — и пожалел - 1
Сравниваю опыт работы с Terraform и CloudFormation

До прихода в Twitch (он же Amazon Jr.) я трудился в одном стартапе и года три использовал Terraform. На новом месте я тоже вовсю использовал Terraform, а потом компания продавила переход на все а-ля Amazon, включая CloudFormation. Я усердно разрабатывал лучшие практики и для того, и для другого, и оба инструмента использовал в очень сложных рабочих процессах в масштабах организации. Позднее, вдумчиво взвесив последствия перехода с Terraform на CloudFormation, я убедился, что Terraform, наверное, — лучший выбор для организации.

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

AWS Elasticsearch: фундаментально дефектный продукт - 1

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

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

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

Как AWS «варит» свои эластичные сервисы. Масштабирование серверов и базы данных - 1

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

Amazon EKS Windows в GA с багами, но зато быстрее всех - 1

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

Тема DevOps и IaC очень популярна и развивается быстро. Однако большинство авторов касаются сугубо технических проблем на этом пути. Я же опишу проблемы, характерные для большой компании. Решения у меня нет — проблемы, в общем, фатальны и лежат в области бюрократии, аудита, и «soft skills».

Песнь льда (кровавый Enterprise) и пламени (DevOps и IaC) - 1

Раз название статьи такое, то в качестве котика выступит Дайнерис, перешедшая на сторону Enterprise
Читать полностью »

Написанной мной инструмент командной строки 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

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

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

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

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

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


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