대규모 클러스터의 데이터 손실에 대해

일반적으로 사용되는 세 가지 복제 루틴이 있습니다. 데이터베이스는 각 데이터가 세 대의 서로 다른 컴퓨터에 있는 세 개의 독립 디스크에 복사되도록 합니다. 그 이유는 간단합니다. 디스크는 특정 순간에만 작동하지 않습니다. 하나의 디스크가 죽으면 교체할 시간이 있고 나머지 두 복사본 중 하나를 가져와서 데이터를 복원하고 새 디스크에 쓸 수 있습니다. . 복원하기 전에 두 번째 디스크가 죽을 확률은 너무 낮아서 두 디스크가 동시에 죽을 확률은 소행성이 지구에 충돌하는 것만큼 희박합니다.

또한 디스크 1개가 고장날 가능성은 거의 0.1%(어쩌면 대략), 디스크 2개가 고장날 가능성은 거의 10의 6제곱, 디스크 3개가 동시에 고장날 확률은 거의 0.1%라고 특별히 계산했습니다. 10의 -9승은 약 10억분의 1입니다. 이 계산은 한 디스크의 오류가 다른 디스크의 오류와 무관하다는 것을 보여줍니다. 이는 그다지 정확하지 않습니다. 예를 들어 디스크가 모두 동일한 생산 라인에서 생산된 경우 디스크가 모두 불량할 수 있습니다. 하지만 이 정도면 충분합니다. 우리의 아이디어를 위해.

지금까지는 이것이 타당해 보이지만 안타깝게도 많은 데이터 저장 시스템에서는 그렇지 않습니다. 이 블로그에서는 그 이유를 알려드리겠습니다.

데이터 손실이 너무 쉽습니다

데이터베이스 클러스터에 3개의 머신만 포함되어 있는 경우 모든 머신이 동시에 충돌할 가능성은 너무 낮습니다(데이터 센터 파괴와 같은 관련 오류 제외). 그러나 더 큰 클러스터를 사용하면 그에 따라 문제가 달라집니다. 클러스터에서 사용하는 노드와 디스크가 많을수록 데이터가 손실될 가능성이 높아집니다.

이것은 계산에 따른 것입니다. "정말? 데이터를 디스크 3개에 복사했습니다. 어떻게 클러스터가 늘어날수록 실패 확률이 높아질 수 있습니까? 클러스터 용량은 어떻습니까?"라고 생각할 수도 있습니다. 그러나 가능성을 계산하여 보여줍니다. 다음 아이콘을 사용하여 이유를 설명하세요:

분명히 하나의 노드에 장애가 발생할 가능성은 없습니다. 세 개의 데이터 복사본이 모두 영구적으로 손실될 가능성이 있으므로 백업에서 데이터를 복원하는 것은 보수적인 접근 방식일 뿐입니다. 클러스터가 클수록 데이터가 손실될 가능성이 높아집니다. 이는 데이터 복제 비용을 지불하는 것에 대해 생각할 때 생각하지 못할 수도 있는 사항입니다.

그래프의 Y축은 다소 임의적이며 많은 상상력에 의존하지만 선의 방향은 놀랍습니다. 이전 가정에 따르면 어느 시점에서 노드가 실패할 확률은 0.1%입니다. 그러나 그림에 따르면 8,000개의 노드가 있는 클러스터에서 데이터 복사본 3개가 영구적으로 손실될 확률은 약 0.2%입니다. 예, 맞습니다. 세 개의 복사본을 모두 잃을 위험은 한 노드의 데이터를 잃을 위험의 두 배입니다. 그렇다면 이 사본은 무엇에 사용됩니까?

이 사진을 보면 직관적으로 판단할 수 있습니다. 8,000개의 노드가 있는 클러스터에서는 특정 시간에 일부 노드가 다운되는 것이 일반적입니다. 이는 문제가 되지 않을 수 있습니다. 혼란과 노드 교체의 특정 확률이 유추될 수 있으며, 그 중 일부는 일상적인 유지 관리입니다. 그러나 운이 좋지 않아 복사한 노드 데이터의 대상 노드가 다운된 경우에는 데이터를 결코 검색할 수 없습니다. 데이터 손실은 클러스터의 전체 데이터 세트에서 상대적으로 작은 부분이지만, 세 개의 복제본을 손실했을 때 "이 데이터를 정말로 잃고 싶지 않다"고 생각할 수도 있습니다. 실수로 일부 데이터가 손실되었습니다. 비록 크기는 크지 않지만 "누락된 데이터 중 이 부분이 데이터의 중요한 부분일 수도 있습니다.

세 개의 복제본이 모두 불량 노드일 가능성은 시스템에서 사용하는 복제 알고리즘에 따라 다릅니다. 위 다이어그램은 특정 수의 파티션(또는 샤드)으로 분할되는 데이터에 의존하므로 각 파티션은 무작위로 선택된 3개의 노드(또는 의사 무작위 해시 함수)를 저장합니다. 이것은 Cassandra와 Riak에서 사용되는 일관된 해싱의 특별한 경우입니다(내가 아는 한). 다른 시스템에서는 복제 작업을 어떻게 분배하는지 잘 모르기 때문에 멀티 스토리지 시스템의 내부를 잘 아는 사람에게서 보고 있습니다.

데이터 손실 확률 계산

복제된 데이터베이스의 확률 모델을 사용하여 위 그래프를 어떻게 계산했는지 보여드리겠습니다.

독립 노드가 데이터를 잃을 확률은 p=P(노드 손실)이라고 가정합니다. 이 모델에서는 시간을 무시하고 특정 기간 동안의 실패 확률을 간략하게 살펴보겠습니다. 예를 들어, p=0.001은 특정 날짜에 노드가 실패할 확률이라고 가정할 수 있습니다. 노드를 교체하고 손실된 데이터를 새 노드에 덤프하는 데 하루를 보내는 것이 합리적입니다. 간단히 말해서, 노드 장애와 디스크 장애를 구분하고 싶지는 않습니다. 영구 장애에 대해서만 이야기하겠습니다.

n을 클러스터의 노드 수로 설정합니다. f는 실패한 노드의 수(오류가 상대적으로 독립적이라고 가정)이고 이항 분포입니다.

표현식은 f 노드가 실패할 확률입니다. n-f 노드가 실패하지 않도록 보장하는 확률입니다. 이는 n에서 다양한 방식으로 추출된 f 노드의 수입니다. "n choose f"로 발음되며 다음과 같이 정의됩니다.

. . . . . .

여기서는 구체적인 파생 과정을 자세히 설명하지 않습니다. 위의 공식을 기반으로 n개의 노드와 복제 인자(복제된 백업 노드 수)가 있는 클러스터에서 하나 이상의 파티션이 손실될 확률을 도출할 수 있습니다. 실패한 노드 수 f가 복제 인자보다 작으면 데이터가 손실되지 않았음을 확신할 수 있습니다. 하지만 f가 r과 n 사이에 있을 때는 모든 가능성을 추가해야 합니다.

조금 장황하지만 정확하다고 생각합니다. r=3, p=0.001, k=256n, n이 3에서 10000 사이라고 하면 위의 그림을 얻을 수 있습니다. 나는 이 계산을 구현하기 위해 몇 가지 Ruby 프로그램을 작성했습니다.

더 간단한 추측을 위해 공용체 바인딩을 사용합니다.

한 파티션의 오류가 다른 파티션과 완전히 독립적이지는 않지만 이 추측은 여전히 ​​적용됩니다. 실험 결과에 더 가까운 것 같습니다. 도중에 데이터 손실 확률은 노드 수에 비례하는 직선과 비슷합니다. 추측에 따르면 확률은 숫자와 양의 관계가 있으며 각 노드에는 고정된 256개의 파티션이 있다고 가정합니다.

실제로. . .

실제로 어떻게 작동할지 잘 모르겠습니다. 하지만 저는 이것이 계산적으로 민감한 흥미로운 현상이라고 생각합니다. 대규모 데이터베이스 클러스터를 보유한 회사에서 실제 데이터 손실이 발생한 상황에 대해 들었습니다. 하지만 기사나 보고서에서는 흔하지 않습니다. 현재 이 주제를 연구하고 있다면 나에게 말해 줄 수 있습니다.

계산 결과에 따르면 데이터 손실 가능성을 줄이려면 파티션 수를 줄이고 복제 인자를 높여야 합니다. 더 많은 백업을 사용하면 비용이 더 많이 들기 때문에 대규모 클러스터를 고려할 때 이미 비용이 많이 듭니다. 그러나 파티션 수는 의미 있는 로드 밸런싱 프로세스를 나타냅니다. Cassandra는 원래 노드당 하나의 파티션을 가지고 있었지만 나중에 더 나은 로드 분산과 효율적인 보조 밸런싱에 대처하기 위해 노드당 256개의 파티션이 되었습니다.

실제로 작동하려면 합리적으로 큰 클러스터를 찾아야 하지만, 많은 대기업에서는 수천 수준의 클러스터를 사용합니다. 그래서 저는 이 분야에 실무 경험이 있는 사람들의 의견을 듣고 싶습니다. 10,000개 노드의 영구 데이터 손실 확률을 매일 0.25% 이내로 통제한다면 1년 안에 데이터의 60%가 손실된다는 뜻이다.

분산 데이터 시스템 설계자로서 이 글을 읽고 어떤 생각이 드시나요? 내 말이 옳다면 복제 체계를 설계할 때 더 많은 고려 사항을 고려해야 합니다. 이 글이 여러분의 현실 인식을 높이는 데 도움이 되기를 바랍니다. 왜냐하면 3개의 복제 노드는 실제로 그렇게 안전하지 않기 때문입니다.

위 내용은 대규모 클러스터의 데이터 손실에 대해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!