Category: Amazon Redshift*


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)

Amazon Redshiftクエリーモニタリングルールでクエリーワークロードを管理する

データウェアハウスのワークロードは多様性で知られています。これは、季節性や、往々にして高コストになりがちな探索的クエリー、SQL開発者のスキルレベルのばらつきなどによるものです。

Amazon Redshiftワークロード管理機能(WLM)を用いて優先度やリソース使用量を柔軟に管理することで、極めて多様なワークロード環境でも高い性能を得ることが可能となります。WLMによって、短時間で完了するクエリーが長時間実行されるクエリーのせいでキューに滞留するような状況を避けることができます。にも拘わらず、あるクエリーが不釣り合いな量のリソースを独占し、システム内のその他のクエリーを圧迫することが依然として起こり得ます。こうしたクエリーは、一般にrogue queryやrunaway queryと呼ばれます(訳者註:rogueはならず者、面倒を起こすといった意味、runawayは暴走の意で、ここでは一方的にリソースを占有し他のクエリーに影響を及ぼすクエリーを指します)

WLMは、メモリー使用量を制限し、タイムアウトを用いてクエリーを別のキューに移動させる機能を持ちますが、ずっと粒度の細かいコントロールができることが望ましいことは論を俟ちません。クエリーモニタリングルールを用いて、リソース使用量のルールを作成し、クエリーのリソース使用量を監視し、それらがルールを犯した時のアクションを決めることが可能になりました。

ワークロード管理における同時並列性とクエリーモニタリングルール

Amazon Redshift環境では、単一クラスターに対し最大500まで同時接続することができます。性能指標であるスループットは一般に一時間あたりのクエリー数として表現されますが、MySQLのような行指向データベースであれば、同時接続数を増やすことによってスケールします。Amazon Redshift環境では、ワークロード管理(WLM)によって、同時接続数とは異なる方法でスループットを最大化します。WLMは二つの部分があります。キューと同時並列性です。キューはユーザーグループまたはクエリーグループのレベルでのメモリー割り当てを可能にします。同時並列性(またはメモリースロット)は、この割り当てをさらにどのように分割し、個々のクエリーにメモリーを割り当てるかを制御します。

例えば、同時並列性10の1つのキューがある(メモリー割り当て100%)と仮定しましょう。これは、個々のクエリーは最大10%のメモリーの割り当てを受けることを意味します。もしクエリーの大半が20%メモリーを必要とした場合、これらのクエリーはディスクにスワップアウトし、スループットの劣化をもたらします。しかし、もし同時並列性を5に下げた場合、個々のクエリーは20%のメモリー割り当てを受けることができるため、トータルのスループットは高くなり、SQLクライアントへのレスポンスも全体的に高速になります。高い同時並列性がよりよいパフォーマンスに繋がると考えてしまうことは、行指向のデータベースを列指向に切り替える時に陥りがちな典型的な落とし穴の一つです。

同時並列性について理解したところで、クエリーモニタリングルールについて掘り下げていきましょう。リソース使用量に基づくルールと、それに違反した場合に取るアクションを定義します。当該クエリーによるCPU使用量、クエリー実行時間、スキャンされた行数、返された行数、ネステッドループ(Nested loop)結合など、12の異なるリソース使用量メトリクスを利用できます。

それぞれのルールは最大3つの条件(述語)と、一つのアクションを持ちます。

述語は、メトリック、比較演算子(=、<または>)、値で構成されます。あるルール内の全ての述語がマッチすると、そのルールのアクションがトリガーされます。ルールアクションには、ログ(記録)、ホップ(次のキューへの移動)、アボート(終了)があります。

これにより、はた迷惑なクエリーを、より深刻な問題が出来する前に捕捉することが可能になります。ルールはアクションをトリガーしてキューを解放し、スループットと応答性を改善します。

例えば、短時間実行クエリー専用のキューのために、60秒を超えて実行し続けるクエリーをアボートするルールを作ることができます。設計のよくないクエリーを追跡するために、ネステッドループを含むクエリーを記録する別のルールを作ることもできます。Amazon Redshiftコンソールには、簡単に始められるよういくつかのテンプレートが事前定義されています。

シナリオ

クエリーモニタリングルールを使って、単純なロギングからクエリーのアボートまで、幅広いクエリーレベルアクションを行うことができます。また、全てのアクションはSTL_WLM_RULE_ACTIONテーブルに記録されます。

それでは、以下の三つのシナリオを用いて、クエリーモニタリングルールをどのように使うかを見ていきましょう。

シナリオ1:アドホッククエリーに潜む非効率なクエリーを制御するには?

二つの大きなテーブルを結合するようなクエリーは、何十億、あるいはそれ以上の行を返す可能性があります。十億行を超える行を返すクエリーをアボートさせるルールを設定することで、アドホッククエリーの安全性を担保することができます。このルールは、論理的には以下のようになります。

IF return_row_count > 1B rows then ABORT

以下のスクリーンショットの設定では、十億行を超える行を返すBI_USERグループ内のクエリーはすべてアボートします。

シナリオ 2: 非効率で、CPUインテンシブなクエリーを制御するには?

CPUスパイクをもたらすクエリーが、必ずしも問題というわけではありません。しかし、高いCPU使用量と長いクエリー実行時間を併せ持ったクエリーは、実行中の他のクエリーのレイテンシーを悪化させます。例えば、高いCPU使用率を示し続ける非効率なクエリーが長時間実行されている場合、それは誤ったネステッドループ結合のせいかも知れません。

こうしたケースでは、10分間にわたって80%以上のCPU使用率を示しているクエリーをアボートさせるルールを作成することで、クラスターのスループットと応答性を上げることができます。このルールは、論理的には以下のようになります。

IF cpu_usage > 80% AND query_exec_time > 10m then ABORT

以下のスクリーンショットの設定では、10分間にわたってCPU使用率が80%を超えているクエリーはすべてアボートします。

80%以上のCPU使用率を5分以上続けるクエリーを記録し、10分以上続いた場合はアボートするよう、ルールを拡張することもできます。このルールは、論理的には以下のようになります。

IF cpu_usage > 80% AND query_exec_time > 5m then LOG and IF cpu_usage > 80% AND query_exec_time > 10m then ABORT

以下のスクリーンショットの設定では、5分間にわたってCPU使用率が80%を超えているクエリーは記録され、10分間にわたってCPU使用率が80%を超えているクエリーはすべてアボートします。

シナリオ 3:

進捗していないクエリーを監視し、記録するには?

例えば、ミックスワークロード環境では、ETLジョブがS3から大量のデータを抽出し、Amazon Redshiftにロードしているケースがあります。データ抽出中、キューでスタックして、全く進捗していないように見えるCOPYコマンドが見つかるかも知れません。このようなクエリーはデータ抽出を遅延させ、ビジネス上のSLAに悪影響を与える可能性もあります。

クエリーを追跡し記録するルールを作ることで、こうしたクエリーを捕捉することができます。低いCPU使用率のまま長時間実行されているクエリーを見つけ出すルール、例えば1%のCPU使用率で10分間動作しているようなクエリーを記録するルールを作成します。このルールは、論理的には以下のようになります。

IF cpu_usage < 1% AND query_exec_time > 10m then LOG

以下のスクリーンショットの設定では、10分間にわたってCPU使用率が1%未満であるクエリーが記録されます。

まとめ

Amazon Redshiftは強力かつフルマネージドなデータウェアハウスであり、高いパフォーマンスと低いコストの双方をクラウド上でご提供します。しかしながら、クラスターリソースを独り占めするクエリー(rogue queries)はユーザーエクスペリエンスに悪影響を及ぼします。

このポストでは、クエリーモニタリングルールがこの種のクエリーにどのように対処可能かを見てきました。これらの内容は、ミックスワークロード環境でのクラスター性能とスループットを最大化し、円滑なビジネス遂行を実現する上で役立つはずです。

ご質問やご提案がありましたら、以下にコメントを残していただけますと幸いです。

(翻訳はAWS Japanプロフェッショナルサービス仲谷が担当しました。原文はこちら

オンプレミスや Amazon EC2 上の Oracle Database を Amazon Redshift に移行

AWS Database Migration Service (AWS DMS) は、簡単かつ安全なAWSへのデータベース移行の手助けをします。AWS Database Migration Service は広く使われている商用データベースとオープンソースデータベースに対応しています。このサービスはOracleからOracleのような同一プラットフォームでの移行に対応していますし、Oracleから Amazon Aurora や、Microsoft SQL Server からMySQLのような異なるプラットフォーム間での移行にも対応しています。移行元のデータベースは移行中も完全に動作しつづけたままであり、データベースに依存するアプリケーションのダウンタイムを最小限に抑えます。

AWS Database Migration Service を使用したデータレプリケーションは、AWS Schema Conversion Tool (AWS SCT) と緊密に統合されており、異なるプラットフォーム間でのデータベース移行プロジェクトを簡略化します。異なるプラットフォーム間での移行には AWS SCT を使用できますし、同一プラットフォームであれば移行元エンジンの純正スキーマ出力ツールが使えます。

この投稿では、Oracle Database のデータウェアハウスから Amazon Redshift へのデータ移行にフォーカスします。

以前の AWS SCT では、Oracle Database のビューやファンクションなどのカスタムコードを Amazon Redshift と互換性のあるフォーマットに変換できませんでした。ビューとファンクションを変換するには、最初に Oracle Database スキーマをPostgreSQLに変換し、それから Amazon Redshift と互換性のあるビューとファンクションを抽出するスクリプトを実行する必要がありました。

お客様のフィードバックに基づいたアップデートの後、AWS SCT と AWS DMS を使用して Oracle Database のビューとファンクションを Amazon Redshift に移行できるようになりました。

次の図は移行手順を示しています。

準備

この移行を開始するには次の手順を実行します。

  • AWS SCT をダウンロード
  • AWS SCT グローバル設定 からデータベースドライバーをダウンロードし、そのパスを設定。
  • 米国西部(オレゴン)リージョンで使用できる Amazon EC2 キーペアを用意。持っていない場合は新しい Amazon EC2 キーペアを作成。

スタックの作成

この投稿では、AWS CloudFormation スタックを起動するために、以下の Launch Stack を使います。起動プロセス中に前述のアーキテクチャも作成されます。結果は AWS DMS コンソールで確認できます。移行が終わると、CloudFormationスタックは破棄できます。

このリンクは米国西部(オレゴン)リージョン (us-west-2) でスタックを開始します。

一部のリソースを使用されている間は料金が発生します。

Launch Stack

スタックを起動して名前を付けるには、次のようにします。

  1. AWSアカウントにまだログインしていない場合はログイン。
  2. Launch Stack を選んで、あらかじめ用意されたCloudFormationテンプレートでCloudFormationコンソールを起動。「次へ」を選択。
  3. スタック名には入力済みのorclrsmigrationを使用するかカスタム名を入力。KeyNameを選択し、Redshiftクラスター用のMasterUserPasswordを入力し、「次へ」を選択。
    Specify Details
  4. 確認ページにて、スタックの起動結果としてCloudFormationが AWS Identity and Access Management (IAM) ロールを作成することを確認。「作成」を選択。
    I acknowledge that AWS CloudFormation might create IAM resources with custom names.
  5. スタック作成の進行状況を確認するには更新ボタンを押し、起動イベントを表示するスタックを選択。
    Eventsタブ
  6. スタックが正常に起動すると、状況はCREATE_IN_PROGRESSからCREATE_COMPLETEに変わります。次のセクションで使用する値を表示するには「出力」を選択。
    Outputsタブ

このCloudFormationテンプレートによって作成されたインフラは、次のセクションで使用されます。以下のテーブルでリストされている値が表示されています。

Schema Conversion Tool での設定

Schema Conversion Tool での設定のために、以下を実行します。

  1. AWS Schema Conversion Tool を開始。
  2. Fileから New Project を選択。New Project ダイアログが表示される。
    New Project dialog
    次のプロジェクト情報を追加。

    Project Name プロジェクト名を入力。コンピュータにローカル保存される
    Location ローカルプロジェクトファイルの保存先を入力
    Data Warehouse (OLAP)
    Source DB Engine Oracle DW
    Target DB Engine Amazon Redshift
  3. AWS Schema Conversion Tool プロジェクトを作成するためOKを選択。
  4. Oracle Database に接続するため、Connect to Oracle DW を選択。

    Connect to Oracle DW ダイアログが表示される。移行元の Oracle Database 接続情報を入力。

    以下の値をフォームに入力。

    Server name <移行元EC2エンドポイントのDNS名>
    Server port 1521
    Oracle SID XE
    User name dms_sample
    Password dms_sample
    Use SSL チェックしない
  5. 移行元のデータベースに正しく接続できるかを確認するため、Test Connection を選択。
  6. 移行元データベースに接続するため、OKを選択。
  7. DMS_SAMPLEデータベースを選び、Nextを選択。
  8. Database Migration Assessment Report を読み、Nextを選択。

  9. Amazon Redshift に接続するため、Connect to Amazon Redshift を選択。

    Connect to Amazon Redshift ダイアログが表示される。移行先のデータベース接続情報を入力。

    以下の値をフォームに入力。

    Server name 移行先RedshiftエンドポイントのDNS名
    Server port 5439
    Database dev
    User name admin
    Password CloudFormationで選ばれたパスワード
    Use SSL チェックしない
  10. 移行先のデータベースにただしく接続できるかを確認するため、Test Connection を選択。
  11. 移行先データベースに接続するため、OKを選択。

スキーマを変換

次にスキーマを変換します。

  1. Viewを選び、Main View を選択。
  2. 移行元のデータベースのスキーマを表示している左側のパネルから変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Convert schema を選択。
  3. AWS Schema Conversion Tool でのスキーマ変換が完了すると、選択されたスキーマがビューやファンクションを含めて移行先の Amazon Redshift クラスター上で表示されます。この時点では、移行先の Amazon Redshift クラスターにスキーマは適用されていません。このウィンドウでスキーマを編集できます。編集したスキーマはプロジェクトの一部として保存されます。変換されたスキーマをデータベースに適用することを選択すると、編集されたスキーマが移行先DBインスタンスに書き込まれます。
  4. 移行先データベースのスキーマを表示する右側のパネルで、変換するdms_sampleスキーマオブジェクトを選択。オブジェクトのコンテキスト(右クリック)メニューを開き、Applyを選択。

この時点で、データが空の状態のデータベーススキーマが Amazon Redshift クラスター上にできあがります。

データベース移行のために AWS DMS を構成

次にDMSに移ります。

  1. AWSマネジメントコンソールでDMSを選び、「移行の作成」を選択。
  2. 「AWS Database Migration Service へようこそ」ページで「次へ」を選択。
  3. 「レプリケーションインスタンスの作成」ページが表示される。

    このページで以下の値を入力し、「次へ」を選択。

    名前 8から16文字のASCII文字によるレプリケーションインスタンスの名前(/、”、@を除く)
    説明 レプリケーションインスタンスの説明を入力
    インスタンスクラス dms.t2.medium
    VPC 使いたい Amazon Virtual Private Cloud (Amazon VPC) を選択。移行元または移行先または両方があるVPCを使う
    Multi-AZ いいえ
    パブリックアクセス可能 チェック
  4. 「アドバンスト」タブはデフォルトのままで、「次へ」を選択。

データベースエンドポイントの設定

  1. ソースエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン oracle
    サーバー名 <移行元EC2エンドポイントのDNS名>
    ポート 1521
    SSLモード none
    ユーザー名 dms_sample
    パスワード dms_sample
  2. ターゲットエンドポイントに以下の値を設定。
    エンドポイント識別子 エンドポイントを識別するために使いたい名前を入力
    ソースエンジン redshift
    サーバー名 <RedshiftエンドポイントのDNS名>
    ポート 5439
    SSLモード none
    ユーザー名 admin
    パスワード CloudFormationで選ばれたパスワード

レプリケーションインスタンスが正しく作成された後に「テストの実行」を選ぶことで、エンドポイントへの接続をテストできます。

タスクの作成

「タスクの作成」ページでタスクのオプションを設定します。

以下のテーブルはタスクの設定について説明しています。

タスク名 タスク名を入力
ソースエンドポイント 使用する移行元エンドポイントを選択
ターゲットエンドポイント 使用する移行先エンドポイントを選択
レプリケーションインスタンス 使用するレプリケーションインスタンスを選択
移行タイプ Migrate existing data
作成時にタスクを開始 チェックする

「ターゲットテーブル作成モード」は「何もしない」を選択。

「テーブルマッピング」ではdms_sampleを選び、Add selection rule を押して、「タスクの作成」を選択。

タスクの監視

タスクの作成で「作成時にタスクを開始」を選んだ場合、「タスクの作成」を選択するとすぐにデータ移行が開始されます。AWSマネジメントコンソールから実行中のタスクを選ぶことで、タスクの統計と監視の情報を表示できます。次のスクリーンショットはデータベース移行のテーブル統計を表しています。

まとめ

この投稿では Oracle Database の商用環境をビューやファンクションとともに Amazon Redshift に移行することがいかに簡単であるかをご紹介しました。


翻訳はソリューションアーキテクト柴田(シバタツ)が担当しました。原文は Migrating Oracle Database from On-Premises or Amazon EC2 Instances to Amazon Redshift です。

Amazon Redshiftのワークロード管理(WLM)を使ってミックスワークロードを実行する

ミックスワークロードの環境下では、ビジネス上の要求を満たすために、バッチとインタラクティブのワークロード双方が同時に実行されます。ミックスワークロードを管理し構成するには、アクセスパターンやシステムリソースの使われ方、およびパフォーマンス要件についての詳細な理解が必要です。

ミックスワークロードでは、一般に、一部のプロセスが他より高い優先順位を必要とします。あるケースでは、これはあるジョブが特定の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-Picture 1

WLM最適化クラスター構成のガイドライン

1. 複数のビジネスワークロードを分離し、クエリーを互いに独立して実行する。

ダッシュボードクエリーとETLといった異なるビジネスプロセスをサポートするため、互いに独立したキューを作成します。例えば、ワンタイムクエリーのための独立したキューを作成することは、それらのクエリーがより重要なETLジョブを阻害しないようにするための有益なソリューションと言えます。

また、より短時間で実行されるクエリーは一般的にメモリー使用量が少ないため、それらのワンタイムユーザーやクエリーグループ用のキューには、より低いWLM使用メモリー比率(訳者註:マネジメントコンソール上の”メモリ(%)”の設定値)を設定することができます。

2. 同時実行数やメモリー割り当てをアクセスパターンに合わせてローテーションする。(適合するユースケースの場合)

トラディショナルなデータ管理では、ETLジョブはソースシステムから特定のバッチウィンドウ内でデータを取得、整形した後、ターゲットのデータウェアハウスにロードします。このアプローチでは、業務時間中は、BI_USERグループにより多くの同時実行数とメモリを割り当て、ETL_USERには非常に限られたリソースのみを割り当てます。業務時間後は、重くリソースインテンシブなジョブが迅速に完了するよう、ETL_USERへの割り当てを動的に変更またはスイッチすることを、クラスターの再起動なしに行うことが可能です。

注:下記のAWS CLIコマンドサンプルはデモ目的のために、複数の行で表示されています。実際のコマンドは改行を挟まず一行で実行する必要があります。また、下記のJSON構成にはエスケープクォートが必要です。

Redshift_Workload_2

WLM設定を動的に変更する方法として、AWSはスケジュールされたLambda関数あるいはスケジュールされたデータパイプライン(ShellCmd)をお勧めします。

3. ミックスワークロード(ETLとBIワークロード)を継続的にサポートないし最適化するために、キューホッピングを使用する

WLMキューホッピングは、読み取り専用クエリー(BI_USERのクエリー)が、キャンセルされる代わりにあるキューから別のキューに移動することを可能にします。例えば、以下のスクリーンショットにあるように、二つのキュー(一つはタイムアウトが60秒に設定されたインタラクティブクエリー用のもの、もう一つはタイムアウトなしで設定されたバッチクエリー用のもの)を作成し、同じユーザーグループ(BI_USER)をそれぞれのキューに設定します。WLMは、インタラクティブキューで実行され、タイムアウトしたBI_USERのクエリー(のみ)を、バッチキューに自動的に再ルーティングし再実行します。WLM-Picture 2

この例では、ETLワークロードはBIワークロードクエリーを阻害しません。長時間実行されている読み取り専用クエリーは、自動的にバッチとして分類され、より短時間で完了するクエリーをブロックしないようになります。

4. リソースインテンシブなETLやバッチクエリー用に、スロットカウントを一時的に増やす。

Amazon Redshiftはメモリー不足エラーを回避するために中間結果をディスクに書きますが、ディスクI/Oはパフォーマンスを劣化させる要因となります。次のクエリーは、ディスク上で実行されているアクティブクエリーを表示します。

SELECT query, label, is_diskbased FROM svv_query_state WHERE is_diskbased = 't';

クエリーの結果は以下の通りです。

query | label        | is_diskbased
-------+--------------+--------------
1025   | hash tbl=142 |      t

一般的に、ハッシュ、集計、ソートの操作は、システムが十分なメモリーをクエリー処理に割り当てなかった場合、ディスクにデータを書く可能性が高くなります。この問題を回避するには、その処理が使用するクエリースロットの数を一時的に増やすことで、より多くのメモリーを割り当てます。例えば、同時実行レベルが4であるキューは、4つのスロットを持っています。この時、スロットカウントを4に設定すると、単一のクエリーがそのキューの持つ全ての利用可能メモリーを使うことができるようになります。なお、複数のスロットを単一クエリーに割り当てると、同時実行数が消費され、他のクエリーが実行できなくなり得る点に注意して下さい。

以下の例では、クエリーを実行する前にスロットカウントを4にセットし、クエリー完了後、1に戻しています。

 

SQL
set wlm_query_slot_count to 4;
select
	p_brand,
	p_type,
	p_size,
	count(distinct ps_suppkey) as supplier_cnt
from
	partsupp,
	part
where
	p_partkey = ps_partkey
	and p_brand <> 'Brand#21'
	and p_type not like 'LARGE POLISHED%'
	and p_size in (26, 40, 28, 23, 17, 41, 2, 20)
	and ps_suppkey not in (
		select
			s_suppk
                                  from
			supplier
		where
			s_comment like '%Customer%Complaints%'
	)
group by
	p_brand,
	p_type,
	p_size
order by
	supplier_cnt desc,
	p_brand,
	p_type,
	p_size;

set wlm_query_slot_count to 1; -- after query completion, resetting slot count back to 1

注: 上記のTPC データセットクエリーは例示のみを目的としています。

WLMクエリーの例

以下のサンプルクエリーは、お客様がご自身のワークロードに関してお持ちの、以下のような疑問への回答となるかも知れません。

  • 現在のクエリーキュー構成は?クエリースロット数や、それぞれのキューのタイムアウト設定はどうなっているか?
  • いくつのクエリーが実行され、キューに到達し、また現在クエリーキュー上で実行されているか?
  • 我々のワークロードは、各クエリーキュー上で毎時どの程度滞留しているか?負荷に応じて、構成を変更する必要があるか?
  • 我々の既存のWLM構成はどのように動作しているか?どのクエリーキューがビジネス上の要求に対して最適化される必要があるか?

WLMは、内部で定義されたWLM”サービスクラス”に応じて、クエリーキューを構成します。”キュー”と”サービスクラス”の用語は、システムテーブル内でほぼ同義に使われます。

Amazon Redshiftは、WLM構成で定義されたキューと共に、これらのサービスクラスに応じたいくつかの内部キューを作成します。それぞれのサービスクラスは一意のIDを持ちます。サービスクラス1 – 4はシステム用途に予約されています。スーパーユーザーキューはサービスクラス5を使用します。ユーザー定義のキューはサービスクラス6以上を使用します。

クエリー:既存のWLM構成

既存のWLM構成を確認するためには、以下のクエリーを実行します。4つのキューが構成され、それぞれのキューはある数字に割り当てられています。クエリーでは、キュー番号はサービスクラスにマップされ(ETL_USER用の1番目のキューはサービスクラス6にマップされている)、evictableフラグ(*)はfalseに設定されています(クエリータイムアウトが設定されていない)。

*訳者註:evictは“立ち退き”の意で、ここではキューホッピングを意味しています。

SQL
select service_class, num_query_tasks, evictable, eviction_threshold, name
from stv_wlm_service_class_config
where service_class > 5;
Redshift_Workload_4

上記のクエリーは現在のWLM構成についての情報を提供します。このクエリーはLambdaを使用して自動化し、WLMに変更が発生した都度、運用チームに通知を送ることが可能です。

クエリー: キュー状態

キューの状態、各キューに対するメモリー割り当て、および各キューに対して実行されたクエリーをモニタリングするには、以下のクエリーを実行します。このクエリーは、カスタムキューとスーパーユーザーキューについての情報を提供します。

SQL
select config.service_class, config.name
, trim (class.condition) as description
, config.num_query_tasks as slots
, config.max_execution_time as max_time
, state.num_queued_queries queued
, state.num_executing_queries executing
, state.num_executed_queries executed
from
STV_WLM_CLASSIFICATION_CONFIG class,
STV_WLM_SERVICE_CLASS_CONFIG config,
STV_WLM_SERVICE_CLASS_STATE state
where
class.action_service_class = config.service_class
and class.action_service_class = state.service_class
and config.service_class > 5
order by config.service_class;

Redshift_Workload_5

上記の結果からは、サービスクラス9は使用されていないことが伺えます。このことは、デフォルトキューに割り当てるリソース(同時実行数とメモリー)を最小限に押さえることができることを意味します。サービスクラス6(etl_group用)はより多くのクエリーを実行しているため、より多くのメモリーや同時実行数を割り当てることを検討してもよいかも知れません。

クエリー: 前回のクラスター再起動後の状況

前回のクラスター再起動後から現在までに完了または実行中のクエリーの数をサービスクラスごとに確認するには、以下のクエリーを実行します。

SQL
select service_class, num_executing_queries,  num_executed_queries
from stv_wlm_service_class_state
where service_class >5
order by service_class;

Redshift_Workload_6
サービスクラス9は使用されていません。サービスクラス6(etl_group用)は他のサービスクラスより多くのクエリーを実行しています。クエリー処理を高速化するために、このグループ用のメモリーや同時実行数を変更することを検討した方がよいでしょう。

クエリー: 各WLMキューの時間ごとのワークロード

各WLMクエリーキューの時間ごとのワークロードを確認するには、以下のクエリーを実行します。このクエリーを使用して、WLMキューの最適化を行うことが可能です。少なすぎるスロットや多すぎるスロットを含んだキューは、WLMでのキューイングや、未使用のクラスターメモリーに繋がります。このクエリー(wlm_apex_hourly.sql)は、amazon-redshift-utils GitHubレポジトリーからコピーできます。

SQL
WITH
        -- Replace STL_SCAN in generate_dt_series with another table which has > 604800 rows if STL_SCAN does not
        generate_dt_series AS (select sysdate - (n * interval '1 second') as dt from (select row_number() over () as n from stl_scan limit 604800)),
        apex AS (SELECT iq.dt, iq.service_class, iq.num_query_tasks, count(iq.slot_count) as service_class_queries, sum(iq.slot_count) as service_class_slots
                FROM
                (select gds.dt, wq.service_class, wscc.num_query_tasks, wq.slot_count
                FROM stl_wlm_query wq
                JOIN stv_wlm_service_class_config wscc ON (wscc.service_class = wq.service_class AND wscc.service_class > 4)
                JOIN generate_dt_series gds ON (wq.service_class_start_time <= gds.dt AND wq.service_class_end_time > gds.dt)
                WHERE wq.userid > 1 AND wq.service_class > 4) iq
        GROUP BY iq.dt, iq.service_class, iq.num_query_tasks),
        maxes as (SELECT apex.service_class, trunc(apex.dt) as d, date_part(h,apex.dt) as dt_h, max(service_class_slots) max_service_class_slots
                        from apex group by apex.service_class, apex.dt, date_part(h,apex.dt))
SELECT apex.service_class, apex.num_query_tasks as max_wlm_concurrency, maxes.d as day, maxes.dt_h || ':00 - ' || maxes.dt_h || ':59' as hour, MAX(apex.service_class_slots) as max_service_class_slots
FROM apex
JOIN maxes ON (apex.service_class = maxes.service_class AND apex.service_class_slots = maxes.max_service_class_slots)
GROUP BY  apex.service_class, apex.num_query_tasks, maxes.d, maxes.dt_h
ORDER BY apex.service_class, maxes.d, maxes.dt_h;

本ポストの主旨に基づき、結果はサービスクラスごとにブレイクダウンされています。

Redshift_Workload_7

上記の結果からは、サービスクラス6が24時間を通じて、コンスタントに最大8までのスロットを消費していることが伺えます。この数字を見る限り、このサービスクラスへの変更は現時点では特に必要ありません。

Redshift_Workload_8

サービスクラス7は、上記の結果に基づき最適化することが可能です。

二つの点が観察できます。

  • 朝6時から午後3時まで、あるいは午後6時から翌朝6時まで:消費されている最大スロットは3です。これらのアクセスパターンに基づいて、同時実行数とメモリー割り当てをローテーションする余地があります。リソースのローテーションについて詳しくは、本ポストのガイドラインセクションの項を参照して下さい。
  • 午後3時から午後6時まで:この期間にピークの発生が観察されます。この時間帯については、現在の設定のままで構いません。

まとめ

Amazon Redshiftは強力かつ完全に管理されたデータウェアハウスであり、高いパフォーマンスと低いコストの双方をクラウド上でご提供します。WLM機能を用いることで、クラスター上で動作する異なるユーザーとプロセスが、それぞれのパフォーマンスとスループットを最大化するための適切な量のリソースを得られることを担保することができます。

ご質問やご提案がありましたら、以下にコメントを残していただけますと幸いです。

著者について

Suresh_90Suresh AkenaはAWS Professional ServiceのシニアBig Data/ITトランスフォーメーションアーキテクト。SureshはAWSプラットフォームへのマイグレーション、ビッグデータ、分析プロジェクトを含む巨大データストラテジーのリーダーシップをエンタープライズカスタマーに提供し、AWSを使ったデータドリブンアプリケーションの最適化や市場に出るまでにかかる時間の改善を支援しています。余暇には8才と3才の娘達と遊び、映画を楽しんでいます。

(翻訳はプロフェッショナルサービス仲谷が担当しました。原文はこちら


関連記事:Amazon Redshiftのパフォーマンスチューニングテクニック Top 10

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 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

Redshiftアップデート:列や表の名前に日本語が使用できるように

Amazon Redshift で列や表、もしくはビューといったオブジェクトの名前として日本語が利用可能になりました!これは以前から日本のお客様からご要望いただいていた機能ですので、以下で説明します。

Redshiftはこれまではデータとしては日本語を含むマルチバイト文字を格納可能でしたが、表や列の名前には使用できませんでした。これが改善され、Redshift v1.0.1122からは日本語のテーブル名や列名が利用可能になります。利用する前にご自身のRedshiftクラスターが1.0.1122以降に更新されているかをご確認ください。

列や表の名前は最大で127バイトまで利用でき、文字はUTF-8で保存されます(日本語の漢字やひらがなは1文字を表現するのに3バイト必要です)。以下のドキュメントも更新されています。現時点では日本語翻訳はまだ更新されていないので、英語に切り替えてご覧ください。

なおマルチバイト文字のテーブル名や列名を使用する場合は、RedshiftのJDBCドライバー 1.2.1以降、ODBCドライバー 1.3.1以降にアップデートする必要がある事に注意してください。どちらもRedshiftのマネジメントコンソールから、もしくは以下のリンクよりダウンロードが可能です(こちらも英語にしてご覧ください)。名前のマルチバイト対応だけでなく、バグフィックスや機能向上を含みますのでぜひこの機会にドライバを最新に更新して御利用ください。

RedshiftはPostgreSQLとの互換性がありますので、既存のPostgreSQLのJDBC/ODBCドライバやpsqlコマンドでの接続も可能です。パフォーマンスや機能の面から上記のRedshift専用ドライバの利用が強く推奨されますが、試しに手元の環境でpsqlコマンドでRedshift v1.0.1122に接続してみたところ、問題なく日本語のテーブル名や列名が利用できました。

下佐粉 昭(@simosako