Project Tsurugi(劔)とAsakusaについて Â

Project Tsurugi(劔)とAsakusaについて

ついでにAsakusa advent calendarの分も

 

■Tsurugiの特にNEDOプロ部分について

日経の記事はこちら

https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00001/03044/

本紙はこちらからかな？

https://www.nikkei.com/article/DGXMZO51692890R01C19A1000000/

 

・NEDOのサイト

https://www.nedo.go.jp/content/100891996.pdf

 

・スライドはここ

drive.google.com

・togetterはここ

 https://togetter.com/li/1430683

 　本来であれば、あまり外向きに書く話ではないのですが、仮にも公金が入っていて、日経の方にも「親方日の丸」的は記事も出てしまっているので、当事者として「今の状況の感想」みたいなものを、外でしゃべった内容の補足として開示しておく感じになります。

　ここに書いてる内容は基本的にNEDOで公開されている情報の解説なので、特に細かい情報が必要な人はそちらから取得してください。

 

・NEDOプロについて

　TsurugiのNEDOに関わる部分は、きっちり公募に入札して、第三者の審査を通ったプロジェクトです。現在も監査を含めて、透明性・運用適正性が求められ、それに対応しつつ作業しています。尚、後述もしますが、Tsurugi自体はコミュニティベースの部分もあり、この部分についてはNEDOとは関係ありません。

 

・日経さんでの「親方日の丸」という言い方について

　まず基本的に「親方日の丸」ではありません。そもそも「親方日の丸」が何かという話ですが・・・一円でも公的なお金が入ったら「親方日の丸」である、と言われると、その意味では「親方日の丸」になってしまいますが、そういう話でもないと思っています。（逆に公金が入らなくても「親方日の丸」なものはいくらでもあると思っています。）

　おおむね個人的には、ITにおける「親方日の丸」は以下のスキームを指すと理解しています。

-霞が関が「これやるぞー！」と声上げて、

-適当なリーダーまたはコンサルっぽい人が意気投合して「やるぞー！」と呼応して、

-フォローの民間企業が「おー（震え声）！」、と続く、

というスキームで始まるプロジェクト的なナニカだと個人的には理解しています。

 

　仮に「親方日の丸」が、この意味なのであれば、今回のTsurugiについては、まったく違います。

 

　そもそもは有志で集まっていたDBやらTxやらの勉強会・コミュニティの延長線上で、「もう他に選択肢もないし、ちょっといろいろ自力でDBつくりますか？」という話で始まったのが事の起こりです。この勉強会・コミュニティは今も活動していますし、NEDOとは別に動いています。この流れの中で、国の支援を得るのはありではないか、どうなのか？という議論や紆余曲折があって、メンバーの中で支援を受けてもやぶさかではない、というメンバーがNEDOプロに参加している、という形になっています。よって、現在もNEDOには参加せずに、Tsurugiの活動に参加しているところは実際にあります。

 

　よって、日経さんの「親方日の丸」の意味が、自分の理解している、また、おそらく多くのIT関係者が揶揄に利用する言葉としての「親方日の丸」ではあれば、事実と異なるし、逆に、1円でも公金が入れば「親方日の丸」である、という意味での「親方日の丸」であれば、その通りです。・・・なんでこんなこと言ってるかというと、単純に変なバイアスがかかるのがいやだからです。

 

・体制として船頭多くないか？という疑問について

　体制図をご覧の通り、相当な企業・組織・大学が参加しています。実施する各自のタスクの割り当て/管理/成果物管理・NEDO完了後の普及へモチベーション/あり方は、参加者が連携を取りながら各自で進めています。

　船頭的には三つあってそれぞれ役割が違います。学術的なとりまとめは東工大の横田先生にお願いしていて、全体の枠組・法的な対応・公的な対応はNECさんが担当、技術的な方向性やそもそものDBとしてのあり方のとりまとめはNautilusということで動いてます。それぞれの船頭がそれぞれの得意のところで水先案内をしているというところかと思います。なので、多分山に登ることはないですね。

　なお、Tsurugiの特に技術的な方向性・勿論、枠組や全体の方向性としての合意は参加者全員で意思統一して上で進めています。その意味では船頭は多いとも言えますが、うまくバランスとってやっているというのが自分の感覚です。

 

・そもそも金が足らないんじゃないかという疑問について

　まずDBとDBMSは違うので誤解のないように。今回作るのはDBであって、DBMSはPostgresの「外側」を利用する形になります。Management Systemレベルまでスクラッチで作るのであれば、たしかに全く金額が足りません。ただ、コアのDBだけを作るのであれば、金額として決して過小というわけではないです。

 

■Tsurugiの意義について

 

・そもそもなんでRDBなのか

　そもそも今時RDBかよ、って言う人が多いかと思います。RDBなんてもう何十年も前の技術で、内容的は掘り尽くされているじゃないの？という印象はあると思います。実際、CPU・メモリーが貴重で、基本をDiskベースにした旧来のRDBの延長線上なのであればば、その通りでほぼ新規にやれることはあまりないと思います。

　しかしながら、コア数と利用可能メモリーが文字通り桁違いに増えた現在のハードウェア環境では、旧来アーキテクチャのDiskベースのRDBでは残念ながら、前提がまったく異なるためパフォーマンスがでません。

　メニーコア・大容量メモリーベースはそもそも考え方が旧来のDiskベースとは抜本的に異なるため、まったく新規に作っていく必要があります。この分野はまだまだ理論的にも未成熟でいくらでも研究・開発の余地があります。

 

・某商用ベンダーとあんた方まじめに勝負する気なのか

　技術的にはまじめに勝負する気です。普通に勝算はあります。技術的にこれはいけるというものがなければそもそもRDBの開発などしません。

　が、ビジネス的にどうかといえばその規模感は、アリと巨人ぐらいでしょうね。まぁそれはそうです。技術が秀でているからそれがそのまま普及してビジネスになるとはまったく思っていません。淡々と普通にやって、よりよい選択肢を提供していくことが目標になります。もちろん、公金が入る以上、普及や商用という話は出てきますが、なにより、まず自分たちでちゃんと使いたいというのが本音です。そもそも某商用ベンダーのアレはコストも含めて、ちょっとイマイチなんすよね。

 

・DBだけ作ったって誰も使わんでしょう

　わかってます。普通にミドルはそんなもんです。なので、使いやすいように

1.OSSにした

2.外側は可能な限りPostgres

3.割と派手目の、毛色の違う3種類のプロトタイプアプリを準備する

と、ここまで準備します。それでも厳しいのは自覚しています。

 

・んで技術的にどうよってのは、端的に言えば

-低遅延分散環境を前提

-lockベースではなくtimestampベース

-order theoryとしてはPOSETのなかの特殊なサブタイプをバックボーンにもつ

-multi-versionな並行性制御を軸

-分散処理に最適な処理系/実行計画を装備するOLTP

-現状では最先端の最適化を指向したOLAP

-OLTPとOLAPをシームレスに統合したserializableなHTAPを視野にいれている

になります。なんかいろいろ難しそうなこと書いてますが、別にそれほど大したものではないです。今時であれば普通に考えるでしょう、というものをちゃんと入れているだけです。特段に奇をてらったというものは目指していませんが、次世代の標準の指針になるような意識はもっています。

 

■さて、ここからはAsakusa的な話です。

 

　Asakusaの実行基盤としてTsurugiをどうとらえるか？は今のところは白紙です。もちろんNautilusのビジネスとしては、お客さんのことを考えるのであれば、一義的には考えるべきところではありますが、Tsurugiは別にNautilusが単社で全面主体でやっているプロジェクトではないし、公金も入っている以上、私物化的扱いは厳禁です。李下に冠をたださずが正しいスタンスでしょう。とまぁ倫理的な話はもちろん前提ですが・・・実際は技術的（どちらかというと理論的なフレームワーク）な話の方が問題です。

 

　まず前提の確認ですが、メニーコア・大容量メモリー（NUMA）は基本的に分散システムです。なので、バッチ処理は、そのまま分散バッチ処理になります。よって・・・分散バッチ処理ではどのようなtransactionモデルを採用すべきか？ということになります。

 

　グローバルなアカデミアでの「バッチ処理」の話をすると、まず日本的バッチ処理というのはわりとコンセプトとして二つの性格が整理されていない、ということが浮き彫りになります。

　一般的にアカデミアでは、バルク処理としてのバッチ処理とlong transactionは別々にわけて考えます。バルク処理は複数のtransactionをまとめて処理とすることを指します。このときone-transaction（すなわちnested transaction）とするか、あくまで複数のtransactionかはケースバイケースです。現在のところは普通に複数のtransactionで処理という考え方が普通ですね。一方、long transactionはデカい処理が一つのtransactionとして処理され、他のtransactionと処理時間のスケールが合わないため、いろいろ厄介ごとがおきる、というものを指します。

　それぞれ別のコンテキストで話をされるのが普通です。前者のバルク処理ではスループットの問題で、後者のlong transactionではlock制御の問題で、それぞれ専らに検討されます。日本固有（といってもいいかと思います）の「バッチ処理」では、普通に二者の話が混在します。整理されていません。

 

　Asakusaでも、この混在の話は基本整理していません。まずもってtransactionがないので議論の無駄です。HadoopやらSparkやらでの処理は基本はisolationの保護は運用側のタスクになりますし、分散処理でlockとかスループット考えるとセンス悪すぎです。したがって、まずもってAsakusa→Tsurugiの筋道の前に「そもそもバッチ処理でのtrasactionをどう考えるかしっかり整理する必要」があります。

 

　現状のTsurugiでは、やっとMCSRクラス相当のモデルが完成した段階で、その上のより高次のMVSRに近いモデルまでの定式化を進めている段階です。この定式化で分散処理・バッチ処理について目処を立てる予定です。バッチ処理的な分散transactionはまだ検討がついてません。なので、白紙ですというか、現時点では白紙にせざるを得ません。

 

とまぁこれだと身も蓋もないので、現在までの、自分個人の考え方を述べたmemoを置いておきます。これは個人のmemoに過ぎませんので、その辺の扱いでお願いします。

 

問題：

　バッチ処理とtransaction処理での最大の課題は大量のwriteです。これはRDBがもっとも苦手とする処理であり、そもそも原理の問題になります。特にsingle versionのCSR前提の現在のRDBではlock制御が前提です。long transactionで大量にwriteをする場合は普通にDBが即死します。ハードがどんなに頑張ろうが、これはソフトウェアのアーキテクチャの問題でどうにもなりません。

 

どーするかって話ですが、原則論としては以下です。

 

-multiversionが前提。バッチ処理中とそれ以外の処理でversionをisolateする

要するにバッチ処理中のversionとそれ以外の処理を別versionとしてきっちり管理しきる。これにより、他のversionに対するtransactionを稼働させるということができ、バッチ処理中でも別の処理をconcurrentに走らせることが可能になります。もっともこれはそもそもMVの基本的な原理なので、これは“本来は”当たり前の話です。（というのは簡単ですが、なにも考えないと普通にNP完全で即死です。）

 

-メニーコアを利用して分散処理を原則として行う

要するにバラしてスループットを上げろ、ということです。もっと端的に言えば分散ノードではなく、メニーコア上でHadoopとかSparkっぽい処理をDB上で実行しろって話です。これも普通にスループットは上がります。このあたりはすでにAsakusa/M3BPで実績もあるので、勘所はある程度はわかっています。（というのは簡単ですが、なにも考えないと普通にbarrierで詰まりますね。）

 

以上をやるだけで、旧来のコア少なめのdiskベースのRDBよりも桁違いのスループットが出るのは確実です。というのは簡単ですが、この状況で「一貫性を担保する」方法は、2019年現在、世界中で解決案は出ていないレベルです。というか「そんなの無理だから検討するだけ無駄」ってのが世界の相場です。

 

まぁ、やりようはあるので頑張ります、ということになるかと思います。

それは追々説明するとして、（ちょっと面倒な数学/メカニズムを使う話になるのでここでは説明は省きます。）

 

まず、上記のMVCCと分散処理を前提として、いわゆる「バッチ処理のtransaction」をどう考えるか？のための整理のポイントをAsakusaの経験から以下に並べます。これは端的に言うと、並列処理ができる順でTx化した方がよいのではないかと思っています。要するに例えば・・・

 

[処理]

大量の在庫処理が前提で、ほぼ全在庫にアクセスして一斉に特定条件（相互に独立）に合った引き当てを行って、かつ伝発を行い、なんらかの総合計のレポートを算出する。

 

疑似フローは以下

 

-PlanA

TX-begin

LOOP

全在庫に順次アクセス：

アクセス順に条件にヒットした処理を実行：

各在庫別に伝票発行：

END_LOOP

レポート作成：

TX-commit

まぁ普通はないですけど、なにも考えないとやりそうではあります。1件でも失敗すれば最初から。実行計画的には一直線に順番に在庫処理をして、すべて完了したあとに集計して終了。失敗のroll backは最初から。

 

-PlanB

LOOP：parallel

TX-begin

全在庫に順次アクセス：

アクセス順に条件にヒットした処理を実行：

各在庫別に伝票発行：

TX-commit

END_LOOP

TX-begin

レポート作成

TX-commit

これが普通によくあるパターンの一つになると思います。これは実は伝票発行がストリクト・シーケンスなユニークナンバー要求だったりするとそこでつまります。ただし、そこ以外はconcurrencyが上がる。あとはなにか失敗した場合に、在庫→処理→伝票の単位でroll backできるので、全体の進捗が管理しやすい。伝票処理の業務例外を在庫関連に一部反映させたいときとか、いろいろ諸般の事情で「凝り固まっている」ときに有効。

 

-PlanC

LOOP : parallel

TX-begin

全在庫に順次アクセス：

アクセス順に条件にヒットした処理を実行：

TX-commit

END_LOOP

LOOP : non parallel / parallel

TX-begin

各在庫別に伝票発行：

TX-commit

END_LOOP

TX-begin

レポート作成

TX-commit

割と汎用機系バッチ処理では王道のバッチフロー。concurrencyの高い在庫処理のみを別Txにして、伝発とは別のTxにして可能であればparallelで処理。 ただしなにかの失敗が在庫管理と伝票管理の双方にまたがる場合は、ほぼ確実にroll backできないので、取り消しバッチを別に流す必要がある。

 

バッチ処理でTxを考えるのであれば、たぶんPlanBかCです。まぁ以前のRDBだと普通にPlanAとかやるので論外ですが・・・考え方としては、

1.DB側が勝手に判断して、BかCかを判断していい感じに実行する

2.バッチ設計者がBかCか判断してバッチを実装する

現実的には2でしょうね。

 

これとAsakusaがどういう関係か、という話ですが、Asakusaで開発をしたことがある人であれば、この設計はそのままAsakusaでの開発プロセスそのものだということがわかると思います。要するに「バッチ処理でTx処理をデザインする」ということは、そのまま「AasakusaにTxを導入する」という話とほぼ同じになります。その意味で、Tsurugiのバッチ処理とAsakusaは同じ路線の上にいるといっていいと思います。

 

そんな感じです。

 

以下、今までの印象とか感想ですが。

 

とにかくwrite intensiveなヘビーバッチ処理ってのと、現在のRDBのTx処理というのは、恐ろしく相性が悪いです。おそらくIT史上もっとも筋の悪い組み合わせの一つです。やればやるほど実感します。この問題はなかなか特級の厄ネタで、根っこにある数理モデルから根本的に再構成しないと手が打てません。

 

・・・しかしながら、普通に大量の書き込みやりながら、高スループット維持したままで、普通に単発のクエリーをどかどか打ち込んでも問題なく動いて、かつ一貫性を担保してほしいですよね。今時そんなこともできないのか？とか一般民間的には思うじゃないですか。世間は人工知能だ、シンギュラリティだとか、夢みたいなこと言ってるんすよ。その足下の基本のDBで、こんなことすら出来ていません。んで、簡単そうに見えて、これがまた想像を絶する難易度で・・・・。まぁ、なんとか頑張ります。

 

いずれにしろTsurugi頑張りますので、ちょっとでいいので応援お願いします。