Sizing calculation for a simple system (WS)
published: ⏰ 4A year ago I wrote an article about Sizing calculation for a simple system (CLI). This is a similar article, but using a web service instead of CLI. It has slightly more capabilities and a more convenient interface than working with XML and console.
Introduction
The web service allows performing the same actions as CLI, but with a more convenient interface. They share the same calculation engine, so the difference is mainly in editing the infrastructure model.
In this example, I will show how to create a project, add elements to it, and perform sizing calculation.
Project
To start, you need to create a project where all main planning elements will be located. Similar to the previous CLI example, I will create a project called ACME Systems. After creation, you must select it to make additional project workspace elements available. Below is an example of some screens.
Environments
When the project is created, you need to create environments. What environments are we talking about? These could be: dev, test, staging, prod. In this example, I will create 3 environments: test, uat, prod. Further, I will mainly use examples only for prod, to avoid increasing the number of steps.
Additionally, systems are required that services will belong to. Creating multiple is not necessary; there could be just one for a small project. In this example, I will create 2 systems:
Infra Services– everything related to infrastructure: observability, network file systems, etc.App System– everything related to applications.
Services
After systems are created, you can create services. Services are created within systems, which allows grouping them by logical blocks. This is convenient when working with a large number of services.
Each service is a deployment service template, i.e., if a cluster is needed, it’s not necessary to create a separate service for each instance. The required number of service instances will be determined in its template. For example, I’ll specify a couple of replicas per service.
For some services, a load balancer will be used to distribute requests across the cluster. For databases, replication (master-slave) is additionally enabled. Not shown in screenshots, but for the metrics collection service, a retention limit of 64GiB is set to avoid filling up disk space.
Each service has modules that describe its structure. These could be REST API endpoints, database modules, web interface modules, etc. Modules can be either shared or unique to a specific service. All subsequent data flows in the system will be described through service modules.
The final list of services for different environments is shown below in the screenshot.
Data Flows
Now you need to describe the data flows that will generate actual load based on which metrics are calculated. In this case, these will be read and write flows to frontend, backend, and database.
The example below shows read and write flows to frontend, backend, and database. Main read load: 1K RPS, and write is 1 per minute.
Additionally, I’ll add a couple of metrics and logs collection flows from the frontend for the example.
Backup
Backup, like in the previous example, on every 2nd day of the month for the database and additionally for metrics storage.
Load Forecast
At this stage, you have everything needed to create a load forecast. It will be based on the previously described data flows and backups.
The number of forecasts created is unlimited and can be either one or several with the ability to switch between them. This allows creating forecasts for different scenarios, for example, when load increases or decreases. Forecast creation example below.
After the forecast is calculated, you can view the execution process in the journal. You can also select it as the main one for further equipment planning and view its metrics.
Metrics are calculated by service modules, which allows estimating which ones are most loaded. In most cases, this is excessive, so in the report modules are hidden by default and show aggregate metrics by services and systems.
Additionally, metrics will appear in previously created services and can be edited if needed.
Server Creation
Next, if service distribution across servers is needed, you must create them.
Servers can be created from templates or completely manually. In the example below, a ready-made one from tekBlueprint.kbase is used – kb@main://hardware-server/enterprise:hp-dl360:1.0:gen10-8sff to avoid filling it in manually. After planning, server components become available for editing. Essentially, at this stage it’s a server template.
I’ll also specify that 2 units are needed; they will be created automatically.
Next, you need to run service planning. They can be added to servers manually or automatically when creating a plan. In this example, services will be added automatically.
After the plan is created, you can select it as the main one and edit it if needed. In the server list, you can see there are now two (units=2) and services are distributed between them roughly evenly.
Conclusion
There is still one step left – generating documentation for created forecasts and plans; this will be covered later.