2012年9月10日月曜日

OSC 2012 Tokyo Fall 1日目のみ参加

諸事情でINTEROPの報告が書けなかったが、OSCは書いてしまう。

オープンソースカンファレンス 2012 Tokyo Fall に参加してきました。

http://www.ospn.jp/osc2012-fall/

会場は明星大学。
とても大学っぽくて羨ましかったです。

片っ端から聴講してたので、それぞれについて簡潔に記載を。

全部書いちゃうのもアレなので、要所要所だけ。



■10:00-10:45 OpenStackで始めるクラウド環境構築入門

Ubuntu Server 12.04サーバ1台で、とりあえず動かしてみる。


・OpenStackの構成図のざっと説明
・OpenStackの構成要素について説明
 ・Nova
 ・Swift
 ・Glance
 ・Horizon
  ・Keystone
と、Novaのコンポーネントの説明
あとは設定方法やコマンド類の説明

●インストール時の罠があるようです。
ベースOSとしてUbuntu Serer 12.04をインストールする際に日本語を選択すると、stack.sh実行時にKeystoneの初期化に失敗する
→ 環境設定でEnglishを優先言語に変更しログインしなおすこと

apt-getが初回必要なので、その時はインターネット接続環境が必要

DeStackの場合ログの設定が別途必要。


所感:
入れてみました、動きましたね。という印象。
これから環境構築する場合にはコマンド手順らが使えるかもしれない。


■11:00-11:45  PostgreSQLエンタープライズコンソーシアムのご紹介と技術検証WG進捗のご紹介

各企業がPostgreSQLの商用での使い方、ノウハウをもっとオープンにしましょうよ。
という団体ができました。
その組織図のマイルストーンのお話。

ちなみに SRA OSS Inc日本支社は当然入ってるけど
NTT、NEC、日立、富士通など、有名企業類も参加なさっている様子。

技術展開等は今後発信していくそうです。
WG(ワーキンググループ)ごとにテーマを持つそうで
2012年度は性能と設計運用が主なテーマ。

ちなみにPostgreSQLそのものはもちろん
・pg-poolⅡ
・Postgres-XC
も視野に入ってるようです。
この点はとても期待。

あと、マンパワーが足りないらしいので、興味ある企業は是非とのこと。


所感:
広報系はパンフの話しか話さなかったのでカット。
技術系は個人的に突っ込んだ話をいろいろ聴けたので満足。
特にPostgreSQLConference 2012からXCは注目されてたので、色々と。。。


■12:00-12:45 LT@Bussiness Day

LTなので簡潔に。1人5分。

・Ustreamのやりかた
・MicroSoft AzureはMacでも動くよ!
・Monacaというクラウド上 iOS&Android向け開発環境のお話
・Job-Hubで、もっと自由な働き方をしよう
・MySQL マイグレーション ウィザードの紹介


所感:
OSCっぽかった。
基本的に各企業の宣伝だけど、ネタあり笑いありな和やかな感じで良かった。


■13:00-13:45 Oracle技術者必見! Postgres Plus Advanced Serverの実力とは

・PostgreSQLのおさらい
・PostgreSQLとOracle DBのアーキテクチャ
・Postgres Plus Advanced Serverとは
・Postgres Plus Advanced Serverの機能評価、性能評価


・PostgreSQLとOracleDBの違いで、Oracleの共有プール(実行計画を保存していくメモリ部分)がない
・実装レベル、性能障害対応でもさまざまな違いあり
→ 結果、PostgreSQLでもRDBMSとして基本機能が十分有するが、商用向けとしてはまだ不足している点が多い

・PostgreSQLの標準機能に加え、商用向け機能を充実させたPostgres Plus Advanced Server

・PostgreSQLとPostgres Plus Advanced Serverの比較をいろいろと実施
 ・データベース稼働状況を分析・診断する場合の工数
 ・ストアドプログラム
 ・SQLヒント
 ・CPU、セッションのスケーラビリティ
 ・共有バッファのチューニング

所感:
OracleDBに比較して、運用面・障害面でPostgreSQLはまだ弱いところがある。
そこを補う製品を展開。
お値段がわからない点、肝心のOracleDBとの比較が何もなかったのが残念。


■14:00-14:45
Webアプリケーションサーバ JBoss 入門~知っておきたい!JBoss移行時の注意点とAS7新機能解説~

・JBossとは、コミュニティ版と商用版がある。
・JBossメリット
 ・サーバのライセンスコストが削減
 ・オープンスタンダード
 ・長時間システム利用(最大10年のサポート適用)
・移行時はJAVA EE準拠で構成されたアプリは基本的には異なるAPサーバでもグ億
 ただし、他システム連携部分や非機能要件も踏まえて検討するべし
 → APサーバやロードバランサ等
・移行に大切なのは、移行リスクと影響度の調査が最も重要
・アプリケーションの移行の注意点や、WebLogicから移行の注意点


・JBoss7からドメインモードが導入された
 → 今まで1台ずつ管理していたサーバをドメインという管理単位にて一元的に管理できる
 ・また、そのための設定ファイル、注意点の説明
うれしいこと
→ システム全体をマスターホストで集約して管理が可能、ゆえに複数サーバからなるシステムの運用に要する管理コストを削減


所感:
移行時のノウハウや判断基準が開示されていたのは助かる。
結構ありがたい機能が追加された印象。多数のサーバがある場合に便利。


■15:15-16:00 Mongo DB 2.2の新機能

MapReduceなんて複雑な機能を使わなくてもいい時ってあるよね?
それを対応したよ。
イメージとしてはパイプラインのようにネストするのさ。
詳しくは 雲屋のWebもしくは公式ドキュメントで!

(゜Д゜)・・・え。

所感:
一瞬で終わった・・
たしかにMapReduceするまでもない計算って結構あると思う。 (温度の平均とか・・?)
「雲屋」さんのWebページに載っているらしいのでそこでスライド確認しましょう。。。


■16:15-17:00 Strutsの時代から標準Java EEで実現する効率的なWebサイトの構築へ

「JSF 2.0」を使うとこんなに楽になる という説明&ムービー
もうJSPも書かないでXHTMLで書く時代。
Ajaxの対応も1行でいいし、XMLもいらない。
タグも使えるしすごい便利。

所感:
開発者が便利&楽なのはとてもよくわかった。
メモリどんだけ食うのかなとか、実際に使ったらどうなのかなとか
いろいろ思った次第ですが、発表者さんのWebページにて
より詳しく書かれているようです。 リンクしていいのかな?

あと、Oracleさんでしたが、突如じゃんけん大会勃発
見事に勝ちましてJavaOneバッグもらえました。
各社のロゴ入っててかっこいいです。まじめに欲しかったんでうれしいです。
# 帰り大変でしたけど。



■17:15-18:00 JBoss Data Grid 6.0概要および検証結果の紹介

・InfinispanをベースにしてRedHat社が製品化
・分散メモリキャッシュストア

注意点
・ライブラリモードは、まだRedHat社が正式サポートしてないらしい。

データの保存方法4つ
・Local Mode 1台で構成
・ReplicationMode 参照向き クラスタ構成で、同一データを全ノードで保持
・InvalidationMode  一意なデータを持つことを保証したい場合用 クラスタ化されているが1つのデータは1ノードにのみ保持し、データ更新時に過去のデータを削除
・DistributionMode クラスタ構成で、1つのデータを複数のノードにレプリカを保持して参照させる・データ更新時は全レプリカを更新


ちなみに・・InfiniSpan事例 Redhat社資料による(らしい)
日本より海外で需要あり、主な目的がCoherenceからの移行。(高いからだろうなぁ)

・試験目的
キャッシュサーバにしたときの典型的シナリオで性能測定
・検証方法(ここでの記載はざっくり)
3シナリオでGET/PUTを用いた基礎性能
・想定シナリオ
1、GET/PUT=100/0  高速なデータ参照が必要な場合
2、GET/PUT=95/5 稀にデータ更新が発生する場合
3、GRT/PUT=50/50 参照も更新も多数発生する場合

・ハードウェア
検証クライアント メモリ96GB 4台
JBoss Data Grid サーバ メモリ96GB 4台
DBサーバ1台 メモリ48GB 1台 (メモリにのらない場合を測定したいため)

・結果サマリ
シナリオ1
データサイズ10GB、60GBで試験
40スレッド以上でデータ参照処理の負荷分散効果が現れ、4ノードなら2ノードのスループットの2倍

シナリオ2
PUTの兵器の打とう時間がGETと比較して約4倍かかる。
理由はデータを多重化しているため、そのノードで更新を行っているためと考えられる

シナリオ3
データサイズが大きくなってもスループットがほぼ一定
シナリオ2よりスループットは低下するが、スレッド数を増やした際のGet平均応答時間が1ms以下



所感:
1日通してもっともしっかりしてたと思った。
残念ながら、クエリ検索などの検証はなし。
当然なことにサーバ増やしてメモリ多いほうが良い。


■おまけ
自宅ラックの方々のサーバがとても業務用でした。
すごかったです、いやホントに。
とにかく参加者(特に展示ブースの方々は大変活き活きとして楽しそうでした)
いろんなグッズもらえました。