По просьбе одного из клиентов, попробуем скептически рассмотреть поданные доклады на ближайший якобы HighLoad.
Судя по всему - эта конференция не совсем верно называется. Это не совсем про HighLoad а про “мозг”. То есть проблемы компетенций в соседенем с 1С мире также наличествуют - большая часть доклада лежит в плоскости проектирования систем, применению CICD и другого Continous. Те или иные вопросы примерно в том же ключе, затрагиваются и на Инфостарте - так что похоже на то что мы (в 1С сообществе) не умней и не глупей соседей.
первый подход:
Docker
Docker в Букинге
Все кто начинают использовать docker в продуктиве собирают все возможные и причем свои грабли, хотя их можно было избежать если знать ключевые особенности. Докер в продутиве начинается не с контейнеров - их вагон, а с выбора оркестратора, виртуализатора и способа организации блочных устройств, то есть персистетных (постоянных) дисков. Как только ты выбрал - дальше ты просто контейнеризируешь приложения и объединяешь их в стек, горизонтальное машстабирование сейчас идет из коробки с флагом --scale. Дополнительно придется пережить безопасников и истории с серой сеткой внутри докер контейнеров. И конечно развертыванием собственного хранилища образов. Но букинг судя по докладу решил пойти по стартаперски и все грабли собрал на продуктиве, вместо того чтобы вначале пойти по правильному и почитать мануалы ;-).
Docker в Авито
- я так понимаю они научились пользоваться Кубером и подключили Prometeus/ELK/etc
Вообще такое слышать странно, оркестратор контейнеров, как и виртуализатор требуют мониторинга и сбора показателей, а затем изменение разных параметров. Собственно так работали с OpenStack (CloudStack), HyperV и т.д. - как уже было сказано выше, флаг --scale он же автоматически запускается в зависимости от показателей счетчиков. 1С-никам предположительно светит как Кубер, так и возможно ZooKeeper. Наверное это Хайлоад. Но по моему нет - вот когда авторы Docker показывают 30.000 контейнеров развертываемых под нагрузку в 7 дата-центрах по миру: вот это хайлоад. 
Docker и базы данных
как я написал выше, в докерах придется разбираться с дисками, а если с дисками которые переживают пересоздание контейнеров придется разбираться, то большой вопрос: куда девать базы данных - в контейнеры или нет. Это не к хайлоаду имеет отношение, а скорее к пониманию docker как такового. А также наличия внезапно мультимастеров в СУБД, а поэтому рядом же в докладах летят 2 разных решения
-
Apache Kafka - здесь уже есть опыт по работе и граблям с этим распределенным журналом транзакций, но оно открыто и интересно и как мы помним требует долгого кодинга клиента, потому что это “тупой сервер”.
-
Neo4J - а эта хрень хоть и имеет красивый сайт https://neo4j.com/, но тащит за собой обычно программно-аппартные комплексы Terradata и HP Vertica, которые если кто не знает стоят под 300 килобаксов и горизонтально маштабируются способом закупки еще одной стойки за новые 300.000 баксов (хорошо хоть линейно). И опять - это наверное Хайлоад, но на последнем Инфостарте мы это уже тоже разбирали: большие базы и дорогие серваки с POWER8 процессоры это конечно круто для похвальбы в курилках, но стоимость владения этим такая огромная, что повторить такое смогут только 10 компаний в России максимум. И вот приедут люди - облизнуться и уедут обратно.
PostgreSQL
Я очень уважаю сообщество консультантов PostgreSQL, и скорее всего будут рассказаны какие-то фишки типа “не делайте сервера очередей на базе PG”, но какое это отношение имеет к высоким нагрузкам. Фактически это просьба уметь проектировать БД, тут как раз в Москве проходит курс по теории проектрования баз данных на базе PostgreSQL и курс чуть больше полезен чем доклад на десяток минут.
Почему это Хайлоад то ?.
11-тый PostgreSQL будет круче чем 10-тый - это и так известно. О новшествах рассказывали на Инфостарте и будут в феврале на PgConf возможно с нашим участием в части с 1С.
Репликация в PostgreSQL давно известна, она нужна почти всегда, даже если база маленькая. Наиболее интересные решения у PG.Pro и 2Quadrant. Но можно и WAL-E®. У кого хоть одна база на PostgreSQL есть тот в курсе.
MySQL
- исходная открытая СУБД тормозит
- люди делают деньги продавая не тормозящую открытую СУБД со своими закрытыми наработками и службами мониторинга
- покупают PHP-программисты, которые очень не хотят учить 1С, C#, Java, GoLang, JavaScript (typeScript) и переезжать на PostgreSQL
Apache Kafka
с выжимкой из тезисов докладов
- первый момент “это круто”, жили раньше на другом, стало круто
- второй момент “это больно”, пилили пилили, сервер крутой, но тупой - нужно долго пилить клиент и сделать его умным
- третий момент - если клиент надо делать умным, пришлось искать умную команду, когда нашли клиент напилили даже на PHP, хотя вначале думали что GoLang наше всё
ClickHouse
Здесь примерно как в нашем 1С-ном мире
- казалось что СУБД спасет мир
- и вот мы делаем обработку 1.6 мегасобытия в секунду
- пришлось включить мозг, сразу сходу не получилось
- разработчики делали странное с СУБД, она тормозила
Полнотекстовый поиск
- должен быть !!!
- должен строится на специализированном решении
- возможно применение машинного обучения, если есть умная команда
- может использоваться как основа для A/B тестирования
Ну мы это и так все знали, а уже рекомендательные сервисы для сайтов не писал только ленивый ;-).
Командо-образование
Лаборатория качества и счастье
Вообще непонятно как относится к Хайлоаду, но по умному то что пропагандируется описано в книжках про холократию, бирюзовые организации и в SAFe - наверное это HighLoad менеджмента.
Инфраструктурная команда
Банальные моменты про то что нужно создавать выделенную команду экспертов по производительности и низкоуровневым штукам - это еще называется shadow team (команда тень). Наверное это тоже Хайлоад, но у нас вроде как при крупным внедрениях это тупое требование без которого проект вообще не начнется, а не какая-то там магия.
Кстати я так понимаю - про Яндекс.Облако примерно в эту же степь будут задвигать. Другое дело что Яндекс.Облако - это действительно модно-молодежно, но я так понимаю опять на каких то “почти прорывных” технологиях, которые начнут тормозить через 3 года как ClickHouse
Технический долг
Читаю тезисы и вообще не понимаю при чем здесь Хайлоад. Ну было старое легаси решение, сели прикинули как по компонентно разделить и ввести в продуктив. Так это сейчас все делаю так когда с УПП переходят. С тестами TDD, BDD И Сонаром
Интернет-вещей
Высокие нагрузки в IoT
Принципиально вообще непонятно как так получается, что все считали что интернет-вещей это про кофеварки, всем 1С специалистам которые так или иначе связаны с ERP решениями уже давно известно, что интернет-вещей индустриального уровня он во первых программно-аппаратный и там действительно огромный объем данных. ХайЛоад ли это - да скорее всего, да вот только на этих ваших НЛМК уже давно (я так понимаю лет 20 как) собирают всю теллеметрию и нормально так анализируют. И даже на 1С - без вских БигДата ;-), хотя с бигдатой круче.
Фактические товарищ будет рассказывать про начатое мной обсуждение в соседней теме OPC-UA мост в MQTT
Железки
Linux
Короткий вывод то такой - что Linux администратор нужен, особенно если у вас там PostgreSQL крутится. В целом если у вас Linux - вам в любом случае его нанимать, даже если у вас база 20MB без всяких хайлоадов. А уже он за изменениями в мире Linux ядра должен следить.
Мониторинг
Собирайте метрики иначе будет беда. APDEX имеется ввиду наверное. Для этого не нужен Хайлоад, надо просто пройти сертификацию на 1С:Эксперта.
Разработка
Браузер с нуля
Очередной виток делает история, то мы боролись за JS в браузере - тем вот браузер-парсер HTML на чистом Си и WebAssembly. О чем собственно мы тут пару недель назад и говорили, что HTML придуман для браузера - очередное подтверждение.
Фактически тут нет Хайлоада - тут есть изначально неверный посыл с рекламой HTML для людей
GoLang
Проблемы производительности… А кто говорил что GoLang спасет мир микросервисов ;-). На самом деле GoLang как язык действительно интересен, но его применение то было ориентировано изначально только на одну задачу.
Cloud Native
Как и все вышесказаное в докладе я так понимаю будет сделан упор, что проектирование под облака и докеры придется делать. Нельзя просто так взять и перенести приложение в докер или облако. 1С-ники пытавшиеся сделать 1С и докер давно уже в курсе, что приложение адаптированное сразу под облако будет дешевле в эксплуатации. Но это опять не про хайлоад а про мозг.
Безопасность
Тут наверное дело не в хайлоаде в целом, а в наличии в компании ИТ безопасноти как таковой. А сервисов на данный момент огромное количество под разные базовые задачи - включая например аутентфикацию в облачных сервисах под корпоративными акаунтами внутри периметра с возможностью отзыва доступа.
Дата-инженерия
Никто так нормально и не сформулировал как сейчас стоит работать с большими данными и что это такое: цифровая трансформация только началась, поэтому большая часть докладов не про хайлоад, а про конептуальные подходы - дескать “а давайте анализировать данные”. Странно что про RPA никто ничего не говорит.
Hadoop
- это еще работает
- запускается тяжело
- распределенные микрохранилища на микросервисах наступают на пятки
Дата-инженер
- собственно ИТ стандарт по этому поводу уже опубликован
- требует 2 курса профильного инженерного института с математической статистикой на борту как минимум.
- нам как 1С-никам также стоит присматриваться к сложным прогнозно-аналитическим инструментам - у нас то в каждой базе по террабайту только структурированных данных, а если еще журналы регистрации анализировать - то тут совсем интересно становится.
Настоящий хайлоад
А он всегда программно-аппаратный, например на АЭС или при работе с видеопотоком или при работе с устройствами на промышленном (индустриальном уровне). Все только программные решения на мой взгляд хайлоадом не являются.
Продолжение следует…