저는 Amazon Web Services, 특히 Instagram의 백엔드 설정을 많이 살펴보았습니다. 그들의인스타그램 엔지니어링 블로그그들은 django/Gunicorn을 실행하는 앱 서버 앞에 있는 세 개의 NGINX 서버 앞에 어떻게 Elastic Load Balancer가 있는지 언급했는데, 그 이유는 무엇입니까(버퍼링을 위한 것인가요? 캐싱을 위한 것인가요?)
그렇다면 해당 NGINX 서버를 django/gunicorn 앱 서버에 어떻게 연결할 수 있습니까?
답변1
Instagram 게시물을 살펴보면 그들이 버퍼링이나 캐싱을 위해 Nginx를 사용하고 있다는 것을 믿을 수 없습니다(물론 제가 틀렸을 수도 있음). 비슷한 것을 사용하지만 Nginx 대신 HAProxy를 사용합니다.
우리가 이 접근 방식을 취한 몇 가지 이유는 다음과 같습니다.
- Nginx와 HAProxy는 레이어 7에서 작동하는 반면 ELB는 이후 4에서 작동합니다. 레이어 7 서비스가 필요한 경우 ELB는 이를 제공할 수 없습니다.
- 상태 확인이 실패할 경우 연결을 정상적으로 종료합니다. ELB는 트래픽이 서비스 중단 인스턴스에서 제거되는 동안 계속해서 HAProxy/Nginx로 트래픽을 전달할 수 있습니다. 보다https://forums.aws.amazon.com/message.jspa?messageID=231571
- 필요한 경우 부하 분산 계층을 실시간으로 확장할 수 있습니다.
- HAProxy/Nginx 계층 뒤에 있는 각 인스턴스의 트래픽 및 성능에 대한 더 나은 지표
- ELB는 HAProxy 인스턴스가 실패한 시기를 감지하고 해당 인스턴스로의 트래픽 전송을 중지할 수 있습니다.
답변2
내가 생각할 수 있는 몇 가지 사항은 다음과 같습니다.
- 요청을 분산하고 서버 상태를 모니터링하므로 nginx 서버 중 하나가 충돌하더라도 사이트는 계속해서 완벽하게 작동합니다.
- Amazon은 결국 일부 서비스 거부 완화를 수행합니다. 로드 밸런싱을 직접 처리한다면 이에 도달하는 모든 트래픽에 대한 비용을 지불하게 될 것입니다. Amazon이 ELB를 겨냥한 일부 공격을 차단하는 경우 해당 부분에 대한 비용을 지불하지 않아도 됩니다.
- nginx 서버의 보안 그룹을 ELB에만 잠글 수 있으므로 공개 인터넷에 공개하는 것보다 보안이 더 강화됩니다.