mandy

[MySQL] 인덱스

mandykr — Fri, 2 Jun 2023 14:34:48 +0900

1. 랜덤 I/O와 순차 I/O 디스크 읽기

2. 인덱스

1. 랜덤 I/O와 순차 I/O 디스크 읽기

랜덤 I/O는 하드 디스크 드라이브의 플래터를 돌려서 읽어야 할 데이터가 저장된 위치로 디스크 헤더를 이동시킨 다음 데이터를 읽는 것을 의미한다.

3개의 페이지를 디스크에 기록하기 위해 순차 I/O는 1번의 시스템 콜로 디스크의 헤더를 1번 움직이고,

랜덤 I/O는 3번의 시스템 콜로 디스크 헤드를 3번 움직인다. 디스크의 성능은 디스크 헤더의 위치 이동없이 얼마나 많은 데이터를 한 번에 기록하느냐에 의해 결정되기 때문에 랜덤 I/O 작업이 부하가 훨씬 크다.

테이블의 레코드 대부분을 읽는 작업에서는 인덱스 레인지 스캔(랜덤 I/O)이 아닌 풀 테이블 스캔(순차 I/O)을 사용하도록 유도할 수 있지만 그 외에는 랜덤 I/O를 순차 I/O로 바꿔서 실행할 방법은 많지 않다.

결국 쿼리를 튜닝하는 것은 랜덤 I/O 자체를 줄이는 것으로 쿼리를 처리하는 데 꼭 필요한 데이터만 읽도록 쿼리를 개선하는 것을 의미한다.

2. 인덱스

컬럼의 값과 레코드가 저장된 주소를 키와 값의 쌍으로 삼아 컬럼의 값을 정렬해서 보관하는 데이터베이스 객체이다.

데이터베이스 테이블의 모든 데이터를 검색해서 원하는 결과를 가져오려면 시간이 오래 걸리기 때문에 인덱스를 만들어 두고 활용한다. 인덱스는 데이터가 저장될 때마다 항상 값을 정렬해야 하므로 저장하는 과정이 복잡하고 느리지만 이미 정렬돼 있어서 아주 빨리 원하는 값을 찾아올 수 있다.

결론적으로 인덱스는 데이터 저장 성능을 희생하고 그 대신 데이터의 읽기 속도를 높이는 기능이다.

따라서 테이블의 인덱스를 추가할지 말지는 데이터의 저장 속도를 어디까지 희생할 수 있는지, 읽기 속도를 얼마나 더 빠르게 만들어야 하느냐에 따라 결정된다.

(1) B-Tree 인덱스

데이터베이스 인덱싱 알고리즘 가운데 가장 많이 사용되는 B-Tree(Balanced Tree) 인덱스는 컬럼의 원래 값을 변형시키지 않고 인덱스 구조체 내에서 항상 정렬된 상태를 유지한다.

● 인덱스 구조

출처: https://velog.io/@evelyn82ny/B-Tree-index-feat-difference-from-B-plus-Tree

B-Tree 의 구조는 루트 노드, 브랜치 노드, 리프 노드로 이루어져 있고 가장 하위의 리프 노드는 항상 실제 데이터 레코드를 찾아가기 위한 주솟값을 가지고 있다. (MyISAM 테이블은 세컨더리 인덱스가 물리적인 주소를 가지는 반면 InnoDB 테이블은 프라이머리 키를 주소처럼 사용한다.)

대부분의 RDBMS의 데이터 파일에서 레코드는 특정 기준으로 정렬되지 않고 임의의 순서로 저장된다. 하지만 InnoDB 테이블에서 레코드는 클러스터되어 디스크에 저장되므로 기본적으로 프라이머리 키 순서로 정렬되어 저장된다.

B-Tree 인덱스와 클러스터링 인덱스

출처: https://velog.io/@evelyn82ny/B-Tree-index-feat-difference-from-B-plus-Tree

InnoDB 테이블에서 인덱스를 통해 레코드를 읽을 때는 인덱스에 저장돼 있는 프라이머리 키 값을 이용해 프라이머리 키 인덱스를 한번 더 검색한 후, 프라이머리 키 인덱스의 리프 페이지에 저장돼 있는 레코드를 읽는다. 즉, InnoDB 스토리지 엔진에서는 모든 세컨더리 인덱스 검색에서 데이터 레코드를 읽기 위해서는 반드시 클러스터링 인덱스를 한번 더 검색해야 한다.

● 인덱스 키 추가

레코드를 추가하면 B-Tree에 인덱스 키 추가 작업이 발생한다. 이 때 저장될 키 값을 이용해 B-Tree 상의 적절한 위치를 검색해야 한다. 저장될 위치가 결정되면 레코드의 키 값과 대상 레코드의 주소 정보를 B-Tree의 리프 노드에 저장한다. 리프 노드가 꽉 차서 더는 저장할 수 없을 때는 리프 노드가 분리돼야 하는데, 이는 상위 브랜치 노드까지 처리의 범위가 넓어진다. 이러한 작업 탓에 B-Tree는 상대적으로 쓰기 작업에 비용이 많이 든다.

(체인지 버퍼)

InnoDB는 변경해야 할 인덱스 페이지가 버퍼 풀에 있으면 바로 업데이트를 수행하지만 디스크로부터 읽어와서 업데이트 해야 한다면 이를 즉시 실행하지 않고 임시 공간에 저장해 두고 바로 사용자에게 결과를 반환하는 형태로 성능을 향상시킨다. 이때 사용하는 임시 메모리 공간을 체인지 버퍼라고 한다.

* 체인지 버퍼에 임시로 저장된 인덱스 레코드 조각은 이후 백그라운드 스레드(머지 스레드)에 의해 병합된다.

* 유니크 인덱스는 반드시 중복 여부를 체크해야 하기 때문에 체인지 버퍼를 사용할 수 없다.

● 인덱스 키 삭제

레코드 삭제로 B-Tree 인덱스 키 값이 삭제될때는 해당 키 값이 저장된 리프 노드를 찾아 삭제 마크하는 작업만 발생한다. 이렇게 삭제 마킹된 인덱스 키 공간은 계속 그대로 방치되거나 재활용할 수 있다. 이 작업 역시 디스크 I/O가 필요한 작업이다.

● 인덱스 키 변경

인덱스 키 값은 그 값에 따라 저장될 리프 노드의 위치가 결정되므로 B-Tree의 키 값이 변경되는 경우 기존 인덱스 키 값을 삭제한 후 새로운 인덱스 키 값을 추가하는 작업으로 처리되고, InnoDB 테이블은 이 작업 모두 체인지 버퍼를 활용해 지연 처리될 수 있다.

● 인덱스 키 검색

B-Tree 인덱스를 이용한 검색은 100% 일치, 값의 앞부분만 일치하는 경우, 부등호(<, >) 비교 조건에서 인덱스를 사용할 수 있다.

다음은 인덱스 키 검색을 사용할 수 없는 경우이다.

인덱스를 구성하는 키 값의 뒷부분만 검색하는 용도

SELECT * FROM CUSTOMER WHERE NAME LIKE '%A';

함수나 연산을 수행한 결과로 정렬하거나 검색하는 작업
(인덱스의 키 값에 변형이 가해진 후 비교되는 경우 변형된 값은 B-Tree 인덱스에 존재하는 값이 아니다.)

SELECT * FROM EMP WHERE TO_CHAR(hire_date, 'YYYY') = '2021';

● 인덱스 시간 복잡도

MySQL 인덱스는 B-Tree 계열(B+Tree, B*Tree) 자료구조를 사용한다.

B-Tree는 이진 탐색 트리(binary search tree, BST)의 일반화된 형태이다. 이진 탐색 트리가 자식 노드가 2개 이하인 트리라면, B-Tree는 자식 노드가 2개 이상인 트리이다. 즉, 노드의 개수를 늘리고 트리의 전체 높이를 줄여서 빠른 탐색 속도를 얻을 수 있다. 최대 M개의 자식을 가질 수 있는 B-Tree를 M차 B-Tree라고 한다.

출처: https://hudi.blog/db-index-and-indexing-algorithms/

B-Tree는 정렬된 트리이므로 탐색이 의 시간 복잡도를 갖는다. 28이라는 숫자를 찾는데 고작 4번의 탐색을 거친다.

B+Tree

일반적으로 DBMS에서는 B+Tree를 사용하는데 B+Tree는 리프 노드가 연결리스트 형태를 가진다.

부등호 연산에서 B-Tree는 트리 순회를 하지만 B+Tree는 리프 노드를 순차 검색할 수 있어 B-Tree에 비해 빠르다.

(2) 클러스터링 인덱스

MySQL에서 InnoDB 엔진만 지원하는 기능으로 프라이머리 키 값이 비슷한 레코드끼리 묶어서 저장하는 것을 의미한다.

프라이머리 키 값이 변경된다면 그 레코드의 물리적인 저장 위치가 바뀌기 때문에 테이블은 프라이머리 키 값 자체에 대한 의존도가 상당히 크다. 테이블 자체가 클러스터링 되기 때문에 "클러스터링 테이블"과 동의어로 사용한다.

클러스터링 인덱스를 사용해 조금 느린 쓰기를 감수하고 읽기를 빠르게 유지할 수 있다.

(테이블에 프라이머리 키가 없는 경우)

InnoDB 엔진이 다음 우선순위대로 대체할 컬럼을 클러스터링 키로 선택한다.

프라이머리 키가 있으면 기본적으로 프라이머리 키를 선택
NOT NULL 옵션의 유니크 인덱스 중에서 첫 번째 인덱스를 선택
자동으로 유니크한 값을 가지도록 증가되는 컬럼을 내부적으로 추가한 후 선택

InnoDB 테이블의 모든 세컨더리 인덱스는 해당 레코드의 주소가 아니라 프라이머리 키 값을 저장한다.

출처: https://velog.io/@evelyn82ny/B-Tree-index-feat-difference-from-B-plus-Tree

따라서 클러스터링 키 값이 변경되면 레코드의 주소가 변경되는데 이때, 모든 세컨더리 인덱스가 업데이트 되는 오버헤드가 발생하지 않는다.

● 클러스터링 인덱스 키의 크기

클러스터링 테이블의 모든 세컨더리 인덱스가 PK 값을 포함하기 때문에 PK의 크기가 커지면 세컨더리 인덱스도 자동으로 크기가 커진다.

5개의 세컨더리 인덱스를 가지는 테이블의 경우

PK 크기가 커질수록 인덱스가 성능을 내기위해 필요한 메모리가 증가한다.

PK 크기	레코드당 증가하는 인덱스 크기	100만 건 레코드 저장 시 증가하는 인덱스 크기
10B	10B * 5 = 50B	50B * 1,000,000 = 47MB
50B	50B * 5 = 250B	250B * 1,000,000 = 238MB

PK 는 메모리를 고려해 Auto-Increment 보다는 업무적인 컬럼으로 생성하는 것을 권장한다.

(3) 유니크 인덱스

유니크 인덱스는 세컨더리 인덱스와 구조상 차이가 없고 읽기 성능도 차이가 미미하다.

하지만 쓰기 작업에서는 유니크 인덱스가 중복된 값이 있는지 체크하는 과정이 필요하고 이로 인해 체인지 버퍼를 사용할 수 없어 세컨더리 인덱스보다 더 느리게 작동한다.

참고

[MySQL] MySQL의 격리 수준

mandykr — Fri, 2 Jun 2023 14:33:07 +0900

1. READ UNCOMMITTED

2. READ COMMITTED

3. REPEATABLE READ

4. SERIALIZABLE

MySQL의 격리 수준

트랜잭션의 격리 수준이란 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것이다.

1. READ UNCOMMITTED

각 트랜잭션에서의 변경 내용이 COMMIT이나 ROLLBACK 여부에 상관없이 다른 트랜잭션에서 조회할 수 있다.

어떤 트랜잭션에서 처리한 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있는 Dirty read 가 허용된다.

2. READ COMMITTED

어떤 트랜잭션에서 데이터를 변경했더라도 COMMIT이 완료된 데이터만 다른 트랜잭션에서 조회할 수 있다.

● Dirty read 가 발생하지 않는다.

새로운 값인 "Toto" 는 테이블에 기록되고 이전 값인 "Lara"는 언두 영역으로 백업한다.

사용자 B의 조회 결과는 언두 영역에 백업된 레코드("Lara")가 반환된다.

● NON-REPEATABLE READ 라는 부정합 문제가 발생할 수 있다.

사용자 B가 하나의 트랜잭션 내에서 똑같은 SELECT 쿼리를 실행했을 때는 항상 같은 결과를 가져와야 한다는 REPEATABLE READ 에 어긋난다.

3. REPEATABLE READ

InnoDB 엔진의 기본 격리 수준이다.

MVCC 를 이용해 현재 트랜잭션의 ID보다 작은 ID로 변경된 데이터만 언두 로그에서 조회한다.

사용자 B가 10번으로 트랜잭션을 시작했는데, 그때부터 사용자 B의 10번 트랜잭션 안에서 실행되는 모든 SELECT 쿼리는 트랜잭션 번호가 10(자신의 트랜잭션 번호)보다 작은 트랜잭션 번호에서 변경한 것만 조회하게 된다.

● PHANTOM READ 가 발생할 수 있다.

다른 트랜잭션에서 수행한 변경 작업에 의해 레코드가 보였다 안보였다 하는 현상이다.

"SELECT ... FOR UPDATE", "SELECT ... FOR SHARE" 를 제외한 SELECT 에서는

InnoDB 스토리지 엔진에서 갭 락과 넥스트 키 락 덕분에 PHANTOM READ 가 발생하지 않는다.

SELECT ... FOR UPDATE 쿼리는 SELECT 하는 레코드에 쓰기 잠금을 걸어야 하는데, 언두 레코드에는 잠금을 걸 수 없어 변경 전이 아닌 현재의 레코드를 조회하게 된다.

4. SERIALIZABLE

읽기 작업도 공유잠금을 획득하기 때문에 한 트랜잭션에서 읽고 쓰는 레코드를 다른 트랜잭션에서는 접근할 수 없다.

(잠금 없는 일관된 읽기)

잠금 없는 일관된 읽기 (Non-Locking Consistent Read)

InnoDB 스토리지 엔진은 격리수준이 SERIALIZABLE이 아닌 경우 MVCC 기술을 이용해 다른 트랜잭션이 가지고 있는 잠금을 기다리지 않고 읽기 작업이 가능하다.

격리 수준이 1 > 4 로 갈수록 트랜잭션 간의 격리 정도가 높아지며, 동시 처리 성능은 떨어진다.

	DIRTY READ	NON-REPEATABLE READ	PHANTOM READ
1. READ UNCOMMITTED	O	O	O
2. READ COMMITTED	X	O	O
3. REPEATABLE READ	X	X	O (InnoDB는 없음)
4. SERIALIZABLE	X	X	X

참고

[MySQL] 옵티마이저의 데이터 처리

mandykr — Fri, 2 Jun 2023 13:52:19 +0900

1. 풀 테이블 스캔과 풀 인덱스 스캔

2. 병렬 처리

3. ORDER BY 처리

4. GROUP BY 처리(Using filesort)

5. DISTINCT 처리

옵티마이저

MySQL에서는 쿼리를 최적으로 실행하기 위해 각 테이블의 데이터가 어떤 분포로 저장돼 있는지 통계 정보를 참조해 최적의 실행 계획을 수립하는 작업이 필요한데 옵티마이저가 이 작업을 수행한다.

옵티마이저는 쿼리 파서의 파싱 작업을 거쳐 만들어진 SQL 파스 트리를 참조하며 다음과 같은 과정을 거쳐 실행 계획을 만든다.

불필요한 조건 제거 및 복잡한 연산의 단순화
여러 테이블의 조인이 있는 경우 어떤 순서로 테이블을 읽을지 결정
각 테이블에 사용된 조건과 인덱스 통계 정보를 이용해 사용할 인덱스를 결정
가져온 레코드들을 임시 테이블에 넣고 다시 한번 가공해야 하는지 결정

수립된 실행 계획대로 스토리지 엔진에 레코드를 읽어오도록 요청하고, MySQL 엔진에서는 스토리지 엔진으로부터 받은 레코드를 조인하거나 정렬하는 작업을 수행한다.

1. 풀 테이블 스캔과 풀 인덱스 스캔

옵티마이저는 다음과 같은 조건이 일치할 때 주로 풀 테이블 스캔을 선택한다.

테이블의 레코드 건수가 너무 작아서 인덱스를 통해 읽는 것보다 풀 테이블 스캔을 하는 편이 더 빠른 경우
(일반적으로 테이블이 페이지 1개로 구성된 경우)
WHERE 절이나 ON 절에 인덱스를 이용할 수 있는 적절한 조건이 없는 경우
인덱스 레인지 스캔을 사용할 수 있는 쿼리라고 하더라도 옵티마이저가 판단한 조건 일치 레코드 건수가 너무 많은 경우
(인덱스의 B-Tree를 샘플링해서 조사한 통계 정보 기준)

풀 테이블 스캔이 실행되면 처음 몇 개의 데이터 페이지는 포그라운드 스레드가 페이지 읽기를 실행하지만 특정 시점부터는 읽기 작업을 백그라운드 스레드로 넘기고 포그라운드 스레드는 미리 버퍼 풀에 준비된 데이터를 가져다 사용하기만 하면 되므로 상당히 빨리 처리된다.

(리드 어헤드)

InnoDB 스토리지 엔진은 특정 테이블의 연속된 데이터 페이지가 읽히면 백그라운드 스레드에 의해 리드 어헤드 작업이 자동으로 시작된다. 리드 어헤드란 어떤 영역의 데이터가 앞으로 필요해지리라는 것을 예측해서 요청이 오기 전에 미리 디스크에서 읽어 InnoDB 버퍼 풀에 가져다 두는 것을 의미한다.

innodb_read_ahead_threshold 시스템 변수에 설정된 개수만큼의 포그라운드 스레드에 의해 연속된 데이터 페이지가 읽히면 InnoDB 스토리지 엔진은 백그라운드 스레드를 이용해 대량으로 그다음 페이지들을 읽어서 버퍼 풀로 적재한다.

2. 병렬 처리

MySQL 8.0 에서는 아무런 WHERE 조건 없이 단순히 테이블의 전체 건수를 가져오는 쿼리만 병렬로 처리할 수 있다.

innodb_parallel_read_threads 시스템 변수를 이용해 하나의 쿼리를 최대 몇 개의 스레드를 이용해서 처리할지를 변경할 수 있다.

SET SESSION innodb_parallel_read_threads = 4;
SELECT COUNT(*) FROM salaries;

병렬 처리용 스레드 개수를 아무리 늘리더라도 서버에 장착된 CPU의 코어 개수를 넘어서는 경우에는 오히려 성능이 떨어질 수 있다.

3. ORDER BY 처리(Using filesort)

정렬을 처리하는 방법은 인덱스를 이용하는 방법과 "Filesort"라는 별도의 처리를 이용하는 방법으로 나눌 수 있다.

	장점	단점
인덱스 이용	(INSERT, UPDATE, DELETE 쿼리가 실행될 때) 이미 인덱스가 정렬돼 있어서 순서대로 읽기만 하면 되므로 매우 빠르다.	INSERT, UPDATE, DELETE 작업 시 부가적인 인덱스 추가/삭제 작업이 필요하므로 느리다. 인덱스 때문에 디스크 공간이 더 많이 필요하다. 인덱스의 개수가 늘어날수로 InnoDB 버퍼 풀을 위한 메모리가 많이 필요하다.
Filesort 이용	인덱스를 생성하지 않아도 되므로 인덱스를 이용할 때의 단점이 장점으로 바뀐다. 정렬해야 할 레코드가 많지 않으면 메모리에서 Filesort가 처리되므로 충분히 빠르다.	정렬 작업이 쿼리 실행시 처리되므로 레코드 대상 건수가 많아질수로 쿼리의 응답 속도가 느리다.

인덱스를 이용한 정렬이 빠르지만 다음과 같은 경우 때문에 모든 정렬을 인덱스를 이용하도록 튜닝하긴 불가능하다.

정렬 기준이 너무 많아서 요건별로 모두 인덱스를 생성하는 것이 불가능한 경우
GROUP BY의 결과 또는 DISTINCT 같은 처리의 결과를 정렬해야 하는 경우
UNION의 결과와 같이 임시 테이블의 결과를 다시 정렬해야 하는 경우
랜덤하게 결과 레코드를 가져와야 하는 경우

1) 소트 버퍼

MySQL은 정렬이 필요한 경우에만 소트 버퍼라는 별도의 메모리 공간을 할당받아 정렬에 사용하고 쿼리의 실행이 완료되면 즉시 시스템으로 반납한다.

(소트 버퍼 메모리 크기)

버퍼의 크기는 정렬해야 할 레코드의 크기에 따라 가변적으로 증가

최대 사용 가능한 버퍼의 공간은 sort_buffer_size 시스템 변수로 설정

(1) 멀티 머지

정렬해야 할 레코드의 건수가 소트 버퍼로 할당된 공간보다 큰 경우 MySQL은 레코드를 여러 조각으로 나눠서 처리한다.

버퍼 크기만큼 정렬된 레코드를 병합하면서 정렬을 수행한다. 이 작업들은 모두 디스크 I/O를 유발한다.

메모리의 소트 버퍼에서 정렬을 수행
결과를 임시로 디스크에 기록
다음 레코드를 가져와 반복 수행

(2) 세션 메모리 영역

소트 버퍼는 세션 메모리 영역을 사용하는데, 커넥션이 많을수록, 정렬 작업이 많을수록 소트 버퍼로 소비되는 메모리 공간이 커지게 된다. 소트 버퍼의 크기를 10MB 이상으로 설정하면 대량의 레코드를 정렬하는 쿼리가 여러 커넥션에서 동시에 실행되면서 운영체제는 메모리 부족 현상을 겪을 수도 있다.

테스트하는 서버에서 메모리나 디스크의 특성에 따라 다를 수 있지만 일반적인 트랜잭션 처리용 서버에서 소트 버퍼 크기는 56KB ~ 1MB가 적절하다.

2) 정렬 알고리즘

정렬할 때 소트 버퍼에 레코드 전체를 담을지, 정렬 기준 컬럼만 담을지에 따라 싱글 패스와 투 패스 모드로 나눌 수 있다.

(1) 싱글 패스(Single-pass)

소트 버퍼에 Select 대상이 되는 컬럼을 전부 담아서 정렬을 수행

<sort_key, additional_fields>: 정렬 키와 레코드 전체를 가져와서 정렬하는 방식, 레코드의 컬럼들은 고정 사이즈로 메모리 저장
<sort_key, packed_additional_fields>: 정렬 키와 레코드 전체를 가져와서 정렬하는 방식, 레코드의 컬럼들은 가변 사이즈로 메모리 저장

(2) 투 패스(Two-pass)

정렬 대상 컬럼과 PK 값만 소트 버퍼에 담아서 정렬을 수행

정렬된 순서대로 다시 PK로 테이블을 읽어서 SELECT 할 컬럼을 가져오는 방식

<sort_key, rowid>: 정렬 키와 레코드의 Row ID만 가져와서 정렬하는 방식

최신 버전에서는 일반적으로 싱글 패스 방식을 주로 사용하고, 다음의 경우 투 패스 방식 사용

레코드의 크기가 max_length_for_sort_data 시스템 변수에 설정된 값보다 클 때
BLOB이나 TEXT 타입의 컬럼이 SELECT 대상에 포함될 때

3) 정렬 처리 방법

쿼리에 ORDER BY가 사용되면 다음 3가지 방법중 하나로 정렬이 처리된다.

인덱스를 사용할 수 있는지 검토하고 사용할 수 없으면 WHERE 조건에 일치하는 레코드를 검색해 정렬 버퍼에 저장하면서 Filesort 한다.

	실행 계획의 Extra 컬럼 내용	우선 순위	처리 속도
인덱스를 사용한 정렬		1	1
조인에서 드라이빙 테이블만 정렬	"Using filesort"	2	2
조인에서 조인 결과를 임시 테이블로 저장 후 정렬	"Using temporary; Using filesort"	3	3

(1) 인덱스를 이용한 정렬

인덱스의 값이 정렬돼 있기 때문에 인덱스의 순서대로 읽기만 하면 된다.

SELECT * FROM employees e, salaries s
WHERE s.emp_no=e.emp_no
AND e.emp_no BETWEEN 1000002 AND 100020
ORDER BY e.emp_no;

인덱스를 이용한 정렬을 위해 필요한 조건

ORDER BY에 명시된 컬럼이 드라이빙 테이블에 속해야 한다.
ORDER BY 순서대로 생성된 인덱스가 있어야 한다.
WHERE 절에 첫 번째로 읽는 테이블의 컬럼에 대한 조건이 있다면 그 조건과 ORDER BY는 같은 인덱스를 사용할 수 있어야 한다.

(2) 조인의 드라이빙 테이블만 정렬

드라이빙 테이블의 레코드를 먼저 정렬한 다음 조인을 실행한다.

SELECT * FROM employees e, salaries s
WHERE s.emp_no=e.emp_no
AND e.emp_no BETWEEN 100002 AND 100010
ORDER BY e.last_name;

인덱스를 이용해 "emp_no BETWEEN 100001 AND 100010" 조건을 만족하는 9건을 검색
검색 결과를 last_name 컬럼으로 정렬을 수행(Filesort)
정렬된 결과를 순서대로 읽으면서 salaries 테이블과 조인을 수행해 86건의 최종 결과를 가져옴

드라이빙 테이블만 정렬을 위해 필요한 조건

드라이빙 테이블의 컬럼만으로 ORDER BY 절을 작성해야 한다.

(검색은 인덱스 레인지 스캔으로 처리할 수 있지만,

ORDER BY 절에 명시된 컬럼은 PK와 전혀 연관이 없으므로 인덱스를 이용한 정렬은 불가능하다.)

(3) 임시 테이블을 이용한 정렬

"드라이빙 테이블만 정렬" 방식 외의 패턴에서는 조인된 데이터를 임시 테이블에 저장하고 정렬을 수행한다.

SELECT * FROM employees e, salaries s
WHERE s.emp_no=e.emp_no 
AND e.emp_no BETWEEN 100002 AND 100010
ORDER BY s.salary;

(4) 정렬 처리 방법의 성능

스트리밍 방식 : 레코드가 검색될 때마다 바로바로 클라이언트로 전송해주는 방식
버퍼링 방식 : 모든 레코드를 가져온 후, 정렬하거나 그루핑해서 차례대로 전송하는 방식

인덱스를 사용한 정렬 방식은 스트리밍 형태의 처리이며, 나머지 2가지 방법은 버퍼링 방식으로 처리된다. 따라서 가능하다면 인덱스를 사용한 정렬로 유도하도록 튜닝하는 것이 좋다.

(JDBC 라이브러리의 버퍼링)

MySQL 서버는 스트리밍 방식으로 처리해서 레코드를 반환하더라도 JDBC 라이브러리는 MySQL 서버로부터 받는 레코드를 일단 내부 버퍼에 모두 담아두고 마지막 레코드까지 전달받으면 클라이언트의 애플리케이션에 반환하기 때문에 버퍼링 방식으로 동작한다.

4) 정렬 관련 상태 변수

MySQL 서버는 처리하는 주요 작업에 대해서는 해당 작업의 실행 횟수를 상태 변수로 저장한다.

FULUSH STATUS;
SHOW STATUS LIKE 'Sort%';

Sort_merge_passes	멀티 머지 처리 횟수
Sort_range	인덱스 레인지 스캔을 통해 검색된 결과에 대한 정렬 작업 횟수
Sort_scan	풀 테이블 스캔을 통해 검색된 결과에 대한 정렬 작업 횟수
Sort_rows	정렬한 전체 레코드 건수

4. GROUP BY 처리

GROUB BY 작업은 인덱스 스캔, 루스 인덱스 스캔, 인덱스를 사용하지 못하고 임시 테이블을 사용하는 방법으로 나뉜다.

1) 인덱스 스캔을 이용하는 GROUP BY(타이트 인덱스 스캔)

드라이빙 테이블에 속한 컬럼만 이용해 그루핑할 때, GROUP BY 컬럼으로 인덱스가 있다면 인덱스를 차례대로 읽으면서 그루핑 작업을 수행하고 그 결과로 조인을 처리한다. 그룹 함수등의 그룹값을 처리해야 하는 경우에는 임시 테이블이 필요할 때도 있다.

실행 계획의 Extra : 없음

2) 루스 인덱스 스캔을 이용하는 GROUP BY

단일 테이블에 대해 수행되는 GROUP BY 처리에만 사용할 수 있다.

(루스 인덱스 스캔 참고)

실행 계획의 Extra : "Using index for group-by"

3) 임시 테이블을 사용하는 GROUP BY

GROUP BY의 기준 컬럼이 드라이빙, 드리븐 테이블에 있는지와 관계없이 인덱스를 사용하지 못할 때 처리되는 방식이다.

MySQL 8.0 에서는 GROUP BY가 필요한 경우 내부적으로 GROUP BY 절의 컬럼들로 구성된 유니크 인덱스를 가진 임시 테이블을 만들어서 중복 제거와 집합 함수 연산을 수행한다.

실행 계획의 Extra : "Using temporary"

5. DISTINCT 처리

1) SELECT DISTINCT

집합 함수를 사용하지 않고 DISTINCT 만 사용한 경우 GROUP BY와 동일한 방식으로 처리된다.

SELECT DISTINCT emp_no FROM salaries;
SELECT emp_no FROM salaries GROUP BY emp_no;

2) 집합 함수와 함께 사용된 DISTINCT

COUNT(), MIN(), MAX() 같은 집합 함수 내에서 사용된 DISTINCT는 그 집합 함수의 인자로 전달된 컬럼값이 유니크한 것들을 가져오고 단순히 DISTINCT 만 사용한 경우와 다르게 동작한다.

EXPLAIN
SELECT COUNT(DISTINCT s.salary)
FROM employees e, salaries s
WHERE e.emp_no=s.emp_no
AND e.emp_no BETWEEN 100001 AND 100100;

"COUNT(DISTINCT s.salary)" 를 처리하기 위해 조인한 결과에서 salary 컬럼의 값만 저장하기 위해 임시 테이블을 사용하지만 실행 계획에서 "Using temporary"를 표시하지 않는다.

인덱스된 컬럼에 대해 DISTINCT 처리를 수행할 때는 인덱스를 풀 스캔하거나 레인지 스캔하면서 임시 테이블 없이 최적화된 처리를 수행할 수 있다.

참고

[MySQL] B-Tree 인덱스를 통한 데이터 읽기

mandykr — Mon, 22 May 2023 13:05:28 +0900

1. B-Tree 인덱스를 통한 데이터 읽기

2. B-Tree 인덱스의 정렬 및 스캔 방향

3. B-Tree 인덱스의 가용성과 효율성

어떤 경우에 인덱스를 사용하게 유도할지, 또는 사용하지 못하게 할지 판단하려면 MySQL이 어떻게 인덱스를 이용해서 실제 레코드를 읽어 내는지 알아야 한다. MySQL이 인덱스를 이용하는 방법들과 인덱스의 정렬, 가용성에 대해 알아본다.

1. B-Tree 인덱스를 통한 데이터 읽기

1) 인덱스 레인지 스캔

인덱스 레인지 스캔은 검색해야 할 인덱스의 범위가 결정됐을 때 사용하는 방식이다.

SELECT * FROM employees WHERE first_name BETWEEN 'Ebbe' AND 'Gad';

(1) 인덱스 레인지 스캔

루트 노드 → 브랜치 노드 → 리프 노드(n) → 리프 노드(n+1) → ... → 레코드 반환

루트 노드에서부터 비교를 시작해 브랜치 노드를 거치고 리프 노드까지 찾아가 레코드의 시작 지점을 찾는다.
시작 지점부터 순서대로 레코드를 읽는다.
페이지의 끝까지 읽으면 리프 노드간의 링크(Linked list)를 이용해 다음 리프 노드를 찾아서 다시 스캔한다.
최종적으로 레코드를 끝까지 읽으면 사용자에게 반환한다.

(2) 인덱스 레인지 스캔을 통한 레코드 읽기

인덱스의 리프 노드에서 검색 조건에 일치하는 건들은 데이터 파일에서 레코드를 읽어오는 과정이 필요하다.

인덱스 조건을 만족하는 값이 저장된 위치를 찾는다. (Index seek, 인덱스 탐색)
탐색된 위치부터 필요한 만큼 인덱스를 차례대로 쭉 읽는다. (Index scan, 인덱스 스캔)
읽은 인덱스 키와 레코드 주소를 이용해 레코드가 저장된 페이지를 가져오고 최종 레코드를 읽어온다.

리프 노드에 저장된 레코드 주소로 데이터 파일의 레코드를 읽어오는데 레코드 한 건 단위로 랜덤 I/O가 발생하기 때문에 인덱스를 통해 데이터 레코드를 읽는 작업은 비용이 많이 드는 작업으로 분류된다. 그리고 인덱스를 통해 읽어야 할 데이터 레코드가 20~25%를 넘으면 인덱스를 통한 읽기보다 테이블의 데이터를 직접 읽는 것이 효율적인 처리 방식이 된다.

(커버링 인덱스)

쿼리가 필요로 하는 데이터가 인덱스의 키로 사용되고 있는 경우 디스크의 레코드를 읽지 않을 수도 있는데 이를 커버링 인덱스라고 한다. 랜덤 읽기가 상당히 줄어들기 때문에 그만큼 성능이 빨라진다.

2) 인덱스 풀 스캔

인덱스의 처음부터 끝까지 모두 읽는 방식을 인덱스 풀 스캔이라고 한다.

대표적으로 쿼리의 조건절에 사용된 컬럼이 인덱스의 첫 번째 컬럼이 아닌 경우 사용된다.

쿼리가 인덱스에 명시된 컬럼만으로 조건을 처리할 수 있는 경우 이 방식이 사용되고 디스크 I/O가 적기 때문에 테이블 풀 스캔보다 빠르지만 인덱스 레인지 스캔 보다는 느리다. 인덱스 뿐만 아니라 데이터 레코드까지 모두 읽어야 한다면 이 방식으로 처리되지 않는다. 인덱스 풀 스캔은 일반적으로 인덱스를 생성하는 목적은 아니다.

3) 루스 인덱스 스캔

인덱스 레인지 스캔과 비슷하게 작동하지만 중간에 필요치 않은 인덱스 키 값은 무시(SKIP)하고 다음으로 넘어가는 형태로 처리한다. 일반적으로 GROUP BY 또는 집합 함수 가운데 MAX() 또는 MIN() 함수에 대해 최적화를 하는 경우에 사용한다.

SELECT dept_no, MIN(emp_no)
FROM dept_emp
WHERE dep_no BETWEEN 'd002' AND 'd004'
GROUP BY dept_no;

dept_no 그룹별로 첫 번째 레코드의 emp_no 값만 읽으면 되기 때문에 옵티마이저는 조건에 만족하지 않는 레코드는 무시하고 다음 레코드로 이동한다.

4) 인덱스 스킵 스캔

다중 컬럼 인덱스의 선행 컬럼이 쿼리의 조건절에 없는 경우, 선행 컬럼의 유니크한 값을 비교하는 조건을 쿼리에 추가해서 다시 실행하는 형태로 동작하게 한다.

ALTER TABLE employees
ADD INDEX ix_gender_birthdate (gender, birth_date);

-- 인덱스 레인지 스캔으로 동작
SELECT * FROM employees WHERE gender = 'M' AND birth_date >= '1965-02-01';

인덱스를 효율적으로 사용하기 위해 gender 컬럼과 birth_date 컬럼의 조건을 쿼리가 모두 가져야 한다.

-- 인덱스 풀 스캔으로 동작
SELECT gender, birth_date FROM employees WHERE birth_date >= '1965-02-01';

인덱스의 선행 컬럼인 gender가 쿼리의 조건에 없는 경우에는 인덱스 풀 스캔 혹은 테이블 풀 스캔으로 동작하는데

MySQL 8.0 버전부터 옵티마이저가 gender 컬럼을 건너뛰어서 인덱스 검색이 가능하도록 하는 최적화 기능이 도입됐다.

우선 gender 컬럼에서 유니크한 값을 모두 조회해서 주어진 쿼리에 gender 컬럼의 조건을 추가해서 쿼리를 다시 실행한다.

인덱스 스킵 스캔의 제약 조건

WHERE 절에 조건이 없는 인덱스의 선행 column의 유니크한 값 개수가 적어야 함
쿼리가 인덱스에 존재하는 column만으로 처리 가능해야 함(커버링 인덱스)

2. B-Tree 인덱스의 정렬 및 스캔 방향

인덱스를 생성할 때 설정한 정렬 규칙에 따라서 인덱스의 키 값은 항상 오름차순이거나 내림차순으로 정렬되어 저장된다. 하지만 인덱스를 어느 방향으로 읽을지는 쿼리에 따라 옵티마이저가 실시간으로 만들어내는 실행 계획에 따라 결정된다.

1) 인덱스의 정렬

인덱스 생성 시점에 ASC, DESC 키워드로 인덱스의 정렬 방향을 설정할 수 있다.

CREATE INDEX ix_firstname ON employees (first_name ASC);

2) 인덱스 스캔 방향

쿼리의 ORDER BY 처리나 MIN() 또는 MAX() 함수 등의 최적화가 필요한 경우에도 MySQL 옵티마이저는 인덱스의 읽기 방향을 전환해서 사용하도록 실행 계획을 만들어 낸다.

-- ix_firstname 인덱스를 정순으로 10개 스캔
SELECT * FROM employees ORDER BY first_name ASC LIMIT 10;

-- ix_firstname 인덱스를 역순으로 10개 스캔
SELECT * FROM employees ORDER BY first_name DESC LIMIT 10;

3) 내림차순 인덱스

다음과 같은 이유로 InnoDB에서 인덱스 역순 스캔이 정순 스캔에 비해 느리다.

페이지 잠금이 인덱스 정순 스캔에 적합한 구조
페이지 내에서 인덱스 레코드가 단방향으로만 연결된 구조

따라서 쿼리에서 자주 사용되는 정렬 순서대로 인덱스를 생성하는 것이 효율적이다.

3. B-Tree 인덱스의 가용성과 효율성

쿼리의 WHERE 조건이나 GROUP BY 또는 ORDER BY 절이 어떤 경우에 인덱스를 사용할 수 있고 어떤 방식으로 사용할 수 있는지 식별할 수 있어야 쿼리의 조건을 최적화하거나, 역으로 쿼리에 맞게 인덱스를 최적으로 생성할 수 있다.

1) 비교 조건의 종류와 효율성

SELECT * FROM dept_emp
WHERE dept_no = 'd002' AND emp_no >= 10114;

(1) 케이스 A: INDEX (dept_no, emp_no)

" dept_no = 'd002' AND emp_no >= 10114 " 인 레코드를 찾고, 그 이후에는 dept_no가 'd002'가 아닐 때까지 인덱스 스캔
필요한 만큼의 비교작업만 수행하므로 효율적
5번의 비교로 5건 반환

(2) 케이스 B: INDEX (emp_no, dept_no)

" emp_no >= 10114 AND dept_no = 'd002' " 인 레코드를 찾고, 그 이후 모든 레코드에 대해 dept_no가 'd002'인지 비교
dept_no가 범위를 좁히는데 도움을 주지 못하기 때문에 비효율적
7번의 비교로 5건 반환

케이스 A에서 사용된 두 조건(dept_no = 'd002' AND emp_no >= 10114)과 같이 작업 범위를 결정하는 조건은 많으면 많을수록 쿼리의 처리 성능을 높이지만 케이스 B에서 사용된 조건(dept_no = 'd002')과 같은 체크 조건은 쿼리의 성능을 높이지 못하고 오히려 더 느리게 만들 때가 많다.

2) 인덱스의 가용성

B-Tree 인덱스는 왼쪽 값에 기준해서 오른쪽 값이 정렬돼 있기 때문에 정렬 우선순위가 낮은 뒷부분의 값만으로는 인덱스의 효과를 얻을 수 없다.

INDEX (first_name)
SELECT * FROM dept_emp WHERE first_name LIKE '%mer';

다중 컬럼 인덱스는 첫번째 컬럼으로 정렬한 후 두번째 컬럼으로 정렬돼 있기 때문에 인덱스의 선행 컬럼 조건없이 검색하면 인덱스를 효율적으로 사용할 수 없다.

INDEX (dept_no, emp_no)
SELECT * FROM dept_emp WHERE emp_no >= 10144;

3) 가용성과 효율성 판단

(1) 인덱스 사용 불가 조건

NOT-EQUAL로 비교된 경우 (NOT IN, NOT BETWEEN, IS NOT NULL)
- WHERE column <> 'N'
- WHERE column NOT IN (10,11,12)
- WHERE column IS NOT NULL
LIKE %?? 형태의 문자열 패턴 비교인 경우
- WHERE column LIKE '%test‘
- WHERE column LIKE '%test%‘
- WHERE column LIKE '_test‘
스토어드 함수나 다른 연산자로 인덱스 컬럼이 변형된 후 비교된 경우
- WHERE SUBSTRING(column,1, 1) = 'X'
- WHERE DAYOFMONTH(column) = 1
NOT-DETERMINISTIC 속성의 스토어드 함수가 비교 조건에 사용된 경우
- WHERE column = deterministic_function()
데이터 타입이 서로 다른 비교(인덱스 컬럼의 타입을 변환해야 비교가 가능한 경우)
- WHERE char_column = 10
문자열 뎅터 타입의 콜레이션이 다른 경우
- WHERE utf8_bin_char_column = euckr_bin_char_column

(2) 멀티 컬럼 인덱스의 가용성

INDEX ix_test ( column_1, column_2, column_3, ... , column_n)

작업 범위 결정 조건으로 인덱스를 사용하지 못하는 경우
- column_1 컬럼에 대한 조건이 없는 경우
- column_1 컬럼의 비교 조건이 위의 "인덱스 사용 불가 조건" 중 하나인 경우
작업 범위 결정 조건으로 인덱스를 사용하는 경우
- column_1 ~ column_(i-1) 컬럼까지 동등 비교 형태("=" 또는 "IN")로 비교
- column_i 컬럼에 대해 다음 연산자 중 하나로 비교
  1. 동등 비교("=" 또는 "IN")
  2. 크다 작다 형태(">" 또는 "<")
  3. LIKE로 좌측 일치 패턴(LIKE 'test%')

다른 일반적인 DBMS에서는 NULL 값이 인덱스에 저장되지 않지만 MySQL에서는 NULL 값도 인덱스에 저장되기 때문에 작업 범위 결정 조건으로 인덱스를 사용한다.

WHERE column IS NULL

참고

컨슈머 파티션 할당 전략(Cooperative Sticky)

[JPA] 조회 성능 최적화

mandykr — Fri, 28 Apr 2023 13:22:48 +0900

1. 엔티티 단건 조회

2. 엔티티 목록 조회

3. 컬렉션 조회

N + 1

JPA의 N + 1 문제는 즉시로딩과 지연로딩 두 경우 모두 발생할 수 있다.

즉시로딩은 JPQL 을 사용해 엔티티를 조회할 때 쿼리가 실행된 후 즉시로딩으로 연관 관계가 매핑된 엔티티를 조회하는 쿼리가 추가로 실행된다.
지연로딩은 엔티티를 조회할 때 연관 관계가 매핑된 엔티티는 프록시로 조회하지만 프록시의 필드에 접근할 때 해당 엔티티를 조회하는 쿼리가 추가로 실행된다.

다음은 지연로딩으로 매핑된 엔티티들의 연관 관계 종류에 따라 발생하는 N + 1 문제와 최적화 과정이다.

지연로딩은 JPQL로 엔티티를 조회해도 연관된 엔티티를 추가로 조회하지 않기 때문에 N + 1 문제가 발생하지 않는다.

하지만 엔티티의 목록을 조회할 때 연관된 엔티티나 컬렉션에 대해서 N + 1 문제가 발생한다.

연관관계

@Entity
public class Mate {
    @Id
    private UUID id;

    @ManyToOne(optional = false, fetch = FetchType.LAZY)
    private Project project;

    @OneToOne(fetch = FetchType.LAZY)
    private Reviewer reviewer;

    @OneToMany(mappedBy = "mate")
    private List<Review> reviews = new ArrayList<>();
}

1. 엔티티(Mate) 단건 조회

Mate 단건을 조회하는 경우 Project, Reviewer, Review의 필드에 접근할 때 추가 쿼리가 실행된다.

Mate 조회

mateRepository.findById(mateId);

[Mate 조회 쿼리]

mateId 를 파라미터로 사용한다.

select *
from mate
where id = 'b061adb9-76a1-484b-beab-4f8cf4d7e798';

[Project 조회 쿼리 (ManyToOne)] - 추가 쿼리

Mate 조회 쿼리의 결과로 project_id 를 파라미터로 사용한다.

select *
from project
where id = [mate의 project_id 외래키];

[Reviewer 조회 쿼리 (OneToOne)] - 추가 쿼리

Mate 조회 쿼리의 결과로 reviewer_id 를 파라미터로 사용한다.

select *
from reviewer
where id = [mate의 reviewer_id 외래키];

[Review 목록 조회 쿼리 (OneToMany)] - 추가 쿼리

mateId로 review 목록을 조회한다.

select *
from review
where mate_id = [mate_id];

1개의 Mate를 조회하는데 추가로 3개의 쿼리가 실행되었다.

문제는 여러개의 Mate를 조회하는 경우 Mate의 갯수만큼 3개씩의 쿼리가 추가로 실행되게 된다.

2. 엔티티 목록 조회

Mate 목록을 조회하는 경우 Mate의 갯수만큼 Project, Reviewer, Review의 필드에 접근할 때 추가 쿼리가 실행된다.

모든 Mate를 조회한다.

mateRepository.findAll();

쿼리	실행 횟수	결과 row
Mate 조회	1	10
Project 조회	10	10
Reviewer 조회	10	10
Review 조회	10	0+

[ 최적화 방법 ① ] 페치 조인

JPQL 페치 조인을 사용하면 SQL JOIN을 사용해서 페치 조인 대상까지 함께 조회한다.

연관 관계 엔티티를 지연로딩으로 설정하고 필요한 경우에만 함께 조회하기 위해 페치 조인을 사용할 수 있다.

엔티티(Mate) 목록 조회

@Query("select distinct m" +
        " from Mate m" +
        " join fetch m.project p" +
        " join fetch m.reviewer r" +
        " left join fetch m.reviews s")
List<MateReviewResponse> findAllWithReviews();

ToOne 관계에서는 Mate의 중복이 발생하지 않지만 OneToMany 관계(Mate - Review)에서는 DB에서 조회할 때 Review 갯수만큼 Mate가 중복된다. 이때는 distinct 키워드를 사용해 중복을 제거해준다. DB에서는 중복된 상태로 가져오지만 메모리에서 Mate의 중복을 제거한다.

fetch 조인 쿼리

select distinct ...
from mate m
inner join project p
        on m.project_id = p.id 
inner join reviewer r
        on m.reviewer_id = r.id 
left outer join review w
        on m.id = w.mate_id;

하지만 필요한 경우에만 페치 조인을 사용하는 방법이 결국 프리젠테이션 계층의 영향이 데이터 접근 계층에 까지 영향을 주게된다. 화면별로 조회 쿼리를 만들어 사용하면 화면에 맞춘 리포지토리의 메소드가 증가할 수 있다.

그리고 페치 조인으로 컬렉션을 조회할 때는 페이징이 불가능하다.

3. 컬렉션 조회

OneToMany 관계(Mate - Review)가 있을때는 페치 조인을 이용해 페이징 조회가 불가능하다.

@Query(value = "select m" +
        " from Mate m" +
        " join fetch m.project p" +
        " join fetch m.reviewer r" +
        " left join fetch m.reviews s" +
        " order by p.id",
        countQuery = "select count(m.id) from Mate m")
Page<Mate> findAllWithReviews(PageRequest page);

Mate 하나에 Review가 여러개의 row 로 매핑되기 때문에 DB에서 조회하면 Review의 갯수 만큼 조회된다.

Mate 를 기준으로 페이징을 해야 하지만 Review 를 기준으로 데이터가 조회되기 때문에

컬렉션을 페치 조인 할 때 페이징을 사용하면 하이버네이트는 모든 데이터를 메모리에 올려서 페이징을 만들게 된다.

따라서 컬렉션 페치 조인은 메모리 문제가 발생할 수 있다.

QueryTranslatorImpl:HHH000104: firstResult/maxResults specified with collection fetch; applying in memory!

[최적화 방법 2] 배치 사이즈로 지연로딩

ToOne, OneToMany(컬렉션) 관계가 함께 있을 때 페이징을 하기 위해 ToOne 은 페치 조인을 사용하고

컬렉션은 지연 로딩을 사용해야 한다.

// repository
@Query(value = "select m" +
        " from Mate m" +
        " join fetch m.project p" +
        " join fetch m.reviewer r" +
        " order by p.id",
        countQuery = "select count(m.id) from Mate m")
Page<Mate> findAllMates(PageRequest page);

// service
Page<MateReviewResponse> response = mateRepository.findAllMates(PageRequest.of(0, 3))
        .map(MateReviewResponse::of);

// dto
public static MateReviewResponse of(Mate mate) {
    return new MateReviewResponse(
            mate.getId(),
            mate.getProject().getCodeStore().getName(),
            mate.getReviewer().getName(),
            mate.getReviews().stream()
                    .map(ReviewResponse::of)
                    .toList()
    );
}

MateReviewResponse DTO에서 Review의 필드에 접근할 때 지연로딩이 발생하는데

컬렉션을 지연 로딩할 경우 Mate의 갯수만큼 Review 목록을 조회하는 쿼리가 추가로 실행되지만

Review 프록시 객체를 한꺼번에 설정한 size(hibernate.default_batch_fetch_size , @BatchSize) 만큼 IN 쿼리로 조회할 수 있다.

select *
from review
where mate_id in (
    ?, ?, ?
);

글로벌 단위 설정

# application.properties
spring.jpa.properties.hibernate.default_batch_fetch_size=100

엔티티 단위 설정

@BatchSize(size = 100)
@OneToMany(mappedBy = "mate")
private List<Review> reviews = new ArrayList<>();

[최적화 방법 3] QueryDSL 사용

QueryDSL 라이브러리를 사용하면 페이징과 DTO 직접 조회를 편리하게 사용할 수 있다.

public Page<MateReviewResponse> findAllMates(Pageable page) {
    List<MateReviewResponse> content = queryFactory
            .from(mate)
            .join(mate.project, project)
            .join(mate.reviewer, reviewer)
            .leftJoin(mate.reviews, review)
            .offset(page.getOffset())
            .limit(page.getPageSize())
            .transform(groupBy(mate.id)
                    .list(bean(MateReviewResponse.class,
                            mate.id,
                            project.codeStore.name.as("projectName"),
                            reviewer.name.as("reviewerName"),
                            list(bean(ReviewResponse.class,
                                    review.id,
                                    review.status)
                            ).as("reviews")))
            );

    JPAQuery<Long> countQuery = queryFactory
            .select(mate.count())
            .from(mate);

    return PageableExecutionUtils.getPage(content, page, countQuery::fetchFirst);
}

[Kafka] 5. 스키마 레지스트리

mandykr — Tue, 18 Apr 2023 13:28:21 +0900

1. 스키마

2. 스키마 레지스트리

3. Avro

4. 스키마 레지스트리 동작 방식

5. 스키마 호환성

6. 스키마 레지스트리 실습

카프카를 사용하면서 스키마 레지스트리를 사용해야 하는 이유와 스키마 레지스트리의 동작 방식을 알아본다.

1. 스키마

카프카의 데이터 흐름은 대부분 브로트캐스트 방식이기 때문에 프로듀서를 일방적으로 신뢰할 수밖에 없는 방식이다. 따라서 프로듀서 관리자는 카프카 토픽의 데이터를 컨슘하는 관리자에게 반드시 데이터 구조를 설명해야 한다. 데이터를 컨슘하는 부서가 많고 관리자가 자주 바뀐다면 그때마다 데이터 구조를 설명하는 일이 쉬운 일은 아닐것이다. 이와 같이 데이터를 컨슘하는 여러 부서에게 그 데이터에 대한 정확한 정의와 의미를 알려주는 역할을 스키마를 통해 할 수 있다.

그 외에도 비즈니스 변화 등에 따라 모델링이나 데이터 포맷이 변경되는 경우 새로운 필드를 추가하거나 필드 이름을 변경 또는 삭제해야 하는데 이러한 스키마의 진화도 카프카에서 지원하기 때문에 애플리케이션들이 별다른 영향없이 스키마를 변경할 수 있다.

2. 스키마 레지스트리

스키마 레지스트리는 카프카에서 스키마를 등록하고 관리하는 별도의 애플리케이션이다.

프로듀서와 컨슈머는 스키마 레지스트리와 직접적으로 통신하는데 스키마 레지스트리가 지원하는 데이터 포맷을 사용해야 하며 대표적인 포맷이 Avro 이다.

3. Avro

Avro 는 시스템, 프로그래밍 언어, 프로세싱 프레임워크 사이에서 데이터 교환을 도와주는 오픈소스 직렬화 시스템이다.

스키마 레지스트리는 Avro, JSON, Protocol Buffer 포맷을 지원한다.

따라서 이 중 한 가지를 선택해 사용해야 하며 컨플루언트는 다음과 같은 이유로 Avro 포맷 사용을 권장한다.

Avro는 JSON과 매핑된다.
Avro는 매우 간결한 데이터 포맷이다.
JSON은 메시지마다 필드 네임들이 포함되어 전송되므로 효율이 떨어진다.
Avro는 바이너리 형태이므로 매우 빠르다.

{
    "namespace": "student.avro",
    "type": "record",
    "doc": "This is an example of Avro.",
    "name": "Student",
    "fields": [
        {"name": "name", "type": "string", "doc": "Name of the student"},
        {"name": "class", "type": "int", "doc": "Class of the student"},
    ]
}

namespace: 이름을 식별하는 문자열
type: Avro는 record, enums, arrays, maps 등을 지원
doc: 사용자들에게 이 스키마 정의에 대한 설명 제공(주석)
name: 레코드의 이름을 나타내는 문자열, 필수값
fields: JSON 배열로서 필드들의 리스트를 뜻함
- name: 필드의 이름
- type: boolean, int, long, string 등의 데이터 타입 정의
- doc: 사용자들에게 해당 필드의 의미 설명(주석)

4. 스키마 레지스트리 동작 방식

프로듀서와 컨슈머가 각자 스키마 레지스트리와 통신하면서 스키마의 정보를 주고받을 수 있다.

프로듀서가 스키마 정보를 스키마 레지스트리에 등록함으로써 프로듀서가 전송하는 메시지의 크기와 컨슈머가 읽는 메시지의 크기도 줄일 수 있고 사전에 정의되지 않은 형식의 메시지는 전송할 수 없기 때문에 컨슈머에서 해당 처리에 대한 고민을 줄일 수 있다.

출처: https://docs.confluent.io/platform/current/schema-registry/fundamentals/index.html#schemas-subjects-and-topics

로컬 캐시에 없으면, 스키마 전송(등록)
Avro 프로듀서는 컨플루언트에서 제공하는 io.confluent.kafka.serializers.KafkaAvroSerializer 라는 새로운 직렬화를 사용해 스키마 레지스트리의 스키마가 유효한지 여부를 확인한다. 만약 스키마가 확인되지 않으면 Avro 프로듀서는 스키마를 등록하고 캐시한다.
스키마 등록(ID 할당)
스키마 레지스트리는 현 스키마가 저장소에 저장된 스키마와 동일한 것인지, 진화한 스키마인지 확인한다. 스키마 레지스트리 자체적으로 각 스키마에 대해 고유 ID를 할당한다. 이 ID는 순차적으로 1씩 증가하지만, 반드시 연속적이진 않다. 스키마에 문제가 없다면 스키마 레지스트리라는 프로듀서에게 고유 ID를 응답한다.
스키마 ID별 Avro 메시지 직렬화 전송
프로듀서는 스키마 레지스트리로부터 받은 스키마 ID를 참고해 메시지를 카프카로 전송한다. 이때 프로듀서는 스키마의 전체 내용이 아닌 오로지 메시지와 스키마 ID만 보낸다. JSON은 key:value 형태로 전체 메시지를 전송해야 하지만, Avro를 사용하면 프로듀서가 스키마 ID와 밸류만 메시지로 보내게 되어 카프카로 전송하는 전체 메시지의 크기를 줄일 수 있다.
로컬 캐시에 없으면 스키마 ID별로 가져오기
Avro 컨슈머는 스키마 ID로 컨플루언트에서 제공하는 io.confluent.kafka.serializers.KafkaAvroDeserializer 라는 새로운 역직렬화를 사용해 카프카의 토픽에 저장된 메시지를 읽는다. 이때 컨슈머가 스키마 ID를 갖고있지 않다면 스키마 레지스트리로부터 가져온다.

5. 스키마 호환성

스키마 레지스트리는 하나의 서브젝트에 대한 버전 정보별로 진화하는 각 스키마를 고유한 ID와 함께 관리해준다. 또한 스키마가 진화함에 따라 호환성 레벨을 검사해야 하는데, 스키마 레지스트리에서는 BACKWARD, FORWARD, FULL 호환성 레벨을 제공한다.

1) BACKWARD 호환성

BACKWARD 호환성은 진화된 스키마를 적용한 컨슈머가 진화 전의 스키마가 적용된 프로듀서가 보낸 메시지를 읽을 수 있도록 허용하는 호환성이다.

호환성 레벨	지원 버전(컨슈머 기준)	변경 허용 항목	스키마 업데이트 순서
BACKWARD	자신과 동일한 버전과 하나 아래의 하위 버전	필드 삭제, 기본 값이 지정된 필드 추가	컨슈머 -> 프로듀서
BACKWARD_TRANSITIVE	자신과 동일한 버전을 포함한 모든 하위 버전	필드 삭제, 기본 값이 지정된 필드 추가	컨슈머 -> 프로듀서

2) FORWARD 호환성

FORWARD 호환성은 진화된 스키마가 적용된 프로듀서가 보낸 메시지를 진화 전의 스키마가 적용된 컨슈머가 읽을 수 있게 하는 호환성이다.

호환성 레벨	지원 버전(컨슈머 기준)	변경 허용 항목	스키마 업데이트 순서
FORWARD	자신과 동일한 버전과 하나 위의 상위 버전	필드 추가, 기본 값이 지정된 필드 삭제	프로듀서 -> 컨슈머
FORWARD_TRANSITIVE	자신과 동일한 버전을 포함한 모든 상위 버전	필드 추가, 기본 값이 지정된 필드 삭제	프로듀서 -> 컨슈머

3) FULL 호환성

FULL 호환성은 BACKWARD와 FORWARD 호환성 모두를 지원한다.

호환성 레벨	지원 버전(컨슈머 기준)	변경 허용 항목	스키마 업데이트 순서
FULL	자신과 동일한 버전과 하나 위 또는 하나 아래 버전	기본값이 지정된 필드 추가, 기본 값이 지정된 필드 삭제	순서 상관 없음
FULL_TRANSITIVE	자신과 동일한 버전을 포함한 모든 상위 버전과 하위 버전	기본값이 지정된 필드 추가, 기본 값이 지정된 필드 삭제	순서 상관 없음

6. 스키마 레지스트리 실습

프로젝트 구성

Java 11
Spring boot 2.7.9
Oracle VM VirtualBox
Confluent Kafka 7.2.1

VM에 Confluent Kafka 를 구성하고 주키퍼, 카프카, 스키마 레지스트리 순서로 기동한다.

IP: 192.168.56.101

zookeeper-server-start etc/kafka/zookeeper.properties
kafka-server-start etc/kafka/server.properties
schema-registry-start etc/schema-registry/schema-registry.properties

Confluent Cloud Schema Registry and Spring Boot 를 참고해 Spring boot 프로젝트를 설정한다.

build.gradle

plugins {
    id "com.github.davidmc24.gradle.plugin.avro" version "1.2.0"
    id "idea"
}

repositories {
    gradlePluginPortal()
    mavenCentral()

    maven {
        url "https://packages.confluent.io/maven"
    }
}

dependencies {
    implementation 'org.springframework.kafka:spring-kafka'
    implementation 'org.apache.avro:avro:1.11.0'
    implementation "io.confluent:kafka-avro-serializer:6.1.0"
}

application.properties

spring.kafka.producer.bootstrap-servers=192.168.56.101:9092
spring.kafka.producer.properties.schema.registry.url=http://192.168.56.101:8081
spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer
spring.kafka.producer.value-serializer=io.confluent.kafka.serializers.KafkaAvroSerializer

src/main/avro/ReviewMessage.avsc

{
  "type": "record",
  "name": "ReviewMessage",
  "namespace": "com.papaco.avro.schema",
  "fields": [
    {
      "name": "id",
      "type": "string"
    },
    {
      "name": "mateId",
      "type": "string"
    },
    {
      "name": "status",
      "type": "string"
    }
  ]
}

Gradle 탭에서 Tasks > source generation > generateAvro 를 실행하면 build/generated-main-avro-java 패키지에 ReviewMessage.avsc 파일을 사용해 ReviewMessage Java 클래스가 생성된다.

kafkaTemplate 을 이용해 브로커로 메시지를 전송한다.

KafkaTemplate<String, ReviewMessage> kafkaTemplate;

Schema Registry API 를 통해 스키마 정보를 확인할 수 있다.

$ curl -s "http://localhost:8081/subjects/papaco.review-value/versions/1"
{"subject":"papaco.review-value","version":1,"id":1,"schema":"{\"type\":\"record\",\"name\":\"ReviewMessage\",\"namespace\":\"com.papaco.avro.schema\",\"fields\":[{\"name\":\"id\",\"type\":{\"type\":\"string\",\"avro.java.string\":\"String\"}},{\"name\":\"mateId\",\"type\":{\"type\":\"string\",\"avro.java.string\":\"String\"}},{\"name\":\"status\",\"type\":{\"type\":\"string\",\"avro.java.string\":\"String\"}}]}"}

kafka-avro-console-consumer 를 통해 전송된 데이터를 카프카 서버에서 확인할 수 있다.

$ kafka-avro-console-consumer \
 --topic papaco.review \
 --property schema.registry.url=http://localhost:8081 \
 --bootstrap-server localhost:9092 \
 --property key.deserializer=org.apache.kafka.common.serialization.StringDeserializer \
 --property print.key=true \
 --property key.separator="-" \
 --from-beginning
e747975b-caa3-402a-bf10-a4aca10473f6-{"id":"e747975b-caa3-402a-bf10-a4aca10473f6","mateId":"6fec2b25-9ad4-4dba-9f54-bc3c3305a6a5","status":"DEMANDED"}

참고

실전 카프카 개발부터 운영까지

[Kafka] Spring Kafka 구성(Broker, Producer, Consumer)

mandykr — Tue, 21 Mar 2023 13:55:20 +0900

도메인 이벤트를 발생시키는 프로듀서와 이벤트를 가져와 데이터를 변경하는 컨슈머를 구성한다.

메시지 중복 저장을 방지하는 멱등성 프로듀서를 구성하고 카프카 클러스터는 3개의 브로커를 가지는 멀티 노드 클러스터로 만들어 가용성을 높인다. 컨슈머는 브로커 파티션의 갯수만큼 멀티 스레드로 구성해 데이터를 병렬로 처리하도록 한다.

1. 개발 환경

java 11
spring boot 2.7.x
gradle
confluent kafka 3.x
oracle VM

2. 카프카 환경 설정

confluent-kafka 설치

$ wget https://packages.confluent.io/archive/7.2/confluent-community-7.2.1.tar.gz
$ tar xvf confluent-community-7.2.1.tar.gz

힙 메모리, path 설정

$ mv confluent-7.2.1 confluent

$ vi ~/.bashrc
export KAFKA_HEAP_OPTS="-Xmx400m -Xms400m"
export CONFLUENT_HOME=/home/ec2-user/confluent
export PATH=.:$PATH:$CONFLUENT_HOME/bin

$ source ~/.bashrc
$ echo $KAFKA_HEAP_OPTS
$ echo $CONFLUENT_HOME

멀티 노드 설정

[zookeeper]
$ vi etc/kafka/zookeeper.properties
dataDir=/home/mandy/data/zookeeper-logs

$ mkdir /home/mandy/data/zookeeper-logs

kafka broker 실행 옵션 설정

[kafka-x]
$ vi etc/kafka/server.properties
broker.id=0
listeners=PLAINTEXT://:9092
advertised.listeners=PLAINTEXT://kafka-x-IP:9092
log.dirs=/home/mandy/data/kafka-logs
zookeeper.connect=zookeeper:2181

$ mkdir -p /home/mandy/data/kafka-logs

schema registry 실행 옵션 설정

$ vi etc/schema-registry/schema-registry.properties

zookeeper, broker, schema registry 구동

[zookeeper]
$ zookeeper-server-start etc/kafka/zookeeper.properties

[kafka-x]
$ kafka-server-start etc/kafka/server_0.properties
$ kafka-server-start etc/kafka/server_1.properties
$ kafka-server-start etc/kafka/server_2.properties

[zookeeper]
$ schema-registry-start etc/schema-registry/schema-registry.properties

파일 시스템 구조

home
├── mandy
│   ├── data
│   │   ├── zookeeper-logs
│   │   ├── kafka-logs
│   ├── confluent
│   │   ├── bin
│   │   │   ├── kafka-configs
│   │   │   ├── kafka-console-consumer
│   │   │   ├── kafka-console-producer
│   │   │   ├── kafka-server-start
│   │   │   ├── kafka-topics
│   │   │   ├── zookeeper-server-start
│   │   │   ├── schema-registry-start
│   │   │   ├── ksql-server-start
│   │   ├── etc
│   │   │   ├── kafka
│   │   │   │   ├── server.properties
│   │   │   │   └── zookeeper.properties
│   │   ├── lib
│   │   ├── LICENSE
│   │   ├── logs
│   │   │   ├── server.log

3. 개발

1) 토픽

토픽 생성

$ kafka-topics --bootstrap-server localhost:9092 \
--create \
--topic papaco.review \
--partitions 3 \
--replication-factor 3
--config min.insync.replicas=2

파티션 개수

● partitions 3

메시지 키를 사용해 데이터 처리 순서를 지켜야 하기 때문에 토픽을 생성할 때 파티션을 엄격하게 결정한다.

프로듀서가 기본 파티셔너를 사용할 때 파티션 개수가 달라지면 이미 매칭된 파티션과 메시지 키의 매칭이 깨지고 전혀 다른 파티션에 데이터가 할당될 수 있기 때문이다.

복제 개수

● replication-factor 3

복제 개수가 높으면 높을수록 데이터의 복구 확률이 높아지지만 복제 개수가 너무 높으면 팔로워 파티션이 데이터를 복제하는 데에 시간이 오래 걸릴 수 있으면 클러스터 전체를 봤을 때 저장되는 데이터의 용량도 그만큼 더 늘어난다.

클러스터의 브로커 1대에 이슈가 발생했을 경우에도 안정적으로 데이터를 받기 위해 최소 2 이상으로 설정한다.

최소 동기화 리플리카

● min.insync.replicas=2

ISR의 2개 이상의 파티션에 적재되었음을 확인한다. 리더 파티션과 1개의 팔로워 파티션에 데이터가 정상적으로 적재되었음을 보장한다. min.insync.replicas 옵션은 프로듀서의 acks를 all로 설정한 경우에만 유효하다.

브로커의 복제 개수와 동일하게 설정하면 클러스터의 브로커 1대만이라도 이슈가 발생하여 동작하지 못하는 경우 최소 파티션의 개수가 부족하기 때문에 프로듀서가 데이터를 토픽에 전송할 수 없게 된다.

토픽 확인

$ kafka-configs --bootstrap-server localhost:9092 --entity-type topics --entity-name papaco.review --describe --all
All configs for topic papaco.review are:
  compression.type=producer sensitive=false synonyms={DEFAULT_CONFIG:compression.type=producer}
  leader.replication.throttled.replicas= sensitive=false synonyms={}
  message.downconversion.enable=true sensitive=false synonyms={DEFAULT_CONFIG:log.message.downconversion.enable=true}
  min.insync.replicas=2 sensitive=false synonyms={DYNAMIC_TOPIC_CONFIG:min.insync.replicas=2, DEFAULT_CONFIG:min.insync.replicas=1}
  segment.jitter.ms=0 sensitive=false synonyms={}
  cleanup.policy=delete sensitive=false synonyms={DEFAULT_CONFIG:log.cleanup.policy=delete}
  flush.ms=9223372036854775807 sensitive=false synonyms={}
  follower.replication.throttled.replicas= sensitive=false synonyms={}
  segment.bytes=1073741824 sensitive=false synonyms={STATIC_BROKER_CONFIG:log.segment.bytes=1073741824, DEFAULT_CONFIG:log.segment.bytes=1073741824}
  retention.ms=604800000 sensitive=false synonyms={}
  flush.messages=9223372036854775807 sensitive=false synonyms={DEFAULT_CONFIG:log.flush.interval.messages=9223372036854775807}
  message.format.version=3.0-IV1 sensitive=false synonyms={DEFAULT_CONFIG:log.message.format.version=3.0-IV1}
  max.compaction.lag.ms=9223372036854775807 sensitive=false synonyms={DEFAULT_CONFIG:log.cleaner.max.compaction.lag.ms=9223372036854775807}
  file.delete.delay.ms=60000 sensitive=false synonyms={DEFAULT_CONFIG:log.segment.delete.delay.ms=60000}
  max.message.bytes=1048588 sensitive=false synonyms={DEFAULT_CONFIG:message.max.bytes=1048588}
  min.compaction.lag.ms=0 sensitive=false synonyms={DEFAULT_CONFIG:log.cleaner.min.compaction.lag.ms=0}
  message.timestamp.type=CreateTime sensitive=false synonyms={DEFAULT_CONFIG:log.message.timestamp.type=CreateTime}
  preallocate=false sensitive=false synonyms={DEFAULT_CONFIG:log.preallocate=false}
  min.cleanable.dirty.ratio=0.5 sensitive=false synonyms={DEFAULT_CONFIG:log.cleaner.min.cleanable.ratio=0.5}
  index.interval.bytes=4096 sensitive=false synonyms={DEFAULT_CONFIG:log.index.interval.bytes=4096}
  unclean.leader.election.enable=false sensitive=false synonyms={DEFAULT_CONFIG:unclean.leader.election.enable=false}
  retention.bytes=-1 sensitive=false synonyms={DEFAULT_CONFIG:log.retention.bytes=-1}
  delete.retention.ms=86400000 sensitive=false synonyms={DEFAULT_CONFIG:log.cleaner.delete.retention.ms=86400000}
  segment.ms=604800000 sensitive=false synonyms={}
  message.timestamp.difference.max.ms=9223372036854775807 sensitive=false synonyms={DEFAULT_CONFIG:log.message.timestamp.difference.max.ms=9223372036854775807}
  segment.index.bytes=10485760 sensitive=false synonyms={DEFAULT_CONFIG:log.index.size.max.bytes=10485760}

리더 파티션 선출

● unclean.leader.election.enable=false

리더 파티션의 브로커에 장애가 발생한 경우, ISR이 아닌 팔로워 파티션을 리더 파티션으로 선출하지 않고 리더 파티션이 존재하는 브로커가 다시 실행될 때까지 기다린다.

그동안 서비스가 중단되지만 데이터의 유실은 발생하지 않는다.

2) 프로듀서

(1) 프로듀서 설정

application.properties

spring.kafka.producer.bootstrap-servers=192.168.56.101:9092
spring.kafka.producer.properties.schema.registry.url=http://192.168.56.101:8081
spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer
spring.kafka.producer.value-serializer=io.confluent.kafka.serializers.KafkaAvroSerializer
spring.kafka.producer.properties.enable.idempotence=true

ProducerConfig

(org.apache.kafka.clients.producer.ProducerConfig)

ProducerConfig values: 
	acks = -1
	batch.size = 16384
	bootstrap.servers = [192.168.56.101:9092]
	buffer.memory = 33554432
	client.dns.lookup = use_all_dns_ips
	client.id = producer-1
	compression.type = none
	connections.max.idle.ms = 540000
	delivery.timeout.ms = 120000
	enable.idempotence = true
	interceptor.classes = []
	key.serializer = class org.apache.kafka.common.serialization.StringSerializer
	linger.ms = 0
	max.block.ms = 60000
	max.in.flight.requests.per.connection = 5
	max.request.size = 1048576
	metadata.max.age.ms = 300000
	metadata.max.idle.ms = 300000
	metric.reporters = []
	metrics.num.samples = 2
	metrics.recording.level = INFO
	metrics.sample.window.ms = 30000
	partitioner.class = class org.apache.kafka.clients.producer.internals.DefaultPartitioner
	receive.buffer.bytes = 32768
	reconnect.backoff.max.ms = 1000
	reconnect.backoff.ms = 50
	request.timeout.ms = 30000
	retries = 2147483647
	retry.backoff.ms = 100
	sasl.client.callback.handler.class = null
	sasl.jaas.config = null
	sasl.kerberos.kinit.cmd = /usr/bin/kinit
	sasl.kerberos.min.time.before.relogin = 60000
	sasl.kerberos.service.name = null
	sasl.kerberos.ticket.renew.jitter = 0.05
	sasl.kerberos.ticket.renew.window.factor = 0.8
	sasl.login.callback.handler.class = null
	sasl.login.class = null
	sasl.login.connect.timeout.ms = null
	sasl.login.read.timeout.ms = null
	sasl.login.refresh.buffer.seconds = 300
	sasl.login.refresh.min.period.seconds = 60
	sasl.login.refresh.window.factor = 0.8
	sasl.login.refresh.window.jitter = 0.05
	sasl.login.retry.backoff.max.ms = 10000
	sasl.login.retry.backoff.ms = 100
	sasl.mechanism = GSSAPI
	sasl.oauthbearer.clock.skew.seconds = 30
	sasl.oauthbearer.expected.audience = null
	sasl.oauthbearer.expected.issuer = null
	sasl.oauthbearer.jwks.endpoint.refresh.ms = 3600000
	sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms = 10000
	sasl.oauthbearer.jwks.endpoint.retry.backoff.ms = 100
	sasl.oauthbearer.jwks.endpoint.url = null
	sasl.oauthbearer.scope.claim.name = scope
	sasl.oauthbearer.sub.claim.name = sub
	sasl.oauthbearer.token.endpoint.url = null
	security.protocol = PLAINTEXT
	security.providers = null
	send.buffer.bytes = 131072
	socket.connection.setup.timeout.max.ms = 30000
	socket.connection.setup.timeout.ms = 10000
	ssl.cipher.suites = null
	ssl.enabled.protocols = [TLSv1.2, TLSv1.3]
	ssl.endpoint.identification.algorithm = https
	ssl.engine.factory.class = null
	ssl.key.password = null
	ssl.keymanager.algorithm = SunX509
	ssl.keystore.certificate.chain = null
	ssl.keystore.key = null
	ssl.keystore.location = null
	ssl.keystore.password = null
	ssl.keystore.type = JKS
	ssl.protocol = TLSv1.3
	ssl.provider = null
	ssl.secure.random.implementation = null
	ssl.trustmanager.algorithm = PKIX
	ssl.truststore.certificates = null
	ssl.truststore.location = null
	ssl.truststore.password = null
	ssl.truststore.type = JKS
	transaction.timeout.ms = 60000
	transactional.id = null
	value.serializer = class io.confluent.kafka.serializers.KafkaAvroSerializer

acks 옵션

● ack=all

ack 를 all로 설정하면 min.insync.replicas 개수 만큼의 Replicator에 복제를 수행한 뒤에 리더 브로커가 보내는 Ack 를 받은 후 다음 메시지를 전송한다. 1이나 0에 비해 프로듀서가 클러스터로 데이터를 저장하는 데에 시간이 오래 걸리지만 클러스터 또는 네트워크에 이상이 생겼을 경우 복구할 확률이 가장 높다.

파티셔너

● partitioner.class = class org.apache.kafka.clients.producer.internals.DefaultPartitioner

DefaultPartitioner는 키를 가지는 메시지의 경우 키 값을 Hashing하여 키 값에 따라 파티션 별로 균일하게 전송한다.

파티셔너에 의해 구분된 레코드는 데이터를 전송하기 전에 어큐뮬레이터에 데이터를 버퍼로 쌓아놓고 발송한다. 버퍼로 쌓인 데이터는 배치로 묶어서 전송함으로써 프로듀서 처리량을 향상시킨다.

어큐뮬레이터

● buffer.memory = 33554432

● linger.ms = 0

● batch.size = 16384

전반적인 Producer와 Broker간의 전송이 느리다면 linger.ms를 0보다 크게 설정하여 Sender Thread가 하나의 Record Batch를 가져갈 때 일정 시간 대기하여 Record Batch에 메시지를 보다 많이 채울 수 있도록 적용할 수 있다.

linger.ms는 보통 20ms 이하로 설정을 권장한다.

재시도

● retries = 2147483647

● request.timeout.ms = 30000

● linger.ms = 0

● retry.backoff.ms = 100

● delivery.timeout.ms = 120000

Sender Thread가 0ms(linger.ms)만큼 대기한 후에 Record Accumulator에서 레코드를 배치별로 가져간다.

Sender Thread는 배치를 브로커로 전송하고 30000ms(request.timeout.ms)만큼 대기한 후

리더 브로커로부터 에러 메시지를 받으면 100ms(retry.backoff.ms) 후에 재전송을 시도한다.

이와 같은 방식으로 재전송을 2147483647회(retries) 시도하고 더 이상 retry 시도 하지 않는다.

멱등성 프로듀서

● enable.idempotence=true

동일한 데이터를 여러번 전송하더라도 카프카 클러스터에 단 한번만 저장되도록 한다.(정확히 한번 전달)

멱등성 프로듀서는 기본 프로듀서와 달리 데이터를 브로커로 전달할 때 프로듀서 PID와 시퀀스 넘버를 함께 전달한다. 그러면 브로커는 프로듀서의 PID와 시퀀스 넘버를 확인하여 동이한 메시지의 적재 요청이 오더라도 단 한번만 데이터를 적재한다.

(2) 데이터 포맷

Avro

● value.serializer = class io.confluent.kafka.serializers.KafkaAvroSerializer

KafkaAvroSerializerConfig

(io.confluent.kafka.serializers.KafkaAvroSerializerConfig)

KafkaAvroSerializerConfig values: 
	auto.register.schemas = true
	basic.auth.credentials.source = URL
	basic.auth.user.info = [hidden]
	bearer.auth.credentials.source = STATIC_TOKEN
	bearer.auth.token = [hidden]
	key.subject.name.strategy = class io.confluent.kafka.serializers.subject.TopicNameStrategy
	latest.compatibility.strict = true
	max.schemas.per.subject = 1000
	proxy.host = 
	proxy.port = -1
	schema.reflection = false
	schema.registry.basic.auth.user.info = [hidden]
	schema.registry.ssl.cipher.suites = null
	schema.registry.ssl.enabled.protocols = [TLSv1.2, TLSv1.3]
	schema.registry.ssl.endpoint.identification.algorithm = https
	schema.registry.ssl.engine.factory.class = null
	schema.registry.ssl.key.password = null
	schema.registry.ssl.keymanager.algorithm = SunX509
	schema.registry.ssl.keystore.certificate.chain = null
	schema.registry.ssl.keystore.key = null
	schema.registry.ssl.keystore.location = null
	schema.registry.ssl.keystore.password = null
	schema.registry.ssl.keystore.type = JKS
	schema.registry.ssl.protocol = TLSv1.3
	schema.registry.ssl.provider = null
	schema.registry.ssl.secure.random.implementation = null
	schema.registry.ssl.trustmanager.algorithm = PKIX
	schema.registry.ssl.truststore.certificates = null
	schema.registry.ssl.truststore.location = null
	schema.registry.ssl.truststore.password = null
	schema.registry.ssl.truststore.type = JKS
	schema.registry.url = [http://192.168.56.101:8081]
	use.latest.version = false
	value.subject.name.strategy = class io.confluent.kafka.serializers.subject.TopicNameStrategy

스키마 레지스트리

● schema.registry.url = [http://192.168.56.101:8081]

● key.subject.name.strategy = class io.confluent.kafka.serializers.subject.TopicNameStrategy

● value.subject.name.strategy = class io.confluent.kafka.serializers.subject.TopicNameStrategy

(3) 메시지 전송

private final KafkaTemplate<String, ReviewMessage> kafkaTemplate;

public void sendMessage(ReviewEvent event) {
    // ...
    
    kafkaTemplate.send(topic, key, message).addCallback(new ListenableFutureCallback<SendResult<String, ReviewMessage>>() {
        @Override
        public void onFailure(Throwable ex) {
            log.error("kafka send error: {}", ex.getMessage());
        }

        @Override
        public void onSuccess(SendResult<String, ReviewMessage> result) {
            log.info("kafka send result: {}", result.toString());
        }
    });
}

3) 컨슈머

(1) 컨슈머 설정

application.properties

spring.kafka.consumer.bootstrap-servers=192.168.56.101:9092,192.168.56.101:9093,192.168.56.101:9094
spring.kafka.consumer.properties.schema.registry.url=http://192.168.56.101:8081
spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringDeserializer
spring.kafka.consumer.value-deserializer=io.confluent.kafka.serializers.KafkaAvroDeserializer
spring.kafka.consumer.properties.allow.auto.create.topics=false
spring.kafka.consumer.properties.auto.offset.reset=earliest
spring.kafka.consumer.properties.specific.avro.reader=true
spring.kafka.listener.type=BATCH
spring.kafka.listener.ack-mode=MANUAL

ConsumerConfig

(org.apache.kafka.clients.consumer.ConsumerConfig)

ConsumerConfig values: 
	allow.auto.create.topics = false
	auto.commit.interval.ms = 5000
	auto.offset.reset = earliest
	bootstrap.servers = [192.168.56.101:9092, 192.168.56.101:9093, 192.168.56.101:9094]
	check.crcs = true
	client.dns.lookup = use_all_dns_ips
	client.id = consumer-papaco-review-project-query-1
	client.rack = 
	connections.max.idle.ms = 540000
	default.api.timeout.ms = 60000
	enable.auto.commit = false
	exclude.internal.topics = true
	fetch.max.bytes = 52428800
	fetch.max.wait.ms = 500
	fetch.min.bytes = 1
	group.id = papaco-review-project-query
	group.instance.id = null
	heartbeat.interval.ms = 3000
	interceptor.classes = []
	internal.leave.group.on.close = true
	internal.throw.on.fetch.stable.offset.unsupported = false
	isolation.level = read_uncommitted
	key.deserializer = class org.apache.kafka.common.serialization.StringDeserializer
	max.partition.fetch.bytes = 1048576
	max.poll.interval.ms = 300000
	max.poll.records = 500
	metadata.max.age.ms = 300000
	metric.reporters = []
	metrics.num.samples = 2
	metrics.recording.level = INFO
	metrics.sample.window.ms = 30000
	partition.assignment.strategy = [class org.apache.kafka.clients.consumer.RangeAssignor, class org.apache.kafka.clients.consumer.CooperativeStickyAssignor]
	receive.buffer.bytes = 65536
	reconnect.backoff.max.ms = 1000
	reconnect.backoff.ms = 50
	request.timeout.ms = 30000
	retry.backoff.ms = 100
	sasl.client.callback.handler.class = null
	sasl.jaas.config = null
	sasl.kerberos.kinit.cmd = /usr/bin/kinit
	sasl.kerberos.min.time.before.relogin = 60000
	sasl.kerberos.service.name = null
	sasl.kerberos.ticket.renew.jitter = 0.05
	sasl.kerberos.ticket.renew.window.factor = 0.8
	sasl.login.callback.handler.class = null
	sasl.login.class = null
	sasl.login.connect.timeout.ms = null
	sasl.login.read.timeout.ms = null
	sasl.login.refresh.buffer.seconds = 300
	sasl.login.refresh.min.period.seconds = 60
	sasl.login.refresh.window.factor = 0.8
	sasl.login.refresh.window.jitter = 0.05
	sasl.login.retry.backoff.max.ms = 10000
	sasl.login.retry.backoff.ms = 100
	sasl.mechanism = GSSAPI
	sasl.oauthbearer.clock.skew.seconds = 30
	sasl.oauthbearer.expected.audience = null
	sasl.oauthbearer.expected.issuer = null
	sasl.oauthbearer.jwks.endpoint.refresh.ms = 3600000
	sasl.oauthbearer.jwks.endpoint.retry.backoff.max.ms = 10000
	sasl.oauthbearer.jwks.endpoint.retry.backoff.ms = 100
	sasl.oauthbearer.jwks.endpoint.url = null
	sasl.oauthbearer.scope.claim.name = scope
	sasl.oauthbearer.sub.claim.name = sub
	sasl.oauthbearer.token.endpoint.url = null
	security.protocol = PLAINTEXT
	security.providers = null
	send.buffer.bytes = 131072
	session.timeout.ms = 45000
	socket.connection.setup.timeout.max.ms = 30000
	socket.connection.setup.timeout.ms = 10000
	ssl.cipher.suites = null
	ssl.enabled.protocols = [TLSv1.2, TLSv1.3]
	ssl.endpoint.identification.algorithm = https
	ssl.engine.factory.class = null
	ssl.key.password = null
	ssl.keymanager.algorithm = SunX509
	ssl.keystore.certificate.chain = null
	ssl.keystore.key = null
	ssl.keystore.location = null
	ssl.keystore.password = null
	ssl.keystore.type = JKS
	ssl.protocol = TLSv1.3
	ssl.provider = null
	ssl.secure.random.implementation = null
	ssl.trustmanager.algorithm = PKIX
	ssl.truststore.certificates = null
	ssl.truststore.location = null
	ssl.truststore.password = null
	ssl.truststore.type = JKS
	value.deserializer = class io.confluent.kafka.serializers.KafkaAvroDeserializer

bootstrap-servers

● spring.kafka.consumer.bootstrap-servers=192.168.56.101:9092,192.168.56.101:9093,192.168.56.101:9094

bootstrap-servers 는 브로커 리스너들의 리스트이고 브로커들의 메타정보를 가져오는데 사용된다.

카프카 브로커들은 토픽 파티션의 Leader와 Follower들의 메타 정보를 서로 공유하고 있는데 카프카 컨슈머는 bootstrap-servers 에 접속해 이 메타 정보를 가져오고 메타 정보를 통해 토픽의 파티션이 있는 브로커로 다시 접속하게 된다.

2개 이상 브로커 정보를 입력하여 일부 브로커에 이슈가 발생하더라도 접속하는 데에 이슈가 없도록 설정 가능하다.

(프로듀서도 동일)

auto.offset.reset

● auto.offset.reset = earliest

__consumer_offsets에 컨슈머 그룹이 해당 토픽의 파티션별로 offset 정보를 가지고 있지 않을 때 컨슈머가 접속하면 파티션의 처음 offset 부터 가져오도록 설정한다.

Consumer Fetcher 설정 파라미터

● fetch.min.bytes = 1

● fetch.max.wait.ms = 500

● fetch.max.bytes = 52428800

● max.partition.fetch.bytes = 1048576

● max.poll.records = 500

● BatchConsumerAwareMessageListener.DEFAULT_COMMIT_TIMEOUT = 30; (스프링 카프카 컨슈머)

Fetcher가 Linked Queue에서 가져오는 레코드의 개수는 500(max.poll.records)으로 제한한다.

Linked Queue에 데이터가 없으면 ConsumerNetworkClient는 30초(DEFAULT_COMMIT_TIMEOUT)까지 Broker에 메시지를 요청한다.

ConsumerNetworkClient가 브로커에서 가져오는 레코드 배치의 최대 크기는 max.partition.fetch.bytes와 fetch.max.bytes로 설정한다.

리밸런스 관련 컨슈머 파라미터

● heartbeat.interval.ms = 3000

● session.timeout.ms = 45000

● max.poll.interval.ms = 300000

컨슈머는 3초(heartbeat.interval.ms)마다 브로커로 heartbeat을 보낸다.

컨슈머가 45초(session.timeout.ms)만큼 heartbeat을 보내지 않거나,

300초(max.poll.interval.ms)만큼 poll() 호출을 하지 않으면 브로커(코디네이터)는 리밸런스 명령을 리더 컨슈머에게 보낸다.

● partition.assignment.strategy = [class org.apache.kafka.clients.consumer.CooperativeStickyAssignor]

리밸런스 발생시 기존 토픽들의 파티션과 컨슈머 매핑은 최대한 유지하고 재할당되어야 하는 파티션들만 컨슈머에 따라 순차적으로 재할당을 수행한다. 모든 파티션 할당을 취소하지 않는 Cooperative 모드에서 동작한다.

(2) 메시지 컨슘

@KafkaListener(
            topics = "${papaco.kafka.review.avro.topic.name}", 
            groupId = "papaco-review-project-query",
            concurrency = "3")
public void listenReview(ConsumerRecords<String, ReviewMessage> records, Consumer<String, String> consumer) {
    consumer.commitSync();
}

컨슈머 그룹 ID

● @KafkaListener(groupId = "papaco-review-project-query")

review 관련 메시지를 수신하는 컨슈머들을 컨슈머 그룹으로 묶어서 관리한다. 컨슈머 그룹을 기준으로 브로커에서 오프셋(__consumer_offsets)을 관리하고 컨슈머 리밸런스가 발생하면 해당 오프셋을 기준으로 다시 메시지를 가져오기 때문에 메시지 중복이나 유실이 발생하지 않는다.

배치 컨슈머 리스너

● spring.kafka.listener.type=BATCH

● spring.kafka.listener.ack-mode=MANUAL

● public void listenReview(ConsumerRecords<String, ReviewMessage> records, Consumer<String, String> consumer)

● consumer.commitSync();

스프링 카프카 컨슈머에서 제공하는 BATCH 타입의 리스너를 사용해 레코드 묶음(ConsumerRecords)을 파라미터로 받아 한 번에 처리하도록 한다. 또한 AcksMode를 MANUAL로 설정해 Auto commit 이 아닌 동기 혹은 비동기 Manual commit 을 사용하도록 설정한다. Comsumer 객체를 파라미터로 받아 commitSync() 와 같이 Manual commit 메소드를 호출할 수 있다.

동기 오프셋 커밋은 메시지를 읽고 브로커에 commit 적용이 성공적으로 될 때까지 블로킹 하도록해 비동기 방식에 비해 메시지 중복 읽기 가능성을 줄여준다.

멀티 스레드 컨슈머

● @KafkaListener(concurrency = "3")

스프링 카프카 컨슈머는 concurrency 옵션값에 해당하는 만큼 컨슈머 스레드를 만들어서 병렬처리한다.

파티션의 개수만큼 컨슈머 스레드를 늘려서 운영하면 각 스레드에 각 파티션이 할당되며, 데이터 유실의 가능성이 작고 파티션 별로 컨슈머에서 레코드를 처리하므로 메시지 키를 갖는 경우 레코드 처리 역전이 발생하지 않는다.

정리

높은 처리량

카프카는 데이터 송수신을 묶어서 처리할 수 있기 때문에 동일한 양의 데이터에서 네트워크 통신 횟수를 줄일 수 있고, 데이터 배치 처리와 파티션 단위로 병렬 처리가 가능하기 때문에 높은 데이터 처리량을 보인다.

확장성

카프카는 데이터가 적을 때 클러스터의 브로커를 최소한의 개수로 운영하다가 데이터가 많아지면 브로커의 개수를 늘려 스케일 아웃할 수 있다. 반대로 스케일 인도 가능하다.

영속성

카프카는 디스크 기반의 파일 시스템에 데이터를 저장하기 때문에 브로커에 장애가 발생해 종료되더라도 데이터가 사라지지 않는다.

고가용성

3개 이상의 서버들로 운영되는 카프카 클러스터는 데이터를 복제해 저장하기 때문에 일부 서버에 장애가 발생하더라도 무중단으로 안전하고 지속적으로 데이터를 처리할 수 있다.

참고

[Kafka] 4. 카프카 컨슈머

mandykr — Thu, 2 Feb 2023 11:04:31 +0900

1. 컨슈머 Client

2. Poll

3. Heartbeat Thread

4. 리밸런싱

5. 오프셋 커밋

6. 특정 파티션만 할당

7. 컨슈머의 안전한 종료

8. 멀티 스레드 컨슈머

9. 컨슈머 랙

10. 스프링 카프카 컨슈머

1. 컨슈머 Client

카프카 컨슈머는 하나의 컨슈머 그룹에 속해 실행되며 카프카 브로커의 파티션은 컨슈머 그룹내 하나 이상의 컨슈머에 할당된다.

기본 컨슈머 Client API 처리 로직

// 1. Consumer 환경 설정(Properties 객체를 이용)
String topicName = "simple-topic";
Properties props = new Properties();
props.setProperty(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.56.101:9092");
props.setProperty(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
props.setProperty(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
props.setProperty(ConsumerConfig.GROUP_ID_CONFIG, "group-01");
        
// 2. 1에서 설정한 환경 설정값을 반영하여 KafkaConsumer 객체 생성.
KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<String, String>(props);

// 3. 읽어들일 Topic을 subscribe()를 호출하여 설정
kafkaConsumer.subscribe(List.of(topicName));

// 4. 지속적으로 poll( ) 을 호출하여 Topic의 새로운 메시지를 계속 읽어 들임.
while (true) {
    ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofMillis(1000));
    for (ConsumerRecord record : consumerRecords) {
        logger.info("record key:{}, record value:{}, partition:{}",
                record.key(), record.value(), record.partition());
    }
}
        
// 5. KafkaConsumer객체를 명확하게 close() 수행
kafkaConsumer.close();

기본 CLI 명령어

# Consumer Group id group_01을 가지는 consumer를 생성
$ bin/kafka-console-consumer.sh --bootstrap-server kafka-0:9092,kafka-1:9092,kafka-2:9092 --group group_01 --topic topic-p3r3 \
--property print.key=true --property print.value=true \
--property print.partition=true

kafka-consumer-groups.sh

# 컨슈머 그룹 목록 확인
$ bin/kafka-consumer-groups.sh --bootstrap-server kafka-0:9092,kafka-1:9092,kafka-2:9092 --list

# 컨슈머 그룹 내의 컨슈머 정보 확인
$ bin/kafka-consumer-groups.sh --bootstrap-server kafka-0:9092,kafka-1:9092,kafka-2:9092 --describe \
--group group_01

GROUP    TOPIC    PARTITION    CURRENT-OFFSET    LOG-END-OFFSET    LAG    CONSUMER-ID    HOST    CLIENT-ID
goupe_01 topic-p3r3 ...

# 컨슈머 그룹 삭제
$ bin/kafka-consumer-groups.sh --bootstrap-server kafka-0:9092,kafka-1:9092,kafka-2:9092 --delete \
--group group_01

2. Poll

ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofMillis(1000));

동작 과정

ConsumerNetworkClient는 비동기로 계속 브로커의 메시지를 가져와서 Linked Queue에 저장
Fetcher는 Linked Queue에서 데이터를 읽음
Linked Queue에 데이터가 있을 경우 Fetcher는 데이터를 가져오고 반환 하며 poll() 수행 완료
Linked Queue에 데이터가 없을 경우 Fetcher가 ConsumerNetworkClient에게 데이터를 브로커로 부터 가져올 것을 요청
ConsumerNetworkClient는 1000ms 까지 Broker에 메시지 요청 후 poll 수행() 완료

Consumer Fetcher 설정 파라미터

파라미터	기본값	설명
fetch.min.bytes	1	Fetcher가 record들을 읽어들이는 최소 bytes. 브로커는 지정된 fetch.min.bytes 이상의 새로운 메시지가 쌓일때 까지 전송을 하지 않음.
fetch.max.wait.ms	500ms	브로커에 fetch.min.bytes 이상의 메시지가 쌓일 때까지 최대 대기 시간.
fetch.max.bytes	50MB	Fetcher가 한번에 가져올 수 있는 최대 데이터 bytes.
max.partition.fetch.bytes	1MB	Fetcher가 파티션별 한번에 최대로 가져올 수 있는 bytes.
max.poll.records	500	Fetcher가 한번에 가져올 수 있는 레코드 수.

Consumer Fetcher 설정 파라미터 동작 방식

가져올 데이터가 1건도 없으면 poll( ) 인자 시간만큼 대기 후 Return
가져와야할 과거 데이터가 많을 경우 max.partition.fetch.bytes로 배치 크기 설정.
그렇지 않을 경우 fetch.min.bytes로 배치 크기 설정
가장 최신의 offset 데이터를 가져오고 있다면 fetch.min.bytes 만큼 가져오고 return 하고
fetch.min.bytes만큼 쌓이지 않는다면 fetch.max.wait.ms 만큼 기다린 후 return
오랜 과거 offset 데이터를 가져 온다면 최대 max.partition.fetch.bytes 만큼 파티션에서 읽은 뒤 반환
max.partition.feth.bytes에 도달하지 못하여도 가장 최신의 offset에 도달하면 반환
토픽에 파티션이 많아도 가져오는 데이터량은 fetch.max.bytes로 제한
Fetcher가 Linked Queue에서 가져오는 레코드의 개수는 max.poll.records로 제한

3. Heartbeat Thread

카프카 컨슈머 클라이언트는 Heart Beat Thread 를 통해서 주기적으로 브로커의 Group Coordinator에 컨슈머의 상태를 전송한다.

Group Coordinator 는 카프카 브로커중 한대가 담당하는데 컨슈머 Hearbeat 을 받아 컨슈머가 동작중인지 확인하고,

Heartbeat 이 오지 않으면 컨슈머가 다운되었다고 판단해 컨슈머를 컨슈머 그룹에서 제외시킨다.(리밸런스를 컨슈머로 명령한다.)

4. 리밸런싱

리밸런싱은 컨슈머 그룹 내에서 컨슈머에 변경이 생길 때 파티션과 컨슈머의 조합을 변경하는 과정이다.

브로커의 그룹 코디네이터가 컨슈머들에게 파티션을 재할당하는 리밸런싱을 지시한다.

1) 리밸런싱 과정

① 컨슈머 그룹내의 컨슈머가 브로커에 최초 접속을 요청하면 Group Coordinator 생성
② 동일 group.id로 여러 개의 컨슈머로 브로커의 Group Coordinator로 접속
③ 가장 빨리 Group에 Join 요청을 한 컨슈머에게 컨슈머 그룹내의 리더 컨슈머로 지정
④ 리더 컨슈머는 파티션 할당전략에 따라 컨슈머들에게 파티션 할당
⑤ 리더 컨슈머는 최종 할당된 파티션 정보를 Group Coordinator에게 전달
⑥ 정보 전달 성공을 공유한 뒤 개별 컨슈머들은 할당된 파티션에서 메시지 읽음

⑦ 컨슈머 그룹 내에 새로운 컨슈머가 추가되거나 기존 컨슈머가 종료되면(Heartbeat 를 받지 못함) Group Coordinator는 컨슈머들에게 파티션을 재할당하는 리밸런싱을 수행하도록 지시

2) Consumer Group Status

컨슈머 그룹은 Group Meta Data 에 컨슈머 그룹의 상태를 저장한다.

Empty : 컨슈머 그룹은 존재하지만 컨슈머는 없음
Rebalance : Rebalance 수행
Stable : Rebalance가 종료되고 안정적으로 컨슈머 운영

3) Consumer Static Group Membership

컨슈머 그룹 내의 컨슈머들에게 고정된 IP를 부여하여,

컨슈머 별로 컨슈머 그룹에 최초 조인 시 할당된 파티션을 그대로 유지하고 컨슈머가 shutdown되어도
session.timeout.ms내에 재기동되면 리밸런스가 수행되지 않고, 기존 파티션이 재할당 된다.

컨슈머 그룹 내에서 리밸런스가 수행되면 모든 컨슈머들이 데이터를 소비하지 못하고 Consumer LAG 이 길어지게 되는데

Consumer 스태틱 그룹 멤버쉽으로 Consumer Restart 에서 불필요한 리밸런스가 발생하지 않도록 한다.

Consumer LAG
프로듀서가 데이터를 넣는 속도가 컨슈머가 가져가는 속도보다 빠른 경우,
토픽의 가장 최신 오프셋(LOG-END-OFFSET)과 컨슈머가 가져간 데이터의 오프셋(CURRENT-OFFSET)의 차이를 kafka consumer lag이라 부른다.

4) 리밸런스 관련 컨슈머 파라미터

파라미터	기본값(ms)	설명
heartbeat.interval.ms	3000	Heart Beat Thread가 Heart Beat을 보내는 간격. session.timeout.ms 보다 낮게 설정되어야 함. Session.timeout.ms의 1/3 보다 낮 게 설정 권장.
session.timeout.ms	45000	브로커가 Consumer로 Heart Beat을 기다리는 최대 시간. 브로커는 이 시간동 안 Heart beat을 consumer로 부터 받지 못하면 해당 consumer를 Group에서 제 외하도록 rebalancing 명령을 지시
max.poll.interval.ms	300000	이전 poll( )호출 후 다음 호출 poll( )까지 브로커가 기다리는 시간. 해당 시간동 안 poll( )호출이 Consumer로 부터 이뤄지지 않으면 해당 consumer는 문제가 있 는 것으로 판단하고 브로커는 rebalance 명령을 보냄.

heartbeat.interval.ms 마다 컨슈머는 heartbeat 을 브로커로 보내고 컨슈머가 session.timeout.ms 만큼 heartbeat 을 보내지 않거나 max.poll.interval.ms 만큼 poll() 호출을 하지 않으면 브로커(코디네이터)는 리밸런스 명령을 리더 컨슈머에게 보낸다.

컨슈머에서 메시지를 읽어서 처리하는 서비스 로직이 max.poll.interval.ms 보다 커지면 의도치 않게 리밸런스가 발생할 수 있기 때문에 서비스 로직의 수행 시간을 줄일 수 없다면 max.poll.interval.ms 를 늘리거나 파티션을 추가하는 등의 방법을 고려해야 한다.

5) Consumer Rebalancing Protocol

Eager 모드

Rebalance 수행시 컨슈머들의 모든 파티션 할당을 취소하고, 새롭게 Consumer에 파티션을 다시 할당 받고 다시 메시지를 읽는다. 모든 컨슈머가 Rebalance 되는 동안 잠시 메시지를 읽지 않는 시간으로 인해 Lag가 상대적으로 크게 발생할 가능성 있다.

Cooperative 모드

Rebalance 수행 시 컨슈머들의 모든 파티션 할당을 취소하지 않고 대상이 되는 컨슈머들에 대해서 파티션에 따라 점진적으로(Incremental) 컨슈머를 할당하면서 Rebalance를 수행한다. 많은 컨슈머를 가지는 컨슈머 그룹내에서 Rebalance 시간이 오래 걸릴 시 활용도 높다.

6) Consumer 파티션 할당 전략

카프카 컨슈머는 Consumer의 부하를 파티션 별로 균등하게 할당하고 데이터 처리 및 리밸런싱의 효율성 극대화하기 위해 4개의 파티션 할당 전략 유형을 제공한다.

(1) Round Robin 할당 전략

Round Robin 전략은 토픽들의 파티션별로 순차적으로 Consumer에 할당하므로 파티션 매핑이 Consumer별로 비교적 균일하게 할당한다.

Rebalancing 시에도 토픽들의 파티션과 Consumer들을 균등하게 매핑하므로 Rebalance 이전의 파티션과 Consumer들의 매핑이 변경되기 쉽다.

(2) Range 할당 전략 (기본 전략)

Range 전략은 서로 다른 토픽들의 동일한 파티션들을 같은 Consumer로 할당한다.

Rebalancing 시에도 서로 다른 토픽에서 동일한 키값을 가지는 파티션들은 같은 Consumer에서 처리 할 수 있도록 유도한다.

(3) Sticky 할당 전략

Sticky 전략은 Rebalancing 시 기존 토픽들의 파티션과 Consumer 매핑은 최대한 유지하고 재할당되어야 하는 파티션들만 Consumer들에 할당한다.
하지만 모든 Consumer들의 파티션이 일제히 취소되는 Eager Protocol 기반에서 동작한다.

(4) Cooperative Sticky 할당 전략

Rebalancing 시 기존 토픽들의 파티션과 Consumer 매핑은 최대한 유지하고 재할당되어야 하는 파티션들만 Consumer들에 할당한다.

모든 매핑을 다 취소하지 않고 기존 매핑을 그대로 유지한채 재할당되어야 할 파티션만 Consumer에 따라 순차적으로 Rebalance를 수행한다.

5. 오프셋 커밋

컨슈머 그룹은 토픽이 특정 파티션으로부터 데이터를 가져가서 처리하고 이 파티션의 어느 레코드까지 가져갔는지 확인하기 위해 오프셋을 커밋한다.

1) __consumer_offsets

커밋한 오프셋은 브로커의 __consumer_offsets 이라는 내부 토픽에 저장하고 __consumer_offsets 토픽은 컨슈머 그룹별로 관리된다.

리밸런싱과 같이 컨슈머가 동일한 컨슈머 그룹으로 새롭게 접속할 시 __consumer_offsets에 있는 offset 정보를 기반으로 메시지를 가져오기 때문에 메시지 중복이나 손실이 발생하지 않는다.

Consumer는 poll( ) 메소드를 이용하여 주기적으로 브로커의 토픽 파티션에서 메시지를 가져오고

메시지를 성공적으로 가져 왔으면 commit을 통해서 __consumer_offse 에 다음에 읽을 offset 위치를 기재한다.

__consumer_offsets 저장

컨슈머 그룹의 컨슈머가 모두 종료되어도 offset 정보는 7일동안 __consumer_offsets에 저장 (offsets.retention.minutes)
Topic이 삭제되고 재생성될 경우에는 해당 offset 정보는 0으로 __consumer_offsets에 기록

2) auto.offset.reset

auto.offset.reset 은 __consumer_offsets에 컨슈머 그룹이 해당 토픽의 파티션별로 offset 정보를 가지고 있지 않을 때 컨슈머가 접속하면 파티션의 처음 offset 부터(earliest) 가져올 것인지, 마지막 offset 이후 부터 가져올 것인지를 설정하는 파라미터이다.

__consumer_offsets 에 오프셋이 저장되어 있을 경우

earliest, latest 모두 마지막 오프셋 이 후의 메시지를 읽는다.

__consumer_offsets 에 오프셋이 저장되어 있지 않을 경우

earliest 는 0번 오프셋 부터 메시지를 읽는다.
latest 는 마지막 오프셋 이 후의 메시지를 읽는다

3) Auto Commit

Auto Commit 수행 시점

poll()
close()

Consumer의 파라미터로 auto.enable.commit=true 인 경우 읽어온 메시지를 브로커에 바로 commit 적용하지 않고,
auto.commit.interval.ms 값(기본 5초)마다 Consumer가 자동으로 Commit을 수행한다.

auto.commit.interval.ms 값만큼 지난 후 수행되는 poll()에서 이전 poll()에서 가져온 마지막 메시지의 offset을 commit 한다.

auto.commit.interval.ms=5000 인 경우,

첫번째 poll() 에서 5초보다 작은 3초가 소요되면 offset을 commit하지 않는다.

두번째 poll() 에서 5초가 지나면 이전 poll() 의 offset을 commit 한다.

컨슈머가 비정상적으로 종료되면 현재까지 읽은 offset을 commit 하지 못해 메시지 중복 읽기가 발생할 수 있다.

__consumer_offsets 에 커밋된 offset 부터 메시지를 읽기 때문에 partition 0의 offset 2와 partition 1의 offset 1이 중복으로 읽히게 된다.

4) Manual Commit

Consumer Property를 enable.auto.commit = false 로 설정하고 명시적으로 동기 / 비동기 방식 오프셋 커밋을 적용할 수 있다.

(1) 동기 오프셋 커밋

Consumer객체의 commitSync( ) 메소드를 사용
메시지 배치를 poll( )을 통해서 읽어오고 해당 메시지들의 마지막 offset을 브로커에 commit 적용
브로커에 commit 적용이 성공적으로 될 때까지 블로킹 적용
Commit 적용 완료 후에 다시 메시지를 읽어옴
브로커에 Commit 적용이 실패할 경우 다시 Commit 적용 요청
Commit 적용 재시도가 일정 횟수동안 실패할 경우 CommitFailedException 발생
비동기 방식 대비 더 느린 수행 시간

(2) 비동기 오프셋 커밋

Consumer객체의 commitAsync( ) 메소드를 사용
메시지 배치를 poll( )을 통해서 읽어오고 해당 메시지들의 마지막 offset을 브로커에 commit 적용 요청하지만 브로커에 commit 적용이 성공적으로 되었음을 기다리지 않고(블로킹 하지 않음) 계속 메시지를 읽어옴
Callback(OffsetCommitCallback) 을 통해 Exception 을 처리
브로커에 Commit 적용이 실패해도 다시 Commit 시도 안함
(Consumer 장애 또는 Rebalance 시 한번 읽은 메시지를 다시 중복해서 가져 올 수 있음)
동기 방식 대비 더 빠른 수행 시간

5) 리밸런스 리스너

Auto와 Manual offset commit 모두 offset 을 커밋하지 못하고 리밸런스가 발생하면 offset 커밋 이 후 읽은 메시지는

리밸런스가 완료되고 중복해서 읽게된다. 이런 문제를 해결하기 위해 리밸런스가 발생하면 현재까지 처리한 메시지를 기준으로 커밋을 시도해야 한다. 리밸런스 발생을 감지하기 위해 카프카 라이브러리는 ConsumerRebalanceListener 인터페이스를 지원한다.

public static void main(String[] args) {
	// ...
    configs.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);

    consumer = new KafkaConsumer<>(configs);
    consumer.subscribe(Arrays.asList(TOPIC_NAME), new RebalanceListener());
    while (true) {
        ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(1));
        for (ConsumerRecord<String, String> record : records) {
            currentOffsets.put(
            	new TopicPartition(record.topic(), record.partition()), 
                new offsetAndMetadata(record + 1, null)
            );
        }
    }
}

public class RebalanceListener implements ConsumerRebalanceListener {
    public void onPartitionsAssigned(Collection<TopicPartition> partitions) {
    }

    public void onPartitionsRevoked(Collection<TopicPartition> partitions) {
        consumer.commitSync(currentOffsets);
    }
}

onPartitionsAssigned() : 리밸런스가 끝난 뒤에 파티션이 할당 완료되면 호출
onPartitionsRevoked() : 리밸런스가 시작되기 직전에 호출
가장 마지막 레코드를 기준으로 커밋을 실시한다.

6. 특정 파티션만 할당

Consumer에게 여러 개의 파티션이 있는 Topic에서 특정 파티션만 할당할 수 있다.

배치 처리시 특정 key레벨의 파티션을 특정 Consumer에 할당하여 처리할 경우에 적용한다.

TopicPartition topicPartition = new TopicPartition(topicName, 0);
kafkaConsumer.assign(Arrays.asList(topicPartition));

특정 파티션의 특정 오프셋부터 메시지를 읽을 수도 있다.

특정 메시지가 누락되었을 경우 해당 메시지를 다시 읽어 오기 위해 유지 보수 차원에서 일반적으로 사용한다.

TopicPartition topicPartition = new TopicPartition(topicName, 1);
kafkaConsumer.assign(Arrays.asList(topicPartition));
kafkaConsumer.seek(topicPartition, 6L);

7. 컨슈머의 안전한 종료

컨슈머 애플리케이션이 비정상적으로 종료되면 세션 타임아웃이 발생할때까지 컨슈머가 컨슈머 그룹에 남게되기 때문에 더는 동작을 하지 않는 컨슈머가 존재하기 때문에 파티션의 데이터는 소모되지 못하고 컨슈머 랙이 늘어나게 된다.

KafkaConsumer.wakeup()

public static void main(String[] args) {
    Runtime.getRuntime().addShutdownHook(new ShutdownThread());

    try {
        while (true) {
            ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(1));
            // ...
            consumer.commitSync();
        }
    } catch (WakeupException e) {
        logger.warn("Wakeup consumer");
    } finally {
        logger.warn("Consumer close");
        consumer.close();
    }
}

static class ShutdownThread extends Thread {
    public void run() {
        logger.info("Shutdown hook");
        consumer.wakeup();
    }
}

셧다운 훅은 사용자 또는 운영체제로부터 종료 요청을 받으면 실행되는 스레드를 뜻한다.

컨슈머 애플리케이션이 종료되면 셧다운 훅을 사용해 wakeup() 메서드를 호출한다. wakeup() 메서드가 실행된 이후 poll() 메서드가 호출되면 WakeupException 예외가 발생하는데 WakeupException 예외처리에서 사용한 자원들을 해제하고 마지막으로 close() 메서드로 카프카 클러스터에게 컨슈머의 종료를 전달해야 한다.

8. 멀티 스레드 컨슈머

파티션을 여러개로 운영하는 경우 데이터를 병렬처리하기 위해서 파티션 개수와 컨슈머 개수를 동일하게 맞추는 것이 가장 좋은 방법이다. 그러므로 컨슈머는 멀티 프로세스 방식이나 멀티 스레드 방식을 선택해 개발할 수 있다.

자바는 멀티 스레드를 지원하므로 멀티 컨슈머 스레드를 개발할 수 있는데 멀티 스레드로 컨슈머를 운영하기 위해서는 각 컨슈머 스레드 간에 영향이 미치지 않도록 스레드 세이프 로직, 변수를 적용해야 한다.

1) 컨슈머 멀티 워크 스레드 전략

컨슈머 멀티 워크 스레드 전략은 컨슈머 스레드는 1개만 실행하고 데이터 처리를 담당하는 워커 스레드를 여러개 실행하는 전략이다.

ExecutorService executorService = Executors.newCachedThreadPool();
while (true) {
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(10));
    for (ConsumerRecord<String, String> record : records) {
        ConsumerWorker worker = new ConsumerWorker(record.value());
        executorService.execute(worker);
    }
}

public class ConsumerWorker implements Runnable {
    private String recordValue;

    ConsumerWorker(String recordValue) {
        this.recordValue = recordValue;
    }

    @Override
    public void run() {
        // record 처리
    }
}

ConsumerWorker 클래스는 Runnable 인터페이스를 구현해 스레드로 실행된다.
ExecutorService 자바 라이브러리를 사용하면 레코드를 병렬처리하는 스레드를 효율적으로 생성하고 관리할 수 있다.
Executors 를 사용해 CashedThreadPool을 사용하면 레코드 처리가 완료되면 스레드는 종료된다.

컨슈머 멀티 워크 스레드 전략 문제점

데이터 유실

각 레코드의 데이터 처리가 끝났음을 리턴받지 않고 다음 poll() 메서드를 호출하기 때문에 데이터 처리가 스레드에서 진행중임에도 다음 poll() 메서드를 호출해 커밋을 하게되면 데이터의 유실이 발생할 수 있다.

레코드 처리 역전

스레드의 생성은 순서대로 진행되지만 나중에 생성된 스레드의 레코드 처리시간이 더 짧을 경우 이전 레코드가 다음 레코드보다 나중에 처리될 수 있다.

2) 컨슈머 멀티 스레드 전략

컨슈머 멀티 스레드 전략은 파티션의 개수만큼 컨슈머 스레드를 늘려서 운영하는 전략이다.

데이터 유실의 가능성이 작고 파티션 별로 컨슈머에서 레코드를 처리하므로 메시지 키를 갖는 경우 레코드 처리 역전이 발생하지 않는다.

private final static int CONSUMER_COUNT = 3;

ExecutorService executorService = Executors.newCachedThreadPool();
for (int i = 0; i < CONSUMER_COUNT; i++) {
    ConsumerWorker worker = new ConsumerWorker(configs, TOPIC_NAME, i);
    executorService.execute(worker);
}

public class ConsumerWorker implements Runnable {
    private final Properties prop;
    private final String topic;
    private final String threadName;
    private KafkaConsumer<String, String> consumer;

    ConsumerWorker(Properties prop, String topic, int number) {
        this.prop = prop;
        this.topic = topic;
        this.threadName = "consumer-thread-" + number;
    }

    @Override
    public void run() {
        consumer = new KafkaConsumer<>(prop);
        consumer.subscribe(Arrays.asList(topic));
        try {
            while (true) {
                ConsumerRecords<String, String> records = consumer.poll(Duration.ofSeconds(1));
                for (ConsumerRecord<String, String> record : records) {
                    logger.info("{}", record);
                }
                consumer.commitSync();
            }
        } catch (WakeupException e) {
            System.out.println(threadName + " trigger WakeupException");
        } finally {
            consumer.commitSync();
            consumer.close();
        }
    }

    public void shutdown() {
        consumer.wakeup();
    }
}

9. 컨슈머 랙

컨슈머 랙은 토픽의 최신 오프셋과 컨슈머 오프셋 간의 차이다.

컨슈머 랙은 컨슈머 그룹과 토픽, 파티션별로 생성된다.

컨슈머 랙은 컨슈머가 정상 동작하는지 여부를 확인할 수 있기 때문에 필수적으로 모니터링하고 컨슈머 랙이 늘어나 지연이 발생하면 일시적으로 파티션 개수와 컨슈머 개수를 늘리는 등의 처리를 할 수 있다.

컨슈머 랙 모니터링

1) 카프카 명령어

bin/kafka-consumer-group.sh --bootstrap-server localhost:9092 \
--group group_01 --describe

2) 컨슈머 애플리케이션

kafkaConsumer.metrics()

record-lag-max
record-lag
record-lag-avg

3) 외부 모니터링 툴

Datadog
컨플루언트 컨트롤 센터
카프카 버로우

10. 스프링 카프카 컨슈머

1) 메시지 리스너

스프링 카프카에서는 리스너 컨테이너를 사용해 컨슈머를 2개의 타입으로 래핑하였다.

레코드 리스너(MessageListener) : 1개의 레코드를 처리
배치 리스너(BatchMessageListener) : 한 번에 여러개의 레코드들을 처리

컨슈머 타입별 리스너

타입	리스너	설명
RECORD	MessageListener	Record 인스턴스 단위로 프로세싱. 오토 커밋 또는 컨슈머 컨테이너의 AckMode를 사용하는 경우
	Acknowledging MessageListener	Record 인스턴스 단위로 프로세싱. 매뉴얼 커밋을 사용하는 경우
	ConsumerAware MessageListener	Record 인스턴스 단위로 프로세싱. 컨슈머 객체를 활용하고 싶은 경우
	AcknowledgingConsumerAware MessageListener	Record 인스턴스 단위로 프로세싱. 매뉴얼 커밋을 사용하고 컨슈머 객체를 활용하고 싶은 경우
BATCH	BatchMessageListener	Records 인스턴스 단위로 프로세싱. 오토 커밋 또는 컨슈머 컨테이너의 AckMode를 사용하는 경우
	BatchAcknowledging MessageListener	Records 인스턴스 단위로 프로세싱. 매뉴얼 커밋을 사용하는 경우
	BatchConsumerAware MessageListener	Records 인스턴스 단위로 프로세싱. 컨슈머 객체를 활용하고 싶은 경우
	BatchAcknowledgingConsumer MessageListener	Records 인스턴스 단위로 프로세싱. 매뉴얼 커밋을 사용하고 컨슈머 객체를 활용하고 싶은 경우

매뉴얼 커밋을 사용할 경우 Ackowledging이 붙은 리스너를 사용하고,

KafkaConsumer 인스턴스에 직접 접근하여 컨트롤하고 싶다면 ConsumerAware가 붙은 리스너를 사용하면된다.

리스너별 생성 메서드 파라미터

2) AcksMode

카프카 클라이언트에서는 3가지로 나뉘지만 스프링 카프카에서는 커밋의 종류를 7가지로 세분화 하고 로직을 만들어 놓았다.

AckMode의 기본값은 BATCH이고 컨슈머의 enable.auto.commit 옵션은 false로 지정된다.

AcksMode 종류

AcksMode	설명
RECORD	레코드 단위로 프로세싱 이후 커밋
BATCH	poll() 메서드로 호출된 레코드가 모두 처리된 이후 커밋. 기본값.
TIME	특정 시간 이후에 커밋 시간 간격을 선언하는 AckTime 옵션을 설정해야 한다.
COUNT	특정 개수만큼 레코드가 처리된 이후에 커밋 레코드 개수를 선언하는 AckCount 옵션을 설정해야 한다.
COUNT_TIME	TIME, COUNT 옵션 중 맞는 조건이 하나라도 나올 경우 커밋
MANUAL	Acknowledgement.acknowledge() 메서드가 호출되면 다음번 poll() 때 커밋을 한다. 매번 acknowledge() 메서드를 호출하면 BATCH 옵션과 동일하게 작동한다. AcknowledgingMessageListener 또는 BatchAcknowledgingMessageListener를 사용해야 한다.
MANUAL_IMMEDIATE	Acknowledgement.acknowledge() 메서드를 호출한 즉시 커밋한다. AcknowledgingMessageListener 또는 BatchAcknowledgingMessageListener를 사용해야 한다.

3) 기본 리스너 컨테이너

(1) 레코드 리스너(MessageListener)

spring:
  kafka:
    consumer:
      bootstrap-servers: my-kafka:9092
    listener:
      type: RECORD

리스너 타입을 RECORD로 설정한다.

● 기본 리스너

poll()이 호출되어 가져온 레코드들은 차례대로 개별 레코드의 메시지 값을 파라미터로 받게 된다.

@KafkaListener(topics = "test",
        groupId = "test-group-00")
public void recordListener(ConsumerRecord<String,String> record) {
    logger.info(record.toString());
}

● 메시지 값을 파라미터로 받는 리스너

기본값인 StringDeserializer 를 사용해 String 클래스로 메시지 값을 전달받는다.

@KafkaListener(topics = "test",
        groupId = "test-group-01")
public void singleTopicListener(String messageValue) {
    logger.info(messageValue);
}

● 개별 리스너에 컨슈머 옵션값을 부여

@KafkaListener(topics = "test",
        groupId = "test-group-02", properties = {
        "max.poll.interval.ms:60000",
        "auto.offset.reset:earliest"
})
public void singleTopicWithPropertiesListener(String messageValue) {
    logger.info(messageValue);
}

● 멀티 스레드 리스너

concurrency 옵션값에 해당하는 만큼 컨슈머 스레드를 만들어서 병렬처리한다.

@KafkaListener(topics = "test",
        groupId = "test-group-03",
        concurrency = "3")
public void concurrentTopicListener(String messageValue) {
    logger.info(messageValue);
}

● 특정 토픽의 특정 파티션만 구독

@KafkaListener(topicPartitions =
        {
                @TopicPartition(topic = "test01", partitions = {"0", "1"}),
                @TopicPartition(topic = "test02", partitionOffsets = @PartitionOffset(partition = "0", initialOffset = "3"))
        },
        groupId = "test-group-04")
public void listenSpecificPartition(ConsumerRecord<String, String> record) {
    logger.info(record.toString());
}

(2) 배치 리스너(BatchMessageListener)

spring:
  kafka:
    consumer:
      bootstrap-servers: my-kafka:9092
    listener:
      type: BATCH

● 기본 리스너

컨슈머 레코드의 묶음을 파라미터로 받는다.

카프카 클라이언트 라이브러리에서 poll() 메서드로 리턴받은 ConsumerRecords를 리턷받아 사용하는 것과 동일하다.

@KafkaListener(topics = "test",
        groupId = "test-group-01")
public void batchListener(ConsumerRecords<String, String> records) {
    records.forEach(record -> logger.info(record.toString()));
}

● 메시지 값의 묶음을 파라미터로 받는 리스너

@KafkaListener(topics = "test",
        groupId = "test-group-02")
public void batchListener(List<String> list) {
    list.forEach(recordValue -> logger.info(recordValue));
}

● 멀티 스레드 리스너

concurrency 옵션값에 해당하는 만큼 컨슈머 스레드를 만들어서 병렬처리한다.

@KafkaListener(topics = "test",
        groupId = "test-group-03",
        concurrency = "3")
public void concurrentBatchListener(ConsumerRecords<String, String> records) {
    records.forEach(record -> logger.info(record.toString()));
}

(3) 배치 커밋 컨슈머 리스너(BatchAcknowledgingConsumerMessageListener)

배치 컨슈머 리스너는 컨슈머 인스턴스를 파라미터로 받아 동기, 비동기 커밋을 사용할 수 있고,

배치 커밋 리스너는 Acknoledgment 인스턴스를 파라미터로 받아 AckMode 를 사용할 수 있다.

spring:
  kafka:
    consumer:
      bootstrap-servers: my-kafka:9092
    listener:
      type: BATCH
      ack-mode: MANUAL_IMMEDIATE

● 배치 커밋 리스너

AckMode를 MANUAL 또는 MANUAL_IMMEDIATE로 사용할 경우 수동 커밋을 하기 위해 파라미터로 Acknowledgment 인스턴스를 받아야 한다. acknowledge() 메서드를 호출함으로써 커밋을 수행할 수 있다.

@KafkaListener(topics = "test", groupId = "test-group-01")
public void commitListener(ConsumerRecords<String, String> records, Acknowledgment ack) {
    records.forEach(record -> logger.info(record.toString()));
    ack.acknowledge();
}

● 배치 컨슈머 리스너

동기, 비동기 커밋을 사용하고 싶다면 컨슈머 인스턴스를 파라미터로 받아서 사용할 수 있다.

consumer 인스턴스의 conmmitSync(), conmmitAsync() 메서드를 호출하면 사용자가 원하는 타이밍에 커밋할 수 있다.

@KafkaListener(topics = "test", groupId = "test-group-02")
public void consumerCommitListener(ConsumerRecords<String, String> records, Consumer<String, String> consumer) {
    records.forEach(record -> logger.info(record.toString()));
    consumer.commitSync();
}

4) 커스텀 리스너 컨테이너

서로 다른 설정을 가진 2개 이상의 리스너를 구현하거나 리밸런스 리스너를 구현하기 위해서는 커스텀 리스너 컨테이너를 사용해야 한다. 카프카 리스너 컨테이너 팩토리(KafkaListenerContainerFactory) 인스턴스를 생성해야 한다.

@Configuration
public class ListenerContainerConfiguration {

    @Bean
    public KafkaListenerContainerFactory<ConcurrentMessageListenerContainer<String, String>> customContainerFactory() {
        Map<String, Object> props = new HashMap<>();
        props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "my-kafka:9092");
        props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
        props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);

        DefaultKafkaConsumerFactory cf = new DefaultKafkaConsumerFactory<>(props);
        ConcurrentKafkaListenerContainerFactory<String, String> factory = new ConcurrentKafkaListenerContainerFactory<>();
        factory.getContainerProperties().setConsumerRebalanceListener(new ConsumerAwareRebalanceListener() {
            @Override
            public void onPartitionsRevokedBeforeCommit(Consumer<?, ?> consumer, Collection<TopicPartition> partitions) {
            }

            @Override
            public void onPartitionsRevokedAfterCommit(Consumer<?, ?> consumer, Collection<TopicPartition> partitions) {
            }

            @Override
            public void onPartitionsAssigned(Collection<TopicPartition> partitions) {
            }

            @Override
            public void onPartitionsLost(Collection<TopicPartition> partitions) {
            }
        });
        factory.setBatchListener(false);
        factory.getContainerProperties().setAckMode(ContainerProperties.AckMode.RECORD);
        factory.setConsumerFactory(cf);
        return factory;
    }
}

@KafkaListener(topics = "test",
        groupId = "test-group",
        containerFactory = "customContainerFactory")
public void customListener(String data) {
    logger.info(data);
}

DefaultKafkaConsumerFactory로 리스너 컨테이너 팩토리를 생성할 때 컨슈머 기본 옵션을 설정한다.
ConcurrentKafkaListenerContainerFactory로 concurrency 옵션을 설정할 수 있는 리스너를 만들 때 사용하는 리스너 컨테이너를 만든다.
setConsumerRebalanceListener() 메서드를 호출해 리밸런스 리스너를 만든다.
setBatchListener() 메서드에 파라미터로 false를 넣어 리코드 리스너임을 명시한다.
setAckMode() 메서드에 파라미터로 RECORD를 넣어 레코드 단위 커밋을 설정한다.

참고

[Kafka] 3. 카프카 프로듀서

mandykr — Thu, 2 Feb 2023 11:03:34 +0900

1. 프로듀서 Client

2. Serializer

3. Partitioner

4. Accumulator

5. Sender

6. 멱등성(idempotence) 프로듀서

7. 트랜잭션 프로듀서

8. 스프링 카프카 프로듀서

1. 프로듀서 Client

카프카 프로듀서는 브로커로 데이터를 전송할 때 내부적으로 직렬화, 파티셔너, 배치 생성 단계를 거친다.

기본 프로듀서 Client API 처리 로직

// 1. Producer 환경 설정(Properties 객체를 이용)
String topicName = "simple-topic";
Properties props  = new Properties();
props.setProperty(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.56.101:9092");
props.setProperty(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.setProperty(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

// 2. 1에서 설정한 환경 설정값을 반영하여 KafkaProducer 객체 생성.
KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(props);

// 3. 토픽명과 메시지 값(Key, Value) 을 입력하여 보낼 메시지인 ProducerRecord 객체 생성
ProducerRecord<String, String> producerRecord = new ProducerRecord<>(topicName, "hello world");

// 4. KafkaProducer객체의 send( )메소드를 호출하여 ProducerRecord 전송
kafkaProducer.send(producerRecord);
kafkaProducer.flush();

// 5. KafkaProducer객체의 close( )메소드를 호출하여 종료
kafkaProducer.close();

2. Serializer

카프카 프로듀서는 Serializer를 통해 데이터를 Byte Array 형태로 전송하고 파티션에서도 Byte Array 형태로 저장한다.

자바 객체(Object)도 Serialization을 통해서 바이트 배열(바이트 스트림) 형태로 저장하기 때문에 객체의 유형, 데이터의 포맷, 적용 시스템에 상관없이 이동/저장/복원이 자유롭다.

카프카 컨슈머에서는 Byte Array를 받아서 DeSerialization 과정을 거쳐 원본 객체로 변환한다.

카프카 프로듀서 클라이언트에서 메시지를 Serialization 하는데 활용할 Serializer 를 명시해줘야 한다.

Properties props  = new Properties();
props.setProperty(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
props.setProperty(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName()

카프카 클라이언트가 제공하는 기본 Serializer

StringSerializer
ShortSerializer
IntegerSerializer
LongSerializer
DoubleSerializer
BytesSerializer

3. Partitioner

파티셔너는 ProducerRecord를 토픽의 어느 파티션으로 전송할 지 결정한다.

기본 파티셔너는 DefaultPartitioner 이고 프로듀서 API는 RoundRobinPartitioner, UniformStickyPartitioner를 제공한다.

Partitioner 인터페이스를 상속받은 사용자 정의 클래스를 만들 수 있다.

메시지 키

메시지는 Partitioner를 통해 토픽의 어떤 파티션으로 전송되어야 할 지 미리 결정 되는데,

Key값을 가지지 않는 경우 라운드 로빈(Round Robin), 스티키 파티션(Sticky Partition)등의 파티션 전략등이 선택되어 파티션 별로 메시지가 전송된다.

카프카는 하나의 파티션 내에서만 메시지 순서를 보장하기 때문에 서로 다른 파티션에 저장된 메시지는 순서를 보장받지 못한채 컨슈머에 의해 읽혀질 수 있다.

메시지 순서를 보장하기 위해서는 메시지 키를 사용해야 한다.

같은 키를 가지는 메시지는 같은 파티션으로 파티셔닝되기 때문에 메시지 순서가 보장된다.

또한, 하나의 파티션에 서로 다른 키를 가지는 메시지가 저장될 수 있다.

# 키를 가지는 메시지 전송
$ bin/kafka-console-producer.sh --bootstrap-server kafka-0:9092,kafka-1:9092,kafka-2:9092 --topic topic-p2r3 \
--property key.separator=: --property parse.key=true
>K1:V1
>K2:V1
>K1:V2
>K2:V2
>K3:V1

# 키를 가지는 메시지 컨슘
$ bin/kafka-console-consumer.sh --bootstrap-server kafka-0:9092,kafka-1:9092,kafka-2:9092 --topic topic-p2r3 \
--property print.key=true --property print.value=true \
--property print.partition=true

Partition:0    K1    V1
Partition:1    K2    V1
Partition:0    K1    V2
Partition:1    K2    V2
Partition:0    K3    V1

RoundRobinPartitioner

카프카 클라이언트 2.4.0 이전 버전에서 기본 파티셔너
메시지 키가 있으면 키의 해시값과 파티션을 매칭
ProducerRecord가 들어오는 대로 파티션을 순회하면서 전송
데이터가 배치로 묶이는 빈도가 적다.

UniformStickyPartitioner

카프카 클라이언트 2.5.0 버전에서 기본 파티셔너
메시지 키가 있으면 키의 해시값과 파티션을 매칭
특정 파티션으로 전송되는 하나의 배치에 메시지를 빠르게 먼저 채워서 보내는 방식
어큐뮬레이터에서 데이터가 배치로 모두 묶일 때까지 기다렸다가 배치로 묶인 데이터는 모두 동일한 파티션에 전송
RoundRobinPartitioner에 비해 향상된 성능을 가진다.

4. Accumulator

Record Accumulator는 Partitioner에 의해서 메시지 배치가 전송이 될 토픽과 Partition에 따라 저장되는 KafkaProducer 메모리 영역이다.

KafkaProducer 객체의 send( ) 메소드는 호출 시마다 하나의 ProducerRecord를 입력하지만 바로 전송 되지 않고 Accumulator에 단일 메시지를 토픽 파티션에 따라 Record Batch 단위로 묶인 뒤 전송된다.

메시지들은 Accumulator에 여러 개의 Batch들로 buffer.memory 설정 사이즈 만큼 보관될 수 있으며 메시지 전송은 Sender Thread에 의해 여러 개의 Batch들로 한꺼번에 전송할 수 있다.

Sender Thread는 Accumulator에 누적된 메시지 배치를 꺼내서 브로커로 전송한다.

1개의 Batch를 가져갈수도, 여러 개의 Batch를 가져 갈 수도 있다.

buffer.memory : Record accumulator의 전체 메모리 사이즈
linger.ms : Sender Thread로 메시지를 보내 기전 배치로 메시지를 만들어서 보내기 위한 최대 대기 시간
batch.size : 단일 배치의 사이즈

linger.ms는 보통 20ms 이하로 설정을 권장한다. 기본값은 0.

props.setProperty(ProducerConfig.BATCH_SIZE_CONFIG, "32000"); // 배치 사이즈 설정
props.setProperty(ProducerConfig.LINGER_MS_CONFIG, "20"); // linger ms 설정

5. Sender

Producer Client의 Main Thread가 send( ) 메소드를 호출하면 메시지 전송을 시작하지만 바로 전송되지 않으며 내부 Buffer에 메시지를 저장 후에 별도의 Thread가 Kafka Broker에 실제 전송을 하는 방식이다.

1) 동기 / 비동기 메시지 전송

(1) 동기 메시지 전송

Future<RecordMetaData> = KafkaProducer.send() 기본적으로 비동기 호출인데,

Future객체의 get( )을 호출하여 브로커로 부터 메시지 Ack 응답을 받을 때 까지 Main Thread를 대기 시키는 방식 으로 동기화를 구성 할 수 있다.

try {
    RecordMetadata recordMetadata = kafkaProducer.send(producerRecord).get();
    logger.info("\n ###### record metadata received ##### \n" +
            "partition:" + recordMetadata.partition() +"\n" +
            "offset:" + recordMetadata.offset() + "\n" +
            "timestamp:" + recordMetadata.timestamp());
} catch (ExecutionException e) {
    e.printStackTrace();
} catch (InterruptedException e) {
    e.printStackTrace();
} finally {
    kafkaProducer.close();
}

동기 메시지 전송은 Record Accumulator 의 배치에 메시지를 채우고 Acks 를 기다리기 때문에 linger.ms 설정값 만큼 대기한 후 Sender Thread 가 메시지를 카프카 브로커로 전송하고 Acks 를 받은 후 RecordMetadata 를 받는다.

따라서 배치에 담기는 메시지는 항상 1개이기 때문에 메시지 배치처리가 불가능하다.

(2) 비동기 메시지 전송

Main Thread 에서 콜백 메시지를 전송할 때 콜백 객체를 함께 보내고,

Sender 에서 카프카 클러스터의 응답을 받아 콜백 객체에 선언된 메소드를 실행한다.

Main Thread 에서는 카프카 클러스터 응답에 대한 Exception 이나 RecordMetadata 를 확인한다.

kafkaProducer.send(producerRecord, (metadata, exception)-> {
    if (exception == null) {
        logger.info("\n ###### record metadata received ##### \n" +
                "partition:" + metadata.partition() + "\n" +
                "offset:" + metadata.offset() + "\n" +
                "timestamp:" + metadata.timestamp());
    } else {
        logger.error("exception error from broker " + exception.getMessage());
    }
});

2) acks 옵션

acks 옵션으로 프로듀서가 메시지를 전송하고 다음 메시지를 전송하기 전에 리더 파티션으로부터 응답을 기다릴지에 대해 설정할 수 있다.

기본값은 -1이다.

props.setProperty(ProducerConfig.ACKS_CONFIG, "0");

(1) acks = 0

리더 브로커가 메시지를 정상적으로 받았는지에 대한 Ack 메시지를 받지 않고 다음 메시지를 바로 전송

메시지 손실의 우려가 가장 크지만 가장 빠르게 전송할 수 있음

(2) acks = 1

리더 브로커가 메시지를 정상적으로 받았는지에 대한 Ack 메시지를 받은 후에 다음 메시지를 바로 전송

메시지를 복제 중에 다운될 경우 다음 리더가 될 브로커에는 메시지가 없을 수 있기 때문에 메시지를 소실할 우려가 있음

(3) acks = all, -1

min.insync.replicas 개수 만큼의 Replicator에 복제를 수행한 뒤에 리더 브로커가 보내는 Ack 를 받은 후 다음 메시지를 바로 전송. 만약 오류 메시지를 브로커로 부터 받으면 메시지를 재전송

3) 메시지 전송/재 전송 시간 파라미터

max.block.ms : Send( ) 호출 시 Record Accumulator에 입력하지 못하고 block되는 최대 시간.
초과시 Timeout Exception
linger.ms : Sender Thread가 Record Accumulator에서 배치별로 가져가기 위한 최대 대기시간.
request.timeout.ms : 전송에 걸리는 최대 시간. 전송 재 시도 대기시간 제외.
초과시 retry를 하거나 Timout Exception 발생
retry.backoff.ms : 전송 재 시도를 위한 대기 시간.
retries 는 재 전송 횟수를 설정
delivery.timeout.ms : Producer 메시지(배치) 전송에 허용된 최대 시간.
( delivery.timeout.ms >= linger.ms + request.timeout.ms )
초과시 Timeout Exception

예) retries=10, request.timeout.ms=10000ms, retry.backoff.ms=30 인 경우,
request.timeout.ms 만큼 기다린후 재 전송하기전 30ms 이후 재전송 시도

이와 같은 방식으로 재 전송을 10회 시도하고 더 이상 retry 시도 하지 않음

max.in.flight.requests.per.connection : 비동기 전송 시 브로커의 응답없이 한꺼번에 보낼 수 있는 Batch의 개수.
기본값은 5. ( Kafka Producer의 메시지 전송 단위는 Batch 이다. )

6. 멱등성(idempotence) 프로듀서

Producer는 브로커로 부터 ACK를 받은 다음에 다음 메시지를 전송하는데, Producer ID와 메시지 Sequence를 Header에 저장 하여 전송한다.

브로커는 Producer가 보낸 메시지의 Sequence가 브로커가 가지고 있는 메시지의 Sequence보다 1만큼 큰 경우에만 브로커에 저장하고 브로커에서 메시지 Sequece가 중복 될 경우 이를 메시지 로그에 기록하지 않고 Ack만 전송한다.

Idempotence 를 위한 Producer 설정

enable.idempotence = true
acks = all
retries는 0 보다 큰 값
max.in.flight.requests.per.connection은 1에서 5사이 값

Kafka 3.0 버전 부터는 Producer의 기본 설정이 Idempotence 이다.

acks=1로 설정하는 등 다른 파라미터를 변경하면 Idempotence 로 동작하지 않지만 메시지는 전송된다.

enable.idempotence = true 를 명시적으로 설정하고 다른 파라미터를 잘못 설정하면 Config 오류가
발생한다.

시퀀스 넘버가 일정하지 않은 경우에는 OutOfOrderSequenceExceptioin 이 발생한다.

(예: 시퀀스 넘버 0 다음에 1이 아닌 2가 오는 경우)

7. 트랜잭션 프로듀서

트랜잭션 프로듀서는 다수의 파티션에 데이터를 저장할 경우 모든 데이터에 대해 동일한 원자성을 만족시키기 위해 사용된다.

트랜잭션 프로듀서를 위한 Producer 설정

enable.idempotence = true
transactionl.id 를 임의의 String 값으로 설정
컨슈머의 isolation.level = read_committed

트랜잭션 프로듀서는 사용자가 보낸 데이터를 레코드로 파티션에 저장할 뿐만 아니라 트랜잭션의 시작과 끝을 표현하기 위해 트랜잭션 레코드를 한 개 더 보낸다. (트랜잭션 레코드는 오프셋을 한 개 차지한다.)

트랜잭션 컨슈머는 파티션에 저장된 트랜잭션 레코드를 보고 트랜잭션이 완료되었음을 확인하고 데이터를 가져간다.

8. 스프링 카프카 프로듀서

스프링 카프카 라이브러리 디펜던시 추가

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
    implementation 'org.springframework.kafka:spring-kafka'
}

스프링 카프카 프로듀서는 Kafka Template 이라는 클래스를 사용해 데이터를 전송할 수 있다.

1) 기본 카프카 템플릿

application.properties 에 프로듀서 옵션을 설정할 수 있다.

별도로 선언하지 않으면 기본값으로 설정된다.

spring.kafka.producer.acks
spring.kafka.producer.batch-size
spring.kafka.producer.bootstrap-servers
spring.kafka.producer.buffer-memory
spring.kafka.producer.client-id
spring.kafka.producer.compression-type
spring.kafka.producer.key-serialzier
spring.kafka.producer.properties.*
spring.kafka.producer.retries
spring.kafka.producer.transaction-id-prefix

메시지 전송

private static String TOPIC_NAME = "test";

@Autowired
private KafkaTemplate<Integer, String> template;

template.send(TOPIC_NAME, "test");

KafkaTemplate 객체를 스프링 빈에서 주입받아 사용한다.

send() 메서드를 사용해서 토픽 이름과 케시지 값을 넣어 전송한다.

2) 커스텀 카프카 템플릿

커스텀 카프카 템플릿은 프로듀서 팩토리를 통해 만든 카프카 템플릿 객체를 빈으로 등록하여 사용할 수 있다.

@Configuration
public class KafkaTemplateConfiguration {

    @Bean
    public KafkaTemplate<String, String> customKafkaTemplate() {

        Map<String, Object> props = new HashMap<>();
        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "my-kafka:9092");
        props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
        props.put(ProducerConfig.ACKS_CONFIG, "all");

        ProducerFactory<String, String> pf = new DefaultKafkaProducerFactory<>(props);

        return new KafkaTemplate<>(pf);
    }
}

커스텀 프로듀서는 필수 옵션(bootstrap.servers, key.serializer, value.serializer)을 포함한 옵션들을 선언해야 한다.

ProducerFactory 를 property 로 초기화 하고 KafkaTemplate을 빈으로 등록한다.

메시지 전송

@Autowired
private KafkaTemplate<String, String> customKafkaTemplate;

ListenableFuture<SendResult<String, String>> future = customKafkaTemplate.send(TOPIC_NAME, "test");
future.addCallback(new KafkaSendCallback<String, String>() {
    @Override
    public void onSuccess(SendResult<String, String> result) {
    }

    @Override
    public void onFailure(KafkaProducerException ex) {
    }
});

ListenableFuture 인스턴스에 addCallback 함수를 붙여 프로듀서가 보낸 데이터의 브로커 적재여부를 비동기로 확인할 수 있다. 브로커에 정상 적재되었다면 onSuccess 메서드가, 적재되지 않고 이슈가 발생했다면 onFailure 메서드가 호출된다.

참고

[Kafka] 2. 토픽과 파티션

mandykr — Thu, 2 Feb 2023 10:17:22 +0900

1. 적정 파티션 개수

2. 토픽 정리 정책

3. 멀티 노드 카프카 클러스터

4. 복제와 리더 / 팔로워 파티션

5. ISR

6. Kafka Config

토픽과 파티션을 사용함에 있어 발생하는 여러가지 운영상 고려사항을 확인하고 멀티 노드 카프카 클러스터를 구성한다.

1. 적정 파티션 개수

토픽의 파티션 개수는 카프카의 성능과 관련이 있기 때문에 적절한 파티션 개수를 설정하고 운영하는 것이 매우 중요하다.

토픽 생성시 파티션 개수 고려사항

데이터 처리량
메시지 키 사용 여부
브로커, 컨슈머 영향도

1) 데이터 처리량

데이터 처리량을 늘리기 위해 파티션을 추가하고 파티션 개수만큼 컨슈머를 추가해서 병렬 처리량을 늘릴 수 있다.

(컨슈머가 실행되는 서버의 사양을 올리는 스케일업이나 GC 튜닝 등 컨슈머의 처리량을 늘리는 방법도 있다.)

프로듀서가 보내는 데이터 양과 컨슈머의 데이터 처리량을 계산해서 파티션 개수를 정할 수 있다.

프로듀서 전송 데이터량 < 컨슈머 데이터 처리량 x 파티션 개수

프로듀서가 보내는 데이터가 초당 1,000 레코드이고,
컨슈머가 처리할 수 있는 데이터가 초당 100 레코드이면,
파티션 개수는 10

2) 컨슈머 데이터 처리량

파티션 개수만큼 컨슈머 스레드를 운영한다면 병렬처리를 극대화할 수 있다.

전체 컨슈머 데이터 처리량이 프로듀서가 보내는 데이터보다 적다면 컨슈머 랙이 생기기 때문에 컨슈머 전체 데이터 처리량은 프로듀서 데이터 처리량보다 많아야 한다.

컨슈머 데이터 처리량 측정

컨슈머 데이터 처리량은 운영중인 카프카에서 더미 데이터 테스트로 구할 수 있다.
그리고 프로듀서가 보내는 데이터 양을 하루, 시간, 분 단위로 쪼개서 예측한다.
데이터의 최대치를 데이터 생성량으로 잡는다.

3) 메시지 키 사용 여부

메시지 키를 사용하면 데이터 처리 순서가 보장받지 못하는 경우가 생길 수 있다.

[ 파티션 추가 전 ]

[ 파티션 추가 후 ]

프로듀서가 기본 파티셔너를 사용할 때,

메시지 키를 사용하면 프로듀서가 토픽으로 데이터를 보낼 때 메시지 키를 해시 변환하여 메시지 키를 파티션에 매칭시킨다.
만약 파티션 개수가 달라지면 이미 매칭된 파티션과 메시지 키의 매칭이 깨지고 전혀 다른 파티션에 데이터가 할당된다.
파티션을 변환하기 이전과 이후 메시지 키의 파티션 위치가 달라지기 때문에 컨슈머는 메시지 키의 순서를 더는 보장받지 못한다.

따라서 메시지 처리 순서가 보장되어야 한다면,

파티션 개수를 프로듀서가 전송하는 데이터양보다 더 넉넉하게 잡고 최대한 파티션의 변화가 발생하지 않는 방향으로 운영해야 한다.

만약에 파티션 개수가 변해야 하는 경우에는 기존에 사용하던 메시지 키의 매칭을 그대로 가져가기 위해 커스텀 파티션너를 개발하고 적용해야 한다.

4) 브로커와 컨슈머의 영향도

파티션은 각 브로커의 파일 시스템을 사용하기 때문에 파티션이 늘어나는 만큼 브로커에서 접근하는 파일 개수가 많아진다. 그런데 운영체제에서는 프로세스당 열 수 있는 파일 최대 개수를 제한하고 있다. 만약 브로커가 관리하는 파티션 개수가 너무 많다면 파티션 개수를 분산하기 위해서 카프카 브로커 개수를 늘리는 방안도 고려해야 한다.

2. 토픽 정리 정책

토픽의 데이터를 더는 사용하지 않는 경우 cleanup.policy 옵션을 사용해 데이터를 완전 삭제(delete)하거나 압축(compact)으로 동일 메시지 키의 가장 오래된 데이터를 삭제할 수 있다.

1) 토픽 삭제 정책(delete policy)

cleanup.policy 옵션을 delete로 설정하면 토픽의 데이터를 삭제 한다.

토픽의 데이터는 세그먼트 단위로 삭제된다.

세그먼트

세그먼트는 토픽의 데이터를 저장하는 명시적인 파일 시스템 단위이고, 파티션마다 별개로 생성되며 파일 이름은 오프셋 중 가장 작은 값이 된다.

segment.bytes 옵션으로 1개의 세그먼트 크기를 설정할 수 있다. segment.bytes 크기보다 커질 경우에는 기존에 적재하던 세그먼트 파일을 닫고 새로운 세그먼트를 열어서 데이터를 저장한다.

삭제 주기

retention.ms는 토픽의 데이터를 유지하는 기간을 밀리초 단위로 설정할 수 있다.

세그먼트 파일의 마지막 수정 시간이 retention.ms를 넘어가면 세그먼트는 삭제된다.

retention.bytes는 토픽의 최대 데이터 크기를 제어한다.

retention.bytes를 넘어간 세그먼트 파일들은 삭제된다.

2) 토픽 압축 정책(compact policy)

cleanup.policy 옵션을 compact로 설정하면 메시지 키별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제한다.

동일한 메시지 키를 기준으로 오래된 데이터를 삭제하기 때문에 파티션의 오프셋과 관계없이 중간에 있는 레코드가 삭제될 수 있다.

* 액티브 세그먼트: 데이터를 저장하기 위해 사용중이 세그먼트
압축 정책은 액티브 세그먼트를 제외한 나머지 세그먼트들에 한해서만 데이터를 처리한다.

* 테일(tail) 영역: 압축 정책에 의해 압축이 완료된 레코드들
테일 영역의 레코드들을 클린 레코드라고 한다.

* 헤드(head) 영역: 압축이 진행되지 않은 레코드들
헤드 영역의 레코드들을 더티 레코드라고 한다.

더티 비율

더티 비율은 더티 영역의 메시지 개수를 압축 대상 세그먼트에 남아있는 데이터의 총 레코드 수로 나눈 비율을 뜻한다.

더티비율
= 더티 레코드 개수 / 총 레코드 수(클린 레코드 개수 + 더티 레코드 개수)
= 3 / (3 + 3)
= 0.5

압축 시작 시점

min.cleanable.dirty.ratio 옵션값으로 데이터의 압축 시작 시점을 결정한다.

min.cleanable.dirty.ratio 옵션값은 액티브 세그먼트를 제외한 세그먼트에 남아있는 데이터의 테일 영역의 레코드 개수와 헤드 영역의 레코드 개수의 비율을 뜻한다.

min.cleanable.dirty.ratio를 0.5로 설정할 경우 더티 비율이 0.5가 넘어가면 압축이 수행된다.

0.9와 같이 크게 설정하면 한번 압축을 할 때 많은 데이터가 줄어들므로 압축 효과가 좋지만 압축 전까지 많은 용량을 차지하게된다.
0.1과 같이 작게 설정하면 압축이 자주 일어나기 때문에 최신 데이터만 유지할 수 있지만 압축이 자주 발생하므로 브로커에 부담을 주게된다.

3. 멀티 노드 카프카 클러스터

카프카는 데이터 복제(Replication)을 통해 분산 시스템 기반에서 카프카의 최적 가용성을 보장한다.

EC2 인스턴스를 활용해 멀티 노드 카프카 클러스터를 구성한다.

1) 설치 및 기본 설정

(1) EC2 인스턴스 생성 및 접속

zookeeper 1, broker 3대를 설치할 총 4개의 인스턴스를 생성한다.

zookeeper의 보안그룹을 설정한다.

kafka 브로커의 보안그룹을 설정한다.

EC2에 접속한다.

(2) host 설정

[ec2 인스턴스]
$ sudo vi /etc/hosts
13.125.172.62 zookeeper
13.124.8.60 kafka-0
43.201.102.129 kafka-1
43.201.149.82 kafka-2

(3) 별칭 설정

[ec2 인스턴스]
$ vi ~/.bashrc
USERNAME=zookeeper
PS1='[\e[1;31m$USERNAME\e[0m][\e[1;32m\t\e[0m][\e[1;33m\u\e[0m@\e[1;36m\h\e[0m \w] \n\$ \[\033[00m\]'

$ source ~/.bashrc

(4) Java 설치

[ec2 인스턴스]
$ cd ~
# aws coreetto 다운로드
$ sudo curl -L https://corretto.aws/downloads/latest/amazon-corretto-11-x64-linux-jdk.rpm -o jdk11.rpm

# jdk11 설치
$ sudo yum localinstall jdk11.rpm

# jdk version 선택
$ sudo /usr/sbin/alternatives --config java

# java 버전 확인
$ java --version

# 다운받은 설치키트 제거
$ rm -rf jdk11.rpm

(5) 카프카 설치

[ec2 인스턴스]
$ wget https://downloads.apache.org/kafka/3.4.0/kafka_2.12-3.4.0.tgz
$ tar xvf kafka_2.12-3.4.0.tgz
$ cd kafka_2.12-3.4.0.tgz

(6) 카프카 브로커 힙 메모리 설정

[ec2 인스턴스]
$ vi ~/.bashrc
export KAFKA_HEAP_OPTS="-Xmx400m -Xms400m"

$ source ~/.bashrc
$ echo $KAFKA_HEAP_OPTS

3) 멀티 브로커 구성

1개의 zookeeper에 연결된 3개의 멀티 브로커를 구성한다.

(1) 주키퍼 실행 옵션 설정

[zookeeper]
$ vi config/zookeeper.properties
dataDir=/home/ec2-user/data/zookeeper-logs

$ mkdir -p /home/ec2-user/data/zookeeper-logs

(2) 카프카 브로커 실행 옵션 설정

[kafka-x]
$ vi config/server.properties
broker.id=0
listeners=PLAINTEXT://:9092
advertised.listeners=PLAINTEXT://kafka-x-IP:9092
log.dirs=/home/ec2-user/data/kafka-logs
zookeeper.connect=zookeeper:2181

$ mkdir -p /home/ec2-user/data/kafka-logs

(3) 주키퍼 실행

[zookeeper]
$ bin/zookeeper-server-start.sh -daemon config/zookeeper.properties
$ jps -vm

(4) 브로커 실행

[kafka-x]
$ bin/kafka-server-start.sh -daemon config/server.properties
$ jps -m

(5) 브로커 로그 확인

[kafka-x]
$ tail -f logs/server.log

파일 시스템 구조

home
├── ec2-user
│   ├── data
│   │   ├── zookeeper-logs
│   │   ├── kafka-logs
│   ├── kafka_2.12-3.4.0
│   │   ├── bin
│   │   │   ├── kafka-configs.sh
│   │   │   ├── kafka-console-consumer.sh
│   │   │   ├── kafka-console-producer.sh
│   │   │   ├── kafka-server-start.sh
│   │   │   ├── kafka-topics.sh
│   │   │   ├── zookeeper-server-start.sh
│   │   ├── config
│   │   │   ├── server.properties
│   │   │   └── zookeeper.properties
│   │   ├── libs
│   │   ├── LICENSE
│   │   ├── logs
│   │   │   ├── server.log
│   │   ├── NOTICE
│   │   └── site-docs

4. 복제와 리더 / 팔로워 파티션

데이터 복제는 카프카를 장애 허용 시스템으로 동작하도록 하는 원동력이다. 데이터 복제로 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용할 수 있다.

데이터 복제는 파티션 단위로 이루어지고 토픽을 생성할 때 파티션의 복제 개수(replication factor)를 설정할 수 있다.

직접 선택하지 않으면 브로커에 설정된 옵션 값을 따라간다.(기본값 1)

토픽 생성

파티션 3, replication factor 3

[kafka-0]
$ bin/kafka-topics.sh --create \
--bootstrap-server kafka-0:9092,kafka-1:9092,kafka-2:9092 \
--replication-factor 3 \
--partitions 3 \
--topic topic-p3r3

토픽 정보 확인

[kafka-0]
$ bin/kafka-topics.sh --describe \
--bootstrap-server kafka-0:9092,kafka-1:9092,kafka-2:9092 \
--topic topic-p3r3

Topic: topic-p3r3       TopicId: pdUUUMzuSd2-xuD2kgrmFg PartitionCount: 3       ReplicationFactor: 3    Configs:
        Topic: topic-p3r3       Partition: 0    Leader: 1       Replicas: 1,0,2 Isr: 1,0,2
        Topic: topic-p3r3       Partition: 1    Leader: 0       Replicas: 0,2,1 Isr: 0,2,1
        Topic: topic-p3r3       Partition: 2    Leader: 2       Replicas: 2,1,0 Isr: 2,1,0

파티션을 기준으로 Leader 브로커, Replica 브로커, Isr(리더,브로커)을 확인할 수 있다.

메시지 전송

[kafka-0]
$ bin/kafka-console-producer.sh --bootstrap-server kafka-0:9092,kafka-1:9092,kafka-2:9092 --topic topic-p3r3
>hello kafka

프로듀서가 전송할 파티션을 결정하면 해당 파티션의 리더에게 메시지를 전송한다.

팔로워 파티션들은 리더 파티션의 데이터를 가져와 복제한다.

메시지 확인

[kafka-0]
$ bin/kafka-dump-log.sh --deep-iteration --print-data-log --files /home/ec2-user/data/kafka-logs/topic-p3r3-0/00000000000000000000.log
Dumping /home/ec2-user/data/kafka-logs/topic-p3r3-0/00000000000000000000.log
Log starting offset: 0
baseOffset: 0 lastOffset: 0 count: 1 baseSequence: 0 lastSequence: 0 producerId: 0 producerEpoch: 0 partitionLeaderEpoch: 3 isTransactional: false isControl: false deleteHorizonMs: OptionalLong.empty position: 0 CreateTime: 1676881897607 size: 79 magic: 2 compresscodec: none crc: 1301629467 isvalid: true
| offset: 0 CreateTime: 1676881897607 keySize: -1 valueSize: 11 sequence: 0 headerKeys: [] payload: hello kafka

5) 컨트롤러 브로커

컨트롤러 브로커는 브로커들의 파티션 리더를 선출하는 역할을 하는데, 컨트롤러는 주키퍼에 의해 결정된다.

주키퍼

주키퍼는 디렉토리 구조 기반의 Z Node를 활용해 개별 노드의 중요 정보를 담고 있으며 Z Node를 계속 모니터링하며 Z Node에 변경 발생 시 Watch Event가 트리거 되어 변경 정보가 개별 노드들에 통보한다.

[zookeeper]
$ bin/zookeeper-shell.sh localhost:2181

# 노드 확인
ls /
[admin, brokers, cluster, config, consumers, controller, controller_epoch, feature, isr_change_notification, latest_producer_id_block, log_dir_event_notification, zookeeper]

# 컨트롤러 확인
get /controller
{"version":2,"brokerid":0,"timestamp":"1676881398744","kraftControllerEpoch":-1}

클러스터에서 주키퍼의 역할은 다음과 같다

Controller Broker 선출(Election)
Kafka 클러스터내 Broker들의 List, Broker Join/Leave 관리 및 통보
Topic의 파티션, replicas등의 정보를 가짐

Heartbeat

카프카 브로커는 주기적으로 Zookeeper에 접속하면서 Session Heartbeat을 전송하여 자신의 상태를 보고하는데

Zookeeeper는 zookeeper.session.timeout.ms 이내에 Heartbeat을 받지 못하면 해당 브로커의 노드 정보를 삭제하고 Controller 노드에게 변경 사실을 통보한다.

컨트롤러

Zookeeper에 가장 처음 접속을 요청한 Broker가 Controller가 되고 Controller는 파티션에 대한 Leader Election을 수행한다.

Leader Election

Controller는 Zookeeper로 부터 broker 추가/Down등의 정보를 받으면 해당 broker로 인해 영향을 받는 파티션들에 대해서 새로운 Leader Election을 수행한다.

broker-2 Shutdown
Zookeeper는 session 기간동안 Heartbeat이 오지 않으므로 broker-2의 노드 정보 갱신
Controller는 Zookeeper를 모니터링 하던 중 Watch Event로 broker-2에 대한 Down 정보를 받음
Controller는 다운된 브로커가 관리하던 파티션들에 대해 새로운 Leader/Follower 결정
결정된 새로운 Leader/Follower 정보를 Zookeeper에 저장
해당 파티션을 복제하는 모든 브로커들에게 새로운 Leader/Follower 정보를 전달하고 새로운 Leader로 부터 복제 수행할 것을 요청
Controller는 모든 브로커가 가지는 Metadatacache를 새로운 Leader/Follower 정보로 갱신할 것을 요청

4. ISR

ISR(In-Sync-Replicas)은 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태를 뜻한다.

리더 파티션에 새로운 레코드가 추가되어 오프셋이 증가하면 팔로워 파티션이 위치한 브로커는 리더 파티션의 데이터를 복제하는데 리터 파티션에 데이터가 적제된 이후 팔로워 파티션이 복제하는 시간차 때문에 리터 파티션과 팔로워 파티션 간에 오프셋 차이가 발생한다.

리더 파티션은 replica.lag.time.max.ms 만큼의 주기를 가지고 팔로워 파티션이 데이터를 복제하는지 확인한다.

replica.lag.time.max.ms값보다 긴 시간동안 데이터를 가져가지 않는다면 해당 팔로워 파티션에 문제가 생긴 것으로 판단하고 ISR 그룹에서 제외한다.

min.insync.replicas 파라미터는 브로커의 설정값으로 Producer가 acks=all 로 성공적으로 메시지를 보낼 수 있는 최소한의 ISR 브로커 개수를 의미한다. 프로듀서의 Acks=all 일때, min.insync.replicas 값보다 ISR 브로커의 개수가 작으면 프로듀서에게 Error를 반환한다. (NotEnoughReplicasException 또는 NotEnoughReplicasAfterAppendException)

1) 리더 파티션 선출

(1) Preferred Leader Election

파티션 별로 최초 할당된 Leader/Follower Broker설정을 Preferred Broker로 그대로 유지한다.

auto.leader.rebalance.enable=true, leader.imbalance.check.interval.seconds를 일정시간으로 설정(기본 300초)하면 브로커가 shutdown후 재 기동될 때 Preferred Leader Broker를 일정 시간 이후에 리더로 재선출한다.

Topic: topic-p3r3       TopicId: pdUUUMzuSd2-xuD2kgrmFg PartitionCount: 3       ReplicationFactor: 3    Configs:
        Topic: topic-p3r3       Partition: 0    Leader: 0     Replicas: 1,0,2 Isr: 0
        Topic: topic-p3r3       Partition: 1    Leader: 0     Replicas: 0,2,1 Isr: 0
        Topic: topic-p3r3       Partition: 2    Leader: 0     Replicas: 2,1,0 Isr: 0

(2) Unclean Leader Election

unclean.leader.election.enable 옵션으로 ISR이 아닌 팔로워 파티션을 리더 파티션으로 선출 가능한지 여부를 선택할 수 있다.

unclean.leader.election.enable: false

ISR이 아닌 팔로워 파티션을 리더로 선출하지 않는다.
리더 파티션이 존재하는 브로커가 다시 시작되기 까지 기다리기 때문에 서비스가 중단된다.
대신 데이터의 유실은 발생하지 않는다.

Topic: topic-p3r3       TopicId: pdUUUMzuSd2-xuD2kgrmFg PartitionCount: 3       ReplicationFactor: 3    Configs:
        Topic: topic-p3r3       Partition: 0    Leader: none     Replicas: 1,0,2 Isr: 0
        Topic: topic-p3r3       Partition: 1    Leader: none     Replicas: 0,2,1 Isr: 0
        Topic: topic-p3r3       Partition: 2    Leader: none     Replicas: 2,1,0 Isr: 0

unclean.leader.election.enable: true

ISR이 아닌 팔로워 파티션이 리더로 선출될 수 있다.
서비스가 중단되지 않는다.
동기화되지 않은 파티션이 리더로 선출되므로 일부 데이터가 유실될 수 있다.

$ bin/kafka-configs.sh --bootstrap-server broker-1:9092 \
--entity-type topics \
--entity-name topic-p3r3 \
--describe --all | grep unclean

... unclean.leader.election.enable=false ...

$ bin/kafka-configs.sh --bootstrap-server broker-1:9092 \
--entity-type topics \
--entity-name topic-p3r3 \
--alter \
--add-config unclean.leader.election.enable=true

일부 데이터가 유실되더라도 토픽과 연동 중인 서비스의 무중단이 더 중요하다면 true,

서비스가 중단되더라도 데이터가 유실되면 안되는 경우 false로 설정한다.

6. Kafka Config

Config 구분	설명
Broker와 Topic 레벨 Config	• Kafka 서버에서 설정되는 Config • Topic의 Config 값은 Broker 레벨에서 지정한 Config를 기본으로 설정하며 별도의 Topic 레벨 Config를 설정할 경우 이를 따름 • 보통 server.properties에 있는 Config는 변경시 Broker 재기동이 필요한 Static Config이며, Dynamic Config는 kafka-configs를 이용하여 동적으로 config 변경 가능.
Producer와 Consumer 레벨 Config	• Kafka 클라이언트에서 설정되는 Config • Client 레벨에서 설정되므로 server.properties에 존재하지 않고, kafka-configs로 수정할 수 없으며 Client 수행시마다 설정할 수 있음

kafka-configs.sh 명령어로 브로커와 토픽 레벨의 설정을 변경할 수 있다.

# broker 0번의 config 설정 확인
$ bin/kafka-configs.sh --bootstrap-server kafka-0:9092 --entity-type brokers --entity-name 0 --all --describe

# topic의 config 설정 확인
$ bin/kafka-configs.sh --bootstrap-server kafka-0:9092 --entity-type topics --entity-name multipart-topic --all --describe
$ bin/kafka-configs.sh --bootstrap-server kafka-0:9092 --entity-type topics --entity-name multipart-topic --all --describe \
| grep max.message.bytes

# topic의 config 설정 변경
$ bin/kafka-configs.sh --bootstrap-server kafka-0:9092 --entity-type topics --entity-name multipart-topic --alter \
--add-config max.message.bytes=2088000

# 변경한 topic의 config를 다시 Default값으로 원복
$ bin/kafka-configs.sh --bootstrap-server kafka-0:9092 --entity-type topics --entity-name multipart-topic --alter \
--delete-config max.message.bytes

참고

[Kafka] 1. 카프카 기본 개념

mandykr — Wed, 1 Feb 2023 13:13:29 +0900

1. 카프카

2. 주키퍼, 클러스터, 브로커

3. 프로듀서

4. 컨슈머

1. 카프카

카프카는 링크드인의 데이터팀이 파편화된 데이터 파이프라인의 복잡도를 낮추기 위해 개발한 오픈소스 프로젝트이다.

데이터 파이프라인
엔드 투 엔드 방식의 데이터 수집 및 적재를 개선하고 안정성을 추구하며, 유연하면서도 확장 가능하게 자동화한 것

높은 처리량

카프카는 프로듀서가 브로커로 데이터를 보낼 때와 컨슈머가 브로커로부터 데이터를 받을 때 많은 양의 데이터를 묶음 단위로 처리하기 때문에 네트워크 비용을 최소화할 수 있다.

또한, 파티션을 통해 데이터를 병렬 처리할 수 있어 시간당 데이터 처리량을 늘릴 수 있다.

확장성

카프카는 데이터가 적을 때는 클러스터의 브로커를 최소한의 개수로 운영하다가 데이터가 많아지면 브로커의 개수를 늘려 스케일 아웃할 수 있다. 반대로 데이터 개수가 적어지면 브로커 개수를 줄여 스케일 인할 수 있다.

영속성

카프카는 전송받은 데이터를 메모리가 아닌 파일 시스템에 적재하고 페이지 캐시 메모리 영역을 사용해 파일 시스템에 데이터를 저장, 전송하는 과정에서의 처리량을 높였다. 디스크 기반의 파일 시스템을 활용한 덕분에 브로커 애플리케이션이 장애 발생으로 종료되더라도 프로세스를 재시작하여 안전하게 데이터를 다시 처리할 수 있다.

고가용성

카프카 클러스터는 프로듀서에서 전송받은 데이터를 1대의 브로커에 저장하고 나머지 브로커에 복제된 데이터를 저장하기 때문에 한 브로커에 장애가 발생하더라도 지속적인 데이터 처리가 가능하다.

2. 주키퍼, 클러스터, 브로커

1) 주키퍼

주키퍼는 카프카의 메타데이터를 관리하는 데 사용된다.

통신 보안규칙, jmx port 상태 정보, host 정보
컨트롤러 역할을 하는 브로커 정보
카프카에 저장된 토픽 목록 정보

2) 클러스터, 브로커

브로커는 카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체이다.

카프카 클러스터로 묶인 브로커들은 프로듀서가 보낸 데이터를 안전하게 분산 저장하고 복제하는 역할을 수행한다.

(1) 데이터 저장, 전송

프로듀서로부터 데이터를 전달받으면 카프카 브로커는 프로듀서가 요청한 토픽의 파티션에 데이터를 저장하고 컨슈머가 데이터를 요청하면 파티션에 저장된 데이터를 전달한다.

프로듀서로부터 전달받은 데이터는 파일 시스템에 저장된다.

(토픽의 파티션이 11개이면 11개의 디렉토리가 생성된다.)

파일 시스템은 메모리에 올려서 사용하는 것보다 입출력 속도가 현저히 느리지만 카프카는 페이지 캐시를 사용하여 디스크 입출력 속도를 높였다.

(2) 데이터 복제, 싱크

토픽을 생성할 때 파티션의 복제 개수를 옵션으로 설정할 수 있다. (기본값은 브로커에 설정된 값)

복제를 통해 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용할 수 있다.

복제는 파티션 단위로 이루어진다.

복제된 파티션은 리더와 팔로워로 구성된다.

팔로워 파티션들은 리더 파티션의 오프셋을 확인하여 현재 자신이 가지고 있는 오프셋과 차이가 나는 경우 리더 파티션으로부터 데이터를 가져와 자신의 파티션에 저장한다.

리더 파티션만 프로듀서, 컨슈머와 직접 통신한다.

리더 파티션이 저장된 브로커가 다운되면 리더 파티션은 사용할 수 없기 때문에 팔로워 파티션 중 하나가 리더 파티션 지위를 넘겨 받는다.

(3) 컨트롤러

클러스터의 브로커 중 한 대가 컨트롤러의 역할을 수행 한다.

컨트롤러는 다른 브로커들의 상태를 체크하고 장애로 브로커가 클러스터에서 빠지는 경우 리더 파티션을 재분배한다.

컨트롤러 역할을 하는 브로커에 장애가 생기면 다른 브로커가 컨트롤러 역할을 한다.

(4) 데이터 삭제

카프카는 컨슈머가 데이터를 가져가더라도 토픽의 데이터는 삭제되지 않고 오직 브로커만이 데이터를 삭제할 수 있다.

로그 세그먼트 단위로 삭제되는 데이터의 기한을 설정할 수 있고 오래된 데이터를 압축하는 정책을 가져갈 수도 있다.

(5) 컨슈머 오프셋 저장

컨슈머 그룹은 토픽이 특정 파티션으로부터 데이터를 가져가서 처리하고 이 파티션의 어느 레코드까지 가져갔는지 확이하기 위해 오프셋을 커밋한다.

커밋한 오프셋은 __consumer_offsets 토픽에 저장된다.

(6) 코디네이터

클러스터의 브로커중 한 대가 코디네이터의 역할을 수행한다.

코디네이터는 컨슈머 그룹의 상태를 체크하고 파티션을 컨슈머와 매칭되도록 분배하는 역할을 한다.

컨슈머가 컨슈머 그룹에서 빠지면 매칭되지 않은 파티션을 정상 동작하는 컨슈머로 할당하는 리밸런스 과정을 수행한다.

3) 토픽, 파티션

토픽은 카프카에서 데이터를 구분하기 위해 사용하는 단위이다.

토픽은 1개 이상의 파티션을 소유하고 있다.

파티션에는 프로듀서가 보낸 데이터인 레코드들이 저장된다.

파티션은 컨슈머들이 레코드를 병렬로 처리할 수 있도록 매칭된다.

3. 프로듀서

카프카 클라이언트를 라이브러리로 추가하여 프로듀서 애플리케이션을 만들 수 있다.

프로듀서는 카프카 브로커로 데이터를 전송할 때 내부적으로 파티셔너, 배치 생성 단계를 거친다.

1) ProducerRecord

전송하고자 하는 데이터는 ProducerRecord 클래스를 통해 인스턴스를 생성한다.

필수값인 토픽과 메시지 값을 설정하고 필요에 따라 파티션 번호, 타임스탬프, 메시지 키를 설정할 수 있다.

2) Partitioner

파티셔너는 ProducerRecord를 토픽의 어느 파티션으로 전송할 지 결정한다.

기본 파티셔너는 DefaultPartitioner 이고 프로듀서 API는 RoundRobinPartitioner, UniformStickyPartitioner를 제공한다.

Partitioner 인터페이스를 상속받은 사용자 정의 클래스를 만들 수 있다.

3) Accumulator

프로듀서는 파티셔너에 의해 구분된 레코드를 어큐뮬레이터에 버퍼로 쌓아놓고 배치로 묶어서 전송함으로써 처리량을 향상시킨다.

4. 컨슈머

카프카 클라이언트를 라이브러리로 추가하여 컨슈머 애플리케이션을 만들 수 있다.

컨슈머는 카프카 브로커에 적재된 데이터를 가져와서 필요한 처리를 한다.

1) Fetcher

컨슈머 애플리케이션을 실행하면 내부에서 Fetcher 인스턴스가 생성되어 컨슈머가 poll() 메서드를 호출하기 전에 미리 레코드들을 내부 큐로 가져온다.

이후에 사용자가 명시적으로 poll() 메서드를 호출하면 컨슈머는 내부 큐에 있는 레코드들을 받아 처리를 수행한다.

2) 컨슈머 그룹

컨슈머 그룹은 다른 컨슈커 그룹과 격리되는 특징을 가지고 있다.

따라서 프로듀서가 보낸 데이터를 각기 다른 역할을 하는 컨슈머 그룹끼리 영향을 받지 않게 처리할 수 있다.

예를 들어, 각기 다른 저장소에 저장하는 컨슈머를 다른 컨슈머 그룹으로 묶음으로써 각 저장소의 장애에 격리되어 운영할 수 있다.

컨슈머 그룹의 컨슈머 개수는 가져가고자 하는 토픽의 파티션 개수보다 작거나 같아야 한다.

3개의 파티션을 가진 토픽에서 4개의 컨슈머로 이루어진 컨슈머 그룹은 1개의 컨슈머가 파티션을 할당받지 못하고 유휴상태가 된다.

3) 컨슈머

데이터 처리중 발생한 리밸런싱에 대응하는 코드를 작성해야 한다.

파티션이 컨슈머에 재할당 되는 과정을 리밸런싱이라고 한다.
리밸런싱은 카프카 브로커중 한 대가 역할을 맡는 코디네이터에 의해 발생한다.

다음 상황에서 리밸런싱이 발생한다.

컨슈머가 추가되는 상황
컨슈머가 제외되는 상황

리밸런싱으로 컨슈머의 가용성을 높일 수 있지만 리밸런싱이 발생할 때 파티션의 소유권을 재할당 하는 과정에서 데이터의 중복이나 유실이 발생할 수 있다.

따라서 컨슈머는 브로커로부터 데이터를 어디까지 가져갔는지 커밋을 통해 기록해야 한다.

커밋은 브로커의 내부 토픽(__consumer_offsets)에 기록된다.

명시적 오프셋 커밋

poll() 메서드 호출 후 일정 간격마다 자동으로 커밋
poll() 메서드 호출 이후에 리밸런싱 또는 강제 종료 시 데이터 중복 또는 유실 발생 가능

비명시적 오프셋 커밋

동기 오프셋 커밋
- commitSync() 사용
- 브로커에 커밋 요청을 하고 응답을 기다린다.
- 컨슈머의 처리량에 영향을 미침

비동기 오프셋 커밋
- commitAsync() 사용
- 브로커에 커밋 요청을 하고 응답을 기다리지 않는다.
- 커밋 요청이 실패한 경우 현재 처리중인 데이터의 순서를 보장하지 않으며 데이터 중복 처리가 발생할 수 있다.

참고

스프링 DB 1편 - 데이터 접근 핵심 원리(김영한)

비동기 메시징(SNS-SQS Fanout)

mandykr — Fri, 2 Dec 2022 14:46:01 +0900

1. 메시징

2. 이벤트기반 아키텍처

서비스에 적용 가능한 IPC(Inter-Process Communication) 기술은 HTTP 기반 REST나 gRPC 등 동기 요청/응답 기반의 통신 매커니즘도 있고, AMQP, STOMP 등 비동기 메시지 기반의 통신 메커니즘도 있다.

IPC의 선택은 시스템 가용성에 영향을 미치는데, 요청을 처리하는 과정에서 타 서비스와 동기 통신을 하면 그만큼 가용성이 떨어지므로 가능한 서비스가 비동기 메시징을 이용하여 통신하도록 설계하는 것이 좋다.

1. 메시징

메시징은 서비스가 메시지를 서로 비동기적으로 주고받는 통신 방식이다.

메시지

메시지는 헤더와 바디로 구성되고 종류는 다음과 같다.

문서(document) : 데이터만 포함된 제네릭한 메시지, 메시지 해석은 수신자가 결정.
커맨드(command) : 호출할 작업과 전달할 매개변수가 지정되어 있다.
이벤트(event) : 송신자에게 어떤 사건이 발생했음을 알리는 메시지(도메인 이벤트).

메시지 채널

메시지는 메시지 채널을 통해 교환되고 종류는 다음과 같다.

점대점(point-to-point) 채널 : 채널을 읽는 컨슈머 중 딱 하나만 지정하여 메시지를 전달(예: 커맨드 메시지)
발행-구독(publish-subscribe) 채널 : 같은 채널을 바라보는 모든 컨슈머에 메시지를 전달(예: 이벤트 메시지)

메시지 브로커

메시징 기반의 애플리케이션은 대부분 메시지 브로커를 사용한다.

메시지 브로커는 메시지가 지나가는 중간 지점이고 송신자가 메시지 브로커에 메시지를 쓰면 브로커는 메시지를 수신자에게 전달한다.

장점

느슨한 결합 : 클라이언트는 적절한 채널에 메시지를 보내는 식으로 요청하고 서비스 인스턴스를 몰라도 되므로 느슨한 결합을 갖게 한다.
메시지 버퍼링 : 메시지 브로커는 처리 가능한 시점까지 메시지를 버퍼링한다. 동기 요청/응답 프로토콜과 달리 메시징을 쓰면 컨슈머가 처리할 수 있을 때까지 큐에 메시지가 쌓인다.

단점

단일 장애점 가능성 : 메시지 브로커의 가용성이 낮으면 시스템의 신뢰도가 떨어진다.
운영 복잡도 부가 : 메시징 시스템 역시 설치, 구성, 운영해야 하는 시스템 컴포넌트이다.

2. 이벤트기반 아키텍처

비동기 메시징 패턴으로 이벤트 기반 아키텍처를 구축한다.

먼저, 스프링 애플리케이션 이벤트로 관심사를 분리하고 트랜잭션을 통해 데이터 일관성을 보장한다.

다음으로 AWS SNS-SQS 메시징 시스템으로 비관심사를 분리하고 외부 이벤트를 발행한다.

마지막으로 AWS SNS-SQS 메시징 시스템으로 외부 이벤트의 구독 계층을 구성한다.

1) 첫번째 구독자 계층

(1) 트랜잭셔널 메시징

트랜잭셔널 아웃박스

도메인 엔티티를 DB 업데이트 후 메시지가 전송되지 않은 상태에서 서비스가 중단되거나 메시징 시스템에 장애가 발생한 경우 시스템의 장애로 이어지는 문제가 발생할 수 있어 DB 업데이트와 메시지 발행 두 작업이 서비스에서 원자적으로 수행되도록 해야한다.

이벤트를 도메인과 동일한 저장소를 사용해 저장하면 ACID 트랜잭션에 대한 처리를 DBMS에 믿고 맡길 수 있다.

동일 저장소를 통해 데이터베이스를 저장하고 이벤트를 발행함에 안정적인 정합성을 보장하는 방식은 Transactional outbox Pattern 이라고 한다.

[ 스프링 애플리케이션 이벤트 발행 ]

@Transactional
public ProjectResponse createProject(ProjectCreateRequest request) {
    Project project = request.toProject(UUID.randomUUID());
    codeStoreValidationService.validateToApply(project);

    Project saveProject = projectRepository.save(project);
    eventPublisher.publish(ProjectEvent.of(saveProject, EventType.CREATED));
    return ProjectResponse.of(saveProject);
}

@Transactional
public void publish(ProjectEvent event) {
    eventPublisher.publishEvent(event);
}

[ 이벤트 저장 ]

@Transactional
@EventListener
public void handleEvent(ProjectEvent event) {
    projectEventRecordUseCase.record(event);
}

이벤트 재발행

구독자들이 이벤트를 정상적으로 처리하더라도, 이벤트 처리를 잘못할 수 있기 때문에 언제든 이벤트를 재발행 해줄 수 있어야 하고 이 때 구독자들이 원하는 이벤트들의 형태는 자유롭다.

따라서 다음과 같은 조건을 고려해 이벤트 형태를 설계한다.

이벤트 발행을 보장하기 위해 이벤트가 발행되었는지 확인할 수 있어야 한다.

특정 회원, 특정 행위, 특정 속성 변화, 특정 기간을 조회하여 재발행할 수 있어야 한다.

이벤트 형태

create table project_event (
   id bigint not null auto_increment,
   aggregate_id varbinary(16),
   event_type varchar(255),
   created_at datetime(6),
   published bit not null,
   published_at datetime(6)
)

정상 발행되지 않은 이벤트는 이벤트 발행 감지 배치를 통해 자동 재발행 처리되도록 한다.

(2) 관심사 분리

이벤트를 메시징 시스템으로 전달하는 것은 도메인에게는 관심사가 아니지만 시스템에서는 중요한 정책다. 이런 경우 도메인 정책에 변경없이 트랜잭션을 확장하여 구독자의 행위를 트랜잭션 내에서 처리되도록 변경할 수 있다.

[ 메시지 전달 ]

@Transactional
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleEvent(ProjectEvent event) {
    messagePublisher.publish(ProjectEventPayload.from(event));
}

2) 두번째 구독자 계층

(1) 이벤트 발행 보장

첫번째 구독자 계층에서 최초 이벤트를 기록할 때는 발행 여부를 false로 저장하였다. 두번째 구독자 계층에서 이벤트 발행 여부를 기록하는 구독자를 추가하여 데이터를 업데이트 처리한다. 발행된 이벤트는 삭제하지 않고 발행 여부만 true로 변경한다.

[ 이벤트 발행여부 업데이트 ]

@SqsListener(value = "sqs-project-event-publish-record.fifo", deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS)
public void recordEventPublish(@NotificationMessage EventPayload payload) {
    log.info("listen from sqs-project-event-publish-record.fifo: {}", payload);
    projectEventRecordUseCase.recordPublish(Long.valueOf(payload.getEventId()));
}

(2) 비관심사 분리

도메인 행위가 수행될 때 함께 수행되어야 하는 정책들이 있을 수 있다. 이러한 부가 정책들이 도메인의 주 행위인 것으로 착각될 수 있으며, 의존성 관계를 확장시키고 도메인의 주 행위에 대한 응집을 방해하게 된다.

따라서 주요 기능을 찾고 비관심사를 분리하여 도메인 행위의 응집을 높이고 비관심사에 대한 결합을 느슨하게 만들어야 한다.

예를 들어 로그인 프로세스에서 부가 기능은 다음과 같을때 비 관심사로 분리한다.

“동일 계정 로그인 수 제한” 규칙에 따라 동일 계정이 로그인된 타 디바이스 로그아웃 처리
회원이 어느 디바이스에서 로그인되었는지 기록
동일 디바이스의 다른 계정 로그아웃 기록

@SqsListener(value = "${sqs.login-device-login}", deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS)
public void loginDevice(@Payload MemberLoginApplicationEvent payload) {
    devices.login(payload.getMemberNumber(), payload.getDeviceNumber());
}

@SqsListener(value = "${sqs.login-member-other-device-logout}", deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS)
public void logoutMemberOtherDevices(@Payload MemberLoginApplicationEvent payload) {
    devices.logoutMemberOtherDevices(payload.getMemberNumber(), payload.getDeviceNumber());
}

@SqsListener(value = "${sqs.login-other-member-device-logout}", deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS)
public void logoutOtherMemberDevices(@Payload MemberLoginApplicationEvent payload) {
    devices.logoutOtherMemberDevices(payload.getMemberNumber(), payload.getDeviceNumber());
}

(3) 외부 이벤트 발행

MSA 를 위한 외부 시스템과의 관심사 분리를 위한 외부 이벤트 발행이 필요하다. 외부 시스템에 이벤트를 전파하는 행위 또한 도메인 내에 존재하던 비관심사로 볼 수 있다.

@SqsListener(value = "sqs-change-project-broadcast.fifo", deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS)
public void handleBroadcast(@NotificationMessage ProjectEventPayload payload) {
    log.info("listen from sqs-change-project-broadcast.fifo: {}", payload);
    messageBroadcaster.broadcast(ProjectBroadcastMessage.from(payload));
}

3) 세번째 구독자 계층

세번째 구독자 계층은 애플리케이션의 외부 이벤트를 구독하여 처리한다.

커맨드와 쿼리를 서로 분리해야 하는 필요에 따라 쿼리 서비스를 만들어 이벤트를 구독하도록 할 수 있다.

예를 들어, 여러 서비스에 흩어진 데이터를 조회하는 경우, 데이터를 저장하는 서비스와 별도로 효율적으로 쿼리하는 DB가 필요한 경우에 데이터를 저장하는 서비스가 발행한 이벤트를 구독하여 항상 최신 상태로 유지되는 DB를 쿼리하는 서비스를 만들 수 있다. CQRS 참고

정리

애플리케이션 이벤트를 통해 이벤트 발행을 보장할 수 있고 내부 이벤트를 통해 비관심사를 분리할 수 있다.

Github

참고

마이크로서비스 패턴

회원시스템 이벤트기반 아키텍처 구축하기

트랜잭셔널 메시징(아웃박스, 폴링 발행기)

mandykr — Sat, 22 Oct 2022 15:14:34 +0900

1. 트랜잭셔널 메시징

2. Amazon SQS

3. SQSListener

Github OAuth2 인증을 통해 테이블에 Account 계정을 생성하고 Github 계정 정보가 변경된 경우 Member 마이크로 서비스의 Account 레플리카를 업데이트 하는 기능을 개발한다. 트랜잭셔널 아웃박스 패턴과 폴링 발행기 패턴을 활용해 DB 업데이트와 메시지 발행에서 마이크로 서비스간의 데이터 일관성이 깨지는 문제를 해결한다.

DB 업데이트와 메시지 전송을 한 트랜잭션으로 묶지 않으면 마이크로 서비스간 데이터 일관성이 깨지는 문제가 발생할 수 있다. 예를 들어, DB 업데이트 후 메시지를 발행했지만 트랜잭션을 커밋하기 전에 서비스에 문제가 생겨 서버가 종료되는 경우 메시지는 전송되었지만 DB에는 반영되지 않는 문제가 생길 수 있다.

DB를 업데이트하는 트랜잭션의 일부로 메시지를 전송하도록 하더라도 메시지 전송이 실패하는 경우 트랜잭션이 롤백 되도록 할 수는 있지만 메시지는 전송되고 DB 업데이트에는 실패하는 경우가 발생할 수 있다.

따라서, 변경되는 DB의 트랜잭션으로 메시지를 함께 저장하면 데이터 일관성을 유지할 수 있다.

1. 트랜잭셔널 메시징

1) 트랜잭셔널 아웃박스 패턴 (Transactional Outbox Pattern)

DB 업데이트와 이벤트 생성을 트랜잭션으로 묶고 이벤트 리스너에서 도메인 이벤트를 받아 Outbox 테이블에 저장하도록 작성한다.

[ CustomOAuth2UserService ]

@RequiredArgsConstructor
@Service
public class CustomOAuth2UserService implements OAuth2UserService<OAuth2UserRequest, OAuth2User> {
    private final OAuth2UserDetailsService oAuth2UserDetailsService;
    private final ObjectMapper objectMapper;

    @Override
    public OAuth2User loadUser(OAuth2UserRequest userRequest) throws OAuth2AuthenticationException {
        // ...

        OAuth2UserDetails userDetails = oAuth2UserDetailsService
                .saveOrUpdateAccount(objectMapper.convertValue(attributes, Map.class));
    }
}

Github AOuth2 로그인이 성공하면 CustomOAuth2UserService에서 Github 계정 정보를 가져와 LoginAccountService.saveOrUpdateAccount()를 호출해 DB에 저장한다.

[ LoginAccountService, AccountEventPublisher ]

@RequiredArgsConstructor
@Transactional
@Service
public class LoginAccountService implements OAuth2UserDetailsService {
    private final AccountRepository accountRepository;
    private final AccountEventPublisher accountEventPublisher;

    @Override
    public LoginAccount saveOrUpdateAccount(Map<String, Object> accountAttributes) {
        LoginAccount loginAccount = LoginAccount.of(accountAttributes);
        Optional<Account> optional = accountRepository.findByUserName(loginAccount.getUserName());

        Account account = null;
        if (optional.isPresent()) {
            account = optional.get();
            updateAccount(account, loginAccount);
            accountEventPublisher.publishUpdatedEvent(account);
        }
        if (optional.isEmpty()) {
            account = createAccount(loginAccount);
            accountRepository.save(account);
            accountEventPublisher.publishCreatedEvent(account);
        }

        return LoginAccount.of(account);
    }
}

@RequiredArgsConstructor
@Transactional
@Service
public class AccountEventPublisher {
    private final ApplicationEventPublisher eventPublisher;

    public void publishEvent(Account account, EventType eventType) {
        AccountEventMapper eventMapper = new AccountEventMapper(account, eventType);
        eventPublisher.publishEvent(eventMapper.toAccountEvent());
    }

    public void publishUpdatedEvent(Account account) {
        publishEvent(account, EventType.UPDATED);
    }

    public void publishCreatedEvent(Account account) {
        publishEvent(account, EventType.CREATED);
    }
}

.LoginAccountService는 DB의 Account 테이블을 변경하고 AccountCreated 혹은 AccountUpdated 이벤트를 생성한다.
Account 테이블의 변경과 ApplicationEventPublisher의 publishEvent()는 한 트랜잭션으로 묶여있다.

[ AccountOutboxService ]

@Slf4j
@RequiredArgsConstructor
@Transactional
@Service
public class AccountOutboxService {
    private final AccountOutboxRepository accountOutboxRepository;

    @EventListener
    public void saveOutbox(AccountEvent accountEvent) {
        OutboxMapper outboxMapper = new OutboxMapper();
        AccountOutbox outbox = outboxMapper.createOutbox(AccountOutbox.class, accountEvent);
        accountOutboxRepository.save(outbox);
    }
}

OutboxService에서 발행한 Account 이벤트를 받아 Outbox 테이블에 저장한다.
@Transactional, @EventListener
- @Transactional 로 트랜잭션을 확장해 이벤트 발행과 Outbox 저장을 하나의 트랜잭션으로 묶는다.
- @saveOutbox에서 ObjectMapper가 동작하거나 Outbox 테이블을 변경하는 중에 예외가 발생하면 Account의 DB 변경 트랜잭션도 롤백된다.

2) 메시지 발행

폴링 발행기 패턴 (Polling Publisher Pattern)

Outbox 테이블을 지속적으로 Polling 해서 메시지 브로커로 전송한다.
DB를 자주 폴링하면 비용이 발생하고 NoSQL DB는 쿼리 능력에 따라 사용 가능 여부가 결정된다.
따라서 규모가 작을 경우 사용할 수 있고 DB 트랜잭션 로그 테일링이 좀 더 정교하고 성능이 좋은 방법이다.

로그 테일링 패턴 (Log Tailing Pattern)

트랜잭션 로그 마이너로 DB 트랜잭션 로그를 읽어 Outbox 테이블의 변경분을 하나씩 메시지 브로커로 전송한다.
트랜잭션 로그 마이너는 디비지움, DynamoDB 스트림즈 등이 있다.

예제에서는 메시지 발행에 단순하게 적용할 수 있는 방법인 폴링 발행기 패턴을 활용한다.

[ MessageRelayService ]

@RequiredArgsConstructor
@Transactional
@Service
public class MessageRelayService {
    private final AccountOutboxRepository accountOutboxRepository;
    private final AccountProducer accountProducer;

    @Value("${cdc.batch_size}")
    private int batchSize;

    @Scheduled(fixedDelayString = "${cdc.polling_ms}")
    public void sendAccountEvent() {
        List<AccountOutbox> outboxes = accountOutboxRepository.
                findAllByPublishedIsFalseOrderByIdAsc(Pageable.ofSize(batchSize))
                .toList();
        accountProducer.send(outboxes);
        outboxes.forEach(Outbox::publish);
    }
}

@EnableScheduling
@SpringBootApplication
public class PapacoAuthServiceApplication {

    public static void main(String[] args) {
        SpringApplication.run(PapacoAuthServiceApplication.class, args);
    }

}

간단하게 스프링의 Scheduling 기능을 사용해 Outbox 테이블을 폴링하도록 했다.
@Scheduled(fixedDelayString = "${cdc.polling_ms}")
- application.properties에 작성한 시간을 주기로 동작한다.
findAllByPublishedIsFalseOrderByIdAsc()
- published 값이 false인 (전송되지 않은) 데이터만 조회한다.
accountProducer.send(outboxes);
- AccountProducer는 인터페이스다.
- 인터페이스 구현체인 AccountSQSProducer를 통해 Amazon SQS로 메시지를 발행한다.
outboxes.forEach(Outbox::publish);
- 전송한 Outbox 는 필드를 업데이트한다.

[ Outbox, AccountOutbox ]

@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public abstract class Outbox {
    @CreatedDate
    LocalDateTime createdAt;
    boolean published;
    LocalDateTime publishedAt;

    public void publish() {
        this.published = true;
        this.publishedAt = LocalDateTime.now();
    }

    public abstract Outbox create(DomainEvent event, String payload);
}

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Entity
public class AccountOutbox extends Outbox {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(nullable = false)
    private Long aggregateId;

    @Column(nullable = false)
    private String aggregateType;

    @Enumerated(EnumType.STRING)
    @Column(nullable = false)
    private EventType eventType;

    @Lob
    @Column(nullable = false)
    private String payload;

    public AccountOutbox(Long aggregateId, String aggregateType, EventType eventType, String payload) {
        this.aggregateId = aggregateId;
        this.aggregateType = aggregateType;
        this.eventType = eventType;
        this.payload = payload;
    }

    @Override
    public Outbox create(DomainEvent event, String payload) {
        return new AccountOutbox(event.getAggregateId(), event.getClass().getSimpleName(), event.getEventType(), payload);
    }
}

createdAt, published, publishedAt
- 이벤트 재발행을 위한 필드
- 이벤트 타입, 시간, 애그리거트 속성으로 조회해 재발행할 수 있다.
- 이벤트 재발행은 배치를 통해 이루어진다.

[ application.properties ]

cdc.polling_ms=5000
cdc.batch_size=50

5초마다 Outbox 테이블을 폴링한다.

account 테이블 업데이트와 outbox 테이블 저장이 같은 DB 트랜잭션으로 묶여있기 때문에 메시지는 전송되었지만 account 만 업데이트되는 문제가 해결되었고, 메시지 전송과 outbox 테이블 삭제가 한 트랜잭션으로 묶여있기 때문에 메시지 전송에 실패하면 outbox 테이블도 삭제되지 않는다.

2. Amazon SQS

SQS 접근을 위한 IAM 사용자와 SQS를 생성해 애플리케이션에서 메시지를 전송한다.

MemberService에서는 SQS를 폴링해 Account 레플리카를 업데이트한다.

1) IAM 사용자 생성

SQS 서비스에 접근하기 위한 IAM 사용자그룹을 다음과 같이 두 개의 권한을 갖도록 생성한다.

AmazonEC2FullAccess
AdministratorAccess

사용자 그룹에 IAM 사용자를 생성한다.

액세스 유형 프로그래밍 방식 액세스로 선택한다.

생성된 사용자의 액세스 키 ID와 비밀 액세스 키는 애플리케이션에서 SQS에 메시지를 전송하는데 사용한다.

2) Amazon SQS 생성

fifo 방식의 SQS를 생성한다.

2) 애플리케이션 적용

[ build.gradle ]

dependencyManagement {
    imports {
        mavenBom "io.awspring.cloud:spring-cloud-aws-dependencies:2.3.3"
    }
}

dependencies {
    // aws
    implementation 'io.awspring.cloud:spring-cloud-aws-context'
    implementation 'io.awspring.cloud:spring-cloud-starter-aws-messaging'
}

스프링에서 aws를 사용하기 위해 의존성을 추가한다.

io.awspring.cloud:spring-cloud-aws-context
io.awspring.cloud:spring-cloud-starter-aws-messaging

[ application.properties ]

cloud.aws.region.static=ap-northeast-2
cloud.aws.region.auto=false
cloud.aws.stack.auto=false
cloud.aws.credentials.access-key=[access-key]
cloud.aws.credentials.secret-key=[secret-key]
cloud.aws.end-point.uri=[queue-end-point-uri]

access-key : IAM 사용자 access key
secret-key : IAM 사용자 secret key
queue-end-point-uri : SQS URL

[ SQSConfig ]

@Configuration
public class SQSConfig {
    @Value("${cloud.aws.credentials.access-key}")
    private String accessKey;

    @Value("${cloud.aws.credentials.secret-key}")
    private String secretKey;

    @Value("${cloud.aws.region.static}")
    private String region;

    @Bean
    public QueueMessagingTemplate queueMessagingTemplate(AmazonSQSAsync amazonSQSAsync){
        return new QueueMessagingTemplate(amazonSQSAsync());
    }

    private AmazonSQSAsync amazonSQSAsync() {
        BasicAWSCredentials credentials = new BasicAWSCredentials(accessKey, secretKey);
        return AmazonSQSAsyncClientBuilder
                .standard()
                .withRegion(region)
                .withCredentials(new AWSStaticCredentialsProvider(credentials))
                .build();
    }
}

QueueMessagingTemplate을 스프링 빈으로 등록한다.
- IAM 정보와 국가 정보를 함께 넣어준다.

[ AccountSQSProducer ]

@Slf4j
@RequiredArgsConstructor
@Component
public class AccountSQSProducer implements AccountProducer {
    private final QueueMessagingTemplate queueMessagingTemplate;

    @Value("${cloud.aws.end-point.uri}")
    private String endpoint;

    @Transactional
    @Override
    public void send(List<AccountOutbox> outboxes) {
        outboxes.forEach(outbox -> {
            Message<String> message = MessageBuilder.withPayload(outbox.getPayload())
                    .setHeader(SqsMessageHeaders.SQS_GROUP_ID_HEADER, String.valueOf(outbox.getAggregateId()))
                    .setHeader(SqsMessageHeaders.SQS_DEDUPLICATION_ID_HEADER, String.valueOf(outbox.getId()))
                    .setHeader(OutboxMessageHeaders.AGGREGATE_TYPE, outbox.getAggregateType())
                    .build();

            queueMessagingTemplate.send(endpoint, message);
            log.info("Message: {}, {}, {}", outbox.getAggregateId(), outbox.getId(), message);
        });
    }
}

FIFO 방식으로 메시지를 전달하기 위해 두 개의 헤더가 필요하다.
- SQS_GROUP_ID_HEADER : account의 id, 메시지 그룹을 만들어 메시지가 순서대로 처리되도록 한다.
- SQS_DEDUPLICATION_ID_HEADER : outbox 의 id, 중복 메시지 전송을 5분간 방지한다.

3. SQSListener

Member Service에서 SQS를 폴링해 Auth Service에서 전송한 메시지를 가져온다.

Account 이벤트를 읽어 Member Service 내의 Account 레플리카를 업데이트한다.

[ build.gradle, application.properties ]

Auth Service의 설정과 동일하다.

[ AccountSQSConsumer ]

메시지는 전송했는데 outbox 테이블을 삭제하는 과정에서 문제가 발생하면 이 후에 메시지를 중복 전송하는 문제가 생길 수 있다.

Amazon SQS의 FIFO 방식으로 메시지를 전송할 때 SQS_DEDUPLICATION_ID_HEADER 정보를 함께 넣어 주는데 이 값은 메시지가 중복인지를 확인하는데 사용된다. 이는 중복 메시지를 5분 동안 전송하지 않는데 사용되기 때문에 이 후에는 중복 메시지가 전송될 수 있다. 따라서 확실한 처리는 메시지를 받는 Member Service에서 해주어야 한다.

@Slf4j
@RequiredArgsConstructor
@Transactional
@Service
public class AccountSQSConsumer implements AccountConsumer {
    private final ProcessedEventRepository eventRepository;
    private final AccountRepository accountRepository;
    private final ObjectMapper objectMapper;

    @Override
    @SqsListener(value = "sqs-login-account-update.fifo", deletionPolicy = SqsMessageDeletionPolicy.ON_SUCCESS)
    public void receive(String payload, @Headers Map<String, String> headers) {
        Long messageId = Long.getLong(headers.get(SqsMessageHeaders.SQS_DEDUPLICATION_ID_HEADER));
        Long aggregateId = Long.getLong(headers.get(SqsMessageHeaders.SQS_GROUP_ID_HEADER));
        String aggregateType = headers.get(OutboxMessageHeaders.AGGREGATE_TYPE);

        checkDuplicate(messageId, aggregateType);
        process(payload, headers);
        saveProcessedMessage(messageId, aggregateId, aggregateType);
    }

    @Override
    public void checkDuplicate(Long duplicateId, String aggregateType) {
        if (eventRepository.findByIdAndAggregateType(duplicateId, aggregateType).isPresent()) {
            throw new MessageReceiveDuplicatedException(duplicateId);
        }
    }

    @Override
    public void process(String payload, Map<String, String> headers) {
        try {
            AccountEvent accountEvent = objectMapper.readValue(payload, AccountEvent.class);
            accountRepository.findById(accountEvent.getAggregateId())
                    .ifPresentOrElse(
                            entity -> entity.update(accountEvent.getName(), accountEvent.getEmail()),
                            () -> saveAccount(accountEvent)
                    );
        } catch (JsonProcessingException | IllegalArgumentException e) {
            log.error("payload={}, headers={}", payload, headers, e);
            throw new MessageProcessingFailedException(e);
        }
    }

    private void saveAccount(AccountEvent accountEvent) {
        Account account = accountEvent.toAccount();
        accountRepository.save(account);
    }

    @Override
    public void saveProcessedMessage(Long messageId, Long aggregateId, String aggregateType) {
        eventRepository.save(new ProcessedMessage(messageId, aggregateId, aggregateType));
    }
}

@SqsListener
- value: SQS 큐 이름
- deletionPolicy: 메시지 삭제 방식 정의
  - SqsMessageDeletionPolicy.ON_SUCCESS : receive() 메소드에서 예외가 발생하지 않으면 삭제
checkDuplicate() : 메시지를 중복 수신했는지 확인한다.
process() : 메시지를 받아 처리한다.
- SQSMessageProcessingFaildException
  - 다음 두 개의 예외가 발생했을 때 잡아서 명시적으로 커스텀 예외로 처리한다.
    - objectMapper.readValue(payload, AccountEvent.class) → JsonProcessingException
    - accountRepository.save(account) → IllegalArgumentException
- 예외가 발생하지 않으면 Account를 업데이트 한다.
saveProcessedMessage() : 메시지 처리가 완료되었으면 수신한 Account 이벤트를 저장한다
- 메시지 중복 체크에 활용한다.

참고

마이크로서비스 패턴

회원시스템 이벤트기반 아키텍처 구축하기

[Spring] 예외 처리

mandykr — Fri, 21 Oct 2022 16:36:33 +0900

1. 자바 예외

2. 자바 예외 활용

3. 예외 포함과 스택 트레이스

4. 예외 추상화

5. JDBC 반복 문제 해결 - JdbcTemplate

6. 서블릿 예외처리

7. 스프링 부트 오류 페이지

8. API 예외처리

목표

자바의 체크 예외와 언체크(런타임) 예외의 활용법을 이해하고 스프링에서 제공하는 예외 추상화를 통해 특정 기술에 의존하지 않고 순수한 서비스 계층을 유지하는 방법에 대해 알아본다.
서블릿의 예외처리 과정을 이해하고 스프링에서 예외를 공통으로 처리하는 방법에 대해 알아본다.

1. 자바 예외

1) 예외 계층

(1) Throwable

최상위 예외이다. 하위에 Exception 과 Error 가 있다.

(2) Error

메모리 부족이나 심각한 시스템 오류와 같이 애플리케이션에서 복구 불가능한 시스템 예외이다.

애플리케이션 개발자는 이 예외를 잡으려고 해서는 안된다.

상위 예외를 catch 로 잡으면 그 하위 예외까지 함께 잡기 때문에

애플리케이션 로직에서는 Throwable 예외도 잡으면 안되는데, Error 예외도 함께 잡을 수 있기 때문에다.

애플리케이션 로직은 이런 이유로 Exception 부터 필요한 예외로 생각하고 잡으면 된다.

참고로 Error 도 언체크 예외이다.

(3) Exception

체크 예외
애플리케이션 로직에서 사용할 수 있는 실질적인 최상위 예외이다.

Exception 과 그 하위 예외(단, RuntimeException 제외)는 모두 컴파일러가 체크하는 체크 예외이다.

(4) RuntimeException

언체크 예외, 런타임 예외

컴파일러가 체크 하지 않는 언체크 예외이다.

RuntimeException 과 그 자식 예외는 모두 언체크 예외이다.

2) 체크 예외

Exception을 상속받은 예외는 체크 예외가 된다.

public class MyCheckedException extends Exception {
    public MyCheckedException(String message) {
        super(message);
    }
}

체크 예외는 try ~ catch로 잡아서 처리하거나, 또는 thorws로 밖으로 던지도록 선언해야 한다.

그렇지 않으면 컴파일 오류가 발생한다.

public class Service {
    public void callCatch() {
        try {
            repository.call();
        } catch (MyCheckedException e) {
            log.info("예외 처리, message={}", e.getMessage(), e);
        }
    }

    public void callThrow() throws MyCheckedException {
        repository.call();
    }
}

public class Repository {
    public void call() throws MyCheckedException {
        throw new MyCheckedException("ex");
    }
}

log.info("예외 처리, message={}", e.getMessage(), e);

로그를 남길 때 로그의 마지막 인수에 예외 객체를 전달해주면 로그가 해당 예외의 스택 트레이스를 추가로 출력해준다.

Exception 으로 MyCheckedException 을 잡거나 던질 수 있다.

catch는 해당 타입과 그 하위 타입을 모두 잡을 수 있다.
예외를 밖으로 던지는 경우에도 해당 타입과 그 하위 타입을 모두 던질 수 있다

▶ 체크 예외 장단점

장점: 개발자가 실수로 예외를 누락하지 않도록 컴파일러를 통해 문제를 잡아주는 훌륭한 안전 장치이다.
단점: 하지만 실제로는 개발자가 모든 체크 예외를 반드시 잡거나 던지도록 처리해야 하기 때문에, 너무 번거로운 일이 된다. 크게 신경쓰고 싶지 않은 예외까지 모두 챙겨야 한다. 추가로 의존관계에 따른 단점도 있다.

3) 언체크 예외

RuntimeException 과 그 하위 예외는 언체크 예외로 분류된다.

public class MyUncheckedException extends RuntimeException {
    public MyUncheckedException(String message) {
        super(message);
    }
}

언체크 예외는 컴파일러가 예외를 체크하지 않는다.

언체크 예외는 예외를 던지는 throws 를 선언하지 않고 생략할 수 있다. 이 경우 자동으로 예외를 던진다.

public class Service {
    public void callCatch() {
        try {
            repository.call();
        } catch (MyUncheckedException e) {
            log.info("예외 처리, message={}", e.getMessage(), e);
        }
    }

    public void callThrow() {
        repository.call();
    }
}

public class Repository {
    public void call() {
        throw new MyUncheckedException("ex");
    }
}

언체크 예외는 throws를 생략해도 되지만 중요한 예외의 경우 선언해두면 해당 코드를 호출하는 개발자가 이런 예외가 발생한다는 점을 IDE를 통해 좀 더 편리하게 인지할 수 있다.

public void callThrow() throws MyCheckedException {
    repository.call();
}

▶ 언체크 예외 장단점

장점: 신경쓰고 싶지 않은 언체크 예외를 무시할 수 있다.
체크 예외의 경우 처리할 수 없는 예외를 밖으로던지려면 항상 throws 예외 를 선언해야 하지만, 언체크 예외는 이 부분을 생략할 수 있다. 신경쓰고 싶지 않은 예외의 의존관계를 참조하지 않아도 되는 장점이 있다.
단점: 언체크 예외는 개발자가 실수로 예외를 누락할 수 있다. 반면에 체크 예외는 컴파일러를 통해 예외 누락을 잡아준다.

2. 자바 예외 활용

(1) 체크 예외 활용

체크 예외는 컴파일러가 예외 누락을 체크해주기 때문에 개발자가 실수로 예외를 놓치는 것을 막아준다.

하지만 다음과 같은 문제점을 갖는다.

public class Controller {
    Service service = new Service();
    public void request() throws SQLException, ConnectException {
        service.logic();
    }
}

public class Service {
    Repository repository = new Repository();
    NetworkClient networkClient = new NetworkClient();
    public void logic() throws SQLException, ConnectException {
        repository.call();
        networkClient.call();
    }
}

public class NetworkClient {
    public void call() throws ConnectException {
        throw new ConnectException("연결 실패");
    }
}

public class Repository {
    public void call() throws SQLException {
        throw new SQLException("ex");
    }
}

▶ 복구 불가능한 예외

SQLException 을 예를 들면 데이터베이스에 무언가 문제가 있어서 발생하는 예외이다.

이런 문제들은 대부분 복구가 불가능하다. 특히나 대부분의 서비스나 컨트롤러는 이런 문제를 해결할 수는 없다.

따라서 이런 문제들은 일관성 있게 공통으로 처리해야 한다.

오류 로그를 남기고 개발자가 해당 오류를 빠르게 인지하는 것이 필요하다.

서블릿 필터, 스프링 인터셉터, 스프링의 ControllerAdvice 를 사용하면 이런 부분을 깔끔하게 공통으로 해결할 수 있다.

▶ 의존 관계에 대한 문제

throws SQLException, ConnectException 처럼 예외를 던지는 부분을 코드에 선언하면 서비스, 컨트롤러에서 java.sql.SQLException 을 의존하기 때문에 문제가 된다.

리포지토리를 JDBC가 아닌 JPA로 변경한다면,
SQLException 에 의존하던 모든 서비스, 컨트롤러의 코드를 JPAException 에 의존하도록 고쳐야 한다.

OCP, DI를 통해 클라이언트 코드의 변경 없이 대상 구현체를 변경할 수 있다는 장점이 사라지게 된다.

(2) 언체크 예외 활용

체크 예외를 다음과 같이 언체크 예외로 변환해 체크 예외를 사용할 때 발생하는 문제를 해결한다.

SQLException → RuntimeSQLException
ConnectException → RuntimeConnectException

public class Controller {
    Service service = new Service();
    public void request() {
        service.logic();
    }
}

public class Service {
    Repository repository = new Repository();
    NetworkClient networkClient = new NetworkClient();
    public void logic() {
        repository.call();
        networkClient.call();
    }
}

public class NetworkClient {
    public void call() {
        throw new RuntimeConnectException("연결 실패");
    }
}

public class Repository {
    public void call() {
        try {
            runSQL();
        } catch (SQLException e) {
            throw new RuntimeSQLException(e);
        }
    }
    
    private void runSQL() throws SQLException {
        throw new SQLException("ex");
    }
}

public class RuntimeConnectException extends RuntimeException {
    public RuntimeConnectException(String message) {
        super(message);
    }
}

public class RuntimeSQLException extends RuntimeException {
    public RuntimeSQLException() {
    }
    public RuntimeSQLException(Throwable cause) {
        super(cause);
    }
}

▶ 복구 불가능한 예외

시스템에서 발생한 예외는 대부분 복구 불가능 예외이다. 런타임 예외를 사용하면 서비스나 컨트롤러가 이런 복구 불가능한 예외를 신경쓰지 않아도 된다.

물론 이렇게 복구 불가능한 예외는 일관성 있게 공통으로 처리해야 한다.

▶ 의존 관계에 대한 문제

런타임 예외는 해당 객체가 처리할 수 없는 예외는 무시하면 된다.

따라서 체크 예외 처럼 예외를 강제로 의존하지 않아도 된다.

(3) 결론

기본적으로 언체크(런타임) 예외를 사용하자.
체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용하자.
이 경우 해당 예외를 잡아서 반드시 처리해야 하는 문제일 때만 체크 예외를 사용해야 한다.

런타임 예외를 사용하면 중간에 기술이 변경되어도 해당 예외를 사용하지 않는 컨트롤러, 서비스에서는 코드를 변경하지 않아도 된다. 구현 기술이 변경되는 경우, 예외를 공통으로 처리하는 곳에서만 변경하면 되기 때문에 변경의 영향 범위는 최소화 된다.

(4) 런타임 예외 문서화

런타임 예외는 컴파일 단계에서 체크하지 않기 때문에 문서화를 잘해야 한다.

또는 코드에 throws 런타임예외를 남겨서 중요한 예외를 인지할 수 있게 해야 한다.

 * Make an instance managed and persistent.
 * @param entity entity instance
 * @throws EntityExistsException if the entity already exists.
 * @throws IllegalArgumentException if the instance is not an
 * entity
 * @throws TransactionRequiredException if there is no transaction when
 * invoked on a container-managed entity manager of that is of type
 * <code>PersistenceContextType.TRANSACTION</code>
 */
public void persist(Object entity);

/**
 * Issue a single SQL execute, typically a DDL statement.
 * @param sql static SQL to execute
 * @throws DataAccessException if there is any problem
 */
void execute(String sql) throws DataAccessException;

3. 예외 포함과 스택 트레이스

예외를 전환할 때는 꼭! 기존 예외를 포함해야 한다.

public void call() {
    try {
        runSQL();
    } catch (SQLException e) {
        throw new RuntimeSQLException(e); //기존 예외(e) 포함
    }
}

public class RuntimeSQLException extends RuntimeException {
    public RuntimeSQLException(Throwable cause) {
        super(cause);
    }
}

throw new RuntimeSQLException(e);

예외를 포함해서 기존에 발생한 java.sql.SQLException 과 스택 트레이스를 확인할 수 있도록 해야한다.

4. 예외 추상화

리포지토리에서 SQLException을 MyDbException이라는 RuntimeException으로 변환했을때,

서비스 계층에서는 MyDbException 이라는 예외만 넘어오기 때문에 예외를 구분할 수 없는 단점이 있다.

만약 특정 상황에는 예외를 잡아서 복구하고 싶으면 예외를 어떻게 구분해서 처리할 수 있을까?

예) 키 중복 오류

1) 에러 코드

데이터베이스마다 오류별 오류 코드를 제공한다.

같은 오류여도 각각의 데이터베이스마다 정의된 오류 코드가 다르다.

키 중복 오류 코드

H2 DB: 23505
MySQL: 1062

H2 데이터베이스 오류 코드 참고
https://www.h2database.com/javadoc/org/h2/api/ErrorCode.html

2) 예외 구분

키 중복 오류에 대해 서비스 계층에서 별도 처리를 하기위해 기존에 사용했던 MyDbException 을 상속받아서 의미있는 계층을 형성한다. 데이터 중복의 경우에 사용하는 MyDuplicateKeyException을 만든다.

public class MyDuplicateKeyException extends MyDbException {
    public MyDuplicateKeyException() {
    }
    public MyDuplicateKeyException(String message) {
        super(message);
    }
    public MyDuplicateKeyException(String message, Throwable cause) {
        super(message, cause);
    }
    public MyDuplicateKeyException(Throwable cause) {
        super(cause);
    }
}

MyDuplicateKeyException은 JDBC나 JPA 같은 특정 기술에 종속적이지 않다.

따라서 이 예외를 사용하더라도 서비스 계층의 순수성을 유지할 수 있다.

하지만 리포지토리에서 이런 방식으로 예외를 구분하면 데이터베이스와 수많은 에러 코드에 의존성을 가지게 된다.

try {
    con = dataSource.getConnection();
    pstmt = con.prepareStatement(sql);
    pstmt.setString(1, member.getMemberId());
    pstmt.setInt(2, member.getMoney());
    pstmt.executeUpdate();
    return member;
} catch (SQLException e) {
    //h2 db
    if (e.getErrorCode() == 23505) {
        throw new MyDuplicateKeyException(e);
    }
    throw new MyDbException(e);
}

SQL ErrorCode는 각각의 데이터베이스 마다 다르다. 결과적으로 데이터베이스가 변경될 때 마다 ErrorCode도 모두 변경해야 한다.
데이터베이스가 전달하는 오류는 키 중복 뿐만 아니라 락이 걸린 경우, SQL 문법에 오류 있는 경우 등등 수십 수백가지 오류 코드가 있다.

3) 스프링 예외 추상화

스프링은 데이터 접근 계층이 데이터베이스와 에러 코드에 의존하는 문제들을 해결하기 위해 데이터 접근과 관련된 예외를 추상화해서 제공한다.

예외의 최고 상위는 org.springframework.dao.DataAccessException 이다.
런타임 예외를 상속 받았기 때문에 스프링이 제공하는 데이터 접근 계층의 모든 예외는 런타임 예외이다.
NonTransient와 Transient
- Transient 는 일시적이라는 뜻이다.
  Transient 하위 예외는 동일한 SQL을 다시 시도했을 때 성공할 가능성이 있다.
  예를 들어서 쿼리 타임아웃, 락과 관련된 오류들이다. 이런 오류들은 데이터베이스 상태가 좋아지거나, 락이 풀렸을 때 다시 시도하면 성공할 수 도 있다.
- NonTransient 는 일시적이지 않다는 뜻이다.
  같은 SQL을 그대로 반복해서 실행하면 실패한다.
  SQL 문법 오류, 데이터베이스 제약조건 위배 등이 있다.

(1) 예외 변환기

스프링은 데이터베이스에서 발생하는 오류 코드를 스프링이 정의한 예외로 자동으로 변환해주는 변환기를 제공한다.

void exceptionTranslator() {
    String sql = "select bad grammar";
    try {
        Connection con = dataSource.getConnection();
        PreparedStatement stmt = con.prepareStatement(sql);
        stmt.executeQuery();
    } catch (SQLException e) {
        // e.getErrorCode() = 42122        
        SQLExceptionTranslator exTranslator = new SQLErrorCodeSQLExceptionTranslator(dataSource);
		DataAccessException resultEx = exTranslator.translate("select", sql, e);
		// resultEx.getClass(): org.springframework.jdbc.BadSqlGrammarException
    }
}

translate()
- 메서드의 첫번째 파라미터는 읽을 수 있는 설명이고, 두번째는 실행한 sql, 마지막은 발생된 SQLException 을 전달하면 된다
- 이렇게 하면 적절한 스프링 데이터 접근 계층의 예외로 변환해서 반환해준다.
- SQL 문법이 잘못되었으므로 BadSqlGrammarException 을 반환

(2) sql-error-codes.xml

스프링 SQL 예외 변환기는 SQL ErrorCode를 sql-error-codes.xml 파일에 대입해서 어떤 스프링 데이터 접근 예외로 전환해야 할지 찾아낸다. 따라서 각각의 DB마다 다른 SQL ErrorCode에 대해 같은 예외를 반환할 수 있다.

예를 들어, H2 데이터베이스에서는 42000, MySQL 데이터베이스에서는 1054 가 발생하면 badSqlGrammarCodes 이기 때문에 BadSqlGrammarException 을 반환한다.

org.springframework.jdbc.support.sql-error-codes.xml

<bean id="H2" class="org.springframework.jdbc.support.SQLErrorCodes">
    <property name="badSqlGrammarCodes">
        <value>42000,42001,42101,42102,42111,42112,42121,42122,42132</value>
    </property>
    <property name="duplicateKeyCodes">
        <value>23001,23505</value>
    </property>
</bean>
<bean id="MySQL" class="org.springframework.jdbc.support.SQLErrorCodes">
    <property name="badSqlGrammarCodes">
        <value>1054,1064,1146</value>
    </property>
    <property name="duplicateKeyCodes">
        <value>1062</value>
    </property>
</bean>

스프링 예외 추상화는 데이터베이스 뿐만 아니라 특정 기술에도 종속적이지 않게 설계되어 있다.

따라서 서비스 계층에서도 스프링이 제공하는 예외를 사용하면 된다. 향후 JDBC에서 JPA로 구현 기술을 변경하더라도, 스프링은 JPA 예외를 적절한 스프링 데이터 접근 예외로 변환해준다.

5. JDBC 반복 문제 해결 - JdbcTemplate

스프링이 예외를 추상화해준 덕분에, 서비스 계층은 특정 리포지토리의 구현 기술과 예외에 종속적이지 않게 되었다.

하지만 다음과 같이 리포지토리에서는 예외 변환 코드를 반복해서 작성해야 하고 다른 반복 코드들도 존재한다.

} catch (SQLException e) {
	throw exTranslator.translate("save", sql, e);
}

JDBC 반복 문제

커넥션 조회, 커넥션 동기화
PreparedStatement 생성 및 파라미터 바인딩
쿼리 실행
결과 바인딩
예외 발생시 스프링 예외 변환기 실행
리소스 종료

스프링은 JDBC의 반복 문제를 해결하기 위해 JdbcTemplate 이라는 템플릿을 제공한다.

JdbcTemplate 은 JDBC로 개발할 때 발생하는 반복을 대부분 해결해준다. 그 뿐만 아니라 트랜잭션을 위한 커넥션 동기화는 물론이고, 예외 발생시 스프링 예외 변환기도 자동으로 실행해준다.

public class MemberRepository {
    private final JdbcTemplate template;

    public MemberRepository(DataSource dataSource) {
        template = new JdbcTemplate(dataSource);
    }

    @Override
    public Member save(Member member) {
        String sql = "insert into member(member_id, money) values(?, ?)";
        template.update(sql, member.getMemberId(), member.getMoney());
        return member;
    }

    @Override
    public Member findById(String memberId) {
        String sql = "select * from member where member_id = ?";
        return template.queryForObject(sql, memberRowMapper(), memberId);
    }

    @Override
    public void update(String memberId, int money) {
        String sql = "update member set money=? where member_id=?";
        template.update(sql, money, memberId);
    }

    @Override
    public void delete(String memberId) {
        String sql = "delete from member where member_id=?";
        template.update(sql, memberId);
    }

    private RowMapper<Member> memberRowMapper() {
        return (rs, rowNum) -> {
            Member member = new Member();
            member.setMemberId(rs.getString("member_id"));
            member.setMoney(rs.getInt("money"));
            return member;
        };
    }
}

트랜잭션 커넥션 동기화를 위해 작성해야 했던 다음과 같은 코드도 JdbcTemplate을 사용하면서 불필요해졌다.

private void close(Connection con, Statement stmt, ResultSet rs) {
    JdbcUtils.closeResultSet(rs);
    JdbcUtils.closeStatement(stmt);
    DataSourceUtils.releaseConnection(con, dataSource);
}

private Connection getConnection() {
    Connection con = DataSourceUtils.getConnection(dataSource);
    log.info("get connection={} class={}", con, con.getClass());
    return con;
}

정리

서비스 계층의 순수성
- 트랜잭션 추상화 + 트랜잭션 AOP 덕분에 서비스 계층의 순수성을 최대한 유지하면서 서비스 계층에서 트랜잭션을 사용할 수 있다.
- 스프링이 제공하는 예외 추상화와 예외 변환기 덕분에, 데이터 접근 기술이 변경되어도 서비스 계층의 순수성을 유지하면서 예외도 사용할 수 있다.
- 서비스 계층이 리포지토리 인터페이스에 의존한 덕분에 향후 리포지토리가 다른 구현 기술로 변경되어도 서비스 계층을 순수하게 유지할 수 있다.
리포지토리에서 JDBC를 사용하는 반복 코드가 JdbcTemplate 으로 대부분 제거되었다.

6. 서블릿 예외처리

애플리케이션은 사용자 요청별로 별도의 쓰레드가 할당되고, 서블릿 컨테이너 안에서 실행된다.

애플리케이션에서 예외가 발생했는데, 어디선가 try ~ catch로 예외를 잡아서 처리하면 아무런 문제가 없다.

그런데 애플리케이션에서 예외를 잡지 못하면, 다음과 같은 경로로 WAS까지 예외가 전달된다.

WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)

1) 톰캣이 제공하는 오류 페이지

스프링 부트가 제공하는 기본 예외 페이지 설정을 비활성화하면 톰캣에서 제공하는 오류 페이지를 확인할 수 있다.

application.properties

server.error.whitelabel.enabled=false

(1) 500

톰캣은 예외를 받으면 서버 내부에서 처리할 수 없는 오류가 발생한 것으로 생각해서 HTTP 상태 코드 500을 반환한다.

HTTP Status 500 – Internal Server Error

(2) 404

HTTP Status 404 – Not Found

2) 서블릿 컨테이너에게 오류를 전달하는 방법

(1) 예외 발생

@Controller
public class ServletExController {
    @GetMapping("/error-ex")
    public void errorEx() {
        throw new RuntimeException("예외 발생!");
    }
}

(2) response.sendError(HTTP 상태 코드, 오류 메시지)

HttpServletResponse 가 제공하는 sendError 라는 메서드를 사용해 서블릿 컨테이너에게 오류가 발생했다는 점을 전달할 수 있다.

@GetMapping("/error-404")
public void error404(HttpServletResponse response) throws IOException {
     response.sendError(404, "404 오류!");
}

@GetMapping("/error-500")
public void error500(HttpServletResponse response) throws IOException {
     response.sendError(500);
}

서블릿 컨테이너는 고객에게 응답 전에 response 에 sendError() 가 호출되었는지 확인한다.
그리고 호출되었다면 설정한 오류 코드에 맞추어 기본 오류 페이지를 보여준다.

3) 서블릿 오류 페이지 제공 방법

서블릿 컨테이너가 제공하는 오류 페이지가 아닌 직접 오류 처리 화면을 등록할 수 있다.

오류가 전달되면 서블릿 컨테이너는 오류 정보를 확인해 오류 페이지를 재요청한다.

(1) 오류 페이지 등록

에러 페이지 등록

/templates/error-page/404.html
/templates/error-page/500.html

에러 페이지 컨트롤러 등록

ErrorPageController
- @RequestMapping("/error-page/404")
- @RequestMapping("/error-page/500")

@Slf4j
@Controller
public class ErrorPageController {
    @RequestMapping("/error-page/404")
    public String errorPage404(HttpServletRequest request, HttpServletResponse
            response) {
        log.info("errorPage 404");
        return "error-page/404";
    }
    
    @RequestMapping("/error-page/500")
    public String errorPage500(HttpServletRequest request, HttpServletResponse
            response) {
        log.info("errorPage 500");
        return "error-page/500";
    }
}

에러 발생시 재요청 경로 설정

WebServerCustomizer

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {
    
    @Override
    public void customize(ConfigurableWebServerFactory factory) {
        ErrorPage errorPage404 = new ErrorPage(HttpStatus.NOT_FOUND, "/error-page/404");
        ErrorPage errorPage500 = new ErrorPage(HttpStatus.INTERNAL_SERVER_ERROR, "/error-page/500");
        ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-page/500");
        factory.addErrorPages(errorPage404, errorPage500, errorPageEx);
    }
}

new ErrorPage(RuntimeException.class, "/error-page/500");

RuntimeException이 발생하면 WAS는 "/error-page/500" 경로로 재요청 한다.

(2) 오류 페이지 작동원리

서블릿은 Exception(예외)이 발생해서 서블릿 밖으로 전달되거나 또는 response.sendError() 가 호출 되었을 때 설정된 오류 페이지를 찾는다. 오류 페이지를 출력하기 위해 오류 페이지를 재요청한다.

1. WAS(여기까지 전파) <- 필터 <- 서블릿 <- 인터셉터 <- 컨트롤러(예외발생)
2. WAS `/error-page/500` 다시 요청 -> 필터 -> 서블릿 -> 인터셉터 -> 컨트롤러(/errorpage/500) -> View

RuntimeException 예외가 WAS까지 전달되면, WAS는 오류 페이지 정보를 확인한다.
- new ErrorPage(RuntimeException.class, "/error-page/500"
확인해보니 RuntimeException 의 오류 페이지로 /error-page/500 이 지정되어 있다. WAS는 오류 페이지를 출력하기 위해 /error-page/500 를 다시 요청한다.

(3) request.attribute

WAS는 오류 페이지를 단순히 다시 요청만 하는 것이 아니라, 오류 정보를 request 의 attribute 에 추가해서 넘겨준다

javax.servlet.error.exception : 예외
javax.servlet.error.exception_type : 예외 타입
javax.servlet.error.message : 오류 메시지
javax.servlet.error.request_uri : 클라이언트 요청 URI
javax.servlet.error.servlet_name : 오류가 발생한 서블릿 이름
javax.servlet.error.status_code : HTTP 상태 코드

정리

1. 예외가 발생해서 WAS까지 전파된다.

2. WAS는 오류 페이지 경로를 찾아서 내부에서 오류 페이지를 호출한다. 이때 오류 페이지 경로로 필터, 서블릿, 인터셉터, 컨트롤러가 모두 다시 호출된다.

3. WAS는 오류 페이지와 함께 오류 정보를 request 의 attribute 에 추가해서 넘겨준다

4) 필터와 인터셉터 재요청 구분

오류가 발생하면 오류 페이지를 출력하기 위해 WAS 내부에서 다시 한번 호출이 발생한다.

이때 필터, 인터셉터도 모두 다시 호출된다. 따라서 오류 페이지를 출력하기 위한 내부 요청인지 구분해 필터와 인터셉터에서 비효율적으로 동작하지 않도록 해야한다.

서블릿은 이런 문제를 해결하기 위해 request.attribute에 DispatcherType 이라는 추가 정보를 제공한다.

DispatcherType

REQUEST : 클라이언트 요청
ERROR : 오류 요청
FORWARD : MVC에서 배웠던 서블릿에서 다른 서블릿이나 JSP를 호출할 때
RequestDispatcher.forward(request, response);
INCLUDE : 서블릿에서 다른 서블릿이나 JSP의 결과를 포함할 때
RequestDispatcher.include(request, response);
ASYNC : 서블릿 비동기 호출

(1) 필터에서 구분

필터는 filterRegistrationBean.setDispatcherTypes() 으로 DispatcherType에 따라 필터를 적용할 수 있다.

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Bean
    public FilterRegistrationBean logFilter() {
        FilterRegistrationBean<Filter> filterRegistrationBean = new
                FilterRegistrationBean<>();
        filterRegistrationBean.setFilter(new LogFilter());
        filterRegistrationBean.setOrder(1);
        filterRegistrationBean.addUrlPatterns("/*");
        filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);
        return filterRegistrationBean;
    }
}

filterRegistrationBean.setDispatcherTypes(DispatcherType.REQUEST, DispatcherType.ERROR);
- 클라이언트 요청은 물론이고, 오류 페이지 요청에서도 필터가 호출된다.
아무것도 넣지 않으면 기본 값이 DispatcherType.REQUEST 이다.

(2) 인터셉터에서 구분

인터셉터는 excludePathPatterns()를 이용해 오류 페이지 경로를 제외시킬 수 있다.

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LogInterceptor())
                .order(1)
                .addPathPatterns("/**")
                .excludePathPatterns(
                        "/css/**", "/*.ico"
                        , "/error", "/error-page/**" //오류 페이지 경로
                );
    }
}

7. 스프링 부트 오류 페이지

스프링 부트는 WebServerCustomizer에 예외 종류에 따라서 ErrorPage를 추가하는 과정과

예외 처리용 컨트롤러 ErrorPageController를 만드는 과정을 자동화해준다.

따라서 개발자는 특정 경로에 에러 페이지만 만들어 두면 된다.

1) 기본 오류 페이지

스프링 부트는 ErrorPage 를 자동으로 등록한다.

상태코드와 예외를 설정하지 않으면 모든 오류는 /error 를 호출하게 된다.

new ErrorPage("/error")

ErrorMvcAutoConfiguration

ErrorMvcAutoConfiguration는 /error에 오류 페이지를 자동으로 등록해준다.

private static class StaticView implements View {
	
    public void render(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response)
            throws Exception {
 
        builder.append("<html><body><h1>Whitelabel Error Page</h1>").append(
                "<p>This application has no explicit mapping for /error, so you are seeing this as a fallback.</p>")
                .append("<div id='created'>").append(timestamp).append("</div>")
                .append("<div>There was an unexpected error (type=").append(htmlEscape(model.get("error")))
                .append(", status=").append(htmlEscape(model.get("status"))).append(").</div>");

    }
}

2) BasicErrorController

스프링 부트는 BasicErrorController를 스프링 빈으로 등록한다.

BasicErrorController는 "/error " 경로를 받아 오류 페이지를 매핑한다.

@Controller
@RequestMapping("${server.error.path:${error.path:/error}}")
public class BasicErrorController extends AbstractErrorController {
	@RequestMapping(produces = MediaType.TEXT_HTML_VALUE)
	public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse response) {
		HttpStatus status = getStatus(request);
		Map<String, Object> model = Collections
				.unmodifiableMap(getErrorAttributes(request, getErrorAttributeOptions(request, MediaType.TEXT_HTML)));
		response.setStatus(status.value());
		ModelAndView modelAndView = resolveErrorView(request, response, status, model);
		return (modelAndView != null) ? modelAndView : new ModelAndView("error", model);
	}
}

BasicErrorController가 제공하는 기본 정보

BasicErrorController 컨트롤러는 다음 정보를 model에 담아서 뷰에 전달한다.

timestamp, path, status, message, error, exception, errors, trace

오류 정보 포함 여부 설정

application.properties에 오류 정보를 model 에 포함할지 여부 선택할 수 있다.

server.error.include-exception=false : exception 포함 여부( true , false )
server.error.include-message=never : message 포함 여부
server.error.include-stacktrace=never : trace 포함 여부(never, always, on_param)
server.error.include-binding-errors=never : errors 포함 여부(never, always, on_param)

실무에서는 이것들을 노출하면 안된다! 사용자에게는 오류 화면과 고객이 이해할 수 있는 간단한 오류 메시지를 보여주고 오류는 서버에 로그로 남겨서 로그로 확인해야 한다.

3) 뷰 선택 우선순위

뷰 템플릿이 정적 리소스보다 우선순위가 높고, 404, 500처럼 구체적인 것이 5xx처럼 덜 구체적인 것 보다 우선순위가 높다. 5xx, 4xx 라고 하면 500대, 400대 오류를 처리해준다.

1. 뷰 템플릿

resources/templates/error/500.html
resources/templates/error/5xx.html

2. 정적 리소스( static , public )

resources/static/error/400.html
resources/static/error/404.html
resources/static/error/4xx.html

3. 적용 대상이 없을 때 뷰 이름( error )

resources/templates/error.html

8. API 예외처리

오류 페이지는 단순히 고객에게 오류 화면을 보여주고 끝이지만, API는 각 오류 상황에 맞는 오류 응답 스펙을 정하고, JSON으로 데이터를 내려주어야 하기 때문에 생각할 내용이 더 많다.

1) JSON 응답

컨트롤러에서 예외가 발생하거나 response.sendError()로 응답하면 WAS는 기본 경로인 "/error" 를 요청해 BasicErrorController에서 받아 처리한다. HTML이 아닌 JSON으로 응답하기 위해 WebServerFactoryCustomizer를 구현하고 컨트롤러에서 WAS의 재요청을 받아 JSON으로 응답한다.

@Component
public class WebServerCustomizer implements WebServerFactoryCustomizer<ConfigurableWebServerFactory> {        
    @Override
    public void customize(ConfigurableWebServerFactory factory) {
        ErrorPage errorPageEx = new ErrorPage(RuntimeException.class, "/error-page/500");
        factory.addErrorPages(errorPageEx);
    }
}

// controller
@RequestMapping(value = "/error-page/500", produces = MediaType.APPLICATION_JSON_VALUE)
public ResponseEntity<Map<String, Object>> errorPage500Api(HttpServletRequest request, HttpServletResponse response) {
    Map<String, Object> result = new HashMap<>();
    Exception ex = (Exception) request.getAttribute(ERROR_EXCEPTION);
    result.put("status", request.getAttribute(ERROR_STATUS_CODE));
    result.put("message", ex.getMessage());
    Integer statusCode = (Integer) request.getAttribute(RequestDispatcher.ERROR_STATUS_CODE);
    return new ResponseEntity(result, HttpStatus.valueOf(statusCode));
}

produces = MediaType.APPLICATION_JSON_VALUE
- 클라이언트가 요청하는 HTTP Header의 Accept 의 값이 application/json 일 때 해당 메서드가 호출된다.
ResponseEntity 를 사용해서 응답하기 때문에 메시지 컨버터가 동작하면서 클라이언트에 JSON이 반환된다.

2) BasicErrorController

@RequestMapping의 produces 옵션으로 HTTP Header의 Accept에 따라 호출될 컨트롤러를 구분할 수 있었는데

BasicErrorController도 "/error"라는 동일한 경로에 HTML을 반환할지 JSON을 반환할지 구분해 두 개의 메소드가 정의되어 있다.

@RequestMapping(produces = MediaType.TEXT_HTML_VALUE)
public ModelAndView errorHtml(HttpServletRequest request, HttpServletResponse response) {}

@RequestMapping
public ResponseEntity<Map<String, Object>> error(HttpServletRequest request) {}

errorHtml() : produces = MediaType.TEXT_HTML_VALUE : 클라이언트 요청의 Accept 해더 값이 text/html 인 경우에는 errorHtml() 을 호출해서 view를 제공한다.
error() : 그외 경우에 호출되고 ResponseEntity 로 HTTP Body에 JSON 데이터를 반환한다.

BasicErrorController 는 HTML 페이지를 제공하는 경우에는 매우 편리하지만,

API 마다, 각각의 컨트롤러나 예외마다 서로 다른 응답 결과를 출력해야 할 수도 있다.

따라서 API 오류 처리는 @ExceptionHandler 를 사용해야한다.

3) HandlerExceptionResolver

컨트롤러에서 예외가 발생하거나 request.sendError()를 사용했을 때 컨트롤러 밖으로 던져진 예외를 해결하고, 동작 방식을 변경하고 싶으면 HandlerExceptionResolver를 사용할 수 있다. (ExceptionResolver)

직접 HandlerExceptionResolver를 구현할 수도 있고 스프링 부트가 제공하는 3가지 HandlerExceptionResolver를 사용할 수도 있다.

참고: ExceptionResolver 로 예외를 해결해도 postHandle() 은 호출되지 않는다.

(1) ExceptionResolver 활용

예외 상태 코드 변환

예외를 response.sendError(xxx) 호출로 변경해서 서블릿에서 상태 코드에 따른 오류를 처리하도록 위임
이후 WAS는 서블릿 오류 페이지를 찾아서 내부 호출, 예를 들어서 스프링 부트가 기본으로 설정한 /error 가 호출됨

WAS 재요청 생략

뷰 템플릿 처리나 API 응답 처리처럼 WAS에서 에러 페이지를 재요청할 필요가 없는 경우에 response.sendError()를 호출하지 않으면 불필요한 과정을 생략하고 깔끔하게 응답할 수 있다.
뷰 템플릿 처리
- ModelAndView 에 값을 채워서 예외에 따른 새로운 오류 화면을 뷰 렌더링 해서 고객에게 제공
API 응답 처리
- response.getWriter().println("hello"); 처럼 HTTP 응답 바디에 직접 데이터를 넣어주는 것도 가능하다. 여기에 JSON 으로 응답하면 API 응답 처리를 할 수 있다.

(2) 사용자 정의 ExceptionResolver

HTTP 요청 해더의 ACCEPT 값이 application/json 이면 JSON으로 오류를 내려주고, 그 외 경우에는 error/500에 있는 HTML 오류 페이지를 보여준다.

UserHandlerExceptionResolver

@Slf4j
public class UserHandlerExceptionResolver implements HandlerExceptionResolver {
    private final ObjectMapper objectMapper = new ObjectMapper();

    @Override
    public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
        try {
            if (ex instanceof UserException) {
                String acceptHeader = request.getHeader("accept");
                response.setStatus(HttpServletResponse.SC_BAD_REQUEST);

                if ("application/json".equals(acceptHeader)) {
                    Map<String, Object> errorResult = new HashMap<>();
                    errorResult.put("ex", ex.getClass());
                    errorResult.put("message", ex.getMessage());

                    String result = objectMapper.writeValueAsString(errorResult);
                    response.setContentType("application/json");
                    response.setCharacterEncoding("utf-8");
                    response.getWriter().write(result);
                    
                    return new ModelAndView();
                } else {
                    //TEXT/HTML
                    return new ModelAndView("error/500");
                }
            }
        } catch (IOException e) {
            log.error("resolver ex", e);
        }
        return null;
    }
}

response.sendError()를 호출하지 않았기 때문에 WAS는 내부 요청을 다시 하지 않는다.
빈 ModelAndView: new ModelAndView() 처럼 빈 ModelAndView 를 반환하면 뷰를 렌더링 하지 않고, 정상 흐름으로 서블릿이 리턴된다. JSON 응답에 사용한다.
ModelAndView 지정: ModelAndView 에 View , Model 등의 정보를 지정해서 반환하면 뷰를 렌더링 한다.
null: null 을 반환하면, 다음 ExceptionResolver 를 찾아서 실행한다. 만약 처리할 수 있는 ExceptionResolver 가 없으면 예외 처리가 안되고, 기존에 발생한 예외를 서블릿 밖으로 던진다.

WebConfig에 UserHandlerExceptionResolver 추가

@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void extendHandlerExceptionResolvers(List<HandlerExceptionResolver> resolvers) {
        resolvers.add(new UserHandlerExceptionResolver());
    }
}

4) 스프링이 제공하는 ExceptionResolver

스프링 부트가 기본으로 제공하는 ExceptionResolver 는 다음과 같다.

1. ResponseStatusExceptionResolver : HTTP 응답 코드 변경

2. DefaultHandlerExceptionResolver : 스프링 내부 예외 처리

3. ExceptionHandlerExceptionResolver : @ExceptionHandler 을 처리

예외 발생시 동작 우선 순위

3 → 1 → 2

(1) ResponseStatusExceptionResolver

ResponseStatusExceptionResolver 는 예외에 따라서 HTTP 상태 코드를 지정해주는 역할을 한다.

response.sendError(statusCode, resolvedReason) 를 호출해 지정한 코드로 변경한다.

public class ResponseStatusExceptionResolver extends AbstractHandlerExceptionResolver implements MessageSourceAware {
    protected ModelAndView applyStatusAndReason(int statusCode, @Nullable String reason, HttpServletResponse response)
            throws IOException {

        if (!StringUtils.hasLength(reason)) {
            response.sendError(statusCode);
        }
        else {
            String resolvedReason = (this.messageSource != null ?
                    this.messageSource.getMessage(reason, null, reason, LocaleContextHolder.getLocale()) :
                    reason);
            response.sendError(statusCode, resolvedReason);
        }
        return new ModelAndView();
    }
}

[ @ResponseStatus ]

//@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "잘못된 요청 오류")
@ResponseStatus(code = HttpStatus.BAD_REQUEST, reason = "error.bad")
public class BadRequestException extends RuntimeException {
}

BadRequestException 예외가 컨트롤러 밖으로 넘어가면 ResponseStatusExceptionResolver 가 해당 애노테이션을 확인해서 오류 코드를 HttpStatus.BAD_REQUEST (400)으로 변경하고, 메시지도 담는다.

messages.properties

error.bad=잘못된 요청 오류입니다.

reason 을 MessageSource 에서 찾는 기능도 제공한다.

[ ResponseStatusException ]

@ResponseStatus 는 개발자가 직접 변경할 수 없는 예외에는 적용할 수 없다. (애노테이션을 직접 넣어야 하는데, 내가 코드를 수정할 수 없는 라이브러리의 예외 코드 같은 곳에는 적용할 수 없다.) 추가로 애노테이션을 사용하기 때문에 조건에 따라 동적으로 변경하는 것도 어렵다. 이때는 ResponseStatusException 예외를 사용하면 된다.

@GetMapping("/api/response-status-ex2")
public String responseStatusEx2() {
     throw new ResponseStatusException(HttpStatus.NOT_FOUND, "error.bad", new IllegalArgumentException());
}

(2) DefaultHandlerExceptionResolver

DefaultHandlerExceptionResolver 는 스프링 내부에서 발생하는 스프링 예외를 해결한다.

public class DefaultHandlerExceptionResolver extends AbstractHandlerExceptionResolver {
    protected ModelAndView doResolveException(
            HttpServletRequest request, HttpServletResponse response, @Nullable Object handler, Exception ex) {

        } else if (ex instanceof TypeMismatchException) {
            return handleTypeMismatch(
                    (TypeMismatchException) ex, request, response, handler);
        }
    }

    protected ModelAndView handleTypeMismatch(TypeMismatchException ex,
            HttpServletRequest request, HttpServletResponse response, @Nullable Object handler) throws IOException {

        response.sendError(HttpServletResponse.SC_BAD_REQUEST);
        return new ModelAndView();
    }
}

파라미터 바인딩 시점에 타입이 맞지 않으면 내부에서 TypeMismatchException 이 발생하는데, 이 경우 예외가 발생했기 때문에 그냥 두면 서블릿 컨테이너까지 오류가 올라가고, 결과적으로 500 오류가 발생한다.
그런데 파라미터 바인딩은 대부분 클라이언트가 HTTP 요청 정보를 잘못 호출해서 발생하는 문제이다. HTTP 에서는 이런 경우 HTTP 상태 코드 400을 사용하도록 되어 있다.
DefaultHandlerExceptionResolver 는 handleTypeMismatch()에서 이것을 500 오류가 아니라 HTTP 상태 코드 400 오류로 변경한다.
sendError(400) 를 호출했기 때문에 WAS에서 다시 오류 페이지( /error )를 내부 요청한다.
HTTP Header의 Accept에 따라 BasicErrorController가 응답한다.

{
  "status": 400,
  "error": "Bad Request",
  "exception": "org.springframework.web.method.annotation.MethodArgumentTypeMismatchException",
  "message": "Failed to convert value of type 'java.lang.String' to required
type 'java.lang.Integer'; nested exception is java.lang.NumberFormatException:
For input string: \"hello\"",
  "path": "/api/default-handler-ex"
}

(3) ExceptionHandlerExceptionResolver

API는 컨트롤러, 예외 등에 따라 응답에 세밀한 제어가 필요한데, @ExceptionHandler를 사용하면 편리하게 예외를 처리할 수 있다.

@ExceptionHandler을 사용하면 ExceptionHandlerExceptionResolver가 동작하고 ExceptionHandlerExceptionResolver는 기본으로 제공하는 ExceptionResolver 중에 우선순위도 가장 높다.

[ Controller ]

@RestController
public class ApiExceptionController {
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    @ExceptionHandler(IllegalArgumentException.class)
    public ErrorResult illegalExHandle(IllegalArgumentException e) {
        return new ErrorResult("BAD", e.getMessage());
    }

    @ExceptionHandler
    public ResponseEntity<ErrorResult> userExHandle(UserException e) {
        ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
        return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
    }

    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    @ExceptionHandler
    public ErrorResult exHandle(Exception e) {
        return new ErrorResult("EX", "내부 오류");
    }
}

@ExceptionHandler 애노테이션을 선언하고, 해당 컨트롤러에서 처리하고 싶은 예외를 지정해주면 된다. 해당 컨트롤러에서 예외가 발생하면 이 메서드가 호출된다. 참고로 지정한 예외 또는 그 예외의 자식 클래스는 모두 잡을 수 있다.

실행 흐름

1. 컨트롤러를 호출한 결과 IllegalArgumentException 예외가 컨트롤러 밖으로 던져진다.

2. 예외가 발생했으로 ExceptionResolver 가 작동한다. 가장 우선순위가 높은 ExceptionHandlerExceptionResolver 가 실행된다.

3. ExceptionHandlerExceptionResolver 는 해당 컨트롤러에 IllegalArgumentException 을 처리할 수 있는 @ExceptionHandler 가 있는지 확인한다.

4. illegalExHandle() 를 실행한다. @RestController 이므로 illegalExHandle() 에도 @ResponseBody 가 적용된다. 따라서 HTTP 컨버터가 사용되고, 응답이 다음과 같은 JSON으로 반환된다.

5. @ResponseStatus(HttpStatus.BAD_REQUEST) 를 지정했으므로 HTTP 상태 코드 400으로 응답한다.

다양한 예외

다양한 예외를 한번에 처리할 수 있다.

@ExceptionHandler({AException.class, BException.class})

예외 생략

@ExceptionHandler 에 예외를 생략할 수 있다. 생략하면 메서드 파라미터의 예외가 지정된다.

@ExceptionHandler
public ResponseEntity<ErrorResult> userExHandle(UserException e) {}

파리미터와 응답

@ExceptionHandler 에는 마치 스프링의 컨트롤러의 파라미터 응답처럼 다양한 파라미터와 응답을 지정할 수 있다.

스프링 공식 문서

5) @ControllerAdvice

@ExceptionHandler 를 사용해서 예외를 깔끔하게 처리할 수 있게 되었지만, 정상 코드와 예외 처리 코드가 하나의 컨트롤러에 섞여 있다. @ControllerAdvice 또는 @RestControllerAdvice 를 사용하면 둘을 분리할 수 있다.

[ @ControllerAdvice ]

Controller 코드에 있는 @ExceptionHandler 모두 제거

@RestControllerAdvice
public class ExControllerAdvice {
    @ExceptionHandler
    public ResponseEntity<ErrorResult> userExHandle(UserException e) {
        ErrorResult errorResult = new ErrorResult("USER-EX", e.getMessage());
        return new ResponseEntity<>(errorResult, HttpStatus.BAD_REQUEST);
    }
}

대상 컨트롤러 지정 방법

@ControllerAdvice 에 대상을 지정하지 않으면 모든 컨트롤러에 적용된다. 스프링 공식 문서

// Target all Controllers annotated with @RestController
@ControllerAdvice(annotations = RestController.class)
public class ExampleAdvice1 {}

// Target all Controllers within specific packages
@ControllerAdvice("org.example.controllers")
public class ExampleAdvice2 {}

// Target all Controllers assignable to specific classes
@ControllerAdvice(assignableTypes = {ControllerInterface.class, AbstractController.class})
public class ExampleAdvice3 {}

정리

@ExceptionHandler 와 @ControllerAdvice 를 조합하면 예외를 깔끔하게 해결할 수 있다.

결론

자바 예외 활용

체크 예외는 예외를 반드시 잡거나 던지도록 처리해야 하는데

복구 불가능한 예외를 잡아 처리할 수 없고 던지면 다른 계층에서의 의존관계 문제가 발생한다.

따라서, 체크 예외를 런타임 예외로 변환해 사용하고 런타임 예외가 발생할 수 있는 코드는 문서로 남겨서 중요한 예외를 인지할 수 있게 해야 한다.

그리고 예외를 변환할 때는 기존 예외를 포함해야 발생 원인을 쉽게 파악할 수 있다.

스프링 예외 추상화

스프링은 데이터 접근 계층이 데이터베이스와 에러 코드에 의존하는 문제들을 해결하기 위해 예외 변환기, sql-error-codes.xml을 사용해 데이터 접근과 관련된 예외를 추상화해서 제공한다.

서블릿 오류 처리 과정

먼저, 오류 페이지, 오류 페이지 경로 매핑(WebServerCustomizer), 오류 페이지 컨트롤러를 정의한다.

1. 예외가 발생해서 WAS까지 전파된다.

3. WAS는 오류 페이지와 함께 오류 정보를 request 의 attribute 에 추가해서 넘겨준다.

스프링 부트 오류 페이지

스프링 부트는 오류 페이지, 오류 페이지 경로 매핑(WebServerCustomizer), 오류 페이지 컨트롤러를 정의하는 과정을 자동으로 해준다.

오류 페이지 생성: ErrorMvcAutoConfiguration
오류 페이지 경로: "/error"
오류 페이지 컨트롤러: BasicErrorController

뷰 선택 우선순위를 고려해 커스텀 오류 페이지를 생성할 수 있다.

API 예외처리

HandlerExceptionResolver를 활용하면 예외 상태 코드를 변환하거나, WAS 재요청을 생략할 수 있다.

1. ResponseStatusExceptionResolver : HTTP 응답 코드 변경
2. DefaultHandlerExceptionResolver : 스프링 내부 예외 처리
3. ExceptionHandlerExceptionResolver : @ExceptionHandler 을 처리
예외 발생시 동작 우선 순위: 3 → 1 → 2

@ExceptionHandler를 활용해 예외를 깔끔하게 처리할 수 있고 @ControllerAdvice를 활용해 정상 코드와 예외 처리 코드를 분리할 수 있다.

출처

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술

[Spring] 트랜잭션

mandykr — Wed, 19 Oct 2022 12:41:06 +0900

1. 트랜잭션

2. DB 락

3. 애플리케이션 트랜잭션 적용

4. 스프링 트랜잭션

목표

데이터베이스의 트랜잭션에 대해 알아보고 스프링이 트랜잭션을 지원하기 위해 제공하는 트랜잭션 매니저와 트랜잭션 동기화 매니저에 대해 알아본다.

1. 트랜잭션

데이터를 단순히 파일에 저장하는 것이 아닌 데이터베이스에 저장하는 이유는 데이터베이스가 트랜잭션이라는 개념을 지원하기 때문이다.

트랜잭션 ACID

트랜잭션은 다음의 ACID를 보장해야 한다.

원자성(Atomicity): 트랜잭션 내에서 실행한 작업들은 마치 하나의 작업인 것처럼 모두 성공 하거나 모두 실패해야 한다.
일관성(Consistency): 모든 트랜잭션은 일관성 있는 데이터베이스 상태를 유지해야 한다. 예를 들어 데이터베이스에서 정한 무결성 제약 조건을 항상 만족해야 한다.
격리성(Isolation): 동시에 실행되는 트랜잭션들이 서로에게 영향을 미치지 않도록 격리한다. 예를 들어 동시에 같은 데이터를 수정하지 못하도록 해야 한다. 격리성은 동시성과 관련된 성능 이슈로 인해 트랜잭션 격리 수준 (Isolation level)을 선택할 수 있다.
지속성(Durability): 트랜잭션을 성공적으로 끝내면 그 결과가 항상 기록되어야 한다. 중간에 시스템에 문제가 발생해도 데이터베이스 로그 등을 사용해서 성공한 트랜잭션 내용을 복구해야 한다.

1) 데이터베이스 트랜잭션

(1) 커넥션과 세션

사용자는 클라이언트를 사용해서 데이터베이스 서버에 접근한다.
클라이언트는 데이터베이스 서버에 연결을 요청하고 커넥션을 맺게된다.
이 때, 데이터베이스 서버는 내부에 세션이라는 것을 만들고 해당 커넥션을 통한 모든 요청은 세션을 통해서 실행하게 된다.
세션은 트랜잭션을 시작하고, 커밋 또는 롤백을 통해 트랜잭션을 종료한다.
그리고 이후에 새로운 트랜잭션을 다시 시작할 수 있다.
사용자가 커넥션을 닫거나, 또는 DBA(DB 관리자)가 세션을 강제로 종료하면 세션은 종료된다.

(2) 수동 커밋

자동 커밋으로 설정하면 각각의 쿼리 실행 직후에 자동으로 커밋을 호출한다.

따라서 커밋이나 롤백을 직접 호출하지 않아도 되는 편리함이 있다.

하지만 쿼리를 하나하나 실행할 때 마다 자동으로 커밋이 되어버리기 때문에 우리가 원하는 트랜잭션 기능을 제대로 사용할 수 없다.

set autocommit false; //자동 커밋 모드 설정

보통 자동 커밋 모드가 기본으로 설정된 경우가 많기 때문에, 수동 커밋 모드로 설정하는 것을 트랜잭션을 시작한다고 표현할 수 있다. 수동 커밋 설정을 하면 이후에 꼭 commit , rollback 을 호출해야 한다.

(3) 트랜잭션

memberA 의 돈을 memberB 에게 2000원 계좌이체하는 트랜잭션을 실행한다.

set autocommit false;
insert into member(member_id, money) values ('memberA',10000);
insert into member(member_id, money) values ('memberB',10000);

데이터 수정

세션1에서 데이터를 변경하면 세션1에서는 임시 상태로 데이터가 변경된다.
세션1이 커밋하기 전에는 변경된 데이터를 세션1에서는 조회할 수 있지만 세션2에서는 기존 데이터가 조회된다.

커밋 - commit

세션1이 트랜잭션을 커밋했기 때문에 데이터베이스에 데이터 변경이 반영된다.
커밋 이후에는 모든 세션에서 변경된 데이터를 조회할 수 있다.

롤백 - rollback

계좌이체를 실행하는 도중에 두 번째 update 쿼리에서 SQL 오류가 발생한다.
그래서 memberA 의 돈을 2000원 줄이는 것에는 성공했지만, memberB 의 돈을 2000원 증가시키는 것에 실패한다.
이럴 때는 롤백을 호출해서 트랜잭션을 시작하기 전 단계로 데이터를 복구해야 한다.

세션1이 트랜잭션을 롤백했기 때문에 임시 상태의 데이터가 DB에 반영되지 않고 트랜잭션을 시작하기 전 상태로 돌아왔다.

2. DB 락

세션1이 트랜잭션을 시작하고 데이터를 수정하는 동안 아직 커밋을 수행하지 않았는데, 세션2에서 동시에 같은 데이터를 수정하게 되면 여러가지 문제가 발생한다. 바로 트랜잭션의 원자성이 깨지는 것이다.

여기에 더해서 세션1이 중간에 롤백을 하게 되면 세션2는 잘못된 데이터를 수정하는 문제가 발생한다.

데이터베이스는 락을 통해 원자성을 보장한다.

1) DB 락 - 변경

1. 세션1은 트랜잭션을 시작한다.
2. 세션1은 memberA 의 money 를 500으로 변경을 시도한다. 이때 해당 로우의 락을 먼저 획득해야 한다. 락이 남아 있으므로 세션1은 락을 획득한다. (세션1이 세션2보다 조금 더 빨리 요청했다.)
3. 세션1은 락을 획득했으므로 해당 로우에 update sql을 수행한다.
4. 세션2는 트랜잭션을 시작한다.
5. 세션2도 memberA 의 money 데이터를 변경하려고 시도한다. 이때 해당 로우의 락을 먼저 획득해야 한다. 락이 없으므로 락이 돌아올 때 까지 대기한다. 참고로 세션2가 락을 무한정 대기하는 것은 아니다. 락 대기 시간을 넘어가면 락 타임아웃 오류가 발생한다. 락 대기 시간은 설정할 수 있다.

SET LOCK_TIMEOUT 60000; // 락 획득 시간을 60초로 설정한다.

// 락 대기 시간동안 락을 얻지 못하면 타임아웃 오류가 발생한다.
Timeout trying to lock table {0}; SQL statement:
update member set money=10000 - 2000 where member_id = 'memberA' [50200-200]
HYT00/50200

6. 세션1은 커밋을 수행한다. 커밋으로 트랜잭션이 종료되었으므로 락도 반납한다.

락을 획득하기 위해 대기하던 세션2가 락을 획득한다.

7. 세션2는 update sql을 수행한다.
8. 세션2는 커밋을 수행하고 트랜잭션이 종료되었으므로 락을 반납한다.

2) DB 락 - 조회

데이터베이스마다 다르지만, 보통 데이터를 조회할 때는 락을 획득하지 않고 바로 데이터를 조회할 수 있다.

예를 들어서 세션1이 락을 획득하고 데이터를 변경하고 있어도, 세션2에서 데이터를 조회는 할 수 있다.

데이터를 조회할 때도 락을 획득하고 싶을 때가 있다. 이럴 때는 select for update 구문을 사용하면 된다.
이렇게 하면 세션1이 조회 시점에 락을 가져가버리기 때문에 다른 세션에서 해당 데이터를 변경할 수 없다.
물론 이 경우도 트랜잭션을 커밋하면 락을 반납한다.

set autocommit false;
select * from member where member_id='memberA' for update;

트랜잭션 종료 시점까지 해당 데이터를 다른 곳에서 변경하지 못하도록 강제로 막아야 할 때 사용한다.

예를 들어서 애플리케이션 로직에서 memberA 의 금액을 조회한 다음에 이 금액 정보로 애플리케이션에서 어떤 계산을 수행한다. 그런데 매우 중요한 계산이어서 계산을 완료할 때 까지 memberA 의 금액을 다른곳에서 변경하면 안된다. 이럴 때 조회 시점에 락을 획득하면 된다.

3. 애플리케이션 트랜잭션 적용

실제 애플리케이션에서 DB 트랜잭션을 사용해서 계좌이체 같이 중요한 비즈니스 로직에서 원자성을 보장하도록 구현한다. 애플리케이션에서 트랜잭션을 구현하기 위해서는 구현 계층과 커넥션 동기화를 고려해야 한다.

1) 비즈니스 로직과 트랜잭션

트랜잭션은 비즈니스 로직이 있는 서비스 계층에서 시작해야 한다.

비즈니스 로직이 잘못되면 해당 비즈니스 로직으로 인해 문제가 되는 부분을 함께 롤백해야 하기 때문이다.

그런데 트랜잭션을 시작하려면 커넥션이 필요하다. 결국 서비스 계층에서 커넥션을 만들고, 트랜잭션 커밋 이후에 커넥션을 종료해야 한다.

2) 커넥션과 세션

DB 트랜잭션을 사용하려면 같은 세션을 사용해야 하기 때문에 애플리케이션에서는 같은 커넥션을 유지해야 한다.

3) 적용

스프링에서 제공하는 트랜잭션 기술을 사용하지 않고 트랜잭션을 구현해 발생하는 문제점을 확인한다.

데이터 접근 기술은 JDBC를 활용한다.

JDBC를 사용할 때 발생하는 SQLException은 RuntimeException으로 변환해 처리한다.

[ 리포지토리 ]

public class MemberRepository {
    private final DataSource dataSource;
    
    // ... 생략

    public Member findById(Connection con, String memberId) {
        String sql = "select * from member where member_id = ?";
        PreparedStatement pstmt = null;
        ResultSet rs = null;
        try {
            pstmt = con.prepareStatement(sql);
            pstmt.setString(1, memberId);
            rs = pstmt.executeQuery();
            if (rs.next()) {
                Member member = new Member();
                member.setMemberId(rs.getString("member_id"));
                member.setMoney(rs.getInt("money"));
                return member;
            } else {
                throw new NoSuchElementException("member not found memberId=" + memberId);
            }
        } catch (SQLException e) {
            log.error("db error", e);
            throw new RuntimeException(e);
        } finally {
            //connection은 여기서 닫지 않는다.
            JdbcUtils.closeResultSet(rs);
            JdbcUtils.closeStatement(pstmt);
        }
    }

    public void update(Connection con, String memberId, int money) {
        String sql = "update member set money=? where member_id=?";
        PreparedStatement pstmt = null;
        try {
            pstmt = con.prepareStatement(sql);
            pstmt.setInt(1, money);
            pstmt.setString(2, memberId);
            pstmt.executeUpdate();
        } catch (SQLException e) {
            log.error("db error", e);
            throw new RuntimeException(e);
        } finally {
            //connection은 여기서 닫지 않는다.
            JdbcUtils.closeStatement(pstmt);
        }
    }
}

계좌이체 트랜잭션에서 호출하는 MemberRepository 의 findyById(), update() 메소드는 커넥션을 유지하기 위해 Connection 을 파리미터로 받는다.
커넥션 유지가 필요하기 때문에 리포지토리에서 커넥션을 닫지 않고 이후 서비스 로직이 끝날 때 트랜잭션을 종료하고 닫아야 한다.

[ 서비스 ]

public class MemberService {
    private final DataSource dataSource;
    private final MemberRepository memberRepository;

    public void accountTransfer(String fromId, String toId, int money) {
        Connection con = dataSource.getConnection();
        try {
            con.setAutoCommit(false); //트랜잭션 시작
            //비즈니스 로직
            bizLogic(con, fromId, toId, money);
            con.commit(); //성공시 커밋
        } catch (Exception e) {
            con.rollback(); //실패시 롤백
            throw new IllegalStateException(e);
        } finally {
            release(con);
        }
    }

    private void bizLogic(Connection con, String fromId, String toId, int money) {
        Member fromMember = memberRepository.findById(con, fromId);
        Member toMember = memberRepository.findById(con, toId);
        memberRepository.update(con, fromId, fromMember.getMoney() - money);
        validation(toMember);
        memberRepository.update(con, toId, toMember.getMoney() + money);
    }
    
    private void release(Connection con) {
        if (con != null) {
            try {
                con.setAutoCommit(true); //커넥션 풀 고려
                con.close();
            } catch (Exception e) {
                log.info("error", e);
            }
        }
    }
}

Connection con = dataSource.getConnection();
- 트랜잭션을 시작하려면 커넥션이 필요하다.
con.setAutoCommit(false); //트랜잭션 시작
- 트랜잭션을 시작하려면 자동 커밋 모드를 꺼야한다. 이렇게 하면 커넥션을 통해 세션에 set autocommit false 가 전달되고, 이후부터는 수동 커밋 모드로 동작한다. 이렇게 자동 커밋 모드를 수동 커밋 모드로 변경하는 것을 트랜잭션을 시작한다고 보통 표현한다.
bizLogic(con, fromId, toId, money);
- 트랜잭션이 시작된 커넥션을 전달하면서 비즈니스 로직을 수행한다.
- 이렇게 분리한 이유는 트랜잭션을 관리하는 로직과 실제 비즈니스 로직을 구분하기 위함이다.
- memberRepository.update(con..) : 비즈니스 로직을 보면 리포지토리를 호출할 때 커넥션을 전달하는 것을 확인할 수 있다.
con.commit(); //성공시 커밋
- 비즈니스 로직이 정상 수행되면 트랜잭션을 커밋한다.
con.rollback(); //실패시 롤백
- catch(Ex){..} 를 사용해서 비즈니스 로직 수행 도중에 예외가 발생하면 트랜잭션을 롤백한다.
release(con);
- finally {..} 를 사용해서 커넥션을 모두 사용하고 나면 안전하게 종료한다. 그런데 커넥션 풀을 사용하면 con.close() 를 호출 했을 때 커넥션이 종료되는 것이 아니라 풀에 반납된다. 현재 수동 커밋 모드로 동작하기 때문에 풀에 돌려주기 전에 기본 값인 자동 커밋 모드로 변경하는 것이 안전하다.

4) 문제점

(1) 서비스 계층이 특정 기술에 종속되는 문제

구현 기술을 변경해도 비즈니스 로직을 갖는 서비스 계층 코드는 최대한 유지할 수 있어야 한다.
하지만 트랜잭션을 적용하기 위해 JDBC 구현 기술이 서비스 계층에 누수되었다.
dataSource.getConnection();

(2) 트랜잭션 동기화 문제

같은 트랜잭션을 유지하기 위해 커넥션을 파라미터로 넘겨야 한다.
또한 커넥션을 유지하는 기능과 아닌 기능을 별도로 구현해야 한다.
memberRepository.findById(con, fromId);
memberRepository.findById(fromId);

(3) 트랜잭션 적용 반복 문제

트랜잭션 적용 코드를 보면 반복이 많다. try , catch , finally ...

4. 스프링 트랜잭션

스프링은 위의 문제들을 다음과 같은 방법으로 해결한다.

트랜잭션 동기화

트랜잭션 추상화
- PlatformTransactionManager 인터페이스로 트랜잭션 추상화
- 서비스 계층이 특정 기술에 종속되는 문제 해결
리소스 동기화
- TransactionSynchronizationManager 클래스의 쓰레드 로컬 사용
- 트랜잭션 동기화 문제 해결

트랜잭션 템플릿

TransactionTemplate 클래스로 템플릿 콜백 패턴 적용
트랜잭션 적용 반복 문제 해결

트랜잭션 AOP

@Transactional을 사용해 트랜잭션 프록시 적용
PlatformTransactionManager, TransactionSynchronizationManager 를 사용해 트랜잭션 동기화
트랜잭션 적용 반복 문제 해결
서비스 계층에 트랜잭션 처리 로직이 함께 섞여있는 문제 해결

1) 트랜잭션 동기화

(1) 트랜잭션 추상화

스프링은 트랜잭션 기술들을 PlatformTransactionManager(트랜잭션 매니저)로 추상화해 서비스 계층이 특정 기술에 종속되는 문제를 해결한다.

서비스가 특정 트랜잭션 기술이 아닌 PlatformTransactionManager에 의존하고 환경에 따라 원하는 구현체를 DI를 통해 주입하면 된다.

JDBC 사용: DataSourceTransactionManager 를 확장한 JdbcTransactionManager
JPA: JpaTransactionManager

PlatformTransactionManager

package org.springframework.transaction;

public interface PlatformTransactionManager extends TransactionManager {
    TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransactionException;
    void commit(TransactionStatus status) throws TransactionException;
    void rollback(TransactionStatus status) throws TransactionException;
}

(2) 리소스 동기화

PlatformTransactionManager는 트랜잭션 동기화와 함께 리소스 동기화 기능을 제공한다.

PlatformTransactionManager는 TransactionSynchronizationManager(트랜잭션 동기화 매니저)를 사용해 데이터베이스 커넥션을 유지하도록 한다.

TransactionSynchronizationManager는 ThreadLocal을 사용해서 커넥션을 동기화하기 때문에 멀티쓰레드 상황에 안전하게 커넥션을 동기화 할 수 있다.

따라서 커넥션이 필요하면 트랜잭션 동기화 매니저를 통해 커넥션을 획득하면 된다.

TransactionSynchronizationManager

package org.springframework.transaction.support;

public abstract class TransactionSynchronizationManager {

	private static final ThreadLocal<Map<Object, Object>> resources =
			new NamedThreadLocal<>("Transactional resources");
}

(3) 트랜잭션 매니저 동작 방식

트랜잭션 시작

1. 서비스 계층에서 transactionManager.getTransaction() 을 호출해서 트랜잭션을 시작한다.

2. 트랜잭션을 시작하려면 먼저 데이터베이스 커넥션이 필요하다. 트랜잭션 매니저는 내부에서 데이터소스를 사용해서 커넥션을 생성한다.

3. 커넥션을 수동 커밋 모드로 변경해서 실제 데이터베이스 트랜잭션을 시작한다.

4. 커넥션을 트랜잭션 동기화 매니저에 보관한다.

5. 트랜잭션 동기화 매니저는 쓰레드 로컬에 커넥션을 보관한다. 따라서 멀티 쓰레드 환경에 안전하게 커넥션을 보관할 수 있다.

로직 실행

6. 서비스는 비즈니스 로직을 실행하면서 리포지토리의 메서드들을 호출한다. 이때 커넥션을 파라미터로 전달하지 않는다.

7. 리포지토리 메서드들은 트랜잭션이 시작된 커넥션이 필요하다. 리포지토리는 DataSourceUtils.getConnection() 을 사용해서 트랜잭션 동기화 매니저에 보관된 커넥션을 꺼내서 사용한다. 이 과정을 통해서 자연스럽게 같은 커넥션을 사용하고, 트랜잭션도 유지된다.

8. 획득한 커넥션을 사용해서 SQL을 데이터베이스에 전달해서 실행한다.

트랜잭션 종료

9. 비즈니스 로직이 끝나고 트랜잭션을 종료한다. 트랜잭션은 커밋하거나 롤백하면 종료된다.

10. 트랜잭션을 종료하려면 동기화된 커넥션이 필요하다. 트랜잭션 동기화 매니저를 통해 동기화된 커넥션을 획득한다.

11. 획득한 커넥션을 통해 데이터베이스에 트랜잭션을 커밋하거나 롤백한다.

12. 전체 리소스를 정리한다.

트랜잭션 동기화 매니저를 정리한다. 쓰레드 로컬은 사용후 꼭 정리해야 한다.
con.setAutoCommit(true) 로 되돌린다. 커넥션 풀을 고려해야 한다.
con.close() 를 호출해셔 커넥션을 종료한다. 커넥션 풀을 사용하는 경우 con.close() 를 호출하면 커넥션 풀에 반환된다.

(4) 트랜잭션 동기화 적용

PlatformTransactionManager, TransactionSynchronizationManager로 트랜잭션 추상화와 리소스 동기화를 적용한다.

[ 서비스 ]

public class MemberService {
    private final PlatformTransactionManager transactionManager;
    private final MemberRepository memberRepository;

    public void accountTransfer(String fromId, String toId, int money) {
        //트랜잭션 시작
        TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());        
        try {
            //비즈니스 로직
            bizLogic(fromId, toId, money);
            transactionManager.commit(status); //성공시 커밋
        } catch (Exception e) {
            transactionManager.rollback(status); //실패시 롤백
            throw new IllegalStateException(e);
        }
    }    
}

TransactionManager transactionManager

트랜잭션 매니저를 주입 받는다. 지금은 JDBC 기술을 사용하기 때문에 DataSourceTransactionManager 구현체를 주입 받아야 한다.

transactionManager.getTransaction()

트랜잭션을 시작한다. 기존에 이미 진행중인 트랜잭션이 있는 경우 해당 트랜잭션에 참여한다.

[ 테스트 ]

// memberService 생성
DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
PlatformTransactionManager transactionManager = new DataSourceTransactionManager(dataSource);
MemberService memberService = new MemberService(transactionManager, memberRepository);

// ... 테스트

new DataSourceTransactionManager(dataSource)

dataSource로 트랜잭션 매니저를 생성한다.

[ 리포지토리 ]

public class MemberRepository {
    private final DataSource dataSource;

    public Member findById(String memberId) {
        String sql = "select * from member where member_id = ?";
        Connection con = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;
        try {
            con = getConnection();
            pstmt = con.prepareStatement(sql);
            pstmt.setString(1, memberId);
            rs = pstmt.executeQuery();
            if (rs.next()) {
                Member member = new Member();
                member.setMemberId(rs.getString("member_id"));
                member.setMoney(rs.getInt("money"));
                return member;
            } else {
                throw new NoSuchElementException("member not found memberId=" + memberId);
            }
        } catch (SQLException e) {
            log.error("db error", e);
            throw new RuntimeException(e);
        } finally {
            close(con, pstmt, rs);
        }
    }

    private Connection getConnection() {
        //주의! 트랜잭션 동기화를 사용하려면 DataSourceUtils를 사용해야 한다.
        Connection con = DataSourceUtils.getConnection(dataSource);
        log.info("get connection={} class={}", con, con.getClass());
        return con;
    }
    
    private void close(Connection con, Statement stmt, ResultSet rs) {
        JdbcUtils.closeResultSet(rs);
        JdbcUtils.closeStatement(stmt);
        //주의! 트랜잭션 동기화를 사용하려면 DataSourceUtils를 사용해야 한다.
        DataSourceUtils.releaseConnection(con, dataSource);
    }
}

DataSourceUtils.getConnection()

트랜잭션 동기화 매니저가 관리하는 커넥션이 있으면 해당 커넥션을 반환한다.
트랜잭션 동기화 매니저가 관리하는 커넥션이 없는 경우 새로운 커넥션을 생성해서 반환한다.

DataSourceUtils.releaseConnection()

- 트랜잭션을 사용하기 위해 동기화된 커넥션은 커넥션을 닫지 않고 그대로 유지해준다.
- 트랜잭션 동기화 매니저가 관리하는 커넥션이 없는 경우 해당 커넥션을 닫는다.
- close() 에서 커넥션을 con.close() 를 사용해서 직접 닫아버리면 커넥션이 유지되지 않는 문제가 발생한다. 이 커넥션은 이후 로직은 물론이고, 트랜잭션을 종료(커밋, 롤백)할 때 까지 살아있어야 한다.

3) 트랜잭션 템플릿

TransactionTemplate을 사용하여 트랜잭션 적용에 사용되는 반복 코드를 제거한다.

반복코드: 트랜잭션을 시작하고, 비즈니스 로직을 실행하고, 성공하면 커밋하고, 예외가 발생해서 실패하면 롤백

//트랜잭션 시작
TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());
try {
    //비즈니스 로직
    bizLogic(fromId, toId, money);
    transactionManager.commit(status); //성공시 커밋
} catch (Exception e) {
    transactionManager.rollback(status); //실패시 롤백
    throw new IllegalStateException(e);
}

(1) TransactionTemplate

public class TransactionTemplate {
    private PlatformTransactionManager transactionManager;
    public <T> T execute(TransactionCallback<T> action){..}
    void executeWithoutResult(Consumer<TransactionStatus> action){..}
}

execute() : 응답 값이 있을 때 사용한다.
executeWithoutResult() : 응답 값이 없을 때 사용한다.

(2) 적용

TransactionTemplate과 템플릿 콜백 패턴을 적용해 트랜잭션 적용 반복 코드를 제거한다.

[ 서비스 ]

public class MemberService {
    private final TransactionTemplate txTemplate;
    private final MemberRepository memberRepository;

    public MemberService(PlatformTransactionManager transactionManager, MemberRepositoryV3 memberRepository) {
        this.txTemplate = new TransactionTemplate(transactionManager);
        this.memberRepository = memberRepository;
    }

    public void accountTransfer(String fromId, String toId, int money) {
        txTemplate.executeWithoutResult(status -> bizLogic(fromId, toId, money));
    }
}

TransactionTemplate 을 사용하려면 transactionManager 가 필요하다.
생성자에서 transactionManager 를 주입 받으면서 TransactionTemplate 을 생성했다.
트랜잭션 템플릿의 기본 동작
- 비즈니스 로직이 정상 수행되면 커밋한다.
- 언체크 예외가 발생하면 롤백한다. 그 외의 경우 커밋한다.

(3) 남은 문제점

트랜잭션 템플릿 덕분에, 트랜잭션을 사용할 때 반복하는 코드를 제거했지만

핵심 기능인 비즈니스 로직과 부가 기능인 트랜잭션을 처리하는 로직이 한 곳에 있어 두 관심사를 하나의 클래스에서 처리하고 있다.

결과적으로 코드를 유지보수 하기 어려워진다.

따라서 서비스 계층에 트랜잭션 처리 기능을 없애고 순수한 비즈니스 로직만 남도록 구성해야 한다.

참고로 JDBC의 반복 문제는 JdbcTemplat을 사용해 해결한다.

4) 트랜잭션 AOP

@Transactional을 사용해 스프링 AOP와 프록시를 적용한다.

스프링 AOP와 프록시를 통해 트랜잭션 동기화 트랜잭션 처리 기능이 서비스 계층에 남아있는 문제를 해결한다.

(1) 트랜잭션 AOP 적용 흐름

서비스 로직에 @Transactional을 사용하면 스프링은 프록시를 만들어

트랜잭션을 처리하는 객체와 비즈니스 로직을 처리하는 서비스 객체를 명확하게 분리할 수 있도록 한다.

1. 클라이언트는 서비스 객체가 아닌 프록시를 호출하고
2. 프록시는 스프링 컨테이너를 통해 트랜잭션 매니저를 획득한다.
3. 프록시가 transactionManager.getTransaction() 을 호출해서 트랜잭션을 시작한다.
4. 트랜잭션 매니저는 내부에서 데이터소스를 사용해서 커넥션을 생성한다.
5. 커넥션을 수동 커밋 모드로 변경해서 실제 데이터베이스 트랜잭션을 시작한다.
6. 커넥션을 트랜잭션 동기화 매니저에 보관한다.
7. 트랜잭션 동기화 매니저는 쓰레드 로컬에 커넥션을 보관한다. 따라서 멀티 쓰레드 환경에 안전하게 커넥션을 보관할 수 있다.
8. 프록시가 실제 서비스를 호출하고 서비스는 비즈니스 로직을 실행하면서 리포지토리의 메서드들을 호출한다.
9. 리포지토리 메서드들은 트랜잭션이 시작된 커넥션이 필요하다. 리포지토리는 DataSourceUtils.getConnection() 을 사용해서 트랜잭션 동기화 매니저에 보관된 커넥션을 꺼내서 사용한다. 이 과정을 통해서 자연스럽게 같은 커넥션을 사용하고, 트랜잭션도 유지된다.
획득한 커넥션을 사용해서 SQL을 데이터베이스에 전달해서 실행한다.

(2) 트랜잭션 프록시 코드 예시

public class TransactionProxy {
    private MemberService target;
    
    public void logic() {
        //트랜잭션 시작
        TransactionStatus status = transactionManager.getTransaction(..);
        try {
            //실제 대상 호출
            target.logic();
            transactionManager.commit(status); //성공시 커밋
        } catch (Exception e) {
            transactionManager.rollback(status); //실패시 롤백
            throw new IllegalStateException(e);
        }
    }
}

(3) 적용

[ 서비스 ]

@RequiredArgsConstructor
public class MemberService {
    private final MemberRepository memberRepository;

    @Transactional
    public void accountTransfer(String fromId, String toId, int money) {
        bizLogic(fromId, toId, money);
    }
}

[ 테스트 ]

@Slf4j
@SpringBootTest
class MemberServiceTest {
    @Autowired
    MemberRepository memberRepository;

    @Autowired
    MemberService memberService;

    @TestConfiguration
    static class TestConfig {
        @Bean
        DataSource dataSource() {
            return new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        }

        @Bean
        PlatformTransactionManager transactionManager() {
            return new DataSourceTransactionManager(dataSource());
        }

        @Bean
        MemberRepository memberRepository() {
            return new MemberRepository(dataSource());
        }

        @Bean
        MemberService memberService() {
            return new MemberService(memberRepository());
        }
    }

    @Test
    void AopCheck() {
        log.info("memberService class={}", memberService.getClass());
        log.info("memberRepository class={}", memberRepository.getClass());
        Assertions.assertThat(AopUtils.isAopProxy(memberService)).isTrue();
        Assertions.assertThat(AopUtils.isAopProxy(memberRepository)).isFalse();
    }
}

@SpringBootTest : 스프링 AOP를 적용하려면 스프링 컨테이너가 필요하다.
이 애노테이션이 있으면 테스트시 스프링 부트를 통해 스프링 컨테이너를 생성한다.
그리고 테스트에서 @Autowired 등을 통해 스프링 컨테이너가 관리하는 빈들을 사용할 수 있다.
@TestConfiguration : 테스트 안에서 내부 설정 클래스를 만들어서 사용하면서 이 에노테이션을 붙이면,
스프링 부트가 자동으로 만들어주는 빈들에 추가로 필요한 스프링 빈들을 등록하고 테스트를 수행할 수있다.
TestConfig
- DataSource 스프링에서 기본으로 사용할 데이터소스를 스프링 빈으로 등록한다.
  추가로 트랜잭션 매니저에서도 사용한다.
- DataSourceTransactionManager 트랜잭션 매니저를 스프링 빈으로 등록한다.
  스프링이 제공하는 트랜잭션 AOP는 스프링 빈에 등록된 트랜잭션 매니저를 찾아서 사용하기 때문에 트랜잭션 매니저를 스프링 빈으로 등록해두어야 한다
AopCheck() : memberServic는 프록시가 스프링 빈으로 등록되었다.
실행 결과
memberService class=class hello.jdbc.service.MemberService$ $EnhancerBySpringCGLIB$$...
memberRepository class=class hello.jdbc.repository.MemberRepositoryV3

(4) 스프링 부트의 자동 리소스 등록

스프링 부트는 다음과 같이 application.properties 에 있는 속성을 사용해서 DataSource 를 생성하고 스프링 빈으로 등록한다.

[ application.properties ]

spring.datasource.url=jdbc:h2:tcp://localhost/~/test
spring.datasource.username=sa
spring.datasource.password=

스프링 부트가 기본으로 생성하는 데이터소스는 커넥션풀을 제공하는 HikariDataSource 이다.
커넥션풀과 관련된 설정도 application.properties 를 통해서 지정할 수 있다
spring.datasource.url 속성이 없으면 내장 데이터베이스(메모리 DB)를 생성하려고 시도한다.

[ 트랜잭션 매니저 ]

스프링 부트는 적절한 트랜잭션 매니저( PlatformTransactionManager )를 자동으로 스프링 빈에 등록한다.
자동으로 등록되는 스프링 빈 이름: transactionManager
개발자가 직접 트랜잭션 매니저를 빈으로 등록하면 스프링 부트는 트랜잭션 매니저를 자동으로 등록하지 않는다.
어떤 트랜잭션 매니저를 선택할지는 현재 등록된 라이브러리를 보고 판단하는데, JDBC를 기술을 사용하면
DataSourceTransactionManager 를 빈으로 등록하고, JPA를 사용하면 JpaTransactionManager 를 빈으로 등록한다.
- 둘다 사용하는 경우 JpaTransactionManager 를 등록한다.
  JpaTransactionManager 는 DataSourceTransactionManager 가 제공하는 기능도 대부분 지원한다.

[ 테스트 ]

@Slf4j
@SpringBootTest
class MemberServiceTest {
    @Autowired
    MemberRepository memberRepository;

    @Autowired
    MemberService memberService;

    @TestConfiguration
    static class TestConfig {
        private final DataSource dataSource;

        public TestConfig(DataSource dataSource) {
            this.dataSource = dataSource;
        }

        @Bean
        MemberRepository memberRepository() {
            return new MemberRepository(dataSource);
        }

        @Bean
        MemberService memberService() {
            return new MemberService(memberRepository());
        }
    }

스프링 부트가 application.properties 에 지정된 속성을 참고해서 데이터소스와 트랜잭션 매니저를 자동으로 생성해준다.
memberService와 memberRepository는 충돌이 없는 경우 수동으로 등록하지 않고
@Service, @Repository를 사용해 스프링 빈으로 등록할 수 있다.

정리

@Transactional을 사용해 트랜잭션 프록시 적용
- PlatformTransactionManager, TransactionSynchronizationManager 를 사용해 트랜잭션 동기화
- 트랜잭션 적용 반복 문제 해결
- 서비스 계층에 트랜잭션 처리 로직이 함께 섞여있는 문제 해결
스프링 부트의 자동 리소스 등록
- application.properties 에 있는 속성을 사용해서 DataSource 를 생성하고 스프링 빈으로 등록

결론

데이터베이스 트랜잭션

데이터베이스 트랜잭션은 ACID를 보장해야 한다.

데이터베이스는 락을 통해 원자성을 보장한다.

트랜잭션 종료 시점까지 조회한 데이터를 다른 곳에서 변경하지 못하도록 강제로 막아야 할 때는 조회 락을 사용할 수 있다.

애플리케이션 트랜잭션

애플리케이션에서 DB 트랜잭션을 사용하려면 같은 세션을 사용해야 하기 때문에 애플리케이션에서는 같은 커넥션을 유지해야 한다. (커넥션 동기화를 고려해야 한다.)

스프링 트랜잭션

트랜잭션 추상화

스프링은 트랜잭션 기술들을 PlatformTransactionManager(트랜잭션 매니저)로 추상화해 서비스 계층이 특정 기술에 종속되는 문제를 해결한다.

트랜잭션 동기화

PlatformTransactionManager는 TransactionSynchronizationManager(트랜잭션 동기화 매니저)를 사용해 데이터베이스 커넥션을 유지하도록 한다.

TransactionSynchronizationManager는 ThreadLocal을 사용해서 커넥션을 동기화하기 때문에 멀티쓰레드 상황에 안전하게 커넥션을 동기화 할 수 있다.

트랜잭션 AOP

서비스 로직에 @Transactional을 사용하면 스프링은 프록시를 만들어 트랜잭션을 처리하는 객체와 비즈니스 로직을 처리하는 서비스 객체를 명확하게 분리할 수 있도록 한다.

프록시는 PlatformTransactionManager를 사용하기 때문에 트랜잭션 추상하와 트랜잭션 동기화를 함께 제공한다.

스프링 부트의 자동 리소스 등록

스프링 부트는 다음과 같이 application.properties 에 있는 속성을 사용해서 DataSource 를 생성하고 스프링 빈으로 등록한다. 등록한 빈을 PlatformTransactionManager 의 구현체로 사용한다.

출처

스프링 DB 1편 - 데이터 접근 핵심 원리(김영한)

[HTTP] 6. HTTP 헤더(캐시와 조건부 요청)

mandykr — Wed, 8 Jun 2022 12:38:22 +0900

1. 캐시 기본 동작

2. 검증 헤더와 조건부 요청

3. 캐시와 조건부 요청 헤더

4. 캐시와 조건부 요청 헤더

5. 프록시 캐시

6. 캐시 무효화

1. 캐시 기본 동작

1) 캐시가 없을 때

데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.
인터넷 네트워크는 매우 느리고 비싸다.
브라우저 로딩 속도가 느리다.
느린 사용자 경험

2) 캐시 적용

캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.
비싼 네트워크 사용량을 줄일 수 있다.
브라우저 로딩 속도가 매우 빠르다.
빠른 사용자 경험

[ 첫 번째 요청 ]

chche-control

[ 두 번째 요청 - 캐시 사용 ]

[ 세 번째 요청 - 캐시 시간 초과 ]

캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고, 캐시를 갱신한다.
이때 다시 네트워크 다운로드가 발생한다.

2. 검증 헤더와 조건부 요청

1. 검증 헤더

캐시 데이터와 서버 데이터가 같은지 검증하는 데이터
Last-Modified , ETag

2. 조건부 요청 헤더

검증 헤더로 조건에 따른 분기
If-Modified-Since: Last-Modified 사용
If-None-Match: ETag 사용
조건이 만족하면 200 OK
조건이 만족하지 않으면 304 Not Modified

1) Last-Modified, If-Modified-Since

1. 데이터 미변경 예시

캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 10:00:00
304 Not Modified, 헤더 데이터만 전송(BODY 미포함)
전송 용량 0.1M (헤더 0.1M, 바디 1.0M)

2. 데이터 변경 예시

캐시: 2020년 11월 10일 10:00:00 vs 서버: 2020년 11월 10일 11:00:00
200 OK, 모든 데이터 전송(BODY 포함)
전송 용량 1.1M (헤더 0.1M, 바디 1.0M)

[ 첫 번째 요청 - 검증 헤더 추가 ]

Last-Modified

[ 두 번째 요청 - 캐시 시간 초과, 조건부 요청 ]

if-modified-since

304 Not Modified

Last-Modified, If-Modified-Since 단점

1초 미만(0.x초) 단위로 캐시 조정이 불가능
날짜 기반의 로직 사용
사용이 적절하지 않은 경우
- 데이터를 수정해서 날짜가 다르지만, 같은 데이터를 수정해서 데이터 결과가 똑같은 경우
- 서버에서 별도의 캐시 로직을 관리하고 싶은 경우
  예) 스페이스나 주석처럼 크게 영향이 없는 변경에서 캐시를 유지하고 싶은 경우

2) ETag, If-None-Match

ETag(Entity Tag)
캐시용 데이터에 임의의 고유한 버전 이름을 달아둠
예) ETag: "v1.0", ETag: "a2jiodwjekjl3"
데이터가 변경되면 이 이름을 바꾸어서 변경함(Hash를 다시 생성)
예) ETag: "aaaaa" -> ETag: "bbbbb"
진짜 단순하게 ETag만 보내서 같으면 유지, 다르면 다시 받기!
캐시 제어 로직을 서버에서 완전히 관리
클라이언트는 단순히 이 값을 서버에 제공(클라이언트는 캐시 메커니즘을 모름)
예)
- 서버는 배타 오픈 기간인 3일 동안 파일이 변경되어도 ETag를 동일하게 유지
- 애플리케이션 배포 주기에 맞추어 ETag 모두 갱신

[ 첫 번째 요청 - 검증 헤더 추가 ]

ETag

[ 두 번째 요청 - 캐시 시간 초과, 조건부 요청 ]

if-None-Match

304 Not Modified

4. 캐시와 조건부 요청 헤더

1) 캐시 제어 헤더

Cache-Control: 캐시 제어
Pragma: 캐시 제어(하위 호환)
Expires: 캐시 유효 기간(하위 호환)

[ Cache-Control: 캐시 지시어(directives) ]

1. Cache-Control: max-age

캐시 유효 시간, 초 단위

2. Cache-Control: no-cache

데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용

3. Cache-Control: no-store

데이터에 민감한 정보가 있으므로 저장하면 안됨
(메모리에서 사용하고 최대한 빨리 삭제)

[ Pragma: 캐시 제어(하위 호환) ]

Pragma: no-cache
HTTP 1.0 하위 호환

[ Expires: 캐시 만료일 지정(하위 호환) ]

expires: Mon, 01 Jan 1990 00:00:00 GMT
캐시 만료일을 정확한 날짜로 지정
HTTP 1.0 부터 사용
지금은 더 유연한 Cache-Control: max-age 권장
Cache-Control: max-age와 함께 사용하면 Expires는 무시

2) 검증 헤더와 조건부 요청 헤더

1. 검증 헤더 (Validator)

ETag: "v1.0", ETag: "asid93jkrh2l"
Last-Modified: Thu, 04 Jun 2020 07:19:24 GMT

2. 조건부 요청 헤더

If-Match, If-None-Match: ETag 값 사용
If-Modified-Since, If-Unmodified-Since: Last-Modified 값 사용

5. 프록시 캐시

글로벌 서비스에 요청할 때 프록시 캐시 서버를 통해 빠른 응답을 받을 수 있다.

1. Cache-Control: public

응답이 public 캐시에 저장되어도 됨

2. Cache-Control: private

응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본값)

3. Cache-Control: s-maxage

프록시 캐시에만 적용되는 max-age

4. Age: 60 (HTTP 헤더)

오리진 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

6. 캐시 무효화

Cache-Control - 확실한 캐시 무효화

1. Cache-Control: no-cache

데이터는 캐시해도 되지만, 항상 원 서버에 검증하고 사용(이름에 주의!)

2. Cache-Control: no-store

데이터에 민감한 정보가 있으므로 저장하면 안됨
(메모리에서 사용하고 최대한 빨리 삭제)

3. Cache-Control: must-revalidate

캐시 만료후 최초 조회시 원 서버에 검증해야함
원 서버 접근 실패시 반드시 오류가 발생해야함 - 504(Gateway Timeout)
must-revalidate는 캐시 유효 시간이라면 캐시를 사용함

4. Pragma: no-cache

HTTP 1.0 하위 호환

[ no-cache 기본 동작 ]

[ no-cache vs must-revalidate ]

no-cache

must-revalidate

출처

[HTTP] 5. HTTP 헤더(일반 헤더)

mandykr — Wed, 8 Jun 2022 12:37:06 +0900

1. 표현

2. 콘텐츠 협상

3. 전송 방식

4. 일반 정보

5. 특별한 정보

6. 인증

7. 쿠키

HTTP 헤더

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)

field-name은 대소문자 구문 없음

HTTP 전송에 필요한 모든 부가정보
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보...
표준 헤더가 너무 많음
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
필요시 임의의 헤더 추가 가능
helloworld: hihi

RFC7230(최신 HTTP 표준)

Representation = representation Metadata + Representation Data

표현 = 표현 메타데이터 + 표현 데이터

메시지 본문(message body)을 통해 표현 데이터 전달
메시지 본문 = 페이로드(payload)
표현은 요청이나 응답에서 전달할 실제 데이터
표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공
- 데이터 유형(html, json), 데이터 길이, 압축 정보 등등
참고: 표현 헤더는 표현 메타데이터와, 페이로드 메시지를 구분해야 하지만, 여기서는 생략

1. 표현

표현 헤더는 전송, 응답 둘다 사용

Content-Type: 표현 데이터의 형식
Content-Encoding: 표현 데이터의 압축 방식
Content-Language: 표현 데이터의 자연 언어
Content-Length: 표현 데이터의 길이

[ Content-Type ] : 표현 데이터의 형식 설명

미디어 타입, 문자 인코딩
예)
- text/html; charset=utf-8
- application/json
- image/png

[ Content-Encoding ] : 표현 데이터 인코딩

표현 데이터를 압축하기 위해 사용
데이터를 전달하는 곳에서 압축 후 인코딩 헤더 추가
데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
예)
- gzip
- deflate
- identity

[ Content-Language ] : 표현 데이터의 자연 언어

표현 데이터의 자연 언어를 표현
예)
- ko
- en
- en-US

[ Content-Length ] : 표현 데이터의 길이

바이트 단위
Transfer-Encoding(전송 코딩)을 사용하면 Content-Length를 사용하면 안됨

2. 협상(콘텐츠 네고시에이션)

클라이언트가 선호하는 표현 요청

협상 헤더는 요청시에만 사용

Accept: 클라이언트가 선호하는 미디어 타입 전달
Accept-Charset: 클라이언트가 선호하는 문자 인코딩
Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
Accept-Language: 클라이언트가 선호하는 자연 언어

(1) Accept-Language 적용

[ Accept-Language 적용 전 ]

[ Accept-Language 적용 후 ]

클라이언트가 선호하는 언어를 전달해 해당 언어의 데이터를 응답 받을 수 있도록 한다.

(2) 협상과 우선순위

Quality Values(q) 값 사용
0~1, 생략하면 1

[ Accept-Language 우선순위 적용 전 ]

[ Accept-Language 우선순위 적용 후 ]

클라이언트가 선호하는 언어를 서버가 지원하지 않을 수 있기 때문에 언어의 우선순위를 지정할 수 있다.

'q' 가 클수록 높은 우선순위

Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

1. ko-KR;q=1 (q생략)
2. ko;q=0.9
3. en-US;q=0.8
4. en:q=0.7

구체적인 것이 높은 우선순위

Accept: text/*, text/plain, text/plain;format=flowed, */*

1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

구체적인 것을 기준으로 미디어 타입을 맞춘다.

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5

3. 전송 방식

단순 전송 : [ Content-Length ]

압축 전송 : [ Content-Encoding ]

분할 전송 : [ Transfer-Encoding ]

1. 크기(Byte)

2. 데이터

범위 전송 : [ Range, Content-Range ]

4. 일반 정보

From: 유저 에이전트의 이메일 정보
Referer: 이전 웹 페이지 주소
User-Agent: 유저 에이전트 애플리케이션 정보
Server: 요청을 처리하는 오리진 서버의 소프트웨어 정보
Date: 메시지가 생성된 날짜

From: 유저 에이전트의 이메일 정보

일반적으로 잘 사용되지 않음
검색 엔진 같은 곳에서, 주로 사용
요청에서 사용

Referer: 이전 웹 페이지 주소

현재 요청된 페이지의 이전 웹 페이지 주소
A -> B로 이동하는 경우 B를 요청할 때 Referer: A 를 포함해서 요청
Referer를 사용해서 유입 경로 분석 가능
요청에서 사용
참고: referer는 단어 referrer의 오타

User-Agent: 유저 에이전트 애플리케이션 정보

user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36
클리이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
통계 정보
어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
요청에서 사용

Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보

Server: Apache/2.2.22 (Debian)
server: nginx
응답에서 사용

Date: 메시지가 발생한 날짜와 시간

Date: Tue, 15 Nov 1994 08:12:31 GMT
응답에서 사용

5. 특별한 정보

Host: 요청한 호스트 정보(도메인)
Location: 페이지 리다이렉션
Allow: 허용 가능한 HTTP 메서드
Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

Host: 요청한 호스트 정보(도메인)

요청에서 사용
필수
하나의 서버가 여러 도메인을 처리해야 할 때
하나의 IP 주소에 여러 도메인이 적용되어 있을 때

가상호스트를 통해 여러 도메인을 한번에 처리할 수 있는 서버 실제 애플리케이션이 여러개 구동될 수 있다.

Location: 페이지 리다이렉션

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)
응답코드 3xx에서 설명
201 (Created): Location 값은 요청에 의해 생성된 리소스 URI
3xx (Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴

Allow: 허용 가능한 HTTP 메서드

405 (Method Not Allowed) 에서 응답에 포함해야함
Allow: GET, HEAD, PUT

Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

503 (Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT (날짜 표기)
Retry-After: 120 (초단위 표기)

6. 인증

Authorization: 클라이언트 인증 정보를 서버에 전달
WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의

Authorization: 클라이언트 인증 정보를 서버에 전달

Authorization: Basic xxxxxxxxxxxxxxxx

WWW-Authenticate: 리소스 접근시 필요한 인증 방법 정의

리소스 접근시 필요한 인증 방법 정의
401 Unauthorized 응답과 함께 사용
WWW-Authenticate: Newauth realm="apps", type=1, title="Login to \"apps\"", Basic realm="simple"

7. 쿠키

Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달

HTTP는 Stateless

HTTP는 무상태(Stateless) 프로토콜이다.
클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다.
클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다.
클라이언트와 서버는 서로 상태를 유지하지 않는다.

[ 로그인 ]

[ 로그인 이후 welcome 페이지 접근 ]

[ 모든 요청에 쿠키 정보 자동 포함 ]

쿠키 특징

예) set-cookie: sessionId=abcde1234; expires=Sat, 26-Dec-020 00:00:00 GMT; path=/; domain=.google.com; Secure
사용처
- 사용자 로그인 세션 관리
- 광고 정보 트래킹
쿠키 정보는 항상 서버에 전송됨
- 네트워크 트래픽 추가 유발
- 최소한의 정보만 사용(세션 id, 인증 토큰)
- 서버에 전송하지 않고, 웹 브라우저 내부에 데이터를 저장하고 싶으면 웹 스토리지 (localStorage, sessionStorage) 참고
주의: 보안에 민감한 데이터는 저장하면 안됨(주민번호, 신용카드 번호 등등)

쿠키 - 생명주기

Expires, max-age
Set-Cookie: expires=Sat, 26-Dec-2020 04:39:21 GMT
- 만료일이 되면 쿠키 삭제
Set-Cookie: max-age=3600 (3600초)
- 0이나 음수를 지정하면 쿠키 삭제
세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지
영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지

쿠키 - 도메인

예) domain=example.org
명시: 명시한 문서 기준 도메인 + 서브 도메인 포함
- domain=example.org를 지정해서 쿠키 생성
- example.org는 물론이고
- dev.example.org도 쿠키 접근
생략: 현재 문서 기준 도메인만 적용
- example.org 에서 쿠키를 생성하고 domain 지정을 생략
- example.org 에서만 쿠키 접근
- dev.example.org는 쿠키 미접근

쿠키 - 경로

예) path=/home
이 경로를 포함한 하위 경로 페이지만 쿠키 접근
일반적으로 path=/ 루트로 지정
예)
- path=/home 지정
- /home -> 가능
- /home/level1 -> 가능
- /home/level1/level2 -> 가능
- /hello -> 불가능

쿠키 - 보안

Secure, HttpOnly, SameSite
Secure
- 쿠키는 http, https를 구분하지 않고 전송
- Secure를 적용하면 https인 경우에만 전송
HttpOnly
- XSS 공격 방지
- 자바스크립트에서 접근 불가(document.cookie)
- HTTP 전송에만 사용
SameSite
- XSRF 공격 방지
- 요청 도메인과 쿠키에 설정된 도메인이 같은 경우만 쿠키 전송

출처

[HTTP] 4. HTTP 상태코드

mandykr — Fri, 3 Jun 2022 13:59:07 +0900

1. HTTP 상태 코드

2. 2xx - 성공

3. 3xx - 리다이렉션

4. 4xx - 클라이언트 오류

5. 5xx - 서버 오류

1. HTTP 상태 코드

클라이언트가 보낸 요청의 처리 상태를 응답해서 알려주는 기능

1xx (Informational): 요청이 수신되어 처리중
2xx (Successful): 요청 정상 처리
3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함

클라이언트가 인식할 수 없는 상태코드를 서버가 반환되는 경우

클라이언트는 상위 상태코드로 해석해서 처리
미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 됨

2. 2xx - 성공

클라이언트의 요청을 성공적으로 처리

200 OK
201 Created
202 Accepted
204 No Content

[ 200 OK ]

요청 성공

[ 201 Created ]

요청 성공해서 새로운 리소스가 생성됨

[ 202 Accepted ]

요청이 접수되었으나 처리가 완료되지 않았음

배치 처리 같은 곳에서 사용
예) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함

[ 204 No Content ]

서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

예) 웹 문서 편집기에서 save 버튼
save 버튼의 결과로 아무 내용이 없어도 된다.
save 버튼을 눌러도 같은 화면을 유지해야 한다.
결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.

3. 3xx - 리다이렉션

요청을 완료하기 위해 유저 에이전트의 추가 조치 필요

300 Multiple Choices
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
307 Temporary Redirect
308 Permanent Redirect

종류

1. 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동

예) /members -> /users
예) /event -> /new-event

2. 일시 리다이렉션 - 일시적인 변경

주문 완료 후 주문 내역 화면으로 이동
PRG: Post/Redirect/Get

3. 특수 리다이렉션

결과 대신 캐시를 사용

[ 리다이렉션 ]

자동 리다이렉트

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동

(1) 영구 리다이렉션

301, 308

리소스의 URI가 영구적으로 이동
원래의 URL를 사용X, 검색 엔진 등에서도 변경 인지

[ 영구 리다이렉션 - 301 Moved Permanently ]

리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)

[ 영구 리다이렉션 - 308 Permanent Redirect ]

301과 기능은 같음
리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

(2) 일시적인 리다이렉션

302, 307, 303

리소스의 URI가 일시적으로 변경
따라서 검색 엔진 등에서 URL을 변경하면 안됨

[ 일시적인 리다이렉션 - 302 Found ]

리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)

[ 일시적인 리다이렉션 - 307 Temporary Redirect ]

302와 기능은 같음

리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)

[ 일시적인 리다이렉션 - 303 See Other ]

302와 기능은 같음

리다이렉트시 요청 메서드가 GET으로 변경

(3) PRG: Post/Redirect/Get

일시적인 리다이렉션 - 중복 방지를 위한 패턴

예시

POST로 주문후에 웹 브라우저를 새로고침하면?

새로고침은 다시 요청이기 때문에 중복 주문이 될 수 있다.

[ PRG 사용전 ]

[ PRG 사용 ]

POST로 주문후에 새로 고침으로 인한 중복 주문 방지
POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트
새로고침해도 결과 화면을 GET으로 조회
중복 주문 대신에 결과 화면만 GET으로 다시 요청

307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용
자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음

(4) 기타 리다이렉션

300, 304

[ 기타 리다이렉션 - 300 Multiple Choices ]

안쓴다.

[ 기타 리다이렉션 - 304 Not Modified ]

캐시를 목적으로 사용
클라이언트에게 리소스가 수정되지 않았음을 알려준다.
따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다. (캐시로 리다이렉트 한다.)
304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 하므로)
조건부 GET, HEAD 요청시 사용

4. 4xx - 클라이언트 오류

클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음
오류의 원인이 클라이언트에 있음
클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패함

[ 400 Bad Request ]

클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음

요청 구문, 메시지 등등 오류
클라이언트는 요청 내용을 다시 검토하고, 보내야함
예) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때

서버 입장에서는 전달 받는 데이터에 대한 Validation을 철저히 해서

서버 오류가 아닌 400으로 응답해 클라이언트에서 다시 검토할 수 있도록 해야한다.

[ 401 Unauthorized ]

클라이언트가 해당 리소스에 대한 인증이 필요함

인증(Authentication) 되지 않음
401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명

참고

인증(Authentication): 본인이 누구인지 확인, (로그인)
인가(Authorization): 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)
오류 메시지가 Unauthorized 이지만 인증 되지 않음을 의미

[ 403 Forbidden ]

서버가 요청을 이해했지만 승인을 거부함

주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
예) 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우

[ 404 Not Found ]

요청 리소스를 찾을 수 없음

요청 리소스가 서버에 없음
또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때

5. 5xx - 서버 오류

서버 문제로 오류 발생
서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있음(복구가 되거나 등등)

[ 500 Internal Server Error ]

서버 문제로 오류 발생, 애매하면 500 오류

서버 내부 문제로 오류 발생
애매하면 500 오류

[ 503 Service Unavailable ]

서비스 이용 불가

서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음

5xx는 서버에 문제가 발생했다는 의미이기 때문에

비즈니스 예외를 발생시키는 경우 5xx을 사용하지 않아야 한다.

비즈니스 에외는 2xx, 4xx를 활용하자.

예) 사용자의 계좌의 잔고가 부족하다.

출처

https://restfulapi.net/resource-naming/

[HTTP] 3. HTTP 메서드

mandykr — Thu, 2 Jun 2022 17:09:23 +0900

1. HTTP API

2. HTTP 메서드

3. HTTP 메서드 속성

4. HTTP 메서드 활용

1. HTTP API

좋은 URI는 행위는 배제한 채 리소스를 식별하고 계층 구조를 활용해 API URI를 설계하는 것이다.

회원 목록 조회 /members
회원 조회 /members/{id}
회원 등록 /members/{id}
회원 수정 /members/{id}
회원 삭제 /members/{id}

[ 리소스 ]

회원

[ 행위 ]

조회, 등록, 수정, 삭제

계층 구조의 URI에 행위를 의미하는 HTTP 메서드를 추가해 API를 구분할 수 있다.

2. HTTP 메서드

주요 메서드

GET: 리소스 조회
POST: 요청 데이터 처리, 주로 등록에 사용
PUT: 리소스를 대체, 해당 리소스가 없으면 생성
PATCH: 리소스 부분 변경
DELETE: 리소스 삭제

기타 메서드

HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

1) GET

리소스 조회
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음

[ 조회 ]

[ 응답 ]

2) POST

요청 데이터 처리
메시지 바디를 통해 서버로 요청 데이터 전달
서버는 요청 데이터를 처리
메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

[ 요청 ]

[ 응답 ]

POST 사용

리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다.

1. 새 리소스 생성(등록)

서버가 아직 식별하지 않은 새 리소스 생성

2. 요청 데이터 처리

단순히 데이터를 생성하거나, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
예) 주문에서 결제완료 -> 배달시작 -> 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
예) POST /orders/{orderId}/start-delivery (컨트롤 URI)

3. 다른 메서드로 처리하기 애매한 경우

예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우
애매하면 POST

3) PUT

리소스를 대체

리소스가 있으면 대체
리소스가 없으면 생성
쉽게 이야기해서 덮어버림

클라이언트가 리소스를 식별

클라이언트가 리소스 위치를 알고 URI 지정
POST와 차이점

[ 리소스가 있는 경우 ]

기존 리소스를 대체한다.

[ 주의! ]

기존 리소스의 일부 필드를 전달하지 않는 경우에도 전달하는 리소스로 완전히 대체한다.

서버에서 리소스를 json 문서로 다루고 있는 경우 필드가 삭제되고

Spring Framework를 사용할떄처럼 json을 객체로 변환해 다루는 경우 객체의 필드에 기본값이 저장된다.

[ 리소스가 없는 경우 ]

새로운 리소스를 생성한다.

4) PATCH

리소스 부분 변경

5) DELETE

리소스 제거

3. HTTP 메서드 속성

1) 안전(Safe)

호출해도 리소스를 변경하지 않는다.

GET, HEAD

2) 멱등(Idempotent)

얼마든지 호출해도 결과가 똑같다.

멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지는 않는다.

GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.

활용

자동 복구 메커니즘

3) 캐시 가능(Cacheable)

응답 결과 리소스를 캐시해서 사용해도 되는가?

GET, HEAD, POST, PATCH 캐시가능
실제로는 GET, HEAD 정도만 캐시로 사용
POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음

4. HTTP 메서드 활용

1) 클라이언트에서 서버로 데이터 전송

쿼리 파라미터를 통한 데이터 전송

GET
주로 정렬 필터(검색어)

메시지 바디를 통한 데이터 전송

POST, PUT, PATCH
회원 가입, 상품 주문, 리소스 등록, 리소스 변경

(1) 정적 데이터 조회

[ 쿼리 파라미터 미사용 ]

이미지, 정적 텍스트 문서
조회는 GET 사용
정적 데이터는 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회가능

(2) 동적 데이터 조회

[ 쿼리 파라미터 사용 ]

주로 검색, 게시판 목록에서 정렬 필터(검색어)
조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용
조회는 GET 사용
GET은 쿼리 파라미터 사용해서 데이터를 전달

(3) HTML Form 데이터 전송

HTML Form 전송은 GET, POST만 지원

[ POST 전송 - 저장 ]

회원 가입, 상품 주문, 데이터 변경
Content-Type: application/x-www-form-urlencoded
- form의 내용을 메시지 바디를 통해서 전송(key=value, 쿼리 파라미터 형식)
- 전송 데이터를 url encoding 처리
  • 예) abc김 -> abc%EA%B9%80

[ GET 전송 - 저장 ]

GET은 웹 브라우저가 form 형식의 데이터를 쿼리 파라미터로 변경한다.
GET은 조회에서만 사용해야 한다.

[ GET 전송 - 조회 ]

GET은 웹 브라우저가 form 형식의 데이터를 쿼리 파라미터로 변경한다.
조회를 위한 Form 데이터 전송

[ multipart/form-data ]

파일 업로드 같은 바이너리 데이터 전송시 사용
다른 종류의 여러 파일과 폼의 내용 함께 전송 가능

(4) HTTP API 데이터 전송

서버 to 서버
- 백엔드 시스템 통신
앱 클라이언트
- 아이폰, 안드로이드
웹 클라이언트
- HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용(AJAX)
- 예) React, VueJs 같은 웹 클라이언트와 API 통신
POST, PUT, PATCH: 메시지 바디를 통해 데이터 전송
GET: 조회, 쿼리 파라미터로 데이터 전달
Content-Type: application/json을 주로 사용 (사실상 표준)
- TEXT, XML, JSON 등등

2) HTTP API 설계

(1) POST 기반 등록

[ 회원 관리 시스템 ]

회원 목록 /members -> GET
회원 등록 /members -> POST
회원 조회 /members/{id} -> GET
회원 수정 /members/{id} -> PATCH, PUT, POST
회원 삭제 /members/{id} -> DELETE

[ 특징 ]

1. 클라이언트는 등록될 리소스의 URI를 모른다.

회원 등록 /members -> POST
POST /members

2. 서버가 새로 등록된 리소스 URI를 생성해준다.

HTTP/1.1 201 Created
Location: /members/100

3. 컬렉션(Collection)

서버가 관리하는 리소스 디렉토리
서버가 리소스의 URI를 생성하고 관리
여기서 컬렉션은 /members

(2) PUT 기반 등록

[ 파일 관리 시스템 ]

파일 목록 /files -> GET
파일 조회 /files/{filename} -> GET
파일 등록 /files/{filename} -> PUT
파일 삭제 /files/{filename} -> DELETE
파일 대량 등록 /files -> POST

[ 특징 ]

1. 클라이언트가 리소스 URI를 알고 있어야 한다.

파일 등록 /files/{filename} -> PUT
PUT /files/star.jpg

2. 클라이언트가 직접 리소스의 URI를 지정한다.

3. 스토어(Store)

클라이언트가 관리하는 리소스 저장소
클라이언트가 리소스의 URI를 알고 관리
여기서 스토어는 /files

(3) HTML FORM 사용

회원 목록 /members -> GET
회원 등록 폼 /members/new -> GET
회원 등록 /members/new, /members -> POST
회원 조회 /members/{id} -> GET
회원 수정 폼 /members/{id}/edit -> GET
회원 수정 /members/{id}/edit, /members/{id} -> POST
회원 삭제 /members/{id}/delete -> POST

[ 특징 ]

1. HTML FORM은 GET, POST만 지원

2. 컨트롤 URI

GET, POST만 지원하므로 제약이 있음
이런 제약을 해결하기 위해 동사로 된 리소스 경로 사용
POST의 /new, /edit, /delete가 컨트롤 URI
HTTP 메서드로 해결하기 애매한 경우 사용(HTTP API 포함)

(4) 참고하면 좋은 URI 설계 개념

1. 문서(document)

단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
예) /members/100, /files/star.jpg

2. 컬렉션(collection)

서버가 관리하는 리소스 디렉터리
서버가 리소스의 URI를 생성하고 관리
예) /members

3. 스토어(store)

클라이언트가 관리하는 자원 저장소
클라이언트가 리소스의 URI를 알고 관리
예) /files

4. 컨트롤러(controller), 컨트롤 URI

문서, 컬렉션, 스토어로 해결하기 어려운 추가 프로세스 실행
동사를 직접 사용
예) /members/{id}/delete

컬렉션과 문서로 최대한 해결하고 복잡한 API를 설계할 때 컨트롤 URI를 고려하자.

출처

[HTTP] 2. HTTP 기본

mandykr — Thu, 2 Jun 2022 14:36:53 +0900

1. HTTP

2. HTTP 특징

1) 클라이언트 서버 구조

2) 무상태 프로토콜

3) 비 연결성

4) HTTP 메시지

1. HTTP

HyperText Transfer Protocol

HTTP 메시지에 모든 것을 전송

기존에는 HyperText를 통한 연결과정에서 HTTP를 사용했지만 현재는 다른 여러 곳에서도 사용이 가능하다.

HTML, TEXT
MAGE, 음성, 영상, 파일
JSON, XML (API)
거의 모든 형태의 데이터 전송 가능
서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

HTTP 역사

HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X
HTTP/1.0 1996년: 메서드, 헤더 추가
HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)
HTTP/2 2015년: 성능 개선
HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

기반 프로토콜

TCP: HTTP/1.1, HTTP/2
UDP: HTTP/3
현재 HTTP/1.1 주로 사용
HTTP/2, HTTP/3 도 점점 증가

2. HTTP 특징

클라이언트 서버 구조
무상태 프로토콜(스테이스리스), 비연결성
HTTP 메시지
단순함, 확장 가능

1) 클라이언트 서버 구조

Request / Response 구조
클라이언트는 서버에 요청을 보내고, 응답을 대기
서버가 요청에 대한 결과를 만들어서 응답

클라이언트와 서버가 각자의 책임에 집중해 독립적으로 진화할 수 있도록 한다.

클라이언트는 UI에 집중
서버는 비즈니스 로직에 집중(아키텍처, 트래픽 처리 ...)

2) 무상태 프로토콜

스테이스리스(Stateless)

서버가 클라이언트의 상태를 보존하지 않는다.

장점: 서버 확장성 높음(스케일 아웃)
단점: 클라이언트가 추가 데이터 전송

상태 유지 -Stateful

상태를 서버에서 갖고있기 때문에 항상 같은 서버가 유지되어야 한다.
다른 서버로 변경이 불가능하다.

무상태 - Stateless

서버로 요청할 때 클라이언트에서 상태를 함께 전달한다.
다른 서버로 변경되어도 문제가 발생하지 않는다.
무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능

무상태(Stateless) - 스케일 아웃

무상태는 어느 서버로 요청해도 문제가 발생하지 않기 때문에 서버의 수평 확장에 유리하다.

무상태(Stateless) - 실무 한계

모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.

무상태

예) 로그인이 필요 없는 단순한 서비스 소개 화면

상태 유지

예) 로그인
로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
일반적으로 브라우저 쿠키와 서버 세션등을 사용해서 상태 유지
상태 유지는 최소한만 사용

3) 비 연결성

HTTP는 기본이 연결을 유지하지 않는 모델
일반적으로 초 단위의 이하의 빠른 속도로 응답
1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
서버 자원을 매우 효율적으로 사용할 수 있음

연결을 유지하는 모델

당장 사용하지 않는 클라이언트와 연결을 유지하기 때문에 서버 자원을 낭비하게 된다.

연결을 유지하지 않는 모델

요청과 응답이 필요한 경우에만 연결하고 응답이 완료되면 연결을 끊는다.

서버가 유지하는 자원을 최소한으로 줄일 수 있다.

[ 1. 요청과 응답 ]

[ 2. 연결 종료 ]

[ 3. 새로운 요청 ]

비 연결성의 한계와 극복

한계

TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등
등 수 많은 자원이 함께 다운로드

극복

HTTP 지속 연결(Persistent Connections)로 문제 해결
HTTP/2, HTTP/3에서 더 많은 최적화

[ HTTP 초기 - 연결, 종료 낭비 ]

[ HTTP 지속 연결(Persistent Connections) ]

4) HTTP 메시지

HTTP 메시지 구조

HTTP 메시지 구조	HTTP 요청	HTTP 응답

(1) 시작 라인

▼ HTTP 요청 메시지

start-line = request-line

request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)

HTTP 메서드 (GET: 조회)
요청 대상 (/search?q=hello&hl=ko)
HTTP Version

[ HTTP 메서드 ]

( GET )

종류: GET, POST, PUT, DELETE...
서버가 수행해야 할 동작 지정
GET: 리소스 조회
POST: 요청 내역 처리

[ 요청 대상 ]

( /search?q=hello&hl=ko )

absolute-path[?query] (절대경로[?쿼리])
절대경로= "/" 로 시작하는 경로
참고: *, http://...?x=y 와 같이 다른 유형의 경로지정 방법도 있다.

[ HTTP Version ]

( HTTP/1.1 )

HTTP Version

▼ HTTP 응답 메시지

start-line = status-line

status-line = HTTP-version SP status-code SP reason-phrase CRLF

HTTP 버전
HTTP 상태 코드: 요청 성공, 실패를 나타냄
이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 글

[ HTTP Version ]

( HTTP/1.1 )

[ HTTP 상태 코드 ]

( 200 )

200: 성공
400: 클라이언트 요청 오류
500: 서버 내부 오류

[ 이유 문구 ]

( OK )

(2) HTTP 헤더

header-field = field-name ":" OWS field-value OWS (OWS:띄어쓰기 허용)

field-name은 대소문자 구문 없음

HTTP 전송에 필요한 모든 부가정보
예) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보...
표준 헤더가 너무 많음
https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
필요시 임의의 헤더 추가 가능
helloworld: hihi

(3) HTTP 메시지 바디

HTTP 요청도 메시지 바디를 가질 수 있음
실제 전송할 데이터
HTML 문서, 이미지, 영상, JSON 등등 byte로 표현할 수 있는 모든 데이터 전송 가능

출처

[DDD] 5. 도메인 이벤트와 CQRS

mandykr — Tue, 31 May 2022 14:45:25 +0900

1. 도메인 이벤트

2. 스프링 ApplicationEvent

3. 이벤트 소싱(Event Sourcing)

4. CQRS(명령 및 쿼리 책임 분리)

1. 도메인 이벤트

느슨한 결합과 강한 결합

외부 서비스가 정상이 아닐 경우 트랜잭션 처리를 어떻게 해야 할지 애매
외부 서비스 성능에 직접적인 영향을 받는 문제가 있다.
도메인 객체에 서비스를 전달하면 추가로 설계상 문제가 나타날 수 있다.
도메인 객체에 서비스를 전달할 떄 또 다른 문제는 기능을 추가할 때 발생한다.
비동기 이벤트를 사용하면 두 시스템 간의 결합을 크게 낮출 수 있다.

이벤트

이벤트가 발생한다는 것은 상태가 변경됐다는 것을 의미한다.
도메인 모델에서도 UI 컴포넌트와 유사하게 도메인의 상태 변경을 이벤트로 표현할 수 있다.
보통 '~할 때', '~가 발생하면', '만약 ~하면'과 같은 요구사항은 도메인의 상태 변경과 관련된 경우가 많고 이런 요구사항을 이벤트를 이용해서 구현할 수 있다.
이벤트는 이미 과거에 일어난 사건이기 때문에 수정되거나 삭제되지 않는다.

이벤트 관련 구성요소

도메인 모델에서 이벤트 주체는 엔티티, 밸류, 도메인 서비스와 같은 도메인 객체이다.
도메인 객체는 도메인 로직을 실행해서 상태가 바뀌면 관련 이벤트를 발생한다.
이벤트 핸들러(handler)는 이벤트 생성 주체가 발생한 이벤트에 반응한다.
이벤트 핸들러는 생성 주체가 발생한 이벤트를 전달받아 이벤트에 담긴 데이터를 이용해서 원하는 기능을 실행한다.
이벤트 생성 주체와 이벤트 핸들러를 연결해 주는 것이 이벤트 디스패처(dispatcher)이다.
이벤트를 전달받은 디스패처는 해당 이벤트를 처리할 수 있는 핸들러에 이벤트를 전파한다.

이벤트의 구성

이벤트는 현재 기준으로 (바로 직전이라도) 과거에 벌어진 것을 표현하기 때문에 이벤트 이름에는 과거 시제를 사용한다.
이벤트는 이벤트 핸들러가 작업을 수행하는 데 필요한 최소한의 데이터를 담아야 한다.

이벤트 용도

도메인의 상태가 바뀔 때 다른 후처리를 해야 할 경우 후처리를 실행하기 위한 트리거로 이벤트를 사용할 수 있다.
이벤트의 두 번째 용도는 서로 다른 시스템 간의 데이터 동기화이다.

이벤트 장점

서로 다른 도메인 로직이 섞이는 것을 방지할 수 있다.
이벤트 핸들러를 사용하면 기능 확장도 용이하다.

비동기 이벤트 처리

로컬 핸들러를 비동기로 실행하기
메시지 큐를 사용하기
이벤트 저장소와 이벤트 포워더 사용하기
이벤트 저장소와 이벤트 제공 API 사용하기

2. 스프링 ApplicationEvent

1) Event Publisher 사용

[ Event Publisher ]

@Transactional
@Service
public class ProductService {
    private final ApplicationEventPublisher publisher;

    public ProductService(ApplicationEventPublisher publisher) {
        this.publisher = publisher;
    }

    public void create(String name, int price) {
        Product product = new Product(name, BigDecimal.valueOf(price));
        publisher.publishEvent(new ProductCreatedEvent(name));
    }
}

public class ProductCreatedEvent {
    private UUID id;
    private final String name;
    private final int price;

    public ProductCreatedEvent(UUID id, String name, int price) {
        this.id = id;
        this.name = name;
        this.price = price;
    }

    public UUID getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public int getPrice() {
        return price;
    }
}

[ Event Listener ]

@Component
public class EmailSender implements Sender {
    @EventListener
    public void send(ProductCreatedEvent event) {
        System.out.println("email sender = " + event.getName());
    }

    @Override
    public void send(String text) {
        System.out.println("email sender = " + text);
    }
}

@Component
public class SmsSender implements Sender {
    @EventListener
    public void send(ProductCreatedEvent event) {
        System.out.println("sms sender = " + event.getName());
    }

    @Override
    public void send(String text) {
        System.out.println("sms sender = " + text);
    }
}

@EventListener는 이벤트를 발행하는 트랜잭션에 묶여있기 때문에 send() 에서 실행이 실패하면 이벤트를 발행하는 로직이 롤백된다.

이 문제는 @TransactionalEventListener를 사용해 트랜잭션 범위 밖에서 실행되도록 할 수 있다.

@TransactionalEventListener
public void send(ProductCreatedEvent event) {
    System.out.println("email sender = " + event.getName());
}

특정 조건에 의해 이벤트 로직이 수행되어야 할 때 이벤트 발행은 조건을 체크하는 로직이 들어가지 않도록 작성하고

이벤트를 수신하는 쪽에서 조건에 따라 로직이 처리되도록 작성할 수 있다.

@TransactionalEventListener(condition = "#event.price != 0")
public void send(ProductCreatedEvent event) {
    System.out.println("email sender = " + event.getName());
}

[ Test ]

@RecordApplicationEvents 를 사용해 이벤트 목록 주입받을 수 있다.

다음과 같은 테스트는 비용이 크기 때문에 단위 테스트 보다는 인수 테스트에서 작성해볼 수 있다.

@RecordApplicationEvents
@SpringBootTest
class ProductServiceTest {
    @Autowired
    ProductService productService;

    @Autowired
    private ApplicationEvents events;

    @Test
    void create() {
        assertThat(events.stream(ProductCreatedEvent.class).count()).isEqualTo(0);
        productService.create("치킨", 10_000);
        assertThat(events.stream(ProductCreatedEvent.class).count()).isEqualTo(1);
    }
}

2) Abstract Aggregate Root

명시적으로 AbstractAggregateRoot 클래스를 상속하도록 작성한다.

엔티티에서 이벤트를 register 하고 응용 서비스에서 명시적으로 Spring Data Jpa 의 save()를 호출해 이벤트를 발행한다.

@Transactional
@Service
public class ProductService {
    private final ProductRepository productRepository;
    private final ApplicationEventPublisher publisher;

    public void changePrice(UUID id, int price) {
        Product product = productRepository.findById(id).orElseThrow(EntityNotFoundException::new);
        product.changePrice(BigDecimal.valueOf(price));
        // 이벤트 발행을 위해 save()를 명시적으로 호출해줘야 한다.
        productRepository.save(product);
    }
}

@Entity
public class Product extends AbstractAggregateRoot<Product> {
    @Column(name = "id", columnDefinition = "varbinary(16)")
    @Id
    private UUID id;

    // ...

    public void changePrice(BigDecimal price) {
        this.price = new ProductPrice(price);
        registerEvent(new ProductPriceChangedEvent(id, price));
    }
}

public class ProductPriceChangedEvent {
    private final UUID id;
    private final BigDecimal price;

    public ProductPriceChangedEvent(UUID id, BigDecimal price) {
        this.id = id;
        this.price = price;
    }
}

엔티티의 ID를 @GeneratedValue를 이용해 자동 생성하는 경우 엔티티를 DB에 저장하기 전에는 ID를 알 수 없는 문제가 발생한다.

이런 경우 @PostPersist를 사용해 엔티티가 영속화된 경우 이벤트를 생성하도록 할 수 있다.

// service
public Product create(String name, int price) {
    Product product = productRepository.save(new Product(name, BigDecimal.valueOf(price)));
    return product;
}

// entity
@PostPersist
private void created() {
    registerEvent(new ProductCreatedEvent(id, name, price));
}

3. 이벤트 소싱(Event Sourcing)

개념

도메인 모델에서 발생하는 모든 이벤트를 기록하는 데이터 저장 기법
반응형 시스템에 적합하고 규모 확장 용이
로깅은 예외 상황이나 프로파일링까지 고려하지만 Event Sourcing은 비즈니스 이벤트에 대해서만 다룬다.
Update나 Delete 연산은 수행되지 않는다.

입출금 예시

이벤트: 사용자 A가 통장 a에 1000원을 입금(+)한다.
현재 상태: 1000원

이벤트: 사용자 A가 통장 a에 500원을 인출(-)한다.
현재 상태: 500원

이벤트: 사용자 A가 통장 a에 1000원을 입금(+)한다.
현재 상태: 1500원

4. CQRS(명령 및 쿼리 책임 분리)

CQRS

상태를 변경하는 명령(Command)을 위한 모델과 상태를 제공하는 조회(Query)를 위한 모델을 분리하는 패턴이다.
CQRS는 복잡한 도메인에 적합하다.

웹과 CQRS

메모리에 캐시하는 데이터는 DB에 보관된 데이터를 그대로 저장하기보다는 화면에 맞는 모양으로 변환한 데이터를 캐시할 때 성능에 더 유리하다.
조회 속도를 높이기 위해 별도 처리를 하고 있다면 명시적으로 명령 모델과 조회 모델을 구분하자.
조회 기능 때문에 명령 모델이 복잡해지는 것을 방지할 수 있고 명령 모델에 관계없이 조회 기능에 특화된 구현 기법을 보다 쉽게 적용할 수 있다.

CQRS 장단점

명령 모델을 구현할 때 도메인 자체에 집중할 수 있다.
조회 성능을 향상시키는 데 유리하다.
구현해야 할 코드가 더 많다.
더 많은 구현 기술이 필요하다.

출처

NEXTSTEP: DDD 세레나데 3기

[DDD] 4. 도메인 주도 설계 아키텍처

mandykr — Tue, 31 May 2022 12:58:46 +0900

1. 계층형 아키텍처

2. DTO(Data Transfer Object)

3. 의존 역전 원칙

4. 전략적 설계 - ANTICORRUPTION LAYER

1. 계층형 아키텍처

도메인 주도 설계의 아키텍처가 별도로 정의되어 있는 것은 아니지만

계층형 아키텍처, 클린 아키텍처, 헥사고날 아키텍처 처럼 도메인을 보호하는 아키텍처의 개념이 중요하다.

계층형 아키텍처의 비즈니스 로직은 도메인 모델에서 수행되도록 한다.

Entity, Value Object 는 물론이고 비즈니스 로직이 Application Service 로 넘어가지 않도록 하는 Domain Service도 도메인 모델에 속한다.

1) Presentation Layer

사용자가 시스템을 사용할 수 있는 (화면) 흐름을 제공하고 제어
사용자가의 요청을 알맞은 응용 서비스에 전달하고 결과를 사용자에게 제공한다.
사용자의 세션을 관리한다.

2) Application Layer

응용 영역은 시스템이 사용자에게 제공해야 할 기능을 구현한다.

Application Service

사용자의 요청을 처리하기 위해 리포지터리로부터 도메인 객체를 구하고, 도메인 객체를 사용한다.
로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임한다.
도메인 객체 간의 실행 흐름을 제어
트랜잭션 처리
도메인 영역에서 발생시킨 이벤트를 처리

public Result doSomeFunc(SomeReq req) {
    // 1. 리포지터리에서 애그리거트를 구한다.
    SomeAgg agg = someAggRepository.findById(req.getId());
    checkNull(agg);
    // 2. 애그리거트의 도메인 기능을 실행한다.
    agg.doFunc(req.getValue());
    // 3. 결과를 리턴한다.
    return createSuccessResult(agg);
}

[ 메서드 파라미터와 값 리턴 ]

응용 서비스에 데이터로 전달할 파라미터가 두 개 이상 존재하면 데이터 전달을 위한 별도 클래스를 사용하는 것이 편리하다.
응용 서비스는 표현 영역에서 필요한 데이터만 리턴하는 것이 기능 실행 로직의 응집도를 높이는 확실한 방법이다.

[ 값 검증 ]

값 검증은 표현 영역과 응용 서비스 두 곳에서 모두 수행할 수 있다.
원칙적으로 모든 값에 대한 검증은 응용 서비스에서 처리한다.
표현 영역에서 필수 값과 값의 형식을 검사하면 실질적으로 응용 서비스는 아이디 중복 여부와 같은 논리적 오류만 검사하면 된다.

3) Domain Layer

도메인 영역은 도메인 모델을 구현한다.

Domain Service

도메인 서비스는 애플리케이션 서비스와 달리 도메인 로직을 다룬다.
엔티티와 값 객체만으로 표현하기 어려운 비즈니스 로직을 도메인 서비스를 통해 애플리케이션 계층으로 넘어가지 않도록 한다.
도메인 서비스는 상태가 없을 수 있고 절차적일 수 있으며 클래스 이름이 Service로 작성되지 않을 수 있다.
Spring Framework에서 애플리케이션 서비스에 @Service를 사용한다면 차별을 위해 @Component를 사용하거나 별도로 어노테이션을 만들어 관리한다.

예) 송금과 관련된 정책을 처리하는 도메인 서비스

public class TransactionValidator {
    public boolean isValid(Money amount, Account from, Account to) {
        if (!from.getCurrency().equals(amount.getCurrency())) {
            return false;
        }
        if (!to.getCurrency().equals(amount.getCurrency())) {
            return false;
        }
        if (from.getBalance().isLessThan(amount)) {
            return false;
        }
        if (amount.isGreaterThan(someThreshold)) {
            return false;
        }
        return true;
    }
}

Domain Model

[ 값 검증 ]

도메인 모델에서의 값 검증은 유효성 검사의 개념보다는 모델링을 구현하고 모델링의 검증에 대한 개념이 강하다.

public class PhoneNumber {
    private final String phoneNumber;

    public PhoneNumber(String phoneNumber) {
        Objects.requireNonNull(phoneNumber, "phoneNumber must not be null"); // 
        var sb = new StringBuilder();
        char ch;
        for (int i = 0; i < phoneNumber.length(); ++i) {
            ch = phoneNumber.charAt(i);
            if (Character.isDigit(ch)) { // 
                sb.append(ch);
            } else if (!Character.isWhitespace(ch) && ch != '(' && ch != ')' && ch != '-' && ch != '.') { // 
                throw new IllegalArgument(phoneNumber + " is not valid");
            }
        }
        if (sb.length() == 0) { // 
            throw new IllegalArgumentException("phoneNumber must not be empty");
        }
        this.phoneNumber = sb.toString();
    }

    @Override
    public String toString() {
        return phoneNumber;
    }
}

4) Infrastructure Layer

인프라스트럭처 영역은 구현 기술에 대한 것을 다룬다.

2. DTO(Data Transfer Object)

1) 응용 서비스의 출력

응용 프로그램 서비스를 설계 할 때 중요한 한 가지 결정은 사용할 데이터와 반환 할 데이터를 결정하는 것

도메인 모델을 직접 사용하거나, - Domain Model Everywhere
별도의 DTO(Data Transfer Object) 사용하기 - Pure Domain Model

2) DTO(Data Transfer Object)

프로세스 간에 데이터를 전달하는 객체
구조체

VALUE OBJECT는 DTO가 아니다. - Martin Fowler

DTO의 용도로 VO를 사용할 수는 있지만 VO는 DTO를 의미하지 않는다.

3) Domain Model Everywhere

도메인 모델을 모든 계층에서 사용
- 이미 가지고 있는 클래스를 사용할 수 있다.
- 도메인 모델과 DTO 간에 변환이 필요 없다.
OSIV(Open Session In View) 사용
- Spring - Open Session In View - Kingbbode
Getter 메서드, Setter 메서드 사용
DTO는 나쁘다!

4) Pure Domain Model

클라이언트와 도메인 모델 간의 분리
애플리케이션의 외부 요구 사항과 내부 요구 사항을 분리

항상 DTO를 만드는 것은 실용적이지 않다.

3. 의존 역전 원칙

1) 고수준 모듈, 저수준 모듈

고수준 모듈

어떤 의미 있는 단일 기능을 제공하는 모듈
e.g. 가격 할인 계산

예) 고객 정보를 구한다.

룰을 이용해서 할인 금액을 구한다.

저수준 모듈

고수준 모듈의 기능을 구현하기 위해 필요한 하위 기능의 실제 구현
e.g. 가격 할인 계산

예) RDBMS에서 JPA로 구한다.

Drools로 룰을 적용한다.

2) 고수준 모듈의 의존 문제

고수준 모듈이 저수준 모듈을 의존
저수준 모듈의 변경에 따라 고수준 모듈이 영향을 받는다.
고수준 모듈만 테스트하기 어렵다.
다른 구현 기술을 사용하려면 코드의 많은 부분을 고쳐야 한다.

3) DIP

저수준 모듈이 고수준 모듈에 의존한다고 해서 이를 DIP(Dependency Inversion Principle, 의존 역전 원칙)라고 부른다.
인프라스트럭처 영역에 의존할 때 발생했던 구현 교체가 어렵다는 문제와 테스트가 어려운 문제를 해소할 수 있다.
고수준 모듈은 더 이상 저수준 모듈에 의존하지 않고 구현을 추상화한 인터페이스에 의존한다.

DIP를 적용할 때 하위 기능을 추상화한 인터페이스는 고수준 모듈 관점에서 도출한다.
추상화한 인터페이스는 저수준 모듈이 아닌 고수준 모듈에 위치한다.

계층형 아키텍처에서 DTO(Pure Domain Model)를 사용하고 DIP를 적용하는 이유는 도메인을 보호하기 위함이다.

결국 계층형 아키텍처에서 도메인을 보호하는 개념의 헥사고날, 어니언, 클린 아키텍처로 가게된다.

4) 육각형, 양파, 클린 아키텍처

육각형 아키텍처(hexagonal architecture), 양파 아키텍처(onion architecture) 및 클린 아키텍처(clean architecture)의 기본 규칙

4. 전략적 설계 - ANTICORRUPTION LAYER

손상 방지 레이어를 다른 하위 시스템 사이에 배치하여 격리한다.

이 레이어는 두 시스템 간의 통신을 변환하여, 다른 응용 프로그램이 해당 디자인 및 기술 방식을 손상시키지 않도록 하여 해당 시스템을 변경되지 않은 상태로 유지하도록 할 수 있다.

출처

NEXTSTEP: DDD 세레나데 3기

[DDD] 3. 도메인 주도 설계 기본 요소

mandykr — Mon, 30 May 2022 12:00:26 +0900

1. 전술적 설계 - ENTITY와 VALUE OBJECT

2. 전술적 설계 - AGGREGATE와 REPOSITORY

3. 전술적 설계 - SERVICE

1. 전술적 설계 - ENTITY와 VALUE OBJECT

도출한 도메인 모델은 Entity와 Value Object로 구현될 수 있다.

1) Entity

식별자를 갖는다.
- 객체의 상태 중 해당 객체의 고유한 성질을 표현할 수 있는 상태들을 식별자라고 부른다.
식별자는 엔티티 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 갖는다.

식별자 생성

특정 규칙에 따라 생성
UUID 사용
값을 직접 입력
일련번호 사용(시퀀스나 DB의 자동 증가 칼럼 사용)

도메인 모델에 set 메서드 넣지 않기

changeShippingInfo() vs setShippingInfo()
completePayment() vs setOrderState()

도메인 모델에 getter 메서드와 setter 메서드를 무조건 추가하는 것은 좋지 않은 버릇
특히 setter 메서드는 도메인의 핵심 개념이나 의도를 코드에서 사라지게 한다.
setter 메서드의 또 다른 문제는 도메인 객체를 생성할 때 완전한 상태가 아닐 수도 있다는 것이다.
도메인 객체가 불완전한 상태로 사용되는 것을 막으려면 생성 시점에 필요한 것을 전달해 주어야 한다.

2) Value Object

의미를 명확하게 표현하거나 두 개 이상의 데이터가 개념적으로 하나인 경우 밸류 타입을 이용

예) 우편번호를 String으로 표현하는 것이 가능할까?

String으로 저장은 가능하지만 실제로 여러 특수문자가 저장될 수 있다.

우편번호 값 객체를 통해 유효성 검사를 할 수 있다.

시스템이 성숙함에 따라 데이터 값을 객체로 대체
밸류 타입은 불변
밸류 객체의 값을 변경하는 방법은 새로운 밸류 객체를 할당하는 것뿐이다.
항상 equals와 hashCode를 재정의 한다.

원시값으로 표현

class Car {
    private String name;
    private int position;
    
    Car(final String name, final int position) {
        if (Objects.isNull(name) || name.length() > 5) {
            throw new IllegalArgumentException();
        }
        this.name = name;
        this.position = position;
    }
}

Value Object로 표현

class CarName {
    private final value;
    
    CarName(final String value) {
        if (Objects.isNull(value) || value.length() > 5) {
            throw new IllegalArgumentException();
        }
        this.value = value;
    }
}

class Car {
    private CarName name;
    private int position;
    
    Car(final String name, final int position) {
        this.name = new CarName(name);
        this.position = position;
    }
    
    void changeName(final String name) {
        this.name = new CarName(name);
    }
}

불변 객체

모든 클래스를 상태를 변경할 수 없는 불변 클래스(immutable class)로 만들면 유지 보수성이 크게 향상된다.
불변 객체에는 아래의 ‘식별자 변경(identity mutability)’ 문제가 발생하지 않는다.
객체가 완전하고 견고한 상태이거나 아니면 아예 실패하는 실패 원자성(failure atomicity)을 가진다.
시간적 결합(temporal coupling)을 없앨 수 있다.
스레드 안정성
- 객체가 여러 스레드에서 동시에(concurrently) 사용될 수 있고 예측 가능한(predictable) 결과를 보장하는 객체의 품질
단순성(simplicity), 객체가 더 단순해질 수록 응집도는 더 높아지고, 유지보수는 더 쉬워진다.
불변 객체의 크기가 작은 이유는 불변 객체의 경우 생성자 안에서만 상태를 초기화할 수 있기 때문이다.

2. 전술적 설계 - AGGREGATE와 REPOSITORY

Aggregate

Bounded Context 내에서 Entity와 Value Object를 묶는 개념

관련 객체를 하나로 묶은 군집
애그리거트는 군집에 속한 객체들을 관리하는 루트 엔티티를 갖는다.
애그리거트로 묶어서 바라보면 좀 더 상위 수준에서 도메인 모델 간의 관계를 파악할 수 있다.
애그리거트에 속한 객체는 유사하거나 동일한 라이프사이클을 갖는다.
한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다.
두 개 이상의 엔티티로 구성되는 애그리거트는 드물게 존재한다.

AGGREGATE ROOT

다른 애그리거트와의 소통은 애그리거트 루트간에 메시지를 주고 받으며 이루어진다.

애그리거트 루트는 글로벌 ID를 가지고 애그리거트를 식별하는데 사용된다.

애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다.
애그리거트 루트는 애그리거트가 제공해야 할 도메인 기능을 구현한다.
이는 애그리거트의 내부 구현을 숨겨서 애그리거트 단위로 구현을 캡슐화할 수 있도록 돕는다.
루트 엔티티는 애그리거트에 속해 있는 엔티티와 밸류 객체를 이용해서 애그리거트가 구현해야 할 기능을 제공한다.

AGGREGATE 참조

애그리거트를 직접 참조할 때 발생할 수 있는 가장 큰 문제는 편리함을 오용할 수 있다.
ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다,
ID를 이용한 참조 방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 원천적으로 방지할 수 있다.

REPOSITORY

엔티티나 밸류가 요구사항에서 도출되는 도메인 모델이라면 리포지터리는 구현을 위한 도메인 모델
애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의한다.
애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공해야 한다.
리포지터리가 완전한 애그리거트를 제공하지 않으면, 필드나 값이 올바르지 않아 애그리거트의 기능을 실행하는 - 도중에 NullPointerException과 같은 문제가 발생하게 된다.
리포지토리는 애그리거트(루트) 단위로 존재하며 테이블 단위로 존재하는 것이 아니다.

3. 전술적 설계 - SERVICE

상품, 주문, 할인 쿠폰, 회원과 같이 여러 애그리거트를 활용해 결제 금액을 계산하는 로직은 어떤 애그리거트에 위치해야 할까?

도메인 서비스

한 애그리거트에 넣기 애매한 도메인 개념을 구현하려면 애그리거트에 억지로 넣기보다는 도메인 서비스를 이용해서 도메인 개념을 명시적으로 드러내면 된다.

응용 영역의 서비스가 용용 로직을 다룬다면 도메인 서비스는 도메인 로직을 다룬다.
도메인 영역의 애그리거트나 밸류와 같은 다른 구성요소와 비교할 때 다른 점은 상태 없이 로직만 구현한다.
서비스를 사용하는 주체는 애그리거트가 될 수도 있고 응용 서비스가 될 수도 있다.
애그리거트 메서드를 실행할 때 도메인 서비스를 인자로 전달하지 않고 반대로 도메인 서비스의 기능을 실행할 때 애그리거트를 전달하기도 한다.
특정 기능이 응용 서비스인지 도메인 서비스인지 감을 잡기 어려울 때는 해당 로직이 애그리거트의 상태를 변경하거나 애그리거트의 상태 값을 계산하는지 검사해 보면 된다.

FACTORY

어떤 객체를 생성하는 일이 복잡하다면 FACTORY를 이용해 이것을 캡슐화할 수 있다.
생성자, 팩토리 클래스
연관된 애그리거트에서 생성할 수 있다.
어떤 다른 곳에서 해당 객체를 생성할 때 생산자의 정보를 필요로 하는 것을 줄일 수 있다.
아울러 생산자와 생성된 객체 사이의 특별한 관계를 전해주기도 합니다.

출처

NEXTSTEP: DDD 세레나데 3기

[DDD] 2. 도메인 모델링

mandykr — Sat, 28 May 2022 09:56:25 +0900

1. 전략적 설계 - UBIQUITOUS LANGUAGE

2. 전략적 설계 - BOUNDED CONTEXT

3. 이벤트 스토밍(Event Storming)

1. 전략적 설계 - UBIQUITOUS LANGUAGE

유비쿼터스 언어(Ubiquitous Language)는 언제 어디서나 사용되는 언어란 뜻이다.

회의, 기획, 디자인, 개발 등 프로젝트 내부의 언제 어디서나 사용되기 위해 정의된 언어이다.

도메인에서 사용하는 용어를 프로젝트 내의 사람들이 모두 다르게 표현하면 번역 비용이 발생하고

코드에 사용된 언어와 다르거나 코드에 반영하지 않으면 그 코드는 개발자에게 코드의 의미를 해석해야 하는 부담을 준다.

따라서, 용어가 정의 될 때마다 용어 사전에 이를 기록하고 명확하게 정의 함으로써 추후 또는 다른 사람들도 공통된 언어를 사용할 수 있도록 한다.

코드의 가독성을 높여서 코드를 분석하고 이해하는 시간을 절약할 수 있고 사람들 사이에서 발생하는 번역 비용을 줄일 수 있다.

용어 사전

다음은 식당 포스기의 용어사전 예제이다. 참고

매장 주문

방문한 손님 수	number of guests	식기가 필요한 사람 수. 필수 사항은 아니며 주문은 0명으로 등록할 수 있다.
빈 테이블	empty table	주문을 등록할 수 없는 주문 테이블
서빙	served	조리가 완료되어 음식이 나갈 수 있는 단계
완료	completed	고객이 모든 식사를 마치고 결제를 완료한 단계
접수	accepted	주문을 받고 음식을 조리하는 단계
접수 대기	waiting	주문이 생성되어 매장으로 전달된 단계
주문	order	매장에서 식사하는 고객 대상. 손님들이 매장에서 먹을 수 있도록 조리된 음식을 가져다준다.
주문 상태	order status	주문이 생성되면 매장에서 주문을 접수하고 고객이 음식을 받기까지의 단계를 표시한다.
주문 테이블	order table	매장에서 주문이 발생하는 영역
주문 항목	order line item	주문에 속하는 수량이 있는 메뉴

도메인 모델링

용어 사전이 정의가 되었다면 용어 사전을 바탕으로 도메인을 모델링 한다.

표현해야 할 것을 더 쉽게 말하는 방법을 찾아낸 다음 그러한 새로운 아이디어를 다이어그램과 코드에 적용한다.

지속적으로 도메인을 탐색하며 풍부한 도메인 모델을 작성하도록 한다.

도메인 모델은 개발자가 애플리케이션을 개발하는데 밑거름이 된다.

매장 주문

OrderTable은 식별자와 이름, NumberOfGuests를 가진다.
OrderTable의 추가 Order는 OrderTable에 계속 쌓이며 모든 Order가 완료되면 EmptyTable이 된다.
EmptyTable인 경우 NumberOfGuests는 0이며 변경할 수 없다.
Order는 식별자와 OrderStatus, 주문 시간, OrderLineItems를 가진다.
메뉴가 노출되고 있으며 판매되는 메뉴 가격과 일치하면 Order가 생성된다.
Order는 접수 대기 ➜ 접수 ➜ 서빙 ➜ 계산 완료 순서로 진행된다.
OrderLineItem는 가격과 수량을 가진다.
OrderLineItem의 수량은 기존 Order를 취소하거나 변경해도 수정되지 않기 때문에 0보다 적을 수 있다.

모델링은 사업팀도 이해할 수 있도록 작성해야 한다.

개발 용어가 포함되지 않도록 작성한다.

클래스 다이어그램이 아닌 mermaid를 활용해 이해하기 쉽게 도식화 한다.

2. 전략적 설계 - BOUNDED CONTEXT

같은 모델에 대해 컨텍스트별로 바라보는 관점이 다르기 때문에 용어 사전 정의와 도메인 모델링은 컨텍스트 별로 이루어 져야 한다.

Sales Context 관점의 Customer: 상품을 구매하는 고객
Support Context 관점의 Customer: 상담을 요청하는 고객

Sales Context 에서는 고객의 생일 정보를 통해 생일 할인 이벤트를 적용해볼 수 있지만

Support Context 에서 고객의 생일 정보는 불필요할 수 있다.

하위 도메인마다 사용하는 용어가 다르기 때문에 올바른 도메인 모델을 개발하려면 하위 도메인마다 모델을 만들어야 한다.
모델은 특정한 컨텍스트(문맥)하에서 완전한 의미를 갖는다.
이렇게 구분되는 경계를 갖는 컨텍스트를 DDD에서는 BOUNDED CONTEXT라고 부른다.

좋은 BOUNDED CONTEXT

하나의 BOUNDED CONTEXT는 하나의 팀에만 할당되어야 한다.
하나의 팀은 여러 개의 BOUNDED CONTEXT를 다룰 수 있다.
각각의 BOUNDED CONTEXT는 각각의 개발 환경을 가질 수 있다.

CONTEXT MAP

컨텍스트 맵은 상호 교류하는 시스템의 목록을 제공하고, 팀 내 의사소통의 촉매 역할을 한다.

프로젝트와 조직 관계

파트너십(Partnership) : 두 CONTEXT가 하나의 트랜잭션으로 묶여 있다.
공유 커널(Shared kernel) : 상호 의존하는 공유 모델을 관리한다.
고객-공급자(Customer-Supplier Development) : 업스트림(서버:공급자), 다운스트림(클라이언트:고객)로 단방향으로 의존
한다.
순응주의자(Conformist) : 업스트림(서버)이 모든 것을 제어한다.
오픈 호스트 서비스(Open Host Service) : REST/API, RPC, Socket
분리된 방법(Seprate Ways) : 의존 없음
큰 진흙공(Big ball of mud) : 안티 패턴

DDD vs OOP

DDD는 OOP에 근간을 두고 있지만 ID를 사용한 간접참조, 값 객체의 사용 등은 OOP를 위반하는 내용일 수 있다.

OOP는 상속과 재사용성을 중요시하지만 DDD는 도메인의 분리를 중요시한다.

3. 이벤트 스토밍(Event Storming)

DDD 도입을 위해 이벤트 스토밍을 진행한다.

복잡한 비즈니스 도메인을 빠르게 탐색하고 학습할 수 있는 워크숍
도메인 전문가와 개발자를 학습 과정에 참여시키기 위한 빠른 설계
코드를 없애고 모든 사람을 동일한 수준으로 만드는 시각적 접근 방법

1단계: 혼란스러운 탐험

각자가 알고 있는 도메인 이벤트를 작서하도록 요청한다.

각자가 작성한 이벤트는 볼 수 있지만, 토론을 시작하지 말고 자신이 옳다고 생각하는 방식으로 기록한다.

도메인 이벤트 - 주황색

이벤트 전문가가 관심이 있는 어떤 사건
이벤트 이름은 과거에 일어났던 일을 표현하기 때문에 과거 시제를 사용한다.
이벤트가 발생한다는 것은 상태가 변경되었다는 것을 의미한다.

2단계: 타임라인 적용

모든 도메인 이벤트를 올바른 타임라인으로 정렬하고 실제로 중복되는 이벤트를 제거한다.

시간은 왼쪽에서 오른쪽으로 흐르고, 위에서 아래로 평행한 시간을 표현할 수 있다.

핫 스폿 - 자주색

2단계에서 발생한 갈등을 시각화하고 캡쳐하는 데 사용한다.
당장 토론하지 않는다. 나중에 문제가 해결되면 제거한다.

액터와 시스템 - 노란색과 분홍색

단순한 '사용자' 또는 '고객'보다 구체적인 페르소나를 설정한다.

외부 시스템으로부터 일부 레거시 및 마이크로 서비스에 이르기까지 책임을 전가할 수 있는 모든 것

바운디드 컨텍스트

같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다를 수 있다.

명백한 언어 불일치는 종종 동일한 프로세스 내에서 여러 개의 바운디드 컨텍스트를 나타내는 지표이다.

커멘드 또는 액션 - 파란색

시스템에서 일어나는 일
도메인 이벤트가 발생하는 원인

리드 모델 또는 정보 - 초록색

결정을 내리는데 필요한 정보

정책 - 연보라색

주로 `~할 때마다'라는 단어로 시작한다.
도메인 이벤트와 커멘드 사이에 위치한다.

에그리게잇 또는 비즈니스 규칙 - 연노란색

시스템이 기대하는 책임을 수행하는 일관성을 유지하는 단위
일관성은 항상 참이어야 하는 속성을 유지함으로써 달성된다.

자산화

Miro

이벤트 스토밍으로 얻을 수 있는 것

모두가 서로에게서 배운다.
모두가 서로 소통한다.
자신의 관점에서 문제를 발견하면 누구나 말할 수 있다.
모두가 문제를 해결하는 방법에 대한 자신의 아이디어를 제공한다.
워크숍 후에는 모두가 같은 사실을 알게된다.

출처

NEXTSTEP: DDD 세레나데 3기

[DDD] 1. 도메인 주도 설계 이해

mandykr — Fri, 27 May 2022 16:38:54 +0900

1. 본질적 복잡성

2. 도메인 주도 설계

3. 도메인 주도 설계 주의

1. 클린 아키텍처

비즈니스 규칙이 Java, Javascript, SQL 등에 분산되어 있고 심지어 기획자가 알고있는 비즈니스 규칙이 코드가 아닌 문서에만 운영 정책으로 작성되어 있다면 유지보수가 어려워지고 요구사항이 추가될 때마다 시스템의 복잡도는 점점 높아질 것이다.

예) 소수점 표현 정책이 Java, Javascript, SQL 에서 모두 다르다.

클린 아키텍처를 적용해 비즈니스 규칙을 한 곳에 모을 수 있다.

클린 아키텍처

클린 아키텍처는 계층을 분리하여 관심사를 분리하고 의존성 규칙을 통해 아키텍처가 동작하도록 한다.

의존성 규칙: 모든 소스코드 의존성은 반드시 외부에서 내부로, 고수준 정책을 향해야 한다.

즉, 업무의 업무 로직을 담당하는 코드들이 DB 또는 Web 같이 구체적인 세부 사항에 의존하지 않아야 한다.

이를 통해 업무 로직(고수준 정책)은 세부 사항들(저수준 정책)의 변경에 영향을 받지 않도록 할 수 있다.

출처: The Clean Architecture, https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

클린 아키텍처는 로버트 C. 마틴이 제안한 좋은 소프트웨어 아키텍처의 보편적인 원칙으로 다음과 같은 특징을 가지고 있다.

프레임워크 독립성	아키텍처는 다양한 기능의 라이브러리를 제공하는 소프트웨어, 즉 프레임워크의 존재 여부에 의존하지 않는다. 이를 통해 이러한 프레임워크를 도구로 사용할 수 있으며, 프레임워크가 지닌 제약사항 안으로 시스템을 욱여 넣도록 강제하지 않는다.
테스트 용이성	업무 규칙은 UI, 데이터베이스, 웹 서버, 또는 여타 외부 요소가 없이도 테스트할 수 있다.
UI 독립성	시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있다. 예를 들어 업무 규칙을 변경하지 않은 채 웹 UI를 콘솔 UI로 대체할 수 있다.
데이터베이스 독립성	오라클이나 MS SQL 서버를 몽고DB, 빅테이블, 카우치DB 등으로 교체할 수 있다. 업무 규칙은 데이터베이스에 결합되지 않는다.
모든 외부 에이전시에 대한 독립성	실제로 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못한다.

본질적 복잡성(essential complexity)과 우발적 복잡성(accidental complexity)

본질적 복잡성은 문제 자체에서 발생하며 문제의 범위를 줄이지 않고는 제거할 수 없다.

반면에 우발적 복잡성은 솔루션으로 인해 발생하며 프레임워크, 데이터베이스 또는 기타 인프라가 될 수 있다.

클린 아키텍처와 같은 개념으로 좋은 소프트웨어 아키텍처의 보편적인 원칙을 지키고 고수준인 규칙을 캡슐화하였다면

도메인 주도 설계는 본질적 복잡성을 낮추는 방법에 초점을 맞춰 시스템의 복잡성을 낮출수 있도록 한다.

2. 도메인 주도 설계

도메인

도메인은 소프트웨어로 해결하고자 하는 문제 영역이다.

쇼핑몰을 구축할 때 도메인은 전자 상거래이며, 사용자가 무엇에 대해 말하고 원하는지 이해하려면 전자 상거래에 대한 지식이 필요하다.

도메인 모델

도메인 모델은 특정 다이어그램이 아니라 다이어그램이 전달하려는 아이디어이자 목적을 가진 의사소통 수단이다. 이 의사소통 수단은 회의, 기획, 디자인, 개발에 사용되어야 한다.

항공권 예약 시스템에서는 항공기, 승객 등 물리적으로 존재하는 것들을 모델링할 수 있고, 회계 시스템에서는 화폐, 금융 등 물리적으로 존재하지 않는 것들을 모델링할 수 있다. 도메인 모델을 사용하면 여러 이해관계자가 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는 데 도움이 된다.

도메인 주도 설계

기획자가 생각하는 도메인 모델과 개발자가 생각하는 도메인 모델은 대부분 다르다.

개발자는 요구 사항을 기술 언어로 번역하고 솔루션에 집중해 문제를 숨기는 경향이 있다.

번역된 언어는 의사소통을 위해 언어를 다시 번역해야 하고 이 과정에서 많은 의사소통 비용이 낭비된다.

도메인 주도 설계는 도메인 모델의 적용 범위를 구현으로 확장하기 위해 도메인을 탐색하고 학습하기 위한 다양한 원칙과 패턴을 제안한다.

유비쿼터스 언어
전략적 설계
전술적 설계

3. 도메인 주도 설계 주의

경우에 따라 DDD 기술 규칙과 패턴이 DDD 구현에 방해가 될 수 있다.
중요한 것은 패턴 자체가 아니라 비즈니스 문제에 맞게 코드를 구성하고 동일한 비즈니스 용어(유비쿼터스 언어)를사용하는 것이다.
CRUD 서비스처럼 간단한 업무는 DDD가 아닌 더 간단한 방법으로 관리할 수 있다.
도메인 주도 설계는 완벽히 설계하고 그 다음 구현하는 방법을 의미하지 않는다. 설계와 구현을 병행하도록 한다.

출처

NEXTSTEP: DDD 세레나데 3기

[HTTP] 1. 인터넷 네트워크

mandykr — Sat, 30 Apr 2022 14:22:31 +0900

1. 인터넷 네트워크

2. URI와 웹 브라우저 요청 흐름

1. 인터넷 네트워크

1) IP 프로토콜

IP 프로토콜은 지정한 IP 주소(IP Address)를 이용해 패킷이라는 통신 단위로 데이터를 전달하는 역할을 한다.

출발지 IP 주소, 도착지 IP 주소, 전송 데이터 등을 IP 패킷에 포함해 전송
인터넷 노드를 거쳐 이동

IP 프로토콜의 한계

비연결성

클라이언트는 전송 대상 서버가 패킷을 받을 수 있는 상태인지 모르기 때문에

클라이언트에서는 패킷을 전송하고 서버는 도착하는 패킷을 받을 수 없다.

패킷 손실

전송 과정에서 네트워크상의 문제로 패킷이 손실될 수 있다.

패킷 전달 순서 문제 발생

용량이 큰 데이터는 여러개의 패킷으로 나눠서 전달하는데

패킷이 서로 다른 노드를 거쳐갈 수 있기 때문에 도착 순서가 변경될 수 있다.

2) TCP / UDP

인터넷 프로토콜 스택의 4계층

1. 프로그램이 Hello, world! 메시지 생성

2. SOCKET 라이브러리를 통해 전달

3. TCP 정보 생성, 메시지 데이터 포함

4. IP 패킷 생성, TCP 데이터 포함

1 ~ 4 과정을 거쳐 TCP/IP 패킷이 만들어진다.

3) TCP 특징

전송 제어 프로토콜(Transmission Control Protocol)

연결 지향

3 way handshake 방식을 사용해 클라이언트 서버간에 연결한다.

연결은 가상 연결이고 논리적으로만 연결된 것이지 실제 연결을 보장하는 것은 아니다.

데이터 전달 보증

데이터가 정상적으로 전달되었는지 응답을 받는다.

순서 보장

TCP 세그먼트의 전송 제어 정보를 참고해 도착 순서가 잘못된 경우

잘못된 순서의 패킷부터 다시 보내도록 클라이언트로 요청한다.

4) UDP 특징

사용자 데이터그램 프로토콜(User Datagram Protocol)

연결 지향 X
데이터 전달 보증 X
순서 보장 X
데이터 전달 및 순서가 보장되지 않지만 단순하고 빠름
IP와 거의 같다. (PORT, 체크섭 정도만 추가)
애플리케이션에서 추가 작업 필요

5) PORT

같은 IP 내에서 프로세스를 구분한다.

TCP/IP 패킷의 출발지와 도착지 PORT 정보를 사용한다.

0 ~ 65535 할당 가능
0 ~ 1023: 잘 알려진 포트, 사용하지 않는 것이 좋음
- FTP - 20, 21
- TELNET - 23
- HTTP - 80
- HTTPS - 443

6) DNS

도메인 네임 시스템(Domain Name System)

IP 정보는 기억하기 어렵고 변경될 수 있기 때문에

IP 주소를 도메인 명으로 매핑한다.

2. URI와 웹 브라우저 요청 흐름

1) URI

Uniform: 리소스 식별하는 통일된 방식

Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)

Identifier: 다른 항목과 구분하는데 필요한 정보

URI는 로케이터(Locator), 이름(Name) 또는 둘다 추가로 분류될 수 있다.

2) URL, URN

URL - Locator: 리소스가 있는 위치를 지정

URN - Name: 리소스에 이름을 부여

위치는 변할 수 있지만, 이름은 변하지 않는다.

예) urn:isbn:8960777331 : 특정 책의 isbn URN

3) URL

scheme://[userinfo@]host[:port][/path][?query][#fragment]

https://www.google.com:443/search?q=hello&hl=ko

프로토콜(https)
호스트명(www.google.com)
포트 번호(443)
패스(/search)
쿼리 파라미터(q=hello&hl=ko)

scheme (https)

주로 프로토콜 사용

프로토콜: 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙

예) http, https, ftp 등등

http는 80 포트, https는 443 포트를 주로 사용, 포트는 생략 가능

https는 http에 보안 추가 (HTTP Secure)

userinfo

URL에 사용자정보를 포함해서 인증

거의 사용하지 않음

host (www.google.com)

호스트명

도메인명 또는 IP 주소를 직접 사용가능

port (443)

접속 포트

일반적으로 생략, 생략시 http는 80, https는 443

path (search)

리소스 경로(path), 계층적 구조

예)

/home/file1.jpg
/members
/members/100, /items/iphone12

query (q=hello&hl=ko)

key=value 형태

?로 시작, &로 추가 가능 ?keyA=valueA&keyB=valueB

query parameter, query string 등으로 불림, 웹서버에 제공하는 파라미터, 문자 형태

fragment

예) https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html

#getting-started.introducing-spring-boot

html 내부 북마크 등에 사용
서버에 전송하는 정보 아님

4) 웹 브라우저 요청 흐름

HTTP 메시지 생성

1. DNS 서버에서 조회해 IP 주소를 얻어오고

2. HTTP PORT를 확인해

3. HTTP 요청 메시지를 생성한다.

HTTP 메시지 전송

1. 웹 브라우저가 HTTP 메시지 생성

2. SOCKET 라이브러리를 통해 전달

- A: TCP/IP 연결(IP, PORT, 3 way handshaking)

- B: 데이터 전달

3. TCP/IP 패킷 생성, HTTP 메시지 포함

HTTP 응답

구글 서버는 요청 패킷을 받아 분석하고

검색 엔진을 통해 리소스를 찾아 응답 메시지를 만든다.

웹 브라우저는 응답 패킷을 받아 HTML을 렌더링한다.

출처

https://zero-base.co.kr/category_dev_camp/cleancode_1book

[JPA] 8. JPQL(2)

mandykr — Thu, 14 Apr 2022 16:38:38 +0900

1. 경로 표현식

2. 페치 조인

3. 다형성 쿼리

4. 엔티티 직접 사용

5. Named 쿼리

6. 벌크 연산

1. 경로 표현식

경로 표현식은 .(점)을 찍어 객체 그래프를 탐색하는 것이다.

select m.username -> 상태 필드
 from Member m
 join m.team t -> 단일 값 연관 필드
 join m.orders o -> 컬렉션 값 연관 필드
where t.name = '팀A'

상태 필드(state field)

단순히 값을 저장하기 위한 필드(ex: m.username)

select m.name, m.age from Member m

연관 필드(association field)

연관관계를 위한 필드

단일 값 연관 필드: @ManyToOne, @OneToOne, 대상이 엔티티(ex: m.team)
컬렉션 값 연관 필드: @OneToMany, @ManyToMany, 대상이 컬렉션(ex: m.orders)

단일 값 연관 경로

묵시적 내부 조인 발생, team.name 탐색 O

select m.team.name from Member m

컬렉션 값 연관 경로

묵시적 내부 조인 발생, t.members.name과 같이 탐색 X

select t.members from Team t

FROM 절에서 명시적 조인을 통해 별칭을 얻으면 별칭을 통 해 탐색 가능하다.

select m.name from Team t join t.members m

묵시적 조인 주의사항

가급적 묵시적 조인 대신 명시적 조인 사용

조인은 SQL 튜닝에 중요 포인트

묵시적 조인은 조인이 일어나는 상황을 한눈에 파악하기 어려움

JPQL과 SQL의 형태를 최대한 맞춰 명시적 조인을 사용하자.

2. 페치 조인(fetch join)

SQL 조인의 종류가 아니며 JPQL에서 성능 최적화를 위해 제공하는 기능

연관된 엔티티나 컬렉션을 SQL 한번에 함께 조회

join fetch 명령어 사용

String jpql = "select m from Member m join fetch m.team";
List<Member> resultList = em.createQuery(jpql, Member.class)
        .getResultList();

for (Member member : resultList) {
    System.out.println("username = " + member.getName() + "," +
            " teamName = " + member.getTeam().getName());
}

일반 조인

( select 절에서 m.team을 조회하지 않는 경우 )

select m from Member m join m.team

조회하는 시점에 Team의 프록시가 영속성 컨텍스트에 담기고

즉시 로딩인 경우 Member를 조회한 후 Team을 조회하는 쿼리가 실행되고

지연 로딩인 경우 실제 Team의 데이터를 사용하는 시점에 조회 쿼리가 실행된다.

[즉시 로딩]

[지연 로딩]

회원의 소속 팀이 모두 다른 경우 조회되는 Member 수 만큼 Team을 조회하는 쿼리가 실행되기 때문에

지연로딩, 즉시로딩 모두 N + 1 문제가 발생한다.

페치 조인

페치 조인은 엔티티에 직접 적용하는 글로벌 로딩 전략보다 우선하다.

( @OneToMany(fetch = FetchType.LAZY) // 글로벌 로딩 전략 )

select m from Member m join fetch m.team

조회하는 시점에 Team의 프록시가 아닌 실제 엔티티가 영속성 컨텍스트에 담긴다.

컬렉션 페치 조인

Team과 Member를 DB에서 일대다 조인하면 Member의 수 만큼 Team이 중복되어 조회된다.

팀A에 회원1과 회원2가 소속되어 있을 때 팀A에 해당하는 데이터가 2개의 row로 조회된다.

[SQL]
SELECT M.*, T.* FROM MEMBER M
INNER JOIN TEAM T ON M.TEAM_ID=T.ID

JPQL도 마찬가지로 같은 객체이지만 팀A의 참조값이 페치 조인 결과 리스트에 중복되어 저장된다.

String jpql = "select t from Team t join fetch t.members where t.name = '팀A'";
List<Team> resultList = em.createQuery(jpql, Team.class)
        .getResultList();

for(Team team : resultList) {
    System.out.println("teamname = " + team.getName() + ", team = " + team);
    for (Member member : team.getMembers()) {
        System.out.println("-> username = " + member.getName()+ ", member = " + member);
    }
}

페치 조인과 DISTINCT

SQL 상에서 DISTINCT는 서로 다른 row이기 때문에 중복이 제거되지 않고

JPQL 상에서 DISTINCT는 JPA가 중복되는(같은 식별자를 가진) 엔티티를 제거해준다.

select distinct t from Team t join fetch t.members where t.name = '팀A'

페치 조인과 일반 조인의 차이

JPQL은 결과를 반환할 때 연관관계를 고려하지 않고 SELECT 절에 지정한 엔티티만 조회할 뿐이다.

페치 조인은 연관된 엔티티도 함께 조회한다. 객체 그래프를 SQL 한번에 조회하는 개념.

( N + 1 문제를 페치 조인으로 해결 )

페치 조인의 한계

페치 조인 대상에는 별칭을 줄 수 없다.

select t from Team t join fetch t.members m where m.age > 10

둘 이상의 컬렉션은 페치 조인 할 수 없다.

컬렉션을 페치 조인하면 페이징 API(setFirstResult, setMaxResults)를 사용할 수 없다.

일대다는 데이터 중복으로 row 수가 증가하기 때문에 페이징할 수 없다.

하이버네이트는 경고 로그를 남기고 실제 메모리에서 페이징한다.(매우 위험)

다대일, 일대일 조인으로 변경해서 해결해야 한다.

페치 조인의 특징

연관된 엔티티들을 SQL 한 번으로 조회
N + 1 문제를 해결해 성능 최적화
실무에서 글로벌 로딩 전략은 모두 지연 로딩
최적화가 필요한 곳은 페치 조인 적용

정리

페치 조인은 객체 그래프를 유지할 때 사용하면 효과적이다.

select m from Member m join fetch m.team

여러 테이블을 조인해서 인티티가 가진 모양이 아닌 전혀 다른 결과를 내야 하면

페치 조인 보다는 일반 조인을 사용하고 필요한 데이터들만 조회해서 DTO로 반환하는 것이 효과적이다.

select m, t from Member m join m.team t

3. 다형성 쿼리

Type

조회 대상을 특정 자식으로 한정

예) Item 중에 Book, Movie를 조회해라

[JPQL]
select i from Item i
where type(i) IN (Book, Movie)

[SQL]
select i from i
where i.DTYPE in (‘B’, ‘M’)

TREAT(JPA 2.1)

예) 부모인 Item과 자식 Book이 있다.

[JPQL]
select i from Item i
where treat(i as Book).auther = ‘kim’

[SQL]
select i.* from Item i
where i.DTYPE = ‘B’ and i.auther = ‘kim’

4. 엔티티 직접 사용

기본 키 값

JPQL에서 엔티티를 직접 사용하면 SQL에서 해당 엔티티의 기본 키 값을 사용한다.

[JPQL]
select count(m.id) from Member m //엔티티의 아이디를 사용
select count(m) from Member m //엔티티를 직접 사용

[SQL]
select count(m.id) as cnt from Member m

파라미터로 전달하는 경우도 마찬가지로 기본 키 값을 사용한다.

[JPQL]
select m from Member m where m.id = :memberId
select m from Member m where m = :member

[SQL]
select m.* from Member m where m.id=?

외래 키 값

연관된 엔티티를 직접 사용하거나 연관된 엔티티의 기본 키 값을 사용해도 SQL에서는 외래 키 값을 사용한다.

[JPQL]
select m from Member m where m.team.id = :teamId
select m from Member m where m.team = :team

[SQL]
select m.* from Member m where m.team_id=?

5. Named 쿼리

미리 정의해서 이름을 부여해 두고 사용하는 JPQL

@Entity
@NamedQuery(
        name = "Member.findByUsername",
        query="select m from Member m where m.name = :username")
public class Member {

List<Member> resultList = em.createNamedQuery("Member.findByUsername", Member.class)
        .setParameter("username", "회원1")
        .getResultList();

for (Member member : resultList) {
    System.out.println("username = " + member);
}

애플리케이션 로딩 시점에 Named 쿼리를 SQL로 파싱하기 때문에 사전에 쿼리에 대한 검증이 가능하다.

Spring Data JPA의 @Query 어노테이션을 사용할 때 Named 쿼리로 등록된다.

public interface UserRepository extends JpaRepository<User, Long> {

  @Query("select u from User u where u.emailAddress = ?1")
  User findByEmailAddress(String emailAddress);
}

6. 벌크 연산

JPA 변경 감지 기능으로 실행하려면 너무 많은 SQL이 실행되는 경우

쿼리 한 번으로 여러 테이블의 로우를 변경하기 위해 벌크 연산을 사용한다.

예) 재고가 10개 미만인 모든 상품의 가격을 10% 상승하려면?

1. 재고가 10개 미만인 상품을 리스트로 조회한다.

2. 상품 엔티티의 가격을 10% 증가한다.

3. 트랜잭션 커밋 시점에 변경감지가 동작한다.

변경 감지를 이용하면 변경된 데이터가 100건이라면 100번의 UPDATE SQL 실행

벌크 연산

int resultCount = em.createQuery("update Member m set m.age = 20")
                .executeUpdate();

executeUpdate()의 결과는 영향받은 엔티티 수 반환
UPDATE, DELETE 지원
INSERT(insert into .. select, 하이버네이트 지원)

벌크 연산 주의

벌크 연산은 영속성 컨텍스트를 무시하고 데이터베이스에 직접 쿼리한다.

영속성 컨텍스트의 엔티티와 벌크 연산으로 변경된 엔티티의 필드 값이 다른 경우 문제가 발생한다.

em.persist(memberA);

int resultCount = em.createQuery("update Member m set m.age = 20")
        .executeUpdate();

// em.clear();

Member findMemberA = em.find(Member.class, memberA.getId());
System.out.println("memberA.age = " + findMemberA.getAge());

JPQL이 실행될 때 영속성 컨텍스트에 저장된 SQL은 함께 flush 되어 나가기 때문에 문제가 없지만

영속성 컨텍스트의 memberA 나이와 벌크 연산으로 수정된 memberA 나이가 달라지는 경우

벌크 연산 이 후 memberA를 조회하면 1차 캐시에서 조회하기 때문에 변경되기 전의 나이가 조회된다.

따라서 영속성 컨텍스트에 엔티티를 영속화 하기 전에 벌크 연산을 먼저 실행하거나

벌크 연산 수행 후 영속성 컨텍스트를 초기화 해주어야 한다.

Spring Data JPA에서는 @Modifying의 clearAutomatically 옵션을 통해 영속성 컨텍스트를 초기화 할 수 있다.

clearAutomatically의 기본값은 false이고 true로 설정해 주어야 한다.

package org.springframework.data.jpa.repository;

@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.METHOD, ElementType.ANNOTATION_TYPE })
@Documented
public @interface Modifying {
	boolean flushAutomatically() default false;
	boolean clearAutomatically() default false;
}

@Modifying(clearAutomatically = true)
@Query("update User u set u.firstname = ?1 where u.lastname = ?2")
int setFixedFirstnameFor(String firstname, String lastname);

출처

https://www.inflearn.com/course/ORM-JPA-Basic 자바 ORM 표준 JPA 프로그래밍 - 기본편(김영한)

[Spring] 3. 스프링 빈

mandykr — Wed, 13 Apr 2022 16:53:12 +0900

1. 빈 생명주기 콜백

2. 빈 생명주기 콜백 사용 방법

3. 빈 스코프

4. 웹 스코프

1. 빈 생명주기 콜백

데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고,
애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면,

객체의 초기화와 종료 작업이 필요하다.

예제로 이 NetworkClient 는 애플리케이션 시작 시점에 connect() 를 호출해서 연결을 맺어두어야 하고,

애플리케이션이 종료되면 disConnect() 를 호출해서 연결을 끊어야 한다.

public class NetworkClient {

    private String url;
    
    public NetworkClient() {
        System.out.println("생성자 호출, url = " + url);
        connect();
        call("초기화 연결 메시지");
    }
    
    public void setUrl(String url) {
        this.url = url;
    }
    
    //서비스 시작시 호출
    public void connect() {
        System.out.println("connect: " + url);
    }
    
    public void call(String message) {
        System.out.println("call: " + url + " message = " + message);
    }
    
    //서비스 종료시 호출
    public void disconnect() {
        System.out.println("close: " + url);
    }
}

객체의 생성과 초기화를 분리

생성자는 필수 정보(파라미터)를 받고, 메모리를 할당해서 객체를 생성하는 책임을 가진다.

반면에 초기화는 이렇게 생성된 값들을 활용해서 외부 커넥션을 연결하는등 무거운 동작을 수행한다.

@Configuration
class LifeCycleConfig {

    @Bean
    public NetworkClient networkClient() {
        NetworkClient networkClient = new NetworkClient("http://hello-spring.dev");
        return networkClient;
    }
}

NetworkClient를 스프링 빈으로 등록할 때

위와 같이 생성자 안에서 무거운 초기화 작업을 함께 하는 것 보다는

객체를 생성하는 부분과 초기화 하는 부분을 명확하게 나누는 것이 유지보수 관점에서 좋다.

NetworkClient networkClient = new NetworkClient();
networkClient.setUrl("http://hello-spring.dev");

물론 초기화 작업이 내부 값들만 약간 변경하는 정도로 단순한 경우에는 생성자에서 한번에 다 처리하는게 더 나을 수 있다.

빈 생명주기 콜백

객체의 생성과 초기화 부분을 분리하였을 때 스프링 빈의 라이프 사이클은 (생성자 주입 이외)

객체 생성 -> 의존관계 주입 순서이기 때문에 객체의 초기화 작업이 모두 완료되기 전,

객체 생성 단계(NetworkClient 생성자 호출)에서는 url 정보를 알 수 없다.

따라서 객체의 초기화가 완료된 시점을 알아야 url 정보가 초기화된 NetworkClient의 connect() 를 호출할 수 있다.

스프링은 의존관계 주입이 완료되면

스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다.

또한 스프링은 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 준다.

따라서 안전하게 종료 작업을 진행할 수 있다.

스프링 빈의 이벤트 라이프 사이클

스프링 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 -> 사용 -> 소멸전 콜백 -> 스프링 종료

초기화 콜백: 빈이 생성되고, 빈의 의존관계 주입이 완료된 후 호출
소멸전 콜백: 빈이 소멸되기 직전에 호출

2. 빈 생명주기 콜백 사용 방법

스프링은 크게 3가지 방법으로 빈 생명주기 콜백을 지원한다

인터페이스(InitializingBean, DisposableBean)
설정 정보에 초기화 메서드, 종료 메서드 지정
@PostConstruct, @PreDestroy 애노테이션 지원

1) 인터페이스(InitializingBean, DisposableBean)

InitializingBean : afterPropertiesSet() 메서드로 초기화를 지원한다.

DisposableBean : destroy() 메서드로 소멸을 지원한다

public class NetworkClient implements InitializingBean, DisposableBean {
    //...   
    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("NetworkClient.afterPropertiesSet");
        connect();
        call("초기화 연결 메시지");
    }
    
    @Override
    public void destroy() throws Exception {
        System.out.println("NetworkClient.destroy");
        disConnect();
    }  
}

[ 결과 ]

객체 초기화가 완료된 시점에 afterPropertiesSet()가 호출되었고

스프링 컨테이너의 종료가 호출되자 destroy() 소멸 메서드가 호출되었다.

단점

이 인터페이스는 스프링 전용 인터페이스다. 해당 코드가 스프링 전용 인터페이스에 의존한다.
초기화, 소멸 메서드의 이름을 변경할 수 없다.
내가 코드를 고칠 수 없는 외부 라이브러리에 적용할 수 없다.

인터페이스를 사용하는 초기화, 종료 방법은 스프링 초창기에 나온 방법들이고,

지금은 다음의 더 나은 방법들이 있어서 거의 사용하지 않는다

2) 설정 정보에 초기화 메서드, 종료 메서드 지정

설정 정보에 @Bean(initMethod = "init", destroyMethod = "close") 처럼 초기화, 소멸 메서드를 지정할 수 있다.

@Configuration
static class LifeCycleConfig {

    @Bean(initMethod = "init", destroyMethod = "close")
    public NetworkClient networkClient() {
        NetworkClient networkClient = new NetworkClient();
        networkClient.setUrl("http://hello-spring.dev");
        return networkClient;
    }
}

public class NetworkClient {
	//...
    public void init() {
        // 의존관계 주입후
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메세지");

    }

    public void close() {
        // 빈이 종료될 때
        System.out.println("NetworkClient.close");
        disconnect();
    }
}

특징

메서드 이름을 자유롭게 줄 수 있다.
스프링 빈이 스프링 코드에 의존하지 않는다.
코드가 아니라 설정 정보를 사용하기 때문에 코드를 고칠 수 없는 외부 라이브러리에도 초기화, 종료메서드를 적용할 수 있다.

종료 메서드 추론

@Bean의 destroyMethod 는 기본값이 (inferred) (추론)으로 등록되어 있다.

이 추론 기능은 close , shutdown 라는 이름의 메서드를 자동으로 호출해준다.

이름 그대로 종료 메서드를 추론해서 호출해준다.

3) @PostConstruct, @PreDestroy 애노테이션 지원

@PostConstruct , @PreDestroy 이 두 애노테이션을 사용하면 가장 편리하게 초기화와 종료를 실행할 수 있다.

public class NetworkClient {
	//...
    @PostConstruct
    public void init() {
        // 의존관계 주입후
        System.out.println("NetworkClient.init");
        connect();
        call("초기화 연결 메세지");

    }

    @PreDestroy
    public void close() {
        // 빈이 종료될 때
        System.out.println("NetworkClient.close");
        disconnect();
    }
}

특징

최신 스프링에서 가장 권장하는 방법이다.
패키지를 보면 javax.annotation.PostConstruct 이다. 스프링에 종속적인 기술이 아니라 JSR-250 라는 자바 표준이다. 따라서 스프링이 아닌 다른 컨테이너에서도 동작한다.
컴포넌트 스캔과 잘 어울린다.

단점

유일한 단점은 외부 라이브러리에는 적용하지 못한다는 것이다.

외부 라이브러리를 초기화, 종료 해야 하면 @Bean의 기능을 사용하자.

정리

@PostConstruct, @PreDestroy 애노테이션을 사용하자
코드를 고칠 수 없는 외부 라이브러리를 초기화, 종료해야 하면 @Bean 의 initMethod , destroyMethod 를 사용하자.

3. 빈 스코프

빈 스코프는 스프링 빈이 존재할 수 있는 범위를 뜻한다.

스프링 빈은 기본적으로 싱글톤 스코프로 생성된다.

빈 스코프 종류

싱글톤

기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.

프로토타입

스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고

더는 관리하지 않는 매우 짧은 범위의 스코프이다

웹 관련 스코프

request: 웹 요청이 들어오고 나갈때 까지 유지되는 스코프이다.
session: 웹 세션이 생성되고 종료될 때 까지 유지되는 스코프이다.
application: 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프이다.

1) 싱글톤

싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환한다.

1. 싱글톤 스코프의 빈을 스프링 컨테이너에 요청한다.

2. 스프링 컨테이너는 본인이 관리하는 스프링 빈을 반환한다.

3. 이후에 스프링 컨테이너에 같은 요청이 와도 같은 객체 인스턴스의 스프링 빈을 반환한다.

[ 예제 ]

class SingletonTest {

  @Test
  void singletonBeanFind() {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SingletonBean.class);

    SingletonBean singletonBean1 = ac.getBean(SingletonBean.class);
    SingletonBean singletonBean2 = ac.getBean(SingletonBean.class);
    System.out.println("singletonBean1 = " + singletonBean1);
    System.out.println("singletonBean2 = " + singletonBean2);

    assertThat(singletonBean1).isSameAs(singletonBean2);

    ac.close();

  }

  static class SingletonBean {

    @PostConstruct
    public void init() {
      System.out.println("SingletonBean.init");
    }

    @PreDestroy
    public void destroy() {
      System.out.println("SingletonBean.destroy");
    }
  }

}

빈 초기화 메서드를 실행
같은 인스턴스의 빈을 조회
종료 메서드까지 정상 호출

참고

new AnnotationConfigApplicationContext(SingletonBean.class);

ApplicationContext 를 생성할 때 파라미터로 빈으로 등록할 클래스를 전달하면

@Component 필요 없이 컨포넌트 스캔 대상이 된다.

2) 프로토타입 스코프

프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다.

1. 프로토타입 스코프의 빈을 스프링 컨테이너에 요청한다.

2. 스프링 컨테이너는 이 시점에 프로토타입 빈을 생성하고, 필요한 의존관계를 주입한다.

3. 스프링 컨테이너는 생성한 프로토타입 빈을 클라이언트에 반환한다.

4. 이후에 스프링 컨테이너에 같은 요청이 오면 항상 새로운 프로토타입 빈을 생성해서 반환한다.

[ 예제 ]

class PrototypeTest {

  @Test
  void prototypeBeanFind() {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(PrototypeBean.class);
    PrototypeBean prototypeBean1 = ac.getBean(PrototypeBean.class);
    PrototypeBean prototypeBean2 = ac.getBean(PrototypeBean.class);
    System.out.println("prototypeBean1 = " + prototypeBean1);
    System.out.println("prototypeBean2 = " + prototypeBean2);
    
    assertThat(prototypeBean1).isNotSameAs(prototypeBean2);

    ac.close();

  }

  @Scope("prototype")
  static class PrototypeBean {

    @PostConstruct
    void init() {
      System.out.println("PrototypeBean.init");
    }

    @PreDestroy
    void destroy() {
      System.out.println("SingletonBean.destroy");
    }

  }

}

스프링 컨테이너에 요청할 때 마다 새로 생성된다.
스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입 그리고 초기화까지만 관여한다.
종료 메서드가 호출되지 않는다.
그래서 프로토타입 빈은 프로토타입 빈을 조회한 클라이언트가 관리해야 한다.
종료 메서드에 대한 호출도 클라이언트가 직접 해야한다.

3) 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 문제점

싱글톤 빈(ClientBean)에서 프로토타입 스코프 빈(PrototypeBean)을 참조해 사용하는 예제이다.

class SingletonWithPrototypeTest1 {

  @Test
  void singletonClientUsePrototype() {
    ApplicationContext ac = new AnnotationConfigApplicationContext(ClientBean.class, PrototypeBean.class);
    ClientBean clientBean1 = ac.getBean(ClientBean.class);
    int count1 = clientBean1.logic();
    assertThat(count1).isEqualTo(1);

    ClientBean clientBean2 = ac.getBean(ClientBean.class);
    int count2 = clientBean2.logic();
    assertThat(count2).isEqualTo(2);
  }

  static class ClientBean {
    private final PrototypeBean prototypeBean; // 생성시점에 주입

    ClientBean(PrototypeBean prototypeBean) {
      this.prototypeBean = prototypeBean;
    }

    public int logic() {
      prototypeBean.addCount();
      return prototypeBean.getCount();
    }
  }

  @Scope("prototype")
  static class PrototypeBean {
    private int count = 0;

    public void addCount() {
      count++;
    }

    public int getCount() {
      return count;
    }

    @PostConstruct
    public void init() {
      System.out.println("PrototypeBean.init " + this);
    }

    @PreDestroy
    public void destroy() {
      System.out.println("PrototypeBean.destroy " + this);
    }

  }
}

clientBean 은 싱글톤이므로, 보통 스프링 컨테이너 생성 시점에 함께 생성되고, 의존관계 주입도 발생한다.

1. clientBean 은 의존관계 자동 주입을 사용한다. 주입 시점에 스프링 컨테이너에 프로토타입 빈을 요청한다.
2. 스프링 컨테이너는 프로토타입 빈을 생성해서 clientBean 에 반환한다. 프로토타입 빈의 count 필드 값은 0이다.이제 clientBean 은 프로토타입 빈을 내부 필드에 보관한다. (정확히는 참조값을 보관한다.)

클라이언트 A는 clientBean 을 스프링 컨테이너에 요청해서 받는다.싱글톤이므로 항상 같은 clientBean 이 반환된다.

3. 클라이언트 A는 clientBean.logic() 을 호출한다.
4. clientBean 은 prototypeBean의 addCount() 를 호출해서 프로토타입 빈의 count를 증가한다.
count값이 1이 된다

클라이언트 B는 clientBean 을 스프링 컨테이너에 요청해서 받는다.

싱글톤이므로 항상 같은 clientBean 이 반환된다.

clientBean이 내부에 가지고 있는 프로토타입 빈은 이미 과거에 주입이 끝난 빈이다.

주입 시점에 스프링 컨테이너에 요청해서 프로토타입 빈이 새로 생성이 된 것이지,

사용 할 때마다 새로 생성되는 것이 아니다!

5. 클라이언트 B는 clientBean.logic() 을 호출한다.
6. clientBean 은 prototypeBean의 addCount() 를 호출해서 프로토타입 빈의 count를 증가한다.
원래 count 값이 1이었으므로 2가 된다.

[ 문제점 ]

싱글톤 빈이 프로토타입 빈을 사용할 때마다 프로토타입 빈을 새로 생성해서 사용하고자 했지만

싱글톤 빈은 생성 시점에만 의존관계 주입을 받고 의존관계 주입 시점에만 프로토타입 빈이 새로 생성되어

싱글톤 빈과 함께 계속 유지되는 문제가 발생한다.

4) 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결

Dependency Lookup(DL)

의존관계를 외부에서 주입(DI) 받는게 아니라 직접 필요한 의존관계를 찾는 것을 의존관계 조회(탐색)(DL) 이라한다.

싱글톤 빈이 프로토타입 빈을 사용할 때마다 프로토타입 빈을 새로 생성하려면

DL 방식을 사용해 스프링 컨테이너에서 프로토타입 빈을 꺼내오면 된다.

(1) ObjectFactory, ObjectProvider

static class ClientBean {
    @Autowired
    private ObjectProvider<PrototypeBean> prototypeBeanProvider;

    public int logic() {
        PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
        prototypeBean.addCount();
        int count = prototypeBean.getCount();
        return count;
    }
}

스프링의 애클리케이션 컨텍스트를 주입받아 PrototypeBean을 받아올 수 있지만

ObjectFactory, ObjectProvider를 사용하면 지정한 프로토타입 빈만을 컨테이너에서 찾아주는 DL 정도의 기능만 사용할 수 있다.

ObjectFactory: 기능이 단순, 별도의 라이브러리 필요 없음, 스프링에 의존
ObjectProvider: ObjectFactory 상속, 옵션, 스트림 처리등 편의 기능이 많고, 별도의 라이브러리 필요 없음, 스프링에 의존

(2) JSR-330 Provider

static class ClientBean {
    @Autowired
    private Provider<PrototypeBean> provider;
    public int logic() {
        PrototypeBean prototypeBean = provider.get();
        prototypeBean.addCount();
        int count = prototypeBean.getCount();
        return count;
    }
}

스프링에 의존하지 않고 DL을 사용하려면 javax.inject.Provider 라는 JSR-330 자바 표준을 사용할 수 있다.

이 방법을 사용하려면 javax.inject:javax.inject:1 라이브러리를 gradle에 추가해야 한다.

implementation 'javax.inject:javax.inject:1'

정리

실무에서 웹 애플리케이션을 개발해보면, 싱글톤 빈으로 대부분의 문제를 해결할 수 있기 때문에 프로토타입 빈을 직접적으로 사용하는 일은 매우 드물다.
ObjectProvider , JSR330 Provider 등은 프로토타입 뿐만 아니라 DL이 필요한 경우는 언제든지 사용할 수 있다.

ObjectProvider vs JSR-330 Provider

스프링을 사용하다 보면 이 기능 뿐만 아니라 다른 기능들도 자바 표준과 스프링이 제공하는 기능이 겹칠때가 많이 있다. 대부분 스프링이 더 다양하고 편리한 기능을 제공해주기 때문에, 특별히 다른 컨테이너를 사용할 일이 없다면, 스프링이 제공하는 기능을 사용하면 된다.

4. 웹 스코프

웹 스코프는 웹 환경에서만 동작한다.

웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리한다.

따라서 종료 메서드가 호출된다.

웹 스코프 종류

request: HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프, 각각의 HTTP 요청마다 별도의 빈
인스턴스가 생성되고, 관리된다.
session: HTTP Session과 동일한 생명주기를 가지는 스코프
application: 서블릿 컨텍스트( ServletContext )와 동일한 생명주기를 가지는 스코프
websocket: 웹 소켓과 동일한 생명주기를 가지는 스코프

request 스코프

웹 스코프는 웹 환경에서만 동작하므로 web 환경이 동작하도록 라이브러리를 추가해야 한다.

implementation 'org.springframework.boot:spring-boot-starter-web'

@Component
@Scope(value = "request")
public class MyLogger {
    
    private String uuid;
    private String requestURL;

    public void setRequestURL(String requestURL) {
        this.requestURL = requestURL;
    }

    public void log(String message) {
        System.out.println("[" + uuid + "]" + "[" + requestURL + "] " +
                message);
    }

    @PostConstruct
    public void init() {
        uuid = UUID.randomUUID().toString();
        System.out.println("[" + uuid + "] request scope bean create:" + this);
    }

    @PreDestroy
    public void close() {
        System.out.println("[" + uuid + "] request scope bean close:" + this);
    }
}

@Controller
@RequiredArgsConstructor
public class LogDemoController {
    private final LogDemoService logDemoService;
    private final ObjectProvider<MyLogger> myLoggerProvider;

    @RequestMapping("log-demo")
    @ResponseBody
    public String logDemo(HttpServletRequest request) {
        String requestURL = request.getRequestURL().toString();
        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.setRequestURL(requestURL);
        myLogger.log("controller test");
        logDemoService.logic("testId");
        return "OK";
    }
}

@Service
@RequiredArgsConstructor
public class LogDemoService {    
    private final ObjectProvider<MyLogger> myLoggerProvider;
    
    public void logic(String id) {
        MyLogger myLogger = myLoggerProvider.getObject();
        myLogger.log("service id = " + id);
    }
}

MyLogger 클래스를 request 스코프로 지정했다.

이 빈은 HTTP 요청 하나씩 생성되고 HTTP 요청이 끝나는 시점에 소멸된다.

LogDemoController와 LogDemoService는 싱글톤 빈이고 애플리케이션이 실행되는 시점에

싱글톤 빈은 생성해서 주입이 가능하지만, request 스코프 빈은 고객의 요청이 와야 생성된다.

ObjectProvider를 이용해서 ObjectProvider.getObject() 를 호출하는 시점까지 request scope 빈을 애플리케이션 컨텍스트에서 조회하는 처리를 지연할 수 있다.

ObjectProvider.getObject() 를 호출하시는 시점에는 HTTP 요청이 진행중이므로 request scope 빈의 생성이 정상 처리된다.

request 스코프 빈은 HTTP 요청마다 하나의 인스턴스를 생성되고 관리된다.

따라서 같은 HTTP요청(같은 UUID)이면 같은 스프링 빈이 반환된다.

스코프와 프록시

MyLogger의 가짜 프록시 클래스를 만들어두고 HTTP request와 상관 없이 가짜 프록시 클래스를 다른 빈에 미리 주입해 둘 수 있다.

@Component
@Scope(value = "request", proxyMode = ScopedProxyMode.TARGET_CLASS)
public class MyLogger {
}

myLogger = class hello.core.common.MyLogger$$EnhancerBySpringCGLIB$$b68b726d

@Scope 의 proxyMode = ScopedProxyMode.TARGET_CLASS) 를 설정하면

스프링 컨테이너는 CGLIB 라는 바이트코 를 조작하는 라이브러리를 사용해서,

MyLogger를 상속받은 가짜 프록시 객체 생성한다.

CGLIB라는 라이브러리로 내 클래스를 상속 받은 가짜 프록시 객체를 만들어서 주입한다.
이 가짜 프록시 객체는 실제 요청이 오면 그때 내부에서 실제 빈을 요청하는 위임 로직이 들어있다.
가짜 프록시 객체는 실제 request scope와는 관계가 없다. 그냥 가짜이고, 내부에 단순한 위임 로직만
있고, 싱글톤 처럼 동작한다.

정리

Provider를 사용하든, 프록시를 사용하든 핵심 아이디어는 진짜 객체 조회를 꼭 필요한 시점까지 지연처리 한다는 점이다.
단지 애노테이션 설정 변경만으로 원본 객체를 프록시 객체로 대체할 수 있다.
이것이 바로 다형성과 DI 컨테이너가 가진 큰 강점이다.
꼭 웹 스코프가 아니어도 프록시는 사용할 수 있다.

주의점

싱글톤을 사용하는 것 같지만 다르게 동작하기 때문에 결국 주의해서 사용해야 한다.
이런 특별한 scope는 꼭 필요한 곳에만 최소화해서 사용하자, 무분별하게 사용하면 유지보수하기 어려워진다.

출처

스프링 핵심 원리 - 기본편(김영한)

[JPA] 8. JPQL(1)

mandykr — Tue, 29 Mar 2022 13:22:20 +0900

1. JPQL

2. 기본 문법과 쿼리 API

3. 프로젝션

4. 페이징

5. 조인

6. 서브 쿼리

7. JPQL 타입 표현

8. 조건식 - CASE 식

9. JPQL 함수

1. JPQL

JPA를 사용하면 엔티티 객체를 중심으로 개발을 진행하는데

EntityManager.find()나 객체 그래프 탐색(a.get())으로 조회가 어려운

검색 쿼리를 작성할 때 JPQL을 사용한다.

String jpql = "select m From Member m where m.name like ‘%hello%'";
List<Member> result = em.createQuery(jpql, Member.class)
        .getResultList();

JPA는 SQL을 추상화한 JPQL이라는 객체 지향 쿼리 언어 제공
SQL과 문법 유사, SELECT, FROM, WHERE, GROUP BY, HAVING, JOIN 지원
JPQL은 엔티티 객체를 대상으로 쿼리
JPQL은 결국 SQL로 변환됨

SQL을 추상화해서 제공하기 때문에 특정 데이터베이스 SQL에 의존하지 않는다.

JPQL은 SQL을 문자열 타입으로 작성하기 때문에 컴파일 과정에서

문법에 대한 체크가 이루어 지지 않는다.

따라서 QueryDSL 라이브러리를 함께 사용하도록 한다.

2. 기본 문법과 쿼리 API

select m from Member as m where m.age > 18

JPQL은 엔티티를 대상으로 쿼리하기 때문에 엔티티와 속성에 대한 대소문자를 구별한다.

(Member, age)

JPQL 키워드는 대소문자를 구분하지 않는다.

(select, from, where)

TypeQuery, Query

TypeQuery: 반환 타입이 명확할 때 사용

TypedQuery<Member> query =
        em.createQuery("SELECT m FROM Member m", Member.class);

Query: 반환 타입이 명확하지 않을 때 사용

Query query =
        em.createQuery("SELECT m.username, m.age from Member m");

결과 조회 API

query.getResultList(): 결과가 하나 이상일 때, 리스트 반환

결과가 없으면 빈 리스트 반환

List<Member> result = em.createQuery("select m from Member m", Member.class)
        .getResultList();

query.getSingleResult(): 결과가 정확히 하나, 단일 객체 반환

결과가 없으면: javax.persistence.NoResultException

둘 이상이면: javax.persistence.NonUniqueResultException

Member result = em.createQuery("select m from Member m", Member.class)
        .getSingleResult();

파라미터 바인딩

이름 기준

SELECT m FROM Member m where m.username=:username
query.setParameter("username", usernameParam);

위치 기준

SELECT m FROM Member m where m.username=?1
query.setParameter(1, usernameParam);

유지보수를 위해 위치 기준보다는 이름 기준을 사용하자.

3. 프로젝션

createQuery()의 파라미터로 select 절에 조회할 대상을 지정한다.

프로젝션 대상: 엔티티, 임베디드 타입, 스칼라 타입(숫자, 문자등 기본 데이터 타입)

엔티티 프로젝션

List<Member> result = em.createQuery("select m from Member m", Member.class)
        .getResultList();

Member 객체로 반환값을 매핑한다.

엔티티 프로젝션 - 조인

연관 관계 사이에서 엔티티 프로젝션을 사용할 때는 조인이 발생한다.

묵시적 조인

List<Team> result = em.createQuery("select m.team from Member m", Team.class)
        .getResultList();

명시적 조인

List<Team> result = em.createQuery("select t from Member m join m.team t", Team.class)
        .getResultList();

실행 결과를 예측 가능하도록 명시적 조인을 사용해서 조인이 발생함을 명확히 명시하자.

임베디드 타입 프로젝션

List<Address> result = em.createQuery("select o.address from Orders o", Address.class)
        .getResultList();

프로젝션 - 여러 값 조회

Query 타입으로 조회

List results = em.createQuery("select m.name, m.age from Member m")
        .getResultList();

Object[] 타입으로 조회

List<Object[]> results = em.createQuery("select m.name, m.age from Member m")
        .getResultList();

new 명령어로 조회

List<MemberDto> results = 
        em.createQuery("select jpabook.jpql.MemberDTO(m.username, m.age) from Member m", MemberDto.class)
        .getResultList();

패키지 명을 포함한 전체 클래스명 입력.

순서와 타입이 일치하는 생성자가 필요하다.

4. 페이징

JPA는 페이징을 다음 두 API로 추상화

setFirstResult(int startPosition) : 조회 시작 위치 (0부터 시작)
setMaxResults(int maxResult) : 조회할 데이터 수

String jpql = "select m from Member m order by m.name desc";
List<Member> resultList = em.createQuery(jpql, Member.class)
        .setFirstResult(10)
        .setMaxResults(20)
        .getResultList();

페이징 API - MySQL 방언

SELECT
	M.ID AS ID,
	M.AGE AS AGE,
	M.TEAM_ID AS TEAM_ID,
	M.NAME AS NAME
FROM
	MEMBER M
ORDER BY
	M.NAME DESC LIMIT ?, ?

페이징 API - Oracle 방언

SELECT * FROM
	( SELECT ROW_.*, ROWNUM ROWNUM_
	FROM
		( SELECT
			M.ID AS ID,
			M.AGE AS AGE,
            M.TEAM_ID AS TEAM_ID,
            M.NAME AS NAME
		FROM MEMBER M
		ORDER BY M.NAME
        ) ROW_
    WHERE ROWNUM <= ?
	)
WHERE ROWNUM_ > ?

5. 조인

1) 조인 기본 문법

엔티티간의 연관관계를 통해 조인 SQL을 만든다.

( Member m join m.team t )

내부 조인

SELECT m FROM Member m [INNER] JOIN m.team t

외부 조인

SELECT m FROM Member m LEFT [OUTER] JOIN m.team t

세타 조인

연관관계가 없은 엔티티 간의 조인

select count(m) from Member m, Team t where m.username = t.name

2) ON 절을 활용한 조인

조인 대상 필터링

ON 절을 추가해 조인 대상을 필터링 한다.

예) 회원과 팀을 조인하면서, 팀 이름이 A인 팀만 조인

SELECT m, t FROM Member m LEFT JOIN m.team t on t.name = 'A'

SQL의 ON 절의 조인 조건으로 team.name = 'A' 가 추가된다.

연관관계 없는 엔티티 외부 조인

예) 회원의 이름과 팀의 이름이 같은 대상 외부 조인

SELECT m, t FROM Member m LEFT JOIN Team t on m.username = t.name

SQL ON 절에 id 조건이 빠지고 member.username = team.name 조건이 추가된다.

6. 서브 쿼리

1) 서브 쿼리 기본 문법

예) 나이가 평균보다 많은 회원

select m from Member m
where m.age > (select avg(m2.age) from Member m2)

예) 한 건이라도 주문한 고객

select m from Member m
where (select count(o) from Order o where m = o.member) > 0

2) 서브 쿼리 지원 함수

[NOT] EXISTS (subquery): 서브쿼리에 결과가 존재하면 참

{ALL | ANY | SOME} (subquery)
ALL 모두 만족하면 참
ANY, SOME: 같은 의미, 조건을 하나라도 만족하면 참

[NOT] IN (subquery): 서브쿼리의 결과 중 하나라도 같은 것이 있으면 참

예) 팀A 소속인 회원

select m from Member m
where exists (select t from m.team t where t.name = ‘팀A')

예) 전체 상품 각각의 재고보다 주문량이 많은 주문들

select o from Order o
where o.orderAmount > ALL (select p.stockAmount from Product p)

예) 어떤 팀이든 팀에 소속된 회원

select m from Member m
where m.team = ANY (select t from Team t)

3) JPA 서브 쿼리 한계

JPA는 WHERE, HAVING 절에서만 서브 쿼리 사용 가능
SELECT 절도 가능(하이버네이트에서 지원)
FROM 절의 서브 쿼리는 현재 JPQL에서 불가능
(조인 > 쿼리 분할 > 네이티브 쿼리 순서로 풀 수 있으면 풀어서 해결)

7. JPQL 타입 표현

문자: ‘HELLO’, ‘She’’s’
숫자: 10L(Long), 10D(Double), 10F(Float)
Boolean: TRUE, FALSE
ENUM: jpabook.MemberType.Admin (패키지명 포함)
엔티티 타입: TYPE(m) = Member (상속 관계에서 사용) 상속관계 매핑 조인전략 참고

JPQL 기타 문법

EXISTS, IN
AND, OR, NOT
=, >, >=, <, <=, <>
BETWEEN, LIKE, IS NULL

8. 조건식

1) CASE 식

기본 CASE 식

select
 case when m.age <= 10 then '학생요금'
 when m.age >= 60 then '경로요금'
 else '일반요금'
 end
from Member m

단순 CASE 식

select
 case t.name
 when '팀A' then '인센티브110%'
 when '팀B' then '인센티브120%'
 else '인센티브105%'
 end
from Team t

2) COALESCE, NULLIF

COALESCE

하나씩 조회해서 null이 아니면 반환

예) 사용자 이름이 없으면 이름 없는 회원을 반환

select coalesce(m.username,'이름 없는 회원') from Member m

NULLIF

두 값이 같으면 null 반환, 다르면 첫번째 값 반환

예) 사용자 이름이 ‘관리자’면 null을 반환하고 나머지는 본인의 이름을 반환

select NULLIF(m.username, '관리자') from Member m

9. JPQL 함수

1) JPQL 기본 함수

CONCAT
SUBSTRING
TRIM
LOWER, UPPER
LENGTH
LOCATE
ABS, SQRT, MOD
SIZE, INDEX(JPA 용도)

select size(t.members) from Team t

2) 사용자 정의 함수

사용하는 DB 방언을 상속받고, 사용자 정의 함수를 등록한다.

H2 데이터베이스 경우 H2Dialect 클래스에 JPQL 함수를 정의해 놓았다.

[MyH2Dialect]

public class MyH2Dialect extends H2Dialect {

public MyH2Dialect() {
    registerFunction("group_concat", 
               new StandardSQLFunction("group_concat", StandardBasicTypes.STRING));
}

[persistence.xml]

<!--<property name="hibernate.dialect" value="org.hibernate.dialect.H2Dialect"/>-->
<property name="hibernate.dialect" value="jpql.MyH2Dialect"/>

select function('group_concat', i.name) from Item i

출처

https://www.inflearn.com/course/ORM-JPA-Basic 자바 ORM 표준 JPA 프로그래밍 - 기본편(김영한)

[클린코드] 10. 클래스

mandykr — Mon, 28 Mar 2022 13:25:23 +0900

1. 클래스 체계

2. 단일 책임 원칙

3. 낮은 결합도와 높은 응집도

4. 클래스는 변경하기 쉬워야 한다.

1. 클래스 체계

클래스를 정의하는 표준 자바 관례에 따르면 다음과 같은 순서이다.

static public 상수 > private 변수
공개 함수 > private 함수

비공개 함수는 자신을 호출하는 공개 함수 직수에 넣는다.

추상화 단계가 순차적으로 내려가 가독성이 높아진다.

캡슐화

https://www.programminghunk.com/2020/01/encapsulation.html

클래스를 개발할 때 기본적으로 구현을 감추고 외부 객체와 상호작용 하는 부분만 노출한다.

필드를 private으로 제한, 외부의 잘못된 사용을 방지한다.

2. 단일 책임 원칙 (SRP)

클래스는 함수와 마찬가지로 작아야 한다.

작은 클래스는 각자 맡은 책임이 하나며, 변경할 이유가 하나며,

다른 클래스와 협력해 시스템에 필요한 동작을 수행한다.

규모가 어느 수준에 이르는 시스템은 논리가 많고 복잡하다.

이런 복잡성을 다루려면 체계적인 정리가 필수다. 그래야 개발자가 무엇이 어디에 있는지 쉽게 찾는다.

변경이 발생하는 상황에서 직접 영향이 미치는 컴포넌트만 이해해도 충분한데,

큼직한 다목적 클래스 몇 개로 이뤄진 시스템은 당장 알 필요가 없는 사실까지 들이밀어 독자를 방해한다.

3. 낮은 결합도와 높은 응집도

결합도는 낮을 수록 응집도는 높을 수록 유지보수성이 좋다.

낮은 결합도

시스템의 결합도를 낮추면 유연성과 재사용성도 더욱 높아진다.
DIP - 클래스가 상세한 구현이 아니라 추상화에 의존해야 한다.
추상화를 이용하면 테스트 코드 짜기에 용이하다.

결합도가 높은 클래스의 문제점

연관된 클래스가 변경되면 수정이 필요하다.
결합도가 높으면 연관된 클래스들을 모두 이해해야 한다.

높은 응집도

클래스는 인스턴수 변수 수가 적어야 한다.
메서드는 인스턴스 변수를 하나 이상 사용해야 한다.
메서드가 인스턴스 변수를 많이 사용할 수록 응집도가 높아진다.
응집도가 높다 = 클래스에 속한 메서드와 변수가 서로 의존하며 논리적인 단위로 묶인다.
클래스가 응집도를 잃어간다면 함수를 쪼개야 한다.

응집도가 낮은 클래스의 문제점

여러 기능이 있으므로 이해하기 어렵다.
재사용하기 어렵다.

4. 클래스는 변경하기 쉬워야 한다.

새로운 기능을 추가할 때 기존 코드에도 수정이 발생하면 OCP에 위반된다.

새로운 SQL을 추가할 때도 수정이 발생하고, 기존 SQL 문을 수정할 때도 수정이 발생하므로 OCP에 위반된다.

따라서 공개 인터페이스를 전부 SQL 클래스에서 파생하는 클래스로 만들고,

비공개 메서드는 해당 클래스로 옮기고 공통된 인터페이스는 클래스로 분리했다.

새로운 기능에는 개방적인 동시에 다른 클래스를 닫아놓는 방식으로 수정에 폐쇠적이다.

출처

Clean Code(클린 코드) 애자일 소프트웨어 장인 정신 - 로버트 C. 마틴 지음

[클린코드] 8. 경계

mandykr — Mon, 28 Mar 2022 12:32:21 +0900

1. 경계란

2. 외부 코드 사용하기

3. 학습 테스트

1. 경계란

프로젝트에서 오픈소스, 라이브러리 같은 외부 코드를 자주 사용한다.

우리 코드는 외부 코드의 인터페이스를 제공받아 사용하는데

제공자와 사용자 사이의 시스템 경계에서는 문제가 생길 소지가 많기 때문에

외부 코드를 우리 코드에 깔끔하게 통합 할 수 있도록 경계를 잘 지어야 한다.

2. 외부 코드 사용하기

캡슐화

외부 코드를 사용하는 부분을 캡슐화해

데이터를 보호하고 외부 인터페이스가 변할 경우 우리 코드에 미치는 영향을 최소화 한다.

java.util.Map 인터페이스를 예로 든다.

Map<Sensor> sensors = new HashMap<Sensor>();
...
Sensor s = sensors.get(sensorId );

Map 인터페이스가 제공하는 clear 등 불필요한 기능이 노출된다.
외부 코드가 함부로 호출하면 sensor 데이터가 손상될 수 있다.
Map 인터페이스가 변경되면 사용하는 우리 코드의 수정할 코드가 많아진다.

public class Sensors {
    private Map sensors = new HashMap();
    
    public Sensor getById(String id) {
        return (Sensor) sensors.get(id);
    }
}

캡슐화를 통해 Map을 감춘다.
원하는 기능(getById())만 공개할 수 있다.
Map 인터페이스가 변하더라도 나머지 프로그램에는 영향을 미치지 않는다.

Map과 같은 경계 인터페이스를 이용할 때는

이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의해야 한다.

Adapter 패턴

Adapter 패턴은 외부 코드를 호출할 때,

우리가 정의한 인터페이스대로 호출하기 위해 사용하는 패턴이다.

TransmitterAdapter에 API 사용을 캡슐화해 API가 바뀔 때 수정할 코드를 한 곳으로 모은다.

CommunicationController 코드는 Transmitter 인터페이스를 정의해 외부 API와 분리했기 때문에 가독성이 높아지고 코드의 의도도 분명해진다.

또한, 이런 설계는 테스트를 만들때는 적절한 Fake 객체를 만들어 주입해 사용할 수 있기 때문에

외부 API와 분리해 우리의 코드가 제대로 동작하는지 테스트할 수 있다.

Adapter 패턴 in Elastic Search

1. 우리 코드(내 패키지)가 아닌 외부 코드를 import 하고 있다.

2. 외부 코드인 NettyAdaptor는 nettyChannel을 감싸고 있다.

Adapter에 우리가 원하는 타입의 파라미터를 전달해 경계 인터페이스를 사용한다.

ByteBuffer, Page타입의 파라미터를 ByteBuf로 변환해 외부 코드인 nettyChannel에 전달한다.

만약 Adapter를 통해 변환을 거치지 않았다면

nettyChannel에 데이터를 전달할 때마다 타입을 변환하는 과정이 필요해진다.

3. 학습 테스트

학습 테스트를 작성해 외부 코드에 대한 이해도를 높이고 안정성도 미리 검증할 수 있다.

또한, 외부 코드의 버전이 변경됐을 때, 우리 코드와 호환되는지 확인할 수 있다.

예) 경로 탐색을 위한 라이브러리 JGraph의 학습 테스트

@Test
public void getDijkstraShortestPath() {
    WeightedMultigraph<String, DefaultWeightedEdge> graph
            = new WeightedMultigraph(DefaultWeightedEdge.class);
    graph.addVertex("v1");
    graph.addVertex("v2");
    graph.addVertex("v3");
    graph.setEdgeWeight(graph.addEdge("v1", "v2"), 2);
    graph.setEdgeWeight(graph.addEdge("v2", "v3"), 2);
    graph.setEdgeWeight(graph.addEdge("v1", "v3"), 100);

    DijkstraShortestPath dijkstraShortestPath
            = new DijkstraShortestPath(graph);
    List<String> shortestPath 
            = dijkstraShortestPath.getPath("v3", "v1").getVertexList();

    assertThat(shortestPath.size()).isEqualTo(3);
}

출처

Clean Code(클린 코드) 애자일 소프트웨어 장인 정신 - 로버트 C. 마틴 지음

https://zero-base.co.kr/category_dev_camp/cleancode_1book

[클린코드] 7. 오류 처리

mandykr — Fri, 25 Mar 2022 16:28:10 +0900

1. 예외 처리 방식

2. Business Exception

1. 예외 처리 방식

오류 코드보다 예외를 사용하자.

오류 코드를 사용하는 것 보다 예외를 던지는 방식이 더 명확하고 메소드를 호출하는 코드와 처리 흐름이 깔끔해진다.

오류가 발생한 부분에서 Checked Exception을 발생시키고

상위 레벨에서는 예외를 catch 하여 처리하거나 메소드 선언부에 throws를 명시한다.

Checked Exception은 예외에 대한 처리가 반드시 필요하기 떄문에

하위 레벨 메소드에서 Checked Exception을 발생시키면 catch 블록이 나오기 까지 모든 상위 레벨 메소드에서

throws 처리를 해주어야 한다.

결국 상위 레벨 메소드에서 하위 레벨 메소드의 디테일에 대해 알아야 하기 때문에 OCP 원칙에 위배된다.

Unchecked Exception을 사용하라.

출처 https://www.nextree.co.kr/p3239/

Exception을 상속하면 Checked Exception 명시적인 예외 처리가 필요하다.
(예)IOException,SQLException
RuntimeException을 상속하면 Unchekced Exception 명시적인 예외 처리가 필요하지 않다.
(예)NullPointerException, IllegalArgumentException, IndexOutOfBoundException

C#, C++, 파이썬, 루비 등의 언어는

Checked Exception을 지원하지 않지만 안정적인 소프트웨어를 구현하기에는 무리가 없다.

명시적인 예외 처리가 필요하지 않은 Unchekced Exception을 사용하자.

예외에 메세지를 담아라.

private DeviceHandle getHandle(DeviceID id) {
    ...
    throw new DeviceShutDownError("Invalid handle for: " + id.toString());
    ...
}

오류가 발생한 원인과 위치를 찾기 쉽도록 예외를 던질 떄는 전후 상황을 충분히 덧붙인다.

실패한 연산 이름과 유형 등 오류 메세지에 정보를 담아 예외와 함께 던진다.

Exception Wrapper를 사용하라.

ACMEPort port = new ACMEPort(12);
try {
    port.open();
} catch (DeviceResponseException e) {
    reportPortError(e);
    logger.log("Device response exception", e);
} catch (ATM1212UnlockedException e) {
    reportPortError(e);
    logger.log("Unlock exception", e);
} catch (GMXError e) {
    reportPortError(e);
    logger.log("Device response exception");
} finally {
    …
}

외부 라이브러리를 호출하며 해당 라이브러리가 던질 예외를 모두 잡아내는 방식이다.

호출하는 라이브러리 API를 감싸면서 porte.open()이 던지는 Checked Exception을 하나의 예외 유형으로 감싸서 반환하면 코드를 간결하게 고칠 수 있다.

LocalPort port = new LocalPort(12);
try {
    port.open();
} catch (PortDeviceFailure e) {
    reportError(e);
    logger.log(e.getMessage(), e);
} finally {
    …
}

public class LocalPort {
    private ACMEPort innerPort;
    
    public LocalPort(int portNumber) {
        innerPort = new ACMEPort(portNumber);
    }
    
    public void open() {
        try {
            innerPort.open();
        } catch (DeviceResponseException e) {
            throw new PortDeviceFailure(e);
        } catch (ATM1212UnlockedException e) {
            throw new PortDeviceFailure(e);
        } catch (GMXError e) {
            throw new PortDeviceFailure(e);
        }
    }
}

외부 API를 감싸면 외부 라이브러리와 프로그램 사이의 의존성도 크게 줄어든다.

나중에 다른 라이브러리로 변경할 떄의 비용도 적다.

또한 실제 API를 호출하는 대신 테스트 코드를 넣어주는 방식으로 프로그램을 테스트 하기도 쉬워진다.

null을 반환하지 마라.

반환 데이터가 없는 경우 null을 리턴하면 이 후 모든 코드에서 null 체크가 있어야 하기 때문에

가독성을 떨어트리며 null 체크를 누락할 수 있는 위험성이 있다.

(1) 기본값을 리턴한다.

복수형의 데이터를 가져올 때는 데이터의 없음을 의미하는 컬렉션을 리턴하면 된다.
null 보다 size가 0인 컬렉션이 훨씬 안전하다.

(2) 도메인에 맞는 기본값을 리턴한다. (getOrElse)

UserLevel userLevel = userService.getUserLevelOrDefault(userId);

시스템이 중단되지 않고 정상적인 흐름을 가져갈 수 있도록 도메인에 맞는 기본값인 basic level을 리턴한다.

데이터를 제공하는 쪽에서 예외를 처리하기 떄문에 호출부 코드의 논리적인 흐름도 끊기지 않는다.

(3) 예외를 던진다.

기본값을 반환할 수 없는 경우에는 Unchecked Exception을 던질수 있다.

마찬가지로 호출부 코드의 가독성도 높일 수 있다.

null을 전달하지 마라.

호출자가 실수로 넘기는 null을 적절히 처리하는 별도의 방법이 없기 때문에

애초에 null을 넘기지 못하도록 금지하는 정책이 합리적이다.

2. Business Exception

자바에서 제공하는 Exception이 아닌 커스텀 Exception을 만들어 사용할 수 있다.

RuntimeException을 상속하는 Business Exception을 만들고 enum으로 ErrorCode를 정의한다.

커스텀 Exception을 사용하면 IllegalArgumentException 처럼 외부 라이브러리에서 발생할 수 있는 예외와 섞이지 않고

에러 로그에서 우리 시스템에서 발생한 예외를 파악하기에 용이하다.

자세한 내용 참고 : Exception 전략

출처

Clean Code(클린 코드) 애자일 소프트웨어 장인 정신 - 로버트 C. 마틴 지음

https://zero-base.co.kr/category_dev_camp/cleancode_1book

[Spring] 2. 컴포넌트 스캔과 의존관계 자동 주입

mandykr — Mon, 21 Mar 2022 12:18:11 +0900

1. 컴포넌트 스캔과 의존관계 주입

2. 컴포넌트 스캔

3. 의존관계 자동 주입

1. 컴포넌트 스캔과 의존관계 주입

[Spring] 1. 스프링 컨테이너 예제에서는 AppConfig와 같이 설정 정보 클래스에서 빈과 의존관계를 설정해 주었다.

하지만 프로젝트 규모가 커지고 등록해야 할 스프링 빈이 많아지면서 수동으로 관리하기가 점점 복잡해진다.

그래서 스프링은 별도의 설정 정보 없이 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다.

@Configuration
@ComponentScan
public class AutoAppConfig {

}

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
            discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

// 로그
ClassPathBeanDefinitionScanner - Identified candidate component class:
.. RateDiscountPolicy.class
.. MemberServiceImpl.class
.. MemoryMemberRepository.class
.. OrderServiceImpl.class

@Bean으로 등록할 필요 없이 설정 정보 클래스에 @ComponentScan을 붙여주면 @Component가 붙은 클래스의 객체를 스프링 빈으로 등록한다.

@Bean으로 설정 정보를 직접 만들어 사용할 때와 달리 의존관계 주입을 할 수 없기 때문에

@Autowired를 붙여서 의존관계를 자동으로 주입하도록 설정한다.

스프링 컨테이너에서 타입이 맞는 빈을 찾아 주입한다.

동작 과정

@ComponentScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다.

이때 스프링 빈의 기본 이름은 클래스명을 사용하되 맨 앞글자만 소문자를 사용한다.

이름 기본 전략: MemberServiceImpl --> memberServiceImpl
빈 이름 직접 지정: @Component("memberService2")

생성자에 @Autowired를 지정하면 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아서 주입한다.

이때 기본 조회 전략은 타입이 같은 빈을 찾아서 주입한다.

2. 컴포넌트 스캔

1) 탐색 위치

모든 자바 클래스를 다 컴포넌트 스캔하면 시간이 오래 걸리기 때문에

꼭 필요한 위치부터 탐색을 시작하도록 설정할 수 있다.

@ComponentScan(
        basePackages = "hello.core",
}

기본 설정은 @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치
basePackage: 탐색할 패키지의 시작 위치를 지정
basePackageClasses: 지정한 클래스의 패키지를 탐색 시작 위치로 지정

되도록 설정 정보 클래스의 위치를 최상단에 두고 별도의 패키지 위치를 지정하지 않도록 권장.

@SpringBootApplication

@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
		@Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {
}

Spring Boot에서는 @SpringBootApplication에 @ComponentScan이 들어있다.

따라서 @SpringBootApplication이 붙은 클래스의 패키지가 컴포넌트 스캔의 시작 위치가 된다.

2) 컴포넌트 스캔 기본 대상

컴포넌트 스캔은 @Component 뿐만 아니라 다음과 내용도 추가로 대상에 포함한다.

@Component : 컴포넌트 스캔에서 사용
@Controlller : 스프링 MVC 컨트롤러에서 사용
@Service : 스프링 비즈니스 로직에서 사용
@Repository : 스프링 데이터 접근 계층에서 사용
@Configuration : 스프링 설정 정보에서 사용

@Component
public @interface Controller {
}

@Controller, @Configuration과 같은 어노테이션은 @Component를 포함하고 있기 때문에 컴포넌트 스캔의 대상이 되는데 어노테이션이 특정 어노테이션을 들고 있는 것을 인식할 수 있는 것은

자바 언어가 아닌 스프링이 지원하는 기술이다.

부가 기능

컴포넌트 스캔의 용도 뿐만 아니라 다음 애노테이션이 있으면 스프링은 부가 기능을 수행한다.

@Controller : 스프링 MVC 컨트롤러로 인식
@Repository : 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환해준다.
@Configuration : 앞서 보았듯이 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가
처리를 한다.
@Service : 사실 @Service 는 특별한 처리를 하지 않는다. 대신 개발자들이 핵심 비즈니스 로직이 여기에
있겠구나 라고 비즈니스 계층을 인식하는데 도움이 된다.

프로젝트의 DB를 바꾸면 예외의 내용이 바뀌는데 @Repository가 Spring 예외로 변환해 추상화 해주기 때문에 별도의 문제가 발생하지 않는다.

3) 필터

컴포넌트 스캔 대상을 추가하거나 제외하도록 설정할 수 있다.

@Configuration
@ComponentScan(
        includeFilters = @Filter(type = FilterType.ANNOTATION, classes =
                MyIncludeComponent.class),
        excludeFilters = @Filter(type = FilterType.ANNOTATION, classes =
                MyExcludeComponent.class)
)

includeFilters : 컴포넌트 스캔 대상을 추가로 지정한다.
excludeFilters : 컴포넌트 스캔에서 제외할 대상을 지정한다.

FilterType 옵션

ANNOTATION: 기본값, 애노테이션을 인식해서 동작한다.
ex) org.example.SomeAnnotation
ASSIGNABLE_TYPE: 지정한 타입과 자식 타입을 인식해서 동작한다.
ex) org.example.SomeClass
ASPECTJ: AspectJ 패턴 사용
ex) org.example..*Service+
REGEX: 정규 표현식
ex) org\.example\.Default.*
CUSTOM: TypeFilter 이라는 인터페이스를 구현해서 처리
ex) org.example.MyTypeFilter

스프링 부트는 컴포넌트 스캔을 기본으로 제공하는데,

옵션을 변경하면서 사용하기 보다는 스프링의 기본 설정에 최대한 맞추어 사용하는 것을 권장한다.

3) 중복 등록과 충돌

@Component을 이용한 자동 빈 등록과 @Bean을 이용한 수동 빈 등록 과정에서

같은 빈 이름을 등록하도록 요청하면 컴포넌트 스캔에서 다음과 같은 처리가 이루어 진다.

자동 vs 자동

ConflictingBeanDefinitionException 예외 발생

수동 vs 자동

@Component
public class MemoryMemberRepository implements MemberRepository {}

@Configuration
@ComponentScan(
        excludeFilters = @Filter(type = FilterType.ANNOTATION, classes =
                Configuration.class)
)
public class AutoAppConfig {
    @Bean(name = "memoryMemberRepository")
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
}

// 로그
Overriding bean definition for bean 'memoryMemberRepository' with a different
definition: replacing

이 경우 수동 빈 등록이 우선권을 가진다.
(수동 빈이 자동 빈을 오버라이딩 해버린다.)

동일한 이름의 빈을 오버라이딩하는 경우는 애매한 버그를 만들어 파악하기 어려운 상황을 만들 수 있다.

최근 스프링 부트에서는 수동 빈 등록과 자동 빈 등록이 충돌하면 오류가 발생하도록 기본 값을 바꾸었다.

스프링 부트인 CoreApplication을 실행하면 다음과 같은 에러가 발생한다.

Consider renaming one of the beans or enabling overriding by setting
spring.main.allow-bean-definition-overriding=true

3. 의존관계 자동 주입

1) 다양한 의존관계 주입 방법

스프링 컨테이너는 스프링 빈을 먼저 등록하고 의존관계를 주입하는 순서로 동작한다.

의존관계 주입은 스프링 빈이어야 가능하다.

생성자 주입은 빈 등록 과정에서 의존관계 주입까지 이루어지고

나머지는 빈등록이 먼저 이루어지고 이 후에 의존관계를 주입한다.

생성자 주입

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    
    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

생성자 호출 시점에 딱 1번만 호출되며 애플리케이션을 시작할 때 빈의 의존관계 설정을 완료한다.

불변, 필수 의존관계에서 사용한다.

생성자가 1개만 있으면 @Autowired를 생략할 수 있다.

생성자 주입을 선택하자.

대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안되지만(불변)

생성자 주입 이외의 경우에는 외부에서 의존관계를 변경할 수 있다.

또한 의존관계 주입이 누락된 경우 생성자 주입 방식에서는 런타임 시점에서 NPE가 발생하지만

생성자 주입 방식에서는 컴파일 단계에서 확인할 수 있다.

final 키워드를 함께 사용하면 더 안전하게 의존관계 주입을 설정할 수 있다.

private final MemberRepository memberRepository;

항상 생성자 주입을 선택하고 일부 필요한 경우 수정자 주입을 사용하자.

수정자 주입

@Component
public class OrderServiceImpl implements OrderService {
    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;
    
    @Autowired
    public void setMemberRepository(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }
    
    @Autowired
    public void setDiscountPolicy(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }
}

필드의 값을 변경하는 setter 메서드를 통해서 의존관계를 주입하는 방법이다.

선택, 변경 가능성이 있는 의존관계에 사용한다.

필드 주입

@Component
public class OrderServiceImpl implements OrderService {
    @Autowired
    private MemberRepository memberRepository;
    
    @Autowired
    private DiscountPolicy discountPolicy;
}

DI 프레임워크가 없으면 외부에서 협력 객체 변경이 불가능해서 테스트하기 힘들다.

@SpringBootTest 등으로 스프링 빈을 사용해서 테스트 할 수 있지만

상황에 따라 필요한 객체 혹은 가짜 객체(Mock, Stub, Fake 등)를 만들어서 주입하는 방식으로 테스트 코드를 만들지 못한다.

애플리케이션의 실제 코드와 관계없는 테스트 코드, 스프링 설정을 목적으로 하는 @Configuration 같은 곳에서만 특별한 용도로 사용한다.

일반 메서드 주입

@Component
public class OrderServiceImpl implements OrderService {
    private MemberRepository memberRepository;
    private DiscountPolicy discountPolicy;
    
    @Autowired
    public void init(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

한번에 여러 필드를 주입 받을 수 있다.

일반적으로 잘 사용하지 않는다.

2) 옵션 처리

주입할 스프링 빈이 없어도 동작해야 할 때가 있는데 이런 경우 자동 주입 대상을 옵션으로 처리할 수 있다.

//호출 안됨
@Autowired(required = false)
public void setNoBean1(Member member) {
    System.out.println("setNoBean1 = " + member);
}

//null 호출
@Autowired
public void setNoBean2(@Nullable Member member) {
    System.out.println("setNoBean2 = " + member);
}

//Optional.empty 호출
@Autowired(required = false)
public void setNoBean3(Optional<Member> member) {
    System.out.println("setNoBean3 = " + member);
}

@Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨
org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력된다.
Optional<> : 자동 주입할 대상이 없으면 Optional.empty 가 입력된다.

@Nullable, Optional은 스프링 전반에 걸쳐서 지원된다.

생성자 주입, 수정자 주입에서 특정 필드에만 적용해도 된다.

3) 롬복

롬복 라이브러리 설치, IntelliJ Lombok 플러그인 설치, Enable annotation processing 설정.

생성자 주입 방식에서 코드를 간결하게 수정할 수 있다.

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
}

@RequiredArgsConstructor 는 final 필드에 대해 생성자를 만들어 준다.

4) 조회 대상 빈이 2개인 경우

조회 대상 빈이 2개인 경우 NoUniqueBeanDefinitionException이 발생한다.

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Component
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    
    @Autowired
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
}

NoUniqueBeanDefinitionException: No qualifying bean of type
'hello.core.discount.DiscountPolicy' available: expected single matching bean
but found 2: fixDiscountPolicy,rateDiscountPolicy

@Autowired 필드 명

스프링은 타입 매칭을 먼저 시도하고 여러개의 빈이 조회된 경우 필드명, 파라미터 명으로 빈이름과 매칭한다.

@Autowired
public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy rateDiscountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = rateDiscountPolicy;
}

타입 매칭
타입 매칭의 결과가 2개 이상일 때 필드 명, 파라미터 명으로 빈 이름 매칭

@Qualifier

빈 등록과 주입시에 @Qualifier를 붙여주고 이름으로 매칭되도록 설정한다.

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
@Qualifier("fixDiscountPolicy")
public class FixDiscountPolicy implements DiscountPolicy {}

@Autowired
public OrderServiceImpl(MemberRepository memberRepository, 
                        @Qualifier("mainDiscountPolicy") DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

@Qualifier끼리 매칭
빈 이름 매칭 (mainDiscountPolicy)
NoSuchBeanDefinitionException 예외 발생

@Qualifier("mainDiscountPolicy") 에서 mainDiscountPolicy는 문자이기 때문에 컴파일 과정에서

의존관계 주입이 정상적으로 동작할 지 확인할 수 있도록 어노테이션을 별도로 만들어서 사용할 수 있다.

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,
ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {
}

@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                        @MainDiscountPolicy DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

@Primary

@Autowired 시에 여러 빈이 매칭되면 @Primary 가 우선권을 가진다.

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Primary, @Qualifier 활용

우선 순위 : @Primary < @Qualifier

코드에서 자주 사용하는 메인 데이터베이스의 커넥션을 획득하는 스프링 빈이 있고,

코드에서 특별한 기능으로 가끔 사용하는 서브 데이터베이스의 커넥션을 획득하는 스프링 빈이 있다고 생각해보자.

메인 데이터베이스의 커넥션을 획득하는 스프링 빈은 @Primary 를 적용해서 조회하는 곳에서 @Qualifier
지정 없이 편리하게 조회하고, 서브 데이터베이스 커넥션 빈을 획득할 때는 @Qualifier 를 지정해서
명시적으로 획득 하는 방식으로 사용하면 코드를 깔끔하게 유지할 수 있다.

물론 이때 메인 데이터베이스의 스프링 빈을 등록할 때 @Qualifier 를 지정해주는 것은 상관없다.

5) 조회한 빈이 모두 필요할 때

의도적으로 해당 타입의 스프링 빈이 모두 필요한 경우,

Map과 List로 주입받아 간단하게 전략 패턴을 구현할 수 있다.

class DiscountService {
    private final Map<String, DiscountPolicy> policyMap;
    private final List<DiscountPolicy> policies;
    
    public DiscountService(Map<String, DiscountPolicy> policyMap,
                           List<DiscountPolicy> policies) {
        this.policyMap = policyMap;
        this.policies = policies;
    }
    
    public int discount(Member member, int price, String discountCode) {
        DiscountPolicy discountPolicy = policyMap.get(discountCode);
        return discountPolicy.discount(member, price);
    }
}

Map<String, DiscountPolicy> : map의 키에 스프링 빈의 이름을 넣어주고, 그 값으로
DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
List<DiscountPolicy> : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
만약 해당하는 타입의 스프링 빈이 없으면, 빈 컬렉션이나 Map을 주입한다

int discountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");

클라이언트가 할인 정책을 선택해서 할인 받도록 하는 경우

discountCode 파라미터로 빈 이름을 넘겨주면서 사용될 스프링 빈을 결정할 수 있다.

6) 자동, 수동 등록 기준

편리한 자동 기능을 기본으로 사용하자

스프링은@Component 뿐만 아니라 @Controller , @Service , @Repository 처럼 계층에 맞추어 일반적인
애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다. 거기에 더해서 최근 스프링 부트는 컴포넌트
스캔을 기본으로 사용하고, 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록하도록
설계했다.

직접 등록하는 기술 지원 객체는 수동 등록

업무 로직 빈: 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는
리포지토리등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.
기술 지원 빈: 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결이나,
공통 로그 처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들이다.

기술 지원 로직은 업무 로직과 비교해서 그 수가 매우 적고, 보통 애플리케이션 전반에 걸쳐서 광범위하게 영향을 미친다. 그리고 업무 로직은 문제가 발생했을 때 어디가 문제인지 명확하게 잘 들어나지만, 기술 지원 로직은 적용이 잘 되고 있는지 아닌지 조차 파악하기 어려운 경우가 많다. 그래서 이런 기술 지원 로직들은 가급적 수동 빈 등록을 사용해서 명확하게 들어내는 것이 좋다.

스프링과 스프링 부트가 자동으로 등록하는 수 많은 빈들은 예외다.

이런 부분들은 스프링 자체를 잘 이해하고 스프링의 의도대로 잘 사용하는게 중요하다. 스프링 부트의 경우 DataSource 같은 데이터베이스 연결에 사용하는 기술 지원 로직까지 내부에서 자동으로 등록하는데, 이런 부분은 메뉴얼을 잘 참고해서 스프링 부트가 의도한 대로 편리하게 사용하면 된다.

다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자

private final Map<String, DiscountPolicy> policyMap;

DiscountPolicy 로 어떤 빈들이 들어오게 될지 한눈에 확인이 되지 않는다.

이런 경우 수동 빈으로 등록하거나 또는 자동으로하면 특정 패키지에 같이 묶어두는게 좋다.

@Configuration
public class DiscountPolicyConfig {

    @Bean
    public DiscountPolicy rateDiscountPolicy() {
        return new RateDiscountPolicy();
    }
    @Bean
    public DiscountPolicy fixDiscountPolicy() {
        return new FixDiscountPolicy();
    }
}

출처

스프링 핵심 원리 - 기본편(김영한)

[클린코드] 6. 객체와 자료 구조

mandykr — Mon, 7 Mar 2022 11:42:42 +0900

1. 자료구조 vs 객체

2. 객체 - 디미터 법칙

3. DTO

4. Active Record vs Data Mapper

1. 자료 구조 vs 객체

자료 구조(Data Structure)	객체(Object)
데이터 그 자체	비즈니스 로직과 관련
자료를 공개한다.	자료를 숨기고 추상화한다. 자료를 다루는 함수만 공개한다.
변수 사이에 조회 함수와 설정 함수로 변수를 다룬다고 객체가 되지 않는다. (getter, setter)	추상 인터페이스를 제공해 사용자가 구현을 모른 채 자료의 핵심을 조작할 수 있다.

예시 (1) Vehicle - 자료 구조

조회 함수와 설정 함수로 자료를 공개한다.

public interface Vehicle {
    double getFuelTankCapacityInGallons();
    double getGallonsOfGasoline();
}

public class Car implements Vehicle {
    double fuelTankCapacityInGallons;
    double gallonsOfGasoline;

    @Override
    public double getFuelTankCapacityInGallons() {
        return fuelTankCapacityInGallons;
    }

    @Override
    public double getGallonsOfGasoline() {
        return gallonsOfGasoline;
    }
}

예시 (1) Vehicle - 객체

자료를 숨기고 추상화한다. 자료를 다루는 함수만 공개한다.

public interface Vehicle {
    double getPercentFuelRemaining();
}

public class Car implements Vehicle {
    double fuelTankCapacityInGallons;
    double gallonsOfGasoline;


    @Override
    public double getPercentFuelRemaining() {
        return this.gallonsOfGasoline / this.fuelTankCapacityInGallons * 100;
    }
}

예시 (2) Shape - 자료 구조

절차적인 코드는 새로운 자료 구조(도형 클래스)를 추가하기 어렵다.

하지만 Geometry 클래스의 함수를 고쳐야 한다.

public class Square {
    public Point topLeft;
    public double side;
}

public class Rectangle {
    public Point topLeft;
    public double height;
    public double width;
}

public class Circle {
    public Point center;
    public double radius;
}

public class Geometry {
    public final double PI = 3.141592653589793;

    public double area(Object shape) throws NoSuchShapeException {
        if (shape instanceof Square) {
            Square s = (Square) shape;
            return s.side * s.side;
        } else if (shape instanceof Rectangle) {
            Rectangle r = (Rectangle) shape;
            return r.height * r.width;
        } else if (shape instanceof Circle) {
            Circle c = (Circle) shape;
            return PI * c.radius * c.radius;
        }
        throw new NoSuchShapeException();
    }
}

예시 (2) Shape - 객체

객체지향 코드는 새로운 클래스를 추가하기 쉽다.

하지만 함수를 추가하려면 도형 클래스 전체에 추가 해야 한다.

public class Square implements Shape {
    private Point topLeft;
    private double side;

    public double area() {
        return side * side;
    }
}

public class Rectangle implements Shape {
    private Point topLeft;
    private double height;
    private double width;

    public double area() {
        return height * width;
    }
}

public class Circle implements Shape {
    private Point center;
    private double radius;
    public final double PI = 3.141592653589793;

    public double area() {
        return PI * radius * radius;
    }
}

상황에 맞는 선택을 하면 된다.

자료 구조를 사용하는 절차적인 코드는 기본 자료 구조를 변경하지 않으면서 새 함수를 추가하기 쉽다.
절차적인 코드는 새로운 자료 구조를 추가하기 어렵다. 그러려면 모든 함수를 고쳐야 한다.
객체지향 코드는 기존 함수를 변경하지 않으면서 새 클래스를 추가하기 쉽다.
객체지향 코드는 새로운 함수를 추가하기 어렵다. 그러려면 모든 클래스를 고쳐야 한다.

2. 객체 - 디미터 법칙

디미터 법칙은 잘 알려진 휴리스틱으로 모듈은 자신이 조작하는 객체의 속사정을 몰라야 한다는 법칙이다.

클래스 C의 메서드 f는 다음과 같은 객체의 메서드만 호출해야 한다.

(휴리스틱 : 경험에 기반하여 문제를 해결 하기 위해 발견한 방법. 의사 결정을 단순화 하기 위한 법칙들.)

클래스 C
자신이 생성한 객체
자신의 인수로 넘어온 객체
C 인스턴스 변수에 저장된 객체

위의 객체에서 허용된 메서드가 반환하는 객체의 메서드는 호출하면 안된다.

다음과 같은 코드를 기차 충돌이라 부른다.

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

디미터 법칙을 위반하는지 여부는 ctxt, options, scratchDir이 자료 구조인지 객체인지에 달렸다.

자료 구조라면 당연히 내부 구조를 노출하므로 디미터 법칙이 적용되지 않고 다음과 같이 구현할 수 있다.

final String outputDir = ctxt.options.scratchDir.absolutePath;

객체라면 내부 구조를 숨겨야 하므로 디미터 법칙을 위한한다.

따라서 객체에게 뭔가를 하라고 메세지를 전달해야지 속을 드러내라고 말하면 안된다.

코드가 데이터를 가져오는 근본 원인을 찾아 다음과 같이 코드를 수정하도록 한다.

임시 디렉터리의 절대 경로를 얻으려는 이유가 임시 파일을 생성하기 위한 목적이기 때문에

객체에게 임시 파일을 생성하라고 명령하도록 수정한다.

BufferedOutputStream bos = ctxt.createScratchFileStream(classFileName);

3. DTO

DTO(Data Transfer Object) : 자료 구조

다른 계층 가 데이터를 교환할 때 사용

로직 없이 필드만 갖는다.
일반적으로 클래스 명이 Dto or DTO로 끝난다.
getter/setter를 갖기도 한다.

Beans

Java Beans : 데이터 표현이 목적인 자바 객체

멤버 변수는 private 속성이다.
getter와 setter를 가진다.

4. Active Record vs Data Mapper

Active Record

Database row를 객체에 매핑하는 패턴

비즈니스 로직 메서드를 추가해 객체로 취급하는 건 바람직하지 않다.

비즈니스 로직을 담으면서 내부 자료를 숨기는 객체는 따로 생성한다.

객체가 row를 담을 뿐 아니라 database에 대한 접근을 포함한다.
Person의 속성을 담을 뿐 아니라, 생성/수정도 객체 안에서 수행할 수 있다.
사례 - Ruby on rails

Data Mapper

row를 담는 객체와 database에 접근할 수 있는 객체가 분리 되어 있다.
Person은 값만 담고 있고, 생성/수정 등 액션은 PersonMapper에서 담당 한다.
사례-Hibernate

출처

Clean Code(클린 코드) 애자일 소프트웨어 장인 정신 - 로버트 C. 마틴 지음

https://zero-base.co.kr/category_dev_camp/cleancode_1book

[Spring] 1. 스프링 컨테이너

mandykr — Fri, 4 Mar 2022 14:33:45 +0900

1. DI 컨테이너

2. 스프링 컨테이너

3. 싱글톤 컨테이너

1. DI 컨테이너

회원을 생성하고 회원 등급에 따라 할인 정책을 적용해 상품에 대한 주문을 처리하는 서비스이다.

주문 서비스의 도메인 구조가 위와 같을 때,

회원 저장 역할은 데이터베이스가 변경됨에 따라 함께 변경될 수 있고

할인 정책 역할은 회원의 등급에 따라 다른 정책을 적용하는 등 변경 가능성이 높다.

다음과 같이 주문 서비스가 회원 저장소와 할인 정책의 구현체에 의존하면 확장에 의한 변경에 대응할 수 없게 된다.

코드를 보면 주문 서비스가 회원 저장소의 구현체인 MemoryMemberRepository와 할인 정책의 구현체인 FixDiscountPolicy에 의존하고 있다.

데이터베이스가 변경되거나 할인 정책이 변경되면 비즈니스 코드인 OrderServiceImpl 클래스를 수정해 주어야 한다.

public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository = new MemoryMemberRepository();
    private final DiscountPolicy discountPolicy = new FixDiscountPolicy();
    
    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);
        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}

따라서 OCP와 DIP원칙에 따라 다음과 같이 역할과 구현을 분리해 주어야 한다.

역할을 추상화 하면 구현 객체를 자유롭게 조립하면서 유연하게 회원 저장소와 할인 정책을 변경할 수 있다.

회원 저장소와 할인 정책의 역할을 정의하는 인터페이스와 역할을 구현하는 클래스를 만들고 주문 서비스가 추상에 의존하도록 설정하였다.

아직은 구현 객체가 주문 서비스 내에 없기 때문에 NPE(null pointer exception)가 발생하고 애플리케이션은 정상적으로 동작하지 않는다.

다음으로 SRP원칙에 따라 구현 객체를 생성하고 연결하는 책임을 별도의 클래스가 갖도록 위임하고 주문 서비스는 해당 객체를 전달받아 사용하며 주문에 대한 기능에만 집중하도록 할 수 있다.

구성 역할을 하는 AppConfig 클래스를 만들어 사용한다.

public class AppConfig {
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
    
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }
    
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    
    public DiscountPolicy discountPolicy() {
        return new FixDiscountPolicy();
    }
}

애플리케이션을 실행하는 시점에 AppConfig에서 필요한 객체를 꺼내 전달하고

public class OrderApp {
    public static void main(String[] args) {
        AppConfig appConfig = new AppConfig();
        
        MemberService memberService = appConfig.memberService();
        OrderService orderService = appConfig.orderService();
    }
}

주문 서비스에서는 생성자를 통해 객체를 전달받아 사용한다.

public class OrderServiceImpl implements OrderService {
    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;
    
    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
        this.memberRepository = memberRepository;
        this.discountPolicy = discountPolicy;
    }
    
    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);
        return new Order(memberId, itemName, itemPrice, discountPrice);
    }
}

AppConfig의 등장으로 객체를 생성하고 구성하는 영역과 사용 영역으로 관심사가 분리되었고 회원 저장소와 할인 정책이 변경되어도 사용 영역은 전혀 영향을 받지 않게되었다.

위와 같이 필요한 구현 객체를 생성하고 사용하며 프로그램의 제어를 스스로 하지 않고 AppConfig 처럼 외부에서 프로그램의 흐름을 제어하는 것을 제어의 역전(IoC)이라고 한다. 사용 영역에서는 추상에 의존하며 프로그램의 제어가 역전되었기 때문에 외부에서 전달되는 객체에 신경쓰지 않고 자신의 로직을 실행하는 역할만 담당하게 된다.

애플리케이션 실행 시점(런타임)에 외부에서 실제 객체를 생성하고 사용 영역에 전달해서 실제 의존관계가 연결되는 것을 의존관계 주입(DI)이라고 하며, AppConfig 처럼 DI를 담당하는 것을 DI 컨테이너라고 한다.

2. 스프링 컨테이너

@Configuration, @Bean 어노테이션으로 스프링이 AppConfig를 사용해서 컨테이너를 생성하고 DI를 하도록 설정할 수 있다.

@Configuration
public class AppConfig {
    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }
    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }
    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
    @Bean
    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

스프링은 @Configuration이 붙은 AppConfig를 설정정보로 사용한다.

@Bean이 붙은 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다.

이 스프링 빈은 @Bean이 붙은 메서드의 이름을 빈의 이름으로 사용한다.

ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
MemberService memberService = ac.getBean("memberService", MemberService.class);

설정 정보(AppConfig)를 전달해 스프링 컨테이너를 생성하고 ApplicationContext 에서 스프링 빈을 꺼내 사용한다.

스프링 컨테이너는 BeanFactory와 ApplicationContext로 구분되어 있는데

ApplicationContext가 BeanFactory를 상속하고 있는 구조이다. 하단 설명 참고.

위의 코드에서 자바 설정 클래스를 기반으로 AnnotationConfigApplicationContext를 생성했는데 XML 기반으로 GenericXmlApplicationContext를 생성할 수 있다.

두 개 모두 인터페이스인 ApplicationContext의 구현체이다.

1) 스프링 컨테이너 생성 과정

스프링은 스프링 빈을 생성하고, 의존관계를 설정하는 단계가 나누어져 있다.

스프링 빈 생성

파라미터로 넘어온 클래스 정보를 사용해서 스프링 빈을 등록한다.

스프링 빈 이름은 메서드 이름을 사용하지만 @Bean(name="memberService2")와 같이 직접 부여할 수도 있다.

의존관계 설정

실제 자바 코드로 스프링 빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한번에 처리된다.

하지만 단순히 자바 코드를 호출하는 것과는 차이가 있다.

참고: 의존관계 자동 주입, 싱글톤 컨테이너

2) 스프링 빈 조회

(1) 모든 빈 조회 : ac.getBeanDefinitionNames()

스프링 컨테이너에 등록된 모든 빈

String[] beanDefinitionNames = ac.getBeanDefinitionNames();
for (String beanDefinitionName : beanDefinitionNames) {
    Object bean = ac.getBean(beanDefinitionName);
    System.out.println("name=" + beanDefinitionName + " object=" + bean);
}

애플리케이션 빈

String[] beanDefinitionNames = ac.getBeanDefinitionNames();
for (String beanDefinitionName : beanDefinitionNames) {
    BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);
    
    //Role ROLE_APPLICATION: 직접 등록한 애플리케이션 빈
    //Role ROLE_INFRASTRUCTURE: 스프링이 내부에서 사용하는 빈
    if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
        Object bean = ac.getBean(beanDefinitionName);
        System.out.println("name=" + beanDefinitionName + " object=" + bean);
    }
}

(2) 스프링 빈 조회 : ac.getBean(빈이름, 타입)

빈 이름으로 조회

MemberService memberService = ac.getBean("memberService", MemberService.class);

타입만으로 조회

MemberService memberService = ac.getBean(MemberService.class);

이름과 타입으로 조회

MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);

타입으로 모든 빈 조회

Map<String, MemberRepository> beansOfType = ac.getBeansOfType(MemberRepository.class);
for (String key : beansOfType.keySet()) {
    System.out.println("key = " + key + " value = " + beansOfType.get(key));
}

상속 관계 스프링 빈 조회

부모 타입으로 조회하면 모든 자식 타입도 함꼐 조회된다.

Object 타입으로 조회하면 모든 빈이 조회된다.

Map<String, DiscountPolicy> beansOfType = ac.getBeansOfType(DiscountPolicy.class);
for (String key : beansOfType.keySet()) {
    System.out.println("key = " + key + " value=" + beansOfType.get(key));
}

예외

조회 대상 스프링 빈이 없는 경우 : NoSuchBeanDefinitionException

조회 대상 스프링 빈이 둘 이상인 경우 : NoUniqueBeanDefinitionException

3) BeanFactory와 ApplicationContext

BeanFactory : 빈 관리기능

가 스프링 컨테이너 최상위 인터페이스 이고, 스프링 빈을 관리하고 조회하는 역할을 담당한다.

(getBean() 등 제공)

ApplicationContext : 빈 관리기능 + 편리한 부가 기능

빈을 관리하고 검색하는 기능은 BeanFactory의 기능을 상속받아서 사용하고.

애플리케이션을 개발할 때 필요한 부가 기능을 여러 인터페이스에서 상속받아 제공한다.

MessageSource

메시지소스를 활용한 국제화 기능
한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력

EnvironmentCapable

환경변수
로컬, 개발, 운영등을 구분해서 처리

ApplicationEventPublisher

애플리케이션 이벤트
이벤트를 발행하고 구독하는 모델을 편리하게 지원

ResourceLoader

편리한 리소스 조회
파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

ApplicationContext 구현체

스프링 컨테이너는 다양한 ApplicationContext의 구현체를 제공하기 때문에 애플리케이션의 설정정보를 유연하게 변경할 수 있다.

4) BeanDefinition

다양한 설정 파일을 통해 스프링 컨테이너가 스프링 빈을 생성할 수 있는 이유는

각각 빈에 대한 메타정보를 BeanDefinition이라는 추상화를 만들기 때문이다.

설정 형식 각각 BeanDefinitionReader를 통해 BeanDefinition을 만들고

스프링 컨테이너는 BeanDefinition에 저장된 빈에 대한 메타정보를 기반을 스프링 빈을 생성한다.

BeanDefinition 정보

BeanClassName: 생성할 빈의 클래스 명(자바 설정 처럼 팩토리 역할의 빈을 사용하면 없음)
factoryBeanName: 팩토리 역할의 빈을 사용할 경우 이름, 예) appConfig
factoryMethodName: 빈을 생성할 팩토리 메서드 지정, 예) memberService
Scope: 싱글톤(기본값)
lazyInit: 스프링 컨테이너를 생성할 때 빈을 생성하는 것이 아니라, 실제 빈을 사용할 때 까지 최대한 생성을 지연처리 하는지 여부
InitMethodName: 빈을 생성하고, 의존관계를 적용한 뒤에 호출되는 초기화 메서드 명
DestroyMethodName: 빈의 생명주기가 끝나서 제거하기 직전에 호출되는 메서드 명
Constructor arguments, Properties: 의존관계 주입에서 사용한다. (자바 설정 처럼 팩토리
역할의 빈을 사용하면 없음)

자바 설정 파일을 통해 BeanDefinition의 정보를 만들때는 외부에서 AppConfig의 메소드를 호출하는 팩토리 메소드 방식이기 때문에 BeanClassName이 비어있고 factoryBeanName, factoryMethodName이 등록되어 있다.

3. 싱글톤 컨테이너

1) 싱글톤 패턴

순수한 DI 컨테이너인 AppConfig는 요청을 할 때마다 객체를 새로 생성하기 때문에 메모리 낭비가 심하다.

따라서 클래스의 인스턴스를 1개만 만들어 공유하도록 DI 객체를 구성하기 위한 클래스에 싱글톤 패턴을 적용해야 한다.

static 영역에 인스턴스를 미리 1개 만들어 올려두고 getInstance() 메서드를 통해서만 인스턴스를 제공한다.

생성자는 private으로 선언해 외부에서의 객체생성 요청을 막는다.

public class SingletonService {
    //1. static 영역에 객체를 딱 1개만 생성해둔다.
    private static final SingletonService instance = new SingletonService();
    
    //2. public으로 열어서 객체 인스터스가 필요하면 이 static 메서드를 통해서만 조회하도록 허용한다.
    public static SingletonService getInstance() {
        return instance;
    }
    
    //3. 생성자를 private으로 선언해서 외부에서 new 키워드를 사용한 객체 생성을 못하게 막는다.
    private SingletonService() {
    }
    
    public void logic() {
        System.out.println("싱글톤 객체 로직 호출");
    }
}

// Test
SingletonService singletonService1 = SingletonService.getInstance();
SingletonService singletonService2 = SingletonService.getInstance();
assertThat(singletonService1).isSameAs(singletonService2);

싱글톤 패턴을 적용해서 고객의 요청에 대해 하나의 인스턴스를 공유하도록 만들었지만

다음과 같은 문제점이 있다.

싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다.
클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
테스트하기 어렵다.
내부 속성을 변경하거나 초기화 하기 어렵다.
private 생성자로 자식 클래스를 만들기 어렵다.
결론적으로 유연성이 떨어진다.
안티패턴으로 불리기도 한다.

2) 싱글톤 컨테이너

스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서, 객체 인스턴스를 싱글톤으로 관리한다.

싱글톤 패턴을 위한 위의 예제와 같은 지저분한 코드가 들어가지 않아도 되고,

DIP, OCP, 테스트, private 생성자로 부터 자유롭게 싱글톤을 사용할 수 있다.

3) @Configuration과 싱글톤

@Configuration은 AppConfig와 같은 설정정보 클래스의 빈을 스프링 컨테이너에 등록할 때

CGLIB 바이트 코드 조작 라이브러리를 사용한다.

실제로 AppConfig는 컨테이너에 등록하지 않고 AppConfig를 상속받는 클래스의 빈을 등록한다.

스프링 컨테이너에서 AppConfig 타입으로 빈을 조회해 보면 클래스의 타입이 다른 것을 확인할 수 있다.

ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
AppConfig bean = ac.getBean(AppConfig.class);
System.out.println("bean = " + bean.getClass());

@Configuration을 사용하지 않은 경우

bean = class hello.core.AppConfig

@Configuration을 사용한 경우

bean = class hello.core.AppConfig$$EnhancerBySpringCGLIB$$bd479d70

AppConfig@CGLIB

AppConfig@CGLIB 는 AppConfig를 통해 등록되는 빈들의 싱글톤을 보장해준다.

@Bean을 통해 컨텍스트에 스프링 빈을 등록할 수 있지만 @Configuration이 없으면 스프링 빈 간의 의존 관계에서 싱글톤을 보장하지 않는다.

AppConfig를 통해 @Configuration과 싱글톤을 테스트 해본다.

AppConfig에서 MemoryMemberRepository가 생성되는 메소드는 3곳이다.

memberService(), orderService(), memberRepository()

@Configuration이 싱글톤을 보장해 주더라도 AppConfig를 통해 스프링 빈을 만들면

memberRepository()는 3번 호출되어야 한다.

public class AppConfig {
    @Bean
    public MemberService memberService() {
        System.out.println("call AppConfig.memberService");
        return new MemberServiceImpl(memberRepository());
    }
    
    @Bean
    public OrderService orderService() {
        System.out.println("call AppConfig.orderService");
        return new OrderServiceImpl(
                memberRepository(),
                discountPolicy());
    }
    
    @Bean
    public MemberRepository memberRepository() {
        System.out.println("call AppConfig.memberRepository");
        return new MemoryMemberRepository();
    }
    
    @Bean
    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

// Test
ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
MemberServiceImpl memberService = ac.getBean("memberService", MemberServiceImpl.class);
OrderServiceImpl orderService = ac.getBean("orderService", OrderServiceImpl.class);
MemberRepository memberRepository = ac.getBean("memberRepository", MemberRepository.class);

System.out.println("memberService -> memberRepository = " + memberService.getMemberRepository());
System.out.println("orderService -> memberRepository = " + orderService.getMemberRepository());
System.out.println("memberRepository = " + memberRepository);

@Configuration 없이 테스트해 보면 총 3번의 memberRepository()가 호출된다.

결국 new 키워드로 memberRepository를 생성하기 때문에 모두 다른 객체이며 싱글톤을 보장하지 않는다.

call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.orderService
call AppConfig.memberRepository
call AppConfig.memberRepository

@Configuration 을 사용하면 memberRepository()가 단 한번만 호출되기 때문에 싱글톤을 보장한다.

call AppConfig.memberService
call AppConfig.memberRepository
call AppConfig.orderService

위의 테스트에서 볼 수 있듯이 @Configuration은 이미 스프링 컨테이너에 등록된 빈은

새롭게 생성하지 않는다는 것을 확인할 수 있고 이 것이 가능한 건 AppConfig가 아닌

AppConfig@CGLIB를 사용하기 때문이다.

AppConfig@CGLIB 예상 코드

@Bean
public MemberRepository memberRepository() {

    if (memoryMemberRepository가 이미 스프링 컨테이너에 등록되어 있으면?) {
        return 스프링 컨테이너에서 찾아서 반환;
    } else { //스프링 컨테이너에 없으면
        기존 로직을 호출해서 MemoryMemberRepository를 생성하고 스프링 컨테이너에 등록
        return 반환;
    }
}

@Bean만 사용해도 스프링 빈으로 등록되지만 memberRepository()처럼 의존관계 주입이 필요해서 메서드를 직접 호출하는 경우에는 싱글톤을 보장하지 않지만 @Configuration을 통해 가능하다.

4) 싱글톤 방식의 주의점

싱글톤 패턴이든, 스프링 같은 싱글톤 컨테이너를 사용하든,

객체 인스턴스를 하나만 생성해서 공유하기 떄문에 싱글톤 객체는 무상태로 설계해야 한다.

특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안되고 가급적 읽기만 가능하도록 해야한다.

필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.

public class StatefulService {
    private int price; //상태를 유지하는 필드
    
    public void order(String name, int price) {
        System.out.println("name = " + name + " price = " + price);
        this.price = price; //여기가 문제!
    }
    
    public int getPrice() {
        return price;
    }
}

statefulService1.order("userA", 10000);
statefulService2.order("userB", 20000);
int price = statefulService1.getPrice(); //20000원 출력

StatefulService를 price라는 상태를 갖도록 설계하고 스프링 빈으로 등록하였다.

userA, userB가 싱글톤 객체를 공유하기 때문에 price 필드를 공유한다.

userA의 주문 금액이 userB에 의해 변경되는 문제가 발생하게 된다.

출처

스프링 핵심 원리 - 기본편(김영한)

[클린코드] 5. 형식 맞추기

mandykr — Thu, 3 Mar 2022 17:14:14 +0900

1. 형식을 맞추는 목적

2. 적절한 코드 형식을 작성하는 방법

3. 클래스 및 인터페이스 선언

4. TeamCodingConvention

5. 참고할 만한 컨벤션

1. 형식을 맞추는 목적

좋은 소프트웨어 시스템은 읽기 쉬운 문서로 이루어 져야 하기 때문에

소스 코드의 스타일이 일관적이고 매끄러워야 한다.

스타일과 가독성 수준은 유지보수 용이성과 확정성에 계속 영향을 미치기 때문에

한 소스 파일에서 봤던 형식이 다른 소스 파일에도 쓰이리라는 신뢰감을 독자에게 주어야 한다.

2. 적절한 코드 형식을 작성하는 방법

신문 기사와 같이 위에서 아래로 자연스럽게 읽히며 고차원에서 시작해 마지막에 저차원의 개념이 나오도록 작성한다.

1) 개념은 빈 행으로 분리

각 행은 수식이나 절을 나타내고, 일련의 행 묶음은 완결된 생각 하나를 표현한다.

생각 사이에는 빈 행을 넣어 분리한다.

2) 클래스의 적절한 행 길이

코드길이를 200 줄정도로 제한 하는것은 반드시 지킬 엄격한 규칙은 아니지만,

일반적으로 큰 파일보다 작은 파일이 이해하기 쉬우며

클래스가 200 라인을 넘어가는 큰 파일인 경우 여러가지 일을 하고 있는지 의심해 봐야 한다.

3) 수직 거리

서로 밀접한 개념은 가능한 같은 파일에 세로로 가까이 둬야 한다.

변수 선언

지역 변수는 각 함수 맨 처음에 위치하도록 한다.

인스턴스 변수는 통상적으로 잘 알려진 위치(최상단)에 세로로 거리를 두지 않고 작성한다.

종속 함수

한 함수가 다른 함수를 호출한다면 두 함수는 세로로 가까이 배치한다.

호출하는 함수를 호출되는 함수보다 위쪽에 배치한다.

가로 공백과 밀집도

가로로는 공백을 사용해 밀접한 개념과 느슨한 개념을 표현한다.

연산자와 피연산자, 함수의 인수간에는 공백을 사용하고

함수 이름과 이어지는 괄호 사이에는 공백을 넣지 않는다.

3. 클래스 및 인터페이스 선언

오라클 문서에서 권장하는 Class 내부 코드 순서 Oracle Code Convention

1) static변수 : public -> protected -> package -> private순서
2) instance변수 : public -> protected -> package -> private
3) 생성자
4) 메서드 : public 메서드에서 호출되는 private 메서드는 그 아래에 둔다. 가독성 위주로 그룹핑.

4. Team Coding Convention

개발 언어의 컨벤션이 우선이지만, 애매한 부분은 팀 컨벤션을 따른다.

예) [MySQL Convention] - 컬럼명은 snake_case로 네이밍한다.

예) [Team Convention] - enum 타입으로 사용하는 varchar 타입의 경우 컬럼명은 _type으로 끝나도록 네이밍한다.

5. 참고할 만한 컨벤션

1) Google Java Style Guide

2) Naver Hackday Java Convention

출처

Clean Code(클린 코드) 애자일 소프트웨어 장인 정신 - 로버트 C. 마틴 지음

https://zero-base.co.kr/category_dev_camp/cleancode_1book

[JPA] 7. 값 타입

mandykr — Wed, 2 Mar 2022 16:50:19 +0900

1. JPA의 데이터 타입 분류

2. 임베디드 타입(복합 값 타입)

3. 값 타입과 불변 객체

4. 값 타입의 비교

5. 값 타입 컬렉션

1. JPA의 데이터 타입 분류

1) 엔티티 타입

@Entity로 정의하는 객체
데이터가 변해도 식별자로 지속해서 추적 가능

2) 값 타입

자바 기본 타입이나 객체
식별자가 없고 값만 있으므로 변경시 추적 불가

(1) 기본값 타입

자바 기본 타입(int, double)
래퍼 클래스(Integer, Long)
String

항상 값을 복사하기 때문에 절대 공유되지 않는다.

Integer같은 래퍼 클래스나 String 같은 특수한 클래스는 공유 가능한 객체이지만 변경되지 않는다.

(2) 임베디드 타입(embedded type, 복합 값 타입)

(3) 컬렉션 값 타입(collection value type)

2. 임베디드 타입(복합 값 타입)

새로운 값 타입을 직접 정의하여 임베디드 타입이라는 이름으로 매핑한다.

Member 엔티티의 임베디드 타입으로 Period, Address 클래스를 만들어 매핑하면

각각 클래스의 필드가 하나의 DB 테이블에 컬럼으로 매핑된다.

임베디드 타입 사용법

@Embeddable: 값 타입을 정의하는 곳에 표시
@Embedded: 값 타입을 사용하는 곳에 표시
기본 생성자 필수
임베디드 타입을 포함한 모든 값 타입은, 값 타입을 소유한 엔티 티에 생명주기를 의존함

@Entity
public class Member extends BaseEntity {
    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;

    private String name;

    @Embedded
    private Period period;

    @Embedded
    private Address address;
}

@Embeddable
public class Period {
    private LocalDateTime startDate;
    private LocalDateTime endDate;

    public boolean isWork() {
    	...
        return true;
    }
}

임베디드 타입은 엔티티의 값일 뿐이기 때문에 다음과 같이 속성을 정의하는 것이 가능하다.

@Column(name = "ZIPCODE")
private String zipcode;

임베디드 타입의 장점

재사용
높은 응집도
Period.isWork()처럼 해당 값 타입만 사용하는 의미 있는 메소드를 만들 수 있음
객체와 테이블을 아주 세밀하게(find-grained) 매핑하는 것이 가능

임베디드 타입과 연관관계

임베디드 타입은 다시 임베디드 타입의 값과 엔티티를 필드로 갖을 수 있다.

@AttributeOverride: 속성 재정의

한 엔티티에서 같은 값 타입을 사용하는 경우

@Embedded
private Address homeAddress;

@Embedded
@AttributeOverrides({
        @AttributeOverride(name="city",
                column=@Column(name = "WORK_CITY")),
        @AttributeOverride(name="street",
                column=@Column(name = "WORK_STREET")),
        @AttributeOverride(name="zipcode",
                column=@Column(name = "WORK_ZIPCODE"))
private Address workAddress;
})

3. 값 타입과 불변 객체

1) 값 타입 공유 참조

임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 부작용(side effect) 발생한다.

Address address = new Address("city", "street", "zipcode");

Member member1 = new Member("member1");
member1.setHomeAddress(address);

Member member2 = new Member("member2");
member2.setHomeAddress(address);

em.persist(member1);
em.persist(member2);

member2.getHomeAddress().setCity("newCity");

회원1과 회원2의 city값이 모두 변경된다.

2) 값 타입 복사

공유 참조가 아닌 값(인스턴스)를 복사해서 사용하여 부작용을 막는다.

Address address = new Address("city", "street", "zipcode");

Member member1 = new Member("member1");
member1.setHomeAddress(address);

Address newAddress = new Address(address.getCity(), address.getStreet(), address.getZipcode());
Member member2 = new Member("member2");
member2.setHomeAddress(newAddress);

em.persist(member1);
em.persist(member2);

member2.getHomeAddress().setCity("newCity");

3) 불변 객체

객체 타입의 한계

임베디드 타입은 객체 타입이기 때문에 참조 값을 직접 대입해 사용하는

공유 참조를 컴파일 단계에서 막을 방법이 없다.

따라서 값 타입을 불변 객체로 설계하여 객체 타입을 수정할 수 없게 만들어야 한다.

불변 객체

생성 시점 이후 절대 값을 변경할 수 없는 객체

생성자로만 값을 설정하고 수정자(setter)를 만들지 않아야 한다.

(ex, Integer, String)

값을 변경해야 할 때에는 객체를 새롭게 생성해서 사용한다.

Address newAddress = new Address("newCity", address.getStreet(), address.getZipcode());
member2.setHomeAddress(newAddress);

4. 값 타입의 비교

값 타입은 a.equals(b)를 사용해서 동등성 비교를 해야 한다.
값 타입의 equals() 메소드를 적절하게 재정의(주로 모든 필드 사용)

@Override
public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    Address address = (Address) o;
    return city.equals(address.city) && street.equals(address.street) && zipcode.equals(address.zipcode);
}

@Override
public int hashCode() {
    return Objects.hash(city, street, zipcode);
}

5. 값 타입 컬렉션

favoriteFoods, addressHistory와 같이 값 타입을 하나 이상 사용하는 경우

컬렉션을 별도의 테이블 FAVORITE_FOOD, ADDRESS에 저장한다.

값 타입 컬렉션 사용법

public class Member extends BaseEntity {
    @Id @GeneratedValue
    @Column(name = "MEMBER_ID")
    private Long id;
    private String name;
    
	// ...
    
    @Embedded
    private Address homeAddress;

    @ElementCollection
    @CollectionTable(name = "FAVORITE_FOOD", joinColumns =
        @JoinColumn(name = "MEMBER_ID")
    )
    @Column(name = "FOOD_NAME")
    private Set<String> favoriteFoods = new HashSet<>();

    @ElementCollection
    @CollectionTable(name = "ADDRESS", joinColumns =
        @JoinColumn(name = "MEMBER_ID")
    )
    private List<Address> addressHistory = new ArrayList<>();
}

값 타입 컬렉션 저장

Member member = new Member("member");
member.setHomeAddress(new Address("homeCity", "street", "zipcode"));

member.getFavoriteFoods().add("치킨");
member.getFavoriteFoods().add("족발");
member.getFavoriteFoods().add("피자");

member.getAddressHistory().add(new Address("oldCity1", "street", "zipcode"));
member.getAddressHistory().add(new Address("oldCity2", "street", "zipcode"));

em.persist(member);

favoriteFoods, addressHistory가 별도의 테이블로 관리되지만

단순히 엔티티의 값 타입이기 때문에 Member와 생명주기가 동일하다.

값 타입 컬렉션은 영속성 전이(Cascade) + 고아 객체 제거 기능을 필수로 가진다고 볼 수 있다.

값 타입 컬렉션 조회

값 타입 컬렉션은 기본적으로 지연 로딩을 사용한다.

기본 값 타입과 임베디드 값 타입은 기본적으로 즉시 로딩으로 조회하고

favoriteFoods, addressHistory는 사용하는 시점에 조회한다.

Member findMember = em.find(Member.class, member.getId());

Set<String> favoriteFoods = findMember.getFavoriteFoods();
for (String favoriteFood : favoriteFoods) {
    System.out.println("favoriteFood = " + favoriteFood);
}

List<Address> addressHistory = findMember.getAddressHistory();
for (Address address : addressHistory) {
    System.out.println("address = " + address);
}

값 타입 컬렉션 수정

String 타입

Member findMember = em.find(Member.class, member.getId());
findMember.getFavoriteFoods().remove("치킨");
findMember.getFavoriteFoods().add("한식");

DB 테이블에서 delete와 insert 가 실행된다.

Object 타입

컬렉션에서 remove는 equals()로 동작하기 때문에 Address 클래스에 equals(), hashCode()를 재정의 해야 한다.

// 저장
member.getAddressHistory().add(new Address("oldCity1", "street", "zipcode"));
member.getAddressHistory().add(new Address("oldCity2", "street", "zipcode"));

// 수정
Member findMember = em.find(Member.class, member.getId());
findMember.getAddressHistory().remove(new Address("oldCity1", "street", "zipcode"));
findMember.getAddressHistory().add(new Address("newCity1", "street", "zipcode"));

값 타입 컬렉션에 변경 사항이 발생하면,

주인 엔티티와 연관된 모든 데이터를 삭제하고, 값 타입 컬렉션에 있는 현재 값을 모두 다시 저장한다.

값 타입은 엔티티와 다르게 식별자 개념이 없고 값을 변경하면 추적이 어렵다.

값 타입 컬렉션을 매핑하는 테이블은 모든 컬럼을 묶어서 기본키를 구성해야 한다. (null 입력X, 중복 저장X)

값 타입 컬렉션 대안

실무에서는 상황에 따라 값 타입 컬렉션 대신에 일대다 관계를 고려해야 한다.
일대다 관계를 위한 엔티티를 만들고, 여기에서 값 타입을 사용.
영속성 전이(Cascade) + 고아 객체 제거를 사용해서 값 타입 컬렉션 처럼 사용.

// Member Class
@OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
@JoinColumn(name = "MEMBER_ID")
private List<AddressEntity> addressHistory = new ArrayList<>();

@Entity
@Table(name = "ADDRESS")
public class AddressEntity {
    @Id @GeneratedValue
    private Long id;
    private Address address;
    
    public boolean isSame(AddressEntity addressEntity) {
        return this.address.equals(addressEntity.getAddress());
    }
    
    /...
}

AddressEntity findAddress = addressHistory.stream()
        .filter(a -> a.isSame(oldAddress))
        .findFirst()
        .orElseThrow(IllegalArgumentException::new);
findAddress.setAddress(newAddress.getAddress()); // 편의상 setter 사용

값 타입 컬렉션은 단순히 저장만 하고 추적할 필요가 없는 경우에만 사용하자.

출처

https://www.inflearn.com/course/ORM-JPA-Basic 자바 ORM 표준 JPA 프로그래밍 - 기본편(김영한)

[ATDD] 4. 테스트 기반 문서화

mandykr — Thu, 17 Feb 2022 16:07:43 +0900

1. ATDD + 문서화

2. 문서 자동화

3. Spring Rest Docs 프로세스

4. ATDD + 문서 자동화

1. ATDD + 문서화

내부 개발자든 외부 파트너든 새로운 사용자를 온보딩하는 데 소요되는 시간을 줄여줄 뿐만 아니라

API에 대한 이해와 활용도를 높이기 위해선 API의 정보를 문서화 하는 작업이 필요하다.

ATDD + TDD cycle 로 개발하면서 어느 시점에 문서화 작업을 진행할 수 있을까?

개발 전 문서화 장점

백엔드 개발자간 병렬 작업
백엔드 & 프론트엔드 개발자간 병렬 작업
커뮤니케이션 비용을 줄일 수 있음

2. 문서 자동화

문서를 코드레벨에서 관리할 수 있도록 하여

문서와 기능에 대한 동기화 작업이 없어지기 때문에 두 개의 관리 포인트를 하나로 줄여준다.

Swagger

Swagger는 API call하여 테스트하는 기능에 특화
Swagger는 기능이 많은 반면에 Spring Rest Docs는 단순히 문서임
Swagger 사용 시 불필요한 프로덕션 코드 오염이 발염

Spring Rest Docs

테스트 코드에 설정(및 작성)하여 프로덕션 코드에 영향이 적음
Swagger의 api call 기능은 intellij(local)에서 Http Request하는 기능을 사용하여 대체함

3. Spring Rest Docs 프로세스

1) Test

컨트롤러 계층에 대한 api 테스트를 작성한다.

테스트 작성 과정에서 문서화에 필요한 요청, 응답 Snippet 정보를 작성해 세팅한다.

2) Spring Rest Docs

테스트를 활용해(테스트 실행) 문서화에 사용될 코드 조각(Snippet)을 만든다.

3) 문서 템플릿

Adoc 문서 템플릿 파일에 Snipet 들을 가져와 필요한 위치에 include 한다.

4) Asciidoctor

Asciidoctor를 실행해 Adoc 파일을 활용하여 html 문서를 만든다.

gradle 설정 등 전체 코드 확인 github

4. ATDD + 문서 자동화

개발 순서

1) 인수 테스트 만들기

2) 컨트롤러(응답하는 부분만) 만들기

3) 응답값이 있는 경우 응답값 생성 로직은 서비스로 위임

4) 위임한 부분(서비스)에 대한 stubbing 하고 문서화 테스트 만들기

5) TDD 로 기능 구현

출처

[ATDD] 3. ATDD 기반 리팩터링

mandykr — Tue, 15 Feb 2022 12:11:40 +0900

1. 인수 테스트 통합

2. 레거시 리팩터링

1. 인수 테스트 통합

1) 인수 테스트 리팩터링

인수 테스트를 다음 세가지 방법으로 리팩터링 하면서 활용해 볼 수 있다.

인수 테스트 리팩터링 : 메소드 분리, 스텝 분리 참고
단위 테스트로 분리 : 비지니스 규칙에 대한 부분을 단위 테스트로 분리
인수 테스트 통합 : CRUD 각각의 인수 테스트를 하나로 통합

2) 인수 테스트의 검증 범위

인수 테스트에서 요청에 대한 검증을 어느정도 까지 해야할지에 대한 고민.

응답 코드로 확인하는 방법

요청을 한번 더 보내서 응답값을 확인하는 방법

given/when/then 이후 추가 스탭이 필요함

테스트 목적은 다르지만 같은 로직을 검증하는 인수 테스트가 발생할 수 있음

(생성에 대한 인수 테스트에서 조회에 대한 검증이 포함되기 때문에 조회에 대한 인수 테스트와 함께 조회 중복 검증이 발생한다.)

3) 인수 테스트 통합

생성, 조회 등 CRUD에 대한 각각의 인수 테스트를 하나로 통합하는 방식으로 리팩터링을 진행한다.

인수 테스트 검증 범위에 대한 고민을 어느정도 줄여줄 수 있다.

인수 테스트 통합 예시

단점

하나의 테스트가 많은 것을 검증하게 된다.

테스트를 작성하기 어려워진다.

장점

api 단위가 아닌 사용자 관점의 기능과 플로우를 검증 대상으로 설정할 수 있다. (Journy Test or Story Test)

테스트 비용을 절감할 수 있다.

스텝의 중복을 효과적으로 제거할 수 있다.사이드 케이스는 단위 테스트에서 수행하게 유도할 수 있다.

방법

(1) 기존 처럼 따로 만든 다음 하나로 통합하기

(2) 처음부터 하나의 테스트 메서드로 한 스텝씩 검증하면서 구현하기

2. 레거시 리팩터링(인수 테스트를 이용한)

1) 인수 테스트가 있는 경우

인수 테스트가 있으면 레거시를 리팩터링 할 때 인수테스트가 성공하는 시점으로 돌아갈 수 있기 때문에

기능 변경 혹은 리팩터링을 하더라도 마음껏 할 수 있다.

2) 인수 테스트가 없는 경우

스트랭글러패턴 참고

인수 테스트를 먼저 만들고 시작세부 구현에 의존하지 않는 블랙박스 테스트이기 때문에 기능이 변경되어도 테스트가 가능하다.

인수 테스트 다음 스텝

인수 테스트를 성공시키기 위한 단위 테스트 작성
단위 테스트를 성공시기기 위한 기능 구현 (or 리팩터링)
단위 테스트 성공 후 리팩터링
그리고 반복

레거시 리팩터링 단계

기존의 프로덕션 코드를 바로 수정하면 변경한 부분을 의존하는 부분에서 문제가 발생

기존의 테스트 코드를 바로 수정하면 기존의 프로덕션 코드를 검증할 수 없게됨

새로운 테스트 만들기(ATDD + TDD)
기능 구현하기
기존 테스트, 프로덕션 코드 제거

기능 구현하기 단계

기존 코드와 신규 코드가 함께 존재함

기존 코드가 유지되기 때문에 이슈가 발생하지 않음

기존 코드와 신규 코드가 혼재되는 기간을 짧게 가져가도록 해야함

출처

[ATDD] 2. ATDD + TDD

mandykr — Mon, 7 Feb 2022 13:53:06 +0900

1. 단위 테스트

2. 협력 객체

3. 통합과 고립(Sociable and Solitary)

4. Test Double

5. Classist TDD vs Mockist TDD

6. ATDD + TDD Cycle

TDD, ATDD 란?

ATDD(Acceptance Test Driven Development) 참고

1. 단위 테스트

단위 테스트란?

단위는 클래스, 메소드 등 정의하기 나름이지만 단위 테스트의 목적은

작은 코드 조각에 대한 검증에 있다.

따라서 단위 테스트는 다른 종류의 테스트 보다 수행 속도가 빠르다.

2. 협력 객체

@Service
@Transactional
public class LineService {
    private final LineRepository lineRepository;

    public LineService(LineRepository lineRepository) {
        this.lineRepository = lineRepository;
    }
    
    public LineResponse saveLine(LineRequest request) {
        Line line = lineRepository.save(new Line(request.getName(), request.getColor()));
        return LineResponse.of(line);
    }
}

Service 계층의 메소드에 대한 단위 테스트를 작성할 때 Repository 객체에 의존하고 있으면

Repository 객체가 단위 테스트의 협력 객체가 된다.

협력 객체가 있는 경우

협력 객체가 없는 경우는 비교적 테스트가 쉽지만,

반대의 경우 협력객체의 상태와 의존성을 고려해야 하기 때문에 복잡도가 높아진다.

3. 통합과 고립(Sociable and Solitary)

협력 객체의 사용 방식에 따라 다음 두 가지 단위 테스트로 나눌 수 있다.

1) 통합 : 협력 객체를 실제 객체를 사용해 단위 테스트를 작성

- 장점 : 협력 객체의 상세 구현을 알 필요가 없다.

- 단점 : 협력 객체의 동작에 영향을 받는다.

2) 고립 : 협력 객체를 Mock(가짜)로 사용해 단위 테스트를 작성

- 장점 : 외부 요인(협력 객체)로 부터 격리되어 테스트 대상의 검증에 집중할 수 있다.

- 단점 : 테스트가 협력 객체의 상세 구현을 알아야 함.

협력 객체의 로직이 변경되면 단위 테스트는 성공하지만 실제 시스템은 다르게 동작하게 된다.

4. Test Double

실제 객체 대신 사용되는 모든 종류의 객체에 대한 일반 용어

Stub

협력 객체의 호출에 대한 응답을 설정해 놓고 테스트 대상의 상태 검증에 사용한다.

Fake

실제 구현체를 만들어 특정 데이터에 다른 응답을 하도록 설정할 때 사용한다.

Mock

테스트 대상의 행위에 대한 검증에 사용한다.

Mock 객체가 만들어 지면 특정 메소드가 몇 번 호출 되었는지를 카운트해 검증 하는데 사용한다.

Stubbing : Stub 객체를 정의하는 행위

1) Mockito 활용

2) MockitoExtension 활용

3) Spring을 활용한 Stubbing

Spring 컨테이너를 띄우고 실제 객체를 Mock Bean으로 변경해 주입한다.

5. Classist TDD vs Mockist TDD

단위 테스트를 바라보는 두 관점 Classist와 Mockist.

1) Classist TDD

테스트와 테스트 간의 격리

테스트 간의 의존성이 아니라면 실제 객체를 사용한다.

도메인 설계가 충분히 이루어진 다음 진행 가능
TDD 사이클을 이어나가기가 상대적으로 어려움
프로덕션 코드에 덜 의존적인 테스트가 작성됨

TDD 진행 방식 : Inside-Out

의존성이 작은 레벨인 도메인 모델부터 시작

의존하는 협력 객체가 실제 존재해야 테스트를 작성할 수 있음

2) Mockist TDD

테스트 대상과 협력 객체의 격리

도메인에 대한 이해도가 높지 않은 상태에서 진행이 가능
상대적으로 프로덕션 코드에 의존적인 테스트가 작성됨 (깨지기 쉬운 테스트)

TDD 진행 방식 : Outside-In

(1) 의존성이 큰 상위 레벨(Controller)부터 시작

(2) 테스트 더블을 활용하여 테스트 대상이 의존하는 협력 객체(Service)의 예상 결과를 정의

(3) 다음 사이클로 테스트 더블로 미리 정의한 협력 객체를 테스트 대상으로 함

6. ATDD + TDD Cycle

1) 인수 테스트 작성을 통해 요구사항과 기능 전반에 대한 이해를 선행

2) 내부 구현에 대한 설계 흐름을 구상

3) 도메인에 대한 이해가 생길 때 까지 Outside-In TDD 를 진행한다.

4) 도메인에 대한 이해가 생기면 도메인부터 차근차근 Inside-Out TDD로 기능 구현

출처

[ATDD] 1. ATDD(Acceptance Test Driven Development)

mandykr — Fri, 21 Jan 2022 13:04:55 +0900

1. TDD(Test Driven Development) : 테스트 주도 개발

2. ATDD(Acceptance Test Driven Development) : 인수 테스트 주도 개발

3. 단위 테스트 vs 통합 테스트 vs 인수 테스트

4. ATDD 학습 방법

1. TDD(Test Driven Development) : 테스트 주도 개발

1) 실패하는 테스트 코드 작성

2) 테스트를 성공시키기 위한 최소한의 프로덕션 코드 작성

3) 프로덕션 코드 리팩토링

테스트 코드를 먼저 작성하고 프로덕션 코드를 작성하는 이유는

단위 테스트에서 테스트 코드가 기능 검증의 역할 보다

테스트 할 단위에 대한 요구사항을 명세하는 역할이 더 크기 때문이라고 할 수 있다.

2. ATDD(Acceptance Test Driven Development) : 인수 테스트 주도 개발

TDD와 ATDD는 요구사항을 명세하고 기능을 구현하는 개발 방식은 동일하다.

다만, 요구사항의 형태가 다른데 ATDD에서는 시나리오 형태의 요구사항을 작성한다.

인수 테스트(Acceptance Test)란

사용자의 관점에서 올바르게 작동하는지를 검증하는 방법이다.

때문에 인수 조건은 기술용어가 사용되지 않고 일반 사용자들이 이해할 수 있는 단어(도메인 언어)를 사용한다.

인수 조건을 시나리오 형태의 사용자 스토리로 만들어 테스트가 통과하는지를 검증한다.

인수 테스트 기반 구현 프로세스

1) 인수 조건(요구사항)을 시나리오 형식으로 만든다.

2) 인수 테스트 코드를 작성한다.

3) 프로덕션 코드를 작성한다.

인수 조건 예시

CRUD에 대한 각각의 인수 테스트를 하나로 통합하는 방식으로 리팩터링을 진행할 수도 있다.

인수 테스트 통합

ATDD의 목적

개발을 진행하기 이전에 고객, 개발자, 테스터가 충분한 논의를 통해 함께 요구사항을 적립하고

테스트 할 수 있는 명확한 요구조건을 만들도록 하여 서로의 의도와 다른 결과물이 나오는 것을 방지한다.

명확한 요구사항과 인수 테스트를 통한 빠른 피드백으로 공통의 이해를 도모해 프로젝트를 진행하도록 한다.

3. 인수 테스트의 가독성

인수 테스트는 사용자의 관점에서 인수 조건을 시나리오 형태로 만들어 검증하는 방식이기 때문에

구체적인 행위 보다는 목적이 뚜렷하게 드러나도록 하는 것이 좋다.

인수 테스트의 가독성을 높여주는 방법

메소드 분리, CRUD 추상화, BDD도구 사용 등으로 리팩토링

1) 의도 드러내기 : 한글 메소드 활용

2) 스텝 메소드(Given, When, Then)들을 static 선언하여 별도의 클래스로 분리(결국 Cucumber같은 BDD 도구가 필요해짐)

3) BeforEach를 활용해 중복 코드 제거

한글 메소드 예시

스텝 메소드 예시

4. 단위 테스트 vs 통합 테스트 vs 인수 테스트

인수 테스트의 개념은 테스트 의도에 따라 정해지는 것이지 테스트를 어떻게 구현하는지에 따라 정해지는 것이 아니다.

인수 테스트는 단위, 통합 테스트 등 어떤 레벨에서도 인수 테스트를 적용할 수 있다.

단위 테스트 : 구현한 부분, 단위를 검증
통합 테스트 : 각 단위들이 유기적으로 잘 동작하는지 검증
인수 테스트 : 요구사항을 만족하는지를 검증

5. 테스트 비용

인수 테스트는 반드시 확인해야할 인수 조건에 한해 검증하는 것에 집중한다.

나머지 데이터 검증, 예외 검증 등은 단위 테스트 등으로 확인할 수 있다.

6. ATDD 학습 방법

백엔드 개발자의 입장에서 ATDD를 단독으로 실천하기 위해서 인수 테스트의 의도를

고객을 프론트엔드 개발자 혹은 API를 활용하는 사람을 대상으로 한 E2E 테스트(API 접점에서 검증)로 정한다.

API의 Request와 Response 정보 이외 내부 정보는 최대한 가리는 블랙박스 형식의 테스트를 통해 ATDD를 경험해 볼 수 있다.

블랙박스 테스트란

내부 구현이나 기술에 의존적이지 않은 테스트로 내부 코드가 변경되더라도 테스트가 쉽게 깨지지 않도록 한다.

출처