Stories in signals : 스트리밍 실험 기록

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

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

예를 들면 이런 상황이다.

• 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는 다양한 스트리밍 프로토콜을 입력(Input)과 출력(Output) 양쪽에서 지원한다.

이를 통해 서로 다른 스트리밍 시스템 간의 연결 브릿지 역할을 할 수 있다.

2026년 3월 기준으로 SRT ,RTMP_PUSH , RTMP_PULL ,RTP ,RTSP_PULL ,RIST 프로토콜을 지원하며

이러한 프로토콜 지원 덕분에 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만 년 프로젝트

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호에서 집주인 몰래 중고로 구입한 세탁기가 있었는데 그 세탁기가 배관으로 들어오는 물을 다 잡아먹고 있어서 수도에서 물이 안 나왔던 것이라고 설명드렸다. 

끝.

Tencent Cloud AI Code Assistant

 Tencent Cloud AI Code Assistant는 텐센트에서 5월에 공개한 AI 코딩 어시스턴트 툴로, 텐센트의 자체 거대 언어 모델인 훈위안(混元，hunyuan)을 기반으로 개발되었다. 개발자들에겐 이미 Copilot이나 CursorAI 등의 다른 AI 코딩 툴을 먼저 접해봐서 익숙할텐데 Tencent Cloud AI Code Assistant 역시 코드 자동완성, 변수명 제안, 리팩토링, 테스트코드 작성, 최적화 등 코딩 시 개발자에게 편리한 기능을 제공해준다. VScode나 인텔리제이 IDE 제품들 내부에서 플러그인 형태로 적용 가능하며 현재는 중국 콘솔에만 베타버전으로 오픈된 것으로 보인다.

 이 글에서는 해당 제품을 직접 사용해보고, 다른 AI 코딩 어시스턴트 툴과 비교해보는 경험담을 소개한다. 덧붙이자면 본 제품의 원래 명칭은 腾讯云 AI 代码助手 이고 이를 직역한 Tencent Cloud AI Code Assistant를 본문의 표기법으로 하려고 했으나 글 작성 시 편의를 위해 앞 글자만 따서 TACA로 줄여서 작성한다. (개발자와 AI툴의 티키-타카)

TACA 설치

 이 글에서 설치는 VSCODE 기준으로 진행한다. 

VSCODE 익스텐션에서 Tencent Cloud AI Code Assistant 를 검색하여 설치한다.

플러그인을 설치하면 Tencent Cloud 계정에 로그인을 하라는 팝업이 뜨는데, 문제는 TACA가 아직 인터네셔널 콘솔에 정식으로 오픈이 안 되어서 그런지 중국 텐센트클라우드 계정으로 로그인 해야한다는 점이다. Wechat이나 QQ계정이 있다면 SSO를 지원하니 로그인 하면 되고 없다면 별도로 계정을 만들어야한다.

로그인에 성공하면 위와 같이 팝업이 뜬다. 파란 버튼을 누르면 다시 IDE로 돌아오고 사용할 준비가 끝난다. 

TACA 기능 체험

플러그인을 설치하면 에디터에 위와 같이 TACA의 상냥한 메시지가 뜬다. Command⌘ + I 를 입력하면 뜨는 input 창에 내용을 입력하면 코파일럿처럼 사용이 가능하다. 몇 가지 명령을 내려본 결과 다른 AI 코딩 어시스턴트와 거의 동일한 기능과 성능을 제공하는 것을 알 수 있었다.

이렇게 간단한 코드작성을 요청하거나

이미 작성한 내 코드에 커서를 가져다 대면 주석작성, 리팩토링 아이디어, 단위테스트 생성 등의 기능을 TACA가 제안해준다.

아직 공식 국제 콘솔에 공식 오픈된 것이 아니기 때문에 중국어 이외 언어에 대하여 완벽하게 패치된 것은 아니지만 적어도 AI 코딩 어시스턴트로써의 성능은 만족스러웠다.

 또한 텐센트에서 개발한 툴이기 때문에 텐센트클라우드나 다른 텐센트 생태계와 매우 잘 조화를 이루는 것을 확인할 수 있었는데 대표적으로 Wechat 미니프로그램의 HTTPS 프로토콜 기반 통신 API인 wx.request를 이용한 기본 보일러플레이트 코드 작성 요청도 단번에 알아듣고 결과값을 주었다. 

이번엔 TACA에게 텐센트클라우드의 API Explorer의 API 중 CVM 인스턴스 목록조회에 대한 API를 파이썬으로 작성해달라고 요청하였는데 역시 정확한 값을 주었다. 해당 언어에 대한 SDK 설치 가이드도 함께 제시하는 모습이었다.

TACA는 텐센트클라우드를 프로바이더로 한 IaC를 도입한 유저라면 tf파일 작성에도 활용이 가능했다. CVM Auto-scaling 스케일링 그룹 생성 테라폼 코드를 작성요청을 한 모습이다.

마치며

 TACA는 아직 international 콘솔에 오픈된 것이 아니고, 중국 텐센트클라우드 홈페이지에도 베타버전 형태로 공개된 것이라 소개글을 작성하는 것이 조심스럽긴 하지만 그래도 텐센트가 자체 개발한 LLM을 활용해 개발된 AI 코딩 어시스턴트의 성능이 어떤지 궁금해서 내용을 공유하게 되었다.

 방대한 깃허브 레파지토리를 기반으로 학습된 기존 서비스들과 달리 TACA는 중국의 거대한 IT 생태계를 학습타겟으로 포함하고 있기 때문에 같은 질문을 던져도 신선한 답변을 주기도 했다. 텐센트클라우드를 주력으로 운영하는 고객들뿐 아니라 중국의 AI기술을 가장 익숙하고 간편한 방법으로 체험해 보고 싶은 고객들에게 TACA가 정식으로 릴리즈가 된다면 좋은 선택지가 될 수 있을 것 이다.

Spot instance

 Tencent Cloud의 스팟인스턴스는 Pay-as-you-go 대비 매우 저렴한 가격으로 인스턴스를 빌려 사용할 수 있는 과금모델이다. 그러나 인스턴스의 재고상황에 따라 자동으로 회수되는 특성 때문에 프로덕션 환경에 직접적으로 사용하기에는 적합하지 않다. (사실 입찰가격이 시장가격보다 낮아지면 회수되는 것이 보통이지만 , 텐센트클라우드의 공식홈페이지를 보면 2024년1월8일 기준으로 가격 이슈로는 회수되지 않는다고 되어있다. 언제든 바뀔 수 있다.) 따라서 불시에 종료되어도 무방한 테스트 환경이나 고성능의 서버로 시간을 크게 단축시킬 수 있는 애플리케이션 빌드 및 배포, 배치작업 등에 알맞은 과금모델이다. 

 스팟인스턴스를 구매한다는 것은 한 마디로 동네 부자형에게 밥 한 끼 사고 스포츠카를 빌리는 것과 같다고 할 수 있다. 형에게 밥 한 끼 가격으로 고급 스포츠카를 빌려서 내 것처럼 탈 수 있지만 형이 언제든지 와서 가져갈 수 있으니 동창회 같은 장소나 중요한 데이트 자리에 몰고 가면 안 되는 것 처럼 스팟인스턴스도 적재적소에 사용해야 효율을 크게 높일 수 있다.

Spot instance 회수정책

 스팟인스턴스의 재고상황에 따라 인스턴스 회수가 확정되면 텐센트클라우드에서는 인스턴스의 메타데이터를 통해 스팟의 현재상태를 쿼리할 수 있는 API와 메시징을 이용한 스팟인스턴스 회수 알림 기능을 제공한다. 회수 알림은 인스턴스 회수가 확정되면 종료 2분 전에 알림을 보내주는데 2분이란 시간은 어떤 조치를 하기엔 너무 짧은 시간이라 미련없이 떠나보내 주는게 낫다.

인스턴스가 회수되면 원칙적으로 인스턴스 내부의 데이터는 모두 함께 삭제된다. 아는 형의 스포츠카를 빌려 탈때 차 안에 현금 다발이나 귀중품을 두고 있다가 까먹으면 형은 얄짤없이 통째로 다 가져간단 소리다. 

Auto Scaling 에서의 Spot instance

 Auto Scaling을 설정 시 스케일링 그룹에 일정 비율 Spot instance를 추가하게 하여 Pay-as-you-go 리소스와 혼합하는 스케일링 전략을 구성할 수 있다. 서비스에 적합하기만 하다면 Scale-out 시 비용을 크게 절감할 수 있다. Tecent Cloud Auto Scaling 콘솔에서 스케일링그룹 생성 시 기본 Policy 작성 → 로드밸런서 선택 후 아래와 같이 Spot instance allocation 옵션을 토글하면 Spot instance 구성을 진행할 수 있다.

각각의 옵션을 살펴보면

• Pay-as-you-go base capacity : 종량제 인스턴스의 최소 수. Scale-out이 활성화되면 이 값에 도달할때 까지는 종량제 인스턴스만 추가된다.
• Pay-as-you-go above base : Scale-out 시 추가 할당되는 인스턴스 중 종량제 인스턴스의 비율
• Spot instance creation policy : 스팟인스턴스를 처음 추가하는 시점에 어떤 모델의 인스턴스를 추가할지 선택하는 옵션으로 재고가 가장 많은 인스턴스 모델을 선택하거나 가장 코어당 가격이 저렴한 인스턴스 모델을 선택하는 옵션 중 선택할 수 있다.
• Capacity rebalancing : 스팟인스턴스가 회수되려고 할때 다른 스팟인스턴스로 대체하여 설정했던 종량제 인스턴스와 스팟인스턴스의 비율을 유지해주는 역할을 하는 옵션이다.
• Spot fallback to pay-as-you-go : 활성화 시 Scale-out 타겟 스팟인스턴스의 재고가 부족할 때 종량제 인스턴스로 대체한다. 

서비스 로직에 맞게 종량제와 스팟인스턴스 간의 비율을 조정하여 스케일링 그룹 구성이 가능하다. 

Lifecycle hook

 Lifecycle hook은 Auto Scaling 시 인스턴스가 종료 혹은 생성되는 경우 곧이어 수행할 작업을 지정할 수 있는 기능이다. 예를들어 Scale-out시 새로운 인스턴스가 생성되게 되면 특정 스크립트를 실행하거나 런타임 환경을 구성하는 작업을 수행하도록 hook이 직접 발동되거나 큐잉 메시지를 통해 작업을 지시할 수 있다. 마치 갓 입대한 신병들을 바로 부대로 보내지 않고 훈련소를 거치게 해서 사람을 만들어 놓는 느낌이라고 보면 되겠다.

TencentOS Server

  메이저 클라우드 벤더들이 그러하듯 텐센트클라우드 역시 자체개발한 OS를 오픈소스로 제공하고 있다. CentOS를 기반으로 한 리눅스 배포판인 TencentOS Server가 바로 그 것. 당연하게도 CentOS와 호환되며 텐센트클라우드 상품에 최적화된 성능을 제공한다고 한다. CentOS의 유지관리가 중단된 시점에서 갈 길을 헤매고 있는 이들에게 새로운 한 줄기 빛이 될 수 있을지 텐센트가 소개하는 TencentOS Server의 내용을 살펴보도록 한다.

TencentOS Server 소개 및 장점

CVM 인스턴스 구입 시 총 세 가지 버전의 TencentOS Server의 퍼블릭 이미지를 선택할 수 있다.

텐센트클라우드 공식 문서에는 TencentOS Server를 아래와 같이 소개하고 있다.  

 TencentOS Server는 인스턴스의 애플리케이션에 더 높은 성능과 높은 보안성과 안정적인 실행 환경을 제공하기 위해 특정 기능과 성능 최적화를 제공합니다. Linux 커널을 기반으로 자체 개발 및 설계되었으며 10년 이상 운영 체제 분야에서 Tencent의 기술을 축적하였고, 수 년간 Tencent 내부 대규모 비즈니스에 의해 검증 및 최적화 되었습니다. 

 동시에 Tencent는 소셜 네트워킹, 게임, 금융 결제, AI, 보안 등 중국 내에서 가장 다양한 비즈니스 생태계를 보유하고 있으며, 안정성, 보안성, 호환성 및 성능 등 핵심 능력이 충분히 검증되었습니다. 커뮤니티 OS 버전 대비, TencentOS Server는 안정성, 성능, 컨테이너 인프라 등 기타 핵심 능력 측면에서 포괄적으로 향상되고 최적화되어, 기업에 안정적이고 가용성이 높은 서비스를 제공합니다. 최고의 클라우드 운영 체제를 목표로 노력하고 있으며, CentOS보다 더 나은 엔터프라이즈급 운영 체제 솔루션입니다.

장점

천만 규모의 노드에서 검증된 고도의 안정성

TencentOS Server는 총 수천만 개의 배포 규모와 99.999%의 전체 가용성으로 대규모 비즈니스에 대한 장기간의 검증을 거쳤습니다.

완전히 최적화된 더 높은 성능

고도로 최적화된 고성능 OS는 시스템의 다양한 소프트웨어에 최적화되어 있으며, 일반적인 비즈니스 성능은 50% 이상 향상되었습니다. Tencent Cloud를 통해 TencentOS Server를 사용하면 더 높은 성능을 얻을 수 있습니다.

오픈 소스 호환, 클라우드에서 더 나은 OS

100% 오픈 소스 Linux 릴리스 버전인 사용자 모드는 CentOS와 계속 호환되며 안정성과 성능 면에서 더 많은 장점이 있으며 클라우드에서 CentOS보다 더 나은 대안입니다.

클라우드를 위해 탄생, 고도화된 커스터마이징

최신 개방 표준 기반 버츄얼화 및 클라우드 네이티브 툴 포함하고, 다양한 워크로드에 적합하며, 클라우드 전용으로 개발되었습니다.

보안 및 컴플라이언스, 무중단 복구

Security Lab은 시스템 보안을 유지하고, 시스템 수준의 보안을 강화하며, 다양한 취약점을 적시에 수정하고, 핫 패치 복구를 지원하여 불필요한 중단 시간을 방지합니다.

출처 : https://www.tencentcloud.com/ko/document/product/213/40223

벤더사에서 자체 개발한 OS이기도 하고 대규모 중국 시장에서 검증되었으니 AWS에서 amazon linux를 쓰 듯 텐센트클라우드 유저도 안 써볼 이유가 없을 것 같다. CentOS 난민들을 구제하기 위해 친절한 난민행동강령도 공식문서에서 안내하고 있으니 관심이 있다면 참고해보면 좋을 것 같다.

부록) TencentOS와 CentOS와의 상관관계

무서운 이야기1

TencentOS는 CentOS보다 더 낫다.

centOS에 10배를 곱하면 TencentOS가 되기 때문에..

무서운 이야기2

리눅스의 마스코트는 펭귄이다.

그런데,

끝.

중요한 것은 '무엇'이 아닌 '어떻게' 

 한 때 유행 따라 로봇청소기를 산 적이 있었다. 가끔 집안청소가 필요할 때 작동을 시켜봤는데 성능이 내가 생각했던 것보다 기대이하였다. 외출했다 돌아오면 거실 구석에서 버벅거리고 있기도 하고 열린 현관문 밖으로 탈출을 시도하기도 했다. 이럴 거면 그냥 내가 손으로 청소기를 돌리는 게 낫겠다 싶었다. 
 
 그러던 어느날 친구집에 놀러 갔는데 이놈이 로봇청소기 때문에 삶의 질이 달라졌다고 하는 게 아닌가. 내가 쓰는 모델보다 성능도 더 낮은 편에 속하는 모델이었는데도 전혀 다른 반응인 게 신기해서 물어보니 친구는 나에게 로봇청소기에 대한 팁 몇 개를 알려주었다. 청소기의 이동 동선을 방해하지 않게 바닥은 적당히 정리를 해야 하고 물 보충은 어떻게 하는지 등등.. 모두 기본적인 것들이었다. 그때 느꼈다. 중요한 것은 '무엇'을 쓰냐가 아니라 '어떻게' 쓰느냐 인 것을.
 
 여러 크고 작은 기업에 텐센트클라우드를 소개하고 도입을 도와주는 역할을 하는 필자는 클라우드에 대한 다양한 생각을 가진 고객들을 만나게 된다. 대부분 자체 엔지니어들이 깊은 클라우드 지식을 가지고 있는 경우가 많았고 일부 클라우드가 익숙하지 않은 고객들도 잘 정리된 공식문서와 몇 번의 커뮤니케이션을 통해 기존 서비스 환경을 유지하는데 큰 어려움을 겪지 않았다. 그러나 몇몇 기업들은 그들의 서비스의 규모와는 달리 클라우드에 대한 무지와 막연한 불신을 가지고 있기도 했다. 기업의 비즈니스 규모와 구성원의 기술적인 성숙도가 클라우드에도 똑같이 적용되는 것은 아닌 듯했다.
 
 클라우드로 서비스 운영을 해본 경험이 없거나 이미 온프레미스 환경에 익숙한 기업들이 클라우드 도입을 시도할 때, 클라우드의 장점을 살리지 못하는 방향으로 사용을 진행하는 경우가 더러 있다. 이 글을 통해 필자가 만나 본 기업들의 사례를 기반으로 몇 가지를 소개하려고 한다. 이름하여 '클라우드를 클라우드답게 사용하기 위해 피해야 할 몇 가지'. 물론 대부분의 기업들에겐 해당되지 않는 IT의 기본 공리조차 간과한 이야기 같겠지만 이들 중 놀랍게도 이름만 들으면 누구나 알만한 기업에게서 얻은 사례도 있다. 
 
 이 글을 읽는 사람들에게 괜히 불안한 마음에 덧붙이자면 아래에 소개할 괴담 같은 것들이 실제로 일어나고 있는 원인은 MSP의 역량부족이나 고객사의 기술적 수준과는 전혀 관계가 없다. 이들은 몰라서 이러는 게 아니고 그냥 이렇게 쓴다.   
 

1. VPC 설계에 관심이 없다

 VPC는 클라우드에서 논리적으로 격리된 가상네트워크 환경으로 클라우드 아키텍처의 기본이 되는 개념이다. 고객들은 자체 서비스 워크로드에 맞게 VPC를 생성하고 그 안에 수많은 서브넷과 보안그룹, ACL 설정을 통해 그들만의 네트워크 환경을 구축한다. 
 
 그런데 일부 고객사들은 이러한 VPC설정을 쿨하게 생략한다. 다시 한번 말하지만 그들은 몰라서 그러는 게 아니다. 그들은 서비스 지역의 리전과 가용영역 정도만 고려할 뿐 나머지 설정은 default에 맡긴다. 기본 보안그룹에서 열려있지 않은 포트들을 열기 위해 보안그룹 설정을 건드리는 최소한의 작업만 진행할 뿐이다.

 
 어떤 고객은 1개의 텐센트클라우드 계정에 1개의 VPC, 1개의 서브넷에 수십 개의 CVM을 몰아넣고 사용하기도 한다. 심지어 데이터베이스도 퍼블릭 서브넷에 두고 퍼블릭 IP를 이용해서 서버와 통신하는 매우 열린 마음의 고객들도 있다.

 
 물론 이런 유형의 고객들은 대부분 자체 서비스를 운영하기보다 브랜드의 의뢰를 받아 간단한 웹 사이트나 위챗 미니프로그램 개발을 대행하는 SI 업체에 집중되어 있는 편이다.
 
 일단 서비스 규모가 작기도 하고 1년 단위로 계약이 바뀌기도 하니 일단 빠르게 만들고 넘기기 위해 개발팀에 퍼블릭 IP만 던져주는 방식을 선호하기 때문. 의뢰하는 브랜드 입장에서도 자체 내부망을 타거나 고객 데이터베이스에 접근하지 않는 외주 서비스의 경우 크게 이런 부분에 신경을 안 쓰기도 하고 결과물을 평가할 때 겉으로 보이는 완성도나 웹 사이트 접속 속도 같은 지표들만 통과범위 안에 든다면 서로 딱히 문제 될 것은 없으니 더욱 그렇다. 
 
 이에 대해 MSP 입장에서도 고객사의 별다른 요청이 없는데 계속 계정을 모니터링해가며 VPC 아키텍처에 관해 이래라저래라 하는 것도 사실상 불가능한 일이고 그 누구도 아무런 불편을 겪지 않으니 오히려 모두에게 해피엔딩이라고 봐야 할까.

2. 종량제 요금에 대한 두려움이 있다

 필자가 클라우드의 대표적 장점 중 하나라고 생각하는 것이 바로 오토 스케일링이다. 이를 통해 고객사들은 불규칙적인 트래픽에 대응하여 자원을 효율적으로 활용할 수 있다. 이에 뒤 따라오는 비용절감 효과는 덤이다. 그런데 일부 고객사는 스케일링 도입을 꺼린다. 서비스의 트래픽 패턴이 딱 스케일링에 부합하는 경우인데도 말이다. 
 
 그 이유는 역설적이게도 탄력적인 비용에 있다. 그들은 트래픽을 제외한 부분에서 고정적인 비용 지출을 하는 것에 익숙하기 때문에 비용이 싸든 적든 고정적인 비용을 내길 원한다. 같은 이유로 쓰는 만큼 비용을 지출하는 종량제 요금제(Pay-as-you-go)에 대해서도 회의적이다. 자원 활용을 실제 트래픽에 맞춰서 설정하고, 적게 쓰면 적게 내고 많이 쓰면 많이 내는 과금 모델이 그들에게는 예상치 못한 요금폭탄의 이미지로 다가오는 것 같다. (그렇다고 해서 약정모델에 대한 선호도가 높은 것도 아니다.)
 
 그래서 이런 유형의 고객들이 필자에게 가장 많이 묻는 말이 '그래서 한 달에 얼마예요?'다. 이 질문을 하는 고객들의 머릿속에는 이미 유연함을 필두로 한 클라우드의 장점들은 사라지고 견적서에 찍힌 고정가격만 남는다. 사실상 일반 웹 호스팅과 차이가 없어지게 되는 것이다.

3. CAM 설정에 소극적이다

 텐센트클라우드의 CAM(Cloud Access Management)은 사용자의 클라우드 리소스에 대한 액세스를 관리하고 제어하는 서비스로 CAM을 통해 사용자는 다양한 리소스에 대한 액세스 권한을 정밀하게 설정할 수 있고 이는 클라우드 보안에 있어서 가장 첫 번째 단계라고 할 수 있다. AWS의 동일한 서비스인 IAM을 예로 들어서 'AWS는 IAM에서 시작해서 IAM으로 끝난다'는 말이 있을 정도다.
 
 '아무도 믿지 않는다'는 제로트러스트 보안 원칙에 따라 모든 텐센트클라우드 접근 사용자는 그들이 조작하려는 리소스에 대한 최소한의 권한만 가져야 한다. 서비스의 규모에 따라 계정 내에 다양한 리소스가 생성되고 관련 있는 여러 부서 구성원의 콘솔 접근이 필요한 경우가 있는데 이에 대한 그림을 그리고 적절한 정책을 가진 서브 어카운트를 생성하여 관리하는 것도 기업의 클라우드 운영능력을 평가하는 데 있어서 중요한 지표라고 할 수 있을 것이다. 
 
 그런데 일부 고객사는 별도의 CAM 설정 없이 루트 계정 하나만으로 모든 조직 구성원이 돌려서 사용하는 경우가 있다. 여러 사람이 삼삼오오 모여 각자 숟가락으로 찌개 하나를 공유하는 과거 '한국인의 정'을 클라우드화 하는것이 목적이라면 모르겠지만 대단히 위험한 운영방식이다. 콘솔 루트계정은 콘솔에 대한 모든 제어권한을 가지고 있기 때문이다. 

 
그럴리는 없겠지만 누군가 악의적인 의도로 루트계정에 접근한다면 서비스를 강제로 중단시킬 수도 있고 의도하지 않은 리소스를 대량으로 구매해서 요금 폭탄을 날릴 수도 있다. 이런 경우 웃는 곳은 단 한 곳밖에 없으니 고객사 입장에서는 반드시 개선해야 한다.
 

4.  완전 관리형 상품을 막연히 기피한다

 텐센트클라우드에는 TencentDB나 TKE와 같은 완전관리형 PaaS 상품들이 있다. OS단에 대한 관리와, 업그레이드 및 패치 작업을 텐센트클라우드에 일임하므로, 사용자는 시스템 유지 관리에 대한 걱정 없이 비즈니스 애플리케이션에 집중할 수 있는 서비스라 할 수 있겠다. 
 
 데이터베이스를 기준으로 보면, 보통 소규모 워크로드를 보유한 고객사에서는 자체서버나 CVM에 DB를 직접 설치해서 사용하는 방법을 선호한다. 익숙하기도 하고 가격 측면에서도 저렴한 것이 당연하기 때문이다. 따라서 일부 고객사들은 이러한 완전관리형 PaaS상품의 도입을 공연히 기피하는 경향이 있다. 원인은 당연히 가격에만 존재한다. 고객들이 머신 위에 직접 세팅하는 것에 비해 완전관리형 상품들은 뛰어난 장점이 있지만 그만큼 가격이 더 나가는 것도 사실이다.
 
 기업들은 직접 데이터베이스를 설치하고 소프트웨어 버전 업데이트 및 런타임 환경을 관리하는 것에 드는 인건비를 고려하면 현재 책정된 완전관리형 PaaS 상품가격이 전혀 높다고 볼 수 없다는 것도 알고 있지만 실제 표시된 가격 앞에서 이러한 판단은 모두 흐려진다.  '그래서 한 달에 얼마예요?'에 이어 '오픈소스 DB가 그렇게 비싸요?' 라는 질문공격이 연타로 들어온다.
 
  물론 상품 특성상 소규모 애플리케이션 구축에는 어울리지 않을 수 있으나 관련 상품들은 '안 써본 사람은 있어도 한 번 써본 사람은 없다.'는 말이 딱 적합할 만큼 소중한 자체 엔지니어 인력들이 소프트웨어 관리하는데 드는 시간과 노력을 줄이고 개발에만 집중할 수 있게 해주는 좋은 방법이니 막연한 두려움은 잠시 뒤로하고 친해져 볼 필요가 있겠다. 때로는 돈을 아끼기 위해 돈을 써야 하는 법이다.
 

마치며

 너무 기본적인 것들이라 다소 황당하게 보일 수는 있지만 많은 고객들이 이러한 기본적인 것들을 지키지 않아 클라우드를 클라우드답게 사용하지 못하고 있다. 이러한 사례가 전체 클라우드 매출에서 차지하는 비중은 작을 수 있지만, 숫자로 보면 적지 않은 기업들이 포함될 것이다.  이미 언급했지만 그들이 이런 방법으로 클라우드 서비스를 운영하는 이유가 기술적인 역량이 부족해서 이거나 좋은 MSP를 만나지 못해서가 아니다. 알면서도 당장의 편의를 위해 가장 익숙한 방법을 택하기 때문이다. 기술부채로 포장하기에는 개선방식이 너무 간단하기에 미필적고의에 의한 참사에 가깝다.
 
 필자가 이 글을 작성한 이유도 고객사 험담을 하기 위한 게 아니다. 사례로 든 유형의 기업들은 이미 유능한 테크니션들을 보유하고 있고 그들이 가진 잠재력도 높기 때문에 구석에 방치된 필자의 로봇청소기와 같은 그들의 현재 클라우드 운영방식이 클라우드의 효율을 조금이라도 높이는 방향으로 개선이 되기를 바라는 마음에서 이다. 그것이 옳은 방향이라면 그들이 가진 잠재력과 클라우드가 만나 폭발적인 시너지를 낼 수 있을 것이다.

Tencent Cloud의 Cloud Block Storage를 구매한 후 인스턴스에서 정상적으로 접근하려면, 해당 인스턴스에 CBS 리소스를 마운트하는 과정이 필요합니다. 또한, 필요한 경우 파일 시스템을 포맷하고 파티션을 설정하는 작업도 진행해야 합니다. 이 글에서는 리눅스 시스템에서 이러한 과정을 진행하는 방법을 소개합니다.

CBS 구매 및 인스턴스에 연결하기

OS가 설치된 System disk (50GB) 이외에 어떤 볼륨도 마운트 되지 않은 CVM을 준비합니다. 

CVM콘솔에서 'Cloud Block Storage' 메뉴를 클릭합니다. CVM과 같은 가용영역 내에서 적당한 크기의 CBS리소스를 구매한 후 해당 디스크의 옵션에서 Attach를 클릭하여 인스턴스와 디스크를 연결합니다. 여기서는 200GB 크기의 Premium cloud disk를 구입하였습니다.

구입한 CBS의 상태가 순차적으로 변화하는 것을 확인할 수 있습니다. (To be mounted → Attaching → In use)

새로 추가된 200GB짜리 데이터 디스크가 lsblk 명령어 결과에는 보이지만 df -h 명령어 결과에는 보이지 않는 이유는 디스크가 시스템에는 인식되었지만, 아직 파일 시스템이 생성되지 않았거나 마운트되지 않았기 때문입니다.

lsblk 커맨드의 결과를 보면, 현재 루트 리소스는 /dev/vda 이고, /dev/vda1 를 파티션으로 가지고 있습니다. 방금 연결한 /dev/vdb는 파티션이 없습니다. 스냅샷에서 가져온 볼륨이 아닌 이상 파일시스템이 설치되있을리 없지만 한 번 확인해봅니다.

 /dev/vda1 파티션에는 EXT4 파일 시스템이 포맷되어 있습니다. 만약 추가하려는 디스크에 파일시스템이 설치되어 있다면 포맷 시 데이터가 모두 유실되니 반드시 백업을 해두도록 합니다. 일반적으로 리눅스에 사용되는 EXT4 , XFS 파일시스템에 대한 정보는 아래 링크를 참조합니다. 

https://ko.wikipedia.org/wiki/Ext4

https://ko.wikipedia.org/wiki/XFS

파티션 구성

디스크의 용량이 2TB 미만인 경우 일반적으로 MBR(Master Boot Record)을 사용하고, 2TB 이상인 경우에는 GPT(GUID Partition Table) 파티셔닝 메커니즘을 사용합니다. 파티셔닝이 필요하지 않은 경우, 곧바로 연결된 볼륨에 파일시스템을 설치합니다. 이 글에서는 디스크를 100GB, 50GB 두 개의 데이터 파티션과 남은 공간을 모두 스왑 파티션으로 하는 총 3개의 파티션 구성을 진행합니다. Tencent Cloud 공식문서에 EXT4를 예시로 유사한 과정을 소개하고 있으므로 XFS를 기준으로 소개합니다.

먼저 파티셔닝 타겟에 대해 아래 커맨드를 입력합니다.

fdisk /dev/vdb

연속적인 물음에 아래와 같이 입력합니다.

1) n : 새로운 파티셔닝 실행

2) p : 파티션 타입 (MBR의 경우 최대 4개까지의 물리 파티션을 지원합니다. 이를 초과하려는 경우 논리 파티션 생성이 필요합니다.)

3) 파티션 넘버 : 3개의 파티션으로 분리할 예정이므로 1부터 시작합니다.

4) 시작섹터 설정 : enter 입력 (첫 번째 섹터를 기본값으로 설정)

5) 마지막 섹터 설정 : 크기 기준으로 설정합니다. 첫 번째 파티션이므로 +100G를 입력합니다.

파티션 생성 후 p 옵션으로 현재 세션에 적용이 잘 되었는지 확인합니다. 

fdisk /dev/vdb
$ p

같은 작업을 2,3 번째 파티션에도 반복합니다. 3번 파티션의 경우 마지막 섹터를 기본값으로 설정하여 잔여 용량을 모두 소진하도록 합니다.

마지막 파티션의 타입을 스왑 파티션으로 설정하기 위해 Hex code를 82로 변경합니다.

이제 메모리에 있는 변경사항을 디스크에 기록하기 위해 아래의 커맨드를 입력합니다.

fdisk /dev/vdb
$ w

위와 같이 작업이 완료됩니다.

파일 시스템 포맷 (XFS)

각 파티션 별로 파일시스템을 설치하고 마운트포인트를 생성한 뒤 마운팅 합니다.

mkfs.xfs /dev/vdb1
mkdir /mnt/num1
mount /dev/vdb1 /mnt/num1

mkfs.xfs /dev/vdb2
mkdir /mnt/num2
mount /dev/vdb2 /mnt/num2

mkfs.xfs /dev/vdb3
mkdir /mnt/num3
mount /dev/vdb3 /mnt/num3

마운트 정보 기록 (/etc/fstab)

서버가 재부팅될 때에도 자동으로 마운트 정보를 불러오려면 /etc/fstab 파일에 변경사항을 기록해야합니다. 리눅스는 부팅 시 해당파일을 참조하여 가상머신의 마운트된 디스크 정보를 읽습니다.

이에 앞서 먼저 blkid 커맨드를 통해 파티션의 고유 식별자(UUID)를 조회합니다.

편집기로 해당 파일을 편집합니다. 편집 전 반드시 백업본을 생성하여야 합니다.

nano /etc/fstab

해당 파일 하단에 아래 정보를 추가합니다. UUID, 마운트포인트, 파일시스템종류, 마운트옵션 순서로 입력하고 0은 덤프사용 off, 마지막의 숫자는 부팅 시 파일시스템 체크 순서를 의미합니다. 루트 파일 시스템이 아닌 경우 2를 입력합니다.

UUID=<파티션1의 UUID값> /mnt/num1 xfs defaults 0 2
UUID=<파티션1의 UUID값> /mnt/num2 xfs defaults 0 2
UUID=<파티션1의 UUID값> /mnt/num3 xfs defaults 0 2

파일 수정 후 각각의 볼륨을 모두 언마운트 했다가

umount /mnt/*

아래 커맨드를 통해 모두 정상적으로 마운트되는 것을 확인하면 작업이 성공적으로 끝난 것입니다.

mount -a

끝.