Information System Hardware Sizing Guideline (TTAK.KO-10.0292/R3)
1. Overview
A. Definition
A TTA (Telecommunications Technology Association) standard guideline for objectively and quantitatively sizing hardware capacity for servers, storage, networks, and the like, based on workload and performance indicators when building an information system; R3 (revised 2023.12) updates the sizing formulas and reference tables to reflect cloud and virtualization environments.
Sizing is the activity of deciding, on solid grounds, "how powerful the equipment must be, and how much of it is needed." This is not a simple quote but a demand-supply matching problem: forecasting future workload and working backward to the computing resources that will absorb it. Relying only on experience or a vendor proposal blurs accountability for the judgment and makes different bidders' proposals mutually incomparable, whereas this guideline mandates a common calculation procedure and standard performance indicators (such as tpmC) so that different suppliers, auditors, and ordering agencies produce evidence that can be verified the same way.
The TTA standard number TTAK.KO-10.0292 has been revised several times, expanding its sizing targets and indicators. Early on the core was server-centric tpmC sizing, but through revisions the scope broadened to storage, network, and security equipment, and correction logic premised on virtualization and cloud resource sharing was added. In other words, it is important to understand that the guideline is not a fixed calculator but a living standard whose sizing model has been updated to keep pace with changing technical environments.
The character of this guideline can be summarized in three points. First, objectivity — the sizing basis is stated with standard indicators and coefficients so anyone can retrace and verify it. Second, quantitativeness — empirical judgment is excluded and scale is worked back from workload figures. Third, reproducibility — the procedure is defined so that the same input yields the same result, making results comparable across suppliers and auditors. These three characteristics are the basis on which the guideline functions as a de facto benchmark in public procurement and audit systems.
B. Background and Necessity
Hardware sizing fails in two directions. Over-sizing buys more equipment than needed, wasting budget, floor space, power, and cooling, and leaving idle resources even before depreciation ends. Conversely, under-sizing leads to response delays, timeouts, and outages at peak, destroying service trust and forcing urgent expansion at extra cost and downtime. Both failures are costs, but under-sizing in particular surfaces as a public-facing service halting right after launch, with wide social repercussions.
Especially in public and large-scale projects funded by taxpayers, "why is this much equipment needed" must be objectively justified during auditing, budget review, and procurement. For example, if a public agency proposes dozens of high-performance servers for a next-generation system, the audit demands the basis: concurrent users, transaction volume, peak ratio, and headroom. Without a standard guideline this justification falls into the circular argument that "the vendor proposed it," but with the guideline the sizing formula and coefficients can be retraced to verify the validity of the result after the fact.
Standardizing the basis of sizing also serves dispute prevention. When a performance problem arises after launch, comparing the workload assumptions used in sizing against actual workload can determine whether responsibility lies with the ordering agency's inadequate requirements, the supplier's sizing error, or an unforeseeable demand surge. Such after-the-fact judgment is possible only when the basis is documented.
C. Sizing Targets
Sizing targets are classified into servers (WAS/DB/AP), storage and backup, network (lines and switches), and security equipment. Each target has a different load profile and thus a different indicator: servers are sized around throughput (TPS, tpmC) and CPU/memory, storage around total data volume, growth rate, and IOPS (input/output per second), network around concurrent sessions and bandwidth (bps), and security equipment around sessions and throughput per second.
The reason indicators differ by target is that the bottleneck lies in a different place. No matter how fast transactions are, if disk IOPS cannot keep up the DB becomes the bottleneck; even with a relaxed server, insufficient line bandwidth blocks bulk transfers. Sizing is therefore not a single-indicator task but a multidimensional one that checks each resource's bottleneck together, and generously provisioning one resource while neglecting the rest binds the whole system to the performance of its weakest link.
The targets also differ in load character by tier. In a three-tier (web-WAS-DB) architecture, the web tier handles many static requests and sessions and scales horizontally easily, the WAS uses much CPU for business logic, and the DB is a stateful single point with heavy vertical-scaling and redundancy burdens. Thus even the same transaction sizes to different required resources per tier, and the DB tier in particular is hard to scale, so the cost of a sizing error there is greatest.
2. Sizing Procedure and Overall Structure
flowchart LR
A["Requirements & workload analysis"] --> B["Select target & method"]
B --> C["Apply baseline & correction factors"]
C --> D["Calculate scale"]
D --> E["Verify & adjust"]
E -->|"short or excessive"| A
The core logic of the procedure is "define demand first, then divide that demand by the unit performance of the equipment." Summarized as a division, sizing is required equipment = total required performance ÷ unit performance of one machine, and how accurately the numerator is built governs the quality of the sizing.
In the first step, workload analysis, the concurrent users, transactions (TPS), data volume, and the peak (maximum load) point are identified. Because sizing must withstand the peak rather than the average, identifying the peak is especially important. For instance, systems whose load surges at a specific moment—year-end tax settlement, course registration, holiday ticketing—will surely fail if sized by average load. In this step, a peak scenario is fixed as concrete figures on the basis of past logs, comparable-system statistics, and interviews with business owners.
Next the sizing method is chosen per target. Standard-indicator-based quantitative sizing suits new large-scale systems, while reference models are used alongside for expansions of existing systems or when comparable cases are abundant. Then correction factors—performance, headroom, redundancy, target availability—are applied to inflate total required performance, the scale is calculated, and finally it is verified and adjusted through benchmarks (BMT), load tests, and validity review. If verification reveals over- or under-sizing, returning to the workload assumptions to re-size is the iterative loop that forms the essence of this procedure.
This procedure emphasizes the traceability of each step. One must be able to work back from the final equipment count to the workload profile, or justification in auditing and review is impossible. Conversely, if some step's assumption is undocumented, that point becomes a blind spot in verification, making accountability impossible when problems arise after launch. Leaving the outputs of each step (workload profile, correction-basis table, sizing result report) is therefore the practical requirement for complying with the guideline.
| Step | Content | Output |
|---|---|---|
| Workload analysis | Identify concurrent users, transactions (TPS), data volume, peak | Workload profile |
| Method selection | Decide sizing method per target (quantitative, reference) | Sizing method document |
| Apply correction | Reflect performance, headroom, redundancy, availability factors | Correction-basis table |
| Calculate & verify | Compute scale, then verify validity and benchmark | Sizing result report |
3. Sizing Methods and Performance Indicators
flowchart TB
subgraph Demand["Required performance (numerator)"]
T1["Baseline transaction volume"] --> M["Total required performance"]
T2["Peak ratio"] --> M
T3["Headroom, redundancy, availability"] --> M
end
subgraph Unit["Unit performance (denominator)"]
U1["tpmC / OPS / SPECint"] --> U["Equipment unit performance"]
end
M --> R["Required scale = required perf. ÷ unit perf."]
U --> R
Sizing methods are built along three axes. Numerical (quantitative) basis calculates with standard performance indicators such as TPC-C's tpmC, transaction throughput (OPS), and SPEC's SPECint. tpmC, meaning "new-order transactions processable per minute," is the TPC-C benchmark indicator; because server makers publish certified measurements, using it as the denominator (unit performance) gives a clear basis and suits new large-scale systems. SPECint represents integer-operation performance and is used for sizing CPU-intensive work.
Reference-model basis compares and infers from actual measurements or standard configurations of comparable existing systems. It is used when deriving a new indicator is hard (e.g., new equipment with no benchmark) or when quantitative results need cross-checking. For example, if a peer agency's identical-task system runs on four servers and our workload is 1.5 times theirs, one takes about six servers as a reference to check against the quantitative figure. Reference models fit reality well but are limited in that the result depends on the quality of the reference target.
To this, correction and headroom are commonly applied to absorb real-world uncertainty. The skeleton of the formula is required performance = baseline transaction volume × peak ratio × headroom ÷ equipment unit performance. As a concrete case, in a system that normally processes 100 transactions per second, if load surges threefold at peak (peak ratio 3) and CPU utilization is capped at 70% for 30% headroom (headroom ≈ 1/0.7 ≈ 1.43), the performance actually to be secured is 100 × 3 × 1.43 ≈ 429 TPS, well over four times the baseline. Adding redundancy (N+1) for fault tolerance raises the secured scale again. Multiplying coefficients explicitly like this makes the sizing basis transparent and lets each coefficient's validity be reviewed individually.
| Method | Description | Suitable situation |
|---|---|---|
| Numerical (quantitative) basis | Calculate with standard indicators such as tpmC, OPS, SPECint | New, large-scale; certified basis needed |
| Reference-model basis | Compare and infer from comparable-system cases and standard configs | Expansion, cross-check; indicator hard to derive |
| Correction and headroom | Reflect peak ratio, growth rate, redundancy, target availability | Applied commonly to all sizing |
How large the correction factors are set is the crux of the trade-off. Setting headroom large is safe but drifts toward over-sizing; setting it small is economical but weak at peak. The guideline requires reference ranges by workload type and a stated basis so these factors are not chosen arbitrarily, and this is the dividing line between "sizing by gut feel" and "standard sizing."
Not only CPU/tpmC but memory sizing matters separately. WAS sizes baseline memory as concurrent sessions × heap use per session, and DB sizes by summing buffer cache, sort area, and connection pool. If memory is insufficient, swapping and GC (garbage collection) surges cause response to plummet even with spare CPU, so the classic "CPU is ample yet it's slow" bottleneck comes from under-sizing memory. Thus tpmC-based CPU sizing and memory sizing must be performed independently and cross-checked.
Headroom also hides the variable of peak duration. A momentary spike can be absorbed by queuing and buffering, but if the peak persists for tens of minutes or more, the resource is actually needed at that level. Thus even at the same peak ratio, a "short, sharp load" and a "long, gentle load" require different performance, and one must grasp the load's shape (duration, distribution) in workload analysis to set headroom reasonably.
4. Sizing Practice Cases and Comparison
Quantitative and reference sizing are not exclusive but complementary. In practice a three-tier structure is common: draw a first-cut scale with the quantitative formula, cross-check with a reference model whether the value is in a sensible range, then finally validate with a BMT (benchmark test). If the three methods diverge greatly, one of the workload assumptions or coefficients is wrong, signaling a re-review.
The reason this cross-check matters is that each method misses a different error. The quantitative formula silently misses by a lot if a coefficient assumption is wrong and has no sense of reality, while the reference model is realistic but distorted if the reference target's work characteristics differ. BMT has the highest reliability but takes time and cost and makes securing real data hard. Overlaying the three methods lets one catch another's error, raising the robustness of sizing above relying on any single one.
Consider a public portal as a concrete case. With 10,000 concurrent users normally and 0.2 transactions per second per user, the baseline load is 2,000 TPS. But if access surges fivefold on a policy-announcement day, applying peak ratio 5 requires 10,000 TPS. Adding headroom 1.43 and redundancy for non-stop operation, the performance to secure exceeds 20,000 TPS, and if one server's unit performance is a certain tpmC-equivalent level, the required server count is derived. Without this calculation, "a few servers will do" is merely an unverifiable assertion.
The reason each resource's sizing logic differs is the difference in bottleneck location noted earlier, and the practical implication is "resources must be secured in balance." Over-investing in one resource raises cost but leaves overall performance bound to the weakest resource, unimproved. This sense of balance makes sizing a design activity rather than simple division.
Network sizing likewise does not end with a bandwidth multiplication. One must look at concurrent session count, average/peak traffic per session, and the session-handling limits of security equipment (firewall, IPS) together. For example, if bandwidth is ample but the firewall's concurrent session table fills up, new connections are refused—a separate bottleneck not solved by adding lines. Identifying each resource's "limit that is exhausted first" is thus the crux of accurate sizing.
Storage sizing differs in logic from servers. One must look not only at total data volume but also at growth rate and IOPS. For instance, assuming 10TB of initial data with 30% annual growth requires about 22TB in three years, and adding backup, snapshot, and index overhead plus headroom space (typically 20–30%) gives the actual capacity to secure. At the same time one must separately confirm that the disk configuration (SSD/HDD, RAID) can handle the IOPS transactions require, avoiding the case where capacity is enough but I/O becomes the bottleneck.
Because growth-rate assumptions compound, even a small error widens greatly over time. In the example above, wrongly under-estimating growth as 50% instead of 30% makes the actual need in three years about 34TB, far exceeding the sizing. Thus, taking as a premise that storage is a resource re-sized and expanded more frequently than servers, it is practical to also design a structure allowing online expansion (scale-out storage, volume expansion). This is why servers are approached with ample initial provisioning while storage is approached around expandability.
| Category | Server | Storage | Network |
|---|---|---|---|
| Key indicator | TPS, tpmC, SPECint | Total, growth rate, IOPS | Concurrent sessions, bandwidth |
| Bottleneck factor | CPU, memory | Capacity, I/O | Line, switch |
| Headroom | CPU utilization cap | Headroom space 20–30% | Peak bandwidth |
In actual public-sector audits, each item in this table is checked for whether "assumed value—basis—calculation—result" lines up row by row. For example, whether the peak ratio 3 in server sizing is based on three years of past traffic logs, or whether the 25% headroom space reflects backup and index overhead. Putting in large coefficients without basis draws over-sizing reductions, and conversely omitting growth rate draws early-expansion-risk findings. In this way the guideline makes sizing auditable and secures the legitimacy of the budget.
5. Deep Dive: Sizing Change in the Cloud/FinOps Era
From a professional engineer's perspective, the notable recent change is that cloud migration is shifting the sizing paradigm. On-premises-era sizing was a fixed-provisioning (peak-based provisioning) model that bought all the equipment to withstand future peaks up front. But in on-demand, auto-scaling environments, one keeps only minimum resources normally and increases automatically as load rises, so the center of gravity shifts from "fixed provisioning for the peak" to "elastic provisioning + cost optimization (FinOps)."
Even so, the sizing guideline remains valid; rather, its role is redefined. Auto-scaling too must set minimum/maximum capacity and a budget cap to prevent runaway costs, and setting those boundaries requires a workload-based quantitative basis. Decisions like reserved instances (RI) and savings plans that lower unit price via long-term commitment also stand on the sizing judgment of "how large is the baseline load." That is, the cloud has not eliminated sizing but changed its character from a one-off initial calculation to continuous capacity and cost management.
In container/Kubernetes environments too, a pod's requests/limits and the HPA (Horizontal Pod Autoscaler) thresholds become new sizing targets. Setting requests too large wastes node resources; too small causes OOM (out of memory) and throttling that break performance. Ultimately the guideline's fundamental logic of "measure required performance and divide by unit resource" works unchanged, with only the unit changed from physical servers to pods.
As a practical case, large-scale e-commerce experiences an extreme peak where load on a big sale day jumps tens of times over normal. Unable to handle this with fixed provisioning, they operate on minimum resources normally, scale up in advance to match predicted load before the event, and absorb residual variation with auto-scaling. Even then, "how far to scale up (maximum capacity)" and the "budget cap" are set in advance by sizing calculation, and here the logic of the sizing guideline is reused as the backbone of cloud cost control.
Advances in observability shift the basis of sizing from prior prediction to measurement-based continuous correction. Constantly observing actual load via APM and metric collection lets one verify whether the peak ratio and headroom assumed in sizing match reality, and reflect that in the next expansion decision. This can be seen as extending the "verify and adjust" loop the guideline requires into the operations stage.
Regarding likely exam directions, hardware sizing is likely to deepen beyond a short-answer "state the sizing formula and coefficients accurately" toward asking about its relation to cloud/auto-scaling, cost optimization from a FinOps perspective, and its linkage with availability design. Therefore, in an answer, weaving together the classic basis of the tpmC formula and the latest current of elastic provisioning and continuous capacity management is the high-scoring strategy. Presenting the guideline's reason for existence (securing an objective basis) as a principle running through both on-premises and cloud raises persuasiveness.
6. Considerations and Implications
Reflecting the future and growth: Sizing must cover not the snapshot at launch but the data and user growth of the coming 3–5 years. Omitting growth rate causes early expansion with extra cost and downtime, while over-estimating it causes initial over-investment. Stating the basis of the growth curve (business plan, past trend) is key.
Linkage with availability and redundancy design: A target availability (e.g., 99.9%) determines redundancy and DR (disaster recovery) capacity, so it is inseparable from sizing. Requiring non-stop operation needs N+1 or more spare nodes, which enlarges the secured scale accordingly. Availability requirements must be fixed as quantitative goals first, then reflected in sizing.
Risk of sizing without verification: Do not stop at the formula; validate with BMT and load tests. A vendor-certified tpmC is a value under ideal conditions and often does not appear as-is in actual work, so the gap from a value measured with real data and queries must be corrected before the sizing figure earns trust.
Strategic shift to cloud/FinOps: In on-premises–cloud hybrid environments, a strategic placement of baseline load on on-premises/RI and variable load on on-demand/auto-scaling is effective. Sizing becomes the basis for setting the boundary of this placement and is used as a baseline not only for initial capacity but for continuous cost optimization.
Consistency with standards and audits: For a public project, the sizing basis must be consistent with TTA guidelines and audit criteria to pass budget review and audit. Documenting the sizing method, coefficients, and reference basis to secure after-the-fact verifiability is the practical point a professional engineer must handle.
Resource balance and per-tier scalability: Secure CPU, memory, IOPS, and bandwidth in balance, but a single point like the DB that is hard to scale horizontally must be given ample headroom and redundancy from the start. Distinguishing tiers that scale easily from those that do not, and applying differentiated headroom, yields high cost-effectiveness.
Sustainability and power efficiency (Green IT): Recently, data centers face growing power and carbon constraints, so over-sizing is a burden not only in budget but in power, cooling, and carbon terms. A perspective that also considers performance per watt and PUE to choose a sustainable scale is required in sizing.
Decision-making under uncertainty: Because future workload is inherently a prediction, it is desirable to size not with a single scenario but with optimistic/baseline/pessimistic multiple scenarios and present that range to decision-makers. The elasticity of the cloud becomes a means to absorb this uncertainty, so the newer the service with lower prediction confidence, the greater the value of elastic provisioning over fixed provisioning.
References
- Telecommunications Technology Association (TTA) standards library: https://www.tta.or.kr
- TPC-C benchmark (tpmC) official site: https://www.tpc.org/tpcc/
- SPEC (Standard Performance Evaluation Corporation): https://www.spec.org
In one line: TTAK.KO-10.0292/R3 is a guideline that objectively sizes HW capacity on the basis of standard performance indicators such as tpmC through the procedure workload analysis → method selection → correction → calculation and verification; with the logic required performance = baseline volume × peak ratio × headroom ÷ unit performance it prevents over- and under-sizing and provides an audit basis for public projects, and in the cloud/FinOps era its role is redefined beyond initial capacity sizing into a baseline for elastic provisioning and continuous cost optimization.