PREVIEW OF STORM
이덕준
Storm: profile
 BackType 에서 만든
 스트림 처리 시스템
 실시간
 분산
 BackType을Twitter 가 인수
 오픈 소스화 예정 (‘11. sep. 19th)
 Strange Loo...
Opening Question
 Reach 를 구하시오!
 Reach?
 어떤 특정 URL이 트위터를 통해 몇 명에게 노출
되었을까?
Reach 구하는 방법
1. 특정 URL을 트윗한 사람을 모두 구한다.
2. 그 사람의 모든 팔로워(Follower)를 구한다.
3. 팔로워 레코드를 단일화한다.
4. 센다.
Reach 구하는 비용
 비용
 수천 건의 데이터베이스 호출
 수천만 건의 팔로워 레코드 처리
 분산 처리 필수
 Strom 으로 하면 몇 초 이내
 대부분 URL은 일 초 이내
Storm more?
 실시간 처리 분야의 하둡
 하둡: batch processing
 스톰: realtime processing
 주의
 여기에서, Realtime 은 Mission-Critical, Saf...
Realtime Processing?
 전통적인 Realtime Processing
 큐, 일꾼(Worker) 의 그래프
 일꾼은
 큐에서 메시지를 가져옴
 메시지 처리 후
 데이터베이스 갱신
 또는 새로운...
Realtime Processing은 어려워
 신경 쓸 일 많아
 큐와 일꾼이 잘 돌고 있을까?
 결함에 취약
 메시지 흐름 관련 복잡성
 메시지를 어디에 보내야?
 어디에서 메시지를 받아야?
 작업을 어떻...
Storm은?
 처리 로직 구현에만 집중하세요
 자동으로 머신 클러스터에 병렬화 해줌
 메시지 전달 추상화
 Stream,Topology, Spout, Bolt
Storm의 특징
1. 단순성
 병렬 배치 처리 MapReduce로 쉽게(하둡)
 실시간 처리의 복잡성을 낮춤(스톰)
2. 다양한 프로그래밍 언어 지원
 스톰은 Clojure로 작성
 JVM에서 돌아감
 Jav...
Storm의 특징 (cont.)
3. 장애 허용(Falut-tolerant)
 스톰이 토폴로지 감시
 뻗은 일꾼 자동으로 감시, 재시작
4. 확장성
 모든 연산이 병렬적
 컴퓨터만 사서 추가하면 됨
5. 신뢰성
...
Use Cases
 스트림 처리
 전통적인 Use Case
 Continuous Computation
 Continuous Query 결과를 Streaming
 ex. 지난 몇 분간 가장 많이 RT 된 사용자 ...
Upcoming SlideShare
Loading in …5
×

스톰 미리보기

1,239 views

Published on

실시간자료분산연구회 발표자료

Published in: Technology
  • Be the first to comment

스톰 미리보기

  1. 1. PREVIEW OF STORM 이덕준
  2. 2. Storm: profile  BackType 에서 만든  스트림 처리 시스템  실시간  분산  BackType을Twitter 가 인수  오픈 소스화 예정 (‘11. sep. 19th)  Strange Loop 에서
  3. 3. Opening Question  Reach 를 구하시오!  Reach?  어떤 특정 URL이 트위터를 통해 몇 명에게 노출 되었을까?
  4. 4. Reach 구하는 방법 1. 특정 URL을 트윗한 사람을 모두 구한다. 2. 그 사람의 모든 팔로워(Follower)를 구한다. 3. 팔로워 레코드를 단일화한다. 4. 센다.
  5. 5. Reach 구하는 비용  비용  수천 건의 데이터베이스 호출  수천만 건의 팔로워 레코드 처리  분산 처리 필수  Strom 으로 하면 몇 초 이내  대부분 URL은 일 초 이내
  6. 6. Storm more?  실시간 처리 분야의 하둡  하둡: batch processing  스톰: realtime processing  주의  여기에서, Realtime 은 Mission-Critical, Safety- Critical 분야의 예측가능성, 결정성을 다루는 realtime 과 다름
  7. 7. Realtime Processing?  전통적인 Realtime Processing  큐, 일꾼(Worker) 의 그래프  일꾼은  큐에서 메시지를 가져옴  메시지 처리 후  데이터베이스 갱신  또는 새로운 메시지를 다른 큐로 전달
  8. 8. Realtime Processing은 어려워  신경 쓸 일 많아  큐와 일꾼이 잘 돌고 있을까?  결함에 취약  메시지 흐름 관련 복잡성  메시지를 어디에 보내야?  어디에서 메시지를 받아야?  작업을 어떻게 배치해야?  큐는 어떻게 배치해야?
  9. 9. Storm은?  처리 로직 구현에만 집중하세요  자동으로 머신 클러스터에 병렬화 해줌  메시지 전달 추상화  Stream,Topology, Spout, Bolt
  10. 10. Storm의 특징 1. 단순성  병렬 배치 처리 MapReduce로 쉽게(하둡)  실시간 처리의 복잡성을 낮춤(스톰) 2. 다양한 프로그래밍 언어 지원  스톰은 Clojure로 작성  JVM에서 돌아감  Java, Clojure는 물론 Ruby, Python도 지원  스톰과 통신하는 라이브러리만 작성해주면 어 떤 언어든 OK
  11. 11. Storm의 특징 (cont.) 3. 장애 허용(Falut-tolerant)  스톰이 토폴로지 감시  뻗은 일꾼 자동으로 감시, 재시작 4. 확장성  모든 연산이 병렬적  컴퓨터만 사서 추가하면 됨 5. 신뢰성  모든 메시지가 적어도 한번은 처리됨 6. 속도  처리 속도를 염두에 둔 구현  ZeroMQ 사용
  12. 12. Use Cases  스트림 처리  전통적인 Use Case  Continuous Computation  Continuous Query 결과를 Streaming  ex. 지난 몇 분간 가장 많이 RT 된 사용자 50명  분산 RPC  Invocation 을 기다리는 intense query  ex. Reach 구하기

×