トランザクションの実装にはRDB/NoSQLにかかわらず教科書的な定番がある～業務システムをRDBなしで作れるのか？（前編） エンジニアサポートCROSS 2016

数年前にNoSQLが登場した当時、NoSQLにはデータの一貫性を保証してくれるトランザクション機能などが十分に備わっていないため、業務システムのバックエンドとして使うのは容易ではないと考えられていました。

しかしその後、NoSQLをバックエンドにした業務アプリケーションは現実にはいくつか登場してきています。ワークスアプリケーションズが2014年に発表したERPの「HUE」もCassandraをバックエンドに採用した、本格的な業務アプリケーションです。

そのHUEの開発に関わるスタッフが、どういう実装ならばNoSQLが業務アプリケーションのバックエンドに使えるのか、それにはどういう意味があるのか、などについて議論したセッション「業務システムをRDBなしで作れるのか?」が2月に横浜で開催されたイベント「エンジニアサポートCROSS 2016」で行われました。

セッションでは、アプリケーションレベルでのトランザクション管理や分散データベースにおけるデータの一貫性についてなど、技術的に興味深い議論がなされました。本記事ではその内容のダイジェストを次の3本の記事で紹介します。

前編：トランザクションの実装にはRDB/NoSQLにかかわらず教科書的な定番がある
中編：アプリケーションのレベルでこそ要求に合ったトランザクションが実装できる
後編：同時実行性制御をアプリケーションで解決しようとすると深刻な問題が発生する

いまお読みの記事は前編です。

業務システムをRDBなしで作れるのか？

ワークスアプリケーションズ 井上誠一郎氏

私は以前、Lotus Notesの開発をしていました、Notesはドキュメント型の分散データベースで非同期のレプリケーションというアーキテクチャで、今のCouchDBに近い仕組みです。

NoSQLが業務で使えるということを、Notesはもう実証していたと思います。ただ、Notesは同時実行性制御でコンフリクトを起こしたときにユーザーに直してもらうという割り切った実装にしていました。それでも申請系などのアプリは作れています。データモデルをどう設計するかと言うときに、ユーザー単位や業務単位でデータをシェアしないようになっていればコンフリクトは起きないので、データモデルの設計で対応できるという一例かと思います。

ワークスアプリケーションズ 堤勇人氏。

堤と申します。現在はHUEのバックエンド周り、Cassandraからクラウドの運用まで一通り関わっています。

今回は、アプリケーションでNoSQL特有の問題などを解決していこうというアプリケーション実践者の立場で話をしていきます。ただ、いつもこういうことを言っているわけではなくて、あくまで今回の役割ということです（笑）。

ワークスアプリケーションズ 劉雨氏。

劉と申します。私は2004年に大学を卒業し、分散ジョブ管理システム、ワークフローみたいな製品の開発を日系の会社でしていて、2006年末に日本に来ました。2009年に国立情報学研究所に入り、並列プログラミングの研究で2014年に博士号を取りました。

ワークスアプリケーションズには2014年に入社して、分散プラットフォームの研究や分散データベースなどの研究をしています。

NoSQLとRDBをめぐるキーワード

井上氏。

まずはNoSQLをめぐるキーワードについて整理しておきましょう。

データベースを「データモデル」「クエリ言語」「トランザクション管理」の観点で眺めてみると、RDBはデータモデルがリレーショナルでクエリ言語はSQL、そしてトランザクションを備えています。

一方で、多くのNoSQLではこのうちのどれかが異なると。

「ストレージモデル」と「ネットワークモデル」。ストレージモデルでは、ローストアかカラムストアか、それ以外か。ネットワークモデルでは分散か非分散か、そしてレプリケーションが同期なのか非同期なのか、マスター／スレーブなのか、マスター／マスターなのか。

NoSQLではだいたい、データモデルがリレーショナルではなくてネットワークモデルが分散型になるのかなと思うので、今日もだいたいそれを前提に話をしていきます。

トランザクション管理の技術

NoSQLで論点になりやすいのはトランザクション管理の部分で、みなさんも気になると思います。データベースにおけるトランザクション管理は「障害時の回復」と「同時実行性制御」の技術です。

これらはRDBだけが備えているのではなくて、NoSQLでも必要に応じて備えています。

障害時回復とは、ネットワークとかシステムに問題が起きたときに、問題が起きてない状態までデータを戻したい、というのが問題領域で、解決手段としてよく使われるのがログ法とシャドーページングです。

ログ法はいったんストレージなどの永続的なところに正しい単位でデータを書き出しておいて、それが消えない前提でコミットが完了。なにか問題があったらアンドゥという形でロールバックするか、リドゥとしてロールフォワードをして、最終的に正しい状態に戻します。

RDBではこの実装が多いと思います。

シャドーページングは、いまあるデータを書き換える代わりに新しい場所に書いて、書いている途中で問題が起きたらそこは全部捨てて、正しく書き終えたら新しい場所に切り替えましょう、というものです。

もう1つ、同時実行性制御。トランザクションというとこちらを思い浮かべる方が多いかもしれません。

これにもそんなに手段があるわけじゃなくて、主に静的に依存性解析をして矛盾があったらアボートしましょうというアプローチ。

RDBでは動的な実装が多くて、ロックベースでは同時実行が起きそうなところをロックで守って同時に書き換えられないようにして矛盾を防ぐ。タイムスタンプベースでは、時刻をデータに付けて、時刻を見てよろしくない書き込みをはじくなりアボートするなりすれば、同時実行でも矛盾が起きませんよと。

3つめのコンバージェントベースは教科書にはあまり載っていないので、アカデミック的にはここで紹介するのは適切ではないのかもしれませんが、時間を掛ければ正しい状態に収束していきますよ、というもの。

わかりやすい例は追記オンリーのセット型。データの追記だけしていき、どこかで全体をマージすれば一意な状態に収束するので。これも同時実行性制御の手段になるかなと。

なぜERPをCassandraで作っているか

NoSQLの定義はあまりないと思うのですが、私は「RDBでないもの全部」というよりも「RDB＋α」というか、RDBが捨てている部分を含めているものだと見ています。

一般にはNoSQLというと非リレーショナルな分散データベース、というところでしょうか。

ちなみに、いまわれわれは「HUE」というERPをCassandraをメインに使って開発しています。このあとの議論ではあえてCassandraで苦手なケースを中心に話すので、ここではなぜCassandraかという話を簡単にしておきます。

Cassandraは間違いなく高い可用性があります。多少ノードが死んでも全体としては生き続ける。スループットも高く、一カ所に処理が集中しないのでレイテンシが落ちにくい。

われわれはグローバルにHUEを展開しようとしているので、グローバルな複数の拠点に透過的にサービスを展開できるという利点もあります。

アプリケーションから隠すか、アプリケーションで解決するか

伝統的な考え方でいうと、同時実行性制御のような難しい処理、分散システムではさらに複雑になるので、そういったものはアプリケーションから隠しましょう、というのが一般的だと思います。

一方で、分散データベースや分散トランザクション処理には非常に大きなトレードオフがあります。例えば、性能を高めようとすると一貫性の確保や可用性の実装が難しくなるなどのCAP定理のような。

そこで汎用的なレイヤを作っても、アプリケーションの要求を満足しないことが多い。だったらむしろアプリケーション側で制約をかけてしまえば、そうしたトレードオフをうまく解消できるはずだ、という考え方もあります。

このあと、堤さんにはそういう立場で話してもらいます。劉さんには前者の、なるべく汎用的なデータストアというかトランザクションマネージャがあったほうがいい、という立場で話をしてもらいます。

ここで会場の皆さんに、いま直感で、どちらがいいと考えているか聞こうと思います。アプリケーションで制約を作ってそこで解いてしまったほうがいい、という方は配られたウチワの赤を、そんなのは車輪の再発明なので、下のレイヤで隠してしまったほうがいい、という方は青をあげてください。

（青が多く上がる）

下のレイヤで隠したほうがいい、というトラディショナルな考えを支持する人のほうが多そうですね。

では堤さんから、実際にERP製品で発生するトランザクションにかかわる問題提起をしてもらい、それをどのようにCassandra上のアプリケーションで解いているか、いくつかのケースを話してもらいます。

Publickeyによる補足：トランザクションの実装技法

ここまでの井上氏による説明のポイントは、トランザクションの実装には何種類かの教科書的な方法があり、RDBであれNoSQLであれ、何らかのトランザクション機能を備えるためには、これらの技法から適切なものを選択して実装することになる、ということでしょう。

そしてRDBやNoSQLに限らず、アプリケーションレベルであっても同様の技法を使えばデータに対してトランザクションを実装することができる、ということが、次のページで展開される堤氏の発言で示されていきます。

≫次のページでは、NoSQL上のアプリケーションでも、要求に対応するトランザクションがアプリケーションレベルで実装できるのだ、ということが示されていきます。