이번 포스팅에서는 카프카의 트랜잭션에 대해 알아보고자 합니다. 저희가 흔히 사용하는 DB 트랜잭션의 경우 여러 DB 작업을 하나의 원자적 단위로 묶어주는 역할을 합니다. 카프카를 사용할때도 여러 이벤트 발행 작업이 하나의 원자적인 단위로 묶일 필요가 있는데, 이때 카프카 트랜잭션을 사용 가능합니다. 카프카 작업 간의 트랜잭션을 통한 원자성 보장 문...

이번 포스팅에서는 카프카 프로듀서가 분산 환경에서 어떻게 신뢰성 있는 데이터 전송을 보장하는지 알아보고자 합니다. 프로듀서 중복 전송 이슈 카프카는 분산시스템이기 때문에 얼마든지 네트워크 이슈로 인한 예외 상황이 발생할 수 있다. 데이터 중복 전송이 발생할 수 있는 하나의 케이스를 살펴보자. 위의 그림과 같이 카프카 프로듀서는 브로커로 메세지...

카프카의 프로듀서를 학습하는 과정에서 내부 동작 흐름을 디버깅 해본 기록을 남기고자 합니다. 해당 글에서 다루고자 하는 카프카 프로듀서의 구조 이번 글에서 다루고자 하는 부분을 먼저 거시적으로 살펴보고 가자. 카프카 프로듀서에서 생성된 메세지는 Serializer와 Partitioner를 거쳐 RecordAccumulator에 batch 단위로 적...

최근 스프링이 제공하는 @Async를 사용한 비동기 작업을 구현하다가, 작업을 실행하는 쓰레드풀에 대해 조금 더 자세히 알아봐야 겠다는 생각이 들었습니다. 이번 글에서는 설정값들을 변경하며 ThreadPoolExecutor를 가지고 놀아본 경험을 기록해보고자 합니다. ThreadPoolExecutor은 무엇인가 ThreadPoolExecutor는 ...

보통 네트워크는 예측할 수 없는 구간이라고 한다. 클라이언트와 서버가 물리적으로 떨어져있는 만큼 중간 노드(ex. NAT, Load Balancer, Switch)들을 경유하고 보안 장비(ex. SG, WAF)를 거치면서 패킷이 필터링 될 수도 있기 때문이다. 또한 서버와 어플리케이션 자체의 상태에 따라서도 에러 처리가 모두 다르다. 문제가 발생하면...

TCP에 대해 학습을 진행하던 중 클라이언트 입장에서의 소켓과 서버 입장에서의 소켓이 동작하는 방식이 달라진다는 걸 알게되었다. 서비스 운영에 있어서 중요한 고려 지점이 될 것이라 생각해 좀 더 깊게 파해쳐보기로 했다. 클라이언트 소켓과 서버 소켓의 차이 시스템의 규모가 확장되고 비즈니스가 복잡해질수록 다른 서버와의 통신도 잦아진다. 이때 다른 서...

프로젝트에 레디스 pub/sub을 적용하면서 내부 구현 방식과 다른 기술과의 차이점이 궁금해졌다. 먼저 내부가 어떻게 생겼는지 파악한 뒤에 구조는 다르지만 비슷한 기능을 제공하는 카프카와 비교 분석을 진행해보자. Redis pub/sub의 내부 동작 원리 레디스가 내부적으로 pub/sub을 어떻게 구현했는지 살펴보자. 레디스 pub/sub 내...

프로젝트에 스프링 캐시를 도입하는 과정에서 어떤 방식으로 내부 구현이 되어 있는지 궁금해졌습니다. @Cacheable 어노테이션을 사용해서 캐시 조회 기능을 사용했을때 어떻게 동작하는지 위주로 분석해보겠습니다. 캐시 호출 시 가장 먼저 동작하는 클래스는 CacheAspectSupport이다. 해당 클래스는 AOP를 사용해 스프링 캐시의 구체 기술을 ...

오늘은 프로젝트에 DB 쓰기락을 적용해서 동시성 문제를 해결한 경험을 공유하겠습니다. 문제 상황 현재 서비스에서는 댓글에 좋아요를 누를 수 있는 기능을 제공합니다. 이때 여러명의 사용자가 동시에 좋아요 버튼을 누르면 동시성 문제로 인해 갱신 손실이 발생할 수 있습니다. 문제 해결 방법 선정 현재 서비스가 단일 서버로 운영된다고 생각해보겠습니...

프로젝트를 리팩토링하면서 좋은 구조는 무엇일지에 대해 고민을 많이 했습니다. 전체 구조를 여러번 수정하면서 제 나름대로 내린 결론은 확장에 열려있고 적절한 격리를 통해 유지 보수 시 코드 변경 지점을 최소화 하는게 좋은 구조라 생각하게 됐습니다. 지금부터 제 생각을 프로젝트에 녹여본 경험을 공유하고자 합니다. 멀티 모듈 구조 도입 Melly 프...