BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース 現実世界におけるデータ一貫性を語る: Uwe Friedrichsen氏による学術論文へのご招待

現実世界におけるデータ一貫性を語る: Uwe Friedrichsen氏による学術論文へのご招待

原文(投稿日:2016/03/13)へのリンク

ドイツのベルリンで開催されたmicroXchg 2016 コンファレンスでのUwe Friedrichsen氏のプレゼンテーションは“「現実世界におけるデータ一貫性」”についての深い見識を示すものであった。Friedrichsen氏はいくつかの学術論文を引合に、ACID vs BASE、一般的なSQL型DBが保証する一貫性についての厳密な理解を多くの開発者が欠いていること、また様々なデータ一貫性のモデルを(マイクロサービスを代表とする)分散型システムで実現するためのアプリケーションレベルの実装はどうあるべきか、といったトピックについて語った。

今回InfoQはプレゼンテーションで語られた内容について更なる詳細に踏み込むべく、codecentric AGのフェローでもある Friedrichsen氏へのインタビューに臨んだ。インタビューでは、データ一貫性をよりよく理解するための学習ステップ、データストアに限定せずシステム全体観点から最適なデータ一貫性モデルを実現することの重要性、そしてストレージ・クラスメモリ(SCM)やリモートダイレクトメモリアクセス(RDMA)といった最新の技術がデータ一貫性に関する今日の常識を覆す可能性などが着目して欲しい重要なポイントとして語られた。

InfoQ: 本日はインタビューのお時間をいただきありがとうございます。早速ですが、microXchgで行われたプレゼンテーションの背景やこの題材を選んだ動機を教えていただけますか。

簡単に答えるのが難しい質問ですね。複数の洞察を経てようやくプレゼンテーションに至ったというのが実情で、2~3行で答えることはできそうにないです。頑張ってはみますが、予めお断りしておきます。

データ一貫性について考えるとき、(私自身が長い間そうであったように)多くの人は2つのモデルしか頭にありません。1つ目は、通常非分散システムにおけるACID に基づく強い一貫性、2つ目は、分散システムにおけるBASEに基づく弱い一貫性です。後はPaxosやそれに似た技術を用いて分散環境で強い一貫性を実現するモデルぐらいでしょう。

このことは開発者にとって、シンプルなプログラミングモデルを採用して分散を諦めるか、極めて困難なプログラミングモデルを採用して分散を実現するかのいずれかの選択しかないことを意味します。私の経験から言えば、後者のモデルを採用した場合、BASEトランザクションやその本質に対する理解が不十分なため、多くのプロジェクトでは問題の種となります。理解不足に加えてプログラミングモデル自身が非常に理解が困難であるためBASEトランザクションでは保証されないていないデータ一貫性が、保証されるものと多くの開発者は思い込んでしまっているのです。

この問題に関してPeter Bailis氏による論文を偶然発見したのですが、そこでは「拡張性や可用性を諦めることなく、達成可能なデータ一貫性にはどのようなレベルが存在するのか」についてのおもしろい見解が述べられていました。Peter Bailis氏とその共著者は論文の中で、ACIDトランザクションモデルとBASEトランザクションモデルの間には多くの、異なるレベルのデータ一貫性と拡張性/可用性を実現する実用的なモデルが複数存在することが示されていました。

そこで示されたていた新たなモデルの多くが実用的な拡張性/可用性を備えており、開発者にとっても非常に有用であったため、私はより詳しく調べてみることにしたのです。その過程で分散システムにおけるデータ一貫性に関する多くの論文を見つけました。それらの論文は商用ソフトウェア開発にそのまま適用可能なほど成熟したものではありませんでしたが、「開発者に(ACIDとBASE以外にも)適切なデータ一貫性モデルを提供する必要がある」という大きな方向性は一貫していました。具体的に言えば「拡張性や処理速度の要求を満たし、同時に開発者が扱いやすい(データ一貫性に関する)プログラミングモデルを提供する必要がある」ということです。

これらの論文から得た洞察とは別に、プレゼンテーションに影響した事実が2つあります。先に見つけた幾つかの論文ではACIDトランザクションモデルにおけるデータ一貫性について詳細に検討がなされており、それを読んで私は長年忘れていたことを思い出しました。それは「我々が通常ACIDトランザクションについて語る時は、最も堅固なデータ一貫性モデルである、『シリアライズなトランザクション』を念頭においている」という事実です。シリアライズなトランザクションとはシンプルな「トランザクションを開始して、なんらかの処理をして、コミットする」といったお馴染みの完全なデータ一貫性を担保するモデルです。トランザクションは成功するか、失敗するかのいずれかで不整合が起きることはなく、例外もありません。要するに、完全なのです。

ところが現実世界では、ACIDトランザクションがシリアライズなトランザクションであることの方が稀なのです。ANSI SQLはデータ一貫性に関する幾つかのレベルを定めていますが、シリアライズ性はその最上位に位置します。ただ通常シリアライズ性を実現するためには大きな犠牲をパフォーマンス面で強いることになるため、ほぼ全てのデータベース製品でシリアライズ性は実現されていません。つまりACIDトランザクションを利用していても、運用時に不整合が起きる可能性は存在し、実際、不整合はおきます。ただ多くの開発者はそのことを知りません。現実は開発者が信じている通りではないため、我々の多くが考えるより遥かに高い頻度で、運用時に問題が発生しているのです。

もう一つは残念ながらデータストレージの領域(に限らず)でよく見かける「同じ解決策が全ての問題で有効だ」という考え方です。10年程前は、何もかもがリレーショナルデータベースでした。時代は変わって、リレーショナルデータベースの不足箇所を補完すべくNoSQLという選択肢が新たに加わりました。ところがにリレーショナルデータベース時代に培われた「同じ解決策が全ての問題に有効だ」という姿勢だけは変わることなく、今度は「全てはHadoopで解決だ」、お次は「全てはCassandraで解決だ」といった始末です

それぞれの問題領域において有効な解決策を提供するデータベースが存在していることは間違いありませんが、全ての問題領域を解決する一般解などありません。最適なデータストアを選定するための観点は数多くあります。例えば、必要とするデータ一貫性のレベル、データモデルの複雑さ、クエリーモデルの複雑さ、拡張性等々ですが、全ての観点において最適だと言えるデータベースなどあるはずがありません。だからこそ、異なる要求には、個別に注意深く最適なソリューションを検討する必要があるのです。データスストアに対して幅広い要求があるという事実は、すなわちそれだけ問題領域があることを意味しています。

こういった事柄がmicroXchgで行ったプレゼンテーションの背景にはあります…やはり私が恐れていた通り簡潔な答えとは程遠い説明となってしまいましたが、結局2~3行に収めりませんでした。

InfoQ: プレゼンテーションの中で多くのひらめきをAdrian Colyer氏の「Morning Paper」ブログから得られたと述べられていますが、このブログの常連ですか。もしそうだとすれば、あなたと同じように開発者やアーキテクトは学術論文を読むべきだとお思いですか。

おっしゃる通り、Adrian氏の「Morning Paper」は素晴らしいブログで1年程前からニュースフィードに登録しています。またその前から時々ブログを訪れていました。彼が取り上げる論文には大変興味深いものが多く、彼自身の投稿も素晴らしいものが多いため、ブログの常連になると時間がいくらあっても足りなくなってしまうという問題がありますが、それだけの価値は間違いなくあります。

興味がある分野について深く知りたいのであれば、私は開発者も学術論文を読むべきだと思います。実際、学術論文からしか深い知識を得られないことも多いのです。とっかかりとしては、本やインターネットで見つけられるチュートリアルから始めてもよいでしょう。さらに深い知識を得ようと思えば、それに関したブログの投稿や専門レベルのプレゼンテーションや記事を見つけることができるでしょう。しかし本当に深いレベルに達するためには、基礎から始めて最高レベルの知識まで段階を追って理解する必要があります。少なくとも分散システムの領域においては、そういった理解を得るためには学術論文しか手立てがありません。

InfoQ: インタビューの中でACIDトランザクションは理想的なプログラミングモデルだが、現実的には多くの実装はそうではないと言及なされていましたが、そこをもう少し詳しく説明していただけますか。

最初の質問であらかたに答えたことですが、シリアライズトランザクション(理想的案トランザクション)の実現には多大なパフォーマンスを犠牲にしなければならないため、実際はほとんどのデータベースではより低いレベルのデータ一貫性しか保証できていません。それにも関わらずACIDトランザクションとシリアライズトランザクションは同義だと思い込みがちです。現実は理想と異なることに気づいていなければ、理想的なトランザクションを前提にアプリケーションの設計と実装を進めてしまうことでしょう。その結果「対処できない障害」が運用時に発生してしまうのです。原因に気づいてないのでは、対処法もわかりようがありません。

InfoQ: プレゼンテーションの中で、クラウドコンピューティング、マイクロサービス、NoSQL、そしてBASEトランザクションに触れることなく「今日の」現実世界におけるデータ一貫性について語ることはできないと述べられてましたが、普通のプロジェクトで、拡張性やデータストレージ/データアクセスが担保するべき範囲に関する設計の中で、データ一貫性モデルについて十分に考慮できていると考えてられますか。

私が見る限り、答えは「ノー」です。

私が思うに、このような状態にあるのには幾つかの理由があります。まず最初に挙げられるのは、知識の欠如です。誰が悪いというわけではないのですが、分散システムにおけるデータ一貫性というトピックは、とても理解が難しく、混乱しやすく、完全に理解するには時間が掛かるものです。その一方で開発者やアーキテクトは日々の仕事に忙殺されています。山のように降ってくる要求や要件、受入れ難いステークスホルダーの意見、容赦のない期限、毎日のように現れる新しい技術、そのうえ大量のインチキ定例報告書を作成しなければないときています。これでは理解を深めるための時間を作るのはとても無理で、結果、浅い理解にとどまってしまうのもうなづけます。

それに加えて、Pat Helland氏の著名な論文「分散トランザクションのその先へ( "Life beyond distributed transactions")」で述べられているように、分散システムにおいて結果整合性より高いレベルでデータ一貫性を実現するには、データストアのことだけを考えれば良いというわけにはいかないのです。最高レベルのデータ一貫性を実現するためには、アプリケーションやそれを支えるデータベース等の基盤システムも同じレベルで検討されなければなりません。もはやデータ一貫性はデータストアだけの問題ではなく、アプリケーション設計の一部として正式に扱われなければならないのです。この理由は同氏の別の論文「砂上に楼閣を建てる("Building on quicksand")」でもはっきりと述べられています。

要するに、ビジネス要求を満たすアプリケーションを構築するためには、データ一貫性が保証するべき範囲についてもしっかりと検討する必要があり、データ一貫性に求められるレベルを知るためには、簡単なことではありませんが、ステークホルダーともこの観点で議論をする必要があるのです。最後に、困難なことではあるのですが、検討したデータ一貫性モデルをアプリケーションやデータストアの実装レベルに落とし込むことは欠かせません。

最適なデータ一貫性モデルを検討し設計すれば、それがより簡易なプログラミングモデルにつながり、結果として大きな時間の節約となるはずなのですが、前述のとおり多くの開発者は日常に忙殺されており、データ一貫性モデルに割く時間は残されておらず、なかなかそのようには進まないのが現実です。残念なことにデータ一貫性だけの問題ではなく、この傾向は他の分野でもよく見られます。

InfoQ: データ一貫性に関する今日の最前線の研究について聞かせてもらえますか。最近のメモリストレージの動向について意見をいただけますか。

分散システムにおけるデータ一貫性の限界が因果一貫性モデルであることは知られています。ただしこの場合クライアントからのリクエストを受け付けるノードは固定化しなければなりません。今さかんに研究されているのは、結果整合性と因果一貫性の中間に位置づけられる、より考慮しやすく、使いやすく、効率的で一般的なデータ一貫性モデルの実装方法についてです。まだ商用ソフトウェア開発への適用に耐えうるような成果は出ていませんが、将来的には大きな進展があることを期待できます。

その一方で、高速分散システムにおける強いデータ一貫性の実現も研究がさかんな分野です。強いデータ一貫性と高い拡張性/可用性の両立を諦める替わりに、可能な限り高速で効率的なシステムを目指すという方向性になります。弱いデータ一貫性と比べて、強いデータ一貫性のプログラミングモデルが遥かに扱いやすく、強いデータ一貫性でしか実現できないユースケースがあることを考えれば、この研究にも高い価値があると言えます。

またこれらの研究とは別に、メモリやストレージの分野でも新たな方向性が示されています。 ストレージクラスメモリ(SCM)は、場合によってはRAMと同等の速度を実現しうる、RAMとSSDの間の隙間埋める不揮発性メモリとして注目されていますし、CPUをバイパスしてリモートマシンのRAMに直接アクセスするRDMA(Remote DMA)という技術も実現されつつあります。ローカルマシンのRAMへのアクセスよりも低速だとしても、ローカルマシンのSSDへのアクセスと比べれば二桁以上(80-100倍程度)の速度性能向上が見込まれる技術です。

これらのストレージに関する新しい技術は、システムアーキテクチャやアプリケーションアーキテクチャにも多くの革新的な選択肢をもたらすことでしょう。コンピュータ黎明期から「CPUが最も速く、次は揮発性メモリ、一番遅いのが不揮発性メモリ」というのが常識でした。そのためキャッシング技術(RAMもいうなればキャッシュの一種ですし)を代表にCPUを最大有効利用するために多くのアーキテクチャ上の工夫がなされてきたわけですが、これらの新たなストレージの出現によって、その常識がもはや常識ではなくなるのです。これからはストレージのパフォーマンスを最大化する目的で多くのCPUを利用することが当たり前となり、これまで常套手段とされてきたアーキテクチャ上の工夫は見直しを迫れることになるでしょう。

実際のところ先をはっきりと予見できているわけではないのですが、新たな環境により適した多くのシステムアーキテクチャやアプリケーションアーキテクチャが生まれることは間違いないと思います。分散システムにおけるデータ一貫性モデルという分野に限っても重要な話ではありますが、その範疇にとどまらず、今日のアプリケーションの設計や実装をすっかり変えてしまう結果になると考えています。

InfoQ: 現在、そしてこの先データ一貫性が、アプリケーション要件やプログラミングモデルに与える影響が何なのかを、特に知りたいと思う読者にお勧めの記事や速成講座のようなもの、もしくは習得ガイドラインがあれば教えてもらえますか。

もちろんです。まずは私のmicroXchgでのプレゼンテーションを見てください…と言うのは冗談ですが、簡潔な初心者向け解説はどこにもないかと思います。今回のプレゼンテーションのために40本弱の論文を利用していますし、スライド(スライド番号55-57)には20弱の参考文献が記載されています。

内容が内容ですので、残念ながら速成講座を紹介することはできませんが、参考文献をどの順番で読み進めるべきかの簡単なガイドラインならば示せます。

まずはPat Helland氏とDave Campell氏による論文「砂上に楼閣を建てる("Building on Quicksand")」 から始めるのが良いでしょう。この論文はなぜデータ一貫性をアプリケーション操作レベルで検討する必要性を論理的に説明しています。「なぜ」を理解しないことには何も始りません。ですのでこの論文がとっかかりとして最適なのです。

次にAdrian Colyer which氏の「Out of the Fire Swamp」ブログに進むのが良いでしょう。このブログでは多くの最前線の研究についてわかりやすく要約されています。

その後、Peter Bailis氏と共著者によってデータ一貫性の系統が示されている「高可用トランザクション:その長所と限界("Highly Available Transactions: Virtues and Limitations")」、およびACIDトランザクションモデルの限界について書かれたHal Berenson氏の「ANSI SQL分離レベルの評価( "A Critique of ANSI SQL Isolation Levels")」に進むのが良いでしょう。またここであげた論文のコンセプトの要約はAdrian Colyer氏の「Morning paper」 ブログの最近の投稿で読むことができます。

これらの論文と投稿で必要な基礎を学ぶことができます。後はプレゼンテーションのスライドで示したものや、先ほど紹介した論文や投稿で示されている参考文献をそれぞれの興味に従って道標とし、先へ進めば良いかと思います。

InfoQ: 本日はどうもありがとうございました。最後にInfoQの読者に一言いただけますか。

こちらこそどうもありがとうございました。まだこのトピックについては氷山の一角に触れただけで、伝え足りていないことが多くあるとは思いますが、もう十分以上にしゃべり過ぎました。

このインタビューを通してデータ一貫性について興味を持っていただけたのであれば幸いです。

microXchgでのUwe Friedrichsen氏のプレゼンテーション「現実世界におけるデータ一貫性を語る( “Real-world consistency explained”)」の動画はYouTubeのmicroXchg チャンネルから閲覧可能だ。

 
 

Rate this Article

Relevance
Style
 
 

この記事に星をつける

おすすめ度
スタイル

BT