企業やサービスをつなぐ分散トランザクションマネージャを目指して：マイクロサービス構築の課題「分散トランザクション管理」とは？ Scalarに聞いた
マイクロサービスアーキテクチャが注目される一方、課題として浮き彫りになっているのが「分散トランザクション管理」です。「分散トランザクション」とは何か、どのような解決策があるのか、分散トランザクションマネジャーを提供するScalerへのインタビューを交えながら紹介します。
本連載第5回では、年次イベントのレポートやインタビューを通じて分散SQLデータベース（DB）であるYugabyteDBの解説を試みました。分散SQLDBのメリットは理解できるものの「今の現場や会社に、分散DBが必要なのか分からない」という意見も頂きました。
今回は現在トレンドとなっているマイクロサービスを検討していく上で課題となる分散トランザクションについて、国内で数少ない専業ベンダーであるScalarの代表取締役CEO兼CTO（最高技術責任者）の山田浩之氏に話を伺いました。
古くて新しい分散トランザクションの問題
過去の連載記事でも取り上げたように、クラウドネイティブなシステムの要素として注目されるマイクロサービスアーキテクチャ（MSA）は、DBに見逃しがたい変化をもたらします。そこでは「Database per Service」の原則に従い、サービス一つ一つが分割されたDBを持ちます。そのため、サービスをまたがるトランザクションはローカルなDBMSの境界を越えて実現する必要があり、それがMSAの難しさの一つとなっています。
では、個々のDBMSの境界を越えた分散トランザクションは、MSAと同時に発生した新しい課題なのでしょうか？
多くの読者の方々がご存じのように、そうではありません。それはTPモニターなど（参考記事）に見られるように、システム間をつなぐ技術として長く発展してきた製品が解こうとしていた課題と重なります。
一方、DBに分散トランザクションのコーディネーターを内包する動きも見られます。それが第3回で紹介したTiDBや、第5回で紹介したYugabyteDBといったDBです。これらのDBはアプリケーション側にデータの整合性保証を押し付けず、拡張性も高いRDBを実現しようとしています。
分散DBに内包されたコーディネーターと、本記事のテーマである分散トランザクションマネジャーの構成を比較すると下図のようになります。
（B）では分散トランザクションの管理がDBから切り離され、その結果として、異なるDB間（RDBとKVS）でトランザクションを実行できる構成になっていることが分かります。
Scalar DBとは
Scalarが提供するScalar DBは、まさに上図のパターン（B）を実現する分散トランザクションマネジャーです。
ScalarではScalar DBをオープンソースソフトウェア（OSS）として公開しApache License2.0と商用ライセンスで提供しています。同社の山田氏にScalar DBの利用目的や開発のいきさつを伺いました。
マイクロサービスに対応したScalar DB
小林 2021年9月に「Scalar DBのマイクロサービス向けトランザクション管理機能」が発表されました。この管理機能はどのような利用を想定したものなのでしょうか。
山田 管理機能はScalar DBのバージョン3.2で実現したものです。もともとScalar DBは、企業内や企業間で使われる多様なDB上でトランザクションを管理することを目的としていました。しかし、昨今トレンドとなっているマイクロサービスでも同技術は適用可能と考え、サービスにまたがるACID（Atomicity《原子性》、Consistency《一貫性》、Isolation《独立性》、Durability《永続性》）トランザクション機能を提供するに至りました。
小林 マイクロサービスの場合、DBが分かれていることを前提にSagaパターンやTCCパターンなどで分散トランザクションを実現しようとする試みが見られます。それらのアプローチとScalar DBの違いはどこにあるのでしょうか。
山田 はい、SagaパターンやTCCパターンで複雑なシステムを運用している例も聞いています。ただ開発難度が高く、リカバリーを必要とするケースがあるため、DevOpsを実現している体力のある企業でないと採用しづらい印象です。Scalar DBはエンタープライズ向けの開発現場において、Sagaよりも容易に分散トランザクションを実装可能です。
小林 類似のソフトウェアにはどのようなものがあるでしょうか。役割的にはミドルウェアと言い換えてもよいかも知れませんが。
山田 そうですね、まず小林さんとお話したことのあるApache ShardingSphereがあります。これはShardingと名前にある通り、既存のRDBMSを水平にスケールさせることを目的としたソフトウェアです。分散トランザクションも実装されています。またSeataというプロジェクトもあります。こちらは明確にマイクロサービスをターゲットにした分散トランザクションソリューションです。
小林 ShardingSphereはコミュニティーの活動も活発で、個人的にも注目しているプロジェクトの一つです。ただ、分散トランザクションなどのDBを補完するミドルウェアは知名度ではまだまだな点があります。
山田 おっしゃる通りです。われわれのScalar DBを顧客に説明する際は「現代版のTuxedo」という言い方をすることもあります。
小林 エンタープライズで古くからDBに関する課題に悩むお客さまにとっては、その言い方だと理解しやすいかも知れませんね。
Scalar DB開発のいきさつ
小林 エンジニアとして気になる部分ですが、Scalar DBはどのように開発されてきたのでしょうか。
山田 「Scalable distributed transactions across heterogeneous stores」という論文に着想を得ています。これは複数のデータストアにまたがる分散トランザクションの手法を提案しています。この手法では、データストアの外側で、多くのデータストアが持つ機能だけを用いてトランザクションを実現する点に特徴があります。
小林 ScalarではCassandraコミュニティーへの貢献も多く見られますが、Scalar DBでCassandra向けの対応が進んでいるのはどういった背景でしょうか。
山田 Cassandraを最初に選んだのは、スケーラブルで使いやすい分散DBとして開発当初に適当だったためです。当時は他にHBaseなどもありましたが、Cassandraの方がより知見がありました。
小林 TiDBを開発したPingCAP（参考記事）ではHBaseをベースにしようとしたという話がありましたが、同じころの話なのでしょうか。
山田 はい、その後は他のデータストアおよびDBMSの対応を進めています。またインタフェースとしてもGraphQLにScalar DBバージョン3.5で対応しました。今後もそうした対応を進め、Scalar DBがさまざまな環境で利用しやすいようにしていきます。
小林 これからもリリース情報には注目ですね。ありがとうございました。
まとめ
今回は国内で分散トランザクションマネジャーのScalar DBを開発、提供しているScalarに話を伺いました。
古くからシステム間の連携として使われてきた分散トランザクション管理は、マイクロサービスのトレンドの中にあっても引き続き重要な技術です。複数のデータストアやサービス間でそれを実現するScalar DBは、現在注目されている分散SQLDBにも解決できない課題を解く可能性があるといえそうです。
Copyright © ITmedia, Inc. All Rights Reserved.