Amazon Web Services ブログ

Category: Amazon Aurora

オンラインセミナー「RDS+Lambda が始まる。過去のアンチパターンはどう変わるのか」 資料および QA 公開

先日(2020/7/28)開催しましたオンラインセミナー
「 RDS+Lambda が始まる。過去のアンチパターンはどう変わるのか」
の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

Read More

Amazon Aurora Global Database の書き込み転送を使用してグローバルに分散された MySQL アプリケーションを構築する

AWS は 2018 年に Amazon Aurora Global Database をリリースしました。Aurora Global Database は主に 2 つのユースケースで使えます。最初のユースケースは、災害復旧ソリューションをサポートすることです。これにより、低目標復旧時点 (RPO) と低目標復旧時間 (RTO) でリージョン全体の障害に対処しながら、保護対象のデータベースクラスターへのパフォーマンスへの影響を最小限に抑えることができます。Aurora Global Database を使用すると、通常、RPO は 5 秒未満、RTO は 1 分未満に抑えることができます。書き込みワークロードが大きい場合でも、ソースクラスターとターゲットクラスターの両方に対するパフォーマンスへの影響は無視できるほどに小さいものです。 Aurora Global Database の 2 番目の主なユースケースは、最大 5 つのリモートリージョンに Amazon Aurora クラスターの読み取り専用コピーを供給して、そのリージョンに近いユーザーにサービスを提供することです。これにより、リモートリージョンのユーザーは、さらに離れたプライマリリージョンに接続する必要がある場合よりも低いレイテンシーで読み取りが行えます。 次のグラフは、2 つのリージョン間で MySQL 論理レプリケーションを使用した例を示しています。クエリの数が段階的に増加すると、ターゲットクラスターで観察されるレプリケーションタイムラグは指数関数的に増加します。さらに、テスト済みの設定で処理できる 1 秒あたりのクエリ数は、ピーク時に約 35,000 でした。 対照的に、次のグラフは、Aurora Global Database を使用したのと同じワークロードとインスタンスのサイジングを示しています。レプリケーションは 1 秒未満のタイムラグを維持し、1 秒あたりのクエリ数はピーク時に約 200,000 (+ […]

Read More

Amazon Aurora MySQL から Amazon S3 にデータをエクスポートおよびインポートするためのベストプラクティス

複雑なアプリケーションを小さな部分に分割することにより、多数の専用データベースを使用して高度に分散したアプリケーションを構築できます。これにより、ジョブに適したデータベースを選択できます。Amazon Aurora は、OLTP ワークロードの推奨される選択肢です。Aurora により、クラウド内でリレーショナルデータベースをセットアップ、操作、スケーリングするのが容易になります。 この記事では、Aurora MySQL から Amazon Simple Storage Service (Amazon S3) にデータをエクスポートおよびインポートする方法を示し、関連するベストプラクティスについて説明します。Amazon Aurora PostgreSQL では、データを Amazon S3 機能にエクスポートおよびインポートすることもできます。このブログでは、Amazon Aurora MySQL に焦点を当てます。 Aurora と Amazon S3 の概要 Aurora は、クラウド向けに構築された MySQL と PostgreSQL の互換性があるリレーショナルデータベースで、従来のエンタープライズデータベースのパフォーマンスと可用性、およびオープンソースデータベースのシンプルさと費用対効果を兼ね備えています。 Amazon S3 は、業界をリードするスケーラビリティ、データの可用性、セキュリティ、およびパフォーマンスを提供するオブジェクトストレージサービスです。つまり、どの規模と業界の顧客もこれを使用して、任意の量のデータを保存および保護できます。 前提条件 始める前に、以下を完了してください。 Aurora MySQL DB クラスターを起動します。既存のクラスターを使用することもできます。 MySQL クライアントをインストールした Amazon EC2 インスタンスを起動します。ここでは、MySQL Workbench を使用することもできます。 次の必須の Identity and Access […]

Read More

AWS DMS を使用して Amazon Aurora for PostgreSQL のメジャーバージョンへのアップグレードを最小ダウンタイムで実現する

AWS は 2 つのマネージド型 PostgreSQL オプションを提供しています。Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL です。Amazon RDS または Aurora がデータベースエンジンの新しいメジャーバージョン (PostgreSQL 10 から 11 など) をサポートしている場合、DB インスタンスを新しいバージョンにアップグレードできます。メジャーバージョンのアップグレードには、既存のアプリケーションとの下位互換性がない可能性があるデータベースの変更が含まれる可能性があります。詳細については、「Aurora PostgreSQL 向けの PostgreSQL DB エンジンをアップグレードする」と「Amazon RDS を PostgreSQLのメジャーバージョンとマイナーバージョンにアップグレードするためのベストプラクティス」を参照してください。 Amazon RDS と Aurora のどちらにも、DB インスタンスを変更することにより、メジャーバージョンのアップグレードを手動で開始するオプションがあります。これは、インプレースアップグレードとも呼ばれ、アップグレードプロセス中にアプリケーションのダウンタイムを必要とします。また、アップグレードで問題が発生した場合は、最新のバックアップを復元する必要があります。したがって、このオプションはすべてのワークロードタイプに望ましいとは限りません。別のアプローチは、メジャーバージョンのアップグレードに AWS Database Migration Service (DMS) を使用することです。AWS DMS は、PostgreSQL 論理レプリケーションを使用して、2 つのメジャーバージョン間のデータをほぼリアルタイムで同期します。AWS DMS は、次の要件を満たしている場合にのみ使用してください。 特定のメジャーバージョンで利用できるインプレースアップグレードオプションがない Aurora クラスター内の少数または一部のデータベースをアップグレードする必要がある アップグレードプロセスに必要なダウンタイムを最小限に抑え、カットオーバーで問題が発生した場合に古いインスタンスへ素早くロールバックできるオプションを確保したい […]

Read More

Amazon Aurora マルチマスタークラスターが東京リージョンに対応しました

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン、シニアエバンジェリストの亀田です。 Amazon Auroraのマルチマスタークラスター機能が東京リージョンに対応しましたのでお知らせいたします。 Amazon Auroraは、MySQL および PostgreSQL と互換性のあるクラウド向けのリレーショナルデータベースであり、従来のエンタープライズデータベースのパフォーマンスと可用性に加え、オープンソースデータベースのシンプルさとコスト効率性も兼ね備えたAWSにより設計されたデータベースです。標準的な MySQL データベースと比べて最大で 5 倍、標準的な PostgreSQL データベースと比べて最大で 3 倍高速です。また、商用データベースと同等のセキュリティ、可用性、信頼性を、10 分の 1 のコストで実現します。 マルチマスター機能は、複数のアベイラビリティーゾーンにわたってAuroraデータベースの複数の読み書きインスタンスを作成できる単一のデータベースであり、稼働時間に敏感なアプリケーションがインスタンス障害を通じて継続的な書き込み可用性を実現できるようにします。この機能のご利用には、MySQL 5.6 と互換性のある Aurora MySQL バージョン 1 が必要です。 マルチマスタークラスターでは、すべての DB インスタンスで書き込みオペレーションを実行できます。単一の読み書きプライマリインスタンスと、複数の読み取り専用 Aurora レプリカの概念は適用されません。別の書き込み DB インスタンスを使用して、失敗したインスタンスの作業を引き継ぐことができるため、書き込み DB インスタンスが利用できなくなっても、フェイルオーバーが発生することのない、継続的な可用性を実現可能です。 その一方で従来のAuroraと動作が異なる点が多くあるため、利用には事前の検証を推奨しています。また他のAuroraやRDSでサポートしているインスタンスのStop(一時停止)には対応していません。 考慮すべき事項や制限事項などはこちらにまとまっていますのでご覧ください。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/aurora-multi-master.html また以下のブログもマルチマスター機能の基本概要をご理解いただくうえで非常に役に立ちますので合わせてご参考ください。 https://aws.amazon.com/jp/blogs/news/building-highly-available-mysql-applications-using-amazon-aurora-mmsr/ – シニアエバンジェリスト 亀田    

Read More

GTID ベースのレプリケーションを使用したフォールバックオプションで Amazon Aurora MySQL へ移行する

本番アプリケーションを移行する場合、多くの場合、フォールバックオプションを備えていることが重要です。このブログ記事では、グローバルトランザクション識別子 (GTID) ベースのレプリケーションを使用して、Amazon RDS MySQL ワークロードを Amazon Aurora MySQL に移行する方法を説明します。また、問題が発生した場合にフォールバックメカニズムを使用する方法についても説明します。 GTID ベースのレプリケーションの詳細については、「Amazon Aurora for MySQL 互換エディションでグローバルトランザクション 識別子 (GTID) によるレプリケーションがサポートされるようになりました」をご覧ください。 この記事では、レプリケーショントポロジには、2 つのリードレプリカ (RDS MySQL リードレプリカと Aurora MySQL レプリカ) を持つマスター RDS MySQL インスタンスがあります。移行中に問題が発生した場合のフォールバックインスタンスとして RDS MySQL リードレプリカを使用し、元の RDS MySQL マスターが影響を受けないようにします。ただし、元の RDS MySQL マスターインスタンスをフォールバックオプションとして使用することもできます。移行が成功すると、Aurora MySQL レプリカが RDS MySQL レプリカインスタンスのマスターインスタンスになります。 GTID ベースのレプリケーションを使用する主な利点は、すべてのトランザクションに一意の識別子を割り当てられ、レプリケーショントポロジ内の各 MySQL サーバーがすでに実行したトランザクションを追跡できることにあります。GTID ベースのレプリケーションはトランザクションベースであるため、マスターとレプリカ間のデータの一貫性を簡単に判断できます。マスターでコミットされたすべてのトランザクションがレプリカにもコミットされている場合、2 つの間に一貫性があります。これにより、auto-positioning が可能になります。これは、binlog ファイルの名前または位置を指定することなく、レプリカがマスターインスタンスをポイントする機能です。 前提条件 このチュートリアルを実行するには、次の前提条件を満たしている必要があります。 […]

Read More

Amazon Aurora Global Database を使った Aurora PostgreSQL 災害復旧ソリューション

 Amazon Aurora (PostgreSQL 互換) は、高性能商用データベースのパフォーマンスと可用性、そしてオープンソースデータベースのシンプルさとコスト効率性を兼ね備えています。Aurora は、同じリージョン内の 3 つのアベイラビリティーゾーンにストレージをスケールすることでこれを実現し、単一リージョン内で読み込みワークロードと高可用性をスケールアウトするために最大 15 個のリードレプリカをサポートします。Amazon Aurora Global Database では、リージョン全体で障害が発生した場合におけるリモート読み込みアクセスと災害復旧のために、最大 5 つのリージョンに PostgreSQL データベースをレプリケートできるようになりました。 Aurora は、保護グループと呼ばれる 10 GB の論理ブロックにストレージボリュームを構築しています。Aurora は、同じリージョン内の 3 つのアベイラビリティーゾーン (AZ) にまたがって割り当てられている 6 個のストレージノード (AZ ごとに 2 個) 全体に各保護グループをレプリケートします。データのボリュームが現在割り当てられているストレージを超えると、Aurora は必要に応じて新しい保護グループを追加することによってボリュームを拡大し、需要を満たします。 Aurora Global Database とは? 複数のリージョンにまたがる Aurora Global Database は、リージョン全体の障害からの災害復旧を実現し、最も近い位置にある Aurora クラスターからの読み込みを許可することによって、低レイテンシーのグローバル読み込みを可能にします。 Aurora の機能として、Global Database は Aurora のストレージレイヤーにある専用のインフラストラクチャを使用して、リージョン間のレプリケーションを処理します。レプリケーションはストレージレイヤー内の専用レプリケーションサーバーが処理するため、データベースのパフォーマンスを損なうことなく高度な復旧および可用性目標を達成できます。 PostgreSQL […]

Read More

最終のご案内: 3月5日までに Amazon RDS / Aurora / DocumentDB のSSL/TLS証明書を更新してください

Amazon Relational Database Service (RDS)、Amazon Aurora、または Amazon DocumentDB をご使用中のお客様で、データベースインスタンスにSSL/TLS接続している方は、2020年3月5日までにSSL/TLS証明書を更新してください。実行しなかった場合、SSL/TLSでのデータベース接続ができなくなります。

Read More

Autodesk のミッションクリティカルなデータベースを Microsoft SQL Server から Amazon Aurora MySQL に移行する

 この記事は、Autodesk のソフトウェアアーキテクトである Tulika Shrivastava 氏が、AWS の Rama Thamman の協力の下で執筆したゲスト投稿です。Autodesk は自社を評して次のように述べています。「Autodesk は 3D 設計、エンジニアリング、エンターテイメントソフトウェアの分野で牽引する企業です。車を運転したり、超高層ビルを見上げたり、スマートフォンを使用したり、偉大な映画を見たりしたことがある人は、何百万もの Autodesk ユーザーがソフトウェアで行っていることを身をもって体験されているものと思われます」 Autodesk は、AWS のサービスの中でも特に、プライベートデータセンターから Amazon EC2 へワークロードを移行することで、数年前にクラウドのモダナイゼーションを開始しました。Autodesk は、柔軟性とスケーラビリティを得て予想される成長を後押しするために近代化する必要がありました。2019 年、当社はミッションクリティカルなシングルサインオン (SSO) アプリケーションを EC2 上のセルフマネージド SQL Server から完全マネージド型の Amazon Aurora MySQL に移行しました。このサービスでは、1 億 4200 万人を超えるユーザーからの認証リクエストを集め、1 分あたり 145,000 件を超える API リクエストに応答しています。認証と承認のために 300 を超える製品とサービスと統合されています。 この移行により、Autodesk SSO サービスの管理と復元力が合理化され、コストが最適化され、インフラストラクチャメンテナンスのオーバーヘッドが削減されました。初期コスト分析によると、当社は Amazon Aurora MySQL を使用することで、データベース全体のコストの約 40〜50% を毎月節約できるだろうことがわかりました。 この記事では、Autodesk […]

Read More

Aurora PostgreSQL のキャッシュ管理機能の紹介

Amazon Aurora は、ハイエンドな商用データベースが持つ速さや可用性を、オープンソースデータベースのシンプルさやコスト効率の高さと組み合わせた、リレーショナルデータベースエンジンです。PostgreSQL 互換エディションの Aurora では、同じハードウェアで動作させたとき、標準 PostgreSQL の最大 3 倍のスループットが実現できます。既存の PostgreSQL アプリケーションおよびツールは、修正をせずにそのまま使用可能です。この、PostgreSQL の互換性と Aurora のエンタープライズデータベース機能の組合せは、商用データベースを移行する際の理想的なターゲットとなっています。 リレーショナルデータベースでのキャッシング キャッシングは、すべてのリレーショナルデータベースがディスク I/O を削減するために備えている、主要な機能の一つです。これは、最も使用頻度の高いデータを、バッファーキャッシュと呼ばれるメモリの中に一時保存します。バッファーキャッシュにあるデータへのアクセスは、ディスクに保存されたものより高速です。つまり、スケーラビリティやアプリケーションのパフォーマンスを高めることができます。 PostgreSQL では、(テーブルやインデックスブロックなどの) アクセス頻度の高いデータブロックをキャッシュします。この設定は、データベースサーバーが使用する共有メモリバッファーの容量を規定する設定パラメータ (shared_buffers) により定義されます。詳細については、PostgreSQL ドキュメントウェブサイトの「Memory」をご参照ください。 キャッシングとフェイルオーバー Aurora PostgreSQL では、フェイルオーバー優先順位が最も高いリードレプリカを自動的に新しいマスターに昇格することで、高速のフェイルオーバー (約 35 秒) を実現しています。 リードレプリカは、プライマリと同じワークロードで実行するものではありません。従って、リードレプリカにおけるバッファーキャッシュの内容は、アプリケーションでの読み出し/書き込みワークロードを反映しきっていない、あるいは、障害が発生したプライマリの内容と完全に異なっている、ということがあり得ます。 フェイルオーバー発生時のバッファーキャッシュの内容によっては、新たに昇格された書き込みインスタンスにおいてキャッシュをウォームアップ (障害を起こす前のプライマリと同様な状態にキャッシュが遷移) するための時間が必要となります。バッファーキャッシュのウォームアップに必要な時間は、障害以前と同じ応答速度をアプリケーションが得られるようになるまでの時間です。 障害が起きた時点でのバッファーキャッシュの内容によっては、新たに昇格する書き込みインスタンスがキャッシュを (障害前のプライマリを反映した状態までに) ウォームアップするのに、顕著な時間を要することもあります。バッファーキャッシュのウォームアップに要する時間は、障害前と同じく信頼できる応答速度を得られるまで、アプリケーションが待機しなければならない時間となります。 クラスターキャッシュ管理 クラスターキャッシュ管理 (CCM) 機能は、フェイルオーバーが発生した後の、新しいプライマリ/書き込みインスタンスのパフォーマンスを向上させます。レプリカでは、アクセス頻度の高いバッファーをプライマリおよび書き込みのインスタンスからキャッシュして、予防的な読み込みを行っています。CCM により、特定の Aurora PostgreSQL レプリカをフェイルオーバーのターゲットとして指定することが可能です。CCM は、指定されたレプリカのキャッシュにあるデータが、プライマリ DB インスタンスのキャッシュにあるデータと正確に同期するようにします。 CCM の機能説明図を次に示します。読み出し専用 (RO) ノードは、読み出し/書き込み […]

Read More