Amazon Web Services ブログ
Amazon Auroraアップデート – Parallel Read Ahead, Faster Indexing, NUMA Awareness
Amazon Aurora はAWSサービスの中で最も速く成長するサービスになりました！
リレーショナルデータベースをクラウドに適したデザインにすることで(Amazon Aurora – Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!! の記事もご覧ください)、Aurora は大きなパフォーマンス改善や、64TBまでシームレスにスケールアップするストレージ、堅牢性・可用性の向上を実現しています。AuroraをMySQL互換にデザインすることによって、お客様は既存のアプリケーションの移行や新しいアプリケーションの構築を簡単に行って頂けています。
MySQL互換を保ちながら、そしてクラウドネイティブなAuroraアーキテクチャを活用することでAuroraには多くのイノベーションを加えられると考えています。
本日、3つのパフォーマンスを改善する新機能をAuroraに追加しました。それぞれの機能は、AWSをご利用の多くのお客様の一般的なワークロードでAuroraのパフォーマンスを改善するように設計されました。
Parallel Read Ahead – レンジ select、 フルテーブルスキャン、テーブル定義の変更やindex作成が最大5倍高速に
Faster Index Build – indexの作成時間が約75%短縮
NUMA-Aware Scheduling – 2つ以上のCPUが搭載されているデータベースインスタンスをご利用の場合、クエリキャッシュからの読み込みやバッファキャッシュからの読み込みが速くなり、全体的なスループットが最大10%向上
詳細をご紹介します
Parallel Read Ahead
MySQLで利用されているInnoDBストレージエンジンは行やindex keyを利用するストレージ(ディスクページ)を管理します。これはテーブルのシーケンシャルスキャンの高速化や新しく作成されたテーブルに効果的です。しかし、行が更新・作成や削除されるにつれて、ストレージがフラグメントされることによって、ページは物理的にシーケンシャルではなくなってきます。そして、スキャン性能が大きく低下します。InnoDBのLinear Read Ahead機能はページが実際に利用されるまでメモリ内で64ページまでまとめることでフラグメントに対処しています。しかし、エンタープライズスケールのワークロードでは、この機能は有効な性能向上にはなりません。
今日のアップデートでは、Auroraは多くの状況で賢くこのような状況を扱う機能をご提供します。Auroraがテーブルをスキャンする際に、論理的に判断し、並列で追加のページをプリフェッチします。この並列プリフェッチはAuroraのレプリケーションが行われているストレージ(3つアベイラビリティゾーンにそれぞれ2つずつのコピー)で優位性を発揮し、データベースキャッシュ中のページがスキャンオペレーションに関連しているかを判断するのに役立ちます。
結果として、レンジselect、フルテーブルスキャン、ALTER TABLE そして、index作成を以前のバージョンと比較して最大5倍高速に行えるようになりました。
Aurora 1.7(詳細はこの後の情報をご覧ください)にアップグレードすることで、すぐにこのパフォーマンス改善をご体験頂けます。
Faster Index Build
プライマリー、セカンダリーインデックスをテーブルに作成する時、ストレージエンジンは新しいキーを含んだ木構造を作成します。この処理は、多くのトップダウンのツリーサーチや、より多くのキーの増加に対応するためにツリーの再構築によりページ分割が伴います。
Auroraはボトムアップ戦略でツリーを構築します。リーフを最初に作成し、必要な親ページを追加していきます。この機能によりストレージ内の移動を軽減し、加えて各ページが一旦全て埋まるためページを分割する必要がなくなります。
この変更により、テーブルのスキーマによりますがindexの追加やテーブルの再構築が最大4倍高速になります。例として、Auroraチームが以下の様なスキーマでテーブルを作成し100億行を追加し5GBののテーブルを作製しました:
create table test01 (id int not null auto_increment primary key, i int, j int, k int);
そして4つのindexを追加しました
alter table test01 add index (i), add index (j), add index (k), add index comp_idx(i, j, k);
db.r3.largeインスタンスで、このクエリの実行時間が67分から25分になりました。db.r3.8xlargeでは、29分から11.5分に短縮されました。
これは新機能でプロダクション環境以外でのテストをお勧めします。利用するには、Aurora 1.7へアップグレードを行ない DB Instance Parameter group(詳細は DB Cluster and DB Instance Parametersをご覧ください)でaurora_lab_modeを1に設定します。
Auroraチームはこのパフォーマンス改善に対するみなさまからのフィードバックを楽しみにしています。お気軽にAmazon RDS Forumへ投稿をお願いします。
NUMA-Aware Scheduling
最も大きいデータベースインスタンス(db.r3.8xlarge) は2つのCPUを搭載しNUMA(Non-Uniform Memory Access)と呼ばれる機能を持っています。このタイプのシステムでは、メインメモリの各区画は各CPUに直接効率的にアクセス出来ます。残りのメモリは少し非効率なCPU間のアクセス経路を介してアクセスします。
Auroraはこの不均等なアクセス時間を活用するためにスケジューリングスレッドのjobを効率的に扱うことが可能になりました。スレッドは他のCPUに接続されている非効率なメモリへのアクセスを気にする必要がありません。結果として、クエリキャッシュやバッファキャッシュを大量に利用する様なCPUバウンドな操作で最大10%性能が向上しました。パフォーマンス向上は同じデータベースインスタンスに数百または数千接続を行っているときに顕著に発揮します。例として、Sysbench oltp.lua ベンチマークで570,000 reads/secondから625,000 reads/secondに向上しました。このテストではdb.r3.8xlarge DBインスタンスで以下のパラメータを利用して行いました。
- oltp_table_count=25
- oltp_table_size=10000
- num-threads=1500
Aurora 1.7にアップグレードすることで、すぐにこのパフォーマンス改善をご体験頂けます。
Upgrading to Aurora 1.7
新しく作成されたDBインスタンスはAurora 1.7で自動的に起動します。既に起動しているDBインスタンスでは、update immediately か during your next maintenance windowを選択することでインストールが可能です。
以下のクエリでAurora 1.7で起動しているか確認出来ます。
mysql> show global variables like “aurora_version”;
+—————-+——-+
| Variable_name | Value |
+—————-+——-+
| aurora_version | 1.7 |
+—————-+——-+