대역폭 분배를 위해 여러 정적 파일 서버에서로드 밸런싱을 수행하는 가장 좋은 방법은 무엇입니까?


12

먼저 내 상황을 설명해 드리겠습니다. 나는 상당히 인기있는 웹 사이트를 부수적 인 프로젝트로 운영하고 있으므로 실제로 많은 돈을 투자 할 수는 없습니다. 현재 HAProxy가있는 서버가 하나만 있고 Apache에 일반 요청을 보내고 모든 정적 파일 요청을 Lighttpd에 보냅니다. 이것은 모든 PHP 및 post 요청이 Apache에 의해 처리되고 모든 이미지가 더 빠른 Lighttpd로 전송되기 때문에 실제로 잘 작동합니다 (사이트는 대부분 이미지이므로 매우 중요합니다). 짧은 URL도 매우 중요하므로 HAProxy를 사용해야하는 이유 때문에 이미지를 제공하기 위해 하위 도메인을 설정할 필요가 없습니다.

내가 사용하고있는 아주 저렴한 계량되지 않은 대역폭을 제공하는 호스팅 제공 업체를 찾았는데, 100mbs 네트워크 카드가 처리 할 수있는만큼의 대역폭을 제공 할 때 문제가 발생하여 두 번째 서버가 필요합니다.

나는 내 선택에 대해 많은 생각을했다. 그래서 나는 당신에게 각각을 설명 할 것이다. 바라건대 당신은 나에게 가장 적합한 옵션에 대한 통찰력을 제공 할 수도 있고, 아직 내가 생각하지 못한 다른 옵션이있을 수도 있습니다.

요구 사항 :

  • 대역폭 분배조차도 필수입니다. 나는 매우 강력한 서버를 가지고 있으므로 스케일 업은 옵션이 아닙니다. 더 많은 대역폭을 확보하려면 수평 확장이 필요합니다.

  • 짧은 URL. 이미지를 제공하기 위해 img.example.com과 같은 하위 도메인을 설정하지 않습니다. example.com/image.jpg는 지금의 모습이며 실제로 어떻게 유지하고 싶습니까? 그러나 다른 방법이 없다면 이해합니다.

  • 요청을 처리하는 clostest 서버는 정말 좋을 것이지만 필수는 아닙니다. 명심해야 할 것.

HAProxy에서로드 밸런싱 :

  • 어쨌든 이미 HAProxy를 사용하고 있기 때문에 정말 쉽습니다. 그러나 대역폭을 분배 할 때 문제가 발생한다고 생각합니다. 나는 이것에 틀렸을 수도 있지만 HAProxy는 서버가 요청을 처리 한 서버로 요청을 보낸 다음 HAProxy를 통해 클라이언트로 다시 보내지 않습니까? 따라서 모든 트래픽이로드 밸런서를 통해 다시 전송되어 모든 서버가 결합한만큼의 대역폭을 사용하게됩니다.

DNS 라운드 로빈 :

  • 이것이 내 최선의 선택 일 수 있습니다. 여러 서버에 웹 사이트를 복제하고 지금하고있는 작업을 수행하십시오. 단점은 한 서버가 다운되면 클라이언트가 여전히 서버로 전송된다는 것입니다. 또한 여러 서버에서 사이트를 복제해야합니다. 정적 파일을 제외한 모든 것을 처리하는 하나의 기본 서버가 있고 두 개의 정적 파일 서버가 있기를 바랐습니다. 나는 이것이 일종의 '가난한 사람들의로드 밸런싱'이었다는 것을 읽었으며 조금 더 정교한 것을 갖는 것이 좋을 것입니다.

직접 서버 반환 :

  • 정말 복잡해 보이지만 좋은 옵션 일 수 있습니다. 여전히 특정 URL을 특정 서버로 보낼 수 있습니까? HAProxy와 마찬가지로, 올바른 파일 확장자로 끝나는 모든 URL은 Lighttpd로 전송되고 다른 확장자는 Apache로 전송됩니다. 그래서 비슷한 것이 필요합니다. 마찬가지로 모든 PHP 요청은 밸런싱 소프트웨어를 실행하는 동일한 서버에서 처리되는 반면 모든 jpg 요청은 여러 서버로 전송됩니다.

HAProxy가 Direct Server Return을 지원하면 이상적으로 문제가 해결 될 것입니다. CDN은 정말 비싸기 때문에 CDN을 사용하고 싶지 않으며 결국 부수적 인 프로젝트입니다.

내 문제를 이해합니까? 내가 옳은 것을 설명하지 않았거나 더 많은 정보가 필요하면 알려주십시오.


1
이것은 Imgur이며 최근 4 천만 달러를 모금했습니다. : O
L1th1um

답변:


3

응용 프로그램의 요청 / 응답주기 그림을 그리고 병목 현상을 격리하십시오. 많은 애플리케이션 서버에로드를 분배하는 단일 프록시가 모든 애플리케이션 서버의 총 대역폭을 필요로하는 것이 맞습니다. 고전적인 솔루션은 RR DNS입니다. Google, Yahoo 및 Amazon은 모두이 기술을 짧은 TTL과 함께 사용합니다. 나는 얼마 동안 조사를했고 나의 발견을 문서화했다 .

또 다른 솔루션은 가상 IP 주소 지정을 사용하는 팬던트 엔터프라이즈로드 밸런싱 솔루션을 사용하여 실제 IP 주소를 가진 여러 애플리케이션 서버 간의 요청을 균형 조정하는 것입니다. Netscaler 및 Stonesoft 제품과 협력했습니다. 둘 다 잘 수행하지만 끔찍한 특질을 가지고 있으며 매우 복잡합니다.


대단히 감사합니다. 설문 조사 결과는 매우 도움이되었습니다. 이것이 내가 마침내 올 해결책이라고 생각합니다. 그러나 "좋은 연구원처럼 데이터가 충분할 때까지 행동하지 않습니다." :)
Alan

통찰력에 감사드립니다. 불행하게도 아이러니하게도 결과와의 연결이 끊어진 것 같습니다. 고칠 수 있습니까?
TCB13

3

일부 답변 :

  • 예, 모든 트래픽은 HTTP 수준 프록시로 작동하므로 HAProxy를 통해 전달됩니다. HAProxy가 여러 백엔드 서버의로드 밸런스를 수행하는 별도의 서버에 설치된 경우에도 동일합니다. 따라서 호스팅 제공 업체가 100MBit 네트워크 포트만 제공하고 이미 100MBit을 푸시하고 있다면 문제가있는 것입니다.
  • 도메인과 관련하여 최적의 방법은 하위 도메인이나 다른 도메인이 아닌 웹앱과 다른 도메인의 이미지를 제공하여 쿠키가 이미지 요청시 전송되지 않도록하는 것입니다. 참조 스티브 수 더스 원작 , 또는 스택 오버플로 여기에 구현 . 짧은 URL이 매우 중요한 경우 웹앱을 기본 URL에서 다른 위치로 옮기는 것이 가장 좋습니다 (예 : 파일 관리 응용 프로그램을 login.sitename.com?

이미지 요청에 대한 인증이 필요합니까? 그렇지 않다면 Amazon S3와 같은 것을 사용하는 것은 어떻습니까? 확장 성이 뛰어나고 데이터 전송 비용이 상당히 저렴합니다. 이 경우 i.sitename.com과 같은 것을 Amazon S3 버킷 호스트 이름의 DNS CNAME으로 사용합니다 ( Amazons docs 참조) . AFAIK에는 루트 도메인 이름 (sitename.com)을 CNAME으로 사용할 수 없으므로 i.sitename.com과 같은 하위 도메인을 사용해야합니다.

여러 서버에서 이미지를 해시 할 수도 있습니다. 즉, login.sitename.com 및 a.sitename.com과 같은 DNS 구조를 만듭니다. b.sitename.com; c.sitename.com 등 "a." 그리고 "b." etc 서버에는 이미지가있는 파일 시스템과 가벼운 HTTP 서버가 포함되어 있습니다 (이미 Lighttpd를 사용하고 있으므로 계속 사용하십시오. 향후 프로젝트에서는 nginx를 더 나은 대체물로 볼 것을 제안합니다). 이미지에서 고유 식별자, 아마도 사용자 이름, 파일 이름 또는 여러 식별자 조합의 해시 를 만듭니다 . 이 해시에서 이미지를 저장할 서버를 결정합니다.

편집 해싱이 이미 논의 된 것을 보았을 것입니다. 본질적으로 여기서 제안하는 것은 호스트 이름에 해싱을 사용하여 여러 호스트에 네트워크 트래픽을 고르게 분산시키는 것입니다.

얼마나 저렴해야할지 모르겠지만 100MBit의 네트워크 트래픽을 추진할 때 "저렴하고 좋은"것은 곧 환상으로 밝혀졌습니다. 어쩌면 당신은 좋은 비즈니스 모델을 얻는 것을 먼저보아야 할 것입니다.


1

HAProxy가 다른 응용 프로그램과 동일한 서버에 있다고 가정합니까? HAProxy를 다른 시스템으로 분리하여 요청을 실행하고 일반 요청을 한 서버로 보내고 이미지 요청을 다른 서버로 보내도록 할 수 있습니다. 문제는 모든 요청이 여전히 하나의 상자로 가고 있다는 것입니다. 대역폭을 포화 상태로 유지하면 큰 도움이되지 않을 수 있습니다.

짧은 URL이 중요하다고합니다. 왜? "example.com"에서 "i.example.com"으로 이미지를 전환하는 것이 정말 큰 일입니까? Lighttpd를 사용하여 자체 서버에서 "i"를 고유 한 IP로 설정하고 HAProxy를 완전히 무시하여 처리량 문제를 해결할 수 있습니다. 또한 웹 브라우저를 사용하면 요청을 다른 도메인 이름으로 간주하고 더 많은 동시 연결을 열 수 있으므로 한 번에 더 많은 요청을 열 수 있습니다. 단일 "i"서버가 포화 상태이면 DNS 라운드 로빈을 사용하여 다른 서버를 추가 할 수 있습니다. 그 당시에는 더 나은 솔루션을 구현하기에 충분한 수익을 창출하고 있기를 바랍니다.


예, HAProxy는 동일한 서버에 있습니다. 지금까지는 하나만 있습니다. 다른 서버로 데이터를 분리하더라도 위에서 설명한 것처럼 모든 데이터가 HAProxy를 통해 서버를 통과하지는 않습니까? 짧은 URL은 사이트의 목적과 유사하기 때문에 중요합니다. ImageShack과 TinyPic 간의 크로스 오버입니다. URL이 길수록 사이트의 포인트가 줄어 듭니다. 그러나 내가 말했듯이, 가능한 유일한 옵션은 하위 도메인을 설정하는 것이라면 그렇게해야합니다. 나는 정말로 싶지는 않습니다.
Alan

1

호스팅 제공 업체는로드 밸런싱 서비스를 제공합니까? 최선의 해결책이라고 생각합니다.

그것을 수행하는 또 다른 방법은 테스트해야하지만 요청을 다시 작성하는 것입니다. 예를 들어 example.com/file.html은 아파치 상태로 유지되고 example.com/image.jpg는 i.example.com/image.jpg로 리디렉션됩니다. 모든 요청은 아파치를 통해 관리되지만 응답 (업스트림 대역폭)은 lighttpd 서버로 전달됩니다. 도메인은 사용자에게 투명합니다. 아파치가 모든 요청을 처리 할 수 ​​있는지 또는 lighttpd가이 작업을 수행 할 수 있는지 테스트해야합니다.

모든 데이터가 HAProxy를 통과하는 것이 맞으므로 (내가 아는 한) 직접 서버 반환을 수행 할 수 없습니다.

최신 정보

에서 찾고 HAproxy 문서 I는 "REDIR"매개 변수를 발견했다. 아파치 다시 쓰기처럼 작동 할 수 있는지 모르겠지만 유용 할 수 있습니다. 설명서는 다음과 같이 말합니다.

주로 클라이언트가 서버에 직접 연결하여 정적 서버의 대역폭을 늘리는 용도로 사용됩니다.

어쩌면 그것은 당신의 경우에 효과가 있습니다.


답변 감사합니다. 나는 실제로 이것을 이미 시도했지만 이론 상으로는 실제로 잘 작동하지 않습니다. 그 이유는 Apache가 모든 요청을 처리하므로 사용자가 이미지를 칠 때마다 Apache가 생성되고 URL을 확인한 다음 가볍게 보냅니다. 아파치가 처음에 이미지를 처리하는 것과 다르지 않습니다. 호스트가 제공하는로드 밸런서가 최선의 선택이지만 가장 비싸다는 것에 동의합니다. 동시 연결 당 요금이 청구되며 수백 대를받습니다.
Alan

가벼운 서버가 자신의 대역폭을 소비하는 클라이언트에게 직접 응답을 보내는 방식이 다릅니다. 문제는 Apache 서버가 많은 요청을 처리한다는 것입니다. 내 답변의 업데이트를 확인하고 다른 해결책을 찾았습니다.
hdanniel

1

크기 조정 가능한 이미지 세트를 사용하면 이름 충돌이 발생하기 때문에 원래 파일 이름을 기반으로 이미지를 저장하지 않는다고 가정합니다.

이러한 유형의 문제를 처리하는 많은 응용 프로그램은 파일의 해시와 해당 해시에 기반한 디렉토리 구조를 사용합니다. 디렉토리 구조는 다음과 같습니다. 여기서 디렉토리 경로는 해시의 첫 두 문자이고 두 번째 레벨 디렉토리는 해시의 다음 두 문자입니다.

/image root/AA/AA/images  
/image root/AA/AB/images

여기서의 이점은 해시가 파일 배포를 매우 균일하게 유지하고 여러 서버로 쉽게 분리 할 수있는 네임 스페이스를 제공한다는 것입니다. 기본적으로 서로 다른 서버에서 해시 공간의 일부를 제공하며 확장함에 따라 필요에 따라 더 세분화 할 수 있습니다.

단점은 해시가 완벽하지 않으며 충돌이 발생할 수 있다는 것입니다. 이것이 어떻게 처리되는지 잘 모르겠습니다. 따라서 약간의 연구가 필요할 수 있습니다. 프록시의 다시 쓰기 규칙이 A3A8BBC83261.jpg라는 해시를 가져 와서 http://img3.domain.com/A3/A8/BBC83261.jpg로 다시 작성할 수 있다고 생각합니다 . 당신은 짧은 URL이라고 생각하지 않을 수 있습니다.


예, 이것이 바로 이미지를 저장하는 방법입니다. 그러나 문제는 스토리지가 아니라 대역폭 분배에 관한 것입니다.
Alan

그러나 한 서버에 AA를 통해 33을 저장하고 다른 서버에 34를 통해 99를 저장하면 스토리지 문제뿐만 아니라 대역폭 분포도 균형을 유지하게됩니다.
3dinfluence

0

귀하의 게시물에서 당신은 DNS 라운드 robbin이 최선의 선택 일 것이라고 생각했지만 단일 서버 실패에 대해 걱정하고 있습니다 ...

그렇다면 JH Software의 Simple Failover를 살펴보십시오. 나는 과거에 그것을 사용했고 아주 잘 작동합니다.

http://www.simplefailover.com

기본적으로 서버를 모니터링하고 서버가 다운되는 것을 발견하면 DNS를 빠르게 다시 작성하여 죽은 서버를 회전에서 빼냅니다.

웹 사이트의 스 니펫은 다음과 같습니다.

Simple Failover는 지속적으로 서버를 모니터링하여 작동중인 서버와 작동하지 않는 서버를 찾은 다음 도메인 이름이 항상 기능 서버를 가리 키도록 DNS 레코드를 동적으로 업데이트합니다.

웹 서버 (HTTP), 메일 서버 (SMTP, IMAP, POP3), FTP 서버 및 기타 다른 TCP / IP 기반 서버 유형과 함께 작동합니다.

앞에서 언급했듯이 과거에는 웹 사이트와 메일 서버 모두에 사용했습니다. 상당히 잘 수행되었습니다. 대부분의 경우 페일 오버는 매우 빠르며 (2-5 분 추측) 거의 모든 사람이 15 분 이내에 장애 조치를 수행했다고합니다.

반드시 완벽 할 필요는 없지만 확실히 빠르고 쉽습니다.

참고 : 이것은 Windows 제품입니다. Linux 버전인지 여부는 확실하지 않지만 DNS 기반이기 때문에 원하는 서버를 페일 오버 할 수 있습니다.

우리의 경우에는 XP 시스템에서 방금 던졌고 밤새 한 번 재부팅하도록 시스템에 지시했으며 몇 년 동안 정상적으로 작동했습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.