複数ゾーンへの Lindorm インスタンスのデプロイ - Lindorm

Lindorm では、複数ゾーンにまたがるインスタンスを作成できます。マルチゾーンデプロイメントソリューションでは、Lindorm インスタンスは複数ゾーンにデプロイされます。マルチゾーンインスタンスは、ディザスタリカバリ機能を向上させることができます。 Lindorm インスタンスは、複数ゾーンにわたる強力なデータ整合性を確保できます。 Lindorm インスタンスにリクエストを送信できます。データに結果整合性が求められる場合、インスタンスは高速で結果を返すことができます。これにより、オンラインビジネスのサービス品質が向上します。

従来のアーキテクチャとの比較

従来のプライマリ/セカンダリディザスタリカバリの概要

従来のプライマリ/セカンダリディザスタリカバリの場合、ゾーン A とゾーン B にプライマリインスタンス 1 とセカンダリインスタンス 2 という名前の 2 つのインスタンスを購入できます。これにより、高可用性を確保できます。 Lindorm Tunnel Service（LTS）を使用して、Lindorm インスタンス間で双方向同期を実行できます。プライマリインスタンス 1 で障害が発生した場合、またはゾーン A が使用できない場合は、接続をセカンダリインスタンス 2 またはゾーン B に切り替えて、高可用性を確保できます。次の図は、プライマリ/セカンダリディザスタリカバリの高可用性アーキテクチャを示しています。

プライマリ/セカンダリディザスタリカバリソリューションは、ほとんどのユーザーの高可用性要件を満たすことができます。ただし、このソリューションはすべてのビジネスシナリオに適しているわけではありません。このソリューションには、次のデメリットがあります。

プライマリインスタンスとセカンダリインスタンスの間でデータを同期するときに、遅延が発生します。その結果、データの強力な整合性を確保できません。
プライマリインスタンスとセカンダリインスタンス間のデータ同期は、非同期的に実行されます。ビジネスデータは、プライマリインスタンス 1 に書き込まれた後にのみ、セカンダリインスタンス 2 に同期できます。フェールオーバーが実行されると、ビジネスアプリケーションでは最新のデータをすぐに読み取ることができません。ただし、ビジネスアプリケーションでは最新のデータをすぐに取得する必要があります。ビジネスで Increment や CheckAndPut などのアトミックセマンティックインターフェイスを使用して、データが書き込まれる前にデータを読み取り、最新のデータの読み取りに失敗した場合、データの順序が正しくなくなったり、データのロールバックが発生したりします。ゾーン A のネットワークで問題が発生した場合、ゾーン A のネットワークが回復するまでの同期遅延により、ゾーン B のデータは失われたままになります。
セカンダリインスタンスのリソース使用率は高くありません。
プライマリ/セカンダリディザスタリカバリが実行されるシナリオでは、セカンダリインスタンスのリソースはほとんどの時間使用されません。リソースは、フェールオーバー中にのみアクセスされます。
データベース管理者は、フェールオーバーを実行する必要があります。
プライマリ/セカンダリディザスタリカバリは、ビジネス側で完了する必要があります。ビジネスアプリケーションのデータベース管理者は、プライマリインスタンスのステータスに注意を払う必要があります。プライマリインスタンスで障害が発生した場合、データベース管理者はワークロードをセカンダリインスタンスに切り替えるかどうかを決定します。フェールオーバーのカスタムロジックとソリューションを指定する必要があります。ロジックとソリューションはビジネスに影響を与えます。

上記の課題は、従来のプライマリ/セカンダリディザスタリカバリを使用すると発生します。 Lindorm が提供するマルチゾーンデプロイメント機能を使用して、これらの課題を解決できます。

Lindorm のマルチゾーン高可用性デプロイメントの概要

Lindorm は、マルチゾーンデプロイメントをサポートしています。 Lindorm インスタンスのワイドテーブルの各パーティションには、各ゾーンに独立したレプリカがあります。先行書き込みログ（WAL）ログは、ゾーン C の基盤となる LindormDFS に保存されます。ゾーン A が使用できない場合、ゾーン C のデータを使用してゾーン B のデータを復元します。レプリカ間のデータは、Lindorm が提供するレプリカコンセンサプロトコルを使用して同期されます。レプリカコンセンサプロトコルを使用してレプリカ間のデータを同期する場合、少なくとも 2 つのレプリカのデータが必要です。マルチゾーンデプロイメントモードでは、Lindorm を使用してテーブルの整合性レベルを設定し、さまざまなビジネス要件に対応できます。テーブルの整合性レベルには、強力な整合性と結果整合性が含まれます。

強力な整合性：テーブルの整合性レベルを強力な整合性に設定すると、データはテーブルのプライマリパーティションからのみ読み取ることができ、プライマリパーティションにのみ書き込むことができます。セカンダリパーティションは、レプリカコンセンサプロトコルを使用してのみ、プライマリパーティションからデータを受信できます。プライマリゾーンのすべてのサーバーが終了した場合、またはゾーンが使用できない場合、Lindorm は自動的にプライマリゾーンを選択します。セカンダリゾーンをプライマリゾーンに昇格するには、ある程度の時間がかかります。強力な整合性モードでは、書き込まれた最新のデータを読み取ることができます。
結果整合性：結果整合性は、弱い整合性とも呼ばれます。テーブルの整合性レベルを結果整合性に設定すると、データはテーブルのプライマリパーティションとセカンダリパーティションから読み取ることができ、テーブルのプライマリパーティションとセカンダリパーティションに書き込むことができます。レプリカコンセンサプロトコルは、ゾーン A に書き込まれたデータをゾーン B に同期するために使用されます。データは非同期に同期されるため、レプリカのデータは不整合になる場合があります。ほとんどの場合、同期遅延は 100 ミリ秒です。結果整合性モードでは、データはテーブルのプライマリパーティションとセカンダリパーティションから読み取ることができ、テーブルのプライマリパーティションとセカンダリパーティションに書き込むことができます。ゾーン A は使用できず、データの書き込み操作とデータの読み取り操作中にグリッチやサーバー障害などの障害が発生します。このシナリオでは、指定された時間が経過すると、結果は返されません。この場合、待つ必要はなく、セカンダリゾーンをプライマリゾーンに切り替える必要もありません。 Lindorm は自動的にゾーン B を選択してリクエストを送信できます。これにより、高可用性が確保され、読み取りおよび書き込み操作のグリッチが軽減されます。

特徴

Lindorm は、高可用性を提供する分散アーキテクチャを使用しています。一部のビジネスでは、可用性に対する要件が高くなっています。この場合、Lindorm は、ネットワークの不通や都市レベルの災害などのサーバー障害や極端な問題を処理する必要があります。Lindorm が提供するマルチゾーンデプロイメントは、次の機能をサポートしています。これらの機能を使用して、さまざまな予期しない状況でデータベースが予期どおりに実行されていることを確認できます。

マルチゾーンデプロイメントは、データセンターレベルまたは都市レベルでディザスタリカバリ機能を提供します。
Lindorm インスタンスの強力なデータ整合性要件または結果データ整合性要件を満たすことができます。
障害の識別とフェールオーバー操作は、Lindorm によって自動的にトリガーされます。この方法は使いやすいです。

次の表は、マルチゾーン高可用性デプロイメント、プライマリ/セカンダリディザスタリカバリ、および Paxos ベースまたは Raft ベースの整合性プロトコルが使用されるシナリオの機能を比較しています。

機能	マルチゾーン高可用性デプロイメント		プライマリ/セカンダリディザスタリカバリ	Paxos ベースの整合性プロトコルまたは Raft ベースの整合性プロトコル
機能	強力な整合性	結果整合性	プライマリ/セカンダリディザスタリカバリ	Paxos ベースの整合性プロトコルまたは Raft ベースの整合性プロトコル
データ損失（目標復旧時点（RPO））	0	< 100 ミリ秒	< 1 秒	0
サービスリカバリ（目標復旧時間（RTO））	1 分	10 秒～ 30 秒	RTO は、フェールオーバー操作の実行に必要な時間に基づいて決定されます。	30 秒～ 3 分
アクセス応答時間	プライマリゾーンのデータにアクセスします。この場合、データは複数ゾーンにわたって読み書きされる可能性があります。	最寄りのゾーンのデータにアクセスします。この場合、データは複数ゾーンから読み書きできます。これにより、グリッチが軽減されます。	プライマリゾーンのデータにアクセスします。この場合、データは複数ゾーンにわたって読み書きされる可能性があります。	プライマリゾーンのデータにアクセスします。この場合、データは複数ゾーンにわたって読み書きされる可能性があります。
使いやすさ	このソリューションはビジネスに影響を与えません。	このソリューションはビジネスに影響を与えません。	ビジネスを変革する必要があります。外部同期リンクが提供されています。ビジネス要件に基づいてリンクを切り替えることができます。	このソリューションはビジネスに影響を与えません。
ログとデータを保存するために必要な最小ゾーン数	ログの保存に必要な最小ゾーン数：3 データの保存に必要な最小ゾーン数：2	ログの保存に必要な最小ゾーン数：2 データの保存に必要な最小ゾーン数：2	ログの保存に必要な最小ゾーン数：2 データの保存に必要な最小ゾーン数：2	ログの保存に必要な最小ゾーン数：3 データの保存に必要な最小ゾーン数：3

従来のプライマリ/セカンダリディザスタリカバリソリューションおよび Paxos ベースまたは Raft ベースの整合性プロトコルに基づくソリューションと比較して、Lindorm のマルチゾーンデプロイメントは、より柔軟なデータアクセス、より短いサービスリカバリ時間、およびより高いユーザビリティを提供します。

説明

Lindorm のマルチゾーン高可用性デプロイメントの場合、Lindorm インスタンスのワイドテーブルの障害識別とフェールオーバーは、強力な整合性または弱い整合性のどちらが必要かどうかに関係なく、インスタンスによって決定されます。このプロセス全体はユーザーにとって透過的です。 1 つの Lindorm インスタンスにアクセスして、データを読み書きできます。複数のインスタンスを接続し、インスタンス間で切り替えるためのミドルウェアを開発する必要はありません。

ビジネスで強力な整合性が不要な場合は、マルチゾーン Lindorm インスタンスを選択し、テーブルの整合性レベルを結果整合性に設定することをお勧めします。
ビジネスで強力な整合性が必要な場合は、マルチゾーン Lindorm インスタンスを選択し、テーブルの整合性レベルを強力な整合性に設定することをお勧めします。

制限事項

オープンソースの HBase クライアントなどのオープンソースクライアントは、マルチゾーン高可用性モードでの Lindorm インスタンスのデプロイをサポートしていません。
マルチゾーンデプロイメントは LindormTable にのみ適用されます。したがって、検索インデックスやカラムナーインデックスなどの他のエンジンに依存する機能は、マルチゾーン Lindorm インスタンスではサポートされていません。セカンダリインデックス、動的カラム、ワイルドカードカラムなど、LindormTable でサポートされている機能は、マルチゾーン Lindorm インスタンスでもサポートされています。
コールドストレージとコールド・ホットデータ分離機能は、マルチゾーン Lindorm インスタンスではサポートされていません。

マルチゾーン高可用性モードでデプロイされた Lindorm インスタンスを購入する

Lindorm コンソールで、マルチゾーン高可用性モードでデプロイされた Lindorm インスタンスを購入できます。詳細については、「インスタンスを作成する」をご参照ください。

マルチゾーン高可用性モードでデプロイされた Lindorm インスタンスを使用する

整合性レベルを選択する

ほとんどの場合、Lindorm インスタンス用に作成されたテーブルの整合性レベルは、デフォルトで結果整合性に設定されています。結果整合性は、ほとんどのユーザーの整合性要件を満たし、高可用性を確保し、グリッチを軽減できます。結果整合性モデルを使用することをお勧めします。ほとんどの場合、100 ミリ秒前に生成されたデータを読み取ることができます。 Lindorm クライアントを使用して、最寄りのゾーンでデータを読み書きできます。読み取りクライアントと書き込みクライアントが同じゾーンにある場合、クライアントが読み取るデータは最新のデータです。グリッチやサーバーのシャットダウンなどの問題が発生した場合でも、現在のゾーンのパーティションは使用可能なまま、またはタイムアウトしません。ビジネスに次の要件がある場合は、テーブルの整合性レベルを強力な整合性に設定します。

最新のデータを読み取る必要があります。
Increment や CheckAndPut などのアトミックセマンティックインターフェイスを使用する必要があります。
テーブルのセカンダリインデックスを作成する必要があります。

説明

強力な整合性モードでは、Lindorm で複数のレプリカを読み取ることによってジッターやグリッチを軽減することはできません。プライマリゾーンで障害が発生した場合、セカンダリゾーンをプライマリゾーンに昇格するには、ある程度の時間がかかります。

テーブルを作成し、テーブルの整合性レベルを設定する

説明

HBase API と HBase シェルは、データ整合性を保証しません。 HBase API を使用して LindormTable にアクセスする場合は、HBase API と HBase シェルを使用してテーブルを作成します。デフォルトでは、作成されたテーブルの整合性レベルは結果整合性に設定されています。次の手順を実行して、テーブルの CONSISTENCY 属性を変更できます。

Lindorm-cli を使用して LindormTable に接続し、SQL ステートメントを実行して LindormTable にアクセスします。詳細については、「Lindorm-cli を使用して LindormTable に接続して使用する」をご参照ください。
テーブルの CONSISTENCY 属性を設定します。
- テーブルを作成するときは、次のステートメントを実行して、テーブルの CONSISTENCY 属性を強力な整合性に設定します。
```
CREATE TABLE dt (
    p1 INT,
    p2 INT,
    c1 VARCHAR,
    c2 BIGINT,
    PRIMARY KEY(p1)
) WITH (CONSISTENCY='strong');
```
  テーブルを作成するときは、次のステートメントを実行して、テーブルの CONSISTENCY 属性を結果整合性に設定します。
```
CREATE TABLE dt2 (
    p1 INT,
    p2 INT,
    c1 VARCHAR,
    c2 BIGINT,
    PRIMARY KEY(p1)
) WITH (CONSISTENCY='eventual');
```
- テーブルを作成した後、次のステートメントを実行して、テーブルの CONSISTENCY 属性の値を結果整合性に変更します。
```
ALTER TABLE dt SET CONSISTENCY='enventual';
```
  テーブルを作成した後、次のステートメントを実行して、テーブルの CONSISTENCY 属性の値を強力な整合性に変更します。
```
ALTER TABLE dt2 SET CONSISTENCY='strong';
```

ワイドテーブルにデータを書き込む

マルチゾーン高可用性モードでデプロイされた Lindorm インスタンスは、シングルゾーンインスタンスと同じ方法で使用されます。 LindormTable に接続し、ワイドテーブルにデータを書き込みます。詳細については、「Lindorm-cli を使用して LindormTable に接続して使用する」をご参照ください。

ワイドテーブルにデータをインポートする

API 操作を呼び出して、マルチゾーンモードまたはマルチゾーン高可用性モードでデプロイされた Lindorm インスタンスにデータをインポートできます。 Lindorm コンソールで Lindorm インスタンスのエンドポイントを取得し、そのエンドポイントを使用してデータをインポートするだけです。
BulkLoad を使用してマルチゾーン高可用性モードでデプロイされた Lindorm インスタンスにデータをインポートする場合は、各ゾーンにデータのコピーをインポートします。データをインポートする際に質問がある場合は、テクニカルサポートにお問い合わせください。