Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

DevOps дайджест #29: Kubernetes на F-16, Git для Monorepo, ClickHouse как Макгрегор

В выпуске: U.S. Air Force переехала на Kubernetes, Tanka от Grafana, Clickhouse наносит удар по ScyllaDB, релиз Elastic Cloud on Kubernetes.

Kubernetes

U.S. Air Force Deployed Kubernetes and Istio on an F-16
Лёд тронулся. Вроде бы и обычная статья о том, как переехали на Kubernetes, но это оборонка! U.S. Air Force решила изменить свой подход к разработке ПО, ушла от waterfall модели и вместе с тем заадоптила кубер с истио. Как обьясняет их CSO, для оборонки очень важно избежать вендерлока, не отставать от мейнстрима, ну и one point for the team was to demonstrate that it could be done :)

Production checklist for web apps on Kubernetes
Best practice чек-лист по управлению веб-сервисами в Kubernetes от Senior Principal в Zalando, автора тех самых Kubernetes Failure Stories k8s.af.

Debugging network stalls on Kubernetes
Сказ о том, как ребята из Гитхаба упоролись в troubleshooting сети в Kuberentes.

Introducing Tanka, Our Way of Deploying to Kubernetes
Grafana представила свой инструмент деплоя в Kubernetes — Tanka. Описывают, почему Helm с YAML им не подошел и почему ушли в сторону своего инструмента с Jsonnet.

Большая редкость, когда для open-source продукта существует bug bounty программа. В блоге Kubernetes появилась статья — официальный анонс bug bounty program. Поддержка bug bounty будет осуществляться провайдером HackerOne, команда которого специально для этого прошла сертификацию CKA. В статье также приводится много ссылок на руководства по безопасности для Kubernetes.

Vitess on Kubernetes for MySQL Решение для запуска MySQL в кластере Kubernetes. На данный момент подходит для баз размерами 250Gb-300Gb. Кстати, всеми известный и любимый YouTube также пользует Vitess. Рекомендую смотреть, пробовать и пользоваться.

Zero Downtime Server Updates For Your Kubernetes Cluster
Серия статей от компании Gruntwork о том, как следует делать правильный graceful shutdown.

Amazon EKS Price Reduction
Ну и хорошая новость для тех, кто использует EKS: Амазон понизил цены на свой кубер в 2 раза!
*Примечание от авторов: очень надеемся, что и релиз новых версий/фич они ускорят в 2 раза :) Вроде как обещают.

Google Cloud

Want to use AutoML Tables from a Jupyter Notebook? Here’s how
Хотите использовать machine learning (ML) в Google Cloud? AutoML Tables — иструмент для построения ML models без необходимости владения особой экспертизой в данном направлении.

Exploring container security: Announcing the CIS Google Kubernetes Engine Benchmark
Если вы серьезно относитесь к безопасности в Kubernetes — вам следует построить сильный бекграунд. Center for Internet Security’s (CIS) Kubernetes Benchmark предоставляет такую возможность.

Databases

Database of Databases
Шпаргалка по БД. Список существующих баз данных и краткое описание к ним.

Rebooting datastores into the future
Классная статья о том, как инженер из Нетфликса сумел добиться in-place OS image upgrade на statefull нодах с ephemeral storage. Сейчас Netflix использует этот подход для апгрейда своих кластеров Cassandra и Elasticsearch.

ClickHouse Cost-Efficiency in Action: Analyzing 500 Billion Rows on an Intel NUC
Ответочка ScyllaDB от ClickHouse. Используя всего один Intel NUC, Clickhouse сумел приблизиться к результатам огромного кластера ScyllaDB, а в некоторых случаях и вовсе обогнать. Судя по статье, благодаря своему хорошему коэффициенту сжатия (1:9) ClickHouse смог с легкостью поместить 525 миллиардов строк в 685 гиг памяти. Вот прямо захотелось покрутить ClickHouse. Кстати, кто у себя использует и для чего? Поделитесь в коментариях :)

Тот самый Intel NUC

Releases

Self-hosted Sentry 10 is ready to serve — get it while it’s hot!
Завезли много чего крутого: платформу для создания интеграций, новый UI и даже переписали свой поисковый сервис и назвали его Snuba. Новый сервис сопровождается новыми зависимостями вроде Kafka и ClickHouse... не уверен, что все это нужно для малых и средних проектов.

ECK — Elastic Cloud on Kubernetes
Elastic в довесок к их Docker-образам и Helm-пакетам официально анонсировали их ECK — Elastic Cloud on Kubernetes. ECK упрощает установку, обновление и поддержку Elasticsearch и Kibana. По сути, это набор YAML-файлов с описанием CRDs и операторов, при помощи которых можно установить, обновить, масштабировать продукты Elastic. Также можно делать бекапы, организовать security-аудит. За подробностями — в статью.

Redis 6 RC1 is out
По мнению автора Сальваторе, this is the most ’enterprise’ Redis version to date. Теперь Redis поддерживает ACL и SSL. Кроме этого среди обновлений: новый протокол RESP3, Client Side Caching, Disque (in-memory, distributed job queue) теперь доступен в качестве модуля и многое другое.

Prometheus 2.15
Состоялся релиз Prometheus 2.15, в котором оптимизировали работу TSDB, а именно significantly reduced memory footprint of loaded TSDB blocks and optimized buffer during compaction, что положительно повлияло на количество используемой памяти. Например, в моем случае после апгрейда Prometheus вместо 11 гиг стал кушать 7.

Git 2.25
Вышел Git 2.25. Разработчики активно дорабатывают partial clones, что позволит скачивать только часть данных — не нужно будет скачивать каждую версию каждого файла, как раньше. Например, будет очень полезно для Monorepo, подробнее об этом можно почитать здесь. Другие изменения по ссылке выше.

Miscellaneous

Как ЛУН совершенствует карту новостроек
Мне понравилось, какой путь проделали ребята из ЛУН по улучшению своей карты: от построения полигонов на карте до 3D-реконструкций и AR-моделей.

A decade in review in tech
Технический обзор прошлого десятилетия от Cindy Sridharan и немного мыслей о том, каким будет будущее. Также есть перевод от Фланта.

Tips for High Availability
Повторение мать учения. Советы, как построить real HA и минимизировать время даунтайма от Netflix.

Performance Reviews for Software Developers
Статья о том, как следует проводить перформанс ревью. Полностью согласен с мнением автора, менеджерам на заметку.

Сравнение производительности HTTP/1.1, HTTP/2 и HTTP/2 + Server Push. Автор статьи написал очень интересные тесты. В статье отличные визуализации скорости загрузки документа со всеми связанными с ним ресурсами (например — HTML-страничка + стили, изображения). Длинная и очень содержательная статья с не всегда очевидными выводами.

Co-authors


← Предыдущий выпуск: DevOps дайджест #28
Следующий выпуск: DevOps дайджест #30

LinkedIn

Похожие статьи

15 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Вот прямо захотелось покрутить ClickHouse. Кстати, кто у себя использует и для чего? Поделитесь в коментариях :)

для хранения метрик в Graphite

ClickHouse у нас с полпинка не взлетел, постоянно вешался на инстансах EC2, использовали для коллекций товаров.

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

U.S. Air Force Deployed Kubernetes and Istio on an F-16

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

не, ну что Вы. Вот Боинг так уже сделал со своим boeing 737 max — отлично же получилось.

на некоторых американских корветах управление корабельными турбинами под win nt 4.0
уже было несколько эпизодов, когда боевой корабль обратно в порт буксировали, т.к. собственного хода он не имел из-за проблем с софтом

Еще немного по Druid-у и я пойду пожалуй.
1. У него существует два API доступа к даным:
— JSON-запросы — самый быстрый способ доступа к данным на данный момент
— SQL-сервис на базе Avatica. Встречается инфа что в будущем разработчики планируют постепенно перейти на него в качестве основного, но пока это не так.
2. В Druid-e схема данных определяется дискриптором ingestion task-и, таким образом у него легко возможна ситуация при которой сегменты разных временных интервалов могут иметь разнуют структуру данных.
3. В Druid-e нет ничего похожено на delete/insert/update. Данные в Druid-e нельзя изменить через SQL, только через таски. Сегмент данных не меняется.
4. Сегмент данных(интервала) можно только перезалить. В зависимости от типа источника.
Если источник файл формата CSV/TSV/JSON (c доп. плагинами поддерживается AVRO, Parquet и ORC), то есть возможность делать append или rebuild. В случае потоковых данных только append.
5. В Druid-e на текущий момент отсутствуют JOIN-ы. Это непривычно конечно, и мне трудно сказать является это недостатком или фитчей ибо с одной стороны это удобно, с другой это 100% проблематичное место оказывающее влияние на производительность.
6. Cамое хлипкое место Druid-a, как и в Hadoop-e — это метакаталог в качестве которого используется классическая СУБД MySQL или PostgreSQL или что-то еще. Все остальные сервисы могут дублироваться и по мере разрастания кластера организовываться в пулы.

Из личных впечатлений.
Мне всегда было интересно познакомиться с NoSQL решением, решающим проблему интеративного анализа данных, при этом использующее для хранения данных медленный Deep Storage типа AWS S3 и его альтренатив.
Druid — отличный пример, того как это может быть реализовано.

Уточнение по ClickHouse: 685 GB SSD для хранения данных. А то «память» может трактоваться двояко.
Мы используем CH для аналитики по сырым данным + матвьюхи в качестве витрин нижнего уровня. По соотношению количества фичей к стоимости эксплуатации альтернатив я не знаю.
Если разобраться как CH работает внутри, правильно создать схемы данных и вдумчиво писать запросы, то действительно на полудохлом сервере можно считать агрегаты с группировками со скоростью вычитки 500+М строк в секунду.
Но это всё манипулятивные цифры. )) Т.к. CH — база колоночная, есть трюки по хранению данных. И нужно чётко понимать, что на самом деле происходит под капотом, что означает «500М строк в секунду» и как это сравнивать с другими БД. Потому что сравнение влоб ClickHouse и ScyllaDB — это как бы тёплое с мягким. О чём, в принципе, автор статьи упомянул.

По соотношению количества фичей к стоимости эксплуатации альтернатив я не знаю.

Не надо грязи© :)

Прямые конкуренты Apache Druid, Apache Pinot и еще много менее известных проектов.
Это класс продуктов под названием timeseriesDB. Если это знать, то становится сильно проще искать альтернативы и сравнивать их.
Учитывая системные риски, связанные со страной происхождения ClickHouse-a, нет смысла с ним связываться. Кроме того, на момент рассмотрения у него были ограничения которых не было у Druid-a.

Далее о Druid-e.

The data we had in MongoDB was migrated. This data stored in MongoDB was using approximately 60GB of disk space, and when indexed inside Druid, the same data represented only 600MB. Yep. 100x less storage!

Источник: towardsdatascience.com/...​ion-to-druid-4bf285b92b5a
У Druid-a это работает так.
Во время ingestion task в описании которой содержится dimensions и measurements и глубина детализации ( segment Granularity) согласно этому описанию нарезаются сегменты данных, сжатый колоночный формат с бинарными индексами.
Сервис который этим занимается в Druid-e называется MiddleManager или индексатор.
Сегменты данных укладываются в Deep Storage ( NFS, HDFS, Amazon S3, Google Cloud, Apache Cassandra и т.д).
Суть в том, что скорость Deep Storage-a не оказывает никакого влияния на производительность пользовательских запросов, поскольку при старте сегменты данных поднимаются с Deep Storage на сторону Historical сервисов где разархивируются на в локальной FS и постепенно поднимаются в кэш файловой системы хоста на котороий запущен сервис. То есть фактически все входящие запросы попадают на данные который находятся в памяти, отсюда миллисекундная скорость ответов на запросы.

Основная сфера применения Druid-e это конечно же чтение и аггрегация потоковых данных, через коннектор из Kafka-и и подобных источников данных. Аггрегация происходит почти в online. Как только фрагмент данных, считанный из топика Кафки проиндексирован индексатором, он сразу же становится становится доступным для пользовательских запросов, еще до того как оно он будет уложен в Deep Storage и потом поднят Historical сервисом в кэш, просто пока это не случилось за эти сегменты данных отвечает MiddleManager. То есть при работе с потоковыми данными пользовательский запрос посылается на Broker сервис, который собирает сегменты удовлетворяющие условиям фильтрации пользовательского запроса из разных сервисов ( Historical , MiddleManager)

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

Хочу особо подчеркнуть, что подобный софт — сильно далек от классической СУБД и предназначен для узкого круга задач, с которыми он отлично справляется.

P.S.
Хочу так же обратить внимание на еще один интересный момент. Apache Druid может использоваться как самостоятельный сервис, но так же находит применение в Hadoop стэке от бывшего HortonWorks в связке с Hive + LLAP + Druid, что делает пригодным Hadoop для интерактивной аналитики. Оптимизатор (я его так называю) TEZ генерирует DAG из пользовательского запроса составляющими которого могут быть как сегменты данных в Orc на HDFS-e , так и хэндлеры Druida. В последних версиях к ним добавились хэндлер JDBC датасорса , хэндлер топика Кафики.

Прошу прощения за много слов.

Надеюсь, Вы обратили внимание на ключевое «по соотношению»? Если на секунду предположить, что это соотношение базируется на анализе всех доступных альтернатив на рынке, то общаться становится сильно проще.
Druid — это дичайший монстр, который может себе позволить саппортить разве что суровый энтерпрайз. Если вы оттуда — поздравляю, скорее всего компания сделала правильный выбор ))

Я практически на 100% уверен, что если я попрошу вас предоставить сравнительную таблицу «этих самых соотношений» у вас ее вдруг не окажется, не так ли? :)

Когда не понимаешь, как оно работает, всегда переводи тему на Enterprise bullshit. :)

Apache Druid — полностью опенсорсный Java-base проект, в котором нет ни единного проприентарного компонента.
Без проблем поднимается в докере. Много сервисов с которыми надо разбираться? Так с любым софтом надо разбираться. У меня например на десктопе легко поднимается докеровский env для отладки pipeline-ов, состоящий из сервисов Кафк-и, Druid-a, Vertica-и и т.д cовместно работающих.
Для желающих есть компания imply.io которая осуществляет его коммерческую поддержку продукта.
Если вас напрягло слово Hadoop, то оно было упомянуто в качестве примера дополнительной сферы применения Druid-а и только.

Как только я найду время написать статью на ДОУ — тегну вас персонально, обещаю ))
На данный момент я не понимаю, кому и зачем мне что-то доказывать. Ребята попросили рассказать, кто как использует ClickHouse. Я отметился — используем. Если будут дополнительные вопросы по теме — с удовольствием отвечу. Ввязываться в бессмысленные холивары — увольте.
В наших конкретных условиях ограниченности по ресурсам и поставленным задачам, ClickHouse действительно является очень удачным и по-сути безальтернативным на данный момент решением, закрывающее большинство текущих потребностей. Если интересно — можно задать дополнительные вопросы. Но попытки доказать, что Druid лучше на каких-то абстрактных задачах, выглядят немного странно.

Прямые конкуренты Apache Druid, Apache Pinot и еще много менее известных проектов.
Это класс продуктов под названием timeseriesDB.

начнем с того, что все они — Druid, Pinot, ClickHouse, являются column-oriented DBMS
и TSDB — всего лишь один из множества возможных сценариев их использования,
в отличие от TSDB, таких как — InfluxDB, TimeseriesDB, ...

Софта подпадающего под описание timeseries DB достаточно. Проблема в том, что не всякий timeseries DB годится для аналитики, а вот упомянутая тройка годится.

TSDB

которому нужен HBase, который в свою очередь хочет Hadoop инфраструктуру, что не всех приводит в восторг. :)
Про InfluxDВ ничего не скажу ибо не знаю, и пока у нас нет никаких аргументов для того чтобы отказываться от Druid-a в пользу чего-то еще.

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

Мы используем CH для аналитики по сырым данным + матвьюхи в качестве витрин нижнего уровня.

Как типовой Datawarehouse+BI или именно с CH используете Machine Learning для аналитики?

Для поведенческой аналитики и репортинга. Что-то вроде доморощенного GA, но со специфическими для OTT входящими данными и метриками, некоторые из которых считаются на последовательностях событий очень нетривиальным образом.
А для ML используются данные, которые лежат в data lake уровнем ниже. Одна из основных причин, по которым строится своя аналитика, — это владение полным объёмом данных, не платя при этом все деньги мира. Чтобы иметь возможность работать с этими данными чуть глубже, чем это позволяет BI. Но это уже другая история.

Подписаться на комментарии