システム系論文輪読会で話してきた #pfisystemreading

先週の金曜日に、PFIで開催されたシステム系論文輪読会で話してきた。いい加減に積んであるものが多すぎて、こういった機会に便乗して自分を追い込まないと何もできないからである。


第2回 システム系論文輪読会 - connpass

僕が読んで解説したのは Peter Bailis et al., "Coordination-Avoiding Database Systems" VLDB 2015, to appear である。この論文がどれだけすごいものであるかという話についてはぼくのレジュメを参照いただくとして…この論文は神林さんに教えてもらったのだけど、VLDBやBailisのグループは要チェックだということを再確認した。この論文、なかに分散システムの証明が書いてあったりするのだけど、21回も続いている分散合意本読書会で鍛えた証明の読解力で割とスラスラとノリを理解できたので感動した。というわけで合意本を読めば…

Fault-Tolerant Agreement in Synchronous Message-Passing Systems (Synthesis Lectures on Distributed Computing Theory)

Fault-Tolerant Agreement in Synchronous Message-Passing Systems (Synthesis Lectures on Distributed Computing Theory)

といいたいところであるが、この本は一人で読み進めることは素人には不可能なのでなかなかキビシイ。ちなみに、わりとついてきた地力を使えば、CAP定理の証明 [1] くらいであれば、サクサクと読めるようになったりはする。

話を戻すと、この論文の内容はともかくとして、この論文がどうすごいのかを書いておこう、と思ったけど上のGistにだいたい書いてあった。クラウドとか分散KVSとか言ってるひとたち、この論文読まないとだめだよ。あとサーベイとしても非常によくできていて(各方面の歴史たちが共著者になっているので、歴史的に漏れがほとんどない)、参考文献リストの長さに顔が青くなること必至である。

まあ、流れでいうと、NoSQL的にトランザクションとかACIDとかレプリケーションをそこそこで割り切って作ったデータベースのよいところと、RDBMSとか2PCとかデータの整合性をキッチリキッチリやってきた流れがここで融合しているのがすごいのである。市場にも「トランザクションできるNoSQLだぜー」とか高速なRDBMSだぜーみたいな話は死ぬほどあるのだけど、どれもこれまでのデータベースの研究と製品の歴史を無視したマーケティングなので無視したらよい。製品にして使ったところでどこかでハマるのが原理的にわかっているので(ハマらないことが証明された設計になっているのであれば、それは論文にして出した方がマーケティングとしても効果が高い)。MongoDBやMySQLのようなタイプのレプリケーションをやっていると、ネットワーク分断、耐障害性、スケーラビリティのどこかで問題が出てくるし、CassandraやRiakのような設計でレプリケーションをやっているとスケーラビリティや耐障害性が十分であっても、整合性に限界があったりアプリケーション的なユースケースが限られたりする。

これはひとつのパラダイムでいろいろなデータベースの問題を解いて全てのユースケースをカバーできないということの証左であるわけだが、このCoordination Avoidingなデータベースでは、ひとつのデータベースで、ユースケース毎に理論的な限界をギリギリまで詰められることを証明した。具体的には、整合性を保ちつつスケーラビリティや分断耐性を追うためのユースケース分析をして、それをうまく使い分ける提案をしたわけだ。I-Confluenceの概念とその証明でだんだんテンションは上がって、TPC-Cのアクセスパターン分析でこの論文は最高に盛り上がる。

しかし原理の解説やTPC-Cの分析と実験は非常に興味深いのだけど、実装や設計の話がほとんどなくて、これじゃあちょっと再現とか実装してテストしてみるというわけにはいかなそうなのが難点である。きっとベンチャーを立ち上げるのだろう。

個人的には、この論文の実装が世にでるか出ないかのタイミングで「ひとつの用途にひとつのデータストア」の時代が終わるのではないかと予想している。今でも、AWSに入ってる各種データストアや、Orchestrate.ioなどが登場しており、データベースを個別にデプロイして使い分けるのではなく、複数のユースケースをなるべくシンプルなサービスにまとめて使い分けるという形が主流になっていくのではないか。手前味噌であるが、Riak も2.0のリリースでその第一歩を踏み出している

  • [1] Nancy Lynch and Seth Gilbert, “Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services”, ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51-59.

退路を断つ

ベルセルクのドルドレイ攻略戦で、鷹の団が川を背にして陣をとるシーンがある。グリフィスはそこで「後ろは川だ!退路はない!ここで踏ん張って勝つぞ」といった趣旨の発言で味方に発破をかけて大軍に勝つというシーンがある。人間が自分で何かを達成したいときも、似たような考え方をしてモチベーションを整えていく方法がある。大学受験に失敗して浪人をするとき、就職活動がうまくいかなくて留年するとき、卒業のための最後の2単位をとろうとするとき、などなど。一旦これで成功体験を得てしまうと、次の挑戦でも同様に自分を追い込んでからが勝負になりがちだが、良い子はマネをしてはいけない。

ベルセルク (7) (Jets comics (542))

ベルセルク (7) (Jets comics (542))

いくつか理由がある。

グリフィスは勝つ見込みがあって勝負をかけた

何を言ってるか分からないと思うが、ドルドレイ攻略戦ではグリフィスは寡軍を更に分割して、別働隊を出している。鷹の団の本隊が押され気味になったときに要塞内の守兵を戦功を餌に誘き出して、守りがほとんどいないドルドレイ要塞は別働隊が簡単に占拠してしまったのだ。また、中世の戦闘では大将の強さが軍隊の強さを決める側面があるが、敵の大将のボスコーン将軍をガッツが倒してしまうのである。漫画の主人公が負けるわけはないのだから、グリフィスはそこも計算していたことだろう。漫画のキャラクターが漫画の外の事情を考慮することは一般にご都合主義と呼ばれるが、ベルセルクという漫画はグリフィスをそういう物理的制約の外側にいる神秘的なキャラクターとして漫画内で上手く描いている。そうやってお膳立てを全部整えた上で「退路はない」と煽るのである。つまり計算づくなわけだ。

ちなみにこの退路を断つ戦略は、私が知る限り「項羽と劉邦」で韓信が中盤で用いている(確か楚との一連の戦いの中で)。おそらくはどこかの古典に載っている戦術だと思われる。どうしてこれが成功するのかという戦史上の分析はリデル・ハートの「戦略論」にタップリと書かれているのでお楽しみ頂きたい。

翻って、自分がそういったことを考えるときに勝つ見込みは十分にあるだろうか?火事場の馬鹿力という言葉を信じすぎていないだろうか?自分が普段できないこと、していないことを計算や予測に入れてはいけない。もし入れるなら、火事場になって突然腰が抜けて動けなくなるリスクも計算に入れなければならない。

そんなことを考えた時点で本人は十分に真剣だ

鷹の団の士気が低かったとはいわないが、この方法はあくまで「大将が兵士たちのモチベーションを高めるため」に用意した状況である。自分が自分のモチベーションを高める、という風に自分を客体的に扱ってコントロールすることに使えるかもしれない。しかし、私の理解だとそれは必要以上にモチベーションを高めてしまい、思考を停止させる。そのような方法は持続的ではないし、人間はそんなに強くない。

他にも敵を誘き出すすためという目的もあったが、個人での内面のメンタル維持であれば、その状況を外から観測することはできないので敵はおびき出されないし、外部の状況が何か変化することはないから、好転することもない。

リラックスした方がパワーは出る

常に退路を用意しておく方がリラックスできる。「逃げちゃダメだ」みたいな有名シーンもあるが、それは本当に退路がどこにもない場合だ。大抵の人生では、退路や他の選択肢は本人が思っている以上に多く用意されている。ダメそうだったら早めに諦めてまた仕切りなおせばいいじゃない。ぼくは高校3年の冬に「えー、キミたちは大学受験まであと13ヶ月ありますが」とかセンター試験の一週間前に「ほんまに大丈夫なん?今年は諦めてまた来年頑張ってもええねんで」とか言われたことがある。冗談めかして言われたわけではなく真剣にだ。それはどうかと思う、というか、それを真に受けつつ真に受けないくらいの余裕をちゃんと用意しておこう。

たまにはスピリチュアルなことを書いてみた。

在宅勤務環境を整備した

2年前に一念発起して組んだマシンがあって、Core i7と32GBものRAMを節操無く積んでいたもののファンの音が気になるとか子供が邪魔をするとか、ディスプレイが小さいとか理由であまり使っていなかった。引越を機会に自分の仕事場がつくれそうなので、これを機会にデスクトップ環境をもう一度整備した。

ディスプレイ

やはりこれが一番大切だろう。必須条件は解像度がいわゆる4Kあること。MacBook Proを使ってRetinaの美しさに慣れてしまった今、これまでの普通の液晶モニタでは何インチあっても意味がない。もともと液晶のサイズそのものではなく、解像度に興味があったので必然だ。本当は海のむこうだと$500とかそういうレベルで変えるらしいのだが、日本に住んでいるのでなんか出てるかなーと思ったらASUSからPB287QIODATAからM4K281XBがそれぞれ出ていた。ぼくは海よりも深い理由からASUSを選んだ。

と、それだけではいけない。なぜならこのディスプレイ、DisplayPort経由じゃないとフル解像度じゃないと表示できないのだそうだ。HDMI規格が悪いのかディスプレイが悪いのかはわからないが、とにかくグラフィックボードも買うことにした。

ビデオカード

@moriyoshit とかいう人によると、LinuxのドライバはGeForceの方がそれなりに動くそうなので、AMD党としては残念だがGTX750あたりを目指して探してみることにする。MacBook Proの最上位モデルはこのボードが入っているそうだからというだけの理由である。もともとゲームはやらないので、そんなに強力な3D性能が必要になるわけでもない。と思っていろいろ探していたが、DisplayPortを持っているボードはELSAだとGTX760からのものしかないらしい。というわけでこれにした。

ELSAにしたのは積極的な理由はないのだが。。。本当はマザーボードと同じメーカーにしたかったのだが、ASRockのZ77 Extreme4という、グラフィックボードを出していないメーカーのマザーボードを使っていたので、逆に、GIGABYTEなどのマザーボードも作っているところはあえて避けてみた。非常に消極的で根拠のないことなのだが。

そういうわけで4Kになった。すばらしい

ちなみに、ドスパラでは、間違った機種をWeb経由で注文しても他社のようにキャンセルはできないので注意。キャンセルの代わりに返品か、同額以上のものに追加で支払って交換してもらおう。

キーボード

人間の両手は、ふつうのキーボードを叩くと両手首が極端に曲がってしまう構造になっている。ふつうのキーボードではもう手首が痛いのでKinesisのエルゴノミクスキーボードを買うことにした。日本だと代理店のエジクン総研から買うのが一番安かった。配達も早かったのでオススメ。この画像のときはまだ全部環境揃ってなかったからMBPで最初に試してたのかな。今はふつうに4Kのディスプレイの前で使っている。

ちなみにこのキーボード、いちおうUS配列を謳ってはいるが、通常のUS配列とは全くの別物で慣れるまでに1週間以上かかると覚悟したほうがよい。仕事で使う場合は、少なくとも3日ほどは練習期間に充てた方がよいだろう。いきなり仕事で使おうとすると、Typoばかりで(自分が)使い物にならないので注意が必要だ。しかし10年以上も使い慣れたものとは全く異なる配列に挑戦するのは、脳の普段使ってない神経をこじ開けていくような気分がしてとても新鮮だった。人間慣れすぎてしまうのもよくない。

マウス

G700sってかいてある。まあこれはあまり使わないので別に何でもよい。スワイプとかXfceにねーし。

椅子

まだ買ってないが、なんかいいやーつがほしい。

まとめ

ちなみに電話会議とかパワポやるときはふつうにMBP使うよ。さて、これでバリバリとErlangを書く!はず…

Riak CS 1.5 がリリースされました

Riak CS 1.5.0 が米国時間で昨日、リリースされたOSSになってから1年余りになる。このリリースは、1.4系に残っていた多くのバグをなおしつつ、いくつかのAPI追加を行ったものだ。相変わらず運用まわりの地味な機能追加が多い。また、コレは Riak 1.4系の上で動作する最後のRiak CSになるだろう。1系の集大成だと個人的には思う。思えば一年半、遠くにきたもんだ。いろいろ怒られたり、ちょっとだけ売れたり、ちょっと前には Riak CS上で今をときめくトレジャーデータのシステムが動き始めたりと…

なんでこんなことを書いているかというと、このリリースのために割といろいろ頑張ったからですね。こういう風にあちこちで使われている製品のソースコードに、技術的な難しさはほとんどないとはいえかなりの量をコミットしたのは私の人生では初めてのことなので、これはまたちょっと感慨深いのであった。1.3のときにつくった Bucket Policy もそれなりに使われているみたいなのだけど、あれは新機能の追加がほとんどなので、既存の部分をそこまで理解しなくても作れたのでよかった。それに、後に同僚いわく「あんな短いコードでどうして動くのかサッパリわからん」といわしめたゴルフ力もあって、ちょっと一人よがりなところはあったかなーと思う(今もあるけど)。

1.5.0 のみどころその1: Hadoop MapReduceがちゃんと動くようになった

むかし、Riak CSをHiveのデータソースにするという記事を書いたのだけども、いまいち歯切れの悪い記事であった。それは、PUT Copyが実装されていないせいで、Reduce完了後のファイルの移動に必ず失敗していたのだった。MixiではHadoopの方にパッチを当てて使っていたそうだが、さすがに世界中でそうしてくれというわけにもいかず、Javaを書けないのでHadoopにパッチをコントリビュートする力もなかった。で、今回そのPUT Copyを実装したのでHadoopが普通に動くようになったという話でした。


1.5.0 のみどころその2: 削除が速くなった

それまでのRiak CSでも、削除そのものは速いけれども、論理削除はバックグラウンドで動作するGCを待たないといけなかった。このGCが遅くて、シングルスレッドで動いていたり、Riakの新しい効率的なAPIを使っていなかったりでとても遅くて、ファイルの作成と削除があまり多いとディスク使用量が平衡できずに膨らんでいくという問題があったのだけど、とりあえずこのGCを並列動作できるようにして、Riakの新しいAPIを使うように修正していった。だいぶ速くなって、今度はディスクがボトルネックになるようになったのだけど、Riakの削除がこれまた曲者で…ネットワーク分断に耐えるように作るから仕方がないんだけどね。

1.5.0 のみどころその3: 今話題のSparkが普通に動く

http://qiita.com/kuenishi/items/71b3cda9bbd1a0bc4f9e

jets3tを使っているから当たり前なんだけども。

1.5.0 のみどころその4: バグが沢山なおっている(ぇっ

 
お後がよろしいようで。えっ。
 

それではみなさん、バグの報告やPull Requestをお待ちしています。

遅ればせながら「「特許庁業務・システム最適化計画」の改定について」について

Slashdotでみた56億円返還の件で興味が湧いて調べていたら、 「特許庁業務・システム最適化計画」の改定についてというやつを見つけたので目を通してみた。一度失敗したプロジェクトをどう再出発させるのかということと、実社会に直接影響を与えるこのシステムがどういう風になっていくかに興味があるからだ。

28枚という短い文書だが、短いだけに情報が凝縮されていてとても面白い。リンクされているPDFの文書は、平成25年3月という、一作年度末に書かれたものであることがわかる。この文書は、改定前の失敗とかそういったことには一切触れない。おそらく改定前のものと比べながら読んだら非常に味わい深いものになること請け合いであるが、ここではとりあえず措くこととする。

まず、特許庁の業務は大きく分けて、受付発送、方式審査、実体審査、登録、公報発行、審判の6種類があること、そのために平成2年に世界で初めて電子化されたシステムがあることが語られる。それは電子出願、事務(包袋事務処理システムと審査周辺システム)、検索システムに分けられるという。

で、オフコン2台を含むシステムが、とりあえずのペーパーレス化を実現したものの、個別システムの複雑化が起きていて、相互依存、手続きの遅延、データの重複が特に問題だと。で、それらを改善するためにシステムを10カ年計画で段階的刷新するといっている。

他に興味がわいた点としては、

  • オフコンのオープン化(久しぶりに聞いたわ
  • 多言語翻訳機能などグローバル化、ちゃんとした検索の提供
  • 「音や色といった新たな権利客体を取り扱うことになる」
  • 審査官が照会するDBとユーザーが照会するDBを一元化する、とかいてある
  • 第二期に「ユーザーへの情報提供の迅速化やAPI(Application Programming Interface)の提供の検討を進める。」
  • 「「クレジットカード決済」を利用した料金納付を可能とするシステムを整備する。」
  • 「データセンタ・クラウドの活用」

個人的に最も興味深かった点はP15だ(以下、引用):

  • 業務AP同士の通信を排除し、業務APを疎の関係とすることにより、システム全体の複雑性を低減させ、システム改修時のコスト低減を図る。
  • 個別システムにおいて基盤機能とデータベースを分離した後、個別システム間で共通的な基盤機能を集約化することにより、制度改正・運用変更時の影響箇所数を削減し、システム改修時のコスト低減を図る。
  • 個別システム間でデータベースを論理的に集約化することにより、システム全体として保持する情報量を低減させることで、システム全体のダウンサイジングを実施し、経常経費の削減を図る。

ぼくには、データベースの集約と個別サービスの粗結合化を進めると書いているように読めるのだが、それは不可能なのでシステムの完成図がちょっとイメージできない。P20には「特実出願系共有DB」なる言葉が登場しているので、それのことかもしれない。ときおり登場する「XML」という言葉がさらに不安を助長する。

クライマックスはP22の工程表だ。今日は2014年度だから、特実出願系DBの開発はテスト工程が4ヶ月目に入っていなければならない。果たしてどのようなDBがまさに今テストされているのだろうか。。。

さて、私の個人の感想を書いておきたい。ひとつは、変化に強いシステムを作る思想に欠けているようにみえるところが心配だ。それは政権が朝令暮改になっているから対応するという意味ではなく、これから技術をとりまく時間の流れは速くなっていく一方なのだから、必要に応じてシステムを迅速に変更できるようになっていてほしい。
もうひとつは、P23の経常経費の試算図が最高にいけてないところだ。要は「少しずつコストを圧縮していきます」と書いている。わたしはコスト構造を時代の流れに合わせて変えてほしいと思っていて、もっというと情報システムに払う金はコストではなくて投資になっていくべきだと思っている。つまり、ハードやネットワークのコストは当然下がっていくが、ソフトウェアや運用にかかる金額はもっと上がっていくということだ。一度に全部つくり直そうとして失敗したことに懲りて、「今度はちゃんとやるぞ」という意志を確かに感じるのだが、失った年月は戻らないしコンピュータ技術はその間に大きく進化してしまった。

さて、このシステムは10年かけて更改してしまったらそれでオシマイだろうか?特許のシステムは100年維持されるものにしなければならない。一度作ったら終わりといってたら未来永劫にわたって完成なぞしないのであって、システムの改善を内包するように設計した方がよいのではと…しかしソフトウェア保守費に15億円ってことは保守だけで150人も維持するのかと思うと、保守だけで終わるのかなぁと本当にドキドキする。

組織の発展段階におけるトレードオフの移行

なんか昔の下書きが放置してあったので、頑張らないでなんか形にしてみよう。

初期:人が少ない

1〜4人
スピード重要
分業なし
自分から仕事を見つけられる人
組織の目標、レゾンデートルをビジネスモデルと一緒に構築していく

中期:人はまだ少ない

5〜20人
発展段階
ある程度の分業役割分担が必要
自分から仕事を見つけられる人
ビジネスモデルはある程度確立される

中長期:人は足りない

20人〜
中期ほどの速度ではないが発展
役割分担が明確になってくる
あまり話したことない同僚がいる状態
上司・部下の関係が登場
 →自分から仕事を見つけられる&上司による役割分担のマネジメント
マネジメントの間で息が合っていればうまく動く

成熟期:トータルでは人は余るが局所的には人は足りない

数百人〜?
完璧な役割分担
20%のエース
60%の中堅層
20%の遊び層
マネジメントも多様化してくるので、組織の目標がかなり明確でないとダイナミクスを維持できない
(明確でない目標であっても、実力以上の利益があると組織を維持できる)
80%の人間のベクトルが揃う(=明確な目標)と、かなりのスピードとパワーを発揮する

各段階に共通するトレードオフ:

  • 画一性 vs 多様性: あまりに画一性が強くて似たものばかりになると外の世界に関心が向かなくなり、自分たちの論理だけで動くようになる。似たもの同士なので、組織トータルでの馬力は非常に強くなりマネジメントのコストは非常に低いが、外界の変化に対応できにくくなる。ある程度の多様性があると組織としてのまとまりを維持する難易度が高いが、多彩なアイディアが出たり外界の変化に対応しやすい。
  • 役割分担なし vs 役割分担と管理: これは全体把握と詳細特化のトレードオフと言い換えてもいい。分業の度合いが低いと、メンバーの流動性が強くリソースの集中投下がしやすくなる。反面、専門的な事柄に弱くなりがち。分業の度合いが高いと、専門性から生まれる競争力を得られる可能性がある。また、分業すると往々にして情報共有と管理が必要になる。
  • 投資+赤字 vs 自己資金+黒字: 前者は高速なブートストラップを期待できる反面、市場がないところに誤ってブートストラップしてしまうような、フィードバックによる方向修正がしにくい。ターボエンジンを積んでグラベルを走るようなものだ。一方、後者はブートストラップは遅いが確実な進歩、方向修正をしやすい(外界からの干渉や注目も少ないだろう)。一方で自転車操業に陥るリスクもある。

中長期が、ベンチャー企業の死の谷といわれるところで、このトレードオフが揺れているところだからバランス舵取りを間違えると即死する。

「すごい Erlang ゆかいに学ぼう!」という本が7月に出ます

すごいErlangゆかいに学ぼう!

すごいErlangゆかいに学ぼう!

いままでいろんな観点からErlang/OTPに関する本が出てきたが、この本はそのErlangの技術の集大成といっていい本だ。コレ一冊読んでおけば間違いない。他の本は忘れてもいい。あえていうなら、これを読んだ後にもっと詳しい作者自身の哲学を知りたい場合だけ、戦闘機本を読めばよい。だが他の本は別にいらない。内容が古かったりツールを網羅していなかったりするためだ。

原著は Heroku のエンジニア Fred Hebert のWeb記事をもとにした本だ。

Learn You Some Erlang for Great Good!: A Beginner's Guide

Learn You Some Erlang for Great Good!: A Beginner's Guide

このFred君というひとはとてもおもしろい人で、 Erlang Factory San Francisco で夜にネタプレゼンをかまして毎年爆笑をとっている人だ。

とにかく量が膨大で、訳者の山口くんの馬力には感服するしかない。レビューアーが10人ちかく集められたが、レビューアーは誰一人彼の仕事に追いつけずにいた。なにを隠そうこの私もレビューアーとして声をかけていただいて、遅々として進まないレビューで彼を待たせてしまって非常に申し訳なかった。レビューアーとして参加する報酬として本書を一冊いただけることになっているようなので、レビューで読めなかったところを改めて読み返して、知らなかった知識をコッソリ埋めることとしよう。

素晴らしい仕事だった(まだ終わってないかもしれないけど)。みなさん、ありがとう。

追記

出版記念パーティーが開催されることを失念していた。参加条件などいろいろあるが、訳者の山口君に会いたいというひとや、東京のErlang/OTPクラスタが集うので興味がある方はどうぞ。