RightScale Blog

Cloud Management Blog
RightScale 2017 State of the Cloud Report
Cloud Management Blog

RightScale Compute: How RightScale Architects Its Own Databases

RightScale Compute: How RightScale Architects Its Own Databases

Want a peek behind the scenes at how RightScale builds the tools that help organizations deploy and manage applications across public, private, and hybrid clouds? I'm RightScale's chief architect, and at RightScale Compute 2013 I'll be sharing that information in a session on Building RightScale's Globally Distributed Datastore, where you can learn how we use both relational and NoSQL databases to provide a scalable, distributed, and highly available service around the world.

RightScale uses a mix of relational databases — notably MySQL — and NoSQL technology, in particular Cassandra.

Our data taxonomy involves several systems with different data semantics. They include global objects — such as users, account plans, and settings — as well as a number of different items that are private to each account:

  • Dashboard objects, such as deployments, audit information, and alert specifications
  • Cloud polling data, which includes cloud resource states and cloud credentials
  • Routing data, such as the location of instance and core agents and an agent action registry
  • Monitoring and syslog data

In practice, when it comes to using the data, we need to pay attention to the scope of any given data - whether it is shared among accounts or used by only a single account - and its placement, by which I mean who uses the data. Global and dashboard objects are used by the Dashboard and API — they are “close” to users. Cloud polling data, routing data, and monitoring and syslog data are used by instances and resources — they are “close” to the cloud. Those two concepts, scope and placement, make up two axes against which we can graph our database systems.

In my session I'll share details on how these two axes influence how RightScale geographically deploys its systems, as well as how they dictate the technologies that we use (MySQL, Cassandra, S3, and others) for each specific task based on the availability, replication, and geographical proximity constraints of each of the tasks. For example, we will show how we leverage MySQL for its ACID semantics and "queryability," Cassandra for its strength in availability and scalability, and S3 for its archival and large volume capabilities. I'll also talk about our disaster recovery strategy and show how it reacts when facing complete region outages.