[인프런 - 아파치 카프카 애플리케이션 프로그래밍]
작년 11월에 이직하여 현재 근무하고 있는 이커머스 회사에서 서비스를 파악하면서 개선해보고 싶은 내용이 있어 Kafka 학습을 시작하였습니다.
개선점
현재 사내에서 상품 정보를 변경 시에 처리하는 로직은 두 가지 방식이 있습니다.
1. 변경이 일어나 상품정보에 수정이 필요한 데이터들을 수정 처리.
2. 스케줄러를 통해 변경된 데이터를 주기적으로 감지 후 처리.
위 두가지 방식의 문제점
1. 단일 프로세스 부하 증가.
- 하나의 프로세스에서 여러 작업을 처리하다 보니 시스템의 부하 증가. 이는 성능 저하, 트래픽이 많은 시기에는 다른 서비스에도 영향을 줄 수 있음.
2. 비효율 적인 자원 사용.
- 스케줄러를 통해 변경된 데이터를 주기적으로 감지하고 처리하는 방식은 변경 감지기 필요한 시점이 아닌데도 불구하고 지속적으로 데이터를 감지하는 작업을 수행해야 하므로 시스템 리소스 낭비됨.
3. 처리 지연.
- 스케줄러 기반 처리는 실시간성으로 처리가 되지 않기 때문에 실시간 가격정보, 상품 정보등이 중요한 이커머스 환경에서는 큰 단점이 될 수 있음.
4. 복잡성 증가
- 하나의 프로세스에서 여러 작업을 처리하는 구조는 코드의 복잡성을 증가시키고 이는 개발 생산성, 유지보수를 하는데 어려움.
Kafka 도입시에 장점
1. 분산 처리.
- 각기 다른 작업을 독립적으로 분산 처리할 수 있음. 하나의 프로세스로 처리가 아닌 각기 다른 분산 처리로 가능.
상품 정보 변경 이벤트
- 상품 테이블 정보 변경
- 전시 테이블 상품 정보 변경
...
2. 실시간 처리.
- 데이터 변경 이벤트가 발생하면 토픽에 기록되고 컨슈머는 이를 실시간으로 처리가 가능, 비효율적인 자원 사용과 처리 지연을 줄일 수 있음.
3. 높은 처리량, 확정성, 영속성, 고가용성
이러한 문제를 해결과 개선을 위해 이벤트 큐를 도입하고 싶어 학습을 하려 합니다.
'MQ' 카테고리의 다른 글
Kafka 학습하기_토픽, 파티션, 레코드 (0) | 2024.06.02 |
---|---|
Kafka 학습하기_브로커와 클러스터 (0) | 2024.06.01 |
Rabbitmq 이해하기 (0) | 2023.05.11 |
RabbitMQ Prefetch Count 란? (closing AMQP connection) (0) | 2023.02.10 |
CentOS 6.x에 RabbitMQ 설치 (0) | 2020.07.27 |