2012年02月05日
![{book['rank']](http://booklog.jp/images/rank/4.gif){kind=icon}
![{book['rank']](http://booklog.jp/images/rank/5.gif){kind=icon}
2012年01月04日
Trac でコンポーネントごとに異なるデフォルト送信先にメールを送る
昨年末の話だが、Trac でコンポーネントごとに異なるデフォルト送信先にメールを送るようにして欲しいと言われて、TracHack を漁っていたところ、DefaultCC Pluginというプラグインを見つけた。たぶん、これがベスト・ソリューション。チケットの発行をフックして、コンポーネントごとに登録してある DefaultCC 用メール・アドレス(trac.db の component_default_cc テーブルに登録される)を、自動的にチケットの 'cc' フィールドに追加してくれる。
ただし、デフォルトのままだと 'cc' フィールドへの追加を(存在しない)'DefaultCC Plugin' ユーザで行なってしまう。僕のところの Trac は ticket_change の author に対してもメールを送る設定になっているので、このままだと 'DefaultCC Plugin@yourdomain.example.com' とかにメールを送ろうとしてしまう。DefaultCC Plugin に含まれる main.py にちょっとしたパッチを当てるのが吉。
--- main.py.org 2012-01-04 11:02:22.625498607 +0900
+++ main.py 2012-01-04 11:02:31.195562621 +0900
@@ -40,7 +40,7 @@
if ticket['cc']:
ticket['cc'] += ', '
ticket['cc'] += comp_default_cc.cc
- ticket.save_changes('DefaultCC Plugin', '')
+ ticket.save_changes(ticket['reporter'], '')
def ticket_changed(self, ticket, comment, author, old_values):
return
2012年01月02日
2011年11月、12月に読んだ本
昨年 11月、12月に読んだ本は、わずかに 2冊。プロジェクトが忙しくて自分の時間が取れなかったこともあるが、読書習慣自体が失なわれたというのもある。今年読んだ本は、昨年の 100冊から大幅ダウンの 53冊。やっぱ年間 100冊という目標は無理があるなぁ。今年は年間 60冊(月5冊)くらいを目処に読もう
2011年11月01日
2011年10月03日
2011年09月01日
2011年08月01日
2011年07月01日
2011年06月01日
![{book['rank']](http://booklog.jp/images/rank/2.gif){kind=icon}
2011年05月01日
2011年4月に読んだ本
2011年4月に読んだ本。この4月に異動になって、通勤時間(電車の中で本を読む時間)が大幅に減ったので、本はほとんど読めなくなるかと思ったが、そうでもなかった。コンピュータ系の技術書を読む意欲も多少復活。
2011年04月17日
Trac でもっと細かい粒度のアクセス権設定をする
Trac 系のコネタをもう一つ。デフォルトより細かい粒度のアクセス権設定をする。
もともとは「そもそもこの Trac は…」という内容を WikiStart のページに書いてしまったので、このトップ・ページはログインしていない人も含めて全員が見られるようにしておきたい。また、Wiki にかかれるいくつかの技術情報は広く見てもらいたいものなので、やっぱりログインしていない人でも見られるようにしておきたい。でも、いくつかのページはログイン権限を持っていない人には見せたくない。デフォルトの権限設定では、WIKI_VIEW 権限の有無しか設定できないので、こんな器用なことはできない。
幸い、Trac 0.11 からはこのようなアクセス権限の微妙な制御ができるような plugin を組み込み可能になっている。Trac Fine Grained Permissions が参考になるだろう。Trac 0.12 では Authz ライクなアクセス権限設定を可能にする AuthzPolicy がデフォルトで含まれている。0.12 では、trac.ini の [component] セクションで authzpolicy コンポーネントを有効化し、[trac] セクションの permission_policies に AuthPolicy を追加する。permission_policies は記載された順番に適用されるため、順番に意味がある(詳細はマニュアルを参照)。また、[authz_policy]セクション authz_file で、設定ファイルの場所を指定する。
[component] tracopt.perm.authz_policy.authzpolicy = enabled [trac] # permission_policies = DefaultPermissionPolicy, LegacyAttachmentPolicy permission_policies = AuthzPolicy, DefaultPermissionPolicy, LegacyAttachmentPolicy [authz_policy] authz_file = /path_to_policy_file/authzpolicy.conf
WebAdmin からコンポーネントを有効化すると、[trac] セクションに空の authz_file を作ってくれるのだが、ここにファイルを設定してもダメ。一瞬ハマッた。ちゃんとマニュアル通りに [authz_policy] セクションに書くこと。
auth_policy ファイルの書き方は、上のマニュアル参照。Wiki だけでなく、Ticketや SVN についても、もっと細かいアクセス権限の設定が可能だ。僕が入れた定義はこんな感じ
# 名前が Private で終わるページは、ログインが必要 [wiki:*Private] authenticated = WIKI_VIEW, WIKI_CREATE, WIKI_MODIFY, WIKI_RENAME * = # それ以外のページは、デフォルト通りの設定 [wiki:*] authenticated = WIKI_CREATE, WIKI_MODIFY, WIKI_RENAME * = WIKI_VIEW
やっぱり上から順番に見ていって適用される(適用できる定義が無かったときのみ、次の定義が読まれる)ので、このファイルも順番に意味がある。これも一瞬ハマった。
Trac でユーザ定義の「権限」を追加する
最近、仕事で Trac サーバを立ち上げる機会があったので、コネタを一つ。ユーザ定義の「権限(TICKET_VIEW などの類)」の追加の仕方。
この手の BTSを会社で使おうと思うと、チケットをアサインされた人がチケットをクローズした後に、プロジェクト・マネージャが「クローズを承認」するというワークフローにしたくなる。ワークフローのカスタマイズ自体は Trac 0.11 くらいからすでにかなり柔軟にできるのだが、しかし、マネージャ用に新しく「承認権限」を作りたいと思うと、結構なコード量のプラグインを入れたりして、なかなか面倒だった。
Trac 0.12 では ExtraPermissionProvider というコンポーネントがデフォルトで組み込まれており、ユーザ権限を自由に追加できる。コンポーネントはデフォルトで無効になっているため、trac.ini の [component] セクションに
と書く。または AdminModule が入っていれば、ウェブの管理画面、プラグインのページから、Trac 0.12.x 内にある上のコンポーネントを有効にする。[component] tracopt.perm.config_perm_provider.extrapermissionsprovider = enabled
あとは、trac.ini の [extra-permissions] セクションにに追加したい権限を記述するだけ。
[extra-permissions] # TICKET_REIVIEW 権限を追加。 # 既存の TICKET_ADMIN 権限が TICKET_REVIEW 権限を含むようになる。 ticket_admin = ticket_review # 上のマニュアルにある例。EXTRA_VIEW、MODIFY、DELETE の3権限を作った上で、 # EXTRA_ADMIN という 3権限を含む権限を新たに作る extra_admin = extra_view, extra_modify, extra_delete # 上のマニュアルにある例。ADMIN 系のメタ権限を作りたくない場合は、 # 等号の左側を '_' ではじめる。 _perms = extra_view, extra_modify
2011年04月01日
2011年4月に読んだ本
2011年3月に読んだ本は、6冊。今年は読んでる本は少な目だが、比較的当たりが多い。
Michael Gates Gill
読了日：03月21日
![{book['rank']](http://booklog.jp/images/rank/3.gif){kind=icon}
2011年03月01日
2011年2月に読んだ本
2011年02月01日
2011年01月25日
「何でも心情をTwitterで吐露することの危険性」じゃない気がする
ちょっと前の話題だけれど、最近思うところがあったので、メモ。
個人的には、これは(ご自身も言われている通り)勝間さんのスルー力が無さ過ぎだと思う。もちろん @koisyo_kaonashi はサービス業に携わる人間として最低の行為を行なったわけだが、だからと言って、それに 140字を大幅に越える反論を送りつけなければ気がすまないというのは、大人気ない。せめて、普通に 140字で反論していれば、(お互いにとって)単なる洒落で済んだだろうに。
と、書きたかったのはこんなことではなくて、本題は:
これは僕自身も感じていることなのだが、facebook にしろ twitter にしろ、やっているうちに段々、自分の「外向きのアイデンティティ」が失なわれていく気がしている。
人間は、その場その場に応じて、それぞれ異なる「自分」を演じているものだ。たとえば、ある人は会社では「課長」だが、家では「パパ」だし、趣味の世界では「上級アマチュア・ゴルファー」だったりする。しかし、twitter 上では1つのアカウントで「自分」を表わしていて、かつ、それぞれに異なるコミュニティからフォローされているため、えてして他人に「異なる場の自分」を見せてしまいがちだ。もちろん、それには自分の異なる側面を見てもらえる(「あの課長も、家ではあんなにいいパパなのか」とか「パパもゴルフやってるときはこんなに楽しそうなのか」とか)というプラスの効果もある。しかし、ときとして、それぞれの役割が混乱して、見せるべきではなかった自分を、見せてしまうこともある。
今回の話も、「店長」という役割と「勝間和代が嫌いな一個人」という役割、あるいは「多数の著作がある有名人」という役割と「食事を楽しむ一個人」という役割が混乱した結果だ。もともとは、「勝間和代が嫌いな一個人」としての @koisyo_kaonashi が、「多数の著作がある有名人」である @kazuyo_k に対して「大嫌い」と言っただけの話なのだが、これが twitter 上では「店長」としての @koisyo_kaonashi が、「食事を楽しむ一個人」の @kazuyo_k に向かって言ったことにもなるから、妙な話になった。@koisyo_kaonashi も「食事を楽しむ一個人」の @kazuyo_k に向かってこんな口の聞き方はしないはずだし、@kazuyo_k も「勝間和代が嫌いな一個人」としての @koisyo_kaonashi に何を言われてたところで別段気にもしないはずなのに、だ。
というわけで、結論というほどの結論は無いのだが、「外向きのアイデンティティ」が失なわれていく時代にあっては、相手が演じている役割をコンテキストから読み取る能力も、また、求められているのだなぁと感じた次第。もちろん、お互いに。
ちなみに、twitter で複数アカウントを使いわければいいじゃないかという話もあるが、それはまた別の議論。Dana Boyd 'Autistic Social Software' も参照。
2011年01月10日
[読書] 深海のYrr
Booklog から「ブログに貼り付け」の機能が付いたようなので、貼ってみる。
我々のすぐ隣にある未開の宇宙、深海が人間に牙をむき、クジラが船を襲い、津波が都市を破壊し、未知のウイルスが人間の生活を踏み潰していく描写は、微に入り細を穿って圧巻の一言。ラスト間際に描かれる人間の醜悪な狂気も、真に迫って素晴しい。しかし、正月早々、人がたくさん死ぬ小説を読んだのはよくなかったかもしれない…。
2011年01月03日
2010年12月01日
2010年11月01日
2010年10月に読んだ本
2010年10月に読んだ本。今月は 3冊しか本を読まず。まぁ、そういうときもある。仕事が忙しいと、電車の中で眠ってしまうので、なかなか読書計画通りに読み進められないのだ。
2010年10月01日
2010年09月01日
2010年08月01日
2010年07月26日
訃報: 森毅
高校時代にモリキの本を読んで、数学者にあこがれたし、京大にあこがれた。もっとも、僕の入学と退任(国憲の豊田と並ぶ楽勝科目で、惜しまれつつ去った)が同じタイミングだったので、記念講演か何かを聞いたことがあるだけで、授業を受けることはできなかった。
20年ぶりくらいで、「現代の古典解析」でも読み返すか……。ご冥福をお祈りいたします。
2010年07月22日
Agile Conference Tokyo 2010 に行ってきました
Agile Conference tokyo 2010に参加してきた。
300人程度入る会場がほぼ満席と、あいかわらず Agile に関する注目度は高い模様。会場の様子やセッションの内容については、多くの人が報告してくれると思うので、僕は簡単に所感を。あと、Togetterまとめ。
Key Note
Key Note は ThoughtWorks 社の Jez Humble 氏。テーマは CI。
従来、アジャイルで最も効果的なプラクティスはテスト・ファースト、あるいは単体テストの自動化だと言われてきたが、昨今は CI がその座を奪いつつあるようだ。後の飯田さんのセッションでも同様の話があったのだが、CI は取り組みが容易(環境さえ作れば、チームの意識改革なしに始められる)で、効果が高いところが魅力。他の Agile プラクティス同様、「とにかく一度やったらやめられない」ことは間違いない。というわけで、CI の素晴しさについては省略。
印象に残った話は、「CI に非機能要件(性能など)テストの実行を組み込むことで、リリース 1ヶ月前になってアーキテクチャの変更が必要になるような事態を避けられる」という話。Agile とアーキテクチャは依然として明確な解のない問題の一つだが、CI と自動非機能テストによって、ある種のアーキテクチャ・ブレーカーを早期発見することは可能だ、というのは新しい知見であった。
その他、CI 導入のプラクティスについて、「最初から全てを自動化する必要はない。リリースに際して一番オーバヘッドになっている場所、一番面倒な場所を効率化(自動化を含む)することから始めて、徐々に CI に近付けていく」。
IBM CALC Tool の紹介
大規模、分散環境、受託開発の Agile を支える Rational ツールのご紹介。
大規模、分散開発を進める上で、「ツール」の活用は無視できないトピックだが、実は、個人的にはあんまり興味が無い。ホワイトボードに勝るツールを使ったことが無いのが原因かもしれない。
セッションの終わりにくだらない質問をしたら、「チームコンサート超入門」という本をプレゼントしていただいた。どーもです。読ませていただきます。
IPA 非ウォーターフォール型開発の調査
IPA SEC の松田所長によるプレゼンテーション。非ウォーターフォール型開発に関する調査 (必読!!) からの抜粋。
ウォーターフォールを「はだかの王様」に例えていたのが面白かった。曰く、ウォーターフォールで総合テスト前までの工程は、「はだかの王様」で二人の服屋が透明な服を作っているのと同じだと。「ほら、裁断してますよ、織ってますよ」と言うものの、何も見えないし、何も触れない。もちろん、ウォーターフォール開発をしている人達は実際に物を作っているわけで、この批判は不適切なのだが、しかし、ユーザ側から見るとそう見えてしまうというわけだ。
その他、統計データで Agile プロジェクトの成功確率は 77.5% という話も示唆に富んでいた。普通のプロジェクトの成功確率は 60〜70% と言われているので、やはり Agileの効果が高いことが判る。ものの、銀の弾丸ではないことも明らかだ。というわけで、一回失敗しても、そこであきらめないこと!
Agile は生産性の向上よりも、品質や保守性に有効(向上した分の生産性は、すでに品質や保守性の向上に注ぎ込まれてしまっている)という見解は、僕の実体験ともマッチしていて、納得できるところ。
あと、「多重請負構造を変革しないとダメだ〜」という話。僕も契約形態の問題(請負契約と Agile がアンマッチ)については意識していたのだが、多重請負構造が抱える問題については、若干意識が薄い部分があった。反省。
日立SAS COMMONDATION Reel
日立SAS が実践した「アジリティ開発手法」についての解説。通常のウォーターフォール開発の、開発部分だけ(要件定義とユーザ受け入れを除く部分)に Agile 開発のプラクティスを適用したような開発方法論で、現在の日本型受託開発に何とか Agile 開発のメリットを取り入れようとした試みと理解した。
正直、Agile 開発の最も重要な点である「ビジネス価値の追及」、「小さく頻繁なリリース」、「顧客からのフィードバックに基づいた変化」といった点がおろそかにされており、やはり(顧客を巻き込まずに) SIer 主導で Agile 開発に取り組むという考え方には無理があるという印象を受けた。
もっとも、登壇者の英さんもそのあたりは認識していて「Agile 開発、と呼ぶのはおこがましいので、アジリティ開発と呼んでいます」と言っていた。日本の商習慣に適合しつつ、アジリティを兼ね備えた開発方法論を創出しようという志は素晴しく、感銘を受けたが、「もうすこしがんばりましょう」という感じ。
Microsoft VS2010の紹介
スーツのコスプレが似合わない、長沢さんによるプレゼンテーションは、VisualStudio2010 Team Foundation Server のデモが中心。
なぜか MacBook 上の Eclipse から、TFS と連携して、Java で CI するデモが楽しかった。つーか、MS Project と競合しているような気がするんですけど、どーなんでしょ。
アジャイルはじめの一歩
NEC ソフトの飯田さんが、Agile 開発に取り組んだときの物語。
印象に残ったのは「Agile 開発をやって、とにかく楽しかった」という話。楽しいからこそ、もっといいコードを書こうとするし、もっと素晴しいシステムを作ろうとするし、もっと顧客のために役立つものを作ろうと思う。Twitter で誰かが「Agile って、楽しさドリブン開発だよね」と言っていたが、まさにその通りだと思う。
あと、最初の適用プロジェクトでは大成功だったんだけど、2つ目のプロジェクトでは苦戦したという話。会場からも「『2回目失敗説』は良く聞く」という声があり、どうも Agile 開発にとって 2つ目のプロジェクトというのは鬼門になることが多いらしい。1回目があまりに上手く行き過ぎた場合の副作用で、どうしても適用範囲やプロジェクト規模、制約条件の見極めが甘くなってしまうのだろう。
トーク・セッション
最後は、登壇 + IBM Distinguished Engineer の榊原彰さんを加えたトークセッション。
品質
最初のテーマは品質。Jez さん「日本は、おそらく世界で唯一、ウォーターフォール開発で品質を確保できている国」。そっかー、ここでもガラパゴスなのか……。ウォーターフォールでも高品質なシステムを構築できることを示した実証例ではあるものの、アジャイルでやった方がもっと安く、簡単に高品質を確保できるを確保できるよ、と続く。
同じ Jez さんの「テストフェーズの後に、修正フェーズが無いので驚いた」という話が会場内ではウケていたのは意外だった。うちの会社はちゃんと修正のための期間を積んでるけどなぁ。もちろん、お客様に対して「前工程の不良を修正する期間分のお金をください」とは言えないので、テスト期間の中に埋め込んじゃってるけど。
松田さんが Agile はまだプラクティスの集合体であり、「エンジニアリング」になっていない(ので、みんな品質確保ができるかどうか不安を持つ)と指摘する一方で、榊原さんが「Integration Test まで何ができあがるのか確信を持てないような開発手法は、そもそもエンジニアリングではない」と言っていたのが好対照だった。
大規模
2つ目のテーマは大規模について。長沢さん「VS2010 の開発は 3,600人体制だったけど、scrum ばばーんだぜ」。榊原さん「IBM の Jazz だって、120人体制で Agile ばばーんだお」。日立SAS の英さん「製品開発と SI 受託の大規模開発はちげーだろ、おまいら」。
Microsoft の話でも IBM の話でもそうなのだが、システム全体を小規模(10名程度)の Agile チームに分割するところに肝がある。個人的には「アーキテクチャ設計重要」という立場を取っているので、ここも「各チームが個別に独立して開発を進められるようになるような、『意図的なアーキテクチャ』の設計がまず大切」という風に理解した。
見積り
3つ目のテーマは見積りについてだったが、特に興味深い話はなかったので略。
個人的に考えたこと: 昨今、受託開発でも要件定義から総合テストまで一本の契約で済ますのではなく、各工程ごとに分割して契約する習慣が広まっている(経産省のモデルでもそうなっている)。これは、開発初期の精緻でない見積りに基づいて全てを決めてしまうリスクを回避するための措置で、スコープを固定したまま(すべて作るという前提で)、ウォーターフォールの工程を少しずつ進めていって、徐々に見積りの精度を高めていきましょうという動きだ。一方、Agile 開発は、スコープを可変にして(工程はすべてをやる前提で)、スコープを徐々に広げながら、見積りの精度を高めていきましょうという動きだ。切り口の軸が違うだけで、ウォーターフォールの分割発注も、Agile 開発も、やりたいことは同じなのかな、と思った。
2010年07月01日
![{book['rank']](http://booklog.jp/images/rank/1.gif){kind=icon}
2010年06月21日
Infotalk#19
僕も参加した InfoTalk#19 の Togetter。どちらも面白い発表でしたが、小松さんの発表はとくに興味深かったです。Mozc のソース、ちゃんと読まな……。
2010年05月25日
Riak と Cassandra と HBase、あらまー!
Mozilla Blog Riak and Cassandra and HBase, Oh My!の勝手訳。各分散 KVS の特徴が分析されていて興味深い……と思って訳してみた。この無様なタイトルは Google 翻訳による。
Riak と Cassandra と HBase、あらまー!
我々は、SoCorro Crash プロジェクトにおいて HBase との統合を進めているが、その話はちょっと置いておいて、今回はメトリック・チームが巻き込まれている別のプロジェクトについて話をしよう。
Mozilla Labs Test Pilotは、実世界の Firefox ユーザをから集めたデータを分析して、ユーザ・エクスペリエンスを向上させるための実験をしたり、定量的データを集めたりするためのプロジェクトだ。
私がこのプロジェクトに興味をそそられ、興奮しているのは、彼らがユーザのプライバシーを保護しようという姿勢を強く示しているためだ。嬉しいことに、彼らはユーザ視点で非常に読み易いプライバシー・ポリシーを公開している。
Test Pilot では、データ送信の各ステップで、ユーザは自分が送信しているデータを意識し、安心できるようになっている。ユーザーは自分自身が送信するデータを送信前に確認することができるし、その上でデータを送信するかどうかを選択できるようにしているのだ。ほとんどの送信データは URL のような機微情報を含まない、ごく一般的なものに限られていて、どのようなことであれ個人を特定できるような情報とは関連付けられていない。
Test Pilot のプレ 1.0 リリースでは、そのアドオンから送信されるデータは単純なスクリプトで処理され、NFS サーバ上のフラットファイルに格納されていた。
我々は、ユーザ数と集収データ量を急激に拡大させようと計画している。というわけで、この単純なストレージは役に立たない。以下は、我々の計画で洗い出されたデータ・ストレージが備えるべき最も重要な要件群だ。
- 想定される最少ユーザ数: 百万人。年末までには一千万人を収容し、さらに数千万人規模に拡張可能なデザイン(これは私のお気に入りである見積りの 1x 10x 100x ルールに従うものだ)。
- 一回の「実験」で集められるデータは 1.2TB。
- 想定されるピークトラフィック: 実験の終了間際で、8時間にわたって約75GB/時間。これが2回。この 2日間で全データの約 90% を集収するはずだ。
- 高トラフィック化でも高い可用性を保つこと。
- 不正なデータによって実験が影響を受けたり、アプリケーションが障害になったりしないよう、必要な検証機構やセキュリティ制約を課せられること。
- 柔軟で使いやすいデータ解析、データ走査。統計やデータ処理に長けた連中ではあるが、全員がプログラミングに長けているというわけではないので、高レベル API があればなお良い。
- 性能。
私は技術屋だ。私は、流行にのったり、可能性のあるツールを使うために、技術を調査するのが好きだ。私は SQL の熱烈な信奉者だが、一方で"NoSQL" 系技術の大ファンでもある。NoSQL が活用される場面は、かなり多いと思っている。
このプロジェクトの特性を考えたとき、私は key-value ストアかカラム・ストアの採用が適切であると感じて、自分の調査用ブックマークを掘りおこして技術的なメリット・デメリットの比較を行なった。
最終的に、我々のチームは選択肢を以下の 3候補に絞った。
- HBase
- Cassandra
- Riak
我々は最近、これらのソリューションの利点と欠点を洗い出すための打ち合わせを持った。ここでは、その議論の結果をみんなと共有したいと思う。私が議論の結果を共有したいと思っているのは、採用に至らなかった 2候補に改善をうながすためではなく、以下の 2つの理由からだ。
- クラウド(Crowd;群集)ソーシング - 私は、様々な技術に精通したエキスパートから幅広いフィードバックを受けるためには、思索や仮説をオープンにすることが一番有効だと信じているからだ。また、問題点を隠しておくよりは、それを軽減するために、見過していた機能に注目したり、有識者からの警告を受け入れた方が良いと信じている。
- 知識の共有 - 仮に我々の出した答が完全でなく、理想のソリューションに辿りついていなかったとしても、我々がここで提示したたくさんの良い基準は、同様の選択を迫られている他のチームの役に立つだろうと信じる。
では、具体的な比較ポイントを説明していこう。
- スケイラビリティ - 当初想定負荷を捌き、また負荷の増大に応じて容易にスケールアウト可能なソリューションであること。
- 弾性(Elasticity) - ピーク時間帯が比較的短かく、ピーク時間以外はほとんどアイドル状態である。このため、割り当てたハードウェアが遊ばないように、またピーク時にリソースが枯渇しないような方法を考えることが重要である。
- 信頼性 - 安定した稼働と高い可用性が重要である。ある領域のプロジェクトと比較すれば信頼性要件は比較的低いものの、ピーク時間帯に数時間もダウンするようなことがあれば、クライアント層でデータを保持しておき、後日に再送信するような仕組みが必要になるだろう。
- ストレージ - 実施中の実験および、データ分析中の直近のいくつかの実験について、充分な容量を保持できる必要がある。データは時がたつにつれて古くて使いものにならなくなると思われるので、活動中のクラスタから取り除いてアーカイブできることが望ましい。
- 分析 - 分析者フレンドリなシステムを提供するためには、何が必要だろうか?
- コスト - 初期構成および年末までに準備する構成のために、ハードウェアの追加配備に必要な実コスト。
- 人的リソース - プロジェクトが最初の重要な段階およびその後のいくつかの段階をこなすまでに、どの程度の時間と手間を必要とするか。加えて維持管理コストとコードの所有権についても考慮する必要がある。
- セキュリティ - 我々が扱うデータは、外部の信頼できないデータソースから受信されるため、ユーザのプライバシーとシステムの健全性を確実なものにするために何が必要かを検討しなくてはならない。
- 拡張性 - 将来的なプロジェクトの要件拡大に応じて進化可能なプラットフォームを配備する必要がある。願わくば、他プロジェクトでも利用可能なプラットフォームにしたい。
- 障害回復とデータ移行 - もしリリース後にシステムが要件を満たせなくなった場合、どのような代替手段が取れるか。他の技術に乗り替えようとした場合、どのようにデータを移行するか?
さて、3つの候補について我々のチームが出した結論とともに、もう一度これらのポイントを見直してみよう。
- 弾性 - 負荷の増大に応じて、マシンを追加できること。マシンを取り除くときには、マシンの電源を切ればデータが再配置されること。ソフトウェアの不良によって、レプリケーション・データが欠損したり破損したりして、データを喪失するリスクは、もちろんある。3候補すべてについて、既存データの再配置は、データがクラスタ内を行き来するために、余計な負荷がかかる。どの程度の時間が必要か、またどの程度の手動操作が必要か、どこまで自動化できるか、どの程度のリスクがあるのか、ノード追加時に追加の効果を得るまでにどれくらいの時間を要するか、などを考慮する必要がある。
- HBase
- HBaseでは、データは "region" に分割されている。"Region" のデータ・ファイルは HDFS に保存されているため、クラスタ内の複数ノードにレプリケーションされている。各 RegionServer が一組の region を所有している。通常は、RegionServer は自分自身が稼働するローカル HDFS データノード内の region を所有する。新しいノードが追加されると、HDFS はそのノードをレプリケーション用に使用しようとする。Region ファイルが分割されるタイミングで、HBase はどのマシンがその新しく分割された region を所有すべきかを決定する。最終的には、新しく追加されたノードは適切な量の新しいデータや新しくスプリットされたデータを保持する。データの再配置は、HDFS の再配置と HBase による region の再構成の両方を含む。
- Cassandra
- Cassandra では、各ノードは、複数のデータ範囲を要求する。デフォルトでは、新しいマシンが追加されると、データ範囲のうち最も大きいものの、半分のデータを保持する。この挙動を変更する起動時オプションも存在する。安全で容易な再配置のためには特定の設定が必要であり、全データ範囲を対象とした再配置コマンドも存在する。再配置の進捗を監視するためのツールも存在する。
- Riak
- Riak では、データは各ノードに分散配置された複数のパーティションに分割される。ノードが追加されると、パーティション所有権の分散が変更され、既存データと新規データの両方について新しいデータへの移行が開始される。
- コスト - どのソリューションも、一般的なサーバ・ハードウェアと Linux OS が使用可能である。
- HBase
- ピーク時間帯の膨大なトラフィックを処理するため、専用のクラスタが必要となる。たとえば Socorro のような他プロジェクトとクラスタを共有すると、他プロジェクトに悪影響が及ぶだろう。また、計画メンテナンス時にも、どちらか片方だけではなく、両方のプロジェクトを止めなくてはいけなくなる。HBase はメモリ喰いだ。現在の我々のシステムは、デュアル・クアッド・コアのハイパースレッド付きで、4TB のディスクと 24GB のメモリを積んでいる。これより小さな構成というのは、組めそうにない。マスターノードのために、少なくとも 2台の高可用性マシンが必要であり、年末には 1クラスタのために12台のマシンが必要になるだろう。
- Cassandra
- メモリ要件に関してはずっと軽い。特にキャッシュに大量のデータを保持する必要がない場合は、特に軽い。現在の Test Pilotプロジェクトに割り当てられている 4ノードについてCPU 数を二倍にするほか、8台のマシンを追加でオーダーすることになるだろう。Cassandra 上で分析を行うには、既存の Hadoop クラスタを活用する必要がある。
- Riak
- メモリ要件は Cassandra 同様に軽い。当初はプロジェクトに割り当てられている既存の 4台(クアッドコア、8GBメモリ)だけで充分で、さらに同等程度のマシンを 2台、クラスタに追加したい。さらに分析処理用に2つ目のクラスタを 6〜8台のやや性能的に劣るマシンで構築する。Riak が持つ弾力性のおかげで、ピーク時間帯にはこのうちの N-3台を一時的に書き込み用クラスタに転用することができる。
- 人的リソース
- HBase
- クライアントから実験データを受けとるためのフロントエンド層が必要。クライアントへの修正が少なければ少ないほど良い。Thriftか、Java による独自開発が妥当な選択肢だ。機能性、安定性とも、アプリケーションは充分にテストされる必要がある。開発とテストにそれぞれ 2週間と見積もっている。見積りは、実装が必要なセキュリティ・コード、サニティ・チェック、クラスタ間通信のエラー処理などの量に依存する。分離されたフロントエンドを維持管理していくのは、不毛だ。データをパースして、適切なカラム・ファミリー内に格納するために、スキーマ設計の結果を、フロントエンドのコードに反映する必要がある。
- Cassandra
- ほとんど HBase と同じ。Thrift または Java のアプリケーションを手動で開発、テストする必要がある。フロントエンドのスキーマ設計も必要となる。
- Riak
- 組み込みの REST サーバが、すでに充分にテストされ、リリース可能な状態。スキーマ設計は最小限で、スキーマを REST サーバ上に作り込む必要は特に必要ない。
- Security - いかなる種類のハンドシェイク・プロトコルも、認証トークンも、使用することはできない。もし、認証トークンを使おうと思ったら、クライアント・アドオンに膨大な修正が必要になり、プロジェクトの遅延を引き起こす。どうせ機微情報はやりとりしないので、オーバヘッドばかり大きなSSL は、たいして役には立たなそうだ。我々のファイアウォールとプロキシー/ロードバランサー層が、最も重要な防御ラインだ。URL ハックや、不自然なサイズのペイロード、同一の IP アドレスから繰り返される通信などは、ここで排除できる。理想的には、データ検査部分が IP アドレスのブラックリストや、データ・シグネチャーのブラックリストと通信できれば、クラスタの健全性損失を最小限に抑えるために充分な防備を持っていると言えるだろう。
- HBase/Cassandra
- データを検査し、不正なまたは不完全なデータを排除するためのフロントエンド層を独自開発する必要がある。これはフロントエンド層への要件と開発時間見積りに追加される。
- Riak
- Webmachine の pre-commit フックをデータ検査のために使用することができる。
- 拡張性 - 格納されているデータが変更されたとき、3候補すべてにおいて入力のセキュリティチェック処理やスキーマ変更に伴う入力解析処理の変更が必要になる可能性がある。
- HBase
- カラム・ファミリーの追加または変更を含むスキーマの変更は、テーブルを無効にしてから行う必要がある。つまり、保守のための計画停止が必要になる。新しいテーブルの作成は、オンラインで行うことができる。
- Cassandra
- スキーマの変更は、各ノードのローリング・リスタートを必要とする。
- Riak
- 新規のバケツとスキーマは、完全に動的に作成できる。
- データ移行 - 3候補いずれとも、データをシステム外に複製、エクスポート、MapReduce する処理は容易だ。
- 障害復旧 - 3候補いずれを採用しても、クライアント・アドオン側で、クラスタ高負荷時には通信を控え、通信が失敗したときには、後でリトライするような機能を作り込むのがベストだろう。
- HBase
- 独自に実装するフロントエンドは、クラスタがオンラインになるまでデータをスプールしておく機能を持つことで、障害時処理の一部を担当できるだろう。障害時用に別のクラスタを持っておくことが、最も実行可能性の高い障害対策だ。
- Cassandra
- HBase と同じ。
- Riak
- 分析用のクラスタを一時的に受信データの処理用に利用することができる。独自に作り込んだフロントエンドは存在しないので、もし、Riak クラスタをクライアントから接続可能な状態にできなければ、サーバ側でデータをスプールするような場所はない。
- 信頼性 - 特にクライアントのアドオンがリトライ機能を持っていたり、フロントエンド層がスプール機能を持っている場合には、短期間のダウンタイムは深刻な問題ではない。
- HBase
- 今後のバージョンがより良い高可用性オプションを提供するまでは、Hadoop NameNode と Habase Master は依然として単一障害点である。ある種の管理作業とアップグレードは、NameNode と HBase Masterの情報を更新するまでの間、全クラスタを同時停止する必要がある。多くの管理作業についてローリング・リスタートで対応できるものの、HBase の有識者はローリング・リスタートの採用を推奨していない。
- Cassandra
- 単一障害点なし。ほとんどの構成変更は、ローリング・リスタートで対応可能。
- Riak
- カサンドラと同じ。
- 分析
- HBase
- (場合によっては JDBC 接続とともに) HIVE ベースのインターフェースを提供可能。分析者がある種の共通的で単純なジョブを実行するときのために、単純化された MapReduce フレームワークを提供可能。
- Cassandra
- Hadoop を使えるので、HBase と同様。
- Riak
- Map Reduce ジョブは、JavaScript で開発可能で、REST API を通じて実行できる。これらのジョブ実行を実現するための、軽量なウェブインターフェースを作り込むこともできる。
これらの評価と、ソリューションをほとんど初期設定不要な状態で提供する上で必要な人的リソースを考慮して、Test Pilot のバックエンドは Riak で構築することに決定した。我々が大きく投資している HBase と比較して、いろいろな意味で似通っている別技術を採用することには少し違和感があるが、私はこの選択が最善であると考えている。また、他プロジェクトで Riak を採用する可能性がある分野も、実際にいくつかある。
もしなにか質問や心配ごと、不明な点があれば、どうぞお気軽にコメントに書いて欲しい。質問には返事をして、必要であれば記述を更新する。
2010年04月15日
はてぶったー
はてなブックマークした内容を twitter に転送したいと思って、はてブの WebHook を使ったサービスをつくってみた。半分くらいできたところで気がついたんだけど、はてブツイートとやっていることがまったく同じだった……orz。向こうは ruby、こっちは GAE python。
まぁ、OAuth の勉強になったから、いっか。
2010年03月26日
Ubuntu9.10 のログイン画面にユーザー名を表示させない
メモ: Ubuntu9.10 のログイン画面にユーザー名を表示させないようにする
Ubuntu9.10 の gdm は、/etc/gdm/custom.conf を見なくなってしまったので、ログイン画面にユーザー名がデカデカと表示されていて、困っていた。というわけで、ユーザー名を表示させないようにするには、gdm ユーザの gconf をいじる。
sudo -u gdm gconftool-2 -s --type=boolean /apps/gdm/simple-greeter/disable_user_list true
ずっと /desktop/gnome の下を探して、該当のキーが無くて困っていたのだが、/apps/gdm の下だった……orz。しかし、わしの若い頃には「ユーザー名もセキュリティの一部」と教わったものだが、最近の若い者は大胆じゃのぉ。
