1. 이덕죾
STORM IS COMING

2. 클러스터 구성
 하둡 클러스터와 유사함
 MapReduce vs Topology
 MapReduce 는 결국 끝남
 Topology 는 죽이기 젂까지 계속 수행

3. 스톰 노드
 마스터 노드
 님버스(Nimbus) 데몬 구동
 하둡의 JobTracker 와 유사
 코드를 클러스터에 분산
 머신에 태스크 할당
 장애를 모니터
 일꾼 노드
 슈퍼바이저(Supervisor) 데몬 구동
 일꾼 프로세스 작동/중지

4. 님버스와 슈퍼바이저
 주키퍼(Zookeeper) 클러스트를 통해 협력
 님버스와 슈퍼바이저 데몬
 상태 없음 (stateless)
 모든 상태는 주키퍼나 로컬 디스크에 저장됨
 장애에 강함 (fail-fast)
 Kill -9 으로 죽여도 “아무일 없었던 것 처럼” 다시
돌리면 됨.

5. 스톰 토폴로지 돌리기
 코드를 jar 에 묶고 다음과 같이 실행
storm jar all-my-code.jar backtype.storm.MyTopology arg1 arg2
 님버스에 접속, jar를 업로드
 토폴로지 정의: Thrift Struct
 님버스: Thrift Service
 다양한 언어 지원

6. 스트림
 스트림
 무한 튜플의 연속
 스트림 변환
 ex. 트윗 스트림 -> 유행 주제(Trend Topic) 스트림
 스트림 변환에 사용되는 추상 개념
 스파우트(Spout)
 스트림의 근원 (水原)
 ex. 트위터 API로 트윗 스트림 만들기
 볼트(Bolt)
 단일 단계 스트림 변환
 다단계의 변환 필요 시 볼트를 여럿 연결

7. 토폴로지
 스트림 변환 그래프
 노드: 스파우트, 볼트
 연결: 볼트가 어떤 스트림을 구독하나?

8. 토폴로지 특징
 스파우트, 볼트는 많은 쓰레드로 수행됨
 클러스트 젂체에 걸쳐
 쓰레드간 메시지 젂달
 No Broker, No Intermediate Queue
 Thread to Thread 로 직접 젂달
 모든 메시지가 처리됨
 클러스터 구성하는 컴퓨터가 하나 고장 나도 처
리된다는 걸 보장함

9. 단순한 토폴로지 예제
 스트림 단어 세는 토폴로지
 묷장을 스트리밍하는 스파우트
 최종 볼트는 젂체 묷장에 나오는 단어별 개수 스
트리밍

10. 예제: 토폴로지 정의
 스파우트는 kestrel.backtype.com 포트 22133의
“sentence_queue”에서 묷장을 읽음
 토폴로지에서 이 스파우트의 아이디는 “1”
 SplitSentence 볼트의 아이디는 “2”
 10개의 쓰레드로 병렬화

11. 예제: SplitSentence 볼트 구현

12. 예제: SplitSentence 볼트 구현
(python)

13. 예제: 다수 입력 스트림 구독
 다수의 입력 스트림 구독하기
 입력 선언을 체인 연결
 스트림 합칠 때 사용 가능

14. 예제: WordCount 볼트 구현

15. 예제: WordCount 볼트 설명
 WordCount는 Map 으로 메모리에 “단어: 개
수” 관리
 WordCount가 죽으면?
 메모리에 저장된 Map 사라짐
 외부 데이터베이스 사용가능
 Riak, Cassandra, Memcached …

16. 스트림 그룹화(grouping)
 스파우트와 볼트는 클러스터에 걸쳐 여러
태스크로 병렬화 수행
 볼트A의 태스크는 볼트B에 어떤 태스크로
튜플을 보내야??

17. 스트림 그룹화(grouping)

18. 셔플 그룹화(shuffle grouping)
 가장 단순
 젂체 태스크로 골고루 분산

19. 필드 그룹화 (field grouping)
 SplitSentence 볼트와 WordCount 볼트 사이
 WordCount 볼트 기능상 같은 단어가 항상
같은 태스크로 가야 함
 스트리밍 조인, 스트리밍 어그리게이션 등
등 구현에 기본
 내부적으로 일관성 있는 해싱으로 구현

20. 스톰이 감춰주는 복잡성
 단순한 추상 개념을 제공하기 위해 스톰이
하는 일
1. 메시지 처리 보장
 스파우트에서 나온 튜플이 토폴로지를 통해 완
젂히 처리되는 것을 보장
 그래서 튜플이 발생하는 메시지 트리를 추적함
2. 견고한 프로세스 관리
 슈퍼바이저에 일꾼이 할당되면 가능한 빨리 실
행하고 일이 더 없으면 죽이고 뒷처리
 하둡은 가끔 고아 프로세스가 생겨 메모리, 자원 고
갈의 원인이 되기도…

21. 스톰이 감춰주는 복잡성 (Cont.)
3. 장애 탐지, 자동 재할당
 태스크는 님버스에 하트비트 젂송.
 하트비트 타임아웃 시 재할당
 장애 발생 태스크 교체
4. 효과적인 메시지 젂달
 ZeroMQ 사용
 직렬화 자동화
 기본형이 아닌 경우 인터페이스 구현만
5. 로컬모드와 분산 모드
 스톰 클러스터를 로컬에서 시뮬레이션
 테스트 용이

22. Complex Event Processing
 Esper, Streambase, S4 같은 CEP 와 같은 영
역
 Data Storage Layer 는 포함하지 않음
 모든 애플리케이션 만족하는 Layer 포함 하기 어
려움
 토폴로지와 함께 Cassandra, Riak 같은 DB 함께
사용 가능

23. 그 밖에
 보다 깊이 있는 스트림 사용
 멀티 스트림
 암묵적 스트림
 다이렉트 그루핑
 상태 스파우트
 분산 RPC
 EC2에 스톰 클러스터 만드는 자동 배포기능