Category: Database

この投稿では、商用データベースから Amazon Aurora への移行を容易にするために AWS Schema Conversion Tool (AWS SCT) と AWS Database Migration Service (AWS DMS) をどのように使えるかの概要をお伝えします。今回は、Oracleから Amazon Aurora with MySQL Compatibility への移行にフォーカスします。 データベースエンジンの変更は不安を伴うかもしれません。しかし、Amazon Aurora のようなスケーラビリティやコスト効果の高いフルマネージドサービスのバリュープロポジションは、それに挑戦する価値を生み出します。その手順を簡単にするツールがある場合は特にです。データベースをあるエンジンからほかのものに移行するとき、主に2つのことを考慮する必要があります。スキーマとコードオブジェクトの変換と、データ自身の移行と変換です。幸いにも、データベースの変換と移行の両方を容易にするツールをAWSは用意しています。 AWS Schema Conversion Tool は移行元データベースのスキーマとカスタムコードの大部分を新しい移行先データベースと互換性のあるフォーマットに自動的に変換することで、異なるプラットフォーム間でのデータベース移行をシンプルにします。このツールが変換するカスタムコードには、ビューやストアドプロシージャ、ファンクションを含みます。このツールで自動変換できない一部のコードは明確に示されるので、ユーザー自身でそれを変換することができます。AWS Database Migration Service は最小限のダウンタイムでデータを簡単かつ安全に移行することを手助けします。 すばらしい！ では、どこから始まれば良いのでしょう？ AWS SCT での移行手順 通常、移行の最初のステップは実現可能性と作業量のアセスメントです。現行のOracleからAuroraにデータベースを移行するために要する作業量の大枠な概要を AWS SCT は生成することができます。SCTはいくつかのOS上で動作しますが、このブログではWindows上で動かします。SCTをダウンロードするためには、マニュアルの AWS Schema Conversion Tool のインストールと更新 をご覧ください。SCTのマニュアル全体を見たい場合は AWS Schema Conversion Tool […]

こんにちは。ソリューションアーキテクトの江川です。本日は、AWS のプロダクトマネージャーである Eran Schitzer が、AWS Database Blogに投稿したEvents and Notifications in AWS Database Migration Service を翻訳してご紹介します。 先日、AWS Database Migration Service (AWS DMS) に新機能が追加され、Amazon Simple Notification Service (Amazon SNS)を介して、Email や テキストメッセージ、HTTP エンドポイントへの通知といった形で、DMS のイベント通知を受け取れるようになりました。 お客様は2種類のイベント(DMS インスタンスに関連するイベントと、レプリケーションタスクに関連するイベント)をサブスクライブし、通知を受信できます。DMS インスタンスに関連するイベントには、可用性、設定変更、作成、削除、メンテナンスに関するイベントが含まれます。例えば、DMS インスタンスがメンテナンスにより停止すると、通知がトリガーされます。 レプリケーションタスクに関連するイベントには、タスクの開始、停止、終了、Full Load の完了、CDC の開始などのイベントが含まれます。例えば、移行タスクとしてすべてのデータを移行し終えると、“Full Load completed” という通知がトリガーされます。もし、タスクが Full Load に続けて、CDC を実行する(つまり、Full Load が開始してからのデータの変更をレプリケーションする)設定となっていた場合は、続けて “CDC started” という通知がトリガーされます。 さらに、AWS DMS ではイベントが様々なカテゴリに分類されており、ユーザーは AWS DMS […]

ミックスワークロードの環境下では、ビジネス上の要求を満たすために、バッチとインタラクティブのワークロード双方が同時に実行されます。ミックスワークロードを管理し構成するには、アクセスパターンやシステムリソースの使われ方、およびパフォーマンス要件についての詳細な理解が必要です。 ミックスワークロードでは、一般に、一部のプロセスが他より高い優先順位を必要とします。あるケースでは、これはあるジョブが特定のSLA内で完了しなくてはならないことを意味します。別のケースでは、あまりクリティカルではないレポーティングワークロードが一度に多くのクラスターリソースを消費しすぎないようにするだけでよいこともあります。 ワークロード管理（WLM）を利用しない場合、各クエリーは同じ優先順位で処理されます。これによって、あるメンバー、チーム、あるいはワークロードが、他のビジネス上重要なジョブに比べてさほど重要ではない処理のために、大量のクラスターリソースを消費するといった事態が起こり得ます。 このブログポストでは、一般的なWLMパターンに関するガイドラインを提供するとともに、WLMに関連する様々なクエリーとビューを使用して本番ワークロードの構成を最適化する方法について記載します。 ワークロードの概念 WLMを使用して、複数のビジネスワークロードを分離すると共に、システム上で実行される様々なタイプの同時実行クエリ−の優先順位を設定することができます。 インタラクティブ：実行する人間の入力を受け付けるソフトウェア。インタラクティブなソフトウェアには、BIツールやレポーティングアプリケーションなどのポピュラーなプログラムが含まれます。 短時間のみ実行される、読み取り専用のユーザークエリー。低レイテンシーで実行する要件を含むTableauダッシュボードクエリーなどが該当します。 長時間実行される、読み取り専用のユーザークエリー。過去10年間の営業データの集計する複雑な構造化レポートなどが該当します。 バッチ：手動介入を伴わない、サーバープログラム内の一連のジョブの実行（非インタラクティブ）。単一の入力ではなく、複数の入力の集合（”バッチ的な”入力とも言えます）に基づく一連のプログラムの実行は、カスタムジョブと呼ばれます。 一括で実行されるINSERT、UPDATE、およびDELETEトランザクションもバッチクエリーに含まれます。ETLやELTプログラムはこの一例です。 Amazon Redshift ワークロード管理（WLM） Amazon Redshift はスケーラビリティ、セキュリティおよび高パフォーマンスを提供する、ペタバイトスケール・カラムナー・超並列型の、完全に管理されたデータウェアハウスです。Amazon Redshiftは業界標準のJDBC/ODBCドライバーインターフェイスを提供します。これにより、お客様は彼らの既存のBIツールを用いて接続することができ、また既存の分析クエリーを再利用することが可能です。 Amazon Redshiftは様々な種類の分析的データモデルに適合します。例えば、スタースキーマ、スノーフレークスキーマや、 シンプルな非正規化テーブルなどが利用できます。 ワークロードを管理する Amazon Redshiftワークロード管理は、特定環境下における、様々なサイズと複雑性を持つワークロードの管理を可能にします。WLMの構成はパラメーターグループに含まれ、いくつのクエリーキューが処理に利用可能か、およびそれぞれのキューがどのようにそれらのキューにルーティングされるかを決定します。カスタムパラメーターグループを作成してグループ内の設定を編集し、それをクラスターに関連付けて下さい。以下のような設定が構成可能です。 それぞれのキュー内でいくつのクエリーが同時に実行可能か キュー間でのメモリ配分 クエリーがどのようにキューにルーティングされるか。誰がクエリーを実行しているか、クエリーレベルは、などの基準 あるキューにおけるクエリータイムアウト設定 ユーザーがクエリーを実行する際、WLMはそのクエリーを最初にマッチしたキューに割り当てた上で、WLMの構成に基づいてルールを実行します。WLMクエリキュー、同時実行、ユーザーグループ、クエリーグループ、タイムアウト設定、およびキューホッピング機能等の詳細については、クエリーキューの定義を参照して下さい。動的に変更可能な構成プロパティの詳細については、WLM の動的設定プロパティと静的設定プロパティを参照して下さい。 例えば、以下のスクリーンショットのWLM構成では、ETL、BI、およびそれ以外のユーザーをサポートするための三つのキューが構成されています。ETLジョブは長時間実行用のキューに割り当てられ、BIクエリーは短時間実行用のキューに割り当てられます。その他のユーザーのクエリーはデフォルトキューで実行されます。   WLM最適化クラスター構成のガイドライン 1. 複数のビジネスワークロードを分離し、クエリーを互いに独立して実行する。 ダッシュボードクエリーとETLといった異なるビジネスプロセスをサポートするため、互いに独立したキューを作成します。例えば、ワンタイムクエリーのための独立したキューを作成することは、それらのクエリーがより重要なETLジョブを阻害しないようにするための有益なソリューションと言えます。 また、より短時間で実行されるクエリーは一般的にメモリー使用量が少ないため、それらのワンタイムユーザーやクエリーグループ用のキューには、より低いWLM使用メモリー比率（訳者註：マネジメントコンソール上の”メモリ（％）”の設定値）を設定することができます。 2. 同時実行数やメモリー割り当てをアクセスパターンに合わせてローテーションする。（適合するユースケースの場合） トラディショナルなデータ管理では、ETLジョブはソースシステムから特定のバッチウィンドウ内でデータを取得、整形した後、ターゲットのデータウェアハウスにロードします。このアプローチでは、業務時間中は、BI_USERグループにより多くの同時実行数とメモリを割り当て、ETL_USERには非常に限られたリソースのみを割り当てます。業務時間後は、重くリソースインテンシブなジョブが迅速に完了するよう、ETL_USERへの割り当てを動的に変更またはスイッチすることを、クラスターの再起動なしに行うことが可能です。 注：下記のAWS　CLIコマンドサンプルはデモ目的のために、複数の行で表示されています。実際のコマンドは改行を挟まず一行で実行する必要があります。また、下記のJSON構成にはエスケープクォートが必要です。 WLM設定を動的に変更する方法として、AWSはスケジュールされたLambda関数あるいはスケジュールされたデータパイプライン（ShellCmd）をお勧めします。 3. ミックスワークロード（ETLとBIワークロード）を継続的にサポートないし最適化するために、キューホッピングを使用する WLMキューホッピングは、読み取り専用クエリー（BI_USERのクエリー）が、キャンセルされる代わりにあるキューから別のキューに移動することを可能にします。例えば、以下のスクリーンショットにあるように、二つのキュー（一つはタイムアウトが60秒に設定されたインタラクティブクエリー用のもの、もう一つはタイムアウトなしで設定されたバッチクエリー用のもの）を作成し、同じユーザーグループ（BI_USER）をそれぞれのキューに設定します。WLMは、インタラクティブキューで実行され、タイムアウトしたBI_USERのクエリー（のみ）を、バッチキューに自動的に再ルーティングし再実行します。 この例では、ETLワークロードはBIワークロードクエリーを阻害しません。長時間実行されている読み取り専用クエリーは、自動的にバッチとして分類され、より短時間で完了するクエリーをブロックしないようになります。 4. リソースインテンシブなETLやバッチクエリー用に、スロットカウントを一時的に増やす。 Amazon Redshiftはメモリー不足エラーを回避するために中間結果をディスクに書きますが、ディスクI/Oはパフォーマンスを劣化させる要因となります。次のクエリーは、ディスク上で実行されているアクティブクエリーを表示します。 SELECT query, label, is_diskbased FROM svv_query_state […]

昨年、Amazon Aurora に PostgreSQL 互換のエンジンをリリースするとアナウンスしました。その際、プライベートプレビューのサインアップを紹介し、申し込んでいただくようご案内しました。 そのリクエストの反応は非常に大きいものでした！お客様は既に Amazon Aurora が高い可用性、堅牢性を提供することを理解し、ご自身の PostgreSQL 9.6 アプリケーションを AWS クラウドで動かすのを楽しみにされていました。 Opening up the Preview 本日、興味をお持ちのすべてのお客様に Amazon Aurora with PostgreSQL Compatibility の プレビューを開放し、こちらからサインアップ可能となります。プレビューは、米国東部(バージニア北部)リージョンで実施され、従来の環境で運用されていたPostgreSQL に比べて、2-3倍の性能を提供します。このプレビューでは、高速で低レイテンシなリードレプリカをすばやく簡単に作成することも可能です。 Amazon RDS Performance Insights もPreview にてご利用可能です 本プレビューには、Amazon RDS Performance Insights も含まれます。このツールを利用することで、各クエリの詳細を含む細かいレベルでデータベース性能を確認することができます。Performance Insight ダッシュボードを通して、データベースの負荷を可視化し、SQL, waits, users, hostsという観点でフィルタリングできます: — Jeff; 原文: Sign up Today – Preview of Amazon Aurora with […]

既にAmazon DynamoDBの事はご存知の方が多いと思います。ご存じのように、必要なだけのテーブルスペース、読み込み容量、書き込み容量に対応できるように拡張されたフルマネージドのNoSQLデータベースです。応答時間は1桁のミリ秒単位で測定され、多くのお客様がadtech、IoT、ゲーム、メディア、オンライン学習、旅行、電子商取引、金融など、さまざまな種類のアプリケーションにDynamoDBを使用しています。一部のお客様では一つのDynamoDBテーブルに100TB以上のデータを格納し、1秒当たり何百万もの読み取りまたは書き込み要求を行います。 Amazonの小売サイトはDynamoDBに依存しており、Black Friday、Cyber​​ Monday、Prime Dayなどの短時間で高強度のイベントに関連するトラフィックの急増に耐えます。 DynamoDBは、あらゆるアプリケーションやワークロードに対して、高速で一貫性のあるパフォーマンスのメリットを提供することができますが、常に改善の余地があります。いくつかのワークロード（ゲームやadtechが代表的な例ですが、他にもたくさんあります）のビジネス価値は、低レイテンシかつ高性能な読み取り処理を行えるデータベースによってもたらされます。できるだけ早くDynamoDBからデータを取得する機能により、クリックスルー率が最も高いゲームや広告の反応が速くなります。   Amazon DynamoDB Accelerator このような重い読み込み処理を必要とする方の為に我々はパブリックプレビューでAmazon DynamoDB Acceleatorをローンチしました。DAXとも呼びます。 DAXはフルマネージドのキャッシュサービスでDynamoDBテーブルの前段（論理的に）に置かれます。Write – throughモードで動作し、DynamoDBとAPI互換を持っています。キャッシュからレスポンスが返る時はマイクロセカンドのレスポンスを実現し、eventually – consistentなread heavyなワークロードに特に向きます。DAXはシームレスかつ簡単に使えます。シンプルにDAXクラスターを作成する事が出来、アプリケーション側に読み書きのエンドポイントのターゲットとしてDAXを指定するだけです。DAXにパッチを当てるオペレーションをしたり、クラスタのマネジメントやレプリケーション、障害について心配することはありません。 DAXクラスタは1~10ノードで構成されます。読み込み処理の量に応じてノードを追加する事が可能です。クラスタでキャッシュ出来るサイズ（working setとも呼ばれる）はベースとなるノードの大きさ（dax.r3.large から dax.r3.8xlargeまで選択出来ます）を選択してクラスタを作成します。クラスタはVPC内に作成されAvailabillty Zones毎に分割してノードを配置出来ます。 利用するにはDAX for Java SDKを必要とします。このSDKは作成したクラスタとlow – level TCPでのやりとりを行う事で低レイテンシかつ高スループットを実現するためにチューニングしてあります。（我々は今後他の言語向けSDKについても速やかに対応する方針です。） DAX クラスタの作成 それではDAXクラスタをDynamoDB Consoleから作ってみましょう（APIやCLIでの操作も可能です）。マネジメントコンソールのCreate clusterをクリックして始めます。 まず名前と詳細を入力し次にノードタイプを選択します。そして初期のクラスタサイズを設定します。DAXに与えるIAM roleとpollicyとして私のDynamoDBテーブルにアクセス出来る権限を設定します。（必要な権限が設定されている既存の物を指定する事も可能です。） 例としてコンソールではポリシーとして一つのテーブルにアクセス出来る権限を許可します。アクセスするテーブルを追加したくなったらIAMのコンソール上からポリシーを編集する事で可能です。 次にDAXで使われるノードを配置するサブネットグループを作成します。グループ名とどのサブネットを使うか選択します。 デフォルト設定で起動する事を確認したらLaunch clusterをクリックします。 クラスタは数分で起動します。 次に私のアプリケーションをDAX SDKを使うようにしエンドポイントとして私のDAXクラスタのエンドポイントを指定します。（今回ではdax1.seut3.clustercfg.use1.cache.amazonaws.com:8111です） アプリケーションを起動し実行、Metricsタブを選択するとキャッシュパフォーマンスに関係するメトリクスを見ることが出来ます。 Amazon CloudWatchメトリクスに含まれキャッシュヒットやキャッシュミス、リクエストカウント、エラーカウントなどが見れます。 Alarmsを選択する事でこのメトリクスを利用したCloud Watch Alarmを作る事が出来ます。 例えばキャッシュミスが異常な数になった物を検知する事が出来ます。 Nodesタグを選択する事でクラス内のノードリストを見ることが出来ます。新しいノードを追加したり削除する事が可能です。 DAXがどのように動いているか、DAXのサンプルアプリケーションをインストールして二回実行してみます。初めにDynamoDBにダイレクトアクセスし、キャッシュが無い状態で操作を行います。ベースラインパフォーマンスとしては以下の通りです。 […]

現在、数クリックでクラウド上にコンピュートリソースやストレージリソースを構築可能です。現在のチャレンジは、それらのリソースを活用して生のデータを出来る限り素早く、かつ効果的に活用可能な結果に変換することです。 Amazon Redshiftを活用することで、AWSのお客様はペタバイト級のデータウェアハウスを構築し、社内・社外の多様なデータソースからのデータを統合することが可能です。Redshiftは巨大な表に複雑なクエリ（複数の表をジョインする等）を実行することに最適化されているため、小売、在庫、ファイナンシャルデータといった膨大なデータを特別な苦労なく処理することができます。Redshiftにデータをロードした後は、Redshiftパートナーが提供するビジネスインテリジェンス（BI）ツールやエンタープライズレポーティングツールを活用することが可能です。 データウェアハウスを使い続ける上での１つの大きなチャレンジは、継続的に更新される、もしくは追加されるデータを速いペースでロードすることです。高速なクエリーパフォーマンスを提供するために、データをロードするというフェーズでは圧縮、データの正規化や最適化といった作業が行われます。これらの作業自体は自動化、スケールさせることは可能ですが、複雑なロード作業はデータウェアハウス維持にオーバーヘッドと複雑さを追加し、効果的な活用方法を得ることを阻害する場合もあります。 データフォーマットについては別の興味深いチャレンジが存在します。いくつかのアプリケーションはデータウェアハウスの外でデータ元々のフォーマットのままで処理を行っています。他のアプリケーションはデータウェアハウスにデータを取り込み、クエリーを実行しています。この利用方法だと同じデータが２つの場所に存在することになりますのでストレージを効率的に使えていないことになりますし、ロードがタイムリーに行われていない環境では、それぞれのアプリケーションで異なった結果が返る可能性があります。 Amazon Redshift Spectrum データを置いた場所によらず、そのままのデータフォーマットでAmazon Redshiftのパワーとフレキシビリティを活用できるようにするため、Amazon Redshift Spectrumをローンチいたします。Spectrumを使うことで、Amazon Simple Storage Service (S3)上に置かれたファイルをRedshiftにロードしたり特殊な準備をすることなく、高度なクエリを実行することが可能になります。 使い方はこれまで通り、データソース（データベースへの接続）を作成してクエリーをRedshiftに投入するだけです。クエリー実行の背後ではSpectrumが数千台までスケールするインスタンスが用意されており、データセットがエクサバイトを超えて大きくなっても、高速なデータ取り出しと一貫したパフォーマンスを実現します！S3上のデータを直接クエリーできるようになるということは、Redshiftのクエリーモデルや、全てのレポーティングツール、BIツールを維持したまま、コンピュートリソースとストレージリソースをそれぞれ独立してスケールさせることが出来るようになるということです。クエリーはRedshiftにストアされたデータとS3上に置かれたデータの任意の組み合わせを参照することが可能です。 クエリーが投入されると、Redshiftはクエリーを分解してクエリープラン（実行計画）を作成します。クエリープランはS3上に置かれたデータにおけるカラムナ（列指向）フォーマットの特性および日付等のキーでのパーティションの特性をいかし、読み取る量が最小になるように作成されます。クエリープランが出来るとRedshiftは巨大な共有プールに用意されているSpectrumワーカーに指示を出し、射影・フィルター・アグリゲーションといったSQL操作をS3上のファイルに対して実行させます。結果セットを作成する最終的なプロセスはRedshiftの中で実行され、ユーザに結果が返されます。 SpectrumはS3上に保存されたデータに直接アクセスできるということは、他のAWSサービス、例えばAmazon EMRやAmazon Athenaといったサービスを使ってそのデータを処理できるということです。また、頻繁にアクセスされるデータはRedshiftのローカルストレージに維持して、他はS3に置くであるとか、ディメンジョン表に加えてファクト表の直近データだけRedshiftに置き、他の古いデータはS3に置くといったハイブリッドな構成を実現することも可能です。より高いレベルでの並列実行を実現するために、複数のRedshiftクラスターを用意してS3上の同じデータを参照させるということも可能になります。 SpectrumはCSV/TSV、Parquet、SequenceFile、RCFileといったオープンなフォーマットをサポートします。ファイルはGzipかSnappyで圧縮しておくことが可能です。この他のフォーマットや圧縮アルゴリズムについては、今後サポートすることを計画しています。 Spectrum イン・アクション サンプルデータセットを使って、クエリーを実行することでSpectrumを試してみましょう！ まずExternal SchemaとExternal Databaseを作成するところから始めます:（訳注：External Databaseはこの後で定義するExternal Tableの定義を格納しておくためのデータベースです。External SchemaはIAMロールの情報を保持し、SpectrumはそのIAM権限でS3上にアクセスします） そして、External Table (外部表）をデータベースの中に定義します: このExternal Tableで定義したデータの行数を得るために、簡単なクエリーを実行してみましょう(61億行): 最後に全ての列を使ったクエリーを実行します: ご覧いただいたように、Spectrumは60億行のデータ全体をスキャンする必要がある演算を4分と少々で実行できています。クラスターのパフォーマンスを確認すると、CPUパワーはまだ十分な余裕があり、同様のクエリーを多数並列実行することが可能であることが見て取れます: 本日からご利用可能です！ Amazon Redshift Spectrumは、本日、今からご利用可能です！ Spectrumの費用はクエリーによってS3から読み取られたデータサイズによって決まり、1TBあたり$5です（データを圧縮したり、カラムナフォーマットでデータを保存することで費用を節約することが可能です）。Redshiftのクラスターの稼動費用やS3の保存費用は通常通り必要になりますが、Spectrumを使ったクエリーを実行しない限りはSpectrumの費用は発生しません。 （訳注：Spectrumは各リージョンに順次展開されていき、展開後のメンテナンスウィンドウのタイミングでクラスターにパッチが適用されます。パッチ1.0.1293以降のRedshiftクラスターであればSpectrumが使用可能になっています。本稿執筆時点では東京リージョンにはまだ展開されていませんでしたが、例えばバージニア北部リージョン等にはすでに展開されています。Spectrumの使い方についてはこちらのドキュメントを参照してください） – Jeff; 翻訳：下佐粉　昭（@simosako）

“信頼するが、確認する” – ロナルド・レーガン米国大統領、1987 このコメントで、レーガン大統領は、核軍縮条約の哲学について、ロシアの諺を引用しました。DevOpsにも同じ考え方が当てはまります！   Amazon ElastiCache for Redisは、自動化されたフェイルオーバとリカバリを備え、高可用性を提供しています。ElastiCacheクラスタを作成したければ、 Redis Cluster モードを使用し、クラスタ内のシャード数を設定します。各シャードには、1つのプライマリノード（読み取りと書き込み用）と0〜5つのレプリカノード（読み取りとフェールオーバー保護用）があります。1つのクラスタは、レプリカがゼロ（1ノード）のシャードと同じくらい小さくても、5つのシャード（5つのレプリカ（合計90ノード））を持つことができます。   AWSでは障害が頻繁に発生することはありませんが、いずれのマシンでも障害は発生します。レプリカノードに障害が発生すると、障害が検出され、数分でノードが置き換えられます。   Redis Cluster では、プライマリノードに問題が起きた時に、Redis Cluster は障害を検知しレプリカノードを新しいシャードのプライマリとして昇格させます。このプロセスは大体30秒程で実施されます。問題の起きたノードは入れ替えられ、クラスタのレプリカノードとして復帰します。Redis ClusterとElstiCacheを、エンジンとして Redis 3.2.4 と Cluster モードを有効にすることによって使うことができます。   これを信じてください…しかし検証するべきです。   ElastiCacheのテストフェイルオーバのおかげで検証は簡単です。マネジメントコンソールかAWS CLIを使用し、ElasiCache クラスタのいずれかのノード障害をシミュレートする事ができます、そして、どのようなプロセスで貴方のアプリケーションが動くのかも見ることができます。マルチシャード、もしくはシングルシャードの環境でもテストは可能です。さらに古いRedis 2.8の環境でもテストは可能です。 コンソールまたはAWS CLIを使用して、ElastiCacheクラスタ内の任意のノードの障害をシミュレートし、自分のアプリケーションでフェールオーバープロセスがどのように機能するかを確認できます。マルチシャード環境とシングルシャード環境、さらに古いRedis 2.8ブランチ環境でもフェールオーバーをテストできます。コンソールでこれを行うには、クラスタとシャードを選択してノードビューを表示し、次にフェールオーバープライマリを選択します。マネジメントコンソールでテストを行う際には、クラスタとシャードを選択してNode Viewを確認し、次にFailover primaryを選択します。   使用には注意してください。どのようなクラスタでも同じように動きます。なぜならどのクラスタも開発環境、テスト、本番かをAWSが知るすべが無いためです。その本番のクラスタで実行しても良い事が確信していない限りは本番ノードでは障害を発生させないでください。   自動フェイルオーバのテストを試してみてください！   翻訳は桑野が担当しました。原文はこちら。

Anurag GuptaはAmazon Auroraを含む彼がデザインに参加した、いくつかのAWSデータベースサービスに携わっています。 Under the Hoodシリーズでは、Auroraを支える技術や設計について説明します。 Amazon Auroraはオープンソースデータベースのシンプルさとコスト効率とハイエンドなコマーシャルデータベースの可用性と性能を兼ね備えたMySQL互換のデータベースです。この投稿では、Amazon Auroraが一般的な、完了までMySQLでは数時間かかるようなDDL文をほぼ即座に実行出来る仕組みを見ていこうと思います。   Fast DDLとは？なぜ考慮するのか アプリケーションを変更すると、それに付随するデータベースのスキーマを変更する必要があるケースがあります。クエリのワークロードが変わると、インデックスの追加や削除を行う必要があります。データのフォーマットが変更になると、既存のカラムのデータタイプを変更する必要があります。そして、このような変更は頻繁に起こりえます。Ruby on Railsアプリケーションをサポートする一部のDBAは、週に数十回スキーマを変更すると話しています。 多くのMySQLのDBAはご存知のように、このようなスキーマの変更はプロダクションシステムの中断が発生する可能性があります。変更に時間がかかるからです。場合によっては、完了まで数時間から数日かかることもあります。システムのリソースも奪われるため、アプリケーションのスループットも低下します。また、長時間のオペレーションは長時間のクラッシュリカバリが発生する可能性があります。DDL操作の一部は書き込みロックが必要なため、アプリケーションの一部が使用できなくなります。加えて一時的なスペースを多く必要とする可能性があり、小規模のインスタンスではディスクが不足する可能性もあります。 私たちはこのような点を取り除けるように改善を行っており、良く見る一般的なDDL操作(nullableカラムをテーブルの最後に追加)から改善を始めました。   なぜ既存の方法では問題が起こるのか？ MySQLがどの様にnullableカラムをテーブルの最後に追加する実装になっているか見ていきましょう。 MySQLは以下のような処理を行っています: データベースはトランザクションのprepareフェーズでオリジナルテーブルに対して排他ロックを取得します 変更後のスキーマで新しい空のテーブルを作成します 1行ずつコピーを行ない、インデックスをその後作成する。同時に実行されたデータ操作(DML)文は、一時ファイルに記録されます 再度、排他ロックを取得し一時ファイルから新しく作成したテーブルへDML文を適用します。適用すべき操作が多くある場合、この処理に時間を要します オリジナルテーブルをdropし、テーブルをリネームします これらの処理には多くのロックが必要になり、データのコピーやインデックスの作成にオーバヘッドが必要になります。そして、I/Oが多く発生し、一時領域も消費します。   もっと良い方法はないのでしょうか？ これについてはないと思うかもしれません。各行のデータ形式は変更する必要があります。しかし、この変更をテーブル上で実行されている他のDML(および関連するI/O)操作の上にのせることで、多くのことが実行できます。 完全なアプローチは、ブログポストではやや複雑すぎるので、ここでは簡単に説明します。 Auroraでは、DDLをユーザが実行すると データベースがINFORMATION_SCHEMAのシステムテーブルを新しいスキーマで更新します。加えて、各操作に対してタイムスタンプを付与し変更をリードレプリカに伝搬します。古いスキーマ情報は新しいシステムテーブル(Schema Version Table)内に格納されます 同期的に行う操作はこれだけで完了です。 そして、その後のDML文は、影響のうけるデータページがスキーマの変更を待っている状態か監視します。この操作は、各ページのlog sequence number (LSN)タイムスタンプとスキーマ変更のLSNタイムスタンプを比べるだけで簡単に行なえます。必要に応じて、DML文を適用する前に新しいスキーマにページを更新します。この操作は、redo-undoレコードページの更新と同じ更新プロセスで実行されます。そして、I/Oはユーザの実行するクエリと同様に扱います。 DML操作では、ページ分割が発生する可能性があるため、ページの変更に注意する必要があります。変更はAuroraのレプリカノードでも同様に扱う必要があります。そして、リードレプリカではどのデータへの変更も許可されていません。SELECT文のために、MySQLに戻されるメモリ上のバッファ内のイメージ変更します。この方法では、ストレージ内で新旧のスキーマが混在していたとしても常に最新のスキーマを参照出来ます。 もし、皆さんがAuroraがどのようにストレージからの読み込みとログの適用を行っているかご存知の場合、このアプローチが似ていると感じると思います。しかし、このアプローチではredo logのセグメントではなく、変更を記録するためにテーブルを使用します。 パフォーマンス比較は以下のようになっています。Auroraは Schema Version Tableを変更するために一定の時間で処理が完了しているのがおわかりになると思います。しかし、MySQLではテーブルサイズにほぼ比例して線形に処理時間が増加しています。 明らかに私達が改善すべき多くのDDL文があります。しかし、殆どの物は同様のアプローチで対処可能と考えています。 このことは重要です。たとえデータベースが通常の可用性で稼働していても、これらの長い操作ではアプリケーションへ影響が発生します。それらを並列、バックグラウンド、非同期処理に移すことで違いが出てきます。 質問やフィードバックはありますか？aurora-pm@amazon.comへ是非お寄せ下さい。皆さんの考えや提案を私たちは非常に大切にしています。 注: こちらの機能は2017年4月6日現在Lab modeにてご提供しております。 翻訳は星野が担当しました。原文はこちら。

今回は、Amazon Redshift シニアプロダクトマネージャーの Maor Kleider からのゲスト投稿です。 -Ana Amazon Redshift は、ペタバイト規模の高速なフルマネージド型データウェアハウスサービスであり、すべてのデータをシンプルにコスト効率よく分析できます。多くのお客様 (Scholastic、King.com、Electronic Arts、TripAdvisor、Yelp など) は、Amazon Redshift に移行して機敏性を実現し、洞察が得られるまでにかかる時間を短縮して、同時にコストも大幅に削減しています。 列指向の圧縮は、Amazon Redshift の重要なテクノロジーです。このテクノロジーにより、ノードの効果的なストレージ容量を増やしてコストを削減し、SQL リクエストの処理に必要な I/O を削減してパフォーマンスを向上させることができます。I/O の効率を高めることは、データウェアハウスに非常に重要です。昨年、I/O の向上に伴ってクエリスループットは倍増しました。この度、Amazon Redshift に新しい圧縮の強化機能が追加されました。以下に、いくつかをご紹介します。 まず、Zstandard 圧縮アルゴリズムのサポートが追加されました。このアルゴリズムは、ビルド 1.0.1172 での高い圧縮率とスピードを適切なバランスに維持します。標準の TPC-DS、3 TB ベンチマークで raw データに適用した場合、Zstandard はディスク容量の 65% を節減します。Zstandard は幅広く適用できます。SMALLINT、INTEGER、BIGINT、DECIMAL、REAL、DOUBLE PRECISION、BOOLEAN、CHAR、VARCHAR、DATE、TIMESTAMP、および TIMESTAMPTZ のいずれのデータ型にも使用できます。 2 番目として、CREATE TABLE AS、CREATE TABLE、ALTER TABLE ADD COLUMN の各コマンドで作成されたテーブルに対する圧縮の自動化が強化されました。Amazon Redshift のビルド 1.0.1161 以降では、これらのコマンドで作成された列のデフォルト圧縮が自動的に選択されます。パフォーマンスを低下させずにディスク容量を節減できるような場合は、自動圧縮が行われます。ディスク容量は、最大 […]

Amazon Auroraの最近のアップデートを振り返ってみたいと思います。Amazon AuroraはMySQL互換のハイパフォーマンスなデータベースです(間もなくPostgreSQL互換のAuroraもリリース予定です)。 最近Auroraへ追加された機能は以下のとおりです クロスリージョンスナップショットコピー 暗号化されたデータベースのクロスリージョンレプリケーション 暗号化されたスナップショットのアカウント間の共有 US West (Northern California)リージョンのサポート T2.smallインスタンスサポート   クロスリージョンスナップショットコピー Amazon Auroraのスナップショット(自動・手動取得に関わらず)リージョン間でコピー出来るようになりました。スナップショットを選択し、Snapshot ActionsからCopy Snapshotを選択します。その後、リージョンを選択後、新しいスナップショットの名前を入力します。 この操作の中で、暗号化済みスナップショットも選択可能です。詳細はドキュメントをご覧ください。   暗号化されたデータベースのクロスリージョンレプリケーション Amazon Aurora DBを作成する際に暗号化オプションを設定出可能です。 数クリックで他のリージョンにリードレプリカを作成することが出来るようになりました。この機能を利用することで、マルチリージョン、ハイアベイラビリティなシステムが構築可能になりますし、ユーザに近い位置にデータを移動することも可能です。クロスリージョンリードレプリカを作成するには、既存のDBインスタンスを選択し、メニューからCreate Cross Region Read Replicaを選択するだけです。 その後、Network & Securityからリージョンを選択し、Createをクリックします。 レプリケーション先のリージョンには必ず2つ以上のアベイラビリティゾーンを含んだDB Subnet Groupが必要です。 このパワフルな新機能について詳細は、ドキュメントをご覧ください。   暗号化されたスナップショットのアカウント間の共有 Amazon Aurora DBインスタンスを作成する際に、定期的に自動でスナップショットを行う設定が可能です。この他にも、数クリックで任意のタイミングでスナップショットを作成することも可能です。 DBインスタンスが暗号化されている場合はスナップショットも暗号化されます。 AWS間で暗号化されたスナップショットを共有出来るようになりました。この機能を使うためには、DBインスタンスはdefault RDS keyではないマスターキーで暗号化されている必要があります。まず、スナップショットを選択し、Snapshot ActionsメニューからShare Snapshotを選択します。 そして、共有先のAWS Account IDを入力し(それぞれのアカウント毎にAddをクリックします)、Saveを選択します。 この他にも、スナップショットの暗号化で使用したキーも共有する必要があります。この機能の詳細はドキュメントをご覧ください。   US West (Northern […]