Как стать автором
Обновить
40
0
Василий Пантюхин @Hen

Архитектор в AWS

Отправить сообщение

Миллион распределенных баз данных в облаке

Время на прочтение13 мин
Количество просмотров3.9K

Помните детскую забаву? Поставить швабру на ладонь и удержать ее в вертикальном положении как можно дольше? В теории управления она известна под именем обратного маятника. Есть палка с грузом на конце и тележка, которая должна удерживать этот маятник в вертикальном положении. 

Это отличная аналогия для современных облачных сервисов. Палка с грузом — это Data Plane сервиса. На русский язык этот термин можно перевести как “уровень передачи и обработки данных”. Тележка — Control Plane или “уровень управления”.  Основная задача Control Plane заключается в обеспечении стабильной работы Data Plane. То есть нужно балансировать так, чтобы Data Plane всегда был в вертикальном, работоспособном состоянии. Это не просто — любые задержки и сбои в Control Plane неминуемо приведут к тому, что Data Plane “упадет”. Василий Пантюхин, архитектор AWS, поделится примером того, как нетривиальную задачу по стабилизации сервисов решают в облаке Amazon.

Читать далее
Всего голосов 16: ↑15 и ↓1+14
Комментарии5

Закупки как сервис

Время на прочтение11 мин
Количество просмотров4.7K

Всем привет!

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

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

Пусть это будет Максми Поташёв Александр Друзь.

Почему? потому что чаще всего я по работе отвечаю на три простых вопроса:

Что из оборудования или софта было заказано в текущему/прошлом месяце/квартале? Что ещё можно/нужно заказать в этом квартале, чтобы уложиться в бюджет?
Где деньги сейчас находится заказанное оборудование? А что есть на складе?
Когда приедет/будет оплачено то, что заказали?

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

Зачем инженеру заниматься закупками?
Всего голосов 23: ↑22 и ↓1+21
Комментарии9

Программист учится рисовать. Дневник Емели

Время на прочтение16 мин
Количество просмотров34K
Так получилось, что моим основным хобби на лихой 2020-й год стало освоение ремесла рисования.

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

spoiler
В конце года я остался доволен собой и окончательно понял, что я хотел бы прокачиваться и дальше!

image
Так выглядел мой уровень изобразительных навыков в ноябре предыдущего (2019-го) года

Формат подачи данной статьи — это на 95% личный дневник, который я вел в гугл-доке, записывая, что я делал каждый месяц, свои ощущения и как-то фиксируя собственный прогресс — смотрел, сколько работ мне удалось нарисовать и какого они были качества — нравились ли они мне лично или были совсем так себе по исполнению.
Читать дальше →
Всего голосов 144: ↑143 и ↓1+142
Комментарии123

Олды в ИТ

Время на прочтение18 мин
Количество просмотров89K

Когда ты молод, ты «бессмертен» и не задумываешься о старости. Есть просто уверенность, что если много и хорошо работать, то твоя карьера и доходы будут неуклонно расти. Следуя этой стратегии, ты развиваешься в профессии уже 15, 20, 30 лет. За эти годы уже получил огромный опыт и, наверное, он обязательно поможет безбедно и интересно прожить остаток дней. Но все не так просто. Да, ты уже давно работаешь в хорошей компании, занимаешься интересными проектами, получаешь за это достойную зарплату, но в будущем уже не так уверен, как раньше. Профессиональный возраст приходит с массой вопросов, на которые нужно ответь стратегически.

 Эта статья родилась на основе обсуждения горячей темы «Олды в ИТ», которую 4 января 2021 г. мы записали для подкаста Linkmeup. Обязательно послушайте запись здесь или в любимом подкаст-приложении.

Читать далее
Всего голосов 188: ↑181 и ↓7+174
Комментарии435

Невыдуманные истории про сеть: как я учил физику на своих и чужих ошибках

Время на прочтение7 мин
Количество просмотров22K
Привет, Хабр! Меня зовут Антон Клочков, я сетевой архитектор в компании DataLine, а также участник проекта linkmeup. Я занимаюсь сетями более 10 лет и за это время успел поработать в больших и маленьких телеком-операторах, крупных корпорациях и небольших бизнесах. 

На практике я не раз убеждался, что физика упряма и обязательно отомстит за попытки пренебречь ее законами. За ошибки в физике сети я расплачивался квартальными премиями, исправлением косяков по ночам и «любовью» пользователей.  Зато такая школа жизни запоминается раз и навсегда.

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



Дисклеймер: в статье собраны истории из моего опыта в больших и малых энтерпрайзах и операторах связи. Многие из них случились со мной или коллегами еще на заре карьеры. Большинство персонажей — собирательные образы, любые совпадения случайны. Мое мнение может не совпадать с мнением компании DataLine.
Читать дальше →
Всего голосов 58: ↑57 и ↓1+56
Комментарии64

Хьюстон, у нас проблема. Дизайн систем на отказ

Время на прочтение15 мин
Количество просмотров7.7K
В 1970 г. американские инженеры запустили аппарат Аполлон-13 к Луне. На борту три батареи топливных элементов, беспокоиться не о чем, всё надежно и многократно продублировано. Но никто не мог предположить, что взрыв кислородного баллона выведет из строя две батареи из трёх. Трагедия! Астронавты вернулись домой, о событии сняли художественный фильм с Томом Хэнксом, а фраза астронавта Джека Свигерта: «Хьюстон, у нас проблема!», вошла в историю.



История Аполлона-13 это еще одно доказательство известного факта, что нельзя подготовиться ко всем возможным неприятностям. Это естественное свойство окружающего мира: железо периодически ломается, код сбоит, а люди ошибаются. Полностью исключить это невозможно.

Для больших распределенных систем такое поведение нормально, это следствие эффекта масштаба и статистики. Именно поэтому Design for Failure (дизайн на отказ) — базовый принцип проектирования облачных сервисов AWS. Системы изначально строятся так, чтобы максимально быстро восстановить штатную работу и минимизировать ущерб от известных и ещё неизвестных сбоев. На HighLoad++ Василий Пантюхин на примерах реальных проблем с боевыми сервисами показал паттерны проектирования распределенных систем, которые используют разработчики AWS.
Всего голосов 21: ↑21 и ↓0+21
Комментарии1

Hadoop: что, где и зачем

Время на прочтение14 мин
Количество просмотров459K


Развеиваем страхи, ликвидируем безграмотность и уничтожаем мифы про железнорождённого слона. Под катом обзор экосистемы Hadoop-а, тенденции развития и немного личного мнения.
Читать дальше →
Всего голосов 61: ↑58 и ↓3+55
Комментарии26

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

Время на прочтение9 мин
Количество просмотров8.7K
Масштаб сети 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.
Читать дальше →
Всего голосов 20: ↑19 и ↓1+18
Комментарии10

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

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



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

Мал, да удал. Анбоксинг микровиртуалки Firecracker

Время на прочтение11 мин
Количество просмотров12K
Записывайте рецепт микровиртуалок Firecracker. Берем два популярных метода изоляции многопользовательской нагрузки — виртуальные машины и контейнеры. Выжимаем лучшее из обоих подходов, максимально упрощаем, тестируем на настоящем хайлоаде. В итоге получаем непробиваемую изоляцию виртуалок, которые можно запускать за сотни миллисекунд. Именно это решение работает под капотом AWS Lambda и Fargate, запуская в облаке миллионы serverless-функций и контейнеров каждую секунду. Оно называется Firecracker.



Этот инструмент микровиртуализации доступен в OpenSource. Если ваши задачи требуют мульти-тенантной изоляции, (ну, например, вы решили сделать собственное облако), Firecracker — это то, что надо.

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

Дисклеймер: всё, что ниже — это личное мнение Василия, и оно может не совпадать с позицией Amazon Web Services.
Всего голосов 37: ↑35 и ↓2+33
Комментарии3

Информация

В рейтинге
Не участвует
Откуда
None, Люксембург
Зарегистрирован
Активность