1

IoT 커넥티비티 대용량 서버 구축기Prepared for Tech Planet

December, 2014

2

• 1985년생 (만 29세)

• 컴퓨터 공학 전공 & 최적화 알고리즘 연구

• 구글, 애드바이미등 에서 빅데이터 처리

• ZOYI Corporation CEO & Co-founder

최시원

3

•IoT 개론

•커넥티비티 문제 정의

•Web Socket

•Kafka

•Hadoop

4

Background

5

CES 2014, January

http://www.itproportal.com/2014/01/06/ces-2014-nvidia-stirs-things-up-with-triple-announcement/

6

에서 가장 많이 언급된 단어

IoT (Internet of Things)

7

http://commons.wikimedia.org/wiki/File:Internet_of_things_signed_by_the_author.jpg

8

The Size of IoT

0B

3B

6B

8B

11B

14B

2003 2013

12.5B

0.5B

6.8B6.3B

People IoT

9

IoT - 2020년 사람당 26개 디바이스가 있을 것으로 예상

10

손목에 시계는 3개쯤 차줘야…

11

2013

12

Retail Market Overview

■ 오프라인 리테일 시장은 온라인 리테일에 비해 7배 큰 시장(2013 국내 통계청 자료 기준)이나, 2013년 오프라인 리테일의 성장률은 0.7%로 온라인 리테일 성장률 12.3%에 비하면 매우 저조한 수준

1%

15%

84%

오프라인 커머스 온라인 커머스 소셜 커머스0%

2%

4%

6%

8%

10%

12%

14%

2013년 성장률

12.3%

0.7%

오프라인 성장률 온라인 성장률

13

Future vs Stone Age

■ 고객의 구매 프로세스 전 과정을 파악하여 전략 설정

■ 구매 퍼널(Purchase Funnel)을 구글 어날리틱스등 웹 분석도구를

통해 분석하여 개선 방법을 도출하고, 지속적으로 최적화 시키는 방

식이 일반화 되어있음

■ 상위 500개 온라인 리테일 업체의 98%가 분석 도구 이용 중

■ 오프라인 리테일의 방문객 데이터 수집 및 활용은 아직 기초적 수준

■ 대부분 POS(Point Of Sales)기를 통해 기구매 고객만 분석

■ 대형 리테일도, 적외선, CCTV 등 프로젝트성의 방문객 계수 정도만

가능하여,구매 퍼널에서 어느 부분에 문제가 있고 개선이 가능한지

적합한 전략을 도출하기 어려움

Online Offline

Awareness Familiarity Consideration Purchase Loyalty

14

Goal

■ 온라인과 같은 수준의 오프라인 리테일 어날리틱 서비스 제공

■ 상권 분석, 구매 퍼널 분석, 동선 분석, 로열티 분석 등 다각도로 현 상황을 진단 ➡ 상황 개선을 위한 액션플랜 도출 ➡ 실행 ➡ 분석

■ 피드백 루프를 완성하여 매장 성과를 개선, 궁극적으로 고객의 실제적 매출 증대 달성을 목표로 함

Feedback Loop

›❯›❯›❯›❯

›❯›❯

›❯›❯Action

Analytics

Insights

Strategy

15

0:26:45

Method

■ 스마트폰의 와이파이 신호에서 발생하는 무선 신호(와이파이 및 블루투스)를 감지하여, 매장을 방문객을 실시간으로 파악

■ 방문객에게 별다른 행위(예: 앱 다운로드, 인터넷 접속 등)를 요구하지 않고도 기기별 고유값이 있어 체류시간 및 재방문 측정 가능

■ 특정 AP에 접속해 있지 않더라도, 휴대폰이 대기상태라도 와이파이가 켜져 있기만 하면 실시간으로 인식 가능

■ 기존 방식으로 측정이 불가능했던 매장 밖 유동인구, 고객 체류시간, 재방문 패턴 등을 파악하여 구매퍼널 완성

16

Technology

17

Technology Requirements

하드웨어 생산부터 빅데이터 처리 및 분석, 대시보드 구현에 이르는 전 과정을 융합하는 풀 스택(Full Stack) 개발이 필요

■ 하드웨어(Sensor): 매장 설치 및 데이터 수집, 전송에 용이한 센서 설계 및 주문 생산

■ 빅데이터(Big Data): 하루 8,000만 건 시그널 처리가 가능한 대량 풋트래픽 수집 및 배치 데이터 처리 시스템 구축

■ 분석(Analytics): 수집된 데이터를 기반으로 구매퍼널 분석, 시계열 코호트(cohort)분석, 동선 분석 등 리테일에 필요한 분석

■ 대시보드(Dashboard): 고객이 데이터 결과를 기간별, 항목별로 분석할 있는 웹 및 앱 형태의 분석 결과 제공

하드웨어 및 임베디드 기술대용량 서버 분산 및

저장 기술리테일 분석 알고리즘 및

대용량 분석 시스템웹&앱 서비스

Sensor Big Data Analytics Dashboard

›❯ ›❯ ›❯

18

Limitations of Competitors’ Sensors

■ 북미/유럽 시장의 경우 쇼핑몰에 네트워크 시설과 함께 설치하는 경우가 다수 ➡ 유선 LAN 케이블이 필요

■ 브랜드 전문점 중심인 아시아의 경우 구조상 천장 설치가 필수적이나, LAN 공사가 제한되는 경우가 많아 북미제품 사용이 어려움

■ 요구 조건을 충족하는 새로운 센서의 필요성 대두

19

ZOYI Square Design

■ 매장의 원하는 곳에 설치가 용이할 것

■ 설치 및 사용이 단순할 것

■ 다양한 인테리어 환경과 조화를 이룰 것

115.4

115.4

25.7

13.4

2

9.4 15.6 15.6 14.9

7.5

11.9

94

78

115.4

115.4

25.7

13.4

2

9.4 15.6 15.6 14.9

7.5

11.9

94

78

20

ZOYI Square Board Production

■ 탐지와 인터넷 연결이 가능하게 2개의 Wi-Fi 모듈 탑재 ➡ 유선랜이 필요없어 천장 등 원하는 곳 설치 가능

■ 블루투스 4.0 탑재 ➡ iBeacon 등 인도어 커뮤니케이션 가능

21

Network Diagram

Client

Server

22

Connectivity

23

Size of Retail Shop분류 상세 분류 예 매장 수

리테일

전문소매점(패션,뷰티 제외) 하이마트, 다이소, 오피스디포 2,000

편의점 세븐일레븐, GS25 80,000

대형마트 이마트, 홈플러스, 롯데마트 450

쇼핑몰/아울렛 코엑스, 아비뉴프랑 200

드럭스토어 올리브영, 왓슨스 1,800

멀티샵 ABC마트, Aland, KOON 500

백화점 롯데백화점, 현대백화점 100

식음료

카페 클래치앤바르도 15,000

체인점(직영)베니건스, 고기킹

3,235

체인점(가맹) 72,903

브랜드 (패션/뷰티/잡화)

SPA 유니클로, 자라, 포에버 21, 에잇세컨즈, H&M 등 250

패션기타 신세계인터, LG패션, 한섬, 휠라코리아, 베이직하우스, 영원무역, 아비스타, 신원, F&F, 엠케이트렌드 20,000

화장품 미샤, 페이스샵, 네이처리퍼블릭, 토니모리 5,000

전통시장 1,000

202,438

24

Requirement

■ 4MB 플래시 램 / 여유공간 500KB 남짓u-boot 128 KB

kernel 896 KB

rootfs data 2048 KB

ART (Atheros Radio Test)

ART 64 KB

0x020000

0x000000

0x100000

0x300000

0x3f0000

0x400000

overlay 960 KB

rootfs

firmware

Embeded

■ 방화벽에 걸리지 않아야 함

■ 실시간 데이터 전송이 가능해야 함

■ 서버에 의한 Push 메세지 처리 해야 함 (reload 등)

Network

■ 한 센서에서 발생하는 트래픽은 많지 않음

■ 한 서버당 최대의 커넥션을 처리할 것Connection

25

Good-bye Protocol Buffers and Thrift

■ Protocol Buffers - 구글이 만든 RPC 프로토콜

■ Thrift - 2007 X-Googler 디자인 페이스북이 개발 / RPC 지원 프레임워크

■ Boost만 해도 400KB로 메모리 여유 공간 없음

■ 80/443 포트가 아니여서 때때로 방화벽에 제한됨

■ C++/Java Thrift 서버 테스트시 다량의 커넥션 처리가 어려움

➡ http 기반의 가벼운 클라이언트 접속 방법에 대해 고민

26

C10K Problem

■ 하나의 시스템에 얼마나 많은 커넥션이 붙을 수 있을지에 대한 문제

■ 네트웍 서버는 크게 동기 방식과 비동기 방식이 있음

■ 동기 방식으로는 주로 Thread가 이용되는데 C10K 를 해결할 수 없음

■ 비동기 방식은 Event-Driven으로 호스트에 따라 epoll(linux) / kqueue(BSD) / IOCP(windows)가 사용됨

■ 단점은 개발 및 유지 관리가 어려움

■ 잘 짜진 비동기 서버를 이용하면 좋을 텐데… ➡ Node.js!

27

Node.js

■ 2011년 이후 가장 주목받는 웹 서버 플랫폼 중 하나

■ 코어는 C로 작성되었고, 각 호스트 환경의 최적화된 Event-Driven 사용

■ 개발자는 JS로 작성하며 V8엔진이 이를 해석 수행함

■ Low 레벨로 컨트롤 할 수 있는 장점

■ 싱글 Thread임!

28

Polling?

Browser

Server

Request

Response

Time: Requests every n seconds

29

Long Polling?

Browser

Server

Request

Response

Time: Requests every n seconds

30

Too much overhead

31

Header traffic analysis

■ Use case A: 10,000 frames every 60 seconds

▶ Network throughput is (871 x 10,000)/60 = 1.1 Mbps

■ Use case B: 10,000 frames every second

▶ Network throughput is (871 x 10,000)/1 = 66 Mbps

■ Use case B: 100,000 frames every 10 seconds

▶ Network throughput is (871 x 100,000)/10 = 66 Mbps

■ Example network throughput for Polling HTTP request/response headers

32

Web Socket

33

What is a WebSocket?

■ W3C/IETF 스탠다드

■ Full-duplex 커뮤니케이션 채널

■ Raw Socket On HTTP

■ 80/443에서 동작되어 Proxy/Firewall에 유용함

■ HTTP 1.1에서 “Upgrade” 커넥션을 이용 연결됨

■ 프로토콜은 ws:// 및 wss:// 로 표기함

34

Supported Browsers

35

Reduces Network Traffic

■ 각 메세지 “프레임” 은 오직 2 바이트의 오버헤드만 있음

■ HTTP 메세지로 부터 커넥션을 맺는데 추가 레이턴시 없음

■ 폴링 오버헤드 없음 - 오직 메세지가 있을 때만 보냄

■ Use case A: 10,000 frames every 60 seconds

▶ Network throughput is (2 x 10,000)/60 = 2.6 Kbps (was 1.1 Mbps)

■ Use case B: 10,000 frames every second

▶ Network throughput is (2 x 10,000)/1 = 156 Kbps (was 66 Mbps)

36

Web Socket + Node.js

✓ 경량화로 임베디드에 넣기 충분 (libwebsockts 약 100KB)

✓ C10K 가능

✓ 80/443 포트 사용으로 방화벽에 유연

✓ Node.js 확장성 (서버 코드 100줄 남짓)

37

After that…

Client

Node.jsWebsocket

?

Database

38

Kafka

39

Kafka

■ Persistent, Distributed, Replicated, Pub/Sub messaging system

■ Scala/Java로 작성되어 있다.

■ 분산처리(Distributed Processing)가 가능하다.

■ Log Data를 디스크에 기록한다.

■ Publish-Subscribe구조로 되어 있다.

■ 확장 가능(Scalablility)하다.

■ Disk임에도 처리량이 높다.(High Throughput)

■ 응답속도가 빠르다.(Low Latency)

40

Kafka

41

Throughput

■ SSD : Broker 1대일때 56MB/s, 2대 일때 74.9MB/s, 3대 일때 96.6MB/s Throughput

■ HDD : Broker 1대일때 20.4MB/s, 2대 일때 35.8MB/s, 3대 일때 45.4MB/s Throughput

42

Powered By Kafka

■ LinkedIn - Apache Kafka is used at LinkedIn for activity stream data and operational metrics. This powers various

products like LinkedIn Newsfeed, LinkedIn Today in addition to our offline analytics systems like Hadoop.

■ Twitter - As part of their Storm stream processing infrastructure, e.g. this.

■ Netflix - Real-time monitoring and event-processing pipeline.

■ Square - We use Kafka as a bus to move all systems events through our various datacenters. This includes metrics,

logs, custom events etc. On the consumer side, we output into Splunk, Graphite, Esper-like real-time alerting.

■ Spotify - Kafka is used at Spotify as part of their log delivery system.

■ Pinterest - Kafka is used with Secor as part of their log collection pipeline.

■ Uber

43

Example

44

After that…

Client

Node.jsWebsocket DatabasePub/Sub Processing

45

Hadoop

46

Hadoop

■ 본 서비스가 처리하는 데이터 양은 시간 당 2천만 건. 향후 글로벌 진출 시 매장 20만 개를 커버하려면 시간 당 5억

건의 데이터를 처리하게 됨

■ 이를 저장하고 분석하기 위해 Hadoop 이용

■ 예를 들어 다음과 같은 연산을 수행해야 함

- 시계열분석 : 최소 시간 단위 분석이 필요, 중복 제거 유니크 방문자 식별 ⇨ 시간당 10TB에서 중복 제거 계산

- 재방문분석 : 각 방문자당 과거 12개월 내에 재방문 했었는지를 찾아야함 ⇨ 시간당 350TB 열람

47

IoT

48

Thank You