호호홍얍얍

카프카 살펴보기(1부)

호호홍얍얍 — Fri, 24 Jan 2025 22:01:12 +0900

본 글에서는 메시지의 저장과 소비만을 다룬다.
- keyword: topic, partition, offset, partitioner, segment, clean-up policy

들어가며

이벤트는 키-밸류 구조로 되어있는, 무슨 일이 일어났는지에 대한 사건의 기록이다.

사건을 기록하고 꺼내어봄으로써 각 어플리케이션의 요구에 맞게 특정한 행동을 수행할 수 있다.

키는 기록에 대한 구분자로, 어떤 user 가 될 수도 있고, 번호가 될 수도 있다. 하나의 키에 여러 가지 사건이 발생될 수 있으므로 유니크할 필요도 없고 반드시 있어야만 하는 것도 아니다. 이 키에 대한 내용을 밸류로 갖고, 이벤트 메시지는 사실 키-밸류와 함께 타임스탬프, 메타정보인 헤더를 갖는다. 이벤트는 하나의 기록이므로 당연히 변경되지 않는다.

카프카는 실시간 데이터를 처리한다. 우리가 일기를 쓰듯이 하루에 한 번 지나간 사건에 대해 기록하는 것이 아니다. 상시 특정 대상에 대한 변화 지점을 계속해서 포착하는 것이다. 카프카는 이러한 실시간 이벤트를 수집하고, 그것들을 받아서 바로 처리할 수 있게끔, 또는 나중에 찾아볼 수 있게끔 잘 구성해서 저장한다. 각 이벤트들은 기록 자체로는 서로 상관 없는 개별적인 사건이 될 뻔했지만, 이를 잘 구성함으로써, 데이터의 지속적인 흐름과 해석을 보장해주고 있다. 실시간 정보를 주고 받는 상시 접속 시대에, 자동화된 메시징 처리를 가능하게 하는 이벤트 스트리밍이 카프카의 기본 컨셉이다.

그럼 어떻게 잘 구성해서 저장하길래 다양한 애플리케이션이 필요에 따라 효과적으로 데이터를 찾고 처리할 수 있게 하는가?

데이터의 저장

메시지 저장 순서 보장

이벤트는 토픽에 저장된다. 토픽은 말 그대로 특정 주제인데, 그 주제에 해당하는 메시지들을 저장한다. 카프카는 메시지를 저장, 관리, 분산 처리를 하는 카프카 서버(브로커)와 이 메시지를 발행하고 수신하는 클라이언트인 프로듀서, 컨수머로 구성된다. 프로듀서가 발행한 메시지는 브로커에 쌓인다.

실제로 데이터가 저장되는 곳은 파티션이다.

https://curiousjinan.tistory.com/entry/understand-kafka-partitions

하나의 토픽은 여러 개의 파티션을 가질 수 있다. 각 파티션에는 특정 컨수머가 동적으로 할당되는데, 파티션이라는 개념이 없었다면, 여러 개의 메시지 발행자, 소비자가 메시지 읽기/쓰기를 하기 위해 계속 줄서있어야 했을 것이다. 파티션은 특정 주제 내에서의 분산을 가능하게 한다.

그렇다면 메시지 순서는 어떻게 보장되지? 이걸 이해하기 위해 필요한 개념은 오프셋이다. 오프셋은 파티션에 저장되는 메시지의 위치이다.

오프셋은 파티션 내에서 고유하다. 즉, 파티션이 달라지면 오프셋은 달라진다. 각 메시지는 토픽과 파티션, 오프셋을 가짐으로써 저장 순서가 보장된다.

https://www.geeksforgeeks.org/topics-partitions-and-offsets-in-apache-kafka/

다시 말하면, 파티션 밖에서의 오프셋은 의미가 없다. 위 그림에서 7번 메시지는 파티션 0, 1, 2 에서 모두 다른 메시지이다. 메시지를 저장된 순서에 따라 처리하려면, 같은 파티션으로 배치해야 한다.

파티셔닝

카프카는 이를 위해 파티셔닝이라는 개념을 가지고 있다. 어떤 파티션에 배치할 것인가를 결정하는 전략인데, 총 세 가지의 방식이 있다.

첫 번째로, 키 기반 파티셔닝은 메시지가 키를 가지고 있을 때, 같은 키는 같은 파티션에 할당하는 전략이다.

두 번째로, 스티키 파티셔닝은 배치 사이즈 또는 시간으로 결정된다. 배치 설정에 따라 크기가 꽉 차면 / 시간이 되면 그 묶음은 한 파티션에 할당한다. 만약 배치가 차지 않았다면, 이전 레코드와 동일한 파티션에 발행되고, 새로 생성된 배치는 무작위로 할당된다.

세 번째는 라운드 로빈 방식이다. 카프카 2.4 이전까지는 키가 없을 때의 기본 전략이었다.

위 동작을 수행하는 것이 파티셔너이다.

파티셔너는 프로듀서의 영역이다. 메시지가 발행될 때 어떤 파티션에 배치될지가 결정된다. 필요하다면 개별 어플리케이션에서 Partitioner 를 구현하여 커스텀 파티셔너를 만들어도 된다.

키 기반 파티셔닝을 데이터 스트림 관점에서 보자면, 파티션은 주제별로 묶인 이벤트를 또 한 번 묶은 최후의 데이터 단위인 셈이다.

https://www.youtube.com/watch?v=kj9JH3ZdsBQ&t=22s

파티션의 구성

앞서 언급했듯, 예상되는 부하에 따라 토픽 별로 파티션 개수를 정할 수 있다.

몇 개가 적절할까? 우선 파티션은 늘리는 건 가능해도, 줄일 수는 없다. 그렇다면 최초에 넉넉하게 만들되, 지나치게 많지 않게 해야 한다. 또, 키 기반 파티셔닝을 사용할 때, 파티션의 개수를 늘리면 파티셔닝 계산이 깨진다. 순서 보장이 안 될 수 있다. 때문에 늘리는 것도 신중하게 해야 한다.

어차피 파티션 수가 더 적으면 특정 컨수머는 유휴 상태에 들어간다. 반대로 지나치게 많으면 하나의 컨수머가 처리해야 하는 파티션 수가 너무 늘어나게 된다. 쓰기 속도, 파티션 키 분산도 신경 써야 한다.

결국 잘, 해야 한다는 건데, https://docs.cloudera.com/runtime/7.2.18/kafka-performance-tuning/topics/kafka-tune-sizing-partition-number.html 에 따르면 파티션 수 = max(목표 처리량 / 프로듀서 처리량, 목표 처리량 / 컨슈머 처리량) 이런 공식을 제공하고 있긴 하다.

메시지의 삭제

메시지는 최대 저장 한도가 있다. 기본적으로 7일, 무제한이 최대 한도이다. 하지만 서버에 메시지가 쌓이기만 한다면 문제가 생길 것이다.

어떤 메시지를 어떻게 삭제할 것인가? 카프카의 메시지의 삭제 정책은 두 가지가 있다.

cleanup.policy=delete(default): 정해진 용량이나 시간을 초과하면 삭제
- retention.ms / log.retention.ms
- retention.bytes / log.retention.bytes
cleanup.policy=compact: key 기준 최신 메시지만 남기고 삭제

https://kafka.apache.org/documentation

cleanup.policy=delete,compact: delete 와 compact 를 조합

다만 메시지 삭제는 개별 메시지 단위가 아닌 ‘세그먼트’ 단위로 이루어진다. 따라서 실제 메시지 보존 기간은 설정값보다 길어질 수 있음에 유의해야 한다.

자세한 얘기를 하기 전에, 세그먼트가 뭔지부터 보자.

세그먼트

세그먼트는 메시지가 저장되는 묶음이다. 아까 메시지는 파티션에 저장되고, 파티션 내에서만 순서가 유지된다고 했는데, 이건 또 무슨 소리일까?

메시지가 파티션에 저장된다고 하면, 파티션에 차곡차곡 순서대로 쌓을 것 같지만, 사실은 세그먼트 단위로 만들어진 파일을 차곡차곡 쌓게 된다. 아래의 그림과 같이, 설정된 크기 또는 시간(segment.ms / segment.bytes)에 따라 세그먼트가 생성된다.

https://rohithsankepally.github.io/Kafka-Storage-Internals/

토픽 내 파티션에 메시지를 발행한다면, 실제 세그먼트는 아래와 같이 생긴다.

메시지는 .log 라는 하나의 파일에 쌓인다. (*.index, *.timeindex 파일도 생긴다)

파일명은 시작 offset 을 의미한다.

00000000000000000000.* - Capture storage of messages with 0 <= offset <35.
00000000000000000035.* - Capture storage of messages with offset >=35

자세한 내용은 https://rohithsankepally.github.io/Kafka-Storage-Internals/ 이 글을 보라.

삭제의 대상

log 파일을 통해 우리는 delete 를 하든, compact 를 하든 삭제가 세그먼트 단위로 이뤄지는 이유에 대해 알 수 있다.

데이터는 로그의 헤드 부분에 쌓인다. 자연히 오래된 메시지는 테일 부분에 오래된 순으로 쌓여 있다.

세그먼트는 크기 또는 시간에 따라 구분된다고 했다. 이미 크기 또는 시간이 꽉 찬 테일 부분은, 여러 개의 세그먼트로 나뉘어져 있을 것이다. 반면 헤드의 세그먼트에는 계속해서 새로운 데이터가 쌓이게 된다.

https://docs.confluent.io/kafka/design/log_compaction.html

아래의 그림이 있을 때, 삭제 후보는 활성화된 세그먼트를 제외하고, 아래의 1, 2, N-1 이다.

https://docs.cloudera.com/runtime/7.2.10/kafka-overview/topics/kafka-overview-logs-and-log-segments.html

실제 삭제 대상은 delete 이냐, compact 이냐에 따라 다르다.

delete 정책은

보존 기간이나 크기를 초과한 닫힌 세그먼트를 대상으로 한다.
오래된 세그먼트부터 순차적으로 삭제한다.
설정된 보존 기준을 초과하지 않는 세그먼트는 그대로 유지된다.
위의 그림에서, Segment N 이 활성화된 세그먼트이고, 보존 기준을 초과한 세그먼트가 Segement 1 뿐이라면, 2, N-1, N 은 그대로 유지된다.

세그먼트가 생기는 시간 / 사이즈가 있고, 보존 기간 / 사이즈가 있기 때문에 어떤 메시지가 삭제되느냐는 예상과는 조금 다를 수 있다.

아래의 그림을 보면, 세그먼트 사이즈가 보존 기간보다 크고, 체크 스레드가 보존 기간을 초과한 세그먼트를 삭제하고 있다.

https://www.redpanda.com/guides/kafka-performance-kafka-logs

compact 정책은

닫힌 세그먼트를 대상으로 한다.
각 키에 대해 가장 최신 값만을 유지하고, 이전 버전의 데이터는 제거한다.
압축 과정에서 새로운 세그먼트가 생성되며, 이 세그먼트에는 각 키의 최신 값만 포함된다.

compact 방식일 때의 대상은 보존 기간의 초과가 아니라, 아래 세 가지 설정에 의해 결정된다.

log.cleaner.delete.retention.ms controls how long the records are retained after they are confirmed for deletion.
log.cleaner.min.compaction.lag.ms defines the minimum age of the records that are subject to compaction.
log.cleaner.max.compaction.lg.ms defines the maximum age of records that can remain in the system without compaction.

https://developer.confluent.io/courses/architecture/compaction/

만약 compact 방식인데 키가 null 이면 어떻게 될까? 키가 null 인 레코드는 전송되지 않는다(https://blog.voidmainvoid.net/505 ).

더 자세하게 알고 싶으면 https://developer.confluent.io/courses/architecture/compaction/ 여기에 아주 잘 설명돼 있다.

1부를 마치며

카프카는 로그 기반 구조를 취함으로써, 한 번 쓰여진 데이터는 변경이 불가능하게 한다. 또한 테일 영역의 데이터만 삭제함으로써 삭제를 용이하게 하며, 끝에만 저장하니까 속도도 빠르다(https://docs.confluent.io/kafka/design/file-system-constant-time.html ).

카프카는 이러한 방식으로 데이터를 저장함으로써, 이벤트 스트리밍이라는 컨셉을 구현했다. 또, 이 글에서 다루지는 않았지만, 파티션의 복제를 통해 분산 처리를 지원하는데, 로그 기반의 순차적인 시스템이 이것을 가능하게 한다.

여기까지, 실시간으로 변화하는 현재의 사건들을 여러 클라이언트가 대응할 수 있도록 한 카프카의 컨셉이 어떻게 실현되었는지 살펴봤다.

메시지 소비

to be continued

[누구나 자료구조와 알고리즘] 3장. 빅오표기법

호호홍얍얍 — Mon, 17 Oct 2022 19:55:02 +0900

빅오표기법: 시간 복잡도를 효율적으로 나타내기 위한 표기법

탄생배경
어떤 알고리즘을 "22단계의 알고리즘"과 같은 식으로 표기하는 방식은 원소수가 달라질 때마다 몇 단계가 필요한지 달라지기 때문에 부적절하다.
또한 "N개의 원소가 있을 때 선형 검색에 N단계가 필요하다"와 같은 표기는 너무 길다.

O(N): 데이터 원소가 N개일 때 알고리즘에 몇 단계가 필요한지 표기

빅오표기법은 최악의 경우를 상정해 표기한다.
위의 표기는 선형검색에서 최악의 경우를 고려하여 표현한 것이다.
빅오표기법은 "데이터 원소가 N개일 때 알고리즘에 몇 단계가 필요할까?"에 대한 답을 표현한 것이다.
그에 대한 답은 "알고리즘에 N단계가 필요하다"는 것이다.

O(1): 가장 빠른 알고리즘 유형 = 상수 시간을 갖는 알고리즘

읽기는 배열에 원소가 몇 개든, 항상 1단계만 소요된다.
데이터가 늘어나도 알고리즘의 단계수는 증가하지 않는다.

빅오로 구분하는 알고리즘 유형

빅오의 본질은 데이터가 늘어날 때 알고리즘의 성능이 어떻게 바뀌는지를 의미한다.
1) O(1)이든, O(3)이든 데이터 증가에 영향을 받지 않는 유형이므로, 둘을 구분할 필요가 없다. 즉, O(3)이라 표기하지 않고 O(1)로 표기한다.
2) O(N)은 데이터 증가가 성능에 영향을 미치므로, O(1)과는 다른 유형이다.
이러한 내용은 아래 그래프로 확인할 수 있다.

O(N)과 항상 100단계가 걸리는 알고리즘의 효율성 비교

아래 그래프를 보면, 특정 원소수를 기준으로, 100 미만은 O(N)이, 100 초과는 100단계 알고리즘이 더 낫다고 볼 수 있다.

이진검색의 빅오표기: O(logN) - 데이터가 두 배로 증가할 때마다 한 단계씩 늘어나는 알고리즘

'로그 시간의 시간 복잡도'의 유형
O(logN)
- O(log2(N))에서 2를 생략한 것
- 데이터 원소가 N개 있을 때 알고리즘에 log2(N) 단계가 걸린다는 의미이다.
- 즉, O(logN)은 원소가 하나가 될 때까지 데이터 원소를 계속해서 반으로 줄이는 만큼의 단계 수가 걸린다.
알고리즘의 효율성 비교: O(1) > O(logN) > O(N)

- 로가리즘(로그)

로가리즘은 지수와 역의 관계다.
log2(8) = 3
- 2의 3제곱의 역으로, 2를 3번 곱해야 8을 얻을 수 있다.
- 1이 나올 때까지 8을 2로 몇 번 나눠야 하는지 계산하면 구할 수 있다.

O(logN) VS O(N)

1) O(logN): 데이터 원소가 두 배로 늘어날 때마다 딱 한 단계만 더 필요하다.

2) O(N): 데이터 원소 수만큼의 단계가 필요

연습문제 - 각 함수의 시간복잡도 구하기

function isLeapYear(year) {
	return (year % 100 === 0) ? (year % 400 === 0) : (year % 4 === 0);
}

O(1)

- 어떤 수가 들어오든 항상 한 단계만 수행하므로(데이터가 늘어남에 따라 영향을 받지 않으므로) 상수 시간의 알고리즘이다.

function arraySum(array) {
	let sum = 0;
    
    for(let i = 0; i < array.length; i++) {
    	sum += array[i];
    }
    
    return sum;
}

O(N)

- 배열의 길이에 따라 단계가 달라지므로 O(N)이다.

function chessboardSpace(numberOfGrains) {
	let chessboardSpaces = 1;
    let placedGrains = 1;
    
    while (placedGrains < numberOfGrains) {
    	placedGrains *= 2;
        chessboardSpaces += 1;
    }
    
    return chessboardSpaces;
}

O(logN)

- N이 두 배 늘어날 때마다 루프를 한 번 더 실행하므로 O(logN)이다.

function selectAStrings(array) {
	let newArray = [];
    
    for(let i=0; i < array.length; i++) {
    	if (array[i].startsWith("a")) {
        	newArray.push(array[i]);
        }
    }
    
    return newArray;
}

O(N)

- 어떤 배열이 오든, 배열의 모든 자리수를 검사해야 하므로 O(N)이다.

5. '정렬된' 배열의 중앙값 구하기 함수

function median(array) {
	const middle = Math.floor(array.length / 2);
    
    if (array.length % 2 === 0) {
    	return (array[middle - 1] + array[middle]) / 2;
    } else {
    	return array[middle];
    }
}

O(1)

- 한 번만 수행한다.

[오늘 한 것 & 배운 것]

호호홍얍얍 — Sat, 3 Sep 2022 20:30:43 +0900

오늘 한 것

1. 면접준비

2. 모의면접

3. 코딩테스트

배운 것

1. stream 내에서 if 문 사용하는 방법: 중괄호 활용

List<String> nameList = Arrays.stream(split)
                .map(name -> {
                    String[] nameArr = name.split(" ");
                    if (nameArr.length > 2) {
                        return nameArr[0].substring(0, 1) + nameArr[1].substring(0, 1);
                    } else {
                        return nameArr[0].substring(0, 1);
                    }
                })
                .collect(Collectors.toList());

2. 필터와 인터셉터

- 오늘 모의면접 중, 필터와 인터셉터의 차이에 대해 질문했는데 이 질문에 대답을 못했다. 간단히 아래와 같이 정리한다.

- 필터: 스프링에 들어오기 전(디스패처 서블릿 앞단)에 동작

- 인터셉터: 디스패처 서블릿 호출 후 컨트롤러 호출 전/후로 동작

- AOP: 메소드의 실행 전/후로 동작

[오늘 한 것 & 배운 것]

호호홍얍얍 — Thu, 1 Sep 2022 18:27:26 +0900

오늘 한 것

1. 코딩테스트 연습

배운 것

1. Array, List

2. 프로세스, 스레드

3. Wrapper 클래스

- 컬렉션 프레임웤

데이터 집단을 저장하는 클래스들을 표준화한 설계
컬렉션 인터페이스: Collection(List, Set), Map
컬렉션 클래스: ArrayList, HashMap, ...

- List

순서가 있는 데이터의 집합
데이터의 중복을 허용한다

-- ArrayList

배열의 저장공간을 처음부터 지정해야 한다
더 큰 공간이 필요하면 새로운 더 큰 배열을 생성해서 기존 배열의 내용을 복사하여 새로운 배열에 저장한다
메모리 상에 연달아 공간을 확보한다
첫 번째 위치만 알면, index로 상대적 위치를 빠르게 찾을 수 있다
Vector는 스레드 세이프하기 때문에 멀티 스레드 환경이 필요하면 Vector를 사용한다 - 하지만 예전과의 호환을 위해서만 남아 있는 것이기 때문에 안 쓰는 게 좋음
중간 데이터를 추가/삭제할 때는 데이터를 복사 후에 집어 넣는 방식이므로 효율이 좋지 않다

-- LinkedList

한 노드가 다음 노드의 주소를 저장하여, 불연속적으로 존재하는 데이터를 서로 연결한 형태
자바에서는 이전 노드도 저장하는 더블 링크드 리스트로 구현되어 있다
중간 데이터를 추가/삭제할 때는 참조를 변경하기만 하면 되서 처리속도가 매우 빠르다

--- 순차적으로 추가/삭제하는 경우에는 ArrayList가 LinkedList보다 빠르지만, 중간데이터를 추가/삭제하는 경우에는 LinkedList가 더 빠르다

-- Stack

마지막에 저장한 데이터를 가장 먼저 꺼내는 LIFO 구조
순차적으로 데이터를 추가하고 삭제하기 때문에 ArrayList와 같은 배열 기반의 컬렉션 클래스가 적합하다
자바에서는 클래스로 구현되어 있다

-- Queue

처음에 저장한 데이터를 가장 먼저 꺼내는 FIFO 구조
데이터의 추가/삭제가 쉬운(데이터의 복사가 발생하지 않는) LinkedList로 구현하는 것이 적합하다 - 자바에는 LinkedList가 구현되어 있다

--- PriorityQueue

Queue의 구현체, 저장한 순서에 관계없이 우선순위가 높은 것부터 꺼낸다

- Set

순서를 유지하지 않는 데이터의 집합
데이터의 중복을 허용하지 않는다

- Map

키와 값의 쌍으로 이루어진 데이터의 집합
순서는 유지되지 않는다
키는 중복을 허용하지 않고 값은 중복을 허용한다

2. 프로세스와 스레드

3. Wrapper 클래스

https://bibapditura.tistory.com/79

Wrapper 클래스

호호홍얍얍 — Thu, 1 Sep 2022 09:50:20 +0900

Wrapper 클래스란?

기본형을 객체로 포장하는 것
기본형: char, boolean, int, byte, short, double, float, long
참조타입으로 변환되므로, 주소를 저장하게 된다(equals 사용)

언제 사용되는가?

메소드의 파라미터로 객체 타입만이 요구되는 경우
클래스의 장점 - 클래스에 포함된 메소드를 활용하는 경우
제네릭의 사용

박싱 & 언박싱

박싱: 기본형을 Wrapper 클래스로 변환할 때 사용
- Integer num = new Integer(1);
언박싱: Wrapper 클래스를 기본형으로 변환할 때 사용
- int n = num.intValue();

오토박싱 & 오토언박싱

위처럼 직접 쓰지 않고 바로 대입해도 박싱/언박싱이 이뤄진다
오토박싱: Integer num = 1;
오토언박싱: int n = num;

SQL문 - Join, Case when, Datetime

호호홍얍얍 — Wed, 31 Aug 2022 17:10:59 +0900

Join

- inner join: 교집합

예시: A, B 테이블에 모두 존재하는 데이터 중, A 테이블 기준 기간이 긴 데이터 찾기

SELECT *
from animal_ins A 
left join animal_outs B on A.animal_id=B.animal_id
where A.datetime > B.datetime
order by A.datetime

- outer join: 합집합

예시: A, B 테이블 중 B 테이블에만 존재하는 데이터 찾기

SELECT B.animal_id, B.name
from animal_ins A right outer join animal_outs B on A.animal_id=B.animal_id
where A.animal_id is null

If / case when

- If: 특정 조건에 따라 분기

예시: A인 경우에는 X, 아닌 경우에는 O로 표기하기

SELECT ANIMAL_ID, NAME, IF(SEX_UPON_INTAKE LIKE 'Intact%', 'X', 'O') AS '중성화'
FROM ANIMAL_INS
ORDER BY ANIMAL_ID;

- Case When End: 특정 조건에 따라 분기

예시: A인 경우에는 X, 아닌 경우에는 O로 표기하기

SELECT animal_id, name,
case when sex_upon_intake like 'intact%' then 'X'
else 'O'
end as '중성화'
from animal_ins

Datetime

- datediff: 두 날짜의 기간 일수로 비교하기

SELECT B.animal_id, B.name
from animal_outs B
join animal_ins A
on A.animal_id=B.animal_id
where B.animal_id is not null
order by datediff(A.datetime, B.datetime)
limit 2

- 날짜 포맷

SELECT animal_id, name, date_format(datetime, '%Y-%m-%d') as '날짜'
from animal_ins 
order by animal_id

[오늘 한 것 & 배운 것]

호호홍얍얍 — Fri, 26 Aug 2022 23:12:16 +0900

오늘 한 것

티끌 ver.2 - 네이버 쇼핑 API 붙이기
모의 면접
- 레디스를 사용한 이유는?
- 레디스 말고 다른 것도 있는데 레디스를 사용한 이유는 무엇인가?
- pub/sub란 무엇인가?
- OAuth2가 작동하는 프로세스에 대해 설명해보라
- 구글 토큰을 별도로 저장하지 않았는지? - 별도 저장을 통해 자동 로그인을 구현할 수 있다
- @Autowired 어노테이션에 대해 설명해보라
- 스프링의 기본 동작 프로세스에 대해 설명해보라
- 싱글톤은 어떻게 유지되는지? - 인스턴스를 static으로 만들어서 유지

배운 것

예를 들어 UserService에서 BoardRepository를 참조해야 할 일이 생긴다. 이것은 옳은 방식일까?
- 두 가지로 나눌 수 있을 것 같다
- 한 번만 호출하는 경우: Repository를 바로 호출하는 편이 효율적임
- 여러 군데서 활용하는 경우
  - 서비스별로 파라미터를 걸어서 호출
  - 팩토리 패턴: 임플과 서비스를 나누어라

[스프링 핵심 기본 원리] SOLID 원칙

호호홍얍얍 — Wed, 10 Aug 2022 11:28:02 +0900

1. SRP 단일책임원칙 Single Responsibility Principle

* 한 클래스는 하나의 책임만 가져야 한다.

-> 변경이 있을 때 파급효과가 적어야 한다.

2. OCP 개방-폐쇄원칙 Open/Closed Principle

* 확장에는 열려 있으나, 변경에는 닫혀 있어야 한다.

* 다형성을 활용하여, 인터페이스를 구현한 새로운 클래스를 만들어서 새로운 기능을 구현했다고 해보자.

이때, 서비스 단에서는 아래와 같은 코드를 작성하게 된다.

MemberRepository mp = new MemoryMemberRepository();

그런데, mp를 new JdbcMemberRepository();로 바꾸어야 한다면?

DIP를 위반하게 되고, 변경에 열려 있는 것이 되어 버린다.

-> 이것을 해결하려면 빈 컨테이너를 활용하여 DI를 하는 것이 필요하다.

3. LSP 리스코프 치환원칙 Liskov Substitution Principle

* 프로그램의 객체는 프로그램의 정확성을 깨트리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

- 자동차 인터페이스의 엑셀: 앞으로 간다는 규약 -> 뒤로 간다는 기능을 만들어서는 안 됨

4. ISP 인터페이스 분리 원칙 Interface Segregation Principle

* 특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다

- 자동차 인터페이스를 정비사/운전으로 쪼개라

5. DIP 의존관계 역전 원칙 Dependency Inversion Principle

* 프로그래머는 '추상화에 의존해야지, 구체화에 의존하면 안 된다'

- 의존성 주입은 이 원칙을 따르는 것이다.

- 역할에 대해서만 알아야 하는 것. 구현에 의존하면 안 된다.

=====

* 다형성만으로는 OCP, DIP를 지킬 수 없다 -> 스프링 프레임워크를 사용한다!

* 객체지향: 객체들의 모임. 객체는 메시지를 주고 받고 데이터를 처리한다.

* 다형성: 역할과 구현으로 구분할 수 있다.

20220713

호호홍얍얍 — Wed, 13 Jul 2022 21:38:39 +0900

통계 스케쥴러 구현

- 내가 아낀 이력 월별 통계 구현

Scheduler 선정 이유

일정 시간에 정해진 일을 수행하는 데는 batch, quartz, scheduler가 있다.

- batch: 여러 job을 순차적으로 처리. 보다 규모가 큰 경우 사용

- quartz, scheduler: 특정 job을 특정 시간에 처리. 단, quartz는 클러스트링 등 세부적인 조작이 가능하지만 구현이 복잡하다.

단순히 통계만을 위한 작업이므로, scheduler를 사용하기로 했다.

* scheduler는 스프링부트 스타터에 기본적으로 포함되어 있어 새로 주입할 필요가 없다.

고려해야할 것

* 서버 시간과 로컬 시간이 다를 수 있음

* cron 표현 방식

* 사람이 없는 시간대에 작동시켜야 함(ex. 새벽 5시)

* queryDSL 사용

* 프론트에서 요청하는 api, 정해진 시간에 맞춰 저장시킬 api 두 개가 필요하다.

고민

* 통계테이블에 userid를 연관관계를 맺어야 한다?

- yes: user별 데이터를 객체로 다루기 쉽다.

- no: 양방향 매핑을 한다면, 불필요한 데이터까지 꺼내와야 한다. 단방향 매핑을 한다면 되지만, 역시 userid 외 불필요한 데이터를 가져오게 된다. 번거롭더라도 where 절을 통해 구현하는 게 맞을 거라는 생각

* db에서 갖고 와서 sum/count를 계산할 것인가? 아니면 아예 갖고 와서 계산할 것인가?

queryDSL

문자가 아닌 코드로 쿼리를 작성함으로써, 컴파일 시점에 문법 오류를 쉽게 확인할 수 있다.
자동 완성 등 IDE의 도움을 받을 수 있다.
동적인 쿼리 작성이 편리하다.
쿼리 작성 시 제약 조건 등을 메서드 추출을 통해 재사용할 수 있다.

속성 종류

cron : cron표현식을 지원한다. "초 분 시 일 월 요일 (년)"으로 표현한다. cron표현식에 쓸 수 있는 것들(특수문자 활용 포함)이 많은데 해당 내용이 핵심이 아니므로 다른 블로그에서 확인해보기를 바란다.
fixedDelay : milliseconds 단위로, 이전 작업이 끝난 시점으로 부터 고정된 시간을 설정한다. ex) fixedDelay = 5000
fixedDelayString : fixedDelay와 같은데 property의 value만 문자열로 넣는 것이다. ex) fixedDelay = "5000"
fixedRate : milliseconds 단위로, 이전 작업이 수행되기 시작한 시점으로 부터 고정된 시간을 설정한다. ex) fixedRate = 3000
fixedRateString : fixedDelay와 같은데 property의 value만 문자열로 넣는 것이다. ex) fixedRate = "3000"
initialDelay : 스케줄러에서 메서드가 등록되자마자 수행하는 것이 아닌 초기 지연시간을 설정하는 것이다.
initialDelayString : 위와 마찬가지로 문자열로 값을 표현하겠다는 의미다.
zone : cron표현식을 사용했을 때 사용할 time zone으로 따로 설정하지 않으면 기본적으로 서버의 time zone이다.

목표

호호홍얍얍 — Thu, 23 Jun 2022 23:12:43 +0900

이번 주차 목표

- 메서드 분리하기

- 깃 협업툴로 활용하기

- 기획 똑띠 하기!

- 컨플루언스로 정책 정의 & 지라로 이슈 관리

- 예외처리

지난 주차에 한 것

- MySQL 연결(select / update / insert / delete / drop 등 기본 sql문 작성)

- 데이터베이스 설계

- 영속성 약간 건드림...

- 람다식 써봄

- jwt 약간 이해