KR101296778B1

KR101296778B1 - ＮｏＳＱＬ 데이터베이스를 위한 결과적 트랜잭션 처리 방법

Info

Publication number: KR101296778B1
Application number: KR1020120103188A
Authority: KR
Inventors: 이승용
Original assignee: (주)카디날정보기술
Priority date: 2012-09-18
Filing date: 2012-09-18
Publication date: 2013-08-14

Abstract

본 발명은 대용량 데이터를 처리하기 위해 분산시스템으로 구성된 NoSQL(Not Only SQL) 데이터베이스의 트랜잭션(transaction) 처리에 있어서, 트랜잭션의 4가지 성질 ACID - 원자성(Atomic), 일관성(Consistent), 고립성(Isolated), 지속성(Durable)을 보장하기 위해, 트랜잭션 로그를 이용한 트랜잭션의 일관성과 고립성을 보장하는 동시성 충돌 검사를 수행하는 단계와, NoSQL 클러스터 노드에서 장애가 발생한 시점에 활성화되어 있던 트랜잭션의 원자성과 지속성을 보장할 수 있도록 장애가 발생한 서버가 복구되어 정상화될 때 트랜잭션을 복구하는 단계를 특징으로 가지는 결과적 트랜잭션 방법에 관한 것이다.
본 발명의 결과적 트랜잭션은 분산시스템의 2단계 커밋(two phase commit) 방식으로 수행되며, 1단계에서 트랜잭션의 동시성을 검사하는 단계, 2단계에서 충돌 회피를 보장 받은 트랜잭션을 NoSQL 데이터베이스에 수행하는 단계를 가진다. 결과적 트랜잭션의 실패는 1단계의 동시성 충돌에서만 발생하고, 2단계에서 발생한 실패는 NoSQL 데이터베이스 복구 과정에서 실패한 트랜잭션을 복구함으로써 NoSQL 데이터베이스 장애와 상관없이 트랜잭션의 4가지 성질을 유지하도록 하는 특징을 가진다.

Description

ＮｏＳＱＬ 데이터베이스를 위한 결과적 트랜잭션 처리 방법 {Method of Eventual Transaction Processing On NoSQL Database}

본 발명은 NoSQL 데이터베이스의 트랜잭션을 구현하는 방법에 관한 것으로, 1단계에서 트랜잭션의 동시성 충돌 검사를 수행하여 트랜잭션의 일관성과 고립성을 보장하고, 2단계에서 NoSQL 데이터베이스 장애와 상관 없이 트랜잭션의 원자성과 지속성을 보장시키는 결과적 트랜잭션 방법에 관한 것이다.

[문헌 1] Nancy Lynch, Seth Gilbert. "Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services." ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51-59.

[문헌 2] W. Vogels. "Eventually Consistent." ACM Queue vol. 6, no. 6, December 2008.

NoSQL이 트랜잭션을 보장하지 않는 이론적 배경에는 에릭 브루어가 UC 버클리에 제임 중이던 2000년대에 분산 컴퓨팅 이론에 대한 ACM 심포지엄에서 발표한 CAP(Consistency, Availability, Partition Tolerance)이론에 설명되어 있다. CAP 정리에 따르면, 대규모 분산 데이터 시스템에는 슬라이딩 의존성(sliding dependency)과 관계를 맺는 세 가지 요건, 일관성, 가용성, 파티션 허용이 있으며, 분산 시스템은 셋 중에 두 가지만 강력하게 지원할 수 있다. 전통적인 관계형 데이터베이스는 브루어 CAP 정리에 의해, 일관성과 가용성을 중시한 시스템으로 대용량 데이터를 처리하기 위한 파티션 허용을 강력하게 지원할 수 없는 반면, NoSQL은 관계형 데이터베이스와는 달리 파티션 허용을 제공하는 가운데, 일관성을 강하게 지원하는 형태와 가용성을 강하게 지원하는 형태로 나누어진다.

따라서 NoSQL 기술은 데이터 무손실에 대한 보장을 해주지 못하기 때문에, 안전하기 보다는 로그와 같이 손실되어도 무방한 대용량 데이터를 저장하는 단순 저장소로만 간주되고 있다. 본 발명은 결과적 일관성(Eventual Consistency) 개념을 이용한 결과적 트랜잭션(Eventual Transaction)을 정의하고, 이를 활용하여 NoSQL 기술에 트랜잭션을 제공함으로써 데이터를 안전하게 저장하는 무손실 방법을 제공하는데 그 목적을 둔다.

이하에서는 본 발명의 구체적인 내용에 대한 기본적인 이해를 돕기 위하여 간단한 요약을 제공한다. 이 요약은 광범위한 개관이 아니며, 본 발명의 중요/핵심 구성 요소를 식별하거나 특허청구범위를 한정하고자 하는 것이 아니다. 이는 단지, 이하의 보다 상세한 설명에 대한 서설로서, 몇몇 개념들을 단순한 형태로 제공하기 위한 것이다.

본 발명은 대용량 데이터를 처리하기 위해 분산시스템으로 구성된 NoSQL(Not Only SQL) 데이터베이스에 대한 트랜잭션(transaction) 처리에 관한 것이다. 이러한 처리를 위해 본 발명은 결과적 트랜잭션(eventual transaction)을 정의하였다. 결과적 트랜잭션은 트랜잭션의 4가지 성질 ACID - 원자성(Atomic), 일관성(Consistent), 고립성(Isolated), 지속성(Durable)을 보장하기 위해, 트랜잭션 로그를 이용한 트랜잭션의 일관성과 고립성을 보장하는 동시성 충돌 검사를 수행하고, NoSQL 클러스터 노드에서 장애가 발생한 시점에 활성화되어 있던 트랜잭션의 원자성과 지속성을 보장할 수 있도록 장애가 발생한 서버가 복구되어 정상화될 때 트랜잭션을 복구하여 트랜잭션의 4가지 성질이 충족될 수 있도록 만든다. 즉, 결과적 트랜잭션은 트랜잭션으로 구성된 질의 집합을 NoSQL 클러스터 노드의 장애와 상관없이 트랜잭션 성질을 유지하도록 만든다.

본 발명의 결과적 트랜잭션은 분산시스템의 2단계 커밋(two phase commit) 방식으로 수행된다. 커밋 1단계는 트랜잭션의 동시성을 검사하는 단계로 동시에 발생하는 트랜잭션의 충돌로 인해 일관성과 고립성이 결여되는 것을 방지하고, 커밋 2단계에서 충돌 회피를 보장 받은 질의를 NoSQL 데이터베이스에 수행한다. 결과적 트랜잭션의 실패는 커밋 1단계에서의 실패에서만 발생한다. 커밋 2단계에서 발생한 실패는 NoSQL 데이터베이스 장애로 인해 트랜잭션이 결여된 부분이므로, NoSQL 데이터베이스 복구 과정에서 트랜잭션을 같이 복구한다.

이와 같이 본 발명이 트랜잭션의 실패를 커밋 1단계에서만 허용하는 것은, NoSQL 데이터베이스가 질의를 수행한 것을 롤백(rollback)하는 기능을 가지고 있지 않기 때문이다. 트랜잭션은 복수개의 질의들이 논리적인 한 개의 질의로 통합된 것으로 트랜잭션을 구성한 질의들이 트랜잭션 실패에 따른 롤백이 가능하여야 한다. 하지만, NoSQL 데이터베이스는 질의 하나에 대해 원자성을 보장해 주지만, 복수개의 질의에 대해서는 원자성을 보장해 주지 않는다. 따라서, 결과적 트랜잭션은 트랜잭션을 구성하는 복수개의 질의 중에 한 개라도 수행되었다면, 해당 트랜잭션은 원자성이 결여되지 않아야 하므로, NoSQL 클러스터 장애가 복구될 때 우선적으로 활성화된 트랜잭션을 먼저 재 수행함으로써 트랜잭션의 원자성을 보장한다.

본 발명은 결과적 트랜잭션을 위해, 결과적 트랜잭션을 발생시키는 결과적 트랜잭션 클라이언트와 결과적 트랜잭션 동시성을 제어하는 결과적 트랜잭션 서버로 구성된다. 결과적 트랜잭션 클라이언트는 트랜잭션을 생성하고 트랜잭션을 구성한 질의를 결과적 트랜잭션 서버에 트랜잭션 로그로 저장하고, 서버에 저장된 트랜잭션 로그를 기반으로 트랜잭션 동시성 충돌 검사를 위한 커밋 1단계를 요청한다.

커밋 1단계를 요청 받은 결과적 트랜잭션 서버는 클라이언트가 보내준 트랜잭션 로그를 분석하여 이전에 발생한 트랜잭션과의 충돌을 검사한다. 만약, 클라이언트가 보내준 트랜잭션이 이전에 발생한 트랜잭션과 데이터 일관성이 충돌한다면, 서버는 클라이언트에 커밋 1단계가 실패하였음을 통지한다. 커밋 1단계 실패를 통지 받은 클라이언트는 서버에 동일한 트랜잭션 다시 요청하여 충돌 검사를 수행하며, 재 요청은 환경 변수에 설정된 반복 횟수만큼 수행한다. 만약, 반복 횟수만큼 수행한 결과가 충돌을 회피할 수 없으면 결과적 트랜잭션을 실패로 인식하여, 클라이언트는 서버에 트랜잭션 실패를 전송한다. 트랜잭션 실패를 전달 받은 서버는 해당 트랜잭션을 구성하고 있는 트랜잭션 로그를 서버에서 제거한다. 트랜잭션 서버에 저장된 트랜잭션 로그의 제거는 물리적 저장장치에 기록된 데이터를 완전히 제거하는 방법과 삭제 플래그를 이용한 삭제 처리를 수행할 수 있다. 삭제 플래그를 이용하여 삭제 처리를 수행하는 방법은 백그라운드(background)로 수행되는 스케줄러(scheduler)에 의해 데이터 완전 삭제를 처리한다.

결과적 트랜잭션의 충돌 검사는 데이터 저장을 선점한 트랜잭션이 완료될 때까지 대기하는 락(lock)을 이용한 전통적인 트랜잭션 동시성 제어 방식과는 다른 특징을 가진다. 분산시스템에서의 락은 대용량 데이터의 삽입이 많을 경우에 대기 상태를 계속 유지시켜 시스템 전체가 대기 상태에 빠질 수 있도록 만들 수 있으며, 또한 데드락(deadlock) 발생 가능성도 높아지는 원인이 된다. 따라서, 결과적 트랜잭션은 데이터 저장 충돌 회피를 위해 트랜잭션 충돌 검사를 클라이언트의 반복 요청으로 처리한다. 결과적 트랜잭션 클라이언트와 서버는 네트워크로 연결되어 있고, 네트워크를 통한 요청은 일정 지연 시간을 유지하기 때문에, 시스템 전체가 락에 의해 대기상태로 빠지는 데드락 현상을 줄일 수 있다. 또한 결과적 트랜잭션 클라이언트에서 발생한 대용량 트랜잭션 처리는 결과적 트랜잭션 서버의 수평적 확장(scale-out)으로 해결할 수 있다.

커밋 1단계를 성공한 결과적 트랜잭션 클라이언트는 커밋 2단계를 위해 NoSQL 데이터베이스에 질의를 수행한다. 커밋 2단계 과정은 NoSQL 데이터베이스 특성에 따라 차이가 접근 방법에 차이가 있다. NoSQL 데이터베이스는 대용량 데이터를 고속으로 처리하기 위해 메모리 캐시에 데이터를 저장하고 백그라운드로 수행되는 디스크 저장 컴포넌트를 통해 메모리 캐시에 저장된 데이터를 하드 디스크에 저장한다. 만약, 메모리 캐시에 있는 데이터가 안전한 하드 디스크에 저장되기 전에 시스템 장애로 전원이 커져 버리면, 메모리에 있는 데이터는 없어지는 현상이 발생된다.

이와 같이 NoSQL 데이터베이스는 대용량 데이터를 빠르게 처리하기 위해 트랜잭션이 없는 캐시 정책을 사용하기 때문에, 캐시 손실에 따른 데이터 정합성이 결여될 수 있는 문제점을 가지고 있다. 이를 위해 NoSQL 데이터베이스는 복제 정책을 통해 데이터 안정성을 제공한다. 하지만 복제 역시 복제를 수행하는 짧은 시간이 소요되며, 이러한 짧은 시간 동안 시스템 부하에 의한 전체 시스템 장애가 발생하게 되면 데이터 손실이 일어난다.

결과적 트랜잭션은 커밋 2단계를 처리하기 위해 장애 유형을 시스템이 자동으로 복구가 가능한 일반 장애와 자동 복구가 불가능하여 사람이 수작업으로 복구를 수행하여야 하는 심각 장애로 구분한다. 일반 장애는 복제로 구성된 분산 클러스터 시스템에서 임의의 한 노드가 장애가 발생하더라도 나머지 노드들이 장애가 발생한 노드의 기능을 수행할 수 있는 상태를 의미하고, 심각 장애는 분산 클러스터 시스템의 임의의 노드가 장애가 발생하여, 전체 시스템이 정상적으로 동작할 수 없는 장애를 의미한다. 예를 들어, 마스터(master)/슬레이브(slave) 방식의 분산 시스템은 마스터 장애가 발생하면 슬레이브들이 투표를 통해 마스터를 선출하고, 선출된 새로운 마스터를 통해 서비스를 계속 진행한다.

결과적 트랜잭션 클라이언트는 커밋 2단계에서 일반 장애인 경우는 장애가 복구될 때까지 대기하고 트랜잭션을 재 수행함으로써 트랜잭션을 보장하고, 심각 장애의 경우는 결론적 트랜잭션 서버에 트랜잭션 실패를 통보한다. 클라이언트는 심각 장애가 발생한 상태에서는 이 후에 발생되는 트랜잭션에 대해 실패로 처리한다. 클라이언트는 백그라운드로 수행되는 NoSQL 헬스 검사기를 통해 NoSQL 데이터베이스의 심각 장애가 복구되었는지 판단하여, 심각 장애가 복구되었을 경우 서버에 트랜잭션 실패로 설정된 트랜잭션들의 복구를 수행한다. 실패된 트랜잭션의 모든 복구가 완료된 상태에서 클라이언트는 다시 트랜잭션을 받아 들여 결과적 트랜잭션 처리를 수행한다. 즉, 커밋 2단계를 수행한 트랜잭션은 장애에 의해 트랜잭션이 결여되어도, 복구를 통해 트랜잭션의 4가지 성질이 보장된다.

전술한 바 및 그와 관련된 목적들을 달성하기 위하여, 이하의 설명 및 첨부된 도면과 관련하여 특정한 예시적인 양태들이 설명된다. 하지만, 이러한 양태들은 본 발명의 원리가 사용될 수 있는 다양한 방법 중에 오직 일부만을 설명하는 것일 뿐이며, 본 발명에서는 이러한 모든 양태 및 그 균등물들을 포함하고자 한다. 그 밖의 유리하고 새로운 특징들은, 첨부된 도면과 함께 이하의 상세한 설명을 참조하면 명백해질 것이다.

이상에서 설명한 바와 같이, 트랜잭션을 제공하지 않는 NoSQL 데이터베이스에 결과적 트랜잭션을 제공함으로써, NoSQL 기술을 단순히 손실되어도 무방한 대용량 데이터를 저장하는 저장소뿐만 아니라, 안전한 데이터를 저장 관리할 수 있는 데이터베이스로 사용될 수 있다.

제1도는 결과적 트랜잭션 시스템 구성도
제2도는 결과적 트랜잭션 클라이언트 시스템 구성도
제3도는 결과적 트랜잭션 클라이언트의 트랜잭션 생성기 장치의 구성도
제4도는 결과적 트랜잭션 클라이언트의 장애 상태 이전도
제5도는 결과적 트랜잭션 로그 구성도
제6도는 결과적 트랜잭션 서버 시스템 구성도
제7도는 결과적 트랜잭션 처리를 위한 클라이언트 전체 처리 흐름도
제8도는 결과적 트랜잭션 2단계 커밋 처리 흐름도
제9도는 결과적 트랜잭션 커밋 2단계의 수행 단계 처리 흐름도
제10도는 결과적 트랜잭션 동시성 충돌 검사를 위한 서버 전체 처리 흐름도
제11도는 읽기 연산에 대한 결과적 트랜잭션 동시성 충돌 검사 처리 흐름도
제12도는 쓰기 연산에 대한 결과적 트랜잭션 동시성 충돌 검사 처리 흐름도

이제 도면을 참조하여 본 발명을 설명하고자 한다. 도면에서 동일한 참조 번호는 동일한 구성요소를 나타낸다. 이하의 설명에서는 설명을 목적으로, 본 발명에 대한 보다 충분한 이해를 돕기 위하여 여러 가지 구체적인 세부 사항을 설명하였다. 하지만, 이러한 구체적인 세부 사항 없이도 실시될 수 있다는 점이 명백할 것이다. 한편 본 발명에 대한 설명을 보다 용이하게 하기 위하여, 잘 알려진 구조 및 장치들은 블록도의 형태로 도시하였다. 본 출원에 있어서, 개시된 발명을 구현하기 위하여, 본 발명은 컴퓨터를 제어하기 위한 소프트웨어, 펌웨어, 하드웨어, 또는 이들의 임의의 조합을 생성하기 위하여 표준 프로그래밍 및/또는 엔지니어링 기법을 사용하여 메소드(method), 장치, 또는 제품으로 구현될 수 있다.

이제 도 1을 참조하면, 도 1은 NoSQL 데이터베이스의 트랜잭션을 처리를 수행하는 시스템(100)을 도시한다. 결과적 트랜잭션을 생성하는 결과적 트랜잭션 클라이언트(106)는 결과적 트랜잭션의 동시성 충돌 검사와 장애 복구에 따른 트랜잭션 복구를 위한 결과적 트랜잭션 서버(102)와 NoSQL 데이터베이스(104)에 연결된다. 클라이언트(106)는 복수 개의 응용에 설치되며(106-110) 복수 개의 결과적 트랜잭션 클라이언트들로부터 대용량의 트랜잭션이 발생되어 서버(102)에 부하가 증가할 경우, 서버(102)는 클러스터로 구성시켜 트랜잭션을 부하 분산시킬 수 있다.

이제 도 2를 참조하면, 도 2는 결과적 트랜잭션을 생성하여 NoSQL 데이터베이스(104)에 데이터를 저장하기 위한 클라이언트 시스템(200)을 도시한다. 시스템(200)은 결과적 트랜잭션을 생성하여 질의를 처리하는 트랜잭션 생성기(202), NoSQL 데이터베이스(104)의 장애 여부를 검사하는 NoSQL 헬스 검사기(204), 그리고 트랜잭션 로그를 저장소에 저장하는 트랜잭션 로거(206)로 구성된다.

NoSQL 헬스 검사기(204)는 주기적으로 NoSQL 데이터베이스(104)의 장애 상황을 체크하여, 그 결과를 헬스 플래그(210)에 저장한다. 트랜잭션 생성기(202)는 헬스 플래그(210)의 값을 이용하여, NoSQL 데이터베이스(104)의 상태에 따른 트랜잭션 수행 여부를 판단하고, 또한 복구가 완료된 NoSQL 데이터베이스(104)에 대해서는 트랜잭션 복구를 결과적 트랜잭션 서버(102)에 요청한다.

트랜잭션 로거(206)은 트랜잭션 생성기(202)에서 생성한 트랜잭션에 대한 로그 데이터를 저장하는 컴포넌트로 서버(102)의 장애가 발생하여 자동으로 트랜잭션을 복구할 수 없을 경우에, 수동으로 트랜잭션을 복원할 수 있는 트랜잭션 로그 데이터를 저장한다. 트랜잭션 로거(206)는 트랜잭션 생성기(202)에서 전달 받은 로그 데이터를 로컬 저장소(206)에 일정한 규칙에 의해 파일로 저장하며, 주기는 시간 주기 별로 각기 다른 파일로 저장하도록 구성할 수 있다. 또한, 트랜잭션 로그 데이터는 로컬 저장소(208) 이외에 네트워크 디스크 또는 원격 저장소에 동일한 로그 데이터를 따로 저장할 수 있다.

이제 도 3을 참조하면, 클라이언트(106)에서 결과적 트랜잭션을 생성하고 2단계 커밋을 수행하는 트랜잭션 생성기(202)의 시스템(300)을 도시한다. 시스템(300)은 네트워크를 통해 결과적 트랜잭션 서버(102)와 통신을 수행하는 결과적 트랜잭션 서버 연동 컴포넌트(312), NoSQL 데이터베이스(104)와 통신을 수행하는 NoSQL 데이터배이스 연동 컴포넌트(314), 트랜잭션 생성 시 발생되는 트랜잭션 ID를 UUID로 형태로 생성하는 트랜잭션 ID 생성 컴포넌트(302), 트랜잭션 질의를 트랜잭션 로그로 변환하는 트랜잭션 로그 변환 컴포넌트(304), 결과적 트랜잭션의 2단계 커밋을 수행하는 결과적 트랜잭션 처리기(306), NoSQL 데이터베이스의 일반 장애가 복구되었을 때 결과적 트랜잭션을 복구하는 트랜잭션 복구 컴포넌트(308), 그리고 NoSQL 장애를 일반 장애와 심각 장애로 판단하는 NoSQL 장애 처리 컴포넌트(310)로 구성된다.

시스템(300)의 트랜잭션 로그 변환 컴포넌트(304)는 트랜잭션을 구성하는 질의를 텍스트 로그 데이터로 변환하여 결과적 트랜잭션 처리기(306)를 통해 서버(102)에 전송하고, 또한 트랜잭션 로거(206)에 전달하여 로그를 저장한다. 트랜잭션 로그는 트랜잭션 생성된 시간과 트랜잭션 ID를 포함한 질의 데이터로 구성된다.

결과적 트랜잭션 처리기(306)는 전술한 바와 같이 2단계 커밋으로 구성된 결과적 트랜잭션을 처리한다. 결과적 트랜잭션 처리기(306)는 결과적 트랜잭션의 동시성 충돌 검사를 위한 커밋 1단계를 결과적 트랜잭션 서버 연동 컴포넌트(312)를 통해 서버(102)에 요청하고, 요청한 결과가 성공일 경우 NoSQL 데이터베이스 연동 컴포넌트(314)를 통해 커밋 2단계를 수행한다. 결과적 트랜잭션은 커밋 1단계를 완료한 커밋 2단계 과정에 있는 모든 트랜잭션에 대해서 트랜잭션을 보장하여야 한다. 이러한 처리를 위해 본 발명은 NoSQL 데이터베이스(104)의 장애를 자동 복구가 가능한 일반 장애와 자동 복구가 불가능한 심각 장애로 구분한다. 일반 장애는 NoSQL 데이터베이스(104)가 스스로 복구 될 수 있는 상태로, 일정 시간이 지난 후에 장애가 복구 된 후, 트랜잭션 처리를 재 시도 할 수 있음을 의미한다. 따라서, 일반 장애에 대한 트랜잭션은 클라이언트(106)가 보장한다. 심각 장애는 NoSQL 데이터베이스(104)가 자동 복구 할 수 없는 상태를 의미하며, 클라이언트(106)가 트랜잭션 복구를 수행하지 않고 NoSQL 데이터베이스(104)가 복구 된 후, 서버(102)를 통해 트랜잭션 복구를 수행한다.

시스템(300)의 트랜잭션 복구 컴포넌트(308)는 전술한 바와 같이 NoSQL 데이터베이스(104)의 일반 장애에 대한 실패한 트랜잭션을 복구한다. 트랜잭션의 복구는 트랜잭션을 구성하고 있는 질의가 정상적으로 수행되었는지 NoSQL 데이터베이스(104)를 검사하여, 레코드가 삽입, 수정, 삭제되지 않은 질의를 재 수행하여 트랜잭션을 완료시킨다. 만약, 트랜잭션 복구 컴포넌트(308)가 복구를 수행하는 도중에 NoSQL 데이터베이스(104)가 복구되지 않았거나 또는 다시 장애가 발생하였다면, 시스템(300)은 설정된 재 시도 회수만큼 복구를 진행시킨 다음, 장애 유형을 심각 장애로 전이시킨다.

시스템(300)이 NoSQL 데이터베이스(104)의 장애를 일반 장애와 심각 장애로 구분하기 위해, 헬스 플래그(210)에 표 1과 같이 장애 플래그와 하트비트 플래그를 사용한다. 장애 플래그는 NoSQL 데이터베이스(104)에 질의를 수행할 때 발생되는 장애를 판단하여 저장하는 것으로, NoSQL 장애 처리 컴포넌트(310)가 시스템(300)에 설정한 재시도 회수를 초과하여 NoSQL 데이터베이스(104)의 장애가 지속되었을 경우 장애 플래그를 On으로 설정한다. 하트비트 플래그는 NoSQL 장애 처리 컴포넌트(310)가 일반 장애를 판단하여 플래그를 On으로 설정하고, NoSQL 헬스 검사기(204)가 주기적으로 NoSQL 데이터베이스(104)의 장애 상황을 점검하여 장애가 복구가 되면, Off로 설정한다.

장애 플래그	하트비트 플래그	의미
Off	Off	정상적인 상태로, 장애도 없으며 NoSQL 데이터베이스(104)도 정상 동작함
Off	On	NoSQL 데이터베이스(104)에서 장애가 발생한 것으로, 이전에 발생한 장애가 없는 상태. 이러한 상태는 장애 플래그를 On으로 변경하고, NoSQL 데이터베이스(104)가 정상화 될 때까지 질의를 재 시도 한다.
On	Off	NoSQL 데이터베이스(104)가 이전에 발생한 장애가 있으며, 복구를 필요한 상태를 의미하며, NoSQL 데이터베이스(104) 자체는 복구가 완료되어 정상 동작하고 있음. 이러한 상태에서는 트랜잭션 복구 명령을 결과적 트랜잭션 서버(102)에 요청한다.
On	On	NoSQL 테이터베이스(104)가 이전 또는 현재 장애가 발생하여 복구가 필요한 상태이며, 트랜잭션 처리는 실패되어 결과적 트랜잭션 서버(102)에 트랜잭션 실패 명령을 전달한다.

이제 도 4를 참조하면, 표 1의 두 개의 플래그를 가지고 있는 헬스 플래그(210)의 4가지 상태에 대한 상태이전도(400)를 도시한다. 상태 이전도(400)의 두 개의 플래그 값의 첫 번째는 장애 플래그 값을 의미하고 두 번째 플래그 값은 하트비트 플래그의 값을 의미하는 것으로, 4가지 상태는 안정상태(Off/Off), 일반장애(Off/On), 심각장애(On/On), 그리고 복구가능상태(On/Off)로 구분한다. 상태이전도(400)의 초기 상태는 안정상태(402)이다. 클라이언트(106)는 NoSQL 데이터베이스(104)에 트랜잭션 질의를 수행하는 도중에 에러가 발생하였다면, 상태를 일반장애(404)로 전이시킨다. 일반장애(404)로 전이가 되면 클라이언트(106)은 NoSQL 헬스 검사기(204)를 이용하여 NoSQL 데이터베이스의 장애가 복구되었는지 주기적으로 검사한다. 만약 복구가 완료되었다면 상태를 안정상태(402)로 전이시키고, NoSQL 데이터베이스(104)가 재 시도 회수 동안 복구되지 않았다면, 심각장애(406)으로 전이시킨다.

일반장애(404)에서 심각장애(406)로 상태이전을 수행하는 시간은 NoSQL 데이터베이스(104)가 스스로 자동 복구를 수행하는 최대 시간으로 설정되며, 심각장애(406)로 전이된 순간의 트랜잭션은 실패로 처리되어 서버(102)에 실패된 트랜잭션 정보를 전송한다. 그리고, 클라이언트(106)는 심각장애(406) 상태 이후 발생되는 모든 트랜잭션에 대해서는 결과적 트랜잭션 생성을 수행하지 않고, 심각장애(406) 상태와 함께 에러코드를 예외 처리한다.

NoSQL 헬스 검사기(204)는 장애상태가 일반장애(404)로 전이된 시점부터 시작하여 NoSQL 데이터베이스(104)가 복구될 때까지 주기적으로 복구 상황을 체크한다. 만약, NoSQL 데이터베이스(104)가 복구되었다면, 장애상태가 일반장애(404)인 경우에는 안정상태(402)로, 심각장애(406)에서는 복구가능(408) 상태로 전이시키고 NoSQL 데이터베이스(104)의 장애 상황을 체크하는 것을 종료한다.

클라이언트(106)는 장애상태가 복구가능(408) 상태 이후 발생되는 첫 번째 트랜잭션에서 트랜잭션을 생성하기 전에 서버(102)에 트랜잭션 복구 명령을 요청하고 그 결과를 기다린다. 만약 서버(102)에 요청한 결과가 성공이라면 장애상태를 안정상태(402)로 전이하고 트랜잭션을 처리한다. 만약 서버(102)에 요청한 결과가 실패한 경우는 트랜잭션 생성을 수행하지 않고, 복구가능(408) 상태와 함께 에러코드를 예외 처리한다.

이제 도 5를 참조하면, 트랜잭션 로그 변환 컴포넌트(304)가 생성하는 트랜잭션 로그(500)를 도시한다. 트랜잭션 로그(500)는 6개의 블록으로 구성된 한 개의 행(row) 데이터로 구성된다. 타임 스탬프(502)는 트랜잭션이 생성된 시간을 나타내는 것으로, 트랜잭션을 구성하는 모든 질의는 같은 시간을 가진다. 트랜잭션 ID(504)는 트랜잭션 ID 생성 컴포넌트(302)가 생성한 UUID를 저장하는 영역으로 트랜잭션을 구성하는 모든 질의는 동일한 트랜잭션 ID를 가진다. 명령어 종류(506)는 트랜잭션을 구성하는 질의의 종류를 나타내는 것으로 표 2와 같은 값을 가진다. 트랜잭션 로그(500)는 표 2의 질의 유형 ETTYPE_START로 시작하여 ETTYPE_END로 끝나며, 트랜잭션을 구성하는 질의는 질의 유형 ETTYPE_START와 ETTYPE_END 로그 안에 명시된다. 데이터베이스 질의 명령은 쓰기 연산 3개(삽입, 삭제, 수정)와 1개의 읽기 연산으로 총 4개의 연산으로, 각각 표 2의 질의 유형 ETTYPE_OP_INSERT, ETTYPE_OP_DELETE, ETTYPE_OP_UPDATE, 그리고 ETTYPE_OP_READ로 정의된다.

질의 유형	의미
ETTYPE_START	트랜잭션의 시작을 나타내며, 테이블 명(510), 명령어 해쉬 코드(512)와 명령 쿼리 데이터(514)는 생략된다
ETTYPE_END	트랜잭션의 종료를 나타내며, 테이블 명(510), 명령어 해쉬 코드(510)와 명령 쿼리 데이터(512)는 생략된다.
ETTYPE_OP_INSERT	트랜잭션 연산 중 삽입 연산을 의미한다.
ETTYPE_OP_DELETE	트랜잭션 연산 중 삭제 연산을 의미한다.
ETTYPE_OP_UPDATE	트랜잭션 연산 중 수정 연산을 의미한다.
ETTYPE_OP_READ	트랜잭션 연산 중 읽기 연산을 의미한다.

명령어 일렬 번호(508)은 임의의 정수로 시작되는 일렬 번호이다. 예를 들어 일렬번호를 1부터 시작하였다면 총 3개의 질의로 구성된 트랜잭션은 질의 유형 ETTYPE_START와 ETTYPE_END를 첨가하여 5개의 트랜잭션 로그로 구성되므로 마지막 일렬번호는 5가 된다. 테이블 명(510)은 명령어 종류(506)가 ETTYPE_START와 ETTYPE_END인 경우에는 생략되고, 쓰기와 읽기 연산을 나타내는 질의 로그에 데이터에 접근하는 테이블 명을 명시한다. 테이블 명(510)은 접근하는 NoSQL 데이터베이스(104)에 유일하여야 한다. 만약 테이블 명이 중복되어 나타날 수 있는 NoSQL 구조에서는 유일하게 명시할 수 있는 방법으로 정의한다. 예를 들어, 데이터베이스 명과 테이블 명을 혼합한 구조로 만들 수 있다.

명령 해쉬 코드(512)는 테이블 명(510)의 명령어 종류(506)가 ETTYPE_START와 ETTYPE_END인 경우에 생략되고, 쓰기와 읽기 연산을 나타내는 질의 로그에 데이터에 접근하는 테이블 행의 유일한 해시 코드(hash code)를 생성하여 저장한다. 테이블 명(510) 이외에 명령 해시 코드(512)를 추가로 명시함으로써 트랜잭션 동시성 충돌 검사의 충돌 범위를 테이블이 아닌 트랜잭션이 직접 관련된 레코드 또는 행 단위로 충돌 범위를 축소시킬 수 있다. 질의 중에서 수정 연산이 한 개의 레코드 만을 수정하는 것이 아니라 복수 개의 레코드를 동시에 수정하는 연산인 경우, 질의 문으로 모든 레코드를 취득하여 트랜잭션 로그를 생성하는 것은 시스템 부하를 가중시킬 수 있다. 이와 같은 경우는 명령 해시 코드(512)를 명시하지 않고, 테이블 명(510) 전체에 대한 충돌 범위를 설정할 수 있다. 명령 쿼리 데이터(514)는 명령어 종류(506)가 ETTYPE_START와 ETTYPE_END인 경우에 생략되고, 트랜잭션 쓰기와 읽기 연산의 질의 문을 텍스트 형태로 저장한다.

이제 도 6을 참조하면, 클라이언트(106)가 보내준 트랜잭션의 동시성 충돌 검사를 수행하는 결과적 트랜잭션 서버(102)에 대한 시스템(600)이 도시되었다. 시스템(600)은 결과적 트랜잭션 클라이언트 연동 컴포넌트(612)를 통해 클라이언트(106)와의 메시지 통신을 수행한다. 클라이언트(106)는 수집된 트랜잭션 로그를 서버(102)에 저장하기 위한 메시지, 서버(102)에 저장된 트랜잭션을 구성하는 질의가 다른 트랜잭션과의 동시성 충돌이 있는지 검사하기 위한 동시성 충돌 검사 요구 메시지, 트랜잭션 상태 변경 메시지, 트랜잭션 복구 요청 메시지를 발신하고, 서버(102)는 수신된 메시지를 해당 컴포넌트에 연결하고, 결과를 클라이언트(106)에 전달한다.

시스템(600)은 클라이언트(106)가 보내준 트랜잭션 로그를 트랜잭션 로그 저장소(610)에 저장한다. 트랜잭션 로그 저장소(610)는 유한개의 트랜잭션을 저장하는 저장소로, NoSQL의 일반 장애가 발생하는 지연 시간 정도로 처리할 수 있는 최대 트랜잭션 개수보다 큰 저장소로 할당된다. 예를 들어, 클라이언트(106)가 NoSQL 데이터베이스(104)의 일반 장애를 판단하는 지연시간이 300ms라고 하고, 클라이언트(106)에서 발생한 최소 크기의 결과적 트랜잭션이 평균 1,000TPS(Transaction Per Seconds)라고 가정하자. 그러면, 1개의 트랜잭션이 처리되는 시간은 1ms이므로, 클라이언트(106)에서 트랜잭션을 실패를 감지할 수 없는 시간 300ms 동안 처리될 수 있는 최대 트랜잭션 개수는 300개가 된다. 따라서, 서버(102)의 트랜잭션 로그 저장소(610)은 최대 300개 이상의 트랜잭션을 저장할 수 있는 저장 공간을 가져야 한다. 전술한 예와 같이 서버(102)는 서버 환경 파일을 통해 트랜잭션 로그 저장소(610)의 크기를 조정할 수 있으며, 그 크기는 NoSQL 데이터베이스(104)의 일반 장애에 의한 최대 판단 지연 시간과 최소 트랜잭션이 처리되는 시간의 곱보다 큰 값을 가진다.

서버(102)의 트랜잭션 동시성 제어 컴포넌트(606)는 전술한 바와 같이, 트랜잭션의 동시성 충돌 여부를 결정하는 결과적 트랜잭션 커밋 1단계를 수행한다. 트랜잭션 생성 시간을 포함한 트랜잭션 로그를 이용하여 트랜잭션이 동시에 동일한 데이터 영역(테이블)을 접근할 때, 먼저 테이블에 접근을 시도한 트랜잭션에 우선권을 부여하고, 나중에 발생한 트랜잭션에 대해서는 실패로 처리한다.

결과적 트랜잭션의 커밋 2단계를 수행하던 클라이언트(106)에서 NoSQL 데이터베이스(104)의 심각 장애로 인해 트랜잭션을 완료하지 못한 경우, 클라이언트(106)는 완료하지 못한 트랜잭션을 실패로 간주하고 이에 대해 정보를 서버(102)에 통보한다. 서버(102)는 클라이언트(106)로부터 전송 받은 실패한 트랜잭션 정보를 트랜잭션 로그 저장소(610)에 저장한다. 만약, NoSQL 데이터베이스(104)가 복구되었다면, 클라이언트(106)는 서버(102)에 실패한 결과적 트랜잭션에 대한 복구를 요청한다. 복구 메시지를 전달 받은 서버(102)는 트랜잭션 복구 컴포넌트(608)에 복구 명령을 요청하고, 트랜잭션 복구 컴포넌트(608)는 트랜잭션 로그 저장소(610)에 실패한 결과적 트랜잭션이 있는지 검사하여 실패한 트랜잭션이 있을 경우는, 복구를 수행하기 위한 커밋 2단계를 NoSQL 데이터베이스 연동 컴포넌트(614)를 통해 NoSQL 데이터베이스(104)에 질의를 수행한다.

복수의 클라이언트(106)를 사용하는 시스템에서, NoSQL 데이터베이스(102) 복구에 따른 트랜잭션 복구 요청을 클라이언트(106)가 동시에 서버(102)에 요청할 수 있다. 이러한 경우 서버(102)는 먼저 발생된 요청에 대해 트랜잭션 복구 명령을 수행하고, 트랜잭션 복구 수행 중에 요청된 클라이언트(106)의 복구 요청은 트랜잭션 복구 상태 중임을 알려주는 상태 코드로 클라이언트(106)에 응답해 준다. 클라이언트(106)는 서버(102)가 트랜잭션 복구 중일 경우는, 일정 시간 간격을 두고 트랜잭션 복구 요청을 다시 수행한다. 서버(102)는 클라이언트(106)의 NoSQL 데이터베이스(104)의 상태를 체크하는 컴포넌트를 가지고 있지 않기 때문에, 클라이언트(106)가 동시에 요청한 트랜잭션 복구 메시지에 대해, 이미 복구가 완료된 상태라는 상태 코드를 알려줄 수 없다. 따라서, 서버(102)는 클라이언트(106)가 요청한 트랜잭션 복구 요청에 대한 결과로 3가지 유형(복구할 대상이 없음, 복구 중, 복구 완료)으로 응답한다. 이러한 처리를 위해 본 발명은 클라이언트(106)는 수평적 확장이 가능한 서로 데이터를 공유하지 않는 무공유 데이터 저장 구조의 특징을 가진다.

서버(102)의 결과적 트랜잭션 서버 로그 저장소(604)는 트랜잭션 동시성 제어 컴포넌트(606)와 트랜잭션 복구 컴포넌트(608)가 수행한 명령에 대한 로그를 저장한다. 로그 저장소(604)에 저장된 로그는 결과적 트랜잭션 관리 웹 서버(602)를 통해 서버(102)가 처리한 트랜잭션에 대한 통계 정보를 제공한다. 서버(102)의 실시간 통계 정보를 제공하기 위해, 결과적 트랜잭션 서버 로그 저장소(604)는 로컬 저장소가 아닌 데이터베이스로 구축될 수 있으며, 서버(102)와 동일한 노드 또는 다른 노드에 설치된 저장소를 사용할 수 있다. 또한 결과적 트랜잭션 관리 웹 서버(602) 역시, 서버(102)의 부하 상태에 따라 서버(102)와 다른 노드에 구축될 수 있다.

이제 도 7 내지 도 12를 참조하면, 본 발명과 관련된 방법들이 일련의 행위로서 설명된다. 몇몇 행위들은 본 명세서에 도시되고 설명된 순서와 다른 순서로 일어날 수 있고 및/또는 다른 행위와 동시에 일어날 수도 있는바, 본 발명은 행위의 순서에 의하여 한정되지 않는다는 점을 이해할 것이다. 예를 들어, 당업자라면, 상태도와 같이 상호 관련된 일련의 상태 또는 이벤트로 방법이 표현될 수 있다는 것을 이해할 것이다. 또한 도시된 행위 모두가 본 발명에 따른 방법을 구현하는데 필요한 것은 아닐 수 있다. 또한, 본 명세서를 통해 개시된 방법들은, 이러한 방법들을 운반 및 전송 가능하게 하는 제품에 저장될 수 있다는 것을 이해할 것이다. 본 명세서에서 제품이란. 임의의 컴퓨터 판독기능 장치, 반송파, 또는 매체로부터 액세스 가능한 컴퓨터 프로그램을 포함하는 것이다.

도 7을 참조하면, 클라이언트(106)가 결과적 트랜잭션을 수행하기 전에 NoSQL 데이터베이스(104)의 장애 상태를 체크하는 방법(700)이 도시된다. 방법(700)은 단계(702)에서 시작되고, 단계(704)에서 NoSQL 헬스 플래그를 검사한다. 단계(704)에서 읽어 들인 헬스 플래그의 장애 상태가 심각장애(406) 상태인지 체크한다. 만약 심각장애(406) 상태라면 방법(700)은 단계(724)로 진행하여, 결과적 트랜잭션을 실패로 처리하고 단계(726)에서 완료된다. 단계(704)에서 심각장애(406) 상태가 아니라면 방법(700)은 단계(708)로 진행하여, 장애상태가 복구가능(408) 상태인지 체크한다. 방법(700)은 단계(708)에서 장애 상태가 복구가능(408) 상태라면 단계(710)로 진행하고, 복구가능(408) 상태가 아니라면 단계(716) 상태로 진행한다. 방법(700)은 단계(710)에서 서버(102)에 복구를 요청한다. 서버(102)는 클라이언트(106)으로부터 요청 받은 복구 명령을 수행한 결과를 클라이언트에 전송한다.

방법(700)은 단계(712)에서 서버(102)로부터 전달받은 복구 결과가 '복구 완료' 또는 '복구할 대상 없음'일 경우에 복구 성공으로 처리하여 단계(714)로 진행하고, 복구 결과가 '복구 중'일 경우는 일정시간 동안 대기하고, 클라이언트(106)에 설정된 반복 회수만큼 반복하여 서버(102)에 복구를 요청한다. 만약, 반복 회수만큼 서버(102)에 요청한 복구 결과가 계속 '복구 중'일 경우, 방법(700)은 단계(724)로 진행하여 결과적 트랜잭션을 실패로 처리하고, 단계(726)에서 완료된다.

방법(700)은 단계(714)에서 결과적 트랜잭션을 생성하고, 단계(716)에서 생성된 결과적 트랜잭션을 위한 2단계 커밋 과정을 수행하며, 처리 과정은 이하에 설명한다. 단계(716)에서 수행한 결과는 단계(718)에서 트랜잭션 처리 성공여부를 판단한다. 단계(718)에서 트랜잭션 처리가 성공하면, 단계(720)으로 진행하여 결과적 트랜잭션을 성공 처리하고, 방법(700)은 단계(726)에서 종료한다. 방법(700)은 단계(718)에서 트랜잭션 처리가 실패할 경우는 단계(722)로 진행하여 실패한 결과적 트랜잭션 정보를 서버에 전송하여, NoSQL 데이터베이스(104)가 복구되어 실패한 트랜잭션을 복구처리 할 수 있도록 하고, 단계(724)로 진행하여 결과적 트랜잭션을 실패로 처리하고, 단계(726)에서 완료된다.

이제 도 8을 참조하면, 결과적 트랜잭션의 2단계 커밋 과정을 처리하는 방법(800)이 도시된다. 방법(800)은 단계(802)에서 시작되고, 단계(804)에서 결과적 트랜잭션을 구성하는 질의를 트랜잭션 로그로 변환하고, 변환된 트랜잭션 로그를 서버에 저장한다. 단계(806)에서 클라이언트(106)는 서버에 저장된 트랜잭션 로그를 이용하여 다른 트랜잭션과의 동시성 충돌이 있는지 서버(102)에 동시성 충돌 검사를 요청한다. 단계(808)에서 클라이언트(106)가 요청한 동시성 충돌 검사 결과를 판단하여 충돌이 발생하였다면 단계(810)으로 진행하고, 충돌이 발생하지 않았다면 단계(812)로 진행한다.

단계(810)은 클라이언트(106)가 동시성이 충돌될 경우, 시스템에 설정된 재 시도 횟수만큼 동시성 충돌 요청을 수행하기 위해 단계(808)로 진행한다. 하지만, 재 시도 회수를 초과하여 동시성 충돌 요청을 할 수 없을 경우는, 선점한 트랜잭션이 대용량 작업을 수행하고 있거나 또는 NoSQL 데이터베이스(104)의 심각 장애로 트랜잭션이 완료되지 않은 상태를 의미하는 것으로, 단계(826)에서 결과적 트랜잭션의 실패를 수행하고, 방법(800은 단계(834)에서 완료된다.

전술한 바와 같이 결과적 트랜잭션은 커밋 1단계가 정상적으로 수행되었다면, 커밋 2단계에서 장애로 인해 트랜잭션이 실패하더라도, 장애 복구와 함께 실패한 트랜잭션의 원자성과 지속성을 보장해 주어야 한다. 결과적 트랜재션의 커밋 2단계는 NoSQL 데이터베이스(104)의 장애를 일반 장애와 심각 장애로 구분하여 일반 장애인 경우는 클라이언트(106)가 장애가 복구됨과 동시에 트랜잭션을 완료하고, 심각 장애인 경우는 서버(102)에 실패한 트랜잭션을 통보해 주어야 한다. 이러한 처리를 위해 결과적 트랜잭션의 커밋 2단계는 장애 상황을 체크하기 위한 단계를 초기 단계, 수행 단계, 완료 단계로 구분된 3군데 지점에서 수행한다.

초기 단계는 트랜잭션의 질의를 수행하기 전 장애를 판단하여 NoSQL 데이터베이스(104)의 장애가 판단되면 장애 상태를 일반 장애로 처리하고, 장애가 복구될 때까지 클라이언트(106)가 설정한 시간만큼 대기한다. 장애가 복구되면 일반 장애 상태를 안정 상태로 설정하고, 수행 단계를 진행된다. 만약, 장애가 복구되지 않았다면 일반 장애를 심각 장애로 설정하고, 트랜잭션 실패를 서버에 전송한다.

수행 단계는 초기 단계에서 장애가 발생하지 않은 안정 상태에서 수행되며, 질의를 수행한 시간을 누적시켜 주기적으로 NoSQL 데이터베이스(104)의 장애 상황을 검사한다. 완료 단계는 트랜잭션의 질의를 수행하고 난 다음에 NoSQL 데이터베이스(104)의 장애 상황을 검사한다. 수행 단계와 완료 단계는 트랜잭션을 구성하는 질의 중 일부가 수행되었기 때문에, 일반 장애에서 NoSQL 데이터베이스(104)가 복구되어 안정 상태로 전이될 때,, 수행 중이던 트랜잭션을 완료하는 특징을 가진다. 만약, 일반 장애에서 장애 상태가 복구되지 않을 경우는 트랜잭션을 실패를 서버에 전송한다.

단계(812)은 단계(808)에서 서버(102)에 요청한 동시성 충돌 요청 결과가 충돌이 발생하지 않은 것으로, 커밋 2단계의 장애 상황을 체크하는 초기 단계를 수행한다. 단계(814)는 단계(812)에서 수행한 장애 검사에서 장애가 발생한 상태인지 검사하고, 장애가 발생하면 단계(832)로 진행하여 서버(102)에 트랜잭션 실패 정보를 전송하고, 단계(826)으로 진행하여 결과적 트랜잭션 실패를 처리하고, 방법(800)은 단계(834)에서 완료된다.

단계(816)은 단계(814) 의 초기 단계가 장애가 발생하지 않았다면, 트랜잭션을 구성하는 질의를 수행한다. 단계(814)는 장애 상황 체크의 수행 단계를 처리하는 것으로 이하에 설명한다. 단계(818)은 단계(814)에서 수행한 질의 수행 처리에서 모든 질의 수행이 성공하였는지 검사하고, 단계(816)에서 모든 질의가 정상적으로 수행되었다면 단계(820)으로 진행하고, 실패하였다면 단계(828)로 진행한다.

단계(820)은 장애 상황 체크의 마지막 단계인 완료 단계를 수행한다. 단계(820)의 수행 결과를 단계(822)에서 판단하여 장애가 발생하였다면 단계(828)로 진행하고, 장애가 발생하지 않았다면, 단계(824)를 수행하여 결과적 트랜잭션을 성공 처리하고, 방법(800)은 단계(834)에서 완료된다.

단계(828)은 단계(818)의 질의 수행 처리가 성공하지 못한 경우 또는 단계(822)의 장애 상황 체크의 완료 단계에서 장애가 발생한 경우에 수행하고, NoSQL 데이터베이스(104)의 일반 장애인 동안 복구를 수행한다. 단계(830)은 단계(828)에서 수행한 트랜잭션 복구 처리의 성공 여부를 판단하여 실패한 경우는 단계(832)로 진행하여 서버(102)에 결과적 트랜잭션 실패 정보를 전송한 후, 시스템의 장애 상태를 일반 장애에서 심각 장애로 전이시키고, 단계(826)에서 결과적 트랜잭션 실패 처리하고, 방법(800)은 단계(834)에서 완료된다. 단계(830)에서 복구 처리가 성공하였다면, 트랜잭션을 복구 처리가 완료된 상태이므로, 일반 장애를 안정 상태로 전이시키고, 단계(824)로 진행하여 결과적 트랜잭션을 성공 처리하고, 방법(800)은 단계(8340에서 완료된다.

이제 도 9를 참조하면, 도 9는 결과적 트랜잭션의 커밋 2단계에서 장애 상황을 체크하는 수행 단계의 방법(900)이 도시된다. NoSQL 데이터베이스(104)는 대용량 데이터를 처리하기 위해 메모리 캐시를 사용하고, 가용성을 위해 복제를 수행한다. 전술한 바와 같이 메모리 캐시와 복제를 수행하는 NoSQL 데이터베이스(104)는 데이터가 NoSQL 데이터베이스(104) 클러스터에 저장되었다고 해서, 트랜잭션의 지속성 성질을 보장하는 것이 아니다. 지속성이란 한번 저장된 데이터가 유지되어야 하는 성질로 메모리 캐시에 저장된 데이터가 복제를 수행하지 않았거나 안전한 디스크로 저장되지 않았다면 장애와 함께 데이터 손실된다. 이와 같이 데이터 지속성이 보장되지 않는 NoSQL 데이터베이스(104)의 장애를 판단하기 위해 질의가 수행되는 시간을 누적시켜 일정시간이 경과한 다음에 NoSQL 데이터베이스(104)의 장애 상황을 검사하여야 한다.

방법(900)은 단계(902)에서 시작되고, 단계(904)에서 트랜잭션을 구성하는 질의를 NoSQL 데이터베이스(104)에 수행한다. 그 결과 질의의 수행 시간을 취득하여 단계(906)에서 질의 수행 시간을 누적시킨다. 단계(908)은 단계(906)에서 누적 시킨 질의 수행 시간이 NoSQL 장애 판단 시간을 초과하였는지 검사한다. NoSQL 장애 판단 시간은 전술한 바와 같이 NoSQL 데이터베이스(104)가 장애가 발생하여 메모리 캐시에 저장된 데이터가 복제 또는 로컬 디스크로 데이터를 저장하지 않아 데이터가 손실되는 최소 시간을 의미한다. 예를 들어, 복제 주기가 100ms이고 로컬 디스크 저장 주기가 1s라고 한다면, 최소 시간인 100ms가 NoSQL 장애 판단 시간이 된다. 단계(908)에서 NoSQL 장애 판단 시간을 초과한 경우는 단계(914)로 진행하고, 초과하지 않았다면 단계(910)으로 진행한다.

단계(914)에서 NoSQL 데이터베이스(104)의 장애 상황을 검사하여, 이전에 수행한 질의가 안정하게 저장되어 있는지 판단한다. 단계(916)은 단계(914)에서 수행한 NoSQL 데이터베이스(104)의 장애 여부를 판단하여 장애가 발생하였다면 단계(920)으로 진행하여 트랜잭션을 실패 처리하고, 방법(900)은 단계(922)에서 완료된다. 단계(916)에서 장애가 발생하지 않았다면, 방법(900)은 단계(918)에서 질의 누적 시간을 초기화하고, 단계(910)으로 진행한다.

단계(910)에서 더 이상 수행할 질의가 없을 경우는 단계(912)로 진행하여 트랜잭션을 성공 처리하고 방법(900)은 단계(922)에서 완료된다. 만약 수행할 질의가 있다면 단계(904)로 진행하여 질의를 수행한다. 방법(900)의 단계(912)의 트랜잭션 성공 처리는 트랜잭션을 구성하는 모든 질의에 대해 성공하였다고 보장하지 못한다. 예를 들어 단계(914) 이전에 수행한 질의는 NoSQL 데이터베이스(104)에서 장애가 발생하지 않았다면 수행된 질의의 지속성을 보장하지만, 단계(908)로 인해 마지막 질의가 단계(914)를 수행하지 않은 상태에서 완료될 수 있다. 따라서 마지막 질의의 성공 여부는 장애 상황 체크의 완료 단계에서 트랜잭션의 지속성 보장 여부를 판단한다.

이제 도 10을 참조하면, 도 10은 클라이언트(106)이 요청한 결과적 트랜잭션 동시성 충돌 요청을 처리하는 서버(102)의 처리 방법(1000)이 도시된다. 서버(102)가 처리하는 결과적 트랜잭션의 동시성 충돌 검사는 클라이언트(106)가 보내주는 트랜잭션 로그를 분석하여 동일한 시간에 동일한 테이블에 접근하는 트랜잭션을 검사한다. 방법(1000)은 단계(1002)에서 시작되고, 단계(1004)에서 동시성 충돌을 검사하기 위한 트랜잭션을 취득한다. 단계(1004)에서 트랜잭션을 취득하는 방법은 클라이언트(106)가 요청하는 메시지에 파라미터로 전달 받은 트랜잭션 ID를 이용한다.

단계(1006)에서 단계(1004)에서 취득한 트랜잭션의 질의 개수를 취득하고, 단계(1008)로 진행한다. 단계(1008)은 단계(1006)에서 취득한 트랜잭션 질의 개수만큼 반복할 것인지를 판단하고, 질의 개수만큼 반복 회수가 넘지 않았다면 단계(1010)으로 진행하고, 반복 회수를 초과하였다면 단계(1018)로 진행하여, 트랜잭션을 구성하는 모든 질의가 충돌되지 않아 트랜잭션 동시성 충돌이 없는 트랜잭션 성공 처리하고, 방법(1000)은 단계(1022)에서 완료된다.

단계(1010)에서 트랜잭션을 구성하는 질의가 읽기 연산인 경우에 다른 트랜잭션과 동시성 충돌이 있는지 검사한다. 읽기 연산에 대한 동시성 충돌 처리는 이하에 설명한다. 단계(1012)는 단계(1010)에서 수행한 읽기 연산에 대한 동시성 충돌이 있는지 검사하고, 충돌이 발생하면 단계(1020)으로 진행하여 트랜잭션 동시성 충돌이 있음을 클라이언트(106)에 통보하고, 방법(1000)은 단계(1022)로 완료된다.

단계(1014)는 트랜잭션을 구성하는 질의가 쓰기 연산인 경우에 다른 트랜잭션과 동시성 충돌이 있는지 검사한다. 쓰기 연산에 대한 동시성 충돌 처리는 이하에 설명한다. 단계(1016)는 단계(1014)에서 수행한 쓰기 연산에 대한 동시성 충돌이 있는지 검사하여, 충돌이 발생하면 단계(1020)으로 진행하여 트랜잭션 동시성 충돌이 있음을 클라이언트(106)에 통보하고 방법(1000)은 단계(1022)로 완료된다. 만약 단계(1016)에서 트랜잭션 충돌이 없다면, 트랜잭션을 구성하는 다음 질의를 처리하기 위해 단계(1008)로 진행된다.

이제 도 11를 참조하면, 도 11은 결과적 트랜잭션을 구성하는 질의 중에서 읽기 연산에 대한 동시성 충돌 검사를 수행하는 방법(1100)이 도시된다. 방법(1100)은 단계(1102)에서 시작되고, 단계(1104)에서 읽기 연산의 트랜잭션 로그를 분석하여 읽기 연산이 속한 트랜잭션의 타임 스탬프를 취득한다. 단계(1106)에서 활성화된 다른 트랜잭션 중에서 동일한 테이블에 접근하는 쓰기 연산을 가지고 있는 트랜잭션의 타임 스탬프(또는 타임 스탬프 리스트)를 취득한다.

단계(1108)에서 단계(1104)에서 취득한 타임 스탬프가 단계(1106)에서 취득한 타임 스탬프와 같거나 더 크다면(최신이라면) 트랜잭션 동시성은 충돌되었다고 판단하고, 단계(1110)으로 진행하여 트랜잭션 충돌 처리하고, 방법(1100)은 단계(1114)에서 완료된다. 만약 단계(1108)에서 충돌되지 않았다면 단계(1112)으로 진행하여 트랜잭션 성공 처리하고, 방법(1100)은 단계(1114)에서 완료된다.

보다 자세히 설명하면, 읽기 연산의 동시성 충돌은 읽기 연산을 수행하는 테이블이, 쓰기 연산을 연산을 수행하는 다른 트랜잭션이 먼저 선점하고 있다면 충돌이라고 판단하고, 선점된 쓰기 연산이 없다면 트랜잭션은 충돌되지 않는다고 판단한다. 또한 읽기 연산과 읽기 연산을 서로 동시성 충돌이 없으므로, 비교 대상에서 제외된다.

이제 도 12를 참조하면, 도 12는 결과적 트랜잭션을 구성하는 질의 중에서 쓰기 연산에 대한 동시성 충돌 검사를 수행하는 방법(1200)이 도시된다. 방법(1200)은 단계(1202)에서 시작되고, 단계(1204)에서 쓰기 연산의 트랜잭션 로그를 분석하여 쓰기 연산이 속한 트랜잭션의 타임 스탬프를 취득한다. 단계(1206)에서 활성화된 다른 트랜잭션 중에서 동일한 테이블에 접근하는 읽기 연산을 가지고 있는 트랜잭션의 타임 스탬프(또는 타임 스탬프 리스트)를 취득한다.

단계(1208)에서 단계(1204)에서 취득한 타임 스탬프가 단계(1206)에서 취득한 타임 스탬프와 같거나 더 크다면(최신이라면) 트랜잭션 동시성은 충돌되었다고 판단하고, 단계(1210)으로 진행하여 트랜잭션 충돌 처리하고 방법(1200)은 단계(1218)에서 완료된다. 만약 단계(1208)에서 충돌되지 않았다면 단계(1212)로 진행하여, 활성화된 다른 트랜잭션 중에서 동일한 레코드 또는 행에 쓰기 연산을 수행하는 트랜잭션의 타임 스탬프(또는 타임 스탬프 리스트)를 취득한다.

단계(1212)에서 단계(1204)에서 취득한 타임 스탬프가 단계(1212)에서 취득한 타임 스탬프와 같거나 더 크다면(최신이라면) 트랜잭션 동시성은 충돌되었다고 판단하고, 단계(1210)으로 진행하여 트랜잭션 충돌 처리하고, 방법(1200)은 단계(1218)에서 완료된다. 단계(1212)에서 충돌되지 않았다면 단계(1216)으로 진행하여 트랜잭션 성공 처리하고 방법(1200)은 단계(1218)에서 완료된다.

보다 자세히 설명하면, 쓰기 연산의 동시성 충돌은 쓰기 연산을 수행하는 테이블이, 읽기 연산을 수행하는 다른 트랜잭션이 먼저 선점하고 있다면 충돌이라고 판단하고, 쓰기 연산을 수행하는 다른 트랜잭션에 대해서는 동일한 레코드를 접근하는 다른 트랜잭션이 먼저 선점하고 있다면 충돌로 판단한다. 만약, 다중 업데이트와 같이 복수개의 레코드에 대한 쓰기 연산이 있을 경우는 레코드 단위가 아닌 테이블 단위로 쓰기 연산과의 동시성 충돌 검사를 수행한다.

전술한 내용은 본 발명의 예들을 포함한다. 본 발명을 설명하기 위하여 방법 또는 구성 요소의 가능한 모든 조합을 설명하는 것은 불가능하지만, 당업자라면 보다 더 많은 다양한 조합 및 치환이 가능하다는 것을 이해할 것이다. 따라서, 본 발명은 특허청구범위의 사상 및 범위에 포함되는 이러한 모든 교체, 변경, 변화를 포괄하는 것이다.

Claims

NoSQL 데이터베이스의 트랜잭션을 처리하는 방법에 있어서,
결과적 트랜잭션 서버(102)는 결과적 트랜잭션 클라이언트(106)가 생성한 트랜잭션을 전달 받고, 결과적 트랜잭션 클라이언트(106)가 요청한 트랜잭션이 처리되는 시간대에 NoSQL 데이터베이스에 존재하는 동일한 테이블 또는 레코드에 접근하는 다른 트랜잭션이 존재하는지 판단하는 동시성 충돌 검사를 수행하여 트랜잭션 처리 시간대가 중첩되지 않는 트랜잭션을 성공으로 처리하는 (1)단계와, 상기 (1)단계의 성공한 트랜잭션을 결과적 트랜잭션 클라이언트(106)가 NoSQL 데이터베이스에 저장하는 (2)단계를 포함하고,
상기 (1)단계의 트랜잭션 동시성 충돌 검사에서 성공한 트랜잭션은 (2)단계에서 NoSQL 데이터베이스의 장애로 인해 트랜잭션 저장이 실패하더라도 NoSQL 데이터베이스의 장애를 자동 복구가 가능한 일반 장애와 자동 복구가 불가능한 심각장애로 구분하여, 일반 장애는 결과적 트랜잭션 클라이언트(106)가 트랜잭션 저장을 재 수행함으로써 트랜잭션 처리를 완료하고, 심각 장애는 NoSQL 데이터베이스 복구와 함께 (2)단계에서 실패한 트랜잭션을 결과적 트랜잭션 서버(102)가 트랜잭션 처리를 완료함으로써 트랜잭션을 보장하는 것을 특징으로 하는 NoSQL 기반의 결과적 트랜잭션 방법.
제1항에 있어서,
상기 (1)단계의 트랜잭션 동시성 충돌 검사를 위해 트랜잭션 생성 시간을 나타내는 타임 스탬프(502)와, 트랜잭션 ID(504)와, 명령어 종류(506)와, 명령 일련 번호(508)와, 테이블 명(510)와, 명령 해시 코드(512)와, 질의 데이터(514)를 포함하는 트랜잭션 로그는 동일한 트랜잭션 ID(504)를 가지는 모든 트랜잭션 로그에 대해 동일한 타임 스탬프(502) 값을 가지며, 상기 트랜잭션 로그를 트랜잭션 시작과 종료를 나타내는 질의 유형과 함께 서버에 저장하는 (가)단계 : 상기 (가)단계 수행 후 클라이언트가 서버에 트랜잭션 충돌 검사를 요청하는 (나)단계 : 상기 (나)단계를 받아들인 서버가 명령어 종류(506)를 읽기 연산과 쓰기 연산으로 구분하는 (다)단계 : 상기 (다)단계의 읽기 연산을 완료되지 않은 활성화된 트랜잭션의 쓰기 연산과 비교하여 이전 타임스탬프 값을 가지는 트랜잭션이 있으면 충돌로 처리하는 (라)단계 : 상기 (다)단계의 쓰기 연산을 완료되지 않은 활성화된 트랜잭션의 읽기와 쓰기 연산과 비교하여 이전 타임스탬프 값을 가지는 트랜잭션이 있으면 충돌로 처리하는 (마)단계 : 상기 (라)와 (마)단계의 충돌이 발생된 트랜잭션을 일정 회수만큼 클라이언트가 서버에 충돌 검사를 재 요청하는 (바)단계 : 상기 (바)단계 동안 충돌이 해결되지 않으면 트랜잭션을 실패로 처리하는 (사)단계 : 상기 (사)단계의 실패한 트랜잭션 정보를 클라이언트가 서버에 통보하여, 서버에 저장된 트랜잭션 로그를 제거하는 (아)단계를 포함하여 트랜잭션의 일관성과 고립성을 보장하는 것을 특징으로 하는 NoSQL 기반의 결과적 트랜잭션 방법.
제1항에 있어서,
상기 (2)단계의 NoSQL 데이터베이스에 트랜잭션 저장을 보장하는 방법은, NoSQL 데이터베이스의 장애를 자동 복구가 가능한 일반 장애와 자동 복구가 불가능한 심각 장애로 구분하고,
상기 일반 장애가 발생한 트랜잭션은 일반 장애가 자동 복구 될 때, 결과적 트랜잭션 클라이언트(106)가 트랜잭션을 구성하고 있는 질의가 정상적으로 수행되었는지 NoSQL 데이터베이스를 검사하여 레코드가 삽입, 수정, 삭제되지 않은 질의를 재 수행하여 트랜잭션을 완료하고,
상기 심각 장애가 발생한 트랜잭션은 결과적 트랜잭션 클라이언트(106)가 결과적 트랜잭션 서버(102)에 트랜잭션 실패를 통보하고, NoSQL 데이터베이스가 복구되어 결과적 트랜잭션 클라이언트(106)가 새로운 트랜잭션 처리를 요청 받게 되면, 결과적 트랜잭션 서버(102)의 트랜잭션 로그에 저장된 실패한 트랜잭션을 먼저 복구하는 것을 특징으로 하는 NoSQL 기반의 결과적 트랜잭션 방법.
제3항에 있어서,
상기 일반 장애와 심각 장애에 발생한 트랜잭션을 처리하기 위해, 결과적 트랜잭션 서버(102)에서 동시성 충돌 검사에서 다른 트랜잭션과 시간대가 충돌하지 않은 트랜잭션을 결과적 트랜잭션 클라이언트(106)가 NoSQL 데이터베이스에 저장하는 처리 과정을 초기 단계, 수행 단계, 완료 단계로 구분하고,
상기 초기 단계에서 트랜잭션 수행하기 전, 장애가 판단되면 장애 상태를 일반 장애로 처리하는 (A)단계 : 상기 (A)단계가 복구될 때까지 일정시간을 대기 하는 (B)단계 : 상기 (B)단계 동안 장애가 복구되지 않으면, 일반 장애를 심각 장애로 설정하고 트랜잭션 실패를 서버에 전송하는 (C)단계를 포함하고,
상기 수행 단계에서 트랜잭션 개별 질의가 수행되는 시간을 누적시키는 (D)단계 : 상기 (D)단계의 누적시킨 시간과 NoSQL 장애 판단 지연 시간과 비교하고, NoSQL 장애 판단 지연 시간을 초과하기 전에 장애 상황을 검사하여 트랜잭션의 지속성 성질이 보장하는 (E)단계 : 상기 (E)단계에서 장애가 발생하면 트랜잭션을 실패 처리하는 (F)단계 : 상기 (E)단계에서 장애가 발생하지 않으면 누적 시간을 초기화하고 (D)단계로 진행하는 (G)단계를 포함하고,
상기 완료 단계에서 (F)단계의 트랜잭션 실패 또는 장애가 판단되면 장애 상태를 일반 장애로 처리하는 (H)단계 : 상기 (H)단계가 복구될 때까지 일정시간을 대기 하는 (I)단계 : 상기 (I)단계 동안 일반 장애가 복구되지 않으면, 일반 장애를 심각 장애로 설정하고 트랜잭션 실패를 결과적 트랜잭션 서버(102)에 전송하는 (J)단계 : 상기 (I)단계 동안 장애가 복구되면, 실패한 트랜잭션을 완료하는 (K)단계를 포함하는 것을 특징으로 하는 NoSQL 기반의 결과적 트랜잭션 방법.
NoSQL 데이터베이스의 트랜잭션을 처리하기 위한 시스템에 있어서,
결과적 트랜잭션 서버(102)는 결과적 트랜잭션 클라이언트(106)가 생성한 트랜잭션을 전달 받고, 결과적 트랜잭션 클라이언트(106)가 요청한 트랜잭션이 처리되는 시간대에 NoSQL 데이터베이스에 존재하는 동일한 테이블 또는 레코드를 접근하는 다른 트랜잭션이 존재하는지 판단하는 동시성 충돌 검사를 수행하여 트랜잭션 처리 시간대가 중첩되지 않는 트랜잭션을 성공으로 처리하는 결과적 트랜잭션 서버(600)와
결과적 트랜잭션 클라이언트(106)는 결과적 트랜잭션 서버(102)에서 동시성 충돌 검사를 성공한 트랜잭션을 NoSQL 데이터베이스의 장애로 인해 트랜잭션 저장이 실패하더라도 NoSQL 데이터베이스의 장애를 자동 복구가 가능한 일반 장애와 자동 복구가 불가능한 심각장애로 구분하여, 일반 장애는 결과적 트랜잭션 클라이언트(106)가 트랜잭션 저장을 재 수행함으로써 트랜잭션 처리를 완료하고, 심각 장애는 결과적 트랜잭션 클라이언트(106)가 결과적 트랜잭션 서버(102)에 심각 장애를 통보하여 NoSQL 데이터베이스 복구와 함께 저장을 실패한 트랜잭션을 결과적 트랜잭션 서버(102)가 트랜잭션 처리를 완료함으로써 트랜잭션을 보장하는 결과적 트랜잭션 클라이언트(200)를 포함하는 시스템.
제5항에 있어서,
상기 결과적 트랜잭션 클라이언트(200)는 결과적 트랜잭션을 생성하여 결과적 트랜잭션 서버(600)에 트랜잭션 동시성 충돌 검사를 수행하고, 동시성 충돌 검사를 성공한 트랜잭션을 NoSQL 데이터베이스에 저장하는 트랜잭션 생성기(202)와, NoSQL 데이터베이스의 장애를 자동 복구가 가능한 일반 장애와 자동 복구가 불가능한 심각 장애로 판단하는 NoSQL 헬스 검사기(204)와, 트랜잭션 로그를 로컬 저장소에 저장하는 트랜잭션 로거(206)를 포함하며, 복수개로 수평적 확장이 가능하도록 무공유 저장 구조 특징을 가지는 시스템.
제6항에 있어서,
상기 트랜잭션 생성기(202)는 NoSQL 데이터베이스에 트랜잭션을 저장함에 있어서, 결과적 트랜잭션 클라이언트에 저장된 NoSQL 장애 판단 지연 시간을 초과하여 NoSQL 데이터베이스의 장애가 지속되었을 경우 헬스 플래그(210)의 장애 플래그를 On으로 설정하는 장애 처리 컴포넌트(310)와, NoSQL 데이터베이스의 장애가 결과적 트랜잭션 클라이언트에 저장된 NoSQL 장애 판단 지연 시간 안에 복구되어 정상 동작을 수행할 경우 트랜잭션을 구성하고 있는 질의가 정상적으로 수행되었는지 NoSQL 데이터베이스를 검사하여, 레코드가 삽입, 수정, 삭제되지 않은 질의를 재 수행하여 트랜잭션을 완료시키는 트랜잭션 복구 컴포넌트(308)를 포함하고,
상기 NoSQL 헬스 검사기(204)는 NoSQL 데이터베이스의 장애가 발생함과 동시에 기동 되어 하트비트 플래그를 On으로 설정하는 단계와 주기적으로 장애 상태를 체크하여 NoSQL 데이터베이스가 복구되면 하트비트 플래그를 Off로 설정하고 장애 상태 체크를 종료하는 단계와 장애 플래그와 하트비트 플래그를 이용하여 장애가 발생하지 않은 안정상태와 NoSQL 데이터베이스의 장애를 자동 복구할 수 있는 일반장애상태와 NoSQL 데이터베이스의 장애를 자동 복구할 수 없는 심각장애상태와 심각장애 발생 후 NoSQL 데이터베이스가 복구되어 결과적 트랜잭션을 재수행할 수 있는 복구가능상태로 구분하는 헬스 플래그(210)를 포함하고,
상기 트랜잭션 로거(206)는 결과적 트랜잭션 서버(102) 장애로 인해 결과적 트랜잭션 서버(600)가 트랜잭션 복구를 수행할 수 없을 경우 로컬에 저장된 트랜잭션 로그를 이용하여 트랜잭션을 복구하는 것을 특징으로 하는 시스템.
제5항에 있어서,
상기 결과적 트랜잭션 서버는 결과적 트랜잭션 클라이언트에서 생성된 트랜잭션을 저장하는 트랜잭션 로그 저장소(610)와, 결과적 트랜잭션 클라이언트가 요청한 트랜잭션이 처리되는 시간대에 NoSQL 데이터베이스에 존재하는 동일한 테이블 또는 레코드를 접근하는 다른 트랜잭션이 존재하는지 판단하는 동시성 충돌 검사를 수행하는 트랜잭션 동시성 제어 컴포넌트(606)와, NoSQL 데이터베이스 장애로 NoSQL 데이터베이스에 저장하지 못한 트랜잭션을 트랜잭션 로그 저장소(610)에 저장된 트랜잭션 로그를 재 수행함으로써 실패한 트랜잭션을 복구하는 트랜잭션 복구 컴포넌트(608)를 포함하고,
상기 트랜잭션 동시성 제어 컴포넌트(606)와 트랜잭션 복구 컴포넌트(608)에서 발생한 행위 로그를 저장하는 결과적 트랜잭션 서버 로그 저장소(604)와, 상기 행위 로그를 이용한 통계 정보를 보여주는 결과적 트랜잭션 관리 웹 서버(602)를 더 포함하는 시스템.