스프링을 사용하다 보면 이벤트 기반 아키텍처를 자주 접하게 된다. 그 중 많이 쓰는 것이 @TransactionalEventListener인데, 적용과 별개로 내부 동작을 파헤치는 곳이 없는 것 같아 아주 조금 확인해보는 시간을 가지려고 한다.

@TransactionalEventListener는 Spring의 트랜잭션 동기화(Transaction Synchronization) 메커니즘을 활용해 이벤트 실행 시점을 트랜잭션의 상태와 결합합니다. 핵심적으로, 이벤트가 발행될 때 즉시 실행되지 않고, 트랜잭션의 특정 단계(커밋, 롤백 등)에 맞춰 실행되도록 '예약'하는 방식으로 동작한다.

📌 기본 개념

기본 이벤트 리스너 vs 트랜잭셔널 이벤트 리스너

기본 이벤트 리스너

@Component
class OrderEventHandler {

    @EventListener
    fun handle(event: PaidCompleteEvent) {
        log.info("일반 이벤트 리스너 호출: ${event.orderUUId}")
    }
}

• ApplicationEventPublisher.publishEvent(event) 호출 시 즉시 실행

• 트랜잭션과 무관하게 동작

트랜잭셔널 이벤트 리스너

@Component
class OrderEventHandler {

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    fun handle(event: PaidCompleteEvent) {
        log.info("트랜잭션 커밋 이후 실행: ${event.orderUUId}")
    }
}

• 트랜잭션 경계와 결합
• phase에 따라 실행 시점 제어 가능

실행 시점 (TransactionPhase)

@TransactionalEventListener는 트랜잭션의 수명 주기에 맞춰 이벤트를 실행한다.

📌 내부 동작

1. 이벤트 발행

eventPublisher.publishEvent(new PaidCompleteEvent(...));

• 이 시점에서는 즉시 실행되지 않는다.
• 대신, TransactionSynchronizationManager에 "트랜잭션 끝날 때 실행할 콜백"을 등록한다.

2. @TransactionalEventListener의 특별한 처리

스프링 부트가 실행될 때, TransactionalEventListenerFactory라는 BeanPostProcessor가 등록된다.

이 Factory는 @TransactionalEventListener가 붙은 메서드를 스캔한다. 해당 메서드를 TransactionalApplicationListener라는 특별한 리스너 객체로 감싼다. 즉, "이 메서드는 단순한 이벤트 리스너가 아니라, 트랜잭션 경계와 관련된 특별한 리스너"라고 스프링에 알려주는 장치이다. 역할: @TransactionalEventListener가 붙은 메서드를 스프링 이벤트 리스너로 등록하는 팩토리

💡 주요 메서드

• supportsMethod : 특정 메서드가 이벤트 리스너로 등록될 수 있는지 판단
• createApplicationListener : 실제 이벤트를 처리할 ApplicationListener 인스턴스를 생성
  • 1. 일반 이벤트 리스너는 ApplicationListenerMethodAdapter를 쓰지만, @TransactionalEventListener는 TransactionalApplicationListenerMethodAdapter를 쓴다.
  • 2. 이 어댑터가 트랜잭션과 연동되어 이벤트 실행 시점을 BEFORE_COMMIT, AFTER_COMMIT, AFTER_ROLLBACK, AFTER_COMPLETION으로 맞춰 준다.

3. 메서드와 이벤트를 연결하는 Adapter : TransactionalApplicationListenerMethodAdapter

• 역할 : @TransactionalEventListener 메서드를 감싸서 트랜잭션 라이프사이클에 맞게 실행 시점을 조정하는 어댑터

1. @TransactionalEventListener가 붙은 메서드를 감싸서 트랜잭션 동기화 매니저(TransactionSynchronizationManager)에 등록
2. 지정된 트랜잭션 Phase(BEFORE_COMMIT, AFTER_COMMIT, AFTER_ROLLBACK, AFTER_COMPLETION)에 이벤트 실행 시점을 맞춤

내부에 여러 메서드가 있지만 내가 생각했을때 onApplicationEvent 메서드가 핵심인것 같다.

트랜잭션이 활성화되어 있을 때

• TransactionalApplicationListenerSynchronization.register(...) 호출 시 이벤트를 즉시 실행하지 않고 예약한다.

• 예약된 이벤트는 트랜잭션이 커밋되거나 롤백될 때 실행된다.

• 내부적으로 TransactionSynchronizationManager에 등록되어 트랜잭션과 이벤트 실행을 동기화한다.

트랜잭션이 없지만 fallback 실행이 허용된 경우

• isDefaultExecution()이 true이면, 트랜잭션 없이도 이벤트를 즉시 실행한다.
• 단, Phase가 AFTER_ROLLBACK인 경우 경고 로그를 남긴다.

  트랜잭션도 없고 fallback도 허용되지 않은 경우

• 이벤트는 무시되고 실행되지 않는다.

이 메서드 덕분에 트랜잭션 커밋 이후에만 실행해야 하는 로직과, 트랜잭션과 상관없이 바로 실행해도 되는 로직을 명확히 구분할 수 있는 것 같다.

역할 정리

너무 이해하기 어렵다. 역할을 단순히 정리를 하자면

• 트랜잭션 활성 여부 판단
• 이벤트를 즉시 실행할지, 등록할지, 무시할지 결정
• 등록이 성공하면 실제 이벤트 실행은 Synchronization에게 위임

4. 트랜잭션 시점에 맞춰 이벤트 실행을 담당 : TransactionalApplicationListenerSynchronization

이벤트 실행 자체와 콜백 관리를 책임지는 핵심 메서드: processEventWithCallbacks()

• 역할: 트랜잭션 시점에 이벤트를 실제로 실행
• 콜백 처리: 이벤트 실행 전(preProcessEvent), 후(postProcessEvent) 콜백 지원
• 예외 처리: 이벤트 실행 중 예외 발생 시 postProcessEvent에 예외 전달

이벤트 실행 메서드 : beforeCommit, afterCompletion

• 트랜잭션 커밋 전 : beforeCommit (TransactionPhase.BEFORE_COMMIT일 때만)
• 트랜잭션이 완료된 후 : afterCompletion

클래스 역할 정리

• 이벤트를 트랜잭션 Commit/Rollback 시점에 실행
• BEFORE_COMMIT, AFTER_COMMIT, AFTER_ROLLBACK, AFTER_COMPLETION 모두 처리 가능
• 이벤트 실행 전후로 콜백(pre/post) 처리 가능
• 트랜잭션이 없으면 fallbackExecution 옵션에 따라 즉시 실행하거나 무시

📌 정리

1. 이벤트 발행: 서비스 계층에서 ApplicationEventPublisher.publishEvent()가 호출

2. 어댑터 실행: TransactionalApplicationListenerMethodAdapter의 onApplicationEvent 메서드가 호출.

3. 트랜잭션 동기화 등록: 현재 활성화된 트랜잭션이 있으면, 이벤트와 그 실행 정보를 담은 TransactionalApplicationListenerSynchronization 객체를 TransactionSynchronizationManager에 등록.

4. 트랜잭션 종료: 트랜잭션이 커밋되거나 롤백되면, TransactionSynchronizationManager는 등록된 TransactionalApplicationListenerSynchronization 객체의 콜백 메서드(beforeCommit 또는 afterCompletion)를 호출.

5. 이벤트 실행: 콜백 메서드는 @TransactionalEventListener에 지정된 TransactionPhase에 따라 예약된 이벤트 핸들러 메서드를 실제로 호출.

트랜잭션은 데이터의 일관성을 보장하기 위한 핵심 메커니즘이다.특히 복잡한 비즈니스 로직에서 여러 서비스가 얽혀 있을 때, 어느 한 단계라도 실패하면 전체 작업이 롤백되어야 한다.

이번 글에서는 스프링 트랜잭션 롤백이 잘 동작하는지 테스트하는 방법과 AOP를 활용해 트랜잭션 상태(롤백 여부, 예외 발생 여부)를 실시간으로 추적하는 방법을 주문 기능과 함께 이야기해보려고 한다.

사실 난 지금까지 부끄럽지만 롤백 테스트를 postman을 이용한 실테스트로 진행해왔다. 이번에는 롤백 테스트도 테스트 코드로 해낼 수 있지 않을까?에서 부터 시작된 이야기이다.

📌 트랜잭션 롤백 테스트의 필요성

예를 들어, 주문 생성 시 재고 차감과 결제 포인트 차감이 동시에 이루어진다. 만약 재고 차감에서 예외가 발생하면, 결제 역시 취소되어야 한다.

이를 보장하기 위해서는 전체 주문 프로세스가 하나의 트랜잭션 내에서 실행되어야 하며,한 부분이라도 실패하면 전체가 롤백되어야 한다.

📌 필요한 구성 요소

1. 트랜잭션 상태 정보 저장용 객체 (TransactionTraceInfo)

트랜잭션 실행 중 발생한 상태(어떤 메서드에서, 어떤 인자와 함께 실행됐고, 롤백 상태인지, 예외가 있었는지)를 한 곳에 모아 구조화된 데이터로 관리하기 위해 필요하다.

• 메서드 이름과 인자를 기록해 어떤 트랜잭션인지 추적 가능
• 롤백 여부를 알면 트랜잭션 성공/실패를 판단할 수 있음
• 예외 발생 여부로 문제 발생 원인 분석 가능

2. 저장소(TransactionTraceHolder)

트랜잭션 상태 정보를 스레드 로컬(ThreadLocal) 에 안전하게 저장하고 꺼내는 저장소 역할이다. 동시에 여러 요청이 병렬로 처리되는 서버 환경에서, 각 요청별로 트랜잭션 상태를 독립적으로 관리하기 위해 필요하다. ThreadLocal은 각 스레드마다 독립된 저장 공간을 제공하기 때문에, 여러 스레드가 동시에 접근해도 데이터가 섞이지 않는다.

• ThreadLocal을 이용해 스레드별 독립 저장소 제공
• 여러 스레드가 하나의 전역 변수나 공유 객체를 건드리는 것을 방지해 데이터 충돌, 혼선 방지
• 테스트나 로그에서 각 트랜잭션의 상태를 정확히 조회하기 위한 안정적이고 안전한 상태 보관소 역할
• 요청 처리가 끝나면 clear()로 상태 제거해 메모리 누수 및 정보 오염 방지

3. AOP 처리기 (TransactionTraceAspect)

Spring의 AOP(Aspect-Oriented Programming)를 사용해 @Transactional이 붙은 메서드 호출 시점에 개입하여 트랜잭션 상태(rollback 여부, 예외 발생 여부 등)를 추적하고 기록하는 클래스가 필요하다. 즉, 트랜잭션 동작을 감시하는 관찰자 역할을 하는 TransactionTraceAspect를 만들어냈다. 이를 통해, 트랜잭션 내부에서 발생한 상태(성공, 실패, 롤백 여부)를 코드 변경 없이도 획득할 수 있어 테스트나 로깅등을 할 수 있다.

• 트랜잭션 동작을 관찰하는 역할
• 별도 코드 수정 없이 트랜잭션 상태 정보 획득 가능
• 테스트 및 로깅에 활용 가능

📌 트랜잭션 롤백 테스트와 상태 추적 AOP의 원리

1. 스프링 트랜잭션 관리 원리 스프링은 AOP를 구현하기 위해 프록시 패턴을 사용합니다. @Transactional이 붙은 클래스에 대해 동적 프록시를 생성하고, 이 프록시를 통해 메서드 호출을 가로채 트랜잭션 경계를 설정한다.

• 스프링은 @Transactional이 붙은 클래스에 대해 프록시 객체를 생성한다.
• 클라이언트가 실제 객체의 메서드를 호출하면, 스프링은 프록시 객체를 통해 호출을 가로챈다.
• 프록시는 트랜잭션을 시작하고, 실제 객체의 메서드를 실행한다.
• 메서드가 정상 종료되면 프록시는 트랜잭션을 커밋한다.
• 메서드 실행 중 예외가 발생하면 프록시는 트랜잭션을 롤백하여 데이터 일관성을 보장한다.

2. 트랜잭션 롤백 테스트 원리

• 테스트는 @Transactional이 적용된 최상위 메서드를 대상으로 한다.
• 이때 모킹 프레임워크(Mockito 등)를 사용하여 내부 서비스 메서드에 강제로 예외를 발생시킨다.
• 최상위 메서드는 이 예외를 감지하고, 스프링의 트랜잭션 관리자에 의해 롤백이 유도된다.
• 테스트는 이 롤백이 실제로 발생했는지 검증하여 트랜잭션이 올바르게 동작하는지 확인한다.

3. 트랜잭션 상태 추적을 위한 AOP 원리

• AOP(Aspect Oriented Programming)를 이용해 @Transactional 메서드 실행 시점 전후에 추가 로직을 삽입한다.
• 메서드 실행 전, AOP는 ThreadLocal 기반 저장소(TransactionTraceHolder)에 트랜잭션 추적 정보를 기록한다.
• 메서드 실행 중 예외가 발생하면 AOP는 이를 감지하고, 트랜잭션 상태(TransactionAspectSupport.currentTransactionStatus())를 읽어와 롤백 여부, 예외 발생 여부를 추적 정보에 업데이트한다.
• 이 상태 정보는 테스트 코드나 로깅 시스템에서 참조할 수 있어, 트랜잭션의 동작을 정확히 파악할 수 있다.

테스트 진행

롤백 테스트 중 재고차감 실패시 전체 트랜잭션이 롤백되는지의 여부를 확인하는 테스트이다.

핵심 메커니즘

• TransactionAspectSupport.currentTransactionStatus()를 호출해 현재 스프링 트랜잭션의 상태를 얻는다.
• isRollbackOnly 값이 true면, 해당 트랜잭션은 롤백 대기 상태임을 의미한다.
• @Around 어드바이스는 예외 발생 여부를 감지하고, 메서드 실행 결과와 함께 상태 정보를 저장한다.

소감

처음에는 트랜잭션 롤백 테스트가 복잡하고 어려운 주제로 느껴졌다.특히 여러 서비스가 엮여 있고, 동시에 발생하는 예외 상황까지 고려해야 하다 보니 더욱 그랬다. 하지만 이번에 직접 코드를 작성하고, AOP로 트랜잭션 상태를 추적하는 방식을 적용해보면서 스프링이 제공하는 트랜잭션 관리의 강력함과 유연함을 다시 한번 체감할 수 있었다. 테스트 코드로 롤백 동작을 검증하니, 수작업 테스트 대비 훨씬 신뢰도가 높고 반복 가능하다는 점도 큰 장점이었고, 이 덕분에 서비스 안정성을 높이는 데 큰 도움이 될 것이라 생각한다. 또한, AOP를 활용해 트랜잭션 상태 정보를 실시간으로 수집하고 기록하는 구조는 로깅이나 모니터링, 문제 발생 시 원인 분석에도 매우 유용하다는 점에서 운영 환경에서 장애 대응에 큰 힘이 될 것이라는 생각이 들었다.

멱등성이란?

멱등성은 같은 작업을 여러번 수행하더라도 항상 동일하게 유지되는 성질이다. 사용자의 실수로 버튼을 여러번 누르거나, 네트워크 불안정으로 요청이 중복 전송될때 시스템이 오작동하지 않도록 방지하는 중요한 개념이다. 즉, 좋아요 기능을 예시로 들자면, 좋아요를 여러번 눌러도 좋아요 개수가 계속 늘어나거나, 이미 좋아요를 취소했는데 다시 취소 요청이 들어와도 오류가 나지 않아야 한다는 의미이다.

비교

올리브영

: POST (개별 액션 엔드포인트) 올리브영은 좋아요(찜하기) 등록과 취소를 각각 다른 POST 엔드포인트를 통해 명확하게 구분하여 처리한다.

구현 방식 분석

• 좋아요(찜하기) 등록:

  • 메서드: POST
  • 엔드포인트: https://www.oliveyoung.co.kr/store/mypage/getWishListJson.do
  • 사용자가 상품을 찜할 때 이 엔드포인트로 요청을 보낸다.

• 좋아요(찜하기) 취소:

  • 메서드: POST
  • 엔드포인트: https://www.oliveyoung.co.kr/store/mypage/delWishLstAjax.do
  • 사용자가 찜한 상품을 취소할 때 이 엔드포인트로 요청을 보낸다.

    장점

• 명확한 액션 구분: 각 API가 수행하는 액션(등록/삭제)이 URL에 명시적으로 드러나 개발자가 이해하기 쉽다. API의 목적이 URL에 담겨 직관적이다.

• 클라이언트의 명시적 제어: 클라이언트가 '등록'과 '취소'를 명확히 구분하여 요청을 보낼 수 있다.

멱등성 보장

POST는 본래 멱등성이 보장되지 않는다. 따라서 올리브영은 서버 측에서 다음과 같은 방식으로 멱등성을 보장할 것이라 '예상' 한다.

• 등록 요청 시: 이미 해당 상품이 사용자의 찜 목록에 있다면, 중복으로 추가하지 않고 성공 응답을 반환한다. 데이터베이스의 고유 제약 조건(Unique Constraint)을 활용하여 중복 저장을 방지하는 것이 일반적이다.

• 취소 요청 시: 해당 상품이 찜 목록에 없다면, 삭제할 것이 없으므로 아무것도 하지 않고 성공 응답을 반환한다.

• 동시성 제어: 여러 번의 요청이 거의 동시에 들어올 경우, 서버는 내부적으로 트랜잭션 또는 락(Lock)을 통해 한 번의 처리만 보장한다.

무신사

: POST (단일 엔드포인트 & Body로 액션 구분) 무신사는 '좋아요(찜하기)' 등록과 취소를 하나의 POST 엔드포인트로 처리하되, 요청 본문(Body)의 데이터로 실제 수행할 액션(등록 또는 취소)을 구분한다.

구현 방식 분석

• 메서드: POST
• 엔드포인트: https://log.data.musinsa.com/log/user-event/v2_cart_purchase_like

• 액션 구분: 등록시

  • 요청 본문 data 내에 event_name: "add_to_wishlist" 포함

• 액션 구분: 취소 시

  • 요청 본문 data 내에 event_name: "remove_from_wishlist" 포함

장점

• 단일 API 엔드포인트: 클라이언트가 '찜하기' 관련 기능을 하나의 URL로 관리할 수 있다.

  멱등성 보장

  POST는 멱등성을 가지지 않으므로, 무신사도 서버 측에서 멱등성을 보장해야 한다. 이는 올리브영의 개별 POST 엔드포인트 방식과 유사할 것이라 예상한다.

• 요청 본문 분석: 서버는 event_name 값을 확인하여 'add' 요청인지 'remove' 요청인지 파악한다.

• 현재 상태 확인 및 조건부 처리:

  • add_to_wishlist 요청 시: 이미 찜 목록에 있다면 중복 추가하지 않고 성공 응답.
  • remove_from_wishlist 요청 시: 찜 목록에 없다면 삭제하지 않고 성공 응답.

• 동시성 제어: 여러 번의 중복 요청에 대해 데이터 정합성을 유지하기 위한 서버 내부 로직(고유 제약, 락 등)이 필요하다.

컬리

: PUT (단일 엔드포인트 & Body로 상태 변경) 컬리는 '좋아요(찜하기)' 상태 변경을 PUT 메서드를 사용하고, 요청 본문(Body)에 최종적인 찜 상태를 true 또는 false로 명시하는 방식을 사용한다.

구현 방식 분석

• 메서드: PUT

• 엔드포인트: https://api.kurly.com/member/proxy/pick/v1/picks/products/{productId} ( {productId}는 실제 상품 ID)

• 상태 구분:

찜하기 설정 시: 요청 본문 {"is_pick": true}

찜하기 해제 시: 요청 본문 {"is_pick": false}

장점

PUT 메서드의 멱등성 활용: PUT 메서드는 자원의 전체를 갱신하는 의미를 가지며 그 자체가 멱등성을 보장한다. 같은 요청을 여러 번 보내도 자원의 최종 상태(찜 여부)는 항상 동일하게 유지된다. 이는 서버 측 멱등성 구현 부담을 줄여준다.

단일 API 엔드포인트 & 상태 주도: 클라이언트는 현재 찜 상태와 관계없이 원하는 최종 상태만 is_pick: true 또는 is_pick: false로 전달하면 된다. 클라이언트 로직이 비교적 간결하다.

멱등성 보장

PUT 메서드 자체가 멱등성을 보장하므로, 서버는 요청 본문의 is_pick 값에 따라 단순히 해당 상품의 찜 상태를 '설정' 또는 '해제'하면 된다. 중복 요청이 들어와도 결과는 동일하다.

그렇다면, 어떤 방법이 '더' 나을까?

세 가지 방법 모두 멱등성을 성공적으로 보장한다. 어떤 방법이 '더 좋다'고 단정하기는 어려우며, 이는 API 설계 철학, 개발팀의 선호도, 그리고 서비스의 특성에 따라 달라질 수 있다.

• 올리브영의 POST (개별 액션): API의 명시성과 직관성을 중요하게 생각하는 경우 유리하다. 각 URL이 어떤 액션을 수행하는지 명확하다. POST의 멱등성은 서버 측에서 견고하게 처리해야 한다.

• 무신사의 POST (단일 & Body 구분): 단일 엔드포인트를 선호하면서도 POST 메서드를 사용해야 할 때 선택할 수 있는 방식이다. 특히 이벤트 로깅 시스템과 연동이 필요할 때 유용할 수 있다. 역시 POST 멱등성은 서버가 보장한다.

• 컬리의 PUT (단일 & Body로 상태 변경): HTTP 메서드의 멱등성 속성을 적극적으로 활용하여 서버 측 구현의 복잡성을 줄이고 싶을 때 이상적이다. '찜하기' 상태를 특정 리소스의 속성으로 보고 이를 업데이트하는 RESTful 한 방식에 가깝다.

궁극적으로 중요한 것은 어떤 방식을 선택하든 시스템의 신뢰성을 위해 멱등성이 완벽하게 보장되도록 설계하고 구현하는 것이라 생각한다. 다만 흥미로웠던 점은 같은 기능이 각기 서비스마다 다른 형태를 보였다는 것이다. 이를 통해 같은 방향을 추구하지만 정답이 없음을 다시한번 느꼈다.

예전의 나에게 테스트란 단지 ‘구현이 끝난 후, 이상이 없는지 확인하는 마지막 절차’였다.
하지만 지금은 다르다. 테스트는 이제 내가 어떻게 구현해야 할지를 알려주는 설계 지침서다.

이 글에서는 테스트가 내 개발 방식과 사고를 어떻게 바꿔놓았는지, 그리고 내가 생각하는 좋은 테스트란 무엇인지를 이야기해보려 한다

📌 E2E 테스트

E2E(End-to-End) 테스트는 사용자의 요청이 프론트엔드를 거쳐 백엔드와 DB까지 연결되는 전체 흐름을 검증하는 테스트다.

예를 들어, ‘포인트 조회’ 기능을 개발한다고 해보자. 테스트를 먼저 작성하면서 다음과 같은 질문이 자연스럽게 떠오른다:

1. 어떤 endpoint로 요청할 것인가?
2. 어떤 요청값이 필요하고, 어떤 응답값을 줄 것인가?

이런 고민을 바탕으로, 먼저 간단한 테스트 코드를 작성하고 mock 응답을 내려주는 방식으로 작업을 시작했다.
이를 통해 프론트엔드 개발자와 백엔드 개발자가 기능 구현 이전에 명확한 요청/응답 계약을 공유하고, 병렬로 작업할 수 있는 기반을 만들 수 있었다.

이 단계에서의 테스트는 실제 DB나 구현 로직 없이도 API의 인터페이스와 흐름을 검증하는 데 목적이 있다.
엄밀히 말하면 이는 ‘Stub 기반 테스트’ 또는 ‘Contract 테스트’에 가깝지만, 이후 실제 구현이 완성되면 자연스럽게 진짜 E2E 테스트로 발전하게 된다.

예전의 나였다면 컨트롤러뿐 아니라 서비스, 레포지토리, 엔티티까지 전부 구현한 후 테스트를 작성했겠지만,
지금은 테스트를 먼저 작성하고, 그 테스트를 통과하는데 필요한 최소한의 구조만 정의하고 흐름에 따라 점진적으로 구현을 확장해나간다. 즉, 이 테스트는 일회용이 아닌, 이후 전체 흐름을 점검하는 완전한 E2E 테스트로 진화하며 끝까지 유지된다.

이처럼 테스트는 ‘기능이 다 구현된 후 확인하는 단계'가 아니라, 처음부터 설계를 이끄는 도구로 사용될 수 있다. 지금 보여준 예시는 아직 2단계까지 구현된 상태이며, 단위 테스트와 통합 테스트를 거쳐, 이 테스트는 완전한 E2E 테스트로 완성될 예정이다.

다음과 같은 단계를 거쳐 테스트를 완성된 E2E로 발전시켜간다.

• 1단계 – Stub 기반 테스트: 요청/응답 형태를 테스트로 먼저 정의

• 2단계 – 최소한의 구조 구현: DTO, Controller 등 테스트 통과에 필요한 부분만 작성

• 3단계 – 점진적 로직 구현: 실제 서비스/도메인 구성 요소 추가

• 4단계 – 통합된 E2E 테스트: 실제 데이터, DB, 전 구간 테스트

  📌 단위 테스트

  단위 테스트에서는 핵심 비즈니스 로직에 대한 정합성과 규칙을 검증한다.
  예를 들어 ‘포인트 충전’ 기능을 구현하면서, 다음과 같은 규칙을 세웠다:

• 0 이하의 값은 충전할 수 없다.

이다. 이 로직을 어디에서 검증할지 고민하게 되었고, 결국 request → command로 변환하는 시점에서 유효성을 체크하기로 했다.
이렇게 계층별로 책임을 분리함으로써 테스트 가능성과 유지보수성이 향상되었다.

내가 단위 테스트를 작성하면서 가장 크게 달라진 점이 있다면,

• 그전에는 중요한 로직을 private 함수에 숨겨놨다.
  → 중요한 비즈니스 로직은 별도 클래스로 분리하여 작은 public 함수로 노출
• 한 메서드에 여러 책임이 혼재되어 있었다 (생성 + validate 등).
  → 테스트가 명확해지도록 책임을 분리
• 단, 외부에 무분별하게 public으로 열기보다는 설계를 통해 테스트 가능하게 만들자.

📌 통합테스트

각 기능이 단독으로는 잘 동작하더라도, 실제 서비스에서는 다양한 컴포넌트가 조합되어 동작한다.
통합 테스트는 이러한 구성 요소들이 서로 올바르게 연결되어 있는지, 데이터 흐름에 문제가 없는지를 확인하는 테스트다.

예를 들어, 회원가입 기능에서 다음 두 가지가 모두 성공해야 한다:

1. 회원 정보가 DB에 저장된다.
2. 저장된 회원 정보가 응답으로 반환된다.

이 테스트는 UserService.create()를 호출했을 때,

• UserRepository.save()가 실제로 호출되었는지,
• 저장된 값이 올바르게 매핑되어 응답으로 반환되었는지를 검증한다.

📌 좋은 테스트란 무엇인가

내가 생각하는 좋은 테스트는 "잘 실패하는 테스트"다.

기능을 수정하거나 리팩토링할 때, 이전에 작성한 테스트가 실패한다면 자연스럽게 이렇게 생각하게 된다:

"이번 변경이 기존 기능에 어떤 영향을 미친 걸까?" "어디서 잘못된 흐름이 발생했지?"

이런 고민을 통해 전체 구조와 책임을 다시 한 번 되짚어보게 되고,그 과정은 곧 코드를 더욱 견고하게 다듬는 시간이 된다.

잘 실패하는 테스트는 결국 “코드를 되돌아보게 만드는 테스트”다.

테스트가 깨지면 무조건 그 원인을 분석하게 되고, 그 분석 과정에서 설계, 구조, 책임의 균형을 검토하게 된다.이것이 내가 테스트를 사랑하게 된 이유이자, 테스트의 진짜 가치라고 믿는 부분이다.

내가 생각하는 좋은 테스트의 조건

• 잘 실패한다: 코드 변경이 기존 동작에 어떤 영향을 미치는지 즉시 드러난다.
• 설계를 이끈다: 테스트를 먼저 작성하면서 구조와 책임이 명확해진다.
• 신뢰할 수 있다: 반복 실행 시 항상 같은 결과를 보장한다.
• 빠르다: 실행 속도가 빨라, 언제든 부담 없이 돌려볼 수 있다.

📌 결론

우리는 매일 많은 기능을 만들고, 그 기능들은 수많은 사용자가 경험하게 된다.
그렇기에 테스트는 단순한 ‘확인’의 수단이 아니라, 설계의 시작점이자 유지보수의 안전망이 되어야 한다.

TDD에서 말하는 "Driven"은 단순히 테스트를 먼저 쓴다는 의미가 아니다.
진짜 핵심은, 테스트가 코드의 방향, 책임 분리, 인터페이스 구조를 이끌어가는 힘이라는 점이다.

이제 테스트는 ‘시험’이 아니라 ‘설계자’다. 즉, 테스트는 단지 '기능을 확인하는 수단'이 아니다.
테스트는 설계를 이끌고, 유지보수성을 확보하며, 개발자의 자신감을 만들어주는 자신감의 근거가 된다고 생각한다.

배경

이번에 회사에서 진행했던 프로젝트는 승인서버 프로젝트이다. 승인서버 프로젝트는 외부 연동으로 들어온 데이터를 우리 관리 시스템으로 들어오기 전에 검수하는 시스템을 구축하는 프로젝트다.

크게 보면 이렇게 볼 수 있다.

여기서 내가 한 일 중 하나는 이미지 배치 처리 기능의 설계 및 구현이다. 주요 작업은 다음과 같다.

S3 이미지 업로드를 위한 비동기 배치 모듈 개발

• 1시간 단위로 실행되는 이미지 배치 작업: INIT, FAIL 상태이며 재시도 횟수가 1 이하인 프로덕트/아이템 이미지를 대상으로 처리
• 특정 프로덕트 단위의 재연동 기능 구현: 선택된 프로덕트의 INIT, FAIL 상태 이미지만 재처리하며, 재시도 제한 없음

  이미지 업로드 후 상태 및 재시도 관리

• 업로드 성공 시: retry 횟수 증가 + 상태 COMPLETE로 변경
• 업로드 실패 시: retry 횟수 증가 + 상태 FAIL 유지 및 슬랙 알림 전송

배치를 적용한 이유

2차 승인 단계에서 등록되는 각 프로덕트/아이템은 여러 개의 이미지를 포함하고 있으며, 이 이미지들은 모두 AWS S3에 업로드되어야 한다. 초기에는 등록 시점에 실시간으로 이미지를 업로드하는 방식도 고려했지만, 아래와 같은 이유로 배치 처리 방식을 도입하게 되었다.

성능 이슈

이미지 업로드는 네트워크 I/O와 S3 API 호출이 포함된 작업으로, 처리 시간이 길다. 이를 실시간으로 수행할 경우 등록 속도가 느려지고, 사용자 경험에도 부정적인 영향을 줄 수 있다.

처리 안정성 확보

등록 도중 이미지 업로드에 실패하면 전체 등록이 실패할 수 있다. 배치로 처리하면 실패한 이미지에 한해 재처리할 수 있어 안정적인 처리가 가능하다.

S3 요청 비용 최적화

AWS S3는 요청 건수에 따라 비용이 발생한다. 실시간으로 이미지를 업로드할 경우, 이미지 수만큼 S3 요청이 발생하고, 트래픽이 많아질수록 비용도 크게 증가한다. 배치 처리 방식은 요청을 모아서 처리하기 때문에 네트워크 연결 및 클라이언트 설정을 재사용할 수 있고, 요청 효율을 높여 비용 절감과 처리 흐름 단순화에 기여한다.

이러한 이유로 이미지 업로드 작업을 프로덕트/아이템 등록 시점이 아닌 배치 처리로 전환하게 되었고, 해당 로직의 설계와 구현은 내가 직접 맡아 수행하였다.

장애 발생 및 대응

시원한 음료 한 잔 마시며 한숨 돌리고 있던 그 때 경고가 떴다!!!!!! 락이 걸린다고? 갑자기?? 배치에서??? 왜??? 범인은 나였다. 나야 나...(내가 그 주인공이 될 줄은 몰랐다)

원인

이미지 업로드를 시키는 과정은 사실 단순하다.

1) INIT,FAIL 상태 & 재시도 1 이하인 임시이미지 조회 2) 해당 이미지 S3에 업로드 3) 해당 이미지 상태, 재시도 개수 수정 저장

근데 문제는 내가 데이터의 규모를 예상치 못하고 조회시 관련 모든 데이터를 가져오게 만들었다는 것이다. 사실 이것만 봤을때는 뭐가 문제인데 할 수 있다. 관련 모든 데이터를 가져오는게 맞잖아? 그러나.. 데이터의 양이 6만 3천개라면?

왜 락이 걸렸을까?

쉽게 말하면 6만개의 데이터를 수정하면서도 저장(flush)를 미루니까 트랜잭션이 너무 길어지고 락이 오래 유지되는 상황에서 동시에 같은 row에 접근하려는 다른 트랜잭션과 충돌이 발생하게 된것이다.

정리하면, 다음 세 가지가 문제의 핵심이었다:

1. 한 번에 모든 데이터를 불러옴 (6만 건)
2. 처리 중간에 flush 없이 트랜잭션을 유지
3. DB 업데이트가 지연되면서 row-level lock 충돌 발생

해결법

page 단위로 chunk 100개씩 가져와서 락을 빨리 빨리 해제하도록 수정하였다.

• AS_IS

• TO_BE

후기

해결 방법은 단순했다. 데이터를 페이지 단위로 나눠서 처리하면 되는 일이었다. 하지만 처음에는 그 방식이 떠오르지 않았다. 테스트 환경에서는 문제없이 동작했고, 실제 운영에서 63,000건이 넘는 데이터가 한 번에 들어올 거라고는 예상하지 못했기 때문이다.

이번 일을 통해 대규모 데이터 처리에서의 사소한 설계 차이가 시스템 안정성에 큰 영향을 줄 수 있다는 점을 몸소 깨달았다. 특히 다음 두 가지를 깊이 체감했다:

• 운영 환경 데이터를 기준으로 사고할 것

• 트랜잭션은 짧고 명확하게 유지할 것

실제 장애는 대량 데이터를 한꺼번에 처리하면서 트랜잭션이 길어지고, 그로 인해 DB 락 충돌이 발생한 것이 원인이었다. 이후 100건 단위로 나눠 처리하는 방식으로 개선하면서 락 점유 시간을 줄일 수 있었다.

단순한 설계 실수도 큰 장애로 이어질 수 있다는 점을 다시금 느꼈고, 앞으로는 더 철저하게 사고하고 검증해야겠다는 다짐을 하게 된 경험이었다.

📌 등장 배경

🌞 화창한 아침..운영 실무자에 의해 데이터 변경 요청이 떨어졌다

현재 요청된 내용은 프로덕트에 매핑된 속성을 변경하되 그 속성 옵션값은 그대로 유지해달라는 요청이다. 좀 더 구체적으로 말해보자면, 상품1에 속성으로 PRADA 컬러라는 속성이 있고 그 값으로 빨강, 주황이 있는데 상품 1의 속성을 GUCCI 컬러라는 속성으로 변경하되 값은 그대로 빨강, 주황으로 유지 해달라는 것이다.

• 운영팀의 요청: 특정 상품의 속성을 다른 속성으로 변경해야 하지만, 속성 값은 유지해야 한다.

• 문제: 기존 정책상 노출 속성은 수정할 수 없으므로, 마이그레이션 작업이 필요하다.

현재 정책상 노출 속성은 한번 상품에 매핑되면 수정불가한 정책을 가지고 있기 때문에 우리가 마이그레이션을 해줄 수밖에 없다.

내가 할일은

1. product_attribute에서 attribute를 변경해주고
2. item_attribute_option에서 attribute와 attributeOption을 변경해줘야한다. 바꿀 attributeOption은 기존의 attributeOption 값과 일치한 것을 찾아다가 변경해주면된다.

사실 여기까지보면 뭐.. 쿼리 돌려주면 되지 한다. 맞다 이 일은 어렵지 않다. 근데 문제는 hash이다. 이번 이야기에서 나오는 주제의 주인공은 HASH이다.

우리는 상품과 아이템의 중복확인을 hash로 구별한다.

• 상품 중복 조건 : 카테고리 + 상품이름 + 노출속성목록 + 브랜드Id + 모델명
• 아이템 중복 조건 : 상품 Id + 노출속성목록 + 속성값목록

이렇게 되어 있다. 이번에 이 조건들 중에 상품에는 노출 속성 목록이, 아이템에는 노출속성목록과 속성값 목록이 변경되기 때문에 Hash를 새로 변경해줄 수밖에 없다. 그럼 변경된 상품과 아이템만 변경하면되잖아? 하기에는 이번 작업부터 중복 조건이 일부 변경되었다. 위에 언급한 조건은 이번에 변경되는 조건에 해당된다.

에이 변경하면 되지..하기엔 단순히 몇백개가 아니고 몇십만 단위다..ㅎ 거기다가 상품 중복 조건이 이번 작업부터 변경된 조건이라 해시 충돌이 안날래야 안날 수가 없는 작업이다 ㄸㄹㄹ,,

💡 정리하자면, 상품과 아이템의 중복 여부를 확인하는 데 해시를 사용하는 이번 속성 변경하면서 그 기준이 되는 값 또한 변경이 되었기에 hash 작업이 필요하다

📌 Hash?

💡 해시 임의의 크기를 가진 데이터를 고정된 크기의 데이터로 변화시켜 저장하는 것

결론부터 말하자면, 동일한 입력값이면 항상 동일한 해시값이 생성되므로, 데이터를 직접 비교하지 않고도 빠르게 중복을 판별할 수 있다. 즉, 중복 체크하는데 성능적으로 해시가 더 빠르다고 판단한 것이다.

🐳 직접 비교 Vs 해시 비교

상품을 등록하는 걸 예시로 들어보자. 상품을 등록하기 전 위 중복조건에 의해 중복된 상품이 있는지 확인해야 한다.

만약 직접 비교해야 한다면?

EXPLAIN SELECT * FROM product WHERE category_id = ? AND product_name = ? AND brand_id = ? AND model_no = ? AND displayed_attribute_ids = ?;

해당 쿼리를 돌려 보면 실행계획에 테이블 풀스캔하고 있음을 확인할 수 있었다. 즉, 상품을 추가할때 기존 상품과 하나씩 비교한다는 것이다. -> 최악의 경우 O(N) 풀 스캔하는 것을 보니 데이터가 많을수록 성능이 저하됨을 의미하는데 현재 우리 상품은 몇십만개이다. 그럼.. 성능은 아주 최악이 되는 것이다.

그럼 Hash의 경우는?

EXPLAIN SELECT * FROM product_identity pi WHERE pi.hash = ?;

해당 쿼리를 돌려보면

const row lookup으로 인덱스를 확용한 상수 조회를 하고 있음을 확인할 수 있다. 해당 스캔 방식은 단일 행을 대상으로 하는 상수 값을 기반으로 하는데 Primary Key 또는 Unique Key에 대한 WHERE 절의 상수 값 비교가 있을 때 나타난다. hash에 의해 unique를 걸 수 있기 때문에 인덱스를 걸 수 있는 것이다. 즉, 테이블의 유니크 인덱스 (uk_hash)를 사용하여 단 한개의 행만 조회하고 있다. -> 시간 복잡도 O(1) ~ O(logN)

결과적으로 직접 비교보다 해시비교가 풀스캔 방지가 될 뿐만아니라 속도도 훨씬 빠르기 때문에 중복 검사에 해시를 적용하는 것이 성능상 최적이라는 것을 알 수 있다.

정리하자면,

• 직접 비교 풀스캔, 시간복잡도 : O(N), 데이터 많을수록 성능 저하

• Hash 비교 O(1) ~ O(logN), 인덱스를 활용해 빠른 조회 가능

📌 마이그레이션 작업에 대한 회고

작업에 대한 플로우를 말해보자면,

1. 속성 변경에 대한 프로덕트-속성 매핑 데이터, 아이템-속성 매핑 데이터 변경
2. 중복 조건에 의한 해시 충돌 테스트
3. 충돌된 상품에 대한 실무자 전달 및 데이터 정리
4. 프로덕트, 아이템 해시 테이블에 생성 -> 임시 테이블에 생성
5. 기존 해시 테이블 백업 후 임시테이블을 기존 테이블 명으로 변환
6. product, item 해시 캐시의 기존 데이터 삭제 후 새로 생성

상용 데이터를 다루기도 하고, 내 기준상 데이터가 많아서 사실 두렵기도 하고 어려움도 많았던 작업이었다. 이 작업을 하면서 흥미로웠던 구간은 기존의 데이터에 대한 해시 생성 구간이었다.

아이템만 해도 현재 활성화된 아이템이 몇십만개인데 이걸 어떻게 생성을 하느냐? 방법은 page를 활용해서 한번에 3000개씩 가져와서 배치를 돌리는 것이다. ( 이건 그냥 여담인데 아무생각없이 10개씩 가져오도록 했다가 반나절이되어도 안끝났다..ㅎ 그래서 확 3000개씩 가져오는 걸로 바꾸었더니 5도 안되어서 끝났다. ㅎㅎ 네트워크 비용에 대한 체감이 확 드는 순간이었다. )

🐳 내부 코드 분석

가장 흥미로웠던 코드를 분석해보자.

해당 코드는 대량 데이터를 한번에 삽입해야 할때 사용한다. 먼저 excute 내부 코드를 살펴보면, ( Spring 내부 코드 )

1) getTransaction() : 직접 트랜잭션을 가져오고, 2) commit() : 트랜잭션을 직접 커밋하고 3) rollbackOnException() : 트랜잭션을 수동으로 롤백하고 이를 통해 excute() 메소드는 트랜잭션 관리 로직을 직접 실행하는 메서드임을 확인할 수 있다. -> 예외 발생시 전체 롤백이 되게 됨을 알 수 있다. 실제로 테스트할때 충돌로 인한 예외 발생시 전체 롤백된 것을 확인하였다.

대망의 batchUpdate 메소드를 살펴보자면, ( Spring 내부 코드 ) 이 메소드는 JDBC 기반 배치 업데이트 메서드로 여러개의 데이터를 한번에 업데이트하는 기능을 함을 알 수 있다.

실제로 Sql에 해당 하는 코드가 이렇게 앞전에 선언해놓았고, 이것을 매개변수로 받아서 hash 생성을 한꺼번에 하는 것을 알 수 있었다.

🐳 회고

이 작업을 수행하면서, 역시 직접해봐야 좀더 와닿음을 다시 한번 확인하는 순간이었다. 내가 이번에 작업한 해시는 이전부터 중복 검사를 위해 해놓았던 조치였다. 그러나 내가 한게 아니다보니, 해시 작업에 대한 이해도가 낮았다. 이번에 해시 생성 작업을 하다보니, 왜 필요하고 어떤 코드를 사용했는지 나를 납득해가면서 작업을 하다보니 얻어가는 것도 많고 이해도도 높아짐을 알 수 있었다. 나중에 중복 검사가 필요할때 이 작업을 떠올리며 해시를 생각해내지 않을까? ㅎㅎ😄

처음에 이 작업이 주어졌을때, 상용 데이터를 만진다는 것에 대한 두려움이 있었는데, '이 연차에 어떤 누가 몇십만개의 상용 데이터를 다루는 경험을 하겠어?' 하는 마음으로 임했다. 그래도 무서웠다. 혹시 내가 잘못할까봐 덜덜 떨면서 했다. 며칠 지난 지금, 이 작업을 회고하면 간단한데? 싶다.

이 작업에서 가장 오래 시간이 걸렸던 부분은 해시 충돌 부분이었다. 사실 상품 해시 충돌은 예상했지만, 아이템 해시 충돌은 예상 못했다. 왜냐면 상품 해시 충돌된 것을 해결하면(상품 충돌난 아이템까지 삭제했기에) 아이템 중복 기준에 상품 ID가 있기 때문에 아이템 해시 충돌은 전혀 나지 않을 것이라 예상했기 때문이다. 그런데 아이템 해시 충돌이 발생했다.

앞선 코드에 보여줬던 것이 하나라도 충돌되면 멈추는 로직이기때문에 몇십만개의 아이템을 다 돌리면서 충돌날때마다 에러나는 상황은 너무나도 시간이 많이 들기때문에

에러나더라도 계속 돌아가도록 해당 부분을 try-Catch로 감싸서 충돌나서 에러가 나더라도 멈추지 않도록 했고, 페이지네이션으로 3000개씩 데이터를 돌렸더니 몇십만개의 데이터가 모두 거의 5분만에 다 돌아가서 모든 충돌을 잡아낼 수 있었다. 덕분에 빠르게 어떤 아이템들이 충돌났는지 확인할 수 있었다.

거의 40개의 아이템이 충돌났고, 상품으로 따지자면 3개 상품에 대한 아이템들이었다. 알고보니 임의로 수동으로 넣은 아이템 데이터에서 발생한 것이다. 따라서 해당 아이템들과 상품들을 삭제하니 해결되었던 문제였다.

해시 충돌된 상품들과 아이템들이 다행히 모두 주문이 나간적이 없거나 테스트 상품이라서 삭제하기 어렵지 않았다. 물론 해당 상품과 아이템들을 삭제하기 위해 그 하위 집단인 벤더아이템, 딜벤더아이템, 딜 등의 삭제 작업들을 추가로 해줘야 하지만 오더가 없었기에 스위칭이 아닌 삭제로 해결할 수 있었던 작업이었다. 이번 작업을 통해 실무자와 커뮤니케이션도 해야하고 배포 작업도 걸려있어서 부담이 많이 가는 작업이었다. 하지만, 정말 값진 경험이었다. 앞으로 중복검사나 데이터 마이그레이션이 필요할때 이번 경험이 큰 도움이 될 것 같다.

📌 조건은?

우선, 난 Jmeter를 활용해서 하나의 락을 거는 @DistributedLock과 여러 락을 동시에 거는@MultiDistributedLock에 대한 동시성 테스트를 진행했다. 조건은 둘다 똑같이 설정했다. 조건을 해석해보자면,

• 50개의 스레드 (동시 사용자 50명)
• Ramp-up 시간 50초 (1초마다 1개의 스레드가 추가됨)
• Loop Count: 10 (각 스레드가 10번 반복 요청)

→ 즉, 최대 500개의 요청이 순차적으로 발생

추가적으로 설명하자면, Ramp-up Period는 모든 스레드(사용자)를 얼마나 걸쳐서 실행할지를 결정하는 값이다. 즉, JMeter는 총 N개의 스레드를 Ramp-up Period 동안 균등하게 분배하여 시작한다.

이걸 공식으로 정리하자면, 🔹 스레드 시작 간격 (초) = Ramp-up Period / 총 스레드 개수

내가 설정한 조건에 의하면, Ramp-up Period를 50초, 스레드 개수를 50으로 설정하게 되고 50초/50쓰레드 가 되니 1초마다 1개의 스레드가 추가되는 구조가 된다.

정리하자면, 50초 동안 50개의 스레드가 점진적으로 늘어나며, 매 초마다 1개의 스레드가 실행된다. 50초가 지나면 모든 스레드가 동시에 실행된 상태에서 반복(Loop Count: 10번)하면서 요청을 보내게 되는 조건이다.

📌 테스트 해볼까?

이제 본격적으로 테스트를 해보자.

@DistributedLock 테스트

{
  "id": "row:2"
}

하나의 키를 동시에 여러번 테스트하는 것인데 한 키만을 걸었기 때문일까

모든 요청이 동시에 보냈음에도 불구하고 성공률이 100%였다 ㅋㅋㅋ 하나하나 뜯어보자면,

• Samples: 500 → 총 500개의 요청이 전송됨
• Average: 5006 ms → 모든 요청의 평균 응답 시간이 5006ms (5.006초)
• Median: 5006 ms → 응답 시간을 작은 순서대로 정렬했을 때 중간 값이 5006ms
• 90% Line: 5010 ms → 응답 시간이 5010ms 이하인 요청이 전체의 90%
• 95% Line: 5012 ms → 응답 시간이 5012ms 이하인 요청이 전체의 95%
• 99% Line: 5015 ms → 응답 시간이 5015ms 이하인 요청이 전체의 99%
• Min: 5001 ms → 가장 빠른 응답 시간이 5001ms
• Max: 5028 ms → 가장 느린 응답 시간이 5028ms
• Error %: 0.0% → 오류 없이 100% 성공
• Throughput: 5.0/sec → 초당 평균 5개의 요청을 처리
• Received KB/sec: 0.86 KB/s → 서버에서 초당 0.86KB 데이터를 받아옴
• Sent KB/sec: 1.03 KB/s → 서버로 초당 1.03KB 데이터를 보냄

평균 응답시간 (Throughput)이 5초인게 아마 코드 상 Thread.sleep(5000) 영향인 듯 싶다. 사실 어떻게 100% 성공일 수 있지? 설마 락이 안걸리나 싶어서 log를 걸어서 봤는데 락이 잘 걸려있는 것을 확인할 수 있었다. 그렇다면 멀티로 락을 걸었을때는 어떨까?

@MultiDistributedLock 테스트

@DistributedLock과 같은 조건으로 진행하였다. 사실 처음에 테스트 할때는 이것도 성공률이 100%일줄 알았다.

뭐야? 이건 왜 간간히 성공해?? 왜 실패한건 500에러야? 에러 메세지를 확인해보니, 락 거는데 에러가 뜬거였다.

Single 락과 Multi 락 왜 같은 조건인데 결과가 다를까??

✔️ @DistributedLock (Single)

• 요청마다 하나의 키(row:2 같은 단일 값)만 사용
• waitTime = 15이므로 락을 못 잡으면 최대 15초까지 대기 + 쓰레드 sleep 5초
• 하나의 키만 처리하므로 충돌 가능성이 낮음
• 결과적으로 스레드 간 충돌 없이 요청이 순차적으로 처리됨 → 실패율 낮음

✔️ @MultiDistributedLock (Multi)

• 여러 개의 키(["row:2","row:1","row:3"])를 락으로 사용
• 만약 다른 스레드가 row:1을 선점했어도, row:2와 row:3이 잠겨 있으면 락을 얻지 못함
• 락을 얻지 못하면 실패 (대기 시간이 지나도 모든 키를 얻지 못하면 실패)
• 일부 키만 사용 가능해도 전체가 실패하는 구조 → 충돌 가능성이 급증

따라서 싱글락과 달리 멀티락에서 에러가 뜨는 것은 동시성 테스트에서 잘 방어를 하고 있다는 뜻이었다.

참고) 나의 github 코드 : https://github.com/sue4869/lockPractice

이번에 회사에서 하는 프로젝트는 '오더 상태 관리'이다. '오더서밋, 오더취소, 배송, 오 더컨펌' 까지의 다양한 오더 상태에 대한 관리를 적용하는 프로젝트이다.

우리 회사는 공급사 상품들의 묶음 단위인 딜을 이용해 주문을 한다. 상품이 있으니까 재고가 있겠지? 즉, 각 오더 상태의 역할별로 재고가 차감되거나 복원된다.

• 오더 서밋시 : 재고 차감
• 오더 취소시 : 재고 복원
• 오더 컨펌시 : 재고 차감 / 재고 복원 이러한 상태가 변경될때 각 딜에는 항상 중복되는 상품이 존재하기 때문에 동시성 문제가 발생하게 된다. 여기서 추가로 딜에는 여러 상품들이 있기 때문에 여러 상품을 동시에 락을 걸어야 하는 상황이다.

📌 동시성 문제를 해결하는 방법

여러가지 방법이 있는데 비관적락, 낙관적락, 분산락, 네임드락 등이 있다. 각각의 특징을 간단히 알아보자면,

1) 비관적락(DB락)

• DB에서 직접 락을 걸어 다른 트랜잭션 차단
• 장점 : 데이터 정합성 강하게 보장, 실시간 동시 수정 방지 가능
• 단점 : 성능 저하(트랜잭션이 길어질수록 락 유지시간 증가), 데드락
• 적용 예시) 은행 계좌 잔고 업데이트

2) 낙관적락(버전 필드)

• 충돌 감지 후 재시도 (rollback & retry)
• 장점 : 락을 안걸어서 성능이 좋음
• 단점 : 충돌이 빈번할 경우 계속 재시도하여 성능 저하를 일으킴. 정합성이 다소 낮음

3) 분산락(Redis, Zookeeper)

• 여러 서버에서 동일한 리소스를 동시에 수정하지 못하도록 제어
• 장점 : 분산 시스템에도 동기화 가능
• 단점 : 락 관리(해제, TTL 설정 등) 신경 써야 함, 분산 환경에서 네트워크 이슈로 인해 지연 가능

우리 회사의 경우, 멀티 인스턴스 환경에서 오더상태 변경을 해야하고 재고관리에 있어서 강한 정합성을 요구하기 때문에 분산락을 적용하기로 결정하였다.

📌 분산락

분산락이란 무엇일까? 앞서 언급했듯이 분산락은 여러 서버에서 동일한 리소스를 동시에 접근하지 못하도록 제어하는 것을 의미한다.(비관적 락이나 낙관적 락은 하나의 DB에서만 동작하는 락) 좀 더 기술적 용어를 사용해서 설명하자면,

💡 분산락 락을 획득한 프로세스 혹은 스레드만이 공유 자원 혹은 Critical Section 에 접근할 수 있도록 하는 것

키(락)를 가진 사람(프로세스/스레드)만 보물이 있는 공간(공유자원)의 문을 열 수 있는 것이다 🗝

분산락을 적용하는 방법은 여러가지가 있다. Redis, Zookeeper, MySql 등등.. 결론적으로 말하자면, 우린 Redis를 사용하였다. 우선 Redis는 그동안 캐시용도로 이미 구성해놓은 반면에 Zookeeper는 추가적인 인프라 구성이 필요하기 때문에 제외하게 되었다. 그리고 알다시피 Redis는 싱글스레드로 작동하기 때문에 동시성 문제도 현저히 작다. 아 물론 Mysql도 있긴 한데, 락을 사용하기 위해 별도의 커넥션 풀을 관리해야 하고 락에 관련된 부하를 RDS에서 받으니 Redis를 사용하는 것이 더 효율적이다.

Redisson을 사용한 이유는?

Redis는 인메모리 데이터 저장소로 사용되지만 , 캐시 역할을 넘어서 다양한 분산 시스템 기능을 지원하는 구현제(라이브러리, 프레임워크)들이 존재한다. 그 중 난 분산락을 위한 구현체에 대해 간단히 알아보자면,

• Jedis -> Lettuce가 성능이 더 좋아서 Lettuce로 대체됨
• Lettuce
• Redisson

1) Lettuce

• Spring Data Redis에서 기본적으로 사용하는 Redis 클라이언트
• setnx를 활용한 스핀락 : 반복적으로 락 획득 시도 -> 레디스에 많은 부하 발생. CPU를 계속 사용하면서 재시도하는 방식
• 락 획득 방식 (1) SET NX 명령어로 락 획득을 시도 (2) 락이 없으면 성공 → 작업 진행 후 DEL로 락 해제 (3) 이미 락이 있으면 실패 → 일정 시간 대기 후 재시도 (스핀락 방식) (4) TTL(EX)을 설정하여 데드락 방지

2) Redisson

• 별도의 Lock interface를 지원 : RedLock, RLock(단일 인스턴스 락) 지원

  💡 RedLock

  • Redis 기반의 분산 락을 더 안전하게 보장하기 위한 알고리즘
  • 멀티 Redis 노드 환경에서 장애 복구가 중요한 경우
  • 데이터 정합성이 중요한 글로벌 시스템
  • Redis 장애가 발생해도 락을 유지해야 하는 경우
  • RedLock은 과반수 이상의 Redis 노드에서 락을 획득해야 성공

• Pub/Sub 방식을 이용하기에 락이 해제되면 락을 subscribe 하는 클라이언트는 락이 해제되었다는 신호를 받고 락 획득을 시도

• Redisson은 락 대기 및 해제 처리를 최적화하여 불필요한 CPU 낭비 없이 안정적으로 락을 관리

• 락이 만료되기 전에 자동으로 TTL을 연장하여, 장시간 작업에서도 안정적인 락 유지가 가능 ( Lettuce는 TTL이 지나면 락이 풀릴 수 있어 작업 중 충돌 위험이 존재 )

결론적으로, Lettuce보다 안정적인 분산 락이 필요했고, CPU 사용을 줄이면서 TTL 자동 연장과 다양한 락 기능을 활용하기 위해 Redisson을 선택하게 된것이다. 그럼 이제, RedLock을 이용할지, RLock을 이용해서 구현할지에 대한 고민이 생긴다.

RedLock, RLock ? 어떤 것을 이용할까

❌ RedLock이 과할 수 있는 경우 싱글 Redis 노드 환경이거나, 락을 걸어야 하는 트랜잭션이 짧다면 RedLock은 오버헤드가 될 수도 있다

• 단일 Redis 인스턴스 환경에서는 RedLock을 사용할 필요 없음
• 과반수 노드가 죽으면 락 획득이 불가능해질 수도 있음

현재 우리의 레디스 환경은 하나의 레디스 인스턴스에서 모든 데이터와 락을 관리하는 싱글 노드 형태이기 때문에 RedLock보다는 RLock을 선택하는 것이 낫다는 판단이 되었다.

📌 코드내에서 주목해야 할점

코드 내에서 주목해야 할 점을 난 2가지를 뽑았다.

1) RLock의 내부 코드 파헤치기 2) 트랜잭션 분리

1.🤔 RLock의 내부 코드 파헤치기

Redission을 이용한 분산락 코드는 사실 인터넷을 조금은 서칭하면 거의 비슷하게 나온다. 그런데 정작 내부의 RLock의 코드를 파헤친 기록은 없더이다. 퇴근하고 남는게 시간인데 놀면 뭐하나,, 내부 코드 뒤적거리면서 시간이나 보내야지 ⏳ 적용한 코드를 크게 보면 간단하다

락 객체 생성(열쇠 가져오기) → 락 걸기(열쇠로 잠그기) → 락 해제(열쇠로 잠금 풀기)

1) 락 객체 생성(열쇠 가져오기)

자.. 락 객체 생성부터 알아볼까? 처음 시작은 getLock부터 시작한다. 이 코드를 따라가다보면, 최종적으로 RedissonLock 클래스의 생성자로 연결된다. 첫번째 코드 줄을 통해, RedissonLock은 RedissonBaseLock을 상속받고, 기본적인 락 이름(name)과 명령 실행기(commandExecutor)가 초기화함을 알 수 있다. 명령 실행기(commandExecutor)라는 것은 🎁 비동기 Redis 명령어 실행기를 의미한다. 음 Redis에 직접 명령을 보내는 역할인거다. 예를 들어 tryLock()을 호출하면, 내부적으로 SET NX PX 명령이 Redis에 전송되는 것이다. 그래서 명령 실행기를 초기화한다는 것은 commandExecutor를 통해 Redis와 통신할 준비를 한다는 거라고 생각하면 된다.

internalLockLeaseTime는 자동 락 해제 시간 설정하는 것이다. 여기서 우리가 주목해야 할것은 🎁 락 워치독 (Watchdog) 기능이다. 쉽게 말하면, 자동 연장 기능이다.

📌 락 워치독(Watchdog)은 왜 필요할까? 보통 Redis에서 락을 설정할 때 TTL(만료 시간)을 지정하는데, 작업이 TTL 안에 끝나지 않으면 락이 자동으로 해제되는 문제가 있다.

예를 들어 TTL이 5초인데 작업이 6초걸린다고 치자. 5초 후 락이 만료되고 자동으로 해제되면? 다른 프로세스가 같은 락을 획득할 수 있다 → 데이터 일관성 깨짐 😨 그래서 락을 획득한 스레드가 살아 있는 동안 TTL이 자동으로 연장된다는 기능이다. TTL을 직접 설정하지 않으면 기본 30초 동안 유지된다고 한다.

마지막 줄인 pubSub은 🎁 Pub/Sub 기능을 활용하여 락 해제 이벤트를 감지하는 역할이다. Redis에서 분산 락을 사용할 때, 다른 클라이언트가 락을 대기하는 방식에는 2가지 방식이 있다.

• 폴링(Polling) 방식: 주기적으로 Redis를 조회해서 락이 해제되었는지 확인함.
• 이벤트 기반 방식: 락이 해제될 때 Redis가 직접 알림(Pub/Sub)을 보내서 대기 중인 클라이언트가 즉시 실행됨.

만약 폴링 방식이라면? 락을 얻으려는 클라이언트가 주기적으로 Redis에 요청을 보내 락이 해제되었는지 확인해야한다. 듣기만 해도, 불필요한 Redis 부하가 발생하고 클라이언트가 지속적으로 Redis에 요청을 보내므로 트래픽이 많아질 거라는 단점이 느껴지지? 그래서 Redisson에서는 락이 해제될 때 이벤트를 발생시켜 다른 클라이언트가 즉시 실행될 수 있도록 처리한다. 언제? RLock.unlock() 이 호출될때!

2) 락 걸기(열쇠로 잠그기) 이제 락을 어떻게 거는지 알아보자. 코드를 따라가다보면 Redission 클래스에서 tryLock()의 구현체를 확인할 수 있다. 코드에 대한 내용을 간단하게 정리하자면, 주어진 대기 시간(waitTime) 내에 락을 획득하려 시도하며, 락을 획득하면 지정된 임대 시간(leaseTime) 동안 락을 유지한다. 락을 즉시 획득하지 못한 경우, 다른 클라이언트의 락 해제 이벤트를 대기하기 위해 Pub/Sub 메커니즘을 활용하고, 대기 시간 내에 락을 획득하지 못하면 false를 반환하는 매커니즘을 확인할 수 있다.

3) 락 해제(열쇠로 잠금 풀기)

비동기적으로 락을 해제하는 모습을 볼 수 있다. unlock코드를 파보다보면, unlockInnerAsync메소드를 발견할 수 있다. 첫번째 박스인 락 해제시도 코드를 따라가다보면, 아래 사진에 나온 것처럼 레디스에 명령어를 보내는 코드를 확인할 수 있었다.

2.🤔 트랜잭션 분리

코드를 살펴보면 락을 걸고 나서 트랜잭션을 분리해서 비즈니스 로직을 실행하는 역할을 하는 것을 볼 수 있다.

음..쉽게 말하면 DistributedLock 어노테이션이 선언된 메서드를 별도의 트랜잭션으로 실행하게 만든 코드인 것이다.

Propagation.REQUIRES_NEW 옵션을 지정해 부모 트랜잭션의 유무에 관계없이 별도의 트랜잭션으로 동작하게끔 설정하고 반드시 트랜잭션 커밋 이후 락이 해제되게끔 처리하고 있다. 왜 이렇게 분리를 했을까? 해당 내용은 컬리의 블로그에 너무 자세히 써져있다. 내가 진행한 프로젝트도 재고를 위한 분산락인데 여기서도 재고를 예시로 들어서 너무나 적절하게 써져있으니 해당 링크 참고하길 바란다. 결론을 말하자면 데이터 정합성을 위한 방법으로 트랜잭션 커밋 이후 락이 해제되게끔 처리 해놓았다.

📌 추가된 요구사항

실전으로 넘어가기 전에, 추가할 요구사항이 있다. 앞선 요구사항은 하나의 key 즉, 하나의 row만 락을 거는 형식으로 구현되어 있다. 하지만 우리 회사 특성상 주문시 여러 상품을 동시에 상태 변경하기 때문에 한번에 여러 상품의 재고를 변경해야한다. 따라서 하나의 row가 아닌 여러 row에 락을 걸어야 한다.

그렇다면 기존에 받는 키도 하나에서 여러개를 받게 되고 락도 동시에 여러개를 건다는 말이겠지? 정리하자면, 여러 개의 락을 동시에 걸고, 하나라도 실패하면 전체 실패하도록 하고 싶다는 것이다. 이때 난 RedissonMultiLock이라는 것을 사용했다.

즉, 하나의 트랜잭션처럼 모든 락이 성공해야만 실행되도록 할때 사용된다. 그렇다는 말은 락을 해제할때도 한꺼번에 해제한다는 말과 동일하다.

이제 추가된 요구까지 알아보았으니 본격적으로 테스트를 해볼까? 해당 내용은 다음편에 있다.

참고)

• https://velog.io/@a01021039107/%EB%B6%84%EC%82%B0%EB%9D%BD%EC%9C%BC%EB%A1%9C-%ED%95%B4%EA%B2%B0%ED%95%98%EB%8A%94-%EB%8F%99%EC%8B%9C%EC%84%B1-%EB%AC%B8%EC%A0%9C%EC%9D%B4%EB%A1%A0%ED%8E%B8
• https://helloworld.kurly.com/blog/distributed-redisson-lock/
• https://techblog.woowahan.com/17416/
• https://velog.io/@jinony/Spring-Boot-Apache-JMeter%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EB%B6%80%ED%95%98-%ED%85%8C%EC%8A%A4%ED%8A%B8

등장 배경 - facebook의 상황

Facebook은 매일 수억 명의 사용자로부터 발생하는 막대한 읽기/쓰기 요청을 처리해야 한다. 이를 위해 대규모 데이터를 빠르게 처리하고 실시간으로 사용자 경험을 제공하는 것이 필수적이다. 기존의 데이터베이스 시스템만으로는 이러한 규모를 감당하기 어렵기 때문에, Memcached를 기반으로 한 분산 캐싱 시스템을 구축했다.

• 초당 수십억 요청을 처리해야 하는 대규모 소셜 네트워크 인프라.
• 데이터베이스 부하 증가로 인해 응답 시간 지연 발생.
• 전 세계 사용자에게 실시간 데이터 제공 필요.

memcache

메모리 내 데이터를 빠르게 저장하고 읽는데 사용되는 해시 테이블 기반 시스템

facebook에서 memcache란?

• 인메모리 캐싱 솔루션 → 읽기/쓰기 요청 경감 및 데어터 접근 속도 향상
• 분산 키-값 저장소

facebook에서의 memcache 아키텍처

Facebook은 Memcached를 단순히 한 대의 서버에서 사용하는 것이 아니라, 여러 서버로 확장하여 클러스터화했다. 데이터는 일관된 해싱 기법을 통해 여러 Memcached 서버에 분산 저장되며, 클라이언트는 Memcached를 먼저 조회한 후 캐시 미스일 경우 데이터베이스에서 데이터를 가져오도록 설계되었다.

• 기본 구조 1) master- slave 구조 2) 일관된 해싱을 통해 키 분산 3) 모든 웹서버는 짧은 시간 내에 모든 memcache 서버와 통신 (all to all 통신 패턴→ 병목 현상, incast congestion의 원인)

• 읽기 및 쓰기 경로

- **읽기**: Memcache 조회 → 캐시 미스 시 데이터베이스 접근.
- **쓰기**: 데이터베이스 업데이트 후 Memcache 캐시 삭제(무효화).

주요 기술 및 최적화

📌 병렬 요청 및 일괄 처리

Facebook의 Memcache 클라이언트가 네트워크 효율성을 극대화하고 요청 지연 시간을 최소화하기 위해 구현한 전략

1. 병렬 요청

   문제

   • Facebook의 한 사용자 요청(예: 피드 로드)은 Memcache에서 수백 개의 키를 요청하는 작업으로 이루어질 수 있다. (한 요청 = 여러 memcache 조회)

   • 이러한 요청을 하나씩 순차적으로 처리하면 네트워크 왕복(Round-Trip Time, RTT)이 증가하여 응답 시간이 길어진다.

   • 해결 방법*

   • 요청 간의 의존 관계를 분석하여 병렬로 처리 가능한 요청을 동시에 실행.

   • 의존 관계를 DAG(Directed Acyclic Graph, 방향 비순환 그래프)로 나타내어 요청을 설계:

     • 예: 요청 A가 요청 B에 의존하지 않는다면 두 요청을 병렬로 실행 가능.
     • 요청 B가 요청 A의 결과를 필요로 한다면, A를 완료한 후에 B를 실행.
     • DAG 구조
       • DAG(Directed Acyclic Graph) : 방향성 비순환 그래프
       • 데이터 또는 작업의 의존 관계를 나타내는 데 사용
       • Facebook의 Memcache 클라이언트가 요청을 병렬 처리하는 데 중요한 역할

💡 예시

• Facebook 뉴스피드 로드 시:

     1) 게시물 데이터를 가져오기 위한 요청(A).

  2) 각 게시물의 댓글 데이터를 가져오는 요청(B, C, D). 3) 댓글 좋아요 수 데이터를 가져오는 요청(E, F).

  이처럼 요청 간 **의존 관계**가 있을 경우, 순차적으로 처리하면 성능이 저하

• DAG 구조의 적용 : 의존 관계를 DAG로 표현하여 병렬로 실행 가능한 요청을 구분

            - A → (B, C, D) → (E, F).
            - 요청 A가 완료된 후, 요청 B, C, D를 병렬로 실행.
            - B, C, D가 완료되면, 요청 E와 F를 병렬로 실행.

• 결과
  • 요청의 네트워크 왕복 횟수를 최소화하여 응답 시간을 단축.
  • 많은 사용자 요청을 빠르게 처리할 수 있는 병렬 처리가 가능해짐.

2. 요청 일괄 처리

   문제:

   • Memcache는 단일 요청마다 네트워크 비용이 발생하므로, 많은 키를 개별 요청으로 보낼 경우 네트워크와 서버 부하가 증가한다

   • 해결 방법:*

   • 여러 키를 한 번의 요청으로 묶어서 일괄 처리(Batch) 형태로 서버에 전송.

     • 예: 24개의 키를 요청해야 할 경우, 24번의 개별 요청 대신 한 번의 요청으로 묶어서 처리.

   • 클라이언트는 병렬로 묶인 요청 배치를 Memcache 서버에 보냄으로써 네트워크 부하를 줄임.

   • 결과:*

   • 평균적으로 한 번의 요청에 24개의 키를 포함.

   • 서버와 클라이언트 간 네트워크 왕복(RTT)이 감소.

   • 네트워크 패킷 수를 줄여 네트워크 대역폭을 절약.

💡 사례 예시 사용자가 Facebook 뉴스피드 로드 요청 시

1. 병렬 처리:
   • 뉴스피드의 각 게시물, 댓글, 좋아요 데이터를 독립적으로 병렬 요청.
2. 일괄 처리:
   • 게시물 100개에 대한 데이터를 한 번의 요청으로 Memcache에서 가져옴.

📌 클라이언트-서버 통신의 최적화 방식

배경

• Facebook의 Memcache 시스템에서 웹 서버(클라이언트)는 Memcache 서버에 자주 요청을 보낸다.
• 이때 클라이언트와 서버 간의 통신은 효율적이어야 하고, 지연 시간을 최소화해야 한다.
• 초기 설계에서는 서버 간 통신이 필요하지 않았지만, 클라이언트와 서버 간의 통신에서 최적화가 필요했기 때문에 다양한 방법이 도입됨

방식

• Memcache는 서버 간의 직접적인 통신을 하지 않는다
  • Memcache 서버들은 서로 상호작용하지 않고, 각 클라이언트(웹 서버)가 여러 Memcache 서버에 직접 접근
  • 모든 복잡한 로직(예: 요청 라우팅, 오류 처리 등)은 클라이언트(웹 서버)에서 처리
• 상태 없는(stateless) 시스템
• 클라이언트(웹 서버)는 요청을 여러 Memcache 서버로 보낼 때, 여러 작업을 동시에 할 수 있도록 복잡한 로직을 처리
• UDP와 TCP를 사용하여 통신 → 네트워크 대역폭 최적화
  • UDP : 읽기 요청 - 연결을 설정하지 않고 빠르게 데이터를 전송할 수 있기 때문에
  • TCP : 쓰기 요청 - 데이터 일관성을 보장해야 하기 때문에 신뢰성 있는 전송이 필요
• incast congestion을 방지하기 위한 흐름 제어(flow control)가 적용
  • incast congestion : 여러 클라이언트가 동시에 많은 요청을 서버에 보내면서 네트워크가 과부하되는 현상
  • 슬라이딩 윈도우 방식을 사용하여 동시에 보낼 수 있는 요청 수를 제한

📌 부하 감소를 위한 방법

Memcache 시스템을 사용하여 서버의 부하를 어떻게 줄일까?

Memcache 시스템은 읽기 요청이 매우 많고, 캐시 미스(캐시에서 찾지 못한 데이터를 데이터베이스에서 다시 가져오는 작업)가 발생할 때마다 데이터베이스 부하가 증가

1. Leases (리스)

   stale sets와 Thundering herds를 해결하기 위한 메커니즘

   • stale sets: 캐시된 값이 최신 상태가 아니어서 데이터가 불일치할 때 발생하는 문제.
   • Thundering herds: 특정 키가 자주 읽고 쓰여서 여러 클라이언트가 동시에 캐시를 갱신하려고 시도하는 상황에서 발생하는 문제.
   • Leases 메커니즘:
     • Memcache 인스턴스는 클라이언트에게 Leases 토큰(64비트 값)을 부여.
       • 클라이언트가 캐시 누락을 경험할 때 데이터를 캐시에 다시 설정하기 위함
       • 토큰 : 클라이언트가 원래 요청한 특정 키에 바인딩된 값
     • 리스가 유효할 때만 클라이언트가 Memcache에 데이터를 다시 쓸 수 있다.
     • 리스를 통해 동시 데이터 업데이트로 인한 불일치를 방지하고, 여러 클라이언트가 같은 데이터를 동시에 수정하는 문제를 해결
   • 결과:
     • 캐시 세트가 발생하는 것을 방지하여 데이터 일관성 유지.
     • 스램 문제를 해결해 데이터베이스 부하를 감소시킴.

💡 예시 Facebook에서 사용자가 피드를 로드할 때, 각 게시물의 좋아요 수를 Memcache에서 캐시하고 있다. 여러 사용자가 동일한 게시물을 동시에 좋아요를 눌렀다면, 좋아요 수를 업데이트하려는 여러 요청이 동시에 들어오게 될 수 있다.

• 리스가 없는 경우 (문제 발생):

1. 사용자 A와 사용자 B가 동시에 같은 게시물에 대해 좋아요를 누른다.
   2. 두 사용자가 Memcache에서 캐시된 좋아요 수를 조회하고, 캐시 미스가 발생하여 데이터베이스에서 값을 가져온다.
2. 데이터베이스에서 가져온 값은 기존 값이고, 두 사용자가 동시에 좋아요 수를 증가시킨다.
3. 두 사용자가 각각 Memcache에 업데이트를 하게 되면, 최신 상태의 데이터가 아니므로 일관성이 깨지게 된다.

• 리스 적용 후 (문제 해결)

1. 사용자 A가 첫 번째로 Memcache에서 캐시된 좋아요 수를 조회.
2. Memcache는 좋아요 수를 새로 갱신할 수 있는 리스 토큰을 사용자 A에게 할당.
3. 사용자 A는 해당 데이터를 갱신하고, 리스 토큰을 이용해 Memcache에 값을 설정.
4. 사용자 B가 동일한 게시물의 좋아요 수를 조회할 때, 이미 리스 토큰이 만료되지 않은 사용자 A에게만 데이터 갱신 권한이 있기 때문에, 사용자 B는 데이터를 다시 가져와 갱신을 시도할 수 없다.
5. 사용자 B는 새로운 리스 토큰을 요청하고, 사용자 A의 갱신 작업이 완료되면 데이터베이스에서 최신 값을 가져와 업데이트.

• 결과 리스 메커니즘 덕분에 사용자 A만 해당 데이터를 갱신할 수 있으며, 사용자 B는 갱신 권한을 얻기 전까지 기다린다. 이를 통해 데이터 일관성을 유지하고, 스램 문제를 해결하며, 데이터베이스 부하도 줄인다.

2. Memcache Pools

Memcache 서버는 여러 워크로드(작업 부하)를 처리할 수 있지만, 서로 다른 데이터 접근 패턴과 메모리 사용량을 가진 워크로드가 한 풀 안에서 상호작용하면 성능이 저하될 수 있다.

• 예를 들어, 자주 변경되는 데이터와 드물게 접근되는 데이터가 같은 Memcache 풀에 있으면, 자주 변경되는 데이터로 인해 드물게 접근되는 데이터가 메모리에서 지워질 수 있다.
• Memcache 풀:
  • Memcache 서버를 여러 개의 별도 풀로 나누어 사용
    • wildcard pool: 일반적인 캐시 데이터를 저장. 자주 업데이트되지 않는 데이터
    • app-specific pool: 자주 변하는 데이터를 저장.
    • replicated pool: 읽기 요청이 많은 데이터를 저장.
    • regional pool: 지역적 특성이 있는 데이터를 저장.
• 결과:
  • 서로 다른 데이터를 분리하여 풀에 저장함으로써, 각 데이터 유형에 맞는 최적화된 메모리 관리와 성능 향상을 이끌어낼 수 있다
  • 서로 다른 데이터 유형이 메모리 풀 간섭 없이 저장되므로, 성능이 향상되고 효율적인 메모리 사용이 가능

3. Replication 특정 키가 자주 요청되는 경우, 여러 Memcache 서버에 복제본을 만들어 데이터 접근 시간을 단축시키는 기법

• 복제된 데이터를 여러 Memcache 서버에 분산 저장하여, 읽기 요청이 한 서버에 몰리는 것을 방지.
• 데이터베이스 요청이 많아지는 시점에 복제를 통해 다중 서버에서 동시에 데이터 제공이 가능

📌 글로벌 확장

Memcache 시스템이 글로벌 사용자에게 안정적이고 빠른 서비스를 제공하였나

1. 지역 기반 설계:

• facebook은 글로벌 사용자에게 빠르고 일관된 응답을 제공하기 위해, Memcache를 지역별로 분산하여 배치
• 지역 단위로 캐시 데이터를 관리하고, 서버 간의 데이터 전파 시간을 줄여 응답 시간을 최적화
• 각 지역별 클러스터:
  • Facebook은 지역별 클러스터를 구성하여, 서버들이 같은 지역 내에서만 통신하도록 설계.
  • 예를 들어, 북미, 유럽, 아시아 등 각 대륙별로 독립적인 Memcache 클러스터를 운영.
  • 각 지역에 서버를 배치하여, 사용자 요청이 발생할 때 가장 가까운 서버에서 데이터를 처리하도록 하여 응답 시간을 최소화.
• 글로벌 서버 분산:
  • 데이터는 여러 서버에 복제되어 저장. 각 지역에 복제된 데이터를 두어, 한 지역에서 장애가 발생하더라도 다른 지역에서 백업 데이터를 빠르게 사용할 수 있게 된다.

2. 클러스터 분할 (Sharding) : 효율적인 확장

샤딩은 Memcache 서버를 여러 개의 작은 서브 클러스터로 나누는 방식으로, 각 클러스터가 데이터의 일부분만 담당하도록 한다.

1. 데이터 일관성 (Data Consistency) : 다양한 지역에 배포된 서버들이 동일한 데이터를 제공.

• 캐시 일관성 유지

  • Facebook은 일관성 있는 데이터를 보장하기 위해 원격 캐시 및 데이터 동기화 전략을 사용.
    • 각 서버가 다른 지역에 있는 서버들과 주기적으로 데이터를 동기화하여, 최신 데이터를 여러 지역에서 동일하게 제공.
    • 데이터베이스에서 변경된 사항은 캐시에서 무효화된 후, 새로 갱신된 데이터를 다시 캐시로 가져오는 방식으로 일관성을 유지.

  • 데이터 전파 및 복제

    • 데이터베이스의 변경 사항은 복제된 Memcache 서버에 자동으로 전파.
    • 동기 복제 또는 비동기 복제 방식을 사용하여 각 지역 서버에 실시간 데이터 동기화를 구현.

📌 단일 서버 개선 사항

• 멀티스레드 구현

• Adaptive Slab Allocator 적용 Memcache 서버에서 메모리를 고정 크기 블록으로 할당할 경우, 메모리 낭비가 발생할 수 있음. 특히 작은 크기의 데이터나 자주 변하는 데이터에 대해서는 비효율적인 메모리 사용이 문제이다.

  • 메모리 할당을 동적으로 최적화
  • 작은 데이터는 작은 크기의 슬랩을 사용하고, 큰 데이터는 더 큰 슬랩을 할당하여 메모리 사용 효율을 높임

• LRU(Least Recently Used) 캐시 정책 개선 Memcache는 기본적으로 LRU(Least Recently Used) 정책을 사용하여 오래된 데이터를 삭제하고 새로운 데이터를 저장하는 방식으로 동작 → 데이터 삭제가 발생할 때 불필요한 연산이 발생 LRU 알고리즘을 개선하여 캐시의 유효성을 최적화하고, 불필요한 삭제를 최소화

• 비동기 요청 처리 도입

• 네트워크 지연 시간 감소

• 메모리 효율성 향상

그래서 Redis랑 어떤차이가 있는 건데? 🤔

데이터 구조

• Redis: 다양한 데이터 구조를 지원.

  • 문자열 (String)
  • 리스트 (List)
  • 집합 (Set)
  • 정렬된 집합 (Sorted Set)
  • 해시 (Hash)
  • 비트맵, 하이퍼로그로그 등 고급 자료 구조

• 이를 통해 복잡한 데이터 연산을 인메모리에서 처리할 수 있다.

• Memcached: 단순히 key-value 쌍의 데이터를 문자열 또는 바이너리 형태로 저장.

• 구조가 간단하여 캐싱 이외의 복잡한 작업에는 부적합.

영속성 (Persistence)

• Redis:데이터 영속성을 지원.

  • RDB (주기적으로 데이터 덤프)
  • AOF (명령 로그 기록)

• 캐시로뿐만 아니라 데이터베이스로도 활용 가능.

• Memcached:영속성을 지원하지 않는다.

• 메모리가 날아가면 데이터도 손실.

클러스터링 (Clustering)

• Redis:Redis 클러스터를 통해 샤딩과 복제를 지원.

• 확장성이 높으며, 고가용성을 위한 설정이 가능합니다.

• Memcached: 클러스터링을 자체적으로 지원하지 않는다.

• 클라이언트 라이브러리를 사용해 샤딩 구현.

성능

• Redis: 다양한 데이터 구조와 기능으로 인해 특정 상황에서 오버헤드가 발생할 수 있습니다. 하지만 대부분의 경우 성능은 매우 뛰어나다.

• Memcached: 단순한 구조 덕분에 읽기/쓰기 성능이 매우 빠르다.

• 단순 캐싱 용도라면 Redis보다 약간 더 나은 성능을 보일 수 있다.

사례

• Redis: 세션 관리, 실시간 분석 (e.g., 순위, 카운터), 메시지 큐, Pub/Sub 시스템, 복잡한 데이터 구조 캐싱
• Memcached:단순 데이터 캐싱, 웹 페이지 렌더링 속도 개선,자주 변경되지 않는 데이터 저장

메모리 관리

• Redis:

  • LRU(Least Recently Used) 정책으로 메모리 관리.
  • 사용자가 메모리 사용량을 세부적으로 제어 가능.

• Memcached: 메모리 블록 단위로 데이터를 저장하며, 메모리 초과 시 오래된 데이터를 자동 삭제.

정리하자면, Redis는 다양한 데이터 구조와 영속성을 지원하며, 데이터베이스나 메시지 브로커 등으로도 활용 가능. 복잡한 작업에 적합하다. Memcached는 단순한 데이터 캐싱에 특화되어 있으며, 빠르고 가볍다

논문 링크 : https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf

도대체 왜 만들었지? 🤔

사실 프로그래밍 공부를 하면서 점점 중요하다가 느끼는 것 중 하나가 '호기심을 잃지 않는 것이다' 처음에 공부를 시작할때는 모든 것이 새로웠고 신기했기에 어디에나 호기심이 가득한 상태로 공부해왔다. 그러나, 시간이 지나고 직장 생활을 하다보니 기존에 존재를 알고 있던 것을 정말 깊숙히 알고 있는 것으로 착각하고, 어렵고 신기한것만 탐구하려는 성향이 강해짐을 느껴진다. 이번에 float과 double에 대해 공부하면서 이런 기초적인 것에도 많은 것이 담겨있는데 난 이제까지 알고 있다고 착각하고 있었구나 라는 것을 느낀다.

자, 본격적으로 이제 내가 공부한 내용을 차근차근 읊어볼까~?

Float과 Double 차이점에 대해 알고 있어?

float과 double은 모두 숫자를 저장하기 위한 기본 자료형이다. float은 32비트의 저장소로 소수점 이하 약 7자리의 정확도를 가지고 있고, double은 64비트의 저장소로 소수점 이하 약 15자리의 정확도를 가진다.

여기서 우리가 주목해야 할 점은

• 정확도에 차이가 있다.

• double이 float보다 정확도가 높구나?

• 메모리에 차이가 있다

• float이 double의 절반의 메모리를 사용한다. 따라서 메모리 효율성이 float이 더 높다. 그럼 double보다 더 많은 데이터를 다룰 수 있다는 것이고 연산속도도 더 빠르겠네~!

• 부동소수점을 위한 기본 자료형이 float과 double이다.

부동소수점?

• 실수를 표현하는 방식 중 하나
• 숫자를 지수와 가수로 나누어 저장하여 소수점의 위치가 자유롭게 변할 수 있는 방식

"부동"은 "떠다니다" 라는 의미로, 소수점의 위치가 고정되어 있지 않고 숫자의 크기에 따라 위치가 변할 수 있음을 나타낸다.그래서 부동소수점은 매우 큰 수나 작은 수를 지수의 크기에 따라 동적으로 표현 할 수 있다. 즉, 넓은 수자 범위를 효율적으로 표현할 수 있다는 것

-> 모든 실수를 정확하게 표현 할 수 없다

부동소수점의 한계 예시

난 이거 알아볼때 사실 감동이었다.ㅎㅎ

1) 0.1 ( 아, 이건 번외인데 +라는 기호는 쓰지말자..ㅎ)

단순히 작동하면 출력 결과가 0.1로 나온다. 그럼 정확한거잖아?? 라고 생각할 수 있다. 하지만 이는 반올림의 결과이다 실제로 내부의 값을 bigDecimal을 이용해 확인해보면

결과는? 두둥

정확히 0.1이 아님을 알 수 있다.

2) 0.2와 0.1의 덧셈 부동소수점의 정밀도로 인해 기대값이 0.3이 아닐 수 있다.

의 결과는?

정확히 0.3이 안나오는데 정확성이 중요한 곳에서는 어떻게 부동소수점을 쓰겠는가?

그럼 정확성이 중요할 때는 뭘 사용해야하지? BigDecimal을 사용해야한다.

BigDecimal

위의 덧셈 연산을 그대로 bigDecimal을 적용해보자면

의 결과는 으로 정확한 숫자가 나오는 것을 확인할 수 있다. 그래서 정확도가 필요한 상황이라면 BigDecimal을 사용해야한다. 하지만 단점도 존재한다.

• 연산 속도가 float, double보다 느리다.
• 메모리 사용량이 높다
• 성능 저하

BigDecimal은 참조형이다. 즉 매번 덧셈, 곱셈, 나눗셈과 같은 기본 연산에서도 객체를 생성해야한다. 객체를 새로 생성한다는 말은 즉, 메모리를 추가로 사용한다는 말이다. 이는 곧 숫자의 크기가 커질 수록 더많은 연산 자원을 소모해서 성능 저하를 발생시킬 가능성이 있다는 말이다.

선택 정리

• 느리지만 높은 정확도가 필요하다면? BigDecimal
• 높은 정밀도는 필요하지 않지만 많은 소수점 연산을 빠르게 처리해야하거나 메모리 효율이 중요한 경우? float
• float보다는 정밀도가 높고 성능 저하가 없으며 메모리에 대한 여유가 있으면? Double

오라클 문서에는 "메인 메서드는 반드시 public, static, void로 선언하고, 그 매개변수는 String 배열 타입으로 선언해야 합니다." 라고 써져있다.

아래 내용을 진행하기전에 우리가 알아야할 배경 지식을 알려주겠다.

• 자바프로그램은 JVM이라고 불리는 자바 가상 머신을 통해 실행된다.
• 프로그램을 작동시키기 위해 JVM이 처음으로 부르는 시작점은 main 메소드이다. 시작점에 대한 의문은 갖지 마라. 떡하니 entry point라고 써져있다. 자바 프로그램의 진입점으로 예약된 메소드 이름이다.

참고)

• 오라클 jls-12.1.4
• Java Tutorials

왜 메인 메소드는 static이라고 선언이 되어 있어야 하는가?

프로그램을 작동시키기 위해 JVM이 처음으로 부르는 시작점은 main 메소드이기 때문에 main 메소드를 부를 때 JVM은 정말 아무것도 없는 빈털털이로 객체 생성이 아무것도 없는 상태에서 호출하고 있고 객체 생성을 하지도 못하고 있다. 결론부터 말하자면, 객체 생성 없이 프로그램을 실행할 수 있어야 하기 때문에, 클래스 레벨에서 이름만으로 직접 호출 가능한 메소드로 static으로 선언 되어야 한다.

객체 생성?

객체가 무엇인데? 객체 생성은 어디에서 이루어지는데? 우선 근본적인 것부터 해결해보자.

위의 나온바와 같이, 제임스 고슬링이 작성한 자바 언어 설명서 (The java Language Specification)에는 객체(object)란 클래스의 인스턴스나 배열을 말한다고 정의되어 있다. 우리가 코드상에서 객체를 만든다고 한다면 흔히 new 선언을 통해 생성해준다.

new로 선언한다고 하니 참조자료형이 생각나지 않나?ㅎㅎ 즉, 객체는 힙메모리에 저장된다.아래 자료에서도 힙에 할당된다고 써져있다.

클래스에서 객체를 만들기 때문에 클래스가 로드 된 후에야 객체 생성을 시작할 수 있다.

JVM이 자바 프로그램을 실행 하기까지의 진행 과정은?

📌 1. 클래스 로드 및 메소드 영역 할당, 정적 초기화

자바 애플리케이션이 시작되면 JVM은 클래스 파일을 로드하고, 메소드 영역(Method Area)에 클래스의 static 필드와 메소드등의 클래스 정보를 저장한다. 그리고 정적 초기화가 진행된다 (초기화 과정에서 필요한 값들이 메소드 영역에 저장된다) 이 시점에 인스턴스 생성은 발생하지 않기에 힙 메모리나 스택 메모리는 사용되지 않는다.

📌 2. JVM이 main 메소드 호출

JVM이 프로그램 시작점으로 main 메소드를 찾는다. main 메소드는 static으로 선언되어 있기 때문에 인스턴스가 없어도(객체 생성없이도) JVM이 main 클래스를 메모리에 로드하고 호출할 수 있다.

📌 3. 메인 메소드 실행

main 메소드가 호출되면, 클래스가 메로리에 로드 되었기 때문에 그 안에서 이제 객체 생성이 시작된다. 이제 힙과 스택 메모리가 사용되기 시작하는 것이다. 프로그램이 본격적으로 실행된다.

이를 통해 우리가 알 수 있는 점을 정리하자면, 객체 생성 및 할당을 힙메모리에서 하지만, main 메소드를 호출하기 전에는 JVM이 주로 메소드 영역에만 접근하여 프로그램을 준비하기 때문에 main 메소드 호출전에는 객체 생성을 못한다는 말이며, static으로 메인 메소드를 선언을 해야 객체 생성 없이 클래스 자체에서 main 메소드를 호출할 수 있다는 것을 알 수 있다.

참고) 오라클 문서

💡 '컴파일이 뭔지 설명할 수 있어?'

오늘은 여러가지 내용 중에 컴파일에 관련된 것에 한번 알아보려고 한다.

컴파일은 뭐야?

우선 책의 내용을 정리하자면, compile이라는 단어는 "엮다"라는 말이다. 즉, 내가 만든 프로그램 코드를 컴퓨터가 이해할 수 있도록 엮어주는 작업이 컴파일이라고 한다. 그래서 컴파일러는 번역기라고 생각하면 된다. 우리랑 컴퓨터랑 언어가 다르니까~

책에서는 딱 이렇게 만 보여줬다 간단하게..ㅎ 궁금하면 나보고 더 파보라는 이야기인가? 이 그림에는 정말 많은 것이 생략되어 있다. 양파같은 녀석..ㅋㅋ

하이브리드 언어

첫번째로 까볼 양파는..🧅 사진에서도 그렇고 책에서도 그렇고 컴파일러만 등장하지만 사실 '인터프리터'도 존재한다. 자바는 대표적인 하이브리드 언어이다. 컴파일러와 인터프리터에 대해 간단히 정리하자면,

컴파일러

• 전체 파일을 통으로 번역한다. ( 전체적으로 한번만 디코딩해서 실행한다)
• 한꺼번에 번역하고 저장해야하니 저장공간(메모리)가 많이 필요로 한다.
• 실행시간 측면에서 인터프리터보다 실행속도가 엄청 빠르다.(초기 스캔 시간은 오래 걸린다.)
• 스캔하는 과정에서 모든 오류를 한꺼번에 출력해서 실행 전에 오류를 알 수 있다.

인터프리터

• 한 줄 단위로 번역하기 때문에 실행속도가 드리다.한 줄마다 디코딩해야한다.
• 한 줄씩만 번역하고 저장하니 메모리를 덜 소비한다.
• 한 줄씩 실행하기 때문에 오류를 만나면 그제서야 프로그램 중지한다. 프로그램을 실행해봐야지만 오류 발견한다.

그대는 실행속도를 선택할 것인가.. 메모리를 선택할 것인가..

자바는 왜 하이브리드 방식을 선택하였는가?

진행 과정

책의 사진을 내 나름대로 다시 꾸며서 진행과정을 그려보자면 아래 그림으로 된다.

보다시피 바이트 코드 전까지는 컴파일방식이고 그 뒤에는 JIT 컴파일러와 인터프리터가 공존하는 하이브리드 방식이다.

우선적으로 왜 앞부분은 컴파일 방식일까?

Write Once, Run Anywhere

자바의 철학을 엿볼 수 있는 구절이다. "한번 작성하면 어디서든 실행 가능하다" 이를 실현하기 위해 바이트 코드가 필요하고 바이트 코드는 주로 컴파일러가 필요하다.

• 바이트 코드 : 플랫폼에 독립적인 중간코드로 JVM에서 실행될 수 있도록 변환된 형태이다. 어느 운영체제에서나 실행가능하다.

그럼 컴파일 방식을 쭉 쓰지.. 왜 인터프리터를 왜 써?

다른 언어는 바로 실행하는 것에 비해, 앞에서 설명한 것과 같이 자바는 JVM이 알아들을 수 있는 언어로 바꾸는 작업이 추가로 필요하기 때문에 다른 언어에 비해 출발선이 다르다. 자바 실행했는데 한참 지나도 세월아 하면서 서버가 안뜨면 누가 자바를 쓰겠나?..ㅎㅎ 이때 필요한것은 속도! 컴파일러는 전체를 다 읽어야 하기 때문에 초기 시작 시간이 느린데 인터프리터는 한 줄씩 읽고 즉시 실행하기에 프로그램을 빨리 시작할 수 있다.

이때 우리가 겪을 수 있는 것은 성능문제가 발생한다. JVM이 바이트 코드를 한 줄씩 해석하여 그때그때 실행하게 되는데, 매번 바이트코드를 읽고 해석하는 과정이 반복되니 자주 실행되는 코드일 수록 오버헤드가 커지게 되는 것이다. 빨리 시작하면 뭐해 점점 느려져.. 이런 소리를 들을 것인가?

JIT 컴파일러 등장!

Wikipedia - Just-in-time compilation In computing, just-in-time (JIT) compilation (also dynamic translation or run-time compilations) is a way of executing computer code that involves compilation during execution of a program (at run time) rather than before execution.

그래서 등장한것이 JIT 컴파일러이다. 자주 사용되는 코드(핫스팟)을 감지해서 네이티브 코드로 컴파일 한다.

• 네이티브 코드 : 기계어로 CPU가 바로 실행할 수 있기 때문에 바로 실행된다. 바이트 코드처럼 추가적인 해석 과정이 필요없다.

자주 실행되는 코드, 반복되는 코드, 자주 호출되즌 함수를 네이티브 코드로 변환함으로써 더이상 해석없이 빠르게 실행 할 수 있어 추가적으로 속도와 성능이 향상되는 것이다.

정리하자면

• JVM에서 초기 실행은 주로 인터프리터 방식을 사용하여 실행 시작을 빠르게 하고,
• 프로그램이 진행됨에 따라 자주 실행되는 코드에 대해 필요한 부분만 JIT 컴파일러가 개입하여 실행 중에 발생하는 성능 병목을 해결하고 빠른 응답성을 유지하는 것이다.
• 또한, 자주 사용되지 않는 코드는 굳이 네이티브 코드로 변환하지 않기 때문에 메모리와 CPU 자원을 더 효율적으로 사용할 수 있는 것이다

회고

처음에는 컴파일에 대해서만 쓸려고 했는데 타고타고 가다보니 결론적으로 Execution engine의 일부를 설명하는 글이 되어 버렸다 ㅎㅎ 시간 순삭이다. 재밋긴 했다. 맨날 컴파일 컴파일 해도 그냥 넘겼는데 드디어 양심상 컴파일이라는 단어 앞에 안 작아져도 될 것 같다.

이 글을 쓰면서 벌써 다음 글감이 나왔다. 클래스 로더 ㅋㅋㅋㅋ 야호~

참고

• [컴파일러 강의] (http://www.kocw.net/home/cview.do?cid=483c036ed189cda6)
• https://en.wikipedia.org/wiki/Java
• https://kangmoo.github.io/posts/Compile-vs-Interpret-vs-Hybrid/
• https://junhyunny.github.io/information/java/jvm-execution-engine/
• https://medium.com/@amitvsolutions/jvm-part-2-architecture-1bf3044a9378

A. 레디스를 왜 썼어요? 라고 누군가 물어본다면 뭐라고 답해야 할까 Q. 디비로 가는 비용이 큰데 굳이 디비로 가지 않아도 되는 데이터인 캐시를 담아둘 저장소가 필요했어요. 그리고 빠른 응답으로 속도가 엄청 빨라요

내가 그동안 레디스에 대한 아는 것을 여기까지다..ㅎ 그럼 어떤 사실을 알고 어떤 것을 모르는지 간단히 1장에서 이야기 하고 있는 레디스의 특징을 통해 기록하고자 한다.

왜 빨라?

우리가 일반적으로 알고 있는 MySQL이나 오라클과 같은 RDBMS와 같은 디스크 기반으로 처리하는 데이터베이스 엔진이라도 디스크에 입출력할 필요없이 메모리에서 처리하는 경우가 있다고 한다(오,,몰랐는데?🤔) 레디스는 버퍼 관리 등에 따른 오버헤드를 제거하고 기능을 최소화하는 방식을 통해 빠르게 동작한다고 한다. 아직 초반이라 간단하게 이야기하고 있는데 레디스가 어떤 매커니즘으로 동작하는 지 파악하고 어떤 방식을 사용하여 왜 빠른지에 대한 결론을 짓는 일이 이 책의 읽는데 목표가 될 것 같다.

싱글 스레드 기반이래!

아 난 정말 레디스를 그냥 써왔음을 알게되는 순간이었다. 레디스를 검색만 해도 알게되는 내용인데 이제 알게되다니 ㅠ 싱글 스레드지만 이벤트 루프를 형성하여 많은 요청을 처리할 수 있다고 한다. 또한 부분적으로 멀티스레드로 데이터 접근부분만 싱글 스레드고 옵션을 통해 I/O 부분은 멀티 스레드 처리를 활성화 할 수 있다고 한다. 기본적으로 싱글 스레드이고 필요시 멀티스레드 기능을 사용하는 것 같다.

자료형이 다양하다

그동안 난 레디스를 캐시로만 사용해왔기 때문에 String만 알고 있었는데 이밖에 정말 다양한 자료형이 있음을 확인했다. 각 자료형마다의 명령어도 다르다고 한다. String, list, hash, set, sored set이 있다고 하는데 다음 장에서 알 수 있을 것 같다.

캐시용 말고도 용도가 많아!

배치 처리 메시지 큐, Pub/Sub 시스템 구축(클라이언트/서버 모델 기반의 요청/응답 통신)에도 쓰인다고 한다.

트랜잭션 처리

레디스는 RDBMS에 있는 트랜잭션 실패 시 롤백 기능은 지원하지 않는다. 명령어를 실패하더라도 그대로 나머지 처리를 계속해서 수행하는 패턴이다.

데이터의 영속성을 갖추고 있어?

나는 레디스의 데이터 영속성에 대해 전혀 알고 있지 않았다. 책에서는 레디스가 두가지 종류의 영속성을 제공한다고 한다.

• RDB(Redis Database) 특정 시점의 레디스 데이터(스냅샷)를 나타내는 여러개의 데이터 파일을 생성하는 방식(백업)
• AOF(Append Only File) AOF로 appendFsync의 값을 always로 설정함으로써 영속성을 보장할 수 있다. 쓰기 작업마다 디스크에 플러시 한다.

AOF 내용에 대한 관련 논문이 있다. Redis에서 AOF Rewrite 기법의 오버헤드 분석 해당 논문에 대한 내용은 추후 따로 작성해볼 예정이다.

읽어도 읽어도 모르는 개념이 너무 많고 이해가 않가는게 너무 많아서 내 부족함에 대한 자괴감이 드는데 나 이대로 괜찮을까? 이런 책을 읽을 만한 위치가 되는가?

이런 생각 속에서도 그 날도 습관적으로 그냥 책을 읽었고, 모르면 모른대로 넘겼고, 스터디에 참가하였다. 책걸이를 하던 날이던가..? 거의 책을 다 읽어나가고 다음 어떤 스터디를 할 것인가에 대한 이야기를 나누던 중 다음 것도 어려운 것을 하게 되면서 다른 스터디원이 하던 말이 내 부족함에 자괴감에 대한 해답을 주었다.

어려울 걸 알고, 나도 여기서 나온 개념들이 현재 실무에 쓰이는가?에 대한 생각을 많이 한다. 실제로 지금 전혀 쓰지 않아 잘 와닿지 않을 때가 많다. 하지만 나는 이것들이 배경 지식이라고 생각한다. 지금은 익숙하지 않아서 그냥 넘어가지만, 다음에 언젠가 문제 해결을 위한 방법을 찾아갈 때 '어? 이런거 있었지 않았나?' 하는 그 순간을 위해 어렵지만 읽어나가야한다고 생각한다.

맞아. 그 순간을 위해 내가 이렇게 해왔지?

덕분에 이로써 부족함에 대한 자괴감에 대한 해결을 되었다. 그리고 다시 일어설 수 있었다. 그리고 그동안 내가 읽어왔던 책들을 정리해보았다. 정리하다보니 나는 어떤 책을 읽어왔는지 증명할 수 있는 기록이 없고 정말 단지 '글자를 읽었다' 라는 개념밖에 지금은 남지 않고 있다는 것을 깨달았다. 이 시리즈는 내가 읽은 책들에 대한 기록이 될것이다. 사실 지식 전달을 하기보다는 해당 개념에 대한 내 생각을 정리하는 것에 대한 기록을 할 것이다. 해당 지식을 알고 싶으면 직접 책을 다시 읽어라 미래의 내 자신아! 그리고 기록해줘. 다시 읽어보니 또 어떤 생각의 확장이 발생되었는지!

나를 위한 책 시리즈가 될 것이다.

component1()

리스트의 첫번째 요소를 반환한다. 만약 리스트의 요소를 첫번째 이외에도 가져오고 싶다면 1이 아닌 다른 숫자를 적용하면 된다. 5번째까지 가능한 것 같다.

contains(), elementAt(), elementAtOrElse(), elementAtOrNull()

해당 요소가 포함되어 있는지 확인하는 용도로 쓰인다. 그렇다면 특정 위치의 element를 알고 싶다면? elementAt을 쓰면 된다. 코드를 보니 elementAtOrElse 를 사용하는 것을 볼 수 있다. 특정 위치에 element가 없다면 대신 다른 것을 내보내는 역할에 쓰인다. 아 물론 default가 아닌 null을 내보내고 싶을때는 elementAtOrNull()를 쓰면 된다.

find ⭐️

• find : 앞에서부터 탐색하여 만족하는 요소 존재한다면 만족하는 요소의 가장 첫번째를 반환한다. 없다면 null을 반환한다.
• findLast: 뒤에서부터 탐색하여 만족하는 요소가 존재한다면 만족하는 요소 있다면 반환하고 없다면 null을 반환한다.

get

• getOrElse : 인덱스 위치에 요소가 있으면 해당 요소를 반환하고 아닌 경우, 지정한 기본값을 반환한다.
• getOrNull : 주어진 인덱스에 대해 element가 없으면 반환해주고, 없으면 null 반환한다.

index

• indexOf : 주어진 요소에 일치하는 첫 인덱스를 반환한다.
• indexOfFirst : 람다식에 일치하는 첫 요소의 인덱스를 반환한다.
• indexOfLast : 람다식에 일치하는 마지막 요소의 인덱스를 반환한다.

last, first ⭐️

• last: 마지막 요소를 반환한다. 람다식에 일치하는 마지막 요소 반환한다. 그외 : lastIndexOf() - 마지막 인덱스 반환 lastOrNull() - 없으면 null 반환

• first: 첫번째 요소를 반환한다. 람다식에 일치하는 첫번째 요소를 반환한다. 그외 firstNotNullOf - 주어진 람다를 적용한 결과 중 첫 번째로 null이 아닌 값을 반환 ( first는 요소 자체를 반환하지만 firstNotNullOf는 요소에 변환을 적용한 후 null이 아닌 결과를 찾는다.) firstNotNullOfOrNull - NoSuchElementException이 발생하는 상황에서 null을 반환 firstOrNull() - 없으면 null 반환

random

• random() : collection의 요소 중 하나를 랜덤으로 가져온다
• randomOrNull() : collection의 요소 중 하나를 랜덤으로 가져오거나 collection이 비어있으면 null을 반환한다.

single

• single() : 조건을 만족하는 원소가 딱 하나일 때 그 값을 반환한다. 없으면 에러낸다.
• singleOrNull() : 조건을 만족하는 원소가 딱 하나일 때 그 값을 반환한다. 없으면 null을 반환한다.

drop ⭐️

• drop(n: Int) : 리스트의 앞부분부터 지정한 개수(n)만큼의 요소를 뺀 새로운 리스트를 생성하는 메서드
• dropLast(n: Int) : 리스트의 뒤에서부터 지정한 개수(n)만큼의 요소를 뺀 새로운 리스트를 생성하는 메서드
• dropWhile(predicate: (T) -> Boolean) : 조건이 만족할 때까지 앞에서부터 버리고 나머지를 리턴한다
• dropLastWhile(predicate: (T) -> Boolean) : 조건이 만족할 때까지 뒤에서부터 버리고 나머지를 리턴한다.

filter ⭐️

• filter : 컬렉션에서 주어진 조건을 만족하는 요소들만을 필터링하여 새로운 리스트를 반환

• filterTo : 컬렉션에서 주어진 조건을 만족하는 요소들만 필터링하여, 그 결과를 주어진 컬렉션에 추가

📌 인덱스 활용

• filterIndexed : 리스트의 각 요소와 해당 요소의 인덱스를 기반으로 조건에 맞는 요소들만을 필터링하여 새로운 리스트를 반환. 새로운 리스트가 필요할 때 사용 -> 각 요소의 인덱스를 고려하여 조건을 만족하는 요소만 필터링하고 있음. 여기서 짝수 인덱스이면서 값이 2보다 큰 요소들만 선택됨

• filterIndexedTo : 주어진 리스트나 컬렉션에 인덱스와 값을 기준으로 필터링된 요소를 추가. 결과를 다른 컬렉션에 담아야 할 때 유용 -> 필터링된 결과를 새로운 리스트에 반환하는 대신, 이미 존재하는 targetList에 추가

📌 특정 타입의 요소들만 필터링

• filterIsInstance : 컬렉션에서 특정 타입의 요소들만 필터링하여 새로운 리스트로 반환. 새로운 리스트가 필요할 때 사용 -> String 타입의 요소들만 필터링하여 새로운 리스트를 반환

• filterIsInstanceTo : 컬렉션에서 특정 타입의 요소들을 주어진 컬렉션에 필터링하여 추가. 기존 컬렉션을 이용해 결과를 추가할 때 유용 -> 필터링된 결과를 새로운 리스트가 아닌, targetList라는 기존의 리스트에 추가

📌 특정 조건에 맞지 않는 요소 또는 null이 아닌 요소를 필터링

• filterNot : 주어진 조건을 만족하지 않는 요소들만 필터링하여 새로운 리스트를 반환

• filterNotTo : 주어진 조건을 만족하지 않는 요소들만 필터링하여, 그 결과를 주어진 컬렉션에 추가

• filterNotNull : 컬렉션에서 null이 아닌 요소들만 필터링

• filterNotNullTo : 주어진 조건을 만족하지 않는 요소들만 필터링하여, 그 결과를 주어진 컬렉션에 추가

기타 ⭐️

• slice : 컬렉션에서 주어진 인덱스 또는 범위에 해당하는 요소를 선택하여 새로운 컬렉션을 반환. 인덱스 범위를 지정하여 그에 해당하는 요소만 선택

• partition : 컬렉션의 요소를 두 개의 리스트로 나누는 함수

• take : 컬렉션의 처음부터 주어진 개수만큼의 요소를 선택하여 새로운 리스트를 반환

• takeLast : 컬렉션의 끝에서부터 주어진 개수만큼의 요소를 선택하여 새로운 리스트를 반환

• takeLastWhile : 주어진 조건을 만족하는 마지막 요소들만 선택하여 새로운 리스트를 반환합니다. 조건을 만족하지 않는 첫 번째 요소가 발견될 때까지 선택. 조건에 맞는 요소를 끝에서부터 선택

• takeWhile : 주어진 조건을 만족하는 처음부터 요소들을 선택하여 새로운 리스트를 반환합니다. 조건을 만족하지 않는 첫 번째 요소가 발견될 때까지 선택

• reversed : 컬렉션의 요소 순서를 반전시켜 새로운 리스트를 반환 ⭐️

• shuffle : 컬렉션의 요소를 무작위로 섞어 새로운 리스트를 반환

sort ⭐️

• sortBy : 오름차순으로 정렬

• sortByDescending : 내림차순으로 정렬

• sorted : 리스트를 오름차순으로 정렬한 새로운 리스트를 반환

• sortedDescending : 리스트를 내림차순으로 정렬한 새로운 리스트를 반환

• sortedBy : 주어진 기준에 따라 오름차순으로 정렬한 새로운 리스트를 반환

• sortedByDescending : 주어진 기준에 따라 내림차순으로 정렬한 새로운 리스트를 반환

• sortedWith : 커스텀 Comparator를 사용하여 정렬한 새로운 리스트를 반환

sortBy, sortByDescending: 원본 리스트를 기준에 따라 정렬하며, 원본이 변경됨 (MutableList 전용). sorted, sortedBy, sortedByDescending, sortedDescending, sortedWith: 새로운 리스트를 반환하며, 원본은 변경되지 않음.

변환

컬렉션을 배열로 변환

• toBooleanArray

• toByteArray

• toCharArray

• toDoubleArray

• toFloatArray

• toIntArray

• toLongArray

• toShortArray

• toMutableSet

• toCollection : 컬렉션을 다른 컬렉션(타입 지정 가능)으로 변환. 주로 새 컬렉션에 기존 데이터를 넣고자 할 때 사용

• toHashSet : 컬렉션을 HashSet으로 변환. 중복을 제거하고 순서는 보장

• toList

• toMutableList

• toSet

associate ⭐️

• associate : 컬렉션의 각 요소에 대해 Pair를 생성하여, 이를 키-값 쌍으로 Map

• associateBy : 각 요소를 키로 변환하는 함수를 제공하여, 이를 기준으로 Map을 만듦

• associateByTo : 기존 MutableMap에 각 요소를 키로 변환한 값을 추가하여 MutableMap을 만듦. associateBy와 기능은 동일하지만, 결과를 지정한 MutableMap에 추가

• associateTo : 각 요소에 대해 Pair를 생성하고, 이를 주어진 MutableMap에 추가. associate와 기능은 동일하지만, 결과를 지정한 MutableMap에 추가

• associateWith : 각 요소를 키로 사용하고, 이를 값으로 변환하는 함수를 제공하여 Map을 만든다

• associateWithTo : 각 요소를 키로 사용하고, 변환한 값을 제공된 MutableMap에 추가하여 MutableMap을 만듭니다. associateWith와 동일하지만, 결과를 지정한 MutableMap에 추가

group ⭐️

• groupBy : 컬렉션의 요소들을 지정된 키 기준으로 그룹화하여, Map으로 반환

• groupByTo : groupBy와 동일하지만, 그룹화 결과를 새로운 Map 대신 지정한 MutableMap에 추가

• groupingBy : 컬렉션을 지연 그룹화하는데 사용됩니다. groupingBy는 즉시 결과를 반환하는 대신 그룹화 전략 객체를 생성. 그룹화된 데이터를 후처리하기 위한 여러 확장 함수와 함께 사용

정리 groupBy: 즉시 그룹화하여 새로운 Map 반환. groupByTo: 결과를 기존 MutableMap에 추가. groupingBy: 지연 그룹화 후 추가 처리 가능.

map ⭐️

• flatMap : 각 요소를 변환한 후 다중 요소로 확장하고, 이를 평탄화(flatten)하여 하나의 리스트로 만든다.

• flatMapIndexed : 각 요소와 인덱스를 사용하여 다중 요소로 변환하고, 이를 평탄화(flatten)하여 하나의 리스트로 만든다.

• flatMapIndexedTo : 각 요소와 인덱스를 사용하여 변환한 다중 요소를 지정된 MutableCollection에 추가하고, 이를 평탄화(flatten)

• flatMapTo : 각 요소를 다중 요소로 변환하고, 이를 지정된 MutableCollection에 평탄화(flatten)하여 추가

• map : 컬렉션의 각 요소를 변환하여 새로운 컬렉션으로 만든다.

• mapIndexed : 각 요소와 해당 요소의 인덱스를 함께 사용하여 변환된 새로운 컬렉션을 만든다.

• mapIndexedNotNull : 각 요소와 인덱스를 함께 사용하여 변환하되, null을 제외한 요소들만을 포함하는 새로운 컬렉션을 만든다.

• mapIndexedNotNullTo : 각 요소와 인덱스를 사용하여 변환한 결과에서 null을 제외하고, 지정된 MutableCollection에 추가

• mapIndexedTo : 각 요소와 인덱스를 함께 사용하여 변환된 결과를 지정된 MutableCollection에 추가

• mapNotNull : 각 요소를 변환하되, null이 아닌 요소들만 포함하는 새로운 컬렉션을 만든다

• mapNotNullTo : 각 요소를 변환하여 null을 제외한 결과를 지정된 MutableCollection에 추가한다.

• mapTo : 각 요소를 변환한 결과를 지정된 MutableCollection에 추가한다.

기타

• withIndex : 컬렉션의 각 요소에 대한 인덱스와 값을 포함하는 시퀀스를 반환

• distinct : 컬렉션의 중복 요소를 제거하여 새로운 컬렉션을 반환 ⭐️

• distinctBy : 주어진 조건에 따라 중복 요소를 제거

• intersect : 두 컬렉션의 교집합을 반환

• union : 두 컬렉션의 합집합을 반환 ⭐️

• subtract : 컬렉션에서 다른 컬렉션의 요소를 제거하여 새로운 컬렉션을 반환

• all : 컬렉션의 모든 요소가 주어진 조건을 만족하는지 확인 ⭐️

• any : 컬렉션의 어떤 요소라도 주어진 조건을 만족하는지 확인 ⭐️

• count : 주어진 조건을 만족하는 요소의 개수를 반환 ⭐️

• none : 컬렉션의 모든 요소가 주어진 조건을 만족하지 않는지 확인 ⭐️

• windowed : 컬렉션을 지정한 크기의 슬라이딩 윈도우로 나누어 리스트의 리스트를 반환 ⭐️

• zip : 두 컬렉션의 요소를 쌍으로 묶어 새로운 리스트를 생성 ⭐️

• zipWithNext : 컬렉션의 요소를 인접한 요소와 쌍으로 묶어 새로운 리스트를 생성

• joinTo : 컬렉션의 모든 요소를 지정한 대상에 문자열로 추가

• joinToString : 컬렉션의 모든 요소를 문자열로 결합하여 반환. 각 요소 사이에 지정된 구분자를 사용하고, 필요에 따라 접두사와 접미사를 추가할 수 있다 ⭐️

형식)
joinToString(
    separator: String = ", ",
    prefix: String = "",
    postfix: String = "",
    limit: Int = -1,
    truncated: String = "...",
    transform: ((T) -> CharSequence)? = null
): String

• asSequence : 컬렉션을 시퀀스로 변환하여, 지연 평가를 사용할 수 있게 합니다. 이는 큰 컬렉션을 처리할 때 성능을 개선할 수 있습니다. 특징: 시퀀스는 중간 연산을 지연 실행하므로, 효율적으로 요소를 처리할 수 있다. ⭐️

• average : 숫자형 컬렉션의 평균 값을 계산하여 반환

fold ⭐️

• fold : 컬렉션의 왼쪽부터(앞에서부터) 각 요소를 누적하여 하나의 값으로 축약합니다. 초기값을 설정한다. -- 형식: fold(initial: R, operation: (acc: R, T) -> R)

• foldIndexed : fold와 동일하게 왼쪽부터 처리하되, 인덱스를 포함하여 요소를 처리한다. -- 형식: foldIndexed(initial: R, operation: (index: Int, acc: R, T) -> R)

• foldRight : 컬렉션의 오른쪽부터(뒤에서부터) 각 요소를 누적하여 하나의 값으로 축약합니다. 초기값을 설정할 수 있다. -- 형식: foldRight(initial: R, operation: (T, acc: R) -> R)

• foldRightIndexed -- 형식: foldRightIndexed(initial: R, operation: (index: Int, T, acc: R) -> R)

Each ⭐️

• forEach : 컬렉션의 각 요소에 대해 주어진 작업을 수행함.
• forEachIndexed : forEach와 동일하나, 각 요소와 함께 인덱스 정보도 제공
• onEach : 컬렉션의 각 요소에 대해 주어진 작업을 수행한 후, 원래 컬렉션을 그대로 반환합니다. 보통 중간 연산으로 사용되며, 작업을 수행한 후 결과를 다시 사용
• onEachIndexed : onEach와 동일하나, 각 요소와 함께 인덱스 정보도 제공합니다. 작업 후 원래 컬렉션을 반환

• forEach 계열은 주로 부작용을 발생시키며 결과를 반환하지 않는다.
• onEach 계열은 부작용을 발생시키면서도 원래 컬렉션을 반환하여 체이닝에 유용

max ⭐️

• max : 컬렉션에서 최댓값을 찾기

• maxOrNull : 컬렉션에서 최댓값을 찾으며, 비어 있는 경우 null을 반환

• maxByOrNull : 주어진 람다식에 따라 특정 기준을 기반으로 최댓값을 찾으며, 비어 있는 경우 null을 반환

• maxBy : 주어진 람다식에 따라 특정 기준을 기반으로 최댓값을 찾는다. 비어 있는 컬렉션이면 예외가 발생

• maxOf : 주어진 람다식을 적용하여 최댓값을 반환합니다. 비어 있는 컬렉션이면 예외가 발생

• maxOfOrNull : 주어진 람다식을 적용하여 최댓값을 반환하며, 비어 있는 경우 null을 반환

• maxOfWith : 주어진 비교 기준(Comparator)을 사용하여 특정 람다식을 적용한 후 최댓값을 반환합니다. 비어 있는 컬렉션이면 예외가 발생

• maxOfWithOrNull : 주어진 비교 기준과 람다식을 사용하여 최댓값을 찾으며, 비어 있는 경우 null을 반환

• maxWith : 주어진 비교 기준(Comparator)을 사용하여 컬렉션에서 최댓값을 반환합니다. 비어 있는 컬렉션이면 예외

• maxWithOrNull : 주어진 비교 기준(Comparator)을 사용하여 최댓값을 찾으며, 비어 있는 경우 null을 반환

min ⭐️

• min
• minBy
• minByOrNull
• minOf
• minOfOrNull
• minOfWith
• minOfWithOrNull
• minOrNull
• minWith
• minWithOrNull

reduce ⭐️

reduce 함수들은 컬렉션의 요소들을 누적(accumulate)하여 하나의 값으로 축약하는 연산을 수행합니다. fold와 비슷하지만, reduce는 초기값을 사용하지 않고 컬렉션의 첫 번째 요소를 누적값으로 시작합니다.

• reduce: 컬렉션의 왼쪽부터 차례대로 요소를 누적하며 하나의 값으로 축약합니다. 첫 번째 요소를 시작점으로 사용합니다. 비어 있는 컬렉션이면 예외가 발생 초기값 없이 컬렉션의 첫 번째 요소를 누적값으로 사용

• reduceOrNull : reduce와 동일하지만, 비어 있는 컬렉션일 경우 null을 반환

• reduceIndexed : reduce와 동일하지만, 인덱스 정보를 함께 사용하여 요소를 누적합니다. 첫 번째 요소를 시작점으로 사용합니다. 비어 있는 컬렉션이면 예외가 발생

• reduceIndexedOrNull : reduceIndexed와 동일하지만, 비어 있는 컬렉션일 경우 null을 반환

reduceRight 계열은 오른쪽부터 처리한다

• reduceRight
• reduceRightIndexed
• reduceRightIndexedOrNull
• reduceRightOrNull

running ⭐️

runningFold와 runningReduce 계열 함수들은 중간 결과를 포함한 연산의 누적 결과 리스트를 반환하는 함수들입니다. 기존의 fold와 reduce처럼 연산을 누적하는 방식이지만, 매 단계마다의 중간 결과를 리스트에 저장하여 최종 결과뿐만 아니라 각 단계에서의 결과를 확인할 수 있다.

• runningFold : 주어진 초기값(initial value)에서 시작하여, 컬렉션의 각 요소마다 누적값을 적용한 중간 결과 리스트를 반환

• runningFoldIndexed : runningFold와 동일하지만, 인덱스 정보를 함께 사용하여 각 요소마다 누적 연산을 수행하고 중간 결과 리스트를 반환

• runningReduce : reduce와 유사하게, 초기값 없이 컬렉션의 첫 번째 요소를 누적값으로 시작하며, 각 요소마다 누적 결과 리스트를 반환

• runningReduceIndexed : runningReduce와 동일하지만, 인덱스 정보를 함께 사용하여 각 요소마다 누적 연산을 수행하고 중간 결과 리스트를 반환

이 함수들은 각 단계별 중간 결과를 기록하는 점에서 단순한 fold 및 reduce와 차이가 있습니다.

scan ⭐️

• scan : 컬렉션의 각 요소를 누적하여 결과 리스트를 반환합니다. 첫 번째 요소를 시작점으로 사용하고, 각 요소마다 누적 결과를 포함. 첫 번째 요소를 누적값으로 사용하며, 각 단계의 누적 결과가 리스트로 저장

• scanIndexed : scan과 동일하지만, 인덱스 정보를 함께 사용하여 각 요소마다 누적 연산을 수행하고 결과 리스트를 반환합니다.

중간 결과를 기록하는 점에서 유용하며, 복잡한 누적 연산을 쉽게 구현할 수 있게 도와준다.

sum

• sumBy : 컬렉션의 각 요소에 대해 주어진 변환 함수를 적용하여 그 결과의 합을 계산합니다. 주로 정수 값을 반환하는 함수와 함께 사용

• sumByDouble : 컬렉션의 각 요소에 대해 주어진 변환 함수를 적용하여 그 결과의 합을 계산합니다. 주로 Double 값을 반환하는 함수와 함께 사용합니다. 현재는 deprecated된 함수입니다.

• sumOf : 컬렉션의 각 요소에 대해 주어진 변환 함수를 적용하여 그 결과의 합을 계산합니다. Int, Double, Long 등 다양한 타입의 합계를 지원 ⭐️

require, chunk ⭐️

• requireNoNulls : 컬렉션에 널(null) 값이 포함되어 있지 않음을 보장하는 함수입니다. 만약 컬렉션에 널 값이 포함되어 있다면, IllegalArgumentException을 발생시킵니다. 주로 널 값을 허용하지 않는 컬렉션을 필요로 하는 경우 사용합니다

• chunked : 컬렉션을 주어진 크기(chunk size)로 나누어 작은 리스트의 리스트로 변환하는 함수. 남은 요소가 있는 경우, 마지막 청크는 주어진 크기보다 작을 수 있습니다. 이를 통해 대규모 데이터를 작은 조각으로 나누어 처리할 수 있습니다.

minus, plus

• minus
• minusElement : minus와 기능적으로 유사하지만, 명시적으로 minusElement를 사용하여 의도를 더욱 분명히 할 수 있습니다.
• plus
• plusElement : plus와 기능 같습니다

새로운 시니어 개발자가 들어왔당🎉 그때 들었던 말 중에 하나가

나랑 일하려면 리플랙션 알아야 행 ><

였다. 리플랙션? 그게 뭐였지? 그 동안 코드 상에서 리플랙션을 사용해본 적이 없어서 '뭐였더라? 예전에 어노테이션이랑 이런거 관련된 거 였는데' 정도만 생각하고 있었다. 이전에 내가 써놓은 이론적인 내용을 찾아보니 >> Object와 Reflection

리플렉션은 구체적인 클래스 타입을 알지 못해도, 그 클래스의 메소드, 타입, 변수들에 접근할 수 있도록 해주는 자바 API이다. 프로그램이 동적으로 소스 코드를 해석하여 클래스의 정보를 분석해 내는 기술

이라고 써져 있었다. 취준 기간에는 단순히 어떤 것인지 알아보았다면 이번에는 실무에서 얼마나 활용하는지 확인해보려고 한다.

📌 리플랙션을 통해 가져올 수 있는 것

간단히 리플랙션을 통해 알 수 있는 정보를 정리해보자면,

• getXXX() : 상속받은 클래스와 인터페이스를 포함하여 모든 public 요소를 가져온다.
• getDeclaredXXX() : 상속받은 클래스와 인터페이스를 제외하고 해당 클래스에 직접 정의된 내용만 가져온다. 또한 접근 제어자와 상관없이 요소에 접근할 수 있다 👉 메소드, 필드, 어노테이션 다 가져올 수 있다는 말

1. Class 객체를 획득 할 수 있다.
2. Class 를 사용해서 생성자를 Constructor 타입으로 가져올 수 있다
3. 필드 (목록) 가져올 수 있다 : 리플렉션을 사용하여 Field 타입의 오브젝트를 획득하여 객체 필드에 직접 접근할 수 있다.객체의 필드값에 접근하여 값을 수정 할 수도 있다.
4. 메소드 (목록) 가져져올 수 있다 : 리플렉션을 사용하여 Method 타입의 오브젝트를 획득하여 객체 메소드에 직접 접근할 수 있다
5. 어노테이션에 대한 정보 가져올 수 있다 : 클래스에 붙어있는 어노테이션을 가져올 수 있다. 어노테이션이 가지고 있는 필드에도 접근할 수 있다.

이렇게만 알면 잘 와닿지가 않는다. 생각해보면 내가 가장 궁금했던 것은 진짜 이걸 실무에서도 쓰긴 하는 거야? 어떻게 활용하는 거야? 였다.

📌 리플랙션의 활용

결론은 은근히 사용했다. 경험이 쌓이면 더 많이 사용하는 모습이 보일 것 같다. 내가 찾은 활용도는

1) 어노테이션 자신의 어노테이션을 만들고, 해당 어노테이션이 선언되어 있는 클래스가 있다.

만약 해당 어노테이션이 선언된 클래스들을 모아다가 같은 비지니스 로직을 행하게 하고 싶으면?

• metadata.getEntityBindings(): 데이터베이스 매핑 정보에서 모든 엔터티를 가져오는 메서드. 이는 ORM에서 데이터베이스 테이블과 Java 클래스 간의 매핑 정보를 나타낸다.
• persistent.getMappedClass(): 데이터베이스의 매핑된 엔터티에 해당하는 Java 클래스를 가져오는 메서드.
• type.getDeclaredAnnotation(BsEntityListeners.class): Java 클래스에서 BsEntityListeners 어노테이션을 찾아 가져오는 메서드

이런 식으로 활용한 경우도 있다.

2) 필드 비교 해당 코드는 나도 리플랙션을 사용해보고 싶어서 코드를 짜본 것이다. 기존 데이터와 데이터를 비교해서 만약 업데이트 된 컬럼이 존재한다면 해당 컬럼을 가져와야하는 요구사항이 있었다.

각 테이블마다 히스토리 테이블이 있었고 테이블의 모든 컬럼을 가져오고 일일히 다 비교하는 코드를 매 히스토리 테이블마다 하는 중복되는 코드를 짜고 싶지 않아서 리플랙션을 사용해서 요구사항을 풀었다.

위의 두 예시를 통해 단순히 실무에서도 종종 아주 가끔 사용은 한다~ 정도로만 참고하면 될 것 같다.

📌 리플랙션의 단점

하지만 실무에서도 리플랙션 사용을 선호하지는 않는다. 크게 두가지 이유가 존재한다.

1) 성능 저하 리플렉션은 클래스의 바이트 코드를 이용하는 것이 아닌, 메모리에 해당 클래스의 특성을 투영한 데이터를 이용하므로 매 번 호출되는 메서드라도 최적화가 되지 않게 된다. 즉,런타임에 클래스의 구조를 조사하고 메서드를 찾아야 하기 때문에 반복적으로 호출되는 작업에 대해서는 성능이 저하될 수 있다.

2) Private 필드 접근 가능 접근 제어자와 상관없이 다 접근 가능하기 때문에 보안적인 문제가 발생한다. invoke 메서드 호출 전에 setAccessible(true) 메서드를 호출해버리고 해당 값에 접근해버린다.

참고

• 리플렉션reflection이-느린-이유
• 리플렉션Reflection
• 리플렉션 (reflection) 개념 이해하기

처음 든 생각은 이게 뭐지?? 처음 본 것인데.. 내가 이렇게 공부를 안했던 거야? 언제 사용하는 것이지?? 바꿔서 달라지는 점이 뭐지?? 하위는 final?? 이게 무엇일까? 라는 의문을 가득 들게 만들었다. 의문점 해결 겸, 공부 겸, 다시 블로그를 쓰자는 올해의 다짐을 이행할 겸 컴퓨터 앞에 앉게 되었다.

📌 Sealed class 가 무엇일까?

자바 17에 나타난 존재였다.. 수민아 공부하자 ㅎ

개념 정리를 하자면

• sealed type : 상속할 수 있는 것을 제한하는 것이다. 특정 타입이 가질 수 있는 종류를 제한한다는 관점으로 접근하면 이해하기 쉽다. 즉 무분별한 자식 클래스 생성을 방지하기 위해 봉인한다는 의미를 가지고 있다. sealed type을 사용하기 위해서는 반드시
• permit : 허용하는 하위 타입 목록 지정 (sealed 클래스를 상속하는 클래스 지정) 를 같이 써줘야한다.

개발자는 코드가 이해가 빠르쥬? (클래스명은 이해해줘요..이름 바꿀꺼다..이름짓는게 너무 어려워!)

이렇게 써주면된다. 단, sealed 타입을 상속한 타입은

• final : 상속 못받음
• sealed : 상속을 다시 받을 수 있음
• non-sealed : 봉인을 해제한다. 중 하나를 지정해야 한다. 또한, sealed 타입과 같은 패키지/모듈에 위치해야 한다는 점을 명심해야 한다.

📌 Sealed class은 그래서 언제 쓴다고??

Sealed class의 특징을 살펴보자면,

1) 허락하지 않으면 추상화된 클래스에 접근 할 수 없다 2) 광범위하게 접근 가능하지만 광범위하게 확장 가능하지는 못한다. 라고 적혀져 있다. ㅎㅎ 너무 어렵게 표현되어있는데 사실 간단하게 정리하자면, ** 📍추상화가 필요한 곳 중 구현체를 제한하고 싶을 때 sealed class를 활용하면 된다. **

Superclass Accessible, Not Extensible

이 말이 딱 적절한 표현인 듯 싶다.

📌 그래서 현재 내 코드에 적용하는 것이 타당한가?

타당하다고 생각한다. 현재 내가 진행하는 코드는 상위 추상 클래스를 두 클래스가 상속하도록 되어있다. 기존 코드는 이 두 클래스 이외에도 다른 클래스들도 무분별하게 해당 상위 추상클래스를 상속받을 수 있는 구조기 때문에 지정된 클래스만 상속할 수 있도록 제한할 필요성이 있었다. 그런 이유로 sealed 클래스를 적용하라고 리뷰를 달아주신 것 같다. 리뷰를 달아주신 steven님에게 감사의 마음을 표현한다. 문서에서도 sealed class를 사용하는 예시에 대해 잘 이야기하고 있다.

• 관련 참고 링크

• CPU가 현재 작업중인 프로세스에서 다른 프로세스로 넘어갈 때, 이전의 프로세스 정보를 PCB에 저장하고 새롭게 실행할 프로세스의 정보를 PCB에서 읽어와 레지스터에 적재하는 과정을 말한다.

1) 요청 발생 : 인터럽트나 트렙에 의해서 컨텍스트를 바꿔야 한다는 요청이 들어옴
ex) I/O 입출력, 예외, 시스템 콜 등 2) PCB 에 프로세스 정보 저장 : 기존에 실행중이던 프로세스 P0 와 관련된 정보들을 PCB0 에 저장함
running → waiting 3) CPU 새롭게 할당 운영체제는 새롭게 실행할 프로세스 P1 에 대한 정보를 해당 PCB 에서 가져와 CPU 레지스터에 적재함 4) 요청 발생 : 인터럽트나 트렙에 의해서 컨텍스트를 바꿔야 한다는 요청이 들어옴 - P1의 상태를 PCB1에 저장 5) PCB0에 저장된 P0의 상태를 불러와 복구한다. 6) P0 실행

📌 PCB ( Process control block )

• 운영체제가 프로세스를 제어하기 위해 정보(CPU 레지스터 값들)를 저장해 놓는 곳으로 프로세스의 상태 정보를 저장하는 구조체 운영체제가 프로세스 스케줄링을 위해 프로세스에 관한 모든 정보를 가지고 있는 데이터베이스

• 각 프로세스가 생성될 때마다 고유의 PCB가 생성되고, 프로세스가 완료되면 PCB는 제거된다.

• 프로세스는 CPU를 점유하여 작업을 처리하다가도 상태가 전이되면, 진행하던 작업 내용들을 모두 정리하고 CPU를 반환해야 하는데, 이때 진행하던 작업들을 모두 저장하지 않으면 다음에 자신의 순서가 왔을 때 어떠한 작업을 해야하는지 알 수 없는 사태가 발생한다.

• 프로세스는 CPU가 처리하던 작업의 내용들을 자신의 PCB에 저장하고, 다음에 다시 CPU를 점유하여 작업을 수행해야 할 때 PCB로부터 해당 정보들을 CPU에 넘겨와서 계속해서 하던 작업을 진행할 수 있게 된다.

• PCB 는 프로세스의 중요한 정보들을 담고 있으므로 일반 사용자는 접근하지 못하는 보호된 메모리 영역에 존재

• PCB에 저장되어 있는 정보 1) 프로세스 식별자(Process ID) : 프로세스 고유 번호 2) 프로세스 상태(Process State) : 생성(create), 준비(ready), 실행 (running), 대기(waiting), 완료(terminated) 3) 프로그램 계수기(Program Counter) : 프로그램 계수기는 이 프로세스가 다음에 실행할 명령어의 주소를 가리킵니다. 4) CPU 레지스터 및 일반 레지스터 : CPU(Central Processing Unit)가 요청을 처리하는 데 필요한 데이터를 일시적으로 저장하는 기억장치 5) CPU 스케줄링 정보 : 우선 순위, 최종 실행시각, CPU 점유시간 등 6) 메모리 관리 정보 : 해당 프로세스의 주소 공간 등 7) 프로세스 계정 정보 : 페이지 테이블, 스케줄링 큐 포인터, 소유자, 부모 등 8) 입출력 상태 정보 : 프로세스에 할당된 입출력장치 목록, 열린 파일 목록 등 9) 포인터 : 부모프로세스에 대한 포인터, 자식 프로세스에 대한 포인터, 프로세스가 위치한 메모리 주소에 대한 포인터, 할당된 자원에 대한 포인터 정보 등. 프로세스가 준비상태나 대기 상태일 경우에 큐로 운영이 되는데, 프로세스 제어 블록을 연결 시 큐로 구현하기 위해 포인터를 사용한다.

• 운영체제는 빠르게 PCB에 접근하기 위해 프로세스 테이블을 사용하여 각 프로세스의 PCB를 관리한다

• 프로세스는 각각의 프로세스 이미지를 가진다. 프로세스 이미지는 데이터, 프로그램, 스택, PCB를 가진다.

📌 TCB (Thread Control Block)

• TCB는 PCB보다 적은 데이터를 가지는 자료구조이다. 참고) 스레드끼리는 사용자 수준 문맥의 text 영역과 data 영역은 공유, stack 영역은 따로 갖는다

• 구조 1) 스레드 ID : 스레드가 생성될 때 운영 체제에서 스레드에 할당하는 고유 식별자 2) 스레드 상태: 스레드가 시스템을 통해 진행됨에 따라 변경되는 스레드의 상태 3) CPU 정보: 스레드가 얼마나 진행되었는지, 어떤 데이터가 사용되고 있는지 등 OS가 알아야 하는 모든 정보가 포함스레드 4) 우선 순위: 스레드 스케줄러가 READY 대기열에서 다음에 선택해야 하는 스레드를 결정하는 데 도움이 되는 다른 스레드에 대한 스레드의 가중치(또는 우선 순위) 5) PCB를 가리키는 포인터 : 이 스레드 생성을 트리거한 프로세스를 가리키는 포인터 6) 이 스레드가 생성한 스레드를 가리키는 포인터 ** 7) stack 포인터** ( stack : 스레드가 함수 호출할때 저장하는 곳)

• 메모리영역 중 PCB는 커널 영역TCB는 유저영역과 커널 영역에 둘다 있을 수 있다.

(1) 유저 영역 → 요즘은 거의 유저 영역은 거의 사용안함. 유저영역에 text, data, stack, heap 영역 스레드를 구현하고 관리하는 것이 유저영역에 heap에서 한다. 스레드 관련 모든 동작이 사용자 영역

(2) 커널 영역

커널에서 스레드 관련된 모든 작업(스케줄링, 실행) 을 관리한다. 사용자 스레드와 커널 스레드가 1:1 매핑이 되었있다. 커널이 전체 프로세스와 스레드 정보까지 유지한다. 스케줄링과 동기화를 위해 더 많은 자원 필요하다 스레드 교환에 커널 개입으로 사용자영역에서 커널 영역으로 전환 필요하다

• 프로그램을 구동하여 프로그램 자체와 프로그램의 상태가 메모리 상에서 실행되는 작업의 단위ex) 자바.class → 엔터 → JVM 시작 : 자바 프로세스 시작! 프로그램 : 일반적으로 하드 디스크 등에 저장되어 있는 실행 코드

• 하나의 프로세스는 운영체제로부터 각각 독립된 메모리 영역 (code, data, stack, heap)을 할당받는다.
• 한 프로세스는 다른 프로세스의 메모리에 직접 접근할 수 없다.
• JVM 기준, 기본적으로 32MB ~ 64MB의 물리 메모리 점유 프로세스를 이용해 하나의 작업을 동시에 수행하려고 여러개의 프로세스를 띄워 각각 메모리를 할당해야 한다면? → 쓰레드 등장 : 1MB 이내의 메모리 점유

쓰레드

• 프로세스 내에서 실행되는 흐름의 단위 혹은 CPU 스케줄링의 기본 단위
• 쓰레드는 각자 자신의 stack 영역을 보유한다.
• 쓰레드는 프로세스 내에서 Code, Data, Heap 영역을 공유한다.
• 프로세스 내에서 쓰레드들은 서로 주소 공간이나 자원들을 공유하며 실행할 수 있다.ex. 서로의 힙 메모리를 서로 읽고 쓸 수 있다.

멀티프로세스와 멀티 쓰레드

멀티프로세스

• 한 애플리케이션에 여러개의 프로세스를 구성하여, 각 프로세스가 하나의 작업을 처리한다.

• 장점 1) 안정성이 좋다 2) 여러개의 자식 프로세스 중 하나에 문제가 생겨도, 다른 자식 프로세스에 영향이 확산되지 않는다 ex) 크롬 브라우저에 여러개의 탭을 띄우고 여러 웹사이트 방문시 한 탭이 잘못되어도, 해당 탭만 이용못하고 다른 탭은 별 문제가 없다. 3) 각 프로세스들이 독립적으로 동작하여 자원이 서로 다르게 할당 된다.

• 단점 1) 메모리 사용량이 많다. 2) 프로세스간 자원 공유가 필요할시 IPC(Inter-Process Commnuication)를 사용IPC : 프로세스 사이의 어렵고 복잡한 통신 기법, 파이프, 소켓, 메세지큐 등을 이용 3) context switching에 의한 성능 저하의 우려가 존재한다.

• • CPU 메모리 검색(다음 프로세스 정보 불러오기)
• • CPU 캐시 메모리 초기화
• • 프로세스 상태 저장
• • 등등..

멀티 쓰레드

• 한 애플리케이션에 여러개의 쓰레드를 구성하여, 각 쓰레드가 하나의 작업을 처리한다. ex) 하나의 프로그램에서 두가지 이상의 동작을 동시에 처리하도록 하는 행위 . 웹서버

• 웹 브라우저의 단일 탭/창 내에서 브라우저 네트워크 처리, I/O 및 기타 작업을 관리하고 처리

• 장점 1) 자원 공유가 쉽다. 2) 시스템의 자원 소모가 감소하므로 프로세스를 할당하는 것보다 쓰레드를 할당하는 것이 비용이 적다 3) 프로세스 간 통신 방법에 비해 스레드 간의 통신 방법이 훨씬 간단하다-> 프로세스 간의 전환 속도보다 쓰레드 간의 전환 속도가 빠르다. 4) 스레드가 프로세스보다 가벼움

• • 데이터 용량
• • 생성 및 종료 5) 프로세스간 통신(IPC)를 사용하지 않고도 데이터 공유 가능 6) 컨텍스트 스위칭 오버헤드 존재하지만 상대적으로 프로세스의 컨텍스트 스위칭 오버해드보다 훨씬 비용이 낮다
• • 스레드 간에 공유하는 자원을 제외한 스레드 정보(stack, register)만 교체 7) 응답 시간이 빠르다

• 단점 1) 하나의 스레드에서 문제가 발생하면 다른 스레드들도 영향을 받아 전체 프로그램이 종료될 수 있다. 2) 쓰레드풀을 이용해 잔여 쓰레드를 가져와서 종료를 방지할 수 있지만, 새로운 쓰레드 생성이나 놀고 있는 쓰레드 가져오는 것에 대한 추가 비용 발생 3) 동기화 문제 발생 ( 공유 자원 ) 4) 데드락 문제 발생 5) 그래도 context switching overhead 문제는 존재

회사에서도, 친구들과의 대화에서 각각 한번씩 언급되었던 것이 빌더 패턴이었다. 대부분의 상황은 나는 주로 빌더패턴을 많이 사용했고, 이에 대해 반대하는 것이었다. 빌더 패턴은 객체를 생성하는 방법 중에 하나이다. 여러 대화를 하다보니, 내가 사실 그동안 빌더패턴을 사용한 것이 장점이 있어라기 보다는 습관적인 행동이었다는 것을 깨달았고, 이제라도 각각 어떤 장단점이 있는지 간단하게 정리해보려고 한다.

📌 객체를 생성하는 방법

객체를 생성하는 방법은 보통 3가지로 알려져있다.

1. 점층적 생성자 패턴
2. 자바빈즈 패턴
3. 빌더 패턴

각각의 생성 형태를 비교하자면,

🐳 점층적 생성자 패턴

User user = new User("유저1", "1234", "email1", 0L);

userRepository.save(user);

• 필수 매개변수를 받는 생성자를 먼저 생성하고, 선택 매개변수 1개를 추가로 받는 생성자, 선택 매개변수 2개를 추가로 받는 생성자 등의 형태로 매개변수 개수만큼 생성자를 늘리는 방식이다. 마치 생성자가 점층적으로 성장하는 생성자를 가지도록 한 디자인 패턴이다.
• 생성자를 오버로딩 하는 방식이다.

🐳 자바 빈즈 패턴

   User user = new User();
   user.setUserId("유저1");
   user.setUserPassword("1234");
   user.setEmail("email1");
   user.setMoney(0L);

   userRepository.save(user);

매개 변수가 없는 생성자(기본 생성자)로 객체를 만든 후, setter 메서드를 호출하여 원하는 매개변수의 값을 설정하는 방식이다.

🐳 빌더 패턴

    User user = User.builder()
                .userId("유저1")
                .userPassword("1234")
                .email("email1")
                .money(0L)
                .build();

    userRepository.save(user);

• 복잡한 객체의 생성 과정과 표현 방법을 분리하여 다양한 구성의 인스턴스를 만드는 생성 패턴이다.

• 생성자에 들어갈 매개 변수를 메서드로 하나하나 받아들이고 마지막에 통합 빌드해서 객체를 생성하는 방식이다. = 별도의 Builder 클래스를 만들어 메소드를 통해 step-by-step 으로 값을 입력받은 후에 최종적으로 build() 메소드로 하나의 인스턴스를 생성하여 리턴하는 패턴이다.

  • 메소드 체이닝을 통해 구현된다.

    📌 장단점

    🐳 점층적 생성자 패턴

  • 장점 구현이 간단하고 직관적이다

  • 단점 1) 매개변수가 많아질수록 많은 조합이 만들어지고, 생성자의 수가 많아진다. 2) 초기화하고 싶은 필드만 포함한 생성자가 존재하지 않을 경우 원치 않는 필드까지 매개변수에 값을 지정해줘야 한다.

  🐳 자바 빈즈 패턴

  • 장점 1) 구현이 간단하고 가독성이 좋다 2) setter 메서드를 통해 유연하게 객체의 상태를 변경할 수 있다.
  • 단점 1) 객체 생성과 초기화가 분리되어 객체의 무결성을 보장하기 어려울 수 있다. 2) setter 메서드가 있기 때문에 객체가 불변성을 가지기 어렵다 3) 멀티스레드 환경에서 동기화 문제가 발생할 수 있다. 4) 하나의 객체를 완성하기까지 메서드를 여러 번 호출해야 한다.

  🐳 빌더 패턴

  • 장점 1) 객체의 불변성을 보장한다. (setter 메소드가 없으므로) 2) build() 함수가 잘못된 값이 입력되었는지 검증하게 할 수도 있다. 3) 한 번에 객체를 생성하므로 객체 일관성이 깨지지 않는다.

  • 단점 1) 객체를 생성하기 위해 빌더 객체를 추가로 생성해야 하므로 오버헤드가 발생하다. 2) 일부 필드의 값을 안넣어도 필드가 Null로 들어가면서 객체가 생성가능하여, 개발자가 필수적으로 설정해야 하는 필드를 빠트릴 수 있다. 예를 들어 , 위의 예시에서 userPassword와 money에 대한 값을 넣지 않아도 생성가능하다.

    User user = User.builder()
                .userId("유저1")
                .email("email1")
                .build();
    
    userRepository.save(user);