--- title: "ScalarDB Clusterとは｜異種DB横断ACIDの仕組みと3.20の変更点・Kubernetes導入" url: "https://www.issoh.co.jp/tech/details/11185/" published: 2026-03-03 updated: 2026-10-31 categories: ["データベース"] publisher: "株式会社一創" --- # ScalarDB Clusterとは｜異種DB横断ACIDの仕組みと3.20の変更点・Kubernetes導入 ScalarDB Clusterは、MySQLとCassandra、PostgreSQLとDynamoDBのように種類の違うデータベースをまたぐ処理を、1つのACIDトランザクションとして実行するミドルウェアです。オープンソースのScalarDB（Community版）をKubernetes上でクラスタ化した商用版で、Enterprise StandardとEnterprise Premiumの2エディションがあります。2026年10月30日公開の3.20では、3.19で非推奨になった2フェーズコミット（2PC）インターフェースがライブラリから消え、マイクロサービス間のトランザクションはTransaction CoordinatorとGlobal Transaction APIに一本化されました。本記事では、3.20のリリースノートとソースコード、公式ドキュメントをもとに、構成、エディション差、3.20へ上げるときに壊れる箇所、Kubernetesへの導入と本番の冗長化構成を整理します。 ## まとめ：ScalarDB Clusterの要点 - ScalarDB Clusterは、ScalarDBの機能を持つノード群をKubernetes上で動かす構成です。ノード間の振り分けにはコンシステントハッシュを使い、メンバー情報はKubernetes APIから取得します。本番はKubernetes前提で、開発・テスト用にはスタンドアロンモードがあります。 - 下位DBのトランザクション機能には頼らず、Consensus Commitというプロトコルで異種DB間のACIDを実現します。分離レベルの既定はSNAPSHOTで、SERIALIZABLEも選べます。 - Community版（Core）でもDB横断トランザクションは使えます。クラスタリングと認証・認可はEnterprise Standard以上、SQL・JDBC・Spring Data JDBC・GraphQLはEnterprise Premiumに限られます。 - 3.20で2PCインターフェースとjoin()・resume()が削除されました。3.19.2向けの2PCコードは3.20.0のjarに対してコンパイルが通りません。分離クラスタ型の構成は、Transaction CoordinatorとGlobal Transaction APIへ書き換えてから上げます。 - 本番の最小構成は、4vCPU・8GBメモリのワーカーノード3台にScalarDB ClusterのPodを3つ分散させる形です。ゾーン障害まで耐えるには、ノードを別々のアベイラビリティゾーンに置きます。 以下、構成とプロトコル、エディション、接続方式、3.20の変更、導入と本番構成の順に説明します。 ## ScalarDB Clusterの構成：ScalarDBをクラスタ化したgRPCサーバー ScalarDBには、ライブラリとしてアプリケーションに組み込むCoreと、サーバーとして動かすClusterがあります。Clusterの各ノードはCoreの機能をすべて持ち、アプリケーションからのリクエストをgRPCで受け付けます。クライアントSDKはJava版と.NET版があり、gRPCのprotoファイルからほかの言語のクライアントも生成できます（protoファイルはサポート窓口から入手します）。 Clusterが必要になる理由は、トランザクションの状態がサーバー側にあることです。複数のリクエストにまたがるトランザクションでは、同じトランザクションのリクエストをすべて同じノードで処理しなければなりません。ロードバランサーのセッションアフィニティで対処すると製品ごとに設定が変わるため、ScalarDB Clusterでは、リクエストを受けたノードがコンシステントハッシュで担当ノードを判定し、自分の担当でなければ正しいノードへ転送します。転送回数の上限は `scalar.db.cluster.hop_limit`（既定値3）です。ノードの参加と離脱はKubernetes APIで検知し、構成が自動で組み直されます。 | ポート | 用途 | 公開範囲 | | ----- | ----------------------------- | -------------- | | 60053 | Transaction API・SQL API・管理API | アプリケーションから | | 60054 | ノード間の内部gRPC通信 | ノード間のみ | | 5432 | PostgreSQLワイヤプロトコル（3.20〜） | 有効にした場合のみ | | 8080 | GraphQL | GraphQLを使う場合のみ | | 9080 | メトリクス（Prometheus） | 監視基盤から | 5432番は `scalar.db.postgres.port` の既定値で、`scalar.db.postgres.enabled=true` にしたときだけ開きます。Transaction Coordinatorを使う構成では、Coordinator側の60055番（クライアントの `contact_port` 既定値）も加わります。 ## Consensus Commitの仕組みと分離レベル ScalarDBのトランザクションは、XAのように下位DBのトランザクション機能を使うのではなく、ScalarDB自身が実装するConsensus Commitプロトコルで処理されます。並行制御は楽観的並行性制御（OCC）で、コミットは次の順で進みます。 1. 準備（prepare）：書き込むレコードを「準備済み」の状態で各DBへ書く。ほかのトランザクションと競合していれば、Coordinatorテーブルに ABORTED を書いて中断する。 2. 検証（validate）：分離レベルがSERIALIZABLEのときだけ、読んだレコードを読み直し、書き換えられていないかを確かめる。 3. コミット状態の確定：Coordinatorテーブルにトランザクションごとの COMMITTED レコードを書く。この書き込みが成功した時点でコミット済みになる。 4. レコードの確定：準備済みのレコードを COMMITTED に書き換え、ほかのトランザクションから見えるようにする。 競合の検出には、各DBが備える条件付き書き込みを線形化可能な形で使います。トランザクションのメタデータはアプリケーションのデータと同じテーブルに持つのが既定で、これが分散した先行書き込みログ（WAL）の役割を果たします。障害時にはCoordinatorテーブルの状態を見て、途中のトランザクションをロールバックまたはロールフォワードで復旧します。3.20では、連続するGet操作を並列にまとめて読む設定（`scalar.db.consensus_commit.parallel_batch_get.enabled`）が加わり、ロールバック対象のレコードも並列に読むようになりました。 | 分離レベル | 起こりうる異常 | 速度 | | --------------- | ---------------------------- | ---------------- | | SNAPSHOT（既定） | リードスキュー・ライトスキュー・読み取り専用異常 | SERIALIZABLEより速い | | SERIALIZABLE | 原則なし（非JDBCのパーティション横断スキャンは例外） | 検証処理の負荷あり | | READ\_COMMITTED | SNAPSHOTと同じ＋最新でない値を返すことがある | 最も速い | 既定のSNAPSHOTは、ドキュメント上は「読み取りコミット・スナップショット分離（スナップショット分離の弱い変種）」と説明されています。残高チェックのように、読んだ値を条件に別のレコードを更新する処理ではライトスキューが起きうるため、SERIALIZABLEを選びます。プロトコルの正しさは、GitHubの `tla+/consensus-commit` にあるTLA+の形式仕様と、`scalar-labs/scalar-jepsen` の障害注入テストで検証されています。 ## 対応データベースとエディション別の機能 ### 3.20で使える下位データベース ClusterはCoreを通じてデータベースにアクセスするため、対応DBはCoreと同じです。2026年10月31日時点の公式[ScalarDB Requirements](https://scalardb.scalar-labs.com/docs/latest/requirements/)は3.19までの表で、そこに[3.20.0のリリースノート](https://github.com/scalar-labs/scalardb/releases/tag/v3.20.0)の変更（SQL Server 2025の追加と2017の削除。同日公開の3.19.2にも同じ変更が入っています）を反映すると次のとおりです。 | 分類 | データベース（対応バージョン） | | ----------- | -------------------------------------------------------- | | RDB | PostgreSQL 13〜17、MySQL 8.0・8.4、Oracle 19c・21c・23ai | | RDB | SQL Server 2019・2022・2025、MariaDB 10.11・11.4 | | RDB | Db2 11.5・12.1、SQLite 3 | | NewSQL | Aurora MySQL 2・3、Aurora PostgreSQL 13〜17、AlloyDB 15・16 | | NewSQL | TiDB 6.5・7.5・8.5、YugabyteDB 2025.2、Spanner（PostgreSQL方言） | | NoSQL | DynamoDB、Cassandra 3.0・3.11・4.1・5.0、Cosmos DB for NoSQL | | オブジェクトストレージ | S3、Azure Blob Storage、Cloud Storage（Private Preview） | Db2はLinux・UNIX・Windows版のみで、z/OS版には対応していません。組み合わせるDBのどれか1つにCoordinatorテーブルを置きます。3.19.1からは、Aurora PostgreSQLとAurora MySQLの高速フェイルオーバーのためにAWS Advanced JDBC Wrapperにも対応しています。Cassandraのデータモデル自体は[Cassandraの仕組みとデータモデル](/tech/details/15868/)で解説しています。 ### Community・Enterprise Standard・Enterprise Premiumの機能差 | 機能 | Community（Core） | Standard | Premium | | ------------------------------- | --------------- | --------- | ----------------- | | DB横断トランザクション | ○ | ○ | ○ | | クラスタリング | － | ○ | ○ | | 認証・認可 | － | ○ | ○ | | 非トランザクションのストレージ操作 | － | ○（3.14以降） | ○（3.14以降） | | 保存データの列単位暗号化 | － | － | ○（3.14以降） | | SQL（JDBC・Spring Data JDBC・LINQ） | － | － | ○ | | GraphQL | － | － | ○ | | ベクトル検索 | － | － | ○（Public Preview） | | リモートレプリケーション | － | － | ○（Public Preview） | 判断を分けるのはSQLが必要かどうかです。既存のJavaアプリケーションをJDBCやSpring Data JDBC経由で動かしたいならPremiumが前提になります。CRUD APIで実装でき、暗号化などPremium限定の機能が要らないならStandardで足ります。属性ベースのアクセス制御（Public Preview）は別途のオプション契約です。CoreはApache License 2.0で公開されています。 ## クライアントの接続方式：direct-kubernetes・indirect・PostgreSQLワイヤプロトコル ### Javaクライアントのdirect-kubernetesとindirect Javaのクライアントライブラリには、direct-kubernetesとindirectの2つの接続モードがあります。公式の本番チェックリストは、性能面からdirect-kubernetesを推奨しています。 - direct-kubernetes：アプリケーションのPodをScalarDB Clusterと同じKubernetesクラスタに置き、クライアントがメンバー情報を読んで担当ノードへ直接つなぐ。Envoyは不要だが、エンドポイントを読むためのRole・RoleBinding・ServiceAccountを用意する。 - indirect：クラスタの外のアプリケーションから、Envoyのロードバランサー経由でつなぐ。Java以外の言語でgRPC APIを直接使う場合もEnvoyが必要になる。 ``` # direct-kubernetes モード（名前空間 ns のエンドポイント scalardb-cluster を参照） scalar.db.transaction_manager=cluster scalar.db.contact_points=direct-kubernetes:ns/scalardb-cluster # indirect モード（Envoy のロードバランサーの IP アドレスを指定） # scalar.db.contact_points=indirect:192.168.10.1 ``` 本番では、CRUD APIなら `scalar.db.transaction_manager=cluster`、SQL APIなら `scalar.db.sql.connection_mode=cluster` になっているかを確認します。3.20では内部用だった `singleton:` の接続先指定（SINGLETONモード）が削除されました。また、direct-kubernetesのクライアントを閉じてもスレッドとKubernetes APIサーバーへの接続が残る不具合が、3.19.2と3.20で直っています。クライアントを作っては閉じる処理（JDBCドライバー経由を含む）で、いずれ新しいスレッドを作れなくなる症状が出ていたなら、このどちらかへ上げます。 ### PostgreSQLワイヤプロトコルでの接続（3.20） 3.20から、ScalarDB ClusterのノードがPostgreSQLのワイヤプロトコルを話せるようになりました。psql、PostgreSQL JDBCドライバー、そのほかのPostgreSQL用ツールから、ScalarDB Clusterに対してSQLを実行できます。ScalarDB専用のJDBCドライバーやSDKを入れられないツール（BIツールや運用スクリプト）を接続したい場面で効きます。 ``` # ScalarDB Cluster ノードのプロパティ scalar.db.postgres.enabled=true scalar.db.postgres.port=5432 # userpass（パスワードのみ）か oidc_jwt（OIDCアクセストークンのみ）に絞れる scalar.db.postgres.auth=userpass ``` 認証を有効にしたクラスタでは、クライアントはScalarDB Clusterのユーザーとしてログインし、パスワードかOIDCアクセストークン（パスワード欄に入れる）を使います。権限はほかのクライアントと同じく検査され、接続には既定でTLSが必須です。証明書を個別に指定しなければ、ノードのTLS証明書と秘密鍵が使われます。対応しないSQL構文やPostgreSQL固有機能の一覧は、2026年10月31日時点の公式ドキュメントでは確認できませんでした。既存のPostgreSQL向けクエリをそのまま流す前に、検証環境で通るかを確かめてください。 ## 3.20で変わった点とアップグレードの確認項目 ### 2PCインターフェースの削除とGlobal Transaction APIへの一本化 マイクロサービスでScalarDB Clusterを使う構成には、すべてのサービスが1つのClusterを共有する共有クラスタ型と、サービスごとにClusterを持つ分離クラスタ型があります。分離クラスタ型では、各サービスが prepare を呼び、全員の成功を確かめてから commit する2PCインターフェースをアプリケーションで実装していました。 このインターフェースは3.19で非推奨になり、3.20で消えました。[3.20.0のリリースノート](https://github.com/scalar-labs/scalardb/releases/tag/v3.20.0)は概要で「レガシーなトランザクションAPIの削除」とまとめ、個別項目にはjoin()・resume()やGraphQLの2PC（`@twoPhaseCommit` ディレクティブと prepare・validate・commit のミューテーション）の削除が並びます。2PCインターフェース本体の削除は個別項目に書かれていませんが、Maven Centralの3.20.0のjarには `TwoPhaseCommitTransactionManager` と `TransactionFactory.getTwoPhaseCommitTransactionManager()` がありません。2026年10月31日に、このメソッドを呼ぶだけのコードをコンパイルしたところ、3.19.2のjarでは非推奨の注意だけで通り、3.20.0のjarでは「cannot find symbol」の3件のエラーで止まりました。Cluster Java Client SDKの3.20.0からも、`ClusterClientTwoPhaseCommitTransactionManager` と `ClusterClientSqlTwoPhaseCommitTransactionManager` が消えています。 これから設計する場合は、まず共有クラスタ型で要件を満たせるかを確かめます。公式ドキュメントはもともと「可能な限り共有クラスタ型を使う」としており、Clusterは重要な状態をメモリに持たないため、共有してもサービスごとのDB分割の原則から大きくは外れません。クラスタを分ける必要があるときは、次のTransaction Coordinatorを使います。 ### Transaction CoordinatorとGlobal Transaction APIの実装 Transaction Coordinator（3.19.0で追加）は独立したプロセスとして動き、アプリケーションに代わって複数のClusterに対する2PCを進めます。アプリケーション側は `GlobalTransactionManager` を使います。起点のサービスが `begin()` でグローバルトランザクションを開始してIDをほかのサービスへ渡し、各サービスはそのIDで `beginBranch()` を呼んで担当分のCRUDを実行し、`end(Status)` で結果を宣言します。起点のサービスは、すべてのブランチが SUCCESS で終わったことを確かめてから `commit()` を呼びます。 次のコードは、注文サービスが決済サービスを呼び出してコミットするまでの抜粋です（import、メソッド宣言、orderId・customerId・amount・customerの定義は省略）。[BranchTransaction.java（v3.20.0）](https://github.com/scalar-labs/scalardb/blob/v3.20.0/core/src/main/java/com/scalar/db/api/BranchTransaction.java)のJavadocが示す形に合わせており、scalardb 3.20.0のjarに対してコンパイルが通ることを確認しています（クラスタ上での実行はしていません）。 ``` TransactionFactory factory = TransactionFactory.create("scalardb-client.properties"); GlobalTransactionManager manager = factory.getGlobalTransactionManager(); GlobalTransaction global = manager.begin(); BranchTransaction branch = null; try { branch = manager.beginBranch(global.getId()); branch.insert(Insert.newBuilder() .namespace("order_service").table("orders") .partitionKey(Key.ofText("order_id", orderId)) .intValue("amount", amount) .build()); branch.end(BranchTransaction.Status.SUCCESS); // 決済サービスは同じIDで beginBranch し、処理後に end(SUCCESS) してから応答する customer.pay(global.getId(), customerId, amount); global.commit(); // managerはアプリケーション終了時に manager.close() で閉じる } catch (Exception e) { // 3.20では、SUCCESS宣言後のFAILURE宣言とcommit後のrollbackは何もしない if (branch != null) { try { branch.end(BranchTransaction.Status.FAILURE); } catch (RuntimeException | CrudException suppressed) { e.addSuppressed(suppressed); } } try { global.rollback(); } catch (RollbackException suppressed) { e.addSuppressed(suppressed); } // UnknownTransactionStatusExceptionなら結果は未確定。結果を確かめるまで再試行しない throw e; } ``` 3.20では、`commit()` が成功しても失敗してもトランザクションはそこで終わり、その後の `rollback()` は何もしません。そのため、失敗時の後始末を1つの catch にまとめられます。注意点は、[GlobalTransaction.java（v3.20.0）](https://github.com/scalar-labs/scalardb/blob/v3.20.0/core/src/main/java/com/scalar/db/api/GlobalTransaction.java)のJavadocにあるとおり「すべてのブランチが SUCCESS で終わるまで commit() しない」を強制する仕組みが無いことです。処理中のブランチがあるままコミットすると、その途中までの書き込みがコミットされる可能性があります。 クライアント側では、Transaction Coordinatorへトランザクション制御を送る設定を有効にします。 ``` scalar.db.transaction_manager=cluster scalar.db.contact_points=indirect:order-cluster scalar.db.cluster.id=order-cluster scalar.db.cluster.client.transaction_coordinator.enabled=true scalar.db.cluster.client.transaction_coordinator.contact_points=indirect:transaction-coordinator ``` 参加する側のClusterノードでは `scalar.db.cluster.node.transaction_participant.enabled=true` と `scalar.db.cluster.id` を、Transaction Coordinator側では対象のClusterを `scalar.db.cluster.transaction_coordinator.clusters` に列挙します。`transaction_coordinator.enabled` を false に戻すと、同じアプリケーションコードが1つのCluster内のトランザクションとして動くので、共有クラスタ型と分離クラスタ型を設定だけで切り替えられます。 ### SQLのグローバルトランザクション（GLOBAL\_TRANSACTIONモード） 3.19のGlobal Transaction APIはCRUD API向けでしたが、3.20でScalarDB SQLにも同じ仕組みが入りました。`SqlSession` とJDBCドライバーに `GLOBAL_TRANSACTION` モードが加わり、あるプロセスが開始したグローバルトランザクションに対して、各プロセスが `BEGIN BRANCH` と `END BRANCH` でブランチを実行します。Transaction Coordinator側で `scalar.db.sql.enabled=true` にすると、CoordinatorがSQLのトランザクションについても複数Clusterの2PCを進めます。CRUD APIと同じく、同じアプリケーションコードが設定次第で1つのCluster内のトランザクションとしても動きます。SQLの構文の詳細（ブランチの終了状態の書き方など）は、2026年10月31日時点の公式ドキュメントでは確認できず、本記事ではリリースノートの説明までにとどめます。 ### 3.19から3.20へ上げる前の確認項目 リリースノートとjarの差分から、アップグレードで動作やビルドが変わる箇所を抜き出すと次のとおりです。SQL Server 2017の削除とJava 21化は3.19.2にも入っているため、3.19.0・3.19.1から上げる場合に関係します。 | 変更 | 影響する使い方 | 対応 | | -------------------------- | ------------------------------- | ----------------------- | | 2PCインターフェース削除 | 分離クラスタ型の2PC実装 | Global Transaction APIへ | | join()・resume()削除 | 1つのトランザクションの再開 | Global Transaction APIへ | | SQLのJOIN・SUSPEND・RESUME文削除 | SQLでの中断・再開 | GLOBAL\_TRANSACTIONモードへ | | GraphQLの2PC削除 | @twoPhaseCommit | @transactionへ | | 設定名の変更 | active\_transaction\_management | two\_phase\_commit.を付ける | | 失効時間の既定値 | \-1から60000ミリ秒へ | 必要なら値を明示 | | トランザクション中のDDL・DCL | ScalarDB SQL | commit後に実行 | | SQL Server 2017 | 下位DB | 2019以降へ | | Schema LoaderなどのJava 21化 | Java 8専用のJVMオプション | オプションを外す | 設定名は、`scalar.db.active_transaction_management.enabled` が `scalar.db.two_phase_commit.active_transaction_management.enabled` になり、2PCのコーディネーターと参加者にだけ効くようになりました。`scalar.db.active_transaction_management.expiration_time_millis` の既定値は -1 から 60000 に変わりました。長い時間開いたままにするトランザクションがある処理は、上げる前にこの値を明示しておきます。Spring Data連携の `ScalarDbRepositoryImpl` から begin()・commit()・rollback() などが外れた点と、`BranchTransaction.getId()` がブランチ自身のIDを返すようになった点（グローバルトランザクションのIDは `getGlobalTransactionId()`）も、コンパイルや動作に影響します。 ## KubernetesへのHelm導入手順 公式のHelm Chartは `scalar-labs/scalardb-cluster` です。2026年10月30日公開のChart 1.13.0がScalarDB 3.20.0に対応しています（appVersion 3.20.0）。ローカルのKubernetesで試す流れは次のとおりです。 1. 下位DB（例：PostgreSQL）をHelmで起動する。 2. `helm repo add scalar-labs https://scalar-labs.github.io/helm-charts` でリポジトリを登録する。 3. DBの認証情報とライセンスキーを `kubectl create secret generic` でSecretに入れる。 4. カスタム値ファイルを保存し、`helm install scalardb-cluster scalar-labs/scalardb-cluster -f scalardb-cluster-custom-values.yaml --version 1.13.0 -n default` を実行する。 5. `kubectl get pod` でノードとEnvoyのPodがそれぞれ3つずつ Running になったことを確かめ、`kubectl get svc` でEnvoyの外部IPを確認する。 カスタム値ファイルの中心はノードのプロパティです。公式チュートリアルの値ファイルから、ストレージとライセンスの設定を抜き出すと次のようになります。 ``` envoy: enabled: true service: type: "LoadBalancer" scalardbCluster: image: repository: "ghcr.io/scalar-labs/scalardb-cluster-node-byol-premium" scalardbClusterNodeProperties: | scalar.db.cluster.membership.type=KUBERNETES scalar.db.cluster.membership.kubernetes.endpoint.namespace_name=${env:SCALAR_DB_CLUSTER_MEMBERSHIP_KUBERNETES_ENDPOINT_NAMESPACE_NAME} scalar.db.cluster.membership.kubernetes.endpoint.name=${env:SCALAR_DB_CLUSTER_MEMBERSHIP_KUBERNETES_ENDPOINT_NAME} scalar.db.storage=jdbc scalar.db.contact_points=jdbc:postgresql://postgresql-scalardb-cluster.default.svc.cluster.local:5432/postgres scalar.db.username=${env:SCALAR_DB_CLUSTER_POSTGRES_USERNAME} scalar.db.password=${env:SCALAR_DB_CLUSTER_POSTGRES_PASSWORD} scalar.db.cluster.node.licensing.license_key=${env:SCALAR_DB_CLUSTER_LICENSE_KEY} scalar.db.cluster.node.licensing.license_check_cert_pem=${env:SCALAR_DB_CLUSTER_LICENSE_CHECK_CERT_PEM} secretName: "scalardb-credentials-secret" ``` イメージ名の byol-premium は、ライセンスキーを自分で持ち込むPremium版を表します。アプリケーションをdirect-kubernetesモードで動かす場合は、クライアントのServiceAccountにエンドポイントの get・watch・list を許可するRoleを割り当てます。Kubernetesのリソースとエンドポイントの関係は[Kubernetes APIの仕組みとリソース構造](/tech/details/9733/)で解説しています。 ## 本番構成の冗長化・リソース・費用 ### 冗長化の構成：Pod・ノード・ゾーンの3段 ScalarDB Clusterの冗長化は、どの単位の障害に耐えるかで3段に分かれます。[公式の本番チェックリスト](https://github.com/scalar-labs/docs-scalardb/blob/main/docs/scalar-kubernetes/ProductionChecklistForScalarDBCluster.mdx)の最小構成は、ワーカーノード3台以上にScalarDB ClusterのPodを3つ以上分散させる形です。 - Pod単位：Podを3つ以上動かす。障害後はメンバー情報の更新で残りのノードへ振り分けられる。ただし、処理中のトランザクションがそのまま継続する保証はなく、エラーに応じた再試行やコミット結果の確認が必要になる。 - ノード単位：`podAntiAffinity` で同じワーカーノードにPodが偏らないようにする。 - ゾーン単位：ワーカーノードを別々のアベイラビリティゾーンに置き、ゾーン障害でもPodが残るようにする。 Clusterのノードは重要な状態を永続化しないため、データの冗長化は下位DB側の責任です。下位DBでは自動バックアップとポイントインタイムリカバリ（PITR）を有効にします。ClusterはScalar Adminのインターフェースを実装しており、一時停止してトランザクション整合性のあるバックアップを取れます。Clusterはインターネットに直接サービスを出さないため、プライベートネットワークに置きます。 ### ノードのサイズとPAYGのリソース上限 BYOLコンテナのPodには2vCPU・4GBメモリ以上を割り当てます。同じノードにEnvoy・アプリケーション・監視のPodも載るため、ワーカーノードは4vCPU・8GBメモリ以上を3台が最小です。HPAでPodを自動で増やす場合は、上限のPod数からノードの大きさを逆算します。 2vCPU・4GBの扱いは、ライセンスの持ち込み方で変わります。BYOLでは推奨値ですが、AWS Marketplaceの従量課金（PAYG）コンテナでは `resources.limits` の上限で、これを超える値を設定したPodは自動で停止します。PAYGで処理能力を上げるには、Podを大きくせずPodの数を増やします。 ``` scalardbCluster: resources: requests: cpu: 2000m memory: 4Gi limits: cpu: 2000m memory: 4Gi ``` ### ScalarDB ClusterのPAYG料金とバージョン別保守期限 AWS Marketplaceの[Enterprise Standard（従量課金）](https://aws.amazon.com/marketplace/pp/prodview-jx6qxatkxuwm4)と[Enterprise Premium（従量課金）](https://aws.amazon.com/marketplace/pp/prodview-djqw3zk6dwyk6)のリスティングでは、2026年10月31日時点でStandardが1ユニットあたり1.40ドル、Premiumが2.79ドルです。[Scalarの料金ページ](https://www.scalar-labs.com/pricing)はこれを1時間あたりの価格として表示しています。同じページの注記では、2vCPU・4GBメモリのPod 1つを1ユニットと数えます。最小構成のPod 3つなら、ライセンス分だけでStandardが1時間4.20ドル、Premiumが8.37ドルです。Google Cloudでの価格はStandardが1時間1.50ドル、Premiumが2.89ドルと表示されています。インフラ費用は別にかかり、BYOLの価格は販売元への問い合わせになります。既存のRDBとNoSQLをどう組み合わせて載せるかの設計から相談したい場合は、[データベース設計・移行支援](/service/system/database/)で対応しています。 保守期限は[公式のリリースサポートポリシー](https://github.com/scalar-labs/docs-scalardb/blob/main/docs/releases/release-support-policy.mdx)で確認します。2026年10月31日時点の表では、3.20は「TBD」（次のマイナーバージョンが出たときに確定）、3.18はメンテナンスサポートが2027年8月2日まで、3.17は2027年5月1日まで、3.16は2026年11月26日までです。3.19のメンテナンスサポート終了日は2026年10月30日、アシスタンスサポート終了日は2027年4月28日と書かれています。3.19だけが前の版より早く終わる表記になっているため、3.19で運用中なら保守の残り期間を契約窓口で確認したうえで、3.20への移行計画を立ててください。 ## ScalarDB Clusterを採用すべきでないケース ScalarDB Clusterは、異種DBをまたぐ強い整合性が必須の場面で効く製品です。次の条件に当てはまるなら、別の手段を先に検討すべきです。 - 単一DBのローカルトランザクションで足りる：DB自体のトランザクションで済むなら、Consensus Commitのメタデータ書き込みとgRPCの往復は余分なコストになる。1つのDBで水平スケールが必要なら、[CockroachDBのような分散SQL](/tech/details/16002/)や[MySQL互換のTiDB](/tech/details/16005/)の方が構成は単純になる。 - 結果整合性で業務が成り立つ：在庫の引当や通知のように、一時的な不整合を補償処理で戻せるなら、[Sagaパターンと補償トランザクション](/tech/details/16175/)で足り、商用ライセンスとKubernetesの運用を背負う理由は弱い。DB更新とイベント発行の不一致には[Outboxパターン](/tech/details/16177/)を組み合わせる。 - Kubernetesを運用できない：本番のクラスタ構成はKubernetes前提で、この製品のためだけに導入するのは負担が大きい。その場合は、Community版のCoreをライブラリとして組み込み、1つのプロセス内で完結する範囲に絞る選択肢がある。 - 2PCインターフェースのまま当面動かしたい：3.20で削除されたため、3.19に留まると保守期限の制約を受ける。書き換えの工数を確保できないなら、移行計画が立つまで新規の分離クラスタ型を増やさない。 逆に、既存のRDBとNoSQLを載せ替えず、対象データへのアクセスをScalarDB経由にそろえたうえで両者をまたぐ更新をACIDで行いたい、しかもアプリケーションに補償処理を書きたくない、という条件がそろうなら有力な選択肢になります。トランザクションと分離レベルの基本は[トランザクションとACID・分離レベルの解説](/tech/details/13690/)で整理しています。 ## よくある質問 ### ScalarDB Clusterとは何ですか？ オープンソースのScalarDBを、Kubernetes上で複数ノードのサーバーとして動かす商用版です。種類の違うデータベースをまたぐ処理を1つのACIDトランザクションとして実行でき、ノード間の振り分けを自動で行います。Enterprise StandardとEnterprise Premiumの2エディションがあります。 ### ScalarDB CoreとScalarDB Clusterの違いは何ですか？ CoreはApache License 2.0のOSSで、アプリケーションにライブラリとして組み込んで使います。ClusterはCoreの機能をgRPCサーバーとしてクラスタ化したもので、リクエストの振り分けと認証・認可を備えます。SQLやGraphQLはClusterのPremium版でのみ使えます。 ### ScalarDB Clusterの最新バージョンはいくつですか？ 2026年10月31日時点の最新は3.20.0（2026年10月30日公開）で、対応するHelm Chartは1.13.0です。同じ日に3.19.2・3.18.3・3.17.6・3.16.8の修正版も出ています。 ### ScalarDB Clusterの価格はいくらですか？ AWS Marketplaceの従量課金版では、2026年10月31日時点でEnterprise Standardが1ユニット1時間1.40ドル、Enterprise Premiumが2.79ドルです。1ユニットは2vCPU・4GBメモリのPod 1つで、最小構成の3 Podならライセンス分はStandardで1時間4.20ドルになります。インフラ費用は別で、従量課金版のPodは2vCPU・4GBメモリを超えて割り当てられません。 ### 2フェーズコミットのインターフェースは使えなくなりましたか？ 3.19で非推奨になり、3.20.0のライブラリからは消えています。3.19.2向けに書いた2PCのコードは3.20.0ではコンパイルできないため、共有クラスタ型の1フェーズコミットか、Transaction CoordinatorとGlobal Transaction APIを使う構成へ書き換えてから上げます。 ## 関連記事 - [Sagaパターンとは？補償トランザクション設計と実装方式の選び方を解説【2026年版】](/tech/details/16175/) - [トランザクションとは？分離レベルの違い・ACID・commit/rollbackを実装目線で解説【2026年版】](/tech/details/13690/) - [CockroachDBとは？分散SQLの仕組み・ライセンス変更と採用判断を実装者目線で解説](/tech/details/16002/) - [TiDBとは：MySQL互換の分散SQLの仕組みとHTAP・検証手順・採用判断を解説](/tech/details/16005/) - [Outboxパターンとは？DB更新とイベント発行を一致させる実装方式を解説【2026年版】](/tech/details/16177/) --- 出典: [ScalarDB Clusterとは｜異種DB横断ACIDの仕組みと3.20の変更点・Kubernetes導入]()（株式会社一創）