グローバル化の中で日本の宗教を意識できないと負ける


Koshianがまた面倒なエントリを書いているが、この話は昔L.starもやったことがある。

日本人は外国で「宗教:なし」と書く ― 民族と宗教が不可分な人たちが犯す間違い


こういう話題はいわゆる自称中道の保守層には大変ウケが悪い。というのも「日本人は無宗教だから、他国にありがちな宗教的いざこざと無縁な素晴らしい国である」という幻想を破壊するからだ。いや、日本国がキリスト教vsイスラム教を始めとした各種宗教論争と比較無縁なのは、確かに事実ではある。ただそれが日本文化の素晴らしさと直結するかというとかなり疑わしい。

そもそも、無宗教っていうのは何なのか。普通に考えると「私はいかなる宗教も信仰していません」という定義からして、無宗教であることを示すのは、悪魔の証明に近いけっこう大変な作業なのだということに気づくはずなのだが。論理的な積み重ねだけで物事を考えていくことでたどり着く、それなりに大変な道のりの結果なのである。L.starは自称理論肌だし、@elm200氏から「ブログ職人」と呼ばれるぐらいにはちゃんと論理的にしているつもりである。そのうえで正直に言うと、自分が無宗教の境地に達している自信がない。がっつり日本の土着宗教に汚染されている。他の人達が「日本人は無宗教です」と語るとき「そんなでたらめな基準で無宗教って語っていいのか!」とまで思う。

 

多くの日本人が自分を無宗教だと考えるのは大体「私はいかなる特定の宗教にも明示的に入信していません」という理由からだろう。ところが日本の場合、面倒なことが2つある。

ひとつは、日本の土着宗教は神道やら仏教やら儒教やらがぐっちゃぐちゃに交じり合ったもので、それを表す具体的な名称がないこと。それゆえに、自分がほんのりと信じている土着宗教に名前をつけることができないため、特定の宗教だと認識できない。

もうひとつは、日本の土着宗教と呼べるものは、神道にしろ仏教にしろ、いかなる明示的な入信も求めないこと。明示的に入信していないが、その宗教性というのは生活の中にこっそりと隠されていて、例えば結果として新年やお盆を日本土着的な宗教行為として祝う。「僕は名前のない宗教の宗教的行為をしているかもけど、入信したと口で言っていないから無宗教です」という言葉は、どう見ても詭弁である。

ついでに言うと3つ目があって、それは日本の土着宗教が組織的には西洋東洋の各種宗教と比べてとてもちっぽけな存在で、およそ世界定義では宗教といえるほどの力がないこと。日本における宗教の強化の試みはなかったわけではなくて、いろんな形で実施はされているものの、時代を超えて生き残っていない。その最後にして最高の試みは、明治時代の国家神道だろう。そしてこれは第二次大戦の敗戦とともに木っ端微塵に打ち砕かれた。まあこれは日本の宗教が弱かったからとかいう話では全然なくて、単純に宗教が有効な時代が終わってしまったから、単純に遅すぎたということだろうなと思ってはいるが。

 

はっきりさせておきたいのは、強いとか弱いとか曖昧とかそういうのは個人の宗教の関わり方として全くどうでもいい話。日本の土着宗教を信仰していることは、別段悪いことでも何でもないということだ。他人に強制する必要もないし、他宗教から理解し難い行動も要求されないし、食生活にも影響を及ぼさない。歴史も長いし趣深いところも多数ある。一部の戒律の厳しい宗教とか、へんてこなカルトとか、有名宗教で過激派に染まるとかよりははるかに健全といえるだろう。まあ強いて言うなら儒教的価値観から出ているとしばしば指摘される長時間労働なんかは辛い話だが、それとて他国の人にまで強制されることはない。それゆえ、外国の日系企業で働く日本人が長時間労働でこき使われる一方で、他の国の人は普通に定時で帰るといったことになるわけだが、まあそれは別の話とも言える。

一方で、「明示的に日本の土着宗教を含む他の宗教に背を向けて生きている」本当の無宗教の人は実際に存在するのも確かだ。ただ、そういう人はだいたい周りから爪弾きにされて生きている事が多い。なにしろ日本の土着宗教は日本人の行動様式に深く根ざしているわけで、それに背を向けるのはつまるところ「変人」だから。「無宗教」というのはそれだけ覚悟のいる行為でもあるし、それもそれで賞賛できる行動だと思う。

要するになんでもいいのだ。自分のやっていることがわかってさえいればね。

 

英語に例えてみよう。日本人の宗教性を英語にマッピングするとそれは「日本語英語」だろう。完璧な無宗教というのはいわゆる「訛りのない完璧な英語」といえる。ちなみにここで完璧な英語というのはネイティブのしゃべる英語のことではなく、正しい訓練を受け、文法と発音を徹底的に矯正した人にしか喋れないやつのことを指している。ネイティブの、特にイギリスでもウェールズやスコットランド人の話す英語は訛りまくっててむしろ聞き取りづらい。宗教性なんて、所詮は訛りみたいなものである。

もちろん完璧な英語を喋れるに越したことはないし、それを目指して努力するのは素晴らしいことだ。しかし、所詮英語はツールでしか無いと割り切り、自分の英語が「日本語英語」であることを理解した上で、ビジネスを押し通す人だってたくさんいる。どちらもそれなりに褒められた行為といえる。ところが無自覚に無宗教というのは、自分が「日本語英語」しか喋れないくせに、それを「完璧な英語」だと思い込んで得意げにしゃべっている状態を指すのだ。お分かりだろうか。

繰り返すがL.starもKoshianも、自分の宗教性を否定しろというつもりなど毛頭ない。日本人の、また他の民族の宗教性を理解した上で、強みを活かすなり弱みを克服するなりしろ、ということを言っているのだ。自分自身の持つ暗黙的な宗教性に無自覚なのは「己自身を知らない」ということだからだ。魑魅魍魎巨大起業の跋扈するグローバルの世界は、そんな状態で戦えるほど生易しい場所ではない。孫子曰く、敵を知らず、己を知らずば百戦して必ず敗れる。

日本の電気自動車「エリーカ」が米国の「テスラ」にこれだけ差をつけられたワケ

ワケを説明するわけでもなく釈然としない内容なんだけど、以下の一文に大変ビックリした。
資料を読んだ限りでは遙かに先端的な「エリーカ」が、技術的には余り特徴があるとは思えないテスラにこれだけ引き離されたしまったの何故か?

なぜびっくりしたかというと、その答えはあまりに簡単だから。「エリーカ」がはるかに先進的だったからこそ、技術的に凡庸に見えるテスラに離されてしまったのだ。

テスラ・ロードスターはそもそもがロータス・エリーゼのコンバージョンEVのようなところで始まり、ボディもかなりの部分で設計流用、バッテリーは汎用品、EVユニットまで当初は他社のものだったはず。つまりテスラ社の独自要素技術部分は殆ど無く、既存のものをインテグレートしただけ、というところに近い。もちろん独自部分の比率はその次のタイプSでは増えているし、今後もその傾向は続くだろうけど。

一方のエリーカは発明は割と初期とはいえ実用例に乏しいインホイールモーターゆえサスペンションも従来のものが使えず既存の車体の流用が難しいし、その上電気自動車の理想的なプラットフォームを追求しており、その後のSIM-Drive社の他のプロトタイプでは軽量化のためにカーボンのような新素材にも手を出している。いやスペックは素晴らしいしチャレンジングスピリットは買う。しかしこれだけ色々手を出していたら、テスラのアプローチにはスピードで叶うはずがない。

これ、すなわち「巧緻は拙速に如かざるなり。兵法の基本ですがな。

あるいはKISS(Keep it Simple Stupid)原則と言い換えることもできる。テスラが素早く自社製品をリリースできたのは、要素技術的に特徴がない、シンプルでつまらないものにしたからこそ。そういう意味ではテスラと比べるべきはコンバージョンEVの会社で、あくまでテスラはそういうラピッドプロトタイピングの手法で車を作っていた。

こういう自明なことをどうして分からないものか、と思う。映画「風立ちぬ」で扱った軍用機の世界もそういう高い目標を掲げ必死で解決した結果、整備の困難な稼働率の低い機体が出来上がったわけで。無駄に高い目標立てて右往左往する時間があるのなら、その前に低い目標を順次クリアしていけばよいのに。

ただし、SIM Driveのアプローチが間違っているかというと必ずしもそうとはいえなくて、立ち上がりこそ遅くても、あとから追いつくことができればそこで帳尻は合うわけです。テスラのアプローチが逃げなら、エリーカは追い込みだった。それはあくまで戦法の差であって、勝てる勝てないではない。むしろ追い込みに期待したいと思ってはいるけれども。

 

昨今のDBMSの分野の進歩はGoogleがパンドラの箱を空けてからずっと凄いスピードで進化し続けているが、中でもVoltDBは飛び抜けたOLTP性能に特化したDBMSだ。しかしそのプロトタイプであるH-Storeからもう何年も経っており、当然その先の何か、というのが見えてくる。

最近久々に技術に立ち戻ってちょっと最新のDBMSに関する論文を読むか、とカラム指向データベースの圧縮手法について学ぼうかとStonebraker教授の前作C-Store(後のHP Vertica)を調べたり、ハイブリッドDBの前段に使われるインメモリDBの構造について勉強しようと思ったりしてたら非常に興味深いシステムを見つけたので紹介したい。それはミュンヘン工科大学のHyPerだ。HyPerはH-Storeのあとを受け、そのOLTP性能の高さを受け継ぎながら、OLAP性能に関してもインメモリDBならではのずば抜けた性能を発揮できるシステムになっている。

超絶OLTP性能を実現するための三種の神器、非同期I/Oモデル・オンメモリ・ストアドプロシージャのみ許可


ここでVoltDBがなぜありえないほどのOLTP性能を持っているか、というところを確認しておきたい。それはひとつにインメモリDBであることだが、もう一つ重要なことがある。VoltDBでは非同期I/Oを使ったクエリ実行モデルを備えていることだ。非同期I/Oイベント駆動モデルはすでにnode.jsとかでその優秀さ、特にレイテンシの低さを証明しているが、VoltDBは更にその上を行っている。

RDBMSにおいては、マルチスレッドモデルでDisk I/Oの高いレイテンシを隠蔽する一方で、古典的なロックモデルによる悲観的ロックを用いて競合する更新を排除するのが基本方針だ。ところがインメモリDBは高いレイテンシを持つI/Oは無い。するとマルチスレッドを採用する必要がない。となるとロックを取る必要もない。だから非同期I/Oで十分だ!ということになる。一見先祖返りだが、個々のクエリの実行時間が短ければこれはうまくいく。しかもロックを取らなくて良くなることで、さらに実行時間が短くなる。

更に上手く行かせる工夫として、すべての実行可能なクエリを原則事前コンパイルしたストアドプロシージャにすることで、1つの問い合わせが自動的に1つのトランザクションを構成するようになっている。その上ネットワーク上でインタラクティブなやり取りが発生するのも抑えている。なんとなれば、begin一本投げるだけでも、ネットワーク越しでは0.1ms程度かかるわけで、これは従来の遅いRDBMSなら無視出来るレベルであったが、100000tpsを目指そうとする非同期I/ODBMSでは無視できない巨大な損失である。

実にVoltDBのオンメモリ非同期I/Oというモデルは一石三鳥の素晴らしい選択であったことがわかる。これを更に改良していこうというのがHyPerの目的なわけだが、どう切り込んでいくか見てみよう。

非同期I/Oを補助するマルチスレッド


とはいえ、単純非同期I/OでマルチコアCPUの恩恵は受けられないし、メモリ帯域を使いきれるわけでもない。HyPerの改善点の一つは、読み込みのみのOLTPクエリを並列処理するためのマルチスレッドモデルを非同期I/Oの下に用意しているところだ。非同期I/Oモデルによるロッキングは、確かに同時に他の書き込みSQLを実行させないことを求めている。しかし読み込みは別に制限されない。だから、読み込み専用の場合のみ、マルチスレッドで実行させてしまえば良いわけだ。

この改善で本来非同期I/Oモデルが苦手とするマルチコアCPUの性能を使いきりつつ、なおかつ読み込み専用トランザクションの性能を大きく改善できる。それゆえHyPerのOLTP性能は、VoltDBに比べても際立っている。ただし最近VoltDBも相当改善したはずで、そこと比べるといい線いっているかもしれないが。

非同期I/OモデルとOLAPが共存しないわけと、その解法とは


このVoltDBの非同期I/Oモデルは、とにかくあらゆるSQLが超短期間で終了することを前提としている。それゆえ、OLAPクエリととてつもなく相性が悪い。巨大なOLAPクエリはシングルスレッドを専有し、あらゆる書き込みをその間遮断してしまう。OLAPクエリの大半はマルチスレッドで実行させても大丈夫なものが多いが、非同期I/Oでやってしまうと、単にCPUを使いこなせない上にずっとロックするろくでもないシステムにしかならない。故に、VoltDBではOLAPクエリを実行しないことを求めている。これはVoltDBの設計の致命的な部分で、ただそこを犠牲にすることによりOLTP性能を実現しているわけでもある。

HyPerの凄いところは、この致命的な欠陥を回避する解法として、Virtual Memory Snapshotという手法を使って、HyPer内部のインメモリDBの前データのスナップショットをとっている。このスナップショットに対しては更新もされない。心置きなく自分のOLAPクエリを実行できる。スナップショットを取るタイミングは、全くトランザクションが発生していないタイミングで、なおかつ遅延されている更新が存在しない状況に限る。そんな都合のいいタイミングがあるか、というと非同期I/Oではトランザクションが同時に1個しかはしらないから、いつでも発生するのである。そこで魔法の呪文を唱えれば、OLAP用のバックエンドがハイ完成。

ちみにこのOLAP用バックエンドは完全なコピーであるから、バックアップもこのスナップショットから直接作ることができ、容易である。

古の魔法の呪文、その名はfork()


さて、この随分手の込んでいるように見えるVM Snapshotという技法だが、実はずっと昔から存在している。あるプロセスのメモリを丸々コピーし、互いに干渉しない2つのプロセスに分割させる手法、そう、UNIXのfork()そのものだ。今時のfork() はshadow pagingというかcopy-on-writeなので、実際にはコピーすらせずに同じメモリ領域を見ることになる。その御蔭でコピーも最小限、変更した時の挙動も最小限。実に言うことがない。

つまり、OLAPクエリがやってきたときは、非同期I/Oの中で処理せず、マルチスレッドも使わず、そのまま内部でfork()を実行してそっちに処理を引き渡すだけなのである。これが傑作なのは、fork()は結構重いAPIだと昔からみなされており、かつてのMySQL vs PostgreSQL論争では、良くマルチスレッドのMySQLのほうが性能がよく、fork()を使うPostgreSQLの性能が良くない、と言われてきたところにある。かつてあれほど非難されたfork()が、今度は性能向上の切り札として再登場するのだから痛快である。目から鱗が落ちるとはこのことだ。

まとめ:HyPerの見どころは、非同期I/O・マルチスレッド・forkのハイブリッドプロセスモデル


というわけで、HyPerとはVoltDBをベースに、単純非同期I/Oからプロセス/スレッドモデルをハイブリッド化することで更なる多様なワークロードに対応できるように進化したシステムである。なお、この手法を持ってしても、巨大な更新クエリ、例えば全件Updateのようなものには対応できるようにはならない。もともとこういうクエリはかなり特殊な部類で、リレーショナルモデルの完全性を思い知る一方で、性能向上にはやさしくない機能だなとよく思っていたが。

なお、残念ながら、ソースコードは公開されていないようである。2010年代にふさわしい?見事なシステムと思うが、この成果が利用できるのはまだまだかなり先かもしれない。

 

↑このページのトップヘ