펌뱅킹 이중화 완전정리 - ASCS ERS NAS Pacemaker HA 구조

안녕하세요. 아는 형입니다.

얼마 전에 BC 담당자랑 DB 이중화 관련 구성한다고 했을때 펌뱅킹 시스템의 이중화 처리 요청을 같이 했습니다. 이때 같이 리뷰를 하던 중 BC가 펌뱅킹 이중화에 대해 전혀 이해를 못하고 있어 설명을 해줘야 하는 상황이 왔습니다. 아무래도 외부 BC를 소싱해서 구축하는 경우, 고객사나 계열사에 구축된 펌뱅킹 시스템이 어떻게 돌아가는지 알지 못하는 상태에서 지원을 해달라고 하니 모르는 반응도 이해가 되었지요. 그래서 제가 원하는 이중화 구조 및 왜 이중화가 필요한지부터 설명을 할 필요가 있었습니다.

예를 들어 운영 중 발생했었던 장애 케이스로 펌뱅킹 서비스가 떠 있던 Active 서버에 장애가 나서 SAP DB 이중화로 Standby 서버로 넘어갔는데, 정작 Active 서버에는 펌뱅킹 서비스가 여전히 살아 있어서 양쪽에서 동시에 서비스가 돌다가 지급 처리 시 전문 파일이 길을 잃어 지급처리에 문제가 발생하여 장애로 이어진 사례라던가 반대로 펌뱅킹 서비스가 죽었는데 SAP 전체가 Standby 서버로 넘어가버린 황당한 사례. 이 둘을 예로 들어 펌뱅킹 이중화가 왜 필요한지 설명을 했지만 BC 입장에서는 그래서 어떻게 해달라는 건가 라는 반응이 나왔죠. 특히 계열사에 소속된 BC라면 모를까 외주 컨설턴트면 나는 잘 몰라요의 반응이 많았었습니다. 프로젝트 일정은 정해져있고 정해진 기간 내에 시스템을 빠르게 구성해야 하는 저희 입장에서는 BC가 이렇게 나오면 꽤 답답한 상황이 되죠.

그래서 이번엔 아예 저부터 이 구조를 정확히 이해하고 있어야 겠다는 생각이 들었습니다. 그래야 상대방 담당자도 맞춰서 이해하고, 제가 원하는 방향대로 구성해줄 수 있을 테니까요.

결론부터 말하면, SAP가 하나의 거대한 Active/Standby 덩어리로 움직인다고 생각하면 이 질문 자체가 성립하지 않습니다. 실제로는 완전히 다른 계층의 HA 구성이 되어있는 것이고 그중 하나가 죽었다고 나머지가 같이 넘어갈 이유는 없습니다. 이 글에서는 펌뱅킹(Firm Banking) 이중화를 예로 들어서, SAP Application Server, ASCS, ERS, DB HA, NAS, 그리고 이걸 지휘하는 Pacemaker 같은 Cluster Solution이 각각 어떤 역할을 하는지 하나씩 뜯어보겠습니다.

지금 구성을 계층별로 나눠보면

일단 표로 정리하고 시작하는 게 낫겠습니다. 나중에 다시 돌아와서 참고하기 좋게요.

구분	역할	장애 발생 시 목적
SAP Application Server	SAP 업무 프로그램 실행	다른 AP에서 SAP 업무 지속
ASCS	Message Server + Enqueue Server	SAP 중앙 서비스 유지
ERS	Enqueue Lock 정보 복제	ASCS 장애 시 Lock 정보 보호
NAS / File Server	펌뱅킹 송·수신 파일 공유	어느 AP에서 데몬이 실행돼도 동일 파일 접근
펌뱅킹 데몬	은행과 전문 송·수신	장애 시 다른 AP에서 재기동
Database HA	SAP 데이터 저장	Primary DB 장애 시 Standby DB로 전환
Pacemaker 등 Cluster	서비스 상태 감시 및 Failover 제어	장애 시 서비스를 올바른 노드에서 재기동

여섯 개가 넘는 영역이 각자 다른 목적으로 움직이고 있습니다. SAP 중앙 서비스 이중화, DB 이중화, 파일시스템 공유, 펌뱅킹 데몬 이중화는 전부 서로 다른 계층의 이야기입니다. 이걸 하나로 뭉뚱그려서 생각하는 순간부터 설계도 꼬이고, 장애 대응 시나리오도 꼬입니다.

전체 그림 한 장으로 먼저 보고 가자

텍스트로만 설명하면 감이 잘 안 오니까, 구조를 그대로 옮겨보겠습니다.

여기서 핵심은 딱 하나입니다. AP1, AP2, AP3가 전부 동일한 NAS의 펌뱅킹 Directory를 바라보고 있다는 것. 그래서 AP1에서 펌뱅킹 데몬이 돌다가 문제가 생겨도, AP2가 같은 NAS 파일을 그대로 이어받아서 서비스를 계속할 수 있습니다.

다만 조건이 하나 붙습니다. 펌뱅킹 데몬은 원칙적으로 한 시점에 하나의 Active 인스턴스만 실행되도록 제어해야 합니다. AP1과 AP2에서 동시에 같은 데몬이 돌면 같은 송신 파일을 중복 전송하거나 동일 수신 파일을 중복 처리하는 사고로 이어질 수 있습니다.

NAS(File Server)가 하는 일 — 그리고 놓치기 쉬운 함정

NAS는 Network Attached Storage의 약자입니다. 여러 서버가 네트워크로 동일한 파일을 공유해서 쓸 수 있게 해주는 공유 Storage인데, 회사에서 다들 쓰는 공용 Network Drive랑 개념은 비슷합니다. 다만 서버 시스템에서 쓰는 고가용성 공유 저장공간이라는 점이 다르죠.

AP1에서 /firmbank/send/A001.dat 파일을 만들었다면 AP2에서도 그 파일이 그대로 보입니다. 그러니까 펌뱅킹 프로그램 자체가 AP1에서 AP2로 넘어가더라도 파일을 별도로 복사할 필요가 없는 거죠.

좀 더 구체적으로 볼까요. AP1에서 은행 송신 파일을 /NAS/FIRMBANK/SEND/PAYMENT_20260910_001.dat 위치에 만들었다고 합시다. 데몬이 AP1에서 돌다가 장애가 났는데, AP2가 같은 NAS를 보고 있다면 AP2에서도 바로 같은 경로의 같은 파일을 확인할 수 있습니다. Local Disk 간 복사 절차 자체가 필요 없는 겁니다. SAP도 HA 시스템의 공유 디렉터리를 NFS, Shared Disk, Cluster File System 같은 외부 기술로 구성할 수 있다고 안내하고 있고, /sapmnt/<SID>나 /usr/sap/trans도 대표적인 Shared File System 대상입니다.

그런데 여기서 실무자들이 자주 놓치는 부분이 있습니다. 혹시 이런 질문 받아보신 분 계신가요 — “AP는 3대인데 NAS는요?”

AP 서버가 3대라도 NAS가 물리적으로 딱 한 대뿐이고 자체 이중화가 안 돼 있다면, 그 NAS 자체가 새로운 SPOF(Single Point of Failure)가 됩니다.

상황	결과
AP1 장애	AP2 사용 가능 → OK
AP2 장애	AP3 사용 가능 → OK
NAS 장애	AP1/AP2/AP3 모두 파일 접근 불가 → 펌뱅킹 중단

“모든 AP가 동일 NAS를 쓴다”와 “NAS 자체가 HA로 구성돼 있다”는 완전히 다른 이야기입니다. 실제 운영 환경에서는 Storage Controller 이중화, NAS Cluster, Active/Standby Storage, NFS HA 등 여러 방식을 쓸 수 있고, 이건 회사별 인프라 구성과 HA 솔루션에 따라 달라집니다.

ASCS, 정확히 뭘 하는 놈인가

자 여기서 AP1번에 설치했다고 하는 ASCS가 뭘까요? ASCS는 ABAP SAP Central Services의 약자입니다. SAP ABAP 시스템의 핵심 중앙 서비스를 담당하는데, 대표적으로 Message Server와 Enqueue Server 두 가지가 여기 들어갑니다. SAP 공식 문서에서도 ASCS Instance에 ABAP Message Server와 Enqueue Server가 포함된다고 설명합니다.

Message Server

Message Server는 SAP Application Server들끼리의 통신과 시스템 내 Instance 정보를 관리하는 중앙 서비스입니다. SAP GUI Logon Group을 이용한 Logon Load Balancing에서도 Message Server가 Application Server 정보를 활용합니다.

여기서 오해하기 쉬운 게 하나 있습니다. “Message Server가 모든 AP 부하를 직접 처리한다”고 이해하면 조금 다릅니다. 실제 사용자 요청을 처리하는 건 각 Application Server의 Dispatcher와 Work Process고, Message Server는 SAP System의 중앙 통신 및 Logon 정보를 관리하는 역할입니다.

Enqueue Server

Enqueue Server는 SAP의 Logical Lock을 중앙에서 관리합니다. A 사용자가 전표를 수정하는 중에 B 사용자가 같은 Business Object를 동시에 건드리면 데이터 정합성이 깨질 수 있는데, 이걸 막는 게 Logical Lock입니다.

Enqueue Server가 가진 Lock Table은 SAP Transaction의 데이터 정합성 측면에서 꽤 중요한 정보입니다.

ERS는 ASCS의 백업이 아니다

ERS는 Enqueue Replication Server입니다. 쉽게 말하면 ASCS의 Enqueue Server가 갖고 있는 Lock 정보를 다른 서버에 복제해두는 역할이라고 보면 됩니다.

ASCS가 갑자기 장애가 나면 Enqueue Memory에 있던 Lock 정보가 손실될 수 있는데, ERS가 이 정보를 복제해뒀다가 HA 환경에서 Enqueue 서비스를 복구할 때 씁니다. SAP 공식 문서도 ERS가 ASCS Enqueue Server의 Lock Table 복사본인 Replication Table을 보유한다고 정의합니다. 최근 ABAP Platform 환경에서는 Enqueue Server 2 / Enqueue Replicator 2 구조가 쓰일 수 있는데, 정확한 Failover 방식은 SAP Release와 HA Solution에 따라 차이가 있습니다.

이 부분에서 제가 처음에 꽤 헷갈렸던 게, “ASCS = Active, ERS = ASCS Standby”라고 단순하게 도식화해버린 거였습니다. 이렇게 이해하면 틀린 건 아닌데 반쪽짜리입니다. ERS가 평상시에 ASCS 전체 기능을 그대로 수행하는 게 아니거든요. HA Cluster가 장애를 감지하면 ASCS 서비스를 다른 Cluster Node에서 새로 기동하면서, ERS에 복제돼 있던 정보를 활용해서 Enqueue 서비스를 보호하는 구조입니다. SAP는 HA 환경에서 ASCS와 ERS를 Cluster Software의 제어 대상으로 구성하도록 안내하고 있습니다.

DB 이중화는 또 다른 이야기

DB HA는 앞의 ASCS/ERS와는 완전히 다른 계층입니다.

평상시엔 Active DB가 SAP 요청을 처리하고 Standby DB는 Active데이터를 복제만 합니다. Active DB에 장애가 나면 HA Solution이 Standby DB를 새 Active로 승격시키는 형태로 구성할 수 있습니다.

다만 DB HA 방식은 쓰는 DBMS에 따라 다릅니다. SAP HANA라면 SAP HANA System Replication을 이용한 HA 구성이 대표적이고, Oracle, DB2, MS SQL은 각각의 DB와 Cluster Solution에 따라 방식이 달라집니다. 그래서 “SAP는 DB가 Active/Standby로 동작한다”고 뭉뚱그리기보다는, “현재 인프라는 DB HA 솔루션을 통해 Primary DB 장애 시 Standby DB로 전환되도록 구성돼 있다”고 표현하는 게 더 정확합니다.

Pacemaker — 누가 어디서 뭘 살릴지 결정하는 놈

Pacemaker는 Linux 환경에서 쓰는 대표적인 Cluster Resource Manager입니다. 서버 자체가 아니라, 어떤 서비스가 살아 있는지 확인하고 장애가 나면 어느 서버에서 그 서비스를 다시 실행할지 결정하고 제어하는 HA 관리자라고 보면 됩니다.

여기서 진짜 중요한 게 Split-Brain과 중복 실행 방지입니다. AP1에서 기존 펌뱅킹 Process가 완전히 종료되지 않은 상태에서 AP2가 새 Process를 띄워버리면 양쪽에 서비스가 떠있게 되면서 펌뱅킹 지급시점에 지급처리시 파일을 찾는데 문제가 발생할 수 있는데요. 이 상태는 펌뱅킹에서는 정말 위험합니다. 동일 지급 파일을 두 Process가 처리하면 은행 전문 중복 송신으로 이어질 수 있거든요.

그래서 Cluster Script는 작성 시에는 기존 프로세스를 확인하고 Active 서비스를 확실하게 종료 처리를 한 후 Standby에 서비스가 올라갔을 때 다시 펌뱅킹 서비스를 살리는 로직을 추가해야 합니다. 이 부분은 BC나 네트워크 담당자가 펌뱅킹 모듈이 어떻게 구성되었는지 모를 수 있으므로 같이 Script파일을 확인해야 합니다.

구체적인 Pacemaker Resource나 fencing 정책, Script 내용은 회사마다 OS/Cluster/펌뱅킹 솔루션 설계에 따라 다릅니다. 여기 적은 건 SAP 표준 기준으로 가능한 시나리오이고, 실제 커스터마이징이나 내부 운영 정책에 따라 달라질 수 있다는 점은 짚고 넘어가야겠네요.

펌뱅킹 장애와 ASCS Failover를 분리해야 하는 이유

이게 사실 이 글에서 제일 하고 싶었던 이야기입니다. 처음에 언급했던 BC 담당자의 질문으로 돌아가 볼게요.

AP1 서버 안에 SAP 관련 서비스와 FirmBank 서비스가 같이 떠 있다고 합시다. 여기서 FirmBank 서비스가장애가 났다고 해서 AP1 서버 전체가 죽으면 안되겠지요.

항목	상태
AP1 Server	정상
SAP ASCS	정상
OS	정상
Network	정상
FirmBank Daemon	장애

이 상황에서 원하는 동작은 “FirmBank 서비스만 AP1 → AP2로 Failover”지, “ASCS까지 AP1 → AP2로 Failover”일 필요는 없습니다. 즉 펌뱅킹 Resource Group과 SAP ASCS/ERS Resource Group의 장애 범위를 분리해서 설계해야 합니다. 그래야 펌뱅킹 데몬 하나의 장애 때문에 멀쩡히 돌고 있는 SAP Central Service까지 불필요하게 Failover되는 걸 막을 수 있습니다.

SAP 공식 HA 문서도 ASCS/ERS와 Application Server가 각각 별도의 역할을 가지며, Application Server Instance 자체는 일반적으로 ASCS와 동일한 SPOF 개념으로 취급하지 않는 구조를 설명하고 있습니다.

전체 구조를 다시 정리해봅시다.

중요 조건만 다시 짚으면 이렇습니다.

모든 AP에서 동일 NAS 접근
FirmBank 데몬(서비스)은 1개만 Active
기존 Process 종료 확인 후 신규 Process 시작
FirmBank 서비스 Failover와 SAP ASCS Failover 분리
DB Failover 역시 별도 HA 영역
NAS 자체의 HA 여부도 별도로 확인

결국 이 구성은 하나의 거대한 Active/Standby 구조가 아니라, 여러 HA Layer가 겹쳐 있는 구조로 이해하는 게 맞습니다. 계층별로 막는 장애도 다릅니다 — AP 서버 이중화는 SAP ABAP 프로그램의 처리 능력과 가용성을, ASCS+ERS는 Message Server와 Logical Lock이라는 중앙 서비스를, DB HA는 회계전표·Master Data·지급정보 같은 Database 자체를, NAS는 AP가 바뀌어도 동일한 송수신 파일을 쓸 수 있게, 펌뱅킹 Daemon HA는 은행과의 실제 전문 송수신을, 그리고 Pacemaker 같은 Cluster Solution은 어떤 서버에서 어떤 서비스를 Active로 실행할지를 감시하고 제어합니다.

이 여섯 개는 서로 대체 관계가 아닙니다. ASCS/ERS가 있다고 펌뱅킹 Daemon이 자동으로 이중화되지 않고, DB HA가 있다고 NAS가 자동으로 이중화되지 않습니다. AP가 3대 있다고 ASCS가 자동으로 HA가 되는 것도 아니고, NAS를 공유한다고 펌뱅킹 프로세스 중복 실행이 자동으로 방지되는 것도 아닙니다. 계층마다 별도의 HA 설계가 필요합니다.

정리하며

다시 처음 질문으로 돌아가면, “펌뱅킹 데몬 하나 죽었다고 SAP 전체를 Failover 해야 하냐”는 질문에 대한 답은 이제 명확합니다. 아니요, 그럴 필요 없습니다. 오히려 그렇게 설계하면 안 됩니다.

현재 구조에서 BC/인프라 담당자와 반드시 합의해야 하는 핵심은 딱 한 문장으로 정리됩니다. 펌뱅킹 서비스 장애와 SAP 서비스 장애를 동일한 장애로 판단하지 않는다. FirmBank 서비스가 Down됐다면 SAP가 정상인 AP1 서버 자체를 Failover시킬 이유가 없을 수 있습니다. FirmBank Resource만 다른 AP로 이동시키되, 기존 Node의 Process가 완전히 종료됐는지 검증한 후에 새 Node에서 서비스를 시작해야 합니다. AP1, AP2, AP3가 모두 같은 NAS를 보고 있으니, 펌뱅킹 서비스가 어느 서버에서 실행되든 동일한 송·수신 파일을 쓸 수 있다는 것도 함께요.

정리하면 이 세 문장입니다. SAP ASCS/ERS HA는 SAP 중앙 서비스를 보호합니다. DB HA는 SAP 데이터를 보관하는 Database를 보호합니다. NAS + Cluster/Pacemaker 기반 펌뱅킹 HA는 은행과 전문을 송수신하는 펌뱅킹 서비스를 보호합니다. 세 영역은 서로 연결돼 있지만, 각각 독립적인 장애 영역(Failure Domain)으로 이해하고 설계하는 게 맞습니다. 다음 글에서는 실제로 Scenario 7 — 은행 송신 도중 Failover가 발생했을 때 중복 송신을 어떻게 막았는지 실제 로그를 가지고 풀어보겠습니다.

참고 자료

ASCS / ERS / Enqueue

SAP Help – High Availability with Standalone Enqueue Server 2
SAP Help – High Availability with the Standalone Enqueue Server
SAP Note 2630416 / 2711036 (SAP for Me 로그인 필요)

공유 파일시스템(NAS) / 클러스터

Database HA

펌뱅킹 이중화 구성은 어떻게 해야할까? With ASCS ERS NAS Pacemaker HA 구조