자바의 희망 구독/서브모델의 Kafka , 대용량처리 관련 캐쉬하는 Redis, 장애예방 CircuitBreaker, 장애대응책 RetryConfig

1. Redis

Redis를 보다보니까 잘 변하지 않는데이터, 즉 약국 검색시에 약국위치 같은 거를 저장하고 있는 것이다. 약국의 이름과 위치는 자주 바뀌지 않는다 그러므로 이런 데이터 중에 자주 조회하는 데이터를 Redis로 캐싱해서 저장하면 궂이 DB까지 안가도 된다. 이렇게 Redis는 비동기 메시지큐로 대규모 병렬 분산처리가 가능해서 메시지큐 역할도 할 수 있다.

2. Kafka

Kafka는 구독/서브 모델이다.

생산자와 소비자가 있고,

Topic(주제)이 있다. 이를 통행 생산자와 소비자 사이에 발생하는 대용량 실시간 스트리밍을 할 수 있다. 이러한 메시지 브로커 역할은 이벤트 기반 아키텍처에 기반한다. 이것은 메시지 큐와 다르게, 라우팅도 할 수 있고 다양한 패턴으로 전송할 수 있다. 보통 블로그나 유투브의 팔로우나, 알람기능 등은 모두 이 메세지 브로커로 통해서 쉽게 가능하고, 특히 이 것 때문에 자바/스프링 의 웹응용어플리케이션은 쉽게 죽지 않을것이다.

이 Kafka는 대규모 데이터 PipeLine을 만들어서 스트리밍을 할 수도 있고, 이러한 대규모 구독/서브 스트리밍을 대체할 만한게 마땅치 않은것으로 알고 있다.

이 Kafka의 이벤트 기반 아키텍처를 살펴보면 이벤트를통해 비동기로 상호작용한다. 이벤트 소싱으로 시스템의 상태를 이벤트의 시퀀스로 저장하여 상태변화를 추적하고 재구성이 가능한 것이다. 보통 프로듀서가 이벤트를 저장하고, 컨슈머가 이벤트를 재생한다. 그리고 이 사이 과정의 로그 수집이 가능하여 추적이 가능한것이 가장 큰 장점이다. 

 

3. CircuitBreaker 

CircuitBreaker는 장애대응을 위한 것이다.

해당 API같은 것이 장애시 상태를 닫아 놓을 수 가 있다. 그리고 반열림 상태로 복구를 확인한다. 복구되었음을 확인하면 연다. 장애시 상태를 닫기 때문에 불필요한 자원 낭비를 막을 수 있다. 또한 장애시 폴백 메서드를 통하여 대체 API를 기획 연동해 놓을 수 있다.

 

CircuitBreaker는 알림기능이 있어 장애 예방 관련 필수 적이다.

4. RetryConfig

RetryConfig는 CircuitBreaker의 반열림 정도의 장애 대응과 비슷하다. API요청이나 작동이 안되면, 최대 시도횟수를 설정하고 안될시에 닫았다고 지속적으로 재시도한다.

재시도가 안되면 경우 로그 등을 남기는 방법을 통해 에러 발생 유무를 확인할 수 있다.

 최근에 자바에서 이런 저런 것들을 보면서 나름 재밌다.