ScalarDB のベンチマークをはじめよう
このページは英語版のページが機械翻訳されたものです。英語版との間に矛盾または不一致がある場合は、英語版を正としてください。
このガイドでは、ScalarDB のベンチマークにおける、計画、実行、分析の方法について説明します。体系的なベンチマーク手法を用いることにより、信頼性があり意味のある性能測定を行うことができ、システム設定、リソースサイジング、技術選択について情報に基づいた決定を下すことができます。
ベンチマークの計画
ベンチマーク実行前に慎重に計画することにより、無駄な労力を減らし、実用的な結果を得ることができます。
ベンチマークの目的を定義する
まず、ベンチマークから何を得たいかを明確にします。目的によって、後に続くワークロード、メトリクス、環境、設定の決定が決まります。
一般的なベンチマークの目的には以下があります:
- システム比較: ScalarDB を類似機能を提供する他のシステムと比較し、要件に最も適したシステムを決定します。
- スケーラビリティ検証: 特定のワークロード下でノードを追加したり並行性を増やしたときに、ScalarDB が期待通りにスケールすることを確認します。
- コスト見積もり: 必要な性能を達成するために必要なリソースに洗い出します。
- 性能検証: 特定のワークロード下で ScalarDB が最低性能しきい値を満たすことを確認します。
性能メトリクスを理解する
ベンチマークの2つの基本的な性能メトリクスは、スループットとレイテンシです。スループットは、システムが単位時間当たりに完了するトランザクション数を測定し、秒当たりトランザクション (TPS) として表現されます。レイテンシは、トランザクション送信から応答受信までの経過時間を測定し、ミリ秒 (ms) で表現されます。
スループットとレイテンシは関連していますが異なります。システムは高いスループットを達成する一方で個々のトランザクションが高いレイテンシになる場合もあり、その逆も同様です。システム性能の状況を完全に把握するためには両方を測定することが重要です。
レイテンシを計測する際は、平均値だけでなくパーセンタイル分布 (p50、p95、p99) を含めてください。平均レイテンシは、ユーザエクスペリエンスに影響するテールレイテンシ問題を隠してしまう可能性があります。
ワークロードを選択する
性能はワークロードによって大幅に異なります。スループット値は、それを生成したワークロードと組み合わせた場合にのみ意味があります。両方とも 1,000 TPS を達成する2つのシステムを考えてみてください。一方のシステムがトランザクション当たり10回の読み取り変更書き込み (RMW) 操作を実行し、もう一方が1回の RMW を実行する場合、最初のシステムは同じ TPS 値を報告しているにもかかわらず、10倍の作業を行っています。
ワークロードを設計する際は、以下の要因を考慮してください:
- 操作ミックス: 読み取りと書き込みの比率。
- トランザクション当たりの操作数: 単一トランザクション内の操作数。
- アクセスパターン: ホットスポットに向かって偏っているかユニフォームか。
- 並行性レベル: 並行スレッド数。
- データセットサイズ: ベンチマークが操作するデータの総量。
- レコードサイズ: ベンチマークが操作する各レコードのサイズ。
異なる条件下でシステムがどのように動作するかを理解するため、実験間で並行性レベルとアクセスパターンを変更してください。
比較ベースラインを定義する
ScalarDB を他のシステムと比較する際は、比較が公平で結果が解釈可能であることを確認してください。
まず、同じ保証を提供するシステムを使用することで公平な比較を確保してください。複数のデータベースを跨ぐマルチデータベーストランザクションが要件である場合、当該トランザクションをサポートしないシステムと ScalarDB を比較することは、システムが根本的に異なる問題を解決しているため意味がありません。ただし、マルチデータベーストランザクションが必須ではなくオプションである場合、調停のオーバーヘッドを測定するために2つを比較することは有効です。その場合は、比較が一般的なシステム性能ではなく調停オーバーヘッドを測定していることを明示的に述べてください。
次に、一度に1つの変数を変更してください。設定やシステムを比較する際は、実験ごとに1つのパラメータのみを変更してください。複数の変数を同時に変更すると、どの変数が観察された性能差を引き起こしたかを特定できません。
一貫性保証が異なるシステム (例: 結果一貫性 vs. 線形化可能な一貫性)を 、違いを考慮せずに比較することは、誤解を招く結論につながります。性能結果と並んで、各システムが提供する保証を常に文書化してください。
期待される性能を推定する
ベンチマーク実行前に、ワークロードとシステムの理解に基づいて期待される性能を推定してください。ベンチマークは性能推定と性能測定の組み合わせです。推定なしの測定は検証が困難です。
推定を作成するには、まずワークロードが実行する操作 (読み取り、書き込み、コミット) を特定します。次に、ScalarDB が各トランザクションで実行する Consensus Commit プロトコルのフェーズを確認し、ストレージバックエンドとネットワーク特性に基づいてフェーズごとのレイテンシを合計して、単一トランザクションのレイテンシを推定します。最後に、期待される並行性をこの単一トランザクションレイテンシで割って、大まかなスループット推定値を導き出します。
ScalarDB アプリケーションの性能をモデル化する際、支配的なコスト要因は環境によって異なります。ストレージ I/O が高速な最新の環境では、ネットワークホップ数がトランザクションレイテンシを決定する主要因子であるため、各トランザクションフェーズが必要とするネットワークラウンドトリップを数えることで合理的なレイテンシ推定が得られます。しかし、大きなデータセットと I/O 集約的ワークロードでディスクスループットがボトルネックとなる環境では、トランザクション当たりのディスク読み取り・書き込み数が推定のより良い基準となります。
推定は正確である必要はありません。大雑把な桁数推定でも、設定ミスの検出に役立ちます。例えば、設定エラーが性能を抑制している場合、推定がなければ測定結果だけから問題を検出する方法がありません。逆に、推定と測定が一致すれば、両方とも正しい可能性が高いです。不一致の場合、その差異を調査することで、推定またはシステム設定のエラーが明らかになることがよくあります。
環境の準備
このセクションでは、インフラストラクチャの設定、ベースライン測定の確立、ベンチマークツールの準備について説明します。
インフラストラクチャの準備
テスト環境はベンチマーク結果に直接影響します。安定したコンピューティングリソースを使用し、性能のばらつきを生じさせるクラウドインスタンスタイプを避けてください。
クラウド仮想マシンは他のテナントと物理ハードウェアを共有するため、性能は時間帯によって異なる可能性があります。クレジ ットが枯渇すると CPU 性能が制限され一貫性のない結果を生成するため、バーストアブルインスタンス (例: AWS Tシリーズ) を使用しないでください。同様に、余剰容量を使用しており、ベンチマーク実行中に回収される可能性があるため、スポットインスタンスやプリエンプティブルインスタンスも使用しないでください。
安定したインスタンスタイプの選択に加えて、リソースをワークロードに合わせてください。例えば、ワークロードが I/O 集約的な場合、高い I/O スループットのインスタンス (NVMe SSD でサポートされたインスタンスなど) をプロビジョニングしてください。そうしないと、I/O ボトルネックが実際のシステム性能を隠してしまう可能性があります。
ScalarDB Cluster のプロダクション級ベンチマークには、それぞれ 4 vCPU と 8 GB メモリを持つ最小3つのワーカーノードが推奨され、ScalarDB Cluster ポッドはポッドあたり CPU 2、メモリ 4 GB に制限されます。回復性テストのため、ノードを異なるアベイラビリテ ィゾーンに配置してください。詳細については、ScalarDB Cluster の制作チェックリストを参照してください。
ベースライン環境性能の測定
ScalarDB をベンチマークする前に、環境の生の性能を測定してベースラインを確立し、早期にインフラストラクチャの問題を検出してください。ベースライン性能測定に役立つツールは以下のとおりです:
これらのベースラインは、インフラストラクチャが期待通りに動作しているかどうか、また ScalarDB ベンチマーク中に観察されるボトルネックが ScalarDB ではなくインフラストラクチャに起因するかどうかの判断に役立ちます。
ベンチマークツールの準備
既存のベンチマークツールがワークロードをサポートしている場合は、カスタムツールを構築するのではなくそれを使用してください。確立されたツールを使用することで、測定エラーのリスクが減り、他の人が結果を再現しやすくなります。どのアプローチを選択しても、ワークロードが何をするかを理解することは重要です。
ScalarDB ベンチマークは、ScalarDB の公式ベンチマークツールです。Kelpie フレームワーク上に構築された標準ワークロード (TPC-C と YCSB 変種) を提供します。ベンチマークシナリオで ScalarDB ベンチマークがサポートしていないワークロードが必要な場合は、カスタムベンチマークを構築してください。その場合は、正確なタイミングとレポートを確保するため、測定インフラストラクチャとしての Kelpie の利用を検討してください。
リポジトリのクローン、ベンチマーク JAR の構築、Kelpie のダウンロード、スキーマの読み込み、ベンチマーク設定ファイルの作成を含む ScalarDB ベンチマークの設定手順については、ScalarDB ベンチマークリポジトリを参照してください。ワークロード固有パラメータの完全なリストについては、ScalarDB ベンチマークを参照してください。
ベン チマーク用の ScalarDB 設定
ベンチマーク実行前に、ベンチマーク目的に合致する性能パラメータで ScalarDB を設定してください。以下の接続モードのサブセクションは ScalarDB Cluster に固有です。性能関連プロパティは ScalarDB Core と ScalarDB Cluster 両方に適用されますが、設定場所が異なります (性能関連プロパティの調整を参照)。
デプロイメントパターンを選択する
アプリケーションが ScalarDB をどのように使用するかに基づいてデプロイメントパターンを選択してください。ScalarDB は以下のデプロイメントパターンをサポートします:
- ScalarDB Core (埋め込み): アプリケーションまたはベンチマークプログラムが ScalarDB をライブラリとして埋め込みます。このパターンは別個のサーバーインフラストラクチャが不要なため、設定が最も簡単です。クラスターデプロイメントのオーバーヘッドなしで ScalarDB をベンチマークしたい場合は、このパターンを使用してください。
- 単一クラスターを持つ ScalarDB Cluster: 単一の ScalarDB Cluster インスタンスがアプリケーション にサービスを提供します。これは、ScalarDB Cluster を使用する際の最も一般的なデプロイメントパターンです。管理が簡単で必要なリソースが少ないため、ほとんどのベンチマークシナリオでこのパターンを使用してください。マイクロサービスの使用例では、このパターンは共有クラスターパターンと呼ばれ、すべてのサービスが単一のクラスターインスタンスを共有し、ワンフェーズコミットインターフェースを使用します。
- 複数クラスターを持つ ScalarDB Cluster: 各アプリケーションまたはサービスが独自の専用 ScalarDB Cluster インスタンスを持ちます。複数クラスターにまたがるトランザクションはツーフェーズコミットインターフェースを使用し、トランザクション処理とエラー回復に複雑さが増しますが、より強いリソース分離を提供します。ツーフェーズコミットインターフェースでのクロスクラスタートランザクション性能を具体的に評価する必要がある場合にのみ、このパターンを使用してください。マイクロサービスの使用例では、このパターンは分離クラスターパターンと呼ばれます。
マイクロサービスデプロイメントパターンの詳細については、マイクロサービスにおける ScalarDB Cluster のデプロイパターンを参照してください。
接続モードを選択する
ScalarDB Cluster を使用する際は、クライアント接続モードを選択してください。ScalarDB Cluster は direct-kubernetes モードと indirect モードの2つのモードをサポートします。
direct-kubernetes モードでは、クライアントは Kubernetes API とメンバーシップベースのルーティングアルゴリズムを使用して、正しいクラスターノードに直接接続します。これにより余分なネットワークホップが排除され、より低いレイテンシとより高いスループットが実現されます。ただし、クライアントアプリケーションは ScalarDB Cluster と同じ Kubernetes クラスター内で実行する必要があります。
indirect モードでは、クライアントはロードバランサーを通じて任意のクラスターノードにリクエストを送信します。indirect モード内には2つのルーティングオプションがあります:
- Service (ClusterIP) 経由 (推奨): クライアントはL4ロードバランサーを介して Kubernetes Service に接続し、クラスターノードにルーティングされます。このオプションはEnvoyを経由する追加のホップを避けるため、レイテンシが低くなります。
- Envoy 経由: クライアントはL4ロードバランサーを介して Envoy プロキシに接続し、クラスターノードにルーティングされます。このオプションは Envoy がL7レイヤーでリクエストを分散できるため、ScalarDB Clusterノード間でより良いロードバランシングを提供しますが、追加のネットワークホップが導入されます。
indirect モードではクライアントを Kubernetes クラスターの外部で実行できますが、リ クエストごとに追加のネットワークホップが発生します。2つのオプションのうち、一般的にはより低いレイテンシのため Service 経由の接続が推奨されますが、クラスターノード間でのロード分散が優先される場合は Envoy 経由が好ましい場合があります。
性能の観点から、direct-kubernetes モードは indirect モード内の両オプションよりも推奨されます。direct-kubernetes モードを設定するには、ScalarDB 設定ファイルで以下のプロパティを設定してください:
scalar.db.transaction_manager=cluster
scalar.db.contact_points=direct-kubernetes:<NAMESPACE>/<ENDPOINT_NAME>
scalar.db.contact_port=60053
indirect モードを設定するには、contact_points 値を置き換えてください:
scalar.db.contact_points=indirect:<LOAD_BALANCER_IP>
性能関連プロパティの調整
ScalarDB は性能に影響するいくつかの設定プロパティを提供します。以下のセクションでは、ベンチマークに最も関連するプロパティについて説明します。
ScalarDB Core を使用する場合は、アプリケーションの ScalarDB 設定ファイルでこれらのプロパティを設定してください。ScalarDB Cluster を使用する場合は、ScalarDB Cluster 設定で設定してください。例外は、クライアント側最適化で説明されているクライアント側最適化で、これは ScalarDB Cluster 固有でクライアント上で設定されます。
Consensus Commit 最適化
Consensus Commit プロトコルは、性能を向上させるいくつかの最適化をサポートします。並列実行プロパティ (parallel_preparation や parallel_commit など)はデフォルトで有効になっており、複数レコードトランザクションに対してプロトコルフェーズを並列実行します。非同期コミット (async_commit)は、commit-records フェーズを待つことなく commit-state フェーズ完了後にクライアントに戻り、わずかに広いリカバリーウィンドウの代償としてスループットを向上させます。ワンフェーズコミット (one_phase_commit) は、すべての変更をアトミックに適用できる場合に prepare と commit-state フェーズを完全にスキップし、シンプルなトランザクションのラウンドトリップを大幅に削減します。
| プロパテ ィ | デフォルト | 説明 |
|---|---|---|
scalar.db.consensus_commit.parallel_preparation.enabled | true | 複数レコードトランザクションに対して prepare フェーズを並列実行します。 |
scalar.db.consensus_commit.parallel_commit.enabled | true | commit-records フェーズを並列実行します。 |
scalar.db.consensus_commit.async_commit.enabled | false | commit-records を待つことなく commit-state フェーズ後にクライアントに戻ります。過度なリカバリーにより中程度から高い競合ワークロードで速度低下を引き起こす可能性があることに注意してください。 |
scalar.db.consensus_commit.one_phase_commit.enabled | false | 変更をアトミックに適用できる場合に prepare と commit-state フェーズをスキップします。 |
各最適化が Consensus Commit プロトコルに与える影響の詳細については、パフォーマンスの最適化を参照してください。
分離レベル
scalar.db.consensus_commit.isolation_level プロパティは、トランザクション分離レベルを制御します。利用可能なレベルは SNAPSHOT、SERIALIZABLE、READ_COMMITTED です。より高い分離レベルでは、異常を防ぐためにプロトコルが追加のチェックを実行する必 要があるため、オーバーヘッドが増加します。
性能だけでなく、アプリケーションが受け入れ可能な異常に基づいて分離レベルを選択してください。各レベルは異なるタイプの異常を許可し、正しい選択はアプリケーションの正確性要件によって決まります。
ベンチマークスループットを改善するためだけに分離レベルを弱めないでください。アプリケーションが SERIALIZABLE 分離を必要とする場合、READ_COMMITTED でベンチマークしてもプロダクションワークロードに関係のないスループット数が計測されます。プロダクションで使用する予定の分離レベルで常にベンチマークしてください。
グループコミット
グループコミットは、複数のトランザクションのコーディネーター書き込みを単一の操作にバッチ処理します。これは、コーディネーターテーブルがリモートにあるもしくは高レイテンシのストレージバックエンドにある場合に特に有益です。グループコミットはツーフ ェーズコミットインターフェースと互換性がありません。
| プロパティ | デフォルト | 説明 |
|---|---|---|
scalar.db.consensus_commit.coordinator.group_commit.enabled | false | コーディネーター書き込みでグループコミットを有効にします。 |
scalar.db.consensus_commit.coordinator.group_commit.slot_capacity | 20 | グループあたりの最大トランザクションスロット数。 |
scalar.db.consensus_commit.coordinator.group_commit.group_size_fix_timeout_millis | 40 | 処理前にグループが満杯になるまで待機するミリ秒。 |
グループコミットを調整する際は、slot_capacity と group_size_fix_timeout_millis の組み合わせを一緒にベンチマークして、ワークロードとストレージバックエンドに最適なバランスを見つけてください。例えば、それぞれ 20 と40、30 と 40、20 と 80 を試してください。
クライアント側最適化
以下のプロパティは ScalarDB Cluster に固有で、トランザクションセマンティクスを変更せずにネットワークラウンドトリップを削減します。piggyback_begin プロパティは、トランザクションの開始を最初の CRUD 操作にピギーバックすることで開始 (begin) RPC 呼び出しを排除し、トランザクションあたり1ラウンドト リップを節約します。write_buffering プロパティは、条件付きでない書き込み操作 (insert、upsert、条件付きでない put、update、delete) をバッファリングしてバッチで実行し、書き込みが多いトランザクション環境における RPC 呼び出し総数を削減します。
| プロパティ | デフォルト | 説明 |
|---|---|---|
scalar.db.cluster.client.piggyback_begin.enabled | false | 最初の CRUD 操作にピギーバックすることで開始 (begin) RPC を排除します。 |
scalar.db.cluster.client.write_buffering.enabled | false | 非条件書き込み操作をバッファリングしてバッチで実行します。 |
piggyback_beginが有効な場合、実際の開始操作が実行されるまでDistributedTransaction.getId()メソッドを呼び出すとIllegalStateExceptionが発生します。piggyback_beginまたはwrite_bufferingが有効な場合、DistributedTransactionManager.resume()およびDistributedTransactionManager.join()メソッドを呼び出すと常にIllegalStateExceptionが発生します。
SQL トランザクションでも同様の最適 化が利用可能です。piggyback_begin プロパティは、プリミティブ API 版と同様に動作し、専用の開始 RPC コールを排除します。write_buffering プロパティは、クライアント側で INSERT および UPSERT ステートメントをバッファリングし、バッチで実行します。
| プロパティ | デフォルト | 説明 |
|---|---|---|
scalar.db.sql.cluster_mode.client.piggyback_begin.enabled | false | 最初の実行操作にピギーバックすることで専用の開始 RPC を排除します。 |
scalar.db.sql.cluster_mode.client.write_buffering.enabled | false | INSERT および UPSERT ステートメントをバッファリングしてバッチで実行します。 |
piggyback_beginが有効な場合、実際の開始操作が実行されるまでSqlSession.getTransactionId()はOptional.empty()を返します。piggyback_beginまたはwrite_bufferingが有効な場合、SqlSession.resume()およびSqlSession.join()メソッドを呼び出すと常にIllegalStateExceptionが発生します。
JDBC接続プール
ストレージバックエンドとして JDBC データベースを使用する場合は、期待される並行性に合わせて接続プールを調整してください。max_total プロパティはプール内の最大接続数を制御します。
| プロパティ | デフォルト | 説明 |
|---|---|---|
scalar.db.jdbc.connection_pool.min_idle | 20 | プール内の最小アイドル接続数。 |
scalar.db.jdbc.connection_pool.max_total | 200 | 最大総接続数 (アイドル + アクティブ)。 |
scalar.db.jdbc.connection_pool.connection_timeout_millis | 30000 | プールから接続を取得するまでの最大待機時間（ミリ秒単位）。 |
scalar.db.jdbc.connection_pool.idle_timeout_millis | 600000 | 接続がプール内でアイドル状態のまま維持される最大時間（ミリ秒単位）。 |
scalar.db.jdbc.connection_pool.max_lifetime_millis | 1800000 | プール内の接続の最大生存時間（ミリ秒単位）。 |
scalar.db.jdbc.connection_pool.keepalive_time_millis | 0 | 接続のキープアライブ間隔（ミリ秒単位）。0 はキープアライブを無効にします。 |
設定プロパティの完全なリストについては、ScalarDB Core の設定と ScalarDB Cluster の設定を参照してください。
ベンチマークの実行
このセクションでは、一貫性があり信頼できる測定を行うベンチマーク実行のプラクティスを概説します。
対象システムのウォームアップ
性能測定前に、JVM クラスローディング、JIT コンパイル、接続プール確立、キャッシュのローディングなどの初期化オーバーヘッドを除去するためシステムをウォームアップしてください。ScalarDB ベンチマークは ramp_for_sec パラメータを通じてランプアップ期間をサポートします。これを少なくとも30秒に設定してください。ランプアップ期間中に収集されたデータは結果から除外されます。
十分な時間実行する
ランプアップ期間後、少なくとも60秒間ベンチマークを実行してください。短時間の実行は、結果を歪める可能性があるガベージコレクション停止やネットワーク変動などの一時的な変動の影響を受けやすくなります。
特定の目的に応じて、計測時間を適宜調整してください。迅速な検証には通常1〜5分で十分です。統計的厳密さを必要とする性能比較には5〜15分実行してください。安定性テストまたは劣化検出には、長期的な動作を観察するため数時間または数日実行してください。
複数回の反復実行
クラウド環境は共有物理インフラストラクチャにより性能のばらつく可能性があります。各ベンチマーク設定を少なくとも3回実行し、平均化によって結果を集計してください。反復間で結果が大幅に異なる場合は、調整平均 (最高値と最低値を除外) を使用するか、ばらつきを伝えるため標準偏差とともに結果を報告してください。標準偏差が平均の10%を超える (変動係数が0.1より大きい）場合は、データから結論を導く前にばらつきの原因を調査することをお勧めします。
結果の検証と分析
このセクションでは、ベンチマーク結果を推定値と照らし合わせて検証し、測定が正確で実用的であることを保証するために設定を反復する方法について説明します。
推定性能との比較
各ベンチマーク実行後、測定結果をベンチマーク実行前に準備した推定値と比較してください。
結果が推定値と一致する場合、推定と測定の両方が正しい可能性が高いです。結果が推定値を大幅に下回る場合、設定ミス、リソースボトルネック、または環境問題が性能を抑制している可能性があります。結果を受け入れる前に調査してください。結果が推定値を超える場合、推定が最適化を見落としているか、測定が不正確 (例: 失敗を無視して成功したトランザクションのみ測定) の可能性があります。
説明できないベンチマーク結果を公表したり、それに基づいて行動したりしないでください。説明できない結果は、測定を無効にする設定ミスに起因する可能性があります。
調整と再実行
測定性能が推定値を下回る場合、システムが最適に設定されていない可能性があります。前のセクションで説明した設定プロパティを確認し、一度に1つのパラメータを調整し、各変更後にベンチマークを再実行してください。測定結果と推定値が収束するまでこのサイクルを繰り返してください。
一般的な調整アクションには以下があります:
- ScalarDB は楽観的並行性制御 (OCC) を使用するため、高競合ワークロード下で反復競合からの無駄な作業を削減するためにリトライバックオフ間隔を調整します。例えば、ScalarDB ベンチマークの TPC-C ワークロードはこの目的で
backoffパラメータを提供します。 - 高スループットワークロードで非同期コミットを有効にします。
- 高いコーディネーター書き込みトラフィックを持つワークロードでグループコミットを有効化・調整します。
- 並行性レベルに合わせて JDBC 接続プールサイズを調整します。
結果の分析
測定結果と推定値が一致すれば、結果が有効であることを確信できます。テストした各設定のスループット、レイテンシ分布 (p50、p95、p99)、エラー率を要約してください。ワークロードとシステムの理解を使用して、各設定がその結果を生成した理由を説明してください。元の目的に基づいて、要件に最も適したデプロイメント設定、リソースサイジング、またはシステム選択を決定してください。
次のステップ
- ScalarDB ベンチマークツール — すべてのワークロードパラメータを含む、公式 ScalarDB ベンチマークツールの完全リファレンス。
- ScalarDB Core の設定 — ScalarDB Core 設定プロパティの完全リスト。
- ScalarDB Cluster の設定 — クライアント側最適化を含むクラスター固有設定プロパティ。
- Consensus Commit プロトコル — ScalarDB がデータベース間で ACID トランザクションを実現する方法。
- マイクロサービスにおける ScalarDB Cluster のデプロイパターン — 共有対分離クラスターパターン。
- ScalarDB Cluster の制作チェックリスト — プロダクション向けリソースサイジングとデプロイメント推奨事項。