Amazon Web Services ブログ

Category: Amazon RDS*

Amazon Aurora Clusterに監査機能を追加

re:InventでMySQLデータベースと互換性があり、コマーシャルデータベースの性能と可用性、オープンソースデータベースのコストパーフォーマンスの両面をそなえた、Amazon Auroraの新機能を発表しました。 今日、advanced auditing機能が全てのお客様にご利用頂けるようになったことを発表致します。 advanced auditingとは Auditingとは特定のイベントを収集して手動もしくは他のアプリケーションで分析出来るように提供する機能を指します。これらのログはコンプライアンス規定やガバナンスのベースになる情報として利用可能です。advanced auditingの例には、ログ分析、ユーザーアクションの監査(過去のイベントおよび、ニアリアルタイムの脅威検出など)、セキュリティ関連のイベントに設定されたアラームのが含まれます。 Auroraのadvanced auditing機能は、データベースのパフォーマンスに与える影響を最小限に抑えながら、これらの機能を提供するように設計されています。 advanced auditingを利用するには まずはじめに、advanced auditingを有効にし、audit logを参照します。 advanced auditingの有効化 DBクラスタパラメータグループにあるパラメータを設定することでadvanced auditingの有効化や設定を行うことができます。これらのパラメータの変更がDBクラスタの再起動は必要ありません。また、動作は Aurora DB instance parametersと同様です。 機能を有効/無効化するために server_audit_loggingパラメータを利用します。server_audit_eventsパラメータでどのイベントをログに記録するか設定します。 server_audit_excl_usersとserver_audit_incl_usersパラメータでどのユーザを監査対象にするか設定可能です: server_audit_excl_usersとserver_audit_incl_usersが未指定の場合(デフォルト値)は全てのユーザが記録されます server_audit_incl_usersにユーザを設定し、server_audit_excl_usersを指定しない場合、server_audit_incl_usersに指定したユーザのみ記録されます server_audit_excl_usersにユーザを設定し、server_audit_incl_usersを指定しない場合、server_audit_excl_usersに指定したユーザ以外が記録の対象になります server_audit_excl_usersとserver_audit_incl_usersに同一のユーザを設定した場合は、server_audit_incl_usersの優先度が高いため記録の対象になります advanced auditingのパラメータの詳細を以下でご説明します server_audit_logging 監査ログの有効/無効化を指定します。標準ではOFFになっているので、ONに指定することで有効になります Scope: Global Dynamic: Yes Data type: Boolean Default value: OFF (disabled) server_audit_events イベントのリストをカンマで区切って指定します。リスト中のエレメント間にスペースは入れなように気をつけて下さい Scope: Global Dynamic: Yes Data type: String Default value: Empty […]

Read More

事前にご確認ください – AWSにおける2016年12月31日(日本時間2017年1月1日)のうるう秒

2016年末最後の数秒をカウントダウンする場合は、最後に1秒を追加するのを忘れないようにしてください! 次回のうるう秒(通算27回目)が、UTC(世界標準時)の2016年12月31日 23:59:60として挿入されます(訳注:日本標準時では2017年1月1日 8:59:60になります)。これは地球上での時刻(協定世界時)と太陽時(天文時)とのずれを小さくするために行われ、この結果、UTCでは今年最後の1分は61秒あることになります。 参考)「うるう秒」挿入のお知らせ(総務省) 前回のうるう秒の際に出した情報(事前にご確認ください – AWSでのうるう秒対応)は引き続き有効で、今回も同様に処理されますが、少しの違いと進展があります: AWS調整時刻(AWS Adjusted Time) –うるう秒挿入前後の24時間の期間にわたって、うるう秒の1秒を少しずつ分散します(UTCで12月31日の11:59:59から、2017年1月1日12:00:00まで)。AWS調整時刻と協定世界時はこの期間が終了後に同期します。(訳注:この期間の1秒をごくわずかに遅くすることで、追加される1秒を長い時間のなかに分散する方法であり、これは前回うるう秒挿入時と同じ挙動です。詳しくは前回の情報をご確認ください。) Microsoft Windows – Amazonによって提供されたMicrosoft WindowsのAMIを利用しているインスタンスは、AWS調整時刻に従います。 Amazon RDS – 大多数のAmazon RDS インスタンスは (UTCで設定されている場合)“23:59:59” を2回記録します。しかし、Oracle 11.2.0.2、11.2.0.3、12.1.0.1 はAWS調整時刻に従います。Oracle 11.2.0.4と12.1.0.2について詳細な情報が必要な場合はAWSサポートにお問い合わせください。 サポートが必要ですか? このうるう秒挿入についてご質問がある場合は、AWSサポートにコンタクトいただくか、EC2フォーラムにポストしてください。 — Jeff; 翻訳:下佐粉 昭(@simosako) 原文:https://aws.amazon.com/blogs/aws/look-before-you-leap-december-31-2016-leap-second-on-aws/

Read More

Amazon Auroraアップデート – 空間インデックス・ゼロダウンタイムパッチ

AWSの様々なサービスがリリースされてりますが、Amazon Auroraは現在もAWSサービスの中で最も速く成長しているサービスです!お客様には速度、パフォーマンスや可用性を評価頂いています。MySQL互換のAuroraを多く利用いただいていますが、今後リリースされるPostgreSQL互換のAuroraへも期待していただいています(詳細や最近Auroraに追加された機能はAmazon Aurora アップデート – PostgreSQL 互換のエンジンをご覧ください)。 本日、AWS re:Inventでアナウンスをした、空間インデックスとゼロダウンタイムパッチの2つの機能をリリースしました。 空間インデックス Amazon Auroraは今までも地点やエリアを表すためにGEOMETRY型をご利用頂けました。この型を使ってカラムを作成し、ST_Contains, ST_CrossesやST_Distance(更に他にも)といった機能をspatial queryを実行するためにお使い頂けました。これらのクエリはパワフルですが、大きなデータセットに対してスケールするには不十分な点や制限がありました。 Auroraを利用して、ラージスケールな位置情報を使うアプリケーションを作成していただくために、空間データに対してとても効率的なインデックスをお使い頂けるようになりました。Auroraは dimensionally ordered space-filling curve (次元的に整列した空間充填曲線)を利用して、スケールし、高速かつ正確に情報を取り出すことが出来ます。インデックスはb-treeを使い、MySQL5.7と比較して最大2倍のパフォーマンスです(詳細は、こちらのプレゼンテーションとAmazon Aurora Deep Diveのこちらの箇所をご覧ください)。 この機能を現在ご利用頂くためには、Aurora Lab Modeを有効にして頂く必要があります。機能を有効にした後は、既存のテーブルや新規に作成するテーブルにspatial indexを設定頂けます(詳細はこちらをご覧ください)。 ゼロダウンタイムパッチ 今日のような24×7の世界で、データベースへのパッチ適用やアップデートでデータベースをオフラインにする良い時間はありません。しかし、高可用性を維持するために、read replicaを利用して昇格させる方法が利用されてきました。 私達の、新しいゼロダウンタイムパッチ機能により、Auroraインスタンスへのパッチ適用をダウンタイム無しで、可用性にも影響を及ぼさずオンラインで実行出来るようになりました。この機能は、現在の最新バージョン(1.10)が適用されたAuroraインスタンスで、ベストエフォートで機能します。シングルノードクラスタとマルチノードクラスタのWriterインスタンス双方で機能しますが、バイナリログが有効になっている場合は無効になります。 このパッチは、既に開かれているSSLコネクション、アクティブなロック、トランザクションの完了やテンポラリテーブルの削除を待ちます。パッチ適用可能なウインドウが出来た場合、ゼロダウンタイムパッチとして適用します。アプリケーションセッションは保持されたまま、パッチが適用される間データベースエンジンがリスタートします。この間瞬間的(5秒程度)なスループット低下が発生します。もし、ゼロダウンタイムパッチで適用出来るウインドウがなかった場合、通常のパッチ適用プロセスが実行されます。 さらに詳細にこの機能がどのように動作するかや実装方法については、Amazon Aurora Deep Dive videoのこちらの箇所をご覧ください。 本日からご利用いただけます これらの新機能が本日からご利用頂けます! その他の機能改善やBug fixはこちらのforumをご覧ください。 — Jeff; (翻訳は星野が担当しました。原文はこちら)

Read More

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

Read More

Amazon Auroraを開発・テストワークロードでご利用しやすいT2.Medium DBインスタンスクラスをリリース

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

Read More

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