第5回オープンソーステクノロジー勉強会－開催のご報告－

2006年7月31日(月)、国際大学グローコムにて、第5回「オープンソーステクノロジー勉強会」が開催され、約80名の方にお越しいただきました。

第一部では、SRA OSS, Inc.日本支社取締役支社長の石井達夫氏に、ご講演いただきました。日本PostgreSQLユーザ会初代理事長でもある石井氏から、「PostgreSQL10周年おめでとう!」と題して、PostgreSQLの歴史、普及の経緯、今後の展望などについてご説明いただきました。

（発表資料はこちら）。

第二部ではグリー株式会社の三野泰宏が、前回から引き続き、ウェブデザインパターンでの開発をテーマに発表させていただきました。グリー株式会社での実例をもとに、デザイン担当者としての視点から、導入方法についてご紹介いたしました。

（発表資料はこちら）。

懇親会も前回同様盛況となりました。

今回も、ご参加いただいた皆様、誠にありがとうございました。

来月の勉強会は、8月下旬を予定しております。近日ご案内を掲示いたしますので、ぜひとも奮ってご参加ください。

参加者からのご報告

参加者の皆さんのブログや日記のエントリーをご紹介します。こちらで確認し次第、随時更新いたします。今回の勉強会について書かれた方は、「オープンソーステクノロジー勉強会」という言葉を入れてご記入いただければ、追加いたします。

講演資料(1) .「PostgreSQL10周年おめでとう!(仮題)」

podcast: 音声ファイル(mp3 30,282,612バイト)
RSSフィード(podcast対応)
講演資料: gree_study_20060731_pgsql.pdf

開会の辞(ふじもと)

宣伝
- KDDIさまと提携しました:)
- オープンソースマガジンに記事書きました(9月発売予定)
  - 是非読んで感想をください
- 8/19 PHPカンファレンス2006を蒲田でやります。是非来てください
- 8/26 Lightweight Language Ringに参加します。是非是非来てください

第1部：PostgreSQL10周年おめでとう

はじめに
- GLOCOMで話しをするのは数年ぶり。都会に来れてうれしい
- 7月8日・9日、カナダのトロントでPostgreSQL Anniversary Summitに参加しました
  - SRA OSS, Inc. 日本支社からも3名参加
- 独立行政法人情報処推進機構(IPA)の支援を受けてpgpool-IIを開発中
- 前半はPostgreSQLの歩みを振り返りたい
- 後半はPostgreSQLクラスタ用ミドルウェア(pgpool-II)についてのデモなど

自己紹介
- 石井達夫(SRA OSS, Inc. 日本支社取締役日本支社長)
- SRA OSS, Inc. 日本支社
  - PostgreSQL/Linuxサポート(2/3がPostgreSQL関連、残りはサポート)：契約数100
  - PostgreSQLトレーニング：受講者数700名
  - PostgreSQL認定試験(CE)：受講者数700名
  - PostgreSQLベースパッケージ「PowerGres」の販売：出荷数3,000本
- SI以外のPostgreSQLに関することをやる唯一の会社(自慢:)
  - SIをやらないのは、(親会社である)SRAがやってるのと、OSSでないとできないビジネスモデルをやりたいから

PostgreSQL開発者として
- 国際化など
- ベンチマークツール(pgbentch)
- ミドルウェア(pgpool)

PostgreSQLエバンジェリストととして
- 日本PostgreSQLユーザー会の立ち上げ
- 書籍・雑誌
- ビジネスを通じてPostgreSQLを普及させる(重要)

自分にとっての目標設定
- PostgreSQLはエンタープライズ向け、企業ユースが多い
- 開発コミュニティも重要だが、企業のために役立つサービスの提供が重要であり、経営戦略であり、それが自分の目標
- 後世にも役立つ成果を残すことができれば最高

PostgreSQLの歴史(1)
- University Ingres(1977)
  - カリフォルニア大学バークレー校(UCB)で開発
  - 最初期の関係データベース
  - PostgreSQLとは直接ソースコードを共有していない(コンセプトは引き継がれている)
- postgres(1986)
  - 関係データベース + オブジェクト指向
  - 直接の祖先
  - 今も当時のソースが一部に残る
  - 大学研究だったので研究終了で幕を閉じる
- postgres95(1995)
  - postgresを引き継いで有志で開発
- postgresql95 日本語MLスタート(1996)
- PostgreSQL V6.0(1997)
  - このサーバを立ち上げたのがトロントにあった(それでセレモニーはトロントで開催)

PostgreSQLの歴史(2)
- PostgreSQL V6.1
  - 遺伝的アルゴリズムオプティマイザ
- PostgreSQL V6.2
  - JDBCドライバ、トリガ
- PostgreSQL V6.3
  - 副問い合わせ
- PostgreSQL V6.4
  - ビュー、ルール、マルチバイトサポート(国際化)
- PostgreSQL V6.5
- MVCC(更新トランザクション中に読み込みができる、野心的トランザクション機能)

PostgreSQLの歴史(3)
- 株式会社 SRAでPostgreSQLビジネス開始(1999)
- 日本PostgreSQLユーザ会設立

PostgreSQLの歴史(4)
- PostgreSQL V7.0
- ここから加速度的に企業ユースが増えてくる
- PostgreSQL V8.0(2005)
  - ここまでは毎年リリースだったが、Windowsサポートなどにより時間が掛かった
- PostgreSQL V8.1(2005)
  - 性能の著しい向上

PostgreSQL Anniversary Summit
- カナダトロントにて開催
- 青いＴシャツ(開発者、スピーカーによる直筆サイン入り)をオークション
  - 1000ドルで落札(×3着)
  - 開発費へ
- サミットの模様は日経ITProにて掲載予定なので見てください
- SRA OSS, Inc. 日本支社のWebにも掲載してます

PostgreSQL 8.1での性能改善(検索)
- TPS(縦軸)・同時接続数(横軸)
- PostgreSQL 8.0：負荷が増えるとパフォーマンスが落ちる
- PostgreSQL 8.1：負荷が増えてもパフォーマンス変わらず

PostgreSQL 8.1での性能改善(更新)
- TPS(縦軸)・同時接続数(横軸)
- PostgreSQL 8.0：負荷が増えるとパフォーマンスが落ちる
- PostgreSQL 8.1：むしろ同時接続400で性能が上がっている!!

PostgreSQL 8.2は？(捕捉)
- 今まで苦手だった小さなテーブルに更新を重ねる場合の性能がアップ

PostgreSQLのクラスタリング・レプリケーションソリューション
- クラスタリング・レプリケーションとは？
  - 複数のPostgreSQLサーバを使って信頼性・性能を向上させる技術
- 単独のPostgreSQLでは対応できないような高信頼性、高性能が要求される分野でホットな話題
  - 基幹業務
  - 大容量データベース
  - 高負荷
- クラスタリング・レプリケーションは一生懸命開発が行われている

レプリケーションの方式の違い
- 簡単に言うとコピー
- 同期(eager)/非同期(lazy)に分かれる
  - 同期：いつでも複数のDBサーバが一致
  - 非同期：マスターDBの内容がある遅れをもって他DBに伝播
  - 負荷が低いので性能が上がる
  - 後で更新するので不整合がおきることも...
- 一長一短なので用途に合わせる必要あり

クラスタ構成の違い
- shared nothing方式
  - 独立したDBサーバを複数使う
  - 更新系の性能向上が難しい
- shared方式
  - CPUやディスクなどの一部のリソースを共有(ディスクを共有する方式が多い)
  - 排他制御が難しい
  - 更新系の性能が向上する場合がある(PostgreSQLではまだ実装がない)
  - PGClusterでこの方式のデモがあった

並列処理・負荷分散
- 並列処理(parallel query)
  - 複数のDBサーバでクエリを並列実行
  - 分けて問い合わせして、結果をマージする
- 負荷分散
  - 複数のDBサーバに負荷を分散する
  - 複数セッション時に性能が向上する
  - 複数サーバで常に同じデータを持つ必要あり(レプリケーションが前提)

PostgreSQL用のクラスタ・レプリケーションソフトの例
- Slony-I
  - 非同期レプリケーション
  - 実績有り
- PGCluster
- pgpool
  - 石井さん中心に今はチームで開発する体制になった
  - 小規模向け(サーバ2台まで)
- pgpool-II
  - parallel queryをサポート

pgpool-IIとは
- IPAの補助を受け、SRA OSS, Inc. 日本支社で開発
  - 1月から開発し、9月納品
- pgpoolを置き換えるもの
- 9月に最初のバージョンを公開予定
- GUIツール搭載(pgpoolAdmin)、ノード数の増加、SQLパーサーを使って効率的処理を実現
- 現在10ノード構成をBlade Serverで試験中

pgpool-II Developers!
- Tatsuo Enhance pgpool-I pgpool developer
- Yoshiyuki Project leader pgpool developer
- Taiki PCP Query Cache pgpool developer
- Yoshiharu Query rewriting Parallel execution engin
- Tomoaki Communication manager
- Kaori Project manager System DB

pgpool-II architecture overview
- PostgreSQLに手を入れない方針なので、SQLをパースしqueryを書き直して投げる
  - System DB：pgpoolを管理する用のPostgreSQL
- 書き換えたクエリをParallel execution engineに投げて複数DBに並列問い合わせをする
- 従来のpgpoolの動作モードでも実行できる
- 並列 or レプリケーションしかできない？
  - カスケードで実行できるので並列且つレプリケーションでの組み合わせ実行も可能

Simple parallel query
- 単純に条件を分割し結果をマージする
- 複雑なqueryになるとそうは簡単にいかない場合もある
  - 副問い合わせでソートがある場合など
- 問い合わせを書き換える(ソートする仕組みなど)
- pgpoolとSystem DBの間を再帰する形で実行して行き、書き換えて実行する
- 図解を配布するのでそちらで理解してほしい

pgpoolAdmin
- Webベースの管理ツール
- pgpoolの起動/停止
- 設定ファイルの編集
- 各種モニタリング

Benchmarks
- Hitachi Blade Symphony BS1000
  - 10 Blade
  - Xeon 3.0GHz×1
  - 1GB Memory
  - UL320 SCSI Disks
- Cent OS 4.3
- PostgreSQL 8.1.4/pgbench
- 冷蔵庫みたい(600kg)
- 港北から大塚の引っ越しがすごく大変でした:)

Sequencial Scan case(mid size)
- データ量1GB(9,000万レコード)
- 通常PostgreSQLとpgpool-IIではユーザー数に対しスケーラブルに性能が伸びる
  - 通常のPostgreSQLの7倍早い(32接続ユーザー)

Index Scan case(mid size)
- データ量1GB(9,000万レコード)
- 通常のPostgreSQLの9倍早い(16接続ユーザー)

Index Scan case(large size)
- データ量10GB(9億レコード)
- 通常のPostgreSQLの18倍早い!!(32接続ユーザー)
  - キャッシュがうまく効いている？

Complex query case
- 難しい問い合わせをやると、オーバーヘッドが発生する
- 8接続ユーザー以上から早くなる(でも20%くらいしかない)
- 外部ミドルウェアという立場のツールなので性能向上の余裕がある
  - 将来的にはもっと向上させたい

デモシステムの概要
- ノートPCのVineLinux 3.2上でPostgreSQLを4つ、ポート番号を変えて別DB(うち1つがSystem DB)として稼働
- pgpoolAdminを利用することで
  - 負荷分散の割合などをノードごとに設定できる
  - 特定ノードを落とすこともできる

testデータベースに接続
- 簡単な選択SQLを実行→特定の1台でのみ動いた。
- 何回かやると、3台のうちどれかに投げられる->負荷分散されている
- 更新SQLを実行→すべてのDBサーバで実行された
- 同じSQLをすべてのノードで実行することでレプリケーションを実現

パラレルクエリーモードで実行
- pgpoolを再起動する必要がある。pgpoolAdminで停止モードも指定できる
- 並列モードのpgpoolに接続する
- pgbenchによる10万レコードのデータ入りDBを検索
- SELECTを実行すると、3つのDBに同じSQLが投げられている
- もう少しややこしいSQL(count(*))
  - 3つのDBで行数をとってきて合計する(関数ごとにマージのノウハウを追加している)

質疑応答
- 並列処理モードでINSERTを動くとどういう動作になるのか？
  - System DBにコントロールを行う情報があり、パーティショニングを行う
  - パーティショニングを行うか、方法についてはユーザーが設定できる
- 負荷分散をランダムで投げるのはなぜ？
  - 重み付けが実現できる方法で一番簡単な方法だったから
- もっと最適な振り分け処理に切り替えることができる？
  - まだまだ改良の余地はある
- System DB自体が弱点にならないか？
  - そこでカスケードを使うことで負荷分散・多重化できる
  - SystemDBをpgpool-Iモードで実装することができる
- 9月リリースということだが、いきなり使って大丈夫な品質か？
  - いきなり基幹業務に使うのはちょっと...
  - 人柱志望者にはソースあげます(IPAの許可済み:)

講演資料(2) Webデザインパターン実装編

podcast: 音声ファイル(mp3 8,719,678バイト)
RSSフィード(podcast対応)
講演資料: gree_study_20060731_wdp.pdf

第2部：(デザイナーにとっての)Web Design Patterns

自己紹介
- 三野康宏
- デザイナーです
- 大学生をしながらGREEの準社員として従事しています
- 春休みを使ってGREEキャリアの開発に携わったときに利用したWebデザインパターンの説明をします

目次
- Web Design Patternsの動向
- デザインパターンの狙い
- 前回からの経過をご報告

Web Design Patternsの動向
- Web Design Patternsを集積したサイトの紹介
  - www.welie.comを参考
  - Yahoo Design Patterns
  - Web標準の日でもデザインパターンに言及されたセッションがあった
- HTML部品化するという考えは元からあった
  - CSSができることで表現が自由に
  - 反面、HTMLタグの自由度が増してタグと実際の役割が乖離することになった(CSSにつけるclassやID名の命名が困難になる等)

デザインパターンの狙い
- Christopher Alexander(クリストファーアレキサンダー)著　"A Pattern Language"
  - デザインパターンの原点である本
  - 建築を元に発想したもの
- デザインプロセスにおける共通言語
- 問題発生・解決のシーン(設計・施工)ごとにパターン化
  - これらを繰り返すことで共通言語を洗練化する
- 共通言語を作ることで、各担当者の認識を共通にする。コミュニケーションをスムーズになることで、意志決定が早くなる
  - class/ID名が各プロセスに浸透しやすい

前回からの経過をご報告
- GREEに合ったデザインパターン名を再定義し、質を向上
- エディタ(CSSEdit)を用いて可読性を向上
  - タグで囲むとグループ分けされる
  - CSSをグループにしてコードをまとめてスニペットとして利用できる
- Wikiにドキュメント化
  - パターンごとにイメージとCSSとHTMLをまとめている

Future Works
- Wikiドキュメント化を継続し、使いやすさを向上する方向で応用
- GREEキャリア以外の他サービスへの適用していく
- モバイルも再編中

質疑応答
- class/IDの名称ルールも規定されているのか？
  - www.welie.comを見て該当パターンを探し、そこから拝借した
  - ないものは新しく定義。後々使うのでデザイナとエンジニアで相談して決める
- そのとき、たとえば入れ子になったり入れ子の中で同じ構造があるような場合のルールも決まっているのか？
  - GREEキャリアの制作が最初だったので、ほとんど手探りだった
  - 作る中で勝手に決めていくものもあり、似たような関係のものがあったり、似た名称のものもあったので随時整理していた

構造化をしっかりしているようなので、機械的に一気にclass/ID名から...というのは考えているか？
- 理想はそうだが完全には難しいと思われる
- 細かいコードをスニペットに吐き出してそれをコピペするのが現実的ではないか

エンジニアとデザイナでものを作っており、エンジニアが勝手にclassを作ってしまうがどこまでCSSをわかっているものだろうか？
- GREEのエンジニアはHTMLとCSSができるのが前提
- 勝手に決めてしまわれてもWeb Design Patternという考えを共有しているのでお互い納得して適用している
- デザイナーがclass/IDに関して考えるのがエンジニアとしても望ましいのではないか