Amazon Web Services ブログ

Category: Amazon RDS

RDS PostgreSQL トランスポータブルデータベースを使用したデータベースの移行

Amazon RDS for PostgreSQL が、バージョン 11.5 以降および 10.10 以降で、高速データのインポートおよびエクスポート方法であるトランスポータブルデータベース機能をサポートするようになりました。RDS PostgreSQL インスタンスから別の PostgreSQL インスタンスに PostgreSQL データベースをインポートする必要がある場合は、pg_dump や pg_restore などのネイティブツールを使用するか、\copy コマンドを使用してデータをターゲットテーブルにロードできます。トランスポータブルデータベースを使用すると、こうした従来のツールよりもはるかに高速にデータを移動することができます。この機能は、データベースごとの物理的な転送メカニズムを提供する pg_transport と呼ばれる新しい拡張機能を使用します。物理的な転送では、最小限の処理でデータベースファイルをストリーミングすることにより、最小限のダウンタイムでデータをより高速に移動できます。 この記事では、pg_transport の一般的なユースケースと、AWS CLI と psql ユーティリティを使用して RDS PostgreSQL 環境でこれを設定および使用する方法について説明します。 pg_transport のユースケース 多くのお客様は、RDS PostgreSQL で独自の SaaS またはマルチテナントおよびエンタープライズアプリケーションを実行しています。これは、Amazon RDS により、AWS での PostgreSQL デプロイの設定、操作、スケーリングが簡単になるためです。単一の RDS PostgreSQL インスタンスに複数のデータベースを配置して、さまざまな顧客やアプリケーションにサービスを提供するのは一般的なことです。このような環境では、トランスポータブルデータベースが役立ちます。 以下のようなユースケースに最小限のダウンタイムで対処できます。 リソースの管理や分離を改善するために、RDS インスタンス間でデータベースを移動する。たとえば、SaaS プロバイダーであれば、特定の容量に達した場合、顧客データを異なる構成 (より大きなインスタンスタイプ、プロビジョンド IOPS、または異なるインスタンスファミリー) に移動する必要があります。 セキュリティおよびコンプライアンスの理由でデータを再編成する。たとえば、ある AWS アカウントの […]

Read More

RDS および Aurora PostgreSQL ログの操作: パート 2

このシリーズの最初の投稿である RDS および Aurora PostgreSQL ログの操作: パート 1 では、PostgreSQL のログの重要性と、より多くのデータベースアクティビティの詳細情報をキャプチャするためのさまざまなパラメータを調整する方法を記載しています。PostgreSQL ログは、データベースの問題を解決するのに役立つ情報を提供します。この投稿は、PostgreSQL ログにアクセスするためのさまざまな方法に焦点を当てています。 PostgreSQL ログはクラスターの各インスタンスに生成および保存されます。これらのログファイルにアクセスする方法は複数あります。以下のセクションでは、これらの方法をいくつか説明します。 AWS マネジメントコンソールにアクセスする PostgreSQL ログファイルにアクセスするための最も直接的な方法は、AWS Management Console を介して行います。以下の手順を実行します。 Amazon RDSを開きます。 RDS/Aurora インスタンスを選択します。 [ログとイベント] を選択します。 [Logs] で必要なログファイルを選択します。 [View]、[Watch]、または[Download]のいずれかを選択します。 以下のスクリーンショットは、[Logs] セクションのプレビューです。 これは、ログファイルを表示またはダウンロードするための最も基本的な方法です。 CloudWatch Logs にログファイルを発行する RDS および Aurora PostgreSQL は、Amazon CloudWatch Logs へのログの発行をサポートしています。詳細については、RDS ユーザーガイドの「PostgreSQL ログの Amazon CloudWatch Logs への発行」を参照してください。 ログが CloudWatch Logs の場合、アラームを作成し、リアルタイム分析を行うことができます。たとえば、log_statements を […]

Read More

RDS および Aurora PostgreSQL ログの操作: パート 1

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30 年以上におよぶ開発作業を経ている PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。AWS は 2 つのマネージド型 PostgreSQL オプションを提供しています。Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL です。デバッグやモニタリングのためのデータベースアクティビティログをどのようにキャプチャするのかという質問が、新規の PostgreSQL ユーザーから多く寄せられます。この記事では、RDS および Aurora PostgreSQL を設定して追加のエンジンログを生成する方法について説明します。記事の第 2 部である RDS および Aurora PostgreSQL ログの操作: パート 2 では、これらのログファイルにアクセスする方法をご紹介します。 PostgreSQL は、データベース管理者 (DBA) に役立つ情報を含むイベントログを生成します。デフォルトでは、SQL クエリエラー、ログイン試行の失敗、デッドロックがデータベースログにキャプチャされます。これらのエラーメッセージはアプリケーションのさまざまな問題の特定に役立ちます。たとえば、レガシーアプリケーションを Oracle から PostgreSQL に変換すると、一部のクエリが PostgreSQL 構文に正しく変換されないことがあります。こうした誤った形式のクエリによってログにエラーメッセージが生成されるため、問題のあるアプリケーションコードを特定するのに役立ちます。 デフォルトのログ記録を使用するだけでなく、PostgreSQL ログ記録パラメータに変更を加えれば、パフォーマンスの低下やセキュリティ監査などの問題を特定、解決するのに役立つ情報を取得できます。このログ記録パラメータを設定すると、接続と切断、スキーマ変更クエリ、すべてのスロークエリとその時間、ロックのため待機中で時間がかかるクエリ、一時的なディスクストレージを消費するクエリ、リソースを消費するバックエンド自動バキュームプロセスなどの情報をキャプチャできます。 このログ情報は、データベース使用中の潜在的なパフォーマンスと監査の問題をトラブルシューティングするのに有用です。この記事では、このログ記録の有効化とその利点について詳しく説明します。 DB パラメータグループ RDS および Aurora […]

Read More

S3_INTEGRATION を使用して Amazon RDS for Oracle を Amazon S3 と統合する

Amazon RDS for Oracle では、マネージドサービスソリューションのあらゆる利点を活用できます。リフトアンドシフトアプローチを使用してレガシー Oracle データベースを Amazon RDS for Oracle に移行すると、既存のアプリケーションコンポーネントをリファクタリングしたり変更したりする必要性を減らすことができます。 データウェアハウス (DW) 抽出は、ほとんどのデータベースにおいて不可欠な部分です。データベースのホストと社内データベース用 DW サーバーとの間で、ネットワークファイルシステム (NFS、Network File System) などの共有ファイルシステムに抽出ファイルを保持するのが一般的な方法です。 DW ロード用の共有ファイルシステムを使用してオンプレミスの Oracle から Amazon RDS for Oracle への移行を行う際には、既存の共有転送メカニズムがスムーズに移行できるかという点に特に注意する必要があります。そのことを念頭に置いて、AWS は 2019 年 2 月に、Amazon S3 統合により Amazon RDS for Oracle を強化しました。このオプションにより、Amazon RDS for Oracle Database を Amazon Simple Storage Service (Amazon S3) にシームレスに統合することができます。 この記事では、アプリケーションホストとAmazon […]

Read More

SSL/TLS を経由して RDS MySQL, RDS MariaDB, and Amazon Aurora MySQL に sysbench を実行する

sysbench は MySQL 互換のデータベースでベンチマークを実行するために有用なツールです。もし、sysbench を使って Amazon Aurora MySQL のパフォーマンスの評価をしたい場合、Amazon Aurora Performance Assessment Technical Guide が役に立つでしょう。しかし、もし SSL/TLS を経由して sysbench を実行したい場合、このツールや AWS のサービスにあるいくつかの制限について考える必要があります。 この投稿では、RDS MySQL, RDS MariaDB, and Aurora MySQL で sysbench を実行するにあたっての考慮点と、どのように準備するべきかについて、お話いたします。 考慮点 sysbench の最新のパッケージリリースは 1.0.17 になります。もし、yum や RPM のようなパッケージマネージャから sysbench をインストールした場合、このバージョンがインストールされます。このバージョンでは、sysbench は SSL/TLS を使用するにあたって、以下のような制限を持っています: –mysql-ssl オプションは ON または OFF のみが指定可能で SSL_MODE は REQUIRED 固定 クライアント秘密鍵、クライアント公開鍵、CA […]

Read More

Amazon Relational Database Service (RDS)とAmazon AuroraのSSL/TLS 証明書のアップデートについて

Amazon Relational Database Service (RDS)/Amazon Auroraをご利用のお客様に対し、「SSL/TLS 証明書のアップデートについて」のご案内をお送りさせていただいております。こちらは、現在RDSにて利用しているSSL/TLS 証明書が期限を迎えるため、新しいSSL/TLS 証明書へ更新が行われるという通知となっています。 SSL/TLS 証明書更新に際して、お客様よりよく頂くご質問を以下にまとめましたので、ご確認をお願いいたします。   Q: SSL/TLS 接続を使用している場合、CA 証明書をアップデートする必要がありますか? はい、もしお客様が CA 証明書をアップデートしなかった場合、SSL/TLS 接続ができなくなります。CA 証明書のアップデートは 2020 年 3 月 5 日までに完了する必要があります。AWS では、CA 証明書のアップデートによる影響のテストや対応のための時間を確保するために、2020 年 2 月 5 日までにアップデートを完了していただくことを強くお勧めしております。 Q: CA 証明書のアップデートを 2019 年 10 月 31 日までに完了させる必要がありますか?最終期限はいつになりますか? 2019 年 11 月 1 日以降、お客様が新たに DB インスタンス (Amazon RDS DB インスタンス、Amazon […]

Read More

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