PostgreSQLのエンジンにミッションクリティカルで培ったSymfowareの技術をプラス
そんな中、「PostgreSQLとSymfowareの融合 ―Open I/F はじめました―」というタイトルで講演したのが、富士通株式会社の秀嶋元才氏だ。これは、オープンソースのPostgreSQLと同社の商用データベースであるSymfowareをどう融合させたのか、融合させた結果どんなメリットが生まれたのかを紹介するセッション。商用とオープンソースのハイブリッドで、オープンソースの良さを活かしつつ商用ならではのメリットを加える。そのハイブリッドデータベースの実体について、解説が行われた。
「今、なぜオープンソースのデータベースの活用が増えているのでしょうか。1つには、顧客が特定ベンダーへの依存を嫌う傾向が出てきているのだと思います。たとえば、商用データベースの利用で、パッケージが限定されることを嫌う顧客が最近は増えているのです」
秀嶋氏は、オープンソースのデータベースを利用する波が、いまデータベース市場にはあると指摘する。商用データベースには各社固有のSQLがある。このため、パッケージが対応できるデータベースが限定され、使いたいパッケージ製品が選択しにくい。あるいは、データベースベンダーの都合でバージョンアップなどを強いられるが、利用しているパッケージはそれに追随しない。そのような状況を嫌い、オープンソースデータベースを選ぶことで業務に適した／使いたいパッケージなど様々なパッケージから選択できる、選択肢を広げるという動きがあるのだ。
このオープンソースデータベース利用の拡大という波に乗るために、富士通は新たな方策をとっている。それが、PostgreSQLに対して、富士通が長年ミッションクリティカル領域で実績を積んできたSymfowareの技術で信頼性や運用性を強化するというものだ。PostgreSQLのオープンなインターフェースにより、顧客はSymfowareだけでなく、純粋なPostgreSQLや、さらには他のPostgreSQLの商用ディストリビューションのパッケージをも選択できるようになる。つまりPostgreSQLエンジンのオープンなインターフェースが、アプリケーションの選択肢の幅を広げるのだ。
PostgreSQLを選んだ理由
では、オープンソースの中でもなぜPostgreSQLを、富士通は選んだのか。1つには、長年にわたりPostgreSQLを活用、利用してきたノウハウが同社にあったことだと秀嶋氏は言う。さらに、MySQLのようなベンダーコントロールのオープンソース製品よりも、コミュニティがしっかりと独立していて、先行きが見通しやすいのも選択の理由だった。
「サポート、信頼性、性能という3つが同等に必要です」と秀嶋氏。これらがすべて揃っていれば、ミッションクリティカルな領域でも使える。PostgreSQL I/Fの下に位置するデータベースエンジン部分を、ミッションクリティカルで培ったSymfowarの技術をプラスして強化することで、このサポート、信頼性、性能という3つの条件を満たせるというわけだ。それではミッションクリティカルでも通用するために富士通はどういったことを行ったのか―「3つの条件」があるが、ここではそのうちの一つ、「信頼性」に焦点を当てて説明が行われた。
実際に信頼性を向上するためには、いったいどんなことを行ったのか。1つが、WAL(Write Ahead Log：ログ先行書き込み)の二重化、さらにページチェックサム、透過的データ暗号化という3つの機能で、オリジナルのPostgreSQLにはない信頼性の大幅な向上を成し遂げている。
まずは、WALの二重化だが「オリジナルのPostgreSQLだと、ログの書き込み先のディスク障害などでWALがロストすることがあります。その場合は、結果的にユーザーの業務データをロスすることにもなりかねません」と秀嶋氏。その対策のために、WALの二重化を行った。二重化のために専用のプロセスを加え、それを使って並列に別のディスクにWALを書き出す。別プロセスなので、本体のデータベース処理への影響もほとんど発生しない。
また、ページチェックサム機能については、PostgreSQL 9.3からは本体機能として実装されるようになったが、富士通ではそれ以前からこれを実装している。
「たしかに9.3でチェックサム機能は実装されましたが、オーバーヘッドがかなり大きいものです。そりゃチェックサムのために8Kものサイズに対し演算していたら、それはオーバーヘッドがかなりありますよね、という話です」（秀嶋氏）
これに対し富士通の仕組みでは、ディスクにページを書き出す際、各セクタの一部のデータを使って、独自の方法でチェックサム値を計算し、ページ・ヘッダに記録する。ディスクからページを読み込んだときは、同じ方法でチェックサム値を計算し、ページ・ヘッダに記録した値と照合する。
「この考え方は、Symfowareでずっと行ってきている方法です。データ破損が起こるときは、だいたいセクタの内容全体が破損します。ですので、各セクタの一部のデータを検査しておけば、破損はほぼ間違いなく見つけられるのです。これは、富士通の長年の経験によるものです」（秀嶋氏）
考え方としては、100％の検知率ではなくてもほぼ問題なく破壊を見つけられる範囲にあるということ。これにより、性能は殺さずに極力障害を見つけられるわけだ。このあたりの性能とのバランス加減も、ミッションクリティカル領域での運用では重要なポイントだと言えるだろう。
もう1つの信頼性向上のための透過的データ暗号化でも、性能とのバランスをうまくとっている。現状のPostgreSQLでは、列を指定し暗号化を行うことができる。この方法では、結局は既存のSQLを変えないとうまくアプリケーションは動かない。さらに、SQLの単位で暗号化、複合をやることになり、そのオーバーヘッドもかなり大きくなってしまう。
この対策として富士通がとった方法は、物理媒体に書くとき、読むときにだけデータを暗号化、復号し、アプリケーションの変更を不要にしたのだ。また、必要なものだけを暗号化することでオーバーヘッドを小さくした。これにより、データファイルが暗号化されるので、仮にそれを盗まれても情報が漏洩する心配はない。さらに、この暗号化、複合の処理にIntel Xeonチップの暗号化処理機能を活用する点も性能改善に大きく寄与する。暗号化のところは、チップに任せることでかなり高速化するという。
これら暗号化、複合の処理については、すべてSymfowareのデータベースエンジン側で管理する。なので、アプリケーション側では、暗号化、複合を意識する必要はない。キー管理もデータベースで行うので、手間もほとんどかからない。
暗号化の実装としては、OpenSSLを採用している。そして、具体的にはユーザーデータを含む主フォークを暗号化している。
「結果的にWALも暗号化しているので、レプリケーションの際にデータをそのまま流しても、通信網が暗号化されていなくても途中で情報漏洩する心配はありません」（秀嶋氏）
暗号化キーも2段階に保護されており、テーブル空間ごとに暗号化キーを用意し、暗号化方式はAES-256を採用することで、ミッションクリティカルでも通用するように安全性を確保している。
この暗号化機能の検証を行っており、Xeonチップの暗号化機能を活用することで、かなり高速に処理できるとの結果も出ている。とくにバッチ処理、あるいはインデックス作成を含むロードなど負荷の高い処理において、Xeonの機能を利用することでかなり性能が向上することが明らかになっている。
この他にも、オリジナルのPostgreSQLにはない機能を追加する予定があるとのこと。たとえば、NCHAR拡張を行っており、これについてはオープンソースのほうにフィードバックできないかとも考えていると秀嶋氏。すでに、GUIを用いワンクリックでバックアップ／リカバリー、あるいはコマンドによる一括でのバックアップ／リカバリーの機能は実装済みだ。
富士通ハードウェアとの組み合わせで即日利用できるアプライアンスに
秀嶋氏
このPostgreSQLのエンジンにミッションクリティカルで培ったSymfowareの技術をプラスしたデータベースは、ハードウェアと組み合わせたアプライアンスとしても提供されている。その製品が「FUJITSU Integrated System HA Database Ready」というもの。
「買えば即日利用できるというのがコンセプトです。チューニングは不要です」（秀嶋氏）
特長的なのが、何らかのハードウェア障害があった際にも、ハードウェアの修理を行えばあとはほぼ自動で修復される自動リカバリーの機能があること。このアプライアンスには、2台のデータベースサーバーと、1台のRAID構成のバックアップストレージがある。サーバー1と2は、同期レプリケーションで冗長化している。さらに、データベースの設定情報、ネットワーク情報なども定期的にバックアップストレージに格納されるようになっている。なので、何らかの障害が発生しても、このアプライアンスだけで復旧ができるというわけだ。
たとえば、プライマリーのサーバー1が壊れた際には、サーバー2に切り替わる。
「切り替え時間は、アベレージで10秒くらい。業務停止に影響のない範囲での切替が可能です。アプリケーション側ではとくにこの切り替えは意識する必要はなく、リトライすれば自動的にサーバー2に接続するようになる。アプリケーションの設定で、ドライバーを呼んでくれればそれでOKです」（秀嶋氏）
実際にこのアプライアンスの構成では、
・データベースの片方が壊れる
・データベースが両方壊れる
・バックアップストレージが壊れる
・データベースが片方＋バックアップストレージが壊れる
の4つしか故障パターンはない。というのも、このアプライアンス製品ではこの4つの故障パターン／復旧パターンしか起きないように集約、性能や構成の最適化を行ったからだ。だから簡単な操作で復旧ができる。こうした仕組みが入っているため、アプリ側は何も意識しないで構わない。データベースが片方壊れた場合には、別のデータベースでトランザクションを継続し、壊れたサーバーを復旧させる。そして、まずは非同期で処理を同期させ、ログが追いついた段階で通常運用の同期に切り替える手順となる。アプリケーションへの負荷を減らすために、非同期から同期へと変更する手順をとっているというわけだ。
両方のデータベースが壊れた場合には、バックアップストレージからまずはプライマリーサーバーを復旧し、あとは片方のデータベースが壊れたのと同じ手順となる。また、バックアップストレージが壊れた場合には、プライマリーサーバーからバックアップを戻す。
ハードウェアを復旧させた段階で、管理者はGUIに入ってリカバリーのボタンをクリックするだけで、内部的に障害の状況を判断し自動で一連のデータベース復旧の手順が実行される。この自動復旧も、ミッションクリティカルでも利用できる手間のかからない、業務無停止で復旧できるアプライアンスの大きな特長だという。
PostgreSQLを使うことでオープンソースデータベースのメリットを得たい。とはいえ、ミッションクリティカルの領域で使うとなると足りないところがあるのが現実。それをオリジナルのPostgreSQLに手を入れたり、アプリケーション側で工夫したりで対策するのではなく、エンジン部分をミッションクリティカルで実績のあるSymfowareに取り替えてしまう。このようなソフトウェア同士の融合ができるのもオープンソースならではであり、データベースエンジニアにとっても技術的に興味深いポイントだろう。今後さらに、このような融合による新たなメリットというものに、おおいに期待したい。
▼関連URL
・FUJITSU Software Symfoware
・FUJITSU Integrated System HA Database Ready
