本レポートでは、その様子をご報告します。

■ PostgreSQL 9.5 はいつリリースされるのか？

最初のセッションは、マーケティング部 PostgreSQL技術グループ グループ長の高塚遥による、「次期メジャーバージョン PostgreSQL 9.5 の実力 徹底検証報告」です。

まず、PostgreSQL の開発体制について簡単に紹介させていただきました。
PostgreSQLは、特定のベンダーが開発しているのではなく、コミュニティ主体での開発を行っています。
したがって、万が一どこかの会社が開発を継続できなくなったとしても、PostgreSQL全体としては開発を続けられるため、より安定している、と言えるでしょう。

次に、PostgreSQL 9.5の開発状況とリリース時期についてお話しました。
こちらは、セミナー開催時点では、残念ながら確定していませんが、これまでの実績を踏まえた見通しとしては、2015年末か、2016年の初めのあたりになるのではと考えています。

■ PostgreSQL 9.5の新機能

PostgreSQL 9.5の新機能の中から、７つの機能をピックアップしてご紹介しました。
行単位のセキュリティ、BRINインデックス、トランザクションの巻き戻しをするpg_rewindコマンド、「挿入または更新」という処理に対応した機能、外部テーブルのIMPORTや継承、集計構文の追加、JSONB型向けの関数や演算子の拡充、の７つです。
ここでは詳細を割愛しますが、詳細は、講演資料をご覧ください。
また、11月中に、PostgreSQL 9.5 検証レポートも公開する予定ですので、公開したら、そちらも参考にしていただければと思います。

会場からの質問も活発に行われ、「行単位のセキュリティについて、1つのテーブルに対してポリシーを設定した場合、複数のテーブルを結合した時にも、ポリシーは適用できるのか？」といった質問などがありました。

■ 透過的データ暗号化（TDE)が可能な、PowerGres Plus

次のセッションは、マーケティング部 PostgreSQL技術グループ 松坂による、PowerGres Plus のご紹介です。
PowerGres は、SRA OSS が PostgreSQL をベースに商用のデータベースという形で2003年から販売しており、10年以上の実績がある製品です。
その中でも、「PowerGres Plus」は、「Plus」とあるとおり PostgreSQL にはない機能を付与した製品となっています。

PowerGres Plus の特徴的な機能は、透過的データ暗号化（TDE）です。
暗号化・復号は自動的に行われ、アプリケーションの修正も必要ないので、すでに構築済みのデータベースにも適用しやすいです。
さらに、暗号化によるオーバーヘッドがほとんど無いということも大きなポイントです。
PostgreSQLで暗号化ができるソリューションはほかにもありますが、PowerGres Plus は、「性能への影響がほとんどない（オーバーヘッドが極小）」であることと、最も強固な暗号化方式の一つと言われる AES256 に対応していることです。
また、Oracle Databaseとの比較について質問されることが多いため、OracleのAdvanced Securityとの機能比較についてもご紹介しました。
一部の機能には対応していませんが、必要十分な機能を備えていると考えており、コストパフォーマンスを考えると、要件に合えば最善の選択となりうると考えています。
昨今、「マイナンバー」が話題になっていますが、これに伴い、データベースの暗号化の要件も増えていると感じており、PowerGres Plusも、既にマイナンバー関連のシステムで採用されています。

■ pgpool-IIの基本機能と最新情報

次のセッションは、「pgpool-II 最新バージョン 3.5 のご紹介」です。
こちらは、マーケティング部OSS技術グループ所属で、pgpool-IIの開発者である、長田からお話しをさせていただきました。

pgpool-IIは、PostgreSQLのクラスタ管を管理・活用するためのミドルウェアで、「PgPool Global Development Group」というコミュニティで開発をしているオープンソースのソフトウェアです。
オープンソースのライセンスは、BSDライセンスです。
SRA OSS のメンバーが、リーダーおよび開発者としてプロジェクトに参加しています。

pgpool-IIの1つの特徴として、「アプリケーション側からは1台のPostgreSQLのように見える」という点があります。
つまり、PostgreSQLを使っているアプリケーションは、そのアプリケーションを修正する必要はなく、pgpool-IIを利用できます。
機能は、性能向上のための「コネクションプーリング」や、「ロードバランシング」、「クエリキャッシュ」、可用性を提供するものとして、PostgreSQLの1台が故障してしまった時の、「自動フェイルオーバー」機能や、「watchdog」と呼ばれるpgpool-II自体を高可用化する機能、クラスタ管理としてダウンしたノードを回復する「オンラインリカバリ」や、pgpool-II自体が持っている「ネイティブレプリケーション」という機能があります。
また、アプリケーションから来たクエリを、複数のPostgreSQLノードに振り分けるという「クエリの自動振り分け」という機能があります。
本セッションではこれらの機能について簡単にご紹介させて頂きました。

■ pgpool-II 最新バージョン3.5のご紹介

次に、最新バージョン3.5についての紹介を行いました。
主な機能のうち、「PostgreSQL9.5対応」、「watchdog機能の改善」、「性能改善」の3つについてお話させていただきました。
性能改善については、JDBCドライバなどで利用される拡張問い合わせがTPSで約1.5倍向上させることができました。
バージョン3.5は、この冬のリリースに向けて開発中です。
pgpool-IIについても、沢山のご質問を頂きました。ありがとうございました。

■「軽技 Web for PostgreSQL / PowerGres」で有効的なデータ活用の実現

最後のセッションは、導入事例のご紹介です。
富士電機 早坂様から、『「軽技 Web for PostgreSQL / PowerGres」で有効的なデータ活用の実現』についてご紹介を頂きました。

富士電機様は、エネルギー関連事業の会社で、発電社会インフラや、UPS、半導体等々を作っている、物作りの会社です。
身近なところでは、自動販売機が日本でシェアトップとのことです。
また、セブンカフェのコーヒーメーカーも製造しています。

「軽技 Web」は、元々は、富士電機様の社内ユースから産まれたそうです。1998年、日野に東京工場の生産管理システムのリプレースをする時に、帳票の削減や、工数の削減、導入費用の削減等々を目的として生まれた、エンドユーザコンピューティングを実現するためのツールでした。
現在は、社内利用にとどまらず多くのお客様に利用いただいており、800社を超える導入事例があります。

「軽技 Web for PostgreSQL / PowerGres」は、元々OracleやSQLServerなどの商用DBに対応していたものを、PostgreSQL、PowerGresに対応しました。
対応データベースの拡充により、より「軽技 Web」が利用しやすくなるものと思います。

最後までお読みいただきありがとうございました。
今後も、PostgreSQLをはじめとしたオープンソースに関するセミナーを企画してまいりますので、是非ご興味のあるテーマがございましたら、ご参加をお待ちしております。

ここでは、当社 山本博之が行ったプレゼンテーションの内容をご紹介します。

■OSS ミドルウェアにより構成された、Hinemos で監視するシステム構成の例

この図は、弊社のサポートで扱われることの多い、システム構成のパターンになります。オープンソースのミドルウェアにより構築された Web システムです。

先ず Internet 経由でシステムがリクエストを受け付けますが、入り口で付加分散装置があり、複数の Apache HTTP Web サーバに処理が振り分けられます。その後ろにアプリケーションサーバの Tomcat、そしてデータベースサーバの PostgreSQL があります。この構成がそれぞれ複数台構成されていて、付加分散、冗長化を行っている構成になります。

サーバの台数が多くなってきますと、これらを手動で１台ずつ管理していったのでは非常にコストがかかってしまいます。そういう場合に、統合運用管理ツールの Hinemos を使うことで、運用管理コストを削減できるというメリットがあります。

■デモ環境の構成

今回、このノートPC 上に構築したデモ環境の構成を以下に示します。

Web サーバ 1台と、DB サーバ 1 台と、2 台構成の Web DB システムを Hinemos で管理をするという構成となっております。また、Hinemos マネージャが 1 台、Hinemos クライアントが 1 台あります。

■Hinemos による OSS ミドルウェアの監視

OSS の Web サーバや DB サーバを Hinemos で監視する場合の監視方法について、図に表しました。

性能監視（リソース監視）と、死活監視の 2つに分けることができます。
性能監視というのは、サーバの CPU メモリ使用量、I/O、ディクス I/O といったものの情報を取得して蓄積するということになります。
死活監視につきましては、ローレベルな監視と、サービスレベルの監視があります。
ローレベルな監視とは、プロセスが生きているかどうかの監視や、ping が返ってくるかどうかといった監視になります。
サービスレベルの監視としましては、例えば Web サーバでは、http のリクエストで正常な結果が返ってくるか、DB サーバでは、SQL を投げて正常な結果が返ってくるかということで、サービスが正常に稼働しているかどうかを監視するといった監視方法がとられます。
ここで、監視結果、性能情報といったものが、Hinemos が内部で持っているデータベースに蓄積されていきます。

■Hinemos ジョブによる日時処理

Hinemos の大きな特徴としまして、Hinemos のジョブ管理機能を使った定時処理があります。例えば、日次処理で、それぞれのサーバのバックアップや、その他の処理、複数のサーバにまたがった処理を、Hinemos では簡単に行うことができます。
また、ジョブの実行結果も Hinemos に蓄積されていきます。
Hinemos クライアントから実行結果を確認する場合は、Hinemos の監視パースペクティブを使って、各サーバの現在の状態や、監視項目ごとの現在のステータスや過去に発生したイベントの履歴といったものを見ることができます。
また、性能情報の確認につきましては、確認したい監視項目を選択しまして、それぞれ対象の監視対象と期間を指定することで、閲覧することができます。

ただ、現在 Hinemos クライアントでの監視を行った場合の問題点として、当然ながら Hinemos クライアントにログインする権限が必要となります。
また、性能情報につきましては複数の性能情報をまとめて閲覧できません。

こういった問題を解決してくれるのが、今回紹介いたします Hinemos レポーティングオプションとなります。これから、Hinemos レポーティングオプションについて説明していきたいと思います。

■Hinemos レポーティングオプション

先ほど説明してきました、監視結果や性能情報、またジョブ実行結果といった、Hinemos に蓄積された様々な情報を自動的に集計して、レポートファイルにまとめて出力するとができるのが、Hinemos レポーティングオプションの機能となります。

次に、Hinemos のレポーティングオプションの動作です。
基本的に、Hinemos レポーティングオプションは Hinemos マネージャ上で動作します。マネージャ上でレポート生成して、ユーザに通知します。
Hinemos クライアントでは、Hinemos レポーティングスケジュールの設定を行います。スケジュールの設定では、「毎日」や、「毎月」、「毎週」の何時何分にレポートを生成するという設定が可能です。設定した時間になりますと、Hinemos マネージャ上でレポートを生成して、Hinemos の通知機能を使ってユーザに配信します。配信方法としましては、メールの添付ファイルとして送信するという方法と、コマンドの引数に渡す方法があります。コマンドの内容はユーザが自由に書けますので、別のサーバに転送するなり、ユーザが自由に設定を行うことができます。また、スケジュール実行だけでなく、ユーザが今直ぐ実行結果を見たいという場合、即時出力機能で、直ぐにダウンロードすることもできます。

レポーティングオプションの特長としましては、以下のようなものがあります。

• レポートは PDF 形式で出力されます。
• メールもしくはコマンドで自動的に配信されます。
• PDF 形式で出力されますので、クライアントにログインしなくても情報を閲覧することができます。
• 集計する期間については、1日から 3ヶ月間までの期間を自由に設定することができます。
• 情報をまとめて閲覧することができますので、システム全体の状況を容易に把握、分析して、その結果をシステム運営に反映させるといったことが可能になります。

■レポートの出力結果

こちらが実際に出力されたレポートの一例になります。

これは性能情報の概要で、CPU 使用率、メモリ使用率、ディスク I/O、ネットワーク情報量、ファイルシステムの使用率について、グラフで出力させています。より詳細なデータを出力することも可能です。

次は、監視情報です。

こちらは重要度別のイベント数の期間内の割合を円グラフで表示します。また、日別のイベントの件数を棒グラフで表示しています。
さらに各イベントの詳細情報を一覧で表示します。イベントの各重要度が色分けされていますので、非常に分かりやすい形式となっております。

ここで一部拡大しておりますのが、プロセス数の監視とログ監視になります。
2行目がログの内容に、「sutting down」というのが出ているので警告を出しているということを示しています。
下の行は、プロセス数が 0 となったので、危険と判断されたということになります。

次は、ジョブ情報です。

こちらについては、ジョブセッション情報及びジョブ詳細情報、ノード詳細情報の3通りの情報が出力されます。
ジョブセッション情報というのは、ジョブの起点となるジョブ情報の一覧となります。
右側がジョブ詳細情報です。
1つのジョブユニットもしくはネット内の全てのジョブについて、実行結果がツリー形式で表示されます。
また、右側のほうが実行時間帯をそれぞれのジョブについてガントチャートで分かりやすく出力されています。
左下のノード詳細というのは、サーバ毎のジョブの実行結果一覧となります。

■まとめ

オープンソースで構築しました Web DB システムですが、昨今非常にサーバ台数も多くなって管理も困難になっております。
そこで、Hinemos を使うことで運用管理が非常に楽になります。
Hinemos による監視を行った結果、性能情報、監視情報、ジョブ情報といった様々な情報は Hinemos に蓄積されます。
それらの情報を活用するために、レポーティングオプションを使うことができます。
レポーティングオプションを使うことで、様々な情報をレポート形式にまとめて簡単に閲覧することができるようになりますので、その情報を使って、システムの分析や改善につなげるといったことができるようになります。
レポーティングオプションの入手方法ですが、基本には各 Hinemos パートナー企業様より入手していただくことが可能となっております。

以上で、Hinemos レポーティングオプションを活用した、Linux ＋ Apache ＋ PostgreSQL の監視とレポート作成についてのセッションを終わらせていただきます。ありがとうございました。

ここでは、当社 長田悠吾が行ったプレゼンテーションの内容をご紹介します。

■監視対象のシステム構成

SRA OSS, Inc. 日本支社 の長田です。よろしくお願い致します。
今日は、OSSミドルウェアで構成されたシステムの稼働状況を分析して、システムを改善するためのソリューションについてご紹介します。

まず監視対象のシステム構成について説明します。
Apache 、Tomcat 、PostgreSQL など、複数の OSS ミドルウェアで構成されています。
また、可用性を高めるために、サーバも複数台の構成になっています。

■Hinemos を活用した監視システムの構成と監視機能

次に、Hinemos を活用した監視システムの構成についてご紹介します。なお、当ブースでは、Hinemos を使った監視システムをデモ環境として展示しています。
Hinemos でどのように監視を行っていくか、この環境を例にご説明させていただきます。

これは、Hinemos で行うことができる監視機能の代表的な例を示しています。
Apache については、プロセス死活監視、ログ監視など、PostgreSQL については、プロセス死活監視に加えて、SQL 監視、各サーバでは、CPU やメモリの利用状況などの性能監視を行います。
これらの監視結果・性能情報は、Hinemos のデータベースの中に蓄積されていきます。

また、Hinemos の特長のひとつである、ジョブ監視がございます。
例えば Web サーバについて、日々のバックアップ、DB サーバについては、不要データ削除、DB最適化などのジョブを実行する必要があると思います。Hinemos からこれらのジョブを実行し、その実行時間やジョブの成功・失敗などの情報を監視します。
ジョブの実行結果についても、Hinemos のデータベースの中に蓄積されていきます。

これらの監視結果は、Hinemos クライアントを用いて確認することができます。
ここに示した画面はその一例ですが、各サーバの状況などを確認することができます。

■Hinemos の新機能、レポーティングオプション

それらを一覧でわかりやすく表示するのがレポーティングオプションです。これはつい先日追加された新しいオプションです。監視結果、性能情報、ジョブ実行結果を、まとめて集計して、PDF のレポートとしてわかりやすく表示します。
集計期間も、過去１か月分や、１週間分、昨日１日分など、期間を設定することがき、マンスリーレポート、ウィークリーレポート、デイリーレポートなどを作成することができます。

いつレポートを作成するのかといったスケジュールなどの各種設定は、Hinemos クライアントから設定します。また、即時出力も可能です。
レポーティングオプションとメール通知を組み合わせますと、レポートの作成が終了したタイミングで、レポートの PDF を添付して担当者にメールで通知することも可能です。

■グラフなどを使って、見やすいレポートを作成することができる

これは出力されるレポートの一例ですが、性能情報については CPU 、メモリ、Disk 、ネットワークなどの状況を出力できます。監視情報では、イベントの種類別のグラフなども表示することができます。

ジョブの実行結果については、実行時間をガントチャートで表示することも可能です。

Hinemos 、及び Hinemos のレポーティングオプションを活用することで、システムの監視、監視した情報の蓄積、情報の可視化・レポート、情報の分析を行うことができ、継続的にシステムを改善していくことが可能となります。

2014 年 9 月 11 日に、 東京中央区にて SRA OSS, Inc. 日本支社主催「PostgreSQL 9.4 最新情報 〜 新しいJSONデータ型開発者の Oleg Bartunov 氏を迎えて 〜」セミナーが開催されました。
本セミナーでは、ロシアから来日した PostgreSQL 開発の中心メンバーである Oleg Bartunov（オレグ・バルトノフ）氏より、現在開発中の 9.4 の最新動向をお話いただきました。とくに氏は、PostgreSQL 9.4 のなかでも JSONB 型の改良に関わっているところから「スキーマレス PostgreSQL」というテーマでの講演となりました。
またセミナー後半では、SRA OSS が実際に NoSQL との性能比較を交えて行った PostgreSQL 9.4 の JSON 型について検証結果をご紹介しました。

盛況となりましたセミナーの模様について、後半の PostgreSQL 9.4 検証結果報告をご紹介します。

■ SRA OSS, Inc. 日本支社 マーケティング部 PostgreSQL 技術グループ 高塚 遙 評価検証報告

高塚：

はじめまして。SRA OSS, Inc. 日本支社の高塚と申します。 現在は弊社 PostgreSQL 技術グループにてクラスタ構築支援、マイグレーション技術支援をはじめとした各種サポート業務を行っています。

本日は、PostgreSQL 9.4 の検証結果をご報告させていただきます。新しいバージョンでは、JSONB や GIN インデックスがメインとなりますが、時間の許す限り、それ以外の機能もご紹介できればと思っております。前半は性能アップしましたというポイントから、後半は新しく追加された機能についてご紹介します。

■ GIN インデックス性能改善

では早速、PostgreSQL 9.4 の性能検証についてお話させていだたきます。
バルトノフさんからもたくさんお話がございました GIN インデックスをテストしました。基礎的な性能改善度合いを確認するために、同じマシンで、PostgreSQL 9.3 と 9.4 を比較しました。使ったデータは 50 万件で、次の局面で優劣を比較しました。

• インデックスの物理サイズ
• 既にデータがある状態からのインデックス作成性能
• インデックスが作成されている状態からのデータ挿入性能
• インデックスを使った検索性能

図表をご覧いただくとひと目でわかるのですが、それぞれ、性能アップが数値に現れています。

私はこのテストを作るにあたっては、早くなった理由を知らずに行っているのですが、すべての局面において性能アップが証明されているところが、素晴らしいと感じました。

■ WAL の性能改善

次に WAL （ログ先行書き込み）の性能改善について検証しました。9.4 では、データ圧縮により WAL の出力量が低減したということが言われています。
pgbench という負荷ツールで、更新トランザクションを 5 万回実行したところ、pgbench 標準シナリオで流すと WAL サイズが 6％ 少なくなっています。さらにカスタムシナリオも実行し、アップデートだけのより単純な更新内容にしたところ、15％ 低減しました。

もうひとつ WAL の性能改善としまして、同時実行性が向上したと言われています。2012 年に PostgreSQL が 9.1 から 9.2 にバージョンアップした時も、同時実効性の改善があり、効率が上がったという話がありました。今回もその時と同じように、同時実行の競合を減らすような修正が入っております。その結果はどうかというと、5％ 程度の向上がありました。とくに同時実行を増やしていくと性能が上がっていく、ことがわかりました。

■ JSON 型とJSONB 型の機能比較　データ投入

ここからは、JSON と JSONB の比較になります。結論としましては、さきほどバルトノフさんからお話のあった結果とほとんど同じです。
10万件のログ情報を投入しますと、インサート時間は JSON より JSONB の方が若干遅いですが、投入するときに、JSONB は変換処理をしなければいけませんので、これはしかたないと考えています。
また、インデックス付きのインサート時間は一つの GIN インデックスが、Btree の関数インデックス ４ 箇所分と同じくらいです。4 か所以上インデックス検索したい JSON 上の項目があるなら、GIN インデックスの方が得です。

■ JSON 型と JSONB 型の機能比較　検索

次に、JSON 型と JSONB 型を GIN インデックスを利用しないフィールド検索で比較しました。
JSONB の検索は、JSON の所要時間に比べてほぼ半分になっています。これはバイナリで格納されているという効果です。つまり、GIN インデックスを使わなくても JSONB の検索では速いということがおわかりいただけたかと思います。

■ JSONB 型と他のドキュメント型データベースとの機能比較

最後に、他のドキュメント型データベース Couchbase Server と比較しました。
Couchbase Server は、速さを追求していまして、Web サイトでも他製品より速いことをアピールしています。
まずインサートです。10 万件データを挿入しますと、これはやはり Couchbase Server が速いです。しかしアンログ(Unlogged)にすると、そんなに差はありません。

続いて、並列ランダム更新、条件読み出しというタスクで比較しますと、並列ランダム更新では、PostgreSQL はおよそ 2 倍の時間がかかっています。条件読み出しでは GIN インデックスが使えるので、PostgreSQL の方が速い結果となっています。
とはいえ、もともと違う形態のソフトウェアですので、比較の仕方によって結果も変わってきます。本結果の値は参考程度と考えてください。

■ 新機能　レプリケーションスロット

それでは、PostgreSQL 9.4 から追加された機能の話に移りたいと思います。
まずレプリケーションスロットという機能を紹介します。なかなか説明が難しいですが、一言で言うと、「プライマリーとスタンバイをつなぐ絆」というような機能です。
これまでは、特定スタンバイに対してレプリケーション状態、付帯データというものを保持管理する場所がなかったのですが、その枠組みが出来たということです。それがスロットと呼ばれるものになります。

PostgreSQL 9.4 では、フィジカルレプリケーションスロットとロジカルレプリケーションが用意されています。

■ 新機能　更新ビューのチェックオプション

そのほかの新機能としては、更新ビューのチェックオプションが入りました。更新ビューは、一つ前のバージョン 9.3 から、ビューを定義したときにそのビューをアップデートしたりインサートしたりできるようになりました。この動作をより厳密にすることができるようになりました。

■ 新機能　ALTER SYSTEM / ALTER TABLESPACE MOVE

続きまして、ALTER SYSTEM という新しいコマンドが追加されました。SQL コマンドで PostgreSQL の設定を変更することができます。
また、テーブルスペースの変更をまとめて行うコマンドが追加されました。

■ 新機能　Refresh Materialized View の Concurrently オプション

最後に、REFRESH MATERIALIZED VIEW コマンドに Concurrently オプションというものが登場しました。もともとの Materialized ビューは、普通のビューと違ってテーブルに対してビューを定義したら、問い合わせた結果を覚えておいてくれるものでした。
次に問い合わせたときには、もとのテーブルにはアクセスせずに、覚えていた結果を出してくれます。この覚えていた結果を、元のテーブルをもう一回セットしなおして更新するときには、REFRESH MATERIALIZED VIEW コマンドを実行します。

ただしバージョン 9.3 までの REFRESH MATERIALIZED VIEW は、かなりロックレベルが強かったのです。REFRESH MATERIALIZED VIEW を実行中は、Materialized ビューに対するセレクトがブロックされてしまうわけです。ですので、今回の 9.4 では Concurrently オプションをつけることで、セレクトがブロックされることはなくなったというわけです。

さて、短い時間なので駆け足でのご紹介となりました。
別ページ (PostgreSQL 9.4 に関する検証報告) にも資料をアップしておりますので、興味をお持ちいただいたところは、ぜひご参照いただければと思います。
本日は、ありがとうございました。

« 前半

2014 年 9 月 11 日に、 東京中央区にて SRA OSS, Inc. 日本支社主催「PostgreSQL 9.4 最新情報 〜 新しい JSON データ型開発者の Oleg Bartunov 氏を迎えて 〜」セミナーが開催されました。
本セミナーでは、ロシアから来日した PostgreSQL 開発の中心メンバーである Oleg Bartunov (オレグ・バルトノフ)氏より、現在開発中の 9.4 の最新動向をお話いただきました。とくに氏は、PostgreSQL 9.4 のなかでも JSONB 型の改良に関わっているところから「スキーマレス PostgreSQL」というテーマでの講演となりました。
またセミナー後半では、SRA OSS が実際に NoSQL との性能比較を交えて行った PostgreSQL 9.4 の JSON 型について検証結果をご紹介しました。

盛況となりましたセミナーの模様について、前半部分のオレグ・バルトノフ氏の講演内容を中心にご紹介します。

■ SRA OSS, Inc. 日本支社 取締役支社長 石井 達夫 挨拶

石井：

SRA OSS, Inc. 石井でございます。
本日は、さまざまな改良が現在進行形で進んでいる PostgreSQL 9.4 の最新情報を、開発の中心メンバーであるオレグ・バルトノフさんから直接お話を伺えるという、またとない機会になりました。私もとても楽しみにしております。

このところ、PostgreSQL は再度の脚光を浴びていまして、国内外でさまざまな動きが出ているところです。
もともと PostgreSQL が強いと言われている日本では普及率も高いのですが、とくに最近の国内の動きとしましては、エンタープライズ領域での利用が増えています。
そして、もうひとつ注目すべき点は、海外での勢いです。
たとえば 2014 年 4 月には、イギリス気象庁で使われていたシステムが Oracle から PostgreSQL へ移行することが決まり、現在、鋭意、開発が進められていると聞いています。イギリス気象庁が、Oracle ではなく、PostgreSQL のほうが、業務をまかせるに足る最適なデータベースである、と選択したわけです。

このような背景を踏まえ、現在 PostgreSQL 9.4、β２の開発が進んでいます。今日の講演でも取り上げられる、GIN インデックスの高速化、インデックスサイズの圧縮、それからもちろん JSONB、そして WAL の圧縮など、次々と目を見張るような開発が行われている最中です。

このようなタイミングで、バルトノフさんをロシアからお招きできたことは、非常にうれしい限りです。
今日一日、長い時間になりますが、ぜひお付き合いください。改めましてご来場ありがとうございます。

■ モスクワ大学シュテルンベルク天文研究所所属/PostgreSQL 開発者 Oleg Bartunov（オレグ・バルトノフ）氏の基調講演

バルトノフ：

皆さま、こんにちは。オレグ・バルトノフと申します。現在私は、モスクワ国立大学のシュテルンベルク天文研究所に勤めており、PostgreSQL の開発を行っています。日本に来たのは初めてで、こうして呼んで頂いたことをとても嬉しく思っております。

PostgreSQL 9.4 の β 版は現在、鋭意、開発中です。今日は「スキーマレス PostgreSQL」と題しまして、PostgreSQL の現状と将来に向けてお話をさせていただきたいと思います。

今回リリースされる PostgreSQL 9.4 は、一言でいえば、NoSQL のいいところすべてを搭載している、と言えます。
具体的には、PostgreSQL 9.4 の目玉と呼ばれている JSONB を中心に、以下のアジェンダで話をすすめてまいります。

• 現在抱えている問題点
• HStore
• JSONB 導入
• JSONB クエリ言語
• JS クエリサポートと JSONB
• VODKA アクセスメソッド

■ ビッグデータ時代の課題と NoSQL の急速な進歩

現在進行形の課題としていちばん注目しているのは、データ、あるいはアプリケーション/ Web アプリケーションを取り巻く環境です。「ビッグデータ」という言い方でひとくくりにまとめられていますが、これは量であり、速度であり、種類でもあります。
こうした状況で必要とされているのが、いかに負荷を軽くするか、という点です。また、アプリケーション自体のリリースも、非常にスピードを求められるようになってきています。
ビッグデータ時代に対応する新しいデータベースとしては NoSQL が注目されています。NoSQL、つまり「Not only SQL」は、RDB（リレーショナルデータベース）以外のデータベースの利用・発展を促進させるという意味合いで、大量のデータを扱う場合の旗印のように言われています。NoSQL は、固定されたスキーマにしばられることなく水平スケーラビリティが確保しやすく、同時実行性も高く、なおかつ堅牢であり、といったような特徴があり、どのようなデータでも懐広く受け入れられる仕様になっています。

もともと「NoSQL」はキーバリューデータベースというシンプルなものからスタートしましたが、そこにキーバリューストアや、あるいはレンジサポートというものが加わりました。そしてカラムファミリーであるとか、ドキュメントデータベース、グラフデータベースというものが追加されることによって、非常に複雑な SQL が出来上がりました。こちらをご覧頂くと、「NoSQL」がいかに短期間で進歩してきたかがおわかりいただけるかと思います。

■ RDB の課題から生まれた、PostgreSQL で JSON フォーマットを使うという発想

私たちは PostgreSQL 9.2 で、JSON（JavaScript Object Notation）を導入しました。今回私たちは、JSON のフォーマットをより進化させ、PostgreSQL 9.4 に JSONB を導入したわけですが、ここにいたるまでは長い道のりであり、大きな挑戦でもありました。

その説明に入る前に、改めて RDB の問題点を考えてみましょう。
まず、皆さんがお使いになるアプリケーションには、ACID トランザクションが必要です。ACID トランザクションに加えて、NoSQL の柔軟性を求められた場合、どのように対応すればよいのでしょうか？また、たとえばテーブルを変更する、配列を変えるなどのオンライン上での変更が求められる場合、どう解決したらいいでしょうか？
アプリケーションの側は、こういったスキーマの変更を待たなければならないため、その分リリースが遅れるわけです。迅速なスピードが求められるビックデータ時代、リリースが遅れは致命的な問題につながる可能性があるわけです。

このような課題を見つめることで PostgreSQL で JSON フォーマットを使うという発想が生まれたわけですが、その前段階として HStore というモジュールがありました。

■ PostgreSQL のキーバリュー型のデータストア、HStore が生まれた背景

PostgreSQL は、実は、すでに 2003 年から実質的にスキーマレスになっています。HStore というモジュールが、PostgreSQL をスキーマレスにしたからです。
HStore はキーバリューのペアを格納しやすい形になっており、非常に迅速な検索を可能にします。また、インデックスサポートも兼ね備えています。 システムに変更が生じた場合も、スキーマを変更する必要はなく、HStore の中だけを変えればいいということになるわけです。HStore によってアプリケーションも非常に迅速にリリースできますし、スキーマのアップグレードにも対応できます。

HStore の誕生は、開発途中での問題が新しい気付きとなり開発に繋がっています。その歴史を振り返ると、2003 年に初めてのバージョンが誕生した HStore は、2006 年の 12 月に PostgreSQL 8.2 の一部として導入され、さらに 2007 年の PostgreSQL 8.3 では GIN インデックス for HStoreが導入されました。

■ 9.4 で圧縮と検索性能が改善された GIN インデックス

GIN インデックスは、PostgreSQL 9.4 で大きく改善された機能のひとつです。GIN インデックスの「GIN」とは、「Generalized Inverted Index（汎用転置インデックス）」の略で、文字通り幅広い用途で非常にパワフルに検索できるインデックスです。テキスト全文検索からオブジェクト検索まで、ひとつの値の中に複数の要素を持つようなデータ型に活用できます。

GIN インデックスの今回の改善点はふたつあります。インデックスサイズの圧縮と検索性能の向上です。
まず、インデックスサイズの圧縮ですが、たとえば PostgreSQL 9.3 で 90 バイトのポスティング・リスト（GIN インデックスの構造の一部）があったとすると、9.4 では 21 バイトにまで圧縮されるようになりました。およそ 4 倍強の圧縮がかかっていることになります。
また、検索性能も改善されました。たとえば、PostgreSQL のなかで「ブラウン」と「PostgreSQL」、この二つの言葉をサーチしてみましょう。PostgreSQL 9.3 ではあくまでも「PostgreSQL」という言葉を先に検索します。よく出てくる言語の方に時間が比例する仕組みで、結果が表示されるまでに非常に時間がかかりました。対して 9.4 では、「ブラウン」というめったに出てこない言語を先にサーチしていきますので、非常に時間を短縮できるようになったのです。

■ 試行錯誤の上、HStore から JSONB へ

ここまでお話したように、HStore は非常にシンプルなバイナリで、すばらしいエクステンションなのです。ただし問題点は、シンプルすぎるということでした。ネスティング（Nested）、あるいはツリー構造との関係のなかで HStore をどう扱うべきか、いろいろと模索がありました。
2012 年頃には、ここまで HStore が優れているのだから、いっそのこと「Nested HStore」を作ろう、というプロジェクトが立ち上がりました。しかし、紆余曲折の末、2014 年の 3 月に Nested HStore から、JSONB と呼ばれる新しいデータ型へ移行することを決めました。開発を進めるなかで、HStore の互換性に問題があることがわかってきたからです。

JSONB は、PostgreSQL 9.2 から導入している JSON (JavaScript Object Notation)という XML などと同様のテキストベースのフォーマットに、バイナリデータとしてデータを格納したものです。JSONB の「B」は「バイナリ（binary）」の「B」です。

JSON は構造化されたデータを簡潔に記述できるため、人間が理解しやすいデータフォーマットとして、いまやさまざまな環境やツールで使われています。PostgreSQL の JSON 型は、基本的には文字列データ型で、値を格納するときに JSON としての構文チェックが行われ、JSON 処理関数や演算子も用意されています。

ただ、HStore と JSON を比較すると、やはり JSON は遅いわけです。両者の特性を活かすとしたら、新しい HStore でドキュメントベースモデルをサポートしていく必要がある、と考えました。また JSON に対しては、バイナリの表現ができないか、ということを考えました。
それなら「バイナリの JSON」という発想に切り替えようじゃないか。ということで生まれたのが、JSONB だったのです。そしてこの JSONB が、PostgreSQL 9.4 の目玉と言えます。

■ JSONB デモンストレーション

MongoDB と比較をしてみました。データのローディングでは、MongoDB の方が非常に遅いという結果です。JSONB 43 秒、そして MongoDB 13 分という結果になります。
シーケンシャルスキャンによる検索は、ほぼ同じ。そしてインデックススキャンについては、JSONB がかなり速いという結果です。

こちらが最終的に PostgreSQL と MongoDB を比較したものになりますが、JSONB の速さが際立っています。
テーブルサイズは、やはり MongoDB の方が大きいことがわかります。PostgreSQL の方が 1.3 Gb、MongoDB の方が 1.8 Gb となります。
入力の性能は、MongoDB の方がより良いです。インデックスのサイズについては MongoDB が非常に大きいという結果です。

■ PostgreSQL 9.4 という進化

こちらが、NoSQL がいかに進化してきたか、というスライドになります。
PostgreSQL が登場したころ、２つが最終的に出会う場所というゴールが、今、まさにやってきたわけです。PostgreSQL であり、オープンソースであり、そして RDB という形での提供、そして現代、今ということです。
やっと JSON の非常に強力なサポートというものが実現しました。古いところから新しいもの、古いところからも、またかつ新しいものからも学んでいくというのが、この PostgreSQL のあり方であり、非常に柔軟性に富んだコミュニティからの開発が行われています。
従って、現在 JSON が使える、サポートが得られているということであれば、MongoDB を使う意味は見いだせないような気がします。

今回リリースされる PostgreSQL 9.4 の特徴を一言でいうならば、「NoSQL のいいところすべてを搭載している」と言えるでしょう。すなわち、オープンソースであり、OS を選ばず、JSON サポートのあるデータベースの提供ということです。

他のデータベース管理システムと比較をしてみますと、Microsoft SQL Server と Oracle は、まだ JSON のサポートがありません。MySQL は、JSON の機能をある程度サポートしていますが、インデックスサポートがありません。

■ 現在開発中の VODKA アクセスメソッド

最後に、PostgreSQL の将来について、お話しましょう。

現状、 BTree については試行錯誤しているところでして、たとえば全文検索に対応できるようなものに変えていくことを考えています。そのようななかで、新しいインデックスへのアクセス方法として、VODKA というものを作っています。
現在、PGCon でこの結果を少しずつ発表させていただいています。将来的には、PostgreSQL 9.5、あるいは 9.6、あたりに向けて開発をすすめています。
ということで、VODKA は、決して飲み物ではないということがおわかりいただけたかと思います(笑)。もちろん GIN も飲み物ではありません(笑)。ちなみに、このネーミングは、そもそもアラビアンナイトに出てくる魔法使いのジーニーからとっています。

いずれにしても、私たちの開発は、決して止まることはありません。常に変化を起こしていくことが好きですし、これからもよりよいインデックスを探していく、あるいはそのインデックスに対してのアクセスの方法というものを、皆様に提供したいと考えています。

現在、私たちのプロジェクトは非常に多くのタスクが待ち構えています。皆さんのなかで、ぜひチームに入って一緒に開発をやりたいという方がいらっしゃいましたら、大歓迎でお迎えします。

本日は、ありがとうございました。

■ 質疑応答

質問者：

PostgreSQL では Hint 句は使わないという方針だったと思いますが？

バルトノフ：

ご指摘のとおり、私たちのなかでも反対意見というものはでています。将来的に何か素晴らしいプロジェクトがあって、JSONB に対する統計がとれて分析結果が出てきたときに、Hint 句自体は必要なくなってくるという風に我々も考えています。

ただし、現段階で JSONB をお使いになりたいという場合、複雑なものに対応するには Hint 句というエクステンションが必要になってくるという場合もあると考えています。Hint 句はあくまでも拡張機能ですので、使いたい方が使っていただければというスタンスになっています。

質問者：

JSONB と JSONB のインデックスは、トランザクションに対応していますか？

バルトノフ：

はい。PostgreSQL は RDB ですし、JSONB の方はスタンダードのデータタイプということになりますので、もちろんトランザクションに対応しています。安心してお使いいただけます。

後半 »

2013年11月に新バージョン2.2がリリースされてからというもの、日本国内でも急速に導入が進み注目を集める監視ツール、Zabbix。
仮想環境の監視ツールとしてデファクトスタンダードとの呼び声も高いこのツールについて、Zabbix Japan 代表 寺島 広大氏をお招きして、当社Zabbix技術責任者である盛との対談が実現しました。
参加者の皆さんからの質疑も含めると対談は2時間にも及び、Zabbixの現状と未来について熱いディスカッションが繰り広げられました。

登壇者プロフィール

Zabbix Japan 代表 寺島 広大

Zabbix SIA にてテクニカルサポートエンジニアとして働き、2012年10月からは Zabbix日本支社の CEO として日本国内の Zabbixパートナーの支援、トレーニング講師を行う。
2005年に設立した Zabbix の日本コミュニティーの創設者でもあり、2010年にはZabbix の日本語書籍を執筆。

SRA OSS, Inc. 日本支社 マーケティング部
OSS 技術グループ　マネージャー　盛 宣陽

SRA OSS, Inc. 日本支社で、各種オープンソースミドルウェアのサポート、コンサルティング、改良業務等に従事。
現在は、Zabbix の技術責任者として、構築支援、サポートを中心に活動している。
2013年 Zabbix Conference 等で講演など。

（司会）株式会社オープンソース活用研究所
代表取締役所長 寺田 雄一

2006年に野村総合研究所（NRI）にてオープンソース・ワンストップサービス「OpenStandia（オープンスタンディア）」を創業し、2013年まで事業責任者を務める。
オープンソースビジネス推進協議会（OBCI）、OpenAMコンソーシアム発起人。
2013年12月、NRI を退社しオープンソース活用研究所を設立。

仮想化環境における監視機能が強化されたZabbix2.2

寺田：
本日、司会進行をつとめますオープンソース活用研究所の寺田と申します。
今日は宜しくお願い致します。
まず、Zabbix Japan 寺島さん、SRA OSS 盛さん、自己紹介からお願いします。

盛：
SRA OSSでは、各種オープンソースのサポートを10年ぐらいしております。
またZabbixの技術責任者としても業務を行っています。
今日は仮想化環境におけるZabbixについて、寺島さんの胸をお借りして、忌憚のない意見をぶつけてみたいと思います。

寺島：
現在、Zabbix Japan で日本のユーザー様、パートナー企業の支援を行っています。
Zabbixには、もともとエンジニアとして携わってきました。
ラトビアにある本社で1年半ほど働きまして、その後、2012年に Zabbix初の海外法人として日本で支社を設立しました。
今は代表をしておりますが、現役のエンジニアでもあります。
ちなみに Zabbix 本社の社長も現役エンジニアです。
2013年11月にZabbixが2.2にリリースされました。
2.2の大きな特長は、仮想化環境における監視機能が強化されたところです。
具体的にはリソース監視を中心に実装したVMwareの監視機能が搭載されました。
バージョン2.2で新しく追加された機能の一部では、私も開発にも携わっています。
今日は、Zabbixの深いところも含めてお話できればと思っています。

仮想化環境における監視の課題は、リソースの監視と対象追随機能

寺田：
近年、仮想化環境によるシステム設計が標準になってきました。
物理サーバーの時代と比べ、仮想化環境における運用監視のポイントは、どこにあるのでしょうか？

盛：
実際の運用にあたっては、次の4点がポイントになると思います。
ひとつめは、従来と比べ、監視対象がひとつ増えたことですね。
仮想化環境では、ハイパーバイザー(仮想マシンモニタ)自体の監視が増えました。
次に、どこを監視するか、という点ですね。
ハイパーバイザー側からみたリソース状況と、実際のゲストOS内部からみたリソース状況、この両者を比較しながら監視を行っていくのが、ひとつのポイントとなります。
仮想化環境では、CPUやメモリなどの仮想リソースを、ハードウエアの物理リソースの総量を越えてゲスト環境のOSに割り当てることができます。
これを、オーバーコミットと呼びます。
オーバーコミット機能を使うとリソースを共有して稼働率を高めることができますが、想定以上にシステム全体の負荷が上がることになり、個々のゲストOSだけでなく、全体的な監視が必要になってきます。
3点目は、ハイパーバイザー上でゲストOSが常に動くので、どこの物理サーバーで実際に動いてるかについて、常に追従する必要があります。
最後に、仮想化環境基板では、オートスケールなどゲストOSを追加していく状況に応じて迅速に監視が行える機能が必要となります。

寺島：
盛さんからもお話がありましたが、仮想化環境にあたって重要なのは、リソースの監視と、動的に増えていく対象に追随する機能です。
Zabbix2.2のVMware機能をまとめますと、ハイパーバイザーとゲストVMのリソース監視、vCenter/vSphereのイベント監視、vSphere API、vCenter APIの双方のサポート、自動検知、自動登録、そしてVMware監視用のテンプレートの付属、といったところになります。つまり、仮想化環境での監視における課題に対応した機能を、ひととおり揃えています。
Zabbix2.2は、2013年11月のリリース以来、VMwareの監視機能を使いたいという声が寄せられて、国内外問わず、かなり多くのお客様にご利用いただいている状況です。

VMware監視機能が搭載されたZabbix2.2の威力

寺島：
Zabbixのリソース監視設定は、非常に簡単です。
Zabbixサーバー(監視マネージャー)で運用管理者が行なう操作は、適切なテンプレートを適用させて、APIから必要なURLを登録するだけです。
この登録だけで、監視対象のゲストVMやホストOSのリソースを検知して、自動的に監視が始まる仕組みを搭載しています。
ホストをまたいで動くといった場合も、Zabbixサーバーではグループ化して管理しているので、グループが切り替わることで追随してくれます。
さらに2.0バージョンから搭載されているのが、OSなどが異なるネットワークインターフェイス、ディスクの構成などを自動的に監視項目に追加できる機能です。
これらの機能を組み合わせていくと、さまざまなことが可能になります。
たとえばゲストVMを自動的に検知するだけではなく、ゲストVMがもつインターフェイスの数、ディスクの構成までも、自動的に監視することができるのです。
VMwareの監視として、非常に簡単に始められる仕組みとともに、深い部分でVMwareの監視機能を実装していますので、監視の規模が大きくなっても管理者の方が手間がなく、スムーズに監視できるというのが特長です。

寺田：
盛さんによると、仮想化環境における監視の課題としては主に2つありました。
ゲストOSだけを監視するのではなく、システム全体で見なければならないという点と、ゲストOSが物理的にサーバーを移るので、それにどう追随するかという点でした。
今の寺島さんのお話ではZabbix2.2は、上記の課題に対応している上に、テンプレートがあるので導入が簡単というところが特長なんですね。
ところで、Zabbix2.2はオーバーコミットについて検知できるのですか？

寺島：
Zabbix2.2は、メモリ、CPUなどのリソース監視が標準になります。
ですからオーバーコミットそのものの検知とは異なります。
ただ、Zabbix内部のデータを活用することでオーバーコミットを検知することはできるようになります。

簡単設定、監視自動化、そして圧倒的なパフォーマンス

寺田：
Zabbixをユーザー企業に実際に導入する立場として、盛さんは今回のバージョンアップをどのように評価しますか？

盛：
そうですね。評価の話をするまえに、寺島さんに伺いたいことがあったのですが、Zabbix2.2でVMwareの監視を行なうには、事前準備としてlibcurl 、libxml2をコンパイルする必要があります。
従来は、JAVAのコマンドを使って取得した部分です。
なぜ今回は、libcurl 、libxml2というHTTPとXMLでデータを取得する実装にされたんですか？

寺島：
2.2の開発時の課題のひとつが、パフォーマンスでした。
ご存知のようにvCenterの負荷が上がると監視が継続できないので、パフォーマンスを上げるためにlibcurl 、libxml2を採用しました。
ZabbixサーバーはC言語で作っていますので、Cからリクエストを出して、キャッシュ情報を活用することで、パフォーマンスを向上させることができたと思います。

盛：
なるほど。
私たちも2.2の評価は、そこにあるのではないかと思っていました。
検証を行ったときに驚いたのは、非常に負荷が軽いということでした。
従来は、VMwareの監視をしながらコマンドを叩いていると、ハイパーバイザー側に迷惑をかけたりすることがあったのですが、今回のバージョンではそれが皆無でした。
バージョンアップで こういう状況が解決されたことが、とてもうれしかったです。
パフォーマンスの改善は、多くの副産物を生んでいます。
監視自体もそうなんですが、負荷が改善されたことで、CPU使用率がかなり低くなっています。
また、負荷が改善されたことで、より多くの監視対象が増え、より多くの情報が取得できるようになりました。
あと、さきほど寺島さんからもお話がありましたが、設定も非常に簡単になりました。
ホスト名を指定して、ユーザー名とパスワードを登録し、テンプレートをアップするだけで監視が始まります。
この手軽さには、本当に驚きました。

PostgreSQLは、突発的な負荷に強い

寺田：
盛さんは、ZabbixのデータベースとしてMySQLとPostgreSQLを比較されたそうですね。

盛：
はい。
600ホストをシュミレーションしたZabbixの立場からの検証で、5秒という短い間隔でアイテムを取得してデータベースの負荷を比較したベンチマークです。
デフォルトのメモリを同量にして、データベースを比較したところ、MySQLとPostgreSQLは、ほぼ同じ性能という結果が出ました。
また、Zabbixを運用する上で怖いのが、ハウスキーパーという負荷です。
この負荷が始まると、PostgreSQLのほうが耐性が強いことが見てとれ、突発的な負荷でもPostgreSQLは遅延が起こりづらいという結果がでました。
大規模環境であればあるほどデータベースに負荷をかけてしまうことが多く、監視に影響が出るケースが少なくありません。
この検証からは、ZabbixとPostgreSQLの組み合わせが、大企業でも安定した運用が可能であるという結果が導き出されると思います。

寺田：
PostgreSQL用のバックアップツールも開発したと聞いていますが。

寺島：
Zabbixは、監視設定も監視データもデータベースに貯めていくのですが、たとえば管理者の方が誤って設定を消してしまったような場合、監視設定だけをリストアできるツールですね。
MySQL用のバックアップツールはすでに用意されていますが、PostgreSQL用ツールは開発中です。
近々、公開できると思います。

数万規模の監視にも使われるZabbix

寺田：
仮想化環境でのZabbixの導入事例はありますか？

寺島：
従来Zabbixを導入しているのはIT企業、スタートアップ企業といった限られた業界での利用というイメージがありましたが、現在は、大手企業様の社内システムでの導入も増えています。
国内でも、金融、通信(キャリア)、公共団体などでご利用いただいています。
大規模環境での事例としては、ニフティさんがあります。
ニフティさんでは、VMwareの仮想環境で2.2をご利用いただいています。
詳細は、当社ホームページでご覧いただけます。
グローバルでみると、銀行のATMでの監視をはじめとしたファイナンス系、政府機関、航空機関など多岐に渡り、監視対象が数万規模の企業も少なくありません。

グローバルで認められたZabbixの機能

寺田：
大手企業がZabbixを採用する決め手はなんですか？

寺島：
導入の動機は「これまで構築したものは残しつつ商用製品のライセンスコストを下げたい」、「パフォーマンスを良くしたい」など、企業様によってさまざまです。
コストが決め手になる局面も、当然あると思います。
ただ海外のユーザー様のお話を聞いていると、オープンソースであることが決め手になっているケースが少なくありません。
「ソースが開示されているから、自分たちが今何をしているか把握できる」というオープンソースの特性を気に入っていただいているんですね。
つまり「Zabbixの機能が好きだから使う」というシンプルな選択だと思います。

寺田：
エンタープライズ分野の運用監視は、既に標準のツールが決まっていて、新規参入は難しい印象があるのですが。

寺島：
大手企業様でも、企業内の監視ツールが標準化されていないところは少なくないようです。
プロジェクト単位で担当者が決めているという実情があり、複数のソフトがバラバラに入っているのでそれらをZabbixで統合監視したい、という話を聞くこともあります。

Zabbixは、デファクトスタンダードになるか？

寺田：
最近では監視ツールを導入する場合、いちばんはじめに候補に上がるのがZabbixだと思います。
言い換えると、Zabbix以外に他社製品の名前を聞きませんよね。
ずばり、Zabbixはデファクトスタンダードになると思いますか？

寺島：
デファクトスタンダードになるかどうかは、私たちが決めることではないので、コメントが難しいところですが(笑)。
現状、国内で出回っているツールといえば、ライセンスが必要な商用製品と、コア部分はオープンソースで機能を追加するときはライセンスが必要、というツールがほとんどではないでしょうか？
そういったラインナップのなかでのZabbixの特長は、フルオープンソースで使えるところだと思っています。
ただしZabbixのようなフルオープンソースのツールでは、運用後に不安を抱くお客様がいらっしゃるのも事実です。
運用時、誰がサポートするのかという問題と、安定して新しいバージョンが出てくるのか、という開発の継続性の問題ですね。
Zabbixはもともと個人で開発されたソフトでしたが、企業様が導入するようになってからは法人化されました。
ですから現在のZabbixは、企業が開発しているんです。
お客様の立場からすると、ツールそのものは無料だから導入に障壁が少なく、何かあったときサポートも受けられることになります。
運用後も安定したサポートが受けられるフルオープンソース、という意味では、国内ではZabbixだけかなとは思います。

運用後も安心できる、フルオープンソース

寺田：
Zabbixのサポートサービスについて、詳しく教えてください。

寺島：
ツールが無償というと、会社としてどうやって成り立っているのか聞かれることもありますが(笑)、Zabbix Japan は、有償のサポートを提供しています。
Zabbix Japan が企業として開発やサポートを支援し、SRA さんをはじめとしたZabbixのパートナー企業さんに構築支援をしていただいています。

具体的には、何か問題が起こったときの対応、バグ報告、フィードバックができるコミュニティの運営、さらにポータルサイトでのナレッジの提供を行っています。
このポータルサイトは、今後も充実させていく予定です。
当社がもっているツールやプラグイン、テンプレートなどを共有していく場にもしようとしています。
現在、国内で30社ぐらいのパートナー企業と共に Zabbix を広めており、ユーザー企業様に安心して使っていただく土台を整えているところです。

寺田：
Zabbixパートナー企業であるSRA さんでは、どのようなサポートを受けられるのでしょうか？

盛：
もちろん Zabbix 個別のサポートも行っているのですが、当社が得意としているのは、Zabbixと他のツールを組み合わせたサポートや構築です。
特にPostgreSQLとの組み合わせや、Zabbix、PostgreSQLの冗長構成の構築などを得意としています。

Zabbixの進化の源、開発サービス

寺田：
機能改善のリクエストに基づいた開発サービスについて聞かせてください。

寺島：
実際にZabbixを導入した企業様からいただいた「こんな機能を入れてほしい」という要望をZabbixに取り込み、次のバージョンでリリースするという取り組みが開発サービスです。
企業様の立場から見ると、商用ライセンス費用よりも廉価で、具体的な機能追加を依頼できるというのがメリットになると思います。
機能が追加された暁には、Zabbixそのものの発展にもなるだけでなく、多くのフィードバックを受けたZabbixが、一企業だけでなく、より多くのユーザー様にとって使いやすいツールに発展するところも大きなポイントです。
さきほどお話したVMwareの監視機能も、実は特定の企業様からいただいた機能追加要望に基づいて開発が始まったんです。
現在、Zabbixに取り込まれている機能には、世界のどこかでこのスポンサーシップに近い輪から生まれものが多いんです。
Zabbixは、この開発サービスによって、日々進化していると言えると思います。

寺田：
新しいバージョンのリリースポリシーについて教えてください。

寺島：
Zabbix2.2以降、メジャーバージョンのリリースサイクルが早まります。
開発サービスを利用する企業様が増えてきていて、機能追加をした新バージョンをなるべく早くリリースしたいというのがその理由です。およそ半年スパンで安定的に最新版のリリースを行いながら、長期的サポートの提供も行なう予定です。
ちなみに2.4は、2014年6月にリリース予定です。
新しい機能を使いこなしてご自身でバージョンアップされる方は2.4、同じバージョンを安定して使っていきたい方は2.2がおすすめです。
また、これまでご利用いただいていた Zabbix 1.8 は 2014 年 11 月で開発が終了します。
開発終了後はセキュリティ・ホールなどの対応が難しくなるので、バージョンアップの検討をお願いしています。
「バージョンアップ推進セミナー」という無料セミナーも随時行なっています。

参加者からの質問

【Q】Zabbixプロキシを使った、マルチテナントな大規模監視時のホストグループその他のベスト・プラクティスはありますか？

寺島：
マルチテナントというのは、複数のユーザーがいて権限をわけて、監視サービスを異なるお客様に提供しているというイメージでしょうか？
Zabbixには、権限振り分け機能はあります。
たとえば、プロキシをリモートのお客様において監視をして、集まった情報は特定のユーザーにしか見えないという設定ですね。
ただしプロキシの管理をユーザーにまかせたい場合は、ZabbixのAPIを使って調整していただいているのが現状です。
この課題について、多くのお客様からご要望をいただいていますので、次回の機能追加要望として承っています。

【Q】データセンターサービスでの監視サービスの事例はありますか？

寺島：
あります。
Zabbixの特長のひとつがAPIの存在ですね。
API経由で問い合わせをすることで、収集したデータの一部を抜き出してお客様に見せることができます。
たとえばデータセンター内の環境すべてをZabbixで監視をしておいて、お客様に監視状況を見せる場合は、APIを使って特定の情報を取得したり、ユーザー様向けのダッシュボードを作ったりすることが可能です。

【Q】階層を、もう少し深く分けることはできませんか？
2.2ではハイパーバイザーの上にVMが大量に乗っているので、システム側から見ても見づらいし、ユーザーから見ても運用がしづらいと思います。

寺島：
バージョン2.2を開発する時点で、ホストグループの階層化は課題としては上がっていたんです。
このご要望は非常に多くの方からいただいていますので、近い未来のバージョンアップで公開できるよう検討している最中です。

【Q】1.8から2.2へのバージョンアップを検討しています。
VMwareのハイパーバイザー監視をしたいのですが、エージェントのバージョンアップは必要でしょうか？

盛：
エージェントのバージョンアップは、必要ありません。
VMwareの監視ではZabbixサーバーの機能のみを使うからです。
1.8の機能で充分であればそのままで結構ですし、エージェントのほうで2.2が必要であればバージョンアップしていただければと思います。

【Q】監視対象のハイパーバイザーにもバージョンがあると思うのですが、ターゲットのバージョンに合わせたプロファイルはどのように制御しているのですか？

寺島：
いまのところZabbixが取得できるリソースデータは、ある程度決め打ちになっています。
APIに生でアクセスして、そこから帰ってくるXMLのデータで各バージョンの動作を確認していただくという流れになっています。

【Q】競合製品と比較した場合、Zabbixの優位点、不利な点を教えてください。

盛：
私は、やはり金額に尽きると思います。

寺島：
たしかにゼロ円に勝てるものはないですよね。
また、2.0以降、Zabbixは機能強化されました。
商用製品とZabbixの機能的差異は、日々刻々埋まってきていていると実感しています。
監視機能だけを取り上げれば、商用製品とZabbixはほぼ同じだと思っています。
商用製品にないZabbixの特長としては、自動化の部分でしょうか。
VMwareの監視機能ですね。
設定をテンプレート化すれば、自動的に監視項目を見つけてきて監視を始めてくれるところは、運用管理者の負担を下げると思います。
監視部分の機能だけを商用製品と比較していただくと、この機能の優位性について理解していただけるのではないかと思います。

【Q】商用製品と比べると、Zabbixはとっつきにくいという声を聞きます。
実際に現場で監視しているのは、商用製品のUIに慣れているオペレーターさんですから。こういった問題を改善するための計画はありませんか？

寺島：
そういうお客様の場合は、お客様が実際に目にする管理画面に商用製品を導入して、お客様から見えない内部のシステムにZabbixを使うという構築をするといった、フロントとバックの棲み分けを提案しています。
運用管理として総合的に考えたときには、UI、資産管理、ジョグの部分は使い慣れた商用製品でまかない、監視部分だけZabbixに置き換えるという方法は、理にかなっているかもしれません。
必要に応じて、お客様にとって最適なものを選んでいただければと思います。

【Q】AWSなどのパブリッククラウド環境でのZabbixの活用事例があれば教えてください。

盛：
AWSのクラウド監視は、クラウドウォッチというコマンドが提供されています。
Zabbixは柔軟な監視が可能なので、クラウドウォッチというコマンドを叩くことで、AWS上のデータをとることができます。
Zabbixのパートナー企業TIS社では、Zabbixのオンプレミス環境とAWS環境両方を同時に監視ができる「HyClops（ハイクロップス） for Zabbix」を開発しています。

寺島：
クラウドは、AWSのような定形サービスだけに対応するのであれば問題はないのですが、多くの場合、個別の対応が必要になります。
すべてのサービスに対応するという全方位型ツールは、反面、使いづらくなるものです。Zabbixでは、常に「どうすれば使いやすいのか？」という視点を常に考えています。
そういう意味で、Zabbix本体に機能として取り込むというよりは、クラウドとZabbixをつなぐ部分の環境づくりを考えていきたいです。
イメージとしては、Zabbix向きサードパーテイツールのようなものですね。
これも、今後の課題ですね。

【Q】Zabbixは、オープンフローでサポートを予定しているものはありますか？
オープンフローと他のソフトの連携はありますか？

寺島：
仮想ネットワークも含めて、フローについて質問をいただく機会が増えてきました。
これまでは物理的なものを監視するだけでしたから、監視対象もわかりやすかったのですが、オープンフローでは、何を監視するのかという点を再定義しなければなりません。
そのあたりを課題として、今後対応していきたいテーマのひとつです。

【Q】ビューの多様化についてはどのように考えていますか？
顧客情報、システム情報、物理環境と連携をして負荷状態を見る場合のビューですね。Zabbixはシステム監視機能は素晴らしいのですが、もう少しユーザー目線のサービスを追加して欲しいです。

盛：
Viewの多様化については、ZabbixのAPIを使って加工しています。
以前、寺島さんにJクエリにUIをつけて展開できないかと相談したことはあります。
もっと柔軟にビューを作れるのではないかというリクエストですね。

寺島：
その通りだと思います。
現状では監視項目単位がベースになったビューが多いので、違う切り口のピューは必要ですね。
運用管理者の目線も含めて、これから深く議論をしていきたいところです。

【Q】他のシステムからの移行時の注意点を教えてください。

寺島：
残念ながら、コンバートツールの用意はありません。
監視は運用要件をどう設定に落としこんでいくかがポイントです。
ZabbixはZabbixに適した設定の作り方があるので、いったんZabbixを理解していただき、どういう監視が必要なのかを洗い出しをしていくところから、作業を始めていただきたいと思っています。
乗り換え時点で多少手間はかかりますが、現状の監視ツールを精査していただき必要な要件を見極めていただくことで、これまでより的確な通知ができるようになるし、現状の再定義、課題の洗い出しができるようになると思います。

【Q】障害が起きたときに、どのリソースを使ってたときにこの事象が起きたのか、どのログが出ていたのか、周りのリソースはどうだったのか、負荷はかかっていなかったのか、そういった情報を参照できる仕組みはないですか？　運用時にそういう機能があると助かるし、Zabbixとしての特長が出ると思うのですが。

寺島：
たしかに、そういう情報のヒモ付けができるようになるとより使いやすくなりますね。
今後の課題として、検討させていただきます。

【Q】Zabbixのデータを2次加工できるような機能はありませんか？　たとえば生データを期間別、アイテム別で出力するといったような機能です。実装するのは、そんなに難しい機能ではないと思うのですが。

寺島：
仰るように、機能を実装すること自体は難しくはないんですが、要は、パフォーマンスとの兼ね合いなんですね。
たとえば2年分の情報を抽出しようとして、負荷がかかると監視が止まってしまうと、監視ツールとしてはNGなわけです。
プラグインのような外部ツールとして入れることはできると思うのですが。

【Q】監視間隔はどのぐらいが妥当ですか？

寺島：
Zabbixでは1秒～1時間間隔で監視間隔を設定できます。
リソース監視であれば5分間隔ですが、詳細は用途によって異なります。

寺田：
活発なご意見をありがとうございました。今後のイベント告知などがあれば、お知らせください。

寺島：
6月に開催される「Interop Tokyo 2014」に出展予定です。
SRAさんにもご協力いただいて、監視を担当することになりました。
このイベントでは、会場内のネットワークを出展する企業で構築しようという面白い試みに挑戦します。

盛：
Zabbix Japanさんと共同出展します。
何ができるか話し合っている最中ですが、データベースにPostgreSQLを使ってみようというアイデアもあります。
そのほかZabbixの冗長構成を実現することを考えています。
pgpoolを使って負荷分散して、Zabbixのメリットを伝えたいと思っています。

寺田：
最後に、今後の抱負をお願いします。

盛：
お客様からの要求を集めるのが私たちの仕事です。
それを寺島さんにフィードバックし、適切なソリューションを一緒に考えていきたいです。
また、Zabbixのパートナー企業間でも連携して、よりZabbixに貢献したいと思っています。

寺島：
今の私の役割は、国内ユーザー様へのサービス提供のほかに、日本の利用者が抱いているZabbixへの要望や期待を本社に伝えて、本社のエンジニアを説得することだと認識しています。
そういった意見をZabbixに反映させることでZabbixもよくなりますし、最終的にはすべてのユーザー様へのメリットにもつながると信じています。
今後も多くのパートナー、ユーザー様と接して意見を言っていただける場を増やしたいと思います。
また、一エンジニアとしても、いろいろなところで楽しいことができればいいなと思います。
イベントも頻繁にやっていますので、ぜひ、お気軽にご参加ください。

寺田：
本日は、ありがとうございました。

※ セミナーの様子は、 Think IT 様のイベント・セミナー記事ページ でも掲載されております。
ぜひご覧ください。

]]>