Amazon Web Services ブログ

Category: Database

Performance Insights を使用した Amazon RDS データベースの負荷分析

AWSは Amazon Aurora with PostgreSQL compatibility の一般リリースを先日発表しました。このリリースには Performance Insights と呼ばれる Amazon Relational Database Service (Amazon RDS) に有用な機能の最初のリリースも含まれます。データベースの負荷(どのSQL文が負荷を発生させており、それはなぜなのか)を可視化するダッシュボードを使用して、エキスパートな方とエキスパートではない方の両方が、Performance Insights でパフォーマンス問題を容易に検出できます。

Read More

Amazon RDS for PostgreSQLにおける自動バキュームのケーススタディ

PostgreSQLデータベースにおいて、自動バキューム処理(autovacuum)は複数の重要なメンテナンス操作を実行します。周回を防止するためにトランザクションIDをフリーズすることに加えて、デッドタプルを削除し空きスペースを回復させます。書き込み回数の多いデータベースの場合は、自動バキュームを頻繁に実行するようにチューニングすることをお勧めします。そうすることで、テーブルやインデックスを膨らませるデッドタプルの蓄積を避けることができます。

この記事では、デッドタプルが蓄積される状況でどのように自動バキューム処理を監視し、チューニングするかを実際に示すために、ケーススタディを用いてご説明します。

Read More

Amazon RDSでのIAM multifactor authenticationの利用について

お客様からよく頂くご要望に、インスタンス、スナップショット、クラスタなどのリソースを予期しない、または悪意のあるユーザの削除から保護する方法です。これは、複数のユーザーやチームで共通のAWSアカウントを使用する場合に特に重要です。アカウント内の利用を効率的に行うことも重要ですが、重要なデータを失うことを防ぐためにセキュリティも必要です。 1つの選択肢は、AWS Identity and Access Management(IAM)ポリシーをmultifactor authentication (MFA)で使用することです。MFAでは、AWSリソースに関連した操作を行う際に、承認された認証デバイスまたはSMSテキストメッセージから取得した一意の認証コードを入力する必要があります。この記事はMFAを用いたAmzon RDSのリソースの保護についてご説明します。 たとえば、* prod *のような命名規則でタグ付けされ保護されたリソースの削除を制限するIAMポリシーを作成します。 次に、AWSマネージメントコンソールにアクセスするためにMFA認証が必要な2つ目のIAMポリシーを作成し、このアカウントに対して特定の削除権限を与えます。このようにして、アクセス権のあるすべてのユーザーを監査し、選択されたユーザーのみが必要な権限を持っていることを確認できます。 2つのポリシーを利用します。1つはAWS managed policyの、AmazonRDSFullAccessです。もう1つはcustomer managedポリシーの、RDSDenyDeleteというポリシーを作成します。このポリシーは、リソースを削除する可能性のあるコマンドの実行を制限します。 First step: Start in the IAM console IAMコンソールを開きます。Create policyを選択し、次のJSONコードをポリシーエディタボックスに貼り付けます。 { “Statement”: [ { “Effect”: “Deny”, “Action”: [ “rds:DeleteDBClusterSnapshot”, “rds:DeleteDBSnapshot”, “rds:DeleteDBCluster”, “rds:DeleteDBInstance” ], “Resource”: “*” } ] } Review policyを選択し、ポリシーに名前と説明を付けます。 次に、AmazonRDSFullAccessポリシーとRDSDenyDeleteポリシーを組み合わせたグループを作成します。 IAMコンソールのGroupsから、Create new groupを選択し、グループ名を設定します。この例ではAWSDevelopmentTeamを利用します。 Next stepを選択します。AmazonRDSFullAccessおよびRDSDenyDeleteの横にあるチェックボックスをを選択します。 Next stepを選択し、Create groupを選択します。 […]

Read More

Amazon Neptune が一般向けにご利用いただけます

Amazon Neptune は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、および欧州 (アイルランド) でご利用いただけます。Amazon Neptune は高速で信頼性が高いフルマネージドグラフデータベースサービスであり、これを使用することで高度に接続されたデータセットと連携するアプリケーションの構築と実行が簡単になります。Neptune の中核となるのは、数十億の関係を保存し、ミリ秒単位のレイテンシーでグラフをクエリするために最適化された、専用設計の高性能グラフデータベースエンジンです。Neptune は Apache TinkerPop Gremlin と SPARQL を使用する 2 つの一般的なグラフモデルである Property Graph と RDF をサポートしており、高度に接続されたデータセットを効率的にナビゲートするクエリを簡単に構築することができます。Neptune は、リコメンデーションエンジンやナレッジグラフから医薬品創薬やネットワークセキュリティにいたるまで、あらゆるものを駆動するエンジンとして活用することができます。Neptune は、自動マイナーバージョンのアップグレード、バックアップ、暗号化、およびフェールオーバーによる完全マネージド型です。昨年、私が「AWS re:Invent」向けに寄稿した、「Naptune in detail」では、顧客はプレビューを使用していて、チームが GA 向けサービスを準備に活用した際の素晴らしいフィードバックについてご紹介しています。 今後、Amazon Neptune が一般的に利用できるようになったため、プレビューには次のいくつかの変更点があります: 多項目のパフォーマンス強化および更新内容 AWS CloudFormation サポート AWS コマンドラインインターフェイス (CLI)/SDK サポート Apache TinkerPop 3.3.2 に対応して更新済み Amazon Simple Storage Service (S3) からのバルク読み込むによる IAM ロールに関するサポート […]

Read More

Amazon RDSデータベースプレビュー環境が ご利用可能になりました

Amazon RDSの利便性と柔軟性を備えたPostgreSQLデータベースエンジンのベータ版、リリース候補、およびearly productionバージョンを簡単にテストできる、Amazon RDSデータベースプレビュー環境が利用可能になりました。 PostgreSQLコミュニティから新しいバージョンがリリースされてから数日または数週間以内に、PostgreSQLの新しい機能をテストすることができるようになりました。現在のところ、Amazon RDSデータベースプレビュー環境では、PostgreSQLの次のメジャーバージョンの開発、ベータ、およびリリースの候補バージョンが提供されています。Amazon RDSデータベースプレビュー環境のデータベースインスタンスは全ての機能を有し、データベースのプレビューバージョンを自動でインストールし、プロビジョニング、および管理をお客様側で行って頂く必要がなく、新しいデータベースエンジンをテストできます。Amazon RDSデータベースプレビュー環境のデータベースインスタンスの価格は、米国東部(オハイオ)リージョンで作成されたRDSインスタンスと同じ価格です。 本番環境クラスのセキュリティ、パフォーマンス、信頼性、管理性、および可用性を確保するために、Amazon RDSは多くのテストを行った後で初めて新しいデータベースバージョンをリリースしてきました。Amazon RDSデータベースプレビュー環境は、新バージョンのデータベースエンジンがAmazon RDS環境への統合とテストが完了するのを待たずに、新しいPostgreSQLデータベースエンジンの信頼性、機能性、およびパフォーマンスの向上をすぐにお客様がテスト出来る環境を提供することで、お客様のリリースサイクルを数週間短縮することが可能になります。PostgreSQLのプレビュー版は、PostgreSQLコミュニティによってGA版がリリースされ、その後Amazon RDSでサポートされるまでAmazon RDSデータベースプレビュー環境で使用できます。 Amazon RDSデータベースプレビュー環境は、最新世代のインスタンスクラス(現在のところT2、M4、およびR4)でSingle-AZインスタンスとMulti-AZインスタンスの両方をサポートし、KMSキーを使用した透過的暗号化もサポートしています。Amazon RDSデータベースプレビュー環境データベースインスタンスは、最大60日間保持された後、自動的に削除されます。Amazon RDSデータベースのスナップショットは、プレビュー環境で作成し、データベースインスタンスの作成や復元に使用できますが、プレビュー環境内でコピーしたり、プレビュー環境外にコピーしたりすることはできません。代わりに、PostgreSQL標準のダンプとロード機能を使用して、データベースのロードとアンロードを行うことができます。 既存のAmazon RDSプロダクション環境のSLAはAmazon RDSデータベースプレビュー環境のインスタンスには適用されません。また、プレビュー環境で作成されたインスタンスについては、Amazon Customer Supportでサポートチケットを開くことはできません。私たちは、Amazon RDSデータベースプレビュー環境向けのフォーラムを作成しました。Amazon RDSチームは、PostgreSQLデータベースの候補バージョンとAmazon RDSデータベースプレビュー環境の両方に関する情報などをこちらで共有致します。 Amazon RDSデータベースプレビュー環境は今日からご利用可能です。詳細については、http://aws.amazon.com/rds/databasepreviewを参照してください。   翻訳は星野が担当しました。原文はこちら

Read More

Amazon RDS for PostgreSQL バージョン: 9.3.x リタイアメントのお知らせ

本投稿は、こちらのフォーラムでご案内されたアナウンスメントの参考和訳です。 本アナウンスメントは、Amazon RDS が RDS for PostgreSQL のバージョン9.3のサポートを2018年9月5日をもって終了することをお知らせするものです。 Amazon RDSは2013年からPostgreSQLメジャーバージョン9.3をサポートしています。本リリースの後、機能、セキュリティ、信頼性、パフォーマンスの観点で大幅な改善がなされたメジャーバージョンが続々とリリースされています。PostgreSQLコミュニティは、PostgreSQL 9.3のリリース終了時期を2018年9月と発表しています。コミュニティサポートモデルに合わせて、AWSは9.3.10, 9.3.12, 9.3.14, 9.3.16, 9.3.17, 9.3.19, 9.3.20, 9.3.22 のマイナーバージョンを含めて、メジャーバージョン9.3のサポートを終了いたします。Amazon RDS では引き続き、バージョン9.4 以降の PostgreSQLデータベースをサポートいたします。 できるだけ早いタイミングで、Amazon RDS PostgreSQL データベースインスタンスをバージョン9.6, もしくは、バージョン10 にアップグレードすることを推奨します。その際、RDS のメジャーバージョンアップグレードの機能をご利用いただき、次のバージョンにアップグレードできます。アップグレードを開始するには、AWS マネジメントコンソールにて、「Modify DB Instance(DB インスタンスの変更)」ページに移動し、データベースのバージョンをPostgreSQLの新しいメジャーバージョンに変更します。 [Apply Immediately(すぐに適用)]オプションを選択すると、「Modify DB Instance(DBインスタンスの変更)」ページを終了した直後にアップグレードが開始されます。変更をすぐに適用しない場合は、その後のメンテナンスウィンドウ中にアップグレードが実行されます。 RDS for PostgreSQL のメジャーバージョンのアップグレードの詳細については、PostgreSQL DB エンジンのアップグレードを参照してください。 Amazon RDS PostgreSQL 9.3 のリタイアメントプランの一環として、2018年8月6日 以降、AWSコンソールを使用して新たな PostgreSQL 9.3 インスタンスを作成することが出来なくなります。2018年11月には、残されている 9.3 インスタンスに対する、PostgreSQL […]

Read More

AWS Database Migration Service と AWS Schema Conversion Tool がソースとしての IBM Db2 LUW をサポート開始

AWS SCT がLinux、UNIX、Windows (LUW) 用の IBM Db2 からAWS上でサポートされているオープンソースデータベースにオブジェクトを変換できるようになりました。これには Amazon RDS for PostgreSQL と RDS for MySQL、Amazon Aurora (MySQL and PostgreSQL compatible) を含みます。同時に、AWS DMS のソースとしての IBM Db2 for LUW の一般リリースも発表します。この発表は、AWS DMS を使用して Db2 for LUW から AWS DMS でサポートされているすべてのターゲットに移行できることを意味します。これらの機能は、Db2 for LUW からクラウドへの移行に役立ちます。

Read More

MySQLデータベースをAuroraへ移行する方法をマスターする

By Nathaniel Kangpan, SVP Technology & Data Services, Kepler Group 私は過去12ヶ月の間に(a)クラウドベースのインフラストラクチャを使うことに踏み出していない、もしくはその様なチームがいない(b)2018年のロードマップにクラウドを使うことが乗っていないクライアントに会っていません。ハードウェアからクラウドへ移行した場合のTotal Cost of Ownership(TCO)の節約は無視できません。 しかし、所有しているハードウェアからAWSのようなクラウドベースのインフラストラクチャに移行する際には、本当に何を期待するべきですか? Amazon EC2などの仮想サーバー上にソリューションを複製するだけでいいですか、Amazon RDSのようなマネージドサービスを増やすべきででしょうか? Kepler Groupでは、インフラストラクチャの95%以上が2014年後半からAWS上で稼働しています。過去数年にわたり、多くのお客様に機転となる時に何を期待しているかをアドバイスしました。私達はマーケティングデータベース管理サービスを提供しています。クライアントとの最も一般的な議論の1つは、リレーショナルデータベースをAWSに移行する際に抱えるメリットと課題を理解する助けとなることです。   Global Fortune 100の例 私たちは通常、Global Fortune 100クライアントのために完成した代表的なプロジェクトを中心に、データベースクラウドの移行に関する会話行っています。この特定のクライアントにとって、私たちは最初に、データセンターのハードウェア上にMySQLデータベースを構築しました。その後、MySQLを実行しているEC2インスタンスに移行し、最終的にAmazon Aurora MySQLに移行をしました。クライアントのユースケースと基本的なデータスキーマは、この間にあまり変化しませんでした。そのため、私たちはソリューションの管理がますます効率化されるようになるにつれ、同じMySQLデータベースを複数のフレームワークで実行することの長所と短所について多くのことを学びました。 今回の対象のデータベースは、マーケティングおよびセールスカスタマーリレーションシップマネジメント(CRM)データベースでした。一連の電子メールおよびセールスチームベースのマーケティングキャンペーンで、レポートおよび分析ユースケースのために複数のサードパーティソースにデータを継続的に集約しました。私たちのチームは、データベースの管理に加え、マネージドサービスとしてレポートと分析の提供を担当する主なユーザーです。 このプロジェクトは、スコープと予算の面で一般的に管理していた物の小規模なものでした。クライアントのニーズを満たすことに加えて、次の点に細心の注意を払う必要がありました: データベースメンテナンスの負荷を低く抑える インフラストラクチャコストの制限 信頼性の高いバックアップおよびリカバリプロセスを確保する 前述のように、データベース用に3つの異なるインフラストラクチャソリューションを使い、各バージョンのメリットと課題についてかなりのことを学びました: v1.0:オンプレミスハードウェア上のLinuxでMySQLを実行する v2.0:Amazon EC2上のLinuxでMySQLを実行する v3.0:MySQLと互換性を持つAmazon Aurora 次の移行の概要では、各バージョンへの移行の決定と、その過程で得た利点と課題について説明します。   Version 1.0: オンプレミスハードウェア上のLinuxでMySQLを実行する 2013年後半にこのクライアントとの関係を開始したとき、クラウドベースのサービスを検討し始めましたが、私たちのインフラストラクチャは、データセンターを基盤とするハードウェアソリューションでした。クライアントサービスや厳しい締め切りで働いている多くの人が理解できるように、理想的な長期的なソリューションを最初から構築するのではなく、迅速に稼働させることを優先する必要がありました。私たちは、オンプレミスハードウェア上のLinuxとMySQLの組み合わせから開始することにしました。これは、このプロジェクトで作業しているエンジニアが最も慣れている構成だったからです。 利点 この初期のアプローチの唯一のメリットは、エンジニアがハードウェア+ Linux + MySQLの構成でよく作業していたことです。必要な開発フレームワーク、データ転送メカニズムなどはすべてかなり理解されており、大きな技術的驚きは期待できませんでした。これにより、限られたAWS経験を持つクラウドベースのソリューションに飛び込むのとは対象的に、納期と予算に対するリスクを最小限に抑えながら顧客の設定した期限を迎えることができるという自信が得られました。 チャレンジ しかし、ハードウェア環境で解決策を維持することには、かなりの数の問題がありました。AWSへの移行を後で行うまでは、これらの非効率性を十分に理解していませんでした。具体的には、クラウドと比較してハードウェアソリューションでは次のような課題に直面しました: かなり高いサーバーとデータベースのメンテナンスとアップグレードの運用負荷 時間の経過とともに増加するデータ量に対応する、シームレスではない垂直スケーリングプロセス […]

Read More

Amazon Aurora MySQLやAmazon RDS for MySQLへIAM authenticationを利用してSQL Workbench/Jから接続する

この記事では、Aurora MySQLクラスタに接続するために既に使用しているツールでIAM認証を使用する方法を説明します。この手順は、Amazon RDS for MySQLインスタンスでも同様にご利用頂けます。提供されたスクリプトを使用して、リソースをプロビジョニングしたり、IAM認証用に環境を構成したりすることができます。

スクリプトを使用してIAM認証情報を使用して、mysqlコマンドラインツールまたはSQL Workbench / Jを使用してクラスタに接続します。GitHubリポジトリでは、この投稿で使用されているコードサンプルをご覧いただけます。

Read More