Redis EnterpriseとCohesity SmartFiles連携で実現するデータベースの永続性とバックアップ

私たちはこのほど、Redis Technical Partner Programへのオンボーディングの一環として、Cohesityチームと協力し、HeliosとRedis Enterpriseの統合検証を行う機会を得ました。Helios上で動作するCohesity SmartFilesは、データの保存場所に関わらず、非構造化データを一元的に可視化し、グローバルに管理できるサービスです。Redis Enterpriseの文脈では、SmartFilesはデータベーススナップショットの単一ビューを提供します。

なぜ永続性（Persistence）やバックアップにこだわる必要があるのでしょうか？ 実は、Redisを純粋なキャッシュとして利用し、バックエンドのデータベースからシステムへの影響を最小限に抑えながら再構築（リハイドレート）できるのであれば、その必要はありません。しかし一方で、トランザクション履歴、在庫数、顧客情報の照会など「遅いデータ」への高速アクセスを実現する運用データベースとしてRedisを使う場合は話が変わります。ハードウェア障害が発生した際、さらには別のデータセンターへのフェイルオーバーが必要になった際にも、Redisデータベースは迅速に復旧できなければなりません。

永続性（Persistence）

Redisデータベースのすべてのデータは、RAM、またはRAM＋フラッシュメモリ（Redis on Flash）上にのみ保存・管理されます。そのため、プロセスやサーバーに障害が発生すると、データを失うリスクがあります。このリスクを軽減するための戦略はいくつかあります。プライマリとセカンダリのデータシャードを持つ高可用性（HA）データベース、地理的に分散したアクティブ・アクティブ構成のデータベース、そしてもちろんディスクベースの永続化です。

パフォーマンスの観点からは、プライマリシャードから同期済みのセカンダリシャードへのフェイルオーバーが常に望ましく、Redis Enterpriseはまさにそのように動作します。プライマリとセカンダリの両方のシャードを失った場合にのみ、ディスクからデータベースが復元されます。同様に、データセンター障害の場合も、ディスクからの復旧よりも、別のデータセンターにある同期済みアクティブ・アクティブデータベースへフェイルオーバーする方が高速です。

永続化の選択肢としては、Redisはより高い耐久性を実現できるものの多くのリソースを必要とするアペンドオンリーファイル（AOF）と、耐久性は低いもののリソース消費を抑えられるスナップショット（RDB）の両方をサポートしています。すべての技術選定と同様にトレードオフがあり、詳細はRedis Enterpriseのドキュメントで確認できます。本記事では、より高い耐久性を得るためにAOFを使用することを前提とします。

バックアップ

Redis Enterpriseは、プライマリとセカンダリの両方のデータベースシャードを失った場合の復旧手段として永続化に依存します。アクティブ・アクティブ構成を採用しておらず、データベースと接続ストレージを収めたラック全体を失ってしまった場合、残された道はバックアップからの復元だけです。Redis Enterpriseにおいて、バックアップは常にスナップショットであり、これをAOFによる永続化と組み合わせることで、回復性と耐久性に優れたデータプラットフォームが実現します。

ここでCohesity SmartFilesの出番です。Redis Enterpriseは、SmartFilesが提供するS3互換エンドポイントを活用することで、クラウドを横断したマネージドバックアップを実現できます。設定にはRedis EnterpriseのREST APIを使用します。以下の前提条件を想定しています。

• $S3_IP にはCohesity S3オブジェクトストアのIPアドレスを、$BUCKET にはバケット名を設定します
• $USER と $PASS には、それぞれRedis Enterpriseの管理者ユーザー名とパスワードを設定します
• $ACCESS_KEY と $SECRET_KEY には、それぞれS3オブジェクトストアのアクセスキーとシークレットキーを設定します

まず、データベースの永続化を有効にします。

curl -s -k -u $USER:$PASS -H content-type:application/json -XPUT 
https://localhost:9443/v1/bdbs/1 -d '{"data_persistence": "aof"}'

次に、S3 URLを設定してクラスターがS3オブジェクトストアを使用するように構成します。なお、S3 URLにはバケット名は含めない点に注意してください。

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/cluster -d '{"s3_url": '"$S3_IP"'}'

クラスターのS3バックアップを証明書検証なし（プライバシーのみ）で構成します。

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/cluster -d 
'{"s3_certificate_verification":false}'

バックアップ先の場所を検証します。成功時のレスポンスはHTTP 200 OKのみです。

curl -s -k -u $USER:$PASS -H content-type:application/json -X POST 
https://localhost:9443/v1/bdbs/actions/validate_backup_location -d 
'{"backup_location": {"type": "s3", "bucket_name": '"$BUCKET"', 
"subdir": "","access_key_id": '"$ACCESS_KEY"', "secret_access_key": 
'"$SECRET_KEY"'}}'

バックアップを作成します。成功時のレスポンスはHTTP 200 OKのみです。

curl -s -k -u $USER:$PASS -H content-type:application/json -X POST 
https://localhost:9443/v1/bdbs/1/actions/export -d 
'{"export_location": {"type": "s3", "bucket_name": '"$BUCKET"', 
"subdir": "", "access_key_id": '"$ACCESS_KEY"', "secret_access_key": 
'"$SECRET_KEY"'}}'

30分ごとの定期バックアップを構成します。成功時のレスポンスはHTTP 200 OKのみです。

curl -s -k -u $USER:$PASS -H content-type:application/json -X PUT 
https://localhost:9443/v1/bdbs/1 -d '{"backup":true, 
"backup_interval":1800, "backup_interval_offset":360, 
"backup_location": {"type": "s3", "bucket_name": '"$BUCKET"', 
"subdir": "", "access_key_id": '"$ACCESS_KEY"', "secret_access_key": 
'"$SECRET_KEY"'}}'

まとめ

摩擦のない理想の世界では、HAとアクティブ・アクティブを構成したRedis Enterpriseがあれば、永続化やバックアップを気にする必要はありません。しかし現実の世界はそうではなく、システム障害からの復旧が求められる状況では、HAに加えて永続化とバックアップの両方が不可欠です。Dell EMC、NetApp、Pure Storageなどのアプライアンス製品に見られるように、S3バックアップエンドポイントを採用するのはごく一般的な構成です。幸いにも、Cohesity SmartFilesとの検証済み統合により、このエンドポイントを簡単に活用でき、バックアップを運用戦略に組み込むことが可能になりました。