Category: Amazon RDS

(昨日のように思いますが)ちょうど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 は、高い堅牢性、高可用性、リードレプリカをすぐに作成できる機能など先にあげたすべての利点を提供します。ここには、お気に召すであろういくつかの特徴をあげます：

(more…)

Amazon Auroraは既にdb.r3.large (2 vCPUs, 15 GiB RAM) から db.r3.8xlarge (32 vCPUs 244 GiB RAM)まで5つのインスタンスクラスをご提供していました。これらのインスタンスは非常に多くのプロダクション環境やアプリケーション向けのユースケースをサポートしています。

今日、 db.t2.medium DB インスタンスクラス (2 vCPUs, 4 GiB RAM)の6つ目の選択肢を追加致しました。通常時、このインスタンスクラスではシングルコアの40%のパフォーマンスを利用することが可能で、CPUを利用するクエリやデータベースタスクを実行する場合コアのフルパフォーマンスまでバーストをします。同名のEC2インスタンスの様に、この新しいインスタンスクラスはCPUクレジットを持っており、CPUが多く使われている場合は消費し、そうでない場合はCPUクレジットを蓄積します。(バースト可能な性能を持つ新しい低コストEC2インスタンスで詳細を説明しています)

db.t2.mediumは多くの開発・テスト環境に最適です。また、負荷の少ないプロダクションワークロードにも利用出来ます。CPUCreditUsageとCPUCreditBalance メトリクスを監視することでCPUクレジットの利用や蓄積を確認することが出来ます。

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

新しいインスタンスクラスを使ったAmazon Auroraデータベースは本日から起動頂けます。Amazon Auroraが利用出来る全リージョンで利用可能です。1時間あたり$0.082(N.Virginiaリージョンの場合)からご利用頂けます。

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

多くの AWS serviceはそれ自体だけでもよく動作しますが、組み合わせることで更に良くなります！この大事な我々のモデルは、各サービスを選択し学習を行ない、経験を積み時間とともに他のサービスへ拡張していく事が可能です。一方で、サービスを組み合わせて使う機会は常に存在し、お客様の要望に基づきロードマップへいくつも反映しています。

本日、MySQL互換のリレーショナルデータベースである、Amazon Auroraの2つの新機能をご紹介します。

• Lambda Function Invocation – Amazon Auroraデータベース 内のストアードプロシジャーからAWS Lambdaのfunctionを呼び出すことが可能になりました
• Load Data From S3 –  Amazon Simple Storage Service (S3)のバケットに保存されたデータをAmazon Auroraデータベースにロード可能になりました

これら2つの新機能はAmazon Auroraと他のAWSサービスを連携するためにAmazon Auroraに適切な権限を付与する必要があります。IAM Policyや IAM Roleを作成し、作成したRoleをAmazon Auroraデータベースクラスタへ付与します。詳細な手順はドキュメントをご覧ください。

Lambda Function Integration

ハイレベルな機能を実現するために、リレーショナルデータベースではトリガーやストアードプロシジャーを組み合わせて利用します。トリガーは特定のテーブルへの操作の前後で実行することが出来ます。例えば、Amazon AuroraはMySQLと互換性があるため、INSERT, UPDATE, DELETE操作へのトリガーをサポートしています。ストアードプロシジャーは実行されたトリガーへのレスポンスの中で実行可能なスクリプトです。

Lambda functionを呼び出すストアードプロシジャーを利用可能になりました。この拡張された機能を使うことで、Auroraデータベースと他のAWSサービスを結びつけることが出来るようになりました。Amazon Simple Email Service (SES)を利用してemailを送信したり、 Amazon Simple Notification Service (SNS)を利用し問題の通知を行ったり、Amazon CloudWatchにメトリクスを送信したり、 Amazon DynamoDBのテーブルを更新するようなことが可能です。

その他にも、複雑なETLジョブやワークフロー、データベース内のテーブルに対する監査、パフォーマンスモニタリングや分析なども用途として考えられます。

ストアードプロシジャーからはmysql_lambda_asyncプロシジャーを呼び出す必要があります。このプロシジャーは非同期で与えられたLambda functionを実行するため、Lambda functionの完了を待たずに処理を終了します。Lambda functionには利用するAWSサービスやリソースに対する権限を付与しておく必要があります。

詳細は、 Invoking a Lambda Function from an Amazon Aurora DB Clusterをご覧ください。

Load Data From S3

他の形のインテグレーションとして、S3バケットに保存されたデータを直接Auroraにインポート可能になりました (今までは一度Ec2インスタンス上にダウンロードしたあとにインポートする必要がありました)。

Amazon Auroraクラスタからアクセス可能であれば、AWSのどのリージョンにデータが配置されていてもロード可能です。形式はテキストかXML形式に対応しています。

テキスト形式のデータをインポートするためには、新しい LOAD DATA FROM S3コマンドを利用します。このコマンドはMySQLのLOAD DATA INFILEとほぼ同様のオプションをサポートしています。しかし、圧縮形式のデータは現在サポートしていません。特定の行やフィールドデリミタやキャラクタセットを設定可能で、指定した行や列数を無視して取り込むことも可能です。

XML形式のデータをインポートするためには、新しいLOAD XML from S3コマンドを利用します。XMLは以下の様な形式になります。

<row column1="value1" column2="value2" />
...
<row column1="value1" column2="value2" />

や

<row>
  <column1>value1</column1>
  <column2>value2</column2>
</row>
...

また

<row>
  <field name="column1">value1</field>
  <field name="column2">value2</field>
</row>
...

の形式に対応しています。

詳細は、Loading Data Into a DB Cluster From Text Files in an Amazon S3 Bucketをご覧ください。

すぐにご利用いただけます

これらの新機能は本日からご利用頂けます！

それぞれの機能には追加で料金はかかりませんが、通常のAmazon Aurora, Lambda, S3のご利用料金が発生します。

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

UTL_MAILパッケージをご利用頂くことでRDS for Oracleデータベースから直接メールを送信頂けるようになりました。お使いのDBインスタンスでUTL_Mailを有効にするためには、新しいオプショングループを作成するか、既存のオプショングループをコピーもしくは編集をしOracle UTL_MAILオプションを追加します。その後、このオプショングループをDBインスタンスの作成時か変更時に設定を行ないたいDBインスタンスへ適用します。現在、32KBまでの1つの添付ファイルとASCIIとEBCDIC文字コードのみをサポートしています。Amazon RDSではUTL_MAILをOracle version 12.1.0.2.v5 以上、12.1.0.1.v6以上、 11.2.0.4.v9以上でサポートしています。またこれらのバージョンはJuly 2016 Oracle Patch Set Updates (PSU)を含んでいます。

Amazon RDSはOracle社から提供されているbug fixを、四半期ごとに提供されるDatabase Patch Set Updates (PSU)にて適用しています。現在、Oracle July 2016 PSUがAmazon RDS for Oracleでご利用頂けます。AWS Management Console中の”Launch DB Instance Wizard”から所望のDBエンジンバージョンを選択肢、数クリックで新しいOracle “11.2.0.4.v9″、 “12.1.0.1.v6″と”12.1.0.2.v5″DBインスタンスを作成出来ます。既存のデータベースインスタンスをアップグレードする場合は、AWS Management Console中の”Modify”オプションを選択し、所望のデータベースエンジンバージョンを設定します。プロダクションデータベースインスタンスのアップグレードを行う前に、プロダクションデータベースのスナップショットからテスト用のDBインスタンスを起動し、アップグレード手順や時間のテストやアプリケーションのテストを行うことを推薦します。

Amazon RDS for OracleでUTL_Mailを利用する詳細な手順はドキュメントをご覧ください。また、RDSでのOracle PSUサポートに関してはこちらをご覧ください。

星野 (原文はこちら)

Amazon RDS SQL Serverでローカルタイムゾーンをサポートしました。アプリケーションでお使いのタイムゾーンをAmazon RDS for SQL Serverインスタンスに設定頂けます。

こちらの機能はDBインスタンスのタイムゾーンをご指定の物に設定します。RDS for SQL Serverを作成する際にタイムゾーンを変更する場合は、AWS Management ConsoleのSelect your Time Zoneドロップダウンメニューを利用します。インスタンス作成後はタイムゾーンを変更することが出来ません。このオプションを変更すると、OSレベルでのタイムゾーンの変更が行われ、全てのdateカラムと値に影響がある点ご注意ください。その為、タイムゾーンの変更による影響を事前に調査することを推薦します。ローカルタイムゾーンを設定したデータベースインスタンスを作成する前に、テストデータベースインスタンスで変更を検証することをお勧めします。

Amazon RDS for SQL Serverのローカルタイムゾーンサポートに関する更に詳細な情報は、ドキュメントをご覧ください。

星野 (原文はこちら)

Amazon Relational Database Service (RDS)は構築や運用管理、スケーリングなどを行うプロセスを簡単に行えるクラウド上のリレーショナルデータベースです。現在6つのデータベースエンジン(Amazon Aurora, Oracle, Microsoft SQL Server, PostgreSQL, MySQL,  MariaDB) をサポートしており、RDSはクラウド上で動作するアプリケーションの基本となるサービスとなりました。

2013年後半にPostgreSQLサポートを発表し、PostgreSQLの新バージョンや新機能を追加し続けてきました。

• 2014年11月 – Read Replicas, version 9.3.5, Trigger-based Replication, and Three New Extensions.
• 2015年3月  – Version 9.4.1, Enhanced Monitoring, Enforced SSL Connections.
• 2015年11月 – Point and Click Upgrade from Version 9.3 to 9.4.
• 2016年4月  – Versions 9.3.12, 9.4.7, and 9.5.2.
• 2016年6月  – Cross-Region Read Replicas.

本日、Amazon RDS for PostgreSQLに以下の新機能を追加しました。

• 新マイナーバージョン – 既存のRDS for PostgreSQLデータベースインスタンスは新しいマイナーバージョンにアップグレード可能です

• ロジカルレプリケーション – RDS for PostgreSQLがロジカルレプリケーションに対応しました。

• DMSサポート – ロジカルレプリケーション機能によりRDS for PostgreSQLデータベースインスタンスをAWS Database Migration Serviceのソースデータベースとして利用可能になりました

• Event Trigger – 新しいバージョンのPostgreSQLでデータベースインスタンスレベルでevent triggerをサポートしました

• RAM Disk Size – RDS for PostgreSQLでRAM diskのサイズをコントロール可能になりました

詳しくご紹介します

新マイナーバージョン

PostgreSQL バージョン9.3.14, 9.4.9,  9.5.4をサポートしました。これらのバージョンはリリースノートに記載されているように機能向上やbug fixが行われています。RDSコンソールやAWS Command Line Interface (CLI)から今お使いのデータベースインスタンスをアップグレード可能です。9.5.2から9.5.4にコンソールを利用してアップグレードする例です:

次回のMaintenance Windowまでアップグレードを行ないたくない場合はApply immediatelyにチェックが入っていないか確認をしてください。

command lineからアップグレードを行う例を以下に示します。(私のスキルが現役ということをお伝えするために、今回のポスト中でコマンドラインを利用した例を掲載しています)

$ aws rds modify-db-instance –region us-west-2 \
–db-instance-identifier “pg95” \
–engine-version “9.5.4” \
–apply-immediately

アップグレードの進捗を確認するには

$ aws rds describe-events –region us-west-2 \
–source-type db-instance –source-identifier “pg95” \
–duration 10 –output table

以下の例はインスタンスのアップグレードが完了した場合の出力です

||+-------------------------------------------------+||
 || Events ||
 |+--------------------+------------------------------+|
 || Date | 2016-09-13T00:07:54.547Z ||
 || Message | Database instance patched ||
 || SourceIdentifier | pg95 ||
 || SourceType | db-instance ||
 |+--------------------+------------------------------+|
 ||| EventCategories |||
 ||+-------------------------------------------------+||
 ||| maintenance |||
 ||+-------------------------------------------------+||

データベースインスタンス全体のイベントを監視している場合、RDSがパッチを適用する前後でバックアップを取得している事を確認出来ます。このバックアップはコンソールやコマンドライン経由で参照可能です。

$ aws rds describe-db-snapshots –region us-west-2 \
–db-instance-identifier “pg95” \
–snapshot-type automated –output table

出力は以下のようになります。

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 | DescribeDBSnapshots
 +--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 || DBSnapshots
 |+------------------+-------------------+-----------------------+----------------------------+------------+-----------+----------------+---------------------------+-------+---------------------+-----------------+-----------------------+-
 || AllocatedStorage | AvailabilityZone | DBInstanceIdentifier | DBSnapshotIdentifier | Encrypted | Engine | EngineVersion | InstanceCreateTime | Iops | LicenseModel | MasterUsername | OptionGroupName |
 |+------------------+-------------------+-----------------------+----------------------------+------------+-----------+----------------+---------------------------+-------+---------------------+-----------------+-----------------------+-
 || 100 | us-west-2b | pg95 | rds:pg95-2016-09-12-23-22 | False | postgres | 9.5.2 | 2016-09-12T23:15:07.999Z | 1000 | postgresql-license | root | default:postgres-9-5 |
 || 100 | us-west-2b | pg95 | rds:pg95-2016-09-13-00-01 | False | postgres | 9.5.2 | 2016-09-12T23:15:07.999Z | 1000 | postgresql-license | root | default:postgres-9-5 |
 || 100 | us-west-2b | pg95 | rds:pg95-2016-09-13-00-07 | False | postgres | 9.5.4 | 2016-09-12T23:15:07.999Z | 1000 | postgresql-license | root | default:postgres-9-5 |
 |+------------------+-------------------+-----------------------+----------------------------+------------+-----------+----------------+---------------------------+-------+---------------------+-----------------+-----------------------+-

ロジカルレプリケーション

Amazon RDS for PostgreSQLがロジカルレプリケーションをサポートしました。これにより、Amazon RDS for PostgreSQLデータベースインスタンスからRDS外のcomplementary logical decoding機能をサポートしたデータベースへストリーミングレプリケーションを行うことが出来るようになります(PostgreSQLはbyte/blockベースのPhysical Streaming Replicationもサポートしています)。レプリケーションがlogical slotを経由して行われます。それぞれのslotは確実に1回だけ再実行される変更のストリームを含んでいます(詳細はPostgreSQLドキュメント中のLogical Decoding Slotsをご参照ください)。

RDS外のデータベースへロジカルレプリケーションを設定するために、PostgreSQL のユーザアカウントにrds_superuserとrds_replicationロールが付与されているか確認してください。その他にも、設定するデータベースインスタンスに紐付けられているデータベースオプショングループ中のrds.logical_replicationパラメータを1に設定し再起動を行う必要があります。このパラメータが適用されると、幾つかのPostgreSQLのパラメータがレプリケーションを行うために設定が行われます。

roleとデータベースインスタンスの設定が行われると、logical slotの作成が可能になりRDS外のデータベース(もしくは他のクライアントから)からslot内のレコードを読み込んで処理出来るようになります。例えば、pg_recvlogicalコマンドでデータベースインスタンスに接続し、replication slotからストリームデータを読み込んでローカルファイルに出力出来ます。

さらに詳細は、 Amazon RDS for PostgreSQLユーザガイド内のLogical Replication for PostgreSQLを参照してください。

DMSサポート

AWS Database Migration ServiceはAWSへのデータベースマイグレーションをサポートするサービスです。ロジカルレプリケーションと一緒に使用する事によりPostgreSQLデータベース(RDSやご自身で管理されているデータベースなど)から他のオープンソースデータベースやコマーシャルデータベースへマイグレーションを行うことが可能になりました。マイグレーションを行うために先程説明したように事前に logical replication slotを設定する必要があります。

Event Triggers

新しいPostgreSQLバージョン (9.4.9+ and 9.5.4+)ではデータベースレベルでevent triggerをサポートしています。このトリガーは特定のテーブル外に存在するため、create, modify, delete tableといったDDLレベルイベントを広範囲にキャプチャー可能です(トリガーの全てのイベントのリストはこちらに掲載されています)。さらに詳細や実装のサンプルはユーザガイド内のEvent Triggers for PostgreSQLを参照してください。

RAM Disk Size

rds.pg_stat_ramdisk_sizeを使用してPostgreSQLのstats_temp_directoryで利用されるメモリ量をコントロール可能になりました。このディレクトリはパフォーマンス情報などの一時的な統計情報に利用されます。メモリを多く割り当てることでI/Oを軽減しパフォーマンスを向上出来ます。

Available Now

今までご紹介した新しいバージョンや新機能は本日からご利用頂けます。

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

機能向上を行うたびにAmazon Auroraはパワフルかつ簡単にご利用頂けるようになってきました。ここ数ヶ月で、MySQLバックアップからAuroraクラスタを作成する機能や、クロスリージョンレプリケーション、アカウント間でのスナップショットの共有、フェイルオーバー順を指定可能になったり、他のクラウドやオンプレミス環境のデータベースからAuroraへ移行などを追加してきました。

本日、Auroraのリードレプリカの機能を向上する、クラスタレベルのリードエンドポイントを追加しました。皆様のアプリケーションは今まで通り特定のレプリカに対して直接クエリを実行することが可能です。しかし、今回追加したリードエンドポイントを利用するように変更することで、負荷分散や高可用性といった2つの大きな利点を得ることが出来ます。

Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプリカ間でコネクションのロードバランシングが可能になります。これは、リードワークロードを分散することで利用可能なレプリカ間でリソースを効率的に活用することができ、よりよりパフォーマンスを得ることが可能になります。フェイルオーバーの際には、もしアプリケーションが接続しているレプリカがプライマリインスタンスに昇格した場合コネクションは一旦クローズされます。その後、再接続を行うことでクラスタ内の他のレプリカにリードクエリを実行することが可能です。

Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイント経由で接続することが出来ます。Availability Zoneの可用性の問題が万が一発生した場合、リードエンドポイントを利用することで最小限のダウンタイムでリードトラフィックを他のレプリカに実行可能です。

Find the Endpoint

リーダーエンドポイントはAurora Consoleで確認可能です:

この便利な機能は本日からご利用可能です！

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

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

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

このブログを定期的にご覧になっている読者の方々であれば、私が Amazon Relational Database Service (RDS) のファンなのをご存知でしょう。これは設定、実行、リレーショナルデータベースのスケーリングなど、より定期的な操作に対応できるマネージド型データベースサービスです。2012 年の開始以来、SQL Server サポートは SSL サポート、メジャーバージョンのアップグレード、透過的なデータの暗号化、拡張モニタリング、Multi-AZ などの機能追加に努めてきました。そして今回、SQL Server のネイティブバックアップと復元のサポートが追加されるようになりました。SQL Server のネイティブバックアップには、テーブル、インデックス、ストアドプロシージャ、トリガーなど、すべてのデータベースオブジェクトが含まれています。主に、こうしたバックアップはオンプレミスで実行もしくはクラウドで実行している SQL Server インスタンス間でデータベースを移行する場合に使用されています。またデータの取り込み、災害対策などにも使用することができます。ネイティブバックアップは、オンプレミスの SQL Server インスタンスからのデータインポートやスキーマのプロセスを簡略化することもできるので、 SQL Server DBA が機能しやすくなります。

ネイティブバックアップと復元のサポート
RDS インスタンスからネイティブ SQL データベースのバックアップを取り、Amazon S3 バケットに保管できるようになりました。バックアップは SQL Server のオンプレミスコピーまたは他の RDS を使用する SQL Server インスタンスに復元することも可能です。さらにオンプレミスデータベースのバックアップを S3 にコピーし、RDS SQL Server インスタンスに復元することもできます。Amazon S3 で行う SQL Server のネイティブバックアップと復元は、すべての SQL Server エディションで AWS Key Management Service (KMS) を使用するバックアップの暗号化をサポートします。S3 を通じて AWS でバックアップの保管や移行を行うと、別の災害対策オプションが提供されます。SQL_SERVER_BACKUP_RESTORE オプションをオプショングループに追加し、そのグループと RDS SQL Server インスタンスをリンクすれば、この機能をオンにすることができます。このオプションは S3 バケットの情報でも設定しておく必要があります。また、バックアップを暗号化するために KMS キーを追加することもできます。希望のオプショングループを検索します。

次に SQL_SERVER_BACKUP_RESTORE オプションを追加し、IAM ロールを指定 (または作成) して RDS が S3 にアクセスできるようにします。バケットにポイントし (希望するのであれば) 暗号化を特定し設定します。

設定が完了したらSQL Server Management Studio を使用してデータベースインスタンスに接続し、必要に応じて次のストアドプロシージャ (msdb データベース内で利用可能) を呼び出します。

• rds_backup_database – 1 つのデータベースを S3 バケットにバックアップします。
• rds_restore_database – S3 から 1 つのデータベースを復元します。
• rds_task_status – バックアップの実行を追跡しタスクを復元します。
• rds_cancel_task – 実行中のバックアップをキャンセルするかタスクを復元します。

詳細はSQL Server データのインポートとエクスポートをご覧ください。

ご利用可能
SQL Server のネイティブバックアップと復元サポートは US East (Northern Virginia)、US West (Oregon)、Europe (Ireland)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Asia Pacific (Singapore)、Asia Pacific (Mumbai)、South America (Brazil) リージョンでご利用いただけます。 本機能を　Amazon RDS for SQL Server でご利用されるにあたり追加費用はありませんが、Amazon S3 ストレージの使用量は通常料金で請求されます。

— Jeff

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 ConsoleやAWS Command Line Interface (CLI) を利用してアップロードを行います。さらに大きなバックアップデータの場合は、AWS Import/Export Snowballを利用することをご検討下さい。
4. IAM Role – Amazon Relational Database Service (RDS) がアップロードされたバックアップデータとバケットにアクセスするためにIAM roleを作成します。このIAM roleでは必ず、RDSがListBucket と GetBucketLocation の操作をバケットに実行でき、GetObject の操作をバックアップデータに行える必要があります (サンプルポリシーはドキュメントで確認頂けます)。
5. クラスタの作成 – 新しいAmazon Auroraクラスタをアップロードしたバックアップデータから作成します。RDSコンソール中のRestore Aurora DB Cluster from S3をクリックし、移行元データベースのバージョン番号を入力します。そして、S3バケットを選択し、IAM roleを選択後、Next Stepをクリックします。その後、クラスタ作成ページ(DB Details と Configure Advanced Settings)の残りの項目を入力します。

   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; (翻訳は星野が担当しました。原文はこちら)