Dean83

이론부분은 https://dean83.tistory.com/412 이부분을 보면 된다. 별도로 build.gradle에 추가할 필요는 없다. (대부분 starter-web은 이미 추가 되어 있다) Async 및 TaskExecutor 설정이 부분은 https://dean83.tistory.com/393 에서 자세히 다루었다.@Configuration@EnableAsync@EnableSchedulingpublic class AsyncConfig { @Bean("sseExecutor") public TaskExecutor sseTaskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); e..

WebSocket과 달리, SSE 는 http를 그대로 이용하며, 단방향 통신을 한다. 따라서 서버 -> 클라이언트 로 일방적인 전송을 한다. Http 를 이용하는것이 좋은게, 왠만한 방화벽은 Http는 허용하기 때문이다. WebSocket의 경우 Http Upgrade를 이용하므로 방화벽 설정을 별도로 해 줘야 할 수도 있다. 기본적으로 Async를 통해 실행되는게 좋으므로, Task Executor 설정 등을 별도로 해주는게 좋다. SSE 특징연결 정보(SseEmitter)를 메모리에 저장해 놓고 있고, 유실 시 복구가 불가능 하다.Emitter 자체는 복구가 불가능 하나, 이벤트는 DB 혹은 kafka 등을 통해 복구 가능하다.연결이 끊기면 웹브라우저에서 재접속을 자동으로 요청한다.SSE는 웹 뿐..

WebSocket 은 양방향 실시간 통신으로서, 지속적인 연결이 필요할 경우 사용한다.규모가 커질 경우 외부 브로커를 별도로 두어 같이 운용하는경우가 대부분이다.STOMP는 개발을 빨리 해야 할 때, 메세지 라우팅/권한 제어가 중요한 경우에 사용하고, 순수 WebSocket은 초저지연, 대규모 fan-out이 필요한 경우 적합하다. 예를들어, 채팅, 알림, 협업툴의 경우 STOMP를 쓰고, 게임, 실시간 시세, 대규모 push 같은 경우는 순수 WebSocket을 쓴다. STOMP 장점@MessageMapping, @SendTo, SimpMessagingTemplate 등 Http Controller를 쓰듯 편하게 쓸 수 있다.RabbitMQ 같은 메세지 브로커와 궁합이 잘 맞는다.단점헤더가 많고, 텍스..

이론적인 부분은 이곳에서 확인 가능하다. https://dean83.tistory.com/411단일서버일 경우 WebSocket에 대한 정보를 Map 이나 ConcurrentMap을 통해 저장하지만, 서버가 다수일 경우 Redis를 이용한다.또한, 별도로 DB 에 데이터를 저장해야 되는 부분이 반드시 생기므로, Entity, Service, Repository를 구현해야 한다. 중요한 것은, WebServerHandler 구현체에서 바로 Repository를 주입받아 접근하지 않고, Service를 주입받아 활용한다. 여기서는 DB 에 저장 / 읽기 부분은 제외하고 정리하며, 대용량 및 빠른 경우를 상정하여 ProtoBuf를 이용하였다.실제로 ProtoBuf를 이용하는 경우는 대용량, 초고속일 경우를 제..

Outbox의 경우 오류를 알아채기가 쉽지 않다. 왜냐하면 DB에 failed 항목이 계속 누적이 될 뿐, 실제 서비스 동작은 이상 없는것처럼 보일 수 있기 때문이다. 따라서 모니터링이 필요하다. 이전 글 https://dean83.tistory.com/407 과 연계되는 부분이 있다. OutboxMetirics 컴포넌트@Component@RequiredArgsConstructorpublic class OutboxMetrics { private final MeterRegistry registry; private final AtomicInteger pendingCount = new AtomicInteger(0); @PostConstruct void init() { ..

이론적인 부분은 https://dean83.tistory.com/406 를 참조하면 된다. 간략히 요약하면, Outbox 패턴은 DB + kafka 조합시 한쪽의 오류로 인한 정합성이 깨지는걸 방지한다. Outbox 테이블에 kafka로 보낼 메세지를 담아두고, 배치작업을 통해 db 내용을 불러와 kafka 메세지로 전달해준다. application.yaml 에서 프로듀서 설정 부분spring: kafka: producer: bootstrap-servers: localhost:9092 acks: all retries: 5 enable-idempotence: true properties: max.in.flight.requests.per.co..

Kafka는 비동기 + 배치 동작으로 빠르게 이벤트를 저장하여, MSA 에서 많이 사용된다. 특정 서버에서 작업이 끝났을때 이벤트 로그를 등록 및 기록하고, 원하는곳에서 이 이벤트 로그를 확인함으로서 비동기로 분산되어 있는 서버간의 작업을 유기적으로 수행하도록 해준다. RabblitMQ 와 큰 차이점이라고 하면, Kafka는 이벤트를 로그로서 영구저장하고, RabblitMQ 는 메세지큐 로서 메세지를 영구 저장하지 않고 소비 후 삭제한다. RabbitMQ가 실시간성은 매우 좋은 반면, 대량의 메세지 처리에는 Kafka가 좋다.또한 Kafka 는 메세지를 컨슈머가 가져가는 형태인 반면, RabbitMQ의 경우 브로커가 push를 통해 전달하는 형태이다. Kafka의 구성 크게 Producer, Consu..

이론적인 내용은 https://dean83.tistory.com/406 여기를 참조. 이 글에서는 기본적으로 로컬PC 기준으로 설명한다.기동 순서는 Kafka 실행 -> 토픽 생성 -> 서버실행 순이다. Kafka 설정에서 topic 자동생성을 했다면 상관없지만, 실서버에서는 수동생성을 하므로 순서를 지켜야 한다.서버 실행시 topic이 없다면 실행이 안되므로, CI/CD 혹은 커맨드를 통해 미리 생성해야 한다. Kafka 및 KafkaUI docker-compose 설정 예시 version: '3.8'services: kafka: image: bitnami/kafka:3.7 container_name: kafka ports: - "9092:9092" environment..

캐시가 만료된 시점에 다수의 요청이 발생했을 경우, 캐시가 미스되어 DB 접근으로 접속이 몰리는 현상을 말한다. 대형 서비스는 순간적으로 몰리는 트래픽도 많기 때문에 이 경우 DB 장애 및 전체 서비스 마비가 올 수도 있다. 그게 아니더라도 응답속도 지연 등 문제가 발생한다.특히 DB에 부하를 많이 발생하는 작업이나, CPU 사용량이 많은 서비스일 경우 그 데미지는 더 크다. 이를 해결하기 위해서 여러 해결법이 있다. 1. sync 옵션동일 요청에 대해 한 요청만 DB 에 요청하고, 나머지 요청은 대기한다. 이후, 한 요청이 완료되어 cache 에 갱신하게 되면 나머지 요청은 갱신된 캐시를 통해 결과를 리턴 받는다.Cacheable 에서 sync = true 설정을 한다. 2. Cache warmi..

SpringBoot 의 actuator를 이용하여 모니터링을 구축하는 하나의 예 이다. 물론 스프링부트가 아닌 항목과도 연계를 하여 모니터링을 할 수 있다. (대표적으로 Redis exporter 를 이용하여 Redis 모니터링) 이 글은 스프링부트 3.5.7 버전 기준으로 작성되었다. (다른버전에선 actuator - prometheus 동작을 위해 추가 설정이 필요할 수 있음) 요약하자면SpringBoot actuator + Micrometer 가 데이터를 제공 (actuator/prometheus uri 제공)Prometheus 가 해당 데이터를 수집 (외부)Grafana 가 이를 이용해 시각화 (외부) Springboot Build.gradle 추가actuator와 prometheus용 Micro..