2.1 배전망 운영 현황

기존 배전망의 데이터 연계 시스템은 파일 전송 기반의 일방향장치를 이용하여 데이터를 주기적으로 덤프(dump) 및 임포트(import)하는 방식으로 이루어져 왔다. 데이터에 자동으로 증가하는 번호인 increment ID를 생성하여 특정 시점을 기록하고, 일정 주기가 지나면 그 이후의 데이터를 덤프하여 파일로 생성하는 방식이다.

그림 1. 기존 데이터 연계 방식

Fig. 1. Conventional Data Integration Approach

그림1과 같이 일정 주기를 설정하여 파일 형식으로 데이터를 연계하는 방식은 구현이 간단하다는 장점이 있으나, 데이터 정합성을 보장하지 못한다는 문제점이 있다. 데이터 정합성을 보장하는 트랜잭션 단위를 확인하지 못하며, 데이터를 추출하는 동안에 새로운 데이터의 삽입이나 기존 데이터의 업데이트를 놓치기 때문이다. 이는 변경 데이터 누락으로 이어져 DB 간에 데이터 불일치를 초래한다.

또 다른 문제는 원본 DB 부하의 원인이 되는 것이다. 대량의 데이터를 덤프하는 과정은 원본 DB에 I/O 부하를 발생시키며, 네트워크 대역폭 소모가 커서 실시간 데이터 연계 또한 불가능하게 한다. 이처럼 현재 배전망 데이터 연계 구성은 데이터 정합성, 성능, 운영 효율성 등 많은 면에서 한계를 가지고 있다.

실제로 현재 차세대 배전망 관리 시스템(ADMS)은 배전 데이터를 매일 한 번씩 덤프하여 연계하고 있다. 그러나 이 덤프 작업이 이루어지는 동안 서버에 과부하가 발생하여, 성능 최적화를 위한 추가 작업이 필요한 상황이다.

2.2 관련 기술 동향

ADMS 외에도 기존에 망분리 환경에서 데이터 연계는 보안성과 실시간성 간의 상충 문제로 다양한 연구가 진행됐다. ADMS 이전의 배전 시스템 DAS 역시 일방향 데이터 전달을 위한 연구를 진행해 왔으나 이는 데이터 동기화를 지원하지 않았다.^[6] 다른 국내 연구에서도 대량의 데이터를 실시간으로 처리하며 지연을 줄이고 정확성을 보장하는 DSSP 모델이 제안되었으나 망분리 환경이 고려되지 않았다.^[7] 무선통신 환경의 불안정성을 고려한 CDC 기반 데이터 동기화 연구 또한 진행되었으나 무선망에서의 가용성 문제를 해결하는 데 초점이 맞추어져 있어, 보안상의 이유로 제어망과 업무망이 철저히 구분된 배전망과 같은 망분리 환경에서 직접적으로 적용하기 어렵다.^[8]

위와 같이 기존 연구들은 보안성 또는 실시간성 중 한 측면에 초점을 맞추거나, 망분리 환경을 고려하지 않았다. 본 연구에서는 이러한 기존 시스템의 문제점을 분석하고, 실시간 동기화가 가능한 시스템 구조를 제안함으로써 망 분리 환경에서 데이터의 보안성, 실시간성, 정합성을 동시에 확보하고자 한다.

4.1 송신부 중계서버 설계

송신부는 출발지망의 데이터베이스에서 데이터를 실시간으로 추출하는 변경 데이터 추출 모듈, 데이터를 JSON 형식으로 변환하여 메시지 큐에 저장하는 메시지 수집 모듈, 데이터를 TCP 기반 패킷으로 가공하여 전송하는 데이터 가공 및 전송 모듈로 구성된다. DPI를 지나기 위해 데이터는 TCP를 기반으로 송신되고, 각 모듈의 처리/통계 데이터는 로컬 DB에 저장되며 에러 발생 시 로그 저장 후 관리자에게 알린다.

동기화 데이터의 모듈별 흐름은 그림 3과 같다. 모듈별로 역할이 정의되어 있으며, 데이터의 흐름을 화살표로 표시하였다. 각 모듈의 세부 역할과 구성은 그림4와 같으며 모듈별 세부 설명은 아래와 같다.

그림 3. 송신부 모듈 연계 흐름

Fig. 3. Transmitter Module Interconnection Flow

그림 4. 송신부 중계서버 모듈 구성도

Fig. 4. Architecture of Transmitter Relay Server Module

4.2 변경 데이터 추출 모듈

이 모듈은 원본 데이터베이스의 변동 데이터를 실시간으로 추출하는 기능을 담당하며 Debezium을 활용한다. 그림 5와 같이 Debezium은 원본 DB의 binlog를 참조하여 트랜잭션 단위로 변동 데이터를 확인하고 변동 데이터는 Kafka Source Connector를 통해 Kafka의 메시지로 저장한다.^[10] DB 변동 데이터는 20,000건 또는 3초, 20MB의 조건 중 “OR”조건을 만족할 때 수집하도록 설정하였다. 이는 일방향장치의 성능에 맞게 구현한 것이고 환경에 따라 최적의 성능을 위해 다양하게 수정해 볼 수 있다.

그림 5. Debezium의 CDC구조

Fig. 5. Debezium CDC Architecture

4.3 메시지 수집 모듈

변경 데이터 추출 모듈에서 저장된 데이터를 수집하여 처리하기 쉬운 JSON 형식으로 변환한다. 메시지 수집 모듈이 저장하는 메시지에는 timestamp, offset, Topic 등의 메타데이터가 저장되어 데이터의 추적성을 높인다. 모듈은 데이터의 순서 보장을 위해 단일 Topic으로 메시지를 발행하도록 설계되어 있다. Topic명은 사용자가 직접 설정할 수 있으며 모듈은 해당 Topic명 아래에 순차적으로 데이터를 저장한다.

key에는 변동 데이터의 DB 테이블 내 PK인 데이터의 구조와 값을 나타내고, value의 경우 데이터의 모든 레코드 데이터 구조와 값을 지니고 있다. Kafka는 key 값을 기준으로 파티션을 나누며, 동일 파티션 내에서 데이터의 순서를 보장하기 때문에 정합성을 보장한다. 메시지의 데이터 구성을 시각화하면 아래 그림 6과 같다.

그림 6. 메시지 수집 모듈이 생성한 데이터 구성

Fig. 6. Data Composition Generated by Message Collection Module

테이블별로 Topic이 생성되면 데이터 관리가 쉬울 수 있으나 Kafka는 Topic이 여러 개면 데이터 순서 보장이 불가능하다.^[9] 이는 외래키가 지정되어 있는 경우 데이터 변동의 순서가 달라질 때 참조 오류와 같은 에러가 발생하기 때문에, 데이터를 단일 Topic으로 저장하도록 설계하였다.

4.4 데이터 가공 및 전송 모듈

Kafka Consumer를 활용하여 메시지 큐로부터 메시지를 추출한다. 이 과정에서 데이터 건별 전송 및 수신 측에서의 전체 데이터 수신 여부 판단을 위해 UID, Total Count, Sequence 등의 Header 정보를 추가 생성하며 데이터는 TAB 문자로 구분된다. 추출된 메시지는 이 고유 식별자와 순서 정보를 포함하여 TCP 기반의 패킷으로 구성(패킷화)되며, 이 패킷화된 데이터는 일방향장치를 통해 목적지 망으로 전송된다. 모듈의 동작 및 통계 데이터는 로컬 DB에 저장되며, 에러 발생 시 로그를 저장하고 관리자에게 알림으로써 시스템의 안정적인 운영을 지원한다.

그림 7. 실제 전송되는 Raw Data 예시

Fig. 7. Example of Actual Transmitted Raw Data

전송모듈은 그림 7과 같은 Raw Data를 일방향장치와 연계하기 위해 TCP 기반의 Client 형태로 동작한다. 일방향 장치의 IP 및 PORT를 사전에 약속하여 지정하고 일방향장치의 가이드라인에 따라 TCP 접속, TCP 데이터 전송, TCP 접속 해제를 반복하며 데이터를 한 건씩 송신한다.

4.5 데이터 처리 통계 및 전체 프로세스

송신부 중계서버의 전체 데이터 흐름을 정리하면, 변경 데이터 추출 모듈이 원본 DB의 변동 여부를 실시간으로 확인한다. 데이터 변동분이 존재할 시에 메시지 수집 모듈은 기존의 Topic 설정이 아닌 단일 Topic으로 변경하여 메시지를 저장한다. Topic을 구독하는 데이터 가공 및 전송 모듈은 Header 정보를 추가하여 일방향장치에 데이터를 전송하며 데이터 처리 흐름도는 그림 8과 같다.

수집한 데이터를 가공하여 일방향장치로 전송이 완료된 건에 대하여 내부 DB의 통계 테이블을 사용해 현재까지 처리가 완료된 데이터에 대해 통계 데이터를 저장한다. 통계 데이터에는 처리한 시간, 처리한 건수, 처리한 데이터 백업 파일 등의 정보를 저장하며 해당 정보를 통해 현재까지 몇 건의 데이터를 수집 및 전송하였는지 확인할 수 있다.

Debezium Source Connector의 에러, 일방향장치와 연계 시 통신이 불가하여 발생하는 에러 등 발생한 모든 에러 정보 또한 별도의 통계 테이블에 저장하여 해당 정보를 통해 어떤 에러가 언제 발생하였는지 확인 할 수 있다.

그림 8. 송신부 중계서버 데이터 처리 흐름도

Fig. 8. Data Processing Flowchart of Transmitter Relay Server

5.1 수신부 중계서버 설계

수신부는 일방향 장치를 통해 송신된 데이터를 수신하고, offset과 같은 순서 정보를 활용하여 정렬한 후 최종 데이터베이스에 동기화하는 역할을 한다. 일방향장치가 수신부 중계서버의 TCP Server에 접속하여 데이터를 전송하며 수신부는 빠른 데이터 수신을 위해 Thread Pool을 이용한다. 일방향장치는 송신부에서 전달하는 방법과 동일하게 데이터를 전달하기 때문에 데이터는 한 건씩 수신하게 된다.

송신부의 메시지 수집 모듈에서 단일 토픽 내 단일 파티션으로 메시지를 발행하기 때문에 데이터 처리 순서를 보장한다. 따라서 수신부가 데이터를 정상적으로 수신하였을 때는 데이터의 정합성을 보장하는 것이며, 데이터 수신에 발생하는 모듈별 에러 및 처리/이력 정보는 로컬 DB에 저장하고 관리자에게 알린다. 수신부는 크게 데이터 수신 및 검증 모듈, 메시지 수집 모듈, 데이터 동기화 및 저장 모듈로 구성되며 모듈 간 데이터 연계 흐름은 그림 9와 같다. 각 모듈의 세부 역할과 구성은 그림10과 같으며 모듈별 세부 설명은 아래와 같다.

그림 9. 수신부 모듈 연계 흐름

Fig. 9. Integration Flow of Receiver Module

그림 10. 수신부 중계서버 모듈 구성

Fig. 10. Configuration of Receiver Relay Server Module

5.2 데이터 수신 및 검증 모듈

이 모듈은 TCP 기반으로 수신된 데이터 패킷을 재조립한다. 송신부에서 부여한 Header 정보를 통해 수신한 데이터를 확인하고 같은 UID를 부여받은 데이터끼리 조립한 후, Total Count를 통해 전체 데이터 수신 완료를 확인하고, 데이터의 Sequence를 통해 데이터의 순서를 정렬한다. 패킷 손실 발생 시에는 에러 로그를 저장하고 관리자에게 알림을 제공하여 데이터 손실에 대한 대응을 가능하게 한다.

5.3 메시지 수집 모듈

데이터 수신 및 검증 모듈에서 처리된 수신 데이터를 Kafka Producer를 활용하여 Kaka에 저장한다. 실제 저장하는 데이터 예시는 그림 11과 같다. 이 모듈은 데이터 동기화 모듈에 에러가 발생할 때를 대비하여 별도의 메모리 공간에 데이터를 저장하는 기능을 포함하고 있어, 데이터 유실 방지에 기여한다.

그림 11. 수신 데이터 예시

Fig. 11. Example of Received Data

5.4 데이터 동기화 및 저장 모듈

데이터 동기화 및 저장 모듈은 Sink Connector를 활용하여 최종적으로 목적지 망의 데이터베이스에 데이터를 동기화하는 역할을 수행한다. 데이터의 순서 정합성을 위해 송신부에서 단일 Topic으로 데이터를 보내주었으므로, 수신부도 단일 Topic으로 데이터를 수신한 이후, 데이터 내에서 테이블 정보를 추출하도록 설계하였다.

그림 11의 데이터를 보면 Topic이 cdc.origin_db_group 이지만 해당 내용으로는 실제 동기화해야 하는 테이블 정보를 알 수 없다. 따라서 key/value 안에 존재하는 테이블 정보를 다시 Topic으로 설정하도록 하여 모든 테이블이 순서에 맞춰 적재되도록 한다. 해당 과정에서 에러가 발생할 경우에는 로그를 기록하여 문제 발생 이력을 관리한다.

5.5 데이터 수신 통계 및 전체 프로세스

수신이 완료된 건에 대하여 내부 DB의 통계 테이블을 사용해 현재까지 처리가 완료된 데이터에 대하여 통계 데이터를 저장한다. 통계 데이터는 현재까지 몇 건의 데이터를 처리 및 동기화하였는지를 저장한다. 송신부의 통계 데이터 테이블과 유사하지만, 제어 관련 설정 정보인 fot_setting_info의 경우 timestamp를 기준으로 처리 시점을 남기는 데이터가 필요로 하지 않기 때문에 삭제하였으며 리스트는 표1과 같다.

그림 12. 수신부 중계서버 데이터 처리 흐름도

Fig. 12. Data Processing Flowchart of Receiver Relay Server

데이터 수신 및 검증 모듈이 패킷 재조립을 통해 데이터 수신을 확인하면 데이터 수집 모듈이 데이터를 Kafka에 저장한다. 데이터 동기화 및 저장 모듈은 저장된 데이터를 읽고, 송신부에서 단일화한 Topic이 아닌, 데이터 내에서 원본 테이블 정보를 가지고 와 Topic으로 재 설정한다. Sink Connector는 재 설정된 Topic을 활용하여 원본 테이블을 찾아 데이터를 적용함으로써 원본 DB와 동기화시키며 모든 데이터 처리 흐름도는 그림 12와 같다.