Personal tools

PostgreSQL 事例紹介セミナー2008に行ってきました

有限会社 第四企画 坂井 潔


PostgreSQL 事例セミナー 2008 風景
Creative Commons License

2008年11月28日(金)、この日の天気予報は「雨のち晴れ」。午前10時25分からのスタートです。東京メトロ銀座線の神宮前駅から会場まではちょっと歩くので降られるのはやだなと思っていましたが、なんとか持ちこたえてくれました。

会場は渋谷区神宮前にある、サン・マイクロシステムズのオフィスです。おしゃれなお店が建ち並ぶキラー通りの一角にあります。「月星ビルの交差点」のすぐ近くと言えばわかる方もいらっしゃるのではないでしょうか。


ニューヨーク証券取引所などの「超」大規模事例

サン・マイクロシステムズ 中村 完さん

一つ目の事例紹介は 「大規模事例のご紹介 - PostgreSQL ベースのデータウェアハウス事例 -」。今回のイベントの会場の提供元でもある、サン・マイクロシステムズ株式会社のシステムエンジニア、中村 完さんにしていただきました。本人は緊張してるとはおっしゃってましたが、どう見ても堂々としていらっしゃいました。

本題の導入事例です が、まずはニューヨークの Euronext という証券取引所! 筆者の実生活にはぜんぜん関わってくれないのでうまく想像できませんが、とても大きそうなシステムです。PostgreSQL もこんなミッションクリティカルな場所に使われるようになったんだなぁと、しみじみと感じ入ってしまいました。

「SunDW アプライアンス」

サン・マイクロシステムズと米 Greenplum 社が一緒になって、「SunDW」アプライアンスというプラットフォームを作りました。これは、Sun の Fire X4500 などのハードウェアと Greenplum の DB をセットにしたもので、それを、この冒頭の証券取引所を筆頭に、一日あたり10億のテキストメッセージが行き交う「フィリピン・ロング・ディスタンス・テレフォン」、インド国内で最も成長率速度の速い無線通信事業を行う「リライアンス・コミュニケーションズ」などといった所に導入しているようです。 Greenplum DB は、PostgreSQL をベースに作られているので、基本的に安価。そしてハードウェアもこなれたものなので、これも割と安価。これで「SunDW」アプライアンスは、導入などの初期コストをぐっと押さえられたそうです。

シェアード ナッシング アーキテクチャ

シェアードエブリシングはデータを1箇所(に見えるよう)に共有化された状態でおき、そこを1つ以上の DB 処理(インスタンス/ノード)が利用するという構造です。このアーキテクチャは OLTP 用途には向いているのですが、ストレージアクセスが1箇所に集中してしまうため、レコードの全件検索が頻繁に行われるデータ解析処理には不向きとされていました。この課題を解決するため「SunDW アプライアンス」ではシェアードナッシングアーキテクチャを採用しています。シェアードナッシングアーキテクチャは、データ(レコード)を複数サーバに分けておき、それぞれのサーバでインスタンスが平行して処理を行うことで、高速化や高可用性を実現した分散処理です。CREATE TABLE 時にどのカラムでどう分けるか指定するんだそうです。

TSUBAME にも使われてる Sun Fire X4500

Sun Fire X4500 は、最大 1TB のディスクを 48 台、つまり 48TB の容量を搭載でき、それを4U(高さ18cmほど)のサイズに収めている、内容は巨大ですが非常に高密度なハードウェアです。最近話題になっている東工大のスパコン TSUBAME にも使われています。いやすごいですね。Solaris の ZFS というファイルシステムを使って、例えば 20TB というレベルのバックアップさえも瞬時にとれるんだそうです。バックアップ時はそのスナップショットを取るだけなので、瞬時に終わり、それ以降はその差分を順次とっておくと、その積み重ねでバックアップ時点の状態まで簡単に戻れるんだそうです。こんなこと、よく考えられるなぁと思いました。

SunDW のデモ

このシステムで2台のサーバにストレージ(セグメントと言うんでしょうか?)を分けたときに、1台と2台でそのくらいの差が出るか、実機でデモっていただけました。あ、勿論、それとは別にそれぞれのサーバに命令を発効する「マスタ」のサーバは1台あります。公正を期すためにまずキャッシュをクリアします。

最初はセグメント1台+マスタ1台の構成のデモです。検索中、当たり前ですがマスタのインスタンスには全然負荷がかかりません。1台のセグメントの方だけ負荷がかかります。がっつり GROUP BY してるので、話者の中村さんがちょっと時間を持て余すくらい時間がかかりました。結果は「1:46.137」約106秒でした。

次にセグメント2台とマスタ1台です。このときは当然セグメント2台とも CPU の稼働率はマックスまで振り切ります。結果は「52.800」約53秒。端数はありますが、1台構成に比べてしっかり半分になっていました。これほど正確な例は実際にはあまり無いでしょうが、とても分かり易い例でした。

でもこれだけ大きなアプライアンスを導入する必要があるのは、とても大きなシステムなんでしょうね…。このようなシステムで PostgreSQL がベースに使われているのはうれしいことですね。ちなみに、中村 完さん(kan.nakamura@sun.com)、もしくはお問い合わせ先アドレス(sundw-jpn@sun.com)まで連絡すれば、より詳しくお話を聞けるとのことです。


携帯 CGM サイト「フォレストページ」

ビジュアルワークス 落水 恒一郎さん

「フォレストページ」という携帯 CGM サイトでの PostgreSQL 導入事例です。このサイトを運営している、株式会社ビジュアルワークスの落水 恒一郎さんにお話ししてもらいました。

多感な10代の女子学生がターゲットに

ビジュアルワークスはモバイルコミュニティのサイトを製作/運営する会社で、携帯を中心にした広告ビジネスなどを展開しています。今回の事例であるフォレストページは、ページ数が約180万、月間 PV を25億持つ巨大な携帯コミュニティーで、10代の女の子が中心にページを持っているそうです。落水さんによると彼女らは「一日6~8時間携帯と向き合ってる」んだそうです。うーん、かなり長い気がしますが、もしかすると大人たちはもっと長い時間 PC に向き合っているような…。まあ彼女たちがずーっと携帯に向かっているのは、無理もないのかもしれませんね。

急成長したサービスに課されるもの

立ち上げ当時は、これほどまでに成長するとは想像していなかった「フォレストページ」も順調に大きくなって、最近ではウェブサーバは数十台、DB サイズも 200Gくらいになってしまったそうです。携帯の世界は競争が激しいため、新機能を常に追加していくことが不可欠なのですが、単に機能をそのまま増やして いくと、当然 DB 的には性能劣化が進み、サーバが重い状態が続くような事態が発生するようになりました…。

Slony-I と pgpool-II の組み合わせによる負荷分散

と りあえずはそれまで使用していた PostreSQL 8.1.x を、高速化が評判の 8.3.x に一気にアップグレードしました。パフォーマンスは良くなったそうですが、それでもサイトが快適になるというレベルまでにはならなかったそうです。その 後、Slony-I を導入し、pgpool-II と組み合わせることで可用性の確保とレスポンス改善を図りました。ただ DB サイズが大きく、また過去に実施された
例も無かったため、同期遅延やレプリケーションによる性能劣化がどの程度のものか、正直怖さもあったそうです。なお、Slony-I 上の運用では Primary Key が必須だったり、そもそも非同期の
状態である事や、障害時の復旧の難しさなど、運用にあたっては検討する事項も多くあるようです。

携帯の世界のように要求されるものの変化が非常に早いところでは、長い展望というよりは、いかに今あるニーズに応えていくことが重要なんでしょうね。そうした場合には、SQL の見直しというよりは、ハードウェアの増強や Slony-I の導入による負荷分散など、直接は仕様に影響してこない部分を強化していくことが大事なのかもしれませんね。


医療現場での膨大な量の画像ファイルを管理する

日立メディコ 鈴木 雅登さん

株式会社日立メディコは、ウェブ業界から見るとかなり歴史のある古い会社で、設立が昭和24年! これは西暦だと1949年だから戦後直後ってことでしょうか? あの日立グループの持ってる技術を医療系の装置として作り、売る会社です。その会社の、メディカル IT 事業部 システム本部 開発部 画像グループ(長いですね^^;)の鈴木雅登さんが講師です。

PET/CTという一種のCTスキャナを使うと、どんな小さな癌でも見つかると巷では言われてるそうですが、販売する側の鈴木さんは「それは言い過ぎです」っておっしゃってました。

医療システムで主に扱うのは画像データ

医療系のデータは、とにかく画像データが膨大で、たとえば CT1回で1患者あたり1000枚以上は撮影するのだそうです。その上、これらの画像をすぐに登録/表示できないと、検査を依頼した先生からクレームが来 るんだとか。まあシステムとしてはとても大変でしょうが、患者や先生の立場から考えるとそれは早く処理しないといけないって気もしますね。

「DICOM規格」と「PACS」

そんなデータを、病院のネットワークで使う時の国際規格を「DICOM規格」といい、この規格に則ることで、海外での医療データと日本の病院でもインポート/エクスポートしたりするが可能になるんだそうです。CD-R などにデータを焼くときのフォーマットなども、この規格内で決まっています。データに依ってはDICOM規格といいながら、あまり合っていないデータもあるらしく、それをインポートできるように工夫するのが苦労だったとおっしゃっていました。

こ の医療用画像データをネットワークで管理する、画像保存通信システム(Picture Archiving and Communication Systems)、通称「PACS」を日立メディコでは製作/販売しています。このシステムを作るときに、先生方からの要件として「目が疲れない」「マウ ス操作 が簡単である」などがあったんだそうです。この辺りを突き詰めて作っていったら、日立メディコの「OPEN PACS シリーズNV-1000/ Natural Report」は、2007年 Good Design Award を受賞するほどになりました。すばらしいですね。

DICOM規格をより効率的にした「Enhanced DICOM」という規格もあるようです。まだあまり普及はしていないようですが、データ効率や処理速度的にはずっとアドバンテージがあるとのことです。もっと広く普及するといいですね。

PostgreSQL で3億を超える画像ファイルを管理する

このシステムでは、画像そのものは当然 DB には入れず、通常のファイルとしてあつかっています。その画像それぞれに患者情報、撮影情報、検査情報、画像情報があるので、PostgreSQL はそれらの情報を管理する部分に使用されています。ただ、周辺のいろいろな装置が高性能化してくると、画像の発生量は大幅に増加してきています。これは、 画像のサイズが大きくなっているんではなく、枚数の方が増えてきているんだそうです。2008年でもこの画像のテーブルは、3億レコードっていう膨大な データ量になってしまうんだそうです。ちなみに DB をダンプすると、1GB くらいのサイズになるそうです。

巨大テーブルへの VACUUM とテーブルロック

病院に行くと何となく判りますが、画像発生量(≒システム負荷)は午前中が多いそうです。10、11時辺りがピークなので、この時間帯の処理を考慮すると、 複数DBサーバで分散システムを構築し、冗長化構造にしないと負荷に耐えられないそうです。冗長化構成にすると、そのロジック上でテーブルロックを行う箇 所があり、画像情報のような巨大なテーブルに対する長時間の VACUUM とは、どうしても共存できなかったそうです。PostgreSQL としてはちょっと特別な使い方になりますが、ロック専用の小さなテーブルを作り、それを変更/参照することでなんとか回避したそうです。もしかするとこの 辺りの問題も、今後の PostgreSQL のアップグレードで解決される日が来るかもしれませんね。


口コミサイト「とっとくねっト」で PostgreSQL の機能をフル活用する

オールクリエイター 橋本 俊秀さん

オールクリエイター株式会社の橋本俊秀さんに口コミサイト「とっとくねっト」で PostgreSQL を使って来た経緯をお話ししていただきました。

「とっとくねっト」の立ち上げ

橋本さんはこのサイトを立ち上げる前に、別のお仕事で商用 DB と PostgreSQL を比較しなくちゃならないことがあったそうです。あくまで商用 DB に決めるための比較だったのですが、そのときから「自分で使うなら PostgreSQL も悪くない」って思っていらしたそうです。このサイトの開発を始めた2003年、購入したPerl/CGI本に Pgモジュールの使い方が手厚く載っていたことも後押しし、PostgreSQL を使うことに決めたのだそうです。当初は RedHat 、Perl5 で開発をしていましたが、その後は Vine、PHP に変更になりました。でも、PostgreSQL は浮気をせずそのまま使い続けてきたとのこと。うれしいですね。3年前には大手携帯キャリア3社に対応し、現在では会員2万人以上のサイトへと成長しました。

カーソルは使わない/システムカタログは見ないように

それほど昔から DB を使っていない方には「カーソルを使う」って概念自体が無いのかもしれません。メインフレームや古いサーバなどで RDB を使い複数レコードを取得するときには、カーソル宣言してレコードをひとつずつ FETCH して来るって言うのが常套手段だったような気がします。ただ、現在では件数が多いテーブルでこれをやるとオーバーヘッドが大きくなってしまうので、カーソ ル関数は使わない方向になったそうです。また、テーブル名が pg_ で始まる PostgreSQL のDBMS が使用するテーブル群をシステムカタログと言いますが、PostgreSQL バージョンが 7.x.x の頃には、オフィシャルな文献にもこのシステムカタログを直接参照してコードを書いてある箇所もありました。バージョン 8.x.x 以降になると、システムカタログの参照はあまり推奨されないので、「とっとくねっト」では見ないように変更していったそうです。

JOIN する対象は 4000件以内に

JOIN 自体はとても効果的だったのですが、その対象のレコードが 4000 件以上あると負荷が高くなってしまうので、JOIN する前になるべく件数がそれ以内になるよう WHERE 句などで絞り込んでからにすると良いんだそうです。

EXPLAIN ANALYZE によるコスト意識

JOIN などを活用し、なるべく1回の SQL で複雑だけど大きな処理を発行するときには EXPLAIN ANALYZE でどの辺りにコスト(=時間)がかかっているかをチェックする様にしたそうです。特に遅いマシンで EXPLAIN ANALYZE を使ってテストしある程度満足できる早さになった後に、それをちゃんとしたマシンの本番環境に持っていけばほぼ問題なく動作するそうです。

質疑応答では開発を担当された藤原りかさんが登場

オールクリエイター 藤原 りかさん

Q: JOINの処理で遅くなるところがあると言ってましたが、重くなるときは、JOINするテーブル数が多かったのですか、それともデータ量が多かったのですか?

A: 4000件のレコードを持つ、10個に満たないテーブルでも、何も考えす単純に JOIN するととても遅いです。でも JOIN を適切に書き換え、正しい INDEX をはると、比較にならないくらい早くなります。


自治体ビジネス、そして「トキめき新潟大会」で PostgreSQL を使う

BSN アイネット 白柏 雅資さん株式会社 BSN アイネットの白柏 雅資さんにお話していただきました。他の講師の方よりベテランな感じの白柏さんでした。

BSN アイネットではまずは自社システム、去年からはIPA(情報処理推進機構)の自治体オープンソース導入実証事業として、そして今年は新潟国体と併催される障害者スポーツの祭典「トキめき新潟大会」の競技運営支援システムで PostgreSQL を採用してきました。新潟県の鳥、トキをモチーフにした愛らしいキャラクター「とっぴー」と「きっぴー」、合わせて「トッキッキ」が「トキめき新潟国体・トキめき新潟大会」のマスコットになっています。

メインフレーム(汎用機)との統合データベース

BSN アイネットのユーザーである某A市では、元々大型汎用機によるレガシーシ ステムが運用されていました。後にさまざまな個別業務システムが作られたのですが、汎用システムと個別業務システムでは当然、別々のデータベースを使って いるので、定期的なバッチ処理によって同期させていたそうです。メインフレームが進歩の阻害になっている部分もあったのですが、巨額の投資で得たメインフ レームを簡単に捨てるわけにはいかなかったそうです。なので、それらを連係させるための「統合データベース (現在のシステムではOracle)」を構築することで、個別システムがリアルタイムで情報を得られるようにしたそうです。このことで、某A市の基幹業務 が動作するメインフレームと個別に職員さんが使う行政システムが疎結合され、欲しい情報が一元管理された24時間365日利用できるサー ビスが可能になったんだそうです。

ちなみにですが、白柏さんの 資料には、政府関連のものになると「G to G」「G to B」「G to C」という言葉が出てきました。よく「B to B」とか「B to C」という言葉は聞きますが、この「G」は「Government」のことなのでしょうね。筆者には聞きなれない、新しい言葉だったので一瞬悩んでしまいました…。

OSSでベンダロックインを排除

自 治体情報システムといえども(当然ですが)コスト意識や、サービスレベルの向上は必要です。特にコスト削減のためには、ベンダロックイン(=特定のメー カーや販売会社による自社製品での囲い込み)は避けるようにしなければ、公正な自由市場原理が働く環境にはなりません。このような流れの中で、地方自治体 と民間企業や一般市民のシステムを連携させるための仕組みである「地域情報プラットフォーム」という考えかたが出てきました。「地域情報プラットフォー ム」の考え方とそのサービスの一つである「統合データベース」にそった仕組みについては、既に存在しておりますが、Windows・Unix・Linux が混合し、Weblogic、Oracle といった商用の製品群により構成されています。それらを、Linux、JBoss、そしてPostgreSQL といったオープンソースに置き換えていくことで、ベンダロックインの排除や必要なデータの有機的な連携を可能にし、運用負担やコストの削減を広く検討でき るのではないか…という仮説が生まれてきました。

PostgreSQL と pgpool-HA での実証

これを実証するために、 障害対応の選択肢が豊富で、企業買収の影響を受けにくく、新潟におけるコミュニティもあるので協力を受けやすい PostgreSQL が選定されました。検証の結果においても、商用のものと比較して、処理レスポンスなどは十分な評価が得られたそうで、筆者もほっとしました。

とはいえ、まだまだ全国自治体からの評価において、OSS導入に関して「ベンダから十分なサポートが受けられないのではないか」「自治体業務に必要なアプリ ケーションが少ない」「担当職員にOSSの十分な知識がない」などの意見が多数あり、課題が残っていることも確かなようです。「地域情報プラットフォー ム」「統合データベース」がフルオープンソース化されれば、その後に追加されるアプリケーションやウェブ上のソフトウェアもきっと作りやすくなるだろうな と思いました。

トキめき新潟大会 競技運営支援システム

BSN アイネットでは、新潟国体に併せて行われる、全国の障害者スポーツの祭典「トキめき新潟大会」の競技運営支援システムに Ruby、PostgreSQL といったオープンソースを採用しました。参加する選手(団)情報、競技プログラム情報、リザルト情報などをネットを通して管理するのが PostgreSQL です。このシステムはBSN アイネットが中心になり、新潟市内のネトニー・ウイングの2社と共同受注し、一緒になってマネジメント・開発しているものだそうですが、今後は次の開催県がこのシステムを持ち回りで使ってもらえることを期待しているそうです。


「住友電気工業株式会社におけるオープンソースソフトウェアの積極的な導入」

住友電気工業 中塚 康介さん住友電気工業株式会社 情報システム部の中塚 康介さんにお話いただきました。住友電工は、とても長い歴史を持つ会社です。日立メディコさんも結構古いと思いましたが、住友電気工業株式会社は、1897年、明治30年の創業! いろいろなケーブルとかコネクタなどの部品、プリント回路などを作っていらっしゃいます。

PostgreSQL が標準データベース

こ の歴史ある住友電工のなかで、実際にシステム企画をする情報システム部です。住友電工情報システム株式会社と一緒に、自社および他社に導入するシステムを 提供しています。現在ではそのほとんどが Linux(+ Xen)ベースとなり、2005年からは PostgreSQL が標準DBとして採用され、開発サーバには自動的にインストールされます。PostgreSQL 以外の DB は個別に申請/承認されないと利用できないそうです。ちなみに住友電工と PostgreSQL との関係は深く、バージョン 8.4 の目玉になるであろう「再帰SQL」の開発でリソースを提供したのが住友電工の関係会社である住友電工情報システム株式会社でもあります。

DB を高速に動作をさせるには正規化が重要

正規化されていない DB に対して JOIN を使った SQL を発行すると、処理がとても遅くなってしまいます。そのため、正規化するともっと遅くなってしまうのではないかという誤解があるようですが、実際にはちゃんと正規化し、正しく INDEX をはったテーブルに対して JOIN をすると、かなり速く動作するのだそうです。

質疑応答が白熱しました

Q: Xen を使用して複数の仮想化の中でPostgreSQLに作業をさせるよりも、1つの方が効率が良いんじゃないでしょうか?

A: 障害の対策用などには複数の方が都合がよいときがあります。あるシステムとあるシステムを一つの環境に同居させたくないときとかも有効です。


Q: サーバを実際に壊してみて、復旧の作業をしてみるそうですが、どんな壊し方をするんでしょうか? 電源を引っこ抜いちゃうとか?

A: このセミナー(住友電工では自社研修としてリカバリのセミナーをするそうです)では、ファイルを損傷される、ディスクあふれをおこす、などをシミュレートしました。ただ、電源を引っこ抜くってのはやってないです。


Q: 経理や実際のビジネスを PostgreSQL 支えているのは理解しました。住友電工さんの工場では何を使っているのでしょう?

A: 工場のシステムでも PostgreSQL は使用しています。


Q: 工場ではおそらく 24時間稼働させているのですよね? どうしていますか?

A: 製造は確かに365日、24時間稼働させなくてはならないの大変です。全国のサーバを1箇所にまとめて、だいたい700台くらいの台数で運用しています。


Q: 社内の開発では人員が増えるに従って、ノウハウの蓄積や、情報の共有が必要ですが、どのように実現していますか?

A: 社内では文書などが供給できるように独自のポータルを構築しています。ここには誰でも書類をおけ、閲覧できるようになっています。


最後に

PostgreSQL 事例紹介セミナー 2008

この日、見てきた事例のように、かなり大規模でミッションクリティカルな領域にも PostgreSQL、あるいは PostgreSQL ベースのデータベースが採用されつつあるのには、とても感慨深いものがありました。

それとちょっと驚いたのは、PostgreSQL のバージョンがそれほどまでは最新でないものを皆さんが使っていることでした。確かに、実際に稼動しているシステムのメージャーバージョンをあげるのは、なかなか厳しいのでしょうね。筆者がプログラミングをしているシステムでも結構古いバージョンのものも多いですし…。

ただバージョン 8.3 では、新機能「HOT」を用いて画期的に処理速度が向上しているようなので、ぜひ最新のものを使っていきたいですね。バージョン 8.4 では再帰 SQL も実装されるそうなので、今からとても楽しみですね。

PostgreSQL ユーザ会の本家のページには、今回のセミナーの講演資料やアンケートの集計結果もアップされています。

坂井 潔

写真提供: 小山 哲志

 

You are here: Home 読み物 イベントレポート PostgreSQL 事例紹介セミナー2008