Search

Trouble Shooting Posts

Search

배경

Spring 3.0부터 등장했던 HTTP Template Module ‘RestTemplate’를 사용하면서 큰 문제는 없게 사용했지만, Spring 5.0에서 ‘WebClient’가 나왔고 WebClient 사용을 권고하였기에 WebClient를 주로 프로젝트에 사용해왔습니다. WebClient의 사용하면서 기존에 RestTemplate의 (멀티 스레딩, Blocking 방식) 에서 WebClient (싱글 스레드, Non-Blocking)으로 변경되어 얻을 수 있는 성능과 관리에 이점이 있었습니다. 이 글에서는 WebClient를 사용하면서 발생한 “Connection reset by peer“에 대해서 어떻게 해결해 나갔는지에 대해서 이야기해보려고 합니다.
발생한 예외: (자세한 내용은 펼치기) org.springframework.web.reactive.function.client.WebClientRequestException: readAddress(..) failed: Connection reset by peer;

해결 과정

“Connection reset by peer” 발생
현상을 이야기하면, 구현하고 변경이 없는 Thirdparty 호출 코드에서 발생한 적이 없는 예외가 발생하였습니다. 현재 프로젝트에서 WebClient를 사용하면서, “Client(Application) → Server(Thirdparty) 모델” 관계를 가지고 있습니다. 코드의 변경이 없다는 것은 다음과 같은 경우에서 예외를 발생할 가능성이 있다고 판단하였습니다. 1. Client 코드가 예외를 보완할 수 없는 경우 2. “Framework 또는 Library”와의 Integration에 문제가 있는 경우 3. 호출 대상인 Thirdparty의 Server와의 Integration에 문제가 있는 경우

“Connection reset by peer” 에러는 왜 발생하였나?

위키를 통해서 왜 “Connection reset by peer”이 발생하였는지 찾아봤습니다. 내용은 다음과 같습니다.
A “connection reset by peer” error means the TCP stream was closed, for whatever reason, from the other end of the connection. In other words, the TCP RST was sent and received, but the connection is closed. This issue may happen when you send a packet on your end of the connection, but the other end doesn’t recognize the connection. It’ll send back a packet with an RST bit to close the connection. The error can happen when the peer crashes. Other times, it’s due to poorly-written applications that don’t shut their TCP connections properly.
중요한 내용은 첫 문단입니다. 요약하자면, “‘Connection reset by peer’ 에러 발생은 TCP stream이 닫혔다는 것을 의미한다.”입니다. TCP는 “데이터 전송 제어 프로토콜”로 종단간 연결을 통해서 데이터를 어떻게 전송할지 정의합니다. 그러면 어떻게 TCP 흐름이 중단 되었는지 살펴보겠습니다. 현재 우리 서비스는 HTTP/2를 활용하고 있습니다. HTTP/2는 HTTP/1.1를 호환하는데, HTTP/1.1(RFC 2068)에서 추가된 커넥션 관련 기능인 “Keep-Alive”가 적용되면 다음 이점을 얻을 수 있습니다. 1. latency 감소 : 3-way handshake에 필요한 round-trip이 줄어들기 때문에 그만큼 latency가 감소합니다. 2. 네트워크 비용 감소 : 커넥션을 재사용하기 때문에 새로운 TCP 연결을 만들기 위해서 필요한 CPU, 메모리 리소스를 줄여줍니다. 3. HTTP 파이프라인 커넥션 : 여러 개의 요청을 파이프라이닝 할 수 있다.
그러면, 우리는 여기서 발생한 “Connection reset by peer” 에러에서 왜 TCP Stream이 닫혔는가를 살펴보기 위해서 Server에서 ‘Http Keep-Alive’를 제공하고 있는지부터 확인해보겠습니다.

Thirdparty Server는 ‘Http Keep-Alive’를 제공하는가? “아니다”

“Connection reset by peer” Exception 해결 과정
2023/01/10 11:37
http
현재 글로벌 서비스를 통해서 웹과 앱을 만들고 있습니다. 글로벌 서비스는 국내 서비스보다 개발 기획과 설계 단계에서 많은 요소를 추가 고려해야 합니다. 예시로는 ‘글로벌 언어 제공’, ‘글로벌 결제 기능 제공’, ‘글로벌 계정 인증’ 등이 있습니다. 이번에는 글로벌 서비스가 취약한 계정시스템에 대한 해커의 어뷰징 행위를 어떻게 해결하고 있는 지 정리해보려고 합니다. ** 물론! 회사와 서비스에 관련된 민감한 정보는 제외하고 작성하도록 하였습니다.
설명할 “글로벌 서비스에서 계정시스템을 지켜온 과정”은 간략하게 다음과 같습니다. 다음 3가지의 구분된 과정으로 설명합니다. 1. Business(B) : 비즈니스에 필요한 서비스 구현 2. Attack(A) : 구현된 서비스에 대한 해커의 공격 3. Reinforce(R) : 해커 공격을 방어하고 강화 4. Monitoring(M) : 서비스의 상태 모니터링 현재까지 계정시스템을 방어해온 과정은 간략하게 다음과 같습니다. B ”이메일 계정 API MVP 개발” → A “이메일 회원 가입 API DDoS 공격” → R “이메일 인증 프로세스 도입” → M “이메일 인증 프로세스 도입 이후, 어뷰징 사용자 지표 확인” → A “이메일 가입 여부 확인 API Brute Force 공격” → A “이메일 로그인 API Brute Force 공격” → R “‘AWS WAF’-’Web ACLs’-’Rule’ 적용” → M “계정 탈취 공격 방어 후, 지표 확인” → B “사용자 휴대폰 SMS 인증 도입” → A “사용자 휴대폰 SMS 인증 API Brute Force 공격” → R “Application IP Block 정책 적용” → R “Application SMS 번호인증 횟수 제한 정책 적용” → R “Application 이메일 유효성 확인 정책 적용” → M “‘휴대폰 SMS 인증’, ‘이메일 회원가입’ 어뷰징 확인”
여기서 부터는 어떻게 계정시스템이 지켜져왔는지 자세하게 설명하겠습니다.

1. Business: 이메일 계정 API MVP 개발

•
MVP Open API 개발 배포

2. Attack: 이메일 회원가입 API DDoS 공격

“이메일 회원가입” API 배포 이후, 얼마 지나지 않아 다음과 같은 어뷰징 스크립트 DDoS 공격 들어왔습니다. DDoS의 영향 DDoS 공격으로 신뢰할 수 없는 회원가입이 이루어졌고, 실제 사용자 계정과 관련없는 더미 데이터들이 DB에 쌓이게 되었습니다.
동시에 계정을 관리하는 인증서버는 트래픽을 견디지 못하였습니다. Auto Scaling을 적용하였지만, Scale-out 속도와 DDoS 공격속도는 일정하지 않아서 한동안은 로그인이 지연되거나 실패하는 장애로 이어졌습니다. 최고점에는 평소 트래픽의 8배의 RPM(Requests Per Minute)을 발생시켰습니다. 물론 Scale-out이 진행된 후에는 장애로 이어지지 않았습니다. Scale-out 동안 장애를 발생시키지 않기 위해서 새롭게 만들어진 Instance의 Health Check 주기를 최대한 줄여서 트래픽을 처리할 수 있게 하였습니다.
이 문제를 사용자의 최소 인증을 통해서 해결해야한다고 생각했고, 비즈니스팀과 공감하여 “이메일 인증 프로세스 도입”을 추진하였습니다.
글로벌 서비스에서 계정시스템을 지켜온 과정
2023/01/07 10:28
security
waf
hacking

Trouble Shooting 이란?

“시스템에서 발생하는 복잡한 문제들을 종합적으로 원인을 진단하고 해결하는 것.”

Trouble Shooting 과정

1. 문제 정의

•
문제 동작 확인 분석 후, 문제를 정의한다.

2. 문제 사실 수집

•
‘정의된 문제’를 바탕으로 대략적으로 점검할 항목과 내용을 결정한다.
•
‘정의된 문제’를 재현하는 방법도 수집한다.

3. 문제 원인 추론

•
‘수집된 사실’을 바탕으로 문제의 ‘원인 추론’을 한다.

4. 문제 조치 방안 작성과 조치 구현

•
‘추론한 원인’에 따른 ‘조치 방안’을 마련하고 구현 단계를 거쳐 ‘문제 해결’을 한다

5. 구현이 반영된 후, 결과 관찰

•
‘조치 방안’을 관찰할 ‘조사 방법’을 마련하고 ‘관찰 결과’를 기록한다.
나는 어떻게 Trouble Shooting 하고 있는가?
2022/11/14 12:07
software engineering

1. 장애 탐지

2022.04.16
서비스 장애로 사용자들의 CS 문의가 빗발치기 시작했다.
백엔드에서는 몇가지 작은 에러 로깅이 있었고, 슬랙 알림이 발생했다. 이후에는 심각한 징후도 발견되지 않았다.
QA를 진행한 동료들의 일부는 앱은 서비스가 되고, 웹은 안된다고 하였고, 또 일부는 서비스가 모두 정상적으로 된다고 하였다.
이전에 발생했던 장애와 다른 형태의 장애가 발생한 것이다.
일반적으로 대규모 장애인 경우에 백엔드가 우선적으로 알아차릴 수 있었다.
하지만 이번 장애는 백엔드에서 선제적으로 알아차리지 못했다.
나열된 단서들을 가지고, 장애 전파와 해결에 활용해야한다.

2. 장애 전파

백엔드에서 발생하는 기본 장애 알림은 Slack 채널을 통해 자동화되어 있었다.
그리고 서비스의 전반적인 장애가 발생하였기 때문에 서비스 관련자가 있는 Slack 채널에 @Channel 알림으로 장애에 대한 상황을 전파했다.
그리고 탐지한 이슈 관련자들과 DM을 만들어서 Huddle 을 시작했다.

3. 장애 해결

도메인의 만료를 확인하고, 도메인을 구입한 벤더에서 구매하여, 장애를 해결하였다.
서비스 도메인 갱신 장애
2022/04/16 15:39
domain

에러 발생 원인

•
로컬에서 요청할 DNS 서버 정보가 잘못 설정되어 있는 경우
•
DNS 서버에 내 Domain이 업데이트 되어있지 않는 경우
•
내 Domain이 사용 기간이 만료된 경우
(Domain, IP) 정보를 찾는 이유는 인터넷 세상에서는 IP Addres를 기준으로 요청이 전달되기 때문입니다.

에러 발생 해결

•
로컬에서 요청할 DNS 서버 정보가 잘못 설정되어 있는 경우
•
DNS 서버에 내 Domain이 업데이트 되어있지 않는 경우
•
내 Domain이 사용 기간이 만료된 경우
DNS_PROBE_FINISHED_NXDOMAIN
2022/03/11 15:40
dns
Solution : "An error occurred (TargetNotConnected) when calling the StartSession operation: {instance-id} is not connected."
2022/02/14 16:37
aws

문제 배경

사용자가 서비스에 접속하면, “접속 정보"를 가져오고, DB에 영속화되어 관리되어집니다.
관리되어지는 가장 큰 이유는 비정상적인 또는 Fraud 여지가 있는 사용자들을 구분하기 위해서 입니다.
하지만,
IP와 Geo Location 정보는 시점에 따라서 달라질 수 있습니다.
그래서 사용자의 Geo Location 정보를 최신화하여, DB에서 관리되어지는게 중요합니다.
현재 사용자 접속 정보가 최신 정보가 아니라서 CX팀에서 최신화된 정보를 요구하고 있습니다.

문제 정의

“최신화되지 않은 Geo Location 정보가 영속화되어 변경된 정보와 매칭되지 않습니다”

문제 해결

1. Upgrade “Application Dependency Version” for ‘com.maxmind.geoip2’

AS-IS with 2.12.0
TO-BE with 2.16.1
“사용자 접속 정보” 최신화 하기
2022/08/29 11:29
geo location
data
장애 탐지 → 장애 전파 → 장애 해결 → 장애 보고 → 장애 회고

장애 탐지

2022.08.04

환경

•
Amazon Linux 2 AMI - Kernel 5.10
•
JDK 1.8
•
Spring Boot 2.4
1.
Third-party API를 호출 시, 아래와 같은 장애가 발생
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
예외 발생
2.
SSL 인증서로 기존 “Comodo” 인증서가 “Sectigo”로 변경되면서, 리눅스 시스템 내 Root/chain 인증서가 반영이 안되었고, JAVA SSL HandshakeException 및 Curl 오류가 발생
SSL 인증서

장애 전파

Java 기반에서 SSL 접속시, PKIX path building failed 오류
2022/08/04 04:50
java
ssl