KR100857036B1

KR100857036B1 - 과금 시스템에서 트랜잭션 로그 파일을 이용한 장애 복구방법 및 그 장치

Info

Publication number: KR100857036B1
Application number: KR1020070038988A
Authority: KR
Inventors: 심재희; 정찬호
Original assignee: (주)엔텔스
Priority date: 2007-04-20
Filing date: 2007-04-20
Publication date: 2008-09-05

Abstract

본 발명은 과금 시스템에서 트랜잭션 로그 파일을 이용한 장애 복구 방법 및 그 장치에 관한 것이다. 본 발명에 따른 장애 복구 장치는 트랜잭션 이벤트에 따라 이벤트 트랜잭션 로그 파일을 생성, 저장 및 갱신하는 로그 파일 생성부; 상기 과금 게이트웨이 시스템의 장애를 감지하고, 상기 생성된 이벤트 트랜잭션 로그 파일에 상응하는 로그 파일 정보를 상기 로그 파일 생성부로부터 수신하여 소정의 로그 파일 리스트에 기록하는 장애 관리부; 및 상기 저장된 이벤트 트랜잭션 로그 파일을 독출하여 장애를 복구하는 장애 복구부를 포함한다. 따라서, 본 발명에 따른 장애 복구 장치는 장애 복구를 위한 트랜잭션 로그 파일을 생성하는 수단 및 장애 발생 시 생성된 로그 파일을 이용하여 과금 데이터를 복구하는 수단을 제공함으로써, 보다 안정적이고 정확한 과금 처리를 수행할 수 있다.

장애 복구, 로그, 트랜잭션, 공유메모리, 대기 행렬

Description

과금 시스템에서 트랜잭션 로그 파일을 이용한 장애 복구 방법 및 그 장치{METHOD AND APPARATUS FOR RECOVERING THE FAULT USING THE TRANSACTION LOG FILE IN THE CHARGING SYSTEM}

도 1은 본 발명의 일 실시예에 따른 과금 게이트웨이 시스템 구성도

도 2는 본 발명에 일 실시예에 따른 프로세스흐름관리부의 블록도

도 3은 본 발명에 일 실시예에 따른 프로세스흐름관리부의 초기화 절차를 도시한 순서도

도 4는 본 발명의 일 실시예에 따른 세션 관리부의 동작을 도시한 순서도

도 5는 본 발명의 일 실시예에 따른 응용 프로세스가 요청한 서비스를 초기화하는 방법을 도시한 순서도

도 6은 본 발명의 일 실시예에 따른 응용 프로세스가 요청한 서비스를 초기화하는 과정을 도시한 흐름도

도 7은 본 발명의 일 실시예에 따른 프로세스흐름관리부에서 응용 프로세스의 메시지 삽입 요청을 처리하는 절차를 도시한 흐름도

도 8은 본 발명의 일 실시예에 따른 프로세스흐름관리부에서 응용 프로세스의 메시지 추출 및 삭제 요청을 처리하는 절차를 도시한 흐름도

도 9는 본 발명의 일 실시예에 따른 응용 프로세스에 설정된 서비스를 종료하는 절차를 도시한 흐름도

도 10은 본 발명의 일 실시예에 따른 트랜잭션 이벤트를 로그 파일에 기록하는 방법을 도시한 순서도

도 11은 본 발명의 일 실시예에 따른 체크 포인트 작업 시 로그 파일을 분석하는 방법을 도시한 순서도

도 12는 본 발명의 일 실시예에 따른 체크 포인트 작업 시 로그 파일 삭제하는 방법을 도시한 순서도

도 13은 본 발명의 일 실시예에 따른 장애 복구 시 파일 단위 동기화 작업을 수행하는 방법에 관한 순서도

*주요 도면 부호

100 : 과금 게이트웨이(Charging Gateway)

215 : 응용 프로세스(Application Process)

220 : 프로세스흐름관리API(Process Flow Control API)

225 : 유닉스 공유 메모리(Unix Shared Memory)

230 : 세션 관리부(Session Manager)

240 : 메모리 관리부(Memory Manager)

250 : 세션 스레드(Session Thread)

260 : 대기 행렬(Queue)

280 : 장애 관리부(Audit Manager)

285 : 장애 복구부(Audit Recovery)

290 : 로그 파일 생성부(Audit Logger)

295 : 트랜잭션 로그 파일 저장부(Transaction Log File Storage)

본 발명은 과금 시스템에서 트랜잭션 로그 파일을 이용한 장애 복구 방법 및 그 장치에 관한 것으로, 좀 더 상세하게는 장애 발생 시 실시간 생성된 트랜잭션 로그 파일을 이용하여 과금 데이터를 복구하는 것이 가능한 과금 시스템에서 트랜잭션 로그 파일을 이용한 장애 복구 방법 및 그 장치에 관한 것이다. .

과학 기술의 발전과 경제 수준의 향상은 통신 기기의 개발과 광범위한 보급을 가능하게 하였다. 또한 통신 기기의 보급은 원격지에 위치한 사용자간에 유무선 통신망을 통한 데이터의 송수신을 가능하게 하였다.

서비스 사업자는 특정 사용자에 제공된 패킷 및 음성 서비스에 대한 과금을 수행하기 위해 서비스 별 제공된 과금 기초 데이터를 생성하고 이를 수집 및 처리하여 고객 별 요금 청구서를 작성할 필요가 있다.

하지만, 통신 서비스 가입자의 폭발적인 증가에 따라, 단위 시간 당 과금 처리 시스템에서 처리할 과금 기초 데이터의 양은 급격히 증가하고 있는 실정이다.

또한, 최근 통신 서비스가 다양화됨에 따라, 실시간으로 처리되어야 하는 과금 기초 데이터가 증가하고 있다.

하지만, 실시간 과금 기초 데이터를 효과적으로 수집 및 처리하기 위해서는 하드웨어 성능뿐만 아니라 과금 처리 시스템에 탑재되는 소프트웨어의 성능 최적화시키는 것이 중요하다.

일반적으로, 유선 또는 무선 통신 등에 관련된 대용량의 과금 데이터를 처리하는 과금 처리 시스템은 다중 프로세스 및 다중 스레드(Multi-Thread)로 구성되며, 처리할 데이터의 특성에 따라 다양한 데이터 흐름 제어가 필요하다.

또한, 처리할 데이터의 양 및 제공할 서비스의 종류 등의 운영 환경에 따라 프로세스 및 스레드의 동적인 생성 및 삭제가 발생하므로, 시스템 자원의 효율적인 할당 및 관리가 무엇보다 중요하다.

일반적으로, 과금 처리 시스템에 사용되는 유닉스(Unix) 운용 체제에 있어서, 복수의 프로세스 및 스레드 간의 데이터 메시지의 전달은 프로세스간 통신(IPC : Inter-Process Communication) 방식을 이용하여 수행되었다.

특히, 과금 시스템은 대량의 과금 데이터를 처리하므로, 시스템 내부 또는 외부적인 문제로 인하여, 장애가 발생할 수 있다.

과금 데이터는 고객에게 제공된 서비스에 대한 요금을 산출하는데 있어서, 대단히 중요한 정보이므로 손실 및 훼손이 발생하지 않도록 관리하는 것이 필요하다.

하지만, 종래에는 장애 발생 시 장애 발생 이전 상태로 복구하기 위한 효과 적인 장애 복구 방법이 제공되지 않았다

또한, 일반적으로 종래에는 RDBMS(Relation Database Management System) 시스템을 통해 과금 시스템에서 생성되는 모든 과금 데이터를 백업(backup)하는 방법을 채택하였으나, 이는 대량(예를 들면, 하루에 수억 또는 수십 억 개의 과금 데이터가 될 수 있음)의 과금 데이터가 발생하는 과금 시스템 환경에는 적합하지 않은 문제점이 있었다.

따라서, 종래 기술에 따른 장애 복구 방법은 데이터베이스 시스템에 과부하를 야기할 수 있으며, 잦은 데이터 베이스 접속으로 인해 전체적인 과금 데이터 처리 성능이 떨어지는 문제점이 있었다.

상기한 바와 같은 종래 기술의 문제점을 해결하기 위해, 본 발명의 목적은 프로세스간 메시지 전송을 위해 공유 메모리 및 대기 행렬을 이용하는 과금 게이트웨이(charging gateway)에서 실시간으로 트랜잭션 로그 파일을 생성 및 저장하고 이를 관리하는 방법 및 장치를 제공하는 것이다.

또한, 본 발명의 목적은 장애 발생 시 기 저장된 트랜잭션 로그 파일을 이용하여 공유 메모리 및 대기 행렬의 상태를 장애 발생 이전 상태로 복구하는 것이 가능한 장애 복구 방법 및 그 장치를 제공하는 것이다.

또한, 본 발명의 다른 목적은 트랜잭션 단위의 이벤트를 수신하고, 수신된 이벤트를 이용하여 이벤트 트랜잭션 로그 파일을 생성하는 방법을 제공하는 것이 다.

또한, 본 발명의 다른 목적은 트랜잭션 단위의 데이터 처리를 가능하게 함으로써, 데이터 처리 성능을 향상시키는 것이다.

또한, 본 발명의 다른 목적은 프로세스흐름관리부에 소정의 사용자 인터페이스를 통해 프로세스/자원/망의 상태 관리, 통계 및 분석, 장애 관리 및 구성 정보 관리를 위한 운용 관리부를 추가함으로써, 시스템의 유지 보수가 용이할 뿐만 아니라 연구 개발을 위한 테스트 베드로 활용 가능한 과금 게이트웨이 시스템을 제공하는 것이다.

본 발명의 다른 목적들은 이하의 실시예에 대한 설명을 통해 쉽게 이해될 수 있을 것이다.

상기한 바와 같은 목적을 달성하기 위해, 본 발명의 일 측면에 따르면, 트랜잭션 로그 파일을 이용한 장애 복구 장치가 개시된다.

본 발명의 일 실시예에 따르면, 장애 복구 장치는 트랜잭션 이벤트에 따라 이벤트 트랜잭션 로그 파일을 생성, 저장 및 갱신하는 로그 파일 생성부; 상기 과금 게이트웨이 시스템의 장애를 감지하고, 상기 생성된 이벤트 트랜잭션 로그 파일에 상응하는 로그 파일 정보를 상기 로그 파일 생성부로부터 수신하여 소정의 로그 파일 리스트에 기록하는 장애 관리부; 및 상기 저장된 이벤트 트랜잭션 로그 파일을 독출하여 장애를 복구하는 장애 복구부를 포함하되, 상기 트랜잭션 이벤트는 응용 프로세스간 메시지의 흐름을 제어하는 세션 스레드(Session Thread)로부터 수신되며, 상기 장애 복구부는 상기 추출된 이벤트 트랜잭션 로그 파일을 분석하여 장애 복구 대상인 이벤트 트랜잭션 로그 파일을 선별하고, 상기 선별된 이벤트 트랜잭션 로그 파일을 이용하여 상기 과금 게이트웨이 시스템에 구비된 대기 행렬 및 공유 메모리를 동기화시키는 것을 특징으로 한다.

본 발명의 다른 일 측면에 따르면, 트랜잭션 로그 파일을 이용한 장애 복구 방법이 개시된다.

본 발명의 일 실시예에 따른 트랜잭션 로그 파일을 이용한 장애 복구 방법은 (a) 트랜잭션(Transaction) 단위의 로그 정보를 생성하여 로그 파일에 기록하는 단계; (b) 장애 발생에 따라 상기 과금 게이트웨이 시스템이 재 구동되는 경우, 상기 로그 파일을 분석하여 장애 복구 대상인 로그 파일을 선택하는 단계; 및 (c) 상기 선택된 로그 파일에 저장된 상기 로그 정보를 독출하여 상기 장애 발생 이전 상태로 메모리를 복구하는 단계를 포함하되, 상기 (c) 단계는 상기 (b) 단계에서 선택된 로그 파일에 상응하는 파일 정보가 상기 로그 파일이 생성된 시간 순으로 정렬된 로그 파일 동기화 대상 로그 파일 정보 리스트를 생성하는 단계를 포함하고, 상기 정렬된 순서로 상기 로그 파일을 독출하여 상기 메모리를 복구하는 것을 특징으로 한다.

본 발명의 다른 일 측면에 따르면, (a) 트랜잭션(Transaction) 단위의 로그 정보를 생성하여 로그 파일에 기록하는 단계; (b) 장애 발생에 따라 상기 과금 게이트웨이 시스템이 재 구동되는 경우, 상기 로그 파일을 분석하여 장애 복구 대상인 로그 파일을 선택하는 단계; 및 (c) 상기 선택된 로그 파일에 저장된 상기 로그 정보를 독출하여 상기 장애 발생 이전 상태로 메모리를 복구하는 단계를 포함하되, 상기 (c) 단계는 상기 (b) 단계에서 선택된 로그 파일에 상응하는 파일 정보가 상기 로그 파일이 생성된 시간 순으로 정렬된 로그 파일 동기화 대상 로그 파일 정보 리스트를 생성하는 단계를 포함하고, 상기 정렬된 순서로 상기 로그 파일을 독출하여 상기 메모리를 복구하는 것을 특징으로 하는 이벤트 트랜잭션 로그 파일을 이용한 장애 복구 방법을 실행하는 프로그램이 기록된 기록 매체가 제공된다.

상술한 목적, 특징들 및 장점은 첨부된 도면과 관련한 다음의 상세한 설명을 통하여 보다 분명해 질 것이다. 우선 각 도면의 구성요소들에 참조 번호를 부가함 에 있어서, 동일한 구성요소들에 한해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 번호를 가지도록 하고 있음에 유의하여야 한다.

이하에서, 본 발명에 따른 과금 시스템에서 트랜잭션 로그 파일을 이용한 장애 복구 방법 및 그 장치에 관한 바람직한 실시예를 상세하게 설명한다.

도 1은 본 발명의 일 실시예에 따른 과금 게이트웨이 시스템 구성도이다.

도 1에 도시된 바와 같이, 본 발명의 바람직한 일 실시예에 따른 과금 게이트웨이 시스템(100)은 SGSN(Serving Gateway Support Node, 140) 및 GGSN(Gateway GPRS Support Node, 150)로부터 수신된 실시간 과금 기초 데이터(Charging Data Record, 이하, 'CDR'이라 함)를 수신하는 경우, 프로세스 흐름 제어(Process Flow Control), 실시간 흐름 제어(Realtime Flow Control) 및 배치 흐름 제어(Batch Flow Control) 등의 흐름 제어 모델을 수행한 후, 처리 결과를 빌링 시스템(160) 및 통계 시스템(170)에 제공하는 기능을 수행할 수 있다.

여기서, 흐름 제어 모델은 응용 비즈니스 프로세스-여기서, 응용 비즈니스 프로세스는 업무 단위 별 물리적인 데몬(Deamon) 프로세스로 구현될 수 있음-의 업무 특성에 따라 세 가지의 흐름 제어 모델 중 어느 하나가 선택적으로 수행될 수 있다.

예를 들면, 프로세스 흐름 제어 모델은 대용량 및 실시간으로 발생하는 데이터에 대한 신속한 처리를 요하는 요금관리(Mediation) 및 요금계산(Rating) 작업에 적합할 수 있다.

여기서, 요금 관리는 원시 과금 데이터를 수집하여 원시 과금 파일을 생성하거나, 생성된 원시 과금 파일을 이용하여 장애 복구를 위한 백업 파일을 생성하는 작업을 포함할 수 있다.

또한, 요금 계산은 수집된 과금 데이터, 고객 별 요율 정보-여기서, 요율 정보는 가입 상품 별 요율, 할인율 및 마일리지 적립률 등의 정보를 포함할 수 있음-를 이용하여 사용 요금을 계산하는 작업을 포함할 수 있다.

특히, 백업용 로그 파일의 생성 및 장애 발생 시 생성된 로그 파일을 이용하여 과금 데이터를 복구하는 것은 정확한 청구 요금을 산출하는데 있어서 매우 중요한 기능임은 당업자에게 자명한 사실이다.

본 발명에 따른 과금 게이트웨이(100)는 트랜잭션 단위의 과금 데이터를 실시간 수집하여, 소정의 로그 파일에 저장하고 이를 관리하는 기능 및 장애 발생 시 저장된 로그 파일을 이용하여 과금 데이터를 복구하는 방법 및 그 장치를 제공할 수 있다.

이하의 설명에서는, 본 발명의 이해를 돕기 위해, CDR을 수집, 가공 및 배포하기 위한 과금 게이트웨이(100)의 구조 및 동작 원리를 도면을 참조하여 상세히 설명하기로 한다.

본 발명의 바람직한 일 실시예에 따른 과금 게이트웨이(100)는 프로세스흐름관리부(110), 프로세스흐름관리응용프로그램인터페이스(120, 이하, '프로세스흐름관리API(Application Programming Interface)'이라 함), 응용 업무 프로세스(130) 및 로그 파일 저장부(180)을 포함할 수 있다.

여기서, 로그 파일 저장부(180)는 과금 게이트웨이(100)의 내부 또는 외부에 구비된 기록 매체로서, 프로세스흐름관리부(110)에 의해 제어될 수 있다.

프로세스흐름관리부(110)는 응용 업무 프로세스(130)의 제어 신호에 따라 세션의 설정 및 해제하는 기능, 세션 스레드(Thread) 별 할당되는 대기 행렬(Queue)을 관리하는 기능 및 장애 복구를 위한 로그 파일을 관리하는 기능을 포함할 수 있다.

본 발명에 따른 프로세스흐름관리부(110)는 응용 업무 프로세스(130)로부터 실시간 수신되는 다양한 크기의 메시지 블록을 저장하기 위해 자원의 낭비 없이 필요한 메모리를 동적으로 할당 할 수 있는 특징이 있다.

또한, 프로세스흐름관리부(110)는 공유 메모리(115)에 저장된 과금 데이터와 로그 파일 저장부(180)에 저장된 과금 데이터의 동기를 유지함으로써, 장애 발생시 장애 발생 이전의 상태로 과금 데이터를 복구할 수 있다.

또한, 프로세스흐름관리부(110)는 미리 설정된 구성 정보를 이용하여 생성된 로그 파일의 크기가 미리 설정된 크기가 되는 경우, 새로운 로그 파일을 생성하여 로그 파일 저장부(180)에 순차적으로 저장할 수 있다. 이때, 프로세스흐름관리부(110)는 로그 파일이 생성된 시간 정보를 유지하기 위해 생성된 파일의 이름에 생성 시간 정보를 포함할 수 있다.

본 발명의 일 실시예에 따른 프로세스흐름관리부(110)는 로그 파일의 저장을 위해 할당된 메모리가 풀(Full)되는 것을 방지하기 위해, 일정 주기로 로그 파일을 체크하는 체크 포인트 작업을 수행함으로써, 불필요한 로그 파일이 로그 파일 저장부(180)에 유지되는 것을 방지할 수 있다.

응용 업무 프로세스(130)는 는 프로세스흐름관리API(120)상에 미리 정의된 API를 통해서만 프로세스흐름관리부(115)에 접속할 수 있다. 즉, 응용 업무 프로세스(130)는 특정 서비스의 요청 및 메시지 블록의 처리가 필요한 경우, 미리 정의된 API를 이용하여 프로세스흐름관리API(120)에 미리 정의된 특정 함수를 호출할 수 있다. 프로세스흐름관리API(120)는 호출 함수에 상응하는 제어 메시지를 생성하여 프로세스흐름관리부(110)에 전송할 수 있다.

특히, 본 발명에 따른 과금 게이트웨이(100)는 응용 업무 프로세스(130)의 프로세스흐름관리부(110)로의 접근을 프로세스흐름관리API(120)를 통해서만 가능하게 함으로써, 불법적인 공유 메모리(115) 접근을 미연에 방지할 수 있다.

요약하면, 본 발명에 따른 응용 업무 프로세스(130)는 프로세스흐름관리부(110)에서 제공하는 서비스를 이용하여 위해서는 반드시 프로세스흐름관리API(120)에 정의된 API를 이용해야 한다.

응용 업무 프로세스(130)는 GTP(GPRS Tunneling Protocol) 인터페이스(131), ASN.1 해독기(132), AG(Aggregate, 133), 필터(Filter, 134), 상관기(Correllator, 135) 및 분배기(Distributor, 136) 프로세스를 포함할 수 있다.

GTP 인터페이스 프로세스(131)는 SGSN(140)과 GGSN(150)으로부터 GPRS 터널링 프로토콜을 통하여 CDR을 수집하는 기능 및 외부 장치(예를 들면, 스위치, 게이트웨이 및 응용 서버를 포함함)로부터 수신되는 과금 기초 데이터(예를 들면, CDR, IPDR 및 UDR를 포함할 수 있음)의 흐름을 과금 게이트웨이(100)의 부하에 따라 제어할 수 있다.

ASN.1 해독기 프로세스(132)는 ASN.1 타입으로 인코딩(Encoding)된 CDR 데이터를 디코딩(Decoding)하여 미리 정의된 표준 포맷으로 변환하는 기능을 제공할 수 있다.

AG 프로세스(132)는 ASN.1 해독기(132)를 통해 디코딩된 CDR을 소스 별로 구분하고, 하나의 소스로부터 수신된 복수의 부분 CDR을 하나의 완전한 CDR로 결합하는 기능을 제공할 수 있다.

필터 프로세스(134)는 빌링시스템(160) 또는 통계시스템(170)에 적합한 정보를 생성하기 위해, CDR에 포함된 적어도 하나의 필드 중 필요한 필드만을 필터링하는 기능을 수행할 수 있다.

상관기 프로세스(135)는 복수의 소스로부터 생성된 CDR의 상관 관계를 분석하고, 분석된 상관 관계에 따라 완전한 하나의 CDR을 생성하는 기능을 수행할 수 있다.

예를 들면, 과금 게이트웨이(100)가 하나의 세션에 속하는 CDR을 SGSN(140)과 GGSN(150)으로부터 수신하는 경우, 본 발명에 따른 상관기 프로세스(135)는 수신된 CDR의 상관 관계를 분석하여 하나의 완전한 CDR을 생성할 수 있다.

분배기 프로세스(136)는 과금 게이트웨이(100)에 의해 처리된 과금 데이터를 빌링시스템(160) 및 통계시스템(170)에 전송하는 기능을 수행할 수 있다.

특히, 응용 업무 프로세스(130)는 외부 장치로부터 수신된 CDR의 종류 및 특 성에 따라 상기한 프로세스의 일부 기능을 수행하지 않을 수 있다.

예를 들면, 외부 장치로부터 수신된 CDR이 부분 CDR이 아닌 경우, 과금 게이트웨이(100)는 AG 프로세스(133)의 기능을 수행하지 않을 수 있다. 또한, 외부 장치로부터 문자 메시지에 대응하는 CDR이 수신된 경우, 과금 게이트웨이(100)는 AG 프로세스(133) 및 상관기 프로세스(135) 기능을 수행하지 않을 수 있다.

도 2는 본 발명의 일 실시예에 따른 프로세스흐름관리부의 상세 블록도이다.

도 2를 참조하면, 본 발명에 따른 프로세스흐름관리부(200)는 세션관리부(Session Negotiator, 230), 운용 관리부(Operation/Administration & Management, 235), 메모리 관리부(Memory Manager, 240), 세션 스레드(Session Thread, 250), 대기 행렬(Queue, 260), 제어부(270), 장애 관리부(Audit Manager, 280), 장애 복구부(Audit Recovery, 285) 및 로그 파일 생성부(Audit Logger, 290) 중 적어도 하나를 포함할 수 있다.

구성 정보 저장부(245) 및 트랜잭션 로그 파일 저장부(295)는 프로세스흐름관리부(200)의 내부 또는 외부에 구비될 수 있다. 도 2에 도시된 바와 같이, 구성 정보 저장부(245)는 메모리관리부(240)와 트랜잭션 로그 파일 저장부(295)는 장애 관리부(280), 장애 복구부(285) 및 로그 파일 생성부(290)와 각각 인터페이스를 가질 수 있다.

본 발명에 따른 제어부(270)는 프로세스흐름관리API(220)를 통해 응용 프로세스(215)가 송신한 제어 메시지를 수신하는 경우, 수신된 제어 메시지를 처리하는 하부 모듈로 해당 메시지를 전달하거나 하부 모듈로부터 생성된 제어 메시지를 프로세스흐름관리API(220)에 전달하는 기능을 수행할 수 있다. 즉, 제어부(270)는 프로세스흐름관리부(200)에서의 메시지 라우터(router)로서의 기능을 수행할 수 있다.

또한, 제어부(270)는 프로세스흐름관리부(200)가 최초 시작되는 경우, 미리 정의된 순서에 따라 하부 모듈을 초기화시키는 기능을 수행할 수 있다.

여기서, 하부 모듈은 세션관리부(230), 운용관리부(235), 메모리관리부(240), 장애관리부(280), 장애복구부(285) 및 로그 파일 생성부(290)을 포함할 수 있다.

세션 스레드(250)는 응용 프로세스(215)로부터 수신되는 제어 신호에 따라, 세션 관리부(230)에 의해 실시간으로서 생성 또는 삭제될 수 있다.

대기 행렬(260)은 프로세스흐름관리부(200)의 초기화 과정에서 미리 생성되거나, 응용 프로세스(215)로부터 수신된 제어 신호(여기서, 제어 신호는 서비스 요청 신호 및 서비스 종료 신호를 포함함)에 따라 동적으로 생성 또는 삭제 될 수 있다.

본 발명에 따른 세션 스레드(250)는 대기 행렬(260)과 일대일 대응 관계가 성립될 수 있다. 예를 들면, 제 1 대기 행렬(265)는 제 1 세션 스레드(255)에 의해 관리되는 대기 행렬일 수 있다.

응용 프로그램 모듈(210)은 적어도 하나의 응용 프로세스(215) 및 각각의 응용 프로세스(215)에 상응하는 프로세스흐름관리API(220)를 포함할 수 있다.

도 2를 참조하면, 응용 프로세스(215)별 프로세스흐름관리API(220)가 일대일로 대응하는 것으로 도시되어 있으나, 본 발명의 다른 일 실시예에 따른 프로세스흐름관리부(220)는 응용 프로그램 모듈(210)내에서 하나만 존재하고 모든 응용 프로세스가 공유하는 구조를 가질 수도 있음을 주의해야 한다.

응용 프로세스(215)는 프로세스흐름관리API(220)를 통해서만 프로세스흐름관리부(200)에 접근할 수 있으며, 응용 프로세스(215)와 프로세스흐름관리부(200)와의 메시지 전달은 유닉스(Unix) 시스템에서 제공하는 두 개의 IPC(Interprocess Communication)를 통해 수행될 수 있다.

예를 들면, 제어 메시지-여기서, 제어 메시지는 서비스 요청 및 해제 메시지를 포함할 수 있음-는 유닉스 도메인에서 제공하는 소켓(Socket) 통신을 이용하며, 실제적인 데이터 메시지는 유닉스 공유 메모리(225)를 이용하여 통신할 수 있다. 즉, 응용 프로세스(215)는 데이터 메시지를 저장/검색/삭제하기 위해 사용하는 제어 메시지-여기서, 제어 메시지는 미리 정의된 API인 PUT/GET 등의 함수를 이용할 수 있음-를 소켓 도메인을 이용하여 프로세스흐름관리부(200)에 전송할 수 있다.

만약, 프로세스흐름관리API(220)가 응용프로세스(215)로부터 처리 완료된 데이터 메시지의 저장을 위한 제어 메시지-여기서, 제어 메시지는 저장할 데이터 메시지의 시작 주소 및 길이 정보를 포함할 수 있음-를 수신하는 경우, 프로세스흐름관리API(220)는 수신된 주소 정보 및 길이 정보를 참조하여 응용프로세스(215)에 할당된 공유 메모리에 해당 데이터 메시지를 저장할 수 있다.

세션 스레드(255)는 저장된 데이터 메시지에 대한 블록 정보-여기서, 블록 정보는 고유한 메시지 식별자, 공유 메모리 상에서의 메시지 시작 주소 및 메시지 길이 정보를 포함할 수 있음-를 생성하여 응용 프로세스(215)에 할당된 대기 행렬(265)에 저장할 수 있다.

이후, 프로세스 간 데이터 메시지의 송수신은 대기 행렬(265)에 저장된 블록 정보를 이용하여 수행될 수 있다.

본 발명의 일 실시예에 따른 세션 스레드(255)는 특정 메시지를 로그 파일에 삽입하거나 삭제하기 위해 적어도 하나의 블록 정보를 포함하는 트랜잭션 이벤트를 로그 파일 생성부(290)에 송신할 수 있다.

여기서, 트랜잭션 이벤트는 삽입 이벤트, 삭제 이벤트 중 어느 하나일 수 있다.

만약, 로그 파일 생성부(290)가 유닉스 공유 메모리(225)상에 새롭게 저장된 데이터 메시지를 이벤트 트랜잭션 로그 파일-이하의 설명에서는 이벤트 트랜잭션 로그 파일을 로그 파일과 혼용해서 사용하나 동일한 의미로 사용됨을 주의해야 함-에 저장하기 위해, 적어도 하나의 블록 정보를 포함하는 삽입 이벤트-여기서, 삽입 이벤트는 로그 생성 요청 신호를 이용할 수 있음-를 세션 스레드(250)로부터 수신하는 경우, 로그 파일 생성부(290)는 수신된 블록 정보에 상응하는 데이터 메시지를 공유 메모리로부터 획득한다. 이후, 로그 파일 생성부(290)는 획득된 데이터 메시지 및 메시지 식별자를 포함하는 로그 정보를 로그 파일에 기록할 수 있다.

특히, 본 발명에 따른 로그 파일 생성부(290)는 메시지 식별자 별 로그 파일로의 연결 정보를 소정의 해쉬 테이블에 등록한다. 이후, 로그 파일 생성부(290)는 해당 로그 파일에 삽입된 데이터 메시지의 개수를 가리키는 메시지 카운터를 증가시킬 수 있다.

또한, 해쉬 테이블은 트랜잭션 로그 파일 저장부(295)에 유지될 수 있다.

여기서, 해쉬 테이블은 적어도 하나의 해쉬 노드(Hash Node)를 포함하며, 각각의 해쉬 노드는 메시지 식별자, 메시지 식별자에 상응하는 로그 정보가 기록된 로그 파일 식별자, 로그 파일상에 로그 정보가 기록된 위치 정보 -여기서, 위치 정보는 로그 파일상에서의 해당 로그 정보의 시작 라인(line) 및 로그 정보가 기록된 메모리 상의 물리적인 주소 중 어느 하나일 수 있음-, 로그 정보의 크기 중 적어도 하나를 포함할 수 있다.

본 발명의 일 실시예에 따른 해쉬 테이블은 트랜잭션 로그 파일 저장부(295)에 유지될 수 있다.

반면, 로그 파일 생성부(290)가 처리 완료된 메시지-여기서, 처리 완료된 메시지는 소정의 처리 절차를 거쳐 빌링 시스템(160) 및 통계 시스템(170)에 전송된 메시지를 의미할 수 있음-를 로그 파일로부터 삭제하기 위한 적어도 하나의 블록 정보를 포함하는 삭제 이벤트-여기서, 삭제 이벤트는 로그 삭제 요청 신호를 이용할 수 있음-를 세션 스레드(250)로부터 수신할 수 있다. 이때, 로그 파일 생성부(290)는 수신된 블록 정보에 상응하는 로그 정보가 기록된 로그 파일을 해쉬 테이블을 통해 찾은 후, 해당 로그 정보를 로그 파일로부터 삭제한다. 이후, 로그 파일 생성부(290)는 메시지 카운터를 감소시킬 수 있다.

또한, 로그 파일 생성부(290)는 삭제된 로그 정보에 상응하는 해쉬 노드를 해쉬 테이블에서 삭제할 수 있다.

운용 관리자는 운용관리부(235)가 제공하는 소정의 사용자 인터페이스를 통해 프로세스/자원/망의 상태 관리, 통계 및 분석, 장애 관리 및 구성 정보 관리 기능을 수행할 수 있다.

메모리 관리부(240)는 제어부(270)의 제어 신호에 따라, 구성 정보 저장부(245)로부터 시스템 구성 정보를 획득하여 메모리 초기화 작업을 수행하거나, 응용 프로세스(215) 별 할당된 공유 메모리 및 대기 행렬(265)의 재할당 기능을 수행할 수 있다.

본 발명의 일 실시예에 따른 메모리 관리부(240)는 장애 발생 후 시스템이 다시 구동되는 경우, 장애 복구부(285)와 연동하여 복구 대상 로그 파일의 존재 여부를 판단할 수 있다. 만약, 복구 대상 로그 파일이 존재하는 경우, 메모리 관리부(240)는 복구 대상 로그 파일 리스트를 파일이 생성된 순서로 생성할 수 있다.

장애 관리부(280)는 시스템 운용 중 발생하는 장애를 감지하고 이를 제어하는 기능을 수행한다.

예를 들면, 본 발명의 일 실시예에 따른 장애 관리부(280)는 시스템의 장애를 감지하는 경우, 소정의 비 휘발성 기록 영역에 장애 내역(Fault Inventory)을 기록할 수 있다.

만약, 시스템이 재 구동되는 경우, 메모리 관리부(240)는 장애 내역을 독출한 후 장애 복구부(285)에 장애 복구를 위한 소정의 제어 신호를 송신할 수 있다.

여기서, 장애 내역은 장애 식별 코드, 장애 발생 시간 등의 정보를 포함할 수 있다.

장애 복구부(285)는 장애 발생 후 재 구동 시 메모리 관리부(240)의 제어 신호에 따라 트랜잭션 로그 파일 저장부(295)에 저장된 로그 파일을 추출하여, 장애를 복구하는 기능을 수행한다.

본 발명의 일 실시예에 따른 장애 관리부(280)는 유효한 로그 파일을 관리하기 위해 소정의 로그 파일 리스트-여기서, 로그 파일 리스트는 미리 정의된 자료 구조 및 구성 정보에 따라 트랜잭션 로그 파일 저장부(295)에 저장될 수 있음-를 관리하는 기능을 수행할 수 있다.

예를 들면, 장애 관리부(280)는 로그 파일 별 할당된 메시지 카운터의 값이 0인 경우, 해당 로그 파일을 트랜잭션 로그 파일 저장부(295)로부터 삭제할 수 있다. 이때, 장애 관리부(280)는 로그 파일 리스트에서 삭제된 로그 파일에 대한 정보를 삭제해야 한다.

여기서, 메시지 카운터는 로그 파일에 포함된 장애 복구 대상 메시지-여기서, 장애 복구 대상 메시지는 장애 발생 시 복구가 필요한 메시지를 의미함-의 개수 정보를 저장하기 위한 변수일 수 있다.

예를 들면, 로그 파일 생성부(290)는 세션 스레드(250)로부터 삽입 이벤트를 수신하는 경우 메시지 카운터를 증가시킬 수 있다. 반면, 로그 파일 생성부(290)가 세션 스레드(250)로부터 삭제 이벤트를 수신하는 경우 메시지 카운터를 감소시킬 수 있다.

로그 파일 생성부(290)는 세션 스레드(250)로부터 수신되는 제어 신호에 따 라 새로운 로그 파일을 생성할 수 있으며, 생성된 로그 파일에 관한 정보를 장애 관리부(280)에 제공할 수 있다.

만약, 장애 관리부(280)가 로그 파일 생성부(290)로부터 새롭게 생성된 로그 파일에 대한 정보를 수신하는 경우, 장애 관리부(280)는 로그 파일 리스트에 생성된 로그 파일에 대한 정보를 추가할 수 있다.

여기서, 생성된 로그 파일은 트랜잭션 로그 파일 저장부(295)에 저장되며,.로그 파일 생성부(290)는 세션 스레드(250)로부터 수신된 제어 신호-여기서, 제어 신호는 로그 생성 요청 신호 및 로그 갱신 요청 신호를 포함할 수 있음-에 따라, 해당 로그 파일에 로그 정보를 추가 또는 삭제할 수 있다.

본 발명의 일 실시예에 따른 세션 스레드(250)는 과금 게이트웨이(100)의 처리 성능을 높이기 위해 트랜잭션 단위-여기서, 트랜잭션은 동일 소스 또는 동일 서비스에 상응하여 생성된 메시지의 집합일 수 있음-로 로그 생성 요청 신호 및 로그 갱신 요청 신호를 로그 파일 생성부(290)에 전송할 수 있다.

일반적으로, 응용 프로세스(215)에서 생성되는 데이터 메시지의 크기가 큰 경우(256Kbyte 이상인 경우를 포함함), 소켓을 통한 데이터 메시지의 전송은 잦은 메모리 카피에 따른 프로세서 처리 부하뿐만 아니라 프로세스 간 많은 데이터 전송으로 인해 데이터 전송 부하를 발생시킬 수 있다. 즉, 전체적인 과금 게이트웨이(100)의 처리 효율이 떨어지는 문제점이 있다.

본 발명은 상기와 같은 문제점을 해결하기 위한 본 발명은 특정 이벤트의 발생은 소켓 통신을 통해 수행하고, 실제적인 데이터 메시지의 송/수신은 유닉스 공 유 메모리(225)를 이용함으로써, 응용 프로세스(215)와 프로세스흐름관리부(200)가 공유 메모리를 사용하는데 있어서, 충돌 방지를 위한 별도의 세마포어(Semaphore)나 로킹(Locking) 기능을 추가하지 않아도 되는 장점이 있다.

본 발명의 일 실시예에 따른 프로세스흐름관리부(200)는 공유 메모리에 저장된 데이터 메시지를 다른 응용 프로세스에 전달해야 하는 경우, 대기 행렬 및 프로세스 블록을 이용한 메모리 포인터 전달 방식을 이용하므로, 시스템 자원-여기서, 시스템 자원은 메모리, CPU 및 전송 버스를 포함할 수 있음-의 사용을 줄이는 효과가 있다.

본 발명의 일 실시예에 따른 유닉스 공유 메모리(225) 구조는 응용 프로세스(215)와 프로세스흐름관리부(220) 사이의 메시지 송수신에 필요한 제어 정보를 저장하는 프로세스 블록과 실제적인 데이터 메시지 저장에 이용되는 비교적 작은 크기를 갖는 연속적인 데이터 블록-예를 들면, 1킬로바이트(Kbyte)의 크기가 될 수 있음-으로 구성된 메시지 블록으로 구성될 수 있다.

여기서, 프로세스 블록과 데이터 블록의 사이즈 및 개수는 사용자의 설정에 따라 변경될 수 있음을 주의해야 한다.

프로세스 블록은 응용 프로세스(215)의 정보와 프로세스흐름관리API(220)에서 데이터 메시지를 읽거나 쓰기 위해 필요한 메시지 블록의 주소 정보를 포함할 수 있다.

메시지 블록은 두 개의 연결 리스트(Linked List)로 구성될 수 있다, 각각은 현재 메시지 전송에 사용중인 데이터 블록을 위한 할당 리스트(Allocate List)와 가용한 데이터 블록을 위한 비 할당 리스트(Reserved List)일 수 있다

예를 들면, 만약 메모리관리부(240)가 프로세스흐름관리API(220)로부터 데이터 메시지 전송을 위한 메모리 요청 신호를 수신하는 경우, 메모리관리부(240)는 필요한 만큼의 메모리를 비 할당 리스트에서 할당하고, 할당된 메모리 주소 정보를 프로세스흐름관리API(220)에 제공할 수 있다. 이때, 할당된 메모리에 상응하는 데이터 블록은 할당 리스트로 이동된다.

만약, 메모리관리부(240)가 프로세스흐름관리API(220)로부터 특정 데이터 블록의 삭제 요청 메시지를 수신하는 경우, 해당 데이터 블록을 할당 리스트로부터 비 할당 리스트에 이동시킨다.

다음은 본 발명의 일 실시예에 따른 1킬로바이트 크기를 갖는 데이터 블록의 자료 구조이다.

Typedef struct

{

ME_ADDR_T next_;

int32_t length_;

} ME_STShmDataHeader;

Typedef struct

{

ME_STShmDataHeader header_;

char data_[1024-sizeof(ME_STShmDataHeader)];

} ME_STShmDataBlock;

상기한 자료 구조와 같이, 하나의 데이터 블록은 소정의 헤더(header)와 캐랙터(char) 타입의 데이터를 포함할 수 있다.

여기서, 헤더는 연결 리스트 상의 다음 데이터 블록의 주소를 가리키는 next_필드와 데이터의 길이를 가리키는 length_필드를 포함할 수 있다.

이상의 자료 구조를 통해, 본 발명에 따른 프로세스흐름관리부(200)는 응용 프로세스(215)의 데이터 전송에 필요한 메모리를 효과적으로 할당할 수 있다.

도 3은 본 발명의 일 실시예에 따른 프로세스흐름관리부의 초기화 절차를 도시한 순서도이다.

과금 게이트웨이(100)가 기동되면 프로세스흐름관리부(200)는 서비스 제공을 위한 하부 모듈의 초기화 작업을 시작한다(S300).

본 발명의 일 실시예에 따른 프로세스흐름관리부(200)에 탑재되는 프로그램은 기능 및 특성에 따라 복수의 태스크로 모듈화되어 구성될 수 있다. 이때, 시스템의 하부 모듈을 제어하는 태스크(이하, '제어 태스크'이라 함)가 존재할 수 있으며, 제어 태스크는 시스템의 부팅 및 프로그램 로딩이 완료되면, 최초로 실행되어 시스템의 하부 모듈의 초기화를 수행할 수 있다.

본 발명의 다른 일 실시예에 따르면, 시스템에 전원이 인가된 후 시스템의 부팅 및 프로그램 로딩이 완료되면, 프로세스흐름관리부(200)에 탑재되는 하부 모 듈의 초기화에 필요한 인련의 절차를 정형화된 프로그램 언어로 구현한 초기화 프로그램-여기서, 초기화 프로그램은 사용자 정의된 함수일 수 있음-이 호출될 수 있다.

이하의 설명에서는 하부 모듈의 초기화를 도 2에 도시된 제어부(270)에 상응하는 태스크에서 수행하는 것으로 설명하나 반드시 이에 한정되지 않음을 주의해야 한다.

메모리 관리부(240)는 제어부(270)의 제어 신호에 따라 메모리 관리부(240)의 초기화 절차를 수행한다, 여기서, 메모리 관리부(240)의 초기화 절차는 공유 메모리를 초기화하는 단계(S310)와 대기 행렬을 초기화하는 단계(S320)를 포함할 수 있다.

여기서, 공유 메모리를 초기화 하는 단계는 메모리 관리부(240)가 구성 정보 저장부(245)로부터 공유 메모리의 구성 정보를 추출하는 단계 및 추출된 공유 메모리 구성 정보를 참조하여 프로세스 블록과 데이터 블록을 초기화하는 단계를 포함할 수 있다.

대기 행렬 초기화 단계는 메모리 관리부(240)가 구성 정보 저장부(245)로부터 대기 행렬의 구성 정보를 추출하는 단계 및 추출된 대기 행렬 구성 정보를 참조하여 데이터 메시지 정보를 저장하기 위한 대기 행렬을 생성하고 생성된 대기 행렬을 대기 행렬 리스트에 등록하는 단계를 포함할 수 있다.

여기서, 데이터 메시지 정보는 데이터 메시지 별로 고유하게 부여되는 메시지 식별자 필드, 메시지 길이 필드 및 공유 메모리상에 저장된 데이터 블록의 시작 주소 필드를 포함할 수 있다.

장애 복구부(285)는 제어부(270)의 제어 신호에 따라, 소정의 기록 매체-여기서, 기록 매체는 트랜잭션 로그 파일 저장부(295)일 수 있음-에 저장된 이벤트 로그 파일을 분석하여 장애 복구가 필요한지 판단한다(S330).

여기서, 이벤트 로그 파일은 시스템 운용 중 발생된 알람(Alram) 및 장애(Fault) 보고를 기록하기 위한 인벤토리 파일(Inventory file)로서, 추후, 알람 및 장애의 원인을 분석하기 위한 정보로 사용될 수 있다.

판단 결과, 복구가 필요한 경우, 장애 복구부(285)는 처리가 종료되지 않은 데이터 메시지를 해당 로그 파일로부터 추출하여, 공유 메모리상의 데이터 블록에 추출된 데이터 메시지를 기록하고, 기록된 데이터 메시지에 상응하는 데이터 메시지 정보를 해당 대기 행렬에 등록한다(S340).

상기한 330 단계에 있어서, 복구가 필요하지 않은 경우, 제어부(270)는 로그 파일을 관리하는 장애 관리부(280) 스레드를 생성한다(S350).

제어부(270)는 응용 프로세스의 요청에 따라 세션을 설정하거나 삭제하는 기능을 수행하는 세션 관리부(230) 스레드를 생성한 후(S360), 응용 프로세스 접속 대기 상태로 천이한다(S370).

도 4는 본 발명의 일 실시예에 따른 세션 관리부의 동작을 도시한 순서도이다.

도 4에 도시된 바와 같이, 세션 관리부(230) 스레드-이하의 설명에서는 세션 관리부(230) 스레드를 세션 관리부(230)라 명하기로 함-가 기동되면(400), 세션 관리부(230)는 제어 메시지의 수신 여부를 주기적으로 확인한다(S410).

확인 결과, 수신된 제어 메시지가 존재하는 경우, 세션 관리부(230)는 수신된 제어 메시지가 응용 프로세스로부터 수신된 접속 요청 신호인지 판단한다(S420).

판단 결과, 접속 요청 신호인 경우, 세션 관리부(230)는 해당 응용 프로세스에 상응하는 세션 스레드를 생성하고(S430), 생성된 세션 스레드 정보를 세션 리스트에 등록한다(S440).

여기서, 접속 요청 신호는 소정의 응용 프로세스 식별자를 포함할 수 있으며, 생성된 세션 스레드와 해당 응용 프로세스는 응용 프로세스 식별자를 이용하여 일대일 통신을 수행할 수 있다.

상기한 420 단계에서, 판단 결과, 접속 요청 신호가 아닌 경우, 세션 관리부(230)는 수신된 제어 메시지가 응용 프로세스로부터 수신된 세션 종료 요청 신호인지 판단한다(420).

판단 결과, 세션 종료 요청 신호인 경우, 세션 관리부(230)는 해당 응용 프로세스에 상응하는 세션 스레드를 세션 리스트로부터 삭제한 후(S460), 응용 프로세스 접속 대기 상태로 천이한다(S470).

본 발명의 일 실시예에 따른 세션 관리부(230)는 세션 리스트에 포함된 세션 스레드의 상태를 체크하여, 활성(Active), 정지(Stop) 중 어느 하나의 상태로 설정할 수 있다.

여기서, 활성 상태는 세션 스레드의 동작이 정상임을 의미하고, 정지 상태는 세션 스레드가 비정상적으로 종료되었음을 의미한다.

세션 관리부(230)는 주기적으로 세션 리스트에 포함된 세션 스레드의 상태 정보를 조회하여, 정지 상태인 세션 스레드를 세션 리스트로부터 삭제할 수 있다.

도 5는 본 발명의 일 실시예에 따른 응용 프로세스가 요청한 서비스를 초기화하는 방법을 도시한 순서도이다.

도 5에 도시된 바와 같이, 세션 스레드의 동작이 시작되면, 세션 스레드는 응용 프로세스로부터 패킷이 수신되었는지 확인한다(S510).

확인 결과, 패킷이 수신된 경우, 세션 스레드는 수신된 패킷이 서비스 개시 요구 메시지인지 확인한다(S520).

확인 결과, 서비스 개시 요구 메시지인 경우, 세션 스레드는 요청된 서비스의 개시가 가능한지 여부를 판단한다(S530).

여기서, 서비스 개시 가능 여부의 판단은 구성 정보 저장부(245)에 해당 응용 프로세스에 상응하는 대기 행렬의 등록 여부와 해당 응용 프로세스에 상응하는 서비스 개시 요구가 이미 수신되었는지 여부를 판단하는 절차를 포함할 수 있다.

상기한 530 단계에서, 서비스 개시가 가능한 경우, 세션 스레드는 서비스 초기화 작업 및 해당 응용 프로세스에 서비스 개시 요청에 대한 응답 메시지를 송신한다(S540).

여기서, 서비스 초기화 작업은 메모리 관리부(240)로부터 공유 메모리 상의 프로세스 블록을 할당 받는 단계 및 해당 응용 프로세스에 상응하는 대기 행렬을 할당 받는 단계를 포함할 수 있다.

만약, 서비스 초기화 작업이 성공한 경우, 세션 스레드는 할당된 프로세스 블록의 상대 주소를 포함하는 응답 메시지를 해당 응용 프로세스에 송신할 수 있다.

여기서, 상대 주소는 할당된 공유 메모리의 절대적인 시작 주소(이하, '베이스 주소(Base Address)'이라 함)에 상대적인 오프셋(Offset) 주소 값일 수 있다.

만약, 서비스 초기화 작업을 수행하는 과정에서 오류가 발생한 경우, 세션 스레드는 소정의 오류 코드-여기서, 오류 코드는 할당 가능한 프로세스 블록이 존재하지 않음을 의미하는 코드를 포함할 수 있음-를 포함하는 응답 메시지를 해당 응용 프로세스에 송신할 수 있다.

상기한 530 단계에서 서비스 개시가 불가능한 것으로 판단된 경우, 세션 스레드는 해당 응용 프로세스에 오류 응답 메시지를 송신할 수 있다(S550).

세션 스레드는 서비스 개시 요청 메시지에 상응하는 성공 응답 메시지의 송신 시 소켓 오류-여기서, 소켓 오류는 세션 스레드와 응용 프로세스 사이의 IPC 통신이 불가능함을 의미함-의 발생 여부를 판단한다(S560).

판단 결과, 소켓 오류가 발생하지 않은 경우. 세션 스레드는 요청된 서비스를 개시한다(S570).

상기한 560 단계에서, 소켓 오류가 발생한 경우, 세션 스레드는 세션 스레드를 종료할 수 있다(S590).

상기한 520 단계에 있어서, 수신된 패킷이 서비스 개시 요구 메시지가 아닌 경우, 세션 스레드는 소켓 에러의 발생 여부를 판단한다(S580).

판단 결과, 소켓 오류가 발생하지 않은 경우, 세션 스레드는 상기한 510 단계를 수행한다. 반면, 소켓 오류가 발생한 것으로 판단된 경우, 세션 스레드는 상기한 590 단계를 수행한다.

본 발명의 일 실시예에 따른 세션 스레드를 종료하는 방법은 해당 세션 스레드가 자신의 동작을 중지하고 할당된 메모리를 반환하는 단계, 해당 세션 스레드가 세션 스레드 종료 보고 메시지를 세션 관리부(230)에 송신하는 단계 및 세션 관리부(230)가 세션 스레드 종료 보고 메시지를 송신한 세션 스레드에 상응하는 정보를 세션 리스트에서 삭제하는 단계를 포함할 수 있다.

도 6은 본 발명의 일 실시예에 따른 응용 프로세스가 요청한 서비스를 초기화하는 과정을 도시한 흐름도이다.

도 6을 참조하면, 응용 프로세스(215)는 프로세스흐름관리부(200)의 서비스를 제공받기 위해 프로세스흐름관리 접속 요구 신호를 프로세스흐름관리API(220)에 송신한다(S602).

프로세스흐름관리API(220)는 응용 프로세스(215)가 프로세스흐름관리부(200)에 의해 설정된 공유 메모리로의 접근에 필요한 베이스 주소를 획득한 후(S604), 프로세스흐름관리 접속 응답 신호를 응용 프로세스(215)에 송신한다(S806).

프로세스흐름관리API(220)가 응용 프로세스(215)로부터 서비스 개시 요구 신 호를 수신하는 경우(S608), 프로세스흐름관리API(220)는 유닉스 도메인 소켓을 클라이언트 모드로 전환시킨다(S610).

유닉스 도메인 소켓이 클라이언트 모드로 설정되는 경우, 응용 프로세스(215)는 프로세스흐름제어관리부(200)에 접속할 수 있으며, 클라이언트-서버 구조로 동작할 수 있다. 여기서, 클라이언트는 응용 프로세스(215)이고, 서버는 프로세스흐름제어관리부(200)가 될 수 있다.

만약 세션 관리부(230)가 프로세스흐름관리API(220)로부터 소켓 연결 요구 신호를 수신하면(S612), 세션 관리부(230)는 세션 스레드(250)를 생성하고 생성된 세션 스레드에 대한 정보를 세션 리스트에 등록할 수 있다(S614).

이후, 세션 관리부(230)는 생성된 세션 스레드에 상응하는 소정의 세션 식별자를 포함하는 소켓 연결 응답 신호를 프로세스흐름관리API(220)에 송신한다(S616).

프로세스흐름관리API(220)는 상기 614 단계에서 설정된 세션 스레드(250)에 세션 식별자를 포함하는 세션 개시 요구 신호를 송신한다(S618).

만약, 세션 스레드(250)가 세션 개시 요구 신호를 수신하면, 세션 스레드(250)는 메모리 관리부(240)에 의해 할당된 대기 행렬을 바인딩(binding)하고, 메모리 관리부(240)로부터 프로세스 블록을 할당 받아 설정한다(S620).

이후, 세션 스레드(250)는 세션 식별자, 대기 행렬 바인딩 식별자, 프로세스블록 상대 주소 중 적어도 하나를 포함하는 세션 개시 응답 신호를 프로세스흐름관리API(220)에 송신한다(S622).

프로세스흐름관리API(220)는 미리 정의된 변수에 수신된 프로세스 블록의 상대 주소 값을 설정한 후(S624), 세션 식별자를 포함하는 서비스 개시 응답 신호를 응용 프로세스(215)에 송신한다(S626).

이후, 응용 프로세스(215)는 수신된 세션 식별자를 이용하여 세션 스레드(250)와 일대일 통신을 수행할 수 있다.

본 발명의 다른 일 실시예에 따른 프로세스흐름관리API(220)는 응용 프로세스와 해당 응용 프로세스에 상응하여 할당된 세션 스레드를 위한 세션 식별자의 매핑 테이블을 유지함으로써, 서비스 개시 응답에 세션 식별자를 포함하지 않을 수 있다.

즉, 응용 프로세스가 세션 식별자를 몰라도 프로세스흐름관리API(220)는 매핑 테이블을 이용하여 수신된 제어 신호를 해당 세션 스레드로 전달할 수 있다.

도 7은 본 발명의 일 실시예에 따른 프로세스흐름관리부에서 응용 프로세스의 메시지 삽입 요청을 처리하는 절차를 도시한 흐름도이다.

도 7을 참조하면, 프로세스흐름관리API(220)가 응용 프로세스(215)로부터 데이터 및 데이터의 길이 정보를 포함하는 메시지 저장 요구 신호를 수신하는 경우(S702), 프로세스흐름관리API(220)는 수신된 데이터를 저장하기 위해 필요한 데이터 블록 페이지가 예약된 프로세스 블록에 존재하는지 확인한다(S704).

여기서, 필요한 데이터 블록 페이지는 수신된 데이터 길이를 미리 정의된 데이터 블록의 크기(예를 들면, 본 발명의 일 실시예에 따른 데이터 블록의 크기는 1Kbyte에서 데이터 블록의 헤더 사이즈를 차감한 값일 수 있음)로 나눈 몫에 1을 더한 값일 수 있다.

확인 결과, 필요한 데이터 블록이 존재하지 않는 경우, 프로세스흐름관리API(220)는 수신된 데이터 길이 정보를 포함하는 데이터 블록 할당 요구 신호를 세션 스레드(250)에 송신한다(S706).

세션 스레드(250)는 기존에 할당된 데이터 블록 페이지를 반환한 후 메모리 관리부(240)로부터 필요한 데이터 블록을 재할당 받는다(S708). 세션 스레드(250)는 재할당된 데이터 블록에 상응하는 상대 주소를 계산하고(S710), 계산된 상대 주소를 포함하는 데이터 블록 할당 응답 신호를 프로세스흐름관리API(220)에 송신한다(S712).

프로세스흐름관리API(220)는 수신된 상대 주소에 데이터를 저장한 후(S714), 메시지 저장 응답 신호를 응용 프로세스(215)에 송신한다(S716).

프로세스흐름관리API(220)는 응용 프로세스(215)로부터 실행 요구 신호를 수신하는 경우(S718), 수신된 실행 요구 신호를 세션 스레드(250)에 전달한다(S720).

만약 세션 스레드(250)가 실행 요구 신호를 수신하면, 세션 스레드(250)는 상기 714 단계에서 저장된 데이터에 대응하는 메시지 식별자 및 메시지 정보 구조체를 생성한다(S722).

여기서, 메시지 식별자는 공유 메모리의 프로세스 블록에 저장된 데이터 블록 정보를 대기 행렬에 등록하기 위해 메시지 별로 고유하게 할당되는 식별자이다.

메시지 정보 구조체는 메시지 식별자, 데이터의 길이 및 데이터가 기록된 공 유메모리상의 상대 주소를 포함할 수 있다.

로그 파일 생성부(290)는 메시지 정보 구조체를 포함하는 로그 생성 요구 신호를 세션 스레드(250)로부터 수신하는 경우, 소정의 로그 파일에 메시지 정보 구조체에 상응하는 정보를 저장한다(S726).

본 발명의 일 실시예에 따른 로그 생성 요구 신호는 메시지의 삽입 또는 삭제를 지시하는 제어 식별자를 포함할 수 있으며, 로그 파일 생성부(290)는 수신된 제어 식별자에 따라, 메시지 정보 구조체에 상응하는 메시지를 삽입 또는 삭제할 수 있다.

세션 스레드(250)는 로그 파일 생성부(290)로부터 로그 생성 응답 신호를 수신하면(S730), 기 생성된 메시지 정보 구조체를 대기 행렬 연결 리스트의 마지막 노드에 추가한 후(S730), 추후 응용 프로세스(215)로부터 수신될 메시지 저장 요구 신호를 처리하기 위한 소정의 데이터 블록 페이지를 메시지 관리부(240)로부터 획득한다(S732).

세션 스레드(250)는 획득된 데이터 블록 페이지의 상대 주소를 계산한 후(S734), 계산된 상대 주소 및 데이터 블록 페이지의 개수 정보를 포함하는 실행 응답 신호를 프로세스흐름관리API(220)에 송신한다(S736).

프로세스흐름관리API(220)는 수신된 상대 주소 및 데이터 블록 페이지의 개수 정보를 이용하여, 프로세스 블록 정보를 갱신한 후(S738) 실행 응답 신호를 응용 프로세스(215)에 송신한다(S740).

만약, 상기한 704 단계에서, 필요한 데이터 블록 페이지가 존재하는 경우, 프로세스흐름관리API(220)는 수신된 데이터를 공유 메모리에 저장한 후 소정의 응답 메시지를 응용 프로그램(215)에 송신할 수 있다. 이후, 상기한 718 내지 740 단계가 순차적으로 수행될 수 있다.

본 발명의 일 실시예에 따르면, 세션 스레드(250)는 재할당할 데이터 블록 페이지를 메모리 관리부(240)으로부터 획득할 수 없는 경우, 공유 메모리가 풀(Full) 상태임을 지시하는 데이터 블록 할당 응답 신호를 프로세스흐름관리API(220)에 송신할 수 있다. 이후, 프로세스흐름관리API(220)는 응답 결과가 재시도(AGAIN)인 메시지 저장 응답 신호를 응용 프로세스(215)에 송신할 수 있다.

여기서, 재시도는 다른 응용 프로세스가 데이터 블록 페이지를 반환할 때까지 일정 시간 동안 대기한 후 다시 메모리 저장을 시도하라는 의미로 사용될 수 있다.

본 발명의 다른 일 실시예에 따르면, 프로세스흐름관리API(220)는 트랜잭션 단위로 데이터를 처리하기 위해, 응용 프로세스(215)로부터 수신된 복수의 데이터 메시지를 공유 메모리에 버퍼링한 후, 실행 요구 신호를 수신하면, 버퍼링된 데이터 메시지에 대한 정보를 대기 행렬에 반영할 수 있다.

즉, 프로세스흐름관리부(200)는 상기한 702 단계 내지 716 단계를 여러 번 반복 수행한 후, 공유 메모리상에 버퍼링 된 데이터를 트랜잭션 단위로 한번에 처리함으로써, 프로세스 간의 잦은 문맥 전환(context switching)에 의한 처리 효율이 떨어지는 것을 방지할 수 있다.

도 8은 본 발명의 일 실시예에 따른 프로세스흐름관리부에서 응용 프로세스의 메시지 추출 및 삭제 요청을 처리하는 절차를 도시한 흐름도이다.

도 8을 참조하면, 프로세스흐름관리API(220)가 응용 프로세스(215)로부터 메시지 추출 요구 신호를 수신하는 경우(S802), 프로세스흐름관리API(220)는 메시지 읽기(Read) 요구 신호를 세션 스레드(250)에 송신한다(S804).

세션 스레드(250)는 응용 프로세스(215)에 할당된 대기 행렬 연결 리스트의 첫번째 노드에서 메시지 정보 구조체를 추출한 후, 응용 프로세스(215)에 할당된 프로세스 블록에 추출된 메시지 정보 구조체를 기록한다(S806).

만약, 프로세스흐름관리API(220)가 세션 스레드(250)으로부터 패킷 응답 신호를 수신하는 경우(S808), 프로세스 블록의 정보를 참조하여, 데이터 블록에 저장된 데이터를 사용자 버퍼에 복사한 후(S810), 복사된 데이터 및 메시지 식별자를 포함하는 메시지 추출 응답 신호를 응용 프로세스(215)에 송신한다(S812).

응용 프로세스(215)는 수신된 메시지에 대한 처리가 완료하면(S814), 메시지 식별자 및 삭제 플래그(Flag)를 포함하는 메시지 삭제 요구 신호를 프로세스흐름관리API(220)에 송신한다(S816).

프로세스흐름관리API(220)는 프로세스 블록에 삭제할 메시지 정보를 설정한 후(S818), 메시지 삭제 응답 신호를 응용 프로세스(S215)에 송신한다(S820).

프로세스흐름관리API(220)는 응용 프로세스(215)로부터 실행 요구 신호-여기서, 실행 요구 신호는 메시지 식별자를 포함할 수 있음-를 수신하면, 수신된 실행 요구 신호를 세션 스레드(250)에 전달한다(S824).

세션 스레드(250)는 로그 파일에 기록된 메시지-여기서, 메시지는 삭제 요청된 메시지임-를 삭제하기 위해 메시지 정보를 포함하는 로그 삭제 요구 신호를 로그 파일 생성부(290)에 송신한다(S826).

로그 파일 생성부(290)는 로그 파일에서 해당 메시지를 삭제한 후(S928), 로그 삭제 응답 신호를 세션 스레드(250)에 송신한다(S830).

세션 스레드(250)는 삭제 요청된 메시지에 상응하여 대기 행렬 리스트에 저장된 메시지 정보 및 공유 메모리에 저장된 데이터 블록을 삭제한 후(S832) 실행 응답 신호를 프로세스흐름관리API(220)에 송신한다(S834).

이후, 프로세스흐름관리API(220)는 실행 응답 신호를 응용 프로세스(215)에 송신함으로써(S836), 메시지 추출 및 삭제 절차를 종료한다.

본 발명의 일 실시예에 따른 프로세스흐름관리부(200)는 트랙잭션 단위의 처리를 지원하기 위해, 상기한 802 단계 내지 820 단계를 반복 수행한 후, 응용 프로세스(215)로부터 실행 요구 신호를 수신하면, 반복 수행된 결과를 공유 메모리, 대기 행렬 및 로그 파일에 반영할 수 있다.

도 9는 본 발명의 일 실시예에 따른 응용 프로세스에 설정된 서비스를 종료하는 절차를 도시한 흐름도이다.

도 9에 도시된 바와 같이, 프로세스흐름관리API(220)가 응용 프로세스(215)로부터 서비스 해제 요구 신호를 수신하는 경우(S910), 프로세스흐름관리API(220)는 수신된 서비스 해제 요구 신호를 세션 스레드(250)에 전송한다(S920).

세션 스레드(250)는 응용 프로세스(215)를 위한 서비스를 종료함과 동시에 할당된 메모리-여기서, 메모리는 응용 프로세스(215)를 위해 할당된 대기 행렬일 수 있음-를 반환한 후(S930), 서비스 해제 응답 신호를 프로세스흐름관리API(220)에 송신한다(S940).

또한, 세션 스레드(250)는 자신의 세션 스레드 식별자를 포함하는 세션 스레드 중지 보고 신호를 세션 관리부(230)에 송신한다(S950).

프로세스흐름관리API(220)는 세션 스레드(250)로부터 서비스 해제 응답 신호를 수신하면, 응용 프로세스(215)에 설정된 공유 메모리 접속 권한을 해제(Detach)한 후(S960), 서비스 해제 응답 신호를 응용 프로세스(215)에 송신한다(S980).

만약, 세션 관리부(230)가 세션 스레드(250)으로부터 세션 스레드 중지 보고를 수신하는 경우, 세션 관리부(230)는 자신이 관리하는 세션 스레드 리스트에서 세션 스레드(250)에 상응하는 세션 정보를 삭제한다(S970).

도 10은 본 발명의 일 실시예에 따른 트랜잭션 이벤트를 로그 파일에 기록하는 방법을 도시한 순서도이다.

도 10의 순서도에 도시된 절차는 로그 파일 생성부(290) 및 장애 관리부(280)에 의해 수행되는 절차일 수 있다.

로그 파일 생성부(290)는 세션 스레드(250)로부터 새롭게 발생된 트랜잭션을 로그 파일에 기록하기 위한 제어 신호 수신하는 경우(S1000), 현재 작성중인 이벤트 트랜잭션 로그 파일의 사이즈가 미리 정의된 로그 파일 사이즈를 초과하는지 비 교한다(S1002).

비교 결과, 현재 작성중인 이벤트 트랜잭션 로그 파일의 사이즈가 미리 정의된 로그 파일 사이즈를 초과하는 경우, 로그 파일 생성부(290)는 작성중인 로그 파일을 닫고, 새로운 이벤트 트랜잭션 로그 파일을 생성한다(S1004).

이후, 로그 파일 생성부(290)가 생성된 이벤트 트랜잭션 로그 파일에 대한 정보를 장애 관리부(280)에 송신하면, 장애 관리부(280)는 수신된 로그 파일 정보를 로그 파일 리스트에 등록한다(S1006).

로그 파일 생성부(290)는 발생된 트랜잭션에 대해 트랜잭션의 시작을 알리는 소정의 트랜잭션 지시자가 설정되었는지 확인한다(S1008).

확인 결과, 트랜잭션 지시자가 설정되지 않은 경우, 로그 파일 생성부(290)는 생성된 이벤트 트랜잭션 로그 파일에 트랜잭션의 시작을 알리는 소정의 트랜잭션 지시자-예를 들면, 트랜잭션 지시자는 'Begin Transaction'으로 설정될 수 있음-를 기록한 후(S1010), 이벤트 트랜잭션 로그 파일에 트랜잭션 단위로 로그 정보를 기록한다(S1012).

만약, 상기한 1008 단계에서, 트랜잭션의 시작을 알리는 소정의 트랜잭션 지시자가 설정되지 않은 경우, 로그 파일 생성부(290)는 상기한 1012 단계를 수행할 수 있다.

로그 파일 생성부(290)는 이벤트 트랜잭션 로그 파일에 기록할 트랜잭션이 남아 있는지 확인한다(S1018).

확인 결과, 기록할 트랜잭션이 남아 있는 경우, 로그 파일 생성부(290)는 상 기한 1002 단계를 수행할 수 있다.

만약, 상기한 1018 단계에서, 기록할 트랜잭션이 남아 있지 않은 경우, 로그 파일 생성부(290)는 현재 작성중인 이벤트 트랜잭션 로그 파일에 소정의 트랜잭션 종료 지시자-예를 들면, 트랜잭션 종료 지사자는 'Commit Transaction'일 수 있음-를 기록한 후(S1020), 트랜잭션 처리를 종료한다(S1022).

만약, 상기한 1002 단계에서, 현재 작성중인 이벤트 트랜잭션 로그 파일의 사이즈가 미리 정의된 로그 파일 사이즈를 초과하지 않는 경우, 로그 파일 생성부(290)는 상기한 1008 단계 내지 1012 단계를 순차적으로 수행할 수 있다.

상기한 1004 단계에 있어서, 로그 파일 생성부(290)는 새롭게 생성된 이벤트 트랜잭션 로그 파일의 파일명에 밀리 세컨드(ms) 단위의 파일 생성 시점 정보를 포함할 수 있다.

예를 들면, 본 발명의 일 실시예에 따른 이벤트 트랜잭션 로그 파일의 파일명은 'AUDIT.CCYYMMDDhhmmssxx.LOG'로 설정될 수 있다.

여기서, YY, MM, DD, hh, mm, ss, xx는 각각 년(year), 월(month), 일(date), 시(hour), 분(minute), 초(second) 및 밀리세컨드(millisecond)를 위한 필드일 수 있다.

따라서, 본 발명에 따른 장애 복구부(285)는 장애 발생 후 시스템 재가동에 따라 복구를 수행하는 경우, 파일명을 참조하여 복구 대상 이벤트 트랜잭션 로그 파일을 순차적으로 로딩(Loading)하여 처리할 수 있다.

도 11은 본 발명의 일 실시예에 따른 체크 포인트 작업 시 로그 파일을 분석하는 방법을 도시한 순서도이다.

앞서 설명한 바와 같이, 본 발명에 따른 장애 관리부(280)는 불필요한 이벤트 트랜잭션 로그 파일을 기록 매체-예를 들면, 트랜잭션 로그 파일 저장부(295)-로부터 삭제하기 위해 체크 포인트 작업을 주기적으로 수행할 수 있다.

본 발명에 따른 체크 포인트 작업은 크게 로그 파일 분석 단계 및 분석된 로그 파일을 삭제하는 단계를 포함할 수 있다.

여기서, 로그 파일 분석 단계는 불필요한 로그 파일을 삭제하기 위해 필요한 정보를 산출하는 사전 분석 단계일 수 있다.

일반적으로, 시스템에 할당된 메모리는 한정적이며, 이를 효율적으로 이용하는 것이 무엇보다 중요하다. 하지만, 과도한 체크 포인트 작업은 부가적인 시스템 부하를 발생시키므로, 체크 포인트 작업을 수행하는 주기를 적절히 조절해야 한다.

이를 위해, 본 발명의 일 실시예에 따른 운용 관리부(235)는 소정의 사용자 인터페이스를 통해, 체크 포인트 작업을 수행하는 주기를 변경할 수 있다.

본 발명에 따른 장애 관리부(280)는 이벤트 트랜잭션 로그 파일의 상태를 크게 작업 상태(Working State), 분석 상태(Analysis State), 종료 상태(Close State) 중 어느 하나로 관리할 수 있다.

여기서, 작업 상태는 이벤트 트랜잭션 로그 파일이 복구 대상 파일임을 의미하며, 분석 상태는 복구 대상 파일 중 로그 파일 분석이 완료된 파일을 의미한다. 종료 상태는 삭제 대상인 로그 파일을 의미할 수 있다.

장애 관리부(280)는 체크 포인트 작업의 시작을 지시하는 제어 신호-여기서, 제어 신호는 타이머에 의한 인터럽트로 발생될 수 있음-를 수신하는 경우(S1102), 로그 파일 리스트를 참조하여 작업 상태(Working State)인 이벤트 트랜잭션 로그 파일을 선택한 후(S1104), 선택된 이벤트 트랜잭션 로그 파일로부터 트랜잭션을 독출한다(S1106).

이후, 장애 관리부(280)는 독출한 트랜잭션의 이벤트가 삽입(INSERT) 이벤트인지 비교한다(S1108).

비교 결과, 삽입 이벤트인 경우, 장애 관리부(280)는 삽입 처리를 수행한다. 여기서, 삽입 처리는 트랜잭션에 포함된 데이터 메시지에 상응하는 메시지 식별자를 키 값으로 현재 분석중인 이벤트 트랜잭션 로그 파일 상에서의 매핑(Mapping) 자료-여기서, 매핑 자료는 소정의 매핑 테이블에 미리 정의된 해쉬 알고리즘을 이용하여 삽입될 수 있음-를 생성하는 단계 및 메시지 카운터 값을 증가시키는 단계를 포함할 수 있다.

예를 들면, 매핑 자료는 메시지 식별자 및 메시지 식별자에 상응하는 로그 정보가 기록된 이벤트 트랜잭션 로그 파일 상에서의 위치 정보-여기서, 위치 정보는 메시지 식별자에 상응하는 로그 정보가 기록된 시작 라인(line) 정보를 포함할 수 있음-를 포함할 수 있다.

상기한 1108 단계에 있어서, 만약, 트랜잭션의 이벤트가 삽입 이벤트가 아닌 경우, 장애 관리부(280)는 삭제(DELETE) 처리를 수행한다(S1112). 여기서, 삭제 처리는 매핑 테이블에서 메시지 식별자에 상응하는 매핑 자료를 추출하는 단계, 추출 된 매핑 자료를 매핑 테이블에서 삭제하는 단계 및 메시지 카운터를 감소시키는 단계를 포함할 수 있다.

만약, 장애 관리부(280)는 매핑 테이블에서 메시지 식별자에 상응하는 매핑 자료를 찾지 못한 경우, 해당 메시지는 타입 아웃으로 인해 백업 파일에 저장된 것으로 판단한다. 이후, 장애 관리부(280)는 백업 파일에서 메시지 식별자에 상응하는 로그 정보를 검색하고, 검색된 로그 정보를 백업 파일에서 삭제할 수 있다.

장애 관리부(280)는 삽입 또는 삭제 처리가 완료된 경우, 트랜잭션이 종료되었는지 확인한다(S1114).

확인 결과, 트랜잭션이 종료되지 않은 경우, 장애 관리부(280)는 상기한 1108 단계로 회귀한다.

상기한 1114 단계에서, 트랜잭션이 종료된 경우, 장애 관리부(280)는 이벤트 트랜잭션 로그 파일의 끝인지를 확인한다(S1116).

확인 결과, 이벤트 트랜잭션 로그 파일의 끝이 아닌 경우, 장애 관리부(280)는 상기한 1106 단계로 회귀한다.

만약, 상기한 1116 단계에서, 이벤트 트랜잭션 로그 파일의 끝인 경우, 장애 관리부(280)는 해당 이벤트 트랜잭션 로그 파일의 상태를 분석 상태로 설정한 후(S1118), 로그 파일 리스트에 작업 상태인 이벤트 트랜잭션 로그 파일이 존재하는지 확인한다(S1120).

확인 결과, 작업 상태인 이벤트 트랜잭션 로그 파일이 존재하는 경우, 작업 관리부(280)는 상기한 1104 단계를 수행한다.

만약, 상기한 1120 단계에서, 작업 상태인 이벤트 트랜잭션 로그 파일이 더 이상 존재하지 않는 경우, 작업 관리부(280)는 로그 파일 분석 절차를 종료한다(S1122).

도 12은 본 발명의 일 실시예에 따른 체크 포인트 작업 시 로그 파일 삭제하는 방법을 도시한 순서도이다.

도 12에 도시된 바와 같이, 도 11에 도시된 로그 파일 분석 작업이 완료된 경우, 장애 관리부(280)는 로그 파일 삭제 작업을 시작한다(S1202).

장애 관리부(1204)는 로그 파일 리스트로부터 분석 상태인 이벤트 트랜잭션 로그 파일을 선택한 후(S1204), 선택된 이벤트 트랜잭션 로그 파일의 메시지 카운터의 값이 0(zero)인지 비교한다(S1206).

비교 결과, 메시지 카운터의 값이 0이 아닌 경우, 장애 관리부(280)는 이벤트 트랜잭션 로그 파일의 보관 일자가 경과하였는지 비교한다(S1208).

여기서, 보관일자의 경과 여부에 대한 판단은 이벤트 트랜잭션 로그 파일의 파일명, 미리 설정된 보관 만료 일자 정보 및 현재 시간 정보를 이용하여 수행될 수 있다.

예를 들면, 파일명에 기록된 파일 생성 일자가 2007년 4월 1일 00시 00분 00초 00밀리 세컨드이고, 보관 만료 일자가 5일이고, 현재 시간 정보가 2007년 4월 6일 01시 10분 25초 12밀리세컨드인 경우, 장애 관리부(280)는 보관 만료 일자를 초과한 것으로 판단할 수 있다.

비교 결과, 이벤트 트랜잭션 로그 파일의 보관 일자가 경과한 경우, 장애 관리부(280)는 백업 파일을 생성한 후 이벤트 트랜잭션 로그 파일을 삭제한다(S1210).

여기서, 백업 파일은 이벤트 트랜잭션 로그 파일상에 삭제되지 않은 메시지 별로 생성될 수 있다.

장애 관리부(280)는 로그 파일 리스트에 등록된 다음 이벤트 트랜잭션 로그 파일의 삭제가 가능한지 판단한다(S1212).

여기서, 다음 이벤트 트랜잭션 로그 파일의 삭제 가능 여부는 현재 선택된 이벤트 트랜잭션 로그 파일의 삭제 여부에 따라 달라질 수 있다.

예를 들면, 장애 관리부(280)는 로그 파일 리스트로부터 파일이 생성된 시간 순으로 이벤트 트랜잭션 로그 파일을 읽어올 수 있으며, 만약, 먼저 생성된 파일이 삭제 처리되지 않은 경우, 장애 관리부(280)는 다음으로 생성된 파일의 메시지 카운터 값이 0일지라도 경우에 따라서는 해당 파일을 삭제 처리할 수 없다.

왜냐하면, 먼저 생성된 파일에 남아 있는 메시지의 삭제 정보가 이후 생성된 파일에 존재할 수 있기 때문이다.

상기한 1212 단계에서, 다음 이벤트 트랜잭션 로그 파일의 삭제가 가능한 경우, 장애 관리부(280)는 상기한 1204 단계를 수행할 수 있다.

만약, 상기한 1212 단계에서, 다음 이벤트 트랜잭션 로그 파일의 삭제가 불가능한 경우, 장애 관리부(280)는 로그 파일 삭제 작업을 종료 한다(S1216).

상기한 1206 단계에 있어서, 만약 메시지 카운터의 값이 0인 경우, 장애 관 리부(280)는 해당 이벤트 트랜잭션 로그 파일 및 로그 파일 리스트에 기록된 해당 로그 파일 정보를 삭제한 후(S1214), 상기한 1212 단계를 수행한다.

도 13은 본 발명의 일 실시예에 따른 장애 복구 시 파일 단위 동기화 작업을 수행하는 방법에 관한 순서도이다.

본 발명에 따른 과금 게이트웨이(100)는 장애 발생 후 재 가동될 경우, 이벤트 트랜잭션 로그 파일 단위로 동기화 작업을 시작한다(S1302).

여기서, 동기화 작업은 저장된 트랜잭션 로그 파일 저장부(295)에 저장된 이벤트 트랜잭션 로그 파일을 이용하여, 대기 행렬(260) 및 유닉스 공유 메모리(265)를 장애 발생 이전 상태로 복구하는 것을 의미한다.

좀 더 상세하게는, 메모리 관리부(240)는 과금 게이트웨이(100)가 재 구동되고 장애 복구가 필요한 것으로 판단된 경우, 메모리 관리부(240)는 장애 복구부(285)와 연동하여 트랜잭션 로그 파일 저장부(295)에 저장된 이벤트 트랜잭션 로그 파일을 검사하여, 시간 순으로 정렬된 동기화 대상 로그 파일 정보 리스트를 생성한다(S1304). 여기서, 메모리 관리부(240)는 동기화 대상 파일 중 가장 이른 시간에 생성된 이벤트 트랜잭션 로그 파일에 상응하는 정보부터 동기화 대상 로그 파일 정보 리스트에 순차적으로 삽입할 수 있다.

본 발명에 일 실시예에 따른 동기화 대상 로그 파일 정보 리스트는 첫번째 입력된 정보가 처음으로 출력되는 적어도 하나의 노드(Node)로 구성된 FIFO(First Input First Out) 형태의 자료 구조일 수 있다.

예를 들면, 장애 복구부(285)는 메모리 관리부(240)의 제어 신호에 따라, 메시지 카운터가 0이 아닌 이벤트 트랜잭션 로그 파일에 대한 정보를 추출하고 추출된 정보를 메모리 관리부(240)에 제공할 수 있다.

장애 복구부(285)는 생성된 동기화 대상 로그 파일 정보 리스트의 첫 번째 노드에 기록된 파일 정보를 추출하고, 추출된 파일 정보에 상응하는 이벤트 트랜잭션 로그 파일을 트랜잭션 로그 파일 저장부(295)로부터 독출한다(S1306).

장애 복구부(285)는 독출된 로그 파일에서 트랜잭션을 추출한 후(1308), 추출된 트랜잭션의 이벤트 타입이 삽입 이벤트인지 비교한다(S1310).

비교 결과, 삽입 이벤트가 아닌 경우-여기서, 삽입 이벤트가 아닌 것은 삭제 이벤트를 의미함-, 장애 복구부(285)는 추출된 트랜잭션에 포함된 메시지 식별자에 상응하는 데이터 메시지를 해당 이벤트 트랜잭션 로그 파일로부터 삭제한다(S1312).

만약, 상기한 1310 단계에서, 트랜잭션의 이벤트 타입이 삽입 이벤트인 경우, 장애 복구부(285)는 추출된 트랜잭션에 상응하는 복구 대상 메시지 정보-여기서, 복구 대상 메시지 정보는 메시지 식별자, 데이터 메시지, 데이터 메시지 길이, 대기 행렬 정보 등을 포함함-를 생성한 후, 생성된 복구 대상 메시지 정보를 소정의 해쉬 알고리즘을 이용하여 해쉬 테이블(Hash Table)에 추가한다(S1316). 여기서, 해쉬 테이블은 메시지 식별자를 키 값으로 데이터 메시지가 저장된 위치 정보를 검색하는 것이 가능한 자료 구조일 수 있다.

삽입 또는 삭제 처리가 완료된 경우, 장애 복구부(285)는 해당 트랜잭션의 처리가 종료되었는지 확인한다(S1314).

확인 결과, 해당 트랜잭션의 처리가 종료되지 않은 경우, 장애 복구부(285)는 해당 트랜잭션에 포함된 다음 메시지를 선택한 후(S1324), 상기한 1310 단계를 수행한다.

만약, 상기한 1314 단계에서, 해당 트랜잭션의 처리가 종료된 경우, 장애 복구부(285)는 해당 이벤트 트랜잭션 로그 파일의 처리가 종료되었는지 확인하다(S1318).

확인 결과, 해당 이벤트 트랜잭션 로그 파일의 처리가 종료되지 않은 경우, 장애 복구부(285)는 상기한 1306 단계를 수행한다.

만약, 상기한 1318 단계에서, 해당 이벤트 트랜잭션 로그 파일의 처리가 종료된 경우, 장애 복구부(285)는 동기화 대상 이벤트 트랜잭션 로그 파일이 남아 있는지 확인한다(S1320).

확인 결과, 동기화 대상 이벤트 트랜잭션 로그 파일이 남아 있는 경우, 장애 복구부(285)는 상기한 1306 단계로 회귀하여, 다음으로 처리할 이벤트 트랜잭션 로그 파일을 추출한다.

만약, 상기한 1320 단계에서, 동기화 대상 이벤트 트랜잭션 로그 파일이 남아 있지 않은 경우, 장애 복구부(285)는 동기화 작업을 종료한다(S1322).

본 발명의 일 실시예에 따른 로그 파일 생성부(290)는 트랜잭션의 시작/종료를 가리키는 식별 정보 및 로그 파일의 시작/종료를 가리키는 식별 정보를 생성된 이벤트 트랜잭션 로그 파일에 기록할 수 있다.

상기한 본 발명의 실시예는 예시의 목적을 위해 개시된 것이고, 본 발명에 대해 통상의 지식을 가진 당업자라면 본 발명의 사상과 범위 안에서 다양한 수정, 변경, 부가가 가능할 것이며, 이러한 수정, 변경 및 부가는 하기의 특허청구범위에 속하는 것으로 보아야 할 것이다.

이상에서 설명한 바와 같이, 본 발명은 프로세스간 메시지 전송을 위해 공유 메모리 및 대기 행렬을 이용하는 과금 게이트웨이에서 실시간으로 트랜잭션 로그 파일을 생성하여 저장하고 이를 관리하는 방법 및 장치를 제공함으로써, 복구 대상 로그 파일을 효율적으로 관리할 수 있는 장점이 있다.

또한, 본 발명은 장애 발생 시 기 저장된 트랜잭션 로그 파일을 이용하여 공유 메모리 및 대기 행렬의 상태를 장애 발생 이전 상태로 복구하는 것이 가능한 장애 복구 방법 및 그 장치를 제공하는 장점이 있다.

또한, 본 발명은 트랜잭션 단위의 이벤트를 수신하고, 수신된 트랜잭션 이벤트를 이용하여 이벤트 트랜잭션 로그 파일을 생성하는 방법을 제공함으로써, 시스템 자원 사용 효율을 극대화시키는 장점이 있다.

또한, 본 발명은 프로세스흐름관리부에 소정의 사용자 인터페이스를 통해 프로세스/자원/망의 상태 관리, 통계 및 분석, 장애 관리 및 구성 정보 관리를 위한 운용 관리부를 추가함으로써, 시스템의 유지 보수가 용이할 뿐만 아니라 연구 개발 을 위한 테스트 베드로 활용 가능한 과금 게이트웨이 시스템을 제공하는 장점이 있다.

또한, 본 발명에 따른 장애 복구 장치는 불필요한 이벤트 트랜잭션 로그 파일을 기록 매체로부터 제거하기 위해 주기적으로 검사하는 수단을 제공함으로써, 시스템에 가용한 메모리 자원을 효율적으로 관리할 수 있는 장점이 있다.

또한, 본 발명은 프로세스흐름관리부에 소정의 사용자 인터페이스를 통해 프로세스/자원/망의 상태 관리, 통계 및 분석, 장애 관리 및 구성 정보 관리를 위한 운용 관리부를 추가함으로써, 시스템의 유지 보수가 용이할 뿐만 아니라 연구 개발을 위한 테스트 베드로 활용될 수 있다.

본 발명은 프로세스 및 스레드 간 송수신되는 데이터 메시지를 공유 메모리상에서만 처리하는 것이 가능한 흐름 제어 장치를 구비함으로써, 과도한 메모리 복사(copy)에 따른 처리 성능 저하를 방지하는 장점이 있다.

본 발명에 따른 프로세스흐름관리부는 응용 업무 프로세스로부터 실시간 수신되는 다양한 크기의 데이터를 처리하기 위해 비교적 작은 단위의 데이터 블록 페이지를 동적으로 할당하는 기능을 추가함으로써, 자원의 낭비 없이 필요한 메모리를 할당하는 장점이 있다.

또한, 본 발명은 응용 프로세스가 미리 정의된 프로세스 흐름 관리API를 통해서만 프로세스 흐름 관리부에 접근하는 것을 가능하게 함으로써, 불법적인 메모리의 접근을 미연에 방지하는 효과를 얻을 수 있다.

또한, 본 발명은 특정 이벤트의 발생은 소켓 통신을 통해 수행하고, 실제적 인 데이터 메시지의 송/수신은 공유 메모리를 이용함으로써, 응용 프로세스와 프로세스흐름관리부가 공유 메모리를 사용하는데 있어서, 충돌 방지를 위한 별도의 세마포어(Semaphore)나 로킹(Locking) 기능을 추가하지 않아도 되는 장점이 있다.

특히, 본 발명은 장애 복구에 필요한 로그 정보를 파일 시스템에서 관리함으로써, 과금 시스템의 전체적인 처리 성능을 향상시키는 장점이 있다.

Claims

과금 게이트웨이 시스템(Charging Gateway System)에서 장애를 복구하는 장치에 있어서,

트랜잭션 이벤트에 따라 이벤트 트랜잭션 로그 파일을 생성, 저장 및 갱신하는 로그 파일 생성부;

상기 과금 게이트웨이 시스템의 장애를 감지하고, 상기 생성된 이벤트 트랜잭션 로그 파일에 상응하는 로그 파일 정보를 상기 로그 파일 생성부로부터 수신하여 소정의 로그 파일 리스트에 기록하는 장애 관리부; 및

상기 저장된 이벤트 트랜잭션 로그 파일을 독출하여 장애를 복구하는 장애 복구부를 포함하되, 상기 트랜잭션 이벤트는 응용 프로세스간 메시지의 흐름을 제어하는 세션 스레드(Session Thread)로부터 수신되며,

상기 장애 복구부는 상기 추출된 이벤트 트랜잭션 로그 파일을 분석하여 장애 복구 대상인 이벤트 트랜잭션 로그 파일을 선별하고, 상기 선별된 이벤트 트랜잭션 로그 파일을 이용하여 상기 과금 게이트웨이 시스템에 구비된 대기 행렬 및 공유 메모리를 동기화 시키는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 장치.
제1항에 있어서,

상기 트랜잭션 이벤트는 삽입 이벤트, 삭제 이벤트 중 어느 하나인 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 장치.
제2항에 있어서,

상기 트랜잭션 이벤트는 적어도 하나의 블록 정보를 포함하며,

상기 로그 파일 생성부는 상기 트랜잭션 이벤트에 따라 상기 블록 정보에 상응하는 로그 정보를 생성하여 상기 이벤트 트랜잭션 로그 파일에 기록하거나 상기 블록 정보에 상응하는 로그 정보를 상기 이벤트 트랜잭션 로그 파일로부터 삭제하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 장치.
제3항에 있어서,

상기 로그 파일 생성부는 상기 로그 정보의 검색에 필요한 해쉬 노드(Hash Node)를 상기 트랜잭션 이벤트에 따라 소정의 해쉬 테이블(Hash Table)에 추가하거나 삭제하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 장치.
제4항에 있어서,

상기 해쉬 노드는 메시지 식별자, 로그 파일 식별자, 위치 정보, 로그 정보 크기 중 적어도 하나를 포함하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 장치.
제1항에 있어서,

상기 로그 파일 생성부는 상기 생성된 이벤트 트랜잭션 로그 파일 별로 장애 복구 대상 메시지의 개수를 가리키는 메시지 카운터를 할당하되, 상기 트랜잭션 이벤트에 따라 상기 메시지 카운터를 증가 또는 감소시키는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 장치.
제 6항에 있어서,

상기 장애 관리부는 주기적으로 불필요한 이벤트 트랜잭션 로그 파일을 삭제하는 체크 포인트 작업을 수행하되, 상기 체크 포인트 작업은 상기 메시지 카운터의 값이 0인 이벤트 트랜잭션 로그 파일을 삭제하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 장치.
제1항에 있어서,

상기 장애 관리부는 장애를 감지하는 경우, 소정의 비 휘발성 기록 영역에 장애 내역을 기록하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 장치.
제 8항에 있어서,

상기 장치는 메모리 관리부를 더 포함하되,

상기 메모리 관리부는 특정 장애에 의해 상기 과금 게이트웨이 시스템이 재 구동되는 경우, 상기 장애 내역을 독출하고, 장애 복구를 위한 소정의 제어 신호를 상기 장애 복구부에 송신하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 장치.
삭제
제 1항에 있어서,

상기 로그 파일 정보는 상기 이벤트 트랜잭션 로그 파일의 생성 시간 정보를 포함하되, 상기 장애 관리부는 상기 생성 시간의 오름차순으로 상기 로그 파일 정보를 상기 로그 파일 리스트에 순차적으로 기록하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 장치.
과금 게이트웨이 시스템(Charging Gateway System)에서 장애를 복구하는 방법에 있어서,

(a) 트랜잭션(Transaction) 단위의 로그 정보를 생성하여 로그 파일에 기록하는 단계;

(b) 장애 발생에 따라 상기 과금 게이트웨이 시스템이 재 구동되는 경우, 상기 로그 파일을 분석하여 장애 복구 대상인 로그 파일을 선택하는 단계; 및

(c) 상기 선택된 로그 파일에 저장된 상기 로그 정보를 독출하여 상기 장애 발생 이전 상태로 메모리를 복구하는 단계를 포함하되,

상기 (c) 단계는 상기 (b) 단계에서 선택된 로그 파일에 상응하는 파일 정보가 상기 로그 파일이 생성된 시간 순으로 정렬된 로그 파일 동기화 대상 로그 파일 정보 리스트를 생성하는 단계를 포함하고, 상기 정렬된 순서로 상기 로그 파일을 독출하여 상기 메모리를 복구하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 방법.
제 12항에 있어서,

상기 (a) 단계는,

상기 로그 파일의 크기에 따라 신규 로그 파일의 생성 여부를 판단하는 단계 를 포함하되, 판단 결과, 신규 로그 파일이 생성된 경우, 상기 생성된 신규 로그 파일에 상기 로그 정보를 기록하는 트랜잭션 로그 파일을 이용한 장애 복구 방법.
제 12항에 있어서,

상기 로그 정보는 메시지 식별자, 이벤트 타입, 데이터 메시지, 트랜잭션 시작 지시자, 트랜잭션 종료 지시자 중 적어도 하나를 포함하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 방법.
제 14항에 있어서,

상기 이벤트 타입은 삽입 이벤트, 삭제 이벤트 중 어느 하나인 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 방법.
제 15항에 있어서,

상기 (b) 단계는 상기 로그 파일 별 복구 대상 메시지의 개수를 가리키는 메시지 카운터를 상기 이벤트 타입에 따라 증감시키는 단계를 포함하되, 분석 완료된 로그 파일의 메시지 카운터가 0인 경우, 상기 분석 완료된 로그 파일을 삭제하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 방법.
제 16항에 있어서,

상기(b) 단계는 상기 메시지 카운터가 0이 아닌 경우, 미리 설정된 로그 파일 보관 일자의 경과 여부를 판단하는 단계를 더 포함하되, 판단 결과, 상기 로그 파일 보관 일자가 경과한 경우, 백업 파일을 생성하고 상기 로그 파일을 삭제하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 방법.
삭제
과금 게이트웨이 시스템(Charging Gateway System)에서 장애를 복구하는 방법을 실행하는 유형화된 명령어로 이루어진 프로그램이 기록된 전자 장치에서 판독할 수 있는 기록 매체에 있어서,

(a) 트랜잭션(Transaction) 단위의 로그 정보를 생성하여 로그 파일에 기록하는 단계;

(b) 장애 발생에 따라 상기 과금 게이트웨이 시스템이 재 구동되는 경우, 상기 로그 파일을 분석하여 장애 복구 대상인 로그 파일을 선택하는 단계; 및

(c) 상기 선택된 로그 파일에 저장된 상기 로그 정보를 독출하여 상기 장애 발생 이전 상태로 메모리를 복구하는 단계를 포함하

상기 (c) 단계는 상기 (b) 단계에서 선택된 로그 파일에 상응하는 파일 정보가 상기 로그 파일이 생성된 시간 순으로 정렬된 로그 파일 동기화 대상 로그 파일 정보 리스트를 생성하는 단계를 포함하고, 상기 정렬된 순서로 상기 로그 파일을 독출하여 상기 메모리를 복구하는 것을 특징으로 하는 트랜잭션 로그 파일을 이용한 장애 복구 방법을 실행하는 프로그램이 기록된 기록 매체.