그렇다 그룹 기능이다. 유저 그룹과 디바이스가 통신을 할 수 있고, 유저 그룹내에서 유저끼리의 통신도 가능하다. 디바이스 자리에 유저를 두면 된다. 메시지를 topic을 가진 인스턴스 갯수 만큼 복사하는 방법도 있는데, 간단하기는 하지만 비효율적이다. 효율적인 방법을 좀 찾아보자.
음.. 그룹 topic를 따로 만드는 방법을 생각할 수 있다.
이 방안은 구성이 단순하다는 장점이 있는데, 가입한 그룹이 많아지면 유지해야 하는 소켓이 함께 늘어나는 단점이 있다. 단점을 어떻게 해결할까 ?
클라이언트가 가지는 부담이다. 서버가 부담을 가지고 가는 것 보다는 클라이언트에게 부담을 주는게 낫겠지 ? 라고 맘편하게 생각하고 무시하는 것도 방법이다. 여기에 더해서 유저가 가입할 수 있는 그룹 topic의 총 갯수를 제한하는 방법도 함께 사용할 수있겠다. SNS 서비스라면 문제가 되겠지만 타협도 가능할 것이다. 하지만 기분이 좋지 않은 건 어쩔 수 없다. 소켓이 늘어나면, 모바일 기기의 전원 소비도 늘어날 거다. Ping 패킷 주기가 10초에 소켓이 50개라면 0.2초마다 패킷을 전송해야 한다. 무시할 수 없는 데이터다.
이 방식의 단점을 제거하거나 회피하기 위한 방법을 생각해 보자.
- 소켓 줄이기 : 그룹이 소수의 인스턴스에 몰아 넣을 수 있다면 좋겠는데.. 글쎄.. 이건 방법이 떠오르지 않는다.
- Ping 패킷 주기 줄이기 : 클라이언트 집단이 Ping 패킷을 보내고 있으므로 현재 전체 서버 상황을 알수 있으며, 그중 내가 속한 그룹을 서비스하는 서버들의 상태를 알 수 있다. 한번의 Ping 패킷으로 여러 서버의 상태 정보를 확인할 수 있으므로 ping 요청을 줄일 수 있다.
클라이언트가 할 일을 서버에서 대신 수행하는 방법도 있다.
유저는 private topic에만 붙어있으면, 알아서 그룹 메시지를 척척 배달해 준다. 클라이언트 입장에서는 깔끔하지만, 서버는 더러워진다.
Private topic 인스턴스가 MQTT Client가 되고 Group topic 인스턴스가 MQTT broker 이 되면, 유저 앞단에 ELB 구성이 가능하다. 각각의 서버 군을 어떻게 효과적으로 관리할 것인지가 주요 이슈가 되겠다. 주키퍼를 이용하던지 혹은 어떤 걸 이용하던지 간에, 관리 솔류션 도입이 필요하다. 주키퍼는 따로 다루어야 하겠다.
/group 토픽을 관리하기 위한 별도의 인스턴스를 뒀는데, 이들 인스턴스가 하는 일을 publisher에 맡기는 방법도 있다. Pubisher가 그룹에 있는 모든 유저를 검사해서 pub하는 식이다.
일단 몇 개의 인스턴스들만으로 그림을 그려봤다. 딱히 구성에 문제는 없는 것 같은데, 이 정도 그림으로는 인스턴스가 수백에서 수천으로 넘어갔을 때 제대로 작동할 지를 예상하기 힘들다. 하나 이상의 subnet으로 구성될 경우, 지역을 넘나들 경우를 상정해서 그림을 그려봐야 할 것 같다.