SingleStore Helios SmartDR

危機的状況に直面した場合でも、数回のクリック操作だけでセカンダリ領域でアプリケーションを起動できるため、ダウンタイムを最小限に抑えることができます。さらに、SmartDRは非常にコスト効率が高く、セカンダリ領域で遊休状態のコンピューティングリソースを消費する必要がなくなります。 

この記事では、SingleStore Helios SmartDRが、コスト効率とシンプルさを両立させながら、お客様の災害復旧（DR）要件をどのように満たすのかをご案内します。

災害復旧と高可用性の違い

詳細に入る前に、高可用性（HA）と災害復旧（DR）の違いを明確にしておきましょう。HAとDRはしばしば混同されますが、目的は異なります。どちらも重要なデータやアプリケーションの可用性を維持することを目的としていますが、HAは軽微な不具合や個別のインフラストラクチャ障害による中断を防止または最小限に抑えることに重点を置いています。一方、DRは地域全体に影響を与え、復旧時間が不明な大規模な事象や災害に対処します。

例えば、HAが役立つシナリオとしては、コンピューティングノードの健全性が低下した場合、ストレージボリュームが故障した場合、ネットワーク障害が複数のラックに影響を与えた場合、または停電によりデータセンター全体（可用性ゾーン）が停止した場合などが挙げられます。DRプランは、地震や洪水などの自然災害により地域全体が機能停止し、いつ復旧するか分からない場合に有効になります。銀行や医療などの一部の業界では、特定のリカバリポイント目標（RPO）とリカバリ時間目標（RTO）の要件を満たす強力なDRプランを持つことが義務付けられています。

ディザスターリカバリーソリューションは、通常、RPOとRTOで評価されます。RPOは、システム復旧時に企業にとって許容可能なデータ損失レベルを決定します。RTOは、障害発生から正常な運用（データ可用性を含む）に戻るまでの時間を測定します。RPOとRTOはどちらも時間間隔で測定されます。たとえば、RPOが5分の場合、データベースが復旧した際に5分間のデータが失われることを意味します。これは、プライマリリージョンからセカンダリリージョンへのデータの複製頻度によって異なります。同じ例を続けると、RTOが15分の場合、運用準備が整うまで、またはデータベースの停止が解消されるまでにこれだけの時間がかかったことを示します。

SingleStore SmartDRは違います

SingleStore Helios SmartDR を使用すれば、リージョンをまたいだ災害復旧（DR）戦略を容易に実現できます。SmartDR はデータだけでなく、クラスタ構成、ユーザー、ロールと権限、ファイアウォール ポリシー、パイプライン（データ取り込み用）、その他すべてのメタデータも複製します。SmartDR の特長は、セカンダリ リージョンで常にアイドル状態のコンピューティング インスタンスを複製する必要がないことです。これにより、クレジットを 2 倍無駄に消費せずに済みます。ご存知のとおり、コンピューティング インスタンスはインフラストラクチャの中で最もコストのかかる部分です。

SmartDRの設定

SmartDRは、以下の簡単な手順で使い始めることができます。

1. 上部メニューから「レプリケーション」タブを選択し、 「レプリケーションの設定」をクリックします。
2. データベースが配置されているプライマリリージョンを選択してください。これは事前に選択されており、変更できません。
3. データベースを複製するセカンダリリージョンを選択してください。ドロップダウンリストから任意のリージョンを選択できます。
4. 複製するデータベースを選択してください。リストから1つまたは複数のデータベースを選択できます。
5. レプリケーションの種類として「ストレージのみ」を選択してください。現時点では、このオプションのみが利用可能です。
6. 「送信」ボタンをクリックしてください。ステータスバーが表示され、レプリケーション処理の進行状況と各データベースのレプリケーション状態が表示されます。

SmartDRは、設定したらあとはお任せのソリューションです。レプリケーションを設定すると、SingleStoreが自動的にセカンダリリージョンへのデータの非同期レプリケーションを開始します。UIのレプリケーションタブで、最新の同期ステータスを確認できます。対称型かつ双方向のレプリケーションを採用しているため、オブジェクトストレージ内のデータがセカンダリリージョンに確実にレプリケートされます。さらに、このプロセスではセカンダリリージョンにアイドル状態のコンピューティングリソースをプロビジョニングする必要がありません。

災害が発生し、フェイルオーバーを実行したい場合は、フェイルオーバーボタンを1つクリックするだけで済みます。すると、セカンダリリージョン（ターゲットリージョン）にオンデマンドで環境がプロビジョニングされます。フェイルオーバーが完了すると、セカンダリリージョンはプライマリリージョン（または最近障害が発生したリージョン）とまったく同じ状態になります。あとは、アプリケーションを新しいワークスペースに接続するだけです。 

SmartDRを使用してセカンダリリージョンを事前にプロビジョニングする

SingleStoreでは、セカンダリリージョンを事前にプロビジョニングできる柔軟性も向上します。これには主に3つの利点があります。

1. フェイルオーバーを開始する前に、アプリへの安全な接続のためにプライベートエンドポイントを設定できます。
2. プライマリリージョンに影響を与えることなくセカンダリリージョンにフェイルオーバーすることで、DRをテストできます。
3. ワークスペースが既にアクティブになっているため、より予測可能なフェイルオーバーを実現できます。事前プロビジョニングによりワークスペースを保護し、他のリージョンがダウンした場合に、残りのリージョンで発生する可能性のあるアクセス集中を回避できます。

事前プロビジョニングを行うには、レプリケーション タブに移動して「事前プロビジョニングを開始」を選択するだけです。SingleStore は、バックグラウンドでプライマリ リージョンと同じトポロジと構成を使用してセカンダリ リージョンを構成します。これには、ワークスペース、データベース、ユーザーとグループの権限、セキュリティ構成、パイプラインが含まれます。セカンダリ リージョンを事前プロビジョニングする主な利点は、このセカンダリ リージョンでプライベート エンドポイントを構成できるため、フェイルオーバー時にアプリケーションへの接続プロセスがより高速かつ簡単になることです。

このプロセス中、プライマリリージョンはセカンダリリージョンへのデータの複製を継続的に行います。そのため、コンプライアンス要件を満たすための優れた方法として、本番環境に影響を与えることなくフェイルオーバーをテストすることができます。フェイルオーバーをテストするには、セカンダリリージョンに切り替え、データベースをワークスペースに接続し、クエリを実行して最新のデータがセカンダリリージョンに複製されていることを確認します（接続すると、データベースの新しいブランチが暗黙的に作成されます。これについては後ほど詳しく説明します）。このテストでは、セカンダリリージョンにアプリケーションを接続し、本番環境に影響を与えることなく、アプリケーションが期待どおりにデータベースにデータを挿入または更新できることを検証することもできます。

このテストフェイルオーバーを機能させるために、SingleStoreのDBブランチと呼ばれる機能を活用します。DBブランチはGitブランチに似ていますが、データベース用です。ブランチを作成すると、親ブランチのデータファイルへのメタデータ参照が共有されます。実際のファイルをコピーする必要がないため、高速かつコスト効率に優れています。

履歴を除き、ブランチは互いに独立して動作します。ブランチに加えた変更は、親データベースには影響しません。フェイルオーバーのテスト中、SingleStoreはフェイルオーバー時点までのすべてのデータを反映するデータベースのブランチを自動的に作成します。これにより、プライマリリージョンのワークロードに影響を与えることなく、セカンダリリージョンでアプリケーションの更新を安心してテストできます。

最後に、セカンダリリージョンにアクティブなワークスペースを事前にプロビジョニングしておくことで、もう一つ大きなメリットが得られます。それは、より予測可能なフェイルオーバー体験が保証されることです。災害発生時には、フェイルオーバーを開始することで、SingleStoreはデータベースを準備済みのインフラストラクチャに即座に接続し、顧客がスムーズなエンドポイント切り替えを実行できるようにすることで、アプリケーションのダウンタイムを最小限に抑えることができます。 

フェイルオーバー体験について詳しく見ていきましょう

先日、SingleStore を使用した場合、イベント発生時のフェイルオーバーがいかに簡単で分かりやすいかについて説明しました。レプリケーション タブのフェイルオーバー ボタンをクリックするだけで、インフラストラクチャの保護、データベースの起動、アプリケーションの可用性を再開するための接続文字列の提供など、すべて SingleStore が処理します。

この事例では、SingleStoreは一貫性よりも可用性を優先します。非同期型の災害復旧ソリューションはリージョン間でデータを複製しますが、リージョンA（プライマリリージョン）が突然オフラインになった場合、パイプライン内にあるデータやリージョンB（セカンダリリージョン）にまだ複製されていないデータの一部がフェイルオーバー中に失われる可能性があります。

顧客は、リカバリポイント目標 (RPO) の一部として、このトレードオフを受け入れることがよくあります。たとえば、潜在的なデータ損失に対して 5 分間の猶予時間を設けるなどです。リージョン A からリージョン B にレプリケーションする DR 戦略を考えてみましょう。リージョン A で障害が発生し、トラフィックが 90% 減少したとします。ダウンタイムを最小限に抑えるため、リージョン B にフェイルオーバーすることを迅速に決定します。良いニュースは、リージョン B はリージョン A が完全に停止するのを待たずにオンラインになることです。しかし、落とし穴があります。リージョン A への書き込みはまだ少しずつ行われていますが、新しいプライマリ リージョンでは表示されません。多くのシステムでは、リージョン A での書き込みは単に失われます。

しかし、SingleStoreには優れた機能が備わっています。DBブランチングと対称的かつ双方向のレプリケーションをネイティブにサポートすることで、障害が発生したリージョンが最終的にオンラインに戻れば、データが失われることはありません。SingleStoreのレプリケーションの目的はシンプルです。両方のリージョンのオブジェクトストレージの内容が（最終的に）同じになるようにすることです。つまり、ファイルとメタデータは最終的に両方のリージョンに存在することになります。

次の例を見てみましょう。リージョン A が応答しなくなり、ユーザーがリージョン B にすぐにフェイルオーバーします (リージョン A で最初にフェイルオーバー オプションを有効にしていました)。この時点で、SingleStore はリージョン B で使用可能なデータのブランチを作成し、データベースをアタッチしてダウンタイムを短縮します。このアクションはリージョン A とは独立しています。リージョン A で状況が落ち着くと、コントロール プレーン (接続を積極的に試みている) が不足しているデータをコミットし、リージョン B に複製します。リージョン B の別の DB ブランチからこのデータにアクセスし、必要に応じてINSERT...SELECT...またはUPDATEステートメントを使用してライブ データベースに書き込むことができます。

双方向レプリケーションをサポートするSingleStoreは、リージョンBのライブデータベースに入力された新しいデータがリージョンAにも確実にレプリケートされるようにします。これにより、オブジェクトストレージにあるすべてのデータが最終的に両方のリージョンで利用可能になります。

プライマリリージョンが復旧した後、どのようにしてプライマリリージョンにフェイルバックすればよいですか？

SingleStoreの独自の機能により、オブジェクトストレージデータが最終的に両方のリージョンで利用可能になるため、プライマリリージョンへのフェイルバックが非常に簡単になります。プライマリリージョン（リージョンA）が100%正常に動作していることを確認したら、アクティブなセカンダリリージョン（リージョンB）のレプリケーションタブに移動して、「フェイルバック」をクリックするだけです。

SingleStoreが残りの処理をすべて行います。リージョンAのインフラストラクチャを構成し、ユーザー/権限やその他のファイアウォール設定を更新し、データベースを接続して、プライマリリージョン（リージョンA）でアプリケーションに接続して再開するための接続文字列を提供します。このフェイルバックプロセスは段階的に行われるため、リージョンBからリージョンAにデータベース全体をコピーする必要はありません。変更点のみをコピーすれば済みます。

結論

要約すると、SingleStoreは、ミッションクリティカルなアプリケーションを安心して運用できる環境を提供します。当社のプラットフォームは、リアルタイムOLTPワークロード向けのACIDトランザクションを完全にサポートし、データの整合性と一貫性を確保します。可用性ゾーン全体に分散されたテーブルを備えた高可用性アーキテクチャにより、SingleStoreは高い回復力とパフォーマンスを保証します。オンラインPITR機能により、迅速なデータ復旧が可能になり、データを任意の時点に簡単に復元できます。

SmartDRがあれば、たとえリージョン全体がオフラインになったとしても、重要なアプリケーションは災害に強いと確信できます。SmartDRの直感的なレプリケーション設定は、数回クリックするだけで構成でき、データを別のリージョンに安全に保管できます。さらに、セカンダリリージョンにアクティブなワークスペースは不要なので、アイドル状態のコンピューティングリソースを削減でき、大幅なコスト削減につながります。

SmartDRとその設定に関する詳細については、弊社のドキュメントページをご覧いただくか、 team@singlestore.comまでご連絡いただければ、個別のデモをご提供いたします。