Message Broker를 사용하기 이전 시스템에서 일어날 수 있는 부하에 관해
- 어떠한 시스템에 있어서 소스 시스템(DB와 같은 데이터 집합)이 데이터(API 즉, 컨트롤러정도?)를 타겟 시스템(WEB,APP이 될 수 있으며, 그 이전에 비즈니스 로직단에서도 가능하다. 결국 A시스템에서 B시스템으로 전달하는 것이기 때문)으로 이동한다. 해당 데이터를 가져와 추출, 변환 작업을 거치고 로드한다.
- 회사가 점점 발전하여 소스 시스템이 많아지고 타겟이 되는 시스템도 더 늘어난다. MSA와 같은 분할된 서비스도 있을테고 점점 규모가 커진다. 여기서 공통화로 필요한 데이터 통합문제도 있을테고, 늘어나는 데이터와 여러 서비스에서 거쳐서 받아내는 데이터는 상당해진다. 결과적으로 상당히 복잡해지게 되고 소스시스템이 처리해야할 데이터는 모든 사용자에 비례하여 늘어나기 때문에 과부하가 생길수 바께 없다.
- 각각의 통합을 이루는 시스템은 프로토콜로 사용되는 기술이 바뀌기 때문에 관리가 상당히 어렵다. 데이터를 TCP,HTTP,REST,FTP,JDBC등으로 전송한다. 그리고 그 데이터를 파싱하는 방법들은 Binary, CSV, JSON, Avro 등이 있다.
- 소스 시스템이나 타깃 시스템에서 데이터가 변경되면 모든 소스 시스템은 모든 연겨로가 데이터 추출을 위한 요청으로 인해 부하가 걸리게 된다.
Message Broker를 사용하는 시스템
- Apache Kafka를 이용해 디커플링을 도입한다.
- 디커플링(Decoupling)이란 특정 시스템이나 코드등에서 결합도(의존성이나 관계가 너무 깊게 형성되어서 오히려 역효과를 볼 수 있는것들)가 낮게 짜여진 구조가 좋은 시스템인데 이렇게 결합도를 낮추는걸 디커플링이라 한다.
- 소스 시스템과 타겟 시스템사이에 Kafka라는 메세지브로커를 도입하면서 소스 시스템은 데이터를 생성해서 Kafka에 전달하면서 모든 데이터와 모든 소스 시스템으로 이루어진 데이터 스트림이 되어 있게 된다. 타깃 시스템은 이전에 소스 시스템에만 받아왔던 데이터를 Kafka에서 받아오도록 변경된다.
- 소스 시스템?
- 웹사이트 이벤트, 결제 데이터, 은행 업무, 유저 정보 같은 것들
- 타겟 시스템?
- 데이터 베이스, 분석 시스템, 이메일 시스템, 감사 시스템등
Apache Kafka가 좋은 이유
- 오픈소스 프로젝트로 누구나 무료로 사용이 가능하고 개발이 가능하다.
- 분산형 시스템이고 복구와 시스템 에러에 대한 방지책이 있는 아키텍처로 설계되어 있다.
- 시스템 전체를 끄지 않아도 Kafka를 업그레이드 할 수 있다.
- 수평적으로 확장성이 있기 때문에 시간이 지나면서 브로커를 Kafka 클러스터에 추가할 수 있다. 브로커를 수백개로 확장도 가능하며, 메세지 처리 규모도 엄청난데 1초당 수백만개의 메세지를 처리할 수 있게 된다. 대표적으로 Twitter가 그렇다.
- 레이턴시(대기시간)가 상당히 적은데 종종 레이턴시가 10ms 미만으로 측정된다. 이러한 장점으로 실시간 시스템으로 불른다.
- 사용중인 기업들
- Linkedln, Airbnb, Netflix, Uber, Walmart등이 있다.
Apache Kafka를 어떤 시스템 주로 활용할까?
- 메세징 시스템, 활동 추적 시스템, 다양한 위치에서 메트릭을 수집하는 용도로 사용및 애플리케이션 로그를 수집하는 용도로 사용된다.
- 최근에는 스트림 처리에 사용되고 스트림 API를 통해 시스템 의존성과 마이크로 서비스를 디커플링하는데 사용할 수 있다.
- Spark, Flink, Storm, Hadoop 같은 빅데이터 기술과 통합하는 데 사용된다.
- 마이크로 서비스에서는 발행(pub)/구독(sub)에 사용된다.
- Netflix에서는 Kafka를 사용해서 사용자가 영상을 시청하는 동안에 실시간으로 추천사항을 적용하는데 이용한다.
- Uber에서는 Kafka를 사용해서 사용자, 택시 여행 데이터를 실시간으로 수집하고 수요를 계산하고 예측하는데 사용하며, 실간 요금 계산까지 한다.
카프카는 결과적으로 운송 메커니즘으로만 사용되는데, 엄청난 양의 데이터 흐름을 가능하게 해주기 때문에 많은 데이터를 사용하는 시스템에서는 필요한 시스템이다.