Dev 달팽이 @_''

[객체 지향] 구조 패턴 1 - Adapter, Bridge Pattern

다본죽 — Sun, 1 Jun 2025 18:52:43 +0900

구조 패턴 1 - Adapter, Bridge Pattern

구조 패턴의 대표적인 패턴으로 Adapter, Bridge 패턴에 대해 Deep-Dive하려고 한다. 코틀린은 사용해보진 않았지만, 이번 디자인패턴은 코틀린으로 한번 진행해보려고 한다.

Adapter Pattern

서로 호환되지 않는 인터페이스를 가진 클래스들을 함께 동작하게 해주는 패턴. 가장 흔히 하는 비유가 한국-일본의 전기 플러그 어댑터이다. 일본에 여행갈 때 필수 준비물로 챙겨야하는 물건 중 하나가 돼지코 어댑터이다. 돼지코의 어댑터의 용도를 생각해보면 한국 규격의 콘센트를 일본 전압에 맞게 변환해준다. Adapter Pattern이 바로 그 역할이다. Adapter Pattern의 역할은 기존 클래스를 수정하지 않고도 클라이언트와 호환되도록 인터페이스를 "변환"해준다.

구조(UML)

Target: 클라이언트가 기대하는 인터페이스
Adaptee: 이미 존재하는 클래스(인터페이스가 다름)
Adapter: Target 인터페이스를 구현하고 내부에서 Adaptee를 호출

사용 예제

시나리오

기존 시스템에 있는 OldPrinter 클래스는 printOld(String msg) 메서드만 있음.
새 시스템은 Printable 인터페이스를 통해 print(String msg) 메서드를 사용해야 함.
기존 OldPrinter를 수정하지 않고 새 시스템에 맞게 연결해야 함 → Adapter 패턴

// Target
interface Printable {
    fun print(message: String)
}

// Adaptee(기존 클래스)
class OldPrinter {
    fun printOld(message: String) {
        println("Old printed $message")
    }
}

// Adpater: Printable을 구현하고 OldPrinter를 위임
class PrinterAdapter (private val oldPrinter: OldPrinter) : Printable {
    override fun print(message: String) {
        oldPrinter.printOld(message);
    }
}

fun main() {
    val oldPrinter = OldPrinter()
    val printer : Printable = PrinterAdapter(oldPrinter)

    printer.print("Print Adapter")

}

인터페이스를 구현해 기존 클래스에 맞춤: PrintAdapter는 Printable을 구현함으로써 클라이언트와 호환
기존 코드 수정 없음: OldPrinter는 그대로 유지
유연성 향상: 새로운 시스템은 기존 시스템과 분리된 채로 개발 가능

적용 고려 시점

기존 클래스를 수정할 수 없는 경우
새로운 시스템이이 레거시 시스템과 통합될 경우

Adapter Pattern VS Port-Adpater Pattern

최근 시스템이 MSA향으로 가면서 Port-Adapter Pattern(헥사고널 아키텍처)를 많이 고려하게 된다. Port-Adapter Pattern의 Adpater와 Adapter Pattern에서의 Adapter가 같은 역할을 한다고 생각하기 쉽다.(본인이 그렇게 생각을 하고 있었다...)

결론적으로 말하면, GoF의 Adapter Pattern과 Port-Adapter Pattern의 Adapter는 개념적으로 유사하지만, 쓰임새와 목적이 다르다.

Port-Adapter Pattern의 Adapter

Port-Adapter Pattern의 Port는 내부 도메인이 기대하는 인터페이스로 도메인으로 가거나 도메인에서 외부로 나갈 수 있게 해주는 인터페이스이다. Adapter는 Port구현하거나 호출하는 실제 구현체 (외부 시스템과 연결)이다. 예를 들어, UserRegisterUseCase를 호출하는 구현체 UserController는 Inbound-Adapter이다.

// Port (도메인이 기대하는 인터페이스)
interface UserRegisterUseCase {
    fun registerUser(user: User)
}

// Adapter (외부에서 도메인 호출)
@RestController
class UserController(private val userRegisterUseCase: UserRegisterUseCase) {
    @PostMapping("/users")
    fun createUser(@RequestBody user: User) {
        userRegisterUseCase.registerUser(user)
    }
}

Adapter Pattern과 Port-Adpater Pattern 비교

항목	Adapter Pattern	Port-Adapter Pattern
소속	디자인 패턴 (GoF)	아키텍처 스타일 (Hexagonal)
목적	호환되지 않는 인터페이스 연결	시스템 내부(core)와 외부(world) 연결
초점	객체 간의 인터페이스 변환	계층 간의 역할 구분 및 연결
위치	클래스 또는 객체 수준	아키텍처 상의 경계지점
방향성	클라이언트가 기대하는 인터페이스로 "변환"	내부 도메인 → 외부 or 외부 → 내부 흐름 중계
예시	PrinterAdapter가 OldPrinter 감쌈	Controller가 포트를 구현하여 Service 호출

Bridge Pattern

Adapter 패턴이 "호환"에 초점을 맞춘 패턴이라면, Bridge Pattern은 확장성과 유연성을 극대화하기 위한 패턴. 추상화와 구현을 분리하여 독립적으로 확장할 수 있도록 한다.

구조(UML)

Abstraction: 클라이언트가 사용하는 인터페이스. 구현체를 가짐
Implementor: 구현을 위한 인터페이스
ConcreteImplementor: 실제 구현
RefinedAbstraction: Abstraction의 확장(기능 추가)

사용 예제

시나리오

RemoteControl은 TV를 제어하는 추상화 계층
SamsungTV, LGTV는 TV의 실제 구현체
리모컨 종류와 TV 브랜드를 독립적으로 확장할 수 있어야 함

// Implementor: 구현 인터페이스
interface TV {
    fun turnOn()
    fun turnOff()
    fun setChannel(channel: Int)
}

// ConcreteImplementor: 구체 구현체
class SamsungTV : TV {
    override fun turnOn() = println("(Samsung)TV turned on")

    override fun turnOff() = println("(Samsung)TV turned off")

    override fun setChannel(channel: Int) = println("(Samsung)TV set channel $channel")
}

// ConcreteImplementor: 구체 구현체
class LgTV : TV {
    override fun turnOn() = println("(LG)TV turned on")

    override fun turnOff() = println("(LG)TV turned off")

    override fun setChannel(channel: Int) = println("(LG)TV set channel $channel")

}

// Abstraction: 추상 계층
abstract class RemoteController (protected val tv : TV) {
    abstract fun turnOn()
    abstract fun turnOff()
    abstract fun setChannel(channel : Int)
}

// RefinedAbstraction: 구체 추상화
class BasicRemoteController(tv: TV) : RemoteController(tv){
    override fun turnOn() = tv.turnOn()

    override fun turnOff() = tv.turnOff()

    override fun setChannel(channel: Int) = tv.setChannel(channel)
}

fun main() {
    val samsungTV = SamsungTV()
    val lgTV = LgTV()

    val remote1 = BasicRemoteController(samsungTV)
    val remote2 = BasicRemoteController(lgTV)

    remote1.turnOn()
    remote1.turnOff()
    remote1.setChannel(7)

    remote2.turnOn()
    remote2.turnOff()
    remote2.setChannel(9)

}

RemoteControl은 TV를 제어하는 추상화 계층
SamsungTV, LgTV는 실제 동작을 구현한 구현 계층
이 둘은 서로 독립적으로 확장 가능

적용 고려 시점

구현과 인터페이스를 독립적으로 확장해야 할 경우
기능 계층과 플랫폼 계층이 조합 가능한 형태로 분리되어야 할 경우
상속 대신 구성(Composition) 으로 다형성을 확보하고 싶을 경우

Adapter Pattern VS Bridge Pattern

항목	Adapter	Bridge
목적	호환되지 않는 인터페이스 연결	추상화와 구현을 분리
시점	통합 단계 (사후에 연결)	설계 단계 (처음부터 구조 분리)
유연성	낮음 (Adaptee 고정)	높음 (양쪽 독립적 확장 가능)
관계	1개의 계층 (클래스 ↔ 클래스)	2개의 계층 (추상 ↔ 구현)

[객체 지향] 디자인 패턴의 분류

다본죽 — Wed, 28 May 2025 17:39:05 +0900

디자인 패턴의 분류

본격적으로 디자인 패턴에 Deep-Dive 하기 전에 디자인 패턴의 분류에 대한 이해를 다지고 가려고 한다.(예열 느낌으로...)

디자인 패턴의 세 가지 분류

디자인 패턴의 분류는 패턴을 기능적 목적에 따라 나눈 것이다. 첫번째는 생성(Creational) 패턴, 두번째는 구조(Structural) 패턴, 마지막으로 행위(Behavioral) 패턴이 있다.

생성 패턴 (Creational Patterns)

객체의 생성 과정을 추상화하여 유연하고 재사용 가능한 방식으로 객체를 생성하는 목적의 패턴이다. 객체 생성 로직을 캡슐화하여 코드 의존성을 낮추고, 런타임 시점의 유연한 객체 결정이 가능하도록 하는 것이 특징이다. 대표적 패턴으로 Singleton, Factory Method, Abstract Factory, Builder, Prototype 등이 있다. 실무에서 자주 사용하는 Lombok의 @Builder가 생성 패턴의 대표적인 예이다.

구조 패턴 (Structual Patterns)

클래스나 객체를 조합하여 더 큰 구조를 만들되, 그 구조를 유연하게 유지하는 패턴이다. 객체들 간의 관계(연결/조합 방식)를 정의하고 인터페이스 호환성을 확보하면서 기능을 확장하는 것이 특징이다. 대표적 패턴으로 Adapter, Bridge, Composite, Decorator, Facade, Proxy 등이 있다. Spring을 사용하는 현업자라면 Proxy를 많이 들었을텐데, Proxy가 대표적인 구조 패턴이다.

행위 패턴 (Behavioral Patterns)

객체 간의 상호작용 및 책임 분산 방식을 정의하는 패턴이다. 책임의 위임과 메시지 흐름을 명확하게 하고, 실행 알고리즘을 동적으로 바꾸기 쉽게하는 것이 특징이다. 대표적 패턴으로 Observer, Strategy, Template Method, State, Command, Mediator, Iterator가 있다. 가장 많이 접해 봤을 법한 예로 Spring의 JdbcTemplate이나 RestTemplate(deprecated 됐지만..)이 있다. Spring의 @EventListener도 행위 패턴의 대표적인 예이다.

각 패턴의 핵심 역할 정리

분류 핵심 역할 왜 중요한가? 실제 예 (실무에서 자주 보이는 모습)

분류	핵심 역할	중요성	실무 예
생성(Creational)	객체를 어떻게 만들 것인가에 대한 전략	잘못된 객체 생성 방식은 유지보수와 테스트를 어렵게 만든다. 생성 로직을 분리하면 의존성 주입, 테스트가 쉬워진다.	- DI/IoC 컨테이너 (Spring, Guice) - Builder 패턴으로 복잡한 DTO 생성 - 싱글턴 서비스 인스턴스
구조(Structural)	클래스/객체를 어떻게 조합할 것인가에 대한 전략	변경에 유연한 구조는 장기 프로젝트에서 필수. 클래스 간 관계를 느슨하게 유지해야 확장이 가능해진다.	- Adapter로 외부 API 래핑 - Decorator로 요청/응답 가공 - Facade로 하위 모듈 캡슐화
행위(Behavioral)	객체 간 책임과 커뮤니케이션 방식에 대한 전략	객체 간 협력이 많아질수록 "누가 무엇을 담당하느냐"가 핵심이다. 책임 분산 없이는 코드가 뒤엉킨다.	- Strategy로 다양한 정책 선택 - Observer로 이벤트 처리 - Template Method로 공통 로직 재사용

정리

생성 패턴 - "객체는 아무데서나 만들지 않는다"

서비스 클래스에서 new 키워드 남용 시 테스트가 어려워지고, 의존성이 강해짐
패턴을 통해 의존성 주입, 객체 재사용, 책임 분리가 가능

구조 패턴 - "바꿔 끼울 수 있는 유연한 코드 구조를 만들자"

기존 클래스를 손대지 않고도 기능 확장 가능
변화에 강한 아키텍처 구성 가능

행위 패턴 - "객체 간 역할을 명확히 나누면 시스템이 견고해진다"

협력 관계, 이벤트 처리, 조건 분기 등 로직 흐름 제어에 핵심
유지보수/기능 추가 시 가장 자주 문제가 생기는 영역이므로 설계가 중요

[객체 지향] 객체지향원칙 - SOLID

다본죽 — Tue, 27 May 2025 18:25:41 +0900

객체지향원칙 - SOLID

실무에서 아키텍트 업무를 맡게 되면서(아직 이르지만..) DDD, 헥사고널 아키텍처에 대해 좀 더 깊이 있는 이해가 필요하게 되었다. 기본부터 다시 잡는 다는 생각으로 OOP, 디자인패턴부터 다시 다져보려 한다...

객체 지향 설계

객체지향원칙을 지키면서 설계하는 건 단순 "깔끔한 코드" 작성을 위해서는 아니다. 객체 지향 설계를 한다는 것은 확장이 쉽고, 높은 응집도와 낮은 결함도로 인해 변경이 전체 시스템에 미치는 영향을 줄이고, 리팩토링과 유지보수를 쉽게 설계한다는 것이다. SOLID는 이러한 설계를 할 수 있도록 도움을 주는 지침이다.

SOLID란?

객체지향 프로그래밍(OOP)의 5가지 핵심 설계 원칙, 유지보수성과 확장성이 뛰어난 소프트웨어를 설계하기 위한 개념

S - Single Responsibility Principle (단일 책임 원칙)
O - Open/Closed Principle (개방/폐쇄 원칙)
L - Liskov Substitution Principle (리스코프 치환 원칙)
I - Interface Segregation Principle (인터페이스 분리 원칙)
D - Dependency Inversion Principle (의존 역전 원칙)

Single Responsibility Principle (SRP)

하나의 클래스는 하나의 책임만 가져야 한다는 원칙. 즉, 클래스가 변경되는 이유가 하나뿐이어야 한다. 책임이 여러 개인 클래스는 여러 이유로 변경될 수 있으므로 유지보수가 어려워지고 테스트가 힘들어진다. 여기서 의미하는 책임의 범위는 개개인에 따라 다르다. 책임을 단순 기능(세부 동작)로 오해할 수 있다.(내가 그랬었다..)

예를 들어, Java의 Scanner는 단일 책임 원칙을 지킨 좋은 예이다. Sanner는 입력에 대한 책임만 가지고, 입력 후 데이터 처리는 별도 클래스가 담당한다. Scanner는 입력 -> 파싱 -> 반환의 단일 흐름 책임만 수행한다. 여기서 Scanner는 단일 책임 원칙을 잘 지킨 예라고 했는데 입력, 파싱, 반환 3가지 기능을 하고 있는 걸 볼 수 있다. 하지만 Scanner는 "입력 처리" 라는 단일 책임을 담당하고 있다. 즉, 책임의 범위를 단순 작업의 단위가 아니라 "클래스가 왜 바뀌는가?"를 기준으로 판단해야 한다.

Open/Closed Principle (OCP)

확장에는 열려있고, 수정에는 닫혀 있어야 한다는 원칙. 새로운 기능이 필요할 때 기존 코드는 수정하지 않고, 확장해서 대응할 수 있어야 한다. 추상 클래스와 인터페이스를 사용하여 새로운 기능을 구현하는 것을 의미한다.

예를 들어, Java의 Writer가 전형적인 예시이다. Writer는 추상 클래스로 되어 있다. 이를 FileWriter, BufferedWriter, StringWriter 등 다양한 구현체가 존재하며, 새로운 출력 방식이 필요하면 하위 클래스를 확장하면 된다.

// Writer.java
public abstract class Writer implements Appendable, Closeable, Flushable {
	//...
}

Liskov Substitution Principle (LSP)

자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 한다는 원칙. 부모 타입을 사용하는 코드에서, 자식 타입으로 대체해도 기능에 문제가 없어야 한다. 즉, LSP는 다형성에 대한 원칙이다. LSP를 지키지 않으면 상속을 썼는데도 다형성이 깨져 부모 타입으로 코딩하는 게 의미가 없어진다. 이를 지키기 위해선 자식 클래스가 부모 클래스의 계약(contract)를 지키도록 설계해 치환 가능성을 유지해야한다. 이 말은 LSP는 단순히 "상속이 잘 되도록" 설계하는 것이 아닌 "상위 타입으로 안전하게 추론할 수 있도록" 설계를 해야 한다는 메시지를 담고 있다.

*Contract란?
부모 클래스(또는 인터페이스)가 외부(클라이언트)에게 약속하는 동작과 규칙.
- 메서드 시그니처와 시맨틱
- 입력에 따른 기대 출력
- 예외
- 상태 변화 규칙

Java의 Collection 인터페이스는 LSP의 가장 대표적인 예이다.

List<String> arrayList = new ArrayList<>();
List<String> linkedList = new LinkedList<>();

arrayList.add("1");
linkedList.add("1");

ArrayList, LinkedList는 모두 List 인터페이스 구현체이다. 하위 클래스(구현체)를 상위 타입(List)로 치환해도 기능에 문제가 없다. 또한, Collections.sort(List) 어떤 List 구현체도 동등하게 처리한다.

자식이 부모의 계약을 지키기 위해선 아래가 지켜져야 한다.

부모가 가능한 입력을 자식도 전부 받아들여야 함
부모가 반환하는 값이나 상태 변화와 동등하거나 더 넓은 결과를 보장해야 함
예외 처리나 부작용도 예상 가능한 수준 내에서 일어나야 함

Interface Segregation Principle (ISP)

클라이언트는 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙. 큰 인터페이스 하나를 만드는 것보다, 작고 역할별로 분리된 인터페이스를 만들어야 한다. 즉, "인터페이스는 작게, 목적에 맞게" 설계 해야한다.

ISP 위반 Case

public interface Machine {
    void print();
    void scan();
    void fax();
}

public class SimplePrinter implements Machine {
    @Override
    public void print() {
        System.out.println("Print");
    }

    @Override
    public void scan() {
        System.out.println("Not Supported");}

    @Override
    public void fax() {
        System.out.println("Not Supported");
    }
}

ISP가 위반된 케이스를 보면 불필요한 메서드를 구현체에서 구현하게 된다. 이렇게 되면 유지보수가 어려워지고 코드에 대한 이해가 어려워진다.

ISP를 지킨 개선된 Case

public interface Printer {
    void print();


public interface Scanner {
    void scan();
}

public interface Fax {
    void fax();
}

public class SimplePrinter implements Printer {
    @Override
    public void print() {
        System.out.println("Print");
    }
}

개선된 케이스를 보면 필요한 기능만 구현하면 된다.

ISP의 예제를 보면 단일 책임 원칙(SRP)처럼 단일 책임을 가진 인터페이스를 만드는 것처럼 보인다. 그래서 이 둘의 개념이 혼동의 여지가 있다. 하지만 둘은 적용 대상과 맥락이 완전히 다르다.

SRP vs ISP

항목	SRP (단일 책임 원칙)	ISP (인터페이스 분리 원칙)
초점	클래스(또는 모듈)가 하나의 책임만 가져야 함	클라이언트가 사용하지 않는 인터페이스에 의존하지 않도록
적용 대상	클래스나 모듈 전체	인터페이스 (혹은 API 계약)
목표	변경 이유를 하나로 제한 (수정 시 영향을 최소화)	강제로 쓸데없는 메서드를 구현하지 않게 함
철학	“이 클래스는 왜 바뀌는가?”	“이 인터페이스를 구현하는 입장에서, 다 써야 하는가?”
위반 예	DB 저장 + PDF 출력 + 알림 전송을 한 클래스가 다 함	MultiFunctionPrinter가 scan(), fax() 등 안 쓰는 기능까지 구현

Dependency Inversion Principle (DIP)

고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다는 원칙. 비즈니스 로직은(고수준)은 구체적인 구현(저수준)에 의존 하면 안된다. 즉, 인터페이스(추상화)를 통해 의존 구조를 역전 시켜야 한다. DIP는 대부분 실무에서 많이 접하고 자연스럽게 체득하는 원칙이 아닌가 싶다. (특히, JPA를 보더라도...)

DIP 구조로 보는 JPA vs Hibernate

고수준: 비즈니스 로직 (Service, Repository)
↓
추상화: JPA (javax.persistence)
↓
저수준: Hibernate, EclipseLink, OpenJPA (구현체)

고수준 모듈인 비즈니스 로직은 jPA 인터페이스에만 의존하게 된다. JPA의 실제 동작은 구현체인 Hibernate가 수행한다. 비즈니스 로직은 Hibernate를 몰라도 작동이 가능하다. 또한, JPA의 구현체를 Hibernate가 아닌 다른 구현체를 사용하고 싶으면 구현체만 바꿔주면 된다.

즉, DIP를 통해 유연한 변경 구조가 가능하게 된다.(Loose Coupling)

결론

SOLID는 "변화에 강한 설계"를 위한 철학이다. SRP는 관심사를 분리해서 변경이유를 단일화, OCP는 기능 확장을 유연하게, LSP는 상속 관계에서의 신뢰성 확보, ISP는 클라이언트 인터페이스 최소화, DIP는 유연한 의존성과 테스트 용이성 확보에 초점을 두고 있다.

실무를 하다 보면 어떤 원칙은 자연스럽게 체득하고 고려하지만 어떤 원칙은 아직은 어렵게 느껴지는 거 같다.. 무조건 이 모두를 지켜야한다는 것은 아니지만, 적어도 적용할지 말지 고려하면서 설계하는 습관을 들여야겠다..

Redis Lettuce를 통한 동시성 제어

다본죽 — Mon, 17 Jun 2024 23:37:19 +0900

Redis Lettuce를 통한 동시성 제어

들어가기 전에..

구축 프로젝트 진행 중, 기존 레거시 시스템의 문제(동시 예약)를 해결 해야하는 상황에 직면하게 됐다. 이 상황을 Redis Lettuce를 통해 해결하게 되었고, 이 경험에 대한 내용이다. 안그래도 실무에서 Redis를 경험해보고 싶었는데, 드디어 경험해 볼 기회가 생기게 되었다.(물론, Redis를 써서 해결할 수 있을 거라고 생각은 못했지만..)

직면한 문제

1. 수요일 00시에 주말에 이용할 수 있는 특정 차량 20대에 대한 예약이 풀린다.

2. 이를 예약하기 위해, 많은 이용자들이 23시59분 부터 대기를 하고 있다가 예약을 시도한다.

3. 같은 차량, 같은 날에 대해 동시에 예약이 된다.

이를 해결하기 위한 방법 모색(분산 Lock)

분산 Lock을 위한 방법으로 크게 3가지 방법을 찾았다. 첫번째는 DB에서 직접 처리, 두번째는 Java단에서 Transaction을 통해 처리, 세번째는 Redis를 이용한 방법이다.

1. MySQL Named Lock

get_lock
get_release

2. Java transaction

@Transactional
JTA(Java Transaction APIs)

3. Redis

Lettuce
Redisson

Redis를 선택한 이유

3가지 방법 중 Redis를 선택한 이유는 아래와 같다.

1. MySQL Named Lock

Named Lock을 관리할 별도의 Connection Pool 관리가 필요하다.
예약하기 하나의 버튼에서 실제 예약에 대한 Row만 저장되는 것이 아닌 여러 DB가 서비스 Logic(다른 MSA 영역 호출 포함)이 얽혀있으며, 마지막에 예약 데이터가 저장된다. (RollBack에 대한 부담)

2. Java transaction

동시 예약 간단한 처리 하나 처리하는 것에 비해 너무 많은 시간과 작업이 필요함
Named Lock을 사용할 때와 같이 RollBack에 대한 부담

3. Redis

Token 검증을 위한 Redis 서버가 이미 존재
실제 예약을 위한 서비스 Logic에 진입하기 전에 확인하여 RollBack에 대한 부담이 없음
In-memory 방식이라 사용자에게 빠른 응답이 가능

Lettuce vs Redisson

분산락을 위해 Redis를 사용하기로 정하였고, 이제 어떤 라이브러리를 사용하냐 고민에 있어서는 크게 어려움은 없었다.

Redisson이 더 분산락을 위해 지원하고 있는 것이 많고, Lettuce보다 분산락에 더 특화되어 있는 것이 맞으나, 현재 프로젝트에서 Lettuce를 사용하고 있었으며, 동시 예약에 대한 처리를 위해서만 사용하기 때문에(Retry가 필요 없음) Redisson이 지원하는 기능이 크게 필요가 없었다.

Lettuce를 사용할 때 주의할 점

Lettuce는 Spin Lock 방식이기 때문에, Redis 등록에 실패하면 계속해서 등록을 시도한다.(Redisson은 Pub/Sub 방식)

하지만, 동시 예약에 대한 문제는 등록이 실패되면 예약 실패를 응답으로 주면 되기 때문에, Expired Time을 꼭 줘야한다.

Logic 정리

1. 예약 진입

2. Redis에 예약 정보가(lock) 없으면 예약 Logic 진입

3. Redis에 예약 정보가(lock) 있으면 예약 실패 응답

적용 Flow

마무리

사실 이 문제에 직면했을 때, Redis를 사용해서 해결 할 수 있을 거라는 생각은 하지 못했다.. 기존에 Redis에 대한 개념 학습을 했을 때는 화면과 서버 간의 캐싱에 대해서만 학습했는데, 역시 개념 학습과 실무에 실제 적용은 좀 다르다는 생각이 들었다.

[이펙티브 자바] 2장 - 아이템 2. 생성자에 매개변수가 많다면 빌더를 고려하라.

다본죽 — Wed, 10 Jan 2024 23:36:52 +0900

[이펙티브 자바] 2장 - 아이템 2. 생성자에 매개변수가 많다면 빌더를 고려하라.

정적 팩터리와 생성자에는 매개변수가 많을 때, 적절히 대응하기 어렵다.

실제로 실무에서 Legacy 코드를 보다보면, 멤버변수가 많은 클래스 내부에 생성자, Getter, Setter가 덕지덕지 붙어 있는 경우를 심심찮게 볼 수 있다.

[참고] 멤버 변수가 8개인 User 클래스

public class User {
   String id
   String pwd;
   String nickname;
   
   String name;
   Integer age;
   String addr;
   String email;
   
   LocalDateTime lastLoginDtm;
   
   public User(String id, String pwd, String nickname) {
        this.id = id;
        this.pwd = pwd;
        this.nickname = nickname;
    }

    public User(String id, String pwd, String nickname, String name) {
        this.id = id;
        this.pwd = pwd;
        this.nickname = nickname;
        this.name = name;
    }

    public User(String id, String pwd, String nickname, String name, Integer age, String addr, String email, LocalDateTime lastLoginDtm) {
        this.id = id;
        this.pwd = pwd;
        this.nickname = nickname;
        this.name = name;
        this.age = age;
        this.addr = addr;
        this.email = email;
        this.lastLoginDtm = lastLoginDtm;
    }
    
    // ... 중략
}

또한, 이렇게 많은 멤버변수를 가지고 있는 클래스에 여러 생성자를 가지고 있다면, 어떤 멤버변수에 값을 넣어주고 있는지 파악하기가 힘든 경험이 다들 있을 것이다.

빌더 패턴

1. 안정성과 가독성을 겸비한 빌더 패턴(Builder pattern)

빌더 패턴은 클라이언트가 필요한 객체를 직접 만드는 대신, 필수 매개변수만으로 생성자를 호출해 빌더 객체를 얻는다. 그런 다음 빌더가 객체가 제공하는 일종의 Setter 메소드들로 원하는 선택 매개변수들을 설정한다. 마지막으로 매개변수가 없는 build 메서드를 호출하여 필요한 객체를 얻게 된다.

흔히, Spring에서 @Builder를 통해 빌더 패턴을 사용하곤 한다. 하지만, 실제로 Builder가 어떻게 구성되는지, 어떻게 동작하는지 알지 못하고 습관에 의해 사용하는 경우가 있다. 빌더가 어떻게 동작하는지 코드로 살펴보자.

public class User {
   String id
   String pwd;
   String nickname;
   
   String name;
   Integer age;
   String addr;
   String email;
   
   LocalDateTime lastLoginDtm;
   
   public static class Builder {
      private final String id;
      private final String pwd;
      private final String nickname;
      
      private String name;
      private Integer age;
      private String addr;
      private String email;
      
      public Builder(String id, String pwd, String nickname) {
         this.id = id;
         this.pwd = pwd;
         this.nickname = nickname;
      }
      
      public Builder name(String name) {
         name = name;
         return this;
      }
      
      public Builder age(Integer age) {
         age = age;
         return this;
      }
      
      // ...중략
      
      public User build() {
         return new User(this)
      }
      
   private User(Builder builder) {
      id = builder.id;
      pwd = builder.pwd;
      nickname = builder.nickname;
      
      name = builder.name;
      age = builder.age;
      addr = builder.addr;
      email = builder.email;
   }
}

User user = User.builder("dabon1234","daboni1234!@","dabonee").name("dabon").age(77).build();

User 클래스는 불변이 되었으며, 빌더의 세터 메서드들은 빌더 자신을 반환하기 때문에 연쇄적 호출이 가능하다. 에런 방식을 플루언트 API(fluent API) 혹은 메서드 연쇄(method chaining)이라고 한다. 빌더 패턴으로 인하여 직관적으로 어떤 멤버 변수를 넣었는지 확인이 가능하다.

2. 계층적으로 설계된 클래스와 함께 쓰기에 좋다.

추상 클래스는 추상 빌더를, 구체 클래스는 구체 빌더를 갖게한다. 다음은 메이플스토리의 다양한 직업을 표현하는 계층구조의 루트에 놓은 추상 클래스를 만들었다.

// 초보자
public abstract class Beginner {
    public enum Stat{STR, DEX, INT, LCK}
    private Set<Stat> stats;

    abstract static class Builder<T extends Builder<T>> {
        EnumSet<Stat> stats = EnumSet.noneOf(Stat.class);
        public T plusStat(Stat stat) {
            stats.add(Objects.requireNonNull(stat));
            return self();
        }

        abstract Beginner build();

        protected abstract T self();
    }

    Beginner(Builder<?> builder) {
        stats = builder.stats.clone();
    }

}

해당 코드에서 추상 메서드 self는 하위 클래스에서 형변환하지 않고도 메서드 연쇄를 할 수 있도록 해준다.

하위 클래스로 1차 전직하여 직업을 선택하도록 하였다.

public class Intermediate extends Beginner{
    public enum Job {WARRIOR, ARCHER, MAGICIAN, ROGUE}
    private final Job job;

    public static class Builder extends Beginner.Builder<Builder> {
        private final Job job;

        public Builder(Job job) {
            this.job = Objects.requireNonNull(job);
        }

        @Override public Intermediate build() {
            return new Intermediate(this);
        }

        @Override protected Builder self() {return this;}
    }

    private Intermediate(Builder builder) {
        super(builder);
        job = builder.job;
    }
}

하위 클래스의 build는 해당하는 구체 하위 클래스를 반환하도록 한다. 하위 클래스의 메서드가 상의 클래스의 메서드가 정의한 반환 타입이 아닌, 그 하위 타입을 반환하는 기능을 공변 반환 타이핑(convariant return typing)이라 한다. 이 기능으로 인해 클라이언트는 형변환에 신경쓰지 않고도 빌더를 사용할 수 있다.

Intermediate warrior = new Intermediate.Builder(WARRIOR).plusStat(STR).build();

생성자나 정적 팩터리가 처리해야 할 매개변수가 만하면 빌더 패턴을 선택하는 게 더 효과적이다.

[이펙티브 자바] 2장 - 아이템 1. 생성자 대신 정적 팩터리 메서드를 고려하라.

다본죽 — Tue, 9 Jan 2024 00:26:37 +0900

[이펙티브 자바] 2장 - 아이템 1. 생성자 대신 정적 팩터리 메서드를 고려하라.

클래스는 클라이언트에 public 생성자 대신 정적 팩터리 메서드를 제공할 수 있다.

정적 팩터리 메서드의 장점

1. 이름을 가질 수 있다.

생성자에 넘기는 매개변수와 생성자 자체 만으로는 반환될 객체의 특성을 제대로 설명하지 못한다. 반면에, 정적 팩터리 메서드는 이름만 잘 지으면 반환될 객체의 특성을 쉽게 파악할 수 있다.

class Human {
   private String gender;
   private Integer age;
    
   private Human(String gender,Integer age) {
      this.gender = gender;
      this.age = age;
   }
   
   // 정적 팩터리 메서드 - 남자 생성
   public static Human maleFrom(Integer age) {
      return new Human("male",age);
   }
   
   // 정적 팩터리 메서드 - 여자 생성
   public static Human femaleFrom(Integer age) {
      return new Human("female",age);
   }
   
   // 정적 팩터리 메서드 - 지정
   public static Human of(String gender, Integer age) {
      return new Human(gender,age)
   }
}

public static void main(String[] args) {
    // 20살 남자 생성 
    Human man = Human.maleFrom(20);

    // 30 여자 생성
    Human woman = Human.femaleFrom(30);
    
    // 40살 남자 생성
    Human manFourty = Human.of(40,gender);
}

위의 예와 같이, 정적 팩터리 메서드인 maleFrom과 femaleFrom을 통하여 어떤 성별을 가진 객체가 반환될 것인지 쉽게 묘사가 가능하다.

2. 호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다.

불변 클래스(immutable class)는 인스턴스를 미리 만들어 놓고나 새로 생성한 인스턴스를 캐싱하여 재활용하는 식으로 불필요한 객체 생성을 피할 수 있다. 이는 같은 객체가 자주 요청되는 상황에서 성능 향상을 기대할 수 있다.

public class DefaultDataBody {

   private static DefaultDataBody instance = new DefaultDataBody(0,new byte[0]);
   
   private Integer byteLength;
   private byte[] byteData;
   
   private DefaultDataBody(Integer byteLength, byte[] byteData) {
      this.byteLength = byteLength;
      this.byteData = byteData;
   }
   
   public static DefaultDataBody getInstance() {
      return instance;
   }
   
}

private void sendDefaultData(DataBlockHead head) {
   send(head, DefaultDataBody.getInstance());
}

이 코드는 이전 프로젝트를 참고하여 간략화한 Legacy 코드이다. body가 비어있는 응답을 보낼 경우, 계속해서 객체를 생성하는 것이 아닌 정적 팩터리 메서드(getInstance)를 통해 하나의 인스턴스를 재활용하고 있다.

이처럼, 반복되는 요청에 같은 객체를 반환하는 식으로 정적 팩터리 방식의 클래스는 언제 어느 인스턴스를 살아 있게 할지를 통제할 수 있다. 이를 인스턴스 통제(Instance-Controlled) 클래스라고 한다.

인스턴스를 통제하면 좋은 점은

싱글턴(singleton)으로 만들 수 있다.
인스턴스화 불가(noninstantiable)로 만들 수 있다.
불변 값 클래스에서 동치인 인스턴스가 하나뿐임을 보장할 수 있다.

이는, Flyweight Pattern의 근간이 된다.

3. 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.

이는 반환할 객체의 클래스를 자유롭게 선택할 수 있게 하는 '엄청난 유연성'을 제공한다.

public interface HmgBrand {
	
   public static HmgBrand getHyunDai(){
      return new HyunDai();
   }
    
   public static HmgBrand getKia(){
      return new Kia();
   }

   public static HmgBrand getGenesis(){
      return new Genesis();
   }
}

public class HyunDai implements HmgBrand {
}

public class Kia implements HmgBrand {
}

public class Genesis implements HmgBrand {
}

자바 8 전에는 인터페이스에 정적 메서드를 선언할 수 없어 java.util.Collections와 같이 인스턴스화 불가인 동반 클래스(Companion class)를 만들어 정의하는 것이 관례였다. 하지만, 자바 8 부터는 인터페이스가 정적 메서드를 가질 수 있어 인터페이스 만으로 하위 타입의 객체를 반환할 수 있게 되었다.

4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환 할 수 있다.

반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관 없다.

public interface Human {
   public static Human getHuman(String gender, Integer age) {
      return age<20 ? new Child(gender,age) : new Adult(gender, age);
   }
}

public class Child implements Human {
   String gender;
   String age;
   
   public Child(String gender, String age) {
      this.gender = gender;
      this.age = age;
   }
}

public class Adult implements Human {
   String gender;
   String age;
   
   public Adult(String gender, String age) {
      this.gender = gender;
      this.age = age;
   }
}

5. 정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.

이는 서비스 제공자 프레임워크(service provider framework)를 만드는 근간이 된다. 대표적인 서비스 제공자 프레임워크로 JDBC(Java Database Connectivity)가 있다.

서비스 제공자 프레임워크에서 제공자(provider)는 서비스 구현체이다. 그리고 이 구현체들을 클라이언트에 제공하는 역할을 프레임워크가 통제하여, 클라이언트를 구현체로부터 분리해준다.

서비스 제공자 프레임워크는 3개의 핵심 컴포넌트로 이루워진다.

구현체의 동작을 정의하는 서비스 인터페이스(service interface) - JDBC에서 Connection
제공자가 구현체를 등록할 때 사용하는 제공자 등록 API(provider registration API) - DriverManager.registerDriver
클라이언트가 서비스의 인스턴스를 얻을 때 사용하는 서비스 접근 API(service access API) - DriverManager.getConnection

// 서비스 인터페이스
public interface Connection {
   // SQL Statements Function ...
}

// 서비스 제공자 인터페이스
public interface Driver {
    String getDriverName();
    Connection getConnection();
}

public class DriverManager {

    static final Map<String,Driver> registeredDriver = new HashMap<>();
    
    // 제공자 등록 API
    public static void registerDriver(Driver driver) {
        registeredDriver.put(driver.getDriverName(), driver);
    }

	// 서비스 접근 API
    public static Connection getConnection(String driverName) {
        Driver driver = registeredDriver.get(driverName);
        return driver.getConnection();
    }
}

public static void main(String[] args) {
   Connection conn = DriverManager.getConnection("mySql");
   conn.deleteQuery("DELETE FROM table");
   conn.commit();

}

[Redis] Redis Cluster

다본죽 — Thu, 27 Jul 2023 10:52:59 +0900

[Redis] Redis Cluster

들어가기 전에..

최근 Redis에 대해 정리를 하다보니 Redis Cluster에 대한 정리까지 하면 기본적인 이론은 마무리할 수 있을 거 같아 하는김에 Redis Cluster까지 정리하기로 했다..

Redis Cluster

Cluster란 여러 대의 서버를 하나로 묶어 1개의 시스템처럼 동작하게 만드는 것이다. 그래서 여러 대의 서버에 데이터를 분산하여 저장하기 때문에 1대의 서버 부하를 여러 대로 분산시키므로 더 빠른 속도로 사용자에게 서비스를 제공할 수 있다.

또한, 특정 서버가 장애가 발생하면 다른 서버로 연결하여 서비스 중단과 데이터의 손실 없이 계속해서 사용자에게 서비스를 제공할 수 있다.

Redis Sharding(샤딩)

Redis는 Single Thread이기 때문에 데이터의 양이 많아지면 심각한 장애가 발생할 수 있다.

이러한 문제를 해결하기 위해 1개의 테이블의 데이터를 물리적으로 여러 파티션으로 나누어 저장하여 조회,저장,삭제 등 성능을 크게 향상 시키는 방법을 수평적 파티셔닝(Horizontal Partitioning) 또는 샤딩(Sharding)이라고 한다.

Redis Cluster의 구성 방법

1. Master로만 구성된 Cluster

위 그림과 같이 3개의 Master로 구성하면 데이터가 저장될 때 마다 M1,M2,M3으로 순차적으로 변경되어 저장된다.

2. Master와 Slave로 구성되어 있는 Cluster

Master로만 구성된 클러스터는 Master 중 1대의 Node만이라도 장애가 발생하면 서비스 중단과 데이터 손실이 일어날 수 있다.

따라서, Master와 Slave를 같이 구축해야 된다.

Master와 Slave 서버로 구성되어 있는 클러스로 구성하면 Master Node에 있는 데이터를 복제하여 가지고 있으므로 Master Node가 장애가 발생하더라도 Slave Node가 Master Node로 승격하여 중단없이 사용자에게 서비스를 제공할 수 있다.

정리

Redis Cluster는 Master를 여러 개 두어 분상 저장이 가능(Sharding), Scale Out이 가능하다.
- Redis Cluster는 고성능과 확장성을 제공
하나의 Master에 여러 Slave를 둘 수 있다.
Master 1,2,3이 있다면 데이터는 그 중 하나에 저장되며, Client가 데이터 읽기를 요청 시 저장된 곳이 아닌 다른 Master에 요청했다면 저장된 Master의 정보를 알려주며, Client는 전달받은 Master 정보에 다시 요청해서 데이터를 받아와야 한다.

[배포] 무중단 배포와 배포 전략

다본죽 — Tue, 25 Jul 2023 13:57:50 +0900

무중단 배포와 배포 전략

들어가기 앞서..

최근 쿠버네티스 기초 다지기 3/e 책을 읽기 시작했다. 분명 책이 기초 다지기인데.. 너무 어렵다...(왜 쿠베 생태계를 섭렵한 백엔드 개발자가 몸값이 높은지를 알겠다..)

이제는 책에 대한 내용 정리는 따로 안하려고 했지만.. 너무 내용이 어렵고 모르는 용어도 많이 나와서 예외로 모르는 용어들에 대한 정리나 쿠버네티스에 관한 정리도 따로 해야겠다는 생각이 들었다.

실제로 실무에서 쿠버네티스를 사용하고 있고(내가 관리하고 있지는 않지만..) 처음에는 완벽한 무중단 배포가 아니어서 배포할 때마다 트래픽이 가라앉는 걸 경험했다. 지금은 헬스 체크와 쿠버네티스 pod 교체 시간을 좀 늘리니 트래픽이 가라앉는 양상은 보이질 않고 있지만 내가 배포를 하는 것이 아니니 배포 방식에 대해 알 수가 없었다.

아무래도 쿠버네티스 책을 보면서 무중단 배포와 배포 전략에 대해서는 계속해서 나올 거 같아서 정리 한 번 하는게 좋겠다고 생각이 들었다.

중단 배포 방식과 다운타임

서버 한대로 서비스를 운영하고 있다고 가정하면, 현재 서버에는 V1 버전이 실행되고 있다. 그리고 이번에 새로운 기능들과 V1에서 발견된 버그/결함을 수정한 V2 버전을 개발 완료하였다. 이제 사용자들이 새로운 버전인 V2를 사용하도록 배포해야한다.

배포를 하려면 어떤 과정을 거치게 될까? 먼저, 새로운 V2 버전 빌드를 서버에서 다운로드를 받아야 한다. V1과 V2는 같은 Port를 사용하므로 V2 버전을 실행시키기 전에 V1 프로세스를 종료시켜야 한다. 이 시점 부터 사용자들은 서비스를 이용할 수 없게 된다. 이제 사용자가 사용할 수 있는 V2 빌드를 실행하고 로딩 과정을 거쳐 안정적으로 실행되면 다시 사용자가 정상적으로 서비스를 이용할 수 있게 된다.

앞서 말한 배포방식을 중단 배포라고 하며, V1 버전이 종료되고 V2 버전이 실행되는 사이(사용자가 서비스를 사용할 수 없는 시간)을 다운타임(Downtime)이라고 한다.

무중단 배포(Zero-downtime Deployment)

무중단 배포는 말 그대로 서비스가 중단되지 않은 상태로 새로운 버전을 사용자에게 배포하는 것을 의미한다. 무중단 배포를 위해서는 최소 서버가 2개 이상 확보되어야한다.

롤링 배포(Rolling)

Rolling 배포는 서버를 한 대씩 구버전에서 새 버전으로 교체해가는 전략이다. 서비스 중인 서버 한 대를 제외시키고 그 자리에 새 버전의 서버를 추가한다. 이렇게 구 버전에서 새 버전으로 트래픽을 점진적으로 전환한다. 이와 같은 방식은 서버 수의 제약이 있을 경우 유용하나 배포 중 인스턴스의 수가 감소되므로 서버 처리 용량을 미리 고려해야 한다.

장점

롤링 방식은 k8s, elastic beanstalk과 같은 많은 오케스트레이션 도구에서 지원하여 간편하다. 또한, 많은 서버 자원 확보하지 않아도 무중단 배포가 가능하다.

점진적으로 새로운 버전이 출시되므로, 배포로 인한 위험성이 다소 줄어들 수 있다.

단점

배포 도중 서비스 중인 인스턴스의 수가 줄어들어 각각의 서버가 부담하는 트래픽의 양이 늘어날 수 있다. 따라서 전체적인 트래픽 양과 단일 서버가 처리할 수 있는 트래픽의 양을 잘 파악하여 배포를 진행해야 한다.

또한, 구 버전과 신 버전의 어플리케이션이 동시에 서비스되기 때문에 호환성 문제가 발생할 수 있다.

블루/그린 배포(Blue/Green)

Blue/Green 배포는 구 버전에서 신 버전으로 일제히 전환하는 전략이다. 구 번의 서버와 신 버전의 서버들을 동시에 나란히 구성하고 배포 시점이 되면 트래픽을 일제히 전환시킨다.

장점

롤링 배포와 달리 한번에 트래픽을 모두 새로운 버전으로 옮기기 때문에 호환성 문제가 발생하지 않는다. 또한, 빠른 롤백이 가능하다

단점

실제 운영에 필요한 서버 리소스 대비 2배의 리소스를 확보해야한다. 클라우드 환경에서 운영한다면 필요없는 인스턴스는 제거하면 그만이지만, 온프레미스 방식으로 서비스를 운영했다면 비용 부담이 크다.

카나리 배포(Canary)

Canary 배포는 위험을 빠르게 감지할 수 있는 배포 방법이다. 점진적으로 구 버전에 대한 트래픽을 새 버전으로 옮기는 것은 롤링 방식이랑 비슷하나 Canary 배포의 핵심은 새로운 버전에 대한 오류를 조기에 감지하는 것이다.

소수 인원에 대해서만 트래픽을 새로운 버전으로 옮겨둔 상태에서 서비스를 운영하고 새로운 버전에 이상이 없다고 판단하였을 경우에 모든 트래픽을 신규 버전으로 옮긴다.

장점

새로운 버전으로 인한 위험을 최소화 할 수 있다. 또한, 오류율 및 성능 모니터링에 유용하다.

단점

롤링 배포와 마찬가지로 구 버전과 신 버전의 어플리케이션이 동시에 존재하므로 호환성 문제가 발생할 수 있다.

마치며 ..

지금 실무에서 사용하는 방식은 롤링 배포 전략인 거 같다. pod가 총 10개이며 헬스 체크가 끝나면 텀을 두고 구 버전 pod와 신 버전 pod를 하나씩 교체하면서 배포를 진행하고 있다.

배포 시 마다 모든 Pod가 교체되기 전에 롤링 방식의 단점인 구 버전과 신 버전의 호환성 문제가 발생하여 정확한 분석은 모든 pod교체 된후(배포 작업이 끝난 후)에 진행하고 있는데 그 이유도 이제는 알게 되었다.

[참조]

https://onlywis.tistory.com/

https://hudi.blog/

https://may9noy.tistory.com/

[Redis] 캐시(Cache) 설계 전략

다본죽 — Mon, 24 Jul 2023 17:10:30 +0900

Redis 캐시(Cache) 설계 전략

본 포스트에 앞서..

지난 포스트에서 Redis에 대한 정리를 하는 이유를 다시 복기하자면,

`유저가 많아진 게시판 웹페이지의 첫페이지가 항상 느린데 이유가 무엇인가? 성능 개선 방법은 무엇인가?`

에 대한 대답을 찾기 위해서였다.

이 포스트에서 Redis 설계 전략을 알아보고 저 질문에 대한 내 생각을 적어보려고 한다.

Redis - 캐시(Cache) 전략

캐싱 전략은 웹 서비스 환경에서 시스템 성능 향상을 기대할 수 있는 중요한 기술이다.

캐싱 전략을 구현할 때 고려해야 할 점 중 하나는 캐시 데이터의 수명이다.

캐시는 메모리를 사용하기 때문에 RDM보다 훨씬 빠르다. 하지만 용량이 작아 모든 데이터를 지우지 않고 캐시 저장소에 저장하면 용량 부족 현상으로 인해 시스템이 다운될 수 있다.

그러므로 캐시 만료 정책을 적절하게 설정하고 사용할 것인지가 중요하다.

캐싱 전략 패턴 종류

캐시를 이용하게 되면 반드시 닥쳐오는 문제점이 바로 데이터 정합성이다.

데이터 정합성 문제란, 캐시 저장소(Redis)에 있는 데이터와 DB에 있는 데이터가 다른 경우이다.

캐시를 사용하기 전에는 DB에서만 데이터 조회/수정을 했기 때문에 데이터 정합성 문제가 나타나지 않지만, 캐시를 사용하면 또 다른 데이터 저장소가 생기기 때문에 주 저장소에 저장된 값이 서로 다를 수 있는 현상이 일어날수 밖에 없다.

이를 위해 적절한 캐시 일기 전략(Read Cache Strategy)과 캐시 쓰기 전략(Write Cache Strategy)을 통해, 캐시와 DB 간의 데이터 불일치 문제를 극복하면서도 빠른 성능을 잃지 않도록 해야한다.

캐시 읽기 전략(Read Cache Strategy)

Look Aside 패턴

Cache Aside 패턴이라고도 불림.
데이터를 찾을 때 우선 캐시에 저장된 데이터가 있는지 우선적으로 확인하는 전략.
캐시가 없다면 DB에서 조회.
반복적인 읽기가 많을 때 적합.
캐시와 DB가 분리되어 가용.
- 원하는 데이터만 별도 구성하여 캐시에 저장.
- 캐시 서버가 장애나도 DB에서 데이터를 가져올 수 있어 캐시 장애 대비 구성이 되어있음.
- 단, 캐시에 붙어있는 Connection이 많았다면 캐시 서버 장애 시 다운된 순간 DB로 몰려 부하 발생.

1. Client에서 서버에 데이터 요청
2. Server는 Cache에 해당 데이터가 있는지 확인
3. 데이터가 존재하면 서버에 전달 (Cache Hit)
4. 데이터가 없으면 DB에서 조회 (Cache Miss)
6. Cache에 DB에서 조회해 온 데이터 업데이트
7. Client에게 데이터 응답

Look Aside 패턴은 애플리케이션에서 일반적으로 사용되는 기본적인 캐시 전략.
Cache Store와 DB 간의 정합성 유지가 발생 할 수 있으며, 초기 조회 시 무조건 DB를 호출해야 하므로 단건 호출 빈도가 높은 서비스에서는 적합하지 않음.
대신, 반복적인 동일 쿼리를 수행하는 서비스에 적합한 아키텍쳐.
이런 경우, DB에서 캐시로 데이터를 미리 넣어주는 작업을 하기도 하는데 이를 Cache Warming이라고 함.

[Cache Warming]

Cache Warming은 미리 Cache로 데이터를 넣어두는 작업을 의미한다.
이 작업을 수행하지 않으면 서비스 초기 트래픽 급증시 대량의 cache miss가 발생하여 DB의 부하가 급증할 수 있다(Thundering Herd).
다만, 캐시는 메모리를 사용하여 용량이 매우 작으므로 데이터를 무한정으로 가지고 있을 수 없어 일정시간이 지나면 expire가 되어 다시 Thundergin Herd가 발생 할 수 있다.
따라서, TTL을 잘 조정해야 할 필요가 있다.(뒤에서 설명)

Thundering Herd는 모든 지점에서 발생하는 것은 아니고, 서비스 첫 페이지와 같은 대부분 조회가 몰리는 지점에서 주로 발생한다.

Read Through 패턴

캐시에서만 데이터를 읽어오는 전략(inline cache).
Look Aside와 비슷하지만 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임하는 방식이라는 차이가 있음.
따라서 데이터 조회에 있어 전체적으로 속도가 느림.
데이터 조회를 전적으로 캐시에만 의존하므로, 캐시 서버가 죽으면 서비스에 문제가 생길 수 있음.
캐시와 DB 간 데이터 동기화가 지속적으로 이루어지므로 데이터 정합성 문제에서는 벗어날 수 있음.
읽기가 많은 워크로드에 적합

1. Client에서 서버에 데이터 요청
2. Server는 Cache에 해당 데이터가 있는지 확인, 데이터가 있으면 서버에 데이터 전달(Cache Hit)
3,4. 데이터가 없으면 캐시에서 DB에 조회 후 자체 업데이트(Cache Miss)
5. 데이터를 서버에 전달
6. Client에게 데이터 응답

Look Aside 패턴과 차이점은 캐시에 저장하는 주체가 서버가 아닌 DB 자체임.
직접적인 DB 접근은 최소화하고 Read에 대한 소모되는 자원을 최소화 할 수 있음.
캐시 서버가 죽으면 서비스 전체가 영향이 있으므로 Replication 또는 Cluster로 구성하여 가용성을 높여야 함.
이 방식 또한, Cache Warming을 해주는 것이 좋음.

캐시 쓰기 전략(Write Cache Strategy)

Write Back 패턴

Write behind 패턴이라고도 불림.
캐시와 DB 동기화를 비동기하기 때문에 동기화 과정이 생략.
데이터를 저장할 때 DB에 바로 쿼리하지 않고, 캐시에 모아서 일정 주기로 배치 작업을 통해 DB에 반영.
캐시에 모아놨다가 DB에 쓰기 때문에 쓰기 쿼리 회수 비용과 부하를 줄일 수 있음.
Write가 빈번하면서 Read를 하는데 많은 양의 Resource가 소모되는 서비스에 적합
데이터 정합성 확보
자주 사용되지 않는 불필요한 리소스 저장.
캐시에서 오류가 발생하면 데이터 영구 손실.

1. Client가 데이터 업데이트 요청을 한다.
2. 모든 데이터를 Cache에 저장한다.
3. 일정 시간 뒤 DB에 모두 업데이트한다.

Write Back 방식은 데이터를 저장할 때, DB가 아닌 먼저 캐시에 저장
캐시에 모인 데이터를 특정 시점마다 DB로 쓰는 방식
Cache가 일종의 Queue 역할.
캐시에 데이터를 모았다가 한 번에 DB에 저장하기 때문에 DB 쓰기 횟수 비용과 부하를 줄일 수 있음.
데이터를 옮기기 전 Cache 서버가 죽으면 데이터가 유실되지만 반대로 DB가 죽어도 지속적인 서비스 제공 가능.
캐시에 Replication이나 Cluster 구조를 적용함으로써 캐시 서비스의 가용성을 높이는 것이 좋으며, 캐시 읽기 전략인 Read-Through와 결합하면 가장 최근에 업데이트된 데이터를 항상 캐시에서 사용할 수 있는 혼합 워크로드에 적합.

Write Through 패턴

데이터베이스와 Cache에 동시에 데이터를 저장하는 전략.
데이터를 저장할 때 먼저 캐시에 저장한 다음 DB에 저장(모아놓았다 저장하는 것이 아닌 바로 저장).
Read Through와 마찬가지로 DB 동기화 작업을 Cache에 위임.
DB와 캐시가 항상 동기화 되어있어, 캐시의 데이터는 항상 최신의 상태로 유지.
캐시와 백업 저장소에 업데이트를 같이 하여 데이터 일관성을 유지할 수 있어서 안정적.
데이터 유실이 발생하면 안되는 상황에 적합.
자주 사용되지 않은 불필요한 리소스 저장.
매 요청마다 두번의 Write가 발생하게 됨으로써 빈번한 생성/수정이 발생하는 서비스에서는 성능 이슈 발생.
기억장치 속도가 느릴 경우, 데이터를 기록할 때 CPU가 대기하는 시간이 필요하기 때문에 성능 감소.

Write Through 패턴은 Cache에도 반영하고 DB에도 동시에 반영하는 방식.
그래서 항상 동기화되어 있는 최신의 버전을 가지고 있음.
하지만, 결국 2단계 과정을 거쳐야하기 때문에 상대적으로 느리고, 무조건 일단 캐시에 저장하기 때문에 캐시에 넣은 데이터를 저장만하고 사용하지 않을 가능성이 있어 리소스 낭비 가능성이 있음.

Write Through와 Write Back 패턴 모두 둘 다 자주 사용되지 않은 데이터가 저장되어 리소스 낭비가 발생하는 문제점이 있다. 이를 해결하기 위해 TTL을 꼭 사용하여 사용되지 않는 데이터는 반드시 삭제해줘야 한다.

Write Around 패턴

Write Through보다 훨씬 빠름.
모든 데이터는 DB에 저장(캐시를 갱신하지 않음).
Cache Miss가 발생하는 경우에만 DB와 캐시에도 데이터를 저장.
따라서 캐시와 DB 내의 데이터가 다를 수 있음(데이터 불일치).

1. Client에서 데이터 업데이트를 요청한다.
2. 모든 데이터는 DB에 저장한다.

Write Around 패턴은 속도가 빠르지만, Cache Miss가 발생하기 전 DB에 저장된 데이터가 수정되었을 경우, 사용자가 조회하는 캐시와 DB 간의 데이터 불일치가 발생
따라서, 저장된 데이터가 수정/삭제될 때 마다, 캐시 또한 삭제하거나 변경해야 하며, 캐시의 expire를 짧게 조정하는 식으로 대처해야 함.
Write Around 패턴은 주로 Look Aside, Read Through와 결해서 사용하며, 데이터가 한 번 쓰여지고, 덜 자주 읽히거나 읽지 않는 상황에서 좋은 성능을 제공함.

캐시 읽기 + 쓰기 전략 조합

Look Aside + Write Around 조합

가장 일반적으로 자주 쓰이는 조합

Read Through + Write Around 조합

항상 DB에 쓰고, 캐시에서 읽을 때 항상 DB에서 먼저 읽어오므로 데이터 정합성 이슈에 대한 완벽한 안전 장치를 구성할 수 있음

Read Through + Write Through 조합

데이터를 쓸 때 항상 캐시에 먼저 쓰므로, 읽어올 때 최신 캐시 데이터 보장
데이터를 쓸 때 항상 캐시에서 DB로 보내므로, 데이터 정합성 보장

TTL(Time To Live)

TTL은 Key가 자연스럽게 만료되어 없어지게 하는 시간(Redis의 경우 Integer 당 1ms)이다. 각 전략에 TTL을 추가하면 이득을 취할 수 있다.

Look Aside : 자연스럽게 값이 삭제되어 캐시 미스가 발생하고 최신의 값을 유지 가능.
Write Through : 업데이트가 되지 않은 데이터를 자동 삭제하여 메모리 이득을 볼 수 있음.

Cache Stampede 현상

대규모 트래픽 환경에서 TTL 값이 너무 작게 설정되면 Cache Stampede 현상이 발생할 가능성이 있다.

Look-aside 패턴에서 redis에 데이터가 없다는 응답을 받은 서버(Cache Miss)가 직접 DB로 데이터 요청한 뒤, 다시 redis에 저장하는 과정을 거친다.

그런데 위 상황에서 key가 만료되는 순간 많은 서버에서 이 key를 같이 보고 있었다면 모든 어플리케이션 서버에서 DB로 가서 찾게 되는 duplicate read 가 발생한다.

또 읽어온 값을 각 각 redis에 쓰는 duplicate write 도 발생되어, 처리량도 다 같이 느려질 뿐 아니라 불필요한 작업이 굉장히 늘어나 요청양 폭주로 장애로 이어질 가능성 도 있다.

캐시 공유 방식 지침

캐시는 어플리케이션의 여러 인스턴스에서 공유하도록 설계 된다.

그래서 각 어플리케이션 인스턴스가 캐시에서 데이터를 읽고 수정할 수 있다.

따라서 한 어플리케이션이 캐시에 보유하고 있는 데이터를 수정하는 경우, 다른 어플리케이션의 인스턴스가 변경을 덮어쓰지 않도록 해야한다. 그렇지 않으면 데이터 정합성 문제가 발생한다.

데이터의 충돌을 방지하기 위해 다음과 같은 어플리케이션 개발 방식을 취해야 한다.

캐시 데이터를 변경하기 직전에 데이터가 검색된 이후 변경되지 않았는지 일일히 확인하는 방법
- 변경하지 않았다면 즉시 업데이트
- 변경되었다면 업데이트 여부를 어플리케이션 레벨에서 결정
- 업데이트가 드믈고 충돌이 발생하지 않는 상황에서 적용하기 용이
캐시 데이터를 업데이트 하기 전 Lock을 잡는 방법
- 조회성 업무를 처리하는 서비스에 Lock으로 인한 대기현상이 발생.
- 데이터의 사이즈가 작아 빠르게 업데이트가 가능한 업무와 빈번한 업데이트가 발생하는 상황에 적용하기 용이

마치며..

이제 캐시에 대한 정리를 마치며 마지막으로

`유저가 많아진 게시판 웹페이지의 첫페이지가 항상 느린데 이유가 무엇인가? 성능 개선 방법은 무엇인가?`

에 대한 나의 대답을 정리한 Redis, 캐시 개념을 가지고 내려보면 다음과 같다.

먼저, 유저가 많아진 게시판 웹페이지의 '첫'페이지가 항상 느린 이유에 대한 대답은 Thundering Herd 때문이다. Thundering Herd는 대부분의 조회가 이루어지는 서비스 첫 페이지 같은 곳에서 발생한다. 이를 해결하기 위해 Cache Warming을 해주어야 한다. Cache Warming이란, 초기에 미리 DB에 있는 데이터를 캐시에 넣어주는 것이다.

추가로 빈번하게 업데이트가 되는 게시물의 '좋아요' 등은 캐시 쓰기 전략의 Write Back 패턴을 사용하여 캐시에 데이터를 저장해놓았다가 일정 시간이 되면 한번에 DB에 저장하는 방식을 사용하면 성능 개선을 할 수 있다.

물론, 이 질문의 대한 나의 대답이 틀릴 수도 있다. 혹은 성능 개선에 대한 더 좋은 방법이 있을 수도 있다..

향후에 내가 실제로 실무에서 Redis를 사용하게 되어 같은 상황을 마주하고 다른 방식으로 해결한다면 그 때 어떻게 해결했는지 포스팅을 해봐야겠다.

참고

https://inpa.tistory.com/entry/

https://velog.io/@jinmin2216/

https://sabarada.tistory.com/

[리뷰] 테스트 주도 개발 시작하기

다본죽 — Thu, 20 Jul 2023 21:38:48 +0900

[리뷰] 테스트 주도 개발 시작하기

실무에서 개발을 하다보니 테스트가 중요한 지를 깨달았다. 특히 이번 프로젝트처럼 규모가 어느정도 되는 시스템일 경우는 더더욱 중요한 걸 느꼈다.

내가 맡은 서버가 단말 중개 서버(Bridge)였기 대부분의 인입이 프로토콜의 형태로 들어왔고, 비즈니스 로직도 커서 개발하면서 테스트를 진행하는 건 꿈도 못꾸고 있었다.

그렇다 보니 유닛 테스트 부터 통합 테스트까지 제대로 검증을 못한 채로 필드 테스트를 진행했다. 결과는 역시나 .. 여기 저기서 에러가 뻥뻥 터지고 수정하고 터지고 수정하고 오픈까지 이 일의 연속이었다...

그 때 난 이런 생각을 했다.

`이런 시스템은 테스트를 어떻게 하지? 개발하면서 테스트를 충분히 했다면 좀 더 수월하지 않았을까? 내가 다시 돌아간다면 어떻게 테스트를 할 수 있을까?`

그래서 프로젝트를 오픈하고 가장 먼저 집어 든 책이 바로 이 책이다.

리뷰

서론이 길었다. 본격적으로 이 책을 리뷰하자면, 먼저 나는 나같은 주니어에게는 `강추`이다.

물론 TDD에 대해서 모르는 사람은 없을 것이다. 그러나 어떻게 하는 건지 아는 사람은 많이 없을 것이다.

내가 그랬다...

'TDD는 테스트 주도 개발로 테스트 코드를 먼저 짜고 기능을 개발하는 거야! 나도 요즘 트렌드에 맞게 TDD 개발 해봐야겠다!!(IntelliJ를 키고 스프링 부트 프로젝트를 만든 다음 테스트 폴더에 클래스를 하나 일단 만든다.) 음.. 근데 그걸 어떻게 하지? 기능이 없는데 테스트를? 이게 뭔 소리지?'

이게 나의 모습이었다.

이 책은 나에게 시작도 못하던 TDD를 시작할 수 있게 해주는 가이드를 해주었다.

내가 TDD를 시작하지 못했던, 만들어 놓은 코드가 없는데 테스트를 하는 지, 어떤 거 부터 시작하는지 자세하게 알려준다.

아래는 이 책에서 말하는 TDD 절차(방법)이다.

TDD 절차

테스트할 대상과 케이스 선택
해당 테스트에 대한 테스트 케이스 코드 작성
컴파일 오류를 없애는데 필요한 클래스와 메소드 등을 추가한다.
테스트가 통과되도록 구현한다.(처음엔 하드 코딩 등)
4번에서 구현한(하드 코딩 등) 목록을 일반화(구체적으로)하여 구현한다.
테스트를 통과했다면 5번의 코드를 리팩토링 요소를 찾아 리팩토링을 한다.
모든 테스트가 통과하는지 확인한다.
새로운 케이스를 선정 후 반복하여 점진적으로 코드를 완성해 나간다.

여기까지 보면 정말 간단하고 쉽게 시작이 가능하다.

그러나, 내가 이걸 보면서 생각하는 게 있었다.

'아 시작은 이제 어떻게 하는지 알겠는데.. 내가 진행한 프로젝트는 DB작업도 많고, 외부 연동도 많고, 얽히고 설킨게 많은데 이게 가능한거야? 실제 실무에서 사용하려면 어떻게 해야하는거지?'

신기하게도 이런 생각하면서 의심 반, 걱정 반 하며 읽을 때 쯤 필자가 먼저 얘기를 꺼낸다.

`실제로 실무에서는 외부 연동이나 DB Connection 등 테스트하기 힘들게 만드는 외부 요소들이 존재한다. 이럴 때는 '대역'을 사용한다`

대역에는 스텁(Stub), 가짜(Fake), 스파이(Spy), 모의(Mock)이 있다.

이를 사용하여 테스트가 힘든 외부 요인이나 결과를 대체한다. 하지만, 대역을 사용할 때 주의해야 하는 사항들이 존재한다.

모의 객체를 과하게 사용하면 오히려 테스트 코드가 복잡해질 수 있다.
결과 값을 확인하는 수단으로 모의 객체를 사용하면 결과 검증 코드가 길어지고 복잡해진다.
모의 객체는 기본적으로 메서드 호출 여부를 검증하는 수단이므로, 테스트 대상과 모의 객체 간의 상호 작용이 조금만 바뀌어도 테스트가 깨지기 쉽다.
DAO나 리포지토리와 같은 저장소에 대한 대역은 모의 객체보다 메모리를 이용한 가짜 구현을 사용하는 편이 코드의 간결성과 유지보수성에서 더 좋다.

여기까지는 TDD의 방법을 주로 다뤘으면 다음 장 부터는 테스트를 위한 설계 관점을 다룬다.

테스트를 위한 설계를 하기 위해서는 꽤 많은 부분을 신경써야한다.

테스트가 가능 설계는 다음과 같다.

하드 코딩된 상수를 생성자나 메서드 파라미터로 받는다.
의존 대상을 주입 받는다.
- 의존 대상은 생성자 주입으로 교체할 수 있도록 만든다.
- 의존 대상을 교체할 수 있게 되면 실제 구현 대신에 대역을 사용할 수 있어 테스트가 수월해진다.
테스트하고 싶은 코드를 분리한다.
- 기능의 일부만 테스트하고 싶은 경우, 해당 코드를 별도 기능으로 분리해서 테스트를 진행 할 수 있다.
시간이나 임의 값 생성 기능을 분리한다.
- 테스트 대상이 사용하는 시간이나 임의 값을 제공하는 기능을 별도로 분리해서 테스트 가능성을 높일 수 있다.
외부 라이브러리는 직접 사용하지 말고 감싸서 사용한다.

마지막으로 테스트 코드도 유지보수의 대상이다. 테스트 코드의 유지보수성을 높히기 위한 방법에 대해 소개한다.

이 책을 읽고 `그럼 이제 TDD 방법은 알았으니까 이제 실무에서 TDD를 적용해서 개발 할 수 있을까?` 라는 생각을 해보았을 때, 내 대답은 `흠.. 글쎄.. 간단한 거 정도는 해볼 수 있지 않을까?` 이다.

이런 생각을 한 나에게 이 책의 필자는 마지막에 이런 말을 한다.

`물론 100% TDD로 개발할 수는 없겠지만 할 수 있는 한 많은 범위를 TDD로 개발하는 것이 중요하다.`

`처음엔 쉬운 것을 TDD로 시도해서 TDD에 익숙해지고 이후에 점진적으로 TDD 적용 범위를 늘려나가자.`

필자의 말 처럼 모든 걸 TDD를 할 필요는 없다. 내가 가능한 간단한 거 정도로 부터 시작하면 언젠간 TDD가 주는 효과를 느낄 수 있지 않을까 싶다.

이 책에 대한 내용과 내 생각은 이 글 하나에 담기엔 역부족하다.

내용이 어렵지 않으니 나같은 주니어라면 기회되면 한번은 읽으면 좋을 거 같다.