컨테이너를 확장한다는 것은 단순히 서비스 앞에 프록시를 두고 그냥 방치하는 것보다 더 많은 것입니다. 확장에는 배포 외에도 더 많은 요소가 필요하며, 빠르게 변화하는 컨테이너 세계에서는 확장을 보장하는 데 필요한 다섯 가지 기능, 즉 재시도, 회로 차단기, 검색 , 배포 , 모니터링이 있습니다.
컨테이너 확장 기술에 대한 이 게시물에서는 재시도에 대해 자세히 알아보겠습니다.
어린 시절 게임을 할 때 재시도라는 개념은 많은 게임에서 흔히 볼 수 있습니다. "다시 해!"는 일반적으로 실패 후에 외치는데, 이는 다른 플레이어가 다시 시도할 수 있도록 해주기를 바라는 마음에서입니다. 가끔은 그렇죠. 때로는 그렇지 않아요. 나는 그것이 아이들이 시도하는 것을 막는 경우가 거의 없다는 것을 알았습니다.
앱(또는 원하는 경우 서비스)을 확장할 때 재시도 개념은 거의 같습니다. 프록시는 서비스를 선택하고 요청을 이행하려고 할 때 오류를 받습니다. 기본적인 부하 분산 시나리오에서는 일반적으로 HTTP 응답 코드를 조사하여 결정됩니다. "200 OK" 이외의 모든 것은 오류입니다. 여기에는 네트워크 및 TCP 계층 시간 초과가 포함됩니다. 부하 분산 장치는 실패한 응답을 맹목적으로 반환할 수 있습니다.
요청자이거나, 충분히 똑똑하다면 후속 요청이 성공적인 응답으로 이어질 것이라는 희망으로 요청을 다시 시도할 수 있습니다.
꽤 기본적인 내용이지만, 스케일의 시작 부분에서는 재시도라는 것이 없었습니다. 실패하면 실패이고, 우리는 그 문제를 해결했습니다. 일반적으로 브라우저에서 수동으로 다시 로드하려고 시도합니다. 결국 프록시는 스스로 재시도를 수행할 만큼 똑똑해져서 많은 키보드가 "CTRL"과 "R" 버튼을 닳게 하는 일을 방지할 수 있었습니다.
표면적으로 보면 이것은 광기의 정의에 대한 실존적 예입니다. 결국, 만약 첫 번째 요청이 실패했다면, 두 번째(혹은 세 번째?)에 성공할 것이라고 기대할 수 있을까요?
답은 실패의 이유 에 있습니다. 앱을 확장할 때는 연결 용량이 오류에 미치는 영향을 이해하는 것이 중요합니다. 주어진 시간에 주어진 자원에 걸리는 부하는 고정되어 있지 않습니다. 연결은 끊임없이 열리기도 하고 닫히기도 합니다. Apache나 IIS, node.js 엔진이나 다른 스택 등 기본 웹 앱 플랫폼은 용량 측면에서 정의된 제약 조건을 가지고 있습니다. 동시 연결은 X개까지만 유지할 수 있습니다. 해당 제한에 도달하면 새로운 연결을 열려는 시도가 중단되거나 실패합니다.
이것이 실패의 원인이라면 프록시가 실패한 응답을 받는 데 걸린 마이크로초 동안 다른 연결이 닫혔을 수 있으며, 이로 인해 재시도가 성공할 가능성이 생겼을 수 있습니다.
어떤 경우에는 플랫폼 내부에 오류가 발생합니다. 두려운 " 500 내부 서버 오류 ". 이 상태는 서버가 과부하 상태가 아닌데, 시간 내에 응답하지 못한 다른(외부) 서비스에 대한 호출을 한 경우에 자주 나타납니다. 때로는 이는 데이터베이스 연결 풀이 한계 에 도달한 결과입니다. 외부 서비스에 의존하면 연결 과부하와 마찬가지로 일련의 오류가 연쇄적으로 발생할 수 있으며, 이는 초기 오류가 발생할 때까지 해결되는 경우가 많습니다.
또한 매우 유용한 " 503 서비스를 사용할 수 없음 " 오류가 표시될 수도 있습니다. 이는 과부하에 대한 응답일 수 있지만, 모든 HTTP 오류 코드와 마찬가지로 실제로 무엇이 잘못되었는지 항상 정확하게 예측하는 것은 아닙니다. 이 문제는 DNS 오류에 대한 응답으로 나타날 수도 있고, IIS와 ASP의 경우 대기열이 가득 찬 경우에도 나타날 수 있습니다. 가능성은 정말 다양합니다. 그리고 다시 말씀드리지만, 오류가 발생할 때까지 문제가 해결되었을 수도 있으므로 재시도가 첫 번째 대응책이 되어야 합니다.
물론 소들이 집에 돌아올 때까지 다시 시도할 수는 없죠. TCP 재전송의 의도치 않은 결과(네트워크에 과부하를 일으키고 수신기를 압도할 수 있음)와 마찬가지로 재시도는 결국 무의미해집니다. 포기하기 전에 몇 번이나 재시도해야 하는지에 대한 엄격한 규칙은 없지만, 일반적으로 3~5회가 적당합니다.
이 시점에서 요청자에게 유감을 표하고 회로 차단기를 시작할 때입니다. 다음 게시물에서 해당 기능에 대해 자세히 살펴보겠습니다.