다음을 통해 공유

OLTP(온라인 트랜잭션 처리)

컴퓨터 시스템을 사용하는 트랜잭션 데이터 관리는 OLTP(온라인 트랜잭션 처리)라고 합니다. OLTP 시스템은 조직의 일상적인 작업에서 발생하는 비즈니스 상호 작용을 기록하고, 이 데이터를 쿼리하여 유추할 수 있도록 지원합니다.

트랜잭션 데이터

트랜잭션 데이터는 조직의 활동과 관련된 상호 작용을 추적하는 정보입니다. 이러한 상호 작용은 일반적으로 고객으로부터 수신된 지불, 공급업체로 수행된 지불, 인벤토리를 통해 이동되는 제품, 수행된 주문 또는 배달된 서비스와 같은 비즈니스 트랜잭션입니다. 트랜잭션 자체를 나타내는 트랜잭션 이벤트는 일반적으로 시간 차원, 일부 숫자 값 및 다른 데이터에 대한 참조를 포함합니다.

트랜잭션은 일반적으로 원자 성과 일관성이 있어야 합니다. 원자성은 전체 트랜잭션이 항상 하나의 작업 단위로 성공 또는 실패하고, 절반만 완료된 상태를 유지하지 않는다는 것을 의미합니다. 트랜잭션을 완료할 수 없는 경우 데이터베이스 시스템은 해당 트랜잭션의 일부로 이미 수행된 단계를 롤백해야 합니다. 기존의 RDBMS(관계형 데이터베이스 관리 시스템)에서는 트랜잭션을 완료할 수 없는 경우 이 롤백이 자동으로 수행됩니다. 일관성은 트랜잭션이 항상 데이터를 유효한 상태로 유지함을 의미합니다. (이러한 트랜잭션은 원자성 및 일관성에 대한 비공식적인 설명입니다. ACID와 같은 이러한 속성에 대한 보다 공식적인 정의가 있습니다.)

트랜잭션 데이터베이스는 비관적 잠금과 같은 다양한 잠금 전략을 사용하여 트랜잭션에 대한 강력한 일관성을 지원하여 모든 사용자 및 프로세스에 대해 워크로드 컨텍스트 내에서 모든 데이터가 일관되도록 할 수 있습니다.

트랜잭션 데이터를 사용하는 가장 일반적인 배포 아키텍처는 3계층 아키텍처의 데이터 저장소 계층입니다. 3계층 아키텍처는 일반적으로 프레젠테이션 계층, 비즈니스 논리 계층 및 데이터 저장소 계층으로 구성됩니다. 관련 배포 아키텍처는 비즈니스 논리를 처리하는 여러 중간 계층을 가질 수 있는 N 계층 아키텍처입니다.

트랜잭션 데이터의 일반적인 특성

트랜잭션 데이터는 다음과 같은 특성을 가질 수 있습니다.

요구 사항 설명
표준화 고도로 정규화됨
스키마 쓰기 시 스키마, 적용됨
일관성 강력한 일관성 ACID 보장
무결성 높은 무결성
트랜잭션 사용 예
잠금 전략 비관적 또는 낙관적
업데이트 가능 예
추가 가능 예
작업 과도 쓰기, 보통 읽기
인덱싱 기본 및 보조 인덱스
데이터 크기 소규모~중간 규모
쿼리 유연성 매우 유연
확장 작음(MB) ~ 큼(몇 TB)

이 솔루션을 사용해야 하는 경우

비즈니스 트랜잭션을 효율적으로 처리 및 저장하고, 클라이언트 애플리케이션에 일관된 방식에서 사용할 수 있게 하려는 경우 OLTP를 선택합니다. 처리의 실질적인 지연이 비즈니스의 일상적인 운영에 부정적인 영향을 미칠 경우 이 아키텍처를 사용합니다.

OLTP 시스템은 트랜잭션을 효율적으로 처리 및 저장하고 트랜잭션 데이터를 쿼리하도록 설계되었습니다. OLTP 시스템에서 개별 트랜잭션을 효율적으로 처리하고 저장하는 목표는 부분적으로 데이터 정규화를 통해 수행됩니다. 즉, 중복성이 낮은 작은 청크로 데이터를 분할합니다. 이 단계를 사용하면 OLTP 시스템에서 많은 수의 트랜잭션을 독립적으로 처리할 수 있으며 중복 데이터가 있는 상태에서 데이터 무결성을 유지하는 데 필요한 추가 프로세스를 방지할 수 있습니다.

과제

OLTP 시스템을 구현 및 사용할 경우 다음과 같은 몇 가지 해결 과제가 발생할 수 있습니다.

  • 잘 계획된 스키마와 같은 예외가 있지만 OLTP 시스템은 대량의 분산 데이터에 대한 집계를 처리하는 데 항상 적합한 것은 아닙니다. 수백만 개의 개별 트랜잭션에 대한 집계 계산을 사용하는 데이터에 대한 분석은 OLTP 시스템에 매우 리소스 집약적입니다. 따라서 실행이 느려질 수 있으며, 데이터베이스의 다른 트랜잭션을 차단하게 되어 속도 저하를 야기할 수 있습니다.

  • 고도로 정규화된 데이터에 대한 분석 및 보고를 수행하는 경우 대부분의 쿼리는 조인을 사용하여 데이터를 비정규화해야 하기 때문에 쿼리가 복잡한 경향이 있습니다. 정규화가 증가하면 비즈니스 사용자가 DBA 또는 데이터 개발자의 도움 없이 쿼리하기가 어려울 수 있습니다.

  • 트랜잭션 기록을 무기한 저장하고, 하나의 테이블에 너무 많은 데이터를 저장하게 되면 저장된 트랜잭션 수에 따라 쿼리 성능이 저하될 수 있습니다. 일반적인 해결 방법은 OLTP 시스템에서 관련 기간(예: 현재 회계 연도)을 유지하고 기록 데이터를 데이터 마트 또는 데이터 웨어하우스와 같은 다른 시스템에 오프로드하는 것입니다.

Azure의 OLTP

App Service Web Apps에서 호스트되는 웹 사이트, App Service에서 실행되는 REST API, 모바일 또는 데스크톱 애플리케이션과 같은 애플리케이션은 일반적으로 REST API 중개자를 통해 OLTP 시스템과 통신합니다.

실제로 대부분의 워크로드는 순수 OLTP가 아닙니다. 분석 구성 요소의 역할을 하기도 합니다. 또한 워크로드에는 운영 시스템에 대한 보고서 실행과 같은 실시간 보고가 필요한 경우가 많습니다. 이 워크로드를 HTAP(하이브리드 트랜잭션/분석 처리)(하이브리드 트랜잭션 및 분석 처리)라고도 합니다. 자세한 내용은 OLAP(온라인 분석 처리)를 참조하세요.

Azure에서 다음 데이터 저장소는 모두 OLTP 및 트랜잭션 데이터 관리에 대한 핵심 요구 사항을 충족합니다.

주요 선택 조건

선택 옵션의 범위를 좁히려면 먼저 다음 질문에 답변합니다.

  • 사용자 고유의 서버를 관리하지 않고 관리되는 서비스를 원하시나요?

  • 솔루션에 Microsoft SQL Server, MySQL 또는 PostgreSQL 호환성에 대한 특정 종속성이 있나요? 애플리케이션은 데이터 저장소와 통신하기 위해 지원하는 드라이버 또는 사용되는 데이터베이스에 대한 가정에 따라 선택할 수 있는 데이터 저장소를 제한할 수 있습니다.

  • 쓰기 처리량 요구 사항이 높은가요? 그렇다면 메모리 내 테이블 또는 Azure Cosmos DB와 같은 전역 배포 기능을 제공하는 옵션을 선택합니다.

  • 솔루션이 다중 테넌트인가요? 그렇다면 데이터베이스마다 고정 리소스가 있는 것이 아니라, 탄력적인 리소스 풀에서 여러 데이터베이스 인스턴스를 가져오는 방식의 용량 풀을 지원하는 옵션을 고려합니다. 탄력적 풀을 사용하면 모든 데이터베이스 인스턴스에 용량을 더 효율적으로 분산할 수 있으며 솔루션을 비용 효율적으로 만들 수 있습니다. Azure Cosmos DB는 다중 테넌트 시나리오에 대한 여러 격리 모델을 제공합니다.

  • 데이터를 여러 지역에서 짧은 대기 시간으로 읽을 수 있어야 하나요? 그렇다면 읽을 수 있는 보조 복제본 또는 전역 배포를 지원하는 옵션을 선택합니다.

  • 여러 지리적 지역에서 데이터베이스의 높은 가용성을 유지해야 하나요? 그렇다면 지리적 복제를 지원하는 옵션을 선택합니다. 또한 주 복제본에서 보조 복제본으로의 자동 장애 조치(Failover)를 지원하는 옵션을 고려합니다.

  • 워크로드에 보장된 ACID 트랜잭션이 필요한가요? 비관계형 데이터로 작업하는 경우 논리 파티션 내의 트랜잭션 일괄 처리 작업을 통해 ACID 보증을 제공하는 Azure Cosmos DB를 고려합니다.

  • 데이터베이스에 특정 보안 요구가 있나요? 그렇다면 행 수준 보안, 데이터 마스킹 및 투명한 데이터 암호화와 같은 기능을 제공하는 옵션을 검토합니다.

  • 솔루션에 분산 트랜잭션이 필요한가요? 그렇다면 Azure SQL Database 및 SQL Managed Instance 내의 탄력적 트랜잭션을 고려합니다. SQL Managed Instance는 MSDTC(Microsoft Distributed Transaction Coordinator)를 통한 기존 호출도 지원합니다.

다음 단계