Author: AWS Japan

ミックスワークロードの環境下では、ビジネス上の要求を満たすために、バッチとインタラクティブのワークロード双方が同時に実行されます。ミックスワークロードを管理し構成するには、アクセスパターンやシステムリソースの使われ方、およびパフォーマンス要件についての詳細な理解が必要です。 ミックスワークロードでは、一般に、一部のプロセスが他より高い優先順位を必要とします。あるケースでは、これはあるジョブが特定の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最適化クラスター構成のガイドライン 1. 複数のビジネスワークロードを分離し、クエリーを互いに独立して実行する。 ダッシュボードクエリーとETLといった異なるビジネスプロセスをサポートするため、互いに独立したキューを作成します。例えば、ワンタイムクエリーのための独立したキューを作成することは、それらのクエリーがより重要なETLジョブを阻害しないようにするための有益なソリューションと言えます。 また、より短時間で実行されるクエリーは一般的にメモリー使用量が少ないため、それらのワンタイムユーザーやクエリーグループ用のキューには、より低いWLM使用メモリー比率（訳者註：マネジメントコンソール上の”メモリ（％）”の設定値）を設定することができます。 2. 同時実行数やメモリー割り当てをアクセスパターンに合わせてローテーションする。（適合するユースケースの場合） トラディショナルなデータ管理では、ETLジョブはソースシステムから特定のバッチウィンドウ内でデータを取得、整形した後、ターゲットのデータウェアハウスにロードします。このアプローチでは、業務時間中は、BI_USERグループにより多くの同時実行数とメモリを割り当て、ETL_USERには非常に限られたリソースのみを割り当てます。業務時間後は、重くリソースインテンシブなジョブが迅速に完了するよう、ETL_USERへの割り当てを動的に変更またはスイッチすることを、クラスターの再起動なしに行うことが可能です。 注：下記のAWS　CLIコマンドサンプルはデモ目的のために、複数の行で表示されています。実際のコマンドは改行を挟まず一行で実行する必要があります。また、下記のJSON構成にはエスケープクォートが必要です。 WLM設定を動的に変更する方法として、AWSはスケジュールされたLambda関数あるいはスケジュールされたデータパイプライン（ShellCmd）をお勧めします。 3. ミックスワークロード（ETLとBIワークロード）を継続的にサポートないし最適化するために、キューホッピングを使用する WLMキューホッピングは、読み取り専用クエリー（BI_USERのクエリー）が、キャンセルされる代わりにあるキューから別のキューに移動することを可能にします。例えば、以下のスクリーンショットにあるように、二つのキュー（一つはタイムアウトが60秒に設定されたインタラクティブクエリー用のもの、もう一つはタイムアウトなしで設定されたバッチクエリー用のもの）を作成し、同じユーザーグループ（BI_USER）をそれぞれのキューに設定します。WLMは、インタラクティブキューで実行され、タイムアウトしたBI_USERのクエリー（のみ）を、バッチキューに自動的に再ルーティングし再実行します。 この例では、ETLワークロードはBIワークロードクエリーを阻害しません。長時間実行されている読み取り専用クエリーは、自動的にバッチとして分類され、より短時間で完了するクエリーをブロックしないようになります。 4. リソースインテンシブなETLやバッチクエリー用に、スロットカウントを一時的に増やす。 Amazon Redshiftはメモリー不足エラーを回避するために中間結果をディスクに書きますが、ディスクI/Oはパフォーマンスを劣化させる要因となります。次のクエリーは、ディスク上で実行されているアクティブクエリーを表示します。 SELECT query, label, is_diskbased FROM svv_query_state […]

AWS 2017 サンフランシスコサミットのリリース内容やお知らせを細かくチェックしていたユーザーなら Amazon Lex サービスの一般提供が開始し、今すぐご利用いただけるようになったことをすでにご存知かもしれません。Amazon Lex は、開発者が音声やテキストを使用するアプリケーションで対話式のインターフェイス構築を可能にするフルマネージド型の AI サービスです。Lex は Amazon Alexa を使用する Amazon Echo のようなデバイスと同じディープラーニングを使用しています。Amazon Lex のリリースにより、開発者は独自のアプリケーションで違和感のないユーザーエクスペリエンスやリアルな会話のやり取りを構築できます。Amazon Lex は Slack、Facebook Messenger、Twilio SMS に対応しています。こうした人気のチャットサービスを使用し、ユーザーの音声やテキストのチャットボットを簡単に発行することができます。Amazon Lex サービスを試し、独自のアプリケーションに優れた機能を追加するには、今が絶好のチャンスです。 さて、いよいよお知らせです。 この度 AWS チャットボットチャレンジを開催することになりました! AWS チャットボットチャレンジは、問題を解決したり今後のユーザーに向けた付加価値を追加する、他に例のないユニークなチャットボットを構築するチャンスです。AWS チャットボットチャレンジはアマゾン ウェブ サービスと Slack の協力により実現しました。 チャレンジ このチャレンジに参加する開発者は、Amazon Lex を使用して自然な対話式のチャットボットを構築し、バックエンドでロジックプロセスやデータプロセスを実行するために AWS Lambda と Lex の統合を利用することになります。対象となるボットは新しいものでも既存のものでも構いませんが、既存のボットの場合はこのチャレンジのエントリー期間中に Amazon Lex と AWS Lambda を使用できるように更新する必要があります。 ソリューション構築時の制限は、あなたの想像力のみです。それでは、以下にボット作成やデプロイにおける創作力をサポートするアドバイスをいくつかご紹介します。チャットボットをよりユニークにするためのアドバイスについては次をご覧ください。 Slack、Facebook […]

AWS Marketplace の Allison Johnson 氏が、APN の重要なお知らせを伝えるために以下のゲスト投稿を執筆しました。-Ana 昨年 11 月の re:Invent で、AWS のお客様が特定の AWS のサービスの専門知識やスキルを持つパートナーを AWS パートナーネットワーク (APN) で見つけられるよう支援する、AWS Service Delivery Program を発表しました。本日は、Service Delivery Program の新しいパートナーソリューションとして管理ツールを追加します。AWS Service Catalog が、このカテゴリで開始する最初の製品となります。APN Service Catalog パートナーは、お客様の組織によって、AWS での使用が承認された IT サービスのカタログの作成を支援します。AWS Service Catalog では、お客様や APN パートナーが一般的にデプロイされた IT サービスを集中管理し、一貫性のあるガバナンスを実現してコンプライアンス要件を満たすのと同時に、承認済みのサービスをユーザーが自己プロビジョニングできるようにします。数千のコンサルティングパートナーを含む膨大な APN パートナーエコシステムがあり、このプログラムにより、Service Catalog の実装経験のあるパートナーを見つけるプロセスが簡略化されます。本日このプログラムを共に開始するコンサルティングパートナーは、BizCloud Experts、Cloudticity、Flux7、Logicworks、および Wipro です。 パートナーが Service Catalog の称号を達成するためのプロセスは簡単ではありません。すべてのパートナーは、Service Catalog を使用して一般的に照会可能な顧客を持っている必要があり、当社のソリューションアーキテクトとほとんど同じように […]

それほど遠く無い昔、今日多くのソフトウェア チームがアプリケーション開発で直面している、リリース期限までにソフトウェア プロジェクトを完成させ変化に対応するというような開発チームに私は所属していました。そこには新しいプロジェクト環境のセットアップ、チームメンバーのコラボレーション、各開発ビルドのコード変更、構成、ライブラリの継続的な追跡を行う日常的なタスクなどの課題がありました。 今日、企業がイノベーションと市場投入をより迅速に行うためには、開発チームがソフトウェアの作成、構築、展開をより簡単かつ効率的に行うことが不可欠になっています。   残念なことに、多くの組織は、より機敏で動的なソフトウェア開発プロセスを追求する上で、いくつかの重要な課題に直面しています。 ほとんどの新しいソフトウェア プロジェクトが直面する最初の課題は、開発者がコーディングを開始する前に完了しなければならない長いセットアップ プロセスです。 このプロセスには、IDEのセットアップ、適切なコード リポジトリへのアクセスの取得、および/またはビルド、テスト、および運用に必要なインフラストラクチャの識別が含まれます。   コラボレーションは、ほとんどの開発チームが直面しうる別の課題です。 プロジェクトのすべてのメンバーに安全な環境を提供するために、チームはさまざまなチームの役割とニーズに応じて別々のプロジェクトとツールを頻繁に設定する必要があります。 さらに、すべてのステークホルダーに、課題の更新、開発の進展、およびソフトウェアの問題の報告に関する情報を提供することは、時間がかかる可能性があります。   最後に、ほとんどの企業では、継続的インテグレーションと継続的デリバリに関するベストプラクティスを採用することで、ソフトウェア開発のスピードを高め、市場投入までの時間を短縮したいと考えています。 これらのアジャイル開発戦略を適用するには、企業が方法論についてチームを教育し、これらの新しいプロセスのためのリソースを設定するための時間を費やす必要があります。   AWS CodeStar：プレゼンテーション   開発チームがソフトウェアを構築する上での課題を緩和し、アプリケーションやソリューションをリリースするペースを向上させるために、AWS CodeStarを紹介します。   AWS CodeStarは、開発プロジェクト全体の設定を簡素化することにより、AWS上でアプリケーションの開発、構築、および展開を容易にするために設計されたクラウドサービスです。 AWS CodeStarには、ソフトウェア プロジェクトのコーディング、ビルド、テスト、デプロイ、および実行のためのプロジェクトとリソースのプロビジョニングを可能にする一般的な開発プラットフォーム用のプロジェクト テンプレートが含まれています。   AWS CodeStarサービスの主な利点は次の通りです： Amazon EC2、AWS Elastic Beanstalk、またはAWS Lambda用のテンプレートを使用して、5つの異なるプログラミング言語を使用して新しいプロジェクトを簡単に作成できます。 JavaScript、Java、Python、Ruby、およびPHPをサポートします。 テンプレートを選択すると、サービスはプロジェクトとアプリケーションに必要な基盤となるAWSサービスをプロビジョニングします。 ソフトウェアチーム全体に対するアクセスおよびセキュリティ ポリシー管理の統一されたエクスペリエンスを提供します。プロジェクトは、適切なIAMコントロール ポリシーで自動的に構成され、安全なアプリケーション環境を確保します。 コードのコミット、ビルドの結果、デプロイメント アクティビティなど、さまざまなアクティビティを追跡するための事前設定されたプロジェクト管理ダッシュボード。 素早い立ち上げと実行に役立つ実行可能なサンプルコードは、Visual Studio、Eclipse、またはGitをサポートする任意のコード エディタなどのお好きなIDEで使用できます。 AWS CodeCommit、AWS CodeBuild、AWS CodePipeline、およびAWS CodeDeployを使用して、自動的に構成された各プロジェクトの継続的なデリバリ パイプライン。 […]

昨年、Amazon Aurora に PostgreSQL 互換のエンジンをリリースするとアナウンスしました。その際、プライベートプレビューのサインアップを紹介し、申し込んでいただくようご案内しました。 そのリクエストの反応は非常に大きいものでした！お客様は既に Amazon Aurora が高い可用性、堅牢性を提供することを理解し、ご自身の PostgreSQL 9.6 アプリケーションを AWS クラウドで動かすのを楽しみにされていました。 Opening up the Preview 本日、興味をお持ちのすべてのお客様に Amazon Aurora with PostgreSQL Compatibility の プレビューを開放し、こちらからサインアップ可能となります。プレビューは、米国東部(バージニア北部)リージョンで実施され、従来の環境で運用されていたPostgreSQL に比べて、2-3倍の性能を提供します。このプレビューでは、高速で低レイテンシなリードレプリカをすばやく簡単に作成することも可能です。 Amazon RDS Performance Insights もPreview にてご利用可能です 本プレビューには、Amazon RDS Performance Insights も含まれます。このツールを利用することで、各クエリの詳細を含む細かいレベルでデータベース性能を確認することができます。Performance Insight ダッシュボードを通して、データベースの負荷を可視化し、SQL, waits, users, hostsという観点でフィルタリングできます: — Jeff; 原文: Sign up Today – Preview of Amazon Aurora with […]

既にAmazon DynamoDBの事はご存知の方が多いと思います。ご存じのように、必要なだけのテーブルスペース、読み込み容量、書き込み容量に対応できるように拡張されたフルマネージドのNoSQLデータベースです。応答時間は1桁のミリ秒単位で測定され、多くのお客様がadtech、IoT、ゲーム、メディア、オンライン学習、旅行、電子商取引、金融など、さまざまな種類のアプリケーションにDynamoDBを使用しています。一部のお客様では一つのDynamoDBテーブルに100TB以上のデータを格納し、1秒当たり何百万もの読み取りまたは書き込み要求を行います。 Amazonの小売サイトはDynamoDBに依存しており、Black Friday、Cyber​​ Monday、Prime Dayなどの短時間で高強度のイベントに関連するトラフィックの急増に耐えます。 DynamoDBは、あらゆるアプリケーションやワークロードに対して、高速で一貫性のあるパフォーマンスのメリットを提供することができますが、常に改善の余地があります。いくつかのワークロード（ゲームやadtechが代表的な例ですが、他にもたくさんあります）のビジネス価値は、低レイテンシかつ高性能な読み取り処理を行えるデータベースによってもたらされます。できるだけ早くDynamoDBからデータを取得する機能により、クリックスルー率が最も高いゲームや広告の反応が速くなります。   Amazon DynamoDB Accelerator このような重い読み込み処理を必要とする方の為に我々はパブリックプレビューでAmazon DynamoDB Acceleatorをローンチしました。DAXとも呼びます。 DAXはフルマネージドのキャッシュサービスでDynamoDBテーブルの前段（論理的に）に置かれます。Write – throughモードで動作し、DynamoDBとAPI互換を持っています。キャッシュからレスポンスが返る時はマイクロセカンドのレスポンスを実現し、eventually – consistentなread heavyなワークロードに特に向きます。DAXはシームレスかつ簡単に使えます。シンプルにDAXクラスターを作成する事が出来、アプリケーション側に読み書きのエンドポイントのターゲットとしてDAXを指定するだけです。DAXにパッチを当てるオペレーションをしたり、クラスタのマネジメントやレプリケーション、障害について心配することはありません。 DAXクラスタは1~10ノードで構成されます。読み込み処理の量に応じてノードを追加する事が可能です。クラスタでキャッシュ出来るサイズ（working setとも呼ばれる）はベースとなるノードの大きさ（dax.r3.large から dax.r3.8xlargeまで選択出来ます）を選択してクラスタを作成します。クラスタはVPC内に作成されAvailabillty Zones毎に分割してノードを配置出来ます。 利用するにはDAX for Java SDKを必要とします。このSDKは作成したクラスタとlow – level TCPでのやりとりを行う事で低レイテンシかつ高スループットを実現するためにチューニングしてあります。（我々は今後他の言語向けSDKについても速やかに対応する方針です。） DAX クラスタの作成 それではDAXクラスタをDynamoDB Consoleから作ってみましょう（APIやCLIでの操作も可能です）。マネジメントコンソールのCreate clusterをクリックして始めます。 まず名前と詳細を入力し次にノードタイプを選択します。そして初期のクラスタサイズを設定します。DAXに与えるIAM roleとpollicyとして私のDynamoDBテーブルにアクセス出来る権限を設定します。（必要な権限が設定されている既存の物を指定する事も可能です。） 例としてコンソールではポリシーとして一つのテーブルにアクセス出来る権限を許可します。アクセスするテーブルを追加したくなったらIAMのコンソール上からポリシーを編集する事で可能です。 次にDAXで使われるノードを配置するサブネットグループを作成します。グループ名とどのサブネットを使うか選択します。 デフォルト設定で起動する事を確認したらLaunch clusterをクリックします。 クラスタは数分で起動します。 次に私のアプリケーションをDAX SDKを使うようにしエンドポイントとして私のDAXクラスタのエンドポイントを指定します。（今回ではdax1.seut3.clustercfg.use1.cache.amazonaws.com:8111です） アプリケーションを起動し実行、Metricsタブを選択するとキャッシュパフォーマンスに関係するメトリクスを見ることが出来ます。 Amazon CloudWatchメトリクスに含まれキャッシュヒットやキャッシュミス、リクエストカウント、エラーカウントなどが見れます。 Alarmsを選択する事でこのメトリクスを利用したCloud Watch Alarmを作る事が出来ます。 例えばキャッシュミスが異常な数になった物を検知する事が出来ます。 Nodesタグを選択する事でクラス内のノードリストを見ることが出来ます。新しいノードを追加したり削除する事が可能です。 DAXがどのように動いているか、DAXのサンプルアプリケーションをインストールして二回実行してみます。初めにDynamoDBにダイレクトアクセスし、キャッシュが無い状態で操作を行います。ベースラインパフォーマンスとしては以下の通りです。 […]

昨年の AWS:Reinvent の最中に、「Amazon Lex – 対話的音声＆テキストインターフェースを構築」をご紹介しました。当時は Amazon Lex をプレビューという形でリリースし、開発者向けの公開としてきました。 本日、Amazon Lex を一般公開できることを喜ばしく思います。本日からお使いいただけます！　プレビュー期間の間に追加された、いくつかの機能をご紹介します。 Slack とのインテグレーション – Slack チャンネルのメッセージに反応してイベントを送る機能を持った 、Lex ボットを作成することができます。ボットの Channels タブをクリックしてフォームを埋めることで、Slack を使うためのコールバック URL を取得することができます。 どのように作成するかについては、チュートリアル（Integrating an Lex Bot with Slack）をご覧ください。 Twilio とのインテグレーション – Twilio の SMS 番号に対してメッセージを送る機能を持った Lex ボットを作成することができます。先ほどと同様に、Channel タブをクリックして Twilio を選択肢、フォームを埋めます。 詳しくは、Integrating an Amazon Lex Bot with Twilio SMS をご覧ください。 SDK サポート – AWS SDK により、iOS、Android、Java、JavaScript、Python、.Net、Ruby、PHP、Go、そして […]

私達はAWS re:InventでFPGA搭載F1インスタンスの開発者プレビューを開始しました。 この発表に対する反応は素早く圧倒的でした！私たちは2000件以上のエントリーを受け取り、200人以上の開発者にハードウェア開発キット(HDK)と実際のF1インスタンスへのアクセスを提供することができました。 当時私が書いた記事で、私はこのように述べました： この高度に並列化されたモデルは、計算集約型の問題を処理するカスタムアクセラレータを構築するのに理想的です。 適切にプログラミングされたFPGAは、ゲノム解析や地震解析、財務リスク分析、ビッグデータ検索、暗号化アルゴリズムなど多くのタイプのアプリケーションに30倍のスピードアップを提供する強力な能力を備えています。 プレビュー中に、パートナーや開発者はあらゆる種類の刺激的なツール、サービス、アプリケーションを開発しています。 それらについてちょっとだけ詳細を紹介します。 一般提供開始 本日、米国東部（バージニア州北部）リージョンでF1インスタンスの一般利用を開始しました、多くの時間が経過する前に他のリージョンにも展開する予定です。 私達は、プレビュー中にフィーチャーや機能を追加し、開発ツールをより効率的に使いやすくしました。 下記が概要です： 開発者コミュニティ – AWS FPGAデベロッパーフォーラムを立ち上げ、FPGA開発者が私たちとやりとりしたり、互いにやりとりする場所を提供しました。 HDKとSDK – EC2 FPGAハードウェア(HDK)とソフトウェア開発キットをGitHubに公開し、プレビュー中に受け取ったフィードバックに応じて多くの改善を行いました。 この改善には、Verilogに加えてVHDL (バーチャルJTAG、バーチャルLED、バーチャルディップスイッチ)、FPGA管理用のAWSライブラリ、FPGAランタイム、AWS OpenCLランタイムライブラリを含むOpenCLのサポートが含まれます。 FPGA Developer AMI – このMarketplace AMIには、RTLコンパイラとシミュレータ、OpenCL開発用 Xilinx SDAccelのフルセットのFPGA開発ツールが含まれており、C4、M4、R4インスタンスで使用するために全てチューニングされています。 FPGAのワーク ここでは、我々のパートナーがF1で行っている印象的なものを紹介します。 Edico Genomeは、リアルタイムで実行される全ゲノムシーケンシングを提供することを期待して、F1インスタンスにDRAGEN Bio-ITプラットフォームを導入しています。 Ryftは、Elastic Stackを拡張したデータ解析と機械学習のアクセラレータであるRyft Cloudを提供しています。 Amazon Kinesis、Amazon Simple Storage Service(S3)、Amazon Elastic Block Store(EBS)、およびローカルインスタンスストレージからのデータをソースとし、大量のビット並列処理を使用してパフォーマンスを向上させます。 この製品は、低レベルのC、C++、Java、およびPython APIとともに、高度なJDBC、ODBC、およびRESTインターフェイスをサポートしています (詳細については、Ryft APIページを参照してください)。 Reconfigure.ioは、Goプログラミング言語を使用してFPGAをプログラムできるクラウドベースのサービスを開始しました。 goroutines (軽量スレッド)、channels、selectsなどの並行性指向の言語機能を活用しながら、クラウドベースの環境からコードをビルド、テスト、展開することができます。 NGCodecはRealityCodecビデオエンコーダをF1に移植し、ブロードキャスト品質のビデオを毎秒80フレームで生成するために使用しました。 […]

現在、数クリックでクラウド上にコンピュートリソースやストレージリソースを構築可能です。現在のチャレンジは、それらのリソースを活用して生のデータを出来る限り素早く、かつ効果的に活用可能な結果に変換することです。 Amazon Redshiftを活用することで、AWSのお客様はペタバイト級のデータウェアハウスを構築し、社内・社外の多様なデータソースからのデータを統合することが可能です。Redshiftは巨大な表に複雑なクエリ（複数の表をジョインする等）を実行することに最適化されているため、小売、在庫、ファイナンシャルデータといった膨大なデータを特別な苦労なく処理することができます。Redshiftにデータをロードした後は、Redshiftパートナーが提供するビジネスインテリジェンス（BI）ツールやエンタープライズレポーティングツールを活用することが可能です。 データウェアハウスを使い続ける上での１つの大きなチャレンジは、継続的に更新される、もしくは追加されるデータを速いペースでロードすることです。高速なクエリーパフォーマンスを提供するために、データをロードするというフェーズでは圧縮、データの正規化や最適化といった作業が行われます。これらの作業自体は自動化、スケールさせることは可能ですが、複雑なロード作業はデータウェアハウス維持にオーバーヘッドと複雑さを追加し、効果的な活用方法を得ることを阻害する場合もあります。 データフォーマットについては別の興味深いチャレンジが存在します。いくつかのアプリケーションはデータウェアハウスの外でデータ元々のフォーマットのままで処理を行っています。他のアプリケーションはデータウェアハウスにデータを取り込み、クエリーを実行しています。この利用方法だと同じデータが２つの場所に存在することになりますのでストレージを効率的に使えていないことになりますし、ロードがタイムリーに行われていない環境では、それぞれのアプリケーションで異なった結果が返る可能性があります。 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 EMRやAmazon Athenaといったサービスを使ってそのデータを処理できるということです。また、頻繁にアクセスされるデータはRedshiftのローカルストレージに維持して、他はS3に置くであるとか、ディメンジョン表に加えてファクト表の直近データだけRedshiftに置き、他の古いデータはS3に置くといったハイブリッドな構成を実現することも可能です。より高いレベルでの並列実行を実現するために、複数のRedshiftクラスターを用意してS3上の同じデータを参照させるということも可能になります。 SpectrumはCSV/TSV、Parquet、SequenceFile、RCFileといったオープンなフォーマットをサポートします。ファイルはGzipかSnappyで圧縮しておくことが可能です。この他のフォーマットや圧縮アルゴリズムについては、今後サポートすることを計画しています。 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 Rekognitionを発表し、私のブログポスト(Amazon Rekognition – 深層学習による画像検出と認識)でご紹介しました。その時ご説明した様に、このサービスは毎日数十億枚の画像を何年にも渡って解析を続けている我々のコンピュータビジョンチームによって作られました。 本日、我々はRekognitionに画像の節度の機能を追加致します。もしユーザにプロフィール写真やその他の画像をアップロードさせる様なウェブサイトやアプリケーションをお持ちでしたら、きっとこの新しいRekognitionの機能を気に入って頂けると思います。 Rekognitionはあなたのサイトに不適切な、いやらしさや露骨な内容を含む様な画像を特定することができます。節度ラベルは詳細なサブカテゴリを提供してくれるので、許容できるまたは不快と思う様な画像のフィルタリングを細かくチューニングすることができます。この機能を使って、画像共有サイト、フォーラム、デートアプリ、子供向けコンテンツプラットフォーム、eコマースのプラットフォームやマーケットプレイス等々を改善することができます。 この機能を使うためには、コードからDetectModerationLabrels関数を呼び出します。レスポンスの中には組み込み済みの分類の中からいくつかの節度ラベルが含まれます: “ModerationLabels”: [ { “Confidence”: 83.55088806152344, “Name”: “Suggestive”, “ParentName”: “” }, { “Confidence”: 83.55088806152344, “Name”: “Female Swimwear Or Underwear”, “ParentName”: “Suggestive” } ] AWS Management Consoleではこの機能を実験するための画像節度デモを使うことができます: 画像の節度は今日からご利用可能です！ —Jeff; 原文: Amazon Rekognition Update – Image Moderation (翻訳: SA岩永)