앞서 서버의 처리시간을 단축시키는 방법 중 하나로 비동기 처리 방식을 살펴봤다
그리고 외부 api 연동을 비동기로 처리한다면 우리 서비스의 처리시간에 영향을 주지 않으며
이는 곧 서비스의 응답시간 개선을 이뤄낼 수 있었다.
여기서는 비동기처리 방식이 아닌
동기식 외부 api 연동시 영향을 덜 받는 방법을 알아보고자한다.
- timeout
- 벌크헤드 bulkHead
- 서킷 브레이커 circuit breaker
1. timeout
오래 대기하는것보다 빨리 에러를 발생시키는게 낫다
- 동시에 대기하는 외부 연동 개수가 많아질수록 우리 서비스는 느려지고 망가진다
따라서 우리는 외부 api 연동을 동기처리시 두 개 타임아웃을 설정하자
1. 연결 시간 타임아웃
- 우선 외부 api 연결에 대한 타임아웃을 생각하자
- 보통 1~5초내로 설정하고 이 시간안에 연결이 안된다면 빠르게 에러를 반환하자
2. 응답시간 타임아웃
- 응답시간 = 대기시간 + 처리시간
- 즉 연결 이후!!! 요청처리 시간에 대한 타임아웃도 필요
- 외부 api연동은 되었지만 외부 서비스의 서비스 처리에 대한 응답이 늦어지는경우 이를 끊어내자
- 보통 1~3초가 적당하지만 예외도 있다
- 결제같은경우는 30초
2. 벌크헤드
외부 연동 서비스가 많은데
하나의 커넥션 풀만 사용하는경우
이 경우의 문제점은
-> 커넥션 풀의 한 커넥션이 A서비스와 연결되어있는 상태
-> A서비스의 응답 지연이 발생
-> 해당 커넥션을 여전히 물고있는 상태
-> 다른 많은 요청이 들어와서 나머지 커넥션도 사용되는 상태
-> 현재 사용할 수 있는 커넥션이 남아있지 않는 문제!!!가 발생
-> 따라서 B,C를 향하는 요청도 커넥션이 없으니 처리 불가
-> 전체 서비스의 문제
이를 해결하기위한 방법이 벌크헤드
기능/서비스/클라이언트마다 자원 사용 분리
하나의 기능/서비스 장애가 다른 기능/서비스에 주는 영향 최소화
위 그림에서라면 각 서비스가 서로 다른 자원(커넥션 풀)을 사용하여
A의 장애 영향 범위가 감소하도록
### 3. 서킷 브레이커
오류가 지속되면 일정 시간동안 해당 기능을 차단한다
-> 빠른 실패
-> 빠른 응답시간
외부서비스의 장애가 지속⭐️된다면
우리 서비스는 계속 요청을 보내지만 응답이 지연되고
우리 서비스의 응답 시간도 느려지고 처리량도 감소한다
이때 서킷브레이커는 그 기능을 차단한다
웹 서비스 resilience
1. timeout
2. 벌크헤드
-> 커넥션 풀의 한 커넥션이 A서비스와 연결되어있는 상태 -> A서비스의 응답 지연이 발생 -> 해당 커넥션을 여전히 물고있는 상태 -> 다른 많은 요청이 들어와서 나머지 커넥션도 사용되는 상태 -> 현재 사용할 수 있는 커넥션이 남아있지 않는 문제!!!가 발생 -> 따라서 B,C를 향하는 요청도 커넥션이 없으니 처리 불가 -> 전체 서비스의 문제
이를 해결하기위한 방법이 벌크헤드
위 그림에서라면 각 서비스가 서로 다른 자원(커넥션 풀)을 사용하여 A의 장애 영향 범위가 감소하도록
오류가 지속되면 일정 시간동안 해당 기능을 차단한다 -> 빠른 실패 -> 빠른 응답시간
외부서비스의 장애가 지속⭐️된다면 우리 서비스는 계속 요청을 보내지만 응답이 지연되고 우리 서비스의 응답 시간도 느려지고 처리량도 감소한다 이때 서킷브레이커는 그 기능을 차단한다
서킷 브레이커의 동작방식