204. (TWOK/WORK) [업무 이슈] AWS MQTT Shadow Reported 타이밍과 Shadow Get 타이밍이 맞지 않아 API 에러 코드 반환 이슈

---

[제 목]

​

주제 : 투케이2K 업무 정리

​

타이틀 : 투케이 / 2k / 업무 정리

​

제목 : [업무 이슈] AWS MQTT Shadow Reported 타이밍과 Shadow Get 타이밍이 맞지 않아 API 에러 코드 반환 이슈

​

 

---

[내 용]

​

------------------------------------------------------------------------------
[개발 및 테스트 환경]
------------------------------------------------------------------------------

- 제 목 : [업무 이슈] AWS MQTT Shadow Reported 타이밍과 Shadow Get 타이밍이 맞지 않아 API 에러 코드 반환 이슈


- 테스트 환경 : AWS / Iot / MQTT / Shadow


- 사전) 👉 Aws Iot Core 간단 설명 : 

  >> AWS IoT 는 IoT 디바이스를 다른 디바이스 및 AWS 클라우드 서비스에 연결하는 클라우드 서비스를 제공합니다.

  >> 디바이스가에 연결할 수 있는 경우 AWS IoT는 AWS 가 제공하는 클라우드 서비스에 디바이스를 AWS IoT 연결할 수 있습니다.

  >> AWS IoT Core 메시지 브로커는 MQTT 및 MQTT over WSS 프로토콜을 사용하여 메시지를 게시하고 구독하는 디바이스 및 클라이언트를 지원합니다. 
  
    - HTTPS 프로토콜을 사용하여 메시지를 게시하는 디바이스와 클라이언트도 지원합니다.


- 사전) 👉 MQTT (Message Queuing Telemetry Transport) 설명 : 

  >> MQTT 는 경량 메시지 프로토콜로, 주로 IoT(사물인터넷) 환경에서 사용됩니다

  >> MQTT 목적 : 제한된 네트워크 환경(저속, 불안정)에서 효율적으로 메시지를 주고받기 위해 설계

  >> MQTT 기반 : TCP/IP 위에서 동작

  >> MQTT 패턴 : Publish/Subscribe 모델을 사용

    - Publisher : 메시지를 발행하는 클라이언트

    - Subscriber : 특정 주제(topic)를 구독하는 클라이언트

    - Broker: 메시지를 중개하는 서버 (예: Mosquitto)

  >> MQTT 주요 특징 : 

    - 경량성 : 헤더가 매우 작음(2바이트부터 시작)

    - QoS (Quality of Service) : 
      $ QoS 0: 최대 한 번 전달(보장 없음)
      $ QoS 1: 최소 한 번 전달(중복 가능)
      $ QoS 2: 정확히 한 번 전달(가장 안전)

    - 지속 연결 : KeepAlive로 연결 상태 유지

    - Last Will and Testament (LWT) : 클라이언트 비정상 종료 시 브로커가 메시지 발행

    - 토픽 기반 라우팅 : 계층적 구조(/home/temperature 등)

------------------------------------------------------------------------------





------------------------------------------------------------------------------
[이슈 사항]
------------------------------------------------------------------------------

1. 사용자가 특정 실시간 영상 접속 확인 API 요청 시 기기 Reported 응답과 백엔드 서버에서 Shadow 를 Get 으로 읽는 타이밍이 맞지 않아 '사용자 최대 시청 중입니다.' 팝업창 표시 이슈


2. ✅ 기존 로직 설명 : 

  >> 프론트 앱 특정 사용자가 실시간 영상 재생 종료 수행

  >> 기기는 사용자 관리 userList 배열에서 접속 해제 된 특정 사용자를 제거하고 현재 접속 된 사용자 userList reported 보고 수행

  >> 프론트 앱 특정 사용자가 기기 영상 접속 요청 백엔드 API 호출 수행

  >> 백엔드 서버에서는 특정 기기 사용자 관리 shadow 를 get 으로 읽어 userList 에 포함 된 최대 시청자 수 확인

  >> [IF] 최대 시청자 수가 되지 않아 정상 영상 접속이 가능한 경우 영상 재생에 필요한 webRTC Arn 및 STS 토큰 정보 반환

  >> [ELSE] 최대 시청자 수가 이미 다 찬 경우는 서버 에러 코드 반환 수행

  >> 프론트 앱 특정 사용자는 정상적으로 영상 시청이 가능한 경우 WebRTC 연결 수행 / 서버 에러코드가 내려온 경우 에러 팝업창 표시 수행

------------------------------------------------------------------------------





------------------------------------------------------------------------------
[원인 파악 및 증상 재현]
------------------------------------------------------------------------------

1. 프론트 앱에서 실시간 영상 재생 종료 수행


2. 기기는 사용자 관리 userList 배열에서 접속 해제 된 특정 사용자를 제거하고 현재 접속 된 사용자 userList reported 보고 수행

  >> ❌ 여기에서 네트워크 지연 이슈 발생 : shadow reported 보고 지연


3. 프론트 앱 특정 사용자가 기기 영상 접속 요청 백엔드 API 호출 수행


4. 백엔드 서버에서는 특정 기기 사용자 관리 shadow 를 get 으로 읽어 userList 에 포함 된 최대 시청자 수 확인


5. 기기는 사용자 관리 userList 배열이 아직 reported 되지 않아 shadow 를 get 으로 읽었을 때 최대 시청자 수가 이미 가득 찬 것 확인


6. ❌ 백엔드 서버는 앱 프론트에 에러 코드 반환 수행 > 이후 shadow reported 가 반영 되어 userList 배열이 clear 된 것 확인

------------------------------------------------------------------------------






------------------------------------------------------------------------------
[조치 내용]
------------------------------------------------------------------------------

1. 앱 프론트에서 실시간 영상 재생 정보 요청 API 호출 시 aws shadow reported 딜레이 반영을 고려해 API 폴링 조회 로직 추가


2. ✅ 변경 된 로직 설명 : 

  >> 프론트 앱 특정 사용자가 실시간 영상 재생 종료 수행

  >> 기기는 사용자 관리 userList 배열에서 접속 해제 된 특정 사용자를 제거하고 현재 접속 된 사용자 userList reported 보고 수행

  >> 프론트 앱 특정 사용자가 기기 영상 접속 요청 백엔드 API 호출 수행

  >> 백엔드 서버에서는 특정 기기 사용자 관리 shadow 를 get 으로 읽어 userList 에 포함 된 최대 시청자 수 확인

  >> [IF] 최대 시청자 수가 되지 않아 정상 영상 접속이 가능한 경우 영상 재생에 필요한 webRTC Arn 및 STS 토큰 정보 반환

  >> [ELSE] 최대 시청자 수가 이미 다 찬 경우는 서버 에러 코드 반환 수행

  >> ✅ 프론트 앱 특정 사용자는 정상적으로 영상 시청이 가능한 경우 WebRTC 연결 수행 / 서버 에러코드가 내려온 경우 일정 시간 딜레이 후 기기 영상 접속 요청 백엔드 API 재호출 수행

    - 백엔드 API 재호출은 최대 3회를 수행하며, 재요청 시 마다 3초 대기 후 API 를 재요청 하도록 로직 구현

    - 최종적으로 폴링이 모두 실패한 경우 에러 팝업창 표시 / 정상 접속이 가능한 경우 WebRTC 연결 수행

------------------------------------------------------------------------------





------------------------------------------------------------------------------
[참고 사이트]
------------------------------------------------------------------------------

[Aws Shadow 섀도우 토픽 구독 및 publish 요청 이후 타임아웃 TimeOut 로직 처리]

https://kkh0977.tistory.com/8079

https://blog.naver.com/kkh0977/223906176453?trackingCode=blog_bloghome_searchlist


[Aws Iot Core] Fleet provisioning 플릿 프로비저닝 설명 및 동작 프로세스 정리

https://kkh0977.tistory.com/7439

https://blog.naver.com/kkh0977/223691943757?trackingCode=blog_bloghome_searchlist


[Aws Iot Core] Fleet provisioning 플릿 프로비저닝 수행 방법 정리 - 클레임 인증서 , 신뢰할 수 있는 사용자

https://blog.naver.com/kkh0977/223779257161?trackingCode=blog_bloghome_searchlist


[Aws Iot Core] Aws 프로비저닝 수행 및 섀도우 Shadow 토픽 Topic 구독 시 와일드 카드 (wild card) 설명 정리

https://blog.naver.com/kkh0977/223825295723?trackingCode=blog_bloghome_searchlist


[MQTT (Message Queueing Telemetry Transport) 통신 설명]

https://kkh0977.tistory.com/3631

https://blog.naver.com/kkh0977/222971771381?trackingCode=blog_bloghome_searchlist

------------------------------------------------------------------------------

 

---

[참고 사이트]

​

https://kkh0977.tistory.com/8079

144. (TWOK/LOGIC) [android] Aws Shadow 섀도우 토픽 구독 및 publish 요청 이후 타임아웃 TimeOut 로직 처리

---