Amazon Web Services ブログ

Category: Amazon RDS

Amazon CloudWatch を使用して Performance Insights メトリックにアラームを設定する

Amazon RDS Performance Insightsは、重要ななパフォーマンスメトリックを Performance Insights から Amazon CloudWatchに送信できる機能を、先ごろリリースしました。この機能を使うと、これらのメトリックに関するアラートを設定できます。 Performance Insights が有効になっている場合、CloudWatch に次の 3 つのメトリックが自動的に送信されます。 DBLoad DBLoadCPU DBLoadNonCPU これら 3 つのメトリックを、次に解説します。 DBLoad 最初のメトリック、DBLoadは、Performance Insights の中核となるものです。DBLoad は、同時にアクティブとなるデータベース接続数の尺度となります。この記事の中でセッションと呼んでいるアクティブな接続とは、データベースが結果を返さなかったデータベースにクエリを送信する接続のことです。クエリが送信される間、およびクエリ結果が戻される前、クエリはいくつかある状態のいずれかの状態となります。つまり、CPU 上で実行されているか、CPU を待っているか、ロックや I/O などのリソースが終了するのを待っているか、他のデータベースリソースへのアクセスを待っているかのいずれかの状態です。 クエリの処理中、通常、クエリはこれらの状態の間で切り替わります。ただし、クエリは待機するのではなく、クエリを実際に処理している CPU 上で動く時間がすべてクエリに費やされるのが理想です。同時にアクティブとなっている接続数とその接続状態を確認することで、データベースの負荷をすばやく強力に把握できます。DBLoadは、アクティブな同時データベース接続の平均数である、平均アクティブセッション (AAS) で測定します。デフォルトでは、Performance Insights ダッシュボードにある DBLoad グラフの各ポイントが、1 分以上経過した平均時間です。 DBLoadは 2 つの種類に分かれます。 DBLoadCPU は、接続が CPU 上で実行されていた時間、または CPU 上で実行準備が整っている時間を表します。 DBLoadNonCPU は、接続が I/O、ロック、データベースバッファーなどのデータベースリソースを待機していた時間を表します。 以下では、DBLoadCPU を中心にお話しします。 DBLoadCPU アラートを設定する […]

Read More

Amazon RDS for SQL Server でデータベースメールをパワーアップ – アンダーアーマーが Amazon RDS for SQL Server でデータベースメールを運用する方法

データベースメールは Microsoft SQL Server で多用される機能の 1 つです。データベースメールは、SMTP サーバーを使用することにより、SQL Server からユーザーにメッセージを送信できるようにします。ここでご紹介するソリューションは、ご使用の SQL Server ワークロードが Amazon RDS 上にある場合に、データベースメールを使用するのに役立ちます。 データベースメールの使用例: テキストメッセージを送信する テキストまたはファイル添付でクエリの結果またはレポートを送信する エラーや通知のアラートを送信する ジョブが成功または失敗したときに、SQL エージェントジョブのステータスメッセージを送信する AWS のカスタマーであるアンダーアーマー社では、SQL Server のワークロードを Amazon RDS for SQL Server に移行する手立てを模索していましたが、RDS でデータベースメールがサポートされていないことがネックとなっていました。SQL のワークロードを Amazon RDS へ移行しようとしているカスタマーにとって、この問題は致命的です。 私はアンダーアーマー社のデータアーキテクト、Leonard Humphries とともにこの問題に対処することになり、2 人で次のようなソリューションを思いつきました。私たちは集中データベースメールハブに SQL Amazon EC2 インスタンスをプロモートしたのです。こうすることで、アンダーアーマー社のデータベースメール問題を解決できました。この記事では私たちのソリューションについて解説します。 使用した AWS のサービス Amazon RDS for SQL Server 既存の SMTP […]

Read More

AWS DevDay Tokyo 2018 Database トラック資料公開

Database フリークな皆様、こんにちは!AWS DevDay Tokyo 2018 Database トラックオーナーの江川です。 2018 年 10 月 29 日(月)〜 11 月 2 日(金)にかけて、AWS DevDay Tokyo 2018 が開催されました。本記事では、11/1(木)に実施された Database トラックのセッション資料をご紹介します。 セッション資料紹介に先立ち、お客様セッションとしてご登壇いただいた、Sansan株式会社間瀬様、株式会社ソラコム安川様、Amazon Pay 吉村様にお礼申し上げます。併せて、ご参加いただいた皆様、ストリーミング配信をご覧いただいた皆様ありがとうございました。   ●お客様セッション資料 AWSサービスで実現するEightの行動ログ活用基盤(Sansan株式会社 間瀬哲也様) AWSサービスで実現するEightの行動ログ活用基盤 from Tetsuya Mase DynamoDB Backed なテレコムコアシステムを構築・運用してる話(株式会社ソラコム 安川 健太様) AWS Dev Day Tokyo 2018 | Amazon DynamoDB Backed な テレコムコアシステムを構築・運用してる話 from SORACOM,INC DynamoDBとAmazon Pay で実現するキャッシュレス社会 […]

Read More

Amazon RDS for MySQLの delayed replicationで障害から復旧を行う

Amazon RDS for MySQLでdelayed replicationをサポートしました。これにより、レプリカデータベースがソースデータベースより遅延する期間を設定できます。標準のMySQLレプリケーション設定では、ソースとレプリカの間の遅延が最小限に抑えられています。今回のアップデートで意図的な遅延を導入するオプションを選べるようになりました。 遅延は、人為的なエラーから復旧させる必要がある場合に非常に役立ちます。たとえば、誤ってプライマリデータベースからテーブルを削除した場合、レプリカで同じクエリを実行する必要はありません。テーブルが削除される直前でレプリケーションを停止し、レプリカをスタンドアロンインスタンスに昇格させることができます。このブログ記事では、delayed replicationを使用して、このようなシナリオから復旧させる方法をご紹介します。 次の図は、遅延が3600秒(1時間)に設定されたレプリカを人為的エラーから回復する方法を示しています。まず、レプリケーションを停止します。次に、ログの問題の箇所を見つけ、問題のクエリが実行される直前までトランザクションを実行し。最後に、レプリカをマスターに昇格させます。   前提条件 delayed replicationをチェックする前に、Amazon RDS for MySQLソースデータベースインスタンスでMySQL 5.6.40または5.7.22以降が必要です。また、インスタンスに接続するためのMySQLクライアントと、データベースにアクセスできる適切なセキュリティグループが必要です。 バイナリログを十分な時間保持していることを確認してください。バイナリログの詳細については、 MySQL Binary Logsを参照してください。次のコマンド例は、保持期限を24時間に設定する方法を示しています。 call mysql.rds_set_configuration(‘binlog retention hours’, 24);   シナリオの設定 既存のAmazon RDS for MySQLデータベースを既存のリードレプリカで使用するか、新しいデータベースを作成します。このブログ記事では、既存のRDS MySQLデータベースを利用し、新しい読み取りレプリカを作成します。 データベースの作成 MySQLインスタンス用のAmazon RDSをまだお持ちでない場合は、作成をしてください。クライアントマシンからのアクセスを許可するセキュリティグループを使用してデータベースを構成してください。作業したいMySQLデータベースがすでにある場合は、この手順をスキップしてください。 AWSマネージメントコンソール、AWS CLI、AWS SDK、またはAWS CloudFormationテンプレートを使用して、MySQLデータベース用のRDSを作成します。MySQLインスタンスの作成を支援する必要がある場合は、Create and Connect to a MySQL Database with Amazon RDSの手順に従ってください。次のスクリーンショットは、すでに設定されて使用可能な1つのデータベースインスタンスを示しています。 データベースに接続する マスターデータベース・インスタンスが作成されて使用可能になったら、そのデータベースインスタンスに接続します。Amazon EC2 Linuxマシンを使用している場合は、次のコマンドに示すように、いくつかの環境変数を設定して余分なタイピングを省くことができます。 export REGION=”us-west-2″ export […]

Read More

Database Migration Service を使用して、リレーショナルデータベースから Amazon Kinesis に CDC データをロードする

多くの大企業は、タイムリーな情報を得るために、データ処理をバッチ処理からリアルタイム処理に移行しています。そうすることの課題は、リアルタイムのデータ処理アーキテクチャが着信データストリームに追いつけなければならないということです。これには、強固な耐障害性と伸縮性が必要です。 このブログ記事では、リアルタイムのデータ処理アーキテクチャと、Amazon RDS for SQL Server データベースへの変更をキャプチャして Amazon Kinesis Data Streams に送信する方法について解説します。Amazon S3 および AWS Lambda をデータの初期ロードに使用する方法と、AWS Database Migration Service を進行中のレプリケーションに使用する方法を示します。 AWS では、Amazon Kinesis Data Streams、AWS Database Migration Services (DMS)、AWS Lambda などのデータ処理を適正に行うためのサービスを数多く提供しています。DMS は、既存のデータを移行し、進行中の変更データをソースシステムからターゲットシステムにレプリケートするのに役立ちます。 前提条件および仮定 このソリューションを自分で使用するには、AWS のサービスへのアクセスを提供する AWS アカウントが必要です。 サービスは us-east-1 リージョンで作成する必要があり、ネットワーキングの考慮事項を簡素化するために us-east-1 リージョンの同じ VPC で設定する必要があります。 Lambda 関数のコンパイル済み Java コードは、この Amazon Repository にある ZIP ファイルに含まれています。S3 バケットを作成し、ZIP […]

Read More

Amazon Kinesis Data Streams および AWS Lambda を使用して、Amazon RDS for PostgreSQL の変更をストリーミングする

この記事では、Amazon Relational Database Service (Amazon RDS) for PostgreSQL 中央データベースを、Amazon Kinesis Data Streams にその変更をストリーミングすることで、他のシステムと統合する方法について説明します。以前の記事、「Amazon Kinesis を使用したデータベースの変更をストリーミングする」では、変更を Kinesis へストリーミングすることによって、MySQL データベース用の中央 RDS を他のシステムに統合する方法についてお話ししました。この記事では、さらに進んで、AWS Lambda 関数を使用して Amazon RDS for PostgreSQL の変更をキャプチャし、その変更を Kinesis Data Streams にストリーミングする方法を説明します。 次の図は、分散システムにおける一般的なアーキテクチャ設計を表しています。これには、信頼できる唯一の情報源と呼ばれる中央ストレージと、この中央ストレージを使用するいくつかの派生「サテライト」システムが含まれます。 この設計アーキテクチャーを用いて、データの整合性を維持するためにこのシステムのトランザクション機能を活用しながら、リレーショナルデータベースを中央データストアとして使用することができます。このコンテクストにおいての派生システムとは、全文検索システムであり、この信頼できる唯一の情報源の変更を観察し、それらの変更を変換かつフィルタリングし、最終的にその内部インデックスを更新するものです。もう 1 つの例は、OLAP クエリにより適したカラムナストレージです。一般に、中央リレーショナルシステムの個々の行が変更された時にアクションを実行する必要があるシステムはどれも、派生データストアにするのに適しているとい言えます。 この種のアーキテクチャの単純な実装では、変更された行を検索するために定期的にクエリを発行する派生システムがあります。これは基本的に SELECT ベースのクエリ (バッチ処理システムとも呼ばれます) で中央データベースをポーリングします。一方で、このアーキテクチャにより適した実装は、非同期の更新ストリームを使用するアーキテクチャです。 データベースには通常、行のすべての変更が格納されるトランザクションログがあります。ですので、この変更のストリームが外部のオブザーバシステムに公開されている場合、このシステムはこれらのストリームに接続し、行の変更を処理およびフィルタリングできる可能性があります。 この記事では、PostgreSQL を中央データベースとして、また Kinesis Data Stream をメッセージバスとして使用して、この基本的な実装を紹介します。 通常、PostgreSQL Write-Ahead Logging (WAL) ファイルは、マスター上のすべての変更を読み込んだ後、ローカルに適用するリードレプリカに公開されます。リードレプリカからデータを読み取る代わりに、wal2json 出力プラグインを用いた論理デコードを使用して、WAL の内容を直接デコードします。プラグインはこの GitHub […]

Read More

RDS for MySQL データベースを Amazon Aurora へ移行するためのベストプラクティス

MySQL は世界で最も普及しているオープンソースデータベースです。それにも関わらず、多くの利用者が一様にバックアップ、高可用性の確保にかかる膨大な手間に苦心していたり、また MySQL のスケーリングが複雑である、時間がかかる、あるいはその両方であると感じています。 お客様がそうした既存の MySQL 環境から Amazon RDS for MySQL へ移行する最大の理由の 1 つはそこにあります。Amazon RDS はポイントインタイムリカバリや高可用性などのオプションを複雑な設定など一切なしですぐに使用できる機能を提供します。RDS for MySQL はさらに、ソースあたり 5 つのリードレプリカに対応しています。このように、バイナリログ (binlog) レプリケーションを手動で設定したり、保守したりする必要なく、簡単にワークロードをスケールできます。 MySQL にハイエンドコマーシャルデータベースのパフォーマンスおよび可用性との互換性を期待するのであれば、MySQL データベースを Amazon Aurora に移行することでそれを実現できます。MySQL との互換性を持つ Amazon Aurora を使用することで、fast database clones および autoscaling replicas などの機能を活用できます。また、AWS Lambda および Amazon CloudWatch Logs といった他の AWS サービスとのネイティブ統合も可能になります。これらの機能に加えて、Amazon Aurora はまた、3 つのアベイラビリティーゾーンをまたぐデータのレプリケーションにより、優れた耐久性を実現します。また、最大で 15 個の Aurora レプリカにスケール可能で、すべてが通常では 20 […]

Read More

Amazon RDS の手動スナップショットを管理するための通知メカニズムを構築する

ビジネスの規模に関係なく、ビジネスを遂行する上でデータが不可欠な要素であることは隠すまでもないことです。多くの企業は、リレーショナルデータベースを使用してビジネスデータをホストしています。その結果、バックアップとリカバリはビジネスを継続的に実行するための重要な側面になっています。Amazon RDS の顧客は、複数の戦略を活用して、自動スナップショットと手動スナップショットの両方でデータをバックアップします。データベースを削除すると自動スナップショットも削除されるため、Amazon RDS の手動スナップショットを使用して寿命を延ばすことができます。また、アカウント間およびリージョン間での共有機能を備えた災害対策用の手動スナップショットを使用することもできます。Amazon RDS は、単一のスナップショットからデータベース全体をリカバリできるため、さまざまなバックアップニーズに対応します。 この記事では、RDS インスタンスと Aurora クラスターの両方の Amazon RDS 手動スナップショットを管理するためのサーバーレスの通知メカニズムを構築する方法を示します。実行する主なアクティビティは次のとおりです。 RDS インスタンスと Aurora クラスターのリストを指定されて、定義されたバックアップ間隔で手動スナップショットを作成する バックアップの保存期間に基づいて、古い手動スナップショットを削除する このアクティビティの最後に、新しく作成された手動スナップショットと古い削除されたスナップショット (存在する場合) のリストが登録しているユーザーに通知される。 詳細については、README.md ファイルを参照し、GitHub リポジトリからソリューションを起動してください。 サーバーレスソリューションのアーキテクチャ このサーバーレスソリューションは、AWS CloudFormation スクリプトに組み込まれています。このスクリプトは、ユーザー指定のスナップショットバックアップ間隔、バックアップ保持期間、RDS インスタンス名のリスト、通知用の E メールアドレスなどのさまざまな入力を受け取ります。Amazon CloudWatch Events ルールは、スケジュールに従って AWS Step Functions ステートマシンを起動します。このステートマシンは手動スナップショットを作成し、古いスナップショットを削除し、最終的に Amazon SNS に通知を送信します。SNS は、ユーザー提供の E メールアドレスに E メールを送信します。 Amazon RDS 手動スナップショット (RDS インスタンスと Aurora クラスター) を管理するソリューションは、次の […]

Read More

カリフォルニア州立工科大学ソフトウェア工学科のキャップストーンで MySQL のキャプチャーリプレイを AWS に構築

カリフォルニア州立工科大学は、「Learn by Doing」(実践で学ぶ) という同大学の理念にのっとり、ソフトウェア工学科のキャップストーンを開講しました。この科目で学生は 1 年を通じて協働産業プロジェクトとはどういうものかを体験します。今回で David Janzen 博士がこの科目を教えるのは 10 年目になります。博士は、この長さの科目に最適なプロジェクトを見付け、適切な難易度を与えることに長けています。 今年のプロジェクトは「AWS MyCRT」でした。これは「MySQL Capture and Replay Tool」のことです。 Amazon RDS のチームがサポートしました。30 人の学生が能力に基づいてチームに分かれた結果、5 つの多才なチームができ、それぞれが独自の MyCRT を実装しました。 チーム会議、顧客との会議、Amazon RDS チームの Brian Welcker、Rosa Thomas、Sachin Honnudike との要件導出がプロジェクトを方向付けました。これらの会議から、チーム Titans が以下のようなプロジェクトの背景を導き出しました。 アマゾン ウェブ サービス (AWS) では、Amazon のマネージドデータベースサービスである Relational Database Service (RDS) が利用できます。さまざまなサーバーハードウェアから、顧客の要求に最適なものを選ぶ必要があります。しかし、性能要求に合うハードウェアの選択は難しい判断です。また、性能が不足していたり、不必要に性能が高かったりするのも大変不経済です。Amazon の顧客は、異なるサーバー設定の間で性能を比較し、要求に対して適切なサーバーリソースかどうかを確認したいと言っていました。 この問題に対する MyCRT のソリューションは、RDS MySQL データベースでのワークロードとメトリクスをキャプチャーすることです。これにより、キャプチャーしたワークロードを異なるデータベース設定でリプレイし、メトリクスを収集することができます。また、収集した結果を解析することにより、ビジネス要求に対して理想的な MySQL と RDS の設定を選ぶこともできます。どのチームも、AWS […]

Read More

Amazon RDS Performance Insights が一般利用可能に

本日、Performance Insights が一般利用可能になったことを発表します。Performance Insights を使用すると、パフォーマンス問題が発生したときのボトルネックを簡単に特定し、対処方法を見つけることができます。

一般利用可能に合わせて、Performance Insights は次の機能を導入します。

* 7日間のパフォーマンスデータ履歴
* パフォーマンスデータの長期保持オプション
* SDKとAPIの一般公開

Read More