Amazon Web Services ブログ

Amazon QuickSight – セッション単位の新料金、新リージョン(東京)、多数の新機能

Amazon QuickSightは、高速かつ容易に利用できるビッグデータ用のビジネス・アナリティクスサービスです。QuickSightはデータウェアハウスであるAmazon Redshiftや、Amazon Relational Database Service (RDS)に蓄積されたデータやAmazon S3に保存されたフラットファイル、もしくはコネクター経由でオンプレミス環境にあるMySQL、PostgreSQL、SQL Server等にアクセスし、企業が保持する多様なサイズや形式のデータを分析する事を可能にします。QuickSightは数十、数百もしくは数千人規模の組織に対して、必要な性能をスケールして提供可能です。 本日、QuickSightの新しいセッション単位の新しいプライシングに加えて、サポートリージョンの追加、および重要な新機能をローンチします。ではそれぞれを見ていきましょう。

Read More

Amazon API Gatewayを使用したSAP用APIのデプロイ

この記事は、Amazon Web Services (AWS)のSAPデジタルコンサルタント、KK Ramamoorthyによるものです。 お客様、パートナー、そして従業員は、様々なチャネルによるシームレスかつセキュアなユーザー体験を求めています。例えば、Amazon Alexaのような音声認識デバイスを使用して注文するお客様は、モバイルデバイスでも同じ体験を必要とするでしょう。あるいは、モバイルアプリを使用してトレーニングマニュアルにアクセスしているフィールドテクニシャンは、拡張現実アプリでもこれらのマニュアルにアクセスして表示できる必要があります。 このような統一されたユーザー体験を実現するには、アプリケーションプログラミングインターフェイス (API)が重要な役割を果たします。APIとAPI管理プラットフォームにより、使いやすいドメインドリブンのサービスをアジャイル型で、柔軟性、安全性、拡張性のある方法で公開できます。

Read More

Amazon QuickSight の東京リージョン対応がアナウンスされました。

みなさん。こんにちわ。 アマゾン ウェブ サービス プロダクトマーケティング エバンジェリストの亀田です。 開催中のAWS Summit Tokyo 2018で、Amazon QuickSightの東京リージョン対応が発表されました。 Amazon QuickSight は高速なクラウド対応のビジネス分析サービスで、可視化の構築、アドホック分析の実行、データからビジネス上の分析等を行う環境を素早く構築することが可能です。 クラウドのために一から設計された Amazon QuickSight の超高速でパラレル、インメモリの計算エンジン「SPICE」を搭載し、かつ最新のハードウェアイノベーションによって可能になったインメモリ技術、マシンコード生成、データ圧縮を利用しているので、ユーザーが大規模データセットにインタラクティブなクエリを実行し、すばやくレスポンスを得ることを可能にています。 QuickSight のコストは従来の BI ソリューションに比べて 10 分の 1 で、先行投資も、高価なハードウェア購入やインフラストラクチャの管理も、追加のライセンスやメンテナンス料金も不要となっています。 データソースとして以下をサポートしています。 CSV または Excel ファイル Amazon Redshift、Amazon RDS、Amazon Aurora、Amazon Athena、Amazon S3、Amazon EMR (Presto および Apache Spark) などの AWS データソースから取り込んだデータ SQL サーバー、MySQL、PostgreSQL への接続 Salesforce などの SaaS アプリケーションへの接続 AutoGraph と呼ばれる革新的なテクノロジーが活用されており、濃度やデータ型といったデータのプロパティに基づいて最も適切な可視化を選択することが可能です。また、QuickSight iPhone […]

Read More

Amazon Elastic File System (EFS)の東京リージョン対応がアナウンスされました

みなさん、こんにちわ。アマゾン ウェブ サービス ジャパン 、 プロダクトマーケティング エバンジェリストの亀田です。 現在開催中のAWS Summit Tokyo 2018の、弊社代表取締役社長長崎による基調講演において、Amazon Elastic File System (EFS)の東京リージョンにおけるリリースが、2018年7月予定としてアナウンスされました。 EFSは、クラウドのアーキテクチャーをベースに設計された、スケーラブルで、高信頼性、伸縮自在なファイルストレージで、使いやすく、ファイルシステムをすばやく簡単に作成および構成するためのシンプルなインターフェイスを提供しています。 Amazon EC2インスタンスにマウントして利用する形態をとります。従来EC2にマウントして使用するストレージはAmazon EBSというブロックストレージをご提供していました。このEBSは同時に複数のEC2インスタンスからマウントすることができず、いわゆる共有のファイルストレージとして利用することができませんでした。このため、複数のEC2インスタンスからマウント可能なEFSは、日本のお客様からとても多くのご要望をいただいておりました。 また、EBSとことなり容量は自動で拡張するため、低コストでご利用いただくことができます。そして容量の拡張に応じてスループット及びIOPSが向上していく、という特性を持っています。Amazon EFS の TCO 上のメリットについては、こちらをご覧ください。 そして、システムの各オブジェクトは複数のアベイラビリティゾーンで冗長的に保存され、高可用性及び高耐久性が考慮された設計となっています。 NFSv4 プロトコルに対応したOSでご利用が可能です。 AWS Direct Connectという専用線接続サービスを経由して、オンプレミス環境からもストレージとして利用可能な機能も備えています。 - プロダクトマーケティング エバンジェリスト 亀田

Read More

Amazon DynamoDB での多様なクエリのための Z オーダーインデックス: パート 2

以前の AWS データベースに関するブログ記事で、 複数の属性の範囲の境界を使用して Amazon DynamoDB のテーブルを効率的に照会できるように、データを並べ替えることができる Z オーダーインデックスを紹介しました。この記事では、インデックス用のスキーマを作成するプロセスについて説明します。スキーマに含める属性を決定する方法、インデックスのスキーマがクエリの効率に与える影響、さまざまなデータ型の操作方法について説明します。 この記事はパート 1 で説明した概念に基づいていますので、先へ進む前に少し時間をとってその内容を確認されることをお勧めします。 Z オーダーインデックスのスキーマの作成 前の記事で説明したように、インデックスに保存されている各レコードには Z アドレスが割り当てられます。Z アドレスとは固定長のバイナリ値であり、レコードの属性の既知のセットのビットをインターリーブすることで見つけることができます。次の図は、2つの属性 x と y による Z アドレスの計算を示しています。 Z アドレスは、DynamoDB テーブルのソートキー (またはローカルのセカンダリインデックスキー) として使用されます。ソートキーは、高速でバインドされたクエリを可能にするために保存されているテーブルのデータを並べ替えること、パーティション内のレコードを一意に識別することという 2 つの目的を果たします。パーティションおよびソートキーの詳細については、DynamoDB のドキュメントのプライマリキーを参照してください。 スキーマは、テーブルまたはインデックスに保存される情報の構造を記述します。Z オーダーインデックスの文脈では、スキーマには次のものが含まれます。 インデックス付けされる属性の名前 (上記の図の x と y)。 属性がエンコードされる順序 (y に続いて x)。 属性のそれぞれのデータ型 (x と y は符号なし整数、0 以上の整数) とそれらをバイナリで表現する方法。 新しいレコードをテーブルに挿入するか既存のレコードを更新するたびに、そのレコードの Z アドレスを計算する必要があります。同様に、クエリを作成するときは、範囲の境界を表す最小レコードと最大レコードの Z アドレスを計算する必要があります。Z […]

Read More

Amazon Aurora PostgreSQL で読み書き用に pgpool の単一のエンドポイント設定する方法

Amazon Aurora は、プライマリ DB インスタンス (クラスタエンドポイント) と、リードレプリカ (リーダーエンドポイント) のエンドポイントを提供します。Aurora は、クラスタエンドポイントを自動的に更新するので、常にプライマリインスタンスを指し示すようできています。リーダーエンドポイントの読み取り機能は、使用可能なすべてのリードレプリカの読み取り操作の負荷を分散します。 Amazon Aurora Replica では、通常 100 ms 未満のレプリケーションラグが発生します。したがって、アプリケーションで遅延が許容される場合は、クラスタエンドポイントとリーダーエンドポイントの両方を使用して、水平方向に拡張されたデータベースを利用できます (図 1)。 図 1: 使用するエンドポイントを決定するアプリケーションのアーキテクチャ ただし、読み取り用と書き込み用両方のデータベースエンドポイント管理は、複雑なアプリケーションになります。この記事では、pgpool を使った、書き込みデータ量を自動的にクラスタエンドポイントへ、また読み込みデータ量を読み込みエンドポイントに転送する PostgreSQL-Amazon Aurora 互換の単一エンドポイントの構築方法をご紹介します (図 2)。 図 2: pgpool ミドルウェアに基づいたソリューション提案 アーキテクチャ Pgpool は PostgreSQL データベースとデータベースクライアントの間に位置する BSD ライセンスのミドルウェアですこの例では、図 3 のアーキテクチャを使用します。 図 3: PostgreSQL-Amazon Aurora 互換クラスタ用の単一エンドポイントを構築するミドルウェアとしての pgpool の使用 Amazon Aurora クラスタは、1 つのプライマリインスタンス、2 つのアベイラビリティゾーンと 2 […]

Read More

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