デブサミ2009に行ってみた。¶
初日に行ってきた。デブサミに行ったのは初めて。昨年も実は行きたかったのだが、昨年度の所属部門がサーバOSの構築・運用がメイン 1 の部隊でだったので理由をつけにくかった。今年度は営業寄りなので理由はつけやすい。
聴講したセッションは、仕事寄りとしては、
趣味よりとしては
仕事絡みでクラウドコンピューティング関連のセッションで他にも聞きたいのもあったのだが、途中お客様との月次定例会で中座せざるをえなかったのは残念。
Azureの話。¶
一番最初のクラウドのはMSの方による一般的なクラウドとAzureの話。マーケティングとしては”クラウド”自体がいまだbuzz wordなのだが、技術的には今までのアーキテクチャと異なるのでもっと勉強しないと、と思い参加。Windows Azureは、 丸レクセミナー2008-2009の第２回 を聞いていたので、まるっきり分からないということはなかったが、やっぱり難しい。
一番印象に残ったのは、”N-tierモデルや、RDBのような共通化したスキーマモデルは古い。”
記録したメモを転記。
SOAの問題はどこにあるか？
クラウドの中で重要な役割を持っている。が、さほど普及していない。
再利用できてもスケーラブルでない。
N-tierモデルの問題
クラウドではこのアーキテクチャは古い。
RDBサーバがボトルネックになる。
通常のトランザクションのスケーラビリティがクラウドのトランザクションに比べ、非常に遅れている。
Azureの話
百万台レベルでの構成。(Googleでは300～400万台）
数千台レベルであれば、どのデータがどのサーバが持っているかを保持することは可能。
数百万台レベルになると、その処理だけで終わってしまう。
SLAの観点からみると、ルーティングが発生すると、レスポンスの遅延が発生する可能性があるので、保証が難しい。
クラウドは絶対に落とせないことが重要。古いデータを持っていてもデータの一貫性を犠牲にする。（非同期で複製するから）
一般的なクラウドにおけるパラダイム
スケーラビリティ、可用性を重視
一貫性は重視しない
即時一貫性を求められるビジネスには向いていない。
Azureは標準のファイルシステムの上にデータベースサービスがある。 2
Scale-outの設計指針（トップダウン）
一貫性よりも可用性。
スケーラビリティのパターンの原則
アーキテクチャ定義
機能分割：SOAに基づくサービス単位化
データ設計：保守用データ定義、論理データ配置、アプリケーション設計（ユースケース依存）
データ分割：partition schemaにしたがう水平分割
分散トランザクションの回避：分割したデータ間の一貫性の確保
非同期による機能分割：メッセージ転送の信頼性の設計
キャッシュの設計：主に読み取りデータ向け
一貫性モデルの提供：eventual consistencyなど
その他：REST Resource, ドメインモデルとの対応付け
ふと、Windows AzureのようなクラウドOSの実装がFLOSSで出てこないか(できないか)と妄想してみた。クラウド事業者として実装するにしても、クラウド利用者としてシステムを作るにしても、インフラ技術者もアプリ開発者もこのアーキテクチャは勉強しておかないといけないなぁと思ったり。
まつもとさんの話¶
冒頭から”(立ち見が出るほど人が集まるなんて)どうかしているんじゃないか””実務には役に立たない”と明言してから始まった。（わら
言語の進化要因
簡潔さ
簡潔さは力なり->進化論に似ている
Brooksの法則->人月の神話 あるプログラマーが一日に生成できるコードの量（行数）はどの言語でも同じ。
-言語を変えることによって生産性を挙げることができる。
新パラダイム
構造型プログラミング->当たり前になったので聞かない
オブジェクト指向->21世紀に登場したプログラミング言語は（一部を除いて）ほぼ全て実装されている
論理型プログラミング->Prolog
関数型プログラミング->より宣言的に、より間違いがなくかけるのではないか
外的要因
コスト
-マシンコスト->昔のメインフレームの場合は、人件費の方が安かったので机上デバッグをした。
-人件費
-ソフトウェア開発費
-ハードウェア
–ムーアの法則->物理的限界、発熱
–マルチコア／メニーコア->ソフトウェア側が支援しないといけない。
温故知新
Java
-VM, GC, 例外->LISPでは当たり前だった技術が、Javaのマーケティング効果が大きい。
ロストテクノロジー
HPC
事務計算
ベクトル
言語進化のパターン
冒険
新たなアイディア、荒削り、広く理解されない
改良
第２世代、洗練、一部で受け入れられる
普及
普通の人が使える技術にまで進化、広く受け入れられる、当たり前になる
とりあえず、今勉強中のErlangをさっさと使えるようになるか。
SAPの話¶
デブサミの客層とターゲットが明らかに異なるので、閑古鳥が鳴いていたが、内容自体はおもしろかった。トースターを各ITベンダーが作ったら、というたとえ話がおもろかった。内容はパッケージ製品を使うなら至極当たり前の話だと思ったが、その当たり前ができていないところが多いのだろうなぁ。
LT¶
となりの席があけどさんだった。
今回勉強になったことは、LTではいきなり結論を話す、これに尽きるかな。（わら
明日は¶
行けないけど、id:z-ohnamiさんが行くみたいだから、彼の参加報告を期待。
- 1
というか、ファシリティ除けばそれだけじゃねぇか。
- 2
これを聞いていたときに、 AS/400の統合ファイルシステム を連想した。
lighttpdで404 not found対応¶
昨日、Webサーバをリプレースし、Wikiも変更したのに伴い、404 not foundが多発していたので、新しく設置したWikiページにリダイレクトさせるエラーページを設定した。
lighttpd.confは以下のように設定。
## Format: <errorfile-prefix><status>.html
## -> ..../status-404.html for 'File not found'
server.errorfile-prefix = "/hoge/"
/hoge/ディレクトリ以下に、404.htmlというファイルを置くと、ちゃんとerrorコード404で/hoge/404.htmlが表示されると。
Japanize chumby¶
Tedious work only of developing archive with USB, doing, and turning on power supply that anything might not be done.
chumby日本語化した。¶
アーカイブをUSBに展開して挿して電源入れるだけ、という何もすることのないツマラナイ作業。
Replaced Web Server.¶
The Web server operated with OpenBlockS266 was replaced today. OS also improved the version from Sarge to Lenny. The homepage changed from Wiki to links. Wiki arranged ‘/wiki/’ as follows. Wiki changed from PukiWiki to Hiki.