レポート

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

この記事を読むのに必要な時間:およそ 3 分

性能面では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はオープンソースプロジェクトとクラウドベンダの新しいかたちの関係性を象徴するプロダクトなのかもしれません。

著者プロフィール

五味明子(ごみあきこ)

IT系の出版社で編集者としてキャリアを積んだ後,2011年からフリーランスライターに。フィールドワークはオープンソースやクラウドコンピューティング,データアナリティクスなどエンタープライズITが中心。海外カンファレンス取材多め。Blog 「G3 Enterprise」やTwitter(@g3akk),Facebookで日々IT情報を発信中。

北海道札幌市出身/東京都立大学経済学部卒。

コメント

コメントの記入