오늘날 디지털 최초의 세계에서 데이터에 대한 중단없는 액세스에 대한 기대는 더 이상 럭셔리한 것이 아니라 필수적입니다. 중요한 응용 프로그램을 구동하고, 글로벌 청중에게 멀티미디어 콘텐츠를 제공하거나, 개인 파일을 백업하든, 클라우드 스토리지의 신뢰성은 생산성에서부터 신뢰성까지 모든 것을 직접적으로 영향을 미칩니다. 대부분의 클라우드 공급 업체의 경우 신뢰성은 오프타임 비율(99.9%, 99.99%)에 의해 정량화됩니다. 그러나 이러한 폴리드 서비스 수준 계약 (SLAs) 뒤에는 격렬한 현실이 있습니다 : 진실. - 예기치 않은 지연이나 중단없이 언제든지, 어디서든 데이터에 액세스할 수있는 능력은 여전히 까다롭습니다. 심지어 가장 강력한 중앙화된 클라우드조차도 그들이 완화하려고하는 바로 그 일에 취약합니다. five nines continuous performance 신뢰성은 당신이 희망하는 것이 아니라 당신이 디자인하는 것입니다. 지역 전반의 중단에서부터 잘못 구성된 네트워크 경로에 이르기까지, 중앙 인프라가 얼마나 강화되었는지 상관없이 자체 구조적 제한을 피할 수 없다는 것을 우리는 여러 번 보았습니다.When all roads lead through a handful of data centers, a single misstep – a fire, a routing problem, an internal error – can have ripple effects across entire industries. 지역 전반의 중단에서부터 잘못 구성된 네트워크 경로에 이르기까지, 중앙 인프라가 얼마나 강화되었는지 상관없이 자체 구조적 제한을 피할 수 없다는 것을 우리는 여러 번 보았습니다.When all roads lead through a handful of data centers, a single misstep – a fire, a routing problem, an internal error – can have ripple effects across entire industries. 이 블로그는 왜 Sia의 분산 아키텍처가 이러한 제한을 극복하기 위해 고유한 위치에 있는지 탐구합니다. 다음 섹션에서 우리는이 디자인을 전통적인 저장 모델과 비교하고 실제 실패 시나리오를 분해하고 분산이 더 안전한 것이 아니라 더 신뢰할 수있는 방법을 보여줄 것입니다. Resilience를 통해 성능 왜냐하면 클라우드 스토리지의 미래에서 신뢰성은 당신이 희망하는 것이 아니라 당신이 설계하는 것입니다. 중앙화된 구름의 취약한 기초 전통적인 클라우드 스토리지 플랫폼은 환경 극단, 인간 오류 또는 내부 오류에 직면 할 때 중앙 인프라가 얼마나 취약할 수 있는지 반복적으로 증명해 왔습니다.AWS, Google Cloud 및 Microsoft Azure와 같은 하이퍼 스케일러가 주장하는 인출에도 불구하고 실제 사례 연구는 수백만 명의 사용자가 순간에 액세스를 잃을 수 있으며 전체 비즈니스는 단일 실패 지점으로 인해 중단됩니다. 아마도 클라우드 취약성의 가장 극적인 예는 데이터 센터 화재에서 발견 될 수 있습니다 - 즉시 클라우드 서비스의 전체 영역을 비활성화 할 수있는 사건입니다. 2022 년 8 월, Google의 Council Bluffs 데이터 센터에서 전기 폭발이 3 명의 근로자를 부상 시켰고 Search 및 Maps와 같은 핵심 서비스를 방해했습니다. 1년 후, 파리에서 Google Cloud의 유럽-서부9-A 영역에서 여러 클러스터의 실패가 물 침입으로 시작되었는데, 이는 배터리 룸을 홍수하고 화재를 일으킨 냉각 시스템의 실패로 인해 발생했습니다.이 격렬한 실패는 Google의 주요 유럽 클라우드 지역 중 하나를 제거했을뿐만 아니라 90개가 넘는 클라우드 서비스에 영향을 미쳤습니다. 이 사건들은 2021년 스트라스부르크에서 발생한 악명 높은 OVHcloud 화재로 SBG2 데이터 센터를 완전히 파괴하고 동일한 캠퍼스에 있는 다른 사람들을 부분적으로 손상시켰다. Many customers had no disaster recovery plans in place, and entire websites were lost without backups. 화재 외에도 열파는 예기치 않은 위협이지만 점점 커지는 것으로 입증되었습니다.2022년 7월 런던에서 40°C (104°F)를 초과하는 기록적인 온도가 Google과 Oracle 데이터 센터를 오프라인으로 밀어 넣어 냉각 시스템의 실패로 인해 Google은 하드웨어 손상을 방지하기 위해 클라우드의 일부를 적극적으로 닫아야했습니다. 그러나 모든 중단이 물리적 재앙으로 인해 발생하는 것은 아닙니다 – 일부는 디지털 재앙이 발생하기를 기다리고 있습니다. 2024년 2월, Google Cloud는 지역 메타데이터 스토어의 실패가 미국 서부1 지역을 거의 3시간 동안 오프라인으로 데려갔을 때 또 다른 중단을 겪었습니다. 이러한 실패는 클라우드 서비스 의존성의 위험한 통합을 노출시킵니다. Fastly와 같은 콘텐츠 전달 네트워크 (CDN)가 2021 년에 잘못 구성되었을 때, 그것은 Reddit, Spotify 및 주요 뉴스 매체에 영향을 미치는 글로벌 혼란을 일으켰습니다. 디자인을 통해 지속적인 성능 중앙형 클라우드 공급자가 실패를 방지하기 위해 점점 더 큰 요새를 구축하는 곳에서 Sia는 요새 모델을 완전히 거부함으로써 문제를 해결합니다.일부 지역이나 시설의 탄력성에 모든 것을 내기보다는 Sia는 수십 개의 독립적으로 운영되는 노드에 걸쳐 데이터를 전 세계적으로 배포하여 수학을 사용하여 신뢰성을 보장합니다. 배달할 수 있는 해고 해고는 종종 보안 조치로 간주됩니다 - 실패를 방지하는 방법입니다.하지만 Sia에서, 그것은 그 이상입니다. 기본적으로 Sia는 삭제 코딩을 사용하여 각 파일을 30개의 암호화된 셰어드로 분할합니다.이 셰어드 중 10개만이 파일을 완전히 재구성하는 데 필요합니다.이것은 네트워크가 단순한 중단뿐만 아니라 개별 호스트의 변동적인 성능을 견딜 수 있다는 것을 의미합니다. 해고는 실패가 아니라 지속적인 성과의 기초입니다. 대조적으로, 전통적인 클라우드는 몇 개의 지역에 걸쳐 전체 파일 복제에 의존합니다.If one region fails, access slows or stops – and extra storage doesn’t mean better speed. Sia의 모델은 실시간으로 적응합니다.Retrieval 경로는 호스트 가용성 및 네트워크 조건에 따라 역동적으로 변화합니다.No failovers, no bottlenecks, no downtime windows. 중앙화된 클라우드는 내부적으로 삭제 코딩을 사용할 수 있지만, 그들의 모든 인프라는 여전히 단일 공급자에 의해 운영됩니다. Sia의 호스트는 대조적으로 독립적으로 운영되며, 종종 다른 개인이나 비즈니스에 의해 운영됩니다.Sia를 사용하는 것은 기본적으로 30 개의 다른 클라우드에 데이터를 분할하는 것과 같습니다.아무 회사도 시스템을 제어하지 않으며, 단 하나의 실패도 시스템을 제거할 수 없습니다. 끊임없는 저항성 대부분의 클라우드 환경에서는 무언가가 깨질 때 성능이 손상됩니다.실패 시스템이 설치되어 있더라도 방해는 종종 속도가 떨어지거나 액세스가 방해되거나 인프라가 회복하기 위해 어려움을 겪는 동안 완전한 중단 시간을 초래합니다. Sia의 아키텍처는 다르게 작동합니다. 호스트가 데이터의 일부를 저장하는 경우 - 실패, 유지 보수 또는 불안정성으로 인해 - 파일이 완전히 액세스 할 수 있습니다.로드 스핀, 동기화 지연, 알림이 없습니다. 네트워크는 나머지 호스트에서 필요한 부품을 계속 검색하여 역동적으로 사용할 수있는 가장 빠른 옵션을 선택합니다. 한편, 백그라운드에서, 렌터 소프트웨어는 건강한 호스트에 새로운 격자를 업로드함으로써 완전한 무효성을 자율적으로 회복하기 시작합니다.이 자체 치유 프로세스는 미래의 실패로부터 보호 할뿐만 아니라 성능이 중단되지 않도록 보장합니다. Sia는 실패에서 회복 할뿐만 아니라 그것을 통해 작동합니다. 실패가 발생한 후에 실패에 반응하는 대신, Sia는 churn를 예상되는 행동으로 취급합니다 - 네트워크는 우아하게 대처하기 위해 구축되었습니다. 실패의 단일 지점은 없다 중앙화된 클라우드 플랫폼은 중앙화된 제어에 의존하기 때문에 캐스팅 실패에 취약합니다.A misconfigured router, a faulty software deployment, or a power problem in a single facility can ripple across regions – dragging down services that millions rely on. Sia의 아키텍처는 디자인에 의해 이러한 위험을 제거합니다.모스터 노드가 없습니다.중앙 영역이 없습니다. 시스템을 오프라인으로 무의식적으로 가져올 수있는 특권 권한이 없습니다.그 대신 데이터는 전 세계 수십 개의 독립적 인 호스트에 배포됩니다. 하나의 호스트가 실패하면 시스템이 계속 실행됩니다. 10 개의 호스트가 실패하면 여전히 실행됩니다. 시작할 단일 경로가 없기 때문에 "실패"할 필요가 없습니다. 영역 없음 마스터 노드 없음 bottleneck 없음 막을 수 없는 액세스 이 중앙 의존성의 부족은 단순히 결함 관용을 향상시키는 것이 아닙니다. 당신은 지역이 온라인으로 돌아오기를 기다리고 있지 않습니다.당신은 과부하 게이트웨이 또는 인간 관리자 복구 서비스에 의해 포장되지 않습니다.당신은 가장 빠른 곳에서 데이터를 끌고 있습니다. prevents performance blackouts 신뢰성을 위해 설계, 단지 그것을 희망하는 것이 아닙니다. 우리가 "클라우드 신뢰성"에 대해 이야기 할 때, 우리는 종종 약속을 판매합니다 - 재정적인 벌금, 화려한 가동 시간 비율 및 브랜드 명성에 의해 지원되는 SLA.하지만 우리가 보았듯이, 최대의 클라우드 공급 업체조차도 중앙화와 함께 오는 취약성을 피할 수 없습니다.화재, 열파 또는 소프트웨어 오류 단계, 전통적인 클라우드 모델은 항상 글로벌 혼란에서 멀리 떨어져 몇 번의 실패를합니다. Sia는 근본적으로 다른 접근 방식을 취합니다.Instead of assuming infrastructure will hold and preparing for disaster when it does not, Sia는 실패가 불가피하다고 가정합니다 - 그리고 어쨌든 계속 작동하는 시스템을 구축합니다. 특권 서버 없음, 지역 의존성 없음, 공급자 잠금 없음.자신을 수리하는 분산된 인프라만으로 데이터를 액세스할 수 있는 상태로 유지할 수 있습니다.No privileged servers, no regional dependencies, no vendor lock-in.Just self-repair, decentralized infrastructure that keeps your data accessible because no single actor has the power to make it inaccessible. 지속적인 성능 이것은 기술적 이점 이상입니다. 디지털 저항성에 대해 생각하는 방식의 변화입니다. 더 높은 벽과 더 깊은 벽을 구축하는 대신 Sia는 방어력을 분산시킵니다. 그것은 신뢰를 분산합니다.그리고 그렇게함으로써 안정적인 클라우드 스토리지가 더 이상 중단 시간이 허용되지 않는 세계에서 어떻게 보일 수 있는지 다시 정의합니다. 조직이 증가하는 중단, 증가하는 비용 및 엄격한 준수 요구 사항에 직면함에 따라 분산화는 실현 가능성이 높아졌습니다.If the future of the cloud is about building services that 심지어 상황이 잘못되더라도 신뢰를 중심으로 설계하는 것을 멈추고 확신을 중심으로 설계하기 시작할 때입니다. 단지 일 Sia에서는 지속적인 성능이 목표가 아니라 보장입니다. 출처 데이터 센터 지식. (2022, 8 월 9). 데이터 센터 화재 — 구글 ‘전기 사고’, 3 부상. 데이터 센터 지식. https://www.datacenterknowledge.com/hyperscalers/data-center-fire-google-suffers-electric-incident-3- 부상 Claburn, T. (2023, 4 월 26). Google 클라우드가 물 유출, 화재 중에 유럽에서 흐르고 있습니다. https://www.theregister.com/2023/04/26/google_cloud_outage/ 스베르드리크, Y. (2021, 3 월 9 일). 화재가 OVH의 스트라스부르크 데이터 센터 (SBG2)를 파괴했습니다. 데이터 센터 지식. https://www.datacenterknowledge.com/uptime/fire-has-destroyed-ovh-s-strasbourg-data center-sbg2 블룸버그 뉴스. (2022, 7 월 20). 구글, 오라클 데이터 센터는 런던 열에 의해 오프라인으로 타격. 데이터 센터 지식. https://www.datacenterknowledge.com/cooling/google-oracle-data-centers-knocked-offline-by-london-heat 2024년 12월 5일 (Millward, W. 2024년 12월 5일) 2024년 가장 큰 클라우드 중단 10가지. CRN. https://www.crn.com/news/cloud/2024/the-10-biggest-cloud-outages-of-2024 바레트, B. (2021, 6 월 8). 어두운 회사가 인터넷의 큰 조각을 어떻게 끌었는지. WIRED. https://www.wired.com/story/fastly-cdn-internet-outages-2021/

This story contains new, firsthand information uncovered by the writer.

이 오디오는 이야기의 원래 언어로 제작되었습니다!

Sia, 설계에 의한 지속적인 성능을 통해 클라우드 안정성을 재정의

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

HackerNoon 글쓰기 대회에서 우승하고 싶으신가요? #crypto-api 대회 우승자들이 추천하는 내용은 다음과 같습니다.

작업 흐름을 10배 향상하는 방법: 17가지 필수 앱

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

탭하여 수익 창출: 텔레그램에서 솔라나 이전에 100억 명의 암호화폐 사용자를 확보할 수 있음

HackerNoon 글쓰기 대회에서 우승하고 싶으신가요? #crypto-api 대회 우승자들이 추천하는 내용은 다음과 같습니다.

작업 흐름을 10배 향상하는 방법: 17가지 필수 앱

사용자 중심의 암호화 제품 만들기: 고객 피드백의 중요성

탭하여 수익 창출: 텔레그램에서 솔라나 이전에 100억 명의 암호화폐 사용자를 확보할 수 있음

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps