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

클라우드 비용관리의 중요성

 기업이 클라우드 도입으로 얻는 이점 중 비용절감에 대한 부분은 빼놓을 수 없는 요소이다. 클라우드 운영비용이 자체 데이터센터 운영이나 코로케이션 모델보다 비용적인 우위를 가지느냐는 여전히 뜨거운 논쟁거리이지만 클라우드에 적합한 서비스에 훌륭한 아키텍쳐의 설계가 합쳐지면 충분히 경제적인 인프라 운영이 가능한 것도 사실이다. 여기에 담당자의 적절한 비용 최적화 운영을 더한다면 기업 입장에서는 더 큰 이득을 얻을 수 있다.

 사실 기업이 클라우드 관리를 MSP에 맡기는 이유 중에 큰 비중을 차지하는 부분이 위와 같은 빌링 관련된 내용일 것이다. 수 십개의 계정에서 발생하는 비용을 관리하고 한 번에 정산할 수 있게 해주는 시스템을 MSP들은 잘 구축하고 있기 때문이다. 따라서 아키텍쳐가 복잡하고 서비스가 방대하다면 MSP의 컨설팅을 받는 것도 좋은 방법이다.

 필자는 이 글에서 사용자 레벨에서 수행할 수 있는 비용 최적화 방법 몇 가지를 소개하려고 한다. 단순히 어떻게 하면 싸게 쓸 수 있을지에 대해 고민하는 것이 아닌 비즈니스 시나리오의 요구사항과 실제 프로비저닝된 자원의 불일치를 하나씩 제거하는 방법에 초점을 맞추도록 한다.

Cost Explorer 활용

 Tencent Cloud에서는 계정 별로 클라우드 리소스 사용비용을 효율적으로 관리할 수 있는 Cost explorer 기능을 제공하는데, 이 기능은 단순히 월 별 청구된 비용을 보여주는 것 뿐만 아니라 다양한 필터링 기능과 태그기반으로 비용 상황을 조회하여 고객의 예측가능한 비용 설계를 지원한다.

(본 기능은 Tencent Cloud 공식문서에서도 소개하고 있는 내용이나 MSP에 바인딩된 계정에는 보이지 않을 수 있으므로 이런 경우 비용 관련 컨설팅은 해당 MSP에게 문의하도록 한다.)

Tencent Cloud Console → Billing Center → Cost explorer 에 접속한다. 

 각종 필터링 옵션을 통해 기간별, 태그별 비용 현황을 확인할 수 있다. 해당 대시보드를 분석하여 기업의 현재 서비스 아키텍쳐에 어울리지 않거나 사용하지 않는 리소스를 정지하거나 제거함으로써 비용을 줄일 수 있다. Cost explorer의 Budget Management 를 활용하면 월별, 분기별, 연도별 특정 리소스의 목표 사용요금을 설정하고 해당 요금의 도달 비율에 따라 알람을 발송하는 기능을 지원한다. 이를 활용하여 경제적인 리소스 관리가 가능해진다. 

개별 인스턴스에 대한 사용량을 정해두면 아래와 같이 목표 사용량이 그래프로 제시된다. 

사용량이 적은 리소스의 조정 방안

1) 적절한 COS Storage class 설정 

 빌링시스템이나 실제 트래픽을 참고하여 사용하지 않는 리소스를 제거하는 방법뿐 아니라 스케일링을 통해 사용 목적에 맞는 자원의 스펙조정이 필요한 경우가 있다. COS의 스토리지 클래스를 변경하거나 TencentDB의 스케일링 기능을 활용할 수 있다. 이 글에서는 COS의 예를 들어 비용 최적화 방안을 간단하게 소개한다.

 COS에서는 버킷 내부의 데이터에 대해 다양한 스토리지 클래스를 제공한다. 각각 데이터의 접근 빈도와 보관 기간에 따라 다른 목적과 특성을 가지고 있다. 

 다중 AZ의 옵션을 제외하면 STANDARD , STANDARD_IA , ARCHIVE , DEEP ARCHIVE 등의 클래스를 지원하는데 이러한 클래스들은 데이터의 성격과 R/W 빈도에 따라 분류된다. 핫 데이터에 적합한 STANDARD 클래스와 콜드 데이터

아카이브인 ARCHIVE 를 기준으로 요금을 비교하면 Storage usage fee가 약 3배 가량 차이나는 것을 확인할 수 있다.

물론 COS의 ARCHIVE 클래스는 직접적인 다운로드가 불가능하고 STANDARD 클래스로의 복원 후 R/W가 가능하기 때문에 다운로드가 빈번한 데이터를 ARCHIVE 클래스로 설정하는 경우 R/W 횟수가 증가할수록 비용은 STANDARD클래스를 급격하게 추월하게 된다. 마치 자주 꺼내 먹을 반찬을 냉장고에 넣지 않고 항아리에 보관한다면 매번 밥 차리는 사람의 수고가 많이 드는 것 처럼 말이다.

따라서 R/W 빈도를 고려하여 클래스를 선택하는 것이 무엇보다 중요하다고 할 수 있다. 현재 COS 공식문서는 다양한 방식으로 Batch 데이터 스토리지 클래스 변경 솔루션에 대한 가이드를 제공하므로 이를 참조할 수 있다.

2) Bucket 수명주기 설정

 특정 시나리오에서 COS Bucket에 업로드 된 데이터는 시간이 지날 수록 R/W 빈도가 줄어드는 경향이 있다. 이럴때Bucket의 수명주기를 설정하여 특정 시간이 경과한 데이터의 경우 자동으로 삭제하거나 좀 더 콜드한 스토리지 클래스로 이동시키는 방법을 통해 불필요한 스토리지 비용을 절감할 수 있다.

수명주기 옵션 이외에도 여러가지 버전관리 및 히스토리 파일 관리 규칙 설정이 가능하다. 버전관리가 활성화된 경우, 유저가 object를 삭제하면 실제로 object가 삭제되는 것이 아닌 'Delete Marker'라는 특수 객체가 생성된다. 이 'Delete Marker'는 object가 삭제된 것처럼 행동하지만 실제 object는 여전히 버전 형태로 저장된다. 옵션 조정을 통해 데이터의 모든 버전이 삭제되어 최종적으로 남은 버전이 Delete Marker일 경우 이를 자동으로 제거하는 기능을 제공한다. 

  또한 네트워크 이슈나 기타 예외로 인해 업로드 실패 후 생성된 대형 파일의 일부인 incomplete multipart에 대한 수명주기 관리를 통해 데이터 관리정책과 비용 사이의 균형을 맞출 수 있다.

적절한 과금모델 선택 (RI , Spot instance)

 클라우드 비용 최적화의 가장 원초적인 해결방법으로 비즈니스 모델에 맞는 적절한 요금제를 사용하는 방법이 있다. Reserved Instance 나 Spot Instance의 도입이 가능한 상품의 경우 서비스 워크로드가 해당 과금모델에 적합한지 충분히 검토한 후 도입을 고려할 수 있다. RI의 경우 다른 비슷한 글에서 설명했으므로 Spot instance만 소개한다.

Spot instance

 Spot instance는 Tencent Cloud에서 제공하는 가상머신 과금모델로, Pay-as-you-go 보다 훨씬 저렴한 가격으로 유저들에게 경쟁적으로 자원을 제공하는 방식이다. 매우 저렴한 가변 가격으로 제공하나 자원 상황 변동이 발생하면 언제든지 회수될 수 있다. 시세보다 훨씬 저렴한 광어회를 싯가로 집에 데려왔는데 밥상에 올리자마자 수산시장 사장님이 가져가는 경우가 생길 수 있다는 뜻이다. 그러니 데이터베이스나 핵심 서비스의 일부를 담당하는 자원에는 할당하지 않고 로드밸런서가 바라보는 서비스나 빅데이터 컴퓨팅 자원의 일부 등 맞춤 비즈니스 시나리오에만 적용해야 한다.

 반대로 말하면 시나리오에만 맞는다면 엄청난 할인혜택을 받을 수 있으니 비용 최적화에 딱 맞는 과금모델이라고 할 수도 있다. Tencent Cloud에서는 Spot Instances withdrawal notifications 옵션을 통해 스팟 인스턴스 회수 시 알람을 받을 수 있는 서비스를 제공하며 CVM 메타데이터를 통한 인스턴스 상태조회를 통해 스팟 인스턴스의 회수상태를 체크할 수 있는 API도 제공하고 있으니 도입 시 활용해 볼 수 있겠다.

마치며

 효과적인 비용 관리는 클라우드의 경제적 이점을 극대화하고, 전체적인 IT 비용을 통제할 수 있는 핵심 요소이다. 특히 Tencent Cloud 콘솔의 여러 비용관리 솔루션을 활용하면 리소스 사용을 철저히 모니터링하고, 비용을 예측할 수 있다. 또한 사용량이 적은 리소스에 대해 수명주기를 설정하고 관리를 자동화 하는 것 역시 비용 절감에 큰 도움이 된다. 또한 RI나 Spot instance등의 유연한 과금 모델의 도입을 고려할 수도 있다. 기업은 위와 같은 방법을 통해 마치 오래 입지 않은 바지 주머니에서 오만원 짜리를 발견한 것처럼 뜻 밖의 수확을 얻을 수 있을 것이다. 

Tencent Cloud Lighthouse

 Lighthouse는 경량 애플리케이션 개발, 웹 사이트, 테스트 환경 구축등의 시나리오를 위해 텐센트클라우드에서 제공하는 클라우드 호스팅 서비스로 워드프레스, Node.js , LAMP , 도커등의 오픈소스 소프트웨어를 쉽게 호스팅 할 수 있는 환경을 제공합니다. 사용자는 프로그램이나 런타임 환경의 설치를 고려할 필요 없이 몇 번의 클릭만으로 원하는 스택을 선택하여 웹 애플리케이션을 구축하고 관리하고 할 수 있습니다. 

 보통 간단한 호스팅 서비스를 위해 클라우드 도입을 고려한다면 CVM등의 서버 리소스는 적합하지 않을 수 있습니다. CVM의 장점인 높은 자유도와 유연성은 비용 측면에서 오히려 단점으로 작용할 수 있기 때문입니다. 타 사의 VPS나 웹 호스팅을 사용하던 경우라면 더더욱 그러합니다. 대기업의 경우라도 테스트 환경 구축이나 경량 웹 애플리케이션 구동을 원하는 경우에는 그에 맞는 적절한 해답을 찾아야합니다. 이럴때 텐센트클라우드의 Lighthouse는 가장 좋은 선택이 될 수 있습니다. 

Lighthouse 요금

 이름에서도 알 수 있듯이 Lighthouse는 AWS의 호스팅 서비스인 Lightsail에 대응하는 기능을 갖추고 있습니다. Lighthouse 역시 Lightsail 처럼 선택한 스택옵션에 따라 고정적인 월별 비용을 제공합니다. 사용자는 아래와 같은 고정 요금모델을 통해 예측가능한 비용의 호스팅 운영이 가능합니다.

Lighthouse  vs CVM

 Lighthouse의 도입이 적절한 지 고민하는 사용자들에게 아래와 같은 CVM과의 비교분석을 제시할 수 있습니다.

Lighthouse 구매하기

그럼 이제 직접 Lighthouse의 상품을 구매해보겠습니다. TCCLI와 Terraform을 통한 프로비저닝도 지원하지만 서비스의 특성상 고객사가 콘솔을 이용한 방법을 선호할 가능성이 크기 때문에 콘솔을 통한 구매를 진행하겠습니다.

먼저 텐센트클라우드의 Lighthouse 구매 페이지에 접속 합니다. 다양한 애플리케이션 시나리오에 대한 템플릿을 확인할 수 있습니다. 해당 번들이 아닌 OS Image를 통한 생성도 지원합니다. 이 글에서는 LAMP(Linux+Apache+MySQL+php) 템플릿을 구매해보겠습니다.

원하는 리전과 LAMP 템플릿을 선택 후 'Details' 버튼을 클릭하면 우측에 해당 템플릿에 대한 세부정보가 뜹니다. 세부정보는 해당 소프트웨어의 버전과 시스템 최적화를 위한 권장사양을 제안합니다. 

워크로드에 맞는 템플릿의 스펙-요금을 선택하고

Credential 생성, 약정 구매기간을 선택하고 결제를 완료합니다.

빛 보다 빠른 속도로 구매가 완료되었습니다.

Built in software 확인

상품 구매완료 후 Lighthouse console에 접속하면 방금 구입한 LAMP 기반 instance가 설치된 것을 확인할 수 있습니다. 번들에 포함된 built in software는 Apache 2.4.46 , MariaDB 10.5.9 ,PHP 7.4.29 입니다. 인스턴스에 접속하여 해당 스택이 정상적으로 설치되었는지 확인합니다.

1) Apache

웹 서버는 아래 경로에 Pre-install 되어 있습니다.

/usr/local/lighthouse/softwares/apache

인스턴스의 public IP로 바로 브라우저에서 접속해보면 Lighthouse 아파치 기본 렌더링 페이지를 확인할 수 있습니다.

루트 디렉터리 위치는 /home/www/htdocs 입니다.

2) MariaDB

MySQL(MariaDB) 설치 경로는 아래와 같습니다.

/usr/local/lighthouse/softwares/mariadb

초기 root 계정 비밀번호는 아래 경로의 credential.txt 파일을 참조합니다.

3) php

설치된 php의 경로는 다음과 같습니다.

/usr/local/lighthouse/softwares/php

선택한 버전과 php 버전이 일치하는지 확인합니다.

마치며

 Lighthouse는 사용이 간편하고 설정이 빠른 특성, 그리고 고정적인 과금 모델로 인해 적합한 사용 시나리오 요구사항을 가진 고객에게 매우 매력적인 선택입니다. 특히 이미 타사의 VPS를 사용하거나 웹 호스팅 서비스를 이용하고 있지만 클라우드로의 전환을 고려 중인 고객들에게 Lighthouse는 클라우드 환경을 처음 경험해 볼 수 있는 좋은 기회입니다. 이러한 전환을 통해 사용자는 비용 효율성은 물론 뛰어난 확장성과 유연성을 경험할 수 있을 것입니다.

예약 인스턴스 구매 후, 고객사의 사정으로 인해 RI의 구조를 변경해야 하는 경우가 생기기도 합니다. 이럴때 이미 구매한 RI를 최대한 활용하여 효율적으로 구독 모델을 구성하는 방법을 소개합니다.

Reserved Instance

 Tencent Cloud CVM의 예약인스턴스(Reserved Instance, RI) 과금 모델은 사용한 만큼 비용을 지불하는 Pay-as-you-go 가 아닌 특정 스펙의 가상머신에 대해 1년 단위로 선불금액을 결제하여 고정비용으로 사용하는 약정 과금 모델입니다. 다른 모든 클라우드 벤더 사에도 존재하는 옵션으로, 기업의 비즈니스 모델에 따라 도입할 수 있는 경제적인 선택지 중 하나입니다. 

 Tencent Cloud CVM 콘솔에서 Reserved Instance 항목을 클릭하면 위와 같이 RI 구매 창이 뜨게 되는데 여기서 원하는 리전과 스펙을 선택하면 현재 구매 가능한 RI 리소스들이 리스팅 됩니다. RI는 모든 CVM에 모델에 지원되는 것이 아니니 주의해야 합니다. 원하는 옵션을 선택하고 최종적으로 구매를 완료하고 나면 RI 구매 후 생성되는 인스턴스나 이미 생성된 인스턴스 중 RI 옵션과 일치하는 옵션이 있으면 자동으로 해당 인스턴스의 구독 모델이 RI로 전환됩니다.

 Tencent Cloud에서는 약정금액을 전액 선불로 지불하고 더 큰 할인율을 누리는 All Upfront 방식과 약정액을 분할하여 납부하는 대신 비교적 적은 할인율을 받는 Partial Upfront 방식이 있습니다. (스펙에 따라 No Upfront 모델도 존재하나 권장하는 편은 아닙니다.) 하지만 어떤 지불방식을 선택하든 간에, 1년 약정 계약을 하는 것은 변함이 없고 RI 특성상 인스턴스와의 바인딩 이후에는 Specifications 변경이 불가능합니다. (스펙을 변경하는 경우 바로 RI와의 바인딩이 해지됩니다.)

RI Split & Merge

 그런데 고객사의 요청으로 서버그룹과 RI와 바인딩 이후에 워크로드 구성의 변경이 필요할 수 있습니다. 이에따라 추가적인 RI 구매가 필요하기도 하고 이로 인해 이미 구입한 RI가 낭비되는 상황이 생깁니다. 이러한 경우를 대비하여 Tencent Cloud CVM은 기구매한 RI에 대해 Split 과 Merge 기능을 제공합니다.

1) RI Split

 말그대로 이미 약정 계약이 완료된 RI의 Specification을 여러 개의 RI로 분리하는 기능입니다. 물론 CVM 스펙을 떡 자르듯 마음대로 나눌 수 있는 건 아닙니다. 16Core 64GB 구성의 1개의 RI를 2Core 4GB + 4Core 20GB + 8Core 40GB 구성으로 3개의 RI로 바꿀 수는 없다는 뜻입니다. 

 우선 구입한 RI의 CPU : MeM 비율을 봐야합니다. Tencent Cloud CVM 중 Standard S5 인스턴스는 1:2 혹은 1:4 의 CPU : MeM 비율을 가집니다.

  그리고 normalization factor 값도 살펴봐야 합니다. normalization factor은 vCPU의 성능을 수치화한 것으로, 일반적으로 vCPU의 코어 수와 일치합니다. 

 이 두 가지 CPU : MeM 비율과 normalization factor 값을 알고 있다면 아래 두 조건을 만족시키는 방법으로 RI Split이 가능합니다.

조건 1) Split 전 RI의 CPU:MeM 비율과 같은 RI 들로만 분할이 가능
조건 2) Split 전 RI의 normalization factor = Split 후 RI들의 normalization factor의 합 

복잡해보이지만 어떻게 보면 또 당연한 말이기도 합니다. 직접 콘솔에서 16Core64GB 인스턴스로 RI Split을 시도하면

이렇게 조건을 만족하지 못 하면 Splitting이 진행이 불가능하고

 조건을 만족하면 Splitting 진행이 가능한 것을 확인할 수 있습니다.

 애초에 원래의 RI와 같은 CPU : MeM 비율을 가지도록 메모리는 고정 값으로 지정되어 있기 때문에 위에서 소개한 조건 중 조건2만 고려하면 됩니다. 위 그림의 상황을 기준으로 OK를 클릭하면 원래 RI는 expired되고, 새로운 5개의 RI가 활성화됩니다.

2) RI Merge 

 조립은 분해의 역순이므로 Split을 이해하였다면 Merge도 비슷한 과정입니다. 그러나 Split에 비해 조건이 다소 까다롭습니다. 합치려는 RI들의 가용영역이 모두 같아야 하고 , 설치된 OS까지 같아야 합니다. Merge 하려는 RI들의 normalization factor의 합과 일치하는 normalization factor만 생성 가능합니다.

Split과 마찬가지로 콘솔의 Reserved Instance 항목에서 Merge를 클릭하고

조건에 맞는 RI로 Merge를 할 수 있습니다.

마찬가지로 Merge 조건에 맞지 않는다면 생성이 불가능합니다. 조건을 만족한 후 OK를 클릭하면 원래의 RI들은 expired 되고, 새롭게 생성된 RI가 활성화됩니다.

마치며

 Reserved Instance의 도입은 생각처럼 그렇게 간단한 것은 아닙니다. 사용자 입장에서 약정이라는 구독 모델도 그다지 반가운 것은 아니고 생성 후 스펙을 변경하기도 어렵습니다. 리소스의 재고가 부족한 경우에는 RI가 매진되기도 하고 애초에 RI 대상이 되는 인스턴스 스펙들도 제한적인 편입니다. 그러나 비즈니스 요구사항에 딱 맞는 RI를 찾았다면 가장 비용효율적으로 클라우드 가상머신을 사용할 수 있는 방법이기도 합니다.

 하지만 성공적으로 예약 인스턴스 구성을 마쳤더라도, 약정 기간 내에 서비스에 어떤 변화가 생길지는 모르는 일입니다. 이럴때 이 글에서 소개한 방법들을 활용하면 마치 우리가 안 입는 옷을 잘라서 여러 가지 다른 제품을 만드는 것 처럼 클라우드 자원의 낭비를 막고 비용까지 경제적으로 컨트롤 할 수 있습니다. 

CVM instance

IaC를 도입한 프로젝트에서 가장 많이 작성하게 되는 건 아무래도 가상머신 프로비저닝에 관한 코드일 것입니다. 프로젝트의 규모가 클 수록 많은 tfstate 파일과 configuration tf 파일을 관리하는 일도 쉬운 일은 아니지만 이러한 반복작업을 클라우드 콘솔에서 진행하는 것에 비하면 훨씬 생산적입니다. 이 글에서는 기본적인 스펙의 Tencent Cloud CVM을 생성하는 간단한 IaC 예제를 소개합니다.

목표 및 준비물

 위 그림과 같이 1개의 VPC에 2개의 서로 다른 가용영역을 구성하고, 가용영역 내에 각각 CVM 1대 씩을 배치한 뒤 첫 번째 서브넷의 인스턴스에만 Public IP를 부여하여 Public subnet의 역할을 하게 합니다. 실무에서의 구성과는 거리가 있지만 코드 내에서 다양한 argument를 사용해 보기 위해 이와 같이 구성합니다.

 리소스 프로비저닝을 위한 CAM 계정 생성 및 정책 구성과 SecretId, SecretKey 의 환경변수 설정과 같은 기본적인 내용은 생략합니다. 필요 시에는 Tencent Cloud 공식 홈페이지 문서나 블로그 내에 다른 글들을 참고할 수 있습니다.

main.tf

이번에는 Demo 코드를 참조하지 않고 테라폼의 공식문서에 있는 CVM instance 관련 항목으로 목표 아키텍쳐의 필요한 부분만을 따서 main.tf 파일을 작성합니다. 기본 security group이 아니거나 자세한 기타 설정(요금제, 인스턴스 수명주기 조정, 라우팅 테이블 수정 등이 필요한 경우에도 공식문서의 Argument reference를 참고할 수 있습니다.)

terraform {
  required_providers {
    tencentcloud = {
      source = "tencentcloudstack/tencentcloud"
    }
  }
}

provider "tencentcloud" {
  region = "ap-seoul"

  secret_id  = var.SECRET_ID
  secret_key = var.SECRET_KEY

}

resource "tencentcloud_vpc" "my_vpc" {
  name       = "NewVPC"
  cidr_block = "10.0.0.0/16"
  is_multicast = false
}

resource "tencentcloud_subnet" "subnet_s1" {
  vpc_id            = tencentcloud_vpc.my_vpc.id
  name              = "SubnetS1"
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-seoul-1"
  is_multicast      = false
}

resource "tencentcloud_subnet" "subnet_s2" {
  vpc_id            = tencentcloud_vpc.my_vpc.id
  name              = "SubnetS2"
  cidr_block        = "10.0.2.0/24"
  availability_zone = "ap-seoul-2"
  is_multicast      = false
}

resource "tencentcloud_instance" "instance_s1" {
  instance_name  = "InstanceS1"
  availability_zone = "ap-seoul-1"
  image_id       = "img-1u6l2XXX"  
  instance_type  = "S5.LARGE8"
  system_disk_type = "CLOUD_PREMIUM"
  system_disk_size = 50
  allocate_public_ip = true
  subnet_id  = tencentcloud_subnet.subnet_s1.id
  internet_max_bandwidth_out = 10
}

resource "tencentcloud_instance" "instance_s2" {
  instance_name  = "InstanceS2"
  availability_zone = "ap-seoul-2"
  image_id       = "img-1u6l2XXX"  
  instance_type  = "S5.LARGE8"
  system_disk_type = "CLOUD_PREMIUM"
  system_disk_size = 50
  subnet_id  = tencentcloud_subnet.subnet_s2.id
}

Plan & apply

작성 configuration file을 기준으로 배포합니다.

terraform plan

그런데 위 코드를 기준으로 하면 apply 시 아래와 같은 에러가 발생할 수 있습니다. 

apply를 하면 테라폼은 VPC → 서브넷 → 인스턴스 순서로 프로비저닝을 진행하는데, 서브넷 생성 후 해당 서브넷 ID가 'subnet_id'에 할당되기 전에 인스턴스 생성을 시도해서 생기는 오류입니다. apply 커맨드에 다음과 같은 옵션을 추가하여 해결할 수 있습니다.

terraform apply -auto-approve

Apply complete !

결과물 확인

Tencent Cloud 콘솔이나 TCCLI에서 아래 커맨드를 입력하여 terraform state와 동일한 리소스가 프로비저닝 되었는 지 확인합니다.

tccli configure
// confidential 정보 입력
tccli cvm DescribeInstances

이처럼 이 글에서 작성한 예시코드와 공식문서를 참조하여 프로젝트의 구성에 맞게 Tencent Cloud Terraform 코드를 작성하여 리소스를 편리하게 관리할 수 있습니다.

 어떤 CSP를 쓰든 MSP를 통해 바인딩 된 계정이라면 대부분 콘솔에서 MSP 담당자들이 직접 어카운트에 크레딧을 할당해 주고 유저는 그 크레딧을 통해 온디맨드 클라우드 리소스의 사용료를 차감해서 사용하는 방식을 채택하고 있다. MSP 담당자들이 놓치지 않는 이상 고객사 계정의 크레딧이 0이 될 일은 사실상 거의 없긴 한데, 아주 가끔 그런 일이 발생하지 말라는 보장은 또 없기 때문에 최근에 비슷한 일을 겪은 입장에서 크레딧이 0이 된 MSP 바인딩 계정의 CVM 리소스는 얼마 기간 동안 정상적으로 버틸 수 있을지 궁금하여 한 번 찾아보았다. Tencent Cloud 공식 홈페이지에 친절히 관련 내용이 설명되어있다.

결론은 2시간이다. MSP 담당자의 실수로 고객사 계정의 크레딧이 완전 바닥이 나도 Tencent Cloud CVM은 2시간은 available 하다는 뜻이다. 2시간이 지나면 shut down이 되고 그 시점부터 다시 15일이 경과하면 CVM은 terminated 된다. 물론 2시간이 되기 한참 전부터 MSP 크레딧 담당자의 휴대전화는 무수한 메시지 알림으로 난리가 날테니 걱정할 필요는 없을 것 같다. 

사진 출처 : 

https://www.tencentcloud.com/document/product/213/2181?lang=en

이 글에서는 Tencent Cloud EdgeOne의 애플리케이션 가속 기능을 사용하기 위해 필요한 도메인 등록 절차를 테라폼을 통해 구현하는 방법을 소개합니다. 

EdgeOne with IaC

EdgeOne 리소스 프로비저닝 권한을 가진 CAM계정을 생성한 후 SecretID와 SecretKey 및 EdgeOne PlanID를 준비합니다. PlanID는 구매한 EdgeOne 요금제에 대해 해당 계정이 가지는 고유번호로, 아래와 같이 EdgeOne 콘솔에서 확인가능합니다.

EdgeOne에 등록할 도메인들을 준비합니다. 여기서는 1개의 도메인을 기준으로 하였으며 도메인의 네임서버는 Tencent Cloud의 도메인 호스팅 서비스인 DNSPod의 네임서버로 DNS설정을 하였습니다. 

Demo 코드 다운로드 및 main.tf 수정

Tencent Cloud의 Terraform 공식 깃허브에서 Demo코드를 클론합니다.

git clone https://github.com/tencentcloudstack/terraform-provider-tencentcloud.git

tencentcloud-teo/main.tf 를 찾습니다. 이 tf 파일을 수정하도록 합니다.

1) Credential 설정

먼저 SecretID, SecretKey 가 하드코딩된 부분을 환경변수를 참조하도록 변경합니다.

export TF_VAR_SECRET_ID=xxxx
export TF_VAR_SECRET_KEY=xxxx

provider "tencentcloud" {
  secret_id  = var.SECRET_ID
  secret_key = var.SECRET_KEY
}

2) 도메인 및 오리진 설정

variable "zone_name" {
  default = "perfective.xyz"
}

variable "sub_domain" {
  default = "www"
}

variable "zone_name" {
  default = "example.com"
}

origin_info {
  origin      = "1XX.2X.1XX.2XX"
  origin_type = "IP_DOMAIN"
}

• zone_name  & sub_domain : EdgeOne 가속 도메인 정보를 입력합니다.
• origin_type : 원본서버의 아이피주소나 도메인 주소를 타겟으로 하려면 "IP_DOMAIN" 을, 기타 저장소의 엔드포인트를 타겟으로 하려면 "COS" or "AWS_S3" 를 입력합니다.
• origin : 원본서버의 아이피주소나 엔드포인트 도메인을 입력합니다.
• zone_name : 클라이언트가 접근할 실제 서비스 도메인을 입력합니다.

3) 플랜 정보

구매한 EdgeOne의 플랜 정보에 대한 설정이 필요합니다.

resource "tencentcloud_teo_zone" "zone" {
  area            = "overseas"
  alias_zone_name = "tftest"
  paused          = false
  plan_id         = "edgeone-2rniXXXXXXXX"
  tags = {
    "createdBy" = "terraform"
  }
  type      = "partial"
  zone_name = var.zone_name
}

• type : 엑세스 방식이 CNAME인 경우 "partial" , NS인 경우 "full" . L4 프록시 같이 도메인 등록이 필요하지 않은 경우에는 "noDomainAccess"를 입력합니다.
• area : "noDomainAccess"를 제외한 타입의 경우에 "overseas" , "global" , "mainland" 에서 선택하여 입력할 수 있습니다. 가속 대상 지역에 대한 파라미터로 , "overseas"의 경우 중국을 제외한 글로벌 가속에 해당합니다.

Demo를 기준으로 수정한 main.tf 전체 코드는 다음과 같습니다.

terraform {
  required_providers {
    tencentcloud = {
      source = "tencentcloudstack/tencentcloud"
    }
  }
}

provider "tencentcloud" {
  region = "ap-seoul"

  secret_id  = var.SECRET_ID
  secret_key = var.SECRET_KEY

}

provider "tencentcloud" {
  alias      = "tfdomain"
  region     = "ap-seoul"
  secret_id  = var.SECRET_ID
  secret_key = var.SECRET_KEY
}


variable "zone_name" {
  default = "example.com"
}

# cname
resource "tencentcloud_teo_zone" "zone" {
  area            = "overseas"
  alias_zone_name = "tftest"
  paused          = false
  plan_id         = "edgeone-2rniXXXXXXXX"
  tags = {
    "createdBy" = "terraform"
  }
  type      = "partial"
  zone_name = var.zone_name
}

resource "tencentcloud_dnspod_record" "demo" {
  provider = tencentcloud.tfdomain

  domain      = var.zone_name
  record_type = tencentcloud_teo_zone.zone.ownership_verification.0.dns_verification.0.record_type
  record_line = "default"
  value       = tencentcloud_teo_zone.zone.ownership_verification.0.dns_verification.0.record_value
  sub_domain  = tencentcloud_teo_zone.zone.ownership_verification.0.dns_verification.0.subdomain

}

resource "tencentcloud_teo_ownership_verify" "ownership_verify" {
  domain = var.zone_name

  depends_on = [tencentcloud_dnspod_record.demo]
}

variable "sub_domain" {
  default = "www"
}

resource "tencentcloud_teo_acceleration_domain" "acceleration_domain" {
  zone_id     = tencentcloud_teo_zone.zone.id
  domain_name = "${var.sub_domain}.${var.zone_name}"

  origin_info {
    origin      = "119.XXX.XXX.XXX"
    origin_type = "IP_DOMAIN"
  }

  depends_on = [tencentcloud_teo_ownership_verify.ownership_verify]
}

resource "tencentcloud_dnspod_record" "acceleration_domain_record" {
  provider = tencentcloud.tfdomain

  domain      = var.zone_name
  record_type = "CNAME"
  record_line = "default"
  value       = "${tencentcloud_teo_acceleration_domain.acceleration_domain.domain_name}.eo.dnse0.com."
  sub_domain  = var.sub_domain

}

plan & apply

main.tf가 있는 디렉토리에서 terraform init 을 실행하고 plan 합니다.

terraform plan

Terraform에서 추가될 EdgeOne의 설정을 보여줍니다. 내용에 이상이 없다면 apply 합니다.

terraform apply

Apply complete !

EdgeOne 가속 도메인 등록결과 확인

TCCLI에서 EdgeOne 리소스를 생성한 CAM 계정의 credential 정보로 configure을 한 후 아래 커맨드를 입력하면

tccli teo DescribeZones

방금 등록했던 EdgeOne 가속도메인의 정보를 확인할 수 있으며 같은 정보를 콘솔에서도 확인이 가능합니다.

마치며

 텐센트클라우드 깃헙에서 제공하는 테라폼 코드로 간단한 EdgeOne 설정을 하는 법을 소개하였습니다. 텐센트클라우드와 결합한 IaC 세팅은 복잡한 클라우드 리소스 관리 작업을 간소화하고 자동화합니다. Rule Engine 설정 등 EdgeOne의 디테일한 기능도 모두 Terraform을 통해 구현이 가능하니 IaC에 익숙한 사용자들이라면 한 번 경험해보는 것도 좋을 것 같습니다.

Terraform with Tencent Cloud

이 섹션은 하시코프사의 IaC(Infrastructure as a code) 도구인 테라폼(Terraform)을 통해서 클라우드 인프라를 관리하는 방법을 간단하게 소개합니다. 테라폼은 Tencent Cloud를 Provider로 지원하고 있으므로 Tencent Cloud의 다양한 상품 모듈을 테라폼에서 쉽게 생성, 관리할 수 있습니다. 이 섹션의 글들은 Tencent Cloud 리소스를 IaC로 구현하는 데에 목적이 있기 때문에 HCL 문법이나 테라폼 코드 관리 같은 것은 설명하지 않고 오직 Tencent Cloud 상품에 초점을 맞추어 작성되었습니다. 

테라폼 설치 및 가이드 문서

먼저 테라폼을 설치 합니다. 설치가 끝나면 하시코프 공식 홈페이지의 Terraform Provider 가이드 문서 를 실행합니다. Tencent Cloud가 테라폼을 통해 제공하는 서비스 모듈의 목록과 HCL 작성 예시가 적혀있는데 모든 코드 작성은 이 곳의 예시를 따르면 큰 도움을 받을 수 있습니다.

Credential 설정

Tencent Cloud CAM 설정을 통해 API Key 를 발급합니다. (SecretId, SecrectKey) 이때 root계정이 아닌 테라폼을 통해 프로비저닝하려는 리소스에 대해 필요한 최소한의 권한만을 가진 Sub-user를 생성해서 API Key를 발급할 수 있습니다.

이때 발급한 Key pair 는 아래와 같은 환경변수 설정이나 tccli를 통해 테라폼 코드 작성시 하드코딩 하지 않도록 해야합니다.

1) 환경변수 설정

export TENCENTCLOUD_SECRET_ID=<your-secret-id>
export TENCENTCLOUD_SECRET_KEY=<your-secret-key>

2) tccli

Tencent Clodud의 CLI 도구인 TCCLI를 사용 중이라면 ~/.tclil 하위 .credential 에 JSON으로 API Key가 저장되어있는걸 확인할 수 있는데

main.tf 작성 시 아래와 같이 shared_credentials_dir 값으로 API Key 값을 넣을 수 있습니다.

provider "tencentcloud" {
  shared_credentials_dir = "<.tccli 폴더경로>"
}

main.tf 파일 작성

적당한 위치에 디렉토리를 생성하고 Tencent Cloud Provider를 선언할 main.tf 파일을 작성후 저장합니다.

terraform {
  required_providers {
    tencentcloud = {
      source = "tencentcloudstack/tencentcloud"
      version = "1.81.88"
    }
  }
}

provider "tencentcloud" {
  # Configuration options
}

main.tf를 작성한 위치에서 terraform init을 실행합니다.

terraform init

init이 완료되고 나면 이제 가이드 문서를 참고하여 plan과 apply를 진행할 준비가 된 것 입니다.

Cross-MLC-border acceleration

 ICP 비안을 발급 받지 않은 웹 사이트를 운영하는 해외기업이 EdgeOne의 가속솔루션을 사용을 위해 EdgeoNe에 도메인을 등록할 때 아래 단계에서부터 어려움을 겪게 됩니다.

중국 유저에게 서비스를 해야하기 때문에 Chinese mainland 혹은 Global을 선택해야 하지만 모두 해당 사이트에 ICP비안이 발급되어있는지 검증하는 절차를 통과해야 합니다. 

EdgeOne Cross-MLC-border acceleration 는 Tencent Cloud EdgeOne의 가속 서비스의 기능 중 하나로, 중국 유저의 트래픽을 중국 본토가 아닌 홍콩지역에서 발급받은 IP를 통해 origin에 라우팅하여 중국 내 유저에게 ICP비안을 발급받지 않은 도메인에 대해서도 EdgeOne의 서비스를 이용할 수 있게 해주는 기능입니다. (출시 기준으로 Enterprise 플랜에서만 사용가능합니다.)

적용 방법

우선 타겟 도메인에 대해 Acceleration region을 Global (MLC excluded)로 선택하고 EdgeOne에 등록합니다. (도메인 등록 방법참고)

도메인 등록 완료 후 EdgeOne 콘솔에서 Site Acceleration → Network Optimization 에서 Cross-MLC-border acceleration 을 활성화하면 바로 적용이 끝납니다. (만약 해당 항목이 보이지 않거나 토글이 활성화되지 않는다면 화이트리스팅이 필요할 수 있으므로 관련 MSP에 문의하도록 합니다.)

적용 여부 확인

중국 현지의 유저가 Cross-MLC-border acceleration 기능이 활성화된 가속 도메인에 접근하면 EdgeOne은 자동으로 홍콩 지역 노드로 트래픽을 라우팅 합니다. 적용 여부를 판단하기 위해 중국 현지의 유저에게 부탁하여 엑세스 노드의 IP가 홍콩 지역인지 확인합니다.

성능 테스트

웹 사이트 로딩 시간 측정을 위한 다양한 방법이 있지만 중국 현지에서 테스트 하기 위한 여러 여건등을 고려하여 크롬 개발자도구와 중국 전 지역에서 타겟 도메인으로의 ICMP 응답 시간 및 HTTP 요청 지연시간을 시각화 해주는 중국 플랫폼을 통해 간단하게 Cross-MLC-border acceleration 적용 전, 후 속도변화를 테스트하였습니다. (사용한 Tool과 현지 환경 상 변수 통제가 어려워 정밀한 결과 값은 아닐 수 있으니 변화량 정도만 가볍게 파악하시면 좋을 것 같습니다.)

[적용 전 - 타 사 CDN 사용]

[적용 후 - Cross-border acceleration]

[웹 사이트 응답 지연시간 시각화 결과]

위 사진은 중국 각 지역의 ICMP 요청 응답 및 HTTP 응답에 대한 지연시간을 시각화합니다. 초록색에 가까울 수록 지연시간이 짧고 빨간색에 가까울수록 반대의 경우입니다. 좌측이 적용 전, 우측이 EdgeOne Cross-border acceleration 서비스 적용 후의 결과입니다.

EdgeOne 대시보드에서 Cross-border acceleration에 해당하는 트래픽 사용량을 체크할 수 있습니다.

마치며

 중국시장을 대상으로 IT 플랫폼 서비스를 제공하는 기업에게 ICP 비안은 항상 해결해야할 숙제입니다. 특히 해외 진출을 처음 시작하는 중소기업이나 ICP 비안 발급이 시스템적으로 어려운 공공 기관의 경우에도 중국 현지 사용자들의 서비스 이용 수요를 외면할 수 없기 때문입니다. 이런 상황에 놓인 기업들에게 EdgeOne의 Cross-border acceleration 상품은 효과적인 해결책이 될 수 있습니다.

<<이전 글 에 이어

다음으로 찾은 건축과 부동산 관련 코너(없는 분야가 없는 듯..) 설계부터 디자인, 건축, 서비스까지 텐센트 생태계를 활용하는 방법을 소개해준다.

여긴 XR(확장현실)을 이용한 프로그램을 직접 활동을 통해 체험해볼 수 있는 코너였는데 저 초록색 공간 안에 들어가서 몸을 움직이면 스크린에 실제 인물이 캐릭터로 변환되는 모습을 볼 수 있다. 마음 같아서는 들어가서 춤이라도 추고 싶었지만 행사의 퀄리티 유지를 위해 참기로 했다.

Tencent Cloud 엣지원 소개부스, EdgeOne은 텐센트클라우드의 애플리케이션 가속 및 보안 솔루션으로 텐센트클라우드에서 차세대 CDN 상품으로 밀고 있는 것 같았다. (실제로 이후 CDN이 EdgeOne으로 기능이 완전 통합되었다.)  관련 상품팀 매니저 분들이 적극적으로 응대를 해주셔서 오랜 시간 상품 설명을 자세히 들을 수 있었다. 

이렇게 Energhy & Resources 관련 부스도 있었는데 가볍게 훑어보고 지나갔다.

중간 구역을 지나면 이렇게 텐센트클라우드의 데이터 센터와 CDN PoP 위치를 도시 위에 상징적으로 표시해 놓은 조형물이 보인다. 대형스크린에는 새로 오픈한 텐센트클라우드의 IDC에 대한 소개 영상이 나왔다.

조형물을 지나서 왼쪽으로 방향을 틀었더니 메디컬 섹션이 자리하고 있었다. 이 날 내가 갔던 시간대에 부스들 중에서 이쪽에 사람이 제일 많았다. 왜 그런가 했더니

이렇게 텐센트클라우드의 기술을 활용한 의료기술 장비를 직접 체험할 수 있는 공간이 몇 군데 있었다. 이 곳에는 사진에 보이는 것처럼 실제 안과에서 우리가 시력을 잴 때 쓰는 기구가 있고 렌즈에 눈을 갖다 대면 AI가 직접 안구를 분석해서 건강상태가 어떻고 어떤 안구질환의 위험이 있는 지를 데이터를 뽑아주는 체험코너가 있었다.

이런 건 또 그냥 지나칠 수 없어 한 번 몸소 체험을 해보았다. 

눈 사진을 한 번 찍고 나서 분석하는 데 시간이 좀 걸린다. 다른 곳에 한 바퀴 돌다오면 검사결과지를 받을 수 있다. 나는 위챗 메신저를 통해서 결과보고서를 전달받았다.

안과 옆에는 사람들이 모여서 화면을 바라보며 마이크에 대고 말을 하고 있었다. 화면 속에 있는 건 바로 AI로 만든 스마트닥터 인데 마이크에 자신의 증상을 말하면 음성인식을 통해 AI 닥터가 자세한 진단을 위해 관련된 몇 가지 상세질문을 제시하고 거기에 맞게 대답을 몇 번 하다 보면 최종적으로 처방을 내려주는 걸 현장에서 확인할 수 있다.

생각보다 음성인식 정확도가 높았고 반응도 빨라서 사람들이 신기해하며 줄을 서서 체험하고 있었다.

스마트 의료에 대한 소개. 텐센트가 개발한 스마트 의료 시스템을 중국의 유명 병원 및 의원에서 이미 많이 활용하고 있다는 내용이었다. 

메디컬 섹션을 지나니 텐센트 소프트웨어 상품에 대한 미니부스들이 줄지어 있었다. HR상품, 전자서명서비스, 설문조사 프로그램, Tencent Docs, Tencent One ID 등 다양했다.

텐센트 Financial Cloud에 대한 홍보공간. 크게 관심 있는 주제는 아니었지만 스탬프를 받을 수 있는 미션장소라 기웃거리다가 도장과 펭귄인형을 챙겨 왔다.

스마트모빌리티 섹션. 사실 저기 카운터에 보이는 펭귄인형을 보고 스탬프를 찍을 수 있는 부스인 줄 알고 도장을 찍으려고 했는데 아니었다. 덕분에(?) 상품 담당매니저님의 자세한 텐센트클라우드 기술을 활용한 스마트모빌리티에 대한 설명을 들을 수 있었다.

텐센트의 스마트모빌리티 기술은 단순히 자율주행과 같은 단일 기술에 대한 개발을 넘어서 차량연결 소프트웨어, 스마트 내비게이션, 공유자동차, 대중교통 등에 AI 기술을 접목시켜 교통산업 전체에 종합 솔루션을 제공하고 있었다. 실제로 저 운전석에 타볼 수 있었는데 차량 내부 대시보드에 다양한 기능들이 탑재되어 있었고 일부는 개인 스마트폰의 위챗 메신저와 연동이 되게 설계가 되어있었다.

다음은 텐센트클라우드의 게임생태계를 소개하는 공간이 있었다. 텐센트클라우드는 게임 개발, 테스트, 운영 및 서비스에 이르기까지 모든 게임에 대한 가장 우수한 클라우드 솔루션을 제공한다. 아무래도 가장 강점이 있고 이미 우수한 고객사도 많이 보유하고 있다 보니 오히려 부스에 크게 힘을 주지 않은 느낌이었다. 게임산업에 대한 텐센트의 자신감을 느낄 수 있었다.

게임 부스를 지나 만난 스마트 미디어 & 디바이스 부스. 스마트폰이나 스마트워치에 들어가는 텐센트의 소프트웨어와 텐센트클라우드의 서비스들이 소개되어 있었다.

메디컬 섹션 다음으로 사람이 많았던 VooV 체험장. VooV는 텐센트의 화상회의 플랫폼인데 우리가 평소에 자주 쓰는 Zoom이나 Google meet 같은 프로그램에 더 많은 기능을 넣었다고 보면 될 것 같다. 화상칠판 솔루션 업체와 협업한 내용과 화상회의에 접목된 AI 기반 기능에 대해 시연하고 있었다.

바로 옆 부스에서는 VooV에 탑재된 텐센트의 음성인식 솔루션에 대해서 체험할 수 있는 코너가 있었다.

사진에 보이는 태블릿에 아이폰에서 시리를 부르 듯 봇을 부르면 질문을 할 수 있다. 위에 적힌 사용 예시에는 자동차 내비게이션에 음성인식이 설치된 상황을 시나리오로 해서 여러 가지 명령을 동시에 내리는 것도 가능하다고 안내하고 있다.

이외에도 디지털 휴먼 시연 및 텐센트클라우드 교육 솔루션에 대한 부스를 지나

중국 최대 규모 메신저인 Wechat과 기업버전인 Wecom 부스를 마지막으로 관람을 마무리했다.

도장도 다 모았다.

모든 스탬프 미션을 성공하면 얻을 수 있는 경품.

발품을 팔아서 모은 전리품들.

참관 소감

 평소 클라우드 관련 컨퍼런스나 써밋을 많이 참석하는 편인데, 사실 텐센트의 행사는 처음이라 참관하기 전까지만 해도 감이 잘 잡히지 않았다. 그런데 실제로 참관해 보니 텐센트의 이름에 걸맞게 다양한 볼거리와 인사이트를 얻을 수 있는 시간이었다.  특히 인상 깊었던 것은 국내에서 열리는 다른 클라우드 컨퍼런스의 경우 벤더 사 자체에서 운영하는 부스도 있지만 MSP나 파트너사가 운영하는 부스가 많은 비중을 차지하는데 반해 이번 행사는 텐센트의 부스만으로 대부분의 공간을 채운 점이었다. 

 그러나 보통 이런 행사들은 내가 익히 들어 알고 있는 국내 대기업의 담당자나 스타트업의 CTO들이 많이 발표자로 참여하는 편이라 세션을 듣는 재미가 있었는데 이 행사의 경우 내가 중국 IT기업들의 테크니션들에 대해 아는 정보가 많이 없어서 세션을 많이 찾아 듣지 못해서 그 부분은 아쉬움이 남았다. 그렇지만 현재 중국의 최신기술의 중심에 텐센트클라우드가 위치하고 있다는 걸 직접 체험할 수 있는 귀한 시간이었다.

 * 일정 내내 불편함이 없도록 중국 현지 직원과의 커뮤니케이션 및 원활한 행사참여에 큰 도움 주신 Tencent Korea 시니어 채널 매니저님께 이 글을 빌어 다시 한번 감사의 말씀을 전합니다.

Tencent Cloud EdgeOne

*********************

https://edgeone.ai/

**********************

Tencent Cloud EdgeOne

 EdgeOne은 애플리케이션 가속과 보안기능을 결합한 Tencent Cloud만의 독특한 상품입니다. 전 세계 엣지 노드를 바탕으로 하여 사용자에게 빠르고 안전한 온라인 경험을 제공하는 솔루션으로, 기본적인 CDN 가속 뿐만 아니라 다양한 기능을 통해 웹사이트와 애플리케이션의 성능을 최적화하고 보안을 강화합니다. 본문은 EdgeOne의 많은 기능 중 가속 솔루션에 대한 간단한 적용 가이드 및 성능 테스트 결과에 대한 내용을 담았습니다.

요금제

EdgeOne은 서비스 이용을 위해 요금제가 Personal / Basic / Standard / Enterprise 로 구성되어 있고 각 플랜마다 사용할 수 있는 기능에 제한이 있습니다. 일반적으로 EdgeOne의 기능을 활용하여 원활한 서비스를 운영하려면 Enterprise 플랜을 구매하는 것이 좋습니다. 가격은 공개되어있지 않으나 Tencent Cloud MSP를 통해 문의하면 매우 합리적인 가격에 플랜 구매가 가능하니 Enterprise의 사용을 권장드립니다. 이 글은 Enterprise 플랜을 기준으로 작성되었습니다.

EdgeOne Node

EdgeOne 자원은 전 세계 70개 이상의 국가 및 지역에 분산되어 있으며, 2800개 이상의 가속 노드를 보유하고 있습니다. 최소 40TB에서 최대 1.5PB에 이르는 저장용량을 보유한 노드들이 생산하는 대역폭의 총량은 160Tbps을 초과합니다. 이처럼 거대한 네트워크 리소스를 기반으로 EdgeOne은 다양한 지역에 분산된 서비스와 이용자 간의 연결품질을 효과적으로 개선하고 갑작스러운 트래픽에 대비할 수 있습니다.

EdgeOne 장점

• 정적 컨텐츠 가속 : Tencent Cloud의 엣지 노드를 활용하여 원본 서버(origin)의 정적 컨텐츠를 캐싱하고, 이를 통해 사용자에게 더 빠르게 콘텐츠를 제공하는 기능입니다. 
• 동적 컨텐츠 가속 : EdgeOne은 각 노드에서 발생하는 네트워크 지연 시간을 실시간으로 모니터링하고, 이를 바탕으로 가장 효율적인 origin-pull 경로를 지능적으로 결정하여 동적 컨텐츠의 라우팅을 최적화합니다.
• 애플리케이션 가속 : EdgeOne의 광범위한 L4 프록시 노드를 통해 고가용성 애플리케이션 트래픽의 연결 최적화를 지원합니다.
• 다양한 API 지원 : Tencent Cloud API와 Terraform API를 통해 EdgeOne 기능을 간편하게 구현할 수 있습니다. 
• 웹 보안 기능 : Tencent의 AI엔진을 통해 웹 요청을 공격샘플과 비교하여 CSRF, SQL 인젝션, XSS 어택등의 웹 애플리케이션 공격을 효과적으로 차단합니다. 
• DDos 공격 방어 : Tencent의 AI 지능형 인식 및 보호 알고리즘에 기반한 기본 보안 정책 및 실시간 모니터링을 통한 초단위 DDos 공격 보호를 제공합니다.
• 맞춤형 접근 제어 규칙 설정 : IP, allowlist/blocklist 기반 접근 제어 이외에 복잡한 엑세스 제어 규칙생성을 통해 사용자 비즈니스 요구에 기반한 맞춤형 보안 솔루션 구축이 가능합니다.
• 실시간 모니터링 및 대시보드 : EdgeOne 콘솔에서는 가속기능 및 보안솔루션에 대한 실시간 모니터링을 제공합니다. 

EdgeOne Console

 Edgeone 콘솔에 접속하여 도메인을 등록하면 위와 같이 해당 도메인에 대한 Edgeone의 모든 설정관리가 가능하며 활성화 기능에 대한 실시간 모니터링을 지원합니다. 

도메인 등록하기

EdgeOne 플랜 구매 후 타겟 애플리케이션의 도메인을 등록 및 검증을 하는 간단한 과정이 필요합니다. 아래 간단한 가이드를 참조하거나 아래 텐센트클라우드 공식 문서를 참조하여 사이트 등록 후 구매한 플랜과 바인딩 합니다. 

1. Tencent Cloud EdgeOne 콘솔에 접속하여 Site List → New site 클릭합니다.

2. 등록하려는 사이트의 도메인을 입력합니다.

3. 요금제 플랜을 선택합니다. (아직 플랜을 구매하지 않은 경우 → Purchase plan)

4. 가속노드의 리전유형을 선택합니다. 중국을 제외한 지역에 서비스하는 경우 Global (MLC excluded) 를, 서비스 지역에 중국이 포함된다면 Chinese mainland 혹은 Global을 선택합니다. 이 경우 등록 도메인에 ICP비안이 발급되어 있어야 제한없는 사용이 가능합니다. 

5. Access mode를 선택합니다. CNAME과 네임서버를 통한 엑세스 방식을 지원합니다. 네임서버 엑세스의 경우, 도메인의 네임서버 라우팅을 EdgeOne의 네임서버로 변경하는 방식이고 CNAME 엑세스는 일반적인 DNS CNAME 설정을 통해 EdgeOne 가속 도메인으로 트래픽을 라우팅하는 방식입니다. 

6. CNAME 엑세스 모드를 선택하였다면 도메인 소유에 대한 검증이 필요합니다. 보유 도메인 레지스트라의 DNS설정에서 제시된 TXT레코드를 추가하고 verify를 클릭합니다.

7. 사이트 추가가 완료된 모습입니다.

Site Acceleration

도메인 등록 후 Site Acceleration 활성화를 위해 몇 가지 추가설정을 진행합니다.

[ CNAME access mode 기준 ]

1. EdgeOne 콘솔 메인화면에서 좌측 Domain Name Service → Domain Management 클릭합니다.

2. Add domain name 클릭합니다.

3. 클라이언트가 접속할 도메인 경로를 입력합니다. 루트 도메인으로 설정하는 경우 @를 입력합니다.

4. 해당하는 Origin type을 선택합니다.

5. 실제 원본 컨텐츠가 위치하는 origin 도메인 혹은 로드밸런서 엔드포인트를 입력합니다. 클라이언트 도메인과 동일하게 입력하는 경우 DNS 무한루프에 빠질 수 있으므로 주의합니다.

6. origin에 대한 추가설정을 완료 후 Next를 클릭하면 다음 화면으로 Tencent cloud에서 제공하는 가속 시나리오별 템플릿을 선택하는 화면이 나오는데 원하는 것을 선택하고 없는 경우 skip 합니다.

7. 설정 완료 후 생성된 EdgeOne 가속 도메인을 확인할 수 있습니다. 

[ NS access mode 기준 ]

1. 초기설정에서 NS access mode 를 선택한 경우, CNAME 과 다르게 EdgeOne 콘솔 Domain Name Service 하위에 Acceleration 메뉴가 생성되는데 이를 클릭합니다.

2. Add Record를 클릭하여 클라이언트 도메인 호스트 레코드를 등록합니다.

3. 등록된 레코드를 확인하고 Enable acceleration 을 클릭합니다.

4. 활성화된 도메인을 확인할 수 있습니다. 

DNS 조회를 통해 정상적으로 EdgeOne이 작동하는지 확인하면 모든 절차가 완료됩니다.

Rule Engine

도메인 등록 후 EdgeOne 가속 도메인에 대한 Rule Engine 설정을 할 수 있습니다. Rule Engine 은 개별 비즈니스 요구사항에 맞게 도메인 라우팅 규칙과 캐시 규칙에 대한 설정이 가능합니다. 캐시관련 설정은 좌측의 Site Acceleration → Cache Configuration 메뉴 에서도 가능하나 Rule Engine의 설정이 항상 우선합니다.

Create rule을 클릭합니다.

매칭 타입 및 규칙을 선택하여 Rule Engine 구성을 진행합니다. 옵션별 상세한 기능은 Tencent Cloud EdgeOne 공식문서를 참고할 수 있습니다. (https://edgeone.ai/)

참고자료

https://edgeone.ai/