대량 DB 패치 이후 데이터 복제
2023년 09월 3년의 프로젝트가 마무리되는 시점에 배치에 대한 문제가 발생하였다.
1. 문제
MSA기반으로 진행된 프로젝트에서 한 부분을 담당하고 있는데 타 MSA에서 운영 중 DB를 대량 패치 하였을 떼 다른 MSA에서 어떻게 대응 할 것인가에 대한 문제이다. MSA 구축시 고려 사항 중 하나인데 진행된 프로젝트에서는 오픈 시점에 이야기가 나오고 있다. 분명히 사전에 인지된 상황이었을 건데 ....
Provisioning MSA의 간략한 기능을 살펴보고 문제에 대한 해결 방안을 찾고자 한다.
1-1. Provisioning 기능
MSA B는 프로비저닝 역할을 하는 MSA로 MSA A에서 전문을 받아서 프로비저닝 정책을 적용 하여 Target에 전문을 발송한다.
MSA B는 MSA A에서 받는 메세지에 대한 전문을 저장 하고 있으나 MSA A의 테이블 변경에 대한 이벤트 수신 데이터는 받지 않는다. ( MSA A는 테이블의 변경이 발생 하면 Event를 발행 하는 기능이 있다.) 받지 않는 이유는 MSA B는 MSA A의 여러 테이블에 있는 정보와 MSA A에서 비지니스 처리시 발생하는 가동된 데이터를 받아서 처리해야 하므로 개별 이벤트에 대한 처리로는 수용이 되지 않기 때문이다.
또한 외부 기관과 연동으로 보상 설계는 되어 있지 않으며 연동 구간에 문제가 발생하면 내부적으로 Retry Option을 조정 하여 자체 재 처리가 되는 기능이 제공되어 있다.
MAS B에서 장애 처리에 대한 설계/구현된 방안에 대해서 알아보자
1-2. 장애 대응에 대한 처리 방안
1-2-1. MSA B에서 내부 업무 처리 시 장애
MSA A 에서 발행한 전문을 기준으로 재연동 한다. ( 화면 제공 )
Target 서비스 별 또는 전체 대상으로 재연동 할 수 있는 기능 제공
1-2-2. MSA B에서 외부 연동 시 장애
외부로 발행 되는 전문이 있으므로 재전송 화면을 통해서 한다.
외부로 발행 되는 전문을 수정 하여 재전송 하는 기능 제공
1-2-3. MSA B에서 외부 연동 시 전체 장애
1-3-1, 1-3-2를 활용하여 재연동 또는 재전송 처리를 한다.
1-2-4. MSA A에서 발행 된 전문 오류로 의한 장애
MSA A에서 발행된 전문을 수정 하여 재연동 처리를 한다.
MSA A에 동기화 요청을 하여 현재 정보로 재연동 처리를 한다.
1-2-5. MSA B에서 외부 연동 전문 잘못 생성한 장애
외부로 발행 되는 전문을 수정 하여 재전송 하는 기능 제공
1-2. 문제점
MSA A에서 Kafka 연동 대상 테이블 하나에 대해서 대량 패치가 발생하면 MSA B에 전달하여 처리를 해야 하지만 MSA A에서 DB 패치 후 메세지 기반의 전문을 생성 하여 발행하면 되는데 해당 기능이 없어 대상이 되는 외부 시스템에 동기화 문제가 있다.
2. 문제 해결 방안
특정 테이블의 값을 변경하는 패치는 서비스 운영 중에 빈번히 발생하는 문제로 Legacy 시스템에서도 많은 시스템과 연관이 있어서 다양한 방법으로 각 시스템으로 전파한다, Legacy 시스템에서 전파하는 방법은 다음과 같은 것들이 있다.
DB 테이블에 트리거를 통한 연동
변경된 정보를 문서로 만들어 연관 시스템으로 메일과 같은 오프라인 경로로 전달
별도의 시스템에서 변경 정보를 감지 하여 연동
MSA에서는 어떤 방법으로 해결을 해야 하는지 생각을 해 보면 Legacy 시스템과 크게 차이가 나지 않는다. 특히 특정 테이블이 변경되어 단순히 해당 테이블의 정보만 전달하여 처리하는 것은 다음 기능으로 확인 할 수 있다.
Kafka 이벤트 발행하기 위한 태이블 당 CUD를 처리 하는 기능 제공 ( 데이터 조정 화면 )
필요한 요소는 다음과 기본 항목이 필요하다.
CUD command
CUD 발생 테이블
Event Message
테이블 하나 당 하나의 이벤트로 변경되는 곳에서 publish 발행
해당 Topic을 받는 모든 subscriber에서 수신하여 처리
Message Topic ( 복합 정보 )
복합 정보를 구성하는 서비스 개발 하여 메세지 발행
Last updated
