만약 서비스 계층이 JDBCRepository 구현체에 의존하고 있는 상황에서, 향후 JPA와 같은 다른 데이터 접근 기술로 변경하면 서비스 계층의 트랜잭션 관련 코드도 모두 변경해주어야 합니다.JDBC 트랜잭션 의존JDBC -> JPA로 변경이 문제를 해결하기 위해서는 트랜잭션 기능을 추상화하면 됩니다. 단순하게 생각해보면 아래와 같이 인터페이스를 만들어서 사용하면 될 것 입니다.public interface TxManager { begin(); commit(); rollback();}트랜잭션 추상화와 의존관계서비스는 특정 트랜잭션 기술에 직접 의존하는 것이 아니라, TxManager라는 추상화된 인터페이스에 의존하고 있습니다. 이제 원하는 구현체를 DI를 통해서 주입받기만 하면 되는데..
세션1이 트랜잭션을 시작하고 데이터를 수정하는 동안 아직 커밋을 수행하지 않았는데, 세션2에서 동시에 같은 데이터를 수정하게 되면 여러가지 문제가 발생한다. 만약 세션1이 중간에 롤백을 하게 되면 세션2는 잘못된 데이터를 수정하는 문제가 발생한다.이런 문제를 방지하려면, 세션이 트랜잭션을 시작하고 데이터를 수정하는 동안에는 커밋이나 롤백 전까지 다른 세션에서 해당 데이터를 수정할 수 없게 막아야 한다. 여기서는 데이터베이스 Lock을 이용하여 이 문제를 해결하는 방법을 알아보겠다.세션1은 memberA의 금액을 500원으로 변경하고 싶고, 세션2는 같은 memberA의 금액을 1000원으로 변경하고 싶다. 데이터베이스는 이런 문제를 해결하기 위해 락(Lock)이라는 개념을 제공한다.세션1은 트랜잭션을 시..
데이터베이스 연결 구조사용자는 웹 애플리케이션 서버(WAS)나 DB 접근 툴 같은 클라이언트를 사용해서 데이터베이스 서버에 접근할 수 있다. 클라이언트는 데이터베이스 서버에 연결을 요청하고 커넥션을 맺게 되는데, 이때 데이터베이스 서버는 내부에 세션이라는 것을 만든다. 이후 커넥션을 통한 모든 요청은 이 세션을 통해 실행된다.개발자가 클라이언트를 통해 SQL을 전달하면 현재 커넥션에 연결된 세선이 SQL을 실행한다. 세션은 트랜잭션을 시작하고, 커밋 또는 롤백을 통해 트랜잭션을 종료한다. 사용자가 커넥션을 닫거나, 세션을 강제로 종료하면 세션이 종료된다.커넥션 풀이 10개의 커넥션을 생성하면, 세션도 10개가 만들어진다.트랜잭션 개념 이해하기아래 예제(격리 수준: READ_COMMITED)는 트랜잭션 개..
커넥션을 획득하는 다양한 방법DriverManager를 통해 커넥션 획득커넥션을 얻는 방법은 JDBC DriverManager 를 직접 사용하거나, 커넥션 풀을 사용하는 등 다양한 방법이 존재한다.DriverManager를 통해 커넥션 획득하다가 커넥션 풀로 변경시 문제만약 DriverManager를 통해서 커넥션을 획득하다가, 커넥션 풀을 사용하는 방법으로 변경하려면 어떻게 해야할까? 예를 들어 애플리케이션 로직에서 DriverManager 를 사용해서 커넥션을 획득하다가 HikariCP 같은 커넥션 풀을 사용하도록 변경하면 커넥션을 획득하는 애플리케이션 코드도 함께 변경해야 한다. 의존관계가 DriverManager에서 HikariCP로 변경되기 때문이다. 그리고 둘의 사용법도 조금씩 다를 것이다.커..
데이터베이스 커넥션을 획득할 때는 다음과 같은 복잡한 과정을 거친다.애플리케이션 로직은 DB 드라이버를 통해 커넥션을 조회한다.DB 드라이버는 DB와 TCP/IP 커넥션을 연결한다. 물론 이 과정에서 3 way handshake 같은 TCP/IP 연결을 위한 네트워크 동작이 발생한다.DB 드라이버는 TCP/IP 커넥션이 연결되면 ID, PW와 기타 부가정보를 DB에 전달한다.DB는 ID, PW를 통해 내부 인증을 완료하고, 내부에 DB 세션을 생성한다.DB는 커넥션 생성이 완료되었다는 응답을 보낸다.DB 드라이버는 커넥션 객체를 생성해서 클라이언트에 반환한다.이렇게 커넥션을 새로 만드는 것은 복잡하고 시간도 많이 소모되는 일이다. DB는 물론이고 애플리케이션 서버에서도 TCP/IP 커넥션을 새로 생성하기..
백프레셔는 Publisher로부터 Subscriber에게 끊임없이 전달되는 데이터를 안정적으로 처리하기 위한 처리 방식이다. 이러한 백프레셔를 좀 더 쉽게 이해하기 위해서는 Publisher와 Subscriber가 어떤 방식으로 데이터를 주고 받는지 이해하는 것이 좋다. Publisher와 Subscriber간의 프로세스 리액티브 프로그래밍은 Publisher와 Subscriber간의 Interaction이라고 볼 수 있다. 가장 먼저 Subscriber에서 subscribe() 메서드를 호출하면서 구독을 시작한다. Publisher에서는 구독이 정상적으로 이루어졌음을 onSubscribe signal로 subscriber에게 알려준다. Subscriber에서 데이터를 전달받기 위해 request sig..
CPU 사용량, 메모리 사용량, 톰캣 쓰레드, DB 커넥션 풀과 같이 공통으로 사용되는 기술 메트릭은 이미 등록되어 있기 때문에, 등록된 메트릭을 사용해서 대시보드를 구성하고 모니터링 하면 된다. 만약 비즈니스에 특화된 주문수, 취소수, 재고 수량과 같은 부분을 모니터링하고 싶은데, 이 부분은 공통으로 만들 수 있는 부분이 아니라 각각의 비즈니스에 특화된 부분들이다. 결국 비즈니스에 관한 부분은 각 비즈니스 마다 구현이 다르다. 따라서 비즈니스 메트릭은 직접 등록하고 확인해야 한다. 이번에는 우리 비즈니스의 실시간 주문수, 취소수 또 실시간 재고 수량을 메트릭으로 등록하고 확인해보자. 각각의 메트릭은 아래와 같이 정의한다. 주문수, 취소수 상품을 주문하면 주문수가 증가한다. 상품을 취소해도 주문수는 유지..
메트릭 (metric) 애플리케이션에서 발생한 메트릭을 그 순간만 확인하는 것이 아니라 과거 이력까지 함께 확인하려면 메트릭을 보관하는 DB가 필요하다. 이렇게 하려면 어디선가 메트릭을 지속해서 수집하고 DB에 저장해야 한다. 프로메테우스가 바로 이런 역할을 담당한다. 전체 구조 스프링 부트 액츄에이터와 마이크로미터를 사용하면 수 많은 메트릭을 자동으로 생성한다. 1.1 마이크로미터 프로메테우스 구현체는 프로메테우스가 읽을 수 있는 포멧으로 메트릭을 생성한다. 프로메테우스는 이렇게 만들어진 메트릭을 지속해서 수집한다. 프로메테우스는 수집한 메트릭을 내부 DB에 저장한다. 사용자는 그라파나 대시보드 툴을 통해 그래프로 편리하게 메트릭을 조회한다. 이때 필요한 데이터는 프로메테우스를 통해서 조회한다. 프로메..
서비스를 운영할 때는 애플리케이션의 CPU, 메모리, 커넥션 사용, 고객 요청수 같은 수 많은 지표들을 확인하는 것이 필요하다. 그래야 어디에 어떤 문제가 발생했는지 사전에 대응도 할 수 있고, 실제 문제가 발생해도 원인을 빠르게 파악해서 대처할 수 있다. 예를 들어서 메모리 사용량이 가득 찼다면 메모리 문제와 관련있는 곳을 빠르게 찾아서 대응할 수 있을 것이다. 세상엔 수 많은 모니터링 툴이 존재하며, 시스템의 다양한 정보를 이 모니터링 툴에 전달해서 사용하게 된다. 하지만 모니터링 툴이 작동하려면 시스템의 다양한 지표들을 각각의 모니터링 툴에 맞도록 만들어서 보내주어야 한다. 모니터링 툴에 지표 전달 예를 들어서 CPU, JVM, 커넥션 정보 등을 JMX 툴에 전달해야 한다면, 각각의 정보를 JMX ..
개발자가 애플리케이션을 개발할 때 기능 요구사항만 개발하는 것은 아니다. 서비스를 실제 운영 단계에 올리게 되면 개발자들이 해야하는 또 다른 중요한 업무가 있다. 바로 서비스에 문제가 없는지 모니터링하고 지표들을 심어서 감시하는 활동들이다. 운영 환경에서 서비스할 때 필요한 이런 기능들을 프로덕션 준비 기능이라 한다. 쉽게 이야기해서 프로덕션을 운영에 배포할 때 준비해야 하는 비 기능적 요소들을 뜻한다. 지표(metric), 추적(trace), 감사(auditing) 모니터링 좀 더 구체적으로 설명하자면, 애플리케이션이 현재 살아있는지, 로그 정보는 정상 설정 되었는지, 커넥션 풀은 얼마나 사용되고 있는지 등을 확인할 수 있어야 한다. 스프링 부트가 제공하는 액추에이터는 이런 프로덕션 준비 기능을 매우 ..
- Total
- Today
- Yesterday
- 노마드
- 인프런
- 스프링 부트
- 북클럽
- 파이썬
- 정렬
- 릿코드
- Spring
- Real MySQL
- mysql 8.0
- 자료구조
- leetcode
- 그리디
- kotlin
- 데이터베이스
- spring boot
- 코틀린
- MySQL
- 백준
- 코테
- 노마드코더
- 스프링부트
- 스프링
- 리팩토링
- 문자열
- 구현
- 알고리즘
- 김영한
- webflux
- Algorithm
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |