Category: Database*


Amazon Aurora under the hood: クオーラムと障害

Anurag Guptaは幾つものデザインのヘルプを行ったAmazon Auroraを含むAWSが提供するデータベースサービスの責任者です。このシリーズではAnuragがAuroraを支える技術やデザインについて説明します。

Amazon Aurora ストレージは、ハイエンドなリレーショナルデータベースに求められる高いパフォーマンス、可用性、堅牢性要件を満たさなければならない分散システムです。これから 4回にわたって Amazon Aurora の設計に関する重要な要素を紹介します。この投稿はその第1回目です。

大規模なシステムにおいて必要な実世界の堅牢性、可用性、パフォーマンスのトレードオフを論じるパブリックドキュメントはあまり多くありません。このシリーズはトランザクショナルデータベースを設計する上での考慮点をベースにしていますが、ミュータブルな分散システムを設計する方に有用だと思います。

第1回目の投稿では、どのようにして Aurora ストレージでクォーラム採用するに至ったか、なぜ 3つのアベイラビリティゾーン(AZ)にわたる 6つのコピーを持つのかについてお話します。今回お話するいくつかは、SIGMOD paper にて論じたものです。

分散ストレージは素晴らしい考え方なのに、なぜうまく実現することが難しいのか
まず分散ストレージがなぜよい考え方なのかをお話しましょう。データベースソフトウェアとストレージを1つの箱に配置することで素早くデータベースを構築することは簡単です。この場合、その箱が障害に遭うことが問題となります。障害後にバックアップからリカバリするのに時間がかかります。バックアップされていない直近のデータが失われることを許容できるシステムはほとんどないでしょう。

データベースインスタンスからストレージを分離することで、障害に備えるということに加えて、柔軟性を高めることができます。お客様は、データベースを停止します。スケールアップやスケールダウンを行います。リードレプリカを加えたり、除去します。ストレージとデータベースとを疎結合にすることで、こういった操作が簡単になります。というのも、根幹となるストレージを新しい場所に再作成するのではなく、単にデタッチし、再度アタッチするだけでよいためです。データは重力を持ちますが、コンピュートは異なります。

もちろん、ストレージをコンピュートから分離させることだけでは、それぞれ障害に遭う可能性のある機器を増やしてしまうことになります。それゆえ、同期もしくは非同期のレプリケーションが利用されるのです。もし、障害が複数の機器にまたがるようなものでなければ、レプリケーションが堅牢性を高めます。

しかし、レプリケーションにも考慮が必要な点があります。同期レプリケーションでは、堅牢な書き込みを行うために、すべてのコピーが行われたことを認識されなければいけません。このアプローチでは、最も遅いディスク、ノード、もしくはネットワークに律速されることになります。非同期レプリケーションでは、レイテンシーが改善されますが、もしデータがレプリケートされる前に障害が発生した場合、データロスが起こりえます。どちらの選択肢も魅力的とは言えません。障害によって、レプリカのメンバーシップの変更が必要となります。このアプローチも面倒です。除去されるレプリカを再作成するのも高コストなので、このようなことを行うのは非常に保守的になります。この保守的な振る舞いは、レプリカを隔離するまで数分のダウンタイムが発生することを意味します。
クォーラムモデル
Aurora は代わりにクォーラムモデルを採用し、データコピーのサブセットに対して読み込み、書き込みを行います。V 個のコピーを抱えるクォーラムシステムは形式的に 2つのルールに従うことになります。1つ目は、読み込みクォーラム(Vr)、書き込みクォーラム(Vw)が、少なくとも1つのコピーを共通に持つ必要があります。

この方法では、もし 3つのコピーがある場合に、読み込みクォーラム、書き込みクォーラムが 2となり、それぞれがもう一方を確認することができます。このルールにより、データ項目が、2つのトランザクションによって同時に読み込み、あるいは書き込みされないことが保証されます。また、読み取りクォーラムには、最新バージョンのデータ項目を含むサイトが少なくとも1つ含まれていることが保証されます。

2つ目は、書き込みに使用されるクォーラムは、以前の書き込みクォーラムと重複があることを保証する必要があります。これは、Vw > V/2 という式を満たすことにより簡単に保証されます。このルールにより、同じデータ項目に対して、2つのトランザクションによる2つの書き込み操作が並列に発生しないことが保証されます。ここにいくつかのクォーラムモデルを示します。

V (コピーの数) Vw (書き込みクォーラム) Vr (読み込みクォーラム)
1 1 1
2 2 1
3 2 2
4 3 2
5 3 3
6 4 3
7 4 4

クォーラムシステムは、いくつか優れた特性があります。(例えば、リブートのために発生するような)一時的な障害やクォーラム内の1つのノードの遅延に対処するのと同じくらい簡単に、ノードの長期的な障害に対処できます。

 

The Aurora quorum
Aurora では、3つの AZ にわたって、6つのデータコピーを利用し、4つの書き込みクォーラム、3つの読み込みクォーラムを持っています。書き込みは 全6つのデータコピーに対して発行され、6つのコピーのうち4つから ACK が返ってきた時点で書き込みを完全に認めます。もし、そのうちの1つに遅延が発生していたとしても問題ありません。その他のノードが素早く返答し、遅れているノードは、可能な時に追いつきます。もし、ノードのうちの1つが少しの間、利用不能になった場合でも問題ありません。書き込み、読み込み能力が失われることはなく、そのノードも回復した際にリクエストを継続して受け付けます。そして、もしノードが永続的にダウンしたとしても、しばらく返答がないことを認識し、メンバーシップ変更プロトコルを利用して、新しいメンバーをクォーラムに追加します。

さて、なぜ 6つのコピーなのでしょうか?前述の文言は、多くの商用の分散システムでもよく採用される2/3 クォーラムの場合でも同様です。そのようなシステムでは、1つの障害を透過的に対処できます。こういったシステムでは、1つの障害に対応している間に、それと無関係なもう1つの障害が発生してしまう可能性があるということを極めてまれだと捉えています。

2/3 クォーラムの問題は、すべての障害が独立しているとは限らないということです。3つのAZにそれぞれ1つコピーをもつ 2/3 クォーラムを持っているとしましょう。AWS クラウドのような大規模分散システムでは、ノード、ディスク、ネットワークパス障害により、バックグラウンドでの小規模なノイズが常に発生しています。これ自体は全く問題ではありません。2/3 クォーラムでは、これらの障害に透過的に対処します。バックグラウンドでのノイズは、非常に小規模なので、同時に2つの障害が発生することは極めて稀です。

しかし、AWS リージョンを複数の AZ に分けた理由は、障害を分離するための領域を作るためです。仮に、AWS リージョン内の3つの AZ の内、1つがダウンしたとしましょう。屋根の崩落、火災、洪水、竜巻などのために、長時間ダウンするかもしれません。また、停電、不具合のあるソフトウェアのデプロイなどのために、短時間のダウンになるかもしれません。

こういった障害は、全てのクォーラムにおいて、3つのうちの 1つのコピーが失われる原因となります。既に障害対応をしている少数のクォーラムにとっては、二重障害となります。この時点で、1/3 のコピーのみ参照可能となり、このコピーがすべての書き込みを認識しているかを保証することはできません。この残った1つのコピーが、他の2つのコピーに対して、書き込みがなされた際に、スキップされたものだったという可能性もあります。このような場合、そのクォーラムは書き込み不可、読み込み不可、または復旧不可の状態となり、データベースボリュームが失われます。

6 つのコピーによるクォーラムモデルでは、書き込み可用性を失うことなく、AZ 障害を耐えることができ、AZ 障害とさらにもう1つの障害が重なったとしてもデータロストがありません。正当な読み込みクォーラムがある限り、データコピーを再構築し、完全に修復されたクォーラムを保持するかとができます。”AZ+1″ 障害モデルでは、3つの AZ と各 AZ ごとに 2つのコピーが必要な理由が明らかです。3/4 、または 3/5 クォーラムで運用することでも、”AZ+1″の目的を満たすことも可能ですが、リージョン内に 4つ、もしくは 5つの独立した AZ がある環境で運用した場合のみです。

6つのコピーは十分条件か?
6つのコピーは、必要条件ですが、十分条件でしょうか?この質問に対して、論理的に考えるには、平均故障間隔(MTTF)と平均復旧時間(MTTR)を通じて考える必要があります。ボリュームを修復する能力を失うには、読み込み可用性を失うことを必要とします。6 つのコピーによるクォーラムモデルでは、読み込み可用性を失うとは、6つのデータコピーのうち4つを失うことを意味します。これは、4つの独立した障害、2つの独立した障害、および1つのAZ障害、または2つのAZ障害のいずれかのことです。これらの可能性が最も高いのは、障害が発生したノードがあった後にAZ障害が発生し、最初に障害が発生したノードを修復している間に別のノードが停止することです。

それでも考えにくことですが、MTTF と MTTR が非常に悪い場合、そういったことが起こりえます。ある時点が過ぎると、MTTF や個別の障害が発生する可能性を改善するのが難しくなります。そのため、我々の最善策は、MTTR を小さくすることです。

Aurora では、データベースボリュームを 10 GB のチャンクに分けることによってこれを実現しています。各チャンクは、それぞれ 6つのコピーが利用している protection group に同期されます。大きいデータベースボリュームでは、数千のノードにわたって分散する可能性があります。10 GBでは、10 Gbit ネットワークを利用した場合に、1分以内にクォーラムの修復が完了します。一時的な問題を修復してしまうことを避けるため、検出時間とヒステリシスを考慮しても、MTTR はほんの数分です。その他の障害は、これと独立しているため、他の3つの障害、もしくは AZ 障害ともう1つの障害がこの時間枠で発生する可能性は低いと言えます。可能性はとても低いので、障害を挿入することさえ可能です。ストレージ層へのソフトウェアのデプロイメントは簡単です。単純にノードを停止し、ソフトウェアをインストールし、再起動するだけです。システムはこの障害に透過的に対応し、さらに多くのことを吸収できます。

このアプローチはホットスポット管理にも役立ちます。ホット・ディスクまたはノード上のセグメントを単に死んだとマークすることができ、ストレージ・フリート内の別のノードに自動的に修復されることを確認できます。

しかし、リビルド中に、もし実際に火災や洪水があり、数ヶ月間 AZ を失ったらどうなるでしょうか?この場合、6つのコピーのうち2つが失われてしまい、追加で、二重障害または AZ 障害があれば、データベースボリュームが失われます。考えすぎと言われるかもしれませんが、このようなことも考慮しています。壊滅的な災害が発生した後の、AZ を再建する MTTR です。

先ごろ、そのようなケースのためにデグレードモードへの切り替えを可能にするためのソフトウェアをデプロイしました。このモードでは、バックエンドで、AZ の長期的な喪失時に、3/4 書き込みクオーラムと 2/4 読み取りクオーラムに切り替えることができます。そして、AZ が再度、利用可能になった場合に、6つのコピーと 3AZ によるクオーラムに戻すことができます。このアプローチにより、残った AZ のうち 1 つに一時的な障害が発生しても復旧可能となり、書き込み可用性を失うことなく、さらにもう1つの障害に耐えることが可能です。

次回以降の投稿において、Aurora が前述のアプローチの欠点に対してどのように対処しているかを説明します。

  • パフォーマンス(クォーラムの参照は遅い)
  • コスト(6つのコピーを取得することはコスト増につながる)
  • 可用性(1つのボリュームを小さな複数のチャンクに分ける場合、メンバーシップの変更はコストの高い行為となる)

もしご質問などありまししたら、コメントもしくは aurora-pm@amazon.comにご連絡下さい。

次回: Amazon Aurora Under the Hood: クオーラムの読み取りと状態の遷移

翻訳は江川が担当しました。原文はこちら

Amazon Aurora (MySQL) Asynchronous Key Prefetchにより、Join性能を10倍以上に高速化

Amazon Aurora (MySQL)はJoinクエリを一桁以上高速化可能なasynchronous key prefetch (AKP)機能をリリースしました。

この機能は、Batched Key Access(BKA)JoinアルゴリズムとMulti-Range Read(MRR)最適化を使用するクエリに適用され、データ・セットがbuffer pooやquery cacheにない場合のパフォーマンスを向上させます。 我々のテストでは、上記の条件を満たすクエリでコールドバッファプールを使用した場合、クエリのレイテンシが10倍以上向上しました。

この機能は、Amazon Aurora version 1.15からご利用頂けます。Amazon Auroraドキュメント中のベストプラクティスの項目を是非ご覧ください。

ハイエンドの商用データベースの速度と可用性をオープンソースデータベースのシンプルさとコスト効率でご利用頂ける、Amazon Aurora MySQL/PostgreSQLついてはこちらをご覧下さい。

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

Amazon Aurora (MySQL)がR4インスタンスをサポート – 最大書き込みスループットが2倍に-

本日より、Amazon Aurora (MySQL)でR4インスタンスファミリーがご利用頂けるようになりました。R4インスタンスファミリーは新世代のメモリ最適化インスタンスでR3インスタンスファミリーよりも大きなL3キャッシュや高速なメモリを搭載することで性能の向上を行えます。

R4インスタンスファミリー内で最大のR4.16xlargeでは、64コア ・488GiBメモリを搭載しています。Amazon Aurora (MySQL)では、R4.16xlargeインスタンスをご利用頂くことで、R3.8xlargeインスタンスと比較して倍の最大200,000 writes/second の書き込み性能を発揮出来ます。

R4インスタンスファミリーはAmazon Aurora (MySQL) version 1.15からご利用頂けます。R4インスタンスはAmazon Aurora (MySQL)がご利用頂ける全てのリージョンでサポートしています。価格に関する詳細情報はこちらをご覧下さい。ハイエンドの商用データベースの速度と可用性をオープンソースデータベースのシンプルさとコスト効率でご利用頂ける、Amazon Aurora MySQL/PostgreSQLついてはこちらをご覧下さい。

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

今すぐご利用可能 – Amazon Aurora with PostgreSQL Compatibility

昨年後半、Amazon Aurora に PostgreSQL 互換のエンジンを追加する計画をお話しました。このアナウンスのすぐ後に、プライベートベータを開始し、今年の前半にはオープンプレビューを開始しました。このベータとプレビューの期間、非常に素晴らしい数多くのフィードバックをいただき、このサービスがお客様のニーズを満たし、期待値を超えることが確かなものになるように、できる限りのことをしました!

一般利用可能に
本日、Amazon Aurora with PostgreSQL Compatibility が一般利用可能となり、4つのリージョンで利用できるようになったことをお伝えします(その他のリージョンは今後対応していきます)。本サービスは、PostgreSQL 9.6.3 と互換性があり、そのストレージは、64 TB まで自動的にスケールし、そのバックエンドで 6つのレプリカを持ち、性能と可用性を高めています。

Amazon Aurora with MySQL Compatibility のように、このエディションはフルマネージドで、簡単にセットアップし、利用できます。性能の観点ではお客様自身で運用していた PostgreSQL と比較して、最大3倍のスループットを期待することができます(我々がどのようにこれを実現したかについては、Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases をご確認ください)。

新たにアップデートされた RDS Console から PostgreSQL と互換性のある Amazon Aurora インスタンスを起動することができます。まず、Amazon Aurora をエンジンとして選択し、PostgreSQL-Compatible をエディションとして選択し、[Next] をクリックします。

そして、インスタンスクラス、シングル(開発、テスト環境向き)/Multi-AZ(本番環境向き) デプロイメントの選択を行い、インスタンス名、管理者パスワードを設定し、[Next]をクリックします。

インスタンスクラスは、6つのモデルの中から選択可能です(2 から 64 のvCPUと 15.25 から 488 GiB のメモリ)。

db.r4 インスタンスクラスは新たに Aurora に追加され、トップエンドでより大きなサイズを提供します。 db.r4.16xlarge により、書き込み性能が向上され、これまで複数のデータベースでシャーディングしていたシステムを統合し、1つの Aurora データベースで運用できるようになるかもしれません。

次のページではより高度なオプションを設定できます。まず、VPC やPublicly Accessiblity の設定などのネットワークオプションです。

クラスター名やその他のデータベースオプションを設定します。暗号化も非常に簡単に利用でき、デフォルトで有効化されます; その際、あらかじめ用意されるデフォルトのマスターキーもしくは、ご自身でお持ちの鍵を選択可能です。

フェイルオーバーの動作、スナップショットバックアップの保持期間、拡張モニタリングを通じて詳細な(OSレベル)監視メトリクスを有効にするか選択します。

設定を終えたら、[Launch DB Instance]をクリックして進めましょう!

新しいインスタンス(Multi-AZ を指定したので、プライマリとセカンダリが表示されています)が、数分で立ち上がり、稼働しています。

各 PostgreSQL-Compatible インスタンスは自動的に 44 個のメトリクスを CloudWatch へ発行します。

拡張モニタリングを有効にしていれば、各インスタンスはさらに インスタンスごとかつプロセスごとのメトリクスを発行します。これは、インスタンス起動時、もしくは [Modify Instance]を通じて、起動後に有効化できます。下記に、拡張モニタリングを有効化した際のいくつかのメトリクスを示しています。

[Manage Graph]をクリックして、どのメトリクスを表示するか設定できます:

プロセスごとのメトリクスも利用可能です。

最大15個のリードレプリカを作成し、読み込みのキャパシティをスケールすることが可能です。

各レプリカに対してのリクエストを負荷分散するために、クラスターごとに単一のリーダーエンドポイントが割り当てられます:

Perfomance Insights
先に述べたように、Performance Insights が自動的に用意されます。この Amazon Aurora の機能はデータベースエンジンと直接接続され、クエリが利用するデータベースリソース、そのリソースがどうレスポンスタイムに影響しているかを見ることにより、各クエリの内部を深く確認できます。これが最初の画面です:

各クエリがどれだけ同時実行されているかを把握するために、SQL クエリごとの詳細を確認できます。

Peromance Insights にはこのブログには収まらないほどのビューやオプションがまだまだあります。詳細については、Amazon Performance Insights を使用するをご確認ください。

Amazon Aurora with PostgreSQL Compatibility への移行
AWS Database Migration ServiceSchema Conversion Tool が、商用データベースやオープンソースデータベースに格納されているデータを Amazon Aurora に移行するサポートを行います。Schema Conversion Tool は、既存のデータベーススキーマ、コードのアセスメントを素早く行い、お客様が MySQL, PostgreSQL のどちらを選択すべきかをサポートしてくれるでしょう。新しい期間限定プログラムである、Free DMS プログラムにより、無料で DMS, SCT を利用して、Aurora に移行することができます。最大 6ヶ月まで複数のタイプの DMS インスタンスを無料でご利用いただけます。

もしすでに、PostgreSQL を使っているお客様にとって嬉しい点として、PostGISdblink を含む拡張モジュールをサポートしていることがあげられるでしょう。

Available Now
Amazon Aurora with PostgreSQL Compatibility は本日より、米国東部(北部バージニア)、欧州(アイルランド), 米国西部(オレゴン)、米国東部(オハイオ)でご利用可能です。その他のリージョンについてもできる限り早くサポートできればと思います。

Jeff;

(元記事はこちらをご参照ください。翻訳はソリューションアーキテクト江川が担当しました。)

 

 

 

Amazon Redshift Spectrumによるセキュリティとコンプライアンスのためのデータベース監査ログの分析

(補足:本記事は2017年6月にAWS Bigdata Blogにポストされた記事の翻訳です。一部の記載を現時点の状況に合わせて更新してあります)

クラウドサービスの採用が増加するにつれて、組織は重要なワークロードをAWSに移行しています。これらのワークロードの中には、セキュリティとコンプライアンスの要件を満たすために監査が必要な機密データを格納、処理、分析するものがあります。監査人が良くする質問は、誰がどの機密データをいつ照会したのか、いつユーザが最後に自分の資格情報を変更/更新したのか、誰が、いつシステムにログインしたかということです。

デフォルトでは、Amazon Redshiftは、ユーザーの接続情報、変更情報、アクティビティに関連するすべての情報をデータベースに記録します。ただし、ディスク領域を効率的に管理するために、ログの使用状況と使用可能なディスク容量に応じて、ログは2〜5日間のみ保持されます。より長い時間ログデータを保持するには、データベース監査ロギングを有効にします。有効にすると、Amazon Redshiftは指定したS3バケットに自動的にデータを転送します。

Amazon Redshift Spectrumにより、Amazon S3に格納されたデータにクエリすることを可能にし、さらにAmazon Reshift のテーブルと結合することも可能です。 Redshift Spectrumを使い、S3に格納されている監査データを確認し、すべてのセキュリティおよびコンプライアンス関連の質問に答えることができます。AVRO、Parquet、テキストファイル(csv、pipe delimited、tsv)、シーケンスファイル、およびRCファイル形式、ORC、Grokなどのファイルをサポートしています。 gzip、snappy、bz2などのさまざまな圧縮タイプもサポートしています。

このブログでは、S3に保存されたAmazon Redshift の監査データを照会し、セキュリティーやコンプライアンスの質問への回答を提供する方法を説明します。

作業手順

次のリソースを設定します。

  • Amazon Redshift クラスタとパラメータグループ
  • Amazon Redshift に Redshift Spectrumアクセスを提供するIAMロールとポリシー
  • Redshift Spectrum外部表

前提条件

  • AWS アカウントを作成する
  • AWS CLI にて作業ができるように設定する
  • Amazon Redshift にアクセスできる環境を用意する。(psqlやその他クライアント)
  • S3バケットを作成する

クラスタ要件

Amazon Redshift クラスタは、次の条件を満たす必要があります。

  • 監査ログファイルを格納しているS3バケットと同じリージョンにあること
  • バージョン1.0.1294以降であること
  • ログ蓄積用のS3バケットに読み込み、PUT権限を設定されていること
  • AmazonS3ReadOnlyAccessとAmazonAthenaFullAccessの少なくとも2つのポリシーを追加したIAMロールにアタッチしていること

Amazon Redshift のセットアップ

ユーザーのアクティビティーをロギングするために、新しいパラメータグループを作ります。


aws redshift create-cluster-parameter-group --parameter-group-name rs10-enable-log --parameter-group-family Redshift-1.0 --description "Enable Audit Logging" 
aws redshift modify-cluster-parameter-group --parameter-group-name rs10-enable-log --parameters '{"ParameterName":"enable_user_activity_logging","ParameterValue":"true"}'

Amazon Redshift クラスタを上記で作成したパラメータグループを使い作成します。

aws redshift create-cluster --node-type dc1.large --cluster-type single-node --cluster-parameter-group-name rs10-enable-log --master-username <Username> --master-user-password <Password> --cluster-identifier <ClusterName>

クラスターが出来るまで待ち、作成されたらロギングを有効にします。

aws redshift enable-logging --cluster-identifier <ClusterName> --bucket-name <bucketname>

※S3のバケットポリシーなどはこちらを御覧ください。
※もしくは下記のようにマネージメントコンソールからログ用のS3のバケットを新規で作成するとバケットポリーが設定された状態のバケットが作成できます。

 

Redshift Spectrumをセットアップします。

Redshift Spectrumをセットアップするために、IAM ロールとポリシー、External Database,External Tablesを作成します。

IAM ロールとポリシー

Redshift データベースからS3バケットにアクセスするためのIAMロールを作成します。
RedshiftAssumeRole.json ファイルを作成し、下記のコマンドを実行してください。

aws iam create-role --role-name RedshiftSpectrumRole --assume-role-policy-document file://RedshiftAssumeRole.json

RedshiftAssumeRole.json
{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
			"Service": "redshift.amazonaws.com"
		},
		"Action": "sts:AssumeRole"
		}
	]
}

AmazonS3ReadOnlyAccess および AmazonAthenaFullAccess の2つのポリシーをアタッチします。

aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonAthenaFullAccess --role-name RedshiftSpectrumRole
aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess --role-name RedshiftSpectrumRole

作成したロールをAmazon Redshift クラスタに追加します。 <ClusterName> と <accountNumber> を自身のものに置き換えます。

aws redshift modify-cluster-iam-roles --cluster-identifier <ClusterName> --add-iam-roles arn:aws:iam::<accountNumber>:role/RedshiftSpectrumRole

ここまでの操作で、Amazon Redshift クラスタから S3 にアクセスできるように、Redshift Spectrum は設定されました。

External DatabaseとSchema

Amazon Redshift データベースにログインして、外部データベースとスキーマ、外部表を作成し、S3 に格納されたデータにアクセスできるよう設定します。

例えばpsql でアクセスする場合は下記がコマンド例になります。
本手順で作成している場合は、dev という名前のデータベースが作成されています。

psql -h <ご自身の設定したものを確認して変更ください>.ap-northeast-1.redshift.amazonaws.com -p 5439 -U dbadmin -d dev -W

Amazon Redshift で作成された外部データベースは、Amazon Athena データカタログに格納することが出来、Athena からも直接アクセスできます。

※本Blog (英語版)が書かれたあとにAWS Glue がリリースしておりますので、こちらも参考にしてください。

監査ログデータを照会するには、Amazon Redshift で外部データベースとスキーマを作成します。 DDL を実行する前に、以下のアカウント番号、ロール名、リージョン名を更新してください。

CREATE external SCHEMA auditLogSchema
FROM data catalog
DATABASE 'auditLogdb'
iam_role 'arn:aws:iam::<AccountNumber>:role/<RoleName>'
REGION '<regionName>'
CREATE external DATABASE if not exists;

REGION パラメータは、Athena データカタログのリージョンを指定します。 デフォルトの値は、Amazon Redshift クラスタと同じリージョンになります。(東京リージョンは、ap-northeast-1 になります。)

外部表の作成

Redshift Spectrum は S3 上のデータに対してクエリ可能になる外部表が作成可能です。 外部表は読取り専用であり、 現在、Spectrum を使用して S3 上のデータを変更することはできません。外部表は、表名の前にスキーマ名を付けた形で指定します。

3つの異なる監査ログ・ファイルを照会するための下記3つの表を作成します。

・ユーザーDDL:ユーザーが実施した DDL(CREATEやDROPなど)を記録します。
・ユーザー接続:成功または失敗したすべてのログオン情報をログに記録します。
・ユーザーアクティビティ:ユーザーが実行したすべてのクエリを記録します。
ユーザーDDL とユーザー接続のデータファイル形式は、パイプ区切りのテキストファイルです。 どちらのファイルもgzipユーティリティを使用して圧縮されています。 ユーザーアクティビティログはフリーフローテキストです。 各クエリは新しい行で区切られます。 このログも、gzip ユーティリティを使用して圧縮されています。

次のクエリのS3 バケットの場所を自身のバケットになおして実行してください。

CREATE external TABLE auditlogschema.userlog
(
userid INTEGER,
username CHAR(50),
oldusername CHAR(50),
action CHAR(10),
usecreatedb INTEGER,
usesuper INTEGER,
usecatupd INTEGER,
valuntil TIMESTAMP,
pid INTEGER,
xid BIGINT,
recordtime VARCHAR(200)
)
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<bucketName>/AWSLogs/<accountNumber>/redshift/<regionName>/YYYY/MM/DD/';

CREATE external TABLE auditlogschema.connectionlog
(
event CHAR(50) ,
recordtime VARCHAR(200) ,
remotehost CHAR(32) ,
remoteport CHAR(32) ,
pid INTEGER ,
dbname CHAR(50) ,
username CHAR(50) ,
authmethod CHAR(32) ,
duration BIGINT ,
sslversion CHAR(50) ,
sslcipher CHAR(128) ,
mtu INTEGER ,
sslcompression CHAR(64) ,
sslexpansion CHAR(64) ,
iamauthguid CHAR(36)
)
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<bucketName>/AWSLogs/<accountNumber>/redshift/<regionName>/YYYY/MM/DD/';

CREATE external TABLE auditlogschema.activitylog
(
logtext VARCHAR(20000)
)
row format delimited
lines terminated by '\n'
stored as textfile
location 's3://<bucketName>/AWSLogs/<accountNumber>/redshift/<regionName>/YYYY/MM/DD/';

guest ユーザーを作成して簡単な作業をしログを作成する。

ユーザー “guest”  を作成してログインし、 “person” という表を作成します。次に、テーブルに対してクエリーを実行します。

管理ユーザーとしてログインし、新しいユーザー “guest” を作成します。

CREATE USER guest PASSWORD 'Temp1234';

ユーザー  “guest” としてログインし、以下の DDL を実行します。

CREATE TABLE person (id int, name varchar(50),address VARCHAR(500));

INSERT INTO person VALUES(1,'Sam','7 Avonworth sq, Columbia, MD');
INSERT INTO person VALUES(2,'John','10125 Main St, Edison, NJ');
INSERT INTO person VALUES(3,'Jake','33w 7th st, NY, NY');
INSERT INTO person VALUES(4,'Josh','21025 Stanford Sq, Stanford, CT');
INSERT INTO person VALUES(5,'James','909 Trafalgar sq, Elkton, MD');

guest  でログインしている間に、person テーブルでいくつかのクエリを実行して、アクティビティログを生成します。

SELECT * 
  FROM person;

SELECT * 
  FROM person 
 WHERE name='John';

次に、上記で作成した3つの外部表(それぞれのログ)毎に、1つのクエリーの具体例を説明します。

ユーザーDDL ログ

次のクエリは、ユーザー guest がその日に実行した作業が確認できます。

SELECT username
,action
,recordtime 
  FROM auditlogschema.userlog 
 WHERE action in ('create','alter','drop','rename') 
   AND username='guest';

ユーザー接続ログ

次のクエリでは、ユーザー guest がログインした remotehost名、時刻を確認できます。

SELECT event
,recordtime
,remotehost 
  FROM auditlogschema.connectionlog 
 WHERE length(username) >0 
   AND username='guest' 
ORDER BY recordtime;

ユーザーアクティビティログ

次のクエリは、誰がいつ、person表 にアクセスしたか、またその際に流したクエリを確認できます。

SELECT pu.usename
	,substring(logtext,2,strpos(logtext,'UTC')+1)UTCTime
	,substring(logtext,strpos(logtext,'LOG:')+5) query
  FROM auditlogschema.activitylog al,pg_user pu
 WHERE logtext like '%xid=%'
   AND logtext not like '%SELECT 1%'
   AND logtext not like '%SET %'
   AND logtext like '%from person%'
   AND substring(substring(logtext,strpos(logtext,'userid=')+7),1,strpos(substring(logtext,strpos(logtext,'userid=')+7),' '))=pu.usesysid;

 

まとめ

このBlogでは、Amazon Redshift に新たに追加された機能 (Redshift Spectrum) を使用して、S3に格納されている監査ログデータを照会し、セキュリティおよびコンプライアンス関連の質問に簡単に回答する方法について説明しました。

Amazon Redshift Spectrum は2017年10月20日現在、東京リージョンでも利用可能となっております。

Amazon Redshift Spectrum の詳細については、こちらをご覧ください。 新機能についての詳細は、「Get Started」をご覧ください。

翻訳:パートナーソリューションアーキテクト 相澤

Amazon Redshift Spectrumが東京リージョンで利用可能になりました & Spectrum 一般公開後のアップデート

Amazon Redshift は高速で完全マネージド型のデータウェアハウスです。ペタバイト級のデータを高速なローカルストレージに取り込み、多様なクエリを処理可能なデータウェアハウスを実現可能です。

今年の4月に新機能としてAmazon Redshift Spectrumが発表されました。これはデータをAmazon S3に置いたままロードせずにAmazon Redshiftからクエリする事を可能にする新機能であり、Amazon Redshiftが処理可能なデータサイズをペタバイトから、エクサバイト級に押し上げるものです。データ置き場(Amazon S3)とデータ処理基盤(Amazon Redshift)が分離するということは、単に扱えるデータサイズが増えるだけでなく、これまで以上に多彩なワークロードを実現可能にしました。例えば、ロード時間なしで素早くデータ分析を開始したり、あまりアクセスしない古いデータと頻繁にアクセスするデータの置き場所を変えることで、コスト効率の良いデータウェアハウスを実現しつつ、全期間のデータ分析を実現する等です。

Amazon Redshift Spectrumについての詳細を確認するには、以下の記事を参照してください。

Amazon Redshift Spectrumは北バージニアリージョンから提供を開始し、継続的に利用可能なリージョンを増やしてきました。そして本日からAmazon Redshift Spectrumが東京リージョンで利用可能になりました!

AWSのサービスはリリースした後も新機能が継続的に追加されていきます。Amazon Redshift Spectrumもその例外ではなく、上述のブログには書かれていなかった機能が多数追加されています。本稿ではGA(一般利用開始)から現在までの期間でどのような機能追加、改善があったのかを解説します。

継続的な処理性能の改善

Amazon Redshiftでは内部的な改善による処理性能の向上が継続的に行われています。Amazon Redshift Spectrumでの改善の1つとして、大きいファイルの分割アクセスがあります。GAの時点では1つのファイルを1つのSpectrum層のプロセスが処理していたため、ファイルサイズが巨大だった場合に読み取りがボトルネックになる可能性がありましたが、その後の改善で巨大なファイルは自動的に分割して読み取り処理を行なうように改善されています。(巨大ファイルをそのまま置く事を推奨しているわけではありません。可能であれば利用者の方で適切なサイズに分割しておく事が推奨されます)

Amazon Redshift Spectrumのパフォーマンスについては以下の記事も参照してください。

対応フォーマットの追加

Amazon Redshift Spectrumでは多彩なフォーマットに対応しているのが特長です。CSV、TSVといった区切りファイル、Parquet、RCFileといったカラムナフォーマット等です。そしてGA後も継続的に対応フォーマットが追加されています。例えばカラムナフォーマットのORCファイルや、Regex(正規表現)等がGA後に追加されました。現時点では以下のファイルフォーマットをサポートしています。

  • AVRO
  • PARQUET
  • TEXTFILE
  • SEQUENCEFILE
  • RCFILE
  • RegexSerDe
  • ORC
  • Grok
  • OpenCSV

また読み取りの際の機能追加も行われています。例えばskip.header.line.countプロパティが追加されています。これはCSVファイル等のテキストファイルの先頭数行を読み飛ばすという機能で、列の名前等が先頭行に入っているファイルの読み取りに便利です。

参照)CREATE EXTERNAL TABLE

外部表を含んだVIEWのサポート

GA時には、外部表(Amazon S3上にデータがある表)に対してVIEWを作成する事ができないという制約がありましたが、現在はVIEWの定義に外部表を含むことが可能になっています。これはCREATE VIEWにWITH NO SCHEMA BINDINGオプションが使えるよう機能追加されたことで実現可能になりました。外部表をVIEW定義に含めることが出来ると、データウェアハウスとしての利用がさらに便利になります。例えば最近のデータはローカルストレージ上の表にあり、古いデータがAmazon S3上にあるようなケースでも、全体をUNION ALLで結合したVIEWを作成することで、ユーザはどちらのデータがどちらの領域にあるのか気にすることなく分析を実行することが可能になります。

既存JDBC/ODBCアプリケーションとの互換性向上

JDBCドライバやODBCドライバも改善が続けられています。Amazon Redshift Spectrumリリース当初はドライバのメタデータ取得機能(表の一覧や表定義を取得するための機能)が、外部表のデータを返すことが出来なかったため、SQLワークベンチのようなGUIアプリケーションにおいて、外部表へのSQLは実行できるが、GUI上の表一覧の画面には外部表が表示されないという課題がありました。最新のドライバでは外部表もローカルの表と同じようにメタデータが取得できるように改善されており、既存のJDBC/ODBCアプリケーションでの互換性が向上しています。

AWS Glueデータカタログとの連係

Amazon Redshift Spectrumは外部表のメタデータ管理(どこにファイルが置かれていて、スキーマ定義はどうなっているかといった情報の管理)のために、Amazon Athena、もしくはお客様管理のHiveメタストアを利用することが可能です。AWS Glueがリリースされた際に拡張され、AWS GlueのデータカタログをAmazon Redshift Spectrumのメタデータ管理に利用可能になりました。AWS Glueのデータカタログはサーバレスであるために運用負荷を低く抑えることが可能なだけでなく、クローラーによるスキーマの自動更新が実現可能です。新しいファイルがAmazon S3に置かれると、それをクローラーが発見し、データカタログを更新するため、ユーザが手動で登録すること無しにAmazon Redshift Spectrumからクエリ可能にする事が実現可能になりました。

参照)Amazon Redshift Spectrum Now Integrates with AWS Glue

システム表等、周辺情報を取得する方法の改善

ローカルストレージに存在する表と、外部表を区別することなく、表や列の情報を取り出すためのSVV_TABLESSVV_COLUMNSが追加されました。また外部表のスキーマを分かりやすく返すSVV_EXTERNAL_SCHEMASも追加されています。

また疑似列として$pathと $sizeが利用可能になりました。この列をクエリで指定することで、クエリ対象の外部表のサイズやS3でのURLを得る事が可能です。また、spectrum_enable_pseudo_columns パラメータをfalseに設定することでこの疑似列使えないよう制限することも可能です。

参照)CREATE EXTERNAL TABLE ※本稿執筆時点では日本語マニュアルの既述には$path、$sizeが無いため、英語版に切り替えてご覧ください

ご利用いただくには

東京リージョンで、新しく Redshift クラスタを立ち上げていただいた場合には、そのまま Spectrum の機能をお使いいただくことができます。Spectrum の始め方については、公式ドキュメントをご覧ください。

東京リージョンですでにクラスターをご利用中のお客さまについては、メンテナンスウィンドウ中に順次メンテナンスイベントが実施されていきますので、その後にご利用いただけるようになります。もし既存のクラスター上で、すぐに Spectrum をご利用になりたい場合には、WLM などの設定を変更した上でクラスターを再起動していただくことにより、Spectrum の機能がご利用いただけるようになります。

引き続きご期待ください

本日の発表により、バージニア北部、オレゴン、オハイオ、東京、アイルランドリージョンでAmazon Redshift Spectrumが利用可能になりました。今後もAmazon Redshiftには継続的に新機能、改善が行われていく予定です。最新情報はAWSの最新情報ページで告知されますのでぜひご覧ください(RSSでのアクセスも可能です)。

AWS 下佐粉 昭 (simosako@)

データウェアハウスをエクサバイト級に拡張するAmazon Redshift Spectrum

(補足:本記事は2017年7月にAWS Bigdata Blogにポストされた記事の翻訳です。一部の記載を現時点の状況に合わせて更新してあります)

何年も前、最初にクラウドベースのデータウェアハウスを構築する可能性について検討を始めた際、我々は、我々の顧客が増え続ける一方の大量のデータを持つ一方で、そのごく一部のデータのみが既存のデータウェアハウスやHadoopシステムに投入され分析に利用されているという事実に直面しました。同時に、これがクラウド特有の特殊事情ではないこともわかりました。エンタープライズストレージ市場の成長率がデータウェアハウス市場のそれを大きく上回る様々な業界においても、状況は同じだったのです。

我々はこれを“ダークデータ”問題と名付けました。我々の顧客は、彼らが収集したデータに利用されていない価値があることに気づいていました。そうでなければなぜそれを保管するコストをかけるでしょうか?しかしながら、彼らが利用できるシステムは、これらのデータ全てを処理するには遅すぎ、複雑すぎ、高すぎたため、データのサブセットのみを利用することになりました。彼らはいつか誰かが解決策を見出すことへの楽観的な期待とともに、これらのデータを保持し続けました。

Amazon Redshift はダークデータ問題の解決に寄与することから、AWSサービスの中でも最も成長の速いサービスの一つとなりました。このソリューションは大半の代替案に比べ、少なくとも一桁は安価で、かつ高速でした。また、Amazon Redshiftは当初からフルマネージドのサービスで、ユーザーはキャパシティやプロビジョニング、パッチ対応、監視、バックアップ等を始めとする様々なDBA課題について頭を悩ませる必要がありませんでした。 VevoYelpRedfin,Edmunds, NTTドコモなどの多くの顧客が、Amazon Redshiftに移行して、クエリー性能の改善、DBAオーバーヘッドの削減、そして分析コストの低減を実現しました。

我々の顧客のデータは、極めて速いペースで増え続けています。おしなべて、ギガバイトのデータはペタバイトとなり、平均的なAmazon Redshift顧客が分析するデータ量は毎年二倍になっています。我々が、増加するデータを扱う上でお客様の手助けとなる機能群を実装してきた理由はここにあります。例えばクエリースループットを二倍にする、圧縮率を三倍から四倍に改善する、といったことです。これらは、お客様がデータを破棄したり分析システムから削除したりすることを考慮せざるを得なくなる時期を遅らせることができます。しかしながら、ペタバイトのデータを日々生成するAWSユーザーが増えており、こうしたデータはわずか3年でエクサバイトの水準に達します。このようなお客様のためのソリューションは存在しませんでした。もしデータが毎年倍々になるのであれば、コスト・性能・管理のシンプルさに革新をもたらす、新たな、破壊的なアプローチを見付けることを強いられるまで、そう長い時間はかからないでしょう。

今日利用可能な選択肢に目を向けてみましょう。お客様は、Amazon EMRを用いて、Apache HiveなどのHadoopベースの技術を利用することができます。これは実際のところ、非常に素晴らしいソリューションです。抽出と変換のステップを経ることなく、Amazon S3上のデータを簡単かつ低コストで直接操作できるようになるからです。クラスターは必要な時に起動することができ、実行対象となる特定のジョブに合うよう適切にサイジングすることができます。こうしたシステムは、スキャンやフィルター、集計といったスケールアウト型の処理には最適です。一方で、これらのシステムは複雑なクエリー処理には向いていません。例えば、結合処理ではノード間でデータをシャッフルする必要が生じます。巨大なデータと多数のノードが存在する場合、この処理は極めて低速になります。そし結合処理は、重要な分析課題の大半において本質的に重要なものです。

Amazon Redshiftのような、列指向かつ超並列型のデータウェアハウスを利用することもできます。こうしたシステムは、巨大なデータセットに対する結合や集計といった複雑な分析クエリーを、単純かつ高速に実行することを可能にします。特に、Amazon Redshiftは、高速なローカルディスクと洗練されたクエリー実行、そして結合処理に最適化されたデータフォーマットを活用します。標準SQLを用いるので、既存のETLツールやBIツールを活用することもできます。一方で、ストレージとCPU双方の要件を満たすようにクラスターをプロビジョニングする必要があり、データロードも不可欠となります。

いずれのソリューションも強力な特長を備えていますが、お客様はどちらの特長を優先するかの判断を強いられます。我々はこれを「ORの抑圧(※)」と見做しています。ローカルディスクのスループットとAmazon S3のスケーラビリティは両立できない。洗練されたクエリー最適化と高度にスケールするデータ処理は両立できない。最適化されたフォーマットによる高速な結合処理性能と、汎用的なデータフォーマットを用いる様々なデータ処理エンジンは両立できない、などです。しかし、この選択は本来迫られるべきではありません。この規模においては、選択する余裕など到底ないからです。お客様が必要とするのは「上記の全て」なのです。

※ジム・コリンズが著書「ビジョナリー・カンパニー」で提示した概念。一見矛盾する力や考え方は同時に追求できない。

Redshift Spectrum

Redshift Spectrumは、こうした「ORの抑圧」に終止符を打つべく開発されました。Redshift Spectrumによって、Amazon Redshiftを利用されているお客様はAmazon S3上のデータに対し

簡単にクエリーを実行できるようになります。Amazon EMRと同様に、お客様はオープンなデータフォーマットと安価なストレージの恩恵を享受できます。データを抽出し、フィルターし、射影し、集計し、グループ化し、ソートするために、何千ものノードにスケールアウトすることも可能です。Amazon Athenaと同様に、Redshift Spectrumはサーバーレスであり、プロビジョニングや管理は必要ありません。単に、Redshift Spectrumを利用したクエリーが実行されている間に消費中のリソースに対してお支払いいただくだけです。Amazon Redshift自身と同様に、洗練されたクエリーオプティマイザー、ローカルディスク上のデータへの高速アクセス、そして標準SQLの恩恵を得ることができます。そして、他のどのようなソリューションとも異なり、Redshift Spectrumはエクサバイト級ないしはそれ以上のデータに対して、高度に洗練されたクエリーを、わずか数分で実行することが可能です。

Redshift SpectrumはAmazon Redshiftの組み込み機能の一つであり、お客様の既存のクエリーやBIツールはシームレスにご利用いただくことができます。背後では、我々は複数のアベイラビリティゾーンに跨がった何千ものRedshift Spectrumノードのフリートを運用しています。これらのノードは、処理する必要があるデータに基づいて透過的にスケールし、クエリーに割り当てられます。プロビジョニングや利用の確約は不要です。Redshift Spectrumは同時実行性にも優れています。お客様は任意のAmazon S3上のデータに対して、複数のAmazon Redshiftクラスターからアクセスすることができます。

Redshift Spectrumクエリーのライフサイクル

Redshift Spectrumクエリーのライフサイクルは、クエリーがAmazon Redshiftクラスターのリーダーノードに送信された時に始まります。リーダーノードはクエリーを最適化し、コンパイルし、その実行命令をAmazon Redshiftクラスターのコンピュートノード群に送ります。次に、コンピュートノード群は外部テーブルに関する情報をデータカタログから取得し、当該クエリーのフィルターと結合に基づいて、無関係なパーティションを動的に取り除きます。コンピュートノードはまた、ノード上でローカルに利用可能なデータを精査して、Amazon S3内の関連するオブジェクトだけを効率的にスキャンするようプレディケイトプッシュダウンを行います。

Amazon Redshiftコンピュートノードは、続いて、処理する必要のあるオブジェクトの数に基づいて複数のリクエストを生成し、それらをRedshift Spectrumに一斉に送ります。Redshift Spectrumは、AWSリージョンごとに何千ものAmazon EC2インスタンスをプールしています。Redshift SpectrumのワーカーノードはAmazon S3上のデータをスキャン、フィルター、集約し、処理に必要なデータをAmazon Redshiftクラスターにストリーミングします。その後、最終的な結合とマージの処理がクラスター内でローカルに実行され、結果がクライアントに返されます。

Redshift Spectrumのアーキテクチャーはいくつかのアドバンテージをもたらします。第一に、コンピュートリソースをAmazon S3のストレージレイヤーとは独立した形で、弾力的にスケールさせることができます。第二に、Amazon S3上の同一データに対して複数のAmazon Redshiftクラスターを起動しクエリーを実行できるため、(単一のAmazon Redshiftクラスターに比べて)ずっと高い同時実行性能を提供します。第三に、Redshift SpectrumはAmazon Redshiftのクエリーオプティマイザーを利用して効率的なクエリープランを生成します。これは複数テーブルの結合やWindow関数を伴う複雑なクエリーでも同様です。第四に、ソースデータをそれらのネイティブなフォーマット(Parquet、RCFile、ORC、CSV、TSV、Sequence、Avro、RegexSerDe、Grok等、さらに多くのフォーマットが今後追加される予定です)で直接操作することが可能です。このことは、データロードやデータ変換処理が不要であることを意味します。また、データを重複して保有することや、それに伴う追加のコストも不要にします。第五に、オープンなデータフォーマットを用いることで、単一のAmazon S3データを元に、様々なチーム間で他のAWSサービスや実行エンジンを柔軟に利用し協働することを可能にします。お客様はこれらのアドバンテージ全てを享受することが可能です。また、Redshift SpectrumはAmazon Redshiftの一機能であることから、Amazon Redshiftと同じレベルでのエンドツーエンドセキュリティ、コンプライアンス、および認定を得ることができます。

性能とコストパフォーマンスを目的とした設計

Amazon Redshift Spectrumでは、実際に実行したクエリーでスキャンされたデータ量の分のみ、お支払いいただきます。ファイル分割、列指向フォーマット、データ圧縮を利用してAmazon S3から読み取るデータ量を最小化することをお勧めします。これらはクエリー性能を大幅に改善しコスト削減にも寄与するため、データウェアハウスでは重要なファクターとなります。Amazon S3上のデータを日、時、およびその他のカスタムキーで分割することで、Redshift Spectrumは無関係なパーティションを動的に取り除き、処理対象のデータ量を最小化することができるようになります。データがParquetのような列指向フォーマットで保管されている場合には、Redshift Spectrumは行全体を処理する代わりに、当該クエリーによって必要とされる列だけをスキャンします。同様に、データがRedshift Spectrumでサポートされている圧縮アルゴリズムで圧縮されている場合は、スキャンされるデータはより少ない量で済みます。

Amazon RedshiftおよびRedshift Spectrumでは、両者のいわゆる「いいとこ取り」が可能となります。もし同一データに対する頻繁なクエリーを実行する必要があるなら、Amazon Redshiftにデータを保存することで、フル機能を持ち、構造化されたデータを定額で保存およびクエリーできるデータウェアハウスの利便性を享受できるでしょう。同時に、それが過去のデータであるか直近のデータであるかに関わらず、さらなるデータを複数のオープンフォーマットの形式でAmazon S3に保持して、Amazon Redshiftのクエリー機能をAmazon S3データレイクへと拡張することも可能です。

そしてもうひとつ、データロードが不要になること – これにより、Amazon Redshift Spectrumはデータウェアハウスをエクサバイト級にまで拡張します。Redshift Spectrumは「ORの抑圧」を終わらせます。お客様が、データを望む場所に望むフォーマットで保存し、必要な時に標準SQLを用いて高速に処理できる状態に置くことを、現在と将来にわたって可能にするのです。

 

参考文献

Amazon Redshift Spectrum 10 のベストプラクティス

著者について

Maor Kleider はAmazon Redshiftのシニアプロダクトマネージャーです。Amazon Redshiftは、高速、シンプルかつコスト効率のよいデータウェアハウスです。Maorはお客様およびパートナーの皆様と協働し、彼らの特有なビッグデータユースケースに付いて学び、その利用体験をよりよくすることに情熱を傾けています。余暇では、家族とともに旅行やレストラン開拓を楽しんでいます。

(翻訳はAWS プロフェッショナルサービス仲谷が担当しました。)

Amazon Redshiftに新世代のDC2ノードが追加 – 価格はそのままで最大2倍の性能向上

Amazon Redshiftは高速で完全マネージド型のデータウェアハウス(DWH)です。ペタバイト級までスケールアウトが可能であり、Amazon Redshift Spectrumを利用することでAmazon S3上に保存されたエクサバイト級のデータにロード無しでクエリを実行することも可能です。

Amazon Redshiftがリリースされた当初からご利用いただいている方であれば、当初はHDD搭載のDW1と呼ばれるノード1種類しか無かったことをご記憶かと思います。続いてSSDを搭載した新しいノード追加され、DW1(HDDベース)とDW2(SSDベース)の2タイプから選択可能になりました。

その後、DW1の後継がリリースされる際にHDDベースはDense Storage (DS) に、SSDベースはDense Compute (DC)とそれぞれの特性を表した名前に整理され、DS1(旧DW1)の後継としてDS2がリリースされました。DS2リリース時のブログエントリはこちらにありますが、その登場はDS1ユーザから驚きをもって迎えられました。DWHとしての性能が大きく向上しつつ、ノードの価格は据え置きだったからです。

次はDense Compute (DC)の番です。DC2が本日より利用可能になりました!

第二世代のDense Computeノード

DC2はDC1の後継となるノードであり、高いスループットと低いレイテンシを必要とするDWHワークロードのために設計されています。CPUはIntel E5-2686 v4(Broadwell)になり、高速なDDR4メモリを搭載。ストレージはNVMe接続のSSDです。
私達はAmazon Redshiftがこのより高速なCPU、ネットワーク、ストレージの性能をDC2で十分に発揮できるようチューニングを行い、結果としてDC1との同一価格構成での比較で最大2倍のパフォーマンスを発揮しています。DC2.8xlargeノードではスライスあたりで2倍のメモリを搭載しており、ストレージレイアウトの改善によって30%多いデータが保管できるようになりました。これらの改善がされた新世代のノードを旧世代と同じ価格で提供します。

DC2.8xlargeではパフォーマンスを最大化するためにスライス数が変更されています。旧世代のDC1.8xlargeでは1ノードあたり32スライスでしたが、DC2.8xlargeでは16スライスに変更されています。DC2.largeはDC1.largeと変わらず1ノード2スライスのままです。
このため、DC1.8xlarge (もしくはDS)からDC2.8xlargeへ移行するためにはクラスターのリサイズが必要になります。DC1.largeからDC2.largeへの移行については、リサイズもしくはDC1で取得したスナップショットからの作成が可能です。

本日より利用可能です

DC2ノードはUS East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), EU (Frankfurt), EU (Ireland), EU (London), Asia Pacific (Singapore), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Seoul), Asia Pacific (Mumbai), Canada (Central), South America (São Paulo) リージョンで本日よりご利用いただけます。

詳細な情報はこちらのブログも参照してください。また価格についてはAmazon Redshift料金ページを確認してください。

AWS 下佐粉 昭 (@simosako)

大規模なデータベースをオープンソースデータベースへ移行する際のカテゴリ分けと優先度づけ

AWS Schema Conversion Tool (AWS SCT)AWS Database Migration Service (AWS DMS) はコマーシャルデータベースからAmazon RDSの様々なデータベースエンジンへの移行を簡単に行えるようにするツールです。 AWS SCTはプロプライエタリなデータベースをオープンソースデータベースへ移行する際に手助けを行います。移行元のデータベーススキーマや多くのカスタムコードを移行先のデータベースに適した形へ変換を行います。ツールが変換を行うカスタムコードには、ビュー、ストアード・プロシージャー、ストアード・ファンクションを含みます。一方、自動的に変換が出来ないものとしては、手動で変換が行いやすいように該当箇所を抽出します。AWS DMSはダウンタイムを最小限に抑えながら、簡単・安全にデータを移行することを可能にします。

データベースエンジンを変更することは大変な作業ですが、Amazon Auroraのようなスケーラブルでコスト効率がいいフルマネージドサービスの恩恵を受けやすくなる利点があり、移行を行う価値があります。AWS SCTとAWS DMSを用いることで、単一のデータベースからオープンソースへの移行を評価し、計画を行うことが容易になります。 AWT SCTアセスメントレポートを生成し、これらのツールを使用することで、データベースを移行することが、どのくらい簡単であるかということがおわかりになると思います。

以下のブログやビデオは、オープンソースデータベースへ移行するための情報の一例です。

もし、数百・数千のデータベースを持っていた場合は
評価レポートを作成し、1つ、2つ、またはさらに10のデータベースをオープンソースデータベースへ移行することは、簡単なプロセスです。 おそらく、どのアプリケーションが利用しているデータベースを最初に移動するか判断するための材料は十分お持ちだと思います。 組織内外で利用されている数百または数千のデータベースインスタンスがあり、十分なアプリケーションの知識がない場合はどうなるでしょうか?

集中管理されたIT部門では、管理するデータベースの数、バックアップのスケジュール設定などを一元管理することが出来ます。 しかし、大規模な動向を計画したり、分析のために優先順位を付けるための十分な詳細がないかもしれません。 この記事では、データベースポートフォリオを評価し、管理可能な移行のパイプラインに分解してプロセスを円滑に進めるための方法について説明します。

小さいプロジェクトのコラボレーション

1つの異種データベース移行の詳細なプロジェクト計画は、次の表に示すように12の手順で構成されます。

フェーズ 説明 フェーズ 説明
1 評価 7 システム全体で機能テスト
2 データベーススキーマ変換 8 パフォーマンステスト
3 アプリケーション変換/修正 9 結合とデプロイ
4 スクリプト変換 10 トレーニング
5 サードパーティアプリケーションとのインテグレーション 11 ドキュメントと変更管理
6 データ移行 12 リリース後のサポート

このブログの目的上、移行プロジェクトを計画するプロセスは、分析と計画、スキーマ移行、データ移行、アプリケーション移行、およびカットオーバーの5つの作業領域に分類できます。 移行の所要時間は、通常、移行およびテストのフェーズでどのくらいの時間を費やすかによって異なります。 いくつかの移行を並行して計画している場合は、どちらの移行が最も時間がかかるのか、最初に取り組むことができるのか、迅速に取り組むことができるのかを理解する必要があります。

CTWorkflow

オープンソースデータベースに移行する際に最初に分析するデータベースの優先順位付けは、データベース内で独自のコードがどれくらい使用されているかに左右されます。 使用しているプロプライエタリコードの量は、プロジェクトの移行段階でそれを変換してテストするのにかかる時間に影響します。 カテゴリーと基準を設定した後に、ディクショナリクエリを使用してデータベースをワークロード別に分類できます。

ワークロードを分類するためのフレームワーク

ワークロードは、通常、さらに分析するために5つのカテゴリに分類されます。 このブログでは、カテゴリ1〜3に焦点を当てます。

カテゴリ 1: (ODBC/JDBC)

ODBC(Open Database Connectivity)/ JDBC(Java Database Connectivity)を使用するアプリケーションは、 プロシージャ、ファンクション、トリガー、またはビューで独自のデータベースコードの利用量はとても少ないです。 アプリケーションロジックは、データベース外のコード(例えば、Java、Python、Ruby)にあるため簡単に別のデータベースに移行できます。

カテゴリ2: (独自データベースコードが少ないワークロード)

これらのワークロードでは、アプリケーションレベルのコード(Java、Python、Ruby、bashなど)と独自のデータベースコードを組み合わせて、JavaやPythonで扱いにくい機能を実行します。 経験則として、200未満のプロシージャ/ファンクションがこのカテゴリに分類されます。 高度な機能を使用する場合の許容範囲はさまざまです。 高度な機能を使用すると、ターゲットエンジンへのコードの自動変換が遅くなる可能性があります。 これらのワークロードでは、通常スキーマ設計はかなり簡単です。 テーブルやビューのような基本的なデータ構造を使用します。

カテゴリ3: (独自データベースコードが多いワークロード)

これらのワークロードは、独自のデータベースコードによって完全に実行され、多くの場合、高度な機能が使用されます。 これらのワークロードの多くは、1,000以上の独自の機能を備えています。 また、機能列、マテリアライズド・ビュー、リンクされたサーバーなどの高度なスキーマ機能も使用します。これらのワークロードの課題は、他のフレームワークに変換する際にに多くの作業時間を必要とすることです。 ソースコードで実行されるチューニングオプションは、変換しターゲットエンジンでテストを行う必要があるためです。

カテゴリ4: (ベンダ依存のワークロード)

これらのワークロードは、限定された商用エンジンのサポートのみで動作するフレームワークを使用します。 これらのワークロードをオープンソースに移行することは、アプリケーションを完全に再設計するか、現在サポートされていない高度な機能を必要とします。 機能は移行が非常に難しく、非常に多くの作業時間を消費します。

カテゴリ5: (レガシーワークロード)

これらのワークロードは独自のプログラミングインターフェイスを使用してプログラムを実行します。 例として、Oracle OCIアプリケーションなどが含まれます。 これらは従来のワークロードであることが多く、顧客はこれらのプログラムのソースコードを持っていない可能性があります。 めったに移行されることはありません。

ワークロードの優先度付け

データベースのインベントリを中央のリポジトリに保存しておくと、SQLやスクリプティング言語のような手持ちのツールを使用してポートフォリオ評価を自動化できます。

Oracle

Oracleデータベースの利用が多い場合は、PL / SQLブロックを使用してデータベース内のスキーマをループし、SELECT ANY DICTIONARYが付与されたユーザーに提供される情報を抽出できます。 SQL * Plusを使用し、不要なシステム・スキーマを除外し、コンマで区切られた値のセットをローカル・ファイルmigration_candidates.csvに追加します。 複数のデータベースに適用するには、bashスクリプトまたはプログラムを使用してインベントリシステムまたはファイルから読み込み、スクリプトを繰り返し実行し、同一ファイルに書き込みます。 こちらリポジトリーからOracle用のサンプル・スクリプトをダウンロードできます。

SQL Server
SQL Serverデータベースの利用が多い場合は、SQLブロックを使用してデータベースから読み取り、MSDBおよびsysスキーマから選択する権限を持つユーザーに提供される情報を抽出できます。 SQL Serverデータベースに対してsqlcmdを使用してスクリプトを実行し、コンマ区切りの結果を取得して、ファイルシステムのローカルファイル(migration_candidates.csvなど)に書き込むことができます。 複数のデータベースに適用するには、PowerShellスクリプトまたはプログラムを使用してインベントリシステム、またはファイルから読み取り、同一ファイルに追加するスクリプトを繰り返し実行します。 こちらのリポジトリからSQL Serverのサンプルスクリプトをダウンロードできます。

スクリプトの出力のレビューとカテゴリー分け

すべてのデータベースから結果を取得したら、その結果をMicrosoft Excelまたは別のツールにロードして、データ内のパターンを探します。 次の例では、条件付きデータバーは、ワークロードを分類する際に検討する必要がある度合いを示します。 こちらのリポジトリからサンプルワークロードワークシートをダウンロードできます。

Reviewing-and-categorizing-script-output

カテゴリ 1

緑で強調表示されたいくつかのワークロードがカテゴリ1と見なされ、分析および移行のためにチームに割り当てる必要があります。 これらのワークロードには、移行が必要なコードオブジェクトがほとんどなく、独自の機能(リンクされたサーバー、ジョブ、索引ビューなど)をほとんど使用しないか、または使用しない単純なスキーマ(たとえば、表やビューの数が少ない)があります。

カテゴリ 2

前述のワークロード例では、黄色で強調表示されているカテゴリ2のワークロードがいくつかあることがわかります。これらのデータベースには、少なくともテストを行うために移行フェーズを延長する可能性のある、かなり多くのプロシージャーや多くの独自機能の利用があります。

カテゴリ 3

ワークロード例の1行目〜4行目には、カテゴリ3に分類されるオレンジ色のワークロードが表示されています。これらのデータベースは1,000以上のプロシージャーとファンクションがあり、複雑な構造とジョブやリンクサーバーなどの高度な機能を持っています。

チーム毎の課題

移行パイプラインの概要を確認したので、チームが作業にどのように取り組むか計画をすることができます。 次の例でチームAは、カテゴリ1の移行に重点を置いています。 彼らは迅速に幾つかの移行を完了、パイプラインを次々と移動させます。 チームBは、移行フェーズでは追加の時間を費やす必要があるカテゴリ2の移行を行い、チームCは、同じ時間枠でより複雑なカテゴリ3の移行の内1つを行うことになります。

各マイグレーションは、分析とスキーマ、データ、およびカットオーバーのためのアプリケーションの移行の計画までのすべての移行フェーズを実行します。 しかし、各チームは必要な作業量に基づいて異なるペースで動きます。

TeamComparison

まず、カテゴリ1の移行を対象にすることで、そこで学んだことを後のプロジェクトにすぐに反映させることができます。 大規模なプロジェクトを開始する場合は、拡大したプロジェクトに取り組む前に、チームに勢いを与えることになります。 すべてのプロジェクトを追跡し、作業のパイプラインを維持することで、チームの関与が維持され、全体の進捗状況に関連したステータスを把握することができます。 全体的な結果は、通常、プロジェクトの利害関係者にとって最大の関心事です。 こちらのリポジトリからサンプル計画シートをダウンロードできます。

まとめ

1つの作業としてオープンソースエンジンへの全体的な移行を見ると非常に難しい作業に感じるかもしれません。 作業を最初のハイレベルな評価段階で管理可能サイズに細分化し、最初に速移行可能な物をターゲットにし、全体的なステータスを報告することで、移行の作業パイプラインを管理しし、チームを時間通もしくは早期に作業を完了させることに集中させることができます。


About the Author

Wendy Neu has worked as a Data Architect with Amazon since January 2015. Prior to joining Amazon, she worked as a consultant in Cincinnati, OH helping customers integrate and manage their data from different unrelated data sources.

 

 

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

新機能 – DynamoDB VPCエンドポイントが出ました

今日(翻訳元記事2017年8月16日)からAmazon Virtual Private Cloud(VPC)Amazon DynamoDB用エンドポイントがすべてのAWSのリージョンでご利用いただけます。AWS Management ConsoleまたはAWS Command Line Interface(CLI  コマンドラインインターフェイス)を使用して、すぐにエンドポイントをプロビジョニングできます。DynamoDBのVPCエンドポイントには追加費用はかかりません。

多くのAWSをお使い頂いているお客様は、セキュリティまたは分離の理由からAmazon Virtual Private Cloud(VPC)内でアプリケーションを実行します。以前は、VPC内のEC2インスタンスがDynamoDBにアクセスできるようにするには、2つのオプションがありました。インターネットゲートウェイ(NATゲートウェイを使用するかインスタンスの公開IPを割り当てる)を使用するか、すべてのトラフィックをVPNまたはAWS Direct Connect経由でローカルインフラストラクチャにルーティングしてからDynamoDBに戻すことができます。これらのソリューションには両方ともセキュリティとスループットの関係があり、NACLまたはセキュリティグループを構成してDynamoDBだけへのアクセスを制限することは困難でした。下の画像は上記のパターンのアーキテクチャです。

エンドポイントの作成
DynamoDBのVPCエンドポイントを作成しましょう。DescribeVpcEndpointServices APIコールを使用して、指定したリージョンでエンドポイントがサポートされていることを確認できます。

aws ec2 describe-vpc-endpoint-services --region us-east-1
{
    "ServiceNames": [
        "com.amazonaws.us-east-1.dynamodb",
        "com.amazonaws.us-east-1.s3"
    ]
}

上記の結果により、これらのエンドポイントをサポートしていることを確認出来ました。私は自分のVPCの1つを指定して、CLIまたはコンソールからの操作で簡単にエンドポイントをプロビジョニングできます。コンソールの使い方はこれから説明します。

最初に、VPCコンソールに移動し、サイドバーの[Endpoint]を選択します。そこから「Create Endpoint」をクリックして、この便利なコンソールに遷移します。

エンドポイントのAWS Identity and Access Management (IAM) ポリシーセクションに気づくでしょう。これは、通常のIAMポリシーでDynamoDBがサポートする詳細なアクセス制御をすべてサポートし、IAMポリシー条件に基づいてアクセスを制限できます。

今の例ではこのVPC内のインスタンスはフルアクセスし出来るようにして、「次のステップ」をクリックします。

これは私のVPC内のルートテーブルのリストに、これらのルートテーブルのどれに私のエンドポイントを割り当てるかを尋ねています。いずれかを選択して[Create Endpoint]をクリックします。

コンソールの警告メッセージに注意してください。パブリックIPアドレスに基づいてDynamoDBにソース制限がある場合、DynamoDBにアクセスするインスタンスのソースIPはプライベートIPアドレスになります。

DynamoDBのVPCエンドポイントをVPCに追加した後のアーキテクチャは次のようになります。

これでおしまいです!とても簡単で無料で利用する事ができます。是非利用してみて下さい。詳細が必要な場合は、ここでドキュメントを読むことができます。

(SA 成田が翻訳しました。元記事はこちら