Badoo에서 사진을 저장하고 공유하기 위한 아키텍처

아르템 데니소프( bo0rsh201, Badoo)

Badoo는 세계 최대의 데이트 사이트입니다. 현재 전 세계적으로 약 330억 3천만 명의 등록 사용자가 있습니다. 하지만 오늘 대화의 맥락에서 훨씬 더 중요한 것은 약 3,5페타바이트의 사용자 사진을 저장한다는 것입니다. 매일 우리 사용자들은 약 XNUMX만 장의 새로운 사진을 업로드하며, 독서량은 약 초당 요청 80개. 이는 우리 백엔드에 있어서 상당히 많은 일이며 때로는 이로 인해 어려움이 있습니다.

일반적으로 사진을 저장하고 전송하는 이 시스템의 설계에 대해 이야기하고 개발자의 관점에서 살펴보겠습니다. 어떻게 개발되었는지 간략하게 회고하고 주요 이정표를 간략하게 설명할 예정입니다. 하지만 현재 사용 중인 솔루션에 대해서만 더 자세히 설명하겠습니다.

이제 시작해 보겠습니다.

내가 말했듯이 이것은 회고전이 될 것이며 어딘가에서 시작하기 위해 가장 일반적인 예를 들어 보겠습니다.

우리에게는 사용자 사진을 수락, 저장 및 전송해야 하는 공통 작업이 있습니다. 이 형식에서는 작업이 일반적이므로 무엇이든 사용할 수 있습니다.

• 최신 클라우드 스토리지,
• 현재도 많은 박스형 솔루션이 있습니다.
• 우리는 데이터 센터에 여러 대의 시스템을 설치하고 그 위에 대형 하드 드라이브를 설치하고 거기에 사진을 저장할 수 있습니다.

역사적으로 Badoo는 - 지금과 그때(초창기 시절) - 자체 서버, 자체 DC 내부에 존재합니다. 따라서 이 옵션은 우리에게 최적이었습니다.

우리는 "사진"이라고 불리는 여러 대의 머신을 가져와서 사진을 저장하는 클러스터를 얻었습니다. 하지만 뭔가 빠진 것 같습니다. 이 모든 것이 작동하려면 어떤 컴퓨터에 어떤 사진을 저장할지 어떻게든 결정해야 합니다. 그리고 여기서도 미국을 열 필요가 없습니다.

사용자에 대한 정보가 포함된 일부 필드를 저장소에 추가합니다. 이것이 샤딩 키가 됩니다. 우리의 경우 place_id라고 불렀고, 이 장소 ID는 사용자 사진이 저장되는 장소를 가리킵니다. 우리는 지도를 만듭니다.

첫 번째 단계에서는 이 작업을 수동으로 수행할 수도 있습니다. 해당 장소에 대한 이 사용자의 사진이 해당 서버에 저장될 것이라고 말합니다. 이 지도 덕분에 우리는 사용자가 언제 사진을 업로드하는지, 어디에 저장하는지, 어디서 사진을 제공하는지 항상 알 수 있습니다.

이것은 아주 사소한 계획이지만 상당한 이점이 있습니다. 첫 번째는 제가 말했듯이 간단하다는 것이고, 두 번째는 이 접근 방식을 사용하면 새 자동차를 제공하고 지도에 추가하는 것만으로 쉽게 수평으로 확장할 수 있다는 것입니다. 다른 작업을 수행할 필요가 없습니다.

한동안 우리는 그랬습니다.

2009년쯤이었어요. 그들은 자동차를 배달하고, 배달하고...

그리고 어느 시점에서 우리는 이 계획에 특정한 단점이 있다는 것을 깨닫기 시작했습니다. 단점은 무엇입니까?

우선 용량이 ​​제한되어 있습니다. 우리는 원하는 만큼 많은 하드 드라이브를 하나의 물리적 서버에 넣을 수 없습니다. 그리고 이는 시간이 지남에 따라 데이터 세트가 증가함에 따라 특정 문제가 되었습니다.

그리고 두 번째. 이러한 머신은 일부 다른 클러스터에서 재사용하기 어렵기 때문에 이는 머신의 비정형 구성입니다. 성능은 약하지만 동시에 대용량 하드 드라이브를 사용해야 합니다.

이는 2009년에 대한 내용이었지만 원칙적으로 이러한 요구 사항은 오늘날에도 여전히 유효합니다. 회고전이있어서 2009 년에는 이것으로 모든 것이 완전히 나빴습니다.

그리고 마지막 포인트는 가격입니다.

그 당시에는 가격이 매우 높았기 때문에 우리는 몇 가지 대안을 찾아야 했습니다. 저것들. 우리는 데이터 센터의 공간과 이 모든 것이 위치한 물리적 서버를 어떻게든 더 잘 활용해야 했습니다. 그리고 우리 시스템 엔지니어들은 다양한 옵션을 검토하는 대규모 연구를 시작했습니다. 또한 PolyCeph 및 Luster와 같은 클러스터 파일 시스템도 살펴보았습니다. 성능 문제가 있었고 작동이 상당히 어려웠습니다. 그들은 거절했습니다. 우리는 어떻게든 확장하기 위해 각 자동차에 NFS를 통해 전체 데이터 세트를 마운트하려고 했습니다. 읽기도 제대로 진행되지 않았습니다. 우리는 여러 공급업체의 다양한 솔루션을 시도했습니다.

그리고 결국 우리는 소위 SAN(Storage Area Network)을 사용하기로 결정했습니다.

이는 대량의 데이터를 저장하기 위해 특별히 설계된 대형 SHD입니다. 최종 광출력 기계에 장착되는 디스크가 장착된 선반입니다. 저것. 우리는 아주 작은 일종의 기계 풀과 전송 논리에 투명한 이러한 SHD를 가지고 있습니다. 우리 nginx나 다른 누군가가 이 사진에 대한 요청을 처리할 수 있도록 말이죠.

이 결정에는 분명한 이점이 있었습니다. SHD 입니다. 사진을 저장하는 것을 목표로합니다. 이는 단순히 기계에 하드 드라이브를 장착하는 것보다 저렴합니다.

두 번째 플러스.

즉, 용량이 훨씬 커졌다는 것입니다. 우리는 훨씬 더 작은 볼륨에 훨씬 더 많은 스토리지를 수용할 수 있습니다.

하지만 꽤 빨리 나타난 단점도 있었습니다. 이 시스템의 사용자 수와 부하가 증가함에 따라 성능 문제가 발생하기 시작했습니다. 그리고 여기서 문제는 매우 분명합니다. 일반적으로 많은 사진을 작은 볼륨에 저장하도록 설계된 SHD는 집중적으로 읽는 데 어려움을 겪습니다. 이는 실제로 모든 클라우드 저장소나 다른 모든 것에 해당됩니다. 이제 우리는 무한히 확장할 수 있고 무엇이든 넣을 수 있으며 판독을 매우 잘 견딜 수 있는 이상적인 스토리지가 없습니다. 특히 일상적인 독서.

사진의 경우와 마찬가지로 사진이 일관되지 않게 요청되므로 성능에 큰 영향을 미치게 됩니다.

오늘날의 수치에 따르면 스토리지가 연결된 시스템에서 사진에 대해 500RPS 이상이면 문제가 이미 시작됩니다. 그리고 그것은 우리에게 충분히 나빴습니다. 사용자 수가 증가하고 있기 때문에 상황은 더욱 악화될 것입니다. 이건 어떻게든 최적화가 필요합니다.

최적화하기 위해 당시 우리는 일반적으로 무슨 일이 일어나고 있는지, 무엇이 최적화되어야 하는지 로드 프로필을 살펴보기로 결정했습니다.

그리고 여기서 모든 것이 우리 손에 달려 있습니다.

첫 번째 슬라이드에서 이미 말했듯이 초당 80만 건의 읽기 요청이 있고 하루에 업로드되는 건 3,5만 건에 불과합니다. 즉, 이는 XNUMX자리 크기의 차이입니다. 독서가 최적화되어야 한다는 것은 명백하며 실제로 어떻게 해야 하는지도 분명합니다.

작은 점이 하나 더 있습니다. 서비스의 특징은 사람이 등록하고 사진을 업로드 한 다음 자신과 같은 다른 사람들을 적극적으로 바라보기 시작하고 다른 사람들에게 적극적으로 보여지는 것입니다. 그러다가 짝을 찾느냐 못 찾느냐에 따라 결과가 달라지고 잠시 서비스 이용을 중단하게 됩니다. 현재 그가 사용하는 사진은 매우 뜨겁습니다. 수요가 많고 많은 사람들이 사진을 봅니다. 그가 이 일을 멈추자마자 그는 이전처럼 다른 사람들에게 노출되는 일이 아주 빨리 중단되고 그의 사진은 거의 요청되지 않습니다.

저것들. 우리는 매우 작은 핫 데이터 세트를 가지고 있습니다. 그러나 동시에 그에게 많은 요청이 있습니다. 여기서 완전히 확실한 해결책은 캐시를 추가하는 것입니다.

LRU가 있는 캐시는 모든 문제를 해결할 것입니다. 우리는 무엇을하고 있습니까?

우리는 저장소가 있는 대규모 클러스터 앞에 포토캐시라고 하는 상대적으로 작은 또 다른 하나를 추가합니다. 이는 본질적으로 캐싱 프록시일 뿐입니다.

내부에서는 어떻게 작동하나요? 여기 사용자가 있고 여기에 저장소가 있습니다. 모든 것이 이전과 동일합니다. 그 사이에 무엇을 추가합니까?

이는 단지 물리적인 로컬 디스크가 있는 머신일 뿐이며 속도가 빠릅니다. 예를 들어 SSD를 사용하는 경우입니다. 그리고 이 디스크에는 일종의 로컬 캐시가 저장됩니다.

그것은 어떻게 생겼나요? 사용자가 사진 요청을 보냅니다. NGINX는 먼저 로컬 캐시에서 이를 찾습니다. 그렇지 않은 경우 간단히 우리 저장소에 Proxy_pass를 수행하고 거기에서 사진을 다운로드하여 사용자에게 제공하십시오.

그러나 이것은 매우 진부하고 내부에서 무슨 일이 일어나고 있는지 불분명합니다. 그것은 다음과 같이 작동합니다.

캐시는 논리적으로 세 개의 레이어로 구분됩니다. 내가 "XNUMX개의 층"이라고 말할 때 이것은 어떤 종류의 복잡한 시스템이 있다는 것을 의미하지 않습니다. 아니요, 이는 조건부로 파일 시스템의 세 디렉터리에 불과합니다.

1. 이것은 프록시에서 방금 다운로드한 사진이 이동하는 버퍼입니다.
2. 현재 활발하게 요청된 사진을 저장하는 핫캐시입니다.
3. 그리고 요청이 적을수록 사진이 핫 캐시에서 점차적으로 밀려나는 콜드 캐시도 있습니다.

이것이 작동하려면 어떻게든 이 캐시를 관리해야 하고, 그 안에 있는 사진을 다시 정렬해야 합니다. 이 역시 매우 원시적인 과정이다.

Nginx는 각 요청에 대해 RAMDisk access.log에 기록합니다. 여기에는 현재 제공되는 사진의 경로(물론 상대 경로)와 제공되는 파티션이 표시됩니다. 저것들. "사진 1"이라고 표시된 다음 버퍼, 핫 캐시, 콜드 캐시 또는 프록시가 표시될 수 있습니다.

이에 따라 우리는 사진으로 무엇을 할지 어떻게든 결정해야 합니다.

각 컴퓨터에는 이 로그를 지속적으로 읽고 특정 사진 사용에 대한 통계를 메모리에 저장하는 작은 데몬이 실행되고 있습니다.

그는 단순히 거기에 수집하고 카운터를 유지하며 주기적으로 다음을 수행합니다. 요청이 많은 적극적으로 요청된 사진을 어디에 있든 핫캐시로 옮깁니다.

거의 요청되지 않고 덜 자주 요청되는 사진은 점차적으로 핫 캐시에서 콜드 캐시로 푸시됩니다.

그리고 캐시 공간이 부족해지면 콜드 캐시에서 모든 것을 무차별적으로 삭제하기 시작합니다. 그건 그렇고, 이것은 잘 작동합니다.

사진을 버퍼에 프록시할 때 사진이 즉시 저장되도록 하려면 Proxy_store 지시문을 사용하고 버퍼도 RAMDisk입니다. 사용자에게는 매우 빠르게 작동합니다. 이는 캐싱 서버 자체의 내부와 관련이 있습니다.

남은 질문은 이러한 서버에 요청을 배포하는 방법입니다.

XNUMX개의 스토리지 시스템과 XNUMX개의 캐싱 서버로 구성된 클러스터가 있다고 가정해 보겠습니다(이렇게 되었습니다).

우리는 어떤 사진에 대한 요청이 무엇인지, 그리고 사진을 어디에 전달할 것인지 어떻게든 결정해야 합니다.

가장 일반적인 옵션은 라운드 로빈입니다. 아니면 우연히 그런 일을 하게 됩니까?

이러한 상황에서는 캐시를 매우 비효율적으로 사용하게 되므로 분명히 여러 가지 단점이 있습니다. 요청은 임의의 시스템에 전달됩니다. 여기서는 캐시되었지만 다음 시스템에서는 더 이상 존재하지 않습니다. 그리고 이 모든 것이 효과가 있다면 상황은 매우 나쁠 것입니다. 클러스터에 있는 시스템 수가 적은 경우에도 마찬가지입니다.

어떤 서버에서 어떤 요청을 전달할 것인지 명확하게 결정해야 합니다.

진부한 방법이 있습니다. URL에서 해시를 가져오거나 URL에 있는 공유 키에서 해시를 가져와 서버 수로 나눕니다. 작동할까요? 할 것이다.

저것들. 예를 들어, 2% 요청이 있습니다. 예를 들어 일부 "example_url"에 대한 요청은 항상 인덱스 "XNUMX"가 있는 서버에 도달하고 캐시는 가능한 한 최상의 상태로 지속적으로 폐기됩니다.

그러나 이러한 방식에서는 리샤딩(Resharding)에 문제가 있습니다. 리샤딩(Resharding) - 서버 수를 변경하는 것을 의미합니다.

캐싱 클러스터가 더 이상 대처할 수 없어 다른 시스템을 추가하기로 결정했다고 가정해 보겠습니다.

추가해 보겠습니다.

이제 모든 것은 XNUMX이 아닌 XNUMX로 나누어질 수 있습니다. 따라서 우리가 가지고 있던 거의 모든 키와 거의 모든 URL이 이제 다른 서버에 있습니다. 잠시 동안 전체 캐시가 무효화되었습니다. 모든 요청이 스토리지 클러스터에 전달되어 상태가 나빠지고 서비스가 실패하고 사용자가 불만족스러워졌습니다. 나는 그렇게 하고 싶지 않습니다.

이 옵션은 우리에게도 적합하지 않습니다.

저것. 우리는 무엇을 해야 합니까? 우리는 어떻게든 캐시를 효율적으로 활용하고 동일한 서버에 동일한 요청을 계속해서 보내야 하지만 리샤딩에 저항해야 합니다. 그리고 그러한 해결책이 있습니다. 그렇게 복잡하지 않습니다. 이를 일관된 해싱이라고 합니다.

어떻게 생겼나요?

우리는 샤딩 키에서 일부 기능을 가져와 모든 값을 원에 퍼뜨립니다. 저것들. 지점 0에서는 최소값과 최대값이 수렴됩니다. 다음으로 우리는 대략 다음과 같은 방식으로 모든 서버를 동일한 원에 배치합니다.

각 서버는 한 지점으로 정의되며 그에 따라 시계 방향으로 이동하는 섹터가 이 호스트에 의해 제공됩니다. 요청이 우리에게 오면 예를 들어 요청 A(해시가 있음)가 서버 2에서 제공되고 요청 B - 서버 3에서 제공된다는 것을 즉시 알 수 있습니다.

리샤딩 중에 이 상황에서는 어떻게 되나요?

이전처럼 전체 캐시를 무효화하지 않고 모든 키를 이동하지 않지만 상대적으로 말하면 추가하려는 여섯 번째 서버가 여유 공간에 맞도록 각 섹터를 짧은 거리로 이동합니다. 거기에 추가하겠습니다.

물론 이러한 상황에서는 키도 밖으로 이동합니다. 그러나 그들은 이전보다 훨씬 약해졌습니다. 그리고 처음 두 키는 서버에 남아 있고 캐싱 서버는 마지막 키에 대해서만 변경되었음을 알 수 있습니다. 이는 매우 효율적으로 작동하며 새 호스트를 점진적으로 추가하면 여기서는 큰 문제가 없습니다. 한 번에 조금씩 추가하고 캐시가 다시 가득 찰 때까지 기다리면 모든 것이 잘 작동합니다.

유일한 질문은 거절입니다. 어떤 종류의 자동차가 고장났다고 가정해 봅시다.

그리고 예를 들어 시스템이 재부팅되어 어떻게든 요청을 처리해야 하는 경우 이 순간에는 이 맵을 재생성하거나 캐시의 일부를 무효화하는 등의 작업을 실제로 원하지 않습니다. 우리는 각 사이트에 하나의 백업 사진 캐시를 보관하기만 하면 현재 작동이 중단된 모든 컴퓨터를 대체하는 역할을 합니다. 그리고 갑자기 서버 중 하나를 사용할 수 없게 되면 트래픽이 해당 서버로 이동합니다. 당연히 거기에는 캐시가 없습니다. 춥지만 최소한 사용자 요청은 처리 중입니다. 이것이 짧은 간격이라면 우리는 그것을 완전히 침착하게 경험합니다. 스토리지에 부하가 더 많이 걸립니다. 이 간격이 길면 이미 결정을 내릴 수 있습니다. 즉, 이 서버를 맵에서 제거할지 여부를 결정하거나 다른 서버로 교체할 수도 있습니다.

캐싱 시스템에 관한 것입니다. 결과를 살펴보겠습니다.

여기에는 복잡한 것이없는 것 같습니다. 하지만 이 캐시 관리 방법은 약 98%의 트릭률을 보여주었습니다. 저것들. 초당 80개의 요청 중 1600개만이 저장소에 도달하며 이것은 완전히 정상적인 로드이며 침착하게 견디며 항상 예비가 있습니다.

우리는 이 서버를 XNUMX개의 DC에 배치했으며 프라하, 마이애미, 홍콩의 XNUMX개 지점을 받았습니다.

저것. 그들은 우리의 목표 시장 각각에 어느 정도 지역적으로 위치하고 있습니다.

그리고 좋은 보너스로 우리는 콘텐츠를 제공하는 데 그다지 필요하지 않기 때문에 CPU가 실제로 유휴 상태인 캐싱 프록시를 얻었습니다. 그리고 거기에서 NGINX+ Lua를 사용하여 많은 실용적인 논리를 구현했습니다.

예를 들어, webp 또는 프로그레시브 jpeg(효과적인 최신 형식)를 실험하고, 이것이 트래픽에 어떤 영향을 미치는지 확인하고, 몇 가지 결정을 내리고, 특정 국가에 대해 활성화할 수 있습니다. 즉석에서 사진을 동적으로 크기 조정하거나 자르세요.

예를 들어 사진을 표시하는 모바일 애플리케이션이 있고 모바일 애플리케이션이 큰 사진을 요청한 다음 특정 크기로 크기를 조정하여 클라이언트의 CPU를 낭비하고 싶지 않을 때 좋은 사용 사례입니다. 보기. UPort 조건부 URL에 일부 매개변수를 동적으로 지정하면 사진 캐시가 사진 자체의 크기를 조정합니다. 일반적으로 디스크에 물리적으로 있는 크기를 요청한 크기에 최대한 가깝게 선택하고 특정 좌표에서 하향 판매합니다.

그건 그렇고, 우리는 지난 XNUMX년간의 고부하 시스템 개발자 컨퍼런스의 비디오 녹화물을 공개적으로 만들었습니다. HighLoad ++. 보고, 배우고, 공유하고, 구독하세요 유튜브 채널.

거기에 많은 제품 로직을 추가할 수도 있습니다. 예를 들어, URL 매개변수를 사용하여 다양한 워터마크를 추가할 수 있고 사진을 흐리게 하거나 픽셀화할 수 있습니다. 이것은 사람의 사진을 보여주고 싶지만 얼굴은 보여주고 싶지 않은 경우입니다. 이것은 잘 작동하며 모두 여기에 구현되어 있습니다.

우리는 무엇을 얻었나요? 우리는 세 개의 접속 지점과 좋은 트릭률을 얻었으며 동시에 이 시스템에는 유휴 CPU가 없습니다. 물론 그는 이제 이전보다 더 중요해졌습니다. 우리는 더 강력한 자동차를 제공해야 하지만 그만한 가치가 있습니다.

이는 사진 반환에 관한 것입니다. 여기의 모든 것은 매우 명확하고 분명합니다. 나는 미국을 발견하지 못했다고 생각합니다. 거의 모든 CDN이 이런 식으로 작동합니다.

그리고 아마도 정교한 청취자는 다음과 같은 질문을 할 수도 있습니다. 모든 것을 CDN으로 변경하는 것이 어떨까요? 거의 동일할 것입니다. 모든 최신 CDN이 이를 수행할 수 있습니다. 그리고 여러 가지 이유가 있습니다.

첫 번째는 사진이다.

이는 우리 인프라의 핵심 포인트 중 하나이며 이에 대해 최대한 많은 제어가 필요합니다. 이것이 제XNUMX자 공급업체의 일종의 솔루션이고 이에 대한 권한이 없다면 대규모 데이터 세트가 있고 흐름이 매우 클 때 이를 사용하기가 상당히 어려울 것입니다. 사용자 요청의 수입니다.

예를 들어 보겠습니다. 이제 우리 인프라를 사용하면 예를 들어 문제가 발생하거나 지하에서 노크가 발생하는 경우 상대적으로 말하자면 기계로 가서 주변을 어지럽힐 수 있습니다. 우리는 필요한 일부 측정 항목 모음을 추가할 수 있고, 어떻게든 실험할 수 있으며, 이것이 그래프에 어떤 영향을 미치는지 확인할 수 있습니다. 이제 이 캐싱 클러스터에서 많은 통계가 수집되고 있습니다. 그리고 우리는 주기적으로 그것을 살펴보고 몇 가지 이상 현상을 탐색하는 데 오랜 시간을 보냅니다. CDN 쪽이라면 제어하기가 훨씬 더 어려울 것입니다. 또는 예를 들어, 어떤 종류의 사고가 발생하면 무슨 일이 일어났는지 알고, 이를 감수하고 살아가는 방법과 극복하는 방법을 알고 있습니다. 이것이 첫 번째 결론입니다.

두 번째 결론도 다소 역사적입니다. 왜냐하면 시스템이 오랫동안 개발되어 왔으며 여러 단계에서 다양한 비즈니스 요구 사항이 있었으며 이러한 요구 사항이 항상 CDN 개념에 맞지는 않기 때문입니다.

그리고 이전 것에서 이어지는 요점은

이는 사진 캐시에 요청 시 항상 추가할 수 없는 특정 논리가 많이 있기 때문입니다. 귀하의 요청에 따라 CDN이 일부 사용자 정의 항목을 추가할 가능성은 거의 없습니다. 예를 들어 클라이언트가 무언가를 변경할 수 없도록 하려는 경우 URL을 암호화합니다. 서버의 URL을 변경하고 암호화한 다음 여기에 일부 동적 매개변수를 보내시겠습니까?

이는 어떤 결론을 시사하는가? 우리의 경우 CDN은 그다지 좋은 대안이 아닙니다.

귀하의 경우 특정 비즈니스 요구 사항이 있는 경우 제가 직접 보여드린 내용을 매우 쉽게 구현할 수 있습니다. 이는 유사한 로드 프로필에서 완벽하게 작동합니다.

그러나 일반적인 솔루션이 있고 작업이 그다지 구체적이지 않은 경우 CDN을 절대적으로 안전하게 사용할 수 있습니다. 또는 통제보다 시간과 자원이 더 중요한 경우.

그리고 최신 CDN에는 제가 지금 말씀드린 거의 모든 내용이 포함되어 있습니다. 플러스 또는 마이너스 일부 기능을 제외하고.

사진을 드리는 것입니다.

이제 회고를 조금 더 진행하여 스토리지에 대해 이야기해 보겠습니다.

2013년이 지나가고 있었습니다.

캐싱 서버가 추가되어 성능 문제가 사라졌습니다. 모든 것이 괜찮습니다. 데이터 세트가 증가하고 있습니다. 2013년 현재 스토리지에 연결된 서버는 약 80대, 각 DC에는 약 40대의 캐싱 서버가 있습니다. 이는 각 DC에 560테라바이트의 데이터입니다. 총 약 페타바이트에 달합니다.

그리고 데이터 세트가 증가함에 따라 운영 비용도 크게 증가하기 시작했습니다. 이것은 무엇을 의미합니까?

SAN, 머신 및 캐시가 연결된 이 다이어그램에는 많은 오류 지점이 있습니다. 이전에 캐싱 서버의 오류를 이미 처리했다면 모든 것이 다소 예측 가능하고 이해할 수 있었지만 스토리지 측면에서는 모든 것이 훨씬 더 나빴습니다.

첫째, SAN(Storage Area Network) 자체가 실패할 수 있습니다.

둘째, 광학을 통해 최종 기계에 연결됩니다. 광카드와 스파크 플러그에 문제가 있을 수 있습니다.

물론 SAN 자체만큼 많지는 않지만 그럼에도 불구하고 이는 실패 지점이기도 합니다.

다음은 스토리지에 연결된 머신 자체입니다. 실패할 수도 있습니다.

전체적으로 세 가지 실패 지점이 있습니다.

또한 장애 지점 외에도 저장소 자체에 대한 유지 관리가 많이 필요합니다.

이는 복잡한 다중 구성 요소 시스템이므로 시스템 엔지니어가 작업하는 데 어려움을 겪을 수 있습니다.

그리고 마지막으로 가장 중요한 점. 이 세 지점 중 하나에서 오류가 발생하면 파일 시스템이 충돌할 수 있으므로 사용자 데이터가 손실될 가능성이 XNUMX이 아닙니다.

파일 시스템이 손상되었다고 가정해 보겠습니다. 첫째, 복구 시간이 오래 걸립니다. 데이터 양이 많으면 일주일이 걸릴 수 있습니다. 둘째, 결국 우리는 어떻게든 사용자 사진에 결합해야 하는 이해할 수 없는 파일 묶음으로 끝날 가능성이 높습니다. 그리고 데이터가 손실될 위험이 있습니다. 위험이 상당히 높습니다. 그리고 그러한 상황이 더 자주 발생하고 이 전체 체인에서 더 많은 문제가 발생할수록 이러한 위험은 더 높아집니다.

이에 대해 뭔가 조치를 취해야 했습니다. 그리고 우리는 데이터만 백업하면 된다고 결정했습니다. 이것은 실제로 분명한 해결책이자 좋은 해결책입니다. 우리는 무엇을 했나요?

이전에 우리 서버가 스토리지에 연결되었을 때의 모습입니다. 이것은 주요 섹션 중 하나이며 실제로 광학 장치를 통한 원격 저장소용 마운트를 나타내는 블록 장치일 뿐입니다.

방금 두 번째 섹션을 추가했습니다.

그 옆에 두 번째 저장소를 배치하고(다행히 돈 측면에서 그리 비싸지 않음) 이를 백업 파티션이라고 불렀습니다. 또한 광학 장치를 통해 연결되며 동일한 기계에 위치합니다. 하지만 어떻게든 그들 사이의 데이터를 동기화해야 합니다.

여기서는 근처에 비동기 대기열을 만듭니다.

그녀는 별로 바쁘지 않습니다. 우리는 기록이 충분하지 않다는 것을 알고 있습니다. 대기열은 "이 사진을 백업해야 합니다"와 같은 줄이 기록되는 MySQL의 테이블입니다. 변경이나 업로드가 있으면 비동기식 또는 일종의 백그라운드 작업자를 사용하여 기본 파티션에서 백업으로 복사합니다.

따라서 우리는 항상 두 개의 일관된 섹션을 갖습니다. 이 시스템의 한 부분이 실패하더라도 백업을 통해 언제든지 기본 파티션을 변경할 수 있으며 모든 것이 계속 작동합니다.

하지만 이로 인해 읽기 부하가 크게 증가하기 때문에... 메인 섹션에서 읽는 클라이언트에 추가로, 먼저 거기서 사진을 보고(더 최근의 것임), 찾지 못한 경우 백업에서 찾기 때문입니다(그러나 NGINX는 이 작업을 수행합니다). 우리 시스템은 이제 메인 파티션에서 읽어들이는 플러스 백업이기도 합니다. 병목 현상이 발생한 것은 아니지만 본질적으로 그렇게 부하를 늘리고 싶지 않았습니다.

그리고 작은 SSD인 세 번째 디스크를 추가하고 이를 버퍼라고 불렀습니다.

지금은 어떻게 작동하나요?

사용자가 사진을 버퍼에 업로드하면 해당 사진을 두 섹션으로 복사해야 함을 나타내는 이벤트가 대기열에 발생합니다. 복사된 사진은 일정 시간(예: 하루) 동안 버퍼에 남아 있다가 그 후에만 버퍼에서 제거됩니다. 사용자가 사진을 업로드하면 일반적으로 요청이 즉시 따르기 시작하거나 직접 페이지를 업데이트하고 새로 고치기 때문에 사용자 경험이 크게 향상됩니다. 그러나 그것은 모두 업로드를 수행하는 응용 프로그램에 따라 다릅니다.

또는 예를 들어, 그가 자신을 보여주기 시작한 다른 사람들은 이 사진 이후에 즉시 요청을 보냅니다. 아직 캐시에 있지 않으므로 첫 번째 요청이 매우 빠르게 발생합니다. 본질적으로 사진 캐시와 동일합니다. 느린 저장은 여기에 전혀 관여하지 않습니다. 그리고 하루 후 해당 항목이 제거되면 이미 캐싱 레이어에 캐시되어 있거나 더 이상 이를 필요로 하는 사람이 없을 것입니다. 저것들. 이러한 간단한 조작 덕분에 여기의 사용자 경험은 매우 잘 성장했습니다.

음, 그리고 가장 중요한 것은 데이터 손실이 중단되었다는 것입니다.

그냥 우리가 멈췄다고 하자 잠재적으로 데이터를 잃어버리세요. 실제로는 손실된 것이 아니기 때문입니다. 그러나 위험이 있었습니다. 물론 이 해결책은 훌륭하지만 문제를 완전히 해결하는 것이 아니라 문제의 증상을 완화하는 것과 약간 비슷합니다. 그리고 여기에는 몇 가지 문제가 남아 있습니다.

첫째, 이는 이 모든 기계가 실행되는 물리적 호스트 자체 형태의 실패 지점이며 사라지지 않았습니다.

둘째, SAN에는 여전히 문제가 있고 유지 관리가 많이 필요합니다. 꼭 중요한 요소는 아니었지만, 어떻게든 그것 없이 살아보고 싶었어요.

그리고 우리는 예약 버전인 세 번째 버전(사실 두 번째 버전)을 만들었습니다. 어떤 모습이었나요?

바로 이런 것이었습니다 -

우리의 주요 문제는 이것이 물리적 호스트라는 사실입니다.

첫째, 실험을 원하고 로컬 하드 드라이브만 사용해 보고 싶기 때문에 SAN을 제거합니다.

이것은 이미 2014-2015년이며 그 당시 하나의 호스트에 있는 디스크와 용량의 상황이 훨씬 좋아졌습니다. 우리는 그것을 시도해 보는 것이 어떨까 결정했습니다.

그런 다음 백업 파티션을 가져와 물리적으로 별도의 시스템으로 전송합니다.

따라서 우리는 이 다이어그램을 얻습니다. 동일한 데이터 세트를 저장하는 두 대의 자동차가 있습니다. 그들은 서로를 완전히 백업하고 동일한 MySQL의 비동기 대기열을 통해 네트워크를 통해 데이터를 동기화합니다.

이것이 잘 작동하는 이유는 기록이 거의 없기 때문입니다. 저것들. 쓰기가 읽기와 비슷하다면 아마도 일종의 네트워크 오버헤드와 문제가 있을 것입니다. 쓰기는 적고 읽기는 많습니다. 이 방법은 효과적입니다. 우리는 이 두 서버 간에 사진을 거의 복사하지 않습니다.

좀 더 자세히 살펴보면 이것이 어떻게 작동합니까?

업로드합니다. 밸런서는 단순히 한 쌍의 호스트를 무작위로 선택하고 여기에 업로드합니다. 동시에 자연스럽게 건강검진도 하고, 차가 빠지지 않는지 확인도 해준다. 저것들. 그는 라이브 서버에만 사진을 업로드한 다음 비동기 대기열을 통해 모든 사진을 이웃에 복사합니다. 업로드를 사용하면 모든 것이 매우 간단합니다.

작업이 조금 더 어렵습니다.

바닐라 NGINX에서는 그러한 논리를 만드는 것이 어려울 수 있기 때문에 Lua가 우리를 도와주었습니다. 먼저 첫 번째 서버에 요청을 하고 사진이 있는지 확인합니다. 예를 들어 이웃에게 업로드될 수 있지만 아직 여기에 도착하지 않았기 때문입니다. 사진이 있다면 괜찮습니다. 우리는 이를 즉시 클라이언트에게 제공하고 가능하면 캐시합니다.

만약 거기에 없다면, 우리는 이웃에게 요청하기만 하면 그곳에서 그것을 받을 수 있다는 것이 보장됩니다.

저것. 다시 한 번 말할 수 있습니다. 끊임없는 왕복이 있기 때문에 성능에 문제가 있을 수 있습니다. 사진이 업로드되었지만 여기에 없으며 하나가 아닌 두 개의 요청을 하고 있으므로 천천히 작동해야 합니다.

우리 상황에서는 이것이 느리게 작동하지 않습니다.

우리는 이 시스템에서 많은 측정항목을 수집하며 이러한 메커니즘의 조건부 스마트 비율은 약 95%입니다. 저것들. 이 백업의 지연은 작으며 이로 인해 사진이 업로드된 후 처음으로 가져갈 것이며 두 번 어디로 갈 필요가 없다는 것이 거의 보장됩니다.

그럼 정말 멋진 게 또 있나요?

이전에는 기본 백업 파티션이 있었고 이를 순차적으로 읽었습니다. 저것들. 우리는 항상 기본 항목을 먼저 검색한 다음 백업을 검색했습니다. 그것은 하나의 움직임이었습니다.

이제 우리는 한 번에 두 대의 컴퓨터에서 읽는 것을 활용합니다. 우리는 Round Robin을 사용하여 요청을 배포합니다. 소수의 경우에는 두 가지 요청을 합니다. 그러나 전반적으로 우리는 이제 이전보다 두 배나 많은 독서량을 보유하고 있습니다. 그리고 당시에도 있었던 전송 시스템과 저장 시스템 모두에서 부하가 크게 감소했습니다.

내결함성에 관해서. 사실 우리가 주로 싸운 것은 바로 이것이다. 내결함성을 통해 모든 것이 훌륭해졌습니다.

자동차 한 대가 고장이 납니다.

괜찮아요! 시스템 엔지니어는 밤에도 일어나지 않을 수도 있고 아침까지 기다릴 것이며 나쁜 일은 일어나지 않을 것입니다.

만약 이 기계가 고장이 나더라도 큐가 고장나면 문제가 되지 않고 먼저 리빙 머신에 로그가 쌓인 다음 큐에 추가된 다음 차에 싣게 됩니다. 잠시 후 가동에 들어갑니다.

유지 관리도 마찬가지입니다. 머신 중 하나를 끄고 모든 풀에서 수동으로 꺼내면 트래픽 수신이 중단됩니다. 일종의 유지 관리를 수행하고 무언가를 편집한 다음 서비스로 되돌리면 이 백업이 매우 빠르게 따라잡습니다. 저것들. 하루에 한 대의 자동차의 가동 중지 시간이 몇 분 이내에 따라잡힙니다. 이것은 정말 아주 적습니다. 내결함성을 통해 다시 말하지만 여기서는 모든 것이 훌륭합니다.

이 중복 계획에서 어떤 결론을 얻을 수 있습니까?

우리는 내결함성을 얻었습니다.

사용하기 쉬운. 기계에는 로컬 하드 드라이브가 있으므로 이를 사용하는 엔지니어의 운영 관점에서 볼 때 이는 훨씬 더 편리합니다.

우리는 독서 수당을 두 배로 받았습니다.

이는 내결함성 외에도 매우 좋은 보너스입니다.

그러나 문제도 있습니다. 이제 시스템이 100% 최종 일관성을 가지게 되었기 때문에 이와 관련된 일부 기능을 훨씬 더 복잡하게 개발했습니다.

예를 들어, 백그라운드 작업에서 "지금 우리가 실행 중인 서버는 무엇인가?", "여기에 현재 사진이 실제로 있는 걸까?"라고 끊임없이 생각해야 합니다. 등. 물론 이것은 모두 마무리되었으며 비즈니스 로직을 작성하는 프로그래머에게는 투명합니다. 그러나 그럼에도 불구하고 이 거대하고 복잡한 층이 나타났습니다. 그러나 우리는 그것으로부터 받은 혜택에 대한 대가로 이것을 참을 준비가 되어 있습니다.

그리고 여기서 또 다시 갈등이 발생합니다.

처음에 로컬 하드 드라이브에 모든 것을 저장하는 것은 좋지 않다고 말했습니다. 그리고 이제 나는 우리가 그것을 좋아했다고 말합니다.

예, 실제로 시간이 지남에 따라 상황이 많이 바뀌었고 이제 이 접근 방식에는 많은 이점이 있습니다. 첫째, 작업이 훨씬 간단해졌습니다.

둘째, 자동 컨트롤러나 디스크 쉘프에 대한 연결이 없기 때문에 생산성이 더 높습니다.

거기에는 엄청난 양의 기계가 있는데, 이것들은 여기 기계에 습격을 위해 조립되는 몇 개의 디스크에 불과합니다.

그러나 단점도 있습니다.

이는 오늘날의 가격으로도 SAN을 사용하는 것보다 약 1,5배 더 비쌉니다. 따라서 우리는 대형 클러스터 전체를 로컬 하드 드라이브가 있는 자동차로 과감하게 전환하지 않기로 결정하고 하이브리드 솔루션을 떠나기로 결정했습니다.

우리 기계의 절반은 하드 드라이브와 함께 작동합니다(음, 절반은 아니지만 아마도 30% 정도). 그리고 나머지는 XNUMX차 예약제를 시행하던 오래된 차량들이다. 새 데이터나 다른 것이 필요하지 않았기 때문에 간단히 다시 마운트하고 마운트를 하나의 물리적 호스트에서 두 개로 옮겼습니다.

그리고 이제 우리는 독서량을 많이 확보하고 확장했습니다. 이전에 하나의 머신에 하나의 스토리지를 마운트했다면 이제는 예를 들어 한 쌍에 XNUMX개를 마운트합니다. 그리고 그것은 잘 작동합니다.

우리가 성취한 것, 무엇을 위해 싸웠는지, 그리고 성공했는지 간략하게 요약해 보겠습니다.

결과

우리는 사용자가 33만 명에 달합니다.

우리는 프라하, 마이애미, 홍콩의 세 가지 지점을 가지고 있습니다.

여기에는 NGINX의 간단한 기계, access.log 및 Python 데몬이 실행되어 이 모든 것을 처리하고 캐시를 관리하는 빠른 로컬 디스크(SSD)가 있는 자동차로 구성된 캐싱 계층이 포함되어 있습니다.

원하는 경우 프로젝트에 참여하고 사진이 우리만큼 중요하지 않거나 개발 속도 및 리소스 비용에 대한 균형 제어가 반대 방향인 경우 안전하게 사진을 교체할 수 있습니다. CDN을 사용하면 최신 CDN이 잘 작동합니다.

다음은 서로 백업하는 머신 쌍의 클러스터가 있는 스토리지 계층으로, 파일이 변경될 때마다 파일이 서로 비동기식으로 복사됩니다.

또한 이러한 시스템 중 일부는 로컬 하드 드라이브에서 작동합니다.

이러한 시스템 중 일부는 SAN에 연결되어 있습니다.

그리고 한편으로는 사용하기가 더 편리하고 생산성도 좀 더 높아지는 반면, 배치 밀도와 기가바이트당 가격 측면에서 편리합니다.

이것은 우리가 얻은 아키텍처와 그것이 어떻게 개발되었는지에 대한 간략한 개요입니다.

선장의 팁이 몇 가지 더 있습니다. 매우 간단한 것입니다.

첫째, 사진 인프라의 모든 것을 긴급하게 개선해야 한다고 갑자기 결정한 경우 개선할 필요가 전혀 없기 때문에 먼저 측정하십시오.

예를 들어 보겠습니다. 우리는 채팅의 첨부 파일에서 사진을 보내는 기계 클러스터를 가지고 있으며 이 계획은 2009년부터 작동해 왔으며 아무도 이로 인해 고통을 받고 있지 않습니다. 모두가 괜찮고 모두가 모든 것을 좋아합니다.

측정하려면 먼저 여러 가지 측정 항목을 걸고 살펴보고 불만족스러운 점과 개선해야 할 점을 결정하십시오. 이를 측정하기 위해 Pinba라는 멋진 도구가 있습니다.

이를 통해 각 요청 및 응답 코드, 시간 분포에 대해 NGINX에서 원하는 대로 매우 상세한 통계를 수집할 수 있습니다. 여기에는 모든 종류의 다양한 분석 시스템에 대한 바인딩이 있으며 이를 모두 아름답게 볼 수 있습니다.

먼저 측정한 다음 개선했습니다.

더 나아가. 우리는 캐시로 읽기, 샤딩으로 쓰기를 최적화하지만 이는 분명한 점입니다.

더 나아가. 이제 막 시스템 구축을 시작했다면 사진을 변경할 수 없는 파일로 만드는 것이 훨씬 좋습니다. 캐시 무효화, 논리가 사진의 올바른 버전을 찾는 방법 등의 문제 전체가 즉시 손실되기 때문입니다.

XNUMX개를 업로드한 다음 회전시켜서 물리적으로 다른 파일이 되도록 만들었다고 가정해 보겠습니다. 저것들. 생각할 필요가 없습니다. 이제 약간의 공간을 절약하고 동일한 파일에 쓰고 버전을 변경하겠습니다. 이것은 항상 잘 작동하지 않으며 나중에 많은 두통을 유발합니다.

다음 포인트. 즉석에서 크기 조정 정보.

이전에는 사용자가 사진을 업로드하면 다양한 고객을 위해 모든 경우에 맞게 여러 크기를 즉시 잘라서 모두 디스크에 보관했습니다. 이제 우리는 이것을 버렸습니다.

우리는 소형, 중형, 대형의 세 가지 주요 크기만 남겼습니다. 우리는 Uport에서 우리에게 요청한 것보다 뒤에 있는 크기부터 다른 모든 것을 간단히 축소하고, 간단히 축소하여 사용자에게 제공합니다.

여기에서 캐싱 계층의 CPU는 각 저장소에서 이러한 크기를 지속적으로 재생성하는 것보다 훨씬 더 저렴한 것으로 나타났습니다. 새 것을 추가하고 싶다고 가정해 보겠습니다. 이 작업에는 한 달이 걸립니다. 클러스터를 파괴하지 않고 이 모든 작업을 깔끔하게 수행할 수 있는 스크립트를 어디서나 실행하세요. 저것들. 지금 선택할 수 있는 기회가 있다면 물리적 크기를 가능한 한 적게 만드는 것이 좋지만 최소한 일부 분포는 XNUMX이 되도록 하는 것이 좋습니다. 그리고 그 밖의 모든 것들은 기성 모듈을 사용하여 즉석에서 간단하게 크기를 조정할 수 있습니다. 이제 모든 것이 매우 쉽고 접근 가능해졌습니다.

그리고 증분 비동기 백업이 좋습니다.

우리의 실습에서 알 수 있듯이 이 구성표는 변경된 파일의 지연된 복사에 효과적입니다.

마지막 요점도 분명합니다. 지금은 인프라에 그런 문제가 없지만 깨질 수 있는 부분이 있다면, 조금 더 커지면 반드시 깨질 것입니다. 따라서 이에 대해 미리 생각하고 문제가 발생하지 않는 것이 좋습니다. 그것이 내가 말하고 싶은 전부입니다.

연락처

» bo0rsh201
» Badoo 블로그

이 보고서는 고부하 시스템 개발자 컨퍼런스에서 최고의 연설 중 하나를 녹취한 것입니다. HighLoad ++. HighLoad++ 2017 컨퍼런스까지 한 달도 채 남지 않았습니다.

우리는 이미 그것을 준비했습니다 컨퍼런스 프로그램, 현재 활발하게 일정이 형성되고 있습니다.

올해 우리는 아키텍처 및 확장 주제를 계속해서 탐구합니다.

• XNUMX억 명의 사용자에게 서비스를 제공하고 테라비트 규모의 트래픽을 제공하는 방법 /이고르 바실리예프
• VKontakte 개인 메시지 데이터베이스를 처음부터 다시 작성하고 가동 중지 시간 없이 마이그레이션하는 방법 / 드미트리 에고로프
• 판매에 의한 죽음: Yandex.Money가 블랙 프라이데이를 가속화하고 생존하기 위해 노력한 방법 / 아나톨리 플라스코프스키
• 은행 프런트엔드 시스템의 내결함성 아키텍처 / 로만 셰호프초프, 알렉세이 그로마치코프
• 결제 시스템 아키텍처: 거의 엔터프라이즈급 / 필립 델가도

우리는 또한 고부하 시스템 개발에 관한 온라인 교육 과정에서도 이러한 자료 중 일부를 사용합니다. HighLoad.가이드 특별히 선정된 편지, 기사, 자료, 비디오의 체인입니다. 우리 교과서에는 이미 30개 이상의 독특한 자료가 포함되어 있습니다. 연결하다!

출처 : habr.com