25M 사진을 4가지 크기 = 총 100M 파일로 저장해야 합니다. 파일 크기는 파일당 3Kb에서 200kb 사이로 다양하며 처음에 사용되는 저장 공간은 약 14-15TB입니다.
우리의 목표는 2-4개의 서버에 데이터를 사용 가능하게 하고 이를 로컬 빠른 웹 서버(nginx 또는 lighthttpd)로 제공하는 것입니다. 초당 요청 수를 최대한 많이 서버해야 합니다.
내 계획은 데이터용으로 Raid 6(또는 중복성이 있는 FS??)가 포함된 12x2TB(WD RE4)가 포함된 Intel의 2U 서버 케이스를 사용하고 OS용으로 2x60GB SSD를 사용하는 것입니다. 좋은 방법인가요? 현재: 가장 많이 사용되는 파일의 캐시를 위해 SSD SLC 드라이브를 사용할 수 있는 Adaptec 5805ZQ를 찾았습니다. 이에 대한 제안 사항이 있습니까?
어떤 읽기 캐시 크기를 선택해야 합니까?
해당 서버를 2~4개 보유할 계획이라면 이중화 및 로드 밸런싱을 위한 가장 좋은 방법은 무엇입니까?
우리의 목표와 관련하여 클러스터와 분산 FS 간의 장단점은 무엇입니까?
답변1
이것이 그린필드 개발이라면,나는 이것을 위해 절대적으로 클라우드를 사용할 것입니다. 1억 개의 파일은 많은 양의 데이터입니다. Amazon S3에 대한 중복 스토리지를 오프로드하는 것은 큰 개선이 될 것입니다.
1억 개의 파일에 대해 이야기하고 있다는 점을 감안할 때 데이터 세트의 일부 부분은 '핫'(자주 요청됨)되고 대부분의 부분은 콜드 상태일 것이라고 안전하게 말할 수 있습니다. 따라서 우리는 캐싱을 정말로 원합니다.
Amazon Web Services에서 이 작업을 수행하는 방법에 대한 개요:
- 첫 번째 레이어:nginx 또는 Apache를 사용하여 몇 개의 작은 EC2 인스턴스에 대한 Amazon 관리형 Elastic Load Balancing 및 Amazon CloudWatch 모니터링. 이러한 서버는 정적 구성 파일이 있는 단순한 로드 밸런서이므로 Cloudwatch는 이를 모니터링하고 서버 중 하나가 충돌할 경우 자동으로 새 인스턴스를 생성할 수 있습니다.
- 첫 번째 레이어에서:요청 URL(파일 이름)을 기반으로 한 일관된 해스팅캐시 서버 계층으로. 각 파일이 여러 번 캐시되지 않도록(캐시 적중률 감소) 파일 이름을 기반으로 해싱을 수행하는 대신 N 캐시 서버를 사용하면 각 서버가 주소 공간의 1/N을 처리합니다.
- 두 번째 레이어:캐시 서버. 캐시 서버는 메모리가 더 많고 Squid 또는 Varnish 또는아파치 트래픽 서버캐시가 설치되었습니다.
- 두 번째 계층: 일반 기존 HTTP에서 Amazon S3 파일 스토리지까지.
이 설정은 느슨하게 결합되어 있으므로수평으로 확장하는 것은 쉽습니다.(스케일링 문제가 발생함에 따라).
속도는 핫 데이터와 콜드 데이터의 비율에 따라 크게 달라집니다. 워크로드가 대부분 핫하다면 2개의 소형 로드 밸런서 EC2와 2개의 고용량 메모리 캐시 EC2 인스턴스에서 요청/초가 10,000개를 훨씬 넘는다고 해도 놀라지 않을 것입니다.
답변2
30초 더 빠르게 부팅하는 데 정말로 관심이 없다면 OS 자체용 SSD는 과잉입니다. 작은 SAS 드라이브 한 쌍만 구입하면 충분합니다.
Wrt. 캐시의 유용성은 작업 세트에 따라 다릅니다. 즉, 모든 이미지에 고르게 분산될 것으로 예상되는 이미지에 대한 요청입니까, 아니면 대부분의 요청이 작은 하위 집합에 대한 것일 것으로 예상합니까? 후자의 경우 캐시가 유용할 수 있지만 전자의 경우에는 그다지 유용하지 않습니다. 디스크 컨트롤러의 캐시는 주로 쓰기를 캐시하는 데 유용하며(캐시가 비휘발성인 경우) 데이터베이스와 같은 fsync() 집약적 애플리케이션에 유용합니다. 이미지 제공의 경우 이점이 그다지 크지 않을 것으로 생각됩니다.
클러스터 및 분산 FS의 문제점은 설정이 더 복잡하고 특히 분산 FS는 "일반" 단일 노드 FS보다 성숙도가 낮다는 것입니다. 클러스터 FS는 일반적으로 공유 스토리지를 의미합니다. 이는 단일 장애 지점을 방지하려는 경우 상대적으로 비용이 많이 드는 SAN을 의미합니다.
대안은 HTTP에 액세스할 수 있는 분산 및 복제 키-값 저장소를 제공하는 일종의 Amazon S3 유사를 실행하는 클러스터를 설정하는 것입니다. 예:오픈스택 스토리지.
답변3
해당 항목이 얼마나 자주 사용되는지에 따라 많은 것이 달라집니다. 그 중 작은 비율이 한 번에 매우 활성화될 것으로 예상할 수 있다면 Varnish를 프런트 엔드 처리로 고려하고 nginx/lighthttpd 백엔드에서 로드 밸런싱을 수행하는 것이 좋습니다. 자주 사용하는 이미지는 캐시되기 때문에 디스크 속도는 조금 덜 중요합니다.
그러나 이미지가 반복적으로 요청되지 않고 캐싱이 큰 향상을 제공하지 않는 경우 서버 한두 개에 있는 nginx/lighttpd가 이를 수행합니다. 또한 제공할 대역폭의 양도 고려해야 합니다. 데이터 세트의 작은 하위 집합 중 800mb/초는 OS에 의해 쉽게 캐시됩니다. 데이터 세트의 대규모 하위 집합 중 800mb/초는 디스크에서 데이터를 제공할 수 있을 만큼 빠르게 데이터를 가져올 수 없다는 점에서 IO 병목 현상이 발생할 수 있습니다. 이 경우 시스템을 IO를 확보할 만큼 충분한 부분으로 분할해야 합니다. 대역폭.
raid-6을 실행 중이더라도 여전히 백업을 대체할 수는 없으므로 백업을 수행하거나 장애 조치 스토리지 서버 역할을 할 수 있도록 비슷한 시스템을 예산에 책정하십시오.
답변4
분산 FS 대신 사용자 지정 클러스터를 선택하겠습니다. 작업하는 동안 이해하고 문제를 해결하는 것이 더 간단하기 때문입니다. 즉, 자체 클러스터의 안정성 상충관계는 명백하지만, 분산 FS가 작동하지 않는 서버나 실패한 스위치에 어떻게 반응하는지 파악하는 것은 자체 작업입니다.
문제 유형에 대한 가능한 해결책은 전체 사진 아카이브를 여러 부분(예: 2개 부분)으로 분할하고 URL에 부분 ID를 명시적으로 만드는 것입니다(예: 일반 명령으로 쉽게 추출할 수 있는 하위 도메인 또는 GET 매개변수로 만드는 것). 표현). 그러면 사진이 포함된 4개의 스토리지 서버(각 부분당 2개의 서버)가 있게 됩니다. 다섯 번째 서버를 로드를 분산하고 균형을 맞추는 역방향 프록시로 사용합니다. 5개 서버 모두 lighttpd를 실행할 수 있습니다. 즉, 나는 매우 멍청하지만 작동하는 것을 제안합니다(내가 일했던 회사의 경우 - 초당 총 로드 ~5000개 요청, 크기가 3-10KB인 파일, 총 8TB의 고유 파일, 24개의 백엔드 서버 그러나 lighttpd 솔루션 대신 사용자 정의 HTTP 데몬을 실행하세요.
디스크 및 RAM의 경우: 우리는 각 서버에 4개의 빠르지만 저렴한 SATA 디스크로 구성된 소프트웨어 RAID-0을 사용했습니다(디스크에 오류가 발생하면 모든 데이터는 다른 서버의 복제본에서 어쨌든 복사될 수 있음). 단일 읽기 오류 후 전체 서버를 오프라인으로 전환합니다. RAID-5와 RAID-6은 디스크 하나가 고장나더라도 속도면에서 매우 나쁘므로 사용하지 마십시오. 콘텐츠 서버에서는 디스크 캐시로 많은 양의 RAM이 필수적입니다. 24GB 이상을 찾으세요. 그렇더라도 30분의 준비 시간을 준비하세요. 역방향 프록시에서 lighttpd를 사용하는 경우 전체 업스트림 응답을 가능한 한 빨리 RAM에 버퍼링하고 캐시된 사진을 다이얼업이나 GPRS를 통해 누군가에게 푸시하는 데 많은 시간을 소비할 수 있다는 점을 고려하십시오(그리고 그 시간 동안) , RAM에 해당 버퍼가 필요합니다). 동일한 구성을 유지하기 위해 24GB도 사용했지만 이것이 과잉인지는 잘 모르겠습니다. 역방향 프록시의 메모리 기반 HTTP 캐시는 필수가 아닙니다(핫 이미지가 있더라도!). 백엔드의 OS 제공 디스크 캐시도 마찬가지로 작동하기 때문입니다.
아카이브의 동일한 부분을 제공하는 모든 백엔드가 동일한 데이터를 갖도록 하는 것은 쉽습니다. 사진을 게시할 때 모든 서버에 복사하면 됩니다. 그런 다음 아카이브의 이전 부분에서 rsync를 사용하여 불일치를 수정하여 하나의 복사본을 마스터로 만듭니다.