도입 배경

기존 번개장터의 실시간 클릭 로깅 시스템은 mysql을 이용하여 매 클릭을 수집하여 가공하는 방식으로 개발되어 있었습니다. 트래픽이 늘어가면서 구조적인 한계로 장애도 많이 일어나고, 비용도 많이 발생하여 새로 개발하기로 하였습니다.

신규 시스템

아래와 같은 시스템기준을 잡고 새로운 시스템에 대하여 리서칭 하였습니다.

  • 속도가 빠르고 확정성이 용이한지
  • 최신 기술인지
  • 래퍼런스가 많은지
  • aws 관리형 서비스가 있는지

aws 관리형 서비스 사용

관리형 서비스의 장점인 서버를 직접 구성할 필요가 없어 빠른 시간 안에 개발이 가능하고, 문제가 생기면 언제든 바로 구성이 가능하여 서버 운영 부담이 적기 때문에 관리형 서비스를 적극 활용하기로 하였습니다.

spark streaming으로 개발

spark streaming을 선정하여 개발하였습니다. 선정 이유는 구글링에서도 많이 나오고 spark 책을 통해 기본 개념을 잡기도 쉬웠습니다.
‘word count’기본예제를 본 순간 지금 하려는 실시간으로 클릭을 받아 집계하여 저장하는 그림이 바로 떠올라 선택하게 되었습니다. 또한 spark가 번개장터에서 주력언어로 사용하고 있는 파이썬으로 개발 가능한점도 선정하게된 이유입니다. ( 결국 scala로 개발 하게 됨 )

최근 spark에 구조적 스트리밍 방법이 추가되어 검토해 보았지만 아직 kinesis 플러그인이 없어 직접 만들어야 하는 부담 때문에 시도해보지는 못하였습니다. 현재 Databricks에는 제공하고 있어 조만간 spark에도 적용될 것 같습니다.

다른 실시간 스트리밍 대안으로는 stom은 단점에 관한 글이 많이 보였고, flink는 레퍼런스가 부족해 보였습니다.


전체 시스템 구조

Placeholder image

위 그림은 전체시스템 구조도 입니다. 각시스템을 선택한 이유는 다음과 같습니다.

1. fluentd

서버에서 발생된 로그를 수집하는 기능. 기존에 서버로그가 fluentd로 수집되어있어 이 부분은 크게 시스템을 바꾸지 않았습니다. logstash와 비교되기도 하는데 fluentd가 플러그인도 다양하게 있고 서버 리소스도 적게 사용한다고 하는 글들이 있어서 굳이 변경은 안 하였습니다.

2. kinesis

aws의 관리형 kafka cluster, EMR 앞뒤에서 데이터를 큐로 사용하였습니다. shard 개수만 설정하면 쉽게 생성 가능하고 fluentd 연결 플러그인과 spark streaming 연결 모듈이 있어서 쉽게 로그를 수집하고 전달할 수 있습니다.

3. EMR (spark streaming)

aws 관리형 하둡 클러스터인 EMR에 spark가 설치된 이미지를 사용. spark 뿐만 아니라 Hbase, flink, hive등 하둡과 관련된 프로그램을 선택하여 바로 클릭으로 설치 가능하고 yarn, ganglia 등으로 클러스터링과 모니터링 툴들도 설치할 수 있습니다. 이번에 spark로 개발하면서 하루에도 몇 번씩 클러스터를 띄웠다 지웠다 하였으며, 성능 최적화를 위하여 서버 사양별로 다양한 클러스터를 구성하여 테스트하기도 쉬웠습니다.

4. lambda

spark streaming에서 실시간 처리된 데이터를 elasticsearch에 인덱싱 하기 위해 사용. kinesis에 trigger를 통하여 람다에서 데이터를 가져와 es의 Bluk API로 인덱싱하도록 구성 emr에서 바로 인덱싱 할 수도 있지만 안정적으로 kinesis를 붙이고 lambda에서 추가적인 처리를 하기 위해서 구성하였습니다.

5. elasticsearch

최종적으로 상품당 클릭 카운트가 적제되고 로그를 검색하여 서비스에 데이터를 전달하는 역할. 기존에도 검색서비스에 aws의 관리형 서비스인 elasticsearch service를 사용하고 있어 동일하게 구성하였음. 확실히 데이터 조회 용도에 특화되어있는 만큼 낮은 사양에서도 안정적으로 운영이 가능했습니다.


이후 각 시스템별 구현에 대하여 포스팅 하도록 하겠습니다.