9월 4주 있었던 일 정리

Introduction

회사에 입사하고 나서 실무에서 많은 경험을 하고 있는데, 귀중한 경험을 정리하지 않고 떠나보내는게 너무 아쉬워 매 주 글을 정리 해볼까 해

1. 트러블 슈팅 - PrematureCloseException 에러
2. 프로젝트 중간 점검
3. 오랜만에 경함한 공유의 기쁨

1. 트러블 슈팅 - PrematureCloseException 에러

운영 환경에서 실행하는 도중 다음과 같은 에러가 발생했고, 전달되어야 할 API 요청과 이후 실행되어야 할 Job이 실행되지 않았어. 본문 내용을 추측했을 때, 응답을 보내기 전 Connection 이 영구적으로 닫힌 모습을 볼 수 있었어.

reactor.netty.http.client.HttpClientConnect    : [6c3afa98-2, L:/x.x.x.x:x ! R:api/x.x.x.x:x] The connection observed an error
reactor.netty.http.client.PrematureCloseException: Connection prematurely closed BEFORE response
reactor.core.publisher.Operators         : Operator called default onErrorDropped

Error has been observed at the following site(s):
*__checkpoint ⇢ Request to PATCH http://api:8080/complete [DefaultWebClient]

서비스의 흐름으로 유추 할 때 backup 과정에서 대기하는 시간이 길어지다보니 Connection이 닫힌듯 해.

본문 내용을 추측 해 문제 상황을 구성하기 위해 다음과 같이 코드를 작성했어!

public Mono<Void> backup(int limit, int offset) {
    return registrations
        .flatMap(api::progressBackup)
        .flatMap(registration -> {
            // 4 분 동안 대기
            Thread.sleep(4*60*1000);
            return Flux.just(registration);
        }).flatMap(api::completeBackup)
        .then();
}

위 코드에서 동일한 예외가 발생했고, 이와 관련된 문서화를 통해 문제를 해결 해보려고 다음처럼 정리했어.

서버들은 keep-alive 를 유지하기 위해 probe 를 보낸다.
서버들은 자신들의 커넥션을 지속적으로 관리한다.
자신이나 상대가 커넥션을 끊었는데, 통신을 하려하면 문제가 된다.

해결 방법 1 - evictInBackground 메서드 사용

백그라운드 제거를 사용하도록 설정하면 커넥션 풀에서 닫힌 커넥션들을 주기적으로 정리하게 돼.

즉, webclient 에서 사용하는 connection pool 내부에 연결이 끊긴 커넥션을 방출하는 작업을 한다고 볼 수 있어.

public final SPEC evictInBackground(Duration evictionInterval) {
	this.evictionInterval = Objects.requireNonNull(evictionInterval, "evictionInterval");
	return get();
}

해결 방법 2 - `KeepAlive`를 계속해서 유지한다.

SO_KEEPALIVE를 설정하게 되면 연결이 일정 시간 동안 유휴 상태로 유지될 수 있도록 통신하는 피어에 probe를 계속해서 보내고 있어.

Keepalive는 프로브를 통해 연결이 계속 작동 중임을 확신 할 수 있습니다. 실제로 프로브는 크기가 0인 데이터 패킷을 사용해 TCP 연결을 유지하게 됩니다. 스트림을 전달하는 도중에 프로브가 주기적으로 전달되도 사용자 프로그램에 위험하지 않습니다.

실제로 어떻게 전달받는지 확인하기 위해서 Wireshark를 활용해서 패킷을 캡처했어. Wireshark 덕분에 MySQL 과 인텔리제이 간 연결을 유지하기 위해 prove 를 주고 받는 모습을 볼 수 있었어! 신기하더라 ㅋㅋ

X.900015	SIP	DIP	TCP	44	[TCP Keep-Alive] 3306 → 53226 [ACK] Seq=2834 Ack=488 Win=407808 Len=0
X.900073	DIP	SIP	TCP	56	[TCP Keep-Alive ACK] 53226 → 3306 [ACK] Seq=488 Ack=2835 Win=405440 Len=0 TSval=xxx TSecr=xxx

확인 중에 알 수 있었던 건 인텔리제이에서 DB 와 세션을 유지 할 때, 53XXX 포트 번호를 사용하고 있더라.

서버간에 통신을 확인하고 싶어 패킷을 조사 했지만, 도커 통신으로 이뤄지고 있던터라 패킷 분석이 어려웠어 ㅜㅜ 😭 도커와 관련된 지식이 아쉽더라,,, 꼭 학습해야겠어 🔥

참고자료

적용한 내용

아쉽게도 SO_KEEPALIVE는 제대로 동작하지 않고 커넥션이 끊긴 모습을 확인했고 주기적으로 프로브가 제대로 전달되지 않고 있었어. SO_KEEPALIVE를 사용하게 되면 쉽게 관리 할 수 있을 텐데 말이지,,, 결국 evictInBackground 메서드 사용해 주기적으로 커넥션을 관리할 수 있도록 설정했어.

Configuration.java

    @Bean
    WebClient webclient() {
+        final var provider = ConnectionProvider.builder("provider")
+                .maxConnections(10)
+                .maxIdleTime(_58_SECONDS)
+                .maxLifeTime(_58_SECONDS)
+                .pendingAcquireTimeout(_5_SECONDS)
+                .pendingAcquireMaxCount(INFINITY)
+                .evictInBackground(_30_SECONDS)
+                .lifo()
+                .metrics(true)
+                .build();
        return WebClient.builder()
                .baseUrl(baseUrl)
+                .clientConnector(new ReactorClientHttpConnector(
+                        HttpClient.create(provider)
+                                .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, _3_SECONDS)
+                                .doOnConnected(connection -> connection
+                                        .addHandlerLast(new ReadTimeoutHandler(FIVE))
+                                        .addHandlerLast(new WriteTimeoutHandler(FIVE))
+                                )))
                .codecs(config -> config.defaultCodecs().maxInMemorySize(_2_MEGA_BYTES))
                .build();
    }
},