2019-05-12: SaintHighload - погружение в технологии

Короткая ссылка: Highload-2019-Spb

Ссылки сюда (4) →

Собрал вместе свои заметки с #SaintHighLoad2019 8-9 апреля в Петербурге. Если говорить о конференции в целом, то я на ней знакомился с современными технологиями, слушал доклады о нейронных сетях, современном мониториге, ArangoDB и многом другом. Интересно, что на осенней #HighLoad2018 в Москве у меня такого не получилось, хотя технологические докладов там было большинство. Я там слушал про развитие менеджмента, управление счастьем и общую догику развития цифрового мира, включая задачами почти для миллиона участников Яндекс-толока, о чем можно прочесть в моем отчете Highload-2018. А в Питере случилось погружение в современные технологии.

Но начну я рассказ с двух постов, которые не про доклады, а про результат устных коммуникаций на конференции. Первый касается развилок в развитии технологий, а второй - про специализацию Site Reliable Engineer. А потом - перейду к докладам.

Развилки развития технологий

Пост на FB Вчера на afterparty #SaintHighLoad2019 обсуждали, что известно про будущее и какие есть варианты. И я хочу фрагмент этого разговора здесь запомнить. Сначала - ретроспективно. Все довольно давно понимали, что индивидуальные мобильные телефоны у каждого человека - точно будут. Но дальше была развилка, была идея, что это хорошо обеспечит космическая связь, или что повсеместная установка оборудования для связи. Теперь мы знаем, что реализовался второй сценарий в виде развертывания сетей GPS и других мобильных сетей. Но ведь первый не успел совсем чуть-чуть, спутники Iridium были запущены в нужном количестве, стартовали продажи. И, естественно, когда этот проект делали, про альтернативу в виде мобильных сетей тоже знали, но переоценили стоимость развертывания, решили, что сельскую местность освоить будет нерентабельно, и иридиум будет первый. Но разница по срокам была незначительна. А ведь если бы Iridium успел, то ситуация была бы сильно другой, явно не было бы такого бурного развития и связи, и мобильного интернета, и связанных услуг... Так что будущее, с одной стороны, понятно - индивидуальные мобильные телефоны точно должны были быть, а с другой стороны - вариативно, и различаются явно не детали.

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

Еще развилка. Активно появляются субъекты ИИ, они сдают экзамены в ВУЗы, получают лицензии. Так что они - точно будут. А вот будет ли их всего несколько в крупных компаниях, доступных как сервис, или можно будет, взяв предобученную сетку, сделать своего специализированного субъекта ИИ, который станет участником именно твоей команды - пока неизвестно. А, согласитесь, это принципиально различающиеся для развития общества сценарии.

В частности, за этим вопросом следует еще один. Сейчас субъекты ИИ, получая права водить автомобиль, участвовать во врачебных консилиумах или давать юридические консультации становятся юридическими субъектами. При этом часть из них точно будет свободно общаться - это нужно и врачам и юристам и для многих других специализаций. Вопрос: насколько на них распространятся все остальные права, присущие человеку? Например, право на жизнь? Или право участия в управлении государством и обществом? И так далее...

И аналогичных развилок сейчас много. Впрочем, мир меняется быстро, и через 5-10 лет ответ на эти вопросы будет достаточно понятен.

Roman Poborchy Хайнлайн, Азимов, Гаррисон...

Максим Цепков Да, у них много вариантов ответов, они исследовали ситуации. Но там законы жанра еще требуют конфликтов и драмы, и не предполагают всеобъемлющего рассмотрения. И интересно как, оно окажется в реальности.

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

Roman Poborchy Maxim Tsepkov Я даже немного другой смысл имел в виду. Можно сейчас почувствовать себя фантастом, обсуждая подобные вещи. Это очень приятное ощущение.

Максим Цепков Roman Poborchy Это, кстати, да. При этом научным фантастом, в том смысле, что интересно обсуждение в практическом залоге, а не произвольные фантазии.

Andrei Safonau Право на жизнь, получаемое человеком до рождения(несколько тысячелетий) и право на управление государством, которое породил сам же человек только 500 лет назад не есть, имхо, одно и то же. И развилки в головах - чем более пустые головы, тем больше развилок туда возможно засунуть. Так, Максим?

Максим Цепков Конечно, это - разные права, и каждое будет развиваться отдельно. И эти - то, что я быстро выписал, там еще много других надо смотреть. Например, право на образование. А развилки - они не в головах, они в жизни, это многовариантность путей будущего развития мира. И как раз пустые головы, не осознающие деталей и не пытающиеся детализировано строить картину будущего, этих развилок обычно не видят.

Andrei Safonau Максим Цепков , не видят, согласен, как не видит в лесу, заблудившийся, сторон света, карты леса. Он видит много деревьев вокруг. Понимаете, как я это сравниваю, Максим? Попытка строить "свою персональную" картину мира - это примитивная надежда не подозревающих о Юнге, Шопенгауре, Софокле, Платоне, Сократе...😂

Максим Цепков Andrei Safonau Картина мира у каждого своя, персональная, в собственной голове, и при принятии решений мы опираемся именно на него. Дальше вопрос для каждого - на что опираться о построении этой собственной картины мира. И тут гигантов прошлого необходимо привлекать, чтобы стать великим. Ну а дальше - вопрос выбора, что брать в первоисточниках, что - в поздних компиляциях или современных синтезах тех, кто выкладывает части своей построенной картины мира. Потому что всю информацию мира в голову не загрузишь... О Сократе, Платоне, Софокле, Юнге, Шопенгауэре большинство слышали, вопрос - что из их наследства включено в твою картину мира, помимо факта, что да, были такие люди :)

Andrei Safonau Согласен. Крыть не чем. Типо, как я могу понять, что ты чувствуешь Толстого (Булгакова, Тютчева, Рахманинова), как я? Надо бы мне об этом поразмышлять. Вы бьёте прямо в глаз, Макс. Счас знаете куда пойду? В "Пять выше". Ошибочность персоны при принятии решений опираться не на коллективную, а на собственную картину. Имхо. Гордыня ХХI? Справедливость выше закона, общественное выше личного, совесть- внутренняя свобода личности.

Репост Mark Mamrykin Вести с ИТ полей :) Субъекты ИИ - участник команды "на заказ".... прямая нейросвязь между людьми ...и субъектами ИИ? Спасибо Максим Цепков за репортаж!

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

Site Relible Engineer

Пост на FB На конференции кроме докладов есть много общения, и оно часто более ценное. На этой конференции Vitaly Levchenko рассказал мне про SRE - Site reliable engineer (https://landing.google.com/sre/). Это человек, который объединяет компетенции админа и разработчика, и занимается вопросами надежности высоконагруженных сайтов. Книгу про такую специализацию выпустил Google в 2016 (смотри ссылки в вики https://en.wikipedia.org/wiki/Site_Reliability_Engineering). Возникает вопрос: а почему это - отдельная специализация, а не DevOps. Мой ответ в том, что это следующий такт развития DevOps. DevOps появился раньше, вики говорит, что он восходит к 2009, а дальше, по мере популярности движения, формировался набор практик, которые обеспечивают непрерывность конвейера поставки от разработки до эксплуатации. И сейчас он сформирован и ограничен квалификацией, которую можно сделать относительно массово, как было сказано в разговоре "сейчас думают, что DevOps - это админ, который выучил Jenkins, и этого сильно недостаточно". Понятно, что это - утрированное мнение, и нужны гораздо более квалифицированные DevOps-инженеры, но уже примерно понятно, какую область они закроют. И вот надежность и производительность высоконагруженных сайтов явно кажется за этими пределами, поэтому будет формироваться следующая специализация.

А что мне интересно - Виталий в Питере уже делает сообщество SRE, хотя специализация, можно считать, только зарождается - такие люди сейчас есть только в Google...

Vitaly Levchenko SRE массово есть в SEMRush, многие с этим экспериментируют.

Максим Цепков Круто! Но все-таки - экспериментируют. А, кстати, как на Западе, кроме Google?

Игорь Беспальчук Это просто разные специализации (а она все нарастает...), всякий раз называемые исторически по-дурацки. Разные целевые системы и их аспекты/качества.

Максим Цепков Конечно, разные, специализация нарастает, идет углубление разделения труда. Названия - нормальные (ну, какие есть). Но происходит это делением какой-то более общей специализации, как когда-то программистов поделились на разработчиков, аналитиков и тестировщиков, а потом среди разработчиков появились разработчики сайтов, из которых потом выделились дизайнеры и контент-менеджеры, а сами разработчики позднее поделились на фронт и бэк, а теперь еще возродился фулстек. Тут же фишка в том, что "система в глазах смотрящего", и ее границы можно проводить относительно произвольно - что и происходит при выделении специализации.

Игорь Беспальчук Максим Цепков В глазах смотрящего, оно конечно, но есть же объективный исторический процесс. Он предъявляет новые вызовы и сгустки сложности - не произвольны. Именно вокруг них и формируются специализации. И эта объективная трендовая, типичная, не механизированная пока сложность приходится на разные целевые системы и их аспекты/качества.

Максим Цепков Игорь Беспальчук Тут есть несколько интересных вопросов.

1) Насколько сгустки сложности появляются объективно, а насколько - случайно? Это же статистическая конструкция - сразу у многих экземпляров процессов на этом месте появился сгусток.

2) Насколько конкретный сгусток сложности образуют систему? Конечно, система - в глазах смотрящего, но это не значит, что границы можно проводить совсем произвольно, признаки системы, в том числе инкапсуляция сложности "внутри" - должны присутствовать. А поскольку сгусток образуется статистически, то не всегда так бывает.

3) Насколько тут играет человеческий фактор? В смысле, одни увидели эти сгустки сложности в своем опыте, как-то их порешали и пошли дальше. Ну, может, еще рассказали на конференции об этом. А другие, увидев сгустки, не только как-то порешали, но и организовали серию встреч и инициировали движение и выделение специализации. Или даже не смогли порешать в одиночку, и поэтому организовали обсуждение и сообщество.

А третий вопрос - самый интересный, потому что тут как раз потенциальная точка влияния конкретного человека на развитие мира. На выделении DevOps и SRE из админов эти вопросы хорошо видны.

Игорь Беспальчук Максим Цепков По пунктам.

1) объективно или случайно - мне не очень понятно это противопоставление. Это происходит. Накопилось много данных и нужно их обрабатывать быстро - появляется BigTable, Hadoop, и специализация BigData. Увеличились мощности и всем нужно решать задачи распознавания - появляется специализация ML. И т.д. Вроде нет сомнений в объективности того, что раньше мало кто решал такие задачи, а сейчас - много кто. А что такое "случайные или нет" появления такого рода инженерных задач/сложностей - мне неясно.

2) Иногда образуют системы, иногда аспект, иногда качество. А зачем вам "всегда" для появления специализации? Взять, например, специализацию информационной безопасности. Она крутится и вокруг некоторых специализированных подсистем, и вокруг отдельного качества защищенности прикладных систем. И это нормально. Наросла сложность, не успела выпасть в осадок готовых инфраструктурных средств - и вот, специализация. Да, тут важна статистика. Специализация может появиться и на отдельном предприятии, но если задачи и сложности схожие - прорастает в отрасли повсеместно.

3) Это исторический процесс, в нем есть статистика объема предпосылок плюс поводы и флуктуации. Пнуть может и один человек, но если не он, то другой. Если бы не Ньютон, ну так кто-то другой бы разработал аппарат дифференциального исчисления. Мы это знаем по кейсам параллельных изобретений и открытий. Конечно, один буйный может нагнать некоторого размера волну, но инженерная сложность все-таки объективна, не получится долго жить с малосодержательной дисциплиной - она просто быстро сольется с другой.

Максим Цепков Усложнение или увеличение числа задач далеко не всегда вызывают специализацию, они могут решаться в рамках существующих специализаций их развитием. Тут характерный пример BigData: нарастание объемов данных было всегда, и с этим разбирались в рамках текущих проектов, не артикулируя тренд. Дальше в некоторый момент кто-то (и у этого кого-то есть имя) решил, что это - что-то принципиально новое, поднял на флаг, и Gartner это зафиксировал. Пошли конференции и обсуждения, но дальше выяснилось, что этот сгусток проблем был случайным в том смысле, что они не образуют одну систему, там несколько разных систем, в которых возникли свои практики решения? и вроде некоторые специализации. А тренд BigData Gartner пару лет назад закрыл.

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

P.S. Детали по BigData мне надо поднимать из переписки (+google), я не думаю, что именно они интересны в рамках конкретного обсуждения? тут - иллюстрация мысли.

Игорь Беспальчук Максим Цепков Я не говорил про увеличение числа задач - это решается масштабированием организации. Я говорил про рост когнитивной сложности, объема элементов и понятий. BigData - это не про увеличение объемов данных, это про кардинальную смену парадигмы их обработки и средств их обработки в этой ноаой парадигме. Возникает естественное разделение по классам средств. При этом добавляющаяся сложность (количество структур, понятий, инструментов, языков) достаточно большое - один человек изучает и осваивает достаточно долго. И вот - готова специализация. Чуть раньше, или чуть позже, написал кто-то статью или не написал - это сдвигает сроки, но не более. Субъективный ВЗГЛЯД не может тут ничего поменять "просто взяв другие границы систем".

Иван Евтухович Погугли, термин SRE возник в 2003 году. Так что ты все перепутал. Как раз наоборот SRE - профессия, которую невозможно масштабировать. Плюс DevOps-инженер - профессия, которой не существует.

Максим Цепков Я после разговора с тобой погуглил немного. Про возникновение SRE - мутно. Я смотрел английскую wiki (в посте ссылка) и статье у гугла. Там достоверно, что в 2016 вышла книга. И, наверное, именно в ней рассказывалось, что в 2003 в Google появилась команда из 7 инженеров, которые так себя называли. И никаких следов этой команды в виде статей или докладов на конференциях до книги 2016 не приведено. Если кинешь ссылки до 2016 года - будет хорошо.

А DevOps - инженер на hh 900 вакансий в Москве и еще столько же - в остальной России, и профили в этих вакансиях достаточно однородные (ну, если листать и смотреть взглядом) - так что вполне себе сформированная специализация.

Иван Евтухович Максим Цепков ты не поверишь, я тоже погуглил, и реально у меня такое чувство, что это в устной традиции передавалось - никаких следов в интернете :-)

По поводу devops-инженеров - статья. Опять-же, в devops-тусовке за devops-инженера можно и канделябром получить, но безграмотным hr на это наплевать.

Стас Фомин В комиксе 2011 года SRE - архитипичная роль IT-мира.

Максим Цепков Иван Евтухович Про SRE - думаю тут процесс вот какой: у больших компаний - всегда более глубокое разделение труда, чем в отрасли, и выделяются специализации, которые отрасли в целом не нужны, там это решается через совмещение и привлечение экспертов. Как именно специализация выделяется - зависит от компании, это во многом ситуативно. И в публичном поле это может не обсуждаться. Но по мере развития отрасли процесс идет, и когда он набирает силу, кто-то из лидеров может осознать ситуацию и выложить свой опыт - как сделал Google в книге. И дальше это фокусирует специализацию.

Про канделябр за devops-инженера в devops-тусовке - это достаточно интересный вывих самоидентификации: мы в сообществе, но идентифицировать себя с этим сообществом не хотим, мы - больше(?). Или тут что-то другое? Статьи я посмотрел, там - мутно все, на мой взгляд.

Игорь Беспальчук Максим Цепков Макс, тут речь о том, что термин devops - он был придуман совсем не как название специализации, а почти наоборот - как обозначение культуры, когда инфраструктурная компетенция присутствует в команде разработки. Но одновременно с этим появлялась и осознавалась и сама эта компетенция и специализация. И конечно в поиске названия схватили то, что близко лежало - "devops". И это очень, очень смешно: отдел devops и инженер devops получаются оксюморонами в первоначальном смысле слова devops. Но уже ничего не изменишь, разве что постепенно удастся распространить более адекватное название профессии. Но оно же скучно звучать будет: инженер инфраструктуры разработки ПО или что-то типа того.

Максим Цепков Игорь Беспальчук Нет, DevOps - не про ИТ-инфраструктуру, DevOps - про мост между разработкой и эксплуатацией, про гладкую сшивку и стирание этого барьера. И инженер devops - тот, кто эту сшивку обеспечивает за счет соответствующих инженерных практик. А в культуре разрыв был проявлен, и необходимость устранения - признана. Ну, наверное, еще не всеми, прошло мало времени и старые привычки, в которых этот разрыв на границе был так просто не уходят, а проявляются, так что работа с культурой тоже нужна. Но еще нужны специализированные практики, которые образовали специализацию. И да, в первоначальном замысле отдельной специализации не было, идея была в том, чтобы разработчики и админы начали сотрудничать и вместе устраняли проблемный разрыв. Но оказалось, что этого недостаточно...

Игорь Беспальчук Максим Цепков По факту, когда сейчас ищут "devops-инженеров", в 99% случаев ищут специалистов по инфраструктуре, без всякой "сшивки" и т.п. идеологически прекрасных вещей.

Александр Титов я разговаривал на DevOops c Сетом Варго, он сейчас в Гугле отвечает за DevOps, разговаривал про SRE.

Во-первых, они считают SRE имплементацией DevOps в конкретно взятой компании. Про это можно почитать тут

Во-вторых, википедия так себе источник информации, надо смотреть на факты, а факты такие, создателем SRE считается Benjamin Treynor Sloss, смотрим его линкедин https://www.linkedin.com/in/benjamin-treynor-sloss-207120/ Responsibilities: Site Reliability Engineering: 2003-present. Так что SRE существует в гугле с 2003 года.

В-третьих, я спрашивал Сета, почему они SRE не шарили наружу до 2014 года, он мне честно ответил, что это было их know-how и они боялись конкурентов, а причина шаринга наружу была вообще чисто коммерческая — Гугл облако очень плохо продавалось, так как у людей не было методов работы с ним. Теперь это вылилось в целую программу от гугла. Для понимания, SRE нужен гуглу для продажи своего облака, ну и понятное дело наружу вынесено только то, что нужно для продажи облака.

В-четвертых, я много раз смотрел вакансии DevOps инженеров (работа у меня такая), нет там никакой консистентности, где-то это прокаченный админ, где-то релиз-менеджер, где-то программист, который пишет инструменты, а где-то все это вместе взятое. Понятное дело, что это результат несформировавшегося разделения труда, но в будущем там будет много разных профессий. В Америке к примеру, большинство мигрирует на тайтл SRE, так как у него вполне фиксированный функционал.

В-четвертых, DevOps это про новый инженерный подход к разработке ПО вообще, про это можно почитать у Майкла Портера

Максим Цепков Прикольно! Корпорация добра наносит свое добро только чтобы продать свое облако и лишь св том объеме, в котором это нужно, чтобы продать облако :)

Иван Евтухович Максим Цепков бесплатный кубернетиз бывает только в мышеловке!

Александр Титов Ну а как еще в этом мире жить :) Добро наносить методично и малыми кусками

Станислав Шушкевич. Нейросети в производстве зубных протезов

Пост на FB Смотрю технологические тренды. Станислав Шушкевич. Нейросети в производстве зубных протезов. Как мы применяем глубокое обучение для автоматизации классификации входных данных и генерации дизайна. Это рассказ о том, как нейронные сети заменяют автокад-программы индивидуального проектирования, в которых сейчас зубные техники ведут индивидуальное проектирование зубных коронок, затрачивая примерно 10 минут на коронку. Для практического применения, заказчик - одна из крупнейших американских зубопротезных компаний, программа - для реального использования.

Рассказ мне позволил погрузиться внутрь того, как устроено современное обучение. Фишка в том, что оно - многостадийное. Общая задача разделяется на несколько, каждую решают по своему и часто - в несколько этапов. Например, чтобы есть задача - обучить формировать анатомическую поверхность коронки, в которой техники различают натуральную и нет простым взглядом, и не могут объяснить различия формально. Первая попытка - обучаем на реальных зубах по снимкам, не пошло, потому что зубы слишком разные. Потом попробовали на коронках, они более однородны - оказалось, что 30-60% из них несовершенны. Зато получается материал для обучения - хорошие и плохие коронки. Правда, нужно еще их разделить, и это делают вспомогательной нейронкой: 10k коронок сортируют вручную, на этом обучаем нейронку различать хорошее и плохое, проверяем результата вручную, а дальше эта нейронка создает обучающие выборки на 20k по каждому из 16 зубов отдельно. Но при этом еще особенность - при обучении нельзя ставить критерием, что полученная коронка совпала с той, которая была реально делана, пусть она хорошая, потому что у задачи есть несколько решений, которые техники признают хорошими - поэтому там более сложный критерий для квалификации решения. При этом интересно, что хотя каждый техник делает коронку по своему, при оценке качества верхней поверхности они единогласны, а вот про область прилегания к соседним зубам сбоку у них три школы, каждая считает свой вариант наилучшим. Пока система выдает обобщенное решение, техник подправляет.

Из интересного для меня - результаты обученной нейронки превосходят результаты алгоритма, на основе которого делали обучающую выборку. Например, есть задача сегментации снимка на отдельные зубы и десну вокруг, есть геометрический алгоритм, который это делает с выходом в 30% Прогнали на 15k кейсов, вручную выбрали 5k хороших, на них обучили нейронку. И она качественно сегментирует 90% снимков.

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

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

Во всяком случае, мне рассказывали про аналогичные последствия предыдущего витка перевода расчетных алгоритмов в компьютерные программы. На закате СССР в ЦАГИ группа хороших разработчиков вместе с экспертами перевела расчеты какой-то динамики по обтеканию каких-то сложных геометрий в Фортран-библиотеку, при этом основой моделей были физические эксперименты в аэродинамической трубе. И она очень хорошо рассчитывала. Пока лет десять назад не появились новые композитные материалы, обтекание которых отличается, а библиотека про них просто не знала. И вот тут-то неожиданно оказалось, что за 20+ лет методика проведения экспериментов в трубе была утрачена просто потому, что за счет хорошей библиотеки физические эксперименты оказались не нужны, было достаточно численных... С зубными техниками ситуация в чем-то аналогичная, только гораздо более массовая.

Сергей Добриднюк Там вообще все грустно .. Раньше мама советовала сыночку, Изя, хочешь быть всю жизнь богатым и иметь важную работу - иди в зубные техники ! А теперь - 3D фрезера за минуты вытачивают коронки, с чумовой точностью - недоступной среднему зубному технику.. А есть материалы - типа циркония, которые вручную в принципе не сделаешь - материал сложный и технология ядовитая...

Максим Цепков Ну это как станки с ЧПУ вытачивают детали не так, как токарь/слесарь. Зубные техники, о которых шла речь - они проектируют коронки, вытачивают-то их станки давно.

Timur Batyrshin Какое-то время специалисты будут востребованы как кто-то, кто контролирует работу сети, и возможно весьма долгое время. Другое дело, что за это время характер работы у них сильно изменится (особенно если практики мало) — люди тоже доучатся классифицировать работу алгоритмов. А вот что при этом произойдет при смене поколений не совсем ясно.

Максим Цепков Вот и я об этом. Контролировать надо значительно меньше народа, поэтому нынешних опытных будет для этих позиций избыток, а остальные будут потихоньку деградировать, и новой смены, скорее всего, не появится. Сейчас можно наблюдать на примере многих инженерных специальностей в России, как это происходит, просто причины были другие - когда есть старые спецы в 70-80 лет и совсем молодежь... При этом видимые кейсы - это там, где при этом есть острая необходимость в восстановлении, а наверняка куча кейсов про то, где ее нет. Собственно, об этом и вопрос, если мы хотим увидеть картину будущего.

Дмитрий Волынцев. njs ‒ родной JavaSсript-скриптинг в nginx

Пост на FB Дмитрий Волынцев. njs ‒ родной JavaSсript-скриптинг в nginx. Рассказ о том, зачем nginx решил писать собственный интерпретатор JScript, и немного текста. Решали прагматичную задачу - подключения авторизации на уровне nginx, это актуально в микросервисных архитектурах, чтобы сервисы получали уже авторизованное обращение. Есть openresty, который эту задачу решает, но с ним разногласия по философии: nginx концептуально работает на небольшом количеством командах, совместимых между собой, а openresty делает конкретные команды "по месту". А еще там своя виртуалка 32 битная - можно наступить на ограничения, и написан на lua - нишевый; специфический синтаксис и индексация с единицы; и написан в 1990х и не развивается.

Поэтому решили делать свой, выбрали jscript - популярный, C-like-синтаксис, это важно для использования в конфигах. Активно развивается. Модель - обработка по событиям - хорошо ложится на nginx, обработчики не блокируют друг друга, ветвления могут породить новые события. nginx работает так же, только внизу C. Но для JS потребовался свой интерпретатор. Популярные браузерные V8 и SpiderMonkey - не эффективны в nginx. В браузерах - мало вкладок, garbage коллектор и прочее, но открытие новой вкладки может быть дорогой. На сервере же код - небольшой, нагрузка очень большая, открытие нового запроса должно быть дешево. Duktape - предназначен для встраивания. Но он недостаточно быстр, и он не является фокусом для разработчиков. А еще им было важно сопрячь интерпретатор с nginx, потому что надо создавать мини-интерпретатор на каждый запрос, и делать это быстро и дешево.

И дальше рассказ о том, что получилось. nginx+njs - НЕ application server. Для сервера - node.js или есть их собственное разработка. При этом - разумная (а не перфекционисткая) реализация стандартов, по Парето. Технологии: (а) прекомпиляция кода; новая VM для запроса - клонируется, при это read-only часть кода и констант - переиспользуется, а не копируется. Нет JIT-компиляции, потому что многоплатформенность - дорого, а еще - не нужно, потмоу что численные алгоритмы делать не будут, будут API вызывать, и именно выполнение этих вызовов будут есть основное время. А еще - нет сборки мусора, потому что виртуалка на время запроса, короткоживущая, и за это время объекты не будут плодиться.

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

Андрей Абрамов. ArangoDB: Transactional information retrieval

Пост на FB Андрей Абрамов. ArangoDB: Transactional information retrieval. Очередной такт развития БД. На предпредыдущем бурно пошли альтернативные реляционным базы данных - графовые, объектные, и примкнувшие к ним поисковые движки. На предыдущем такте развитые движки стали включать соседние способы организации дополнительно, и реляционные тоже к этом подключились, делая у себя json-хранение вместе с реляционным, как Postgres. А теперь создаются БД, в которых несколько парадигм заложены изначально, в Arango - пара (ключ-значение) + графы + документы, и сейчас добавили поисковый движок подобный Elastic поверх всех трех.

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

Дальше были технические особенности реализации поиска в ArangoDB, в частности разные варианты скоринга записей с кастомизацией алгоритма. И кейсы реальных внедрений. Первый - на больших медицинских данных. Раньше был Elastic + Kassandra, для конечных запросов все было неплохо, но еще был доступ по API, где надо было выдавать по 50k-100k записей, и вот это Elastic не тянул. Arango - потянул. Второй кейс - графовая задача. Тут сложность, что если за счет кластеризации граф получается распределенным по нодам, то поиск убивает производительность. Arango позволяет организовать smart-хранение, чтобы логические кластеры графа располагались на доном сервере. Если такие атрибуты связности есть, то можно их указать, если нет - в Arango есть встроенные средства анализа. Bio-IT World. Кейс на 4 базах данных: фенотип (состояние алгоритма), геном (наборы мутаций в генах, json), лекарства, ассоциации между ними - в виде статей, где эти базы данных упомянуты. Задача: учесть влияние генома на индивидуальные реакции на лекарства. Надо по первым трем данным найти релевантные статьи. Сложность, что когда выбираешь по заболеванию надо учитывать смежные, общие и частные.

Евгений Потапов. Мониторинг сложных систем в 2019 году

Пост на FB Евгений Потапов (Evgeny Potapov). Мониторинг сложных систем в 2019 году. Что изменилось и как не пропустить проблему?

Основное сообщение доклада - 90% мониторинга - это кодинг, а не установка каких-то инструментов с их настройкой. И потому это требует проектирования, планирования и разработки, требует участия программистов, а не только админов. Эта ситуация сложилась постепенно, 10 лет назад были приложения в БД и сервер приложений интернет-магазина, и их действительно можно было мониторить, развернув и настроив Zabbix. А в 2010 уже надо мониторить нагрузку, проверять, что поисковый движок работает и индексирует, что в в каталоге попали все товары, прохождение доставки, которая во внешней службе, работа sms-сервиса, и надо было уже писать много скриптов мониторинга, но все равно сохранялось обозримое количество приложений. Дальше пришли микросервисы и кластеры, и ситуация еще усложнилась. А в голове у тех, кто планирует проекты, все равно "поставь и настрой софт, пусть не zabbix, а prometheus + Grafana + плугины, и все, мониторинг сработает". А реально 90% мониторинга - это написание кода.

Я от себя хочу заметить, что раньше тоже полноценный мониторинг бизнес-сценариев, о которых шла речь в докладе, zabbix все равно не гарантировал. Просто тогда всем было понятно, что это надо предусматривать внутри приложения, это не рассматривали как часть мониторинга. А сейчас, поскольку приложение из кусочков, есть ложное впечатление, будто это тоже может получить.

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

И разные технические подробности и боли. Кто придумал Prometheus внутрь кубика? Кластер упал - как разбираться будете? Да, изнутри тоже надо, но надо и снаружи смотреть. Внешние проверки работоспособности должны обращаться снаружи - проблемы доступности вашего сервера надо диагностировать. А еще мониторинг мониторинга оже должен быть.

По инструментам - по сути уже есть отраслевые стандарты Prometheus + Grafana - стандарт + логи на ELK-стек + Jaeger (Zipkin) для АРМ и трейсинг. Но! Инструменты после задачи и для нее, а не наоборот. Потому что разные инструменты - для разного. Никто не начинает решать задачу "разработай приложение" поднимая базу данных, а начинают проектировать архитектуру. В том числе - выбирая базу данных. А сейчас DevOps начинают именно с установки инструмента, а потом начинают налаживать мониторинг инфраструктуры, чаще всего не потому, что это болит, а потому, что это - понятная им задача.

Сергей Добриднюк И то не факт.. Чуть посложнее - плывут и Grafana и Elastic Search, и надо кодить напрямую в приложении правильное логирование и откидывание метрик производительности. В том числе и для балансировщика - чтобы например сразу рубил новые соединения, если время отклика БД серьезно увеличивается - чтобы и без того не усугубить ситуацию

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

Кстати, про логирование. Сервер Btrieve был устроен таким образом, что его балансировщик нагрузки при топовых нагрузках сервера отключал логирование изменений, считая это необязательной опцией. Что делало разбор причин экстремальной нагрузки весьма увлекательной задачей :)

А с коннектами - ловили на enterprise, при замедлении ответа пользователь запускает еще один экземпляр приложения и пробует делать параллельную работу. И в результате идет как раз каскадная деградация БД... Фишка в том, что отстреливать при этом по бизнесу часто надо не новые коннекты, а некоторый из тяжелых существующих. Потому что мониторинг часто выявлял либо одну супертяжелую сессию, либо гонки из 2-3 сессий, которые грузили весь сервер.

Развернутый комментарий в репост от Дмитрия Симонова. Максим Цепков написал конспект по выступлению Евгений Потапов на #SaintHighLoad2019 про мониторинг сложных систем в 2019 году. Что изменилось и как не пропустить проблему?

Основное сообщение доклада - 90% мониторинга - это кодинг, а не установка каких-то инструментов с их настройкой. И потому это требует проектирования, планирования и разработки, требует участия программистов, а не только админов. Эта ситуация сложилась постепенно, 10 лет назад были приложения в БД и сервер приложений интернет-магазина, и их действительно можно было мониторить, развернув и настроив Zabbix. А в 2010 уже надо мониторить нагрузку, проверять, что поисковый движок работает и индексирует, что в в каталоге попали все товары, прохождение доставки, которая во внешней службе, работа sms-сервиса, и надо было уже писать много скриптов мониторинга, но все равно сохранялось обозримое количество приложений. Дальше пришли микросервисы и кластеры, и ситуация еще усложнилась. А в голове у тех, кто планирует проекты, все равно "поставь и настрой софт, пусть не zabbix, а prometheus + Grafana + плугины, и все, мониторинг сработает". А реально 90% мониторинга - это написание кода.

Я от себя хочу заметить, что раньше тоже полноценный мониторинг бизнес-сценариев, о которых шла речь в докладе, zabbix все равно не гарантировал. Просто тогда всем было понятно, что это надо предусматривать внутри приложения, это не рассматривали как часть мониторинга. А сейчас, поскольку приложение из кусочков, есть ложное впечатление, будто это тоже может получить.

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

И разные технические подробности и боли. Кто придумал Prometheus внутрь кубика? Кластер упал - как разбираться будете? Да, изнутри тоже надо, но надо и снаружи смотреть. Внешние проверки работоспособности должны обращаться снаружи - проблемы доступности вашего сервера надо диагностировать. А еще мониторинг мониторинга оже должен быть.

По инструментам - по сути уже есть отраслевые стандарты Prometheus + Grafana - стандарт + логи на ELK-стек + Jaeger (Zipkin) для АРМ и трейсинг. Но! Инструменты после задачи и для нее, а не наоборот. Потому что разные инструменты - для разного. Никто не начинает решать задачу "разработай приложение" поднимая базу данных, а начинают проектировать архитектуру. В том числе - выбирая базу данных. А сейчас DeevOps начинают именно с установки инструмента, а потом начинают налаживать мониторинг инфраструктуры, чаще всего не потому, что это болит, а потому, что это - понятная им задача.

Евгений Потапов я только что понял самое смешное, я сделал доклад про мониторинг длиной в 45 минут и 60 слайдов, и на 60 слайдов там нет ни одной картинки с графиками

Stanislav Sysopov В случае рассказа о методологии графики ни к чему

Roman Poborchy Знал бы ты, как ужасны рассказы с "а вот так мы мониторин нашу систему" и скриншот с 12 графиками. Графики редко нужны. =)

Алик Курдюков Евгений Потапов ты просто постиг дао мониторинга :)

Денис Габайдулин Все так. Уже второй проект, где именно такой подход дал нам возможность мониторить именно то, что нужно; а не что есть.

Roman Salin У нас не так, сначала архитектура проекта, всякая: HLA, LLA. Но не по водопаду, некий смешанный подход. Хотя это уже не скрам, конечно.

Александр Волочнев Дима, обнимемся и поплачем. На прошлом проекте несколько месяцев это ПМу объяснял.

Александр Тарасов. Китайские товары (в одноклассниках): просто, дёшево, надёжно

Пост на FB Александр Тарасов. Китайские товары: просто, дёшево, надёжно. Рассказ о том, как внутри устроен сервис одноклассников по продаже китайских товаров. Началось все с того, что в mail.ru появилась платформа, через которую можно делать заказы и отслеживать доставку. А дальше одноклассники стали одним из фронтендов этой платформы, что, вообще говоря, не характерно для социальных сетей. Одноклассники не просто показывают или рекомендуют товар, переходя по выбору в магазин, они еще внутри себя позволяют его купить и ведут заказы, проксируя обращения к внешним сервисам. И им было важно обеспечить доступность приложений при недоступности внешних платформ, а, главное, обеспечить производительность независимо от их нагрузки - набор товаров в ленту надо отдавать за 50мс. Об архитектуре этого решения и был рассказ. Построено кэширование товаров на Cassandra. А внутри - и еще второй уровень кэширования, Off-Heap Map - open source проект одноклассников one-nio, в котором хранятся горячие товары, которые занимают 10% БД и обеспечивают 99% запросов. Правда, для этого потребовался fork Кассандры, в который встроили mutation listener чтобы через него обновлять товары в кэше. И были всякие детали про настройку. Кэш товаров - самая интересная часть, заказы ведут на NewSQL, статистика - Kafka + Hadoop + DWH, эти технологии уже используются и выбраны по однородности.

Андрей Сальников. Борьба с нагрузкой в PostgreSQL, помогает ли репликация в этом?

Пост на FB Андрей Сальников. Борьба с нагрузкой в PostgreSQL, помогает ли репликация в этом? Основная часть доклада была вовсе не про репликации. Она была про типичные проблемы производительности, например, забить все соединения за счет пулов, которые системы поднимают и по факту не используют. Потому что Postgres тянет сотни, а не тысячи соединений. Или открыть транзакцию, и дальше заняться своими делами в backend. А еще - писать в БД все подряд на всякий случай. Все подряд надо писать в логи, организуемые отдельно, а в БД надо писать только операционную нагрузку. Критерий тут в том, что основная нагрузка - читающая, а не пишущая.

Из забавного - PostgreSQL начали использовать так: берем и всю информацию и кладем в большой json. И рекомендация класть основную индексируемую информацию в нативные поля, а в json разделять основную информацию для вывода и все остальное.

И все эти проблемы решаются вовсе без репликаций, и если они у вас есть - то решайте именно их. А уже когда решено - можно подумать про репликации. Делим нагрузку: чтение; insert-update-delete; простые join; count, max, min; where в like '%abcd%'; медленные месячные и аналитические отчеты. Идея - всю статистику и тяжелые запросы уносим на реплику. Потому что они и на основном сервере, выполняясь тяжело, дают устаревшие данные. А для тяжелых отчетов и аналитики - еще одну, отстающую реплику. Асинхронную. Следующий этап - синхронная реплика, из которой мы будем читать данные, а писать на мастер. Дальше пошли детали по настройки потоковой репликации. Основное - понять, что задержка репликаций должна быть разумной, а не минимальной, соразмерной актуальным задачам при запросах.

Филипп Дельгядо О, использование json в БД становится мейнстримом, сколько я к этому шел) Надо бы повторить свой доклад про json в БД где-нибудь.

Максим Цепков Ну, да. Postgres для этого настолько хороший json делал - чтобы не требовалось подключать другую БД. Бартунов об этом в одном из докладов рассказывал. При этом, что интересно, разработку интеграции json в Postgres заказал и финансировал Wargaming, а результат стал доступен всем.

Анатолий Макаров. DropFaaS. Представляя функции как сервис

Пост на FB Анатолий Макаров. DropFaaS. Представляя функции как сервис.

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

Старое решение было основано на кластеризации по региональным серверам, а результате за счет пики суточной нагрузки, еще зависящей от конкретной системы обработки, падали на один сервер, а не распределялся на кластер. Они смотрели промышленные решения (лямбда, от Google, другие), но закрытые не устраивали/ потому что было нужно разворачивание на своих серверах, а открытые на момент исследования были слабые по их требованиям по производительности и по архитектуре. Нужен мастер-мастер, нужна быстрая передача сообщений, да еще с управление на уровне платформы. А еще у них 100+ обработчиков на разных стеках - их нельзя было все переписать. В результате они сделали свой платформу на основе Erlang + docker. Обработчики вытащили существующие, завернули в вызывающую обертку-конфигурацию на yaml, и оно успешно заработало. Цифры результата рассказывали не очень четко, но у них получилось сильно снизить и сделать равномерную нагрузку без оптимизации существующих обработчиков, чисто за счет платформы.

Фичи решения.

• нет выделенных узлов, vip переезжает на другую ноду мгновенно.
• provate spaces - разграничение групп функций по sla - распределение ресурсов между функциями
• управление транспортом сообщений. В контейнерах сеть выключена, только через платформу.
• встраиваемый планировщик, с разными стратегиями - время или ресурсы. И они думают про модель обучения
• есть компрессия потока,
• x86, power8 нативные
• и AWS Support
• Hybrid cloud & fedaration - для ситуативного наращивания мощности. Пока не работает, делают
• объединить две виртуализации - KVM + Container

Это все выложено, в конце доклада ссылка, можно попробовать. Решение они выкладывают в open source и хотят, чтобы проект двигался дальше.

Комментарий Anatoly Makarov в репосте от HL Всем привет! Вот и прошел HL++. Все было оч круто!

Для меня, как докладчика, это первый опыт выступления на таком мероприятии. Хочу поблагодарить всю команду, которая участвовала в организации сего праздника, в особенности Романа Поборчего за профессионализм и очень дельные замечания))

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

Алексей Акулович. CDN своими руками

Пост на FB Алексей Акулович. CDN своими руками. Рассказ про устройство доставки файлов в Вконтакте на региональные сервера для экономии трафика и снижения нагрузки на центральные сервера. Рассматривалась техника определения, на какую из примерно 20 точек направить обращение клиента, на какие данные опираться - они используют информацию BGP о топологии сетей, собственную статистику, потому BGP выдает не быстрые маршруты, а дешевые, а еще GeoIP там где BGP не хватает. И два способа доставки контента на региональные точки - заранее для тяжелого видео и музыки и прокси для фото, документов и остального, с технической и экономической разницей для них. Потому что мощность хранения региональных серверов тоже ограничена, там есть система рейтингов, определяющая, что хранить надо, а что - не надо. Загрузка контента идет на центральный сервер с проксированием в региональном - без этого контент может быть недоступен из другого региона, а это может требоваться сразу.

В вопросах было - а зачем собственный CDN, чем отличается от стандартного. Ответ - сложилось исторически.

Еще вопрос - что нужно, если надо файл удалить, особенно срочно, пришел Роскомнадзор? Ответ: мы ничего не удаляем срочно. А так - есть желтое время, когда клиенту ссылку на региональные сервера не выдают, но она работает для докачки.

Александр Тоболь. UDP против TCP, или Будущее сетевого стека

Пост на FB Александр Тоболь. UDP против TCP, или Будущее сетевого стека. Распространение WiFi обнулили наработки эффективной передачи информации по TCP, обеспечивающей гарантированную доставку. Потому что в обычных сетях потери пакетов свидетельствуют о перегрузке сети, и можно подобрать некоторый оптимальный уровень нагрузки, под которой передача работает стабильно. И развитие шло именно в этом направлении. А WiFi сети теряют и переставляют пакеты просто так, это вовсе не свидетельствует об их перегрузке. И в результате при потерях пакетов всего в 5% скорость существующими алгоритмами снижалась вдвое, и есть еще другие негативные эффекты, связанные с работой с буферами, которая в TCP закрыта от пользователя протоколом. А для конечного пользователя это приводило к тому, что в хорошей WiFi-сети при некоторых настройках ты не мог посмотреть видео, канала не хватало. И, в том числе, потерялся эффект от мультиплексорного соединения http 2.0, потому что поведение tcp под ним изменилось, и его возможности по управлению передачей пакетов в одном соединении не срабатывают в нестабильных сетях, ты не можешь получить контент раньше картинки, а потеря пакета в одном из потоков останавливает все остальные. А еще в TCP существующие протоколы установки соединения и безопасного соединения занимают на таких сетях до 1с, что сильно превышает характерное время ответа сервера.

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

А еще было очень много информации об устройстве сети, о том, как проверять наличие конкретных эффектов, это все доступно, и что и как можно полечить различными настройками, потому что собственный протокол, конечно, дорого. А про будущее - вместо TCP, который окостенел и не может измениться, будет quic от Google, реализованный поверх UDP, и http 3 поверх него. И не верьте тем, кто говорит про отсутствие выигрыша - все тесты были на хороших сетях, и там он не хуже - а вот на плохих он есть.

И это - частный случай вот какого любопытного процесса: требования высоконагруженных приложений влечет развитие технологий, появление альтернатив к ведущей технологии. В результате те задачи, о которых разработчикам не надо было думать, потому что их обеспечивала ведущая технология, опять становятся предметом его заботы. Так появление NoSQL баз данных и последовавшее хранение разных данных в разных базах снова вызвало задачи обеспечение консистентности и транзакций, которые были актуальны в 90х, до повсеместного распространения реляционных БД, которые их решали внутри, и я это очень четко увидел в разных докладах 2013-2015, они напомнили задачи, которые решались в 90-х.

Артемий Рябинков. Практики, особенности и нюансы при работе с Postgres в Go

Пост на FB Артемий Рябинков. Практики, особенности и нюансы при работе с Postgres в Go. Казалось бы, в чем проблема работать с Postgres в Go? Обе не то чтобы стабильные, но достаточно устойчивые технологии, берешь нужные расширения и драйверы и работаешь. Ну да, надо знать, что именно стоит взять, потому что расширения и драйверы появляются более совершенные, и полезно брать именно их, а не работать на старых, и в докладе говорили про преимущества расширения jmoiron/sqlx и новый драйвер jack/pgx вместо lib/pq.

Но, оказывается это не все и есть нюансы, которые обходятся недокументированными путями, и некоторые из них возникают почти сразу. Например, у Postgres есть ограничение на число соединений к БД, потому что на каждый из них создается отдельный процесс, их не больше сотни, поэтому перед БД ставят PgBouncer, организующий пул соединений, и еще часто организуют пул соединений на клиенте. При этом соединение выделяется не на сессию, а на транзакцию, иначе эффект не будет достигнут. А тут возникает проблема с prepared statement и текстовой передачей параметров, из-за того, что одно соединение используют разные пользователи. Выход - переход на бинарную передачу параметров, которая undocumented и совместимость не гарантируется, но драйвер обеспечивает ее из коробки и прозрачно, поэтому не очень опасно. Ну или отказ от prepared, на php они их не использовали, но на Go решили сразу работать "по уму". Или еще нюанс - при подъеме нового соединения идет несколько служебных запросов к базе данных. В результате именно тогда, когда база данных под нагрузкой и уже поднятые соединения заняты запросами, мы поднимаем новые соединения, которые сразу же грузят БД служебными запросами и все падает. И это поправили костылем, тоже через недокументированные возможности - сделали прокладку, которая служебные запросы не отдает в БД, а сразу выдает на них ответ.

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

Андрей Евсюков Не знаю, было ли это в докладе, но с Pgbouncer некоторые расширения в Go не умеют правильно работать. Когда коннект отваливается по таймаут, приложение думает, что коннект живой, а ошибку получаешь уже когда запрос делаешь. Проблему обошли тем, что либа сама понимает, что проблем в протухшем коннекте и сама совершает переподключение. Но это как раз умеют не все библиотеки.

Владимир Красильщик. vert.x против классической многопоточности в JVM

Пост на FB Владимир Красильщик. vert.x против классической многопоточности в JVM. Есть классическая реализация многопоточной работы - потоки и синхронизация через разные очереди, локи и другие известные методы. А есть альтернативные модели, и одна из них - Actor model, независимые агенты, обменивающиеся сообщениями в асинхронном режиме. Дальше эти сообщения передаются адресатам, который может ответить, и для этого крутится реактор - event loop, который читает очереди сообщений и вызывает акторов для обработки. vert.x реализует многореакторную обработку, но при этом гарантируется, что сообщения одного актора обрабатываются в одном потоке, поэтому он может просто сохранять внутреннее состояние в своей памяти, не заботясь о синхронизации. И в докладе было несколько задач с живой демонстрацией решений классическим методом и на vert.x: поставщик-потребитель с буфером между ними для компенсации неравномерной работы; много читателей на одного писателя, обновляющего данные только когда никто не читает. Интересно тут, что классический метод использует разные готовые способы синхронизации - блокирующую очередь, или локи, и в решении в акторной модели модель - одна, и ты сам пишешь агента синхронизации - он крутит циклы, читает и посылает сообщения, и у тебя поэтому гораздо больше свободы. И при этом код этого агента получается достаточно простым и понятным. В конце была задача обеда философов, когда для еды нужно две палочки, а их всего по одной, тут тоже было классическое решение и решение на vert.x, но уже не в акторной модели, а через использование разделяемого доступа к именованным объектам, которая там тоже реализована как базовый механизм.

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

Фрол Крючков. Шаблоны проектирования микросервисов на примере Авито

Пост на FB Фрол Крючков. Шаблоны проектирования микросервисов на примере Авито. Как сказали, представляя докладчика "Уже 4 года avito пилит монолит и рассказывает про микросервисы". Основная цель этого распила - дать возможность командам независимо дорабатывать и поставлять фичи. При этом, чтобы было понятно, в исходном состоянии в 2016 монолит делали 100 разработчиков, и выходило 1-2 релиза в день, но не больше. Это не устраивало...

Три шага. Сначала просто выносили автономные части. Не помогло, потому что фронтенд оставался единый, и развивать отдельно такой сервис не имело смысла. Второй подход - прочитали про DDD и bounded context, попробовали так выделить сервис магазинов для пользователя (набор связанных изменений). Вроде все было логично, но оказалось, что выделенный контекст сильно связан с базовым функционалом подписки, и сервис получился сильно не автономным, независимое развитие по факту не получилось. И третий шаг, понимание необходимости тщательного анализа и выделения ограниченного контекста. Так сделали сервис профиля пользователя, 12 таблиц и 60 входов. Вроде довольны.

После этой истории и основного совета про правильное выделение контекста было пара технических светов. Нужна хорошая реализация null object pattern - когда отказ одного микросервиса не приводит к каскадному отказу системы в целом. Например, отказ сервиса, который рисует определенный фрагмент страницы приводит к тому, что только эта часть на рисуется, а не все. Итого, у вас при запросе есть AbstractCustomer, от которого унаследован RealCustimer и NullCustomer - заглушка.

И правильное обращение к микросервисам: при отказе нужен timeout, повторное обращение, переключение на копию. Неверная настройка таймаутов может привести к тому, что верхние сервисы начинают попытки повторных вызовов, в то время как внутри продолжается работа над предыдущими ненужными запросами. Нужна правильная каскадная настройка таймаутов.

Vitaly Levchenko Таймауты — огромная проблема, разработчики по опыту не умеют с ними работать и понимать как то что сделано реально реагирует на проблемы. Ex. при health check 30с таймаут внутри = потеря запросов за всё это время. Я люблю Go за context, позволяющий каскадно остановить исполнение запроса при отключении клиента. Удобных аналогов не видел

Филипп Дельгядо Ну, на потоке сервисов такая каскадная остановка будет дороже, чем "доделать". А внутри сервиса в каком-то смысле пофиг :) Но вообще проблему таймаутов надо решать нормальной асинхронной работой и проработкой логики взаимодействия. Схему настойки таймаутов сделать хорошо - невозможно.

Мария Мацкевичус. Как мы обучили нейронную сеть классифицировать болты по фотографии

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

Фишка в том, что не просто берем нейронную сетку и обучаем, а разбиваем задачу на несколько, каждую решаем по-своему, потом объединяем. Первый шаг - выделение объекта. Нет, был еще нулевой - они придумали, что вместе с болтом надо сфотографировать монетку, она будет масштабом. А потом - первый. На фотках в каталоге фон - одинаковый, было понятно, что в реальных фотках он был разный, поэтому взяли физические болты и отфоткали на разных фонах. И обучили нейронную сеть выделять объект. При этом она хорошо опознавала болты сложной формы, которых в обучении не было. Следующий шаг - придумали поделить болт на 3 части - головку, острие, ствол, и каждую распознавать раздельно, и еще отдельно - материал по цвету на фотке. Но тогда распознанный объект тоже надо разделить. Первый подход - опишем прямоугольник, вычислим наклон, а головку определим по той половине, где площадь больше. Сработало, кроме очень коротких болтов, вокруг которых прямоугольник становился квадратом произвольной ориентации. Поэтому на длинных болтиках обучили нейронку распознавать угол - и она смогла распознавать угол для коротких тоже. Дальше обучение распознавания отдельных частей, и тут на старте были использованы готовые частично обученные сверточные нейронные сети, которые уже умели распознавать основные геометрические формы, и оставалось только научить опознавать их комбинацию в требуемый объект - это требовало гораздо меньшей выборки. С распознаванием материала оказалась засада - поскольку материал болтов отражающий, то цвет сильно зависит от освещенности. Решение нашли в инете - китайцы распознавали цвет автомобилей. они тоже отражают и там было решение с промежуточной нейронкой, которой воспроизвели.

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

И я понял, что этот рассказ мне напоминает. Это история про аналитические интегрирование. Есть множество методов и приемов и есть задача проинтегрировать конкретную функция. Результат неизвестен, способы - тоже, многие методы трудоемки. Берешь и делаешь, и еще надо знать множество методов, уметь их применять, не ошибаться... А еще - это вполне себе многошаговые технологические задачи со своими этапами проектирования, а вовсе не одношаговые, как было несколько лет назад. Зато - с решением нишевых специализированных задач а не задач общего характера, вчера я слушал про проектирование зубных протезов, сегодня - про распознавание болтов...

Евгений Журин. Детектор ботов, или Как не выплеснуть с водой ребенка

Пост на FB Евгений Журин. Детектор ботов, или Как не выплеснуть с водой ребенка. Основная техническая фишка доклада - это решение для обработки супер-больших графов, таких как граф связности пользователей одноклассников. Прежде чем делать свое, они пробовали решения от Sparx и FB - на их объемах не работает. Что касается борьбы со спамом и выявления спамеров, то, на мой взгляд, в докладе были относительно очевидные вещи про анализ профилей, социальных связей, поведения и работы с контентом в формате "взяли гипотезу - проверили - результат". Проверка - по массиву тех пользователей, которых за спам уже заблокировали. Гипотезы - относительно очевидны. Увлекательной истории про борьбу со спамерами, методы выявления и блокировки и перестройку спамеров для борьбы с этим нам не рассказали, хотя на одном из графиков как раз было показано: включается новый алгоритм - две недели бизнес-метрика показывает успех борьбы, потому возвращается к прежнему состоянию, и наверняка это не единичный случай. А так понятно - успешные гипотезы включаются в автоматический алгоритм, дальше модераторы подтверждают, насколько я понимаю, каждый случай или через выборочные проверки потому пользователи блокируются, но следят, чтобы одновременно блокировок не было слишком много, чтобы не захлебнуться в потоке жалоб.

Александр Крашенинников. Паттерны хранения и обработки данных в ClickHouse

Пост на FB Александр Крашенинников. Паттерны хранения и обработки данных в ClickHouse. Рассказ о тех шаблонах использования, которые уже наработало Badoo, используя CllickHouse. При этом в шаблонах фокус на обеспечение производительности и хорошего размера БД, и такие приемы, как запись ненулевого номера события только в последнюю запись порции, потому что если писать в каждую, то значения не сжимаются, или запись разницы между временами событий вместо самих времен по тем же соображениям. Были конкретные приемы обхода ограничений ClickHouse на построение join, шаблоны создания сложных и производных таблиц - materialized view, distributed, buffer, merge и другие шаблоны. Из любопытного - materialized view можно делать над таблицей с движком null, которая сама не хранится. В конце был рассказ про java-proxy для clickhouse jdbc-bridge, работает на быстром протоколе raw binary: ClickHouse через этот механизм может пойти в другие БД, это для тех, кто не любит odbc и любит java. Это разработал сам Александр, в основной репозиторий не включено, он надеется, что это временно, а в докладе была ссылка. Для меня заглянуть внутрь технологии было любопытно.

Алексей Учакин. Почему Интернет до сих пор онлайн?

Пост на FB Алексей Учакин. Почему Интернет до сих пор онлайн? Действительно, странно. Потому что в рассказе было вскрыто много проблем интернета, начиная от протокола BGP, на котором построена вся маршрутизация, и по которому описывают маршруты соединения около 70k сетей, составляющих сейчас интернет. Он был в 1989 году придуман на 3 салфетках, и является trusted-протоколом: никакой проверки, полное доверие соседям. В принципе проверки предусмотрены, но реально их никто не ставит. В результате - угон префиксов, утечка маршрутов. И, тем не менее, в целом все работает. Хотя проблемы регулярно случаются, например, в декабре 2018 50 часов лежал 3-й провайдер интернета CenturyLink просто потому, что сетевая карта вышла из строя и начала слать неверные сообщения по этому протоколу.

Остальные проблемы связаны с субъектами. Крупными игроками, такими как google или amazone, которые делают собственные сети доставки контента до последней мили, в результате чего интернет рискует превратиться в нескольких крупных сетей и отдельные слабо связанные островки конечных провайдеров. Государствами, которые очень хотят рубильник для отключения интернета или отдельных сервисов, и Россия тут не пионер - Иран, Индия, Пакистан и даже Англия опережают, не говоря уже о Китае. А еще регулярно повторяющиеся DDoS-атаки: средняя продолжительность падает, но растет интенсивность, было зафиксировано 1.7 Tb/c.

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

В вопросах было про IPv6. Ответ - их два, два топовых провайдера не договорились, и они не принимают трафик друг друга. Топология v6 и v4 - принципиально отличаются, и нельзя говорить, что он production ready. А еще - проблемы BGP остаются, и все остальное тоже. И еще вопрос про DNS - его он намеренно не включил, там свои проблемы, DNSsec должен решить, но когда он расползется - непонятно... Недавно отменили поддержку легаси, которому 20 лет...

Вадим Подольный. Высоконагруженная распределенная система управления современной АЭС

Пост на FB Вадим Подольный (Vadim Podolny). Высоконагруженная распределенная система управления современной АЭС. Вадима я слушал осенью на Highload, а здесь было продолжение рассказа про их высокопроизводительную систему обработки данных в памяти с прикольным названием CoreShock для ядра и WhereShock для внешнего интерфейса. Была раскрыта архитектура, и задачи, ради которой они это делают. Задача интересная и необычная: поток сообщений от датчиков, поступающих online, в общем случае, превышает возможности обработки, и поэтому нужна управляющая деградация, убирающая из рассмотрения лишнюю информацию от тех датчиков, где не происходит ничего интересного. Как я понимаю, учитывая рассказ осенью, фишка в том, что это нельзя делать локально: в случае особой ситуации по одному из каналов нужна детальная информация по всем смежным каналам для анализа инцидента. В целом у них получается распределенное по кластеру вероятностное хранение в памяти, которое может работать в локальном или внешнем облаке, где железо тоже предусматривает горячую замену без потерь, репликация осуществляется между памятью узлов, а персистентное хранение обеспечивается сбросом информации в Postgres и/или ClickHouse, которое идет фоном и отложено. В планах - следующая версия ядра, в которой они еще хотят попробовать перейти на FPGA с Xeon E5 - у них задачи высокопроизводительной численной обработки, и FPGA, по оценкам, позволит ускорить втрое. В вопросах было, почему не смотрят на gpu, если проблемы с производительностью Ответ - потому что для GPU не делают сетевых карт, это под другие задачи. А вот когда подключим тензор flow для аналитики - вот тогда будут gpu.

Это был заключительный доклад конференции.

Вадим Подольный Персистентность, все же, в системе реализуется.

Максим Цепков Ну, кстати да, тут получается очень интересное явление: персистентные данные в inmemory database, живущей в вечном облаке. Раньше это казалось оксюмороном...

Вадим Подольный Если умрут все узлы, включая "последний узел" то персистентность рушится, то есть это научно называется "частичная персистентность". Но в целом ...

Максим Цепков Если умрут все сервера и бэкапы то персистентность тоже рушится. Фишка в том, что раньше умирание узлов считалось гораздо более вероятным, чем умирание серверов и бэкапов, а сейчас получается, что это не так, это одного порядка вещи :)

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 01:06, 12 мая 2019 • нет комментариев