Tencent Cloud MPS(Media Processing Service) 소개

들어가기 전에

Tencent Cloud의 미디어 서비스들을 하나씩 살펴보면 공통적으로 등장하는 기술이 있다. TSC(Top Speed Codec) 트랜스코딩, AI 기반 자막 생성, 콘텐츠 모더레이션, 영상 화질 개선이 그것이다. CSS, VOD, StreamLive 등 Tencent Cloud 미디어 PaaS 제품들이 제공하는 처리 기능의 상당 부분은 MPS 위에서 동작한다. MPS는 이 기술들의 코어 엔진이다.

MPS(Media Processing Service)는 멀티미디어 파일에 대한 트랜스코딩, 화질 개선, 미디어 AI 처리를 담당하는 클라우드 기반 미디어 처리 플랫폼이다. 단독으로 사용할 수도 있고, Tencent Cloud 내 다른 미디어 서비스에 내재화된 형태로도 동작한다. Tencent xbright라는 브랜드명으로도 불린다.

Tencent Cloud 미디어 생태계에서의 위치

MPS는 다른 미디어 서비스들의 처리 레이어 역할을 한다.

직접 MPS API나 콘솔을 통해 영상 파일을 처리할 수도 있고, CSS나 VOD 내에서 설정을 켜는 것만으로 MPS 기능이 동작하는 구조다. 퍼블릭 클라우드 외에도 프라이빗 클라우드, 하이브리드 클라우드, SDK 통합 방식으로도 배포 가능해 온프레미스 환경과의 연동도 지원한다.

[아키텍처 다이어그램 삽입]

TSC 트랜스코딩

TSC(Top Speed Codec)는 MPS의 핵심 트랜스코딩 기술로, Tencent Cloud가 자체 개발한 인코딩 커널 기반으로 동작한다. 일반 트랜스코딩과 동일한 흐름으로 사용하되, TSC 템플릿을 선택하는 것만으로 적용된다.

동작 원리

TSC는 세 가지 기술을 결합해 동작한다.

• 스마트 장면 인식: 영상 콘텐츠 유형을 분류해 장면별 최적 인코딩 전략을 선택한다
• 동적 인코딩 파라미터 선택: AI가 프레임 단위로 복잡도를 분석해 비트레이트 배분을 자동 결정한다
• V265 인코더: 자체 개발 H.265 기반 인코더로 높은 압축률과 화질을 동시에 확보한다

이 조합을 통해 동일 화질 기준으로 비트레이트를 최대 50% 이상 절감한다. 단순히 비트레이트를 낮추는 것이 아니라 이미지 품질 복원과 개선을 함께 수행하기 때문에 오히려 원본보다 주관적 화질이 향상되는 경우도 있다.

추가 기능

• HDR to SDR 변환: 영상 장면에 따라 동적 레인지 변환 정책을 자동 적용
• 분산 처리로 일반 대비 최대 30배 빠른 트랜스코딩 속도 지원
• 최대 8K 해상도 출력 지원

지원 코덱

영상·오디오 화질 개선

트랜스코딩 외에도 AI 모델 기반으로 영상과 오디오 품질을 개선하는 기능을 제공한다.

영상 화질 개선

오디오 품질 개선

미디어 AI 기능

MPS의 미디어 AI는 영상 콘텐츠를 분석하고 가공하는 다양한 기능을 제공한다. 각 기능은 독립적으로 적용하거나 워크플로로 조합해 사용할 수 있다.

콘텐츠 생성 및 편집

객체 제거 및 마스킹

콘텐츠 분석 및 인식

콘텐츠 모더레이션

워크플로와 작업 단위

MPS는 처리 단위를 두 가지 방식으로 구성할 수 있다.

• Job: 클라우드 스토리지에 이미 저장된 파일을 대상으로 단건 처리
• Workflow: 새로 업로드된 파일에 자동으로 처리 파이프라인을 적용

워크플로는 콘솔에서 드래그 앤 드롭으로 구성할 수 있어, 트랜스코딩 → 자막 생성 → 모더레이션 → 썸네일 추출을 코드 없이 연결하는 것이 가능하다.

마치며

MPS는 Tencent Cloud 미디어 서비스 전반의 처리 기술을 담당하는 코어 플랫폼이다. TSC 트랜스코딩으로 비트레이트 효율을 높이고, 미디어 AI로 콘텐츠 가공 자동화를 지원한다. CSS나 VOD에서 제공하는 처리 기능 중 상당수가 MPS를 통해 동작한다는 점을 이해하면, 각 서비스의 기능 범위와 한계를 더 명확하게 판단할 수 있다. 개별 서비스 안에서 쓰든, 직접 API로 호출하든, 결국 중심에는 MPS가 있다.

테스트 환경

• Tencent Cloud MPS 콘솔 기준
• 참고: https://www.tencentcloud.com/products/mps

들어가기 전에

  앞서 StreamLive 글에서 DRM을 어디서 처리하는지에 대한 이야기가 나왔다. 결론부터 말하면 DRM은 StreamPackage 단계에서 적용된다. StreamPackage는 StreamLive로부터

  트랜스코딩된 스트림을 받아 패키징하고, DRM 암호화를 적용한 뒤 CDN이 가져갈 수 있는 오리진 엔드포인트를 제공하는 서비스다. AWS 파이프라인에서 MediaPackage가 담당하는

  역할과 동일하다.

  파이프라인에서의 위치

  전체 흐름에서 StreamPackage의 위치는 아래와 같다.

  인코더

    └→ (Streamlink) → StreamLive → [StreamPackage] → CSS/CDN → 시청자

  StreamLive가 트랜스코딩과 다중 출력을 담당한다면, StreamPackage는 그 결과물을 받아 HLS 또는 DASH로 패키징하고 오리진 역할을 수행한다. CDN은 이 오리진 엔드포인트를 통해

  스트림을 가져가 시청자에게 전달한다. StreamLive 없이 외부 인코더나 다른 소스로부터 직접 입력을 받아 독립적으로 사용하는 것도 가능하다.

  [아키텍처 다이어그램 삽입]

  채널 구조와 엔드포인트

  StreamPackage도 채널(Channel) 단위로 구성된다. 하나의 채널에는 입력, 엔드포인트, 인증 설정이 포함된다.

  입력(Input)

  StreamPackage 채널은 아래 두 가지 포맷의 입력을 지원한다.

  ┌───────────┬────────────────────┐

  │ 입력 포맷 │        설명        │

  ├───────────┼────────────────────┤

  │ HLS       │ TS 세그먼트 기반   │

  ├───────────┼────────────────────┤

  │ DASH      │ fMP4 세그먼트 기반 │

  └───────────┴────────────────────┘

  각 채널에는 Primary와 Backup 두 개의 입력 주소가 제공된다. 두 경로로 동시에 스트림을 푸시해두면, Primary 입력에 문제가 생겼을 때 자동으로 Backup으로 전환된다.

  StreamLive의 출력 그룹을 StreamPackage 타입으로 구성하면 이 이중화가 자동으로 연결된다.

  엔드포인트(Endpoint)

  하나의 채널에서 여러 엔드포인트를 생성할 수 있다. 각 엔드포인트는 독립적인 URL을 가지며, DRM 설정이나 인증 방식을 엔드포인트 단위로 다르게 구성할 수 있다. 예를 들어

  동일한 채널에서 DRM 적용 엔드포인트와 미적용 엔드포인트를 병행 운영하는 구성이 가능하다.

  엔드포인트 보안에는 다음과 같은 인증 방식이 지원된다.

  ┌───────────────────┬─────────────────────┐

  │     인증 방식     │      적용 대상      │

  ├───────────────────┼─────────────────────┤

  │ IP 허용/차단 목록 │ 특정 IP 범위 제한   │

  ├───────────────────┼─────────────────────┤

  │ Authkey 검증      │ URL 서명 기반 인증  │

  ├───────────────────┼─────────────────────┤

  │ HTTP 헤더 검증    │ 요청 헤더 기반 인증 │

  └───────────────────┴─────────────────────┘

  [해당 콘솔 캡쳐 삽입]

  DRM과 콘텐츠 보호

  DRM은 엔드포인트 단위로 설정한다. 지원하는 DRM 방식은 FairPlay, Widevine, PlayReady이며, HLS 엔드포인트와 DASH 엔드포인트에서 각각 적용 가능한 방식이 다르다.

  ┌─────────────┬──────────────────┬───────────────────────┐

  │ 암호화 방식 │ 지원 엔드포인트  │     주요 플레이어     │

  ├─────────────┼──────────────────┼───────────────────────┤

  │ FairPlay    │ HLS              │ Safari (macOS, iOS)   │

  ├─────────────┼──────────────────┼───────────────────────┤

  │ Widevine    │ HLS (fMP4), DASH │ Chrome, Firefox, Edge │

  ├─────────────┼──────────────────┼───────────────────────┤

  │ PlayReady   │ HLS (fMP4), DASH │ Microsoft Edge        │

  └─────────────┴──────────────────┴───────────────────────┘

  키 관리는 TencentDRM, SDMC DRM, Custom DRM Key 방식 중 선택할 수 있다. 엔드포인트 하나에 여러 DRM 방식을 동시에 설정해 멀티 DRM 구성을 만드는 것도 가능하다. 이렇게 하면

   플레이어가 지원하는 DRM 방식에 따라 자동으로 적절한 라이선스를 발급하게 된다.

  SSAI와 부가 기능

  서버 사이드 광고 삽입(SSAI)

  StreamLive에서 SCTE-35 마커가 포함된 스트림을 StreamPackage로 전달하면, StreamPackage가 광고 삽입 타이밍을 감지하고 광고 결정 서버(Ad Decision Server)에 요청해 광고

  세그먼트를 수신한다. 이후 매니페스트를 수정해 콘텐츠 세그먼트 사이에 광고 세그먼트를 삽입한 형태로 플레이어에 제공한다. VAST/VMAP 응답을 처리하며, 광고 재생 후 임프레션

   및 인게이지먼트 지표를 트래킹 서버에 리포트하는 기능도 포함된다.

  Harvest Job

  특정 시간 구간의 라이브 스트림을 VOD 콘텐츠로 추출하는 기능이다. 방송 중에 하이라이트 클립을 만들거나, 특정 프로그램 단위로 아카이브를 생성할 때 활용한다.

  Linear Assembly

  여러 VOD 콘텐츠 소스를 조합해 FAST(Free Ad-Supported Streaming TV) 채널을 구성하는 기능이다. 별도 인코더 없이 StreamPackage 내에서 채널 편성을 처리할 수 있다.

  마치며

  StreamPackage는 단순한 패키져가 아니다. DRM 적용, 오리진 이중화, SSAI, Harvest Job, Linear Assembly까지 포함한 미디어 오리진 플랫폼이다. StreamLive가 스트림을 처리하는구간이라면, StreamPackage는 그 결과물을 안전하게 보호하고 CDN에 안정적으로 공급하는 구간이다. Tencent Cloud 미디어 파이프라인에서 두 서비스의 역할 분리를 이해하면 전체 아키텍처 설계가 훨씬 명확해진다.

 들어가기 전에                                                                                                                                                            

  AWS를 주로 사용하는 미디어 엔지니어라면 AWS Elemental MediaLive에 익숙할 것이다. 클라우드에서 라이브 스트림을 수신하고 트랜스코딩해 다양한 포맷으로 내보내는 채널 기반의 서비스다. Tencent Cloud의 StreamLive는 이와 동일한 포지션에 위치한 서비스이다. 방송 수준의 라이브 스트림 처리를 클라우드에서 처리하는 플랫폼으로, 입력 수신부터 트랜스코딩, SCTE-35, 다중 출력까지 하나의 채널 구성 안에서 관리한다.   

  AWS MediaLive가 MediaPackage등 기타 Elemental 시리즈와 결합해 동작하듯, StreamLive도 StreamPackage, CSS와 함께 전체 파이프라인을 구성한다. 서비스 설계 철학이나 구성 단위가 매우 유사하기 때문에, MediaLive 경험이 있다면 StreamLive 구성도 크게 어렵지 않게 접근할 수 있다.

 파이프라인에서의 위치                                                                                                                                                    

 전체 라이브 스트리밍 파이프라인에서 StreamLive의 위치는 아래와 같다.                                                                                                     

  Streamlink가 크로스 리전 전송 안정성을 담당하는 구간이라면, StreamLive는 그 이후 신호를 받아 실제 처리를 수행하는 구간이다. 트랜스코딩, 어댑티브 비트레이트 출력 구성, SCTE-35 처리가 모두 여기서 이뤄진다. StreamLive의 출력은 StreamPackage로 이어지며, 패키징된 HLS 또는 DASH 스트림이 CDN을 통해 시청자에게 전달된다. 또한 StreamLive의 출력을 Streampackge가 아닌 MediaPackage나 기타 라이브 오리진으로 보내는 것도 지원한다. 일반적으로 현재 미디어 워크로드를 크게 바꾸지 않는 상태에서 StreamLive에서 제공하는 트랜스코딩 품질만 얻고 싶을때 사용하는 방식이 되겠다.

  채널 구조: 입력부터 출력까지                                                                                                                                             

  StreamLive는 채널(Channel) 단위로 모든 설정을 관리한다.

  하나의 채널 안에 입력, 트랜스코딩 템플릿, 출력 그룹을 각각 구성하고 연결하는 방식이다.                           

  입력(Input)                                                                                                                                                              

 StreamLive가 지원하는 입력 프로토콜과 방식은 아래와 같다.             

  RTP-MPEGTS 입력은 다중 오디오 트랙을 포함한 스트림을 수신하면서 각 트랙을 채널 내에서 독립적으로 트랜스코딩할 수 있다. 다국어 방송이나 SAP(Secondary Audio Program) 구성이 필요한 환경에서 유용하다.

  또한 각 채널에는 기본(Primary)과 백업(Backup) 입력 주소가 제공되어 Failover 구성이 가능하며 RTP-MPEGTS 입력은 다중 오디오 트랙을 포함한 스트림을 수신하면서 각 트랙을 채널 내에서 독립적으로 트랜스코딩할 수 있다. 다국어 방송이나 SAP(Secondary Audio Program) 구성이 필요한 환경에서 유용하다. Pull 타입 입력은 소스 종료 후 동작을 LOOP(반복) 또는 ONCE(1회) 중에서 선택할 수 있다.

  트랜스코딩                                                                                                                                                               

  비디오와 오디오 트랜스코딩 템플릿을 별도로 생성한 뒤 출력 그룹에 조합해 연결하는 구조다. 지원 해상도는 SD부터 4K까지이며, H.264와 H.265 인코딩을 모두 지원한다. AI 기반 동적 인코딩 파라미터 산출 기능을 통해 비트레이트 대비 화질을 최적화하는 Top Speed Codec 옵션도 제공된다. TSC에 대해서는 별도 섹션에서 설명하기로 한다.

 출력 그룹(Output Group)

 하나의 채널에서 여러 출력 그룹을 동시에 구성할 수 있다. 지원하는 출력 타입은 아래와 같다.                                                                                

  ABR 구성이 필요한 경우, 해상도와 비트레이트가 다른 복수의 트랜스코딩 템플릿을 하나의 출력 그룹 안에 묶어 구성한다. 이 구조는 AWS MediaLive의 Output Group 개념과 동일하다.

  [해당 콘솔 캡쳐 삽입]

 입력 보안과 SCTE-35                                                                                                                                                      

  입력 보안 그룹                                                                                                                                                           

  입력 단에서 CIDR 기반으로 허용 IP를 제한할 수 있다. 보안 그룹을 채널에 연결하면 설정된 IPv4 범위 외의 인제스트 요청은 차단된다. 특정 인코더나 업스트림 서버에서만 신호를 받아야 하는 환경에서 기본적으로 설정해두는 것이 좋다.                                                                                                                    

  SCTE-35                                                                                                                                                                  

  SCTE-35는 방송 스트림 내에 광고 삽입 타이밍 신호를 포함하는 표준이다. StreamLive는 입력 스트림에 포함된 SCTE-35 마커를 처리해 출력 스트림에 전달하는 기능을 지원한다. OTT 플랫폼에서 서버 사이드 광고 삽입(SSAI)을 구성할 때 이 구간의 처리가 전제 조건이 된다.                                                                                   

  마치며                                                                                                                                                                   

  StreamLive는 AWS Elemental MediaLive와 동일한 역할을 Tencent Cloud 생태계 안에서 수행하는 서비스다. 채널 단위의 구성 방식, 입력-트랜스코딩-출력 그룹의 조합 구조, SCTE-35지원까지, 방송급 라이브 스트리밍 파이프라인에 필요한 처리 요소들을 하나의 플랫폼에서 담당한다. StreamLink로 안정적인 신호를 받아 StreamLive에서 처리하고, StreamPackage로 패키징해 CDN으로 내보내는 흐름이 Tencent Cloud 미디어 서비스의 표준적인 구성이다.                                                                        

참고자료 : https://www.tencentcloud.com/document/product/1048?lang=en&pg=

스트리밍을 다루다 보면 이런 순간이 한 번쯤 온다.

“이 스트림을 다른 곳으로 보내고 싶은데?”

예를 들면 이런 상황이다.

• OBS로 송출되는 RTMP 스트림을 다른 플랫폼으로 동시에 보내야 할 때
• 기존 라이브 스트림을 재가공해서 다른 CDN으로 배포해야 할 때
• 모니터링이나 백업용으로 스트림을 복제해야 할 때

보통 이런 작업을 하려면 별도의 미디어 서버를 두거나 ffmpeg로 파이프라인을 직접 만들어야 한다. 여기서 보통 ffmpeg를 꺼내 들게 되는데, 한 번 꼬이기 시작하면 밤 2시에 로그를 보면서 인생을 되돌아보게 된다. Streamlink는 이런 상황을 꽤 우아하게 해결해주는 서비스다.

오늘은 Tencent Cloud Streamlink를 정리해보려고 한다.

Streamlink란 무엇인가

Streamlink는 스트림을 받아서 다른 곳으로 전달하는 스트림 릴레이 서비스다.

쉽게 말하면

Input Stream → Streamlink → Destination

이 구조를 클라우드에서 관리형으로 제공하는 서비스다.

대표적인 특징은 다음과 같다.

• 다양한 프로토콜 지원 (RTMP, SRT 등)
• 스트림 릴레이 및 복제
• 글로벌 네트워크 기반 전달
• 콘솔 기반 간단한 설정

즉, 스트림을 받아서 다른 플랫폼으로 전달하는 역할을 한다.

개념적으로 보면 CDN과 Media Server 사이 어딘가에 위치한 서비스라고 보면 이해하기 쉽다. 유사한 서비스로는 AWS Elemental MediaConnect가 있는데, Streamlink가 가장 유용한 상황은 다음과 같다.

1. 스트림 멀티 배포

하나의 라이브를 여러 플랫폼으로 동시에 보내야 하는 경우다.

예를 들어

OBS
  ↓
Tencent Streamlink
  ↓
YouTube Live
  ↓
Twitch
  ↓
Custom CDN

같은 구조를 만들 수 있다.

OBS에서 여러 플랫폼으로 직접 송출할 수도 있지만,

클라우드에서 릴레이하는 방식이 훨씬 안정적인 경우가 많다.

2. 스트림 백업 (Failover)

라이브 서비스에서는 스트림 이중화가 중요하다.

예를 들어 이런 구조를 만들 수 있다.

Primary Encoder
        ↓
     Streamlink
      ↙     ↘
 Tencent CDN   Backup CDN

이렇게 하면 특정 CDN에 문제가 생겨도 빠르게 전환할 수 있다.

대형 스포츠 이벤트나 콘서트 같은 라이브에서 자주 사용하는 구조다.

3. 프로토콜 변환 파이프라인

스트리밍 서비스에서는 종종 프로토콜 변환이 필요하다.

예를 들어

SRT → RTMP
RTMP → HLS
RTMP → WebRTC

같은 파이프라인이다.

Streamlink는 이런 스트림 전달 과정에서

다른 미디어 서비스들과 쉽게 연결된다.

예를 들어 Tencent Cloud 기준으로 보면

Encoder
 ↓
Streamlink
 ↓
StreamLive
 ↓
StreamPackage
 ↓
CSS CDN
 ↓
Player

같은 구조로 확장할 수 있다.

기본 동작 구조

Streamlink의 동작은 생각보다 단순하다.

1. Input Stream 수신
2. Stream Buffering
3. Destination Push

구조를 간단히 그리면 다음과 같다.

이때 중요한 포인트는

Streamlink 자체는 플레이어 서비스가 아니라 스트림 전달 서비스라는 점이다.

즉, 플레이어는 별도의 CDN이나 패키징 서비스가 담당한다.

지원 프로토콜

Streamlink는 입력과 출력에서 각각 다른 프로토콜 조합을 지원하며, 이를 통해 서로 다른 스트리밍 시스템 간의 연결 브릿지 역할을 할 수 있다. 2026년 3월 기준으로 지원하는 프로토콜 조합은 아래와 같다.

입력(Input)

출력(Output)

입력 프로토콜에 따라 출력 가능한 프로토콜 조합이 정해져있다.

이러한 프로토콜 지원 덕분에 Streamlink는 다양한 환경에서 활용될 수 있다.

예를 들어, 

SRT Encoder
   ↓
Streamlink
   ↓
RTMP CDN

또는

RTSP Camera
   ↓
Streamlink
   ↓
SRT Distribution

같이 서로 다른 프로토콜 간의 연결 파이프라인을 쉽게 구성할 수 있다.

특히 방송 장비나 하드웨어 인코더에서는 SRT / RTP / RIST 같은 전송 프로토콜을 많이 사용하기 때문에

Streamlink를 통해 CDN이나 인코더, OTT 플랫폼과 연결하는 구조를 만들기 쉽다.

Failover 기능

Streamlink는 단순한 스트림 릴레이 기능 외에도, Failover 기능을 통해 입력 스트림 장애 시 자동으로 백업 스트림으로 전환할 수 있다.

예를 들어

Primary Encoder
        ↓
     Streamlink
      ↓
   Distribution

Primary 신호가 끊길 경우

Backup Encoder
        ↓
     Streamlink
      ↓
   Distribution

로 자동 전환된다.

이 기능은

• 스포츠 중계
• 대형 이벤트 라이브
• 방송 송출

같은 중단이 허용되지 않는 스트리밍 환경에서 특히 중요하다.

Tencent Cloud StreamLive 와의 연동

Streamlink는 단순히 스트림을 다른 플랫폼으로 전달하는 것뿐만 아니라 Tencent Cloud의 라이브 인코딩 서비스인 StreamLive와도 연동할 수 있다. 이를 통해 스트림을 다음과 같은 파이프라인으로 확장할 수 있다.

Encoder
   ↓
Streamlink
   ↓
StreamLive
   ↓
StreamPackage
   ↓
CSS CDN
   ↓
Player

여기서 Streamlive (라이브 인코딩) , Streampackage (라이브 패키징) , CSS CDN (라이브 CDN) 에 대해서는 다른 글을 참고하면 설명을 해놓은게 있다.

개인적인 생각

스트리밍 아키텍처를 설계하다 보면

“스트림을 어디로 어떻게 보내야 하는가” 라는 문제가 계속 등장한다.

이걸 직접 구현하면 보통 이런 것들이 필요하다.

• ffmpeg relay
• media server cluster
• monitoring
• failover

솔직히 말하면 꽤 귀찮다.

Streamlink 같은 서비스는 이런 작업을 클라우드에서 관리형으로 처리해 준다는 점에서 꽤 유용하다.

특히

• 멀티 CDN 구조
• 플랫폼 동시 송출
• 스트림 백업

같은 시나리오에서는 생각보다 많이 쓰이게 된다. 

다음 글에서는 직접 Tencent cloud 콘솔에서 Streamlink Flow를 생성해서 스트림을 전달하는 구성을 구현해볼 예정이다.

<참고>

Streamlink 공식문서 : https://www.tencentcloud.com/en/document/product/1073

지구의 600만 년 프로젝트

들어가기 전에                                                                                                                                                           

  AWS에서 라이브 스트리밍을 구성할 때 선택지는 크게 두 가지다. MediaLive + MediaPackage + CloudFront를 조합해 직접 파이프라인을 구성하는 방법과, IVS(Interactive Video    

  Service)처럼 인제스트부터 배포까지를 하나의 서비스로 처리하는 방법이다. Tencent Cloud CSS는 후자에 가깝다. 인코더로부터 스트림을 직접 수신해 클라우드에서 처리하고,     

  CDN을 통해 시청자에게 배포하는 원스탑 라이브 스트리밍 플랫폼이다.                                                                                                       

  트랜스코딩, 녹화, 타임시프트, 워터마크, 미디어 AI, 콘텐츠 모더레이션까지 별도 서비스 없이 CSS 안에서 모두 처리할 수 있다. StreamLive나 StreamPackage 없이도 동작하는    

  독립적인 서비스이며, 방송급 파이프라인이 필요할 때 Stream 시리즈와 결합하는 형태로 확장된다.

 인제스트부터 배포까지의 흐름                                                                                                                                            

  CSS의 기본 흐름은 아래와 같다.                                                                                                                                          

  인코더(OBS, 하드웨어 인코더 등)

    └→ [CSS 인제스트] → 클라우드 처리 → CDN 배포 → 시청자                                                                                                                 

  인코더는 CSS의 푸시 도메인으로 스트림을 전송한다. CSS는 이를 수신해 설정된 처리 기능(트랜스코딩, 녹화, 워터마크 등)을 적용한 뒤, 풀 도메인을 통해 시청자에게 스트림을   

  제공한다. 처리 기능은 기본적으로 비활성화 상태이며, 필요한 항목만 선택해 활성화한다.                                                                                    

  [아키텍처 다이어그램 삽입]                                                                                                                                              

 도메인 구조와 스트림 식별                                                                                                                                               

  CSS는 푸시 도메인과 풀 도메인을 분리해 관리한다. 하나의 스트림은 AppName과 StreamName의 조합으로 식별된다.                                                              

  ┌─────────────┬───────────────────────────────────┬────────┐                                                                                                            

  │  구성 요소  │               역할                │ 기본값 │

  ├─────────────┼───────────────────────────────────┼────────┤                                                                                                            

  │ Push Domain │ 인코더가 스트림을 전송하는 도메인 │ -      │

  ├─────────────┼───────────────────────────────────┼────────┤

  │ Pull Domain │ 시청자가 재생에 사용하는 도메인   │ -      │                                                                                                            

  ├─────────────┼───────────────────────────────────┼────────┤

  │ AppName     │ 스트림 그룹 경로                  │ live   │                                                                                                            

  ├─────────────┼───────────────────────────────────┼────────┤                                                                                                            

  │ StreamName  │ 스트림을 유일하게 식별하는 이름   │ -      │

  └─────────────┴───────────────────────────────────┴────────┘                                                                                                            

  푸시 URL 구조                                                                                                                                                           

  rtmp://push-domain/AppName/StreamName?txSecret=xxx&txTime=xxx                                                                                                           

  인증은 기본 활성화 상태다. txSecret은 Md5(key + StreamName + hex(time))으로 생성되며, txTime은 URL 만료 시각을 16진수 Unix 타임스탬프로 표현한다. 만료 시각이 지난      

  URL로는 인제스트가 차단되므로, 인코더에서 정기적으로 URL을 갱신해야 한다.                                                                                               

  풀 URL과 프로토콜별 지연                                                                                                                                                

  ┌──────────┬──────────────────────────────────────────┬─────────┬─────────────────┐                                                                                     

  │ 프로토콜 │                 URL 예시                 │  지연   │      특징       │

  ├──────────┼──────────────────────────────────────────┼─────────┼─────────────────┤                                                                                     

  │ RTMP     │ rtmp://pull-domain/live/StreamName       │ 1~3초   │                 │

  ├──────────┼──────────────────────────────────────────┼─────────┼─────────────────┤                                                                                     

  │ HTTP-FLV │ https://pull-domain/live/StreamName.flv  │ 1~3초   │ 브라우저 호환   │                                                                                     

  ├──────────┼──────────────────────────────────────────┼─────────┼─────────────────┤                                                                                     

  │ HLS      │ https://pull-domain/live/StreamName.m3u8 │ 10~30초 │ 광범위한 호환성 │                                                                                     

  ├──────────┼──────────────────────────────────────────┼─────────┼─────────────────┤                                                                                     

  │ WebRTC   │ webrtc://pull-domain/live/StreamName     │ 밀리초  │ LEB 전용        │

  └──────────┴──────────────────────────────────────────┴─────────┴─────────────────┘                                                                                     

  [해당 콘솔 캡쳐 삽입]                                                                                                                                                   

  클라우드 처리 기능                                                                                                                                                      

  트랜스코딩

  Top Speed Codec(TSC) 기술을 적용하면 동일 화질 기준으로 비트레이트를 최대 50% 절감할 수 있다. 해상도별 다중 출력을 구성해 어댑티브 비트레이트 스트리밍(ABR)에 활용하는

  것도 가능하다.                                                                                                                                                          

  녹화                                                                                                                                                                    

  라이브 스트림을 실시간으로 클라우드에 저장한다. MP4, FLV, HLS 포맷을 지원하며, VOD 서비스와 연동해 녹화 즉시 재생 가능한 형태로 보관된다.

  타임시프트

  스트림을 TS 세그먼트 단위로 저장해 시청자가 현재 방송 중에 과거 시점으로 되감아 볼 수 있도록 한다. 최대 6시간 구간을 지원하며, 스포츠 중계나 예능 방송처럼 중간 입장    

  시청자가 많은 콘텐츠에서 유용하다.                                                                                                                                      

  워터마크 / 스크린캡쳐                                                                                                                                                   

  스트림에 이미지나 텍스트 워터마크를 실시간으로 삽입할 수 있다. 스크린캡쳐는 일정 간격으로 썸네일을 자동 생성하며, 콘텐츠 모더레이션 파이프라인과 연동해 활용된다.

  릴레이 및 혼합 스트림

  외부 스트림을 CSS로 끌어오거나, 여러 스트림을 하나로 합성해 출력하는 기능이다. 다중 화면 구성이나 게스트 화면 합성 같은 시나리오에서 사용된다.                          

  Standby Stream

  주 입력 스트림이 끊길 경우 자동으로 대기 스트림으로 전환한다. 방송 공백 없이 대체 화면을 송출할 수 있어 고가용성이 요구되는 방송 환경에 적합하다.                       

  미디어 AI 기능

  CSS는 별도 서비스 없이 스트림 처리 단계에서 AI 기능을 직접 적용할 수 있다.                                                                                              

  ┌──────────────────────┬────────────────────────────────────────────────────────┐                                                                                       

  │         기능         │                          설명                          │

  ├──────────────────────┼────────────────────────────────────────────────────────┤

  │ 하이라이트 자동 생성 │ AI가 방송 중 주요 장면을 감지해 클립을 자동 생성       │

  ├──────────────────────┼────────────────────────────────────────────────────────┤

  │ 인텔리전트 요약      │ 멀티모달 분석으로 방송 내용을 자동 요약                │                                                                                       

  ├──────────────────────┼────────────────────────────────────────────────────────┤                                                                                       

  │ 실시간 자막 / 번역   │ 음성을 텍스트로 변환하고 다국어 번역 지원              │                                                                                       

  ├──────────────────────┼────────────────────────────────────────────────────────┤                                                                                       

  │ 오디오·영상 지우기   │ 얼굴, 차량 번호판 등 개인정보를 실시간으로 자동 마스킹 │

  ├──────────────────────┼────────────────────────────────────────────────────────┤                                                                                       

  │ 콘텐츠 모더레이션    │ 음란물, 불법 콘텐츠, 화질 이상 등을 AI로 실시간 감지   │

  └──────────────────────┴────────────────────────────────────────────────────────┘                                                                                       

  서비스 타입                                                                                                                                                             

  CSS는 사용 목적에 따라 세 가지 서비스 타입을 제공한다.                                                                                                                  

  ┌───────────────────────────────┬──────────────┬────────────────────────────────────────┐                                                                               

  │             타입              │     지연     │            주요 사용 케이스            │

  ├───────────────────────────────┼──────────────┼────────────────────────────────────────┤                                                                               

  │ LVB (Live Video Broadcasting) │ 1~3초        │ 대규모 동시 시청, 스포츠 중계, 방송    │

  ├───────────────────────────────┼──────────────┼────────────────────────────────────────┤

  │ LEB (Live Event Broadcasting) │ 밀리초 수준  │ 인터랙티브 방송, 온라인 교육, 이커머스 │                                                                               

  ├───────────────────────────────┼──────────────┼────────────────────────────────────────┤                                                                               

  │ Slow Live Streaming           │ 수십 초 이상 │ 장기 아카이브, 타임시프트 중심 서비스  │                                                                               

  └───────────────────────────────┴──────────────┴────────────────────────────────────────┘                                                                               

  LEB는 WebRTC 기반으로 동작하며 평균 800ms의 지연을 제공한다. 시청자가 방송에 직접 참여하거나 실시간 반응이 중요한 서비스에 적합하다.                

  Stream 시리즈와의 연동                                                                                                                                                  

  CSS는 단독으로도 완결된 서비스지만, 방송급 대형 파이프라인이 필요한 경우 Stream 시리즈와 결합한다.                                                                      

  인코더 → Streamlink → StreamLive → StreamPackage → CSS → 시청자                                                                                                         

  이 구성에서 각 서비스의 역할은 명확하게 나뉜다.                                                                                                                         

  ┌───────────────┬─────────────────────────────────────┐                                                                                                                 

  │    서비스     │                역할                 │

  ├───────────────┼─────────────────────────────────────┤

  │ Streamlink    │ 크로스 리전 안정적 스트림 전송      │

  ├───────────────┼─────────────────────────────────────┤

  │ StreamLive    │ 트랜스코딩, 다중 출력, SCTE-35 처리 │                                                                                                                 

  ├───────────────┼─────────────────────────────────────┤                                                                                                                 

  │ StreamPackage │ 패키징, DRM, 오리진 이중화          │                                                                                                                 

  ├───────────────┼─────────────────────────────────────┤                                                                                                                 

  │ CSS           │ CDN 배포, 부가 처리, 시청자 제공    │

  └───────────────┴─────────────────────────────────────┘                                                                                                                 

  StreamPackage가 오리진 역할을 하고 CSS가 CDN으로 스트림을 당겨가는 구조다. CSS의 클라우드 처리 기능(트랜스코딩, 녹화 등)은 이 구성에서도 동일하게 적용할 수 있다.       

  마치며                                                                                                                                                                  

  CSS는 단순한 CDN이 아니라 인제스트, 처리, 배포를 한 서비스에서 처리하는 원스탑 라이브 스트리밍 플랫폼이다. 소규모 방송부터 대규모 동시 접속까지 CSS만으로 커버할 수     

  있고, 필요에 따라 Stream 시리즈와 결합해 방송급 파이프라인으로 확장할 수 있다. 미디어 AI 기능이 기본 포함되어 있다는 점도 타 서비스와 비교했을 때 눈에 띄는 차이점이다.

Tencent RTC

 Tencent RTC란 텐센트클라우드의 실시간 커뮤니케이션 클라우드 서비스로 음성 및 동영상 통화, 라이브 채팅, 라이브 스트리밍, 인터넷 강의, 화상회의, 뷰티필터 등 미디어적으로 구현할 수 있는 거의 모든 기능을 제공하는 상품이다. 이례적으로 독립적인 상품 홈페이지까지 있는 것으로 보아 텐센트클라우드의 베스트셀러로 보이는 이 TRTC의 카테고리와 장점을 공식 홈페이지에서는 아래와 같이 소개하고 있다.

제품 카테고리

- Video and Voice call : 고품질의 비디오 및 음성통화 구현

- Chat : API를 활용한 실시간 채팅 서비스 (이 상품의 Demo 가이드의 경우 다른 글에서 이미 소개한 적이 있다.)

- RTC Engine : RTC SDK를 활용한 통화 및 인터랙티브 라이브 스트리밍 구현

- Conference SDK :  Zoom과 같은 화상회의 시스템 기능 구현

- Beauty AR : 뷰티필터 기능으로 실시간 이미지 및 비디오 뷰티파이징 구현

제품 특징

높은 품질과 가용성을 갖춘 실시간 인터랙션 서비스

높은 안정성 및 가용성

SLA에 의해 보장되는 99.9% 이상의 서비스 가용성으로 수천만 건의 동시 요청을 지원합니다. 매우 탄력적이고 확장 가능한 네트워크 아키텍처는 수만 명의 엔터프라이즈 사용자에 의해 검증되었습니다.

멀티미디어 품질 보증

전 세계 평균 300ms 미만의 엔드 투 엔드 딜레이로 열악한 네트워크 상황에 대처하는 스마트 알고리즘을 기반으로 패킷 손실률 80%에서음성 통화, 패킷 손실률 70%에서 영상 통화가 가능합니다.

높은 호환성

iOS, Android, Windows, macOS, Web, Flutter, Electron, Unity, Unreal, RN 등 플랫폼을 지원하며 20,000개 이상의 디바이스 모델에 완벽하게 적용할 수 있습니다.

최적화된 글로벌 배포

전 세계 200개 이상의 국가 및 지역에서 사용할 수 있으며 특히 동남아시아, 중동 및 북미의 네트워크에 최적화되어 있습니다.

쉽고 빠른 연결

음성/영상 통화, 음성/화상 회의, 인터랙티브 비디오 라이브 스트리밍을 위한 오픈 소스 UIKits와 전체 플랫폼용 코드 샘플을 통해 개발 프로세스를 단순화합니다.

기업 지원 프로그램

업계 최고의 기술 팀이 7*24시간 연결 서비스와 운영 지원을 제공합니다.

RTC Engine

제품에 대한 소개는 위의 내용과 상품 공식 홈페이지를 참조하면 자세한 설명을 볼 수 있고, 필자는 여러 기능 중 하나인 RTC Engine을 이용하여 데모 서비스를 구성해보려고 한다. RTC Engine은 RTC의 기능을 간단하게 구현할 수 있는 클라이언트SDK와 클라우드 기반 API를 제공해주는 툴킷으로 Web, 안드로이드, iOS, Window, MacOS를 비롯한 다양한 OS를 지원한다. 이 글에서는 RTC Engine을 통해 javascript로 Web에서 간단한 기능을 구현하여 체험해본다.

우선 TRTC 콘솔에 접속 후 새로 애플리케이션을 생성한다.

Select product 에서 RTC Engine을 선택한다.

생성이 완료되면 발급된 SDKAppID와 SDKSecretKey를 기록해 놓는다.

이제 RTC 깃허브에 올라온 Web 코드를 클론한다.

git clone https://github.com/Tencent-RTC/TRTC_Web.git

코드 클론이 끝나면 설치폴더 하위 TRTC_Web/quick-demo-js 폴더의 index.html 파일을 찾아 실행한다.

 파일 실행 시 이렇게 로컬 브라우저에서 Demo 페이지가 뜬다. SDKAppID 와 SDKSecretKey 필드에 발급받은 값들을 넣고 아래 Operation  항목들을 클릭하면 채팅방 입장&퇴장, 음성, 비디오 화면공유 등의 기능을 바로 즉석에서 체험할 수 있다.

무방비 상태에서 기능버튼을 눌렀다간 준비 안 된 오후 3시의 본인 얼굴을 갑작스럽게 마주할 수 있으니 주의한다.

프로덕션 환경에서의 TRTC

 Demo체험 후 정식버전을 구매하면 구매한 플랜에 맞는 범위의 SDK와 API를 사용하여 실제 서비스 환경을 구축할 수 있다. 예시코드와 API 명세는 공식 문서를 참조하여 구현이 가능하다. Demo에서와 다르게 고려해야할 점이 보안이다. 보안 부분에 대한 설계가 확실하지 않다면 채팅 및 회의 특성상 SecretKey 탈취나 크래킹을 통해 음성 및 미디어 정보가 노출될 수 있기 때문이다. 

 Demo에서는 AppID와 SecretKey를 직접 입력 값으로 넣었지만 실제 프로덕션 환경에서는 좋지 않은 방법이 될 수 있다. 텐센트클라우드는 여기서 UserSig라는 자체 보안 서명을 제공하는데 UserSig는 SDKAppID, userid 및 현재시간 만료시 간 등을 산술 합하여 HMAC SHA526 알고리즘을 통해 암호화 되는 보안서명이다.

 자체 계산 공식을 제공하지만 클라이언트 측에서 하드코딩하는 것은 바람직 하지 않고 서버 측에 이에 대한 연산을 맡기고 매 번 서버에 요청하여 UserSig를 받아서 SDK에 전달하는 방식으로 구현한다.

 RTC계열 SDK를 활용하여 개발한 화상회의 서비스에서 사용자가 화상회의 입장 요청 시 사용자 식별자 초기화 전 UserSig 전달 과정은 아래 그림과 같다.

공식문서에서 제공하는 코드로 서버에 UserSig 연산 로직을 짜놓고 매 번 사용자 식별자를 보내 서버에서 UserSig 생성 후 SDK에서 다시 텐센트클라우드 서버로 보내 해당 값의 유효성을 검증 받는 과정이다. 이를 통해 한층 강화된 보안성을 보장받을 수 있다. 

마치며

 CHAT에 이어 이 글에서는 Tencent RTC의 기능을 좀 더 살펴보았다. 사실 기업에서 실시간 리얼 커뮤니케이션 서비스를 개발하는 것은 정말 수고스러운 일이다. 그러나 TRTC가 제공하는 SDK와 API를 사용하면 서비스의 구조를 눈으로 바로 파악할 수 있고, 비용 효율적으로 서비스를 신속하게 런칭할 수 있다.

 이 제품의 소개 홈페이지를 보면 “A Few Lines of Code, Say Goodbye to Busy Work”라는 문구가 있는데, 이 말 처럼 TRTC는 개발자에게 개발 부담을 덜어주고, 비즈니스 측면에서는 아이디어를 빠르게 제품으로 구현할 수 있게 해주는 좋은 툴이기 때문에 관련된 솔루션을 찾고 있다면 먼저 데모 부터 한 번 써보는 것도 좋을 것 같다. 데모는 공짜다..!

참고자료

https://github.com/Tencent-RTC/TRTC_Web

https://trtc.io/document/35607?platform=web&product=rtcengine&menulabel=web

https://www.tencentcloud.com/products/trtc?lang=en&pg=

어느 날 Tencent Cloud EdgeOne 콘솔에서 새로운 메뉴를 발견했다.

Open Edge - AI Gateway 가 바로 그 것.

베타 버전이길래 내 계정에만 특별한 베타테스터 권한을 준건가.. 싶었는데 그건 아니었다.^^;;;

우선 활성화를 해보기 위해 Activate Now 를 클릭하고 

음... 좋은 말씀 같으니 동의하고 또 다시 Activate Now 버튼을 클릭.

그런데 베타버전 사용자 신청 대기가 많으니 인내심을 가지고 기다리라고 한다.

생각 보다 꽤 오랫 동안 대기상태가 지속되었는데, 며칠 뒤 우연히 클릭해보니 열려있었다.

일단 그 전에 OpenEdge 와 AI Gateway가 뭔지 파악해볼 필요가 있다.

Tencent Cloud EdgeOne - OpenEdge

엣지원 공식 문서(https://edgeone.ai/blog/details/open-edge)에서 설명하고 있는 OpenEdge는 이렇다.

OpenEdge란 무엇인가?

더 많은 개발자들이 엣지 애플리케이션 개발에 참여하고, 협업하며, 개선할 수 있도록 Tencent EdgeOne은 OpenEdge라는 오픈 기술 공동 창작 플랫폼을 개발자들을 위해 만들었습니다. 우리는 전 세계적으로 우리의 엣지 노드 기능을 더욱 개방하여, 여러분이 우리와 함께 차세대 서버리스 애플리케이션을 탐구하고 구축할 수 있도록 합니다. 또한 다양한 애플리케이션 선택지와 함께 즉시 사용 가능한 경험을 제공하여, 개발자들이 공동으로 새로운 세대의 엣지 서버리스 애플리케이션을 탐구하고 구축하는 것을 지원하고 촉진합니다.

OpenEdge 아키텍처 개요

OpenEdge 아키텍처는 엣지 컴퓨팅 애플리케이션 작업을 하는 개발자들에게 원활한 경험을 제공하도록 설계되었습니다. 이는 서버리스 애플리케이션 계층, 엣지 컴포넌트 계층, 그리고 컴퓨팅 계층의 세 가지 주요 계층으로 구성됩니다. 각 계층은 엣지 애플리케이션의 효율적인 구현과 운영을 보장하는 데 중요한 역할을 합니다.

1. 서버리스 애플리케이션 계층

경량 애플리케이션에 초점을 맞춘 서버리스 애플리케이션 계층은 개발자들에게 유지 보수가 필요 없고 즉시 사용 가능한 경험을 제공합니다. 현재 우리는 개발자들이 대규모 언어 모델(LLMs)에 대한 접근을 관리하고 제어할 수 있도록 AI Gateway 애플리케이션을 무료로 제공하고 있습니다. 포스터 생성, 실시간 트랜스코딩, 텍스트-이미지 변환 등의 추가 애플리케이션들이 개발 중이며 곧 사용 가능해질 예정입니다.

2. 엣지 컴포넌트 계층

엣지 컴포넌트 계층은 엣지 애플리케이션 구현에 필수적인 핵심 구성 요소들로 이루어져 있습니다. 이 구성 요소들에는 Edge Functions, Edge Cache, Edge KV, Edge COS, Edge AI가 포함됩니다. 이러한 빌딩 블록들은 개발자들이 네트워크의 엣지에서 데이터를 효율적으로 처리하고 관리할 수 있는 강력하고 고성능의 애플리케이션을 만들 수 있게 해줍니다.

3. 엣지 컴퓨팅 계층

엣지 컴퓨팅 계층은 엣지 애플리케이션 구현에 필요한 컴퓨팅 파워를 제공합니다. 여기에는 CPU와 GPU 같은 이기종 리소스가 포함되어, 애플리케이션이 실시간으로 데이터를 효율적으로 처리하고 분석할 수 있도록 합니다. 이 계층은 엣지 애플리케이션이 IoT, AI, 실시간 분석 등의 산업에서 필수적인 저지연, 고성능 결과를 제공할 수 있도록 하는 데 중요한 역할을 합니다.

출처 : https://edgeone.ai/blog/details/open-edge

정리하자면 OpenEdge는 CDN 인프라를 엣지 컴퓨팅 플랫폼으로 확장하여, 개발자들이 글로벌 네트워크에서 효율적으로 애플리케이션을 개발하고 실행할 수 있게 해주는 서비스 정도로 생각하면 될 것 같다. Tencent cloud에서 돌리고 있는 전 세계 엣지 노드들을 단순히 CDN 서비스 뿐 아니라 넓은 영역으로 발전 시켜 나가는 시도가 아닐까.

다음은 AI Gateway에 대한 설명을 보면,

OpenEdge - AI Gateway

 Tencent EdgeOne AI Gateway는 대규모 언어 모델(LLM) 서비스 제공업체에 접근할 때 보안, 가시성, 그리고 요청 행동 제어 관리를 제공합니다. 현재 AI Gateway는 개발자들이 무료 체험을 신청할 수 있도록 제공되고 있습니다.

 AI Gateway는 캐시 구성 기능을 지원하고 있으며, 개발 중인 기능으로는 속도 제한, 요청 재시도, LLM 모델 폴백, 그리고 가상 키가 있습니다. 이러한 기능들의 조합은 LLM 서비스 제공업체에 접근할 때의 보안과 안정성을 효과적으로 보장하는 동시에 접근 비용을 줄여줍니다.

출처 : https://edgeone.ai/blog/details/open-edge

 AI Gateway는 오픈엣지에서 지원하는 기능으로, 성형 AI 모델들과 사용자 사이의 프록시 역할을 하여 LLM 모델을 좀 더 효율적으로 제어하는 역할을 하는 서비스라고 생각하면 될 것 같다. 현재 베타버전 이므로 가볍게 이런 기능이 있구나 하고 간단히 체험해보도록 한다.

AI Gateway 베타 체험

** 베타에 사용한 LLM은 chatGPT만을 기준으로 함

다시 이 창으로 돌아와서

Create를 클릭한다.

생성할 AI Gateway의 기본 정보를 적어주고

Details를 클릭하면

생성한 AI Gateway의 정보를 확인할 수 있다.

이때 Cache 항목이 있는데, 설명을 읽어보면 이 AI Gateway 프록시가 LLM플랫폼의 응답을 캐싱해놨다가 클라이언트가 동일한 유형의 질문을 하면 LLM플랫폼에 요청하지 않고 캐시된 응답을 클라이언트에게 돌려주는 기능으로 보인다. 보통의 LLM 모델들이 쿼리당 토큰을 기준으로 과금을 하는데 아마 이 기능을 사용하면 효과적으로 비용절감을 할 수 있을 것 같다. 

예를 들면 이런 것 이다.

사용자가 GPT에 질문을 날리면, AI Gateway가 해당 질문에 대한 GPT의 답변이 캐싱되어있는지 확인하고 없으면 ChatGPT에게 질문을 한다. 이때 GPT호출의 대가로 토큰을 소모하게 되고 GPT가 뱉은 답변을 AI Gateway가 사용자에게 전달해준다.

여기서 다른 사용자가 같은 질문을 하면 AI Gateway에 해당 질문에 대한 답변이 캐싱되어 있으므로(캐시히트), GPT를 호출하지 않고 캐시된 답변을 사용자에게 전달한다. 이때 GPT를 쿼리하지 않았으므로 토큰을 소모하지 않는다. 일반적인 CDN의 원리 그 자체이다.

실제로 테스트를 해보자, 예시를 살펴보면.

AI Gateway의 chatGPT 호출 엔드포인트에 대해,

https://ai-gateway-intl.eo-edgefunctions7.com/v1/chat/completions

요청헤더 값과 Body의 내용을 참고하여 POST요청을 날리면 된다.

curl -X POST "https://ai-gateway-intl.eo-edgefunctions7.com/v1/chat/completions" \
 -H 'Authorization: Bearer XXXXXXXXXX' \
 -H 'Content-Type: application/json' \
 -H 'OE-Key: df3d6ec8552840bfb311ed7dXXXXXXXXX' \
 -H 'OE-Gateway-Name: Test2024' \
 -H 'OE-AI-Provider: openai' \
 -d '{
  "model": "gpt-4o",
  "messages": [
    {
      "role": "system",
      "content": "You are a poetic assistant, adept at explaining complex programming concepts with creative talent."
    },
    {
      "role": "user",
      "content": "Write a poem to explain the concept of recursion in programming."
    }
  ]
}'

포스트맨을 사용하여 세팅을 하고 AI Gateway 설정에서 캐싱주기를 2분으로 한 뒤

테스트용 질문을 해보자. 필자는 한때 LLM 환각 현상의 예시로 뜨거웠던 질문인 세종대왕 맥북프로 던짐사건 에 대해 물어보았다.

AI Gateway가 정상적으로 chatGPT에 클라이언트의 질문을 전달하고 답변을 받아서 뿌려주는 모습이다.

응답헤더를 확인해보면, 첫 질문이므로 캐시 미스가 일어나는 것을 볼 수 있다. 

GPT의 토큰 소모량을 보면

첫 질문 후 2091-1849 = 242의 토큰이 소모된 것을 알 수 있다.

캐싱 주기인 2분이 지나기 전에 같은 질문으로 다시 POST 요청을 날리면

동일한 답변이 오고 다시 응답헤더를 확인해보면 

이번에는 캐시히트가 일어난 것을 알 수 있다. 방금 답변은 GPT를 거치지 않고 AI Gateway가 가지고 있던 답변을 클라이언트가 받게된 것이다.

GPT의 API 토큰 소모현황을 다시 보면

리퀘스트도 오지 않았고 당연히 토큰 소모도 없는 것을 확인할 수 있다.

마치며

 이 글에는 베타 버전으로 공개된 Tencent Cloud의 AI Gateway의 기능을 간단히 테스트하는 내용을 담았다. AI Gateway의 베타 오픈을 기점으로 OpenEdge의 활용을 통한 많은 기능이 공개될 것으로 보인다. Tencent Cloud가 보유한 방대한 엣지노드와 AI와의 결합이 어떤식으로 발전될지 기대가 되는 부분이다. 앞으로 Tencent Cloud International 콘솔에도 AI를 활용한 여러 상품들이 추가될 것으로 예상하며 이에 주목해보는 것도 좋을 것 같다. 

간단한 트러블슈팅 경험 공유를 위해 작성하였다.

문제 발생

 출근 길 버스에서 고객사의 전화 한 통을 받았다. 고객사는 서비스 확장을 위해 스테이징 환경에서 텐센트클라우드의 CVM과 TencentDB로 작은 웹 서비스 아키텍쳐를 구성했는데 DB접속이 안 되는 현상이 발생했다고 했다. 구체적인 이슈는 이러했다.

 아키텍처를 들여다보면 고객사의 텐센트클라우드 계정에는 특정 VPC 内 1개의 가용영역에 Public IP를 할당받은 CVM 그룹이 위치한 서브넷이 있고 TencentDB가 속한 Private 서브넷이 구성되어 있다. 고객사는 현재 상태에서 추가 아키텍처 설계를 하기 전 CVM 인스턴스에서 DB로 연결 테스트를 진행했는데 타임아웃 에러가 계속해서 뜬다고 했다. 

 가장 먼저 내 머릿속을 스친건 보안그룹 설정이었는데 고객사는 마치 내 답변을 예상하리라도 한 듯 관련된 포트의 오픈여부는 다 확인했다고 했다. 그런데 문제는 생각보다 조금 더 희한했다.

 고객사는 퍼블릭 서브넷 역할을 하는 서브넷에 위치한 인스턴스들 중 특정 한 개의 인스턴스에서만 이런 현상이 발생한다고 했다. 다른 인스턴스들에서는 DB로의 연결이 정상적으로 잡힌다고 했다. 사실 이 말을 듣고 처음든 생각은 텐센트클라우드 제품문제는 아닐 것이라는 확신이었다. 제품 문제라면 해결 절차가 조금 복잡하겠지만 보통 이런 경우는 고객사 운영상 문제에 가까운 경우가 많다. 

문제 해결 시도

 수사의 기본은 사건 현장에서 가까운 것 부터 하나씩 짚어보는 것이라고 하지 않았는가

1) 기본 아키텍처 점검

 CAM설정, CVM, VPC, 서브넷 구성 모두 정상이었다.

2) 보안그룹 및 라우팅테이블 점검

 고객사 CAM계정을 통해 콘솔에 접속해서 우선 보안그룹부터 확인했다. 문제의 CVM이 속한 보안그룹의 아웃바운드는 TencentDB가 속한 서브넷의 보안그룹에 대해 열려있었고 그 반대로의 TencentDB 서브넷의 인바운드도 오픈되어있었다. 포트도 이상이 없고 보안그룹 문제는 확실히 아니었다. VPC 내부 라우팅 테이블 설정도 크게 문제가 없었고 가능성이 낮긴 하지만 ACL 설정도 모두 기본값이라 역시 영향을 주지 않았다.

3) TencentDB

다음은 TencentDB for PostgreSQL의 자체설정을 살펴봤다. 그러나 파라미터 그룹, 엔드포인트 등을 모두 확인했지만 특별한 혐의점이 발견되지 않았다. 일단 다른 CVM에서는 접근이 정상적으로 되는 것으로 보아 이쪽은 가능성이 가장 낮았고 특히 한 개의 인스턴스에서만 접속이 안되는 것으로 보아 제품의 문제와는 더욱 관련이 없어보였다.

상황 정리

 여기서 잠깐 짚고 넘어가면, 필자의 업무 특성 상 고객사의 트러블슈팅 상황을 자주 겪게 된다. 이럴땐 물론 문제해결이 가장 우선순위 이겠지만 고객사의 규모가 그렇게 크지 않은 경우 고객사의 비즈니스팀에게 현재 상황을 어떻게 설명해야 할지 동시에 고려해야할 필요가 있게 된다. 비개발직군에게 장애 상황을 그들의 언어로 적절히 치환해서 유연하게 설명해야 장애의 원인이 제품에 있지 않고 고객사의 운영방식에서 기인한 것이라는 점을 확실하게 전달할 수 있기 때문이다.

 아무리 고가용성이 보장된 시스템이라도 장애는 피할 수 없으나 이것이 제품의 문제인지 사용자의 문제인지를 구분하는 것은 매우 중요하다. 사실 이 부분을 그들에게 명확히 짚고 넘어가지 않으면 나중에 원치않는 누명(?)을 쓰게 될 수도 있다. 

 그들의 언어로 최대한 풀어보면 이렇지 않을까. 고객사를 내 건물 303호에 입주한 세입자라 가정하고, 어느 날 303호에서 수도를 틀었는데 물이 나오지 않았다. 그런데 옆 304호에서는 물이 잘 나온다. 305호, 205호 105호 ... 건물 전체 모든 집을 돌아다니면서 수도꼭지를 돌려봐도 다른 집은 정상이다. 303호만 물이 안 나오는 상황. 수도관과 물탱크를 모두 점검해봤는데도 이상이 없는 상황이라고 할 수 있겠다.

패킷 분석

다시 상황으로 돌아와서, 이쯤되니 문제의 인스턴스에서 무슨 일이 일어나고 있는지 궁금해졌다.

tcpdump -i eth0 -n host <TDB IP>

먼저 일단 인스턴스에 접속해서 패킷을 들여다보았다.

$ tcpdump -i eth0 -n host 10.0.2.100
10:21:00.686502 IP 10.0.1.10.ssh > <TDB IP>.5432: Flags [S], seq 4839923, win 29200, length 0

SYN패킷 요청은 있으나 응답 패킷이 없었다. 

 이번엔 문제의 인스턴스가 아닌 다른 인스턴스에서 패킷 모니터링을 해보니 응답이 정상적으로 오는 것을 확인했다. 해당 인스턴스내 에서 누군가 패킷을 가로채는 느낌이 들어 시스템 내부 라우팅 테이블을 확인해보니 의심가는 부분이 있었다.

$ route -n
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.1.1 0.0.0.0 UG 0 0 0 eth0
172.17.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 docker0
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.1.1 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.1.2 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.0.2.0 0.0.0.0 255.255.192.0 U 0 0 0 br-3887aidc

시스템 라우팅 테이블에서 도커 브릿지가 보였다. 잡았다 요놈..

문제 해결

 원인은 머신에 설치된 도커의 도커 브릿지 네트워크가 10.0.2.0/18로 향하는 트래픽을 중간에서 가로채고 있었다. DB의 IP대역도 이 안에 속해있어서 정상적으로 라우팅이 되지 않는 것이었다. 고객사는 분명 도커 이야기를 한 적은 없고 새로 생성한 서버라고 했었는데 알고보니 잘 돌아가던 다른 서버에서 뜬 이미지로 생성한 머신이었던 것이다. 사전에 도커 세팅을 했다는 것을 알려줬다면 좀 더 쉽게 갈 수 있었을텐데.. 이래서 병원에 가면 의사에게 증상을 제대로 설명해야 병이 빨리 낫는 법이다.

 DB로 라우팅 되어야할 트래픽이 도커브릿지로 새고 있다는 점을 짚어주자 고객사는 원인을 인지하고 곧바로 도커데몬 설정 파일을 수정하여 문제의 브릿지 네트워크 대역을 변경했다. 테스트 결과 문제의 인스턴스에서 TencentDB로 라우팅이 정상적으로 되는 것을 확인하였다. 프로덕션 환경에서 일어난 문제는 아니었고 간단한 해프닝에 가까웠지만 또 하나의 문제해결 방법을 체득한 경험이었다.

 고객사의 비즈니스 팀에게는 위에서 들었던 건물 비유를 다시 들어 303호에서 집주인 몰래 중고로 구입한 세탁기가 있었는데 그 세탁기가 배관으로 들어오는 물을 다 잡아먹고 있어서 수도에서 물이 안 나왔던 것이라고 설명드렸다. 

끝.