Расчёт сайзинга на примере простой системы (CLI)
обновлено:Небольшой пример расчёта сайзинга для простой системы, показывающий, как описывать чертёж с сервисами, а также параметры планируемой нагрузки. Описание специально сделано с минимальным набором сервисов и параметров для них, чтобы не перегружать его деталями.
Подготовка
Для удобства работы рекомендуется использовать редактор с поддержкой XML, например Visual Studio Code или IntelliJ IDEA.
Первым делом необходимо создать новый чертеж blueprint-simple-system.xml (название может быть любым) в каталоге
workbench со следующим содержимым:
blueprint-simple-system.xml:
<?xml version="1.0" encoding="UTF-8"?>
<tekInfraBlueprint model="0.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.tekblueprint.org/xml/infra http://www.tekblueprint.org/xml/infra-0.6.xsd
http://www.tekblueprint.org/xml/core http://www.tekblueprint.org/xml/core-0.7.xsd"
xmlns="http://www.tekblueprint.org/xml/infra" xmlns:c="http://www.tekblueprint.org/xml/core">
<c:name>ACME Systems</c:name>
</tekInfraBlueprint>Пока здесь только название будущей системы с именем ACME Systems. Далее будем добавлять в него различные компоненты.
Окружения
В большинстве случаев система работает в нескольких окружениях, например, для разработки (dev), тестирования (test),
предпродакшена (uat), продакшена (prod) и т.д. Чтобы не усложнять сделаем только два окружения:
global– общее окружение для общих сервисов.prod– продакшен окружение для основных сервисов.
Окружения для чертежа нужны в основном для группировки сервисов в итоговом отчёте.
Добавим их в чертеж:
<tekInfraBlueprint model="0.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.tekblueprint.org/xml/infra http://www.tekblueprint.org/xml/infra-0.6.xsd
http://www.tekblueprint.org/xml/core http://www.tekblueprint.org/xml/core-0.7.xsd"
xmlns="http://www.tekblueprint.org/xml/infra" xmlns:c="http://www.tekblueprint.org/xml/core">
<c:name>ACME Systems</c:name>
<environments>
<environment id="global" name="Global Environment"/>
<environment id="prod" name="Production Environment"/>
</environments>
</tekInfraBlueprint>Так как окружение global в списке указано первым, то в него будут добавляться все сервисы по умолчанию, если не
указано другое.
Сервера
Этот шаг необязателен, если не планируется распределение сервисов по различным серверам. Опять же, для упрощения, будем использовать только один физический сервер, на котором будут располагаться все наши сервисы.
Добавим описание сервера в чертеж в блоке <servers>:
<tekInfraBlueprint model="0.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.tekblueprint.org/xml/infra http://www.tekblueprint.org/xml/infra-0.6.xsd
http://www.tekblueprint.org/xml/core http://www.tekblueprint.org/xml/core-0.7.xsd"
xmlns="http://www.tekblueprint.org/xml/infra" xmlns:c="http://www.tekblueprint.org/xml/core">
<c:name>ACME Systems</c:name>
<environments>
<environment id="global" name="Global Environment"/>
<environment id="prod" name="Production Environment"/>
</environments>
<servers>
<server id="main" x="2" name="main server" _base="enterprise:hp-dl360:1.0"/>
</servers>
</tekInfraBlueprint>Здесь указывается один сервер с идентификатором main и компонентом enterprise:hp-dl360:1.0, указанным через атрибут _base. Компоненты описывают характеристики сервера, такие как количество процессоров, оперативной памяти и т.д.
На текущий момент это необходимо для визуальной группировки сервисов, каких-либо ограничений при распределении сервисов доступные ресурсы серверов не накладывают. В будущем будет добавлена возможность автоматического распределения сервисов по серверам и подсветки превышения доступных ресурсов.
Пример компонента для сервера enterprise:hp-dl360:1.0
<?xml version="1.0" encoding="UTF-8" ?>
<tekHardwareServer model="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.tekblueprint.org/xml/core"
xsi:schemaLocation="http://www.tekblueprint.org/xml/core http://www.tekblueprint.org/xml/core-0.7.xsd"
group="enterprise" artifact="hp-dl360" version="1.0">
<name>HP :: ProLiant DL360</name>
<t>
The HP ProLiant DL360 is a powerful and versatile server designed for enterprise-level performance. It is ideal
for a wide range of applications, including virtualization, web hosting, database management, and more. The
DL360 series offers excellent performance, reliability, and scalability, making it a popular choice among
businesses of all sizes.
</t>
<variants>
<variant id="gen10-8sff" name="HPE ProLiant DL360 Gen10 Server">
<t>
The HPE ProLiant DL360 Gen10 Server supports the Intel® Xeon® Scalable Processor Family with up to 28
cores, plus 2933 MT/s HPE DDR4 Smart Memory supporting up to 3.0 TB max. With the added performance that
HPE Persistent Memory and 10 NVMe bring, the HPE ProLiant DL360 Gen10 means business. Deploy this dense
platform for diverse workloads in space constrained environments and maintain it with ease by automating
the most essential server lifecycle management tasks with HPE OneView and HPE iLO 5.
</t>
<cpu x="2" _base="enterprise:intel-xeon-gold-6130:1.0"/>
<memory>
<slot x="4" _base="enterprise:kingston-server-premier-dd4-2666:1.0:32"/>
</memory>
<storage>
<slot x="1" _base="enterprise:samsung-pm1643-ssd-sas:1.0:1.92"/>
<slot x="4" _base="enterprise:hpe-hdd-sas:1.0:1.8"/>
</storage>
<network>
<slot x="1" _base="enterprise:hpe-331-rj45:1.0"/>
</network>
</variant>
</variants>
</tekHardwareServer>Системы и сервисы
Сервисы, для которых планируется рассчитать потребление ресурсов, группируются в системы внутри блока <systems>. Для примера будет использоваться одна система app с тремя сервисами:
msvc_orders– микросервис обработки заказов.db– СУБД для хранения данных микросервиса.san– SAN-хранилище, на котором будут размещаться резервные копии СУБД.
msvc_orders
Добавим описание системы с микросервисом, используя компонент microservice:java-integration:1.0:
<systems>
<system id="app" name="Application System">
<services>
<service id="msvc_orders" name="Orders Microservice" env="prod" replicas="2"
_base="microservice:java-integration:1.0">
<c:requirements>
<c:cpu cores="0.25" freq="3Ghz"/>
<c:mem capacity="512MiB"/>
<c:disk capacity="256MiB" iops="10"/>
<c:net bandwidthRx="10Mbit/s" bandwidthTx="10Mbit/s"/>
</c:requirements>
<c:module id="restapi" type="http" name="RESTful API">
<!-- <balancer disabled="true"/> -->
</c:module>
</service>
</services>
</system>
</systems>Микросервис содержит только один модуль restapi, к которому и будут обращаться для выполнения запросов.
Блок <c:requirements> позволяет указать базовые требования к ресурсам для сервиса: процессор, память, диск и сеть.
Компонент microservice:java-integration:1.0
<?xml version="1.0" encoding="UTF-8" ?>
<tekSoftwareService model="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.tekblueprint.org/xml/core"
xsi:schemaLocation="http://www.tekblueprint.org/xml/core http://www.tekblueprint.org/xml/core-0.7.xsd"
group="microservice" artifact="java-integration" version="1.0">
<name>Java Microservice for Integration</name>
<t>
The Java Microservice for Integration is a scalable and maintainable solution designed to facilitate seamless
communication between different systems through the use of RESTful APIs.
</t>
<keywords>microservice, integration, java, RESTful, API</keywords>
<license name="tekBlueprint License" holder="tekBlueprint"
url="https://www.tekblueprint.org/about/licence"
commercialUse="true" type="COPYLEFT"/>
<metrics>cpu, mem, net, data, rps, iops</metrics>
<variant id="main" server="main">
<module id="http" type="http"/>
</variant>
<forecasting>
<onModuleOut>
<add-metric id="rps">statistics.probeRequestsPerSecond</add-metric>
<if-type type="http">
<add-metric id="net-tx">statistics.probeBytesPerSecond</add-metric>
<add-metric id="cpu">statistics.probeCpuPerSecond</add-metric>
<add-metric id="mem">statistics.probeMemoryPerSecond</add-metric>
</if-type>
</onModuleOut>
<onModuleIn>
<add-metric id="rps">statistics.probeRequestsPerSecond</add-metric>
<if-type type="http">
<add-metric id="net-rx">statistics.probeBytesPerSecond</add-metric>
<add-metric id="cpu">statistics.probeCpuPerSecond</add-metric>
<add-metric id="mem">statistics.probeMemoryPerSecond</add-metric>
<add-metric id="iops">statistics.probeBytesPerSecond / 4096</add-metric>
</if-type>
</onModuleIn>
</forecasting>
</tekSoftwareService>db
Далее добавим описание базы данных в блок <services> той же системы:
<service id="db" name="Database" env="global" replicas="2" _base="rdbms:postgresql:17">
<c:requirements>
<c:cpu cores=".25" freq="3Ghz"/>
<c:mem capacity="256MiB"/>
<c:disk capacity="1GiB" iops="1K"/>
<c:net bandwidthTx="10Mbits" bandwidthRx="10Mbits"/>
</c:requirements>
<c:module id="msvc_orders" type="table" name="Orders Database">
<c:storage/>
<c:replicate type="master-slave">
<c:overhead>
<c:data in="512b" out="256b"/>
</c:overhead>
</c:replicate>
</c:module>
</service>Здесь уже немного сложнее. В качестве модуля используется table – некая абстрактная таблица, к которой будут обращаться. База будет общей и располагается в окружении global.
Также мы указали replicas="2", то есть хотим разместить две реплики базы данных в кластере. Это означает, что у нас будет две ноды в кластере, каждая из которых будет содержать реплику базы данных.
Для того чтобы сервис хранил в себе данные, добавим блок <c:storage/>. Он включит учёт всех входящих запросов с данными как запись в таблицу. Например, запрос размером в 512 байт будет считаться записью данных размером в 512 байт.
Также добавим репликацию типа master-slave. Это означает, что у нас есть один основной сервер (чтение и запись) и второй для копии данных. Все данные с основного сервиса будут копироваться на вторичные. И дополнительно укажем, что при репликации между серверами добавляется избыточность по передаваемым данным: в 256 байт на запись и 128 байт на ответ.
Компонент rdbms:postgresql:17
<?xml version="1.0" encoding="UTF-8" ?>
<tekSoftwareService model="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.tekblueprint.org/xml/core"
xsi:schemaLocation="http://www.tekblueprint.org/xml/core http://www.tekblueprint.org/xml/core-0.7.xsd"
group="rdbms" artifact="postgresql" version="17">
<name>PostgreSQL</name>
<t>
PostgreSQL is a powerful, open source object-relational database system that uses and extends the SQL language
combined with many features that safely store and scale the most complicated data workloads. It has more than 35
years of active development and a proven architecture that fully supports ACID transactions, foreign keys,
triggers, updatable views, and common table expressions (CTEs). PostgreSQL enhances robustness with
multi-version concurrency control (MVCC), point-in-time recovery, asynchronous replication, and hot standby.
</t>
<keywords>rdbms, database, sql, mvcc, acid</keywords>
<website>https://www.postgresql.org</website>
<license name="The PostgreSQL License" holder="PostgreSQL Global Development Group"
url="https://www.postgresql.org/about/licence"
commercialUse="true" type="PERMISSIVE"/>
<metrics>cpu, mem, net, data, rps, iops</metrics>
<variant id="main" server="main">
<requirements>
<cpu cores="2" _base="enterprise:intel-xeon-e5-2697:1.0"/>
<mem capacity="512MiB"/>
<disk capacity="1GiB" iops="150"/>
<net bandwidth="10Mbs"/>
</requirements>
<module id="table" type="table"/>
</variant>
</tekSoftwareService>san
И последним добавим хранилище для резервных копий СУБД в ту же систему:
<service id="san" name="Storage Area Network" env="global"
_base="san:generic:1.0">
<c:module id="backups" type="disk" name="SAN">
<c:storage/>
</c:module>
</service>Используется некий абстрактный сервис SAN с компонентом san:generic:1.0. Здесь тоже включено хранение данных через <c:storage/>.
Компонент san:generic:1.0
<?xml version="1.0" encoding="UTF-8" ?>
<tekSoftwareService model="1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.tekblueprint.org/xml/core"
xsi:schemaLocation="http://www.tekblueprint.org/xml/core http://www.tekblueprint.org/xml/core-0.7.xsd"
group="san" artifact="generic" version="1.0">
<name>PanelStorage Area Network</name>
<t>
This service provides a robust and scalable PanelStorage Area Network (SAN) solution for high-performance data
storage and retrieval.
</t>
<keywords>san, storage, disk, persistence</keywords>
<license name="tekBlueprint License" holder="tekBlueprint"
url="https://www.tekblueprint.org/about/licence"
commercialUse="true" type="COPYLEFT"/>
<metrics>cpu, mem, net, data, rps, iops</metrics>
<variant id="main" server="main">
<module id="disk" type="disk"/>
</variant>
</tekSoftwareService>Развёртывание
После описания сервисов необходимо указать, на какие сервера они будут развёрнуты. Для этого используется блок <deployments>:
<deployments>
<deploy service="app:msvc_orders" to="main"/>
<deploy service="app:db" to="main"/>
<deploy service="app:san" to="main"/>
</deployments>Каждый элемент <deploy> связывает сервис с сервером. Формат ссылки на сервис: system_id:service_id. В нашем случае все три сервиса разворачиваются на один сервер main.
Параметры симуляции
После того как описаны основные параметры окружения, систем и сервисов необходимо добавить параметры симуляции нагрузки на них.
Первое, что нужно сделать, это определить период времени, за который будет проводиться симуляция нагрузки на систему. Это
делается с помощью блока <timeline>.
<timeline each="hour" duration="1" unit="year"/>Здесь мы говорим, что нужно рассчитать метрики за год с шагом в один час.
Далее необходимо определить нагрузку на каждый сервис. Это делается с помощью блока <streams>, внутри которого
описываются параметры для каждого сервиса. Добавим один поток запросов от некой внешней системы к модулю restapi сервиса msvc_orders
со следующими параметрами:
- Частота запросов – 10 в секунду.
- Размер запроса 1 килобайт, размер ответа на запрос 128 байт
- Время обработки запроса на CPU – 100 мс, время отправки ответа – 10 мс
- Использование оперативной памяти при обработке запроса – 16 килобайт.
- Время ожидания ответа от сервиса
msvc_orders– 5 секунд.
Далее этот запрос передаётся в модуль msvc_orders базы данных app:db, которую мы описывали ранее, со следующими параметрами:
- Размер запроса 512 байт, размер ответа на запрос 128 байт
- Данные должны быть сохранены в сервисе (ранее мы указывали блок
<c:storage/>в модуле базы данных).
Обратите внимание, что адресация потоков теперь использует формат system:service:module.
<streams>
<stream id="s1" to="app:msvc_orders:restapi" name="external requests">
<data in="1KiB" out="128b"/>
<cpu in="100ms" out="10ms"/>
<mem in="16KiB"/>
<latency time="5 sec"/>
<!-- nested stream to database -->
<streams>
<stream id="s2" to="app:db:msvc_orders">
<data in="512b" out="128b" persist="true"/>
</stream>
</streams>
<rate qty="10" per="second"/>
</stream>
</streams>Резервные копии
Последним шагом добавим симуляции создания резервных копий данных на сервисе san, которые были накоплены в сервисе
db.
Для этого используется отдельный блок <backups> на верхнем уровне чертежа. Добавим его со следующими параметрами:
- Запуск каждое 2 число месяца.
- Скорость передачи данных 32 МБ/с.
- Использование 1 ядра процессора на чтение данных от сервиса и запись данных в хранилище.
- Использование 16 КБ оперативной памяти на чтение данных от сервиса.
<backups>
<backup id="b1" name="Periodic backup of orders database"
from="app:db:msvc_orders" to="app:san:backups">
<!--
* * * * *
| | | | |____ day of week (0—6)
| | | |______ month (0—11)
| | |________ day of month (0—30)
| |__________ hour (0—23)
|____________ minute (0—59)
-->
<schedule cron="? ? 2 ? ?"/>
<throughput size="32 MiB" per="second"/>
<cpu in="1" out="1"/>
<mem in="16KiB"/>
<overhead>
<data in="1KiB" out="128b"/>
</overhead>
</backup>
</backups>Документы и отчёты
В чертеже можно описать документы, которые будут сгенерированы по результатам расчёта. Для этого используется блок <documents>:
<documents>
<c:bundle name="Infrastructure">
<c:document name="Infrastructure Sizing v{{doc.self.lastVersion}}"
template="infra:sizing:0.1" format="ASCIIDOC"
author="John Doe" status="draft" priority="high"/>
</c:bundle>
</documents>Шаблон infra:sizing:0.1 определяет структуру отчёта, а формат ASCIIDOC указывает на выходной формат документа.
Результат и запуск расчёта
В результате получим следующий XML-файл с описанием системы:
Итоговый чертёж
<?xml version="1.0" encoding="UTF-8" ?>
<tekInfraBlueprint model="0.2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.tekblueprint.org/xml/infra http://www.tekblueprint.org/xml/infra-0.6.xsd
http://www.tekblueprint.org/xml/core http://www.tekblueprint.org/xml/core-0.7.xsd"
xmlns="http://www.tekblueprint.org/xml/infra" xmlns:c="http://www.tekblueprint.org/xml/core">
<c:name>ACME Systems</c:name>
<!-- Define environments -->
<environments>
<environment id="global" name="Global Environment"/>
<environment id="prod" name="Production Environment"/>
</environments>
<servers>
<server id="main" x="2" name="main server" _base="enterprise:hp-dl360:1.0"/>
</servers>
<deployments>
<deploy service="app:msvc_orders" to="main"/>
<deploy service="app:db" to="main"/>
<deploy service="app:san" to="main"/>
</deployments>
<systems>
<system id="app" name="Application System">
<services>
<!-- orders microservice system configuration -->
<service id="msvc_orders" name="Orders Microservice" env="prod" replicas="2"
_base="microservice:java-integration:1.0">
<c:requirements>
<c:cpu cores="0.25" freq="3Ghz"/>
<c:mem capacity="512MiB"/>
<c:disk capacity="256MiB" iops="10"/>
<c:net bandwidthRx="10Mbit/s" bandwidthTx="10Mbit/s"/>
</c:requirements>
<c:module id="restapi" type="http" name="RESTful API">
<!-- <balancer disabled="true"/> -->
</c:module>
</service>
<!-- database system configuration -->
<service id="db" name="Database" env="global" replicas="2" _base="rdbms:postgresql:17">
<c:requirements>
<c:cpu cores=".25" freq="3Ghz"/>
<c:mem capacity="256MiB"/>
<c:disk capacity="1GiB" iops="1K"/>
<c:net bandwidthTx="10Mbits" bandwidthRx="10Mbits"/>
</c:requirements>
<c:module id="msvc_orders" type="table" name="Orders Database">
<c:storage/>
<c:replicate type="master-slave">
<c:overhead>
<c:data in="512b" out="256b"/>
</c:overhead>
</c:replicate>
</c:module>
</service>
<!-- storage system configuration -->
<service id="san" name="Storage Area Network" env="global"
_base="san:generic:1.0">
<c:module id="backups" type="disk" name="SAN">
<c:storage/>
</c:module>
</service>
</services>
</system>
</systems>
<!-- timeline configuration for forecasting -->
<timeline each="hour" duration="1" unit="year"/>
<!-- stream configurations for external requests to Orders Microservice -->
<streams>
<stream id="s1" to="app:msvc_orders:restapi" name="external requests">
<data in="1KiB" out="128b"/>
<cpu in="100ms" out="10ms"/>
<mem in="16KiB"/>
<latency time="5 sec"/>
<!-- nested stream to database -->
<streams>
<stream id="s2" to="app:db:msvc_orders">
<data in="512b" out="128b" persist="true"/>
</stream>
</streams>
<rate qty="10" per="second"/>
</stream>
</streams>
<backups>
<backup id="b1" name="Periodic backup of orders database"
from="app:db:msvc_orders" to="app:san:backups">
<!--
* * * * *
| | | | |____ day of week (0—6)
| | | |______ month (0—11)
| | |________ day of month (0—30)
| |__________ hour (0—23)
|____________ minute (0—59)
-->
<schedule cron="? ? 2 ? ?"/>
<throughput size="32 MiB" per="second"/>
<cpu in="1" out="1"/>
<mem in="16KiB"/>
<overhead>
<data in="1KiB" out="128b"/>
</overhead>
</backup>
</backups>
<documents>
<c:bundle name="Infrastructure">
<c:document name="Infrastructure Sizing v{{doc.self.lastVersion}}"
template="infra:sizing:0.1" format="ASCIIDOC"
author="John Doe" status="draft" priority="high"
startDate="2025-04-01T08:00:00+04:00"
dueDate="2025-04-04T18:00:00+04:00"
finishDate="2025-04-09T18:00:00+04:00">
<c:versions>
<c:version number="1.0" author="John Doe" approvedBy="Ella Doe" date="2025-04-01T08:00:00+04:00">
Initial draft.
</c:version>
</c:versions>
</c:document>
</c:bundle>
</documents>
</tekInfraBlueprint>Далее запускаем расчёт
./tekBlueprint.infra -w workbench software solve blueprint-simple.en.xml
...
INFO 00:17:07.884 | --- FORECAST SOFTWARE USAGE ---
INFO 00:17:08.011 | 8760 probes, each HOUR during 1 YEAR
INFO 00:17:08.013 | prepare (127 ms)
INFO 00:17:08.226 | progress: 100.00% 8759 / 8760
INFO 00:17:08.226 | forecasting (213 ms)
INFO 00:17:08.229 | merge (2 ms)Метрики будут добавлены в исходный чертёж и он будет записан в файл
workbench/reports/blueprint-simple-system/blueprint.xml. Этот файл можно открыть в редакторе и посмотреть добавленные
метрики по сервисам, сетевым соединениям, резервным копиям и так далее.
Теперь можно добавить расчёт по серверам, выполнив следующую команду:
./tekBlueprint.infra -w workbench hardware solve blueprint-simple.en.xml
...
INFO 00:17:38.369 | --- SOLVING HARDWARE ---
INFO 00:17:38.462 | prepare (91 ms)
INFO 00:17:38.464 | assign (1 ms)
INFO 00:17:38.466 | merge (1 ms)ℹ️ Предупреждение
Команда
hardware solveиспользует для расчётов не исходный файл чертежа, а результат командыsoftware solve, в котором содержатся необходимые метрики.
Отчёты
Отчёты строятся по итоговому чертежу с собранными метриками.
ℹ️ Примечание
Так как чертёж это обычный XML, то не обязательно использовать встроенные отчёты. Вы можете написать свой генератор, например используя XLST трансформацию.
Сгенерируем все доступные отчёты (AsciiDoc, схема развёртывания, вывод в консоль) выполнив команду:
./tekBlueprint.infra -w workbench report blueprint-simple.en.xml
...
INFO 14:32:49.725 | --- GENERATE REPORTS ---
INFO 14:32:51.384 | RENDER : 1429ms (threads 16)
INFO 14:32:51.387 | --- DOCUMENTS ---
INFO 14:32:51.427 |
┌─────────────────────────────────────┬──────────┬─────────┬──────────┬───────────────────┬─────────────────┬───────────────────┬─────────────────┬────────┐
│ Document │ Author │ Version │ Priority │ Status │ Start │ Due │ Finish │ Time │
├─────────────────────────────────────┴──────────┴─────────┴──────────┴───────────────────┼─────────────────┼───────────────────┼─────────────────┼────────┤
│ 1. Infrastructure │ 2025-04-01+0400 │ ⚠ 2025-05-04+0400 │ 2025-05-09+0400 │ - │
├─────────────────────────────────────┬──────────┬─────────┬──────────┬───────────────────┼─────────────────┼───────────────────┼─────────────────┼────────┤
│ :: Infrastructure Sizing v1.0.adoc │ John Doe │ 1.0 │ HIGH │ DRAFT │ 2025-04-01+0400 │ 2025-04-04+0400 │ 2025-04-09+0400 │ 504ms │
├─────────────────────────────────────┼──────────┼─────────┼──────────┼───────────────────┼─────────────────┼───────────────────┼─────────────────┼────────┤
│ :: Infrastructure Sizing v1.0.md │ John Doe │ 1.0 │ HIGH │ DRAFT │ 2025-05-01+0400 │ 2025-05-04+0400 │ 2025-05-09+0400 │ 1423ms │
└─────────────────────────────────────┴──────────┴─────────┴──────────┴───────────────────┴─────────────────┴───────────────────┴─────────────────┴────────┘
document: 1555ms
console: 5ms
INFO 14:32:51.433 | # - size of incoming or outgoing data
INFO 14:32:51.433 | ↓ - incoming
INFO 14:32:51.433 | ↑ - outgoing
INFO 14:32:51.433 | ∑ - sum of incoming and outgoing
INFO 14:32:51.433 |
INFO 14:32:51.433 | TIMELINE: 1 YEAR each HOUR
--- SERVERS ---
ID | NAME | vCPU | MEM | NET-RX | NET-TX | RPS | IOPS | STORE
------ | ----------- | ---- | ---------- | ------------ | ----------- | ----- | ----- | ----------
main | main server | 0.82 | 769.18 MiB | 264.40 Mbits | 1.82 Mbits | 15.00 | 9.04K | 984.66 GiB
main@1 | main server | 0.11 | 400 KiB | 128.00 Kbits | 56.32 Kbits | 15 | 4.84 | 300.75 GiB
--- SERVICES ---
ID | NAME | TYPE | SERVER | # ↓ | # ↑ | # ∑ ↓ | # ∑ ↑ | ↓ ∑ REQ | ↑ ∑ REQ | vCPU | MEM | NET-RX | NET-TX | RPS | IOPS | STORE
---------------------------- | -------------------- | -------- | ------ | ---------- | ---------- | ---------- | ---------- | ------- | ------- | ---- | ------- | ------------ | ------------ | --- | ----- | ----------
* | - | EXTERNAL | - | - | - | - | - | - | - | - | - | - | - | - | - | -
: *:* | | PRIMARY | | 4.39 MiB | 35.15 MiB | 37.59 GiB | 300.75 GiB | - | - | | | 10.24 Kbits | 81.92 Kbits | | |
:: *:*:* | | * | | 4.39 MiB | 35.15 MiB | 37.59 GiB | 300.75 GiB | - | - | | | 10.24 Kbits | 81.92 Kbits | | |
app | - | INTERNAL | - | - | - | - | - | - | - | - | - | - | - | - | - | -
: app:db | Database | PRIMARY | main | 30.76 MiB | 112.53 GiB | 263.15 GiB | 1.14 TiB | 315.36M | - | 0.20 | 800 KiB | 71.68 Kbits | 542.56 Kbits | 10 | 1.56 | 150.37 GiB
:: app:db:msvc_orders | Orders Database | table | | 30.76 MiB | 39.55 MiB | 263.15 GiB | 1.14 TiB | 315.36M | - | 0.20 | 800 KiB | 71.68 Kbits | 542.56 Kbits | 10 | 1.56 | 150.37 GiB
: app:db@1 | - | REPLICA | main@1 | 35.15 MiB | 13.18 MiB | 300.75 GiB | 112.78 GiB | 315.36M | - | | | 81.92 Kbits | 30.72 Kbits | 10 | 3.43 | 300.75 GiB
:: app:db@1:msvc_orders | - | table | | 35.15 MiB | 13.18 MiB | 300.75 GiB | 112.78 GiB | 315.36M | - | | | 81.92 Kbits | 30.72 Kbits | 10 | 3.43 | 300.75 GiB
: app:msvc_orders | Orders Microservice | PRIMARY | main | 19.77 MiB | 10.98 MiB | 169.17 GiB | 93.98 GiB | 157.68M | - | 0.11 | 400 KiB | 46.08 Kbits | 25.60 Kbits | 5 | 1.40 |
:: app:msvc_orders:restapi | RESTful API | http | | 19.77 MiB | 10.98 MiB | 169.17 GiB | 93.98 GiB | 157.68M | - | 0.11 | 400 KiB | 46.08 Kbits | 25.60 Kbits | 5 | 1.40 |
: app:msvc_orders@1 | - | REPLICA | main@1 | 19.77 MiB | 10.98 MiB | 169.17 GiB | 93.98 GiB | 157.68M | - | 0.11 | 400 KiB | 46.08 Kbits | 25.60 Kbits | 5 | 1.40 |
:: app:msvc_orders@1:restapi | - | http | | 19.77 MiB | 10.98 MiB | 169.17 GiB | 93.98 GiB | 157.68M | - | 0.11 | 400 KiB | 46.08 Kbits | 25.60 Kbits | 5 | 1.40 |
: app:san | Storage Area Network | PRIMARY | main | 112.50 GiB | - | 833.03 GiB | - | 15 | - | 0.01 | 16 KiB | 263.03 Mbits | | .00 | 8.02K | 833.03 GiB
:: app:san:backups | SAN | disk | | 112.50 GiB | - | 833.03 GiB | - | 15 | - | 0.01 | 16 KiB | 263.03 Mbits | | .00 | 8.02K | 833.03 GiB
--- STREAMS ---
STREAM | TYPE | NAME | REQUESTS | # ↓ | # ↑
------------------------------- | --------- | ----------------- | -------- | ---------- | ---------
*:*:* → app:msvc_orders:restapi | GENERATOR | external requests | 315.36M | 300.75 GiB | 37.59 GiB
: app:db:msvc_orders | REDIRECT | | 315.36M | 150.37 GiB | 37.59 GiB
--- BACKUPS ---
BACKUP | SUCCESS | START | FINISH | #
------------------------------------ | ------- | ----------------- | ----------------- | ----------
app:db:msvc_orders → app:san:backups | | | |
Periodic backup of orders database | | | |
| ✓ | 02.00.00 00:00:00 | 02.00.00 00:00:00 | 843.75 MiB
| ✓ | 02.01.00 00:00:00 | 02.01.00 00:00:00 | 13.59 GiB
| ✓ | 02.02.00 00:00:00 | 02.02.00 00:00:00 | 25.13 GiB
| ✓ | 02.03.00 00:00:00 | 02.03.00 00:00:00 | 37.90 GiB
| ✓ | 02.04.00 00:00:00 | 02.04.00 00:00:00 | 50.26 GiB
| ✓ | 02.05.00 00:00:00 | 02.05.00 00:00:00 | 63.03 GiB
| ✓ | 02.06.00 00:00:00 | 02.06.00 00:00:00 | 75.39 GiB
| ✓ | 02.07.00 00:00:00 | 02.07.00 00:00:00 | 88.16 GiB
| ✓ | 02.08.00 00:00:00 | 02.08.00 00:00:00 | 100.93 GiB
| ✓ | 02.09.00 00:00:00 | 02.09.00 01:00:00 | 113.29 GiB
| ✓ | 02.10.00 00:00:00 | 02.10.00 01:00:00 | 126.06 GiB
| ✓ | 02.11.00 00:00:00 | 02.11.00 01:00:00 | 138.42 GiB
--- CONNECTIONS ---
CONNECTION | TYPE | # ↓ | # ↑ | REQ | 🖧 ↓ | 🖧 ↑ | ∑ 🖧
---------------------------------------------- | -------- | ---------- | ---------- | ------- | --------------------------- | ----------- | ------------
*:*:* → app:msvc_orders:restapi | PRIMARY | 150.37 GiB | 18.79 GiB | 157.68M | 40.96 Kbits | 5.12 Kbits | 46.08 Kbits
*:*:* → app:msvc_orders@1:restapi | BALANCER | 150.37 GiB | 18.79 GiB | 157.68M | 40.96 Kbits | 5.12 Kbits | 46.08 Kbits
app:db:msvc_orders → app:db@1:msvc_orders | REPLICA | 300.75 GiB | 112.78 GiB | 315.36M | 81.92 Kbits | 30.72 Kbits | 112.64 Kbits
app:db:msvc_orders → app:san:backups | BACKUP | 833.03 GiB | - | 15 | 218.16 Mbits - 268.44 Mbits | - | 268.44 Mbits
app:msvc_orders:restapi → app:db:msvc_orders | PRIMARY | 75.18 GiB | 18.79 GiB | 157.68M | 20.48 Kbits | 5.12 Kbits | 25.60 Kbits
app:msvc_orders@1:restapi → app:db:msvc_orders | PRIMARY | 75.18 GiB | 18.79 GiB | 157.68M | 20.48 Kbits | 5.12 Kbits | 25.60 Kbits По отчёту видны метрики по каждому из сервисов и сетевых соединений между ними.
Так же можно видеть, что резервное копирование под конец года стало занимать около 1 часа при скорости 32 МБ/с.
Остальные отчёты можно найти в каталоге workbench/reports/blueprint-simple-system.
Пример финального документа AsciiDoc в виде PDF – infrastructure_sizing.adoc
Пример диаграммы развёртывания, которая так же строится на основе финального XML с метриками
