Распределённые системы *

В прошлой статье я рассказал, как использование серверов времени (NTP и NTS) решает проблему манипуляцией временем транзакции в блокчейне Hyperledger Fabric (CVE-2024-45244). И к каким финансовым последствиям приводит атака на примере концепта вымышленного уязвимого смарт-контракта, имитирующего цифровой финансовый актив. Концепт-код для защиты от атаки был написан на Go. Поэтому он не применим для смарт-контрактов Hyperledger Fabric, написанных на других языках (Java, JavaScript, TypeScript). Поэтому, я решил сделать Оракул времени: смарт-контракт, который будет источником времени для других смарт-контрактов. Это позволит использовать оракул времени смарт-контрактами, написанными на других языках. Оракул времени доступен в исходном коде.
В этой статье убедимся, что оракул устойчив к атаке "человек посередине" (при использовании NTS). Для атаки будем использовать утилиты netsed (для подмены не зашифрованных данных) и mitmproxy (для подмены сертификата TLS). А также убедимся, что данные протокола NTP подменить возможно. Читатели, которые не знакомы с блокчейном Hyperledger Fabric, могут представить, что оракул времени - это некий API-сервис, возвращающий текущее время (посредник между клиентом и NTP/NTS сервером).

XML (часто с применением SOAP):

<order>
    <bookID>12345</bookID>
    <quantity>2</quantity>
    <user>JohnDoe</user>
</order>

Привет! Меня зовут Антон Васильев, я работаю инженером технической поддержки компании Arenadata и нередко сталкиваюсь с довольно каверзными задачами и багами. Одной из них была проблема оптимизации механизма UPSERT в Greenplum 6. В этой статье я хочу рассказать, как эта задача может быть решена.

Кому пришла в голову идея отправлять SQL запросы в data lake? Оказывается, это позволяет компаниям более гибко и эффективно анализировать свои данные за счёт уменьшения потребности в ETL и снижения нагрузки на корпоративное хранилище. Рассмотрим, какие популярные SQL-движки умеют это делать и как им это удаётся.

Меня зовут Владимир Озеров, я руковожу компанией Querify Labs. Мы уже порядка 10 лет занимаемся распределённым SQL, делаем всевозможные SQL-движки, в частности CedrusData — коммерческий движок на основе опенсорс проекта Trino. Сегодня поговорим про то, каким образом устроен ряд SQL-движков, которые обрабатывают данные от data lake.

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

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

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

Есть у нас флагманский продукт под названием «Единый клиент», с которым работают десятки энтерпрайз-клиентов, оперирующих в нем сотнями миллионов записей. Продукт массивный, обвешанный аналитикой и различными сложными сервисами. В какой-то момент большая часть клиентов захотела получить общий uptime в 99,9%, чего сложно достичь без резервирования решения. И мы начали погружаться в эту тему практически с нуля.

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

Привет, Хабр. Я Вероника, java-разработчик, который юзает Camunda без слез. Здесь моя первая статья, в которой мы переложили BPMN диаграмму на java код и реализовали небольшой процесс. 

На этот раз пишу о мониторинге бизнес-процессов. Давайте представим: мы зарелизились в прод. Всё работает прекрасно. Но тут приходит бизнес, которому нужны графики, диаграммы и отчеты. Что делать?

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

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

О проектировании микросервисной архитектуры с использованием фреймворка Single SPA и технологиях, связанных с его использованием.

Добрый день, уважаемые ИТ-ники. На связи Михаил Голованов. Продолжаем увлекательные эксперименты с tiered storage в Apache Kafka. В этот раз починим то, что не смогли починить ранее (сборка реализации AivenOpen) и поэкспериментируем с реализаций для Minio S3 в качестве бекэнда. Как и в прошлый раз, теория будет перемежаться практикой.

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

Когда спрашиваю у людей на собесах, или когда в команде решаем, как клепать очередной проект, такое порой слышу, что становится страшновато. Мне кажется, лет через 5 все компании будут обитать в мультивселенной безумия из “микросервисов”, которую они себе радостно построили, уходя от этих ваших страшных “монолитов”.

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

"Работает? Не трогай!" Но только не в HighLoad! Расти нужно постоянно. Всё менять и переделывать. Но как? И с помощью каких практик? А может и так сойдёт? Поехал искать ответ на Saint HighLoad++.

Перед вами заключительная, третья часть обзора изменений в Greenplum 7. Если вы по каким-то причинам пропустили прошлые публикации, то их можно найти в нашем блоге здесь и здесь. А сегодня мы поговорим об изменениях в партиционировании таблиц и ресурсных группах, JIT-компиляции выражений и многом другом. Давайте начнём!

На Хабре ещё не было статей про безопасность смарт-контрактов блокчейна Hyperledger Fabric. Так что буду первым. Я занимаюсь исследованием безопасности этого блокчейна год. И сегодня хочу рассказать о довольно серьёзной проблеме: манипуляции временем транзакции (UPD 27.08.2024 уязвимости присвоен идентификатор CVE-2024-45244). По классификации, уязвимость попадает в OWASP Smart Contract Top 10: SC03:2023 Timestamp Dependence.

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

Привет, Хабр! Меня зовут Георгий Меликов, я из VK Cloud и руковожу там инфраструктурной разработкой (IaaS) облака, где мы создаём SDN (Software Defined Networks) — программно определяемые сети; SDS (Software Defined Storages) — программно определяемые хранилища; и другие решения.

А ещё на досуге я — контрибьютор файловой системы OpenZFS с 2016 года.

В этой статье поговорим о наших подходах к разработке на примере создания нашего SDN. Мы ставим перед собой несколько целей:

1) Разрабатывать быстро, чтобы итерации были явно очерченными  и понятными. Хотим, чтобы у нас вырабатывался дофамин от закрытия спринтов, и было понятно, как жить дальше.

2) Эксплуатировать системы без людей — полностью автоматически.

3) Использовать принцип «Дизайн на отказ». Система должна уметь переживать любой возможный сбой и проблему, т.е.обладать так называемым качеством самовосстановления (self-healing).

Предлагаю пройтись эволюционно от простого примера "облака на минималках" до нашей production среды на несколько ЦОДов, собрав по пути проблемы из нашей реальной жизни.

Я написала этот текст из желания помочь разработчикам, которым только предстоит познакомиться с Camunda. С чего начать и как не потеряться - подробно, с кодом и скринами.

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

Сегодня мы поговорим об ещё одном новом для Greenplum типе индексов и не только.

Я фулстек-разработчик, индивидуальный предприниматель. По моему опыту, один из самых востребованных классов проектов, за разработкой которых к нам обращаются, — приложение для работы в режиме реального времени. Конечно, вам такие приложения известны: WhatsApp, Discord, Slack, т.д. При разработке приложений для работы в режиме реального времени следует учитывать различные факторы, в частности, масштабируемость, отказоустойчивость, отзывчивость и распределённость. Это задача не из лёгких, в особенности для небольшой команды или разработчика‑одиночки.

Но что если бы я вам сказал… что можно создавать приложения для работы в режиме реального времени, которые можно масштабировать более чем на миллион пользователей силами всего нескольких разработчиков? К тому же, такие приложения можно было бы развёртывать почти без задержек и ценой минимальных затрат. Здесь я имею в виду, что для этого нужно освоить секретное оружие под названием «Виртуальная машина Erlang» или BEAM (Абстрактная машина Богдана/Бьёрна для языка Erlang).