모든 소프트웨어는 실패한다는 유명한 말이 있다. 즉 실패하지 않는 시스템을 만드는 것은 거의 불가능에 가깝다는 말이다.
실제로 이번에 모바일에 반영을 하며 갑자기 다른 서비스가 죽는 현상이 발생해 긴급 반영을 한 일이 있었다.
만약 실패를 가정하고 대체 루트를 설정했다면 어떻게 됐을까?
문제 없이 서비스를 정상 제공하고 그 사이에 다시 원인을 찾고 문제를 해결할 수 있었을 것이다.
이번 케이스를 통해 서킷브레이커 패턴을 실제로 적용하게 됐다.
그러면 서킷브레이커 패턴은 무엇일까?
서킷 브레이커란 말 그대로 전기에 과부하가 걸릴때 자동으로 차단되는 전기 스위치다. 이를 SW 관점에서 보면 특정 서비스에 대한 호출을 모니터링하여 실패율이 임계치를 넘어가면, 장애가 발생한 서비스로의 요청을 차단하는 방법이다.
즉 특정 임계치를 넘어가면 해당 서비스에 대해 서킷 브레이커가 열리게 되고 대체 서비스로 호출을 하는 것이다.
만약 고장난 서비스에 대해 계속 호출을 하면 어떻게 될까? 클라이언트는 계속 요청을 보낼 것이고 서버는 이에 대해 계속 응답을 하려할 것이고, 요청 대기...가 반복되다가 CPU를 잡아먹고 결국 서버가 최악의 경우 다운될 것이다. 그리고 사용자는 오류가 발생했다며 컴플레인을 걸 수 있다.
서킷 브레이커 패턴은 인프라 관점에서도 구현이 가능하고 직접 운영하는 서비스내에 코드로도 구현이 가능하다.
만약 자신이 서비스를 개발중이라면 서킷 브레이커 패턴을 한번 적용해 보는건 어떨까?