Rootconf 2019

Rootconf 2019

On infrastructure security, DevOps and distributed systems.

About Rootconf 2019:

The seventh edition of Rootconf is a two-track conference with:

  1. Security talks and tutorials in audi 1 and 2 on 21 June.
  2. Talks on DevOps, distributed systems and SRE in audi 1 and audi 2 on 22 June.

Topics and schedule:

View full schedule here: https://hasgeek.com/rootconf/2019/schedule

Rootconf 2019 includes talks and Birds of Feather (BOF) sessions on:

  1. OSINT and its applications
  2. Key management, encryption and its costs
  3. Running a bug bounty programme in your organization
  4. PolarDB architecture as Cloud Native Architecture, developed by Alibaba Cloud
  5. Vitess
  6. SRE and running distributed teams
  7. Routing security
  8. Log analytics
  9. Enabling SRE via automated feedback loops
  10. TOR for DevOps

Who should attend Rootconf?

  1. DevOps programmers
  2. DevOps leads
  3. Systems engineers
  4. Infrastructure security professionals and experts
  5. DevSecOps teams
  6. Cloud service providers
  7. Companies with heavy cloud usage
  8. Providers of the pieces on which an organization’s IT infrastructure runs – monitoring, log management, alerting, etc
  9. Organizations dealing with large network systems where data must be protected
  10. VPs of engineering
  11. Engineering managers looking to optimize infrastructure and teams

For information about Rootconf and bulk ticket purchases, contact info@hasgeek.com or call 7676332020. Only community sponsorships available.

Rootconf 2019 sponsors:

Platinum Sponsor

CRED

Gold Sponsors

Atlassian Endurance Trusting Social

Silver Sponsors

Digital Ocean GO-JEK Paytm

Bronze Sponsors

MySQL sumo logic upcloud
platform sh nilenso CloudSEK

Exhibition Sponsor

FreeBSD Foundation

Community Sponsors

Ansible PlanetScale

Hosted by

Rootconf is a forum for discussions about DevOps, infrastructure management, IT operations, systems engineering, SRE and security (from infrastructure defence perspective). more

Kishore N C

Running A Highly Available RabbitMQ Cluster

Submitted Mar 9, 2019

At Zapier, we connect over 1000 SaaS applications and enable people to automate their workflows spanning across multiple web applications. To achieve that, we use RabbitMQ to run millions of tasks every day. It can be said to be the backbone of Zapier.

We were using RabbitMQ in clustering mode in Zapier for scalability. We soon realised that RabbitMQ clustering is designed for scalability and not for high availability. If a node failed in the cluster, queues on that node will be lost and it also took out the other nodes from service. Read more here. Although RabbitMQ has a mirroring feature that replicates queues across multiple nodes, it does not distribute load across these nodes since consumers connect only to the master. During a failover, there’s also a chance that previously unacknowledged messages will get redelivered.

In this talk, we will dive into how we architected an alternative clustering solution that treated each RabbitMQ node as a stand-alone node, thereby tolerating node failures without disrupting the other nodes.

Outline

  • Setting up the scene: Current scale at Zapier and how Rabbit is a crucial piece of our architecture
  • Understand the shortcomings of native RabbitMQ clustering with a simple example
  • Vision: A highly available, durable, scalable RabbitMQ cluster
  • Designs considered
  • Implementation details of chosen design
  • Demo
  • The Future

Requirements

Basic understanding of message queues

Speaker bio

Kishore works as a Site Reliability Engineer at Zapier. He loves working on distributed systems and gets a kick out of designing for high availability and scale.

Links

Comments

{{ gettext('Login to leave a comment') }}

{{ gettext('Post a comment…') }}
{{ gettext('New comment') }}
{{ formTitle }}

{{ errorMsg }}

{{ gettext('No comments posted yet') }}

Hosted by

Rootconf is a forum for discussions about DevOps, infrastructure management, IT operations, systems engineering, SRE and security (from infrastructure defence perspective). more