日に以て親しむ－新井俊一ブログ

2012年9月2日日曜日

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

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

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

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

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

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

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

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

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

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

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

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といっても、結局は他の同種のサイトに依存してるだけですし。

参考:

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の開発に失敗し、プロジェクトから撤退していたりするので、もちろん彼らも万能というわけではありませんが。

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

参考記事:

2012年7月20日金曜日

A/BテストツールのOptimizelyを使ってみた

Optimizelyは、ウェブサイトのA/Bテストを行うための洗練されたソフトウェアです。

A/Bテストとは、ダイレクトマーケティングでは昔から使われてきた手法で、顧客に対して2種類のダイレクトメールなどを行って、反応が良いものを選び出す、実験の手法です。

これによって、マーケティングのような感覚的な分野においても、データをもとに改善を積み重ねる経営を行うことができるようになります。

最近では、ウェブサイトにおいても顧客にN通りのパターンを見せて、どれが購買に結びつくかなどのA/Bテストを行うことが増えてきました。

A/Bテストツールには色々なものがあり、Google Analyticsなど無料のものもあります。

その中で、Optimizelyは有料ですが、使いやすさに特化されており、話題を集めています。

Optimizelyを使ってA/Bテストを行う場合、HTMLエディタを使ってWYSIWYGで変更内容を編集する方法と、Javascriptを自力で書く方法があります。

静的コンテンツであれば、HTMLエディタで簡単に編集することができますので、プログラマ不要でA/Bテストを行うことができます。

動的コンテンツは、自力で変更案を適用するJavascriptを書かなければなりません。それでも結果測定、集計や統計検証などは自動で行ってくれ、美しいグラフも書いてくれるので、それなりに役に立ちます。

実際に弊社でもちょっとした文字の変更などを試してみたのですが、クリック率の0.7%改善という結果が得られました。しかし、もっと大幅な改善を期待する場合には、変更案を考えるのがなかなか大変だなー、と思いました。

円高の昨今ですから、月79ドルの利用料は高いものではありませんが、月間20,000ページビューを超えると1,000ページビューあたり7ドルという高額の追加料金を取られるので、それは結構問題です。

Google Analyticsなら無料で使えますから、そちらの機能で満足できる人は、あえてOptimizelyを使うまでもないでしょうね。でもたぶんGoogle Analyticsのウェブテスト機能では物足りないし、サポートも足りないので使い物にならないと思いますけど。

今の時代、A/Bテストを使ってウェブサイト反応率を改善していくのは常識になりつつあります。われわれウェブ業界人はA/Bテストツールの一つや二つは使えるようになっておく必要があるのではないでしょうか。

2012年7月12日木曜日

Amazon DynamoDBがウェブのインフラを塗り替える

Amazon Web Services (AWS)は、すごい勢いで機能を増やしており、いわゆるクラウド業界の中で圧倒的な存在感を示しています。AWS ＝クラウドと言っても過言では無いでしょう。

AWSは、他のレンタルサーバーやホスティングと比べたり、自社でデータセンターを借りるのに比べると、だいぶ割高な設定になっています。しかし、その機能は他のサービスを圧倒しています。

AWSがすごいのは、分散ストレージであるS3などの分散システムを管理不要で提供していることです。

分散システムには、耐障害性、性能(スケーラビリティ)などの点で大きなメリットがありますが、実際に分散システムを管理運用するのはとても面倒で煩雑な作業になります。弊社でも分散ストレージを自社開発運用していますが、かなりややこしく、可能な限りやりたくない作業です・・・

とくに分散システムのソフトウェア開発者と、分散システムの管理運用者が異なる場合には、ハードウェアとの相性や、ソフトウェアの細かい癖、ソフトウェアのバグなどを克服してうまく分散システムを運用するのは至難の業となります。

そのため、弊社では、わざわざ自前で分散ストレージのソフトウェアを自社開発しています。機能が少ない簡易的な自社製品の方が、機能が多くて挙動が完全に把握できない他人の作品よりもマシだからです。

その点で、自前でソフトウェアを開発し、サービスを自前で運用しているAmazon Web Servicesは、分散システムの理想型と言えます。これができる企業は、世界でも多くはないでしょう。

Amazonのさらなる強みは、Salesforceのようなエンタープライズ業界の企業と違って、ずっとセンスの良いAPIや使い勝手の良いUIや分かりやすいドキュメントを提供していることです。

さて、本題に移ります。

先日登場したAmazon DynamoDB (分散NoSQLデータベース)には私も強い興味を抱いており、このたびAmazonが開催したDynamoDBセミナーに参加してきました。そこから得たDynamoDBの情報と印象をお伝えしたいと思います。

私はMongoDBなどの既存のNoSQLには極めて懐疑的な見方をしていました。先述のように、分散システムを運用し、期待通りの性能を安定してたたき出すにはかなりの苦労が伴います。それを考えると、どうしても極めて高いスケーラビリティの必要なソーシャルゲーム業界など以外では有用性はないだろうと考えていました。

しかしDynamoDBは違います。テーブルを作成し、必要なスループット(毎秒の読み書き数)を設定するだけで、勝手に分散データベースを自動で作成・運用してくれます。スループットはリアルタイムに変化させることも可能です。これなら何の苦労もなく分散データベースを運用することができます。

DynamoDBの特徴は、極めて簡単な運用、驚愕のスケーラビリティ(高い書き込みスループット)、高可用性の３つです。スケーラビリティは驚くほどで、最高で、秒間200万リクエストの実績があるそうです。データは自動的にリージョン内の3つのデータセンターにレプリケーションされ、高い可用性を誇ります。

DynamoDBの弱点は、現時点では機能がめちゃくちゃ限られていることです。複雑なクエリはもちろんのこと、テーブルにプライマリキー以外のインデックスを貼ったり、バックアップを取ったりする機能すら標準では備わっていません。なんとデータ型も、整数と文字列とそれらの集合の4種類しかありません。

複雑なクエリを実行したり、バックアップを取ったりするためには、Elastic Map Reduce (Hadoop)を利用して、Hiveというクエリマネージャを使ってクエリを実行する必要があります。これははっきりいってややこしいです。

しかしワークショップに参加して、実際にコーディングをして使ってみて思ったのは、実際には意外と色んな用途に使いやすいかもしれないということです。

EC2から同リージョンのDynamoDBにアクセスする場合、レイテンシは極めて短く、データも高速に転送されます。そのため、誇張気味に言うと、ローカルにあるファイルのような感覚で扱うことができます。これなら、小規模システムの場合は、インデックスなど使わずとも、フルスキャンを多用しちゃってもいいのかな、と思いました。

かなり曲者で使いこなしが難しい印象のDynamoDBですが、既にかなり導入実績があり、どんどん売上が伸びているそうです。ソーシャルゲームなどの業界にとっては福音と言えるのでしょう。

将来的に、二次インデックスがサポートされ、データ型もいろいろと実装されてきて、複雑なクエリをうまく実行できるライブラリなどがでると、ソーシャルゲーム業界に限らず、一般のシステムも一部はこれで置き換えられていくのではないかなと思います。RDBMSの運用はいささか面倒ですからね。

EC2, S3, DynamoDB, Cloudfrontの登場によって、スケーラビリティや高可用性を実現するということはお金さえ払えば誰にでもできる仕事になってしまったな、という印象です。

弊社としても、今後はAWSの使いこなしに力を入れていこうと考える次第です。

ところで、Amazonワークショップ内で、2時間で「並列的にニコニコ動画のタグをクロールして集計するスクリプト」を書いたので、おまけとして以下に乗せておきます。DynamoDBの並列性を確保する機能であるConditional PutとAtomic Counterを活用することで、簡潔に並列集計を実現しています。

require 'uri'

require 'net/http'

require 'kconv'

require 'rexml/document'

require 'rubygems'

require 'aws-sdk'

AWS.config({

:access_key_id => "",

:secret_access_key => ""

})

dynamo_db = AWS::DynamoDB.new(:dynamo_db_endpoint => "dynamodb.ap-northeast-1.amazonaws.com")

videos = dynamo_db.tables["nicovideo_videos"]

videos.load_schema

tags = dynamo_db.tables["nicovideo_tags"]

tags.load_schema

# タグ収集、カウント

loop {

vid = (rand * 17392999).to_i

video_id = "sm#{vid}"

puts video_id

begin

url = URI.parse("http://ext.nicovideo.jp/api/getthumbinfo/#{video_id}")

http = Net::HTTP.new(url.host, url.port)

result = http.get(url.path)

xml = REXML::Document.new(result.body)

next unless xml.elements['//title']

title = xml.elements['//title'].text

puts title

videos.items.put({"video_id" => video_id, "title" => title},{:unless_exists => "video_id"})

xml.elements.each('//tag') { |tag|

tag_name = tag.text

puts tag_name

t = tags.items.put({"tag_name" => tag_name, "count" => 1}, {:unless_exists => "tag_name"}) rescue nil

unless t

t = tags.items.at(tag_name)

t.attributes.add({"count" => 1})

end

}

puts "\n\n"

rescue Exception => e

p e

end

}

# 集計

rank = {}

tags.items.select { |tag|

count = tag.attributes['count'].to_i

tag_name = tag.attributes['tag_name']

# puts "#{count}: #{tag_name}"

rank[count] ||= []

rank[count] << tag_name

}

rank.keys.sort[-10..-1].reverse.each_with_index { |count, i|

puts "#{count}件: #{rank[count]}"

}

登録: 投稿 (Atom)