[Spring MVC] K-IMS & K-RMS
소개
IoT 플랫폼의 클라우드 서버는 K-IMS, K-RMS, HTML UI 소스 코드 서버 크게 3가지 부분으로 구분됩니다. 특히 K-IMS 와 K-RMS 는 서로 상호 작용을 하며 동작합니다.
- K-IMS 서버는 MQTT 프로토콜을 사용하여 장치들의 상태 모니터링과 제어를 수행합니다.
- K-IMS 서버는 기기들의 제어, 설정, 상태 모니터링과 같은 정보를 가지고 있습니다.
- K-RMS 서버는 가입자 정보, 제품정보, A/S 정보들을 포함합니다.
- K-RMS 서버는 통신사업자의 시스템 운영을 돕기 위한 UI 를 포함하고 있습니다.
- HTML UI 서버는 모바일과 셋톱박스용 웹 UI 를 송신하는 보통의 웹서버입니다.
왜 서버를 둘로 나눴을까요?
같은 시스템 안에 성격이 아주 다른 두 종류의 트래픽이 있었기 때문입니다.
| 구분 | K-IMS (기기 쪽) | K-RMS (사람 쪽) |
|---|---|---|
| 상대 | 센서, 허브, 셋톱박스 | 가입자, 상담원, 운영자 |
| 성격 | 짧은 메시지가 쉬지 않고 오감 | 필요할 때 한 번씩 조회하 고 수정 |
| 중요한 것 | 끊기지 않는 연결, 지연 최소화 | 정확한 이력, 권한 관리 |
| 프로토콜 | MQTT | HTTP REST |
문 열림 센서 하나가 하루에 수백 번 상태를 올립니다. 반면 가입자가 자기 정보를 고치는 일은 몇 달에 한 번입니다. 이 둘을 한 서버에 두면 기기 트래픽이 몰릴 때 상담원 화면이 같이 느려집니다.
책상 하나에서 전화도 받고 서류도 정리하려는 것과 비슷합니다. 둘 다 할 수는 있지만 전화가 몰리면 서류가 밀립니다. 그래서 자리를 나눴습니다.
MQTT 를 쓴 이유
MQTT 는 작은 메시지를 자주 주고받는 기기를 위해 만들어진 프로토콜입니다. HTTP 와 비교하면 차이가 분명합니다.
- 연결을 유지합니다. HTTP 는 요청할 때마다 연결을 새로 맺습니다. 기기가 1분마다 상태를 올린다면 그 준비 비용이 계속 붙습니다. MQTT 는 한 번 연결해 두고 계속 씁니다.
- 서버가 먼저 말을 걸 수 있습니다. "거실 불 꺼"라는 명령은 서버에서 기기로 가야 합니다. HTTP 만으로는 기기가 주기적으로 물어보게 만들어야 하는데, 그러면 반응이 늦거나 쓸데없는 요청이 늘어납니다.
- 헤더가 가볍습니다. 전원과 통신 환경이 넉넉하지 않은 기기에서는 이 차이가 큽니다.
대신 MQTT 는 사람이 쓰는 관리 화면에는 맞지 않습니다. 목록을 조회하고 조건으로 검색하는 일은 REST 쪽이 훨씬 자연스럽습니다. 그래서 프로토콜을 하나로 통일하지 않고 용도에 맞게 나눠 쓰는 구조가 됐습니다.
Structure
담당 범위
- Apache Tomcat 7 서버 REST API 개발 및 배포
- 개발환경: Spring Framework 4, MVC, MySQL, MyBatis
정리
첫 실무에서 만난 구조인데, "왜 이걸 굳이 나눠 놨을까"를 이해하는 데 시간이 좀 걸렸던 기억이 있습니다. 지금 돌아보면 트래픽 성격이 다르면 분리한다는 원칙을 처음 몸으로 배운 자리였던 것 같습니다.
시간이 흘러 서비스를 쪼개는 이야기는 모놀리식에서 15개 서비스 MSA 로 에 다시 적어 두었습니다.