LINE Developer Conferenceに行ってきた

ふとしたことから LINE Developer Conference の存在を知り、その中の「高可用データベース」という文字列をみて高可用データベースを作っている身としては黙っていられないので行ってきた。喉がかわいたので水をもらえてよかった。

ひとつめのセッションはLINEのシステム運用。インフラは基本に忠実に、無駄に安いハードウェア買って困るくらいならそこそこの値段でいいヤツ買います、ソフトウェアも同様、必要なところでは VMware vSphereやOracleを使いますといった感じだった。やはりメッセージングなのでバーストトラフィックがあるらしく、それのせいでスイッチのパケットバッファが普通に溢れてパケ落ちが発生するらしい。ふつうのTCP/IPならその後の再送はランダムに時間置いて飛ぶはずだからそんなに溢れないと思ってたんだけど、TCP周りの設定をいじったらなんとかなりそうな気もする（※個人の感想です
それでバルスとかも普通に乗りきれるんだけど、今年の正月はRedisクラスタの1台が謎の高負荷状態になって、リトライの嵐になってシステムが不安定になるという障害があった。MSI-X(ってなんだ？？)が動作しているときにirqbalanceが割り込みまくっていた。Redisが使うCPUがなぜか奇数番のCPUに集中してしまうのが高負荷の原因だったので、なんとかというマクロ？を設定して済ませたとか。さすがはLivedoorといったところか。あとHBaseのディスクはPCIE-SSDというハードウェアを使っている（使うことにした？）らしいですよ。まあIOPSは桁違いだもんね…

で、ノベルティを沢山もらいました。

ふたつめのセッションはお目当ての高可用データベース。データベースが数千台もあるとか。Percona MySQL使っていて、マルチマスターで運用しているぜーとのこと。なんとMMMを使っていると（その後某MySQLな人と話したら「MMM使ってる人いたんだ…」と驚かれたのできっとすごいことなのだろう）。Write conflictが起きたらどうするのだろうとか、切り替えにかかる停止時間はどの程度なのだろう、とか、VIP張って切り替えを管理するノードは別にいるみたいなのでそいつの冗長化はどうするの、とか、ネットワーク分断が起きたらどうなるのかなー(;◔ิд◔ิ)とか、気になった。

次はN-baseというおそらく本邦初公開のソフトウェア。MySQLのシャーディングができて、無停止でノード追加ができるというミドルウェアで、gizzerdとかPNUTSみたいなヤツかな。ルーティングのアイディアはCouchBaseとかRiakに似てて、PKEYを使ったConsistent Hashing *1だった。で、ハッシュにかけたあとパーティションに区切るのかな？そのパーティション毎に（おそらく）テーブルを作って、その単位で管理する。どのパーティションをどのサーバーが持ってるかはマスターがいて、そいつがルーティングする（っぽい…ここがRiakやCouchBaseと違うところ）。ノードを追加するときはバックグラウンドでパーティションを渡す。Select/Insertをまわしつつ、全部渡したらテーブルをドロップしちゃう。渡している途中にSelectが来たら、渡す先と渡す元のデータを比較してタイムスタンプが新しい方を使うとのこと。各ノードの死活監視は select now() でやっているらしい。合理的だ。

いくつか気になる質問があったのだけど、懇親会は出れなかったのでここにメモをしておこう。

• インデックスを張ってあるカラムからのSelectはどういう動作になるのか
• ルーティング表を持っているノードの冗長化はどうやってるのか、その子が死んだらダウンタイムになるのでは（そもそもMasterがいないなら、ルーティング表の共有はどうやってる？）
• 複数テーブルや、複数行の同時更新したい場合は分散トランザクションを使っているのか
• パーティションを渡すときの負荷と速度はどのように制御しているのか
• どのパーティションをどのノードが持つかの配置はどういうアルゴリズムでやっているのか
• JOIN使ってるかどうか
• aggregation系のクエリのパフォーマンスは？
• select now(); みたいな死活監視だと故障時にダウンタイムが20とか30秒くらいは出るがそれは許容範囲なのか*2

ダブルブッキングでケツカッチンだったので3つ目のネットワークのセッションを諦めて品川に移動。なんか知り合いが沢山いたらしく、懇親会に出たらもっと別の話も聞けたのかなあとちょっと後悔した。それにしても、なんかいっぱいグッズもらったし渋谷は華やかだった。雨が降ったくらいで出社しないなんてとても勿体ないなあと切に思う。

*1:という言葉を使わなかったのだけど

*2:ええ手前味噌な質問です

データ可視化の実践入門

エンジニアのためのデータ可視化実践入門という本を読んだ。なんでも「ある意味」という言葉をつけておけば大丈夫らしいのでいっておくが、正直いって、ある意味でこの本に騙された感がある。ある意味で。まあ釣られたという言葉が正しいのだろう。

エンジニアのための データ可視化[実践]入門 ~D3.jsによるWebの可視化 (Software Design plus)

この本が出る前にブラウザでグラフ書くならどういうのがいいのだろうなーと思って D3.js を一度試したことがあった。たしかにグラフはカッコよく書けるのだが如何せん私はJavaScriptがさっぱり分からない。どれくらい分からないかというとJavaScriptとJavaはそれぞれv8とJVMという違う処理系の上で動いているらしいというくらいしか知らないくらいよく知らなかった。

でもグラフは描いてみたい。きっとそこにはカッコよくグラフを描くための素敵なテクニックが記載されていてこれさえ読めば私もイケてる今風JSハッカーだぜヒャッハーとなる予定だった。でも読んでみたらそうじゃなかった。釣りタイトルの対する私の指摘をまとめるとこうだ。

• エンジニアのための本ではない - エンジニアじゃなくても、いわゆる数値から意味なり主張を読み解くためのグラフというものを作成する人、それを読む人全員が前半を読むべき
• 実践と入門って結局どっちやねん - 実践的なコードも載っているしCoffeeScript入門までついている
• 「D3.js による」D3.jsじゃなくても役に立つ知識ばかり - D3.jsの解説は全くなくてもよいくらい

特に前半には、テレビや論文、新聞、プレゼン資料などに登場する馬鹿げたグラフに対する著者の恨みのようなものが随所に読み取れていて好感がもてる。もちろんそれだけじゃなくて、今まで暗黙知識だった可視化のノウハウがかなり明文化されており、いままで科学実験、論文やプレゼンでなんとなく空気を読んでグラフ作ってきた人はこれを読んで正統なグラフを描けるようになるだろう。

それにしても今後はこういった釣りタイトルはきっぱりとやめていただきたい。

IT業界（インフラより）のみんな！アニメのBDを大人買いしてる場合じゃないぞ

飲み会で話していたら、この危険さに気づいている人あまりいなかったようなので。

• Google Drive、激値下げ―1TBが月額49.9ドルからなんと月額9.99ドルに
• アマゾン ウェブ サービスがAmazon Glacierを発表
• Facebook uses 10,000 Blu-ray discs to store 'cold' data その衝撃的動画

こうやってニュースを並べると聡明な諸君は気づくだろうが、ストレージの単価がほぼ同じだ。Facebookの記事はコンシューマ向けではないが、単価はそのレベルだろうと想像される*1。

Glacierは登場した当初は「すわテープドライブまでクラウド化か？」という憶測が飛び交ったが、「テープではないらしいぞ」という憶測も登場して実際のところは分からない。GMailはバックアップにデープドライブを使っていたらしいが今でもそうなのかは分からない。

さらに、これらのニュースの間のタイミングで ソニーとパナソニック、容量1TBを狙う長期保存用の光ディスク規格「Archival Disc」というニュースが登場していたということが問題だ。

データセンターを走らせるためのコストは大きく分けて初期コストとランニングコストに分けられる。初期コストはまあバルクで買い叩けばどうにでもなるとして、ランニングコストはエネルギーを消費しているためどうしてもなくならない。ハードディスクは、中でスピンドルを止めていたとしてもメモリ、CPU、電源、空調などを使っているとどうしてもコスト、というかエネルギーを消費する。だから、それを止めるコールドストレージは相当なレベルでコストを下げられる（定量的な議論はあえてしないできないできたらすごい）。

ところが、それを不要にするのがコールドストレージだ。手段としては単純にコンピュータの電源を落とす方法と、長期保存が可能な光学ドライブを利用する方法がある（もちろんテープも）。この中で光学ドライブを大手がこぞって利用し始めたということは…あのJames Hamilton御大までもが光学ドライブについて言及したということは…

Googleだけが上記のなかで光学ドライブを使っていると明言していないが、あの価格はおそらく光学ドライブだ*2。

もちろん、光学ドライブにも技術的な問題点はあってそのまますぐに使えるというわけではない。テープほど耐久性が高くないため、ある程度の確率で時間が経つと読み出せなくなる。市販のDVDでテレビを録画していたが、数年経って見返そうとしたら見れないという経験を持っている人も多いだろう。もちろんHDDよりは寿命が長いだろうが、おそらくは定期的にデータを読みだして壊れていたら複製を増やすという操作が必要になる。そういった耐久性のデータと、複製管理のアルゴリズムの技術と、ロボットで自動化する技術のどれかひとつでも欠けているとこれは実現できない。

*1:「価格競争はしない」というレトリックも問題のひとつなのだが…

*2:一歩譲って、HDDとコールドストレージのハイブリッド構成のはず

ソフトウェアデザイン 4月号は本日？発売です

「なぜRiakはデータをなくさないか」というテーマの2回目。ヒント付きハンドオフがすごいのは分かったけどデータの整合性はどうなるのよ、というときにベクタークロックとかSiblingsとかをどう使うか、これらがどういう挙動をするかについて解説した。

Software Design (ソフトウェア デザイン) 2014年 04月号 [雑誌]

話としてはこのブログ過去の記事の延長線上（土台？）になっている内容なので、ここを読まれている方には新しい情報は少ないかもしれない。
具体的には、CRDTのはなしで触れたSiblingsとかCRDTと、こないだの筑波大学での話の間の関連を埋めるような内容になっているので、これを読んでみなさんも分散素晴らしい、とか分散厨になっていただきたいと切に願ってやまない。

NoSQL認定試験ブロンズ編の問題

基礎編

• 現在主流となっている関係データベースを構成する2つのおおきな技術分野を答えなさい（10点）
• SQLは関係代数と関係論理が理論的基盤になっているが、関係代数に基づいていないSQLの仕様をひとつ挙げなさい（10点）
• トランザクション処理の4要件であるACIDが何の単語を表すか答えなさい（5点）
• トランザクション隔離性の4つのレベルを全て挙げなさい（5点）
• トランザクション隔離性レベルの4つのうち3つのそれぞれについて起きうるAnomalyを挙げなさい（10点）
• mmap(2)と仮想メモリの違いについて説明しなさい（10点）
• B-treeとハッシュというデータ構造について説明しなさい（10点）

概念編

• BASEについて説明せよ (10点)
• CAP定理のCとACIDのCの違いについて説明せよ（30点）
• カラム指向とよばれる概念について、分散データベースおよび関係データベースとの関連と併せて説明しなさい（20点）
• 最古のNoSQLデータベースが登場したのは次のうちいつか 。 [1966 1971 2001 2006] （5点）

個別編

• memcached と Redis は同じオンメモリKVSといわれる分野に属するが、大きく利用目的が異なる場合がある。両者の機能の違いとあわせて説明せよ（20点）
• Hadoop はNoSQLと呼んでよいかどうか（5点）
• HBase をデータの永続化機構として利用する目的となるおおきな特徴のひとつを述べよ。そのためにどのような運用上の注意点があるか解説せよ（15点）
• ZooKeeper のロゴは次のうちどれか（5点）

• TokyoCabinetやMongoDBが物理メモリ32GBのコンピュータで利用する際のキャパシティ上の上限について述べよ（20点）
• CouchDB と CouchBaseの違いについて述べよ（10点）
• Cassandraはついに実用段階に至ったかどうか論ぜよ（50点）
• DynamoDBはデータベースと呼ぶべきかどうか、その機能をもとに論ぜよ（30点）

Disclaimer

飲みながら書いたネタですあくまでも念のため拝承。書き始めたときは面白いかなと思ったが、まあ途中で飽きた。

ソフトウェアデザイン3月号はRiakの中身を解説します

2014年3月号のソフトウェアデザインの記事は「Riakはなぜデータをなくさないか」という観点から、Riakの設計とその思想を解説する。レプリケーションを行うデータベースの一般論からはいって、書き込み競合が起きたらどうなるか、ネットワーク切断が起きたらどうなるか、整合性とは何なのか、永続化とは一体何なのか？について語る。

Software Design (ソフトウェア デザイン) 2014年 03月号 [雑誌]

ACID的なデータベースではDurabilityはあって当たり前であるが、それではDurabilityとは何なのか？という議論もあるのだが、とりあえず、CAP定理的にはレプリカのConsistencyとAvailabilityとPartition Toleranceは矛盾する。昨今のデータベースは基本的にはConsistencyだけにフォーカスしていて、Consistencyを守るためにAvailabilityとPartition Toleranceを犠牲にしている場合が多い。RiakはConsistencyの定義を変えることでAvailabilityとPartition Toleranceを同時に実現しているのだけども、その中でもAvailabilityと、Durabilityの話が中心に進んでいく…というとなんだかカッコイイですね！

これを執筆した後に筑波大学での講演があったのだが、この講演の直前にこの原稿を書いたのが非常にラッキーで、知識の復習になってとてもよかった。

本当はこの中でJepsenの解説もしたかったのだが、他社製品をDisることになってしまうので自重。そしてこれの続編を書いているのだが、ハードコアすぎて終わりが見えない。3月号のつぎの4月号ではスピリチュアルな話ではなく、実際に手を動かしてRiakの整合性がどのように設計されているかについて解説する予定なので、3月号も4月号も買うとよいよ！！

なぜErlang/OTPなのか

このテーマ自体はさんざん語り尽くされていることである。たとえば山口君によるWhy Erlang? というブログ記事の翻訳や、戦闘機本（Programming Erlang: Software for a Concurrent World (Pragmatic Programmers)）を読めば世間でいわれていることはよく分かる。もしくは、同僚が最近書いたソフトウェアデザインの記事を読んでもらってもよいだろう。

Software Design (ソフトウェア デザイン) 2014年 02月号 [雑誌]

私自身もErlangに出会ってから5,6年が経とうとしているが、当初はそのよさがよくわかっていなかったように思う。しかし、仕事で高可用性が要求される複雑な分散システムに携わるようになって*1、いろいろな問題がコンピュータというか、データベースとか分散システムの世界にあることを知った。

メモリ管理の問題

単にmainを読んで、なんらかのロジックを実行してそれなりの時間で終了するプログラムを書いているうちは、メモリリークやメモリ管理の問題についてうるさくいうことはなかったのだけども、マルチスレッドでプログラムを動かしていて、開放されたところをうっかり他のスレッドがタイミング依存でさわってしまうとかいろいろあったわけで…
かといってメモリ管理をJavaやRubyのようなシステムでやってしまうとグローバルなGCをせざるを得ず、死活監視をほぼリアルタイム*2でやりたいといったときにGCでシステムが固まるのは困る。といったときにErlangの仕組みを考えてみると、Per-process-GCというのだけども、すべてのデータはTLSになっていてスレッド間のデータ渡しはメッセージなので基本的にはコピーで行う、というやり方をみて眼から鱗が落ちたのであった。メモリ管理に関する本質的な難しさが完全に解決するわけではないのだけども、人間の脳でもある程度考えられる程度になったという意味で、これと類似のことができるのはErlangくらいなものだと思う。

軽量プロセス

プログラミングモデルでいうと、1つのTCPコネクションに大して1つのOSプロセスをforkしたり、スレッドをcreateするのはとても自然なことである。そのTCPコネクションと、リクエスト処理に関わるもろもろのリソースのライフサイクルを一致させることができ、かつ、関係のない他のものと綺麗に分離できるためだ。だがちょっと待ってほしい。いくらCoWが働くとはいえ、ひとつのOSプロセスを起動して捨てるためのオーバーヘッドはいかほどのものだろうか。スレッドのスタックをある程度確保しないといけない。コンテキストスイッチも毎回おきる。レジスタは総入れ替えでキャッシュも効かなくなる（はず…）ので、モデルとしては正しくても、コスト的には釣り合わない。
そうするとどういうシステムになるかというと、たとえばクロージャを持ち回したり、TCPコネクションにひもづいたコンテキストの構造体を作ってスレッド間で引き回してスレッドプールを作って、つまらせたくない場合はキューをつくって別のスレッドプールに処理を流して、それのレスポンスをトリッキーな方法で待って…とやっていくと大抵は破綻するのである。一方でErlangの軽量プロセスとメッセージングの仕組みは、ひとつのTCPコネクションに対してひとつの軽量プロセスを割り当てる分かりやすいモデルにしつつ、ひとつの軽量プロセスのオーバーヘッドをかなり抑えることができる（300ワードくらいと言っていたような）。これを知ってしまうと、僕のようにあまり頭の回転がはやくないタイプはC++とかJavaで真面目に考えて実装するのはかなり面倒になってしまうのである。

Resilence

これを日本語でどういったらいいのかちょっと分からないが、耐久性というか安定性がある。ほっといても不安定になることはあまりないし、軽量プロセスを多少ぶっ壊したところで再起動するからどうってことないのである。もちろんErlang VM内部のメモリを破壊したらダメなところはあるのだが、それでもノンストップでコードをアップグレードしたりダウングレードできて、それが人間で扱えるレベルで簡単になっているのは恐ろしいことだ。ヤバい。鬼ヤバい。

マルチコア

20や30くらいのコア数だと安定してスケールする。GILとかGVLといったものがない。それは前述した通り、メモリ管理の方法が異なるためだ（もちろん、個々の軽量プロセスのレベルでGC時はとまってしまうのだが）。なので、ひとつのOSに複数のプロセスを起動する必要がない。それがChefがErlangを採用した理由だと聞いているが、何も考えずにOSプロセスをひとつ起動しておけばコアをよしなに使ってくれるのだから便利なものである。コア数が100や200まで増えたときの挙動はまだ私はよくしらないが、基本的にはN:Mのスレッドモデルをユーザー空間で実現しており、しかもメモリがShared-nothingなのでなんとかなるのではないかと楽観している。

まとめ

ここまでみてきたように、Erlangの言語そのものよりも、Erlang VMという処理系のメリットを私は気に入っているようだ。だから、Elixirのようなのものでも同じメリットを享受できる。安定したシステムを作るためにはErlangは最適の処理系である。

残念なところ

とはいっても、残念なところは沢山あるのでちょっと愚痴をいっておきたい。

まず、何よりも型安全ではない。この点ではRubyやPythonと同類で、うっかりテストを忘れていると修正で簡単にデグレがおきる。それを防ぐためのちょっと賢い方法としてDialyzerやQuickCheckがあるが、できればコンパイラと密結合してほしいものである。そのためには今のような beam ファイルの構成ではなくて、全ての実行ファイルを静的に結合してしまってひとつの実行ファイルにするのがよいのであるが、そうするとモジュール毎のライブアップデートや、ネットワークなど外部から変なTermが飛んできたときの扱いやらで、ずっと走り続けるシステムに静的で型安全な世界はムズカシイのかもしれない。それでも、Tupleじゃない代数的データ型、ほしいやん…

古い仕様が残っていることが多い。なるべく使わないものや有害なものはDeprecateしたり使えなくなるようになっているのだが、やはり長期間走るシステムをターゲットにしているだけあって古い仕様を捨てることはあまりない。まあこれはしょうがないか。

最後にDisclaimerであるが、この文章は読み返しているとはいえ、酔っ払って書いたものなのでどうか適度に聞き流して忘れてほしい。

ニッカ 余市 12年 45度 700ml

*1:実装やテストの作業に携われなかったのは今でも口惜しい

*2:古典的な意味で

ひさしぶりに音楽をたくさん買った

新譜を追いかけるのも面倒になってしまって、ここ数年は電車の中でさえ音楽を全く聴いていなかったのだけども、ふと思い立って、自分のiTunesのライブラリをみながら新譜を出しているかどうか調べてみると案外たくさん出していたので、まとめ買いしたものを紹介。試聴すらしないで買うとか、忙しくなったものである。

COMEDOWN MACHINE

なんといってもStrokesがいつの間にか出していたのは嬉しい。1曲目でブッ飛ばされた（痛）。

Bloodsports

Suede復活して一枚出したのは知っていたけど、昔ながらの感じが復活してとてもよい。

RANDOM ACCESS MEMORIES

これがグラミーをとったやつなのかな？歴代の曲を追えているわけではないけど、あいかわらずかっこいい。ぼくもこれくらいかっこよくなりたい。

Four

ちょっと落ち着きが出てきたか？

Codes & Keys

まだ聴いてない。

Right Thoughts, Right Words, Right Action (LTD Edition Double Gatefold CD)

まだ聴いてない。

さすがにThe MusicとかUnion of Knivesとかはもう出していなかったというか、彼らは帰ってこないのだろうな。いやNew Orderとかはもう帰ってこなくていいですよ思い出は思い出のままでいいよ…

それにしても、どうしてこのmp3全盛の時代にCDを買ったのかというと、こういった光学というかディスクのメディアに何がしかの郷愁がないかといわれたらウソになるのであるが、それだけではないように思える。どうしてだろうか。CDはまだ物理媒体だが、書籍はもう完全に電子書籍メインにすることにした（ただしフリーのPDFのみでKindleは使わない）。あの質量、体積の効率の悪さは子供がいる家庭では完全に邪魔でしかない。まだ電子書籍になれないところもあるが、私のように飛ばし読みして内容を忘れてあとで読み返しもしないような人間にはソレくらいがちょうどよいのだろう。
CDはまだ数が少ないし、書籍に比べると場所をとらない。それにもうiPhoneで持ち歩いているし、MacからRipしてiPodなりで持ち歩く生活はもう10年以上続けているのでまあ、オリジナルの媒体くらいは持っておこうかなとも思ったわけである。電子書籍やmp3で買った音楽と違って、やっぱりモノがあると買った気がするし記憶に残るので聴こうという気になるのである。不思議なものである。