Author: AWS Japan Staff


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ついてはこちらをご覧下さい。

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

新インスタンス- NVIDIA Tesla V100 GPUを最大8個搭載したAmazon EC2インスタンス P3

私たちは2006年に最初のm1.smallを発表した後も、お客様のご要望に応じて、そして常に進歩している最先端の技術を利用可能にするために、コンピュート能力、バースト可能な性能、メモリサイズ、ローカルストレージ、アクセラレータなどインスタンスを強化し続けています。

新しいP3インスタンス
本日、次世代のGPUを搭載したEC2インスタンスを4リージョンで公開しました。NVIDIA Tesla V100 GPUを最大8個搭載したP3インスタンスは、コンピュートインテンシブな機械学習、深層学習、流体計算、金融計算、地震解析、分子計算、ゲノム処理を想定して設計しました。

P3インスタンスは、最大2.7GHzで動作するIntel Xeon E5-2686v4プロセッサを搭載し、3種類のサイズを用意しています(VPCのみ、EBSのみ)

Model NVIDIA Tesla V100 GPUs GPU Memory NVIDIA NVLink vCPUs Main Memory Network Bandwidth EBS Bandwidth
p3.2xlarge 1 16 GiB n/a 8 61 GiB Up to 10 Gbps 1.5 Gbps
p3.8xlarge 4 64 GiB 200 GBps 32 244 GiB 10 Gbps 7 Gbps
p3.16xlarge 8 128 GiB 300 GBps 64 488 GiB 25 Gbps 14 Gbps

各GPUは 5,120CUDAコアと640Tensorコアを備え、最大125TLOPSの混合精度浮動小数点演算、15.7TFLOPSの単精度浮動小数点演算、7.8TFLOPSの倍精度浮動小数点演算を可能とします。大きい2つのサイズでは、GPUはNVIDIA NVLink 2.0で相互接続され、最大300Gbpsデータレートで接続されています。これによりGPU間での中間結果やその他のデータのやりとりを、CPUやPCI-Expressを経由せずに高速に行うことが可能です。

Tensorコアとは?
このブログを書き始めるまで、私はTensorコアを聞いたことがありませんでした。大変有益なNVIDIA ブログの記事によると、Tensorコアは大きなDeep Neural Networkの学習や推論を高速化するために設計されています。各コアは、半精度(FP16)の4×4行列同士の積演算と、4×4の別の半精度もしくは単精度(FP32)行列の和演算を行い、半精度もしくは単精度の4×4行列の演算結果を保存することができます。以下にNVIDIAのブログ記事から図を転載します:

この操作は、Deep Neural Networkの学習処理において最も内部のループ処理であり、現在のGPUハードウェアが特定の市場のニーズに対して特化してどのように動作しているかを示しています。そして、Tensorコアの混合精度の性能は、16bitと32bitの浮動小数点の組み合わせを柔軟に扱えることを意味しています。

性能

実際の性能数値を提示することは、より簡易に実際のアプリケーションと関連づけられ、有意義だと考えています。8個のV100 GPUを搭載したp3.16xlargeでは、驚くことに単精度浮動小数点の乗算を1秒に125兆回可能です。

マイクロプロセッサの歴史を振り返って、1977年の夏に私が買ったIntel 8080Aチップを搭載したMITS Altairを考えてみます。2MHzクロックで秒間832回の乗算が可能でした。(このデータを使い、より速いクロックスピードに訂正しました)。p3.16xlargeは約1500億倍も高速です。しかし、その夏から12億秒が経過しました。言い換えると、過去40年に私のAltairが行なった計算に比べ、100倍以上の計算を1秒に実行することが可能となっています!

IBM PC用の追加オプションとして1981年の夏に発表された、革新的な8087数値演算コプロセッサーはどうでしょうか? 5MHzクロックで目的に特化したハードウェアで、秒間52,632回の乗算が可能でした。発表から11.4億秒が経ちましたが、p3.16xlargeは23.7億倍も高速で、当時の小さく貧弱なPCではまだ計算途中の演算が、今日では1秒で可能です。

では、Cray-1はどうでしょう?1976年に発表された最初のスーパーコンピューターは、160MFLOPSのベクトル演算が可能でしたが、p3.16xlargeは781,000倍高速です。当時に比べ、1500回も興味深い問題を繰り返し計算することが可能です。

P3と現在のスケールアウト型スーパーコンピュータの比較は難しくなっています。 スーパーコンピュータのコンポーネントとしてP3を捉え、必要に応じて使うことが可能です。

今すぐ起動できます
V100 GPUとTensorコアの利点を全て享受するには、CUDA 9cuDNN 7が必要です。これらのドライバやライブラリは最新のWindows AMIに追加されており、Amazon Linux AMIにも11月7日に追加予定です。新しいパッケージはAWSのリポジトリで利用可能ですので、必要に応じてすでに利用中のAmazon Linux AMIにインストールできます。

最新のAWS Deep Learning AMIには、Apache MxNet、Caffe2、Tensorflow(それぞれがNVIDIA Tesla V100 GPUをサポート)の最新リリースがプリインストールされており、Microsoft Cognitive ToolkitやPyTorchなどの他の機械学習フレームワークがNVIDIA Tesla V100 GPUのサポートをリリースするとすぐに、P3インスタンスをサポートするように更新されます。また、NVIDIA Volta Deep Learning AMI for NGCを使用することもできます。

P3インスタンスは、米国東部(バージニア北部)、米国西部(オレゴン)、欧州(アイルランド)、アジアパシフィック(東京)のリージョンにて、オンデマンド、スポット、リザーブドインスタンス、Dedicated Hostとして利用可能です。

Jeff;

原文はこちらです。

Amazon Elasticsearch Service が VPC をサポート

本日より、NAT インスタンスやインターネットゲートウェイを必要とせずに Amazon VPC から Amazon Elasticsearch Service ドメインに接続できるようになりました。Amazon ES の VPC サポートは設定も簡単で信頼性が高く、セキュリティをさらに強化することができます。VPC サポートでは、その他のサービスと Amazon ES 間のトラフィックはパブリックインターネットから分離されており AWS ネットワーク内で維持されます。既存の VPC セキュリティグループを使用してネットワークアクセスを管理できます。また、AWS Identity and Access Management (IAM) ポリシーを使って保護機能を強化することもできます。Amazon ES ドメインの VPC サポートは追加費用なしにご利用いただけます。

ご利用開始にあたって

VPC での Amazon Elasticsearch Service ドメインの作成は簡単です。クラスター作成に使ういつもの手順を行い [VPC access] を選択します。

これだけです。その他の手順はありません。これで VPC からドメインにアクセスできるようになりました。

主要事項

VPC をサポートするにあたり、Amazon ES は少なくても 1 つの VPC サブネットにエンドポイントを配置します。Amazon ES はクラスター内の各データノードの VPC に Elastic Network Interface (ENI) を配置します。各 ENI はサブネットの IPv4 範囲内からプライベート IP アドレスを使用し、パブリック DNS ホスト名を受け取ります。ゾーン対応を有効にすると、Amazon ES は異なるアベイラビリティーゾーンで 2 つのサブネットにエンドポイントを作成することで、より優れたデータの耐久性を提供しています。

クラスター内のノード数には IP アドレスの三倍の数を確保しておく必要があります。ゾーン対応を有効にしている場合は、その数を分割できます。Amazon ES 専用の別のサブネットを作成するのが理想的です。

注意点:

  • 現在、既存のドメインを VPC に移動することはできません (その逆も同様)。VPC サポートを利用するには、新しいドメインを作成しデータを移行してください。
  • 現時点で Amazon ES は VPC 内にあるドメインの Amazon Kinesis Firehose をサポートしていません。

詳しくは「Amazon ES ドキュメント (Amazon ES documentation)」をご覧ください。

Randall

Amazon Lightsail の更新 – Windows 仮想プライベートサーバーの起動と管理

Amazon Lightsail については、去年公開したブログ「Amazon Lightsail – AWS のパワーと VPS のシンプルさ (Amazon Lightsail – the Power of AWS, the Simplicity of a VPS)」でご紹介しました。昨年の公開以来、何千人ものユーザーがこの Lightsail を使用して AWS の利用を始めたり、Linux ベースの仮想プライベートサーバーを起動するようになりました。

そして本日より、Window 仮想プライベートサーバーのサポートも追加しました。ほんの数分で、Windows Server 2012 R2 を実行している VPS や Windows Server 2016SQL Server 2016 Express を使う Windows Server 2016 を起動することができます。VPS を使用して、インフラストラクチャのセットアップや実行を必要とせずに .NET または Windows のアプリケーションを構築、テスト、デプロイすることができます。1 回または 2 回クリックするだけで、バックアップ、DNS 管理、オペレーションメトリクスにアクセスできます。

512 MB から 8 GB の RAM、1 または 2 vCPU、最大 80 GB までの SSD ストレージなど、サーバーには 5 つのサイズがあります。料金は 10 USD/月額からご用意しています (ソフトウェアライセンスを含む)。

512 MB サーバーを 1 か月間無料でご利用いただけます (最大 750 時間まで)。

Windows VPS の起動
Windows VPS を起動するには、Lightsail にログインし [Create instance] をクリックして [Microsoft Windows] プラットフォームを選択します。次に SQL Server 2016 Express を実行したい場合は [Apps + OS] をクリックします。Windows だけの場合は [OS Only] を選択します。

初回起動の後に Powershell スクリプトを使用してインスタンスをカスタマイズしたい場合は [Add launch script] をクリックしてスクリプトを入力します。

ご希望のインスタンスプランを選び、インスタンス名を入力してから起動する量を選択し [Create] をクリックします。

1 分ほどでインスタンスが実行されます。

インスタンスをクリックして [Connect using RDP] をクリックします。

これで組み込みブラウザベースの RDP クライアントを使用し接続を実行します (IP アドレスと別のクライアントの認証情報を使用することも可能)。

今すぐ利用可能
この機能は米国東部 (バージニア北部)米国東部 (オハイオ)米国西部 (オレゴン)欧州 (ロンドン)欧州 (アイルランド)欧州 (フランクフルト)アジアパシフィック (シンガポール)アジアパシフィック (ムンバイ)アジアパシフィック (シドニー)アジアパシフィック (東京) の各リージョンでご利用いただけます。

Jeff;

アイテリジェンスとAWSが協力してSAP顧客に価値を提供

itelligence(アイテリジェンス)とAWS: AWSクラウドを介してグローバルにSAPの価値とソリューションを提供することに注力している新しいAmazon Partner Network(APN)メンバーをご紹介します。
この記事は、Amazon Web Services(AWS)でSAP担当ジェネラルマネージャーを務めるBas Kamphuisによるものです。

 

https://www.prnewswire.com/news-releases/itelligence-announces-collaboration-with-amazon-web-services-for-cloud-solutions-300540532.html

 

世界中のトランザクションの76%がSAPシステムと何らかの形でつながっており、SAP社は引き続きERP(Enterprise Resource Planning)市場の首位を占めています。SAP社の主力ソフトウェア製品であるSAP ECC(ERP Central Component)をお使いの数万のお客様の100%が、このリリースのメンテナンスが終了する2025年までには、どこかに移行することになっているでしょう。これは、SAP S/4HANAやSAP BW/4HANAのような、インメモリデータベースSAP HANAによって強化されたイノベーションを促すためです。この変化の誘発により、SAPをご利用中のお客様とパートナーエコシステム全体が、SAPランドスケープを戦略的に見て、どのようにSAP HANAでデジタル変革を実現できるのか明確にすることを迫られています。

世界で最も成功しているSAPグローバルパートナーの1社であるアイテリジェンスは、現在SAPをご利用中のお客様の多くが直面しているこの状況と複雑さを理解しています。大規模なグローバル組織にサービスを提供し、何十年にもわたってSAP環境を実装、維持してきました。アイテリジェンスとAWSのパートナーシップは、賞を受賞するほどのSAPの実装および運用における専門知識と組み合わせて、お客様がAWSクラウドの利点(伸縮性、弾力性、セキュリティ、グローバルスケールなど)を享受できるよう注力していきます。お客様は、既存のビジネスオペレーションのリスクや混乱を招くことなく、今すぐAWSとSAPが提供するイノベーションの恩恵を受けることができます。

私たちの継続した協調では、SAPのイノベーションの活用、選択肢の拡大、コストの削減、そして価値の創造に費やす時間の短縮など、お客様が求める敏捷性を実現するためにお役立ていただける、AWSで加速するアイテリジェンスのより多くのオファリングの提供を目指しています。

現在、お客様にご活用いただけること:

  • AWSにデータセンターを移設して、オンプレミスの設備投資を廃止
  • ツールとベストプラクティスを活用して数週間かかっていたSAPシステム移行を数日で実施
  • 複数地域にまたがるビジネス継続性と災害復旧のアーキテクチャを活用して、企業のセキュリティを強化し、弾力性を向上
  • SAP HANA認定パブリッククラウドの中で最大の品揃えを持つAWS上に本稼働環境を移行し、SAPランドスケープを統合

また、アイテリジェンスのマネージドサービスにAWSを組み込むことで、お客様のIT環境の複雑さを軽減することができます。私たちは連携して、お客様のSAP環境を積極的に自動化、監視および保守するために、人工知能、機械学習やビッグデータなどのAWSサービスを統合していく計画があります。

私たちはアイテリジェンスとの関係について非常に興奮しており、SAPをご利用中のお客様に引き続き最高のソリューションとオファリングを提供するための共同イノベーションを続けていきます。AWS組織全体を代表して、私たちはアイテリジェンスのチームのコミットメントとリーダーシップに感謝を述べたいと思います。Amazon Partner Networkへようこそ。

Bas

翻訳はPartner SA 河原が担当しました。原文はこちらです。

今すぐご利用可能 – 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;

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

 

 

 

【開催報告】第10回 AWS Startup Tech Meetup

こんにちは、ソリューションアーキテクトの篠原英治(@shinodogg)です。

AWSをご利用のStartup企業で働くエンジニアを対象とさせていただいているAWS Startup Tech Communityですが、10回目のMeetupを2017年10月19日にAmazon目黒オフィスで開催しました。カジュアルな雰囲気の中、各セッションともに実践的なQ&Aのやり取りで盛り上がり、私たちAWSの人間も含めた参加者の皆さま同士の非常に濃い学びの場となりました。

– Speee 森岡さん: ヌリカエのデータ集積基盤 on AWS

外壁塗装・屋根塗装の優良業者紹介サービスであるヌリカエのAmazon Kinesis Firehose、Amazon Athena、Amazon QuickSightを活用したデータ基盤について発表していただきました。

– freee 九岡さん: Kubernetes on AWS

全自動クラウド会計ソフトのfreeeにジョインされた九岡さんにk8sをAWS上で稼働させる際の考慮事項やTIPSについて発表していただきました。

– Lightning Talks

AWS 桑野

海外のAWSリージョンの活用方法をご紹介しました。

AWS 高山

リザーブドインスタンスの活用方法をご紹介しました。

pixiv 小芝さん

pixivにおけるAWSの活用についてご紹介いただきました。

– ネットワーキング

セッション以外の時間でも参加者の皆さま同士での活きたノウハウの共有が行われました。写真左:Gunosy小出さん、写真右:Sansan間瀬さん。

先日一周年を迎えたVoicy窪田さんとAWSソリューションアーキテクトの福井と半場。

– 次回開催に向けて

AWSをご利用のStartup企業のエンジニアの皆さまをお招きして、カジュアルにディスカッションできる場として、次回は年明け頃に開催予定です。我こそは!というStartupエンジニアの方は是非お近くのAWSジャパンの人間にお気軽にお声がけください。

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 プロフェッショナルサービス仲谷が担当しました。)