파이의 꿈

TimescaleDB는 무엇인가?

PI.314 — Fri, 29 Dec 2023 23:14:31 +0900

이 글에서는 PostgreSQL 기반의 오픈 소스 시계열 데이터베이스인 TimescaleDB와 그 핵심 기능인 하이퍼테이블에 대해 알아보겠습니다.

TimescaleDB

TimescaleDB는 관계형 데이터베이스의 강력한 기능과 시계열 데이터를 효율적으로 처리하는 능력을 결합한 데이터베이스입니다. PostgreSQL의 확장으로, 기존 SQL 지식을 활용하여 시계열 데이터를 쉽게 처리할 수 있습니다. 높은 쓰기 성능, 효율적인 데이터 압축, 강력한 쿼리 기능이 특징입니다.

하이퍼테이블

하이퍼테이블은 TimescaleDB의 핵심 개념으로, 일반적인 PostgreSQL 테이블처럼 보이지만 내부적으로 여러 개의 데이터 파티션(청크라고 함)으로 나뉩니다. 이 구조는 시계열 데이터의 대량 삽입과 복잡한 쿼리를 효율적으로 처리할 수 있도록 해줍니다.

하이퍼테이블 생성 및 관리

하이퍼테이블은 대규모 시계열 데이터를 효율적으로 관리하기 위해 파티셔닝과 인덱싱을 사용합니다. 이 글에서는 하이퍼테이블의 파티셔닝 방법, 설정 및 관련 쿼리에 대해 설명하겠습니다.

하이퍼테이블 파티셔닝의 이해

하이퍼테이블은 시계열 데이터를 '청크(chunk)'라는 파티션으로 분할하여 관리합니다. 이 청크는 시간 또는 다른 치수(예: 장치 ID)에 따라 생성될 수 있으며, 데이터의 삽입과 쿼리 성능을 향상시킵니다.

청크는 자동으로 생성되며, 특정 시간 범위 또는 다른 치수에 따라 데이터를 포함합니다.
청크의 크기와 수명 주기는 사용자가 설정할 수 있으며, 이는 데이터의 볼륨과 쿼리 패턴에 따라 다릅니다

TimescaleDB에서 하이퍼테이블 설정과 관련된 다양한 쿼리들과 그들의 용도에 대해 설명해드리겠습니다.

1. 하이퍼테이블 생성

하이퍼테이블을 생성하는 기본 쿼리입니다. 일반 PostgreSQL 테이블을 생성한 후, 이를 하이퍼테이블로 변환합니다.

CREATE TABLE temperature_data (
    time TIMESTAMPTZ NOT NULL,
    sensor_id INT,
    temperature DOUBLE PRECISION
);

SELECT create_hypertable('temperature_data', 'time');

2. 청크 시간 간격 설정

하이퍼테이블의 청크 크기를 시간 간격으로 설정합니다. 예를 들어, 아래 쿼리는 각 청크가 1주일의 데이터를 보유하도록 설정합니다.

SELECT set_chunk_time_interval('temperature_data', INTERVAL '1 week');

3. 청크 사이즈 제한 설정

청크의 최대 크기를 설정할 수 있습니다. 이는 디스크 공간을 관리하고 쿼리 성능을 최적화하는 데 유용합니다.

SELECT set_chunk_size_constraint('temperature_data', 524288000); -- 예: 500MB

4. 데이터 보존 정책 설정

데이터 보존 정책을 설정하여 오래된 데이터를 자동으로 삭제할 수 있습니다. 예를 들어, 아래 쿼리는 12개월 이상 된 데이터를 삭제합니다.

SELECT add_retention_policy('temperature_data', INTERVAL '12 months');

5. 데이터 압축 정책 설정

데이터 압축 정책을 설정하여 공간을 절약하고 쿼리 성능을 향상시킬 수 있습니다. 아래 쿼리는 7일보다 오래된 데이터를 압축합니다.

SELECT add_compression_policy('temperature_data', INTERVAL '7 days');

6. 연속 집계(Continuous Aggregation) 생성

연속 집계를 설정하여 자주 실행되는 집계 쿼리의 성능을 향상시킬 수 있습니다. 아래는 시간별 평균 온도를 계산하는 연속 집계의 예시입니다.

CREATE VIEW hourly_temperature_stats
WITH (timescaledb.continuous)
AS
SELECT time_bucket('1 hour', time) as bucket,
       sensor_id,
       AVG(temperature) as avg_temp
FROM temperature_data
GROUP BY bucket, sensor_id;

7. 청크 조회

현재 생성된 청크를 조회하는 쿼리입니다. 데이터 관리 및 트러블슈팅에 유용합니다.

SELECT show_chunks('temperature_data');

이러한 쿼리들은 하이퍼테이블의 성능 최적화, 공간 관리, 데이터 보존 등 다양한 측면에서 중요한 역할을 합니다. 하이퍼테이블 설정을 적절히 관리함으로써, 대규모 시계열 데이터를 효과적으로 처리하고 분석할 수 있습니다.

TimescaleDB vs InfluxDB 비교하기

PI.314 — Fri, 29 Dec 2023 22:46:32 +0900

시계열 데이터베이스는 시간에 따라 변하는 데이터를 저장하기 위해 설계되었습니다. 이것은 시간이 지남에 따라 수집된 모든 종류의 데이터일 수 있습니다. 예를 들어, 어떤 시스템에서 수집한 메트릭들이 이에 해당합니다.

우리는 다양한 종류의 시계열 데이터베이스를 가지고 있는데, 어떤 것을 사용해야 할까요? 이 글에서는 TimescaleDB와 InfluxDB, 두 주요 옵션 사이의 주요 차이점을 살펴볼 것입니다.

InfluxDB

InfluxDB는 InfluxData에 의해 만들어졌습니다. 이것은 Go 언어로 작성된 맞춤형, 오픈 소스, NoSQL 시계열 데이터베이스입니다.

이 데이터 저장소는 InfluxQL이라고 하는 SQL과 유사한 언어를 제공하여 개발자들이 자신들의 애플리케이션에 쉽게 통합할 수 있습니다. 또한 Flux라는 새로운 맞춤형 쿼리 언어도 있습니다. 이 언어는 일부 작업을 더 쉽게 만들 수 있지만, 맞춤형 쿼리 언어를 채택할 때 항상 학습 곡선이 있습니다.

Flux Query Example

from(db:"testing")
|> range(start:-1h)
|> filter(fn: (r) => r._measurement == "cpu")
|> exponentialMovingAverage()

이 데이터베이스에서는 각 측정값이 타임스탬프와 연관된 태그 세트와 필드 세트를 가집니다. 필드는 실제 측정 읽기 값들을 나타내며, 태그는 측정값들을 설명하는 메타데이터를 나타냅니다.
필드 데이터 유형은 float, int, string, boolean으로 제한되며, 데이터를 다시 쓰지 않고는 변경할 수 없습니다. 태그 값은 인덱싱됩니다. 이들은 문자열로 표현되며 업데이트할 수 없습니다.
InfluxDB는 스키마나 인덱스를 만드는 것에 대해 걱정할 필요 없이 시작하기 쉽습니다. 그러나, 추가 인덱스를 만들거나, 연속 필드에 인덱스를 만들거나, 사후에 메타데이터를 업데이트하거나, 데이터 유효성을 강제하는 등의 능력이 없어 꽤 제한적이고 경직되어 있습니다.
InfluxDB는 스키마가 없는 것이 아닙니다. 입력 데이터로부터 자동으로 생성되는 기본 스키마가 있습니다.
InfluxDB는 장애 허용, 고가용성, 백업/복원과 같은 여러 도구를 처음부터 구현해야 했으며, 디스크 신뢰성에 대해 책임을 져야 합니다. 이러한 도구들과 많은 기능들, 예를 들어 HA는 엔터프라이즈 버전에서만 사용할 수 있습니다.
InfluxDB 백업 도구는 전체 또는 증분 백업을 수행할 수 있으며, 특정 시점 복구에 사용할 수 있습니다.
InfluxDB는 PostgreSQL 및 TimescaleDB보다 디스크 압축이 뛰어납니다.

TimescaleDB

TimescaleDB는 빠른 삽입과 복잡한 쿼리에 최적화된 오픈 소스 시계열 데이터베이스로, 전체 SQL을 지원합니다. PostgreSQL을 기반으로 하며, 시계열 데이터를 위한 NoSQL과 관계형 세계의 최고를 제공합니다.

이것은 TimescaleDB 쿼리 예제입니다

SELECT time,
exponential_moving_average(value, 0.5) OVER (ORDER BY time)
FROM testing
WHERE measurement = cpu and time > now() - '1 hour';

TimescaleDB는 PostgreSQL 확장으로서 관계형 데이터베이스입니다.
이것은 새로운 사용자들에게 짧은 학습 곡선을 제공하고, pg_dump 또는 pg_backup과 같은 백업 도구와 고가용성 도구를 상속한다는 것을 의미합니다. 이것은 다른 시계열 데이터베이스에 비해 장점입니다.
또한 주된 복제 방법으로 스트리밍 복제를 지원하며, 고가용성 설정에서 사용할 수 있습니다. 장애 복구 및 백업과 관련하여, ClusterControl과 같은 외부 시스템을 사용하여 이 과정을 자동화할 수 있습니다.
TimescaleDB에서는 각 시계열 측정값이 자신만의 행에 시간 필드와 그 뒤를 이어 여러 필드로 기록됩니다. 이 필드들은 float, int, string, boolean, 배열, JSON 블롭, 지리공간 차원, 날짜/시간/타임스탬프, 화폐, 바이너리 데이터 등이 될 수 있습니다.
필드(표준 인덱스), 여러 필드(복합 인덱스), 함수와 같은 표현식 또는 행의 부분 집합(부분 인덱스)에 대한 인덱스를 만들 수 있습니다. 이러한 필드 중 어느 하나를 부차적인 테이블로의 외래 키로 사용할 수 있으며, 이 테이블은 추가 메타데이터를 저장할 수 있습니다. 이와 같은 방식으로, 시스템에 필요한 스키마와 인덱스를 선택해야 합니다.

Performance

성능에 대해 이야기하자면, TimescaleDB comparison 블로그를 확인할 수 있습니다. 거기에서는 차트와 메트릭을 포함하여 두 데이터베이스 간의 상세한 성능 비교가 있습니다. 이 블로그에서 가장 중요한 정보 몇 가지를 살펴보겠습니다.

Insert

매우 낮은 카디널리티(예: 100개 장치)를 가진 워크로드의 경우 InfluxDB가 TimescaleDB보다 성능이 좋습니다.
카디널리티가 증가함에 따라 InfluxDB의 삽입 성능이 TimescaleDB보다 빠르게 떨어집니다.
중간에서 높은 카디널리티(예: 100개 장치에서 10개 메트릭 전송)를 가진 워크로드의 경우 TimescaleDB가 InfluxDB보다 성능이 좋습니다.

Read latency

간단한 쿼리의 경우 결과가 상당히 다양합니다. 어떤 경우에는 한 데이터베이스가 다른 것보다 확실히 우수한 반면, 다른 경우에는 데이터셋의 카디널리티에 따라 달라집니다. 이 차이는 종종 한 자리수에서 두 자리수 밀리초 범위에 있습니다.
복잡한 쿼리의 경우 TimescaleDB는 InfluxDB보다 훨씬 뛰어난 성능을 보이며, 더 다양한 쿼리 유형을 지원합니다. (여기서의 차이는 종종 몇 초에서 수십 초 범위에 있습니다.)

참고 :

https://www.timescale.com/blog/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877/

TimescaleDB vs. InfluxDB: Purpose-built for time-series data

An in-depth look into how TimescaleDB and InfluxDB stack up in terms of data model, query language, reliability, performance, ecosystem, operational management, and company/community support.

www.timescale.com

Kafka Consumer DLT(Dead Letter Topic) 전략

PI.314 — Mon, 11 Dec 2023 19:18:21 +0900

분산 시스템과 메시지 큐를 다루는 과정에서 메시지 처리 실패는 흔한 일입니다. 이러한 실패를 효과적으로 관리하기 위해 Dead Letter Topic(DLT)과 재시도 전략이 필수적입니다. 해당 포스팅에서는 DLT의 개념을 설명하고, Kafka를 사용하는 구체적인 예시를 통해 재시도 전략을 설계 및 구현하는 방법을 알아보겠습니다.

Dead Letter Topic(DLT)이란?

DLT는 메시지 처리에 실패했을 때 해당 메시지를 저장하는 Kafka 토픽입니다. 재시도 과정에서 여전히 실패하는 메시지를 위한 '마지막 피난처'로 사용됩니다. DLT의 주요 목적은 다음과 같습니다.

처리 실패 메시지의 안전한 저장
실패 원인 분석 및 디버깅 용이성 향상

재시도 전략의 필요성

메시지 처리 중 잠깐의 네트워크 지연이나 일시적인 오류로 인해 실패할 수 있습니다. 이러한 경우, 메시지를 바로 DLT로 보내기보다는 몇 차례 재시도를 하는 것이 바람직합니다. 재시도 전략은 다음과 같은 이점을 제공합니다

일시적 오류의 경우 자동 복구
데이터 손실 최소화

그러면 이제 DLT 구현 샘플 예제를 한번 살펴보겠습니다.

Retry 전략 설계 및 구현 샘플 예제

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
@RetryableTopic(
        attempts = "5",
        backoff = @Backoff(delay = 5000, multiplier = 2.0),
        dltStrategy = DltStrategy.FAIL_ON_ERROR,
        dltTopicSuffix = ".dlt",
        retryTopicSuffix = ".retry",
        exclude = {
                NonRetryableException.class
        })
@KafkaListener(
        topics = "sample.topic",
        groupId = "sample.topic.v1",
        containerFactory = "concurrentFactory"
)
 
public void consume(ConsumerRecord<String, String> record) {
    try {
        log.info("Received message: {}", record.value());
    } catch (RetryableException e) {
        log.error("Retryable error processing message: {}", e.getMessage());
        throw e;
    } catch (NonRetryableException e) {
        log.error("Non-retryable error processing message: {}", e.getMessage());
        throw e;
    }
}
Colored by Color Scripter
cs

@RetryableTopic을 통해 재시도 전략을 구성합니다. 이 설정에는 최대 시도 횟수(attempts), 지연 시간(delay), 지연 시간 증가율(multiplier), DLT 전략(dltStrategy), DLT 및 재시도 토픽 접미사(dltTopicSuffix, retryTopicSuffix)가 포함됩니다.

consume 메서드는 Kafka로부터 메시지를 수신하여 처리합니다. 이 과정에서 재시도 가능한 예외(RetryableException)와 재시도 불가능한 예외(NonRetryableException)를 구분하여 처리합니다.

DLT 구현 샘플 예제

1
2
3
4
5
6
7
8
9
10
11
12
13
@KafkaListener(
        topics = "sample.topic.dlt",
        groupId = "sample.topic.dlt.v1"
)
public void processDltMessages(
        ConsumerRecord<String, String> record,
        @Header(KafkaHeaders.RECEIVED_TOPIC) String topic,
        @Header(KafkaHeaders.RECEIVED_PARTITION_ID) int partitionId,
        @Header(KafkaHeaders.OFFSET) Long offset,
        @Header(KafkaHeaders.EXCEPTION_MESSAGE) String errorMessage
) {
    log.info("key: {}, value: {}, topic : {}, partition : {}, offset : {}, errorMessage : {}", record.key(), record.value(), topic, partitionId, offset, errorMessage);
}
Colored by Color Scripter
cs

샘플코드를 보면, processDltMessages 메서드는 DLT로 전송된 메시지를 처리하게 됩니다.

Kafka의 DLT는 메시지 처리 과정에서 발생하는 오류를 효과적으로 관리하기 위한 메커니즘으로 작용합니다. 처리 과정에서 재시도 전략에도 불구하고 실패한 메시지들은 DLT로 이동되어, 시스템의 주요 메시지 흐름에서 분리됩니다. 이는 전체 시스템의 안정성을 유지하고, 메인 데이터 스트림의 방해를 최소화하는 데 중요합니다.

DLT로 이동된 메시지들은 오류의 원인을 분석하고, 필요한 코드 수정 및 문제를 해결하는 데 사용됩니다.

저는 이 과정에서 개발자가 Kafka 리스너를 동적으로 제어할 수 있도록 구현했고, 개발자나 운영자는 DLT에 적재된 메시지를 분석한 후, 문제를 해결하고 Kafka 리스너의 Start/Stop을 제어함으로써, 수정 사항이 시스템에 올바르게 반영되었는지 확인할 수 있습니다.

이 부분에 대해서 예제를 한번 살펴보겠습니다.

Kafka Listener (DLT) 동적 제어 관련 샘플 예제

1. Kafka Listener 제어 관련 API 구현

먼저 외부에서 HTTP 요청을 통해 Kafka 리스너를 제어하도록 하는 API 구현이 필요합니다.

다음은 Kafka 토픽에 메시지를 보내는 요청을 처리하여 리스너의 상태(시작/중지)를 변경하는 명령을 Kafka Topic에 전달하는 과정입니다. (분산 시스템 환경에서는 여러 서버 또는 인스턴스가 동시에 운영되기 때문에 Kafka 토픽을 통해 리스너를 제어하는 방식으로 구현)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@Slf4j
@RestController
@RequestMapping("/v1/kafka")
@RequiredArgsConstructor
public class KafkaControlController {
 
    private final KafkaControlService kafkaControlService;
 
    @PostMapping("/control")
    public ResponseEntity<?> control(@RequestBody Map<String, Object> request) {
        try {
            kafkaControlService.control("kafka.control", request);
            return ResponseEntity.ok().body("Message sent successfully");
        } catch (Exception e) {
            log.error("Error sending Kafka message: ", e);
            return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body("Error sending message");
        }
    }
}
Colored by Color Scripter
cs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
@Slf4j
@Service
@RequiredArgsConstructor
public class KafkaControlService {
 
    private final KafkaProducerService kafkaProducerService;
    private final ObjectMapper objectMapper;
 
    public void control(String topic, Map<String, Object> event) {
        List<PartitionInfo> partitions = kafkaProducerService.partitions(topic);
        for (PartitionInfo partitionInfo : partitions) {
            try {
                String eventString = objectMapper.writeValueAsString(event);
                kafkaProducerService.send(new ProducerRecord<>(topic, partitionInfo.partition(), null, eventString));
                log.info("Message sent to partition {}: {}", partitionInfo.partition(), eventString);
            } catch (JsonProcessingException e) {
                log.error("Error processing JSON: ", e);
                throw new RuntimeException("Error processing JSON", e);
            }
        }
    }
}
 
Colored by Color Scripter
cs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
@Slf4j
@Service
@RequiredArgsConstructor
public class KafkaProducerService {
 
    private final KafkaTemplate<String, String> kafkaTemplate;
 
    public void sendMessage(String topic, String message) {
        kafkaTemplate.send(topic, message).addCallback(
            result -> log.info("Message sent to topic {}: {}", topic, message),
            ex -> log.error("Error sending message to topic {}: {}", topic, ex.getMessage())
        );
    }
 
    public void send(ProducerRecord<String, String> record) {
        kafkaTemplate.send(record).addCallback(
            result -> log.info("Message sent to topic-partition {}:{}", record.topic(), record.partition()),
            ex -> log.error("Error sending message to topic-partition {}:{}", record.topic(), ex.getMessage())
        );
    }
 
    public List<PartitionInfo> partitions(String topic) {
        return kafkaTemplate.partitionsFor(topic);
    }
}
 
Colored by Color Scripter
cs

2. KafkaListenerEndpointRegistry를 활용한 Kafka Listener 제어 기능 구현

이번에는 kafka.control 토픽로부터 소비한 메시지를 통해 특정 리스너의 상태(시작 또는 중지)를 변경하는 예제를 구현하겠습니다. (분산 환경에서 Kafka 리스너를 동적으로 제어하기 위함)

참고로 KafkaListenerEndpointRegistry는 Spring Kafka에서 Kafka 리스너 컨테이너들을 관리하는 역할을 하는 클래스입니다. 이 클래스를 사용함으로써, 개발자는 프로그래밍 방식으로 Kafka 메시지 리스너의 등록, 조회, 그리고 실행 상태를 제어할 수 있습니다.

1
2
3
4
5
6
7
    @KafkaListener(topics = "kafka.control", groupId = "control-group")
    public void listen(ConsumerRecord<String, String> record) {
        String listenerId = record.key(); 
        boolean active = Boolean.parseBoolean(record.value()); 
 
        kafkaListenerEndpoint.startOrStopListener(listenerId, active);
    }
Colored by Color Scripter
cs

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
@Component
@RequiredArgsConstructor
@Slf4j
public class KafkaListenerEndpoint {
 
    private final KafkaListenerEndpointRegistry registry;
 
 
    public void startOrStopListener(String listenerId, boolean active) {
        MessageListenerContainer listenerContainer = registry.getListenerContainer(listenerId);
        if (active) {
            listenerContainer.start();
            return;
        }
        listenerContainer.stop();
    }
}
 
Colored by Color Scripter
cs

이렇게 DLT & 동적 제어 메카니즘을 구축하게 되면 시스템의 전반적인 관리와 유지보수를 용이하게 하며, 복잡한 분산 환경에서의 운영상의 편의성을 제공합니다. 오류 발생 시 적절한 대응과 빠른 문제 해결을 통해, 시스템의 안정성과 신뢰성을 보장하는 데 필수적인 기능입니다.

DLT와 재시도 전략은 Kafka를 사용하는 분산 시스템에서 메시지 처리의 안정성을 보장하는 중요한 요소입니다. 예시를 통해 이러한 전략을 어떻게 구현할 수 있는지 알아보았습니다. 이러한 접근 방식은 메시지 처리 실패를 효과적으로 관리하고 시스템의 전반적인 신뢰성을 높이는 데 도움이 됩니다.

하루 n억 건 모니터링 데이터를 적재하는 Telemetry 서비스 만들기

PI.314 — Fri, 8 Dec 2023 16:23:02 +0900

문제 인식

회사에서 운영하고 있는 Telemetry 서비스는 1분 마다 각 장비의 모니터링 메시지를 받아서 파싱 및 저장하는 역할을 수행하고 있습니다.

해당 서비스는 원래 각 메시지를 개별적으로 처리하고, 이를 데이터베이스에 건별로 삽입하는 방식을 사용했습니다. 이 접근법은 단순하고 직관적이지만, 데이터 양이 급격하게 증가하면서 서비스 구조 변경이 필요했습니다.

Telemetry 서비스 구조 개선 전 (AS-IS)

그래서 대용량 데이터를 처리하기 위해 다음과 같이 3가지 개선 전략을 적용했습니다.

개선 전략 1: Kafka Batch Listener 도입

처리 효율성을 높이기 위해 Kafka Batch Listener를 도입했습니다. 전통적인 Kafka Listener가 메시지를 개별적으로 처리하는 것과 달리, Batch Listener는 여러 메시지를 한 번에 처리할 수 있어 네트워크 오버헤드와 처리 지연을 줄일 수 있습니다.

Batch Listener 설정

1
2
3
4
5
6
7
8
9
10
@Bean
public ConcurrentKafkaListenerContainerFactory<String, String> kafkaListenerContainerFactory() {
    ConcurrentKafkaListenerContainerFactory<String, String> factory = new ConcurrentKafkaListenerContainerFactory<>();
    factory.setConsumerFactory(consumerFactory());
    factory.setBatchListener(true);
    var containerProperties = factory.getContainerProperties();
    containerProperties.setAckMode(ContainerProperties.AckMode.TIME);
    containerProperties.setAckTime(10000);
    return factory;
}
Colored by Color Scripter
cs

1
2
3
4
@KafkaListener(topics = "topicName", containerFactory = "kafkaListenerContainerFactory")
public void listen(List<ConsumerRecord<String, String>> records) {
    // TODO : 로직 구현
}
Colored by Color Scripter
cs

Kafka Consumer Config 설정

그 외에도 Kafka Batch Listener를 도입할 때 고려해야 할 주요 Kafka Consumer Config 옵션들은 다음과 같습니다. 이러한 설정들은 Kafka 메시지의 효율적인 배치 처리를 위해 조정될 수 있으며, 시스템의 성능과 처리량에 중요한 영향을 미칩니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public ConsumerFactory<String, String> consumerFactory() {
    Map<String, Object> props = new HashMap<>();
    props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092");
    props.put(ConsumerConfig.GROUP_ID_CONFIG, "example-group");
    props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
    props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, false);
    props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
    props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class);
 
    // 해당 설정 값들은, 성능 최적화를 위해 서비스 특성을 고려하여 변경하시면 됩니다.
    props.put(ConsumerConfig.FETCH_MIN_BYTES_CONFIG, 500000); // fetch.min.bytes
    props.put(ConsumerConfig.FETCH_MAX_WAIT_MS_CONFIG, 3000); // fetch.max.wait.ms
    props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, 500);   // max.poll.records
    props.put(ConsumerConfig.MAX_PARTITION_FETCH_BYTES_CONFIG, 1048576); // max.partition.fetch.bytes
    props.put(ConsumerConfig.FETCH_MAX_BYTES_CONFIG, 10485760); // fetch.max.bytes
    props.put(ConsumerConfig.SESSION_TIMEOUT_MS_CONFIG, 15000); // session.timeout.ms
    props.put(ConsumerConfig.HEARTBEAT_INTERVAL_MS_CONFIG, 5000); // heartbeat.interval.ms
 
    return new DefaultKafkaConsumerFactory<>(props);
}
 
 
Colored by Color Scripter
cs

fetch.min.bytes	Kafka 브로커가 컨슈머에게 데이터를 반환하기 전에 최소한으로 모아야 하는 데이터의 양 더 큰 배치 크기를 위해 컨슈머가 더 많은 데이터를 기다리게 하고, 네트워크 사용량을 최적화하고 브로커의 부하를 줄일 수 있음
fetch.max.bytes	단일 fetch 요청으로 브로커에서 가져올 수 있는 데이터의 최대 크기 컨슈머가 한 번에 가져올 수 있는 데이터의 양을 제한하여 메모리 사용을 관리
max.poll.records	한 번의 poll() 호출에서 컨슈머가 가져올 수 있는 최대 레코드 수 이 값을 조정함으로써 컨슈머가 처리할 수 있는 데이터의 양을 제어할 수 있음. 배치 처리에 적합한 크기로 설정 필요
fetch.max.wait.ms	브로커가 fetch.min.bytes에 지정된 데이터 크기에 도달하기 위해 기다리는 최대 시간 응답 지연을 통제하여 더 큰 배치를 만들지만, 지연 시간이 너무 길면 전체 처리 속도가 느려질 수 있음
session.timeout.ms / heartbeat.interval.ms	컨슈머 그룹 내에서 세션 타임아웃과 하트비트 간격을 설정 배치 처리 시간이 길어질 경우, 컨슈머가 그룹에서 타임아웃되지 않도록 설정 필요
max.partition.fetch.bytes	파티션 당 한 번의 fetch 요청으로 가져올 수 있는 최대 데이터 크기 파티션별 데이터 크기를 제어하여 컨슈머의 메모리 사용을 관리

이러한 설정들은 Kafka의 성능과 리소스 사용에 직접적인 영향을 미칩니다. 따라서, 배치 리스너를 사용할 때 이러한 설정을 적절히 조정하는 것이 중요합니다. 설정값은 사용 사례, 메시지 크기, 처리량 요구사항, 시스템 리소스 등에 따라 달라질 수 있기 때문에 모니터링을 통해 최적의 값을 찾는 것이 좋습니다.

개선 전략 2: Bulk Insert 전략 사용

데이터베이스 작업 성능을 개선하기 위해, 각 메시지를 개별적으로 삽입하는 대신 Bulk Insert 전략을 적용했습니다. Spring JDBC의 Bulk Insert 기능을 사용하여 여러 레코드를 단일 쿼리로 데이터베이스에 삽입함으로써, 데이터베이스 쓰기 작업의 횟수를 줄이고 전반적인 성능을 향상시켰습니다.

1
2
3
4
public int[] save(List<Data> bulkData) {
     SqlParameterSource[] batch = SqlParameterSourceUtils.createBatch(bulkData.toArray());
     return namedParameterJdbcTemplate.batchUpdate(SQL_INSERT_TELEMETRY_INFO), batch);
}
Colored by Color Scripter
cs

개선 전략 3: 파티션 수 증가 대신 Concurrency & @Async 사용

Kafka에서 파티션 수를 늘리는 것은 다음과 같은 이슈들을 야기할 수 있습니다.

1. 브로커의 메모리 사용 증가

Kafka 브로커는 각 파티션에 대한 메타데이터를 메모리에 저장합니다. 파티션 수가 증가하면 이 메타데이터의 크기도 증가하여 브로커의 메모리 사용량이 늘어납니다.

2. 리더 선출과 리밸런싱 오버헤드

Kafka는 각 파티션에 대해 리더를 선출하고, 컨슈머 그룹 내에서 파티션을 리밸런싱합니다. 파티션 수가 많으면 이러한 작업이 더 자주 발생할 수 있으며, 이는 추가적인 오버헤드를 유발합니다.

3. 복제 지연

각 파티션은 여러 브로커에 복제됩니다. 파티션 수가 많을수록 복제할 데이터도 많아지기 때문에, 복제 지연을 증가시킬 수 있습니다.

4. 장애 복구 시간 증가

파티션이 많아지면 장애 발생 시 복구해야 할 데이터 양도 늘어나기 때문에, 전체 복구 시간을 길어지게 할 수 있습니다.

위와 같은 이슈들 때문에, Telemetry 서비스의 경우 시스템의 확장성과 관리 효율성을 고려하여 단순히 파티션 수를 증가시키는 대신에 동시성(Concurrency)과 @Async 어노테이션을 사용했습니다.

Concurrency 설정

1
2
3
4
5
6
7
8
9
10
11
@Bean
public ConcurrentKafkaListenerContainerFactory<String, String> kafkaListenerContainerFactory() {
    ConcurrentKafkaListenerContainerFactory<String, String> factory = new ConcurrentKafkaListenerContainerFactory<>();
    factory.setConsumerFactory(consumerFactory());
    factory.setBatchListener(true);
    factory.setConcurrency(2);
    var containerProperties = factory.getContainerProperties();
    containerProperties.setAckMode(ContainerProperties.AckMode.TIME);
    containerProperties.setAckTime(10000);
    return factory;
}
Colored by Color Scripter
cs

Async 설정 및 구현

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
@Configuration
@EnableAsync
public class AsyncConfig {
 
    @Bean(name = "taskExecutorBatch")
    public Executor taskExecutorBatch() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(3);
        executor.setMaxPoolSize(8);
        executor.setQueueCapacity(20);
        executor.setKeepAliveSeconds(120);
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.setThreadNamePrefix("Async-Executor-Batch");
        executor.initialize();
        return executor;
    }
 
    @Bean(name = "taskExecutorParser")
    public Executor taskExecutorParser() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(3);
        executor.setMaxPoolSize(8);
        executor.setQueueCapacity(20);
        executor.setKeepAliveSeconds(120);
        executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        executor.setThreadNamePrefix("Async-Executor-Parser");
        executor.initialize();
        return executor;
    }
}
Colored by Color Scripter
cs

1
2
3
4
5
@Async("taskExecutorBatch")
@Transactional
public void saveAll(List<Data> bulkdata) {
    dao.saveAll(bulkdata);
}
Colored by Color Scripter
cs

이렇게 Concurrency & Async 설정을 통해 파티션 수를 증가시키지 않고 애플리케이션 레벨에서의 스케일링하는 방법을 알아보았습니다. 애플리케이션 레벨에서의 스케일링은 Kafka 시스템의 구조적 변경 없이도 가능하기 때문에 Kafka를 효율적으로 관리할 수 있었습니다.

이러한 전략들의 도입으로 Telemetry 서비스는 하루에 수억 건의 데이터를 처리할 수 있는 서비스 아키텍처로 바뀌었습니다.

Kafka Batch Listener의 사용은 데이터 처리량이 많은 상황에서도 효율적인 메시지 처리를 가능하게 했으며, Bulk Insert 전략은 데이터베이스 쓰기 작업의 성능을 크게 향상시켰습니다. 또한, 파티션 수를 무작정 늘리는 대신 Concurrency와 @Async 어노테이션을 활용함으로써 시스템의 복잡성을 최소화하면서 처리 능력을 극대화했습니다.

Telemetry 서비스 구조 개선 전 (TO-BE)

이러한 개선을 통해, Telemetry 서비스는 높은 처리량과 확장성을 요구하는 환경에서도 원활하게 작동할 수 있는 견고한 아키텍처를 갖추게 되었습니다.

미션 목표

1분마다 50만개 메시지 처리 (하루 누적 7억 2천개)
1개 Message 크기 : 5 KB

부하테스트 환경

Kafka Broker	Instance Type: kafka.m5.2xlarge Zone 당 Broker 개수: 1개 총 Broker 개수: 2개
K8S Deployment	Pod 개수: 4개 리소스 사양: Limits: CPU - 6 cores, 메모리 - 6000Mi Requests: CPU - 1 core, 메모리 - 1000Mi
Timescale DB (EC2)	Access Node: m5.4xlarge Data Node 1: m5.4xlarge Data Node 2: m5.4xlarge

Kafka Batch Listener를 활용하여 성능 개선하기

PI.314 — Sun, 18 Jun 2023 20:58:14 +0900

Kafka Consumer를 운영하는 서비스에서 메시지를 개별적으로 처리하면, 각 메시지를 가져오고 처리하는데 필요한 네트워크 오버헤드와 CPU 사용량이 늘어난다.

특히, 각 메시지에 대해 별도의 트랜잭션을 시작하고 커밋하는 것은 비용이 많이 든다. DB와의 네트워크 통신, 트랜잭션 로그의 쓰기, 디스크 I/O 등에 의한 오버헤드가 각 메시지마다 발생하므로 메시지 처리 성능이 저하될 수 있다. 뿐 만 아니라 각 메시지 처리에 대해 별도 DB Connection Pool이 고갈되어, 새로운 트랜잭션을 생성할 수 없게된다.

이러한 경우 배치 처리를 사용하면 여러 메시지를 하나의 트랜잭션으로 쉽게 묶어 처리할 수 있다.

그럼 Batch Listener를 구현하는 방법에 대해 알아보자.

1. Kafka Listener 구현

    @KafkaListener(topics = {"topic"}, containerFactory = "batchKafkaListenerContainerFactory")
    public void consume(List<ConsumerRecord<String, String>> records, Acknowledgment ack) {	
        
        // 로직 수행
        handler.process();
        
        // Commit
        ack.acknowledge();
    }

자동/수동 커밋은 상황에 맞게 사용하면 된다.

2. Container Factory 설정

    @Bean
    public ConcurrentKafkaListenerContainerFactory<String, String> batchKafkaListenerContainerFactory() {
        ConcurrentKafkaListenerContainerFactory<String, String> factory = new ConcurrentKafkaListenerContainerFactory<>();
        var containerProperties = factory.getContainerProperties();
        containerProperties.setAckMode(ContainerProperties.AckMode.MANUAL_IMMEDIATE);
        // Auto Commit일 경우
        // containerProperties.setAckMode(ContainerProperties.AckMode.BATCH);
        factory.getContainerProperties().setIdleBetweenPolls(60000);
        factory.setConsumerFactory(batchConsumerFactory());
        factory.setBatchListener(true);
        return factory;
    }

setIdleBetweenPolls: 두 poll 사이의 최대 대기 시간을 설정
setBatchListener: Listener가 배치 모드로 동작 (여러 메시지를 한 번에 가져와 처리)

setIdleBetweenPolls를 설정하지 않으면, Consumer가 바로 poll을 수행하기 때문에 상황에 따라 batch가 의미가 없어질 수 도 있다. setIdleBetweenPolls를 설정하면, poll을 수행하기 전에 idle time 동안 메시지를 쌓고 난후에 batch 처리할 수 있다.

    @Bean
    public ConsumerFactory<String, String> batchConsumerFactory() {
        Map<String, Object> props = new HashMap<>();
        props.put(CommonClientConfigs.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
        props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, keyDeserializer);
        props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, valueDeserializer);
        props.put(ConsumerConfig.GROUP_ID_CONFIG, groupId);
        props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, 500);
        props.put(ConsumerConfig.MAX_POLL_INTERVAL_MS_CONFIG, 300000);
        props.put(ConsumerConfig.FETCH_MAX_WAIT_MS_CONFIG, 60000);
        // Auto Commit일 경우
        // props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, true);
        // props.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, 10000);

        return new DefaultKafkaConsumerFactory<>(props);
    }

MAX_POLL_RECORDS_CONFIG: 한 번의 poll에 의해 반환될 수 있는 최대 레코드 수를 지정
MAX_POLL_INTERVAL_MS_CONFIG: Consumer가 Broker에게 정상적으로 응답하기 위한 최대 시간을 지정
FETCH_MAX_WAIT_MS_CONFIG: Broker가 요청에 응답하기 전에 대기하는 최대 시간을 지정

batch 처리의 효과를 높이기 위해서는 MAX_POLL_RECORDS_CONFIG를 통해 반환될 수 있는 최대 레코드 수를 적절하게 지정해야 한다. 각 비즈니스 환경에 따라 다르기 때문에 상황을 고려해서 적절하게 설정하면 된다.

FETCH_MAX_WAIT_MS_CONFIG는 메세지가 없을 때 대기하는 최대시간을 설정할 수 있다. 이 때 주의해야할 것은 FETCH_MAX_WAIT_MS_CONFIG 값은 MAX_POLL_INTERVAL_MS_CONFIG 값보다 작아야 된다. MAX_POLL_INTERVAL_MS_CONFIG은 Consumer가 Brokerd에게 정상적으로 응답하기 위한 최대 시간을 설정하는 값이기 때문에 FETCH_MAX_WAIT_MS_CONFIG값이 더 크면 Timeout이 발생하여 Broker가 비정상으로 인지하여 Rebalancing이 일어날 수 있다.

3. 수행 결과

Kafka Batch Listener를 통해 한 번에 여러 메시지를 batch 처리하고, bulk Insert까지 잘 수행 된 것을 볼 수 있다.

[우아한테크캠프 Pro] 8주차 미션 후기 (안정적인 서비스 만들기)

PI.314 — Tue, 3 Jan 2023 00:15:48 +0900

우아한테크캠프 Pro 8주차 안정적인 서비스 만들기 미션을 진행한 내용과 후기를 정리해보았습니다.

미션 저장소

https://github.com/Gyeom/infra-subway-performance

GitHub - Gyeom/infra-subway-performance

Contribute to Gyeom/infra-subway-performance development by creating an account on GitHub.

github.com

학습 내용

HTTP 개선에 따른 차이를 이해하고 Reverse Proxy 성능 개선을 해봅니다.
HTTP Cache 전략을 이해하여 적절한 정책을 설정해봅니다.
쿼리를 최적화하여 조회 성능을 개선해봅니다.
인덱스를 설정하여 조회 성능을 개선해봅니다.

단계별 요구사항 및 PR 리뷰

1단계 - 화면 응답 개선하기

Reverse Proxy 개선하기
WAS 성능 개선하기
부하테스트 각 시나리오의 요청시간을 목푯값 이하로 개선 개선 전 / 후를 직접 계측하여 확인

https://github.com/next-step/infra-subway-performance/pull/410

[김대겸] Step1 PR by Gyeom · Pull Request #410 · next-step/infra-subway-performance

안녕하세요 리뷰어님, Step1 화면 응답 개선하기 미션 리뷰 요청드립니다~! revers proxy 및 redis 캐싱적용을 했지만 개선 효과를 비교하기 좀 어려운 상황인데, 자문을 구해도 될까요~? 감사합니다.

github.com

Reverse Proxy와 WAS에 캐싱을 적용했는데 생각보다 개선효과과 미미했다.
부하테스트를 진행할 때는 일정 간격을 두고 점진적으로 VUser가 증가 되도록 시나리오를 구성해보자.

2단계 - 스케일 아웃 (with ASG)

springboot에 HTTP Cache, gzip 설정하기
Launch Template 작성하기
Auto Scaling Group 생성하기
Smoke, Load, Stress 테스트 후 결과를 기록

https://github.com/next-step/infra-subway-performance/pull/459

[김대겸] Step2 PR by Gyeom · Pull Request #459 · next-step/infra-subway-performance

안녕하세요 리뷰어님, 2단계 - 스케일 아웃 (with ASG) 리뷰 요청 드립니다. 일단 저번에 healthy 힌트를 주셔서, 가장 먼저 helathy 포트를 8080으로 변경하여 정상 상태로 만들었습니다. 그래도 똑같은

github.com

Auto Scaling은 warm up이 있어서 구간을 보다 길게 갖고 가자.

시작템플릿에 redis를 띄우는 스크립트까지 포함 했다. 이렇게 되면 매 인스턴스마다 불필요하게 redis가 새로 만들어진다.

Controller에서 HttpServletResponse 를 받은 후 직접 `Cache-Controle`을 할당하여 설정할 수도 있고, WebContentInterceptor를 활용할 수 도 있다.
로그인용 사용자 이름, 비밀번호 및 기타 민감한 정보들을 보호하기 위해 SSL 을 로그인 페이지나 회원 정보 페이지등은 SSL로 암호화하는 경우가 많다. SSL 을 사용해서 민감한 정보들을 보호한다고 해도 브라우저에 이 정보가 캐싱되면 문제가 발생할 수 있기 때문에 `Cache-Control: no-cache, no-store, must-revalidate` 와 같이 사용하면 브라우저 캐싱을 방지할 수 있다. 단 캐싱을 하지 않으면 성능 저하가 발생할 수 있으므로 로그인 페이지등에 제한적으로 사용해야 한다.

3단계 - 쿼리 최적화

활동중인(Active) 부서의 현재 부서관리자(manager) 중 연봉 상위 5위안에 드는 사람들이 최근에 각 지역별로 언제 퇴실(O)했는지 조회해보세요.
(사원번호, 이름, 연봉, 직급명, 지역, 입출입구분, 입출입시간)
인덱스 설정을 추가하지 않고 200ms 이하로 반환합니다.
- M1의 경우엔 시간 제약사항을 달성하기 어렵습니다. 2s를 기준으로 해보시고 어렵다면, 일단 리뷰요청 부탁드려요

급여 테이블의 사용여부 필드는 사용하지 않습니다. 현재 근무중인지 여부는 종료일자 필드로 판단해주세요.

https://github.com/next-step/infra-subway-performance/pull/485

[김대겸] Step3 PR by Gyeom · Pull Request #485 · next-step/infra-subway-performance

안녕하세요 리뷰어님 :) 3단계 쿼리최적화 리뷰 요청드립니다. 이번 미션은 성능 효율이 중요했기 때문에, query condition부분에 신경을 써서 작성했습니다. 감사합니다.

github.com

4단계 - 인덱스 설계

주어진 데이터셋을 활용하여 아래 조회 결과를 100ms 이하로 반환
- M1의 경우엔 시간 제약사항을 달성하기 어렵습니다. 2배를 기준으로 해보시고 어렵다면, 일단 리뷰요청 부탁드려요
- Coding as a Hobby 와 같은 결과를 반환하세요.
- 프로그래머별로 해당하는 병원 이름을 반환하세요. (covid.id, hospital.name)
- 프로그래밍이 취미인 학생 혹은 주니어(0-2년)들이 다닌 병원 이름을 반환하고 user.id 기준으로 정렬하세요. (covid.id, hospital.name, user.Hobby, user.DevType, user.YearsCoding)
- 서울대병원에 다닌 20대 India 환자들을 병원에 머문 기간별로 집계하세요. (covid.Stay)
- 서울대병원에 다닌 30대 환자들을 운동 횟수별로 집계하세요. (user.Exercise)

https://github.com/next-step/infra-subway-performance/pull/513

[김대겸] Step4 PR by Gyeom · Pull Request #513 · next-step/infra-subway-performance

안녕하세요 리뷰어님 4단계 - 인덱스 설계 리뷰 요청드립니다. 이번 리뷰도 잘 부탁드립니다 ~!

github.com

[추가] 페이징, Replication

페이징 쿼리 작성
MySQL Replication with JPA

https://github.com/next-step/infra-subway-performance/pull/542

[김대겸] Step5 PR by Gyeom · Pull Request #542 · next-step/infra-subway-performance

안녕하세요 리뷰어님, [추가] 페이징, Replication 단계 리뷰 요청드립니다. 처음에 제가 설정을 잘못했는지 위와 같이 Slave_IO_Running이 NO로 나오더라구요.. 현재는 정상적으로 나오도록 조치했습니

github.com

미션 회고

이번 미션에서 Auto Scaling Group을 구성하는 실습을 진행하면서 삽질을 좀 많이했다. 502 Bad Gateway가 발생해서 보니 서버가 아예 구동되지 않았고 시작템플릿의 문제임을 짐작할 수 있었다. 원인은 mac에서 업로드한 배포스크립트의 행간 문제였던것으로 파악되었다. 그 외에도 인증 관련 이슈 때문에 시간을 많이 날려먹었는데 알고보니 chain.pem을 잘못 복사해서 alb에 적용해서 발생한 이슈였다.

8주차까지 우아한테크캠프 PRO 미션을 모두 완료했다. 8주 전 보다 많은 양의 학습 지식을 습득 한 것은 분명하다. 밑 빠진 독이 되지 않기 위해서 지금까지 배운 내용들을 복습하자.

늘 초심의 마음으로.

[우아한테크캠프 Pro] 7주차 미션 후기 (레거시 코드 리팩터링)

PI.314 — Mon, 2 Jan 2023 22:19:41 +0900

우아한테크캠프 Pro 7주차 레거시 코드 리팩터링을 진행한 내용과 후기를 정리해보았습니다.

미션 저장소

https://github.com/Gyeom/jwp-refactoring

GitHub - Gyeom/jwp-refactoring

Contribute to Gyeom/jwp-refactoring development by creating an account on GitHub.

github.com

학습 내용

많은 기업들이 "서비스를 안정적으로 운영하면서 레거시 코드를 리팩터링할 수 있는 역량을 갖춘 개발자"를 요구한다.
- 레거시 프로젝트를 리팩터링하는 경험을 통해 서비스를 안정적으로 운영하면서 레거시 코드를 리팩터링할 수 있는 역량을 키운다.
- 프로젝트를 만드는 단계에서 끝나는 것이 아니라 프로젝트를 완료한 후 일정 기간 유지보수를 함으로써 레거시 코드를 리팩터링하는 경험을 쌓는다.

단계별 요구사항 및 PR 리뷰

1단계 - 테스트를 통한 코드 보호

kitchenpos 패키지의 코드를 보고 키친포스의 요구 사항을 README.md에 작성한다. 미션을 진행함에 있어 아래 문서를 적극 활용한다.
- 마크다운(Markdown) - Dooray!
정리한 키친포스의 요구 사항을 토대로 테스트 코드를 작성한다. 모든 Business Object에 대한 테스트 코드를 작성한다. @SpringBootTest를 이용한 통합 테스트 코드 또는 @ExtendWith(MockitoExtension.class)를 이용한 단위 테스트 코드를 작성한다.
인수 테스트 코드 작성은 권장하지만 필수는 아니다. 미션을 진행함에 있어 아래 문서를 적극 활용한다.
- Testing in Spring Boot - Baeldung
- Exploring the Spring Boot TestRestTemplate

https://github.com/next-step/jwp-refactoring/pull/651

[김대겸] Step1 PR by Gyeom · Pull Request #651 · next-step/jwp-refactoring

안녕하세요 리뷰어님, 1단계 - 테스트를 통한 코드 보호 리뷰 요청 드립니다. 잘 부탁드립니다 :)

github.com

재사용이 빈번한 객체는 fixture 올려놓자.

2단계 - 서비스 리팩터링

단위 테스트하기 어려운 코드와 단위 테스트 가능한 코드를 분리해 단위 테스트 가능한 코드에 대해 단위 테스트를 구현한다.

https://github.com/next-step/jwp-refactoring/pull/681

[김대겸] Step2 PR by Gyeom · Pull Request #681 · next-step/jwp-refactoring

안녕하세요 리뷰어님, 정말 힘들었던 미션이었습니다 ㅠㅠㅠㅠ 도메인 생성 관련 테스트 코드 작성 서비스 레이어에 있던 비즈니스 로직을 각 도메인에 책임 부여 dao 정상 동작을 위해, dao호출

github.com

어떻게하면 inquery로 개선할 수 있을 지 고민하다가 복잡도가 N이 초과하지 않는 방법으로 map을 활용했다.

    private List<MenuProduct> findAllMenuProductsByProductId(List<MenuProductRequest> menuProductRequests) {
        List<Product> products = toProduct(menuProductRequests);
        validateProducts(products, menuProductRequests);
        Map<Long, Product> productIdToProduct = new HashMap<>();
        
        for (Product product : products) {
            productIdToProduct.put(product.getId(), product);
        }
        
        return menuProductRequests.stream()
        		.map(menuProductRequest -> menuProductRequest.toMenuProduct(productIdToProduct.get(menuProductRequest.getProductId())))
  		        .collect(Collectors.toList());
}

단순히 change보다 해당 명령을 표현할 수 있는 네이밍을 고려하자.

enum 사용 시, 역할을 보다 쉽고 명확하게 알아볼 수 있도록 description을 만들어 관리하자.

OneToMany Lazy에서는 Hibernate Batch Size 옵션의 사용을 고려하자.

repository를 통해 조회하는 것은 findXXX 규칙을 사용하자. (다른 CRUD 도 마찬가지)

3단계 - 의존성 리팩터링

이전 단계에서 객체 지향 설계를 의식하였다면 아래의 문제가 존재한다. 의존성 관점에서 설계를 검토해 본다.

메뉴의 이름과 가격이 변경되면 주문 항목도 함께 변경된다. 메뉴 정보가 변경되더라도 주문 항목이 변경되지 않게 구현한다.
클래스 간의 방향도 중요하고 패키지 간의 방향도 중요하다. 클래스 사이, 패키지 사이의 의존 관계는 단방향이 되도록 해야 한다.
데이터베이스 스키마 변경 및 마이그레이션이 필요하다면 아래 문서를 적극 활용한다.
- DB도 형상관리를 해보자!

https://github.com/next-step/jwp-refactoring/pull/735

[김대겸] Step3 PR by Gyeom · Pull Request #735 · next-step/jwp-refactoring

안녕하세요 리뷰어님, 3단계 의존성 리팩터링 리뷰요청드립니다. 패키지 분리 (Lifecycle이 같은 도메인들은 같은 Aggregate) 서로 다른 Aggregate의 엔티티간의 단방향 참조를 할 수 있도록 간접참조 활

github.com

조영호님의 우아한 객체지향 강의를 듣고, 꼭 절차지향이 안 좋은게 아니다라는 것을 깨달았다.
비즈니스 로직을 보다 명확하고 쉽게 관리할 수 있도록 Validator를 활용해 절차지향을 적용했다.
SRP, OCP를 준수해 validator들을 분리하고, validator들을 관리하는 별도의 객체를 생성해서 관리하면 보다 확장에 용이할 것 같다.

양방향 의존관계를 끊기 위해서, 인터페이스 및 구현체를 활용하여 DIP 원칙을 적용했다.

미션 회고

이번 미션은 생각보다 정말 손이 많이갔다. 우선 처음에는 서비스 레이어에 있는 비즈니스 로직을 도메인에 책임을 부여하도록 리팩토링을 진행했는데, DTO를 개선하면서 구조가 바뀌다보니 테스트 코드에서 계속 에러가 발생했다. 그래서 한번에 모든 것을 변경하려고 하기보다 하나씩 점진적으로 리팩토링을 해나갔다. 어느 정도 코드 리팩토링이 된 후에는, 서비스 의존성 관점에서 설계를 검토하여 리팩토링을 진행했다. 미션을 진행하면서 평소에 어렵게만 느껴졌던 DDD 개념들이 하나씩 이해가 되기 시작했고, 프로젝트의 완성도가 점점 갖춰지는 것이 눈에 띄게 보여 성취감을 크게 느꼈다. 특히, 조영호님의 우아한 객체지향 강의를 통해 배운 'Validator를 활용한 절차지향 적용'과 '양방향 의존관계를 끊기 위한 DIP원칙 적용'은 평소에 내가 생각하던 고정관념을 완전히 깨뜨려 버렸다.

우아한 테크 캠프 PRO 과정에 도전하길 참 잘했다는 생각이 든다.

[우아한테크캠프 Pro] 6주차 미션 후기 (서비스 진단하기)

PI.314 — Mon, 2 Jan 2023 00:46:48 +0900

우아한테크캠프 Pro 6주차 서비스 진단하기 미션을 진행한 내용과 후기를 정리해보았습니다.

미션 저장소

https://github.com/Gyeom/infra-subway-monitoring

GitHub - Gyeom/infra-subway-monitoring

Contribute to Gyeom/infra-subway-monitoring development by creating an account on GitHub.

github.com

학습 내용

USE 방법론을 활용하여 서버를 진단할 수 있고 쓰레드 덤프를 확인해봅니다.
webpageteat, pagespeed를 활용하여 웹 성능 예산을 고민해봅니다.
목표치를 정하고 부하테스트를 직접 수행해봅니다.

단계별 요구사항 및 PR 리뷰

1단계 - 웹 성능 테스트

웹 성능 예산 작성 후 서버 목표 응답시간 도출

https://github.com/next-step/infra-subway-monitoring/pull/525

[김대겸] Step1 PR by Gyeom · Pull Request #525 · next-step/infra-subway-monitoring

안녕하세요 리뷰어님, 1단계 - 웹 성능 테스트 리뷰요청 드립니다. 감사합니다!

github.com

WebPageTest, PageSpeed 등에서 테스트를 진행한 후, 웹 성능 예산을 작성했다.
크롬 브라우저 도구를 활용하여 퍼포먼스 탭에서 각 api별 요청 응답시간을 확인했고, 웹 성능 예산에 영향을 주는 api 를 확인해보고 가설을 세웠다.

2단계 - 부하테스트

테스트 전제조건 정리
- 대상 시스템 범위
- 목푯값 설정 (latency, throughput, 부하 유지기간)
- 부하 테스트 시 저장될 데이터 건수 및 크기
Smoke, Load, Stress 테스트 후 결과를 기록

https://github.com/next-step/infra-subway-monitoring/pull/569

[김대겸] Step2 PR by Gyeom · Pull Request #569 · next-step/infra-subway-monitoring

안녕하세요 리뷰어님, 2단계 부하테스트하기 PR 입니다. 이번 미션도 리뷰 잘 부탁드립니다

github.com

부하테스트 실습을 진행하면서 진행과정을 정리해 보았다.

3단계 - 로깅, 모니터링

애플리케이션 진단하기 실습을 진행해보고 문제가 되는 코드를 수정
로그 설정하기
Cloudwatch로 모니터링

https://github.com/next-step/infra-subway-monitoring/pull/601

[김대겸] Step3 PR by Gyeom · Pull Request #601 · next-step/infra-subway-monitoring

안녕하세요 리뷰어님~ 3단계 - 로깅, 모니터링 리뷰 요청 드립니다. 이번에도 리뷰 잘 부탁드립니다

github.com

로그는 오래된 순서대로 지워지도록 maxHistory를 설정해주자.

미션 회고

이번 미션을 통해 웹 성능 예산 작성, 부하테스트, 로깅 설정 등 서비스 진단에 필요한 실습들을 순차적으로 진행해 볼 수 있었다. 특히, 테스트 설정 값을 직접 구해보고 시나리오를 구성해보는 과정을 경험할 수 있어 흥미로웠고, 부하테스트 결과 값이 기대했던 값으로 잘 나오지 않아서 몇차례 다시 시도하느라 시간이 오래 걸렸지만 꽤 유익한 시간이었다.

[우아한테크캠프 Pro] 5주차 미션 후기 (Subway - ATDD & 단위테스트)

PI.314 — Sun, 1 Jan 2023 23:54:54 +0900

우아한테크캠프 Pro 5주차 ATDD & 단위테스트 미션을 진행한 내용과 후기를 정리해보았습니다.

미션 저장소

https://github.com/Gyeom/atdd-subway-service

GitHub - Gyeom/atdd-subway-service: 우아한테크캠프 pro ATDD 과정 저장소

우아한테크캠프 pro ATDD 과정 저장소. Contribute to Gyeom/atdd-subway-service development by creating an account on GitHub.

github.com

학습 내용

ATDD를 기반으로 지하철 노선도 서비스를 단계별 구현한다.

단계별 요구사항 및 PR 리뷰

1단계 - 인수 테스트 기반 리팩터링

LineService의 비즈니스 로직을 도메인으로 옮기기
한번에 많은 부분을 고치려 하지 말고 나눠서 부분부분 리팩터링하기
전체 기능은 인수 테스트로 보호한 뒤 세부 기능을 TDD로 리팩터링하기

https://github.com/next-step/atdd-subway-service/pull/756

[김대겸] Step1 PR by Gyeom · Pull Request #756 · next-step/atdd-subway-service

안녕하세요 리뷰어님 Step1 인수 테스트 기반 리팩터링 PR 리뷰 요청 드립니다. 잘 부탁드립니다 :)

github.com

@BeforeEach에서 테스트 픽스쳐를 사용하게 되면 테스트 간 결합도가 높아진다.
클래스 외부에 static 팩토리 메소드를 만들어서 사용하자.
테스트 픽스처 올바르게 사용하기

Optional은 비싸다. 그리고 컬렉션은 null이 아니라 비어있는 컬렉션을 반환하는 것이 좋을 때가 많다. 따라서 컬렉션은 Optional로 감싸서 반환하지 말고 비어있는 컬렉션을 반환하자.
Java Optional 바르게 쓰기

주생성자는 하나 뿐이고, 나머지는 secondary constructor다. secondary constructor는 this(..)를 통해서 주생성자를 호출하는 것이 역할이다. 잘 구성된 클래스는 반드시 하나의 주생성자만 가지고 있어야하고, 모든 secondary constructor 이후에 선언되어야 한다. 그 이유는 코드의 중복을 줄여주기 때문이다.
주생성자, 부생성자

2단계 - 경로 조회 기능

최단 경로 조회 인수 테스트 만들기
최단 경로 조회 기능 구현하기

https://github.com/next-step/atdd-subway-service/pull/765

[김대겸] Step2 PR by Gyeom · Pull Request #765 · next-step/atdd-subway-service

안녕하세요 리뷰어님, 2단계 - 경로 조회 기능 PR 입니다. 이번 리뷰도 잘 부탁드립니다

github.com

매직넘버 상수화를 생활화 하자.

3단계 - 인증을 통한 기능 구현

토큰 발급 기능 (로그인) 인수 테스트 만들기
인증 - 내 정보 조회 기능 완성하기
인증 - 즐겨 찾기 기능 완성하기

https://github.com/next-step/atdd-subway-service/pull/803

[김대겸] Step3 PR by Gyeom · Pull Request #803 · next-step/atdd-subway-service

안녕하세요 리뷰어님, 3단계 - 인증을 통한 기능 구현 PR 입니다. 이번 리뷰도 잘 부탁드립니다 :)

github.com

4단계 - 요금 조회

경로 조회 시 거리 기준 요금 정보 포함하기
노선별 추가 요금 정책 추가
연령별 할인 정책 추가

age를 0으로 관리하다보면 나중에 side effect가 존재할 것 같아서 null은 null로 관리하는게 맞다고 판단했다. 물론 정답은 없겠지만, Enum을 통해 default 값을 관리하면 보다 명확하고 이해하기 쉬워서 유지보수에 용이할 것 같다.
리뷰어님이 말씀해주신 것처럼 null 체크를 계속해야 하는 이슈도 해결된다.

LoginMember를 상속받아서 GuestMember 클래스를 따로 관리하면 보다 명확해진다.
뿐 만 아니라, GUEST는 어차피 동일한 값을 유지하기 때문에 static final로 관리하는 것은 좋은 인사이트다.

미션 회고

이번 미션의 주제는 'ATDD & 단위테스트' 였지만 테스트 픽스처, Optional, 주생성자&부생성자, Enum Default값 활용 등 코드를 관리하는데 용이한 TIP들을 많이 공유받을 수 있었다. ATDD는 3주차 때도 진행해서 그런지 이번 미션에서는 보다 수월하게 진행할 수 있었다.

[우아한테크캠프 Pro] 3주차 미션 후기 (Subway - ATDD)

PI.314 — Sun, 1 Jan 2023 23:05:13 +0900

우아한테크캠프 Pro 3주차 ATDD 미션을 진행한 내용과 후기를 정리해보았습니다.

미션 저장소

https://github.com/Gyeom/atdd-subway-admin

GitHub - Gyeom/atdd-subway-admin: 우아한테크캠프 pro ATDD 과정 저장소

우아한테크캠프 pro ATDD 과정 저장소. Contribute to Gyeom/atdd-subway-admin development by creating an account on GitHub.

github.com

학습 내용

미션 수행 방법 문서를 참고하여 실습 환경을 구축한다.
지하철 노선도를 관리할 수 있는 어드민 서비스를 단계별로 구현하세요.
인수 테스트 주도 개발 프로세스를 단계별로 경험하세요.

단계별 요구사항 및 PR 리뷰

1단계 - 지하철역 인수 테스트 작성

지하철역 관련 인수 테스트를 완성하세요.
- 지하철역 목록 조회 인수 테스트 작성하기
- 지하철역 삭제 인수 테스트 작성하기

https://github.com/next-step/atdd-subway-admin/pull/837

[김대겸] Step1 PR by Gyeom · Pull Request #837 · next-step/atdd-subway-admin

안녕하세요 리뷰어님, 1단계 지하철역의 인수 테스트 작성 PR입니다. 잘 부탁드립니다 :)

github.com

리뷰어님께서 인수테스트의 동작들을 분리해보는 것을 제안해주셨고 샘플 예제까지 링크를 공유해주셨다.

    @DisplayName("지하철 노선 생성하면 응답상태 201을 반환한다.")
    @Test
    void createLine() {
        // given
        StationResponse 종각역 = 등록된_지하철역("종각역").as(StationResponse.class);
        StationResponse 역삼역 = 등록된_지하철역("역삼역").as(StationResponse.class);

        // when
        ExtractableResponse<Response> response =
                지하철노선_생성_요청("1호선", "indigo darken-2", 종각역.getId(), 역삼역.getId(), 10);

        // then
        지하철노선_생성_응답상태_201_검증(response);
    }

피드백을 수용하여 위 코드와 같이 Given - When - Then 의 각 구문을 함수로 리팩토링했더니 코드가 깔끔해졌고, 테스트코드로 API 문서를 대체할 수 있다는게 어떤 느낌인지 알 수 있었다.

2단계 - 지하철 노선 기능

기능 구현 전에 인수 조건을 만족하는지 검증하는 인수 테스트를 먼저 만들고 기능구현을 해보세요.
- 지하철 노선 생성
- 지하철 노선 목록 조회
- 지하철 노선 조회
- 지하철 노선 수정
- 지하철 노선 삭제

https://github.com/next-step/atdd-subway-admin/pull/854

[김대겸] Step2 PR by Gyeom · Pull Request #854 · next-step/atdd-subway-admin

안녕하세요 리뷰어님, 2단계 - 지하철 노선 기능 PR 입니다. 이번에도 잘 부탁드립니다 :)

github.com

각 테스트 간에 격리를 위해 DatabaseCleanup 클래스를 활용했다.

평소에도 많이 고민을 했던 부분이지만 의존성 방향에 대해서는 생각하지 못했던 것 같다. 이 부분에 대해 짚어주셔서 관련 Case에 대한 컨벤션을 어떻게 잡아갈 지 방향성이 확고해졌다.

더티 체킹이 일어나면서 데이트 업데이트가 이뤄지지만 save 코드를 작성함으로써 명확하고 읽기 쉬운코드를 작성할 수 있다고 생각했는데, 불필요한 로직이 수행 될 수 있는 지에 대해 파악이 필요할 것 같다.

3단계 - 구간 추가 기능

기능 구현 전에 인수 조건을 만족하는지 검증하는 인수 테스트를 먼저 만들고 기능구현을 해보세요.
- 역 사이에 새로운 역을 등록할 경우
- 새로운 역을 상행 종점으로 등록할 경우
- 새로운 역을 하행 종점으로 등록할 경우
- 역 사이에 새로운 역을 등록할 경우 기존 역 사이 길이보다 크거나 같으면 등록을 할 수 없음
- 상행역과 하행역이 이미 노선에 모두 등록되어 있다면 추가할 수 없음
- 상행역과 하행역 둘 중 하나도 포함되어있지 않으면 추가할 수 없음

https://github.com/next-step/atdd-subway-admin/pull/881

[김대겸] Step3 PR by Gyeom · Pull Request #881 · next-step/atdd-subway-admin

안녕하세요 리뷰어님, 3단계 구간 추가 기능 PR 입니다. 이번에도 잘 부탁드립니다 :)

github.com

의존성이 양방향이라면 결국 하나의 서비스라는 것을 의미하기도 한다. 하지만, Line과 Section은 같은 서비스가 아니기 때문에 단방향을 향하도록 변경이 필요하다. 처음에는 의존성 개념에 대해 이해하기 어려웠지만, 미션을 수행하면서 리뷰어님이 지속적으로 피드백을 제공해주고 코드를 작성하면서 비슷한 상황을 반복해서 접하다보니 자연스럽게 이해할 수 있었다.
의존성 방향은 단방향을 향해야 한다.

getter 사용을 지양하자. getter를 사용하기 전에 다른 클래스를 통해 책임을 위임할 수는 없을 지에 대해 고민하자.

미션 회고

이번 미션을 진행하면서 인수 테스트 주도 개발 프로세스를 단계별로 경험할 수 있었고, 인수테스트의 동작들을 분리에 대한 좋은 인사이트를 얻을 수 있었다. 특히, 이번 미션을 진행하면서 의존성 개념에 대해 명확하게 이해할 수 있었다. 처음에는 의존성 개념이 어렵게 느껴졌는데, 리뷰어님의 피드백을 시작으로 조영호님의 우아한 객체지향 강의를 통해 의존성의 필요성에 대해 명확하게 이해할 수 있었다.