デブサミ2009に行ってみた。

初日に行ってきた。デブサミに行ったのは初めて。昨年も実は行きたかったのだが、昨年度の所属部門がサーバOSの構築・運用がメイン [1] の部隊でだったので理由をつけにくかった。今年度は営業寄りなので理由はつけやすい。

聴講したセッションは、仕事寄りとしては、

趣味よりとしては

仕事絡みでクラウドコンピューティング関連のセッションで他にも聞きたいのもあったのだが、途中お客様との月次定例会で中座せざるをえなかったのは残念。

Azureの話。

一番最初のクラウドのはMSの方による一般的なクラウドとAzureの話。マーケティングとしては”クラウド”自体がいまだbuzz wordなのだが、技術的には今までのアーキテクチャと異なるのでもっと勉強しないと、と思い参加。Windows Azureは、 丸レクセミナー2008-2009の第2回 を聞いていたので、まるっきり分からないということはなかったが、やっぱり難しい。

一番印象に残ったのは、”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

      • 事務計算
      • ベクトル
  • 言語進化のパターン

    • 冒険
      • 新たなアイディア、荒削り、広く理解されない
    • 改良
      • 第2世代、洗練、一部で受け入れられる
    • 普及
      • 普通の人が使える技術にまで進化、広く受け入れられる、当たり前になる

とりあえず、今勉強中のErlangをさっさと使えるようになるか。

SAPの話

デブサミの客層とターゲットが明らかに異なるので、閑古鳥が鳴いていたが、内容自体はおもしろかった。トースターを各ITベンダーが作ったら、というたとえ話がおもろかった。内容はパッケージ製品を使うなら至極当たり前の話だと思ったが、その当たり前ができていないところが多いのだろうなぁ。

LT

となりの席があけどさんだった。

今回勉強になったことは、LTではいきなり結論を話す、これに尽きるかな。(わら

漫才あり、 マンションの話 あり、 お手上げバグ あり、生・高橋メソッドを初めて見れたり、とおもろかった。

明日は

行けないけど、id:z-ohnamiさんが行くみたいだから、彼の参加報告を期待。

[1]というか、ファシリティ除けばそれだけじゃねぇか。
[2]これを聞いていたときに、 AS/400の統合ファイルシステム を連想した。