JADE's Repository

커피와 홍차 클래스를 구현해보면 다음과 같이 추가할 수 있다.public class Coffee { void prepareRecipe() { boilWater(); brewCoffeeGrinds(); pourInCup(); addSugarAndMilk(); } public void boilWater() { System.out.println("물 끊이는 중"); } public void brewCoffeeGrinds() { System.out.println("필터를 통해서 커피를 우려내는 중"); } public void pourInCup() { System.out.println("..

이전 포스트: [Spring AMQP(RabbitMQ)] 안전하게 메시지를 전달하기 위한 설정 - Consume  Dead Letter Queue는 실패하거나 전달되지 못한 메시지를 보관하는 queue이다.Dead Letter Exchange & Dead Letter Queue 생성메시지가 전달에 실패하면, 실패한 메시지는 DLX(Dead Letter Exchange)로 라우팅된다.public static final String topicExchangeName = "spring-boot-topic-exchange"; public static final String dlqExchangeName = topicExchangeName + ".dlx"; public static final String queu..

이전 포스트: [Spring AMQP(RabbitMQ)] 안전하게 메시지를 전달하기 위한 설정 - Publish안전하게 메시지 Consume 하기 위한 설정우선 auto-ack를 false로 설정해주어야한다.auto-ack가 true로 설정되면 다음과 같이 동작한다.queue로 메시지 publishconsumer로 메시지 전달consumer는 queue에게 ack 리턴queue에서 메시지 삭제이때 실제로 consumer에서 메시지를 처리하는 시간이 더 길기 때문에 queue에서의 메시지가 먼저 삭제된다. 따라서 consumer에서 문제가 생겼을 경우 메시지 유실이 발생하게된다. 그리고 메시지 전달에 실패했을 경우는 DLQ(Dead Letter Queue)로 가도록 해야한다.코드 적용Spring AMQP에..

이전 포스트: [Spring AMQP(RabbitMQ)] 안전하게 메시지를 전달하기 위한 설정 - Durability안전하게 Publish하기 위한 설정메시지는 메모리에 저장되며 재실행되거나 라우팅할 수 없는 경우 유실될 수 있다.mandatory를 true로 설정해주면 queue에 메시지가 추가되었을 경우 success를 반환하고 라우팅되지 않을 경우 error를 반환한다.persistent를 true로 설정해주면 메시지가 disk에 저장된다. (동시에 RAM에 저장됨)open channel에서 waitForConfirmsOrDie을 호출하여 메시지가 정상적으로 확인되었는지 알 수 있다. Spring AMQP에서는 ReturnsCallback 또는 ConfirmCallback을 사용할 수 있다.또한 l..

durable이란 broker가 재시작되어도 queue가 삭제되지 않고 남을 수 있게 만드는 속성이다.(RabbitMQ를 Docker 컨테이너로 올려 실행했다.)Non-Durabledurable을 false로 설정할 경우 broker가 재시작되면 queue가 삭제될 것이다. 실제로 그런지 한 번 확인해보았다.Broker 실행broker를 처음 실행하면 아래처럼 queue가 아무것도 없을 것이다.백엔드 서버 실행Spring Boot로 개발한 백엔드 애플리케이션을 실행하게되면 다음과 같이 설정한대로 queue가 생성된다.Broker 재실행broker가 재실행할 때 두 가지 경우를 생각해볼 수 있다.백엔드 서버가 실행되는 중 Broker가 재실행되는 경우백엔드 서버가 다운되었을 때 Broker가 재실행되는 경..

문제 상황팀 프로젝트에서 경매 기능이 추가되면서 여러 사용자가 하나의 경매에 입찰할 수 있도록 기능을 구현하게 되었다. 먼저 경매(auctions) 테이블은 다음과 같이 정의되었다.CREATE TABLE `auctions` ( `id` bigint AUTO_INCREMENT NOT NULL, `member_id` bigint NOT NULL, `file_name` varchar(255) NOT NULL, `title` varchar(255) NOT NULL, `content` text ..

문제Nginx는 기본적으로 Upstream으로 요청을 보낼때 HTTP/1.0 버전을 사용한다. 따라서 Nginx에서 WAS로 요청을 보낼 때 HTTP/1.0을 사용하여 Connection: close 헤더를 사용하게 된다. 하지만 SSE(Server Side Event) 또는 WebSocket은 지속 연결이 필요하기 때문에 HTTP/1.0을 사용하게되어 Connection 요청 후 바로 끊기게된다.해결SSE(Server Side Event)의 경우 다음과 같이 지속 연결이 될 수 있도록 Nginx에 Http Version과 Connection 헤더를 keep-alive 로 설정해주면 해결된다.proxy_set_header Connection 'keep-alive';proxy_http_version 1.1..

음료(Beverage)라는 추상 클래스에 여러 메뉴들을 서브 클래스로 구현한다고 하면 다음과 같이 HouseBlend, DarkRoast, Decaf, Espresso 등을 추가할 수 있다.  하지만 스팀 우유나 두유, 모카와 같은 첨가물이 추가되면 메뉴가 달라지고 추가해야하는 클래스가 무수히 많아지게된다. 추가로 커피 가격까지 달라지게된다. 이와 같은 문제를 해결하기위해서 Beverage 클래스에 첨가물에 대한 정보를 추가해주고 주 메뉴들만 서브 클래스로 구현해주도록 할 수 있다.하지만 위와 같이 구현해주면 첨가물의 가격이 변경되었을 경우 기존 코드를 수정해야한다는 문제와 첨가물의 종류가 추가되면 메소드들도 추가/수정되어야될 수 있다. 그리고 만약 아이스티와 같이 메뉴가 추가될 경우에 whip이 필요없..

SSE(Server-Sent Events)를 사용하여 서버에서 클라이언트로 알림 메시지를 전송할 경우 아래와 같이 단순하게 구현할 수 있다.이때 서버는 저장해둔 SseEmitter를 사용하여 클라이언트에게 메시지를 전송한다. 하지만 이후 서버가 추가되어 여러 대가 될 경우 다음과 같은 문제가 발생한다.클라이언트가 4개, 서버가 3대일 경우 다음과 같은 순서로 동작한다고 해보자.Client A는 Server A에게 SSE 연결을 요청Client A는 댓글 작성과 같은 이벤트 발생Server B에서 Client A의 이벤트를 처리Server B에서 Client A로 알림 메시지를 전송하기위해 SseEmitter를 조회Client A에 대한 SseEmitter는 Server A에 저장했지만 이벤트를 Serve..

메모리 확인Redis를 Standalone으로 Docker Container에 올리고 docker stats로 메모리를 확인해보았을 때 다음과 같았다.  그리고 로그인 후 유저 정보를 캐싱하고 캐싱한 키와 값이 메모리를 얼마나 사용하고 있는지 확인해보았다.  저장된 유저 정보마다 할당되는 크기가 다르겠지만 임의로 하나의 유저 정보가 사용하고 있는 메모리를 확인해보았을 때 1046byte(1.046kb) 만큼 사용하는 것을 확인할 수 있었다. ElastiCache의 데모 옵션(0.5 GiB)을 기준으로 계산해보면 약 50만명의 유저 정보를 저장할 수 있다. 하지만 Redis의 메모리는 데이터를 저장하는 것 이외에도 다양한 기능을 통해 사용되기 때문에 동시 접속 사용자가 50만명보다 적더라도 충분히 OOM(..