Amazon Web Services ブログ

Category: Amazon RDS

Amazon RDS で詳細なバックアップストレージ請求をサポート開始

 最近、AWS は、Amazon RDS の詳細なバックアップストレージ請求機能を一般提供することを発表しました。この機能は、PostgreSQL、MySQL、MariaDB、Oracle、および SQL Server データベースのエンジンに適用されます。この機能がリリースされる前の Amazon RDS バックアップ料金は、毎月の請求書のリージョンごとに単一行の項目として提示されていました。ただし、毎日の自動データベースバックアップと手動 DB スナップショットの両方による Amazon RDS バックアップ請求料金の内訳は理解が困難でした。今後は、AWS Cost Explorer および Cost and Usage Report (CUR) で、コストアロケーションタグに基づいて Amazon RDS バックアップストレージの請求を表示できます。 このブログ投稿では、Amazon RDS データベースインスタンスにタグ値を設定し、コストアロケーションダッシュボードでこれらのタグをアクティブにし、AWS Cost Explorer と CUR で詳細なバックアップストレージ請求コストを表示する方法を示します。 設定 AWS マネジメントコンソールにログインしたら、Amazon RDS バックアップストレージ請求を表示するように設定するために、簡単なステップがいくつか必要です。DB インスタンスに既にタグが付いている場合は、RDS コンソールから、または AWS Cost Explorer から直接開始できます。 ステップ 1: Amazon RDS コンソール、AWS CLI、または API を介して […]

Read More

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

本投稿は、こちらのフォーラムに投稿された Amazon RDS for PostgreSQL をご利用中のお客様向けのアナウンスメントの参考和訳です。 本投稿は、PostgreSQL コミュニティが2020年2月にバージョン9.4を廃止予定であることに従い、2020年1月15日をもって、Amazon RDS が RDS for PostgreSQL 9.4 のサポートを終了することをお知らせするものです。 Amazon RDSは2015年からPostgreSQLメジャーバージョン9.4をサポートしています。本リリース後、機能性、セキュリティ、信頼性、パフォーマンスの観点で大幅な改善がなされたメジャーバージョンが続々とリリースされています。PostgreSQLコミュニティは、PostgreSQL 9.4のリリース終了時期を2020年2月と発表しています。コミュニティサポートモデルに沿って、AWSは9.4.1, 9.4.4, 9.4.5, 9.4.7, 9.4.9, 9.4.10, 9.4.11, 9.4.12, 9.4.14, 9.4.15, 9.4.17, 9.4.18, 9.4.19, 9.4.20, 9.4.21, 9.4.23 のマイナーバージョンを含む、メジャーバージョン9.4のサポートを終了いたします。Amazon RDS では引き続き、バージョン9.5 以降の PostgreSQLデータベースをサポートいたします。 できるだけ早いタイミングで、Amazon RDS PostgreSQL 9.4 データベースインスタンスをバージョン9.6, 10 もしくは、バージョン11 にアップグレードすることを推奨します。9.5 へアップグレードすることも可能ですが、このバージョンは2021年2月にサポート終了が予定されています。 利用中の PostgreSQL 9.4 のマイナーバージョンと PostGIS 拡張の利用有無に応じて、バージョン10 もしくは、11 に直接アップグレードできる可能性があります(※訳者注: […]

Read More

[AWS Black Belt Online Seminar] Amazon Aurora with PostgreSQL Compatibility 資料及び QA 公開

先日 (2019/8/28) 開催しました AWS Black Belt Online Seminar「Amazon Aurora with PostgreSQL Compatibility」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。   20190828 AWS Black Belt Online Seminar Amazon Aurora with PostgreSQL Compatibility from Amazon Web Services Japan AWS クラウドサービス活用資料集(すべての過去資料が閲覧できます) Q. サブネットグループで、AZを2つだけグルーピングしていた場合でも、ストレージ(データ)は、3つのAZに書込みされるのでしょうか? A. はい。サブネットグループの設定に関わらず、Amazon Aurora は自動的に 3 つのアベイラビリティーゾーンにかけて 6 個のデータコピーを保持します。サブネットグループには、プライマリインスタンス(Writer), Aurora レプリカ(Reader)を配置するために利用します。 Q. リードレプリカについては、追加インスタンス毎に、インスタンスタイプを変えることは可能という認識であっていますか? A. はい。ご認識の通り可能です。ただし、プライマリインスタンスとリードレプリカは同じインスタンスクラスを利用することを推奨しています。レプリカの追加方法についてはこちらのドキュメントをご確認ください。 Q. RDS for PostgreSQL を選択するメリットは、どういうものがあるでしょうか? A. […]

Read More

Amazon RDS Under the Hood: Multi-AZ

Amazon Web Services (AWS)のお客様はデータストアと、そのデータストアの高可用性にお客様のビジネスを委ねています。そのようなお客様に向けて、Multi-AZ配置は高可用性を実現する方法を容易に提供します。 Amazon Relational Database Service (Amazon RDS)でMulti-AZを有効にすることで、データの冗長かつ一貫した状態を維持します。もし、primaryデータベースサーバに問題が発生した場合は、standbyデータベースサーバに自動的に変更しデータへアクセスし続けられるようにします。2つのデータのコピーはそれぞれ別のAvailability Zones (AZs)内で管理されています(そのため、Multi-AZと呼ばれています)。別々のAvailability Zones を持つことで、両方のデータが同時に障害に見舞われるリスクを軽減させています。データの適切な管理、簡単な再構成、およびコピーへの信頼できるユーザーアクセスは、顧客環境が要求する高可用性要件に対処するための鍵です。 この投稿では、MySQL、MariaDB、PostgreSQL、およびOracleデータベースインスタンスのAmazon RDS Multi-AZ設定について説明します。Amazon RDS for SQL ServerおよびAmazon Auroraは、異なるテクノロジースタックを使用してマルチAZ機能を提供します。 基本デザイン Mult-AZ機能はデータベースアプリケーションとAmazon Elastic Block Store(Amazon EBS)ボリュームの間にあるレプリケーションレイヤーを使用して実装されています。このレイヤーは、アプリケーションの読み取りおよび書き込み要求を処理し、2つの個別のEBSボリュームコピーがある環境に適用されます。1つはローカルアクセス、もう1つはリモートアクセスです。 通常時は、レプリケーションレイヤーがインストールされた、2つのアクティブなAmazon EC2インスタンスがあります。 各インスタンスは、データの完全なコピーが行われているEBSボリュームを管理しています。この構成により、2つのインスタンスとそのボリュームがMulti-AZデータベースインスタンスとして稼働しています。 レプリケーションレイヤーは、TCP接続を介して互いに直接通信を行っています。 各インスタンスには特定のロールが割り当てられます。1つはプライマリであり、ユーザーがデータにアクセスするための外部エンドポイントを提供します。もう1つはスタンバイであり、プライマリから受信するすべてのデータを同期的に書き込むセカンダリインスタンスとして機能します。データベースの書き込みは、正常応答が呼び出し側アプリケーションに送り返される前に、データが両方のボリュームに適切に書き込まれます。ただし、読み取り操作は常にプライマリEBSボリュームを介して実行されます。データベースサーバープロセスは、スタンバイインスタンスで実行されていないため外部エンドポイントは公開されません。そのため、ユーザーはstandbyデータベースインスタンス上のデータのコピーは使用できません。 可用性を向上させるためにMulti-AZは、インスタンスの1つがプライマリロールにあることを一貫して保証し、データのコピーへのアクセスを提供します。もし可用性の問題が発生した場合、スタンバイインスタンスを自動的にプライマリロールに昇格させ、リダイレクトによって可用性を復元させます。 このイベントは、フェイルオーバーと呼ばれます。旧プライマリがまだ稼働している場合、スタンバイロールに降格されます。 新しいプライマリインスタンスへのリダイレクトは、DNSを介して提供されます。クライアントDNSクエリの結果に含まれるレコードのTTLは非常に短くなっています。アドレス情報の長期間のキャッシングを禁止することを目的としています。これにより、クライアントはフェールオーバープロセスで情報をより早く更新し、DNSリダイレクトの変更をより迅速に取得します。 以下の図が正常時のMulti-AZインスタンスの状態を示しています。 Figure 1: Multi-AZ instance データベースアプリケーション(黄色で表示されるDB APP)は、DNS)オレンジ色で表示)使用して、データへのアクセスを提供している現在の外部エンドポイントのアドレス情報を取得します。 このマルチAZインスタンスには2つのRDS DBインスタンスがあります。プライマリインスタンス(左側に緑色で表示)とスタンバイインスタンス)右側に青色で表示)です。この例では、DNSはアプリケーションをプライマリインスタンスEC2#1に向けており、Availability Zone#1で利用可能なEBS#1のプライマリコピーを提供しています。2つのEC2インスタンスの複製レイヤーが接続されています。アプリケーションが発行する書き込み操作は、2番目のインスタンスへの書き込みにもなります(パスは灰色で表示)。 レプリケーションレイヤーは、それ自体の可視性が制限されているため、より詳細な決定を下すことができません。たとえば、クライアントからの接続問題、ローカルまたはregionの停止、または予期せずサイレントな状態になったEC2ピアの状態などを知るすべがありません。このため、2つのインスタンスは、より重要な情報にアクセスし、インスタンスのステータスを定期的に監視する外部システムによって監視および管理されています。必要に応じて、管理システムは、可用性とパフォーマンスの要件が満たされてるためのアクションを実行します。 Multi-AZが提供する可用性と耐久性の改善は、最小限のパフォーマンスコストで実現しています。通常の使用例では、レプリケーションレイヤーが接続され、スタンバイEBSボリュームへの同期書き込み操作が発生します。スタンバイインスタンスとボリュームは、地理的に離れた個別のAvailability Zoneに配置されています。評価では、データベースのコミットへのオーバーヘッドが2ミリ秒から5ミリ秒増加していることが示されています。ただし、実際の使用例に対する実際の影響は、ワークフローに大きく依存します。ほとんどのお客様のMulti-AZインスタンスは、影響があったとしてもパフォーマンスにわずかな影響を示します。 この設計により、AWSはお客様のデータに対して99.95%の可用性を超えるサービスレベルアグリーメント(SLA)を提供しております。詳細については、Amazon RDSサービスレベルアグリーメントをご覧ください。 実装について ボリューム複製機能の設計は単純で簡単だと思われるかもしれません。しかし、実際の実装はかなり複雑です。これは、絶えず変化し、時には大きく変動する環境内で、2つのネットワークで接続された個別のインスタンスおよびボリュームが遭遇する可能性があるすべての事象を考慮する必要があるためです。 通常の進行中のレプリケーションは、すべてが適切に機能し、正常に動作していることを前提としています。EC2インスタンスが利用可能で、通常のインスタンス監視が機能し、EBSボリュームが利用可能で、ネットワークが期待どおりに動作しています。しかし、これらのピースの1つ以上が誤動作しているとどうなるでしょうか? 発生する可能性のある問題とその対処方法を見てみましょう。 […]

Read More

Amazon RDS PostgreSQL レプリケーションのベストプラクティス

Amazon RDS for PostgreSQL では、読み込み負荷を取り除き、災害復旧 (DR) リソースを作成するために、ソース PostgreSQL インスタンスのレプリカを簡単に設定することができます。リードレプリカは、ソースと同じリージョン、または異なるリージョン内に設定できます。 RDS PostgreSQL リードレプリカインスタンスを使用すると、読み込みワークロードをレプリカインスタンスにオフロードすると同時に、書き込みアクティビティのためにソースインスタンスのコンピューティングリソースも確保します。ただし、レプリケーション遅延を避けるには、リードレプリカを正しく設定し、適切なパラメータ値を設定する必要があります。 概要 この記事では、リードレプリカを正しく設定するためのベストプラクティスをいくつかご紹介します。リージョン内、クロスリージョン、および論理レプリケーションなどのさまざまな RDS PostgreSQL レプリケーションオプションの長所と短所を取り上げ、適切なパラメータ値と、監視するメトリクスを推奨します。以下のステップでは、レプリケーション遅延を最小限に抑えながら、DR 戦略、読み込みワークロード、および健全なソースインスタンスを最適化する方法を説明します。 一般的な推奨事項 全体的なベストプラクティスとして、リードレプリカで実行するリードクエリが、ソースインスタンスとしてデータの最新バージョンを使用することを確認してください。データバージョンは、Amazon CloudWatch メトリクスでレプリケーション遅延を調べることによって確認できます。レプリケーション遅延を最小限に抑えることによって、古いデータに基づいたクエリ出力と、インスタンスの健全性に対するリスクの両方を避けることができます。 リージョン内のレプリケーション RDS PostgreSQL は、ソースインスタンスと同じ AWS リージョン内でリードレプリカを作成するために Postgres ネイティブストリーミングレプリケーションを使用します。ソースインスタンスでのデータの変更は、ストリーミングレプリケーションを使ってリードレプリカにストリームされます。このプロセスが何らかの理由で遅れると、レプリケーション遅延が発生します。以下の図は、RDS PostgreSQL が同じリージョン内のソースとレプリカの間でレプリケーションを実行する方法を示しています。 この後のセクションでは、同じリージョン内でホストされている RDS PostgreSQL インスタンスを最適にレプリケートするために Postgres インスタンスを調整する方法について説明します。 適切な wal_keep_segments の値 Postgres では、wal_keep_segments パラメータで pg_wal ディレクトリに保存される WAL ログファイルセグメントの最大数を指定します。Postgres は、このパラメータを超える WAL セグメントを Amazon S3 バケットにアーカイブします。 リードレプリカが […]

Read More

Amazon RDS Performance Insights のカウンターメトリクスを Amazon CloudWatch にインポートする

Amazon RDS Performance Insights では、Amazon RDS データベースインスタンスをモニターでき、データベースのパフォーマンスの分析やトラブルシューティングが可能です。Performance Insights のデータは AWS Management Console で表示させることができます。また別の手段として、Performance Insights の公開された API を使い、ご自分が必要なデータを照会することもできます。この API を使って、データ取得や、既存のモニタリングダッシュボードへの Performance Insights データの追加、あるいは、ご自身のモニタリングツールの構築などが行えます。今回のブログでは、Cloudwatch へデータを送信するために、この API を使用します。 概要 Performance Insights では、システムパフォーマンスのモニタリングに使うため、オペレーティングシステムやデータベースカウンターについての、多様なメトリクスを収集します。各 Amazon RDS データベースエンジンには、Aurora メトリクスなど、一連のカウンターメトリクスが個別に備わっています。データベースパフォーマンスのトラブルシュートは、データベースの動作時刻を指定することで開始できますが、カウンターメトリクスも、データモニタリングのために、二次的ソースとして便利に利用できます。またこれらを、既存のシステムダッシュボードに統合すると便利です。 この記事は、データベースカウンターメトリクスに関心をお持ちの方すべてに向けたものです。まず、2 つある Performance Insights API の 1 つである GetResourceMetrics を取り上げます。これにより、Performance Insights からデータを取り出す AWS Lambda 関数を作成する方法と、別のモニタリングシステムにそれを統合する方法をご紹介します。この記事では、Boto3、Python3、AWS CLI、Performance Insights API を使用していきます。作業開始の前に、Performance Insights が有効化された Amazon […]

Read More

Amazon RDS および Amazon Aurora のデータベースエンジンに適切な暗号化オプションを選ぶ

 AWS クラウドのデータベースやデータストアの暗号化をデフォルトで選択するお客様の数は、ますます増えています。この流れは、さまざまな規制の枠組みにおいて機密データ (個人特定可能な情報 [PII、Personally Identifiable Information] など) の意味が発展していくのにともなって、勢いを増すばかりです。最新のデータベース暗号化の中から、パフォーマンスや各製品での迅速な反復を維持したまま最適なものを選ぶ方法について教えてほしい、というお客様からの要望も AWS に寄せられています。 そこで今回の記事では、Amazon RDS MySQL、MariaDB、Amazon Aurora MySQL の各データベースエンジンで使用できる、暗号化の方法をご紹介します。この記事は、ワークロードやビジネスのニーズに最も適した暗号化の方法を見つける一助となることを目指しています。なお簡略化のため、上記のエンジンをここでは “RDS MySQL 関連” のエンジン、または “MySQL 関連” のエンジンと呼びます。 概要 RDS で利用できる暗号化の方法は、次の 3 つのカテゴリーに分けることができます。 保存時のデータの暗号化。これには、プラットフォーム全般の機能およびデータベースエンジンそれ自体の機能が含まれます。 送信中のデータの暗号化。これは、データベースとクライアント間のネットワークを移動するデータを確実に保護する方法です。 レプリケーション中に送信されるデータの暗号化。ひとつ前のカテゴリーと大きな違いはありませんが、こちらはデータベースサーバー間のデータレプリケーションのトラフィックに用いられる方法です。 次に、それぞれのカテゴリーを詳しく見ていき、ニーズに合わせて最も効果的に実装する方法をご紹介します。 保存時のデータの暗号化 RDS MySQL 関連のデータベースエンジンを使用している AWS の多くのお客様は、RDS リソースの暗号化に依存しています。RDS により暗号化されたリソースを使うと、データは保存時に、データベース (DB、Database) インスタンスの基盤となるストレージ、その自動バックアップ、リードレプリカ、スナップショットを含めて暗号化されます。この機能は、データの暗号化にオープン標準の AES-256 暗号化アルゴリズムを使用しています。このアルゴリズムはデータベースエンジンに対して透過的です。 Amazon EBS では、RDS MySQL と MariaDB 向けに、基盤となるストレージとスナップショット機能が提供されます。Aurora では、専用の、分散されたログ構造のストレージサービスが使用されています。暗号化された Aurora DB […]

Read More

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