Amazon Web Services ブログ

Category: Amazon RDS

Oracle パフォーマンスメトリクスに基づいた Amazon RDS インスタンスを大規模で適正なサイズにする

オンプレミスのミッションクリティカルなアプリケーションを商用データベースで稼働中のエンタープライズ企業で、コスト効率の高い、マネージド型データベースサービスをお探しのお客様がいらっしゃいます。リレーショナルデータベースのワークロードを移行するプラットフォームの 1 つ、Amazon RDS をおすすめします。RDS はサイズ変更が可能な容量を提供し、時間のかかる重い非個別型管理タスクに対応します。大規模なデータベースの移行では、適切なサイズのターゲット RDS DB インスタンスを多くのデータベースに作成できる、スケーラブルかつ効果的なソリューションが必要です。 この記事では、オンプレミスの Oracle パフォーマンスメトリクスに基づいた DB インスタンス を大規模で適切なサイズにするプロセスについて説明します。Python と SQL スクリプトを使用してオンプレミスデータベースから Oracle パフォーマンスメトリクスを収集する方法、および AWS Glue と Amazon Athena を使った DB インスタンスサイズのデータ分析と推奨事項を得る方法を解説します。このソリューションは、1 つのデータベースから多数のデータベースまでの DB インスタンスのサイズ調整に有効です。 概要 オンプレミスの Oracle ワークロードの検出を目的として、1 時間ごとの I/O、CPU、メモリ使用量の統計について Oracle 自動ワークロードリポジトリ (AWR) をクエリする SQL スクリプトが開発されました。Python スクリプトを検出するデータベースのリストを含む入力ファイルから読み込んで、各データベースをループ処理して SQL スクリプトを実行します。データベースごとに .csv 出力ファイルが生成されます。 目標は、少なくとも 1 か月のパフォーマンスメトリクスを収集し、DB インスタンスのサイズをより正確に推定することです。AWR の保存期間が 1 か月未満に設定されている場合、複数回スクリプトを実行できます。スクリプトはすべて […]

Read More

RDS Classic から Aurora MySQL へのミッションクリティカルな SaaS プロダクションワークロードの移行

Sumo Logic は、AWS スタックが成熟し始めた頃とほぼ同じ時期に創業しました。同社は当初、試行とテストが行われたインフラストラクチャを選択しましたが、同時に最先端のインフラストラクチャ、つまり Amazon RDS for MySQL インスタンスも選択しました。 けれども、時が経つにつれ、その選択で開発者のかなりの時間が取られるようになりました。開発者は、MySQL バージョンのアップグレード、データベース接続の増加によるインスタンスのスケーリング、顧客からのデータと需要の増大に伴うストレージのスケーリングに時間を使いました。 つまり、顧客に見えるダウンタイムを持つことと、古いバージョンの MySQL を長期間使用し続けることとの間に絶え間ない葛藤がありました。当社は、成長するにつれて見込まれる将来のワークロードに対する、より手を加えず、堅牢で柔軟なソリューションを必要としていました。 当社について Sumo Logic は、安全なクラウドネイティブのマシンデータ分析プラットフォームです。アプリケーションのライフサイクルおよびスタック全体にわたって、構造化データ、半構造化データ、および非構造化データからリアルタイムの継続的なインテリジェンスを提供します。 世界中の 2,000 人以上の顧客が最新のアプリケーションとクラウドインフラストラクチャを構築、実行、および保護するための分析と洞察を求め、Sumo Logic を当てにしています。Sumo Logic を利用すると、マルチテナントサービスモデルの優位性を得て、継続的なイノベーションへの移行を加速し、競争上の優位性、ビジネス上の価値、および成長を促進することができます。 Amazon Aurora に移行した理由 Amazon Aurora へ移行することで、Amazon が提供する従来の RDS の実装を超えるいくつかの利点がもたらされました。 完全マネージド: Aurora インスタンスとクラスターは、Amazon RDS によって完全に管理されています。この管理機能により、最小限のダウンタイムでスケーリング、ストレージの追加、アップグレードやパッチの適用を行うことができます。ほとんどの場合、これらはクライアントの中断を招くことなく行われます。これは、Sumo Logic の非常に高い成長率と規模をサポートしているインフラストラクチャチームにとって大きなメリットです。 高可用性と耐久性: 従来の MySQL に関する最大の懸念の 1 つは、メンテナンス、ネットワークパーティション、またはサービスの喪失に伴う、顧客に見える停止時間でした。Aurora はこれらの点ではるかに高い回復力をもたらします。 互換性: Aurora のカギを握る機能は MySQL との互換性です。つまり、クライアントでコードを変更する必要はありませんでした。導入するとすぐにうまくいきました。 デフォルトの VPC: […]

Read More

RDS SQL Server での SQLAgentOperatorRole の活用

SQL Server DBA およびユーザーは、SQL Server インスタンスでジョブをスケジュールするために SQL Server エージェントを長い間使用してきました。これは、スケジュールに従って、アドホックベースで、またはイベントに応じてジョブを起動できる便利なツールです。SQL Server エージェントは常に Amazon Relational Database Service (Amazon RDS) でサポートされていますが、権限が制限されています。たとえば、RDS マスターユーザーでも SQL Server Management Studio (SSMS) ユーザーインターフェイスを使用して、インスタンスでスケジュールされたすべてのジョブを確認することはできません。最近の RDS の変更により、より多くの権限がマスターユーザーに付与されており、上記の制限はなくなりました。このブログでは、権限への変更と、新しい権限をシームレスに使用する方法について説明します。 新しい SQL Server エージェントの権限 RDS SQL Server は、Enterprise、Standard、および Web エディションで SQL Server エージェントをサポートしています。RDS SQL Server インスタンスのマスターユーザーは、デフォルトで SQLAgentUserRole に追加されます。マスターユーザーは他のユーザーを SQLAgentUserRole に追加することもでき、このロールの一部であるすべてのユーザーは SQL エージェントジョブを作成できます。ジョブを作成したユーザーだけが、そのジョブを表示、有効化、無効化、編集、実行、開始、および停止できます。これは一部のユースケースでは十分ですが、このレベルのアクセスでは不十分なユースケースもあります。たとえば、メンテナンスジョブが個々のユーザーアカウントを使用して作成されるデータベース管理者 (DBA) のチームでは、ジョブを作成した DBA が多忙なときは別の DBA がジョブを開始することがあります。この要件やその他の要件に対処するため、2019 […]

Read More

PostgreSQL ユーザーとロールの管理

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30 年以上の開発作業を経て、PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。Oracle などの商用データベースから移行する場合、PostgreSQL はオープンソースデータベースの主要な選択肢と見なされています。アマゾン ウェブ サービス(AWS)は、管理された 2 つの PostgreSQL オプションを提供します:PostgreSQL および Amazon Aurora PostgreSQL 用の Amazon Relational Database Service(Amazon RDS)。この記事では、PostgreSQL でユーザーとロールを管理するためのベストプラクティスについて説明しています。 PostgreSQL を使用すると、きめ細かいアクセス権限を持つユーザーとロールを作成できます。新しいユーザーまたはロールには、各データベースオブジェクトに必要な権限を選択的に付与する必要があります。これはエンドユーザーに多くの力を与えますが、それと同時に、正しい許可を持つユーザーとロールを作成するプロセスを潜在的に複雑にしています。 PostgreSQL では、データベースユーザーに直接権限を付与することができます。ただし、グッドプラクティスとして、アプリケーションとアクセスの要件に基づいて、特定の権限のセットを持つ複数のロールを作成することをおすすめします。次に、各ユーザーに適切な役割を割り当てます。ロールは、データベースオブジェクトにアクセスするための最小権限モデルを強制するために使用するべきです。Amazon RDS および Aurora PostgreSQL インスタンスの作成中に作られたマスターユーザーは、他のユーザー、ロール、およびデータベースの作成などのデータベース管理タスクにのみ使用する必要があります。マスターユーザーはアプリケーションによって使用されるべきではありません。 PostgreSQL できめ細かいアクセスコントロールを設定するための推奨アプローチは次のとおりです: マスターユーザーを使用して、readonly や readwrite などのアプリケーションまたはユースケースごとにロールを作成します。 これらのロールがさまざまなデータベースオブジェクトにアクセスできるように権限を追加します。例えば、readonly ロールは SELECT クエリのみを実行できます。 機能にとって最低限必要な権限をロールに付与します。 app_user や reporting_user のように、アプリケーションごとまたは個別の機能ごとに新しいユーザーを作成します。 適切なロールをこれらのユーザーに割り当てて、ロールと同じ権限をすばやく付与します。例えば、readwrite ロールを app_user に付与し、readonly ロールを reporting_user に付与します。 […]

Read More

Amazon RDS for Microsoft SQL Server で、クロスアカウントのネイティブバックアップおよびリストアを設定する

Amazon Relational Database Service (Amazon RDS) は、Microsoft SQL Server データベースのネイティブバックアップおよびリストアをサポートしています。複数の AWS アカウントがある場合、Amazon RDS インスタンスと Amazon Simple Storage Service (Amazon S3) バケットが同じ AWS リージョンにあれば、これらのアカウント間でネイティブバックアップおよびリストアを実行することができます。これらの手順を進める前に、この要件を理解しておくことが重要です。 この記事では、Amazon RDS for SQL Server でクロスアカウントのネイティブバックアップおよびリストアを実行するために必要なアクセス許可とポリシーを設定する方法について説明します。この手順では、これらのリソースを含む以下の AWS アカウントがあることを前提としています。 アカウント A – Amazon RDS for SQL Server インスタンス アカウント B – Amazon S3 バケット すべての設定は、S3 バケットが存在するアカウント B で行う必要があります。アカウント B で以下の作業を行います。 IAM ポリシーを作成する。 ロールを作成し、信頼ポリシーを設定する。 […]

Read More

Amazon RDS for MySQL のパラメーターを設定するためのベストプラクティス。パート 3: セキュリティ、操作管理性、および接続タイムアウトに関連するパラメーター

このシリーズの前回のブログ投稿では、Amazon RDS for MySQL でレプリケーションを最適化するために使用する MySQL パラメータと、それらに関連するベストプラクティスについて説明しました。本日の記事では、RDS MySQL 環境でさまざまなセキュリティ機能を実装するために最も重要で一般的に使用されている MySQL パラメータについて説明します。また、RDS DB インスタンスの操作管理と問題のトラブルシューティングに役立つパラメータについても説明します。さらに、照合順序と文字セットに関連するいくつかの便利なパラメータについても説明します。 セキュリティに関連するパラメータ 今から、セキュリティ関連の各パラメータを設定するベストプラクティスをご紹介します。 init_connect このパラメータは、接続する各クライアントに対して実行するサーバーの文字列を定義します。このパラメータにはデフォルト値はありません。文字列は、セミコロンで区切られた 1 つ以上の SQL 文で構成されています。 たとえば、このパラメータを使用して、どのデータベースユーザーがデータベースに正常に接続したかの簡単な監査を作成できます。そのためには、まず監査テーブルとトリガーを作成します。その後、init_connect 値をトリガー名に設定します。設定したら、クライアントがパラメータを接続するたびに、接続の詳細が監査テーブルに書き込まれます。 次の例のように、このパラメータを使用して特定のユーザーアカウントの自動コミットを無効にすることもできます。 init_connect = ‘set autocommit=case current_user() when ‘test@localhost’ then 0 else 1 end’. old_passwords このパラメータは、PASSWORD 関数で使用するパスワードハッシュ方式を制御します。また、IDENTIFIED BY 句を使用してパスワードを指定する CREATE USER ステートメントおよび GRANT ステートメントによって実行されるパスワードハッシュにも影響します。 このパラメータを有効にしないことを強くお勧めします。有効にした場合、PASSWORD 関数は安全でないパスワードハッシュを使用してしまうからです。このパラメータのデフォルト値は 0 で、これは MySQL バージョン 4.1 のネイティブハッシュを使用します。 default_password_lifetime […]

Read More

Amazon RDS for MySQL のパラメータ設定 パート 2: レプリケーション関連のパラメータ

このシリーズの前回のブログ投稿では、Amazon RDS for MySQL のパフォーマンスを調整および最適化するために使用する MySQL パラメータと、それらに関連するベストプラクティスについて説明しました。今回の投稿では、RDS MySQL 環境でのレプリケーション構成とレプリケーションの最適化に使用される最も重要な MySQL パラメータについて説明します。 シングルスレッドおよびマルチスレッドの両方のレプリケーションに関連するパラメータ 以下に、シングルスレッドのレプリケーションとマルチスレッドのレプリケーションの両方に使用できるパラメータと、それぞれを設定するためのベストプラクティスの提案を示します。 sync_binlog sync_binlog オプションは、MySQL がバイナリログをディスクにフラッシュする方法をコントロールします。 sync_binlog のデフォルト値は 1 です。マスターサーバで、sync_binlog が 0 に設定されているとディスクと同期しません。この場合、他のファイルと同様に、バイナリログの内容をフラッシュするタイミングはオペレーティングシステムに依存します。したがって、この設定は、MySQL がバイナリログ (binlog) をディスクにフラッシュしないようにすることでレプリケーションのパフォーマンスを向上させます。この方法で、最高のパフォーマンスが得られます。 ただし、MySQL がクラッシュした場合、いくつかのトランザクションが失われる可能性があります。通常、確実にレプリカをマスターと同期させるために、レプリカを再構築する必要があります。バックアップを無効にし、「チェーン接続された」リードレプリカがないRDS リードレプリカでは、binlog を同期する必要がないため、sync_binlog は適用されません。バイナリログが生成されないように、レプリカのバックアップ保存期間を 0 に設定することをお勧めします。 ただし、データの損失を最小限に抑えるには、レプリカソースで sync_binlog パラメータを 1 に設定する必要があります。設定する最善の値は、パフォーマンスと耐久性のどちらを優先するかによって異なります。 binlog_row_image binlog_format パラメータを使用すると、バイナリログでサポートされている 2 つのイベントフォーマットを指定することができます。STATEMENT と ROW です。行ベースのフォーマットを使用すると、非決定性のクエリをログに記録することができるので、レプリカで一時テーブルは作成されません。一方、ステートメントベースのフォーマットは、行ベースのフォーマットよりもコンパクトです。 binlog_row_imag パラメータを使用して、行ベースのイベントについてバイナリログに記録される情報量をコントロールすることができます。行の状態は、バイナリログの「イメージ」で表されます。どの行ベースのイベントでも、変更前イメージと変更後イメージの 2 種類のイメージがあります。変更が行われる前の行は、変更前イメージによって表されます。変更が行われた後の行は、変更後イメージによって表されます。すべてのイベントに、変更の前後のイメージがあるわけではありません。 次の表は、さまざまな行ベースのイベントとそれらの使用可能なイメージをまとめたものです。INSERT ステートメントは Write_rows イベントを作成します。 イベントのタイプ […]

Read More

Amazon RDS for MySQL のパラメータ設定 パート 1: パフォーマンス関連のパラメータ

この記事では、RDS for MySQL インスタンスからベストパフォーマンスを引き出すために留意すべき最重要のパラメータを扱います。これらを調整して、ワークロードに適合させ、ベストプラクティスにも合致させることができます。

Read More

Amazon RDS for Oracle における UTL_FILE 問題の解決

 データベースと各種アプリケーションサーバー間でファイルを転送するための一般的な手法として、Oracle の機能である UTL_FILE があります。UTL_FILEを使うと、クライアントサーバーが POSIX 対応のディレクトリにファイルをコピーし、その後そこからファイルを読み取ることを可能にします。さらに、データベースが PL/SQL ルーチンを使用して、これらの同じファイルに対する読み取りと書き込みを行うことも可能にします。 しかし Amazon RDS 上のOracle Databaseへの移動時には、UTL_FILEを用いたファイル転送において問題が生じます。データベースはサーバ上のファイルの読み取りと書き込みを実行できるのですが、これらのディレクトリは外部システムに公開されていないため、外部システムはそれらにアクセスできません。この問題は、多くの組織にとって Amazon RDS for Oracle を導入する妨げとなっています。 このブログ記事では、この問題を解決するプロセスについて順を追って説明していきます。このプロセスは、Oracle PL/SQL ルーチンを使用して Amazon S3 バケットに Oracle RDS インスタンスを統合することによって問題を解決します。こうすることで、現在 UTL_FILE によって提供されている機能性に似た外部ファイル転送メカニズムが提供されます。 このブログ記事では、Amazon RDS for Oracle インスタンスの変更プロセスのみを取り上げます。追加の参照情報は、以下のドキュメントトピックで見つけることができます。これらは、RDS for Oracle インスタンスを作成して、そのインスタンスにアクセスするためのプロセスを説明しています。 Amazon RDS のセットアップ Amazon RDS の使用開始 Oracle DB インスタンスを作成して Oracle DB インスタンス上のデータベースに接続する また、以下のドキュメントトピックにも追加の参照情報があります。これらには、このプロセスをテストするための S3 バケットの作成プロセスが説明されています。 Amazon Simple […]

Read More

AWS クラウドへの移行時にデータベースコストを削減して可用性を向上させる

従来のオンプレミスデータベースのライセンスコストとインフラストラクチャコストは増えつづけ、データベースのスケーリングが大きな課題になっています。このような場合には何ができるでしょうか? このブログ記事では、AWS クラウドに移行するときにデータベースコストを削減し、可用性を向上させる戦略について説明します。

Read More