オープンソースミドルウェア技術セミナー＠東銀座

ということで午後年休とって東銀座のJJK会館で開催されたオープンソースミドルウェア技術セミナーに行ってきましたよ。

概要

司会進行は稲葉さん＠SRA OSS

オープニング

最初に石井さん＠SRA OSSから挨拶＆セミナー概要の紹介。

PostgreSQLをクラウドで利用しよう

発表者は正野さん。
最初はPostgreSQLの概要の説明。まあ、ここは・・・
次は導入事例紹介。
- 日本だとJTB旅カード。
  - pgpool-IIも併用
- 海外の導入例。Zalando(オンライン服飾販売サイト)の例。
  - DBサイズの総計は5TB
PostgreSQLにおける様々なHA構成の話
- PacemakerとPostgreSQLによるフェイルオーバの説明
- pgpool-IIとPostgreSQLによる参照分散とフェイルオーバの簡単な紹介。
後半はクラウド上でのHA構成の話。
今回はAWS + PostgreSQL(Amazon RDS)上でHA構成を構築するという話。
Availability Zone(仮想環境が動作している物理サーバ)を分けることで、簡単にHA構成にできる。
AWS + PostgreSQL + pgpool-IIの組み合わせ。
- AWSでは仮想IPの仕組みが使えない！
- このためNATインスタンスを使ってネットワーク経路を変更するというテクニックを使っている。

Q.A

AWSのデータ同期は5分間隔と聞いたがそうなのか？
- 5分間隔の同期対象はバックアップファイルなどが対象となる。データに関しては直前のトランザクションまでは保証している。AWSで実現してるけど仕組みの詳細はわからない。

東京大学における超高速データベースエンジンの研究開発 - PostgreSQLベース実装の取り組み -

個人的に今日、一番関心があった発表。
発表者ははやみずさん＠東大喜連川研究室
WebDB Forum 2013で発表・受賞した内容。

ビックデータ化された世界

最初はビッグデータ化された世界の話。
- もうペタとかエクサの時代なんだよねえ・・・
- で、データベースシステムはビッグデータに対応できているのかと。

最近の高速化技法の傾向とOoODE

プロセッサ
- クロックレイテンシ短縮は停滞
ストレージ
- シークレイテンシ短縮は停滞
ソフトウェア
- インオーダ型クエリ実行→マルチコア/広帯域入出力が生かせない
- そこでアウトオーダー型データベースエンジン(OoODE)にしたい。
アウトオーダー型クエリ実行って？
- 簡単にいうと出来るものからどんどん処理していく。
アウトオーダ型クエリの適用領域は、超大規模データで、少量の結果は取得したいけど、結構なサイズのデータの読み込みは行うというもの。
処理内容に応じて、どんどん動的にスレッドを起こして非同期・並列に処理をさせる。で、結果的にI/Oなどの処理をまとめておこなえる。

OoODE実現のアプローチ

エンジン全体の非同期化 vs エンジンの部分的な非同期化
同期的クエリ実行と非同期的クエリ実行をエグゼキュータで連携できないか。→今回はこのアプローチ
OOODE型加速機構を既存エンジンにプラグインとして組み込むという考え方。
データを予めバッファに読み込んで、通常クエリ実行のバッファヒット率を向上させるもの。
- のべつまくなしにバッファに読むのではなく、インテリジェントに予測してバッファに読むみたい。
で、PgBoosterというものを作ってPostgreSQLに組み込んでみた。
PgBoosterではコーディネータプロセスを介して、加速器で効果がありそうなクエリが来たらこの機構を走らせてバッファ読み込みをさせる(ような図に見えた)。
実装は7000行(ほぼ追加)

実機デモ

インオーダーの場合、ディスク24台あっても使い切れていない。
アウトオーダの場合、ディスクをがりがり使っているのが見える。
数十分のクエリを10秒で！
TPC-HベンチマークだとpgBoosterを使った場合、平均20倍(最大36倍)の高速化効果があった。
SRA OSS.でもTPC-H(SF-100)の検証をやってみた。
中規模(TPC-H SF-1000)で検証
- ディスクの帯域が広くなるなど、さらにPgBoosterの恩恵を受けられる。数百倍に高速化する例も。

PostGIS(R-tree)への応用例

GiSTインタフェース上でPgBoosterを組み込んでみた。→1TBのデータの解析が300倍近く高速化できた。

今後の課題

加速機構の高度化や利用性の向上が課題。

Q.A

QA. この機構はPostgreSQLに限らず適用は可能？
- yes
QA. どうやって加速機構向きのクエリだと判断しているの？
- クエリプランや統計情報を見て判断している。1%以下の絞込を行うクエリだと非常に効果が高い。
QA. CPUコア数にスケールして加速器は向上するのか？
- 今回の実装はI/Oをターゲットにしている。

石井さんのコメント

PostgreSQLの基本機能をそのまま残し、APの修正なく高速化されているのが素晴らしい。
喜連川先生イズムを感じる発表でした(超意訳)

ZabbixでPostgreSQLの監視を行おう - pg _monzの紹介 -

発表者は盛さん

統合監視ソフトウェア、Zabbixの話。

- PostgreSQLはクラスタ化のバリエーションが多い・・・それぞれどう監視していくのかも課題の一つ。
- 統合監視ソフトウェアは設定が大変。
- システム固有の情報が多く動的に増減する・・・
Zabbix
- 今一番人気がある、勢いがある統合監視ソフトウェア
- 拡張監視(スクリプト実行結果を監視する)
- 設定作業の自動化→これがPostgreSQL監視に使おうと思った大きな理由。
Zabbix Agentを監視対象とする。このエージェントを各サーバに配置する。
エージェントがインストールできないものはSNMPやPINGなどを使って監視する？

pg_monz

名前の由来
- pg_・・・PostgreSQL
- mon・・・monitor
- z・・・Zabbix用
ZabbixのPostgreSQL監視テンプレート
監視内容は死活、ログ、リソース、性能
PostgreSQLは9.2以降に対応
Zabbixは4つのファイルから構成
- pg_monz_template.xml・・・Zabbixにインストールするもの
- LLDスクリプト2つ(データベース名、テーブルに対応名)
- userparameter_pgsql.conf・・・DB稼働統計情報の問い合わせ
pg_monzの監視項目
- テーブルあたりの監視項目はテーブル数が多くなる監視項目数が増大するのでデフォルトは無効になっている。
性能への検証
- 300データベース、あるいは300テーブルを監視対象にすると、DBサーバの負荷は20%程度上昇する。監視間隔の調整などが必要かも。
pg_monzはリリースしたばかり。今後はクラスタ構成への対応が課題。
background Worker Processで実現できないかというプランもある。

QA.

閾値などは自動設定される？
- 現状のバージョンではテンプレートでは閾値の自動計算はできない。今後の課題。

ログ収集基盤 fluentd の紹介

発表者は引き続き、盛さん。

ログ管理

最初はログ管理の一般論と現状のログ収集機能
- バッチ収集、syslogサーバ、rsyslog、fluentd

fluentd

特徴
- インストールは簡単
- 豊富なプラグインがある。
- 負荷分散、可用性・・・rsyslogでは難しい
- ログのJSON化・・・これがfluentdの特徴の一つ
fluentdでログを活用しよう。
- RDBMSでもいいしNoSQLでもいい。
- フィルタリング
- 集計・解析機能のプラグインもある
fluentdという名称は開発者向け。安定版はtd-agentという名称。
- tdってTreasure Data社の略なんだろうなあ。
ログの半構造化
- 時刻の統一フォーマット化もfluentdでやってくれる。
- 時刻がないログの場合、fluentd側で時刻を付与してくれるみたい。
むー、ログのフォーマットは正規表現か・・・ログ出力のデバッグが大変そう・・・
outputプラグインにはpgjson(PostgreSQL JSON型変換)もあるのか。
バッファリング先にファイルを指定するとfluentdがダウンしていてもバッファ用ファイルからの復元ができると。
ログ転送機能によって複数サーバに送信してHA構成もとれる。
おまけ：fluentd + PostgreSQL9.3 →あー、やろうと思ってたことが書いてあった。まあ、誰でも思いつく話ではあるが。

クロージング＆退場

稲葉さんの営業タイム。主催だから当然だけど。
帰る間際に石井さんに挨拶。はやみずさん発表ネタで軽くトーク。