クラウドストレージサービスでデータベースの地理的冗長性バックアップを簡素化する

※このブログは2022年10月5日に公開された英語ブログ「Simplify Database Geo-redundancy Backup with Cloud Storage Services」の拙訳です。

地理的冗長性とは地理的に分散したデータセンターでデータをバックアップするディザスタリカバリの手法です。この方法は、インシデントの発生を防ぎ、ビジネスの継続性を担保します。データベースシステムでは、コールド (オフライン) バックアップとホット (オンライン) バックアップの2つの方法で地理的冗長性を確保することができます。コールドバックアップの方が安価な上、オンラインパフォーマンスへの影響も少ないため、より広く利用されています。

費用対効果が高く拡張性の高いコールドバックアップソリューションですが、その構築は容易ではありません。拡張性、運用、コストに課題がある場合もあります。この記事では、これらの課題に対する解決策として、クラウドストレージサービスを利用した地理的冗長性バックアップを提案します。

地理的冗長性コールドバックアップへの挑戦

まず、一般的によく使われているコールドバックアップソリューションの限界について見てみましょう。

データベース標準のバックアップ機能

データベースは通常、コールドバックアップ機能を備えて出荷されています。ローカルストレージにデータをダンプするツールや、リモートストレージサービスにデータをアップロードするツールが提供されています。データベースの場合、地理的冗長性バックアップは、単一の宛先バックアップとあまり変わりません。単にリモートストレージの宛先を増やすだけです。

データベースを使った従来のコールドバックアップ

しかし、バックアップ時にデータをダンプすると、多くの帯域を使用することになります。指定する宛先が増えるほど、より多くの帯域幅を消費することになるのです。そのため、データベースのパフォーマンスに大きな影響を与える可能性があります。最悪の場合、データのダンプで帯域幅のほとんどを使い果たしてしまい、データベースがクエリに応答しなくなる可能性もあります。したがって、データベースの標準機能を使った地理的冗長性は、おそらくスケーラブルなソリューションにはなりません。

データベースの地理的冗長性＋メッセージキュー

メッセージキュー (MQ) を使用することで、この帯域幅の問題を解決することができます。MQは非同期プロセス間通信のメカニズムで、帯域幅を節約するソリューションとして広く受け入れられています。特に、ネットワークがデータの同時処理によって制約を受けている場合は、このソリューションが有効です。MQサービスは、データベースインスタンスとリモートストレージの間に配置することができます。

MQを使用すると、データを複数の宛先に分散して、地理的冗長性のあるバックアップをスケールアップして実現することができます。データベース・パフォーマンスへの影響は、単一宛先のバックアップと同じになります。MQがパフォーマンスのボトルネックに達した場合は、チェーンにインスタンスを追加することができます。

MQによるデータベースの地理的冗長性

一見MQソリューションが良さそうに思われますが、まだすべきことがあります。MQソリューションで地理的冗長性を確保するためのステップを見てみましょう。

1. 対象データをMQのペイロードに分割
2. MQインスタンスにデータをフィード
3. MQインスタンスからのデータ読み込み
4. ペイロードを論理バックアップデータに合成
5. リモートストレージサービスにデータを送信

このように、上流と下流のデータ適応コンポーネントを開発し、MQインスタンスをホストする必要があります。このため、運用・保守コストがかさみ、さらに専門的な知識が必要となるのです。

もっとシンプルで安価な解決策はないか

前述のソリューションとその課題から、私たちの要求は明確です。つまり必要としているのは、拡張性があり、シンプルで、より安価な地理的冗長化ソリューションです。そこで、総所有コストが低く、アーキテクチャがシンプルで、メンテナンスが容易なクラウドサービスを検討することになります。1つの選択肢として、Confluent CloudのようなフルマネージドMQサービスがあります。クラウド上のスケーラブルなサービスによりMQの処理手順から解放されるかもしれませんが、それは問題の一部に過ぎません。まだ、上流と下流の適応コンポーネントを開発する必要があるのです。本当に必要なのはStorage as a Service、正確にはCRRaaS (Cross Region Replication as a Service) ソリューションなのです。CRRaaSを使えば、あるリージョンにデータを保存し、他のリージョンに自動的にレプリケーションすることが可能です。

CRRaaSによる地理的冗長性

人気のクラウドソリューションS3とGCSを比較

クラウドベンダーが提供するオブジェクトストレージの中で、最も広く使われているサービスを見てみましょう。Amazon Simple Storage Service (S3) とGoogle Cloud Storage (GCS) です。どちらもリージョンをまたいだレプリケーションのオプションが用意されています。さらに、ほとんどのデータベースがマネージド・ストレージ・サービスへのデータのバックアップをサポートしているので、データ適応のためのコンポーネントは必要ありません。この項では、S3とGCSを比較し、地理的冗長バックアップの目標を達成できるかどうかを確認します。

S3

S3レプリケーションサービスは、クロスリージョンレプリケーションを含みます。バージョニングが有効な2つのストレージバケット間のレプリケーションルールを定義することができます。Amazon S3の地理的冗長性レプリケーションは、次のようになります。

Amazon S3による地理的冗長性

Amazon Web Service (AWS) 1つのアカウントでは、最大1,000バケットまでしかサポートできません。そのため、地理的に冗長なバックアップを必要とするデータベースインスタンスが多い場合、データベースインスタンス間で共有バケットを定義する必要があります。また、S3ではデータ保持のライフサイクル設定をバケットに設定し、コストをコントロールすることができます。

Amazon S3上の共有バケット

GCS

GCSは、ストレージバケット間のレプリケーションルールをユーザーに定義させる代わりに、シングルリージョン、デュアルリージョン、マルチリージョンという3種類のバケットロケーションを提供します。デュアルリージョンまたはマルチリージョンのバケットを選択することで、クロスリージョンレプリケーションを実現することができます。

GCSによる地理的な冗長性

デュアルリージョンのバケットは、2つのバックアップ先までしか拡張できません。2つ以上のバックアップ先で地理的冗長性を実現するには、マルチリージョンバケットを選択する必要があります。

比較

S3とGCSはどちらもCRRaaSの観点から我々の要求を満たしており、それぞれ独自の特性を持っています。この表は、両ソリューションの比較です。

地理的冗長性オプション	S3レプリケーション	GCSデュアルリージョン	GCSマルチリージョン
SLA	15分以内に99.99%	99.9% within 15 minutes (turbo replication mode)	60分以内に99.99%
動作負荷	レプリケーションパフォーマンスの監視 レプリケーションとライフサイクルルールの管理	レプリケーションパフォーマンスの監視	レプリケーションパフォーマンスの監視
拡張性 / 耐障害性	任意のリージョン数への拡張が容易 N-1リージョンでの障害に耐えられる	2つの固定リージョンにデータが分散される 1つの領域の障害に耐えられる	同じ大陸内の2つ以上のリージョンにデータが分散している 2つ以上のリージョンで障害に耐えられる
アクセスレイテンシー	同じリージョンからデータにアクセスする場合はレイテンシーが低い	同じリージョンからデータにアクセスする場合はレイテンシーが低い	すべてのリージョンでデータが保存されていない可能性があり、ユーザーからは見えないため予測不可能

S3とGCSはマネージドストレージサービスなので、開発者はレプリケーションインフラをホストする必要がありません。ここでは、どちらかを選択する前に考慮すべき点をいくつか紹介します。

• サービス品質。S3は、新しいデータオブジェクトの99.99%を15分以内にレプリケートできるSLA (Service Level Agreement) をサポートしています。一方、GCSは、マルチリージョンモードの場合、60分以内に新しく書き込まれたオブジェクトの99.9％を同期することを保証するのみです。システムの高いRPO (Recovery Point Objective) が必要な場合は、S3を選択するのが良いでしょう。
• 操作性の良さ。GCSはより直感的に使用することができ、バケットのロケーションタイプを選択するのも簡単です。マルチリージョンバケットを採用しているため、地理的冗長性の運用が大幅に簡素化されます。Amazon S3では、レプリケーションとライフサイクルルールを設定する必要があるため、操作がやや複雑になります。
• 耐障害性のカスタマイズ。S3では、レプリケーションの対象リージョンの数や場所を選択することができます。これに対し、GCSはオプションが固定されており、障害耐性能力はユーザーからは見えません。もし、あなたのシステムに高度で制御可能な障害回復能力が必要であれば、S3を検討したほうがよいでしょう。そこまでの機能を必要としないシステムでは、デュアルリージョンのバケットで十分です。
• アクセスレイテンシー。S3とGCSのデュアルリージョンバケットでは、ユーザーがどのリージョンに完全なデータコピーがあるのか分かっているため、予測可能な低レイテンシーを保つことができます。しかし、GCSのマルチリージョンバケットでは、大陸のすべてのリージョンで完全なデータコピーにアクセスできることを保証していないため、予測ができません。

システムが比較的高いRPO、予測可能なレイテンシ、および1リージョン障害からの耐障害性を必要とする場合、GCSデュアルリージョンバケットは良く適合するでしょう。また、シンプルで高いリージョン障害の回復性を望むなら、GCSのマルチリージョンバケットは良い選択です。もし、RPO、耐障害性、アクセスレイテンシーに非常に高い要件があり、それらを制御したいのであれば、S3を使用します。

まとめ

クラウドサービスを利用し、データベースの地理的冗長化コールドバックアップを開発することは、従来のシステムよりはるかに簡単です。しかし、Amazon S3やGCSのようなCRRaaSソリューションがすべての悩みを解決してくれるわけではありません。やはりシステムをクラウドプラットフォームと統合する必要があります。全体的なパッケージが必要な場合は、TiDB CloudのようなDatabase as a Serviceを検討するとよいでしょう。このオプションは、データベースに期待されるすべてを、クラウド上で完全に管理して提供します。