증분 처리 플랫폼Cana 개발기

김영준NAVER 검색솔루션개발랩

contents

Cana 소개 / 증분 처리 개요HBaseSI + HBase Coprocessor 기반 구현Omid + Storm Topology 기반 구현Cana Tx + Cana Reactor트랜잭션 성능 / 적용 사례 / 남은 과제 / 유사 솔루션

Cana 소개 /증분 처리 개요

Cana 소개

HBase와 Storm 기반의 증분 처리 플랫폼

검색 증분화 프로젝트 BREW의 하위 프로젝트로 2012년에 시작

문서 정제 증분 처리용 플랫폼을 만드는 것이 목표

수집 정제 색인 서빙

Cana BREW4

A B Sum

R1 10 20 30

R2 7 12 19

R3 … … …

… … … …

… … … …

Total - - 500

증분 처리 개요

(R1, A) = 30

다시 계산해야 할 부분

5

증분 처리 개요

다시 계산할 필요가 없는것도 모두 계산해야 함

배치처리– 긴 반영 시간, 비효율적6

재처리 대상

A B Sum

R1 10 20 30

R2 7 12 19

R3 … … …

… … … …

… … … …

Total - - 500

증분 처리 개요

A B Sum

R1 10 20 30

R2 7 12 19

R3 … … …

… … … …

… … … …

Total - - 500

(R1,A)←30

7

Sum = A + B

Total =∑Sum

(R1,Sum)←50

(Total,Sum)←520

증분처리– 짧은 반영 시간, 효율적

증분 처리 개요

A B Sum

R1 10 20 30

R2 7 12 19

R3 … … …

… … … …

… … … …

Total - - 500

8

Transaction

TransactionTransaction

Event Notification

증분 처리 개요

대용량 갱신 연산 트랜잭션

RDBMS X O O

Hadoop O X X

NoSQL O O Single-Row

데이터저장소후보

Multi-Row 트랜잭션9

증분 처리 개요

무결성 동시성

Serializable Read Uncommitted

트랜잭션의 Isolation Level

10

Snapshot Isolation

높은 무결성을 보장하면서 동시성도 우수한 Isolation LevelTimestamp Oracle과 Multi-Version Data Store 필요

Write(A, 1)

Read(A) == 1, Write(A, 2)

Read(A) == 1, Write(A, 3)

Read(A) == 2

t

Start TS

Write-Write Conflict

11

Commit TS

HBase

대표적인 NoSQL로 Single-Row 트랜잭션만 지원

사내에서 데이터 저장용으로 많이 사용

Snapshot Isolation 구현에 필요한 Multi-Version 기능 제공

12

Cana 프로젝트의 ‘구체적인’ 목표

HBase 위에 Snapshot Isolation 트랜잭션구현

+Event Notification 기능 구현

13

HBaseSI + HBase Coprocessor기반 구현

15

HBaseSI논문기반Coprocessor기반

OmidStorm Topology 기반

Cana TxCana Reactor

Early 2012

Mid 2012

Mid 2013

HBaseSI

HBase 위에 Snapshot Isolation 트랜잭션을 구현한 논문(link)여기에 기반하여 트랜잭션 라이브러리를 구현

Client

Counter Tables(Timestamp Oracle)

DataTable

incrementColumnValue()

commitwrite

CommitRequestQueue

CommitQueue

Committed

16

HBase Coprocessor

HBase 프로세스 내에서 원하는 동작을 실행하는 기능(HBase 0.92에 추가됨)

<Region>put()

<RegionObserver>

postPut()prePut()

17

RegionObserver Coprocessor 구현

기본동작1. put()이 실행되었다는 Event를 postPut()으로 감지

2. 감지된 Event는 RegionObserver 내의 큐에 넣음

3. RegionObserver 내의 스레드에서 큐의 Event를하나씩 꺼내어 관련 트랜잭션 로직 실행

4. 트랜잭션 로직에서 put()이 실행되면 위 과정이 반복

18

RegionObserver Coprocessor 구현

Storage

Sum=A+B

RegionObserver

Total=∑Sum

Region Server

(R1, A) = 30(R1, A) 변경

(R1, Sum) = 50

postPut()App

19

RegionObserver Coprocessor 구현

Storage

Sum=A+B

Total=∑Sum

Region Server

RegionObserver

(R1, Sum) 변경

(Total, Sum) = 520

postPut()

20

특정테이블에요청이집중되어 트랜잭션 성능이 떨어짐21

CommitRequestQueue

Client

Counter Tables(Timestamp Oracle)

CommitQueue

Committed

Client

Client

Hot Spot

HBaseSI 구현의 문제점

Coprocessor 구현의 문제점

어플리케이션의문제가 Region Server에바로영향을미침

CoprocessorApplication

Region Server

CoprocessorApplication

Region ServerBug,

Memory Leak

22

Coprocessor 구현의 문제점

어플리케이션배포가불편

hbase> disable ‘document’hbase> alter ‘document’ … ‘coprocessor’=>‘…’hbase> enable ‘document’Coprocessor

Application

HBaseTable

deploy OtherApp

23

Omid +Storm Topology기반 구현

25

HBaseSI논문기반Coprocessor기반

OmidStorm Topology 기반

Cana TxCana Reactor

Early 2012

Mid 2012

Mid 2013

Omid

Yahoo!에서 개발한 오픈소스(link, 논문)

HBase 위에 Snapshot Isolation 트랜잭션을 구현

Optimistically transaction Management In Data-stores(낙관적 – 트랜잭션이 쓴 데이터는 Commit 전에 저장소에 기록됨)

HBaseSI를 대체할 트랜잭션 엔진으로 선택

26

Omid를 선택한 이유

바로 사용 가능한 코드

Omid를 사용하여 작성한 논문이 공개되어 있었음

HBaseSI 구현에 비해 높은 성능

적어도 Event Notification 기능을 재개발하는 동안은Omid에 의존할 수 있을 것이라 판단

27

Omid

DataTable

write

Servertransactionoperations

Timestamp Oracle

TransactionInformation

Client

서버/클라이언트모델28

Omid - Write

Client

TS Val

1 X

① begin

③ Putwith TS = 1

Column A

Client

TS Val

1 X

1

④ commit(1, [‘A’])

Column A

1

Server Server

⑤ success

1 1→2

②

29

Omid - Read

Client

TS Val

6 Z

3 Y

1 X

③ Getwith TS <= 7

Column A

Client

TS Val

6 Z

3 Y

1 X

7

Column A

7

Server Server

④ commit query / responseinSnapshot(7, 6) ? => NoinSnapshot(7, 3) ? => NoinSnapshot(7, 1) ? => Yes A = X

① begin

②

7 7

30

Omid - Commit 실패 시

Client

TS Val

1 X

① commit

③ Deletewith TS = 1

Column A

Client

TS Val

1

④ cleanup

Column A

1

Server Server

② failure ⑤ ok

1 1

31

Omid - 단일 서버의 한계 극복

Server

Timestamp Oracle

TransactionInformation

BookKeeperWAL

Client 서버 장애 대비

서버로의 요청 횟수↓최대 크기를 제한(오래된 트랜잭션을 강제 abort)

32

Storm

오픈소스실시간연산프레임워크Coprocessor를 대체할 수단으로 선택

33

Storm을 선택한 이유

Event Notification을통한실행모델과유사한컨셉- Storm은 Tuple을 전달함으로써 작업을 처리함

Event Notification 처리에필요한기본적인기능을제공- Scalable- Fault-tolerance- Guaranteeing message processing

어플리케이션배포가간편함

34

Storm Topology 기반 구현

Event의생성과전달방식Event는어플리케이션에서직접생성하여전달(자유도↑)

데이터를 저장소에 기록하지 않고 Event에 포함시켜 전달 가능데이터 write와 무관한 Event도 사용 가능

최초의 Event는 Kestrel 큐에넣음예) 문서 수집/변경 Event

파생 Event는스트림을통해바로관련로직에전달(큐사용 X)

35

Storm Topology 기반 구현

트랜잭션을분산처리할수있도록함

Storm의 분산 처리 기능을 그대로 활용

트랜잭션 객체가 Tuple의 형태로 하위 스트림에 전달됨

‘Sub Topology’ 단위로 트랜잭션이 실행되도록 함

36

Storm Topology 기반 구현

Sum=A+B

Total=∑Sum

Storage

Kestrel

Topology

Sub Topology

Sub Topology

(R1, A) = 30

(R1, A) 변경

App (R1, Sum) 변경

(Total, Sum) = 520

(R1, Sum) = 50

37

Storm Topology 기반 구현

Sub Topology는로직및트랜잭션의단위

Begin Tx Commit Tx

Tx Read/Write(App Logic)

Sub Topology

Spout or

Sub Topology

Tx

Tx

Tx

Tx

Tx

Tx

Tx

Tx

38

Omid의 문제점

기본적인 트랜잭션 기능에서 버그가 종종 발견됨

미완성된 기능 존재

프로젝트가 정체되어 있었음

39

Storm Topology 기반 구현의 문제점

로직이여러 Bolt로분산되어개발/유지보수가어려움

40

A =?

A←10A←20

Storm Topology 기반 구현의 문제점

Event와로직의연결이번거롭고 Topology가커지는문제

41

Sub Topology

Sub Topology

Sub Topology

Storm Topology 기반 구현의 문제점

데이터포함 Event가큐안에서오래대기하면데이터불일치발생

A=20 A=10

A=20

Event의 데이터와저장소의 데이터가불일치

최신 Event가 처리되면되지만 앞 작업은 헛수고

42

Cell Value

A 10 20

… …

Cell Value

A 20

… …

Cana Tx +Cana Reactor

44

HBaseSI논문기반Coprocessor기반

OmidStorm Topology 기반

Cana TxCana Reactor

Early 2012

Mid 2012

Mid 2013

Cana Tx

Omid에서 사용하는 개념만 빌려 새로 개발한 트랜잭션 엔진

Omid의 버그 수정

Omid에서 미완성된 기능 완성- 서버 이중화- Garbage Collection

45

Cana Tx 서버 이중화

Server1

BookKeeper

WAL

ZooKeeperClient Server2

Server3

Active: Server1

46

Curator

Curator

Curator

Curator를사용하여 Active-Standby 방식으로구현

Cana Tx 서버 이중화

Curator를사용하여 Active-Standby 방식으로구현47

BookKeeperZooKeeperClient

Active: Server3WAL

Server1

Server2

Server3

Curator

Curator

Curator

Cana Tx Garbage Collection

필요성–죽은클라이언트에의해남겨진데이터제거

Ta

Tb

Tc

Cana Tx Client Cana Tx Server

Ta Tb Tc

HBase

48

Cana Tx Garbage Collection

Ta

Tb

TcTa Tb Tc

49

필요성–죽은클라이언트에의해남겨진데이터제거

Cana Tx Client Cana Tx ServerHBase

Cana Tx Garbage Collection

필요성 - Commit된데이터중더이상접근되지않는것이발생

TS Val

3

1

TS Val

10

8

3

1

TS Val

21

15

10

8

3

1Committed

Data

Column A Column A Column A

t

50

Cana Tx Garbage Collection

HBase의데이터정리하기–기본아이디어

1. Abort된 데이터는 언제 제거해도 무방2. Commit된 데이터는 읽힐 가능성이 없는 것만 제거해야 함

1) Commit된 데이터를 지워도 되는 기준 타임스탬프를 찾고, 2) 그 이하 구간에서 Abort된 데이터는 모두 제거하고,3) Commit된 데이터는 칼럼 마다

타임스탬프가 최신인 것 하나씩만 남겨두면 됨

51

Cana Tx Garbage Collection

TS Val

23 …

20 …

15 …

10 …

6 …

3 …

1 …

Column A

기준 타임스탬프 = 20Committed = [3, 15]

Aborted = [1, 6, 10, 20]

Cana TxServer

TS Val

23 …

15 …

Column A

Compaction

Tx Snapshot

Coprocessor를써서 Compaction 도중데이터를정리하도록구현52

Cana Reactor

Event와로직연결의유연성을높이기위해 Pub-Sub 모델을사용

Event는변경이발생한영역정보만전달하여최신성문제해결- 더불어 Event는 데이터 변경만을 나타내도록 자유도를 제한

모든 Event는 Topology에연결된큐를거쳐전달

트랜잭션은단일 Bolt 내에서만실행되도록제한- 분산 처리의 이점보다는 로직 개발 편의성이 중요하다고 판단

53

Publish-Subscribe 모델

A observes (T1, F1, Q1)

B observes (T2, F2, Q2)

ZooKeeper

Logic A

Logic B

54

Cell Value

A 10 20

… …

Cell Value

A 20

… …

Event 처리 시점에데이터를 저장소에서읽어옴(최신성 보장)

중복 처리를 하지 않기위한 방법은 필요함(예: 어플리케이션에서

diff 체크)

A A

A

55

Event는 변경이 발생한 영역 정보만 전달

모든 Event는 큐를 거쳐 전달

56

트랜잭션은 단일 Bolt 내에서만 실행

Sub Topology Bolt

57

Cana Reactor

Sum=A+B

Storage

Topology

Total=∑Sum

App

Topology

(R1, A) = 30

(R1, A) 변경

(R1, Sum) 변경

(Total, Sum) = 520

(R1, Sum) = 50

58

Cana Reactor

일반적인 Storm 사용방식과는다름- 로직을 단일 Bolt 내에서 실행- 파생 Event를 스트림이 아니라 큐를 통해 전달

그러나 Storm을그대로사용- 그 동안 Storm을 사용해 와서 익숙함- Storm이 제공하는 기능을 활용하기 위해

59

HBase 테이블 큐

큐가 아니나 Storm Spout에서 쓰는 용어에 맞춰 큐라고 부름

Message Collapsing 기능을 사용하기 위해 개발함

Kestrel 프로젝트가 정체되어 이를 대체할 큐 필요

60

HBase 테이블 큐

Message Collapsing

61

C1 C2 C3

R1

R2

R3

HBase 테이블 큐

T1 + C1 T1 + C2

salted(R1) + R1 N1

salted(R2) + R2 N2

...

테이블 큐

62

T1 테이블N1

N2

C1 C2 C3

R1

R2

R3

HBase 테이블 큐

T1 + C1 T1 + C2

salted(R1) + R1 N1 N3

salted(R2) + R2 N2

...

N3

scan

N3

N2

테이블 큐

63

T1 테이블

트랜잭션 성능 /적용 사례 / 남은 과제 /유사 솔루션

Cana Tx 트랜잭션의 성능 특성

65

트랜잭션 연산 비용 = HBase 연산 비용 + 트랜잭션 오버헤드

트랜잭션 오버헤드: 트랜잭션 시작, Commit Query, Commit

트랜잭션 오버헤드는 HBase와 무관

Commit 비용은 Write-Set이 클수록 증가(Conflict 체크 비용 증가)

Write-Set 크기에 따른 트랜잭션 성능

66

0

1

2

3

4

5

6

7

0 10000 20000 30000 40000 50000 60000

Latency(m

s)

TPS

1

16

32

64

128

# of Columns

적용 사례

2015년 상반기 NAVER 지식인 검색 서비스에 BREW 적용

적용 후 검색 문서 갱신에 소요되는 시간 감소

점차 다른 검색 서비스로 확대 적용 예정

67

남은 과제

Cana TxSQL on HBase 적용(예: Apache Phoenix)HBase 외의 저장소에 적용

Cana ReactorStorm 대체 플랫폼 고려

68

Google Percolator와의 비교

Google Percolator

2010년 논문을 통해 공개됨(link)

증분 인덱싱 시스템 Caffeine에서 사용

Bigtable에 Snapshot Isolation 트랜잭션 제공

Observer Framework를 사용한 Event Notification 기능 제공

69

Google Percolator와의 비교

트랜잭션구현방식비교

Cana Tx Percolator

Timestamp Oracle 서버로 구현 서버로 구현

데이터기록시점 Write 할 때 Commit 할 때

트랜잭션정보저장소

서버의 메모리 +클라이언트의 캐시

메타 칼럼

Commit 서버에서 처리Lock을 사용하여

클라이언트에서 처리

70

Google Percolator와의 비교

Event Notification 구현방식비교

공통점- 테이블에 Event를 저장하고 테이블을 스캔하여 Event를 추출- Message Collapsing 기능 제공

차이점- Cana Reactor: Event 저장 전용 테이블 사용- Percolator: 데이터 테이블의 메타 칼럼에 Event를 저장

71

Omid2

최근 새로운 Omid 코드가 GitHub에 올라옴

기본적인 트랜잭션 처리 방식은 기존과 동일

Commit 관련 정보를 HBase 테이블과 메타 칼럼에 저장

WAL을 더 이상 사용하지 않음

72

유사 오픈 소스 솔루션

HBase 기반 트랜잭션 솔루션- Haeinsa: Percolator 방식과 유사. DEVIEW 2013- Tephra: Omid 방식과 유사- Themis: Percolator 논문에 기반한 구현

Tigon- Storm과 유사- HBase 테이블을 사용하여 큐를 구현- Tephra를 사용하여 트랜잭션 사용 가능

73

Q&A

Thank You