JJUG クロス・コミュニティ・カンファレンス 2007 Fall レポート

Tech

JJUGのCross Comunity Conference 2007 Fallに参加してきました。簡単にですが、カンファレンスの内容をまとめました。(第2部 パネルディスカッション以降は、他のブログでまとまっているので、そちらを参照していただければと思います)

丸山先生レクチャーシリーズ 第1回 Googleの分散処理技術

  • なぜ、分散処理技術が重要か？
    • 第3次産業(サービス業)の増大 (IBM Almaden Research Centerによるレポート)
      • 2050年ごろには7〜8割程度占めるであろうと推測
      • 先進国、発展途上国を問わず、グローバルに起きつつある
    • 今後、サービスとシステムの規模が拡大する
    • これまでのエンタープライズシステムから次世代Webへ
      • 銀行以上の巨大なサービスを提供する可能性がこれから出てくる
      • サービスの規模の問題を考える上で、インフラの問題は外せない
        • サービスをどのようにスケールアウトさせるべきか？
      • インフラの変化は、プログラミング・スタイル、ミドルウェアの変化をもたらす
      • メインフレーム、C/S、Web
  • なぜ、Googleか？
    • 先ほどの分散処理技術の最前線に立っているから
    • Web 2.0 サミット
      • Microsoft、Google、Amazonは、インフラについて語っている
      • つまり、インフラの重要性を既に考えている
    • Cloudとは...
      • ネットワークインフラ、多数のサーバ、データセンタなど
      • 利用者には簡単なインタフェースを提供する
        • 技術からサービスへ
  • Googleの分散処理技術
    • Google File System
    • BigTable
      • 構造化されたデータを管理する分散ストレージシステム
      • Google File System上に構築されたGoogle独自のデータベース
      • 数千台のサーバ上のペタバイト単位の非常に大きなサイズにまでスケールする
      • Googleの多くのプロジェクトはBigTableにデータを格納している
        • 数十億のURL、各ページのバージョン、数億人のユーザ、毎秒数千回のクエリなど
      • 商用DBを利用しない理由
        • データ規模の大きすぎる
        • 扱えるとしてもコストが高くつく
        • DB層でのチューニングよりもストレージの最適化によるパフォーマンスの向上が著しい
    • MapReduce
      • Googleの分散処理でのソフトウェアの心臓部分にあたるアルゴリズム
      • Googleの中核技術であり、入社後には必ずMapReduceについて学ぶ
      • Map → Sort → Reduce
      • MapReduceによる分散処理技術への適用
    • Sawzall
  • Google Clone
    • Apache Hadoop
      • Googleの分散技術からオープンソースで新しい分散処理技術を開発しようとするプロジェクト
      • Yahooによる資本援助
      • Amazonによるプラットホームの提供(EC2/S3)
      • 以前は、分散処理技術の検証、動作確認ができないためにプロジェクト自体が活発ではなかったが、プラットホームの提供により注目を集めている
感想

サービスをスケールアウトさせる手段の1つとしてGoogleが行なっている分散処理技術について学ぶことは、今後のサービス規模の拡大が見込まれるサービスなどを構築することを考えると重要ですね。

また商用のデータベースを利用しないことでスケールアウトによるコスト増大を抑えることもできる点、数ギガレベルの大規模なデータを容易かつ高速に扱うことができる点についても非常に魅力的です。(オープンソースのRDBMS、PostgreSQLやMySQLだと、どの程度のサイズまで扱えるんでしたっけかな？)

Googleの分散処理技術を元に作られたオープンソースApache Hadoopの開発が活発になっているので、これについては少し詳しく調べていった方がよいですね。例えば、こんなところとか。

  • 小規模サービスから規模を拡大させているビジネスモデルの場合に、うまくマッチするのか？
    • 最初からある程度の規模(例えばサーバが数十台など)のインフラが必要とするのか？
  • スケールアウトする方法が容易であるのか？
  • ノード監視(例えば障害発生ノードの自動切り離し)などの機能があるのか？

今回のセミナーでは、Googleの分散処理技術に注目するにいたった経緯や、技術の概要説明のみにとどまっており、セミナーに参加する、独自に調査や検証などの作業を行なうなどといったことをして理解していかないといけないですね。

コミュニティパネル 「Webアプリケーション開発の今後を占う」 - 第1部 ポジショントーク

Seasar、Ruby on Rails、Springのそれぞれの立ち位置の違いがより明確になって面白かったです。

Seasar 代表 ひが やすを さん
  • 生産性を高める
  • フレームワークやツールを利用することで生産性が上がるか？
    • 実際には生産性が上がらない。
    • 例えば、MS Officeにおける機能拡張。機能が増えることで生産性が上がっているか？
  • むしろ開発者自身の生産性を上げるべきだ。
    • 集中力して作業を進めることができる環境。
    • けれどそれを阻害する要因がいくつか存在する。
      • 電話、打ち合わせ、その他
  • 今後は、フレームワークやツールなどを使うことによる生産性の向上よりも開発者自身の生産性を向上をする方向に向かうし、Seasarは開発者自身の生産性向上を目指している。
  • 開発者が作業を止めずにどんどん開発をするために、どうあるべきか？
    • SeasarではHOT deployという技術を組み込んでいる
    • これにより開発者は、ストレスなく開発を進めることができる。
  • HOT deploy、今度リリースされるS2JDBCのデモ
Ruby on Rails 代表 高井 直人 さん
  • 効率ってなんだろう？
    • 「ゴールは何か？」を設定しないと論じることができない。
  • じゃあ、Ruby on Railsのゴールって何？
  • Railsの効率って？
    • 柔軟性の放棄 → CoC(Convention over Configuration/設定よりも規約)
    • 粒度の大きい記述 → WEB+DBアプリケーションの領域に特化
    • 自動化・省力化 → コード・ジェネレータ
  • 枯れた技術の水平思考
    • J2EEパターンの考え方を元にして考えられてたり、適用している。
  • Ruby on Railsはなぜ成功したのか？
  • ROA (Resource-Oriented Architecture)はこれからキーとなる概念。
  • Ruby on Railsとは...
    • Webアプリケーションに特化
    • オーソドックスなパターンの採用
    • プログラマブルWebへ進化
Spring Framework 代表 鈴木 雄介 さん
  • Springとは？
  • 様々なフレームワークとの連携が可能
  • 規約より設定が重要
    • 明示的に設定することでオブジェクトを管理する
    • ただし、設定が容易でないといけない
      • 様々なパターンや規約を用意している
      • Spring 2.5では、設定ファイル以外にもアノテーションで設定することも可能に

参考サイト