Amazon Web Services ブログ
Amazon Aurora アップデート – PostgreSQL 互換のエンジン
(昨日のように思いますが)ちょうど2年前、私は Amazon Aurora を【AWS発表】Amazon Aurora – Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!! の記事にて紹介しました。この記事では、RDS チームがリレーショナルデータベースモデルを既存の制約にとらわれない新鮮な視点で考え、クラウドに適したリレーショナルデータベースをいかに作ったかを説明しました。
それ以来、私たちがお客様から受けたフィードバックは心温まるものでした。お客様は、MySQL との互換性、高可用性、組み込みの暗号化オプションを愛しています。お客様は、Aurora が、耐障害性、自己修復機能を兼ね備え、10 GB から利用開始でき、事前のプロビジョニングなしに 64 TB までスケール可能なストレージを備えているという事実を頼りにしています。そして、Aurora は 6 つのコピーが 3 つのアベイラビリティーゾーンにわたってレプリケートされ、そのデータを性能や可用性への影響なく、Amazon Simple Storage Service (S3) にバックアップされるということをお客様は把握しています。お客様のシステムがスケールする際には、共通のストレージからデータを読み込む最大 15 個の低レイテンシーリードレプリカを追加できることを把握しています。費用の観点では、Aurora はコンピューティングリソースとストレージのリソースを効率的に使用し、商用データベースと比較して、費用対性能が10倍もよくなることを理解しました。世界規模の商用環境で、どのようにお客様がAurora を使用しているかについては、Amazon Aurora のパートナー紹介とお客様の声 をご覧ください。
もちろん、お客様は常によりよいものを求め、我々もお客様の必要とするものを理解し、それを達成するために最善を尽くします。ここでは、お客様のフィードバックに応えてリリースした最近のいくつかのアップデートを振り返ります。
- 10月 – ストアードプロシジャーからLambda Functionの呼び出し
- 10月 – S3からのデータ読み込み
- 9月 – リーダーエンドポイントが追加されました – 負荷分散と高可用性向上 –
- 9月 – Parallel Read Ahead, Faster Indexing, NUMA Awareness
- 7月 – MySQLバックアップからクラスタを作成可能になりました
- 6月 – Cross-Region Read Replicaがご利用頂けるようになりました
- 5月 – アカウント間でスナップショットを共有頂けるようになりました
- 4月 – Cluster view for Amazon Aurora in RDS console
- 3月 – Amazon Auroraのリードレプリカで、フェイルオーバーの順番を指定可能になりました
- 3月 – Local Time Zone Support
- 3月 – ソウルリージョンでご利用可能に
- 2月- シドニーリージョンでご利用可能に
そして今、 PostgreSQL 互換のエンジンをご利用可能に
これらの機能レベルのフィードバックに加えて、我々はその他のデータベースとの互換性を追加してほしいという多くのリクエストをいただいていました。そのフィードバックリストのトップに上がっていたのは PostgreSQL との互換性です。このオープンソースデータベースは、20 年間にわたり継続して、開発され、多くのエンタープライズ、スタートアップ企業に採用されています。お客様は、PostgreSQL に備わる豊富な機能(SQL Server や Oracle Database でも提供されているものと同様のもの)、性能面の利点、地理情報オブジェクトを好んでいます。お客様は、Aurora が提供するすべての利点を活用しながら、喜んでこれらの機能を利用するでしょう。
本日、Amazon Aurora の PostgreSQL-compatible edition を preview にてリリースします。この preview は、高い堅牢性、高可用性、リードレプリカをすぐに作成できる機能など先にあげたすべての利点を提供します。ここには、お気に召すであろういくつかの特徴をあげます:
性能 – Aurora は、今までの環境で稼動中の PostgreSQL に比べて、2倍の性能を提供します。
互換性 – Aurora は、オープンソースデータベースの PostgreSQL (バージョン9.6.1)と互換性があります。ストアドプロシージャでは、PL/pgSQL, Perl, Tcl, JavaScript(V8 JavaScript エンジン)をサポートする予定です。我々は Amazon RDS for PostgreSQL でサポートされているすべての PostgreSQL の機能、拡張モジュールをサポートする予定です。
Cloud Native – Aurora は、AWS 内で稼動しているという事実を最大限に活用します。ここに、そのいくつかのポイントを示します。
- AWS Key Management Service (KMS) – Encryption at Rest(格納時暗号化)
- AWS Identity and Access Management (IAM) – Aurora API とリソースに対するファイングレインアクセスコントロール
- Amazon Simple Storage Service (S3) – Aurora による S3 への継続的なバックアップとそのバックアップを使った短時間でのリカバリ
- Amazon Relational Database Service (RDS) – プロビジョニング、バックアップ管理、監視、コンピュートリソースのスケーリング、データベース設定管理
- AWS Database Migration Service – オンプレミスや EC2 でホストされた PostgreSQL, Oracle DB, SQL Server からの簡単なマイグレーション
- AWS Schema Conversion Tool – マイグレーションの一端として実施される異なるデータスキーマへの簡単なコンバージョン
ここから、どのように RDS コンソールからアクセスできるかを確認しましょう。PostgreSQL Compatible option を選択することにより、開始できます:
そして、DB インスタンスクラスを選択し、Multi-AZ デプロイメントの利用有無、データベースインスタンス名を決定し、ユーザー名とパスワードを入力します:
本日、Amazon Aurora PostgreSQL-compatible edition の preview を US East (Northern Virginia) リージョンにて開始します。アクセスするためにぜひ、サインアップしてください!
クイックな比較
私の同僚である David Wein, Grant McAlister が Amazon Aurora PostgreSQL-compatible edition と PostgreSQL 9.6.1 との比較をするテストを行いました。データベースサーバは、m4.16xlarge インスタンスで稼動し、テストクライアントは c4.8xlarge インスタンスで稼動していました。
PostgreSQL は、ext4 ファイルシステムでフォーマットされた 3本の 15,000 IOPS の EBS ボリュームを 1 つの論理的なボリュームにストライピングさせ、45,000 Provisioned IOPS のストレージを使って稼動していました。そして、彼らがテストしたワークロード上で PostgreSQL の性能を向上させた WAL 圧縮と積極的な autovacuum を可能にしています。
David と Grant は、PostgreSQL のベンチマークツールである pgbench を利用しました。彼らは、30 GiB のデータベースを作成し、いくつかの異なるクライアント数を利用する 2,000 の scaling factor を使いました。各データポイントは、1時間試行され、各試行ごとにデータベースは再作成されてました。その結果は下記のグラフの通りです。
David は、彼の試行の最後の1回の結果も共有してくれました:
Bash
progress: 3597.0 s, 39048.4 tps, lat 26.075 ms stddev 9.883
progress: 3598.0 s, 38047.7 tps, lat 26.959 ms stddev 10.197
progress: 3599.0 s, 38111.1 tps, lat 27.009 ms stddev 10.257
progress: 3600.0 s, 34371.7 tps, lat 29.363 ms stddev 14.468
transaction type:
scaling factor: 2000
query mode: prepared
number of clients: 1024
number of threads: 1024
duration: 3600 s
number of transactions actually processed: 137508938
latency average = 26.800 ms
latency stddev = 19.222 ms
tps = 38192.805529 (including connections establishing)
tps = 38201.099738 (excluding connections establishing)
彼らは、同様の試行の最後40分に関してのスループット(TPS)をグラフにして共有してくれました。
ご覧の通り、Amazon Aurora は PostgreSQL よりも高いスループットを提供し、ジッタ(結果のばらつき)も 1/3 程度となっています(それぞれの標準偏差は、1395 TPS および 5081 TPS です)。
David, Grant は、2017 年の初めに予定している、より詳細な投稿のためにデータを集めています。
Coming Soon – Performance Insights
我々は、データベース性能をとても詳細なレベルで理解することをサポートできるよう設計された新しいツールについても開発しています。お客様は、各クエリの詳細を確認し、データベースがどのようにそのクエリを扱ったのかを確認できます。ここには、preview のスクリーンショットを先出しします:
preview の一部として、この新しい Performance Insights にもアクセスできます。後ほど、こちらの詳細に関してお知らせしたいと思います。
— Jeff;(翻訳は SA 江川が担当しました。原文はこちらです。)