Personal tools

LinuxCon Japan 2010 / Tokyo

Kohei KaiGai


2010年9月27日から29日にかけて、The Linux Foundation の主催による LinuxCon Japan 2010 / Tokyo が、六本木アカデミーヒルズで開催されました。今回のレポートでは、その中で PostgreSQL をテーマにしたセッションの内容をご紹介します。

LinuxCon Japan 2010 / Tokyo とは

LinuxCon Japan とは、The Linux Foundation がグローバルに展開する一連の LinuxCon ブランドを冠したイベントで、セッションの水準や参加者の国籍の多様さ (そして参加費用も) など、グローバルな基準に沿って運営が行われており、アジア・太平洋地域を代表するOSS/Linuxカンファレンスの一つです。

なお、昨年は Linux Kernel Summit と併設の Japan Linux Symposium 2009 という名称でイベントが開催されましたので、事実上、今年で2回目となります。

プログラムの構成は、Linuxカーネルを中心に、組み込み (これはお国柄ですね、韓国や台湾のメーカーの方も参加していたようです) 、仮想化、トレースといったテーマのセッションが数多く設定され、我らがPostgreSQLも、初日の一部屋を占有しての発表が行われました。

PostgreSQL Reloaded (Josh Berkus, PG Experts)

初日、最初のPostgreSQLのセッションは、Josh Berkus 氏によるデモンストレーションを交えた v9.0 の新機能紹介。LinuxConでの発表という事もあり、内容はPostgreSQLに対して特別な前提知識を持たない人向けに v9.0 を概観する形となっていました。なお、今回のセッションは、v9.0へのリリース後、最初のカンファレンスでの発表という事です。

数多くの新機能が盛り込まれた v9.0 の中でも、まずは目玉機能であるビルトインの (標準の) 非同期レプリケーションについて紹介が行われました。これは、マスター側サーバで生成したWALログ (更新ログ) をスレーブ側サーバに転送し、これらに対して読み出し専用クエリの実行を可能にするものです。この機能によって、読み出し専用クエリの負荷分散が可能になるのと同時に、Hot-Standby機能と組み合わせて利用する事によって高い可用性を実現する事ができます。気になるパフォーマンスの方ですが、レプリケーション構成を取った場合でもパフォーマンスの劣化は10%程度に抑えられているとの事 (全てのクエリをマスター側で処理した場合) 。実際には、読み出し専用クエリだけを必要とするトランザクションもあるので、負荷分散による性能向上の伸びしろは大きそうだなという印象を受けました。

また、その他にも、デモンストレーションを交えて、v9.0での新機能である DO 構文 (関数を定義する事なくスクリプト言語による一連の手続きを実行する) や、EXPLAIN 構文の出力を機械的に処理しやすくする XML 形式での出力、特定スキーマ内のDBオブジェクトに対して一度にパーミッションを設定する、といった動作を実際に壇上でのオペレーションを行いながら紹介していました。

最後に、次期バージョンである v9.1 の開発にも言及し、新しいコミッタとして Robert Haas と 板垣さんが加わった事、藤井さんの開発する同期レプリケーション機能や、私の開発する SE-PostgreSQL 機能の開発が続いている事などを取り上げて、日本からの貢献の度合いが大きなOSSプロジェクトであるという事のPRも忘れていませんでした。

SE-PostgreSQL - System-Wide Consistency of Access Control (KaiGai Kohei, NEC)

続いて、私の発表です。大まかに、前半は背景となる考え方 (アクセス制御における一貫性) を、後半はそのセキュリティモデルを実現するために必要な技術要素とその現状を説明しました。

モデル論に関しては、既に多くの場所で説明している事を再度。 即ち、我々が本当にコントロールする必要があるのは、データベースであれファイルシステムであれ、そこに格納されている情報資産であって、例えば同じ機密情報への参照が、その格納手段によって違う結果となってしまうのは望ましくない。そのため、OSやDBを一元的にコントロールする Security-Server (= SELinux) に意思決定を委ね、その結果に基づいてアクセス制御を行うべきであるとする考え方です。

実装方法については、5月のPGCon (オタワ) で大まかな方向性については主要開発者と合意しており、外部の Security-Server (これはSELinuxとは限らない。例えばSolaris-TXなども候補) をサポートするために、モジュールを使って実装する事。また、本体側にもSE-PostgreSQL機能を実装するために必要な要素機能を追加する事になっています。 ここでは、SE-PostgreSQL機能を実装するためにどんな機能が必要で、現在、どのような開発を行っているのかを紹介しました。

認証フック
DB認証のあと、libselinuxの提供する getpeercon(3) というAPIを用いて、接続元プロセスの権限を取得します。そのためには、DB認証の成功時にモジュールを呼び出すフックが必要です。
セキュリティラベル
DBオブジェクトをSELinuxが識別するために、ラベルと呼ばれる短いテキスト形式の識別子を個々のオブジェクトに関連付ける機能が必要です。v9.1では SECURITY LABEL という新しい構文が追加になり、テーブルやスキーマなどに関連付ける事ができるようになります。
セキュリティフック
最も重要なのが、アクセス制御が必要な個所でセキュリティモジュールを呼び出すためのフックです。 現時点では、SELECTやUPDATEなどDML構文の実行時や、SECURITY LABEL構文の実行時など、極めて限定的にしかフックが入っていませんので、v9.1や以降のバージョンでこれを拡充していく必要があります。

現在、すでにv9.1に向けたCommitFestが2回終了し、v9.1ではSE-PostgreSQLを限定的にサポートできる見込みとなっています。

Road to a Cosmopolitan Database System: The History of Internationalization of PostgreSQL (Ishii Tastuo, SAR OSS)

お昼を挟んで、次は石井さんの発表です。 PostgreSQLの発展の歴史 (v6.0の頃から!) と、マルチバイト対応の強化を振り返るというものでした。

やはりというか、最も苦労したのがASCII圏で暮らす開発者にマルチバイト対応や文字コード変換の必要性を納得してもらう事で、その際に注意したのが「世界中の言語 (文字コード) に対して中立」であり、全ての人が利益を享受するような解決策である事だったというのは、自分のセキュリティ機能の開発の経緯を振り返ってみても「なるほどなぁ」と共感。

技術的特徴として、PostgreSQLはデータベース毎の内部エンコーディングを持っており、例えばUnicodeのような、特定の内部エンコーディングは使用しません。これは、

  1. コード変換による性能上のロスを避ける
  2. Unicode で表現できない文字が存在する

という理由によるそうです。PostgreSQLでは、これを実現するためにConversionと呼ばれる、特定の X⇔Y を変換するモジュールを提供する事で、サーバ/クライアント間でエンコーディングが異なる場合の相互変換を実現しているとの事。

結局、これらの機能が現在のような形で統合されたのが、v6.3で最初のマルチバイト対応が統合されてから5年後の v7.3 のリリース時とのお話。いやはや、まず必要性を理解してもらう所から始まって、大変なお仕事です。

pg_statsinfo: Advanced Monitoring tool for PostgreSQL (Kasahara Tatsuhito, NTT)

続いて、笠原さんから pg_statsinfo の発表がありました。 pg_statsinfo は、NTTが開発しOSSとして公開している PostgreSQL の状態監視ソフトウェアで、ロック/トランザクション待ち時間や、挿入/更新/削除をはじめとする統計情報の採取、ログの振り分け、特定のイベント発生時にハンドラを起動するといった機能を持ちます。

pg_statsinfoは、監視対象のPostgreSQLサーバにモジュールとしてインストールされ、バックグラウンドで動作するサーバ監視デーモンを起動します。このプロセスが、統計情報スナップショットを採取して、これを別のリポジトリDBに記録します。サーバ監視デーモンの起動/停止は、PostgreSQLの起動するタイミングで行われるため、特別な手順の変更は必要ないとの事。 筆者は丁度、PostgreSQL向けモジュールからLinuxカーネルの状態を非同期的に取得する機能をどのように実現しようか悩んでいたところだったので、セッションの本題とは別に「こんなことができるのか!」と驚いてしまいました。

こうして採取され、リポジトリDBに集約されたPostgreSQLの統計情報は、後で加工してレポートにまとめたり、いざ障害や性能低下が発生した時に当時の状況を知るために利用することができます。その他、リポジトリDB側では一日あたり200MB程度のディスクを消費するため、必要のなくなったデータは適宜開放してやる必要があるなど、開発者ならではの細々とした注意事項なども説明がありました。

笠原さんは、このセッション以外にも Tracing End User Discussion にパネリストとして参加されていたようです。残念ながら、筆者はこちらには出席することができませんでした。

Built-In Replication in PostgreSQL (Fujii Masao, NTT)

初日最後の発表は、藤井さんから。v9.0の目玉機能として取り込まれたビルトインのレプリケーション機能の紹介。概要は Josh Berkus のセッションでも触れられていたものの、開発者ならでは、もう少し細かい部分を掘り下げるという形になっていました。

歴史的には、PostgreSQLには20個くらいのレプリケーションミドルウェアが乱立しており、"標準" のレプリケーション (つまり、それの使い方さえ覚えれば後々間違いの無いモノ) は長らく待ち望まれた機能だという背景があったとの説明。 今回のレプリケーション機能は、WAL (更新ログ) をマスタ→スレーブに転送し、受け取ったWALをスレーブ側のデータベースクラスタに反映します。そのため、スレーブ側では読み出しのみのクエリは実行できるが、DBへの書き込みを伴うクエリは依然としてマスターサーバ側で処理する必要があります。そのため、アプリケーション側や、コネクションプールが意識してクエリを振り分けないと、負荷分散をする事ができません。また、Hot-Standby機能との組み合わせによって、マスタ側の障害発生時には直ちにスレーブ側が新しいマスタとして機能するために、負荷分散と耐障害性の向上に効果があります。

一方、現在の実装における制限事項にもいくつか言及がありました。 WALを用いるという技術的選択により、レプリケーションの粒度はDBクラスタ全体のみに制約されます。また、データベースの更新がWALに落ちている時点で、既にバイナリデータの塊であるので、OSのアーキテクチャやPostgreSQLのメジャーバージョン (共通のメジャーバージョン間ではデータ形式は共通なので) はクラスター内で一致している必要があります。システム構成としては、マスタ側から複数台のスレーブにWALを飛ばす事はできるが、スレーブからさらに別のスレーブにWALを飛ばすといったカスケード構成を取る事はできないとの事。

藤井さんは元々、PGCon 2008で発表した同期レプリケーション (更新が直ちに他のノードにも反映され、commitは決して失われないが遅い; 非同期だとWAL送出前にマスタがクラッシュするとcommitが失われる) を開発しており、次の v9.1 に向けて同期レプリケーション機能を開発中との事です。

Window Functions in PostgreSQL (Hitoshi Harada, FORCIA)

一日あたり発表枠の関係で、原田さんによるWindow関数の紹介は3日目のセッションでの発表となりました。 同じ時間帯に、Jens Axboe氏の「SSD Impact on Linux IO Stack」という発表があり、そちらに多くの聴衆が流れたため、比較的落ち着いた雰囲気でセッションを聞くことができました。

v8.4で統合されたWindow関数とは、SQL2003準拠の機能で、主要な商用DBでは対応が行われているものの、OSS-DBではPostgreSQLのみが対応しています。 これを使うことで、文字通り窓から覗くように、SQLによる検索結果のうち特定の範囲を参照してそれを同じクエリの結果セットに含めることができます。例えば、10行から成る結果セットで、ある行の値とその前後の値から平均値を計算して1回のクエリで値を返却することができたりします。

v8.4では基本的な機能 (行の通し番号など) が提供されましたが、v9.0では移動平均を求めたりできるように拡張が行われました。 今回のセッションでは、例えば、Window関数の性質上ソート処理を挟む事になる場合が非常に多くなるので、2個以上のWindow関数を含む場合には明示的に ORDER BY を付加する事で、余分なソート処理を省略 (最適化) できるなど、開発者ならではのアドバイスがありました。 この辺のテクニックは、知っておいて絶対に損は無いものばかりです。別の機会にどこかで再演を期待したいところです。

おわりに

今回の LinuxCon Japan 2010 / Tokyo では、Linuxカーネルを中心にして、数多くの日本人の発表がありました。Linuxカーネル対する日本発のコントリビューションがそれだけ増えてきているという事の傍証でもあるのですが、それにも増して、PostgreSQLではv9.0での藤井さん開発による Streaming Replication など、ど真ん中の中核機能が日本発のコントリビューションによって支えられているという事を改めて認識させられました。

今回は、Linuxカーネルの土俵でPostgreSQLの発表を行ったわけですが、こういった機会を通じて、互いにOSSコミュニティ同士の交流・連携がより深まっていけばと思います。


関連リンク


(2010年11月29日 公開)

 

You are here: Home 読み物 イベントレポート LinuxCon Japan 2010/Tokyo