Cloud Storage がイレブンナインの耐久性を実現する仕組みと、その効果を高める方法

※この投稿は米国時間 2021 年 1 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

ストレージ ソリューションの最も基本的な側面の 1 つは耐久性です。つまり、データが損失や破損からどれだけ保護されているかが重要です。そして、それはクラウド環境にとって特に重要であると考えられます。Cloud Storage は、「イレブンナイン」、つまり少なくとも 99.999999999% の年間耐久性を実現するよう設計されています。これは、10 億個ものオブジェクトがあっても、100 年間で 1 つも失わないであろうことを意味しています。

Google は、耐久性の目標達成を非常に重視しています。本稿では、Cloud Storage データを保護するおすすめの方法について説明します。同時に、データ保護は最終的に共有責任でもあるため（データ損失の最も一般的な原因は、ユーザーまたはストレージ管理者による偶発的な削除によるものです）、自然災害やユーザーエラーなどのリスクからデータを保護するためのベスト プラクティスを提供します。

物理的耐久性

多くの人は、耐久性をネットワーク、サーバー、ストレージ ハードウェアの障害の観点から考えています。

Google では、ハードウェア障害から保護するうえで究極的に最良な方法はソフトウェアであるという考えを基本としています。この考えにより、特殊なハードウェア ソリューションに依存する代わりに、低コストでより優れた信頼性を実現できるようになりました。ハードウェアには常に障害が伴うと言っても過言ではありません。しかし、それは耐久性が犠牲になるのは仕方ないという意味ではありません。

Cloud Storage にオブジェクトを保存するには、オブジェクトをいくつかの「データチャンク」に分割し、それをさまざまな電源を備えた異なるサーバーに配置します。また、冗長性のためにいくつかの「コードチャンク」も作成します。ハードウェア障害（サーバー、ディスクなど）が発生した場合、データチャンクとコードチャンクを使用してオブジェクト全体を再構築します。この手法は、消失訂正符号と呼ばれています。さらに、オブジェクトの検索と読み取りに必要なメタデータのコピーをいくつか保存しているため、1 つ以上のメタデータ サーバーに障害が発生した場合でも、引き続きオブジェクトにアクセスできます。

ここでの主な要件は、書き込みが完了したと認識される前に、常に複数のアベイラビリティ ゾーンにわたりデータを冗長的に保存することです。Google が使用するエンコードは、ハードウェア障害に対してイレブンナインを超える耐久性目標をサポートするのに十分な冗長性を提供します。保存されると、チェックサムを定期的に検証して、特定の種類のデータエラーから保存データを保護します。チェックサムの不一致が発生した場合、データはエンコードに存在する冗長性を使用して自動的に修復されます。

ベスト プラクティス: デュアル リージョンまたはマルチリージョン ロケーションの使用

物理的耐久性のリスクに対してこれらの保護レイヤーは十分に機能しますが、戦争、小惑星の衝突などの大規模な災害といったリージョンの物理的破壊から保護できない可能性があります。

Cloud Storage のイレブンナインの耐久性目標は、単一のリージョンに適用されます。さらにリージョン全体を壊滅させる可能性のある自然災害から保護するには、最も重要なデータをデュアル リージョンまたはマルチリージョンのバケットに保存することを検討してください。これらのバケットは、地理的リージョンにわたってデータの冗長性を自動的に確保します。これらのバケットの使用には、アプリケーションに構成や API の変更を加える必要がなく、発生は非常にまれでも壊滅的となり得る事象に対して、耐久性が向上します。さらなるメリットとして、これらのロケーション タイプには、非常に高い可用性 SLA も付属しています。これは、リージョンに一時的にアクセスできない場合に、複数のロケーションからオブジェクトを透過的に提供することで実現されます。

転送中の耐久性

別の部類の耐久性リスクは、転送中のデータの破損に関するものです。この場合は、Cloud Storage サービス内のネットワーク間で転送されるデータ、または Cloud Storage へのオブジェクトのアップロードまたは Cloud Storage からダウンロードされるオブジェクトが考えられます。

こうした破損から保護するために、Cloud Storage 内で転送中のデータは、例外なく常にチェックサムで保護されるよう設計されています。チェックサム検証エラーの場合は、状況に応じて、リクエストが自動的に再試行されるか、エラーが返されます。

ベスト プラクティス: アップロードとダウンロードにチェックサムを使用する

Google Cloud は、サービス内を移動するすべての Cloud Storage オブジェクトをチェックサムしますが、エンドツーエンドの保護を実現するためには、データを Cloud Storage にアップロードするときにチェックサムを提供し、オブジェクトをダウンロードするときにクライアントでこれらのチェックサムを検証することをおすすめします。

人為的な耐久性リスク

データ損失の最大のリスクは、間違いなく人為的エラーによるものです。開発者やサービスのオペレーターとしての私たちによるエラーだけでなく、Cloud Storage ユーザーによるエラーもあります。

ソフトウェアのバグは、データの耐久性に対する単一かつ最大のリスクになり得ます。ソフトウェアのバグによる耐久性の低下を避けるために、Google ではデータ破損やデータ消去のバグの発生を初めから回避するための措置を講じています。次に、耐久性の低下が耐久性の損失につながる前にこうしたバグを検知することを目的として、このタイプのバグを迅速に検出するための安全措置を維持します。

事前にバグを検出するため、Cloud Storage の新しいバージョンは、大規模な統合テストに合格した後にのみ、本番環境にリリースされます。これには、アベイラビリティ ゾーンのダウンなどのさまざまなエッジケースの障害シナリオを実行することや、データ エンコードとプレースメント API の動作を以前のバージョンと比較して、退行のスクリーニングをすることなどが含まれます。

新しいソフトウェア リリースが承認されると、アベイラビリティ ゾーンごとに段階的にアップグレードがロールアウトされます。初期の影響範囲は非常に限定的で、より広範囲に使用されるまで徐々に増加されます。これにより、大きな影響が及ぶ前に、必要な場合に復元を可能にするデータの追加コピー（または十分な数の消去訂正符号チャンク）が残っている状態で問題を特定できます。これらのソフトウェア ロールアウトは、綿密にモニタリングされ、必要であれば迅速なロールバックが行えるよう計画されています。

データ損失を防ぐために実践できることは数多くあります。

ベスト プラクティス: オブジェクトのバージョニングをオンにする

データ損失の最も一般的な原因の一つに、ストレージ管理者またはエンドユーザーによるデータの偶発的な削除があります。オブジェクトのバージョニングをオンにすると、後で復元する必要がある場合に備えて、Cloud Storage は削除されたオブジェクトを保持します。オブジェクトのライフサイクル管理ポリシーを設定することで、ストレージ費用をより適切に管理できるよう、バージョニングされたオブジェクトが完全に削除されるまでの保持期間を制限できます。

ベスト プラクティス: データをバックアップする

Cloud Storage のイレブンナインの耐久性目標は、データのバックアップの必要性を排除するものではありません。たとえば、悪意のあるハッカーが Cloud Storage アカウントへのアクセス権を取得した場合にどうなるかを考えてみてください。目的に応じて、2 番目のデータコピーを別のリージョンやクラウド、オンプレミスにバックアップしたり、テープやディスクを使用してエアギャップで物理的に隔離したりできます。

ベスト プラクティス: データアクセス保持ポリシーと監査ログを使用する

長期的なデータの保持の場合は、Cloud Storage バケットロック機能を使用してデータ保持ポリシーを設定し、データが一定期間ロックされるようにします。そうすることで、偶発的な変更と削除を防止でき、データアクセス監査ログと組み合わせれば、FINRA、SEC、CFTC などの規制やコンプライアンス要件および特定の医療業界のデータ保持規制を満たすことができます。

ベスト プラクティス: ロールベースのアクセス制御ポリシーを使用する

IAM データのアクセス制御ポリシーに職掌分散と最小権限の原則を適用することで、悪意のあるハッカーや偶発的な削除による影響範囲を制限できます。たとえば、バケットを作成できるユーザーと、プロジェクトを削除できるユーザーの区別が可能です。

暗号鍵と耐久性

すべての Cloud Storage データは、クラウド内で保存中および転送中に常に暗号化されるように設計されています。オブジェクトは暗号鍵がないと読み取れないため、暗号鍵の損失は耐久性にとって著しいリスクとなります。耐久性の高いデータでも、読み取れなければ、何の役にも立ちません。Cloud Storage では、鍵管理には 3 つの選択肢があります。1 つ目は、Google に暗号鍵の管理を任せること、2 つ目は、Cloud KMS で顧客管理の暗号鍵（CMEK）を使用すること、3 つ目は、外部のキーサーバーで顧客指定の暗号鍵（CSEK）を使用することです。

Google は、管理下にある暗号鍵の耐久性を保護するために、前述の手順と同様の措置（消失訂正符号と整合性チェックを含む）を講じます。

ベスト プラクティス: 暗号鍵を保護する

鍵管理に CMEK または CSEK を選択することにより、独自の鍵を直接制御できます。これらの場合も、少なくともイレブンナインの耐久性をもたらすように鍵を保護することが不可欠です。CSEK の場合は、鍵を紛失した場合やなんらかの理由で鍵が破損した場合でも、復元できるパスを保持できるようオフサイトの鍵バックアップを維持することです。このような予防措置を講じない場合、暗号鍵の耐久性によってデータの耐久性が左右されます。

イレブンナインを超えて

Google Cloud は、データ保護の責任を最重要視しています。実際には、ここで説明した数多くの手法により、Cloud Storage はこれまでに、イレブンナインを超える年間耐久性を実現しています。その上でこのガイドで共有したベスト プラクティスを実践すれば、今日であれ、数十年後であれ、データが必要なときにいつでも利用できる保証を得る手掛かりになります。まずは、Cloud Storage の入門ガイドを網羅的にまとめたものをご覧ください。

^{本稿の参考元ドキュメントの共著者である CTO オフィス テクニカル ディレクター、Dean Hildebrand の協力に感謝します。}

-Geoffrey Noer、Cloud Storage プロダクト マネージャー

-David Petrie Moulton 博士、 シニア データ サイエンティスト