フォロワークラスターは、2つの独立したデータベースシステム（同じタイプ）の同期を維持できるようにするScaleGrid機能です。クローン作成やレプリケーションとは異なり、これにより、本番データのアクティブなポイントインタイムコピーを維持できます。フォロワークラスターと呼ばれるこの追加のクラスターは、MongoDB、MySQL、PostgreSQLのアプリケーションパフォーマンスの分析、最適化、テストなど、複数のユースケースに活用できます。このブログ投稿では、アプリケーションでフォロワークラスターを活用するための上位3つのシナリオについて説明します。
フォロワークラスターはレプリケーションとどのように異なりますか？
静的クローンとは異なり、このデータは設定されたスケジュールでインポートされるため、フォロワークラスターは常に本番クラスターと同期します。レプリケーションと異なるいくつかの重要な方法は次のとおりです。
- 宛先システムがソースから同期する頻度を制御できます–週に1回、1日に1回、またはそれ以下の頻度。これにより、ソースシステムの負荷を軽減できます。
- これらは2つの独立したシステムであるため、同期されるデータに対してはるかに柔軟性があります。さまざまなユーザー資格情報を設定し、セキュリティ要件に基づいて宛先から一部のデータを削除することもできます（注：これにはユーザー側のスクリプトが必要です。フォロワークラスターの組み込み機能ではありません）。
- 「フォロワー」システムは書き込み可能であるため、アプリケーションの変更をテストするためのステージング環境として使用できます。これは、レプリカノードで実行できることではありません。
注：ScaleGridは、ストレージスナップショットを使用してフォロワークラスターを実装します。 Redis™*のホスティングなどのインメモリデータベース製品では利用できません。
1。データベース開発/テストのセットアップ
私たちは皆そこにいます–おそらく十分にテストされたコードが本番環境にデプロイされ、その後すべての地獄が解き放たれます。制作ワークフローが失敗するか、非常に遅いため、基本的に使用できません。エンジニアはベッドから目覚め、本格的な消火活動を開始します。その後、眠れない夜がたくさんあり、その恐ろしい根本原因が浮かび上がります。
アプリケーションは、本番環境とエンジニアリング環境で異なる動作をします。
つまり、「テストデータ」でテストしました。結局のところ、これは本番データのようなものではありませんでした。まったく。
この状況を回避する明白な方法は、本番データでテストを実行することです。もちろん実際の生産ではありません–それは災害でいちゃつくでしょう。本番データのクローンコピー。プライバシーとデータセキュリティに関する懸念により、これは多くのシナリオで実行不可能になりますが、プライバシー要件が許せば、これが最善の解決策です。適切なデータセットを生成するエンジニアに依存する必要がなくなりました。テストデータを渡すと、本番データを渡すことになります。
つまり、テストデータが本番環境と同期しなくなるまで、適切な近似値ではなくなります。そして、私たちはスクエア1に戻ってきました。
ここでフォロワークラスターが登場します。
フォロワークラスターを使用することで、本番データベースからdev/testデータベースにデータを定期的にインポートできます。また、インポート全体が論理ダンプではなくストレージスナップショットを使用して実行されるため、プロセスはほぼ瞬時に行われます。インポートは、24時間ごと、週に1回、または特定のシナリオに適した頻度でスケジュールできます。
開発クラスターとQAクラスターが本番クラスターに従うように設定されているので、安心できます。アプリケーションがテストデータセットに合格した場合、本番環境にデプロイするのに間違いなく適しています！
2。データ分析
DBAとして働いたことがある場合は、特定の時間にシステムパフォーマンスが「不思議に」遅くなることについてチームと話し合ったことがあるでしょう。ほとんどの場合、原因は大量のデータにアクセスしている分析ジョブであり、システム全体の速度を低下させることになります。
DBaaSベンダーとして、私たちはお客様と何度もこの会話をしました。通常提案する2つのオプションは次のとおりです。
- 分析ジョブがプライマリ/マスターサーバーで実行されている場合は、セカンダリ/レプリカサーバーに移動します。
- 分析ジョブがすでにセカンダリノードで実行されていて、パフォーマンスの低下が許容できない場合は、ジョブを専用の分析クラスターに移動することをお勧めします。
フォロワークラスター機能を使用すると、分析クラスターを実際の本番データで最新の状態に保つのが非常に簡単です。フォロワースケジュールを作成して、分析ジョブが開始される直前に本番環境からの最新データを同期できます。
最良の部分は？フォロワーの同期はデータベースレベルの操作を実行しません。最新のスナップショットを復元するだけです。したがって、本番クラスターへの影響はありません。
3。レポート
お客様がフォロワークラスター機能を使用するもう1つの一般的な使用例は、レポートの生成です。通常、レポートプロセスの実行頻度は低くなりますが、大量のデータにアクセスし、データベースクラスターのリソースのほとんどを消費します。パフォーマンスの低下が許容できない場合は、レポートのワークロードを新しいクラスターに移動することをお勧めします。
レポート操作は頻繁ではないため、お客様の多くは、一時停止/再開機能を利用して、レポートクラスターが使用されていないときに「一時停止」することを好みます。これにより、インフラストラクチャのコストを大幅に節約できます。通常、レポートクラスタは、コストを削減するために、はるかに「小さい」（CPU / RAMが少ない）こともあります。
UIからフォロワークラスターを作成したら、このワークフローを使用してレポートフローを自動化できます：
- 履歴書APIを使用してクラスターを再開します。
- クラスターが実行状態に戻るまで待ちます（この目的でget-status APIを使用できます）。
- 必要に応じて、本番クラスターでバックアップをトリガーします（通常、本番で定期的なバックアップがスケジュールされている場合は、この手順をスキップできます。ただし、レポートを最新のデータで実行する場合は、これが不可欠です）。
- バックアップが完了するのを待ちます。
- フォロワーで同期ジョブをトリガーします–これにより、ソースクラスターで最新のスナップショットが検索され、宛先に復元されます。
- 同期ジョブが完了するのを待ちます。
- レポートタスクを実行します。
- 一時停止APIを使用して、次のレポートジョブまでクラスターを一時停止します！
フォロワークラスターは特定のユーザーケースに適していると思いますか？ヘルプドキュメントで、MongoDB、MySQL、PostgreSQLのフォロワークラスターをデプロイおよび管理する方法についてすべて学ぶことができます！
フォロワークラスターがユースケースの正しいソリューションであるかどうかわからない場合は、コメントを残すか、[email protected]までご連絡ください。要件に最適な機能について喜んで話し合います。
