TITLE : 추천 서비스를 위한 데이터 분석 시스템 구축하기

YOUTUBE LINK : https://youtu.be/4ZG_2C_uR9M PRESENTER : Amazon Web Services Korea DURATION : 01:03:36 PUBLISHED : 2021-11-22

Table of contents

1. TITLE : 추천 서비스를 위한 데이터 분석 시스템 구축하기
2. FULL SCRIPT

FULL SCRIPT

안녕하세요.

AWS SolarLands 아키텍트 김성민입니다.

이번 시간에서는 추천 서비스를 위해서 저희가 데이터 분석 시스템을 어떻게 구축할 수 있는지 이걸 설명해 드리겠습니다.

그래서 이번 시간에 할 내용들을 한번 간략하게 살펴보면 먼저 저희가 데이터 분석을 하기 위해서 필요한 세 가지 사전 지식에 대해서 설명을 드릴 거고요.

그리고 실제 추천 시스템을 구축을 한다면 어떤 데이터가 필요한지 크게 두 가지가 있는데 하나는 사용자 행동로그, 그 다음에 실제 추천 성과를 분석하기 위한 지표들 이런 데이터가 있고, 그 다음에 세 번째로는 그렇다면 그 사용자 행동로그는 어떤 식으로 수집을 할 수가 있는지 그렇게 사용자 행동로그를 수집할 수 있는 데이터 분석 아키텍처는 어떤 식으로 구성할 수 있는지 설명을 드리고 그리고 마지막으로 추천 성과 분석을 위한 데이터 분석 시스템으로 어떻게 확장을 할 수가 있는지 처음에 추천 시스템을 만들기 위해서 저희가 사용자 행동로그를 수집할 수 있도록 만들었을 텐데 그렇다면 그 이후에 추천 성과 분석을 위해서는 어떤 식으로 그 시스템을 다시 확장할 수 있는지 이걸 설명을 드리고 그리고 마지막으로 오늘 이 시간에 했던 내용들을 한번 다시 정리를 해서 실제 데이터 분석 시스템 만들 때 어떠한 아키텍처 원리를 사용하시면 좋은지 간략하게 정리해 드리겠습니다.

그래서 사실 저희가 데이터 분석을 한다면 기본적으로 3가지 개념을 아실 필요가 있는데요 첫 번째는 데이터의 구조, 두 번째는 데이터의 온도 스펙트럼, 세 번째는 그런 데이터들을 처리하는 데이터 파이프라인 구조에 대해서 먼저 이해를 하고 계셔야 돼요.

그래서 하나씩 살펴보면 저희가 처리하는 데이터를 구조 관점에서 나눠본다면 첫 번째로는 맨 왼쪽에 보이시는 것처럼 모양이 다 일정하고 이렇게 딱 잘 정제된 형태의 스트럭쳐드 데이터가 있고 그 다음에 맨 오른쪽에서 보이시는 것처럼 서로 다르고 모양도 다르고 색깔도 다르고 정렬이 잘 안되어 있는 이런 형태의 unstructured data가 있고 그 다음에 일부는 정제되어 있고

또 일부는 잘 규격에 맞게끔 되어 있는데 또 일부는 그렇지 않은 그런 semi-structured data 이렇게 크게 3가지로 나눠볼 수가 있고요 보통 structured data라고 한다면 저희가 여러분들이 많이 사용하고 계시는 rds의 그런 테이블 형태의 데이터라고 생각하시면 되고 그 다음에 unstructured data 같은 경우는 이미지라든가 영상 이런 것들을 생각하시면 되고 semi-structured data는 json 형태의 그런 형태의 데이터라고 생각하시면 되요 json을 상상해 보시면 각각의 attribute가 있고 그래서 attribute가 있기 때문에 그 attribute가 약간 스키마 역할을 하는 것처럼 생각이 들긴 하지만 실제 그걸 어떻게 해석하는가에 따라서 실제 달라질 수가 있어서 이런 것들은 보통 semi-structured data라고 이렇게 얘기를 드리고요 그 다음에 두 번째로 여러분들이 아셔야 될 개념은 데이터 온도 스펙트럼이라는 게 있는데 이 부분이 왜 중요하냐면 실제 저희가 사용하는 데이터들을 어떤 access하는 빈도라든가 그때 한 번에 access할 때 얼마나 많은 데이터를 가져가느냐 이거에 따라서 저희가 hot data 아니면 cold data 이렇게 나눠볼 수가 있거든요 그래서 보통 cold data로 한다면 그냥 그 한 번 access하는 주기가 상당히 긴 거죠 한 번에 access한 다음에 몇일 후에 access을 한다던가 아니면 최소한 1시간 이상 이후에 access를 한다던가 이렇게 보통 access를 하게 되고 그래서 이렇게 access하는 주기가 길다 보니까 한 번에 가져가는 데이터 양도 상당히 많죠 그리고 실제 여러분들이 기대하는 것도 그러한 데이터들은 조금 가져오는데 시간이 오래 걸려도 그냥 이해를 하시는데 그런데 내가 지금 당장 쓰고 싶은 데이터가 있다 그렇다면 그런 데이터들은 가급적 수초 이내에 빨리 가져오기를 원하잖아요 그런 데이터를 hot data라고 그러고 그렇게 빨리 가져와야 되고 아주 빈번하게 요청을 하기 때문에 실제로 한 번에 많은 데이터 양을 가져올 수가 없거든요 그래서 이런 데이터의 특성을 가지고 있고 또한 이런 hot data하고 cold data 같은 경우가 앞서 설명드렸던 그 데이터 스트럭처 구조랑 비교를 해보면 실제로 hot data 같은 경우는 상당히 구조적인 경우가 많고 오히려 cold data는 그냥 unstructured data에 가까운 거죠 그래서 한 번 그냥 unstructured 형태로 구조가 없이 이렇게 쌓아놨다가 나중에 필요하면 그거를 가공을 해가지고 structure 형태로 만들고 그렇게 structure 형태로 만든 거를 이제 빈번하게 그리고 이제 빠르게 가져가는 형태로 hot data 형태로 만들어서 사용을 하시는 거죠 그리고 이런 온도 스펙트럼에 따라서 저희가 사용해야 될 그런 데이터 스토리지의 성격이라든가 이런 부분이 달라지기 때문에 이런 구조랑 온도 스펙트럼을 여러분들이 이해하시고 거기에 따라서 적합한 어떤 스토리지나 아니면 그 데이터를 프로세싱하는 그런 ETL 작업하는 프레임업을 선택하시는 게 좋습니다 지금까지는 데이터 자체에 대한 특성으로만 저희가 데이터에 대해서 봤는데 그렇다면 이런 데이터를 가공을 한다는 측면에서 본다면 저희가 대체로 그 데이터 가공 프로세스는 지금 보이시는 그림처럼 크게 한 4단계에서 5단계 정도로 생각해 볼 수가 있거든요 그래서 원본 데이터가 이렇게 있으면 맨 오른쪽에 어떤 데이터가 있다면 그 데이터가 맨 오른쪽에 이제 저희가 이런 데이터로 어떤 인사이트를 얻거나 아니면 원하는 답을 얻고 싶을 때 이런 데이터를 가공을 하고 분석을 하실 거예요 그때 이제 하는 단계가 먼저 분석이라든가 각 인사이트를 얻기 위해서 필요한 데이터를 수집을 하고 수집한 데이터를 어딘가에 저장을 한 다음에 그 다음에 실제로 그 데이터를 사용하기 쉽도록 변환을 하는 작업을 하죠 저희가 보통 그거를 ETL 또는 ELT 이런 식으로 얘기를 드리고 그렇게 변환한 결과를 다시 한번 어딘가에 또다시 저장을 하고 그 다음에 그 저장된 데이터를 이렇게 소비를 해서 어떤 원하는 답을 찾거나 데이터에 대해서 인사이트를 얻거나 이런 작업들을 하실 거예요 그리고 이런 식의 전체적인 과정을 저희가 구축을 하는 방식을 보통 데이터 파이프라인 이렇게 얘기를 하고 이런 데이터 파이프라인을 구축하실 때 항상 고려하실 점이 이 데이터 파이프라인을 통과하는 데이터 즉 데이터를 넣었을 때 우리가 원하는 결과를 얼마나 빠른 시간에 얻을 수 있느냐 이거에 따라서 각각의 단계에서 어떤 솔루션을 써야 될지 결정이 되고 또 한 가지는 그러면 또 얼마만큼 많은 데이터를 이 데이터 파이프라인에서 한꺼번에 처리할 수 있느냐 이런 것도 생각하셔야 되죠.

빠르면서도 많은 양을 처리해야 되는 이런게 가장 좋은 건데 또 이제 이렇게 두 가지를 고려하시면서 그 다음에 이런 것들 때문에 실제로 그 두 가지 다를 다 달성하기 위해서는 이제 비용 문제, 비용 각점에서도 좀 달라지거든요.

그래서 두 가지를 다 높게, 그러니까 latency도 낮게 하고 throughput도 높게 한다면 이제 비용이 높은 어떤 그런 좋은 솔루션을 쓸 수도 있고 근데 우리는 latency는 낮고 대신에 throughput도 높으면 좋다 그렇다면 비용을 조금 낮춰가지고 또 이제 만들 수도 있고요.

그래서 크게 이런 데이터 파이프라인을 구성하실 때 latency, throughput, cost 이런 세 가지 관점에서도 이렇게 접근하셔서 구성하시고 분석을 하실 수가 있습니다.

이렇게 데이터를 분석하기 위해서 세 가지 개념에 대해서 먼저 얘기를 드렸는데 그렇다면 이런 세 가지 개념을 이해하시고 있다고 생각하신 다음에 그러면 추천 시스템을 만든다고 한다면 그 데이터를 어떤 식으로 가공을 하고 또 어떤 데이터가 필요할까 이걸 한번 생각을 해 보면 저희가 추천 계산을 위해서는 특히나 이제 콜라보레이티브 필터링 이라든가 저희가 이제 아마존 퍼스널라이즈 같은 것을 활용하기 위한다면 사용자가 어떤 아이템에 어떤 행동을 했는지 사용자의 행동 로그 같은 것이 필요하거든요 장바구니에 담았다든가 상품을 구매했다든가 이런 게 필요하고 또 한 가지는 그렇게 해서 추천을 적용했다고 친다면 그러면 그 추천의 성과를 측정하기 위해서 그러면 추천 아이템은 어떤 위치에 얼마나 많이 몇 회 동안 노출이 됐고 그 다음에 그렇게 노출이 됐을 때 실제 사용자들이 얼마나 많이 클릭을 했는지 이런 것들을 데이터로 수집을 해야지 실제 측정을 할 수가 있거든요 그래서 실제로는 추천 시스템에 필요한 데이터는 크게 사용자 행동 로그랑 그 다음에 추천 성과 측정에 필요한 데이터 이렇게 크게 두 가지가 있다고 생각하시면 됩니다 그래서 사용자 행동 로그를 수집하는 부분을 생각해보면 저희가 아마존 퍼스널라이즈라고 하는 그런 서비스를 이용해서 추천을 만든다 이렇게 가정을 해본다면 사용자 행동 로그는 퍼스널라이즈 쪽에 실제 유저 아이템 인터랙션을 활용하는 이런 데이터 세트로 해서 이렇게 들어오게 되고 또 한 가지는 실시간으로 사용자들이 발생시키는 그런 데이터들 같은 경우를 퍼스널라이즈 쪽으로 수집을 하고 싶다 그렇다면 이벤트 트레이커를 활용하셔서 이벤트 트레이커로 실시간으로 데이터를 보내주면 이게 퍼스널라이즈가 활용할 수 있는 이런 구조가 되거든요 그러면 퍼스널라이즈는 이런 형태로 데이터를 수집을 하고 있는데 그러면 퍼스널라이즈를 적용한 구조에서 어떻게 데이터를 퍼스널라이즈로 보낼 수 있을까?

퍼스널라이즈 적용하려면 이렇게 4가지 단계를 거쳐서 데이터 세트에 대한 스케마를 생성하고 데이터 세트를 임포트하고 모델을 생성하고 추첨 결과를 서빙할 수 있는 엔드포인트를 만들어서 서비스에 적용할텐데 이때 필요한 데이터들은 이런 작업들은 이제 스탯 펑션 같은 걸 이용해서 자동화를 시킬 수가 있고 이때 필요한 데이터들은 저희가 S3에 저장을 해야 되는데 그때 S3에 크게 3가지 종류의 데이터가 저장된다고 생각하시면 됩니다 그래서 사용자의 행동록을 저장하는 인터랙션, 사용자에 대한 정보를 저장하는 유저, 아이템에 대한 정보를 저장하는 아이템 수 그렇다면 실제 이러한 S3로 어떤 식으로 데이터를 빠르고 안전하게 그 다음에 데이터가 유시리 없이 저장을 할 수 있을까?

이 파이프라인에 대해서 조금 더 고민을 해보면요 저희가 보통 실시간으로 어떤 데이터 분석을 하고 데이터 파이프라인을 구성한다 그렇다면 그 주요한 컴포넌트가 있는데 그것들에 대해서 먼저 설명을 드리면 맨 왼쪽에 어떤 데이터 소스가 있고 그 다음에 맨 오른쪽에 그 데이터를 최종적으로 처리하는 저장하거나 분석하거나 이런 식으로 처리하고 있는 데이터 싱크 부분이 있다고 친다면 실제 데이터 소스에서 데이터 싱크로 데이터를 보낼 때 대부분 그냥 원본 데이터를 그대로 보내지 않고 대체로 싱크 쪽에 저장하기 쉽도록 아니면 싱크 쪽에서 데이터를 사용하기 쉽도록 데이터를 한번 가공을 하는데 그게 단순히 데이터가 한 번에 이렇게 딱 만들어져 있고 그걸 한 번에 그냥 딱 데이터를 가공하면 끝나는 게 아니라 계속 실시간으로 데이터가 들어오고 그 상태에서 데이터를 가공하는 그렇게 가공해줄 수 있는 스트리밍 프로세스라고 하는 컴포넌트가 필요하고 그렇다면 스트리밍 프로세스에서 그 데이터를 가공을 할 텐데 이때 한 건씩 이렇게 처리하면 이게 수루풋이 안 나오기 때문에 저희가 일정한 크기로 데이터를 모아가지고 스트리밍 프로세스에서 한 번에 처리할 수 있도록 약간 버퍼 역할을 해주는 스트리밍 스토리지 같은 것을 활용합니다.

그리고 그렇다면 스트리밍 스토리지에서 데이터 소스로 어떻게 데이터를 넣어줄 수 있느냐 그게 스트리밍 스토리지의 종류에 따라서 방식이 조금씩 달라지는데 그런 부분을 처리해주는 게 스트리밍 인제스천이라고 생각하시면 됩니다.

그래서 실제로 저희가 실시간으로 데이터를 이동을 시키거나 아니면 분석을 할 때 이런 때는 크게 보면 데이터 소스에서 데이터 싱크 쪽으로 데이터 보내는 과정 중에 스트리밍 인제스천을 통해서 스트리밍 스토리지 쪽으로 데이터를 저장을 하고 그리고 스트리밍 스토리지에 저장된 데이터를 가져와서 스트리밍 프로세스에서 일정한 크기로 모아가지고 한 번씩 처리한 결과를 데이터 싱크 쪽으로 넣어주는 이런 형태로 구성이 된다고 생각하시면 되고요.

그래서 사용자 행동 로그 역시 이렇게 보시면 처음에 이커머스 웹사이트를 처리하는 웹서버가 있다고 했을 때 이 웹사이트에 사용자들이 접속을 하면 그 웹서버 쪽으로 사용자들의 로그가 들어올 거고 그게 이제 그러면 데이터 소스 역할을 할 거고 그 다음에 실제 퍼스널라이즈에서 필요한 데이터를 저장하고 있는 S3가 데이터 싱크 역할을 하게 될 거예요.

그러면 이제 이 사이에 앞서 얘기 드렸던 스트리밍 스토리지랑 스트리밍 프로세스 또는 스트리밍 딜리버리라고 해서 스토리지에서 데이터 싱크 쪽으로 데이터를 보내주는 이런 역할을 하는 스트리밍 딜리버리라고 하는 이런 컴포넌트가 필요하게 되거든요.

그러면 이제 이런 컴포넌트들이 필요한데 이것들 중에 AWS는 어떤 걸 쓸 수가 있을까?

이걸 한번 생각을 해보면 저희가 보통 스트리밍 스토리지로 AWS에서 사용할 수 있는 서비스는 가장 대표적인 Kinesis Data Streams가 있고 그 다음에는 저희가 오픈소스인 카포카를 메이드 서비스 형태로 제공해 드리고 있는 메이드 스트리밍 포카포카 줄여서 MSK라고 하는 게 있습니다.

그 다음에 그러면 스트리밍 스토리지에서 데이터를 읽어 가지고 최종 데스티니션인 S3로 데이터를 보내주거나 아니면 조금씩 가공을 해서 가공된 데이터를 보내주어서 저장시켜 줄 수 있는 그런 서비스로는 뭐가 있냐 이제 대표적인 게 Kinesis Data Files가 있는데요.

그래서 이것들을 조금 더 하나씩 살펴보면 먼저 스트리밍 스토리지 부분을 생각해보면 저희가 그냥 데이터 소스에서 바로 데이터 싱크 쪽으로 따로 그냥 데이터를 보낼 수가 있는데 굳이 왜 스트리밍 스토리지를 써야 될까?

그리고 스트리밍 스토리지를 썼을 때는 어떤 장점이 있을까?

이런 거에 대해서 의문을 가지신 분도 있을 거예요.

그런데 그것에 대해서 좀 더 설명을 드리면 저희가 스트리밍 스토리지를 쓰게 되면 실제로 아래 그림에서 보이는 것처럼 이제 맨 왼쪽은 데이터를 생산해내는 데이터 싱크 쪽의 프로듀서가 될 거고 오른쪽은 스트리밍 스토리지에서 데이터를 읽어 가지고 데이터를 소비하는 그런 컨수머라고 생각하시면 되거든요.

그런데 만약에 그 사이에 스트리밍 스토리지를 넣지 않게 되면 실제 프로듀서랑 컨수머가 연결되는 게 프로듀서랑 컨수머 1대1로 연결되다 보니까 그 연결되는 모습이 약간 메쉬 형태가 되고 금을 형태로 복잡해질 거예요.

하지만 중간에 스트리밍 스토리지를 넣음으로써 실제로 프로듀서 입장에서는 컨수머가 몇 개가 있든지 상관없이 나는 스트리밍 스토리지로 데이터를 넣어주면 알아서 컨수머가 스트리밍 스토리지 데이터를 가져갈 수 있겠지 이렇게 조금 더 아키텍처를 단순화 시킬 수가 있죠 그래서 실제로 프로듀서랑 컨수머를 디커플링 시킬 수가 있고 또 한 가지는 프로듀서랑 컨수머 사이에서의 속도 차이에 의해 가지고 만약에 프로듀서는 데이터를 엄청 빠른 속도로 생산을 했는데 컨수머는 소비하는 속도가 상당히 느리다면 실제로 데이터가 컨수머 쪽에서 소비가 안 되기 때문에 데이터가 프로듀서가 빠르게 생산하는 데이터들이 유실되거나 이런 확률이 크거든요.

그런 문제들을 스트리밍 스토리지를 도입함으로써 어느 정도 해소를 할 수 있다는 거죠.

그래서 만약에 프로듀서가 아무리 빨리 데이터를 생산을 해내더라도 스트리밍 스토리지 쪽에서 한번 버퍼링을 해가지고 가지고 있고 그렇다면 컨수머는 프로듀서의 생산 속도와 상관없이 이제 컨수머의 속도에 맞춰서 데이터를 가져가서 쓸 수가 있는 거죠.

그 다음에 이제 또 한 가지는 여러 개의 프로듀서가 있을 때 이런 프로듀서들의 데이터들을 하나의 스트리밍으로 합치고 싶다.

이때 이제 스트리밍 스토리지 같은 것을 활용하시면 거기에 데이터를 여러 개의 컨수머들이 서로 다른 종류의 프로듀서들이 동일한 스트리밍 스토리지에 데이터를 넣게 되면 자연스럽게 그 스토리지 안에는 여러 개의 스트리밍에서 들어오는 데이터들이 다 들어있고 그거를 컨수머는 한 번에 그냥 소비를 할 수 있다는 거죠.

그리고 이러한 스트리밍 스토리지는 일종의 인메모리 데이터 스트럭처인 CURE하고 똑같이 P4처럼 먼저 들어온 것을 먼저 처리할 수 있도록 순서를 유지해주고 있기 때문에 그런 면에서 실제 클라이언트 즉 컨수머 쪽에서 데이터 처리할 때 그러한 요구사항이 필요하다면 상당히 유리한 거죠.

사용하기 편하시고 그리고 또 한 가지는 이러한 스트리밍 스토리지 같은 경우에는 겉에서 보기에는 하나의 버퍼 또는 하나의 큐처럼 보이지만 실제 내부적으로는 여러 개의 큐랑 버퍼들을 가지고 있어서 각각의 버퍼들을 다른 컨수머들이 각각 읽어갈 수가 있기 때문에 실제 동시에 소비가 가능한 거죠.

그리고 보통 그런 걸 보고 스트리밍 램 리듀스라고 이렇게 얘기를 합니다.

그래서 저는 일반적인 스트리밍 스토리지의 장점에 대해서 설명을 드렸는데 그렇다면 실제 그런 스트리밍 스토리지 역할을 하는 Kinesis Data Stream과 MSK의 구조에 대해서 조금 더 설명을 드리면 Kinesis Data Stream이나 MSK는 인메모리 데이터 구조인 Q라고 생각하시면 일단 제일 쉽거든요.

그래서 맨 먼저 생각하실 때는 이 그림에서 맨 바깥쪽에 있는 이 커다란 원통을 생각하시면 돼요.

그래서 이 원통이 Q라고 생각하시면 되고 그렇기 때문에 실제 그런데 이렇게 하나의 큰 원통, 논리적으로는 하나의 큰 원통인데 그러면 이렇게 큰 원통으로 사용했을 때 문제가 되는 게 어떤 거냐면 만약에 프로듀서가 하나가 아니라 많아졌었다.

그렇게 된다면 하나의 Q만 사용했을 때는 그 Q가 모든 부하를 처리를 해야 되기 때문에 부하가 커지거든요.

그래서 부하 분산을 위해서 저희가 내부적으로 실제로 여러 개의 Q를 사용하게 되는 거죠.

그렇게 해서 실제 프로듀서가 많아졌을 때 여러 개의 Q에서 처리할 수 있도록 이렇게 설계를 했고 그 다음에 이렇게 여러 개의 Q에 어떤 식으로 데이터를 나눠줘야 될까 그때 사용하는 방식이 프로듀서에서 Partition Key라고 하는 이런 키를 주면 Hash Function을 이용해서 각각의 Q에 이렇게 데이터를 나눠주게 됩니다.

그리고 각각의 Q에 데이터가 이렇게 나눠지고 하나의 Q에 대해서는 순서가 보장이 되는 거죠.

그리고 이 각각의 Q를 이제 각각의 컨소머들이 따로따로 소비를 해나갈 수가 있고요.

그리고 여기서 또 한 가지, 이게 In-Memory Q하고 좀 다른 점이 뭐냐면 In-Memory Q 같은 경우는 만약에 데이터를 소비를 해가면 지금 맨 위에 있는 이 Q를 생각해 보시면 4번 위치에 있는 데이터를 소비를 해가게 되면 사실상 4번 앞에 있는 모든 데이터가 사라져야 되는데 실제로 이런 MSK나 Kinesis Data Stream 같은 경우는 데이터를 버리지 않고 그 다음에 다음에 읽어갈 위치에 대한 Offset만 변경을 시킵니다.

그럼으로써 만약에 다른 컨소머가 동일한 이 Q에서 처음부터 읽고 싶다 아니면 원래 이 컨소머가 다시 Offset을 바꿔서 처음부터 읽고 싶다

그러면 그런 부분이 가능하다는 거죠.

그렇기 때문에 이게 단순히 Q라고 부르지 않고 Storage라고 이렇게 얘기를 하는 이유가 이렇게 데이터를 읽어갔다고 해서 바로 지우지 않고 일정한 기간이 지나면 오래된 것들 중심으로 자동으로 지워지게끔 이렇게 만들었기 때문에 저희가 스트리밍 스토리지라고 얘기를 합니다.

그렇다면 이제 Kinesis Stream이랑 MSK 둘 다 스트리밍 스토리지로 쓸 수가 있는데 둘 중에 어떤 게 좋고 어떤 차이점이 있는지 이런 거에 대해서 궁금해하실 텐데요.

보통 Kinesis Data Stream 같은 경우는 저희가 Stream이랑 Shard라고 하는 논리적인 개념으로 저희가 구성이 된다면 MSK 같은 경우는 그에 대응되는 개념이 Topic하고 Partition이라는 개념으로 대응되거든요.

그래서 Stream이라고 한다면 하나의 큰 Q라고 생각하시면 되고 Shard는 그 안에 있는 작은 Q들을 Shard라고 생각하시면 돼요.

마찬가지로 MSK도 Topic이 하나의 큰 Q가 되고 Topic이 여러 개의 Partition으로 이루어졌다고 생각하시면 됩니다.

그리고 Kinesis Data Stream 같은 경우는 사실상 저희가 Open Source인 Kafka를 Kafka에 약간 대체된 형태로 AWS에서 만든 거기 때문에 사실상 MSK랑 Kinesis Data Stream이 기능적으로는 거의 동일하거든요.

유사해요.

하지만 이제 Open Source였냐 아니면 그냥 AWS로 만드는 서버레스 형태의 서비스냐 이 차이가 좀 커서 Open Source를 도입하셨던 고객분들 같은 경우는 기존에 Kafka를 쓰셨을 텐데 아마 그때 운영 부담이라던가 이런 것들이 좀 있으셨다면 MSK 같은 걸 도입하셨을 때는 조금 더 그런 부담에서 자유로울 수도 있겠죠.

그리고 이런 Kinesis Data Stream 같은 경우는 실제 만약에 스로프를 올리고 싶다 그렇다면 Shard 같은 걸 늘려가지고 스로프를 올리는 방식으로 처리를 하고 근데 MSK 같은 경우는 토픽 파티션 수를 늘리던가 이런 식으로 해서 스로프를 늘리는 방식이 아니라 약간 토픽이나 파티션을 제공해주는 브로커라고 하는 MSK를 구성하고 있는 또 다른 물리적인 어떤 서버가 있거든요.

그런 서버들을 늘려줌으로써 즉, MSK의 클러스터 자체를 늘려줌으로써 실제로 성능을 올리는 이런 식으로 대응이 된다고 생각하시면 됩니다.

그리고 MSK랑 Kinesis 중에 어떻게 보면 가장 큰 차이점은 실제 Kinesis Data Stream 같은 경우는 AWS 자체적인 서비스이기 때문에 다른 서비스랑 인테그리션이 잘 돼 있는데 MSK 같은 경우는 Open Source Kafka를 저희가 매니지 서비스 형태로 제공하다 보니까 아직까지는 인테그리션이 잘 안 돼 있는 서비스들이 좀 있어요.

그래서 그런 부분도 한번 같이 고민을 하셔서 어떤 부분에서 Kinesis Data Stream이 좀 더 좋을지 아니면 MSK가 좀 더 좋을지 고민하신 다음에 선택하시면 좋을 것 같습니다.

그러면 이렇게 Kinesis Data Stream이나 MSK 둘 중에 하나로 스트리밍 스토리지가 정해졌다면 거기에 따라서 스트리밍 스토리지에 데이터를 넣는 스트리밍 인제스 방식이 좀 달라지거든요.

그런데 MSK 같은 경우는 Open Source Kafka를 사용하고 있기 때문에 기존에 Open Source 진영에서 사용하고 있는 서드 파티 스트리밍 인제스 방식들을 대부분 다 사용 가능하시고요.

그래서 MSK 관련된 스트리밍 인제스 방식 같은 경우는 Open Source 쪽에 있는 서비스나 솔루션들을 한번 검토해 주면 될 것 같고 그래서 저는 여기서 Kinesis Data Stream 관련해서 조금 더 설명을 드리자면 Kinesis Data Stream에 데이터를 넣는 방식은 저희가 크게 AWS SDK를 사용하실 수가 있고 두번째는 Kinesis Agent를 사용하시면 가령 로그 파일에서 직접 데이터를 읽어서 Kinesis Data Stream을 넣으실 수가 있거든요.

아니라면 Kinesis Producer Library라는 게 있어서 이걸 사용하시면 일정한 크기로 데이터를 모아가지고 Kinesis에 배치 형태로 데이터를 넣어줄 수가 있습니다.

그 외에도 자주 사용되는 Pluntd 라든가 로그 포제 같은 그런 Open Source에서는 Kinesis랑 연동을 할 수 있는 그런 Appender나 Connector가 이미 마련되어 있기 때문에 사실상 Kinesis Data Stream이 AWS에서만 제공하는 서비스이긴 하지만 그래도 여러분들이 Open Source를 사용하시더라도 쉽게 연동을 시켜서 사용할 수 있으니까 너무 걱정하실 필요가 없을 것 같고요.

스트리밍 인젝트를 하는 방법에서 어렵지 않을까?

이런 고민을 하실 수 있는데 여러가지 방법들이 있고 Open Source랑도 잘 연동이 된다 이렇게 이해하시면 될 것 같습니다.

그 다음에 스트리밍 스토리지까지는 저희가 살펴봤는데 그렇다면 실제 데이터 싱크 쪽으로 스트리밍 스토리지에 데이터를 읽어가서 보내줄 때 그때 어떤 방식이 있을까?

만약에 프로세싱이 많이 필요하다면 스트리밍 프로세싱하는 솔루션이 있을 것 같고 그게 아니라 내가 단순히 데이터 소스에서 그냥 바로 데이터 싱크로 데이터를 바로 보내거나 아니면 데이터 스트림에서 그냥 데이터를 읽었는데 큰 가공 없이 바로 보내고 싶다 그럴 때 활용할 수 있는 서비스가 Kinesis Data Stream이 있고 Kinesis Data Stream의 데이터 싱크로는 AWS에서 주로 데이터를 저장하는데 사용하는 S3라든가 Redshift, 일렉서치 서비스 같은 게 있고 아니면 데이터를 또 가공하는데 사용하는 Kinesis Data Analytics 같은 이런 서비스로 바로 보낼 수가 있습니다.

그리고 또 한가지 이러한 Kinesis Data Files를 사용했을 때의 장점은 AWS 클라우드워치라든가 IoT 서비스 같은 거랑 연동이 잘 되거든요 그렇기 때문에 여러분들이 이러한 서비스를 이미 사용하고 있는데 이거를 S3나 Redshift 이런 쪽으로 데이터를 보내고 싶다 그렇다면 별도로 뭔가를 고민하실 필요 없이 Kinesis Files를 선택하시면 쉽게 연동이 된다는 거죠 그리고 스트리밍 스토리지 관점에서는 Kinesis Data Stream 같은 거를 활용하실 수 있고 MSK랑은 직접 연동은 안되고 중간에 카프카 커넥터 같은 거를 이용하셔서 연동을 시킬 수가 있습니다 그리고 Kinesis Data Files 같은 경우에 단순히 데이터를 데이터 소스에서 데스티네이션 쪽으로 옮기는 작업도 하는데 이게 그냥 옮기는 게 아니라 약간의 ETL 작업도 같이 해줄 수가 있거든요 그래서 스트리밍 딜리버리라고도 하긴 하지만 약간 스트리밍 프로세스 서비스라고도 저희가 보통 분류를 하게 되는데요 그게 어떤 식이냐면 Kinesis Firehose랑 Lambda를 이용해서 지금 보이시는 얘 같은 경우는 만약에 Apache 로그가 있다 그러면 첫 번째 데이터 소스 쪽에서 Apache 로그를 Kinesis Data Firehose로 보내주면 그때 Kinesis Data Firehose가 그 Apache 로그에 있는 IP 주소를 가지고 거기에 어떤 지역 정보를 추가하고 싶다고 한다면 그때 지역 정보를 제공해주는 서버와 연동을 해서 그 결과를 기존의 데이터에 추가를 시키는 거죠 그렇게 해서 필요한 데이터를 필터링해서 변경을 시켜서 데이터 소스 쪽으로 똑같이 보낼 수가 있어요 그리고 또 한 가지는 그렇게 이제 그런 Lambda를 활용하실 때 특히나 AWS의 Glue 데이터 카달로그 같은 것을 사용하시면 이제 그 JSON 형태의 데이터에다가 어떤 데이터 스키마를 부여하실 수가 있는 거죠 데이터 스키마를 부여를 하고 그거를 그 JSON 형태로 변환하는 게 아니라 그냥 데이터 포맷을 파K라든가 아니면 ORC 포맷 같은 걸로 이렇게 변경을 시켜가지고 S3로 보낼 때도 이제 Kinesis Data Files만 사용하셔도 쉽게 활용이 가능하다는 거죠 복잡한 어떤 ETL 작업을 따로 만드실 필요 없이 Kinesis Data Files랑 Lambda 같은 것만 활용하셔도 쉽게 이렇게 가능하다는 거죠 그렇다면 지금까지 이제 스트리밍 스토리지랑 스트리밍 딜리버리에서 사용할 수 있는 서비스 3가지 정도를 제가 이제 쭉 설명을 드렸는데 그러면 여기에서는 저는 실제 Kinesis Data Stream을 선택을 했고 그 다음에 Kinesis Data Stream에서 파이어스로 데이터를 보내고 그 다음 그 데이터를 S3로 저장하고 이런 형태로 수집할 수 있도록 한번 아키텍처를 생각을 해봤습니다 그리고 이제 앞서 설명 드렸듯이 만약에 아마존 퍼스널라이저를 쓰는데 실시간으로 사용자의 행동로그를 수집하고 싶다 그렇다면 Kinesis Data Stream에서 그 Lambda를 이용을 해서 데이터를 가져오고 그래서 Lambda에서 이벤트 트레이커 쪽으로 실시간으로 데이터를 보내주는 것으로 바로 퍼스널라이저 쪽으로 실시간으로 데이터를 업데이트 시킬 수가 있는 거죠 그래서 여기까지 하면 실제로 사용자의 행동로그를 수입하는 아키텍처는 만들어졌는데 그렇다면 우리가 저렇게 해가지고 추천 개선하고 이렇게 추천을 적용을 했다 그 이후에 추천 성과 분석은 어떻게 할 거냐 그때 저런 아키텍처를 어떻게 확장시킬 수 있느냐 이런 걸 생각을 해보면 아키텍처를 만들기 전에 저희가 추천 성과를 분석한 다음에 어떤 지표를 분석하는 게 좋고 어떤 방식으로 하면 좋겠는지 이걸 먼저 결정을 해야지 거기에 맞게끔 아키텍처를 만들 수가 있으니까 그걸 먼저 한번 짚어보면 실제 e-commerce에서는 체류 시간, 이탈률, 전환율 같은 것을 중요하게 생각을 하잖아요 그러니까 사용자들이 얼마나 오랫동안 있었고 처음 들어온 사용자들이 그냥 메인 페이지만 보고 바로 나가지 않고 다른 어떤 상품을 클릭했는지 이런 걸 측정하는 이탈률 같은 거 그리고 최종적으로는 그렇게 사용자들이 상품을 다 보고 구매를 얼마나 했는지 이런 것들이 중요한 지표일 텐데 그리고 저런 지표들이 추천을 도입했을 때 얼마나 효과적인지를 측정을 하셔야 될 거예요 그렇다면 추천 자체에 대한 알고리즘 지표도 평가를 하셔야 될 건데 그때 추천 자체에 대한 알고리즘 평가를 위해서는 첫 번째로는 커버리지 그 추천이 얼마나 많은 사용자나 얼마나 많은 상품에 대해서 결과를 보내줄 수 있는지를 확인하셔야 되고 두 번째로는 이제 relevance랑 serendipity라고 해서 얼마나 관련된 상품이나 그런 컨텐츠를 추천해줬는지 그 다음에 또 얼마나 사용자들의 호기심을 자극하는 그런 상품을 추천했는지 이런 것들을 측정을 해야 되는데 사실 relevance랑 serendipity 같은 거를 직접적으로 측정하기는 어려울 수가 있으니까 이런 걸 약간 간접적으로 실제 추천 클릭률 같은 거를 측정함으로써 추천 클릭률이 얼마나 높아지고 그렇게 추천 클릭률이 높아지면서 실제로 e-commerce의 주요 지표들은 어떻게 변화가 되는지 이런 부분들을 트래킹 하시는 게 좋거든요 그래서 이렇게 트래킹 할 수 있도록 어떻게 기존에 지금 사용자 행동로그로 수입하는 아키텍처를 약간 확장을 할 수 있는지 이 부분을 좀 더 살펴보면 기존에 아키텍처는 이런 모양이었다면 실제 웹서버에서 퍼스널라이지를 호출해서 추천 결과를 내보내주겠죠 그리고 사용자 행동로그는 Kinesis Data Stream하고 Kinesis Firehose를 이용해서 S3로 저장을 하고 있을 텐데 우리가 추천에 대한 성과를 분석하고 싶다면 실제 추천한 상품을 얼마나 많이 클릭을 했고 그 상품은 얼마나 많이 노출이 됐는지를 알아야지 추천 클릭률이 계산이 될 거고 또 한 가지는 그러면 그런 추천을 어느 위치에다가 저희가 노출을 시켰을 때 가장 효과가 좋은지, 보통 저희가 채널이라고 얘기하는데 그런 부분도 트래킹을 해야지 추천 성과 분석을 정확하게 더 하실 수 있을 거거든요 그래서 그런 데이터를 모아가지고 실제 이렇게 그래프로 비주얼라이전을 한 다음에 마케터라든가 아니면 데이터 사이언티스트라든가 아니면 비니스 언앨러티스트들이 활용을 하실 거예요 그렇다면 첫 번째로 고민할 부분이 그러면 저렇게 모아진 데이터를 어떻게 비주얼라이전을 하는 게 마케터라든가 BA라든가 데이터 사이언티 분들이 잘 데이터를 활용할 수 있을까?

여기에 고민이 되실 텐데 그때 저희가 사용할 수 있는 서비스가 AWS의 QuickSight라고 하는 서버리스트 형태의 BI 서비스가 있거든요 그래서 QuickSight 같은 경우는 별도의 설치나 이런 것들이 필요가 없고 마찬가지로 데이터만 넣어주시면 자동으로 분석을 해서 그 다음에 이걸 그래프로 그려줄 수가 있고 그리고 또 한 가지 중요한 거는 이제 QuickSight에는 ML 인사이트 기능이 들어가 있어서 만약에 내가 어떤 특정 클리어를 예측하고 싶다든가 아니면 몇 주 후에 상품의 판매량을 예측하고 싶다든가 아니면 그런 추이 같은 거를 예측하고 싶다 그렇다면 언뜻드는 생각이 그렇게 예측할 수 있는 모델을 만들어야 되지 않을까?

이렇게 생각하실 텐데 QuickSight 같은 경우는 그런 모델들이 이미 내장이 돼 있어서 그냥 바로 데이터만 넣어주시면 어느 정도는 사용하실 수가 있다는 거죠 그래서 이런 QuickSight를 사용하셔서 실제 데이터를 시각화하실 수가 있는데 근데 그렇다면 그 다음에 문제는 뭐냐면 저 QuickSight로 데이터를 보내줄 때 그러면 그때 모든 데이터를 그냥 보내주는 게 아니라 뭔가 가공을 하거나 아니면 데이터를 통계를 내거나 집계를 해서 보내줘야 될 텐데 그럴 때 사용할 수 있는 서비스는 어떤 게 있을까?

이런 게 고민이 되실 거예요 그래서 그런 서비스들을 크게 보면 베이치로 한 번에 계산하고 데이터를 시각화할 수 있는 방법이 하나 있을 거고 다른 방법은 대화식으로 사용자들이 필요할 때 쿼리를 날리고 그 쿼리를 그대로 비주얼라이징을 하는 방법 이렇게 크게 두 가지 방식으로 분류를 해보자면 만약에 배치 방식으로 하신다면 글로라든가 아마존 EMR 같은 거를 사용하셔서 가능하실 것 같고 만약에 대화식 형태로 한다고 한다면 SQL 쿼리 같은 게 지원이 되는 레드시프트라든가 아테나 아니면 EMR에서 프레스토어 같은 즉 오픈소스 같은 걸 설치하신 다음에 쿼리를 이용해서 데이터를 집계를 내고 가공을 해서 퀵사이트로 비주얼라이징을 해볼 수가 있는 거죠 그래서 이 네 가지 정도의 서비스를 한 번 더 살펴보면 실제로 이 네 가지 서비스를 먼저 어떤 데이터 구조의 데이터를 이 네 가지 서비스가 각각 처리할 수 있는지 그 다음에 프로그램 언어 같은 거는 어떤 걸 지원하는지 그 다음에 실제 데이터는 어디에 저장하는지 주로 사용하는 유지 케이스는 어떤 건지에 따라서 조금씩 이 서비스의 특징이 달라지는데요 대체적으로 보면 아마존 레드시프트 같은 경우는 RDSI 같은 데이터 웨어라이스기 때문에 데이터 구조 자체가 완전하게 스트럭처드 형태가 필요한데 나머지 글로라든가 프레스토나 아테나 같은 경우는 제이슨 형태의 세미 스트럭처 형태의 데이터도 어느 정도 처리가 가능합니다 그리고 지원되는 언어로 보면 모두 다 SQL 같은 언어를 사용할 수가 있고 그 다음에 이제 Glue나 Spark 같은 경우는 프레임워크에서 제공하는 API 같은 걸 사용하셔도 데이터를 가공할 수가 있죠 그리고 이제 이러한 네 가지 서비스 중에서 대부분 다 ETL 같은 작업들을 다 처리할 수가 있는데 특히나 Glue나 Spark 같은 경우는 주로 데이터를 복잡한 가공이 필요하다 여러 개의 단계를 거쳐서 데이터를 가공하고 싶다 그런 때 많이 사용을 하시고 아니면 보통 아테나나 레지시프트 같은 경우는 주로 RDS에서 SQL로 처리할 수 있는 정도의 그런 ETL 작업을 보통 필요하다 한다면 Spark나 이런 걸 사용하실 필요 없이 그냥 SQL만 가지고 사용할 수 있기

때문에 아테나나 레지시프트 같은 경우는 활용하시면 될 것 같고요 그리고 이제 여기에서 아테나나 레지시프트 같은 경우는 실제 Redshift 노드에 데이터가 저장이 되지만 아테나나 포레스나 Glue 같은 경우는 S3에 데이터가 저장돼 있고 S3에 데이터를 읽어와서 실제 가공하는 거는 다른 노드에서 진행이 되기 때문에 실제 스토리지랑 컴퓨팅이 분리되어 있다고 생각하시면 돼요 그래서 지금 저희 같은 경우에는 1차적으로 사용자의 행동 노드를 S3라고 하는 스토리지에 저장을 하고 있기 때문에 이걸 다시 Redshift 쪽으로 데이터를 똑같이 넣은 다음에 분석하거나 할 필요 없이 만약에 컴퓨팅만 할 수 있는 엔진만 붙여놓으면 뭔가 분석을 할 수 있으면 조금 더 유리하기 때문에 여기서는 아테나를 사용해서 그리고 아테나가 어떤 서버 관리나 이런 것들이 필요 없이 서버리스트 형태로 제공이 되고 있기 때문에 아테나를 사용해서 분석을 하고 그 결과를 퀵사이트에서 확인하는 이런 형태로 구성을 해볼 수가 있거든요 근데 이제 여기까지 하면 아테나를 사용하면 분석을 할 수가 있는데 근데 아테나 같은 걸 사용하게 되면 데이터가 만약에 실시간으로 분석을 하고 싶다

그렇게 한다면 조금 아테나를 그렇게도 쓸 수는 있겠지만 이게 잘 쓰는 방식은 아니거든요 아테나 같은 경우는 대용량의 데이터를 처리할 때 유리한 도구지 특히나 S3 같은 경우는 약간 콜드 데이터 아니면 웜 데이터 같은 데이터를 저장하는 용도로 쓰는 스토리지이기 때문에 이게 실시간으로 핫 데이터 같은 거를 분석하고 처리하고자 한다면 사실은 S3보다는 다른 스토리지를 선택하는 게 더 유리할 수가 있죠 그래서 그렇다면 만약에 실시간으로 데이터 분석을 하고 싶다면 이 구조에서 어떻게 확장을 할 수 있을까 또 이제 이런 고민이 드실 수가 있을 거예요

왜냐하면 내가 추천을 한번 추천 서비스를 적용하기 위해서 알고리즘이 바뀌어 가지고 적용을 했는데 그러면 이게 바로 지금 적용이 됐으니까 지금 실시간으로 그 효과를 좀 측정을 하고 싶다 이런 니지가 클 거거든요 그래서 그런 경우에 저희가 확장할 수 있는 방법이 크게 이제 세 가지 방식이 있는데 첫 번째로는 데이터가 이런 스트리밍 스토리 형태로 실시간으로 계속 스트리밍 방식으로 계속 들어오고 그렇다면 그 데이터를 일단 가공을 해가지고 가공을 한다는 게 데이터를 뭔가 클린징하는 작업도 있겠지만 실시간으로 들어온 데이터를 실시간으로 집계가 필요한 거죠 그래서 그런 집계한 데이터를 어떠한 저장소로 이렇게 저장을 해 놓고 그거를 다시 비주얼라이징 하는 방식 이런 식으로 이렇게 처리해 볼 수가 있는데요 그래서 첫 번째 방식, 1번 방식이 이제 EMR의 Spark이나 Flink와 같은 이렇게 스트리밍 데이터를 처리할 수 있는 Open Source 프레임워크 같은 것을 사용을 하셔가지고 Kinesis Data Stream에서 데이터를 읽어서 그 결과를 RDS라든가 아니면 DynamoDB 아니면 Elastic Cache 같은 데에 데이터를 넣고 실제로 QuickSight나 아니면 커스텀하게 여러분들이 데시보드를 만드셔서 실제로 보여주는 이런 형태로 구성을 해 볼 수가 있죠 그 다음에 두 번째 방식으로는 EMR 같은 걸 활용하시면 EMR에다가 저런 것을 설치를 하신 다음에 쓰셔야 되니까 약간 관리 부담이 있을 텐데 그런데 우리는 관리 운영 효율성을 좀 높이고 싶다 그래서 관리를 하지 않고 약간 서버리스 형태로 실시간으로 직결을 해주거나 ETL을 해줄 수 있는 서비스가 없을까?

그런 걸 고민하신다면 두 번째에 Kinesis Data Analytics라는 서비스를 활용하시면 돼요 그래서 이 서비스 같은 경우는 저희가 서버리스 형태로 제공을 해드리고 그래서 그렇게 실시간으로 직결한 데이터를 다시 Kinesis Data Stream이나 이런 쪽으로 보내준 다음에 아니면 Kinesis Data Files로 보내준 다음에 그 데이터를 이제 RDS나 DynamoDB 아니면 Elastic Cache 쪽으로 이렇게 저장을 해서 비주얼라이저를 하는 거죠 그 다음에 세 번째 방식으로는 우리는 데이터를 이렇게 실시간으로 직결한 결과를 어딘가에 저장해서 쓰는 것보다 일단 실시간으로 그 데이터를 어딘가에 바로 직결을 하고 또 실시간으로 데이터를 그냥 우리가 AdWord하게 퀄이를 날리고 싶다 이런 경우에 쓰실 수 있는 게 이제 일렉서치 같은 것을 저희가 활용해 볼 수가 있는데요 그래서 일렉서치로 데이터를 넣기 위해서 Kinesis Data Stream에서 Kinesis Files를 사용하셔서 데이터를 읽어오신 다음에 그걸 일렉서치에 넣어주시면 일렉서치에서는 또 내장되어 있는 Kibana로 하는 데이터 시각화 도구가 있기 때문에 거기에서 바로 여러분들이 그래프를 그려볼 수가 있고 그 다음에 필요하시면 AdWord하게 퀄이를 쓰면 하셔서 결과를 또 보실 수가 있는 거죠 그래서 이렇게 세 가지를 크게 간단하게 설명을 드렸는데 조금 더 디테일하게 설명을 드리자면 1번하고 2번을 먼저 설명을 드리면 EMR 같은 경우는 저희가 오픈소스인 Spark이랑 Plink가 있는데 이 Spark이랑 Plink를 저희가 메이드 서비스 그리고 서버리스 형태로 변환을 한 게 Spark 같은 경우는 Glue가 있다고 생각하시면 되고 Plink는 Amazon Kinesis Data Analytics for Plink라고 하는 서비스가 있습니다 그리고 만약에 이거 두개를 EC2라든가 이런 데 설치해 가지고 사용하시겠다 그렇다면 EMR 같은 거로 활용하시면 되고요 그래서 사실상 저희가 EMR이라고 하는 서비스는 여러분들에게 그러한 빅데이터를 처리하는 프레임업들, Spark이나 Hive나 Plink나 Presto 같은 이런 서비스들을 프로비전하고 운용하는 부담을 줄여들기 위해서 만들어준 서비스라고 생각하시면 됩니다 그래서 그리고 이런 EMR보다 EMR을 사용하실 때는 프로비전이나 관리 부담이 조금 줄긴 하지만 여전히 관리를 하셔야 될 텐데 그거 말고 그냥 그런 노드 관리 같은 거 저절로 필요 없이 그냥 바로 쓰고 싶다 그런 때는 Kinesis Data Analytics를 사용하시면 되는데요 Kinesis Data Analytics 같은 경우는 크게 두 가지 서비스로 제공해드리고 있거든요 하나는 오픈소스 아파치 Plink를 저희가 서버리스로 제공하고 있는 Kinesis Data Analytics Plink가 있고 다른 거 하나는 Plink 같은 경우는 프로그램을 작성을 해서 ETL 작업이라든가 어그리게이션 같은 그런 통계 작업을 해야 되는데 그게 아니라 SQL Query로 바로 하고 싶다 그런 니즈가 있는 분들한테 제공해드린 게 Kinesis Data Analytics for SQL 이라는 게 있습니다 그래서 Kinesis Data Analytics for SQL 같은 경우는 일제 어떤 스트리밍 스토리지에서 데이터가 이렇게 들어오면 그 데이터를 만약에 지금 예제 같은 경우는 내가 10초 간격으로 20초 간격으로 데이터를 집계를 하고 싶다 그러면 이런 형태로 여러분들이 상당히 친숙한 그런 SQL 형태의 언어를 써가지고 계산을 하고 그 결과를 다른 데이터 싱크 쪽으로 보낼 수가 있다는 거죠 그래서 이 다른 데이터 싱크는 Kinesis Data Stream이라든가 Kinesis Firehose 같은 게 될 수가 있고요 그래서 이런 식의 서비스를 쓸 수가 있고 마지막으로 일렉서치 서비스를 활용하신다면 일렉서치 서비스 같은 경우는 워낙에 오픈소스로 유명하고 특히나 검색 쪽에서도 많이 활용을 하시니까 익숙하신 분들이 많을 텐데 그런데 만약에 이거를 EC2에다가 설치를 하시거나 이런 경우라면 여러분들이 고민하셔야 될 부분들이 보안은 어떻게 할 거냐, 그 다음에 또한 모니터링을 하기 위해서는 어떠한 도구들을 설치할 거냐, 그리고 저것들을 이제 노드를 추가한다든가 이렇게 했을 때 아니면 또 데이터를 백업할 때 어떻게 관리할 거냐, 이런 운영 부담이라든가 보안 부분에서 상당히 어려움이 있을 텐데 이런 부분들을 저희가 약간 메인 서비스 형태로 제공을 해드림으로써 보안이라든가 그 다음에 모니터링이라든가 운영의 효율성을 높여줄 수 있게끔 제공해드리는 게 아마존 일렉서치 서비스이고 실제 오픈소스랑 거의 동일하다고 생각하시면 됩니다 그래서 다시 한번 정리해보면 크게 세 가지 방식 EMR을 쓰거나 Kinesis Data Analytics를 쓰거나 일렉서치 서비스를 쓰거나 이렇게 세 가지 방식으로 실시간으로 스트리밍 형태로 들어오는 데이터를 분석하실 수가 있고 저는 여기서는 약간 1번하고 2번 같은 경우는 또 별도의 스토리지를 사용을 해야 되고 또 한 번 이렇게 ETL 과정을 거치는 저런 작업들이 있기 때문에 그것보다는 그냥 바로 애독하게 쿼리도 할 수 있고

그리고 실제로 크게 지금 다른 여러 가지 서비스를 써 쓸 필요 없이 그냥 하나만 쓰면 해결이 가능한 일렉서치 서비스를 선택을 해서 한번 구성을 해봤고요 그래서 이 상태에서 Kinesis Data Stream에서 파이오스 쪽으로 데이터를 보내고 그렇다면 파이오스에서 다시 ES로 데이터를 적질하고 Kibana를 통해서 실시간으로 데이터 시각화를 해가지고 분석을 할 수 있는 이런 구조로 만들어질 수가 있는 거죠 그래서 데이터 분석 시스템 관점에서 본다면 실제 웹서버에서 들어오는 데이터를 Kinesis Data Stream을 이용을 해가지고 위쪽에는 Athena를 이용해가지고 약간 배치 형태로 데이터를 분석하고 아래쪽 라인에서는 아마존 일렉서치 서비스를 이용을 해가지고 실시간으로 데이터를 분석하고 이런 형태로 구성을 해 볼 수가 있고요 그래서 저희가 이때 데이터 스토리지로 S3 같은 걸 사용했는데 이때 저희가 사용한 S3를 일종의 데이터 레이크라고 생각해 볼 수가 있거든요 그리고 이렇게 데이터 레이크로 구성할 때 S3를 사용함으로써 또 상당한 장점이 있어요.

그래서 그거에 대해서 잠깐 설명을 드리자면 저희가 이제 S3를 데이터 레이크로 썼다.

그렇다면 좋은 점이 기존의 오픈소스로 나와 있는 빅데이터 플레이먹들 즉, 스파크라든가 하이브라든가 프로세서 같은 이런 다양한 빅데이터 플레이먹들을 이 뒷부분 다 S3를 스토리지 엔진으로 사용할 수 있게 잘 연동이 되어 있고 또 한 가지는 Athena를 설명을 드릴 때 얘기했던 것처럼 실제 스토리지랑 쿼리를 실행하는 컴퓨팅 로드가 분리를 시킬 수가 있거든요.

그렇다보면 실제로 저희가 만약에 퍼포먼스 때문에 성능 때문에 튜닝을 한다든가 아니면 비용을 줄이기 위해서 어떤 서버를 줄여야 된다든가 이렇게 했을 때 상당히 유리해진다는 거죠.

만약에 스토리지랑 컴퓨팅 로드가 동일하다고 치다면 성능이 낮아도 되기 때문에 컴퓨팅 로드들을 줄이고 싶은데도 스토리지 공간이 필요하기 때문에 컴퓨팅 로드를 줄이지 못하고 그대로 위치를 해야 되는 상황이 벌어지거든요.

하지만 S3 같은 것을 스토리지로 활용을 하고 컴퓨팅 로드는 별도로 분리를 함으로써 상황에 따라서 컴퓨팅 로드는 좀 더 자유롭게 가져갈 수 있다는 거죠.

그 다음에 S3는 9-11수라고 할 만큼 저희가 이렇게 한 번 들어간 오브젝트는 거의 장애가 나서 삭제되는 경우가 거의 없다.

이런 식으로 저희가 고가용성을 많이 얘기해 드리잖아요.

그렇기 때문에 데이터를 안전하게 저장할 수 있다.

이런 게 가장 큰 장점이고 그리고 상당히 싸다는 게 큰 매력이죠.

어마어마하게 많은 데이터를 저장하더라도 되게 적은 비용으로 활용을 하실 수가 있다는 거죠.

RDS랑 아마 비교를 해보시면 바로 여러분들이 체감하실 수 있는 건데요.

그래서 이러한 S3를 저희가 데이터레이크로 활용을 했고 그 다음에 저 데이터레이크로 데이터를 넣어주기 위해서 스트리밍 스토리지로는 Kinesis Data Stream, 스트리밍 딜리버리로는 Kinesis Firehose 이런 형태로 구성을 해봤고 그 다음에 실제 데이터를 분석하는 부분에 있어서는 데이터레이크인 S3에서 아테나를 이용해서 배치 처리 형태로 데이터를 분석하는 배치 레이어가 있고 그 다음에 그거를 실제 사용자한테 보여주는 서빙 레이어인 QuickSight를 활용을 했었고 그 다음에 위에 라인은 배치 레이어랑 서빙 레이어 같은 경우는 수초 이내 아니면 수분 이내의 데이터를 분석하고 싶을 때는 이런 방식이 어렵지만 저희가 일렉서치 서비스를 도입을 해서 수초 이내 아니면 수분 이내의 데이터도 시각화라고 분석할 수 있도록 스피드 레이어라고 따로 만들었거든요.

그래서 전체적인 데이터 분석 시스템이 배치 레이어랑 스피드 레이어 그 다음에 서빙 레이어 이렇게 세 가지로 구성을 시켰는데 저희가 보통 이러한 아키텍처를 보고 이제 Lambda 아키텍처라고 보통 얘기를 하고 이러한 Lambda 아키텍처의 장점이라고 생각하신다면 배치 레이어랑 스피드 레이어가 구분이 되어 있기 때문에 어느 한쪽이 장애가 나더라도 다른 한쪽에는 크게 영향을 안 준다는 거죠.

예를 들어서 만약에 스피드 레이어 쪽에서 문제가 생겼더라도 실제 시간 단위로 통계를 낸다든가 이런 쪽에는 전혀 영향을 줄 필요가 없는 거죠.

물론 이런 장점이 있긴 하지만 한 가지 단점은 사실상 배치 레이어랑 스피드 레이어 쪽에서 하는 작업이 상당히 유사하기 때문에 코드리베이션에서 보다면 약간 중복된 코드 같은 것들이 있을 수 있긴 한데 그렇지만은 문형 효율성 관점에서 본다면 두 개의 레이어가 날아져 있어가지고 서로 영향을 안 주고 그래서 장애가 동시에 발생할 확률은 낮고 그리고 실제 배포 같은 경우도 따로따로 할 수가 있는 이런 장점이 있어서 이러한 데이터 분석 아키텍처에서는 상당히 많이 사용되는 그런 아키텍처 모델이라고 생각하시면 될 것 같습니다.

지금까지 실제 추천하고 데이터 분석 시스템을 설명을 드렸고 이거를 두 개를 합쳐서 그려보면 지금 이런 모양이 될 거예요.

그래서 웹서버에서 들어온 데이터를 Kerasis 데이터 스팀으로 받아가지고 한쪽은 추천 시스템에 사용할 수 있도록 데이터를 보내주고 또 다른 한쪽은 데이터 분석을 위해서 S3 쪽으로 보내준다든가 일렉서치 서비스 쪽으로 보내준다든가 이런 형태로 구성을 하실 수가 있고 그래서 하나씩 또 살펴보면 위쪽의 영역은 추천 시스템을 사용하는 영역이고 아래쪽은 분석 시스템을 사용하는 영역인데 저희가 이 두 개의 영역을 합칠 수 있었던 이유가 Kerasis 데이터 스팀이라는 것과 S3라는 걸 써가지고 합칠 수 있었거든요.

그래서 좀 더 일반화해서 얘기를 한다면 스트리밍 스토리지라는 그런 솔루션을 사용을 해가지고 그 데이터를 받아온 다음에 그 데이터를 스트리밍 스토리지에 넣었기 때문에 실제 용도가 다른 시스템 쪽으로 데이터를 서로 나눠서 보내줄 수 있었던 거죠.

한쪽은 추천을 위한 퍼스널라이즈 쪽으로 데이터를 보내줄 수가 있었고 또 다른 쪽은 동일한 데이터를 분석 쪽으로 데이터를 보낼 수가 있는 그런 장점이 있었고 또 한 가지는 이러한 데이터 양이 많은데 그것들을 다 모두 저장할 수 있는 데이터 레이크를 구성하기 위해서 S3 같은 것을 활용을 함으로써 데이터 자체를 안전하게 보관을 하고 분석이라든가 추천에 쉽게 활용할 수 있는 형태로 이렇게 구성을 할 수 있었던 거죠.

그리고 이러한 아키텍처를 만들어가는 과정에서 저희가 처음에는 배치 형태의 데이터 분석을 할 수 있는 구조에서 실시간까지 처리할 수 있는 형태의 아키텍처인 Lambda 아키텍처로 발전을 시켰는데요.

그 과정을 한 번 더 정리를 해보자면 기존에 배치 형태의 분석 시스템이라면 데이터 자체가 있고 그 데이터를 한 번에 배치 처리를 할 수 있는 스토리지에 한번 임포트를 시키고 그 다음에 배치 프로세싱을 처리한 다음에 거기에서 나온 결과를 실제 소비할 수 있도록 활동을 만들어주는 서비스 레이어 이렇게 구성이 되어 있을 텐데요.

근데 만약에 데이터 자체가 스트리밍 형태로 계속 지속적으로 발생이 돼서 들어오고 있다.

그렇다면 실제 배치 레이어 쪽으로 한 번에 보내는 게 아니라 스트리밍 스토리지 같은 것을 이용해서 거기에서 일정하게 모은 다음에 그 데이터를 모으기 위해서 스트리밍 인제스천을 사용해서 스트리밍 스토리지에 일정한 크기대로 모아서 그 데이터를 스트리밍 딜리버리 같은 것을 활용해서 배치 레이어 쪽으로 보내주고 그런데 저희가 실시간으로 데이터 분석을 해야 되기 때문에 스트리밍 스토리지에서 실시간으로 데이터를 읽어서 그걸 가공을 해서 어딘가에 저장할 수 있는 그런 형태의 스트리밍 프로세스 서비스를 도입을 해서 스피디 레이어 같은 것을 만들어낼 수가 있는 거죠.

그래서 이렇게 처음에는 배치만 처리됐다가 이런 식의 서비스들이나 컴포넌트를 추가함으로써 실시간까지 처리할 수 있는 남자 아키텍처로 발전을 시켜왔던 거죠.

그리고 전체적으로 이런 데이터 파이프라인이라든가 이런 데이터 처리 시스템을 구성할 때 저희가 사용했던 AWS 서비스를 한눈으로 확인해보면 처음에 데이터를 수집할 때는 스트리밍 스토리지 형태로는 Kinesis Data Stream이랑 MSK를 제가 얘기 드렸고 스트리밍 스토리지에서 데이터를 가져와서 다른 쪽으로 보내주는 또는 약간의 가공을 하는 그런 서비스로는 Kinesis Data Files 그리고 데이터를 저장할 때는 데이터 레이크 역할을 하는 S3 그리고 데이터를 가공하거나 통계를 내거나 이럴 때는 람더부터 해서 일렉서치 서비스까지 이렇게 다양한 서비스가 있었고 마지막으로 저희가 데이터를 소비를 할 때는 데이터를 시각화하거나 아니면 분석을 할 때는 다시 한 번 말씀드리면 AWS는 시스템을 사용하셨고 또 한 가지 추천과 같은 실제 데이터 자체를 활용하고 싶겠다 그렇다면 아마존에서 제공하는 머신러닝 서비스들 여러가지 서비스들을 다 활용하실 수 있는 거죠 오늘 설명드렸던 퍼스널라이지드 같은 것도 있고 또 다른 거는 이후에 설명드릴 컴프리엔드라던가 프로듀스 디렉터 같은 것도 있고 아니면 세이지메이트 같은 것을 활용하셔서 머신러닝 모델을 직접 개발할 수 있는 거고요 지금까지 여러가지 아키텍처를 보고 어떻게 확장했는지 봤는데 여러분들한테 마지막으로 정리해서 얘기를 드리자면 이렇게 저희가 데이터 분석 시스템을 만든다고 한다면 한 번에 모든 것을 처리하도록 모노레이싱 형태로 만들기보다는 데이터의 분석 과정이 데이터를 수집하고 그 다음에 그거를 가공을 하고 다시 저장을 한 다음에 그걸 다시 분석을 하고 결과를 내는 이런 형태의 단계들이 나오는데 이 각각의 단계를 분리를 한 다음에 가장 최적화된 솔루션을 사용해서 처리를 할수록 시스템 자체가 유연하고 그 다음에 이런 레이터시라던가 스루프 같은 것을 향상시킬 수 있는 거죠 그 다음에 또 한 가지는 제가 이제 아테나를 쓸지 레드시프트를 쓸지 EMR을 쓸지 뭐 이런 것들을 얘기할 때 항상 얘기 드렸던 게 이게 운영 관점에서 어떤 게 조금 더 편하냐 그리고 여러분들의 손이 덜 가냐 이런 얘기를 계속 얘기 드렸는데 결국에는 처음에는 만들기는 쉽지만 이것들을 한번 만들고 그냥 내버려 두는 게 아니라 계속 운영을 해야 되기 때문에 이후에는 운영 부담이 커지거든요 그래서 운영이 효율적이고 그 다음에 보안 관점에서도 뛰어난 그런 서비스들을 가급적 선택하시는 게 좋고 그러려면 웬만하시면 매니지드라던가 서버리스 서비스를 선택하시는 게 훨씬 더 효율적이지 않을까 이런 생각이 많이 들고요.

네 번째로는 데이터를 처리하실 때는 데이터 레이크 같은 것을 구성하셔서 처리를 하실 텐데 이런 데이터 레이크 같은 것을 구성하실 때는 항상 유념하셔야 될 부분이 RDS처럼 그냥 그 인플레이스로 그 레코드를 그 자리에서 업데이트를 시키는 것보다는 그 레코드가 변경된 내용만 그대로 똑같이 데이터 레이크라던가 이런 데 저장을 하시고 실제 데이터를 읽어가는 시점에 변경된 내용까지 합쳐가지고 처리하는 이런 형태로 즉 이뮤트어블 로그 형태로 이런 데이터를 처리하도록 디자인하는 게 이후에 확장성이라던가 대용량의 데이터 처리할 때는 유리하시거든요 만약에 인플레이스 형태로 데이터를 가공하고 뭔가 하겠다고 한다면 사실상 RDS 같은 형태의 서비스가 필요한데 그런 RDS 같은 서비스 같은 경우에는 이제 많은 양의 데이터를 처리하기에는 조금 어려운 점이 발생하게 되겠죠 그리고 지금까지 설명드렸던 이런 서비스들이 어떤 서비스는 약간 비용이 많이 나오기도 하고 어떤 서비스는 비용이 적게 나오기도 하는데 이것이 무조건 데이터 양이 많아서 비용이 많이 발생하는 게 아니라 저희가 처음에 데이터 파이프라인을 구성하실 때 레이턴시가 어떻게 되고 그 다음에 스트로프시가 어떻게 되는가에 따라서 실제 거기를 구성하는 각각의 파이프라인을 구성하는 서비스들이 달라지고 그러면 그 서비스들의 가격이 결국 최종적으로 달라지기 때문에 그 가격이 달라지는 거지 실제 데이터의 양하고는 관련이 그렇게 크지는 않거든요 그렇기 때문에 데이터가 많다고 비용이 많을 거다고 이렇게 생각하시지 말고 실제 워크로드의 특성이라든가 그 다음에 어떤 식의 요구사항이 있는지 이거에 따라서 적절한 서비스로 선택하시면 상당히 합리적인 비용으로 좋은 성능을 내는 그런 시스템을 만들 수 있다는 점 꼭 기억을 해주시기 바랍니다 그리고 마지막으로 드리고 싶은 말씀은 보통 제가 이렇게 설명을 드릴 때 데이터 가공 프로세스를 데이터를 저장하고 그 다음에 그걸 처리하고 다시 또 저장하고 분석하고 이렇게 설명을 드리면 이렇게 처음 어떤 일의 순서대로 시스템을 설계하시려고 하시는데 그렇게 설계를 하시는 것보다는 최종적으로 그 데이터를 어떻게 활용했으면 좋겠느냐 아니면 이 시스템의 목적이 뭐냐 이러한 목적을 먼저 생각을 하시고 그 다음에 거꾸로 그 목적에 가장 맞는 선택지를 하나씩 거꾸로 선택하는 방식으로 하시는 게 좋거든요.

그런데 데이터 처리만 보자면 사실은 뒤에 어떤 그 목적으로 사용하든지 상관없이 데이터 처리를 그냥 무조건 빨리 하고 싶다면 가장 빨리 처리되는 그런 서비스를 선택할 수도 있겠지만 그렇게 선택을 했을 때 최종적으로 사용하실 때 보면 그게 안 맞는 경우가 되게 많거든요 그렇기 때문에 실제 설계를 하실 때 뭔가 데이터가 처리되는 순서대로 솔루션을 선택하기보다는 최종적인 목적, 어떤 식으로 데이터를 활용할 건지 생각해 보시고 맨 뒤쪽에서부터 이렇게 서비스를 선택하시는 것을 권장을 드립니다.

그래서 지금까지 추천 서비스를 위해서 데이터 분석 서비스를 어떻게 만들 수가 있는지를 설명을 드렸는데 저희가 이제 e-commerce 입장에서 생각을 해본다면 어떤 사용자 데이터가 있고 그런 사용자 데이터를 저희가 e-commerce 자체를 이런 큰 과일나무로 생각한다면 여러분들은 사실 이 과일나무를 잘 키워가지고 이렇게 리텐션이라든가 첫 레잇이라든가 아니면 컨버전 레잇 같은 경우를 이런 식으로 이렇게 잘 키운 과일을 따시려고 하실 거예요.

그때 저희가 활용하실 때 이런 데이터들을 과일나무 데이터라고 하는 이런 비료라든가 이런 것들이 잘 과일이 흡수할 수 있도록 이런 데이터 파이프라인을 잘 구성을 해주고 그 다음에 여기에 퍼스널라이저 같은 추천 서비스를 잘 활용을 하셔가지고 그냥 데이터를 활용하시는 것보다 훨씬 더 좋은 그런 비즈니스적인 성과를 낼 수 있도록 이렇게 구성을 하실 수가 있습니다.

여기까지 추천 시스템이나 데이터 분석 시스템 구축에 대해서 설명을 드렸습니다.

감사합니다.