クラウドファイルストレージサービスを提供しているDropboxが、自社の災害対応能力を検証するために、同社の最も重要なデータセンターを完全にオフラインにするテストをどのように実施したかを紹介している。
同社は、2015年頃にAmazon Web Services（AWS）からコンピューティングインフラを全面的に自社インフラに移行した後、独自のストレージシステム「Magic Pocket」の運用を開始している。米国のサンアンドレアス断層からそう遠くない場所に位置するサンノゼデータセンター（SJC）で、「高度に集中化」した体制を実現した。
Dropboxは、サンノゼデータセンターの重要性の高さから、このリージョンや「メトロ」（リージョンをさらに分割したDropbox独自の管理単位）がダウンした場合に、同社のサービスのグローバルな可用性にどんな影響が及ぶかを確認したいと考えた。このため同社は、2021年11月に、SJCのデータセンターに接続されているファイバーネットワークの「プラグを物理的に抜く」ことによって、その耐障害性をテストすることにした。
このプロジェクトを実施したチームは、テストについて詳しく説明するブログ記事の中で、「世界的に自然災害が増えており、当社のデータセンターにそのような事態が起きたときの潜在的な影響について検討することが重要だ」と述べている。
同社が保管しているデータには、ファイルの内容そのものと、ファイルやユーザーのメタデータの2種類がある。Magic Pocketは、前者のコンテンツファイルをブロックに分割して、複数の異なるリージョンのインフラにレプリケート（複製）する。このシステムは、各データセンターが独立して同時にブロックデータを提供するように設計されており、いずれかのデータセンターがダウンするような事態でも事業への影響を最小限に抑えられる。いわゆる「アクティブ／アクティブ」なシステムだ。
Dropboxはもともと、メタデータのスタックにも、同様のアクティブ／アクティブなアーキテクチャーを採用することを検討していた。しかし当時、同社のメタデータのメインMySQLデータベースはSJCに置かれており、このデータベースのフェイルオーバー、アクティブ／パッシブな機能のテストは適切に行われていなかった。同社はSJCのデータベースが、別の場所にあるパッシブなデータセンターにレプリケートされたMySQLデータベースに、正常にフェイルオーバーされるかどうかをテストしたいと考えた。2015年に行われたフェイルオーバーのテストは成功だったが、その後、同社のエンジニアは、メタデータにアクティブ／アクティブなアーキテクチャーを採用することはブロックストレージの場合よりも困難であることに気づいた。
そのため同社は、メタデータにはアクティブ／パッシブなアーキテクチャーを採用するという判断を下し、その代わりに、2019年から頻繁にフェイルオーバーのテストを実施し始めた。
しかしその後、2020年5月にDropboxのフェイルオーバーツールに「重大な障害」が発生して、大規模な機能停止が起こり、47分間のダウンタイムが発生するという事態が起きた。同社は既存のフェイルオーバーのツールとプロセスに関する緊急監査を実施するとともに、新たに7人の専任スタッフからなる災害復旧チームを発足させた。同チームは、2021年末までに目標復旧時間（RTO）を大幅に短縮するという目標を掲げた。
ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)
からの記事と詳細 ( 災害時などの耐障害性を検証、Dropboxが「データセンターの接続を断つ」テストで得た成果 - ZDNet Japan )
https://ift.tt/s1SiZlf
No comments:
Post a Comment