BLOG

트위치는 자사 서비스를 어떻게 모니터링할까?
작성일: 2019년 6월 4일

Alex Cioc과 Steve McCurry가 쓴 글을 전합니다.

 

아마존이 2014년 인수한 트위치는 멀티플레이어 엔터테인먼트의 선도적인 서비스 및 커뮤니티입니다. 트위치는 소셜 기능 및 마이크로 트랜잭션 기능을 제공해 시청자가 콘텐츠에 참여하도록 유도합니다. 이 서비스들은 거래가 활발합니다.

 

트위치는 아마존 CloudWatch로 비즈니스 크리티컬 서비스를 모니터링합니다. 그런 다음 주요 사용자 지정 메트릭스에 대해 미리 정의된 임계값을 기반으로 사용자 지정 메트릭스를 눈으로 확인할 수 있게 해주고 경고를 띄웁니다. 트위치 서비스에서 트랜잭션을 대량으로 처리하게 되면 데이터 수집 비용의 균형과 충분한 데이터 처리량 제공, 이 두 마리 토끼를 잡는 메트릭 수집 전략을 세우기 어렵습니다.

 

아마존 CloudWatch client-side aggregation은 PutMetricData API 서비스의 새로운 기능입니다. 사용자가 데이터를 집계하는 작업을 지원해 처리량을 늘리고 효율성을 높여 줍니다. 트위치는 효과적인 메트릭 수집 아키텍처를 구축하면서 어떻게 비용까지 절감하는 걸까요? 힌트는 client-side data aggregations에 있습니다.

 

 

CloudWatch 사용자 지정 메트릭 개요

아마존 CloudWatch는 사용자가 자체 시스템 또는 애플리케이션 메트릭스를 사용자 지정 메트릭스로 게시할 수 있게 해줍니다. 사용자 지정 메트릭스를 게시할 때 추천하는 방법은 호스트에 CloudWatch 에이전트를 배포하는 겁니다. CloudWatch 에이전트는 client-side 데이터를 자동으로 집계해 CloudWatch PutMetricData API 서비스로 데이터를 보냅니다.

 

이전까지 PutMetricData는 API 호출이 있을 때 메트릭 하나 당 단일 데이터 포인트를 게시하는 것 지원했습니다. 이제 client-side aggregation 기능으로 PutMetricData에 값과 수(또는 히스토그램)의 배열을 게시할 수 있습니다. Client-side aggregation을 이용하면 이전보다 더 많은 데이터를 더 싼 가격으로 보낼 수 있어 PutMetricData API를 호출해야 하는 경우가 줄어듭니다. 호스트에서 리소스 활용도도 낮아집니다.

 

 

트위치 데브옵스

트위치에는 트위치 Telemetry 플랫폼을 개발 및 관리하고 조직 전반에서 트위치 Telemetry 플랫폼을 잘 활용할 수 있도록 돕는 중앙 집중식 도구 팀이 있습니다. 트위치 Telemetry는 메트릭스를 수집하고, 전송하고 활용하기 위한 라이브러리를 제공해 트위치 서비스 팀이 서비스를 모니터링하는 작업을 돕습니다.

 

트위치 Rewards와 트위치 Emotes 서비스는 모두 데브옵스 팀으로, 트위치 Telemetry을 이용해 API를 모니터링하고 아마존 CloudWatch에 메트릭스를 보냅니다.

 

  • 트위치 Rewards는 오버워치 리그 같은 방송을 보는 사람들이 비트를 사용하는 선수들을 응원할 수 있게 해줍니다. Rewards 서비스는 초당 최대 1500건의 트랜잭션을 처리할 수 있습니다.
  • 트위치 Emotes는 소셜 채널 페이지에 이모티콘을 띄웁니다. Emotes 서비스는 매일 약 10,000 TPS를 찍습니다.

 

 

트위치는 모니터링을 어떻게 할까?

트위치 Telemetry 이전에 출시된 서비스들은 아마존 CloudWatch에 메트릭스를 전송할 때 맞춤형 툴을 썼습니다. 트위치 서비스는 메트릭스 게시 도구를 효율적으로 확장해야 하는 모니터링 문제가 있었습니다. 서비스들은 사용할 수 있는 데이터 관측치의 극히 일부만을 공개하는 해결책을 선택했습니다. 이런 샘플링 접근방식은 모니터링 시스템에 대한 호출을 줄였지만 데이터가 손실돼 정확한 지표를 얻을 수 없었습니다.

 

트위치 Telemetry는 에이전트 라이브러리를 제공해 서비스 팀이 API 기반 서비스들을 통합하고 아마존 CloudWatch에 사용자 지정 메트릭스를 보낼 수 있게 해줍니다. 트위치 Emote와 트위치 Rewards 같은 서비스들은 트위치 Telemetry를 도입했습니다. 트위치 Telemetry는 메트릭 데이터를 일괄 처리한 후 아마존 CloudWatch로 보냅니다.

 

트위치 데브옵스 팀이 모니터링하는 주요 지표는 대기 시간, 오류 및 제한(throttling)입니다. 트위치 데브옵스 엔지니어는 CloudWatch가 자동으로 계산하는 메트릭 백분위수 통계를 모니터링합니다. 백분위수 통계를 모니터링하면 백분위수 데이터에서 아웃라이어가 제거된 명확한 정보를 얻을 수 있습니다. 이는 일정 기간 동안 메트릭스 샘플 카운트가 높을 때 특히 유용합니다(예: 볼륨이 높은 API 서비스 데이터 관찰).

 

CloudWatch의 경우, Graphed Metrix 탭의 통계 옵션에서 샘플 수 및 백분위수 통계를 선택할 수 있습니다.

 

 

아마존 CloudWatch client-side aggregations 구현

트위치 엔지니어링 팀은 아마존 CloudWatch client-side aggregation으로 메트릭스 게시 툴링을 확장할 수 있는 기회를 잡았습니다. 트위치는 client-side aggregation로 CloudWatch PutMetricData API 서비스 호출 수를 줄여 공개된 데이터 볼륨을 늘렸습니다. 더불어 리소스와 비용도 절감했습니다. 트위치는 분당 데이터 관측 횟수를 더 많이 공개해 백분위수 모니터링에 적합한 측정 지표를 만들 수 있었습니다.

 

트위치 Telemetry는 아마존 CloudWatch 에이전트의 수정 버전에 CloudWatch client-side aggregation을 구축합니다. 에이전트는 client-side 데이터를 자동 집계해 CloudWatch PutMetricData에 대한 API 호출 수를 줄입니다.

 

Clinent-side aggregations로 전환한 결과, 트위치 Emotes 서비스는 하루 PutMetricData 호출이 200만 건에서 2만 건으로 줄었습니다. 그러자 비용이 99% 절감되는 효과가 나타났습니다. 이전에는 Emotes 서비스가 10%의 비율로 샘플링되고 있었는데, client-side aggregation이 구축된 후 샘플링이 제거되고 모든 데이터가 CloudWatch에 게시됐습니다. 서비스 호스트의 CPU를 훨씬 덜 쓰게 됐고, fleet 확장성도 늘었습니다.

 

아래 그래프는 client-side aggregation에 대한 2018년 11월 30일자 마이그레이션이 트위치 fleet에 어떤 영향을 미쳤는지를 보여주고 있습니다.

 

 

트위치 Rewards 서비스는 하루 PutMetricData 호출이 하루에 약 4억 5천만 건에서 약 400만-500만 건으로 줄었습니다. 호출 양이 99% 감소하는 것과 비례해 API 비용도 줄었습니다. Client-side aggregation으로 전환하면서 샘플링이 제거됐습니다.

 

트위치 Emotes와 트위치 Rewards, 이 두 가지 서비스만 해도 1년 동안 직접적으로 절감되는 비용은 상당했습니다. 또 샘플링이 제거돼 이전보다 정확히 측정할 수 있게 됐고 fleet 확장성도 늘어났습니다.

 

 

결론

Client-side metric aggregations는 CloudWatch PutMetricData API 서비스의 새로운 기능으로, 메트릭스 데이터를 이전보다 효율적으로 수집할 수 있게 해줍니다. Client-side metric aggregations는 CloudWatch에 대한 API 호출 수를 줄여 리소스와 비용을 절감해줍니다. Client-side aggregations는 대기 시간, 오류 및 제한(throttling)과 같은 메트릭스를 게시하기 때문에 대용량 API를 모니터링하는 데 쓰일 수 있습니다. CloudWatch에서 계산한 백분위수 통계로 잘못된 경보를 일으킬 수 있는 노이즈를 줄일 수 있습니다. CloudWatch 에이전트는 기본적으로 client-side aggregation을 쓰도록 설정돼 있으며, CloudWatch에 사용자 지정 메트릭스를 게시할 때 권장되기도 합니다.

 

지금까지 트위치가 아마존 CloudWatch client-side aggregation으로 자사 서비스를 어떻게 모니터링하고 있는지 살펴봤습니다. 아마존 CloudWatch 에이전트를 배포해 애플리케이션용 사용자 정의 메트릭스를 게시하면 client-side aggregation 기능을 쓸 수 있습니다. CloudWatch 에이전트는 기본적으로 client-side aggregation을 지원하며 규모에 맞게 사용자 지정 메트릭스를 게시할 때 효율적으로 쓰일 수 있습니다.

 

아마존 CloudWatch 에이전트 설명서를 읽어 보시면 더 자세한 정보가 나와 있습니다. AWS 홈페이지에 오셔서 아마존 CloudWatch가 클라우드 리소스 및 애플리케이션 모니터링 데이터를 눈으로 확인할 수 있는 정보로 만들 때 어떻게 도움이 되는지 알아보세요. AWS 홈페이지에는 AWS SDK로 client-side aggregations를 이용해 아마존 CloudWatch에 데이터를 게시하는 데모 애플리케이션도 있습니다.

 

 

원문 URL : https://aws.amazon.com/ko/blogs/mt/how-twitch-monitors-its-services-with-amazon-cloudwatch/

** 메가존클라우드 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.