Amazon Web Services ブログ

Category: Database

Amazon Auroraアップデート – ストアードプロシジャーからLambda Functionの呼び出しと S3からのデータ読み込みに対応 –

多くの 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 […]

Read More

Amazon ElastiCache for Redisアップデート – Sharded Clusterの追加やエンジンバージョンを更新 –

多くのAWSのお客様に高速で、インメモリデータストアとして Amazon ElastiCacheをご利用頂いています。 2013年にAmazon ElastiCache for Redisをリリースし、スナップショットのS3へのエクスポート機能、エンジンバージョンの更新、スケールアップ機能、タグ、Multi-AZで自動フェイルオーバー機能を数年で追加してきました。 本日、新機能をElastiCache for Redisへ追加しました。詳細は以下の通りです。 Sharded Clusterサポート – 3.5 TiB以上をインメモリデータとして扱う事が出来るsharded clusterを作成可能になりました コンソールの改善 – 以前より簡単にクラスタの作成やメンテナンスが行えるようになりました エンジンアップデート – Redis 3.2の機能をご利用頂けるようになりました Geospatial Data – 地理空間データの処理を行え、利用可能になりました 更に詳細を見ていきましょう!   Sharded Clusterサポート / 新コンソール 今まではElastiCache for Redisは1つのプライマリノードと5つまでのread replicaを含んだクラスタに対応していました。この構成では、メモリサイズがクラスタあたり237 GiBに制限されていました。 1クラスタで15シャードまで作成出来るようになったことで、クラスタ全体のメモリ容量を拡大することが可能になり、最大3.5 TiBまでのデータをインメモリデータとして格納出来ます。それぞれのシャードは5つまでread replicaを作成可能で、1秒あたり2,000万読み込み、450万書き込みの性能を提供します。 シャードモデルは、read replicaと合わせて利用することでクラスタ全体の可用性とパフォーマンスを向上します。データは複数のノードに分散され、read replicaは高速で自動的なフェイルオーバーをプライマリノードに障害が起こった際に提供します。 シャードモデルの利点を活かすために、cluster対応のRedisクライアントを使う必要があります。クライアントは、16,384個のスロットをシャード毎に均等に分散されたハッシュテーブルとして扱い、保存するデータを各シャードにマップします。 ElastiCache for Redisはクラスタ全体を1つのバックアップとリストア用途のユニットとして扱います。そのため、各シャード毎のバックアップを管理したり考えたりする必要がありません。 コンソールの機能が改善され、スケールアウトクラスタを簡単に作成可能になりました。(Redisエンジンを選択した後にCluster Mode enabled (Scale Out)にチェックを入れている点を注目して下さい) 新しい便利なメニューで適切なノードタイプを選択を手助けしてくれます sharded clusterは、AWS Command Line […]

Read More

Amazon RDS for OracleでOracle UTL_MailとJuly 2016 PSU Patchesがご利用可能になりました

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サポートに関してはこちらをご覧ください。 星野 (原文はこちら)

Read More

Amazon RDS for SQL Serverがローカルタイムゾーンをサポートしました

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のローカルタイムゾーンサポートに関する更に詳細な情報は、ドキュメントをご覧ください。 星野 (原文はこちら)

Read More

Amazon RDS for PostgreSQL – 新マイナーバージョン、ロジカルレプリケーション、 DMSサポートなどを追加 –

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月 […]

Read More

Amazon Auroraにリーダーエンドポイントが追加されました – 負荷分散と高可用性向上 –

機能向上を行うたびにAmazon Auroraはパワフルかつ簡単にご利用頂けるようになってきました。ここ数ヶ月で、MySQLバックアップからAuroraクラスタを作成する機能や、クロスリージョンレプリケーション、アカウント間でのスナップショットの共有、フェイルオーバー順を指定可能になったり、他のクラウドやオンプレミス環境のデータベースからAuroraへ移行などを追加してきました。 本日、Auroraのリードレプリカの機能を向上する、クラスタレベルのリードエンドポイントを追加しました。皆様のアプリケーションは今まで通り特定のレプリカに対して直接クエリを実行することが可能です。しかし、今回追加したリードエンドポイントを利用するように変更することで、負荷分散や高可用性といった2つの大きな利点を得ることが出来ます。 Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプリカ間でコネクションのロードバランシングが可能になります。これは、リードワークロードを分散することで利用可能なレプリカ間でリソースを効率的に活用することができ、よりよりパフォーマンスを得ることが可能になります。フェイルオーバーの際には、もしアプリケーションが接続しているレプリカがプライマリインスタンスに昇格した場合コネクションは一旦クローズされます。その後、再接続を行うことでクラスタ内の他のレプリカにリードクエリを実行することが可能です。 Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイント経由で接続することが出来ます。Availability Zoneの可用性の問題が万が一発生した場合、リードエンドポイントを利用することで最小限のダウンタイムでリードトラフィックを他のレプリカに実行可能です。   Find the Endpoint リーダーエンドポイントはAurora Consoleで確認可能です: この便利な機能は本日からご利用可能です! — Jeff; (翻訳は星野が担当しました。原文はこちら)

Read More

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 […]

Read More

新発表 – Redshift や QuickSight で AWS のコストや使用状況レポートのアップロードが可能に

以前より、AWS の多くのお客様からプログラムを使用してコストや使用状況レポートを分析する方法をリクエスト頂いていました (詳しくは New – AWS Cost and Usage Reports for Comprehensive and Customizable Reporting をご覧ください)。リクエストをお寄せくださったお客様は、いくつものリージョンにわたり AWS を使用して複数のビジネスを行い、幅広く様々なサービスをご利用されている傾向があります。AWS では請求レポートやコストに関する詳細情報をご提供しているため、これはビッグデータに関与する問題であり、AWS サービスを使用すれば簡単に解決することができます。今月初旬に私が休暇を取っていた間に、AWS はコストや使用状況レポートを や Amazon QuickSight にアップロードできる新機能をリリースしました。今回はその新機能についてご説明します。 Redshift にアップロード まず、新しい Redshift クラスターを作成してみました (すでに実行しているクラスターがある場合は新たに作成する必要はありません)。私が作成したクラスターは次の通りです。 次に請求レポート機能が有効になっていることを確認しました。 そしてコストと請求レポートに行き、Create report をクリックしました。 次にレポート名を指定 (MyReportRedshift) し、時間制に設定してから Redshift と QuickSight 両方のサポートを有効にしました。 最後に配信オプションを選択しました。 次のページでレポートを作成することを確認し、Review and Complete をクリックしました。レポートが作成され、最初のレポートは 24 時間以内にバケットに届くという通知が届きました。 待機している間に PostgreSQL を EC2 インスタンス (sudo yum […]

Read More

Amazon RDS for SQL Server – Amazon S3 でネイティブバックアップと復元をサポート

このブログを定期的にご覧になっている読者の方々であれば、私が 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 エディションで […]

Read More

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

Read More