배경

• Redis에서 기존의 room:{roomId}:members:{userId} 구조에 Mediasoup 데이터를 함께 저장할 때
• 효율성에 대해서 고민이 됨

해당 사항의 장단점

해당 Hash는 방에 참여한 멤버의 정적 또는 준정적 사용자 정보를 저장하는 데 사용됨

여기에 mediasoup 관련 동적인 정보를 저장한다면 장단점의 다음과 같음

장점

• 데이터 응집성: 특정 방의 특정 사용자에게 관련된 모든 정보를 한 곳에서 관리하므로 개념적으로 이해하기 쉬움
• 간단히 조회: room:{roomId}:members:{userId} 만 조회하면 해당 사용자의 모든 정보를 한 번에 가져올 수 있음

단점

• Hash의 비효율성 증가
  • Redis의 Hash는 필드 수가 적고 값이 작을 때 효율적임
  • 하나의 Hash에 필드 수가 너무 많거나 값이 매우 커지면 성능이 저하될 수 있음
  • Producer와 Consumer는 N*N 관계로 급증할 수 있어 하나의 hash 필드에 모두 저장하기에 부적절함
• 세분화된 업데이트의 어려움
  • 특정 Producer가 추가되거나 삭제될 때, room:{roomId}:members:{userId} Hash 내의 특정 필드를 업데이트 해야 함
  • 이 때 전체 필드를 다시 읽고 수정하는 과정이 필요할 수 있음
• 조회 유연성 저하
  • 이 방에 있는 모든 Transport ID를 가져오는 것과 같은 커리를 수행하려면, 모든 room:{roomId}:members:* 키를 스캔하고 각 Hash를 파싱해야 함
  • 이는 Redis의 Set이나 특정 패턴의 Key를 사용하는 것보다 비효율적임
  • Redis는 특정 키 패턴으로 빠르게 Set 멤버나 Hash 필드를 조회하는 데 강점이 있음

제안

• 동적이고 수가 많아질 수 있는 mediasoup 객체의 ID나 각 객체의 상세 메타데이터는 별도의 Redis 구조를 사용하는 것이 성능, 확장성, 쿼리 유연성 면에서 효율적임
• 이는 데이터 정규화 원칙과도 일치하고 각 mediasoup 객체의 수명 주기를 개별적으로 관리하기 용이함
• 다음과 같은 구조를 제안함: