IOPS와 처리량: 데이터베이스에 맞는 성능 지표 선택하기

By Mirko Peters · 2026-08-11 · Updated 2026-08-26

SQL Server와 같이 부하가 큰 워크로드를 위한 고성능 인프라를 설계하려는 아키텍트와 데이터베이스 관리자는 수많은 기술 약어와 스토리지 사양을 마주하게 됩니다. 그중에서도 가장 중요하지만 자주 오해되는 지표가 IOPS와 처리량입니다. 프로비저닝할 때 잘못된 지표를 선택하면 쿼리가 느려지고, 시스템에 병목이 생기며, 예산이 낭비될 수 있습니다. 데이터베이스가 실제로 데이터를 읽고 쓰는 방식을 이해하는 것이 탄력적인 아키텍처를 구축하는 첫걸음입니다.

Automatically translated with AI from the original post. Read the English original

SQL Server와 같이 부하가 큰 워크로드를 위한 고성능 인프라를 설계하려는 아키텍트와 데이터베이스 관리자는 수많은 기술 약어와 스토리지 사양을 마주하게 됩니다. 그중에서도 가장 중요하지만 자주 오해되는 지표가 IOPS와 처리량입니다. 프로비저닝할 때 잘못된 지표를 선택하면 쿼리가 느려지고, 시스템에 병목이 생기며, 예산이 낭비될 수 있습니다. 데이터베이스가 실제로 데이터를 읽고 쓰는 방식을 이해하는 것이 탄력적인 아키텍처를 구축하는 첫걸음입니다.

이 글에서는 IOPS와 처리량의 근본적인 차이를 살펴보고, 이들이 집약적인 데이터베이스 워크로드에 어떻게 적용되는지 분석합니다. 또한 가상 머신 한도와 같은 일반적인 아키텍처 병목 지점을 짚어 보고, 공유 스토리지 모델이 최신 클라우드 환경을 어떻게 바꾸는지 알아봅니다.

데이터베이스 성능 지표 소개

스토리지 성능은 모든 상황에 맞는 단일 척도로 측정할 수 없습니다. 클라우드 스토리지나 기존 SAN 하드웨어를 살펴보면, 공급업체들은 데이터가 얼마나 빠르게 이동할 수 있는지, 디스크가 초당 몇 개의 작업을 처리할 수 있는지에 대한 인상적인 수치를 내세웁니다. 하지만 데이터베이스 엔진은 동영상 스트리밍 서비스나 대용량 파일 서버와는 완전히 다르게 동작합니다. 동영상 서버는 큰 데이터 스트림을 연속적으로 파이프에 밀어 넣어야 하지만, 데이터베이스는 특정 행을 찾고, 트랜잭션 로그를 갱신하고, 페이지를 메모리에 캐싱하는 데 시간을 씁니다.

압박 속에서도 무너지지 않는 환경을 설계하려면 먼저 워크로드마다 고유한 특성을 이해해야 합니다. 이를 위해 스토리지 성능의 두 축인 초당 입출력 작업 수(IOPS)와 초당 메가바이트(처리량)를 깊이 살펴보겠습니다.

IOPS 정의: 데이터베이스가 작은 읽기와 쓰기에 의존하는 이유

IOPS는 Input and Output Operations Per Second의 약자로, 장치가 1초 동안 처리할 수 있는 개별 스토리지 요청의 수를 나타내는 지표입니다. SQL Server와 같은 집약적인 데이터베이스 플랫폼에서는 보통 IOPS가 가장 중요한 지표입니다.

데이터베이스는 본질적으로 트랜잭션 중심입니다. 사용자가 애플리케이션에 로그인할 때, 데이터베이스는 보통 수 기가바이트에 달하는 거대한 파일을 한꺼번에 읽거나 쓰지 않습니다. 대신 수천 개의 작고 목적이 분명한 작업을 수행합니다. 사용자 프로필을 가져오기 위해 8KB 데이터 페이지를 읽거나, 트랜잭션 로그에 수백 바이트를 기록하거나, 인덱스를 갱신할 수도 있습니다. 이러한 작업은 매우 작기 때문에, 스토리지 하위 시스템이 대량의 개별 명령을 처리하는 능력, 즉 IOPS 용량이 성능을 좌우하는 핵심 요소가 됩니다. 사용자 트랜잭션을 따라잡기 위해 데이터베이스에 10,000 IOPS가 필요한데 스토리지 디스크가 3,000 IOPS만 제공할 수 있다면, 쿼리는 대기열에 쌓이고 잠금이 연쇄적으로 발생하여 애플리케이션 응답 시간이 급격히 떨어지게 됩니다.

처리량 정의: 대역폭이 가장 중요한 경우

IOPS가 작업의 *개수*를 측정한다면, 처리량은 일정 시간 동안 이동한 데이터의 *양*을 측정하며, 보통 초당 메가바이트(MB/s)로 표시합니다. IOPS를 고속도로를 달리는 차량의 대수로, 처리량을 그 차량들이 실어 나르는 화물의 총중량으로 생각하면 이해하기 쉽습니다.

처리량이 IOPS보다 훨씬 중요한 상황도 있습니다. 야간 데이터베이스 백업, 대규모 데이터 웨어하우스 가져오기, 테이블의 수백만 행을 스캔하는 분석 쿼리가 대표적인 예입니다. 이러한 작업은 초당 처리되는 개별 요청의 수보다는, 대량의 데이터 스트림을 얼마나 빠르게 입력하거나 출력할 수 있는지에 더 관심을 둡니다. IOPS는 높지만 처리량 한도가 낮은 스토리지에서 대규모 데이터 마이그레이션을 실행하면, 데이터 파이프가 충분히 넓지 않아 마이그레이션이 예상보다 몇 시간씩 더 걸리는 것을 확인하게 될 것입니다.

애플리케이션 워크로드를 스토리지 구성에 매핑하기

기업 내 모든 애플리케이션에는 고유한 스토리지 특성이 있습니다. 환경을 성공적으로 설계하려면 이러한 특정 읽기 및 쓰기 패턴을 적절한 스토리지 구성에 매핑해야 합니다. 예를 들어, 트랜잭션 처리(OLTP) 데이터베이스는 지연 시간 급증 없이 동시 사용자 요청을 처리하려면 높은 IOPS 성능이 필요합니다. 반대로 데이터 레이크나 보고 서버는 분석 쿼리를 빠르게 처리하기 위해 높은 처리량을 요구할 수 있습니다.

문제는 하나의 환경에서 서로 충돌하는 패턴을 가진 여러 워크로드가 함께 운영될 때 발생합니다. SQL 데이터베이스는 월말 재무 보고 시점에 부하가 최고조에 달하고, 리포팅 서버는 매일 오전 8시에 급증하며, 백업 시스템은 야간에 네트워크 트래픽을 가득 채울 수 있습니다. 과거에는 관리자가 이러한 최고 부하 시점마다 별도의 디스크를 프로비저닝했고, 그 결과 과다 프로비저닝과 유휴 리소스가 대량으로 발생했습니다.

가상 머신 병목 현상: 디스크를 넘어서

데이터베이스의 IOPS와 처리량 요구 사항을 꼼꼼하게 계산하고 가장 빠른 디스크를 프로비저닝하더라도 심각한 성능 한계에 부딪힐 수 있습니다. 원인은 대개 스토리지 매체 자체가 아니라 그 디스크가 연결된 가상 머신에 있습니다.

예를 들어 Azure 가상 머신은 선택한 VM의 크기와 등급에 따라 전체 디스크 IOPS와 처리량에 엄격한 제한을 둡니다. 엔터프라이즈급 초고속 디스크를 사양이 낮은 VM 크기에 연결할 수는 있지만, VM은 자체 최대 임계값까지만 스토리지 트래픽을 허용합니다. 스토리지 시스템이 20,000 IOPS를 제공할 수 있더라도 가상 머신 경로가 10,000 IOPS로 제한한다면, 그것이 실제 상한선입니다. 따라서 디스크 사양과 컴퓨팅 크기를 항상 함께 점검하여, 두 요소 사이의 경로가 최고 부하 워크로드를 감당할 만큼 충분히 넓은지 확인해야 합니다.

공유 스토리지 풀이 성능 계획을 바꾸는 방식

워크로드마다 격리된 대용량 디스크를 프로비저닝하는 악순환을 끊기 위해, 최신 클라우드 아키텍처는 전통적인 SAN(Storage Area Network)을 떠올리게 하는 공유 스토리지 풀을 주목하고 있습니다. 성능을 분리된 고정 컨테이너에 가두는 대신, 공유 모델은 용량과 IOPS를 함께 풀로 묶습니다.

풀링된 리소스를 사용하는 환경에서는 성능 지표가 용량에 비례하여 확장됩니다. 예를 들어 Azure Elastic SAN에서는 기본 용량 1TiB마다 5,000 IOPS와 초당 200MB의 처리량 같은 일정량의 성능이 중앙 풀에 더해집니다. 이 공유 풀을 통해 여러 볼륨이 공통된 성능 예산을 나눠 쓸 수 있습니다. 예를 들어 재무 데이터베이스가 대규모 보고 주기 동안 IOPS를 대량으로 필요로 하는 반면 웨어하우스 시스템이 한가하다면, 그 리소스는 동적으로 이동하여 활성 워크로드를 지원할 수 있습니다.

걸림돌 피하기: 최고 수요와 공유 한도의 균형 맞추기

공유 스토리지 풀은 뛰어난 유연성과 비용 절감 효과를 제공하지만, 무제한 성능을 보장하는 만능 해법은 아닙니다. 리소스를 풀링한다는 것은 모든 데이터베이스가 정확히 같은 밀리초에 절대적 최고 수요에 도달하지는 않는다는 통계적 가능성에 기대는 것입니다.

여러 고부하 워크로드가 동시에 급증하여 결합된 수요가 공유 풀의 한도를 넘으면 스로틀링이 발생합니다. 스로틀링은 지연 시간을 늘리고 쿼리 속도를 떨어뜨리며, 연쇄적인 애플리케이션 타임아웃을 일으킬 수 있습니다. 데이터베이스 관리자와 인프라 설계자는 과거 지표를 면밀히 분석하고 동시 최고 사용량을 파악해야 하며, 공유 스토리지 풀이 겹치는 최고 수요를 여유 있게 흡수할 수 있도록 충분한 헤드룸을 두고 크기를 정해야 합니다.

결론: 데이터베이스에 맞는 지표 선택하기

클라우드에서 고부하 데이터베이스 워크로드를 관리하는 모든 사람에게 IOPS와 처리량의 균형을 맞추는 능력은 필수입니다. 애플리케이션이 작은 단위의 빠른 작업에 목말라 있는지, 아니면 대용량 데이터 대역폭에 목말라 있는지를 정확히 진단하면 값비싼 성능 병목을 피할 수 있습니다. 또한 공유 풀과 같은 최신 스토리지 패러다임을 도입하면 효율을 크게 높이고, 인프라가 비즈니스 성장에 맞춰 지능적으로 확장되도록 할 수 있습니다. 최신 클라우드 스토리지 아키텍처가 이러한 확장 및 성능 과제를 어떻게 해결하는지 더 깊이 알아보려면 관련 팟캐스트 에피소드 Azure Elastic SAN — Simply Explained를 꼭 확인해 보세요.