Amazon Web Services ブログ

Category: RDS for MySQL

Performance Insights で Amazon RDS for MySQL をチューニングする

Amazon RDS Performance Insights は、Amazon RDS への直感的なチューニングインターフェイスを提供し、RDS データベースのパフォーマンスの問題を発見して調査するのに役立ちます。Performance Insights のルックアンドフィールは、RDS for MySQL、RDS for PostgreSQL、Amazon Aurora など、すべてのデータベースエンジンタイプで共通です。けれども、エンジンはどれも実装の点で少し異なります。 Performance Insights は、エンジンに関係なく常にデータベースの負荷と上位の SQL を表示できます。エンジンはどれも、拡張データの保持や Amazon CloudWatch との統合など、Performance Insights の機能をサポートしています。ただし、データベースエンジンの種類によっては、 Performance Insights はエンジンのネイティブパフォーマンス計測に基づいてわずかに異なる情報を表示します。 たとえば、PostgreSQL との互換性を持つ Aurora では、データベースの負荷が PostgreSQL 10 の待機イベントによって細分化されています。MySQL 互換性 と RDS MySQL を備えた Aurora では、 MySQL Performance Schema 待機イベントによって細分化された負荷が表示されます。Performance Insights は、各エンジンタイプのネイティブ待機イベント計測を待機イベント用に消費することにより、各エンジンのネイティブパフォーマンス計測に忠実でありながら、各エンジンタイプ間で同様のルックアンドフィールを維持することができます。 2018 年 8 月 28 日、バージョン […]

Read More

EMR – Sqoop を使用して RDBMS またはオンプレミスデータを EMR Hive、S3、および Amazon Redshift に移行する

 このブログ記事では、AWS のお客様が Apache Sqoop ツールの使用によって利益を得る方法について説明します。このツールは、データをリレーショナルデータベース管理システム (RDBMS) から AWS の EMR Hadoop Distributed File System (HDFS) にインポートし、データを Hadoop で変換して、それをデータウェアハウス (例: Hive または Amazon Redshift) にエクスポートするために設計されています。 Sqoop ツールのデモを行うために、この記事では以下の 3 つのシナリオにおいて、Amazon RDS for MySQL をソースとして使用し、データをインポートします。 シナリオ 1 — AWS EMR (HDFS -> Hive および HDFS) シナリオ 2 — Amazon S3 (EMFRS)、次に EMR-Hive シナリオ 3 — S3 (EMFRS)、次に […]

Read More

ProxySQL と Percona Monitoring and Management で、Amazon RDS for MySQL のデプロイを強化する

本日は、Percona 社の Michael Benshoof 氏によるゲストブログ投稿です。Benshoof 氏によると、「Percona 社は、3 千人以上の顧客をグローバルに持ち、バイアスのない最善の企業規模サポート、コンサルティング、管理サービスおよびトレーニングを提供し、リスクと運用コストを減らす対策を提供しています。さらにオンプレミスとオープンソース環境でのオープンソースデータベースのためのソフトウェアを使って、ロックインを排除し、機敏性を高め、ビジネスの成長を可能にしています。」 」 クラウドにアプリケーションをデプロイする予定で、データ層には Amazon RDS for MySQL を利用しようと考えている? それはいい選択ですね! それでは、アーキテクチャを最大限に活用するためのベストプラクティスをいくつか見てみましょう。 Amazon RDS for MySQL とは RDS for MySQL は、アマゾン ウェブ サービス (AWS) スタック内でサービスを行う管理データベース (DBaaS) です。RDS for MySQL では、次のような細かな操作作業の多くを処理します。 バックアップ ポイントインタイムリカバリ マイナーバージョンの自動アップグレード 新しいレプリカの追加 自動フェイルオーバー (Multi-AZ を実行している場合) このように、RDS for MySQL は、クラウド上で動作するデータ層にとって最適なオプションです。よく見られるフェールオーバーは標準の Multi-AZ デプロイで対応可能はもちろんのこと、RDSの回復力と使いやすさの向上も目指すことが可能です。これらの方法により、ワークロードの増加に合わせて、よりシームレスにデプロイおよびインフラストラクチャを拡張できます。 標準的なベストプラクティス 任意のアーキテクチャ (クラウドまたは物理データセンター内にある) を一から設計する場合、不具合への対応を準備しておくことは大変重要です。障害に対する準備が整ったインフラストラクチャの設定は、耐障害性のある環境を設計する上でかなめとなります。そのため、本番でのデプロイ (または高可用性が必要なデプロイ) の場合は、少なくとも以下を実行する必要があります。 プライマリインスタンスに、Multi-AZ を指定する […]

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

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

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

カリフォルニア州立工科大学ソフトウェア工学科のキャップストーンで 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 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

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

AWS Glue を使って、分析処理のためにデータを抽出、変換、ロードする方法 (パート 2)

企業が直面している大きな課題に、信頼性の高い抽出と変換、およびロード (ETL) プロセスをいかに確立し維持するかがあります。なぜならこれらは、データから値と正しい情報を取り出すのに重要だからです。従来の ETL ツールは使用するにも複雑で、実装、テスト、およびデプロイに数カ月かかることもあります。ETL ジョブを作成すると、データフォーマットとスキーマが頻繁に変更され、新しいデータソースを常に追加する必要があるため、それらを維持するのは骨が折れる作業となります。 一方で AWS Glue は、データの発見、分類、クリーニング、充実化、および移行に関連する未分化の重労働の多くを自動化できるため、データ分析により時間を費やすことができます。AWS Glue はデータソースを自動的にクロールし、データフォーマットを識別して、適切なスキーマと変換を提案します。つまり、データフローを手作業でコーディングする必要がないのです。 AWS Glue は、分析用にデータセットを移行および変換する作業を簡素化するよう設計されています。普及している Apache Spark 実行フレームワーク上に構築したサーバーレスの完全管理型サービスです。 2 部構成となっている移行についてのブログシリーズのパート 2 では、AWS CloudFormation スタックの構築を行います。このスタックを使用して、AWS Glue が Amazon Aurora MySQL データベースとの間でデータを抽出、変換、そしてロードする方法を解説します。ソースとして Amazon Aurora MySQL を、そして AWS Glue のターゲットとして Amazon Simple Storage Service (Amazon S3) を使用します。Amazon Athena を使って簡単なクエリとレポートを行うために、Amazon S3 に集中型データレイクを構築する方法についても説明します。Amazon Redshift をデータウェアハウス戦略の構築のために、データターゲットとして使用することもできます。この記事では、AWS Glue を開始し、必要に応じてカスタマイズするためのフレームワークを説明します。 AWS Glue には、3 つのコアコンポーネントがあります。 […]

Read More