パフォーマンスではAuroraに軍配!? SRA OSS石井達夫氏がPostgreSQL版Auroraを徹底検証

2016年11月、米ラスベガスで開催されたAmazon Web Services(AWS)の年次カンファレンス「AWS re:Invent 2016」の初日、Amazonのアンディ・ジャシーCEOから発表されたいくつものアップデートの中でもとりわけ開発者を熱狂させた発表が、"Amazon Aurora PostgreSQL with Compatibility" ―AWSが誇るクラウドネイティブなデータベースエンジン「Amazon Aurora」にPostgreSQL互換バージョンがプレビューで提供されるというニュースでした。

「AWS reInvent 2016」でプレビュー版として発表されたPostgreSQL互換のAurora。AWSはユーザの要望にもとづいて機能拡張を行うが、PostgreSQLへの強いニーズがあったことがうかがえる。
「AWS reInvent 2016」でプレビュー版として発表されたPostgreSQL互換のAurora。AWSはユーザの要望にもとづいて機能拡張を行うが、PostgreSQLへの強いニーズがあったことがうかがえる。

2014年のre:Inventで発表されて以来、Auroraのスケーラビリティとパフォーマンスを評価するユーザは後を絶たず、数あるAWSのサービスの中でももっとも成長スピードが速いサービスとして知られています。そのAuroraに従来のMySQL互換バージョンに加え、プレビューとはいえPostgreSQLバージョンが追加されたことでAuroraの裾野はますます拡がりを見せています。

この"PostgreSQL版Aurora"に、アナウンス直後から強い関心を寄せてきたのがSRA OSS, Inc. 日本支社 取締役支社長 石井達夫氏です。現役のPostgreSQLコミッタであり、国内のPostgreSQLコミュニティに草創期からかかわってきた、文字通り日本を代表するPostgreSQLエキスパートの石井ですが、既存のRDBとはまったく異なる設計思想であるAuroraエンジンを実装したPostgreSQLにどんなインパクトを受けたのでしょうか。本稿では7月5日に東京・大崎で開催された「AWS Solution Days 2017 ~ AWS DB Day ~」のキーノートで石井氏が発表した「Amazon Aurora for PostgreSQL Compatibilityを評価して」のプレゼン内容から、クラウドデータベースの新たな可能性を拓こうとしているPostgreSQL版Auroraのパワーに迫ってみたいと思います。

「AWS Solution Days 2017」の壇上に立つSRA OSS, Inc.日本支社 石井達夫氏
「AWS Solution Days 2017」の壇上に立つSRA OSS, Inc.日本支社 石井達夫氏

PostgreSQL版Auroraとは何か?

もともとPostgreSQLはクラウドやAuroraが普及するかなり前から商用データベース、とくにOracle Databaseからの移行先としてつねに注目されてきたシステムです。⁠もっともOracleから移行しやすいOSSデータベースとしての評価が根付いている」という石井氏の言葉通り、OracleからPostgreSQLへの移行事例は国内外でも枚挙に暇がありません。その理由として、石井氏は以下の3点を挙げています。

  • (OracleとPostgreSQLが)機能的に似ている
  • 複雑なクエリやジョインも問題なく実行できる
  • 信頼性が高い

とくにPostgreSQLは同じオープンソースのデータベースであるMySQLと比較しても機能が豊富である点が高く評価されている点は周知のとおりです。この秋にはロジカルレプリケーションやネイティブパーティショニングを実装したメジャーアップデート「PostgreSQL 10.0」のリリースが予定されており、ユーザの間でも期待が高まっています。

一方、従来のRDBとは異なり、分散処理とスケールアウト、そして障害時の自動復旧に徹底的にフォーカスしたAmazon Auroraは、クラウドネイティブなアプリケーションが世に増えるにともない、劇的なスピードでそのユーザ数を伸ばしています。現在プレビュー版として公開されているPostgreSQL版AuroraではPostgreSQL 9.6をベースにしており、クラウドに最適化されたAmazon Auroraストレージを利用することが可能です。PostgreSQLと100%互換ではあるものの、パフォーマンス、可用性、堅牢性、リードレプリカといった部分でオリジナルのPostgreSQLを大きく凌ぐとされています。

石井氏はオリジナルのPostgreSQLとPostgreSQL版Auroraを比較して「Auroraはデータベースエンジン部分はまったくPostgreSQLからいじっていない。だがリードレプリカを独自実装しており、PostgreSQLのストリーミングレプリケーションは使っていないと聞いている」と説明しています。

PostgreSQLとAuroraの比較
PostgreSQLとAuroraの比較

石井氏がPostgreSQL版Auroraが登場した際、もっとも注目したのは「Write性能がオリジナルのPostgreSQLに比べて飛躍的に向上している」という部分だったそうです。その理由として石井氏は「Read性能を向上させる技術(スケールアウト、パラレルクエリなど)はすでに存在している。だがWrite性能の向上は難しい。なぜならアプリケーションレベルのシャーディングでWrite性能の向上は可能だが、アプリケーションの変更が必要になってしまう。これまでWrite性能の向上に関しては多くの試みがなされてきたが、まだ決定的なものはない状態」と説明しています。

しかしPostgreSQL版Auroraを試したユーザから「Auroraに乗り換えるだけでWrite性能が向上する」という声が徐々に聞こえてくるようになりました。PostgreSQLの第一人者である石井氏が「そんなうまい話が本当にあるなら、これはぜひ検証してみなければ!」と思い立ったのも当然でしょう。さっそくSRA OSS Inc.としても検証作業に乗り出すこととなりました。

性能面ではAuroraが圧倒

SRA OSS Inc.で用意した検証環境のインスタンスは以下のとおりです。

Amazon RDS for PostgreSQL
db.r3.8xlarge/vCPU 32/メモリ244GB/Provisioned IO(IOPS: 10000)
Amazon Aurora with PostgreSQL Compatibility
db.r3.8xlarge/vCPU 32/メモリ244GB
pgbench(ベンチマークツール)
Amazon EC2 m4.10xlarge/vCPU 40/メモリ160GB
検証環境
検証環境

検証用トランザクションの内容は

  • 同時接続数を250→500→750→1000と変化させ、それぞれ1時間トランザクションを流し、実行できたトランザクション数を性能の指標とする
  • 検証用テーブルは最大で2億行、データベースサイズは30GB
  • 1つのトランザクションでSELECTを1回、UPDATEを3回、INSERTを1回実行する

となっています。さて、その結果はどう出たのでしょうか。

初期データロード時間
Auroraのほうがはるかに短く、とくにRDSに比較してVACUUM時間が大幅に短縮されているのがわかります。
初期データロード時間
初期データロード時間
スループット
同時接続数が増えても、Auroraは高いレベルを保っていますが、RDSは逆に同時接続数が増えるにしたがい、トランザクション処理性能が下がっています。CPU利用率はAuroraのほうが高く、RDSでは「ロック待ちがボトルネックになっている可能性がある」と石井氏。またAuroraは大きなサイズで書き込みができるので、RDSに比べてIOPSが少なくなっています。
スループット比較
スループット比較
応答時間(レイテンシ)
250同時接続で1分間の推移を検証したところ、Auroraのレスポンスは非常に安定しており、レイテンシはほぼ20ms以下です。一方でRDSのほうはばらつきが多い結果となっています。
応答時間比較
応答時間比較

これらの結果を総合して石井氏は「Auroraのほうが全体的に性能が高いと言わざるを得ない。データロード時間は1/3でスループットは3倍。レイテンシも短く、ばらつきが少ない。加えて同時接続数が増えても性能の劣化が少ない」とAuroraの性能を高く評価しています。Auroraに移行するだけで性能向上が実現するのはどうやら本当だったようです(なお、Auroraはレイテンシのゆらぎに強い「read/writeクォーラムシステム」を採用しています⁠⁠。

Aurora版PostgreSQLは万能か?

性能面では全面的にAurora版PostgreSQLに軍配が上がったものの、だからといって世の中のすべてのPostgreSQLがAuroraに移行するほうがよいのか、というと話は別で、石井氏はセッション後に「管理者権限やコストの面から、やはり適材適所の使い分けが求められるのは変わらない」とコメントしています。

前述したようにAuroraは読み出し専用のレプリカであるリードレプリカを独自実装しています。RDSでもリードレプリカは実装されていますが、Auroraでは3つのAZ(アベイラビリティゾーン)をまたいで最大15までのリードレプリカを作成することができます。また、Auroraでは従来のシャーディング、シェアードナッシング、シェアードディスクといったモノリシックなストレージ共有のアーキテクチャに縛られることなくデータベースをスケールすることを掲げており、すべてのマスターとスレーブでストレージ(最大64TB)を共有するしくみを採用しています。つまり、いったんマスターが書き込みを行うと、すべてのスレーブ間で同時に共有されるため、レプリカラグ(レプリケーション後に読み出し可能となるまでのレイテンシ)「数ミリ秒程度」⁠AWS関係者)に抑えられています。

このようにAuroraの性能向上に大きく貢献しているリードレプリカですが、石井氏は「だからといってどんなクエリでもリードレプリカに投げて良いわけではなく、その識別をアプリケーション側で行うのはかなり煩雑」と指摘します。

リードレプリカの利用に注意
リードレプリカの利用に注意

石井氏はここで、SRA OSS Inc.が中心となって開発しているオープンソースのミドルウェア「Pgpool-II」を紹介しています。Pgpool-IIはもともと石井氏が開発したオープンソースで、フェイルオーバー管理やノードの追加/削除などPostgreSQLに関するさまざまな管理を行うことができますが、リードレプリカへの負荷分散管理も可能となっています。

Pgpool-IIの負荷分散機能
Pgpool-IIの負荷分散機能

Pgpool-IIは現在、オリジナルのPostgreSQL(ストリーミングレプリケーション)とAmazon RDS for PostgreSQLに対応していますが、Aurora版PostgreSQLについてはまだサポートしていません。石井氏は「Auroraに対応することは技術的に難しくないが、ユーザの要望がない機能強化を行っても意味がない」として、キーノートの終盤、会場の聴衆に向かって「Pgpool-IIのAuroraサポートを希望する方、挙手を!」と呼びかけたところ、約400名の参加者のうち半分くらいが手を挙げていました。⁠とても勇気づけられる反響なので、SRA OSS Inc.としてもAuroraのサポートに前向きに取り組んでいきたい」とのこと。東京リージョンでPostgreSQL版Auroraの一般提供(GA)が開始されるころには、同時にPgpool-IIも使えるようになっている可能性もありそうです。


複数の機能レイヤが1つのモノリシックなスタックに含まれているトラディショナルなリレーショナルデータベースでは、クラウド時代に適したスケールは難しい ―前述したように、Auroraはスケールと分散処理、そして自動化に徹底的にこだわったクラウドネイティブなデータベースとして誕生しました。オープンソースのデータベースへのニーズがますます高まる昨今、機能が豊富で対応言語も多いPostgreSQLにAuroraがフォーカスするのもごく自然な流れだといえます。今秋リリースされるPostgvreSQL 10.0を受けて、Auroraもまた進化を遂げていくことでしょう。そう考えると、Auroraはオープンソースプロジェクトとクラウドベンダの新しいかたちの関係性を象徴するプロダクトなのかもしれません。

おすすめ記事

記事・ニュース一覧