유실 없는 스트림 처리

1. 유실 없는 스트림 처리
SK플래닛
엄 태 욱
2016-09-26
SK텔레콤 종합기술원 빅데이터 심화 과정

2. http://readme.skplanet.com/?p=12465

3. 데이터와 비즈니스가 끊임없이 변하기 때문이다.
- Amit Sela, Apache Beam Committer
Why? Real-time? Stream?
https://twitter.com/gwenshap/status/740208148263403520
https://twitter.com/ConfluentInc/status/725110136562393088
http://conferences.oreilly.com/strata/big-data-conference-ca-2015/public/schedule/detail/42390
데이터는 실시간으로 태어나기 때문에,
실시간으로 처리되어야 한다.
- Mike Spicer, IBM
실시간은 Big 또는 Fast에 관한 것이 아니라, Big 그리고 Fast에 관한 것이다.
한 번 실시간 빅데이터를 경험한 사람은 계속 더 빠른 빅데이터를 원한다.
-Anil Gadre, MapR

4. https://voltdb.com/sites/default/files/real-time-data-report.pdf 2015 Real-time Data Report by VoltDB
실시간 데이터 분석 효과에 대한 같은 생각
실시간 데이터 분석 능력에 대한 다른 생각

5. 실시간(Real-time) 처리
응답시간 빠른거?
근데 얼마나 빨라야?
마감 시간(Deadline) 준수
1초 이내?300ms 이내?
https://www.soasta.com/blog/23-stats-mobile-web-performance-monitoring/
https://en.wikipedia.org/wiki/Real-time_computing
한 3초 넘으면 준 실시간(Near Real-time)?
Hard
Firm
Soft

6. 빨라? 느려?
Stream 처리 ⇔ Batch 처리
Unbounded Bounded
Data Data
X X
끊임없이 한 번
https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101
https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102

7. Micro-batch
Unbounded Data 작게 쪼개서
작은 배치 처리를
끊임없이 수행

8. 앞으로는 ASAP 같은 “실시간으로”라고 요청하지 말고,
대략적이더라도 목표 응답 시간을 말해 주세요.
목표 응답 시간의 기준은
고객을 잃기 전까지
입니다.
실시간 처리: 데이터 처리 목표
스트림 처리: 데이터 처리 방식
http://bigdatapage.com/4-really-real-meanings-of-real-time/

9. https://tsicilian.wordpress.com/2015/02/16/streaming-big-data-storm-spark-and-samza/
• 배치 작업 Spark과 코드 공유
• REPL(Read-Eval-Print Loop) 제공
• YARN 사용
• 개발 활성화
• Scala
• Exactly-once 보장• 실시간 목표 10초 이내

10. 사용하는 분? 절반이 손듦
좋아하는 분? 절반이 손듦
https://twitter.com/jaykreps/status/568499167686995969
https://twitter.com/miguno/status/568503505113247744
Storm vs. Spark Streaming
좋아하는 분? ...
사용하는 분? 손 하나만 남음

11. https://databaseline.wordpress.com/2016/03/12/an-overview-of-apache-streaming-technologies/
오픈소스 스트림 처리 기술 비교표 (2016-03)

12. https://databaseline.wordpress.com/2016/03/12/an-overview-of-apache-streaming-technologies/
오픈소스 스트림 처리 기술 비교표 (2016-05)

13. https://twitter.com/bigdata/status/714094657722929152

14. 모두 카프카를 사용하기 때문에,
같은 데이터로 쉽게 비교할 수 있다.
Apache Kafka
Oracle DB are your vital organs,
Apache Kafka circulates information to the rest of the body
https://twitter.com/gwenshap/status/715660577926852608
https://twitter.com/gwenshap/status/760579304048631808
Good thing they all use Kafka,
so you can compare them easily on the same data :)
오라클DB는 당신의 생명에 중요 장기이고,
아파치 카프카는 몸 전체에 정보를 순환시킨다.

15. 대용량 데이터 처리
분산 처리 (커단란 건 나눠서)
장애 발생은 일상 무시 (아몰랑! 안중요해)
재작업 성공할 때까지 다시
앞에꺼 취소하고 다시

16. 전송 보장 방식
분산 환경에서 장애로 인해 부분 전송 성공 가능성
At-most-once(최대 한 번): 장애 무시 ⇨ 유실
At-least-once(적어도 한 번): 재시도 ⇨ 중복
Exactly-once(딱 한 번): 유실/중복 없음 ⇨ 어려움

17. 분산 시스템에는 두 가지 어려운 문제가 있다.
2. Exactly-once 전송
1. 메시지의 순서 보장
2. Exactly-once 전송
https://twitter.com/mathiasverraes/status/632260618599403520
Exactly-once 보장
There are only two hard problems in distributed systems:
2. Exactly-once delivery
1. Guaranteed order of messages
2. Exactly-once delivery

18. https://lobste.rs/s/ecjfcm/why_is_exactly-once_messaging_not_possible_in_a_distributed_queue/
Exactly-once delivery is impossible.
Exactly-once processing of messages is possible
if the processing can be made idempotent.
Exactly-once 보장
Exactly-once 전송은 불가능하다.
오직, 데이터 처리가 멱등(idempotent)할 때만,
메시지의 Exactly-once 처리가 가능하다.

19. Exactly-once 보장
재작업 성공할 때까지 다시
앞에꺼 취소하고 다시
Idempotent exactly-once
: 몇 번을 실행해도 한 번 실행한 결과와 같음(멱등성)
= 덮어 써도 무방
= 중복 가능한 At-least-once ⇨ Exactly-once
Transactional exactly-once
: 트랜잭션을 지원한다면 실패시 roll-back 가능
트랜잭션을 지원하는 DB 쓰기에 적합

20. YARN
HDFS
Rake
Server
Query
Cache
AppServer SQL
thin
JDBC client
Apache
Kafka
Rake
Library
Rake
API
Logs
LogAgent
HTTPS
Phoenix
JDBC client
(select)
JDBC client
(upsert)
Kafka
Consumer
Kafka Producer
Collector
BLE 로그 처리
하루 1억 5천만건
10초 micro-batch
초당 최대 7천건

21. YARN
HDFS
Web Server HQL
Apache
Kafka
Kafka
Consumer
Kafka Producer
Kafka
Producer
Collector
YARN
Hive
Tez
11번가 웹로그 처리
하루 3억건
5초 micro-batch
초당 최대 8천건

22. 스트림 처리는 프레임웍이 아니라 디자인 패턴
https://www.oreilly.com/ideas/questioning-the-lambda-architecture
Lambda Architecture
http://lambda-architecture.net/
Kappa Architecture
http://kappa-architecture.com/
결과적으로 기술 부채

23. http://www.slideshare.net/KostasTzoumas/apache-flink-at-strata-san-jose-2016

24. http://www.slideshare.net/stephanewen1/continuous-processing-with-apache-flink-strata-london-2016

25. 데이터 수신, 처리, 저장 단계 중
어느 한 부분이라도 Exactly-once를 보장하지 않으면,
전체는 Exactly-once를 보장하지 않는다.
데이터 원천부터 비즈니스 행동(의사 결정)까지
목표 응답 시간 내에 반응해야만 할 때,
실시간 시스템 구축은 기술 경쟁력을 갖는다.
데이터 파이프라인 중에 배치 처리 구간이 있으면,
아무리 빠르고 정확한 스트림 처리를 구현해도 의미가 퇴색된다.

26. 스트림 처리 기술은 빠르게 발전하고 있어
오늘 내용은 1년 이내에 옛날 방식이 됩니다.
따라서 지속적으로 기술 동향을 파악하고,
실제 개발하고 운영해 보아야
비로소 실력이 쌓입니다.

27. Questions?Questions.foreach( answer(_) )