Amazon Web Services ブログ

Category: Database

AWS Database Migration Service を使用した Amazon RDS for SQL Server の継続的なレプリケーションの紹介

AWS Database Migration Service (AWS DMS) とAmazon RDS for SQL Server が新たに Amazon RDS for SQL Server からの継続的なレプリケーションをサポートするという新機能を発表できることを嬉しく思います。AWS DMSは、データベースをAWSに迅速かつより安全に移行できるサービスです。また、AWS内のデータ移行にも使用できます。Oracle、Microsoft SQL Server、PostgreSQLなど、広く普及している商用およびオープンソースデータベース間でデータを移行できます。このサービスはSQL ServerからSQL Serverのような同エンジン間の移行と、SQL ServerからAmazon Aurora MySQLまたはSQL ServerからAmazon RDS for MySQLなどの異なるデータベースプラットフォーム間の移行の両方が可能です。 この記事では、Microsoft SQL Server からの継続的なレプリケーションプロセスの概要を簡単に説明します。また、MS-CDC(SQL Serverでの変更データキャプチャ)とAWS DMSを使用して、Amazon RDS for SQL Serverからの継続的な変更をストリーミングするための新機能も紹介します。   背景 AWS DMSは異なるエンジン間の移行(SQL ServerからMySQLへの移行など)用に設計されています。ただし、同エンジン間(SQL ServerからSQL Serverなど)の移行もサポートしています。これまではソースインスタンスで実際に行われていた変更にアクセスする必要がありました。 主キーを持つテーブルの場合、AWS DMSはデフォルトで以下のように使用されるように設計されています。 1.SQL Serverから進行中の変更を移行するタスクを設定すると、AWS DMSは最初に次のコマンドを使用してトランザクションレプリケーション用のデータベースを有効にします。 use master exec sp_replicationdboption […]

Read More

AWS SCT と AWS DMS を使ってMySQLから Amazon Aurora に移行する方法

MySQLは素晴らしいオープンソースデータベースエンジンで、そのコスト効率から多くの企業で使われています。しかし、その他のオープンソースデータベースと同様に、ビジネスで使えるレベルの性能を出すには多くの労力が必要です。 データベースサイズが増えるとMySQLのスケーラビリティとクラッシュリカバリの複雑さも増します。レプリケーションスレーブを追加することでMySQLデータベースをスケールさせると、特にMySQLマスターで多くの書き込みが発生した場合に、レプリケーションラグを非常にに小さな値で維持することは困難を伴います。ほとんどの場合、安定したパフォーマンスを維持することは難しいです。 一方、Amazon Aurora では最大15個のリードレプリカを追加できます。また、書き込みノードで発生した変更を再実行するために必要な従来のバイナリログ (binlog) レプリケーションのパフォーマンスをAuroraでは気にする必要がなくなります。これはAuroraクラスターボリューム内のデータは、クラスター内のライターとリーダーに対して単一の論理ボリュームとして見えるためです。 多数のテーブルを含む大規模なデータベースでの高速リカバリも Amazon Aurora の重要な利点の一つです。従来のMySQLの実装では、データベースが大きくなるにつれてリカバリ時間が長くなります。MySQLはREDOログファイルを使用するため、クラッシュするとMySQLはテーブルの検出や検証オペレーションを大量に実行します。データベースの表領域が大きいほど、リカバリに必要な時間は長くなります。この影響は MySQL 5.7 でも当てはまります。 このような要因から、MySQLから Amazon Aurora への移行に関心が集まっています。この移行を実行するにはいくつかの方法がありますが、今回は Amazon RDS for MySQL またはオンプレミスや Amazon EC2 上のMySQLから Amazon Aurora with MySQL compatibility への同種間移行について考えます。 同種間移行の方法 AWSホワイトペーパーのサイトにある Amazon Aurora Migration Handbook で同種間移行のための推奨方法がリストされています。Amazon RDS for MySQL から移行するのであれば、RDSスナップショットでの移行方法を使用できます。この方法では、RDS MySQL のDBインスタンスのスナップショットから Aurora MySQL DB クラスターを作成します。これは非常に簡単です。Amazon Aurora へニアゼロダウンタイムで移行した場合は、ソースとなる RDS MySQL DBインスタンスからAuroraリードレプリカを作ることができます。RDSが Amazon Aurora […]

Read More

Amazon Redshiftを使用した高性能ETL処理のベストプラクティス Top 8

ETL(Extract、Transform、Load)プロセスを使用すると、ソース・システムからデータ・ウェアハウスにデータをロードできます。 これは、通常、バッチまたはほぼリアルタイムのインジェスト(挿入)プロセスとして実行され、データウェアハウスを最新の状態に保ち、エンドユーザーに最新の分析データを提供します。 Amazon Redshiftは、高速でペタバイト規模のデータウェアハウスであり、データ駆動型の意思決定を簡単に行うことができます。 Amazon Redshiftを使用すると、標準的なSQLを使用して、費用対効果の高い方法で大きなデータを洞察することができます。 StarおよびSnowflakeスキーマから、分析クエリを実行するための単純化された正規化されていないテーブルまで、あらゆるタイプのデータモデルを使用した分析が可能です。 堅牢なETLプラットフォームを操作し、Amazon Redshiftにデータをタイムリーに配信するには、Amazon Redshiftのアーキテクチャを考慮してETLプロセスを設計します。 従来のデータウェアハウスからAmazon Redshiftに移行する場合、リフト・アンド・シフト方式を採用することが魅力的ですが、結果としてパフォーマンスとスケールの問題が長期的に発生する可能性があります。 この記事では、ETLプロセスにおける最適かつ一貫した実行時間を確保するためのベスト・プラクティスを下記にご紹介します。 複数の均等なサイズのファイルからデータの COPY Workload Management (WLM) を用いたETL実行時間の改善 定期的なテーブルのメンテナンスの実施 単一のトランザクションで複数ステップの実行 データの一括読み込み UNLOADを利用した大きな結果セットの抽出 アドホックETL処理に Amazon Redshift Spectrumを使用 診断クエリを使用して日常的なETLヘルスの監視 1. 複数の均等なサイズのファイルからデータの COPY Amazon RedshiftはMPP(大規模並列処理)データベースで、すべての計算ノードがデータの取り込み作業を分割して並列化します。 各ノードはさらにスライスに細分され、各スライスは1つ以上の専用コアを有し、処理能力を等しく分割します。 ノードあたりのスライス数は、クラスタのノードタイプによって異なります。 たとえば、各DS2.XLARGE計算ノードには2つのスライスがありますが、各DS2.8XLARGE計算ノードには16のスライスがあります。 Amazon Redshiftにデータを読み込むときは、各スライスに同じ量の作業をさせることを目指すべきです。 1つの大きなファイルまたは不均一なサイズに分割されたファイルからデータをロードすると、一部のスライスは他のスライスよりも多くの仕事をする必要があります。 その結果、プロセスは最も遅い、または最も負荷の高いスライスと同じ速度で実行されます。 以下の例では、1つの大きなファイルが2ノードのクラスタにロードされ、ノード「Compute-0」のうちの1つだけがすべてのデータ処理を実行します。 データファイルを分割する際には、圧縮後のサイズがほぼ同じ(1 MB〜1 GB)であることを確認してください。 ファイル数は、クラスタ内のスライス数の倍数にする必要があります。 また、gzip、lzop、またはbzip2を使用してロードファイルを個別に圧縮し、大規模なデータセットを効率的にロードすることを強くお勧めします。 1つのテーブルに複数のファイルをロードする場合は、複数のCOPYコマンドではなく、テーブルに対して1つのCOPYコマンドを使用します。 Amazon Redshiftはデータの取り込みを自動的に並列化します。 1つのCOPYコマンドを使用してデータをテーブルにバルクロードすると、クラスタリソースの最適な使用と可能な限り高いスループットが可能となります。 2. Workload Management (WLM) を用いたETL実行時間の改善 […]

Read More

東京リージョンで Amazon Aurora with PostgreSQL Compatibility をご利用可能に

Amazon Aurora PostgreSQL-compatible edition が、アジアパシフィック (東京) でも利用可能となりました。これにより、データベースの構築、可用性、スケーラビリティを確保するための選択肢が広がります。 Amazon Aurora は、ハイエンドな商用データベースのパフォーマンスと可用性、オープンソースデータベースのシンプルさとコスト効率性を兼ね備えています。Amazon Aurora は、一般的な PostgreSQL データベースと比べてパフォーマンスが最大 3 倍であり、さらにより高いスケーラビリティ、耐用性、およびセキュリティを備えています。詳しくは、Amazon Aurora の製品ページをご覧ください。リージョンごとのサポート状況については、製品およびサービス一覧をご覧ください。 Recent Updates 2018年に入り、RDS for PostgreSQL からの移行に関して機能が追加されています。 Amazon RDS for PostgreSQL のリードレプリカとして Aurora PostgreSQL レプリカの作成:これにより、スナップショットからの移行に比べてよりダウンタイムの短い移行が実現できます。 暗号化されたスナップショットからの移行:これにより暗号化された状態を維持したまま、 RDS for PostgreSQL インスタンスからの移行が可能です。 移行について 既存のデータベースからの移行については、その運用環境に基づいて、いくつかの選択肢が考えられます。RDS for PostgreSQL をご利用の場合、AWS が提供する機能を利用して移行できます。上記のアップデートでも紹介しましたが、具体的には以下の通りです。 Aurora レプリカを利用した RDS for PostgreSQL からのレプリケーション RDS for PostgreSQL スナップショットからの移行 注意点として、上記の2つの機能を利用するためには、現在のところ RDS for […]

Read More

Amazon Aurora: MySQL 5.7互換をリリース

Amazon AuroraのMySQL 5.7互換版が皆様にご利用頂けるようになりました。JSONサポート、空間インデックス、generated columnsなどをご利用頂け、MySQL 5.7より最大5倍高速です。 Amazon Auroraの空間インデックスの作成は、MySQL 5.7よりも20倍以上の書き込みパフォーマンスと10倍以上の読み込みパフォーマンスとなっています。この機能がどのように実装されているかについては、AWSデータベースブログをご覧ください。またAmazon Auroraのドキュメントもご参照下さい。 Aurora with MySQL compatibilityがご利用頂ける13リージョン(US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Canada (Montreal), Europe (Ireland), Europe (Frankfurt), Europe (London), Europe (Paris), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Seoul), and Asia Pacific (Mumbai))全てでご利用頂けます。 ハイエンドな商用データベースのパフォーマンスと可用性を、オープンソースデータベースのシンプルさとコスト効率と組み合わせたAmazon Aurora (MySQLとPostgreSQL互換のリレーショナルデータベース)の詳細については、Amazon Auroraの製品ページをご覧ください。 CLIを用いた際のエンジンバージョンの指定方法や、スナップショットを利用したアップグレードなどAurora MySQL5.7互換に関する詳細な情報はドキュメントやフォーラムアナウンスをご覧ください。 […]

Read More

プロセッサの投機的実行 – オペレーティングシステムの更新

モダンコンピュータプロセッサ上で投機的実行によるサイドチャネル分析の調査が新しく公開されたのを受け、AWS は AWS Security Bulletin(セキュリティ情報)AWS-2018-013 を先日公開しました。このセキュリティ情報では、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 の3つのセキュリティ勧告に触れています。これらの勧告は Google Project Zero の調査に基づいたもので、Google Project Zero の発表はモダンコンピュータプロセッサ上でのサイドチャネル分析の新しい方法を発見したというものでした。これらの方法は、基礎的な技術、具体的には投機的実行に着目したもので、投機的実行は多くのベンダーのプロセッサに用いられています。そのため研究結果の対象となる範囲は幅広く、その範囲はハイパーバイザーからオペレーティングシステム、さらには Web ブラウザ、携帯電話からクラウドを構成するデータセンター内のサーバにまで及びます。   EC2 インスタンスの分離   Amazon EC2 のすべてのインスタンスは、上述の CVE に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 大多数の EC2 ワークロードに有意なパフォーマンスの影響は見られていません。   オペレーティングシステムへのパッチ   現代のオペレーティングシステムには、「ユーザー空間」プロセスからのカーネル分離、それぞれのプロセスの分離などの、いくつかのタイプのプロセス分離があります。影響を受けうるプロセッサ上でオペレーティングシステムが実行されている環境では、いかなる設定においても、公開された 3 つの問題すべてがプロセス分離に影響を与える可能性があります。ハイパーバイザで実装されている保護は、オペレーティングシステム内のプロセスレベルの分離にまで拡張されないため、リスクを軽減するためにオペレーティングシステムパッチが必要です。 準仮想化(PV)インスタンスでは、CVE-2017-5754 のプロセス間の問題に対処するためのオペレーティングシステムレベルの保護は無いことに注意してください。PV インスタンスは、前述のようにインスタンス間の問題について AWS ハイパーバイザーによって保護されます。しかしながら、PV インスタンスにおけるプロセスの分離(信頼できないデータ処理やコードの実行、ユーザのホスト)にご懸念をお持ちでしたら、長期的に見てセキュリティの恩恵を受けるため、HVM インスタンスタイプへの変更を強くお勧めします。PVとHVMの相違点(およびインスタンスアップグレードパスのドキュメント)の詳細については、以下の URL を参照してください。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html インスタンスのオペレーティングシステムにパッチを適用することで、同じインスタンス内で動作するソフトウェアを分離し、CVE-2017-5754 のプロセス間の問題を緩和することを強く推奨します。以下のオペレーティングシステムのパッチの詳細を記載します。 Amazon Linux & […]

Read More

Amazon Aurora under the hood: Z-order curvesを用いたgeospatial indexの作成

Amazon Auroraのような高性能データベースシステムを設計する場合、一般的に最も幅広いワークロードを大きく改善出来るように取り組みたいと考えるかと思います。しかし時には、ゲームチェンジャーになりえる機会がある場合、特別な用途向けに改善を行うこともあります。 geospatial indexとはなにか、なぜ考慮する必要があるのか? 地理空間分析では、XY(Z)座標に沿った近さ、隣接性、重なりを識別することができます。 そのような分析を実行する必要があるアプリケーションには様々な例があります。タクシーアプリでは、利用可能な最寄りのタクシーを見つけることができます。不動産アプリは、サンフランシスコのPacific Heights地区で販売されている物件を探すことができます。 空間分析は、他にも多くの用途でも役立ちます: マーケティング – 店舗から2マイル以内のすべての見込み顧客をターゲットにプロモーションを行います 資産管理 – 顧客の位置と密度に基づいて影響を最小限に抑えるために修理ユニットを配置します リスク分析 – 顧客の居住地や職場の近くで車の盗難が発生した場合のリスクを見積もります 詐欺検出 – 前回のトランザクションからの距離に基づいて詐欺と考えられる取引の可能性を推定します ロジスティクス計画 – 運行の範囲を最小限にするように、トラブルのチケットを現場の技術者に割り当てます これらのアプリケーションは、高性能な空間データのインデックスから利益を得ることができます。残念なことに、Bツリーのような伝統的なインデックスは、Linlandのために作られたものであり、FlatlandやSpacelandではそうではありません。そのため、高性能な空間インデックスが必要です。 Rツリーとは? 最も一般的に使用される空間インデックスはRツリーです(詳細はこちらの論文を参照してください)。 MySQLとOracleはどちらもR-treeを使用しています。基本的な考え方は、バランスサーチツリーないにバウンダリーレクタングルを保存することです。リーフはデータポイントであり、各内部ノードは、その下のノードのミニマムバウンダリーレクタングルです。したがって、次の例では、長方形Aはリーフノードです。このノードは、矩形NおよびTによって順番に境界が作成されます。 Rツリーの主な問題は、安定していないことです(つまり、決定論的です)。挿入順序が異なると、異なるツリーが生成され、パフォーマンスの特性が大きく異なります。私たちのテストでは、ランダムな挿入順序では、最適な順序で構築されたツリーよりも1桁も性能が劣化したツリーが生成されました。これは、データの挿入順序が予測できず、変更可能なOLTP環境では明らかに問題になります。このような状況では、Rツリーは時間とともに性能が劣化します。1つの回避策は、データを定期的にインデックスを再構築することです。しかし、インデックスの再構築は負荷がかかります。加えて通常この作業は、手作業が必要であり、数時間かかることがあります。また、その期間中の他のトランザクションは遅くなる可能性があります。 そのため、Rツリーは人気がありますが、常に良好なパフォーマンスは得られません。 他にいい方法はあるのか? 私たちはそう考えています!トランザクションと同時実行に最適なデータ構造があります。それはBツリーです。 あらゆる場面で使用され、高いパフォーマンスを発揮するのはデータベースにとって基本です。 しかし、ちょっと待ってください。私はB-treeが多次元データに対してうまく機能しないと言いました。それは本当です。2次元を1次元にマップするトリックがあります。 私たちは、space-filling z-order curves(空間充填zオーダー曲線)を使用して行います。これは、ポイントのz値は、その座標値のバイナリ表現をインターリーブすることによって計算されます。zオーダー曲線は、これらの点をz値の順に横切る線です。たとえば、次の図は、0≤x≤7、0≤y≤7の整数座標の場合のz値を示しています(10進数と2進数の両方を示しています)。 zオーダー曲線上のBツリーの単純な実装では不十分です。なぜこれが当てはまるのかを知るために、以下の例を見てみましょう。緑色の四角形内のすべての点をBツリーで検索すると、クエリー領域外に30個の余分なz値(黄色い三角形の警告標識が付いている物)がスキャンされます。 元のクエリをより少ない偽陽性z値をカバーする小さなクエリに分割することで、この問題を改善します。(これを行うために幾つかの方法を使用していますが、それはこの記事でお伝えする範囲を超えています) それは私たちがポイントするために必要なものすべてを提示します。ポリゴンはどのように空間充填曲線で動作するのでしょうか?ポリゴンが単一点のように見えるまでズームアウトしたとします。どの程度ズームアウトしなければならないかは、ポリゴンの”レベル”によります。各空間オブジェクトは、オブジェクトのレベルとzアドレスの組み合わせとしてBツリーに格納されます。zアドレスがポイントのように見えるまでズームアウトしたので、zアドレスをポイントのように扱うことができます。他のシステムでは、このレベルを手動で指定する必要があります。明らかに、予測不可能で変更可能なデータを扱うOLTPシステムでは動作しません。このレベルはユーザーの設定なしで自動的に設定します。 Auroraのgeospatial indexesは、MySQL 5.7よりもselect-only(1秒当たりの読み込み回数)ワークロードで10倍以上、write-only(1秒当たりの書き込み回数)で20倍以上優れています。具体的には、サイズが1 GB未満のデータセットでSysbenchを使用して、AuroraとAmazon RDS for MySQL 5.7をdb.r3.8xlargeインスタンスを用いて計測しました。select-onlyのテストでは、2,000クライアントとST_EQUALSクエリを使用しました。write-onlyテストでは、4,000のクライアントを使用しました。 ご質問がある場合は、aurora-pm@amazon.comまでご連絡ください。 About the Author Sirish Chandrasekaran is a product […]

Read More

Amazon RDS for PostgreSQL から Amazon Aurora PostgreSQL リードレプリカを作成可能になりました

Amazon Aurora PostgreSQL リードレプリカ(2018/1/23現在英語版ドキュメントのみとなっています)を Amazon RDS for PostgreSQL のインスタンスとして作成し、継続的に Amazon Aurora PostgreSQL へレプリケーション出来るようになりました。これにより、実稼働ワークロードを Amazon RDS for PostgreSQL から Amazon Aurora PostgreSQL に移行する際、アプリケーションとユーザーを Amazon Aurora PostgreSQL へ移す準備ができるまで、インスタンスタイプを同期させておくことで、ダウンタイムを最小化させることが可能です。 Amazon Auroraは、高性能の商用データベースのパフォーマンスや可用性と、オープンソースデータベースのシンプルさや費用対効果を兼ね備えています。スケーラビリティ、耐久性、およびセキュリティの向上とともに、高いクエリ並列度、データサイズが大きい環境下で標準的なPostgreSQLデータベースのパフォーマンスを最大で3倍向上させます。詳細については、Amazon Auroraの製品ページをご覧ください。 翻訳は江川が担当しました。原文はこちらをご覧ください。

Read More

暗号化されたスナップショットを Amazon Aurora PostgreSQL へ移行可能になりました

Amazon RDS for PostgreSQL の暗号化されたスナップショットから Amazon Aurora PostgreSQL へ移行できるようになりました。これにより、Amazon RDS から Amazon Aurora へ移行中の間も、データ暗号化を維持することが可能です。 Amazon Auroraは、高性能の商用データベースのパフォーマンスや可用性と、オープンソースデータベースのシンプルさや費用対効果を兼ね備えています。スケーラビリティ、耐久性、およびセキュリティの向上とともに、高いクエリ並列度、データサイズが大きい環境下で標準的なPostgreSQLデータベースのパフォーマンスを最大で3倍向上させます。詳細については、Amazon Auroraの製品ページをご覧ください。 翻訳は江川が担当しました。原文はこちらをご覧ください。

Read More

Microsoft Azure SQL Database から Amazon Aurora への移行

Oracle や Microsoft SQL Serverなどのライセンスが必要なエンジンから、AWS上で稼働するオープンソースエンジンへ移行する気運がますます高まっています。対象データの移行先として Amazon Aurora が選ばれています。この投稿では AWS Database Migration Service (AWS DMS) を用いた Microsoft Azure SQL database から Amazon Aurora MySQL クラスタへの移行方法を紹介します。 前提条件 この記事では、Azure SQLデータベースが既にインストールされていることを前提としています。移行には、このデータベースの接続情報(DNSエンドポイント、ユーザー名、パスワードなど)が必要です。また、移行作業に使用するユーザには、Azure SQLデータベースのデータにアクセスするための適切な権限が必要です。 記事の目的に合わせ、ターゲット(移行先データベース)として Amazon Aurora クラスタを作成します。 AWS DMSはソース(移行元データベース)およびターゲットとして、様々なデータベースエンジンをサポートしていますが、多くのお客様は独自のストレージエンジンを使用したAmazon Auroraを選択します。このエンジンは、3つのアベイラビリティゾーンに跨る耐久性、自動ポイントインタイムバックアップ、最大15台の低レイテンシ読み取りレプリカを実現します。 ターゲット用の Aurora クラスタを既に作成している場合は、新規に作成する必要はありません。新しい Aurora クラスタを作成する場合は、Amazon Aurora DB クラスタ作成の手順を参照してください。 AWS DMS インフラのセットアップ ここまででソースとターゲットの情報が確認できたので、AWS DMS インフラを設定していきましょう。 AWS DMSは非常に高い柔軟性をもつ為、多くのコンポーネントから構成されています。AWS CloudFormationを使用することで、これらのコンポーネントをまとめて単一の「スタック」にグループ化し、原子性を保った1つのユニットとして何度も再作成することができます。 AWS CloudFormation のコンソールを開いて設定を始めます。 […]

Read More