24×365 지원을 위한 프레임워크 역할

24×365 개요

24×365는 흔히 24시간 365일 무중단으로 운영하는 것을 의미합니다. 시스템을 멈추지 않고 계속 운영하면 365일 24시간 운영할 수 있는데, 왜 이런 용어가 생긴 걸까요?

시스템을 중단하는 근본적인 이유는 전일자 백업 데이터를 확보하기 위함입니다. 금융권(은행·카드·증권·보험)에서는 일 마감 데이터로 처리하는 작업이 수없이 많고, 이 전일자 백업 데이터(BCV)는 일반적으로 계정계 DB Disk 복제를 통하여 만들어집니다. 그런데 날짜가 바뀌고 나서도 BCV Split을 하기 전까지는 계속해서 복제가 이루어지기 때문에 익일 데이터가 백업 DB에 남게 되는데, 이 문제를 해결하기 위해 거래 정지를 하는 것입니다.

거래 정지를 통한 일자전환을 하게 되면, 실생활에서도 마트나 택시에서 또는 계좌이체 시 24시 전후로 거래가 안 되는 것을 경험해 보았을 것입니다. 모두 일자전환을 하기 위한 거래 정지 때문에 발생하는 일들이며, 이와 같은 고객의 불편함이 민원으로 이어지면서 무중단 시스템의 요구가 발생하기 시작한 것입니다.

데이터 복제 흐름

• ETL: Extract, Transform, Load의 약어로서 데이터를 추출하고 가공하고 저장하는 배치 프로그램을 의미합니다.

거래정지를 통한 일자 전환

개요에서 설명했듯이 거래정지를 통한 일자전환은 24시 전후로 거래 유입을 막아 전일자 데이터를 확보하는 것입니다. 가장 확실하게 전일자 데이터를 확보하는 방법이며, 이 방식은 프레임워크의 역할이 필요하지 않습니다.

거래정지를 통한 일자전환 절차

위 절차는 쉽게 이해하기 위한 간략한 실행 순서이며, 회사마다 시간도 다르고 작업도 많이 세분화되어 있다고 봐야 합니다. 위 과정에서 정기배포도 포함시킬 수 있으며, 서버 재기동도 포함시킬 수 있습니다.

단계	내용
BCV Sync	Disk 복제 시작
거래정지	거래 유입 중지
일자전환	일자전환
BCV Split	Disk 복제 중지
거래정지해제	거래 재개

무중단 일자전환

무중단 일자전환은 일자전환 후 백업 DB에 남게 되는 익일자 거래 데이터를 전일자 마지막 데이터로 보정하여, 전일자 데이터를 확보하는 방식입니다. 이를 위해 CUD에 해당하는 이전 데이터와 이후 데이터를 기록해 두고, 보정 배치를 통해 전일자 데이터로 맞춥니다.

무중단 일자전환 절차

단계	내용
BCV Sync	Disk 복제 시작
데이터기록시작	INSERT, UPDATE, DELETE Query의 이전 데이터와 이후 데이터를 기록하기 시작 (프레임워크)
일자전환	일자전환
BCV Split	Disk 복제 중지
데이터기록중지	이전·이후 데이터 기록 종료
BCV 보정배치 수행	백업 데이터의 익일자 데이터를 전일자 데이터로 보정하는 배치 수행 (프레임워크)

프레임워크의 역할

무중단 일자전환을 위해서 프레임워크는 어떤 역할을 해야 할까요? 크게 테이블 관리, 데이터 적재, 보정배치 수행의 세 가지 역할을 해야 하며, 자세한 내용은 하위 챕터에서 다루겠습니다.

DevOn Enterprise, DevOn Boot Enterprise에 특화된 프레임워크의 기능 설명이 아닌 일반적인 개념 위주로 설명합니다.

테이블 관리

전일자 데이터를 보정한다고 해서 계정계 테이블 전체를 보정하는 것은 아닙니다. 몇천 개, 몇만 개 되는 테이블을 모두 보정할 수는 없습니다. 주로 계정성, 즉 돈과 관련된 테이블을 보정하게 되는데, 이 때문에 보정해야 하는 테이블에 대해서 프레임워크에서 관리를 해야 합니다.

컬럼	설명
원장ID	PK
테이블명	보정 대상 테이블
테이블PK	보정 대상 테이블 PK

원장관리테이블

간략하게 위와 같이 보정 대상 테이블을 프레임워크 메타데이터로 관리하며, 운영관리 메뉴를 통해 등록·수정·삭제를 할 수 있어야 합니다.

데이터 적재

CUD(INSERT, UPDATE, DELETE) SQL 수행 시, CUD를 수행하기 전 데이터와 수행한 후의 데이터를 보관하고 있어야 합니다. 무중단 일자전환의 과정 중 "데이터기록시작"이 되면, 대상 테이블이면서 CUD 구문에 해당하는 경우 이전 데이터와 이후 데이터를 보관합니다.

데이터를 적재하는 방법은 보편적으로 아래 세 가지가 있습니다.

DBIO 등록

DBIO 등록 방법은 CUD 구문에 대해 Select 문을 직접 등록하는 것입니다. 예를 들어 다음과 같은 Update 문이 있다고 하겠습니다.

UPDATE TB_ACCOUNT SET AMOUNT = ${amount} WHERE ACCOUNT_NO = ${account_no}

해당 쿼리의 select 구문을 직접 등록합니다.

SELECT * FROM TB_ACCOUNT WHERE ACCOUNT_NO = ${account_no}

이렇게 원쿼리의 DBIO를 직접 등록하여 데이터를 저장하는 방식입니다.

<statement name="updateAccount">
    <dbio>
        SELECT * FROM TB_ACCOUNT WHERE ACCOUNT_NO = ${account_no}
    </dbio>
    <update>
        UPDATE TB_ACCOUNT SET AMOUNT = ${amount} WHERE ACCOUNT_NO = ${account_no}
    </update>
</statement>

프레임워크에서는 런타임 시에 dbio를 이용하여 이전·이후 데이터를 조회할 수 있습니다.

정적분석

정적분석은 CUD 쿼리에 대해 테이블명과 where 구문을 추출하여 select 문을 만드는 것입니다.

UPDATE TB_ACCOUNT SET AMOUNT = ${amount} WHERE ACCOUNT_NO = ${account_no}
-- 추출한 테이블명과 where 구문으로 select 문을 생성
SELECT * FROM TB_ACCOUNT WHERE ACCOUNT_NO = ${account_no}

정적분석 방법은 제약이 있습니다. 오라클을 사용한다면 정적분석이 힘든 구문을 쓰지 않도록 가이드해야 합니다. MERGE 구문이나 INSERT ALL, INSERT FIRST 구문 등을 사용하게 되면 정적분석을 하지 못합니다.

SQL Parser

JSqlParser, Apache Calcite, Druid SQL Parser 등 SQL Parser 라이브러리를 이용해서 대응 쿼리를 만드는 방식입니다.

데이터 저장

데이터는 프레임워크 메타 테이블을 다음과 같이 구성하여 저장할 수 있습니다.

컬럼	설명
테이블명	보정 대상 테이블명
순번	다건의 Update, Delete의 경우 순서
CUD 유형	원 쿼리의 CUD 유형 (INSERT, UPDATE, DELETE)
이미지유형	이전·이후 이미지 구분 (아래 표 참고)
일자	쿼리 수행 일자
시간	쿼리 수행 시간 (YYYYMMDDHH24MISS)
데이터	이미지 유형에 해당하는 데이터
PK	보정 대상 테이블의 PK
GUID	거래 GUID
서비스ID	거래 서비스ID

이미지유형은 원 쿼리의 CUD 유형에 따라 아래와 같이 나뉩니다.

이미지유형	설명
UB	UPDATE 이전 데이터
UA	UPDATE 이후 데이터
NA	INSERT 이후 데이터. INSERT는 이후 데이터만 존재하므로 보정 시 DELETE를 수행합니다.
NB	DELETE 이전 데이터. DELETE는 이전 데이터만 존재하므로 보정 시 INSERT를 수행합니다.

메커니즘

DAO의 Interceptor 패턴을 이용하여 구현하는 것이 일반적입니다. LG CNS의 DevOn Enterprise Framework가 제공하는 AutoDaoInterceptor나 MyBatis의 Interceptor를 이용하여 구현할 수 있습니다. 그렇다면 Interceptor의 전처리(preProcess)와 후처리(postProcess)에서 처리 흐름이 어떻게 이어지는지 살펴보겠습니다.

전처리(preProcess)

전처리에서는 데이터적재모드 여부, 보정 대상 테이블 여부, 이전 이미지 저장 여부 등을 체크하여 이전 이미지를 조회합니다.

전처리(preProcess) 처리 흐름

후처리(postProcess)

후처리에서는 전처리에서 이미지 저장 대상으로 판단된 경우, 이후 이미지를 조회하여 전처리에서 조회한 이전 이미지와 함께 저장합니다.

후처리(postProcess) 처리 흐름

보정배치 수행

일자전환이 끝나고 BCV 백업이 종료된 이후에, 프레임워크에 남겨져 있는 Restore 데이터를 이용하여 보정배치가 수행되어 전일자 데이터로 보정을 합니다. 보정배치에서는 익일자에 수행된 쿼리를 시간으로 descending 하여 시간 역순으로 보정을 수행해 주면 됩니다.

마무리

이 글은 특정 제품의 기능 가이드가 아니라, 24×365가 무엇이고 왜 필요한지 이해하기 위한 개념을 중심으로 정리했습니다. 무중단 일자전환을 구현하는 방식은 제품마다 다르지만, 보정 대상 테이블을 관리하는 체계와 CUD의 이전·이후 이미지를 확보하는 방식, 그리고 이를 전일자 기준으로 되돌리는 보정배치라는 세 가지 축은 공통적으로 필요합니다.

무중단 운영은 시스템을 멈추지 않는 문제라기보다, 전일자 데이터의 정합성을 어떤 구조로 보장하느냐의 문제입니다. 24×365를 검토할 때 개별 기능의 유무보다 이 정합성 보장 체계가 프레임워크 차원에서 표준화되어 있는지를 먼저 살펴본다면, 도입 이후의 운영 부담까지 함께 가늠할 수 있습니다.