🚀 HLS로 음악 주고받기

Main Flow

Client에서 .m3u8 파일 요청
Server에서 NCP Object Storage에 접근해 해당 m3u8 파일을 가져옴
가져온 후, Server는 방에 입장한 시간(TimeStamp) 기준으로 알맞은 음악의 필요한 세그먼트들만 담긴 .m3u8 파일을 응답
Client는 응답받은 .m3u8 파일을 받아 HLS 라이브러리를 사용하여 자동으로 .ts 세그먼트 요청을 보냄
Server는 NCP Object Stroage에 접근해 해당 ts파일들을 응답함

생각해봐야하는 점

1. 캐싱

현재는 NCP Object Storage에 접근해서 m3u8파일을 가져온다. 여기서, 그 방에 있는 모든 사용자가 파일을 가져오는 API를 찌를텐데,

이는 유저가 N명이라 가정하면, Object Stroage에 N번 접근한다. 따라서, 트래픽 증가의 우려가 있다.

따라서, 캐싱을 사용하기로 결정했다.

import { CACHE_MANAGER } from '@nestjs/cache-manager';
import { Inject, Injectable } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import { S3 } from 'aws-sdk';
import { Cache } from 'cache-manager';

export class MusicService {
  private readonly s3: S3;
  private readonly SEGMENT_DURATION = 2;
  constructor(
    private readonly configService: ConfigService,
    @Inject(CACHE_MANAGER) private cacheManager: Cache, // nestJS의 Cache Manager 사용
    )
    const response = await this.s3.getObject(params).promise();
    originalM3u8 = response.Body.toString();
    await this.cacheManager.set( // 캐싱
          originalM3u8CacheKey,
          originalM3u8,
          3600000,
        );

캐싱을 사용하면, 원본 .m3u8 파일 (모든 세그먼트가 들어가있음)을 사용하여, 유저마다 입장시간을 고려하여 다른 m3u8파일을 응답해주면 된다.

또한, segment 파일들도 원본을 캐싱으로 저장하고, 가져다 쓰면 될 것 같다.

2. 파싱 오버헤드

초반에는, 유저에게 필요한 m3u8을 응답해주는 과정에서, m3u8을 파싱 후, 재구성하는 것으로 결정하였다.

다만, 파싱 과정에서의 굉장한 오버헤드가 우려가 되는 상황이어서, 대안을 찾아보았다.

Server

@Injectable()
export class MusicService {
  async generateMusicInfo(joinTimeStamp: number): Promise<{
    m3u8Url: string;
    startSegment: number;
  }> {
    const currentSong = await this.findCurrentSong(joinTimeStamp);
    if (!currentSong) {
      throw new Error('No song is currently playing');
    }

    const elapsedTime = joinTimeStamp - currentSong.startTime;
    const elapsedSeconds = Math.floor(elapsedTime / 1000);
    const startSegment = Math.floor(elapsedSeconds / this.SEGMENT_DURATION);

    return {
      m3u8Url: `${currentSong.id}/playlist.m3u8`,
      startSegment
    };
  }
}

Client

const hls = new Hls({
  startPosition: startSegment // 시작 세그먼트 지정
});
hls.loadSource(m3u8Url);

startPosition 이라는 옵션을 사용하여 시작 세그먼트를 지정해줄 수 있었고, 이는 Server에서 시작되는 세그먼트를 정해주므로 파싱 과정을 거치지 않아도 되었다.

여기서 문제…..

찾아보니 currnet 지점을 확인하는 api를 한 개 더 생성해줘야하는 것이었다.

그냥 파싱하는 것이 훨씬 오버헤드가 적다고 결론을 지었다. 결국 그냥 파싱하는 것으로 돌아가야한다..

3. 입장 시간 계산

입장 시간에 관해서 어떻게 계산을 해야할지 막막했다.

방 입장시간을 기록한 JoinTimeStamp는 파라미터로 받아오지만, 음악 시작 시간을 받아올 방법이 떠오르지 않았다.

윤서님께 여쭤본 결과, 관리자가 방을 생성할 때 아예 음악에 대한 메타데이터를 Redis에 저장하는 방식을 제안해주셨다.

여기서 킥은, 저장할 때, 각 음악에 대한 시작 시간도 저장한다는 것.

결국 Redis에는 아래와 같은 형식으로 저장이 될 것 같다.

songs: [
    {
      id: "song1",
      startTime: 1710810000000, // 2024-03-19 10:00:00
      duration: 180 // 3분
    },
    {
      id: "song2",
      startTime: 1710810180000, // 2024-03-19 10:03:00
      duration: 200 // 3분 20초
    }
  ]

따라서 해줘야하는 작업은

유저가 들어온 시간과 각 노래의 startTIme들을 비교해서 현재 재생되어야 하는 알맞은 노래를 찾고,
그 노래의 startTime과 방 입장 시간을 비교해서 segment 크기(2초?)로 나눈 뒤 알맞은 startSegment를 지정해준다.

11/20 변경사항

KEY: "rooms:{roomId}:session"
HASH Fields:
- releaseTimestamp: 스트리밍 세션 시작 타임 스탬프
- songs: 각 노래들의 duration을 담은 배열 []

rooms:${albumId}:session { releaseTimestamp "123123123"  songs "[97.812563,84.12]" }