Amazon Web Services ブログ

Category: Amazon RDS

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

新機能: Amazon RDS for Oracle Database がvCPUの削減や最適化に対応

すべてのAWSサービスと同様に、Amazon RDS のロードマップは、主にお客様からのフィードバックや製品改善リクエストに基づいています。Oracle RDS for Oracle Database でデータベースワークロードを実行しているエンタープライズの複数のお客様から、私たちはフィードバックを受けました。そのフィードバックとは、物理コアに対するRAMの比率を Amazon RDS for Oracle より大幅に高くすることで、Oracleのワークロードを実行しているエンタープライズのお客様は、ソフトウェアライセンスの価値を最大化しているというものでした。

この記事の目的は、Amazon RDS 上の Oracle Database のための2つの新機能を使用することで、仮想CPU (vCPU) の数を減らし、ライセンスコストを最適化する方法を説明することです。

Read More

Amazon RDS for MySQL および MariaDB に MariaDB MaxScale を使用して Binlog Server を設定する方法

Amazon RDS for MySQL と Amazon RDS for MariaDB の主要機能の 1 つが リードレプリカ を作成する機能です。AWS マネジメントコンソールまたは AWS CLI を使用して、1 つのマスターデータベースインスタンスについて、最大 5 つのレプリカを簡単に作成できます。Amazon RDS は、マスターのバックアップを作成し、バックアップをレプリカとしてリストアし、マスターとレプリカへのレプリケーションチャネルを確立する、といった作業すべてを処理します。Amazon RDS のレプリケーションを完全に自動化した処理は、マネージドレプリケーションと呼ばれます。 非標準のレプリケーショントポロジを求めている場合は、Binlog Server を使用できます。たとえば、レプリカが 5 つ以上必要な場合や、下流のアプリケーションにレプリケーションログレコードを転送する場合です。Binlog Server はレプリカとは違い、マスターのログレコードを使用せず、マスターと 1 つ以上のサブスクライバーの間にキャッシングレイヤーを提供します。今回の記事では、このアプローチを使用した場合の利点 (といくつかの制限) について説明します。MariaDB MaxScale と ノンマネージドレプリケーション を使用して、Amazon RDS for MySQL および MariaDB に Binglog Server をセットアップする作業を紹介します。 Amazon RDS for MySQL および MariaDB […]

Read More

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