일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 패스트캠퍼스
- MYSQL
- 데이터베이스
- AWS
- 시큐리티
- Kafka
- emqx
- 스파르타코딩클럽
- 쇼트유알엘
- 웹개발
- @jsonproperty
- DB
- 개인프로젝트
- 카프카
- 스웨거
- JWT
- docker
- 프로그래머스
- Spring Security
- java
- WEB SOCKET
- 스프링의 정석
- JavaScript
- 생성자 주입
- EC2
- 항해99
- visualvm
- CentOS
- 남궁성과 끝까지 간다
- Spring
- Today
- Total
목록카프카 (3)
Nellie's Blog
카프카에서 웹소켓으로 메시지를 전송하여 실시간 처리를 해야한다. 지금 나는 백엔드 개발자인데, 프론트에 내가 만든 mqtt 정보 (url, 인증정보, 포트 등) 을 제공해주어야 한다. 백엔드 단에서는 테스트가 모두 완료되었지만, 제공하기 전에, 내가 직접 vue 프론트 프로젝트를 만들어서 내가 보낸 카프카 메시지를 잘 받아오는지 확인하고 싶었다. 백엔드 간단한 코드와 vue 코드를 직접 작성하고, 테스트 하는 과정을 정리했다. 사용한 기술 및 버전 스프링 부트 : 2.5.4자바 : 1.8카프카 : 3.7.0MQTT : 1.2.5 (vue 에서는 5.9.1)vue : 3.2.13 백엔드 코드1. 차량 ID 별로 MQTT 토픽 생성하여 전송먼저 카프카 컨슈머에서 데이터를 param으로 받고,ob..
카프카 브로커를 스케일 아웃 하는 것은 처리량을 늘리기 위한 방법은 아니다. (처리량을 늘리려면 가장 먼저 파티션을 늘려야 한다)카프카는 리더 브로커만 실질적으로 프로듀서와 통신하고 나머지 팔로워 브로커는 복제만 담당하기 때문이다. 하지만 혹시 모를 이슈 상황을 대비해 카프카 브로커를 스케일 아웃 해보았다.현재 카프카 브로커는 3개이며 5개로 스케일 아웃을 하고, 다시 3개로 스케일 인을 해보았다. 카프카 버전 : 3.7.0총 소요시간 : 8시간 (인증세팅이 없으면 1시간도 안걸리는 작업이지만, 카프카 브로커 sasl 인증을 추가해 줄 때 Credential을 자꾸 추가해 주는 실수를 해서... 오래 걸렸다. 한번 주키퍼에 저장된 Credentail은 다시 지정해줄 필요가 없다. 인증 프로세스 숙지..
kafka1, kafka2, kafka3 중에 하나씩 브로커를 죽여보고 메시지를 전송해보려고 한다. 업무에 kafka 를 적용하여 운영할 예정이라, 브로커 서버가 죽었을 때 메시지가 정상적으로 전송 되는지 고 가용성 테스트를 해보기로 했다. 목차1. directTest 토픽의 partition 3들의 복제 상태 확인2. 프로듀서 메시지 전송 확인3. 브로커 하나씩 죽여보기4. 브로커 하나씩 다시 살리기 결론 ✅ 1. directTest 토픽의 partition 3들의 복제 상태 확인현재 토픽의 복제 상태를 확인하는 명령어kafka-topics.sh --bootstrap-server kafka1:9092 --topic directTest --describe --command-config /opt/bitn..