Расскажу, как мы в PayPal начинали осваивать Kubernetes. На тот момент большинство наших рабочих нагрузок выполнялось на Apache Mesos, и в рамках этой миграции нам требовалось разобраться с некоторыми аспектами производительности у кластеров, в которых будет работать Kubernetes – с учётом той плоскости управления, что действует в PayPal. Из всех этих аспектов важнее всего было понять, как именно масштабируется платформа, а также выявить, как можно было бы улучшить масштабируемость, настраивая параметры кластера.

Тогда как Apache Mesos может прямо из коробки масштабироваться вплоть до 10 000 узлов, масштабировать Kubernetes непросто. При масштабировании Kubernetes требуется учитывать не только количество узлов и подов, но и ещё некоторые вещи, в частности: сколько ресурсов создано, сколько у нас контейнеров на под, сколько всего сервисов задействовано, а также пропускная способность при развёртывании подов. В этом посте описаны некоторые проблемы, с которыми нам довелось столкнуться при масштабировании, и рассказано, как нам удалось с ними справиться.

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

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

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

Но в опенсорсном пространстве есть решение, разработанное в опенсорсе. В сочетании друг с другом Apache Kafka, Flink и Druid, позволяют создать архитектуру для обработки данных, которая работает в режиме реального времени и позволяет исключить все эти этапы ожидания. В этом посте мы исследуем, как комбинация этих инструментов позволяет создавать широкий спектр приложений для обработки данных в режиме реального времени.

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

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

Многие из тех, кто устанавливает дистрибутив Linux для одной-единственной цели, например, для работы с контейнерами, предпочитают развёртывание по принципу «поставил и забыл». На конференции FOSDEM 2023, состоявшейся в Брюсселе, было представлено несколько проектов из разряда таких «минимальных дистрибутивов Linux». Все они — Fedora CoreOS, Ubuntu Core, openSUSE MicroOS и Bottlerocket OS – решают такие задачи по-своему. Из выступлений на FOSDEM можно составить интересную перспективу, демонстрирующую, в чём эти проекты отличаются на уровне применяемых подходов.

Один из самых естественных треков развития для программиста – стремиться стать программным архитектором. Проектирование систем – непростое дело, а для того, чтобы построить сложную систему, нужно как быть экспертом-технарём, так и обладать опытом в предметной области. На наработку этих навыков требуется немало времени и усилий. Читая книгу Марка Ричардса и Нила Форда «Фундаментальный подход к программной архитектуре», я нашёл у них метафору «архитектурных ката». В их трактовке ката – это отработка решения для элементарной задачи. Я решил опробовать подход с ката, чтобы прокачать мои навыки проектирования систем.

Не так давно я побывала на конференции Kubecon 2023 в Чикаго. Готовясь к конференции, я почитала статьи в блогах, а на самой конференции посетила несколько семинаров для начинающих (в жанре «101»). Но всё равно не могла сказать, что уверенно понимаю эту технологию. Хуже всего прошёл последний день конференции. Я решила добираться в отель на такси и вызвала Uber. И водитель спрашивает: «А о чём была конференция»? Я ему отвечаю: «О Kubernetes». Попыталась объяснить, но почти сразу поняла, что двух слов на эту тему связать не смогу.

Только представьте себе: уезжать с трёхдневной конференции, но быть не в силах рассказать таксисту о той технологии, которая на ней обсуждалась. Фейспалм. Поэтому теперь попытаюсь реабилитироваться и пофантазировать, как следовало бы рассказать о Kubernetes таксисту Uber.

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

Из каких соображений можно хранить данные в виде ячеистой сети

Во всех организациях, где мне доводилось работать, всегда понимали важность данных. Поэтому я видел, что руководство либо заинтересовано, либо прямо планирует создать платформу нового поколения для обращения с этими данными. Как правило, ставится цель перейти от сильно связанных интерфейсов и вариабельных потоков данных к целостной архитектуре, которая позволяла бы аккуратно связать всю экосистему. Речь идёт о распределённой облачной ячеистой топологии (data mesh), где данные можно группировать в зависимости от их предметной области, трактовать “данные как продукт,” организуя в каждой предметной области конвейерную обработку собственных данных. Такой подход отличается от перекачки данных (data plumbing), практикуемой на традиционных (монолитных) платформах, которые, как правило, отличаются сильной связанностью данных. Из-за этого зачастую замедляется поглощение, хранение, преобразование и потребление данных из централизованного озера или хаба.

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

Гексагональная архитектура — это архитектурный паттерн, представленный Алистером Кокберном и описанный у него в блоге в 2005 году. Основная идея заключается в том, чтобы структурировать приложение таким образом, чтобы это приложение можно было разрабатывать и тестировать в изоляции, не завися от внешних инструментов и технологий.

Вот как сам Кокберн описывает эту архитектуру одним тезисом:

Добиться, чтобы приложение в равной степени могло управляться пользователями, программами, автоматизированными тестовыми или пакетными сценариями, а также разрабатываться и тестироваться в изоляции от устройств и баз данных, на которых оно впоследствии будет выполняться. — Алистер Кокберн, 2005 г.

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

JavaScript — это мощный язык, который является частью фундамента интернета. У этого мощного языка также есть некоторые свои особенности. Например, знаете ли вы, что значение 0 === -0 равно true, или что Number("") дает 0?

Дело в том, что иногда эти причуды могут заставить вас почесать в затылке или даже задаться вопросом, был ли Брендан Эйч под кайфом в тот день, когда он изобретал JavaScript. Что ж, дело здесь не в том, что JavaScript — плохой язык программирования или он — зло, как говорят его критики. Со всеми языками программирования связаны какие-то странности, и JavaScript не является исключением.

В этом материале мы покажем подробное объяснение некоторых важных вопросов на интервью по JavaScript. Моя цель будет состоять в том, чтобы тщательно объяснить эти вопросы, чтобы мы могли понять лежащие в их основе концепции.

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

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

Объединим две эти цели – и обнаружим, сколько же существует странных и магических методов для неблокирующего совместного использования данных в разных потоках. Давайте поговорим об одном из этих методов – «чтение-копирование-запись» (RCU).

Terraform позволяет создать облачную инфраструктуру с помощью всего одной команды. Допустим, вы хотите запустить Elasticsearch и Kibana в кластере Kubernetes.

Для этого можно написать несколько файлов .tf и выполнить команду terraform apply для инициализации кластера Kubernetes и развёртывания на нем нескольких подсистем.



Теперь предположим, что вам нужны и другие экземпляры стека Elastic, которые можно использовать для демонстрации. В этом случае придется создать новые рабочие пространства Terraform и выполнить terraform apply несколько раз.

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



Гораздо лучшей альтернативой было бы повторное использование одного кластера Kubernetes и создание на его основе нескольких сред. Таким образом, вы платите за один кластер, и вам не нужно ждать создания нового кластера каждый раз, когда вы создаете новую среду.

Сигнал SIGSEGV, применяемый в Linux, означает нарушение сегментирования в рамках работающего процесса. Ошибки сегментирования возникают из-за того, что программа пытается обратиться к участку памяти, который пока не выделен. Это может произойти из-за бага, случайно вкравшегося в код, либо из-за того, что внутри системы происходит некая вредоносная активность.

Сигналы SIGSEGV возникают на уровне операционной системы, но столкнуться с ними также вполне можно и в контексте контейнерных технологий, например, Docker и Kubernetes. Когда контейнер завершает работу, выдав код возврата 139, дело именно в том, что он получил сигнал SIGSEGV. Операционная система завершает процесс контейнера, чтобы предохраниться от нарушения целостности памяти.

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

В этой статье будет объяснено, что представляют собой сигналы SIGSEGV, как они влияют на работу ваших контейнеров с Linux в Kubernetes. Также я подскажу, как отлаживать ошибки сегментации в вашем приложении, а если они возникают – как с ними справляться.

В нынешнюю эпоху пластика, силиконовых женщин и одноразовых вещей хочется чего-то надёжного и долговечного. Хочется привыкнуть к компьютеру, сделать его частью своей жизни, а может и семейной реликвией, которая достанется правнукам. Естественно, при возможности простого апгрейда компонентов.

Реально ли создать такой компьютер? Представьте, что после Апокалипсиса работающий ПК станет настоящим подарком для многих поколений одичавших потомков… А если жизнь пойдёт обычным порядком, всё равно приятно прикоснуться к такой реликвии через какие-нибудь 100 или 500 лет.

Существует три уровня понимания того, как работает SIMD (ну, по крайней мере, на данный момент я нахожусь на 3-м уровне):

1. Компиляторы умны! Они автоматически векторизуют весь код!
2. Компиляторы тупы, автоматическая векторизация хрупка, ее очень легко нарушить несвязанными изменениями в коде. Всегда лучше вручную написать конкретные инструкции SIMD.
3. Написать SIMD вручную действительно сложно — для каждой архитектуры процессора придется писать разный код. Кроме того, вы, вероятно, понимаете, что компилятор напишет на ассемблере скалярный код лучше вас. Что заставляет вас думать, что вы превзойдете компилятор в SIMD, где еще больше странных инструкций и запретов? Компиляторы — это инструменты. Они могут надежно векторизовать код, если он написан в форме, поддающейся векторизации.

Недавно я перешел со второго уровня на третий, и я заметил, как модель, используемая компилятором, щелкнула у меня в голове. В этом посте я хочу объяснить общую структуру компиляторов, пригодную для оптимизации статических языков, таких как Rust или C++. После этого я применю эту структуру к автоматической векторизации.

«Не вижу в человеческом интеллекте ничего такого, что бы человечество не могло бы понять».

Джон Маккарти — фигура, без преувеличения, легендарная. Создатель термина “искусственный интеллект”, основоположник функционального программирования и создатель языка LISP… Список можно продолжать долго.


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

Когда мы включаем компьютер, он успевает совершить несколько этапов работы ещё до того, как загрузится операционная система. В этом посте будет рассмотрено, как загружается типичный процессор с архитектурой x86. Это очень сложный и многоступенчатый процесс. Здесь его структура будет представлена только в самом общем виде. От загрузочной прошивки зависит, каким именно путём процессор придёт к тому состоянию, в котором сможет загрузить операционную систему. Мы проследим этот процесс на примере опенсорсной загрузочной прошивки coreboot.

Я немного изучил arm64 (aarch64) и решил: попробую написать для него код на голом железе.
Я хотел понять, проанализировать и тщательно рассмотреть машинный код, который выдают на моём MacBook Air M1 такие среды исполнения WebAssembly, как v8 или wasmtime. Для этого я (немного) изучил ассемблер arm64. Коллега Саул Кабрера порекомендовал мне почитать книгу Стивена Смита «Programming with 64-Bit ARM Assembly Language», и я могу только поддержать эту рекомендацию.


«Programming with 64-Bit ARM Assembly Language» by Stephen Smith, APress 2020

В книге отлично объясняется набор инструкций, приёмы оптимизации, а также действующие соглашения и интерфейсы ABI. Но с ней вы научитесь писать программы только под операционную систему. Я же люблю загружать с нуля мой собственный BBC Microbit или Rasperry Pi. В этом посте я набросал пару шагов, которые успел сделать в этом направлении.

В IT так: если что-то существует, то рано или поздно это будет существовать и в браузере. Сегодня так устроен мир. Благодаря работе Филипа Лассена, теперь вы можете гонять Futhark у себя в браузере. В данном посте рассказано, как этого удалось добиться, и почему этот функционал пока не так полезен, как мог бы (спойлер: пока не поддерживается работа с GPU), и какие есть перспективы этот функционал доработать. Подробно о том, как спроектирован этот язык, рассказано в магистерской диссертации Филипа.