기존 아키텍처

기존 IoT 아키텍처는 아래와 같았습니다.

IoT BIz Request 서버는 AWS ASG로 묶여있어 동적으로 손쉽게 개수를 조절할 수 있습니다. 또한 Request 서버는 사용자로부터 HTTP 요청을 받아므로 AWS ALB와 연결되어 있습니다. AWS가 제공하는 ASG와 ALB의 기능 덕분에 Request 서버의 수가 늘어나거나 줄어들어도 이를 Target Group에 자동으로 반영해주므로 개발자가 별도의 작업을 할 필요가 없습니다.

그러나 IoT Relay 서버는 AWS ASG로 묶여있지 않습니다. 그대신 여러 대의 EC2를 생성하고, 그 위에서 수동으로 Relay 서버를 실행하는 형태를 띠고 있습니다.

킥보드는 출고가 될 때 연결될 서버의 IP를 저장하고 있습니다. 그리고 전원이 연결되면 저장된 서버 IP와 통신을 시도하게 됩니다. 즉, 서버가 킥보드를 찾아서 연결하는 방식이 아니라 킥보드가 자신이 연결될 서버를 미리 알고 있고 킥보드가 직접 서버에 연결합니다.

EC2를 재시작하다가 IP를 잃어버리게 된다면 그 IP를 알고 있던 킥보드는 더이상 서버에 연결될 수가 없습니다. 이 킥보드들을 다시 서버에 연결하기 위해서는 직접 하나하나 찾아가서 블루투스로 IP를 바꿔줘야 합니다. 이를 방지하기 위해서 Relay 서버는 모두 고정 IP를 가지고 있습니다.

예를 들어 11111 킥보드와 11112 킥보드는 IoT Relay A 서버와 연결을 시도하며 11113 킥보드는 IoT Relay B와 연결을 시도합니다. 만약 11113 킥보드를 IoT Relay A 서버에 연결하기 위해서는 킥보드에게 저장된 서버의 IP를 IoT Relay A 서버의 IP에서 IoT Relay B 서버의 IP로 바꿔야만 합니다.

또한 Relay 서버는 고유한 이름(A, B 등)을 가지고 있습니다. 이는 EC2 환경 변수에 설정되어 있으며, Relay 서버가 처음 시작될 때 환경 변수에서 이 값을 가져와 초기화하므로 런타임에서 이 값을 수정할 수 없습니다. Relay 서버의 이름을 변경하려면 EC2의 환경 변수를 수정하고 Relay 서버를 수동으로 다시 시작해야 합니다. 이러한 특성때문에 IoT Relay 서버는 ASG를 사용할 수 없습니다. 대신 수동으로 EC2를 생성하고 각각이 고유한 이름을 가지도록 환경 변수를 설정해야만 합니다.

Relay 서버는 고유한 이름을 가지고 있기 때문에 이 이름을 가지고 각자가 다른 Kafka Topic을 구독하는 것이 가능합니다. 위 그림에서 Relay 서버가 구독하는 Topic을 나타내면 다음과 같습니다.

즉, Relay 서버의 이름과 Kafka Topic의 이름은 일대일 대응 관계를 가집니다.

킥보드에게 메시지를 보내려면

Biz Request 서버가 킥보드에게 메시지를 보내기 위해서는 해당 킥보드가 연결된 Relay 서버를 찾고, 그 Relay 서버가 구독하고 있는 Kafka Topic을 찾아서 메시지를 보내면 됩니다.