デブサミ2011に参加しました。初めての参加ですが、雰囲気がAgile Conferenceに似ていてびっくりしました。ここまでクオリティの高いイベントが国内で開催されているというのは、エンジニアとしてとてもうれしいことに思います。また、運営側の皆様にも感謝いたします。
本の販売ブースもあります。販売されている本が技術本ばかりだと楽しい。割引もされていたので、気になる本を探してみないと。
会場は人がたくさんでした。満席のところは立ち見も出ている状態です。
セッションの裏番組として、通路にOpen Jamがありました。Agile2010でもあったのでなつかしい！とおもったら@kawagutiさんがアドバイザーとして暗躍していたみたいです。さすが。
本日参加したセッションは4つ。
- 【17-C-1】 Big Dataを扱うアーキテクチャの原則 Consumer
- 【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
- 【17-E-3】 Hadoop：黄色い象使いへの道 ～「Hadoop徹底入門」より～
- 【17-B-4】チケット管理システム大決戦 JIRA vs Redmine vs Trac 〜ユーザーが語る、なぜ私はこのツールを使うのか
【17-C-1】 Big Dataを扱うアーキテクチャの原則 Consumer
- 通勤ラッシュはなぜ起こるか？ ＞ メタファー：ビッグデータの扱いに似ている
- 制約：窓口部分が有限であること。それぞれの窓口で処理が発生するため待ち行列ができる
- N-tier モデル LB ＞ 複数のWebサーバ ＞ ロジック ＞ RDB
- N-tierは従来のモデル。Webやロジックは横に並べることができるが、ロジックからRDBへのアクセスがボトルネックとなる
- フロントはレイテンシ、バックはスループットがボトルネックの対象となる
Universal Scalability Lawというももがあり、Wikipediaにまとめられている。ここでは、スループットが限定される2つのファクターとして（Throughput limited by two factors）、競合（Contention）と一貫性（Coherency）がその2つとされているのが興味深い。
- SQLは生き残るのか？
- SQLは関係代数である
- ビッグデータであってもそれは集合であるため関係代数であるSQLはつかえるのではないか？
- データ分析設計
- 要求がまずあるがデータのあるべき枠組みを作る設計
- ドメイン内のデータから設計を行う？
論理レベルのデータの配置で考えるべきことが語られていて、すごくわかりやすかった。これらはクラウドであってもなくても普遍的に変わらない部分なので覚えておこう。
- トランザクションデータ ＞ 時間概念を持つ ＞ 更新系
- マスタデータ ＞ 参照
- 概念上の分類を行う ＞ トランザクションやマスタを分割して物理的に配置
- リアルタイム操作のデータモデル CQRS
- 更新と参照をアーキテクチャレベルで分ける
更新と参照を同時に実現したのがRDBMSといえる。しかし、これだとスケールが難しい。
また、更新系は行を対象としたトランザクションであり、参照系は属性を条件にして取ってくる列指向と、異なる指向のデータなので、基本的には分けて考えたほうがよいとのこと。
そうすると、問題は、どうやって更新系と参照系を同期させるか？となり、クラウドでは非同期でやることが多く、RDBMSのようなリアルタイムで更新されたものが反映される考え方ではなく、「もしかしたら、今すぐ反映はできないかもしれない。ただし、あとで反映される」といった考え方になる。
- データ分割・配置 ＞ 転送最適化
- 小さいデータを大きいデータがあるサーバに転送すると転送が最適化される
- メモリに載せるのも小さいデータにする
まとめ
- データ分割で競合を防止し、メモリに載せるのが重要
- すべてをメモリに載せるのではなくハッシュ値をのせることで載せる量を増やす
- 転送最適化
感想。クラウドを活用する場合のデータ設計やアーキテクチャ設計が整理されていて面白かった。ただ、初心者の自分には難解な表現があったので、勉強をしよう。
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
これが今日一番面白かったセッション。
Azure、Google App Engine、Force.com、AWSの4つの環境で同じアプリを作り、RDBMSを使わないなどの制約をくわえ、クラウド上でのアプリ開発について調査をしたというレポートセッション。
- クラウドでは、データに即時一貫性がないため、そこをどうするかを考えていく必要がある
- KVSだと非正規化、必要なデータでデータを構成する形
- バッチ処理しているデータを読み込まないように気をつける必要もある
資料が後で公開されるとのこと。
これまでは、RDBMSが主流だったが、NoSQLの活躍が目立ってきている現状、無視できない存在になっている。しかし、RDBMSの考え方に縛られるのではなく、NoSQLに移行するわけでもなく、必要な場所で、必要な技術を選択することが重要だというメッセージがとても共感できた。
NoSQLによるスキーマレスなデータストアの設計はまだパターン化されていないレベルなので、これからの知識として学んでいく必要がある。これからどうなるかを心配するのではなく、将来、早い導入によって、ナレッジというアドバンテージがとれるようにしなければ、乗り遅れたときのビジネスダメージは大きいはず。
そういったことを、暗黙でクラウドは語っているのかもしれない。
【17-E-3】 Hadoop：黄色い象使いへの道 ～「Hadoop徹底入門」より～
ログなし。入門編だったので話を聞くのみでした。
【17-B-4】チケット管理システム大決戦 JIRA vs Redmine vs Trac 〜ユーザーが語る、なぜ私はこのツールを使うのか
@ryuzeeさん、@akipiiさんが、ツール論争で激論するのを期待して参加。このセッションは大盛況で、開発改善としてツール導入を考える人が増えたのかしらん。
自分もRedmineを使っていて（明日、Shibuya.tracでも発表予定です）、@ryuzeeさんの影響が大きいのだろうけど、ツールなんて何でもよくて、それが負担にならないように、そして、ちゃんとツールの目的を忘れずに使えば、どれでも効果は出るかと思ってますちなみに、自分はそろそろRedmineを卒業しようかと。
明日も楽しみです。
