DEVIEW2015 DAY2. 증분 처리 플랫폼 cana 개발기

1. 증분 처리 플랫폼
Cana 개발기
김영준
NAVER 검색솔루션개발랩

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

3. Cana 소개 /
증분 처리 개요

4. Cana 소개
HBase와 Storm 기반의 증분 처리 플랫폼
검색 증분화 프로젝트 BREW의 하위 프로젝트로 2012년에 시작
문서 정제 증분 처리용 플랫폼을 만드는 것이 목표
수집 정제 색인 서빙
Cana BREW
4

5. A B Sum
R1 10 20 30
R2 7 12 19
R3 … … …
… … … …
… … … …
Total - - 500
증분 처리 개요
(R1, A) = 30
다시 계산해야 할 부분
5

6. 증분 처리 개요
다시 계산할 필요가 없는
것도 모두 계산해야 함
배치 처리 – 긴 반영 시간, 비효율적
6
재처리 대상
A B Sum
R1 10 20 30
R2 7 12 19
R3 … … …
… … … …
… … … …
Total - - 500

7. 증분 처리 개요
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
증분 처리 – 짧은 반영 시간, 효율적

8. 증분 처리 개요
A B Sum
R1 10 20 30
R2 7 12 19
R3 … … …
… … … …
… … … …
Total - - 500
8
Transaction
TransactionTransaction
Event Notification

9. 증분 처리 개요
대용량 갱신 연산 트랜잭션
RDBMS X O O
Hadoop O X X
NoSQL O O Single-Row
데이터 저장소 후보
Multi-Row 트랜잭션
9

10. 증분 처리 개요
무결성 동시성
Serializable Read
Uncommitted
트랜잭션의 Isolation Level
10

11. Snapshot Isolation
높은 무결성을 보장하면서 동시성도 우수한 Isolation Level
Timestamp 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

12. HBase
대표적인 NoSQL로 Single-Row 트랜잭션만 지원
사내에서 데이터 저장용으로 많이 사용
Snapshot Isolation 구현에 필요한 Multi-Version 기능 제공
12

13. Cana 프로젝트의 ‘구체적인’ 목표
HBase 위에 Snapshot Isolation 트랜잭션 구현
+
Event Notification 기능 구현
13

14. HBaseSI +
HBase Coprocessor
기반 구현

15. 15
HBaseSI 논문 기반
Coprocessor 기반
Omid
Storm Topology 기반
Cana Tx
Cana Reactor
Early
2012
Mid
2012
Mid
2013

16. HBaseSI
HBase 위에 Snapshot Isolation 트랜잭션을 구현한 논문(link)
여기에 기반하여 트랜잭션 라이브러리를 구현
Client
Counter Tables
(Timestamp Oracle)
Data
Table
incrementColumnValue()
commitwrite
Commit
Request
Queue
Commit
Queue
Committed
16

17. HBase Coprocessor
HBase 프로세스 내에서 원하는 동작을 실행하는 기능
(HBase 0.92에 추가됨)
<Region>
put()
<RegionObserver>
postPut()prePut()
17

18. RegionObserver Coprocessor 구현
기본 동작
1. put()이 실행되었다는 Event를 postPut()으로 감지
2. 감지된 Event는 RegionObserver 내의 큐에 넣음
3. RegionObserver 내의 스레드에서 큐의 Event를
하나씩 꺼내어 관련 트랜잭션 로직 실행
4. 트랜잭션 로직에서 put()이 실행되면 위 과정이 반복
18

19. RegionObserver Coprocessor 구현
Storage
Sum
=A+B
RegionObserver
Total=
∑Sum
Region Server
(R1, A) = 30
(R1, A) 변경
(R1, Sum) = 50
postPut()App
19

20. RegionObserver Coprocessor 구현
Storage
Sum
=A+B
Total=
∑Sum
Region Server
RegionObserver
(R1, Sum) 변경
(Total, Sum) = 520
postPut()
20

21. 특정 테이블에 요청이 집중되어 트랜잭션 성능이 떨어짐
21
Commit
Request
Queue
Client
Counter Tables
(Timestamp Oracle)
Commit
Queue
Committed
Client
Client
Hot Spot
HBaseSI 구현의 문제점

22. Coprocessor 구현의 문제점
어플리케이션의 문제가 Region Server에 바로 영향을 미침
Coprocessor
Application
Region Server
Coprocessor
Application
Region Server
Bug,
Memory Leak
22

23. Coprocessor 구현의 문제점
어플리케이션 배포가 불편
hbase> disable ‘document’
hbase> alter ‘document’ … ‘coprocessor’=>‘…’
hbase> enable ‘document’Coprocessor
Application
HBase
Table
deploy Other
App
23

24. Omid +
Storm Topology
기반 구현

25. 25
HBaseSI 논문 기반
Coprocessor 기반
Omid
Storm Topology 기반
Cana Tx
Cana Reactor
Early
2012
Mid
2012
Mid
2013

26. Omid
Yahoo!에서 개발한 오픈소스(link, 논문)
HBase 위에 Snapshot Isolation 트랜잭션을 구현
Optimistically transaction Management In Data-stores
(낙관적 – 트랜잭션이 쓴 데이터는 Commit 전에 저장소에 기록됨)
HBaseSI를 대체할 트랜잭션 엔진으로 선택
26

27. Omid를 선택한 이유
바로 사용 가능한 코드
Omid를 사용하여 작성한 논문이 공개되어 있었음
HBaseSI 구현에 비해 높은 성능
적어도 Event Notification 기능을 재개발하는 동안은
Omid에 의존할 수 있을 것이라 판단
27

28. Omid
Data
Table
write
Server
transaction
operations
Timestamp
Oracle
Transaction
Information
Client
서버/클라이언트 모델
28

29. Omid - Write
Client
TS Val
1 X
① begin
③ Put
with TS = 1
Column A
Client
TS Val
1 X
1
④ commit(1, [‘A’])
Column A
1
Server Server
⑤ success
1 1→2
②
29

30. Omid - Read
Client
TS Val
6 Z
3 Y
1 X
③ Get
with TS <= 7
Column A
Client
TS Val
6 Z
3 Y
1 X
7
Column A
7
Server Server
④ commit query / response
inSnapshot(7, 6) ? => No
inSnapshot(7, 3) ? => No
inSnapshot(7, 1) ? => Yes A = X
① begin
②
7 7
30

31. Omid - Commit 실패 시
Client
TS Val
1 X
① commit
③ Delete
with TS = 1
Column A
Client
TS Val
1
④ cleanup
Column A
1
Server Server
② failure ⑤ ok
1 1
31

32. Omid - 단일 서버의 한계 극복
Server
Timestamp
Oracle
Transaction
Information
BookKeeper
WAL
Client 서버 장애 대비
서버로의 요청 횟수↓
최대 크기를 제한
(오래된 트랜잭션을 강제 abort)
32

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

34. Storm을 선택한 이유
Event Notification을 통한 실행 모델과 유사한 컨셉
- Storm은 Tuple을 전달함으로써 작업을 처리함
Event Notification 처리에 필요한 기본적인 기능을 제공
- Scalable
- Fault-tolerance
- Guaranteeing message processing
어플리케이션 배포가 간편함
34

35. Storm Topology 기반 구현
Event의 생성과 전달 방식
Event는 어플리케이션에서 직접 생성하여 전달(자유도 ↑)
데이터를 저장소에 기록하지 않고 Event에 포함시켜 전달 가능
데이터 write와 무관한 Event도 사용 가능
최초의 Event는 Kestrel 큐에 넣음
예) 문서 수집/변경 Event
파생 Event는 스트림을 통해 바로 관련 로직에 전달(큐 사용 X)
35

36. Storm Topology 기반 구현
트랜잭션을 분산 처리할 수 있도록 함
Storm의 분산 처리 기능을 그대로 활용
트랜잭션 객체가 Tuple의 형태로 하위 스트림에 전달됨
‘Sub Topology’ 단위로 트랜잭션이 실행되도록 함
36

37. 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

38. 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

39. Omid의 문제점
기본적인 트랜잭션 기능에서 버그가 종종 발견됨
미완성된 기능 존재
프로젝트가 정체되어 있었음
39

40. Storm Topology 기반 구현의 문제점
로직이 여러 Bolt로 분산되어 개발/유지보수가 어려움
40
A =?
A←10
A←20

41. Storm Topology 기반 구현의 문제점
Event와 로직의 연결이 번거롭고 Topology가 커지는 문제
41
Sub
Topology
Sub
Topology
Sub
Topology

42. Storm Topology 기반 구현의 문제점
데이터 포함 Event가 큐 안에서 오래 대기하면 데이터 불일치 발생
A=20 A=10
A=20
Event의 데이터와
저장소의 데이터가
불일치
최신 Event가 처리되면
되지만 앞 작업은 헛수고
42
Cell Value
A 10 20
… …
Cell Value
A 20
… …

43. Cana Tx +
Cana Reactor

44. 44
HBaseSI 논문 기반
Coprocessor 기반
Omid
Storm Topology 기반
Cana Tx
Cana Reactor
Early
2012
Mid
2012
Mid
2013

45. Cana Tx
Omid에서 사용하는 개념만 빌려 새로 개발한 트랜잭션 엔진
Omid의 버그 수정
Omid에서 미완성된 기능 완성
- 서버 이중화
- Garbage Collection
45

46. Cana Tx 서버 이중화
Server1
BookKeeper
WAL
ZooKeeperClient Server2
Server3
Active: Server1
46
Curator
Curator
Curator
Curator를 사용하여 Active-Standby 방식으로 구현

47. Cana Tx 서버 이중화
Curator를 사용하여 Active-Standby 방식으로 구현
47
BookKeeper
ZooKeeperClient
Active: Server3
WAL
Server1
Server2
Server3
Curator
Curator
Curator

48. Cana Tx Garbage Collection
필요성 – 죽은 클라이언트에 의해 남겨진 데이터 제거
Ta
Tb
Tc
Cana Tx Client Cana Tx Server
Ta Tb Tc
HBase
48

49. Cana Tx Garbage Collection
Ta
Tb
Tc
Ta Tb Tc
49
필요성 – 죽은 클라이언트에 의해 남겨진 데이터 제거
Cana Tx Client Cana Tx ServerHBase

50. Cana Tx Garbage Collection
필요성 - Commit된 데이터 중 더 이상 접근되지 않는 것이 발생
TS Val
3
1
TS Val
10
8
3
1
TS Val
21
15
10
8
3
1
Committed
Data
Column A Column A Column A
t
50

51. Cana Tx Garbage Collection
HBase의 데이터 정리하기 – 기본 아이디어
1. Abort된 데이터는 언제 제거해도 무방
2. Commit된 데이터는 읽힐 가능성이 없는 것만 제거해야 함
1) Commit된 데이터를 지워도 되는 기준 타임스탬프를 찾고,
2) 그 이하 구간에서 Abort된 데이터는 모두 제거하고,
3) Commit된 데이터는 칼럼 마다
타임스탬프가 최신인 것 하나씩만 남겨두면 됨
51

52. Cana Tx Garbage Collection
TS Val
23 …
20 …
15 …
10 …
6 …
3 …
1 …
Column A
기준 타임스탬프 = 20
Committed = [3, 15]
Aborted = [1, 6, 10, 20]
Cana Tx
Server
TS Val
23 …
15 …
Column A
Compaction
Tx Snapshot
Coprocessor를 써서 Compaction 도중 데이터를 정리하도록 구현
52

53. Cana Reactor
Event와 로직 연결의 유연성을 높이기 위해 Pub-Sub 모델을 사용
Event는 변경이 발생한 영역 정보만 전달하여 최신성 문제 해결
- 더불어 Event는 데이터 변경만을 나타내도록 자유도를 제한
모든 Event는 Topology에 연결된 큐를 거쳐 전달
트랜잭션은 단일 Bolt 내에서만 실행되도록 제한
- 분산 처리의 이점보다는 로직 개발 편의성이 중요하다고 판단
53

54. Publish-Subscribe 모델
A observes (T1, F1, Q1)
B observes (T2, F2, Q2)
ZooKeeper
Logic A
Logic B
54

55. Cell Value
A 10 20
… …
Cell Value
A 20
… …
Event 처리 시점에
데이터를 저장소에서
읽어옴(최신성 보장)
중복 처리를 하지 않기
위한 방법은 필요함
(예: 어플리케이션에서
diff 체크)
A A
A
55
Event는 변경이 발생한 영역 정보만 전달

56. 모든 Event는 큐를 거쳐 전달
56

57. 트랜잭션은 단일 Bolt 내에서만 실행
Sub Topology Bolt
57

58. 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

59. Cana Reactor
일반적인 Storm 사용 방식과는 다름
- 로직을 단일 Bolt 내에서 실행
- 파생 Event를 스트림이 아니라 큐를 통해 전달
그러나 Storm을 그대로 사용
- 그 동안 Storm을 사용해 와서 익숙함
- Storm이 제공하는 기능을 활용하기 위해
59

60. HBase 테이블 큐
큐가 아니나 Storm Spout에서 쓰는 용어에 맞춰 큐라고 부름
Message Collapsing 기능을 사용하기 위해 개발함
Kestrel 프로젝트가 정체되어 이를 대체할 큐 필요
60

61. HBase 테이블 큐
Message Collapsing
61

62. C1 C2 C3
R1
R2
R3
HBase 테이블 큐
T1 + C1 T1 + C2
salted(R1) + R1 N1
salted(R2) + R2 N2
...
테이블 큐
62
T1 테이블
N1
N2

63. 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 테이블

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

65. Cana Tx 트랜잭션의 성능 특성
65
트랜잭션 연산 비용 = HBase 연산 비용 + 트랜잭션 오버헤드
트랜잭션 오버헤드: 트랜잭션 시작, Commit Query, Commit
트랜잭션 오버헤드는 HBase와 무관
Commit 비용은 Write-Set이 클수록 증가(Conflict 체크 비용 증가)

66. Write-Set 크기에 따른 트랜잭션 성능
66
0
1
2
3
4
5
6
7
0 10000 20000 30000 40000 50000 60000
Latency(ms)
TPS
1
16
32
64
128
# of Columns

67. 적용 사례
2015년 상반기 NAVER 지식인 검색 서비스에 BREW 적용
적용 후 검색 문서 갱신에 소요되는 시간 감소
점차 다른 검색 서비스로 확대 적용 예정
67

68. 남은 과제
Cana Tx
SQL on HBase 적용(예: Apache Phoenix)
HBase 외의 저장소에 적용
Cana Reactor
Storm 대체 플랫폼 고려
68

69. Google Percolator와의 비교
Google Percolator
2010년 논문을 통해 공개됨(link)
증분 인덱싱 시스템 Caffeine에서 사용
Bigtable에 Snapshot Isolation 트랜잭션 제공
Observer Framework를 사용한 Event Notification 기능 제공
69

70. Google Percolator와의 비교
트랜잭션 구현 방식 비교
Cana Tx Percolator
Timestamp Oracle 서버로 구현 서버로 구현
데이터 기록 시점 Write 할 때 Commit 할 때
트랜잭션 정보
저장소
서버의 메모리 +
클라이언트의 캐시
메타 칼럼
Commit 서버에서 처리
Lock을 사용하여
클라이언트에서 처리
70

71. Google Percolator와의 비교
Event Notification 구현 방식 비교
공통점
- 테이블에 Event를 저장하고 테이블을 스캔하여 Event를 추출
- Message Collapsing 기능 제공
차이점
- Cana Reactor: Event 저장 전용 테이블 사용
- Percolator: 데이터 테이블의 메타 칼럼에 Event를 저장
71

72. Omid2
최근 새로운 Omid 코드가 GitHub에 올라옴
기본적인 트랜잭션 처리 방식은 기존과 동일
Commit 관련 정보를 HBase 테이블과 메타 칼럼에 저장
WAL을 더 이상 사용하지 않음
72

73. 유사 오픈 소스 솔루션
HBase 기반 트랜잭션 솔루션
- Haeinsa: Percolator 방식과 유사. DEVIEW 2013
- Tephra: Omid 방식과 유사
- Themis: Percolator 논문에 기반한 구현
Tigon
- Storm과 유사
- HBase 테이블을 사용하여 큐를 구현
- Tephra를 사용하여 트랜잭션 사용 가능
73

74. Q&A

75. Thank You