Amazon Web Services ブログ

AWS のディープラーニング

私のようなタイプの人であれば、人工知能 (AI) や機械学習 (ML)、ディープラーニングは実に興味深く胸を躍らせるトピックではないかと思います。AI、ML、ディープラーニングが今まで以上に幅広く利用されるようになるに連れ、Dr. Issac Asimov 氏がサイエンスフィクションで描いた「スター・ウォーズ」に出てくるようなロボット工学そして医学の進歩、さらには「スタートレック」のキャプテンカークやそのクルーに「誰も行ったことのない場所へ、勇敢に突き進もう (to boldly go where no man has gone before)」と言わせたテクノロジーが実際に可能になるのではないかと思わずにいられません。   前述のトピックに興味がある人にとって、画像や動画を複数のカテゴリに区別する畳み込みニューラルネットワーク (Convolutional Neural Networks) や、音声認識、自然言語によるインターフェース、推奨エンジンなど、ディープラーニングにより可能となる AI や ML のソリューションには馴染みが深いのではないかと思います。けれども、データサイエンティスト、機械学習の利用者、リサーチサイエンティスト、ディープラーニングに興味を持つ熱心なユーザー達がこうしたテクノロジーに携わりインフラストラクチャや環境、ツールを設定する作業は必ずしも簡単ではありません。多くの開発者はディープラーニング技術を使用して、ディープラーニングをトレーニングモデルそしてソリューション開発に早く繋げていきたいと考えています。こうした理由から、経験豊富なデータサイエンティストであれ、今から始めたいと思っている興味津々の開発者まで、速くディープラーニングのソリューションを構築したいと思っている方々に向けて、いくつかのリソースをご提供したいと思います。 ディープラーニングのリソース Apache MXNet は Amazon が選んだディープラーニングのフレームワークです。Apache MXNet フレームワークと NVIDIA GPU コンピューティングを組み合わせれば、スケーラブルなディープラーニングプロジェクトとソリューションを簡単に AWS クラウドで開始できます。MxNet のディープラーニングの旅を始める方々を対象に、様々なセルフサービス形式のチュートリアルやデータセットが今すぐ利用できるようになっています。 AWS ディープラーニング AMI の起動: このガイドでは、Ubuntu で AWS ディープラーニング AMI を起動する手順を説明しています。 MXNet – コンピュータビジョンのアプリケーションを作成: この実践的なチュートリアルは構築済みのノートブックを使用してニューラルネットワークの利用でコンピュータビジョンを構築し、手書きの数字を識別する方法を説明します。 AWS […]

Read More

コンテナやサーバレスアプリのデプロイツールとしてのAWS CloudFormation

SA岩永です。AWS上にシステムを構築する際に、アプリケーションのデプロイをどのように行うか?については多様なやり方が考えられますが、今日はを使ったデプロイをご紹介したいと思います。CloudFormationはインフラ構築のツールとして考えられている方も多いと思いますが、最近は特にやといったComputeサービスへのアプリケーションデプロイツールとしての活用が進んでいます。AWSのリソースはやSDK等での操作が可能なので自作のツール等を使われるのはもちろん1つの選択肢ですが、もしCloudFormationを検討されたことのない方は、ぜひこの投稿を参考にして頂けるとありがたいです。 デプロイツールとしてのCloudFormationのメリット 最初に結論をまとめておきます。CloudFormationを使ったデプロイには以下の様なメリットがあります。 デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能 宣言的にデプロイが定義・実行できる アプリケーションに関連する他のAWSリソースも合わせて管理可能 現在お使いのデプロイツールで、逆に上記の様な観点で困ったことのある方は、この投稿をじっくり読んで頂くと良いと思います。 デプロイツール自体のインストールが不要、YAML/JSONを書くだけ、ブラウザからでもデプロイ可能 例えばCLIで行う様なデプロイツールの場合、そのツール自体のインストール等が必要になりますが、CloudFormationであればブラウザからテンプレートを指定するだけでデプロイできます。CloudFormationの一番のメリットはここです。アプリケーションの構成を記述したYAML or JSONのテンプレートファイルを用意するだけで、すぐにデプロイが可能です。 CloudFormationも実態はAWSのAPIを実行しながらリソースを作成・更新しますが、CloudFormationの場合にはAPIの実行そのものをCloudFormationのサービス側でやってくれます。例えばECSのデプロイで新しいTask Definitionを作成した後でそれを指定してServiceを更新するという依存関係のある2回のAPI操作を順番に実行する必要がありますが、CloudFormationに1回命令を送るだけで後のAPI操作はCloudFormationのサービスが代わりにやってくれます。なので、デプロイが終わるまで実行プロセスが待っている必要もないですし、複数人の排他的実行も実現できますし、さらに現在の状態と過去の履歴というデータの保存までもやってくれます。 もちろん、CloudFormation自体もAWSのサービスなので、CLI/SDKでの操作は可能です。もしもデプロイをCLIで実行して終わるまで待ちたい、ということであれば、aws cloudformation deployというコマンドを使うと更新が終わるまでポーリングしながら待ってくれます。この場合に必要なものはAWS CLIのインストールのみなので、そこまでハードルの高いものではありません。 宣言的にデプロイが定義・実行できる AWSのAPIを利用しながらデプロイツールを自作する場合には、リソースの作成順序に気を払いながら、かつ途中で失敗した場合のエラーハンドリング等も考慮しつつ手続き的に実装する必要があります。これはシンプルな構成であればそこまで難しくはないのですが、対応したい機能が徐々に増えてくるとだんだんと実装が複雑化してきてしまいます。 CloudFormationで使うテンプレートは、手続きを記述するのではなく、希望する状態を宣言的に定義するものです。そのため、複雑な構成であっても簡潔さを保って記述することができますし、多くのケースで各リソース間の依存関係も自動で判断されるので、実行順序を考えて記述する必要もありません。もちろん、テンプレートにはパラメータを設定することも可能なので、例えばECSであれば新しく作成したコンテナイメージ名をパラメータにしておくと、デプロイはそのパラメータを更新するだけで済みます。 アプリケーションに関連する他のAWSリソースも合わせて管理可能 ECSやLambdaは、それ単体だけで利用するケースよりも、他のAWSのサービスも合わせて利用されることが多いと思います。例えば、のRoleは良く使われますし、データベースとしてを使ったり、ECSのコンテナへの負荷分散にを使うことは非常に多く、場合によってはアプリケーションのデプロイ時にそれらのリソースの更新も行いたいケースもあります。 CloudFormationでは他のリソースも合わせて定義して操作させられるので、そういったケースに非常に強力なツールとなります。アプリケーションと同じテンプレートで作成することもできますし、昨年リリースされたCross Stack Referenceという機能を使うと、先に作成しておいたリソースをアプリケーション側から参照するといった使い方もできます。 CloudFormationを使ったECSのデプロイ例 こちらは、ECSへの継続的デプロイメントについて紹介した以下のブログをご参照頂くのが良いです。 AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント ブログで紹介されている構成では、GitHubへのコードのpushをトリガーにして、イメージのビルドからECSのServiceの更新まで一貫したものを紹介していますが、Service更新部分はCloudFormationテンプレートを使って実施しています。また、がデプロイ方式としてCloudFormationに対応しているので、簡単に設定することが可能です。 参考のために、Task DefinitionとServiceとIAM Roleを定義するYAMLテンプレート例を貼り付けておきます。 https://github.com/awslabs/ecs-refarch-continuous-deployment/blob/master/templates/service.yaml Resources: ECSServiceRole: Type: AWS::IAM::Role Properties: Path: / AssumeRolePolicyDocument: | { “Statement”: [{ “Effect”: “Allow”, […]

Read More

8 月の AWS Black Belt オンラインセミナーのご案内

【注意】セミナーの実施日程について更新がありました.最新の実施日程は,こちらをご覧ください. こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー8月の配信についてご案内させて頂きます。8月は開発者の方々に役立つ内容を多めに放送する予定です。ソリューションカットでは、デプロイをテーマにしたものと,Redshift のテーブル設計についてのものをお送りします。また今年に入って大きなアップデートがあった DynamoDB についてもお送りします。   8月の開催予定   サービスカット 8/2(水) 18:00-19:00 AWS X-ray 8/9(水) 18:00-19:00 Amazon DynamoDB 8/23(水) 18:00-19:00 AWS MobileHub 8/30(水) 18:00-19:00 AWS Key Management Service (KMS) ソリューションカット 8/22(火) 12:00-13:00 Deployment on AWS 8/29(火) 12:00-13:00 Amazon Redshift テーブル設計詳細ガイド お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカー、スタッフ 一同みなさまのご参加をお待ちしております。

Read More

新機能 – Amazon CloudWatch ダッシュボードでの API と CloudFormation のサポート

当社は、数年前に CloudWatch ダッシュボードの提供を開始しました。提供開始にあたって私が書いた投稿で、選択された CloudWatch メトリクスをグラフィカル形式で表示するダッシュボードをインタラクティブに作成する方法をご紹介しました。提供開始後に、フルスクリーンモード、暗いスキンのテーマ、Y 軸範囲のコントロール、名前変更の簡略化、永続的ストレージ、新しい視覚化オプションなどの追加の機能を導入しました。 新しい API および CLI コンソールのサポートはインタラクティブな使用には非常に役立ちますが、多くのお客様から、ダッシュボードとその内部のウィジェットのプログラムによる作成と操作のサポートを求める声が寄せられました。ダッシュボードの動的な構築と管理、および対応する AWS リソースの作成と削除に応じたウィジェットの追加と削除が求めらました。その他のお客様からは、2 つ以上の AWS アカウント間で一貫したダッシュボードのセットを設定、管理する機能の要望が寄せられました。そして、CloudWatch ダッシュボードの API、CLI、 のサポートの提供が開始され、今すぐご利用いただけるようになったことをここに発表いたします。4 つの新しい API 関数 (および同等の CLI コマンド) があります。 ListDashboards / aws cloudwatch list-dashboards – アカウント内のすべてのダッシュボードのリスト、または共通のプレフィックスを共有するサブセットを取得します。 GetDashboard / aws cloudwatch get-dashboard – 1 つのダッシュボードの詳細を取得します。 PutDashboard / aws cloudwatch put-dashboard – 新しいダッシュボードを作成するか、既存のダッシュボードを更新します。 DeleteDashboards / aws cloudwatch delete-dashboards – 1 […]

Read More

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

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

Read More

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

この投稿と付随するコードの作成には、下記3名による多大な貢献がありました。 Jeremy Cowan Solutions Architect Anuj Sharma DevOps Cloud Architect Peter Dalbhanjan Solutions Architect コンテナ化されていないトラディショナルな環境にソフトウェアアップデートを展開するのは難しく、リスクを伴います。デプロイパッケージまたはスクリプトを記述するときは、ターゲットマシンが特定の状態にあると仮定する必要があります。ステージング環境が本番環境の正確なミラーイメージでない場合、デプロイは失敗する可能性があります。デプロイが失敗すると、アプリケーションの最後の正常なバージョンを再デプロイするまでサービス停止が起きることがあります。あなたが運用管理者だとしたら、サービス停止があると夜間に起きていなければいけないでしょう。 リリース内容の審査が終わるまでユーザーに新しいバージョンをさらすことなく、本番環境でテストをおこないたいと考えているお客様が増えています。人によっては、新機能が多くの人たちに公開される前に少数の顧客に対してのみ公開し、フィードバックを集めることもあるでしょう。これは、カナリア分析またはカナリアテストと呼ばれる手法です。この記事では、Application Load Balancersとtarget 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 […]

Read More

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 […]

Read More

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

5月末〜6月頭に開催されたAWS Summit Tokyo 2017において、を実際にご利用頂いているお客様からの導入事例セッションと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 […]

Read More

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 […]

Read More

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テーブルに記録されます。 ログ(LOG)アクションは、情報を記録した上でクエリーの監視を継続します。 ホップ(HOP)アクションは、クエリーを中断し、次に合致するキューで再起動します。 もし合致するキューがない場合、当該クエリーはキャンセルされます。 アボート(ABORT)アクションは、ルールに違反したクエリーをアボートさせます。 それでは、以下の三つのシナリオを用いて、クエリーモニタリングルールをどのように使うかを見ていきましょう。 シナリオ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 > […]

Read More