Smooth operations for large stateful in-memory database application: Using Kubernetes orchestration and Apache Helix for improving operations

Abstract

Relex Solutions’ Plan product is architecturally a giant stateful monolith with an in-memory database. A system is considered a monolith if all its services need to be deployed together. The database has been kept in-memory because of the data amount the application needs to process and how much faster the performance is when the data is kept in-memory. The Plan architects are looking into taking Kubernetes as an orchestration and lifecycle managing tool. Having an orchestrator in place would provide several benefits, such as automatic scheduling workloads onto a shared pool of resources and better isolation between customers. Kuber-netes orchestration is part of bigger architecture initiative to modularize Relex Plan more in attempts to make the monolith more flexible. This thesis is about finding solutions for keeping the operations smooth with Kubernetes and Apache Helix. Literature review and design sci-ence will be used as main methodologies for the research. With Helix role rebalancer and Kubernetes’ Statefulset, we can easily scale out and scale in with graceful shutdown. Autoscaling would be well supported by having a resource pool in Kubernetes. Creating pods with Statefulset, make sure each of the pods has a persistent iden-tifier, so rescheduling and restoring pods in Kubernetes native way is covered, while Helix rebalancer takes care that the cluster has wanted number of Plan roles, so there’s minimal interruption to the users. Zero downtime would require backwards compatibility for database schema updates, this must be implemented on the product side. The backwards compatibility would technically be a requirement if Kubernetes-native rolling update deployment strategy, with zero downtime, is wanted to take into use in the future. The solution can be applied to other monolithic software architecture with similar setup.