Colin Kang

Kafka를 검토하게 된 계기 :

결론 : 

log데이터를 S3 에 저장하고, AWS EMR로 로그 데이터를 가공하며, 다시 이를 S3에 저장, 

이를 조회는 hive로, 가공은 MR, SPARK로 함. 

그럼 바로 instance에서 log data를 S3에 저장하면 되는데, KAFKA를 쓴 이유는 KAFKA가 이러한 데이터를 block size 단위로 S3에 저장할 수 있기 때문에 partition 내의 데이터 크기가 일정해지고, 

향후 해당 partition 의 데이터를 EMR에서 load시 한번 load로 데이터를 불러 오기 때문에 효율적으로 운영할 수 있다.  

현재 AS-IS의 RDBMS의 한계 :

1. 개별 도메인에서 사용하는 로그성의 데이터 (예를 들어 user activity, (로그인, 저장, 수정, action 들, comment, 등등)을 저장하기 위한 목적 

2. 이러한 데이터는 로그가 많지 않을 경우, RDB에 저장하게 된다. 이유는 도메인 데이터를 기존에 저장하고, 여기에서 확장해서 로그를 더 남기면 infra 관점에서 기존 코드를 그대로 이용할 수 있다. 

3. SQL로 쿼리가 가능하며, sorting이나 통계성 쿼리도 가능하므로, 분석도 가능

4. 이를 계속 사용하지 않는 이유 : 현재는 AWS의 Aurora를 사용하고 있으며, slave 에서 쿼리를 보내면 filter에 index가 있을 경우는 좀 나으나, 아니면 무척느림, group by등의 통계나, 조회는 기대 이상으로 느림

5. RDB는 여전히 매력적인 platform이지만 오라클을 오래사용해서인지, 다른 DB는 그냥 파일 저장소 + index이외에 다른 management기능이 많지 않으니 그냥 공유 데이터 저장소 용도 목적으로만 충실하게 사용하게 됨

6. RDB에 남기는 데이터는 대부분 최소화 하고 key로 mapping한다. 하여 많은 데이터가 누락되고,  msa에서는 빅뱅방식의 대규모 전환은 어려우니, 계속 적으로 기존 schema에 add를 하는 방식이라, null데이터도 많고 중복도 많으며, 정규화 되지 않았으니 데이터가 다 남지도 않으며, 의미가 생각된 데이터가 남아 이후 미래에 분석시점에서 원래의 의미를 추적할 수가 없음

7. RDB를 버려야하는 시점 : (10억건 이상이 넘어 갈 경우, 하지만 3V에 답할 수 있어야지... 하지만, 모든 데이터는 data Interface를 SQL로 operation할 수 있는 곳으로 모여야 데이터에 대한 진입장벽이 낮으므로 business user들이 분석이 가능함 )

RDBMS외 다른 platform검토 

5. MYsql의 한계를 느끼고, 다른 platform을 검토하였음, 

5-1. no-sql : 적합하지 않고, 도메인 업무상 document 분석할거 아니면,  no-sql사용할 일 없으며, api로 언제 복잡한 걸 짜서 데이터를 추출해내나. -> pass

5-2. redshift :  vertica등, 분산 rdb는 기존의 쿼리가 다 돌아간다는 장점이 있지만, computing도 전체 노드에서 수행할 수 있지만, results 가 다 취합이 될때까지는, wait이고,  전체 데이터 search시에는  느려지며, 결국, 저가 장비로 분산 computing이외에는 별다른 merit이 없음, 데이터가 늘어나고, 조회 조건에 데이터가 늘어날수록 더 많은 시간이 걸림. -> pass

5-3. mr : update가 없다는 가정하에서, 데이터를 partition 만 잘해서 넣어 놓으면, mr로 아후 row-level로 데이터를 manipulation할 수 있으며, hive 로도 웬만한 쿼리는 지원하니 많은 용량의 데이터를 관리하기에 적합, 하지만 node와 upgrade 유지보수를 어떻게 관리 -. pass

5-4. AWS EMR : AWS node 관리해주다 보니, 데이터만 넣어 주면 

5. 그럼 다른 곳에 저장해야하는데, 저장하는 것은 어렵지 않으나, 이렇게 저장된 데이터를 어떻게 조회하며, 이후에 내가 원하는 데이터만 찾아내거나 ( search), 통계 목적으로 이러한 데이터를 가공해야하는 것도 고려해야 함.

ElastiSearch를 검토했었어야 했음. 2024.05.31 added

Kafka 작동원리

Producer : 메세지를 메세지 set에 넣은 후  producer에게 send, 메세지 생성하여 broker에게 전달

Broker : 전달받은 메세지를 topic별로 분류하여 저장

Consumer : 특정 broker에 연결하여 topic을 pull로 가져옴.

topic은 하나 이상의 파티션으로 구성됨

Kafka single partition :

Simple storage : topic의 각 partition은 동일 크기의 segment file의 set으로로 구성됨

producer가 message를 publish하면 segment file의 맨 뒤에 append.

성능상의 이유로 설정된 메세지 개수가 채워지면 한번에 append함

memory에는 offset을 가지고 읽어야할 segmentfile의 읽어야할 첫번째 list point

Efficient transfer :

file system page cache. 

multi subscriber system

linux sendfile api (file channel to socket channel)

Stateless broker :

simple time based retention policy to delete a message

can rewind

KAFKA 장점

distributed, multiple message into a single request, 

queue 에 오래 대기해도 됨 ( mq는 consume하지 않으면 메세지로 인해 시스템 다운 가능)

메세지를 메모리가 아닌 파일 시스템에 저장

pull model : 상황에 따라 가능한 용량만큼 pull이 가능

topic 중심 메세지 관리

참조정보 :

http://epicdevs.com/17

Kafka: a Distributed Messaging System for Log Processing : http://notes.stephenholiday.com/Kafka.pdf

https://aws.amazon.com/ko/blogs/big-data/best-practices-for-running-apache-kafka-on-aws/

https://aws.amazon.com/ko/blogs/big-data/building-a-recommendation-engine-with-spark-ml-on-amazon-emr-using-zeppelin/