February 13, 2009

デブサミ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の設計指針（トップダウン）

    • 一貫性よりも可用性。

      • スケーラビリティのパターンの原則

      • アーキテクチャ定義

      1. 機能分割：SOAに基づくサービス単位化

        1. データ設計：保守用データ定義、論理データ配置、アプリケーション設計（ユースケース依存）

        2. データ分割：partition schemaにしたがう水平分割

        3. 分散トランザクションの回避：分割したデータ間の一貫性の確保

        4. 非同期による機能分割：メッセージ転送の信頼性の設計

        5. キャッシュの設計：主に読み取りデータ向け

        6. 一貫性モデルの提供：eventual consistencyなど

        7. その他：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の統合ファイルシステム を連想した。

投稿者 mkouhei
カテゴリー: meeting