본문으로 건너뛰기

동기 방식으로 외부 서비스를 호출할 때 외부 서비스 장애가 나면 어떻게 조치할 수 있을까?

외부 서비스 장애로 인해 응답이 오래 걸린다고 했을 때, 외부 API 응답으로 대기하는 자원들이 운영 서버 내부에 쌓이면서 성능에 악영향을 줄 수 있습니다. 이를 해결하기 위한 가장 기본적인 방법은 타임아웃을 설정하는 것입니다. 크게 타임아웃에는 커넥션 타임아웃과 리드 타임아웃, HTTP 커넥션 풀 타임아웃을 설정해 볼 수 있습니다.

✔️ Connection Timeout과 Read Timeout 차이​

Connection Timeout​

종단 간 연결하는데 소요되는 최대 시간을 의미 합니다. 이 시간을 넘기게 되면 연결 할 수 없는 것으로 판단하고 에러가 발생 합니다. Connection 이라는 단어가 의미하는 것처럼 종단 간 연결에 사용되는 타임아웃 입니다. 그리고 이 때의 연결이란 우리가 잘 알고 있는 TCP 3 way handshake를 통해 TCP 연결이 생성되는 것을 의미합니다.

Read Timeout​

연결된 종단 간에 데이터를 주고 받을 때 소요되는 최대 시간을 의미 합니다. 이 시간을 넘기게 되면 데이터를 받을 수 없는 것으로 판단하고 에러가 발생 합니다. Read 라는 단어가 의미하는 것처럼 연결되어 있는 종단 간 데이터를 주고 받을 때 사용되는 타임아웃 입니다.

Rest API 클라이언트의 경우라면 TCP 통신 과정에서 Connection Timeout과 Read Timeout이 적용되는 구간은 아래 그림과 같습니다. Network Timeout

✔️ 다음과 같이 특정 서비스의 장애가 전체 서비스에 영향을 주는 경우는 어떻게 해결할 수 있을까? 🤔​

1. A 서비스, B 서비스, C 서비스 연동 코드가 HTTP 커넥션 풀을 공유한다.
2. A 서비스의 장애로 응답 시간 지연이 발생하는 경우
   2-1. 풀에 남은 커넥션이 점점 줄어든다.
   2-2. 풀에서 커넥션을 구하는 대기 시간이 증가한다.
   2-3. B, C 서비스에 대한 연동도 함께 대기한다.

이 경우는 벌크헤드 패턴을 적용해 볼 수 있습니다. 벌크헤드 패턴은 기능의 종류마다 자원 사용을 분리하는 것을 의미하는데요. 자원을 격리하여 서비스 일부에 장애가 발생해도 전체로 전파되지 않도록 보장해 주는 패턴입니다. 위 예시에서는 외부 서비스마다 다른 HTTP 커넥션 풀을 사용하도록 벌크헤드 패턴을 적용할 수 있습니다. 서로 다른 커넥션 풀을 사용하기 때문에 A 서비스에 문제가 발생해도 B,C의 영향을 최소화할 수 있습니다.

✔️ 외부 서비스 장애가 계속 발생하면 어떻게 되나요?​

지속되는 외부 서비스 장애로 타임아웃에 의한 서비스 에러가 발생할 수 있습니다. 외부 서비스가 장애가 발생했는데도 불구하고 운영 서버는 계속 요청을 보내게 되니, 불필요하게 응답 시간이 저해되고, 처리량도 감소하게 됩니다. 이 문제를 해결하기 위해서는 서킷 브레이커를 적용할 수 있는데요. 서킷 브레이커는 오류가 지속되는 경우 일정 시간 동안 기능 실행을 차단할 수 있습니다. 서킷 브레이커가 빠른 실패를 도와주기 때문에 외부 서비스 장애에 의한 응답 시간 증가를 예방할 수 있습니다.