Project Archive

• Mozilla Foundation、2005年の売り上げは5290万ドル
• The Mozilla Foundation: Achieving Sustainability
• Mozilla Foundation Documents
  • 財務表有り

売り上げの大半の検索エンジンに由来ってFirefoxとかの右上の検索窓提供に対するお金なのかな。Mozilla Foundation Documentsに財務表があって、この検索エンジン関連で5051万ドル分らしい。寄付が49万ドル、利息が57万ドル、支出が817万ドル。金持ちすぎー。

JavaSVNがSVNKitって名前に変わってた。

ディレクトリでJNDI APIいっぱい触ったけど、いまいちJNDIの詳細見てなかったのでメリットが良くわかってなかったり(汗。とりあえず、JNDIは無視してSVNKitいじくってます。僕のコード理解したり書く速度が遅いのであっという間に遅れてたり。

すごい久しぶりにPerl書いた。そして、やり方うる覚えだったけどSourceForge.netでリリース作業した。というわけで、smbldap-attributeというコマンドを追加して、smbldap-entry-tools-0.2をリリースしました。smbldap-attributeは、LDAPサーバ上の任意のエントリの属性と値を追加・編集・削除できるコマンドです。

-d    delete mode
-s    separate character (default ':')
-h,?  show this help message

add attribute and value (support multiple values):
  smbldap-attribute "uid=user1,dc=example,dc=com" "attribute:value"
  smbldap-attribute "uid=user1" "attribute:value"
  smbldap-attribute user1 "attribute:value"
  smbldap-attribute -s "_" "uid=user1,dc=example,dc=com" "attribute_value"

modify value:
  smbldap-attribute "uid=user1,dc=example,dc=com" "attribute:current:new"
  smbldap-attribute "uid=user1" "attribute:current:new"
  smbldap-attribute user1 "attribute:current:new"
  smbldap-attribute -s "/" user1 "attribute/current/new"

delete value:
  smbldap-attribute -d "uid=user1,dc=example,dc=com" "attribute:value"
  smbldap-attribute -d "uid=user1" "attribute"
  smbldap-attribute -d user1 "attribute"

このコマンドはある意味最強かも。なんで今まで作らなかったんだろうというぐらい(;´ー`)。

smbldap-attribute "cn=s2directory,ou=Groups" "description:/home/groups/sandbox/s2directory"

とか出来ちゃう。dc=seasar,dc=orgは補完されるので省略してOK。

イベントサイトが載ってるサーバがあるとこだけちょっと回線が細いので厳しい模様。スライドPDFの一般配布はmod_rewrite仕込んで某大学に置いてあるサーバにリダイレクトさせた方が良いかも・・・。

会議後の飲み会に行こうと思ってたら緊急案件があったので帰宅。。言おうと思ったら皆お店に入っていってて、一応亀谷さんに言ってたのでまぁ良いかなと(;´ー`)スイマセン。

互換性は保たれているようですが、クライアント側で利用者の多いSubclipseとTortoiseSVNが正式に1.4.0相当版がリリースされて問題なさそうなのを確認してからアップデート考えたいと思います。

Seasarのサーバにあった最適な環境を考えてみます。まず現在提供しているサービスを挙げます。

• プロジェクトサイト閲覧
• SVNリポジトリ閲覧
• SVNリポジトリコミット
• SVNリポジトリブラウザ
• イベントサイト閲覧
• イベントサイト編集
• Wiki閲覧
• Wiki編集
• トラッキング閲覧
• トラッキング編集
• 検索エンジン
• メーリングリストアーカイブ
• メーリングリスト配信
• Mavenリポジトリ閲覧
• Mavenリポジトリデプロイ(SCP接続)
• メンバー用ページ

このうち書き込み処理が発生して、かつ頭の良いロードバランサじゃなくてDNSラウンドロビンのような簡易バランサにおいて、アプリケーションレベル(メモリ上)でのロックが必要になりそうなのは、次のサービスだと思われます。

• SVNリポジトリコミット
  • Subversion + WebDAVのロックの仕方によっては大丈夫っぽい
• メーリングリスト配信
  • メールサーバ自体のクラスタリングは問題ないが、メーリングソフトが謎
• Mavenリポジトリデプロイ(SCP接続)
  • 問題ないけど、ホストが変わって新しいサーバ公開鍵だと承認のYes/Noが最初の1回出る可能性がある。サーバ公開鍵を同じのにしちゃうという手もあり。

上記だけ別ホストにすれば、残りはクラスタ化しても問題なさそう。そんなわけで、次のような構成にすると良さそうです。

• 概要
  • SANでデータ一括管理
  • ファイルシステムをGFSにして、複数サーバで同時に読み書き実現
    • GFSはGoogleも改造して一部で使ってる分散ファイルシステム。
  • リモートでの復旧を考慮して実サービスはXen上に展開

• ハード構成
  • ストレージアレイ * 1
  • SANスイッチ * 1
  • 物理サーバ * 3

• Xenゲストサーバ構成
  • xen01 (GFS + SAN)
    • フロントサーバ1
    • 書き込み用サーバ1
  • xen02 (GFS + SAN)
    • フロントサーバ2
    • 書き込み用サーバ2 (xen01が死んだ時用の予備)
    • GFSロックサーバ1
  • xen03 (非 GFS + SAN)
    • データバックアップサーバ

この構成であれば、普段はフロントサーバ1, 2をDNSラウンドロビンで回し、書き込み用はどちらかの書き込み用サーバにアクセスさせておいて、障害が起きたらDNSラウンドロビンを止めるのと書き込み用サーバのアクセス先をもう1台に変えれば良い。もしくはフロントサーバの前にPoundだけが走るXenゲストサーバを走らせれば、障害時に自動的に読み込み用サーバへのアクセスを制御してくれる。もしくはもっと大規模にいくならUltraMonkey？。さらに負荷が高まったら単純にフロントサーバ足せば分散できる環境です。

ただ、この構成の場合の問題点もあります。

• SAN構成が高い
  • ストレージ
  • SANスイッチ
  • ファイバチャネル
    • iSCSIなら安いがパフォーマンス落ちる
• GFS + SAN構成をするのに同一ネットワーク内でないとツライ
  • 同一ネットワークでのGFSのパフォーマンスは通常のext3などのファイルシステムの80%程度らしい
• どこかのデータセンタに一極集中してしまう
• SAN構成部分に冗長性がない
  • やろうと思えばできるけどさらにお値段アップ
  • データバックアップサーバをどこか別の回線が早いとこに置けば、緊急時はそっちで読み込み用サービス可

そんでもって、ほんとにここまでの環境が必要かどうかだけど、たぶん将来必要になるかと。問題はこのリソースを提供してくれるとこがあるかどうか(;´ー`)。また、SeasarじゃなくてもYukaraで必要なんじゃないかなと。

この構成案は今ある技術で考えたもので、実際に試してないので穴や罠があるかもしれないです。また、これ以外にもGoogle、SourceForge、Slashdot、はてな、mixiなどいろんな方法で分散環境を昔から構築されているのでどうやってるのか興味深いです。たまに講演とかニュースでちょこっと話題になることがあるけど、ほんのちょっと話してるだけなので聞きたいことがいろいろ。。

そんなことより、Seasarサーバの復活はやはり月曜になりそうです。コミッタの皆様、もうしばらくお待ちくださいm(_ _)m。こういった障害時のこと考えると、Xen上かいつでも現地対応できる環境は必要そうです。

[追記] DB関係考えてなかった。そこはまた別にレプリケーションの仕組み用意ってことで。

[追記] GFSにDB(PostgreSQL or MySQL)載せたらどうなんだろって調べてたら、GFSについて(eyes blogさん)という良い記事がありました。これによると2台でGFSは危険っぽいかも。

そして19:00からは、Michael Timann氏の講演を聴いてきました。予備知識ほとんどなしで行ったのですが、Michael Timann氏は、Fedora Coreプロジェクト、OSI、GNU C++ Compiter、Cygwinなど、数多くのオープンソースプロジェクトに関わってきた方でした。日頃お世話になっているものばかりです。

で、お話を聴いていて思ったのは、Seasar Foundationもそうですが、こういったOSS組織のボードや長、講演者などは、単にコードを書いているだけじゃなく、社会的な何らかのテーマを改善することを本当によく考えているんだなぁっと思いました。僕なんかだとコードに向き合うほど、単にコードだけを見たり、ちょっとしたコードを書いていくだけで満足していってしまっているので浅はかなもんです。何かを実現したいものを作るだけじゃなく、そのものによって改善される社会的なテーマをきちんと自覚しないと、集まってくる人がそのテーマに気付いてる気付いていないに関わらず多くの人は集まらないのかもしれません。また、同様に上司や社長さんもそういう人でなければ、部下は集まらないんでしょうね。

次のイベントまでの間はIkushipeで遊んでました。1箇所バグっぽいところがあったので、午前中に聞いてきたテスト駆動開発の真似事をして特定してみました。早速お伝えして修正していただき、Ikushipeについてのお話を伺ったりしてました。特にループの処理は、嬉しい挙動してくれるので良いです。いろいろ試しながらまたバグと思われる箇所があったらお伝えしたいと思います。

t-wadaさんの「デベロッパーテスティング – ソフトウェア開発者の基礎体力」の講演を聴いてきました。おぉ良いっと思ったテストの一つに、外部ライブラリの使い方を学ぶためのテストを書くというのがありました。初めて使う外部ライブラリの場合、いきなし目的に応じたことをそのライブラリの使い方を学びながら書いてしまいがちですが、それだと焦点がぼやけてしまって考えることが散乱してしまう欠点があったり、後からその外部ライブラリの使い方を忘れてしまった時にそのテストを見直しても主目的が違うとこにあるため判り難かったりしたりするので、まずは外部ライブラリの使い方を記述したテストケースを作ってみると良いという内容です。こうしておくと、後からその外部ライブラリの使い方を忘れてしまった時に簡単に使い方をおさらいできますし、外部ライブラリのバージョンアップをする時にまずは以前と同じ使い方で問題ないか確認もできます。さらにこれは要は学習の過程を残すものであって、これがあると複数人でプロジェクトを組んだ時に、他の人も簡単にその外部ライブラリの使い方を理解できる手助けになるというわけです。

僕の場合一人で書くことが多いですが、指摘されたように後からその外部ライブラリの使い方を忘れてしまうことが結構あるので、これはなるほどなるほどーっと勉強になりました。というわけで、今度から新しいライブラリを使う時はやってみようと思います。

あと、ペアプログラミングする際、横で小言をいっぱい言ってくれるそうです。嫌われ役にわざとなると笑いながら話されていましたが、それは非常に羨ましい環境です。横で小言をいっぱい言ってくれるということは、そんだけより良いスタイルや良いやり方を早く身に付けられたり、そのコードが自分以外の人に認められながら書けるわけで自信にも繋がります。一人で書いていると、これってほんとに良いやり方なのか？もっと手法があるんじゃないか？っとあれこれ考えちゃうのです。もちろんいつかは一人で書くようになるわけですが、少なくとも導入時にこういった環境で学習できると飛躍的に成長できそうですし、実際そうみたいです。