Рубрика «realtimeboard»

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

  • Для создания и удаления тестового окружения — Terraform скрипты;
  • Для конфигурирования, обновления и запуска — Ansible скрипты;
  • Для динамического масштабирования в зависимости от нагрузки — самописные Python-скрипты.

Благодаря скриптам Terraform и Ansible, все операции от создания инстансов до запуска сервера выполняются всего шестью командами:

#запускаем нужные инстансы в консоли aws
ansible-playbook deploy-config.yml  #обновляем версии серверов
ansible-playbook start-application.yml  #запускаем наше приложение на этих серверах
ansible-playbook update-test-scenario.yml --ask-vault-pass #обновляем Jmeter сценарий, если в нём были изменения
infrastructure-aws-cluster/jmeter_clients:~# terraform apply #создаем jmeter сервера для подачи нагрузки
ansible-playbook start-jmeter-server-cluster.yml #запускаем jmeter кластер
ansible-playbook start-stress-test.yml #запускаем тест

Читать полностью »

Мы задумались о построении инфраструктуры больших нагрузочных тестов год назад, когда достигли отметки в 12K онлайн-пользователей, работающих в нашем сервисе одновременно. За 3 месяца мы сделали первую версию теста, которая показала лимиты сервиса.

Ирония судьбы в том, что одновременно с запуском теста мы достигли лимитов на проде, в результате чего сервис упал на 2 часа. Это дополнительно стимулировало нас начать двигаться от проведения тестов от случая к случаю к созданию эффективной нагрузочной инфраструктуры. Под инфраструктурой я подразумеваю все инструменты для работы с нагрузкой: инструменты для запуска и автозапуска, кластер для подачи нагрузки, кластер, аналогичный проду, сервисы для сбора метрик и для подготовки отчётов, код для управления всем этим и сервисы для масштабирования.

Достоверный нагрузочный тест с учётом непредвиденных нюансов - 1
Читать полностью »

Мы разрабатываем платформу для визуальной коллаборации. Для отображения контента мы используем Canvas: на нём рисуется всё, в том числе тексты. Готового решения для отображения текстов на Canvas один в один как в html не существует. За несколько лет работы с отрисовкой текстов мы изучили разные варианты реализации, набили много шишек и, кажется, нашли хорошее решение. Расскажу в статье, как мы переезжали с Flash на Canvas и почему отказались от SVG foreignObject.

Как мы учились рисовать тексты на Canvas - 1

Переезд с Flash

Мы создавали продукт в 2015 году на Flash. Внутри Flash есть текстовый редактор, умеющий хорошо работать с текстами, поэтому нам не нужно было делать ничего дополнительного для работы с текстами. Но в то время Flash уже умирал, поэтому мы переехали с него на HTML/Canvas. И перед нами встала задача — отображать текст на Canvas как в html-редакторе, при этом не сломать при переезде тексты, созданные во Flash-версии.Читать полностью »

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

У нас высоконагруженный сервис: 2,5 млн пользователей по всему миру, 50К+ активных пользователей каждый день. Сервера находятся в Amazone в одном регионе Ирландии: в работе постоянно 100+ различных серверов, из них почти 50 — с базами данных.

Весь backend — большое монолитное stateful-приложение на Java, которое держит постоянное websocket соединение с клиентом. При одновременной работе нескольких пользователей на одной доске все они видят изменения в режиме реального времени, потому что каждое изменение мы записываем в базу. У нас примерно 10К запросов в секунду к нашим базам. В пиковой нагрузке в Redis мы пишем по 80-100К запросов в секунду.
Отказоустойчивый кластер PostgreSQL + Patroni. Опыт внедрения - 1
Читать полностью »

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

Сейчас у нас 47 000 пользователей ежедневно, около 30 серверов в production, 2 000 API запросов в секунду и ежедневные релизы. Сервис Miro развивается с 2011 года, и в текущей реализации пользовательские запросы обрабатываются параллельно кластером разнородных серверов.

Наш подход к раскраске потоков - 1
Читать полностью »

Я — Head of Product в RealtimeBoard. Я люблю дерзкие цели и постоянно думаю о том, где нас ждут новые горизонты, как улучшить результаты, как завтра стать лучше, чем мы были вчера. И ещё я много думаю о том, насколько важна в этом увлекательном путешествии команда. Мы много внимания уделяем тому, чтобы все в команде понимали цели компании, стратегию и наш прогресс в их достижении.

“Если хочешь идти быстро — иди один, если хочешь дойти далеко — идите вместе”. Говорят, это африканская пословица.

О важных “невидимых" вещах — доверии, культуре и ценностях - 1

Сейчас популярно внедрять OKRs (Objectives and Key Results), KPI и прочие методы повышения эффективности. Иногда оказывается, что эти фреймворки не работают или требуют много микроменеджмента и становятся больше pain in the ass, чем реальным помощником в достижении результата.

На конференциях мне часто задают вопросы о том, как правильно делать OKRs, как это работает у нас в RealtimeBoard и просят «покажи табличку» с OKRs. Как правило, табличкой это, конечно же, не решается. Читать полностью »

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

Как мы мигрировали базу данных из Redis и Riak KV в PostgreSQL. Часть 1: процесс - 1

Долгое время основной базой данных в RealtimeBoard был Redis. Мы хранили в нём всю основную информацию: данные о пользователях, аккаунтах, досках и т.д. Всё работало быстро, но мы столкнулись с рядом проблем.

Проблемы с Redis

  1. Зависимость от сетевой задержки. Сейчас в нашем облаке она составляет порядка 20 мск, но при её увеличении приложение начнёт работать очень медленно.
  2. Отсутствие индексов, которые нужны нам на уровне бизнес-логики. Их самостоятельная реализация может усложнить бизнес-логику и привести к неконсистентности данных.
  3. Сложность кода также усложняет обеспечение консистентности данных.
  4. Ресурсоёмкость запросов с выборками.

Эти проблемы вместе с ростом количества данных на серверах послужили причиной для миграции БД.
Читать полностью »

На конференции по продуктовому маркетингу Epic Growth Conference Андрей Хусид CEO RealtimeBoard поделился, как трансформировалась структура команды в соответствии с изменениями в продуктовой стратегии компании.

Смотрите видео и читайте заметки под катом.
Читать полностью »

image

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

В Carrot quest мы нашли для себя оптимальный список таких сервисов-инструментов и хотим поделиться своим опытом. Мы долго искали удобную для нас форму работы. Система, которую мы выстроили, помогает нам делать свой продукт лучше и быстрее.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js