ベアメタルサーバーでPostgreSQLを超高速化するには？
ITインフラにおける仮想化は過去15年にわたって非常に普及していましたが、高いパフォーマンスの維持、ハードウェアのロックイン、または単にレガシーシステムを踏襲するために、物理サーバー（ベアメタル）にLinuxをインストールして動作させるクリティカルなアプリケーション環境は多々見受けられます。また、SANベースのストレージアレイからHCIへの移行は間違いなく進んできています。かと言ってHCIは仮想環境を前提にデザインされていますので、このようなベアメタル環境のアプリケーションをHCIで動作させることは考慮されていないはずです。
ベアメタル環境で動作させているアプリケーションの一つにオープンソースRDBであるPostgreSQLがあります。PostgreSQLは、「DB-Enginges」によると、グローバルで稼働するRDBのシェアで4位にランクされています。これらのRDBはベアメタルのLinuxホストで実行されているケースが多くあります。
一般的なHCIでは、このようなLinuxのベアメタルサーバーでPostgreSQLを稼働させるという使い方はできません。ですが、Datriumであれば、同じプール内でVMware、KVM、Docker、そしてベアメタルサーバーを混在させることができます。しかも、アプリケーションは物理サーバーごとに分けることで、お互いの負荷を気にせずに運用させることができます。それでいて、混在環境をひとつの管理画面で運用することができますので、HCIを使う最大のメリットである運用負荷の軽減ができるのです。
いくつかのHCIソリューションは、ベアメタルホスト上で実行されているアプリケーションのNFSまたはISCSIターゲットを提供するものもあります。ただ、ローカルに接続されたFlashまたはNVMeデバイスに全てのデータを保存しているわけではなく、せっかくベアメタルで動かしていても期待通りの性能を出せるわけではないようです。これは従来の3層SANアーキテクチャと変わらず、複雑さを増し、多くの場合は重複除外、圧縮、暗号化をフルにサポートしていないことがあります。
Datriumの場合では、仮想化であってもベアメタルであっても同じアーキテクチャと機能をサポートします。Linuxホストにハイパードライバを導入することで、データローカリティ、重複排除、圧縮、イレイジャーコーディング、暗号化、ファイルレベルのスナップショット、リストア、複製、クラウドバックアップ、クラウドDRなどの機能を使うことができるようになります。また、DatriumのGUIはvCenterプレグインでもスタンドアロンでも使用できるので、vCenterのGUIからベアメタルサーバーの情報も参照できるようになりました。
ここで、米国デイトリウム社が行った、ベアメタルでのパフォーマンス検証結果についてご紹介します。Datriumを使った環境において、PostgreSQLがベアメタルのLinuxホスト上でどのように動作し、仮想化との違いについて比較してみたいと思います。テスト環境は、ほぼ同じサーバーのスペックでPGBENCHのテストパラメータも同じにしました。ベアメタルの優位点としては、全てのハードウェア性能をオーバーヘッド無くフルに使えるということです。
以下がパフォーマンス結果になります。
表の読み方ですが、一番上が今回のベアメタルでのPostgreSQL結果です。3万6千TPSと書き込みレイテンシー0.6msを達成しました。
そして、2番め以降は仮想環境でのPostgreSQL結果です。Datirumのバージョンの新しい順に並んでいます。2番めはDBのチューニングを行っています。
ベアメタルの性能値（仮想環境との比較）は以下のようになりました。
- 1秒あたりのトランザクション（TPS） が２倍近くに増加
- 平均読み出しのレイテンシーが0.3msから0.5msに増加
- 平均アプリケーション書き込みレイテンシーが3.9msから0.6msに減少
- 仮想化ベンチマークではE5-2698 v3 @ 2.30GHzを使用し、ベアメタルではE5-2680 v4 @ 2.4GHzを使用していました。これは新しいCPUですが、cpuboss.comによると、古いプロセッサは新しいプロセッサよりも高性能です。（参照）
- テストでは、16のvCPUと1GB RAMを割り当てましたが、今回のベアメタルテストでは全てのホストリソースが利用可能です。CPUのコア数は14個でRAMは256GBです。実際確認したところ、ベアメタルでのCPU使用率は40%以下にとどまりました。
- 上記のように、サーバー上のメモリ容量が異なりますので、これがレイテンシー減少に起因している可能性があります。ただし、Datriumのアーキテクチャーの場合、書き込み性能はData Node側に依存しますので、そこが直接の原因ではなくベアメタルでのボトルネックがなくなった環境が効果的に機能したと思っています。
以下はRHELのpgbench結果のスクリーンショットです：
結論
Datriumのベアメタルサポートによって、企業が求めるDBの性能を最大限に発揮する環境をHCIで提供できるようになりました。また、これまで3層アーキテクチャーとHCIで用途を分けて使っていたような環境を、DatriumのHCIではひとつに纏めてしまって全く問題ないことがお分かりになると思います。
ちなみに、小さいデータセットで異なるクライアント数とスレッド数に変更して同じPGBENCHを実行したこところ、8万9千TPSを出すことができました。すべてのキャッシュをローカルでヒットさせるDatirumのアーキテクチャーがうまくDBの動きと機能しているので、機会があれば検証機で試してみてください。日本国内でも検証機を貸し出すことができます。
