Author: AWS Japan Staff


AWS 料金値下げ – EC2 の SQL Server Standard Edition

AWS は 62 回目となる値下げを発表いたします。今回の対象は EC2 の Microsoft SQL Server Standard Edition です。多くのエンタープライズワークロード (特にオンプレミスまたは企業データセンター) は、Microsoft Windows で実行されています。そのグローバルな展開およびパートナーエコシステムによって支えられたサービスの幅広さにより、Windows アプリケーションの構築、デプロイ、スケール、管理には AWS が最適な場所であると考えています。

AdobePitney Bowesデブリー大学といったお客様は、すべて中核となる実稼働 Windows Server ワークロードを AWS に移行済みです。これらのお客様のアプリケーションは、SharePoint サイトからカスタム .NET アプリケーションや SAP まで広範囲に実行しており、頻繁に SQL Server を使用しています。AWS の Microsoft SQL Server は EC2 Windows インスタンスで実行され、お客様のアプリケーション開発および移行をサポートできます。リレーショナルデータベースをオンプレミスで実行している場合のように、すべての設定を管理でき、32 ビットおよび 64 ビットバージョンのサポートがあります。本日、R4、M4、I3、X1 インスタンスで実行される EC2 上の Microsoft SQL Server Standard Edition のオンデマンドおよびリザーブドインスタンスの料金を、インスタンスタイプ、サイズ、リージョンに応じて最大 52% 値下げします。エンタープライズ規模のアプリケーション、大規模にスケーラブルなウェブサイト、モバイルアプリケーションを、以前よりはるかにコスト効果の高い方法で構築および実行できます。リージョンおよびインスタンスタイプごとの最大の値下げ率を次に示します。

リージョン R4 M4 I3 X1
US East (Northern Virginia) -51% -29% -50% -52%
US East (Ohio) -51% -29% -50% -52%
US West (Oregon) -51% -29% -50% -52%
US West (Northern California) -51% -30% -50%
Canada (Central) -51% -51% -50% -44%
South America (Brazil) -49% -30% -48%
Europe (Ireland) -51% -29% -50% -51%
Europe (Frankfurt) -51% -29% -50% -50%
Europe (London) -51% -51% -50% -44%
Asia Pacific (Singapore) -51% -31% -50% -50%
Asia Pacific (Sydney) -51% -30% -50% -50%
Asia Pacific (Tokyo) -51% -29% -50% -50%
Asia Pacific (Seoul) -51% -31% -50% -50%
Asia Pacific (Mumbai) -51% -33% -50% -50%

オンデマンドインスタンスの値下げされた新料金は、2017 年 7 月 1 日に有効になります。リザーブドインスタンスの新料金は本日有効になります。

Jeff;

EC2 Container ServiceのBlue/Greenデプロイメント

この投稿と付随するコードの作成には、下記3名による多大な貢献がありました。

Jeremy Cowan
Solutions Architect
Anuj Sharma
DevOps Cloud Architect
Peter Dalbhanjan
Solutions Architect

コンテナ化されていないトラディショナルな環境にソフトウェアアップデートを展開するのは難しく、リスクを伴います。デプロイパッケージまたはスクリプトを記述するときは、ターゲットマシンが特定の状態にあると仮定する必要があります。ステージング環境が本番環境の正確なミラーイメージでない場合、デプロイは失敗する可能性があります。デプロイが失敗すると、アプリケーションの最後の正常なバージョンを再デプロイするまでサービス停止が起きることがあります。あなたが運用管理者だとしたら、サービス停止があると夜間に起きていなければいけないでしょう。

リリース内容の審査が終わるまでユーザーに新しいバージョンをさらすことなく、本番環境でテストをおこないたいと考えているお客様が増えています。人によっては、新機能が多くの人たちに公開される前に少数の顧客に対してのみ公開し、フィードバックを集めることもあるでしょう。これは、カナリア分析またはカナリアテストと呼ばれる手法です。この記事では、Application Load Balancerstarget groupsを使用してBlue/Greenとカナリアデプロイを実装するパターンを紹介します。

もし実際にこのアプローチを試したい場合、オープンソースのコードとAWS CloudFormationテンプレートをecs-blue-green-deployment GitHubリポジトリに公開しています。
このワークフローでは、サービスをECSクラスタにデプロイする自動化されたCI / CDパイプラインが構築され、コードの最新バージョンを本番環境に昇格する準備が整ったらターゲットグループをスワップする制御されたプロセスが提供されます。環境は3つのステップで簡単に設定でき、Blue/Greenのスワップが動作することを確認できます。ぜひ試してみてフィードバックを送ってください!

 

Blue/Greenの利点

Blue/Greenデプロイメントは、ソフトウェア更新を低リスクでおこなうことができるイミュータブルデプロイメントの1つのパターンです。現在の実行中の “Blue”バージョンのアプリケーションと新しい “Green”バージョンのアプリケーションを別々の環境で作成することで、リスクが軽減されます。

このデプロイメント方法では、アプリケーションの現在の実行中のバージョンに影響を与えずに、Greenの環境で機能をテストすることができます。Greenバージョンが正常に動作していることが確認できたら、DNSを変更して古いBlue環境から新しい環境にトラフィックを徐々にルーティングすることができます。この方法に従うことで、ほぼゼロダウンタイムで機能更新とロールバックをおこなうことができます。

2つの異なる環境感でトラフィックをシフトする典型的なBlue/Greenデプロイメント

このように運用中のBlue環境に素早くトラフィックを戻すことできることは、Blue/Greenデプロイメントの主要メリットの1つです。Blue/Greenデプロイメントでは、デプロイメントプロセスのどのタイミングでもBlue環境にロールバックすることが可能です。ダウンタイムはGreen環境に問題があることを認識してから、Blue環境にトラフィックを切り戻すまでの時間に制限されます。さらに、停止の影響はすべてのトラフィックではなく、Green環境に振り分けられたトラフィックに限定されます。デプロイエラーの規模が縮小されると、全体的なデプロイのリスクも低下します。

コンテナでBlue/Greenをシンプルに実現する

複数環境の管理およびプロビジョニングの複雑さとコストのために、従来のオンプレミスでのソフトウェア更新にはBlue/Greenデプロイメントはあまり導入されていませんでした。代わりに、アプリケーションはin-placeでアップグレードされていました。

このアプローチは有効でしたが、障害時のロールバックの迅速性などいくつかの欠陥がありました。ロールバックには通常、以前のバージョンのアプリケーションの再デプロイメントをおこなっていましたが、再デプロイメントは良くないリリースがあった場合の停止時間を長期化させる可能性があります。

コンテナは、簡単にパッケージ化でき、環境間を移動しても一貫して動作するため、Blue/Greenデプロイメントの導入を容易にします。この一貫性のひとつの要因は、コンテナのもつ不変性です。コンテナの設定を変更するには、In-Placeでソフトウェアを更新するのではなく、Dockerfileを更新してコンテナを再構築、再デプロイする必要があります。

コンテナは、アプリケーションのプロセスと名前空間の分離も提供します。これにより、複数のバージョンのアプリケーションを同じDockerホスト上で競合することなく並行して実行できます。仮想マシンに比べてサイズが小さいため、ホストあたりにVMに比べて多くのコンテナを詰め込むことができます。これにより、コンピューティングリソースをより効率的に使用できるようになり、Blue/Greenデプロイメントのコストを削減できます。

Amazon ECSのフルマネージド更新

Amazon EC2 Container Service (ECS) は、既存のAmazon ECSサービスを更新すると、ローリングアップデートを実行します。ローリングアップデートでは、現在実行中のバージョンのコンテナを最新バージョンに置き換えます。ローリングアップデート中にAmazon ECSがサービスに追加または削除するコンテナの数は、サービスのデプロイ時に許可される健全なタスクの最小数と最大数を調整することによって制御されます。

最新バージョンのコンテナイメージを利用するようにサービスのタスク定義を更新すると、Amazon ECSによってコンテナの古いバージョンが自動的に最新バージョンに置き換えられます。デプロイメント中、Amazon ECSは現在実行中のバージョンから接続を切断し、新しいコンテナがオンラインになるとApplication Load Balancer に登録します。

Target groups

ターゲットグループは、同じApplication Load Balancerの背後に複数のサービスを実行できるようにする論理構造です。これは、ターゲットグループごとにリスナーを持つことで実現されています。

Application Load Balancerを前に置くECSサービスを作成する時は、サービスのターゲットグループを指定する必要があります。通常はECSサービスごとにターゲットグループを作成しますが、ここでご紹介するアプローチでは、BlueのサービスとGreenのサービスの2つのターゲットグループを作成します。Blueサービスと同じパスを使用してGreenサービスをテストできるように、ターゲットグループごとに異なるリスナーポートを使用しています。

この構成では、Greenサービスに切り替える準備が整うまで、両方の環境を並行して実行できます。セキュリティグループルールや配置制約を使用して、社内ネットワーク上のテスターからにのみGreenバージョンへのアクセスを制限することも可能です。たとえば、サービスのGreenバージョンを、企業ネットワークからアクセス可能なインスタンスでのみ実行するように設定することができます。

切り替え

古いBlueサービスを新しいGreenサービスに置き換える準備ができたら、ModifyListener APIを呼び出して、対象のターゲットグループのリスナールールを入れ替えます。変更は即座に反映されます。その後、Greenサービスはポート80のリスナーを使用してターゲットグループで実行され、Greenサービスはポート8080のリスナーを使用してターゲットグループで実行されています。下の図は、このアプローチを示しています。

シナリオ

2つのサービスが定義されており、それぞれのターゲットグループが同じApplication Load Balancerに登録され、異なるポートで待機しています。 2つのターゲットグループ間でリスナールールを入れ替えることでデプロイが完了します。

Blueサービスへのリクエストはポート80リスナーを持つターゲットグループに向けられ、Greenサービスへのリクエストはポート8080リスナーを持つターゲットグループに向けられています。

テストの後で、Application Load Balancerでリスナールールをスワップし、Greenサービスにトラフィックを送信することで、デプロイメントを完了します。

留意事項

このアプローチを使用する際に注意すべきポイントがいくつかあります。

  • アプリケーションコードが完全にステートレスである必要があります。ステート情報はコンテナの外部に格納してください。
  • コネクションドレイニングはグレースフルには実行されません。ターゲットグループのスワップは突然実行されます。そのため、実行時間が長いトランザクションがあるサービスの場合は注意が必要です。
  • カナリアデプロイメントは実行できません。この方法では、サービスの異なるバージョン間をすばやく切り替えることができますが、本番トラフィックの一部をカナリアに流したり、サービスがクラスタ全体に展開される速度を制御したりすることはできません。

カナリアテスト

標準のAmazon ECSデプロイを使用したデプロイメント方法では、ローリングデプロイメントに伴う重労働の多くが自動化されますが、問題を発見した場合にデプロイメントを途中で中断することはできません。ロールバックしたい場合は、最後の正常なコンテナバージョンにサービスのタスク定義を更新し、Amazon ECSがクラスタ全体にデプロイを実行するのを待つ必要があります。最新のバージョンでテスト中に発見されなかった問題のある変更が導入されてしまった場合、このロールバック方法では遅すぎる可能性があります。

カナリアテストでは、Green環境が期待どおりに動作していないことがわかった場合、Blue環境に影響はありません。トラフィックを元の環境に戻すことができるため、問題のある操作やダウンタイムを最小限に抑え、影響範囲を制限します。

このタイプのデプロイメントは、一部分のユーザーに新しい機能を公開して広く利用できるようにする前にフィードバックを得るA/Bテストに特に役立ちます。

カナリアスタイルのデプロイメントでは、同じターゲットグループにBlueサービスとGreenサービスを配備します。この方法はスワップ方式ほど高速ではありませんが、各サービスのタスク数を調整することで、コンテナの交換レートを制御することができます。さらに、BlueとGreenのサービスのタスク数をそれぞれ調整することでロールバックすることができます。上記のスワップアプローチとは異なり、コンテナへの接続はグレースフルに終了します。我々はAmazon ECSのカナリアスタイルのデプロイメントについてのブログも投稿する計画を立てています。

まとめ

AWSでは、Amazon ECS、Application Load Balancer、およびターゲットグループを使用して、Blue/Greenデプロイメントの操作が可能になります。 ecs-blue-green-deployment GitHubリポジトリに公開されているコードをお客様のユースケースに合わせてカスタマイズすることをお勧めします。

より詳細に興味がある場合、 Blue/Green Deployments on AWSおよびPracticing Continuous Integration and Continuous Delivery on AWSというホワイトペーパーをお読みください。 ご質問やご提案がありましたら、ぜひご意見をお寄せください。あなたのフィードバックを楽しみにしています。

(翻訳はSA千葉が担当しました。原文はこちら)

AWS SDK for Java 2.0 開発者向けプレビューを公開

AWS 開発者用ツールのチームは AWS SDK for Java のリリースに向けて熱心に取り組んできました。そして本日、バージョン 2.0 の開発者用プレビューを公開するに至りました。このバージョンは過去にリリースした 1.11.x codebase を大きく書き換えたものです。整合性、イミュータビリティ、使い勝手の良さに視点を向けて Java 8 の上に構築しました。

新しい SDK には、ノンブロッキングの I/O のサポート、ランタイムで使用したい HTTP 実装を選択できるなど、リクエストが多かった機能を含んでいます。新しいノンブロッキング I/O サポートは既存のものに比べより効率的で、サービスクライアントの Async バリアントのスレッドベース実装を取り入れています。ノンブロッキングのリクエストはそれぞれ CompletableFuture オブジェクトを戻します。バージョン 2.0 SDK では、これまでの API にいくつもの変更を追加しています。たとえば、既存のクライアントのコンストラクタと変更可能なメソッドを、クライアントビルダーと変更不可能なクライアントをベースにした非同期モデルと置換します。また、SDK はリージョンをシングルリージョンクラスにするために使用するクラスの異種コレクションを折りたたみ、ストリーミング用 API の新しいセットを提供します。SDK は GitHub でご利用いただけます。GitHub に関する問題をスタートして公開フィードバックを送信したり、いつもの方法でリクエストのプルを送信することができます。

SDK の詳細については AWS 開発者ブログの「AWS SDK for Java 2.0 – 開発者用プレビュー (AWS SDK for Java 2.0 – Developer Preview)」をご覧ください。

Jeff;

AWS Summit Tokyo 2017でのAmazon EC2 Container Service (ECS) 関連セッションまとめ

5月末〜6月頭に開催されたAWS Summit Tokyo 2017において、Amazon ECSを実際にご利用頂いているお客様からの導入事例セッションとAWSからのTechセッションを合わせると、なんと11ものAmazon ECS関連セッションが行われました。Summit全体で130以上のセッションがありましたので、その中で10%程度がAmazon ECS関連だったということになります。Amazon ECSは、2015年4月にGA(東京リージョン含む)して以来、着実にお客様に導入を頂き、スタートアップからエンタープライズまで、新規システムだけでなくオンプレからの移行でも利用される標準的なサービスとなってきたことの表れかと思います。

この投稿では、それらのセッションを一気に見返せる様に情報を集約してお届けしたいと思います。これらの情報をご覧になって、Amazon ECSの利用をぜひご検討下さいませ。


導入事例トラック

  • ナビタイムサービスにおける、Amazon ECS を活用したシステム移行 ~『乗換NAVITIME』での移行事例 ~ 資料
  • [リコー] サービス全断はダメ、ゼッタイ。途切れないテレビ会議システムを目指して 〜AWS を最大限活用して可用性を高める秘策〜 資料 動画
  • クックパッドの機械学習を支える基盤のつくりかた 資料 動画
  • Amazon ECS と SpotFleet を活用した低コストでスケーラブルなジョブワーカーシステム (※株式会社インティメート・マージャー様事例) 資料 動画
  • [Intelligence] オンプレから移行するので、Amazon ECS でコンテナ化と Terraform でインフラコード化した話 資料
  • DAU 100 万人突破! 急成長を支える Shadowverse のインフラ技術 資料
  • DMM における会員基盤プラットフォームへのAWS導入から活用事例の紹介 資料 動画
  • [ABEJA] IoT / Bigdata / AI 時代におけるスケーラブルな Deep Learning 実行基盤と応用 動画
  • Amazon ECS の進化、DevOps と Microservices の実践 (※フラー株式会社様事例)  動画
  • [CyberZ] OPENREC.tvにおけるライブ動画およびメッセージ配信基盤のリプレース全貌 資料 動画

AWS Techトラック

  • AWS のコンテナ管理入門(Amazon EC2 Container Service)資料 動画
  • C# 開発者必見、Docker コンテナへの継続的デプロイメント on AWS ~CodeCommit, CodeBuild, CodePipeline, CloudFormation, ECR, ECS を活用した CI/CD ~ 資料 動画

その他

  • Running Container-Enabled Microservices on AWS – ブートキャンプ (特別有償トレーニング)
    • 5時間で、コンテナ対応のアプリケーションの管理およびスケーリングについて詳細かつ実践に説明する、エキスパートレベルのトレーニングブートキャンプを実施しました。

最後に、直近のAmazon ECSのアップデートをまとめてご紹介します。

Amazon ECSについてより詳しく学びたい方は、日本語化されたドキュメントAWS Black Belt Online Seminarの資料等をご確認下さい。

SA岩永

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

Amazon Redshift Spectrum を使うことで、Amazon S3 に置かれたデータに対して Amazon Redshift の SQL クエリを走らせることができます。つまり Redshift Spectrum によって、データウェアハウスのローカルディスク内に保存されたデータ以外に対しても、Redshift の分析を拡張できるようになるのです。S3 の “データレイク” に貯まった大量のデータに対して、面倒で時間のかかる抽出・変換・ロード(ETL)処理を行うことなく、クエリを投げることができます。Redshift Spectrum は洗練されたクエリ最適化を用いて、数千ものノードにまでスケールして高速に処理を行います。

このブログポストでは、Redshift Spectrum の 10 の重要なベストプラクティスについて、いくつかのカテゴリにわけてご紹介します。

このガイドラインは、Redshift をお使いのお客さまとの多くのやりとりや、直接的なプロジェクトに基づいて作られています。

Amazon Redshift vs. Amazon Athena

AWS のお客さまは、私たちによく「Amazon Athena と Amazon Redshift Spectrum について、どう使い分けをすればよいのでしょうか?」と尋ねます。

Amazon Athena の利用シーン

Athena は S3 に置かれたデータに対して、SQL によるインタラクティブなアドホッククエリを投げるといったユースケースに向いています。Athena はサーバーレスアーキテクチャなので、クエリを投げるためにクラスタを立ち上げる必要はありません。クエリごとにスキャンした S3 のデータ量に基づいて料金が発生します。データを圧縮、パーティショニング、または列指向フォーマットに変換することにより、費用を節約しつつ優れたパフォーマンスを得ることができます。JDBC に対応しているすべての BI ツールや SQL クライアントから Athena を利用することができます。さらに簡単な可視化であれば Amazon QuickSight を利用することもできます。

Amazon Redshift の利用シーン

大規模な構造化データに対しては、Redshift の使用をおすすめします。Redshift Spectrum により、データを貯める場所、データのフォーマット、そして演算能力をより柔軟に活用することができます。Redshift Spectrum を使うことで、Redshift クラスターのスケーリングについて悩む必要はなくなります。ストレージとコンピュートを分離し、それぞれを独立して拡張することができるようになります。同じ S3 データレイクに対して複数の Redshift クラスターを立ち上げることで、クエリの同時実行数を増やすことができます。Redshift Spectrum は数千インスタンスにまで、自動的に拡張します。そのためテラバイト、ペタバイトそして、エクサバイトのデータに対してさえも、クエリは高速に動作します。

テスト環境の構築

Redshift Spectrum を利用するための前提条件や、開始までのステップについては、Amazon Redshift Spectrum の開始方法をご覧ください。

このブログポストでご紹介するベストプラクティスを検証するにあたって、どのようなデータでもお使いになることができます。ただひとつ大事な要件として、一番大きなテーブルについて、同じデータを 3 つのフォーマット(CSV、パーティション分けされていない Parquet フォーマット、パーティション分けされた Parquet フォーマット)に変換して S3 にファイルとしておく必要があります。どのようにファイルフォーマットを変換するかについては、このブログポストの範囲外となりますので、以下のリソースを参照してください。

外部スキーマの作成

メタデータストアとして、Athena のデータカタログを使い、以下に示すように “Spectrum” という名前の外部スキーマを作成します。

create external schema spectrum 
from data catalog 
database 'spectrumdb' 
iam_role 'arn:aws:iam::<AWS_ACCOUNT_ID>:role/aod-redshift-role'
create external database if not exists;

Redshift クラスターと S3 上のデータファイルは同じ AWS リージョンに置かれていなければいけません。また Redshift クラスターに、Athena のデータカタログと S3 上のファイルに対するアクセス権を与える必要があります。クラスターに対して、適切な IAM ロール(例えば aod-redshift-role)をアタッチします。より詳細な情報は、ステップ 1. Amazon Redshift 用の IAM ロールを作成するを参照してください。

外部テーブルの定義

例えば、パーティション分けされた parquet ファイルや CSV ファイルの Redshift Spectrum 外部テーブルは、以下のように定義されます。

CREATE  external table spectrum.LINEITEM_PART_PARQ ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY BIGINT,
 L_SUPPKEY BIGINT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
partitioned by (L_SHIPDATE VARCHAR(128))
stored as PARQUET
location 's3://<your-bucket>/<xyz>/lineitem_partition/'
;

CREATE  external table spectrum.LINEITEM_CSV ( 
 L_ORDERKEY BIGINT,
 L_PARTKEY INT,
 L_SUPPKEY INT,
 L_LINENUMBER INT,
 L_QUANTITY DECIMAL(12,2),
 L_EXTENDEDPRICE DECIMAL(12,2),
 L_DISCOUNT DECIMAL(12,2),
 L_TAX DECIMAL(12,2),
 L_RETURNFLAG VARCHAR(128),
 L_LINESTATUS VARCHAR(128),
 L_SHIPDATE VARCHAR(128) ,
 L_COMMITDATE VARCHAR(128),
 L_RECEIPTDATE VARCHAR(128),
 L_SHIPINSTRUCT VARCHAR(128),
 L_SHIPMODE VARCHAR(128),
 L_COMMENT VARCHAR(128))
row format delimited
fields terminated by '|'
stored as textfile
location 's3://<your-bucket>/<xyz>/lineitem_csv/'

Redshift クラスターと S3 上のデータファイルは同じ AWS リージョンに置かれていなければいけません。また Redshift クラスターに、Athena のデータカタログと S3 上のファイルに対するアクセス権を与える必要があります。クラスターに対して、適切な IAM ロール(例えば aod-redshift-role)をアタッチします。より詳細な情報は、ステップ 1. Amazon Redshift 用の IAM ロールを作成するを参照してください。

クエリの実行

つまり Redshift Spectrum は、S3 に置かれたデータにクエリを投げるために、外部テーブルを用います。Redshift テーブルと同様に、 SELECT 文で外部テーブルにクエリを投げられます。外部テーブルは読み込み専用であり、書き込むことはできません。

まず、Athena や(Amazon EMR などの)Apache Hive メタストアに構築されているデータカタログを参照するために、Redshift Spectrum で外部スキーマを作成します。続いて外部スキーマに対して外部テーブルを作成します。Redshift 内にテーブルを作成・ロードしないようにするために、外部テーブルに対して SELECT 文を発行する際には、 必ず “外部スキーマ.外部テーブル” と記述する必要があります。

外部スキーマは、外部のデータカタログを参照します。そのため Redshift クラスターに対して、IAM によって S3 と Athena へのアクセス権を付与する必要があります。

Redshift Spectrum のテストを始めるにあたっては、まず以下のクエリを実行するとよいでしょう。

QUERY 1:

SELECT l_returnflag,
       l_linestatus,
       sum(l_quantity) as sum_qty,
       sum(l_extendedprice) as sum_base_price,
       sum(l_extendedprice*(1-l_discount)) as sum_disc_price,
       sum(l_extendedprice*(1-l_discount)*(1+l_tax)) as sum_charge,
       avg(l_quantity) as avg_qty,
       avg(l_extendedprice) as avg_price,
       avg(l_discount) as avg_disc,
       count(*) as count_order
FROM lineitem
WHERE l_shipdate <= '1998-09-01'
GROUP BY l_returnflag, l_linestatus
ORDER BY l_returnflag, l_linestatus;

このクエリは 1 つのテーブルだけにアクセスしており、Redshift Spectrum 層によって追加されるコンピューティングを活用できます。

QUERY 2:

SELECT  l_orderkey,
       sum(l_extendedprice * (1 - l_discount)) as revenue,
       o_orderdate,
       o_shippriority
FROM	customer, orders, lineitem
WHERE	c_mktsegment = 'BUILDING'
       AND c_custkey = o_custkey
       AND l_orderkey = o_orderkey
       AND o_orderdate < date '1995-03-15'
       AND l_shipdate > date '1995-03-15'
GROUP BY l_orderkey, o_orderdate, o_shippriority
ORDER BY revenue desc, o_orderdate
LIMIT 20;

このクエリは 3 つのテーブルを結合しており、Redshift Spectrum と素の Redshift のパフォーマンスを比較するのに向いています。

並行性に関するベストプラクティス

これらのおすすめプラクティスは、Redshift Spectrum による並行ワークロードのパフォーマンスを最適化するのに役立ちます。

1. Amazon Redshift Spectrum をスキャンインテンシブな並行ワークロード改善に活用する

Redshift Spectrum は、利用している Redshift クラスターとは独立した専用のサーバー群にあります。フィルター処理や集約処理といった、多くのコンピュートインテンシブな処理を Redshift Spectrum 層で行うことで、クエリが使用する Redshift クラスターの処理キャパシティは大きく削減されます。加えて Amazon Redshift Spectrum は賢くスケールします。MPP(Massively Parallel Processing)の利点を活かすために、Redshift Spectrum はクエリで必要な量に応じて、最大数千のインスタンスで処理を行います。

スキャンや集約インテンシブなワークロードを並行で実行するようなユースケースでは、平均的な Redshift Spectrum のパフォーマンスは、素の Redshift を上回ります。

MPP システムで最もリソースインテンシブな処理は、データロードのプロセスです。これはアクティブな分析クエリによって、コンピュートリソースだけでなく、MVCC(Multi Version Concurrency Control)によるテーブルロックによる競合が引き起こされるためです。対照的に S3 に追加され、新しいパーティションとしてメタデータも更新されたファイルを、外部テーブルを通じて Redshift Spectrum で認識する形をとることで、こうしたデータ更新のワークロードを Redshift クラスター の外に追いやることができるようになります。これはクエリの同時実行性能に対して、大きなプラスの効果をもたらします。

2. 同時実行性をスケールさせるために、複数のオンデマンド Amazon Redshift クラスターを使用する

複数の Redshift クラスターが、Redshift Spectrum 経由で S3 に保存されたデータにアクセスすることにより、並行ワークロードのパフォーマンスを改善させることができます。Redshift を使うお客さまの一般的なユースケースには、季節的なスパイクや、非常に同時実行クエリ数の多いワークロードがあります。Redshift Spectrum が登場する前は、増加する同時実行クエリ数に対処するために、お客さまはスナップショットからの復元によって、複数の “読み取り専用” Redshift クラスターを立ち上げる必要がありました。このやり方をとった場合、数百テラバイトにもおよぶデータを含む巨大な Redshift クラスターをお持ちのお客さまだと、クラスターの復元に非常に長い時間がかかるため、データレイテンシーの問題が生じてしまいました。

Redshift Spectrum の登場により、最も大きなテーブルを S3 に移動させ、Redshift クラスターには小さなサイズのデータのみを置く、という形を取れるようになりました。クラスターで保持するデータ量が減ったことにより、複数の “読み取り専用” Redshift クラスターを従来よりはるかに高速に立ち上げられるようになり、季節性のあるスパイク的なクエリワークロードに対応できるようになりました(図 1)。コストを削減するためには、ジョブが終わったらすぐに “オンデマンド” な Redshift クラスターをシャットダウンしてください。

Figure 1: 複数の “読み取り専用” Amazon Redshift クラスターからの共有 Redshift Spectrum 層へのアクセス

pgbouncer-rr をお使いいただくことで、複数の Redshift クラスターを立ち上げてクエリのルーティングを行う処理を簡単に行うことができます。詳細については以下のブログ記事を参照してください。

Query Routing and Rewrite: Introducing pgbouncer-rr for Amazon Redshift and PostgreSQL.

ストレージのベストプラクティス

ストレージの最適化を考える際には、あらゆるステップで I/O を削減することを考える必要があります。列指向フォーマットを使用する、圧縮によって各ストレージブロックにより多くのデータを詰め込む、データのパーティショニングをサポートしているファイルフォーマットを使用する、といったことが挙げられます。Redshift Spectrum でサポートされているファイルフォーマットは、CSV、TSV、Parquet、Sequence、そして RCFile です。また圧縮に関しては、Gzip、Snappy、BZ2 がサポートされています。

3. パフォーマンス向上とコスト削減のために Apache Parquet ファイルを使用する

Apache Parquet は、Apache Hadoop エコシステムのあらゆるプロジェクトで、データ処理フレームワークやデータモデル、プログラミング言語に依らず利用可能な列指向フォーマットです。詳細については、Apache Prquet の公式サイトをご覧ください。

Redshift Spectrum は、クエリ実行のために必要なカラムを含んだファイルだけを、S3 から読み出します。Redshift Spectrum はプレディケイトプッシュダウン(プレディケイトフィルタリングとも呼ばれます)をサポートしています(訳注:プレディケイトプッシュダウンとは、WHERE 句や GROUP BY 句などの処理を効率的に行うための手法です。例えば GROUP BY に対するプレディケイトプッシュダウンでは、各リーダーで読み込んだデータについて、全データで GROUP BY を行う前に、各ワーカー内であらかじめ GROUP BY をしておき、その結果を集約ワーカーに転送する、といったプロセスをとります。各ワーカーで先に集約を行うことでデータの転送コストが下がり、結果的にパフォーマンスが向上します。このように、クエリの実行パイプラインの最後で行う処理を、効率化のためにあらかじめ各プロセスでおこなっておく(= プッシュダウン)のが、プレディケイトプッシュダウンの役割となります)。

Redshift Spectrum は、クエリ単位で S3 からスキャンしたデータ量ごとに課金されます。Parquet フォーマットは列指向フォーマットでデータを保持するため、Redshift Spectrum は不必要なカラムを除いた形でスキャンを行うことができます。例として、CSV 形式のテキストファイルと、パーティション分けされた Parquet ファイルのクエリパフォーマンスの違いをみてみるとよいでしょう。

Parquet ファイルの利用によって、パフォーマンスが向上するだけでなく、パーティション分けされていない行指向の CSV ファイルよりはるかにコスト効率がよくなることが、さまざまな検証によって示されています。

SVL_S3QUERY_SUMMARY テーブルを調べることで、パーティション分けされた Parquet ファイルを使う際の、S3 に関するさまざまな興味深いメトリクスを確認することができます。

select * from SVL_S3QUERY_SUMMARY where query=<Query-ID>;

s3_scanned_rowss3query_returned_rows という 2 つのメトリクスに、特に注目してみましょう。CSV ファイルを処理するときと比べて、Redshift Spectrum から Redshift クラスターに送られるデータ総量が驚異的に削減されていることがわかります。

4. 頻繁に使われるカラムをパーティションとした Parquet ファイルをつくる

パーティションとして利用する最適なカラムを決める際には、以下の点に注目しましょう

  • フィルタとして頻繁に使われるカラムは、パーティションカラムの良い候補と考えられます
  • 過度に細かいパーティショニングは、パーティションの情報を取得するのに時間を要します。一方で、必要なパーティションの選択により、S3 からスキャンするデータを減らすのに役立ちます
  • 実際のパフォーマンスは、ファイルの置き方、クエリのパターン、ファイルサイズの分布、ひとつのパーティションに含まれるファイル数、対象となるパーティション数などによって異なります
  • パーティションカカラムの偏りを避けましょう
  • ファイルサイズの分布ができる限り均等になるようにしましょう。つまり、すべて 256MB の Parquet ファイル 10 個の方が、1GB 超のファイル 1 個と 256MB のファイル 6 個より望ましいということです

パーティションによる枝借りが素晴らしい効果を発揮するのを確認するために、2 つの外部テーブルを Parquet ファイルで作成してみましょう。ひとつはパーティション分けされていないもの、もうひとつは日単位でパーティション分けされているものです。

パーティション分けされた外部テーブルは、そうでないものより 2-4 倍程度高速にスキャンできます。

“パーティションの枝借り” の効果をどのように確認すれば良いでしょうか。以下に示す SQL を用いることで、パーティションの枝借りの効果を分析することができます。クエリが数個のパーティションにのみアクセスするような場合には、期待通りの効果が得られていることを確認することができます。

SELECT query,
	segment,
	max(assigned_partitions) as total_partitions,
	max(qualified_partitions) as qualified_partitions 
FROM svl_s3partition 
WHERE query=<Query-ID>
GROUP BY 1,2;

クラスター設定のベストプラクティス

5. 正しい Redshift のクラスター設定により Redshift Spectrum のパフォーマンスを最適化する

Redshift Spectrum クエリの同時実行性能は、以下の 2 つのレベルで制御することが可能です

  • クエリレベル(クエリごと 1 スライスにつき最大 10 の同時実行数)
    • いくつのクエリが同時に実行されているかによって、同時実行数が変わる
    • 割りあてられた同時実行数によって、S3 をスキャンするスレッド数が制限される
  • ノードレベル(ノード状で動作するすべての S3 をスキャンするクエリに適用される。ノードタイプによって数が異なる)
    • より大きなノードタイプを選択するほど、上限数も高くなる

ファイル総数 <= クエリごとの同時実行性能 (例えば 10) * クラスターのスライス数、といった簡単な計算ができます。。ただしクラスターのノード数を増やしても、必ずしもパフォーマンスが向上するとは限りません。最適なクラスターのノード数は、以下のようにして決めてください。まず Redshift Spectrum の外部テーブルに、いくつのファイルが含まれているかを確認してください。続いてクラスターのサイズを大きくしていって(クラスターに含まれるスライス数を増やすということです)、ノード数が増えてもパフォーマンスがこれ以上伸びなくなるというポイントを探してください。そのときのノードタイプにおける、最適な Redshift のクラスターサイズは、それ以上のパフォーマンス向上が起こらなくなるところです。

クエリパフォーマンスのベストプラクティス

S3 に対するクエリのパフォーマンスを改善するための、簡単な方法をいくつかご紹介します。

6. Redshift Spectrum でスキャン・集約インテンシブなクエリを実行する

Query 1 のように結合処理が含まれないクエリでは、物理的な I/O のコストがスキャン速度の大半を占めます。これらのクエリでは、Redshift Spectrum は素の Redshift よりも高速に動作します。その一方で複数の結合処理が含まれる Query 2 のようなクエリでは、ローカルストレージ上できちんと最適化されている素の Redshift テーブルの方が、当然よいパフォーマンスを発揮します。

7. プレディケイトプッシュダウンによって S3 に対するクエリのパフォーマンスを改善する

Redshift Spectrum 層で行われる処理(S3 に対するスキャン、カラム抽出、フィルタリング、集約)は Redshift クラスターとは独立して行われます。もちろん Redshift クラスターのリソースを消費することはありません。

SQL に含まれるある種の処理は Redshift Spectrum 層にプッシュダウンすることができ、可能な場合は常にその恩恵を受けることができます。例えば以下のような処理が挙げられます。

  • GROUP BY 句と、いくつかの文字列関数
  • イコール 条件や LIKE のようなパターンマッチング条件
  • COUNT、SUM、AVG、MIN、MAX、その他の一般的な集約関数
  • regex_replace やその他の関数

DISTINCTORDER BY といった演算子は、Redshift Spectrum にプッシュダウンすることができないため、Amazon Redshift で実行されます。可能ならば、これらの処理の利用を最小化するか、もしくは利用を避けるのが望ましいです。

次に示す 2 つのクエリを実行してみると、両者の間でパフォーマンスが大きく異なることがわかります。なぜでしょうか?

Select MIN(L_SHIPDATE), MAX(L_SHIPDATE), count(*)
	from spectrum.LINEITEM_NPART_PARQ;
Select MIN(DATE(L_SHIPDATE)), MAX(DATE(L_SHIPDATE)), count(*)
        from spectrum.LINEITEM_NPART_PARQ;

最初のクエリの実行計画では、S3 データに対する集約処理が Redshift Spectrum にプッシュダウンされ、集約された結果のみが Redshift に送られます。

一方、2 つめのクエリの実行計画では、Redshift Spectrum が DATE 型を標準のデータ型としてサポートしていないことや、DATE 変換関数をサポートしていないことによって、Redshift Spectrum 層でS3 データに対する集約処理がまったく行われません。結果として S3 から読み出された大量のデータが、Redshift 上で変換処理を行うために送られてくることになります。

また、SVL_S3QUERY_SUMMARY システムビュー(の s3query_returned_rows カラム)に対して、2 つの SQL ステートメントの詳細を確認するクエリを投げることもできます。クエリの結果をみると、Redshift Spectrum から Redshift に送られる行数が両者で大きく異なっていことがわかるでしょう。

8. DISTINCT を GROUP BY で置き換える

GROUP BYMIN/MAX/COUNT といった演算子は、Redshift Spectrum 層に処理をプッシュダウンすることができます。その他の DISTINCTORDER BY のような SQL 演算子は、プッシュダウンできません。一般的に、Redshift Spectrum 層にプッシュダウン可能なすべての演算子は、Redshift Spectrum が動作するパワフルなインフラにより、プッシュダウンによるパフォーマンスの向上が期待できます。

例えば、以下の 2 つの機能的に等価な SQL ステートメントを試してみましょう。

SELECT DISTINCT l_returnflag,
        l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE 	EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
ORDER BY l_returnflag, l_linestatus
;


SELECT l_returnflag,l_linestatus 
FROM 	spectrum.LINEITEM_PART_PARQ 
WHERE EXTRACT(YEAR from l_shipdate::DATE) BETWEEN '1995' AND  '1998' 
GROUP BY l_returnflag, l_linestatus 
ORDER BY l_returnflag, l_linestatus
;

ひとつめのクエリでは(DISTINCT 演算子のせいで)プッシュダウンが行われません。そのため Redshift 上でソートおよび重複除去を行うために、大量のレコードが送られます。ふたつめのクエリでは、重たい処理や集約の大半を行う HashAggregate が Redshift Spectrum で行われます。SVL_S3QUERY_SUMMARY にクエリを投げることで、実行計画の違いを確認することができます。

ここでの学びは、可能なときは常に “DISTINCT” を “GROUP BY” で置き換えるべきだということです。

テーブル配置のベストプラクティス

このシンプルなガイドラインでは、最高のパフォーマンスを得るためのテーブルの置き方について述べます。

9. 大きなファクトテーブルを S3 におき、それ以外を Redshift で持つ

Query 2 では、3 つのテーブルに対して結合処理を行っています。自然な疑問として「もし 3 つのテーブルすべてを、パーティション分けした Parquet ファイルとして、S3 においたらどうなるでしょうか?」と思うでしょう。素の Redshift に 3 つのテーブルがすべて置かれているときと比べて、パフォーマンスは良くなるでしょうか、それとも悪くなるでしょうか?

結合処理に対して最適化を行なった(適切な分散キー、ソートキーを設定済みの)Redshift テーブルは、Redshift Spectrum よりも高いパフォーマンスを発揮します。Redshift Spectrum の外部テーブルは、統計情報をサポートしていません

データベースエンジンはヒューリスティクス、もしくは単純な行数カウントによって結合の順番を決定します。この方法だと、必ずしも最適なパフォーマンスは得られません。AWS では、最も大きいファクトテーブルのみを S3 上に置いて、それ以外の小中規模のディメンジョンテーブルは Redshift に持つことを推奨しています。この場合に、オプティマイザーのヒューリスティクスが最もうまく働きます。

CREATE EXTERNAL TABLE および ALTER TABLE コマンドでは、TABLE PROPERTIES 節の中で (numRows) をテーブル統計情報として設定することができます。この情報によって、オプティマイザーがより良い実行計画を生成するのを手助けすることができます。より詳細な情報については、Redshift のドキュメント内の CREATE EXTERNAL TABLE を参照してください。

少なくとも 3 つのテーブルの結合処理を含むクエリを、それらが正しい順番で結合されるように記述してみてください(Explain 文で確認することができます)これによって、 Redshift Spectrum では複数テーブルの結合を行なってはいけない、といった間違った考えに陥らないようにすることができます。

10 頻繁に結合処理の対象となる大きなテーブルを S3 上に置くときに注意する

素の Redshift は Query 2 のようなクエリについて、大概の同時実行クエリ数において、Redshift Spectrum より約 3 倍のパフォーマンスを発揮します。Query 1 と 2 の違いは、Query 1 では 1 テーブルに対する集約処理しか行なっていないのに対して、Query 2 では 3 つの比較的大きなテーブルの結合処理が含まれている点です。

より明確に言うとすれば、このようなパフォーマンスの違いが生じるのは、結合処理が Redshift の中で行われているためです。結合に必要なデータはまず S3 から読み込まれ、そして Redshift クラスターの各スライスに転送される必要があります。その結果、Redshift のローカルストレージにアクセスするのと比べて、Redshift Spectrum 経由の場合は非常に高いレイテンシーが発生します。

そのため、大きな Redshift テーブルに対して結合を頻繁に行い、かつクエリのワークロードに対して厳しい SLA が設定されている場合には、これらのテーブルを S3 に置くべきではありません。

結論

このブログポストでは、Redshift Spectrum のパフォーマンスを改善するための重要なベストプラクティスについて述べてきました。もちろん各ユースケースで異なる点があるため、ここで示したおすすめの方法をどの程度取り入れるかについて、考える必要があります。

原文: 10 Best Practices for Amazon Redshift Spectrum (翻訳: SA志村)

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

DynamoDB Accelerator (DAX) が正式にサービス開始しました

今年の初め頃 Amazon DynamoDB AcceleratorDAX)について紹介をしました。DAXはフルマネージドのキャッシュサービスでDynamoDBテーブルの前段(論理的に)に置かれます。DAXはキャッシュされたデータに対するリクエストをマイクロ秒単位で返すため、読み込みワークロードに最適です。DAXはアプリケーションコード内ではDynamoDB APIと互換性を保つ様にサポートしており、シームレスで使いやすいようにデザインしています。管理することはDAXクラスタを作成して既存の読み取りと書き込みのターゲットとして使用するだけです。パッチ適用、クラスタメンテナンス、キャッシュデータの複製、または障害管理について心配する必要はありません。

本日から利用可能
今日DAXが正式に利用可能になったことをお知らせします。DAXが利用可能なAWSリージョンを追加拡張し、プレビューの期間にパフォーマンスと可用性をチューニングしました。

5つのリージョンで利用可能 – 現在 DAXはUS East (Northern Virginia)、EU (Ireland)、US West (Oregon)、Asia Pacific (Tokyo)、US West (Northern California) の5つの地域で利用可能です。

In Production – プレビュー期間内にDAXを本番で使用しているユーザーもおり、DAXをアプリケーションに追加するのが楽で今ではアプリケーションの速度が10倍速くなってたという声を頂いています。

Getting Started with DAX
以前の記事(翻訳版はこちら)で紹介したように、DAXを使用して既存のDynamoDBアプリケーションを高速化するのは簡単です。必要なリージョンにDAXクラスタを作成し、 DAX SDK for Javaを利用するようにアプリケーションを更新します(コード内の呼び出し方は同じですが、ライブラリの置き換えを行う事です)。SDKを構成してクラスタにエンドポイントを使用するようにします。リードスルー/ライトスルーキャッシュとして、DAXはすべてのDynamoDB読み取り/書き込みAPIをシームレスに処理します。

私たちは他の言語のSDKのサポートも取り組んでおり、利用可能になった時点で追加情報を共有します。

価格について

US East (Northern Virginia) と US West (Oregon) の各地域で、時間あたり$ 0.269から始まる料金
でクラスター内の各ノード(詳細については、 DynamoDBの価格を参照)を1時間単位でお支払いいただきます。DAXでは、クラスタ内の各ノードが高可用性のための読み取りターゲットおよびフェールオーバーターゲットとして機能します。DAX SDKはクラスタを認識しており、クラスタ内のすべてのノードに対してラウンドロビンで要求を発行し、クラスタのキャッシュリソースを最大限に活用できるようにします。

DAXは読み取りトラフィックの急激な急上昇を容易に処理できるため、テーブルのプロビジョニングされたスループットの量を減らすことができ、結果としてマイクロ秒で結果を返しながら全体のコストを削減できます。

最後にAmazon.comのCTOであるWerner Vogelsが書いたブログを紹介させて頂きます。

Amazon DynamoDB Accelerator (DAX): Speed Up DynamoDB Response Times from Milliseconds to Microseconds without Application Rewrite.

Tinder、Careem、そしてCanon INC. の事例についてもご紹介していますので、ぜひご覧ください。

Jeff;

(翻訳はSA成田が行いました。原文はこちら

AWS WAF 用のレートベースのルールでウェブサイトとサービスを保護

AWS WAF (ウェブアプリケーションファイアウォール) は、悪質または不正なリクエストに関与する様々なタイプのアプリケーションレイヤー攻撃からアプリケーションを保護するために利用できます。このサービスについて説明したブログ (「新しい AWS WAF について (New – AWS WAF)」でもお見せしましたが、クロスサイトスクリプティング、IP アドレス、SQL インジェクション、サイズ、コンテンツ制約に見合うルールを定義できます。

受信リクエストがルールと一致すると、アクションが呼び出されます。アクションは許可やブロックを実行したり、単にマッチ数をカウントすることができます。既存のルールモデルはパワフルかつ様々な種類の攻撃を検出し対応することができます。ただし、特定の IP アドレスから送られた有効なリクエストが大量に送信されただけのケースでは、攻撃として対応することはできません。こうしたリクエストはウェブレイヤーの DDoS 攻撃や総当たりのログインの試行、もしくはパートナー統合で不具合があった場合の可能性があります。

新しいレートベースのルール
本日、WAF にレートベースのルールを追加しました。これにより、ブラックリストへの IP アドレスの追加または削除を管理できるようになり、例外や特別なケースに対応できる柔軟性も提供します。IP アドレスをブラックリストに追加 – 設定済みのしきい値を超える速度でリクエスト数を送信した IP アドレスをブラックリストに追加することができます。IP Address のトラッキング– どの IP アドレスがブラックリストに追加されているか見ることができます。IP Address の削除 – ブラックリストに追加された IP アドレスは、設定済みのしきい値を超える速度でリクエストを送信しないようになれば自動的にリストから削除されます。IP Address の例外 – 特定の IP アドレスをブラックリストの対象外として設定することができます。その場合はレートベースのルール内にある IP アドレスのホワイトリストを使用してください。たとえば、自分のサイトに信頼できるパートナーが高速でアクセスできるように許可したい場合もあるでしょう。モニタリングおよびアラーム発行 – 各ルールに発行した CloudWatch メトリクスでモニタリングしたりアラーム発行をすることができます。新しいレートベースのルールと WAF の条件を組み合わせて高度なレート制限戦略を取り入れることもできます。たとえば、レートベースのルールやログインページと一致する WAF 条件を使用できます。そうすることで、ログインページで適度なしきい値を適用できます (パスワードのブルートフォース攻撃を防ぐため)。そして、マーケティングやシステムステータスのページにより高いしきい値を設定することが可能になります。しきい値は 5 分間で 1 つの IP アドレスによる受信リクエスト数により定義されます。このしきい値を超えると、その IP アドレスからの追加リクエストはリクエストの速度がしきい値以下になるまでブロックされます。

レートベースのルールを使用
サイトの/ログインを保護するレートベースのルールを定義する方法を説明します。そのページの URI で希望のストリングと一致する WAF 条件を定義することから始めます。

次にこの条件を使用してレートベースのルールを定義します (レート制約は 5 分間隔で行われるリクエストをもとにしますが、制限を超え次第ブラックリストに追加されます)。

条件とルールの設定が完了したら、Web ACL (ProtectLoginACL) を作成し、すべて一緒に AWS リソースにアタッチさせます (この場合は CloudFront ディストリビューション)。

次にルール (ProtectLogin) を Web ACL にアタッチします。

これでリソースがルールと Web ACL に合致した状態で保護されるようになりました。関連の CloudWatch メトリクス (この場合は ProtectLoginProtectLoginACL) をモニタリングできます。CloudWatch アラームを作成し、保護用のしきい値を超えたら Lambda 関数の開始に使うこともできます。コードは寄与度が大きい IP アドレスを調べ、複雑なビジネス主導の決定を行ったり、信頼できるパートナーや特別な支払いプランを使用しているユーザーに普通以上の許可を与えられるよう、ホワイトリストのルールに追加することもできます。

今すぐ使用可能
この新しいレートベースのルールは今すぐご利用いただけます。レートベースのルール料金は通常ルールと同様です。詳しくは「WAF 料金 (WAF Pricing)」ページをご覧ください。

Jeff;

新機能 – Amazon WorkSpaces 用のマネージド型デバイスの認証

Amazon WorkSpaces では、ウェブおよびさまざまなデスクトップおよびモバイルデバイスから、クラウド上の仮想デスクトップにアクセスできます。この柔軟性により、WorkSpaces はユーザーが自己所有しているデバイス (BYOD または Bring Your Own Device とも呼ばれます) を使用できる環境に最適です。このような環境では、組織は WorkSpaces にアクセスできるデバイスを管理する機能を必要とする場合があります。たとえば、コンプライアンスまたはセキュリティポリシー要件を満たすため、クライアントデバイスのオペレーティングシステム、バージョン、またはパッチレベルに基づいてアクセスの制御が必要になる場合があります。

マネージド型デバイスの認証
本日、WorkSpaces 用のデバイス認証の提供を開始します。これにより、デジタル証明書を使用して、Apple OSX および Microsoft Windows からのクライアントアクセスを管理できるようになりました。また、iOS、Android、Chrome OS、ウェブ、およびゼロクライアントデバイスからのアクセスを許可またはブロックする選択もできます。ポリシーを実装して、許可するデバイスタイプとブロックするデバイスタイプを、パッチレベルまで管理できます。アクセスポリシーは、各 WorkSpaces ディレクトリに対して設定されます。ポリシーの設定後、クライアントデバイスから WorkSpaces への接続リクエストが評価され、ブロックまたは許可されます。この機能を利用するには、Microsoft System Center Configuration Manager またはモバイルデバイス管理 (MDM) ツールを使用して証明書をクライアントデバイスに配布する必要があります。WorkSpaces コンソールからアクセスコントロールオプションを設定する方法を次に示します。

クライアントが接続を許可されていない場合は、次のようになります。

 

今すぐ利用可能
この機能は、WorkSpaces が利用できるすべてのリージョンで利用できます。

Jeff;

AWS Mobile Hub で JavaScript 開発を改善する

はじめに

JavaScript エコシステムが成長していくなかで、私達はモバイルおよびハイブリットアプリを構築するお客様を支援する取り組みを続けています。本日、 AWS Mobile Hub に Hosting and Streaming 機能をリリースしました。この機能は、Amazon S3 と Amazon CloudFront を使用するモバイル Web サイトのテスト及びプロダクション環境へのデプロイを自動化します。また、標準設定ファイルと SDK を使用する際の設定ワークフローを簡略化します。

この新しい機能によって、 JavaScript 開発者は事前設定された AWS アーキテクチャを起動したり、 Mobile Hub プロジェクトをビルドできます。また、集中管理された設定と事前ダウンロードされた SDK を使用して、ワンクリックでグローバル Web サイトを作成できます。

(more…)