• Implementing Fault-Tolerance PostgreSQL Cluster with Patroni

      I'm a DevOps Teamlead at Miro. Our service is a high-load one: it is used by 4 million users worldwide, daily active users - 168,000. Our servers are hosted by Amazon and located in a single Ireland region. We have more than 200 active servers, with almost 70 of them being database servers.

      The service's backend is a monolith stateful Java application that maintains a persistent WebSocket connection for each client. When several users collaborate using the same whiteboard, they see changes on the whiteboard in real-time. That's because we write every change to a database, resulting in ~20,000 requests per second to the databases. During peak hours, the data is written to Redis at ~80,000–100,000 RPS.

      I am going to speak about why it is important to us to maintain PostgreSQL high availability, what methods we've applied to solve the problem, and what results we've achieved so far.

      image
      Read more →
    • Отказоустойчивый кластер PostgreSQL + Patroni. Опыт внедрения

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

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

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

        Читать дальше →
      • Невидимый деплой монолитного приложения в продакшн на AWS. Личный опыт

        Я – Lead DevOps Engineer в Miro (экс-RealtimeBoard). Поделюсь тем, как наша DevOps-команда решила проблему ежедневных серверных релизов монолитного stateful-приложения и сделала их автоматическими, невидимыми для пользователей и удобными для собственных разработчиков.

        Наша инфраструктура


        Наша команда разработки — это 60 человек, которые делятся на Scrum-команды, среди которых есть и команда DevOps. Большинство Scrum-команд поддерживают текущую функциональность продукта и придумывают новые фичи. Задача DevOps — создавать и поддерживать инфраструктуру, которая помогает приложению работать быстро и надёжно и позволяет командам быстро доставлять новый функционал до пользователей.

        Читать дальше →
        • +16
        • 4.9k
        • 4