RSS Feed

Kafka Consumer 정리

Sat, 23 May 2026 00:00:00 GMT

컨슈머

컨슈머는 카프카 클러스터 내부 특정 토픽에 데이터가 유입되면, 이 토픽을 구독하며 데이터를 가져오게 되는 주체이다. 프로듀서가 전송한 데이터는 브로커에 적재되며, 컨슈머는 적재된 데이터를 사용하고자 브로커의 특정 토픽으로부터 데이터를 가져와서 내부적으로 필요한 처리를 수행한다.

컨슈머 내부 구조

패쳐(Fetcher) : 패쳐(Fetcher) 란 리더 파티션으로부터 레코드들을 미리 가져와서 대기시키는 역할을 한다. 카프카 클러스터에서, 즉 리더 파티션에 있는 브로커가 데이터를 컨슈머 애플리케이션에 보내게 되면, 가장 앞단에서 패쳐(Fetcher) 가 우선적으로 데이터를 전달받게 된다. 패쳐 내부적으로는 데이터를 충분히 전달받게 되면 completedFetches 상태로 변하게 되며, 이 상태일 때 poll() 메소드를 호출하게 되면 ConsumerRecords 라고 하는 객체로 변환하게 된다.
ConsumerRecords : 처리하고자 하는 레코드(ConsumerRecord)들의 한 묶음으로, ConsumerRecord 의 복수 형태이다.
poll() : 패쳐에 있는 레코드들을 리턴하는 메소드이다.

데이터 처리 속도

특징 중 하나로, 이 poll() 메소드를 호출하기 전에 이미 패쳐는 데이터를 브로커로부터 가져온다. 따라서, 우리가 poll() 메소드를 조금 늦게 호출하더라도, 즉 레코드의 처리 속도가 조금 늦더라도 처리 완료 못한 레코드가 쌓여있다는 점에 대해 걱정할 필요가 없다. 이미 패쳐에서 알아서 충분히 데이터를 가져왔고 대기 시켜놓고 쌓아놓았기 떄문에 천천히 데이터를 꺼내와서 처리해도 된다.

비슷한 원리로, 브로커의 리더 파티션으로 부터 패쳐가 데이터를 가져올 때도 배치로 데이터를 미리 다 가져오는 형태이기 때문에, poll() 을 간혈적으로 호출하며 데이터 처리 속도가 매우 빠른 상황이더라도 크게 걱정할 필요가 없다.

ConsumerRecord 의 offset 과 커밋

프로듀서에서 보낸 레코드는 브로커(파티션)에 저장될 때 오프셋(offset) 이 지정 된다고 했었다. 다시 표현하자면, 파티션에 쌓이는 레코드는 타임스탬프, 메시지 키, 메시지 값, 오프셋, 헤더 이렇게 5가지 정보를 가지고 있다.

여기서 오프셋은 0 이상의 숫자로 설정되어 있다. 오프셋은 직접 지정이 불가능하며, 브로커에 저장된 마지막 레코드의 오프셋 값에 +1 한 값으로 저장된다.

지정된 offset 값은 이 ConsumerRecord 에서 확인할 수 있게 되고, 해당 레코드에 대한 처리가 완료되었다면 커밋(Commit) 이라는 과정을 수행하게 된다. 커밋(Commit) 정확히 어떤(몇번 offset 을 가진) 레코드까지 처리를 완료했음을 표식하는 과정이다. 즉, 커밋을 통해 어떤 레코드까지(몇번 오프셋을 가진 레코드까지) 처리 완료했는지 판단하게 된다.

다시 말하자면, 커밋이 정상적으로 수행 및 완료되어야지 컨슈머가 레코드를 정상적으로 처리 완료했다는 것을 보장할 수 있게된다.

커밋(Commit)

컨슈머는 카프카 브로커로부터 레코드를 어디까지 가져갔는지 커밋(commit) 을 통해 기록한다. 즉, 컨슈머가 파티션으로 부터 레코드를 가져온 뒤 해당 데이터를 처리하고, 마지막으로 N번째 레코드까지 처리 완료 했음을 표식으로 남기는 과정이 커밋(commit) 이다. 커밋을 수행하면, 특정 토픽의 파티션을 어떤 컨슈머 그룹이 몇 번째(몇번 Offset) 까지 가져갔는지를 카프카 브로커 시스템에 내장된 __consumer_offsets 이라는 특별한 토픽에 기록한다.

어떠한 문제로 컨슈머에 장애가 발생하여 커밋에 재대로 수행되지 않은 경우, 컨슈머는 데이터를 중복 컨슘할 가능성도 있다. 따라서, 데이터 처리에 중복이 발생하지 않도록 만들기 위해선, 즉 컨슈머 애플리케이션 로직을 구성할 떄 특정 레코드를 처리 완료했다고 하는 커밋을 직접 수행하는 로직(commit() 이라는 메소드를 직접 수동으로 호출)을 구성해두어 명확히 커밋을 수행하도록 만드는 것이 좋다. 또는 오프셋 커밋이 제대로 수행되었는지 검증하는 로직을 만들어두자. (다만, 실제로는 Dead Letter 재처리등 동일한 내용의 데이터를 재처리 할 일은 많기 때문에, 컨슈머 로직을 멱등하게 구성하는 것이 마음 편할 것이다.)

비명시적 오프셋 커밋

enable.auto.commit 옵션의 기본값은 true 인데, 이 상태에서 컨슈머 애플리케이션은 비명시적 오프셋 커밋을 수행한다. 비명시적 오프셋 커밋은 poll() 메소드가 실행된 이후 일정 시간이 지나면 그 시점까지 읽은 오프셋을 커밋하는 방식이다. 이때 일정 시간은 auto.commit.internval.ms 옵션을 통해 설정한다. 이 방식은 poll() 호출 이후에 리밸런싱이 발생하거나, 컨슈머가 비정상적으로 종료되었을 때 메시지가 중복 처리가되거나 유실될 가능성이 있으므로, 이를 허용하지 않는 서비스에선 사용하면 안된다.

명시적 오프셋 커밋

명시적 방식을 사용하려면, enable.auto.commit 을 false 으로 설정하여 자동으로 커밋하지 않도록 하고, poll() 메소드 호출 이후에 commitSync() 메소드를 호출한다. commitSync() 메서드는 poll() 메서드를 통해 반환된 레코드의 가장 마지막 오프셋을 기준으로 커밋한다.

단, commitSync() 는 동기적으로 커밋하는 방식이라서 비명시적 방식에 비해 단위 시간당 처리량이 낮다. 처리량을 높이고 싶으면, 비동기적으로 커밋을 하는 commitAsync() 메서드를 사용하면 된다. commitAsync() 를 사용하면 커밋 요청 후 응답이 올 때 까지 데이터를 처리할 수 있다. 다만, 커밋이 실패한 경우 순서 보장이 불가능하며, 중복 처리가 될 수도 있다. 또 commitSync() 는 실패시 성공하거나 재시도할 수 없는 오류가 발생할 때 까지 재시도하지만, commitAsync() 는 그렇지 않다.

초기 오프셋 전략

컨슈머 그룹이 파티션의 레코드를 읽으려고 하는데, 오프셋이 지정되어 있지 않다면 어떻게 처리할까? auto.offset.reset 옵션을 통해 latest , earliest , none 중 하나를 선택할 수 있다.

latest : 가장 최근의 (오프셋이 가장 높은) 레코드부터 처리한다. 이 옵션이 기본값이다.
earliest : 가장 오래된 (오프셋이 가장 낮은) 레코드부터 처리한다.
none : 커밋 기록이 없다면 오류를 반환하고, 커밋 기록이 있다면 마지막 커밋 이후 오프셋부터 읽기 시작한다.

컨슈머 그룹

컨슈머 그룹은 어떤 특정 토픽의 데이터를 처리하는 컨슈머들을 묶은 그룹이다. 즉, 컨슈머 그룹에 묶인 컨슈머들은 동일한 토픽을 구독하고 처리한다. 동일한 컨슈머 그룹을 가진 컨슈머들은 기본적으로는 다 동일한 내부 로직을 가지고 있는 컨슈머이다.

특정 하나의 토픽에 대해선 2개 이상의 여러 컨슈머 그룹에서 동일한 토픽을 구독할 수 있다. 또한, 동일한 토픽을 구독중인 컨슈머 그룹은 다른 컨슈머 그룹과 서로 영향을 주고 받지 않는다. 이전에 학습했기를, 파티션에 있는 데이터를 컨슈머가 가져간다고 해서 파티션에 쌓인 데이터가 사라지지는 않는다고 했었다. 이 원리에 따라서, 여러개의 컨슈머 그룹에서 특정 동일한 토픽을 구독하고 하는 상황이고, 이때 컨슈머 그룹 중 하나가 파티션에서 레코드를 가져간다고 한들 파티션에서 레코드가 사라지지 않기 때문에 다른 컨슈머 그룹에서도 해당 파티션에 있는 동일한 레코드를 가져갈 수 있게 되는 것이다.

카프카가 아닌 일반적인 메시지 브로커는 메시지를 컨슈머에 푸시(push) 하는 방식으로 동작하는데, 이 방식의 단점은 컨슈머가 자기 자신의 가용량을 엄두할 수 없다는 점이다. 반면, 카프카의 컨슈머는 다른 메시지 브로커와 다르게, 직접 레코드를 풀링(Polling) 하여 읽어오는 방식으로 동작한다. 따라서 컨슈머 각자의 가용량에 따라 유연하게 메시지를 처리할 수 있다. 컨슈머 애플리케이션이 풀링하기 위해선 poll() 메소드를 실행한다.

컨슈머 개수와 파티션 개수 비율

컨슈머 그룹으로 묶인 컨슈머들은 구독하고 있는 특정 토픽 안의 여러개의 파티션들에 동시에 할당되어 데이터를 가져갈 수 있다. 반면 1개의 파티션은 최대 1개의 컨슈머에게만 할당될 수 있다. 이러한 특징에 따라, 컨슈머 그룹의 컨슈머 개수는 구독중인 토픽안의 파티션 개수보다 같거나 작게 만드는 것이 좋다. 가급적이면, 컨슈머와 파티션 개수가 1:1 로 매칭되도록 개수를 동일하게 맞춰주는 것이 베스트이다.

컨슈머 그룹의 컨슈머 개수가 파티션 개수보다 많을 경우

컨슈머가 4개, 파티션이 3개로 컨슈머가 더 많은 상황을 가정해보자. 파티션은 최대 1개의 컨슈머에게만 할당될 수 있다고 했었기 때문에, 파티션 3개에 컨슈머 3개가 1:1 으로 할당되고, 나머지 1개의 여분 컨슈머는 유휴 상태(idle) 가 된다.

이러한 특징으로 보아, 계속 강조하였듯이 파티션 개수만큼만 컨슈머를 딱 맞추어 운영하는 것이 좋다. (정 필요하다면, 컨슈머 개수를 파티션 개수보다 더 늘려서 운영하는 것이 좋다.)

컨슈머 그룹을 활용하는 이유

컨슈머 그룹은 왜 등장하였으며, 언제 어떻게 활용하는 것일까? 이를 위해, 컨슈머 그룹이 없는 상황을 가정해보자. 운영 서버의 주요 리소스인 CPU, 메모리 정보를 수집하는 데이터 파이프라인을 구축한다고 가정해보자. 실시간 리소스를 시간 순으로 확인하기 위해서 데이터를 Elastic Search 에 저장하고, 이와 동시에 대용량 적재를 위해 하둡에 적재할 것이다.

만약 카프카를 활용한 파이프라인이 아니라면, 서버에서 실행되는 리소스 수집 및 전송 에이전트는 수집한 리소스를 엘라스틱 서치와 하둡에 적재하기 위해 동기적으로 적재를 요청 할 것이다. 이렇게 동기로 실행되는 에이전트는 엘라스틱 서치 또는 하둡 둘 중 하나에 장애가 발생한다면 더 이상은 적재가 불가능할 수 있다.

이런 상황은 어떻게 해결할 수 있을까? 바로 카프카 토픽과 컨슈머 그룹으로 데이터를 나누는 것이다. 리소스를 수집하는 특정 에이전트(애플리케이션) 가 프로듀서(Producer) 역할을 하도록 만들고, 엘라스틱서치와 하둡 각각에 대해 컨슈머 그룹을 생성해두는 것이다. 프로듀서에선 데이터를 일단 카프카에 보내고, 카프카내 저장된 데이터를 서로 다른 목적을 가진 컨슈머 그룹들(엘라스틱 서치 적재 / 하둡 적재 컨슈머 그룹) 이 각각 데이터를 가져가도록 한다. 이렇게 구성하면 만약 장애가 터져도 문제가 없다. 가령 엘라스틱 서치에 장애가 텨져도 데이터를 조금 늦게 쌓고, FailOver 한 뒤에 마지막으로 적재된 예전 데이터부터 다시 천천히 적재를 수행하고 시계열화하면 되는 것이다.

그리고 이렇게 목적에 따른 컨슈머 그룹을 따로 구분해 운영하면 또 다른 이점이 생긴다. 위 예시처럼 컨슈머 애플리케이션 특성에 따라 컨슈머 개수를 조절하여 처리량을 각기 다르게 조절할 수 있다는 점이다. 위의 경우 엘라스틱 서치에 데이터 적재시 처리량이 낮아도 되기 때문에 컨슈머를 1개만 운영하였고, 반면 하둡 적재시에는 처리량이 높아야해서 컨슈머를 3개로 여러개 운영하고 있다.

Thread-Safe 를 보장할 것

Thread-Safe 측면에서 주의할 점은, 동일한 컨슈머 그룹이라면 하나의 쓰레드에서 여러개의 컨슈머를 실행해서는 안된다는 점이다. 한 애플리케이션에서 동일한 컨슈머 그룹의 여러 컨슈머를 실행하려면, 별도의 쓰레드에서 실행해야한다.

리밸런싱(rebalancing)

카프카 컨슈머는 리밸런싱이라는 FailOver 방식이 있다. 컨슈머 그룹에 속한 컨슈머 중에 특정 컨슈머에 장애가 터지면, 해당 컨슈머는 일시적으로 컨슈머 그룹에서 내쫓기며 파티션으로부터 유입되는 데이터를 처리하지 않고 유휴(idle) 상태로 넘어간 뒤에 회복이 완료되면 다시 컨슈머 그룹에 참여하여 파티션의 데이터를 처리하게 된다. (이때, 내쫓긴 컨슈머에 매핑되어 있던 파티션은 새로운 컨슈머에 임시적으로 매핑될 것이다.) 이렇게 컨슈머 그룹이 FailOver 하는 과정을 리밸런싱(rebalancing) 이라고 한다.

리밸런스 리스너(rebalance listener)

이런 리밸런싱은 컨슈머가 데이터를 처리하는 도중에 언제든지 발생할 수 있다. 따라서 이 리밸런싱 발생시 어떻게 내부적으로 동작할 것인지에 대한, 즉 리밸런싱에 대한 로직을 추가로 메소드로 구현할 수 있다. 이를 리밸런스 리스너(rebalance listener) 라고 한다.

파티션 개수와 리밸런싱 소요시간

파티션 개수가 많아질수록, 그만큼 리밸런싱의 소요 시간은 길어진다. 가령 토픽에 파티션이 1천개 있고, 컨슈머 그룹에도 동일하게 컨슈머가 1천개 있는 상황을 가정해보자. 컨슈머 1개에 장애가 터지면, 토픽에 있는 파티션 1천개는 컨슈머 999개와 새롭게 매핑 관계를 성립해야하는 내부적인 리밸런싱 과정을 거치게 된다.

따라서, 리밸런싱이 일어나는 상황 자체가 사실상 장애와 비슷한 상황이라고도 볼 수 있다. 따라서 리밸런싱이 자주 발생하지 않도록 운영하는 것이 가장 바람직하지만, 만에 하나 발생할 수도 있는 리밸런싱을 대비하여, 그에 대응하는 로직을 리밸런스 리스너(rebalance listener) 를 통해 미리 구성해두는 것이 좋다.

Assginor

Assginor 는 컨슈머와 파티션을 어떻게 매핑할지에 대한 정책을 담고있는 주체이다. 카프카에선 RangeAssignor, RoundRobinAssignor, StickyAssignor 3가지를 제공하며, 카프카 2.5.0 기준으로는 RangeAssignor 가 디폴트 어사이너로 설정되어 있다.

RangeAssignor : 각 토픽에서 파티션을 숫자로 정렬, 컨슈머를 사전 순서로 정렬하여 할당하는 방식
RoundRobinAssignor : 모든 파티션을 컨슈머에서 번갈아가면서 할당하는 방식
StickyAssignor : 최대한 파티션을 균등하게 배분하면서 할당하는 방식

컨슈머 랙

컨슈머는 본인의 상황 또는 처리 성능에 따라서 파티션에 쌓인 레코드를 가져와 빠르게 처리 못하는 상황이 발생할 수 있다. 이렇게 컨슈머가 파티션에 쌓인 레코드를 처리 못하고 지연이 발생하여 데이터가 쌓인 상황을 "컨슈머 랙이 쌓였다(발생했다)" 라고 표현한다.

컨슈머 랙이 많이 쌓였다는 것은, 그만큼 컨슈머가 프로듀서에 비해 처리량이 낮거나 또는 정상 동작하지 않는 상황임으로 알 수 있다. 따라서, 서비스를 운영할 떄 컨슈머 랙이 쌓여있는지 모니터링 시스템을 구축해두는 것이 좋다. 이어서, 파티션 개수와 컨슈머 개수를 늘려서 처리량을 늘리는 방법으로 쌓여있는 랙을 해결하는 것이 바람직할 것이다.

참고

아파치 카프카 애플리케이션 프로그래밍 - 최원영
https://kafka.apache.org/documentation/
https://hudi.blog/kafka-consumer/

Kafka Producer 정리

Fri, 15 May 2026 00:00:00 GMT

프로듀서

카프카에서 데이터의 시작점은 프로듀서이다. 프로듀서 애플리케이션은 카프카에 필요한 데이터를 선언하고, 브로커의 특정 토픽 안의 파티션에다 데이터를 전송한다. 프로듀서는 데이터를 전송할 때 리더 파티션을 가지고 있는 카프카 브로커와 직접 통신한다.

이때, 프로듀서와 컨슈머 모두 이 카프카 클러스터에 있는 토픽에 접근할 때는 반드시 리더 파티션이 있는 브로커와 통신한다. 이전에 학습했기를, 리더 파티션은 프로듀서가 보낸 데이터를 저장하는 역할을 수행하며, 팔로워 파티션은 리더에 있는 데이터를 실시간으로 복제(Replication) 하며, 장애 발생시 FailOver 하는 역할을 한다고 했었다. 즉, 프로듀서는 실질적으로 통신을 하는 브로커가 위치한 리더 파티션과 통신을 하게 된다.
프로듀서는 내부적으로 카프카 브로커와 통신할 때, 내부적으로 파티셔너(Partitioner), 배치 생성 단계를 거치게 된다.

프로듀서 내부 구조

프로듀서 내부는 다음과 같은 컴포넌트들로 구성된다.

ProducerRecord : 프로듀서가 전송하는 레코드 타입이다. 다시 말해, 이 클래스를 통해 선언된 레코드 객체를 프로듀서가 프로듀싱 할 수 있다. 내부적으로는 토픽(topic), 파티션(partition), 타임스탬프(timestamp), 메시지 키(message key), 메시지 값(message value) 으로 구성 및 정의할 수 있다. 단, 오프셋은 별도로 존재(지정)하지 않는다. 오프셋은 카프카의 특정 파티션에 데이터가 저장된 이후에 지정된다. 그리고 기본적으로는, 프로듀서에서 레코드에 토픽과 메시지 값만 지정되어 있더라도 레코드를 전송할 수 있다. (나머지는 모두 Optional 하다.)
send() : 레코드를 전송 요청하는 메소드이다. 즉, Producer Record 는 send() 메소드를 호출하여 전송할 수 있다. 이때 유의할 점은, 레코드를 send 를 호출하는 그 즉시 전송하는 것이 아니라, 내부적인 과정을 일부 거친 뒤 전송하게 된다.
파티셔너(Partitioner) : 파티셔너는 어느 파티션으로 레코드를 전송할지 지정해주는 라우팅 역할을 담당한다. (마치 로드밸런서의 역할이다.) 레코드의 메시지 키(message key) 를 해싱하여 도출된 해시 결과값을 기반으로 몇번 파티션에 전송할지를 내부적으로 결정해준다. 동일한 메시지 키를 가진 레코드는 항상 동일한 파티션으로 전송되는 특징이 있다.
Accumulator : 파티셔너에 의해 어떤 파티션으로 전송될지 결정된다면, Accumulator 에서는 배치라는 단위로 레코드 여러개를 한 뭉텅이(배치)로 묶는 작업을 한다. 배치로 왜 묶는가라고 하면, 매번 모든 레코드 각각에 대해 send() 를 호출할 때 마다 레코드를 전송하게 되면 네트워크상의 병목과 리소스 낭비가 심해질 것이다. 따라서, 레코드 여러개를 배치로 묶고 전송하게 된다. 즉, Accumulator 를 활용하면 레코드가 많응 경우 최대한 레코드 여러개를 배치로 묶어서 전송하면 높은 데이터 처리량을 가질 수 있게된다. 다시 정리하자면, Accumulator 에 의해 배치라는 단위로 묶여진 레코드 뭉텅이가 일정량 쌓이고 나면, Sender 배치를 브로커와 통신해서 전송하게 된다.

파티셔너

프로듀서 API 를 사용하게 되면 2가지의 파티셔너를 제공받게 된다. 바로 UniformStickyPartitioner 와 RoundRobinPartitioner 이다. 이 중에 디폴트 파티셔너는 UniformStickyPartitioner 으로 설정되어 있다. 이 두 가지 파티셔너들은 각각 어떻게 동작할까? 이 파티셔너들은 레코드에 메시지 키가 있을 때와, 반대로 메시지 키가 없을 때 동작 방식이 조금씩 다른데, 한번 살펴보자.

메시지 키가 있을 경우 동작

메시지 키가 있을 경우, UniformStickyPartitioner 와 RoundRobinPartitioner 모두 메시지 키를 해싱한 결과 값을 특정 파티션에 매핑하고, 해당 파티션에다 레코드를 전송한다. 즉, 동일한 메시지 키를 갖는 레코드는 항상 동일한 파티션(파티션 번호) 에 전송된다.

단, 파티션 개수가 도중에 갑자기 변경될 경우, 기존에 매핑되었던 메시지 키와 파티션 번호간의 매핑 관계는 깨지게 된다. 즉, 파티션 개수가 변경되면 기존 레코드는 새롭게 해싱된 결과값을 기반으로 또 다른 파티션에 새롭게 매핑된다. (몰론 해시 결과값이 이전과 동일한 상황이라면, 해당 레코드는 동일한 파티션에 다시 매핑되는 케이스도 존재할 수 있다.)

따라서, 만약 메시지 키를 활용해야 하는 상황이라면, 파티션 개수를 충분히 많은 개수로 지정하는 것이 좋다. 프로듀서가 보내는 데이터량, 컨슈머가 처리하는 데이터량을 고민을 해서 파티션 개수를 충분히 크게 지정하자. 왜냐하면, 파티션 개수에 따라서 컨슈머의 처리량이 달라지기 때문이다. (파티션 개수만큼 컨슈머 개수를 늘려서 데이터를 처리하기 때문이다.) 따라서, 파티션 개수를 변경하는 일이 발생하지 않도록 만들기 위해선 파티션 개수를 충분히 큰 개수로 지정하고 운영하면 된다.

예를들어 컨슈머가 초당 10개의 데이터를 처리하고, 프로듀서는 100개씩 처리(전송)하는 경우라면, 컨슈머를 10개씩 띄우면 되겠구나라는걸 알고 10개의 파티션을 생성하면 될 것이다. 그런데 문제는, 프로듀서가 보내는 데이터량이 언제든 더 많아질 수도 있을 것이다. 따라서 파티션 개수를 10개보다도 더 많이 미리 널널하게 늘려 놓고 운영하면 좋을 것이다.

메시지 키가 없을 경우 동작

반대로 메시지 키가 없을 경우는 앞서 살펴본 두 파티셔너의 동작 방식이 비슷하면서도 조금 다르다.

공통점 : 파티션에 라운드 로빈(Round Robin) 방식으로 데이터를 최대한 골구로 동일하게 분배시킨다.
차이점 : 파티셔너가 레코드를 전송하는 묶음 단위가 다르다. RoundRobinPartitioner 는 레코드를 단일(1개) 단위로 전송하며, UniformStickyPartitioner 는 레코드를 배치 단위로 묶어서 전송한다.
- RoundRobinPartitioner : 단일(1개) 레코드(ProducerRecord) 가 유입되는대로 그 즉시 각 파티션에 라운드 로빈 방식으로 레코드를 전송한다. Accumulator 에서 묶이는 데이터 단위 정도가 적기 때문에 처리량(성능)이 낮다.
- UniformStickyPartitioner : Accumulator 에서 레코드 여러개가 배치로 묶일 때 까지 대기했다가 라운드 로빈 방식으로 레코드를 전송한다. 배치 단위로 데이터를 전송하기 때문에 비교적 처리량이 뛰어나다.

UniformStickyPartitioner 는 그 특성상 RoundRobinPartitioner 에 비해 성능이 뛰어나다. 이 덕분에 UniformStickyPartitioner 는 현재 디폴트 파티셔너로 지정되어 있다.

커스텀 파티셔너

앞선 파티셔너 외의 파티셔너를 직접 구현하고 싶다면 Partitioner 인터페이스를 구현하면 된다. Partitioner 인터페이스 구현체 내부적으로 메시지 키 또는 메시지 값에 따라 매핑되는 파티션 로직을 구현해볼 수 있다.

프로듀서 API 코드 구현하기

카프카 프로듀서 API 코드는 어떻게 구현하는지 기본적인 스펙만 간단하게 알아보자.

카프카 설정

Properties configs = new Properties();
configs.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "kafka-test:9092"); // (1)
configs.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName()); // (2)
configs.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName()); // (3)

(1) 에서는 Bootstrap 서버를 지정하였으며, (2) 와 (3) 에서는 메시지 키와 값에 대한 직렬화 옵션을 지정하였다. 여기서는 StringSerializer 으로 직렬화 옵션을 지정하였다.

KafkaProducer Template

KafkaProducer<String, String> producer = new KakfaProducer<>(configs);

카프카 프로듀서 인스턴스를 정의해주었다. 카프카 프로듀서 인스턴스를 만들 때는, 앞서 정의한 직렬화 옵션(StringSerializer)에 알맞게 템플릿 형태(<String, String>)를 지정해줘야 한다. 또한 앞서 생성한 카프카 Properties 를 파라미터로 지정해준다.

위와 같이 프로듀서 인스턴스를 정의하면, "kafka-test:9092" 에 있는 카프카 클러스터와 연동함년서 메시지 키와 값을 String 으로 직렬화하는 프로듀서 인스턴스가 되는 것이다.

ProducerRecord

ProducerRecord 기본 선언

String messageValue = "test-messagge-value";
ProducerRecord<String, String> record = new ProducerRecord<>(TOPIC_NAME, messageValue); 
produdcer.send(record);

앞서 정의한 KafkaProducer 인스턴스의 send() 메소드를 호출하여 ProducerRecord 를 전송할 수 있다. ProducerRecord 는 토픽 이름과 메시지 값을 필수로 지정해야한다. 앞서 학습했듯이, ProducerRecord 는 Offset 이 없는 형태이며, 나중에 이 레코드가 브로커에 저장될 때, 즉 리더 파티션에 저장될 때 Offset 이 할당된다.

또한, 앞서 살펴봤듯이 send() 를 호출한다고 해서 레코드가 바로 전송되지 않는다. Accumulator 가 배치로 레코드 여러개를 최대한 모은 뒤에 전송하게 된다.

파라미터 개수에 따른 ProducerRecord 선언 여러가지 방법

ProducerRecord<String, String> record1 = new ProducerRecord<>(TOPIC_NAME, "message key1", "message value1"); // (1)
ProducerRecord<String, String> record2 = new ProducerRecord<>(TOPIC_NAME, 3, "message key1", "message value1"); // (2)

(1) 메시지 키를 가진 ProducerRecord 선언 : 파타미터 3개를 넣으면 순서대로 토픽, 메시지 키, 메시지 값을 지정하게 되는 것이 된다.
(2) 파티션 번호를 지정한 ProducerRecord 선언 : 파라미터 4개를 넣으면 순서대로 토픽, 파티션 번호, 메시지 키, 메시지 값을 지정하게 되는 것이 된다.

CustomPartitioner 구현하기

public class CustomPartitioner implements Partitioner {
  
  @Override
  public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {

    if(keyBytes == null) {
      throw new InvalidRecordException("Need message key");
    }

    if(((String)key).equals("key1")) {
      return 3;
    }

    List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
    int numPartitions = partitions.size();
    
    return Utils.toPostitive(Utils.murmur2(keyByte)) % numPartitions;
  }
}

위처럼 Partition 인터페이스를 구현한 커스텀 파티셔너 구현체를 정의할 수 있다. 위 파티셔너의 경우 "key1" 이라는 메시지 레코드 키를 전달받은 경우 3번 파티션으로 전송되도록 구현하였다. 반면 이 외의 레코드에 대해선, 다시 해시값으로 변환해서 데이터가 전송되도록 하였다.

참고

아파치 카프카 애플리케이션 프로그래밍 - 최원영
https://kafka.apache.org/documentation/

Circuit Breaker 패턴을 활용한 MSA 환경내 장애 차단

Wed, 18 Mar 2026 00:00:00 GMT

서킷 브레이커 패턴의 등장 및 개념

MSA 환경에서 개발을 하다보면, 다른 서비스 컴포넌트에서 제공하는 외부 API 를 호출해야 하는 경우가 흔하다. 특히나 전체적인 시스템 구성이 MSA 로 되어 있다면, 다른 서비스를 호출하는 경우가 매우 빈번하다. 문제는 서버들이 장애가 발생할 수 있다는 점인데, 호출한 다른 서비스에 장애가 발생했다면 장애가 전파되어, 현재 외부 API 를 호출하는 본 서비스에까지 장애가 전파될 수 있다.

특히나 MSA 환경은 클라이언트의 요청이 수 많은 서비스를 거쳐서 응답이 이루어질 수 있다는 점이다. 서비스 A 로 부터 시작된 장애가 서비스 B, C, D, E, ... 로 계속 전파되어 영향을 미칠 수 있다는 점이다. 또한, 장애가 시작될 경우 장애가 어떤 서비스에서부터 시작된 것인지 그 장애 시작점을 파악하기는 쉽지 않다. 따라서, MSA 환경내 각 서비스는 스스로 다른 컴포넌트의 장애가 발생했을 경우를 대비한 장애 우회 정책, 장애 격리 및 FailOver 등을 할 수 있어야 한다.

따라서 장애가 발생한 서비스를 탐지하고, 요청을 재전송하지 않고 장애를 다른 방법으로 우회하도록 차단할 필요가 있다.

서킷 브레이커 패턴

위 문제처럼, MSA 환경내 각 서비스간에 장애 전파를 차단하기 위해 등장한 디자인패턴이 빠로 서킷 브레이커 패턴(Circuit Breaker Pattern) 이다. 서킷 브레이커 패턴은 이름과 같이 과부하가 걸린 전기를 자동으로 차단해서, 전기 사고를 방지하는 회로 차단기와 비슷하게 동작한다.

서킷 브레이커는 다른 서비스에 대한 호출을 모니터링하며, 요청의 실패율이 일정 임계치(Threshold) 를 넘어가면, 장애가 발생한 서비스로의 요청을 차단하여 장애 전파를 막는 방식이다. 만약 서킷 브레이커가 열렸다면, 서비스에 요청하는 대신에 Fallback 을 하게된다.

서킷 브레이커는 위와 같이 크게 3가지 타입의 상태값(State Value) 를 가진다. Closed, Open, Half Open 이 3가지 타입이 존재하는데, 각 상태를 정리하면 다음과 같다.

Closed : 요청 실패율이 정해놓은 임계치보다 낮은 상태로, 평소대로 모든 요청이 처리된다.
Open : 요청 실패율이 정해놓은 임계치보다 높아진 상태로, 서킷 브레이커가 열린 경우, 요청을 보내지 않고 즉시 실패 처리한다.
Half Open : Open 이후 일정 시간이 지나면 Half Open 된다. 이 상태에서 요청이 성공하면 Closed 상태로 변경되고, 실패하면 Open 상태를 유지한다.

서킷 브레이커가 동작하는 상황 예시를 들자면 다음과 같다.

(1) 일반적으로 외부 서버는 정상 실행중이므로, 서킷에 닫혀있고 요청이 정상적으로 전달된다.
(2) 이때, 외부 서버에 장애가 발생했다고 해보자.
(3) 이후의 요청들은 장애가 발생한 외부 서버가 더 이상 전달되지 않고 차단되며, 빠르게 에러 실패 또는 에러를 응답을 반환한다.
(4) 이후의 요청들은 외부 서버가 정상적으로 복구된다.
(5) 이후의 외부 서버가 정상적으로 북구된다.
(6) 회로가 Open 상태가 된지 특정 시간이 지나고, Half Open 상태로 변경된다.
(7) 일부 요청들이 외부 서버로 전달되고, 응답에 성공하여 Closed 상태가 된다.
(8) 모든 요청들이 정상적으로 복구된다.

Open 상태가 되면 특정 시간이 지나야 Half Open 상태가 된다. 만약 Half Open 상태가 되었는데 외부 서버가 복구되지 않았다면, 요청들은 실패해서 다시 Open 상태로 변경될 수도 있다. 여기서 중요한 것은 이러한 상태 변경이 자동으로 수행된다는 것이며, 상태 전이를 위한 시간들은 시스템 내부에서 관리되므로, 대부분 타임아웃과 관련된 모니터링 시스템을 제공해준다.

서킷 브레이커 패턴의 장점과 필요성

서킷 브레이커 패턴을 도입하였을 때 얻는 장점은 다음과 같이 정리해 볼 수 있다.

장애 감지 및 격리

만지 장애가 발생한 서비스를 호출한다면 요청이 타임아웃만큼 대기하게 되고, 쓰레드와 메모리 및 CPU 등의 자원을 점유하게 된다. 이것은 결국 시스템 리소스를 부족하게 만들어 장애를 유발할 수 있다. 장애가 발생한 것은 다른 서비스인데, 장애가 전파되는 것이다. 서킷 브레이커 패턴은 장애가 발생한 서비스를 탐지하고, 더 이상 요청을 보내지 않도록 차단함으로써 장애를 격리시켜준다. 그래서 장애가 발생한 기능 외의 다른 기능들은 동작하게 하여, 시스템의 안정성을 높일 수 있다.

자동 시스템 복구

서킷 브레이커는 요청이 차단되면, 해당 서비스가 주기적으로 검사한다. 그리고 해당 서비스가 복구되었다면 차단이 해제되고, 정상적으로 요청을 보내게 된다. 이러한 부분들은 시스템이 자동으로 해주므로, 개발자들이 신경쓰지 않아도 된다. 대부분 타임아웃 등을 위한 모니터링 기능까지 제공하여, 서킷 브레이커가 모든 연동이 적용되면 데시보드를 통해 전체 시스템들의 연동 현황까지 모니터링 가능하다.

빠른 실패 및 고객 응답

만약 다른 서비스가 문제있음을 알 수 있다면, 타임아웃 동안 자원을 낭비할 필요가 없다. 그래서 빠르게 장애를 탐지하는 것이 중요한데, 서킷브레이커 패턴을 적용하면 가능한 빠르게 실패를 반환하고, 고객에게 응답을 전달할 수 있다.

장애 서비스로의 부하 감소

외부 서비스가 완전히 죽지는 않았는데, Slow Query 등의 이유로 사용 가능한 쓰레드가 더 이상 남아있지 않을 수도 있다. 이때, 계속 요청을 보내는 것은 외부 서비스의 상황을 악화시켜서 장애를 유발할 수 있다. 그러므로 해당 서비스가 안정을 찾도록 멈추는 것이 좋은데, 서킷 브레이커를 사용하면 해당 서비스는 더 이상의 요청이 유입되지 않아서 장애를 복구할 수 있는 기회를 얻을 수 있다.

장애 대안 커스터마이징

외부 서비스에서 장애가 발생했다면, 원하는 데이터를 얻지 못할 수 있다. 이때, 아무런 대응책이 없다면 해당 서비스 역시 장애가 발생한다. 서킷 브레이커를 적용하면, 장애 대안을 커스터마이징 할 수 있는데, 예를들어 다른 소스로부터 값을 얻어오거나, 서킷 브레이커가 캐싱해 둔 값으로 응답하는 등 다양한 방법을 적용할 수 있다. 그러면 외부에 장애가 발생해도 문제없이 서비스를 운영할 수도 있다.

국내 대부분의 서비스들은 MVC 기반으로 되어있다. 스프링 MVC 는 멀티 쓰레드 기반으로 동작하므로, 장애가 있는 서비스를 호출하면 쓰레드를 점유에 의한 응답 지연이 발생하기 쉽다. 그래서 장애가 전파되기 쉬운데, 서킷 브레이커를 적용하면 빠르게 장애가 발생한 서버로의 요청을 차단하고 이를 해결할 수 있다.

Resilience4j 를 사용한 서킷 브레이커 구현

서킷 브레이커 패턴을 개발자가 직접 구현하는 방식보단, 기존에 잘 만들어진 라이브러리를 사용하는 방법이 더 좋다. Resilience4j 는 함수형 프로그래밍으로 설계된 경량(light weight) 장애 허용(fault tolerance) 라이브러리로, 서킷브레이커 패턴을 위해 사용된다. Resilience4j 를 활용한 간단한 서킷 브레이커 구현을 실습해보도록 한다.

💡 서킷 브레이커 실습 코드는, 참고1 을 보았을 때 아래 처럼 간단히 구현 가능한 방법도 있는 것으로 보이나, 외부 API 호출시 FeignClient 에 대한 서킷 브레이커 설정을 통해서도 외부 API 호출시 장애를 차단하는 방법이 있는 것으로 보인다. 이에 대한 실습 코드는 향후 잘 이해가 되었을 떄, 추가로 실습해보도록 한다.

gradle

dependencies {
	implementation("org.springframework.boot:spring-boot-starter")
	implementation("org.springframework.boot:spring-boot-starter-web")
	implementation("org.springframework.boot:spring-boot-starter-aop")
	implementation("io.github.resilience4j:resilience4j-spring-boot2")
}

의존성은 위와 같다. spring-boot-starter-app 의존성이 없으면, 뒤이어 사용할 @CircuitBreaker 어노테이션을 사용할 수 있으니 추가하도록 한다.

application.yml

resilience4j.circuitbreaker:
	configs:
		default:
			registerHealthIndicator: true
			slidingWindowSize: 10
			minimumNumberOfCalls: 5
			permittedNumberOfCallsInHalfOpenState: 3
			automaticTransitionFromOpenToHalfOpenEnabled: true
			waitDurationInOpenState: 5s
			failureRateThreshold: 50
			eventConsumerBufferSize: 10
	instances:
		orderService:
			baseConfig: default

resilience4j-spring-boot2 의존성을 사용하므로, 스프링부트 application.yaml 을 통해 선언적으로 서킷 브레이커에 대한 설정을 할 수 있다.

컨트롤러

@RestContoller
class OrderController {
	private val orderService: OrderService,
) }
	
	@GetMapping("/orders/{orderId}")
	fun getOrder(
		@PathVariable orderId: Long,
	): Order? {
		return orderService.getOrder(orderId);
	}
}

주문을 수행하는 컨트롤러다. 주문 API 요청시 고객 정보를 가져오기 위해 Service Layer 에서 UserClient API 를 호출하는 상황을 가정하도록 한다.

서비스내 서킷 브레이커 적용

@Service
class OrderService(
	private val userClient: UserClient,
) {
	
	@CircuitBreaker(name = "orderService", fallbackMethod = "fallback")
	fun getOrder(id: Long): Order? {
		val user = userClient.getUser(1)
		return Order(id = id, user = user)
	}
	
	private fun fallback(e: Exception): Order? {
		println("Circuit Breaker is opened : $e")
		return null
	}
}

서비스 코드에 서킷 브레이커를 적용했다. @CircuitBreaker 어노테이션을 붙이면 된다. name 파라미터는 서킷 브레이커 설정시 넣어둔 이름과 동일하다.

fallbackMethod 파라미터는 서킷이 열렸을 때 fallback 을 하기위해 실행할 메소드 이름을 입력한다. 단, 메소드 시그너치는 @CircuitBreaker 가 붙어있는 메소드와 메소드 시그너치가 동일해야하되, 추가로 Exception 파라미터를 받아야 한다. 다만, 위와 같이 원본 메소드의 파라미터를 생략하고 Exception 만 받아도 괜찮은 듯 하다.

참고 및 인용

카프카 컴포넌트 핵심 기능 및 역할 정리

Sat, 29 Nov 2025 00:00:00 GMT

카프카 아키텍처 복습

지난 포스팅 에서 다루었던 카프카 아키텍처의 컴포넌트들에 대해 다시금 복습을 짧게 해본 뒤, 본격적으로 이번 포스팅의 주제로 넘어가보고자 한다.

카프카 클러스터(kakfa cluster) : 하나 이상의 카프카 브로커들의 집합이다. 카프카는 확장성과 내결함성을 위해 브로커들을 클러스터로 구성한다.
브로커(broker) : 브로커는 개별 카프카 서버이다. 브로커는 프로듀서로부터 메시지를 전달받아서 토픽에 저장하고, 컨슈머에게 전달하는 역할을 한다. 브로커는 여러개의 토픽을 가질 수 있다.
토픽(topic) : 토픽은 데이터가 저장되는 단위라고 할 수 있다. 마치 데이터베이스에서 테이블(table) 과 거의 유사한 개념이다. 토픽은 이름으로 식별되며, 토픽에 한 번 추가된 데이터는 수정될 수 없다.
파티션(partition) : 카프카의 확장성을 위해서 토픽은 1개 이상의 여러 파티션으로 나뉠 수 있다. 레코드에 설정된 키(key) 가 없다면 라운드 로빈(round robin) 방식으로 파티션에 나뉘어 저장되고, 같은 키(key) 를 가진 레코드는 같은 파티션에 저장된다.
- 반대로, 레코드에 설정된 키(key) 값이 있다면, 해당 키 값을 해싱(hashing) 한 결과값을 기반으로 저장된다.
- 파티션의 내부 구조는 Queue 구조와 유사하게 이루어져 있다. 즉, FIFO 의 특징을 갖는다.
- 컨슈머는 파티션에 적재된 데이터를 가져가저라도, 파티션에 적재된 레코드가 삭제되지 않는다. 즉, 컨슈머는 파티션에서 이미 가져온 동일한 데이터를 또 다시 가져오는 행위가 가능하다. (몰론, 어떤 특정 컨슈머가 어떤 데이터까지 읽었는지는 내부적으로 기록하고 있다. 이렇게 어떤 레코드까지 읽었는지 기록하는 행위를 '커밋' 이라고 한다. 컨슈머는 레코드는 읽어온 뒤 커밋을 하고, 앞서 커밋한 내용을 기반으로 어디서부터 새로운 레코드를 읽어오면 되는지 정보를 읽어온다.)
오프셋(offset) : 파티션에 저장된 레코드는 증가하는 정수 ID 값을 갖고, 이 정수 ID 값을 오프셋이라고 부른다. 오프셋은 0부터 시작하며, 레코드가 파티션에 저장될 떄 마다 순차적으로 값이 증가한다. 특정 파티션의 각 레코드는 고유한 오프셋을 갖지만, 서로 다른 파티션 사이에는 고유하지 않다. 파티션에서 데이터를 읽을 때 작은 것 부터 큰 순서대로 읽는다.
레코드(record) : 파티션에 저장되는 데이터이다. Key, Value, TimeStamp, Compression Type, Optional Headers, Partition and Offset Id 로 구성된다.
프로듀서(producer) : 카프카에 요청을 날려서, 토픽에다 레코드를 추가하는 카프카 클라이언트이다. 카프카의 구성요소가 아니며, 카프카 외부에서 카프카에게 Request 를 전송하는 애플리케이션이다.
컨슈머(consumer) : 하나 이상의 파티션과 토픽으로부터 데이터를 읽어오는 카프카 클라이언트이다. 기본적으로 사용 가능한 가장 낮은 오프셋부터 높은 오프셋까지 순서대로 레코드를 읽어온다. 하나의 토픽 내부의 여러 파티션으로부터 레코드를 읽어올 때는 순서가 보장되지 않는다. 파티션 0, 1, 2 로 부터 레코드를 읽어올 때 파티션 0 의 레코드만 바라봤을 때는 순서가 보장되지만, 읽어온 전체 레코드를 바라봤을 때는 파티션 0 ~ 2 의 레코드가 순서와 상관없이 섞여있을 수 있다.
컨슈머 그룹(consumer group) : 동일한 컨슈머 인스턴스를 여러개 생성하여 컨슈머 그룹을 생성할 수 있다. 컨슈머 그룹을 구성하는 여러 컨슈머는 동일한 토픽의 각자 다른 파티션을 도맡아 메시지를 컨슘할 수 있다. 예를들어 토픽 A 에 파티션이 0, 1, 2 가 생성되어 있고, 컨슈머 그룹 A 에 컨슈머 a, b, c 가 있다고 가정하자. 이 경우 컨슈머 a 는 파티션 0 을, 컨슈머 b 는 파티션 1 을, 컨슈머 c 는 파티션 2 를 컨슘한다.

브로커(Broker)

1. 브로커란?

브로커는 개별 카프카 서버라고 설명했다. 브로커는 프로듀서로부터 메시지를 전달받아서 토픽에 저장하고, 컨슈머에게 전달하는 역할을 한다. 또한 브로커는 여러개의 토픽을 가질 수 있다.

브로커를 다시 표현하자면, 카프카 클라이언트(프로듀서, 컨슈머) 와 데이터를 주고받는 주체이다.
데이터를 분산 저장하여 장애가 터지더라도 안건하게 사용할 수 있도록 도와주는 개별 카프카 서버이다.
하나의 서버에는 한 개의 카프카 브로커 프로세스가 실행된다. 단, 카프카 브로커 서버 1대만으로도 기본 기능이 모두 제공되긴 하지만, 데이터를 안전하게 보관하고 처리하기 위한 가용성(availability) 를 보장하고자 브로커 서버를 여러개로 Scale Out 한다. 그리고 여러대의 브로커 서버를 하나의 카프카 클러스터 단위로 묶어서 운영한다.
카프카 클러스터로 묶인 브로커들은 프로듀서가 보낸 데이터를 안전하게 분산 저장하고, 복제(replication) 도 하며 고가용성(HA) 를 보장한다.

2. 브로커와 주키퍼(zookper)

여러대의 브로커 서버들을 하나의 카프카 클러스터 단위로 묶어서 서비스를 운영한다고 했다. 그런데 이떄, 카프카 클러스터를 실행하기 위해서는 주키퍼(zookper) 라는 컴포넌트가 카프카 클러스터에 필수로 연동되어 있어야 한다. 즉, 카프카 클러스터를 실행하기 위해선 주키퍼가 필요하다. (참고로, 카프카 Ver 3.0 부터는 주키퍼가 없어도 클러스러가 동작 가능해졌다.)

주키퍼 안에 znode 라는 단위를 생성하고, 각 znode 에다 카프카 클러스터를 매핑(연동) 해주는 과정이 필요하다. 즉, 주키퍼의 서로 다른 znode 각각에다 1:1 로 카프카 클러스터를 지정하면 된다.

3. 브로커의 세부 역할(기능)

3-1. 컨트롤러(Controller) 의 FailOver 기능

카프카 클러스터의 여러 브로커 중에 한 대가 컨트롤러(Controller) 라는 역할을 수행한다. 컨트롤러는 다른 브로커들의 상태를 주기적으로 체크(Health Check) 하며, 문제가 발생한 브로커를 클러스터에서 빠르게 내쫓는다. (카프카는 지속적으로 데이터를 처리해야 하므로, 브로커의 상태가 비정상적이라면 빠르게 클러스터에 내쫓는다.)

문제가 된 브로커를 내쫓는 즉시, 내쫓긴 해당 브로커에 존재했던 리더 파티션(leader partition)을 클러스터내 다른 브로커들에게 재분배한다. 반대로 만약 컨트롤러 역할을 하는 브로커 본인에게 장애가 생겼다면, 본인은 내쫓기고 다른 브로커가 컨트롤러 역할을 대체한다.

3-2. 비휘발성 특징을 갖는 레코드를 삭제 가능한 주체

카프카는 다른 메시징 시스템과 다르게 컨슈머가 래코드를 가져가더라도 토픽 안의 래코드는 삭제되지 않는다. 즉, 토픽내 파티션에 쌓인 래코드는 비휘발성 특징을 갖는다. 또한, 컨슈머나 프로듀서가 이러한 레코드에 대해 삭제를 요청할 수도 없다. 만약 비휘발성 특징을 갖는 레코드를 제거해버리고 싶더라도, 오직 브로커만이 레코드를 삭제할 수 있다.

카프카에서 데이터 삭제는 파일 단위로 수행되는데, 이 하나의 파일 단위를 로그 세그먼트(log segment) 라고 부른다. 이 세그먼트에는 다량의 데이터가 담겨있기 때문에, 일반적인 DB 처럼 특정 데이터를 선별해서 삭제할 수 없다.

다시 정리하자면, 카프카에서 데이터는 세그먼트 단위로 삭제가 발생하기 때문에 로그 단위(레코드 단위) 로 개별 삭제는 불가능하다. 또한, 로그(레코드) 의 메시지 키, 메시지 값, 오프셋, 헤더 등 이미 적재된 데이터에 대해서 수정 또한 불가능하기 떄문에 데이터를 적재할 때(프로듀서) 또는 데이터를 사용할 때(컨슈머) 데이터를 검증하는 것이 좋다.

3-3. 컨슈머를 위한 오프셋 커밋

컨슈머 그룹이 특정 토픽의 특정 파티션으로부터 레코드를 가져가서 처리한 뒤에, 해당 파티션의 어느 레코드까지 읽고 처리했는지 기록하고자 오프셋을 커밋(commit) 한다. 이렇게 오프셋을 커밋하는 주체가 바로 브로커이다.

커밋한 오프셋은 __consumer_offsets 이라는 토픽에 저장한다. 여기서 저장한 오프셋을 기반으로 컨슈머 그룹은 그 다음에 처리할 레코드 위치에 접근하여 레코드를 읽고 처리한다.

3-4. 코디네이터 역할 - 파티션 리밸런싱(rebalancing)

코디네이터(coordinator) 는 컨슈머 그룹내 각 컨슈머의 상태를 **체크(Health Check)**하고, 문제가 된 컨슈머를 내쫓은 뒤, 파티션을 다른 정상적인 컨슈머와 적절히 매핑되도록 재분배하는 역할을 한다. 이 코디네이터 역할을 브로커가 담당한다.

어떤 컨슈머가 문제가 터져서 컨슈머 그룹에서 내쫓기면, 매칭되지 않는 파티션을 정상 동작하는 다른 컨슈머로 재할당하여 흐름이 끊기지 않고 레코드가 처리되도록 돕는다. 이렇게 파티션을 컨슈머로 재할당하는 과정을 '리밸런싱(rebalancing)' 이라고 부른다.

4. 브로커의 데이터 저장 방식

4-1. 데이터 저장 디렉토리

카프카를 실행할 떄 config/server.properties 의 log.dir 옵션에 정의한 디렉토리에 데이터를 저장한다. 토픽 이름과 파티션 번호의 조합으로 하위 디렉토리를 생성하며, 그 디렉토리 안에 데이터를 저장한다. 예를들면, 아래처럼 토픽 이름(hello.kafka) + 파티션 번호(0번) 조합으로 디렉토리가 생성되었으며, 해당 디렉토리 안에는 내부적으로 데이터가 저장되어 있다.

$ ls /tmp/kafka-logs
hello.kafka-0

4-2. 각 디렉토리별 저장되는 파일 데이터 종류(로그와 세그먼트)

또한 아래 예시를 보면, hello.kafka 이라는 토픽의 0번 파티션에 존재하는 데이터들을 상세히 조회할 수 있다.

log 파일 : 메시지와 메타데이터를 저장한다.
index 파일 : 메시지의 오프셋을 인덱싱한 정보를 담은 파일이다.
timeindex 파일 : 메시지에 포함된 timestamp 값을 기준으로 인덱싱한 정보가 담겨 있다.

$ ls /tmp/kafka-logs/hello.kafka-0
00000000000000000000.index 00000000000000000000.log
00000000000000000000.timeindex leader-epoch-checkpoint

00000000000000000010.index 00000000000000000010.log
00000000000000000010.timeindex leader-epoch-checkpoint

00000000000000000020.index 00000000000000000020.log
00000000000000000020.timeindex leader-epoch-checkpoint

5. 브로커의 데이터 복제(Replication) 기능

데이터 복제(replication) 기능은 카프카를 장애 허용 시스템(Fault Tolerant System) 을 고려해, 가용성을 확보할 떄 좋은 기능이다. 카프카의 데이터 복제는 파티션 단위로 수행된다. 토픽을 생성할 때 파티션의 복제 개수(replication factor) 도 같이 설정되는데, 직접 옵션을 선택하지 않으면 브로커에 설정된 옵션 값을 따라간다. 복제 개수의 최솟값은 1(복제 없음) 이고, 최댓값은 브로커 개수만큼 설정하여 사용할 수 있다.

복제된 파티션은 리더(leader) 파티션 과 팔로워(follower) 파티션 2가지 타입으로 구분한다. 프로듀서 또는 컨슈머와 직접 통신하는 파티션을 리더 파티션, 나머지 복제 데이터를 가지고 있는 파티션을 팔로워 파티션라고 부른다.

팔로워 파티션 들은 리더 파티션의 오프셋을 확인하여, 현재 자신이 가지고 있는 오프셋과 차이가 나는 경우 리더 파티션으로 부터 데이터를 가져와서 자신의 파티션에 저장한다. (마치, MySQL 레플리케이션 GTID 방식과 비슷한 느낌이 든다. GTID 값을 기반으로 어디까지 복제를 진행했는지 식별하는데, 카프카 레플리케이션 기능도 비슷한 것 같다.)

복제 개수 설정 : 참고로, 데이터 종류마다 다른 복제 개수를 설정할 수 있다. 상황에 따라서는, 각 토픽마다 복제 개수를 다르게 설정하여 운영 가능하는 것도 가능하다.
브로커에 장애가 터졌을 때 FailOver : 브로커가 다운되면, 해당 브로커에 있는 리더 파티션은 사용 불가능하기 때문에 팔로워 파티션 중 하나가 리더 파티션으로 빠르게 승격한다.

토픽(Topic) 과 파티션(Partition)

토픽(Topic)

토픽은 데이터가 저장되는 단위로, 데이터를 타입별로 구분하기 위해 사용하는 단위이다. 앞서 설명했듯이, DB 에서 테이블과 유사한 개념이다. 또한 DB 테이블에서 각 테이블이 이름으로 식별되듯이, 각 토픽은 이름으로 식별되며, 한번 토픽에 추가된 데이터는 수정이 불가능하다고 했었다. 그리고 토픽은 1개 이상의 여러개의 파티션을 보유할 수 있다.

파티션(Partition)

파티션에는 프로듀서가 보낸 데이터인 '레코드(Record)' 가 적재된다.

특징

FIFO & 삭제되지 않는 레코드 : 파티션은 내부 구조가 Queue 와 유사하게 FIFO 특징인 자료구조로 구성되어 있다. 단, 일반적인 자료구조 Queue 와 다르게 카프카의 파티션은 컨슈머가 레코드를 가져간다고 해서 삭제되지 않고, 계속 남아 있는다. 즉, 파티션에 저장된 레코드는 컨슈머가 가져가는 것과 별개로 저장되고, 라이프사이클이 관리된다. 이런 특징 때문에 토픽 내의 레코드는 다양한 목적을 가진 여러 컨슈머 그룹들이 토픽의 데이터를 여러번 가져갈 수 있다.
- 앞서 설명했듯이, 파티션에 쌓인 레코드는 비휘발성 특징을 갖는다고 했었다. 오직 브로커만이 파티션내 레코드를 제거할 수 있다. 또한 브로커를 통해 레코드를 삭제할 때도, 삭제 단위가 세그먼트 단위로 발생하므로 개별 레코드 단위로 제거하는 것 또한 불가능하다고 했었다.
- 또한, 로그(레코드) 의 메시지 키, 메시지 값, 오프셋, 헤더 등 이미 적재된 데이터에 대해서 수정 또한 불가능하다고 했었다. 따라서 데이터를 적재할 때(프로듀서) 또는 데이터를 사용할 때(컨슈머) 데이터를 검증하는 것이 좋다.
프로듀싱한 레코드가 어느 파티션에 저장될지에 대한 기준 : 특정 토픽에 프로듀싱한 레코드는 여러 파티션 중에서 어떤 파티션에 저장될까? 만약 레코드 설정된 키(key) 가 특별히 없다면 라운드 로빈(round robin) 방식으로 파티션에 나뉘어 저장된다. 반대로 키(key) 가 있다면 해당 키 값을 해싱(hashing) 한 결과값을 기반으로 저장될 파티션을 결정하게 된다. 이때, 같은 키(key) 값을 가진 레코드는 같은 파티션에 저장된다.

신규 토픽 생성시 파티션이 내부적으로 배치되는 방식 및 기준

신규 토픽을 생성한다면, 해당 토픽에는 신규 파티션들이 함께 여럿 생성될 것 이다. 만약 신규 토픽에 파티션을 5개 생성했을 경우를 가정해본다면, 위처럼 0번 브로커부터 시작하여 라운드 로빈(round robin) 방식으로 리더 파티션(leader partition) 들이 생성된다. 즉, 파티션들은 0번 파티션부터 시작하여 라운드 로빈 방식으로 각 브로커에 생성된다.

라운드 로빈 방식으로 균등하게 생성됨으로써, 카프카 클라이언트는 여러 브로커에 골구로 균등하게 Request/Response 를 송.수신 할 수 있게된다. 이을 통해, 레코드가 특정 서버(브로커) 에 몰리는 현상(hot spot) 을 방지 할 수 있다.

💡 그럼에도 불구하고, 만약 특정 브로커에 파티션이 몰리는 상황이 발생한다면 kafka-reassign-partitions.sh 명령어를 통해 파티션을 재분배 하여 해결할 수 있다.

파티션 개수와 컨슈머 개수의 처리량

파티션은 카프카의 병렬 처리의 핵심 컴포넌트로써, 그룹(컨슈머 그룹)으로 묶인 컨슈머들이 레코드를 동시간대에 병렬로 처리할 수 있도록 돕는다. 컨슈머의 처리량은 한정되어 있기에, 만약 많은 레코드를 병렬로 더 빠르게 처리하고 싶다면 컨슈머의 개수를 늘리는 것이 좋다. 그와 동시에, 컨슈머 개수만큼 정비례하여 파티션 개수도 늘리주면 처리량이 증가할 것이다. 즉, 컨슈머와 파티션의 개수를 함께 Scale-Out 하여 레코드 처리 속도를 늘릴 수 있다.

파티션 개수를 줄이는 것은 불가능하다

단, 처리량 증가를 위해 파티션 개수를 늘릴 떄 한 가지 주의할 사항이 있다. 바로, 카프카에서 파티션 개수를 줄이는 기능은 지원하지 않는 점이다. 따라서 파티션을 늘리는 작업을 할 때는 그 개수를 다시 줄이는 작업이 불가능하므로 신중하게 파티션 개수를 정해야 한다.

만약, 파티션 개수를 꼭 줄이고 싶다면 토픽을 삭제해버리고 다시 재생성하여 파티션을 새롭게 생성하는 방법이 유일하다.

레코드(Record)

레코드는 타임스탬프, 헤더, 메시지 키, 메시지 값(value), 오프셋으로 구성되어 있다. 프로듀서가 생성한 레코드가 브로커로 전송되면 오프셋과 타임스탬프가 지정되어 저장된다. 브로커에 한번 적재된 레코드는 수정할 수 없고, 설정된 로그(레코드) 리텐션(retention) 기간 또는 용량 한도 설정 값에 따라서만 삭제된다.

💡 오직 브로커만이 레코드를 삭제할 수 있는 주체로 이해했는데, 여기서 언급된 'retention 기간 또는 용량 설정값에 의해서만 삭제된다' 라는 표현이 있다. 이 설정에 의해 삭제하도록 만드는 주체가 브로커인지, 아니면 별건인지 추가 서칭이 필요하다.

타임스탬프(timestamp) : 레코드의 타임스탬프는 스트림 프로세시에서 활용하기 위한 시간을 저장하는 용로도 사용된다. 별다른 설정이 없다면, 기본 값으로 ProducerRecord 생성 시각(CreateTime) 이 들어간다. 또는 이 필드에 브로커 적재 시간(LogAppenTime) 으로도 적재되도록 별도 설정할 수 있다. 이 옵션은 토픽 단위로 설정 가능하다.
오프셋(offset) : 레코드의 오프셋은 프로듀서가 생성한 레코드에는 존재하지 않는다. 프로듀서가 전송한 레코드가 브로커에 적재될 때 오프셋이 지정된다. 오프셋은 0부터 시작되며, 순차적으로 1씩 증가한다. 컨슈머는 오프셋을 기반으로 처리가 완료된 데이터와, 앞으로 처리해야 할 데이터를 구분한다. 각 메시지는 파티션 별로 고유한 오프셋을 가지므로, 컨슈머에서 중복 처리를 방지하기 위한 목적으로도 사용한다.
헤더(header) : 헤더에는 key-value 데이터를 추가할 수 있으며, 레코드의 스키마 버전이나 포맷과 같이 데이터 프로세싱에 간단히 참고할만한 정보를 담아서 사용할 수 있다.
메시지 키(message key) : 메시지 키는 처리하고자 하는 메시지 값을 분류하기 위한 용도로 사용하며, 이를 파티셔닝(partitioning) 이라고 한다. 파티셔닝에 사용하는 메시지 키는 파티셔너(partitionor) 에 따라 토픽의 파티션 번호가 정해진다. 메시지 키는 필수가 아니며, 지정하지 않으면 null 로 설정된다. 메시지 키가 null 인 레코드는 특정 토픽의 파티션에 라운드 로빈으로 전달된다. 반대로, null 이 아닌 메시지 키는 해싱(hashing) 한 결과값에 의해서 특정 파티션에 매핑디어 전달된다.
메시지 값(message value) : 레코드의 메시지 값은 실질적으로 처리할 데이터가 담기는 공간이다. 메시지 값의 포맷(타입)은 제네릭으로, 사용자에 의해 구체 타입이 지정된다. Byte[], Float, String 등 다양한 타입을 지정 가능하다. 브로커에 저장된 레코드의 메시지 값은 어떤 포맷으로 직렬화되어 저장되었는지 알 수 없기 때문에, 컨슈머는 미리 역직렬화 포맷을 알고 있어야 한다.

참고 및 인용

아파치 카프카 애플리케이션 프로그래밍 - 최원영
https://kafka.apache.org/documentation/

'일의 격' 책 인용 및 정리

Sun, 09 Nov 2025 00:00:00 GMT

회사를 다니다가, 지난번에 LINE+ 신규 입사자.임원간의 회식 자리를 가진 적이 있다. 조직장님을 통해 책 '일의 격' 을 추천받았는데, 나에게 큰 동기부여와 도움이 된 책인 것 같다. 주말이기도 하고, 서적을 읽으면서 마음이 들었던 부분 및 문구들을 인용하며 생각을 정리해보고자 한다.

아직 1장, 2장 외에 3장은 못 읽었지만, 그냥 읽는대로 편하게 블로그에 발행해보려고 한다. 완벽한 글을 올리고 싶은 마음이 아닌, 그냥 내 생각이 정리된 글을 편하게 올리고 싶은 것이 목적이니.

📚 1장. 성장 | 일의 성과를 극대화 하는 기술

성공의 가장 큰 적은 실패가 아닌 지루함

아마추어는 기분 좋을 떄만 훈련한다. 보통 선수는 매일 훈련하지만 지루할 떄면 대충 한다. 그러나 뛰어난 선수는 상관없이 훈련한다.
'신경 끄기의 기술' 이라는 책에서도 이런 내용이 있다. "목표는 멋지지만 목표로 가는 길에는 똥 덩어리가 가득하다. 지루한 길이다. 성공을 결정하는 질문은 '나는 무엇을 하고 싶은가?' 가 아니라, '그 과정에서 오는 고통을 견딜 수 있는가?' 이다. 특히 직장 생활을 시작한 초급 사원에게 제일 필요한 것은 허드엣일을 견디는 것이다"
나 자신을 돌이켜보고 내 주위를 봐도 이 지루함을 멈추는 그떄부터 그 사람은 더 이상 성장하지 않는다. 그것이 멈추어질 때 프로들은 현역에서 은퇴한다. 강수진은 그떄 떠나는 게 후배들, 관객들을 위한 예의이자 존중의 표시라고 했다.
그러면 이 지루함을 도대체 어떻게 이길까? 홀륭한 선수라고 열정이 무한대가 아니다. 그들도 열정이 식을 떄가 있다. 그러나 그들을 그 지루함을 지속할 동기를 스스로 찾는다고 한다. 동일한 일을 그대로 반복하는 것이 아니라 조금씩 목표를 올려 도전함으로써 즐거움을 만든다. 그리고 이 과정을 습관화하여 자동으로 행동하게 만든다고 한다.

그냥 찾아가라

어떤 운동을 배울 떄 나 혼자 연습을 열심해 해서 좀 괜찮아진 후 코치를 만나야겠다고 생각했다. 그리고 이것저것하고 시간을 끌었다. 한참 후에 코치를 만나니, 그동안 혼자 이것저것 했던 게 대부분 시간 낭비였음을 발견했다.
우리가 진단, 코칭, 피드백 또는 도움을 받는 이유는 무엇일까? 당연히 문제를 정확히 찾아 빠르게 해결하고 실력의 진보를 위한 것이다. 그런데 왜 미루는 것일까? 여러 이유가 있겠지만, 그 중 하나는 그것을 '평가' 로 여기기 때문이기도 하다. 학창 시절 끝없는 비교와 평가로 살아왔던 우리는 모든 것을 평가로 인식하는 경향이 있다. 또한 실제 진단을 평가로 쓰는 곳도 많다. 그러다 보니, 잘한 다음에 하려고, 또는 잘 보이고자 하는 마음에 자꾸 미룬다.
가장 효과적이며 효율적인 길은 가장 빠른 시간 내에, 그냥 있는 그대로 모습을 드러내어 피드백을 받거나 진단, 도움을 받는 것이다. 미루지 말고 그냥 헤라. 잘한 뒤에 상사나 멘토나 코티나 도움받을 사람을 찾아가는 것이 아니다. 잘하기 위해 찾아가는 것이다. 미리 잘 하려고 애쓰지 마라. 내가 좋은 평가를 받기 위해 고수를 찾아가는 것이 아니라, 도움받기 위해 찾아가는 것이다.

💡 나에게 지금 가장 필요한 조언이 아닐까? 나에게 완벽하는 것을 바라는게 아닐 것이다. 잘하기 위해서, 피드백과 도움을 받기 위해 선배들을 찾아가자.

연봉을 더 받으려면?

연봉이라는 것은 어떻게 산출될까? 경험상으로 대략 공식을 만들어 보면 '개인의 연봉 = f(자신이 만드는 가치, 희소성)' 이라고 할 수 있다. 여러가지 변수가 있겠지만 나는 이 두 가지 변수가 가장 크다는 생각이다.
'자신이 만드는(또는 기여하는) 가치' 란 자신이 일함으로써 회사가 얼마나 이익을 창출할 수 있는가이다. 이는 개인의 능력만으로 결정되는 것은 아니고, 회사의 수익 시스템과 결합되어 결정된다. 예를들어 한 회사가 한 사람을 뽑아 1억의 수익을 얻는다고 한다면 그 사람의 연봉은 1억 이상을 줄 수 없다. 그런데 실제로는 연봉 외에 그 사람을 위해 들어가는 간접비(사무실 임대료, 각종 비용 등) 가 50% 에서 100% 까지 더 들어간다. 만일 간접비가 100% 라면 그 사람에게 최대로 줄 수 이는 연봉은 5천만원 정도이다. 그러면 회사는 아무 이익을 남기지 않고 사업을 할 수 있나? 아니다. 그러므로 마진을 떄면 더 낮아진다.
연봉을 많이 받으려면, 아래 2가지 법칙을 준수하라.
- 법칙1. 가능한 자신을 통해 만들 수 있는 가치가 큰 기업으로 가야한다. 똑같은 능력의 사람으로 5천만원 바에 못 만드는 회사도 있고 10억을 만드는 회사도 있다. 당연히, 적은 가치를 만드는 회사가 높은 연봉을 줄 수 없다. 나랑 똑같은 학교, 학과를 졸업한 내 친구는 저 만큼 받는데 나는 이 모양이라고 불평한다면 답을 심플하다. '갈 수 있다면 그곳으로 가라' 단지, 기억할 것은 지금 큰 가치를 만드는 회사가 미래에도 계속 그러리라는 보장은 없다.
- 법칙2. 대체하기 어려운 희소성을 확보하는 것이다. 그런데, 이때 희소성은 '고정적' 이 아니다. 내가 작은 회사에 다닐 떄는 대체 가능한 사람이 주위에 없었지만, 큰 회사에 가니 대체 가능한 사람들이 주위에 많을 수 있다. 이 경우 오히려 작은 회사에 있는 것이 높은 연봉을 받을 수 있는 가능성이 더 높다. 그러므로, 무조건 큰 기업에 가는 것이 나은 선택이 아니다. 벤처에서 펄펄 날다가 대기업에 와서 그저 그렇게 지내고 연봉도 이후 거의 상승 안되는 직원들도 많이 봤다.
결론적으로, 두 가지 조합의 관점에서 생각해보면 4가지 경우로 나뉜다.
- (1) 생산가치도 높고, 나의 희소성도 높다 : 지금 있는 회사가 좋다. 여기에서 승부를 건다. 굳이, 욕심을 낸다면 동일한 희소성을 유지하면서 더 높은 생산가치를 낼 수 있는 곳으로 옮길 수 있지만, 기업문화 차이 등을 고려할 떄 위험하다.
- (2) 생산가치는 높은데 나의 희소성이 낮다 : 신의 직장이다. 최대한 지금 있는 회사에서 잘리리 않으려 노력한다. 공명심에 회사 그만두면 밖에서는 지옥을 경험할 것이다. 단, 희소성을 높이돌혹 자기계발을 해야 한다.
- (3) 생산가치가 낮은데 나의 희소성은 높디ㅏ : 지금 있는 회사에게 낮은 연봉을 받는다면 높은 연봉을 요청한다. 안 올려주면 같은 회소성을 유지하면서 더 높은 생산가치를 낼 수 있는 곳을 찾아 옮길 것을 고려한다.
- (4) 생산가치도 낮고 나의 희소성도 낮다 : 큰일이다. 연봉은 신경 쓰지 말고 일단 실력을 키운다. 미 취업자라면 일단 받아주는 곳에 가서 잔말 말고 2~3년 정도는 열심히 일하며 실력을 키운다.

하버드생보다 더 뛰어난 성과를 올리는 방법

한 분야의 오랜 학습은 이것저것 잘하는 천재를 이긴다. 소위 공부 잘하는 사람들이 서울대, 허버드를 자랑하고 최고의 성적을 자랑하고 있을 떄, 조금 덜 똑똑해도 한 분야를 끈질기게 오래 한 사람은 자신의 분야에 획을 그을 수 있다.
예전에 일본인 노벨상 수상자들에 관한 글을 읽은 적이 있다. 여기서 흥미로운 점이 있는데, 그들 중 어떤 분들은 평생 외국 유학도 안해보고, 심지어 박사학위도 없이 일반 회사에 다니는 분들도 있다는 것이다. 천재도 아니고, 심지어 공부를 그리 잘하지 못했던 분들도 있었다. 그런데 공통점은 '한 분야' 에 미쳤다는 것이다. 돌아가도 좋다. 서툴러도 좋다. 하나는 완성하는 일, 그것이 중요하다.
스스로 머리가 부족하다고 여길수록 한 분야를 파라. 미친 듯이 오랜 기간 파라. 그러면 이것저것 관심 많고 인기 분야만 쫓아다니는 수재, 천재, 고학력자를 이길 수 있다. 세상은 알량한 머리와 학벌을 자랑하는 이들에 의해 바뀌는게 아니다. 우직하고 호기심 있는 이들의 꾸준하고 피땀어린 노력에 의해 바뀐다.

리더가 에너지를 너무 많이쓰는 대상이 안되는게 좋다.

잘 맞는 인재는 리더가 에너지를 많이 쓰지 않게 한다. 능동적으로 움직인다. 어떤 지시를 하면 리더의 마감일보다 조금 빠르게 결과를 제공하고, 성격이 급한 리더와 함께 할 때는 적절하게 중간 진행을 커뮤니케이션한다. 자신의 일을 깔끔하게 처리하고 맡긴 조직을 잘 끌고 가서 리더가 신경 쓸 일이 많지 않게 한다. 가벼운 코칭으로도 실행을 빠르게 해낸다.
반면, 잘 맞지 않는 구성원은 리더의 에너지를 많이 쓰게 한다. 리더와의 마감 약속을 자꾸 어긴다. 자신의 일을 깔끔하게 처리하지 못해서 자꾸 잔소리를 하게 한다. 커뮤니케이션을 적절히 하지 못햇거 성질 급한 리더가 자꾸 물어보게 한다. 자꾸 마음에 걸리고 신경 쓰인다.
당신이 구성원이라면? 리더가 에너지를 많이 쓰지 않게 하는 것이 좋다. 이 말은 리더가 당신에 대해 무관심하게 만들라는 것이 아니라 믿을만한 모습을 보여주라는 것이다. 특히 꼼꼼하고 성질 급한 상사에 대해서는 선재적인 것이 좋다. 수동적으로 있으면 일을 적게 받는다고 생각하는 분들이 있는데 큰 오해다. 또한 마감보다 항상 조금 앞서 제공하라. 너무 빨리하면 일이 많아질 위험이 있으나 약간 정도만 빠르게 해라. 리더를 위협하지 마라. 셜령 이후 커리어를 고민하고 있을지라도, 있을 때는 영원히 있을 것 처럼 일하라. 리더가 개인 에너지를 덜 빼앗긴다면 당신은 괜찮은 직원으로 여겨질 것이다.
그것보다 더 좋은 것은? 리더의 에너지를 안 쓰게 만드는 정도를 넘어 반대로 리더에게 에너리를 주는 사람이 있다. 그를 보면 힘이 난다. 그러면 당신은 정말 사랑받을 것이다.

💡 요즘 말로 표현하면 알잘딱갈센이 아닐까? 믿을만한 신입 사원이 되기 위해 노력해보자. 선배들이 에너지를 쓰지 않도록 신뢰도 있는 후베가 되어보자.

평범해도 비범해지는 법

어떤 사람은 비범한 일도 평범하게 만드는데, 어떤 사람은 평범한 일도 비범하게 만든다. 일 자체가 평범하거나 비범하다고 여겨서는 안 된다. 일하는 태도가 평범과 비범을 나눈다.
"쥐꼬리만한 돈밖에 받지 않는데 평범한 일을 비범하게 하는 것은 결국 착취당하는 거 아닌가요? 돈 받은 만큼만 일하고 근무시간에는 최대한 놀아야지요. 그건 구세대들 때나 통해는 이야기에요" 이런 말을 하는 분들이 있다. 바보 같은 질문이다. 평범한 일을 비범하게 만드는 것은 남을 위한 것이 아니라 자신의 가치를 높인다. 또한 그런 사람은 절대 그 일만 계속하지 않는다. 더 큰 일을 하게 되며, 그렇게 일하는 것이 몸에 익어 더 큰 을 맡거나 자기 사업을 해도 역시 비범하게 한다.
고깃집에서 알바를 오랜 기간 했다는 직원이 있었다. 그때 팁을 꽤 많이 받았단다. 비결을 물어보니 손님이 오면 어떤 분이 어떤 반찬을 좋아하는지 유심히 관찰했다고 한다. 그분이 다시 오면 그 반찬을 많이 내어 드리고 빠르게 채워드렸다고 한다. 고객이 놀랄 수밖에 없다. 알바는 고기를 더 줄 순 없지만, 반찬은 더 줄 수 있는 권한이 있다. 역시 동일한 알바를 해도 다르게 하는 사람이 있다.

💡 평소에 일하고 있는 작업들도 더 비범하게 만들어보자. 마감기한이 아닌 더 빠르게 작업을 끝낸다던지, 다른 사람들이 생각치 못했던 서비스 장애 및 검수 사항등을 더 고민하고 파악해볼 수 있을 것이다. 또한 내가 노력해 작업한 내용들의 가치를 소중하다고 생각하고, 인정해주자. 비범하게 만든 일을 괜히 평범하게 만들어버릴 수도 있는것은 나 자신이 될 수도 있다.

바쁜 사람은 항상 바쁘다

가끔 "저는 너무 바빠요. 좀 여유롭게 일할 수 없을까요?" 라고 상담하는 분들을 만났다. 그런데 흥미롭게도 이런 분들의 상당수는 여유를 부릴 수 있는 환경에서조차 스스로를 바쁘게 굴린다는 것을 발견했다. 이에 대게 바쁜 사람은 여유로운 일을 맡아도 바쁘고, 여유로운 사람은 정신없는 일을 맡아도 여유롭다.
바쁜 사람과 여유로운 사람 유형으 차이는 무엇일까? 바쁜 사람은 고객 수준이나 프로젝트의 유형과 무관하게 목표를 항상 100% 에 잡았고 품질에 대한 스스로의 완벽성과 만족을 중시하며 일했다. 황상 계획을 빡빡하게 잡았다. 고객의 평가와 무관하게 자신이 만족해야 했기에 매사 힘들 수 밖에 없었다. 반대로 여유로운 사람 유형은 고객의 수준과 프로젝트의 유형에 따라 프로젝트를 진행했다. 고객의 수준이 80 이면 85 정도를 목표로 했던 것이다. 가끔 수준이 높은 고객 프로젝트는 힘들게 진행했지만 대개의 프로젝트는 여유를 가질 수 있었던 것이다.
바쁜 사람으로 일하는 것이 필요하지만 평생 그렇게 일하는 것은 삶에 좋지 않다. 삶은 균형과 여유 공간이 필요하다. 과도하게 일하다가 건강을 해치기도 한다. 강철 체력도 있지만 그렇게 일하다 진짜 골병드는 사람이 있다. 매사 바쁘고 매사 최선을 다하는 삶이 꼭 바람직하다고 말하기 어렵다. 매사 최선을 다하지 말라. 최선을 다할 가치가 있는 일에만 최선을 다하자!
여유롭게 일하는 비결은 다음과 같다.
- 모든 것은 다 동일하게 중요하지 않다는 사실을 인정한다. 중요한 것에 에너지를 쏟고, 중요하지 않은 일을 초스피드로 하거나 대충 하거나 타인에게 맡기거나(떠맡기는게 아니라, 대가를 주거나 역할로 맡김) 아예 하지 않는다.
- 내가 할 일은 내가 빠르게 하고 남의 일을 대신 고민하지 않는다. 나는 내가 할 일과 산하 구성원이 할 일을 명확히 한다. 정치적인 구성원들은 자기가 할 일을 위나 옆이나 아래에 미루곤 한다. 이에 나는 산하 임원에게 "그건 당신이 고민하고 답할 문제인데 왜 제게 떠넘기죠?" 라는 말로 책임을 명확히 준다. 단, 그가 그것을 이루지 못할 경우를 대비한 계획을 준비한다.
바쁘다는 것 자체를 인생을 보람있게 사는 것으로 여기는 분들도 있다. 새벽에 출근해 밤중에 나오면서 삶의 보람을 느끼곤 하신다. 그러다가 퇴직하고는 멘붕에 빠진다. 사실 위로 올라갈수록 더 여유를 가질 수 있는데 대개 워커홀릭은 스스로를 바쁘게 한다.

💡 바쁜것은 나 스스로가 바쁘게 만든 것이 아닐까? 우선순위를 구분하고, 모든 일이 중요하지 않다는 것을 인지하고 일을 하자.

때로 뺀돌이가 되어라

바쁘지 않으면서도 성과를 내는 비결은 이미 다 나와있다. '파레도의 법칙' 을 실행하면 된다.
우리 일을 살펴보면 20의 핵심적인 일과 80의 비 핵심적인 일이 있다. 앞의 20의 특징은 잘하면 비선형적인 성과를 내는 일이다. 핵심 프로젝트를 성공 시키거나 고객을 발굴하거나 새로운 변화를 만드는 일, 새로운 고객 가치를 만드는 일, 재테크 등일 것이다. 반면 뒤의 80은 못하면 욕을 먹지만 잘해야 본전인 일이 많다. 대개 많은 사람 손이 가고 시간을 많아 잡아먹는 운영상 일들이다.
몰론 위의 20이나 80의 일, 둘 다 대충 하면 실패환다. 성실하고 바쁜 사람들은 대개 위의 20이나 80을 구분하지 않고 무조건 최선을 다해 열심히 한다. 다 완벽하려 한다. 이러면 성과도 나고 인정도 받고 승진도 하지만 항상 정신이 없고 여유가 없다. 너무 바빠서 새로운 생각을 하거나 새로운 시도를 하거나 삶을 돌아볼 여유가 부족해진다.
그러면 어떻게 일할 것인가?
위의 20은 열심히 한다. 에너지를 쏟는다. 시간을 더 투자한다.
위의 80은 무작정 열심히 하지 말고 '어떻게 편하게 할까?" 에 초점을 둔다. 소위 뺀돌이가 되는 것 이다. 허술하게 하라는 뜻은 아니다. 거절하거나 시스템화하거나 자동화하거나 아웃소싱하거나 협업을 하거나, 여하튼 편할 방법을 찾아야 한다.
80 중 아예 할 필요가 없는 것은 하지 않는다. 할 필요가 없는 일을 판단하는 기준은 "그 일을 안 했을 때 무슨 큰 일이 일어나는가?" 를 자문하면 된다. 큰 일이 안 일어나는 일은 하지 않으면 된다. 할 필요가 없는 일을 효율적으로 하는 것도 바보짓이다.

피하는 쪽이 아니라 향하는 쪽으로 생각하라

"이러한 원하지 않는 모습을 어떻게 해결할 수 있을까요?" 라는 질문을 많이 받는다. 즉, "피하고 싶은 미래를 어떻게 피하고 해결할 수 있을지" 에 대한 질문이다. 예를들면 "저는 역량이 부족한 것 같아요", "상사가 힘들게 하고 마음에 안 들어요" 등이 있다.
하지만 사람들은 "피하고 싶은 미래가 아니라 정말 이루고자 하는 미래, 원하는 모습, 마음을 하나로 집중시킬 목표는 무엇인가요?" 에 대한 대답은 하지 못한다. 생각 외로 원하는 모습은 잘 묘사하지 못한다. 피하고자 하는 상황, 문제는 잘 아는데 진짜 원하는 모습을 그리는데 익숙하지 않은 것이다. 돈의 결핍을 피하고자 하지만 돈을 번 후 그걸로 무엇을 할지는 생각이 없다. 역량의 부족은 피가호자 하나 역량을 쌓아 뭘 할지는 생각이 별로 없다는 것이다.
"나는 왜 돈이 부족할까?", "나는 왜 실력이 부족할까?", "나는 왜 나쁜 습관에 빠져있을까?" 등에 집중하다보면 항상 돈, 실력이 부족하고 나쁜 습관에 빠져있는 채 살게 된다는 것이다.
진짜 원하는 다른 것에 집중하고 시간을 쓰다보면 버리려던 나쁜 습관이 자연스럽게 없어질 수 있다. 그러므로 중요한 것은, 원하지 않는 것을 없애려는데 시간을 쓰기 보다는 원하는 것에 에너지를 쓰는 것이 더 낫다. "내가 직장에서 어떤 모습을 만들까? 어떤 사람이 될까? 돈을 많이 벌어서 뭐 할까?" 에 집중하게 이를 위해 무엇을 할까? 를 실행하는 것이다.
피하려고 생각하기보다는 향해서 나아가려고 생각하라. 나아가려하면 창의적인 생각들이 떠로은다. 자신의 부족함을 극복하기 위해 애쓰려는 노력을 원하는 형상이나 이미지를 만들고 이를 성취하는데 쓰라.

초보 코치가 아니라 코치다

스스로 과도한 겸손에 빠지면 "초보" 라는 말 뒤에 숨어서 가능성을 제한해버릴 수 있다. 겸손이 지차닌 것 은 부족함과 유사하다. 그런데 흥미로운 점은, 대개 당신이 선망하는 그 유명한 분들은 당신보다 더 어린 나이와 부족한 지식으로 남들을 돕고 가르치기 시작했다는 것을 잊지 마시라.
코치면 코치지 무슨 초보 코치인가? 초보 코치가 아니라 코치이고, 신입사원이 아니라 사원이다.
'신입' 이나 '초보' 라는 이름하에 숨을 이유가 없다. 그것은 겸손이 아니다. 프로의 세계에 들어가면 그때부터 프로인 것이고 프로답게 행동해야 한다. 연륜을 존경할 필요는 있지만, 오히려 연륜이 부족할 때 더 신선한 시각과 넘치는 에너지로 더 잘할 수 있다는 것을 기억할 필요가 있다.

집중력과 의지력의 명과 암

열정, 집중력, 의지력은 등은 용량이 한정되어 있다. 이에, 어떤 것이 에너지를 과하게 쓰는 사람은 항상 그 이면이 있다.
너무 한쪽에 모든 에너지를 써버리거나 매사에 과도한 열정과 의지력을 써버리는 것도 위험하다. 조금 남겨두어야 개인의 삶이나 진짜 원하는 꿈을 위해서도 쓸 수 있다. 일주일에 하루 정도는 눈앞의 일에서 벗어나 소소함을 누리거나 조금 먼 시각, 장기적인 시각에서 자신의 일과 삶을 돌이켜 볼 필요도 있다.
매사에 빈둥거리는 것도 문제이지만 매사에 효과, 효율만 강조하게 조급해하고 불안해하는 것이 오히려 건강한 성장에 도움이 안된다. 의외로 쉬거나 주제없이 대화하는 것을 불안해하고 죄챇감을 느끼는 분들이 많다. 가끔식은 그 동안 집중했던 것에서 떠나 에너지를 축적하고 일상의 소소함, 자연이나 큰 관점에서 에너지를 써보자.

탁월한 사람과 경쟁하면 실력이 늘까?

건전한 경쟁, 약간의 차이가 있는 사람들과의 경쟁은 우리의 실력을 향상시킨다.
그러나 슈퍼스타와의 경쟁은 오히려 자신의 실력을 망가뜨린다. 기량 발휘를 못하고 심리적으로 주눅 들고 쪼그라든다.
그러므로 슈퍼스타가 없는 곳에서 마음 편하게 놀아라. 즉, 용의 꼬리보다 뱀의 머리가 돼라.
더 훌륭한 전략은 슈퍼스타와 경쟁하려 하지 말고 협력화는 것이다. 그리고 실력이 쌓이면 슈퍼스타를 떠나서 자기만의 분야를 만들어라.

💡 내 생각을 다시 정리하면, 우선 경쟁을 통한 성장을 하고 싶다면 비슷한 실력 수준의 사람들과의 경쟁을 통한 성장을 하는 것이 좋다는 것으로 정리되었다. 이것보다 더 좋은 방안은 뛰어난 실력자와 경쟁이 아닌 협업을 통해 성장하는 것이다.

글로 쓰면 다룰 수 있다

글로 명료화하는 순간, 복잡한 생각을 쉽게 다룰 수 있게 된다. 글로 명료화하지 않으면 다루기 어렵다. 생각이란 실체가 없어서 머리 밖으로 뿔뿔이 산발되어 흩어지기 쉽다. 게다가 감정까지 복합되면 아무리 똑똑한 사람도 이를 다룬다는 것은 거의 불가능하다.
그러므로 일할 때나 보고서, 논문 쓸 때만 글로 쓰지말고 평소 자기 삶에서도 써보길 권고한다. 좋은 생각이면 좋은 생각대로, 부정적인 생각이면 부정적인 생각대로 써보면 된다.
쓰지 않는 또 하나의 이유는 너무 잘 쓰려 해서이다. 특히, 블로그나 페북 등의 SNS 를 꾸준히 하는 비결은 몇 줄이라로 가볍게 쓰는 것이다. 처음엔 그냥 내 감정이나 생각을 2~3줄로 '명명' 하거나 '명로화' 하는 정도로 충분하다.
너무 '길게' 그것도 '자주' 그리고 '잘' 쓰려하면 오래가지 못한다. 주말에만 쓰는 것도 방법이다. 주위 사람들의 반응은 '동기' 가 되기도 하고 '독' 이 되기도 한다. 그냥 적절한 동기부여 정도로만 받아들여야지 너무 의식하면 피곤해진다. 자신을 위해서 쓰는 것이지 타인에게 영향주려고 쓰면 피곤해진다. 처음엔 2~3줄로 충분하다. 아무렇게나 막 쓰면 되고, 그러다가 좀 쓰게 되면 글쓰기 책 한 권 정도 보면 된다.
유명해지지 않는 한 당신의 글에 주위 사람들은 아무 관심이 없다. 그냥 고민없이 한번에 쉼 없이 쓰는 것을 추천한다. 그리고 혹 수정할 필요가 있으면 이후 몇 차례 수정한다. 자꾸 읽다 보면 활자 중독이 되어 책을 쉽게 읽게 되는 것 처럼 쓰는 것도 습관화되다 보면 쉽게 된다.

💡 내가 가장 인상깊게 읽었던 부분인 것 같다. 내가 평소에 글을 지주 쓰는 이유 및 철학과 완전히 일치한다. 글을 쓰면 생각이 정교화(elaboration) 되고, 메타인지가 활성화 되는 효과를 자주 느낄 수 있었다. 글쓰기와 관련해 느낀 점 및 개선점을 추가로 적어보자면 아래와 같다.

업무 중에도 CS, QA, 회의 및 기타 안건을 해결할 때 생각이 흩어진 느낌을 받았다면 바로 글로 상황을 정리해보자.

길게, 자주, 잘 쓰려는 것이 부담이 될 수 있다. 블로그에 요즘 글 발행을 거의 못하고 있는데, 부담이 된다면 짧게라도 정리되지 않은 내용을 올린 후 자주 수정 및 업데이트를 해보자. 타인을 의식하지 않고, 순수히 나만을 위한 글을 써보겠다.

타인의 성공비결이 내게 얼마나 도움이 될까?

타인의 성공 및 실패 경험은 나의 성공 및 성장률에 얼마나 큰 도움이 될까? 성공률에 큰 영향력을 끼치는 요소는 타인의 성공 경험이 아닌, 타인의 실패 경험이라는 점이다.
타인의 실패 경험은 내 성공 및 성장에 큰 영향력을 끼친다. 흥미롭게도 타인의 성공 경험은 자신의 성공에 큰 영향을 미치지 않았으나, 타인의 실패 경험은 자신의 성공에 매우 큰 영향을 미쳤다. 왜일까? 대개 사람은 타인의 성공을 부러움으로 가져가지만, 자신의 레슨과 피드백으로는 가져가지 않기 때문이다. 그러나, 타인의 실패는 명확한 피드백이 되고 타산지석이 된다.
흥미롭게도, 자신의 실패를 통한 배움은 없었다. 인간은 오히려 유사한 실패를 반복한다. 그런데 자신의 성공 경험은 더 큰 성공을 가져왔다. 왜일까? 대개 사람은 자신의 실패에 대해서는 주위나 자신을 탓할 뿐 냉정한 피드백을 가져가지 못하기 때문이다.

💡 내가 성공하려면 타인의 성공/실패 경험 어떤 것을 집중해야 할까? 타인의 실패 경험에 집중해보자. 실패 경험을 들음으로써 명확한 피드백과 타산지석이 될 것이다. 아울러, 나 자신의 실패를 통한 배움은 없다고 하는데, 나 자신에게 실패했을 경우에 대한 냉정한 피드백이 있으면 되는 것 아니곘는가? 나 자신에 대한 실패 경험이 생겼을 경우, 괴롭고 고통스럽겠지만 냉정한 피드백을 해보자.

주위에 나보다 잘하는 사람이 많다면

잘하는 상대의 타입에 따라 두 가지 중 하나를 권고한다. 대개 나이가 어린 사람에게는 꾸준함을 잃지 않고 일단 현재 영역에서 어느 정도 수준까지 도달할 것, 또 하나는 현재의 영역을 하고 싶거나 다른 잘 하는 영역과 융합해 볼 것을 이야기한다.
이미 방법론과 룰이 세팅되어 있는 영역에서는 경험과 실력이 더 많은 사람이 항상 또는 거의 이기게 되어있다. 그런 영역은 1등부터 꼴등까지가 명확하다. 자신이 앞서 있다면 몰라도 그렇지 않다면 기존의 게임의 룰을 따르기보다는 자신의 영역을 만드는 것이 나을 것이다. 자신의 영역은 어떻게 만들까? 완전히 새로운 것을 찾을 수도 있지만, 자신의 적당히 하는 것들을 적절히 융합해서 나만의 콘텐츠 및 개성을 찾을 수 있다. 그리고 보통 사람에겐 전자보다 후자가 더 현실적이다.

배움의 기술

배움이 가장 효과를 거두려면 운동이나 악기를 배우는 방식과 유사하다.
- 개략적인 큰 그림을 동영상이든 세미나를 통해 가능한 그 분야를 제일 잘 하는 분이나 잘 가르치는 분에게 배운다. 가능한 '독학으로는' 공부하지 않는다. 수영을 처음하는 사람이 수영을 배우기 위해 수영장이 아닌 수영 책을 섭렵하는 것은 그리 바람직하지 않다.
- 초기에는 실행 과정을 등록하여 그저 시키는 대로, 삶이나 일의 현장에서 실행하면서 꾸준히 피드백과 코칭을 받는다. 프로를 목표로 하지 않는 경우라도 최소 1~3년 정도는 꾸준히 해야 한다.
- 그러면서 어느정도 스스로 분별할 수 있는 수준이 되며 책이나 다른 사람들의 경험, 세미나를 선택하여 스스로 공부하고, 자신에게 접목한다. 열심히 읽고 배우고 다양하게 실험해본다. 그리고 초기에 배웠던 특정 스승을 떠난다.
- 기존 방식과는 다른 자신만의 차별화 방법을 만든다. 멘토의 말은 선별하여 듣는다. 꾸준히 책을 읽으며 감각을 유지하고 발전시킨다. 소비는 그만하고 생산한다.
- 이제 남들을 가르치면서 더 발전한다. 글도 열심히 쓰고 영향력을 확대한다. 타 영역도 배우면서 타 영역의 인사이트를 융합시킨다. 꾸준히 자신의 차별화를 강화시킨다.
좋지 않는 배움의 방식은,
- 혼자 무작정 실행한다. 혼자 무작정 책만 보고 배우거나 주위 비슷한 수준의 친구를 보고 배우거나 자기 느낌대로만 실행하면 초기에는 빠르게 성장하는 것 같지만, 어느 시점 이후로 성장이 정체된다. 거리 싸움꾼이 일반인들은 이기겠지만, 제대로 배운 프로선수는 이기지 못한다. "Street Smart" 에 그친다.
- 유명한 분들만 찾아다니고 수동적인 공부만 하면서 지식만 잔뜩 쌓는 것도 안좋은 배움 방식이다. 방법만 찾고 막상 실험과 행동을 별로 안한다. 소비만 하고 생산은 별로 안한다. 남들의 방법만 쫓아다니고 지적 만족에 그치며, 막상 실험과 행동을 통해 자신만의 방법을 만들지 않는다. 예를들어, 남들이 말하는 '돈 버는 법' 백발 배우고 쫓아다녀야 돈 못 번다. 배우고 실험해서 자신만의 '법' 을 만들어야 한다. 이런 분들은 대개 머릿속에 온작 이론이 뭉쳐저있어 행동을 더 못한다. 'Book Smart' 에 그친다.
💡 말만 번지르르, 책만 읽는 수동적인 배움 태도는 성장하지 못한다. 적극적으로 자신만의 노하우 및 스킬을 찾아나가는 배움의 태도가 최고일 것 같다.

효과적으로 배우는 방법은 비효율적으로 배우는 것이다

수동적인 독서, 강의 듣기는 편하지만 한계가 분명하다. 기껏해야, 이해하거나 요약하는 정도의 머리밖에 쓰지 않는다. 떠먹여 주는 강연이나 설교는 이해나 요약조차 필요 없다.
실제 삶의 변화가 이루어지려면 뇌에 새겨져야 한다. 뇌에 새겨지려면, 스스로 몸과 머리를 쓰고 기록하고 실습하고 연습하고 자기가 이를 말로 이야기해봐야 한다. 그것도 반복해서 해야 한다.
'귀찮음' 과 '지루함' 을 이겨야 한다. 또한 '돈과 시간의 소비' 가 필요하다. 진짜 '효과적' 으로 배우는 방법은 '비효율적' 으로 배우는 것이다.

'처음부터 제대로' 가 '민첩함' 의 발목을 잡는다

어떤 분들은 '처음부터 제대로' 할 것이 아니라면 아예 실행하지 않는다. '실수' 하거나 '실패' 하려 하지 않는다. 특히, 지금까지 좋은 경력과 브랜드를 쌓아 왔을수록, 성공과 인정의 욕구가 강할수록 더더욱 그러하다.
일단 작게 실험해보고 피드백을 받으며 발전시키는 것이 훨씬 효과적이고 효율적이다. 더더욱 변화가 빠르게 예측이 어려운 이 세상에서는 말이다.
'부담 없는 작은 출발' 그리고 '반복', 이 과정 중의 '피드백' 의 '지속적인 반영' 이 완벽한 준비 부담으로 아예 출발조차 못하거나 무겁게 출발했다가 부담이 되어 지속하지 못하는 것보다 훨씬 낫다.

💡 어쩌면 인생은 '애자일' 방법론을 따르면 살아야 하지 않을까? 부담없이 작은 출발을 하고, 피드백을 통해 점차 개선하는 모습은 마치 애자일 방법론을 떠오르게 한다.

낮은 수준의 생각 전략

중요한 일을 회피하는 자신을 합리화하고 안심을 주기 위해 쓸데없는 일을 열심히 하는 것을 '낮은 수준의 생각 전략' 이라고 명명한다. 중요하지만 하기 싫은 일이 있을 때, 높은 수준의 생각을 써야 하는 것이 귀찮고 힘들 떄, 단순한 일을 하고 낮은 수준의 생각을 함으로써 스트레스를 줄이고 자기 합리화를 하는 것이다.
자신이 바쁘다면 스스로에게 물어볼 필요가 있다. 내가 진짜 중요한 일에 바쁜가? 아니면 그것을 회피하기 위한 쉬운 일을 하면서 이게 그 중요한 일이 도움 될 거야라고 스스로를 합리화하고 있는 것은 아닌가?

전략적 무능

'전략적 무능' 이라는 표현이란, 우리가 모든 것이 유능하려고 애쓸 필요가 없다는 것이다. 모든 것을 제대로 하고, 모든 것을 잘 하려고 하면 바쁘고 에너지가 한없이 든다. 그러므로 떄로 어떤 것들에는 '무능' 해질 필요가 있다는 것이다. 가장 가치있고 중요한 일에 초점을 맞추고 나머지는 전략적으로 대충 해도 된다는 뜻이다.
일을 할 때도 내가 집중적으로 봐야 할 부분은 굉장히 깊고 꼼꼼하게 들어가지만, 그렇지 않은 부분은 대충 보는 것이 좋다.
몇 가지 영여겡서 '무능' 을 선택하면 의외로 시간이 많이 남는다. 그 시간에 자기가 원하고 필요한 것을 하면 된다. 세미나 또는 교육 과정을 참석하기도 하고 새로운 것을 배우기도 하며, 책도 읽고 글도 쓰고 페북도 하고 휴일에 침대에서 뒹굴거리기도 하는 것이다.
매우 바쁘게 살고 이를 좀 변화하고 싶다면, 한 번쯤은 거절하고 쳐낼 것, 좀 무능할 영역을 찾아보시라. 그거 안 한다고 죽지도 않고 큰 일 나지도 않는다.

그리 안 똑똑해도 엄청 똑똑하게 보이는 비결은?

일터에서 '묻는 질문에 간략히 핵심만 대답하기' 만 잘해도 정말 똑똑해 보인다.
예를들어, '그 방안의 장점과 단점을 말해주세요' 라고 물었다면 '그 방안의 장점은 ~ 이고, 단점은 ~ 입니다' 이렇게 답함녀 되는데 이렇게 답하는 사람은 의외로 많지 않다. '그 방안은 어떻고요. 그 방은 어떻게 만들어졌고요' 질문과 관계없는 주변 가지들을 자꾸 말한다.
질문에 대해서는 '결론만 짧고 명확히 먼저 말한다' 그리고 시간이 남거나 상대가 이유를 요청하면, 근거가 되는 이유 3가지를 첫째, 둘째, 셋째 이렇게 말한다. 이렇게만 하면 엄청나게 똑똑한 사람으로 보인다.

'그때 그걸 했어야 했는데' 를 지금 하라

과거는 지나갔다. 후회나 평론은 아무 변화를 가져오지 못한다. 과거에 못했다면 교훈을 얻어 지금이라도 하면 된다. 과거는 바꾸지 못하지만 현재와 미래는 바꿀 수 있다. '이랬어야 했는데' 는 과거다. 과거는 과거다. 이랬어야 했는 걸 지금 행동하면 된다.
불가능한 일이 아니라면 지금 하면된다. 창피할지라도, 이랬다저랬다 한다고 욕을 먹더라도, 그냥 하면된다. 돌이키고 자백하고 사과하고 하면 된다. 그것이 진짜 똑똑한 사람이 하는 방식이다. 그런데 왜 이렇게 하기 어려울까? '용기' 가 부족하기 때문이다. 바꾸면 자존심도 상하고 욕도 먹게 되어있다. 과거의 결정이 잘못되었다고 스스로 인정하는 것이기 때문이다. 그걸 뛰어넘는게 '용기' 이다. 욕먹을 용기, 과거 잘못된 판단을 시인할 용기, 자존심을 꺾을 용기, 미움받을 용기, ...
진짜 똑똑한 살함은 '용기 있는 사람' 이다. 진짜 똑똑한 사람은 사과를 하고 변화를 만든다.

제대로 망치를 두드려라

열심히 땀을 뻘뻘 흘리며 일하는게 중요한 것이 아니다. 열심히 일하는데 아무 곳이나 망치를 두드리면 오히려 상황을 악화시킨다.
프로, 전문직이나 기업은 '열심' 이나 '노력' 으로 박수를 받는 것이 아니다. '유능함' 으로 박수를 받아야 한다. 끝없는 훈련과 개발, 경험으로 역량을 쌓아 문제의 본질을 찾아 해결해야 박수를 받는 것이다. 이것저것 아무거나 건드려서 시간을 빼앗과 비용과 에너지를 증가시키는 의사, 변호사, 경영자를 지지할 사람들은 거의 없다.
제대로 망치를 두드려야 한다. 우리 또한 제대로 망치를 두드리는 사람이 되도록 훈련하고 실력을 쌓아야 한다. 만일, 우리 자신이 부족하다면 그런 전문가를 찾아야 한다. 누가 제대로 망치를 두드리는 사람인가를 아는 능력 또한 제대로 망치를 두드리는 능력만큼이나 중요하다.

이미 지고 들어가는 말들

가끔 예의 바른 직원이 자신의 의견을 제시하면서 이런 표현을 쓴다. "외람될지도 모르는 말씀이오나..." 그러나, 이러한 표현을 쓰는 순간 그 다음 그가 하는 말이 별거 아닐수도 있었는데, 이미 듣는이에게 긴장과 불쾌감을 주게 된다.
불필요한 말은 안하는게 낫다. "제가 오늘 준비가 안되었지만요", "제가 오늘 화장이 잘 안 먹어서요", "제가 떨려서요" 다 불필요한 말이다. 몰론 이런 말을 하는 심리적 이유가 있다. 진짜 겸손의 표현일 수도 있지만, 실패할 경우를 대비하여 변경거리를 미리 만드는 것일 수도 있다. 이렇게 해야 심리적 안정이 될 수 있다. 신경 쓰지 않으면 본능적으로 이런 말을 하게 된다.
그러나 불행히도 그런 말을 하는 순간 살함들은 그 프레임 속에서 당신을 보기 시작한다. 화장을 관찰하고 긴장.떨림을 관찰한다. 내가 왜 나보다 못난 녀석에게 이야기를 들어야하지? 라고 여기게 된다.
그냥 하시라. 대부분은 당신의 화장이 잘 먹었는지, 긴장되었는지 모두 관심없다. 발표를 하고 강의를 하고 건의를 하고 부탁을 하고 실례를 하려면 그냥 자신있게 해라.

속독이냐? 정독이냐?

의지력이 강하지 않는 보통 사람들은 기본적으로 '속독' 하고, 마음에 들면 이후 '정독' 하는게 효과적이다. 의지력이 강하거나 책에 쉽게 몰입하는 분들은 처음부터 정독해도 좋으나, 일반인들은 그렇게 접근했다가는 단 한 권도 책 끝까지 못 읽는다.
그러므로 일단, 대충 쓱쓱 읽으면서 주요 부분한 밑줄 친다. 날을 정해서 가능한 몇 시간 내 단숨에 끝까지 읽는다. 그리고 별로면 거기서 끝내고, 정말 좋으면 다시 읽어라.
결론은, 당신이 집중력이 강하고 끈기가 있는 비범한 사람이라면 처음부터 정독하라. 그러나 의지박약에 약한 기억력의 소유자라면 대충 속독하여 일단 끝까지 읽어라. 그리고 정말 좋은 책이라 생각하면 다시 읽어라. 정독할 능력이 안된다면 굳이 처음부터 정독하려 애쓸 필요없다. 또한 다양한 많은 책을 읽으려면 일단 속독하라.

💡 나는 기억력이 좋지않고, 흥미가 안 붙으면 머리속에 정리도 안되고 기억도 안남는다. 이 떄문에 책 안의 내용이 친숙해지고 흥미로워 질 떄까지 n회 속독을 한다. 앞으로도 계속 고집 피우지말고 속독 스타일로 공부, 독서를 해볼까 한다.

피드백을 회피하지 말자

피드백이 제대로 효과를 발휘라혀면 아래 4가지가 충족되어야 한다.
자신이 피드백을 받으려는 마음이 있어야 한다 : 그러나 불행히도 피드백을 받길 좋아하는 사람은 사실상 없다. 인간 본성상 누구에게 쓴 말을 듣고 싶은 사람은 없다.
피드백을 주는 사람에 대한 신뢰가 있어야 한다 : 이 또한 쉽지 않다. 대부분은 리더에 대해 신뢰가 부족하다. 신뢰하지 않는 리더나 코치가 주는 피드백은 꼰대의 잔소리나 간섭, 질책으로 밖에 안 들린다.
피드백을 주는 사람이 제대로 된 구체적인 피드백을 줄 정도로 실력이 있어야 한다
피드백을 주는 사람이 그 피드백을 잘 전달해야 한다
'피드백' 이 없으면 절대 발전이 없다. 천재가 아닌 이상 혼자의 방식대로 수영하고 바둑을 둬서는 제대로 배우고 피드백 받은 사람들을 이길 수 없다. 마찬가지로 일을 하거나 사업을 할 때, 훌륭한 코치를 찾아 제대로 된 피드백을 받아 성장하는 것이 효과적이고 효율적인 길임이 분명하다. 그러하니 누구든지 좋은 코치를 찾아야 하고, '피드백' 받는 것을 회피하거나 두려워하지 말자.

'즐긴다' 는 말의 허상

즐기면서 최고가 될 수 있는 사람은 아무도 없다. 결과는 즐길 수 있겠지만 그 과정은 즐길 수 있는 성질의 것이 아니다. (몰론, 순간순간 성취감에 즐거움을 느낄 수 있겠지만) 고통을 극복하고 최고의 위치에 오른 후 되돌아보니 과거의 고통이 미화되고 성취감과 승리감의 기억에 즐겼다고 오해하는 것일 가능성이 높다.
그러므로 '즐기면서 해라' 라는 말은 취미생활 정도를 목표로 하는 이들에게나 할 수 있는 조언이지, 최고를 지향하는 이들에게 할 수 있는 조언은 아니다.

약점이 강점이 된다

자신의 치명적 약점을 생각해 보면, 의외로 그 약점 덕분에 다른 부분이 발달되었거나 성장할 수 있음을 발견하게 된다. 치명적인 약점을 극복하는 과정에서 오히려 강점이 된 것이 있을 것이다.

Yes 는 Yes 이고 No 는 No 이다

삶에서 어려운 것 중 하나는 Yes 와 No 를 분명히 하지 못하는 것이다. Yes 도 No 도 아닌 채 어중간하게 유지하는 경우들이 종종 있다. 이 이유는 정말 마음속에서 분명한 선택을 못해서인 경우도 있지만, 마음속에 선택을 했음에도 불구하고 상대를 실망시키거나 상대에게 싫은 말을 하지 않기 위해서 질질 끄는 경우가 많다.
그런데, 이렇게 미루는 것은 결과적으로 서로에게 더 큰 피래를 주는 경우가 많은 듯 하다. 상대에게 희망고문이 되는 경우가 많다. 빠르게 'No' 라고 하면, 깨끗하게 포기하고 다른 대안을 찾아 나서면 되는데 이도 저도 아니면 끝없이 기다리고 자원을 써야 한다.
그러므로 중간은 없다. Yes 는 Yes 라고 하고, No 를 No 라고 하는 것이 결과적으로 서로에게 낫다. Yes 를 Yes 라, No 를 No 라 명확히 못하는 사람은 '마음이 여린' 사람이 아니다. '자기중심적인' 사람일 뿐이다.

💡 나도 종종 이럴때가 있다. 결정에 있어 빠르게 판단하고, 의사를 확실하게 밝혀서 상대에 대해 배려를 해주자. 시간을 너무 오래 끌어서 자기중심적인 사람이 되지 않도록 노력하자.

가장 나쁜 핑계 : 나보다 잘하는 사람이 얼마나 많은데요

'나보다 잘하는 사람이 얼마나 많은데요' 이 생각은 자신을 평가절하하고 새로운 시도를 스스로 제한하는 가장 나쁜 핑계 중 하나이다. 가장 노래 잘하는 가수가 가장 유명하고 부를 얻는게 아니다. 가장 노래 잘하는 사람은 보이스 코칭을 하거나 미사리에서 어렵게 어렵게 돈을 벌고 있다. 노래는 별로인데 특별한 매력을 가진 이들이 돈도 벌고 인기도 얻는다. 지신만의 독특함을 찾는게 더 중요하다.

45세 때부터였다

'논리적이고 체계적으로 생각하는 가장 좋은 방법' 은 무엇일까? 이 방법 중 하나는 바로 자신의 생각을 '글로 쓰는 것' 또는 '그림으로 그리는 것'이다. 자신의 머릿속의 생각을 글로 쓰거나 그림으로 표현해 보면 생각을 더욱 정교화 할 수 있다.
'힘든 일이 있거나 감정이 복잡할 떄 해결할 수 있는 방법' 은 무엇일까? 이 또한 '쓰는 것' 이 가장 좋은 방법이다. 헝클어진 생각들은 다루기 힘들다. 이를 글로 정리하면 이제 머릿속의 생각이 지면으로 옮겨진다. 머릿속은 내가 다루기 어렵지만, 언어화된 글은 내가 다룰 수 있다. 글을 써보면 논리적 오류도 찾을 수 있고 생각의 변화를 가져갈 수 있다.

📚 2장. 성공 | 조직을 성공으로 이끄는 리더쉽의 발견

왜 훌륭한 목표와 전략이 실행에서 실패할까?

한 연구소는 50만명 이상의 리더와 팀을 대상으로 조사하여 목표와 전략이 실행단계에서 실패하는 4가지 근본 원인이 있음을 발견했다.
85% 의 응답자는 조직의 목표를 몰랐다.
85% 의 응답자는 조직의 목표를 이루기 위해 자신이나 자신의 조직이 할 일을 명확히 몰랐다.
85% 의 응답자는 회사가 가장 중요해 하는 목표와 관련해서 성공하는지 실패하는지 몰랐다.
79% 는 목표 진행에 있어 자신의 명백한 책임을 몰랐다.

최고의 실행이 안먹히는 이유

우리가 책에서 본 최고의 실행을 도입할 때 주의할 것 중 하나는 Context 를 놓치면 안 된다는 것이다. 그런데 책이나 강연에는 이 Context 가 없다. 저자들이나 강연자들 또한 다른 회사들의 사정을 알 리가 없다. 무작정 듣고 읽고 뱅룬다고 다른 회사의 성과가 복제되는 것은 아니다. 많은 리더들이 이 Context 를 읽지 못한다.
예를들어, 대부분의 실리콘밸리 기업이 자율을 추구할 수 있는 이유는 구성원들의 역량이 있기 때문이다. 완전한 자율과 위임은 구성원들의 역량이 있고 목표가 명확할 때 가능하다. 이 가정을 보지 않고 겉에 드러난 '자율' 만을 이식하려고 하면 어려움이 생기는 것이다.
그러므로 중요한 것은, 자신과 자신의 조직에 대한 이해가 선행되어야 한다. 그렇지 않은 상ㄱ태에서는 아무리 멋진 실행도 맞지 않는 옷이 되는 것이다. 그렇다고 포기하고 예전의 방식을 고수하라는 것은 아니다. 당연히 훌륭한 철학과 실행을 도입하고 변화를 만들어내야 하지만, 자신의 회사가 가지고 있는 역량과 문화에 맞게 조율해야 한다는 것이다.

우리를 성공하게 한 비결이 우리를 실패하게 할 수 있다

자신을 성공으로 이끈 개인 성향 또는 조직의 원칙, 문화가 실패로 이끌 수도 있다. 논리나 데이터를 중시하는 분은 그것이 반드시 최상의 결과를 가져오지 않을 수 있다는 것을 받아들일 필요가 있다.
복잡한 상황, 문제를 대하는 가장 좋은 전략은? 바로 '유연성' 이다.

힘들게 하는 상사를 어떻게 대해야 하는가?

상사와 잘 지내기 위해서는 근본 원리와 기술이 필요하다. 근본 원리는 '신뢰' 이다. 신뢰가 형성되지 않으면 상사와 함께 일하기 어렵다. 신뢰를 얻기 위해서는 1) 일에서 크고 작은 성공들을 쌓고 2) 성실과 충성을 통해 믿을만한 모습을 보이고 3) 인간적 친밀감을 쌓아 나가는 것 외에 길이 없다.
'그는 어떻게 그 모든 일을 해내는가' 책을 보면 '상사를 대하기 위한 좋은 기술' 들이 아래와 같이 접근법을 제시하고 있다.
상사의 스타일을 파악하고 맞춘다.
간섭하는 상사에게는 작은 프로젝트를 통해 신뢰를 얻어라. 상사가 묻기전에 먼저 보고하라. 이런 유형은 안심이 될수록 간섭은 줄어든다.
상사의 의사소통 방식, 업무 스타일에 맞춘다. 메일을 좋아하면 메일로, 대면 보고를 좋아하면 대면으로 하라.
상사가 어떤 유형이든 당신이 매번 과제를 성공한다면 환영을 받는다.
프로젝트를 성공한다는 것과 그걸 알린다는 것은 다르다. 요청하지 않아도 시의적절하게 성과를 알려야 한다. 인사고과 시즌은 당신이 겸손할 때가 아니다. 가만히 있는데 알아서 점수를 잘 주는 상사는 거의 없다.
프로젝트가 실패할 것 같으면 빨리 알려라. 지연되다가 갑자기 안좋은 소식을 듣고 반길 상사는 아무도 없다.
문제 보고 시에는 창의적 해결책도 같이 보고하라.
상사와의 신뢰 구축은 오래 걸리지만 무너지는 것은 한순간이다. 절대 동료들과 상사 뒷담화를 하지마라. 다 귀에 들어간다.
상사에게 반대 의견을 제시해도 최종 결론은 상사의 것이며 따를 것임을 분명히 한다. 근거 자료와 대안을 준비하라. 절대 감정적으로 맞서거나 상사의 능력을 비하하지 마라.

새로운 일을 꺼리고 저항하는 이유는 싫어서가 아니라 몰라서이다

사람들이 저항하는 이유는 '익숙함을 벗어나는 것에 대한 두려움' 이다. 새로운 것을 잘 못화면 뒤쳐질 것 같은 두려움 때문에 저항하는 것이다. 혁신적인 10~20% 는 누가 말 안해도 스스로 배우지만, 중간에 있는 다수는 염려하고 저항한다.
만약 새로운 것을 팀과 도전하고 싶다면, 방법은 2가지가 있다. 하나는 끊임없이 이야기한다. 만날 때고 하고, 메일로도 하고, 전체로 모여도 하고, 그룹으로 모여도 한다. 일 년 내내 이야기한다. 이려면, 대부분의 구성원들이 새로운 변화의 용어를 스스로 자연스럽게 말하게 된다. 두 번째는 배울 수 있도록 도와준다. 말만 백날하고 토론만 백날 해서는 단 하나도 변화하지 않는다.

Learn it all 은 Know it all 을 이긴다

"Learn it all 은 Know it all 을 이긴다" 이 말은 아는체 하지 말고 겸손하게 모른다는 것을 인정하고, 매일이 새로운 날이 되도록 배우고 탐구하고 실험하라는 것이다.
회사를 다닌 기간이 중요한 것이 아니다. 3년 경력만으로도 10년 경력보다 잘 하는 사람들을 종종 보았다. 중요한 것은 얼마나 배우고 성장했는가이다.
모르는 것을 인정하고 끊임없이 배움을 추구하는 사람은, 자신은 이미 모든 것을 알고 있다고 착각하는 사람을 이긴다.

우리가 진실이라고 받아들이는 가정이 때로 우리를 한계 짓는다

한 영역에서 오래 일한 분들은 그 업무를 매우 잘 이해하고 전문성이 있음에 틀림없다. 그런데 흥미롭게도 이들 대부분은 더 큰 애벌레가 되는 '변화' 는 훌륭하게 해내지만, 애벌레가 나비가 되는 '변신' 을 생각하는 데 있어서는 매우 힘들어한다.
왜 그럴까?
- 첫쨰, 기존의 '가정' 을 고수하고 있다. 어느 업무나 '이래야 한다' 는 가정이 있다. '서커스는 동물이 있어야 하고, 프라이드 감자는 기름에 튀경야 하고, 음악은 CD 로 들어야 한다' 는 식의 널리 받아들여진 가정이다. 일도 마찬가지 일 것이다. 어떤 것을 가정하고 오랫동안 일 하다보면, 어느새 그 가정을 절대 깨어질 수 없는 '법칙' 이 된다. 이에 그 가정을 넘어서는 생각을 하지 못한다.
- 둘째, '비효율의 숙달화' 이다. 불편하고 비효율적인 일도 자꾸 하다보면 숙달되어 편해진다. 편해지면 그게 바꾸어야 할 것이라는 것을 못 느낀다.
해결 방법은 무엇일까?
- 1. 경험자들은 자신의 눈에 '맹점' 이 있을 수 있다는 것을 인정해야 하고, 자신이 고수하고 있는 가정이 무엇일지 생각해 본다.
- 1. 고객, 외부에서 온 직원, 신입 직원, 외부인들의 관점을 무시하지 말고 들을 필요가 있다.
- 1. 자신과 다른 업종의 혁신을 참조하고, 새로운 관점을 얻기 위해 책을 읽고 공부해라.

좋은 회사란 무엇인가?

아마존에서 10년 이상 근무한 한국 청년이 아마존에 대해 이상적인 좋은 평가를 하지 않았다. 그의 평은 이러했다. '성장할 수 있지만 버터기 힘든 회사, 괴롭지만 배울 점이 있는 곳, 행복하지 않은 곳, 다시 돌아가고 싶지는 않은 곳' 한마디로 말하면 '훈련소' 같은 느낌이다. 만약, 성장을 중요시하는 직원이었다면 이 회사에 대해 반대로 매우 긍정적인 평가를 했을 가능성이 높다.
무엇이 반드시 성공하는 회사 문화라고, 더 좋은 문화라고 단정할 수 없다.
직원은 자신의 철학과 가치에 일치하는 기업을 찾고 선택하고 노력해야 한다. 개인생활과 자유가 중요한 가치인 직원은 그런 철학을 가진 회사에, 훈련과 성장이 중요한 가치인 직원은 그런 철학을 가진 회사에 가는 것이 좋다.
좋은 회사란 남들이 좋다고 하는 회사가 아니라 자신의 가치와 철학에 맞는 회사이다.

모르는 걸 모른다고 말할 용기

마이그크로소프에서는 실패하면 그 직원은 천재가 아니라고 간주하며 낮은 평가를 주거나 해고하는 문화가 있었다. 그래서 이들은 잘 묻지도, 정보를 공유하지도 않았다. 다들 아는체 했다. 실패하거나 모르면 평가절하되기 때문이다.
그리고 목표를 낮게 설정했다. 높게 했다가 멍청이라고 비난을 받기 때문이다. 실패를 두려워하고 작은 성공에 목매고 모르는 것을 두려워했다. 부서 간에 서로 정보를 감추었다. 당연히 회사는 점점 쇠락했다.
새롭게 CEO 로 부임한 시티아 나델라는 이렇게 말했다. "저는 이 기술을 몰라요. 설명을 해주세요" 그러고는 이런 말을 했다. "모른다는 것과 실패 했다는 것은 멍청하다는 의미가 아닙니다. 성장을 의미하는 것입니다. 우리에겐 천재가 필요한게 아니라 서로 협력하는 팀이 필요합니다." 그러자 그동안 천재 흉내를 내었던 임직원들은 실패를 두려워하지 않고 높은 목표를 설정하고 정보를 오픈했다. 모르는 것은 솔직하게 서로 묻고 답했다.
모르는 것은 모른다고 하는 데에는 상당한 용기가 필요하다. 그러니 용기를 내어 솔직하게 말하자. 그리고 배우고 귀 기율여야 한다. 이것은 자신의 무능을 드러내는 것이 아니라 배움과 성장을 만드는 기회이다. '모르는 것을 모른다고 하는 것' 이것이 성장의 출발점이다.

💡 책을 읽으면서 나에게 가장 교훈이 된 것 같다. 난 아직도 모르는 것을 모른다고 잘 말하지 못하고 있다. 나에겐 아직 용기가 없다. 용기를 내어서, 모른다는 것을 솔직하게 말해야 겠다. 모른다는 것은 성장할 수 있는 기회라는 것을 항상 새기고 있자. 모르는 것을 바로 모른다고 용기있게 말하는데는 아직 습관화되기 전까지는 시간이 걸리겠지만, 그 전까지는 천재인척 모르는 것이 없으며 성장하지 않으려는 태도를 보인다면, 그때 내 스스로를 부끄러워 하자.

상대가 진짜 똑똑한지 허풍인지 구별하는 방법

아마존의 제프 베조스는 자신이 같이 일하고자 하는 '똑똑한 사람' 의 기준을 다음과 같이 일한다. '가장 똑똑한 사람들은 끊임없이 자신의 이해를 수정한다. 그들은 이미 해결했던 문제들에 대해서도 다시 고려해본다. 그들은 기존 사고에 대항하는 새로운 관점, 정보, 생각, 모순, 도전 등에 대해 열려있다. 자신의 예전 생각이 잘못되었다면 언제든 바꾼다"
새로운 정보가 들어왔을 때 자신의 기존 의견 및 의사결정을 바꾸는 것을 '자신이 틀렸고 패배했고 어리석었다' 라는 마인드로 생각해버리지 말자.
몰론, 반드시 지켜야 할 가치와 원칙은 흔들리지 않고 고집스럽게 지켜나가는 것이 중요하다. 또한, 자신의 의견을 바꾸라는 것은 아무 생각도 줏대도 없이 남의 말에 혹해서 정신없이 이랬다저랬다 하라는 의미는 아니다. 자신의 의견은 가지고 있되 가정과 사실과 환경이 바뀌면 과감히 변경하라는 것이다.

Spring Batch 개요

Tue, 09 Sep 2025 00:00:00 GMT

회사에서 Spring Batch 를 사용하는데, 아직 이해도가 낮아서 한번 공부해 볼 필요가 있다고 느꼈다. 이번 포스팅에선 스프링 배치를 왜 사용하고, 내부 아키텍처 동작 및 구성방식이 어떻게 이루어지는지에 대해 학습해보도록 한다.

Batch

스프링 배치에 대해 학습하기전에, Batch 라는 그 자체의 개념에 대해 제대로 이해하고 넘어가보자. 종종 애플리케이션에서 필수적인 작업으로 배치 프로세싱이 요구된다. 그런데 여기서, 배치란 무슨 뜻일까? 배치는 집단, 무리, 함께 묶다 라는 뜻을 가진다. 다시 정리하면, 배치는 하나의 큰 무리.집단 단위를 의미하며, 대부분 그 규모가 큰 것들을 뜻한다. 그래서 Batch Job 이라고 하면 개발자가 정의한 작업을 한번에 일괄 처리하는 애플리케이션 Job 이라고 정의할 수 있다.

예를들어, 한 기업에서 할인 이벤트를 매일매일 진행한다고 해보자. 회원가입된 유저 수는 100만건이며, 매일마다 유저들에게 새로운 할인 이벤트 소식을 전달해야한다. 그러면 이 할인 이벤트 소식을 100만건의 유저에게 어떻게 하루마다 매일 보낼 수 있을까?

이 작업은 기존의 일반적인 웹 애플리케이션을 개발.처리하던 방식과는 다른 처리 방식을 가져야한다. 유저와의 상호작용이 없으며, 대용량 데이터, 복잡한 프로세스, 반복적이고 주기적인 프로세스를 가진다는 특징이 있기 때문이다. 이런 상황말고도, 월말 정산을 처리한다거나 따로 적재된 데이터베이스를 통합하는 작업, 은행 점검 상황등이 있을 것이다. 이런 상황에서 처리하면 되는 작업이 바로 배치이다. 배치 Job 은 사용자가 개입하지 않는 환경에서 특정 완료 지점까지 실행된다.

Batch 처리시 고려사항

Batch 가 없는 일반적인 애플리케이션 개발 상황에서는 고려사항이 꽤나 많다. 트래픽 및 리소스 사용률 급증, 보안 검증, 데이터 Validation 처리 등등 그 모든 것들을 유저를 고려한 소프트웨어 개발이 필요하다.

그와 달리 배치는 위 사항들을 고려할 필요가 없다. 즉, 배치를 사용.처리하는 상황에서는 유저를 고려한 설계.개발 처리가 필요 없다는 것이다. 배치를 사용할 때는 확실한 로그와 피드백용 알림만을 사용해서 정확하게 에러를 인지하고, 복구.처리하는 것에만 집중하면 된다. 몰론 보안이나 데이터 유효성을 처리하기야 해야 겠지만, 트래픽 사용량이나 사용자 중심의 에러 처리를 고려하지 않아도 된다는 뜻이다.

Spring Batch

Spring Batch 는 Enterprise 시스템의 일상적인 운영에 필요한 배치 애플리케이션을 쉽게 개발할 수 있도록 구현된 라이브러리이다. 제공하는 기능으로는 크게 로깅/추적, 트랜잭션 관리, 작업 처리 통계, 작업 플로우 지정(작업을 재시작하거나 스킵), 리소스 관리 등 대량으 레코드를 처리 하는데 필수적인 기능을 재사용 가능한 형태로 제공한다.

여기서 주목할 점은, 재사용 가능하다는 점이다. 1달에 1번씩 필요한 배치 프로세스를 오늘 개발한 뒤에, 다음 달에 다시 자동으로 배치 프로세스를 돌릴 수 있다는 뜻이다. 또한 스프링 배치는 Java 기반 Configuration 이 가능하며, XML 없이도 POJO 기반 개발 접근 방식으로 개발 가능하다.

vs Quartz, Schduler

나도 혼동된 개념이지만, Quartz 나 스케줄러와 같은 개념들과 Spring Batch 의 차이점이 햇갈릴 수 있다. Quartz 는 Job Scheduling 라이브러리로, 비교적 단순하거나 소규모 데이터를 스케줄링하며 처리하는데 적합하다. 즉, Quartz 의 경우는 작은 단위의 데이터를 요구하는 스케줄러만으로 작업이 가능한 범위를 처리 가능하다.

반면 Spring Batch 는 스케줄러를 대체하는 개념이 아니라, 스케줄러에 의해서 동작될 수 있는 개념으로 이해하는 것이 좋다. 스케줄러가 Trigger 되어서 제작한 Spring Batch 를 동작시키도록 한다. 또한 Spring Batch 는 대용량 데이터 처리에 적합하며, 기록 관리.대시보드등의 복잡한 기능까지 함께 제공받고 처리하는데 용이하다.

Spring Batch 아키텍처

스프링 배치는 Layered 아키텍처를 취하며, 크게 3개의 Layer 로 구성된다. Application, Core, Infrastructure 3개의 Layer 컴포넌트가 있다. Application 은 스프링 배치를 사용하는 개발자가 만드는 모든 배치 Job 과 커스텀 코드를 포함한다. Core 는 Job 을 실행하고 제어하는데 필요한 핵심 Runtime 클래스를 포함한다. 각각에 대해 더 자세히 알아보자.

Application

가장 바깥쪽을 보면 Application Layer 가 존재한다. 개발자가 구성한 배치 처리에 사용되는 코드나 컴포넌트가 이 계층에 포함된다. 즉, 스프링 배치 프레임워크를 통해 개발자가 만든 모든 배치 Job 과 커스텀 코드가 이 Layer 에 포함된다. 비즈니스 로직이나 서비스, 또는 Job 구조화와 관련된 내용이 Application 계층에 포함된다고 할 수 있다. 개발자는 이 Application Layer 에서 배치 프레임워크를 활용한 비즈니스 로직 구현에만 집중하고, 배치 관련 기반 기술들은 프레임워크가 내부적으로 담당하고 동작하도록 위임한다.

개발자가 배치를 위해 짜놓은 대부분의 코드가 Core 계층과 함께 동작하는 Application 계층에 있지만, 위 그림은 종종 Reader 나 Writer 를 커스텀하여 Core 또는 Infrastructure 의 일부를 만들기도 하기 때문에, Core 와 Infrastructure 를 감싸도록 표현했다.

Core

배치 Core 에는 배치 작업을 시작하고 제어하는데 필요한 핵심 클래스가 포함되어 있다. Job 을 실행, 모니터링, 관리하는 API 가 이 Layer 안에 담겨있다. Job, Step, Flow, JobLauncher, JobParameters 구현체가 포함된다.

Infrastructure

어떤 처리를 수행하려면 파일, 데이터베이스 등으로부터 읽고 쓸 수 있어야 할 것이다. 또한, Job 수행에 실패한 이후 재시도 처리할 때 어떤 일을 수행하며 재시도할지를 다룰 수 있어야 할 것이다. 이 기능을 가능케 하는 계층이 Infrastructure 계층이다. 애플리케이션 개발자가 코어 프레임워크 자체 두 계층에서 사용할 수 있는 기능들을 제공한다. 정리하자면, Job 실행의 원활한 흐름과 처리를 위한 틀을 제공하는 Layer 이다.

예를들어 개발자가 사용할 수 있는 ItemReader 와 ItemWriter 와 같은 Reader 나 Writer 가 포함되어 있으며, 코어에서 사용할 수 있는 기본 Reader 나 Writer 와 RetryTemplate 과 같은 서비스가 포함된다.

Batch 아키텍처

Spring Batch 의 배치 작업에서 사용되는 핵심 개념들에 대해 살펴보도록 한다. 각각의 개념 및 용어를 살펴보기전에, 우선 Batch 아키텍처를 살펴보자.

위 다이어그램은 스프링 배치의 핵심 개념을 도메인 언어로 나타내고 있다. Job 은 하나 이상의 Step 을 가질 수 있고, 각각의 Step 은 ItemReader, ItemProcessor, ItemWriter 를 단 하나씩만을 가지며, 현재 프로세스에서 필요한 메타정보들은 JobRepository 에 저장된다. 위 아키텍처를 더 자세히 뜯어보면 아래와 같다.

Batch 아키텍처에 등장하는 각 컴포넌트의 개념에 대해 학습해보자.

Job

Job 이란 배치 처리 과정들을 하나의 단위로 만들어 놓은 객체이다. 또한 배치 처리 과정에 있어서 전체 계층 최상단에 위치하고 있다. 또한 Job 은 여러개의 Step 단계별로 나누어진 Step 들을 묶어놓은 논리적인 하나의 배치 처리 단위라고도 정의할 수 있다. 즉, Job 은 그 안에서 여러개의 Step 단계별로 나뉜다.

JobInstance

JobInstance 는 Job 의 실행 단위를 나타낸다. Job 을 실행시키게 되면 하나의 JobInstance 가 생성된다. 예를들어 10월 1일 실행, 10월 2일 실행을 하게되면 각각의 JobInstance 가 생성되며, 10월 1일 실행한 JobInstance 가 실패하여 다시 실행을 시키더라도 이 JobInstance 는 10월 1일에 대한 데이터만 처리하게 된다.

JobParameters

앞서 JobInstance 는 Job 의 실행 단위라고 했다. 그렇다면 각각의 JobInstance 는 어떻게 구별할까? 이는 바로 JobParameters 객체로 구분하게 된다. 즉, JobParameters 는 JobInstance 의 구분.식별자로, 보통 날짜 형식으로 식별자를 만들 수 있다.

JobParameters 는 JobInstance 의 식별자 역할 외에도 개발자 JobInstance 에 전달되는 매개변수 역할도 하고있다. 또한 JobParameters 는 String, Double, Long, Date 와 같은 4가지의 형식만을 지원하고 있다.

JobExecution

JobExecution 은 JobInstance 에 대한 실행 시도에 대한 객체이다. 1월 1일에 실행한 JobInstance 가 실패하여 재실행을 하여도, 동일한 JobInstance 를 실행시키지만 이 각각의 실행에 대한 JobExecution 은 개별로 생성된다. JobExecution 은 이러한 JobInstance 실행에 대한 상태, 시작시간, 종료시간, 생성시간 등의 정보를 담고있다.

Step

Step 은 Job 의 배치 처리를 정의하고 순차적인 단계를 캡슐화한다. 즉, Step 은 Job 내부적으로 순차적인 세부 단계를 정의하는 각각의 논리적인 단위이다. Job 은 최소한 1개 이상의 Step 을 가져야 하며 Job 의 실제 일괄 처리를 제어하는 모든 정보가 들어있다.

StepExecution

StepExecution 은 JobExecution 과 동일하게 Step 실행 시도에 대한 객체를 나타낸다. JobExecution 이 Job 을 위한 객체였다면, StepExecution 은 Step 을 위한 객체인 것이다. 하지만 Job 이 여러개의 Step 으로 구성되어 있을 경우, 이전 단계의 Step 이 실패하게 되면 다음 단계가 실행되지 않음으로 인하여, 실패 이후의 StepExeution 은 생성되지 않는다.

StepExecution 또한 JobExecution 과 동일하게 실제 시작이 될 때만 생성된다. StepExectuion 에는 JobExecution 에 저장되는 정보외에 Read 수, Write 수, Commit 수, Skip 수 등의 정보들도 저장이 된다.

ExecutionContext

ExecutionContext 란 Job 에서 데이터를 공유할 수 있는 데이터 저장소이다. Spring Batch 에서 제공하는 ExecutionContext 는 JobExecutionContext, StepExecutionContext 2가지 종류가 있으나, 이 2가지는 지정되는 범위가 다르다. JobExecutionContext 의 경우 Commit 시점에 저장되는 반면, StepExecutionContext 는 실행 사이에 저장이 된다. ExecutionContext 를 통해 Step 간에 데이터 공유가 가능하며, Job 실패시 ExecutionContext 를 통한 마지막 실행 값을 재구성 할 수 있다.

JobRepository

JobRepository 는 앞서 말한 모든 배치 처리 정보를 담고있는 일종의 저장소이다. Job 이 실행되면 JobRepository 에 JobExecution 과 StepExecution 을 생성하게 되며, JobRepository 에서 Execution 정보들을 저장하고 조회하며 사용하게 된다.

JobLauncher

Job 과 JobParameters 를 사용하여 Job 을 실행하는 객체이다.

ItemReader

ItemReader 는 Step 에서 Item 을 읽어오는 인터페이스이다. ItemReader 에 대한 다양한 인터페이스가 존재하며, 다양한 방법으로 Item 을 읽어올 수 있다.

ItemWriter

ItemWriter 는 처리된 데이터를 Write 할때 사용한다. Writer 는 처리 결과물에 따라 Insert 가 될 수도, Update 가 될 수도, 또는 Queue 를 사용한다면 Send 가 될 수도 있다. Writer 또한 Read 와 동일하게 다양한 인터페이스가 존재한다. Writer 는 기본적으로 Item 을 Chunk 로 묶어서 처리한다.

ItemProcessor

ItemProcessor 는 Reader 에서 읽어온 Item 을 데이터를 처리하는 역할을 한다. Processor 는 배치를 처리하는데 필수 요소는 아니며, Reader, Writer, Processor 처리를 분리하여 각각의 역할을 명확하게 구분하고 있다.

마치며

다음 포스팅에선 Spring Batch 를 직접 코드로 작성하며, 더 높은 이해도를 갖고 Batch 를 다루어볼까 한다.

참고

Spring Cloud 란 무엇이고, 왜 사용하는걸까?

Thu, 04 Sep 2025 00:00:00 GMT

MSA 환경에서 Spring Cloud 의 필요성

MSA 는 단일 애플리케이션을 작은 서비스 단위로 분할하여 개발, 배포, 확장을 용이하게 하는 아키텍처이다. 이러한 MSA 환경에서 각 마이크로 서비스들은 독립적으로 운영되며, 서로 유기적으로 협력하여 전체 시스템을 구성한다. Spring Cloud 는 바로 이러한 MSA 환경에서 각 서비스들이 유연하게 통신.동작할 수 있도록 기능을 제공하는 라이브러리이다.

Spring Cloud 란?

Spring Cloud 는 MSA 를 구현하는데 필요한 다양한 도구와 라이브러리를 제공하는 프레임워크이다. 즉, MSA 환경 구성시 개발, 빌드, 배포, 운영에 필요한 내용들을 쉽게 구성할 수 있도록 도와주는 라이브러리이다. 이를 통해 MSA 환경에서 각 서비스간의 통신, 설정관리, 부하 분산, 서킷 브레이커등 여러 문제를 해결할 수 있다. 더 자세히 어떤 기능을 제공하는지 살펴보자.

Spring Cloud 주요 기능

Spring Cloud 에서 제공하는 기능은 매우 다양하다. 그 중에 가장 핵심 기능에 대해서만 우선 다루고, 아래에서 상세 기능들 각각을 더 자세히 다루어볼까 한다.

중앙화된 구성(설정) 관리

Spring Cloud 는 Spring Cloud Config 라는 솔루션을 제공하여, 애플리케이션의 설정.구성 내용을 중앙에서 관리할 수 있는 기능을 제공한다. 마이크로 서버는 환경에 따라 다른 설정을 필요로 하며, 이런 설정을 일괄적으로 중앙화된 한 곳에서 관리하는 것이 복잡성이 줄어들 것이다.

Spring Cloud Config 를 사용하면 중앙에서 설정을 관리하고, 각 서비스가 변경된 설정을 실시간으로 반영할 수 있도록 해준다. 이를 통해 개발자는 환경 설정 변경으로 인한 문제를 최소화하고, 더 집중적으로 애플리케이션 개발에 집중할 수 있다.

서비스 디스커버리(Service Discovery)

MSA 환경에서는 서비스가 동적으로 배포되고 확장되므로 각 서비스의 위치(IP, 포트) 를 고정할 수 없다. 즉, 각 서비스는 위치값이 동적으로 계속 변한다. 이를 해결하기 위해 Spring Cloud 는 Eureka 와 같은 Service Discovery 솔루션을 제공하여, 각 서비스가 중앙 레지스트리에 자신의 정보를 등록하고 다른 서비스가 이를 동적으로 검색할 수 있도록 기능을 지원해준다.

즉, 각 마이크로 서비스가 네트워크 상에서 서로를 자동으로 찾고 통신할 수 있게 해준다. 이를 통해 서비스간의 유연한 통신.확장성을 갖게 해주며, 마이크로 서버으 위치(IP, Port)가 동적으로 변하는 환경에서도 유연하게 동작할 수 있도록 해준다.

로드밸런싱(부하 분산)

서비스 간에 호출이 발생할 때, 트래픽을 여러 인스턴스에 효율적으로 분산하는 것이 필수이다. Spring Cloud 는 Ribbon 과 같은 클라이언트 사이드 로드밸런서를 제공하여, 서비스간 부하를 자동으로 분산시켜서 시스템의 안정성을 높인다.

장애 대응과 회복력(Fault Tolerance) - 서킷 브레이커

MSA 환경에서는 개별 서비스에 장애가 터질 가능성이 높다. Spring Cloud 는 Hystrix 를 통해 서킷 브레이커(Circuit Breaker) 패턴을 지원하여, 장애가 발생했을 때 빠르게 감지하고 대체 경로를 활용하여 시스템의 안정성을 확보한다.

Spring Cloud 에서 제공하는 서킷 브레이커는, 특정 기준에 따라서 실패한 서비스 API Call 을 자동으로 중단시키고, 시스템이 장애를 우회하고 계속해서 작동할 수 있도록 한다. 이 덕분에 서비스 간의 장애 전파 및 의존성을 최소화할 수 있게된다.

API Gateway

마이크로 서비스를 클라이언트에게 노출할 때, 단일 진입점(Entry Point) 를 제공하는 것이 효율적이고,좋다. Spring Cloud 는 Zuul 과 Spring Cloud GW 를 통해 API Gateway 역할을 수행하며, 요청, 라우팅, 인증, 로깅 등 다양한 기능을 제공한다.

분산 트레이싱(Distributed Tracing)

MSA 환경에서는 요청이 여러 서비스에 걸쳐 분산되어 처리되므로, 장애 분석과 성능 최적화에 어려움이 따른다. Spring Cloud는 Sleuth 와 Zipkin을 이용하여 분산 로그 추적 기능을 제공함으로써 요청의 흐름을 시각적으로 분석하고 문제 발생 시 원인을 파악하는 데 도움을 준다.

Spring Cloud 의 주요 모듈

앞서 Spring Cloud 에서 제공해주는 여러 모듈.툴을 통해 서비스 디스커버리(Service Discovery), API 게이트웨이, 로드밸런싱, 중앙화된 설정.구성 관리, 서킷 브레이커, 분산 트레이싱 등의 기능을 제공받을 수 있음을 알게 되었다. 그렇다면 Spring Cloud 내에서 제공하는 각 기능은 어떤 툴에서 제공하는지에 대해 살펴보자.

Spring Cloud 에서 제공하는 모든 모듈을 다루지는 않겠다.

서비스 디스커버리

(1) Spring Cloud Netfix Eureka : 서비스 인스턴스 등록 및 검색을 위한 서비스 디스커버리 서버를 제공하는 툴이다. 각 서비스는 Eureka 서버에 자신의 위치를 등록하고, 다른 서비스의 위치 정보를 조회할 수 있다.
(2) Spring Cloud Zookeeper : ZooKeeper 를 기반으로 서비스 디스커버리 기능을 제공한다.

API Gateway

(1) Spring Cloud Gateway : 동적 라우팅, 필터링, 인증, 권한 부여 기능을 제공하는 고성능 API 게이트웨이이다.
(2) Spring Cloud Netfix Zuul : (Deprecated 된 기능이다.) 라우팅 및 필터링 기능을 제공한다.

중앙화된 설정.구성 관리

(1) Spring Cloud Config : Git 레포지토리, SVN, 로컬 파일 시스템과 같은 외부 레포지토리로부터 설정.구성 정보를 가져와서 서비스에 적용한다. 설정 정보 변경 내용은 실시간으로 즉시 적용된다.

로드밸런싱

(1) Spring Cloud Load Balancer : 서비스 디스커버리와 연동하여 Client-Side 로드밸런싱 기능을 제공한다.
(2) Spring Cloud Netfix Ribbon : (Deprecated 되었다) Client-Side 로드밸런싱 기능을 제공한다. Spring Cloud Load Balancer 로 대체되는 추세이다.

서킷 브레이커

(1) Spring Cloud Circuit Breaker : 서비스 장애가 터졌을 떄, 해당 서버로의 요청을 차단하고 FallBack 처리를 한다. Resilience4j 를 기반으로 구현되었다.
(2) Spring Cloud Netfix Hystrix : (Deprecated) 마찬가지로 서킷 브레이커 기능을 제공하지만, Deprecated 되었다.

분산 트레이싱

(1) Spring Cloud Sleuth : 서비스 간 호출 흐름을 추적하야 장애 원인을 찾아내는데 도움을 준다. 관련 기술로는 Span, Trace, OpenTelementry, Zipkin, Jager 등이 있다.

위와 같은 기능 및 모듈외에도 Spring Cloud 에선 다양한 모듈을 통해 여러가지 기능을 제공한다. 비동기 메시징, 함수형 프로그래밍, 보안, 클라우드 연동 , REST Client, 배치 처리 등을 제공한다.

참고

카프카 기본 스택 및 아키텍처 살펴보기

Mon, 18 Aug 2025 00:00:00 GMT

회사에서 카프카를 사용한다. OJT 를 듣고, 커뮤니케이션을 할때 카프카의 특징을 학습해두면 큰 도움이 될 것이라는 생각이 들었다. 이번 글에서는 카프카를 왜 사용하며, 어떤 특징이 있는지와, 간단한 내부 아키텍처에 대해 학습해보도록 한다. 참고1 을 통해서 빠르게 학습을 해보도록 한다.

메시지 큐와 MOM

메시지 큐를 사용하면 발신자와 수신자가 서로를 직접 참조하지 않고 메시지 큐를 통해서 통신한다. 즉, 서로를 직접 알 필요가 없기 때문에 (1) 느슨한 결합(decoupling) 관계를 만들어낼 수 있다. 발신자와 수신자는 서로가 의존하지 않으므로 독립적으로 확장(Scale Out) 할 수 있다. N:1:M 의 형태로 발신자, 수신자 사이에 메시지 큐가 메시지를 중개하기 때문이다. 이 덕분에 MSA 환경에서 메시지 큐는 빛을 발한다. 각 마이크로 서버는 메시지 큐를 활용하여 간접적으로 통신하고, 서로에게 미치는 영향을 최소화하며, 독립적으로 확장할 수 있기 때문이다.

또한 메시지 큐는 발신자(producer)가 발행한 메시지가 소비자(consumer) 에게 반드시 전달된다는 (2) 보장성 을 갖는다. 즉, 메시지는 유실되지 않는다. 이 덕분에 MSA 환경에서 각 마이크로 서버가 메시지 및 데이터 유실없이 안전하게 통신할 수 있음을 보장받게 된다.

또한, 메시지 큐를 사용하면 (3) 비동기 통신(asynchoronous) 를 구현할 수 있다. 만약 MSA 환경에서 마이크로 서버 A 와 B 가 통신하는 상황을 가정해보자. A 가 B 를 HTTP 통신을 통해 Request 를 날리는 경우에, 만약 메시지 큐가 없더라면 어떻게 될까? A 는 B 가 해당 Request 를 처리하고 동기적으로 Response 를 받을 때 까지 무한정 대기해야한다. 즉, 동기적 통신으로 인하여 A 는 B 에 대한 의존성이 커진다.

반대로 A 가 메시지를 메시지 큐에 발행하고, B 가 해당 메시지를 컨슘한다면? 즉, 비동기적으로 통신이 이루어진다면 어떻게 달라질까? 비동기 통신 덕분에 B 는 A 의 처리가 완료되기 전까지 대기하지 않아도 된다. B 는 다른 테스크를 수행하다가 메시지 큐로 부터 메시지가 발행되었다는 알림을 받을 때가 되었을 때, 상황에 알맞게 메시지를 꺼내오면 된다.

이러한 특성 덕분에 메시지 큐는 이미지 프로세싱, Batch 처리와 같이 매우 무거운 작업을 처리하거나, 혹은 이벤트 드리븐 아키텍처에서 이벤트가 발생헀음을 알리기 위한 용도로 사용하기 적합하다.

MQ 의 모델 : Point to Point 와 Pub/Sub

메시지 큐는 크게 Point to Point(P2P) 와 Pub/Sub 모델 2가지로 구분할 수 있다. P2P 모델은 한 대의 발신자가 한 대의 수신자에게 메시지를 보내는 방식이다. 즉, 메시지 전송 대상이 한 대로 고정되어 있다. 반면 Pub/Sub 모델은 발신자가 토픽(topic) 이라고 불리는 공간에 메시지를 전송하면, 그 토픽(topic) 을 구독하고 있는 수신자 모두 메세지를 수신하는 방식이다. 즉, 전송 대상이 다수이다.

그리고 MOM(Message Oriented Middleware) 이라고 하면 일반적으로 Kafka, RabbitMQ, ActiveMQ 를 뜻한다. Redis 는 Pub/Sub 을 지원하긴 하지만, MOM 으로는 부르지 않는다. 그리고 RabbitQMQ 와 ActiveMQ 는 P2P 와 Pub/sub 모델을 함께 지원하는 반면에, Kafka 는 Pub/Sub 모델만을 지원한다.

카프카

카프카는 RabbitMQ, ActiveMQ 대비 높은 확장성과 내결함성, 대용량 데이터 처리, 실시간 데이터 처리에 특화되어있는 메시징 시스템이다. 카프카는 어떤 문제를 해결하기 위해 등장했을까? 아래 그림은 카프카 등장 이전의 일반적인 대규모 아키텍처이다. 각 서비스 또는 데이터 저장소가 End-To-End 로 연결되어 아주 복잡하고, 의존.참조 관계를 파악하기 힘든 구조를 가지고 있다.

이렇듯 카프카가 없는 구조는 무엇이 문제가 될까? 당연하게도, 시스템을 확장하기 어려운 구조가 된다. 앞서 설명했듯이, 메시지 큐가 없다면 (1) 강한 의존성 이 생기고, (2) 동기적 통신(synchoronous) 이 발생하기 때문이다. 또한 앞선 그림처럼 (3) 복잡한 참조.의존관계 를 가지게 된다.

반면 카프카를 도입하면 위처럼 시스템 아키텍처가 매우 단순해진다. 모든 이벤트와 데이터 흐름이 카프카에 중앙화되어 있다. 생산자(Producer) 는 이벤트 및 데이터를 카프카에 발행한다. 그리고 해당 이벤트 및 데이터를 필요한 곳(컨슈머) 에서 가져다 쓴다.

예를들어 카카오 모행 서비스가 MSA 로 전환되고, 카프카를 도입하는 상황을 가정해보자. 사용자가 여행지 정보를 조회할 경우 여행지 조회 마이크로 서버로 Request 를 날려서 여행지 정보를 조회할 수 있을 것이다. 동시에 해당 마이크로 서버는 여행지가 클릭되었다는 메시지를 카프카로 전달한다. 이후 해당 메시지를 여행지 추천 시스템 마이크로 서버가 컨슘하여, 회원에게 어떤 여행지를 향후에 추천할지 정보를 최신화한다. 동시에 Logstash(로그 수집기) 또한 해당 메시지를 컨슘하여 개발자가 디버깅하기에 용이하도록 로그를 생성해둔다.

만약 카프카가 없었더라념 각 서버의 통신은 어떻게 이루어졌을까? 여행지 조회 서비스가 추천 서버, Logstash 서버에게 각각 다른 데이터 파이프라인을 통해서 데이터를 전송해야 했을 것이다. 여기서 마이크로 서버가 더욱이 증설 된다면, 의존관계가 더욱이 복잡해 질 것이다. 이에 반해 카프카를 사용하여 데이터 흐름을 중앙화한하면, 복잡도와 성능이 극명히 개선될 것이다.

카프카의 특징 (vs. 다른 MOM)

그렇다면, 카프카가 다른 MOM 와 다르게 갖는 특징이 무엇일까?

높은 처리량(throughput) 과 낮은 지연시간(latency) : 카프카는 대용량 데이터를 실시간으로 처리할 수 있도록 설계되었다. 따라서 높은 TPS 처리량을 가지며, 실시간 스트림, 로그 집계, 이벤트 드리븐 아키텍처 구현에 적합하다.
메시지 내구성 (비휘발성) : 카프카의 메시지는 휘발되지 않는다. 카프카의 메시지느 메모리가 아닌 디스크에 영구 저장된다. (이와 달리 Redis Pub/Sub 은 메시지가 디스크에 저장되지 않고, 구독자에서 장애가 터지면 메시지가 유실된다.) ActiveMQ, RabbitMQ 모두 디스크에 메시지를 영구 저장하는 옵션도 지원하지만, 기본적으로는 컨슘된 메시지를 유실된다. 반면, 카프카는 기본적으로 모든 메시지를 (이미 컨슘된 메시지까지) 디스크에 영구 저장한다.
분산 아키텍처 : 카프카는 카프카 클러스터 내부에 여러대의 브로커(broker) 서버를 구성하여, 높은 확장성과 내결함성(Fault Tolerance) 을 갖는다. 이는 RabbitMQ, ActiveMQ 와 비교했을 떄 카프카만이 갖고 있는 차별점이다.
Pull 기반 메시지 소비 : RabbitMQ 와 ActiveMQ 는 브로커가 컨슈머로 메시지를 Push 하는 방식인데 비해, 카프카는 컨슈머(consumer)가 능동적으로 알아서 브로커로부터 메시지를 가져오는 Pull 방식을 취했다. 이 덕분에 컨슈머(consumer)는 본인의 처리 능력에 따라서 메시지를 컨슘할 수 있기 때문에, 브로커 처리 능력에 연연하지 않고 본인만의 최적의 성능을 낼 수 있다.

카프카 아키텍처

카프카 클러스터(kafka Cluster) : 하나 이상의 카프카 브로커들의 집합이다. 카프카는 확장성과 내결함성을 위해 브로커들을 클러스터로 구성한다.
브로커(broker) : 브로커는 개별 카프카 서버이다. 브로커는 프로듀서로부터 메시지를 전달받아서 토픽(topic) 에 저장하고, 컨슈머에게 전달하는 역할을 한다. 브로커는 여러개의 토픽을 가질 수 있다.
토픽(topic) : 토픽은 데이터가 저장되는 단위라고 할 수 있다. 마치 데이터베이스에서 테이블(Table) 과 거의 똑같은 개념이다. 토픽은 이름으로 식별되며, 토픽에 한번 추가된 데이터는 수정될 수 없다.
파티션(partition) : 카프카의 확장성을 위해서 토픽은 1개 이상의 여러 파티션으로 나뉠 수 있다. 레코드에 키가 없다면 라운드 로빈으로 파티션에 나뉘어 저장되고, 같은 키를 가진 레코드는 같은 파티션에 저장된다.
- 파티션의 내부 구조는 Queue 구조로 이루어져 있다. 다시말해, FIFO 의 특징을 갖는다.
- 컨슈머는 파티션에 적재된 데이터를 가져가더라도, 파티션에 적재된 삭제가 되지 않는다. 즉, 컨슈머는 파티션에서 이미 가져온 데이터를 또 다시 가져가는 것도 가능하다. (몰론, 어떤 특정 컨슈머가 어떤 데이터까지 읽었는지는 내부적으로 기록을 하고 있다. 이렇게 어디까지 레코드를 읽었는지 기록하는 행위를 '커밋' 이라고 한다. 컨슈머는 레코드를 읽어온 뒤 커밋을 하고, 앞서 커밋한 내용을 기반으로 어디서부터 새로운 레코드를 읽어와야 하는지 정보를 가져온다.)
오프셋(offset) : 파티션에 저장된 레코드는 증가하는 정수 ID 값을 갖고, 이 정수 ID 를 오프셋이라고 부른다. 오프셋은 0부터 시작하며, 레코드가 파티션에 저장될 떄 마다 시퀀셜하게(순차적으로) 증가한다. 특정 파티션의 각 레콤드는 고유한 오프셋을 갖지만, 서로 다른 파티션 간에는 고유하지 않다. 파티션에서 데이터를 읽을 때 작은 것부터 큰 순서대로 읽는다.
레코드(record) : 파티션에 저장되는 데이터이다. Key, Value, TimeStamp, Compression Type, Optional Headers, Partition and Offset Id 로 구성된다.
프로듀서(producer) : 카프카에 요청하여 토픽에 레코드는 추가하는 클라이언트이다. 카프카의 구성 요소가 아니며, 카프카 외부에서 카프카에게 Request 하는 애플리케이션이다.
컨슈머(consumer) : 하나 이상의 파티션과 토픽으로부터 레코드를 읽어오는 클라이언트이다. 기본적으로 사용 가능한 가장 낮은 오프셋부터 높은 오프셋까지 순서대로 레코드를 읽어온다. 하나의 토픽의 여러 파티션으로부터 레코드를 읽어올 때는 순서가 보장되지 않는다. 파티션 0, 1, 2 로 부터 레코드를 읽어올 떄 파티션 0의 레코드만 바라봤을 때는 순서가 보장되지만, 읽어온 전체 레코드를 바라볼 때는 파티션 0 ~ 2 의 레코드가 순서와 상관없이 섞여있을 수 있다.
컨슈머 그룹(consumer group) : 동일한 컨슈머 인스턴스를 여러개 생성하여 컨슈머 그룹을 구성할 수 있다. 컨슈머 그룹을 구성하는 여러 컨슈머는 동일한 토픽의 각자 다른 파티션을 도맡아 메시지를 컨슘할 수 있다. 예를들어 토픽 A 에 파티션이 0, 1, 2 가 생성되어 있고, 컨슈머 그룹 A 에 컨슈머 a, b, c 가 있다고 가정하자. 이 경우 컨슈머 a 는 파티션 0을, 컨슈머 b는 파티션 1을, 컨슈머 c는 파티션 2를 컨슘한다.

참고

ELK Stack 전반 개요 살펴보기

Sun, 17 Aug 2025 00:00:00 GMT

회사에서 ELK 스택을 통해 애플리케이션을 로깅하고, 애러를 검출하고 있다. ELK 스택에 관련한 설명을 들을 때 기술에 대한 이해도가 낮아서 학습의 필요성을 느끼게 되었다. ELK 스택에서 각각의 컴포넌트가 어떠한 역할을 수행하며, 데이터가 어떻게 흐르고, 처리되고, 검색되고, 저장되고, 시각화 되는 것인지 전반 개요를 간단히 살펴봐야 겠다는 생각이 들었다.

이번 포스팅에서는 ELK 스택 하나하나에 대한 기술을 깊게 공부하는 목적 보다는, 어떤 역할을 수행하고, 어떤 데이터 처리 흐름을 수행하는 것인지 개요를 학습해보도록 한다. 또한 참고1 을 다수 참고.인용하여 빠르게 학습을 해보도록 하겠다.

로그는 왜 필요할까?

ELK 스택은 로그 수집, 처리 및 분석에 사용되는데, 왜 로그를 수집하고 처리하는 것일까? 그 이유를 정리해보자면 다음과 같다.

장애시 원인 파악 : 로그를 분석하여 장애가 터진 경우 빠르게 원인을 파악하고 해결할 수 있다. 비슷한 원리로, 대용량 배치 작업의 경우 작업 개수가 굉장히 많고 오랜 시간이 걸릴텐데, 전체 배치 작업 중에 실패한 작업에 대해 로깅을 하여 원인을 파악하고 복구하기가 쉬워진다.
사용자 패턴 분석 : 이슈가 발생하여 CS 가 인입되었을 때를 대응하기 위해서, 해당 사용자가 어떤 액션을 취했는지, 어떤 데이터가 요청되었는지를 확인할 필요가 있다.
시스템내 성능.병목.취약 구간 파악 : 사용자의 Request 가 들어오고 Response 가 나가기까지의 시간을 기록하여, 시스템내 성능 저하 및 병목 구간을 파악할 수 있다.

ELK 스택 기반 아키텍처

ELK 는 Elastic Search, Logstash, Kibana 를 합친 약자로, 로그 데이터를 수집하고 분석하는 도구 모음을 뜻한다. 여기에 Beats 라는 경량 데이터 수집 도구가 추가되어서, 이를 묶어 ELK Stack 이라고 부른다. Elastic Search 는 검색 엔진, Logstash 는 데이터 처리 파이프라인 도구, Kibana 는 데이터 시각 대시보드, Beats 는 경량 데이터 수집기이다. 그렇다면 ELK 스택에서 데이터는 어떻게 발생하고, 흐르고, 처리되고, 저장되며, 검색되고, 시각화되는 것일까?

💡 에이전트(Agent) 란? : 시스템에서 특정 작업을 수행하도록 설계된 SW 프로그램이다. 일반적으로 백그라운드에서 실행되고, 사용자의 개입없이 자동으로 특정 데이터를 수집하거나 작업을 처리한다.

(1) Beats 는 로그 또는 메트릭이 발생하는 서버에 에이전트로 설치되어 데이터를 수집하고, 이 데이터를 LogStash 로 전송한다. 위 다이어그램에는 Beats 는 LogStash 사이에 메시지 큐가 위치하는 것을 확인할 수 있는데, 이는 안정성 또는 확장성 등을 위함이다.
(2) Beats (혹은 메시지 큐) 로 부터 데이터를 전달받은 LogStash 는 데이터를 적절히 필터링 및 가공하여 Elastic Search 로 전달한다.
(3) LogStash 로 부터 데이터를 전달받은 Elastic Search 는 데이터를 굉장히 빠른 속도로 검색될 수 있도록 역 인덱싱(Inverted Indexing)한다.
(4) Kibana 는 REST API 를 통해 Elastic Search 로 부터 데이터를 가져와서 유저에게 시각화와 간편한 데이터 검색 기능등을 제공한다.

Elastic Search

💡 Elastic Search 에 대한 자세한 내용은 Elastic Search 역 인덱스(Inverted Index) 구조 살펴보기 에서 다룬적이 있으니 참고하자.

ELK 스택은 Elastic Search 로 부터 시작된다. Elastic Search 는 Lucene 기반 검색엔진 (경우에 따라 NoSQL DB 로 분류하기도 한다) 이며, 대용량 데이터를 빠르게 저장하고 검색할 수 있게 해주는 툴이다. 데이터를 빠르게 검색하기 위해 역 인덱싱(Inverted Indexing) 하여 저장한다. 역 인덱싱과 관련한 내용은 위 포스팅에서 다룬적이 있으므로 생략한다.

Elastic Search 는 클러스터 구조로 분산되어 구성되어 있다. 이 덕분에 높은 가용성과 확장성이라는 특징을 갖는다. 또한 일반적인 관계형 DB 와 다르게 SQL 을 지원하지 않고, REST API 를 통해서 데이터를 추가하고 검색해야 한다. SQL 의 SELECT, INSERT, UPDATE, DELETE 명령은 REST API 기반의 Elastic Search 에서 GET, POST, PUT, DELETE 에 대응된다.

관계형 DB 의 데이터베이스, 테이블, row, 컬럼, 스키마는 각각 Index, Type, Document, Field, Mapping 에 대응된다.

또한 엘라스틱 서치는 일반 관계형 DB 와 다르게 JOIN 절을 지원하지 않고, 트랜잭션을 지원하지 않는다는 점이 단점이 될 수 있겠다.

LogStash

Elastic Search 를 사용하면서 데이터를 손쉽게 수집할 방법이 필요해졌다. 따라서 데이터 처리 파이프라인 툴인 LogStash 가 등장했다. LogStash 는 Input, Filter, Output 순서로 데이터를 수집하고, 가공하고, 전달한다.

Input

Logstash 는 다수의 데이터 소스로부터 동시에 로그 또는 메트릭 데이터를 수집한다. 수집하는 데이터 소스는 Beats, File, TCP, HTTP, Kafka, Redis 등이 있다.

Filter

Logstash 는 Input 를 Output 로 변환하는 사이에 데이터를 Filter 하는 과정을 거치는데, Filter 과정을 통해 아래와 같은 일을 수행할 수 있다. Filter 란 Input 데이터를 필터링하거나, 원하는 형식으로 가공하는 작업이다.

grok 플러그인을 사용해서 정규 표현식을 통해 비정형 데이터로부터 구조를 도출해낼 수 있다.
IP 주소로부터 위치 자표를 얻어올 수 있다.
개인 식별 정보를 익명화하거나 완전히 제거할 수 있다.

위와 같은 데이터 가공.필터링 작업은 Logstash 자체에서 제공하는 다양한 플러그인들로 코딩없이 간단히 작업할 수 있다.

Output

Input 과 마찬가지로 Logstash 는 다양한 데이터 소스로 출력할 수 있다. Output 의 예시로는 Elastic Search, Email, File, TCP, HTTP, Kafka, RabbitMQ, Redis, S3, WebSocket 등이 있다.

Kibana

Elastic Search 만으로 데이터를 검색하는 것은 가능하긴 하지만, Elastic Search 만 단독으로 사용하면 Rest API 를 호출해야만하기 때문에 불편하다. 따라서 Elastic Search 에 저장된 데이터를 보기 쉽도록 시각화 할 도구가 필요한데, 이를 위해 Kibana 를 사용한다. Kibana 는 HTML + JavaScript 엔진으로 사용자가 Elastic Search 에 저장된 데이터를 쉽게 검색하고, 분석하는데 도움을 준다.

Kibana 는 일반적인 텍스트 데이터를 비롯하여, 히스토그램, 차트, 위치 데이터, 시계열, 그래프 등 다양한 시각화를 제공한다. 또한 사용자가 쉽게 데이터를 검색하고 필터링할 수 있는 기능을 제공한다. 추가적으로 Kibana 는 데이터를 모니터링하여 사용자에게 경고 알림을 제공하는 기능도 존재한다.

Beats

마지막으로 Beats 는 로그, 메트릭 등의 다양한 데이터 소스에서 다양한 유형의 데이터를 수집하고 전달하는 경량 데이터 수집기이다. 일반적으로 Beats 는 Logstash 또는 메시지 큐에다 수집한 데이터를 전달한다.

Beats 는 수집하는 데이터 소스, 형태에 따라 아래와 같이 종류가 구분된다.

FileBeat : 서버의 로그 파일을 수집한다.
MetricBeat : 서버의 CPU, 메모리, 디스크 용량과 같은 시스템 메트릭이나 MySQL, Nginx 같은 서비스 메트릭 정보를 수집한다.
PacketBeat : 서버와 클라이언트 간의 트래픽을 실시간으로 모니터링해서 네트워크 상태 정보를 수집한다. HTTP, DNS, MySQL 과 같이 다양한 프로토콜에서 트래픽 정보를 수집한다.
WinlogBeat : 윈도우 시스템에서 발생하는 이벤트 로그를 수집한다.
AuditBeat : 리눅스 시스템에서 발생하는 이벤트 로그를 수집한다.
Hearbeat : 주기적으로 지정된 URL 로 요청을 보내서 서비스 상태를 모니터링한다.
FunctionBeat : AWS Lambda, Google Cloud Functions 등의 FaaS (Function-as-a-Service) 플랫폼에서 데이터를 수집한다.

참고

LINE 서버 개발자가 되기까지, 2025년 상반기 회고

Tue, 22 Jul 2025 00:00:00 GMT

LINE 개발자, LINER가 되었다

LINE Plus 분당 오피스 - 공용 오피스 및 라운지

2025년 상반기 대학교 졸업과 동시에, LINE 개발자로 최종합격 및 입사 예정을 앞두고 있다. 내 직무 역량을 좋게 봐주셨는지, 신입 개발자임에도 경력직 채용 서버 개발자 포지션에 최종 합격하여 입사하게 되었다. LINE 개발자가 되기까지 몇년동안 피땀흘리며 노력했던 과정들을 회고해볼까 한다. 2025년 상반기를 더 중점으로 회고해볼까 하지만, 2025년이 아니더라도 그 동안의 성장 과정을 다시금 길게 회고해볼까 한다.

멋쟁이사자차럼 동아리, 백엔드의 첫 걸음 시작

멋쟁이사자처럼 10기 중앙해커톤 은상 수상

)

SOPT, 멋쟁이사자차럼, UMC, GDSC, ... 등등 대학교 내에도 유명한 IT 개발 동아리가 많이 생겼다. 그 중 나는 멋쟁이사자처럼 이라는 동아리에서 활동하면서, 처음으로 웹 프로그래밍을 접하게 되었다. 사실 멋사말고도 UMC 라는 동아리에서도 활동했었지만, 동아리 부원들과 가장 재밌게 활동하여 추억을 많이 쌓은 동아리는 단연코 멋사가 아닐까 싶다.

부원들과 팀을 꾸려서 중앙해커톤을 참여했으며, 그를 마무리로 멋사의 공식적인 활동을 끝내게 되었다. 10명이 넘는 팀원들과 FE, BE, 디자이너로 역할을 구분짓고 열심히 서비스를 런칭해보는 경험을 가졌다. 그런데 지금 시점에서 다시 생각해보면, 당시 만든 서비스는 정말 엉터리였다 😅 엉터리 레거시 코드, 취약한 보안, 정말 낮은 가용성(availability), 성능 튜닝도 전혀 안된 상태, 다운타임도 심한 서비스이며, API 연동도 안된 결과물이기 때문이다.

다만 웹개발을 처음 접하고, 단순 해커톤 참여인데 어떻게 지금 수준처럼 서비스를 런칭할 수 있을까 싶긴하다. 그 당시에는 고도화된 서비스를 완성시키는데 목적이 있는 프로젝트가 아니였기도 하다. 처음으로 웹개발이 무엇인지 감을 익혀서 만족스럽고, 전국 42개 대학이 참여하는 중앙해커톤에서 은상을 수상했다는 점에서 뿌듯한 경험, 추억이 되었다.

멋쟁이사자처럼에선 백엔드 교육세션을 기본적으로 Python + Django 프레임워크로 진행한다. 이 점이 장점이자 단점이 될 수 있었다. 장점이라 함은 Django 특성상 스프링부트 프레임웤에 비해서 진입장벽이 낮기에 REST API 개발을 빠르게 익힐 수 있다는 점이다. 하지만 단점이라 함은 Django 를 깊이 학습해봤자 취업에 그닥 도움이 되지 않는다는 점이다. 안타깝게도 대한민국을 더붙어 전세계에선 스프링 프레임워크 개발자의 채용 수요가 압도적이다 보니, 파이썬 계열을 열심히 파봤자 그닥 좋은 회사로 취업하지 못할 것이 뻔하게 되었다. (스타트업 일부에서만 Django 를 사용하더라.)

그래서 고민이 많았다. 멋쟁이사자처럼 중앙해커톤과 교육세션이 모두 종료된 시점이 되었을 때, Django 를 기반으로 커리어를 계속 쌓아나갈 것인지, 아니면 스프링부트 프레임워크로 새롭게 커리어를 쌓아나갈지 고민이 많았다. 지금까지 Django 를 열심히 공부했는데, 그냥 버리자니 너무 아깝기 때문이다. 하지만 고민끝에 결국 스프링으로 커리어를 새롭게 쌓기로 결정했다.

UMC 에서 스프링부트 첫걸음 때기

이후 이 때문에 UMC 라는 동아리로 들어가서 스프링부트를 처음 접하게 되었다. 이떄가 2022년 하반기로 기억하는데, 스프링부트가 당시 2점대 버전이었던 것으로 기억한다.

UMC 에선 스프링 생태계의 정말 기초적인 내용을 학습해보며, 스프링 생태계에 대한 전반 오버뷰를 익힐 수 있었다. 교육 과정으로는 데이터베이스 ERD 설계, SQL 쿼리 기초, jdbcTemplate 을 기반으로 진행했다. 아울러, 맨 마지막 교육 세션에는 트랜잭션의 기초 개념에 대해 학습하게 되었다. (트랜잭션 기초 개념이라 함은 ACID, 격리수준과 같은 개념도 아니고, 단순히 스프링 트랜잭션 어노테이션이란 무엇이고, 트랜잭션은 원자성을 보장해 준다 정도의 수준으로 간단히 학습했다.)

이 당시에는 정말 부끄럽게도 스프링 빈, DI, AOP 이런 개념도 들어보지 조차 못했다. 스프링부트 안에서 제공하는 어노테이션을 왜 클래스에 붙여야 하는지도 잘 모르고 그냥 붙였다. 일단 돌아가는 스프링부트 코드를 만들면서 흥미를 붙이는데 의미가 있었지 않나싶다.

이후 2달간 앱 런칭 프로젝트를 시작했다. 7명이 팀을 꾸려 프로젝트를 진행했으며, IOS 2명, 디자이너 1명, BE 4명이었던 것으로 기억한다. (시간이 오래되어서 정확한지는 잘 모르겠지만) 이 당시에는 교육과정에서 배운 jdbcTemplate 이 아니라 JPA 를 기반으로 프로젝트를 진행했다. 교육과정 떄 jdbcTemplate 으로 API 를 만들어보다가 JPA 및 Hibernate 라는 ORM 을 기반으로 REST API 를 개발해보니, SQL 중심적인 개발의 문제점은 정말 많다는 점을 직접 체감하게 되었다.

이 당시만 하더라도 완전 기초 프로그래밍 역량을 갖춘 상태로 개발을 했던 것 같다. 현 블로그를 운영하기 이전 블로그인 Velog 에서 포스팅을 할 때도 포스팅의 퀄리티 및 심도있고 깊은 내용을 다루냐의 수준을 비교해 보면, 지금과 차이가 극명하게 난다. 지금와서 다시금 생각해보면, 짧은 기간인 2년 동안 엄청난 성장을 했기 때문에 LINE 개발자가 될 수 있었던게 아닐까? (열심히 살았다 나 자신 🙂)

서비스 운영 시작, 하지만 실패했다

2023년이 되었을 때 무렵 대학교 3학년이 되었다. 이떄쯤부터 실제 서비스를 운영하고 싶다는 마음이 커졌고, 마침 지인으로부터 서비스 운영 제안을 권유받았던 기억이 난다. 서비스 명은 직접 이곳에 언급할 수 없지만, 사이드 프로젝트치고 규모가 매우 큰 서비스였다. 그 서비스의 특징을 정리해보면 다음과 같다.

MAU 8,000명 가량이 접속하는 서비스

일본, 중국, 대만, 태국, 러시아, 미국, ... 등 전세계 각국에서 트래픽이 유입되는 서비스

문서화, 정책 수립 문화를 체계적으로 잡기 위해 노력하는 팀 문화

꽤나 복잡한 도메인 정책 및 비즈니스 로직 개발

서비스 운영 팀을 나오게 된 이유

네카라쿠배당토 - 대한민국 IT 빅테크 대표 기업들

다시금 생각해봐도 꽤나 매력적인 서비스 운영 경험이라고 생각한다. 하지만, 몇달이 지나고 서비스 운영 팀에서 금방 나오게 되었다. 우선 그 서비스는 학부생이 감당하기엔 미션 크리티컬한 도메인만 가득했다. 때문에 서비스를 운영하면서 자유롭게 기술을 적용하고, 고민해보는 경험을 편하게 할 수가 없는 환경이었다. 게다가 주변에 최상위 기업 (흔히 말하는 네카라쿠배) 에 취업하신 선배님들만 봐도 실제 서비스 운영을 하는가의 유무에 따라 취업을 잘 하는것이 아니였다.

IT 대기업(네카라) 에 취업하기 위해선 서비스 운영을 했냐가 절대로 중요하지 않다. 실제로 나 또한 신입임에도 LINE 개발자가 된 것을 보면, 그닥 서비스 운영 경험이 필수적인 것은 아니라고 증명할 수 있다. (간혹, 주변 사람들을 보면 서비스 운영을 꼭 해야한다는 것에 집착하는 경향이 있는 사람들도 있다.) 네카라 개발자가 되기 위해선 학습의 방향성과, 사용하는 기술들에 대한 내부 동작원리, 본질을 깨닫는 것이 정말 중요하다. 그렇기 때문에 나 또한 네카라 개발자가 될 수 있었다.

해당 서비스를 운영하면서 그닥 내가 배울 것이 없다고 생각했다. 해당 서비스 팀원들은 문서화 문화를 굉장히 중요시 했지만, 그 정도가 지나치게 과했다. 팀은 생각보다 보수적으로 움직였으며, 내가 원하는 방향성과 잘 맞지 않는다고 생각이 들었다. 간단한 서비스 기능 하나를 런칭하는데만 수개월이 걸렸다.

나에게는 서비스를 자유롭게 운영하면서 실수도 해보고, 도메인을 개발할 때 스스로 고민하는 습관을 편하게 기를 수 있는 경험도 쌓길 원했으며, 트러블슈팅도 마주했을 때 그 장애 전파가 되었을 때도 고객들에게 미치는 파급력이 크지 않은, 마치 놀이터와 같은 프로젝트 운영 경험이 필요했다.

또한 팀이 (내가 느꼈을땐) 보수적으로 움직이다 보니, 학습한 기술들에 대해 실제로 서비스에 적용해보면서 학습하고, 고민하고 싶었지만 전혀 그러지 못했다. 이 당시만 해도 무중단 배포 전략(카나리, 블루그린 같은), Redis 분산락과 같이 실무에서 자주 쓰이는 기술 및 전략들에 대해 기술 블로그 포스팅으로 다룬적이 있다. 하지만 실제 서비스 운영에 전혀 적용하지 못하고 있으니, 포스팅 개수만 늘어가고, 이론 기반 지식으로만 학습하면서 시간이 지나며 머릿속에서 모두 휘발되어 버렸다.

이 외에도 여러가지 이유가 있었지만, 아무튼 이러한 이유로 서비스 운영팀에서 나오게 되었다.

카카오테크 부트캠프 1기 수료

카카오테크 부트캠프 판교 교육장

2024년 하반기, 카카오테크 부트캠프에서 진행된 교육과정을 성공적으로 수료했다. 카카오테크 부트캠프에서 활동을 시작하기 전까지는 정말 힘들고, 불안했던 시기들이 많이 있었다. 이와 관련해서는 2024년 카카오테크 코스 최종 합격까지, 상반기 회고 포스팅에서 이미 회고를 자세히 해서, 굳이 다루지 않으려고 한다.

카카오테크 부트캠프를 선택한 이유

이미 내가 신뢰하고 큰 도움을 받고있는 동아리 선배 를 통해서 꾸준히 도움을 청했고, 평소에 많이 고민하고 도전하는 습관을 통해 학습의 방향성과 기술의 본질, 그리고 빠른 러닝커브를 증명할 수 있는 학습법까지 잘 알고있는 상태였다. 그럼에도 왜 부트캠프라는 교육 과정을 선택했을까? 그 이유는 우선, 함께 성장할 동료가 절실히 필요했다. 그 당시 장기간 혼자서 학습을 이어온 상태이다보니, 무언가 같이 스터디를 진행하거나 협업하여 프로젝트를 운영해야 하는 상황이 생기더라도 동료가 없으니 성장하기에 한계가 있었다.

또한 취업의 관점에서도 어딘가의 조직에 속해있어야 함을 느꼈다. 프로젝트를 진행하여 서비스를 런칭하려고 해도 동료도 없으니, 이력서에 작성해낼 내용이 전혀 없었다. 앞서 운영중인 서비스에서 탈퇴했다고 했는데, 이 이후로 어딘가에 속해있는 조직이나 그룹이 없다보니 혼자서 많이 방황하고, 이력서에 채울 내용도 없었다.

만약 부트캠프에 합류하게 된다면, 함께 성장할 동료를 찾을 수 있고, 이력서에 담백히 채울 수 있는 프로젝트 이력이 생길 것이 분명했다. 또한 배우는 것이 최우선 목적이 아니긴 했지만, 카카오 현직자분들을 통해 기술적인 성장이 분명히 있을 것이라 생각했다. 그간의 가꾸어낸 글쓰기+블로깅 기반 메타인지 학습법을 통해 가파른 러닝커브를 만들어낼 수 있을것이란 굳은 믿음이 있었다.

카카오테크 부트캠프에서 무엇을 공부했을까?

교육과정 속에서 내가 카카오 크루, 교육생들과 만나며 열심히 공부한 내용들을 회고해볼까 한다. 나는 카카오 부트캠프에서 무엇을 공부했을까?

디자인패턴, 웹개발, CS, 인프라 오버뷰 학습

디자인패턴

7 ~ 8월 사이에는 이론 강의를 중점으로 교육과정이 진행되었다. 9 ~ 12월 사이에는 대면.오프라인을 중점으로 판교 교육장 오피스에서 현장 중심의 프로젝트 경험을 쌓을 수 있도록 교육 과정이 진행되었다. 이론 수업을 진행할 때 기억에 남는것은 디자인패턴과 웹개발, CS 기초, 인프라의 전반 오버뷰에 대해 학습했다는 점이다.

다만, 교육과정 중에 조금 아쉬웠던 부분도 존재한다. 사실 이론 수업을 들을 때 들은 내용들이 실무에서 정확히 어떻게 쓰인다는 것인지 연결고리를 잘 맺게 도와주셔야 한다고 생각하지만, 그리 순탄히 진행되지는 않았던 것 같다. 프로그래밍을 공부하며 능동적인 성장을 위한 학습방법 에서도 다루었듯이, 모든 학습에는 이론 중심의 학습이 되어서는 안된다. 이 기술을 왜 배워야하고, 실무에서 적용해보면서 이론이 어떻게 되는것인지 깨닫는 과정을 통해 기억의 장기화가 될 수 있다.

자바, POJO 프로그래밍

깃허브 아카이브 레포지토리 에 교육과정동안 학습한 내용들이 모두 담겨있다. 나는 교육과정 동안 자바의 내용을 다시금 복습하고, 스프링의 근간과 Low-Level 을 집요하게 파고들며 학습했다.

프로젝트를 진행하면서 객체지향 프로그래밍에 대해 제대로 고민해보았다. 이전에 공부했던 객체지향의 사실과 오해라는 책을 다시금 읽으면서, 하나의 컴포넌트 및 기능을 구성하는 여러 객체들간에 어떻게 역할과 책임을 나누고 협력할지에 대해 많은 고민과 노력이 있었다. 객체지향 생활체조 원칙 또한 다시금 복습하면서, 우리 서비스내 백엔드 코드에 어떻게 생활원칙이 잘 적용될 수 있읋지 매순간마다 많은 고민을 기울였다.

서비스내 백엔드 코드에 디자인패턴 또한 부분적으로 적용했다. 다양한 서비스 정책이 있을텐데, 비슷한 역할을 수행하면서 구체적인 세부 구현 기능만 다른 경우에 대해서 디자인패턴을 적용했다. 예를들어, 할인정책이 있을때 1,000원 할인하는가, 10,000원 할인하는가에 따른 정책에 따라 캡슐화를 시켜놓는 방식으로 코드를 구현했다. 실제 우리 서비스에는 전략패턴, 데코레이터 패턴등이 코드내에 적용되고 있는 상태이다.

또한 스터디를 진행하며 자바 프로그래밍의 근본이라 할 수 있는 POJO 프로그래밍을 진행하며, 자바 언어에 대한 깊은 학습을 진행했다. 자바 리플렉션, JDK 다이나믹 프록시를 공부하면서 프록시 패턴의 한계점에 대해 직접 체감해보는 경험을 가져봤다. 기초적인 자바 웹 애플레케이션 개발시 자잘한 성능 이슈에 대해 고민해보기도 했다. for 문 대신에 왜 Stream API 를 자주 사용하는지, 왜 성능은 느린것인지 학습해봤으며, String, StringBuilder/Buffer 등의 성능 문제 및 Thread-Safe 특성에 대해 공부하기도 했다.

스프링부트

스프링부트 또한 기초적으로 대충 알고있던 내용들을 제대로 공부하기 시작했다. IoC, DI 와 같은 핵심 개념부터 제대로 근본을 이해하고자 시작했으며, 점차 JDBC 레벨로 파고들며 DataSource, JDBC Driver, HikariCP, 트랜잭션 동기화 및 추상화, TransactionManager 와 같은 스프링 생태계의 데이터베이스 Low-Level 근간을 공부하는데 주력했다. 프로젝트에선 향후 후술할 MySQL 레플리케이션 다중화 환경에서 DataSource 를 트랜잭션 readOnly 에 따라 적절히 라우팅 해줘야하는 Multi DataSource 구축 상황이 발생했는데, 이 과정에서 JDBC 단의 트랜잭션 내부 동작원리를 깊게 공부해보며 스프링의 내부 근간을 더 공부해볼 수 있었다.

프로젝트 또한 Spring JPA 로 운영되고 있기 때문에 JPA 과 관련한 여러 트러블슈팅을 마주하며 마찬가지로 심도있는 내용을 공부해볼 기회가 생겼다. JPA 의 영속성 컨텍스트, 1차 캐시와 같은 중요한 개념은 몰론이고 Multi DataSource 환경에서 JPA OSIV(Open Session In View) 설정 관련 트러블슈팅 까지 마주하며 스프링부트 내부의 동작원리를 깊게 공부했다.

개인 스터디로 Next Step 자바 웹 프로그래밍 서적을 다시금 복습해보았다.톰캣, Spring MVC, JDBC Template 등 현존하는 라이브러리, 프레임워크를 직접 바닥부터 내가 구현해봄는 경험을 해보았다. 바퀴를 재발명하는 경험을 통해 현존하는 기술들에 대한 내부 원리를 직접 체감할 수 있었다.

TDD, 테스트 커버리지 98% 달성

토스ㅣSLASH 21 - 테스트 커버리지 100% 이응준님 발표

서비스를 운영하면서 TDD 또한 제대로 공부해 볼 기회가 생겼다. 테스트 작성은 내가 가장 중요하게 생각하는 프로그래밍 관습 중 하나이다. 특히나 나는 높은 커버리지를 유지해야 한다는 강한 주장을 내세우는 사람중 한 명이다. 토스ㅣSLASH 21 - 테스트 커버리지 100% 라는 토스 Slash 영상을 보면서 실무에서도 100% 라는 커버리지를 유지할 수 있으며, 100% 를 유지했을 때 얻는 장점들이 정말 많다는 점을 배울 수 있었다. 우리 팀 또한 100% 까진 달성못해도 유의미한 테스트를 작성하면서 높은 커버리지를 유지하자는 취지가 강했고, 커버리지 98% 를 달성했다. 추가적으로 90% 미만으로 떨어질 경우 빌드가 실패하여 배포 자체가 불가능하도록 만들었다.

테스트가 있어야지 리팩토링를 자신있고 과감하게 진행할 수 있다고 굳게 믿는다. 잘못된 코드 작성물이 있다면 그 즉시 테스트가 잘못되었음을 알려주어, 빠르게 피드백 받을 수 있다. 또한 테스트 자체가 일종의 문서화 역할을 하여, 협업하는 팀원들간에 해당 도메인을 빠르게 이해시키는데도 도움이 된다.

또한 테스트는 프로덕션과 비즈니스 정책에 대한 이해도를 높여주는데도 도움이 된다. 테스트를 작성하다보면 가끔 무엇을 테스트해야하는지 막히는 상황이 생길 때가 있었는데, 이떄가 바로 도메인과 정책에 대한 이해도가 낮다고 느껴질 때이다. 테스트를 통해 내가 잘못 알고있는 부분이 무엇인지 자연스레 깨닫게 되고, 실수없는 견고한 프로덕션을 만들 수 있게된다.

MySQL, 분산 DBMS 환경 구축

MySQL 또한 정말 집요하게 공부했다. 내가 면접을 볼 때마다 다른 지원자들과 다르게 갖고있는 강점이자 경쟁력을 무엇으로 내세울지 전략을 짜고, 많은 고민이 있었는데, 그 중 하나로 MySQL 및 데이터베이스 관련 고가용성 인프라 아키텍처 설계 역량을 내세웠다.

우리 서비스는 MySQL 레플리케이션 아키텍처 구조를 취하고 있다. 레플리케이션과 관련해서도 정말 많은 포스팅을 발행하며 내부 동작원리와 근본을 깊게 공부하는데 시간을 가장 많이 투자하지 않았나 싶다. 바이너리 로그, 릴레이 로그, 어플라이어 등등 MySQL 복제 내부 아키텍처 및 동작원리를 공부하면서 사용하는 기술에 대해 높은 이해도를 갖출 수 있었다. 이 외에도 FailOver 를 할때 필요한 개념인 바이너리 로그 위치 복제 방식, GTID 복제 방식등을 깊게 공부해보았다. 이렇게 평소에 깊게 공부한 습관들은 향후 면접 대비에서 아주 큰 도움이 되었다 🙂

또한 단순히 분산 데이터베이스 환경을 구축 하는것에 그치지 않았다. 부하 분산, 지리적 분산.재해 대응, FailOver, 백업 및 복구 등 모두 고려한 고가용성 분산 DBMS 환경을 구축하고자 많은 노력을 기울었다. 또한 레플리케이션 아키텍처 그 자체에서 아키텍처를 취할 수 있는 구조가 정말 다양하다. 우리 서비스의 경우는 많은 고민을 기울인 경과 Multi Replica 아키텍처 구조라는 토폴로지 전략을 취했다.

레플리케이션 외에도 클러스터링, 파티셔닝, 샤딩 전략을 취한다면 우리 서비스에 어떻게 취할것인지, 1,000만건 이상의 대규모 데이터가 적재되었다면 어떻게 대응하고 아키텍처를 취할 것인지 고민이 많았다.

10분 카카오 Tech Talk 기술 발표 세미나

Tech Talk 기술 밢표 세미나 참여 영상

카카오테크 부트캠프는 소프트 스킬 증진을 위해 10분 기술 발표 세미나를 진행한다. 매주 지정된 요일에 중앙 타운홀에 모여서 각 파트별(FE, BE, Cloud, AI 등) 로 발표를 진행했는데, FE+BE 는 매주 수요일에 발표를 하게 되었다. 나는 데이터베이스 인덱스의 기초 내용을 간단히 발표 내용으로 다루었다.

발표를 하기 전까지는 그닥 긴장될 이유가 없어서 딱히 별 생각을 안하고 있었는데, 막상 중앙 타운홀에서 발표를 진행하니 떨리고 긴장되는 마음이 커졌다. 그래도 서로가 아는 얼굴들이고, 우리 하모니 팀 팀원들이 격려와 응원을 해주어서 잘 마무리 할 수 있었다.

하모니 팀 기술 블로그 운영

하모니 팀 기술 블로그

나는 기술 공유 문화를 중요시 생각하는 사람이며, 나의 최강점으로 내세울 수 있는 소프트스킬은 글쓰기.문서화 능력이다. 하모니 팀이 서비스를 운영하면서도 서로가 함께 성장할 수 있는 글쓰기 공유 문화를 만들고자 팀 기술 블로그를 만들고 운영했다.

맨 처음에는 글쓰기와 필력에 자신있고 여러 내공이 있는 나랑 도로시가 주도적으로 팀 기술 블로그 운영을 적극 추진했다. 우리 팀은 서로가 역할을 분배했는데, 나는 팀 기술 블로그 운영 및 문서화 문화 활성화에 포커싱했다. 다른 하모니 팀원들에게도 계속 글쓰기 및 포스팅 발행을 독려하면서, 프로젝트 기간동안 45여개의 포스팅을 팀 기술 블로그에 발행할 수 있었다.

교육과정 수료, 취준기 시작

크리스마스 시즌 무렵, 12월 27일을 마무리로 카카오의 교육 과정은 끝이나게 되었다. 막바지 무렵 쯤에는 이력서를 작성하고, 수정하고, 다듬고, 면접에 참여하느라 정신이 없었던 것 같다. 그렇게 교육과정이 끝나자마자 대학교 마지막 학기에 복학함과 동시에 취준기에 본격적으로 뛰어들었다.

LINE 개발자가 되다

LINE Plus 분당 오피스 - 공용 오피스 및 라운지

그렇게 대학교 막학기 재학과 동시에 취준을 병행하며 LINE Plus 서버 개발자 경력직 수시채용 공고에 이력서를 넣었고, 최종 합격을 하게 되었다. 다음달인 8월 초부터 분당 오피스로 출근 예정에 있다.

취준기는 정말 지옥 같았고, 고통스러웠다. 앞으로도 살면서 이때보다 더 힘들고, 우울했던 시기가 있을까 싶을 정도로 정말 싫었다. 하지만 힘들고 어려운 시기를 묵묵히 버티고, 이겨냈기 때문에 LINER 가 된 것이 아니겠는가 😁

지금까지 지원하고, 면접까지 치룬 회사

네카라쿠배당토 - 대한민국 IT 최고의 기업들

나는 IT 서비스 대기업에 취업하기를 몇년간 바라왔으며, 내 직무 역량을 스스로 믿고 굳게 IT 서비스 기업을 중점으로 이력서를 넣었다.

네카라쿠배당토는 이미 신입 채용이 동결된지 오래이다. 2022년을 가장 마지막으로 신입.경력 모두 취업의 문을 모두 닫았으며, 2023년부터 나를 비롯한 모든 개발자들이 심각한 채용 한파를 직격으로 맞았다는 생각이다. 나 또한 심각한 채용 한파를 피해갈 수 없었으며, 23년도, 24년도를 지나서 25년이 되었을 때는 채용 한파가 더욱 심각해져만 갔다.

IT 대기업의 3대장 네카라(네이버, 카카오, 라인) 또한 23년도 쯤부터 이미 신입 채용을 아예 동결시켜 버렸다. 나 또한 그래서 LINE 에 경력직 채용 공고로 지원하게 된 것이며, 공개채용 공고에는 단 한번도 이력서를 넣어보지 못했다. 그만큼 가혹하고도, 힘든 시기를 이겨내는데 정말 많은 노력이 있었던 것 같다.

수시 채용의 특성상 경쟁률은 매우 치열할 수 밖에 없었으며, 채용 또한 언제 마감될지 전혀 모르기 때문에 하루하루가 매우 피말려갔다. 대부분의 채용 공고가 한 자리수 이내로 채용 인원을 선별했으며, 심한 경우는 1명 정도 뽑는 자리에 8,000명 이상의 인원이 지원하여 경쟁률이 1 : 8000 을 넘어가는 수준이었다. 요즘은 작은 스타트업만 해도 1명 뽑는 자리에 1,300명이 넘게 지원한다고 하니깐 정말 심각하다. 또한 합격자가 발생하는 그 즉시 채용 전형 진행중인 모든 지원자를 불합격 처리해버리니, 아무리 능력이 뛰어나도 채용 지원 시기를 잘못타면 불합격 소식을 들을 수 밖에 없었다. (나 또한 LINE 에서 최종합격 소식을 듣자마자 채용 공고가 2시간 뒤에 바로 내려간 것을 봤다.)

서류 탈락을 제외했을 때, 즉 서류 합격 이후의 채용 절차를 밟았던 회사는 다음과 같다. 이 중에서 면접 및 코딩테스트 전형에서 불합격 소식을 들은 것도 정말 많고, 최종 면접 기회를 얻은 회사도 있지만 LINE 최종합격 소식을 듣자마자 면접 포기 메일을 보냈다.

💡 서류 전형 합격 이후의 전형까지 채용 절차를 밟았던 회사 리스트

네이버 본사 (경력 3년 이상)

네이버웹툰 (경력 3년 이하)

카카오 본사 (경력 1년 이상)

카카오페이 서버 개발자 (경력 3년 이상)

카카오엔터프라이즈 스토리지 플랫폼 (경력 3년 이상)

카카오모빌리티 서버 개발자

LINE Plus - 서버 개발자 (경력 2년 이상)

LINE Music (경력 8년 이하)

LINE Plus - DBA

당근마켓 - 추천 시스템 서버 개발자

당근마켓 - 서버 개발자 인턴 포지션

토스뱅크 - 수신 플랫폼 서버 개발자

토스페이먼츠 - 서버 개발자 (경력 3년 이하)

뭐 이렇게 많은 회사의 채용 절차를 밟얐냐는 생각이 들 수도 있겠지만, 지금 우리가 알아야 할 점은 채용 시장에 심각한 한파가 찾아왔다는 점이다. 또한 나는 애당초 신입 개발자임에도 경력직 채용 공고 다수에 서류 합격을 했다는 점에 감사하고 있다. 그리고 면접 전형까지 가기전에 코딩테스트 전형이 대부분 존재했는데, 나는 코딩테스트가 잘 준비되지 않은 상태라 코테 전형에서 떨어진 것도 많다. 또한 LINE 최종 합격을 하자마자 면접 포기 메일을 바로 전송한 회사도 많다.

LINE 채용 절차

서류 전형 & 코딩테스트

서류 전형은 그 누구보다도 자신있었다. 내 소프트스킬 상의 강점은 글쓰기, 필력, 문서화 역량이다. 내 이력서와 자기소개서를 회사 측에서 읽었을 때, 꼭 나를 만나서 얘기해보고 싶게끔 매력적인 이력서를 담아내는 것에 자신감이 넘쳤다. 또한 나만을 위한 글을 쓰는 것이 아니라, 다른 사람들에게 공유하는 목적도 동시에 갖는 글쓰기를 평소에 습관처럼 이어왔다. 이 습관은 이력서와 포트폴리오를 만드는데도 아주 큰 도움이 되었다. 내 이력서를 읽을 때 내가 어떤 사람인지를 빠르게 파악할 수 있도록 하고, 내가 읽고 작성하기 편한 이력서가 아니라 다른 사람이 읽기 편해보이는 이력서를 작성했다.

사실 이번 LINE 서버 개발자 자기소개서를 작성하고, 인적사항 기입 및 이력서를 최종 제출하는데만 30분이 걸리지 않았다. 사실 이 당시 다른 회사 서탈을 너무 많이 했던 시기라, 정신이 반쯤 나간 상태로 전혀 기대 안하고 자기소개서를 30분만에 작성하고 빠르게 제출했다. (근데 작성한 자소서 내용을 지금 다시보니 꽤나 잘 작성했다.) 그래서 서류 합격 소식을 들었을 때 깜짝 놀랐다.

코딩테스트 전형은 매우 난이도가 쉬웠다. 간단한 기초 알고리즘 유형만이 등장했으며, 구현 위주의 문제가 나왔던 것으로 아마 기억한다. 코딩테스트 제한시간이 200분인데, 나는 30분만에 모든 문제를 푼뒤 빠르게 제출하고 코딩테스트를 종료했다. 모든 문제를 빠르게 문제없이 풀고 제출했기 때문에, 코딩테스트 전형은 문제 없기 통과하곘다는 기대를 하게 되었다.

기술 인터뷰

코딩테스트 종료 2일만에 합격 소식을 듣게 되었고, 직무 인터뷰를 일정을 조율하게 되었다. 직무 인터뷰는 약 1시간 정도로 진행되었으며, 꼬리에 꼬리를 정말 깊게, 집요하게 파고들며 물어보는 질문들이 이어졌다. LINE 경력직 기술 인터뷰 후기를 찾아보면 지구 내핵까지 파고들며 영혼이 나갈 정도의 어려운 질문들을 DFS 형태로 진행한다는 후기가 많았는데, 나 또한 예외없이 정말 어렵고, 난해한 기술 질문들을 받았다.

면접 진행중에 내 등 뒤에는 식은땀이 정말 많이 흘렀다. 다만, 어쩜 이렇게 전혀 생각치도 못한, 고민해보지 못한 질문들을 받을 수 있을까.. 속마음으로는 정말 훌륭하고 질 좋은 질문들이 가득하다는 느낌을 받았다. 개인적으로는 정말 어렵고 압박감있는 기술 면접 형태일지라도, 이런 유형의 기술 면접을 좋아한다.

교과서에 잘 나와있는 정형화된 질문들을 달달 외워서 답변할 수 있는가를 검증하는 것이 아니라, 개발자에게 정말 중요한 본질이라 할 수 있는 문제 해결력 을 검증하겠다는 느낌이 강했다. 어려운 서비스 장애 및 문제 상황을 하나 주어지고, 주어진 문제를 스스로 해결해나가고, 논리적인 추론을 슬기롭게 해내가는지를 깊게 검증하려는 느낌이었다.

모든 질문들이 하나같이 예상 질문밖에서만 등장했으며, 정말정말 어렵고 난처한 기술 질문들을 많이 받았다. 하지만 어려운 질문과 상황이 들어와도 끝까지 포기하지 않고, 합격한다면 함께 일하게 될 동료라는 입장으로 최대한 아는 지식들을 모조리 끌어모아서 답변을 드리고자 노력했던 것 같다. 함께 일할 수 있는 동료라는 느낌을 받을 수 있도록, 어려운 질문들에 절대 포기하지 않고 어떻게든 머리를 쥐어짜서 답변드렸다. 버벅 거린것도 많았지만 대부분의 답변에 어떻게든 답변을 드렸고, 다행히 직무 역량을 좋게 봐주시어 기술 인터뷰 합격 소식을 듣게 되었다.

무엇보다, 내가 사용하는 기술들에 대해 매우 깊은 Low-Level 단의 내부 동작원리, 근간을 잘 설명드렸던 것 같다. 코드 레벨단까지 내려가면서 사례.예시와, 내부 동작원리를 잘 설명드렸다. 하도 깊은 내부 동작원리에 대한 설명을 드리다보니 JDBC 수준까지 내려가면서 DataSourceUtils, TransactionSynchornizationManager 등 과 같이 매우 깊은 내용까지도 설명드렸던 것이 기억난다. Nginx 또한 Graceful Shutdown 과 관련하여 Worker Process, Master Process 의 내부 동작 과정까지 설명 드렸기도 했다. 또한 HTTP/1.1 스팩의 Half-Closed Connection 동작 과정까지도 설명드리기도 했다. 이 점에서 기술 인터뷰 전형의 고득점을 얻지 않았을까 싶다.

기술 인터뷰 결과가 나오는데 까지는 시간이 다소 오래걸렸다.. 😓 이 시간동안 정말 피말렸고, 인터넷에 라인 면접 결과가 보통 언제 나왔는지 후기를 수시로 찾아봤던 것 같다. 메일도 하루에만 수십번 열어봤던 것 같다.

컬처핏 & 임원 인터뷰

그렇게 직무 인터뷰 합격 소식을 듣고, 마지막 관문인 컬쳐핏 & 임원 면접 전형만 남게 되었다. 마지막 관문 하나만 통과하면 나도 진짜 LINE 개발자가 되는건가? 절대 도달할 수 없을 것 같았던 LINE 기업에 재직하게 되는건가? 라는 상상만 머릿속에 가득했다. 하지만 마지막 관문에서 실수해서 떨어진다면 그 만큼 상실감과 아픔이 클 것이라고 생각이 드니, 마음이 뒤숭생숭했다.

마지막 최종 인터뷰 전형 후기를 찾아보면, 대부분의 LINE 면접 후기가 2차 면접이 훨씬 어려웠으며, 더 깊고 심층적인 내용을 다루는 기술 면접이라는 후기가 대부분이었다. 특히나 직무 인터뷰에서 고득점을 얻지 못했더나 추가 검증이 필요한 지원자라면 높은 확률로 더욱 심화된 기술 면접을 보게 된다는 후기가 많았다.

그래서 나 또한 직무 관련 질문이 주를 이루며, 더 심화된 기술 질문이 들어오겠다는 추측으로 면접 시나리오를 생각해보았다. 게다가 경력직 채용인데 나는 신입 개발자이다보니, 임원들이 나를 볼때 추가적인 검증을 꼭 하지 않을까라는 생각으로 면접에 임했다. 하지만, 그렇다고 해서 직무 면접을 더 준비하지는 않았고, 컬쳐핏 대비를 철저하게 준비했다. 만약 더 심층적인 질문이 들어온다면 내가 전혀 예측하지 못하고, 미리 준비하지 못하는 질문들이 올 것이 뻔하기에, 뭘 어떻게 미리 준비 할 수 없는 상황일 것이 분명했다.

컬쳐핏 면접 대비를 위해 LINE 의 인재상은 몰론, 내가 지원한 팀의 코어벨류까지 모두 꼼꼼히 찾아봤다. 또한 지원한 팀의 기술 발표 및 관련 영상들 또한 모조리 찾아보았으며, 어떤 특성을 갖고 어떤 팀원을 뽑고 싶을지 계속 고민해보았다. 아울러, 내가 핏이 잘 맞는 부분들을 개인 사례와 함께 정리해보았다. 또한 인터넷에 나와있는 정형화된 인성 질문(ex. 본인의 장단점, 지원동기, 왜 개발자가 되고 싶은지, LINE 에서 이루고 싶은 목표 등) 들 또한 꼼꼼하게, 체계적으로 모두 준비했다.

다행히도 왠걸? 🙂 내가 받은 질문들은 대부분 인성 질문이 주를 이루었다. 기술 질문이 조금 들어왔긴 하지만, 인성+기술을 섞은듯한 느낌의 쉬운 질문을 주셨다. 정리하자면 다음과 같다.

인성 질문 : 80%
기술+인성 질문 : 20%

LINE 의 대부분의 면접 후기는 2차 면접이 훨씬 어려운 기술 면접이라고 했으나, 나는 직무 인터뷰에서 이미 좋은 점수를 얻었다는 확신이 들었다. 내가 실수만 하지않고, 나의 강점과 매력점을 잘 어필할 수만 있다면 충분히 합격하겠다는 생각이 들었다.

3명의 임원 분둘이 참여했으며, 나의 매력과 강점, 경쟁력을 모두 어필하고 보여주겠다는 각오로 면접에 임했다. 면접 분위기는 정말 편한하게 진행되었고, 내가 왜 LINE 에 채용되어야 하는지, 어떤 강점과 특별한 경험들을 가지고 있는지를 한 없이 보여주었다. 내가 가지고 있는 LINE 에 대한 애정 또한 과감하게, 진심을 다해 말씀드리며, 면접이 끝나고도 아쉬움과 후회가 없도록 최선을 다해 답변드렸다.

LINE 최종합격

최종 면접이 끝나고 4일 뒤쯤, 모르는 번호로 유선 연락이 왔다. 누군가 했지만 혹여나 해서 받았는데, LINE 채용 담당자님의 연락이었고, 최종 합격했다는 전화를 받게 되었다 😆 채용 담당자님도 같이 기뻐하시고, 진심으로 축하해주셨다. 최종 합격 소식을 듣자마자 몇년동안 한번도 쉬지않고 노력했던 과정들이 헛되지 않았구나, 잘 살고 있었구나 라는 생각이 들면서 안도의 한숨을 내쉬었다. 최종합격 소식들을 듣자마자 우리 가족들이 옆에 있어서 함께 기쁨을 나누었다.

LINE 개발자라는 것은 나에겐 정말 이상적인 꿈의 직장처럼 보였다. 2년 전만 하더라도 대학교 동아리 친구들한테 나는 네카라쿠배 갈거야!! 라고 장난스럽게 말했는데, 진짜 현실이 될줄은 몰랐다. 절대 안될거라 생각했던 일이, 꿈같던 것이 내가 쉬지않고 몇년동안 노력하니 되는구나... 라는 생각만 가득했다.

LINE 개발자로써의 목표, 향후 목표

교육자의 길

학부 시절부터 "나는 언젠간 꼭 교육자의 길을 걷고 말거야!" 라는 목표가 있었다. 지금도 그 목표는 변함없다. 난 앞으로 교육자의 길을 걸어볼까 한다. LINE 개발자로써 실제 현업에서의 경험을 쌓은뒤, 여유가 된다면 부업으로 교육의 길로 빠져볼까 한다. 최근에 카카오테크 부트캠프에서도 취업 소식을 듣고 인터뷰/특강 초청 연락이 왔는데, 이를 시작으로 조금씩 취미로 하여 교육의 재미를 느껴볼까 한다.

카카오테크 부트캠프, 우아한테크코스, 네이버 부스트캠프 등 교육 사업으로 뻗을 수 있는 길은 어디든지 열려있다고 생각한다. 어서 빠르게 현업에서 경력을 쌓은뒤에, 소프트웨어 교육자가 되어야 겠다 🙂

혹 현업의 일정이 벅차서 여유가 안될경우라면, 교육자가 되는 것이 힘들 수 있다는 생각도 든다. 꼭 오프라인 교육장에서의 교육자가 아니더라도, 인프런.유데미와 같은 교육 플랫폼에서 내 지식을 전파하면서 교육자가 되는 방법도 있을 것이다. 내가 알고있는 지식을 영상으로 공유하면서, 간단히 수익을 창출해보는 것이다.

의도적으로 일에서 멀어지기, 취미 활동 즐기기

지금까지 몇년동안 쉬지 않고 달려왔다. 그래서 나는, 의식적으로 일에서 멀어지는 연습을 할 것이다. 이미 "열정" 은 내 몸안에 가득하기 때문에, 이 열정을 LINE 에서 너무 빠르게 태워버려서 번아웃이 오지 않도록 적절히 휴식하는 방법을 탐구해볼까 한다. 쉴때는 쉬어야하고, 휴식 기간 동안에는 업무 생각을 전혀 하지 않는 환경에 놓여있어야지 꾸준한 페이스로 나아갈 수 있을 것이다.

제대로 휴식하기 위한 가장 좋은 방법은 바로 나만의 취미 생활을 갖는 것이다. 취미 생활이 있다면 정신적으로 건강하게 스트래스도 풀리며, 자연스럽게 업무 생각도 전혀 하지 않게될 것이다. 제대로 휴식을 해여지 업무 시간에 활력을 넣어줄 것이며, 내 성장을 부스트시킬 수 있을 것이다. 지금까지 생각해 놓은 취미생활은 복싱, 수영, 마라톤 달리기, 밴드부에 들어가 보컬 활동등이 있다. 앞으로 내 인생에 꽃길만 가득하기를.

운동 및 다이어트 시작

취준기 동안 살이 너무 쪘다. 그래서 최근부터 다이어트를 시작하고 있는데, 효과는 은근히 잘 나오는 것 같다. 땀을 열심히 흘려면서 다이어트도 하고, 예전의 멋진 상태의 나로 되돌아오기를 🙂

LINE 에서 사용하는 기술스택 빠르게 배우기

LINE 에서는 지금까지 사용하고, 경험해보지 못한 기술 스택과 경험들이 정말 가득하다. 지금까지는 Java, Spring, MySQL 에만 주력을 해왔다면, LINE 플랫폼은 이보다 훨씬 광범위한 기술 스택을 다룬다.

기본적으로 LINE 서버 개발자로 적응하려면 MSA 이벤트 드리븐, Spring Cloud, Redis, Kafka, Hadoop, Apache Kylin, ELK Stack, Kotlin, ... 등등을 다양하게 사용한다고 한다. 이 외에도 정말 많지만, 전부 나열하기에는 끝도 없어보인다. (MySQL 은 안쓴다. 그 대신 하둡을 쓴다.) 아직까지는 무엇을 우선순위로 삼고 공부해야 하는지 감이 잡히지 않으니, 현재로써는 회사에 합류하여 도메인을 파악하고 내가 어떤 것을 우선순위로 삼고 공부해야하는지 목표로 해두자! 정도만 생각해 두고있다.

그럼에도 서버 개발자 1년차동안에는 개인적으로 공부해보고 싶은 것을 간략히 나열해보면 다음과 같다.

MSA 이벤트 드리븐 : 마이크로서비스 아키텍처 구축 발췌독

Hadoop 및 데이터 파이프라인 : 데이터 중심 애플리케이션 설계

Redis : 개발자를 위한 레디스

네트워크 : 컴퓨터네트워크 - 한양대학교 이석복 교수님

마치며

그 누구보다 열심히, 피땀흘리며 살았다고 자부할 수 있을만큼 LINE 이라는 좋은 기업에 취업하게 되었다. 신입임에도 불구하고 LINE 서버 개발자 경력 포지션으로 합류하게 되었다. 채용 한파를 뚫고, 다른 경력직 지원자를 모두 제치고, 치열한 경쟁률을 모두 이겨내며 LINER 가 되었다.

앞으로는 현직자로써 어떤 개발자가 되고 싶은지, 어떤 커리어를 쌓아나가며 어떤 꿈을 중.장기적으로 이루고 싶은지 고민하면서 살 것이다. 훌륭한 개발자가 될 수 있도록 꾸준한 페이스로, 멋진 사람이 되도록 살아나가야 겠다.

MSA 환경에서 SAGA 패턴과 2PC 패턴를 통해 분산 트랜잭션 구현하기

Sat, 11 Jan 2025 00:00:00 GMT

MSA 환경에서 글로벌 트랜잭션 구현하기

기존 모놀리식 환경에서는 DBMS 가 트랜잭션의 ACID 를 보장해주었다. 이는 로컬 트랜잭션으로 동작하기 덕분이다. 트랜잭션 작업 중 일부가 실패하면, 전체 작업을 커밋 또는 롤백하는 구현이 간단했다.

하지만, MSA 환경에서는 하나의 기능이 여러 마이크로 서버를 걸쳐서 수행된다. 즉, MSA 환경에서는 하나의 트랜잭션이 마이크로 서비스의 물리적인 로컬 트랜잭션 여러개가 묶여서 구성된다. 더 이상 DBMS 가 지원하는 단순한 로컬 트랜잭션 만으로는 데이터 일관성을 유지할 수 없게 된다. 일부 마이크로 서버에서 로컬 트랜잭션 커밋에 실패하여 롤백하게 되면, 데이터 일관성을 깨지게 된다.

예를들어 MSA 환경에서 회원 서비스, 멤버쉽 혜택 관리 서비스, SNS 친구 관리 서비스가 있다고 해보자. 각 마이크로 서비스는 독립적인 데이터베이스를 바라보고 있다. 이때, 유저가 회원가입을 시도하면 어떻게될까? 우선 (1) 회원 서비스에서 회원가입과 동시에 회원 데이터를 데이터베이스에 저장하는 트랜잭션이 생성될 것이다. 그리고 (2) 신규 회원을 위한 멤버쉽 혜택을 회원 서버에게 전달하며, 신규 회원을 위한 멤버 혜택 정보 및 등급을 저장하는 트랜잭션이 실행된다. 마지막으로 (3) 친구 추천을 제공하기 위한 트랜잭션이 실행된다.

각 트랜잭션 1, 2, 3은 서로 다른 마이크로 서비스내의 완전히 분리된 데이터베이스에서 동작한다. 그런데 트랜잭션 2를 실행하다 장애가 발생하여 롤백해야 한다면? 트랜잭션 1은 이미 커밋된 상황이라면 어떻게 될까? 아불싸. 달리 방법이 없다. 각 트랜잭션들은 별도의 처리가 없다면 로컬 트랜잭션으로 동작하므로 각자 알아서 커밋되고, 롤백되기 때문이다. 2번 트랜잭션을 수행하다 장애가 터져 트랜잭션 1, 2를 모두 함께 롤백하고 싶다면, 이 로컬 트랜잭션들을 하나의 트랜잭션 덩어리로 묶어서 커밋, 롤백하는 기법이 필요하다. 이를 글로벌 트랜잭션(Global Transaction) 이라고 한다.

그렇다면, MSA 환경에서 여러 마이크로 서비스에 걸친 로컬 트랜잭션들을 마치 하나의 트랜잭션으로 합쳐서 수행하는 방법으로 무엇이 존재할까? 즉, 글로벌 트랜잭션 구현 방법 종류에 어떠한 것들이 있을까? 이 구현 방법에는 크게 2PC 와 SAGA 패턴이 있다.

글로벌 트랜잭션

글로벌 트랜잭션과 관련해서는 글로벌 트랜잭션 (feat. GTID) 에서도 간단히 다룬적이 있다. 복습 차원에서 다시 개념을 짧게 학습해보겠다.

만약 하나의 트랜잭션에서 데이터베이스 여럿에 접근해 데이터를 추가해야 한다면 어떻게 해야할까? 또는 데이터베이스에 데이터를 추가하고, 그 이후에 메시지 큐에 메시지를 추가하는 작업을 하나의 트랜잭션으로 묶고 싶다면? 즉, 2개 이상의 작업 단위를 하나의 트랜잭션으로 처리하고 싶다면?

이는 앞서 설명했듯이 로컬 트랜잭션으로는 처리가 불가능하다고 했다. 로컬 트랜잭션은 하나의 커넥션에 종속적이기 떄문이다. 따라서 다수의 자원 및 작업에 대한 요청을 하나의 트랜잭션으로 처리하기 위해선 각 DB 에 종속적으로 만들어지는 커넥션을 통해서가 아니라, 별도의 트랜잭션 매니저를 통해 트랜잭션을 관리하는 글로벌 트랜잭션 방식으로 처리해야한다.

스프링 진영에서는 JTA(Java Transaction API) 라는 트랜잭션 매니저 API 를 제공하고 있다. 스프링에서는 JTA 기반 트랜잭션 매니저에 글로벌 트랜잭션(2PC) 가 구현되어 있다고 했었다.

2PC(Two-Phase Commit) 패턴

2PC 에 대해 다시금 학습해보자. 2PC 는 글로벌 트랜잭션 (feat. GTID) 에서도 간단히 다룬적이 있다. 2PC 는 코디네이터(coordinator) 와 독립된 여러 데이터베이스간의 합의를 통해 트랜잭션이 커밋/롤백이 결정된다. (어쩌면 합의라는 표현보다는, 코디네이터와 DB 간의 질의를 통해 커밋/롤백이 결정된다고 표현하는 것이 적합하겠다.)

2PC(Two-Phase Commit) 은 이름 그대로 두 단계의 Phase 를 거쳐서 트랜잭션을 수행한다. 각 Phase 에서는 어떠한 작업을 수행하는가? 글로벌 트랜잭션 수행되는 플로우를 3단계로 나누어보면 아래와 같다.

(1) 코디네이터(트랜잭션 매니저) 는 트랜잭션을 시작하고, 각 데이터베이스에게 쿼리를 날려 연산을 수행한다.
(2) 1-Phase : 1-Phase 에서는 Coordinator 가 각 데이터베이스에게 커밋을 해도 되는지 (또는 롤백해야 하는지) 를 질문한다. 이에 따라 글로벌 트랜잭션에 참여하는 각 데이터베이스는 커밋이 가능한 상태 또는 불가능한 상태임을 코디네이터에게 응답한다.
(3) 2-Phase : 1-Phase 응답 과정을 분석하여, 코디네이터는 모든 트랜잭션을 커밋 또는 롤백할지 결정한다.

1-Phase 는 Prepare 과정으로도 불리고, 2-Phase 는 Commit 과정으로 불린다. 두 단계의 Phase 로 나뉘므로 Two-Phase Commit 으로 불린다. 이를 통해 서로 다른 DB 간의 정합성을 보장할 수 있다.

그리고 그림을 보면 알 수 있듯이, 데이터에는 쓰기 시작할 때 부터 커밋할 때 까지 락을 건다. 따라서 두 데이터베이스를 함께 조회하더라도 커밋되지 않은 쪽은 락이 잡혀있어서, 두 데이터베이스가 불일치된 상태로 조회되지 않는다. 즉, 락을 이용해 정합성을 보장한다. Phase-1 에서 모든 리소스(데이터베이스) 가 OK 응답을 보재면, Phase-2 에서는 모든 리소스 매니저에게 Commit 을 지시하고, 락도 해제한다.

단점

다만, 2PC 패턴은 아래의 단점들로 인해 MSA 환경에서 잘 사용되지 않는다.

락을 사용하므로 성능이 저하된다.
NoSQL 등 일부 DBMS 에서 지원하지 않는 경우가 존재하여, 2PC 를 구현 불가능한 경우가 있다.
이종의 DBMS 에서는 사용하기 어렵다.
MSA 에서 일반적으로 마이크로 서비스는 각자의 데이터베이스를 소유하고, 다른 마이크로 서비스에게는 Public API 를 통해 데이터를 제공한다. 여러 데이터베이스에 걸친 글로벌 트랜잭션을 하나의 코디네이터가 관리하는 구조에서 적합하지 않다.
코디네이터에 의존적이다. 코디네이터 장애 상황에서 각 데이터베이스는 커밋/롤백 여부를 스스로 결정할 수 없다.

SAGA 패턴

SAGA 패턴은 MSA 같은 분산 환경에서 데이터 일관성을 보장하기 위해 등장한 설계 패펀이다. 이 패턴에서는 연속된 개별 마이크로 서비스에서 로컬 트랜잭션이 실행되고 이어지면서, 전체 비즈니스 트랜잭션을 구성한다. 첫번째 트랜잭션이 완료되면 두번째 트랜잭션이 트리커 되고, 두번째 트랜잭션이 완료되면 3번째 트랜잭션이 트리커된다.

만약 트랜잭션 중 하나가 실패하면, SAGA 패턴은 이미 성공적으로 완료된 로컬 트랜잭션들을 **보상 트랜잭션(compensating transaction)**을 발생시켜 모두 취소하여 전체 데이터 일관성을 유지한다. 보상 트랜잭션이란 이전에 커밋된 트랜잭션을 취소하는 연산이다. 즉, SAGA 패턴에서는 데이터 일관성을 보장하는 주체가 DBMS 가 아니라 애플리케이션이다. 이것이 핵심이다. 보장 트랜잭션이 적용되기 전까지 일시적으로 데이터베이스 일관성이 잠시 깨져있을 수 있으나, 보장 트랜잭션이 완료되면 "결과적으로" 정합성을 보장한다.

💡 보상 트랜잭션은 이미 발생한 트랜잭션이 만들어낸 변경을 되돌리기 위해 새로운 트랜잭션을 추가하는 방식이다. 고객이 이미 결제 금액을 지불했다면 지불된 돈을 돌려주는 것이고, 고객에게 포인트를 부여했다면 그 포인트를 다시 회수하는 것이 보상 트랜잭션의 예시가 될 수 있다. 이렇기 때문에 보상 트랜잭션을 의미론적인 롤백(semantic rollback) 이라고도 말한다.

SAGA 패턴는 2가지 종류가 있다. 코래오그래피 기반 사가와 오케스트레이션 기반 사가 이 2가지가 있다.

코레오그래피 기반 사가 (Choreography-based Saga)

각 마이크로 서비스는 트랜잭션이 완료되면, 완료 이벤트를 메시지 큐에 발행한다. 만약 그 다음에 수행되어야 할 로컬 트랜잭션이 있다면, 해당 이벤트를 구독한 마이크로 서비스가 이어서 로컬 트랜잭션을 실행한다. 이때 만약 중간에 로컬 트랜잭션이 실패하면, 이를 상쇄하기 위한 보장 트랜잭션 이벤트를 발생하여 롤백을 시도한다.

장점

구성이 편리하다
하나의 서비스에 장애가 터져도, 시스템 나머지 부분이 영향을 덜 받는다.

단점

SAGA 참여자가 많을 경우 트랜잭션 흐름이 복잡하고, 길어진다.
마이크로 서비스간 순환 종속성이 발생할 수 있다.
각 마이크로 서비스가 서로를 알고있는 구조로, 결합도가 높다.

오케스트레이션 기반 사가 (Orchestration-based Saga)

중앙 집중된 1대의 SAGA Orchestrator(코디네이터) 가 SAGA 참여자들에게 어떤 로컬 트랜잭션을 실행해야하는지 알려주는 방식이다. 즉, 중앙화된 1대의 코디네이터가 전체 프로세스의 로컬 트랜잭션 실행 순서를 정의하고, 필요하다면 보상 트랜잭션을 발생시켜 롤백한다.

징점

모든 로컬 트랜잭션을 오케스트레이터가 관리하여, 트랜잭션 흐름이 명확하다. (모니터링 하기도 쉬워질 것이다.)
각 마이크로 서비스는 서로를 알 필요가 없다. 따라서 결합도가 낮다.

단점

오케스트레이터가 중앙 집중되어 SPOF(단일 장애 지점) 이 될 수 있다.
같은 이유로 확장성과 유연성이 낮다.

정리

MSA 환경에서 각 마이크로 서비스별로 데이터베이스를 분리하는 것은 일반적인 패턴이다. 데이터베이스를 분리할 때는 서비스간의 독립성과 확장성을 확보할 수 있다는 장점이 있지만, 서비스 전체의 데이터 일관성을 유지하는 것이 기존의 단일 데이터베이스보다 어려워진다는 이슈도 존재한다.

이를 해결하기 위해 2PC 와 같은 2단계 커밋 프로토콜이 등장하기도 했지만, 이는 모든 DB 가 응답할 떄까지 코디네이터가 기다려야하는 방식이므로 네트워크 지연등으로 인해 전체 트랜잭션 처리 시간이 길어질 수 있다는 성능 문제가 있다.

이후 등장한 SAGA 패런은 연속적인 로컬 트랜잭션의 조합으로 데이터 일관성을 유지하고 하는데, 2PC 과 달리 특정 데이터에 락을 걸지 않아도 된다는 장점이 있다.

코레오그래피 기반 사가 vs 오케스트레이션 기반 사가

SAGA 패턴의 구현 방식 2가지 중 어떤 방식을 선택하는게 적합할까? 우선 코레오그래피 방식은 마이크로 서비스간의 결합도가 낮고 중앙화된 코디네이터를 필요로 하지 않기 떄문에, 오케스트레이션 방식에 비해 장점이 크다고 보지만 그만큼 프로세스의 실행 순서와 진행 상황을 파악하고, 모니터링하기 어렵다. 따라서 코레오그래피 방식은 팀 내에서 적절한 모니터링과 로깅, 이벤트 전략을 갖추었을 때에만 선택하는 것이 적합하다.

SAGA 패턴은 트랜잭션이 격리(Isolation)되지 않는다

SAGA 패턴은 트랜잭션 ACID 원칙 중에 격리성(Isolation) 을 보장하지 않는다. 따라서 이를 고려한 설계가 필요하다.

참고

MSA 환경에서 BulkHead 패턴을 사용한 장애 전파 최소화하기

Fri, 10 Jan 2025 00:00:00 GMT

BulkHead 패턴

벌크해드란 한국어로 번역하면 격벽을 뜻한다. 격벽이란 선박의 공간을 여러 구획으로 분할하고자 사용되는 벽을 의미한다.

벌크헤드 패턴은 선박의 격벽으로부터 영감을 받아 만들어졌다. 리소스를 격리하여, 일부 컴포넌트에 장애가 발생하더라도, 그 장애가 시스템 전체로 전파되는 것을 막게끔 하는 패턴이다.

BulkHead 패턴 미사용시 장애 발생

빠른 학습을 위해 참고1 과 참고2 를 다수 참고하여 학습을 이어가보도록 하겠다. MSA 환경에서 서비스 A, B, C 가 존재한다고 해보자. 서비스 A 의 B-API 는 서비스 B 를 호출하여 응답을 만들고, C-API 는 서비스 C 를 호출하여 응답을 만들어낸다고 해보자.

그런데, 서비스 B에서 장애가 발생하여, 응답을 매우 느리게 주는 상황이라면 어떻게 할까? 이런 상황에서 서비스 A의 B-API 호출이 발생한다면, 서비스 A 는 서비스 B의 응답을 기다리느라 쓰레드를 계속 점유할 것이다. 장애 시간이 길어짐에 따라, 서비스 A의 톰캣 쓰레드 풀은 고갈될 것이다. 그렇다면 C-API 는 서비스 B에 의존하지 않지만, 톰캣 쓰레드를 할당받지 못하여 덩달아 장애 전파 영향력을 받게 된다.

BulkHead 패턴을 적용하면?

여기에 BulkHead 패턴을 사용하게 된다면? 두 쓰레드 풀을 격리하면 어떻게 될까? 여전히 서비스 B에 의존적인 B-API 의 요청을 철하는 쓰레드 풀은 고갈 상태가 유지되지만, 서비스 C에 의존적인 C-API 의 요청을 처리하는 쓰레드 풀은 고갈 상태가 아니므로, 서비스 B 장애 여부와 무관하게 요청을 잘 처리할 것이다.

즉, BulkHead 패턴의 핵심 아이디어는 "리소스 격리를 통한 장애 격리" 이다. 앞서들은 예시에선 쓰레드 풀을 예로 들었지만, 커넥션 풀과 같은 다른 자원에도 이 패턴을 적용해서 장애 격리를 해볼 수 있다. 또한 꼭 리소스 풀을 물리적으로 분리하지 않고도, 세마포어 등의 상호배제(Mutual Exclusion) 기법을 사용해서 BulkHead 패턴을 구현해볼 수 있다.

BulkHead 패턴 구현을 통한 장애 격리

백문이 불여일타. 간단한 실습을 통해 BulkHead 패턴을 적용해보자. 우리는 의도적으로 장애 전파가 발생하는 상황을 가정해보고, 이에 BulkHead 패턴을 적용하여 장애를 격리해볼 것 이다.

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class Main {
    public static void main(String[] args) {
        ExecutorService tomcatThreadPool = Executors.newFixedThreadPool(4);

        long startTime = System.currentTimeMillis();

        for (int i = 0; i < 4; i++) {
            tomcatThreadPool.execute(() -> callBService(startTime));
        }

        for (int i = 0; i < 4; i++) {
            tomcatThreadPool.execute(() -> callCService(startTime));
        }

        tomcatThreadPool.shutdown(); // 작업 완료 후 shutdown
    }

    public static void callBService(long callTime) {
        System.out.println("* 서비스 B 호출 완료 | 소요 시간: " + (System.currentTimeMillis() - callTime) + "ms");
    }

    public static void callCService(long callTime) {
        System.out.println("* 서비스 C 호출 완료 | 소요 시간: " + (System.currentTimeMillis() - callTime) + "ms");
    }
}

위 코드를 실행하면, tomcatThreadPool 의 쓰레드들은 서비스 B 를 호출하기 위해 모두 할당된 후, 작업을 잘 마치고 난 뒤 서비스 C 를 호출하기 위해 할당될 것이다. 그럼 아래와 같이 정상적으로 작업이 완료된다.

* 서비스 B 호출 완료 | 소요 시간: 1ms
* 서비스 B 호출 완료 | 소요 시간: 1ms
* 서비스 B 호출 완료 | 소요 시간: 1ms
* 서비스 B 호출 완료 | 소요 시간: 1ms
* 서비스 C 호출 완료 | 소요 시간: 6ms
* 서비스 C 호출 완료 | 소요 시간: 6ms
* 서비스 C 호출 완료 | 소요 시간: 6ms
* 서비스 C 호출 완료 | 소요 시간: 6ms

그런데 서비스 B의 데이터베이스에 장애가 발생하여, 서비스 B가 굉장히 느리게 응답을 하기 시작했다. 이를 아래처럼 Thread.sleep() 을 사용해서 표현한다.

public static void callBService(long callTime) {
    try {
        Thread.sleep(20_000); // 데이터베이스 장애로 인해 응답이 매우 느림
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt(); // 인터럽트 상태 복구
        System.out.println("서비스 B 호출 중 인터럽트 발생");
    }
    System.out.println("* 서비스 B 호출 완료 | 소요 시간: " + (System.currentTimeMillis() - callTime) + "ms");
}

이렇게 서비스 B 에 장애가 발생한 상황에서는. 서비스 B를 호출하기 위한 쓰레드를 비정상적으로 오래 보유한다. 그렇게 되면 서비스 C만 필요한 요청이 톰캣 쓰레드를 할당받지 못하고, 아래처럼 장애가 전파될 것이다.

* 서비스 B 호출 완료 | 소요 시간: 20008ms
* 서비스 C 호출 완료 | 소요 시간: 20026ms
* 서비스 C 호출 완료 | 소요 시간: 20027ms
* 서비스 C 호출 완료 | 소요 시간: 20027ms
* 서비스 C 호출 완료 | 소요 시간: 20027ms
* 서비스 B 호출 완료 | 소요 시간: 20008ms
* 서비스 B 호출 완료 | 소요 시간: 20007ms
* 서비스 B 호출 완료 | 소요 시간: 20007ms

서비스 C를 호출하는 함수는 호출 즉시 결과를 반환할 수 있었으나, 서비스 B 호출로 인해 쓰레드 풀이 밀려 정상적으로 쓰레드를 할당받지 못하게 되었고, 그 결과 서비스 C를 호출하는 함수의 응답까지 덩달아 굉장히 느려졌다. 장애가 전파된 것이다. 실제 스프링 애플리케이션이었다면, 타임아웃이 발생하여 아예 응답을 주지 못하고 예외가 발생했을수도 있다.

BulkHead 를 적용해 장애 격리

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class Main {
    public static void main(String[] args) {
        ExecutorService bulkheadForB = Executors.newFixedThreadPool(4);
        ExecutorService bulkheadForC = Executors.newFixedThreadPool(4);

        long startTime = System.currentTimeMillis();

        // 서비스 B는 bulkheadForB에서 실행
        for (int i = 0; i < 4; i++) {
            bulkheadForB.execute(() -> callBService(startTime));
        }

        // 서비스 C는 bulkheadForC에서 실행
        for (int i = 0; i < 4; i++) {
            bulkheadForC.execute(() -> callCService(startTime));
        }

        // 작업 완료 후 자원 해제
        bulkheadForB.shutdown();
        bulkheadForC.shutdown();
    }

    public static void callBService(long callTime) {
        try {
            Thread.sleep(20_000); // DB 장애로 지연
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            System.out.println("서비스 B 인터럽트 발생");
        }
        System.out.println("* 서비스 B 호출 완료 | 소요 시간: " + (System.currentTimeMillis() - callTime) + "ms");
    }

    public static void callCService(long callTime) {
        System.out.println("* 서비스 C 호출 완료 | 소요 시간 : " + (System.currentTimeMillis() - callTime) + "ms");
    }
}

그럼 결과는 아래와 같을 것이다. 서비스 C를 호출하는 메서드는 더이상 서비스 B의 장애에 영향을 받지 않는다.

* 서비스 C 호출 완료 | 소요 시간: 2ms
* 서비스 C 호출 완료 | 소요 시간: 2ms
* 서비스 C 호출 완료 | 소요 시간: 2ms
* 서비스 C 호출 완료 | 소요 시간: 2ms
* 서비스 B 호출 완료 | 소요 시간: 20010ms
* 서비스 B 호출 완료 | 소요 시간: 20009ms
* 서비스 B 호출 완료 | 소요 시간: 20008ms
* 서비스 B 호출 완료 | 소요 시간: 20009ms

Resilience4j Bulkhead

실무에선 위와 같이 직접 BulkHead 를 구현할 필요가 없다. Resilience4j 에선 이미 벌크헤드 패턴 기능을 제공하기 떄문이다. Resilience4j의 Bulkhead 는 쓰레드 풀 또는 세마포어를 사용하여 동시 호출 수를 제어하며, 이에 따라 특정 작업으로 인해 과도한 리소스를 차지하지 않도록 리소스를 격리할 수 있도록한다.

application.properties 에 아래와 같이 추가한다.

resilience4j.bulkhead.instances.backendA.maxConcurrentCalls=4
resilience4j.bulkhead.instances.backendA.maxWaitDuration=0

maxConcurrentCalls 는 허용할 최대 동시 호출 수, maxWaitDuration 은 최대 동시 호출 수에 도달했을 때 추가 요청이 들어온 경우 얼마나 기다려줄 것인지를 나타낸다. 지금과 같은 설정은 최대 4개의 동시 요청을 허용하며, 5번째 요청부터는 즉시 실패하도록 한다. backendA 는 벌크헤드의 이름이다.

import io.github.resilience4j.bulkhead.annotation.Bulkhead;
import io.github.resilience4j.bulkhead.Bulkhead.Type;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class BulkheadController {

    @Bulkhead(name = "backendA", type = Type.SEMAPHORE)
    @GetMapping("/bulkhead")
    public String bulkhead() {
        try {
            Thread.sleep(10_000); // 10초 지연
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return "INTERRUPTED";
        }
        return "DONE";
    }
}

위와 같이 간단하게 컨트롤러를 작성했다. type 은 Bulkhead.Type.SEMAPHORE 와 Bulkhead.Type.THREADPOOL 두가지가 있으며, 생략하면 기본값은 세마포어이다. 해당 엔트포인트로 4개를 초과한 동시 요청을 넣게 되면, BulkheadFullException 이 발생한다.

참고

글로벌 트랜잭션 (2PC, XA, JTA Manager)

Wed, 08 Jan 2025 00:00:00 GMT

데이터베이스 레플리케이션에 대해 깊이있게 학습하던 중, GTID(Global Transaction ID) 에 대해 알게 되었다. 그런데, 이 중에 글로벌 트랜잭션이라는 키워드가 등장한다. 이 글로벌 트랜잭션이란 무엇인지에 대해 찾아보니, 레플리케이션에서 GTID 에 등장하는 글로벌 트랜잭션의 개념과 그냥 글로벌 트랜잭션은 전혀 다른 개념이었다. 글로벌 트랜잭션에 대해 글을 작성하며, GTID 에서 등장하는 개념과 무엇이 다른지 더 확실히 개념을 짚어보고자 한다.

글로벌 트랜잭션

지금까지 별다른 트랜잭션 처리가 없었던, 우리는 로컬 트랜잭션을 사용하고 있었던 것이 된다. 로컬 트랜잭션이란 하나의 데이터베이스의 커넥션에서 만들어지는 트랜잭션을 뜻한다. 그렇다면, 얼핏 글로벌 트랜잭션은 여러개의 데이터베이스 커넥션에서 만들어지는 개념일까 생각해 볼 수 있지만, 그건 아니었다.

상황을 하나 생각해보자. 만약 하나의 트랜잭션으로 여러개의 데이터베이스에 접근하여 연산을 처리하고 싶다면 어떻게 해야할까? 이는 앞서 설명한 로컬 트랜잭션으로는 처리가 불가능하다. 로컬 트랜잭션은 단 하나의 데이터베이스에만 커넥션이 종속적으로 연결되어 있기 때문이다. 우리가 원하는 것은, 한 트랜잭션에서 여러 데이터베이스에 커넥션을 맺고 연산을 처리하는 것이다. 하지만, 한 트랜잭션에서 하나의 커넥션으로 여러 데이터베이스에 접근한다는 것은 말이 되지 않는다.

이를 해결하는 방법이 바로 글로벌 트랜잭션이다. 글로벌 트랜잭션은 실제 여러개의 데이터베이스와 커넥션을 맺고 통신하는 방식이 아니라, 별도의 트랜잭션 매니저를 활용해 트랜잭션을 관리하는 방식이다. 즉, 트랜잭션에 참여중인 여러 독립적인 작업들 중에 하나라도 다른 데이터베이스에서 일어나는 경우를 처리하는 트랜잭션이다.

JtaTransactionManager

💡 JTA 는 Java Transaction API 의 준말로, XA 리소스 (분산 리소스) 간의 트랜잭션을 처리하는 API 이다.

이때, 자바는 글로벌 트랜잭션을 위해 JTA(Java Transaction API) 라는 트랜잭션 매니저의 표준 API 를 제공하여 글로벌 트랜잭션을 관리할 수 있도록 한다. (트랜잭션 추상화를 학습할 때 등장하는 그 개념이 맞다.) PlatformTransactionManager 라는 추상 인터페이스의 구현체로는 JDBC 를 활용한다면 DataSourceTransactionManager, JPA 를 활용하는 경우라면 JpaTransactionManager 구현체를 사용하게 되는데, 여러 리소스(데이터베이스) 를 사용하는 경우에는 JtaTransactionManager 를 활용한다. JtaTransactionManager 라는 구현체를 통해 우리는 JTA 라는 API 를 사용하여 글로벌 트랜잭션으로 동작하게 되는 것이다.

글로벌 트랜잭션 매니저인 JtaTransactionManager 는 데이터베이스와 메시징 서버를 제어하고 관리하는 각각의 리소스 매니저와 XA 프로토콜을 통해 연결된다. 이를 통해 트랜잭션 매니저가 여러 리소스에 대해 종합적으로 트랜잭션을 제어할 수 있게된다.

XA, 2PC

XA 란 2PC(Two-Phase Commit) 을 통한 분산 트랜잭션 처리를 위한 표준이다. 그리고 JTA 트랜잭션 매니저는 각 리소스 매니저간에 XA 프로토콜을 통해 통신한다고 했다. 보통 1PC 라면 begin, end, commit 의 절차로 수행되는 반면, 2PC는 begin, end, prepare, commit 의 절차로 수행된다. (이때, prepare 과정은 아마 트랜잭션에 참여한 리소스들이 서로 같은 리소스라고 확인하는 과정을 뜻하는 듯하다. 그 때문에 로컬 트랜잭션은 prepare를 안해도 되고, 1PC 로 처리된다. 정확한 개념은 추후 학습이 필요하다.)

2PC 는 둘 이상의 리소스에 대한 트랜잭션을 원자적으로(atomic) 처리하기 위한 알고리즘이다. 위에서도 다른 리소스 둘에 대한 요청을 원자적으로 처리하기 위해 1PC 에서 prepare, commit 이 추가되었다. 이 방법으로 서로 다른 데이터베이스간의 정합성을 보장할 수 있다고 한다.

GTID vs 글로벌 트랜잭션

그래서 GTID 에서 등장하는 글로벌 트랜잭션과 무엇이 다른가? GTID 에서 등장한 글로벌 트랜잭션은 레플리케이션 환경에서 트랜잭션을 전역적으로 유일하게 식별하고 추적한다는 점에 초점이 맞춰진 개념이다. 즉, 출처가 식별되는 트랜잭션 개념에 가깝다. 반면 위에서 살펴본 일반적인 의미의 글로벌 트랜잭션은 분산 데이터베이스 환경에서 하나의 논리적 작업 단위로 실행되는 트랜잭션을 의미한다. (실제로 레플리케이션 환경에서, 지금까지 학습했던 트랜잭션들은 커넥션을 맺었고, 각기 다르게 처리되었다.)

참고

MSA 환경에서 SAGA 패턴으로 안전한 분산 트랜잭션 구현하기

Thu, 02 Jan 2025 00:00:00 GMT

코어뱅킹 서버의 환전 기능

토스뱅크는 코어뱅킹 서버의 도메인들은 Oracle DB 를 그대로 참조하고 있다. 반면 새롭게 개발중인 도메인들은 MySQL 을 참조한다. 예를들면 예전부터 존재했던 원화 계좌 서버는 변동없이 기존 코어뱅킹의 데이터베이스인 Oracle 을 참조하고 있다. 반면 신규 상품인 외화 계좌 서버는 DB 까지 분리된 MSA 환경에서 MySQL 을 참조하고 있다.

즉, 환전 기능은 데이터베이스와 마이크로 서버 모두가 독립적으로 분리된 원화 계좌 서버, 외화 계좌 서버로 2개를 동시에 활용하며 구현되어야 했다. 토스뱅크의 환전 기능은 토스뱅크 앱으로 간편하게 원화를 지불하고 외화로 바꿔받는 기능이다. (또는 그 반대이다.)

여기서 문제는, 원화 계좌 서버와 외화 계좌 서버가 서로 다른 데이터베이스를 바라보고 있다. 이에 따라 분산 트랜잭션 기법이 필요함을 느낄 수 있다. 즉, 글로벌 트랜잭션을 구현해야 한다.

분산 트랜잭션 구현하기 (2PC vs SAGA)

2PC 와 SAGA 패턴은 MSA 환경에서 SAGA 패턴과 2PC 패턴를 통해 트랜잭션 일관성 보장하기 에서도 다룬적이 있다. 코어뱅킹 서버의 환전 기능에는 어떠한 구현 방식이 적합할까?

2PC 의 경우 모든 데이터에 락을 걸기도 하고, 글로벌 트랜잭션에 참여하는 모든 참여자로부터 OK 신호를 받을 때 까지 기다려야한다. 즉, 참여자중에 트랜잭션 처리가 가장 느린 참여자들을 위해 다른 모든 참여자들이 대기해야하므로 성능이 느리다.

반면 SAGA 패턴의 경우 각 서비스들에서 로컬 트랜잭션만 진행한다는 점에서 높은 가용성과 확장성을 갖는다. 몰론 일부 로컬 트랜잭션들만 커밋된 중간 상태가 노출되며, 롤백을 위한 보장 트래잭션을 직접 구현해야 한다는 단점이 있긴하다. 하지만 토스뱅크는 환전 서비스가 높은 트래픽을 견디고 카드, 회계등 다른 참여자들도 향후에 더 생길 수 있다는 점에서 SAGA 패턴을 택했다.

오케스트레이션 기반 사가 vs 코레오그래피 기반 사가

코레오그래피 사가는 중앙 제어가 없기 떄문에 SPOF 가 발생하지 않고, 각 서비스들간에 메시지 큐를 활용해 통신하므로 결합도가 느슨하다.

하지만, 토스뱅크는 모니터링이 중요했기 떄문에 오케스트레이션 사가를 택했다. 클라이언트 요청을 받아 환전을 시작하는 환전 서버가 필요했고, 현재 진행중인 환전들의 상태를 실시간으로 관리해야 했기 떄문이다. 예를들어 환전 한도를 구현하려면, 현재 진행중인 환전의 금액과 상태도 추적해야 했기 떄문이다.

환전 구현 방법

환전 기능 이해를 위해, 한화 1300원을 지불하고 외화 1달러를 지급받는 것을 가정해보자. 이떄, 실패 하는 경우를 가정해보겠다. 실패의 종류는 (1) 정상적인 실패와 (2) 비정상적인 실패(에러) 로 나뉜다.

정상적인 실패란 잔액 부족, 고객/계좌 거래 제한등으로 인해 입출금이 실패하는 것으로, 당연히 실패하는 것이 정상적인 케이스를 뜻한다. 반대로 네트워크 에러, 타임아웃등의 에러가 발생하는 경우이다.

환전 실패 CASE1 - 입금 실패

만약 사용자가 원화 계좌로 1300원을 출금하는데는 성공했지만, 외화 계좌로 1달러는 입금받는데 실패했다면 어떻게 처리해야할까? 이는 SAGA 패턴에서 보상 트랜잭션을 통해 롤백하여, 원화 계좌로 입금된 1300원을 사용자에게 원상태로 되돌려줘야 한다.

이를 위해 보장 트랜잭션을 내부 로직을 원화 계좌로 1300원을 입금해주는 방식으로 구현하여, 사용자에게 돈을 다시 되돌려줄 수 있다. 즉, 유저 입장에서는 -1300원 되었던것이 다시 +1300원 되어 0원이 되어서, 원상 복귀 된 것이다.

왜 출금이 입금보다 선행 되어야 할까?

SAGA 패턴의 특성상, 일부 로컬 트랜잭션만 커밋된 중간 상태가 노출될 수 있다고 했었다. 이 특성 때문에 출금이 입금보다 선행되어야 한다. 만약 입금이 선행된다면 무슨 문제가 발생할까?

외화 계좌로 1달러를 가장 먼저 입금했다고 해보자. 그 두에 원화 계좌로부터 1300원을 출금해오려고 하는데, 이때 실패하여 보상 트랜잭션으로 롤백해야한다. 그런데 이때, 카드 서버에서 결제 요청이 와서 외화 계좌로 부터 입금되었던 1달러를 가져간다면, 외화 계좌는 0달러가 된다. 맙소사. 이 상황이 발생하면 보상 트랜잭션 처리가 불가능해진다. 외화 계좌가 카드 결제로 인해 1달러에서 0달러로 변했으므로, 현재 잔고 0달러에서 1달러를 가져오는 것은 불가능하기 때문이다. (계좌 잔고가 0달러에서 1달러가 출금되어 -1달러가 되는건 말이 안되니깐.)

즉, 환전을 입금부터 실행하면 환전이 끝나기전에 다른 트랜잭션에서 입금한 돈에 개입하여 출금해버릴 수 있다. 따라서 환전 기능은 반드시 출금이 선행되어야 한다.

입금, 출금시 통신 방식 (HTTP vs Kafka)

이때, 입출금시 어떠한 통신 방식으로 통신하고 있을까? 크게 HTTP 와 Messaging 방식이 있을 것이다.

대부분 SAGA 패턴에서는 Messaging 방식으로 구현된다. 비동기 방식이며, 서비스간 결합도가 느슨해지며, 메시지 브로커 레벨에서 재시도와 같은 애러 핸들링을 지원하기 때문에 데이터에 대한 결과적 정합성을 보장하는데 유리하다.

하지만, 토스뱅크는 HTTP 통신 방식을 택했다. 그 이유는 (1) 출금 결과를 반드시 알고 입금으로 넘어가야 하기 때문이다. (By 동기 방식) 그리고 (2) 유저에게 환전이 즉시 완료되기를 알려줘야 하기 때문이다. 만약 환전 기능이 지연되었다면 유저에게 환전이 지연되었음을 알려줘야 하는데, 이 경우 타임아웃 기능이 필요하다. 타임아웃을 비동기 메시징 방식으로 구현하려면 입출금 결과를 다시 메시지로 받고 Polling 하는 등의 구현 복잡도가 높아진다.

출금 취소는 Messaging

반면 보상 트랜잭션의 구현 내용인 출금 취소는 Messaging 방식을 택했다. 그 이유는 (1) 출금 취소는 마지막 과정이며, (2) 유저가 이를 기다릴 필요가 없기 떄문이다. (돈이 실제로 다시 입금되는 것을 동기로 기다릴 필요는 없다.) 그리고 (3) 출금 취소 또한 실패할 수 있다. 이미 입금이 실패했기 때문에, 출금된 돈은 반드시 유저에게 돌려줘야한다. 그런데 이런 애러 핸들링을 메시지브로커 원화 계좌 컨슈머에게 위임한다면, 결과적 정합성을 보장하기 유리할 것이다.

비정상적인 에러 핸들링

환전 서버에서 원화 계좌 서버로 출금 요청을 보냈을 때 타임아웃이 발생했다면 어떻게 해야할까? 타임아웃 자체가 나버리면 원화 계좌 서버에서 요청을 정상적으로 처리했는지 안했는지, 즉 성공/실패를 확정할 수 없다.

이는 원화 계좌 서버로 다시 출금 결과룰 재확인(Retry)하여 그에 따라 조취한다. 재확인 결과로, 만약 출금에 성공했음을 알게 되었다면 출금 취소를 처리하면 된다. 반대로 출금에 실패했다면 요청 자체가 실패한 것이므로, 추가적인 조취 없이 환전을 실패 처리하면 끝이다.

입금의 경우도 마찬가지이다. 입금 요청에서 타임아웃이 발생하면 입금 결과를 다시 재확인한다. 그 결과로 입금에 성공했음을 알게 되면 출금과 입금 모두 성공한 것이므로 환전을 성공 처리하면 된다. 반대로 입금에 실패했다면, 앞서 출금했던 내역을 보장 트랜잭션으로 취소한다.

재확인조차 못한다면?

만약 상대방 서버(외화 계좌, 원화 계좌) 자체에 장애가 터져거나 네트워크 병목이 발생하여 재확인 조차 못한다면 어떻게 해야할까? 이 해결법은 확정할 수 없는 모종의 네트워크 에러/지연 문제를 안전하게 서비스하기 에서도 다룬적이 있다. 바로 카프카와 같은 메시지 큐를 이용하면 된다.

토스뱅크에는 메시지를 지연시켜서 발행할 수 있는 카프카 메시지 스캐줄러 서버가 존재한다. 일반적인 경우, Producer 가 메시지를 발행하면 그 즉시 메시지 브로커를 통해 컨슈머에게 메시지가 전달된다. 그런데 여기에, 메시지에다 지연시간 값을 넣어서 메시지를 발행하면 별도의 지연 Topic 을 거쳐서 메시지가 카프카 메시지 스캐줄러에게 전달된다. 카프카 메시지 스캐줄러는 메시지를 지연시간만큼 대기시킨 후, 원래의 Topic 에 메시지를 다시 발행하여 컨슈머가 해당 메시지를 가져갈 수 있게 유도한다.

이때, Producer 와 Consumer 를 모두 환전 서버가 된다면 어떤 효과가 있을까? Kakfa 에 발행한 메시지를 지연 시간만큼 지연된 후 다시 자기 자신에게 되돌려받는 셈이다. 이 방법을 활용하여, 상대 서버가 회복(Recovery) 할 시간을 줄 수 있다. 만약 아직도 회복하지 못한 상태라면, 재요청하는 시간대를 더 늘리면 된다.

환전 서버가 다운되었다면?

만약 환전 서버에 장애가 터져서, 환전 지연 메시지를 카프카 메시지 스캐줄러에 발행하지 못하고 죽었다면 어떻게 해야할까?

이런 경우는 Batch 를 통해 재처리 할 수 있다. 오케스트레이션 SAGA 패턴으로 구현된 환전 서버가 환전 트랜잭션의 마지막 상태를 저장하고 있기 떄문에 (어떤 로컬 트랜잭션까지 실행되었는지 알고 있기 떄문에) 트랜잭션이 중단된 구간부터 다시 재개하면 된다.

예를들어 출금이 성공하고 멈춰버린 환전의 경우에는, 배치가 출금 취소 메시지를 발행한 후에 환전을 실패 처리할 수 있다.

지금까지의 과정을 요약하면, 입출금 요청에서 애러가 발생했을 때 기본적으로 입출금 결과를 다시 확인하여 재처리하고, 네트워크 병목으로 인해 확인 자체를 못한다면 환전 지연을 통해 계좌 서버에게 회복할 시간을 준다. 그런데 이러한 환전 지연까지 못했을 경우네는 최종적으로 배치를 통해 환전을 재시작할 수 있다.

원화 계좌 서버가 출금 취소 메시지를 처리하다 애러가 발생했다면?

토스뱅크는 위 애러 처리를 위해 CDL(Consumer Dead Letter) 메시지 브로커를 통해 카프카 메시지의 정합성을 보장하고 있다. 원화 계좌 서버가 애러가 발생하면 CDL 메시지 브로커릃 통해 메시지를 DL 서버로 전송한다.

그리고 이 DL 서버는 정해진 재시도 횟수와 간격으로 서비스 메시지 브로커를 다시 전달하여 원화 계좌 서버의 출금 취소를 재시도한다.

Transaction Mesaging

SAGA 패턴에서는 로컬 트랜잭션 커밋과 메시지 발행이 원자적으로 함께 이루어져야한다. 즉, 입금 실패로 인한 환전 실패 처리와 출금 취소 메시지 발행은 항상 같이 이루어져야 한다. 그런데, 서비스 몌시지 브로커 장애 등으로 메시지 발행 자체가 안되면 이를 어떻게 보장할 수 있을까?

PDL (Producer Dead Letter)

트랜잭션 메시징을 보장하는 방법에는 여러가지가 있지만, 토스뱅크는 그 중에 PDL 기법을 택하고 있다. 환전 서버가 서비스 메시지 브로커의 장애로 메시지 발행에 실패했을 경우에는 Producer 메시지 브로커로 메시지를 대신 발행하여 DL 서버로 메시지를 전달한다. 그리고 이 DL 서버는 일정 시간이 지난 후 회복된 서비스 메시지 브로커로 메시지를 다시 전달하여 원화계좌 컨슈머가 가져갈 수 있도록 한다.

더 학습해볼 주제 및 궁금점

Kafka Message Scheduler 를 통해 지연 시키는 방법과, 지난 Exponential 지연 방식과 어떤 연관이 있을까?

Next 코어뱅킹, MSA와 MySQL로 여는 평생 무료 환전 시대

Thu, 02 Jan 2025 00:00:00 GMT

왜 모든 은행은 Oracle 만 사용하고 있을까?

기존 토스뱅크의 코어뱅킹 시스템을 아울러, 대부분의 은행은 Oracle 데이터베이스를 사용하고 있다. 어떤 장점에서 오라클 데이터베이스를 사용하고 있었을까? (1) 신뢰성과 안정성이 뛰어나다. 트랜잭션 관리, 고가용성, 복구 기능, 데이터 무결성 보장등의 측면에서 좋다. (2) 확장성이 좋다. 매우 큰 데이터 볼륨을 처리할 수 있는 뛰어난 확장성을 갖는다. (3) 성능도 좋다. 복잡한 트랜잭션 처리와 대규모 데이터베이스 쿼리에 효과적이다. (4) 오랜기간 축적된 노하우가 있다.

반면 오라클 데이터베이스는 치명적인 단점이 있다. 바로 (1) Scale Out 이 제한적이라는 점이여서, 유연한 대처가 어렵고 SPOF 가 발생한다. 또한 (2) MySQL 대비 비싼 라이센스 비용을 갖는다. 오라클의 경우 CPU 코어수에 비례하여 비용이 증가한다. (이 때문에 토스뱅크는 SPOF 를 해결하고자 각 마이크로 서버에게 서로 다른 Oracle 데이터베이스를 바라보게 하는 전략을 고려했지만, CPU 코어 수에 비례하는 비용 증가 문제로 인해 택하지 않았다.)

이 떄문에 MySQL 을 도입했다. MySQL 은 Oracle 대비 확장성에 유리하다. 레플리케이션과 같은 전략을 통해 유연한 Scale Out 이 가능하고, 비용도 Oracle 대비 저렴하다. 또한 MySQL 은 MVCC 기술을 사용하기 떄문에 동시성 제어에도 유리하다. 이 외에도 Oracle 을 사용할 이유가 점점 옅어졌다. IT 기술이 발전함에 따라 트랜잭션 관리 방법이 발전하였다. 기존에는 데이터베이스에서 트랜잭션을 직접 제어해야 했지만, Redis 분산락, Kafka 를 활용한 SAGA 패턴등의 기술을 도입하여 애플리케이션 Layer 에서도 유용하게 트랜잭션 관리를 가능케 했다.

MSA 환경을 전환중인 아키텍처

토스뱅크는 기존의 레거시한 모놀리식 코어뱅킹 서버(원화 예금 서버) 에서 기능을 마이크로 서버로 조금씩 때내고 있다. 대표적으로 지금 이자 받기, 송금, 원장 관리와 같은 도메인들을 새롭게 MSA 로 구현중에 있다. (몰론 데이터베이스는 오라클 DB 를 바라보고 있다.)

그리고 외화 예금 서버를 MySQL 과 마이크로 서버로 새롭게 다자인했다. (위 그림에서 왼쪽 부분이 외화 예금 서버이고, 오른쪽은 원화 예금 서버이다.) 전반 오버뷰는 위와 같은데, 지금부터 외부 예금 서버에서 트랜잭션을 어떻게 처리하고 있는지 아키텍처를 더 자세히 뜯어보자.

외화예금 트랜잭션 아키텍처

외화 예금 서버에서 사용자에게 빠른 환전 경험을 제공하기 위해 트랜잭션들이 전반적으로 느슨하게 연결되도록 설게했다. 단, 고객의 잔액 관리 부분(외환 서버, 수신 외화예금 서버) 에서 만큼은 서버들간의 트랜잭션을 엄격하게 관리했다. 하지만 이 외의 고객과 관련 없이 은행 내부적으로 회계 처리를 위한 서버들(손익 처리, 회계 처리, 계정계 서버) 간의 트랜잭션을 카프카를 활용하여 비동기적으로 처리했다.

금원 거래(환전) 플로우

이런 아키텍처 위에서 금원 거래가 어떻게 이루어지는지 플로우를 알아보자. (즉, 사용자의 원화가 외화로 어떻게 환전되며, 은행의 총 계장 원장 금액이 어떻게 바뀌는지 플로우를 알아보자.)

(1) 가장 먼저 고객이 환전을 요청할 것이다. (2) 그 요청은 외환 서버로 도착하고, 외환 서버는 어떤 종류의 환전인지 확인하고 환율을 확정한다. (3) 이어서 수신 원화예금 서버를 호출하여 원화 계좌에서 출금하고, (4) 수신 외화예금 서버를 호출하여 외화 계좌에 돈을 입금한다.

여기까지 되었다면 고객 계좌의 잔액 변동은 끝이난다. 빠른 환전 경험을 제공하기 위해 여기까지만 서버들간의 트랜잭션을 SAGA 패턴으로 묶어서 안전하게 관리하고 있다.

이후 은행 계좌를 처리하는 부분은 카프카를 이용해서 트랜잭션을 분리시켰다. (5) 외환 거래였기 때문에 손익에 대한 처리가 필요하다. 따라서 손익을 위한 카프카에 메시지를 발행하면 손익 서버가 그를 컨슘하여 환율에 따른 손익을 결정한다. (6) 이후 은행 회계 처리를 위해 회계 처리 서버가 카프카로 또 컨슘한다. (이 과정에서 회계 처리 서버는 은행의 어떤 계좌에 얼마를 기록할지를 오라클에 기록해둔다.) (7) 그렇게 오라클에 기록된 정보를 레기시 코어뱅킹의 Deferred 라는 존재가 주기적으로 조회해서, 은행 계좌 총 원장에 잔액을 변동시킨다.

만약 기존 레거시 코어뱅킹으로 환전 기능을 구현했다면?

몰론 위 과정들을 기존 레거시 코어뱅킹에서 하나의 로컬 트랜잭션으로 모두 처리할 수는 있었을 것이다. 하지만, 복잡한 은행 비즈니스 로직간의 의존성이 더욱 높아지게 되고, 고객과 관련없는 회계처리 부분도 하나의 트랜잭션으로 함께 묶여서 처리된다. 즉, 모든 것들이 하나의 로컬 트랜잭션으로 묶어 동기적으로 처리되므로 환전 속도가 느려진다.

외화예금 API

동시성 처리

환전 기능에서 외화예금 API 가 있을텐데, 그 중에 입금 API 에는 동시성 처리가 필요했다. (원화 계좌에서 출금된 돈이 외화 계좌로 "입금" 될 때 동시성 처리) 환전을 하는 동시에 똑같은 계좌로 카드 결제가 들어올 수 있었기 때문이다. 즉, 환전을 하는 동시에 얼마든지 타 요소로 인해 잔액 변동이 일어날 수 있었다.

동시성 처리를 위해 애플리케이션 계층에서는 Redis 분산 락을 사용했으며, 실제로 데이터가 수정되는 MySQL 데이터베이스에는 비관적 락을 걸었다. 이때 분산 락은 당연히 DB 보다 빠른 응답 속도를 기대할 수 있기 때문에 다른 트랜잭션에서 접근하더라도 Fail Fast 를 유도할 수 있었기 때문이다.

코루틴

그 다음으로는 거래가 가능한지 검증하는 단계이다. 예를들어 계좌를 확인하여 계좌가 해지된 상태는 아닌지, 명의도용된 계좌는 아닌지 등을 검증하는 것이다. 여기서는 레거시 코어뱅킹처럼 하나씩 동기적으로 검증하기엔 검증 요소들이 너무 많아서 느리다. 이를 해결하기 위해 코루틴을 도입하였고, 동시간대에 여러 검증을 수행하도록 했다.

그 이후 플로우

거래 가능한 계좌라는 것이 확인되었다면, 거래 내역을 MySQL 에 저장하고, 계좌의 잔액을 수정하고, DB 커밋을 한다. 그 이후로는 은행 계좌 및 회계 처리를 위한 카프카를 발행하고 있다.

24시간, 365일 무중단 환전 서비스 구현 방법

기존 은행 시스템은 매일 자정 근방에 거래가 불가능하다. 이는 은행의 회계 시스템 때문이다. 이 회계 시스템과 연관된 것이 바로 수신 외화예금 마이크로 서버에서 잔액대사 기능이다.

잔액대사란 무엇일까? 앞서 설명했듯이, 금원거래가 발생하면 고객 계좌와 은행 계좌가 바뀐다고 했었다. 그것이 매일 자정마다 잘 처리되었는지 검증하는 행위이다. 즉, 매일 자정을 기준으로 모든 고객 계좌의 잔액의 총 합이 은행의 총 계좌의 잔액의 합과 동일한지 검증한다.

일반 은행에서 정확한 전일자 잔액을 계산하기 위해선, 자정 근방에 모든 사용자들의 거래를 막고 모든 고객 계좌 잔액의 총합을 계산하면 된다. 00시 00분 근방에 거래가 없었기 떄문에 정확한 잔액을 산출할 수 있다. 하지만, 고객들이 거래할 수 없다는 치명적인 단점이 존재한다.

새로운 방안1

이를 위해 토스뱅크는 새로운 방안을 찾았다. (1) 00시 00분에 전일자 스냅샷 테이블을 만든다. 몰론, 이때도 거래가 계속 이루어질 것 이므로 정확한 계산 값이 도출되지 않을 것이다. (2) 그래서 00분 이후의 각 사용자의 첫번째 거래 내역을 확인하고, 가져온다. (3) 이렇게되면 잔액과 거래내역 금액을 게 되었으므로, 잔액을 역산하여 전일자 스냅샷 테이블을 보정하면 된다.

새로운 방안2

이 보다 외화예금 기능을 개발하면서 더 좋은 방안을 찾았다. 이 방법은 데이터 보정도 없이 데이터 구조를 바꿔서 새롭게 설계한 방법이다.

첫번째로 (1) 일자별 & 계좌별을 PK 구분자로 하여 잔액만 기록해두는 테이블을 만든다. 그리고, 금원 거래가 발생할 때 마다 일자별을 기준으로 그 계좌에 잔액을 기록해둔다. (2) 그리고 전일자 스냅샷 테이블을 만들 때, 앞서 (1) 엣허 만들어 놓은 테이블에서 일자별을 기준으로 모든 계좌의 잔액을 가져온다.

100% 테스트 자동화

5명의 팀원들이 어떻게 6개월이라는 짧은 기간만이 외화 예금을 출시할 수 있었을까? 이 비결은 100% 테스트 자동화에 있다. 외화 예금을 만드는 당시 총 3가지 방법으로 테스트를 자동화했다.

로컬 환경에서 테스트 : 단위 테스트 작성

로컬에서는 우리가 흔히 알고있는 단위 테스트를 작성했다. 테스트가 단 1개라도 실패하면 빌드가 실패된다.

Dev 환경에서 테스트 : E2E 테스트 활용

그리고 Dev 서버에서는 E2E 서버를 활용하여 업무의 정합성을 검증했다. E2E 서버란 실제로 배포 서버의 타깃이 되는 API 서버를 Dev 환경에서 호출할 수 있도록 코드를 작성할 수 있는 공간이다. 토스뱅크는 E2E 서버에 고객의 외화예금을 거래하는 것 처럼 고객의 시나리오를 코드화하여 작성했다.

코드 수정 사항이 발생할 때 마다 Trigger 되어, E2E 서버가 자동으로 수신 외화 예금 서버에 API 를 호출할 수 있도록 해놓았다.

Live 환경에서 테스트 : 이상거래탐지 서비스 개발 (데이터 완결성 검증)

마지막으로 운영 환경에서는 이상 거래 탐지 서비스를 개발하여 데이터 완결성까지 검증했다.

이상거래탐지 서비스란, 운영 환경에서 발생하면 안되는 데이터가 발생했는지 한 번더 검증하는 서비스이다. 이 서비스는 데이터의 중요도에 따라 주기적으로 돌면서 알림을 주도록 설정해놓았다.

예를들어 해지된 계좌에서 거래가 발생한 건은 없는지, 하루에 이자를 2번받은 잘못된 계좌는 없는지등 처럼 발생하면 안되는 데이터가 발생했는지를 검증한다.

전환 성과

금융권 최초로 MySQL 을 도입, MSA 기반의 안정적인 코어뱅킹 시스템을 구축하였음 : 덕분에 1910만 MAU를 자랑하는 토스 홈에서의 3000TPS 트래픽을 안정적으로 소화 중이다.
세상에서 가장 빠른 환전 고객 경험 제공 : 원화 송금 속도인 280ms 보다도 훨씬 빠른 속도인 외화 환전 속도를 30ms 로 빠르게 구현. MySQL 뿐만 아니라 Redis 기반 캐싱, 코루틴 등의 신기술을 활용하여 속도를 최적화
24시간, 365일 잠들지 않는 무중단 환전/결제 고객 경험 제공 : 외환 서버 구축과 동시에 은행의 회계 정합성을 위한 원장 보정 작업들도 MSA 로 전환함에따라 고객분들에게 24시간 서비스 제공

참고

https://www.youtube.com/watch?v=uWnAVYgCd0k

네트워크 타임아웃 문제를 안전히 처리하기 위한 재시도 전략 (Backoff, Retry Storm)

Tue, 31 Dec 2024 00:00:00 GMT

네트워크 지연으로 인해 실패를 확정지을 수 없는 상황

클라이언트가 서버로 네트워크를 통해 요청을 보낼 때, 성공적으로 잘 처리되어 응답을 받는 경우가 대부분이겠지만, 일부 요청에서는 에러가 발생할 것이다. 그리고 이 에러 중 대부분의 경우는 응답을 받는 즉시 요청이 정말로 실패했는지 확정지을 수 없겠지만, 일부 에러의 경우 실패를 확정지을 수 없다.

서드파티에게 요청을 보냈을 때, 서드파티가 요청을 정상적으로 처리하였지만 타임아웃이 되었다면? 아불싸. 네트워크 지연 문제로 인해 우리 서비스는 요청을 성공했다고 처리해야할까, 아니면 실패했다고 처리해야할까? 네트워크 지연으로 인해 타임아웃 되었다면 서드파티가 우리가 보낸 요청을 성공적으로 처리했는지, 실패했는지 알 방법이 없다.

타임아웃 발생

한 가지 상황을 떠올려보자. 클라이언트가 서버에 게시글 작성을 요청했고, 서버는 그 요청을 받아 게시물을 데이터베이스에 저장하기 시작했다. 그런데 데이터베이스에 병목이 발생하여 요청한 DB I/O 작업이 장시간 지연되었다. 클라이언트는 30초 넘게 기다렸지만 서버가 응답을 주지 않아 Read Timeout 에러로 클라이언트는 서버와 연결을 끊었다. 즉, 타임아웃이 발생하였다.

하지만 타임아웃 발생 이후 데이터베이스 작업이 끝났고, 게시물이 정상적으로 등록되었다. 분명 클라이언트는 Read Timeout 에러를 만났지만, 서버는 요청 처리 속도가 느렸을자라도 성공적으로 작업을 수행하였다. 만약 여기서 무턱대고 클라이언트에게 요청이 실패했다고 응답한다면? 실제 요청은 성공했음에도 클라이언트에게는 요청이 실패했다고 응답하게 되는 아주 모순적인 상황이 발생한다.

성공/실패를 단언할 수 없는 네트워크 에러 문제

이처럼 네트워크 에러는 성공/실패 여부를 즉시 확정지을 수 없는 경우가 존재한다. 이러한 네트워크 에러가 발생한 경우, 아래 3가지 case 로 나누어볼 수 있을 것이다.

(1) 요청이 서버에 도달한 뒤, 네트워크 에러가 발생했고, 그 요청을 실제로도 진짜 실패했다.

(2) 요청이 서버에 도달한 뒤, 네트워크 에러가 발생했지만, 사실 그 요청은 서버에서는 막상 까보니 성공했다.

(3) 알고보니 요청이 서버에 도달 조차 하지 못했다.

결과를 당장 확정할 수 없는 네트워크 에러가 발생했을 때 별 생각없이 이를 실패했다고 확정 해버린다면, 사용자에게 잘못된 결과를 노출할 수 있다. 또한 모놀리식 환경과 다르게, MSA 환경에서는 데이터베이스의 트랜잭션을 활용한 롤백이 불가능하다. 따라서 한쪽에 실패한 경우 정합성이 깨질 수 있는 것이다.

💡 왜 MSA 환경에서는 트랜잭션을 활용한 롤백이 불가능한지 추가 학습이 필요하다. 이는 2PC, SAGA 패턴 등으로 해결 가능한것인가? 보상 트랜잭션등에 관련한 학습을 해봐야겠다.

주문과 결제 서버

hudi 님의 기술 블로그 포스팅을 다수 인용 및 참고하여 작성하였다.

이커머스 서비스를 개발하고 있다고 가정해보자. 우리 서비스는 유저로부터 주문 요청을 받는 주문 서버, 주문 서버로부터 결제 요청을 받는 결제 서버를 만들고 있다. 주문 서버는 유저의 주문 내역을 저장하고, 결제 서버는 유저의 결제 내역을 저장한다.

이때, 주문 서버가 결제 서버로 요청했지만 타임아웃이 발생했다면 어떻게 핸들링 해야할까? 주문 서버는 자신의 주문을 확정해야하는데, 결제가 완료되었는지 알 수 없으니 그럴 수 없다. 단순히 결제 요청이 실패해다고 곧바로 주문을 실패처리한다면, 유저는 주문이 실패했다고 응답을 받았는데, 맙소사. 막상 실제로 결제는 성공하여 돈이 빠져나가는 경우가 발생할 수 있다.

재시도 (Retry) 를 통해 성공/실패를 확정짓기

일단 주문서버는 결제서버에 재시도를 해볼 수 있을 것이다. 결제 서버가 제대로 응답을 할 때 까지 2번이고, 3번이고, ... 성공할 때 까지 N번의 요청을 재시도하는 것이다. 이때 재시도 과정에서 결제 서버가 정상 응답을 내려주었다면, 주문의 상태도 성공/실패로 확정지을 수 있다.

그렇다고해서 무턱대고 재시도를 막 구현해도 괜찮을까? 토스 SLASH 22, 애플 한 주가 고객에게 전달되기 까지 에서도 다루었듯이, (1) 타임아웃의 특성상 짧은 주기로 재요청을 시도하면 네트워크 지연 상황을 더욱 악화시킬 수 있다. (네트워크 병목이 더 심해지기만 한다.) (2) 또한 의도치 않게 1번의 주문으로 다건의 결제가 진행되는 금융 사고가 발행할 수 있다. 즉, 1건의 주문에 대해 1건의 결제 데이터가 적재되는 것이 아닌, 다량의 결제 데이터가 적재될 수 있다.

위 2가지 문제를 어떻게 현명히 해결할 수 있을까?

멱등한 API 요청을 통해 안전하게 재시도

우선 (2) 를 해결하기 위한 방법을 생각해보자. 멱등성이란 같은 요청을 여러번 수행하더라도 항상 최초 요청과 동일한 결과를 응답받도록 하는 성질을 뜻한다. 예를들어, 결제 서버에 멱등성이 적용된다면 동일한 결제 요청이 도달하더라도 결제는 단 1번만 수행되어야 할 것이다. 그런데, 이 멱등성은 어떻게 구현할 수 있는가? "동일한 요청" 임을 결제 서버가 어떻게 식별하고, 판단할 수 있을까?

멱등 키 (Idenpotency Key) 를 통한 동일한 요청 식별

주문 서버는 결제 서버에 결제 요청을 보낼 때, Unique 한 ID 를 생성하여 함께 보내면 된다. 이 ID 를 멱등키라고 한다. 유일성을 갖는 식별자를 양측간에 서로 공유함으로써, 중복 결제 요청을 방지할 수 있다.

결제 서버는 주문 서버로부터 결제 요청을 받음과 동시에, 이전에 동일한 멱등키로 결제가 진행된 적이 있는지 확인하면 된다. 만약 없다면, 즉 처음 받은 멱등키라면 결제를 진행한다. 반대로, 이전에 받아 이미 결제가 수행되었던 멱등키라면, 결제를 수행하지 않고 처음 요청의 결과를 그대로 반환한다.

네트워크 병목을 고려하여 Retry 하기

그리고 앞선 (1) 을 고려한 해결방법을 떠올려보자. (1) 은 짧은 주기로 재시도했을 때 되려 네트워크 병목만 발생하여 실패 확률을 더 높이는 상황이다. 이 상황으로보아, 현재 네트워크 상에서 결제 서버는 굉장히 큰 부하를 받고 있는 상태이다.

결제 서버 입장에서는 당장 현재 받고있는 트래픽이 낮아져야지 요청 속도가 개선된다. 하지만 결제 서버는 주문 서버가 짧은 주기로 Retry 해버리면 이전보다 더 큰 부하를 받게되어, 상황이 더 악화되기만 한다. 게다가 실제 서비스에서는 주문 서버 뿐만 아니라, 결제 서버에 의존하는 수 많은 서버들이 Retry 요청을 보내게 될 것이다. 이를 Retry Storm 이라고 부른다.

지수적 간격으로 재시도 (Exponential Backoff)

이를 위해, 토스증권에서도 지수적(Expoential) 재시도 간격을 두는 전략을 취하고 있다.

예를들면, 위 그래프처럼 최초 재시도는 1초 뒤에 보낸다. 그 뒤에는 재시도 간격을 지수적으로 늘리는 전략을 취한다. 이후 재시도는 2초 뒤에, 그 다음은 4초 뒤에, 8초 뒤, 16초 뒤, ... 이렇게 지수적으로 재시도 간격을 늘리는 전략을 취하면 된다.

짧은 주기로 동일한 간격을 갖는 재시도 요청을 보내는 것 보다, 지수적으로 재시도 주기를 더 늘려가면서 요청하는 것이 부하도 훨씬 적어지고, 응답 속도도 더 빨리질 것이다.

하지만, 결제 서버로 요청하는 모든 서버가 동일한 지수적 증가 전략을 사용하게 되면, 결국 재시도 시점에 결제 서버가 받는 부하는 여전히 클 것이다. (결국엔 모든 서버가 재시도를 보내는 시점 타이밍이 똑같으니깐.) 이를 해결할 수 있는 방법은 아래와 같다.

Exponential Backoff with Jitter

Jitter 란 패킷이 도달하는 시간이 일정하지 않고 불규칙한 현상을 뜻한다. Exponential Backoff with Jitter 전략은, 이 Jitter 를 의도적으로 발생시켜서 재시도 요청들이 일정한 시각에 몰리는 것을 방지하는 전략이다. 즉, 위에서 살펴본 지수적 증가 전략에다 무작위성을 더한 전략이다.

위 그래프에서도 볼 수 있듯이, 지수적으로 증가하는 간격에다 무작위성을 추가하니 동일한 시간대에 요청이 몰리지 않고 분산됨을 알 수 있다.

재시도는 무한정 시도할 수 없다.

당연하게도, 재시도는 무한정으로 보내면 안된다. 무제한으로 재시도 요청을 보낼수는 없다. 많은 재시도를 하게 된다면, 사용자도 그 만큼 늦게 응답을 받게된다. 또한, 재시도는 그 자체로 리소스 낭비가 될 수 있다. 즉, 최대 재시도 횟수를 정해두고 언젠가는 재시도를 포기해야한다.

그렇다면 최악의 경우에 수많은 재시도 끝에도 타임아웃을 만나게 되었다면, 주문 서버는 결국 결제 요청의 성공 여부를 결국 모를 것이다. 하지만 주문 서버는 자신의 주문 상태를 확정지여야 한다. 이를 어떻게 해결해야할까?

중복 주문 방지

수 많은 재시도 요청끝에 타임아웃을 만나게 되었다면, 유저에게는 "주문 처리 결과를 알 수 업다" 는 메시지가 노출 될 것이다. 유저는 자신의 주문이 어떻게 처리되었는지 알 방법이 없으니, 재주문을 시도할 것이다. 하지만 재주문을 요청한다면 중복으로 주문이 발생할 가능성이 있다. 따라서 주문 서버는 아래 과정을 통해 중복 요청을 막아야한다.

(1) 주문 상태 초기화 : 주문 서버는 유저에게 주문 요청을 하자마자, 주문을 대기 상태로 저장한다.
(2) 결제 요청 및 주문 상태 전이 : 주문 서버는 결제 서버에 결제 요청을 보내고, 응답에 따라서 주문의 상태를 성공 또는 실패 로 변경한다. 하지만 다수의 Retry 에도 불구하고 타임아웃이 발생했다면, 결제의 상태를 확정할 수 없으므로 주문의 상태도 여전히 대기 상태이다.
(3) 중복 주문 방지 : 대기 상태의 주문을 보유한 유저가 새로운 주문을 중복 요청하려는 경우, "이전 주문건이 진행중입니다. 잠시만 기다려주세요." 이라는 문구를 노출하고 중복 주문 요청을 막는다.

확정되지 않은 결제 요청 확정

우선 이렇게 중복 주문을 방지했다. 이제부터는, 주문 서버가 결제 서버로부터 결제 상태를 알아내어 주문 상태를 대기 에서 성공 또는 실패 로 확정시켜야 한다. 이를 위해 주문 서버가 결제 서버로 부터 결제 상태를 알아낼 수 있는 방법은 크게 2가지이다.

첫번째는 주기적으로 결제 서버에게 요청을 보내어, 결제 내역 상태를 물어보는 방법인 풀링(Polling) 을 사용한 방법이 있다. 두번째는 결제 서버가 최종 상태로 전이된 결제 내역에 대해 이벤트(메시지) 를 발행하는 방법인 메시지 큐(Message Queue) 를 사용하는 방법이다.

풀링(Polling)

결제 서버가 결제 내역의 상태를 조회할 수 있는 API 를 하나 만들어두고, 주문 서버가 해당 API 를 주기적으로 요청하는 것이다. 주문 서버는 이 API 를 통해 대기 상태로 남아있는 결제건에 대해 상태를 주기적으로 질의한다. 주기적인 질의를 통해 결제 서버가 해당 결제에 대해 성공 또는 실패의 최종 상태로 응답을 한다면, 주문 서버도 해당 결제건과 매핑되어 있는 주문 내역의 상태를 성공 또는 실패로 확정(갱신) 하면 된다.

하지만 이 풀링(Polling) 의 특성상 앞서 살펴본 Retry Storm 과 마찬가지로 결제 서버에 부하를 줄 수 있다. 결제 상태가 최종 상태로 확정되는 순간에, 주문 서버가 이를 알 수 있도록 하는 방법은 없을까? 이는 바로 메시지 큐를 사용하면 가능해진다.

메시지 큐 (Message Queue)

카프카와 같은 메시지 큐를 사용하면, 결제 서버에 부하를 주지 않는다. 결제 서버는 완료된 결제 내역에 대해 성공/실패 여부를 메시지로 발행하고, 주문 서버가 해당 메시지를 컨슘한다. 주문 서버는 컨슘한 메시지의 결제 내역의 상태에 따라, 주문 내역의 상태를 성공 또는 실패로 갱신한다.

풀링에 비해 부하도 발생하지 않으며, CDL Retry 패턴등을 사용하여 더 안정적으로 정합성을 유지할 수 있다.

결제 서버에서 결제 요청이 도달조차 하지 못했다면?

네트워크 지연으로 인해 주문 서버의 요청이 결제 서버에 도달조차 하지 못한 경우도 낮은 확률로 발생할 수 있다. 이 경우 결제 서버는 해당 결제건에 대해 애당초 전혀 모를 것이다. 이런 경우 영영 주문 상태는 최종 상태로 확정되지 못할 것이고, 유저는 영원히 주문을 할 수 없는 상태에 놓인다.

이런 상황을 막기 위해선, 대기중인 주문이 이미 존재하여 유저의 주문을 막기 전에, 주문 서버는 결제 서버에게 대기중인 주문건에 매핑된 결제건에 대해 알고있는지 물어보야한다. 결제 서버가 모르고 있다면, 결제 과정 자체가 시작되지 않았으므로 주문을 실패로 확정 처리해도 된다.

몰론 결제 요청이 알 수 없는 이유로 결제 상태 확인 요청보다 늦게 들어오는 경우 또 정합이 깨질 수 있다. 이럴 때에는 주문 서버와 결제 서버 모두가 타임아웃 시간을 합의하고, 결제 요청에 요청을 보낸 타임스탬프를 기록한 뒤, 타임아웃 시간 이후에 요청이 들어온 경우를 항상 실패처리하면 된다.

참고

트랜잭션 동기화와 추상화 (feat. JDBC Connection)

Mon, 30 Dec 2024 00:00:00 GMT

데이터베이스 레플리케이션을 구축할 때 TransactionaSynchornizationManager 를 사용하여 라우팅 환경을 구축한 경험이 있다. 이번 포스팅에선 트랜잭션 동기화와 추상화에 대해 다루어보고자 한다.

JDBC 에서 트랜잭션 로직이 뒤섞이는 문제

데이터베이스에서 간단히 SELECT, INSERT 문을 날리면 데이터베이스 쿼리 결과가 실제로 반영된다. 사실 이를 가능케 하는것 AUTO COMMIT 기능이 활성화되었기 때문이다. AUTO COMMIT 이란 데이터베이스 내부적으로 커밋을 자동으로 수행하는 기능이다. 반대로 말해, AUTO COMMIT 이 꺼져있다면 커밋이 수행되지 않아서 데이터베이스에 쿼리가 반영되지 않는다.

보통 트랜잭션을 처리하면 최소 2개 이상의 여러 쿼리가 한 단위로 묶여서 수행된다. 그런데 만약 AUTO COMMIT 이 활성화되었다면 트랜잭션이 정상 수행될까? 트랜잭션은 ACID 원칙에 따라 원자성(atomic) 을 보장해야한다. 그런데 AUTO COMMIT 이 활성화된다면 단일 쿼리가 별개로 동작하고 커밋되어서 원자성을 갖지 못하게 된다. 따라서 JDBC 환경에선 트랜잭션의 원자성을 보장하기 위해 AUTO COMMIT 기능을 비활성화하고, 우리가 직접 커밋과 롤백의 시점을 관리하고 구성해야한다.

Connection 오브젝트는 setAutoCommit() 메소드를 통홰 AUTO COMMIT 의 활성화 여부를 설정할 수 있도록 해준다. 아래와 같이 여행지를 방문하는 상황을 가정해보자. 여기서 가장 중심적으로 살펴봐야 할 부분은 Connection 을 외부로부터 파라미터로 전달받는다는 점이다.

@Repository
public class TripDao {
    // ...
    public Trip findTrip(final Connection connection, final int tripId) {
        String sql = "SELECT * FROM trip WHERE id = ?";
        try (Connection conn = dataSource.getConnection();
            PreparedStatement pstmt = conn.prepareStatement(sql)) {
            pstmt.setInt(1, tripId); // id에 해당하는 값을 매개변수로 설정
            ResultSet rs = pstmt.execteQuery();

            return new Trip(
                rs.getId("id"),
                rs.getString("place_name"),
                rs.getString("image_url"),
            );
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }
}

이어서 여행지를 방문했다면 동시에 해당 여행지의 누적 방문 수를 1증가시키는 기능도 함께 동작하도록 해야한다.

public void updateTrip(final Connection connection, final int tripId) {
    try {
        String sql = "update trip set visited_count = visited_count +1 where id = ?";
        PreparedStatement pstmt = connection.prepareStatement(sql);
        pstmt.setInt(1, tripId);
        pstmt.executeUpdate();
    } catch(SQLException e) {
        e.printStackTrace();
    }
}

앞서 설명했듯이 DAO 내부에서 직접 Connection 을 생성하는 것이 아니라 외부로부터 파라미터로 주입받아서 사용한다. 이렇게 구성한 이유는, 트랜잭션을 사용하기 위해선 트랜잭션을 구성하는 여러개의 쿼리가 동일한 커넥션에서 실행되어야하기 때문이다. 아래와 같이 애플리케이션 계층에서 여행지 조회 및 업데이트 쿼리가 동일한 Connection 에서 실행될 수 있어야지 트랜잭션 묶음으로 수행되었다고 할 수 있다. 또한 쿼리 실행전에 AUTO COMMIT 을 비활성화하였으며, 모든 쿼리 실행 후 커밋을 수행한 모습을 볼 수 있다.

@Service
public TripService {
    private TripDao tripDao;

    public Trip findTrip(final int tripId) {
        Connection connection = null;

        try {
            connection = DrivierManager.getConnection();
            connection.setAutoCommit(false);

            Trip trip = tripDao.findTrip(connection, tripId);
            tripDao.updateTrip(connection, tripId);

            connection.commit();
        } catch(SQLException e) {
            connection.rollBack();
        } finally {
            try {
                connection.close();
            } catch(SQLException e) {
                // ...
            }
        }
    }
}

위 코드는 비즈니스 로직이 직관적으로 눈에 보이지 않는다. 위에서 사용되는 모든 쿼리를 동일한 Connection 에서 처리해야 하다보니, 불가피하게 Connection 이 애플리케이션 계층에 위치할 수 밖에 없다. 애플리케이션 계층의 주 관심사는 비즈니스 로직인데, 이 때문에 비즈니스 로직에 집중할 수가 없게 되었다. 또한 try-catch-finally 구조로 인해 가독성도 저하된다.

결국 커넥션을 생성하고, 트랜잭션 경계를 설정하는 코드가 애플리케이션 계층에 위치해있다보니 DAO 에서 본디 수행해야 할 데이터 엑세스 처리 관련 로직이 애플리케이션 계층에도 존재한다.

트랜잭션 동기화

Connection 을 파라미터로 넘겨서 공유하는 방식은 많은 단점을 안겨준다. 이를 해결하기 위해 Connection 을 계속 파라미처로 전달하는 코드를 재거해보자. 스프링에서는 **트랜잭션 동기화 매니저(Transaction Synchornization Manager)**을 통해 이를 가능케한다. 트랜잭션 동기화 매니저는 트랜잭션을 시작하기 위해 각 쓰레드마다 생성한 Connection 객체를 고유한 쓰레드 로컬(Thread Local) 에 저장하고, 필요할 때 마다 매번 쓰레드 풀에서 꺼내 쓰는 역할을 수행한다. 쓰레드 로컬 특성상 각 쓰레드별로 독립적인 Connection 을 보관할 수 있기 때문에 멀티 쓰레드 환경에서도 항상 동일한 커넥션 객체를 가져올 수 있게된다.

트랜잭션 동기화는 다음과 같은 과정을 통해 수행된다.

(1) @Transactional 을 만나는 그 즉시 트랜잭션 추상화 매니저(PlatformTransactionManager) 가 getConnection() 을 호출하여 트랜잭션을 시작할 준비를 한다.
(2) 이때, 트랜잭션을 시작하기 위해선 Connection이 필요하다. 따라서 트랜잭션 매니저는 내부에서 DataSource 를 사용해서 Connection 을 생성한다.
(3) Connection 의 자동 커밋을 비활성화 해준다. 즉, AUTO COMMIT 옵션을 False 로 지정한 뒤에 이제부터 본격적으로 트랜잭션을 시작한다.
(4) Connection 을 트랜잭션 동기화 매니저(Transaction Synchornization Manager) 에 보관한다.
(5) 트랜잭션 동기화 매니저는 본인이 보유한 쓰레드 로컬에 커넥션을 저장한다. 앞으로 트랜잭션내의 비즈니스 로직을 수행하면서 커넥션이 필요할 때 마다 이 쓰레드 로컬에 저장한 커넥션을 꺼내어 올 것이다.
(6) 비즈니스 로직을 수행하면서 커넥션이 필요할 때 마다 DataSourceUtils 의 getConnection() 을 호출하여 트랜잭션 동기화 매니저에 보관된 커넥션을 꺼내어 사용한다. 이로써 하나의 트랜잭션내에 담긴 모든 쿼리를 수행시 동일한 커넥션을 사용하게 된다.
(7) 비즈니스 로직이 끝나고 트랜잭션을 커밋 또는 롤백할 때도 트랜잭션 매니저에서 커넥션을 꺼내와서 트랜잭션을 커밋 또는 롤백한다.

트랜잭션 동기화 적용

스프링에선 TranscationSynchornizationManager 라는 클래스를 사용해서 트랜잭션을 동기화한다. 이 클래스를 활용하여 앞선 코드를 개선해보자. 앞서 설명했듯이 커넥션을 생성하기 위해선 DataSource 가 필요하다. 이를 위해 DataSource 에 대한 기본 설정을 application.yml 에서 진행해주자.

JDBC 에서 데이터베이스 커넥션 풀 다루기 (feat. JDBC Driver, DataSource, HikariCP) 에서 다루었듯이, DataSource 는 자바 애플리케이션에서 데이터베이스 커넥션을 얻어오기 위해 사용하는 방법 중 하나이다. 각 서비스에서 사용하는 DB 벤터에 알맞게 DataSource 구현체(HikariCP, DriverManager 등) 이 자동 주입될 것이다.

spring:
  datasource:
    url: jdbc://mysql://localhost:3306/moheng
    username: root
    password: 1234
    driver-class-name: com.mysql.cj.jdbc.Driver

그리고 아래와 같이 TransactionSynchornizationManager 를 통해 트랜잭션 동기화 작업을 수행한다. 트랜잭션 동기화의 핵심은 어떤 계층, 어떤 곳에서든 동일한 트랜잭션이라면 항상 동일한 커넥션으로 쿼리를 수행하는 것이다. 실제로 Connection 을 일일이 메소드 파라미터로 넘겨주지 않더라도 같은 커넥션내에서 쿼리가 수행되도록 개선되었다.

@Service
public TripService {
    private final DataSource dataSource;
    private final TripDao tripDao;

    // ...

    public Trip findTrip(final int tripId) {
        TransactionSynchornizationManager.initSynchornization(); // 트랜잭션 동기화 초기화

        Connection connection = DataSourceUtils.getConnection(dataSource); // 트랜잭션 동기화 매니저에 생성된 커넥션 가져오기

        try {
            connection.setAutoCommit(false);

            Trip trip = tripDao.findTrip(tripId);
            tripDao.updateTrip(tripId);

            connection.commit();
        } catch(SQLException e) {
            connection.rollBack();
        } finally {
            DataSourceUtils.releaseConnection(connection, dataSource); // 커넥션 해제
        }
    }
}

개선 결과, Dao 가 아래처럼 외부로부터 파라미터를 통해 Connection 을 전달받지 않는다. 그 대신 DataSourceUtils 를 사용하여 커넥션을 꺼내오도록 개선되었다.

@Repository
public class TripDao {
    private final DataSource dataSource;
    // ...

    public Trip findTrip(final int tripId) {
        Connection connection = DataSourceUtils.getConnection(dataSource);

        String sql = "SELECT * FROM trip WHERE id = ?";
        try (Connection conn = dataSource.getConnection();
            PreparedStatement pstmt = conn.prepareStatement(sql)) {
            pstmt.setInt(1, tripId); /
            ResultSet rs = pstmt.execteQuery();

            return new Trip(
                rs.getId("id"),
                rs.getString("place_name"),
                rs.getString("image_url"),
            );
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

    public void updateTrip(final int tripId) {
        Connection connection = DataSourceUtils.getConnection(dataSource);

        try {
            String sql = "update trip set visited_count = visited_count +1 where id = ?";
            PreparedStatement pstmt = connection.prepareStatement(sql);
            pstmt.setInt(1, tripId);
            pstmt.executeUpdate();
        } catch(SQLException e) {
            e.printStackTrace();
        }
    }
}

이렇게 TransactionSynchorizationManager 를 통해 커넥션을 일일이 메소드 파라미터로 전달하는 코드가 제거되었다. 그런데, 아직까진 애플리케이션 계층이 다소 지저분하다는 느낌을 받지 않는가? 아직 TripService 코드에는 커넥션을 통해 직접적으로 트랜잭션 경계를 설정하는 코드가 남아있다.

트랜잭션 추상화

애플리케이션 계층내에 트랜잭션 경계를 직접 설정하는 코드를 제거하고 싶다는 생각이 든다. 이를위해, 스프링에서는 트랜잭션 추상화(Transaction Abstraction) 방법을 제공하고 있다. 트랜잭션 추상화란 트랜잭션 경계를 지정하는 과정을 추상화한 방법으로, 트랜잭션 추상화 관리자로 PlatformTransactionManager 를 제공한다. 이를 사용하여 트랜잭션 경계를 지정하는 로직을 간편히 구성할 수 있다.

public interface PlatformTransactionManager extends TransactionManger {
    TransactionStatus getTransaction(@Nullable TransactionDefinition definition) throws TransacionException;
    void commit(TransactionStatus status) throws TransactionException;
    void rollback(TransactionStatus status) throws TransactionException;
}

PlatformTransactionManger 는 위와 같은 3가지 메소드를 제공하고 있다. 유추할 수 있듯이, 커밋과 롤백되는 시점을 지정할 수 있는 방법을 간편하게 추상화하였다. 이때 TransactionStatus 는 현재 트랜잭션의 ID와 구분 정보를 담고있는 객체이다.

트랜잭션 추상화 매니저인 PlatformTransactionManger 는 인터페이스이다. 이의 구현 클래스로 DataSourceTransactionManager, JpaTransactionManager, HibernateTransactionManager 등 많은 구현체가 존재한다. 우리는 PlatformTransactionManger 을 통해 JPA, JDBC, Hibernate, Jta, ... 등 기술 스택이 변경되는 상황에서도 유연하게 대응할 수 있다.

만약 앞선 트랜잭션 동기화 코드를 트랜잭션 추상화를 적용하여 개선한다면 어떻게될까? PlatformTransactionManger 구현체 중 하나인 DataSourceTransactionManager 를 사용하여 코드를 개선해보자.

@Service
public TripService {
    private final DataSource dataSource;
    private final TripDao tripDao;

    // ...

    public Trip findTrip(final int tripId) {
        PlatformTransactionManager transactionManager = new DataSourceTransactionManger(dataSource);
        TransactionStatus status = transactionManager.getTransaction(new DefaultTransactionDefinition());

        try {

            Trip trip = tripDao.findTrip(tripId);
            tripDao.updateTrip(tripId);

            transactionManager.commit();
        } catch(RuntimeException e) {
            transactionManager.rollBack(status);
        }
    }
}

어떤가? 훨씬 간편해지지 않았는가? 커넥션을 쓰레드 로컬에서 직접 꺼내오는 로직이 없어졌고, 커넥션을 코드상에서 직접 조작하지 않을 수 있게 되었다. 앞선 코드에서는 커넥션을 꺼내와서 트랜잭션 경계를 장황하게 설정해야 했지만, 이 코드가 더 깔끔히 개선되었다. 또한 트랜잭션 동기화를 위한 코드도 제거되었다. 이를통해 PlatformTransactionManager 는 트랜잭션 동기화 로직도 추상화함을 알 수 있다.

TransactionStatus 는 트랜잭션의 4가지 속성 (트랜잭션 전파, 격리 수준, 타임아웃, 읽기/쓰기 전용 여부) 의 상태값을 담고있는 인터페이스이다. 이 구현체로 DefaultTransactionDefinition 를 사용했다.

AOP 를 이용한 선언전 트랜잭션

사실 PlatformTransactionManager 를 우리가 평소에 직접 사용할 일은 거의 없다. 그렇다면 우리는 어떠한 방식으로 트랜잭션 추상화를 누리고 있던것일까? 이 비밀은 바로 @Transactional 어노테이션에 있다.

@Transactional 은 AOP 를 통한 트랜잭션 경계 어노테이션이다. 우리는 이 어노테이션을 사용하면서 내부적으로 PlatformTransactionManager 의 기능, 즉 트랜잭션 추상화의 기능을 제공받고 있었던 것이다.

AbstractRoutingDataSource 에서 동적으로 DataSource 를 결정하는 원리

이렇게까지 트랜잭션 동기화와 추상화에 대해 학습해보았다. 이번 포스팅의 가장 큰 목적은 트랜잭션 동기화 매니저에 대해 학습하는 것 이었다. 이 트랜잭션 동기화 매니저는 아래와 같이 데이터베이스 레플리케이션 환경을 구축할 때 AbstractRoutingDataSource 에서 사용했다.

//  AbstractRoutingDataSource : Multi DataSource 환경에서 여러 DataSource 를 묶고 분기해줄 때 사용한다.
public class RoutingDataSource extends AbstractRoutingDataSource {
    // determineCurrentLookupKey 메소드 : 여러 datasource 중에서 실제로 사용될 DataSource 를 결정하는 역할
    // 현재 트랜잭션의 속성에 따라 targetDataSourceMap 의 조회 Key 를 결정하기위해 AbstractRoutingDataSource 를 상속받아서 determineCurrentLookupKey 를 구현했다.
    @Override
    protected Object determineCurrentLookupKey() {
        boolean isReadOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();
        logger.info("현재 트랜잭션 속성이 ReadOnly인가?:" + isReadOnly);
        return isReadOnly ? "slave" : "master";
    }
}

AbstractRoutingDataSource 구현체는 DataSource 인터페이스의 구현체로, 동적인 DataSource 를 뜻한다. AbstractRoutingDataSource 는 어떻게 동적인 DataSource 를 결정할 수 있는것일까?

(1) @Transactional 를 마주한 시점부터 트랜잭션이 시작된다. 트랜잭션 추상화 매니저(PlatformTransactionManger) 가 getConnection() 을 호출하면서, 내부적으로 DataSource 를 사용하여 커넥션을 생성할 준비를 한다. 또한, 이때 현재 트랜잭션의 4가지 속성도 분석하여 TransactionStatus 형태로 트랜잭션 동기화 매니저 (쓰레드 로컬) 에 저장한다.
(2) 커넥션을 생성하기 위해선 DataSource 정보가 필요할 것이다. 이때, 만약 AbstractRoutingDataSource 를 별도로 설정해놓았다면, AbstractRoutingDataSource 가 동적으로 트랜잭션 속성에 따라 적절한 DataSource 정보를 제공하게 된다.
(3) 이에따라 RoutingDataSource 의 determineCurrentLookupKey() 메소드를 호출하게 된다. 이 메소드는 트랜잭션의 읽기 전용 여부를 확인하고 어떤 DataSource 를 제공할지 선택하는 역할을 한다. TransactionSynchronizationManager 의 isCurrentTransactionReadOnly() 가 호출된다면, 앞서 (1) 에서 저장해놓았던 TransactionStatus 정보를 쓰레드 로컬에서 추출하여 현재 트랜잭션의 ReadOnly 여부를 판단한다. 그를 기반으로 아직 제대로 결정되지 못했던 DataSource 를 확실히 결정짓게된다.

@Bean
public DataSource routingDataSource(
	@Qualifier(master) DataSource masterDataSource,
	@Qualifier(slave) DataSource slaveDataSource) {

   RoutingDataSource routingDataSource = new RoutingDataSource(); // 쿼리 요청을 적절한 서버로 분기할 때 활용됨
   HashMap<Object, Object> targetDataSourceMap = new HashMap<>(); // (1)

   // targetDataSourceMap 객체에 분기할 서버들의 DataSource 빈을 저장
   targetDataSourceMap.put("master", masterDataSource); // (2)
   targetDataSourceMap.put("slave", slaveDataSource);

   routingDataSource.setTargetDataSources(targetDataSourceMap); // (3) => DataSource 타깃을 설정한다.
   routingDataSource.setDefaultTargetDataSource(masterDataSource); // (4)

	return routingDataSource;

(4) 이렇게 동적으로 DataSource 를 결정하게 된 RoutingDataSource 를 위처럼 스프링 빈으로 등록해주면, PlatformTransactionManager 는 내부적으로 이 DataSource 를 사용해서 커넥션을 을 생성한다.
(5) 이후 과정은 앞서 트랜잭션 동기화 과정에서 설명한 내용과 동일하다. 커넥션의 AUTO COMMIT 을 비활성화하고, 이제부터 트랜잭션을 본격적으로 시작하게 될 것이다. 그리고 이 커넥션 객체는 TransactionSynchornizationManager 에 보관된다.
(6) 현재 트랜잭션내에서 매번 쿼리가 수행될 때 마다 DataSourceUtils 의 getConnection() 이 호출될 것이다. 이에따라 쓰레드 로컬에서 추출된 동일한 커넥션을 재사용함으로써 트랜잭션 동기화가 보장된다.

@Bean
@Primary
public DataSource dataSource(){
	DataSource determinedDataSource = routingDataSource(masterDataSource(), slaveDataSource());
	return new LazyConnectionDataSourceProxy(determinedDataSource);
}

(7) 마지막으로 LazyConnectionDataSourceProxy 를 사용하여 커넥션을 획득하는 시점을 지연(Lazy) 시킨다. 만약 이 과정이 없다면 스프링은 기본적으로 @Transactional 을 만나자 마자, 즉 트랜잭션에 진입하자마자 그 즉시 DataSource 를 가져오고 커넥션을 맺는다. 이 떄문에 RoutingDataSource 내에서 라우팅할 DataSource 를 결정하는 작업은 DataSource 로 부터 이미 커넥션을 맺은 이후에 뒤늦게 동작한다. 따라서 커넥션을 획득하는 시점을 지연시키는 것이다.

LazyConnectionDataSourceProxy 를 사용하면 트랜잭션 진입 시점에 실제 커넥션을 리턴하는 대신에 프록시 커넥션 객체를 대신 리턴한다고 했었다. 이를통해 커넥션이 실제로 사용되는 시점까지 커넥션 획득을 지연시켜서, AbstractRoutingDataSource 가 정상적으로 트랜잭션 ReadOnly 상태 값을 읽어올 수 있게된다.

참고

스프링 데이터베이스 1편 : 데이터 접근 핵심 원리, 김영한
https://velog.io/@daehoon12/Spring-DB-트랜잭션-매니저
https://jongmin92.github.io/2018/04/08/Spring/toby-5/

MySQL 레플리케이션 복제 동기화 방식 (비동기, 반동기)

Sat, 28 Dec 2024 00:00:00 GMT

소스 서버에서 빌셍힌 이벤트(트랜잭션)은 바이너리 로그에 기록되고, 레플리카 서버는 주기적으로 바이너리 로그 덤프 쓰레드를 사용하여 이벤트를 요청하고, 전송받는다. 즉, 소스 서버에서 레플리카 서버로 데이터를 복제하는데에 소요 시간이 댜소 발생한다. 그럼 궁금증이 하나 생긴다. 과연 복제하는 동안에는 두 서버의 데이터가 다를텐데, 이로 인해 문제가 발생하지는 않을까?

비동기 복제 방식 (Asynchronous replication)

특징

위와 같은 문제점은 비동기 복제 방식에서 발생할 수 있다. 비동기 복제 방식이라면 레플리카로 이벤트가 잘 전달 되었는지, 실제로 이벤트 복제가 잘 이루어졌는지 알 수 없고, 보장하지도 않는다. 비동기 방식은 소스 서버에서 쓰기 연산이 수행된 후, 이벤트를 레플리카 서버에서 전송하기만 하고 자기는 곧 바로 커밋하는 셈이다. 즉, 소스 서버에서 발생한 트랜잭션은 레플리카에 동기화되었는지와 별개로 동작하고, 커밋된다.

MySQL 레플리케이션은 기본적으로 비동기 복제 방식으로 동작한다. 따라서 별다른 설정이 없다면 서버간의 데이터 누락, 정합성 문제가 발생할 수 있다. 그런데, 이렇게 소스 서버가 레플리카 서버에 이벤트 동기화 여부를 보장하지 않는다는 특징은 장점도 있고, 단점도 있다.

장점

어떻게 보면 장점이 되기도 한다. 비동기 처리의 특성상 성능이 더 빨라지게 된다. 소스 서버 입장에서는 각 트랜잭션 작업을 수행할 때 레플리카 서버로 전송하는 부분을 기다리지 않고 수행되기 때문에, 트랙잭션 처리 속도가 빨라진다. 또한 레플리카 서버에 문제가 발생하더라도 소스 서버가 영향을 받지 않고 독립적으로 동작할 수 있다는 점이다.

단점

소스 서버에 장애가 발생시 레플리카 서버로 이벤트가 제대로 전달되지 않을 수 있다. 즉, 복제 과정에서 데이터 누락이 발생할 수 있다. 만약 소스 서버에서 장애가 발생하여 FailOver를 위해 레플리카를 소스 서버로 승격시킨다면, 레플리카에서 누락된 데이터를 일일이 수작업으로 찾고 반영해줘야한다.

반동기 복제 방식 (Semi-synchronous replication)

비공기 복제 방식보다 데이터 동기화 문제를 더 견고하게 해결해주는 방식이다. 소스 서버의 이벤트가 레플리카 서버에 잘 전달된 것을 확인한 뒤에서야, 소스 서버의 트랜잭션을 마무리하는 방식이다. 즉, 소스 서버는 레플리카 서버가 소스 서버로부터 전달받은 이벤트를 릴레이 로그에 기록하고 응답(ACK) 을 보내면, 그때서야 트랜잭션을 커밋한다. 앞선 비동기 복제 방식과 달리 소스 서버가 트랜잭션을 커밋하고, 레플리카 서버에 복제하는 2개의 작업 모두가 한 묶음으로 같이 수행된다.

하지만, 이 방식은 이벤트가 레플리카 서버의 릴레이 로그에 기록되는 것 까지만 보장한다. 즉, 릴레이 로그의 내용이 SQL 쓰레드에 의해 레플리카 서버의 스토리지에 실제로 반영되는 것까지 확인하고 응답하지는 않는다. 다시 해석하자면, 동기화 대상을 "전송" 하는 것까지만 보장하고 실제로 스토리지에 "적용" 되는 것 까지는 보장하지 않는다.

이 방식 또한 어찌보면 당연하게 설계된 방식이다. 만약 각 레플리카 서버의 스토리지에 실제로 잘 적용되는 것 까지 모두 확인하고 응답하는 구조였다면, N개의 레플리카 서버를 배치한 환경이라면 하나의 SQL 문을 N+1번 실행하는 것과 같은 성능 저하를 부를 것이기 때문이다.

장점

복제 과정에서 데이터 정합성이 중요하고, 성능은 다소 떨어져도 되는 상황에 사용하기 적합하다. 레플리카 서버로부터 ACK 응답을 받은 뒤 트랜잭션을 커밋하므로 최소 하나의 이상의 레플리카 서버에는 복제가 성공했음을 보장할 수 있다.

단점

계속 설명했듯이, 비동기 방식에 비해 느리다. 반동기를 위한 네트워크 통신이 1번 더 발생하고, 레플리카 서버에 문제가 있어서 ACK 응답속도가 늦어질 경우 그만큼 트랜잭션 수행시간이 더 늦어진다. 이 떄문에 소스와 레플리카 서버가 물리적으로 가까이 위치한 경우에 사용하기 좋을 것이다.

AFTER_SYNC vs AFTER_COMMIT

반동기 복제 또한 2가지 종류로 나뉜다. 정확히 어떤 시점에 이벤트를 레플리카 서버로 전송하고 응답을 받느냐에 따라 AFTER_SYNC, AFTER_COMMIT 으로 나뉜다.

AFTER_COMMIT : 소스 서버의 이벤트(트랜잭션)를 바이너리 로그에 기록하고, 스토리지에 커밋해서 실제로 적용하는 것까지 모두 마친 뒤에 레플리카 서버로 이벤트를 전송하는 방식이다. 커밋 이후에 복제를 진행하기 때문에 AFTER COMMIT 반동기 복제라고 부른다.
AFTER_SYNC : 레플리카 서버의 릴레이 로그에 정상적으로 기록이 되었음을 확인받은 뒤에야 안전하게 스토리지에 커밋하는 방식이다. 이는 동기화 이후에 트랜잭션 커밋을 수행하기 때문에 AFTER SYNC 반동기 복제하고 부른다.

AFTER COMMIT

반동기 복제 방식을 지원하기 시작한 초기에, 디폴트로 실행되던 AFTER COMMMIT 방식은 특정 장애 상황이 발생했을 때 문제가 있었다. 만약 소스 서버가 트랜잭션을 커밋한 뒤, 레플리카 서버에 이벤트를 전송하는 도중에 장애가 터졌다고 가정해보자. 문제점은 아래와 같다.

(1) 장애가 터진 소스 서버를 대신하여 레플리카 서버를 새로운 소스 서버로 대체했을 때, 기존 소스 서버에는 정상적으로 반영되었던 데이터 변경이 새롭게 대체된 소스 서버에는 반영되지 않은, 의도하지 않은 롤백이 발생할 수 있다.
(2) 팬텀리드(Phantom Read) 가 발생할 수 있다. 장애가 터진 소스 서버를 즉시 고쳐서 다시 운영 환경에 투입했을 경우, 새로운 소스 서버에는 반영되어 있지 않은 데이터 변경사항이 FailOver 되어 다시 투입된 소스 서버에는 반영되어 있는 문제가 발생할 수 있다.

흔치 않는 장애 발생 상황이긴 하지만, 팬텀 리드와 같은 데이터 정합성 문제가 일어날 여지가 있는 방식이 AFTER COMMIT 이다.

AFTER SYNC

위와 같은 AFTER COMMIT 의 데이터 정합성 문제를 해결하기 위해, MySQL 8.0 부터는 디폴트로 레플리카 서버의 릴레이 로그에 정상적으로 기록이 되었음을 확인받은 뒤에야 스토리지에 커밋하는 방식을 채택하게 되었다. 앞서 설명했듯이, 이는 동기화 이후에 트랜잭션 커밋을 수행하므로 AFTER SYNC 반동기 복제라고 한다.

AFTER SYNC 방식에서 앞선 장애 상황이 터졌을 때, 레플리카 서버에는 반영되지 않았지만 소스 서버에만 반영되는 일은 발생하지 않는다. 따라서 팬텀 리드가 발생하지 않는다.

어떤 동기화 복제 방식을 선택해야 할까?

데이터 정합성을 위해선 확실히 비동기 방식에 비해 반동기 방식이 유리해보인다. 하지만, 성능은 더 느릴 것이다. 과연 데이터 정합성 보장을 위해 성능을 포기하면서까지 AFTER SYNC 방식을 택하는 것이 좋을까?

사실상 데이터의 레플리케이션 작업은 생각보다 매우 짧은 시간에 이루어진다. 보통의 경우 약 200ms ~ 300ms 라는 짧은 시간안에 데이터를 복제해서, 데이터 불일치로 생기는 불편함을 느낄 일이 흔히 발생하지 않는다.

어떤 동기화 복제 방식을 택할지는 서비스 특성에 따라 다를 것이다. 만약 변경된 데이터를 정말 즉각적으로 읽어야하는 민감한 서비스라면, 아무래도 반동기 방식이 더 유리할 것이다. 상황에 따라 얼만큼을 성능을 고려하고, 데이터 정합성을 고려할지 생각해보자.

정리

비동기 복제 방식 : 트랜잭션 처리 속도가 빠르지만, 레플리케이션의 성공을 반드시 보장하지 않는다.
반동기 복제 방식 : 트랜잭션 처리 속도가 느리지만, 레플리카 서버로의 전송을 보장해준다.

참고

https://velog.io/@backfox/무뇽이와-알아보는-대규모-데이터-관리-데이터베이스-복제하기리플리케이션-f4pota6h
Real MySQL 8.0 - 백은빈, 이성욱

Redis 분산 락(Distribution Lock)을 구현하여 동시성 해결하기

Sat, 21 Dec 2024 00:00:00 GMT

분산 락(Distribution Lock)

스프링 웹 애플리케이션은 기본적으로 멀티 쓰레드 환경에서 구동된다. 이를 위해 여러 쓰레드가 함께 접근할 수 있는 공유 자원에 대한 경쟁 상태(Race Condition) 가 발생할 수 있고, 임계영역(Critical Section) 에 대한 동시성 제어 메커니즘을 사용할 수 있다.

특히나, 자바 진영에서는 모니터 기반의 상호 배제(mutual exclusion) 기법을 제공하는 synchornized 키워드를 제공한다. 하지만, 이 키워드를 사용하면 임계영역에 대한 동시 접근을 제어할 수 있지만, 문제는 단일 서버에서만 상호 배제를 보장한다는 점이다. 우리는 이를 통해, 다중화된 분산 환경에서 여러 서버의 동시성 문제를 다루기 위한 락 메커니즘이 필요함을 느낄 수 있다.

분산 락(Distribution Lock) 은 다중화된 분산 환경에서 상호 배제(mutual exclusion) 기반의 락 메커니즘을 제공한다. 즉, 분산된 여러 서버들은 모두 동일한 락 제공처로부터 락을 획득하고(acquire), 해제(release)할 수 있다. 이떄 분산 환경에서 제공되는 락 타입을 분산 락이라고 하며, 락 제공처는 가장 많이 사용되는 것이 Redis, Zookeeper 등이 있다. 다시 정리하자며느 분산 환경에서 여러대의 서버들은 락을 획득하기 위해 Redis 와 같은 락 제공처를 바라보며, 임계영역에 접근할 수 있는지 확인하고, 대기하고, 수행한다.

이번 포스팅에서는 Redis 를 사용하여 간단히 분산 락을 구현해보도록 한다. RedLock 알고리즘에 대해서도 다루어볼까 하는데, 이는 다음 포스팅에서 천천히 다루어볼까 한다.

동시성 이슈 발생 상황 가정

동시성이 터질만한 애플리케이션 요구사항을 하나 만들어 볼 것이다. 우리는 대학교 수강신청 사이트에서 동시성 이슈가 터지는 상황을 하나 가정해보고, 이를 Redis 를 활용한 2가지 방법의 분산 락으로 해결해볼 것이다. 그리고 인프라 아키텍처는 간딘히 아래와 같이 구성했다.

스프링부트 애플리케이션 인스턴스 2대를 띄웠다.
MySQL 서버에 수업에 대한 더미 데이터를 미리 띄웠다.

Course

수업에 대한 엔티티이다. 수업명, 수강신청 제한 수, 현재까지의 수강신청 인원 수로 구성했다.

@Entity
@Getter
public class Course {
    @Id
    @GeneratedValue(starategy = GenerationType.IDENTITY)
    private int id;
    private String courseName;
    private int countLimit;
    private int currentCount;

    public boolean isOverFlow() {
        return currentCount > countLimit;
    }
}

CourseController

컨트롤러는 아래와 같이 간단히 구성했다.

@RestController
@RequestMapping("/course")
public class CourseController {
    private final CourseService courseService;

    public CourseController(final CourseService courseService){
        this.courseService = courseService;
    }

    @ResponseBody
    @PostMapping("/registration/{courseIdx}")
    public ResponseEntity<RegisterRes> registerCourse(@PathVariable("courseIdx") final int courseIdx) throws InterruptedException{
        RegisterRes registerRes = courseService.registerCourse(courseIdx);
        return ResponseEntity.created(URI.create("/course/registration/"))
                .body(registerRes);
    }
}

CourseRepository

레포지토리는 아래와 같이 구성했다.

@EnableJpaRepositories
public interface CourseRespository extends JpaRepository<CourseEntity, Integer> {
    CourseEntity findById(final int id);
}

CourseService

수강 신청의 핵심 로직을 담당하는 서비스 레이어이다. isOverFlow() 를 통해 수강신청 인원이 초과했는지를 검증하도록 간단히 구현했다.

@Service
public class CourseService {
    private final CourseRespository courseRespository;
    private final RedisLockRepository redisLockRepository;

    @Autowired
    public CourseService(CourseRespository  courseRespository, RedisLockRepository redisLockRepository){
        this.courseRespository = courseRespository;
        this.redisLockRepository = redisLockRepository;
    }


    @Transactional
    public RegisterRes registerCourse(int courseIdx) {
        CourseEntity courseEntity = courseRespository.findCourseEntityByCourseIdx(courseIdx);

        courseEntity.setCurrentCount(courseEntity.getCurrentCount() + 1);

        if(courseEntity.isOverFlow()){
            throw new RuntimeException("마감 되었습니다");
        }

        return new RegisterRes(courseEntity.getCurrentCount());
    }
}

Jmeter 를 사용하여 동시간대에 100개의 요청을 보내도록 한다. 그러면 분명히 100개의 쓰레드가 요청했음에도 불구하고, currentCount 값이 100이 아닌 19밖에 증가히지 않았다. 즉, 동시성 이슈가 발생했다. 앞서 설명했듯이, 우리의 환경은 단일 서버가 아닌 분산 환경이므로 synchornized 으로도 이를 해결할 수 없다. (사실 JPA 락 메커니즘을 사용하는 것을 고려해볼 수 있지만, 현재 포스팅에선 고려 대상에서 일단 제외한다.)

이를 Redis 에서 제공하는 분산 락으로 해결해보자. 분산 락 구현방식에는 크게 2가지가 존재한다.

Redis SETNX 를 뢀용

💡 Redis 2.6.12 버전 이전에는 SETNX 명령어가 제공되었지만, 2.6.12 버전부터는 deprecated 되었다고 한다. SET 명령어에 NX 옵션을 전달하는 방향으로 수정하였다. 우선, SETNX 명령을 기준으로 설명한다. 이후 포스팅에서 2.6.12 이후 버전의 RedLock 알고리즘에 대해 다루어보고자 한다.

Redis 에는 SETNX 라는 명령어가 존재한다. "SET if Not eXists" 의 줄임말이다. 말 그대로 특정 key 에 value 가 존재하지 않을때만 값을 설정할 수 있다는 뜻이다.

127.0.0.1:6379> setnx 1 lock
(integer) 1
127.0.0.1:6379> setnx 1 lock
(integer) 0
127.0.0.1:6379> del 1
(integer) 1
127.0.0.1:6379> setnx 1 lock
(integer) 1

위는 SETNX 명령어를 사용한 모습이다. Key 1 에 lock 이라는 value 를 설정하는 장면이다. 최초에는 key 에 아무값도 설정되어 있지 않기 때문에 1을 반환하며 성공한다. 그런데, 이후 동일한 명령어를 또 실행하는데, 이미 해당 key 에 대한 value 가 존재하기 때문에 0을 반환하며 실패하였다. 이후 DEL 명령어를 통해 key 1의 데이터를 가져오고, 동일하게 SETNX 명령어를 실행하니 다시 1을 반환하며 성공한다.

SETNX 명령을 활용하면 스핀 락(Spin Lock) 을 구현하여 동시성을 해결할 수 있다. 즉, Redis 서버에 지속적으로 SETNX 명령어를 보내서 임계 영역 진입 여부를 확인한다. 이를 위해 아래와 같이 의존성을 추가하고, 스핀 락을 구현해보자.

implementation 'org.springframework.boot:spring-boot-starter-cache'

RedisRepository

Redis 분산 락을 얻고 해제하는 레포지토리 컴포넌트를 간단히 생성해주었다.

@Component
public class RedisLockRepository {
    private RedisTemplate<String, String> redisTemplate;

    public RedisLockRepository(final RedisTemplate<String, String> redisTemplate){
        this.redisTemplate = redisTemplate;
    }

    public Boolean lock(final int key){
        return redisTemplate.opsForValue()
                .setIfAbsent(String.valueOf(key), "lock", Duration.ofMillis(3_000));
    }

    public Boolean unlock(final int key) {
        return redisTemplate.delete(String.valueOf(key));
    }
}

RedisTemplate 을 주입받아서 락을 관리하는 RedisLockRepository 를 구현한다. lock() 메소드는 이름 그대로 락을 획득하는 것으로, setIfAbsent() 를 사용하여 SETNX 명령어를 실행시킬 수 있다. 이때, key 는 Course 엔티티에 대한 PK 값으로, value 는 lock 으로 설정한다. 3번째 파라미터는 타임아웃 설정이다. 즉, 락을 3초 이상 획득하지 못한 쓰레드는 타임아웃된다.

unlock() 메소드는 key 에 대해 DEL 명령어를 실행한다. 이를 통해 락을 해제할 수 있다.

CourseService

@Service
public class CourseService {
    private final CourseRespository courseRespository;
    private final RedisLockRepository redisLockRepository;

    public CourseService(CourseRespository  courseRespository, RedisLockRepository redisLockRepository){
        this.courseRespository = courseRespository;
        this.redisLockRepository = redisLockRepository;
    }

    public RegisterRes registerCourse(int courseIdx) throws InterruptedException {
        while (!redisLockRepository.lock(courseIdx)) {
            Thread.sleep(100);
        }

        try {
            CourseEntity courseEntity = courseRespository.findCourseEntityByCourseIdx(courseIdx);
            courseEntity.setCurrentCount(courseEntity.getCurrentCount() + 1);

            if (courseEntity.isOverFlow()) {
                throw new RuntimeException("마감 되었습니다");
            }

            return new RegisterRes(courseEntity.getCurrentCount());
        } finally {
            redisLockRepository.unlock(courseIdx);
        }
    }
}

registerCourse() 에 스핀 락을 적용하였다. while 문을 활용해서 락을 획득할 때 까지 무한 반복과 대기를 한다. Redis 서버에 부하를 덜기위해 100ms 를 쉬어주고, 임계영역에 진입후 수강신청에 대한 로직을 처리후 finally 블럭으로 락을 해제해준다. 이때 락을 해제해주지 않으면 다른 쓰레드에서 임계영역에 진입하므로 주의하자.

위와같은 스핀 락 방식 과연 적합한 구현 방식일까? 몰론 기본적으로 제공되는 Redis Client 인 Lettuce 만으로도 금방 락 메커니즘을 구현할 수 있기 때문에, 구현 난이도가 낮을 것이다. 하지만, 스핀 락 방식으로 동작하므로 Redis 서버와 스프링 애플리케이션 서버 모두에 심한 부하가 생길 것이다.

Redis 의 Pub/Sub 기반 메시지브로커 활용 (Redisson 클라이언트)

스핀 락으로 인해 발생하는 심한 부하는 사실상 서비스에 도입하기란 무모하다. 이번에는 스핀락처럼 부하가 발생하는 기능이 아닌, 더 효율적인 방법으로 구현해보자. Redis 가 제공하는 Pub/Sub 메시지브로커를 사용하여 분산 락을 구현해보자. Pub/Sub 과 관련한 내용은 Redis Pub/Sub 을 사용한 분산 환경에서 로컬 캐시 동기화 에서도 다룬적이 있다.

Redis 의 Pub/Sub 의 활용하면, 락을 해제할 주체자(Publisher) 가 다른 클라이언트(Subscriber) 에게 락 획득 가능 메시지를 브로드케스트 한다. 즉, 락이 해제될 때 마다 Subscriber 들에게 락 획득을 이제 시도해도 된다라는 메시지를 발행한다. 이를 통해, 앞선 SETNX 명령어 기반 스핀 락 방식과 달리 락 획득 여부를 체크하지 않아도 된다.

Redisson 이라는 라이브러리는 Redis 의 Pub/Sub 을 활용하여 분산 락 메커니즘을 구현했다. 이 라이브러리는 타임아웃 기능 또한 제공하여, 일정 시간동안 락을 획득하지 못하면 타임아웃 되도록 처리할 수 있도록 한다. Redisson 을 사용하기 위해 아래와 같이 의존성을 추가해주자.

implementation 'org.redisson:redisson-spring-boot-starter:3.17.7'

CourseService

RedissonClient 을 아래와 같이 주입받자.

 public CourseService(final CourseRespository courseRespository, RedissonClient redissonClient){
    this.courseRespository = courseRespository;
    this.redissonClient = redissonClient;
}

그리고 아래처럼 redissonClient.getLock() 을 통해 락을 획득하고, tryLock() 을 통해 락 획득을 시도한다. 락 획득에 성공하면 임계영역에 진입하여 비즈니스 로직을 수행하고, finally 블럭에서 unlock() 한다. 락 획득을 실패하였으면, 끊임없이 레디스 서버에 재확인하는것이 아니라 대기 상태로 들어가 메시지가 발행되기를 기다린다.

public RegisterRes registerCourse(Long courseIdx){
    RLock lock = redissonClient.getLock(String.valueOf(courseIdx));

    try{
        boolean available = lock.tryLock(100 ,2, TimeUnit.SECONDS);
        int newCourseIdx = Math.toIntExact(courseIdx);

        if(!available){
            throw new RuntimeException("Lock 획득 실패!");
        }

        // 비즈니스 로직 (임계영역)
        CourseEntity courseEntity = courseRespository.findCourseEntityByCourseIdx(newCourseIdx);
        courseEntity.setCurrentCount(courseEntity.getCurrentCount() + 1);

        if (courseEntity.isOverFlow()) {
            throw new RuntimeException("마감 되었습니다");
        }

        return new RegisterRes(courseEntity.getCurrentCount());
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    } finally {
        lock.unlock();
    }
}

JPA 락 메커니즘 vs 분산 락

JPA 에서 제공하는 낙관적 락, 비관적 락의 주 관심사는 특정 엔티티에 대한 동시성 제어이다. 즉, 동시성을 제어히기 위한 엔티티가 존재해야한다. 반면, 분산 락은 synchornized 와 같이 임계영역에 대한 접근 제어이다. 엔티티 접근 제어가 아닌, 여러 엔티티에 대한 생성, 수정, 삽입, 삭제 그 모든 행위에 대해 접근을 제어할 수 있다.

우리 서비스에서 비관적 락을 사용하는데, 문제가 되진 않을까?

가장 고민이 많았던 요소 중 하나는, 우리 모행 서비스에는 어떠한 동시성 제어 락 메커니즘을 취하는가이다. MySQL 8.0 레플리케이션과 스프링부트 DataSource 라우팅을 통한 부하 분산 에서도 다루었듯이, 해당 포스팅에서 다룬 내용과 거의 유사한 구조로 데이터베이스 레플리케이션 구조를 취하고 있다. 이러한 상황에서 우리 서비스는 JPA 비관적 락을 사용하는데, 다중화된 데이터베이스 환경에서 ROW 단위의 락을 걸어도 괜찮은가이다.

하지만, 이는 다행히 문제가 되지 않는다. JPA 비관적 락은 PESSIMISTIC_WRITE 옵션 기준으로 쓰기 락, 베타 락을 설정한다. PESSIMISTIC_WRITE 데이터에 변경 가능성이 있는 연산이므로, 쓰기 트랜잭션으로 간주된다는 것이다. 따라서 이 FOR UPDATE 절을 사용하는 쿼리는 Master 서버로 전송된다. 우리는 AbstractRoutingDataSource 를 통해 쓰기 연산에 대해선 Master 서버로 라우팅하도록 되어있는데, 현재 Master 서버는 단 1대밖에 존재하지 않으며, Slave 서버로 전송되지 않는다. 따라서 쓰기 연산에 대한 데이터 정합성에 문제가 되지 않는다.

만약 우리 서비스가 더 거대해져서 Master 서버가 2대 이상으로 커진다면, Master 서버간에 락을 공유할 방법이 없다. 즉, 각 Master 서버는 중앙화된 락 제공처를 사용하지 않으므로, 락이 각기 별개로 관리된다. 이 문제는 현재 포스팅에서 다룬 Redis 분산 락을 통해 동시성 문제를 해결해볼 수 있을 것이다. 2대 이상의 다중화된 데이터베이스 환경이라면 ROW 단위의 락 설정에 대해 잘 고려해야한다.

MySQL 네임드 락 vs Redis 분산 락

MySQL 의 네임드 락의 경우 GET_LOCK(문자열, Timeout) 을 통해 락을 획득하고, RELEASE_LOCK(문자열) 을 통해 락읗 해제하는 방식으로 구현할 수 있다. 또한 GET_LOCK 을 얻을 때 타임아웃 시간을 지정하게 되는데, 타임아웃 시간 내에서 동시 요청에 의한 작업들은 누락되지 않고, 정상적으로 처리되는 부분이 있다.

네임드 락의 장점으로는 추가적인 리소스가 필요하지 않는다. 다른 소프트웨어를 사용하지 않고도 기존의 DB 인 MySQL 로 분산락을 구현할 수 있는 장점이 있다. 하지만 단점으로는 락에 대한 정보가 테이블에 따로 저장되어 무거워질 수 있고, 실제 DB 에 락으로 인한 커넥션 대기가 발생하기때문에 성능상 단점이 있다.

그에 비해 Redis 메세지 브로커를 이용한 분산락은 락에 대한 정보는 휘발성이 있고, 메모리에서 락을 획득하고 해제하기때문에 가볍다는 장점이 있다.

마치며

만약 우리 모행 서비스가 분산된 환경이라면, 상황에 따라 Redis 분산 락을 적극 고려해볼 것이다. 하지만, 지금 모행 서비스는 단일 서버인 점을 감안한다면 Redis 분산 락을 도입할 이유가 없다. 또한, JPA 의 비관적 락 만으로도 엔티티에 대한 충분히 동시성을 해결할 수 있다. ROW 단위에 대해서만 락을 거는 것에 비해 상호 배제 기반의 분산 락을 도입하여 불필요하게 성능 저하를 일으킬 이유는 없다.

다음 포스팅에선 Redis 의 RedLock 알고리즘에 대해 간단히 학습하도록 한다.

참고

하모니 팀의 Jenkins와 Nginx를 활용한 Blue/Green 무중단 배포 도입기

Sat, 21 Dec 2024 00:00:00 GMT

💡 현재 포스트는 하모니 팀 기술 블로그 에도 게시된 글 입니다.

기존 배포 방식에서 Downtime이 발생하는 문제점

기존의 모행 배포 파이프라인 스크립트는 아래와 같다. 우선 (1) 구동중인 애플리케이션을 확인하고 (2) 구동중인 애플리케이션이 존재한다면 종료시킨다. (3) 그리고 이후 jar 파일을 실행하여, 신버전 스프링부트 애플리케이션이 구동된다.

if [ -z "$CURRENT_PID" ]; then
        echo "구동중인 애플리케이션이 없으므로 종료하지 않습니다."
else
        echo "구동중인 애플리케이션을 종료합니다."
        kill -15 $CURRENT_PID
fi

sudo -E nohup java -jar /home/ubuntu/myproject/deploy/core-0.0.1-SNAPSHOT.jar &

그런데 문제점이 있다. 과정 (2) 에서 (3) 으로 넘어갈 때, 우리 서비스가 일시적으로 중단되어 이용 불가능한 상태가 된다. 즉, 구버전 프로세스를 종료하고 새로운 프로세스를 실행하는 과정에서 서비스가 중단된다. 실제로 우리 서비스 다운타임을 측정한 결과, 약 7초정도의 다운타임이 발생하는 것을 확인할 수 있었다.

무중단 배포 전략은 왜 필요할까?

서비스가 새로운 버전이 배포될 때 마다 일시적으로 사용할 수 없다면 누가 해당 서비스를 마음놓고 사용할까? 무엇보다 우리 팀처럼 애자일하게 자주 배포하는 환경에서는 더욱이 서비스 중단이 자주 발생한다. 간혈적인 서비스 중단은 유저 이탈로 이어지게 될 것이다.

따라서 24시간 서비스를 중단 없이 사용할 수 있도록 배포 환경을 구축해야한다. 이렇게 일시적으로 서비스를 이용 불가능한 시간을 다운타임(Downtime) 이라고 하며, 다운타임이 발생하지 않도록 배포하는 전략을 무중단 배포(Zero-Downtime Deployment) 전략이라고 한다. 지금부터 우리 모행 서비스에 어떻게 무중단 배포 전략을 구현했으며, 기존에 발생한 다운타임을 제거했는지 소개해보고자 한다.

우리 서비스에 어떤 무중단 배포 전략을 취했을까?

롤링(Rolling) 배포

롤링(Rolling) 배포 전략이란, 각 서버에서 구동중인 애플리케이션을 점진적으로 구버전에서 새로운 버전으로 차근차근 하나씩 전환하며 바꾸는 방식을 뜻한다.

롤링 배포 전략의 경우, EC2 인스턴스 개수가 제한된 환경에서 사용하기 좋은 전략이다. 다만, 배포가 진행중인 시점에는 유저의 트래픽이 구버전과 신버전으로 동시에 향하게 되므로 정합성 이슈가 발생할 수 있으므로 제외하였다.

카나리(Canary) 배포

다음으로 카나리(Canary) 배포 전략이란, 소수 인원에 대해서만 트래픽을 새로운 버전에 옮겨둔 상태에서 서비스를 운영하는 전략이다. 새로운 버전에 이상이 없다고 판단하였을 경우에 신버전에 대해 트래픽 유입율을 점진적으로 올려간다. A/B 테스트를 하기에 적합하다.

대규모 트래픽이 유입되고, 팀 규모가 큰 서비스들에선 카나리 배포 전략을 취하는 경우가 많다. 다만, 우리 서비스는 카나리 배포 전략을 도입할 만큼 서비스 규모와 팀의 규모가 아직은 크지 않다. 카나리 배포의 취지는, 신버전에서 발생할 오류를 조기에 감지하고, 문제가 발생하면 빠르게 롤백하는 방식이다. 다만, 우리는 트래픽을 점진적으로 옮겨가며 배포하며 사전 오류를 감지할 즉시 대응할 정도로 민감하지 않아, 이 또한 제외했다. 또한 팀의 규모가 크지않다. QA, CS 담담자등이 존재하지 않기에, 사전 테스팅 및 즉각 오류 감지에 대해 관리할 정도로 규모가 있지 않기에, 되려 카나리 배포 도입 근거가 옅어지기에 제외하였다. 다만, 향후 서비스와 팀의 규모가 커진다면 카니리 배포로 전환하는 하는 것이 매우 좋아보인다.

블루그린(Blue/Green) 배포

블루그린(Blue/Green) 배포 전략이란, 현재 운영중인 서비스를 종료하지 않고 새로운 운영 환경을 만든 뒤 트래픽을 한 번에 신버전으로 옮기는 방식이다. 마치 빅뱅 배포 방식이라고 보면 된다.

우리 팀은 블루그린 배포 전략을 취했다. 블루그린 배포는 어떠한 장점이 있을까? 우선 (1) 블루그린 배포는 롤링 배포와 달리 한번에 트래픽을 모두 새로운 버전으로 옮기기 때문에 호환성 문제가 발생하지 않는다. (2) 또한, 카나리 배포에 비해 우리 서비스처럼 아직 서비스 규모가 크지 않은 경우에 구성하기 매우 편리하고 적합한 배포 전략이다. (3) 무엇보다 포트(port) 를 스위칭하는 배포 전략을 취한다면, 서버를 증설하지 않고도 충분히 무중단 배포가 가능하다. 다시말해, 상대적으로 저렴한 서버 비용으로 무중단 배포를 충분히 구현할 수 있다.

다만, 향후 서비스와 팀의 규모가 확장된다면 카나리 배포 전략을 고려해보는 것도 좋은 선택안 일 것이다.

Blue/Green 배포 파이프라인 구현

지금부터, 우리 서비스에서 구현한 블루그린 배포 전략 파이프라인 스크립트를 구현해보겠다. 그를 통해 무중단 배포가 어떻게 동작하는지 소개해볼까 한다. 우리 팀은 8080 포트와 8081 포트를 번갈아 스위칭하는 방식으로 무중단 배포 전략을 사용하였으며, 내부 동작 과정을 정리하면 아래와 같다.

(1) 깃허브가 Jenkins에 Webhook 요청을 전송한다.
(2) Jenkins는 새로운 버전 코드를 pull 해오고 jar 파일을 빌드한다.
(3) Jenkins는 구버전 프로세스가 8080 포트로 실행되고 있는지, 또는 8081 포트로 실행되고 있는지 확인한다. 이를 위해, Blue 서버에 Health Check 를 시도한다. Blue 가 살아있다면 신버전을 Green 에 배포하면 되고, 살아있지 않다면 Blue 에 배포한다.
(4) (구버전 프로세스가 8080 포트로 실행되고 있다는 가정하에) Green 서버인 8081 포트로 신버전 프로세스를 배포한다. Green 서버에 맨 처음 빌드해둔 jar 파일을 전송하고, 신버전 애플리케이션을 구동시킨다.
(5) 지속적으로 8081 포트로 헬스체크를 시도하여, 신버전 애플리케이션이 제대로 구동되었다면 (6) 으로 넘어간다.
(6) Nginx 의 리버스 프록시 설정을 변경하여 8080 으로 프록싱하던 설정을 8081로 변경하고 Reload 한다. 즉, Nginx 프록시 방향을 Blue 에서 Green 으로 스위칭한다. 이렇게 되면 앞으로 모든 클라이언트의 트래픽이 신버전 애플리케이션으로 향한다.
(8) 곧바로 8080 포트로 구동중이던 구버전 프로세스 (Blue 서버) 를 kill 한다.

Nginx 리버스 프록시 환경 설정

본격적인 젠킨스 파이프라인 구성에 앞서, Nginx 에 대한 설정이 필요하다. 이를 간략히 살펴보자.

sites-enabled

server {
    listen 80;

    include /etc/nginx/conf.d/service-url.inc;

    location / {
        proxy_pass $Service_url;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
    }
}

위 설정을 보면 include 라는 지시어를 볼 수 있다. 이는 외부에서 설정파일을 불러올 수 있는 Nginx의 기능이다. 또한 $service_url 이라는 URL 로 리버스 프록시 요청을 보내는 것을 볼 수 있다. 이 변수에는 service-url.inc 파일로부터 변수 값이 할당된다.

service-url.inc

set $service_url https://111.111.111:8080;

기본적으로 Blue 인스턴스의 포트번호 기반으로 초기 변수값을 설정해두었으나, Green 서버로 설정해도 상관없을 것이다. 젠킨스가 이 파일을 직접 수정하여 리버스 프록시 방향을 바꿔줄 것이다.

Jenkins 무중단 배포 스크립트

아래는 새롭게 개선한 젠킨스 무중단 배포 스크립트이다. stage Github 와 Build 는 깃허브에서 신규 버전의 소스 코드를 가져와 애플리케이션을 빌드하는 과정이다. 핵심은 stage Deployment 의 쉘 스크립트 내용이다. 이를 자세히 살펴보자.

pipeline {
    agent any
    stages {
        stage('Github') {
            steps {
                git branch: 'develop-backend', url: 'https://github.com/kakaotech-25/moheng.git'
            }
        }
        stage('Build') {
            steps {
                sh "./gradlew bootJar"
            }
        }

        stage('Deployment') {
            steps {
                sshagent (credentials: ['key-jenkins']) {
                    sh '''#!/bin/bash
                        if curl -s "http://${BACKEND_PUBLIC_DEV_IP}:${BLUE_PORT}" > /dev/null
                        then
                            deployment_target_port=${GREEN_PORT}
                        else
                            deployment_target_port=${BLUE_PORT}
                        fi

                        scp -o StrictHostKeyChecking=no ./build/libs/core-0.0.1-SNAPSHOT.jar root@${BACKEND_DEV_IP}:/home/ubuntu
                        ssh root@${BACKEND_DEV_IP} "nohup java -jar -Dserver.port=${deployment_target_port} /home/ubuntu/core-0.0.1-SNAPSHOT.jar > /dev/null &" &


                        for retry_count in \$(seq 5)
                        do
                          if curl -s "http://${BACKEND_DEV_IP}:${deployment_target_port}
                          then
                              echo "✅ Health Checking 에 성공했습니다! 포트 번호: ${deployment_target_port}"
                              break
                          fi

                          if [ $retry_count -eq 10 ]
                          then
                            echo "❌ Health checking 에 실패했습니다."
                            exit 1
                          fi

                          echo "🏥 10초후에 다시 Health Checking 이 시도될 예정입니다."
                          sleep 10
                        done

                        ssh root@${nginx_ip} "echo 'set \\\$service_url http://${BACKEND_DEV_IP}:${deployment_target_port};' > /etc/nginx/conf.d/service-url.inc && service nginx reload"
                        echo "Switch the reverse proxy direction of nginx to ${deployment_target_port} 🔄"

                        if [ "${deployment_target_ip}" == "${blue_port}" ]
                        then
                            ssh root@${BACKEND_DEV_IP} "fuser -s -k ${GREEN_PORT}/tcp"
                        else
                            ssh root@${BACKEND_DEV_IP} "fuser -s -k ${BLUE_PORT}/tcp"
                        fi
                        echo " ✅ 구버전 프로세스를 종료하고, 신버전 프로세스로 교체합니다."
                    '''
                }
            }
        }
    }
}

1. Blue 서버 Health Check 및 배포할 포트번호 설정

if curl -s "http://${BACKEND_DEV_IP}:${BLUE_PORT}" > /dev/null
then
    deployment_target_port=${GREEN_PORT}
else
    deployment_target_ip=${BLUE_PORT}
fi

Blue 서버에서 애플리케이션이 구동중인지 curl 로 헬스체킹한다. -s 옵션은 slient 옵션으로, 프로그래스 바가 출력되지 않도록 한다. /dev/null 은 리눅스에서 null device를 나타내며, 이곳으로 쓰여진 데이터를 마치 블랙홀처럼 공허로 버려진다. 리다이렉션 ">" 을 통해 curl 의 표준 출력을 버리기 위해 사용한다.

curl 을 통한 헬스체킹 결과에 따라, Blue 가 살아있다면 deployment_target_port 를 ${GREEN_PORT} 로 설정하고, 죽어있다면 ${BLUE_PORT} 로 설정한다.

2. jar 파일 전송 및 새로운 포트 번호로 애플리케이션 실행

scp -o StrictHostKeyChecking=no ./build/libs/core-0.0.1-SNAPSHOT.jar root@${BACKEND_DEV_IP}:/home/ubuntu
ssh root@${BACKEND_DEV_IP} "nohup java -jar -Dserver.port=${deployment_target_port} /home/ubuntu/core-0.0.1-SNAPSHOT.jar > /dev/null &" &

scp 명령으로 $BACKEND_DEV_IP 인스턴스에 jar 파일을 전송하고, ssh 명령으로 해당 파일을 실행하여 애플리케이션을 구동한다. 이때, 구동할 애플리케이션 포트 번호로 ${deployment_target_port} 를 지정한다.

3. 주기적인 Health Check 로 새로운 포트에 애플리케이션이 잘 떴는지 확인

for retry_count int \$(seq 10)
do
  if curl -s "http://${BACKEND_DEV_IP}:${deployment_target_port}" > /dev/null
  then
    echo "✅ Health Checking 에 성공했습니다!"
    break
  fi

  if [ $retry_count -eq 10 ]
  then
    echo "❌ Health checking 에 실패했습니다."
    exit 1
  fi

  echo "🏥 10초후에 다시 Health Checking 이 시도될 예정입니다."
  sleep 10
done

최대 10번, 10초 간격으로 ${deployment_target_port} 포트 번호를 가진 새로운 인스턴스에 curl 을 통해 Health Check 를 시도한다. 10번안에 Health Check 에 성공했다면, 다음 과정으로 넘어간다. 반대로 실패했다면 exit 로 스크립트 실행을 중단한다.

4. Nginx 리버스 프록시 방향 변경

ssh root@${nginx_ip} "echo 'set \\\$service_url http://${BACKEND_DEV_IP}:${deployment_target_port};' > /etc/nginx/conf.d/service-url.inc && service nginx reload"
echo "Switch the reverse proxy direction of nginx to ${deployment_target_port} 🔄"

앞선 헬스체킹에 성공했다면, $service_url 에 새로운 포트로 구동된 주소값을 할당하여 Nginx 가 새로운 프로세스를 바라볼 수 있도록 한다. 이후 Nginx 설정을 Reload 하여 설정을 반영한다.

5. 구버전 프로세스 Kill

if [ "${deployment_target_port}" == "${blue_port}" ]
then
    ssh root@${BACKEND_DEV_IP} "fuser -s -k ${GREEN_PORT}/tcp"
else
    ssh root@${BACKEND_DEV_IP} "fuser -s -k ${BLUE_PORT}/tcp"
fi

echo " ✅ 구버전 프로세스를 종료하고, 신버전 프로세스로 교체합니다."

배포된 서버가 $BLUE_PORT 라면 구버전인 $GREEN_PORT 서버의 프로세스를 Kill 한다. (그 반대라면 $BLUE_PORT 서버의 프로세스를 죽인다.) fuser 를 사용하면 특정 포트를 점유하고 있는 프로세스를 죽일 수 있다. -k 옵션을 붙여야 프로세스를 죽일 수 있다.

추가 개선점

이렇게 블루그린을 통해 우리 팀의 무중단 배포 전략을 직접 구현해보았다. 기존의 7초 가량의 다운타임이 약 0.03초로 크게 감소했다.

다만, 이때 0.03초의 다운타임은 왜 발생하는 것인지, 완벽히 제거하는 방법이 없는지와 관련한 궁금증이 생길 것이다. 이는 향후 별도의 포스팅에서 다루어볼까 한다. 이만 포스팅을 마쳐본다 😎

참고

Redis 는 왜 싱글 쓰레드인데 성능이 빠를까?

Fri, 20 Dec 2024 00:00:00 GMT

아직 제대로 지식이 체화된 것 같지는 않지만, 이해도를 더 확보하기 위해 짧게나마 글을 작성해본다. 특히 멀티플렉싱이 아직 추가 학습이 필요해보이지만, 우선 글을 쓰며 이해도를 보다 높인 후 향후 더 자세히 추가 학습해보도록 한다.

Redis

Redis 를 떠올리면 인메모리, key-value, 빠른 성능, 싱글 쓰레드등의 키워드가 떠오는다. 그런데 왜 싱글 쓰레드인데 성능이 빠른 것일까?

Redis 는 싱글 쓰레드와 멀티 쓰레드를 함께 사용한다.

이번에 처음 알았던 사실인데, Redis 는 싱글 쓰레드로 동작하되, 일부 기능에서 멀티 쓰레드 방식으로 동작한다. 클라이언트로부터 전송된 네트워크를 읽는 부분과 전송하는 부분은 멀티 쓰레드로 구현되어 있다. 아래 사진을 보면 알 수 있듯이, 멀티플렉싱(Multiplexing) 방식으로 클라이언트의 요청을 받아 이벤트 루프(Event Loop) 에서 싱글 쓰레드로 처리한다. 즉, 우리가 Redis 에 요청한 명령을 실행하는 부분은 싱글 쓰레드로 구현되어 있다. 이 때문에 싱글 쓰레드의 장점인 Atomic 연산이 가능해진다.

다시 정리하자면, 사용자의 요청을 받을 때와 해당 요청에 대해 메모리에 I/O 작업을 할 때는 멀티 쓰레드 방식으로 처리한다. 이후 각 요청들을 큐에 넣고 처리하는 부분은 싱글 쓰레드로 동작한다.

이 덕분에 수행되는 각 명령어들에 대한 원자성(atomic) 을 보장할 수 있고, 컨텍스트 스위칭 없이 빠른 작업이 가능하다.

멀티플랙싱(Multiplexing)

아직 멀티플렉싱 개념이 잘 와닿지는 않지만, 일단 작성해본다. I/O 멀티플렉싱이란 싱글 쓰레드가 여러 I/O 작업을 동시에 모니터링 할 수 있도록 해주는 기술이라고 한다. 이 방법을 사용하면, 여러 파일 디스크립터(File Descriptor) 의 I/O 상태를 하나의 호출로 확인하고, Non-Blocking Model 의 단점을 극복할 수 있게 해준다.

(1) 클라이언트 연결이 발생하면(소캣 생성), Redis 는 여러 연결(소캣)을 동시에 감시(모니터링)한다.
(2) 데이터가 준비되었는지 확인한 후, 준비 된 요청만 처리한다.
(3) 처리중인동안 다른 요청들은 대기하지 않고, 준비가 되면 바로 처리한다.

여기서 "준비된 요청" 이라는 말이 햇갈릴 수 있는데, 우선 준비가 안된 요청에 대해 먼저 설명해보겠다. 준비가 안된 요청이란 클라이언트가 Redis 에 데이터를 보내고 있지만, 아직 네트워크 지연등으로 인해 데이터가 도착하지 못해 처리하지 못하는 요청을 뜻한다. 이에 반면 준비된 요청이란 클라이언트의 요청이 완전히 도착했고, Redis 가 바로 읽고 처리할 수 있는 상태를 뜻한다. (마치 비유하자면, 식당에서 손님이 주문을 할 때 주방장이 손님이 주문을 말하고 있는 중에는 조리를 시작할 수 없고, 주문을 다 말했을 때 주문서를 보고 바로 요리를 시작할 수 있는 상황과 같다.)

이벤트 기반

또한 이벤트 기반으로 처리하기 떄문에 소켓 연결의 도착, 데이터의 도착, 데이터 전송 가능 상태등과 같은 상황을 받아서 처리할 작업을 그때그때 효율적으로 선택하고 처리할 수 있다.

정리

Redis 는 Multiplexing I/O 모델을 사용하여 하나의 싱글 쓰레드만으로도 여러 클라이언트에게 입출력이 가능하다.
이벤트 기반으로 처리하기 떄문에 동적으로 그때그때 처리할 이벤트를 빠르게 처리할 수 있다.

참고

토스 SLASH 22, 애플 한 주가 고객에게 전달되기 까지

Fri, 20 Dec 2024 00:00:00 GMT

💡 토스 SLASH 22, 애플 한 주가 고객에게 전달 되기까지 에서 필요한 내용을 발췌하여 간단히 정리하였다.

토스증권의 해외주식 원장계는 MSA를 기반으로 구성하였다. 각 도메인 별 모듈들이 독립적으로 구성되어 있기 때문에 단일 모듈의 장애 전파를 방지하고, 효율적인 리소스 관리가 가능하다.

토스증권은 한국 법인이므로, 나스닥과 같은 현지 거래소와 직접 거래할 수 없다. 이 때문에 중간에서 브로커(해외거레 중개인) 을 통해 주문을 제출하고, 체결한다. 브로커를 통해 주문을 체결하므로 토스증권과 브로커간의 주문 데이터 정합성 관리가 매우 중요하며, 네트워크 지연 이슈도 잘 고려해야한다.

주문 체결 플로우

고객의 주문은 (1) 매매 서버, 매매 요청 서버를 거쳐서 브로커에게 전달되고, 브로커는 해외 현지 거래소에 주문을 제출하게 된다. (이 과정은 모두 하나의 주문 트랜잭션으로 처리되는 듯 하다.) (2) 브로커를 통해 해외 거래소로 제출된 주문에 대한 체결 결과 여부를 처리하는 트랜잭션은 앞선 주문 트랜잭션과는 별개로 동작한다.

앞선 (2) 의 주문 체결 결과 처리 트랜잭션은 체결 수신 서버를 거친 뒤 Kafka 를 거쳐서, 다시 매매 서버로 유입되어 처리가 마무리된다.

동시 다발적으로 발생하는 트랜잭션에서 고객 자산에 대한 동시성 처리하기

토스증권에서는 WTS, MTS, 자동 매매등 다양한 방법을 통해 고객의 잔고를 동시에 갱신하는 트랜잭션이 발생하게 된다. 즉, 고객의 잔고 갱신에 한 동시성 처리가 필요하다. 이 방법들을 통해 유입된 요청은 매매 서버로 전달되고, 브로커에게 전달된다. (앞선 (1) 트랜잭션이다.)

이는 어떻게 해결할 수 있을까? (1) 무턱대고 대상 테이블에 대해 하나하나 모두 FOR UPDATE 로 락을 걸어버린다면 데드락을 피할 수 없다. (2) 이를 위해 락을 위한 테이블(계좌락 테이블) 을 별도로 두고, 아래처럼 FOR UPDATE 를 걸어서 동시성을 제어해볼 수 있다.

BEGIN TRANSACTION

SELECT *
FROM account_lock
WHERE account_number = "1911234"
FOR UPDATE;

// ... (비즈니스 로직상에 존재하는 쿼리 실행)

END TRANSACTION;

하지만 이 방식은 단일 데이터베이스 환경에서만 적용할 수 있다. MSA 환경에서 각 마이크로 서버(모듈)는 서로가 각기 다른 독립적인 데이터베이스를 바라보고, 사용한다. 즉, 각 모듈은 서로 락을 공유하지 않는다. 게다가 각 모듈이 바라보는 서버 내에서도 데이터베이스 다중화까지 발생할 수도 있다.

Redis 분산 락을 사용한 동시성 해결

이는 Redis 분산 락으로 해결할 수 있다. 분산 락을 통해 모든 서버는 락을 중앙화된 Redis 서버로부터 공유하고, 제어한다. 또한 분산 락은 여러 서버들에서 모두 요청하기 때문에 높은 처리량(throughput) 이 보장되어야 한다. Redis 는 메모리 기반 저장소이므로 DBMS 에서 계좌락을 별도로 사용하는 방식보다 높은 처리량을 제공한다.

분산 락 타임아웃 설정과 그에 따른 갱실문제

하지만, 분산 락을 사용하면 임계영역에 하나의 쓰레드만 진입할 수 있다. 이 때문에 하나의 트랜잭션이 무한정 락을 소유한다면 다른 서버들의 요청이 무한정 대기하여 데드락이 발생한다. 이 때문에 분산 락의 타임아웃을 설정하여 문제를 해결해보고 싶지만, 아쉽게도 분산 락 타임아웃은 의도대로 동작하지 않을 수 있다.

분산 락 타임아웃이 지나서 락 자체를 해제가 되었으나, 트랜잭션은 아직 끝나지 않는 상태라서 다른 트랜잭션과의 경합이 발생할 수 있다. 즉, 갱신 분실 문제(Lost Updates Problem) 가 발생할 수 있다.

갱실 분실 문제 (Lost Updates Problem)

이와 관련한 유사한 문제는 JPA 낙관적 락과 비관적 락으로 엔티티에 대한 동시성 이슈 해결하기 에서도 동일하게 다룬적이 있다. 토스증권 또한 송금 관련 트랜잭션에서 갱실 분실 문제가 발생한 듯 하다.

통장에 3000원이 있는 상황이다. 트랜잭션1 과 트랜잭션2 는 서로 다른 서버에서 시작되었고, 트랜잭션1이 먼저 실행되어 분산 락을 획득(acquire) 한 상태이다. Redis 분산 락의 타임아웃은 2초 설정했다 가정해보자.

그런데 만약, 트랜잭션1 에 지연이 발생하여 2초 넘게 UPDATE 와 COMMIT 을 하지 못한 상태로 타임아웃되면 어떻게 될까? 우선 트랜잭션 1은 락을 해제하고, 그 즉시 트랜잭션 2가 락을 획득한다. 이때, 트랜잭션 1은 아직 커밋을 하지 못한 상태이므로 통장의 잔고를 업데이트하지 못했다. 이 타이밍에 트랜잭션 2가 통장 잔고를 데이터베이스로 부터 조회해버리게 되므로, 트랜잭션 2의 입장에서는 잔고를 0원이 아니라 3000원으로 읽어오게 된다.

그 뒤로, 뒤늦게 트랜잭션 1이 잔고를 갱신하고 커밋했다. 이 때문에 데이터베이스내에 잔고는 0원으로 갱신된다. 그러나, 곧 이어서 트랜잭션 2가 이 또한 커밋되어 잔고가 -1000원 (엄밀히는 -1000이 아니라, 이때 애러 핸들링을 하긴 했을 것이다.) 이 아니라 2000원으로 갱신해버린다. 즉, 트랜잭션1의 갱신 내역을 덮어씌워버린다.

이렇듯 분산 락 메커니즘을 사용하였음에도 불구학, 갱신 분실 문제가 발생했다. 이처럼 분산 락이 있음에도 락이 발생하는 경우는 언제일까? (1) 분산 락을 해제하기 전에 DB 트랜잭션이 커밋되거나, (2) 분산 락을 해제하고나서 커밋 되는 경우에 발생하게 된다. (위 경우는 2번에 해당할 것이다.) JPA 를 사용한다면 쿼리를 영속성 컨텍스트에 저장해 놓았다가 지연 쓰기 하므로, 이 문제가 발생할 확률이 더 높아진다.

해결안

겡신 분실 문제를 어떻게 해결할 수 있을까? 그 해결안은 아래와 같을 것이다.

(1) 명시적 잠금 (FOR UPDATE 절)
(2) 원자적 연산 사용 (atomic 하게 연산 처리. mutex, sempahore 등)
(3) 갱신 손실 자동 감지 (낙관적 락 기반 Version 관리와 유사)
(4) CAS(Compare-And-Set) 연산

각 메커니즘에 대한 추가적인 이해가 필요하다. (각 기법이 정확히 무엇을 말하는 것인가?)

그런데, 명시적 잠금의 경우 앞서 살펴본 것 처럼 여러 테이블을 갱신하는 트랜잭션에서 비용이 매우 비싸다. 한편 원자적 연산 과 갱신 손실 자동 감지 기법의 경우는 DBMS 에 의존적이기 때문에 ORM 과 호환성이 좋지 않다고 한다.

낙관적 락을 사용한 동시성 해결

토스 증권은 CAS 연산 구현을 택하였다. JPA 에서 제공하는 @OptimisticLocking 을 사용해, 즉 낙관적 락을 사용하여 간단히 CAS 연산 구현이 가능하다.

그렇다면, 분산 락 없이 낙관적 락 만으로도 동시성 해결이 가능하지 않을까? 싶다. 하지만, 분산 락이 업다면 동시적으로 발생하는 트랜잭션들은 대기 없이 실패하게 된다. 또는 갱신 실패시 재시도를 위한 별도의 재시도(Retryable) 구현이 필요하다. 재시도 구현은 JPA 낙관적 락과 비관적 락으로 엔티티에 대한 동시성 이슈 해결하기 에서도 다루었듯이 좋은 방법이 아니고, 코드의 복잡성이 증가한다.

따라서 토스증권은 분산 락으로 동시성을 제어하고, 만약의 상황을 대비하여 낙관적 락을 통해 갱신 분실 문제를 해결하였다.

해외구간 네트워크 지연으로부터 안전하게 서비스하기

앞서 살펴보았듯이, 매매 요청 서버는 브로커와 통신하고 있다. 이때, 브로커와 매매 요청 서버가 통신하는 이 구간은 해외 망으로써 네트워크 지연이 빈번히 발생한다. 이를 위해, 토스 증권에서는 고객의 요청을 받는 매매 서버와, 브로커에게 요청하는 쓰레드를 분리하여 모든 쓰레드가 Blocking 되는 이슈를 해결하였다. (즉, 브로커 요청과 관련없는 쓰레드들까지 모두 Blocking 되는 상황을 막은 듯 하다.)

브로커의 응답을 받지 못한 상태에서 타임아웃 되버린 경우

하지만, 매매 서버와 브로커가 통신하는 구간은 여전히 네트워크 지연이 발생한다. 따라서 하나의 API 에서 동기로 처리할 경우 상황에 따라 고객은 이 주문 응답을 기다리느라 다른 서비스를 이용할 수 없게 된다.

토스증권은 이 구간을 비동기로 처리하여 고객 경험을 상승시키고, 트랜잭션 시간을 최소화하고 있다. 브로커 요청이 실패할 수도 있기 때문에, 브로커 요청 이전에 주문을 반드시 대기상태로 저장해야 한다. 대기상태의 주문은 브로커의 응답 결과에 따라 접수 성공/실패로 주문 상태를 갱신하게 된다.

그런데 만약, 매매 서버와 브로커간에 TCP 기반으로 통신하는 이상 타임아웃이 발생한다면 어떻게 처리해야 할까? 브로커의 응답을 받지 못한체 타임아웃 되버렸기 때문에 해당 주문 상태를 임의로 우리가 판단할 수 없게 된다. (타임아웃 되버렸다고 무식하게 주문 상태를 완료 처리로 바꿔버린다면 문제가 된다. 네트워크 지연으로 인해 타임아웃 되었지만, 실제 브로커에서는 주문을 정상 처리했을 수 있기 때문이다.)

또한 브로커 측의 식별자를 전달받지도 못한 상태이므로 주문 상태를 조회할 수도 없다. 토스증권은 이렇듯 브로커와의 통신에서 타임아웃되어 주문 상태를 처리하지 못하는 주문들을 재시도 대상으로 판단한다. 재시도에서 발생할 수 있는 문제들을 간단히 살펴보고, 이를 어떻게 해결했는지 알아보자.

멱등한 API 요청을 통해 안전하게 처리하기

사용자가 1번 주문을 요청하였다. 이에 따라 매매 서버는 브로커와 통신하여 주문 요청을 한다. 이때 네트워크 지연 문제로 인해 타임아웃 되었지만, 브로커 서버에서는 주문이 정상적으로 처리 되었고 주문 데이터도 1번으로 잘 생성되었다고 해보자. 이 상황에서 재시도 요청을 하였다면, 브로커는 1번 주문에 대해 2개의 주문을 생성해버린다. 즉, 토스증권의 주문과 브로커의 주문 데이터간의 정합성이 깨진다.

이는 멱등한 API 요청을 통해 해결했다. 멱등성은 같은 요청에 대해 항상 같은 값을 유지하는 성질로, 여러번 요청하더라도 항상 같은 결과를 반환한다. 멱등성을 위해 토스증권은 토스 주문 ID 를 멱등키로 보내어, 하나의 토스 주문 ID 에는 하나의 브로커 주문한 생성하도록 보장하였다.

네트워크 병목이 발생하지 않기 위한 재시도 전략

이렇게 주문 요청에 대한 멱등성을 확보했다. 그러면 이제 성공할 때 까지 주문 요청을 계속 재시도하면 끝날까?

타임아웃의 특성상, 짧은 주기로 재요청을 하게 된다면 네트워크 지연 상황을 더욱 악화시킬 수 있다. (되려 네트워크 병목을 불러일으키는 셈이다.) 네트워크 지연으로 인해 더 빈번한 타임아웃이 발생하게 되는 악순환의 고리로 이어지는 셈이다.

따라서 토스증권에서는 일정 횟수로 재시도를 제한하고, 지수적으로 간격을 두어 재시도하는 전략을 사용하고 있다. 예를들면 1분에 한번, 그리고 2분, 4분, 8분에 한 번식 재시도 요청을 보내는 것이다.

혹시라도 주문 및 체결 정합성이 깨지는 경우가 발생하면 대사 배치에서 잡히게 되고, 이는 별도의 오퍼레이션에 의해 처리할 수 있도록 장치가 준비되어 있다. 그리고 토스증권내의 모든 데이터 정합성은 채결 내역에서부터 시작하기 때문에, 토스증권내의 정합성이 틀어지는 일을 절대 발생하지 않는다.

이렇게 되면 해외 구간 요청은 안전하게 처리되었다.

브로커 의존성 격리하기

브로커는 외부 기관이므로, 비즈니스 로직이 언제든 추가되고 변경될 수 있다. 별도의 처리가 없는 위에서 본 구조라면, 새로운 브로커가 추가되면 네트워크 프로토콜부터 인터페이스까지 매매 서버가 새로운 브로커에 맞추게 되며 변경에 같이 가해진다. 또한 매매 서버 처리량이 브로커의 처리량과 강하게 결합되어 있다. (브로커가 문제가 발생하면 매매 서버도 영향을 받는다.)

이를 위해, 토스증권은 브로커 의존성을 가장 강한 격리 수준인 서버 레벨에서 격리시키고 있다. (기존에는 매매 서버가 직접 브로커와 통신했는데, 매매 서버와 브로커 사이에 매매 요청 서버를 증설했다는 뜻인듯 하다.) 즉, 브로커가 전문 통신을 지원하던, HTTP 등 어떤 스팩을 지원하던간에 상관없이 매매 서버는 영향을 받지 않도록 내부 인터페이스만 맞추면 되도록 했다.

앞서 살펴본 타임아웃 주문 처리 역시 대표적인 브로커 인터페이스 의존 요소이다. 토스증권 식별자로 상태를 조회할 수 있게 제공해주는 브로커가 추가된다면, 전혀 다른 방식의 타임아웃 주문 처리를 도메인 로직과는 무관하게 확장 가능하다.

또한 브로커 처리량에 따라서 매매 요청 서버를 Scale Out 하여 효율적인 리소스 사용이 가능해지고, 브로커 장애가 토스 증권 서비스 전체로부터 격리 가능한 구조로 개선되었다.

위의 주문 체결 플로우를 보면, 매매 요청과 체결 수신 서버를 중간에 배치하여 매매 서버를 브로커와의 결합성을 낮추었다.

브로커 의존성을 격리함으로써 채결 수신 처리 서버 또한 강력한 장점들이 생겨난다. 채결 수신 서버는 브로커의 이벤트를 받아 데이터베이스에 적재하고, Kafka 로 매매 서버에게 발송한다. 이로써 매매 서버가 매우 바쁜 상황이더라도 브로커의 이벤트를 수신하지 못하는 상황을 방지할 수 있다.

또한 카프카에 이벤트를 업로드하기 전에 브로커 수신 내역을 데이터베이스에 적재하고 있기 때문에, 카프카 서버가 다운되더라도 폴링 모드로 전환하는 등 다양한 Fail Over 전략이 메시지 유실 없이 처리 가능해진다.

또한 중복 이벤트 역시 브로커 인터페이스와 무관하게 처리 가능해진다. 중복 처리는 이벤트를 발행할 때 Unique 한 ID 를 발급하여 처리가 가능하다. 브로커 파트너가 여러개라면, 각 파트너끼리 ID 가 경합될 수도 있다. 하지만 이 역할을 체결 수신 서버가 여러개의 브로커 파트너에 대해서도 중복 없이 전역적인 Unique 한 ID 발급이 가능해진다.

마치며

이렇게 토스증권이 어떻게 해외까지 이어지는 트랜잭션을 안전하게 처리하는지 알아보았고, MSA 의 특성을 이용해 확장 가능한 원장을 만들었는지 알아보았다.

더 학습해볼 질문 주제

모행 서비스가 분산 환경, 데이터베이스 Source 서버가 다중화되는 경우의 동시성 처리 방법
지난 [가상 면접 사례로 배우는 대규모 시스템 설계 기초] 제 10장. 알림 시스템 설계 에서 등장한 내용과 연관지어 생각하기. 왜 카프카를 쓰는가? 왜 수신 내역을 데이터베이스에 저장하도록 구성했는가?

LazyConnectionDataSourceProxy 의 커넥션 획득 지연 방법

Tue, 17 Dec 2024 00:00:00 GMT

MySQL 8.0 레플리케이션과 스프링부트 DataSource 라우팅을 통한 부하 분산 에서도 다루었듯이, 우리 서비스는 레플리케이션을 위해 LazyConnectionDataSourceProxy 를 사용한다. 이에 대한 학습을 더 자세히 진행해볼까 한다.

LazyConnectionDataSourceProxy

스프링은 어떤 시점에 DataSource 로 부터 커넥션을 가져올까? 결론부터 말하면, 스프링에서는 트랜잭션에 진입하는 순간 그 즉시 설정된 DataSource 의 커넥션을 가져온다. 그런데, 이 특징 때문에 발생할 수 있는 문제점은 다음과 같다.

Encache 같은 Cache 를 사용하는 경우 실제로 데이터베이스에 접근하지 않지만 불필요하게 커넥션을 점유
Hibernate 의 영속성 컨텍스트 1차 캐시 (실제 데이터베이스에 접근하지 않음) 에도 불필요한 커넥션을 점유
외부 서비스 (http, etc ...) 에 접근해서 작업을 수행한 이후에 그 결과값을 데이터베이스에 Read/Write 하는 경ㅂ우 외부 서비스에 의존하는 시간만큼 불필요한 커넥션 점유
Multi DataSource 환경에서 트랜잭션에 진입한 이후 DataSource 를 결정해야할 때 이미 트랜잭션 진입 시점에 DataSource 가 결정되므로 분기가 불가능

위 단점들을 해결할 수 있는 방법이 바로 LazyConnectionDataSourceProxy 이다. 이를 사용하면 실제로 커넥션이 필요한 경우가 아니라면 커넥션 풀에서 커넥션을 점유하지 않고, 실제로 필요한 시점에만 커넥션을 점유할 수 있다.

사용에 따른 차이 확인

아래 예제를 살펴보쟈.lazy() 메소드는 DBCP 의 DataSource 타입에 따라 분기처리를 한다. 실제 데이터베이스에 쿼리를 날리지 않고, 커넥션 수의 변화를 확인하는 코드이다. 여기서 중요한 점은, 실제로 데이터베이스와 통신하는 부분이 없다는 점이다.

@Transactional
@Service
public class LazyService {
    private final DataSource dataSource;

    public void lazy() {
        HikariPoolMXBean hikariPool;

        if(datasource instanceof LazyConnectionDataSourceProxy) {
            hikariPool = ((HikariDataSource) (LazyConnectionDataSourceProxy) dataSource).getTargetDataSource()).getHikariPoolMXBean();
        } else {
            hikariPool = ((HikariDataSource) dataSource).getHikariPoolMXBean();
        }

        log.info("TotalConnection = {}", hikariPool.getTotalConnections());
        log.info("ActiveConnection = {}", hikariPool.getActiveConnections());
        log.info("IdleConnection = {}", hikariPool.getIdleConnections());
    }
}

LazyProxy 는 LazyConnectionDataSourcePrroxy 를 빈으로 등록하는 코드이다. LazyProxy 를 통해 프록시를 사용했을 때와 사용하지 않았을 때 어떻게 커넥션이 변경되는지 확인해보자.

@Component
public class LazyProxy {

    @Bean
    public DataSource lazyDataSource(final DataSourceProperties dataSourceProperties) {
        final HikariConfig hikariConfig = new HikariConfig();

        hikariConfig.setJdbcUrl(dataSourceProperties.getUrl());
        hikariConfig.setDriverClassName(dataSourceProperties.getDriverClassName());
        hikariConfig.setUsername(dataSourceProperties.getUsername());
        hikariConfig.setPassword(dataSourceProperties.getPassword());

        return new LazyConnectionDataSourceProxy(new HikarDataSource(hikariConfig));
    }
}

LazyConnectionDataSourceProxy 를 사용하지 않았을 때의 결과는 아래와 같다. 데이터베이스에 쿼리를 날리지 않고, 아무런 작업을 하지 않았음에도 커넥션을 불필요하게 사용하게 된다.

반대로 LazyConnectionDataSourceProxy 를 사용한 결과는 아래와 같다. LazyConnectionDataSourceProxy 를 사용하면 커넥션이 꼭 필요한 시점이 되기 전까지 커넥션을 가져오지 않는 모습을 확인할 수 있다.

커넥션을 가져오는 시점

LazyConnectionDataSourceProxy 를 사용하지 않는다면, @Transcational 을 만나는 그 즉시 설정된 DataSource 에 대한 커넥션을 획득하게 된다. 그렇다면 트랜잭션이 시작되고 정확히 어떤 시점에서 커넥션을 획득하는 것일까?

트랜잭션을 보통 위와 같이 동작한다. 트랜잭션이 적용되어 있는 객체의 CGLIB 프록시가 호출이 되면 트랜잭션이 시작된다. 그 후 트랜잭션의 커밋이나 롤백등을 관리하는 TransactionManager 의 인터페이스를 가져오고, 설정된 DataSource 를 바탕으로 커넥션을 생성한다. 그러고 난 뒤에서야 뒤 늦게 TransactionSynchornizationManager 를 통해 트랜잭션을 유지할 수 있게 같은 커넥션을 사용하도록 보장한다. TransactionSynchornizationManager 와 관련한 자세한 내용은 스프링 트랜잭션 동기화와 추상화 (feat. TransactionManager) 에서 다룬적이 있다.

즉, TransactionSynchornizationManager 가 DataSource 정보를 읽어오는 시점은 이미 DataSource 가 결정되고 커넥션까지 모두 생성된 뒤에서야 그 정보를 읽어오게 된다. 그런데, 만약 LazyConnectionDataSourceProxy 를 사용하면 데이터베이스를 접근하기 전 (쿼리를 날리기 직전) 타이밍이 되었을 때 커넥션을 가지고 오게 된다. 앞서 설명했듯이, LazyConnectionDataSourceProxy 를 사용하면 실제로 데이터베이스와 쿼리를 주고받고 통신하며 커넥션을 획득해야 하는 시점까지 커넥션 획득을 지연시킬 수 있기 때문이다.

Multi DataSource 환경에서 LazyConnectionDataSourceProxy 의 역할

이전 포스팅에서 다루었듯이, 데이터베이스 레플리케이션 환경에서 원활한 라우팅을 위해 AbstractRoutingDataSource 를 사용하고 있다. 여기서 determineCurrentLookupKey() 메소드를 사용해서 DataSource 를 찾는다. 그렇다면, LazyConnectionDataSourceProxy 를 설정안하고 AbstractRoutingDataSource 만 사용해서 분기를 할 수 있을 것 같지만, 그렇지 않다.

//  AbstractRoutingDataSource : Multi DataSource 환경에서 여러 DataSource 를 묶고 분기해줄 때 사용한다.
public class RoutingDataSource extends AbstractRoutingDataSource {
    // determineCurrentLookupKey 메소드 : 여러 datasource 중에서 실제로 사용될 DataSource 를 결정하는 역할
    // 현재 트랜잭션의 속성에 따라 targetDataSourceMap 의 조회 Key 를 결정하기위해 AbstractRoutingDataSource 를 상속받아서 determineCurrentLookupKey 를 구현했다.
    @Override
    protected Object determineCurrentLookupKey() {
        boolean isReadOnly = TransactionSynchronizationManager.isCurrentTransactionReadOnly();
        logger.info("현재 트랜잭션 속성이 ReadOnly인가?:" + isReadOnly);
        return isReadOnly ? "slave" : "master";
    }
}

내부적으로 TransactionSynchornizationManager 를 통해서 트랜잭션의 Read Only 여부를 확인하고 있다. 그런데 앞서 학습했듯이, 스프링은 기본적으로 커넥션을 TransactionManager 에서 TransactionSynchornizationManager 으로 넘어갈 때 가져온다. 따라서 LazyConnectionDataSourceProxy 를 사용하지 않고서는 Read Only 여부에 따라 다른 DataSource 를 선택할 수 없게 된다.

결론적으로, LazyConnectionDataSourceProxy 통해 커넥션을 획득하는 시점을 실제 데이터베이스와 쿼리로 통신하는 시점으로 미루기 때문에, TransactionSynchornizationManager 를 통해 트랜잭션 Read Only 여부를 파악해 알맞은 DataSource 로 라우팅 해줄 수 있다.

참고

Redis가 제공하는 RedLock 알고리즘 간단히 살펴보기

Thu, 12 Dec 2024 00:00:00 GMT

지난 Redis 분산 락(Distribution Lock)을 구현하여 동시성 해결하기 에서 다루었듯이, Redis 는 모니터(monitor) 기반의 상호 배제(mutual exclusion) 기법인 분산 락(Distribution Lock) 을 제공한다. 이 분산 락은 RedLock 알고리즘에 기반하여 구현되어있다. 이 RedLock 알고리즘은 어떠한 방식으로 동작할까? 이를 간단히 학습해보도록 한다.

Redis SET NX

RedLock 은 분산 환경에서 Redis 가 권장하는 락을 제공하는 방법이다. Redis SET 명령어에 NX 옵션을 통한 락을 제공하는 방법과 한계, RedLock 의 특징과 한계에 대해 알아보자.

SET key value NX PX 30000
// key, value 를 저장하는데 Not Exists 일 경우에만 저장하고, 30초(30,000ms) 동안 유지해줘

Redis 2.6.12 버전 이전에는 SETNX 명령어가 제공되었지만, 2.6.12 버전 이후 부터는 SETNX 명령어는 deprecated 되었고, SET 명령어에 NX 옵션을 전달하는 방향으로 수정했다. NX 옵션을 전달하면 SET 하려는 key 가 없는 경우에만 SET 이 성공한다. Redis 는 싱글 쓰레드로 동작하기 때문에 여러 프로세스가 공유 자원에 접근할 때 발생하는 동시성 문제를 이 명령어로 해결할 수 있다.

즉, 먼저 접근한 쓰레드가 NX 옵션을 전달한 SET 에 성공한다면 다른 쓰레드들은 대기한다. 여기서 다른 쓰레드들이 대기하도록 while 과 같은 루프와 sleep 같은 함수는 개발자가 직접 제공해야 한다. 그리고 락을 획득해 먼저 자원을 선점한 쓰레드는 작업을 끝낸 후 key 를 제거한다.

DEL key

여기서 단순히 DEL 명령어로 key 를 삭제하면, 락을 획득하지 않은 다른 클라이언트들도 삭제가 가능하다. 따라서 key 가 존재하고 값이 일치할 때만 삭제할 수 있도록 아래처럼 Lua 스크립트를 통해 삭제할 것을 권장한다.

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

여기서 문제점은, Redis 가 단일 서버 1대로 동작하면 SPOF 가 된다는 점이다. 이를 위해 Master-Slave 레플리케이션 구조를 도입할 경우, 복제구조가 비동기 방식이기 때문에 Lock 데이터에 대한 정합성 문제(경쟁 상태)가 발생할 수 있다.

RedLock

RedLock 은 N대의 Redis 서버가 있다고 가정할 때, 과반 수 이상의 노드에서 락을 획득했다만 락을 획득한 것으로 간주한다. RedLock 알고리즘 동작은 간단히 설명하면, 아래처럼 동작한다.

(1) 클라이언트가 락을 획득하기 위해 모든 Redis 서버에게 락을 요청한다. 과반 수 이상의 Redis 서버에게 락을 획득하면 락을 획득하게 된다.
(2) 과반수 이상의 락 획득에 실패했다면, 모든 Redis 서버에게 락 해제를 요청하고 일정 시간 후에 락을 획득하기 위해 재시도한다.

RedLock 은 완벽하지 않다.

RedLock 알고리즘 또한 문제가 발생할 수 있다. 아래 코드는 락을 획득 후 파일에 데이터를 저장하는 코드이다.

// THIS CODE IS BROKEN
function writeData(filename, data) {
  var lock = lockService.acquireLock(filename);
  if (!lock) {
    throw 'Failed to acquire lock';
  }

  try {
    var file = storage.readFile(filename);
    var updated = updateContents(file, data);
    storage.writeFile(filename, updated);
  } finally {
    lock.release();
  }
}

위 코드에서 어떻게 문제가 발생할 수 있을까?

클라이언트 A 가 마스터 서버에서 락을 획득한다.
클라이언트 A 에서 Stop-The-World GC 로 인해 애플리케이션 코드 중지가 발생하고, 그 사이에 락이 만료된다.
클라이언트 B 가 분산 락을 획득하고 파일에 데이터를 쓴다.
클라이언트 A 가 GC 가 끝난 후 파일에 데이터를 쓰면서 동시성 문제가 발생한다.

글로벌 트랜잭션에 대한 이론은 글로벌 트랜잭션 (feat. GTID) 에서 다룬적이 있으니, 참고하자. 일반적으로 글로벌 트랜잭션은 매우 빠르게 수행되지만, Stop-the-World 글로벌 트랜잭션은 드물게 락이 만료될 정도로 지속될 수 있다. GC 말고도 네트워크 지연이나 Timing 이슈에 따라 RedLock 이 깨질 수 있음을 유의하자.

RedLock은 Redis가 공식적으로 권장하고 있는 분산 락 알고리즘이다. 이 방법을 사용해 공유 자원에 대한 동시성 문제를 해결할 수 있다. 다만 발생할 확률이 낮기는 하지만 RedLock도 완벽하지 않다는 것은 이해하고 있어야 한다.

참고

토스 SLASH 23, 은행 최초 코어뱅킹 MSA 전환기(feat. 지금 이자 받기)

Wed, 11 Dec 2024 00:00:00 GMT

💡 현재 포스팅은 토스 SLASH 23, 코어뱅킹 MSA 전환기 를 듣고 정리한 내용이다.

토스뱅크는 기존의 코어뱅킹 서비스를 고객 중심으로 변화시키기 위해, 금융의 혁신을 위해 많은 노력을 기울이고 있다. 그런데, 문제가 있다. 기존의 전통적인 뱅킹 시스템을 구현하는 방식으로는 안정적인 고객 중심 뱅킹 서비스에 한계가 있었다. 토스뱅크는 어떤 기술로 고객 중심의 뱅킹 서비스를 제공할 수 있었을까?

전통적인 금융 시스템

채널계와 코어뱅킹(계정계)

일반적인 금융권 시스템은, 특히 코어뱅킹 서버는 매우 거대한 모놀리식 아키텍처로 구성되어 있다. 은행에는 크게 고객의 요청을 코어뱅킹 서버로 전달하는 채널계와, 금원과 관련된 메인 비즈니스 로직을 처리하는 코어뱅킹(계정계) 라고 하는 2개의 서버를 중심으로 아키텍처가 구성되어있다.

코어뱅킹 시스템 아키텍처 역사

코어뱅킹 시스템은 왜 거대한 모놀리식 아키텍처를 유지해왔을까? 이 이유는 금융 시스템의 변천사를 이애하면 그 정답을 알 수 있다.

1970년대부터 은행의 계좌 데이터를 적절하게 가공하고 처리해야 하는 니즈가 생기면서, 1세대와 2세대 코어뱅킹 아키텍처가 생겨났고, 2000년대에 디지털 붐이 일면서 모바일 뱅킹, 웹 뱅킹, 텔레뱅킹 등 다양한 거래 요청을 한 곳에서 적절하게 처리해줄 수 있도록 현재의 모놀리식 코어뱅킹 아키텍처가 생겨나게 되었다.

지난 20여년간 코어뱅킹 아키텍처는 운영체제와 개발 언어의 크고 작은 변화는 있었지만, 현재의 모바일 트렌드와는 맞지 않는 20년전의 모놀리식 아키텍처를 대부분의 은행에서 사용한다. MSA 의 구조를 취하지 않고, 현재의 거대한 모놀리식 형태로 몸집을 더 키워나가고 있었다.

현재 토스뱅크의 채널계는 기존 토스 전반 생태계의 DNA를 이어받아 모두 MSA 환경으로 구성되어 있다. 하지만, 기존의 토스 코어뱅킹 시스템은 여타 은행과 다름없이 채널계와의 통신을 위한 모놀리식 시스템으로 구성되어 있었다. 기존의 토스 코어뱅킹 시스템은 Redis, Kafka 등의 모던한 기술을 사용하고는 있었지만, 여타 은행과 다름없이 채널계와의 통신을 위한 MCI, 대외연계를 위한 FEP, 대내 단위 시스템과의 연계를 위한 EAI 가 코어뱅킹 서버에 강하게 결합되어 있는 구조를 취하고 있었다.

💡 용어 정리

MCI(Message Channel Interface) : 시스템 간의 데이터 교환을 위해 사용하는 메시지 기반 통신 인터페이스

FEP(Front-end Processor) : 메인 시스템 앞단에서 데이터 통신을 처리하는 전처리 장치 또는 프로세서

EAI(Enterprise Application Integration) : 조직 내 여러 이기종 애플리케이션간의 통합 및 데이터 교환을 가능하게 하는 소프트웨어 아키텍처

모놀리식 아키텍처의 한계. MSA 로의 전환

토스 코어뱅킹 시스템은 과거의 모놀리식 아키텍처를 금융권 최초로 MSA로 전환하였다. 모놀리식 코어뱅킹 아키텍처는 어떤 한게가 있었기에 MSA 로 전환을 했을까?

모놀리식 아키텍처도 몰론 장점이 있긴하다. 로컬 트랜잭션으로 하위 도메인 데이터를 ACID 하게 변경할 수 있고, 개발하게도 쉽다는 점이다. 하지만, SPOF(Single Point Of Failure) 에 취약하다. 모놀리식으로 구성된 코어뱅킹 시스템에 트래픽이 몰린다면, 특정 코어뱅킹 시스템만 스케일 아웃하는 전략을 취할 수 없다.

토스뱅크는 대량 트래픽에 특화되어 있고, 각 업무별 서비스 영향도를 분리할 수 있는 MSA로 전환하기로 했다. 그 중에서도 토스뱅크 서비스 중 가장 트래픽이 많은 이자 받기 서비스를 모놀리식 코어뱅킹 시스템에서 분리하여 MSA로 전환하기로 했다. 지금부터 토스뱅크가 이자 받기 서비스를 어떻게 MSA 로 전환했는지에 대해 알아보자.

기술 스택

MSA 로의 전환을 위해, 토스뱅크 채널계에서 사용하는 기술들을 대부분 채택했다. 쿠버네티스위에 스프링부트, 코틀린, JPA 등을 기반으로 개발했고, 비동기 메시지 처리와 캐싱은 Kafka, Redis 를 사용하기로 결정했다.

"지금 이자 받기" 기능 AS-IS 흐름

MSA 아키텍처 구조

우선, 토스뱅크가 MSA 구조를 어떻게 구성했는지 전반 아키텍처 플로우에 대해 알아보자. 토스뱅크는 MSA 전환을 시작하자마자 첫 번째 고민에 봉착했다. 현재 모놀리식으로 강하게 결합된 업무별 비즈니스 의존성을 어느 정도까지 느슨하게 가져갈 것인가이다. 지금 이자 받기 서비스를 위해 필요한 도메인은 (1) 고객 정보 조회, (2) 금리조회 및 이자계산, 그리고 (3) 이자의 회계 처리를 위한 회계 정보 조회 및 처리. 이 모든것을 하나의 마이크로 서버에서 처리하는 것은 MSA의 장점을 활용하지 못할 것이라 판단하여, 도메인 단위로 서비스를 나누기로 결정했다.

과거의 고객의 지금 이자 받기 요청은 고객 정보 조회를 거쳐, 금리 조회와 이자계산, 이자 송금, 회계처리를 1개의 트랜잭션으로 처리하고 있었다. MSA 로 전환한 새로운 코어뱅킹 아키텍처에서는, 트랜잭션으로 엮이지 않아도 되는 도메인은 별도의 마이크로 서버로 구성했다. 그리고 각 서버의 API 호출을 통해 비즈니스 의존성을 느슨하게 가져가도록 구성했다.

💡 아키텍처를 보면서 궁금한점은, 각 마이크로 서버간의 데이터베이스는 어떻게 구성되어있고, 공유하는가이다. 정확한 구현 방식은 안그래도 조만간 토스뱅크 면접이 잡혀있으니, 한번 어쭤봐야겠다 😎

동시성 제어

은행 시스템의 안정성과 직결되는 부분은 동시성 처리이다. 토스뱅크 또한 동시성 처리를 위해 많은 고민이 있었다.

💡 이와 거의 똑같은 동시성 처리에 관하여 JPA 낙관적 락과 비관적 락으로 엔티티에 대한 동시성 이슈 해결하기 에서 다룬적이 있다. 이를 참고하자.

동시성 문제가 터지는 상황을 하나 가정해보자. 현재 사용자 계좌에 남은 잔액은 100원이다. 그리고 트랜잭션 1은 "100원 지금 이자 받기" 를 처리하며, 트랜잭션 2는 "300원 타행 송금" 을 처리한다.

가장 먼저 트랜잭션1을 통해 이자를 받았고(잔액 100원 감소 로직), 트랜잭션2를 통해 입금을 받았다(잔액 300원 증가 로직)고 가정해본다면, 트랜잭션1은 현재 잔액인 100원에 지금 이자 받기를 수행하여 200원으로 계좌 잔액을 갱신할 것이다.

이렇게 트랜잭션 1이 수행되는 그 사이에 트랜잭션2가 수행된다면? 트랜잭션2는 200원이 아니라 기존 잔액 값인 100원이라는 값을 읽어오고, 300원을 더하여 400원이라는 엉뚱함 금액으로 잔액을 갱신하게 된다. 즉, 데이터 정합성 문제가 발생한다. 토스뱅크는 동시성 처리를 위해 Redis Global Lock 과 JPA 에서 제공하는 락을 사용하여 문제를 해결했다.

다만, 락을 사용할떄는 주의사항이 있다. 락을 꼭 잡아야하는 최소한의 데이터에 대하서만 락을 획득해야 데드락과 성능 저하를 예방할 수 있다는 점이다. 지금 이자 받기 API 의 경우 잔액을 갱신하는 이벤트가 메인 비즈니스 로직이다. 따라서 계좌 단위 현재 잔액 데이터에 대해서만 ROW 단위의 락이 걸리도록 개발하여, 동시성을 처리했다.

또한 트랜잭션 2의 동시성이 발생했을 때, 트랜잭션 1이 끝날 때까지 기다릴 수 있도록 재시도할 수 있는 로직과 적절한 타임아웃을 적용해주었다. 이를 통해 고객은 락이 걸렸는지도 모르게 안정적으로 이자를 받을 수 있게 된다.

💡 추측컨데, 토스뱅크는 이 당시 동시성 처리를 위해 JPA 낙관적 락을 사용하지 않았을까라는 생각이 든다. 우선 낙관적 락은 충돌이 자주 발생하지 않고 락을 거는 방식이다. "지금 이자 받기" 의 기능은 동시성이 아무래도 자주 발생할 경우는 아니다. 또한 재시도 로직은 @Retryable 로 처리할 수 있읉텐데, 비관적 락의 경우 처음부터 충돌을 방지하기 위해 락을 걸어두므로 재시도 로직을 수행할 필요가 없다. 타임아웃의 경우 낙관적 락과 비관적 락 어느 하나에 한정되지 않고 처리할 수 있는 로직이다. 낙관적 락을 활용해 @Retryale 로 재시도 로직을 구현하다 무한 대기에 빠지는 경우를 처리하기 위해 JPA 의 QueryHint 를 사용하지 않았을까? 라는 추측이다. 이 또한 토스뱅크 면접때 가능하다면, 한번 어쭤봐야겠다.

💡 또한 Redis Global Lock 을 사용했다고 하는데, 이는 단일 서버가 아닌 분산 환경에서 흔히 사용되는 락 메커니즘 일 것이다. JPA 락 메커니즘과 Redis 분산락을 어떻게 함께 사용했다는 건지 이 영상만 보고는 이해가 안간다. 이 또한 알아봐야겠다.

💡 나 또한 모행 서비스에서 동시성 처리를 해주었는데, 우리 서비스는 비관적 락으로 처리해두었다. "지금 이자 받기" 와 달리 여행지 조회시 카운팅 로직은 충돌이 자주 발생할 수 밖에 없는 상황이다. 이와 관련한 내용은 이전에 따로 정리해두었다.

성능 개선을 위해, Kafka 를 활용한 비동기 처리

다음으로, 토스뱅크는 Kafka 를 활용하여 비동기 트랜잭션을 구현했다. 기본 코어뱅킹 시스템에서는 1번의 이자를 지급받기 위해, 무려 20개의 테이블에 80번의 UPDATE, INSERT 대량의 쿼리를 날려야하는 복잡한 구조였다.

따라서 지금 이자 받기 서비스의 속도는 평균 300ms 으로, 전체 코어뱅킹 서비스 중에서 정말 느린 편에 속했다. 이렇게 대량의 쿼리가 나가는 상황이라면, 아무리 DB 정규화를 잘 하고, 인덱스로 쿼리 튜닝을 하더라도 매우 빠른 응답속도를 기대하기는 어려울 것이다. 그래서 기존의 지금 이자 받기 기능의 트랜잭션에서 분리가 가능한 테이블은 카프카를 이용해 트랜잭션에서 분리했다.

카프카의 비동기 처리에 대한 추가 학습이 필요하다.

트랜잭션 분리에 대한 기준은 어떻게 했을까? 이는 고객의 잔액과 통장 데이터 관점에서 DB 쓰기 지연이 발생했을 때, 실시간으로 문제가 발생하느냐? 로 접근했다. 또한, 반드시 트랜잭션이 보장되어야 하는 데이터 모델과 즉시성(즉시 처리되지 않아도 되는) 을 요구하지 않는, 즉 세금 처리와 같이 지금 이자 받기 트랜잭션과 묶이지 않아도 되는 데이터 모델의 DML 은 트랜잭션을 분리했다.

더 자세히 알아보자면, 지금 이자 받기 서버에서 지금 이자 받기의 트랜잭션 종료와 동시에 세금 카프카 토픽에 메시지를 Produce 하고, 비동기 처리 서버가 Consume 해서 세금 DB 에 저장하도록 구현했다. 이와 유사한 브로트캐스팅 기법은 Redis Pub/Sub 을 사용한 분산 환경에서 로컬 캐시 동기화 에서 다룬적이 있다. 정상적인 상황이라면, 이자 DB 와 세금 DB 에도 준 실시간으로 업데이트가 되었을 것이기 때문에 지금 이자 받기 거래는 정상적으로 종료될 것이다.

그런데, 카프카 메시지가 정상적으로 처리되지 않는 경우도 있다. 따라서 Dead Letter Queue 를 이용해서 세금 DB 에 대한 트랜잭션을 안정적으로 처리할 수 있도록 보장했다. 또한, 재처리시 중복으로 세금이 업데이트 안 되도록 API 도 멱등하게 설계했다.

이렇듯 토스뱅크는 세금 DML 을 지금 이자 받기 트랜잭션에서 분리함으로써, 기존 80회의 DML 쿼리가 이루어지던 트랜잭션을 50회의 DML 로 줄이는 개선 효과를 얻어내었다.

Redis 를 활용한 캐싱 전략

기존 코어뱅킹 시스템에서의 이자 계산은 RDB 기반의 일자별 거래내역 DB 를 조회해서 연산하는 방식으로 구현되어있었다.

고객이 지금 이자 받기를 할 때마다, 계좌의 매일 매일 거래내역을 데이터베이스로 부터 조회해서 이자 계산과 세금을 계산하는 구조였다. 그 때문에 성능적으로 오래 걸릴 수 밖에 없는 구조였다. 그러나 고객은 하루에 1번밖에 이자를 못 받기 때문에 Redis 를 활용하면, 하루에 1번만 DB I/O 를 발생시킬 수 있을 것이라 판단해서 Redis 를 이용해 캐시를 활용하기로 했다.

기존의 이자 금액은 고객이 계좌 상세탭에 접근할 때 마다, 이자계산을 위한 DB I/O 가 발생하고 있었다. 이를 고객이 하루 중 처음으로 계좌 상세탭에 접근할 때만 DB 에 접근하도록 구현했고, 이자예상조회의 결과를 Redis 에 캐싱해 두도록 구현했다.

그래서 고객이 하루에 2번이상 계좌 상세탭에 접근할 경우에는 Redis 에 미리 저장되어있던 이자계산 결과를 리턴하도록 했다. 그래서 불필요하게 DB 리소스가 낭비되는 것을 방지했다. 또한, Redis 에 캐싱된 이자 데이터의 만료일자도 하루로 두어서, 이자금액이 잘못 계산되는 오류 케이스도 원천적으로 방지했다. 그래서 매일 자정 이후 고객이 계좌 상세탭에 처음 접근할 때만, 이자 에상 조회의 결과를 캐싱해서 이자 데이터의 정합성을 보장할 수 있게 되었다.

기존 모놀리식 아키텍처를 MSA 로 안전하게 마이그레이션 하는 방법 (API 검증)

위와 같은 과정을 통해, 토스뱅크는 이자 지급 마이크로 서버에 이자 조회 거래, 지금 이자 받기 거래 개발을 마쳤다. 그렇다면 이제, 기존 코어뱅킹(계정계) 를 참조하던 서비스를 이자 지급 마이크로 서버를 바라보도록 라우팅 환경을 전환해야 할 것이다.

그런데, 이 라우팅 환경을 재구축하기 위한 선수 과정이 필요했다. 이자 지급 마이크로 서버 API 가 기존에 모놀리식 아키텍처에 구현된 방식과 똑같이 동작하는 것에 대해 검증이 필요하다는 점이다. 이를 위해 어떤 방식으로 검증을 할 수 있을까?

실시간 검증을 통한 건별 검증 방식 (온라인 검증)

토스뱅크는 이를위한 첫번째 방안으로, 온라인 검증을 시도했다. 먼저, 앱(채널계)에서 고객이 이자 조회 거래를 일으키면 채널계에서 MCI(Message Channel Interface) 통한 기존 코어뱅킹 서버에 이자 조회 서비스를 호출하고, 이자 지급 마이크로 서버의 API 를 "동시에" 호출했다.

코어뱅킹 서버에서 리턴된 이자 값과 이자 지금 마이크로 서버에서 리턴된 이자 값을 각각 리턴받아, 두 이자값이 불일치 할 경우 토스뱅크 내부 모니터링 채널에 해당 내용을 알림받도록 했다. 채널에 알림이 오면 대상 및 로그를 확인하고 원인을 확인하여, 이자 계산 로직을 수정해주는 과정을 거쳤다.

배치를 활용한 대량 검증 방식

Staging 환경이란, 실제 운영환경과 동일하게 구성된 내부 API 테스트용 환경을 뜻한다.

또한 배치를 활용한 대량 검증 방식을 도입했다. Staging 환경에서 채널계 배치를 통해 매일 대량의 검증 대상 목록을 추출했고, 앞선 온라인 검증 방식과 동일하게 코어뱅킹 서버와 이자 지급 마이크로 서버를 각각 호출해주었다. 대상 목록에 대한 검증이 모두 끝나면, 이자 리턴 값이 불일치했던 건들에 대한 내용을 담아 내부 모니터링 채널에 알림으로 받았고, 로직 수정을 반복하였다.

테스트 시나리오 작성을 통한 E2E 통합 테스트 수행하기

위와 같은 API 검증 방식을 통해, 이자 조회 거래에 대한 검증을 마쳤다. 그런데 실제 이자를 지급받는 지금 이자 받기 거래의 경우 코어뱅킹 DB 원장에 잔액을 갱신하고, 회계 처리를 해주는 등의 작업이 필요했다. 따라서 거래가 발생했을 때 실제 데이터가 정확하게 쌓이고 갱신되었는지 추가로 검증해야 했다.

토스뱅크 통장은 잔액을 구간별로 나누어 이자를 차등 지급하고 있다. 잔액 구간별로 나누어 차등 계산되어, 이자가 지급되었는지 검증이 필요했다. 그리고 명의도용, 해킹 피해, 사망 등 토스뱅크 고객의 상태에 따른 검증이 필요했고, 계좌의 상태 및 출금/입금 정지 상태에 따른 검증이 필요했다.

해당 검증 케이스들을 고려해서 테스트 시나리오를 작성했고, 케이스 별로 테스트를 진행하여 이자 계산 및 실제 데이터베이스에 데이터가 정확하게 갱신되었는지를 확인하며 로직을 수정해주는 과정을 거쳤다. 이 과정을 통해, 이자 받기 거래에 대한 정합성 검증을 완료할 수 있다.

순차 배포를 통한 안정적인 마이그레이션하기

💡 여기서 말하는 순차 배포란, 무중단 배포 전략 중 하나인 롤링(Rolling) 배포를 말하는 듯 하다.

이렇게 API 검증이 끝났으니, 코어뱅킹을 바라보던 서비스를 이제는 이자 지급 마이크로 서버 API 만을 바라보도록 라우팅 환경을 전환해주면 된다. API 를 전환할 때 대상 모수를 점차 늘려가며, 순차적으로 오픈했다. 먼저 토스뱅크 수신 개발팀에 오픈하여 직접 이자 받기 거래를 일으키며 데이터 검증 값을 검증했다. 특이사항이 없는 것을 확인하여 토스뱅크 내부 팀원에게 오픈했고, 모니터링을 진행했다.

다음으로는 일부 고객을 대상으로 오픈하고 점차 모수를 늘려가며 순차 오픈하여, 전체 고객을 대상으로 전환을 완료하는 방식을 선택했다. 코어뱅킹 서버를 바라보던 API 호출량과 이자 지급 마이크로 서버를 바라도면 API 호출량을 조절하여 이자 지급 마이크로 서버의 트래픽을 점차 늘려가는 형태로 진행했다.

이로써 토스뱅크는 순차 배포 방식을 채택함으로써 기존에 운영하고 있던 시스템을 무중단하고, 안정적으로 시스템을 마이그레이션했다.

코어뱅킹 MSA 전환의 성과

코어뱅킹 시스템의 세대 전환
오픈소스 기반의 개발 환경 변화에 따른 유연성 및 확장성 증가
지금 이자 받기 거래의 성능 170배 개선
계정계 서버로부터 독립저깅ㄴ 서버를 구축함으로써 안정성 증가
지금 이자 받기 피크타임 트래픽에도 개별적으로 이자 지급 서버 스케일 아웃 가능
도메인 단위로 분리하여 효율적인 MSA 코어뱅킹 시스템 구축
빅뱅 배포 방식을 탈피하여 무중단 시스템 전환 가능

MySQL 레플리케이션 바이너리 로그 기록 타입 (Row, Statement, Mixed)

Sun, 08 Dec 2024 00:00:00 GMT

MySQL 8.0 레플리케이션 동작 과정과 아키텍처 구성 방식 에서 설명했듯이, MySQL 레플리케이션은 현재 GTID 기반의 안정적인 복제 방식을 택했다. 이때 궁금한 점은, 정확히 어떤 이벤트를 기록한다는 것일까?

Row 포맷 (변경된 데이터를 기록)

MySQL 데이터베이스에서 실행한 작업을 바이너리 로그에 저장하는 다양한 형태(포맷)이 있다. 그 중 하나는 SQL 실행을 통해 변경이 일어난 데이터 전부를 바이너리 로그 파일에 기록하는 방법이 있다. 데이터베이스 변경 내용을 각각의 행(row) 단위로 기록한다고 하여, Row 기반 바이너리 로그 포맷이라고 한다.

Row 기반 바이너리 로그 포맷은 변경된 데이터가 모두 바이너리 로그에 기록된다는 것이 가장 큰 특징이다. 따라서 변경되는 데이터가 많을수록 바이너리 로그에도 많은 데이터가 기록된다.

이는 무엇이 문제가 될까? 만약 MySQL 에서 실행한 쿼리가 대량의 데이터를 변경했거나, 또는 데이터 수가 대량으로 삭제되어도, 또는 BLOB 처럼 엄청 큰 용량의 값이 새롭게 추가되거나 수정된다면 문제가 된다. 바이너리 로그 파이릐 크기가 매우 커지면서 저장 공간을 크게 차지하게 된다.

Statement 포맷 (실행한 SQL 을 기록)

그렇다면 변경된 데이터를 모두 기록하느 방법 대신에 다른 방법이 있지 않을까? 그에 대한 방안으로, 실행한 SQL 을 기록하는 방법이 등장했다.

Statement 기반 바이너리 로그 포맷은, 각 이벤트에서 실행한 SQL 문을 바이너리 로그 파일에 기록하는 방법이다. 바이너리 로그의 용량이 크게 줄어들기 때문에, 더 이상 용량을 걱장할 필요가 없다.

하지만 이 또한 문제점이 있다. SQL 문이 복제되어 동일한다고 한들, 실행할 때 마다 결과 다르게 나오는 비확정적(Non-Deterministic) 쿼리가 존재한다면, 소스 서버와 레플리카 서버의 데이터가 다르게 기록된 데이터 정합성 문제가 발생할 수 있기 때문이다. UUID() 함수를 사용하는 쿼리가 전형적인 비확정적(Non-Deterministic) 쿼리 에 해당한다. UUID 함수는 고유한 식별자를 만들기위해 실행할 때 마다 매번 다르고 고유한 값을 만든다.

결국, 소스 서버에서 사용한 SQL 문을 가져와 레플리카 서버에서 동일하게 실행하는 방법은, 소스 서버와 레플리카 서버간에 비확정적 쿼리로 인해 데이터 정합성 문제가 발생할 수 있다.

Mixed 포맷 (Row + Statement 혼합)

이를 해결한 방식이 Mixed 포맷이다. 이는 Row 와 Statement 방식을 혼합한 방식이다. 평상시에는 Statement 포맷으로 로그를 기록하여 바이너리 로그의 크기를 최소한으로 관리한다. 그러다 Statement 포맷으로 복제했을 때 문제가 발생할 수 있는 비확정적 쿼리를 저장하는 경우, Statement 대신에 Row 방식으로 바이너리 로그에 이벤트를 기록한다. 이를 통해 용량 문제도 해결하고, 데이터 정합성 문제도 해결할 수 있다.

MySQL 의 경우 Mixed 포맷을 기본적으로 택한다. 어떤 쿼리가 비확정적 쿼리인지는 MySQL 스토리지 엔진이 자체적인 기준에 따라 판별한다.

만능은 아니다.

편리하긴 하지만 포맷 형식을 MySQL 이 잘못 판단하 저장할 가능성도 조금은 존재하기 때문에, Mixed 방식이 항상 만능은 아니라는 점을 알고있자. 따라서 자신에게 가장 맞는 바이너리 로그 포맷을 찾아서 적용할 수 있어야함을 알자.

참고

무중단 배포 환경에서 구버전 프로세스를 안전하게 종료해보자!(feat. Graceful Shutdown)

Sun, 08 Dec 2024 00:00:00 GMT

현재 포스팅은 하모니 팀 크루 하온(haon) 이 작성했습니다.

현재 무중단 배포 환경의 문제점

지난 Jenkin와 Nginx를 활용한 Blue/Green 무중단 배포 도입기 에서도 다루었듯이, 무중단 배포 전략을 도입하여 다운타임을 최소화했다. 무중단 배포 프로세스를 다시 정리하자면 아래와 같다.

(1) 깃허브 브랜치에 코드가 병합되면, 깃허브는 Jenkins 에 Webhook 요청을 보낸다.
(2) Jenkins는 새로운 버전 코드를 pull 해오고 jar 파일을 빌드한다.
(3) 빌드한 jar 파일을 배포 서버로 전송한다.
(4) Blue 서버에 구버전 애플리케이션이 띄워져있는지 Health Check 하고, 그 결과에 따라 Blue 또는 Green 서버에 신버전 애플리케이션을 띄운다.
(5) (Blue 서버에 구버전 프로세스가 띄워져있다는 가정하에) Green 서버에 신버전 애플리케이션이 잘 띄워졌는지 지속적으로 Health Check 한다.
(6) Green 서버에 애플리케이션이 잘 떴다면, 리버스 프록시로 사용중인 Nginx의 프록시 방향을 Blue 에서 Green 스위칭한다.
(7) 곧바로 Blue 에 띄워져있던 구버전 애플리케이션 프로세스를 즉시 kill 한다.

그런데 위 과정에서 문제가 하나있다. 7번 과정에서 즉시 애플리케이션을 kill 한다는 점이 문제가 된다는 점이다. 만약 7번 과정을 수행하는 도중에 구버전 애플리케이션에 요청이 들어와 처리중인 작업이 있다면, 해당 요청은 어떻게 처리가 될까? 만약 별다른 처리가 없다면, 해당 시점에 유입된 유저의 요청은 아직 정상적으로 처리 완료가 되지 않았음에도 애플리케이션이 강제 종료되어 문제가 될 것이다. 이를 해결하기 위한 방법이 바로 Graceful Shutdown 이다.

강제로 구버전 프로세스를 kill 하던 스크립트

기존에 구성했던 무중단 배포 스크립트 일부를 보자면 아래와 같다. 구버전 프로세스를 강제로 Kill 하는 모습을 볼 수 이다. 문제는 -k 옵션은 kill 명령어를 축약한 것으로, 별다른 지정이 없다면 -15 옵션으로 실행된다. 이는 무엇이 문제가 될까?

if [ "${deployment_target_port}" == "${blue_port}" ]
then
    ssh root@${BACKEND_DEV_IP} "fuser -s -k ${GREEN_PORT}/tcp"
else
    ssh root@${BACKEND_DEV_IP} "fuser -s -k ${BLUE_PORT}/tcp"
fi

echo " ✅ 구버전 프로세스를 종료하고, 신버전 프로세스로 교체합니다."

Unix 시그널(SIGNAL)

유닉스는 시그널(SIGNAL) 을 사용하여 프로세스에 **인터럽트(Interrput)**를 건다. 시그널의 종류는 매우 다양하지만, 그 중 눈여겨 봐야할 시그널은 바로 9 - SIGKILL 과 15 - SIGTERM 으로, 이 둘은 프로세스를 종료하기 위해 사용하는 시그널이다.

9 - SIGKILL 의 경우, 프로세스의 의사와 상관없이 프로세스를 강제로 종료해버린다. 프로세스는 이 시그널을 무시하거나 차단할 수 없다는 특징이 있어, 항상 강제로 즉시 종료된다. 또한 SIGKILL 시그널을 받은 프로세스는 자식 프로세스를 종료하라는 시그널을 보낼 수 없다. 따라서 SIGKILL 은 정상적으로 프로세스를 내릴 수 없을 때 강제로 즉시 중단하도록 사용하는 최후의 수단이다.

그에 반면, 15 - SIGTERM 은 프로세스를 정상적으로 종료시킨다. 프로세스는 현재 사용중인 리소스를 해제하거나, 데이터를 저장하는 등 현재 처리중인 모든 작업을 안전하게 처리한 뒤 종료된다. -k 옵션의 경우, 디폴트로 SIGTERM 이 수행된다.

"fuser -s -k ${GREEN_PORT}/tcp"

SIGTERM 의 문제점

앞서 살펴보았듯이, 우리 팀은 구버전 프로세스를 -k 을 통해 종료하며, 기본 시그널인 SIGTERM 를 이용해 종료한다. 그런데 이때 또한 문제가 존재한다. SIGTERM 시그널을 사용시 애플리케이션에 별다른 설정이 없다면, 애플리케이션을 어떻게 종료해야 할지 몰라서 강제 종료가 되버린다는 점이다. 즉, SIGKILL 과 같이 강제로 종료되버리므로 애플리케이션에 별다른 설정이 필요하다는 점인데, 이때 사용하는 것이 바로 Graceful Shutdown 이다.

SpringBoot Graceful Shutdown

Graceful Shutdown 은 스프링부트 2.3.0 부터 제공하는 기능이다. Graceful Shutdown 을 활성화 하면, 스프링부트는 프로세스 종료 요청인 SIGTERM 이 들어왔을 때 더 이상 새로운 요청을 받지 않으면서, 처리중인 요청은 모두 처리한 뒤 프로세스를 종료하게 된다. (반면 SIGKILL 이 들어온다면 Graceful Shtudown 활성화는 무의미하다.)

Graceful Shutdown 활성화

설정은 간단하다. 아래처럼 application.yml 에서 활성화시켜주면 끝이다.

server:
  shutdown: graceful

타임아웃 추가 설정

그런데 만약 현재 진행중인 요청이 데드락에 빠져서 영원히 작업을 끝내지 못한다면, 스프링부트 프로세스는 영원히 종료되지 않고 대기할 것이다. 이러한 미연의 상황을 방지하기 위해 우리는 아래와 같이 타임아웃을 추가 설정할 수 있다.

spring:
  lifecycle:
    timeout-per-shutdown-phase: 5s

참고

Elastic Search 역 인덱스(Inverted Index) 구조 살펴보기

Fri, 06 Dec 2024 00:00:00 GMT

검색엔진을 이용하다보면, 검색어를 타이밍하는 순간 연관된 추천 검색어들이 등장하는 것을 알 수 있다. 그런데, 어떻게해서 사용자가 타이핑을 하는 그 '찰나' 에 추천 검색어를 빠르게 찾아낼 수 있을까? 그리고 많은 인터넷 문서들 가운데, 검색 키워드에 맞는 문서를 찾아낼 수 있을까? 일반적인 선형탐색을 떠올린다면 절대로 불가능한 속도이다. 이를 가능하게 하는 방법 중 하나가 바로 Elastic Search 를 활용하는 것이다.

Elastic Search

엘라스틱 서치는 Lucene 기반의 오픈소스 검색엔진이다. 잠시 RDBMS 의 인덱스를 떠올려보자. MySQL 과 같은 RDBMS 를 떠올려본다면, 테이블이 인덱싱되면 복잡한 쿼리에서 훨씬 빠른 성능을 보여준다는 것을 알 것이다. 인덱스를 생성하면, 주어진 검색어를 찾기 위해 모든 열을 찾아보는 대신에 인덱스를 활용하여 원하는 데이터가 어디있는지를 찾아낼 수 있다.

엘라스틱 서치의 경우, 검색어가 될 수 있는 문자 또는 문자열에 대해 유연하게 여러 토큰(term)으로 토큰화하고 역 인덱싱한다. (역 인덱스에 대한 내용은 조금 뒤에 설명하도록 한다.) 예를들어 "Hello my world" 가 있다고 해보자. 이 문자열에 대해 빠른 검색 기능을 제공하고자 Elastic Search 를 도입한다면, 이 문장에 대해선 아래와 같은 방법으로 토큰화되고, 인덱싱 될 것이다.

["Hello my world"] : 문자를 통째로 토큰화 할 수 있고,
["Hello", "my", "world"] : 각각의 단어를 토큰화 할 수도 있고,
["Hello", "world"] : 의미있는 중요한 단어들로만 토큰화 할수도 있고,
["hElLo", "WoRlD"] : 대소문자를 구분하지 않고 모두 검색 대상에 포함될 수 있도록 다양하게 토큰화할 수 있다.

이렇게 토큰화된 단어들은 인덱스 key 가 되어, 훨씬 빠른 검색 기능을 지원하게 된다.

역 인덱스 (Inverted Index)

엘라스틱 서치는 검색할 데이터를 역 인덱싱한다. 역 인덱스란 무엇일까? 우리가 일반적으로 알고있는 데이터베이스 인덱스는 책 앞 부분의 목차로 비유한다. 그에 반면, 역 인덱스는 책 뒷부분의 찾아보기에 비유할 수 있다. 책에서 찾아보기는 특정 키워드가 책의 몇 페이지에서 등장했는지를 나타낸다.

MySQL 과 같이 일반적인 RDBMS는 텍스트로 데이터를 검색하기 위해서 LIKE 연산, 즉 패턴 매칭으로 데이터를 탐색한다. 그런데 문제는, LIKE 연산은 성능이 못하다는 점이다. 데이터베이스의 50번째 행, 1,000번째 행에 devhaon 라는 데이터가 저장되어있는 경우를 가정해보자. 만약 RDBMS 에서 LIKE %devhaon% 으로 데이터를 검색한다면, 1,000번째 행까지 모두 탐색을 해야한다. 반면 역 인덱스 구조에선 devhaon 이라는 키워드가 어디있는지 바로 알 수 있다.

위 그림을 살펴보자. 우선 Doc1 ~ 3 을 일반적인 RDBNS 에 저장하고, LIKE 연산자를 활용하여 database 라는 단어가 포함된 테이블을 검색한다고 해보자. (Doc 은 마치 데이터베이스의 하나의 행(row) 개념이라고 이해하면 쉽다.) 이 경우 해당 테이블의 모든 row 를 탐색해야 하므로, O(n) 이라는 시간이 소요될 것이다.

반면 Elastic Search 를 사용하여 역 인덱스를 검색하는 경우라면, 곧 바로 database 행을 찾아보니 3번째 Doc 에 있다는 것을 알 수 있다. 마치 해시 테이블과 같이, key 값만 안다면 그 즉시 value 를 O(1) 에 찾아낼 수 있는 것과 같다. 이때 key 값이란 역 인덱스에서 토큰(term) 이 될 것이다.

역 인덱싱 과정 (토큰 생성 과정)

다시 한 번 앞서 예시로 들었던 "Hello My World" 를 예시로 들어, Elastic Search 에서 토큰이 생성되는 과정을 알아보자.

(1) 텍스트를 특정 단위 (여기서는 띄어쓰기) 단위로 분리한다. ["Hello", "My", "World"] 와 같이 분리한다.
(2) 대문자를 모두 소문자로 변경하고, 토큰을 아스키 코드 순서대로 정렬한다.
(3) 검색에 잘 사용되지 않는 굳이 필요없는 불용어(a, the, of, for, to 등) 를 제거한다.
(4) 형태소 분석 과정을 거쳐서 단어를 원형으로 변환한다. (예를들어 executing 단어를 execute 와 같이 원형으로 변환)
(5) 중복되는 토큰에 대해 토큰 단 1개만을 남긴다. (중복 토큰 제거)

이렇듯 역 인덱스는 생각보다 생성하는데에 많은 작업이 요구된다. 그 때문에 원하는 데이터가 역 인덱싱되는데 까지 걸리는 시간이 좀 오래 걸리는데, 이 생성되는데 까지 걸리는 시간을 NRT(Near Real Time) 이라고 한다.

ELK Stack 에서의 역할

Elatic Search 는 흔히 부르는 ELK Stack 에 사용된다. ELK Stack 이란 Elastic Search, Logstatch, Kibana 를 합친 약자로, 데이터를 수집하고 분석하는 도구를 뜻환다.

그 중에서 Elastic Search 는 Lucene 기반 검색엔진 (NoSQL 데이터베이스로도 분류하기도 함) 이며, 대량의 데이터를 빠르게 저장하고 검색할 수도 있도록 지원한다. 앞서 살펴봤듯이, 빠른 데이터 검색을 위해 데이터를 역 인덱싱(Inverted Index) 하여 저장한다. Elastic Search 는 클러스터 구조로 분산 구성된다. 따라서 고가용성과 확장성있는 설계에 유리하다. 또한 우리가 아는 일반적인 RDBMS 와 다르게 SQL 을 지원하지 않고, Restful API 를 통해 데이터를 추가하고, 검색한다. 마치 SQL 의 SELECT 쿼리가 엘라스틱 서치에서는 GET 요청에 대응되고, INSERT 는 POST 요청에 대응된다.

ELK 스택은 일반적으로 로그 수집, 처리 및 분석에 활용된다. 이 중에서 엘라스틱 서치는 계속 설명했듯이 검색 엔진으로, 수집한 로그를 저장하는데에 활용된다.

단점

엘라스틱 서치 또한 단점이 존재하기에, RDBMS 를 많이 사용한다. 엘라스틱 서치는 JOIN 절을 지원하지 않는다고 한다. 또한 트랜잭션을 지원하지 않는다.

정리

엘라스틱 서치란? : 엘라스틱 서치는 역 인덱스 구조의 검색엔진으로, 검색어가 될 수 있는 문자에 대해 여러 토큰(term) 을 생성하고 O(1) 에 검색할 수 있도록 지원한다.
Elastic Search의 인덱스구조와 RDBMS의 인덱스 구조의 차이점 : 일반적인 RDBMS의 인덱스는 B+ Tree 기반의 자료구조로 구성되며, 정형 데이터에 대한 검색만을 빠르게 지원한다. 반면, 엘라스틱 서치는 역 인덱스 자료구조로 구성되며, 비정형 데이터에 대한 검색을 빠르게 지원한다.
Elastic Search의 키워드 검색과 RDBMS의 LIKE 검색의 차이점 : RDBMS 는 단순히 패턴과 일치하는 검색(단순 패턴 매칭)만을 제공하여, 동의어나 유의어 같은 검색은 불가능하다. 하지만, 엘라스틱 서치는 동의어나 유의어를 활용한 검색이 가능하며, 비정형 데이터의 색인과 검색이 가능하고, 역 인덱스를 지원하므로 매우 빠른 검색이 가능하다.

💡 MySQL 최신 버전에서 n-gram 기반의 Full-Text Search 지원하여, 동의어와 유의어에 대한 검색이 가능해졌다고는 한다. 하지만, 한글 검색의 경우 아직 많이 빈약한 감이 있다고 한다. 이때 Full-Text 란 이미지, CSS, 글 등의 복합적으로 이루어진 컨텐트에서 순수하게 텍스트만 추출한 데이터를 뜻한다.

참고

MSA 기초

Thu, 28 Nov 2024 00:00:00 GMT

MSA 등장 배경과 이유는 어쩌면 다 풀어 설명할 수 있을 것 같지만, MSA 의 전반 오버뷰에 대해 다시 학습해보겠다는 차원에서 포스팅을 작성해본다.

모놀리식 아키텍처의 한계

MSA 에 대해 본격적으로 학습하기 전에, 우선 모놀리식 아키텍처 시스템에 대해 다시 짚어볼 필요가 있다. 모놀리식 시스템이란 웹 애플리케이션을 하나의 단일한 독립 시스템으로 구축하는 아키텍처이다. 즉, 하나의 애플리케이션에 모든 비즈니스 로직을 통째로 모아놓은 구조를 취한다.

이 특징 덕분에 모놀리식 아키텍처는 소규모 프로젝트에 적합하다. 개발, 빌드, 배포 및 테스트가 용이하다. 하지만, 기업의 시스템 규모가 점점 커지고 복잡해지는 경우 모놀리식 아키텍처의 한계점이 드러나기 시작한다. 무엇이 문제가 될까?

(1) 작은 수정사항 하나에도 전체 빌드 및 재배포가 다시 일어나야 한다. 이 때문에 불필요하게 빌드 및 배포 시간을 잡아먹는 시간이 많아진다.
(2) 많은 양의 코드가 몰려있어서 유지보수가 어려워진다.
(3) 시스템내의 자그마한 한 부분에 장애가 발생하면 전파되어 시스템 전체에 영향을 미치고, 자칫 시스템의 모든 기능이 중단될 수도 있다.
(4) 특정 부분에 대해서만 Scale Out 이 어렵다. 만약 배달의민족 서비스내의 여러 기능중에 주문 기능에 대해서만 요청의 빈도수가 매우 높아, 이에 대해서만 성능을 올리고 싶다 해보자. 즉, Scale Out 을 하고 싶은 경우인데, MSA 와 달리 주문 도메인 서버가 분리되어 있지 않으므로 부분 Scale Out 이 어렵다.

MSA

MSA 는 이러한 모놀리식 시스템의 대안으로 등장했다. MSA 환경에서는 시스템을 여러 작은 독립적인 서비스로 분할하여 독립적으로 개발하고, 관리하고, 배포한다. 또한 장애 발생시 다른 서비스로 전파될 위험이 줄어든다. 발생한 해당 장애는 해당 마이크로 서버에서만 한정되고, 다른 마이크로 서버에는 영향을 미치지 않는다. 즉, 각 마이크로 서버는 서로에게 영향을 받지않고 독립적으로 확장(Scale Out) 가능하고, 관리할 수 있다.

MSA 의 장점

(1) 개발 유연성의 한계 극복 : 모놀리식 아키텍처는 모든 구성요소가 하나의 애플리케이션으로 구성되어 있어, 변화에 대한 대응이 어렵다. 만약 새로운 기능 추가를 하거나 자그마한 수정을 하나만 하고싶더라도 전체를 빌드, 재배포해야하는 문제가 있었다. 반면 MSA 는 꼭 필요한 독립적인 마이크로 서버만 수정 및 빌드/배포가 신속히 가능하다.
(2) 배포/롤백 리스크 감소 : MSA 는 여러개의 서비스로 구성되어 있다. 이 중 수정이 필요한 부분만 빠르게 찾아 정확히 대응이 가능하다.
(3) 장애 전파 방지 : 모놀리식은 특정 부분에 대한 장애가 시스템 전체로 전파될 수 있다. 반면 MSA 는 각각의 서비스가 약한 결합도를 가지므로 장애 전파를 최소화하거나 아예 막아버릴 수 있다. 이를 통해 장애 서비스만 빠르게 FailOver 할 수 있다.
(4) 독립적인 Scale Out 가능 : 모놀리식에서 Scale Out 을 하고 싶다면 불필요한 서비스 및 도메인 코드까지 포함하여 함께 확장해야 한다. 반면 MSA 는 원하는 마이크로 서버만 Scale Out 이 가능하다. 이 덕분에 효율적인 리소스 사용이 가능해진다.

단점

하지만 당연하게 단점 또한 존재한다. MSA 는 만능이 아니다.

(1) 모놀리식에 비해 복잡도가 매우 크다. 코드가 직관적이지 않기 때문에 단번에 코드를 이해하고 수정하는 것이 어려워서 유지보수가 자칫 어려워질 수 있다.
(2) 성능이 저하될 수 있다 : MSA 의 각 마이크로 서버는 서로 네트워크 통신을 해야하므로 네트워크 지연 및 Latency 가 발생할 수 있다. 즉, 모놀리식 아키텍처에 비교한다면 성능이 더 느리다.
(3) 데이터 일관성 : 서비스가 독립적으로 데이터를 가지고 있을 때 일관성을 유지하기 어려울 수 있다. 분산 시스템에서 트랜잭션 처리, 일관성 유지 등에 대한 처리 기법에 대한 높은 이해도가 요구된다.
(4) 테스트가 어려워진다 : 모놀리식에 비해 여러 서비스간의 통합 테스트와 E2E 테스트를 수행하기 어려워진다.

참고

✒️ 카카오테크 부트캠프에서 찾아낸 나만의 효과적인 프로그래밍 학습법

Thu, 28 Nov 2024 00:00:00 GMT

💡 카카오테크 부트캠프는 자율 주제 글쓰기 & 소정의 이벤트가 주어진다. 이 포스팅은 "카카오테크 부트캠프에서 찾아낸 나만의 효과적인 프로그래밍 학습법" 주제로 작성한 글이다.

최고의 소프트웨어 개발자 양성 과정, 카카오테크 부트캠프

벌써 첫 눈이 내린 11월 말이네요. 저희 카카오테크 부트캠프 크루들과 어제 라이언 눈사람도 만들고, 교육장에 들어와 따뜻한 커피도 한 잔 했답니다. 최고의 동료, 훌륭한 멘토들과 함께 성장하는 이곳이 정말 행복하기만 한데, 벌써 수료를 앞두고 있네요. 아직 카카오테크 부트캠프에서 동료들과 하고 싶은 것들이 넘쳐나는데, 시간은 무정하게 흘러갔습니다. 곧 12월부터 카카오테크 부트캠프 2기 모집이 시작된다고 합니다.

문득, 수료를 앞두고 있으니 작년 이맘때 혼자서 프로그래밍을 공부할 때가 생각나네요. 혼자서 공부하니 무엇을 공부해야하는지 조차 스스로 찾아야 했고, 혼자 긴 시간을 방황해야 했습니다. 곁에서 올바른 방향으로 바로 잡아줄 멘토가 없다보니, 정말 많이 방황하게 되더라고요.. 스스로가 제대로 공부하고 있는 게 맞는지 끊임없이 의심하면서 감정 소모도 많이 했습니다. 그런 저에게 카카오테크 부트캠프는 큰 길잡이가 되었어요. 무엇을 시작해야하는지 조차 몰랐던 저에게 현장 중심의 교육 기회를 제공해주었고, 평생동안 자기 주도적으로 학습할 수 있는 역량을 가진 인재로 만들어주었거든요.

지금부터, 카카오테크 부트캠프만의 소프트웨어 교육 철학을 소개해볼까 해요. 최고의 몰입 환경 속에서 그간 어떻게 성장했는지를 돌이켜보고자 합니다. 그리고 6개월의 과정 속에서 제가 만들어낸 나만의 자기주도 학습법에 대해 공유해볼까 합니다 😎

전통적인 교육, 그리고 카카오테크 부트캠프

카카오테크 부트캠프 오프라인 교육장

저희는 초, 중, 고등학교와 대학교를 거치며 책상에 가만히 앉은 상태로 지식이 주입되는 교육 방식에 익숙합니다. 하지만, 그런 교육에는 주관과 비판적 사고가 결여되어있죠. 이런 전통적인 교육과정을 거쳐 간 저희 대부분은 스스로 생각하고, 고민하는 방법을 잊은 지 오래 일 것입니다. 자신이 진정 무엇을 하고 싶은지도 모른 채 높은 점수를 위한, 평가를 잘 받기위한 학습만을 해온 저희는 학습의 본질을 잊은 채 살아왔던 것은 아닐까요? 🤔

일방적으로 답을 알려주는 교육은, 교육받는 이로부터 스스로 답을 찾기 위한 고민의 기회를 박탈하는 것입니다. 타인이 정의해준 문제를 남이 정해놓은 방법으로 해결하는 것을 의미있는 학습이라고 부를 수 있을까요? "Why?" 라는 질문을 던지는 학생을 찾아볼 수 없는 교육에서 저희는 정말로 본질을 이해하고, 깨달을 수 있을까요?

PBL(Problem Based Learning)

카카오테크 부트캠프는 일방적인 강의를 진행하면서 정답을 제공하는 교육이 아닙니다. 카테부는 강의 위주의 교육 보다는 잘 설계된 미션, 그리고 관련된 최소한의 지식이나 키워드만을 크루들에게 던져줍니다. 그리고 크루들은 주어진 개인 & 팀 미션을 해결하기 위해 정해진 해결 방법이 아닌 자신만의 해결 방법을 만들기 위해 끊임없이 고민하고, 스스로 찾아야합니다. 즉, 학습자는 지식보다 문제을 먼저 접하고, 문제를 해결하는 과정에서 자연스럽게 필요한 지식을 습득합니다. 그렇게 크루들은 자신이 직접 학습한 지식의 필요성에 대해 깊은 공감을 할 수 있습니다. 카카오테크 부트캠프는 이 교육 철학을 PBL(Problem Based Learning) 이라고 부르고 있어요.

Project Based Learning : 프로젝트 기반 학습

Problem Based Learning : 문제 해결 기반 학습

(Sequential) Progress Based Learning : (순차적) 진행 기반 학습

카테부(일명, 카카오테크 부트캠프) 는 PBL(Problem Based Learning) 를 위와같이 정의하고 있어요. 전통적인 수동적 수업 방식을 벗어나 학습자가 학습의 주체가 되어 능동적인 학습 활동을 할 수 있도록 설계된 수업을 말하는 것으로, 주체적이고 협동적인 학습 활동을 통해 문제해결 능력, 자기주도학습 능력, 협동학습 능력을 향상시킬 수 있는 효과적인 학습 방법을 뜻합니다.

주어진 개인 & 팀 미션을 열심히 마치고 멘토님에게 피드백을 요청하면, 그에 대한 상세 피드백이 미션이 끝난 시점에야 비로소 진행됩니다. 문제를 해결하기 위해 많은 고민을 끝마치고, 이미 자신만의 해결 방법을 만들어낸 상황에서 듣는 강의는 우리에게 '정답'이 아닌 문제에 대한 '새로운 관점' 이죠. 이 과정에서 잘못 알고 있던 내용을 교정할 수 있고, 모호하게 알고 있던 부분이 좀 더 선명해지게 됩니다.

미션 수행 과정에서 만들어진 각자의 문제 해결 방법은 평가되거나, 채점되는 방식이 아닙니다. 생각이 다르고 더 경험이 풍부한 멘토님들을 통해 피드백과 자유로운 의견을 주고받는 과정만이 존재할 뿐이죠. 🙂

카카오테크 부트캠프에서 발견한 나만의 평생 자기주도 학습법

맹목적으로, 자신의 생각과 깊은 고민이 담겨있지 못한 학습 태도는 학습자 본인에게 절대 유의미한 성장을 끌어낼 수 없습니다. 학습 방법도 마찬가지입니다. 모두에게 적용되는 절대적인 최적의 학습법이 있을까요? 한 사람에게 매우 효과적으로 작용한 학습 방법이 다른 사람에게는 무용지물일 수 있습니다. 사람 모두는 각기 다른 성향을 갖고 있기 때문이죠.

저 또한 카카오테크 부트캠프에서 나만의 효과적인 학습법을 찾아내는데 이것저것 많은 방법을 시도했습니다. 맹목적으로 귄위있는, 일방적인 누군가의 의견을 따르는 것 보다, 평생 저만의 학습법을 찾는 것이 좋겠다는 생각이었습니다. 카테부 교육 철학 또한 일방적인 주입식 교육이 아닌, 본인과 크루별로 자율적인 문화, 학습법을 찾아내길 강조하죠. 저는 이 교육 철학 속에서 아래와 같은 학습법을 찾아낸 것 같습니다. 몰론 아직 다듬어야 할 부분은 많지만, 어느정도 학습법이 정교화된 것 같습니다.

기록하고, 공유하고, 설명하기

💡 제 프로그래밍 학습법에 대한 자세한 내용이 궁금하다면 프로그래밍을 공부하며 능동적인 성장을 위한 학습방법 을 참고해주세요! 😎

저는 한 주제에 대한 학습을 제대로 마쳤다! 의 기준을 남에게 명확히 설명할 수 있는가? 로 판단합니다. 즉, 주어진 학습 키워드를 나만의 언어로 타인에게 제대로 설명할 수 있어야지 자신만의 지식으로 체화한 것이라고 생각해요. 이를 확인하기 위한 좋은 방법은, 주변 크루들에게 내가 학습한 내용을 설명해보는 것입니다. 학습한 내용을 타인에게 설명하다보면 내가 어떤 부분을 잘 모르고, 잘 이해했는지 금방 알아차릴 수 있거든요. 즉, 학습한 지식을 머리 밖으로 인출(Output)하는 과정속에서 생각이 정교화(elaboration) 되고, 메타인지가 활성화됩니다.

실시간 오프라인 오피스 작업 공간

이 믿음을 갖고 카테부에서 제 학습법을 정교화시키기 위해 크루들과 정말 다양한 방법을 시도해봤어요. 한 뜻을 가진 크루들과 스터디를 하며 회의실에서 발표도 해보고, 교육장 내의 오피스에서 일과시간에 끝나고 다같이 남아서 뜨겁게 토론도 해봤습니다.

카테부 오프라인 교육장은 자신만의 효과적인 학습법을 찾아낼 수 있도록 장기간 몰입하기에 최고의 환경이에요. 자율적인 몰입 환경에서 성장에 열망 넘치는 크루들이 가득하고, 함께 성장하며 여러 학습법을 시도해볼 수 있고, 정해진 규정없이 자신만의 정답을 찾아갈 수 있도록 지원합니다. 즉, 나만의 색깔과 개성을 찾아갈 수 있도록해요. 이를 위해 중앙 타운홀 무대에서 짧게 강연을 해도 좋고, 각 팀 마다 제공되는 오피스에서 프로젝트 회의를 해도 좋고, 회의실을 예약하고 스터디와 소규모 발표 세미나를 열여도 되거든요. (카테부 멘토님들, 운영진, 크루들 모두에게 항상 땡큐 😉)

그런데, 문제점이 하나 있었습니다. 저 또한 교육장에서 여러 학습법을 시도해보던 중 한 가지 아쉬운 점을 발견했어요. 그건 바로 24시간 내내 저를 따라다니며 설명을 들어줄 크루는 그 어디에도 없었다는 점이에요. 밤새 공부하고 싶어도 사람마다 공부하는 시간대, 주제 모든 것이 똑같을 순 없죠.

블로깅을 통해 학습한 지식을 설명하기

그렇다면 현실적으로 가장 좋은 방법은 무엇일까요? 저는 바로 블로깅이라고 생각해요. 내가 그날 공부한 개념에 대해 잘 모르는 다른 사람들도 쉽게 이해할 수 있도록 글을 쓰는 그 과정에서 메타인지가 향상되는 경험을 많이 할 수 있었습니다. 누군가에게 가르치듯이 설명하고, 시끄럽게 떠드는 학습 방식은 이미 뇌과학적으로 높은 학습효과를 보인다는 것이 이미 증명된 사실이죠. 반면 조용하게 인강과 책을 읽고, 문제를 대충 풀어보는 수동적인 방식은 매우 낮은 학습효과를 보인다는 것 또한 이미 증명된 사실이에요.

블로깅은 자신의 상황에 알맞게 언제든지 글쓰기를 시작할 수 있습니다. 글을 작성하면서 본인 스스로 남을 위해 설명하듯 글을 작성하다보면, 생각이 정교화(elaboration) 되고, 이곳저곳 흩어진 생각을 한 곳으로 모으며 지식을 글로 설명(explain) 할 수 있어요. 타인에게 설명을 하듯 글쓰기를 시작하면, 자연스레 지식과 생각들이 정리됩니다. 또한 글을 적다가 내가 잘 모르는 부분이 있다면 반드시 설명을 하는데에 막힐 수 밖에 없습니다. 이 과정에서 메타인지가 활성화됩니다. 내가 부족한 부분을 글을 작성하며 정확히 알 수 있게되죠. 그를 보충하기 위한 추가 학습 키워드가 생기며, 필요에 의해 능동적으로 학습하고, 배우고, 고민하고, 보충할 수 있는 기회가 주어집니다.

또한 블로깅은 기억의 장기화에 매우 큰 효과를 보이기도 해요. 인간은 망각의 동물입니다. 모든것을 기억할 수 없으며, 설령 높은 이해도를 갖고 있던 지식들도 오랜 시간이 지났을 때 잊기 마련이죠. 이때 블로깅은 장점을 보입니다. 그 당시 내가 갖고 있던 정교화된 생각들을 빠르게 상기할 수 있으며, 휘발된 기억을 빠르게 되찾을 수 있거든요. 이렇게 정교화된 생각들을 내가 필요할 때 마다 계속 꺼내볼 수 있다는 점도 매우 큰 장점입니다.

글을 쓰고 있는 지금 기준으로, 카카오테크 부트캠프 시작 이후에 작성한 블로그 포스트가 110개가 쌓였어요. 약 2일에 한 번꼴로 글을 쓴 것 같아요. 이렇게 글쓰기 습관을 들이면, 나중에 성장이 지체되는 것 같은 불안감이 오더라도 그간 작성한 블로그 포스트를 돌아보며 '맞아. 그래도 나 이런 것들을 공부했었어. 힘내보자!' 라는 생각도 할 수 있습니다. 이렇듯 블로그 포스팅은 학습의 정량적인 지표 가 되기도 합니다.

함께 글쓰기를 통해 성장하기

하모니 팀 기술 블로그

몇 달 전부터, 블로깅을 저 혼자가 아닌 카테부 크루들과 함께 작성하며 성장할 수 있는 방법도 떠올려봤어요. 팀원 서로가 태스크를 진행하며 학습하거나 경험한 내용을 글로 공유하며 이해도를 높이는 고유 문화를 만들기 위해, 하모니 팀 기술 블로그 주도적으로 운영하고 있어요. 팀 기술 블로그 플랫폼은 제가 직접 개발한 Gatsby 블로그 오픈소스 프로젝트를 사용해서 개설했답니다. 팀 기술 블로그내에 작성한 글을 토대로 자체 세미나를 열고, 다른 크루들에게 설명하는 시간을 매주 가지니 더 효과적인 학습이 되는 것 같습니다. 이렇듯 저는, 글쓰기를 기반으로 카테부 오프라인 교육장에서 저만의 색깔과 학습법을 찾아가고 있어요. 😁

카테부에서 찾아낸 학습법이 더 궁금하다면 프로그래밍을 공부하며 능동적인 성장을 위한 학습방법 을 참고해주세요. 블로깅을 통한 프로그래밍 학습 방법, 이 좋은걸 저만 할 수는 없죠! 훗. 😄

뜨겁게 토론하고, 잡담하고, 발표하기

카테부에 참여하기 전에는, 제가 가지고 있는 생각에 대한 자신감이 많이 없는 편이었습니다. 옛날에는 제가 무지하다는 것을 남에게 들키는게 정말 무서웠고, 타인의 의견과 갈등이 생기는게 정말 싫어서 항상 토론을 회피했거든요. 하지만, 카테부에서의 저는 확연히 달라졌습니다. 카테부는 뜨거운 토론, 잡담을 중요시하는데요, 갈등 해결 경험 또한 중요한 소프트 스킬 중 하나라고 생각하는 문화가 녹아있습니다.

카카오테크 부트캠프, 매주 오후 2시에 진행되는 Tech Talk 기술 발표 세미나 참여

동일한 학습 주제, 미션, 프로젝트 기능 구현을 해결하는데에 뜨거운 잡담을 통해 다양한 시야가 확장되는 것을 자주 경험했습니다. 혼자서 공부하고, 프로그래밍 하다 보면 자신만의 틀에 박힌 생각에 갇히게 되는 경우가 많거든요. 하지만 서로 다른 의견을 가지고 있는 사람과 뜨겁게 의견을 주고받다보면 전혀 생각치 못한 획기적인 방법을 깨닫고, 다양한 시야가 확장된다는 것을 알 수 있었습니다. 더 빠르게 성장하는 학습 방법은 더 능동적으로 최대한 많이 토론하고, 잡담하는 것입니다. 저희 크루들은 서로가 다른 의견을 가지고 있을 때 그 자리를 회피하기보다는 오히려 의견 교환에 적극 참여하는 경우가 대부분입니다. 저 또한 갈등이 싫어 토론과 잡담을 항상 회피하는 사람이었으나, 지금은 오히려 다양한 의견 교환을 위해 여러 스터디, 기술 발표 세미나에 적극 참여중입니다.

한 예로, 이번주에 10분 카카오 Tech Talk 기술 발표 세미나 에 참여해 열심히 발표를 했던 기억이 남네요. 일명, 카부톡 발표 세미나는 매주 월~수요일 오후 2시에 각 과정별로 크루들이 기술적 경험을 공유하는 발표 세미나입니다. 제가 알고있는 지식을 발표 세미나에서 공유하고, 생각치 못했던 질문들과 토론을 주고받으면서 함께 성장할 수 있는 세미나입니다.

이번 주차 발표자로 참여하면서, 이 당시 또한 하지만 서로 다른 의견을 가지고 있는 사람과 의견을 주고받으며 자연스럽게 시야가 확장되는 것을 경험했습니다. 책 '함께 자라기' 에서 강조하는 함께 성장하기가 이제는 무엇인지 조금은 알 것 같아요. 맥락은 조금 다르겠지만, 카테부에서 오프라인으로 다른 사람들과 물리적으로 모여있는 공간에서 얻을 수 있는 가장 좋은 점이 이렇게 뜨겁게 토론하고, 잡담하며 함께 성장할 수 있는 것이 아닐까 싶습니다. (카테부 다시 한 번 땡큐 😉)

마치며

카카오테브 부트캠프 교육과정은 타인의 생각을 수동적으로 받아들이던 과거의 나로부터 탈피하여, 나만의 생각을 만들어가는 과정이라는 생각이 많이 듭니다. 제일 중요한 것은 타인의 생각을 맹목적으로 따르지 않기인 것 같습니다. 나만의 색깔과 개성, 학습법을 찾아가게 해준 카테부 모든 분들에게 항상 감사할 따름입니다. 다른 모든 분들도 동의되지 않은 권위에 굴복하지 않기를 바라며, 글을 마치겠습니다 😁

Grafana, Prometheus, SpringBoot Actuator 기반 모니터링 환경 구축하기

Wed, 27 Nov 2024 00:00:00 GMT

학습배경

최근에 서비스를 개발하면서 클라우드 팀과 모니터링을 논의할 때, 스프링에서 메트릭 수집방법과 데시보드 구성 방식을 잘 몰라서 어려움을 겪었다. 간단한 실습을 해보며, 전반 흐름에 대해서 얇게 이해해보도록 한다.

모너티링 구축 배경

Micrometer 추상화

사실 모너터링 툴은 Prometheus 외에도 굉장히 다양합니다. 저도 지금 직접 모니터링 환경을 구축하면서 느끼듯이, 모든 개발자 및 인프라팀은 상황 및 기호에 따라 다양한 모너터링 툴을 변경해야는 상황이 발생하는데, 마이크로미터 가 추상화를 제공하여 다양한 모너터링 구현체를 지원한다. 개발자는 마이크로미터가 정한 표준 방법으로 메트릭(측정 지표) 를 전달하고, 사용하는 모너터링 툴에 알맞는 구현체 (여기선 프로메테우스) 를 선택하면 된다.

메트릭(Metric) 수집 아키텍처

Spring Actuator 는 마이크로미터가 수집하는 CPU, JVM, 커넥션등의 수많은 메트릭(지표) 를 편리하게 사용할 수 있는 기능을 제공해준다. 지금부터 알아볼 Actuaor, Grafana, Prometheus 의 기능을 요약해보면 다음과 같다.

Spring Actuator : 메트릭 정보를 쉽게 수집할 수 있게 정보를 제공
Prometheus : 마이크로미터로 부터 주기적으로 메트릭 정보를 PULL 받아서 저장
Grafana : 프로메테우스가 수집한 정보를 활용하여 사용자에게 보기좋은 정보를 제공해주는 DashBoard

SpringBoot Actuator 와 마이크로부터로 부터 메트릭 정보가 자동으로 생성되며, 프로메테우스 구현체가 읽을 수 있는 메트릭 포맷으로 변환된다. 그러면 프로메테우스는 일정 주기로 메트릭을 주기적으로 수집해서, 수집한 메트릭을 내부 DB 에 저장한다. 그러면 그라파냐 데시보드를 통해 프로메테우스에 수집된 메트릭 수집정보를 시각자료로써 손쉽게 조회 가능하다.

Spring Actuator

그럼 지금부터 메트릭 수집 환경을 구축해봅시다. 우선 엑츄에이터의 의존성을 추가해주자.

implementation 'org.springframework.boot:spring-boot-starter-actuator'

Actuator 엔드포인트

라이브러를 추가한뒤 서버를 실행시키고 /actuator 로 접속해보면 Actuator 가 제공하고 있는 엔드포인트 목록들을 확인할 수 있다. 엔드포인트란 쉽게말해 Actuator 를 통헤 애플리케이션의 내부 정보를 외부에 유출시키는 것을 의미한다.

{
    "_links": {
        "self": {
            "href": "http://localhost:8080/actuator",
            "templated": false
        },
        "health": {
            "href": "http://localhost:8080/actuator/health",
            "templated": false
        },
        "health-path": {
            "href": "http://localhost:8080/actuator/health/{*path}",
            "templated": true
        }
    }
}

마이크로미터 프로메테우스 구현체

위와 같이 Actuator 가 기본적으로 유출시키는 엔드포인트에 이어서, Prometheus에서 사용되는 메트릭에 대한 엔드포인트도 외부에 유출 시켜야한다. 이를위해 우선 Prometheus 에 대한 의존성이 필요하다.

runtimeOnly 'io.micrometer:micrometer-registry-prometheus'

위 의존성은 애플리케이션에 마이크로미터 프로메테우스 구현체 라이브러를 추가하는 것이다. 프로메테우스는 JSON 형식의 메트릭 데이터를 이해할 수 없다. 따라서 프로메테우스가 이해할 수 있는 메트릭 포맷으로 변경해야하는데, 이 때문에 마이크로미터를 사용해서 프로메테우스가 이해할 수 있는 포맷으로 손쉽게 변형 가능하도록 위 구현체를 활용하는 것이다.

Prometheus 엔드포인트 유출

이어서, 아래와 같이 application.yml 파일에 설정을 추가해서 외부에 엔드포인트를 유출시킨다.

management:
  endpoint:
    shutdown:
      enabled: true
  endpoints:
    web:
      exposure:
        include: prometheus

정상적으로 외부에 유출시켰다면 아래와 같은 결과를 조회할 수 있습니다.

// ...
"prometheus": {
  "href": "http://localhost:8080/actuator/prometheus",
  "templated": false
}

Prometheus

앞선 과정을 통해 actuator 엔트포인트로 프로메테우스가 이해할 수 있는 metric 을 생성하고 있으니, 이제 프로메테우스가 해당 metric 을 주기적으로 수집할 수 있도록 설정 해보겠습니다. "prometheus.yaml" 파일을 생성하고 아래와 같이 내용을 구성해주자.

global:
  scrape_interval: 1m   // 기본값:1m (1분)

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ['http://localhost:8080'] // 또는 'host.docker.internal:8080'
        metric_path: '/actuator/prometheus'

scrape_interval 은 메트릭을 수집할 주기를 명시하는 것으로 위에서는 10초의 주기로 메트릭을 수집하도록 설정했다. job_name 은 말그대로 job 이름으로 임의의 이름을 사용했으며, metric_path 는 메트릭을 수집할 경로로써, 앞서 유출시켰던 엔트포인트를 명시해주었다. targets 은 메트릭을 수집한 애플리케이션 경로를 명시하는 것이다.

이때 저는 host.docker.internal를 사용하여 도커 인스턴스 내부에서 호스트의 포트에 접속해보자. 로컬이 아닌 환경이라면 이에 맞게 입력하며 된다.

도커를 이용한 Prometheus 설치

$ docker pull prom/prometheus

docker run \
    -p 9090:9090 \
    -v {%상위경로%}/prometheus.yml:/etc/prometheus/prometheus.yml \
    prom/prometheus

{%상위 경로%}에는 위에서 입력한 prometheus.yml의 상위 경로를 작성해준다. 이로써 도커 기반의 프로세스 실행에 성공하면 9090 포트 로 접속해보자. 그러면 아래와 같이 프로메테우스 대시보드를 조회할 수 있게된다.

프로메테우스가 수집한 여러 메트릭 중 하나를 확인해보자. 예를들어 http_server_requests_seconds_max 메트릭을 입력하면 아래와 같이 Graph로 시각화하여 메트릭을 조회가 가능하다.

Grafana

앞서 말했듯이, 프로메테우스가 메트릭에 대한 시각화를 제공하지만 그라파나를 이용하여 더욱 강력한 메트릭 시각화 할 수 있다.

$ docker pull grafana/grafana
$ docker run --name grafana -d -p 3000:3000 grafana/grafana

docker run을 성공적으로 실행하면 3000번 포트로 로 그라파나에 접속할 수 있다.

Grafana에 접속하면, 위와 같은 로그인 페이지에 접속됩니다. 초기 계정은 admin, admin 이고, 처음 로그인하면 비밀번호를 변경하는 창이 나온다.

데이터소스 추가를 위해 그라파나 첫 페이지에서 DATA SOURCE를 클릭해줍시다. 여기서 앞서 구축했던 프로메테우스를 연동하는 것이다.

Data Source 이름을 지정해주고, URL에 http://host.docker.internal:9090/ 를 입력해주자. (또는 http://localhost:9090 을 입력) Data Source 설정에 성공할 경우 성공을 알리는 녹색 상태창이 나오게 된다.

이제 최종적으로 Import 를 클릭하여 대시보드를 생성 해보자. 스프링부트 메트릭을 보여주는 유명한 대시보드로 JVM dashboard 가 있습니다. 몰론 우리가 직접 데시보드를 구성하는 것도 가능하지만, 지금은 유명한 프리셋을 사용한다. 다양한 대시보드는 Grafana Dashboards에서 확인할 수 있다.

Import via grafana.com 에다 h‘https://grafana.com/grafana/dashboards/4701-jvm-micrometer/’ 를 넣어주고 Load 를 클릭합시다. 그러고 마지막으로 Import 를 클릭하면 아래와 같은 깔끔하고 멋진 데시보드가 조회되는 모습을 확인할 수 있습니다.

Grafana Dashboard

이렇게 멋진 그라파나 대시보드를 만들어보았다. 스크린샷보다 더 많은 메트릭이 있으므로 스크롤하여 확인해봐도 좋습니다. 기본 범위는 24시간으로 설정되어있다.

참고

어노테이션 기반 DI 컨테이너 프레임워크 구현하기

Sun, 24 Nov 2024 00:00:00 GMT

본 포스팅에서 실제 구현한 실습 구현 코드는 DI 컨테이너 구현하기 PR 에서 확인할 수 있다.

왜 DI 가 필요한가?

DI 의 필요성에 대해 정리하기 전에 먼저 의존관계(Dependency) 에 대해 정리해볼 필요가 있다. 의존관계란 한 객체에서 모든 일을 처리하기 힘들기 때문에, 무게가 무거워지기 때문에 내가 해야할 일을 다른 객체에게 위임하면서 발생한다.

가령 레이어드 아키텍처에서 UserController 가 모든 회원가입 로직을 담당할 수 있음에도 UserService, UserRepository 객체를 필요로 하고, 역할과 책임을 떠넘기게 된다. 이때 의존관계가 발생하는 것이다. 내가 가지고 있는 역할과 책임을 다른 객체에게 위임하는 순간 의존성이 발생하는 것이다. 지금껏 스프링부트 프레임워크를 사용할 때 DI, 싱글톤에 대한 내용은 수 없이 들어왔다. 만약 DI 컨테이너 개념이 도입되지 않았다면, 의존관계에 있는 객체를 사용하기 위해 객체를 매번 new 키워드로 직접 생성하고 사용하는 방식으로 구현했을 것이다.

이번 포스트에선 실습 수행 구현 코드를 어떻게 구현했는지 단순히 나열하지 않고, 왜 DI 컨테이너가 필요하고 어떤 방식으로 발전되었는지를 상세히 설명하는 것을 목표로 한다.

DI 란?

DI 하면 가장 먼저 떠오르는 디자인 패턴이 싱글톤(SingleTon) 임을 스프링부트 프레임워크를 한 번이라도 공부해봤다면 알 것이다. 싱글톤으로 구현되지 않은 프레임워크라면 가령 Service 레이어 오브젝트에서 Dao, Repository 객체를 사용하기 위해 객체를 매번 직접 생성해야한다. 하지만 이 방식은 유연한 개발, 확장성을 제한하기 때문에, 인스턴스를 생성하는 책임과 사용하는 책임을 분리하자는 것이 DI 의 핵심이자 등장 이유이기도 하다. 즉, Service 는 레포지토리에 대한 인스턴스를 생성하는 책임을 없애고, 단순히 사용만 함으로써 유연성을 높이는 것이 DI 접근 방식이다.

정리하자면, DI 란 객체간의 의존관계에 대한 결정권을, 의존관계를 가지는 객체가 가지는 것이 아니라 외부의 제 3자가 담당하도록 역할을 떠넘김으로써 더 유연한 구조로 개발하는 기법이다.

step1. static 키워드 기반 싱글톤 컨테이너

static 기반의 안티패턴 컨테이너

한편 자바의 싱글톤(SingleTon) 패턴 구현 방법 6가지, Bill Pugh Solution 에서도 설명했듯이 싱글톤은 안티패턴이라고도 불리는 패턴이다. 객체지향적이지 못하다는 의견이 분분하다. 이때 말하는 싱글톤은 static 키워드를 기반으로 구현한 경우에 해당한다.

static 키워드를 사용하면 변화에 유연하게 대응하기 힘들다. static 메소드를 사용하는 부분에서 요구사항이 변경된다면 모든 코드도 변경되어야 한다. 즉 static 키워드에 기반하여 컨테이너를 구현할 경우 DIP, OCP 등의 원칙을 위반하게 된다.

static 기반의 싱글톤 컨테이너 구현은 아래와 같은 단점이 있다.

(1) 테스트의 어려움 : 싱글톤 패턴으로 구현된 클래스와 의존관계를 가지는 경우 해당 클래스와 강한 의존관계를 가지기 때문에 테스트하기 어렵다.

(2) 상속 불가능 : getInstance( ) 와 같은 메소드로 정적 팩토리 메소드를 만들고 생성자를 Private 으로 감추기 떄문에, 싱글톤으로 구현된 클래스를 상속할 수 없다.

(3) OCP, DIP 위반 : 유연한 확장이 불가능하디. 클래스간의 강한 의존관계가 발생하여, 한 객체의 변화가 발생할 경우 다른 의존 객체에서도 변화가 발생한다.

예를들어 아래와 같은 UserController, UserService, UserDao 가 있다고 해보자. 둘 다 static 기반의 싱글톤으로 구현된 클래스다.

public class UserController extends AbstractConntoller {
  private UserService userService = UserService.getInstance(UserDao.getInstance());

  // ...
}

public class UserService {
  private static UserService userService;

  private UserDao userDao = UserDao.getInstance();

  private UserService() {
  }

  private static UserService(UserDao userDao) {
    this.userDao = userDao;
  }

  public static UserService getInstance(UserDao userDao) {
    if(userService == null) {
      userService = new UserService(userDao);
    }
    return userService;
  }

  // ...
}

public class UserDao {
    private static UserDao userDao;
    private JdbcTemplate jdbcTemplate = JdbcTemplate.getInstance();

    private UserDao() {
    }

    public static UserDao getInstance() {
        if (userDao == null) {
            userDao = new UserDao();
        }
        return userDao;
    }

    public void insert(User user) {
        String sql = "INSERT INTO USERS VALUES (?, ?, ?, ?)";
        jdbcTemplate.update(sql, user.getUserId(), user.getPassword(), user.getName(), user.getEmail());
    }

    // ...

위와 같은 코드는 테스트하기 쉬울까? 위 코드의 모든 로직들이 원활히 수행되는지 알기위해 테스트 코드를 작성하는 것을 가정해보자. 이때 나는 데이터베이스에 의존하지 않고 테스트를 진행하고 싶다. 즉, 데이터베이스와의 의존관계 없이 독립적으로 테스트를 진행하고 싶다.

하자만 막상 UserDao 코드를 보면 데이터베이스와의 의존관계가 발생하고 있다. 따라서 UserDao 가 데이터베이스와 의존관계를 가지지 않도록 코드를 변경해야지 데이터베이스에 의존하지 않는 테스트가 가능하다. 이를위해 코드를 어떻게 수정해야할까?

고민1. UserDao 를 상속한다.

UserDao 를 상속한 클래스를 하나 만들어서 메소드를 오버라이드 하면 될 것이다. 하지만 UserDao 에 대한 생성자를 싱글톤 패턴을 적용하면서 private 으로 구현했기 때문에 상속이 불가능하다.

고민2. 생성자를 protected 로 변경한다.

그렇다면 private 메소드를 protected 로 변경하는 것을 생각해볼 수 있다. 하지만 이는 싱글톤 패턴 구현 방식에 어긋난다.

step2. 인터페이스를 통한 유연한 확장으로 개선

위 고민1, 고민2 으로는 싱글톤 구현, 유연한 확장에 제한이 있다. 이를 해결하기 위한 해결안은 인터페이스에 있다.

고민3. Mocking(모킹) 을 통한 의존성 해소

객체 간의 의존관계에 대한 강한 의존성을 줄이기 위해 인터페이스를 적용해보자. 기존 UserDao 에 대한 추상화 타입인 인터페이스를 하나 적용하면 유연한 확장이 가능해질 것으로 기대된다.

이에 대한 개선된 코드는 아래와 같다.

public interface UserDao {
  // ...
}

public class MockUserDao implements UserDao {
  private Map<Long, User> users = Maps.newHashMap(); // In-Memory DataBase

  @Override
  public void insert(User user) {
    users.put(user.getId(), user);
  }

  // ...
}

기존 UserDao 클래스 이름을 JdbcUserDao 로 변경하고, 이에 대한 추상화 인터페이스를 UserDao 로 구현했다. 또한 테스트 작성을 위한 Mock 객체를 위처럼 MockUserDao 로 구현할 수 있다. MockUserDao 는 Map 을 활용한 인메모리 데이터베이스를 활용하기 때문에, 실제 데이터베이스와 의존성이 발생하지 않았다.

이로써 데이터베이스와 의존관계를 가지지 않음을 확신을 가지며 아래 테스트 코드를 수행한다.

public class UserDaoTest {
  private UserService userService;
  private MockUserDao userDao;

  @Before
  public void setUp() {
    userDao = new UserDao();
    userService = UserService.getInstance(userDao);
  }

  @Test
  public void deleteUser() throws Exception {
    User user = new User();
    userDao.insert(user);
    userService.deleteUser();
  }
}

예상처럼 테스트 코드는 원활히 수행될 것이다. 그렇다면 위처럼 인터페이스 기반 테스트 코드는 앞서 언급한 3가지 단점을 보완했을까? 우선 (2) 상속의 어려움 을 먼저 생각해본다면, 이는 다행히 해결되었다고 볼 수 있을것이다. Dao 테스트 작성을 위해 Dao 를 상속한 메소드가 필요했는데, 이를 대체할 모킹(Mocking) 클래스를 생성했기에 가능하다.

하지만 (1) 테스트의 어려움 이 온전히 해결되었다고 볼 수 있을까? 아직 모호하다. 테스트를 위해 Mock 객체를 매번 구현해야 하는 것은 꽤 많은 비용이 들고 번거로운 작업이다. 즉, 순수히 싱글톤 패턴으로 구현하면 테스트에 어려움이 발생한다.

step3. 싱글톤 패턴을 제거한 DI

위처럼 싱글톤 패턴으로 구현할 경우 많은 문제점을 결코 해결할 수 없음을 살펴봤다. 싱글톤 패턴을 활용하는 경우 싱글톤 패턴으로 구현된 클래스와 의존관계를 가지는 경우 해당 클래스와 강한 의존관계를 가지기 떄문에 테스트하기 어렵다.

또한 어떤 형태로던 억지로 테스트가 가능하겠지만, 위처럼 매번 Mock 객체를 구현해야 하는 것은 많은 비용이 발생한다. 몰론 Junit 차원에서 Mockito 를 제공하긴 하지만, 매번 모킹을 활용한다는 그 자체의 행위는 좋아보이지 않는다. 모킹은 구현체의 내부 구현에 대해 잘 알아얄하며, 내부 구현 변경에 민감하다는 점에서 꼭 필요한 경우를 제외하곤 사용을 지양하는 것이 좋을 것이다.

LegacyHandlerMapping 에 DI 적용

HandlerMapping 에 대한 구현 코드는 어노테이션 기반 Spring MVC 프레임워크 구현하기 를 참고하자 🙂

그렇다면 싱글톤 패턴을 적용하지 않는다면 어떻게 인스턴스 하나만을 생성해 인스턴스를 재사용할 수 있을까? 이는 기존 HandlerMapping 을 리팩토링 함으로써 구현할 수 있다. 기존에 HandlerMapping 인터페이스의 구현 클래스인 LegacyHandlerMapping, AnnotationHandlerMapping 내부에선 컨트롤러에 대해 싱글톤 패턴을 적용하지 않고 싱글톤과 동일한 효과를 낼 수 있었다. (각 컨트롤러에 대한 인스턴스를 1개만 존재하도록 유일성을 보장할 수 있었으니.)

이것이 가능한 이유는 서블릿 컨테이너가 DispatcherServlet 을 초기화하는 시점에 컨트롤러 인스턴스를 생성한 후 재사용 가능하도록 구현했기 떄문이다. 이와 동일한 방식으로 인스턴스를 관리한다면 굳이 싱글톤 패턴을 적용하지 않으면서 인스턴스 하나를 재사용할 수 있게된다.

싱글톤 제거 및 리팩토링 코드

UserService 에 대한 싱글톤 패턴을 제거해보자. 싱글톤 패턴을 위한 코드를 모두 제거하고 생성자를 public 으로 전환한다.

public class UserService {
  private UserDao userDao;

  public UserService(USerDao userDao) {
    this.userDao = userDao;
  }

  // ...
}

다음은 UserController 에 대해 싱글톤을 제거했다. 아래처럼 getInstance 를 제거하고, 생성자를 public 으로 전환했다.

public class UserController extends AbstractController {
  private UserService userService;

  public UserController(UserService userService) {
    this.userService = userService;
  }

  // ...
}

마지막으로 각 컨트롤러를 생성할 때 UserService, UserDao 를 DI 로, 즉 HandlerMpaping 으로 전달하도록 수정한다.

public class LegacytHandlerMapping implements HandlerMapping {
  private Map<String, Controller> mappings = new HashMap<>();

  public void initMapping()
    UserDao userDao = new JdbcUserDao();
    UserService userService = new UserService(userDao);

    mappings.put("/user/signup", new SignUpController(userService));
    mappings.put("/user/login", new LoginController(userService));
    // ...
  }
}

이로써 싱글톤 패턴을 사용하지 않으면서 인스턴스 하나를 사용하도록 했다. 하지만 아쉬운점은, 컨트롤러 하나에서 시작해 꼬리를 꼬리를 물고 의존관계를 가지는 구조로 iniMapping() 에서 모두 구현해야한다. 만약 의존관계가 깊어진다면 initMapping() 객체간의 의존관계를 매핑해주는 작업이 매우 복잡해지기 떄문에 이 코드 또한 개선이 필요하다. 이 내용은 추후 별도로 다루겠다.

step4. 어노테이션 기반 DI 컨테이너 구현

다음으로 HandlerMapping 의 또 다른 구현체인 어노테이션 기반 AnnnotationHandlerMapping 에 대해서도 DI 컨테이너로 개선했다.

기존의 어노테이션 기반 MVC 프레임워크는 자바 리플렉션을 활용해 @Controller 어노테이션이 설정되어 있는 클래스를 찾아 인스턴스를 생성하고, URL 매핑 작업을 자동화했다. 같은 방법으로 각 클래스에 대한 인스턴스 생성 및 의존관계 설정을 어노테이션을 자동화했다.

어노테이션은 각 클래스 역할에 맞도록 @Service, @Repository 어노테이션을 추가로 설정했다. 이 3개의 설정으로 생성된 각 인스턴스간의 의존관계는 @Inject 어노테이션을 사용한다. 이 @Inject 는 스프링부트에서 제공하는 @Autowired 와 비슷한 역할을 수행한다. DI 컨테이너에 생성된 각 인스턴스는 스프링부트 프레임워크와 마찬가지로 빈(Bean) 오브젝트로 부르곘다.

BeanFactory

빈(Bean) 인스턴스를 생성하는 클래스다. instantiateClass() 와 instantiateConstructor() 두 메소드의 재귀호출을 통해 복잡한 의존관계에 있는 빈을 생성하는 과정을 완료할 수 있다. instantiateClass() 을 보면 알 수 있듯이, Bean 인스턴스를 생성하기 위해 재귀 함수로 구현했다. @Inject 어노테이션이 설정되어 있는 생성자를 통해 Bean 객체를 생성한다. 그런데 이 생성자의 인자로 전달할 빈도 다른 빈과 의존관계에 있다. 이와 같이 꼬리에 꼬리를 물고 Bean 사이에서 의존관계가 발생할 수 있다. 다른 Bean 과 의존관계를 가지지 않는 Bean 을 찾아 인스턴스를 생성할 때 까지 재귀를 실행하는 방식으로 구현했다.

재귀함수의 시작은 instantiateClass() 에서 시작하게 되는 것이다. @Inject 어노테이션이 설정되어 있는 생성자가 존재하면 instantiateConstructor() 메소드를 통해 인스턴스를 생성하고, 존재하지 않을 경우 기본 생성자로 인스턴스를 생성한다. instantiateConstructor() 메소드는 생성자의 인자로 전달할 빈이 생성되어 Map<Class<?>, Object> 에 이미 존재하면 해당 빈을 활용하고, 존재하지 않을 경우 instantiateClass() 메소드를 통해 빈을 생성한다.

public class BeanFactory {
    private static final Logger logger = LoggerFactory.getLogger(BeanFactory.class);

    private Set<Class<?>> preInstanticateBeans;

    private Map<Class<?>, Object> beans = Maps.newHashMap();

    public BeanFactory(Set<Class<?>> preInstanticateBeans) {
        this.preInstanticateBeans = preInstanticateBeans;
    }

    @SuppressWarnings("unchecked")
    public <T> T getBean(Class<T> requiredType) {
        return (T) beans.get(requiredType);
    }

    public void initialize() {
        for(Class<?> clazz : preInstanticateBeans) {
            if(beans.get(clazz) == null) {
                instantiateClass(clazz);
            }
        }
    }

    private Object instantiateClass(Class<?> clazz) {
        Object bean = beans.get(clazz);
        if(bean != null) {
            return bean;
        }

        Constructor<?> injectedConstructor = BeanFactoryUtils.getInjectedConstructor(clazz);
        if(injectedConstructor == null) {
            bean = BeanUtils.instantiate(clazz);
            beans.put(clazz, bean);
            return bean;
        }

        logger.debug("Constructor : {}", injectedConstructor);
        bean = instantiateConstructor(injectedConstructor);
        beans.put(clazz, bean);
        return bean;
    }

    private Object instantiateConstructor(Constructor<?> constructor) {
        Class<?>[] pTypes = constructor.getParameterTypes();
        List<Object> args = Lists.newArrayList();
        for(Class<?> clazz : pTypes) {
            Class<?> concreteClazz = BeanFactoryUtils.findConcreteClass(clazz, preInstanticateBeans);
            if(!preInstanticateBeans.contains(concreteClazz)) {
                throw new IllegalArgumentException(clazz + "는 Bean 이 아닙니다.");
            }

            Object bean = beans.get(concreteClazz);
            if(bean == null) {
                bean = instantiateClass(concreteClazz);
            }
            args.add(bean);
        }
        return BeanUtils.instantiateClass(constructor, args.toArray());
    }

    public Map<Class<?>, Object> getControllers() {
        Map<Class<?>, Object> controllers = Maps.newHashMap();
        for(Class<?> clazz : preInstanticateBeans) {
            Annotation annotation = clazz.getAnnotation(Configurable.class);
            if(annotation != null) {
                controllers.put(clazz, beans.get(clazz));
            }
        }
        return controllers;
    }
}

BeanScanner

다음은 @Controlller, @Service, @Repository 로 설정되어 있는 빈을 찾는 BeanScanner 아래와 같이 구현했다. 또한 AnootationHandlerMapping 이 BeanFactory 를 사용할 수 있도록 개선했다. @Controller 로 설정한 빈을 조회할 수 있는 기능을 getControllers() 가 담당하게 했다.

public class BeanScanner {
    private Reflections reflections;

    public BeanScanner(Object... basePackage) {
        reflections = new Reflections(basePackage);
    }

    @SuppressWarnings("unchecked")
    public Set<Class<?>> scan() {
        return getTypesAnnotatedWith(Controller.class, Service.class, Repository.class);
    }

    @SuppressWarnings("unchecked")
    private Set<Class<?>> getTypesAnnotatedWith(Class<? extends Annotation>... annotations) {
        Set<Class<?>> preInstantiatedBeans = Sets.newHashSet();
        for(Class<? extends Annotation> annotation : annotations) {
            preInstantiatedBeans.addAll(reflections.getTypesAnnotatedWith(annotation));
        }
        return preInstantiatedBeans;
    }
}

AnnotationHandlerMapping

마지막으로 리팩토링된 AnnotationHandlerMapping 이다. BeanFactory 를 초기화한 후 @Controller 로 설정한 빈을 사용하도록 구현했다.

public class AnnotationHandlerMapping implements HandlerMapping {
    private static final Logger logger = LoggerFactory.getLogger(AnnotationHandlerMapping.class);

    private Object[] basePackage;

    private Map<HandlerKey, HandlerExecution> handlerExecutions = Maps.newHashMap();

    public AnnotationHandlerMapping(Object... basePackage) {
        this.basePackage = basePackage;
    }

    public void initialize() {
        BeanScanner scanner = new BeanScanner(basePackage);
        BeanFactory beanFactory = new BeanFactory(scanner.scan());
        beanFactory.initialize();
        Map<Class<?>, Object> controllers = beanFactory.getControllers();
        Set<Method> methods = getRequestMappingMethods(controllers.keySet());
        for (Method method : methods) {
            RequestMapping rm = method.getAnnotation(RequestMapping.class);
            logger.debug("register handlerExecution : url is {}, method is {}", rm.value(), method);
            handlerExecutions.put(createHandlerKey(rm),
                    new HandlerExecution(controllers.get(method.getDeclaringClass()), method));
        }

        logger.info("Initialized AnnotationHandlerMapping!");
    }

    private HandlerKey createHandlerKey(RequestMapping rm) {
        return new HandlerKey(rm.value(), rm.method());
    }

    @SuppressWarnings("unchecked")
    private Set<Method> getRequestMappingMethods(Set<Class<?>> controlleers) {
        Set<Method> requestMappingMethods = Sets.newHashSet();
        for (Class<?> clazz : controlleers) {
            requestMappingMethods
                    .addAll(ReflectionUtils.getAllMethods(clazz, ReflectionUtils.withAnnotation(RequestMapping.class)));
        }
        return requestMappingMethods;
    }

    @Override
    public HandlerExecution getHandler(HttpServletRequest request) {
        String requestUri = request.getRequestURI();
        RequestMethod rm = RequestMethod.valueOf(request.getMethod().toUpperCase());
        logger.debug("requestUri : {}, requestMethod : {}", requestUri, rm);
        return handlerExecutions.get(new HandlerKey(requestUri, rm));
    }
}

어노테이션 적용

@Controller 에 이어서 @Service, @Repository 어노테이션을 적용한 예시 코드는 아래와 같다. 우리가 항상 스프링부트 프레임워크를 사용할 때 표시했던 어노테이션과 아주 유사한 구조를 지니며, 기능 역시 똑같이 동작한다 🙂

@Service
public class TestService {
  private TestRepository testRepository;

  @Inject
  public TestService(TestRepository testRepository) {
    this.testRepository = testRepository;
  }
  // ...
}

@Repository
public class TestRepository {
  // ...
}

마치며

이렇게 이전에 구현했던 어노테이션 기반 MVC 프레임워크 구현 코드와 DI 컨테이너 코드를 통합했다. 지금까지 구현했던 실습 미션 중에 가장 어려웠던 내용이 아닌가 싶다 🥲 아직 100% 완벽히 내 것으로 만들었다는 기분은 아니기에, 그리고 매우 유익한 내용이기 떄문에 향후 다시 한번 제대로 정리해볼까 한다. 서블릿 컨테이너, JSP 내용부터 전반 내용을 상세히 정리해 봐야겠다.

지금부터 내가 가져야 할 학습 방향성과 태도

Sat, 23 Nov 2024 00:00:00 GMT

카카오에서 주관하는 개발자 양성 과정에 참여한지 많은 시간이 지났다. 나는 훌륭한 카카오 코치님들, 최고의 동료들과 함께 성장하고 있다. 이 몰입 과정이 정말 끝나지 않았으면 하는 바람이지만, 수료까지 많은 시간이 남지 않았다. 수료까지, 아니 취업까지 난 어떻게 성장해야할까? 평소처럼 기술적인 내용을 다루지 않고, 정말 마음 편하게 짧은 회고를 해볼까 한다. 주말이기도 하고 😉

불안함과 초조함 걷어내기

내 스스로 느끼기에, 타인도 느끼기에 가장 안좋은 단점은 쉽게 불안함과 초조함을 느낀다는 점이다. 안좋은 습관도 생겼다. 자꾸 불안함을 느낄 때 마다 머리를 꼬는 버릇도 생겼다. 예전에 회고했기를, 의식적인 노력이 필요하다고 했지만 이 노력을 하지 않은것도 정말 오랜 시간이 지났다. 개발자로 살아가면서 불안과 가면 증후군, 메타인지 학습법을 가꾸는 방법 에서 회고했듯이, DMN 은 의식을 의도적으로 잠시 다른 곳으로 분산키기거나, 잠시 일상 생활에서 벗어나는 행위를 통해 극복해야 없어질 수 있다. DMN 이 켜지는 것은 성장통으로 받아들이되, 활성 빈도가 높아질수록 일상에 큰 악영향을 끼친다는 점을 다시 꼭 알아두자.

자주 생기는 불안함은 일상생활과 취업에 큰 영향을 끼치고 있었다. 불안함을 이겨내지 못한체 평일은 몰론 주말에 새벽 2시가 넘어서까지 노트북을 내려놓지 못한다. 충분한 휴식이 있어야만 평소 일상생활에 일에 집중할 수 있고, 더 빠르게 성장할 수 있다. 이를 작업하면서도 생각하고 있지만, 마음처럼 그는 쉽게 되지 않는다.

또한 불안함이 만땅인 상태에서 충동적으로 지금 문제를 급히 해결하려 시도할 때가 많다. 이는 이력서를 제출하면서 많이 느꼈던 점이다. 불합격 통보를 받고, 충분한 생각과 고민, 그리고 휴식을 거치지 않은체 곧바로 입사 지원을 하고있다. 제 3자의 입장에서 봤을때도 이 불안함은 좋지 못할 것이다. 내가 다시 한번 인지해야 할 내용은 다음과 같다.

불안함에 가득차있을 때는 의식적인 노력이 필요하는 점을 다시 꼭 기억하자. 일정한 극복 패턴이 필요하다.
불안함에 가득차 있을때 결정을 내렸던 행동 중 단 한번도 좋은 결과물이 나온적이 없다.
불안함으로 인해 충분한 휴식을 취하지 않았을 때 항상 일주일동안의 작업량은 매우 극명하게 낮다.
강제로 휴식을 취해야는 날을 주 1회이상 만든다. 이 또한 의식적인 노력이다.
불안함이 높은 상태이고, 판단력이 흐려졌다고 생각이 드는 그 즉시 결정을 뒤로 미룬다. 가장 이상적인 것은 오늘 몇 시간 뒤가 아닌, 다음날 아침이다. 아침에 기상한 나는 가장 현명한 선택을 내릴 수 있는 사람이 된다.
비슷한 맥락으로, 곧 바로 일을 절대 저지르지 말자. 최소 하루 이상의 고민 시간을 가진뒤에 결단을 내린다. 하루가 안된다면, 몇 시간이라도 시간을 가진다.
실패는 다음의 성공을 위한 소중한 자산이 된다. 끊임없이 실패하고, 성공을 위한 소중한 경험을 쌓자. 앞으로 만들어질 성공이라는 성취감을 만끽하자.
심리적인 마인드 셋 또한 성장통임을 잊지 말자. 내 감정과 심리적 압박을 유연하게 다룰 줄 아는 것 또한 성장이다.
주변에 성공하는 사람들 모두가 내가 생각한 것 보다 훨씬 많은 실패를 겪었다. 서강대 출신 30만 구독 유튜버도 58번의 서류 탈을 통보받았다.
가면 증후군을 의식적인 노력을 통해 벗겨내자. 나는 주변 사람들에게 자주 인정받았을 만큼 멋진 사람이다. 내 노력을 인정하고 사랑할 줄 알자.
스트래스를 풀 수 있는 나만의 취미가 필요하다. 확실한 취미를 찾아서 불안함을 깔끔히 제거할 수 있다.
실패는 실패한대로 둔다. 단, 그 실패가 다음 성공을 위한 도약점이 되어야한다.

훌륭한 퀄리티를 보장하는 휴식은 무엇일까?

나에게 더 일에 몰입하기 위한 휴식 방법에 대한 고민이 많았다. 취미를 만들기 위해 여러 고민이 많았다. 일과 시간이 끝나면 저녁을 먹고 밖에나가 몇 시간동안 뛰어보기도 했고, 어릴 때 즐겨했던 마인크래프트 게임을 다운로드 받아서 잠시 추억을 회상해보기도 했다. 하지만, 게임을 즐겨했던 것도 잠시일 뿐, 옛날처럼 그다지 내게 큰 재미를 가져다주지는 못했다. 운동을 나가서 열심히 조깅하는 것은 도움이 된 것은 분명하지만, 완전히 심신의 안정감을 가져다주는 것에는 도달하지 못했다. ~~(마인크래프트 8,900원에 유료 구매한거 매우 후회중이다!)~~

좋은 휴식에 대한 조건은 보통 아래 3가지와 같다고 한다.

편안: 휴식이 끝났을 때 심신의 안정을 얻을 수 있어야 한다. 휴식을 했는데도 긴장이 풀리지 않거나 되려 더 자극 받게 되는 방법들(뉴스, 공포 영화, 리그오브레전드 등의 자극적인 게임) 은 편안하지 않다.
도파민 분출과 몰입: 나 또한 이에 매우 공감되는 내용인데, 우리 뇌는 무언가에 몰입할 떄 도파민이 분출된다. 반면 인스타, 쇼츠등의 의식적이지 않고 행복하지 않은 것은 좋은 휴식이 아니다.
거리두기: 앞서 회고한 내용과 동일하다. 강제로 일에서 벗어나는 것이다. 진정한 휴식은 "일과 얼마나 거리를 두었는가" 이다. 업무 외적인 시간에도 업무를 생각해야 업무 능률이 더 향상될 것 같지만, 사실 뇌는 충분한 휴식을 가진 뇌가 더 효율적으로 일한다고 한다. 나 또한 매우 공감하는 내용이다.

앞서 회고한 내용들이 대다수 위 내용에 포함된 내용들이다. 진정한 휴식이라면 편안해야 하고, 내가 몰입할 수 있여야하며, 업무와 전혀 관련없는 것이어야 한다. 앞으로 나는 최소 주 1회이상 업무와 전혀 연관없는 취미를 가져볼까 한다. 또한 내가 재밌게 몰입할 수 있는 취미를 해보면서, 실제로 충분한 휴식이 내 성장을 얼마나 부스트 할 수 있을지 실험해볼까 한다. 글을 적다보니, 앞으로 어떤 것을 취미로 가질지 고민이 생긴다. 막연하게 당장 떠오르는 취미는 아래와 같다.

글쓰기 (현실적으로 가장 좋아하는 것. 지금도 글을 너무 재밌게 쓰고 있다. 😂)
레고 아이쇼핑 및 간단한 조립 (정말 내가 좋아했던 레고를 다시 해볼까 생각한다. 다만 너무 비싸서, 비싼건 아이쇼핑만 하고 가격이 그나마 괜찮은 건 조립해보기로.)
맛집과 좋은 카페 찾아다니기 (안그래도, 내일 판교 주변에 있는 백현동 카페거리에 가볼까 한다.)
요리 만들기 (요즘 좋은 취미가 생긴 것 같다. ~~백종원님 레시피 보면서 요리 만드는게 생각보다 너무 재밌다!~~)
복싱 (현실적으로 판교에서는 하기 힘들지만, 김포로 다시 돌아다면 시작할지도?)

유튜브만 보지 말고, 주 1회 더 생산적으로 도파민이 분출될만한 취미를 찾아 나서보자.

블로그와 코딩테스트

블로그

최근 10월 말~11월 초중순 사이, 괜히 바쁘다는 핑게로 글을 거의 발생하지 못했다. 1차 데모데이 마감기한이 얼마 남지 않았기 떄문에, 사실 그 당시 글을 발생하지 못했던 것은 어쩌면 당연하다. 핑계가 아닐 수 있다. 하지만, 글쓰기를 통해 내 성장을 이끌어내지 못했던 것은 객관적으로 자명한 사실이다.

나는 블로깅을 위해 아래 재밌는 실험을 해볼까 한다.

블로그 작성 루틴에 대한 실험이다. 나는 글을 한번 작성할 떄 제대로 이해했는지 알기 위해서 쓰지만, 간혹 남에게 더 잘보여주고 싶은 괜한 욕심도 생겨서 장문의 글을 작성할 떄도 있다. 글의 길이로 인해 포스팅 작성이 간혹 부담스럽게 느껴져서 시작을 안할떄도 있다. 그래서 나는, 한가지 실험을 해볼까한다. 글의 퀄리티, 길이를 신경쓰지 않고 주 3회 이상의 포스팅을 강제로 발행하는 것이다. 블로그를 남에게 보여주는 것에 포커싱을 맞춰야 하는 것이 아니라, 내 학습 수단을 위한 것임을 잊지 말도록 해야한다. 우선 위 방식대로 몇주간 강제로 글을 발행해본 뒤, 기존 방식과 강제적인 글 발행 방식 중에 어떤 것이 더 내 성장을 부스팅하는지 실험해보고자 한다.

코딩테스트

코딩 테스트가 가장 심각한 내 단점이다. 사실 지난번에 여러 차례 회사에서 경력직 채용 서류 합격 통보를 받았음에도 불구하고, 결국 코딩테스트에서 탈락이 되버렸다. 내가 현실적으로 가장 몰입해야 할 것은 코딩테스트이다.

코딩테스트 또한 강제성을 부여해볼까 한다. 하루 2문제, 주 12문제 이상의 알고리즘 문제를 강제로 푸는 것이다. 또한 여기에 조건을 붙여보고자 한다. 그 당일 문제가 (내 주관적인 기준하에) 쉽다고 판단되면, 2문제 이상이 아닌 여러 문제를 풀어야 그 날의 할당량이 인정되는 방식이다. 또한 알고리즘 또한 글쓰기를 통해 생각을 정교화(elaboration) 해볼까한다. 지금까지 알고리즘 풀이를 마구잡이로 블로그에 작성한다면 글을 남발한다는 생각 떄문에 작성하지 않았다. 이젠, 알고리즘 또한 중요성을 꺠달았기에 생각을 확실히 정교화해볼까 한다. 세컨드브레인 또는 새로운 기술 블로그를 개설하여 풀이 과정을 설명하는 방식으로 공부해볼까 한다. 단, 메타인지 활성화를 위해 확실히 개념을 정교화 싶은 이론은 현재 메인 블로그에 글을 작성하는 것을 고려해보자. 어떤 방식이 나에게 최적으로 성장을 부스팅할지 확정할 수 없기 떄문에, 우선 글을 작성한다는 것 그 하나만은 확실히 결정하도록 한다. 어떤 방식으로 글을 작성할지만 달라질 듯 하다.

다시 좋은 기회를 잃고싶지 않다면, 정신차리고 코딩테스트에 집중하자. 현실적으로 이제 내년 상반기 취업을 위해 준비할 수 있는 마지막 기회임을 절대 잊지말자. 내가 하고싶은 주제만 하면 안된다. 현실을 바라보자.

내가 쌓아온 정량적 지표들 정리하기, 모범 케이스 찾아보기

다시 한번 이력서를 점검하는 시간도 가져볼까 한다. 모범 사례들을 다시 한번 참고하여, 내 활동을 더 응집하여 표현해볼까 한다. 우선 당장에는, 다음주 카카오 Tech Talk 발표를 준비하고, 교육과정에서 활동한 내용들을 별도 깃허브 레포지토리를 생성하여 아카이브 해볼까 한다.

마치며

글을 적으니 역시 생각이 정리된다. 더 빠르게 성장을 부스트하기 위해, 내 생각을 잠시 정리해보는 시간을 가져보았다. 앞으로도 더 빠르게 성장할 수 있는 내가 되기위해, 꾸준히 노력해보자. 불안함의 안개를 걷어내기 위해 의식적인 노력을 하고, 충분한 휴식을 가져보자. 블로그와 코딩테스트, 이력서를 계획한대로 발전시켜보자.

[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 제 10장. 알림 시스템 설계

Fri, 22 Nov 2024 00:00:00 GMT

1단계. 문제 이해 및 설계 범위 확정

하루에 백만건 이상의 알림을 처리하는 확장성 높은 시스템을 구축하는게 쉬운 과제가 아니다. 알림 시스템이 어떻게 구현되는지에 대한 깊은 이해가 필요한 작업이다. 이에 관한 무제가 면접에 출제될 때는 보통 정해진 정답이 없고, 문제 자체가 모호하게 주어지는 것이 일반적이므로, 적절한 질문을 통해 요구사항이 무엇인지 지원자 스스로 알아내야 한다.

지원자 : 이 시스템은 어떤 종류의 알림을 지원해야 하는가?
면접관 : 푸시 알림, SMS 메시지, 그리고 이메일이다.
지원자 : 실시간 시스템이어야 하는가?
면접관 : 연성 실시간(soft real-time) 시스템이라고 가정한다. 알림은 가능한 빨리 전달되어야 하지만, 시스템에 높은 부하가 걸렸을 때 약간의 지연은 무방하다.
지원자 : 어떤 종류의 단말을 지원해야 하는가?
면접관 : ios 단말, 안드로이드 단말, 그리고 랩탑/데스크탑을 지원해야 한다.
지원자 : 사용자에게 보낼 알림은 누가 만들 수 있는가?
면접관 : 클라이언트 애플리케이션 프로그램이 만들 수도 있고, 서버 측에서 스캐줄링 할 수도 있다.
지원자 : 사용자가 알림을 받지 않도록 설정할 수도 있어야 하는가?
면접관 : 그렇다. 해당 설정을 마친 사용자는 더 이상 알림을 받지 않는다.
지원자 : 하루에 몇 건의 알림을 보낼 수 있어야 하는가?
면접관 : 천만 건의 모바일 푸시 알림, 백만 건의 SMS 메시지, 5백만 건의 이메일을 보낼 수 있어야 한다.

2단계. 개략적 설계안 제시 및 동의 구하기

ios, 및 안드로이드 푸시 알림, SMS 메시지, 그리고 이메일을 지원하는 알림 시스텥ㅁ의 개략적 설계안을 만들어보자. 이를 위해 아래 내용들을 다룬다.

알림 유형별 지원 방안
연락처 정보 수집 절차
알림 전송 및 수신 절차

알림 유형별 지원 방안

ios 푸시 알림

ios 에서 푸시 알림을 보내기 위해서는 3가지 컴포넌트가 필요하다.

(1) 알림 제공자 : 알림 요청을 만들어 애플 푸시 알림 서비스(APNS) 로 보내는 주체이다. 알림 요청을 만들려면 다음과 같은 데이터가 필요하다.
- 단말 토큰 : 알림 요청을 보내는 데 필요한 고유 식별자이다.
- 페이로드 : 알림 내용을 담은 JSON 딕셔너리이다.
(2) APNS : 애플이 제공하는 원격 서비스이다. 푸시 알림을 ios 장치로 보내는 역할을 담당한다.
(3) ios 단말 : 푸시 알림을 수신하는 사용자 단말이다.

안드로이드 푸시 알림

안드로이드 푸시 알림도 비슷한 절차도 전송된다. APNS 대신 FCM(Firebase Cloud Messaging) 을 사용한다는 점만 다르다.

SMS 메시지

SMS 메시지를 보낼 때는보통 트월리오, 넥스모 같은 제 3 사업자의 서비스를 많이 이용한다. 이런 서비스는 대부분 상용 서비스라서 이용 요금을 내야한다.

이메일

대부분의 회사는 고유 이메일 서버를 구축할 역량은 갖추고 있다. 그럼에도 많은 회사가 상용 이메일 서버를 이용한다. 그 중 유명한 서비스로 센드그리드, 메일침프가 있다. 전송 성공률도 높고, 데이터 분석 서비스도 제공한다.

연락처 수집 정보 절차

알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요하다. 사용자가 우리 앱을 설치하거나 처음으로 회원가입 하면 API 서버는 해당 사용자의 정보를 수집하여 데이터베이스에 저장한다.

데이터베이스 스키마 설계도 잘 고려해보자. user, device 라는 테이블을 설계하고, user 와 device 테이블을 1:n 관계로 매핑한다. 그리고 user 테이블에는 이메일 주소와 전화번호를 저장하고, device 테이블에는 단말 토큰을 저장한다. 한 사용자가 여러 단말을 가질 수 있고, 알림은 모든 단말에 전송되어야 한다는 점을 고려하였다.

알림 전송 및 수신 절차

우선 개략적인 설계안부터 살펴보고, 점차 최적화 해나가보자.

개략적 설계안 (초안)

1~N까지의 서비스 : 이 서비스 각각은 MSA 일 수도 있고, CronJob 일 수도 있고, 분산 시스템 컴포넌트 일 수도 있다. 사용자에게 납기일을 알리고자 하는 과금 서비스, 배송 알림을 보내려는 쇼핑몰 웹 사이트 등이 그 예시이다.
알림 시스템 : 알림 시스템은 알림 송.수신 처리의 핵심이다. 우선 1개 서버만 사용하는 시스템이라고 가정해보자. 이 시스템은 서비스 1~N에 알림 전송을 위한 API 를 제공해야 하고, 제 3자 서비스에 전달할 알림 페이로드(payload) 를 만들어 낼 수 있어야 한다.
제 3자 서비스 (서드파티 서비스) : 이 서비스들은 사용자에게 알림을 실제로 전달하는 역할을 한다. 제 3자 서비스와의 통합을 진행할 때 유의할 것은 확장성이다. 쉽게 새로운 서비스를 통합하거나 기존 서비스를 제거할 수 있어야 한다는 뜻이다. 또 하나 고려해야 할 점은, 어떤 서비스는 다른 시장에서는 사용 못 할 수도 있다는 점이다. 따라서 중국 시장에서는 제이푸시, 푸시와이 같은 서비스를 사용해야만 한다.
ios, 안드로이드, SMS, 이메일 단말 : 사용자는 자기 단말에서 알림을 수신한다.

문제점

하지만, 위 설계에는 몇 가지 문제점이 존재한다.

SPOF : 알림 서비스에 서버가 1대밖에 없다. 따라서 알림 서비스에 장애가 발생하면 전체 서비스의 장애로 이어진다.
규모 확장성 : 1대의 서비스로 푸시 알림에 관계된 모든 것을 처리하므로, 데이터베이스나 캐시 등 중요 컴포넌트의 규모를 개별적으로 늘릴 방법이 없다.
병목 발생 : 알림을 처리하고 보내는 것은 자원이 많이 필요한 작업이다. 예를들어 HTML 페이지를 만들고 서드파티 서비스의 응답을 기다리는 일은 시간이 많이 걸릴 가능성이 있는 작업이다. 따라서 모든 것을 한 서버로 처리하면 사용자 트래픽이 많이 몰리는 시간에는 시스템이 과부하 상태에 빠질 수 있다.

개략적 설계안 (개선된 버전)

문제점을 아래와 같이 개선할 수 있다.

💡 개선된 점

데이터베이스와 캐시를 알림 시스템의 주 서버에서 분리하였다.

알림 서버를 증설하고 자동으로 수평 확장(Scale Out) 이 이루어질 수 있도록 개선하였다.

메시지 큐를 이용해 시스템 컴포넌트 사이의 강한 결합을 끊었다.

각 컴포넌트의 역할

위와 같은 설계안에서 각 컴포넌트는 어떠한 역할을 수행할까?

1부터 N까지의 서비스 : 알림 시스템 서버의 API 를 통해 알림을 보낼 서비스들
알림 서버
- 알림 전송 API : 스팸 방지를 위해 보통 사내 서비스 또는 인증된 클라이언트만 이용 가능하다.
- 알림 검증(validation) : 이메일 주소, 전화번호 등에 대한 기본적 검증을 수행한다.
- 데이터베이스 또는 캐시 질의 : 알림에 포함시킬 데이터를 가져오는 기능이다.
- 알림 전송 : 알림 데이터를 메시지 큐에 넣는다. 본 설계안의 경우 하나 이상의 메시지 큐를 사용하므로 알림을 병렬적으로 처리할 수 있다.
캐시 : 사용자 정보, 단말 정보, 알림 템플릿 등을 캐싱한다.
데이터베이스 : 사용자, 알림, 설정 등 다양한 정보를 저장한다.
메시지 큐 : 시스테 컴포넌트 간 의존성을 제거하기 위해 사용한다. 다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할도 한다. 본 설계안에서는 알림의 종류별로 별도의 메시지 큐를 사용하였다. 따라서 서드파티 서비스 중 하나가 장애가 발생하더라도 다른 종류의 알림 기능은 정상 동작한다.
작업 서버 : 메시지 큐에서 전송할 알림을 꺼내서 서드파티 서비스로 전달하는 역할을 담당하는 서버

API 요청 플로우

위 컴포넌트들이 어떻게 협력하여 알림을 전송하게 될까?

API 를 호출하여 알림 서버로 알림을 보낸다.
알림 서버는 사용자 정보, 단말 토큰, 알림 설정 같은 메타데이터를 캐시나 데이터베이스에서 가져온다.
알림 서버는 전송할 알림 종류에 알맞는 이벤트를 만들어서 해당 이벤트를 위한 큐에 넣는다. 가령 ios 푸시 알림 이벤트는 ios 푸시 알림 큐에 넣어야 한다.
작업 서버는 메시지 큐에서 알림 이벤트를 꺼내고, 서드파티 서비스로 전송한다.
서드파티 서비스는 사용자 단말로 알림을 전송한다.

3단계. 상세 설계

지금까지 개략적 설계를 진행하면서 알림의 종류, 연락처 정보 수집 절차, 그리고 알림 송수신 절차에 대해 알아보았다. 이제 아래 내용들을 더 자세히 알아보자.

안정성
추가로 필요한 컴포넌트 및 고려사항 : 알림 템플릿, 알림 설정, 전송률 제한, 재시도 매커니즘, 보안, 큐에 보관된 알림에 대한 모니터링과 이벤트 추적 등
개선된 설계안

안정성

분산 환경에서 운영될 알림 시스템을 설계할 때는 안정성을 확보하기 위한 사항 몇가지를 반드시 고려해야한다.

(1) 데이터 손실 방지 : 알림이 소실되면 안된다. 알림이 지연되거나 순서가 틀려도 괜찮지만, 알림 자체가 어딘가에서 유실되면 곤란해진다. 이 요구사항을 만족하려면 알림 시스템은 알림 데이터를 데이터베이스에서 보관하고 재시도 메커니즘을 시도해야한다.
- 이를 위해 알림 로그 데이터베이스를 별도로 개설하는 것이 좋다. ios 단말을 예로들면, ios 푸시 알람 큐로 부터 작업 서버가 메시지를 전달받으면, 해당 메시지가 유실되는 일이 없도록 알림 로그 데이터베이스에 로그를 관리해야 할 것이다.
(2) 알림 중복 전송 방지 : 같은 알림이 여러번 반복되는 것을 완전히 막는 것은 가능하지 않다. 대부분의 경우 알림은 단 1번만 전송되겠지만, 분산 시스템의 특성상 간혹 같은 알림이 중복되어 전송되기도 할 것이다. 그 빈도를 줄이려면 중복을 탐지하는 메커니즘을 도입하고, 오류를 신중히 처리해야 한다. 다음은 간단한 중복 방지 로직의 사례이다.
- 보내야 할 알림이 도착하면 그 이벤트 ID 를 검사하여, 이전에 본 적이 있는 이벤트인지를 검사한다. 중복된 이벤트라면 버리고, 그렇지 않으면 알림을 발송한다.

추가로 필요한 컴포넌트 및 고려사항

알림 설정 : 사용자는 이미 너무 많은 알림을 받고 있어서 쉽게 피곤함을 느낀다. 따라서 많은 웹사이트와 앱에서는 사용자가 알림 설정을 상세히 조정할 수 있도록 하고있다. 이 정보는 알림 설정 테이블에 보관되며, 이 테이블에는 아마 다음과 필드들이 필요할 것이다.
- user_id
- channel (varchar) : 알림이 전송될 채널. 푸시 알림, 이메일, SMS 등
- opt_in (boolean) : 해당 채널로 알림을 받을 것인지의 여부

이와 같은 설정을 도입한 뒤에는 특정 종류의 알림을 보내기 전에 반드시 해당 사용자가 해당 알림을 켜 두었는지 확인해야 한다.

전송률 제한 : 사용자에게 너무 많은 알림을 보내지 않도록 하는 1가지 방법은, 한 사용자가 받을 수 있는 알림의 빈도를 제한하는 것이다. 이것이 중요한 이유는, 알림을 너무 많이 보내기 시작하면 사용자가 알림 기능을 아예 꺼버릴 수도 있기 떄문이다.
재시도 방법 : 서드파티 서비스가 알림 전송에 실패하면, 해당 알림을 재시도 전용 큐에 넣는다. 같은 문제가 계속해서 발생하면 개발자에게 통지(alert) 한다.
큐 모니터링 : 알림 시스템을 모니터링 할 때 중요한 메트릭(metric) 하나는 큐에 쌓인 알림의 개수이다. 이 수가 너무 크면 작업 서버들이 이벤트를 빠르게 처리하고 있지 못하다는 뜻이다. 그런 경우에는 작업 서버를 Scale Out 하는 것이 바람직할 것이다.

개선된 최종 설계안

초안에 비해 많은 컴포넌트와 기능이 추가되었다. (1) 알림 서버에 전송률 제한 기능이 추가 되었으며, 전송 실패에 대응하기 위해 재시도 기능이 추가되었다. (2) 전송에 실패한 알림은 다시 큐에 너호 지정된 횟수만큼 재시도한다. (3) 전송 템플릿을 사용하여 알림 생성 과정을 단순화하고 알림 내용의 일관성을 유지한다. (4) 모니터링과 추적 시스템을 추가하여 시스템 상태를 확인하고 추후 시스템을 개선하기 쉽도록 하였다.

더 학습해볼 주제 및 궁금점

메시지 전송 실패율을 낮추기 위해 재시도 메커니즘을 도입하는데, 이를 정확히 어떻게 구현할 수 있는가? (지금드는 해법은, Infrastructure 레이어에서 서드파티 호출시 예외가 터지면 @Retryable 로 재시도하는 것이다.)
왜 메시지 큐는 각 알림별로 도입해야하는가? 카프카처럼 중앙화된 메시지 큐 1대로 처리할 수는 없는가?
전송률 제한은 구체적으로 어떻게 구현할 수 있는 것인가?
모니터링 시스템을 통해 메트릭을 수집하는데, 이를 통해 어떻게 재시도 로직을 처리한다는 것인지 연관성에 대한 이해도가 더 필요하다.
데이터베이스 서버는 다중화가 필요없는가?

데이터베이스 분산 스토리지를 위한 파티셔닝과 샤딩

Thu, 21 Nov 2024 00:00:00 GMT

데이터 분산 환경의 필요성

높은 가용성과 확장성을 확보하기 위해 다양한 인덱스 생성, N+1 문제 해결등 여러 성능 튜닝을 시도할 수 있다. 하지만, 결국 단일 데이터베이스 하나에서 병목이 발생하면 시스템 전체에 성능 저하가 발생한다. 즉, SPOF(Single Point Of Failure) 로 가 발생하여 HA(High Availability) 를 확보할 수 없다. 이를위해 우리 모행 서비스에선 데이터베이스 레플리케이션을 통한 부하 분산 환경을 구축한 적이 있다. 이와 관련한 내용은 고가용성과 확장성을 위한 데이터베이스 레플리케이션(DB Replication) 에서 다룬적이 있다.

그런데, 이 레플리케이션 방법 외에도 다양한 방식으로 데이터를 분산 저장할 수 있다는 사실을 알게 되었다. 이번 포스팅에선 데이터를 분산화하여 저장하는 방법 중 파티셔닝과 샤딩에 대해 학습하도록 한다.

데이터베이스 파티셔닝

파티셔닝은 데이터베이스내의 큰 테이블이나 인덱스를 여러개의 작은 테이블(파티션) 으로 분할하는 기법이다. 이때 큰 테이블 여러 작은 단위로 쪼갰을 때, 이 작은 하나의 단위를 파티션(Partition) 이라고 한다. 큰 테이블을 여러 테이블로 나누어 저장하기 떄문에 쿼리 성능이 개선될 수 있다. 이때, 데이터는 물리적으로 여러 테이블에 분산하여 저장된다. 파티셔닝은 MySQL 에서 InnoDB 와 NDB 에서 지원하고 있지만, MyISAM 은 지원하지 않는다.

파텨셔닝은 테이블을 수직 또는 수평으로 분할하는가에 따라 수직 파티셔닝과 수평 파티셔닝으로 구분된다. 테이블을 수직과 수평으로 분할한다는 것이 무슨 뜻일까?

수직 파티셔닝 (Vertical Partitioning)

수직 파티셔닝은 한 테이블을 수직 방향으로 쪼개어, 한 테이블의 각 행을 작은 테이블 여러개에 분산시키는 방법이다. 즉, 테이블을 컬럼 기준으로 분할하여 여러개의 작은 테이블로 분할한다.

장점

자주 사용하는 컬럼만으로 구성한 작은 테이블을 만들어서 성능을 개선할 수 있다. 만약 한 테이블을 SELECT 하면 모든 컬럼들을 메모리에 올리게 될 것이다. 이 때문에 필요없는 컬럼까지 올라가서 한 번에 읽을 수 있는 ROW 의 수가 감소하게 된다. 따라서 수직 파티셔닝을 통해 필요한 컬럼만 올린다면, 훨씬 많은 수의 ROW 를 메모리에 올릴 수 있으니 성능상 이점이 된다. 또한 같은 타입의 데이터가 저장되기 떄문에 그룹화 되어서, 데이터의 응집성을 높일 수 있게된다.

단점

데이터를 찾는 과정이 복합해져서 Latency 가 증가한다.

수평 파티셔닝 (Horizontal Partitioning)

수평 파티셔닝은 말 그대로 수평으로 파티션을 생성한다. 즉, 하나의 테이블의 각 행을 다른 테이블에 분산하는 방법이다. 이 방법은 아래에서 학습해볼 샤딩(Sharding) 과 비슷한 점이 많다. 스키마를 복제한 후 샤드키를 기준으로 데이터를 분할하는 방식으로 동작한다. 다시말해, 스키마가 같은 두 데이터를 여러 작은 테이블에 분산 저장한다.

예를들어 위와 같은 User 테이블에서 유저 PK 를 샤드키로 사용하여 샤딩하기로 했다면, 0 ~ 999번 PK 를 가진 유저 정보는 샤드1에 저장하고, 1000 ~ 1999번 PK 에 대한 유저 정보는 샤드2에 저장한다.

장점

한 테이블의 데이터들을 개수 를 기준으로 나누어 분할하기 떄문에 데이터 개수가 작아진다. 따라서 인덱스의 개수도 작아지고, 성능이 개선된다.

단점

마찬가지로 데이터를 찾는 과정이 복합해져서 Latency 가 증가한다. 또한 여러 데이터베이스 서버들 중에 한 서버에 장애가 발생하면 데이터 무결성이 깨질 수 있다.

파티셔닝의 분할 기준(범위)

DBMS 는 파티셔닝에 대해 다양한 데이터 분할 기법을 제공한다. 분할은 분할 키(Partitioning Key) 를 사용한다.

List Partitioning (목록 분할)

데이터 값이 특정 목록에 포함된 경우 데이터를 분리한다. 분포도가 비슷하며, 많은 SQL 에서 해당 컬럼에 조건이 많이 들어오는 경우에 유용하게 사용된다. 위처럼 특정 지역별로 데이터를 분할할 때 사용할 수 있다.

Range Partitioning (범위 분할)

데이터를 특정 범위를 기준으로 분할할 떄 사용한다. 연속적인 숫자나 날짜를 기준으로 파티셔닝 하는 방식이다. 위처럼 1 ~ 2월, 3 ~ 4월, 5 ~ 6월, .. 으로 데이터를 분리할 떄 사용할 수 있다.

Hash Partitioning (해시 분할)

해시 함수를 사용하여 데이터를 분할하는 방식이다. 특정 컬럼의 값을 해싱하여 저장할 파티션을 선택한다. 데이터의 균등 분할하고 싶을 떄 사용할 수 있다.

공식문서에 따르면, 여러 컬럼으로 해싱하는 이 방법은 그리 권장하지 않는 방법이라고 한다. 만약 이 방법을 활용한다면, 유저 PK 처럼 유일성이 높고 데이터 분포가 고른 컬럼을 파티션 키로 선정해야 효과적이다.

Composite Partitioning (합성 분할)

위 파티셔닝 기법들 중에 여러 방식을 혼합하여 사용하는 방식이다. 단, 파티션을 나누는 기준이 너무 많아지면 파티션 개수가 너무 많아지고, 인덱스의 경합이 너무 심해져서 잘 사용하지 않는 방법이라고 한다.

데이터베이스 샤딩

샤딩은 동일한 스키마를 가지고 있는 여러 데이터베이스 서버들에 데이터를 작은 단위로 나누어 분산 저장하는 기법이다. 이때, 작은 단위를 샤드(Shared) 라고 한다. 어떻게 보면 샤딩은 수평 파티셔닝의 일종이다. 그러나 차이점은, 수평 파티셔닝의 경우 데이터를 동일한 서버에 저장하지만 샤딩은 서로 다른 서버에 분산하여 저장한다는 점이다. 따라서 쿼리 성능 개선 뿐만 아니라 부하 분산되는 효과도 얻을 수 있다. 즉, 샤딩은 데이터베이스의 Scale-Out 이다.

샤딩은 물리적으로 분산된 환경에서 사용되는 기법으로, 데이터베이스 차원이 아닌 애플리케이션 레벨에서 구현하는 것이 일반적이다. 다만, 샤딩을 플랫폼 차원에서 제공하는 시도가 많다고 한다.

샤드 키 (Shared Key)

샤드 키란 분할 된 여러 샤드중에 어떤 샤드를 선택할지 결정할 떄 사용하는 Key 값이다. 또한 이 샤드키를 어떤 방식으로 생성할지에 따라서 샤딩의 방법이 구분된다. 샤딩의 종류에는 해시 샤딩(Hash Sharding), 동적 샤딩(Dynamic Sharding), 엔티티 그룹(Entity Group) 등이 있다.

Hash Sharding

Hash Sharding 은 해시함수를 사용한 방식으로, PK 값을 나머지 연산하여 그 결과값으로 어떤 샤드에 들어갈지 결정하는 방식이다. 이 방식은 구현 자체가 샤드의 수만큼 해싱을 하면 되기 떄문에 간단하다.

다만, 총 데이터베이스 수가 고정적으로 정해져있을 때만 유용하다. 데이터베이스 개수가 줄어들거나 늘어나면 해시 함수내의 modular 값도 변경해야한다. 따라서 데이터의 재정렬이 필요하다.

Range Sharding (Dynamic Sharding)

Range Sharding 은 Dynamic Sharding 이라고도 불린다. 이 샤딩은 PK 를 범위로 지정하여 샤드를 결정하는 방식이다. 예를들어 PK 값이 1 ~ 999 번인 데이터라면 1번 샤드에 저장하며, 1000 ~ 1999번인 데이터는 2번 샤드에 저장한다. Hash Sharding 대비 데이터베이스 증설 작업에 큰 비용이 소모되지 않는다. 따라서 자주 데이터베이스가 증감할 수 있는 상황에선 Range Sharding 을 사용하는 것이 유리하다. 이 때문에 Range Sharding 은 Dynamic Sharding 이라고도 불린다.

대신 단점은, 특정 샤드에만 부하가 몰릴 위험이 있다. 예를들어 최근 게시글 조회 API 가 있다고 해보자. 최근에 작성된 게시글은 마지막 샤드에만 위치하게 될텐데, 최근 게시들을 조회하기 위해 많은 사용자들의 요청이 마지막 샤드에만 몰릴 수 있다. 따라서 부하 분산을 위해 데이터가 몰리는 DB는 다시 재 샤딩(re-sharding)하고, 트래픽이 저조한 데이터베이스는 다시 통합하는 작업이 필요할 것이다.

Entity Group

위 샤딩 기법들이 key-value 타입의 NoSQL 에 더 적합한 방식이라면, 이 방식은 RDBMS 에서 더 유리한 방식으로 쓰인다. 관계가 매핑되어 있는 엔티티들을 같은 샤드에 저장하도록 만든 방식이다. 따라서 유저가 작성한 게시글이나 댓글을 같은 샤드에서 가지고 있도록 작성할 수 있다.

따라서, 한 샤드내에서 강한 응집도를 가질 수 있다. 그 덕분에 동일한 그룹에 대한 SQL 문에 대해서 매우 빠른 응답 속도를 받을 수 있다. 하지만 다른 그룹에 대한 SQL 문에 대해서는 매우 비효율적인 방식이 될 것이다.

참고

[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 제 7장. 분산 시스템을 위한 유일 ID 생성기 설계

Thu, 21 Nov 2024 00:00:00 GMT

이번 장에서는 분산 시스템에서 사용될 유일 ID 생성기를 설계해 볼 것이다. 아마, "auto increment 속성이 설정된 관계형 데이터베이스의 기본 키를 쓰면 되지 않을까? 라고 생각할 수 있다. 하지만 분산 환경에서 이 접근법을 통하지 않을 것이다. 데이터베이스 서버 1대로는 그 요구를 충족하지 못할 뿐더러, 여러 데이터베이스 서버를 쓰는 경우에는 지연시간을 낮추기가 무척이나 힘들기 때문이다.

1단계. 문제 이해 및 설계 범위 확정

시스템 설계 면접 문제를 푸는 첫 단계는 적절한 질문을 통해 모호함을 없애고 설계 방향을 정하는 것이다. 아래는 면접관과 지원자 사이에 오갈 수 있는 질문과 답변의 예시이다.

지원자 : ID 는 어떠한 특성을 갖는가?
면접관 : ID 는 유일해야 하고, 정렬 가능해야 한다.
지원자 : 새로운 레코드에 붙일 ID 는 항상 1만큼 큰 값이어야 하는가?
면접관 : ID 의 값은 시간이 흐름에 따라 커질 테지만, 언제나 1씩 증가한다고 할 수는 없다. 다만 확실한 것은, 아침에 만든 ID 보다는 저녁에 만든 ID 가 큰 값을 갖는다는 특징이다.
지원자 : ID 는 숫자로만 구성되는가?
면접과 : 그렇다.
지원자 : 시스템 규모는 어느 정도인가?
면접관 : 초당 10,000 ID 를 생성할 수 있어야 한다.

질문을 할 때는 요구사항을 이해하고 모호함을 해소하는 데 초점을 맞추어야 한다. 위와 같은 질문을 통해, 이번 문제에 대한 답안이 만족해야 할 요구사항을 정리해보면 아래와 같다.

ID 는 유일해야 한다.

ID 는 숫자로만 구성되어야 한다.

ID 는 64비트로 표현될 수 있는 값이어야 한다.

ID 는 발급 날짜에 따라 정렬 가능해야 한다.

초당 10,000개의 ID 를 만들 수 있어야 한다.

2단계. 개략적 설계안 제시 및 동의 구하기

분산 시스템에서 유일성이 보장되는 ID 를 만드는 방법에는 여러 가지가 있다. 우리는 다음과 같은 선택지를 살펴볼 것이다.

다중 마스터 복제
UUID
티켓 서버
트위터 스노플레이크 접근법

각각의 동작 원리와 장단점을 살펴보도록 하자.

설계안1 - 다중 마스터 복제 (Multi Master Replication)

다중 데이터베이스 서버 환경에서 auto increment 를 사용하는 방법이다. 단, auto increment 의 증가량이 1이 아니라 k인 점이 일반적인 방식과 차이가 있다. k는 총 데이터베이스의 서버 대수이다.

예를들어 데이터베이스가 총 4대가 있다고 해보자. 1번 데이터베이스는 ID 값이 1, 5, 9, 13, ... 으로, 2번 데이터베이스는 2, 6, 10, 14, ... 으로, 3번 데이터베이스는 3, 7, 11, 15, ... 처럼 증가하도록 설계하면 된다.

이 방법은 다중 시스템에서 유일한 ID 를 생성할 수 있으며, 데이터베이스 수를 늘려 초당 생성할 수 있는 ID 수를 늘릴 수 있다. 하지만, 아래의 단점이 존재한다.

우선 확장성에 불리하다. 데이터베이스 수가 늘거나 줄게되면 중간에 k 값이 변경되는데, 이에 대응하는 것이 어렵다. 이미 과거의 k 값을 기준으로 생성된 ID 와 중간부터 생성될 ID 를 생각하면 확장성이 쉽지 않아 보인다. 이런 특징으로 여러 데이터 센터에 걸쳐 규모를 확장하기 어려울 것이다. 즉, 데이터베이스 수가 끝까지 최초 k 로 고정된 상황에서 쓰기 적합해보이는데, 이는 데이터베이스 수가 무조건 항상 고정되어야 한다는 특징이 보장되어야 하므로 확장성에 불리하다.

두번째로는 시간 흐름에 맞게 커짐을 보장하지 않는다는 점이다. 요구사항 중 "ID 는 발급 날짜에 따라 정렬 가능해야 한다" 가 있었다. 그런데, 이 방법에서는 2번 ID 가 1번 ID 보다 먼저 생성될 수 있다. 1번 데이터베이스보다 2번 데이터베이스에서 먼저 요청이 실행되면 발생하는 문제이다. 즉, ID 가 시간적 순서에 따라 정렬되지 않으므로 요구사항을 위반하게 된다.

설계안2 - UUID

UUI 는 정보를 유일허게 식별하기 위한 128bit 짜리 16진수이다. UUID 는 충돌 가능성이 아예 0% 라고는 못하지만, 사실상 충돌할 일이 없다고 보는것이 맞다. 만약 UUID 가 충돌 가능성이 50% 가 되기 위해선, 100년동안 초당 10억개의 ID 를 생성해내면 50% 가 된다고 한다. 즉, UUID 는 사실상 충돌할 일이 없다.

이러한 특징으로 보아, UUID 를 유일 키로 사용하명 어떨까? 서버간 조율 과정도 필요 없으므로 동기화가 필요 없고, 각 서버는 자기가 알아서 쓸 ID 를 만드는 구조이므로 규모 확장이 쉽다.

하지만, ID 는 128로 길다. 앞선 요구사항을 보면 최대 64비트로 제한된다. 또한 숫자로만 구성되어 있지도 않으며, 발급 날짜에 따라 정렬이 불가능하다.따라서 문제를 해결할 수 없다. 몰론 이러한 요구사항 및 제약사항이 없었더라면 UUID 는 꽤 괜찮은 선택지가 되었을 것이다.

설계안3 - 티켓 서버

아예 유일한 키를 생성하는 서버를 별도로 분리하는건 어떠할까? 플리커(Flicker) 라는 회사는 분산 기본 키(Distributed Primary Key) 를 생성하기 위한 방법으로 이를 택했다고 한다.

웹 서버 여러대가 auto increment 로 ID 를 생성하는 티켓 서버를 중앙 집중형으로 하나만 사용하는 것이다. 이 방법은 유일성이 보장되고, 숫자로만 구성된, 64비트로 표현 가능한, 발급 날짜에 따라 정렬 가능한 ID 를 생성할 수 있다. 성능만 갖춰진다면 초당 10,000개의 ID 를 생성할 수 있을 것이다. 구현도 굉장히 쉬울 것이다.

하지만, 이 방법은 SPOF(Single Point Of Failure) 가 된다. 티컷 서버를 중앙 집중형으로 단 1대만 사용한다. 따라서 티켓 서버 1대에서 장애가 발생하면 모든 서비스를 이용할 수 없게 된다. 이를 해결한다고 티켓 서버를 다중화해버리면, 애당초 해결하고자 했던 동기화 이슈가 다시 발생한다.

설계안4 - 트위터 스로우플레이느 접근법

앞선 방법들은 모두 요구사항을 충족하지 못한다. 트위터는 이 문제를 해결하기 위해 스노우플레이크라고 부르는 독자적인 ID 생성 기법을 만들어 해결했다.

ID 는 총 5개의 절(section) 으로 나뉜다. 절 순서대로 간략히 설명해보자면 아래와 같다.

(1) 사인(sign) 비트 : 1비트를 할당한다. 현재는 사용되지 않는다. 나중을 위해 확보해둔 비트로, 임수롸 양수를 구변하는데 사용할 수 있다.
(2) 타임스탬프(timestamp) : 41비트를 할당한다. Epoch Time 이후로 몇 밀리세컨드가 경과했는지 나타낸다. 41비트이므로 최대 69년의 시간을 표현할 수 있다. 일반적으로 Epoch Time 은 1970년 01월 01일 00시 00분 00초를 뜻한다. 그런데 트위터는 더 오래 이 ID 체계를 사용하기 위해 Epoch Time 으로 기원시각(297,616,116,518) 으로 보정해여 사용한다고 한다.
(3) 데이터센터 ID : 5비트를 할당한다. 2^5, 즉 32개의 데이터 센터를 사용할 수 있다.
(4) 서버 ID : 5비트를 할당한다. 2^5, 즉 데이터 센터별 32개의 서버를 사용할 수 있다.
(5) 일련번호 : 12비트를 할당한다. 각 서버는 ID 를 생성할 때 마다 이 일련번호를 1씩 증가시킨다. 이 값은 1ms 가 경과할 때 마다 0으로 초기화된다.

이는 요구사항을 모두 충족할까? 우선, ID 에 타임 스탬프 값을 넣어두기 때문에 시간순으로 정렬이 가능하다. 또한 데이터 센터 ID 와 서버 ID 를 사용하여 서로 다른 서버에서 같은 시각에 생성한 ID 도 충돌이 발생하지 않는다. 또한 내부적으로 일렵번호를 사용하여 같은 서버에서 생성한 ID 값 끼리도 충돌이 발생하지 않는다. 이 과정은 서버간 동기화가 필요 없기 때문에, 확장성 측면에서도 유리하다. ID 전체 길이도 딱 64비트라서 모든 요구사항을 만족한다.

4단계. 마무리

이번 장에서는 유일성이 보장되는 ID 생성기 구현에 쓰일 수 있는 다양한 전략 4가지를 학습했다. 마무리 단계에선 면접관과 함께 아래와 같은 추가 논의를 진행해볼 수 있다.

시계 동기화 : 이번 설계를 진행하면서 우리는 ID 생성 서버들이 모두 같은 시계를 사용한다고 가정했다. 하지만 이런 가정은 하나의 서버가 여러 코어에서 실행될 경우 유효하지 않을 수 있다. 여러 서버가 물리적으로 독립된 여러 장비에서 실행되는 경우에도 마찬가지이다. (시계 동기화와 관련한 추가 학습이 필요하다.)
각 절(section) 의 길이 최적화 : 예를들어 동시성이 낮고 수명이 긴 애플리케이션이라면 일련번호 절의 길이를 줄이고 타임스탬프 절의 길이를 늘리는 것이 효과적일 수도 있을 것이다.
고가용성(HA) : ID 생성기는 필수 불가결 컴포넌트이므로 아주 높은 가용성을 제공해야 할 것이다.

마치며

생각해보면, 지금 모행 서비스에서 데이터베이스 레플리케이션을 도입하고 있는데 다중 데이터베이스 서버간의 유일 ID 생성과 관련해 생각하지 못했었다. 우리 서비스에서도 이와 관련한 추가 도입이 필요할 듯 하다.

Redis Pub/Sub 을 사용한 분산 환경에서 로컬 캐시 동기화

Wed, 20 Nov 2024 00:00:00 GMT

💡 현재 포스트는 하모니 팀 기술 블로그 에 게시된 글 입니다.

분산 환경에서 로컬 캐시 동기화 문제

지난 스프링 로컬 캐시와 TTL 을 구현한 외부 서빙 API 요청 최적화 에서 다루었듯이, 우리 모행 서비스에는 로컬 캐시를 사용하여 외부 서드파티 API 호출에 대한 응답을 캐싱해두고 재사용한다. 지금까지는 단일 서버로 동작하기 떄문에 캐싱에 별 문제가 없어보인다. 그런데 만약, 우리 서비스가 향후 Scale-Out된 분산 환경이라면 로컬 캐시에 어떤 문제가 발생할까?

일반적으로 로컬 캐시는 구현이 간편하다. 스프링에서 제공해주는 @Cacheable 어노테이션만 간단히 명시하고, 기본 캐시 매니저인 ConcurrentMapCacheManager 를 제공받을 수 있다. 하지만, 만약 Scale-Out 된 분산 환경이라면 각 애플리케이션 서버가 서로 다른 캐시 데이터를 갖는 데이터 일관성 문제가 발생할 수 있다. 이를위해, 결국 Redis 와 Memcached 와 같은 글로벌 캐싱을 도입하여 한곳에서 중앙회된 캐시 데이터를 공유하는 방식으로 해결할 수 있다.

그렇다면 글로벌 캐싱을 도입했을 때는 문제점이 없을까? 글로벌 캐시 또한 문제점이 정말 많다. 우선, 글로벌 캐시는 Redis 와 Memcached 와 같이 외부 캐시 저장소를 사용하기 때문에 네트워크 I/O 비용이 발생한다. 또한 캐시에 데이터를 저장하고 꺼내올 때 직렬화와 역직렬화 비용도 발생한다. 반면 로컬 캐시는 RAM Access 비용만 발생하기 떄문에 글로벌 캐싱에 비해 매우 빠르다. 당연하게도, 직렬화와 역직렬화도 발생하지 않는다. 또한, 중앙화된 글로벌 캐싱을 사용한다면 캐시 서버가 SPOF(Single Point Of Failure) 가 되므로 HA(High Availability) 를 보장하지 못한다.

다시 처음으로 돌아가보자. 로컬 캐시의 성능은 매우 빠르기에 도입하고 싶지만, 분산 환경에서 각 캐시 서버간의 동기화 문제를 피할 수 없다. 이를 해결하기 위해선 어떻게 해야할까? 이를 해결하기 위한 방법 중 하나로, 이번 포스팅에선 Redis Pub/Sub 에 대해 간단히 학습해보도록 한다. 만약 모행 서비스가 Scale-Out 되어야 할 상황이라면, 이 Pub/Sub 구조를 적극 고려해보도록 한다.

Redis Pub/Sub

Redis 는 위치럼 Pub/Sub 기능을 제공한다. Publisher 가 특정 채널은 구독하는 Subscriber 들에게 브로드캐스킹하는 방식이다. 이를 이용하면 여러 서버간의 로컬 캐시를 동기화할 수 있을 것이다. 특정 애플리케이션 서버의 캐시가 최신화되었을 때, 그 이벤트, 즉 메시지를 다른 모든 애플리케이션 서버에 브로드캐스트 하는 방식으로 동기화시킬 수 있다.

이 Pub/Sub 구조에서는 모든 애플리케이션 서버가 Publisher 이자 Subscriber 로 동작한다. 즉, 캐시 갱신 이벤트가 발생한 애플리케이션 서버로 동작할 때는 Publisher 가 되며, 떄로는 캐시 갱신 메시지를 전달받는 입장도 되기 떄문에 Subscriber 가 되기도 한다. 그리고 한 서버의 로컬 캐시가 갱신되면 그 즉시 다른 서버에게 갱신 이벤트를 브로트캐스트 하는 방식으로 동작한다. 브로드캐스트 할 때 갱신된 캐시의 키를 메시지로 전달한다.

추가적인 상식으로만 알아두면 좋을 내용을 학습했다. Pub/Sub 에서 Redis 내부 각 채널은 이벤트를 저장하지 않는 비휘발성의 특징을 가진다는 점이다. 만약 채널에 메시지가 도착했다면, 해당 채널의 Subscriber 가 존재하지 않거나 또는 해당 Subscriber 서버에 장애가 터졌다면, 그 메시지는 휘발된다. 또한 Subscriber 는 동시에 여러 채널을 구독할 수 있다.

Redis Pub/Sub 과 Message Queue

더 찾아보니, Redis 의 메시지 브로트캐스트 방법에는 Pub/Sub 외에도 다양한 메시징 기법을 제공함을 알게 되었다. 여러 방법중 보편적으로 사용되는 메시징 기법에는 크게 Pub/Sub 와 메시지 큐(Message Queue) 이 있다. Message Queue은 Point-To-Point Channel 방식으로도 불린다. 오로지 한 Consumer 만 메시지를 수신받는 방식이다. 송신자와 수신자가 1:1로 대응되어서 데이터를 수신받는 구조이다. 또한 메시지는 큐에 저장한다. 앞서 설명했듯이 Pub/Sub 은 별다른 저장소 없이 메시지를 즉시 브로트캐스트 하지만, 메시지 큐는 큐 형태의 저장소에 메시지를 저장하므로, 메시지가 손실되지 않는다. 이러한 메시지 큐를 구현하기 위한 방식에는 Redis Lists, Redis Streams 등이 존재하는 듯 하다.

반면 Pub/Sub 은 메시지를 발생하는 Publisher 와 Subscriber 가 1:n 의 구조 를 취한다. 즉, Pub/Sub 와 Message Queue 의 차이점은 수신자가 1명인가, 또는 n명인가에 따라 다르며, 휘발성/비휘발성에도 차이점이 있다.

정리하자면, Redis Pub/Sub 은 실시간 메시징 방식이며, 모든 Subscribe 에게 브로트캐스트 해야하는 상황에 적합하다. 반면 Message Queue 는 실시간이 보장되지 않더라도 높은 신뢰성을 보장하며, 1:1 관계로 특정 Consumer 에게만 브로트캐스트 하는 방식에 적합하다. 다만, 로컬 캐시는 다른 하나의 애플리케이션 서버만이 아닌, 채널을 구독하는 모든 로컬 캐시가 동기화되어야 한다. 따라서 Redis Message Queue 방식은 도입하기에 부적합하다.

Pub/Sub 과 Producer/Consumer 의 차이점

또한 Pub/Sub 과 Producer/Consumer 는 서로 거의 비슷한 개념인 것 처럼 보이지만, 엄연히 다른 개념이다. Pub/Sub 모델은 특정 채널에 Publisher 가 메시지를 발행하면 그 채널을 구독하고 있는 모든 Subscriber 에게 메시지를 브로드캐스트한다. 즉, 모든 Subscribe 가 메시지를 수신한다.

반면, Producer/Consumer 모델은 Producer 가 한번 발행한 메시지를 가정 먼저 Consume 한 Consumer 만 해당 메시지를 읽을 수 있다. 즉, 작업이 한번만 실행되도록 하고 싶을 떄 사용한다. 이는 앞서 말한 Message Queue 방식이 이 Producer/Consumer 로 동작한다.

분산환경 로컬 캐시 동기화 구현

백문이불여일타. 지금부터 스프링 애플리케이션에서 Redis Pub/Sub 을 사용하여 로컬 캐시를 동기화하는 간단한 실습을 진행해보자. 이론적으로만 학습한 Redis Pub/Sub 을 스프링 애플리케이션에서 어떻게 사용하는지 간단히 파악하는 것이 목적으므로, 깊이 파고들지는 않도록 한다. Redis 와 Spring Data Redis 의 깊이있는 학습은 시간이 될 때 해보도록 한다. 실습 환경은 아래와 같이 구성했다.

Redis 서버 1대를 띄웠다.
스프링부트 애플리케이션 서버 4대를 띄웠다.
캐시 매니저로 스프링 기본 캐시 매니저인 ConcurrentMapCacheManager 를 사용한다.

@Entity
@Getter
@NoArgsContructor
public class Book {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;
}

캐시를 위한 캐시 매니저를 아래와 같이 등록해준다.

@EnableCaching
@Configuration
public class LocalCacheConfig {
    @Bean
    public CacheManager cacheManager() {
        return new ConccurrentMapCacheManager();
    }
}

RedisConfig

Redis 를 위한 설정을 진행했다. (1) Lettuce 를 사용하기 위해 LettuceConnectionFactory 팩토리 메소드를 생성했다. 이렇게 주입된 스프링 빈 오브젝트는 Redis 와 연결을 한다. (2) 그리고 RedisMessageListenerContainer 는 Subscriber 가 특정 채널을 구독하도록 만들며, 이따 살펴볼 Subscriber 클래스의 MessageListener 인터페이스를 구현한 클래스인 RedisSubscriber 를 메시지 리스너(메시지를 구독하는 자)로 등록하고 관리한다. 이들에 대한 더 자세한 이론은 추가적인 학습이 필요하다.

@Configuration
public class RedisConfig {
    @Value("${spring.data.redis.host}")
    private String redisHost;

    @Value("${spring.data.redis.port}")
    private int redisPort;

    @Bean // (1)
    public LettuceConnectionFactory connectionFactory() {
        return new LettuceConnectionFactory(redisHost, redisPort);
    }

    @Bean // (2)
    public RedisMessageListenerContainer redisMessageListener(LettuceConnectionFactory lettuceConnectionFactory) {
        RedisMessageListenerContainer conatiner = new RedisMessageListenerConatiner();
        container.setConnectionFactory(lettuceConnectionFactory);
        return container;
    }

    @Bean // (3)
    public RedisTemplate<String, Object> redistTemplate() {
        RedisTemplate<String, Object> redisTemplate = new RedisTemplate();
        redisTemplate.setConnectionFactory(connectioFactory());
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        redisTemplate.setValueSerializer(new Jackson2JsonRedisSerializer<>(Book.class));
        return redisTemplate;
    }
}

Publisher, Subscriber 정의

아직 Publisher, Subscriber 에 대한 정의가 없다. 앞서 Redis 에 메시지를 발행하기 위한 기본 커넥션을 설정을 진행했으니, 이젠 Pub, Sub 에 대한 행위(Action) 에 대해 정의 해보자.

RedisPublisher

메시지를 발행하는 주체, 즉 Publisher 에 대해 정의를 해준다. publish() 를 보면 외부로부터 전달받은 채널에 Book 타입의 메시지를 발행한다. 이때 채널명은 애플리케이션 Service Layer 로 부터 전달받도록 한다. 그리고 RedisTemplate 에서 제공하는 convertAndSend() 를 사용하여 Book 타입의 메시지를 채널에 발행하도록 동작한다.

@Service
public class RedisPublisher {
    private final RedisTemplate<String, Object> redisTemplate;

    public RedisPublisher(final RedisTemplate<String, Object> redisTemplate) {
        this.redisTemplate = redisTemplate;
    }

    public void publish(ChannelTopic topic, Book message) {
        redisTemplate.convertAndSend(topic.getTopic(), message);
    }
}

실제로 아래 Service Layer 코드를 살펴보자. Book 을 업데이트하는 이벤트가 발생하면, 그 이벤트를 book-channel 이라는 Redis 채널에 발행한다.

@Transactional
public void updateBook(Book book) {
    // ... (Book 엔티티에 대한 업데이트 로직)
    redisPublisher.publish(ChannelTopic.of("book-channel"), book);
}

RedisSubscriber

Subscriber 에 대한 동작을 정의해준다. 앞서 Publisher 가 book-channel 이라는 Redis 채널에 메시지를 발행했다면, 그 메시지를 Subscriber 가 어떻게 처리할 것인지 행위를 정의한다.

@Service
public class RedisSubScriber implements MessageListener {
    private final RedisTemplate<String, Object> redisTemplate;
    private final CacheManager cacheManager;

    public RedisSubscriber(final Redistemplate<String, Object> redisTemplate.
                           final CacheManager cacheManager,
                           final RedisMessageListenerContainer redisMessageListener) {
        this.redisTemplate = redisTemplate;
        this.cacheManager = cacheManager;

        ChannelTopic bookUpdateChannel = new ChannelTopic("book-channel");
        redisMessageListener.addMessageListener(this, bookUpdateChannel);
    }
}

MessageListener 인터테이스를 구현한 이 Subscriber 는 메시지 리스너(메시지를 전달받는 자) 로 등록되고, 관리된다. 앞서 RedisConfig 를 설명할 때, RedisMessageListenerContainer 를 스프링 빈으로 등록시 MessageListner 에 대한 구현체인 RedisSubscriber 를 메시지 리스너로 등록해서 사용할 수 있게 한다고 설명했었다. 이 구현체가 바로 위와 같이 정의되었다. 이 Subscriber 는 메시지가 채널에 발행될 떄 마다 onMessage() 에 정의한 대로 동작한다.

onMessage

OnMessage() 는 메시지가 발행되었을 때 항상 자동으로 호출되는 메소드이다. 즉, 발행된 메시지에 대한 행위(Action) 을 정의한다. 필자는 위처럼 CacheManager 를 사용하여, 캐시에서 변경이 발생한 특정 캐시 데이터를 무효화(invalidte) 하는 행위를 정의했다. 즉, 모든 Subscriber 서버의 로컬 캐시의 특정 캐시 데이터는 삭제(evict) 된다.

RedisMessageListenerContainer

RedisMessageListenerContainer 는 특정 채널을 구독하는 역할을 수행하도록 돕는다. MessageListner 구현체인 Subscriber 가 새로운 채널을 등록하고 메시지를 수신하도록 돕는다. 실제로 위처럼 book-channel 이라는 채널을 Subscriber 가 구독하도록 돕고있다.

스프링 애플리케이션

@Service
public class BookService {
    private final BookRepository bookRepository;
    private final RedisPublisher redisPublisher;

    @Autowired
    public BookService(final BookRepository bookRepository, final RedisPublisher redisPublisher) {
        this.bookRepository = bookRepository;
        this.redisPublisher = redisPublisher;
    }

    @Cacheable(value = "book")
    @Transactional(readOnly = true) 
    public Book findBookInfo(String name) {
        return bookRepository.findByName(name);
    }

    @Transactional
    public void updateBook(String name) {
        // ... (Book 엔티티 업데이트 로직)
        Book book = bookRepository.findByName(name);
        book.updateName(name);

        redisPublisher.publish(ChannelTopic.of("book-channel"), book);
    }
}

findBookInfo() 는 특정 Book 을 가져오는 메소드이다. @Cacheable 을 통해 캐싱한다.

updateBook() 메소드는 Book 엔티티를 업데이트 하면서, redisPublisher 를 사용하여 book-channel 채널에 메세지를 발행한다. 발행한 메시지는 앞서 정의한 RedisSubscriber 가 수신하고, 캐시를 Evict 한다.

마치며

향후 모행 서비스의 규모가 더 커지고, SPOF(Single Point Of Failure), FA(Fault Tolerance) 와 같은 문제가 발생할 것이 예상된다면 Redis Pub/Sub 을 사용한 로컬 캐시 동기화 구조를 적극 고려하고 있다. 글로벌 캐싱에 비해 여러 로컬 캐시를 통한 HA(High Availability) 를 보장하는 방식이 더 적합하다고 생각하기에, 분산 환경에서도 로컬 캐시를 웆;하면서 동기화 문제를 해결할 예정이다.

더 학습해야 할 키워드

Redis
Kafka
Spring Data Redis
직렬화/역직렬화
Producer/Consumer

참고

[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 제 3장. 시스템 설계 면접 공략법

Tue, 19 Nov 2024 00:00:00 GMT

시스템 설계 면접은 무엇을 평가할까?

시스템 설계 면접을 당황스러울 때가 많다. 널리 알려진 상품 X (유튜브, 트위치, 인스타그램 등) 을 설계해보라는 식으로 막연한 문제가 나올때도 맣다.

다행인 것은, 아무도 면접자에게 실제 시스테처럼 복잡한 요구를 하지는 않는다. 실세계에서 이용되는 시스템으 구조는 극도로 복잡하다. 그러하면, 왜 대체 시스템 설계 면접이 있는 것일까? 시스테 설계 면접은 2명의 동료가 모호한 문제를 풀기 위해 협력하여 그 해결책을 찾아내는 시뮬레이션이다. 이 문제에는 정해진 결말도 없고, 정답도 없다. 이 문제에는 정해진 결말도 없고, 정답도 없다. 최종적으로 도출될 설계안은 본인이 설계 과정에 들인 노력에 비하면 그다지 중요하지 않다.

이 면접은 면접자의 설게 기술을 시연하는 자리익, 설게 과정에서 내린 결정들에 대한 방어 능력을 보이는 자리이며, 면접관의 피드백을 건설적인 방식으로 처리할 자질이 있음을 보이는 자리인 것이다.

면접관의 입장에서는, 일차적 목표는 면접자의 능력을 평가하는 것이다. 가장 피하고 싶은 일은 면접이 매끄럽게 진행되지 않아서 충분한 시그널(signal) 을 수집하지 못한 바람에 평가 결과를 확정 지을 수 없는 상황일 것이다. 그렇다면 면접관이 시스템 설계 면접에서 찾고자 하는 것은 무엇인가?

많은 사람들이 시스템 설계 면접은 지원자의 설계 능력이 기술적 측면을 평가하는 자리일 것이라 생각할 것이다. 사실은 그 이상이다. 시스템 설계 면접이 잘 진행되면, 지원자가 협력에 적합한 사람인지, 압박이 심한 상황도 잘 해쳐 나갈 자질이 있는지, 모호한 문제를 건설적으로 해결할 능력이 있는지 등을 살펴볼 수 있다. 좋은 질문을 던질 능력이 있는지도 살펴볼 수 있다.

훌륭한 면접관은 부정적 신호(red flag) 도 놓치지 않는다. 설계의 순수성에 집착한 나머지, 팀원과 타협하여 결정하는 것을 등한시하고 과도하게 오버 엔지니어링을 하게되는 개발자들이 현업에도 많다. 그런 엔지니어들은 과도한 엔지니어링의 결과로 시스템 전반의 비용이 올라간다는 사실을 알아채지 못하는 일이 많은데, 그 결과로 상당수 회사들은 값비싼 대가를 치르고 있다. 우리는 면접관에게 이런 엔지니어들과 같은 경향이 있다는 것을 보이면 안된다. 이것 이외의 부정적 신호로는 완고함, 편협함 같은 것들도 있다.

효과적 면접을 위한 4단계 접근법

시스템 설계 면접은 전부 제각각이다. 훌륭한 설계 면접은 정해진 결말도 없고 정답도 없다. 하지만 그 절차나 범위에는 공통적인 부분이 있다.

1단계. 문제 이해 및 설계 범위 확정

바로 답부터 들이밀지 마라. 속도를 늦추고, 깊이 생각하고 질문하여 요구사항과 가정들을 정확히 파악하라.

시스템 면접을 볼 떄는 생각없이 바로 답을 내서는 좋은 점수를 받기 어렵다. 요구사항을 완전히 이해하지 않고 답을 내놓은 행위는 아주 엄청난 감점 요소이다. 면접은 퀴즈 쇼가 아니며, 정답 따위는 없다는 걸 상기하자.

그러니 바로 답부터 들이밀지 마라. 속도를 늦춰라. 깊이 생각하고 질문하여 요구사항과 가정들을 분명히 하라. 이 단계의 중요성은 강조하고 또 강조해도 모자람이 없다. 엔지니어인 우리에게는 어려운 문제를 풀고 최종 설계를 바로 내놓고 싶은 욕구가 있다. 하지만 그러면 잘못된 시스템을 설계할 가능성이 높아진다. 엔지니어가 가져야 할 가장 중요한 기술 중 하나는 올바른 질문을 하는 것, 적절한 가정을 하는 것, 그리고 시스템 구축에 필요한 정보를 모으는 것이다.

질문을 던지면 면접관은 우리가 질문에 대한 답을 바로 내놓거나, 아니면 우리 스스로 어떤 가정을 하기를 요구할 것이다. 후자의 경우(스스로 가정하기) 에는 그 가정을 화이트보드다 종이에 적어두어야 한다. 나중에 필요해질 때가 있어서다. 그렇다면 어떤 질문을 해야하나? 요구사항을 정확히 이해하는데 필요한 질문을 하라. 예를들어 아래와 같은 질문을 해볼 수 있다.

💡 요구사항을 정확히 이해하기 위해 필요한 질문 예시

구체적으로 어떤 기능들을 만들어야 하나?

제품 사용자 수는 얼마나 되나?

회사의 규모는 얼마나 빨리 커지리랄 예상하나? 3달, 6달, 1년뒤의 규모는 얼마나 되리라 예상하는가?

회사가 주로 사용하는 기술 스택은 무엇인가? 설계를 순화하기 위해 활용할 수 있는 기존 서비스로는 어떤 것들이 있는가?

예제 (1단계)

뉴스 피드 시스템을 설계하라는 요구를 받았다고 해보자. 요구사항을 분명히 하기위한 질문을 던져야 할 것이다. 우리와 면접과 사이에 오갈 대화는 다음과 비슷할 것이다.

지원자 : 모바일 앱과 웹 앱 가운데 어느 쪽을 지원해야 하나요? 아니면 둘 다일까요?
면접관 : 둘 다 지원해야 합니다.
지원자 : 가장 중요한 기능은 무엇인가요?
면접관 : 새로운 포스트를 올리고, 다른 친구의 뉴스 피드를 볼 수 있도록 하는 기능입니다.
지원자 : 이 뉴스 피드는 시간 역순으로 정렬해야 하나요? 아니면 다른 특별한 정렬 기준이 있습니까? 제가 특별한 정렬 기준이 있느냐고 묻는 이유는, 피드에 올라갈 포스트마다 다른 가중치가 부여되어야 하는지 알고 싶어서 입니다. 가령 가까운 포스트가 사용자 그룹에 올라가는 포스트보다 더 중요하다거나요.
면접관 : 문제를 단순하게 만들기 위해, 일단 시간 역순으로 정렬된다고 가정합시다.
지원자 : 한 사용자는 최대 몇 명의 사용자와 친구를 맺을 수 있나요?
면접관 : 5000명입니다.
지원자 : 사이트로 오는 트래픽 규모는 어느 정도입니까?
면접관 : DAU 기준 1천만명입니다.
지원자 : 피드에 이미지나 비디오도 올라올 수 있나요? 아니면 포스트는 그저 텍스트입니까?
면접관 : 이미지나 비디오 같은 미디어 파일로 포스트 할 수 있어야 합니다.

지금까지 우리가 면접관에게 던질 수 있는 질문 사례를 살펴보았다. 요구사항을 이해하고 모호함을 없애는 게 이 단계에서 가장 중요하다는 것을 명심하자.

2단계. 개략적인 설계안 제시 및 동의 구하기

이번 단계에서 초점을 맞춰야 할 것은 개략적인 설계안을 제시하고 면접관의 동의를 얻는 것이다. 이 과정은 면접관과 협력하며 진행하면 좋다.

(1) 설게안에 대한 최초 청사진(아키텍처 설계를 문서화한 기술 도면) 을 제시하고 의견을 구하라. 면접관을 마치 팀원인 것처럼 대하라. 훌륭한 면접관들은 지원자들과 대화하고 설계 과정에 개입하기를 즐긴다.
(2) 화이트보드나 종이에 핵심 컴포넌트를 포함하는 다이어그램을 그려라. 클라이언트(모바일/웹), API, 웹 서버, 데이터 저장소, 캐시, CDN, 메시지 큐 같은 것들이 포함될 수 있다.
(3) 이 최초 설계안이 시스템 규모와 관게된 제약사항들을 만족하는지를 개력적으로 계산해보아라. 계산 과정은 소리내어 설명하라. 아울러, 이런 개략적 추정이 필요한지는 면접관에게 미리 물어보도록 하자.

가능하다면 시스템의 구체적 사용 사례도 몇 가지 살펴보자. 개력적 설계안을 잡아 나가는데 도움이 될 것이다. 미처 고려하지 못한 엣지 케이스를 발견하는데도 도움이 될 것이다.

이 단계에서 "API 엔드포인트나 데이터베이스 스키마도 보야아 하는가?" 이는 질문에 따라 다르다. 가령 "구글 검색 엔진을 설계하라" 와 같은 큰 규모의 설계 문제라면 이 단계에서 다루기에는 지나치게 세부적인 내용일 것이다. 멀티 플레이어 포커 게임의 백엔드를 설게하라는 질문이라면 괜찮을 것이다. 면접관의 의견을 물어보아라.

예제 (2단계)

"뉴스 피드 시스템을 설게하라" 라는 질문을 그대로 활용하여, 개략적 설계는 어떻게 만들어 내는지 살펴보겠다. 시스템이 실제로 어떻게 동작하는지 지금 당장 이해할 필요는 없다. (상세한 내용은 본 서적의 11장에서 다룬다고 한다.)

개략적으로 살펴보자면 이 설계는 2가지의 처리 플로우(flow) 로 나누어 생각해볼 수 있다. 피드 발행과 피드 생성이 2가지이다.

피드 발행 : 사용자가 포스트를 올리면 관련된 데이터가 캐시/데이터베이스에 기록되고, 해당 사용자의 친구 뉴스 피드에 뜨게된다.
피드 생성(조회) : 어떤 사용자의 뉴스 피드는 해당 사용자 친구들의 포스트를 시간 역순으로(최신 포스트부터 오래된 포스트 순으로) 정렬하여 만든다.

3단계. 상세 설계

이 단계로 왔다면 우리는 면접관과 아래 목표들은 달성한 상태일 것이다.

시스템에서 전반적으로 달성해야 할 목표와 기능 범위 확인
전체 설계의 개략적 청사진 마련
해당 청사진에 대한 면접관의 의견 정취
상세 설계에서 집중해야 할 영역들 확인

이제 면접관과 해야할 일은 실제 대상 컴포넌트 사이의 우선순위를 정하는 것이다. 어떤 면접에서는 면접관이 우리에게 집중 했으면 하는 영역을 알려 주기도 한다. 반면 어떨 때는, 특히 선임급 개발자 면접이라면, 시스템의 성능 특성에 대한 질문을 던질 것이고, 그 경우 질문 내용은 시스템의 병목 구간이나 자원 요구량 추정치에 초점이 맞춰져 있을 것이다. 대부분의 경우 면접관은 우리가 특정 시스템 컴포넌트들의 세부사항을 깊이 있게 설명하는 것을 보길 원한다.

가령 출제된 문제가 단축 URL 생성기 설계라고 해보자. 그렇다면 면접관은 우리가 그 해시 함수의 설계를 구체적으로 어떻게 설계할 것인지 듣고 싶어 할 것이다. 반면 체팅 시스템에 관한 문제였다면, 어떻게 하면 레이턴시를 줄이고 사용자의 온/오프라인 상태를 표시할 것인지를 듣고자 할 것이다.

면접 시에는 시간 관리에도 특별히 주의하자. 사소한 세부사항을 설명하느라 정작 우리의 능력을 보일 기회를 놓쳐버리게 될 수도 있다. 우리는 면접관에게 긍정적 신호를 전달하는 데 집중해야 한다. 불필요한 세부사항에 시간을 쓰지말자. 예를들어, 페이스북에서 뉴스 피드의 순위를 매기는 데 사용되는 EdgeRank 알고리즘에 대해 얘기하는 것은 바람직하지 않은데, 시간을 너무 많이 쓰게 되는데다 우리가 규모 확장 가능한 시스템을 설계할 능력이 있다는 것을 입증하는데는 도움이 되지 않는다.

예제 (3단계)

뉴스 피드 시스템의 개략적 설계를 마친 상황이라고 해보자. 그리고 면접관도 그 설계에 만족하고 있다고 해보자. 이제 2가지 중요한 용례를 보다 깊이 탐구해야 한다. (상세 설계도는 생략하겠다.)

(1) 피드 발행
(2) 뉴스 피드 가져오기

4단계. 마무리

이 마지막 단계에서 면접관은 설계 결과물에 관련된 몇 가지 후속 질문을 던질 수도 있고, 우리 스스로 추가 논의를 진행하도록 할 수도 있다. 아래의 몇 가지 지침을 활용하도록 하자.

면접관이 시스템 병목구간, 혹은 좀 더 개산 가능한 지점을 찾아내라 주문할 수 있다. 거기에 대고 우리의 설계가 완벽하다거나 개선할 부분이 없다는 답은 하지 않도록 하자. 개선할 점은 언제나 있기 마련이다. 이런 질문은 우리의 비판적 사고 능력을 보이고, 마지막으로 좋은 인상을 남길 기회이다.
우리가 만든 설계를 한번 다시 요약해주는 것도 도움이 될 수 있다. 우리의 해결책을 제시한 경우에는 특히 중요하다. 긴 면접이 끝난뒤에 면접관의 기억을 환기시켜주는 것은 효과가 있기 때문이다.
운영 이슈도 논의할 가치가 충분하다. 메트릭은 어떻게 수집하고 모니터링 할 것인가? 로그는? 시스템은 어떻게 배포해나갈 것인가?
미래에 닥칠 규모 확장 요구에 어떻게 대처할 것인지도 흥미로운 주제이다. 예를들어, 현재 설계로 백만 사용자는 능히 감당할 수 있다고 해보자. 천만 사용자를 감당하려면 어떻게 대처해야 할까?

정리

면접에서 해야할 것과 하며 안되는 것을 정리하면 아래와 같다.

해야할 것

(1) 질문을 통해 확인하라. 스스로 내린 가정이 옳다 믿고 진행하지 마라.
(2) 문제의 요구사항을 이해하라.
(3) 정답이나 최선의 답안 같은 것은 없다는 것을 명심하라. 스타트업을 위한 설계안과 수백만 사용자를 지원해야 하는 중견 깅버을 위한 설계안이 같을리 없다. 요구사항을 정확하게 이해했는지 다시 확인하라.
(4) 가능하다면 여러 해법을 함께 제시하라.
(5) 개략적 설계에 면접관이 동의하면, 각 컴포넌트의 세부사항일 설명하기 시작하라. 가장 중요한 컴포넌트부터 진행하라.
(6) 면접관의 아이디어를 이끌어내라. 좋은 면접관은 우리와 같은 팀원처럼 협력할 것이다.
(7) 포기하지 말라.

하지 말아야 할 것

(1) 전형적인 면접 문제들에도 대비하지 않은 상태에서 면접장에 기자 말라.
(2) 요구사항이나 가정들을 분명히 하지 않은 상태에서 설계를 제시하지 말자.
(3) 처음부터 특정 컴포넌트의 세부사항을 너무 깊이 설명하지 말자. 개략적 설계를 마친 뒤에 세부사항으로 나아가자.
(4) 진행 중에 막혔다면, 힌트를 정하기를 주저하지 말자.
(5) 소통을 주저하지 말라. 침묵 속에 설계를 진행하지 말자.
(6) 설계안을 내놓은 순간 면접이 끝났다고 생각하지 말자. 면접관이 끝났다고 말하기 전까지는 끝난 것이 아니다. 의견을 일찍, 그리고 자주 구하라.

시간 배분

45분의 시간이 주어진다고 가정하고, 각 단계에 어느정도 시간을 쓰는 것이 좋을까? 대략적인 추정치에 불과하니, 참고만 하자.

1단계 (문제 이해 및 설계 범위 확정) : 3~10분
2단계 (개략적 설계안 제시 및 동의 구하기) : 10~15분
3단계 (상세 설계) : 10~25분
4단계 (마무리) : 3~5분

스프링 페이지네이션에서 발생한 Latency 의 원인과 커버링 인덱스 생성을 통한 문제 해결기

Mon, 18 Nov 2024 00:00:00 GMT

💡 현재 포스트는 하모니 팀 기술 블로그 에 게시된 글 입니다.

이번 트러블슈팅 해결기는 지난 MySQL 인덱스 레인지 스캔을 통한 쿼리 성능 개선기 에 이어지는 내용입니다. 지난 인덱스 적용을 통한 쿼리 성능 개선시 발생한 문제점을 어떻게 또 다시 해결했는지를 다루는 것이므로, 지난 포스팅을 읽고오신다면 이해에 큰 도움이 될 것입니다! 😎

문제 상황

지난 MySQL 인덱스 레인지 스캔을 통한 쿼리 성능 개선기 에서 향후 출시될 플래너 API 를 위해 인덱스를 생성한 쿼리 튜닝을 시도했습니다. 실제로 그 결과 약 36.839초가 걸리던 쿼리를 약 0.023초로 크게 감축시키는 성능 개선을 성공적으로 이루어냈죠. 하지만 막상 API 를 테스트해보니, 기대와 달리 쿼리 소요시간이 간혹 길게 측정되는 문제가 발생했습니다.

실제 API 호출 응답시간

Jmeter를 사용하여 성능 테스트를 수행한 결과, 저희의 기대처럼 쿼리 튜닝이 적용된 경우에는 실제 API를 요청시 Best Case 에서 29ms 가 측정되었습니다. 또한 100명이 동시 요청시에는 평균 응답속도가 552ms 가 측정되었습니다. 이로보아, 처음에는 스프링 애플리케이션 로직이 인덱스를 제대로 타는 것으로 판단하게 되었습니다.

하지만, 문제는 상황에 따라 위처럼 소요시간이 천차만별이라는 점입니다. Best Case 에서 29ms 라는 매우 빠른 소요시간을 보이던 성능이 간혹 위치럼 긴 Latency 가 발생하고 있습니다. 이 문제는 무엇이 문제였을까요? 이와 관련한 트러블슈팅 해결과 쿼리 성능 개선기를 공유해보고자 합니다 🙂

💡 실마리 발견

SELECT name, description, created_at, start_date, end_date, created_at
FROM trip_schedule
WHERE created_at >= '2020-01-01' AND created_at <= '2020-06-01' AND is_private = false
ORDER BY created_at DESC
LIMIT 30 OFFSET 5000;

문제가 발생하는 원인을 찾기위해 이것저것을 여러 방식으로 시도해봤습니다. 단일 인덱스가 아닌 복합 인덱스를 통해 쿼리 성능 개선을 다시 시도해보기도 했고, BETWEEN 절에 들어가는 범위의 시작값과 끝값을 늘리고 줄여보면서 원인을 찾아보려고 시도했습니다.

🤔 복합 인덱스를 생성하지 않았기 떄문인가...?

처음에는 복합 인덱스를 생성하지 않았기 떄문에 쿼리가 경우에 따라 소요시간이 천차만별인 줄 알았습니다. 지난 쿼리 성능 개선기 포스팅에서 다루었듯이, 저희는 아래처럼 WHERE 절에서 사용하는 created_at 에 대해서만 인덱스를 생성했습니다. 복합 인덱스로 생성하지 않았던 이유는 지난번에 자세히 다루었으므로 여기서는 생략합니다.

SELECT name, description, created_at, start_date, end_date, created_at
FROM trip_schedule
WHERE created_at >= '2020-01-01' AND created_at <= '2020-06-01' AND is_private = false
ORDER BY created_at DESC
LIMIT 30 OFFSET 5000;

이번에는 WHERE 절에 사용되는 is_private 컬럼에 대해서도 함께 포함시킨 복합 인덱스를 생성하여 쿼리 성능 문제를 해결해보고자 했습니다. is_private 컬럼은 카디널리티 수치가 낮기 떄문에 인덱스에 포함시키지 않았던 것인데, 경우에 에따라 인덱스를 운이 좋게 잘 탄다면 성능 개선에 도움되지 않을까라는 기대를 해보았죠.

하지만 이 방법 또한 문제의 원인이 아니였습니다. WHERE 절에 걸린 모든 인덱스에 대한 복합 인덱스를 생성하더라도 성능 개선은 매우 미미한 상태였죠. 대체 무엇이 문제였을까요?

🎯 OFFSET 값이 클 때만 발생하는 문제

이렇게 여러 방법을 시도해보던 중 재밌는 점을 하나 발견했습니다. 신기하게도 맨 마지막에 OFFSET 에 들어가는 값을 늘렸다가 줄여보니, OFFSET 값에 따라서 쿼리 소요시간이 매우 다양하게 측정된다는 점입니다.

만약 OFFSET 값이 매우 작다면 앞선 테스트와 같이 50ms 의 소요시간이 측정되기도 했습니다. 반면 OFFSET 값이 매우 크다면, MySQL 실행계획을 통해 조회한 결과 지난번과 동일하게 36초가 넘는 소요시간이 비슷하게 측정되기도 하였습니다. 이로보아, 이번 쿼리 성능 저하의 주범은 OFFSET 과 관련이 있겠다는 강한 확신이 들었습니다. OFFSET 값에 따라서, 상황에 따라 테이블 풀 스캔과 비슷하게 쿼리가 인덱스를 잘 타지 않고 수행되고 있다는 강한 느낌이 들었습니다.

페이지네이션을 사용하는 플래너 API

OFFSET 은 어디서 사용되는 절일까요? 바로 페이지네이션 로직에서 사용되는 쿼리 절이랍니다. 저희 서비스에서 제공하는 플래너 API 는 페이지네이션을 사용합니다. JPA 에서 제공하는 Pageable 을 사용하여 URL 쿼리 스트링으로 전달받은 값을 기반으로 OFFSET 을 설정하게 되었습니다. 추가적으로 PageableDefault 를 사용하여 LIMIT=30 이 쿼리에 나가도록 지정해주었습니다.

@GetMapping("/search/date")
public ResponseEntity<FindPlannerPublicForCreatedAtRangeResponses> findPublicSchedulesForCreatedAtRange(
                                    @Authentication final Accessor accessor,
                                    @RequestBody final FindPublicSchedulesForRangeRequest findPlannerOrderByDateBetweenRequest,
                                    @PageableDefault(size = 30) final Pageable pageable) {
    return ResponseEntity.ok(plannerService.findPublicSchedulesForCreatedAtRange(findPlannerOrderByDateBetweenRequest, pageable));
}

위 코드를 보시다시피 플래너 API 는 페이지네이션을 사용하며, 이 페이지네이션 로직은 OFFSET 쿼리절을 사용합니다. 실제로 아래와 같이 page 옵션을 뒤에 붙여서 쿼리가 나가도록 동작합니다. 이로써 결국 이번 쿼리 성능 발생 저하의 주범은 페이지네이션을 가능성이 반확정할 수 있었습니다. 왜 대체 페이지네이션이 문제였을까요?

https://ip_address/api/planner/search/date?page=100

🧵 원인은 페이지네이션 안에 담긴 OFFSET

우리가 보통 페이지네이션(Pagnation) 처리를 위해 흔히 사용하는 LIMIT, OFFSET 방식은 어떻게 동작할까요? 페이지네이션은 맨 앞에서부터 순차대로 OFFSET 값 만큼의 모든 ROW 를 읽은 후, LIMIT 값 만큼의 ROW 를 가져오는 방식으로 동작합니다. 따라서 단순한 서비스에서는 성능상 큰 문제가 되지 않습니다. 하지만, 많은 ROW 가 저장되어 있는 상태에서 OFFSET 값을 매우 크게 설정하면 심각한 성능 저하 문제가 발생하게 됩니다. 아래 예시를 살펴봅시다.

SELECT * FROM PERSON WHERE id BETWEEN 1 and 100000 LIMIT 3 OFFSET 10; // (1)
SELECT * FROM PERSON WHERE id BETWEEN 1 and 100000 LIMIT 3 OFFSET 10000; // (2)

위 2개의 쿼리는 모두 WHERE 절에서 클러스터링 인덱스가 자동 생성된 PK 값을 통해 범위 탐색을 시도하고 있습니다. 또한 LIMIT, OFFSET 절을 통한 페이지네이션 처리를 시도하고 있죠. 둘의 가장 큰 차이점은 OFFSET 값이 다르다는 점입니다. (1) 의 경우 10번째 페이지부터 3개의 데이터를 읽어오기 위해 맨 앞에서부터 10개의 행을 거쳐서 이동해야합니다. 반면 (2) 의 경우 맨 앞에서부터 10,000개의 행을 거쳐서 이동해야합니다. 당연하게도, (1) 에 비해 (2) 가 읽어들이며 이동해야 하는 범위가 매우 크기 떄문에 성능이 더 나쁩니다. 앞서 설명했듯이, 페이징은 맨 앞에서부터 순차대로 모든 행을 읽고난 뒤에, 그제서야 LIMIT 만큼의 행을 가져오는 방식으로 동작하기 떄문이죠.

Random I/O 가 발생하는 페이지네이션

이전 포스팅에서 다루었듯이, 저희는 created_at 에 대해서만 단일 인덱스를 생성하였습니다. 하지만 이렇게 인덱스를 생성할 경우의 문제점은, 커버링 인덱스가 아니기 때문에 Random I/O 가 발생한다는 점입니다.

SELECT name, description, created_at, start_date, end_date, created_at
FROM trip_schedule
WHERE created_at >= '2020-01-01' AND created_at <= '2020-06-01' AND is_private = false
ORDER BY created_at DESC
LIMIT 30 OFFSET 5000;

MySQL 의 LIMIT 절의 특성은, LIMIT 절에서 필요한 레코드 건수만 준비되며 즉시 쿼리를 종료한다는 것입니다. 하지만, 커버링 인덱스를 생성하지 않는 일반적인 모든 조회 쿼리는 LIMIT - OFFSET 을 수행할 때 실제 레코드에 접근하는 Random I/O 가 발생합니다. 즉, 커버링 인덱스로 처리할 수 없는 조회 쿼리는 테이블의 실제 레코드를 맨 처음부터 OFFSET 값 만큼의 모든 레코드를 읽어야합니다. 위 쿼리의 경우 5,000건의 실제 레코드를 읽는 Random I/O 가 발생합니다. 그렇게 읽은 5,000건의 데이터는 모두 버리고 마지막 30건만 사용자에게 결과값을 반환하게 됩니다. 즉, OFFSET의 수치가 커질수록 Random I/O 의 발생횟수는 비례해서 증가하고, 이 떄문에 상당히 오랜 시간이 걸리게 되는 것입니다.

커버링 인덱스 vs 커서 기반 페이징

이를 해결하기 위한 대표적인 2가지 방법이 존재합니다. 하나는 (1) 커버링 인덱스를 생성하여 Random I/O 를 제거하는 방식이고, 다른 하나는 (2) 커서 기반 페이징 기법을 적용하는 것입니다. 일반적으로 권장하는 방법은 (2) 방식읕 커버 기반 페이징 방식입니다. 이 커버 기반 페이징 방식이란 무엇일까요?

커버 기반 페이징 (Cursor Based Paging)

커버 기반 페이징 방식이란 OFFSET 키워드를 사용하지 않는 것으로, 커서 값을 클라이언트에서 매번 일일이 저장해두었다가 다음 페이지는 가져오는 방식입니다. 아래 코드는 저희의 OFFSET 기반 쿼리문을 커서 기반 페이징으로 변환한 쿼리문입니다.

SELECT name, description, created_at, start_date, end_date
FROM trip_schedule
WHERE created_at < {커서값} 
  AND created_at >= '2020-01-01'
  AND created_at <= '2020-06-01'
  AND is_private = false
ORDER BY created_at DESC
LIMIT 30;

가장 변화된 지점은 바로 WHERE 절에 ID 값이 추가되었으며, OFFSET 이 없어졌다는 점입니다. 이렇듯 커서 기반 페이징은 OFFSET 을 제거한 방식입니다. 그 대신에 단점은, 클라이언트에서 매번 일일이 어떤 지점에서부터 또 다시 다음 페이지 데이터들을 읽어들어야 할지 항상 기억하고 있어야한다는 점입니다. 이때 커서(Cursor) 란 위처럼 ID 값이 될 것입니다. 커서란 말 그대로 포인터와 같은 것으로, 한번 데이터를 LIMIT 만큼 읽어들인 뒤 또 다시 데이터를 조회하기 위해 그 위치 값을 클라이언트에서 저장하는 방식입니다.

😤 커서 기반 페이징을 도입하지 않은 이유

커서 기반 페이징은 정말 좋은 방식입니다. OFFSET 을 사용하지 않기 떄문에 쿼리 성능이 매우 빨라진다는 점이 존재하죠. OFFSET 방식에서는 원하는 소량의 데이터를 읽기 위해 OFFSET 가 커질수록 불필요하게 Random I/O 가 많이 발생한다는 치명적인 문제점이 존재했습니다. 반면, 커서 기반 페이징은 LIMIT 만큼에 대해서만 Random I/O 가 발생하므로, 성능 저하를 우려할 필요가 없죠.

하지만 문제는, 커서 기반 페이징방식은 이전 페이지(커서) 값을 기준으로 다음에 읽어들일 데이터를 페이징하기 떄문에, 특정 페이지로 건너 뛰어서 넘어갈 수 없다는 한계점이 존재합니다. 즉, 커서 기반 페이징은 곧 바로 다음 페이지로만 이동 가능하다는 문제점이 존재합니다. 따라서 무한 스크롤이나 More 버튼이 있는 형태로만 페이징 기능을 사용 가능합니다.

무엇보다 저희 플래너 API 에 사용되는 쿼리에 커서로 활용될 컬럼으로 어떤 컬럼을 지정할지 모호하다 는 문제점이 존재합니다. 커서 기반 페이징은 다음에 어떤 페이지를 읽어들일지 알 수 있도록 커서 값을 클라이언트가 저장한다고 했었죠. 그런데, 만약 커서 값이 유니크(Unique) 하지 않고 중복되는 값이 존재한다면 어떤 문제가 발생할까요? 아래 쿼리를 다시 살펴봅시다.

SELECT name, description, created_at, start_date, end_date
FROM trip_schedule
WHERE created_at < {커서값} 
  AND created_at >= '2020-01-01'
  AND created_at <= '2020-06-01'
  AND is_private = false
ORDER BY created_at DESC
LIMIT 30;

보듯이 created_at 이 커서로 활용되고 있습니다. 하지만, created_at 은 플래너 여행 일정 등록날짜로, 유니크(Unique) 하다는 보장이 없습니다. 만약에 현재 커서값에 활용되는 created_at 에 2020-03-10 이 할당된 상태이고, 이 2020-03-10 이라는 중복된 값을 가지는 데이터 건수가 10개가 넘는다면 어떻게 될까요? 어쩔 수 없이 MySQL 쿼리는 그 10건의 데이터 중에 정확히 어떤 레코드부터 시작하여 LIMIT 값 만큼 읽어와야할지 알 수 없기 떄문에, 그 10건중 임의로 한 데이터를 읽어올 수 밖에 없습니다. 즉, 커서 기반 페이징에서 커서 값은 반드시 유니크(Unique) 해야 하지만, 쿼리 특성상 created_at 은 유니크하지 않으므로 문제가 발생합니다.

그렇다면 커서 값을 중복되지 않은 유니크한 컬럼을 선택하면 문제가 해결될 것입니다. 이를위해 PK 컬럼에 대해 커서로 지정해볼 수 있겠죠. 하지만, BETWEEN 절로 정렬되는 결과물의 여행 일정 리스트는 PK 를 기반으로 정렬되지 않고, created_at 을 기반으로 정렬됩니다. 즉, 위 쿼리에서 ORDER BY 절을 통해 created_at 로 정렬된 결과 리스트에서 PK 의 크기는 서로 뒤죽박죽 이라는 점입니다. 따라서 PK 는 커서로 활용할 수 없습니다. 정리하자면, 커서 기반 페이징은 특정 컬럼에 의존하여 데이터를 정렬하기 때문에, 고유하지 않은 필드로 정렬할 경우, 커서 값이 중복될 가능성이 있어 데이터가 누락되거나 중복될 수 있다는 문제점이 발생합니다.

이러한 이유로, 저희 서비스의 요구사항 특성상 커서 기반 페이징을 도입하기엔 어렵다는 결론을 내리게 되었습니다. 비슷한 이유로, 역방향 페이징도 어렵고, 클러이언트와 서버 양측 모두 커서 관리의 부담이 커지며, 커서를 자유롭게 이동하면서 여행 일정을 편하게 조회할 수 없다는 문제점이 존재하므로 도입하지 않았습니다.

🎯 커버링 인덱스를 생성한 쿼리 성능 최적화

앞서 설명했듯이, 커서 기반 페이징 또는 커버링 인덱스를 생성하여 이번 문제를 해결할 수 있다고 했습니다. 저희는 결론적으로 커서 기반 페이징 방식이 아닌 커버링 인덱스를 생성하여 쿼리 성능 문제를 해결했습니다.

커버링 인덱스는 MySQL 인덱스 레인지 스캔을 통한 쿼리 성능 개선기 에서도 다루었듯이, Random I/O 자체를 완전히 제거해버릴 수 있는 방식입니다. 커버링 인덱스란 쿼리내에 수행되는 모든 컬럼을 복합 인덱스가 모두 포함하고 있는 인덱스를 뜻한다고 했었죠. 이 경우 인덱스 이 경우 인덱스가 필요로하는 모든 데이터를 이미 가지고 있기 떄문에, 실제 레코드에 접근하여 데이터를 조회하는 랜덤 I/O 가 절대 발생하지 않습니다. 따라서 성능이 매우 빨라집니다.

쿼리 성능 문제가 발생했던 쿼리를 아래처럼 다시 살펴봅시다. 이전에는 created_at 에 대해서만 단일 인덱스를 생성해주었다면, 커버링 인덱스를 위해 이번엔 created_at 은 몰론 SELECT 절에서 사용되는 모든 컬럼을 복합 인덱스에 포함시켜 주도록 해야합니다.

SELECT name, description, created_at, start_date, end_date, created_at
FROM trip_schedule
WHERE created_at >= '2020-01-01' AND created_at <= '2020-06-01' AND is_private = false
ORDER BY created_at DESC
LIMIT 30 OFFSET 5000;

실제로 저희 팀은 아래와 같이 커버링 인덱스를 생성함으로써, OFFSET 으로 인해 발생하는 쿼리 성능 문제를 해결하였습니다. 이로써 OFFSET 으로 인해 Random I/O 가 발생하는 일을 최소할 수 있겠죠?

ALTER TABLE trip_schedule
ADD INDEX trip_schedule_covering_idx(created_at, is_private, name, description, start_date, end_date);

성능 개선 확인

성능 개선 정도를 확인하기 위해, Jmeter 를 사용하여 실제 API 의 평균 응답시간을 분석했습니다. 1초 간격으로 100번의 요청을 보내 평균 응답 시간을 냈습니다. 또한 MySQL 의 실행계획을 측정하여 순수하게 쿼리 성능이 어느정도로 개선되었는지 또한 측정하였습니다. Page 값은 임의로 약 10만을 부여하였습니다.

성능 개선 전

우선 플래너 API 호출 평균 응답시간은 4,637ms 가 측정되었네요. 심지어 간혹 Conneciton Timeout 으로 인해 애러율이 약 6.8%라는 수치가 도출되기도 했습니다. 상황에 따라 타임아웃이 발생하고, 평균 4.6초 이상이나 기다려야하는 응답시간을 받는 사용자 입장에선 큰 불편함을 느낄 수 밖에 없을 것입니다.

성능 개선 후

성능 개선 후에는 놀라운 변화가 일어났습니다. 기존 4.6초의 평균 응답식나이 522ms, 즉 0.52초라는 평균 응답시간으로 크게 개선되었습니다. 이로써 Random I/O 발생 유무 차이가 얼마나 성능에 큰 영향을 끼치는지 알 수 있죠. 페이지네이션 로직에서 커버링 인덱스를 적용한 쿼리 튜닝 방법은 API 호출에 약 8.8배 개선되었습니다.

MySQL 실제 쿼리 응답속도 또한 직접 확인한 결과, 쿼리 튜닝 후 응답속도가 17ms 가 측정되었네요. 기존 성능 개선전에 약 36.838초가 소요된것에 비해 0.017초로 극명하게 개선된 것을 확인할 수 있었습니다.

마치며

이렇게 페이지네이션에서 발생하는 OFFSET 으로 인한 쿼리 성능 이슈를 해결할 수 있었습니다. 저희 서비스 요구사항에 알맞게 커서 기반 페이징 방식과 커버링 인덱스를 통한 2가지 방식을 비교헀으며, 결국 커버링 인덱스를 통한 성능 개선을 이루어낼 수 있었습니다. 무엇보다 Random I/O 가 발생함으로 인해 발생하는 성능 저하가 생각보다 크다는 것을 이번 기회에 직접 체감할 수 있었습니다.

다만, 지금의 개선 구조는 완벽한 구조가 아니라는 점입니다. 커서 기반 페이징 방식에서도 문제점이 존재하듯이, 커버링 인덱스를 통해 쿼리 튜닝 방식 몰론 문제점이 존재하죠. 지난 포스팅에서 커버링 인덱스가 아닌 단일 인덱스를 도입했던 이유처럼, 커버링 인덱스는 무턱대고 도입하는 것이 좋은 것이 아닙니다. 결국 쿼리의 모든 항목이 포함되기 떄문에 인덱스 크키가 커질 수 있고, 아무리 커버링 인덱스가 빠르다고 한들 커버 기반 페이징 방식과 달리 소요시간이 O(n) 으로 선형적으로 증가하는 문제는 여전이 존재하긴 합니다. 다만, 그럼에도 커버 기반 페이징 방식에 비해 더 좋은 이점들도 존재하기 떄문에 커버링 인덱스를 생성하여 문제를 해결해습니다. 게다가 소요시간이 선형적으로 증가하겠지만, 큰 값을 가지는 OFFSET 이 등장한다고 한들 대부분 커버링 인덱스로 최적화되어 빠른 성능이 도출됩니다.

지금보다 더 좋은 방법이 또 있을지, 커서 기반 페이징 방식외에도 다른 방식도 존재하는지를 계속 고민해보는 시간을 가져볼까 합니다. 그럼 이만 포스팅을 마쳐보겠습니다 😎

참고

MySQL 인덱스 레인지 스캔을 통한 쿼리 성능 개선기

Fri, 15 Nov 2024 00:00:00 GMT

💡 2024.11.17 추가 : 이 포스팅에서 진행한 쿼리 성능 개선기는 스프링 페이지네이션에서 발생한 Latency 의 원인과 커버링 인덱스 생성을 통한 문제 해결기 로 이어집니다. 페이지네이션 로직에 대한 커버링 인덱스 적용기를 참고해주세요! 🙂

오랜만의 포스팅이다. 이번 포스팅에선 모행 서비스에서 SLOW QUERY 가 발생한 문제 상황을 어떻게 해결했는지에 대해 다루어보고자 한다. 데이터베이스 인덱스의 개념와 특징에 대해 다시금 곱씹어보며 어떠한 방식으로 인덱스를 적용했는지에 대한 근거를 공유해볼까 한다. 또한 우리 서비스내에 데이터베이스 인덱스를 생성한 사례 중 하나를 중점으로 자세히 다루어보고자 한다. 즉, 우리 서비스내에 생성한 인덱스 종류에는 이번 포스팅에서 다룰 인덱스 단 1가지 종류만 존재하는 것이 아니라는 것을 말하고 싶다 😎

문제 상황

우리 하모니 팀은 높은 가용성(Availability) 확보와 사용자 경험을 향상하기 위해 다양한 성능 개선을 시도하고 있다. 지금까지 데이터베이스 레플리케이션을 통한 부하 분산, 로컬 캐시를 사용한 API 요청 최적화, 톰캣 서버 튜닝, HikariCP 적절 사이즈 튜닝, N+1해결등 수많은 문제를 해결해왔다. 하지만, 결국 데이터베이스내에 대량의 데이터가 쌓인다면 여러 성능 튜닝을 했음에도 SLOW QUERY 가 발생할 수 밖에 없다.

실제로 우리 팀내에도 대량의 더미 데이터를 삽입한 뒤 쿼리 속도를 측정한 결과 Long Query 가 발생하고 있다. 이는 시스템내에 성능 저하가 발생 요인이 되며, 한 커넥션을 붙잡고 있는 시간이 길어지므로 시스템 전체에 성능 저하와 병목 현상을 일으킬 수 있다. 이 문제를 해결하기 위해 데이터베이스 인덱스 생성을 통한 쿼리 성능을 개선했다. 이번 포스팅에서 대량의 더미 데이터를 삽입한 상황속에서 인덱스를 생성한 쿼리 적용 과정, 고민 사항에 대해 다루어보고자 한다.

플래너 API 특성 파악하기

우리 서비스에서 향후 출시할 플래너 공유 기능을 구현하고 테스트를 진행하고 있다. 이 API 는 향후 커뮤니티 기능으로 출시될 플래너 공유 기능에 활용될 예정이다. 대량의 데이터중 빠르게 원하는 여행 일정(플래너)를 찾을 수 있도록 등록 날짜를 기준으로 검색하는 기능이 존재한다. 아래처럼 검색할 시작날짜와 종료날짜를 기준으로 공개된 (비공개 상태 OFF) 여행 일정을 조회할 수 있도록 지원한다.

그런데 문제는, 대량의 데이터가 삽입된 상황이라면 원하는 데이터를 찾아오는데만 36.839초 라는 매우 긴 시간이 소요된다는 점이다. 이 떄문에 실제 API 를 테스트를 해봤을 때 자꾸만 Connection Timeout 이 발생한다. HikariCP 와 데이터베이스 커넥션 풀(DBCP) 최적화 고민하기 - 이론편 에서 설명했듯이, 우리 팀의 HikariCP 커넥션 타임아웃 대기 시간 정책은 3초로 정해져있다. 3초이상 사용자를 대기시킨다면 큰 붎편함을 줄 것이라 생각했기 때문이다.

결국 사용자는 원하는 데이터를 검색해서 찾기위해 대기하는 시간만 길어지고, 데이터를 조회하지 못한 못한 상태로 Timeout 되버린다. 사용자 경험에서 정말 좋지 못하다. 이 뿐만 아니라 시스템내에 Slow Query 로 인한 커넥션 고갈이 발생하여 성능 저하의 주원인이 될 수 있다.

실제 Long Query 수행시간 측정해보기

실제로 플래너 조회 API 를 호출시 나가는 쿼리를 확인해보자. 테스트 서버내에 쌓인 데이터 건수는 아래와 같이 약 1,600만건의 더미데이터가 저장된 상황임을 가정한다.

또한 쌓인 더미데이터는 다음과 같은 특징을 지닌다.

약 1,600만건의 데이터가 저장된 상황

2020년 ~ 2023년도 사이의 등록된 데이터가 골구로 분포된 상태 (즉, 여행 일정 등록날짜가 특정 년도에만 밀집된 것이 아니라 골구로 분산되어 있다.)

이 외에도 여행 일정의 name, description 필드의 데이터끼리 100만가지 이상으로 서로 다른 값을 가진 상태 (중복되는 데이터 값을 최소화했다.)

쿼리 특성 파악하기

아래 쿼리는 WHERE 절을 통해 여행 일정 등록날짜 created_at 를 기준으로 범위내에 해당하는 여행 일정 리스트를 조회한다. 스프링부트 내에서 부하 분산을 위해 페이지네이션 로직을 적용했기 떄문에 LIMIT 과 OFFSET 이 함께 나가는 것을 확인할 수 있다. 추가적으로 WHERE 절에서 is_private 이라는 boolean 필드가 존재하여, 검색에 활용되는 것을 확인할 수 있다.

SELECT name, description, created_at, start_date, end_date, created_at
FROM trip_schedule
WHERE created_at >= '2020-01-01' AND created_at <= '2020-06-01' AND is_private = false
ORDER BY created_at DESC
LIMIT 30 OFFSET 100;

이떄 페이지네이션 적용을 통한 LIMIT 쿼리가 나간다는 점도 중요하게 볼 사항 중 하나이다. 데이터베이스 인덱스는 커버링 인덱스를 타지 않는 이상 리프 페이지의 매핑되는 실제 레코드를 읽어오기 위해 Random I/O 가 발생할 수 밖에 없다.

MySQL 에서 B+ Tree 기반 인덱스로 데이터를 스캔하는 방식 (인덱스 레인지 스캔) 에서 다루었듯이, 랜덤 I/O 는 순차 I/O 에 비해 비용이 꽤 많이 드는 작업이다. 따라서 MySQL 옵티마이저는 실제 데이터 레코드 수가 전체에서 20 ~ 25%를 넘는다면, 테이블의 인덱스를 타지 않고 레코드를 직접 읽어 순차 I/O 가 발생하는 테이블 풀 스캔(Table Full Scan) 방식을 수행하도록 쿼리를 유도한다. 따라서 페이지네이션 로직을 적용함으로써 읽어야 할 데이터 건수가 20~25% 수준을 절대 넘어가지 않고 소량의 데이터만 읽도록 하여, 항상 인덱스를 타도록 스프링부트 애플리케이션 로직을 개발했다.

위 쿼리에 대한 실제 수행시간을 확인해보면 아래와 같다. 약 1,600만건의 대량 데이터가 서비스내에 저장된 상황이라면 약 36.839초 이라는 매우 긴 시간이 소요된다. 이렇듯 데이터베이스 인덱스를 생성하지 않은 상황아라면 Slow Query 가 수행된다는 것을 알 수 있다.

데이터베이스 인덱스를 생성한 성능 개선 시도

이러한 문제 상황이 발생하므로, 데이터베이스 인덱스를 통한 Slow Query 를 제거할 필요성을 느낄 수 있다. 하지만 무턱대고 인덱스를 마구잡으로 생성한다면, 자칫 되려 성능 저하와 불필요한 공간 낭비를 일으킬 수 있기 떄문에 효율적인 적용 방안을 마련해야한다.

데이터베이스 인덱스를 생성하여 랜덤 I/O 를 최소화하기

쿼리 튜닝을 위한 HDD 와 SSD 의 순차 I/O 와 랜덤 I/O 에서 다루었듯이, 데이터베이스 쿼리 튜닝의 핵심은 Random I/O를 최소화하는 것이다. HDD 의 경우 랜덤 I/O 가 발생한다면 디스크내에 불연속적으로 위치한 데이터를 읽기위해 헤더를 이동시키는 Seek Time 이 발생한다. 이 Seek Time 횟수가 많아질 수록 성능 저허가 심해지기 떄문에 인덱스를 통한 쿼리 튜닝을 시도해볼 수 있다. SSD 또한 HDD 에 비해 빠르다고 한들, 인덱스를 통한 쿼리 성능 튜닝이 필요하다. SSD 또한 랜덤 I/O 가 순차 I/O 에 비해 성능이, 즉 처리율(throughput)이 꽤 느리다. SSD 는 물리적으로 NAND 플래시 메모리에 저장된 데이터를 직접 쓰고 읽는 것이 아니라, 내부적으로 논리주소를 매핑하는 매핑 테이블을 사용한다. 매핑 테이블을 업데이트하려면 NAND 플래시 메모리의 물리적인 메모리를 찾아갸아 하므로, 랜덤 I/O의 경우 이 과정에 추가적으로 발생하기 때문에 성능이 느리다.

인덱스의 B+ Tree 구조는 항상 정렬된 상태를 유지하기 떄문에 리프 페이지의 탐색 시작점을 빠르게 찾아낼 수 있다. 또한 리프 노드끼리 서로 링크드리스트로 연결되어 있기 떄문에, 인덱스 범위 탐색이 가능하다. (이 또한 B+ Tree 구조에서 리프 노드끼리도 서로 정렬된 상태를 구성하기 떄문에, 빠르게 범위 탐색이 가능하다.)

그렇다면 아래 쿼리에서 어떤 필드를 기준으로 인덱스를 생성해야할까? 우리 팀은 어떻게 인덱스를 적용하기 위한 고민이 있었을까? 그 고민 사항을 하나씩 소개해보곘다.

SELECT name, description, created_at, start_date, end_date, created_at
FROM trip_schedule
WHERE created_at >= '2020-01-01' AND created_at <= '2020-06-01' AND is_private = false
ORDER BY created_at DESC
LIMIT 30 OFFSET 100;

🤔 1. 커버링 인덱스를 통해 성능 개선을 시도해볼까?

💡 2024.11.17 추가 : 앞서 언급했듯이, 이 포스팅에서 진행한 쿼리 성능 개선기는 스프링 페이지네이션에서 발생한 Latency 의 원인과 커버링 인덱스 생성을 통한 문제 해결기 로 이어집니다. 페이지네이션 로직에 대한 커버링 인덱스 적용기를 참고해주세요! 🙂

일반적으로 디스크에 접근하는 그 행위 자체를 완전히 제거하고 싶다면 커버링 인덱스를 통한 성능 개선을 생각해볼 수 있다. 커버링 인덱스란 쿼리내에 수행되는 모든 컬럼을 인덱스가 모두 가지고 있는 인덱스를 뜻한다. 이 경우 인덱스가 필요로하는 모든 데이터를 이미 가지고 있기 떄문에, 실제 레코드에 접근하여 데이터를 조회하는 랜덤 I/O 가 절대 발생하지 않는다. 따라서 성능이 매우 빨라진다.

ALTER TABLE trip_schedule
ADD INDEX trip_schedule_covering_idx(created_at, is_private, name, description, start_date, end_date);

만약 워 쿼리를 위한 커버링 인덱스를 생성한다면, 위와 깉이 인덱스를 생성할 수 있다. created_at, name, description, start_date, end_date 등 SELECT 쿼리내에 요구되는 모든 필드에 대해 인덱스를 생성했다.

이렇게 된다면 모든 필드가 인덱스를 타기 떄문에 절대 디스크 랜덤 I/O 가 발생하지 않는다. 따라서 당장엔 성능이 매우 빨라진다. 하지만 데이터베이스 인덱스 B+ Tree 구조는 왜 조회 쿼리 성능이 빠를까? 에서 다루었듯이, 인덱스는 아무곳에나 필요하다고 막 적용하는 것이 아닌, 정말 필요한 최소한의 컬럼에만 인덱스를 적용해야한다. 인덱스가 생성되는 저장 공간은 데이터베이스 전체 공간에서 최대 10%만을 허용한다. 즉, 인덱스를 생성할 수 있는 저장공간은 한정적이므로 마구잡이로 모든 컬럼에 생성해버리면 불필요한 저장 공간을 낭비할 수 있다. 이러한 이유들로 커버링 인덱스는 우선 적용하지 않고, 더 적합한 인덱스 생성 방법을 찾아보는 것이 바람직하겠다 판단했다.

🧐 2. WHERE 절에 포함된 모든 컬럼을 포함한 복합 인덱스를 생성해야할까?

모든 컬럼에 인덱스를 적용하는 방법이 다소 무모하다면, 랜덤 I/O 가 발생하더라도 인덱스 레인지 스캔을 통해 쿼리 성능 개선을 시도해볼 수 있다. 인덱스 레인지 스캔(Index Range Scan) 이란 리프 페이지에서 범위 탐색의 시작점부터 끝점까지 순차대로 따라가며 원하는 데이터들을 스캔하는 방식이다. 이때 랜덤 I/O 가 발생하므로 커버링 인덱스에 비해선 상대적으로 다소 비효율적일 수 있지만, B+ Tree 구조 특성상 이 스캔 방식 또한 매우 빠르게 범위 탐색이 가능하다. 그리고 WHERE 절에 담긴 필드를 인덱스가 생성되어야지 인덱스 레인지 스캔이 발생한다.

앞서 살펴본 쿼리 내역중에 WHERE 절을 중점으로 다시 살펴보자. 아래와 같이 created_at, is_private 을 모두 WHERE 절에 포함된 상태이다.

WHERE created_at >= '2020-01-01' 
AND created_at <= '2020-06-01' AND is_private = false

만약 인덱스를 생성한다면 아래와 같이 생성해보는 것을 시도해볼 수 있다.

ALTER TABLE trip_schedule
ADD INDEX trip_schedule_complex_index(created_at, is_private);

하지만, 여기서 위처럼 복합 인덱스로 생성할지, 아니면 created_at 에 대해서만 단일 인덱스로 생성할지 고민이 많았다. 복합 인덱스란 위의 (created_at, is_private) 과 같이 2개 이상의 여러 컬럼에 대한 인덱스를 생성하는 것을 뜻하며, 단일 인덱스란 (created_at) 과 같이 단 1개의 컬럼에 대해서 인덱스를 생성하는 방식이다.

초기에는 복합 인덱스를 위처럼 (created_at, is_private) 으로 생성하고 쿼리 성능 개선을 시도하였다. 그 결과 실제 쿼리 시간은 약 55ms 가 측정된 것을 확인할 수 있다. 앞서 인덱스를 적용하지 않았을 때에 비하면 약 36.839초 에서 0.055초 극명하게 개선되었다.

복합 인덱스 vs 단일 인덱스

하지만 문제점이 있다. 이 또한 적합한 인덱스 생성 방식일까라는 의문이 남는다는 점이다. 앞선 커버링 인덱스 고민사항과 달리 WHERE 절에 담긴 컬럼만으로 인덱스를 타게 되었지만, is_private 컬럼을 포함한 복합 인덱스를 생성하는 것이 바람직할까 라는 점이다.

복합 인덱스를 생성시 중요한 점중 하나는 카디널리티(Cardinality) 이다. 애당초 인덱스는 생성된 컬럼들을 기준으로 정렬되는데, 복합 인덱스로 생성시에도 마찬가지로 생성된 컬럼들을 기준으로 B+ Tree 가 정렬된다. 이때 **카디널리티(Cardinality)**가 더 높은(더 유니크하고, 중복이 적은) 컬럼을 중심으로 더 선행 컬럼으로 배치하여 인덱스를 생성해야한다. 선행된 컬럼을 기준으로 인덱스가 우선 정렬되고, 그 다음으로 배치된 컬럼을 후순위로하여 인덱스가 정렬되기 떄문이다.

그런데 문제는, 복합 인덱스로 생성한 (created_at, is_private) 에서 is_private 의 카디널리티가 과연 높은가이다. is_private 컬럼은 true, false 이 둘 중 하나의 값을 가지기 떄문에 카디널리티가 매우 낮은 수치이다. 이를 고려하여 복합 인덱스의 가장 선행되는 1번째 순서가 아닌 2번째 순서로 배치하였지만, created_at 에 비해 매우 낮은 카디널리티 수치를 가지므로 인덱스를 적용하는 것이 사실상 큰 성능 개선이 되지 않는다. (created_at, is_private) 와 같이 복합 인덱스를 생성한다면, created_at 을 기반으로 선행 정렬될 것이며, is_private 을 후순위로 하여 정렬되겠지만, true / false 를 정렬하는 것은 사실상 무의미한 행위이며, 되려 인덱스 공간을 낭비하는 셈이 될 것이라 생각되었다.

그렇다고 해서 is_private 로 인해 랜덤 I/O 가 발생하지 않는 것도 아니다. 랜덤 I/O 가 발생하지 않는 것은 앞선 커버링 인덱스일 때만 가능해진다. 따라서 복합 인덱스 생성은 성능 개선이 미미한 행위가 되며, 불필요한 인덱스 공간 낭비가 된다.

🎯 단일 인덱스를 생성한 인덱스 레인지 스캔 유도

ALTER TABLE trip_schedule
ADD INDEX trip_schedule_simple_index(created_at DESC);

결국 (created_at, is_private) 형태의 복합 인덱스 생성은 비효율적인 인덱스 생성 개선 방법이라 판단되어, 위처럼 created_at 에 대한 단일 인덱스를 생성하여 성능 개선을 시도하였다.

실제로 쿼리가 인덱스를 타는지 EXPLAIN 명령어, 즉 MySQL 싫행게획을 통해 조회해보면 아래와 같이 조회된다. type=range 가 뜻하는 바는 인덱스 레인지 스캔이 수행됨을 뜻한다.

실제 쿼리를 실행했을 때의 시간을 측정해보면 아래와 같이 수행시간에 약 23ms 라는 시간이 소요됨을 확인할 수 있다. 여기서 신기한점은, 앞선 복합 인덱스 생성방식 보다 되려 수행시간이 비슷하다는 점이다. 미미한 수준이지만, 되려 수행시간이 더 빠르게 측정되기도 했다. 이로보아 is_private 과 같이 카디널리티가 매우 낮은 컬럼에 대해 인덱스에 포함한 복합 인덱스를 생성한다고 해서, 그 효과는 사실상 미미하거나 없다고 보는 것이 맞다.

무엇보다 기존 테이블 풀 스캔(Table Full Scan) 방식이 약 36.839 소요시간이 수행된 것에 비해, 인덱스 레인지 스캔(Range Scan) 을 통해 쿼리가 인덱스를 타니 약 0.023초 로 극명하게 개선된 것을 확인할 수 있다 🙂

마치며

이렇게 인덱스를 통한 쿼리 성능 개선기에 대해 다루어보았다. 우리 서비스내에 적합한 인덱스를 적용하기 위해 위처럼 하나하나의 많은 고민과 효율적인 해결안을 찾고자 노력하였고, 기존 테이블 풀 스캔 방식일 때 약 36.839초 가 걸리던 쿼리를 0.023초 로 개선하였다. 만약 커버링 인덱스를 적용한다면 현재 측정된 소요시간인 0.023초 에 비해 더 빠른 성능을 이루어낼 수 있었겠지만, 이 쿼리 소요시간 만으로도 충분히 쿼리 성능이 극명하게 최적화되었다고 생각하여 커버링 인덱스 생성을 적극 고려하지 않았던 것도 이유 중 하나이다. 성능 개선이 된다고 한들, 그 수준이 매우 미미한 수준일 것이다.

앞으로도 우리 서비스 사용자들이 더 편리함을 누릴 수 있도록, 사용자 경험을 개선할 수 있도록 많은 고민 시간을 가져볼까 한다. 이만 포스팅을 마쳐본다 😎

[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 제 2장. 계략적인 규모 측정

Fri, 15 Nov 2024 00:00:00 GMT

시스템 설계 면접을 볼 때, 떄로는 시스템 용량이나 성능 요구사항을 개략적으로 추정해보라는 요구를 받게 된다. 개략적인 규모 측정은 보편적으로 통용되는 성능 수치상에서 사고 실험을 행하여 추정치를 게산하는 행위로써, 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것이다.

개략적 규모 추정을 효과적으로 해 내려면 규모 확장성을 표현하는데 필요한 기본기에 능숙해야한다. 특히 2의 제곱수나 응잡지연(latency) 값, 그리고 가용성에 관계된 수치들을 기본적으로 잘 이해하고 있어야 한다.

2의 제곱수

분산 시스템에서 다루는 데이터 양은 엄청나게 커질 수 있으나, 그 계산법은 기본을 크게 벗어나지 않는다. 제대로 된 계산 결과를 얻으려면 데이터 볼륨의 단위를 2의 제곱수로 표현하면 어떻게 되는지를 우선 알아야 한다. 최소 단위는 1바이트이고, 8비트로 구성된다. ASCII 문자 하나가 차지하는 메모리 크기가 1바이트이다.

모든 프로그래머가 알아야 하는 응답지연 값

메모리는 빠르지만 디스크는 아직도 느리다.
디스크 탐색(seek) 은 가능한 피하라.
단순한 압축 알고리즘은 빠르다.
데이터를 인터넷으로 전송하기 전에 가능하면 압축한다.
데이터 센터는 보통 여러 지역에 분산되어 있고, 센터들 간에 데이터를 주고받는데는 시간이 걸린다.

가용성에 관계된 수치들

고가용성은 시스템이 오랜시간동안 지속적으로 중단없이 운영될 수 있는 능력을 지칭하는 용어이다. 고가용성을 표현하는 것은 퍼센트로 표현하는데, 100%는 시스템이 단 한번도 중단된 적이 없었음을 의미한다. 대부분의 서비스는 99% 에서 100% 사이의 값을 갖는다.

팁

개략적인 규모 추정과 관계된 면접에서 가장 중요한 것은 문제를 풀어 나가는 절차이다. 올바른 절차는 밟느냐가 결과를 내는 것보다 중요하다. 면접자가 보고싶어하는 것은 문제 해결 능력이다. 이와 관련된 팁은 다음과 같다.

근사치를 활용한 계산 : 면접장에서 복잡한 게산을 하는것은 어려운 일이다. 계산하는데 시간을 쓰는 일은 낭비이다. 적절한 근사치를 활용하여 시간을 절약하자.
가정들은 적어두라. 나중에 살펴볼 수 있도록.
많이 출제되는 개략적 규모 추정 문제는 QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등을 측정하는 것이다. 면접에 임하기 전에 이런 값들을 계산하는 연습을 미리 해두자.

✒️ 팀 프로젝트에서 발견한 진정한 의미의 함께 성장하기

Wed, 13 Nov 2024 00:00:00 GMT

💡 카카오테크 부트캠프는 자율 주제 글쓰기 & 소정의 이벤트가 주어진다. 이 포스팅은 "우리는 프로젝트에서 함께 성장할 수 있을까" 주제로 작성한 글이다.

솔직하게 말하는 습관이 팀을 더 성장시킨다

저는 갈등을 정말 싫어하는 사람이었습니다. 카테부에 참여하기 전의 저는, 남에게 제가 무지하다는 것을 들키는 것이 정말 싫었어요. 제가 가지고 있는 생각에 대한 확신도 없고, 자신감이 많이 없었습니다. 타인과 갈등이 생기지 않도록 항상 제 의견을 감추는 편이었답니다. 그저 단순히 맹목적으로 타인의 의견을 수용하고, 열정적인 의견 교환이 일어나지 않았죠. 갈등없이 화목하게 지내는 팀이 좋은 팀이라고 생각했었죠.

하지만, 혼자 의견을 감추고 의견을 적극 내세우지 않는다는 것이 좋지 않다는 것을 깨달았습니다. 팀 프로젝트를 통해 깨달은 점이 하나 있어요. 서로 다른 의견을 가지고 있는 크루들과 열정적으로 의견을 주고받아야만 전혀 생각치 못한 방법을 알게되고, 다양한 시야가 확장된다는 것이에요.

회의에서 계속 정적이 흐르고, 만장일치 의견이 나온다는 것은 팀원 간 사이가 좋다는 뜻이 아닙니다. 계속되는 만장일치는 팀 전체가 하나의 수동적인 틀에만 박힌 생각에서 빠져나오지 못하게 되는 경우가 많거든요. 하지만 서로 다른 의견을 가지고 있는 사람과 뜨겁게 의견을 주고받다보면 전혀 생각치 못한 획기적인 방법을 깨닫고, 다양한 시야가 확장된다는 것을 알 수 있었습니다. 더 빠르게 팀이 성장하기 위한 방법은 더 능동적으로 최대한 많이 토론하고, 잡담하는 것입니다. 저희 하모니 팀 크루들은 서로가 다른 의견을 가지고 있을 때 그 자리를 회피하기보다는, 오히려 의견 교환에 적극 참여하는 경우가 대부분입니다.

그러나, 자칫 무작정 반대하는 의견은 서로 간의 신뢰가 쌓여있지 않다면 자신에 대한 공격으로 받아들여질 수 있습니다. 그 떄문에 하모니 팀은 프로젝트 초반부터 좋은 팀 분위기를 형성하는데 많은 시간을 쏟았습니다. 특히, 서로의 의견을 편안하게 이야기할 수 있는 분위기를 만드는 것이 가장 큰 목표였어요. 자신의 생각과 고민을 편안하게 이야기할 수 있어야만 더 활발한 의견 교류가 이어지고, 팀원 전체가 공통된 하나의 목표를 위해 빠르게 달려나갈 수 있거든요.

팀원을 설득하기 위해선, 그를 위한 충분한 근거를 만들자!

카테부의 참여하기 전의 저 자신과 크게 달라진 점이 또 있어요. 팀원을 설득하기 위해선, 그를 위한 충분한 논리와 설득력이 필요하다는 점이죠. 어떤 기술을 도입하기 위해선 항상 "Why?" 를 떠올리며, 해당 기술과 행위에 대한 당위성을 확보해야한다는 것을 알게 되었어요.

하모니 팀에서 RefreshToken 을 위한 저장소를 구축하던 중, 한 가지 재밌었던 일화가 기억에 남아요. 인증/인가 로직을 구현하던 중 리프레시 토큰을 Redis 에 저장하는 방식을 생각했습니다. 로컬에서 Redis 를 간단히 설치하여 구축 후, 회의 시간에 저희 클라우드 팀원 레오, 엘라에게 Redis 를 사용하자고 의견을 내세웠지만, "왜 써야해?" 라는 질문에 답하지 못했어요. 충분한 논리와 설득력없이 "그냥" 쓰기만 했어요.

아무리 생각해보아도, 저희 팀에게 Redis 가 꼭 필요한 근거를 찾을 수 없었습니다. Redis 는 서버를 다중화하여 운영할 때 데이터 동기화 문제를 해결할 수 있다는 큰 장점이 있지만, 저희 하모니 팀은 다중화를 한 상황이 아닙니다. 단일 서버 1대라면 Redis 없이도 충분히 인메모리에서 토큰을 관리할 수 있었죠.

기술은 어떤 특정한 상황을 해결하기위해 등장한 것입니다. 기술은 이유 없이 등장한 것이 아니죠. 기술을 도입할 이유가 없는데도 충분한 고민없이 기술을 도입하는 것은 팀의 학습비용과, 자칫 불필요한 비용 낭비만 발생합니다. 저희 팀은 이때부터 새로운 기술 도입이 생길 때마다 더 효율적인 방안은 없을지, 우리에게 이 기술이 꼭 필요한 것인지 충분한 근거와 고민 시간을 확보하고 있답니다. 과거의 저는 단순히 새로운 기술 도입이 그저 멋져 보여서 사용한 것이 아닐까요?

팀원들을 통해, 전혀 몰랐던 나만의 장점을 찾아내기

혼자서 프로그래밍을 공부할 때와 달리, 팀원들과 함께 협업해야하다보니 말하기 스킬이 늘었던 것 같습니다. 팀원들과 의사소통하면서 내가 몰랐던 장점을 발견할 수도 있었어요. "하온은 글을 정말 잘 쓰는 것 같아! 필력이 진짜 좋다!" 와 같이 내가 몰랐던 장점을 찾아낼 수도 있었어요. 팀원들과 함께 성장하기 위해 제가 학습했던 블로그 포스팅을 자주 공유하곤 했는데, 이때마다 크루들에게 칭찬을 많이 듣기도 했어요.

이번 카테부에서 몰랐던 나만의 장점을 많이 발견할 수 있었답니다. 혼자 공부할 때는 내가 무엇을 잘 하고 못하는거지? 라는 좁은 시야에 갇혀서 빠져나오지 못했었. 하지만, 이번 깊이 있는 협업 프로젝트 경험에서 팀원들 덕분에 나만의 개성과 색깔은 무엇인지 알 수 있었어요. 그리고 제 성향과 색깔이 협업하는 크루들에게 어떤 기여도를 끼칠 수 있는지도 알게 되었답니다.

다양한 색깔과 경험을 가진 사람들과 함께 성장하기

글을 적다보니 카카오테크 부트캠프에 참여하기 전, 대학교에서 팀 프로젝트를 진횅했을 때가 생각나네요. 지금까지 경험했던 팀 프로젝트는 팀원들의 열정이 제각각이었답니다. 누군가는 이번 프로젝트가 진심으로 열정을 다 하고 싶다면, 다른 누군가에겐 별 생각없이 억지로 참여하는 프로젝트였답니다.

그런데, 카카오테크 부트캠프는 달랐습니다. 카카오테크 부트캠프 크루들은 모두가 열정을 다하고, 성장에 열망이 넘치는 사람들이 넘쳐나요. 서로가 불 태우는 열정은 협업하는 팀원 모두에게 전염되고, 그 열정이 또 다른 이에게 전염되어 함께 성장하고 있습니다.

또한 서로 다른 개성과 경험, 가치관을 가진 팀원들이 모여 하나의 서비스를 개발하고 있습니다. 여기서 저는, 책 ‘함께 자라기’ 에서 강조하는 함께하는 성장이 무엇인지 조금 알게 된 것 같아요. 하모니 팀은 모두가 팀이 직면한 문제를 해결히기 위해 함께 고민하고, 진심으로 열정을 태웁니다. 일과 시간이 끝나고도 카카오테크 부트캠프는 불이 꺼지지 않아요. 누군가 강제하는 것도 아닌데, 끝까지 남아서 크루들과 토론하고, 고민하고, 생각합니다.

이 과정속에서 저는 크루들에게 많이 배우고 있어요. 혼자서 공부하고, 프로그래밍 하다 보면 자신만의 틀에 박힌 생각에 갇히게 되는 경우가 많거든요. 하지만 서로 다른 의견을 가지고 있는 사람과 뜨겁게 의견을 주고받다보면 전혀 생각치 못한 획기적인 방법을 깨닫고, 다양한 시야가 확장된다는 것을 알 수 있었습니다. 더 빠르게 성장하는 학습 방법은 더 능동적으로 최대한 많이 토론하고, 잡담하는 것입니다.

이런 선순환 속에서 저는 함께 자라기를 경험했습니다. 개인의 성장이 곧 팀의 성장이고, 팀의 성장이 곧 개인의 성장으로 이어지는 경험을 했습니다. 이런 경험을 쌓게해준 저희 카테부 하모니 팀원들에게 항상 고마울 따름이에요. 아직 부족함이 많은 저와 팀 프로젝트를 함께한 하모니 팀 크루 리안, 레오, 엘라, 도로시, 민디에게 항상 감사를 표하며 이만 글을 마치겠습니다. 😊

어노테이션 기반 Spring MVC 프레임워크 구현하기

Tue, 12 Nov 2024 00:00:00 GMT

진행한 실습 코드 PR 은 PR : 어노테이션 기반 MVC 프레임워크 구현하기 에서 확인 가능하다.

지난 레거시 MVC 프레임워크의 문제점

지난 AJAX 기반 레거시 MVC 프레임워크 구현하기 에선 AJAX 에 기반한 모방 MVC 프레임워크를 구현했지만 아쉽게도 문제점이 여럿 존재한다.

우선 새로운 컨트롤러가 추가될 때 마다 (1) 매번 RequestMapping 클래스에 요청 URL 과 컨트롤러를 추가줘야 한다. 꽤 번거롭고 귀찮은 작업이 발생한다. 유지보수 관점에서도 생각해본다면 컨트롤러 수가 100개가 넘어가기 만 해도 관리하기가 힘들어진다. 또한 각 컨트롤러의 execute() 매소드엔 10줄이 넘어가는 경우가 거의 없다. 새로운 기능이 추가될 때 마다 매번 컨트롤러 오브젝트를 추가하는 것이 아닌, 메소드를 추가하는 방식으로 개선되면 좋을 것이다. 또한 (2) 요청 URL 을 매핑할 때 HTTP 메소드도 매핑에 활용할 수 있다면 좋을 것이다. HTTP 메소드에 대한 지원이 가능하다면 URL 은 같지만 다른 메소드로 매핑하는 것도 가능할 것이다.

이번 학습의 목적은 지난 MVC 프레임워크을 점진적으로 리팩토링 하면서, 어노테이션에 기반한 새로운 NVC 프레임워크로 개선하는 것이 주 목적이다.

기본 어노테이션 및 클래스

@Controller, @RequestMapping

기본적인 어노테이션은 아래와 같이 제공되고 있다. 특히 RequestMethod 는 GET, POST, PUT, ... 등을 값으로 가지는 enum 클래스이다.

// RequestMapping.java
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface RequestMapping {
  String value() default "";

  RequestMethod method() default RequestMethod.GET;
}

// Controller.java
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface Controller {
  String value() default "";
}

RequestMethod

public enum RequestMethod {
  GET, POST, // ...
}

@Controller 어노테이션 설정 클래스 스캔

어노테이션 기반으로 MVC 프레임워크를 구현하려면 먼저 @Controller 어노테이션 설정이 되어있는 클래스를 찾아야한다. 자바 reflection 라이브러리를 활용해 클래스 목록을 찾고, 각 클래스에 대한 인스턴스 목록까지 구현한다.

ControllerScanner

public class ControllerScanner {
    private static final Logger log = LoggerFactory.getLogger(ControllerScanner.class);
    private Reflections reflections;

    public ControllerScanner(Object... basePackage) {
        reflections = new Reflections(basePackage);
    }

    public Map<Class<?>, Object> getControllers() throws InstantiationException, IllegalAccessException {
        Set<Class<?>> preInitiatedControllers = reflections.getTypesAnnotatedWith(Controller.class);
        return instantiateControllers(preInitiatedControllers);
    }

    Map<Class<?>, Object> instantiateControllers(Set<Class<?>> preInitiatedControlllers)
            throws InstantiationException, IllegalAccessException {
        Map<Class<?>, Object> controllers = Maps.newHashMap();
        try {
            for(Class<?> clazz : preInitiatedControlllers) {
                controllers.put(clazz, clazz.newInstance());
            }
        } catch (InstantiationException | IllegalAccessException e) {
            log.error(e.getMessage());
        }
        return controllers;
    }
}

@RequestMapping 어노테이션 설정을 활용한 매핑

앞서 ControllerScanner 와 자바 리플랙션을 통해 찾아낸 컨트롤러 클래스를 찾아냈을 것이다. 찾아낸 컨트롤러 클래스 내부의 @RequestMapping 어노테이션 설정을 기반으로 매핑을 해야한다. 매핑을 이전 MVC 프레임워크와 같이 Map 을 활용한다.

HandlerKey

새로운 MVC 프레임워크 버전에서 다른점은 Map 의 Key 로 사용되는 값이 요청 URL 과 더붙어 HTTP 메소드 조합으로 구성되어야 한다는 것이다. 요청 URL 과 HTTP 메소드 정보를 가지는 클래스를 HandlerKey 라는 이름으로 구현했다.

public class HandlerKey {
    private String url; // 요청 URL
    private RequestMethod requestMethod; // HTTP 메소드 정보

    public HandlerKey(String url, RequestMethod requestMethod) {
        this.url = url;
        this.requestMethod = requestMethod;
    }

    @Override
    public String toString() {
        return "HandlerKey [url=" + url + ", requestMethod=" + requestMethod + "]";
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((requestMethod == null) ? 0 : requestMethod.hashCode());
        result = prime * result + ((url == null) ? 0 : url.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj)
            return true;
        if (obj == null)
            return false;
        if (getClass() != obj.getClass())
            return false;
        HandlerKey other = (HandlerKey) obj;
        if (requestMethod != other.requestMethod)
            return false;
        if (url == null) {
            if (other.url != null)
                return false;
        } else if (!url.equals(other.url))
            return false;
        return true;
    }
}

HashMap 의 Key 값으로 활용하기 위해 위 HandlerKey 오브젝트를 hashCode(), equals() 를 재정의하여 동등성을 보장해줬다.

HandlerExecution

한편 Map 의 Value 값으로는 @RequestMapping 어노테이션이 설정되어 있는 메소드 정보를 가져야한다. 값에 저장되는 메소스 정보는 자바 리플렉션으로 해당 메소드를 실행할 수 있는 정보를 가져야한다. 즉, 메소드가 위치하는 클래스의 인스턴스 정보와 java.lang.reflect.Method 정보를 가지고 있어야한다. 이 정보를 가지는 클래스를 HandlerExecution 이라는 이름으로 아래와 같이 구현했다.

public class HandlerExecution {
  public static final Logger logger = LoggerFactory.getLogger(HandlerExecution.class);
  private Object declaredObject; // 메소드가 위치하는 클래스의 인스턴스 정보
  private Method method;  // Method 정보

  public HandlerExecution(Object declaredObject, Method method) {
    this.declaredObject = declaredObject;
    this.method = method;
  }

  public ModelAndView handle(HttpServletRequest request, HttpServletResponse response) throws Exception {
    try {
        return (ModelAndView) method.invoke(declaredObject, request, response);
    } catch (IllegalAccessExcpetion | IllegalArgumentException e) {
        logger.error("{} method invoke fail. Error message : {}", method, e.getMessage());
        throw new RunTimeException(e);
    }
  }
}

AnnotationHandlerMapping

Map 에서 사용할 key 와 value 에 대한 클래스인 HandlerKey, HandlerExecution 의 구현을 완료했다. HandlerKey 와 HandlerExecution 을 연결해야 한다. HandlerKey, HandlerExecution 이들에 대한 매핑 초기화 작업 을 AnnotationHandlerMapping 클래스를 추가해 구현했다.

public class AnnotationHandlerMapping {
  private static final Logger logger = LoggerFactory.getLogger(AnnotationHandlerMapping.class);
  private Object[] basePackage;
  private Map<HandlerKey, HandlerExecution> handlerExecutions = Maps.newHashMap();

  public AnnotationHandlerMapping(Object... basePackage) {
    this.basePackage = basePackage;
  }

  public void initalize() {
    ControllerScanner controllerScanner = new ControllerScanner(basePackage);
    Map<Class<?>, Object> cotnrollers = controllerScanner.getControllers();
    Set<Method> methods = getRequestMappingMethods(controllers.keySet());
    for(Method method : methods) {
        RequestMapping rm = method.getAnnotation(RequestMapping.class);
        logger.debud("register handlerExecution : url is {}, method is {}", rm.value()., method);
        handlerExecutions.put(createHandlerKey(rm), new HandlerExecution(controllers.get(method.getDeclaringClass()), method));
    }
  }

  private HandlerKey createHandlerKey(RequestMappign rm) {
    return new HandlerKey(rm.value(), rm.method());
  }

  @SuppressWarnings("unchecked")
  private Set<Method> getRequestMappingMethods(Set<Class<?>> controllers) {
    Set<Method> requestMappingMethods = Sets.newHashSet();
    for(Class<?> clazz : controllers) {
        requestMappingMethods.addAll(ReflectionUtils.getAllMethods(clazz, ReflectionUtils.withAnnotataion(RequestMapping.class)));
    }
    return requestMappingMethods;
  }

  // 클라이언트 요청에 해당하는 HandlerExecution 을 조회하는 매소드
  public HandlerExecution getHandler(HttpServletRequest request) {
    String requestUri = request.getRequestURI();
    RequestMethod rm = RequestMethod.valueOf(request.getMethod().toUpperCase());
    logger.debug("reqeustUri: {}, requestMethod: {}", requestUri, rm);
    return handlerExecutions.get(new HandlerKey(requestUri, rm));
  }
}

DispatcherServlet 과 AnnotationHandlerMapping 통합

지금까지 앞선 구현을 통해 어노테이션 기반으로 컨트롤러 설정이 가능하도록 구현했다. 이젠 DispacherServlet 에서 새롭게 추가한 AnnotationHandlerMapping 을 활용해 서비스가 가능하도록 통합해야한다. 그런데 DispatcherServlet 기존 코드에는 컨트롤러를 RequestMapping 클래스로 정보를 담고있다. 즉 DispatcherServlet 은 이전까지 레거시 MVC 프레임워크의 매핑 정보를 담고있는 RequestMapping 과, 현재 어노테이션 기반으로 매핑 정보를 담고있는 AnnotationHandlerMapping 의 오브젝트를 모두 필드로 가지고, 지원해야한다.

RequestMapping 과 AnnotationHandlerMapping 을 모두 지원하기 위해 둘을 각각 분리해서 관리할 수도 있겠지만, 둘을 일관된 인터페이스로 통합한 후 관리하는 것이 확장성 측면에서 유리하다. 이 2가지 매핑 클래스에 대해 추상화한 공용 인터페이스를 HandlerMapping 이라는 이름으로 추가했다. 즉, RequestMapping 과 AnnotationHandlerMapping 클래스가 HandlerMapping 인터페이스를 구현한다.

public interface HandlerMapping {
  Object getHandler(HttpServletRequest request);
}

LegacyRequestMapping

또한 기존 RequestMapping 클래스의 이름을 LegacyRequestMapping 으로 이름을 변경했다.

public class LegacyHandlerMapping implements HandlerMapping {
  private Map<String, Controller> mappings = new HashMap<>();

   void initMapping() {
      // ...
   }

   @Override
   public Controller getHandler(HttpServletRequest request) {
     return mappings.get(request.getRequestURI());
   }
}

DispatcherServlet 리팩토링

DispatcherServlet 이 HandlerMapping 인터페이스의 구현체 2가지 타입인 LegacyHandlerMapping, AnnotationHandlerMapping 에 대해 모두 동작(호환) 되도록 개선했다. 초기화가 끝난 HandlerMapping 을 List 로 관라하면서 요청 URL 과 HTTP 메소드에 해당하는 컨트롤러를 찾아 컨트롤러가 존재할 경우 컨트롤러에게 작업을 위임하도록 구현했다.

@WebServlet(name = "dispatcher", urlPatterns = "/", loadOnStartUp = 1)
public class DispacherServlet extends HttpServlet {
  private static final Logger logger = LoggerFactory.getLogger(DispacherServlet.class);
  private List<HandlerMapping> mappings = Lists.newArrayList();

  @Override
  public void init() throws ServletException {
    LegacyHandlerMapping lhm = new LegacyHandlerMapping();
    lhm.initMapping();
    AnnotationHandlerMapping ahm = AnnotationHandlerMapping("next.controller");

    ahm.initalize();
    mappings.add(lhm);
    mappings.add(ahm);
  }

  @Override
  protected void service(HttpServletRequest req, HttpServletRespisnoe resp) throws ServletException, IOException {
    Object handler = getHandler(req);
    if(handler == null) {
      throw new IllegalArgumentExcpetion("존재하지 않는 URL입니다.");
    }

    try {
      ModelAndView mav = execute(handler, req, resp);
      View view = mav.getView();
      view.render(mav.getModel(), req, resp);
    } catch (Throwable e) {
      logger.error("Exception : {}", e);
      throw new ServletException(e.getMessage());
    }
  }

  private Object getHandler(HttpServletRequest req) {
    for(HandlerMapping handlerMapping : mappings) {
      Object handler = handlerMapping.getHandler(req);
      if(handler != null) {
        return handler;
      }
    }
    return null;
  }

  private ModelAndView execurte(Object handler, HttpServletRequest req, HttpServletResponse resp) throws Exception {
    if(handler instanceof Controller) {
      return ((Contoller)handler).executea(req, resp);
    } else {
      return ((HandlerExecution)handler).handler(req, resp);
    }
  }
}

@Controller 어노테이션 활용

모든 작업이 끝났다. 이제 테스트 컨트롤러를 생성한 후 아래와 같이 @Controller 어노테이션을 명시하면 원활히 동작할 것이다. 앞서 코드 구현을 통해 기존 컨트롤러에 대한 지원도 가능하면서 새롭게 추가한 AnnotationHandlerMapping 도 지원하므로 호환성이 유리한 MVC 프래임워크가 되었다.

@Controller
public class TestController {

    @RequestMapping(value = "/get-test", method = RequestMethod.GET)
    public ModelAndView findUserId(HttpServletRequest request, HttpServletResponse response) {
        // ...
        return modelAndView;
    }

    @RequestMapping(value = "/post-test", method = RequestMethod.POST)
    public ModelAndView save(HttpServletRequest request, HttpServletResponse response) {
        // ...
        return modelAndView;
    }
}

마치며

이렇게 어노테이션 기반 Spring MVC 를 모방한 프레임워크를 구현할 수 있었다. 스프링부트 프레임워크의 내부 동작원리를 깊게 이해할 수 있었던 가장 유익한 학습거리가 되었다! 지금까지 학습해왔던 내용들중에 가장 큰 배움이 있었던 미션이지 않나 싶다. 기존 레거시 코드에 대한 처리, 점진적인 리팩토링 과정하는 과정이 꽤 어려웠지만, MVC 프레임워크를 직접 구현해보니 덕분에 이해도가 훨씬 높아졌다.

다만, 아직 DI 컨테이너 직접 구현하기에 대한 미션이 남아있다. 어서 진행해보고 싶은 마음이다. DI 컨테이너를 구현한 후, DI 컨테이너와 현재 구현된 Spring MVC 코드를 어서 통합해봐야겠다 🙂

더 학습해야 할 키워드

자바 리플렉션 (JAVA Reflection)

HTTPS 의 SSL 기반 암호화, 복호화 통신 과정은 어떻게 이루어질까?

Fri, 08 Nov 2024 00:00:00 GMT

HTTP vs HTTPS

HTTPS 는 HTTP 프로토콜에 SSL 을 추가로 덧붙였다.

HTTP(Hypertext Transfer Protocol) 은 서버에서 브라우저로 데이터를 전송시 가장 널리 사용되는 프로토콜이지만, 전송되는 정보가 암호화되지 않아 보안에 취약하다는 문제점이 있다. 그로인해 등장한 프로토콜이 HTTPS(Hypertext Transfer Procotol Secure) 로, 기존 HTTP 프로토콜에 SSL 을 추가적으로 덧붙여 사용한 프로토콜이다.

HTTP 그 자체를 암호화하진 않는다.

그렇다고 HTTPS 는 HTTP 그 자체를 모두 암호화하는 것은 아니다. HTTP 를 사용해서 운반하는 내용, 즉 HTTP 의 Message Body 를 암호화하지만 HTTP Header 는 아쉽게도 암호화하지 않는다.

SSL 과 TLS

그렇다면 SSL 은 무엇일까? SSL(Secure Socket Layer) 의 약자로, Netscape 사에서 보안성이 강화된 통신을 위해 만든 프로토콜이다. 가장 큰 특징은 공개키(public key) 와 개인키(private key), 즉 공개키 방식과 대칭키 방식을 혼합해서 함께 사용한다는 것이다.

대칭키 (Symmetric Key)

대칭 키란 데이터 송.수신자 사이에 동일한 Key 값을 기반으로 암호화 및 복호화를 수행하는 기법이다. 그래서 이 암호화.복호화에 활용할 대칭키값만 탈취한다면, 해당 데이터를 쉽게 복호화할 수 있다. 이 떄문에 대칭키 방식은 Key 값이 탈취되면 암호화 복호화가 매우 쉽게 진행된다는 취약점이 존재한다.

공개 키 (Public Key)

대칭 키 방식과 비교

대칭 키(Symmetric Key) 방식이 통신의 양방향측에서 서로 동일한 Key 값으로 암호화하는 방식이라면, 공개 키는 서로 다른 Key 값으로 암호화.복호화를 수행하는 기법이다. 즉, 대칭키와 공개키 방식은 동일한/서로 다른 Key 값으로 암호화(복호화)를 수행하는가에 따라 차이가 나는 기법이라고 정리할 수 있다. 이 때문에 공개 키 방식은 비대칭키(Non Symmetric Key) 방식이라고도 불린다.

공개 키

더 자세히는 데이터를 암호화할 땐 공개키를 사용하고, 데이터를 복호화할 떄는 개인키를 사용한다. 공개키로 암호화한 데이터는 오직 개인키로만 복호화할 수 있기 떄문에, 그 누구던지 공개키를 탈취해도 문제가 없다. 즉, 공개키는 말 그대로 공개된 키로써 중간에 누군가에게 탈취되어도 문제가 발생하지 않는다.

데이터의 송.수신자 입장에서 다시 정리해보자. 데이터 송신자는 전달할 데이터를 공개키를 기반으로 암호화하여 전송한다. 암호화된 데이터를 전송받은 수신자는, 해당 데이터를 복호화하기 위해 개인키를 활용하여 복호화를 진행한 후 데이터를 열람할 수 있게된다. 도중에 제 3자가 공개키를 탈취하고 데이터 복호화를 시도하려고 한들, 개인키 또한 탈취하지 않는 이상 복호화가 불가능하다.

하지만 이 또한 단점이 있다. 공개키 방식은 대칭키 방식에 비해 암호화 연산 시간이 더 오래걸린다.

최종적으로 정리해보자면, 공개 키 방식은 통신 양측간에 서로 다른 Key 값을 사용하여 전달받은 암호문을 복호화한다고 했다. 이떄 서로 다른 Key 값이란 개인 키(private key) 를 의미한다.

공개키 vs 대칭키

결국 공개 키가 가진 단점을 대칭키에선 장점으로 누리고 있으며, 반대로 대칭키에서 가진 단점을 공개키에선 장점으로 활용하고 있다. 이 때문에 SSL 은 2가지 방식이 가진 장.단점 떄문에 이 둘을 모두 적절히 활용한다.

SSL 의 통신 과정

SSL 은 2가지 방식을 적절히 섞어 활용한다고 했다. 더 정확히는 SSL 은 공개키 방식으로 대칭키를 얀전하게 전달하여, 서로가 동일한 대칭키 값을 기반으로 통신하는 방식이다. 이 대칭키를 활용하여 암호화, 복호화를 하며 통신을 진행한다.

우선 송신자는 수신자에게 접속 요청을 보내서 수신자의 공개키를 전달받는다. 그러면 송신자는 전달받은 공개키를 기반으롷 본인의 대칭키를 암호화한다. 암호화된 결과(대칭키)를 수신자에게 전달하면, 수신자는 전달받은 대칭키를 자신의 개인키로 복호화하여, 그 복호화 결과로 송신자의 대칭키를 얻어낼 수 있게된다.

즉, 데이터 암호화 및 복호화를 위한 한 쪽의 대칭키를 다른쪽의 공개키로 암호화하여 전송하면, 반대편에서 자신의 개인키로 복호화하여 그 반대편의 대칭키를 알아내고, 이 동일한 대칭키 값을 바탕으로 서로 안전하게 통신할 수 있게된다.

SSL 의 유효한 사이트 판별 방법

그렇다면 사용자가 접속한 사이트가 유효한 사이트인지 어떻게 확인할 수 있는가? 즉, 특정 사이트가 HTTPS 프로토콜을 사용하여 사이트 사용자에게 안전한 사이트임을 알리기 위해선 사이트 인증기관(CA) 로 부터 SSL 인증서 (사이트 인증서) 를 발급받아야 한다. 이 과정을 자세히 살펴보자.

1. CA 인증기관 과의 협력

이해를 돕기위해, 사이트를 네이버에 비유하겠다. 가장 먼저 네이버는 본인이 안전한 사이트임을 사용자에게 알리고, HTTPS 프로토콜을 지원하기 위해 SSL 인증서를 발급받아야한다. 이를위해 네이버 본인의 사이트 정보와 Public key 를 CA 인증기관에게 전송하여 SSL 인증서를 발급받기를 시도한다. 이 기대에 따라 CA 인증기관은 전달받은 데이터를 검증하여 (CA 기관 본인의 private key 로 데이터를 서명하는 과정 발생) 네이버에게 SSL 인증서를 발급해준다.

또한 CA 인증기관은 네이버 사용자에게 본인의 public key 를 전달하고, 이 공개키는 사용자 브라우저내에 자동으로 내장된다.

2. 사용자가 웹 사이트 접속 요청시

위 까지는 사용자가 사이트에 접속하기 전까지 내용이다. 이어서 사용자가 사이트 접속을 요청했을 때 어떤 일이 일어날까?

우선 사용자가 네이버에 접속을 요청하면, 네이버는 앞서 CA 인증기관으로 부터 발급받은 SSL 인증서를 사용자에게 전달하여 자신이 신뢰할 수 있는 사이트임을 증명한다.

그러면 사용자는 앞서 브라우저 내에 내장한 CA 인증기관의 public key 로 전달받은 네이버의 SSL 인증서를 복호화하여 검증한다. SSL 인증서 복호화에 성공했다면, 네이버에 대한 사이트 정보와 공개키를 얻을 수 있게된다. 이렇게 얻은 네이버 사이트의 public key 를 활용하여 사용자는 본인의 대칭키를 암호화하고, 그 암호화한 대칭키를 네이버에게 전달한다.

이어서 네이버는 본인의 private key 로 전달받은 암호문을 복호화하여 사용자의 대칭키를 얻어내고, 이제 이렇게 얻은 대칭키를 활용하여 사용자와 네이버 사이트는 서로 암호문을 주고받을 수 있게 된다. 즉, SSL 통신을 할 수 있게된다.

참고

AJAX 기반 레거시 MVC 프레임워크 구현하기

Wed, 06 Nov 2024 00:00:00 GMT

스터디를 진행하면서 알게된 학습 내용, 고민 사항을 정리했다.

MVC 패턴, JSP

MVC 패턴이 등장하기 이전까지만 해도 대부분의 로직은 JSP 에 모두 담겨있었다. JSP 에 상당 로직을 포함하는 것이 초기 개발 속도는 빠를진 몰라도 유지보수 비용은 상당했다.

MVC 패턴을 적용할 경우 기존 JSP 만이 존재할 때와 다른점은, JSP 의 역할은 단순히 컨트롤러로부터 전달된 데이터를 단순히 출력하는 로직만을 포함하고 있다는 점이다. 대부분의 로직은 컨트롤러와 모델이 담당하고 있고, JSP 는 단순 뷰의 로직만을 수행하면 된다.

1단계. DispatcherSevlet 기반 MVC 프레임워크 구현

우선 기본적인 MVC 프레임워크 1단계를 진행했다. 지난 실습에선 RequestHandler 에서 모든 요청을 받고 요청 URL 에 따라 분기 처리해줬는데, 이를 서블릿으로 변경한다. 즉 DispatcherServlet 서블릿을 구현하하고, 이 하나의 서블릿이 모든 요청을 받고 요청 URL 에 따라 분리 처리하도록 구현했다.

Controller

우선 클라이언트 요청에 대한 처리를 담당하는 부분인 컨트롤러를 추상화했다. execute() 에서 리다이렉트 방식으로 이동할 경우 redirect: 로 시작하고 forward 방식으로 이동할 경우 JSP 를 반환하도록 구현했다.

public interface Controller {
  String execute(HttpServletRequest request, HttpServletResponse response) throws Excpetion;
}

Controller 구현체

Controller 를 구현한 컨트롤러 구현체 중 하나다. 이렇게 생성된 여러 컨트톨러 오브젝트들은 이후 살펴볼 RequestMapping 에서 서비스에서 발생하는 모든 요청 URL 과 각 URL 에 대한 서비스를 담당할 컨트롤러가 매핑된다.

public class ListUserController implements Controller {
  @Override
  public String execute(HttpServletRequest request, HttpServletResponse response) throws Exception {
    if(isLogined(request.getSession())) {
      return "redirect:/users/loginForm";
    }
    req.setAttribute("users", Database.findAll());
    return "/item/list.jsp";
  }

  private boolean isLogined(HttpSession session) {
    // ...
  }
}

RequestMapping

앞서 언급한 RequestMapping 이다. RequestMapping 은 서비스에서 발생하는 모든 요청 URL 과 각 URL 에 해당 서비스를 담당할 컨트롤러를 연결하는 작업을 담당한다.

public class RequestMapping {
  private static final Logger logger = LoggerFactory.getLogger(DispatcherServlet.class);
  private Map<String, Controller> mappings = new HashMap<>();

  void initMapping() {
    mappings.put("/", new HomeController());
    mappings.put("/users/form", new ForwardController());
    mappings.put("/users/profile", new ProfileController());
    // ...
  }

  public Controller findController(String url) {
	return mappings.get(url);
  }

  void put(String url, Controller controller) {
    mappings.put(url, controller);
  }
}

DispatcherServlet

마지막으로 구현할 부분은 클라이언트의 모든 요청을 받아 URL 에 해당하는 컨트롤러로 작업을 위임하고, 실행된 결과 페이지로 이동하는 작업을 담당하는 DispatcherServlet 를 구현했다. 각 요청 URL 에 대한 매핑 컨트롤러 정보는 ReqeustMapping 필드를 통해 보유하고 있다.

유심해서 볼 부분은 DispatcherServlet 을 프론트 컨트롤러 패턴 을 활용하여 구현했다는 점이다. move() 메소드를 보면 각 서블릿에서 서블릿과 JSP 사이를 이동하기 위해 모든 중복 코드를 이곳에서 담당하고 있으며, 이를 프론트 컨트롤러 패턴이라고 한다. DispatcherServlet 은 모든 컨트롤러 앞단에서 모든 요청을 가장 먼저 받아 각 컨트롤러에게 작업을 위임한다.

@WebServlet(name = "dispatcher", urlPatterns = "/", loadOnStartUup = 1)
public class DispatcherServlet extends HttpServlet {
  private static final long serialVersionUID = 1L;
  private static final Logger logger = LoggerFactory.getLogger(DispatcherServlet.class);
  private static final String DEFAULT_REDIRECT_PREFIX = "redirect:";

  private RequestMapping rm;

  @Override
  public void init() throws ServletExcepton {
    rm = new RequestMapping();
    rm.initMapping();
  }

  @Override
  protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOExcpetion {
    String requestUri = rqe.getRequestURI();

    Controller controller = rm.findController(requestUri);
    try {
      String viewName = controller.execute(request, response);
      move(viewName, request, response);
    } catch(Throwable e) {
      logger.error("Exception : {}", e);
      throw new ServletException(e.getMessage());
    }
  }

  private void move(String viewName, HttpServletRequest request, HttpServletResponse response) throws ServletExcpetion, IOException {
    if(viewName.startsWith(DEFAULT_REDIRECT_PREFIX)) {
      resp.sendRedirect(viewName.subString(DEFAULT_REDIRECT_PREFIX.length()));
      return;
    }
    RequestDispatcher rd = req.getRequestDispatcher(viewName);
    rd.forward(request, response);
  }
}

2단계. AJAX 기반 MVC 프레임워크로 개선

위 1단게 구현까지 마쳤다면 그것만으로 훌륭한 구현 코드라고 생각할 수 있으나, 아쉽게도 위 코드는 JSON 데이터를 응답하지 못한다. 즉, SSR 기반 HTML 정적 데이터 타입만을 응답하도록 구현된 코드이다. 따라서 HTML, JSON 2가지 형태를 모두 응답하는 MVC 프레임워크로 개선해보았다.

기존 Coneroller 의 문제점

앞서 보여줬던 컨트롤러 구현체중 하나다. 이 컨트롤러 구현체 하나만 놓고 본다면 썩 문제점이 발생하지 않을 것 같고, 기존 MVC 프레임워크 코드만으로도 원활히 동작할 것 으로 보인다.

public class ListUserController implements Controller {
  @Override
  public String execute(HttpServletRequest request, HttpServletResponse response) throws Exception {
    if(isLogined(request.getSession())) {
      return "redirect:/users/loginForm";
    }
    req.setAttribute("users", Database.findAll());
    return "/item/list.jsp";
  }

  private boolean isLogined(HttpSession session) {
    // ...
  }
}

하지만 아래 컨트롤러를 보면 2가지의 문제점을 가지고있다. 우선 JSON 으로 응답을 보내는 경우 이동할 JSP 페이지가 없으니 불필요하게 null 을 리턴하고 있다. AJAX 에서 사용할 컨트롤러를 리턴값이 굳이 필요없다. 이 문제가 발생한 원인은, 기존과 달리 컨트롤러에서 응답할 뷰 타입이 JSP 하나에서 JSP, JSON 2가지로 늘어났기 떄문이다.

또한 자바 객체를 JSON 으로 변환하고 응답하는 부분에서 중복이 발생한다. 중복 코드를 최소화할 필요가 있다.

public class DeleteAnswerController implements Controller {
  @Override
  public String execute(HttpServletRequest request, HttpServletResponse response) {
    Long answerId = Long.parseLong(req.getParameter("answerId"));
    AnswerDao answerDao = new AnswerDao();
    answerDao.delete(answerId);

    ObjectMapper mapper = new ObjectMapper();
    response.setContentType("application/json;charset=UTF-8");
    PrintWriter out = response.getWriter();
    out.print(mapper.writeValueAsString(Result.ok()));
    return null; // 불필요하게 null 을 리턴
  }
}

ModelAndView

위 2가지 문제점을 해결할 수 있는것은 바로 ModelAndView 라는 추상화 클래스를 만드는 방법에 있었다. 이 클래스는 (1) 기존에는 JSP 뷰 타입만을 리턴했다면, 이젠 다른 종류의 뷰인 JSON 도 응답할 수 있도록 기능을 제공한다. 또한 (2) 컨트롤러의 exetute() 메소드에서 HttpServletRequest 타입으로 전달되는 모델 데이터를 별도의 Map 을 활용해 타입을 변환하여 전달하도록 한다.

여기서 (2) 를 해야하는 이유가 있다. 만약 ModelAndView 에 Map 으로 변환하는 코드가 없는 경우라면, HttpServletRequest 에 추가되어 있는 모든 데이터를 JSON 으로 변경한다. 그런데 HttpServletRequest 의 경우 서블릿 필터, 서블릿의 여러 단계를 거치면서 개발자가 모르는 상태에서 추가 데이터가 발생할 수 있다. 이 경우 개발자가 의도치 않게 불필요한 데이터가 모두 JSON 으로 변환되어 클라이언트 응답으로 보내질 수 있으므로, HttpServletRequest 를 통해 데이터를 전달하지 않고 개발자가 원하는 데이터만 정확하게 뷰에 전달할 수 있도록 모델 데이터에 대한 추상화 작업을 진행해야 하는 것이다.

이로써 뷰를 포함해 모델 데이터에 대한 추상화를 담당하는 클래스인 ModelAndView 를 따로 분리시켰다.

public class ModelAndView {
  private View view;
  private Map<String, Object> model = new HashMap<>();

  public ModelAndView(View view) {
    this.view = view;
  }

  public ModelAndView addObject(String attributeName, Object attributeValue) {
    model.put(attributeName, attributeValue);
    return this;
  }

  public Map<String, Object> getModel() {
    return Collections.unmodifiableMap(model);
  }

  public View getView() {
    return view;
  }
}

View

ModelAndView 를 보면 View 타입 필드가 있는것을 볼 수 있다. JSP 와 JSON 뷰를 추상화 한 것이다. 이 인터페이스의 구현체로 JspView, JsonView 를 만들었다. 간단한 if-else 분기 처리로 뷰 타입에 따른 로직을 수행하지 않고 따로 클래스로 분리시킴으로써 다양한 뷰 타입에 대한 유연한 확장을 가능하도록 했다. JSP, JSON 외의 신규 뷰 타입이 추가될 경우 추가 View 구현 클래스를 만들면 된다.

또한 render() 메소드를 보면 모델 데이터를 파라미터로 전달할 수 있도록 했다.

public interface View {
  void render(Map<String, ?> model, HttpServletRequest request, HttpServletResposne response) throws Exception;
}

JspView

JSP 에 대한 페이지 이동 처리를 담당한다. 이동할 뷰 이름을 생성자로 받은 후, render() 메소드를 호출 시 해당 페이지로 이동하도록 했다. 이 부분은 기존의 DispatcherServlet 의 move() 메소드 구현 부분을 render() 메소드 내에다 옮겼다.

public class JspView implements View {
  private static final String DEFAULT_REDIRECT_PREFIX = "redirect:";
  private String viewName;

  public JspView(String viewName) {
    if(viewName == null) {
      throw new NullPointerExcpetion("viewName is null. 이동할 URL 을 입력해주세요.");
    }
    this.viewName = viewName;
  }

  @Override
  void render(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception {
    if(viewName.startsWith(DEFAULT_REDIRECT_PREFIX)) {
      response.sendRedirect(viewName.substring(DEFAULT_REDIRECT_PREFIX.length()));
      return;
    }

    Set<String> keys = model.keySet();
    for(String key : keys) {
      request.setAttribute(key, model.get(key));
    }

    RequestDispatcher rd = request.getRequestDispatcher(viewName);
	rd.forward(request, response);
  }
}

JsonView

JSON 데이터 응답을 담당할 View 이다. 이동할 URL 이 없기 떄문에, render() 메소드는 HttpServletRequest 를 통해 전달되는 자바 객체를 JSON 으로 변환한 후 응답하는 기능을 가지도록 구현했다.

public class JsonView implements View {
  @Override
  public void redner(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception {
    ObjectMapper mapper = new ObjectMapper();
    response.setContentType("application/json;charset=UTF-8");
    PrintWriter out = response.getWriter();
    out.print(mapper.writeValueAsString(model));
  }
}

Controller 리팩토링

컨트롤러가 이젠 JSP 외에 JSON 타입도 지원해야 하므로, 기존에 String 타입을 리턴했던 코드를 ModelAndView 를 리턴하도록 개선했다.

public interface Controller {
    ModelAndView execute(HttpServletRequest req, HttpServletResponse resp) throws Exception;
}

AbstractController

ModelAndView 생성을 더 쉽도록 돕기 위한 추상 클래스다.

public abstract class AbstractController implements Controller {
  protected ModelAndView jspView(String forwardUrl) {
    return new ModelAndView(new JspView(forwardUrl));
  }

  protected ModelAndView jsonView() {
    return new ModelAndView(new JsonView());
  }
}

Controller 구현 클래스

기존에 Controller 인터페이스를 구현했던 구체 컨트롤러를 이젠 AbstractController 를 상속하도록 개선했다. AbstractController 메소드인 jsonView() 를 통해 손쉽게 ModelView 오브젝트를 리턴하는 것을 볼 수 있다.

public class AddAnswerController extends AbstractController {
    private static final Logger log = LoggerFactory.getLogger(AddAnswerController.class);

    @Override
    public ModelAndView execute(HttpServletRequest req, HttpServletResponse resp) throws Exception {
        Answer answer = new Answer(req.getParameter("writer"), req.getParameter("contents"),
                Long.parseLong(req.getParameter("questionId")));
        log.debug("answer : {}", answer);

        AnswerDao answerDao = new AnswerDao();
        Answer savedAnswer = answerDao.insert(answer);
        resp.setContentType("application/json;charset=UTF-8");
        return jsonView().addObject("answer", savedAnswer);
    }
}

DispatcherServlet 리팩토링

마지막 작업으로 DispatcherServlet 이 JSP 뷰 타입만을 지원하기 위해 String 을 리턴했다면, 이젠 ModelAndView 뷰 타입을 리턴하도록 개선했다.

@WebServlet(name = "dispatcher", urlPatterns = "/", loadOnStartup = 1)
public class DispatcherServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;
    private static final Logger logger = LoggerFactory.getLogger(DispatcherServlet.class);
    private static final String DEFAULT_REDIRECT_PREFIX = "redirect:";

    private RequestMapping rm;

    @Override
    public void init() throws ServletException {
        rm = new RequestMapping();
        rm.initMapping();
    }

    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        String requestUri = req.getRequestURI();
        logger.debug("Method : {}, Request URI : {}", req.getMethod(), requestUri);

        Controller controller = rm.findController(requestUri);
        ModelAndView modelAndView;
        try {
            modelAndView = controller.execute(req, resp);
            View view = modelAndView.getView();
            view.render(modelAndView.getModel(), req, resp);
        } catch (Throwable e) {
            logger.error("Exception : {}", e);
            throw new ServletException(e.getMessage());
        }
    }

    private void move(String viewName, HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        if (viewName.startsWith(DEFAULT_REDIRECT_PREFIX)) {
            resp.sendRedirect(viewName.substring(DEFAULT_REDIRECT_PREFIX.length()));
            return;
        }

        RequestDispatcher rd = req.getRequestDispatcher(viewName);
        rd.forward(req, resp);
    }
}

마치며

이로써 다양한 뷰 타입을 지원할 수 있는 MVC 프레임워크를 구현해봤다. 아직 100% 소화된 느낌은 아니기에, 조금 더 추가 학습을 해봐야겠다 🙂

다음은 어노테이션 기반 MVC 프레임워크를 구현한 내용에 대해 다루고자 한다.

OSI 7계층의 물리, 데이터 링크 계층(1~2계층)

Tue, 05 Nov 2024 00:00:00 GMT

OSI 에 대한 전반적인 개요는 OSI 7계층, TCP/IP 프로토콜의 기본 규약 정리 를 참고하자.

물리 계층(Physical Layer)

OSI 7계층에서 최하위에 위치한 물리 계층은 컴퓨터들을 물리적으로 연결하거나 데이터를 전기 신호 *로 변환하고 제어하는 역할을 한다. 이때 전기 신호에는 아날로그, 디지털 신호 2가지 종류가 존재한다.

송신자가 수신자에게 데이터(문장)를 전송하는 과정은 먼저 (1) 문장을 0과 1로 구성된 비트로 변환하고 (2) 해당 비트를 전기 신호(디지털 신호)로 변환한 후 (3) 수신자에게 해당 디지털 신호를 전달한다. 이후 (4) 수신자 측에서는 전기 신호(디지털 신호)를 다시 0과 1로 구성된 비트로 변환한다.

랜 카드(LAN Card)

이때 직전에 설명한 과정속에서 (1) 에서 (2) 로 넘어갈 때, 즉 전기 신호를 변환하는 것은 랜 카드가 해주는 것이다. 즉, 랜 카드란 전기 신호를 변환하는 역할로써, 데이터가 내 컴퓨터 밖을 나가는 출발점이라고 할 수 있다.

정리하자면, 랜 카드란 0과 1의 비트를 전기 실호로 변환하여 밖으로 내보내는 출발점 역할을 한다.

케이블

한편 케이블은 랜 카드가 내보내는 전기 신호를 다른 곳으로 전달하는 역할을 수행한다. 즉, 케이블이란 컴퓨터, 서버, 라우터 및 다른 네트워크 장치간에 데이터 신호를 전달하는 역할을 한다.

케이블은 구리선과 광섬유로 구성되며, 동축 케이블 이 가장 많이 사용되는 케이블 종류다. 동축 케이블은 중앙의 구리선에 흐르는 전기 신호로 데이터를 주고받는다. 한편 컴퓨터에서 사용되는 꼬임선 방식 으로도 케이블을 구성할 수 있는데, 이는 말 그대로 몇 개의 전선들을 꼬아서 만든 케이블이다. 이 꼬임선 방식을 이용하는 케이블의 종류로는 UTP, FTP, STP 가 존재한다.

꼬임선 방식에 대해 더 자세히 설명하는 것은 현재 나에겐 불필요한 지식이라고 판단되어 설명을 생략한다.

리피터 vs 허브

리피터 (하위호환)

물리 계층에서 사용하는 장비로는 리피터 와 허브 가 있다. 리피터(Reapter) 란 전기 신호를 "증폭" 하는 기능을 가진 장치이다. 전기 신호를 전송할 때 거리가 멀어지면 신호가 감쇠되는 성질이 있느데, 이때 감쇠도니 신호를 다시 재생하여(증폭시켜서) 전다랗는 장치가 리피터다. 하지만 요즘 시대에선 리피터를 거의 사용하지 않는데, 이 기능을 허브라는 장치에서 대신해주기 때문이다.

허브 (상위호환)

허브는 리피터의 확장 버전이라고 보면된다. 즉, 허브는 전송되는 (1) 데이터 신호를 정형하고 증폭하여 데이터 왜곡을 보정하며, 하나의 입력 신호를 여러 디바이스로 복제하여, (2) 데이터에 대한 분배 및 네트워크 확장을 지원한다.

리피터가 1:1 통신만 가능하다면, 허브는 포트를 여러개 가지고 있기 때문에 여러대의 컴퓨터와 연결할 수 있다. 그래서 요즘 시대에는 리피터가 아닌 허브를 사용하고 있다.

cf) 더미 허브

허브는 다음과 같은 특징이 있다.

각 컴퓨터가 허브로 데이터를 보낼 수 있다.

그러면 허브에 연결된 모든 컴퓨터가 데이터틀 받는다. 이와같잉 허브는 특정 컴퓨터를 지정하여 데이터를 보낼 수 없다고 하여 더미 허브(Dummy Hub) 라고도 부른다.

1계층(물리 계층) 설명 요약

지금까지 설명한 것을 요약하면, 1계층에서는 랜 카드를 이용해서 데이터를 전기 신호(디지털 신호)로 변환한 후 케이블을 통해 데이터를 전송한다. 또한 1계층에 사용하는 장비로는 리피터와 허브가 있으며, 요즘 리피터는 잘 사용하지 않는다.

데이터 링크 계층(Data Link Layer)

데이터 링크 계층은 (1) 데이터를 작은 프레임 단위로 분할하고, MAC 주소를 활용하여 장비를 식별한다.

또한 (2) 오류를 탐지하고 수정하는 역할을 하며, 데이터를 원활한 흐름과 네트워크 매체에서 충돌 관리도 수행한다. 네트워크에서 여러 기기가 동시에 데이터를 전송하려고 하면 신호 충돌이 발생할 것이다. 이 상황에서 데이터를 동시에 전송하면 여러 데이터가 충돌하게 되어 제대로 전달되지 않는데, 그래서 이러한 오류 탐지 및 수정 역할을 수행하는 것이다.

오류를 감지하거나 수정하는 방법에는 크게 3가지가 있는데, 회선 제어, 오류 제어, 흐름 제어 에 대해 알아보자.

회선 제어

회선 제어는 오류를 감지하기 보다는 회피 하는 방법으로, 신호 간 충돌 현상이 발생하지 않도록 제어하는 기법이다. 그러기위해 신호의 시작을 의미하는 ENQ(Enquiry) 와 끝을 의미하는 EOT(End of Transmission) 를 명시적으로 지정한다. 수신자는 송진자로부터 신호를 받으면 "응! 문제없이 잘 받았어." 라는 ACK 을 송신자에게 보내서 신호를 정상적으로 수신헀음을 알린다. 이러면 신호 간 충돌을 피할 수 있다.

즉, 송신자와 수신자 사이에선 다음과 같은 플로우로 회선 제어가 적용된다. 송신자 입장에서의 플로우는 다음과 같다.

ENQ 를 전송 -> ACK 받음 -> 데이터 전송 -> ACK 받음 -> EOT 전송

오류 제어

오류 제어는 송수신 데이터가 외부 간섭, 시간 지연등에 의해 데이터가 변형되거나 순서가 어긋나는 등 통신 장애가 발생하지 않도록 오류를 검출하고 정정하여 통신에 대한 신뢰성을 확보하는 기법이다.

패리티 검사

오류 검사로 사용되는 것 중에 패리티 검사하는 것이 있다. 패리티 검사(parity check) 란 수신자에게 보내는 최종 데이터의 1의 개수를 짝수개로 보낼지, 홀수개로 보낼지 송.수신자가 미리 약속하고 여분의 비트(패리티 비트) 를 채워서 보내는 방법이다.

예를들어 송.수신자가 1을 짝수개로 보내겠다고 미리 약속한다. 그리고 데이터에 1이 4개라면 송신자는 전송하려는 데이터 내부에서 남은 여분의 비트(패리티 비트)에다 0을 추가적으로 첨부해서 보내는 것이다. 수신자는 전달받은 데이터에서 패리티 비트를 조회하여 0이라면 문제가 없다고 판단하게 되고, 반대로 1이 조회된다면 통신간에 문제가 발생헀다고 판단할 수 있다. 이런 방법으로 송.수신에 사용된 데이터가 문제없음을 보장할 수 있다.

CRC, 검사 합(Check Sum), 해밍 코드(Hamming Code)

패리티 검사 외에도 CRC(Cyclic Redundancy Check) 나 검사합(Check Sum) 등의 기법도 있다.

CRC 는 데이터에 CRC 코드를 추가하여 오류를 감지하는 방법으로, 송신자가 CRC 코드를 생성하고 수신자 측에서도 동일한 계산을 수행하여 일치 여부를 확인하는 방법이다.

검사 합 은 데이터의 각 바이트 값을 더하거나 연산하여 생성되는 값이다. 송신자가 데이터와 관련된 검사합을 계산하고 수신자 측에서도 동일한 계산을 수행하여, 두 검사합 값이 일차하면 데이터가 오류없이 전송된 것으로 간주하게 된다.

해밍 코드 는 데이터가 추가적인 패리티 비트 여러개를 포함시킨다. 이 패리티 비트들은 데이터 비트와 조합되어 특별한 방식으로 구성된다. 패리티 비트들을 분석하여 오류가 발생한 비트를 식별하고, 해당 비트의 값을 수정함으로써 오류를 정정한다.

흐름 제어

흐름 에저는 송신자와 수신자의 데이터 처리 속도 차이를 해결하기 위해 수신자 상황에 따라 송신자의 데이터 전송량을 조절하는 기법이다.

정지-대기(Stop & Wait)

흐름 제어로 사용되는 방법 중 하나가 정지-대기 기법이다. 송신자가 하나의 데이터를 전송한 후 다음 데이터르 전달하기 전에 확인 응답을 기다리는 방법이다.

예를들어 수신자가 ACK 메시지를 송신자에게 완전히 전달하고 난 뒤에서야 다음 데이터를 천천히 보내는 방법이 정지-대기 기법에 해당한다.

이더넷

이더넷(Ethernet) 이란 다수의 컴퓨터, 허브, 스위치 등을 하나의 인터넷 케이블에 연결한 네트워크 구조다. LAN 과 WAN 에서도 이더넷을 사용한다.

CSMA/CD 프로토콜

이더넷은 CSMA/CD 라고 하는 프로토콜을 사용한다. 2대 이상의 여러 컴퓨터가 동시에 데이터(프레임) 을 보내면 충돌이 발생할 수 있을 것이다. 이런 충돌 현상을 방지하기 위해 이더넷에서는 전류의 강도를 확인해 케이블이 사용 중인지 여부를 확인하는 CSMA/CD 방식을 사용한다. 즉, 송신전에 케이블이 사용 가능한지 확인하고(Carrier Sense), 사용 가능하면 데이터를 전송(Multiple Access)한다. 또한 전송 이후에도 여전히 발생할 수 있는 충돌을 수시로 확인한다.

정리하자면, 이 기법은 (1) 전류의 강도를 확인하여 송신전에 케이블이 사용 가능한지 확인한다. 그러고 (2-1)전류의 강도 세기가 높다면 데이터를 전송하지 않고 강도가 낮아질 떄까지 대기했다가 천천히 데이터를 송신하게 된다. (2-2) 반대로 강도가 낮다면 데이터를 바로 송신한다.

마치 비유를 하자면 CSMA/CD 는 각 컴퓨터끼리 충돌을 방지하기 위해, 데이터를 전송하기 전에 서로 눈치 게임을 하고 있는것이다.

다만 스위치(Switch) 장비가 충돌 방지 역할을 대신 해주고 있기 때문에, CSMA/CD 는 현재 잘 사용되지 않는 기법이다.

MAC 주소

MAC(Media Access Control) 주소는 랜 카드에 할당된 값이며, 전 세계에서 하나밖에 존재하지 않는 고유한 값이다.

비트 체계

MAC 주소는 48비트로 표현된다. 상위 24비트는 OUI 라고 해서 랜 카드 제조사에 부여된 코드이며, 하위 24비트는 UAA 라고하여 제조사가 랜 카드에 부여한 고유 번호이다.

이더넷 헤더 구성요소

발신자 컴퓨터가 데이터를 전송할 때 2계층에서 MAC 주소를 헤더에 넣어 프레임을 생성하게 된다. 이때 헤더가 추가되는 MAC 주소는 송신자의 MAC 주소뿐 아니라 발신자의 MAC 주소도 모두 함께 프레임에 추가된다. 또한 유형(type) 이라는 프로토콜 정보도 이더넷 헤더에 추가된다. 유형이란 IPv4, IPv6, ARP 프로토콜 중에서 어떤 프로토콜인지에 대한 정보이다.

정리하자면, 2계층에서 이더넷 헤더에 추가되는 정보는 (1) 발신자 MAC 주소, (2) 수신자 MAC 주소, (3) 프로로콜 유형(type) 이렇게 3가지가 된다.

ARP 프로토콜이란?

이때 ARP(Address Resolution Protocol) 이란 IP 주소와 MAC 주소를 매핑하기 위한 프로토콜이다. 즉, ARP 프로토콜은 IP 주소에 해당하는 MAC 주소를 매핑하기 위한 프로토콜이다.

ARP 프로토콜을 이용해서 MAC 주소를 알아내는 과정을 다음과 같다.

(1) ARP 요청(브로드캐스팅): 컴퓨터 A는 허브에 묶여있는 모든 컴퓨터에게 192.168.0.3 이라는 IP 주소에 대응하는 MAC 주소를 묻는다. 이렇게 모든 컴퓨터에게 질의하는 것을 브로드캐스트 라고 하며, MAC 주소를 묻는 것을 ARP 요청 이라고 한다.

(2) ARP 응답: 그러면 모든 컴퓨터는 자신의 IP 를 192.168.0.3 과 비교한다. 결국 192.168.0.3 IP 를 사용하는 컴퓨터 B가 A의 요청에 응답할텐데, 이때 컴퓨터 B의 MAC 주소를 전달한다. 이를 ARP 응답 이라고 한다. 이후 컴퓨터 A는 컴퓨터 B의 IP 와 MAC 주소를 메모리에 저장하는데, 이것을 ARP 테이블 이라고 한다. 앞으로 컴퓨터 A가 B와 통신하고자 할 떄는 일일이 물어보는 것이 아니라, 자신의 ARP 테이블을 참조한다.

(3) 이제 컴퓨터 A는 B의 MAC 주소를 알게 되었으므로 이 2대의 컴퓨터는 통신이 가능한 상태가 된다.

이때 중요한 것은 MAC 주소 확인은 LAN 환경(우리 집이나 학교등에서만) 안에서만 확인 가능하므로, WAN 환경에서의 MAC 주소는 라우터 장비를 거쳐야만 확인 가능하다.

스위치(Switch)

스위치는 2계층에서 사용되는 장비로, 허브와 유사한 특징을 지니고 있다. 허브의 경우, 해당 허브에게 연결되어 있는 모든 컴퓨터에게 데이터가 전송된다. 반면 스위치는 연결되어 있는 컴퓨터들 중에서 데이터를 받아야하는 특정 컴퓨터에게만 전달할 수 있다.

정리하자면, 스위치란 소규모 네트워크 안에서 모든 장치(컴퓨터)를 서로 연결해서 데이터를 쉽게 공유할 수 있도록 하는 장비로, 허브와 달리 특정 장치에만 데이터를 송.수신할 수 있어 효율성이 높다.

스위치에서 MAC 테이블 관리하기

스위치는 허브처럼 데이터를 공유하는 기능 외에도, 스위치 포트에 연결된 컴퓨터의 MAC 주소를 관리하는 기능도 있다. MAC 테이블이란 "1번 포트의 MAC 주소는 무엇이다" 와 같이 스위치에서 각 포트에 대한 MAC 주소를 매핑하는 역할을 한다.

스위치는 처음부터 모든 컴퓨터의 MAC 주소를 MAC 테이블에 보유하고 있는 것이 아니기 떄문에, MAC 테이블에 필요한 컴퓨터의 MAC 주소를 추가한다. 스위치에 물려있는 모든 컴퓨터에게 데이터를 보내서 MAC 주소를 얻어내고, 그 정보들을 MAC 테이블에 업데이트하는 플러딩(Flooding) 과정이 발생한다. 또한 업데이트된 MAC 테이블을 정보를 기반으로, 스위치에 연결된 특정 컴퓨터에게만 데이터를 송.수신하는 MAC 주소 필터링 과정이 발생한다.

단방향 통신과 앙방향 통신

단방향 통신(Simplex Transmission)

앞서 말헀듯이 여러대의 컴퓨터가 동시에 데이터를 보내면 충돌이 발생할 수 있다. 충돌이 발생하는 이유는 컴퓨터간에 단방향 통신을 하기때문이다. 단방향 통신(Simplex Transmission) 은 선로(채널)가 하나만 있기 떄문에 일방 통행만 가능하다.

앙방향 통신(Duplex Transmission)

단방향 통신은 생각해보면 한 번애 여러개의 데이터를 주고받지 못하기 때문에 비효율적이다. 그래서 등장한 통신방식이 양방향 통신으로, 하나의 통신 채널에서 송수신이 모두 가능한 방시기다. 이에는 반이중 방식 과 전이중 방식 2가지 종류가 있다.

반이중 방식(Half Duplex)

반이중 방식은 양쪽 방향에서 통신이 가능하지만 동시에 통신할 수는 없다. 한쪽에서 데이터를 보내면 다른 쪽에서는 수신만 가능하다. 하지만 아쉽게도 반이중 방식도 충돌 현상이 여전히 발생한다. 채널을 여전히 1개만 사용하기 떄문에 충돌이 발생할 수 밖에 없다.

전이중 방식(Full Duplex)

반이중 방식의 충돌 현상을 방지하고자 등장한 방식이다. 이 방식은 채널(선로) 를 2개 두어서 양쪽 방향에서 동시에 데이터를 주고받을 수 있는 방식이며, 스위치에서 사용된다. 채널을 2개나 사용하므로 얖선 충돌 문제를 해결할 수 있다.

마치며

다음에는 OSI 3~5계층에 대해 다루고자 한다.

OSI 7계층의 네트워크, 전송, 애플리케이션 계층 (3,4,7 계층)

Sun, 03 Nov 2024 00:00:00 GMT

OSI 에 대한 전반적인 개요는 OSI 7계층, TCP/IP 프로토콜의 기본 규약 정리 를 참고하자.

네트워크 계층(Network Layer)

라우터

가령 학교A 에서 학교B 로 이메일을 보내야하는 상황을 가정해보자. 이 상황에선 이전에 다루었던 2계층 장비인 스위치로는 전송이 불가능하다. 스위치로 전송할 경우, 연결되어 있는 컴퓨터들중에 어떤 컴퓨터로 보내야할지 MAC 주소를 물어야한다. 하지만 어떤 MAC 주소로 보내야할지 알아내는 것은 같은 스위치로 연결된 경우에만 가능하다. 정리하자면, 스위치는 연결되어 있는 컴퓨터들중에 특정 컴퓨터에게만 MAC 주소를 알아내고 데이터를 전송할 수 있다는 특징이 있었기 떄문에, 이와 같이 연결되지 않은 네트워크 상의 지역끼리는 통신이 불가능하다.

그래서 필요한 것이 3계층 장비인 라우터이다. 2계층 장비인 스위치가 LAN 단위의 근거리 통신을 담당할 수 있다면, 3계층 장비인 라우터는 WAN 단위의 광범위 네트워크 통신을 담당한다. 라우터는 데이터가 어떤 경로로 전달되어야 하는지를 알려주는 내비게이션과 같은 역할을 한다. 어떤 길이 가장 빠른지 결정하는 것이다. 그리고 어떤 길이 가장 빠른 길인지 찾는 과정을 라우팅(Routing) 이라고 한다. 또한 라우터는 스위치와는 다르게 IP 주소를 이용해서 통신을 한다.

OSI 7계층의 네트워크 계층에서 추가되는 헤더 정보는 IP 주소이다. 네트워크 계층에서 헤더가 추가될때 다양한 정보가 추가되지만, 우리가 가장 주목해서 봐야할 부분은 송신자와 수신자의 IP 주소이다.

IP 주소

LAN 환경에서는 스위치를 이용하여 MAC 주소로 통신한다. 하지만 여기에는 치명적인 단점이 있다. 인터넷이 바로 접속할 수 없고, 우리 회사(근거리 통신망) 이외의 컴퓨터와 통신이 불가능하다. 그래서 필요한 것이 바로 IP 주소이다. IP(Internet Procotol) 이란 인터넷상에 있는 컴퓨터의 고유한 주소이다.

공인, 사설 IP

공인 IP 는 인터넷 서비스 제공자(SKT, KT, ...) 에 의해 전 세계적으로 고유하게 할당되는 IP 주소이다. 이 공인 IP 주소는 주기적으로 변경된다는 특징을 지닌다.

반면 사설 IP 는 주로 기업 내부에서만 사용되는 IP 주소로, 기업밖에 위치한 컴퓨터와는 통신이 불가능하다.

IP 주소 체계

IP 주소의 길이는 4바이트, 즉 32 비트로 구성된다. 마지막 1바이트의 가장 작은 수인 0과 작은 큰 수인 255는 용도가 정해져있기 떄문에 컴퓨터의 IP 주소로 사용하지 않는다. 아래와 같이 마지막 1바이트가 0인 주소를 네트워크 주소라고 한다. 네트워크 주소 는 네트워크를 통칭하기위해 사용되는 주소이다. 또한 마지막 1바이트가 255인 경우를 브로드케스트 주소라고 한다. 브로드케스트 주소는 네트워크에 연결된 컴퓨터에 데이터를 한 번에 일괄적으로 전송할 때 사용하는 주소다.

192.168.2.0 // => 마지막 1바이트인 "0" 이 네트워크 주소임.
192.168.2.255 // => 마지막 1바이트인 "255" 이 브로드케스트 주소임.

IP 주소의 구조

IP 주소에는 많은 정보가 포함되어 있다. IP 주소는 네트워크 ID 와 호스트 ID 로 구분할 수 있다. 호스트 ID 는 라우터에 연결된 개별 컴퓨터들을 관리하기 위해 사용된다. 즉, 호스트 ID 는 개별 컴퓨터들이 사용하는 것이고, 네트워크 ID 는 컴퓨터가 많을 경우 관리의 어려움이 있기 떄문에 네트워크의 범위를 지정해(컴퓨터들의 집합) 관리를 쉽게 하기위해 사용한다.

예를들어 네트워크 A에 포함된 컴퓨터 A, B, C 의 IP 주소가 다음과 같다고 해보자. 이때 컴퓨터 A의 네트워크 ID 와 호스트 ID 는 다음과 같다.

// NetWork A
컴퓨터 A: 192.168.1.2  // 네트워크 ID: 192.168.1 / 호스트 ID: 2
컴퓨터 B: 192.168.1.3  // 네트워크 ID: 192.168.1 / 호스트 ID: 3
컴퓨터 C: 192.168.1.4  // 네트워크 ID: 192.168.1 / 호스트 ID: 4

IP 주소의 클래스

공인 IP 주소에는 A~E 까지의 5개의 클래스가 있다. 또한 클래스 A 에서 E 로 내려갈수록 호스트 ID 의 개수가 줄어든다. 클래스의 A의 경우 IP 주소의 4바이트 중에서 첫 바이트가 네트워크 ID 를 의미하고, 나머지 3개의 바이트는 호스트 ID 를 뜻한다. 즉, 클래스 A에선 하나의 네트워크가 가질 수 있는 호스트 ID 가 가장 많은 클래스로써, 컴퓨터들에게 할당할 IP 가 가장 많다는 것이된다.

반면 B 클래스의 경우 A 클래스에서 네트워크 ID 가 하나 줄어든 형태이다. 앞의 2개의 바이트가 네트워크 ID 를 나타낸다. 이와 같은 동일한 원리로 C 클래스는 B 클래스에서 네트워크 ID 가 하나씩 줄어든다.

또한 각 클래스의 맨 앞 비트들은 각각 A, B, C 순으로 "0, "10", "110", ... 의 순으로 고정되어 있다.

브로트캐스트, 유니캐스트, 멀티캐스트

네트워크에서 데이터를 주고받는 방식에는 브로드캐스트, 유니캐스트, 멀티캐스트가 있다. 이들에 대해서도 정리해보자.

브로드캐스트 (BroadCast)

브로드캐스트는 같은 네트워크에 속한 모든 컴퓨터에게 데이터를 전달하는 방식이다. 허브와 비슷한 방식이다. 그런데 수신자 입장에선 내가 원하지 않더라도 일방적으로 배느는 정보를 받아야한다. 따라서 데이터를 수신하는 컴퓨터는 그 정보가 필요한지 판단해야하는 번거로움이 있다.

유니캐스트 (Unicast)

반면 유니캐스트는 1:1 통신 이다. 같은 네트워크에 여러대의 컴퓨터가 있을 때 특정한 1대의 컴퓨터에만 데이터를 보내고자 할때 사용한다. 이때 유니케스트로 통신하기 위해선 당연하게도 상대방의 MAC 주소를 알아야만 통신이 가능하다.

멀티케스트 (MultiCast)

멀티케스트는 브로드캐스트와 유니캐스트를 섞어놓은 방식이다. 같은 네트워크에서 데이터를 보내고 싶은 컴퓨터가 1대라면 상대방의 MAC 주소를 확인하는 것은 어렵지않다. 하지만 그 대상이 2대 이상이라면 꽤 번거롭다. 이떄 사용하는 것이 멀티캐스트다. 멀티캐스트란 특정 그룹을 지정해서 그 그룹에 해당하는 컴퓨터에게만 데이텅를 보내는 방식이다.

서브넷, 서브넷 마스크

서브넷이란 하나의 네트워크 주소를 작은 단위로 쪼개서 사용하는 것이다. 또한 서브넷과 서브넷 마스크는 앞서 살펴봤던 네트워크 ID 와 호스트 ID 를 이용한다.

그런데 A 클래스, B 클래스, C 클래스를 각각 하나의 네트워크로 사용하는 것은 비효율적인 방법이다. 하나의 네트워크에 속한 모든 컴퓨터는 브로드캐스트 주소로 오는 데이터를 모두 수신해야하고, 그것이 내가 필요한 정보인지 필터링해야한다. 그래서 하나의 네트워크를 좀 더 효율적인 방법으로 사용해보고자 등장한 개념이 바로 서브넷이다. 서브넷은 하나의 네트워크가 분할된 작은 네트워크다. 이때 작은 네트워크로 나누는 작업을 서브넷팅(Subneting) 이라고 한다.

서브넷팅의 원리

서브넷팅의 원리는 간단한다. IP 주소에는 네트워크 ID 과 호스트 ID 가 있을텐데, 네트워크 ID 는 그대로두고 호스트 ID 를 쪼개는 방식이다. 이때 호스트 ID 를 쪼개는 개수가 적을수록 사용 가능한 호스트(컴퓨터) 주소가 많아진다.

서브넷팅을 네트워크 맥락에서 표현하면 다음과 같다.

호스트 ID 를 서브넷 ID 와 호스트 ID 로 나누는 작업

즉, 호스트 ID 를 서브넷 ID 와 호스트 ID 로 분리하는 작업이 서브넷팅이다.

서브넷 마스크

IP 주소를 서브넷팅하면 네트워크 ID 와 호스트 ID 의 경계를 판별하기가 어려울 때가 많은데, 이때 서브넷 마스크를 사용한다. 즉, 서브넷 마스크란 IP 주소에서 네트워크 ID 와 호스트 ID 를 구분하기 위한 구분자이다.

다음 2가지 표현을 보자. 아래에서 "/24" 와 "255.255.255.0" 은 표현만 다를 뿐 모두 같은 의미의 서브넷 마스크에 대한 표현이다.

192.168.1.1/24
255.255.255.0

그럼 위와 같은 "/24" 혹은 "255.255.255.0" 은 어떻게 얻을 수 있을까? 서브넷 마스크는 1과 0의 조합으로 구성되긴 하지만 아래처럼 1이 연속적으로 나온 이후 0이 연속적으로 나오는 형태를 취한다. 또한, 서브넷 마스크를 구하기 위해서는 네트워크 ID 는 모두 1로 채우고 호스트 ID 는 0으로 채운다.

예를들어 아래 그림과 같이 C 클래스의 경우 24비트가 네트워크 ID 이다. 따라서 24비트 1의 값을, 나머지 8비트에 해당하는 호스트 ID는 0으로 채워주면 다음과 같이 255.255.255.0 의 값이 나온다. 그리고 "/24" 가 의미하는 것은 네트워크 ID 의 비트 수이다. 24비트가 모두 1의 값을 가지기 떄문에 "/24" 라고 표현하는 것이다.

// C 클래스의 서브넷 마스크
2진수: 11111111 11111111 11111111 00000000   // => 네트워크 ID 비트 수가 24개이다.
10진수: 255     255      255      0

라우터의 동작 방식

앞서 간단히 살펴봤듯이, 라우터는 이름 그대로 데이터의 전송을 위해 가장 빠른 길을 찾아 네트워크 간의 경로(route) 를 설정하는 장비이다.

2계층의 장비인 스위치는 같은 네트워크 (LAN 범위) 내에서만 통신이 가능한 장비라고 했다. 즉, 서로 다른 네트워크 간의 통신은 불가능했다. 그래서 서로 다른 네트워크 간의 통신을 위해서는 라우터를 사용해야 한다. 예를들어 "172.16.1.0/24" 네트워크와 "172.16.2.0/24" 네트워크는 서로 다른 네트워크이다. 이 둘 간에 통신이 가능하려면 라우터가 필요하다.

라우팅

그런데 서로 다른 네트워크 간에는 1개 이상의 라우터가 존재할 수 있다. 이러한 경우, 어떤 경로로 이동해야 빠른 통신이 가능한지 확인해야한다. 즉, 네트워크와 네트워크 간의 데이터 이동시 가장 빠른 경로(route) 를 설정해야 하는데, 이를 라우팅이라고 한다. 다시 말해서, 라우팅은 한 네트워크에서 다른 네트워크로 데이터를 전달하는 과정이다.

라우팅 테이블

그런데 라우팅시 경로는 어떻게 설정할까? 스위치에서 MAC 테이블을 이용했던 것과 같이 라우터에서는 라우팅 테이블이라는 것을 이용한다. 라우팅 테이블은 데이터를 목적지까지 보내기 위한 거리과 방법등을 명시한 테이블이다.

라우팅 테이블에는 데이터를 목적지로 전달하기 위해 어떤 방향(인터페이스라고도 부름)으로 가야 하는지에 대한 정보를 가지고 있다. 따라서 라우터가 데이터를 목적지로 보내려고 하면 라우팅 테이블을 찾아보게 된다.

예를들어 컴퓨터 A가 컴퓨터 B에게 데이텅를 보내려는 간단한 상황을 가정해보자. 먼저 라우터 A는 컴퓨터 B의 네트워크 주소를 확인한다. 그러고 컴퓨터 B로 가는길이 정의되어있는지 라우팅 테이블을 검색한다. 그랬더니 라우팅 테이블에 컴퓨터 B 네트워크로 가려면 E1 경로로 가라는 내용이 있다면, 이제 라우터 A는 라우터 B에게 컴퓨터 B의 IP 주소가 무엇인지 물어보기만 하면된다.

전송 계층 (Transport Layer)

전송 계층은 기본적으로 (1) 오류를 점검하는 기능(즉 데이터를 목적지에 문제없이 전달하는 기능) 과 (2) 컴퓨터가 제대로 데이터를 받았을 경우 어떤 애플리케이션으로 전달해야 하는지를 식별하는 기능을 담당한다. 이전에 2계층에서 살펴봤던 오류 점검 방식이 현재 전송 계층에도 존재한다.

혼잡 제어

혼잡 제어(Congestion Control) 은 네트워크로 들어가는 정보량을 조절하여 네트워크가 혼잡해지지 않게 조절하는 방법이다. 이를위해 송신자는 먼저 하나의 데이터만 보내고 수신자 측에서 ACK 가 오면 전송량을 2배씩 증가시켜 나간다.

그러다가 타임아웃이 발생하면 여러개 보냈던 데이터를 줄여서 보낸다. 또는 동일한 ACK 을 여러번 받는 경우에도 데이터를 줄여서 보내는 방식을 취한다. (타임아웃이나 ACK 을 여러번 받았다는 것은 네트워크가 데이터를 실어 나르느라 바쁘다는 뜻이니) 이후 정상적인 ACK 을 받게되면 또 다시 데이터를 배수로 전송함으로써 데이터 전송량을 조절한다.

흐름 제어

흐름 제어는 데이터 링크 계층에서 사용했던 정지-대기(Stop & Wait) 방식과 완전히 동일하다. 정지-대기 방식은 송신자가 하나의 데이터를 전송한 후 다음 데이터를 전달하기 전에 확인 응답을 기다리는 방법이다. 예를들어 수신자 측에서 ACK 이라는 메시지가 송신자 측에 전달되어야만 다음 데이터를 보내는 방식이다.

오류 제어

오류 제어도 마찬가지로 데이터 링크 계층의 오류 제어 방식과 동일하다. 하지만 방법은 조금 다르다. 오류를 검출하기 위해서는 확인 응답과 시간 초과 방법 을 사용한다.

(1) 확인 응답: 수신자 측으로부터 ACK 이라는 응답을 받아야하지만 ACK 이 없다면 오류로 판단한다.

(2) 시간 초과 방법: 특정 시간 내에 ACK 이 없으면 세그먼트에 오류가 있다고 판단한다.

3-way handshake

전송 계층은 데이터를 목적지에 문제없이 전달하는 것을 목표로 한다. 이떄 데이터를 전달하는 목적에 따라 연결형과 비연결형 통신으로 나뉜다.

연결형 통신: 데이터를 정확하게 전달하는 것을 목표로 하는 통신. TCP 프로토콜을 사용한다.

비연결형 통신: 효율적으로 데이터를 보내는 통신. UDP 프로토콜을 사용한다.

TCP 프로토콜은 3-way handshake 방법을 통신을 시작한다. TCP 프로토콜이 데이터를 전달하는 것을 목표로하기 때문에 상대방이 내 신호를 받을 수 있는 상태인지 확인하고 전송하는 방식이다. 즉, 3-way handshake 는 TCP 통신을 하는 장치(컴퓨터)간에 서로 통신할 준비가 되었는지를 확인하는 과정이다.

3-way handshake 의 과정은 다음과 같은 수행된다.

(1) 송신자는 연결 요청을 위해 임의의 SYN 번호를 수신자에게 보낸다.
(2) 수신자는 요청을 잘 받았다는 의미로 송신자에게 받은 SYN 번호에 1을 더해 ACK 을 보낸다. 또한, 수신자도 연결을 요청하는 의미로 SYN 에 임의의 번호를 보낸다.
(3) 송신자는 연결이 수립되었다는 의미로 수신자로부터 받은 SYN 에 1을 더해서 수신자에게 ACK 을 보낸다. 그럼 이제 통신을 위한 연결이 수립된 것이다.

위와 같은 3 way handshake 를 이용하면 송신자와 수신자 양츩 모두 데이터를 전송할 준비가 되었다는 것을 보장한다.

TCP 의 구조

전송 계층에선 헤더 정보에서 포트 번호를 포함한 다양한 정보들이 포함된다. 각 정보들을 상세하게 살펴보자.

1. 포트 번호

가장 중요한 포트번호이다. 전송 계층은 어떤 애플리케이션과 통신하는지 정의하는 곳이라고 했다. 그 기능을 하는것이 포트 번호이다. 포트 번호의 각 카테고리는 다음과 같다.

0 ~ 1023번: 잘 알려진 포트(well-known port) 로, 말 그대로 특정한 쓰임을 위해 사용된다.

1024 ~ 49151번: 기관이나 기업들이 사용하는 포트로, 사전 등록된 포트(registered port) 라고도 한다.

49152 ~ 65535번: 일반 사용자들이 자유롭게 사용할 수 있는 포트로, 다이나믹 포트(dynamic port) 라고도 한다.

2. 일련번호와 확인 응답 번호

포트번호 외에도 일련번호, 확인 응답 번호가 헤더에 추가된다. 일련번호 는 송신자가 수신자에게 보내려는 데이터가 몇 번째인지 알려주는 것이고, 반대로 확인 응답 번호 는 수신자가 몇 번째 데이터를 받았는지 송신자에게 알려주는 역할을 한다. 이 둘을 이용해서 수신한 데이터가 순서는 맞는지, 오류는 없는지 검사할 수 있다.

예를들어 다음과 같은 송신자가 수신자에게 데이터르 보내는 상황을 가정해보자.

보내야 할 총 데이터 크기 : 1500바이트
패킷의 크기: 500바이트

이떄 패킷의 크기란 한번에 보낼 수 있는 데이터의 최대 크기이다. 즉, 한번에 보낼 수 있는 최대 크기가 500 바이트라는 것이다. 따라서 1500바이트의 데이터를 보내기 위해서는 총 3번에 걸쳐 보내야한다. (500바이트씩 3번이면 1500바이트가 되므로) 따라서 일련번호는 이렇다. 처음의 일련번호가 1이라고 가정할 떄 다음의 일련번호는 501, 또 다음은 1001 이다.

확인 응답 번호는 수신자가 몇번쨰 데이터를 받았는지 송신자에게 알려주는 역할을 한다.

3. 윈도우 크기

설명에 앞서, 상황을 하나 가정해보자. 수신자가 받을 수 있는 데이터의 양은 적은데, 송신자가 그것을 공려하지 않고 많은 양의 데이터를 보낸다면 어떤 일이 발생할까? 송신자는 모든 데이터를 보냈다고 생각하곘지만, 수신자는 송신자가 보낸 데이터를 받아들이지 못하고 일부는 거절당한다. 그러면 정상적인 통신이 불가능해질 것이다. 그래서 등장한 것이 윈도우 크기다.

윈도우 크기(Window Size) 란 송신자가 한 번에 보낼 수 있는 데이터의 최대 크기이다. 즉, 수신자가 얼마나 데이터를 받아들일 수 있는지 확인한 후, 그 크기를 고려해서 데이터를 보내겠다는 의도인 것이다.

수신자의 윈도우 크기는 3-way handshake 과정에서 알아낼 수 있나. 헨드쉐이크 과정에서 SYN, ACK 외에도 Window Size 라는 정보를 주고받게 도니다. 이렇게 확인된 윈도우 크기를 이용하면 더 효윯적인 데이터 전송이 가능하다. 매번 데이터를 보내고 ACK 을 기다리는 것이 아니라, 수산자가 받을 수 있을만큼 데이터를 한 번에 보내면 된다.

4. 코드 비트

코드 비트는 헨드쉐이크 과정에서 세부 상태를 표현하낟. 모두 기본값은 0이며, 비트가 활성화되면 1이 된다.

TURG: 긴급 처리 데이터가 있음
ACK: 확인 응답 번호 사용
SYN: 연결을 초기화하기 위해 순서 번호를 동기화
FIN: 데이터 송신 종료
... (이하 생략)

UDP 프로토콜

UDP 는 TCP 와 달리 신뢰성이 보장되지 않으며, 데이터 전송 속도가 빠른 프로토콜이다. 데이터를 수신자 측에서 오류없이 받던간에 상관없이 데이터를 보내기만 하면 되며, 브로트캐스트시 사용되는 프로토콜이 UDP 이다.

UDP 프로토콜에서 사용되는 헤더는 TCP 와 비교했을 때 상당이 축약된 정보만 포함하고 있다. 신뢰성을 보장하지 않기 때문이다. UDP 헤더내에 송.수신자의 포트번호 와 헤더 길이, 검사 합(CheckSum) 정도의 정보만 포함한다.

응용 계층

응용 계층은 평소 서버 개발시 자주 사용하기에, 이미 잘 알고이는 지식들이 대부분이다. 따라서 다른 계층에 비해 설명은 많이 생략하도록 한다.

HTTP 프로토콜

HTTP(HyperText Transfer Protocol) 은 클라이언트와 서버가 어떻게 데이터를 교환할지 정해놓은 규칙으로, 80번 포트를 사용한다.

HTTP 버전

현재 HTTP 버전은 1.0, 1.1, 2.0 순서로 진화했다. HTTP 프로토콜에는 자체적으로 정의한 헤더가 있어서 HTTP 버전 정보, 상태 정보등 여러 정보를 서버로 보낼 수 있게 되었다. 하지만 매 요청마다 연결을 수립하는 과정을 반복하다 보니, 이것을 처리하는 서버의 성능이 저하되는 문제점이 있었다.

그래서 등장한 것이 HTTP 1.1 이며 현재 가장 많이 사용하는 버전이다. HTTP 1.1 부터는 keep-alive 기능이 추가되어 연결이 1번 수립되면 데이터 교환을 마칠 때까지 연결을 유지하고, 데이터 교환이 끝나면 연결을 끊는 구조이다. 한편 HTTP 2.0 부터는 응용 계층이 바이너리 프레임(Binary Frame) 을 추가하여 기존의 일반 텍스트 데이터를 바이너리로 변환한 후 데이터를 분할하여 보낸다. 이렇게 하면 전송 속도가 빨라지고 오류 발생 가능성도 낮아진다.

DNS 서버

IP 주소를 도메인 주소로 변경해주는 것이 DNS 서버이다. 사용자가 가령 Google 웹 브라우저에서 랜더링을 요청하며, 해당 요청은 DNS 서버로 전송된다. 만약 이떄 DNS 서버가 google 의 IP 주소를 모른다면 또 다른 DNS 서버에 질의해서 IP 주소를 전달받는다.

DHCP 서버

DHCP 서버는 IP 주소를 자동으로 관리하기 위해 등장했다. DHCP(Dynamic Host Configuration Protocol) 서버는 사용자들에게 IP 주소를 할당하거나 회수하는 것을 자동으로 해주는 서버다.

OSI 7계층, TCP/IP 프로토콜의 기본 규약 정리

Fri, 01 Nov 2024 00:00:00 GMT

네트워크를 다시금 공부하면서 장기 기억화를 위해 글을 작성한다. OSI 의 각 계층에 대해선 향후 포스트에서 자세히 다루도록 할 것이며, 현 포스트에선 네트워크의 전반 흐름에 대해 오버뷰로 간단히만 다루도록 한다.

랜(LAN) 과 웬(WAN)

네트워크를 이해하려면 통신 범위의 단위인 LAN 과 WAN 에 대해 선수로 알아야한다. 랜(LAN, Local Area NetWork) 란 좁은 범위내에 특정 지역을 범위로 하는 네트워크를 뜻하며, 웬(WAN, Wide Area NetWork) 이란 2개 이상의 LAN 을 연결한 광범위의 네트워크를 뜻한다. 또한 LAN 은 WAN 에 비해 비교적 근거리 통신망 형태로 구축되므로 전송 속도가 매우 빠르다.

LAN

특히 LAN 의 구성방법에 대해 자세히 알 필요가 있다. 랜의 구성 방법, 즉 네트워크 접속 형태는 다음과 같이 3가지 방식으로 구할 수 있다. (3가지 이상의 다양한 방식으로 LAN 을 구성 가능하지만, 이 정도만 알아도 충분할 것으로 보인다.)

스타형 (star) : 하나의 허브(Hub) 에 여러대의 컴퓨터를 연결하는 방식

링형 (ring) : 개별 컴퓨터가 서로 원(circle) 형태로 연결되는 방식

버스형 (bus) : 하나의 긴 케이블에 컴퓨터를 포함한 모든 주변 장치를 연결하는 방식

한편 WAN 은 LAN 과 달리 광범위한 영역을 커버해야 하기 때문에 LAN 과 같은 별도의 네트워크 접속 형태가 없다. 이미 LAN 에서 접속 형태를 정의헀으니, 또 다시 네트워크를 구성할 필요가 없기 때문이다. 네트워크 망을 구축시 LAN 사이에 통신이 잘 이루어지도록 연결만 해주면 된다.

네트워크 기본 구성장치

컴퓨터와 컴퓨터간에 통신하기 위해선 다양한 접속 장치가 필요하다. 접속 장치에 대해 자세한 설명은 향후 포스트에서 자세히 다룰것이므로, 여기선 간단히 장치의 종류만 언급하겠다.

컴퓨터 A, 컴퓨터 B 가 있다고 가정했을 때 이 둘은 서로 통신하기 위해 허브, 스위치, 라우터등의 네트워크 장치가 필요하다. 가령 이 예시의 경우 컴퓨터 A 가 B 에 대해 데이터를 통신하기 위해선 아래와 같은 플로우로 통신하게 된다.

컴퓨터 A -> 허브1 -> 스위치A -> 라우터 -> 스위치B -> 허브2 -> 컴퓨터B

반대로 컴퓨터 B 에서 A 방향으로 통신하길 원한다면 위 플로우와 반대 방향으로 이루어질 것이다.

각 장치에 대한 기능을 정리해보면 다음과 같다.

허브: 여러대의 컴퓨터를 연결할 때 사용하는 장치

스위치: 대역폭을 확대해주는 장치

라우터: 컴퓨터 B를 찾아가기 위한 길을 제시하는 장치

브리지: 2개 이상의 네트워크를 연결하기 위한 장치로, 데이터를 한 곳에서 다른 곳으로 전달하는 역할

이때 브리지는 OSI 7계층에서 각 상.하위 계층간에 데이터를 전갈할 때 다리 역할을 하는 것으로 이해하면 된다. 또한 스위치를 설명할 때 대역폭 이란 키워드가 등장했는데, 대역폭이란 1초당 처리할 수 있는 데이터의 양을 의미한다. 다시 말해, 대역폭이 넓을 수록 해당 네트워크가 동일한 시간내에 처리할 수 있는 양은 커지는 것이다.

OSI 7계층

프로토콜(protocol) 이란 컴퓨터나 원거리 통신 장비 사이에서 메시지를 주고받는 양식과 규칙의 체계를 뜻한다. 쉽게말해, 컴퓨터 세계에서 형식적으로 나누는 인사 과정을 뜻한다. 네트워크를 조금이라도 접해봤으면 알듯이, OSI 7계층 과 TCP/IP 4계층 이 대표적인 프로토콜이다. 이들의 간단한 오버뷰에 대해 알아보자.

OSI 7계층의 등장배경, 필요성

1980년대 부터 시작하여 "다양한" 통신 기술, 컴퓨터의 생산은 급격히 증가했다. 이에따라 당연하게도 컴퓨터간의 통신을 위해 각 회사마다 각기 다른 다양한 허브, 스위치, 라우터 장치를 생산하기 시작했다. 이렇듯 다양한 제조사에서 만든 컴퓨터와 허브, 스위치, 라우터를 서로 연결하여 통신할 떄 각기 다른 통신방법, 프로토콜을 사용하게 되었다.

이에 따라 OSI 프로토콜 표준 규약이 등장했다. 제조사마다 각기 다른 자신들만으 프로토콜을 사용하기 때문에 호환성을 보장하기 위해 등장했다. 다양한 장치가 서로 간의 통신을 보장할 수 있는 규악이며, 각 계층별로 필요한 장치들을 정의했기 때문에 제조사들은 통신에 필요한 프로토콜을 통일할 수 있게 되었다.

OSI 7계층

OSI 7계층은 컴퓨터와 컴퓨터가 통신하는 구조를 7개의 계층으로 정의해둔 약속, 즉 프로토콜이다.

각 계층에 대한 특징은 다음과 같다.

7계층(Application Layer): 사용자와 애플리케이션 간의 소통을 정의함.

6계층(Presentation Layer): 데이터를 어떻게 표현할지 정의함.

5계층(Session Layer): 통신을 설정, 관리, 종료함.

4계층(Transport Layer): 신뢰성있는 정확한 데이터를 전달함.

3계층(Network Layer): 네트워크 장치간의 경로 선택과 데이터를 전송함.

2계층(Data Link Layer): 물리적인 연결을 위해 오류없는 데이터를 전달함.

1계층(Physical Layer): 전기 신호를 이용해서 통신 케이블로 데이터를 전송함.

송신자가 데이터를 전송할 때는 캡슐화, 반대로 수신자가 데이터를 전달받을때는 역캡슐화 가 발생한다. 캡슐화는 7계층에서 1계층 방향으로, 반대로 역캡슐화는 1계층에서 7계층으로 발생하면서 각 계층을 지나칠 때 마다 헤더(Header) 라는 단위가 덧붙여진다(해제된다).

이때 각 계층에서 덧붙여지는 헤더(Header) 는 각 계층마다 다른 이름으로 부른다. 각 계층에서 사용하는 전송 단위인 헤더를 나열해보면 다음과 같다.

응용 계층부터 세션 계층까지(7~5계층): 데이터(메시지)

전송 계층(4계층): 세그먼트(segment)

네트워크 계층(3계층): 패킷

데이터 링크 계층(2계층): 프레임

물리 계층(1계층): 비트

다시 설명하자면 캡슐화 과정이 일어날 떄 한 단계씩 아래로 내려가면서 통신을 위한 정보인 헤더가 하나씩 붙게된다. 세그먼트 에서는 포트 번호, 패킷 에서는 송.수신자의 IP 주소, 프레임 에서는 송.수신자의 MAC 주소가 붙게 된다.

반대로 역캡술화 과정이 발생할땐 헤더 정보가 하나씩 벗겨진다. 데이터 링크 계층(프레임)에선 수신자가 MAC 주소를 획득하고, 네트워크 계층(패킷)에선 IP 주소, 전송 계층(세그먼트)에선 포트번호를 획득하게 된다.

VPN

마지막으로 VPN 에게 소개하곘다. VPN(Virtual Private Network) 란 인터넷을 통해 데이터를 안전하게 전송하기 위한 기술이다.

인하대학교 학사관리 시스템을 예로 들어보겠다. 가령 인하대학교 본교(본교는 인천시 미추홀구에 위치해있음) 의 학사관리 시스템이 있을 때, 학교의 중요한 기밀 정보를 외부에서 함부로 접근하지 못하도록 신경써야 할 것이다. 여기서 하나 가정을 더 붙여보자면, 인하대학교 본교가 아닌 제2 캠퍼스가 송도가 있다고 해보자. 이때 학사관리 시스템은 본교(미추홀구) 에 위치해있게 때문에 제2 캠퍼스(송도)에서 근무하는 교직원들에게도 특별히 외부 접근 권한을 부여해야 한다. 이때 VPN 이라는 것을 이용하면 제2 캠퍼스 교직원들이 학사관리 시스템이 접속하여 중요한 정보를 가져올 수 있다.

VPN 의 동작방식

VPN 은 일반적으로 다음과 같은 방식으로 동작한다.

(1) VPN 클라이언트 소프트웨어 섩치

(2) VPN 서버 연결 및 인증

(3) 데이터 암호화

(4) 터널링

우선 (1) 먼저 컴퓨터에 VPN 클라리언트 소프트웨어를 설치해야 한다. 인하대학교 제2 캠퍼트에서 근무하는 교직원들으 경우 자신의 노트북에 VPN 클라이언트를 설치해야 한다. 이후 (2) 설치된 VPN 클라이언트를 이용하여 VPN 서버에 연결해야 한다. 이때 사용자 이름과 암호를 사용하여 인증을 한다.

(3) VPN 연결이 설정되면 모든 데이터는 암호화되어 전송된다. 이는 데이터가 인터넷을 통해 전송될 때 누구나 볼 수 없게 만들어준다. 마지막으로 (4) VPN 은 암호화된 데이터를 전송하기 위해 터널링 기술을 사용한다. 터닐링(Tunneling) 이란 본교와 제2 캠퍼스 간에 마치 터널이 뚫린 것처럼 네트워크 사이에 통로를 설정하는 것을 말한다.

이후 통신이 종료되면 VPN 터널은 종료되고 VPN 연결도 종료된다.

마치며

다음 포스트부터 본격적으로 OSI 7계층에 대해 다루고자 한다.

레거시 DAO 를 리팩토링하며 JDBC 라이브러리 구현하기

Mon, 28 Oct 2024 00:00:00 GMT

JDBC 라이브러리 구현하기 를 진행해보면서, 학습한 내용을 정리했다.

JDBC

과거 HTTP 웹 서버가 가지고 있었던 문제는 사용자가 입력한 데이터가 서버를 재시작하면 사라진다는 점이다. 따라서 DB 서버를 도입해야 하는것은 당연시 되었다. 자바 진영에서 JDBC 표준 인터페이스를 정의하고 있으며, 우리는 이를 활용하여 데이터베이스와의 통신을 할 수 있게된다.

그런데 이떄, JDBC 는 인터페이스 정의 만을 제공하고 있다. 즉, JDBC 는 데이터베이스 통신을 위한 규악만 정하고, 이에대한 구현체는 데이터베이스를 만들어 서비스하는 회사가 직접 구현하고 제공하도록 하고있다. 서블릿도 마찬가지다. 서블릿 또한 인터페이스만 정의하고 서블릿 컨테이너를 만들어 제공하는 회사 또는 단체가 이 인터페이스에 대한 구현체를 제공하도록 하고 있다.

정리하면, 이처럼 표준만 정의함으로써 DB 에 대한 연결설정만 변경해 다른 DB 를 지원함으로써 소스코드의 변경을 최소화하고 있다.

JDBC API

JDBC API 를 통해 데이터베이스에 접근할 때, API 내부 코드에선 정말 많은 중복 코드가 발생한다. 그래서 이 중복 코드를 제거한 라이브러리가 바로 JdbcTemplate 이다. 즉 JdbcTemplate 이란 JDBC API 의 중복 코드를 제거한 SQLMapper 라고 볼 수 있다.

이 라이브러리가 어떻게 등장했는지를 다루어보겠다. 우선 중복 코드가 많은 순수 JDBC API 레거시 코드를 점진적으로 중복 코드를 제거하면서, JdbcTemplate 를 모방한 코드를 직접 구현해보겠다.

레거시 UserDao

UserDao 의 초기 레거시코드다. DAO 오브젝트를 통해 데이터베이스에 대한 접근 로직 처리를 담당하도록 되어있다.

현재 초기 Dao 는 JDBC API 를 직접 사용하여 DataSource 생성하고, 커넥션을 획득 및 해제하며, 예외처리 작업을 모두 담당하고 있다. 그래서 가독성 및 생산성이 저하된다. 무엇보다 아까 언급했던 중복 코드가 여러 메소드에서 발생하고 있다. 따라서 이를 제거해야 함을 신경쓰면서 라이브러리를 구현해야했다. 구현한 세부 단계들을 천천히 살펴보자.

public class UserDao {
    public void insert(User user) throws SQLException {
        Connection con = null;
        PreparedStatement pstmt = null;
        try {
            con = ConnectionManager.getConnection();
            String sql = "INSERT INTO USERS VALUES (?, ?, ?, ?)";
            pstmt = con.prepareStatement(sql);
            pstmt.setString(1, user.getUserId());
            pstmt.setString(2, user.getPassword());
            pstmt.setString(3, user.getName());
            pstmt.setString(4, user.getEmail());

            pstmt.executeUpdate();
        } finally {
            if (pstmt != null) {
                pstmt.close();
            }

            if (con != null) {
                con.close();
            }
        }
    }

    public void update(User user) throws SQLException {
        Connection con = null;
        PreparedStatement pstmt = null;
        try {
            con = ConnectionManager.getConnection();
            String sql = "UPDATE USERS SET password = ?, name = ?, email = ?, WHERE userId = ?";
            pstmt = con.prepareStatement(sql);
            pstmt.setString(1, user.getUserId());
            pstmt.setString(2, user.getPassword());
            pstmt.setString(3, user.getName());
            pstmt.setString(4, user.getEmail());

            pstmt.executeUpdate();
        } finally {
            if (pstmt != null) {
                pstmt.close();
            }

            if (con != null) {
                con.close();
            }
        }
    }

    public List<User> findAll() throws SQLException {
    	// ...
    }

    public User findByUserId(String userId) throws SQLException {
    	// ...
    }
    // ...
}

1단계. 중복 로직을 처리할 클래스를 분리

JdbcTemplate

중복 코드를 제거하기 위해 앞서 말한 JdbcTemplate 모방 클래스를 구현했다. 반복적으로 발생하는 중복 로직을 상위 클래스가 구현하고 변화가 발생하는 부분만 추상 메소드로 만들어 구현하도록 하는 템플릿 메소드 패턴 을 적용했다. createQuery() 는 UserDao 로 부터 동적으로 SQL 쿼리문을 전달받으며, setValues() 는 PreparedStatement 를 활용하여 UserDao 에서 동적으로 쿼리문에 전달된 파라미터를 전달받는다.

public abstract class JdbcTemplate {
  public void update() throws Exception {
    Connection con = null;
    PreparedStatement pstmt = null;
    try {
      con = ConnectionManager.getConnection();
      String sql = createQuery();
      pstmt = con.preparedStatement(sql);
      setValues(pstmt);
      pstmt.executeUpdate();
    } finally {
      if(pstmt != null) {
        pstmt.close();
      }

      if(con != null) {
        con.close();
      }
    }
  }

  abstract String createQuery():
  abstract void setValues(PreparedStatement pstmt) throws SQLException;
}

UserDao

실제로 이에 상응하는 UserDao 구현부는 아래와 같이 구현해줬다. 2개의 추상 메소드를 Dao 에서 구현하여 동적으로 쿼리문을 JdbcTemplate 오브젝트에게 전달한다.

public class UserDao {
  public void insert() throws SQLException {
    JdbcTemplate jdbcTemplate = new JdbcTemplate() {
      @Override
      void setValues(PreparedStatement pstmt) throws SQLException {
        pstmt.setString(1, user.getUserId());
        pstmt.setString(2, user.getPassword());
        pstmt.setString(3, user.getName());
        pstmt.setString(4, user.getEmail());
      }

      @Override
      String createQuery() {
        return "INSERT INTO USERS VALUES (?, ?, ?, ?)";
      }
    };
    jdbcTemplate.update();
  }

  // ... (추가 메소드 구현)
}

2단계. SELECT 절을 고려한 리팩토링

mapRow 구현, createQuery 제거

위 JdbcTemplate 코드만으론 SELECT 쿼리문에 대한 처리가 불가능하다. SELECT 절의 경우 INSERT, UPDATE 를 할때와 달리 조회한 데이터를 자바 객체로 변환하는 부분이 추가적으로 필요하다. 그래서 새롭게 추가한 메소드가 mapRow() 이다.

또한 기존의 createQuery() 는 제거했다. 쿼리문은 생각해보면 굳이 추상 메소드로 구현하지 않고도 UserDao 에서 insert(), update() 등의 메소드를 호출할 때 파라미터로 넘겨줄 수 있기 때문이다.

public void abstract class JdbcTemplate {
  public void update(String sql) throws SQLException {
  	// ...
  }

  abstract Object mapRow(ResltSet rs) throws SQLException;
  abstract void setValues(PreparedStatement pstmt) throws SQLException;
}

query, queryForObject 구현

UserDao 의 findUserById(), findAll() 메소드가 활용할 query(), queryForObject() 를 구현했다. 둘 다 조회를 위해 사용될 것이다.

public void abstract class JdbcTemplate {
  public void update(String sql) throws SQLException {
  	// ...
  }

   // 여러건의 데이터 조회
   public List query(String sql) throws SQLException {
     Connection con = null;
     PreparedStatement pstmt = null;
     ResultSet rs = null;

     try {
       con = ConnectionManager.getConnection();
       pstmt = con.prepareStatement(sql);
       setValues(pstmt);

        rs = pstmt.executeQuery();

        List<Object> result = new ArrayList<Object>();
        while(rs.next()) {
          result.add(mapRow(rs)); // SELECT 쿼리를 실행하여 조회된 데이터를 하나씩 리스트에 Add
        }
        return result;
     } finally {
       // ...
     }
   }

   // 한건의 데이터 조회
  public Object queryForObject(String sql) throws SQLException {
    List result = query(sql);
    if(result.isEmpty()) {
      return null;
    }
    return result.get(0);
  }

  abstract Object mapRow(ResltSet rs) throws SQLException;
  abstract void setValues(PreparedStatement pstmt) throws SQLException;
}

UserDao

mapRow() 를 구현한 Dao 코드의 findAll() 구현부는 아래와 같다. 데이터베이스로부터 조회한 데이터는 ResultSet 파라미터에 담기고, 이를 자바 Object 타입으로 (정확히는 User 타입으로) 변환한다.

public List<User> findAll() throws SQLExcpetion {
  @SuperWarnings("unchecked")
  JdbcTemplate jdbcTemplate = new JdbcTemplate() {
    @Override
    void setValues(PreparedStatement pstmt) throws SQLException {
    }

    @Override
    Object mapRow(ResultSet rs) throws SQLException {
      return new User(
        rs.getString("userId"),
        rs.getString("password"),
        rs.getString("name"),
        rs.getString("email"));
      )
    }
  };

  String sql = "SELECT userId, password, name, email FROM USERS";
  return (List<User>)jdbcTemplate.query(sql);
}

3단계. RowMapper, PreparedStatementSetter 인터페이스를 활용

문제점 : 불필요한 mapRow( ) 구현

하지만 여기서 또 문제가 생긴다. UserDao 는 SELECT 절 외에 INSET, DELETE, UPDATE 문을 실행할 땐 굳이 mapRow() 메소드를 구현할 필요가 없음에도, SELECT 절을 위해서 mapRow() 를 구현하는 불편함을 가지고 있다. 실제로 UserDaot 의 insert() 메소드를 살펴보자면 아래와 같다.

public void insert(User user) throws SQLException {
 JdbcTemplate jdbcTemplate = new JdbcTemplate() {
    @Override
    void setValues(PreparedStatement pstmt) throws SQLException {
      pstmt.setString(1, user.getUserId());
      pstmt.setString(2, user.getPassword());
      pstmt.setString(3, user.getName());
      pstmt.setString(4, user.getEmail());
    }

    @Override
    Object mapRow(Resultset rs) throws SQLExcpetion {
      return null;
    }
  };
  String sql = "INSERT INTO USERS VALUES (?, ?, ?, ?)";
  jdbcTemplate.update(sql);
}

이를 해결할 필요가 있다. 이 해결안은 바로 인터페이스에 있다.

인터페이스 추가를 통해 해결하기

mapRow() 를 쓸모없이 구현할 수 밖에 없었던 이유는 JdbcTemplate 와 UserDao 간의 의존관계가 생겨버렸기 때문이다. setValues() 메소드와 mapRow() 메소드를 별도로 분리해 서로 간의 의존관계를 끊어버릴 수만 있다면 더 유연한 개발이 가능해진다. 즉, Dao 의 각 메소드에선 본인에게 필요한 기능만 구현할 수 있게 만들면 된다.

정리하자면, 위 2개의 추상 메소드를 같은 클래스가 가지도록 하지말고, 각 추상 메소드를 인터페이스로 따로 분리시키는 것이다. 아래와 같이 인터페이스를 구현한다.

public interface PreparedStatementSetter {
  void setValues(PreparedStatement pstmt) throws SQLException;
}

public interface RowMapper {
  Object mapRow(ResultSet rs) throws SQLException;
}

또 이를 활용한 리팩토링 코드는 아래와 같다. update, query 메소드만을 가져왔는데, 보듯이 인터페이스 오브젝트를 외부로 부터 필요한 것들만을 선택적으로 주입받고 활용한다.

public class JdbcTemplate {

  // PreparedStatementSetter 를 주입
  public void update(String sql, PreparedStatementSetter pss) throws SQLException {
    Connection con = null;
    PreparedStatement pstmt = null;
    try {
      con = ConnectionManager.getConnection();
      pstmt = con.preparedStatement(sql);
      pss.setValues(pstmt);
      pstmt.executeUpdate();
    } finally {
      if(pstmt != null) {
        pstmt.close();
      }
      if(con != null) {
        con.close();
      }
    }
  }

  // PreparedStatementSetter, RowMapper 를 주입
  public List query(String sql, PreparedStatementSetter pss, RowMapper rowMapper) throws SQLException {
    Connection con = null;
    PreparedStatement pstmt = null;
    ResultSet rs = null;
    try {
      con = ConnectionManager.getConnection();
      pstmt = con.prepareStatement(null);
      pss.setValues(pstmt);
      rs = pstmt.executeQuery();

      // ...
    }
  }
}

4단계. 최종 리팩토링

최종적으로 리팩토링한 전체 코드는 아래와 같다. 특별한것은 없고, 컴파일타임 Exception 인 SQLException 대신 RunTimException 을 상속한 커스터마이징 DataAccessException 을 활용헀다. 제네릭 문법을 활용해 User 타입 외에도 모든 타입에 범용성을 맞추도록 개선했으며, 가변인자를 활용하여 쿼리에 파라미터를 전달하도록 했다.

JdbcTemplate

public class JdbcTemplate {
    public void update(String sql, Object... parameters) throws DataAccessException {
        try (Connection con = ConnectionManager.getConnection();
             PreparedStatement pstmt = con.prepareStatement(sql)) {
                for(int i=0; i< parameters.length; i++) {
                    pstmt.setObject(i+1, parameters[i]);
                }
            /* pss.setValues(pstmt);
            pstmt.executeUpdate(); */
        } catch (SQLException e) {
            throw new DataAccessException(e);
        }
    }

    @SuppressWarnings("rawtypes")
    public <T> List<T> query(String sql, PreparedStatementSetter pss, RowMapper<T> rowMapper) throws DataAccessException {
        ResultSet rs = null;
        try (Connection con = ConnectionManager.getConnection();
             PreparedStatement pstmt = con.prepareStatement(sql)) {

            pss.setValues(pstmt);
            rs = pstmt.executeQuery();

            List<T> result = new ArrayList<T>();
            while(rs.next()) {
                result.add(rowMapper.mapRow(rs, 1)); // SELECT 문으로 조회한 데이터를 자바 객체로 변환
            }
            return result;
        } catch (SQLException e) {
            throw new DataAccessException(e);
        } finally {
            // ...
        }
    }

    @SuppressWarnings("rawtypes")
    public <T> T queryForObject(String sql, PreparedStatementSetter pss, RowMapper<T> rowMapper) throws DataAccessException {
        List<T> result = query(sql, pss, rowMapper);
        if(result.isEmpty()) {
            return null;
        }
        return result.get(0);
    }
}

UserDao

public class UserDao {
    public void insert(User user) throws SQLException {

        JdbcTemplate jdbcTemplate = new JdbcTemplate();

        PreparedStatementSetter pss = new PreparedStatementSetter() {
            @Override
            public void setValues(PreparedStatement pstmt) throws SQLException {
                pstmt.setString(1, user.getUserId());
                pstmt.setString(2, user.getPassword());
                pstmt.setString(3, user.getName());
                pstmt.setString(4, user.getEmail());
            }
        };
        String sql = "INSERT INTO USERS VALUES (?, ?, ?, ?)";
        // jdbcTemplate.update(sql, pss);
        jdbcTemplate.update(sql, user.getPassword(), user.getName(), user.getEmail(), user.getUserId());
    }

    public void update(User user) throws SQLException {
        JdbcTemplate jdbcTemplate = new JdbcTemplate();

        PreparedStatementSetter pss = new PreparedStatementSetter() {
            @Override
            public void setValues(PreparedStatement pstmt) throws SQLException {
                pstmt.setString(1, user.getUserId());
                pstmt.setString(2, user.getPassword());
                pstmt.setString(3, user.getName());
                pstmt.setString(4, user.getEmail());
            }
        };
        String sql = "UPDATE USERS SET password = ?, name = ?, email = ?, WHERE userId = ?";
       //  jdbcTemplate.update(sql, pss);
        jdbcTemplate.update(sql, user.getPassword(), user.getName(), user.getEmail(), user.getUserId());
    }

    public List<User> findAll() throws SQLException {
        JdbcTemplate jdbcTemplate = new JdbcTemplate();
        PreparedStatementSetter pss = new PreparedStatementSetter() {
            @Override
            public void setValues(PreparedStatement pstmt) throws SQLException {
            }
        };

        RowMapper rowMapper = new RowMapper() {
            @Override
            public Object mapRow(ResultSet rs, int count) throws SQLException {
                return new User(
                        rs.getString("userId"),
                        rs.getString("password"),
                        rs.getString("name"),
                        rs.getString("email"));
            }
        };
        String sql = "SELECT userId, password, name, email FROM USERS";
        return (List<User>) jdbcTemplate.query(sql, pss, rowMapper);
    }

    public User findByUserId(String userId) throws SQLException {
        JdbcTemplate jdbcTemplate = new JdbcTemplate();
        String sql = "SELECT userId, password, name, email FROM USERS WHERE userId = ?";
        return jdbcTemplate.queryForObject(sql, (ResultSet rs) -> {
            return new User(
                    rs.getString("userId"),
                    rs.getString("password"),
                    rs.getString("name"),
                    rs.getString("email"));
        }, userId);
    }
}

마치며

JDBC 가 아직 다소 낮선 것 같다. ORM 에 최대한 의존하지 않겠다고 했지만, 역시 근본부터 시작해야 이 기술이 왜 등장했고, 왜 써야하는지를 알 수 있는것 같다. 이번 미션에서도 단순 JDBC API 를 넘어 JdbcTemplate 를 모방하여 구현해보며, SQLMapper 가 얼마나 중복 코드, 레거시 코드를 지양하기 위해 노력했는지 알 수 있었다 🙂

더 학습해볼 키워드

HikariCP

Nginx로 로드밸런싱 환경을 구축해 트래픽 분산시키기

Mon, 28 Oct 2024 00:00:00 GMT

시작에 앞서

서비스 사용자가 늘어남에따라 서버의 부하를 방지하도록 로드밸런싱을 하여 트래픽을 적절히 분산시키는 환경을 간단히 실습해보고자 합니다. 이번 포스팅에서는 Nginx 로 직접 Reverse Proxy 를 셋팅하고 뒷단에 스프링부트 서버 3대를 배치하여, 트래픽을 골구로 분산시키는 것을 구현해 보겠습니다.

다중서버 구축 도메인 설계

저희는 총 4개의 클라우드 서버 인스턴스를 생성해야합니다. 하나는 WS(웹서버)로써 Reverse Proxy 를 위한 Nginx 서버입니다. 나머지 3개의 서버에서는 8080포트로 다른 IP 서버를 구축할겁니다.

클라우드 서버는 EC2 인스턴스를 4개 생성할까 고민했지만, 비용이 많이 나가는 것을 고려하여 Linode 에서 Ubuntu 22.04 LTS 를 기반으로 서버를 구축했습니다.
추가적으로 로드밸런싱 알고리즘은 가장 기본적인 Round Robin(라운드 로빈) 알고리즘으로 트래픽을 분산시켰습니다. (알고리즘에 대한 설명도 할것이니 걱정마세요!)

애플리케이션 설계

동일한 코드를 각 서버에서 실행시킬겁니다. 각 서버에서는 서버이름(serverName) 과 사용자 방문횟수(visitedCount) 를 멤버변수로 가지고 있는 구조입니다.

매 방문마다 어떤 배포 서버에 접속했는지를 알 수 있도록 ServerName 와, 방문횟수를 매번 카운팅하여 몇번 방문했는지를 나타내는 visitedCount 변수의 값을 Map 형태로 리턴받는 구조입니다.

SpringBoot 코드 구현

ServerController

아래와 같이 RestController 하나를 생성하고, 이 컨트롤러로 현재 요청을 보낸 서버에 대한 이름과 방문횟수를 조회할 수 있는 기능을 만들었습니다.

이떄 @PropertySource 어노테이션을 통해 application.yml 에 존재하는 serverName 변수값을 불러왔습니다.

@RestController
@PropertySource(value = "application.yml")
public class ServerController {

    @Value("${serverName}")
    private String serverName;
    private Integer visitedCount = 0;

    @GetMapping("/getServerInfo")
    public ResponseEntity<Map<String, String>> getServerInfo(){
        visitedCount++;

        Map<String, String> serverInfo = new HashMap<>();
        serverInfo.put("ServerName:", serverName);
        serverInfo.put("visitedCount:", visitedCount.toString());

        return ResponseEntity.ok(serverInfo);
    }
}

application.yml

또 아래와 같이 application.yml 파일을 구성해줬습니다. 이떄 중요한 것은 각 서버를 구분짓기 위한 프로필(Profile) 설정을 진행해준 것입니다.

각 서버의 애플리케이션 코드는 모두 동일하나, 단순히 IP, 사용자 정보 정도만 바뀌는 정도라면 이렇게 application.yml 과 같은 설정파일에 프로필을 기록하는 것입니다.

즉, 애플리케이션 코드는 전부 동일한데 설정정보만 조금 다르게 하고 싶다면, 각 서버를 구분지어줄 프로필을 부여하면 됩니다. 그러고 각 서버를 실행시킬때 각각 다른 프로필 정보에 기반해 실행하면 됩니다.

spring:
  config:
    activate:
      on-profile: server1

serverName: my-server1


---
spring:
  config:
    activate:
      on-profile: server2

serverName: my-server2

---
spring:
  config:
    activate:
      on-profile: server3

serverName: my-server3

추후에 클라우드 서버에 올린 jar 파일을 실행할때 위와 같이 프로필 정보를 함께 입력해서 nohup 으로 실행하면, 해당 프로파일의 설정으로 애플리케이션을 시작할 수 있게됩니다.

클라우드 환경 구축

클라우드 서버는 앞서 말씀드렸듯이 1개의 Nginx 서버와, 뒷단에서 스프링부트 애플리케이션이 실행되고 있는 3개의 서버를 구축했습니다. 우선 스프링부트 서버를 어떻게 구축했는지를 설명해보고자 합니다.

스프링부트 클라우드 서버 환경

1.jdk-11 설치

현재 Ubuntu 서버에는 자바가 설치되어 있지 않을겁니다. 자바 설치 여부를 확인해봅시다.

java --version

만일 설치되어 있지 않다면 아래와 같이 자바를 서버에 설치해줍시다. default-jdk 로 jdk 를 설치하는 경우 기본적으로 jdk-11 이 설치된다는 점을 알고 넘어갑시다.

만일 본인의 프로젝트가 JAVA 11 버전이 아니라면 다른 방법을 통해 설치해주셔야합니다!

apt-get update
apt install default-jdk -y

그러고 다시 자바 버전을 확인하여 자바가 정상적으로 설치되었는지 확인해봅시다!

java --version

2.로컬에있는 jar 파일 전송

다음으로 로컬에서 작업한 스프링부트 프로젝트를 빌드하고 생성된 jar 파일을 클라우드 서버에 전송해봅시다. 저는 이번에는 scp 전송을 활용했습니다. (SSH 도 사용해도 되지만, 예전에 사용해본 경험이 있어서 새로운 방식을 택했습니다!)

아래처럼 gradlew 디렉토리에서 booJar 를 통해 프로젝트를 빌드하여 jar 파일을 생성합시다.

$ ./gradlew bootJar

아래처럼 빌드에 성공해야합니다!

그러면 생성된 jar 파일은 build/libs 안에 존재할겁니다.

$ cd build
$ cd libs
$ ls   //  core-0.0.1-SNAPSHOT.jar

3.로컬에 생성한 jar 파일을 클라우드 서버 3개에 각각 전송하기

이렇게 생성된 jar 파일을 클라우드 서버에 전송하면 됩니다. 앞서 말씀드렸듯이 SCP 를 활용했으며, 그 방법은 다음과 같이 진행해주시면 됩니다.

참고로 test-server 란 제가 jar 파일을 제가 새롭게 파일명을 지어준것입니다.

또 당연한 말이지만, 클라우드 서버 인스턴스를 3개 생성했다면 각 서버에 대해 모두 jar 파일을 각각 전송해주셔야합니다!

$ {파일명}.jar root@111.111.111.111:test-server.jar
// build/libs 에서 실행해주세요! (jar 파일에 존재하는 디렉토리에서)

ex) $ scp core-0.0.1-SNAPSHOT.jar  root@111.111.111.111:test-server.jar

jar 파일을 전송할떄 아래와 같이 root 계정의 비밀번호를 입력하도록 해야하는데, 본인의 클라우드 서버의 루트 계정을 입력해주시면 전송에 성공할겁니다.

클라우드 서버에서 jar 파일이 잘 전송되었는지 확인도 해봅시다!

4.스프링부트 애플리케이션 실행하기 (Background 실행)

이제 클라우드 서버에 전송된 jar 파일을 실행시키면 스프링부트 애플리케이션이 배포될 겁니다. 저희는 서버가 다운되는 일이 없도록 nohup 을 통해 무중단배포를 실행할겁니다.

이떄 프로필명을 구분지어서 각 서버에서 다른 프로필에 기반하여 각각의 다른 설정정보를 기반으로 스프링부트 애플리케이션을 실행시켜주셔야 합니다.
아래와 같이 각 3개의 서버에서 프로필명을 각각 server1, server2, server3 로 실행시켜주시면 됩니다.

$ nohup java -jar Dspring.profiles.active="프로필명" test-server.jar &

ex) $ nohup java -jar -Dspring.profiles.active=server1 test-server.jar &

아래와 같이 실행되면 정상입니다.

또 백그라운드에서 스프링부트 애플리케이션이 잘 실행되고 있는지를 확인해봅시다.

$ jobs

Nginx 로드밸런서 서버 구축

다음으로 Nginx 로 로드밸런싱을 해주도록, 인스턴스 서버 하나에 Nginx 를 설치하고 Reverse Proxy 를 셋팅해주겠습니다.

Nginx 설치

아래와 같이 Nginx 를 설치해줍시다.

$ apt install nginx     // nginx 설치
$ serivce nginx start   // 설치한 Nginx 가 정상적으로 반영되도록 재시작
$ ps -ef | grep nginx        // 정상적으로 Nginx가 실행되었는지 확인

Nginx 설정파일 생성

그러고 Nginx 가 로드밸런싱을 하기위한 설정파일을 새롭게 생성해주고, 그 설정파일을 기반으로 뒷단의 스프링부트 애플리케이션에 트래픽이 분산되도록 해야합니다.

기본적으로 Nginx 는 http 요청이 들어왔을때 sites-enabled 디렉토리 안에 있는 파일들의 설정정보를 기반으로 로드밸런싱과 같은 일련의 작업을 수행합니다.
따라서 아래와 같이 sites-enabled 로 이동해서 로드밸런싱을 해주기 위한 새로운 파일을 생성하고, 설정정보를 기입해줍시다.
default 파일은 말그대로 http 요청이 들어왔을때 Nginx 에 어떤 작업을 수행할지에 대한 디폴트 설정정보 파일입니다. 이 디폴트 파일은 삭제시키고 저희만의 새로운 로드밸런싱 관련 파일을 만들어줍시다.

$ cd /etc/nginx/sites-enabled
$ rm -rf default //  default 파일 삭제
$ vi myapp      // nginx 로드밸럱싱 파일에 대한 새로운 파일생성

cf) Nginx 에 대한 설정정보 파일을 스캔하는 디렉토리를 새롭게 설정할 수 있습니다. 즉 sites-enabled 가 아닌 다른 디렉토리로도 설정이 가능합니다. 이는 nginx.conf 에서 수정해주시면 됩니다!

Nginx 로드밸런싱 설정하기

myapp 설정파일 구성

다음으로 이번 포스팅의 핵심인 Nginx 의 로드밸런싱 설정입니다. 직전에 생성한 myapp 에서 아래와 같이 구성해주시면 됩니다.

클라이언트의 모든 요청은 80 포트로 들어오게 됩니다. 80 포트로 들어온 요청을 upstream 에 지정해준 3개의 스프링부트 서버로 로드밸런싱이 진행됩니다.
Nginx upstream 이란?

=> upstream 서버는 말로 Origin 서버라고도 부르비다. proxy_pass 를 통해 Nginx 웹서버가 받은 요청들을 여러대의 스프링부트 애플리케이션 서버로 넘겨주는 역할을 수행합니다.

upstream backend{
        // 로드밸런싱 디폴트 알고리즘 : Round Robin
        server 111.111.111:8080;  // 스프링부트 애플리케이션이 실행되고 있는
        server 111.222.222:8080; // 서버 3개에 대한 IP 주소를 명시해주자!
        server 333.333.333:8080;
}

server{
        listen 80;  // 클라이언트가 요청하는 포트

        location / {
                proxy_pass http://backend;  // 설정한 이름으로 요청 보내기
        }
}
~

설정정보 다시 불러오기

$ nginx -s reload

설정파일인 myapp 을 변경했다면 정상적으로 반영이 되도록, 위 명령을 통해 Nginx 의 설정 파일을 다시 로드하도록 합시다!

트래픽 분산 눈으로 확인해보기

위와 같이 Nginx 설정정보가 반영되었다면 Nginx 서버에 API 요청을 보내봅시다. 그러면 아래와 같은 결과를 확인할 수 있을겁니다!

보시듯이 3대의 서버에 트래픽이 골구로 분산되는 모습을 확인할 수 있습니다.

{
    "ServerName:": "my-server1",
    "visitedCount:": "1"
}
{
    "ServerName:": "my-server2",
    "visitedCount:": "1"
}
{
    "ServerName:": "my-server3",
    "visitedCount:": "2"
}
{
    "ServerName:": "my-server1",
    "visitedCount:": "2"
}
{
    "ServerName:": "my-server2",
    "visitedCount:": "2"
}

{
    "ServerName:": "my-server3",
    "visitedCount:": "2"
}
{
    "ServerName:": "my-server1",
    "visitedCount:": "3"
}
        // ...

로드밸런싱 알고리즘

사실 로드밸런싱을 하는 방법이 다양하다는 사실 알고 계신가요?

위에서 진행한 방식은 Round Robin(라운드 로빈) 알고리즘을 사용해서 트래픽을 분산시킨 것입니다.

별도로 알고리즘을 지정해주지 않으면 라운드 로빈 알고리즘을 사용하는 것이죠.

알고리즘 종류

알고리즘 종류	설명
Round Robin (Defualt)	요청을 순서대로 처리
least_conn	현재 연결수가 가장 적은 서버로 요청을 전송
ip_hash	클라이언트 IP 를 해싱하여 특정 특정 클라이언트가 특정 서버로 연결되게 한다
Random	트래픽을 무작위로 분배
least_time	연결수가 가장 적으면서 + 평균 응답시간이 가장 적은 서버를 선택해서 분배 (Nginx Plus) 에서만 가능

알고리즘과 어떻게 적용시키지?

알고리즘 적용은 앞서 적용했던 Nginx 설정파일에서 upstream 에 지정해주시면 됩니다.

upstream backend{
        leaast_conn;   // least_conn 알고리즘을 적용
        server 111.111.111:8080;
        server 111.222.222:8080;
        server 333.333.333:8080;
}

server{
        listen 80;

        location / {
                proxy_pass http://backend;
        }
}

server 에 대한 다양한 옵션

알고리즘 외에도 다양한 server 지시어에 다양한 옵션을 부여해서 트래픽을 분산시킬 수 있습니다.

weight

특정 서버에 가중치를 설정 가능합니다. 가중치가 설정된 서버는 다른 서버보다 가중치의 배수만큼 트래픽을 받게됩니다.

upstream backend {
  server 111.111.111:8080 weight=4;  // 다른 서버보다 4배의 트래픽을 받는다.
  server 222.222.222:8080;
  server 333.333.333:8080;
}

down

down 옵션을 부여하면 특정 서버로 트래픽이 분배되지 않도록 할 수 있습니다.

upstream backend {
  server 111.111.111:8080 down;  // 2, 3번째 서버만 트래픽을 분배받는다.
  server 222.222.222:8080;
  server 333.333.333:8080;
}

max_conns

서버와의 최대 동시 커넥션 수를 지정된 숫자만큼으로 제한하는 옵션입니다.

upstream backend {
  server 111.111.111:8080 max_conns=10;  // 최대 10개의 트래픽을 분배받는다.
  server 222.222.222:8080;
  server 333.333.333:8080;
}

마치며

지금까지 Nginx 를 통해 로드밸런싱을 진행하고, 뒷단에 존재하는 3대의 스프링부트 서버에 대해 트래픽을 분산시키는 다양한 알고리즘과 옵션에 대해 알아봤습니다. Nginx 를 학습하시는 분들에게 이번 포스팅이 도움이 되었으면 하는 바람입니다 😉

참고

[Nginx] Load Balancing 설정하기 [Nginx] 로드밸런싱 개념 및 구축 WebServer[nginx] nginx 로 로드밸런싱 하기 Nginx 로드밸런싱 적용하기

[springboot] 스프링부트 jar 파일 백그라운드 실행방법 스프링부트 Profile 사용하기 cannot find symbol method value() 에러 해결 nohup 명령어 활용하기

프로세스 및 쓰레드 동기화를 위한 여러 상호배제 기법 (mutex, semaphore, monitor)

Sun, 27 Oct 2024 00:00:00 GMT

스프링 애플리케이션은 멀티 쓰레드 기반으로 동작한다. 이로 인해 공유 자원에 대한 동시성 이슈는 언제든 발생할 수 있다. 경쟁 상태가 발생할 수 있는 조건에 대해 경쟁 상태의 2가지 패턴 - Read-Modify-Write, Check-Then-Act 에서 다룬적이 있으니, 경쟁상태와 임계영역에 대한 설명은 생략한다.

이번 포스팅에선 경쟁상태에 대한 동시 접근 제어 메커니즘 3가지인 뮤텍스, 세마포어, 모니터에 대해 학습해보도록 한다.

상호 배제(Mutual Exclusion)

공유 자원에 대해 다량의 프로세스 또는 쓰레드가 접근하면 경쟁 상태가 발생할 수 있다. 따라서 프로세스나 쓰레드를 동기화(synchornization) 할 수 있는 방법이 필요하다. 이때 동기화란, 공유 자원에 대해 동시에 접근하지 못하도록 접근 순서를 제어하는 방법을 뜻한다.

프로세스 및 쓰레드간 동기화는 일반적으로 상호 배제(Mutual Exclustion) 을 통해 구현할 수 있다. 아래 3가지 방법은 모두 Lock 메커니즘을 기반으로 동작한다. 자원에 접근한 뒤 해당 자원을 잠그고, 자원을 모두 사용하면 잠금을 헤제하는 방식으로 동작한다.

뮤텍스 (Mutex)

뮤텍스는 Mutual Exclustion 의 약자로, 말 그대로 상호 배제를 위한 기법이다. 공유 자원을 사용하기전에 잠그고, 사용을 마쳤다면 잠금을 해제하는 간단한 방식이다. 이때, 잠금이 설정되면 다른 프로세스나 쓰레드는 해당 공유 자원에 접근할 수 없다. 뮤텍스는 (1) 잠김 (2) 잠기지 않음 2가지 상태 상태만을 갖는다.

뮤텍스는 화장실이 하나밖에 없는 식당과 비슷하다. 화장실에 가려면 카운터에서 열쇠를 받아가야 한다. 만약 화장실을 가려는데 카운터에 키가 있으면 사람이 없다는 뜻이고, 그 열쇠를 이용해서 화장실 잠금을 풀고 들어갈 수 있는 것과 유사하다.

세마포어 (Semaphore)

세마포어는 공유 자원에 접근할 수 있는 여러 프로세스 또는 쓰레드의 최대 허용치를 관리하는 정수 타입 변수이다. 만약 정수 값이 5라면, 최대 5개의 프로세스 또는 쓰레드가 공유 자원에 접근할 수 있다. (마치 화장실에 최대 5명의 사용자가 들어갈 수 있는 경우와 비슷하다.)

프로세스 하나가 이 공유 자원에 접근하면 정수 값을 1 감소시키고, 반대로 공유 자원을 모두 사용한 뒤 임계영역에서 프로세스가 하나 나왔다면 다시 정수값을 1 증가시킨다. 여기서 각 과정을 wait() 과 signal() 이라고 한다. 만약 세마포어 값이 0이라면 이 이상 임계영역에 프로세스 또는 쓰레드가 진입이 불가능한 상태가 되며, 1 이상인 양수일 때만이 접근 가능하다.

즉, wait() (또는 P) 가 호출되면 세마포어 정수 값을 1 감소시킨다. 만약 감소시키려는데 세마포어 값이 0이라면, 해당 프로세스는 세마포어 대기열에서 기다려야한다. 반면 signal() (또는 V) 은 세마포어 값을 1 증가시키고, 세마포어 대기열에서 기다리고 있는 맨 앞의 프로세르르 하나 깨워서 임계영역에 진입하도록 한다.

이진 세마포어(Binary Semaphore) vs 계수 세마포어(Counting Semaphore)

세마포어는 정수 값 크기에 따라 이진 세마포어와 계수 세마포어 2가지 종류로 나뉜다. 이진 세마포어는 0 또는 1 값만 가질 수 있다. 이진 세마포어는 마치 뮤텍스와 비슷하게 동작한다. 다만, 뮤텍스는 잠금 메커니즘이고, 세마포어는 신호 기반의 상호 배제 방법이다. 계수 세마포어는 1보다 큰 세마포어 정수를 가질 수 있는 방식이다.

모니터 (Monitor)

세마포어를 사용하기 위해건 임계 영역에 명시적으로 상호 배제 로직을 우리가 직접 구현해야한다. 모니터는 이 상호 배제 로직을 제거하고, 공유 자원 접근에 대한 고수준의 인터페이만을 제공한다. 또한 공유 자원도 외부로부터 캡슐화하여 숨긴다. 즉, 모니터를 사용하며 세마포어를 직접 구현하지 않아도 되고 제공되는 인터페이스만을 사용하여 간편히 상호배제를 보장할 수 있다. 따라서 모니터를 사용하며 세마포어보다 구현 난이도가 매우 쉽고, 실수가 줄어든다. 자바의 synchornized 의 경우가 모니터를 사용하여 구현되었다.

공유 자원에 접근하고자 하는 프로세스 또는 쓰례드는 모니터 내부로 진입해야한다. 모니터는 모니터 큐에 작업 이벤트를 순차적으로 쌓아두고, 한번에 한 프로세스 또는 쓰레드만 임계 영역에 접근할 수 있도록 한다. 즉, 한번에 하나의 프로세스만 모니터에서 작업할 수 있도록 해준다. 개념적으로는 이진 세마포어와 같은 기능을 제공하는 셈이다.

참고

혼자 공부하는 컴퓨터구조, 운영체제 (한빛미디어 강민철 지음)
https://heeonii.tistory.com/14
https://hudi.blog/race-condition-critical-section-mutual-exclusion/#%EB%AE%A4%ED%85%8D%EC%8A%A4-mutex
https://velog.io/@leesfact/뮤텍스-세마포어-모니터

[가상 면접 사례로 배우는 대규모 시스템 설계 기초] 제 1장. 사용자 수에 따른 규모 확장성

Fri, 25 Oct 2024 00:00:00 GMT

수백만 사용자르 지원하는 시스템을 설계하는 것은 도전적인 과제이다. 이번 포스팅에서는 한 명의 사용자를 지원하는 시스템에서 시작하여, 최종적으로는 몇 백만 사용자를 지원하는 시스템을 설계하는 방법에 대해 학습해보도록 한다.

단일 서버

모든 컴포넌트가 단 1대의 서버에서 실행되는 간단한 시스템부터 설계해보자. 일반적으로 아래와 같은 절차로 수행될 것이다.

(1) 사용자는 도메인 이름으로 DNS 에 질의하여 IP 주소를 얻어낸다.
(2) 이 IP 주소로 사용자는 HTTP 요청을 전송한다.
(3) 웹 서버는사용자에게 HTML 웹 페이지를 제공한다.

데이터베이스

사용자가 늘면 서버 하나로는 충분하지 않다. 따라서 여러 서버를 배치해야 한다. 한 서버는 웹/모바일 트래픽 처리 서버이고, 다른 하나는 데이터베이스 서버이다. 이렇게 각 서버를 용도별로 분리하면 각자 독립적으로 확장해 나갈 수 있게 된다.

어떤 데이터베이스를 사용할 것인가?

전통적인 RDBMS 에는 MySQL, Oracle DB, PostgreSQL 등이 있다. RDBMS 는 자료를 테이블과 열, 컬럼으로 표현하며, SQL 을 사용하면 여러 테이블에 있는 데이터를 그 관계에 따라 JOIN 하여 합칠 수 있다.

반면 NoSQL 도 에는 CouchDB, DynamoDB 등이 있다. NoSQL 은 다시 4가지 분류로 나눌 수 있는데, key-value 저장소, 그래프 저장소, 컬럼 저장소, 그리고 문서 저장소로 분류할 수 있다.

NoSQL 을 사용해야 하는 일부 케이스

대부분의 상황에서는 시장에서 40년간 잘 살아남은 RDBMS 를 사용하는 것이 최선이다. 그렇다면, 언제 NoSQL 을 사용하는 것이 바람직할까?

아주 낮은 Latency 가 요구되는 상황
다루는 데이터가 비정형(unstructured) 이라서 관계형 데이터가 아닌 상황
데이터(JSON, XML 등) 를 직렬화하거나 역직렬화 할 수 있기만 하면 되는 상황
아주 많은 양의 데이터를 저장해야 하는 상황

수직적 규모 확장 vs 수평적 규모 확장

수직적 규모 확장(scale up) 은 서버에 고사양 자원을 추가(더 좋은 CPU, 더 많은 RAM 등) 을 추가하는 행위를 뜻한다. 반면 수평적 규모 확장(Scale Out) 은 더 많은 서버를 추가하여 성능을 개선하는 행위를 뜻한다.

서버로 유입되는 트래픽의 양이 적을때는 수직적 확장이 좋은 선택이다. 하지만, 수직적 확장에는 아래와 같은 심각한 단점이 존재하여 대규모 애플리케이션에는 수평적 확장이 더 적절하다.

한 대의 서버에 CPU 나 메모리를 무한대로 증설할 방법은 존재하지 않기에, 언젠가는 분명 서버 사양을 올리는데 한계점에 도달한다.
FailOver 이나 다중화 방안을 제시하지 않는다. 서버에 장애가 발생하면 웹사이트는 완전히 중단된다.

로드밸런서

앞서 살펴본 설계에서는 사용자가 웹 서버에 직접 바로 연결된다. 이 설계 구조는 웹 서버가 다운될 경우 사용자자는 웹 사이트에 접속할 수 없게도니다. 또한, 트래픽이 너무 많아져서 서버가 한계에 도달하면 Latency 가 증가하거나 접속이 불가능해진다. 이 문제를 해결하기 위해 로드밸런서를 도입해야한다.

로드밸랜서는 부하 분산 집합(load balancing set) 에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할을 한다. 사용자는 웹 서버에 직접 접근하는 대신에 로드밸런서의 공개 IP 주소로 접근하게 된다. 따라서, 웹 서버는 클라이언트의 접속을 직접 처리하지 않는다. 일반적으로 보안을 위해 서버간 통신에는 사설(비공개) IP 주소를 사용한다. 따라서, 로드밸런서와 웹 서버는 이 사설 주소를 사용하여 통신한다.

부하 분산 집합에 또 하나의 웹 서버를 추가하고 나면 FailOver 가 안되는 문제를 해결할 수 있으며, 웹 계층의 가용성(Availability) 은 향상된다. 서버1이 다운되면(offline) 모든 트래픽은 서버2로 전송된다. 따라서 웹 사이트 전체가 다운되는 일이 없어진다. 또한 웹 사이트로 유입되는 트래픽에 가파르게 등장하면, 부하를 분산하기 위해 새로운 서버를 더 추가할 수도 있다.

이제 웹 계층은 괜찮아졌다. 그렇다면 데이터베이스 서버는 가용성 측면에서 안전한가? 아직 데이터베이스 서버는 한 대이고, FailOver 나 다중화를 지원하지 않는다. 데이터베이스 다중화는 이런 문제를 해결한다.

데이터베이스 다중화

많은 데이터베이스는 다중화를 지원한다. 보통은 서버 사이에 주(master) - 부(slave) 관계를 설정하고 데이터 원본은 주 서버에, 사본은 부 서버에 저장하는 방식으로 구성한다. 또한 쓰기 연산은 master 서버에서만 지원한다. slave 서버는 master 서버로부터 그 사본을 전달받고, 읽기 연산만을 지원한다.

대부분의 애플리케이션은 읽기 연산의 비중이 쓰기 연산보다 훨씬 높다. 따라서 통상 slave 데이터베이스의 수가 master 서버의 수 보다 많다.

그렇다면, 데이터베이스 다중화를 통해 어떤 이점을 얻을 수 있을까?

(1) 부하 분산을 통한 성능 개선 : master-slave 다중화 모델에서 쓰기 연산은 master 서버로만 전달디는 반면, 읽기 연산은 slave 서버들로 분산된다. 따라서 병렬로 처리되는 쿼리 수가 늘어나므로 성능이 향상된다.
(2) 지리적 분산 : 자연 재해 등의 이유로 데이터베이스 서버 가운데 일부가 파괴되어도 데이터는 보존된다. 지리적으로 떨어져있는 곳으로 서버를 다중화할 수 있기 때문이다.
(3) 가용성 : 데이터를 여러 지역에 복제해 둠으로써, 하나의 데이터베이스 서버에 장애가 발생하더라도 다른 서버에 있는 데이터를 가져와 계속 서비스 할 수 있게된다.

또한 데이터베이스를 다중화한다면 아래와 같은 상황에 대처할 수 있게 된다.

한 대뿐인 slave 서버가 다운되었다면, 읽기 연산은 일시적으로 master 서버에게 전달된다. 또한 즉시 새로운 slave 서버를 올려서 장애 서버를 대체(FailOver) 할 수 있을 것이다. slave 서버가 여러대인 경우라면 읽기 연산이 정상 동작하는 slave 서버들에게 분산되고, 이후 새로운 master 서버가 장애 서버를 대체할 수 있을 것이다.
master 서버가 다운되었고, slave 서버가 1대뿐인 경우 : slave 서버가 새로운 master 서버로 승격하고, 일시적으로 읽기/쓰기 연산을 모두 처리한다.

프로덕션 환경에서 벌어지는 일은 이것보다는 사실 더 복잡하다고 한다. slave 서버에 보관된 데이터가 최신 상태가 아닐 수 있기 때문이다. 없는 데이터는 복구 스크립트를 돌려서 추가해야 한다. 다중 마스터(Multi Master) 나 원형 다중화(Circular Replica-tion) 방식을 도입하면 이 복잡한 상황에 대처할 수 있는데, 이는 너무 어려운 내용이라 책에서 다루지 않는다.

캐시

캐시란 값 비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소다. 애플리케이션 성능은 데이터베이스를 얼마나 자주 호출하느냐에 따라 크게 좌우되는데, 캐시는 그런 문제를 완화할 수 있다.

캐시 계층(cache tier)

캐시 계층은 데이터가 잠시 보관되는 곳으로 데이터베이스보다 훨씬 빠르다. 데이터베이스는 데이터를 디스크에 저장하고, 캐시는 RAM 에 저장하기 때문이다. 별도의 캐시 계층을 두면 (1) 성능이 개선되고 (2) 데이터베이스 부하가 줄어들고 (3) 캐시 계층을 독립적으로 확장할 수 있다.

읽기 주도형 캐시 전략

웹 서버는 캐시 서버에 데이터가 있다면(Cache Hit) 캐시 서버에서 데이터를 읽는다. 반대로 없다면(Cache Miss) 데이터베이스에서 데이터를 읽고, 캐시에 저장한 뒤 사용자에게 응답을 반환한다. 이런 캐시 전략을 **읽기 주도형 캐시 전략(read-through caching strategy)**이라고 한다. 이 외에도 데이터 종류, 크기, 엑세스 패턴에 맞는 다양한 캐시 전략이 있다고 한다.

캐시 사용시 유의할 점

캐시를 사용할 때는 아래 사항들을 고려해야 한다.

캐시는 어떤 상황에 바람직한가? : 데이터 갱신은 자주 일어나지 않지만 참조가 빈번할 때
어떤 데이터를 캐시에 두어야 하는가? : 캐시는 데이터를 휘발성 메모리에 두므로, 영속적으로 보관할 데이터는 캐시에 두지 않는 것이 바람직하다. 중요한 데이터는 데이터베이스와 같이 지속적 저장소(persistent data store) 에 두어야 한다.
캐시에 보관된 데이터는 어떻게 만료(expire) 되는가? : 적절한 만료 정책이 필요하다. 만료된 데이터는 캐시에서 사라져야 한다. 만료 정책이 없으면 데이터는 영원히 캐시를 점유하게 된다. 만료 기한은 너무 짧으면 곤란한데, 데이터베이스를 너무 자주 읽게 될 것이기 때문이다. 너무 길어도 곤란한데, 실제 원본 데이터와 캐싱된 데이터간에 차이가 날 수 있기 떄문이다.
일관성(consistency)은 어떻게 유지되는가? : 일관성이란 데이터 저장소의 원본과 캐시 내의 사본이 같은지 여부이다. 저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 트랜잭션으로 처리되지 않는 경우, 이 일관성이 깨질 수 있다. 원본 데이터 갱신을 성공하고, 캐시 갱신에는 실패했을 때 이 두 연산이 단일 트랜잭션으로 묶이지 않았다면 원본과 캐시의 일관성이 깨진다. 여러 지역에 걸쳐 시스템을 확장하는 경우 캐시와 저장소 사이의 일관성을 유지하는 것은 어려운 문제이다.
장애에는 어떻게 대처할 것인가? : 케시 서버를 한 대만 배치하면 SPOF(Single Point Of Failure) 가 될 수 있다. SPOF 를 피하려면, 여러 지역에 걸쳐 캐시 서버를 분산해야한다.
캐시 메모리를 얼마나 크게 잡을 것인가? : 캐시 메모리가 너무 작다면, 엑세스 패턴에 따라 캐시 메모리에서 너무 자주 밀려나버려(eviction) 성능이 떨어지게 된다. 이를 막을 한 가지 방법은, 캐시 메모리를 과할당(over-provision) 하는 것이다. 갑자기 캐시에 보관할 데이터가 많아졌을 때 생길 문제를 방지할 수 있다.
데이터 방출(eviction) 정책은 무엇인가? : 캐시가 꽉 차버리면 추가로 캐시에 데이터를 넣어야 할 경우 기존 데이터를 캐시에서 내보내야 한다. 이것을 캐시 데이터 방출 정책이라고 하는데, 가장 널리 쓰이는건 마지막으로 사용된 시점이 가장 오래된 데이터를 먼저 내보내는 LRU(Least Recently Used) 이다. 다른 정책으로는 사용된 빈도가 가장 낮은 데이터를 내보내는 LFU(Least Frequently Used) 이고, 가장 먼저 캐시에 들어온 데이터를 가장 먼저 내보내는 정책인 FIFO(First In First Out) 도 있다.

콘텐트 전송 네트워크 (CDN)

CDN 은 정적 콘텐츠(HTML, JS 파일, 이미지, 비디오 등) 를 전송하는데 쓰이는, 지리적으로 분산된 서버의 네트워크이다. 사용자가 네트워크를 방문하면, 그 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달한다.

참고로 동적 콘텐츠 캐싱은 요청 경로, Query String, 쿠기, 요청 헤더등의 정보에 기반하여 HTML 페이지를 캐싱하는 것이다. 이는 책에서 다루지 않는다.

CDN 은 어떻게 동작할까? 어떤 사용자가 웹사이트를 방문하면, 그 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달하게 된다.당연한 말이지만, CDN 서버가 서버로부터 멀면 벌수록 웹 사이트는 천천히 로딩될 것이다. 세부 동작 과정은 보통 다음과 같이 동작하게 된다.

(1) 사용자가 이미지 URL 을 이용해 이미지에 접근한다. 이 URL 의 도메인은 CDN 서비스 사업자가 제공한다.
(2) CDN 서버에 해당 이미지가 없는 경우, CDN 서버는 원본 서버에 요청에 이미지 파일을 가져온다. 이때 원본 서버는 웹 서버일수도 있고, AWS S3 와 같은 저장소일 수도 있다.
(3) 원본 서버가 CDN 서버에 파일을 리턴한다. HTTP 응답 헤더에는 해당 파일이 얼마나 오래 캐시될 수 있는지 나타내는 TTL(Time-To-Live) 값이 들어있다.
(4) CDN 서버는 파일을 캐시하고 사용자에게 리턴한다. 이 이미지 파일은 TTL 에 명시된 시칸만큼 캐시된다.
(5) 다른 사용자가 동일한 이미지를 CDN 서버에 요청한다.
(6) 해당 이미지가 만료되지 않았다면 CDN 서버가 캐시해 둔 파일을 리턴한다.

CDN 사용시 고려해야 할 사항

비용 : CND 은 보통 제 3사업자에 의해 운영되며, 데이터 전송량에 따라 요금을 지불한다. 따라서 자주 사용되지 않는 컨텐츠를 캐싱하는 것은 비용 낭비이다.
적절한 만료 시한 설정 : 시의성이 중요한 (time-sensitive) 컨텐츠는 만료 시점을 잘 설정하는게 중요하다. 만료 시한이 너무 길면 컨텐츠의 신선도가 떨어지고, 너무 짧으면 원본 서버에 빈번한 접속 요청이 들어올 것이다. 캐시 서버의 만료 정책과 비슷하다.
CDN 장애에 대한 대처 방안 : CDN 이 응답하지 않는 경우 이 문제를 감지하여 원본 서버로부터 컨텐츠를 가져올 수 있도록 클라이언트를 구성할 필요가 있다.
컨텐츠 무효화(invalidation) 방법 : 아직 만료되지 않은 컨텐츠라고 하더라도, 아래 방법을 통해 CDN 에서 제거할 수 있다.
- (1) CDN 서비스 사업자가 제공하는 API 를 사용한 무효화
- (2) 컨텐츠의 다른 버전을 서비스하도록 오브젝트 비저닝을 이용한다. 컨텐츠의 새로운 버전을 지정하기 위해서는 URL 마지막에 버전 번호를 인자로 준다.

지금까지의 시스템 설계를 그려보면 아래와 같을 것이다.

무상태(stateless) 웹 계층

이제 웹을 수평 확장(Scale Out) 하는 방법을 고민해 볼 차례이다. 이를 위해서는 사용자 세션 데이터와 같은 상태 정보를 웹 계층에서 제거해야한다.

상태 정보에 의존적인 아키텍처

상태정보를 보관하는 서버는 클라이언트 정보, 즉 상태를 유지하여 요청들 사이에 공유(쿠기와 세션등을 사용하여) 되도록 해야한다. 무상태 서버에는 이런 장치가 없다.

문제는 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송되어야 한다는 점이다. 대부분의 로드밸런서가 이를 해결하기 위해 고정 세션(Sticky Seession) 기능을 제공하고 있는데, 이는 로드밸런서에 큰 부담을 준다. 게다가 로드밸런서 뒷단에 서버를 추가하거나 제거하기도 까다로워진다.

사실 왜 로드밸런서 뒷단에 서버를 추가하거나 제거하기도 까다로워지는지 잘 이해되지 않아서, 이는 추가 학습이 필요하다.

무상태 아키텍처

무상태 아키텍처는 세션과 같은 상태 정보를 별도의 공유 저장소(Shared Storage) 로 부터 데이터를 저장하고 가져온다. 즉, 상태 정보는 웹 서버로부터 물리적으로 분리되어 있다. 이런 구조는 단순하고, 안정적이고, 규모 확장이 쉽다. 이 공유 저장소는 Redis 와 Mecached 같은 캐시 서버를 사용할 수도 있고, NoSQL 서버를 사용할 수도 있다. 다만, 책에서는 규모 확장이 간편한 NoSQL 을 선택했다고 한다.

세션과 같은 상태를 Redis 와 같은 별도의 상태 저장소에 보관하면 오토스케일링(AutoScaling) 도 가능해진다. 오토스케일링은 트래픽 양에 따라 유연하게 웹 서버를 자동 추가하거나 삭제하는 기능이다. 상태 정보가 각 웹 서버에서 관리하는 방식이 아니므로, 트래픽 양에 따라 웹 서버를 넣었다 뺄 수 있는 유연한 구조로 개선된다.

왜 오토스케일링을 가능하게 만드는지에 대한 추가 학습이 필요하다.

데이터 센터

만약 우리 서비스가 전 세계적으로 사용하게 되었다면 어떨까? 가용성을 높이고 전 세계 어디서든 빠르게 사용하기 위해 데이터 센터를 지원해야한다.

지리적으로 분리된 2개의 데이터 센터가 있다고 해보자. 장애가 없는 상황에서 사용자는 가장 가까운 데이터 센터로 라우팅된다. 이 절차를 지리적 라우팅(geoDNS-routing 또는 geo-routing) 이라고 한다. 지리적 라우팅에서 geoDNS 는 사용자의 위치에 따라 도메인 이름을 어떤 IP 주소로 변환할지 결정해주는 DNS 서비스이다. 만약 데이터 센터 중 하나에 장애가 발생하면, 모든 트래픽은 장애가 발생안한 다른 데이터 센터로 라우팅된다.

다중 데이터 센터를 구축하려면 몇 가지 기술적 난제를 해결해야한다.

트래픽 우회 : 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾는다. geoDNS 는 사용자에게서 가장 가까운 데이터 센터로 트래픽을 보낼 수 있도록 해준다.
데이터 동기화 : 데이터 센터마다 별도로 데이터베이스를 사용하고 있는 상황이라면, 장애가 자동으로 복구되어(failover) 트래픽이 다른 데이터베이스로 우회된다 해도, 해당 데이터 센터에는 찾는 데이터가 없을 수 있다. 이런 상황을 방지하는 보편적 전략은, 동일한 데이터를 여러 데이터센터에 걸쳐 똑같이 다중화 하는 것이다.

메시지 큐

시스템을 더 큰 규모로 확장하기 위해서는 시스템의 컴포넌트를 분리하여, 각기 독립적으로 확장될 수 있도록 설계해야한다. 메시지 큐(message queue) 는 많은 실제 분산 시스템이 이 문제를 해결하도록 지원한다.

메시지 큐는 비동기 통신을 지원하는 컴포넌트잉다. 메시지 큐는 무손실을 보장하는 특징이 있는데, 이는 메시지 큐에 한번 저장된 메시지는 소비자가 꺼낼때까지 안전히 보관된다는 점이다. 메시지 큐는 메시지의 버퍼 역할을 하며, 비동기적으로 전송한다.

ProduceR (또는 Publisher) 라고 불리는 서비스가 메시지를 만들어 메시지 큐에 메시지를 발생(publish) 한다. 메시지 큐에는 Consumer 또는 Subscriber 라고 불리는 서비스 또는 서버가 연결되어 있는데, 메시지를 받고 동작을 수행한다.

메시지 큐를 사용하면 서비스 또는 서버 간 결합이 느슨해져서, 규모 확장성이 보장되어야 하는 안정적인 애플리케이션을 구성하기 좋다. 또, 결함에 대한 내성을 높여준다. 생산자는 소비자가 다운되어 있을 때도 메시지를 발행할 수 있고, 반대로 소비자는 생산자 서비스가 다운되어 있더라도 메시지를 수신할 수 있다. 즉, 생산자 소비자는 서로의 서버가 살아있던 죽어있던 간에 상관없이 메시지를 발행하기만 하면 되기 떄문에, 비동기적으로 동작할 수 있다는 것이고 서버간 결합이 느슨해지며 규모를 확장하기 쉽다는 것이다.

사용 예로 시간이 오래 걸리는 이미지 보정 작업을 들 수 있다. 생산자인 웹 서버는 이미지 보정 작업을 메시지 큐에 넣는다. 사진 보정 작업 프로세스는 메시지 큐에서 메시지를 꺼내 해당 비동기적으로 이미지 보정 작업을 수행한다. 이런 구조에서는 생산자와 소비자 서비스의 규모는 각기 독립적으로 확장될 수 있다.

로그, 메트릭 그리고 자동화

소규모 서비스에서는 로그, 메트릭(metric), 자동화(automation)은 좋지만 필수는 아니다. 하지만 사업 규모가 커지면 이런 도구에도 투자해야한다.

데이터베이스의 규모 확장

저장할 데이터가 많아지면 데이터베이스에 대한 부하도 커진다. 그때는 데이터베이스를 증설할 방법을 찾아야한다. 데이터베이스 규모를 확장하는 방법에는 수직적 확장과 수평적 확장 2가지로 나뉜다.

수직적 확장

데이터베이스 서버의 CPU, RAM, 디스크와 같은 자원을 증설하는 방법이다. 하지만, 이 방법에는 몇가지 심각한 단점이 존재한다.

서버 하드웨어를 무한 증설할 수 없으므로 한계점에 언제가 반드시 도달한다.
하나의 데이터베이스를 수직 확장하면 SOF 로 인한위험성이 크다.
고성능 서버로 갈수록 가격이 올라가므로 비용이 많이 발생한다.

수평적 확장 - 데이터베이스 샤딩

💡 데이터베이스 샤딩에 대한 자세한 이론은 데이터베이스 분산 스토리지를 위한 파티셔닝과 샤딩 을 참고하자.

데이터베이스의 수평적 확장을 샤딩(Sharding) 이라고 한다. 더 많은 서버를 증설함으로써 성능을 개선할 수 있다. 샤딩은 대규모 데이터베이스를 샤드(shared) 라는 작은 단위로 분할한다. 모든 샤드는 같은 스키마를 사용하지만, 샤드에 보관되는 데이터 사이에는 중복이 없다.

샤딩 방식에는 여러가지가 있다. 그 중 해시 샤딩(hash sharding) 의 경우 샤드의 개수에 따라서 해시 함수를 사용하여 데이터가 보관되는 샤드를 결정한다. 예를들어 샤드가 4개라면, user_id % 4 를 해시 함수로 사용하여 데이터가 보관됭 샤드를 결정할 수 있다.

샤딩 전략에서 가장 중요하게 고려한 것은 샤딩 키(sharding key, 즉 Partitioning Key) 를 어떻게 정하는가에 있다. 샤딩 키는 데이터가 어떤 샤드에 저장되는지 결정하는 하나 이상의 컬럼으로 구성된다. 위 예제의 경우 user_id 가 샤딩 키이다. 샤딩 키를 정할때는 데이터가 고르게 분산될 수 있도록 하는것이 중요하다.

샤딩을 도입하면 시스템이 복잡해지고 풀어야할 새로운 문제도 생긴다.

데이터의 재 샤딩(re-sharding) : 데이터가 너무 많아져서 하나의 샤드로는 감당이 어렵거나, 또는 균등하게 데이터 분포가 되지 않아 특정 샤드에 데이터가 몰려 할당된 공간 소모가 다른 샤드에 비해 빠르게 될 때 재 샤딩을 고려해야한다. 이를 샤드 소진(shard exhaustion) 이라고 하는데, 이런 현상을 해결하기 위해 샤드 키를 계산하는 함수를 변경하고 재배치 해야한다. (이는 안정 해시라는 기법을 사용하면 해결할 수 있다고 한다.)
유명인사(celebrity) 문제 : 핫스팟 키 문제라고도 부른다. 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제이다. 페이스북 같은 서비스에서 유명 인사 유저가 모두 한 샤드에 집중적으로 저장되어 있다면 해당 샤드에만 과부하가 걸릴 것이다. 이를 해결하기 위해 유명인사 각각에 샤드 하나씩을 할당해야 할 수도 있고, 더 잘게 샤드를 쪼개야할 수도 있다.
조인과 비정규화(join and de-normalization) : 하나의 데이터베이스를 여러 서버로 쪼개면, 여러 샤드에 걸친 데이터를 조인하기 힘들다. 이를 해결하는 방법 중 하나는 데이터베이스를 비정규화 하여 조인 없이 하나의 테이블에서 질의가 수행될 수 있도록 하는 것이다.

정리

지금까지 학습한 내용을 정리하면 다음과 같다.

웹 계층은 무상태 계층으로
모든 계층에 다중화 도입
가능한 한 많은 데이터를 캐시할 것
여러 데이터 센터를 지원할 것
정적 컨텐츠는 CDN을 통해 서비스할 것
데이터 계층은 샤딩을 통해 그 규모를 확장할 것
각 계층은 독립적 서비스로 분할할 것
시스템을 지속적으로 모니터링하고, 자동화 도구를 이용할 것

더 학습해야 할 키워드

Sticky Session
왜 상태를 별도의 저장소에 저장하면 부하 분산 집합내의 AutoScaling 이 가능해지는가?

스프링부트 애플리케이션 run 메소드가 실행되기까지의 동작원리

Fri, 25 Oct 2024 00:00:00 GMT

지난 프론트 컨트롤러 구현에 이어서, 스프링부트 애플리케이션을 실행하기 까지의 전 과정에 대해 다루어보고자 한다. 또한 한 단계씩 거쳐가며 애플리케이션 로직을 리팩토링 해보겠다.

프론트 컨트롤러에 대한 설명은 서블릿 컨테이너로 프론트 컨트롤러(Front Controller) 를 구현하여 공통 요청을 처리해보자! 을 참고하자.

Assembler

스프링 컨테이너는 DI 컨테이너로써 Assembler 역할을 수행한다. Assembler 란 원래는 직접 의존관계가 없는 클래스들의 오브젝트를 가져다가 가져다가 서로 관계를 연결시켜주고 사용 가능하도록 만들어주는 "제 3자" 역할이다.

스프링 컨테이너는 우리가 제공한 메타 정보를 기반으로 클래스의 싱글톤 Bean 오브젝트를 생성하고, 각 오브젝트간의 의존 관계를 주입(연결) 해주는 작업을 수행한다. 이때 관례적으로 Bean 오브젝트 간의 의존관계를 생성하는 것이 "생성자 주입" 일텐데, 생성자의 파라미터는 인터페이스로 추상화를 시켜놓는다.

인터페이스로 파라미터 객체를 받는 이유는 유연한 확장을 위함일 것이다. 개발자의 구현 코드 레벨에선 인터페이스로 추상화를 시켜놓고 확장을 위해 여러 구체 클래스를 만들었을텐데, 이 구체 클래스로 어떤 것을 "주입" 시켜줄지를 스프링 컨테이너에 등록해주는 것이다. 특정 Bean 클래스가 사용하고 싶은 Bean 구체 클래스를 바로 생성자 주입 통해 주입한다는 것이다.

AppplicationContext

기존 프론트 컨트롤러에 스프링 컨테이너를 도입했다. 컨테이너에 등록할 Bean 객체는 AppplicationContext 로 등록한다. 이 인터페이스를 구현한 GenericApplicationContext 의 registerBean() 메소드를 통해 등록해줄 수 있다.

public class HellobootApplication {
	public static void main(String[] args) {
		GenericApplicationContext applicationContext = new GenericApplicationContext();

		applicationContext.registerBean(HelloController.class);
		applicationContext.registerBean(SimpleHelloService.class); 로 넣겨준다.
		applicationContext.refresh();

		TomcatServletWebServerFactory serverFactory = new TomcatServletWebServerFactory();
		HelloController helloController = new HelloController();

		WebServer webServer = serverFactory.getWebServer(servletContext -> {
			servletContext.addServlet("hello", new HttpServlet() {
				@Override
				protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
					// 인증, 보안, 다국어등의 공통 처리 코드 부분 (생략함)
					if(req.getRequestURI().equals("/hello")) {
						String name = req.getParameter("name");

						HelloController helloController = applicationContext.getBean(HelloController.class);
						String ret = helloController.hello(name);

						resp.setContentType(MediaType.TEXT_PLAIN_VALUE);
						resp.getWriter().println(ret);
					}
					else if(req.getRequestURI().equals("/user")) {
						resp.setStatus(HttpStatus.OK.value());
					}
					else {
						resp.setStatus(HttpStatus.NOT_FOUND.value());
					}
				}
			}).addMapping("/*");
		});

		webServer.start();

	}
}

DispatcherServlet

한편 이전까지 개발했던 서블릿 컨테이너는 Containerless 하지 못하다. 개발자 입장에선 프론트 컨트롤러를 매번 직접 구현하는 과정이 꽤나 번거롭다. 매핑 코드 (ex. URL 경로, HTTP 메소드), 파라미터 (ex. DTO) 등 애플리케이션 로직과 긴밀하게 연결된 코드들이 서블릿 컨테이너 내부 구현 코드로 등장한다는 것이다.

Servlet Containerless

이 떄문에 Servlet Containerless 를 만드는 것의 필요성이 느껴찐다. 그래서 등장한 것이 바로 DispatcherServlet 이다. 기존의 서블릿 컨테이너에서 직접 하드코딩했던 수고가 줄어들게 되었다.

어노테이션으로 메타 정보를 전달하는 방법

기존에 하드 코딩했던 서블릿은 URL 매핑 정보, 파라미터, 스프링 컨테이너와의 매핑 정보등의 "메타 정보" 를 직접 구현했었다. 하지만 반면 DispatcherServlet 은 이런 직접 일일이 구현해야했던 수고를 없애도록 어노테이션 을 활용한 방법이 등장했다.

@RequestMapping
public class HelloController {
    private final HelloService helloService;

    public HelloController(HelloService helloService) {
        this.helloService = helloService;
    }

    @GetMapping("/hello")
    @ResponseBody
    public String hello(String name) {
        return helloService.sayHello(Objects.requireNonNull(name));
    }
}

매핑 정보를 서블릿 코드에 직접 넣는 대신에, 그 요청을 처리할 Controller 클래스 내부에다 매핑 정보를 대신 집어넣는 방법이다. 클래스 레벨에선 @RequestMapping 을, 메소드 레벨에선 @GetMapping 등의 어노테이션을 간단히 붙임으로써 DispatcherServlet 은 메타 정보를 인식할 수 있게된다.

위와 같이 개선하면 DispatcherServlet 은 먼저 클래스 레벨에서 매핑 정보를 찾고, 그 클래스 내부의 메소드 레벨에서 추가 정보를 찾는다.

참고로 hello() 메소드에서 그냥 String 데이터를 리턴해버리면 View 를 랜더링하게 된다. 즉 Stirng 리턴 값을 View 이름 값으로 인식하는 것이다. hello.html 을 찾고 랜더링 하고자 하므로 404 에러가 발생하는데, 이는 @ResponseBody 를 붙여줌으로써 해결된다. 사실 @RestController 를 클래스에 붙인다면 기본적으로 해당 클래스 내부의 모든 메소드에 @ResponseBody 가 붙어있지만, 여기선 @RestController 를 활용하지 않았기 떄문에 이 어노테이션을 붙여준 것이다.

스프링 컨테이너, 서블릿 컨테이너 초기화 코드 최소화하기

앞서 설명한 내용을 기반으로 코드를 구성한다면 크게 2개의 파트로 구분된다. 우선 (1) 스프링 컨테이너 초기화 작업 일 것이다. 스프링 컨테이너를 생성하고 Bean 을 등록하여 초기화 작업을 해주는 부분이다. 또한 (2) 서블릿 컨테이너 초기화 작업 도 발생한다. 그렇게 만들어진 스프링 컨테이너를 활용하면서 서블릿 컨테이너를 코드에서 생성하고, 그 내부에 프론트 컨트롤러 역할을 하는 DispatcherServlet 을 등록하는 부분이다.

이렇게 과정 (1), (2) 로 구분된 "초기화" 작업 코드를 최소화해보고 싶다. (1) 에서 발생하는 서블릿 컨테이너를 생성하고 초기화하는 하드 코딩 을 (2) 를 실행하는 중간에 발생하도록 개선해보겠다. 즉, 스프링 컨테이너를 초기화하는 중간에 서블릿 컨테이너 생성 및 초기화도 발생하도록 한다는 것이다.

GenericWebApplicationContext 를 활용한 초기화

스프링 컨테이너의 초기화 작업은 GenericWebApplicationContext 의 refresh() 메소드를 호출하여 발생한다. 이때 refesh() 를 호출하여 초기화 작업이 일어나는 중간에 부가적인 추가 작업을 수행하기 위해선 GenericWebApplicationContext 클래스를 상속한 새로운 클래스를 하나 만들고, onRefesh() 라는 메소드를 재정의 해줘야한다.

우리는 이 새로운 클래스를 익명 클래스로 상속하겠다.

public class HellobootApplication {
	public static void main(String[] args) {
		GenericWebApplicationContext applicationContext = new GenericWebApplicationContext() {
			@Override
			protected void onRefresh() {
				super.onRefresh(); // 익명클래스가 onRefresh() 를 오버라이딩 한다.

				// 서블릿 컨테이너 초기화 코드는 아래와 같이 삽입해줬다.
				TomcatServletWebServerFactory serverFactory = new TomcatServletWebServerFactory();

				WebServer webServer = serverFactory.getWebServer(servletContext -> {
					servletContext.addServlet( "dispatcherServlet",
							new DispatcherServlet(this)
					).addMapping("/*");
				});

				webServer.start();
			}
		};

		applicationContext.registerBean(HelloController.class);
		applicationContext.registerBean(SimpleHelloService.class);

		applicationContext.refresh();
	}
}

서블릿 컨테이너를 초기화하는 코드를 onRefresh() 재정의시에 넣어주면 된다. 이렇게 되면 스프링 컨테이너의 초기화 작업이 발생할 때 동시에 서블릿 컨테이너의 생성 및 초기화 작업도 일어날 수 있게된다.

자바 팩토리 메소드로 Bean 오브젝트 구성하기

앞서 살펴봤던 ApplicationContext 의 registerBean() 를 통해 Bean 오브젝트를 등록했지만, @Bean 어노테이션이 붙은 자바 팩토리 메소드를 통해서도 스프링 컨테이너에 빈 등록이 가능하다.

이후 한 가지 작업을 더 해줘야한다. @Configuration 을 클래스 레벨에 붙이는 것이다. 그러면 스프링 컨테이너가 해당 클래스 내부 내용을 통해 Bean 오브젝트를 가진, 즉 자바 팩토리 메소드 구성정보를 가짐을 알 수 있게된다.

요약하자면, 스프링 컨테이너는 @Configuration 이 붙은 클래스를 인식하여 @Bean 어노테이션이 붙은 팩토리 메소드를 기반으로 빈을 구성한다.

AnnotationConfigWebApplicationContext

또한 기존 GenericWebApplicationContext 는 자바 코드로 만든 구성 정보를 인식하지 못한다. 이는 AnnotationConfigWebApplicationContext 로 대체하면 된다. 이 클래스 객체는 어노테이션이 붙은, 즉 @Bean 이 붙은 자바 코드를 기반으로 구성 정보를 읽어오고 빈을 구성한다.

AnnotationConfigWebApplicationContext 은 기존의 registerBean() 메소드를 지원하지 않는다. 이를 자바 코드로 구성 정보를 가지고 있는 클래스 (즉 @Configuation 이 붙은 클래스) 를 등록해줘야한다. 이를 register() 메소드로 아래와 같이 구성해준다.

@Configuration
public class HellobootApplication {
	@Bean
	public HelloController helloController(HelloService helloService) {
		return new HelloController(helloService);
	}

	@Bean
	public HelloService helloService() {
		return new SimpleHelloService();
	}

	public static void main(String[] args) {
		AnnotationConfigWebApplicationContext applicationContext = new AnnotationConfigWebApplicationContext() {
			@Override
			protected void onRefresh() {
				super.onRefresh();

				TomcatServletWebServerFactory serverFactory = new TomcatServletWebServerFactory();

				WebServer webServer = serverFactory.getWebServer(servletContext -> {
					servletContext.addServlet( "dispatcherServlet",
							new DispatcherServlet(this)
					).addMapping("/*");
				});

				webServer.start();
			}
		};
		applicationContext.register(HellobootApplication.class);

		applicationContext.refresh();
	}
}

컴포넌트 스캔으로 리팩토링

@Component 를 활용하면 @Configuration, @Bean 등으로 직접 등록하던 팩토리 메소드를 제거한다. 즉 설정 정보 클래스를 제거하고 간단히 클래스에다 @Component 를 붙일 수 있다. 또한 @Component 가 붙은 클래스를 찾아서 빈으로 등록해 달라는 것을 @ComponentScan 을 붙임으로써 컨테이너에게 전달할 수 있다.

@Configuration
@ComponentScan
public class HellobootApplication {

	public static void main(String[] args) {
		AnnotationConfigWebApplicationContext applicationContext = new AnnotationConfigWebApplicationContext() {
			@Override
			protected void onRefresh() {
				super.onRefresh();

				TomcatServletWebServerFactory serverFactory = new TomcatServletWebServerFactory();

				WebServer webServer = serverFactory.getWebServer(servletContext -> {
					servletContext.addServlet( "dispatcherServlet",
							new DispatcherServlet(this)
					).addMapping("/*");
				});

				webServer.start();
			}
		};
		applicationContext.register(HellobootApplication.class);

		applicationContext.refresh();
	}
}

위처럼 applicationContext 가 등록된 HellobootApplication 클래스 위에 @ComponentScan 이 붙어있으면, 이 클래스가 붙어있는 패키지부터 시작해서 그 하위 패키지를 뒤져서 @Component 라는 어노테이션이 붙은 모든 클래스를 Bean 으로 등록한다. Bean 으로 등록할 때 필요하다면 의존 오브젝트를 찾아나고 이를 생성자를 호출할 때 파라미터로 넘겨주기도 한다.

TomcatServletWebServerFactory, DispatcherServlet 를 Bean 으로 등록

당연히도 TomcatServletWebServerFactory, DispatcherServlet 이 없다면 애플리케이션 서버를 시작할 수 없다. 이 2개의 으브젝트도 Bean 으로 등록해줘야 한다.

앞서 말했길, DispatcherServlet 은 자신이 이용할 컨트롤러를 찾아야하기 때문에 ApplicationContext 을 파라미터로 넘겨줘야 한다고 했었다. 이에 따라, DispatcherServlet 이 아래와 같이 setAppplicationContext() 라는 setter 를 호출하도록 한다. 파라미터로 this 키워드를 넣었다. 즉 ApplicationContext 를 파라미터로 넘겨준 것이라 볼 수 있다.

@Configuration
@ComponentScan
public class HellobootApplication {
	@Bean
	public ServletWebServerFactory servletWebServerFactory() {
		return new TomcatServletWebServerFactory();
	}

	@Bean
	public DispatcherServlet dispatcherServlet() {
		return new DispatcherServlet();
	}

	public static void main(String[] args) {
		AnnotationConfigWebApplicationContext applicationContext = new AnnotationConfigWebApplicationContext() {
			@Override
			protected void onRefresh() {
				super.onRefresh();

				ServletWebServerFactory serverFactory = this.getBean(ServletWebServerFactory.class);
				DispatcherServlet dispatcherServlet = this.getBean(DispatcherServlet.class);

				dispatcherServlet.setApplicationContext(this);//setter 호출

				WebServer webServer = serverFactory.getWebServer(servletContext -> {
					servletContext.addServlet( "dispatcherServlet",
							new DispatcherServlet(this)
					).addMapping("/*");
				});

				webServer.start();
			}
		};
		applicationContext.register(HellobootApplication.class);

		applicationContext.refresh();
	}
}

ApplicationContextAware

하지만 이렇게 setter 를 호출할 필요가 없다. 이 이유를 알기 위해선 먼저 ApplicationContextAware 라는 인터페이스에 대해 알아야한다.

ApplicationContextAware 는 인터페이스 타입으로, 대표적인 구현 클래스로 DispatcherServlet 가 해당된다. ApplicationContextAware 의 정의문에 따르면, 이 인터페이스를 구현한 구현 클래스가 스프링의 빈으로 등록이 되면 자동으로 setApplication 메소드를 자동 호출하여 주입해준다.

즉, 우리 대신에 스프릴 컨테이너가 DispatcherServlet 은 ApplicationContext 가 필요하다고 생각하고 자동으로 주입한다. 따라서 굳이 setter 를 직접 호출하지 않아도 자동으로 setter 가 호출된다. 위 코드에서 setter 호출문은 제거해주자.

최종 SpringBootApplication 구현

마지막으로 기존 코드, 즉 서블릿 컨테이너와 서블릿 컨테이너를 초기화 후 애플리케이션을 구동하는 코드를 run() 이라는 메소드로 따로 분리시켜보자.

run() 생성

현재 클래스 HellobootApplication 뿐만 아니라, 다른 메인이 되는 여러 클래스에서도 서블릿 컨테이너를 코드에서 자동으로 띄워주면서 스프링 컨테이너에서 필요한 정보를 받아와서 기본적인 기능을 수행할 수 있도록 만드는 메소드라고 볼 수 있다. 즉, 스프링 컨테이너 초기 준비작업을 해주는데 이 메소드를 재사용할 수 있다.

@Configuration
@ComponentScan
public class HellobootApplication {
	@Bean
	public ServletWebServerFactory servletWebServerFactory() {
		return new TomcatServletWebServerFactory();
	}

	@Bean
	public DispatcherServlet dispatcherServlet() {
		return new DispatcherServlet();
	}

	public static void main(String[] args) {
		run(HellobootApplication.class, args);
	}

	public static void run(Class<?> applicationClass, String[] args) {
		AnnotationConfigWebApplicationContext applicationContext = new AnnotationConfigWebApplicationContext() {
			@Override
			protected void onRefresh() {
				super.onRefresh();

				ServletWebServerFactory serverFactory = this.getBean(ServletWebServerFactory.class);
				DispatcherServlet dispatcherServlet = this.getBean(DispatcherServlet.class);

				WebServer webServer = serverFactory.getWebServer(servletContext -> {
					servletContext.addServlet( "dispatcherServlet",
							new DispatcherServlet(this)
					).addMapping("/*");
				});

				webServer.start();
			}
		};
		applicationContext.register(HellobootApplication.class);

		applicationContext.refresh();
	}
}

최종 run() 분리, SpringBootApplication 생성

최종적으로 MySpringBootApplication 이라는 클래스로 run() 를 분리했다. 이 결과는 우리가 평소에 자주봤던 SpringBootApplication 시작을 위한 run() 메소드와 매우 유사하다. 이러한 내부 동작원리로 스프링부트 애플리케이션을 가동할 수 있었던 것이다 🙂

@ComponentScan
public class HellobootApplication {
	@Bean
	public ServletWebServerFactory servletWebServerFactory() {
		return new TomcatServletWebServerFactory();
	}

	@Bean
	public DispatcherServlet dispatcherServlet() {
		return new DispatcherServlet();
	}

	public static void main(String[] args) {
		MySpringBootApplication.run(HellobootApplication.class, args);
	}
}



public class MySpringBootApplication {
    public static void run(Class<?> applicationClass, String[] args) {
        AnnotationConfigWebApplicationContext applicationContext = new AnnotationConfigWebApplicationContext() {
            @Override
            protected void onRefresh() {
                super.onRefresh();

                ServletWebServerFactory serverFactory = this.getBean(ServletWebServerFactory.class);
                DispatcherServlet dispatcherServlet = this.getBean(DispatcherServlet.class);

                WebServer webServer = serverFactory.getWebServer(servletContext -> {
                    servletContext.addServlet( "dispatcherServlet",
                            new DispatcherServlet(this)
                    ).addMapping("/*");
                });

                webServer.start();
            }
        };
        applicationContext.register(HellobootApplication.class);

        applicationContext.refresh();
    }
}

마치며

이렇게까지 SpringBootApplication 의 run() 을 어떻게 구동시킬 수 있는지를 직접 코드를 구현하여 내부 원리를 이해할 수 있었다. 이번 학습은 정말정말 대만족스럽다 😆 항상 서블릿과 JSP 를 등한시 해왔던 내가 드디어 "왜" 중요하다는지 에 대한 명확한 설명을 할 수 있게 되었다.

하지만 아직 학습해야 할 내용이 많이 남았다. 특히 구현한 코드는 실제 run() 메소드와 다르게 DispatcherServlet, TomcatServletWebServerFactory 에 대한 Bean 오브젝트를 스프링 컨테이너에 등록해줘야 한다. 이에 대한 해결방안은 천천히 찾아보고자 한다 🙂

더 학습해볼 키워드

ServletWebServerFactory, DispatcherServlet 에 대한 Bean 오브젝트 없이 어떻게 run() 메소드를 동일하게 구현할 수 있는가?
Jetty
ApplicationContext (아직 더 깊은 이해도가 필요한건 사실이다 🥹)

데이터베이스 클러스터링 인덱스와 세컨더리 인덱스

Thu, 24 Oct 2024 00:00:00 GMT

만약 인덱스가 없었더라면, 테이블 풀 스캔(Table Full Scan) 이 발생하여 원하는 데이터를 찾는데 꽤 오랜 시간이 걸릴것이다. 인덱스가 없는 경우엔 데이터가 단순히 삽입된 순서대로 담기게 된다. 이 떄문에 순차 탐색을 해야하고, 최악의 경우 O(n) 시간이 소요된다.

이를 개선하기 위해 인덱스가 등장했다고 여러 포스팅에 걸쳐 설명했었다. 이 인덱스는 사실 2종류로 나뉜다. 이번 포스팅에선 인덱스의 2가지 종류인 클러스터링 인덱스와 비클러스터링 인덱스에 대해 다루어본다.

클러스터링 인덱스 (Clustering Index)

클러스터링 인덱스는 데이터가 테이블에 물리적으로 저장되는 순서를 정의하는 인덱스이다. 즉, 클러스터링 인덱스는 특정 컬럼을 기준으로 데이터들을 정렬시킨다. 이때, 클러스터링 인덱스는 실제 데이터와 무리(Cluster) 를 지어 인덱싱 되므로 클러스터링 인덱스라고 부른다. 클러스터링 인덱스의 주 목적은 실제 데이터를 정렬하는 것이다. 실제 데이터들은 클러스터링 인덱스를 기준으로 하여 함께 묶여서 정렬되기에, 원하는 데이터를 탐색시 더 빠르게 정렬된 구조에서 데이터를 찾을 수 있게 해준다.

클러스터링 인덱스는 테이블당단 1개만 생성할 수 있다. 다시말해, 테이블 당 데이터는 오직 1가지의 클러스터링 인덱스로 정렬 기준을 갖고 실제 데이터들이 정렬된다. 정렬 기준으로 오직 1개의 컬럼만을 선택할 수 있다는 뜻이다.

따라서 정렬 기준으로 가장 적합한 컬럼 하나만을 클러스터링 인덱스로 지정할 수 있는데, 대표적으로 PK(Primary Key) 가 클러스터링 인덱스로 자동 지정된다. 만약 PK 가 아니라 다른 컬럼을 지정하고 싶다면, Unique + Not NULL 제약조건을 부여한 컬럼은 클러스터링 인덱스가 자동 생성된다. 만약 PK 와 Unique + Not NULL 을 부여한 컬럼이 동시에 존재한다면, PK 를 우선순위로 하여 클러스터링 인덱스를 생성한다. (클러스터링 인덱스는 단 1개의 컬럼만 허용하기 떄문에, 어떤 것을 선택할지 우선순위를 두고 결정한다.) 만약 이 2가지 모두 없는 경우, InnoDB 는 내부적으로 GEN_CLUST_INDEX 라는 컬럼을 생성하여 클러스터링 인덱스를 생성한다. GEN_CLUST_INDEX 는 행이 생성된 순서대로 값을 부여한다.

클러스터링 인덱스는 B+ Tree 형태로 구성되어 있는데, 각 페이지(노드) 는 고유의 페이지 번호(Page ID)를 가지고 있다. 페이지 번호는 마치 집 주소 번지값이라고 생각하면 쉽다.

위 예제를 살펴보자. 각 데이터는 리프 페이지에서 PK 를 기준으로 정렬되어 있다. 루트 페이지는 Key 로 각 페이지에 대한 고유 페이지 번호를 갖고 있으며, Value 로 각 페이지가 보유한 PK 중 가장 앞단의 PK 를 가지고 있다. (간단한 예시를 들기위해, 루트와 리프 페이지 중간 계층의 페이지가 있는것은 생략했다.) 보듯이 PK 를 기준으로 정렬되어 있으며, 리프 페이지엔 인덱스가 실제 데이터와 함께 군집(Cluster) 를 이루어 저장된다. 클러스터링 인덱스를 기준으로 실제 데이터들이 정렬된다.

SELECT * FROM MEMBER
WHERE id = 7

PK 값을 WHERE 절에 넣어 데이터틑 탐색하는 과정을 생각해보자. PK 값은 7이기 떄문에, 루프 페이지에서 5 와 9 사이에 존재하는 값임을 알 수 있다. 앞서 설명했듯이 각 루프 페이지는 각 페이지가 보유한 PK 중 가장 앞단 (가장 작은) PK 를 저장한다고 했으므로, id = 5 를 가진 10002번지에 대한 리프 페이지로 내려간다. 그러고 원하는 데이터를 해당 리프 페이지에서 찾아낼 수 있게된다.

단점

클러스터링 인덱스를 기준으로 실제 데이터들이 함께 군집을 이루어 정렬 된 상태를 유지하기 떄문에 검색 속도가 매우 빨라진다. 하지만, 순서는 오직 하나의 컬럼을 기준으로 정렬되기 떄문에 중간에 새로운 데이터가 삽입된다면 이후의 모든 컬럼을 한 칸씩 이동(재정렬) 해줘야 한다. 즉, 데이터를 삽입, 변경, 삭제할 떄 마다 전체 데이터 페이지에 재정렬이 필요하므로 속도가 매우 느리다는 점을 유의해야 한다.

만약 PK = 2 를 가진 신규 데이터를 삽입한다고 해보자. 그리고 데이터 이후에 1만개의 데이터가 존재한다고 해보자. 그렇다면 기존의 PK = 3 ~ 10001 까지의 데이터들은 모두 한 칸씩 뒤로 이동시켜줘야하는 셈이다. 인덱스가 군집(Cluster) 를 이루기 떄문이다. 이렇듯 새로운 데이터를 삽입할 떄는 많은 비용이 소모된다는 점을 유의하자.

비클러스터링 인덱스 (Non Clustering Index)

비클러스터링 인덱스(Non Clustering Index) 는 보조 인덱스(Secondary Index) 라고도 불리며, 클러스터링 인덱스와 달리 인덱스들이 실제 데이터들과 함께 군집을 이루어 저장되는 방식이 아니다. 그 대신에 정렬된 별도의 인덱스 페이지로 저장되고 관리된다. 실제 데이터와 함꼐 군집을 이루지 않고, 별도의 분리된 인덱스 페이지 저장 공간에서 실제 데이터 페이지들을 포인터로 가리키는 구조를 취한다. 만약 UNIQUE 제약 조건을 걸은 컬럼이 있다면, 해당 컬럼은 자동으로 비클러스터링 인덱스가 생성된다. 또는 INDEX 쿼리를 넣어서 직접 인덱스를 생성하는 방법도 있다. 아래 3가지 방법은 모두 비클러스터링 인덱스가 생성된다.

ALTER TABLE member
ADD CONSTRAINT name UNIQUE(name); // unique 제약 조건

CREATE UNIQUE INDEX name // 중복을 허용하지 않는 인덱스를 생성
ON member (name)

CREATE INDEX name; // 중복을 허용하는 인덱스 생성
ON member (name)

인덱스 페이지를 항상 정렬된 상태를 유지하지만, 실제 데이터 페이지는 정렬되지 않아서 클러스터링에 비해 삽입, 수정, 삭제 작업이 더 느리다. 데이터 페이지를 무작위로 삽입하고, 정렬 순서를 유지하지 않기 떄문이다.

루트 페이지는 클러스터링 인덱스와 비슷하게 인덱스로 지정한 컬럼들과 페이지 번호를 갖고 있다. 반면 리프 노드에서 인덱스는 RID(데이터 페이지의 번호 + offset) 을 조합한 값을 저장하여, 특정 데이터 페이지의 특정 행을 가지킨다. (RID = RowID, 데이터 주소) 이 방식을 통해 인덱스 페이지에서 특정 데이터 페이지로 이동하고, 원하는 실제 데이터를 찾을 수 있다.

클러스터링 인덱스와 비클러스터링 인덱스의 혼합

그런데 현실적으로, 기본적으로 생성되는 클래스터링 인덱스 외에도 비클러스터링 인덱스를 생성해야하는 경우가 대다수일 것이다. 즉, 하나의 테이블에 클러스터링 인덱스와 비클러스터링 인덱스가 혼합되어 있는 경우가 많다. PK 는 기본적으로 항상 존재하며, 추가로 조회가 자주 발생하는 컬럼에 대해 인덱스를 추가하기 떄문이다.

이렇게 혼합된 경우에선 비클러스터링 인덱스를 먼저 거치고, 이어서 클러스터링 인덱스를 거쳐서 실제 데이터를 찾는 방식으로 동작한다. 이때, 비클러스터링 인덱스의 리프노드는 실제 데이터에 대한 주소값(데이터 위치 값) 대신, 클러스터링 인덱스에 대한 컬럼 값(PK 값) 을 갖는다. 실제로 위 예시를 보면 비클러스터링 인덱스의 인덱스 페이지는 앞서 살펴봤던 RID(데이터 페이지의 번호 + offset) 대신에 PK 값을 가지고 있다. 이 PK 값에 매핑되는 클러스터링 인덱스를 찾아내고, 이후 앞서 살펴본 클러스터링 인덱스에서의 동작과정이 동일하게 일어난다.

비클러스터링 인덱스는 왜 PK 값을 들고 있어야할까?

그런데 이상하다. 왜 비클러스터링 인덱스는 PK 값을 가지고 있는 것일까? 그냥 RID 값을 들고있고, 바로 원하는 실제 데이터를 찾아내도록 구조를 취하면 안될까? 만약 그렇게 된다면, 테이블에 데이터가 추가, 변경 및 삭제될 때 마다 테이블 데이터의 페이지 번호와 페이지 내 순서가 모두 변경되어야 한다. 클러스터링 인덱스는 데이터를 직접 가지고 있고, 테이블 전체가 정렬된 인덱스라고 했었다. 이런 구조에서 비클러스터링 인덱스가 RID 값을 직접 들고 있다면, 비클러스터링 인덱스를 모두 수정해야하는 문제가 발생한다. 그래서 비클러스터링 인덱스가 PK 값을 가지고 있는 구조를 취해야하는 것이다.

참고

자바 리플렉션 (Java Reflection) 다루기

Tue, 22 Oct 2024 00:00:00 GMT

자바 리플렉션 (Java Reflection)

자바는 캄파일이 시작되면, 컴파일러가 자바 코드로 작성된 클래스 정보들을 바이트 코드로 변환해준다. 그리고 클래스 로더(Class Loader) 는 변환된 이 바이트 코드를 읽어들여서 JVM 내에 메모리 영역에 저장한다. 리플렉션은 컴파일 된 이후 런타임 시점에 이 JVM 내의 메모리 영역에 저장된 클래스 객체 정보들을 꺼내온 뒤, 그 중 우리에게 필요한 상세 정보들(생성자, 필드, 메소드 등)을 추출하여 사용할 수 있게 해주는 기술이다. 즉, 리플렉션을 사용하면 특정 클래스에 대한 생성자, 메소드, 필드 등의 아주 상세한 정보들을 알아낼 수 있다.

이는 다시말해, 객체의 타입을 컴파일 시점 전까진 몰라도 동적으로 객체를 생성할 수 있게 해주기도 한다. 이 장점을 살려서 프레임워크나 라이브러리가 내부적으로 리플렉션을 매우 유용하게 사용하고 있다. 우리가 직접 코딩을 할때는 객체의 타입을 모르는 일이 거의 없는 반면에, 프레임워크나 라이브러리는 컴파일을 돌리기 전까진 객체의 타입을 알 수 없다. 이런 문제를 해결하기 위해 리플렉션을 사용한다. 리플렉션을 사용하면 프레임워크나 라이브러리 입장에서 컴파일 되기 전 시점에 객체의 타입을 몰라도 전혀 무관하며, 런타임 시점에 동적으로 객체의 타입을 읽어올 수 있기 때문이다.

리플렉션의 유용한 실제 활용 사례

리플렉션은 실제로 많은 프레임워크와 라이브러리에서 활용되고 있다. 어떤 부분에서 실제로 사용되고 있을까?

리플렉션과 기본 생성자

JPA 엔티티에서도, 단순한 DTO 에서도 모두 기본 생성자를 항상 필수로 생성할 것을 요구한다. 이렇게 기본 생성자를 필수로 생성해야하는 이유는 리플렉션 때문이다. 왜 리플렉션 떄문일까?

public class Member {
    // ...
    public Member(final String name) {
        this.name = name;
    }

    public Member(final String name, final String email) {
        this.name = name;
        this.email = email;
    }

    public Member(final String name, final String email, final String url) {
        this.name = name;
        this.email = email;
        this.url = url;
    }
}

만약 위처럼 기본 생성자가 없다면 생성자 종류가 많은 경우에 어떤 생성자를 선택해서 객체를 생성할지 프레임워크가 판단하기 어렵기 떄문이다. 또한 아래와 같이 파라미터의 타입이 같은 경우, 필드와 이름이 다르다면 값을 올바르게 넣어주기 힘들기 떄문이다.

public Member(final String name, final String email, final String url) {
    this.name = email;
    this.email = url
    this.url = name;
}

만약 기본 생성자를 사용한다면 위에서 언급한 문제점들을 제거할 수 있다. 리플렉션이 기본 생성자로 간단히 객체를 생성한 다음에, 필드 이름에 맞춰서 알맞은 값을 넣어주기만 하면 끝이다.

어노테이션의 동작 원리

@Component, @Bean, @Service 와 같은 어노테이션은 대표적으로 프레임워크에서 리플렉션을 사용한 사례이다. 만약 리플렉션이 없었다면, 어노테이션 그 자체로는 아무런 역할도 하지 못한다. 스프링 프레임워크는 내부적으로 리플렉션을 사용하여 어노테이션이 붙어있는 클래스(또는 메소드, 파라미터 등) 의 정보를 가져온다. 그 다음 후술할 Class 타입의 객체 메소드 중 getAnnotation(), getDeclaredAnnotation() 등을 호출하여 어떤 어노테이션이 붙어있는지를 확인하고, 그에 따른 로직을 수행한다.

Class 클래스

앞서 설명했기를, 리플렉션을 사용하여 객체의 타입을 컴파일 시점 전까진 몰라도 동적으로 객체를 생성할 수 있게 해준다. 동적인 객체 타입을 수용할 수 있게 해주는 것이 바로 Class 클래스이다. 즉, Class 타입 객체를 선언하면 런타임 시점에 주입될 실제 객체 타입이 그 무엇이던간에 모두 생성할 수 있게된다.

Class 타입의 객체를 통해 클래스에 붙은 어노테이션을 조회할 수 있고, 클래스가 가진 생성자나 필드, 메소드에 대한 정보를 조회할 수 있다. 심지어 클래스의 부모 클래스 또는 구현하고 있는 인터페이스까지 정보를 조회할 수 있다. 그리고 Class 타입 객체는 public 생성자가 존재하지 않고, JVM 에 의해 자동으로 객체가 생성된다.

Class 객체 생성

그렇다면 Class 객체를 어떻게 생성할 수 있을까? 우선 (1) 클래스의 .class 속성을 통해 획득할 수 있다. 그리고 (2) 객체의 getClass() 메소드를 사용하는 방법도 있으며, (3) Class 클래스의 forName() 메소드에 패키지 경로를 전달하여 해당 경로에 대응하는 클래스에 대한 Class 타입의 객체를 얻을 수 있다.

Class<Member> clazz1 = Member.class; // (1)

Member member1 = new Member();
Class<? extends Member> clazz2 = member1.getClass(); // (2)

Class<?> clazz3 = Class.forName("moheng.member.domain"); // (3)

getXXX(), getDelaredXXX()

Class 객체의 메소드는 크게 getFields(), getMethods(), getAnnotations() 와 같은 형태와 getDeclaredFields(), getDelcaredMethods(), getDeclaredAnnotations() 와 같은 형태 2가지로 메소드가 정의되어 있다. 이 메소드들은 클래스에 정의된 필드, 메소드, 어노테이션 목록을 가져오기 위해 사용된다.

getXXX() 형태의 메소드는 상속받은 클래스와 인터페이스를 포함하여 모든 public 요소를 가져온다. 예를들어 getAnnotations() 는 파라미터로 넣어준 클래스 타입이 붙어있는 모든 어노테이션을 가져온다. getMethods() 는 파라미터로 넘겨준 클래스가 상속받은, 그리고 구현한 인터페이스에 대한 모든 public 메소드를 가져온다.

반면 getDeclaredXXX() 형태의 메소드는 상속받은 클래스와 인터페이스를 제외하고 해당 클래스에 직접 정의된 내용만 가져온다. 또한 접근 제어자와 무관하게 요소에 접근한다. 예를들어 getDelcaredMethods() 는 해당 클래스에만 직접 정의된 private, protected, public 메소드를 모두 가져온다.

어노테이션 가져오기

앞서 게속 설명했듯이, 스프링은 리플렉션을 사용하여 어노테이션이 붙어있는 클래스(또는 메소드, 파라미터 등) 의 정보를 Clsss 타입의 객체로 가져온다. 이후 getAnnotation(), getDeclaredAnnotation() 등을 호출하여 어떤 어노테이션이 붙어있는지를 확인하고, 그에 따른 로직을 수행한다.

Class<Member> member = Member.class;
Entity entityAnnotation = member.getAnnotation(Entity.class); // @Entity 어노테이션을 가져옴
String value = entityAnnotation.value();
System.out.println("value = " + value);

getAnnotation() 은 위와 같이 사용할 수 있다. 위처럼 메소드에 직접 어노테이션 타입을 넣어주면, 클래스에 붙어있는 어노테이션을 가져올 수 있다. 또한 어노테이션이 가지고 있는 필드에도 접근할 수 있는 것을 볼 수 있다.

Class 를 사용하면 어노테이션 외에도 생성자를 Constructor 타입으로 가져올 수 있고, 객체 필드를 Field 로 접근할 수 있으며, 객체 메소드를 Method 타입으로 접근할 수 있다. 자세한 설명은 생략한다.

EntityManager 와 리플렉션을 활용하기

격리된 테스트(Isolated Test) 구축과 빌드 최적화 여정 - 실전편 에서 다루었듯이, 테스트 격리 환경에서 자바 리플렉션을 사용했던 경험이 있다. 각 테스트가 실행되기 직전에 호출되어 DB를 초기 상태로 만들어주는 DB Cleaner 에서 리플렉션이 사용되었다.

@Component
public class DatabaseCleaner {
    private EntityManager entityManager;
    private List<String> tableNames;

    public DatabaseCleaner(final EntityManager entityManager) {
        this.entityManager = entityManager;
        this.tableNames = entityManager.getMetamodel()
                .getEntities()
                .stream()
                .map(Type::getJavaType)
                .map(javaType -> javaType.getAnnotation(Table.class))
                .map(Table::name)
                .collect(Collectors.toList());
    }

    @Transactional
    public void clear() {
        entityManager.flush();
        entityManager.createNativeQuery("SET foreign_key_checks = 0").executeUpdate();

        for (String tableName : tableNames) {
            entityManager.createNativeQuery("TRUNCATE TABLE " + tableName).executeUpdate();
        }

        entityManager.createNativeQuery("SET foreign_key_checks = 1").executeUpdate();
    }
}

이 DB Cleaner 는 EntityManager 를 통해 모든 Entity 를 가져오고, 자바 리플렉션을 통해 Entity 의 @Table 어노테이션이 달린 클래스의 테이블 명을 가져오는 방식으로 동작한다. 보듯이 getEntities() 로 모든 엔티티를 가져왔으며, getAnnotation() 을 통해 @Table 어노테이션이 달린 각 Table 어노테이션 객체들에 대해 name (테이블 명)을 추출하고 있다. 그렇게 가져온 테이블 명 리스트를 활용하여 TRUNATE TABLE 쿼리를 날려서 깨끗하게 데이터베이스를 초기화한다.

리플렉션의 단점

리플렉션을 사용시 많은 단점을 가지고 있기 떄문에, 일반적인 상황에서 사용할 일이 거의 없다. 일반적으로 메소드를 호출하면, 컴파일 시점에 분석된 클래스를 사용하지만 리플렉션은 런타임 시점에 클래스를 분석하므로 속도가 매우 느리다. 또한 타입 체크가 컴파일 타이밍에 불가능하여 애플리케이션의 신뢰도를 깨뜨릴 원인이 될 수 있다. 그리고 객체의 추상화가 깨진다는 점도 존재한다.

보통 리플렉션은 라이브러리나 프레임워크를 개발할 때 사용된다. 따라서 정말 필요한 곳에만 리플렉션을 한정적으로 사용하도록 하자.