Category: Database*


Amazon Redshift Spectrum – S3のデータを直接クエリし、エクサバイトまでスケール可能

現在、数クリックでクラウド上にコンピュートリソースやストレージリソースを構築可能です。現在のチャレンジは、それらのリソースを活用して生のデータを出来る限り素早く、かつ効果的に活用可能な結果に変換することです。

Amazon Redshiftを活用することで、AWSのお客様はペタバイト級のデータウェアハウスを構築し、社内・社外の多様なデータソースからのデータを統合することが可能です。Redshiftは巨大な表に複雑なクエリ(複数の表をジョインする等)を実行することに最適化されているため、小売、在庫、ファイナンシャルデータといった膨大なデータを特別な苦労なく処理することができます。Redshiftにデータをロードした後は、Redshiftパートナーが提供するビジネスインテリジェンス(BI)ツールやエンタープライズレポーティングツールを活用することが可能です。

データウェアハウスを使い続ける上での1つの大きなチャレンジは、継続的に更新される、もしくは追加されるデータを速いペースでロードすることです。高速なクエリーパフォーマンスを提供するために、データをロードするというフェーズでは圧縮、データの正規化や最適化といった作業が行われます。これらの作業自体は自動化、スケールさせることは可能ですが、複雑なロード作業はデータウェアハウス維持にオーバーヘッドと複雑さを追加し、効果的な活用方法を得ることを阻害する場合もあります。

データフォーマットについては別の興味深いチャレンジが存在します。いくつかのアプリケーションはデータウェアハウスの外でデータ元々のフォーマットのままで処理を行っています。他のアプリケーションはデータウェアハウスにデータを取り込み、クエリーを実行しています。この利用方法だと同じデータが2つの場所に存在することになりますのでストレージを効率的に使えていないことになりますし、ロードがタイムリーに行われていない環境では、それぞれのアプリケーションで異なった結果が返る可能性があります。

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 EMRAmazon Athenaといったサービスを使ってそのデータを処理できるということです。また、頻繁にアクセスされるデータはRedshiftのローカルストレージに維持して、他はS3に置くであるとか、ディメンジョン表に加えてファクト表の直近データだけRedshiftに置き、他の古いデータはS3に置くといったハイブリッドな構成を実現することも可能です。より高いレベルでの並列実行を実現するために、複数のRedshiftクラスターを用意してS3上の同じデータを参照させるということも可能になります。

SpectrumはCSV/TSVParquetSequenceFileRCFileといったオープンなフォーマットをサポートします。ファイルはGzipSnappyで圧縮しておくことが可能です。この他のフォーマットや圧縮アルゴリズムについては、今後サポートすることを計画しています。

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

 

Amazon ElastiCache for Redis の リードレプリカの自動フェイルオーバのテスト

“信頼するが、確認する”

– ロナルド・レーガン米国大統領、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が知るすべが無いためです。その本番のクラスタで実行しても良い事が確信していない限りは本番ノードでは障害を発生させないでください。

 

自動フェイルオーバのテストを試してみてください!

 

翻訳は桑野が担当しました。原文はこちら

Amazon Aurora: Fast DDLの詳細

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は以下のような処理を行っています:

  1. データベースはトランザクションのprepareフェーズでオリジナルテーブルに対して排他ロックを取得します
  2. 変更後のスキーマで新しい空のテーブルを作成します
  3. 1行ずつコピーを行ない、インデックスをその後作成する。同時に実行されたデータ操作(DML)文は、一時ファイルに記録されます
  4. 再度、排他ロックを取得し一時ファイルから新しく作成したテーブルへDML文を適用します。適用すべき操作が多くある場合、この処理に時間を要します
  5. オリジナルテーブルをdropし、テーブルをリネームします

これらの処理には多くのロックが必要になり、データのコピーやインデックスの作成にオーバヘッドが必要になります。そして、I/Oが多く発生し、一時領域も消費します。

 

もっと良い方法はないのでしょうか?

これについてはないと思うかもしれません。各行のデータ形式は変更する必要があります。しかし、この変更をテーブル上で実行されている他のDML(および関連するI/O)操作の上にのせることで、多くのことが実行できます。

完全なアプローチは、ブログポストではやや複雑すぎるので、ここでは簡単に説明します。

Auroraでは、DDLをユーザが実行すると

  1. データベースが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ではテーブルサイズにほぼ比例して線形に処理時間が増加しています。

TableComparison

明らかに私達が改善すべき多くのDDL文があります。しかし、殆どの物は同様のアプローチで対処可能と考えています。

このことは重要です。たとえデータベースが通常の可用性で稼働していても、これらの長い操作ではアプリケーションへ影響が発生します。それらを並列、バックグラウンド、非同期処理に移すことで違いが出てきます。

質問やフィードバックはありますか?aurora-pm@amazon.comへ是非お寄せ下さい。皆さんの考えや提案を私たちは非常に大切にしています。

注: こちらの機能は2017年4月6日現在Lab modeにてご提供しております。

翻訳は星野が担当しました。原文はこちら

Amazon Redshift のデータ圧縮の強化で圧縮率が最大 4 倍に

今回は、Amazon Redshift シニアプロダクトマネージャーの Maor Kleider からのゲスト投稿です。

-Ana


Amazon Redshift は、ペタバイト規模の高速なフルマネージド型データウェアハウスサービスであり、すべてのデータをシンプルにコスト効率よく分析できます。多くのお客様 (ScholasticKing.comElectronic ArtsTripAdvisorYelp など) は、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 以降では、これらのコマンドで作成された列のデフォルト圧縮が自動的に選択されます。パフォーマンスを低下させずにディスク容量を節減できるような場合は、自動圧縮が行われます。ディスク容量は、最大 40% 削減されます。

3 番目に、引き続き内部オンディスクデータ構造が最適化されています。プレビュー版をご利用のお客様は、この機能改善により、ディスク容量の使用量を平均して 7% 削減しました。この機能はビルド 1.0.1271 から提供されています。

最後に、ディスク容量の削減量を推定するための ANALYZE COMPRESSION コマンドが強化されました。これまで以上にデータを圧縮してパフォーマンスを向上させる機会が増えました。データは、バックグラウンドでサンプリングされて、最も効果的な圧縮が推奨されます。お客様の判断で、推奨された暗号化を使用するか、別の適切な暗号化を指定できます。

「最近追加されたすべての圧縮機能を利用するまでは、当社の最大のテーブルは 7 TB を超えていました。それが今は 4.85 TB までになり、ディスク容量は 30.7% も節減されました。これにより、ディスク容量は合計で 4 分の 1 に削減でき、非圧縮データに基づく有効原価は 250 USD/TB/年未満になります。Amazon Redshift で分析できるデータ量が増え、これまで以上にクエリのパフォーマンスが向上しました」Chuong Do (Coursera 社の Director of Analytics)

無論、実際にクラスターに適用した場合の効果は、ワークロードとデータに応じて異なります。以上の強化機能を組み合わせた場合、データの圧縮は、従来の通常の 3 分の 1 に対して、最大 4 分の 1 になると思われます。

Amazon Redshift データウェアハウスのコストはわずか 1,000 USD/テラバイト/年であるとお聞きになったことがあるかもしれません。これは圧縮後のデータに基づくコストである点にご注意ください。AWS では、データは圧縮されて保存されます。AWS 以外のベンダーではそうでない場合があります。多くのベンダーはデータを圧縮しますが、コストは非圧縮データのテラバイトに基づいています。嘆かわしいことです。データを圧縮しても非圧縮データとして課金するのは法外と言わざるを得ません。

-Maor Kleider

Amazon Auroraアップデート: クロスリージョン・クロスアカウントサポートの拡張、T2.Small DBインスタンス、リージョンの追加

Amazon Auroraの最近のアップデートを振り返ってみたいと思います。Amazon AuroraはMySQL互換のハイパフォーマンスなデータベースです(間もなくPostgreSQL互換のAuroraもリリース予定です)。Amazon Auroraの紹介は、【AWS発表】Amazon Auroraをご利用頂けるようになりました!や【AWS発表】Amazon Aurora – Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!!をご覧ください。

最近Auroraへ追加された機能は以下のとおりです

  • クロスリージョンスナップショットコピー
  • 暗号化されたデータベースのクロスリージョンレプリケーション
  • 暗号化されたスナップショットのアカウント間の共有
  • US West (Northern California)リージョンのサポート
  • T2.smallインスタンスサポート

 

クロスリージョンスナップショットコピー

Amazon Auroraのスナップショット(自動・手動取得に関わらず)リージョン間でコピー出来るようになりました。スナップショットを選択し、Snapshot ActionsからCopy Snapshotを選択します。その後、リージョンを選択後、新しいスナップショットの名前を入力します。

au_copy_snap

この操作の中で、暗号化済みスナップショットも選択可能です。詳細はドキュメントをご覧ください。

 

暗号化されたデータベースのクロスリージョンレプリケーション

Amazon Aurora DBを作成する際に暗号化オプションを設定出可能です。

au_enable_encr

数クリックで他のリージョンにリードレプリカを作成することが出来るようになりました。この機能を利用することで、マルチリージョン、ハイアベイラビリティなシステムが構築可能になりますし、ユーザに近い位置にデータを移動することも可能です。クロスリージョンリードレプリカを作成するには、既存のDBインスタンスを選択し、メニューからCreate Cross Region Read Replicaを選択するだけです。

au_ccrrr_menu

その後、Network & Securityからリージョンを選択し、Createをクリックします。

au_pick_dest_reg

レプリケーション先のリージョンには必ず2つ以上のアベイラビリティゾーンを含んだDB Subnet Groupが必要です。

このパワフルな新機能について詳細は、ドキュメントをご覧ください。

 

暗号化されたスナップショットのアカウント間の共有

Amazon Aurora DBインスタンスを作成する際に、定期的に自動でスナップショットを行う設定が可能です。この他にも、数クリックで任意のタイミングでスナップショットを作成することも可能です。

au_take_snapshot

DBインスタンスが暗号化されている場合はスナップショットも暗号化されます。

AWS間で暗号化されたスナップショットを共有出来るようになりました。この機能を使うためには、DBインスタンスはdefault RDS keyではないマスターキーで暗号化されている必要があります。まず、スナップショットを選択し、Snapshot ActionsメニューからShare Snapshotを選択します。

au_share_snap_menu

そして、共有先のAWS Account IDを入力し(それぞれのアカウント毎にAddをクリックします)、Saveを選択します。

au_share_snap

この他にも、スナップショットの暗号化で使用したキーも共有する必要があります。この機能の詳細はドキュメントをご覧ください。

 

US West (Northern California)リージョンのサポート

Amazon Aurora DBをUS West (Northern California) リージョンでご利用頂けるようになりました。Auroraをご利用頂けるリージョンのリストは以下の通りです。

  • US East (Northern Virginia)
  • US East (Ohio)
  • US West (Oregon)
  • US West (Northern California)
  • Canada (Central)
  • EU (Ireland)
  • EU (London)
  • Asia Pacific (Tokyo)
  • Asia Pacific (Sydney)
  • Asia Pacific (Seoul)
  • Asia Pacific (Mumbai)

それぞれのリージョンでの価格については、こちらをご覧ください。

 

T2.smallインスタンスサポート

t2.small DBインスタンスをご利用頂けるようになりました。

au_launch

これらの経済的なインスタンスは、開発環境とテスト環境、および負荷の少ないプロダクションワークロードに最適です。また、Amazon Auroraの経験を積むこともできます。これらのインスタンス(昨年11月にリリースしたt2.mediumを含む6つのインスタンスと同様)は、Auroraが利用できるすべてのAWSリージョンで利用可能です。

t2.small DBインスタンスのオンデマンド価格はUS East (Northern Virginia)リージョンでは、1時間あたり$0.041からご利用いただけ、3年のAll Upfrontリザーブドインスタンスをご利用頂くと、1時間あたり$0.018となります。さらに詳細な価格についてはAmazon Auroraの料金ページをご覧ください。

Jeff; (翻訳は星野が担当しました。原文はこちら)

発表: Amazon ElastiCache で Redis バックアップおよび復元を実現、クラスターのサイズ変更も可能に

インメモリキャッシュは、アプリケーション設計時またはソリューション構築時の大規模なパフォーマンス強化やコスト削減と同等に扱われます。ここで、サービスが 1 つのみの場合は、スケーリングする機能を強化しながら、継続的にクラウド内のインメモリキャッシュをより簡単にデプロイおよび活用できるようにします。冗談はさておき、この優れた機能を実現するクラウドサービスとは、もちろん Amazon ElastiCache です。Amazon ElastiCache は、パフォーマンスの高いインメモリデータストアまたはキャッシュをクラウドで実現する AWS マネージドサービスです。I/O 集約型または計算量の多いデータの低レイテンシー、安全性、アクセスを実現するための分散環境を作成、スケール、管理する簡単な方法を提供します。また、ElastiCache では、Amazon CloudWatch を通じて、キャッシュシステムのノードの主要なパフォーマンスメトリクスの可視性を強化すると同時に、障害が発生したノードを検出して置換することで、インメモリデータ構造サーバやキャッシュのインフラストラクチャを管理するオーバーヘッドを抑えることができます。この優れたサービスで、Redis バックアップおよび復元とクラスターのサイズ変更を実現しました。

Amazon ElastiCache に精通している方であれば、ElastiCache で次の 2 つのインメモリキー値エンジンがサポートされていることをご存じでしょう。

  • Memcached: パフォーマンスの高いオープンソースの分散メモリオブジェクトキャッシュシステム。データベースの負荷を軽減して動的なウェブアプリケーションを高速化することを当初の目的として 2003 年に開発されました。
  • Redis: オープンソースのインメモリデータ構造ストア。Redis クラスターを使用して、組み込みレプリケーション、アトミックオペレーションサポート、さまざまなレベルのオンディスクの永続性、高可用性を実現しながら、キャッシュ、メッセージング、データベースのブローカーとして開発され、2009 年に発表されました。

2016 年 10 月、Redis 3.2.4 使用の Redis クラスターがサポートされるようになり、ElastiCache Redis のユーザーは Redis クラスターを活用できるだけでなく、次のことが行えるようになりました。

  • クラスターレベルのバックアップの作成
  • バックアップ内のクラスターのシャード単位でのスナップショットの生成
  • 最大 15 シャードの間で 3.5TiB のデータのワークロードのスケール

ElastiCache や関連する機能を活用した Redis の使用については、「Amazon ElastiCache for Redis」の製品ページを参照してください。Redis バックアップおよび復元とクラスターのサイズ変更機能が発表され、ElastiCache は、マネージド型の Redis クラスター経験に確実に移行できるように Redis のサポートをますます強化しています。この機能には、ElastiCache と Redis ユーザーのどちらにとっても、次のような利点があります。

  • シャード数やスロット配置が異なる Redis クラスターにバックアップを復元可能
  • ユーザーによる Redis ワークロードのサイズ変更が可能
  • シャードされた Redis クラスターを作成する入力として、Redis データベースファイル (RDB) スナップショットを使用可能
  • シャードされた Redis クラスターの作成に必要なデータ入力として、EC2 実装 (Redis クラスターと単一シャード Redis の両方) で Redis のスナップショットを使用可能

これらのタスクを実現するために、ElastiCache は、バックアップの各スナップショット間で Redis キー空間を解析し、要求されたシャードやハッシュスロットの数に応じて、新しいクラスター内にキーを再分散します。RDB スナップショットを作成して、S3 に格納し、ElastiCache で希望のシャードおよびスナップファイルの数を指定します。Redis データストアを Redis クラスターに格納する面倒な作業も ElastiCache で行うことができます。中には、ElastiCache の「Redis バックアップおよび復元とクラスターのサイズ変更」機能を本当に簡単に活用できるのか、と考える方がいるかもしれません。検証している時間はありません。AWS マネジメントコンソールに移動し、ElastiCache を用いて外部の RDB スナップショットを新しいクラスターで復元し、新たにリリースされた拡張を使用します。まず、AWS マネジメントコンソールで、「Amazon S3 コンソール」に移動します。ElastiCache への外部の Redis スナップショットの復元をテストするために、AWS の一部ピアから受け取った Redis .rdb スナップショットファイルがいくつかあります。ElastiCache Redis クラスターの入力としてスナップショットにアクセスできるように、これらのファイルを Amazon S3 に配置します。

S3 コンソールで、テストおよび開発の目的で作成した S3 バケット、aws-blog-tew-posts に移動します。提供された .rdb スナップショットファイルをこの S3 バケットにアップロードします。

S3 バケットの名前は DNS 標準に準拠しなければなりません。DNS 標準に準拠するために、バケット名は 3 文字以上で、小文字の英文字、数字、ハイフンのみを使用し、先頭と末尾の文字は小文字の英文字または数字でなければなりません。当たり前かもしれませんが、バケット名は IP アドレスフォーマットにすることはできません。S3 バケットの制約の詳細については、「こちら」を参照してください。.rdb ファイルが正常に aws-blog-tew-posts バケットにアップロードされたら、これらのバックアップファイルへの S3 パスをメモします。上記のファイルの場合、パスは、aws-blog-tew-posts/dump_1.rdb または aws-blog-tew-posts/dump_10.rdb になります。ファイルをフォルダに配置する場合は、フォルダ名をこのパスに含む必要があります。例: thebucketname/thefoldername/thefilename

ElastiCache からこれらのファイルにアクセスするには、該当サービスに各ファイルの読み取り権限があることを確認します。アクセス権限を付与するには、被付与者を対象リージョンの正規化 ID として割り当てることで各 .rdb ファイルの読み取り権限をアップデートしてから、開く/ダウンロードのアクセス権限をこのユーザーに付与します。中国 (北京)、AWS GovCloud (米国) を除くすべてのリージョンの正規化 ID は次のとおりです。

540804c33a284a299d2547575ce1010f2312ef3da9b3a053c8bc45bf233e4353

[Save] ボタンをクリックすると、ElastiCache Redis クラスターの入力としてこれらのファイルを使用するように設定されます。

次に、ElastiCache コンソールに移動します。ここで、新たに ElastiCache Redis クラスターを作成し、このクラスターを S3 バケット内のファイルに配置された RDB スナップショットのいずれかのデータに追加します。dump_1.rdb スナップショットファイルを選択して、この新しいクラスターを追加するデータ入力として使用します。今年 10 月に Redis Cluster 3.2.4 のサポートによって追加された ElastiCache Redis 機能や、クラスターのサイズ変更に対応した新しいバックアップおよび復元機能について説明するため、Redis クラスターを新たに作成し、クラスターモードが有効であることを確認します。この時点で、Redis (クラスターモードが有効) クラスターを使用して作成されたバックアップから Redis (クラスターモードが無効) クラスターに復元することはできません。まず、ElastiCache コンソールダッシュボードの [今すぐ始める] ボタン、またはコンソールビューの [作成] ボタンをクリックします。

[Amazon ElastiCache クラスターの作成] ダイアログウィンドウで、キャッシュの [Redis] を選択し、[有効なクラスターモード (スケールアウト)] のチェックボックスがオンになっていることを確認します。新しいクラスターの名前は、tew-rediscluster となり、クラスターモードを有効にしているため、ElastiCache Redis のエンジンバージョンは、3.2.4 です。このクラスターの Redis ポートは、デフォルトの 6379 のままにしておきます。

ElastiCache 拡張の Redis バックアップおよび復元機能の主な利点は、元々バックファイルで使用されていた数と異なるシャード数で新しいクラスターを構築することができるクラスターのサイズ変更機能です。新しい Redis クラスターを構成するために、唯一の RDB スナップショットファイルである dump_1.rdb を使用します。このファイルは、シャードが 1 つのみの小さな Redis インスタンスバックアップです。ただし、新しい tew-rediscluster を作成する際、1 つのシャードに 2 つのレプリカを含む 3 つのシャードを選択しました。さらに、RDB スナップショットより、元のインスタンスとは異なるサイズの新しいクラスターのノードタイプを指定することもできます。前述の通り、dump_1.rdb は、以下に示した tew-rediscluster 向けに選択したノードタイプより大幅に小さい Redis インスタンスのバックアップです。

他にも、ElastiCache Redis クラスターを作成するために必要なオプションやデータ入力がありますが、このブログ投稿には記載していません。ただし、ElastiCache Redis クラスターの作成に必要な各ステップを行う場合は、『クラスターを起動する』の「AWS ElastiCache の開始」のドキュメントで詳細を確認してください。ElastiCache Redis クラスターの作成に必要な情報をすべて入力したら、ElastiCache で S3 バケットのファイル場所を指定して、クラスターに .rdb ファイルを追加する方法を指定します。作成ダイアログの「クラスターへのデータのインポート」セクションにおいて、「シードする RDB ファイルの S3 の場所」テキストボックスdump_1.rdb への S3 パスを入力します。S3 ファイルパスの命名法は、Bucket/Folder/ObjectName が適用されるため、S3 内の RDB ファイルへのパスとして、aws-blog-tew-posts/dump_1.rdb を入力します。最後に、[作成] ボタンをクリックします。

これで完了です。ElastiCache で新しい Redis クラスターを作成できるようになりました。間もなくすると、新しい Amazon ElastiCache Redis クラスターが ElastiCache コンソールで選択できるようになります。外部の RDB スナップショットファイルより復元されたデータでこのクラスターを作成することができました。

外部の RDB スナップショットを用いて ElastiCache Redis クラスターを作成する方法を説明しましたが、既存の ElastiCache Redis クラスターのバックアップを使用してバックアップを作成または復元することもできます。新たにリリースされた本機能の詳細をお知りになりたい場合は、『Amazon ElastiCache User Guide』の「バックアップからの復元とクラスターのサイズ変更」を参照してください。Amazon ElastiCache を使用したアプリケーションのパフォーマンス強化の詳細については、「AWS Amazon ElastiCache」の製品の詳細、リソース、お客様の声を参照してください。

Tara

Amazon RDS for MySQL バージョン: 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23 リタイアメントのお知らせ

Amazon RDS for MySQLにおいて、MySQLのマイナーバージョン 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23 のサポートを2017年7月19日に終了致します。これらのバージョンはAmazon RDSで2014年10月から2015年6月にかけてサポートされました。そして、新機能やセキュリティ・安定性向上を含んだバージョンに更新されてきました。

現在これらのバージョンをご利用の場合、現在サポートされているMySQLの最新のマイナーバージョン(2017/3/8現在: 5.6.34)にアップグレードを行うことを推奨致します。メジャーバージョンアップグレードと異なり、マイナーバージョンアップグレードはそれ以前データベースエンジンのマイナーバージョンと後方互換性を持っています。

2017年4月5日Auto Minor Version UpgradeがYesに設定されているDBインスタンスに対して、自動アップグレードを設定致します。アップグレードはこの日以降の通常のメンテナンスウインドウ内で順次実施されます。

2017年7月5日以降に起動しているMySQL 5.6.19a, 5.6.19b, 5.6.21, 5.6.21b, 5.6.22, 5.6.23バージョンのRDS DBインスタンスは、Auto Minor Version Upgradeの設定に関わらず自動的に最新のマイナーバージョンに、各インスタンスに設定されているにメンテナンスウインドウ内でアップグレードが行われます。

2017年7月19日以降に起動している該当バージョンのRDS MySQLインスタンスは、メンテナンスウインドウに関わらず即座にアップグレードが実施されます。

RDSでのMySQLのマイナーバージョンアップグレードについては、こちらをご覧ください。

不明点などがありましたら、AWS サポートチームへコミュニティフォーラムかサポートセンター経由でご連絡下さい。

今回のアップグレードは、2017年4月5日到来前にアップグレード対象バージョン以上のマイナーバージョンもしくは、メジャーバージョンにアップグレードして頂くことで回避可能です。そのため、テスト環境などでテストを行っていただき、自動適用が開始される前に手動でアップグレードすることをお勧め致します。

 

原文はこちらをご覧ください。

 

Amazon Aurora: 暗号化されたスナップショット・データベースに対する新機能

本日Amazon Auroraの新機能を2つリリース致しました。

暗号化済みデータベースのクロスリージョンサポート

暗号化済みのデータベースでAWSリージョンをまたいだレプリケーションがサポートされました。クロスリージョンレプリケーションを利用することで、ユーザに近い場所でリードオペレーションを実行することが可能になったり、ディザスターリカバリー環境を簡単に構築出来ます。また、リージョンをまたいだデータベースの移行も容易に行なえます。

また、暗号化されたスナップショットをAWSリージョン間でコピー可能になりました。開発チームとテストチームが様々な地域に分散していたとしても、本番データベースの最新のコピーを安全に共有することによって、グローバルな開発プロセスを構築できます。また、遠隔地にスナップショットを安全に保管することで、ディザスターリカバリー戦略を強化することも可能です。

詳細は、クロスリージョンレプリケーションクロスリージョンスナップショットコピーのドキュメントをご覧ください。

 

AWSアカウント間で暗号化済みスナップショット共有をサポート

AWSアカウント間で暗号化済みスナップショットの共有が可能になりました。暗号化キーを共有しているアカウントを分離するためにAuroraのセキュリティモデルを拡張出来ます。他のアカウントの所有者は、スナップショットをコピーしたり、スナップショットからデータベースインスタンスを復元することができます。

詳細なドキュメントはこちらをご覧ください。

Amazon Auroraは、フルマネージド、高可用性、コストパフォーマンスのよいリレーショナルデータベースです。MySQLと互換性があるためアプリケーションコードの変更なしに移行が行なえます。また、こちらのツールを利用することでダウンタイムを最小限に移行を行うことも可能です。

翻訳は星野が担当しました。原文は、Amazon Aurora Announces Encryption Support for Globally Distributed Database DeploymentsAmazon Aurora Supports Cross-Account Encrypted Snapshot Sharing

 

 

 

 

 

 

AWS Database Migration Service – 現在も増え続けているこれまでの移行数 20,000 件

AWS Database Migration Service について初めてブログ (AWS Database Migration Service) を投稿したのは 1 年ほど前のことです。その時点で AWS ユーザー 1,000 人がすでに AWS への移行の一部として同サービスを使用していました。簡単に説明すると、AWS Database Migration Serviceスキーマ変換ツール (SCT) は、AWS のお客様が高価な独自のデータベースやデータウェアハウスから、リレーショナルデータをよりコスト効率の良い Amazon AuroraAmazon Redshift、MySQL、MariaDB、PostgreSQL といったクラウドベースのデータベースやデータウェアハウスに、ダウンタイムを最低限に抑えた状態で移行できるようにサポートします。ユーザーの皆様からは、その柔軟性とコスト効率に優れた点において良い評価を頂いています。たとえば Amazon Aurora に移行すると、商用データベースに掛かる 10 分の 1 のコストで MySQL と PostgreSQL との互換性を持つデータベースにアクセスすることができます。Expedia、Thomas Publishing、Pega、Veoci といった企業による使用事例は AWS Database Migration Services Customer Testimonials でご覧いただけます。

独自の移行数 20,000 件
AWS のお客様は、これまでに AWS Database Migration Service を使用して 20,000 件もの独自のデータベースを AWS に移行しており、現在もその数は上昇する一方です (2016 年 9 月の移行数は 10,000 件を記録)。昨年はいくつもの新機能を DMS と SCT に追加しました。概要は次をご覧ください。

詳細
移行を始めるには、まず最近のオンラインセミナーなどを参考にして詳細情報をご覧ください。シャードからスケールアップへの移行 – 複数の独立した要素にわたりデータベースをシャードし、それぞれを別のホストで実行するなどして、リレーショナルワークロードに対応できるようにスケールアウトする方法を選択したお客様もいらっしゃいます。そうしたお客様は、移行の一環として 2 つ以上のシャードを 1 つの Aurora インスタンスにまとめ、複雑さを軽減し信頼性を高めながらコスト節約を実現しています。この方法を行うには、こちらのブログ記事オンラインセミナーの録画プレゼンテーションをご覧ください。Oracle や SQL Server から Aurora への移行 – その他のお客様は Oracle や SQL Server といった商用データベースから Aurora に移行しています。この方法を行うには、こちらのプレゼンテーションオンラインセミナーの録画を併せてご覧ください。AWS Database Blog ではその他にも多数の役に立つブログを公開しています。

  • シャーディングしたシステムを Aurora で統合しリソース消費を低減 -「シャーディングしたシステムを 1 つの Aurora インスタンスに統合したり、Aurora で実行しているシャード数を減らすことでコストを節約できることがあります。このブログでは、まさにその方法を説明しています。」
  • Oracle データベースを Amazon Aurora に移行 – 「このブログでは AWS スキーマ変換ツール (AWS SCT) と AWS Database Migration Service (AWS DMS) を使用して、商用データベースを Amazon Aurora に移行しやすくするための概要を提供しています。このブログ記事では Oracle から MySQL との互換性がある Amazon Aurora への移行に焦点を当てました。」
  • AWS スキーマ変換ツールと AWS Database Migration Service を使用しているクロスエンジンデータベースレプリケーション -「AWS SCT はソースデータベーススキーマを自動変換することで異種データベースを移行しやすくします。さらに、AWS SCT はビューや関数など大方のカスタムコードをターゲットデータベースと互換性のある形式に変換します。」
  • データベースの移行—移行前に知っておくべきことは? -「おめでとうございます! データベースをクラウドに移行するように、上司や CIO を説得できたようですね。もしかすると、ご自身が上司または CIO なのかもしれませんが、どちらにせよバンドワゴン効果をぜひご活用ください。率先してデータベースを移行するユーザーは稀です。ここでのポイントは、ご利用されているアプリケーションを新しい環境やプラットフォーム、テクノロジー (アプリケーションの更新) に移行することです。
  • データベース移行のスクリプト -「AWS DMS コンソールまたは AWS CLI、AWS SDK を使用してデータベース移行を実施できます。このブログでは AWS CLI での移行に注目します。」

マニュアルには 5 つの便利なガイドが含まれています。

ハンズオンラボもご提供しています。参加するには登録が必要です。(ハンズオンラボは英語のみの場合があります。)

ではサミットでお会いしましょう
DMS チームは今後開催予定の AWS サミットにいくつも参加する予定です。皆さんに直接お会いしてデータベース移行について語り合えることを楽しみにしています。

Jeff;

Amazon RDS – 2016 を振り返る

昨年は 294 件のブログを公開しましたが、取り上げることができなかった紹介に値するリリースはいくつもありました。そこで今回は Amazon Relational Database Service (RDS) に焦点を当て、このファミリーが 2016 年に進歩を遂げたすべてのポイントに関する総集編をお届けします。去年、同チームは 4 つの主なエリアに注目しました。

  • 高可用性
  • 拡張モニタリング
  • セキュリティの簡略化
  • データベースエンジンの更新

では、これらのエリアを見ていきましょう。

高可用性
リレーショナルデータベースは様々なタイプのアプリケーションにおいて、その中心にあります。高可用性の高いアプリケーションをお客様が構築できるようにするため、RDS は 2010 年初期からマルチ AZ サポートを提供しています (詳細は Amazon RDS – Multi-AZ Deployments For Enhanced Availability & Reliability をご覧ください)。データベースインスタンスの作成時にマルチ AZ 配置を選択すれば、複数のインスタンス設定、レプリケーションのアレンジ、ネットワーク、インスタンス、ネットワーク問題などの検出に使うスクリプトを書いたり、フェイルオーバーの決断や新しいセカンダリインスタンスをオンラインにするために、何週間にもわたりセットアップにかける時間を省くことができます。また、RDS はクロスリージョンリードレプリカを作成しやすくします。高可用性を実現しやすくするため、AWS が 2016 年に行ったその他の機能強化については次のブログをご覧ください。

 

拡張モニタリング
MySQL、MariaDB、Amazon Aurora のサポートなど、拡張モニタリングで行った最初の大きなステップは 2015 年末のことでした (New – Enhanced Monitoring for Amazon RDS)。そして引き続き 2016 年にも新たなニュースをお届けしました。

 

セキュリティの簡略化
保管中または利用中にかかわらず、お客様のデータを保護するための暗号化を可能な限りシンプルで使いやすくしたいと考えています。昨年に施した強化機能については次をご覧ください。

 

データベースエンジンの更新
オープンソースコミュニティと商用データベースのベンダーは非常に速いペースで新機能を追加したり新しいリリースを製作しています。AWS はその作業を密接に把握し重要なリリースに合わせて、できる限り早急に RDS を更新できるように努めています。2016 年のリリース内容については次をご覧ください。

 

次回の投稿
今年はすでに大きな発表がありました (詳細は AWS 2017 年の最新情報をご覧ください)。最近お知らせしたニュース (PostgreSQL との互換性を備えた Aurora バージョン) はもちろん、その他にも色々ご用意しています。お楽しみに! RDS、Amazon AuroraAmazon ElastiCache を最大限に活用する方法を詳しく説明している AWS データベースブログへの参加もご検討ください。

Jeff;

追伸 – このブログ投稿には、去年 AWS Database Migration Serviceスキーマ変換ツールに施したすべての強化機能は含まれていません。このトピックについては別件でブログを投稿する予定です。