Amazon Web Services ブログ

Category: Analytics

Amazon Kinesis Agent for Microsoft Windows を使用して、Windows イベント、ログ、およびメトリックを収集、解析、変換、ストリーム配信する

Amazon Kinesis Agent for Microsoft Windows (KA4W) を含む完全なデータパイプラインは、Windows ベースのサービスのパフォーマンス、セキュリティ、および可用性を分析および監視するのに役立ちます。Windows サービスにほぼリアルタイムのダッシュボードとアラームを構築できます。また Amazon Athena、Kibana、Amazon QuickSight、Amazon CloudWatch などの可視化およびビジネスインテリジェンスツールを使用して、迅速に位置の特定、診断、および解決を行うこともできます。 KA4W は、ログを解析して JSON などの標準形式に変換することで、クラウドベースのログ処理を排除します。これらの形式は、データパイプラインの可視化ツールやビジネスインテリジェンスツールですぐに使用できます。 KA4W を使ってみた経験についてあるお客様から寄せられた声を少しご紹介します。 「Microsoft Windows 用の新しい Amazon Kinesis Agent は、複数の相互接続されたシステム間の複雑なオーケストレーションを排除することで、ログをストリーミングするワークフローを簡略化しました。エージェントはセットアップ、構成、更新が容易でしたが、最も重要な点は、パフォーマンスが大幅に改善された点です。総体的に見て、Amazon Kinesis Agent for Microsoft Windows は、環境内の問題の可視性を大幅に改善し、運用コストを著しく削減するポテンシャルを秘めています」- Sanjay Kumar 氏、シニアソフトウェアエンジニア、Autodesk Inc. この記事では、新しい Kinesis Agent for Windows が Windows アプリケーション、サーバー、およびワークステーションに関連するストリーミング分析のユースケースをどのように行うかを検証します。新しいエージェントを使い始める方法もご紹介します。KA4W を使用してリアルタイムデータを Amazon Kinesis サービスにプッシュすることで、次のようなさまざまな運用上の問題を解決できます。 枯渇したスコープの場合に IP リースが拒否されたことを識別するための Dynamic Host […]

Read More

Amazon Redshift を使用して、デジタルコンテンツを収益化するプロデューサーを支援している Narrativ

Narrativ は、彼ら自身の言葉によれば、「Narrativ は次世代のデジタルコンテンツプロデューサーのための収益化技術を構築しています。当社の製品ポートフォリオには、毎月数百万ドルの広告主価値と数十億データポイントを生成するリアルタイム入札プラットフォームとビジュアルストーリーツールが含まれています」ということになります。 Narrativ では、過去 15 ヶ月間に当社の製品によって生成されたデータが同様に桁違いに増加し、プラットフォームの使用量が大幅に増加しました。このブログ記事では、AWS を使用した、堅牢でスケーラブルで、パフォーマンスが高く、費用対効果の高い分析環境への進化を共有します。また、データウェアハウジングとデータレイク分析の過程で学んだベストプラクティスについても説明します。 Narrativ の継続的な成長の加速を見越して、私たちは昨年末、次の規模の計画を立て始めました。当社では Amazon Redshift をデータウェアハウスとして使用してきており、非常に役に立っています。データが増え続ける中、Amazon S3 をデータレイクとして利用し、Amazon Redshift Spectrum の外部テーブルを使用して S3 で直接データを照会しました。これにより、コストや複雑さに対するトレードオフなしで、ニーズを満たすためにストレージやコンピューティングのリソースを容易に個別に拡張できるようになったことを嬉しく思いました。 このプロセスで、Redshift Spectrum での作業を簡素化し、多数のベストプラクティスをカプセル化する Spectrify を作成しました。Spectrify は、簡単なコマンドで次の 3 つのことを実現します。まず、Amazon Redshift のテーブルをコンマ区切り値 (CSV) 形式で S3 にエクスポートします。次に、エクスポートされた CSV ファイルを並行して Apache Parquet ファイルに変換します。最後に、Amazon Redshift クラスターに外部テーブルを作成します。これで、クエリは Amazon Redshift のデータを使用して、膨大な量の Parquet データを S3 で展開し、すぐに結果を返すことができるようになりました。   上の図は、Amazon S3 の Parquet データと Amazon […]

Read More

Amazon Athena で CTAS ステートメントを使用して、コストを削減し、パフォーマンスを向上させる

Amazon Athena は、標準 SQL を使用して Amazon S3 でのデータの分析を簡易化するインタラクティブなクエリサービスです。Athena はサーバーレスであるため、インフラストラクチャの管理は不要であり、実行したクエリにのみ課金されます。Athena は最近、SELECT クエリまたは CREATE TABLE AS SELECT (CTAS) ステートメントの結果を使用するテーブルの作成のサポートをリリースしました。 アナリストは、CTAS ステートメントを使用して、データのサブセットまたは列のサブセット上の既存のテーブルから新しいテーブルを作成することができます。また、Apache Parquet や Apache ORC などのカラムナ形式にデータを変換し、分割するオプションもあります。Athena は、結果として得られたテーブルとパーティションを AWS Glue データカタログに自動的に追加し、その後のクエリですぐに使用できるようにします。 CTAS ステートメントは、大きなテーブルから構築された小さなテーブルでクエリを実行できるようにすることで、コストを削減し、パフォーマンスを向上させます。この記事では、元のデータセットよりも小さい新しいデータセットを作成し、その後のクエリをより高速に実行できるという、CTAS の使用の利点を示す 3 つのユースケースについて説明します。これらのユースケースではデータを繰り返し照会する必要があると想定して、より小さく、より最適なデータセットを照会して、より迅速に結果を取得できるようになりました。

Read More

SimilarWeb が、Amazon Athena と Upsolver を使って毎月数百テラバイトのデータを分析する方法

これは、SimilarWeb のデータ収集およびイノベーションチームのリーダーである Yossi Wasserman 氏の寄稿です。 SimilarWeb は、同社の説明によれば、「SimilarWeb は、インテリジェンス市場の先駆者であり、デジタル世界を理解するための標準です。SimilarWeb は、すべての地域のすべての業界のウェブサイトまたはモバイルアプリに関する詳細な情報を提供します。SimilarWeb は、マーケティング担当者、アナリスト、セールスチーム、投資家、エグゼクティブなどがデジタル世界で成功するために必要な洞察を活用して、企業が意思決定を行う方法を変えています。」 SimilarWeb は、デジタル世界全体で何が起こっているのかについての洞察を提供するマーケットインテリジェンスの会社です。何千社もの顧客がこれらの洞察を活用して、マーケティング、販売促進、投資決定などの戦略を強化する重要な判断を下しています。当社のソリューションがもたらす意思決定の重要性が、こうした情報を効果的に収集して使用する当社の能力を強調しています。 特に、私が率いているチームは SimilarWeb のモバイルデータ収集の監督を担当しています。現在、毎月数百 TB の匿名データを処理しています。 欠陥のあるデータや不完全なデータに基づいて顧客の洞察を提供することはできないので、データ収集プロセスは SimilarWeb にとって重要です。データ収集チームは、新しいタイプのデータ、パートナーの統合、全体的なパフォーマンスなどを可能な限り迅速に効率よく分析することを必要としています。チームは可能な限り早期に異常を特定し、対処することが不可欠です。このプロセスをサポートするツールは、大きな利点をもたらします。 SimilarWeb のモバイルデータ収集の技術的課題 数百 TB のデータが、異なるソースから毎月 SimilarWeb にストリーミングされます。データは複雑です。 数百のフィールドがあり、その多くは深くネストされており、null 値を持つものも数多く含まれています。データをきれいにし、正規化し、照会のために準備する必要があるため、こうした複雑さから技術的な課題が生じます。 最初の選択肢は、実行に数時間かかる毎日のバッチ処理で SimilarWeb のすべてのデータを処理する、既存のオンプレミス Hadoop クラスターを使用することでした。ビジネスクリティカルな監視にとって、24 時間の遅延は受け入れられません。 そこで、Hadoop を使用して新しいプロセスを開発することを検討しました。しかしながら、それには私たちのチームが毎日の作業から離れて、抽出、変換、ロード (ETL) ジョブのコーディング、スケール、維持に集中することが必要です。また、異なるデータベースを扱う必要があるため、チームが業務に集中する妨げともなります。そのため、チームのメンバー全員が新しいレポートを作成し、不一致を調査し、自動化されたテストを追加できるようなアジャイルソリューションが必要でした。 また、コンピューティングのボトルネックを引き起こした別個を数える問題もありました。別個を数える問題とは、反復要素を含むデータストリームで別個の要素の数を数えるのが難しいという問題です。たとえば、デバイス、オペレーティングシステム、国別など、数十億もの可能なセグメントの一意のビジター数を追跡します。別個を数えることは非加算的集約であるため、一意のビジターの正確な数を計算するには、通常、多くのメモリ集約型コンピューティングノードが必要です。 Amazon Athena を選んだ理由 こうした課題を解決するために、当社は Amazon Athena を選びました。  Athena が、もたらしたもの: SQL を使用する高速な照会 — 私たちのチームは SQL を使用してデータを照会したいと考えていましたが、従来の SQL […]

Read More

Pagely が、カスタマーサポートの分析を容易にするために AWS でサーバーレスデータレイクを実装

Pagely は、マネージド型 WordPress ホスティングサービスを提供する AWS アドバンスドテクノロジーパートナーです。当社の顧客は、使用、請求、サービスのパフォーマンスの可視性を向上させるために継続的に当社にプレッシャーをかけています。こうした顧客により良いサービスを提供するため、サービスチームは、アプリケーションサーバーが作成したログに効率的にアクセスする必要があります。 以前から、当社ではオンデマンドで基本的な統計を集めるシェルスクリプトを利用していました。最大の顧客のログを処理する場合、Amazon EC2 インスタンスで実行される最適化されていないプロセスを使用して 1 件のレポートを作成するのに 8 時間以上かかりました—時には、リソースの制限のためにクラッシュすることがありました。そこで、従来のプロセスの修正にさらに力を注ぐのではなく、適切な分析プラットフォームを実装する時が来たと判断しました。 当社の顧客のログはすべて、圧縮された JSON ファイルとして Amazon S3 に保存されています。Amazon Athena を使用して、これらのログに対して直接 SQL クエリを実行しています。データを準備する必要がないため、このアプローチは優れています。単にテーブルとクエリを定義するだけです。JSON は Amazon Athena でサポートされているフォーマットですが、パフォーマンスやコストに関して最も効率的なフォーマットというわけではありません。JSONファイルは、データの各行から 1 つまたは 2 つのフィールドを返すだけであってもその全体を読み取る必要があるので、必要以上に多くのデータをスキャンしなくてはなりません。さらに、JSON を処理するのが非効率であるため、クエリ時間が長くなります。 30 分のクエリタイムアウト限度に達したため、Athena で最大の顧客のログを照会することは理想的ではありませんでした。この制限を増やすことはできますが、クエリは既に必要以上に時間がかかるようになっていました。 この記事では、Pagely が AWS アドバンスドコンサルティングパートナーである Beyondsoft とどのように協力して、Beyondsoft が開発したオープンソースツールである ConvergDB を使用して DevOps 中心のデータパイプラインを構築したかについて説明します。このパイプラインでは、AWS Glue を使用してアプリケーションログを最適化されたテーブルに変換し、Amazon Athena を使用して迅速かつ費用対効果の高いクエリを実行できます。 Beyondsoft との協力 当社は、できるだけ少ないオーバーヘッドで、エンジニアがデータに簡単にアクセスできるようにするために何かを行う必要があることを知っていました。クエリ時間を短縮するために、データをより最適なファイル形式にしたいと考えていました。無駄のない企業なので、当社には技術を深く掘り下げる余裕はありませんでした。このギャップを克服するために、Beyondsoft と協力して、データレイクの最適化と管理に最善のソリューションを決定しました。 ConvergDB […]

Read More

Amazon QuickSight でメールレポートとデータラベルのサポートを開始

今日は、Amazon QuickSight でご利用いただけるようになった、メールレポートとデータラベルについてご紹介します。 メールレポート Amazon QuickSight のメールレポートでは、定期的および 1 回限りのレポートを受け取ることができます。このレポートはメールボックスに直接配信されます。メールレポートを使用することで、Amazon QuickSight アカウントにログインすることなく最新の情報にアクセスできます。また、メールレポートでデータにオフラインでアクセスすることもできます。より深く分析および考察するために、メールレポートをクリックするだけで、Amazon QuickSight のインタラクティブダッシュボードに移動できます。 メールを使用してレポートを送信する 作成者は Amazon QuickSight アカウント内でダッシュボードにアクセスできるユーザーに、1 回限りまたは定期的なメールレポートを送信するよう選択できます。受信者のユーザー設定に応じて、デスクトップまたはモバイルレイアウト用にメールレポートをカスタマイズできます。 ダッシュボード用にメールレポートを有効化するのは簡単です。ダッシュボードページで [Share] (共有) メニューにナビゲートし、[Email Report] (メールレポート) オプションを選択します。ダッシュボード上でメールレポートを送信する、またはスケジュールを変更するには、ダッシュボードの所有者か共有所有者である必要があります。 この画面ではスケジュール、メールの詳細 (たとえば、件名の行)、受信者のオプションを指定してメールレポートを構成できます。 メールレポートがダッシュボード用に有効化されたあとは、そのダッシュボードにアクセスできる全ユーザーが、メールレポートのサブスクリプションを登録または解除できます。また、受信者は自分のアカウント内でダッシュボードにナビゲートすることで、レイアウト設定 (モバイルまたはデスクトップ) を変更することもできます。また、作成者は書式設定とレイアウトが正しいかを確認するために、自分自身にテスト用のメールレポートを送信することもできます。 メールレポートがスケジュールされたあとは、指定された頻度とタイミングでレポートが配信されます。Amazon QuickSight ダッシュボードの所有者は、メールレポートの配信を一時停止したり、スケジュールされた配信とは別に 1 回限りのレポートを送信することもできます。何らかのエラーがあった、またはダッシュボードに関連付けられた、基となる SPICE データセットの更新に失敗した場合は、Amazon QuickSight は自動的にレポートの配信をスキップします。Amazon QuickSight はこのような場合、ダッシュボードの所有者にエラーレポートも送信します。 料金表: メールレポートは Amazon QuickSight Enterprise Edition でご利用いただけます。Amazon QuickSight の作成者の場合、メールレポートは毎月のサブスクリプション料金に含まれています。作成者は 1 か月間無制限でメールレポートを受け取ることができます。Amazon QuickSight の読者の場合、メールレポートの料金はセッション単位の料金モデルが適用されます。読者の場合、受信するメールレポート […]

Read More

Amazon Elasticsearch Service のインプレースバージョンアップグレード

本日、Amazon Elasticsearch Service (Amazon ES) は、バージョン 5.1 以降を実行するドメイン用のインプレース Elasticsearch アップグレードをサポートすることを発表しました。この新しい機能では、数回のクリックだけで、同じメジャーバージョン内での最新リリース (例えば 5.3 から 5.6 など) に、またはメジャーバージョンの最新リリースから次のメジャーバージョンの最新リリース (例えば 5.6 から 6.3) に移行できます。  また、同じドメインエンドポイント URL を保持しているため、ドメインと連動するサービスでは、新しいバージョンにアクセスするのに設定を変更する必要はありません。 これまで手作業でドメインアップグレードしていたのと比べて、新しい機能では新しい方法で操作を簡素化しています。この機能ができる前は、手動で以前のバージョンのスナップショットを作成し、対象バージョンの新しいドメインを作成し、手動でインデックススナップショットを新しいドメインに復元し、さらには新しいドメインを示すにアプリケーション構成に調整する必要がありました。 このブログ記事では、5.1 Elasticsearch ドメインから 6.3 Elasticsearch ドメインに移行する方法を説明します。 新しい機能でできること アップグレードプロセスは自動化しているため、一連のイベントは慎重に計画されており、対象バージョンへと正常に移行することが可能です。アップグレード中、ドメインに要求が追加される可能性もあります。 このプロセスには、以下のものが含まれます。 アップグレードをブロックする可能性のある問題の確認 アップグレードが失敗した場合に、ロールバックに対処するための Elasticsearch クラスタのスナップショットの作成 新しい Elasticsearch 版でのシャードの再配置 5.1 から 5.6 へのアップグレードの開始 アクティブなドメインのインプレースバージョンのアップグレードを実行するには、AWS マネジメントコンソールにサインインし、[Elasticsearch Service] を選択します。Amazon ES コンソールで、リストから自身のドメイン名を選択し、ダッシュボードを開きます。次に、[ドメインをアップグレード] を選択します。 対象となるアップグレードバージョンと、今すぐドメインをアップグレードするか、またはアップグレードの適格性を確認するかのオプションが表示されます。次のように [アップグレードの適格性を確認する] を選択すると、サービスはドメインをターゲットバージョンにアップグレードするためのチェックを実行します。 アップグレードの適格性のチェックを送信したら、[アップグレード履歴] […]

Read More

地震を追跡中: Amazon Redshift によりETL処理を通じて視覚化のための非構造化データセットを準備する方法

組織が分析慣行を拡大し、データ科学者やその他の専門家を雇用するにつれ、ビッグデータのパイプラインはますます複雑になります。高度なモデルが毎秒収集されるデータを使用して構築されています。 今日のボトルネックは分析技術のノウハウではない場合がよくあります。むしろ、クラウドには適さないことがあるツールを使用した ETL (抽出、変換およびロード) ジョブの構築と維持の難しさがボトルネックになっています。 この記事では、この課題の解決策を示します。私は数年にわたり、地球のあちこちで記録された地震イベントの中途半端に構造化されたデータセットから始めます。私は地球の表面自体、つまり構造プレートストラクチャを形成する岩の性質に関する広範囲な洞察を取得して、Amazon QuickSightのマッピング機能を使用して視覚化ようとしました。

Read More

AWS DevDay Tokyo 2018 Database トラック資料公開

Database フリークな皆様、こんにちは!AWS DevDay Tokyo 2018 Database トラックオーナーの江川です。 2018 年 10 月 29 日(月)〜 11 月 2 日(金)にかけて、AWS DevDay Tokyo 2018 が開催されました。本記事では、11/1(木)に実施された Database トラックのセッション資料をご紹介します。 セッション資料紹介に先立ち、お客様セッションとしてご登壇いただいた、Sansan株式会社間瀬様、株式会社ソラコム安川様、Amazon Pay 吉村様にお礼申し上げます。併せて、ご参加いただいた皆様、ストリーミング配信をご覧いただいた皆様ありがとうございました。   ●お客様セッション資料 AWSサービスで実現するEightの行動ログ活用基盤(Sansan株式会社 間瀬哲也様) AWSサービスで実現するEightの行動ログ活用基盤 DynamoDB Backed なテレコムコアシステムを構築・運用してる話(株式会社ソラコム 安川 健太様) AWS Dev Day Tokyo 2018 | Amazon DynamoDB Backed な テレコムコアシステムを構築・運用してる話 DynamoDBとAmazon Pay で実現するキャッシュレス社会 公開調整中。後日公開された場合は本記事をアップデートします。 ●AWSセッション資料 DevOps with Database on […]

Read More

Amazon EMR クラスター上でストレージを動的にスケールアップする

Amazon EMR クラスターのような管理された Apache Hadoop 環境では、クラスター上のストレージ容量がいっぱいになると、それに対処する便利なソリューションはありません。この状況は、クラスター起動時に、Amazon Elastic Block Store (Amazon EBS) ボリュームを設定し、マウントポイントを設定するために発生します。そのため、クラスタの実行後にストレージ容量を変更することは困難になります。これに適したソリューションとしては、通常 、クラスターにさらにノードを追加し、データレイクにデータをバックアップしてから、より大きな記憶容量を持つ新しいクラスターを起動する方法があります。または、ストレージを占有するデータを消去してもよい場合は、通常、余分なデータを削除するという方法があります。 Amazon EMR で管理可能な方法により、この問題に対処する際の役に立つ、Amazon EBS のElastic Volumes 機能を使用してストレージを動的にスケールアップする方法を説明します。この機能で、ボリュームの使用中に、ボリュームサイズを増やしたり、パフォーマンスを調整したり、ボリュームタイプを変更することができます。変更が有効になっている間も、EMR クラスターを継続使用して、大きなデータアプリケーションを実行できます。

Read More