https://www.maeil-mail.kr/question/74
요약: 일반적으로 동기 방식에서 여러 서비스가 동작할 때, 앞의 서비스에서 장애가 발생시, 뒤의 서비스까지 영향을 받으며, 커낵션 풀을 얻지 못한다. 이 때 각 커넥션마다의 서비스를 배정하는 벌크헤드 패턴을 통해서 해당 문제를 해결가능하다.
그러나 이러한 경우에도 계속 장애가 일어나게 된다면, 아무리 커낵션풀을 서비스마다 할당되어있다고 해도, 당연하게도 장애가 일어난 서비스는 자연스럽게 해결되지 않고, 더욱 꼬이게 된다. 이 때는 서킷 브레이커를 통해서 오류가 지속되는 경우 기능을 차단하여, 외부 서비스 장애의 응답시간 증가를 줄일 수 있다.

벌크헤드 패턴

Spring환경에서는 외부 API를 사용하기 위해서 RestTemplate를 사용하게 된다. 이 때 http요청을 통해서 하게되는데, 이 때 커넥션 풀을 이용해서 연결하게 된다.
하지만 하나의 기능에서 여러가지의 외부 API를 가져와서 사용하는 경우를 예를 들어보자.

출처:https://internet-craft.tistory.com/77
비동기 처리가 아닌 동기처리에서는 A-1의 외부 API가 커낵션을 모두 획득했기에 A-2는 A-1이 끝날 때까지 기다릴 수 밖에 없다. 이 때 A-1에서 만약에 장애가 발생한다면, 다음에 수행되어야 할 A-2까지 지연 될 수 밖에 없음 따라서 각 커넥션 별로 서비스를 구획하는 방향으로 설계하면 해당 문제의 발생을 막을 수 있을 것이다. 이를 벌크헤드 패턴이라고 한다.

하지만 위의 벌크헤드 패턴의 경우 A-1이 만약 많은 양의 데이터를 가져와야하거나, 많은양을 받아야하는경우(비디오 데이터의 경우) 시간이 더욱 오래 걸릴수 있다.
따라서 이 상황에서는 벌크헤드 패턴이 옳게 적용된것이 맞는지를 판단해보는 과정이 내가 생각하기엔 필수적인 과정이다.

자세한 내용은 MSA에 대해서 더욱 공부하고 포스팅 하도록 하겠다.

서킷 브레이커

서킷 브레이커는 전류가 너무 많이 흐르면 차단되는 전압기처럼 문제가 발생하는 부분을 차단 시켜서 문제를 더욱 확산시키지 않게 한다.
이를 통해서 문제에 대한 더욱 세밀한 컨트롤이 가능하다.

출처: https://mangkyu.tistory.com/261
서킷이 closed상태일 때는 장애가 일어나지 않고, 잘 작동을 하는 상황이다. 이 때 장애가 일어난다면 Open상태로 변환되고, 일정 시간이 지나면 Half Open상태로 변환된다. 이 때 장애가 복구되면 Closed상태가 되지만 여전히 장애 상태면 Open으로 변환된다.
이를 통해서 하나의 인스턴스가 장애가 되었다고 해서 이와 연관된 인스턴스들도 같이 장애가 일어나는 것이 아닌 장애의 격리가 가능하게 되는 것이다.