카프카 인트로

강의 출처 : https://www.youtube.com/watch?v=PtILI6v0ngY

데이터간의 관계가 포커스가 아닌 실시간 데이터에대한 사업적인 니즈가 생김

=> 카프카를 사용하자

카프카 개념

- Message broker

- publish  - consume 구조

- 스트리밍 플랫폼

- 분산 시스템

- 안정적인 스토어

- 많은 처리량

카프카의 특징

1. producer 와 consumer 는 의존도가 없다.

2. broker 에게 topic을 받아서 디스크에 적는다. => 굉장히 안정적이다.

disk를 쓰는데 빠른 이유 : page cache 를 이용해서 데이터를 모았다가 IO 하기 때문에

3. 변경 불가능한 이벤트 로그를 스트림하여 수집

옛날의 데이터 스트림 처리	카프카의 데이터 스트림 처리
Log or Data -> FTP -> hadoop	Log or Data -> Kafka -> hadoop
문제점  Q. FTP로 전송하다 실패하면?  A. 하둡에 전송된 일부를 지우고 재 전송해야한다.  Q. 제 시간안에 파일 덤프가 생기지 않으면?  A. 왜 안생겼는지 물어봐야하고 수동으로 다시 돌려야한다.	장점  전송하다 실패하면 실패 부분부터 재전송이 가능하다.  파일로 만들고 읽어들여서 보내는 것이 아닌 이벤트가 발생하면 바로 전송한다.

메세지 브로커의 필요성

MSA는 필연적으로 서비스간의 통신이 필연적으로 복잡해진다. 

서비스 간의 의존성이 강해져서 결합도도 높아지게된다.

서비스 하나의 장애가 곧 다른 서비스의 장애로 연결된다.

이로인해 서비스 간의 결합도를 끊고자하는 니즈가 생겼다.

이미지 출처 : https://hmjo.tistory.com/156

중재자 패턴의 필요성과 흡사. 마이크로 서비스간의 중재자가 카프카가 됨

=> 카프카를 Backbone으로 두고 서비스들이 카프카와 비동기로 통신하게 바꾸자

=> 하나의 서비스가 장애가나도 다른 서비스는 모른다.

=> 서비스가 장애가 나더라도 서비스를 복구했을 때 카프카에 큐에 있는 Request를 읽어 처리하면 되기때문에 밀린 요청을 처리 가능하다.

카프카 Streams 의 장점

1. 가볍다 : Framework가 아닌 라이브러리이기 때문에 가볍다. 데몬을 돌릴 수 있는 서버만 있으면된다.

2. Consumer group 을 같은걸 쓰면 Scalability, Load balancing, High availability 가 자동으로 된다. 

- Scalability : 그냥 consumer를 늘리기만 하면된다.

- Load balancing : 카프카에서 자동으로 해준다.

- High availability : 특정 consumer가 죽어도 다른 consumer 가 consume하면 된다.

3. 쉽다 : Spring cloud 의 kafka binder를 사용해서 MSA에 카프카를 도입하기가 쉽다.