このドキュメントでは、本番環境で RIOT ライブ マイグレーションをデプロイして Redis Enterprise Cloud に移行する場合に移行の範囲を定義する方法について説明します。データベース アーキテクト、DevOps / SRE チーム、ネットワーク管理者はこのアーキテクチャを採用することで、チームに対するダウンタイムがほとんどない移行を実現できます。このドキュメントは、Google Cloud CLI と Compute Engine の使用に精通していることを前提としています。
移行の範囲を定義するには、次の手順を実施します。
- 移行元の環境を評価します。
- 移行元インスタンスのインベントリを作成します。
- 移行の範囲と受容できるダウンタイムを特定して文書化します。
- デプロイと管理のプロセスを評価します。
移行元の環境を評価する
移行元の環境を評価するには、Redis OSS、AWS ElastiCache、Azure Cache for Redis から Google Cloud のフルマネージド Redis Enterprise Cloud インスタンスに移行するリソースの要件と依存関係を決定します。
評価フェーズは、次のタスクで構成されます。
- Redis 互換ワークロードの包括的なインベントリを構築します。
- データのサイジングと Redis Cluster のサイジングを実行します。
- VPC ピアリングや Private Service Connect などのネットワーク要件を確認します。
- Redis Enterprise Cloud の料金ページにアクセスして、移行先の環境の総所有コスト（TCO）を計算します。
- 移行するワークロードの順序と優先度を決定します。複数のサブスクリプションを作成して、開発やテスト、ステージング、本番環境など目的が似ているデータベースを統合します。
移行元インスタンスのインベントリを作成する
移行の範囲を定義するには、Redis OSS、AWS ElastiCache、Azure Cache for Redis から移行元インスタンスのインベントリを作成します。このステップの目的は、メモリ上限、IOPS、耐久性の要件など、各データベースに関する情報を収集することです。
- サブスクリプション レベルでの一般的なプロパティ:
- サブスクリプションのリージョン
- アクティブ - アクティブの地理的分散
- 自動階層化（メモリ上限が 250 GB を超える場合は総所有コストを抑えられる）
- 各データベースの構成:
- メモリ上限とスループット（1 秒あたりのオペレーションの回数）
- 高可用性
- 耐久性の要件
- 検索、JSON、時系列、確率など、データベースごとの高度な機能
- ポート、ユーザー、その他のセキュリティ オプションなどの接続情報
- 要件と制約事項:
- 目標復旧時点（RPO）と目標復旧時間（RTO）
- サービスレベル契約（SLA）
- 規則とコンプライアンスの要件（Redis のカスタマー トラスト センターを参照）
- 認証とセキュリティの要件
移行の範囲と受容できるダウンタイムを特定して文書化する
移行を成功させるには、移行の範囲を適切に設定する必要があります。移行の範囲を設定するために、移行戦略とツールに影響を与える重要な情報を文書化します。評価のこの段階では、次のような質問に回答できます。
- データベースが 250 GB を超えているかどうか。超えている場合、自動階層化を有効にすると総所有コストを抑えられます。
- データベースはどこにあるか（リージョンとゾーン）、そのアプリケーションとの距離はどのくらいか。
- データが変更される頻度はどのくらいか。
このような質問に対する回答の多くは、前のセクションの「移行元インスタンスのインベントリを作成する」で明らかになっています。ただし、このステップではスケーラビリティ、耐久性、維持する必要があるセキュリティ要件と制約を文書化するなど、他の側面も考慮する必要があります。Redis のトラスト センターで業界とコンプライアンス認証について確認し、必要に応じてビジネス オーナーや法務チームと話し合うことをおすすめします。
また、詳細な移行の範囲を定義する必要があります。ECstats や acrp2acre などのツールからの出力を使用して、Google Cloud の Redis Enterprise Cloud インスタンスのサイズ要件を定義できます。スケーラビリティやセキュリティ要件など、各データベース インスタンスの属性を確認します。データベースのサイズが 250 GB を超える場合は、自動階層化の使用をおすすめします。また、類似する特性とセキュリティ プロファイルを持つデータベースは、単一のサブスクリプションにグループ化することをおすすめします。そうすることで、データベースの移行が既存の SLA やビジネス オペレーションに影響を与えないようにすることができます。
デプロイと管理のプロセスを評価する
本番環境に不要な中断が発生しないように、データベースの運用プロセスとデプロイ プロセスを評価することをおすすめします。この評価は、移行を成功させるためにデータベースをどのように適応させる必要があるかを判断するのに役立ちます。
- データベースへのアクセスを制御するために、データベース インスタンスのセキュリティ ポリシーを定義、適用する方法を評価します。
- アカウントに送信される通知メールとそれをトリガーする条件を定義することによって、モニタリングとアラートの要件を評価します。
- Redis の Prometheus と Grafana との統合を使用して、Redis Cloud の指標を収集して可視化します。
次のステップ
- Google Cloud のデータ移行に関するコンテンツを読む。
- RIOT の各種ドキュメントで、詳細なドキュメントとベスト プラクティスを確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者:
- ISV パートナー エンジニア | Saurabh Kumar
- Redis、プリンシパル クラウド アーキテクト | Gilbert Lau
その他の関係者:
- データ マネジメント担当カスタマー エンジニア | Chris Mague
- デベロッパー アドボカシー マネージャー | Gabe Weiss
- クラウド ソリューション アーキテクト | Marco Ferrari