Go Gradually - Repository

[RabbitMQ Java] RabbitMQ를 이용한 RPC

두 번째 튜토리얼에서 우리는 Work Queue를 사용하여 시간이 오래 걸리는 작업을 여러 워커(worker)에게 분산하는 방법을 배웠다. 하지만 어떤 함수를 원격 컴퓨터에서 실행하고 그 결과를 기다려야 한다면 어떨까?이는 조금 다른 이야기가 된다.이 패턴은 흔히 원격 프로시저 호출(Remote Procedure Call, RPC) 이라고 불린다. 이번 튜토리얼에서는 RabbitMQ를 사용하여 RPC 시스템(클라이언트와 확장 가능한 RPC 서버) 을 만들어보자.분산할 만한 시간이 오래 걸리는 작업은 딱히 없으므로, 임의로 피보나치 수를 반환하는 단순한 RPC 서비스를 예제로 구현할 것이다.클라이언트 인터페이스RPC 서비스 사용 방식을 보여주기 위해 간단한 클라이언트 클래스를 만든다.call이라는 메서드..

[RabbitMQ Java] Pub-Sub 3: 토픽

이전 튜토리얼에서는 로깅 시스템을 개선했다.단순히 브로드캐스팅만 가능한 fanout exchange 대신 direct exchange를 사용하여 선택적으로 로그를 받을 수 있도록 했었다. direct exchange를 사용함으로써 시스템이 개선되었지만, 여전히 한계가 존재한다.바로 여러 기준을 기반으로 라우팅할 수는 없다는 점이다.우리의 로깅 시스템에서는 심각도(severity)뿐 아니라 로그를 발생시킨 소스(source)에 따라서도 구독하고 싶을 수 있다.이 개념은 Unix의 syslog 도구에서 익숙할 수 있다.syslog는 심각도(info/warn/crit...)와 facility(auth/cron/kern...) 모두를 기준으로 로그를 라우팅한다. 이를 지원하는 기법이 바로 토픽(Topic)이다..

[RabbitMQ Java] Pub-Sub 2: 메시지의 라우팅, Direct Binding

이전 튜토리얼 에서는 간단한 로깅 시스템을 구축했다. [RabbitMQ Java] Pub-Sub 모델, 그리고 Exchange이전 튜토리얼 에서는 Work Queue를 생성했다. [RabbitMQ Java] Work Queue 직접 만들어보기와 메시지의 분배 방식이번 튜토리얼에서는 시간이 많이 걸리는 작업을 여러 작업자 간에 분배하는 데 사용할 Wodev.go-gradually.me이를 통해 로그 메시지를 여러 수신자에게 브로드캐스트할 수 있었다. 이 튜토리얼에서는 여기에 기능을 추가해볼 것이다.바로 메시지의 일부만 구독할 수 있도록 하는 것이다.예를 들어, 디스크 공간을 절약하기 위해 중요한 오류 메시지만 로그 파일에 저장하면서도 모든 로그 메시지를 콘솔에 출력할 수 있다.바인딩이전 예제에서는 이미 바..

[RabbitMQ Java] Pub-Sub 1: Pub-Sub 모델, 그리고 Exchange

이전 튜토리얼 에서는 Work Queue를 생성했다. [RabbitMQ Java] Work Queue 직접 만들어보기와 메시지의 분배 방식이번 튜토리얼에서는 시간이 많이 걸리는 작업을 여러 작업자 간에 분배하는 데 사용할 Work Queue(작업 큐)를 만들어 보자. Work Queue(Task Queue)의 핵심 아이디어는 리소스 소모가 많은 작업을 즉시dev.go-gradually.meWork Queue의 기본 가정은 각 작업이 정확히 하나의 워커에게 전달된다는 것이다.이번 파트에서는 ​​완전히 다른 작업을 수행할 것이다.바로, 하나의 메시지가 이를 구독한 여러 컨슈머에게 메시지를 전달하는 형태이다.이 패턴을 "Pub/Sub"이라고 한다. 즉, 다음과 같다.- 생산자/소비자 모델은 하나의 메시지가 하..

[RabbitMQ Java] Work Queue 직접 만들어보기와 메시지의 분배 방식

이번 튜토리얼에서는 시간이 많이 걸리는 작업을 여러 작업자 간에 분배하는 데 사용할 Work Queue(작업 큐)를 만들어 보자. Work Queue(Task Queue)의 핵심 아이디어는 리소스 소모가 많은 작업을 즉시 실행하고 완료될 때까지 기다리는 것을 방지하는 것이다.먼저, 우리는 이어질 작업이 나중에 수행되도록 작업을 예약시킨다.또한 우리는 그 작업을 메시지로 캡슐화하여 큐에 보낼 것이다.백그라운드에서 실행되는 worker 프로세스가 각자 작업을 팝(pop)하고 최종적으로 작업을 실행한다.여러 worker를 실행하면 작업이 작업자 간에 공유되도록 만든다.이 개념은 짧은 HTTP 요청 창 동안 복잡한 작업을 처리하는 것이 불가능한 웹 애플리케이션에서 특히 유용하다.준비 작업이 튜토리얼의 이전 부..

[RabbitMQ Java] 가장 간단한 프로듀서-컨슈머 사용해보기

원래 RabbitMQ 는 할 생각이 없었고, Kafka를 해보려고 했는데Kafka Definitive Guide의 내용이 너무 방대해서 당장 애플리케이션을 만들기 위한 기술에는 부적합하다고 판단했다.따라서, RabbitMQ를 공부해보고자 한다.RabbitMQ는 메시지를 수신하고 전달하는 메시지 브로커이다. 간단하게 우체국에 비유해 보자.우편물을 우체통에 넣으면 우편 배달부가 결국 수신자에게 우편물을 배달할 것이라고 확신할 수 있다.이 비유에서 RabbitMQ는 우체통, 우체국, 그리고 우편 배달부이다. RabbitMQ와 우체국의 주요 차이점은 RabbitMQ는 종이를 다루지 않고 대신 이진 데이터 블롭(메시지)을 수용, 저장, 전달한다는 점이다.RabbitMQ와 메시징 전반에서는 몇 가지 전문 용어를..

조건 분기가 많은가?뭘 하는가를 한눈에 알 수 있는가?이전 흐름으로 돌아올 일이 많은가?주석이 "왜 작성된 코드인지"를 설명하는가?코드가 "무엇을 하는 코드인지"를 설명하는가?conventional한 코드인가?

일반적으로 패키지 네이밍 시 사용되는 용어들의 종류와 그 의미이다.토큰보통 포함되는 위치의미/용도(관례)config최상위 또는 layer스프링 설정 클래스들 (Java Config, 빈 정의, 프로퍼티 등)domainBounded Context 안도메인 모델: 엔티티, 밸류, 애그리거트, 도메인 서비스entitydomain 하위 또는 별도JPA @ Entity 전용 클래스dto / modeldomain 옆계층 간 데이터 전달용 객체 (DTO/VO)repositoryinfrastructure 또는 domain영속성 인터페이스, Spring Data 리포지토리persistence / infra(structure)root layerDB·메시징·외부 API 등 인프라 어댑터serviceapplication la..

DispatcherServlet의 doDispatch() 동작구조DispatcherServlet 구조라이브러리 : org.springframework.web.servlet.DispatcherServletDispatcherServlet도 부모 클래스에서 HttpServlet을 상속받아서 사용하고, 서블릿으로 동작한다.DispatcherServlet → FrameworkServlet → HttpServletBean → HttpServlet스프링 부트는 DispatcherServlet 을 서블릿으로 자동으로 등록하면서 모든 경로( urlPatterns="/" )에 대해서 매핑한다.참고: 더 자세한 경로가 우선순위가 높다. 그래서 기존에 등록한 서블릿도 함께 동작한다요청 흐름서블릿이 호출되면 HttpServle..

캐싱 전략은 읽기/쓰기 정책과 캐시 인프라 구조에 따라 달라진다. 각 전략은 상황에 맞게 선택되어야 하며, 읽기/쓰기 정책 관점, 캐시 인프라 구조 관점으로 구분할 수 있다.1. 읽기/쓰기 정책 관점Cache Aside특징주로 읽기 작업에 적합하다.개발자가 직접 캐시 히트/미스 로직을 구현한다.캐시 장애에 대비한 구성이 가능하다.데이터 업데이트 시 정합성 문제가 발생할 수 있다.동일 쿼리를 반복 수행하는 서비스에 유리하다.Write Back특징쓰기 작업에 적합하다.Cache Store가 Data Store에 Write 부하를 줄이기 위해 Throttling Queue 역할을 수행한다.캐시 장애 시 데이터 유실 위험이 있다.캐시에 변경사항을 먼저 적용하므로 정합성이 확보된다.조회되지 않는 데이터가 불필요하..