Геокодио перешло с MariaDB на ClickHouse, Kafka и Vector для обработки миллиардов запросов. Исходная система на MariaDB с движком TokuDB не справлялась с нагрузкой: токизация базы не обновлялась с 2021 года, производительность падала с ростом данных, а запросы к миллиардам записей приводили к таймаутам.

Новая архитектура распределяет поток данных через Kafka, который направляет их в ClickHouse для аналитики в реальном времени и долгосрочного хранения. Vector агрегирует данные перед загрузкой, что значительно ускоряет обработку.

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

• Основной вывод: авторы обсуждают, как правильно организовать поток данных от источника к ClickHouse, используя Kafka, Vector или Redis в качестве буфера.
• Практика: вместо того чтобы писать в ClickHouse напрямую, они используют Kafka как очередь, а затем Vector для буферизации.
• Архитектура: ClickHouse не предназначен для очень больших объемов вставки, и поэтому требуется внешняя система буферизации.
• Альтернативы: обсуждаются такие варианты как async insert в ClickHouse, использование Redis вместо Kafka, или применение встроенной функции async insert в ClickHouse.

OpenTelemetry Collector: что это, когда нужен и когда нет

Практическое руководство по OpenTelemetry Collector: что делает, как работает, архитектурные паттерны и как решить, нужен ли он вам для производительности, контроля, безопасности и экономии.

Нужен ли вам OpenTelemetry Collector? Для небольших проектов — возможно нет. Для production-среды с множеством сервисов, где важны стоимость, производительность и безопасность — почти наверняка да.

Краткое определение

OpenTelemetry Collector — это нейтральный к вендорам, расширяемый конвейер телеметрии, который принимает, обрабатывает и экспортирует данные (трейсы, метрики, логи) из ваших приложений в одно или несколько хранилищ.

Он позволяет:

• Очищать данные (удалять чувствительные поля, добавлять контекст)
• Пакетировать отправки и повторять при сбоях
• Применять умное семплирование (сохранять ошибки и редкие медленные трейсы)
• Сглаживать различия между версиями SDK
• Маршрутизировать данные в разные хранилища
• Служить защитным барьером между приложениями и интернетом
• Снижать затраты, отсеивая малополезную телеметрию

Архитектура

Без Collector (прямой экспорт)

Каждый сервис отправляет телеметрию напрямую в бэкенд:

Плюсы:

• Проще (меньше компонентов)
• Меньше операционных затрат
• Подходит для маленьких приложений / POC

Минусы:

• Каждый сервис сам handles retries, auth, backpressure
• Сложно менять экспортеры
• Нет централизованного семплирования / очистки / маршрутизации
• Риск misconfigurations
• Выше стоимость исходящего трафика при отправке в несколько систем

С центральным Collector

Все приложения отправляют данные в центральный Collector, который затем экспортирует:

Плюсы:

• Централизованная конфигурация: семплирование, очистка, обогащение
• Один канал исходящего трафика с пакетированием и retry
• Развязывает жизненный цикл приложения от изменений вендоров
• Меньше нагрузки на приложения
• Безопасность: приложения не выходят в интернет напрямую

• Рекомендуется использовать коллектор OpenTelemetry для упрощения архитектуры, локальной отладки и управления аутентификацией
• Предлагается декаплеить коллектор от потребителей трассировок через брокеры сообщений (Kafka/NATS) для надежности и масштабируемости
• Коллектор рассматривается как защитный шлюз (read-only) между приложениями и базой данных для безопасности
• Отмечается сложность освоения OpenTelemetry, но подчеркивается его ценность как стандарта для интероперабельности
• Указывается полезность OTEL даже для монолитов благодаря возможностям корреляции и вложенных спэнов
• Обсуждаются альтернативы (Vector vs OTEL) и необходимость улучшения документации и примеров
• Упоминается использование коллектора для валидации и тестирования с помощью AI-агентов

Как я решил проблему распределённой очереди через 15 лет

В Reddit всё — голоса, комментарии, посты — сначала попадало в RabbitMQ, потом в базу.
Очередь давала горизонтальное масштабирование, шейпинг и cron, но падала: задача могла исчезнуть после взятия из очереди или при краше брокера. Нужны были долговечные очереди, сохраняющие состояние в Postgres.

Сегодня это реализуется через долговечные workflow: каждый шаг чек-поинтится в БД, задачи запускаются параллельно, при падении продолжаются с последнего сохранённого места.

• Пост вызвал спор: одни хвалят вводный уровень, другие ждут разбора «распределённой» сложности и конкретного решения.
• Критика: заголовок обещает «как я решил», но статья не формулирует проблему и не показывает шаги решения.
• Автор подменяет «очереди» «устойчивыми воркфлоу»; читатели считают, что это разные вещи.
• RabbitMQ 15-летней давности обвинили в отсутствии надёжного бэкапа состояния; Kafka, наоборот, приводят как пример «и быстро, и надёжно», но её обвиняют в перекладывании сложности на потребителя.
• Главная идея DBOS: устойчивость без внешнего координатора и без переписывания кода под async-рантайм.

Предупреждение: это сатира, не используйте в проде. Читая, вы клянётесь не повторять описанное.

Проблема

Managed NAT Gateway в AWS тарифицирует исходящий трафик по 0,07 $/ГБ и убивает стартапы счетами за облако.

Решение

Вместо него для веб-хуков можно:

• поднять exit-ноду Tailscale с публичным IP;
• привязать её к той же VPC;
• получить шифрование и экономию до 700 %.
  Это единственный безопасный фрагмент статьи.

---

S3 как очередь

AWS начинался с S3, SQS и EC2. S3 — это malloc() для облака:

• выделяете «память» (бакет);
• кладёте туда объекты любой длины;
• освобождаете, когда надоедает.

Аналогия с C: malloc() → указатель, free() → удаление объекта. Ошибка выделения → ENOMEM, дальше — краш.

---

Как превратить S3 в очередь

1. Писать сообщения в виде объектов с ключом queue/<uuid>.json.
2. Читать через ListObjectsV2 и GetObject.
3. Удалять после обработки.
4. Повторять раз в секунду — получаем «очередь» с задержкой ~1 с и бесплатным исходящим трафиком внутри региона.

Плюсы:

• нет платы за NAT Gateway;
• S3 дёшев и масштабируем;
• можно шифровать объекты.

Минусы:

• eventual consistency: сообщения могут дублироваться или задерживаться;
• rate limit 3 500 PUT/COPY/POST/DELETE и 5 500 GET/HEAD на префикс;
• ListObjects дорогой (0,005 $ за 1 000 запросов);
• придётся реализовать ack/nack, dead-letter и backoff самому.

---

«Продвинутые» техники

• Long polling: ждать, пока в бакете появится новый объект.
• Fan-out: несколько читателей по префиксам.
• Batching: складывать сообщения в один объект gzipом.
• Priority: префиксы high/, low/.
• FIFO: ключ queue/<timestamp>-<uuid>.json.
• DLQ: префикс failed/.
• Крон: Lambda по расписанию чистит старые сообщения.

---

Итог

S3-очередь — это пародия на архитектуру, но она работает и экономит деньги. Для настоящих задач используйте SQS, Kafka или RabbitMQ.

• Участники вспомнили, как в 90-х использовали Microsoft Exchange вместо дорогого TIBCO, а Amazon Video — S3 вместо очереди, и оба решения оказались «костылями».
• Подчеркивают, что очередь — это просто быстрый конечный автомат, но самописные варианты на SQL или Git-вебхуках быстро ломаются под нагрузкой.
• Некоторые шутят, что любую технологию можно превратить в очередь или базу, если использовать её «достаточно неправильно».
• Обсуждают юридические проблемы с IP, когда хобби-проект пересекается с работой, и сравнивают цены AWS с Whole Foods.
• В итоге сходятся во мнении: костыль может работать, но рано или поздно придётся платить за правильное решение.