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を用いワンクリックでバックアップ／リカバリー、あるいはコマンドによる一括でのバックアップ／リカバリーの機能は実装済みだ。
