이중화가 없을 때 더 신뢰할 수 있는 경우 – 이중화의 신화

위험은 어려운 개념이며 주어진 시나리오를 제대로 평가하려면 많은 훈련, 사고 및 분석이 필요합니다. 종종 위험 평가가 너무 어렵기 때문에 우리는 위험 분석 대신 단순히 기본적인 이중화를 추가하고 위험을 적절히 완화했다고 가정합니다. 그러나 매우 자주 이것은 사실이 아닙니다. 복잡성의 도입이나 추가적인 장애 모드는 종종 이중화 추가와 함께 발생하며, 이러한 새로운 형태의 장애는 추가된 이중화가 제거하는 것보다 더 많은 위험을 추가할 가능성이 있습니다. 스토리지 시스템은 특히 이러한 의사결정 프로세스에 취약한데, 장애에 취약하고 보호가 중요한 시스템이 거의 없기 때문에 불행한 일입니다.

RAID는 전체론적 위험 사고의 부재가 어떻게 이상한 의사결정으로 이어질 수 있는지에 대한 좋은 예입니다. 드문하지 않은 시나리오를 살펴보면, 드라이브 장애를 방어하려는 목표가 추가적인 이중화가 적용될 때조차 실제로 위험 증가로 이어질 수 있는 곳을 볼 수 있습니다. 이 시나리오에서는 단일 어레이에 12개의 3테라바이트 SATA 하드 드라이브로 구성된 12드라이브 어레이를 비교할 것입니다. “최대 용량과 성능”을 갖추면서 “장애에 대한 적절한 보호”를 위해 이 시나리오에서 RAID 5를 선택하는 것을 들어본 적이 있는 것은 드문 일이 아닙니다.

여기서의 아이디어는 RAID 5가 단일 드라이브 손실에 대해 보호하며, 두 번째 드라이브가 장애를 일으키기 전에 교체하고 어레이가 재구성될 수 있다는 것입니다. 이것은 이론적으로는 훌륭하지만, 36테라바이트의 드라이브 용량을 가진 이 크기의 어레이의 실제 위험은 사람들이 일반적으로 의심하는 다중 드라이브 장애가 아니라 단일 드라이브 장애 후 어레이를 신뢰할 수 있게 재구성하지 못하거나 개별 드라이브 장애 없이 어레이 자체의 장애에서 비롯됩니다. 두 번째 드라이브 장애의 위험은 낮습니다. 없는 것은 아니지만 상당히 낮습니다. 오늘날 드라이브는 매우 신뢰할 수 있습니다. 하나의 드라이브가 장애를 일으키면 두 번째 드라이브가 장애를 일으킬 가능성이 높아지는데, 이는 잘 문서화되어 있습니다. 그러나 이 위험이 우리를 진정한 위험, 즉 실패한 리실버링 작업의 위험에서 멀어지게 하지 않기를 바랍니다.

RAID 5 리실버 작업 중에 우리를 두렵게 하는 것은 복구 불가능한 읽기 오류(URE)가 발생할 수 있다는 것입니다. 그럴 경우 리실버 작업이 중단되고 어레이는 쓸모없는 상태로 남게 되며, 어레이의 모든 데이터가 손실됩니다. 일반 SATA 드라이브에서 URE 비율은 10^14, 즉 12테라바이트의 읽기 작업마다 한 번입니다. 이는 리실버링 중인 6테라바이트 어레이가 URE에 도달하여 실패할 확률이 약 50%라는 것을 의미합니다. 50% 실패 확률은 엄청나게 높습니다. 차를 운전할 때마다 바퀴가 떨어질 확률이 50%라고 상상해보세요. 따라서 10^14 URE SATA 드라이브를 사용하는 소형(오늘날 기준) 6테라바이트 RAID 5 어레이로 단일 드라이브를 잃는다면, 드라이브를 즉시 교체한다고 가정했을 때 어레이가 복구될 확률은 50%에 불과합니다. 이것은 두 번째 드라이브 장애의 위험을 포함하지 않고, URE 장애의 위험만을 포함합니다. 또한 드라이브가 리실버 작업 외에 완전히 유휴 상태라고 가정합니다. 드라이브가 동시에 다른 작업에 바쁘게 사용된다면 URE나 두 번째 드라이브 장애와 같은 나쁜 일이 발생할 가능성이 극적으로 증가하기 시작합니다.

12테라바이트 어레이에서 리실버 작업 중 완전한 데이터 손실 가능성은 100%에 가까워지기 시작합니다. 즉, RAID 5는 해당 경우에 전혀 기능이 없다는 것을 의미합니다. 생존 가능성은 항상 있지만 매우 낮습니다. 6테라바이트에서는 리실버 작업을 한 발의 탄환이 있고 여섯 개의 방이 있는 러시아 룰렛 게임에 비교할 수 있으며 세 번 방아쇠를 당겨야 합니다. 12테라바이트에서는 여섯 번 당겨야 합니다! 이것은 좋은 확률이 아닙니다.

하지만 우리는 12테라바이트 어레이에 대해 이야기하는 것이 아닙니다. 우리는 36테라바이트 어레이에 대해 이야기하고 있습니다. 이것은 크게 들리지만, 오늘날 가정에서도 쉽게 가질 수 있는 크기이며, 비즈니스는 더욱 그렇습니다. 오늘날 모든 주요 서버 제조업체와 거의 모든 저비용 스토리지 벤더들이 이 용량 범위에서 1만 달러 미만의 스토리지 시스템을 만들고 있습니다. 36테라바이트 어레이에서 단일 드라이브 장애로 RAID 5 어레이를 리실버링하는 것은 러시아 룰렛, 탄환 하나, 여섯 개의 방에서 방아쇠를 18번 당기는 것과 같습니다! 데이터가 살아남을 가능성이 많지 않습니다. 이 크기의 어레이를 리실버하는 데 필요한 엄청난 시간을 더하면, 리실버 기간 동안 두 번째 디스크 장애의 위험이 상당한 위협이 되기 시작합니다. 일부 시스템에서는 리실버 시간이 몇 주 또는 몇 달에 달하는 추정치를 본 적이 있습니다. 다른 드라이브를 잃을 수 없는 상태로 오래 실행하는 것입니다. 몇 시간 또는 며칠을 이야기할 때 위험은 상당히 낮지만 여전히 존재합니다. 리실버 작업이 극도로 드라이브 집약적이기 때문에 몇 주 또는 몇 달의 지속적인 사용을 이야기할 때 장애율이 극적으로 증가합니다.

이 크기의 어레이에서는 단일 드라이브 손실이 전체 어레이 손실을 의미한다고 효과적으로 가정할 수 있으며, 이는 드라이브 장애 보호가 전혀 없다는 것을 의미합니다. 이제 RAID 0으로 동일하거나 더 나은 성능과 동일하거나 더 나은 용량의 드라이브를 보면, RAID 5 어레이에 12개가 필요한 동일한 드라이브 중 11개만 사용하면 됩니다. 이것이 의미하는 바는 연간 장애 확률이 약 3%인 12개의 하드 드라이브 대신 11개만 갖게 된다는 것입니다. 그것만으로도 장애를 일으킬 드라이브가 적어지기 때문에 RAID 0 어레이가 더 신뢰할 수 있게 됩니다. 드라이브가 적을 뿐만 아니라 동일한 사용률에 대해 RAID 0 어레이의 기계적 마모를 극히 약간 줄이는 패리티 블록을 쓰거나 읽을 때 패리티 블록을 건너뛸 필요가 없어 아주 약간의 추가 신뢰성 이점을 제공합니다. 11드라이브 RAID 0 어레이는 12드라이브 RAID 5 어레이와 용량이 동일하지만 처리량과 지연 시간이 약간 더 좋을 것입니다. 모든 면에서 승리입니다. 게다가 추가 드라이브가 필요 없어 비용도 절감됩니다.

따라서 여기서 우리는 (스핀들 수가 아닌 용량이) 큰 어레이에서 RAID 0이 특정 시나리오에서 실제로 RAID 5를 능가한다는 것을 알 수 있습니다. 일반 SATA 드라이브를 사용할 때 이것은 파워 유저들도 가정에서, 그리고 많은 소규모 비즈니스에서 경험하는 용량에서 발생합니다. 엔터프라이즈 SATA 드라이브나 SAS 드라이브로 이동하면 이것이 발생하는 용량 수치가 매우 높아지며 오늘날에는 문제가 되지 않지만 드라이브 용량이 더욱 커지는 몇 년 안에는 문제가 될 것입니다. 하지만 이것은 오늘날 우리가 보는 크기에서 RAID 5가 얼마나 위험한지를 강조합니다. 모든 사람이 RAID 0의 믿을 수 없는 위험을 이해하지만, RAID 5의 문제가 너무 극단적이어서 실제로 RAID 0보다 덜 신뢰할 수 있을 수 있다는 것을 관점에 두기가 어려울 수 있습니다.

리실버 작업만을 기준으로 이 크기의 어레이에서 RAID 5가 RAID 0보다 덜 신뢰할 수 있을 수 있다는 것은 시작에 불과합니다. 이 크기의 대형 어레이에서 리실버 시간은 너무 오래 걸리고 드라이브에 너무 많은 부담을 줄 수 있어 두 번째 드라이브 장애가 측정 가능한 위험이 되기 시작합니다. 그리고 드라이브 장애 없이 전체 어레이를 파괴하기 위해 리실버 알고리즘을 활용할 수 있는 어레이 컨트롤러 오류로 인한 추가 위험도 있습니다. RAID 0(또는 RAID 1 또는 RAID 10)은 리실버 알고리즘을 사용하지 않으므로 이 추가 위험을 겪지 않습니다. 이러한 위험은 수량화하기 어렵지만 중요한 것은 더 간단한 시스템이 처음부터 더 신뢰할 수 있을 때 더 복잡한 시스템을 사용할 때 누적되는 추가 위험이라는 것입니다.

RAID 5가 RAID 0보다 덜 신뢰할 수 있다는 것을 확인했으니, RAID 0의 명백한 위험에 대해 지적하겠습니다. RAID는 일반적으로 단일 하드 드라이브 장애의 위험을 완화하는 데 사용됩니다. 우리 모두는 단일 드라이브가 단순히 실패하고 모든 데이터가 손실될 것을 두려워합니다. RAID 0은 어떠한 형태의 이중화도 없는 드라이브의 대형 스트라이프로서, 단일 드라이브 장애 시 데이터 손실의 위험을 여러 드라이브에 걸쳐 배가시켜 어느 드라이브가 장애를 일으켜도 모든 드라이브의 모든 데이터가 손실됩니다. 따라서 위의 11디스크 예시에서 11개의 디스크 중 어느 하나라도 장애를 일으키면 모든 것이 손실됩니다. 이것이 단순히 단일 드라이브를 단독으로 사용하는 것보다 훨씬 더 위험하다는 것은 명확하게 알 수 있습니다.

여기서 제가 지적하려는 것은 이중화가 신뢰성을 의미하지 않는다는 것입니다. RAID 5처럼 무언가가 이중화되었다고 해서 단순히 이중화되지 않은 것보다 항상 더 신뢰할 수 있다는 보장은 없습니다.

제가 좋아하는 비유는 토네이도에서의 집을 보는 것입니다. 한 시나리오에서는 벽돌과 모르타르로 집을 짓습니다. 두 번째 시나리오에서는 두 개의 이중화된 집을, 각각 짚으로 짓습니다(건축가들이 돼지인 것 같습니다). 토네이도(또는 큰 나쁜 늑대)가 왔을 때 어느 쪽이 남은 집을 남길 가능성이 더 높을까요? 분명히 하나의 벽돌 및 모르타르 집이 이중화된 짚 집에 비해 몇 가지 중요한 신뢰성 이점을 가지고 있습니다. 이중화는 중요하지 않았고, 신뢰성이 결국 중요했습니다.

이중화는 종종 수량화하기 쉽지만 자격화하기 어렵기 때문에 오해를 불러일으킵니다. 이중화는 흑백 질문입니다: 이중화되어 있습니까? 예 또는 아니오. 간단합니다. 신뢰성은 그렇게 간단하지 않습니다. 신뢰성은 장애율과 가능성에 관한 것입니다. 통계와 분석에 관한 것입니다. 비즈니스 담당자에게 프로젝트를 판매할 때 신뢰성을 의미 있는 방식으로 수량화하기 어렵기 때문에 이중화는 종종 이 복잡한 개념의 간단한 대체물이 됩니다.

이중화를 사용하여 신뢰성 질문을 전환하는 개념은 매우 복잡한 방식으로 하위 시스템에도 적용됩니다. “시스템”을 이중화하는 대신 신뢰성이 높고 저비용인 하위 시스템을 이중화하고 하위 시스템 이중화를 전체 시스템에 적용되는 것처럼 처리하는 것이 일반적이 되었습니다. 가장 일반적인 예는 SAN 제품의 RAID 컨트롤러입니다. 이중화된 SAN(두 개의 SAN을 의미)을 갖는 대신 제조업체는 종종 일반 서버에서 자주 이중화되지 않는 하나의 구성 요소를 이중화하고 SAN을 이중화라고 부릅니다. 이는 이중화를 포함하는 SAN으로, 동일한 것이 전혀 아닙니다.

좋은 비유는 두 대의 완전한 작동 차량을 의미하는 이중화된 자동차와 메인 워터 펌프가 고장날 경우를 대비해 트렁크에 예비 워터 펌프가 있는 단일 자동차를 비교하는 것입니다. 분명히 예비 워터 펌프는 나쁜 것이 아닙니다. 그러나 두 번째 완전한 차가 준비되어 있는 것에 비하면 차량 장애에 대한 보호 수준이 미미합니다. 한 경우에는 섀시를 포함한 전체 시스템이 이중화됩니다. 다른 경우에는 섀시 내의 하나의 신뢰성 높은 구성 요소만을 이중화합니다. 그것은 최소한 장애 가능성이 더 높은 자동차 부품인 예비 타이어를 갖는 것과도 비교가 되지 않습니다.

RAID 5 신뢰성과 시스템/하위 시스템 신뢰성의 신화와 마찬가지로, SAN과 NAS와 같은 공유 스토리지 기술은 특히 가상화와 관련하여 동일한 방식으로 처리되는 경우가 많습니다. 가상화 프로젝트가 시작되고 사람들이 본능적으로 패닉 상태에 빠지는 일반적인 시나리오가 있는데, 단일 가상화 호스트가 단일 장애 지점을 나타내어 장애가 발생하면 많은 시스템이 동시에 실패할 수 있기 때문입니다.

“단일 장애 지점”이라는 용어를 사용하면 패닉 상태를 유발하고 대화를 조종하는 훌륭한 수단이 됩니다. 하지만 우리가 SPOF라고 부르는 것은 가능하면 제거하고 싶은 것이지만 세상의 끝은 아닐 수 있습니다. 우리의 벽돌 집을 생각해보세요. 그것은 SPOF입니다. 두 개의 짚 집은 그렇지 않습니다. 그러나 단순한 미풍이 우리의 신뢰할 수 있는 SPOF보다 이중화된 솔루션을 더 빨리 날려버립니다. SPOF를 찾는 것은 시스템에서 취약점을 찾는 좋은 방법이지만, 모든 SPOF가 모든 시나리오에서 이중화되어야 한다고 느끼지 마세요. 대부분의 비즈니스는 많은 SPOF를 사용하는 것에서 최고의 가치를 찾습니다. 우리의 진정한 목표는 적절한 비용으로 신뢰성을 달성하는 것이고, 이중화는 신뢰성의 대체물이 아니라 신뢰성을 달성하기 위해 사용할 수 있는 도구입니다.

가상화 시에 많은 사람들이 따르는 이론은 가상화 호스트를 “이 호스트는 SPOF이므로 두 개가 필요하며 투명한 장애 조치를 허용하는 고가용성 기능을 사용해야 한다!”라고 말하는 것입니다. 이것은 선도적인 가상화 벤더가 주로 비싼 HA 애드온 제품을 판매하여 돈을 벌고, 두 번째로 대형 스토리지 벤더에 의해 소유되어 있기 때문에 자극됩니다. 따라서 불필요하거나 심지어 위험한 추가 공유 스토리지를 판매하는 것이 큰 금전적 이익이며 처음부터 가상화 공간을 챔피언으로 이끈 이유가 될 수 있습니다. 이중화된 가상화 호스트와 공유 스토리지는 좋게 들리지만 몇 가지 이유로 매우 잘못 유도될 수 있습니다.

첫 번째 이유는 초기 SPOF인 가상화 호스트를 제거하면 새로운 SPOF인 공유 스토리지로 대체된다는 것입니다. 이것은 아무것도 달성하지 못합니다. 비교 가능한 품질의 서버와 공유 스토리지를 사용하고 있다고 가정하면, 우리가 한 것은 위험의 위치를 이동시킨 것이지 위험의 크기를 변경한 것이 아닙니다. 스토리지 시스템이 장애를 일으킬 가능성은 원래 서버가 장애를 일으킬 가능성과 대략 동일합니다. 그러나 셸 게임처럼 SPOF를 이리저리 섞는 것 외에도 훨씬, 훨씬 더 나쁜 일을 했습니다. 연쇄 또는 단계적 장애 의존성을 도입했습니다.

원래 시나리오에서는 단일 서버가 있었습니다. 서버가 작동하면 좋고, 실패하면 그렇지 않습니다. 간단합니다. 이제 두 개의 가상화 호스트, 단일 스토리지 서버(SAN, NAS, 무엇이든)와 이를 연결하는 네트워크가 있습니다. 공유 스토리지가 장애를 일으킬 위험이 원래 시나리오의 전체 시스템 위험과 대략 동일하다는 것을 이미 결정했습니다. 그러나 이제 네트워크와 두 개의 프론트엔드 가상화 노드의 추가 의존성이 있습니다. 이러한 구성 요소 각각은 취약한 공유 스토리지(기계적 드라이브가 있는 모든 것이 취약할 것입니다)보다 더 신뢰할 수 있지만, 이들이 위험이 낮다는 것은 문제가 아니며, 문제는 위험이 조합적이라는 것입니다.

이 세 가지 구성 요소(스토리지, 네트워크 또는 프론트엔드 노드) 중 어느 하나가 장애를 일으키면 모든 것이 실패합니다. 이에 대한 해결책은 공유 스토리지 자체를 이중화하고 네트워크 자체를 이중화하는 것입니다. 충분한 작업으로 우리는 공유 스토리지를 추가하여 도입한 취약성과 위험을 극복할 수 있지만, 공유 스토리지 자체는 위험 완화의 형태가 아니라 완화되어야 하는 위험 자체입니다. 복잡성의 나선이 시작되고 이 새로운 시스템을 원래 단일 서버 시스템의 신뢰성과 동등한 수준으로 끌어올리는 데 관련된 비용은 천문학적일 수 있습니다.

이 모든 이중화가 갖추어지면 걱정해야 할 또 다른 위험이 하나 더 있습니다. 이 모든 이중화, 이 모든 움직이는 부품을 관리하려면 간단한 단일 서버를 관리하는 것보다 훨씬 많은 지식, 기술 및 준비가 필요합니다. 우리는 간단한 솔루션에서 매우 복잡한 솔루션으로 이동했습니다. 개인적인 경험에서 이러한 솔루션의 실제 위험은 하드웨어 장애가 아닌 인적 오류에서 비롯됩니다. 인적 오류가 이 새로운 시스템의 장애를 초래하는 것을 방지하기 위해 거의 아무것도 하지 않았을 뿐만 아니라, 사람이 실수로 이중화를 포함한 전체 시스템을 다운시킬 수 있는 무수한 지점을 추가했습니다. 직접 목격했고 공포 스토리를 들었습니다. 시스템이 복잡할수록 사람이 실수로 모든 것을 망칠 가능성이 높아집니다.

IT 전문가로서 한발 물러서서 완전한 시스템을 살펴보고 신뢰성과 위험을 고려하며 이중화를 신뢰성 추구에서 사용하는 도구로만 생각하는 것이 매우 중요합니다. 이중화 자체는 만병통치약이 아닙니다. 단순성도 마찬가지입니다. 신뢰성은 해결하기 복잡한 문제입니다. 단순한 대체를 피하는 것이 신뢰성 문제를 가리는 것에서 직면하고 해결하는 것으로 나아가는 중요한 첫 번째 단계입니다.