GTM-MML4VXJ
Skip to main content
  1. ホーム >
  2. 製品 >
  3. ソフトウェア >
  4. ライブラリー >
  5. 特集 >
  6. WALが損失するという課題の解決(2/2)

富士通の技術者に聞く!PostgreSQL最新技術
WALが損失するという課題の解決(2/2)
PostgreSQLインサイド

富士通の技術者に聞く!PostgreSQL最新技術WALが損失するという課題の解決(2/2)

前へ

  • 1
  • 2

WALの二重化機能によるオーバーヘッドの影響は?

―前編で伺ったWALの二重化機能についてですが、同じデータを二ヶ所に書き込みすると性能への影響が気になります。性能とはトレードオフとなってしまうのでしょうか?

綱川

いいえ、性能も大事にしました。WALの二重化機能によるオーバーヘッドは2%くらいです。
実際にpgbenchを使った更新の多いOLTPベンチマークを実行して計測したところ、WALの二重化機能ありの場合となしの場合でトランザクションのスループット差が2%ほどでした。この結果より、オーバーヘッドに関しては影響をほぼ考慮しなくて良いレベルになっていると思います。

―どのようにしてオーバーヘッドを抑えたのでしょうか?

綱川

WALの二重化機能では、WALと二重化されたWAL(これを便宜上「二重化WAL」と呼びます)に対して並列にデータを書き込むことでオーバーヘッドを抑えています。PostgreSQLでは、データベースを更新する各サーバプロセスがWALに更新ログを書き込むのですが、ここに二重化WALに書き込むための専用サーバプロセスである「ログ多重化プロセス」を用意しました。ログ多重化プロセスはサーバインスタンスごとに1つ存在し、データベースの起動・停止にあわせて起動・停止します。

―ログ多重化プロセスですか。もう少し詳しく教えてください。

綱川

はい。私たちが開発したWALの二重化機能では、サーバプロセスがWALに更新ログを書き込む際に、まずログ多重化プロセスに対し二重化WALへのログ書き込みを指示します。その後サーバプロセスは通常どおりWALへのログ書き込みを実施します。このときにログ多重化プロセスも同時に二重化WALへの書き込みを実施します。
サーバプロセスは自分自身の書き込み完了とログ多重化プロセスからの書き込み完了報告を待ち合わせます。サーバプロセスは両方の書き込み完了報告を受けて本来の“ログ書き込み完了”となるのです。
つまりログ多重化プロセスへの依頼と完了報告応答のやりとりが2%のオーバーヘッドになっているということです。

ログ多重化プロセスの概要図

【ログ多重化プロセスの概要図】

開発の苦労話について

―二重化WALに書き込む専用のプロセスが存在しているのですね。性能についてとても気を使っているのが伝わってきますが実際の開発で苦労されたことはありますか?

綱川

当社ではPostgreSQLを搭載したデータベースの垂直統合製品として「PRIMEFLEX for HA Database」というハードウェアアプライアンスを提供しているのですが、性能のオーバーヘッドを抑えることにとても苦労しました。

―さきほどWALの二重化機能にはほとんどオーバーヘッドがないというお話でしたが・・・どういうことでしょうか?

綱川

従来のサーバではWALなどのファイルがハードディスクに格納されます。WALを配置したハードディスクと二重化WALを配置したハードディスクの性能は同等ですので問題なかったのです。
ところがPRIMEFLEX for HA Databaseではフラッシュメモリを搭載しているため、ディスク性能の関係が逆転してしまったのです。

―ディスク性能の関係が逆転・・・・ですか?

綱川

はい、PRIMEFLEX for HA Databaseは、1つのユニットが2台のサーバとそれに接続される1つのETERNUSディスクアレイで構成されています。各サーバにはPCIeバス直結の高速なフラッシュメモリが搭載されており、そこにデータベースやWALが配置されます。一方ETERNUSディスクアレイにはハードディスクが搭載されています。いくらETERNUSディスクアレイに搭載されているハードディスクがエンタープライズ用途の高性能なものであると言ってもフラッシュメモリと比較するとデータの読み書き速度は劣ります。

―高速なフラッシュメモリにWALを書き込み、それに比べて低速なハードディスクに二重化WALを書き込むのですね。

綱川

そうです。
単純にWALと二重化WALを並列に書き込みすると、フラッシュメモリの方が先に完了してしまい、ハードディスクの性能に引きずられるログ多重化プロセスの書き込みが遅くなります。そうすると、サーバプロセスはログ多重化プロセスからの書き込み完了報告を待つ状態が発生してしまいます。これではフラッシュメモリの高性能を活かせません。
PRIMEFLEX for HA Databaseにとって、性能は非常に重要な要素ですので何らかの割り切り策が必要でした。そこで「高速WAL二重化モード」を新たに用意しました。
このモードでは二重化WALへの複数の書き込みを束ねてしまいます。こうすることで二重化WALへの書き込み回数を減らし、ハードディスクの性能による影響を小さくすることに成功しました。

―新たな発想で見事に課題を解決しているのですね!

綱川

いえ、そうは簡単にいかないのです。
性能を追求するトレードオフとしてWALと二重化WALとの内容が一致しない“すきま時間”がわずかに生じてしまうという問題が発生しました。しかし、この問題はすぐに解決できました。
実はPRIMEFLEX for HA Database 上の2台のサーバは同期レプリケーションによって常に連携しています。そのため、もしプライマリサーバが故障しても、スタンバイサーバ側にすべてのWALが存在しているので通常のトラブルではトランザクションは失われません。すきま時間が問題になりうるのは両方のサーバが同時に故障してしまったときのみです。しかし、物事に絶対はないので両方のサーバが同時に故障してしまった場合も考えていかねばなりません。

―ということは今後も更なる改良を重ねるのですね?

綱川

はい、もちろんです。
将来はこのようなトレードオフがなくなるよう、PRIMEFLEX for HA Database 上のETERNUSにもフラッシュメモリを搭載したり、フラッシュメモリと同等の性能を発揮するように多数のハードディスクでRAID構成を組むなど性能を追求できたらと思います。

―ソフトウェアに閉じないハードウェアと一体化したPostgreSQLのミッションクリティカル性をさらに追求していくのですね。今後の進化が楽しみです。

前へ

  • 1
  • 2

技術者からのコメント

富士通株式会社
ミドルウェア事業本部 データマネジメント・ミドルウェア事業部
綱川 貴之

入社以来、永年に渡り、データベース管理システム(Symfoware、PowerGres Plus、Interstage Shunsaku)の開発・保守・サポートに従事してきました。 また、富士通の各種ミドルウェアで利用されるPostgreSQLの技術サポートも単独で担当し、PostgreSQLカンファレンスで講演したり、社内の教育講座で講師を務めたりもしてきました。
私はオープンソース・コミュニティの力を強く信じています。オープンなPostgreSQLとともに、Symfowareがイノベーティブな進化をしていくのを楽しみにしています。


本ページに記載された内容は、掲載日現在のものです。その後予告なしに変更されることがあります。あらかじめご了承ください。

富士通のPostgreSQLに関する情報がここに「PostgreSQL インサイド」

製品情報

本コンテンツに関するお問い合わせ

Webでのお問い合わせ

入力フォームはこちらから

当社はセキュリティ保護の観点からSSL技術を使用しております。

お電話でのお問い合わせ

富士通コンタクトライン(総合窓口)0120-933-200

受付時間 9時~17時30分
(土曜・日曜・祝日・当社指定の休業日を除く)