Let’s look at the infrastructure that helps Kanka run. We’re publishing this article in tandem with Jay’s Setup article.
Hardware running our servers
First things first. Kanka runs primarily on five servers, all located in Germany (Nuremberg).
All our servers have 2 vCPUs, 4GB of RAM, and plenty of disk.
Thumbor – generating fast images
Our Thumbor works on generating optimised images for the web. These include making thumbnails of all shapes and sizes used by Kanka. These images are saved on the machine’s network attached disk, and gets reset every few months.
As the name implies, we use the thumbor service to generate the images.
Our two frontend servers are who you get when trying to call Kanka. Our DNS is setup so that you’ll randomly speak with one, and usually stay with that one for your session’s duration.
Haproxy is our loadbalancing and proxy service. It runs before anything else, making sure that the rest of the services are responding and that the request can be handled. It’s also where we handle our SSL certificats.
Haproxy will send the request to our varnish 6 service on either the same frontend server or on another (loadbalancing) if the server is under heavy load. Varnish acts as a cache, so that if a page was already requests and doesn’t involve any user data, the page doesn’t need to be generated again. If the request isn’t available in the cache, it goes to our backend servers.
When a backend server receives a request, nginx will start up an php-fpm process. That’s what runs Kanka’s PHP code. The same backend servers have a MariaDB process running for the database, and a Redis server for application cache.
Third party services
We store all images uploaded to Kanka on an Amazon AWS3 storage. Any error generated by the PHP code goes to Sentry.
To manage all of these servers, we use Ansible. This allows us to easily add a new server when needed. When a new server is added to our infrastructure, our first step is to install Ansible on it and add it to our network.