컨테이너를 확장한다는 것은 단순히 서비스 앞에 프록시를 두고 그냥 방치하는 것보다 더 많은 것입니다. 확장에는 배포 외에도 더 많은 요소가 필요하며 빠르게 변화하는 컨테이너 세계에서는 확장을 보장하는 데 필요한 다섯 가지 기능이 있습니다. 즉, 재시도 , 회로 차단기, 검색 , 배포 , 모니터링입니다 .
컨테이너 확장 기술에 대한 두 번째 게시물에서는 회로 차단기에 대해 알아보겠습니다.
작동하지 않는 수천 개의 가젯과 작동하는 몇 가지 유명한 가젯을 발명한 것으로 유명한 토마스 에디슨은 1879년 특허 출원을 통해 회로 차단기의 개념을 우리에게 제공했습니다. 네, 그때도 특허는 있었습니다. 에디슨의 버전은 퓨즈를 사용했고, 퓨즈는 교체해야 합니다(어떤 사람들은 옛날 차에서 퓨즈를 찾아 헤매던 걸 기억할지도 모릅니다). 반면, 더 현대적인 버전은 "트립"하도록 제작되어 전기 흐름을 중단시킵니다. 그런 다음 재설정하여 정상적인 흐름과 작동을 복원할 수 있습니다.
규모의 맥락에서 회로 차단기는 동일한 원리로 작동합니다. 그들은 "오버플로"를 감지하고 의도적으로 차단하여 연결의 다른 쪽에서 서비스에 과부하가 걸리는 것을 방지합니다. 또한 재설정을 통해 요청 및 응답의 정상적인 흐름을 복원할 수도 있습니다.
회로 차단기는 오랫동안 부하 분산 프록시의 일부로 사용되어 왔습니다. 전제는 X가 시도한 후에도 주어진 서비스에 도달할 수 없으면 해당 서비스는 사용할 수 없다는 것입니다. 프록시와 네트워크에서 리소스를 낭비하는 것뿐인데, 프록시가 줄 수 없는 것을 계속해서 요구하는 데는 이유가 있습니다. 따라서 (일반적으로) 구성 가능한 실패 횟수가 발생하면 프록시는 회로를 "차단"하고 추가 연결을 시도하지 않습니다.
이는 재시도와 같지는 않지만 과정은 비슷해 보입니다. 재시도는 요청이 결국 성공할 것이라는 전제 하에 작동합니다. 회로 차단기는 요청이 실패할 것이라는 전제 하에 작동하므로 이를 위해 시간과 리소스를 낭비하는 것을 피할 수 있습니다.
문제가 해결되면 회로 차단기를 "재설정"하여 정상적인 흐름을 재개할 수 있습니다.
초기에는 이 과정이 수동이었습니다. 운영자는 대상 서비스가 실제로 다시 서비스로 돌아왔는지 확인한 후 재설정을 수행해야 했습니다. 최근 몇 년 동안 이 과정은 건강 모니터링을 통해 자동화되었습니다. 일반적으로 이러한 작업에는 서비스에 접속하기 위한 주기적 시도가 포함되며, 성공하면 회로 차단기를 재설정하여 다시 정상적인 작동을 허용합니다.
회로 차단기는 서비스 간 및 서비스 간에서 많은 양의 트래픽이 발생하기 때문에 컨테이너화된 마이크로서비스 환경에서 특히 중요합니다. 일부 실패는 금방 인식되지만, 다른 실패는 네트워크 스택의 문제로 인해 장시간 TCP 시간 초과가 발생할 때까지 알아차리지 못할 수도 있습니다. 타임아웃은 원치 않는 지연 시간을 발생시키므로, 회로 차단과 재시도는 지연 시간에 대한 전체 애플리케이션 허용 범위(또는 경우에 따라 허용 범위 외)를 고려해야 합니다. 이러한 값을 구성하려면 시간 초과 값과 성능과 관련된 비즈니스 기대치를 고려해야 합니다. 지연 시간 허용 범위가 낮으면 재시도 횟수를 줄이고 회로 차단 동작을 더 빠르게 수행해야 할 수도 있습니다.