자바에는 "Write Once, Run Anywhere", 줄여서 WORA라는 잘 알려진 슬로건이 있습니다.

한 번 작성한 코드가 어디서나 똑같이 동작한다는 뜻입니다. 자바 코드는 특정 OS에 맞춰 컴파일되지 않고 바이트코드라는 중간 형태로 컴파일되며, 이 바이트코드를 각 OS에 설치된 JVM이 해석해 실행합니다. OS마다 다른 부분은 JVM이 대신 처리하므로, 개발자는 코드를 한 번만 작성해도 Windows든 Linux든 macOS든 똑같이 동작할 것이라고 기대합니다.

이번 포스팅에서는 자바가 내세우는 WORA의 진정한 의미를 Thread.sleep() 의 사례로 짚어 보겠습니다.

이 포스팅은 Hotspot JVM을 기준으로 작성되었습니다.

1. Thread.sleep()

코드를 작성하다 보면 Thread.sleep()을 사용하는 일이 종종 있습니다.

1. 외부 API 호출이 실패했을 때 간격을 두고 재시도
2. 작업이 끝났는지 일정 간격으로 폴링
3. 요청 사이에 간격을 두어 요청 속도를 제한
4. 비동기 결과를 기다리는 테스트를 작성할 때(권장되지는 않습니다)

// 재시도 사이에 100ms 간격을 둘 때
for (int attempt = 0; attempt < MAX_RETRY; attempt++) {
    if (callExternalApi()) break;
    Thread.sleep(100);
}

// 조건이 만족될 때까지 50ms 간격으로 폴링할 때
while (!job.isDone()) {
    Thread.sleep(50);
}

Thread.sleep(100)을 호출하면 우리는 보통 "100ms 뒤에 다시 실행되겠지"라고 생각합니다.

그런데 정말 우리가 지정한 시간만큼 스레드의 실행이 멈출까요?

2. 같은 코드, 다른 결과

다음은 10ms씩 1,000번 실행을 멈췄다가 재개하는 동작을 반복하면서, 전체 시간이 얼마나 걸리는지 측정하는 간단한 벤치마크입니다.

public class SleepBenchmark {
    public static void main(String[] args) {
        final int iterations = 1_000;

        long start = System.nanoTime();
        for (int i = 0; i < iterations; i++) {
            try {
                Thread.sleep(10); // 10ms씩 멈추면 합계는 10초가 나와야 정상
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
        long elapsedMs = (System.nanoTime() - start) / 1_000_000;

        System.out.printf("총 소요: %d ms%n", elapsedMs);
        System.out.printf("sleep 1회 평균: %.2f ms%n", elapsedMs / (double) iterations);
    }
}

이론대로라면 10ms × 1,000회 = 10,000ms, 즉 10초 정도면 끝나야 합니다.

그런데 실제로 실행해 보면 결과가 다릅니다.

Linux 환경에서 실험한 결과

총 소요: 10125 ms
sleep 1회 평균: 10.13 ms

Windows 환경에서 실험한 결과

총 소요: 15944 ms
sleep 1회 평균: 15.94 ms

똑같은 바이트코드인데 OS가 달라졌다는 이유만으로 실행 시간이 달랐습니다. 앞에서 설명한 WORA의 기대와 어긋나는 결과입니다.

참고 1: 구체적인 수치는 OS 버전, 하드웨어 설정 등에 따라 달라집니다. Windows도 설정 변경을 통해 차이를 줄일 수 있습니다. 중요한 것은 절대적인 수치가 아니라, OS에 따라 결과가 달라진다는 점입니다.

참고 2: Windows 환경에서 실행되는 Thread.sleep()은 매개변수로 받은 ms 가 10의 배수가 아닌 경우에는 OS 타이머 인터럽트 주기를 1ms로 조정한 후 sleep 을 시작합니다. 따라서, ms 가 10의 배수가 아닌 경우에는 Windows 와 Linux가 동일하게 동작합니다. 이번 포스팅에서는 OS에 따라 결과가 다르다는 예시를 보여드리기 위해 10ms 로 설정했습니다.

3. 원인은 OS의 타이머 인터럽트 주기

Thread.sleep()이 얼마나 정확한지는 자바가 정하지 않습니다. 자바는 OS에 "이만큼 멈췄다가 다시 실행해 달라"고 요청할 뿐이고, 실제로 언제 재개되는지는 OS 타이머 인터럽트 주기에 좌우됩니다.

타이머 인터럽트란?

인터럽트는 실행 중인 흐름을 잠시 멈추고 CPU 코어를 미리 정해진 처리 루틴으로 분기시키는 신호입니다. 실행 중인 스레드가 시스템 콜이나 예외로 스스로 커널에 진입하지 않는 한, OS가 그 스레드를 강제로 멈추려면 타이머 인터럽트 같은 신호가 필요합니다. 그래서 OS는 프로그래밍 가능한 하드웨어 타이머가 일정 간격으로 인터럽트를 발생시키도록 설정해 두고, 그 신호가 올 때마다 제어권을 돌려받아 시간 관리와 스케줄링 같은 일을 처리합니다. 이렇게 주기적으로 발생하는 인터럽트를 tick이라고 부릅니다.

tick이 발생하면 다음 작업이 수행됩니다.

• 실행 중이던 스레드가 잠시 멈추고 제어권이 커널로 넘어갑니다.
• 커널이 시스템 시간을 갱신하고, 만료된 타이머가 있는지 확인합니다.
• 대기 중인 스레드 중 재개 시점(sleep deadline)이 지난 것이 있으면 실행 대기열(런큐)로 옮겨 다시 실행될 수 있게 합니다.

Linux와 Windows의 타이머 인터럽트 주기는 다르다

Linux 보통 1~4ms 정도입니다. 다만 HotSpot은 sleep을 고해상도 타이머(hrtimer)로 처리하므로, 타이머 인터럽트 주기와 무관하게 요청한 시간과 거의 비슷하게 sleep 합니다. (실제로 tick이 4ms인 환경에서도 sleep(10)이 ~10ms로 정확했습니다.)

Windows 보통 15ms입니다. Thread.sleep(10)을 호출해도 다음 tick은 최대 15ms 뒤에야 옵니다. 그래서 10ms sleep을 호출해도 최대 16ms 정도 중단됩니다.

스레드 관점에서는 동일하게 실행을 멈췄을 뿐인데, 그 스레드를 다시 실행할지 점검하는 주기는 OS마다 다릅니다. JVM은 OS에 "이 스레드를 10ms 뒤에 다시 실행해 달라"고 요청할 뿐이고, 실제로 언제 재개할지는 OS가 자신의 타이머 인터럽트 주기에 맞춰 결정합니다.

4. JDK 문서

Thread.sleep()의 명세를 보면 표현이 조심스럽습니다.

현재 실행 중인 스레드의 실행을 지정된 밀리초 동안 일시 중단한다(temporarily cease execution). 단, 시스템 타이머와 스케줄러의 정밀도 및 정확도에 따른다(subject to the precision and accuracy of system timers and schedulers).

핵심은 "시스템 타이머와 스케줄러의 정밀도에 따른다"는 조건입니다.

명세가 보장하는 것은 "최소 N ms 이상 멈춘다"는 하한선뿐이고, 그보다 얼마나 더 멈춰 있을지는 OS의 타이머 인터럽트 주기에 달려 있습니다. 그래서 "정확히 N ms" 가 아니라 "적어도 N ms" 라는 최소한의 보장만 제공하는 것입니다.

Windows 환경에서 15ms 동안 멈춰 있던 것은 버그가 아니라 명세대로 동작한 결과입니다. "최소 10ms"라는 약속을 어긴 것은 아니기 때문입니다. 다만 우리가 "10ms를 요청하면 정확히 10ms일 것"이라고 기대했을 뿐입니다.

5. WORA가 보장하는 것과 보장하지 않는 것

JVM은 OS에 의존하는 영역(스레드 스케줄링, 타이머 정밀도, 파일 시스템 동작, 줄바꿈 문자, 시그널 처리)은 추상화하지 못합니다.

Thread.sleep(10)은 그 차이를 단적으로 드러내는 예시입니다. 한 줄의 코드가 OS에 따라 다르게 동작한다는 사실은, "한 번 작성하면 어디서나 실행된다"와 "어디서나 똑같이 동작한다"가 서로 다른 말임을 보여 줍니다.

WORA는 "바이트코드가 어디서나 실행된다"는 약속이지, "모든 실행 동작이 똑같다"는 약속은 아닙니다. JVM은 OS 위에서 동작하는 추상화 계층일 뿐 OS 자체를 대체하지는 못합니다. 그래서 OS 영역이 동작하는 지점에서는 차이가 생깁니다.

비슷한 사례

• 문자 인코딩

  • Java 18 이전에는 인코딩을 지정하지 않고 파일을 읽거나 쓰면 OS와 로케일에 따라 기본 charset이 달라졌습니다.
  • 이로 인해, 같은 코드라도 Linux(UTF-8)에서는 정상적으로 표시되던 한글이 Windows(MS949)에서는 깨지는 경우가 있었습니다.
  • 이 문제는 Java 18에서 기본 charset을 UTF-8로 통일하면서 해소되었습니다.

• GUI

  • Swing이나 AWT로 만든 화면은 폰트, DPI 처리, 적용한 룩앤필에 따라 OS마다 조금씩 다르게 보입니다.
  • 특히 플랫폼 네이티브 룩앤필을 사용하면 버튼이나 입력창이 각 OS의 기본 모양을 따르므로, 같은 레이아웃 코드라도 화면이 동일하지는 않습니다.
  
  

마무리

"Write Once, Run Anywhere"는 대체로 사실이고, 충분히 강력한 약속입니다. JVM이 책임지는 부분은 어느 OS에서나 동일하게 동작합니다.

문제는 OS나 하드웨어에 크게 종속되는 순간 발생합니다. Thread.sleep의 정밀도는 OS의 타이머 인터럽트 주기에 달려 있고, 기본 인코딩이나, 타임존, 파일 경로 규칙도 환경마다 다릅니다.

정리하면, WORA가 보장하는 계층은 바이트코드 실행과 언어 의미론까지입니다. OS나 하드웨어의 차이가 드러나는 영역에서는 같은 코드가 다른 결과를 낼 수 있습니다.

**"Write Once, Run Anywhere"는 "한 번 작성하면 어디서나 실행된다"는 뜻이지, "어디서나 똑같이 동작한다"는 뜻은 아닙니다. **

이번 글에서는 프레임워크 내부 코드를 탐구하다가 오픈소스 기여까지 이어지게 된 과정을 설명해드리려 합니다.

배경

블로그 설명에도 나와있지만, 저는 기술을 사용할 때 단순히 주어지는 대로 쓰기보다는, "이건 내부적으로 어떻게 동작할까?" 하고 그 원리를 파헤치고 탐구하는 것을 좋아합니다.

이런 성향 덕분에, 저는 Spring MVC의 내부 동작 원리에도 관심이 많았습니다.

Interceptor가 요청을 어떻게 가로채는지, DispatcherServlet이 어떻게 요청을 분배하는지, Controller의 메서드 파라미터로 어떻게 객체들이 바인딩되는지 종종 내부 코드를 열어보며 확인하곤 했습니다.

이러한 호기심으로 인해 우아한테크코스에서 같은 뜻을 가진 크루들과 "Spring 내부 코드 탐험 스터디"를 진행했고, 그 과정에서 HandlerMethodReturnValueHandlerComposite 이라는 클래스를 자세히 살펴보게 되었습니다.

이 클래스는 Controller(HandlerMethod)에서 반환된 객체를 지원하는 적절한 HandlerMethodReturnValueHandler 를 찾아 처리를 위임하는 역할을 합니다. 이때 분석했던 내용이 꽤 흥미로워서, 이를 주제로 테코톡 발표를 진행하기도 했습니다.

테코톡 발표 영상 링크 : https://youtu.be/JOLwv6Btayg?si=N2N019VSeGo3RL08

문제

몇 개월 후, 프로젝트를 진행하다 커스텀 Handler를 만드는 과정에서 HandlerMethodReturnValueHandlerComposite 내부 코드를 다시 읽다가 흥미로운 점을 발견했습니다.

코드를 다시 살펴본 이유는 이 클래스에 캐시를 도입해 보면 어떨까? 하는 생각 때문이었습니다.

🤔 배경지식

HandlerMethodReturnValueHandler 란 HandlerMethod(컨트롤러의 메서드)가 반환한 객체를 사용해 Http 응답을 구성하기 위해 사용하는 "응답 값 핸들러"입니다.

HandlerMethodReturnValueHandlerComposite 란 다양한 HandlerMethodReturnValueHandler를 하나의 묶음으로 구성해서, HandlerMethod(컨트롤러의 메서드)가 반환한 객체를 처리(Handle)할 수 있는 적절한 HandlerMethodReturnValueHandler를 탐색하고 호출합니다.

HandlerMethodReturnValueHandlerComposite 는 현재 반환된 객체를 처리할 수 있는 적절한 HandlerMethodReturnValueHandler를 찾기 위해 내부적으로 반복문을 돕니다.

@Nullable
private HandlerMethodReturnValueHandler getReturnValueHandler(MethodParameter returnType) {
    for (HandlerMethodReturnValueHandler handler : this.returnValueHandlers) {
        if (handler.supportsReturnType(returnType)) {
            return handler;
        }
    }
    return null;
}

매번 루프를 도는 대신 캐시를 도입한다면 큰 성능 최적화가 가능하지 않을까? 하는 호기심이 생겼습니다.

캐싱 로직을 추가해 볼 수 있는지 알아보기 위해 클래스를 자세히 살펴보기 시작했는데, 상단의 JavaDoc을 읽다가 의아한 부분을 발견했습니다.

/**
 * Handles method return values by delegating to a list of registered
 * {@link HandlerMethodReturnValueHandler HandlerMethodReturnValueHandlers}.
 * Previously resolved return types are cached for faster lookups.
 *
 * @author Rossen Stoyanchev
 * @since 3.1
 */
public class HandlerMethodReturnValueHandlerComposite implements HandlerMethodReturnValueHandler {

Javadoc 일부를 보면, Previously resolved return types are cached for faster lookups. 라는 설명이 존재합니다.

분명 코드 로직 상으로는 매번 루프를 돌며 Handler를 찾고 있었는데, JavaDoc에는 "이 클래스는 빠른 탐색을 위해 Handler를 캐싱한다"는 설명이 남아있었습니다.

코드와 주석의 내용이 일치하지 않는 이유를 찾기 위해 해당 클래스의 Git History를 거슬러 올라가 보았습니다.

그 과정에서, 2012년에 작성된 하나의 커밋을 발견했습니다.

문제의 커밋 : https://github.com/spring-projects/spring-framework/commit/cfe2af76906039e42b12dc24cf4fca7b91c9b910

내용을 살펴보니, 2012년 이전에는 실제로 캐싱 로직이 존재했습니다.

하지만 HandlerMethod가 반환한 객체의 내부 상태에 따라 분기 처리를 해야 하는 요구사항이 생기면서, 단순히 반환 타입만으로는 특정 Handler를 고정해서 캐싱할 수 없게 된 것입니다.

결국 캐싱 로직은 해당 커밋으로 인해 제거되었지만, Javadoc 주석은 함께 지워지지 않고 누락되어 있었습니다.

그리고 그 상태로 2012년부터 2026년인 지금까지 그대로 남아있었던 것입니다.

PR 제출

히스토리를 분석해 보니 그 Javadoc이 잘못되었다는 것을 파악했고, 실제 HandlerMethodReturnValueHandlerComposite의 동작과 일치하도록 수정하여 PR을 제출했습니다.

PR : https://github.com/spring-projects/spring-framework/pull/36555

머지

단순한 문서 수정이었기에 리뷰 과정은 비교적 짧게 끝났고, 제 PR은 Spring Framework의 7.0.7 마일스톤에 성공적으로 반영되어 머지되었습니다.

후기

거창한 코드 기여나 엄청난 성능 개선을 이룬 것은 아닙니다.

하지만 평소에 프레임워크의 내부 코드를 열어보고 원리를 궁금해하던 습관 덕분에, 오래된 문서 오류를 바로잡는 소소한 기여를 할 수 있었습니다.

이번 경험을 통해 멀게만 느껴졌던 오픈소스 생태계와의 심리적 거리가 한결 가까워졌고, 제 목표인 공통 플랫폼 개발자에 한 걸음 더 다가간 것 같아 뿌듯한 마음도 듭니다.

프로젝트를 진행하시다가 "이건 내부적으로 어떻게 돌아갈까?"라는 궁금증이 든다면, 라이브러리 코드를 슬쩍 열어보는건 어떨까요? 혹시 아시나요? 작은 궁금증이 오픈소스 기여로 이어질지도 모릅니다.

안녕하세요 머랭입니다. 지난 포스팅에선, InnoDB가 버퍼를 관리하기 위해 STEAL & No-FORCE 정책을 사용한다는 것을 알아보았습니다.

이번 포스팅에서는 No-FORCE 정책을 유지하면서, 동시에 Durability를 보장하기 위한 Redo Log와 WAL(Write-Ahead Logging)에 대해 설명드리겠습니다.

1. Redo Log

InnoDB는 랜덤 I/O를 최소화하기 위해, 트랜잭션이 커밋 이후에도 더티 페이지를 즉시 디스크에 반영하지 않고 버퍼에 보관하는 No-FORCE 정책을 사용합니다. 그러나, No-FORCE 정책은 Durability를 보장할 수 없다는 단점이 존재합니다.

InnoDB는 No-FORCE 정책을 사용하면서도 Durability를 보장하기 위해 Redo Log를 사용합니다. Redo Log는 페이지 내의 데이터 변경 기록을 기록하고, 추후 다시 수행될 수 있도록 하기 위해 존재하는 로그 파일입니다. 장애가 발생하더라도, 재부팅 후 Redo Log를 읽어 변경사항을 다시 수행하면 커밋된 트랜잭션에 대한 데이터는 완벽히 복구됩니다.

2. 구조

Redo Log는 Redo Log Block으로 이루어지며, Redo Log Block은 Redo Log Record들로 이루어집니다. Redo Log Record의 구조는 다음과 같습니다.

• Type: 변경 작업의 성격(Insert, Update, Delete 등)을 나타내는 타입 코드입니다.
• Space ID: 데이터가 변경된 테이블스페이스의 ID입니다.
• Page Number: 변경이 발생한 페이지의 번호입니다.
• Offset: 페이지 내에서 실제 데이터가 수정된 시작 위치입니다.
• Data: 변경된 실제 데이터 내용입니다.

3. WAL(Write-Ahead Logging)과 로그 버퍼

WAL(Write-Ahead Logging)은 데이터를 변경하기 전, 변경 로그를 먼저 기록한다는 원칙입니다. 트랜잭션이 커밋되기 전에 Redo Log를 먼저 기록함으로써 Durability를 보장할 수 있습니다. 장애가 발생하더라도, 재부팅 후 Redo Log를 읽어 변경사항을 다시 수행하면 커밋된 트랜잭션에 대한 데이터를 복구할 수 있습니다.

WAL의 핵심은, “트랜잭션 커밋 전 Redo Log를 저장해야 한다”는 것입니다. 트랜잭션이 커밋되기 전, Redo Log를 어떤 수준까지 저장할 것인지 이해하기 위해선 로그 버퍼에 대해 알아야 합니다.

이후 포스팅에서 다룰 예정이지만, 사실 Redo Log Record는 트랜잭션 커밋 시점이 아닌 MTR(Mini-Transaction)이라는 최소 단위 트랜잭션 커밋 시마다 생성됩니다.

만약, 매 트랜잭션이 끝날 때마다 모든 Redo Log Recoord들이 디스크(혹은 OS 페이지 캐시)저장되어야 한다면 계속해서 랜덤 I/O가 발생하기 때문에 매우 비효율적일 것입니다.

이 문제를 해결하기 위해 도입된 것이 로그 버퍼입니다. 로그 버퍼는 트랜잭션 진행 중 발생하는 Redo Log Record들을 디스크에 쓰기 전 메모리에 임시로 저장하는 버퍼입니다. 트랜잭션 과정에서 발생한 Redo Log Record들을 모아 블록 단위로 묶어 I/O함으로써, 디스크 I/O 횟수를 줄일 수 있습니다.

그러나, 로그 버퍼는 메모리 기반 버퍼이기 때문에 버퍼와 디스크 사이의 데이터 불일치가 발생하는 시점이 존재합니다. InnoDB는 데이터 불일치가 발생하는 기간을 조절할 수 있는 innodb_flush_log_at_trx_commit 속성을 제공합니다. innodb_flush_log_at_trx_commit 속성은 트랜잭션이 성공하기 위해서 로그 버퍼의 블록을 어느 단계까지 작성해야 하는지 정하는 속성입니다.

2: 모든 블록이 OS의 페이지 캐시에 작성되어야 트랜잭션이 성공할 수 있습니다.

• 실제 디스크 기록은 OS가 수행하므로 빠르지만, 서버 장애 발생 시 OS 캐시는 유실됩니다.
• 백그라운드 스레드가 1초 주기로 fsync()를 호출합니다.

0: 모든 블록이 로그 버퍼에 작성되어야 트랜잭션이 성공할 수 있습니다.

• 백그라운드 스레드가 1초 주기로 로그 버퍼의 모든 블록을 디스크에 작성합니다.
• DB 엔진이나 OS 중 하나만 비정상 종료되어도 마지막 1초간의 커밋은 무효화됩니다.

4. 로그 그룹

InnoDB는 Redo Log의 순차 I/O를 위해 여러 개의 Redo Log 파일을 로그 그룹으로 묶어서 관리합니다.

로그 그룹은 하나 이상의 물리적인 Redo Log 파일들을 논리적인 바이트 스트림으로 관리할 수 있게 도와주는 컨테이너입니다. 로그 그룹은 Redo Log 파일들을 원형 큐 형태로 관리합니다. N번 파일의 마지막 바이트 다음 바이트는 N+1번 파일의 첫 번째 바이트로 이어지도록 구성합니다.

바이트를 스트림 형태로 다루는 것은 ‘논리적 추상화’ 입니다. 논리적으로 파일 간 데이터 흐름이 이어질 수 있어도, 파일 단편화로 인해 순차 I/O가 발생하지 않을 수 있습니다. InnoDB는 데이터베이스 초기화 시점에 전체 Redo Log 파일의 크기를 미리 할당받습니다. 이 과정에서, 운영체제는 최대한 연속된 물리 공간을 할당하게 되므로 파편화를 최대한 방지하고, 디스크 헤더 이동 시간을 최소화합니다.

파일이 가득 차면 다음 파일로 넘어가고, 마지막 파일까지 가득 차면 다시 첫 번째 파일의 처음으로 돌아와서 데이터를 덮어씁니다.

무조건 덮어쓰는 것은 아닙니다. 덮어쓰려는 Redo Log가 Inactive 상태여야 합니다. Active: 반영되지 않은 Redo Log Record가 존재해 추후 복구에 해당 Redo Log 파일이 필요할 수 있는 상태. Inactive: 모든 Redo Log Record가 반영되어 더 이상 사용되지 않는 상태.

덮어써야 하는 Redo Log가 Active 상태라면, InnoDB는 새로운 트랜잭션을 잠시 멈추고(Blocking), Redo Log 내 Redo Log Record와 연결된 더티 페이지를 디스크에 쓰기 시작합니다.

Redo Log의 크기와 갯수 옵션을 조절하여 Blocking 문제를 최대한 방지할 수 있습니다. 참고: https://dev.mysql.com/doc/refman/8.4/en/innodb-parameters.html#sysvar_innodb_log_file_size

5. LSN(Log Sequence Number)

Redo Log Record는 더티 페이지가 발생할 때마다 생성됩니다. 이로 인해 장애 복구 시간이 크게 늘어나고, 무한한 Redo Log 저장 공간을 요구하게 됩니다.

이를 해결하기 위해 LSN(Log Sequence Number) 이 도입되었습니다. LSN은 데이터베이스 생성 시점부터 현재까지 발생한 Redo Log의 총 누적 바이트 합계를 나타내는 값으로, Redo Log Record와 페이지에 부여됩니다.

LSN은 Global LSN을 통해 생성되며, 처음엔 Redo Log Record에 부여됩니다. 이후, Redo Log Record가 수정하는 페이지 헤더에 똑같은 LSN을 기록합니다. 이 시점부터 해당 페이지는 더티 페이지가 됩니다.

1. Redo Log Record의 LSN과 페이지의 LSN을 비교하면, Redo Log Record가 이미 반영되었는지 확인할 수 있습니다.

만약, Redo Log Record LSN이 페이지 LSN 보다 크다면 해당 Redo Log Record는 반영되지 않은 것입니다.

2. Redo Log Record 주소 탐색 비용을 최소화할 수 있습니다.

Redo Log Record 크기는 DML 종류에 따라 다릅니다. 누적 바이트 단위인 LSN을 사용하면 간단한 산술 연산만으로 Redo Log Record를 작성해야 하는 주소를 도출할 수 있습니다. Redo Log Record를 작성해야 하는 주소 = Redo Log 시작 주소 + (LSN % 로그 그룹의 총 크기)

6. Checkpoint LSN

InnoDB는 LSN을 통해 복구 시 데이터 비교 없이 특정 Redo Log Record의 변경사항이 특정 페이지에 반영되었는지 확인할 수 있습니다. 그러나, 장애 복구 시 모든 Redo Log Record들을 읽어 일일히 비교하는 것은 비효율적입니다.

InnoDB는 장애 복구 시간을 최소화하기 위해 Checkpoint LSN을 사용합니다. Checkpoint LSN은 Redo Log에 기록된 변경 사항 중, 완전히 반영된 마지막 지점을 나타내는 LSN입니다. 장애 복구 시, Checkpoint LSN 이전의 데이터는 이미 디스크에 반영된 것이 확실하므로 복구할 필요가 없습니다.
Page Cleaner는 주기적으로 더티 페이지들을 디스크에 쓰고, 더티 페이지들 중 가장 낮은 LSN을 Redo Log 파일 헤더의 Checkpoint LSN으로 기록합니다.

SPOF를 방지하기 위해 Checkpoint LSN은 첫 번째, 두 번째 Redo Log 파일 헤더에 기록됩니다. 복구 시, 두 Checkpoint LSN을 비교해 높은 값을 사용합니다.

또한, Checkpoint LSN을 활용하면 Redo Log 파일 순환 시 덮어쓰려는 Redo Log 파일이 Active인지 Inactive인지 판별할 수 있습니다.

OS 페이지 캐시에 반영된 LSN을 Wirte LSN이라 합니다. Active인 경우: Redo Log Group 총 용량 ≤ Write LSN - Checkpoint LSN Inactive인 경우: Redo Log Group 총 용량 > Write LSN - Checkpoint LSN

7. DoubleWrite Buffer

만약, 더티 페이지를 디스크에 쓰는 중 장애가 발생하면 어떻게 될까요? 16KB 페이지 하나를 디스크에 쓰는 도중 전원이 차단되면, 16KB 중 일부만 써지고 뒷부분은 예전 데이터가 남는 Partial Write 현상이 발생합니다.

Redo Log는 물리적으로 무결한 페이지의 특정 오프셋에 기록된 바이트 값을 새 값으로 덮어쓰는 방식으로 작동합니다. 페이지 쓰기 도중 장애로 인해 Torn Page 상태가 되면, Redo Log를 적용할 수 없습니다.

Torn Page란? 페이지 일부분만 저장되어 Checksum이 일치하지 않거나 헤더가 파손된 페이지를 말합니다.

Torn Page에 대해 더 궁금하다면? https://dev.mysql.com/doc/refman/8.4/en/glossary.html#glos_torn_page

InnoDB는 이를 해결하기 위해 Doublewrite Buffer를 사용합니다. Doublewrite Buffer는 더티 페이지들을 디스크에 쓰기 전, 해당 페이지들의 원본 전체를 기록해 두는 디스크 상의 저장 영역입니다. 장애 복구 과정에서, 특정 페이지가 Torn Page 상태라면, Redo Log를 적용하기 전 Doublewrite Buffer 파일에서 해당 페이지의 복사본을 찾아 사용합니다.

Doublewrite Buffer에 대해 더 궁금하다면? https://dev.mysql.com/doc/refman/8.4/en/glossary.html#glos_doublewrite_buffer

마치며

이번 포스팅에서는 No-FORCE 정책을 유지하면서, 동시에 Durability를 보장하기 위한 Redo Log와 WAL(Write-Ahead Logging)에 대해 살펴보았습니다.

다음 포스팅에서는, InnoDB가 STEAL 정책을 유지하면서 어떻게 Atomicity를 보장할 수 있는지 알아보도록 하겠습니다. 끝까지 읽어주셔서 감사합니다.

참고 문서 https://dev.mysql.com/doc/refman/8.4/en/glossary.html MySQL 8.4 Glossary

https://tech.kakao.com/posts/721 MySQL InnoDB Log에 대한 이해 - (1) - christy.seo, sun.j

글의 목적

안녕하세요 머랭입니다. 데이터베이스를 사용하는 애플리케이션을 개발하다 보면 수많은 트랜잭션을 커밋하게 됩니다. 그런데, 여러분이 커밋한 트랜잭션이 실제로 디스크에 반영되지 않았을 수 있다는 사실을 알고 계신가요?

디스크에 반영한다는 것은, 랜덤 I/O가 발생한다는 의미입니다. 만약 모든 트랜잭션마다 랜덤 I/O가 발생한다면, DBMS의 처리량은 매우 낮을 것입니다. MySQL의 InnoDB는 이런 문제를 어떻게 해결했을까요? 몇 개의 포스팅을 통해 InnoDB가 높은 처리량을 보장하면서도 ACID를 지킬 수 있도록 하는 핵심 기술인 WAL(Write-Ahead Logging)에 대해 이야기해보고자 합니다.

이번 포스팅에서는 WAL(Write-Ahead Logging)을 이해하기 위해 필요한 핵심 개념인 InnoDB의 버퍼 풀 관리 정책에 대해 설명드리겠습니다.

대상 독자

1. Undo Log와 Redo Log에 대해서 들어봤지만, 확실하게 알지 못하는 개발자
   • Undo Log와 Redo Log가 무슨 역할을 하는지, 왜 존재하는지 이해할 수 있습니다.
2. InnoDB가 페이지를 어떻게 관리하는지 궁금한 개발자
   • 추상적인 DML 뒤에서 InnoDB 스토리지 엔진이 페이지를 어떻게 관리하는지 이해할 수 있습니다.

이번 글을 통해 얻어갈 수 있는 것들

1. InnoDB가 효율적인 I/O를 위해 선택한 페이지 관리 방식에 대해 이해할 수 있습니다.
2. 트랜잭션이 커밋된 후 디스크에 반영되기까지의 과정을 이해하고 설명할 수 있게 됩니다.
3. InnoDB가 택한 버퍼 관리 정책의 심각한 문제점들을 인지하게 됩니다.

1. 버퍼(버퍼 풀)

데이터베이스의 가장 큰 병목은 언제나 디스크 I/O, 특히 랜덤 I/O 입니다. 버퍼는 디스크 I/O를 최소화하기 위해 페이지를 메모리(RAM)에 캐싱해두는 공간입니다.

InnoDB는 변형된 LRU 알고리즘을 통해 버퍼를 관리합니다. 변형된 LRU 알고리즘이 궁금하다면? MySQL InnoDB 공식 문서

• 데이터 캐시: 자주 쓰이는 데이터를 메모리에 올려두어 디스크 I/O 없이 바로 응답합니다.
• 쓰기 지연: 데이터를 변경할 때 즉시 디스크에 기록하지 않고, 버퍼에서 먼저 변경한 뒤 Page Ceaner가 백그라운드에서 디스크에 기록합니다.

Page Cleaner

Page Cleaner는 InnoDB의 백그라운드 스레드로, 버퍼에 있는 더티 페이지들을 주기적으로 디스크로 플러시(Flush)하여 데이터 손실을 방지하고 버퍼 풀 공간을 확보하는 역할을 합니다.

2 버퍼 관리 정책

2.1 STEAL / No-STEAL

STEAL / No-STEAL 정책은 트랜잭션이 진행 중(커밋 전)일 때, 버퍼에 존재하는 수정된 페이지를 디스크에 미리 쓸 수 있는지 여부를 결정합니다.

STEAL

트랜잭션의 진행 여부와 관계없이, 수정된 페이지를 언제든지 디스크에 쓸 수 있는 정책입니다. 버퍼가 부족하면, 버퍼 관리자는 아직 완료되지 않은 트랜잭션이 수정한 페이지라도 디스크에 기록하고 버퍼를 비울 수 있습니다. 아직 커밋되지 않은 데이터가 디스크에 존재하게 됩니다.

InnoDB를 포함한 대부분의 스토리지 엔진이 이 정책을 사용합니다.

한정된 버퍼를 효율적으로 사용할 수 있습니다.

No-STEAL

트랜잭션이 종료(커밋)될 때까지는 수정된 페이지를 절대 디스크에 쓰지 않는 정책입니다. 변경된 페이지를 계속해서 버퍼에 유지합니다. 디스크에는 항상 커밋된 데이터만 존재하게 됩니다.

트랜잭션이 다루는 데이터가 매우 크면 그만큼 엄청난 양의 메모리 버퍼가 필요해집니다.

2.2 FORCE / No-FORCE

FORCE / No-FORCE 정책은 트랜잭션이 커밋되는 시점에 수정된 모든 페이지를 반드시 디스크에 반영해야 하는지 여부를 결정합니다.

FORCE

매 트랜잭션이 커밋되는 시점에 수정했던 모든 페이지를 디스크에 즉시 반영하는 정책입니다. 커밋 직후 장애가 발생해도, 이미 디스크 쓰기가 완료된 상태이므로 복구가 필요 없습니다.

매 트랜잭션 커밋 시마다 랜덤 I/O가 발생하므로, 성능이 매우 떨어집니다.

No-FORCE

트랜잭션이 커밋되어도 수정된 페이지를 디스크에 즉시 반영하지 않는 정책입니다. InnoDB를 포함한 대부분의 스토리지 엔진이 이 정책을 사용합니다.

랜덤 I/O 횟수가 크게 감소합니다.

3. 버퍼 관리 정책의 문제점

InnoDB를 포함한 대부분의 스토리지 엔진은 STEAL & No-FORCE 정책을 사용합니다.

한정된 버퍼를 효율적으로 사용하기 위해 STEAL 정책을 사용합니다. 랜덤 I/O를 최소화하기 위해 No-FORCE 정책을 사용합니다.

그러나, 두 정책을 사용하게 되면 더티 페이지가 실제 DB에 반영되는 시점과 단위가 모호해지기 때문에 Atomicity와 Durability를 보장할 수 없게 됩니다.

3.1 STEAL - Atomicity 위반

STEAL 정책은 버퍼를 효율적으로 사용하기 위해, 아직 커밋되지 않은 페이지를 디스크에 반영합니다. 이로 인해 장애 발생 시 Atomicity를 보장할 수 없습니다.

시나리오

1. 트랜잭션 시작 및 페이지 수정 디스크에서 페이지를 읽어와 버퍼 풀에서 데이터를 수정합니다. 수정할 페이지가 많아 수정 중간에 버퍼는 더티 페이지로 가득 찼습니다.

2. STEAL 발생 아직 데이터 수정이 더 필요합니다. 이때, STEAL 정책에 의해 Page Cleaner가 동작해 아직 커밋되지 않은 페이지를 디스크에 작성합니다.

3. 갑작스러운 장애 발생 나머지 데이터를 수정하던 중, 갑자기 서버가 다운되었습니다. 트랜잭션은 커밋되지 못하고 비정상 종료되었습니다.

4. 재부팅 후 Atomicity 위반 트랜잭션은 실패했으므로 데이터는 수정 전으로 롤백되어야 합니다. 그러나, Page Cleaner가 디스크에 작성한 페이지까지만 디스크에 반영되어있습니다.

3.2 No-FORCE - Durability 위반

No-FORCE 정책은 랜덤 I/O를 최소화하기 위해, 트랜잭션이 커밋되어도 수정된 페이지를 디스크에 즉시 반영하지 않고 한 번에 Flush합니다.

시나리오

1. 트랜잭션 시작 및 커밋 트랜잭션 커밋 시, 변경된 페이지는 더티 페이지 상태로 버퍼에만 존재합니다. 더티 페이지가 실제로 디스크에 반영되는 것을 기다리지 않습니다. 버퍼에 반영되었으니 트랜잭션 커밋은 성공적으로 이루어집니다.

2. 갑작스러운 장애 발생 Page Cleaner가 더티 페이지들을 디스크에 작성하기 전, 갑자기 서버가 다운되었습니다. 버퍼는 RAM에 존재하므로, 버퍼에 존재하던 더티 페이지는 유실됩니다.

3. 재부팅 후 Durability 위반 트랜잭션은 성공했었으므로, 재부팅 후에도 성공 상태로 남아있어야 합니다. 그러나, 버퍼 유실로 인해 디스크에는 커밋 전 데이터만 존재합니다.

마치며

이번 포스팅에서는 랜덤 I/O로 인한 병목을 해결하기 위해 InnoDB가 도입한 버퍼, 이를 관리하는 Page Cleaner의 역할을 살펴보았습니다. 또한, 버퍼를 관리하기 위한 정책인 STEAL / No-STEAL 그리고 FORCE / No-FORCE에 대해 알아보았습니다. InnoDB를 포함한 대부분의 스토리지 엔진은 STEAL & No-FORCE 정책을 사용합니다.

STEAL & No-FORCE 정책은 버퍼를 효율적으로 사용하고 랜덤 I/O를 최소화한다는 장점이 있지만, Atomocity와 Durability를 보장하지 못한다는 치명적인 단점이 존재합니다.

다음 포스팅에서는, InnoDB가 이 단점들을 어떻게 해결했는지 알아보도록 하겠습니다. 끝까지 읽어주셔서 감사합니다.

참고 문서 https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool.html MySQL 8.4 Glossary

https://d2.naver.com/helloworld/407507 DBMS는 어떻게 트랜잭션을 관리할까? - 오이석|NBP 서비스플랫폼개발센터

https://tech.kakao.com/posts/721 MySQL InnoDB Log에 대한 이해 - (1) - christy.seo, sun.j

"RabbitMQ를 사용해 보셨나요? 그렇다면 AMQP가 무엇인지 아시나요?"

글의 목적

안녕하세요, 백엔드 개발자(지망생) 머랭입니다. 많은 개발자가 RabbitMQ를 사용하지만, 그 근간이 되는 AMQP의 깊은 곳까지는 들여다보지 못하곤 합니다.

AMQP는 크게 0-9-1 버전과 1.0 버전으로 나뉩니다. 언뜻 보면 1.0이 0-9-1의 상위 호환 버전처럼 느껴지지만, 실제로는 지향점이 완전히 다른 프로토콜입니다.

• AMQP 0-9-1은 Exchange, Queue, Binding 등 브로커 내부의 동작 모델을 구체적으로 명시했습니다.
• AMQP 1.0은 브로커 내부 구현을 각 벤더에게 맡기고, 전송 규약에 집중하는 추상적인 접근을 택했습니다.

RabbitMQ는 현대 개발 시장에서 가장 유명한 AMQP 0-9-1 구현체입니다.

RabbitMQ 4.0이 출시되며 AMQP 1.0을 플러그인 형태로 지원하기 시작했지만, 여전히 전 세계 수많은 메시징 시스템은 AMQP 0-9-1 위에서 동작하고 있습니다.

이번 포스팅에서는 현대 개발 시장에서 활발하게 사용되는 AMQP 0-9-1 프로토콜의 공식 문서와 논문을 분석하며 얻은 본질적인 동작 원리를 공유하고자 합니다.

대상 독자

1. RabbitMQ 등 AMQP 기반 브로커에 대한 기본 흐름을 알고 있는 개발자
   • 그 중에서도, 내부 동작 방식에 대해 더 깊은 호기심을 가진 개발자.
2. "왜"를 찾는 멋진 개발자
   • AMQP가 왜 그렇게 설계되었는지 그 논리와 내부 동작이 궁금한 개발자.

단순히 "어떤 라이브러리를 써서 어떻게 보낸다"는 방법론을 넘어, AMQP 0-9-1 공식 문서를 탐구하며 얻은 지식을 바탕으로 "AMQP는 왜 그렇게 동작하는지"에 대한 본질적인 답을 찾아보고자 합니다.

글을 통해 얻어갈 수 있는 것들

라이브러리 메서드 하나로 메시지를 보낼 수 있는 편리한 시대에, 수백 페이지의 명세서를 읽으며 내부 구조를 탐구하는 이유는 명확합니다. 도구를 사용하는 것을 넘어, 기술의 본질을 이해하고 통제하는 힘을 가질 수 있습니다.

1. AMQP에 대한 깊은 이해
   • Exchange, Queue, Binding이 맺는 유기적인 관계와 라우팅 논리를 명확히 이해할 수 있습니다.
2. 물리적 실체에 대한 이해
   • 데이터(메시지)가 네트워크 위에서 어떻게 Frame 단위로 쪼개지고 조립되는지 파악할 수 있습니다.
3. 코더에서 시스템 설계 능력을 갖춘 개발자로의 진화
   • "~ 하니까 되던데?" 와 같은 비논리적인 사고방식에서, 근본을 이해하고 시스템을 설계하는 개발자로 나아갈 수 있습니다.

1. AMQP의 탄생 배경

AMQP는 월스트리트의 투자 은행 JPMorgan에서 시작되었습니다.

기존의 상용 메시징 미들웨어는 메시지 형식이 제각각이었고, 특정 벤더에 종속적이라는 단점이 있었습니다.

ex) IBM의 메시징 미들웨어가 전송한 메시지를 Microsoft의 Consumer가 처리할 수 없었습니다. 이를 가능하게 하려면 메시지 형식 변환 브릿지(어댑터)를 개발해야 했습니다.

AMQP 개발자들은 메시징 기술이 TCP/IP처럼 누구나 사용할 수 있는 공용어가 되기를 원했습니다. 특정 벤더의 기술이나 프로토콜에 얽매이지 않고, 이기종 시스템 간에도 메시지를 신뢰성 있게 교환할 수 있는 개방형 표준을 만드는 것이 AMQP의 목표였습니다.

2. 철학

Broker 중심 아키텍처

Broker는 복잡한 메시지 라우팅, Queue 관리를 비롯해 메시지 전송의 모든 책임을 집니다.

Consumer가 메시지를 잘 받았는지 확인될 때까지 Broker는 메시지를 보관하고 관리하며, 처리가 완료되면 Queue에서 메시지를 제거합니다.

최소 한 번 전달(At-least-once)

메시지를 최소한 한 번 전달합니다.

메시지 유실을 방지하지만, 두 번 전달되는 것은 막을 수 없어 멱등한 비즈니스 로직을 작성해야 합니다.

Pub-Sub 기반 Push 전송

Consumer가 데이터를 가져오기 위해 대기하거나 주기적으로 확인할 필요가 없습니다.

Broker는 새로운 메시지가 Queue에 도착하면 연결된 Consumer에게 즉시 전달합니다.

이 과정에서, prefetch 메커니즘을 통해 Consumer가 처리 가능한 메시지 양을 Broker에 알림으로써, 무분별한 Push로 인한 시스템 마비를 방지합니다

3. 핵심 구성 요소 - 공통

3.1 Frame

설명

Frame은 AMQP 통신에서 네트워크를 타고 흐르는 데이터의 최소 단위입니다.

TCP는 데이터 경계가 없는 스트림 방식이기 때문에, 어디서부터 어디까지가 하나의 데이터 단위인지 구분하기 위해 모든 데이터를 Frame으로 포장해 주고받습니다.

Frame은 네 가지로 분류됩니다.

• 명령을 주고받기 위한 Method Frame
• 메시지의 메타데이터를 주고받기 위한 Content Header Frame
• 메시지의 실제 데이터를 주고받기 위한 Content Body Frame
• Peer 간 하트비트를 주고받기 위한 Heartbeat Frame

구조

• type: Frame의 유형을 나타냅니다.
  • 1: Method Frame
  • 2: Content Header Frame
  • 3: Content Body Frame
  • 4: Heartbeat Frame
• channel: 해당 Frame이 속한 Channel 번호입니다.
• size: payload 영역의 총 바이트 수입니다.
• payload: 실제 데이터가 담기는 공간입니다.
• frame-end: Frame의 끝을 알리는 특수한 값입니다.

3.2 Method(Method Frame)

설명

AMQP는 기능들을 Class로 묶고, 그 안의 동작을 Method로 정의합니다.

Method Frame은 Peer간 명령을 주고받기 위해 사용되는 Frame입니다.

“test-queue라는 이름의 큐를 생성해라” 혹은 “A Exchange를 제거해라”와 같은 명령 데이터를 주고받기 위해 사용됩니다.

개인적으로 CPU instruction set architecture와 비슷한 개념이라고 느꼈습니다.

구조

• class-id: Method가 저장되어있는 Class의 ID입니다.
• method-id: 해당 Class의 명령 번호입니다.
  • 예: Reject(거절) = 90입니다.
• arguments: 명령을 수행하는 데에 필요한 매개변수들입니다.

3.3 Message

설명

A message is the atomic unit of processing of the middleware routing and queuing system. Messages carry a content, which consists of a content header, holding a set of properties, and a content body, holding an opaque block of binary data.

메시지는 미들웨어 라우팅 및 대기열 시스템의 처리를 위한 원자 단위입니다. 메시지는 콘텐츠 헤더, 속성 세트, 불투명한 이진 데이터 블록을 포함하는 콘텐츠 본문으로 구성된 콘텐츠를 전달합니다. AMQP 0-9-1 공식 문서 중..

메시지는 AMQP 시스템에서 데이터 이동의 최소 단위입니다. 논리적인 최소 단위이며, 실제로는 Frame이 데이터 이동의 최소 단위입니다.

• 영속성(Persistence): 영속화되어 디스크에 저장될 수 있습니다.
• 우선순위(Priority): 우선순위를 가질 수 있습니다. 우선순위가 높은 메시지가 먼저 처리되거나, 우선순위가 낮은 메시지가 우선적으로 폐기됩니다.
• 불투명성(Opaque)과 불변성(Immutable): Broker는 메시지의 본문을 확인하거나 수정해선 안됩니다.

구조

메시지는 Content Header와 Content Body라는 두 계층으로 설계되었습니다.

메시지를 전달하는 주체는 Content Header 영역의 데이터만 사용해 메시지를 전달합니다.

Content Header: 메타데이터 영역으로, 메시지의 속성(Properties)이 담겨 있습니다.

• body-size: Content Body 영역의 크기 값입니다.
• delivery-mode: 영속화 옵션으로, 메시지를 메모리에만 저장할지 디스크에도 저장할지 설정할 수 있습니다.
• priority: 우선순위(0~9)로, 우선순위가 높은 메시지는 먼저 처리됩니다.
• reply-to: 응답을 받을 Queue의 이름을 명시하여 Request-Response 패턴을 구현할 수 있습니다.

Content Body: 실제로 애플리케이션이 전달하고자 하는 비즈니스 데이터가 담겨 있습니다.

• 바이너리 형태로 저장되며, Producer와 Consumer를 제외한 모든 Peer는 메시지의 본문을 확인하거나 수정해선 안됩니다.
  • Zero-Copy를 통해 메시지 처리량을 높이기 위함입니다.

3.4 Connection & Channel

설명

AMQP에서 통신은 물리적 연결인 Connection과 논리적 통로인 Channel의 이중 구조로 이루어집니다.

Channel은 메시지를 Frame 단위로 분해하여 전송하는 실질적인 데이터 스트리밍의 주체입니다.

• Connection: Peer 간 맺는 물리적 TCP 연결로, Peer들은 Connection을 통해 여러 Frame을 전송합니다.

  • Connection으로 전송되는 메시지는 여러 개의 Frame으로 나뉘어집니다. (메시지 분할은 Channel이 수행)

  • 덕분에 멀티스레드 환경에서 여러 메시지를 동시에 전송할 수 있습니다.

  • 단일 TCP 연결은 대역폭 한계가 존재하므로, 여러 개의 Connection을 생성해 Connection 풀을 구성할 수 있습니다.

    만약 메시지가 Frame 단위로 나뉘어지지 않는다면? 한 스레드가 Connection을 독점하고 자신이 보낼 모든 메시지를 보낸 후 Connection을 반납합니다.

  • 그 과정에서 다른 스레드는 Blocking됩니다.*

  • 결과적으로, 처리량이 낮아집니다*

• Channel: Connection 내부에 생성되는 논리적인 가상 통로로, 메시지를 Frame으로 쪼개 Connection으로 전송하는 동작을 추상화해 제공하는 인터페이스입니다.

  • Channel을 여는 행위는 Peer에게 지금부터 이 Channel 번호로 대화하자는 합의를 보내는 과정입니다. TCP 연결을 맺는 것과는 다릅니다.
  • Peer에게 Channel.Open Frame을 전송해 Channel 생성을 알립니다.
  • Peer는 Channel.Open-Ok 메서드 Frame을 응답해 Channel 생성을 합의합니다.
  • Channel을 여는 행위는 2번의 네트워크 비용을 요구하기 때문에, 여러 Channel을 생성해 Channel 풀을 구성할 수 있습니다.

3.5 Routing Key

설명

Routing Key는 Producer가 메시지를 발행할 때, 메시지와 함께 전송하는 문자열입니다.

Exchange는 Routing Key를 사용해 메시지를 어떤 Queue로 전달할지 결정합니다. Producer는 메시지가 정확히 어떤 Queue로 전달되어야 하는지에 관심가지지 않고 Routing Key만 Exchange에 전달합니다. 덕분에 Broker는 단순한 1:1 전달을 넘어 하나의 메시지를 여러 Queue에 전달하거나 특정 조건에 맞는 곳으로만 보내는 복잡한 라우팅을 로직을 수행할 수 있습니다. 대소문자를 구분하므로, 설계 시 참고해야 합니다.

Point-To-Point 방식을 사용하려면 Routing Key를 Queue의 이름으로 설정합니다. Pub-Sub 방식을 사용하려면 데이터의 성격을 나타내는 계층적 값을 사용합니다.

예: order.new, payment.success

구조

255 octet 크기의 문자열 형식으로 이루어집니다.

octet: 8비트 크기의 데이터 단위로, 과거 1 바이트가 8비트이지 않은 경우가 있어 생긴 단위입니다.

4. 핵심 구성 요소 - Producer

설명

Producer는 메시지를 생성하고 Broker를 향해 발행하는 클라이언트 애플리케이션입니다. Producer는 Queue에 메시지를 직접 발행하지 않고, 메시지와 Routing Key를 Exchange에게 전송합니다. 메시지를 Queue에 전달하는 과정은 Broker에서 이루어집니다.

높은 처리량을 위해 Producer → Broker 간 메시지 수신응답(ACK/NACK)은 이루어지지 않습니다.

RabbitMQ는 확장 기능으로 이 기능을 제공합니다. 신뢰성이 중요한 경우 사용할 수 있습니다.

동작

1. 메시지 전송 시작 Frame 전송

   • 메시지를 여러 Frame으로 쪼갠 후 모든 Frame 헤더에 Channel 번호를 기입합니다.

   • Basic.Publish Method Frame을 생성해 Connection으로 전송합니다.

     • Basic.Publish Method Frame은 메시지 생산 시작을 위한 Method Frame 입니다.

     • Basic.Publish Method Frame에는 다음 Arguments가 포함됩니다.

     • Exchange 이름

     • Routing Key

     • Mandatory(필수 전달) 플래그

       • 해당 Routing Key와 매칭되는 Queue가 존재하지 않을 때 Basic.Return Method Frame을 통해 Producer에게 메시지를 반환합니다.
       • Basic.Return Method Frame은 메시지 라우팅 실패를 알리기 위한 Method Frame입니다.

     • Immediate(즉시 전달) 플래그

       • Queue에서 즉시 메시지를 소비할 수 있는 Consumer가 존재하지 않을 때 Basic.Return Method Frame을 통해 Producer에게 메시지를 반환합니다.

         RabbitMQ 3.0 이상에서는 다중 Consumer 에 대한 메시지 소비 체크 오버헤드로 인해 Immediate 플래그를 지원하지 않습니다.

   • Basic.Publish Method Frame을 전달받은 Broker는 이제 해당 Frame을 보낸 Channel에서 메시지 Frame을 보낼 것임을 인지합니다.

2. 메시지 Frame 전송

   • Broker에게 메시지의 Content Header Frame을 전송합니다.
     • Broker는 Content Header Frame의 body size를 확인합니다.
   • Broker에게 Content Body Frame들을 전송합니다.
     • Broker는 전달받는 Content Body Frame들의 데이터 합계가 body size와 일치할 때까지 계속해서 Content Body Frame을 수신합니다.

5. 핵심 구성 요소 - Broker

AMQP의 핵심인 Broker는 메시지의 수신, 라우팅, 보관 및 전달을 총괄하는 시스템입니다.

5.1 Exchange

설명

Exchange는 Producer로부터 수신한 메시지를 하나 이상의 Queue 혹은 Exchange로 전달하기 위한 라우팅 엔진입니다. 라우팅 규칙에 따라 하나의 메시지를 여러 Queue 혹은 Exchange에 동시에 전달할 수 있습니다. 메시지의 Content Body에는 관여하지 않으며, 수신한 데이터를 변경 없이 그대로 전달합니다.

구조

가장 중요한 속성 세 가지에 대해 설명하겠습니다.

• name: Exchange를 식별하기 위한 고유한 이름입니다.
• type: 메시지 라우팅 알고리즘입니다.
  • Direct Exchange(Unicast): Routing Key와 Binding Key가 정확히 일치하는 바인딩의 Queue 혹은 Exchange로 전달합니다.
  • Topic Exchange(Multicast): Binding Key 패턴(예: order.*)이 Routing Key(예: order.new)에 매칭되는 바인딩의 Queue 혹은 Exchange로 메시지를 전달합니다.
  • Headers Exchange(Multicast): Routing Key와 Binding Key 대신 메시지의 Content Header 내 headers 테이블의 속성값을 기준으로 전달합니다.
  • Fanout Exchange(Broadcast): Routing Key를 무시하고 해당 Exchange에 바인딩된 모든 Queue 혹은 Exchange로 메시지를 전달하는 브로드캐스트 방식을 수행합니다.
• durability: Broker 재시작 시 Exchange 보존 여부입니다
  • true: 비휘발성 Exchange
    • Exchange 정보를 디스크에 저장합니다.
    • Broker 재시작 후에도 비휘발성 Exchange들은 유지됩니다.
  • false: 휘발성 Exchange
    • Broker가 종료되면 휘발성 Exchange들은 사라집니다.
    • 재시작 후 다시 사용하려면 새로 생성해야 합니다.

동작

1. 서버의 메시지 수신
   • Channel을 통해 들어온 Basic.Publish Method Frame을 읽어 Exchange Name과 Routing Key를 확인합니다.
   • 이후 도착한 Content Header와 Content Body Frame을 조립하여 완성된 메시지 객체를 생성합니다.
   • 최종적으로 Exchange는 메시지를 수신하게 됩니다.
2. Binding 테이블을 통한 메시지 라우팅
   • 각 Exchange는 Binding Table을 참조하며, 이 Binding Table에는 Binding 목록이 저장되어 있습니다.
     • Binding Table은 Broker의 메타데이터 저장소에 존재합니다.
   • Binding Table을 통해 연결(바인딩)할 수 있는 Queue를 찾아 메시지를 전달합니다.

5.1.1 Direct Exchange

Routing Key와 Binding Key가 정확히 일치하는 바인딩의 Queue 혹은 Exchange로 메시지를 전달합니다.

Routing Key: order.new, Binding Key: order.new

• Binding Key가 정확히 일치하기 때문에 메시지가 전달됩니다.

Routing Key: order.new, Binding Key: order.cancel

• Binding Key가 일치하지 않기 때문에 메시지가 전달되지 않습니다.

5.1.2 Fanout Exchange

Binding Key, arguments를 사용하지 않고, 모든 Binding의 목적지로 메시지를 전달합니다(Broadcast).

5.1.3 Topic Exchange

Binding Key 패턴이 Routing Key와 매칭되는 Binding의 목적지에만 메시지를 전달합니다.

Routing Key: order.new, Binding Key: order.*

• Binding Key 패턴이 Routing Key와 매칭되기 때문에 메시지가 전달됩니다.

Routing Key: payment.new, Binding Key: order.*

• Binding Key 패턴이 Routing Key와 매칭되지 않기 때문에 메시지가 전달되지 않습니다.

5.1.4 Headers Exchange

메시지 Content Headers 내의 headers 테이블 내 속성과 arguments 내의 속성을 비교해 메시지를 전달할 지 결정합니다.

headers 테이블: { ”membership”: “VIP”, “foodType”: “PIZZA” } arguments: { ”membership”: “VIP”, “foodType”: “PIZZA”, "x-match": "all” }

• headers 테이블 내 속성과 arguments의 모든(all 이기 때문) 속성이 일치하기 때문에 메시지가 전달됩니다.

headers 테이블: { “foodType”: “PIZZA” } arguments: { ”membership”: “VIP”, “foodType”: “PIZZA”, "x-match": "any” }

• headers 테이블 내 속성과 arguments의 하나 이상의(any 이기 때문) 속성이 일치하기 때문에 메시지가 전달됩니다.

headers 테이블: { ”membership”: “VIP” } arguments: { ”membership”: “VIP”, “foodType”: “PIZZA”, "x-match": "all” }

• headers 테이블 내 속성과 arguments의 모든(all 이기 때문) 속성이 일치하지 않기 때문에 메시지가 전달되지 않습니다.

5.2 Binding

설명

Binding은 Exchange가 수신한 메시지를 다음 목적지로 전달하기 위한 논리적인 연결 규칙입니다. 단순히 Exchange-Queue 형태로 연결하는 것을 넘어, Exchange-Exchange 형태로 메시지 라우팅 경로를 체이닝할 수 있습니다.

구조

• source: 메시지를 보내는 출발지 Exchange의 이름입니다.
• destination: 메시지를 받는 목적지의 이름입니다.
• destination type: 목적지의 타입입니다.
  • 목적지는 Queue혹은 Exchange입니다.
• binding key: 라우팅 시 Routing Key와 대조할 기준 패턴 문자열입니다.
  • 예: order.new, order.*
• arguments: Headers: Map을 기반으로 하는 필터 조건으로, Headers Exchange에서 사용합니다.
  • arguments 내의 x-match 속성은 사전 정의 속성으로, all과 any 값을 가질 수 있습니다.
    • all: 메시지 Content Headers 내의 headers 테이블 내 속성이 전부 일치해야 메시지를 전달합니다.
    • any: 메시지 Content Headers 내의 headers 테이블 내 속성이 하나라도 일치하면 메시지를 전달합니다.
    • 예: { ”membership”: “VIP”, “foodType”: “PIZZA”, "x-match": "all” }

동작

1. 각 Exchange는 Binding Table을 참조하며, 이 Binding Table에는 Binding 목록이 저장되어 있습니다.
2. Exchange는 메시지를 전달받으면, Binding Table을 통해 연결(바인딩)할 수 있는 Queue를 찾아 메시지를 전달합니다.
3. Binding을 어떻게 사용하는지는 Exchange 타입 별로 나뉩니다.

5.3 Queue(Message Queue)

설명

Queue는 메시지가 최송 소비되기 전까지 보관되는 FIFO 버퍼입니다. 기본적으로 FIFO 구조이지만, 다중 소비자 환경이나 메시지 우선순위(Priority) 사용 시 엄격한 순서가 보장되지 않을 수 있습니다.

• 이를 Weak-FIFO라 부릅니다.

하나의 Queue에는 동일한 역할을 하는 여러 Consumer가 연결될 수 있습니다.

AMQP 모델에서 Queue는 단순한 저장소가 아니라 영리한 객체(Reasonably clever object)로 설계되었습니다. 메시지가 도착하면, Queue는 연결된 Consumer에게 즉시 메시지를 전달하려고 시도합니다. 다중 Consumer 존재 시, 일반적으로 라운드 로빈(Round-Robin) 방식으로 메시지를 분배합니다.

구조

• name: Queue를 식별하기 위한 고유한 이름입니다.
• durable: Broker 재시작 시 Queue 보존 여부입니다
  • true: 비휘발성 Queue
    • Queue 정보를 디스크에 저장합니다.
    • Broker 재시작 후에도 비휘발성 Queue들은 유지됩니다.
  • false: 휘발성 Queue
    • Broker가 종료되면 휘발성 Queue들은 사라집니다.
    • 재시작 후 다시 사용하려면 새로 생성해야 합니다.
  • durable 속성은 메시지의 영속화와는 관련이 없는 Queue 자체의 속성입니다.
  • 메시지를 영속화 여부는 메시지의 Content Header에 delivery-mode를 기반으로 결정됩니다.
  • Queue가 Durable로 설정되어있더라도, 메시지가 Transient 라면 Broker 재시작 시 Queue는 보존되지만 메시지는 유실됩니다.
• exclusive: 해당 Queue를 생성한 Connection만 접근할 수 있도록 하는 설정입니다.
  • true인 경우, 해당 Queue를 생성한 Connection이 닫히면 Queue도 자동으로 삭제됩니다.
• auto-delete: Queue를 사용하던 모든 Consumer가 연결을 끊으면 Queue가 자동으로 삭제됩니다.

동작

1. Exchange는 Binding을 사용해 메시지를 Queue에 삽입합니다.
2. 메시지가 도착하면, Queue는 연결된 Consumer에게 즉시 메시지를 전달합니다.
3. 메시지가 Consumer로 전달된 후, 해당 메시지를 승인 대기 상태로 전환합니다
   • 이때, Consumer로부터 성공/실패 응답을 받기 전까지 해당 메시지에 배타적 락을 걸어 다른 Consumer로 이중 전송되는 것을 방지합니다.
4. Consumer가 처리를 완료하고 승인(ACK) 신호를 보내면, Queue는 메시지를 완전히 제거합니다.
5. 소비자가 승인 전 연결을 끊거나 부정 승인(Reject)을 보내면, Queue는 락을 해제하고 메시지를 다시 대기열에 넣거나 제거합니다.
   • 거절된 메시지는 Reject Method Frame의 requeue 속성에 따라 처리됩니다.
     • requeue = true
       • 해당 메시지를 Queue의 맨 앞에 넣습니다. 이후 다시 Consumer에게 전달됩니다.
     • requeue = false
       • Queue에서 메시지를 제거합니다.
   • RabbitMQ는 DLX라는 특수한 Exchange로 메시지를 전송하기도 합니다.
   • RabbitMQ는 메시지의 재시도 카운트 개념을 통해 일정 횟수만 재시도하도록 하기도 합니다.

6. Consumer

설명

Broker로부터 메시지를 전달받아 소비하는 주체입니다. Push받을 수 있는 메시지의 최대 허용량을 설정할 수 있습니다. 이를 통해 자신의 처리 역량에 맞춰 메시지 Push 속도를 조절함으로써, 부하를 방지합니다.

구조

• consumer tag: Broker가 발급해주는 식별자로, Consumer를 유일하기 식별하기 위한 이름표입니다.
  • Consumer가 Queue를 구독하면, Broker는 consumer tag를 발행합니다.(구독 시 원하는 consumer tag도 명시 가능)
  • Queue에 메시지가 들어오면, 해당 Queue를 구독하는 consumer tag를 찾아 해당 Channel로 메시지를 전달합니다.
  • Consumer 입장에서, Channel로부터 전달받은 메시지가 어떤 Queue로부터 온 것인지 구분하기 위해 Broker는 메시지 Frame에 consumer tag를 붙여서 보냅니다.
• channel: Consumer가 메시지를 전달받기 위한 Channel입니다.
• acknowledgement mode: 메시지 수신응답 방식입니다.
  • acknowledgement mode: automatic
    • 메시지를 수신받은 후, 즉시 ACK를 반환합니다.
  • acknowledgement mode: explicit
    • 메시지를 수신받은 후, 클라이언트 로직(비즈니스 로직)을 수행한 다음 ACK를 반환합니다.
• prefetch-count: Consumer가 ACK를 보내기 전까지 Broker가 한 번에 보낼 수 있는 메시지의 최대 갯수입니다.
  • 메시지를 전달받은 Consumer가 메시지를 처리하는 동안, Broker는 ACK를 기다리지 않고, prefetch-count만큼 메시지를 계속해서 전달합니다.
  • Consumer의 메시지 처리 속도를 고려하기 위해 존재합니다.

동작

1. Broker에게 특정 Queue에 대한 Consumer 생성 명령을 전송합니다.
   • Basic.Consume Method Frame을 통해 이루어집니다.
   • 이 때, Basic.Consume Method Frame을 보낸 Channel 위에서 구독이 발생합니다.
   • Broker는 consumer tag를 생성한 후, Channel과 Queue 그리고 consumer tag를 연결하는 레코드를 생성합니다.
     • 구독 시 원하는 consumer tag를 명시할 수도 있습니다.
2. Broker가 메시지를 발송합니다.
   • Broker는 Queue에 메시지 인입 시, 해당 Queue와 연결된 consumer tag를 찾고, 연결된 Channel로 메시지를 발송합니다.
3. 메시지를 전달받은 Consumer는 acknowledgement mode에 따라 ACK를 응답합니다.

7. 마치며

여러분들은 그동안 Spring AMQP와 같은 라이브러리를 사용하며 메서드 하나로 메시지를 아주 편리하게 주고받았습니다. 잘 만들어진 도구들이 복잡한 내부 사정을 우아하게 감추어주었기 때문입니다. 이 방대한 명세서를 한 페이지씩 공부하지 않아도 비즈니스 로직을 구현하고 서비스를 배포하는 데에는 별다른 문제가 없습니다.

사실, 저는 RabbitMQ를 사용/운영해 본 경험이 없습니다. 이 사실에 실망하셨나요? 혹은 "써보지도 않았으면서 원리를 논하나?"라는 의구심이 드시나요?

‘사용’이란 무엇일까요?

사용하다: (사람이 사물을) 어떤 목적이나 기능에 맞게 필요로 하거나 소용이 되는 곳에 쓰다. 출처: 네이버 백과사전

현대 개발 시대에서, 많은 개발자들은 자신이 작성한 메서드 아래에 숨어 있는 블랙박스에는 관심을 가지지 않고, ‘동작’하는 것에 관심을 가집니다. 이것이 나쁘다는 이야기는 아닙니다. 내부의 복잡한 구조를 모르더라도, 문제를 해결하기 위한 다양한 라이브러리 활용법을 아는 것도 훌륭한 능력입니다.

그러나, 저는 코드 한 줄을 작성하는 것보다는 동작 원리를 학습하는 것이 더 재미있어 보였습니다. RabbitMQ를 사용해 본 경험이 없더라도, 저는 이제 메시지 브로커를 잘 활용할 자신이 있습니다.

긴 글 읽어주셔서 감사합니다.

참고 문서 https://www.amqp.org/specification/0-9-1/amqp-org-download Advanced Message Queuing Protocol (AMQP) Protocol Specification, Version 0-9-1

https://queue.acm.org/detail.cfm?id=1255424 Toward a Commodity Enterprise Middleware - John O'Hara, JPMorgan