[보안장비] master-slaves 구조

보안장비 취약점 진단을 수행하던 중, 로그 수집 시스템이 Master-Slave 구조로 구성되어 있는 것을 확인했습니다.
L3 스위치 기반의 보안장비는 SNMP 프로토콜을 통해 로그 정보를 외부 TMS 관리 서버로 전송하고 있었으며, 이 TMS 서버는 하나의 Master와 하나의 Slave로 구성되어 있었고, 각각 다른 IP 주소를 사용하고 있었습니다.

처음에는 단순한 Active-Standby 구조일 것으로 예상했지만, Master는 수집 제어 및 정책을 담당하고, Slave는 데이터를 수집하는 역할을 수행하고 있어, Active-Active 구조에 가까운 Master-Slave 구조라고 판단했습니다.

이 구조는 과거 DNS 서버를 구축할 때, Master가 도메인 영역(zone)을 관리하고, Slave가 이를 복제하여 운영하던 방식과 유사했습니다. 이처럼 Master는 ‘뇌’, Slave는 ‘일꾼’처럼 역할을 분담하며, 보안 로그 수집과 같은 연속적인 작업에서는 부하 분산과 확장성 측면에서 효과적인 구조라고 느꼈습니다.

다만 실제로는 Master와 Slave가 각각 1대씩만 존재하는 1:1 구성으로, 병렬 수집이나 부하 분산이 일어나지 않기 때문에, 이 구조를 단순히 Active-Active로 보기는 어렵습니다.
이 경우 Master는 수집 정책 및 제어를 담당하고, Slave는 실제 로그 수집 및 전송을 수행하는 기능 분리형 Master-Slave 구조로 이해하는 것이 더 적절합니다.

또한, 이 구조에서의 장애 대응은 고가용성(무중단 서비스)보다는 로그 기록 손실 방지에 초점을 맞추고 있습니다. Master 또는 Slave에 장애가 발생하더라도 로그 데이터가 누락되지 않도록 중복 저장과 재전송, 버퍼링 같은 메커니즘을 활용하여, 장애 시에도 중요한 로그 기록이 유지될 수 있도록 설계된 구조라고 판단됩니다.

즉, 현재 구조는 병렬 처리보다는 모듈화와 운영 효율성, 그리고 장애 상황에서 로그 보존에 중점을 둔 설계이며, 향후 시스템 확장과 안정성 확보를 위한 기반으로 볼 수 있습니다.
추후 장비 수나 로그량이 증가할 경우, Slave 노드를 추가하여 실질적인 병렬 수집 구조로 확장할 여지도 충분하다고 생각합니다.