Amazon Web Services ブログ

VLC Media Player から クラウド上の AWS Media Services への RTP を使った接続

全 5 回の Blog 連載のうちの最終回である今回は、様々なエンコーダーから AWS Media Services への接続および設定方法を学びます。AWS Media Services はカスタマーに対して、高いスケーラビリティを持つ over-the-top (OTT) ビデオ体験を提供することを可能にします。ライブチャンネルもしくはイベントを配信するには、カメラなどの機器からのビデオ信号をエンコードし、追加的な処理、パッケージング、配信のために、クラウドに送信します。 VLC MEDIA PLAYER と RTP および AWS MEDIA SERVICES を利用したチャンネルの作成 こちらの例では、RTP (Real-Time Transport Protocol) 伝送用エンコーダーとして VLC media player を用いたストリームをセットアップし、クラウド上での動画処理およびパッケージングのための AWS Media Services の設定方法を、ステップ・バイ・ステップの手順でお見せします。 VLC media player は、様々なストリーミングプロトコルをサポートしている、フリーかつオープンソースのクロスプラットフォームのマルチメディアプレイヤーとフレームワークです。 ワークフロー例のダウンロード こちらの例では、下記の方法を学びます。 ・RTP を使った伝送用エンコーダーとして VLC media player をセットアップ ・伝送ストリームを AWS Elemental MediaLive で受けて、adaptive bitrate (ABR) […]

Read More

Amazon SageMaker アルゴリズムのパイプ入力モードを使用する

本日は Amazon SageMaker の内蔵型アルゴリズムのためのパイプ入力モードについて紹介します。パイプ入力モードを使い、データセットが最初にダウンロードされるのではなく、トレーニングインスタンスに直接ストリーミングされます。これは、トレーニングジョブが直ぐに始まり、早く完了し、必要なディスク容量も少なくて済むという意味です。Amazon SageMakerのアルゴリズムは、高速で拡張性が高くなるように設計されています。このブログ記事では、パイプ入力モード、それがもたらす利点、トレーニングジョブにおいてそれをどのように活用できるかについて説明しています。 パイプ入力モードでは、データはディスク I/O なしで実行中にアルゴリズムコンテナに送られます。このアプローチは、長くかかるダウンロードの処理を短縮し、起動時間を大きく短縮します。それによって通常ならファイル入力モードより読込スループットも良くなります。これは、高度に最適化されたマルチスレッドバックグラウンドプロセスによって、データが Amazon S3 から取得されるからです。また、16 TB の Amazon Elastic Block Store (EBS) のボリュームサイズ制限よりもずっと大きいデータセットをトレーニングできます。 パイプモードによって以下のことが可能になります。 データがトレーニングインスタンスにダウンロードされるのではなく、ストリーミングされるため、起動時間がより短くなります。 より高性能なストリーミングエージェントによる I/O スループットの向上 実質的に無制限のデータ処理能力。 内蔵型 Amazon SageMaker アルゴリズムでファイル入力モードまたはパイプ入力モードを活用できます。大きなデータセットにはパイプモードが推奨されているとはいえ、メモリ内に収まる小さなファイルやアルゴリズムのエポック数が多い場合であっても、ファイルモードは有効です。現在、どちらのモードでもトレーニングジョブの小さい実験から、ペタバイト規模の分散型のトレーニングジョブに至るまでさまざまな使用範囲をカバーしています。 Amazon SageMakerのアルゴリズム 大半のファーストパーティのAmazon SageMakerアルゴリズムは、最適化された Protocol Buffers (プロトコルバッファー) のrecordIO フォーマットを使えば最適に動作します。このため、本リリースでは、protobuf の recordIO フォーマット用のパイプモードのみがサポートされています。以下に一覧するアルゴリズムは、Protocol Buffers (プロトコルバッファー) の recordIO にエンコードされたデータセットで使用した場合に、パイプ入力モードをサポートします。 主成分分析法 (PCA) K 平均法クラスタリング 因数分解法 潜在的ディリクレ配分法 (LDA) 線形の学習者 (分類と回帰) […]

Read More

AWS Step Functions と Apache Livy を使用して Apache Spark アプリケーションをオーケストレーションする

Apache Spark の採用は過去数年で大幅に増加しており、Spark ベースのアプリケーションパイプラインを実行することは今や新しい標準とも言えます。ETL (抽出、変換、ロード) パイプラインにある Spark ジョブの要件はそれぞれ異なります。ジョブ間の依存関係を処理し、実行中の順序を維持し、複数のジョブを並行して実行する必要があります。ほとんどの場合、Apache Oozie、Apache Airflow、さらには Cron などのワークフロースケジューラツールを使用して、これらの要件を満たすことができます。 Apache Oozie は、Hadoop ベースのジョブに広く使われているワークフロースケジューラシステムです。しかし、UI 機能が制限されている、他サービスとの統合がしにくい、XML に大きく依存しているなど、一部のユーザーには適していない恐れがあります。一方、Apache Airflow には、強力な UI とモニタリング機能、いくつかの AWS やサードパーティのサービスとの統合など、たくさんの優れた機能が搭載されています。ただし、Airflow は Airflow サーバーのプロビジョニングと管理を必要とします。Cron ユーティリティは強力なジョブスケジューラです。けれども、仕事の細部に関する可視性があまりなく、Cron ジョブを使用してワークフローを作成することは難しいかもしれません。 特定の順序でいくつかの Spark ジョブを実行したいが、それらのジョブをオーケストレーションしたり、別のアプリケーションを管理するのに時間を取りたくないといった、単純なユースケースがあるとしましょう。 今日は、AWS Step Functions を使ったサーバーレスの方法で、このユースケースを取扱います。Amazon EMR 上で、AWS Step Functions でワークフロー全体を作成し、Apache Livy を通じて、Spark とのやり取りを実行します。 この記事では、AWS Step Functions と Apache Livy を使用して、サーバーレスの Spark ベース ETL パイプラインをオーケストレーションする手順の一覧を順に見ていきます。 データを入力する この投稿のソースデータについては、ニューヨーク市タクシーリムジン委員会 (TLC) […]

Read More

Apache MXNet (Incubating) が Keras 2 のサポートを追加

Keras および Apache MXNet (Incubating) のオープンソースプロジェクトへの参画者のおかげで、Keras-MXNet 深層学習のバックエンドが現在利用可能です。Keras は Python で書かれた高水準なニューラルネットワーク API です。CNN および RNN のプロトタイピングを素早く簡単に作成することで知られています。 Keras の開発者は、現在、畳み込みニューラルネットワーク (CNN) のトレーニングおよび再帰型ニューラルネットワーク (RNN) の分散トレーニング向けのハイパフォーマンスな MXNet 深層学習エンジンを使用することができます。コードを数行更新すると、Keras の開発者は、MXNet のマルチ GPU の分散トレーニング機能を使用して、トレーニングスピードを速めることができます。MXNet モデルを保存できることは、このリリースのもう一つの注目すべき機能です。Keras での設計、Keras-MXNet によるトレーニング、本番環境のインターフェイスの実行が大規模な MXNet で可能です。 Keras 2 および MXNet の分散トレーニング この記事では、Keras-MXNet のインストール方法と CNN および RNN のトレーニング方法の説明をします。以前、他の深層学習エンジンで分散トレーニングを実施したことがある場合は、退屈で難しいかもしれません。それでは、Keras-MXNet について内容を見ていきましょう。 インストールは数ステップだけです。 AWS 深層学習 AMI のデプロイ Keras-MXNet のインストール Keras-MXNet の設定 1. AWS […]

Read More

【開催報告】Amazon Redshift 事例祭り(DWHマイグレーション)

先日(5月10日)、「Amazon Analytics (Redshift) 事例祭り」というイベントが開催されました。オンプレミスDWHを利用していた、もしくは現在使用しているお客様がDWHをAWSクラウド上のAmazon Redshiftに移行した経験談を共有していただくという内容のセミナーで、定員の120名を越えるお申込をいただき、会場が満室になる熱気の中で実践的な情報が共有されました。 この記事ではそのイベントの内容をご紹介します。また、各社発表資料へのリンクも掲載しています。

Read More

成功のヒント: GDPR から学んだ教訓

セキュリティは AWS の最優先事項です。これはサービスの開始時から変わりません。GDPR (EU 一般データ保護規則、2018 年 5 月 25 日に施行開始) の導入により、私たちのセキュリティ中心の文化でもプライバシーとデータ保護がより強く意識されるようになりました。締切りよりかなり前でしたが、数週間前に AWS のすべてのサービスが GDPR の基準を満たしていることを発表しました。つまり、お客様の GDPR の課題を解決する 1 つの方法として AWS をご利用いただけるようになりました (詳細は GDPR Center をご覧ください)。 GDPR への準拠に関しては、多くのお客様で順調に準備が進んでおり、当初の不安はかなりなくなったようです。この話題でお客様とお話をさせていただくと、いくつかのテーマが共通しているように感じます。 GDPR は重要です。EU のデータ主体の個人データを処理する場合は、よいプランが必要です。これはガバナンスの問題だけでなく、GDPR に違反した場合には重い罰則があるからです。 この問題の解決は複雑で、多数の要員とツールが必要になる可能性があります。GDPR のプロセスでは多岐にわたる訓練も必要になるため、人員、プロセス、テクノロジーに影響が及びます。 お客様ごとに状況は異なり、GDPR への準拠を評価する方法も多数あります。そのため、お客様のビジネスの特性を意識することが重要です。 ここでは、私たちが学んだ教訓を共有したいと思います。GDPR の課題を解決するために、重要だったのは次の点です。 経営陣の参加が重要です。GDPR の詳細なステータスを当社 CEO の Andy Jassy と定期的に話し合っています。GDPR が非常に重要であることを AWS の経営陣は理解しています。必要な注意が GDPR にまだ向けられていないなら、今すぐ経営トップに知らせる必要があります。 GDPR 関連の作業を集中管理する必要があります。すべての作業の流れを集中管理することが重要です。当然のことのようですが、管理が分散すると、作業の重複やチーム・メンバーの方向性にズレが生じます。 GDPR の課題の解決で最重要のパートナーは法務部門です。お客様独自の環境に対して GDPR をどのように解釈するかを法務部門以外に任せるのは、リスクが大きく、時間とリソースの無駄になる可能性があります。法務部門から適切な助言を得て、方向性を統一して協力し、適切な緊急感を持って前進すれば、分析麻痺による作業停滞に陥らずにすみます。 […]

Read More

Amazon DynamoDB テーブルのストレージをモニタリングするサーバーレスソリューション

Amazon DynamoDB をアプリケーションの NoSQL データベースサービスとして使用する場合に、DynamoDB テーブルが使用するストレージ使用量を追跡したいとしましょう。DynamoDB は、サービスメトリックを Amazon CloudWatch に公開します。CloudWatch は、これらのメトリックをモニタリングおよび分析し、アラームを設定し、さらに AWS リソースの変更に対して自動的に反応します。現在のところ、DynamoDB は、ThrottledRequests、ConsumedWriteCapacityUnits、および ConsumedReadCapacityUnits を含む、多くの有用なメトリックを CloudWatch に送信します。 DynamoDB テーブルのストレージ使用状況を分析し、DynamoDB ワークロードが使用するストレージ使用量の履歴を把握し、ストレージコストを管理することは重要です。例えば、Time to Live (TTL) を使用して、不要なデータや陳腐化したデータを期限切れにしたいとします。そのような場合、ストリームを使用してそのデータを Amazon S3 または Amazon Glacier にアーカイブすることができるのです。この記事では、DynamoDB テーブルのストレージ使用状況をモニタリングする方法について解説します。 ソリューションの概要 DynamoDB は、6 時間ごとにテーブルのストレージ使用状況を更新します。この情報は、DynamoDB DescribeTable API を使用することで取得できます。テーブルのサイズを決定したら、カスタム CloudWatch メトリックを作成して、データを CloudWatch にプッシュできます。このソリューションでは、AWS CloudFormation を使用して、DynamoDB テーブルのストレージ使用状況をモニタリングするワンクリックデプロイメントアーキテクチャを作成する方法を解説します。これはインフラストラクチャをコードモデルとして実装するために必要です。 次の Python スクリプトと AWS CloudFormation テンプレートは、この GitHub リポジトリで入手できます。プロセスの仕組みは、上の図のようになります。(このソリューションは、DynamoDB ワークロードのあるすべての AWS リージョンでデプロイし、DynamoDB テーブルのストレージ使用量を継続してモニタリングすることを忘れないでください。) Amazon CloudWatch Events は、AWS Lambda 関数をスケジュールに従って実行します。 Lambda 関数は、DescribeTable […]

Read More

日本語の AWS SOC1 レポートの提供

日本のお客様から問い合わせの多かった日本語での SOC1 レポートの提供ですが、2018 年 5 月 23 日より日本語の AWS SOC1 レポートの翻訳文書(以下、日本語 AWS SOC1 レポート)を AWS Artifact 経由で提供を開始しました。今回提供開始の日本語AWS SOC1レポートの対象期間は2017年4月1日から2017年9月30日のものとなります。AWS は最新の SOC1 レポートに合わせてのタイムリーな日本語文書の提供に向けて継続して取り組んでいく予定です。また、SOC レポートに関連してお客様から問い合わせの多い質問と回答を下記に記載しています。各 SOC レポートの詳細、および最新の情報に関しては、以下のサイトをご参照ください。 https://aws.amazon.com/jp/compliance/soc-faqs/   ・SOC1レポートの主目的 SOC1は財務報告に係る内部統制に関連する可能性がある AWS の統制環境について、顧客に情報を提供すること、および財務報告に係る内部統制(ICOFR)の有効性に関する評価および意見について、顧客とその監査人に情報を提供することを目的としています。   ・SOC1 レポートの内容 AWS の統制環境に関する説明、および AWS が定義した統制と目標の外部監査に関する説明   ・各 SOC レポートの入手方法 AWS SOC 1 レポート、日本語AWS SOC1レポート、および AWS SOC2 レポートは、お客様が AWS Artifact (AWS のコンプライアンスレポートをオンデマンドで入手するためのセルフサービスポータル)を 経由して直接入手できます。   […]

Read More

FFmpeg から クラウド上の AWS Media Services への RTMP を使った接続

全 5 回の Blog 連載のうちの 4 回目の連載である今回は、様々なエンコーダーから AWS Media Services への接続および設定方法を学びます。AWS Media Services はカスタマーに対して、高いスケーラビリティを持つ over-the-top (OTT) ビデオ体験を提供することを可能にします。ライブチャンネルもしくはイベントを配信するには、カメラなどの機器からのビデオ信号をエンコードし、追加的な処理、パッケージング、配信のために、クラウドに送信します。 FFMPEG と RTMP および AWS MEDIA SERVICES を利用したチャンネルの作成 こちらの例では、RTMP (Real-Time Messaging Protocol) 伝送用エンコーダーとして FFmpeg を用いたストリームをセットアップし、クラウド上での動画処理およびパッケージングのための AWS Media Services の設定方法を、ステップ・バイ・ステップの手順でお見せします。 FFmpeg は、オーディオとビデオを記録、変換、およびストリームする完全なクロスプラットフォームのソフトウェアソリューションです。 ワークフロー例のダウンロード こちらの例では、下記の方法を学びます。 ・RTMP を使った伝送用エンコーダーとして FFmpeg をセットアップ ・伝送ストリームを AWS Elemental MediaLive で受けて、adaptive bitrate (ABR) のストリームにエンコードする設定方法 ・AWS Elemental MediaLive の出力を AWS Elemental […]

Read More

Amazon RDSデータベースプレビュー環境が ご利用可能になりました

Amazon RDSの利便性と柔軟性を備えたPostgreSQLデータベースエンジンのベータ版、リリース候補、およびearly productionバージョンを簡単にテストできる、Amazon RDSデータベースプレビュー環境が利用可能になりました。 PostgreSQLコミュニティから新しいバージョンがリリースされてから数日または数週間以内に、PostgreSQLの新しい機能をテストすることができるようになりました。現在のところ、Amazon RDSデータベースプレビュー環境では、PostgreSQLの次のメジャーバージョンの開発、ベータ、およびリリースの候補バージョンが提供されています。Amazon RDSデータベースプレビュー環境のデータベースインスタンスは全ての機能を有し、データベースのプレビューバージョンを自動でインストールし、プロビジョニング、および管理をお客様側で行って頂く必要がなく、新しいデータベースエンジンをテストできます。Amazon RDSデータベースプレビュー環境のデータベースインスタンスの価格は、米国東部(オハイオ)リージョンで作成されたRDSインスタンスと同じ価格です。 本番環境クラスのセキュリティ、パフォーマンス、信頼性、管理性、および可用性を確保するために、Amazon RDSは多くのテストを行った後で初めて新しいデータベースバージョンをリリースしてきました。Amazon RDSデータベースプレビュー環境は、新バージョンのデータベースエンジンがAmazon RDS環境への統合とテストが完了するのを待たずに、新しいPostgreSQLデータベースエンジンの信頼性、機能性、およびパフォーマンスの向上をすぐにお客様がテスト出来る環境を提供することで、お客様のリリースサイクルを数週間短縮することが可能になります。PostgreSQLのプレビュー版は、PostgreSQLコミュニティによってGA版がリリースされ、その後Amazon RDSでサポートされるまでAmazon RDSデータベースプレビュー環境で使用できます。 Amazon RDSデータベースプレビュー環境は、最新世代のインスタンスクラス(現在のところT2、M4、およびR4)でSingle-AZインスタンスとMulti-AZインスタンスの両方をサポートし、KMSキーを使用した透過的暗号化もサポートしています。Amazon RDSデータベースプレビュー環境データベースインスタンスは、最大60日間保持された後、自動的に削除されます。Amazon RDSデータベースのスナップショットは、プレビュー環境で作成し、データベースインスタンスの作成や復元に使用できますが、プレビュー環境内でコピーしたり、プレビュー環境外にコピーしたりすることはできません。代わりに、PostgreSQL標準のダンプとロード機能を使用して、データベースのロードとアンロードを行うことができます。 既存のAmazon RDSプロダクション環境のSLAはAmazon RDSデータベースプレビュー環境のインスタンスには適用されません。また、プレビュー環境で作成されたインスタンスについては、Amazon Customer Supportでサポートチケットを開くことはできません。私たちは、Amazon RDSデータベースプレビュー環境向けのフォーラムを作成しました。Amazon RDSチームは、PostgreSQLデータベースの候補バージョンとAmazon RDSデータベースプレビュー環境の両方に関する情報などをこちらで共有致します。 Amazon RDSデータベースプレビュー環境は今日からご利用可能です。詳細については、http://aws.amazon.com/rds/databasepreviewを参照してください。   翻訳は星野が担当しました。原文はこちら

Read More