Cloud Storage の地域的冗長性について考える
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2021 の 25 日目(最後)の記事です。
みなさんこんにちは。そしてメリークリスマス。
Google Cloud Partner Engineer の Yosuke です。
12/1 から実施してきました Google Cloud Japan Customer Engineer Advent Calendar 2021 も本日で最後となります。
最後のテーマがベーシックな Cloud Storage というところで、面食らった方もいると思いますが、基礎を振り返るということでクリスマスを味わいながら、見てもらえると嬉しいです。
TL;DR
Cloud Storage では 1 つのバケットで 異なる 2 つのリージョンにデータを保存する(冗長構成をとる)ことが可能です。今までは 2 リージョン間のデータ同期にかかる時間が明確に定義されておりませんでしたが、今年の 10 月に Preview がアナウンスされた Cloud Storage のターボ レプリケーション機能を使用することで 15 分以内に同期することが担保されました。(デュアルリージョン バケットのみサポート)
はじめに
Cloud Storage はデータ容量が無制限で、高い耐久性を備えたオブジェクト ストレージ サービスです。
Google Cloud においても 10 年以上の歴史があり、IAM などと同様、ほとんどのシステムで使われているサービスになります。
データレイクにおけるデータストアからバックアップ、データ転送の中継など様々なワークロードに対して幅広い用途で利用いただくことが可能です。
Cloud Storage の特徴
Cloud Storage の特筆すべき特徴として以下のようなものがあります。
- 最小オブジェクト サイズのない無制限ストレージ
- 高い耐久性( 99.999999999 % の年間耐久性)
- 高い可用性( 99 % - 99.95 % ※ストレージクラスによる)
- 様々な地域での利用が可能
- 地域的な冗長性への対応
上の 4 つはいわゆるクラウドにおけるオブジェク トストレージとしては一般的な特徴となりますが、5 つめの地域的な冗長性については以前から Cloud Storage の大きな特徴の一つでした。
この記事では、そんな地域的な冗長性について掘り下げていきます。
地域的な冗長性のパターン
Cloud Storage では地域的な冗長化のオプションとして以下の3つが用意されています。
- リージョン
- デュアルリージョン
- マルチリージョン
それぞれの方式に対するデータ配置イメージは次の図のとおりです。
リージョン:特定の1つのリージョンにデータを配置します。
デュアルリージョン:指定可能な地域が限定されていますが、特定の 2 リージョンにデータが冗長的に配置されます。日本では東京と大阪にデータを配置したいケースが多いと思いますが、その場合は 「asia1 (東京と大阪)」を選択する形になります。
※また補足ですが、今年の Google Cloud NEXT ’21 にてこのデュアルリージョンの地域をユーザ側で指定できる機能が今後追加されることがアナウンスされました。より柔軟に指定できるようになりますね!乞うご期待です。
マルチリージョン:指定可能な地域が限定されますが、3つ以上のリージョンが指定したエリアに属しており、その中の任意の 2 リージョンにデータが配置される形となります。国をまたいだ冗長化をしたい場合などに用いられます。
なお、図上は 1 つのデータが配置されているように見えますが、いずれのパターンもリージョン内に存在する複数のゾーンに配置されます。 Cloud Storage のドキュメント にも記載がございますが、最低 2 つのゾーンにまたがって配置されることが担保されています。
リージョン障害時のデータ欠損
さて、先程地域的な冗長性のパターンについて述べましたが、リージョン 障害が発生した場合(例えば東京が被災して asia-northeast1 の Cloud Storage が使えなくなった場合)のデータ欠損に関して確認していきます。
Cloud Storage に格納されている情報は大きく分けるとファイル名やサイズなどのメタデータと実態ファイルのデータに分けられます。冗長化を考える際はこの 2 つを分けて考える必要があります。
メタデータ
メタデータの保存先には Google Cloud のオフィシャルブログ でもアナウンスしておりますが、 Cloud Spanner という高いスケーラビリティと信頼性を有したデータベースが用いられています。この機能により、メタデータに関しては地域的冗長性かつ強整合性が担保されており、東京リージョンが潰れてもオブジェクトの一覧などは問題なく参照することができます。
データ
実際のオブジェクト(データ)に関して強整合は担保されますが、 ドキュメント にも記載がある通り、リージョン間のデータ同期は非同期です。
上記ドキュメントにも記載がある通り、少なくとも1つのリージョンにデータが格納されたタイミングで Cloud Storage はレスポンスを返します。
地理的な冗長性は非同期的に発生しますが、どの Cloud Storage も、アップロードの直後に少なくとも 1 つの地理的な場所内で冗長性を維持します。たとえば、すべての Cloud Storage データは、同じリージョンの少なくとも 2 つのゾーンにわたって冗長になります。
一般的にはその後数分で指定している他のリージョンにコピーされますが、その時のネットワーク帯域やデータサイズによって変動し、何分以内に同期されるか、といった点は明確に担保していません。
勘の良い方はお気づきかもしれませんが、他リージョンに同期中にデータが格納されているリージョンで障害が発生した場合、データ同期がエラーになることが想定されます。
この場合、メタデータは同期されているので、ファイル一覧としては表示されるものの、データにアクセスしようとした際にエラーになるといった挙動になる可能性があります。
※このケースの障害を実際に発生させられないので、どういったエラーになるかは確認ができていない(推測が含まれる)ことをご了承ください。
こうなってしまうとファイル一覧として表示されていても実際のデータにはアクセスできない状況に陥るため、障害復旧作業が複雑になります。
ターボ レプリケーションの概要
ターボ レプリケーションは今年の 9 月に Preview が開始された、上述の課題を解決するためのサービスです。
( 2021/12/25 時点でも Preview です )
デュアルリージョン バケット限定となりますが、この機能を有効にすることにより、別リージョンへの同期時間を 15 分以内を目標に同期することが可能となりました。
1 点、Cloud Storage SLA に記載のあるターボ レプリケーションの SLO は ターボ レプリケーション機能が GA となったタイミングで有効となりますのでご注意ください。
システム要件上、地域的冗長化が必須であり、かつ同期時間を担保する必要があるようなケースでは有効化することをお勧めします。
ターボ レプリケーション機能の設定方法
ここからはターボ レプリケーション機能の設定方法について紹介します。
非常に簡単に設定が可能です。
※ gsutil コマンドでも設定できます
・バケットを新規に作成する場合
・既存のデュアル リージョンバケットを変更する場合
1. 「レプリケーション」横の鉛筆マークを押下
2. 「保存」ボタンを押下
設定後のオブジェクトが同期されるタイミングなど、いくつか考慮事項がございます。こちらは ドキュメント に詳しく載っていますので、必要に応じてご参照ください。
まとめ
今回は GCS の地域的な冗長性についてご紹介しましたが、 Cloud Storage はリージョンを跨いでも 1 つのバケットとして扱えるため、非常に使い勝手がよいサービスです。
ターボ レプリケーションの登場により SLA としても同期時間が定義されることでより扱いやすいサービスとなりました。
高い信頼性を必要とするシステムを設計する際は是非参考にしてみてください。
実際のビジネスニーズに応じて RPO、 RTO が定められていると思いますので実際に設計する際は Google Cloud のサポートをうまく使いながら仕様を確認しつつ、確実なアーキテクチャを設計いただければと思います。
長くなりましたが、以上となります。
皆様良いお年を!!