M2M 협업을 위한 경량형 미들웨어: DPWS‑Raft vs. ZooKeeper 비교 연구

초록

본 논문은 사물인터넷 환경에서 기기 간 협업을 지원하기 위해 기존 데이터센터용 코디네이션 서비스인 ZooKeeper와 경량 웹 서비스 스택인 DPWS에 Raft 합의를 적용한 구현을 비교한다. 실험 결과, DPWS‑Raft 조합이 제한된 자원에서도 충분한 성능을 보이며, ZooKeeper에 비해 배포·운용 유연성이 높음을 확인한다.

상세 분석

이 연구는 M2M 시나리오에서 서비스 구성·조정을 담당하는 미들웨어의 두 축을 심도 있게 탐구한다. 첫 번째 축은 Apache ZooKeeper가 제공하는 파일‑시스템형 추상화와 Zab 프로토콜 기반 복제 메커니즘이다. ZooKeeper는 강력한 일관성을 보장하고 리더‑팔로워 구조를 통해 장애 허용성을 제공하지만, Java SE 1.6 이상을 요구하고 JVM 기반이므로 리소스가 제한된 임베디드 디바이스에 적합하지 않다. 특히, Java Micro Edition이나 Android와의 호환성이 부족해 IoT 현장 적용에 제약이 있다.

두 번째 축은 Devices Profile for Web Services(DPWS) 스택이다. DPWS는 SOAP, WSDL, WS‑Addressing, WS‑Security 등 전통적인 웹 서비스 표준을 경량화하여 구현하고, WS‑Discovery와 WS‑Eventing을 통해 동적 디바이스 탐지와 이벤트 전파를 지원한다. 그러나 표준 자체는 복제·장애 복구 메커니즘을 제공하지 않는다. 이를 보완하기 위해 저자들은 WS4D JMEDS 기반에 Raft 합의 알고리즘을 구현하였다. Raft는 리더 선출, 로그 복제, 안전성 보장을 단순화한 프로토콜로, Paxos 대비 구현 복잡도가 낮고, 클러스터 구성원 변경을 자연스럽게 지원한다.

구현 상세에서는 서버와 클라이언트 두 종류의 엔티티를 정의하고, 서버 내부에 Log, RaftService, ServerClient, TimeoutTask, StateTask 등 5개의 핵심 모듈을 배치하였다. 각 서버는 현재 term, votedFor, currentLeader, nextIndex, matchIndex와 같은 Raft 메타데이터를 유지하며, 리더는 AppendEntries RPC를 통해 로그를 복제하고, 후보자는 RequestVote RPC로 선출 과정을 진행한다. 클라이언트는 임의의 서버에 요청을 보내고, 비리더일 경우 최신 리더 주소를 반환받아 재전송한다.

실험은 제한된 CPU·메모리 환경(예: Raspberry Pi 수준)과 네트워크 지연·패킷 손실을 가정한 시나리오에서 수행되었다. 주요 측정 지표는 쓰기/읽기 레이턴시, 초당 처리량(througphut), 장애 복구 시간이다. 결과는 DPWS‑Raft가 ZooKeeper 대비 평균 15~30% 높은 레이턴시를 보였지만, 리소스 사용량은 40% 이하로 크게 절감되었으며, 리더 장애 시 2초 이내에 새로운 리더가 선출되어 서비스 중단이 최소화되었다. 또한, DPWS의 WS‑Discovery를 활용한 동적 클러스터 구성은 기존 ZooKeeper의 정적 설정 방식보다 운영 편의성을 크게 향상시켰다.

결론적으로, 논문은 “경량·유연·충분한 성능”이라는 세 축을 만족하는 M2M 코디네이션 미들웨어로서 DPWS‑Raft 조합을 제시한다. 이는 자원 제한이 심한 IoT 디바이스에서도 신뢰성 있는 상태 복제를 가능하게 하며, Java 기반 대형 시스템에 비해 배포·관리 비용을 현저히 낮춘다. 향후 연구에서는 보안 강화, 다중 데이터센터 연동, 그리고 Raft 로그 압축·스냅샷 기법을 적용한 장기 운영 안정성 검증이 필요하다.