Привет, Хабр! Меня зовут Вова, я разрабатываю observability-платформу в Ozon. Как-то раз в наш уголок на 42 этаже заглянули коллеги — и поделились наблюдением. Если открыть рядом графики времён запросов и ответов двух живущих в Kubernetes и общающихся между собой микросервисов, то иногда можно наблюдать большую разницу в высоких квантилях: клиент считает, что один ответ из сотни ему приходит за сто миллисекунд, сервер же говорит, что успевает ответить за десять.

Куда ушло время? Можно ли его вернуть? Под катом расскажу о том, с какими граблями может столкнуться микросервис, живущий в типичной инсталляции Kubernetes.

Это история одного моего хобби-проекта - создания встроенной в интерьер майнинг-фермы с видеокартами в масле, которая своим теплом отапливает лоджию.

1. Идеальный. От рождения до смерти следить за зубами.
2. Типовой. Обратить внимание на свои зубы в возрасте примерно 30–40 лет. Вылечить кариес, наладить правильную гигиену. Это когда не просто горизонтальными движениями щёткой по зубам. И зайти к ортодонту и ортопеду. Если вы достоверно точно знаете, что с опорным аппаратом зубов у вас всё ОК, то можете пропустить этот шаг.
3. Сложный. Когда вам уже 60 лет и вставную челюсть не хочется. Это, конечно, уже не про экономию, а про съёмные протезы и профилактику пародонтита.

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

Есть мануалы о том, как настроить связку NiFi и NiFi Registry со включенной аутентификацией и авторизацией. Но... используются самоподписанные серты.

Есть отдельные мануалы, как прикрутить коммерческий серт для NiFi; соответственно для NiFi Registry "кагбэ так же". Но взаимная аутентификация и авторизация будет происходить с использованием Two way SSL... а у нас же LDAP... и обеспечить потом связность сладкой парочки с использованием только внешнего каталога у вас на голой интуиции не получится.

Есть мануалы по связке с LDAP и для NiFi, и для NiFi Registry. Нооо... как и в предыдущем "но", возникают вопросы, как обойтись потом только LDAP'ом, потому что у нас же еще NiFi Cli, а он в LDAP не умеет.

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

Адрес TCP/IP поддерживает только 65000 подключений, поэтому придётся назначить этому серверу примерно 30000 IP-адресов.

Существует 65535 номеров TCP-портов, значит ли это, что к TCP-серверу может подключиться не более 65535 клиентов? Можно решить, что это накладывает строгое ограничение на количество клиентов, которые может поддерживать один компьютер/приложение.

Если есть ограничение на количество портов, которые может иметь одна машина, а сокет можно привязать только к неиспользуемому номеру порта, как с этим справляются серверы, имеющие чрезвычайно большое количество запросов (больше, чем максимальное количество портов)? Эта проблема решается распределением системы, то есть кучей серверов на множестве машин?

1. Мессенджер WhatsApp и веб-фреймворк Phoenix, построенный на основе Elixir, уже продемонстрировали миллионы подключений, прослушивающих один порт.
2. Теоретические возможности на основе протокола TCP/IP.
3. Простой эксперимент с Java, который может провести на своей машине любой, если его всё ещё не убедили мои слова.

Существует великое множество статей об оптимизации PostgreSQL — эта «кроличья нора» весьма глубока. Когда несколько лет назад я начал разрабатывать бэкэнд аналитического сервиса, у меня уже был опыт работы с другими СУБД, такими как MySQL и SQL Server. Тем не менее, раньше мне не приходилось так фокусироваться на производительности. В прошлых проектах, над которыми я работал, либо не было жестких требований к времени обработки (DS/ML), либо не требовалось обрабатывать много строк одновременно (обыкновенные веб-приложения). Однако в этот раз мои запросы:

• состояли из 3-10 JOIN-ов по коррелирующим запросам;

• уielded от 10 до 1,000,000 строк;

• должны были выполняться в течение времени, определенного UX-ом;

• не могли быть hinted — пока Cloud SQL, управляемый PostgreSQL в Google Cloud, не стал поддерживать pg_hint_plan в конце 2021 года;

• запрещали прямой доступ к серверному процессу, чтобы, например, хакнуть некоторые perf — потому что PostgreSQL был managed.

Получение целого миллиона строк в одном API endpoint сигнализирует о проблеме в алгоритме или архитектуре. Конечно, все можно переписать и перепроектировать, но за это нужно платить.

У нас не нашлось «заклинания», которое решило бы все проблемы с производительностью SQL. Тем не менее, я упомяну здесь несколько дельных предложений, которые помогли нам и, надеюсь, смогут помочь читателю. Разумеется, это не какие-то сакральные знания. Но когда мы начинали оптимизацию, я был бы рад их прочитать или услышать.

• Знание ООП и структуры данных;
• опыт разработки на Java для Android.;
• знание Android API, понимание архитектуры Android;
• знание основ HTTP, XML, JSON;
• опыт работы с системами контроля версий Git;
• опыт работы с Android Studio, Gradle;
• опыт работы с SQL базами данных;
• знакомство с принципами Material Design;

1. Конфигурационные файлы.

Вместо введения

Прощай Evernote

Перевод статьи об альтернативе сервису ведения заметок Evernote.

Давайте разберем самые Часто Задаваемые Вопросы, или сокращенно FAQ. Они помогут вам глубже понять тонкости и принцип работы с Ansible. На ранних этапах можете использовать эту статью как некую шпаргалку.

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

Когда вы автоматизируете какую-либо задачу, например, упаковываете свое приложение для Docker, то часто сталкиваетесь с написанием shell-скриптов. У вас может быть bash-скрипт для управления процессом упаковки и другой скрипт в качестве точки входа в контейнер. По мере возрастающей сложности при упаковке меняется и ваш shell-скрипт.

Все работает хорошо.

И вот однажды shell-скрипт совершает что-то совсем неправильное.

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

Понимание того как Kubernetes обрабатывает контейнеры дает большую гибкость при создании пользовательских конфигураций под конкретные нужды.

Kubernetes позволяет выполнять много полезной работы без глубокого понимания деталей. Утилита командной строки kubectl и дашборды в Openshift помогают управлять вашими контейнерами. Однако, как только вы заглянете глубже в Kubernetes все может быстро усложниться.

Тем не менее, понимание того, как основные части взаимодействуют друг с другом, является важным для главного архитектора, который использует Kubernetes в своих проектах. Проведем аналогию с обычным архитектором: для проектирования небоскребов важно знать прочность на растяжение железобетона в сравнении с балками из чистой стали. Также полезно понимать как работают системы отопления, вентиляции и кондиционирования воздуха.

Такая аналогия правдива и для работы с Kubernetes. Просто сказать: "Давайте оставим это на усмотрение разработчиков" - недостаточно, с таким же успехом можно предоставить выбор системы кондиционирования обычным рабочим со строительной площадки. За каждой хорошо спроектированной системой стоит как множество деталей, так и архитектор, который понимает их значение.

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

Продолжаем цикл статей об организации мониторинга. В первом материале разбирали, как и куда вообще имеет смысл навешивать алерты. Теперь поговорим о мониторинге базового серверного ПО, которое встречается в работе практически любого веб-проекта. Хочу поделиться метриками и алертами, которые мы в ITSumma используем для мониторинга виртуальных машин, docker/LXC-контейнеров, web- и application-серверов, supervisor’а, кастомных сервисов, а также ping-url’ов, SSL-сертификатов и доменных имен.

Каждый разработчик потоков Nifi сталкивается с тем, что через некоторое время потоки начинают повторятся. Бизнес хочет получать данные не по одному расписанию, а к определённым моментам времени. И возникает ситуация, когда управлять большим разросшимся потоком становится неудобно и сложно. Устранять ошибку проектирования приходится в десятках процессоры группах. И так далее...

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

Выкладываем запись с Ozon Tech PostgreSQL Meetup. Ранее я уже описывал нашу инфраструктуру: весь PostgreSQL основан на виртуальных машинах — 2К в тестовой среде и ~8К в проде. Это около 2К кластеров баз данных. Так как у нас микросервисная архитектура, мы придерживаемся принципа 1 сервис = 1 база. Нагрузка на базы может быть приличная: 2-2,5 млн транзакций в секунду, а WAL-трафик порядка 1.5 ГБ/c. 

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