Yappi Days 2018. Впечатления

Изначально не планировал идти на эту конференцию, но привлекли пара докладов и свободная суббота, так что решил сходить.

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

Изначально у конфы не заявлена специализация, просто конференция для разработчиков (видно, чтобы собрать всех желающих программистов Ярославля, кстати, их удивительно много, и занимаются интересными вещами, удивился). В результате, темы были весьма разными (чтобы всем хватило), а сложность докладов очень низкая, местами очень капитанская.

При этом, доклады от спонсоров очень хорошо выделялись своей очевидностью и рекламой. Например, доклад про PVS-Studio был всего-лишь рекламой PVS-Studio (продукт, кстати, хорош, и на стенде очень плодотворно пообщались с разработчиками), доклад от Тензора поразил своим абсолютным, нереальным отсутствием практического смысла (рекламировалась внутренняя утилита компании Тензор, т.е. её не увидеть, не пощупать, и использовать можно только если ты работаешь в Тензоре).

Также, у организаторов вышла лажа с порядком докладов: вначале Владимир Ильмов рассказывал про Netflix стек для микросервисов и докер у него был как базовая концепция, а затем был доклад про то, что такое докер в принципе. Совсем не понял, в чём был смысл доклада от CUSTIS, назывался он "Как работает браузер", в реальности человек начал рассказывать про то, что такое DNS, как в http передаются заголовки. Т.е. такой вымученный доклад, лишь бы что-то рассказать (да, я даже в лекции для студентов старался держать уровень выше). При этом CUSTIS никак себя не рекламировал (не было стендов), и смысл им рассказать один бестолковый доклад — я так и не понял.

Конечно, т.к. было 3 потока, я не мог посетить все доклады, возможно, я пропустил что-то интересное, но общее впечатление весьма посредственное. Причём именно из-за докладов — слишком обще, слишком просто, слишком про всё. Надо специализироваться и повышать уровень. И ещё раз скажу, с организацией всё было отлично, а халявные пиццы от Пиццы-Фабрики очень рулили.

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

WireGuard

Сегодня Роскомнадзор в очередной раз забанил подсеть Амазона (или хостер пофиксил "проблему"), в общем пришлось заворачивать всё в VPN, что привело к весьма печальной скорости работы сервера, т.к. VPN был далеко.

Решил поднять его поближе, в Azure, а т.к. в нём весьма грустно с фаирволлом, решил попробовать новый хипстерский VPN под названием WireGuard. Правда потом оказалось, что VPN всё-таки можно было попробовать устроить, но у меня оказалась неправильная виртуалка, в которой всё делается через жопу. Надо было создавать другую и гуглить как в азуровом фаирволле сделать проброс чего-то отличного от TCP и UDP.

В общем, WireGuard позиционируется как простой и правильный VPN, без кучи опций и настроек. Просто работает. И в целом да, только оказалось, что это нифига не VPN в привычном понимании (хотя технически да, и виртуальная, и частная, и сеть).

Что хочется получить от VPN:

• Стабильной работы (у всех существующих решений всё плохо)
• Простой конфигурации (PPTP рулит)
• Безопасности (SSTP, L2TP/IPSec, OpenVPN)
• Выдачи IP адресов (все умеют)
• Выдачи маршрутов (у всех очень грустно)
• Выдачи доп. настроек (ещё хуже)

При этом, стоит напомнить про такую технологию как IPSec, которая не является туннелем сама по себе, т.е. не приносит дополнительных интерфейсов и IP-адресов, а просто безопасно заворачивает IP пакеты в себя. Т.е. идеально подходит для связи Server-Server или Сеть-Сеть через конкретные шлюзы. Для динамики и NAT подходит весьма плохо.

И вот тут вылезает WireGuard. Что же он делает?

• Создаёт отдельный сетевой интерфейс
• На него руками необходимо назначить IP (wat?)
• Клиент и сервер в целом не разделяются (привет IPSec), они равнозначные пиры (peers), но в целом можно использовать концепцию клиент-сервер, просто сделав определённые настройки
• Если нужно устроить VPN, то можно сделать это ручками через iptables и маскарад
• Каждый пир определяется парой ключей (публичным и приватным), так что заранее на сервере никого не добавить (можно нагенерить ключей, но как-то коряво выглядит)
• По умолчанию роуты связаны со списком разрешённых IP'шников, т.е. делаются на клиенте, проброса нет

Так что получается, что это какой-то упрощённый IPSec, но с отдельным интерфейсом и IP-адресом (без добавления, думаю можно извернуться, но уже не очень дефолтная конфигурация). Т.е. использовать его как VPN — можно, но очень фигово (хотя если для себя делаете, то вполне норм). И с VPN'ами по-прежнему всё тухло, а WireGuard оказался каким-то странным созданием.

Но с другой стороны, настраивается он элементарно и начинает сразу же работать. Это ему плюс. Только имейте в виду, что конфигурация через wg-quick и ip работает по-разному, через ip можно сделать гораздо больше и и точнее.

Хранение данных в памяти

Очень давно вынашиваю идею о том, что базу данных для приложения стоит размещать в памяти. Конечно, не полностью в памяти, основную базу оставить, но использовать очень и очень агрессивное кеширование. Зачем? Об этом ниже.

Для начала скажу, что сам я, пока так и не реализовал эту идею в полной мере, были продукты, где это активно использовалось, но в основном, продукты, за которые я ответственен работают достаточно быстро и так, так что как-то и не требуется усложнение и смена парадигмы. Но, когда-нибудь, обязательно попробую!

Почему не стоит полагаться на кеш SQL-сервера?

Потому что он построен именно на модели кеша для данных, и в него можно попадать или не попадать. Конечно, в MS SQL есть OLTP таблицы, которые хранятся в памяти, но они больше для очень активных данных, и вообще это на уровне SQL, причём MS SQL. А без них — используются стандартные алгоритмы для поиска, оптимизированные для данных, находящихся на диске, как результат, необходимый кеш для очень 100% попадания в память многократно превышает размер реальных данных.

Я же предлагаю забить на это, и максимально хранить все данные из базы в памяти (загружать их из базы на старте, или ленивым образом).

Что это даёт?

• Резко упрощается внешняя логика пользователя. Во многих случаях можно отказаться от джойнов, если нет дополнительной фильтрации. Например, классический джойн с данных с пользователем (например, вывести автора данных) можно заменить на выборку данных и доставание всех пользователей по ID. Это очёнь дешёво
• Можно использовать очень тупые алгоритмы, и это всё равно будет очень быстро. Фуллскан 10000 записей почти незаметная вещь, а если надо будет ещё быстрее — всегда можно будет прикрутить "индекс" в виде словарика
• Можно избавиться от отдельного кеша для тяжёлых данных, ибо и так всё в памяти
• Тупо быстрее из-за отсутствия запросов к внешнему SQL-серверу
• Легко хранить данные, которые тяжело забирать из SQL (объект с зависимыми детишками, слабо-структурированные документы, JSON/XML поля)
• При этом, если приложение написано с использованием LINQ, то местами можно вообще не заметить разницы между базой и памятью (если грамотно спланировать архитектуру приложения)

 А в память влезет?

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

• База данных в 20ГБ содержит где-то 20ГБ данных (логично, да?), в памяти это будет занимать примерно столько же. Найти подходящий сервер — не так уж и сложно. Естественно, базы в 100МБ вообще влезут в память без проблем
• Очень часто в "больших" базах большой объём занимают всякие полумёртвые данные — журналы, результаты импорта, файлы, подписанные данные, акксесс логи... Эти данные нужны очень редко, их можно не хранить в памяти, тем самым кардинально снизив объём "реальных" данных
• Многие данные нужны только в небольшом количестве. Например, у вас есть 10000 пользователей в системе, но активны только 1000, тут можно использовать какой-нить LRU кеш и не держать в памяти все объекты, а только активные. Опять же, очень сокращает необходимый объём памяти
• Ну и для реально огромных баз данных можно уж держать в памяти только специально выделенные объекты (например, справочники). Хотя, с такими объёмами у вас будет проблем побольше чем просто держать в памяти

Как реализовать?

Поскольку я ещё не делал это в полном виде, то могу только предположить следующие варианты:

• Собственный кеш класса, ратающего с сущностью (e.g. UserManager), он сам решает, что и как кешировать. Проблемы в куче аналогичного кода в разных классах и сложность с инвалидацией. Плюсы: в каждом конкретном случае можно использовать самые эффективные варианты
• Мемоизация и автомемоизация методов. Плюсы: очень упрощается код, минусы: сложно инвалидировать и оптимально использовать данные. 
• Обёртка над ORM (или использование встроенных средств типа Second Level Cache), которая сделает всё сама. Проблемы: сложно в реализации и конфигурировании. Плюсы: полная прозрачность в использовании со стороны кода

Краткий итог

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

Итоги моего 2017 года

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

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

А в этом активно и вплотную занялся .NET Core под Linux, фактически все новые проекты теперь там и живут, и живут весьма неплохо. На работе кроме всякой мелочи был сделан очень крутой проект. Он. конечно выглядит просто и банально, но внутри там очень всё круто, микросервисно, распредёлённо и кешированно. При этом, пока не замучали новыми фичами, он умудрялся жить на мелких виртуалках, используя по максимуму всё, что они предоставляли. Но в конце-концов, один проект превратился в два, с общей и своей частью, я сдался и развёл проект на 3 сервера и разрешил жрать память (хотя слишком разрешил 16 Гигов, съеденных из-за баги доставили много радости в поиске бага).

В остальном, год был похож на прошлый. Был хакатон, но участвовал я один, в итоге "почётное" третьё место. И ещё не внедрено. Продолжаю пилить на гитхабе свой клонятор, Crc32 (теперь ещё быстрее), и архиватор, который уже помаленьку использую в бою и вижу, что у него есть очень интересные фичи. Также нарисовал свой аналог IPSec под названием AutoTunnel, получилось интересно, но надо бы чуть допилить, ибо склейка фрагментированных UDP пакетов со стороны Windows — это боль.

С нетехнической стороны — год отметился путешествиями: Баку, Минск, Кострома, Мюнхен, Тбилиси, Амстердам, Прага... Посетил кучу мест, получил много впечатлений и не собираюсь останавливаться на достигнутом!

К сожалению, со всей этой беготнёй, забыл про новогоднее настроение, но у меня есть ещё 2 дня его найти, буду упорно стараться. Ну а вам его тоже желаю, надеюсь, что оно у вас уже есть и вы готовитесь к самому весёлому празднику, Новому Году.

С Наступающим!

Ненавистный .NET

Последнее время совсем не пишу в блог, как-то нет подходящих тем, могу только сообщить, что такой ненависти к Microsoft я давно не испытывал. Попытка поработать с .NET Core 2.0 сразу же привела к идиотским ошибкам, типа 2 entry point у приложения. При этом второй генерируется самостоятельно (!), другими словами, у Microsoft новые отличнейшие идеи, как всё должно работать по их мнению, вместо того, чтобы просто сделать рабочий продукт.

Если кончится мат и появятся слова, постараюсь написать что-то более членораздельное. Но, блин, у Microsoft был отличнейший .NET, приложения на котором просто работали... Теперь не так, они могут падать по совершенно различным причинам, а Dll Hell уже перешёл все границы. Ну, как, как можно так портить жизнь разработчикам за их же деньги...

Версионирование .NET Core

Когда-то писал про .NET Core и обещал написать больше, но было лениво, так что руки не дошли.

Сейчас просто для понимания бреда, который творится с версионированием краткое описание разных версий. Это может быть полезно, т.к. вышел .NET Core 2.0 и .NET Standard 2.0, и версии слились в экстазе. Но на самом деле они разные, и скоро разъедутся и будут опять портить всем жизнь. Итак, временно забудем про существование 2.0, и вспомним, что есть:

• Вы собрались писать под .NET Core, соответственно выбираете, какую версию хотите, вы можете выбрать версию 1.0 (на момент написания 1.0.7) или 1.1 (на момент написания 1.1.4), при этом, особой разницы в этом нет. 
• На самом деле, вы можете выбрать рантайм или сдк Логично, что для разработки нужен SDK, для версии рантайма 1.0.7, сдк имеет версию 1.1.4 (т.е. рантайм разрабатывается и старый и новый одновременно, сдк только новый)
• После этого, вы можете решить, что использовать, .NET Standard или .NET Core. Для библиотек лучше использовать Standard, у него версии: 1.0,1.1,1.2,1.3,1.4,1.5,1.6, для запускаемых файлов лучше Core, у него версии 1.0 и 1.1
• Впрочем, вы можете писать библиотеки на Core, а экзешники на Standard, в этом не очень много смысла, но в целом он есть
• Версии Standard для удобства используют стандартную библиотеку NETStandard.Library, она бывает версий 1.6.0 и 1.6.1
• В этой библиотеке есть стандартные библиотеки, которые любят называться как большие и иметь версию 4.3.0 (большие имеют версию 4.0.0). Впрочем, иногда бывают и 4.2.0 и 4.1.0, и всякие разные

Т.е. приложение мод .NET Core 1.0 может запускаться в рантайме 1.1.4, иметь зависимость на библиотеку .NET Standard 1.3, которая использует библиотеку NETStandard.Library 1.6.1 и это всё будет замечательно работать! Главное надо понять, что это просто разные версии разных библиотек. 

Сейчас вышел .NET Standard 2.0, и всё стало совсем просто: приложение под .NET Core 2.0 запускается в рантайме 2.0, имеет зависимость на библиотеку .NET Standard 2.0, которая использует библиотеку NETStandard.Library 2.0.0. К сожалению, скоро все эти версии опять разъедутся в разные стороны, и опять будет путаница. Но. надеюсь, вы теперь будете во все оружии.

PS: Сейчас слушаю про version hell в .NET Core 2.0, и становится страшно, там добавили совместимости из-за которой много всего развалилось, несмотря на обещанную совместимость.

Подлые порты

Я тут настроил логгирование входящих запросов из интернета на мой комп, конечно же, меня периодически (раз в час) сканируют. Решил просто поделиться списком портов, которые интересуют "хакеров".  Зачем? Просто для информации, на какие порты обращать внимание, и на какие порты не стоит вешать ваши сервисы, если они настолько популярны, что их ломают, то и ваши сервисы могут попасть под раздачу или флуд.

Собственно, список:

7
9
13
21
22
23
25
26
37
53
79
80
81
88
106
110
111
113
119
143
144
179
199
389
427
443
444
465
513
514
515
543
544
548
554
587
631
646
873
990
993
995
1025
1026
1027
1028
1029
1110
1433
1720
1723
1755
1900
2000
2001
2049
2121
2717
3000
3128
3306
3389
3986
4899
5000
5009
5051
5060
5101
5190
5357
5432
5631
5666
5800
5900
6000
6001
6646
7070
8000
8008
8009
8080
8081
8443
8888
9100
9999
10000
32768
49152
49153
49154
49155
49156
49157

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