![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/p251b/btszcRQwNIT/EvY7W8HYEtYEovJpApC4i0/img.png)
기본적으로 Aurora를 사용한다면 마스터 노드는 쓰기(update) 등을 담당하고, 슬레이브 노드는 읽기를 담당한다. Aurora RDS postgres를 사용하던 중 마스터 노드가 failover 되었으면 슬레이브 노드 중 장애 조치 우선순위가 높은 노드가 마스터 노드가 된다. 문제는 failover 되었을 경우 기존에 WAS와 맺어놓은 컨넥션들은 수동으로 이를 탐지하지 못하고 이전의 마스터 노드와 TCP 연결을 맺어놓은 컨넥션들은 이전의 마스터 노드로 요청이 간다. 그렇다면 무슨 문제가 발생할까? 읽기 노드에서는 UPDATE를 처리할 수 없다는 에러를 맞이하게 된다. 따라서 Failover에 대해 어떻게 대응할 것인지에 대한 전략이 필요하다. AWS 공식문서에는 다음과 같은 방법을 권유하고 있다. ..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/b6U7dk/btspgnEYIxU/l1AlNH1UgriSye8KvdJuK0/img.png)
{ "timestamp": "2019-02-15T22:24:41.275+0000", "status": 404, "error": "Not Found", "message": "No message available", "path": "/123", "nice": "springboot" } 에러 처리는 애플리케이션 개발에 있어 여러 오류를 빠르게 파악하고 수정하는데 있어 유용하게 사용되어 의무가 아닌 필수가 되었다. 기본적으로 스프링부트 애플리케이션을 만들고 실행하면 404 Not Found에 대해서 다음과 같은 화면을 볼 수 있다. 같은 요청 localhost:8080/123에 대해서 포스트맨을 사용하여 JSON 응답값을 확인해보면 다음과 같다. { "timestamp": "2023-08-14T22:21:24...
MDC란 Mapped Diagnostic Context 의 약자로 일부 특징의 데이터를 Map 형태로 저장하는 메커니즘으로 흔히 사용하는 slf4j, logback, log4j2 등 Logger에서 MDC를 제공해준다. MDC : 현재 실행중인 쓰레드에 메타 정보를 넣고 관리하는 공간 MDC는 로그에 메타데이터를 맵으로 관리할 수 있게 해준다. 쉽게 말하자면 MDC 는 로그에 컨텍스트를 남기는 용도라고 생각하면 된다. 그렇다면 멀티 쓰레드 환경에서 요청 쓰레드 별로 식별가능한 로그를 남기는 것이 가능하다. MDC.put(k,v) , MDC.get(k) 를 이용하여 저장하고 읽을수가 있다. map과 같은데 특징은 이 map이 쓰레드 단위로 생성된다. Filter, Interceptor, AOP 등을 이용하..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/cem8pk/btspk8Uj1bA/gg9iFchZ7V5tMBWW3oAAek/img.png)
ThreadLocal은 JDK 1.2부터 제공된 오래된 클래스다. 이 클래스를 활용하면 스레드 단위로 로컬 변수를 사용할 수 있기 때문에 마치 전역변수처럼 여러 메서드에서 활용할 수 있다. 다만 잘못 사용하는 경우 큰 부작용(side-effect)이 발생할 수 있기 때문에 다른 스레드와 변수가 공유되지 않도록 주의해야 한다. Heap 영역은 일반적으로 모든 thread에서 접근 할 수 있지만 stack은 thread 하나당 만들어 지는 메모리 영역으로 thread간 접근이 불가능하다. 따라서일반 변수의 수명은 특정 코드 블록(예, 메서드 범위, for 블록 범위 등) 범위 내에서만 유효하다. { int a = 10; ... // 블록 내에서 a 변수 사용 가능 } // 변수 a는 위 코드 블록이 끝나면 ..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/baBX5z/btspgnZcvgm/IFNTKU6YYGxYurMWvGCCpk/img.png)
CQRS 패턴은 무엇일까? 종종 듣는 분들도 많을 것이고 실제 회사에서 도입하여 사용하는 케이스도 많다고 들었다. 필자는 CQRS란 무엇인지 스프링을 사용한다면 애플리케이션 레벨에서 어떻게 적용해 볼 수 있는지 작성해보려고 한다. CQRS는 Command Query Responsibility Segregation의 약자로 해석하면 명령 조회 책임 분리이다. 애플리케이션들을 구성하는 아키텍처에 대한 하나의 패턴이다. 즉 애플리케이션을 구현함에 있어 명령과 조회에 대한 책임을 분리하는 것이다. CQRS 패턴에 대해 구글링해보면 자주 마주치는 그림이다. 필자는 그냥 간단하게 생각했다. DB를 조회할 때 조회(READ)와 처리작업(CREATE, UPDATE, DELETE 등)을 다른 노드에게 할당하면 기본적인 ..
![](http://i1.daumcdn.net/thumb/C148x148/?fname=https://blog.kakaocdn.net/dn/ckgEYU/btsjAvsRjCg/q3e7E7SdVovq4WDUIvpfak/img.png)
JPA N+1문제에 대한 기본은 이전에 포스팅한 글을 참고하도록 하자. https://sh970901.tistory.com/126 JPA N+1 문제 1분 이해하기 JPA로 애플리케이션을 개발할 때 성능상 가장 주의해야 하는 것이 N+1 문제이다. JPA를 사용하는 다양한 개발자분들이 이를 사용하다보면 한번 쯤은 꼭 겪게 되는 문제일 것이다. 간단한 예제를 통 sh970901.tistory.com 이번에는 실제 사례를 들어 설명해보려고 한다. 현재 엔티티는 위 그림의 다이어그램을 참고한다. 간단히 설명하자면 회원은 여러 주문을 할 수 있으며 주문은 여러 주문 아이템, 배송 주소, 회원 정보 등으로 구성되어있다. 주로 이 부분에서 JPA N+1 문제를 파악해보려고 한다. 기본적으로 Order Entity에..