今日のデジタルファーストワールドでは、データへの中断のないアクセスを期待することはもはや贅沢ではなく、必要不可欠です。重要なアプリケーションを駆動し、グローバルな視聴者にメディアコンテンツを提供するか、単に個人ファイルをバックアップするかに関わらず、クラウドストレージの信頼性は生産性から信頼性まですべてに直接影響します。 ほとんどのクラウドプロバイダーの場合、信頼性はオープンタイムの割合(99.9%、99.99%)で量子化されます。 しかし、これらのポリスされたサービスレベルの合意(SLAs)の背後には、厳しい現実があります:真実です。 予期せぬ遅延や中断なしに、いつでも、どこでもデータにアクセスする能力は未だに難しく、最も強力な集中型クラウドでさえ、それらが軽減しようとするもの、すなわち失敗に敏感です。 five nines continuous performance 信頼性はあなたが希望するものではなく、あなたが設計するものなのです。 地域規模の停滞からネットワークルートに至るまで、集中インフラがどれほど強化されても、その構造的な制限から逃れることができないことを何度も繰り返し見てきました。 地域規模の停滞からネットワークルートに至るまで、集中インフラがどれほど強化されても、その構造的な制限から逃れることができないことを何度も繰り返し見てきました。 このブログでは、Siaの分散型アーキテクチャがこれらの制限を克服するためにユニークなポジションを持つ理由を説明しています。 今後のセクションでは、このデザインを伝統的なストレージモデルと比較し、現実の失敗シナリオを分解し、分散がより安全であるだけでなく、より信頼性の高い方法を示します。 レジリエンスを通してのパフォーマンス なぜなら、クラウドストレージの将来、信頼性はあなたが希望するものではなく、あなたが設計するものだからです。 集中クラウドの脆弱な基礎 従来のクラウドストレージプラットフォームは、環境の極端、ヒューマンエラー、または内部ミスコンフィギュレーションに直面したときに、集中インフラがどれほど脆弱であるかを繰り返し証明しています。 もしかしたら、クラウドの脆弱性の最も劇的な例は、データセンターの火災で見つかるかもしれない――データセンターサービスの全エリアを即座に無効にすることができる出来事である。2022年8月、GoogleのCouncil Bluffsデータセンターで発生した電気爆発で、3人の従業員が負傷し、検索やマップなどのコアサービスが破壊された。 一年後、パリで、Google Cloudのヨーロッパ西部9区の複数のクラスターの故障は、水の侵入から始まったが、これはバッテリールームを洪水させ、火災を起こした冷却システムの故障によるものであり、Googleの主要なヨーロッパのクラウド地域の1つを奪われただけでなく、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のデータセンターをオフラインに打ち込んだ。 しかし、すべての中断が物理的な災害から生まれるわけではありませんが、いくつかはデジタル災害が起こるのを待っています。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. 1つの地域が失敗すると、アクセスが遅くなったり停止したり、追加のストレージがより良い速度を意味するわけではありません。 Siaのモデルはリアルタイムで適応します. Retrieval pathways shift dynamically based on host availability and network conditions — no failovers, no bottlenecks, no downtime windows. 回収パスは、ホストの可用性とネットワーク条件に基づいてダイナミックに変化します。 中央化されたクラウドは内部で削除コードを使用する場合もありますが、インフラストラクチャ全体はまだ1つのプロバイダーによって運営されています。 対照的に、Siaのホストは、しばしば異なる個人や企業によって独立して運営されています。Siaを使用することは、デフォルトで30の異なるクラウドにデータを分割するのと同じです。 無断の耐久性 ほとんどのクラウド環境では、何かが壊れると、パフォーマンスが損なわれます。 故障システムが存在する場合でも、故障はしばしば速度の低下、アクセス障害、またはインフラストラクチャが回復する際に完全に停止するにつながります。 Siaのアーキテクチャは異なります。 データの一部をストレージしているホストがオフラインに移行した場合 - 故障、メンテナンス、または不安定性のために - あなたのファイルは完全にアクセス可能なままです。 ロードスピナー、同期遅延、警告はありません。 ネットワークは残りのホストから必要なパーツを引き続き取得し、動的に利用可能な最速のオプションを選択します。 一方、バックグラウンドでは、レンタカーのソフトウェアは、健康なホストに新しいブレードをアップロードすることによって、完全な無償を自動的に回復し始めます。 Siaは失敗から回復するだけでなく、それを通じて機能します。 それが起こった後に失敗に反応するのではなく、Siaはチャーンを期待される行動として扱います - ネットワークは優雅に処理するように構築されています。 失敗の1つのポイント Centralized cloud platforms are vulnerable to cascading failure because they rely on centralized control. 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のアーキテクチャは、設計によってこのリスクを排除します。マスターノードはありません。中央リージョンはありません。システムを無意にオフラインに移すことができる特権機関はありません。代わりに、あなたのデータは世界中の数十の独立したホストに分散されます。 1 つのホストが失敗した場合、システムは動き続けます。10 つのホストが失敗した場合、それでも動き続けます。 エリアなし マスターノードなし ボトルネックなし アクセスが止まらない この中央依存の欠如は、欠陥容認を強化するだけでなく、 あなたは、地域がオンラインに戻ってくるのを待っているのではありません。あなたは、過剰なゲートウェイや人間の管理者からの復元サービスによってブロックされていません。 prevents performance blackouts 信頼性のために設計し、それを望むだけでなく、 私たちが「クラウドの信頼性」について話すとき、私たちはしばしば、金融罰金、輝かしいオープンタイムの割合、ブランドの評判に支えられたSLAを約束しますが、私たちが目にしたように、最大のクラウドプロバイダーでさえ、集中化に伴う脆弱性から逃れることができません。 Siaは根本的に異なるアプローチをとるが、インフラストラクチャが持続し、そうでないときに災害に備えると仮定する代わりに、Siaは失敗が避けられないと仮定し、とにかく機能し続けるシステムを構築する。 : 特権サーバーなし、地域依存性なし、ベンダーのロックインなし. 単に自己修復、分散型インフラストラクチャで、データをアクセスできるようにします。 継続パフォーマンス これは技術的な利点以上のものであり、デジタル・レジリエンスの考え方に変化をもたらします。より高い壁やより深いマウントを構築するのではなく、Siaは防御力を分散させます。 組織が停滞の増加、コストの上昇、および厳格なコンプライアンス要件に直面するにつれて、分散化は実現可能なものとなっています - それは優れたものです。 たとえ何かが間違っているとしても、信頼をめぐるデザインをやめ、確信をめぐるデザインを始める時が来た。 単なる仕事 Sia では、継続的なパフォーマンスは目標ではなく、保証です。 源泉 データセンター知識(2022年8月9日) データセンター火災 — Googleが「電気事故」に苦しみ、3人が負傷しました。データセンター知識. https://www.datacenterknowledge.com/hyperscalers/data-center-fire-google-suffers-electric-incident-3-injured Claburn, T. (2023, 4月26日). Google Cloudは、水漏れ、火災の真ん中にヨーロッパでスライスします。 https://www.theregister.com/2023/04/26/google_cloud_outage/ OVHのストラスブールデータセンター(SBG2)を火災で破壊した。データセンター知識. https://www.datacenterknowledge.com/uptime/fire-has-destroyed-ovh-s-strasbourg-datacenter-sbg2 ブルームバーグ・ニュース(2022年7月20日) Google、オラクル・データセンターがロンドン・ホットによってオフラインで叩かれたデータセンター知識 https://www.datacenterknowledge.com/cooling/google-oracle-data-centers-knocked-offline-by-london-heat 2024年12月5日 - 2024年12月5日 - 2024年12月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 - 2024年10月10日 バレット、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 コンテスト優勝者のおすすめはこちら

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

HackerNoon ライティングコンテストで優勝したいですか? #crypto-api コンテスト優勝者のおすすめはこちら

AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

18 種類の開発者ツールで生産性を向上しましょう 🚀🔥

ユーザー中心の暗号通貨製品の作成: 顧客からのフィードバックの重要性

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps