------------------------------------------------------------------------------------ ▣ rtgs 프로젝트 개요 클라우드 환경에서 기본적인 기능에 대해서는 3회차에 걸쳐 테스트를 했는데, 이번 프로젝트에서는 클로드 코드를 통해 업무기능을 완벽히 개발해서 테스트 해보려고해 개발환경은 로컬PC에서 수행 ------------------------------------------------------------------------------------ □ 참고 : C:\ai-dev\workspace\rtgs\docs 폴더내 3회차에 걸친 테스트 결과 보고서, 방안 문서와 의견 등 □ 시스템 — 실시간총액결제(RTGS: Real-Time Gross Settlement) □ 시스템 목표 — 원거리에 위치한 3개 센터에서 A-A-A로 365*24시간 연중무휴 결제서비스를 안정적적으로 제공 □ 프록젝트 목적 — RTGS 프로토타입 시스템 구축 및 테스트 □ 성능 목표 — 10000~20000TPS(이전의 3회차 테스트에서는 접수기능까지만 확인) □ 기능 범위 — 자금이체 신청/접수/청산/조회/정산 □ 데이터 성격 — 트랜잭션(전문/거래), 마스터(기관별 당좌계좌) □ 데이터 형식 — 원본 데이터 XML을 접수 받아서 RTGS시스템 내부에서는 저널(text(?) 축약)로 송수신후 XML로 응답(ISO20022 전문) → 전문 정보는 C:\ai-dev\workspace\rtgs\docs\pacs.7z 파일 참조 □ 사용자 — ADMIN(관리자)/ORG_S(송신기관)/ORG_R(수신기관) □ 기술 스택 — Spring Boot + React + PostgreSQL + 인메모리DB, 이벤트 브로커, 메시지큐 등 □ 시스템 연동 — ERP를 통한 사용자 정보 입수 및 관련 시스템(기존의 회계시스템, 감사시스템, BI시스템 등) 간의 인터페이스(본 프로토타입에서는 제외) 센터 — 3개 센터 Active-Active-Active 동일한 순서로 같은 처리를 수행 □ 테스트 — 3센터 구분은 터미널로 구분하여 동시 부하 테스트 실시 □ 점검대상 — (1) 원격지에 떨어진 3개 센터에서 동일한 순서로 동일한 업무를 수행하는 기능성 (2) 3센터 중에 한개의 센터가 다운되어도 서비스 보장(2개 센터가 다운되면 장애)하는 가용성 (3) 장애가 발생해도 신속하게 데이터 소실없이 자동 복구하는 복원성 □ 프로세스 — (0) RTGS시스템 호출 전에 송신기관에서 송신인 계좌 잔액을 확인하고, 수신기관의 수신인 계좌 확인완료 (1) 송신기관에서 수신기관을 지정하여 3센터 중에 한 센터의 RTGS시스템에 자금이체 전문을 신청 (2) 처리 순서가 정해지고, 나머지 2센터에 순서가 공유(순서를 정하는 역할 GSLB로 구현한다면, 이 GSLB는 3개 센터 중에 한 곳에 위치해야 할지, 또다른 곳에 위치해야 할지, 또따른 곳이라면 이건 센터 간 이중화 안해도 될지 고민임) (3) 각 3센터 모두 동일한 이체업무(RTGS시스템내 송신기관의 당좌계좌에서 이체한 금액을 제하고, 수신기관의 당좌계좌에 더하여 잔액처리) (4) 실제 접수받은 센터에서는 수신기관 앞 이체결과 전문을 통보 □ 관리 — ELK 구성을 통한 로그 수집및 조회 기능 구현 ▣ PC 교체 주의사항 — PC 교체시 C:\ai-dev만 복사 (새 PC에서도 경로를 똑같이 C:\ai-dev로 설정). 복사 전 서비스·인프라를 멈추고 복사(실행 중 DB파일이 잠겨 깨질 수 있음). home\pgsql-data / kafka / es-data / mongo-data는 빼고 복사 → 새 PC에서 재초기화(스크립트가 알아서 다시 생성. 코드·설정만 확실히 오면 됨) ------------------------------------------------------------------------------------ ▣ 서비스 → 전체 프로세스는 C:\ai-dev\workspace\rtgs\docs\UML.xlsx 파일 참조 □CHANEL(Contact Hub for Advanced Networked Entry Liaison) 참가기관(송신)으로부터 거래요청 건을 접수받아 참가기관(송신, 수신)에게 처리결과를 통보하는 서비스 프로세스 개념도 참조 : C:\ai-dev\workspace\rtgs\docs\chanel.png □HERMES(High-Efficiency Rapid Memory Execution for Settlement) 각 센터에서 동일한 거래를 순서대로 처리하여 각 센터 내에 위치한 원장 데이터베이스에 저장하는 결제처리 서비스 프로세스 개념도 참조 : C:\ai-dev\workspace\rtgs\docs\hermes.png □DIOR(Data Integration and Organization Relay) 참가기관(송신)에게 접수한 거래 건을 다중 센터에서 동일하게 처리하기 위한 접수 동기화 서비스 프로세스 개념도 참조 : C:\ai-dev\workspace\rtgs\docs\dior.png □PRADA(Persistent Repository Administrator for Data Aggregation) 각센터에서 처리한 거래처리 결과에 대한 결과 동기화 서비스 프로세스 개념도 참조 : C:\ai-dev\workspace\rtgs\docs\prada.png □LOUIS VUITTON : Leading Operations Unified Information Systems for Validation, Updates, Integration, Tracking, Technology, Operations, and Networks □GUCCI (Global User Communication Control Interface) 3개 센터 간 헬스 체크 센터간 통신을 위한 연계서버(Gateway 역할, Message Queue 역할) 금융기관들(송신기관, 수신기관) 로그인 인증 금융기관들(송신기관, 수신기관)이 호출하는 API 인증 API 서비스 순서 지정 이체신청기관앞 이체결과 송부