트랜잭션 처리

컴퓨터 과학에서 트랜잭션 처리(transaction processing)는 트랜잭션이라 불리는 개별적이고 분리 불가능한 연산으로 나누어진 정보 처리이다.^[1] 각 트랜잭션은 완전한 단위로 성공하거나 실패해야 하며, 부분적으로만 완료될 수는 없다.

예를 들어, 온라인 서점에서 책을 구매할 때, 당신은 책에 대해 돈(이때는 신용판매 형태)을 교환한다. 신용이 유효하다면, 일련의 관련 작업은 당신이 책을 받고 서점이 당신의 돈을 받도록 보장한다. 그러나 교환 중에 일련의 작업 중 하나라도 실패하면 전체 교환이 실패한다. 당신은 책을 받지 못하고 서점은 당신의 돈을 받지 못한다. 교환을 균형 있고 예측 가능하게 만드는 기술을 트랜잭션 처리라고 한다. 트랜잭션은 트랜잭션 단위 내의 모든 작업이 성공적으로 완료되지 않는 한 데이터 지향 리소스가 영구적으로 업데이트되지 않도록 보장한다. 일련의 관련 작업을 완전히 성공하거나 완전히 실패하는 단위로 결합함으로써 오류 복구를 단순화하고 애플리케이션의 신뢰성을 높일 수 있다.

트랜잭션 처리 시스템은 비즈니스 수행에 필요한 일상적인 트랜잭션을 수행하는 트랜잭션 지향 애플리케이션을 호스팅하는 컴퓨터 하드웨어 및 소프트웨어로 구성된다. 예를 들어 판매 주문 입력, 항공 예약, 급여, 직원 기록, 제조 및 배송을 관리하는 시스템이 있다.

오늘날 모든 트랜잭션 처리가 대화형은 아니지만 대부분의 트랜잭션 처리가 대화형이므로 이 용어는 종종 온라인 트랜잭션 처리와 동의어로 취급된다.

트랜잭션 처리는 시스템(일반적으로 데이터베이스 또는 일부 최신 파일 시스템)의 무결성을 알려진 일관된 상태로 유지하도록 설계되었으며, 시스템의 상호 의존적인 작업이 모두 성공적으로 완료되거나 모두 성공적으로 취소되도록 보장한다.

예를 들어, 고객의 저축 계좌에서 당좌 계좌로 700달러를 이체하는 일반적인 은행 거래를 고려해 보자. 이 거래는 컴퓨터 용어로 최소 두 가지 개별 작업을 포함한다: 저축 계좌에서 700달러를 차감하는 것과 당좌 계좌에 700달러를 입금하는 것이다. 한 작업은 성공했지만 다른 작업은 성공하지 못하면, 은행의 장부는 그날 말에 균형이 맞지 않을 것이다. 따라서 전체 은행 데이터베이스에 불일치가 없도록 두 작업 모두 성공하거나 모두 실패하는 방법을 보장해야 한다.

트랜잭션 처리는 여러 개별 작업을 단일의 분리 불가능한 트랜잭션으로 연결하고, 트랜잭션 내의 모든 작업이 오류 없이 완료되거나, 하나도 완료되지 않도록 보장한다. 일부 작업은 완료되었지만 다른 작업을 시도하는 동안 오류가 발생하면 트랜잭션 처리 시스템은 트랜잭션의 모든 작업(성공한 작업 포함)을 "롤백"하여 트랜잭션의 모든 흔적을 지우고 시스템을 트랜잭션 처리가 시작되기 전의 일관되고 알려진 상태로 복원한다. 트랜잭션의 모든 작업이 성공적으로 완료되면 트랜잭션은 시스템에 의해 커밋되고, 데이터베이스의 모든 변경 사항은 영구적으로 저장된다. 일단 커밋되면 트랜잭션은 롤백할 수 없다.

트랜잭션 처리는 트랜잭션이 부분적으로 완료된 상태로 남을 수 있는 하드웨어 및 소프트웨어 오류를 방지한다. 트랜잭션 도중에 컴퓨터 시스템이 충돌하면 트랜잭션 처리 시스템은 커밋되지 않은 모든 트랜잭션의 모든 작업이 취소되도록 보장한다.

일반적으로 트랜잭션은 동시에 발행된다. 이들이 겹치면(즉, 데이터베이스의 동일한 부분에 접근해야 하는 경우) 충돌이 발생할 수 있다. 예를 들어, 위 예제에서 언급된 고객이 저축 계좌에 150달러를 가지고 있고 다른 사람에게 100달러를 이체하려고 시도하는 동시에 당좌 계좌로 100달러를 옮기려고 한다면, 둘 중 하나만 성공할 수 있다. 그러나 트랜잭션을 순차적으로 처리하도록 강제하는 것은 비효율적이다. 따라서 트랜잭션 처리의 동시 구현은 최종 결과가 충돌 없는 결과를 반영하도록 프로그래밍되어 있으며, 이는 트랜잭션을 어떤 순서로든 순차적으로 실행했을 때 도달할 수 있는 것과 동일하다(직렬화 성질이라는 속성). 우리의 예제에서 이는 어떤 트랜잭션이 먼저 발행되었든 관계없이, 다른 사람에게로의 이체 또는 당좌 계좌로의 이체 중 하나는 성공하고 다른 하나는 실패한다는 것을 의미한다.

모든 트랜잭션 처리 시스템의 기본 원리는 동일하다. 그러나 용어는 트랜잭션 처리 시스템마다 다를 수 있으며, 아래에 사용된 용어가 반드시 보편적인 것은 아니다.

 이 부분의 본문은 롤백 (데이터 관리)입니다.

트랜잭션 처리 시스템은 데이터베이스가 수정될 때 데이터베이스의 중간 상태를 기록한 다음, 이 기록을 사용하여 트랜잭션이 커밋될 수 없는 경우 데이터베이스를 알려진 상태로 복원함으로써 데이터베이스 무결성을 보장한다. 예를 들어, 트랜잭션이 어떤 수정도 하기 전에 데이터베이스의 정보 사본은 시스템에 의해 따로 보관된다(이를 때때로 비포 이미지라고도 한다). 트랜잭션의 어떤 부분이 커밋되기 전에 실패하면, 이 사본은 데이터베이스를 트랜잭션이 시작되기 전의 상태로 복원하는 데 사용된다.

데이터베이스 관리 시스템의 모든 수정 사항에 대한 별도의 저널을 유지하는 것도 가능하다(때때로 애프터 이미지라고도 함). 이는 실패한 트랜잭션의 롤백에는 필요하지 않지만, 데이터베이스 실패 시 데이터베이스 관리 시스템을 업데이트하는 데 유용하므로 일부 트랜잭션 처리 시스템에서 이를 제공한다. 데이터베이스 관리 시스템이 완전히 실패하면 가장 최근 백업에서 복원해야 한다. 백업은 백업이 수행된 이후 커밋된 트랜잭션을 반영하지 않는다. 그러나 데이터베이스 관리 시스템이 복원되면 애프터 이미지 저널을 데이터베이스에 적용(롤포워드)하여 데이터베이스 관리 시스템을 최신 상태로 만들 수 있다. 실패 당시 진행 중이던 모든 트랜잭션은 롤백될 수 있다. 결과는 일관되고 알려진 상태의 데이터베이스로, 실패 시점까지 커밋된 모든 트랜잭션의 결과를 포함한다.

 이 부분의 본문은 교착 상태입니다.

어떤 경우에는 두 트랜잭션이 처리 과정에서 동시에 데이터베이스의 동일한 부분에 접근하려고 시도하여 진행을 방해할 수 있다. 예를 들어, 트랜잭션 A는 데이터베이스의 X 부분을 접근하고, 트랜잭션 B는 데이터베이스의 Y 부분을 접근할 수 있다. 이때 트랜잭션 A가 데이터베이스의 Y 부분을 접근하려고 시도하고 트랜잭션 B가 X 부분을 접근하려고 시도하면 교착 상태가 발생하여 어느 트랜잭션도 앞으로 나아갈 수 없다. 트랜잭션 처리 시스템은 이러한 교착 상태가 발생할 때 이를 감지하도록 설계되었다. 일반적으로 두 트랜잭션은 모두 취소되고 롤백된 다음, 자동으로 다른 순서로 다시 시작되어 교착 상태가 다시 발생하지 않도록 한다. 또는 때때로 교착 상태에 있는 트랜잭션 중 하나만 취소, 롤백되고 짧은 지연 후 자동으로 다시 시작된다.

교착 상태는 세 개 이상의 트랜잭션 사이에서도 발생할 수 있다. 관련된 트랜잭션이 많을수록 감지하기가 더 어려워지며, 트랜잭션 처리 시스템이 감지할 수 있는 교착 상태에는 실용적인 한계가 있음을 알게 된다.

커밋 및 롤백 메커니즘을 사용할 수 없거나 바람직하지 않은 시스템에서는 실패한 트랜잭션을 취소하고 시스템을 이전 상태로 복원하기 위해 종종 보상 트랜잭션이 사용된다.

 이 부분의 본문은 ACID입니다.

짐 그레이는 1970년대 후반에 신뢰할 수 있는 트랜잭션 시스템의 속성을 ACID(원자성, 일관성, 고립성, 지속성)라는 약어로 정의했다.^[1]

 이 부분의 본문은 원자성 (데이터베이스 시스템)입니다.

트랜잭션의 상태 변경은 원자적이다: 모든 변경이 발생하거나 아무것도 발생하지 않는다. 이러한 변경에는 데이터베이스 변경, 메시지 및 변환기에 대한 작업이 포함된다.

일관성: 트랜잭션은 상태의 올바른 변환이다. 그룹으로 수행된 작업은 상태와 관련된 무결성 제약 조건을 위반하지 않는다.

트랜잭션이 동시에 실행되더라도 각 트랜잭션 T에게는 다른 트랜잭션이 T 이전에 실행되었거나 T 이후에 실행되었고, 둘 다는 아닌 것처럼 보인다.

트랜잭션이 성공적으로 완료되면(커밋되면) 데이터베이스에 대한 변경 사항은 실패 후에도 유지되고 변경 사항을 보존한다.

 이 부분의 본문은 거래처리시스템입니다.

IBM의 Information Management System과 같은 표준 트랜잭션 처리 소프트웨어는 1960년대에 처음 개발되었으며, 종종 특정 데이터베이스 관리 시스템과 밀접하게 결합되었다. 클라이언트-서버 컴퓨팅은 1980년대에 유사한 원칙을 구현했지만 성공률은 혼합되었다. 그러나 최근 몇 년 동안 분산 클라이언트-서버 모델은 유지 관리가 훨씬 더 어려워졌다. 다양한 온라인 서비스(특히 웹)의 증가로 인해 트랜잭션 수가 증가함에 따라 단일 분산 데이터베이스는 실용적인 해결책이 아니었다. 또한 대부분의 온라인 시스템은 단일 서버가 트랜잭션 처리를 처리할 수 있는 엄격한 클라이언트-서버 모델과는 대조적으로 함께 작동하는 전체 프로그램 모음으로 구성된다. 오늘날 메인프레임을 포함한 대규모 시스템으로 확장되는 프로그램 간 수준에서 작동하는 여러 트랜잭션 처리 시스템이 있다.

한 가지 노력은 X/Open 분산 트랜잭션 처리(DTP)이다(자바 트랜잭션 API(JTA)도 참조). 그러나 IBM의 CICS와 같은 독점 트랜잭션 처리 환경은 여전히 매우 인기가 많지만, CICS는 개방형 산업 표준을 포함하도록 발전했다.

익스트림 트랜잭션 처리(XTP)라는 용어는 특히 처리량 요구 사항(초당 트랜잭션 수)과 같이 비정상적으로 어려운 요구 사항이 있는 트랜잭션 처리 시스템을 설명하는 데 사용되었다. 이러한 시스템은 분산 또는 클러스터 스타일 아키텍처를 통해 구현될 수 있다. 이는 적어도 2011년부터 사용되었다.^[2][3]

• Gerhard Weikum, Gottfried Vossen, Transactional information systems: theory, algorithms, and the practice of concurrency control and recovery, Morgan Kaufmann, 2002, ISBN 1-55860-508-8
• 짐 그레이, Andreas Reuter, Transaction Processing—Concepts and Techniques, 1993, Morgan Kaufmann, ISBN 1-55860-190-2
• Philip A. Bernstein, Eric Newcomer, Principles of Transaction Processing, 1997, Morgan Kaufmann, ISBN 1-55860-415-4
• Ahmed K. Elmagarmid (Editor), Transaction Models for Advanced Database Applications, Morgan-Kaufmann, 1992, ISBN 1-55860-214-3

위키미디어 공용에 트랜잭션 처리 주제와 관련된 미디어 분류가 있습니다.

• 트랜잭션 처리의 핵심 (1999) 보관됨 2014-10-18 - 웨이백 머신
• SQL 데이터베이스 무결성을 위한 트랜잭션 처리 관리
• 트랜잭션 처리