모종닷컴

Docker 이미지 변경 후 TLS Handshake가 깨졌다 (2) — 정말 TLS_RSA_* 하나가 원인의 전부였을까?

모종 — Mon, 13 Jul 2026 20:12:55 +0900

지난 글에서 Docker 이미지를 변경한 뒤 외부 서비스와의 TLS Handshake가 실패했고, JDK 17.0.18부터 java.security의 jdk.tls.disabledAlgorithms에 TLS_RSA_*가 추가된 것이 직접적인 원인이라고 판단했습니다.

운영 장애를 빠르게 복구해야 했기 때문에 -Djava.security.properties를 이용해 TLS 정책을 재정의했고, 실제로 문제도 해결되었습니다.

하지만 장애가 해결된 이후에도 한 가지 의문이 계속 머릿속을 떠나지 않았습니다.

정말 TLS_RSA_* 하나만이 원인이었을까?

해당 외부 서비스는 정말 TLS_RSA_*밖에 사용할 수 없는 서버였을까?

첫 번째 단서: Cipher Suite 재확인

가장 먼저 해당 서버가 실제로 어떤 Cipher Suite를 지원하는지 다시 확인했습니다.

sslscan으로 TLSv1.2에서 지원하는 Cipher를 확인해 보니 1편과 같은 결과를 다시 볼 수 있었습니다.

Preferred TLSv1.2  AES128-GCM-SHA256
Accepted  AES256-GCM-SHA384
Accepted  AES128-SHA
Accepted  AES256-SHA
Accepted  DHE-RSA-AES128-GCM-SHA256
Accepted  DHE-RSA-AES256-GCM-SHA384
Accepted  DHE-RSA-AES128-SHA256
Accepted  DHE-RSA-AES256-SHA256
...

지난 글에서 살펴봤던 disabledAlgorithms는 Forward Secrecy가 없는 정적 RSA Key Exchange(TLS_RSA_*)만 비활성화합니다.

그런데 서버는 TLS_DHE_RSA_* 계열도 지원하고 있었습니다.

즉,

굳이 TLS_RSA_*를 사용하지 않아도 TLS Handshake가 가능해야 하는 것 아닌가?

라는 새로운 의문이 생겼습니다.

JSSE로 직접 연결해 보자

가설을 검증하기 위해 Spring Boot와 Reactor Netty를 모두 제거하고 순수 JSSE만 사용하여 TLS 연결을 시도했습니다.

HANDSHAKE SUCCESS
cipher=TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
protocol=TLSv1.2

JDK 17.0.19에서도 TLS_DHE_RSA_*는 아무 문제 없이 사용할 수 있었습니다.

이 결과를 보는 순간 이런 생각이 들었습니다.

JVM 보안 정책을 우회할 필요가 없었던 것 아닐까?

Forward Secrecy를 지원하는 TLS_DHE_RSA_*만 사용하면 disabledAlgorithms를 건드리지 않아도 충분할 것처럼 보였습니다.

WebClient 설정하면서 Cipher Suite가 대체되었을까?

외부 서비스와의 통신을 위해 서버는 webClient를 사용하고 있었습니다. 따라서 다음으로 의심이 가는 부분은 WebClient 설정에서 Cipher Suite가 대체가 된 것이 아닐까 싶었습니다.

@Bean
fun customClientHttpConnector(): ClientHttpConnector {
    val sslContext =
        SslContextBuilder.forClient()
            .protocols("TLSv1.2")
            ...
            .build()
    val httpClient = HttpClient.create().secure { it.sslContext(sslContext) }
    return ReactorClientHttpConnector(httpClient)
}

...

private val webClient =
    webClientBuilder
        .baseUrl("xxx.xxx.xxx")
        .clientConnector(customClientHttpConnector)
        .exchangeStrategies(
            ExchangeStrategies.builder()
                .codecs { it.defaultCodecs().maxInMemorySize(MAX_BUFFER_BYTES) }
                .build(),
        )
        .build()

기존 코드 Netty의 SslContextBuilder로 이 상태의 cipher 후보를 직접 찍어봤습니다.

===== Netty engine enabled cipher suites (no explicit .ciphers()) =====
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
Exception in thread "main" javax.net.ssl.SSLHandshakeException: (handshake_failure) Received fatal alert: handshake_failure

ECDHE 계열 6종뿐이었습니다. 이전에 sslscan 목록에 ECDHE가 단 하나도 없었습니다 — 전부 RSA 정적 키교환 또는 DHE_RSA 뿐이었습니다. 그렇다면 JDK TLS 정책 문제와 상관없이 SslContextBuilder의 Cipher Suite 목록에서 이미 협의할 Cipher가 없기에 TLS 통신이 안된 거라고 생각했습니다.

근데 의문이 생겼습니다. 이전 코드에서도 WebClient를 사용해서 통신했었는데 이전에는 왜 실패하지 않았을까?

이전 코드에서는 왜 정상 동작했을까?

여기서 저의 큰 착각이 드러났습니다. 원래 운영 코드에는 TLS 설정이 전혀 없었습니다.

이슈를 해결하는 과정에서 자연스럽게 SslContextBuilder를 사용하게 되었는데, 이전에는 SslContextBuilder 기반의 ClientHttpConnector를 사용하지 않고 있었습니다.

@Bean
fun customWebClient(): WebClient =
    WebClient.builder()
        .baseUrl("xxx.xxx.xxx")
        .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
        .build()

그렇다면 이전에는 기본 설정(Spring Boot가 만드는 순정 WebClient)으로 정상 동작했다는 뜻입니다.

기본 설정 Cipher를 확인해 보자

reactor-netty의 HttpClient.create()가 .secure()를 아예 호출하지 않을 때 실제로 쓰는 SslProvider.defaultClientProvider()를 직접 뽑아봤습니다.

===== reactor-netty SslProvider.defaultClientProvider() enabled cipher suites =====
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256      ← Netty raw 기본값엔 없던 항목
TLS_RSA_WITH_AES_128_CBC_SHA        ← 
TLS_RSA_WITH_AES_256_CBC_SHA        ←
TLS_AES_128_GCM_SHA256   (TLS 1.3)
TLS_AES_256_GCM_SHA384   (TLS 1.3)
[real socket] handshake SUCCESS, cipher=TLS_RSA_WITH_AES_128_GCM_SHA256, protocol=TLSv1.2

Netty를 직접 호출했을 때의 기본 cipher 목록과, reactor-netty(Spring WebClient가 실제로 쓰는 경로)의 기본 cipher 목록은 서로 달랐습니다. 후자는 RSA-static 계열까지 포함하고 있고, 그래서 외부 서비스가 가장 선호하는 cipher(AES128-GCM-SHA256)로 정상 협상이 됐습니다. "cipher를 아무것도 안 건드린" 원래 코드가 실제로 작동했던 이유가 바로 이거였습니다.

마지막 확인: JDK 패치가 정말 이 목록을 바꾸는가

같은 테스트 코드를 로컬 JDK(17.0.16, 지난 글에서 비교했던 그 버전)와, 실제 운영과 동일한 eclipse-temurin:17-jre-jammy(JDK 17.0.19+10) 컨테이너에서 각각 테스트해 봤습니다.

로컬 (JDK 17.0.16)

TLS_RSA_WITH_AES_128_GCM_SHA256   ✅ 있음
TLS_RSA_WITH_AES_128_CBC_SHA      ✅ 있음
TLS_RSA_WITH_AES_256_CBC_SHA      ✅ 있음
→ handshake SUCCESS

jammy (JDK 17.0.19+10, 운영과 동일)

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
→ SSLHandshakeException: (handshake_failure) Received fatal alert: handshake_failure

똑같은 코드인데, JDK 패치 버전만 다르게 돌렸더니 enabledCipherSuites 목록에서 RSA-static 3종이 통째로 사라졌습니다.

결론: 인과관계 전체 그림

JDK 17.0.19 이전 (구 alpine)
  reactor-netty 기본 cipher 목록 = ECDHE 6종 + RSA-static 3종 + TLS1.3 2종
  → 외부 서비스가 선호하는 TLS_RSA_WITH_AES_128_GCM_SHA256로 정상 협상
JDK 17.0.19+10 (jammy)
  disabledAlgorithms가 RSA-static 3종을 enabledCipherSuites에서 제거
  → 남은 건 ECDHE + TLS1.3뿐인데 외부 서비스는 ECDHE, TLS1.3 를 전혀 지원하지 않음
  → handshake_failure (실제 장애)

지난 글에서 던졌던 "정말 TLS_RSA_* 하나가 원인의 전부였을까"라는 의문에 대한 답은 결국 맞았습니다, 그게 유일한 원인이었습니다. 다만 그 과정에서 아무도 몰랐던 사실 두 가지를 덤으로 얻을 수 있었습니다.

SslContextBuilder를 직접 호출한 기본값과 HttpClient.create()가 알아서 쓰는 기본값은 서로 다른 cipher 목록을 갖는다 — 뭔가를 "명시적으로 설정"하는 순간, 의도치 않게 더 안전한(넓은) 기본값에서 이탈할 수 있다.
JDK tls 정책을 우회하지 않고도 가능한 Cipher Suite가 존재했다.

후속 조치: JVM 플래그를 걷어내다

TLS_DHE_RSA_* 계열은 forward secrecy가 있어서 애초에 disabledAlgorithms 제약에 걸리지 않습니다. 따라서 cipher를 이걸로 명시하면 JVM 보안 정책을 건드릴 필요가 없습니다.

// Before
.ciphers(listOf("TLS_RSA_WITH_AES_128_GCM_SHA256"), SupportedCipherSuiteFilter.INSTANCE)
// After
.ciphers(
    listOf(
        "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256",
        "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384",
    ),
    SupportedCipherSuiteFilter.INSTANCE,
)

지난 글 마지막에 "이게 정말 원인의 전부인지는 좀 더 파봐야 할 것 같다"라고 적었던 게, 결과적으로 원래 진단이 맞았다는 걸 재확인하는 여정이 됐습니다. 다만 그 여정에서 실제 재현 테스트 코드와 프로덕션 코드가 서로 다른 경로를 타고 있었다는 걸 늦게 알아챈 게 가장 뼈아픈 삽질이었습니다 — 가설을 검증할 땐 반드시 실제 코드 경로를 그대로 태워봐야 한다는 걸 다시 한번 배울 수 있었습니다.

다음 편으로는 그렇다면 JDK 17.0.18부터 왜 TLS_RSA를 비활성화했을까? 에 대한 글을 이어서 써보도록 하겠습니다.

Docker 이미지 변경 후 TLS Handshake가 깨졌다

모종 — Sun, 12 Jul 2026 20:40:20 +0900

Docker 이미지를 변경했더니 TLS Handshake가 실패했다

운영 환경에서 Docker Base Image를 변경한 뒤 예상하지 못한 장애를 경험했습니다.

애플리케이션 코드도 변경하지 않았고, 외부 서비스도 변경되지 않았습니다.

정말 Docker 이미지만 변경했을 뿐인데 특정 외부 서비스와의 HTTPS 통신이 모두 실패하기 시작했습니다.

처음에는 단순히 JDK 업데이트로 인해 TLS 정책이 변경된 것이라고 생각했고 가볍게 대처하였습니다.

하지만 문제를 추적하는 과정을 통해 정확한 원인을 짚고, 올바른 대처를 할 수 있었습니다.

이번 글에서는 장애를 어떻게 분석했고 어떤 가설을 세우며 원인을 좁혀갔는지를 정리해보려고 합니다.

장애 발생

운영 환경에서는 Spring Boot의 WebClient를 사용하여 외부 기관과 HTTPS 통신을 수행하고 있습니다.

Docker Base Image를 변경한 후 기존과 동일한 애플리케이션을 배포했는데, 특정 기관과의 통신에서 아래와 같은 예외가 발생하기 시작했습니다.

javax.net.ssl.SSLHandshakeException

Received fatal alert: handshake_failure

흥미로운 점은 다음과 같았습니다.

애플리케이션 코드는 변경되지 않았다.
요청 데이터도 동일했다.
다른 외부 기관과는 정상적으로 통신된다.
특정 기관과만 실패한다.
로컬에서는 정상적으로 동작한다.

즉,

운영 환경에서만 특정 외부 서비스와 TLS Handshake가 실패하는 상황이었습니다.

TLS Handshake가 왜 실패하는 걸까?

SSLHandshakeException이라는 예외만으로는 원인을 알 수 없습니다.

TLS Handshake 실패는 다양한 이유로 발생할 수 있기 때문입니다.

예를 들어

인증서 문제
TLS Version 불일치
Cipher Suite 협상 실패
Trust Store 문제
SNI 문제
서버 정책 변경

등 여러 가능성이 존재합니다.

처음부터 TLS Debug 로그를 켜는 것보다 먼저 외부 서버가 어떤 TLS 환경을 제공하는지 확인하기로 했습니다.

OpenSSL로 TLS 연결 확인

가장 먼저 OpenSSL을 이용하여 외부 서버와 직접 TLS 연결을 시도했습니다.

openssl s_client -connect xxx.xxx.xxx:443

결과는 정상적으로 연결되었습니다.

Verification: OK

Protocol : TLSv1.2
Cipher   : AES128-GCM-SHA256

즉,

인증서는 정상
TLS 연결도 정상
TLS 1.2로 통신 가능

이라는 사실을 확인했습니다.

적어도 서버 자체가 죽어있거나 인증서가 만료된 것은 아니었습니다.

서버는 어떤 Cipher Suite를 지원할까?

다음으로 확인한 것은 서버가 지원하는 Cipher Suite였습니다.

이를 위해 sslscan을 사용했습니다.

sslscan xxx.xxx.xxx

결과를 보면 TLS 1.2에서 다음과 같은 Cipher Suite를 지원하고 있었습니다.

Preferred TLSv1.2

AES128-GCM-SHA256

Accepted
AES256-GCM-SHA384
AES128-SHA
AES256-SHA
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
...

여기서 중요한 사실은

서버는 TLS 1.2를 지원하며, 여러 종류의 Cipher Suite를 지원한다.

는 것이었습니다.

이 시점에서는 아직 어느 Cipher가 실제로 선택되는지, 어떤 Cipher 때문에 Handshake가 실패하는지는 알 수 없었습니다.

Docker 이미지가 바뀌면서 무엇이 달라졌을까?

애플리케이션 코드는 변경되지 않았습니다.

Spring Boot도 동일했습니다.

Reactor Netty 버전도 동일했습니다.

결국 가장 큰 차이는 Docker Base Image에 포함된 JDK 버전이었습니다.

기존 이미지는

JDK 17.0.16

새로운 이미지는

JDK 17.0.19

를 사용하고 있었습니다.

그래서 자연스럽게

JDK의 TLS 정책이 변경된 것은 아닐까?

라는 가설을 세우게 되었습니다.

TLS Debug 로그 확인

TLS Debug 로그를 활성화했습니다.

-Djavax.net.debug=ssl,handshake

실제로 로그를 출력해보면 수천 줄의 로그가 생성됩니다.

그런데 로그 초반부터 반복해서 나타나는 내용이 있었습니다.

Ignore disabled cipher suite:

TLS_RSA_WITH_AES_128_GCM_SHA256

Ignore disabled cipher suite:

TLS_RSA_WITH_AES_256_GCM_SHA384

...

JDK가 일부 Cipher Suite를 협상 후보에서 제외하고 있다는 의미였습니다.

JDK 정책 확인

이번에는 JDK의 java.security 파일을 확인해보았습니다.

JDK 17.0.19에는 다음과 같은 설정이 존재했습니다.

jdk.tls.disabledAlgorithms=
...
TLS_RSA_*
...

즉,

TLS_RSA_* Cipher Suite가 기본적으로 비활성화되도록 변경된 것입니다.

지금까지의 결과를 종합하면

OpenSSL에서는 정상 연결된다.
JDK는 TLS_RSA_*를 비활성화한다.
TLS Handshake는 실패한다.

이 세 가지 사실을 확인할 수 있었습니다.

당시 내렸던 결론

이 시점에서 저는

JDK가 TLS_RSA를 기본적으로 비활성화하면서 TLS Handshake가 실패한 것

이라고 판단했습니다.

그래서 운영 환경에서는 java.security 정책을 우회하여 TLS_RSA_*를 다시 사용할 수 있도록 설정했고, 실제로 장애도 해결되었습니다.

운영 장애를 빠르게 복구해야 하는 상황에서는 충분히 합리적인 판단이었습니다.

그런데 정말 원인은 TLS_RSA였을까?

장애는 해결되었지만 한 가지 의문이 계속 남아있었습니다.

상대 서버는 여러 Cipher Suite를 지원하고 있는데,

정말 TLS_RSA_* 하나만 사용할 수 있었던 걸까?

혹시 JDK의 보안 정책이 아니라 다른 원인이 있었던 것은 아닐까?

그래서 운영 장애가 해결된 이후, 문제를 처음부터 다시 재현하며 하나씩 검증해보기 시작했습니다.

다음 글에서는 순수 JSSE와 Netty를 각각 이용하여 동일한 환경에서 TLS Handshake를 재현해보면서, 왜 JSSE는 성공했는데 Netty(WebClient)는 실패했는지, 그리고 실제 원인이 무엇이었는지를 자세히 살펴보겠습니다.

MacOS F1~F12 기본 기능키로 바꾸기

모종 — Sun, 2 Nov 2025 21:15:16 +0900

macOS에서는 기본적으로 F1~F12 키가 ‘특수 기능 키(밝기, 소리, 재생 등)’로 동작하고, 실제 F1~F12 기능을 쓰려면 Fn 키(또는 Globe 키=지구모양 키)를 함께 눌러야 합니다.

MacOS를 사용하다보면 "특수 기능"보다는 "기본 기능"을 많이 사용하므로, 저의 경우 F?? 키를 눌렀을 때 기본 기능키로 바꾸는게 적합한 것 같았습니다.

1. 키보드 단축키 설정 들어가기
"시스템 설정" -> 좌측 "키보드" 메뉴 -> "키보드 단축키"

2. F? 키를 표준 기능키로 사용 활성화

좌측 "기능 키" -> 기능 활성화

이 기능을 활성화 한 이후에 특수 기능(예: F11(소리 줄이기))을 사용하려면 설명에 나와있듯이 "Fn" 키를 누르면 됩니다.

컨테이너 환경에 따른 GC 전략

모종 — Thu, 30 Oct 2025 18:03:43 +0900

도커 컨테이너로 자바 애플리케이션을 실행한 후 모니터링을 하다보니 제가 알고 있던 가비지 컬렉션 동작과는 다르다는 것을 발견했습니다.

당시 Oracle Linux Server 리눅스 서버와 openjdk 21를 사용했습니다. 추가로 컨테이너 메모리를 1GB로 제한하였습니다. 이렇게 구성하였을 때 아래와 같이 GC 로그와 자바 버전을 출력해보았습니다.

bash-4.4# java -Xlog:gc --version
[0.002s][info][gc] Using Serial
openjdk 21 2023-09-19
OpenJDK Runtime Environment (build 21+35-2513)
OpenJDK 64-Bit Server VM (build 21+35-2513, mixed mode, sharing)

여기서 첫 번째 줄을 보니 GC 전략이 Serial로 되있다는 것을 발견하였습니다.

Java Ergonomics

HotSpot Virtual Machine Garbage Collection Tunning Guide

HotSpot Virtual Machine Garbage Collection Tuning Guide

Ergonomics is the process by which the Java Virtual Machine (JVM) and garbage collection heuristics, such as behavior-based heuristics, improve application performance.

docs.oracle.com

가비지 컬렉터, 힙 크기 및 런타임 컴파일러 기본 선택 사항에 대한 내용을 담고 있는 내용입니다. 아래와 같이 정리할 수 있습니다.

서버급 시스템에서는 G1 컬렉터, 그렇지 않으면 Serial 컬렉터.
최대 GC 스레드 수는 힙 크기와 사용 가능한 CPU 리소스에 의해 제한
초기 힙 크기 : 물리적 메모리의 1/64
최대 힙 크기는 실제 메모리의 1/4
계층형 컴파일어, C1과 C2 모두 사용

여기서 주목했던 건 당연히 첫 번째 항목입니다. 여기서 말하는 서버급 시스템의 기준은 무엇일까요? 이에 대한 내용도 언급되어 있는데 VM이 두 개 이상의 프로세서와 1792MB 이상의 힙 크기를 감지하면 VM은 머신을 서버급으로 간주한다고 합니다.

즉 위에서 제가 경험했던 문제는 컨테이너에 1GB 메모리 제한을 걸게됨으로서 위에서 얘기하는 서버급 시스템이 아니게 되어 Serial 컬렉터가 사용됬다라는 것을 알 수 있었습니다.

따라서 도커 컨테이너 메모리 제한을 2GB로 설정한 후 다시 GC 로그를 출력해보면 아래와 같이 G1 컬렉터가 사용되는 것을 볼 수 있습니다.

bash-4.4# java -Xlog:gc --version
[0.002s][info][gc] Using G1
openjdk 21 2023-09-19
OpenJDK Runtime Environment (build 21+35-2513)
OpenJDK 64-Bit Server VM (build 21+35-2513, mixed mode, sharing)

Compressed Class 영역

모종 — Sun, 19 Oct 2025 22:10:29 +0900

Docker Container에 리소스 제한 설정을 CPU(1.0), Memory(1GB)로 설정한 후 JVM 메트릭을 확인하는데 Non-heap 영역이 1GB가 넘게 할당되있는 것을 봤습니다.

메모리는 일단 아래와 같이 할당되었습니다.

JVM Heap : 248MiB
JVM Non-Heap : 1.23GiB

혹시 컨테이너 메모리 제한을 잘못설정한건지 리눅스 cgroup을 봤지만 리소스 제한은 잘 된것으로 보였습니다.

컨테이너 메모리는 1GB로 설정했는데 어떻게 된 일 일까요??

Compressed Class 영역

JVM Non-Heap을 들여다 보니 metaspace가 -1B, Compressed Class: 1GiB가 할당되었고, 나머지 240MiB는 기타 다른 영역에 할당됬습니다.
결국 이 Compressed Class라는 영역이 엄청크게 할당되있었습니다.

Compressed Class 영역에 대하여 알아봐야겠습니다.

UseCompressedOops + UseCompressedClassPointers 활성화시 클래스 메타데이터를 위해 네이티브 메모리 상에서 논리적으로 두 개의 다른 영역이 사용됩니다.
일반적인 메타데이터는 Metaspace 영역, 클래스 참조용 포인터는 Compressed Class 영역에 저장되게 됩니다.
CompressedClassPointer는 64비트 프로세스 환경에서 클래스 포인터를 표현할 때 32비트 오프셋을 사용하여 표현됩니다.
CompressedClass 영역의 사이즈 디폴트값은 1GB (-XX:CompressedClassSpaceSize)로 설정되어 있습니다.
클래스 포인터를 위한 공간은 최초 예약 공간이며 필요에 따라 커밋됩니다.

정리하자면 Compressed Class 영역은 클래스 포인터가 저장되는 영역이고, 디폴트가 1GB로 설정되있다는 것을 알 수 있었습니다.

추가 의문: Compressed Class Pointer 방식이 왜 필요한가?

64비트 컴퓨터의 주소 참조를 위해 64비트 포인터를 사용할 수 있습니다. 하지만 대부분 애플리케이션은 64비트 주소 공간 전체를 다 쓰는 경우는 없기 때문에 64비트를 낭비하지 않고, 더 작은 32비트 포인터로 대체하기 위함인것으로 보입니다.

추가 의문: OS는 왜 1GB 넘는 공간을 요구하는 애플리케이션을 실행시켜준걸까?

Compressed Class 영역은 해당 공간을 예약만 하는 가상 주소이지 실제 물리 메모리를 즉시 할당(commit)하지 않기 때문에 실행시켜준게 아닐까 싶습니다.

즉 JVM 메트릭에서 1.23 GiB가 할당된 상태로 애플리케이션이 올라간것처럼 보이지만 실제 메모리에 할당된 상태는 아니라고 볼 수 있을 것 같습니다.

10,000 foot view

모종 — Sun, 12 Oct 2025 01:55:50 +0900

NATS 보다가 "10,000 foot view"가 나와서 뭔가 싶었는데 비행기가 10,000피트 상공에서 아래를 내려다보는 것처럼, 아주 높은 관점에서 전체적인 그림만 보는 개요(overview)를 뜻한다고 합니다.

세부적인 기술적 내용이나 구현 방법이 아닌, 어떤 문제를 해결하려고 하는지 혹은 큰 구조가 어떻게 되는지 등 "큰 그림"을 설명할 때 쓰는 말입니다!

이런 비슷한 표현들이 있나 좀 더 찾아봤습니다.

	직역	의미
30,000 foot view / 50,000 foot view	3만/5만 피트 상공에서 본 관점	10,000피트보다 더 높은 곳에서 바라본다는 뜻으로, 매우 거시적인 시각으로 전체를 바라본다는 뜻입니다.
Big picture	큰 그림	가장 흔한 표현으로 세부보단 전체 흐름을 보자는 뜻입니다.
High-level overview	고수준 개요	기술 문서나 회의에서 요약 설명을 할 때 자주 사용되는 표현입니다.
Bird's eye view	새의 눈에서 본 관점	10,000 foot view와 비슷한 맥락입니다.

Spring EventListener do not working

모종 — Sat, 11 Oct 2025 19:48:00 +0900

@Component
class Test(...) {
    init {
        eventPublihser.publishEvent(TestEvent())
    }
}


@Service
class TestService {
  @EventListener(TestEvent::class)
  fun handleEvent(event: TestEvent) {
      log.info { "hello" }
  }
}

이슈

위와 같은 코드를 작성했을 때 애플리케이션이 켜지면 “hello”가 출력되기를 기대했으나 출력이 안됨.

반면 API를 하나 만들어서 동일한 코드를 실행하면 Listener에서 감지가 된다.

원인

/** Class SimpleApplicationEventMulticaster **/

    @Override
    public void multicastEvent(ApplicationEvent event, @Nullable ResolvableType eventType) {
        ResolvableType type = (eventType != null ? eventType : ResolvableType.forInstance(event));
        Executor executor = getTaskExecutor();
        for (ApplicationListener<?> listener : getApplicationListeners(event, type)) {
            if (executor != null && listener.supportsAsyncExecution()) {
                try {
                    executor.execute(() -> invokeListener(listener, event));
                }
                catch (RejectedExecutionException ex) {
                    // Probably on shutdown -> invoke listener locally instead
                    invokeListener(listener, event);
                }
            }
            else {
                invokeListener(listener, event);
            }
        }
    }

애플리케이션 init 에서 publishEvent와 api로 publishEvent 한 것이 어떤 차이가 나는지를 확인해보기 위해 디버깅을 해보면 위 동작이 달라진다.
애플리케이션 시작시 publishEvent 호출은 for문의 getApplicationListeners(event, type) 결과는 0이고 API로 호출했을 때는 1이 나오면서 invoke(listener, event)가 실행된다.
위 코드는 특별한 로직이 아니다. 이벤트를 처리할 수 있는 리스너를 리턴하면 해당 리스너들에게 이벤트를 전달하는 로직이다.
init {} 코드가 실행되는 시점에는 리스너가 없었다가 api 호출 시점에는 리스너가 생겼다??
여기서 해답을 찾았는데 init이 실행된 타이밍에 TestService의 listener 등록이 늦게 된 것이다.

/** Class AbstractApplicationEventMulticaster **/
    @Override
    public void addApplicationListener(ApplicationListener<?> listener) {
        synchronized (this.defaultRetriever) {
            // Explicitly remove target for a proxy, if registered already,
            // in order to avoid double invocations of the same listener.
            Object singletonTarget = AopProxyUtils.getSingletonTarget(listener);
            if (singletonTarget instanceof ApplicationListener) {
                this.defaultRetriever.applicationListeners.remove(singletonTarget);
            }
            this.defaultRetriever.applicationListeners.add(listener);
            this.retrieverCache.clear();
        }
    }

리스너를 조회하는 코드를 타면 결국 this.defaultRetriever.applicationListeners 로부터 가져오는데 코드 마지막쯤 add코드가 보인다. 이 라인에 브레이크포인트를 걸고 condition을 입력한다.
- listener.getClass() == ApplicationListenerMethodAdapter.class && ((ApplicationListenerMethodAdapter) listener).beanName.equals("")
애플리케이션을 실행해보면 init {..} 코드가 먼저 실행되고 이후에 listeners.add 브레이크 포인트가 동작한다.

Quorum based Controller

모종 — Sun, 7 Jan 2024 17:04:56 +0900

브로커와 컨트롤러

카프카 버전 2.8 이후부터 메타데이터 관리를 주키퍼를 사용하지 않고 자체 관리하게 되었는데 이로 인해 카프카 애플리케이션의 역할은 크게 두 가지(브로커, 컨트롤러)로 구분할 수 있다. '컨트롤러'는 클러스터 수준의 메타데이터 관리 및, 리더 선출, 브로커 추가 제거 같은 클러스터 관리 작업을 하는 역할을 하며, '브로커'는 메시지의 저장 및 전송과 관련된 작업을 담당한다. 애플리케이션을 역할을 지정할 수 있는데, 브로커나 컨트롤러 중 하나의 역할만 지정할수도 있고, 브로커 겸 컨트롤러 역할도 지정할 수 있다.

Quorum based Controller

KRaft 합의 알고리즘을 통해 리더로 선출된 컨트롤러는 Active Controller라고 불리며, 그 외에 컨트롤러는 Follower Controller라고 불린다.
기존 카프카의 __consumer_offsets 토픽이나 트랜잭션 그룹 로그(__transaction_state)같이 메타데이터도 하나의 토픽(__cluster_metadata)을 가지게 되며, 이를 통해 메타데이터를 관리하게 된다. 기존에 주키퍼에 저장되던 모든 메타데이터들이 이 토픽에 저장되게 된다. 메타데이터 토픽의 리더는 당연히 Active Controller가 된다.
쿼럼에서는 주키퍼와 마찬가지로 실행이 유지되기 위해서는 노드의 과반수 이상이 실행되어있어야 한다. 이를 다시 말하자면 3개의 쿼럼 구성에서는 한 번의 장애를 , 5개의 노드 구성에서는 2번의 장애를 극복할 수 있다.

메타데이터 복제 프로세스

KRaft 알고리즘을 통해 리더를 선출하고 리더 컨트롤러가 메타데이터 로그의 리더로 메타데이터를 관리한다는 것을 알았다면 실제 메타데이터가 어떤 과정을 통해 팔로워에게 복제되는지를 알아보면 좋을 것 같다.

메타데이터 저장

만약 메타데이터에 변경 사항이 생긴다면 Active Controller는 관련 변경 내용을 메타데이터 토픽에 저장한다. 좀 더 정확히는 메타데이터 로그에 추가하기 이전에 내구성 확보를 위해 로컬 디스크(Write-ahead Log, WAL)에 먼저 기록하고 fsync를 한 후 메타데이터 토픽에 저장한다.

메타데이터 패치

Follower Controller는 주기적으로 이 메타데이터 로그에 추가된 사항이 없는지 Active Controller에게 Fetch 요청을 보내게 되는데, Active Controller는 이 응답으로 추가된 사항들을 넘겨준다. Follower Controller는 응답받은 데이터를 로컬에 적용한다.

이벤트 / 델타 모델

쿼럼에서는 메타데이터 복제에 이벤트/델타 모델 방식을 사용한다. 특정 메타데이터가 A->B로 변경되었다는 데이터를 넘겨주는 것이 아니라, 어떤 이벤트가 일어났는지를 팔로워에게 전달한다는 것이다. 이벤트/델마 모델을 사용함으로써 과한 정보들이 네트워크들을 통해 송수신되는 것을 방지할 수 있다는 게 장점이 될 것 같다.

예를 들어 브로커 하나가 다운되면서 3만 개의 메타데이터의 변화가 생겼을 때 3만개의 메타데이터를 복제해야하는 것은 큰 작업이다. 하지만 특정 브로커 하나가 다운되었다는 하나의 이벤트만 팔로워에게 넘겨주면 나머지는 팔로워가 자체적으로 3만개의 메타데이터를 변경을 가해주면 된다.

메타데이터 캐시

카프카의 클러스터의 다양한 메타데이터 정보를 빠르게 접근할 수 있게 하기 위해 메모리에 현재 메타데이터 정보를 기록하는데 이를 "메타데이터 캐시"라고 한다. 이를 통해 카프카는 메타데이터 조회를 위해 항상 디스크에 접근하지 않고 빠르게 캐시 된 데이터에 접근할 수 있어 성능이 향상된다. 같은 맥락으로 클라이언트에서 메타데이터를 요구할 때 이 메타데이터 캐시를 이용하여 빠르게 응답을 줄 수 있다.

갱신 시점

팔로워는 Fetch 요청을 통해 리더의 메타데이터 로그를 따라잡는다고 위에서 얘기했는데, 이 Fetch 요청에는 팔로워가 현재 리더 로그의 어느 지점까지 복제 완료했는지를 표현하는 데이터를 포함하게 된다. 이를 통해 Active Controller는 팔로워들이 각각 어느 지점까지 자신의 로그를 따라왔는지를 알 수 있고, 모든 노드가 복제에 성공한 최신 지점까지를 메타데이터 캐시에 적용해도 된다는 명령을 내릴 수 있다.

여기서 주의할 점은 클러스터 내 모든 노드가 복제에 성공한 최신 데이터가 저장된다는 점이다. 예를 들어 A(리더), B, C(팔로워)라는 노드가 클러스터에 참여하고 있다고 가정해 보자. A에는 메타데이터 1,2,3이 저장되어 있고, B가 1,2,3까지 복제에 성공했다. 그런데 C가 아직 1,2까지밖에 복제를 못했다고 했을 때 A, B의 메타데이터 캐시에 1,2,3이 로그가 적용된 메타데이터가 올라가게 되면 클러스터 내의 메타데이터 간의 불일치가 발생하게 된다.

새로운 클린업 정책 = 스냅샷 정책

만약 메타데이터가 무한정 쌓이게 된다면 여러 가지 문제들이 발생하게 된다. 일단 메타데이터도 토픽으로써 디스크에 저장된다 했으므로 당연히 메타데이터가 계속 쌓이게 되면 "디스크 용량 부족" 문제를 겪을 수 있다. 또한 새로운 노드가 클러스터에 참여하게 되면 현재까지 모든 메타데이터 로그를 복제해야 하므로 "동기화하는 시간이 증가"하는 문제가 있을 수도 있다. 또 현재까지의 모든 로그를 팔로워에게 전달해야 하므로 "리더 역시 리소스를 낭비"하게 된다.

기존 카프카에서는 이를 위해 토픽에 삭제 정책, 압축 정책 등이 있었으나, 메타데이터가 이벤트/델타 모델을 사용하게 되면서 기존의 클린업 정책들을 사용할 수 없어 스냅샷이라는 새로운 정책이 등장하게 되었다.

특정 시점이 되었을 때 Active Controller는 현재 메모리에 올라가 있는 메타데이터 캐시를 스냅샷 형태로 변환해서 저장한다. 그리고 현시점 기준 이전의 메타데이터 로그를 삭제한다. 이렇게 하면 새로운 노드가 참여하더라도 이전의 모든 메타데이터 로그를 넘겨주는 것이 아니라 스냅샷을 전달해주기만 하면 된다.

KRaft 합의 알고리즘

모종 — Sun, 7 Jan 2024 15:53:47 +0900

zookeeper를 이용한 카프카 메타데이터 관리

카프카 2.8 버전 이전에는 아래와 같은 메타데이터들을 관리하기 위해 zookeeper를 사용했었음.
- 클러스터 토폴로지 정보, 토픽 메타데이터, 컨트롤러 정보, 컨슈머 그룹 정보, ACLs 정보, 브로커 정보 등..

Zookeeper를 통해 메타데이터를 관리했을 떄 발생하는 문제들

Zookeeper 자체에 이슈가 있다기보다는 주키퍼를 활용하여 메타데이터를 관리하는 카프카의 방식에 여러 가지 문제가 있었음.

주키퍼라서 생기는 문제들.

주키퍼는 카프카와 별개의 분산 시스템
관리자는 카프카를 배포하기 위해 두 개의 개별 분산 시스템을 관리하고 배포하는 방법을 배워야 한다.
SASL과 같은 설정이 카프카, 주키퍼 두 시스템에 모두 적용되어야 한다.
로컬에서 간단한 테스트를 해보고 싶더라도 주키퍼, 카프카 두 가지의 애플리케이션 모두 운영해야 한다.
주키퍼 Watch의 한계점

메타데이터 복제 프로세스 문제

컨트롤러는 메타데이터 변경 사항이 생기면 클러스터 내의 브로커들에게 변경된 내용을 전파(LeaderAndISr, UpdateMetadata 등) 하도록 되어있는데, 이 전송이 성공적으로 전달되지 않으면 브로커 간의 메타데이터 상태가 불일치하게 된다.
업데이트되지 않은 노드에게 클라이언트는 메타데이터를 요구할 수 있다. 이로 인해 클라이언트는 잘못된 정보를 받을 수 있다

Quorum 기반의 메타데이터 관리

카프카의 KIP문서를 보면 이를 "post zookeeper"라고 하면서 처음 소개를 하고 있음. 카프카의 메타데이터 관리를 할 때 주키퍼를 활용하지 않고 카프카 자체적으로 메타데이터를 관리하도록 변경되었으며, 각 클러스터 간의 Quorum을 만들고 참여하는 노드 사이에 합의 알고리즘을 이용하여 메타데이터를 관리함. 이 합의 알고리즘으로 Raft 알고리즘을 사용하는데 Kafka 시스템에 좀 더 적합한 형태로 변화를 살짝 주었는데 이를 KRaft(Kafka Raft) 알고리즘이라 한다.

Raft 합의 알고리즘

분산 시스템 환경에서 모든 노드가 동일한 상태를 유지하도록 하고, 일부 노드의 결함이 전체 시스템에 영향이 없도록 동작하기 위한 합의 알고리즘

TMI로 Raft 알고리즘 이름의 유래가 재밌었는데 검색하다 보면 "Raft"라는 이름이 'reliable', 'replicated', 'redundant', 'fault-tolerant' 등의 단어의 조합된 것이 아닐까 하는 추측들이 있는데, 실제 이름을 짓는 과정에서 Raft 알고리즘의 특징인 log(통나무)라는 것을 이용하여 Paxos(Raft 이전에 자주 사용하던 합의 알고리즘, 그리스에 있는 섬이름임) 섬을 탈출한다에 집중하였고 Raft라는 이름이 등장하게 되었다고 한다.

Raft에서 등장하는 용어들을 먼저 살펴보면 아래와 같다.

Leader: 클러스터를 대표하는 노드. 모든 팔로워에게 명령을 전파한다.
Follwer: 리더를 제외한 노드. 리더로부터 전파된 명령을 로컬에서 수행
Candidate: 선거 기간 동안 리더가 될 자격을 얻은 노드. 선거에서 패하면 팔로워로 추락
Term: "제1대 대통령", "제2대 대통령"처럼 해당 선거가 몇 번째 선거인지를 나타내는 번호

Raft 합의 알고리즘의 동작 과정은 아래의 사이트를 통해 확인해 볼 수 있다.

https://thesecretlivesofdata.com/raft/

KRaft 알고리즘

KRaft 알고리즘은 Raft 알고리즘에 약간의 변형을 주어 만들었다고 했는데, Raft 알고리즘에서 리더 선출과정을 통해 선정된 Leader 노드 는 Follwer 리더에게 로그를 전달(push)하도록 되어있다. 하지만 KRaft 알고리즘에서는 반대로 Follower가 Leader노드에게 변경된 로그를 요청(pull)하도록 되어있다.

이런 변형을 준 이유로 카프카에서는 기존 시스템의 로그 레이어를 재사용하기 편하고, 리더의 과한 역할을 제거하고, 팔로워가 많아질수록 pull 방식이 적합하다고 판단하여서 팔로워가 리더에게 로그를 직접 요청하도록 수정했다고 한다.

카프카 모니터링 - 메트릭

모종 — Sat, 2 Dec 2023 16:25:29 +0900

카프카 메트릭

카프카 코드를 보다 보면 메트릭을 수집해서 특정 클래스에서 계속 계산하는 모습을 볼 수 있습니다. 해당 클래스들은 MBean을 상속받아 작성되어 있어서 내부 메트릭을 JMX를 통해 얻을 수 있습니다. 브로커 뿐만 아니라 KRaft 같은 메타데이터, Producer, Consumer 등의 메트릭도 모두 JMX를 이용할 수 있습니다. 다만 메트릭에 접근하기 위해서는 몇 가지 설정이 필요합니다.

Java Management Extensions (JMX)는 Java 애플리케이션을 모니터링하고 관리하기 위한 기술.
JMX는 MBean (Managed Bean)이라는 관리 가능한 자바 오브젝트를 사용하는데 애플리케이션은 이 MBean을 통해 다양한 정보와 작동 상태를 노출하며, 관리자 또는 모니터링 도구는 JMX 인터페이스를 통해 이러한 정보에 접근할 수 있습니다.

JMX 활성화

카프카의 실행 스크립트의 일부분을 보면 아래와 같습니다.

# JMX settings
if [ -z "$KAFKA_JMX_OPTS" ]; then
  KAFKA_JMX_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false  -Dcom.sun.management.jmxremote.ssl=false "
fi

# JMX port to use
if [  $JMX_PORT ]; then
  KAFKA_JMX_OPTS="$KAFKA_JMX_OPTS -Dcom.sun.management.jmxremote.port=$JMX_PORT "
  if ! echo "$KAFKA_JMX_OPTS" | grep -qF -- '-Dcom.sun.management.jmxremote.rmi.port=' ; then
    # If unset, set the RMI port to address issues with monitoring Kafka running in containers
    KAFKA_JMX_OPTS="$KAFKA_JMX_OPTS -Dcom.sun.management.jmxremote.rmi.port=$JMX_PORT"
  fi
fi

카프카를 실행할 때 JMX_PORT 옵션을 사용해야 합니다. 좀 더 디테일한 상세 설정이 필요하다면 KAFKA_JMX_OPTS를 사용하면 됩니다.
도커를 사용하는 경우 이와 같은 설정을 하면 됩니다.

version: "3.9"

services:
  kafka-1:
    container_name: kafka-1
    image: docker.io/bitnami/kafka:3.5
    ports:
      - 19092:9092
      - {{JMX포트}}:{{JMX포트}}
    environment:
      ...
	  ...
      # JMX
      - JMX_PORT={{JMX포트}}
      - KAFKA_JMX_OPTS=-Dcom.sun.management.jmxremote -Djava.rmi.server.hostname={{호스트명}} -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.authenticate=false  -Dcom.sun.management.jmxremote.ssl=false

JMX 초기화과정

jmx, rmi 에 대해서 간단하게 알아보고 어떤 과정을 통해 실행되는지 흝어보면 도움이 될 것 같습니다. RMI(Remote Method Invocation)는 Java에서 원격 객체 간의 상호작용을 가능하게 하는 API입니다. rmi를 사용하면 로컬에서 네트워크를 통해 다른 JVM에 있는 객체의 메서드를 호출할 수 있습니다.
JMX, RMI는 아래와 같은 과정을 거쳐 최초 초기화됩니다.

kafka가 실행하면서 jmx agent를 같이 실행
jmx agent가 실행될 때 내부적으로 rmi server가 실행됨.
kafka는 자신의 MBean인터페이스를 상속받은 메트릭 클래스들을 jmx agent에 등록

JMX Client 연결

저의 경우 jmx port를 9999번으로 설정했고, rmi port를 9998번으로 설정하였습니다. 도커로 카프카를 실행했기에 컨테이너의 "9999" 포트를 호스트의 "9999" 포트로 매핑시켜 외부에 노출시켰습니다. 이후에 jmx client인 jconsole을 사용해 연결을 시도하니 계속 실패하였습니다.
이는 연결 과정을 알고나면 굉장히 어이없는 문제입니다. Jconsole이 jmx agent와 연결되는 과정은 아래와 같습니다.

jconsole은 jmx 포트를 통해 jmx 서버에 연결을 시도
jmx 서버는 jconsole에게 rmi 포트 정보를 제공
jconsole은 전달받은 rmi 포트를 사용하여 jmx의 rmi 서버와 연결

따라서 위 문제는 jmx 포트 번호만 노출시킨다 해서 연결이 되는 게 아니라 rmi 포트도 노출시켜 주어야 해결이 가능합니다만 rmi와 jmx를 동일한 포트를 사용하도록 설정도 가능합니다. 위에서 KAFKA_JMX_OPTS에 `com.sun.management.jmxremote.rmi.port` 프로퍼티를 설정하지 않는 경우 JMX_PORT를 이용해서 rmi port, jmx port를 설정하도록 돼있으니 이점 유의해서 사용하면 됩니다.

Jconsole 실행

jconsole은 jdk에 이미 포함되어 있는 상태이기 때문에 자바가 이미 설치되어 있다면 터미널로 접속해서 "jconsole"을 입력해서 실행시켜 줄 수 있습니다.

jconsole이 실행되었다면 접속 정보를 입력해주면 되는데 주의할 점은 hostname입니다. 원래 기본값은 localhost인데 저의 경우 도커컴포즈 환경 + jmx expoter 같은 추가적인 세팅을 하다 보니 문제가 좀 있어서 `java.rmi.server.hostname`을 kafka-1로 설정해 주었습니다. 그래서 로컬 hosts 파일에 kafka-1 -> localhost로 등록해주어야 했습니다. 해당 프로퍼티를 사용하지 않은 분이라면 그냥 localhost로 접속시도하면 됩니다.
접속이 완료되면 이제 아래와 같이 메트릭을 보실수 있을 겁니다.