Category: Amazon Aurora*


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_mode1に設定します。

rds_aurora_set_lab_mode

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 |
+—————-+——-+

Jeff (翻訳は星野が担当しました。原文はこちら)

 

Amazon AuroraでMySQLバックアップからクラスタを作成可能になりました

AWSをご利用になり、クラウドへ移行するメリットを感じられているお客様から、アプリケーションやリレーショナルデータベースに保存されている、大量のデータを移行するより良い方法を良く質問されます。

本日、Amazon Auroraにて重要な新機能をリリースしました。既にオンプレミス環境やAmazon EC2インスタンス上でMySQLをお使いの場合、既存のデータベースのバックアップを取得し、スナップショットバックアップをAmazon S3にアップロード行い、そのスナップショットバックアップを利用して、Amazon Auroraクラスタを作成可能になりました。既存のAmazon AuroraのMySQLデータベースからレプリケーションを行える機能と合わせて利用することで、MySQLからAmazon Auroraへアプリケーションを停止させず簡単にマイグレーション可能です。

この新機能を利用することで大容量のデータ(2TB以上)をMySQLデータベースからAmazon Auroraへ移行元データベースへパフォーマンスインパクトを最小限にして効率的に移行を行うことが可能です。私達の行ったテストではmysqldump utilityを利用した場合と比較して20倍高速に処理が行えました。移行対象データベースにInnoDBとMyISAM形式のテーブルが双方が含まれていても移行は可能ですが、移行前にMyISAMからInnoDBへ変換を行っておくことをお勧めします。

移行方法について簡単にご説明します:

    1. 移行元データベースの準備 – 移行元データベースでバイナリログを有効化し。移行期間中バイナリログが残っているように設定を行って下さい。
    2. 移行元データベースのバックアップ – Percona Xtrabackupを利用して移行元データベースから”ホット”バックアップを作成します。このツールはデータベース、テーブルやトランザクションをロックしません。圧縮形式のバックアップを作成可能です。1つのバックアップファイルや複数の小さなバックアップファイルを作成頂けます。Amazon Auroraではどちらの形式でもご利用頂けます。
    3. S3へアップロード – S3へバックアップファイルをアップロードします。5TB未満のバックアップの場合は、AWS Management ConsoleAWS Command Line Interface (CLI) を利用してアップロードを行います。さらに大きなバックアップデータの場合は、AWS Import/Export Snowballを利用することをご検討下さい。
    4. IAM Role – Amazon Relational Database Service (RDS) がアップロードされたバックアップデータとバケットにアクセスするためにIAM roleを作成します。このIAM roleでは必ず、RDSがListBucketGetBucketLocation の操作をバケットに実行でき、GetObject の操作をバックアップデータに行える必要があります (サンプルポリシーはドキュメントで確認頂けます)。
    5. クラスタの作成 – 新しいAmazon Auroraクラスタをアップロードしたバックアップデータから作成します。RDSコンソール中のRestore Aurora DB Cluster from S3をクリックし、移行元データベースのバージョン番号を入力します。そして、S3バケットを選択し、IAM roleを選択後、Next Stepをクリックします。その後、クラスタ作成ページ(DB Details と Configure Advanced Settings)の残りの項目を入力します。rds_aurora_pick_src_backup

      Amazon Auroraはバックアップファイルをアルファベット順に処理します。

    6. MySQLスキーマの移行 – ユーザ、権限やMySQL INFORMATION_SCHEMAで行っていた設定を移行します。
    7. 関連するアイテムの移行 – trigger, functionやstored procedureを移行元データベースからAmazon Auroraクラスタに移行します。
    8. レプリケーションの設定 – 移行元データベースとAmazon Aurora間でレプリケーションを設定し、レプリケーションを追いつかせます。
    9. データベースの変更 – 全てのクライアントアプリケーションの接続先をAmazon Auroraクラスタに変更します。
    10. レプリケーションの停止 – Amazon Auroraクラスタへのレプリケーションを停止します。

本番環境でミッションクリティカルなデータベースの移行前には、移行の検証をお勧めします。

本日からご利用いただけます

この新機能は本日からAsia Pacific (Mumbai)リージョンを除く全てのリージョンでご利用いただけます。さらに詳細な情報はAmazon Aurora User Guide中のMigrating Data from an External MySQL Database to an Amazon Aurora DB Clusterをご覧ください。

Jeff; (翻訳は星野が担当しました。原文はこちら)

Amazon AuroraでCross-Region Read Replicaがご利用頂けるようになりました

Amazon Auroraクラスタににリードレプリカを追加することでリードキャパシティの増強を行って頂けます。本日、リードレプリカを他のリージョンに作成頂ける機能をリリースしました。この機能を利用することでリージョン間でディザスタリカバリ構成を利用出来、リードキャパシティを拡張出来ます。その他にも、他のリージョンにデータベースをマイグレーションしたり、新しい環境を構築する際にもご利用頂けます。

リードレプリカを他のリージョンに作成すると、Auroraクラスタがそのリージョンに作成されます。Auroraクラスタには15台までリージョン内であればレプリカラグのとても低いリードレプリカを作成出来ます(多くのケースで20ms以内)。リージョン間の場合、ソースクラスタとターゲットクラスタの間の距離に応じてレイテンシが増加します。この構成は、現在のAuroraクラスタを複製したり、ディザスタリカバリ目的でリードレプリカをリージョン間で構成することに利用頂けます。リージョン障害が万が一発生した場合、クロスリージョンレプリカをマスターとして昇格します。こうすることで、ダウンタイムを最小限にすることが可能です。こちらの機能は、暗号化されていないAuroraクラスタに適用可能です。

リードレプリカを作成する前に、ターゲットとなるリージョンにVPCやDatabase Subnet Groupsが存在しているか、マスターでバイナリログが有効になっているかを確認する必要があります。(訳者注: 設定を有効にする前に最新のパッチを適用して下さい)

VPCの設定

AuroraはVPC内で起動するため、ターゲットとなるリージョンに適切に設定されたDatabase Subnet Groupsが存在するか確認します:

con_aurora_cross_target_subnet_groups

バイナリログを有効にする

クロスリージョンレプリケーションを設定する前にバイナリログを有効にする必要があります。もしdefaultパラメータグループをお使いの場合、新しいDB Cluster Parameter Groupを作成します:

con_aurora_create_cluster_pg

バイナリログを有効にし(binlog_formatをMIXEDに)、Save Changesをクリックします:

con_aurora_edit_cpg

次に、設定を変更するDBインスタンスを選択しModifyを選択します。そして、新しいDB Cluster Parameter Groupを選択しApply Immediatelyを選択してContinueをクリックします。変更を確認し、設定を反映させるためにをクリックします:con_aurora_pick_cpg

インスタンスを選択し、再起動を実行しreadyになるまで待ちます

リードレプリカの作成

事前準備が完了したら、リードレプリカを作成します!AWS Management Consoleから、ソースクラスタを選択し、 Instance ActionsメニューからCreate Cross Region Read Replicaを選択します:

con_aurora_cross_reg_replica_menu

新しインスタンスやクラスタの名前を設定し、ターゲットリージョンを選択します。DB Subnet Groupを選択し、他のオプションも希望の設定にし最後にCreateをクリックします:

con_aurora_create_cr_replica

Auroraがクラスタやインスタンスを作成します。インスタンスが作成されデータがレプリケーションされるまでcreatingステータスになります(作成完了までの時間はソースクラスタに保存されているデータサイズに依存します)。

こちらの機能は本日からご利用頂けます!

— Jeff (翻訳は星野が担当しました。原文はこちら)

Amazon Auroraでアカウント間でスナップショットを共有頂けるようになりました

Amazon AuroraはMySQL互換で、ハイパフォーマンスなデータベースエンジンです。Auroraはハイエンドデータベース速度や可用性をオープンソースデータベースのコスト効率やシンプルさでご利用頂けます (更に詳細な情報はAmazon Aurora – New Cost-Effective MySQL-Compatible Database Engine for Amazon RDSをご覧ください)。AuroraはAmazon RDSでご利用頂ける、簡単な管理数クリックでスケール可能スピードセキュリティコスト効率などの幾つかの重要な機能を持っています。

数クリックでAuroraクラスタのバックアップを行うためにスナップショットを作成出来ます。スナップショットを作成後、同じく数クリックでスナップショットからデータベースをリストア可能です。

スナップショット共有

本日、Auroraスナップショットを共有頂けるようになりました。スナップショットは他のAWSアカウントと共有するだけではなく、パブリックに共有も可能です。同一リージョンの他のAWSアカウントで起動しているAuroraスナップショットからデータベースをリストア可能です。

スナップショット共有の主なユースケースをいくつかご紹介します:

環境の分離 – 多くのAWSのお客様が開発、テスト、ステージング、プロダクション環境に個別のAWSアカウントをご利用しています。必要に応じでこれらのアカウント間でスナップショットを共有頂けます。例えば、初期データベースをステージング環境で構築し、スナップショットを作成します、そしてそのスナップショットを本番環境のアカウントに共有し、そのスナップショットから本番データベースを作成します。他にも、本番環境のコードやクエリで何か問題が発生した場合、プロダクション環境のデータベースのスナップショットを作成しテスト環境にデバッグ目的で共有することも可能です。

Partnering – 必要に応じてスナップショットを特定のパートナーに共有出来ます

データの共同利用 – もしリサーチプロジェクトを行っているなら、スナップショットを作成しパブリックに共有することが可能です。興味をもった人がそのスナップショットから自分のAuroraデータベースを作成し、皆さんのデータをスタートポイントとして利用出来ます。

スナップショットを共有するために、RDSコンソールからShare Snapshotをクリックします。そして、共有先のAWSアカウントを入力します。(もしくは、パブリック共有のためにPublicを選択します)そして、Addを選択します:

rds_aurora_share_snap

共有出来るスナップショットは、手動作成されたもの、暗号化されていないものを他のAWSアカウントと、パブリックなものを共有可能です。自動取得されたスナップショットと暗号化されたスナップショットは共有出来ません。

共有されたスナップショットは直ぐに他のアカウントで閲覧出来るようになります:

rds_aurora_see_shared_snaps

パブリックスナップショットも参照出来ます(FilterAll Public Snapshotsを選択します):

rds_see_public_snaps

本日からご利用頂けます

この機能は本日から直ぐにご利用頂けます。

— Jeff (翻訳は星野が担当しました。原文はこちら)