Data_Engineering_TIL_(20190402)

study program : https://www.fastcampus.co.kr/extension_des

[학습목표]

• AWS 서비스 인터넷용 스토리지 서비스 S3 이해

• 대규모 데이터 레코드 스트림을 실시간으로 수집하고 처리하는 Kinesis Stream 실습

• AWS 패키지들을 이용한 데이터 수집 실습

[학습기록]

• 데이터 파이프라인 관련 기초용어 정리

1) ETL

데이터웨어하우스 구축 시 각종 소스에서 원본데이터를 Extraction(추출)하여, 데이터 사이언티스트가 분석을 원활하게 할 수 있도록 데이터 형식을 Transformation(가공 또는 변환)하여 데이터 웨어하우스에 Loading(적재)하는 일련의 과정을 말한다.

일반적으로 데이터 변환이라고 하면 데이터 필터링, 정렬, 집계, 데이터 간 join, 중복제거 등의 작업을 포함한다.

2) 데이터 마트

파편화된 데이터를 데이터사이언티스트가 분석을 용이하게 할 수 있도록 구조화한 테이터 집단을 말한다.

데이터 웨어하우스가 데이터 팀이라는 커다란 관점에서 관리하는 데이터 집단이라고 하면 데이터 마트는 마케팅팀, 인사팀같은 이런 조직이나 특정 주제를 기반으로 조직된 의사 결정용 데이터의 집단이라고 할 수 있다. 데이터 마트는 주로 조직의 특정 조직의 특정 업무 분야에 촛점을 맞추어 구성된다. 그러므로 조직의 데이터 마트를 통합하면 이를 데이터 웨어하우스로 볼 수 있다.

3) 데이터 하우스와 데이터 레이크의 차이점

데이터 웨어하우스 - 데이터 레이크에서 가공한 정형데이터를 다룸

데이터 레이크 - 비정형데이터까지 전부 다룸

• 람다 아키텍처를 잘 이해하고 있어야 한다. 람다 아키텍처를 이해하고 있으면 바뀐 기술들을 그 레이어에 끼워서 맞추면 전체적인 플로우를 그대로 가져갈 수 있다.

• 최근에 스트리밍을 중심으로한 새로운 아키텍처가 나오기는 했지만 그것은 데이터 처리하는 것을 리얼타임으로 하다보니까 데이터 손실위험이 있다. 데이터 스트림을 할때 스트림처리한 데이터를 쌓고 그 쌓은 데이터를 처리하는 방식이다. 이런방식을 카파방식 또는 카파 아키텍처라고 한다. 이런 처리 방식을 데이터 람다 아키텍처라고 이해해도 무방하다.

• 람다 language를 하려면 우리가 알아야할 것이 너무나도 많기 때문에 어떤 클라우드 서비스를 쓰던간에 람다 아키텍처와 동일한 기능의 서비스가 있다면 람다로 프로그래밍을 해서 데이터를 처리하기 보다는 그 동일한 서비스를 사용하는게 훨씬 편하고 좋다.

• 람다 프로그램으로 하면 프로그램 자체에 오류가 있을수도 있고, 프로그램이 종료되는 순간 데이터도 같이 다 날아가기 때문에 별로 좋은 방법은 아니다.

• 람다는 이벤트가 발생하면 그때 깨어나서 특정작업을 하는 것이다. 예를들어서 어떤 휴대폰 어플리케이션이 있으면 사용자가 어떤 버튼을 누르는 순간 이벤트가 발생하는 것인데 이 람다가 API게이트웨이를 바라보고 있다가 이벤트가 발생하면 깨어나서 API에 들어온 데이터를 끌어다가 프로그래밍 된 로직으로 처리가 되서 디비에 넣는 방식이다.

• 키네시스의 스르림, 파이어홀스, API 게이트웨이, 람다를 이용해서 S3에 저장하는 것을 데이터 수집을 하는 부분이라고 할 수 있다. 데이터가 수집되는 형태는 다양하다. 휴대폰 어플리케이션에서 나오는 데이터도 있고, 사물인터넷의 센서에서 나오는 데이터도 있고, 협력업체에서 발생시켜서 보내주는 데이터도 있다. 다양하다. 데이터 수집 부분은 데이터 lake를 구성하기 위한 방법이라고 이해할 수 있다.

• 과거에는 API 게이트웨어로 들어온 데이터를 람다에서 받아서 DB에다 저장을 했다. 람다 function을 이용하기 위해 프로그램을 짜야했다. 그래서 데이터가 들어오면 람다 function을 이용한 데이터 처리 프로그램을 통해서 이것을 json으로 만들어서 키네시스에다 parsing하거나 DB에 저장하거나 그런 작업을 했다. 과거에 이렇게 처리를 했는데 문제가 많기 때문에 최근에는 그것들을 도와주는 서비스나 툴이 많이 있고 우리는 그것들을 유용하게 이용하면 된다.

• 데이터 수집자체를 프로그램적으로 하려고 하면 안된다. 왜냐하면 카프카 같은 툴이 괜히 나온것이 아니기 때문이다. 과거에는 데몬프로그램을 짜서 데이터를 수집해서 큐에 담았다가 DB에 저장하고 그런시절이 있었다. 그런데 그때 문제는 그 데몬프로그램이 죽어버리면 데이터가 전부 손실되는 문제가 발생한다. 데몬프로그램이 말이 쉬워서 데몬프로그램이지 이 데몬프로그램은 항상 백그라운드에서 실행되서 돌아가는 프로그램인데 실질적으로 실행해보지 않으면 모르는 일이다. 예를 들어 프로그램을 구현할때는 몰랐는데 실제로 데몬프로그램을 돌려보니 메모리가 부족해서 터져버리는 경우도 있고 여러가지 이슈들이 많이 발생한다. 따라서 프로그램적으로 이 수집자체를 시도하는 것은 매우 어려운 것이기 때문에 그런 기능을 하는 서비스가 있으면 그것을 이용하는 것이 훨씬 좋다.

• 데이터 엔지니어링에서 가장 중요한 부분은 데이터 전처리다.(데이터 사이언티스트에게도 마찬가지이다. 데이터를 분석한다면 가장 많은 시간을 할당하는 부분이다. 또한 우리가 배우는 대부분의 내용은 결국에는 데이터 전처리에 관련된 내용이라고 할 수 있을정도로 데이터 전처리 세션은 중요하다.) 기존의 방식은 DBMS 또는 RDS에 데이터를 전부 저장하는 형태였다. 그래서 과거에는 RDBMS를 정말 큰 것을 썼다. 거기에 그 특정서비스의 정말 모든 메세지가 다 들어갔기 때문이다.

• 스쿱(Sqoop)이라는 툴은 RDBMS에 있는 데이터를 온프로미스의 경우에는 하둡에 내려주고, S3에 내릴때는 얘가 병렬작업을 해서 데이터를 모아서 파일을 보내주게 된다. 프로그램에서는 하루종일 백날 삽질할 일을 빠르게 처리할 수 있다. 이렇게 스쿱을 통해 S3로 데이터를 내려주면 스파크를 이용해서 그 내려진 데이터를 분석했다.

• 결국에는 S3에 데이터를 다 쌓아야 한다. 데이터를 S3에 쌓으면 분석툴을 이용해서 다 분석할 수 있다.

• 스파크가 정말 기능이 좋다. 모든 채널에 있는 RDBMS와 연결이 가능하다. 그렇다고 그 채널들을 전부 댕겨서하면 현재 돌고있는 RDBMS에 부하를 많이 줄 수 있다. 그래서 가능하면 s3에 다 떨군다음에 그 떨군데이터를 가지고 데이터를 처리하는 것이 좋다.

• 데이터 마트는 각 부서에서 그 팀들이 보고싶어하는 데시보드와 1대1 매핑한 테이블이라고 생각하면 된다. S3에 있는 데이터를 처리해서 의미있는 값들로 구성된 집합들을 넣어놓은 것이다. 그렇게 하기 위해서는 일단 S3에 저장을 해놓는데 그 데이터를 하둡에 있는 하이브 테이블 구성으로 즉 정형데이터 형태로 저장을 해놓으면 그 데이터를 아테나나 red shift의 스펙트럼을 이용해서 S3에 있는 데이터를 같이 조회를 해서 읽을 수 있다. 그래서 그 데이터를 읽어서 타블로를 쓰던 제플린, 수퍼셋 등을 쓰던지해서 시각화 및 분석을 할 수 있다.

• 우리가 이렇게 데이터 파이프라인을 잘 구성하면 어느정도 정제된 데이터를 쌓아놓고 볼 수 있기 때문에 데이터 분석의 업무 효율이 증대될 수 밖에 없다.

• 데이터 전처리 한다는 것이 결측값제거, 중복데이터 처리 등 여러가지 의미가 있지만 엔지니어링 관점에서는 추후 시스템에 문제가 생겼을 시 수 많은 데이터를 다시 처리해야할 경우가 생기면 데이터 처리를 위한 cost를 줄이기 위한 목적도 있다.

• 로우데이터라고 하는 것은 건들지 않고 그냥 쌓여있는 데이터를 말한다. 그러면 그 데이터를 한번 전처리를 해서 영역별로 나누어서 예를 들어서 어떤 앱서비스가 있다고 하면 신규사용자의 데이터면 그런 데이터와 DAU(Daily Active User : 일간이용자)를 조인해서 처리하면 된다.

• 데이터 수집은 배치잡으로 처리를 하는 것인지 실시간으로 처리하는 것인지 궁금할 수 있다. 예를 들어서 서버에 있는 로그 정보를 수집한다고하면 기존에 서버에 쌓인 데이터를 읽는 방식인지 궁금할 수 있다. 만약에 AWS EC2 서버가 있다고 치면 키네시스 에이전트라는 것이 있는데 서버의 로그 데이터가 쌓여있는 폴더를 바라보고 있다면 그 키네시스 에이전트는 어느정도 데이터양까지 주고 받았는지 항상 체크하고 있다가 서버에 데이터가 쌓이게 되면 그 데이터들을 버퍼링에다 버퍼링을해서 키네시스로 쏴주게 된다. 다시말해 서버에 쌓여있는 데이터를 읽어와서 저장한다는 말이다. 그런데 그 데이터를 읽어오는 것이 느린것이 아니라 서버에 쌓이자마자 거의 실시간으로 가져와 매우 빠르다고 할 수 있다. 그리고 키네시스 에이전트는 그 데이터 레코드 위치정보를 항상 갖고 있다.

• DB에 있는 데이터를 실시간성으로 처리할 일은 거의 없을 것이다. 그리고 데이터를 정말 실시간으로 처리해야 한다면 그 데이터를 DB에다 넣으면 안된다. 왜냐하면 실시간으로 분석을 해야하는데 디비에다 데이터를 넣는 순간 그 데이터를 다시 인출해야 하는 코스트가 발생하고 또한 엄청 느려지게 되기 때문이다. 이런 문제가 있는데 실시간으로 데이터를 처리한다고 하면 큐(예를들어서 메모리 디비 같은 툴들)에다가 데이터를 넣지 디비에다가 데이터를 넣는 것은 넌센스이다. 실시간 데이터를 디비에다 데이터를 넣더라고 이런 큐를 거쳐서 가야한다는 것이다.

• 예를 들어서 실시간 데이터가 디비에 들어가는 순간 jdbc라는 드라이버를 써서 컨넥션을 하고 데이터를 넣어줘야 하는데 이 경우 접속에 대한 코스트가 들어가고 시간이 딜레이 타임이 발생한다는 것이다.

• 이렇게 데이터가 실시간으로 처리되어야 한다고 하면 데이터가 생성되는 이벤트가 발생하면 바로 카프카 같은 스트림에 넣어야 한다. 카프카는 프로듀서라는 것을 여러개 생성할 수 있다. 예를들어서 하나는 데이터를 생성하는 프로듀서, 하나는 데이터를 소비하는 프로듀서 이런식으로 여러개를 다룰 수 있다. 이렇게 여러개 만든 프로듀서들 중에 하나는 파일을 저장만하고 데이터를 뽑아서 실시간으로 처리할 로직을 넣어서 돌리면된다. 카프카나 키네시스는 다 이런용도로 만들어진 것이다.

• 카프카는 설정할때 파일 사이즈가 있다. 카프카는 하드디스크 큐라고 할 수 있는데 굉장히 빠르다. 그래서 카프카가 꺼져도 데이터 손실이 적은 편이다. 왜냐하면 디스크에 데이터가 있기 때문이다. 그런데 이 디스크가 있다면 예를들어 100메가 바이트만 유지한다. 데이터가 실시간으로 막 들어오면 100메가만 유지하고 나머지는 버린다는 말이다. 통상 이런 사이즈는 1테라 2테라 이런식으로 설정한다. 이렇게 설정하면 그 설정한 용량만큼 큐에 데이터가 들어있는 것이다. 데이터가 들어오는 순으로 있다. 최대 7일치 분량의 데이터를 보관할 수 있느데 이 기간이 길면 길수록 서비스 이용료가 증가한다.

• 위의 그림을 예로 들면 키네시스 스트림 하나에 컨슈머가 4개 있다. 이렇게 키네시스가 하나 있어도 사용자의 용도의 필요에 따라서 하나는 s3에 저장하는 컨슈머하나, 특정 서비스를 또 거치기 위한 컨슈머 하나 이런식으로 여러컨슈머를 두고 사용할 수 있다.

• 샤드가 하나일떄 두개일때 세개일때 다른점은 요청이 오면 샤드가 하나이면 그 하나가 다 처리하고, 두개일때는 병렬로 처리가 가능하다. 즉 샤드는 다다익선이다. 그러나 샤드가 많아질수록 비용도 올라간다.

• Api-Gateway, 키네시스 스트림, firehose, S3의 장점

1) S3를 사용할 경우 저장용량이 사실상 무제한이다.

2) 요청이 많아져도 키네시스 스트림의 샤드 조정만으로 빠른 scability를 처리할 수 있다.

3) 데이터 유실에 대한 키네시스 스트림에서 기본적으로 24시간의 데이터 보존이 가능하다.

4) S3에 반정형화된 제이슨 형식의 데이터로 저장하므로 가변적 데이터 수집(쿼리 파라미터 값이 변화하는 것에 대해서)에 대한 유연한 분석이 가능하다. 따라서 가능하면 제이슨 형태로 저장하는 것이 좋다.

5) serverless의 운영비용이 감소한다.

• api-게이트웨이는 인터넷에서 아마존 웹서비스로 들어오는 문이라고 할 수 있다.

• 인터넷(휴대폰 어플리케이션)에서 보통 데이터를 날리면 거의 100프로 키네시스 같은 큐로 쏜다. 곧장 디비로 가면 매우 느리기 때문이다. 이 로그 데이터에 대한 반응속도가 느려서 서비스 제공속도가 매우 느려지게 될 것이다. 그러나 키네시스 큐로 보내면 로그를 받자마자 매우 빠르게 대응 할 수 있어서 서비스 속도를 보장할 수 있다.

• 파이어호스가 출시되기 전에는 데이터를 저장할때 람다를 쓰는것이 유일한 대안이었다. 파이어호스는 키네시스 스트림 아키텍처에서 컨슈머의 하나라고 할 수 있다. 파피어호스의 역할은 큐에 있는 데이터를 프로그래밍 없이 S3로 보낸다. 또는 레드쉬프트로 저장할 수도 있다.

• 레드쉬프트는 AWS의 데이터 웨어하우스이다. 아마존 ES는 일라스틱 서치를 말하는 것이다.

• 만약에 리얼타임 데이터 처리를 하고 싶다면 파이어호스 2개를 가동해서 하나는 s3 버켓으로 데이터를 저장하고, 하나는 ES로 보내면 된다. 참고로 최근에 출시된 ES는 데이터를 모니터링을 하는 것이기 때문에 데이터를 어느정도 또는 어느기간 동안 갖고 있다가 삭제할지가 중요하다. 과거에는 사용자가 원하는 인덱스를 갖고 나머지는 수동으로 삭제를 해줘야 하는데, 최근에 나온 ES는 그런것을 자동으로 옵션으로 설정할 수 있는 기능이 추가되었다.

• 그렇다면 데이터 파이프라인에서 반드시 키네시스가 필요한 툴인가. 반드시 그런것은 아니다. 키네시스를 놓는 이유는 키네시스를 하나 거치게 되면 여러개의 컨슈머를 둘 수 있다 없다의 차이이다. 키네시스가 필요없으면 파이어호스로 바로 다이렉트로 데이터를 흘릴 수도 있는 것이다.

• S3의 구성개념

1) 버킷 : 아마존 S3에 저장된 객체에 대한 컨테이너이다. 모든 객체는 어떤 버킷에 포함된다. 쉽게 말하면 윈도우 운영체제에서 root 폴더라고 이해하면 된다.

2) 객체 : 아마존 s3에 저장되는 기본 개체이다. 객체는 객체 데이터와 메타데이터로 구성된다.

3) 키 : 버킷 내 객체의 고유한 식별자이다. 버킷 내 모든 객체는 정확히 하나의 키를 갖는다. 버킷, 키 및 버전 아이디의 조합이 각 객체를 고유하게 식별하기 때문에 아마존 s3는 ‘버킷 + 키 + 버전’과 객체 자체 사이의 기본 데이터 맵으로 간주할 수 있다.

• 이제 우리가 실습할 내용은 위의 그림과 같다. 데이터가 생성이 되면 보통 쿼리 스트링으로 보내게 되는데 그 타입을 제이슨 형식으로 보내서 그 데이터를 API 게이트웨이에서 키네시스 스트림으로 보내게 된다. 그래서 파이어호스에서 로우데이터를 저장하고 그 로우데이터를 전처리해서 데이터 웨어하우스에 넣는 작업을 하는 것이다. 그리고 항상 메타데이터가 중심이 되어야 한다.

• RDS랑 S3는 결국에는 똑같은데 문제는 S3는 용량이 거의 무제한이지만 RDS는 인계점이 오면 계속 스케일업을 해줘야하는 문제점이 있다. 또한 EMR을 100개 띄워서 S3에 물려도 S3는 부하가 가지 않는 반면에 RDS에 EMR을 100개 물리게 되면 RDS가 감당을 못하고 죽어버릴 것이다.

Kinesis Stream, Firehose 설정 실습

스텝 1) 서비스에서 ‘kinesis’ 입력 후 접속

스텝 2) 아래 그림과 같이 좌측의 데이터 스트림즈 클릭 -> create 키네시스 스트림 클릭

스텝 3) 아래와 같이 스트림 네임 부여

스텝 4) 샤드 갯수 설정 후 create 키네시스 클릭

• 통상 샤드 하나정도면 하루에 천만건의 데이터는 처리할 수 있다.

스텝 5) 클릭하면 다음과 같이 생성된다.

스텝 6) 그 다음으로는 파이어호스를 만들어야 한다. 좌측의 데이터 파이어호스 클릭 후 크리에이트 딜리버리 스트림을 클릭해준다.

스텝 7) 크리에이트 클릭하고 마찬가지로 아이디를 부여해준다.

스텝 8) 하단에 키네시스 스트림 옵션 클릭 후, 키네시스 스트림 선택옵션에서 내가 방금 만든 키네시스 스트림 아이디를 선택한다.

스텝 9) 다음을 누르면 프로세스 레코드가 나오는데 여기에서는 람다 프로그래밍을 짜는 것처럼 특정작업을 프로그래밍으로 미리 설정해놓을 수 있다. 현재는 그냥 넘어간다

스텝 10) 데이터를 어디에 저장할 것인가에 대한 설정이다. 우리는 s3에 저장할 것이기 때문에 s3를 선택한다.

스텝 11) 지정된 s3 버켓을 먼저 지정하고, 파이어호스에서 데이터를 보낼 시 s3 버켓 내에 서브폴더를 생성하여 저장할 세부 경로를 S3 prefix에 다음과 같이 입력하여 지정할 수 있다.

아래와 같이 입력해주면 경로를 지정을 해주고 실제로 파이어호스가 작동되어 데이터를 날려주면 그때 s3에 폴더가 생성되고 파일이 저장된다.

스텝 11) s3에 버퍼링 옵션을 걸수도 있다. 예를들어 아래 그림처럼 하면 큐에 5메가가 차거나(or) 300초 주기로 데이터를 s3에 쌓는 옵션이다.

스텝 12) 그 다음으로는 운영할때는 s3 compression을 GZIP으로 설정하면 좋으나 우리가 실습할때는 데이터를 S3로 내려서 파일 내용을 확인해야하기 때문에 여기서는 디스에이블로 설정한다.

스텝 13) 파이어호스라는 서비스에서 S3라는 서비스로 데이터를 저장하는 것이기 때문에 권한을 줘야한다. 그래서 아래 그림처럼 크리에이트 뉴 OR 츄즈를 선택한다

스텝 14) 아래 그림과 같이 미리 설정해 놓은 IAM롤을 선택하고, 아래와 같이 입력해준다.

스텝 15) 선택하고 생성하면 다음과 같이 파이어호스까지 만들어지게 된다.

스텝 16) 서비스 사용자 역할을 할 EC2를 하나 생성해준다. EC2 서비스 접속 후 왼쪽에 이미지 AMI 선택 -> 기존에 강사님이 만들어놓은 이미지 선택 -> 왼쪽상단에 launch를 클릭한다.

참고로 선택한 이 EC2 안에는 미리 환경설정이 되어 있는 것이다. 자바도 깔려있고, CSV를 제이슨으로 발송하는 프로그램도 깔려있는 것이다.

스텝 17) 런치한다음에 하드웨어는 그냥 작은걸로해서 선택한다. 그다음 넥스트 누르고 테그에 이름을 꼭 넣어준다. 그다음에 시큐리티 그룹에서는 아래와의 시큐리티 그룹을 선택해준다.

스텝 18) ec2가 생성이 다 되면 우리가 그다음으로 할 것은 다음과 같다. EC2에서 키네시스로 데이터를 쏘려고 하는데 먼저 EC2라는 서비스에서 키네시스의 서비스 접근권한을 줘야한다. 그래서 role을 만들어서 ec2에 부여해줘야한다. 읽고 쓰고 그런 권한을 ec2에게 부여할 것이다.

아래 사진과 같이 생성한 ec2 마우스 오른쪽 클릭 -> 인스턴스 셋팅 -> attach/replace IAM 롤 클릭

스텝 19) 다음과 같이 미리 강사님이 권한을 부여해 놓은 옵션을 선택하고 적용해준다.

스텝 20) 그 다음 커넥트를 누르고 주소를 확인한 다음에 베시쉘로 EC2에 접속해준다.

베시쉘 실행 -> .pem 키 있는 폴더로 이동 -> ssh -i mspark_dees2_seoul.pem ec2-user@ec2-xx-xxx-xxx-xxx.ap-northeast-2.compute.amazonaws.com 입력 및 실행

주의해야 할점은 아래 그림에서 EXAMPLE에는 root@ec2 …로 시작하는 주소인데 루트가 아니라 ec2-user이다.

스텝 21) EC2가 어떤 키네시스를 바라봐야할지도 설정을 그림과 같이 해줘야 한다.

EC2 접속한 쉘에서

aws configure 입력 -> 아이디는 그냥 엔터 -> 엑세스키도 그냥 엔터 -> 디폴트 리전에 ‘ap-northeast-2’ 입력 후 엔터 -> 아웃풋 포멧도 그냥엔터

이렇게 하는 이유는 키랑 엑세스키는 IAM role로 권한을 줬기 때문에 입력을 안해도 되고, 리전만 우리가 쓴 지역이 서울이기 때문에 노스이스트로 해준것이다.

스텝 21) 아래 그림과 같이 입력해서 실행하면 키네시스 스트림에다 데이터를 넣어서 보내는 작업이 완료가 된것이다.

스텝 22) 그리고 아래와 같이 또 입력해준다.

스텝 23) 데이터가 아까 설정해둔 S3 버켓에 잘 들어왔는지 확인해본다.

들어온 파일을 다운받아서 아톰에서 열면은 그림 아래와 같이 전시가 된다.

스텝 24) 아마존 키네시스 콘솔에서 모니터링 메뉴에 들어가면 아래와 같은 흐름 기록이 남는다.

스텝 25) 파이어호스 콘솔에서도 확인 할 수 있다.

이렇게해서 키네시스랑 파이어호스 설정했고 서비스 이용자라고 가정한 EC2에서 데이터를 쐈을때 s3에 데이터가 쌓이는 것을 확인했다.

Api-Gateway 설정 실습

스텝 1) aws 서비스 선택에서 api gateway 선택 및 아래 그림과 같이 create api 선택

스텝 2) 생성 옵션에서 다음과 같이 옵션을 넣어준다. 그 다음에 크리에이션을 해준다.

스텝 3) 생성된 api 게이트웨이 클릭 -> 좌측에 리소스 클릭 -> 화면 가운데 상단에 엑션s 클릭 -> 크리에이트 리소스 클릭 -> 그리고 api에 대한 버전이 바뀔 수도 있어서 버전관리를 위해 아래 그림과 같이 v1으로 하나 생성해준다.

스텝 4) 이게 http 프로토콜 방식으로 들어오는데 그거에 대해서 어떠한 메소드로 처리할 것인가에 대해 설정을 해줘야 한다. 그래서 마찬가지로 엑션s 클릭 -> 크리에이트 메서드 클릭 !

모든 전문은 다 POST 방식이라고 생각하면 된다. 왜냐하면 겟방식은 데이터 리미트가 정해져있고, 파라미터도 단문이어서 이 방식은 잘 안쓴다.

스텝 5) post 선택한 다음에 체크를 누르면 아래 그림과 같은 옵션 선택 화면이 나오는데 빨간색 표시된 것과 같이 옵션을 선택해주면 된다. 그리고 save를 클릭해준다.

포스트 방식으로 데이터가 날라오면 키네시스로 보낼 것인데 이 키네시스가 aws 서비스 안에 있기 때문에 아래와 같이 aws 서비스 옵션을 선택해줘야 한다.

참고로 위의 그림에서 HTTP method에서 POST를 선택하는 것은 이놈은 이 서비스와 서비스를 연결할때 방식을 포스트 방식으로 하겠다는 것이다.

Action은 얘가 약속된 프로토콜이다. Execoution role도 얘가 서비스와 서비스 간에 권한을 설정해줘야하기 때문에 이 설정을 해주는 것이다.

스텝 6) 우리가 할 일은 데이터 받은 것을 인테그레이션 리퀘스트 해줘서 이 데이터를 키네시스로 보내줘야 한다. 그래서 아래 그림처럼 인테그레이션 리퀘스트 클릭해서 들어가준다.

스텝 7) 아래 그림처럼 HTTP Headers 클릭하면

아래와 같이 약속된 헤더값이 있을텐데 이건 뭐냐면

api 게이터웨이에서 키네시스로 보낼때 서로 약속된 패킷의 헤더값을 정의한 것이다.

api 게이트웨이에서 키네시스로 쏠때 헤더값에 제이슨 형식의 어떤것을 넣어줘야 한다.

약속된 헤더값을 설정해줘야 키네시스가 그 헤더값을 보고 내가 받아야 하는 context라는 것을 인지한다. 아래 그림처럼 설정해준다.

그래서 Add header를 눌러준다.

그리고 에드 매핑 템플릿을 눌러준다.

데이터를 보내주는 형식이 data, 파티션키, 스트림네임(데이터를 어디로 보내줄지) 아래와 같이 입력을 해주면 된다.

참고로 파티션키는 키네시스 안에서 쓰는 키다. 데이터가 키네시스로 들어가면 줄을 세워야 하는데 줄을 세우는 데이터에 이름이 있다면 줄세우는데도 훨씬 쉬울것이다.

엔터라는 변수에 진짜 엔터값을 넣어준 것이고, 데이터가 들어오면 제이슨 변수에 넣고, 유틸에 있는 base64 메소드로 이 제이슨 변수를 인코딩한다는 것이다. 파티션키는 X-Amzn의 트레이스 아이디를 받아서 넣어주겠다는 것이다.

엔터라는 변수에 엔터값을 안붙여주면 데이터가 들어오는대로 우측에 계속 붙어버리게 될것이다. 즉 엔터키를 넣어줘야 로우별로 데이터가 쌓인다는 말이다.

위와 같이 설정해주고 save 클릭해주면 된다.

스텝 8) 그리고 얘는 디플로이라는 것을 해줘야 적용이 된다.

액션 클릭해서 디플로이 api 클릭을 해준다.

그리고 스테이지 네임은 아래 그림과 같이 New Stage, 스테이지 네임은 prod로 해준다. 그리고 deploy 클릭을 해준다.

스텝 9) 만든 prod에 host에 보면 URL이 있는데 이 URL을 카피한다.

위의 그림에 보면 쓰로틀링이라는 것이 있는데 ‘목을 조인다’ 라는 뜻으로 특정 조건이상 호출이 안되도록 설정해주는 것이다. 그래서 호출이 많은 서비스 일 경우에는 얘를 지정해서 예를들어 10000개 이상 호출되는 것에 대해서 데이터가 받는다는 조건이다.

스텝 10) EC2 콘솔로 돌아와서 curl -d ‘{“key1”:”value1”, “key2”:”value2”}’ -H “Content-Type: application/json” -X POST https://5xxxxxxh.xxxx.ap-northeast-2.amazonaws.com/PROD (방금 복사한 URL을 이렇게 붙여넣는다.)

제이슨을 쏴주는 Curl이라는 명령어가 있는데 Curl 명령어는 웹페이지 여는 명령어랑 같은 것으로 이해하면 된다.

컨텍스트 타입을 어플리케이션 제이슨으로 할 것이고, POST 방식으로 데이터를 쏴줄 것이다.

아까 접속한 EC2에서 다음과 같이 입력해서 테스트를 한다.

1) Curl 을 활용해서 발송테스트를 해본다.

2) curl -d ‘{“key1”:”value1”, “key2”:”value2”}’ -H “Content-Type: application/json” -X POST https://5xxxxxxlh.xxxx.ap-northeast-2.amazonaws.com/PROD

3) 위와 같이 명령어를 넣어서 실행하면 정상적인 결과는 다음과 같이 시퀀스 넘버를 출력한다.

{“SequenceNumber”:”4958XXXXXXXXXXXXXXXXXX7055638352364841205762”,”ShardId”:”shardId-000000000000”}%

위의 그림은 무슨 의미냐면 jar 파일로 되어 있는데 -jar 명령어를 주게 되면 이 .jar가 실행된다. 그리고 옵션을 붙였는데 -f는 파일을 의미한다. 그리고 danji_master.csv라는 파일을 읽어서 뒤의 URL 주소로 디폴트를 application json으로 해서 보내준다.

위과 같이 명령어를 치고 실행하면 11건 정도 데이터를 보내주게 된다. post에서 리턴벨류 200은 정상적으로 잘 보내졌다는 의미이다.

S3 버킷에 가면 다음과 같이 파일이 생성되어 있을것이다.

S3 버킷에 들어온 파일을 다운받아서 아톰으로 열어보면 다음과 같다.

• 오늘은 수집할 수 있는 서비스를 중심으로 알아봤다. api 게이트웨이를 통해서 수집한 것을 실습한 것이고, 보통의 외부시스템에서 우리의 시스템으로 데이터를 보낼때 웹훅방식이라고해서 포스트방식으로 쿼리스트링으로 던지는 경우가 제일 많다. 우리가 특정 URL로 쏴달라고 요청을하면 또는 외부시스템에 우리가 원하는 URL을 입력을해주면 거기로 그 외부시스템에서 발생하는 이벤트가 웹훅방식으로 우리시스템에 쏴주게 된다. 우리는 그것을 받아서 우리 시스템에 저장하게 되는데 오늘 실습한 방식이 제일 좋다고 할 수 있다.

• 주의해야 할점은 데이터중에 중복데이터가 발생할 수 있다. 항상 중복데이터는 주의해서 처리해줘야한다. 예를 들어서 사용자가 클릭한번하면 될것을 두번 클릭했는데 이 이벤트 두개를 하나로 쳐야지 별개의 두개로 칠수는 없기 때문에 이런 부분을 잘 처리해줘야 한다는 말이다.