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

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

第一部では、ミラクル・リナックス株式会社取締役CTOの吉岡弘隆氏をお招きし、「RDBMSのスケーラビリティについて」として、先ごろ行ったベンチマークの結果とそのプロファイリングについて詳細にご説明いただきました。また、後半では、ご自身の体験をもとに、エンジニアのキャリアについてお話していただきました。

（発表資料:RDBMSのスケーラビリティ / 発表資料:エンジニアのキャリア）。

第二部ではグリー株式会社の岩崎匡寿が、ウェブデザインパターンを利用した開発について、ウェブデザインパターンの概要、導入に当たってのメリット/デメリットとあわせて、グリー株式会社での開発実例について、ご紹介いたしました。

（発表資料はこちら）。

懇親会には45名の方にご参加いただきました。

今回は、悪天候の中も、過去最高の人数が集まり、大変充実した勉強会となりました。ご参加いただいた皆様、誠にありがとうございました。

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

参加者からのご報告

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

講演資料(1) RDBMSのスケーラビリティ

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

第1部：RDBMS(PostgreSQL)のスケーラビリティ

自己紹介
- 吉岡弘隆(ミラクル・リナックス株式会社取締役)
- U-20プログラミングコンテスト審査委員
  - 応募よろしく！

アジェンダ
- Postgresの大規模マシン上(16CPU)での評価について
- 8CPUまではスケール

なぜスケーラビリティが重要か
- いままではクロック数向上に依存したが、今後はそれが見込めないと言われている
- クロック数^2に消費電力が比例し、物理的に限界がある
- マルチコア化、SMP(マルチプロセッサ)化
  - CPU数を増やすことが重要

CPUを増やしたときに性能があがるか？(=スケーラビリティ)

OSSとスケーラビリティの関係
- Oracleはスケーラビリティを考慮している
- OSSは個人開発が中心によるため実験環境に乏しい
  - バザール形式での開発は厳しい
  - 企業とのコラボレーションが必須
  - 個人でもチャレンジングで楽しい課題ではある

OSS推進フォーラム
- IPAの中に民間・政府・大学を含めたフォーラム
- 技術的・制度的な問題を語る
- 開発基盤ワーキンググループ
  - DB系

ベンチマーク
- PostgreSQLをCPU数16、ES7000で評価
- DBT-1でベンチマーク

DBT-1とは
- オープンソースのベンチマークツール
- OLTP系負荷ツール
- TPC-W(企業系ベンチマークを行うNPO)

CPUスケーラビリティ評価結果
- PostgreSQL 8.1では8CPUまでスケールアップ
- 12,16CPUでスループット低下(オーバーヘッド顕在化)
- ハイエンドサーバではある程度いけるが限界もある

測定環境
- 16Way IA32サーバ
- Miracle Linux 4.0(kernel 2.6)

チューニング無しでの測定結果
- 仮想ユーザー数を増やしても頭打ちになる
- 仮想ユーザー2400付近で限界

チューニングを行った測定結果
- postgresql.confによるチューニング
- shared buffer値の向上
- 8CPUまでだと頭打ち点が向上する。
- 12,16CPUだと逆に頭打ち点が8CPUより低くなる

ボトルネックさらなる解析
- Oprofile
  - プログラムをプロファイリングするツール(DB専用ではなく汎用製品)
  - PostgreSQLでは--enable-debugを有効にし、makeする必要がある
  - プロファイルしたデータはOpreportで簡単に集計できる
- Oprofile callgraph
  - 関数がどの関数から呼んだ、呼ばれたか、とかその回数を集計できる
  - ReadBuifferからのロック処理でCPUリソースを消費していることがわかった

PostgreSQLの内部ロック処理(s_lockとは？)
- スピンロックでループを回しながら待つ
- CPUリソースを食う
- 結構使われている。どういうときに使われているのか？
  - トランザクションで使う(排他ロックや共有ロック)
  - CPUが増えればロック回数も増え、競合が発生。その間プロセスが何もできずに性能低下
  - バッファプールのメモリ管理に問題があることが判明

まとめ
- ボトルネック解析はoprofileを使い、呼ばれている関数をしらべ、その処理を見つけ出すのが常道
  - ここまではソースを読まずともツールでわかる(MySQLでも同様)
- MySQLでは3, 4CPUで頭打ちになった
- ロック競合を減らすにはいろいろテクニックがあり、それらを選びながら実験していく
- PostgreSQL 8.2には修正されているかも

今後
- プロファイラでのチューニング技法を広めたい
- PostgreSQL/MySQLで今後もっとディープに調べていきたい
- 測定結果はOSS iPediaで公開してます

今後の課題
- バッファ管理におけるLWLock処理の詳細な処理の分析
- ハッシングによるロックリソースを分散させる

質疑応答

ES7000はフォーラムで持っているのか？
- UNISYSさんのもの。申請して借りた

ES7000のようなマシンをフリープログラマが借りたい場合どうすればいいか？
- 現状難しい。可能な作戦を考えたい
- IPAのような公的機関で検証センターができればいいかなと思っている
- 制度的解決を試みたい

共有メモリロックで困っている人は多いが情報が少ない。情報収集方法はどうすればいいか？
- 簡単な答えはない
- こういった勉強会の場などで知り合いを増やしてそこで解決
- 自分自身も悩んでいる。会う人ごとに聞いているのが現状
- 最初のランナーは雪道を漕ぎながら歩いているようなもの。ひたすらがんばるしかない

個人ユーザーが如何に安く、効率良く検証を取り組むにはどうすればいいか？
- 大勢の力でブレイクスルーするもの、少数の努力でブレイクスルーするものがある
- フリーのHackerのパワーをuniteするような仕組みを考えていきたい
- 個人の思いを伝える手段は現在はある。思いを伝えてお金を持っている人を動かすというのもアリ

OSSのDBを安価なマシンで横展開する場合、CPUの前にHDDやメモリの方がボトルネックとして大きいのではないか？
- そちらについてはvmstat等で検証できる

今回のベンチマークはそういう意味で意義があったのか？
- メーカーにとってはES7000を売れる。Oracleをさける傾向はある
- 一般の人にとっては…別の評価手法が必要

今回の結果をどのくらい情報共有しているか？
- SRA-OSS の石井さんと実施した
- 本家もこういうベンチマークは行っておらず、期待されている

8CPUで限界だったが、それ以上並べる際の解決策はあるのか？
- ある。並列度はDBにおいておおきな問題
- バッファープールのロックを如何に解決するかという問題を解決すれば…

MySQLでも同様構成で検証した際のデータは公開されているのか？
- 当時は別のマシンだった。ES7000は現在検証中
- 当時のデータは(どこかに)公開されている

Linux 2.6で検証したが、OS自体のスケーラビリティは8～16CPU程度では問題ないという前提でおこなったのか？
- 2.4で顕著だったロック競合(4CPUで発生)を2.6では発見できなかった
- 2.6ではロックの問題は解消されたという仮定に基づき、今回はDBMSにフォーカスした
- IO系ベンチマークで顕著に発生。これもIPAで公開されている

第2部：エンジニアとしてのキャリア

エンジニアのキャリアとはなにか？
梅田さんの「高速道路時代」を借りたキャリア論
- ネットのおかげで2次情報へ簡単アクセスできる(高速道路)
- 高速道路の先はやっぱり渋滞
  - ロックの話でも30,40年の研究成果があるのに知識化されていない

人の下をいけ
- 1次情報にアクセスしろ
  - そうすれば、1次情報までは高速道路
  - 渋滞を抜け出すには、やはり定番の一次情報をとにかく読んで基礎体力を身につける必要あり

流行は追うな
- 流行を信じるな
  - 技術進歩とは実感的に昨日の話がすぐ陳腐化するものである
  - でも、原理原則はほとんど変化がない
- OSもRDMSも「性能は重要である」
  - その解決を行うときに、基礎体力をつけていくか、最初からgoogleに頼るではかなり違う
- プロファイリングしてボトルネックを発見するというのは、30年以上前までの常道である
  - そこから先を進むのに基礎体力重要
- ボトルネックはCPU、メモリ、IO、ロック。これも30年以上前から常識

続けろー
- 10年続ける
  - プログラムでも日記でも
- プロフェッショナルになる
- 35歳で引退するなー
  - それまでの経験がもったいない
  - それまでの10年を応用する。そうすれば、世界に通用するプログラマが一人増える
- カーネル読書会
  - みんなでカーネルをわいわい読んだ方がおもしろい
  - 月に1回くらいでまもなく10年
  - 楽しいから、というのは継続するのに重要
  - 勉強になる
  - 知り合いが増える。ネットで、自分の楽しみを共有できる人は他にも居ることがわかる

自分は成長しているか(自らをベンチマークする)
- 半年前、3年前、10年前、技術的なことに限らず、何らかの形でログを残してみる
- 自分に正直になることも重要

質疑応答

2年前までは開発していたが、現場から離れていながら技術を追う必要がある。座学でも意味があるのか？
- どんなことにも意味がない、なんていうことなどない
- 徐々に継続することで、ある時目の前が開ける時がくる
- 山を登るかどうかは自分で決める

(第1部で質問したかったけど)MySQLはバージョンは？
- 5系でした

講演資料(2) ウェブデザインパターンを利用した開発

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

アジェンダ
- ウェブデザインパターンとは？
- メリット・デメリット
- (GREEにおける)利用例

ウェブデザインパターンとは？
- Webのデザインにおけるデザインパターン
- どういうとき・どういうふうに、というのを部品化して構築時に楽をする
- ウェブデザインパターンはメジャーではない。これから普及するかもわからない
- 発展途上な考え方であり、本で書いてあるのをそういう風に統一して呼称している。名称も固定されていない

ウェブデザインパターンの例
- 例：Advanced Search

ウェブデザインのパターン化
- いろんなところで試みが行われている
- Web Design Patterns
- Yahoo Design Patterns
  - アプリケーションに特化。Ajaxにまで及んでいる
- An Introducution to Using Patterns in Web Design

Web Design Patterns
- Martijn van Welie 氏によるサイト
- 日本では全然。外国でもこれから
- いくつかのジャンルにわかれてパターンが定義されている
- 充実したコンテンツ
  - パターンが多い
  - 著名サイトでの例がわかりやすい
  - 本当にパターンなのか？独立性という面で難しい面もある
- GREEではこのアプローチを取り入れている

パターンのサンプル紹介
- ListBuilder
  - 複数アイテムをユーザーが編集するときに使う
- Main Navigation
  - 水平・垂直のパターンがある。たとえばタブ形式
- Breadcrumbs / paging
  - パンくず
  - ページング

メリット
- デザイナとの意思疎通がやりやすい
- 作業工数の削減
  - 大枠で部品・タグを決めておける
- 少しずつ作りやすい
- 部品化することでデザイン一貫性が保てる

デメリット
- 関係者の理解が必要
  - 特にデザイナ
- 開発初期から関係者全員でコミットする必要あり
- XHTMLとCSSの知識重要

(GREEの)利用例
- まず上にメインナビゲーション置こうか
- (...アニメーションによりデザインが完成していくと...)
- こうして(非常に胡散臭い形で)GREEキャリアが完成した！

宣伝
- WEB+DB Press Vol.33に掲載されます

今後(Future Work)
- GREE全体でのパターン適用を
- スピードアップ・スムーズな展開
- 実装レベルまでとりまとめたい

質疑応答

GREEではCSSは誰が書いている？
- デザイナ・開発者の両方が書いている
- サービスによるアサインの関係もあり、決まっていない

属人的になっていないか？
- なっている
- それをウェブデザインパターンで解決したい。それがどういう着地点になるのか

JavaScriptを使うとHTMLが乱れ当初と変わったものになるが、どうしているか？
- 最初から完成形を求めていない
- サイクルの中で作っていくので、そういう意味での苦しみはない

開発者のデザインパターンは抽象レベルだが、ウェブデザインパターンはどのレベルなのか？
- デザインの要素を如何にパターン化するかが主眼。細かい実装はわからない
- GREEではさらに一歩進めて、HTML再利用性に対して今から打てる手をという意図で実装に踏み込んでいる