2012年9月24日月曜日

Martin Fowlerの新刊 NoSQL Distilled を読んだよ

NoSQL Distilledは、Martin FowlerとそのThought Worksの同僚によって書かれたNoSQLへの簡単な概略書です。ページ数も薄く、150ページ程度しかないのですが、英語が苦手な我々日本人には、かえってありがたいですね。概略書といっても、日本の本とは違い、実際に実運用で使った人にしか分からない、深く突っ込んだ考察も随所で行われています。

本書では、なぜNoSQLを使うのか、という理由を、水平スケーラビリティ、プログラムの容易さ(プログラムに適したデータモデルの利用)という2つとしています。

NoSQLの水平スケーラビリティについては改めて言うまでもありませんが、プログラムの容易さというのは興味深い観点だと思いました。いわゆるリレーショナルモデルとプログラム言語のデータモデルとのインピーダンスミスマッチを解消する手段としてNoSQLを使うという考え方です。

キーバリューストアやドキュメントデータベースなどでは、一つのレコードをAggregateというひとまとまりのデータと考えることで、配列やハッシュなどのごちゃまぜになったデータ構造をうまく保存できるとしています。この部分については、NoSQLのデータ構造をうまく説明していますので、一読の価値ありです。

またNoSQLの持つスキーマの柔軟性は頻繁な変更のあるシステムと相性が良いのではないかと指摘しています。

また本書では、NoSQLといっても水平スケール指向のものだけでなく、Graph Databaseのように一つのサーバーだけで動かすことを中心にした種類のものにも言及されています。

ドキュメントデータベースなどは、JSONなどのデータにたいして柔軟なクエリを行うこともできるので、一つのサーバーだけで動かすのでもメリットがあるのではないかと考察されています。DynamoDBなどにも対応して欲しい機能です。

但し、本書では依然としてRDBMSがデータベースの第一選択肢に止まり続けるだろうと述べています。私としても、本書を読んだ限りでは、NoSQLの利用は一部の大規模システムなどに止まるのではないかという印象を受けました。より広く使われるには、NoSQLソフトウェアやそれを取り巻く環境がもっと成熟してくることが必要ですね。

本書は列指向データベースのようなOLAP用のデータベースには触れられていなかったのが残念です。私の読解力では、本書で触れられているColumn-Family Storeというものが、Key-Value Databaseとどのように異なるのか全く理解ができませんでした。

2012年9月9日日曜日

NoSQL、CAP定理、BASE、Eventual Consistencyについて深く考えてみた

最近はNoSQLなどといって分散データベースがやたらに流行です。私もDynamoDBを使ってみようと思って色々調べているところですが、学べば学ぶほど奥が深くて恐ろしくなってきます。

まず第一に言っておきますが、現在のところ、いわゆるKey-value store型のNoSQLのメリットは「書き込みのスケーラビリティ」であって、それ以外には大きなメリットはありません。

DynamoDBの場合は「管理不要」「高信頼性」というおまけが付きますので、また話は少し別ですけどね。

他のオープンソース製品を自分のサーバーにインストールするのであれば、RDBMSほどこなれていないNoSQLを運用するのは大変な苦痛と危険が伴うでしょうね。前の記事にも書いたように分散システムを運用するというのは困難かつ苦痛を伴う仕事ですから。

ですから、すさまじい数のアクセスがあるようなシステムでなければ、NoSQLを選択する意味はないでしょう。

データベースに関しては、高いサーバーを買ってなんとかなるなら、高いサーバーを買ってPostgreSQLでも動かしているほうがトータルではずっと安くあがると思いますよ。Xeonを80コア積んだHP DL980Fusion-IOを突っ込んでも1500万円あればおつりが来る時代ですからね。


さて、ここから先はだいぶ込み入った技術の話をします。私も専門家ではなく、Amazon Dynamo[1]の論文を読んだ程度で話をしています。間違っているところがあればご容赦を。

最近喧伝されているBrewerのCAP定理[2]という理論がありますが、一貫性(Consistency)、可用性(Availability)、ネットワーク分断耐性(Partition tolerance)の3つのうち2つまでしか同時に得ることができないという話です。

このPartition toleranceを誤って「分散」と捉えて、「クラウドでは分散は必須なのだから一貫性か可用性のどちらかを犠牲にするしかない」と言っている人たちがいます[3][4]。これは大きな間違いです。分断耐性とは、ネットワークが分断した場合にも動作できるかどうかという話であり、現実にネットワーク分断など滅多に発生しない以上、一貫性も可用性も問題なく確保できます。

ネットワークが分断した場合でもアクセスできるという特性は、DNSやCDNや巨大P2Pネットワークなどには必要な特性かもしれませんが、通常のシステムには不要と言えます。また、これはキャッシュやデータ伝搬の仕組みを使えばアプリケーション側で実装できます。従って、この定理は分散データベースとは何の関係もありません。

BASEはここでACIDと対比されていますが、このBASEもどちらかといえば、データベースのスケーラビリティの話というよりはキャッシュなどアプリケーションよりの話に思います。

この古い学会発表をもとに現代のNoSQLを語るのは、はっきり言って無意味ですし、有害だと思いますね。


NoSQLがしばしばconsistencyを犠牲にするのは決してCAP定理のためではなく、スケーラビリティを確保するためであると考えて良いでしょう。

DynamoDBではconsistent readをサポートしていますが、その場合、(Dynamoと同じquorumによる実装なら)特定の条件下では無限のスケーラビリティが失われるはずです。

Dynamoは、ハッシュキーによってデータを格納するノードを変えていますが、このとき同じハッシュキーに読み書きが集中したとしても、consistencyを犠牲にすれば、ノード数に比例した性能を得ることができます。なぜなら、その場合は同じハッシュキーのデータを格納するNノードのうち1ノードだけに書いたり読んだりすれば良いからです。

また、読み書きのどちらか一方がヘビーな場合にはconsistentでもスケールすることができます。書き込みヘビーなら、書き込みは1ノードに行い、読み込みは全ノードに行えば、読み込みがスケールしない代わりにconsistentです。読み込みヘビーならその逆ですね。

それに対して、consistentに読み書きの双方を行う場合には、最低でもNノードの過半数にたいして書き込みと読み込みを行わねばならず、ノード数に比例したスケーラビリティが得られないことになります。

そこでeventual consistencyという話がでてくるのであり、CAP定理とは何の関係もない話なのです。ハッシュキーが十分に分散していればconsistentでもスケーラブルで可用性ある分散データベースが作れるはずです。


しかしこのように一つの値についてconsistencyが確保されたとしても、残念ながらACIDが実現されるわけではありません。なぜならCAP定理やDynamoDBの言うconsistencyというのは、ACIDのconsistencyとはレベルが違うからです。前者は、最後に完了した書き込みのデータが常に読み出されるというだけの話です。後者では、複数のレコードやテーブルやインデックスにまたがる一貫性が必要です。

(ここから先は適当な推測で書いてます)

ACIDを実装するためには、基本的には、トランザクションマネージャが全てのトランザクションを受け付けて、順番を管理して、順番が入れ子になった書き込みなどが起きないように管理する必要があります。これはスケーラビリティを大きく損なう事態です。ですので、NoSQLではACIDを実装することは本質的価値を損なってしまうのです。

一貫性のある書き込みができなければ、データベース全体として不整合な状態が生まれてしまうこともあります。インデックスを管理するためにもatomicな書き込みが不可欠です。

NoSQLでSQLがサポートされないのは、実装の複雑さもさることながら、整合性のあるクエリを行うためにはスケーラビリティが犠牲になることが理由の一つかもしれませんね。

(適当な推測おわり)

システムのうち、80%くらいの動作は不整合性を許容できるかもしれませんが、残りの20%ではどうしても整合性が必要です。そのときにはアプリケーション側で排他制御や整合性の管理を行う必要がでてきます。それではアプリケーションの開発効率を著しく下げてしまいます。

それが、NoSQLは特別にアクセスの多い場合だけ有効であり、普通のシステムで使うことはあり得ないという理由です。


ということで私はNoSQL全般には懐疑的なのですが、Amazon DynamoDBのように管理負担を軽減してくれるものであれば、もう少し広い利用価値があるような気がします。

実用になるプログラムを書こうとすると、どうしてもデータベースを扱う必要性がでてきますが、RDBMSを使うのは初心者や趣味プログラマ等には重荷であり、小さなプログラムを書くモチベーションを下げています。

DynamoDBを使うことで、もうちょい簡単にシステムが作れるようにならないかな、と思って少しアイデアを温めています。

NoSQL Distilledという新刊や、牛の本などの名著を読みながら、もっと勉強していこうと思います。

[1] Dynamo: Amazon’s Highly Available Key-value Store, Giuseppe DeCandia, et al.
[2] Towards Robust Distributed Systems, Eric A. Brewer
[3] Cloudの技術的特徴について --- ScalabilityとAvailability ---, 丸山不二夫 
[4] 結果整合性(Eventual Consistency)についての分かりやすいプレゼン資料 - Publickey




2012年9月2日日曜日

「アントレプレナーの教科書」から学ぶ「顧客開発モデル」の方法論

弊社がバイブルとしている書物の一つに「アントレプレナーの教科書」という本があります。この本では、連続起業家であるスティーブ・ブランクが新規事業立ち上げの方法論を明確なプロセスとして表現しています。

顧客開発モデルでは、顧客を見つけるために仮説設定と検証を繰り返していくプロセスを明示しています。顧客の困っていること=ニーズは何か、という仮説を立て、それを早い段階からインタビューして検証します。プロトタイプを作成する前にも、質問などによってニーズがあるかどうかを検証していくことを推奨しています。

顧客のところにでかけていっても、すぐに自分の製品について説明したり、「どんな機能が欲しいか」聞いたりするのではなく、まずは顧客がどのように仕事を進めているか、どのような課題を抱えているか、その課題を自社の製品がどう解決できるか、そういうことを調べていきます。

世の中には起業本が山ほどあふれていますが、これほど「実用的」かつ「実践的」な起業本は少ないでしょう。

製品立ち上げのプロセスを4つの大きなステップ、「顧客発見」「顧客実証」「顧客開拓」「組織構築」に分けて、それぞれを数十の小さなステップに細分して説明しています。それによって細かい実践の方法がカバーされています。

起業本の革命児とも言える書籍であり、アメリカでは本書を元にして「リーン・スタートアップ」などの新しい理論や書籍が次々に誕生しました。

この本は素晴らしい本なのですが、ちょっとした弱点があります。

分かりやすく読みやすい本ではあるのですが、分厚く細かく書かれているので、再読したり、事業の最中にちょっと参考にするには重い感じがするということです。

もう一つには、ステップが細かく書かれているのは良いのですが、具体的に書かれすぎていて、実際の事業に当てはめるときにかえってわかりにくいという点です。

そこをカバーするフォロー本として「顧客開発モデルのトリセツ」という電子書籍が出版されました。この本は、アントレプレナーの教科書を読んだ二人の読者が、その本をフォローする解説本として自費出版した本です。

100ページほどの簡潔な電子書籍となっており、いつでもどこでも何度でも読み返しながら顧客開発モデルについての理解を深めることができるようになっています。

私も「アントレプレナーの教科書」を毎回読み返すのは荷が重いと思ってましたので、この電子書籍が出版されたことは福音だと思っています。

顧客開発プロセスを別の角度から見直すことで、顧客開発モデルについてより詳しく、深く理解することができますからね!

ギーク達の破滅の物語

私は普段フィクションは漫画しか読みません。小説や映画などは時間がかかりすぎるとおもって敬遠しています。しかし、主人公がギークとなれば話は別です。

ギーク(geek)とは、私の定義では、理系男性で、自閉的な性格傾向をもつ変人たちのことです。優秀なプログラマーには、このような性格類型を持つ男性が多く居ます。

ここに紹介する三編の小説は、どれも英国の小説で、皮肉で、滑稽でもあり、やや文学的でもあり、主人公のギーク(科学者またはプログラマー)が冒険をして恋をして破滅するという物語です。

ギーク達がもつ幼稚な愛情、または愛情の欠如が物語に乾いた歪みをもたらします。

ギークは他人が苦手であり、他人とあまり関わろうとしない傾向があります。しかし完全に孤独を好むわけでもなく、彼らが他人と関わるときには常に危うさが伴います。

ギークは恋愛が苦手であり、性欲が薄かったり、愛情が薄かったりします。しかし(以下同文)

そうした彼らが人間と関わり社会と関わるときにどのような問題を引き起こすか、冷めた語り口で、ギークの視点から見ていったのが、これらの物語です。

これらの中でも、「ソーラー」で描かれた、ギークのくせに徹底して俗物で好色で無責任でデブでハゲでチビのマイケル・ビアードという人物に好感と親近感を抱きました。

彼は、他人に興味がなく、他人への誠実さへの欠片も無いくせに、セックスとお金と賞賛が大好きという最低・最悪の人物です。そのくせ、血も涙も無い凶悪人物というわけでもなく、徹底して小人物なのです。

このような人物に嫌悪感を持つ人もいるかもしれませんが、私は彼にこそ人間性の真実を見いだします。俗悪な人物でありながらも、成功と虚栄と求めて、人類の発展に貢献してしまったりする、そんな生き様こそ人間的であり人間の真実だと思うからです。

家族愛にあふれた人たちもいれば、他者を顧みずに数式やコードを愛する人もいる、そんな人間の多様性というものが、この人類の発展を生み出してきたのですから。

日本にもこれくらい俗悪なギークがどんどん増えて、俗悪なベンチャー企業をどんどん立ち上げてくれたら面白くなるのになあ、と思いましたよ。もっと欲望にまみれて生きていきましょう。

2012年8月21日火曜日

ひよこ党結党宣言

先日の「出馬してみた」の精神に基づき、本日2012年8月21日、新党「ひよこ党」を結党します。とりあえず私一人しかいない政党で、今後もなんの活動予定もありませんが、結党宣言を書いたので、ここに載せます。

とりあえずfacebookページを作ったので「いいね」してくれると喜びます。

githubにレポジトリを作ったので、誤字脱字などありましたら、pull requestを送ってください。

みんなも新党旗揚げするといいんじゃないかな?


ひよこ党綱領

2012年8月21日、「出馬してみた」の精神に則り、ここにひよこ党を設立する。

ひよこ党は、自由、博愛、理性の原則に拠り、日本を多様かつ寛容で国際的な自由主義・自由経済・民主主義のリーダーとするべく、現実的で理性的な政策を提唱・実行していく。

ここに本党の三大価値観と行動規範を明記し、今後の活動の礎としたい。

* 三大原則

** 自由

自由ということは、21世紀に社会が繁栄するために最も大切なことであると信じます。

21世紀の社会では、価値はイノベーション(改革)からしか産まれません。イノベーションを生み出すのは自由な社会です。規制でがんじがらめの社会からはイノベーションは産まれません。

自由な経済、自由な文化活動、自由な市民生活、自由な政治活動を保証することが国家の果たすべき最も大切なつとめであると強く信じます。

極端に安全性を重視するのをやめ、規制を減らすことにより、日本経済は発展し、より住みやすい国になるでしょう。


では、自由主義とは政策の検討過程においてどのような働きをするのでしょうか? 実例に則して見てみましょう。

私はタバコの煙が苦手で、喫煙できる店などにいると、すぐに健康を害します。個人的には、公共の場所はすべて禁煙であるべきだと思います。しかし、それを法律によって強制するべきではないと信じます。なぜなら、法で絶対的に禁止せずとも、間接的に禁煙の場所を増やす政策をとることができるからです。

例えば、喫煙できる店を免許制にして、その免許に対して税を課すとか、優れた排煙装置を義務づけるなどすれば、必然性もないのに喫煙可能にしている店は減ることになるでしょう。

かといって我々は自由放任主義(レッセフェール)にも与しません。なぜなら市場は失敗するからです。

日本にはスターバックスができるまで禁煙の喫茶店というものは皆無でした。スターバックスはあっという間に日本で大人気になりましたが、それまで「禁煙の店に行きたい!」という非喫煙者のニーズは完全に市場から無視されていたのです。市場が必ずしも良い働きをするとは限りません。もし欧米で反喫煙の動きが無ければ、そうした市場は永遠に開拓されなかったかもしれません。

またタバコのように依存性がある事柄は、自由放任主義に馴染みません。なぜなら人間はそうしたものに対して必ずしも合理的な判断を下せるとは限らないからです。タバコなどの麻薬類や賭博などに関しては規制が正当化されると思います。

しかしながらタバコやアルコールの全面禁止という政策がうまく行くはずはありません。そうすれば禁止をかいくぐる人がでるでしょうし、自分に害を与える行為であっても完全に禁止するのは行き過ぎたパターナリズム(父権主義)であると考えます。重い課税などによって対処をしていくのが穏当であると考えます。

** 博愛

自由な経済や自由な社会を作るということは、社会のあちこちで競争が生じるということです。経済や労働の面だけではなく、恋愛や結婚、学習や文化活動などあらゆる点において競争が生じます。

競争それ自体は素晴らしいことですが、競争に負けた人を救う仕組みが必要です。

全ての国民がなんとか衣食住を得て、教育を受け、基本的な医療を受け、子供を養っていける最低限の社会保障は守らねばなりません。人々が生まれによって可能性が閉ざされることが無いように最大限の配慮をするべきです。

また、社会が競争のメリットを得るためには、不正な競争、不公正な社会慣行や不公正な取引から人々を守る必要があります。年齢や性別によって雇用差別が行われたり、国籍や人種によって住宅が借りられなかったりするような問題に対しては厳正な対処が必要です。

日本人は高い勤勉さや道徳心を持ち、世界中で高く評価されています。しかし日本は自殺率も高く、幸福度もGDPから見て十分に高いとは言えません。それには、寛容さや多様性の低さが理由の一つではないかと考えます。

人を単一の尺度で測り、上下関係や社会慣行によって縛ることが、人々の社会適応を難しくしており、それが不幸、不効率をもたらしている可能性があります。

強固な上下関係にもとづく長期間労働は国民の不幸や精神状態の悪化をもたらしているでしょうし、上下関係にもとづく自由な発想や闊達な議論の阻害は、経済的不効率をもたらすでしょう。

また寛容性の無い社会では、国際化やイノベーションの恩恵を受けにくくなります。多様性と寛容さを持った社会作りをしていくことが望まれます。

** 理性

いまの政治を悪くしている最大の原因は、政治においては人々が理性的に行動しないからです。

多くの人は、具体的なテーマであり、かつ自分の仕事などの経験も知識もあり真剣に取り組んでいることであれば、理性的に考えれば、それなりに良い答えを見つけることができます。

ビジネスのような分野では、多くの人が切磋琢磨して、結果的に競争によって、良い事業だけが残ります。そのために我々はすぐれた製品やサービスを享受することができます。

しかし政治においては、主権者である国民は政治について詳しい情報も持っておらず、真剣に取り組んでいるわけでもありません。さらに意思判断を行うべき対象は、多数の人の価値観や利害が絡み合う難しい事柄ばかりです。

そして新聞やテレビなどのメディアは速報性を重視しますので、物事のもつ多面性や複雑さを無視する傾向にあります。

そのためどうしても感覚的、感情的な意思判断を行うことになり、選挙や世論は必ずしも良い決定をもたらしません。

私たちは、社会科学と自然科学の知見を活用し、情報公開と透明性を旨として、感情にながされない論理的で冷静な政治を行います。とくに経済的合理性を大切にして政策を行います。

* 行動規範

** 保守主義の原則

「ものごとがそうなっているのは、そうなったからだ」(コンサルタントの秘密、G・M・ワインバーグ著、63ページより)という原理を尊重します。

すなわち、今の社会の在り方というものは、これまでの人々の在り方や努力の結果としてここにあるものです。そこに良くない点があったとしても、それはそれなりの経緯をへてそのようになっているということです。

むやみに今の社会の在り方を否定して、闇雲に改革に走るべきではありません。

なぜ今の社会がこうであるのかを真摯に見つめて、安全に少しずつ変革を行い、それによって損失を被る人を尊重しながら進めていきます。

小さな変革であってもリスクが少なくメリットの大きいものを、大げさな改革より優先します。

どうせ抵抗する人がいる以上、そんなにすぐに変化を起こすことなんかできっこないのですから。他人のやり方を強制的に変えさせることはできないし、他人にやりたくないことをさせることもできないのです。(コンサルタントの秘密、G・M・ワインバーグ著、166~170ページ)

私たちは理想よりも現実と実利をつねに大切にします。

** 党派主義からの脱却

理想よりも現実を大切にすべきだといっても、票を取るために嘘をついたり、世論におもねって間違った政策を実行したり、意味も無く他の政党を攻撃したりすることは、国民を裏切る行為です。

私たちは、得票数や支持者を増やすことにこだわりません。

私たちの目標は議席を取ることではなく、日本や世界をより良い場所に変えることです。

誰が言ったことであれ、良いことには賛成するし、悪いことには反対します。

** 情報公開の原則

今の日本の問題点の一つは、政府による分かりやすい説明がないことです。現状の情報公開の体制・手法は、分かりにくく、問題の全貌を理解するに足るものではありません。

私たちは可能な限り、全ての情報をわかりやすく公開します。とくに「何が問題なのか」「なぜこのように考えるのか」「どういう手が考えられるのか」などを重視して公開します。

世の中の問題について、マスメディアよりも深く多面的に掘り下げた分析を公開します。

例えば、福岡空港のアップグレード検討プロジェクトなどは良い情報公開を行っていたと考えます。「なぜアップグレードが必要なのか」「どのような手法が考えられるか」などといったことを分かりやすく公開し、現空港の増設案が決定されました。


2012年8月14日火曜日

PBKDF2によるパスワード暗号化の手順

会員制ウェブサイトのように、ユーザからのパスワードを保存するシステムでは、必ずパスワードを暗号化して復元できないようにして保存しなければなりません。なぜなら、もし情報漏洩が起こったときにユーザのパスワードが漏洩してしまったら、他のウェブサイトなどへも侵入され、致命的な結果につながりえるからです。

もしあなたが技術者でなくても、技術者や外注先にたいしてパスワードの暗号化保存を要件に入れるべきです。そのときはこの記事をお見せください。

(もちろん全てのウェブサイトで使うパスワードを変えるのが望ましいでしょうし、もし可能ならパスワードに頼らないハードウェアトークンによる認証などの強力な仕組みを採用するのが良いのでしょうが、現状では皆がそこまでできていないのが現実かと思います。)

これまでですと、パスワード保存にはSHA1やMD5のハッシュ関数の適用などによって暗号化していることが多かったかと思います。しかし、いまどきではSHA1関数などは一瞬で計算が終わってしまいますので、総当たり攻撃をされると弱いという問題があります。

それを多少なりとも改善するのがPBKDF2によるパスワード暗号化手法です。

PBKDF2はパスワードから暗号鍵を導出するための関数ですが、SHAなどのハッシュ関数(HMAC)を繰り返し何千回もかけることにより、総当たり攻撃に時間がかかるようにしています。

PBKDF2はOpenSSL 1.0.0以降から実装されましたので、簡単に利用することができます。以下はRuby 1.8.7でのコードですが、他の言語でもOpenSSLを使えば簡単に利用できるかと思います。[1]

require 'openssl'
key = "hogehogehogehoge" # 秘密の文字列
user.salt = OpenSSL::Random.random_bytes(16).unpack('h*')[0]
user.iteration = 10000
user.hashed_password = OpenSSL::PKCS5.pbkdf2_hmac(password,user.salt+key,user.iteration,16,"sha256").unpack("h*")[0]
user.save

この10000という数字が繰り返し回数ですので、これを増やすことによって安全性を高めることができます。この数をユーザーごとにデータベースに保存しておけば、途中で繰り返し回数を高めて安全性を強化することもできますね。

saltというのは、ユーザーごとにランダムの文字列をパスワードに加えることで、ユーザーごとに暗号化結果が異なるようにし、総当たりをやりにくくするとともに、推測をしにくくします。これはデータベースに保存しておかないと認証できなくなってしまいます。

keyというのは、saltに秘密情報を付加しておくことで、データベースだけが流出した場合に、鍵を総当たりしにくくするための付加鍵です。これは私の思いつきなので、意味があるかどうかよく分かりません。

PBKDF2は、他にもAESなどの暗号鍵をパスワードから導出したりすることにも利用することができます。[2]

弱点としては、こうした計算量に依存するものは、クラウドやハードウェアの力によってかなりのスピードで破ることができてしまうことがあります。[2]

計算速度が命なので、同じような関数をRubyやJavaやPHPなどで独自実装することは避けるべきだと思います。Cで記述されたOpenSSLのような高速な実装を使わないと、すぐに破られてしまうでしょう。

また、PBKDF2関数を単に2回適用することで繰り返し回数を単純に増やすのと同じ結果を得ることはできないようですので、既存のパスワードを定期的に強化していくのは難しいのかなあと思いました。(このへん方法があれば知りたいです)

パスワードに依存しない認証方式がもっと普及すればいいんでしょうが、一向に普及する兆しもないですね。OpenIDといっても、結局は他の同種のサイトに依存してるだけですし。

参考:
  1. パスワードのハッシュに使うべきPBKDF2、Bcrypt、HMACの各言語実装一覧 - Dマイナー志向
  2. PBKDF2 - Wikipedia, the free encyclopedia

2012年7月21日土曜日

IBM BlueGene/Qのセミナーを受けてきたよ


IBM東京本社で行われたBlueGene/Qのセミナーを受けてきました。ブロガー向けセミナーということで、IBMの顧客でもなんでもない私がセミナーを受けてきました。2時間超にわたるセミナーの全貌を紹介するわけにはいきませんので、いくつかポイントを記しておきたいと思います。

BlueGene/QはIBMが開発したスーパーコンピューター(HPC)です。

HPCは、通常のコンピュータでは行えないような大規模な科学計算を行うことを目的に作られたコンピュータです。流体力学など、複雑な非線形現象のシミュレーションに主に使われます。計算科学という、理論、実験に続く、第三の研究手法を実現しています。

BlueGene/Qを使ったSequoiaという米ローレンス・リバモア研究所のHPCが、日本の富士通による"京"から世界最高速の座を奪取したことで話題になりました。BlueGene/Qは、他にも多くの顧客に導入されており、HPCのTop20に数多く食い込んでいます。

BlueGene/Qの特徴は、低消費電力(他機種にくらべ、2倍を超える電力効率)、省スペース("京"にくらべ、1ラック当たりの性能が17倍)であることです。

なぜ低消費電力と省スペース性が重要になるかというと、現在のHPCは、とてつもなく巨大で電力をバカ食いするようになっており、それが性能を頭打ちにする限界になっているからです。

電力を食えば、熱を出すので、その熱をうまく排出しなければなりません。スペースを食えば、それだけ長い距離の配線をせねばならず、配線だけでも大変なことになります。

日本の"京"は、たしかに高性能なのですが、BlueGene/Qに比べると電力効率やスペース効率で劣るために、巨大な体育館のような専用の建物を必要としています。これでは、普通の研究所などに導入することができません。

"京"は、「2位じゃダメなんですか?」という言葉で有名になりましたが、世界最高速のHPCを作ること自体は、科学的、産業的にはあまり重要な意味の無いことです。HPCは科学に使われて初めて意味をなします。研究所などに導入しやすいBlueGene/Qのようなシステムを作って、多くの大学や研究所に導入して誰でも使えるようにすることこそ意味があることです。その点では、BlueGene/Qの導入実績を見れば大成功といえます。

IBMの説明によると、"京"も、電力効率で、他の通常のx86+GPUベースのHPCに比べると優れているということです。しかしBlueGene/Qの圧倒的な効率の前には、それもかすんでしまいます。

IBMはBlueGeneシリーズを10年以上前から研究しており、一貫して低消費電力にフォーカスしてHPCを開発してきたということです。組み込み用のPowerPCプロセッサを低電圧、低周波数で動かすことで、高いワット当たり性能を確保しています。

また組み込み用プロセッサをSoCとして、通信回路など全ての回路を一つのチップにまとめています。外部に必要なのはDRAMだけです。それと水冷機構を使うことで、驚くべき高密度実装を可能にしています。ラック当たり16,384コアという驚異の密度です。

そのため、計算機室にサーバラックを4つか5つならべれば、世界最高クラス(ペタフロップス級)のHPCが手に入るという寸法です。水冷なので、工事などはちと面倒かもしれませんが?

BlueGene/Qも、その他のHPCと同じようにLinux+MPIという並列プログラミング環境による標準的なコードを動かすことができるそうです。一つのプロセッサあたり16コアを含み、64スレッド並列で動かすことができます。各コアとメモリはクロスバーで接続されSMPとして動作します。(Intelがクロスバーを諦めてNUMAにしているのとは対称的ですね。なぜ設計思想が違うんだろう?)

IBMでは、BlueGene/Qの他にも、x86ベースのHPC、Power7ベースのHPCを販売しています。顧客によって、スレッド当たりの性能や、I/O性能などのニーズが異なるため、多様なラインアップとしているそうです。

今後しばらくハイエンドのHPCはBlueGene/Qの独壇場となるでしょう。100年以上前からコンピューティングの最先端に居続けるIBMという企業の実力は驚くべきですね。我々ウェブデベロッパには全くご縁が無い企業ではありますが・・・

IBMもPower 7を使った大型HPCプロジェクトのBlue Watersの開発に失敗し、プロジェクトから撤退していたりするので、もちろん彼らも万能というわけではありませんが。

"京"はそもそも完成した計算機の性能で一位を目指すのではなく、製品自体の効率や売上で一位を目指すべきでしたね。

参考記事: