Amazon Web Services ブログ

Category: Analytics

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の行動ログ活用基盤 from Tetsuya Mase DynamoDB Backed なテレコムコアシステムを構築・運用してる話(株式会社ソラコム 安川 健太様) AWS Dev Day Tokyo 2018 | Amazon DynamoDB Backed な テレコムコアシステムを構築・運用してる話 from SORACOM,INC DynamoDBとAmazon Pay で実現するキャッシュレス社会 […]

Read More

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

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

Read More

【開催報告】AWS Data Lake ハンズオンセミナー 秋

こんにちは。AWS ソリューションアーキテクトの上原誠(@pioh07)です。 9月21日に、「AWS Data Lake ハンズオンセミナー」を開催いたしました。前回行ったワークショップの3回目となります。前回も盛況でしたが、今回も80名近くのお客様にご参加頂きました。 はじめに、AWSにおけるデータ活用のベストプラクティスであるAmazon S3を中心とした Data Lakeについて解説し、ビッグデータ分析基盤の考え方として有名なラムダアーキテクチャの解説を行いました。 当イベントでは、AthenaやRedshiftのAWSサービスを駆使して実際にラムダアーキテクチャを構築してみる、というのがゴールです。とはいえすべてを構築し切るのはボリュームが大きいため、コース別に取り組めるようにハンズオンコンテンツを用意しました。最初にコースの説明を行い、出席いただいたお客様ご自身の課題に合わせてコースを選択頂き、ハンズオンを行っていただきました。今回、参加者も多くいらっしゃいましたので、サポートするソリューションアーキテクトも4名で対応させていただきました。 今回参加できなかった方も、ソリューションアーキテクトのサポートを受けながらハンズオンを行いログ分析を初めてみてはいかがでしょうか?   次回は冬ごろに開催予定です。ご参加お待ちしております。

Read More

【開催報告】Amazon Analytics (Data Lake)セミナー ~AWSで実現するビッグデータ&ログ分析およびデータレイクの構築~

2018年6月21日に、「Amazon Analytics (Data Lake)セミナー」というイベントが開催されました。本セミナーでは、ビッグデータの取り扱いとデータ分析を中心とした利活用、またデータレイクによる効率的なデータの運用を中心テーマにおき、AWS クラウド上での最適な実現方法について、AWS ソリューションアーキテクトおよび Amazon Redshift サービスチームからご紹介しました。また、データの可視化については Amazon QuickSight のデモをご覧いただき、あとでお客さまご自身で QuickSight をお試しいただけるよう、セッション終了後にデモのガイドとサンプルデータを配布しました。 この記事ではそのイベントの内容をご紹介します。また、最後に各発表資料へのリンクも掲載しています。  

Read More

[AWS Black Belt Online Seminar] Amazon QuickSight アップデート:一般公開後に追加された特徴的な新機能 資料及び QA 公開

先日 (2018/8/1) 開催しました AWS Black Belt Online Seminar「Amazon QuickSight アップデート:一般公開後に追加された特徴的な新機能」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20180801 AWS Black Belt Online Seminar Amazon QuickSight アップデート from Amazon Web Services Japan PDF Q. DynamoDBやESなどで溜め込んでいる注文情報などをS3などに定期的に吐き出していく(吐き出すたびに別ファイル)場合でも、今回の紹介された形で定期的にリフレッシュするなどして読み込めますか?それともRDSなどに一度入れないと行けないでしょうか? A. QuickSight用のマニフェストファイルを作成し、 “URIPrefixes”で、バケットやプリフィックスを指定しておくと、その中にある複数のファイルをまとめて1つのデータセットとして扱うことが可能です。バケットにファイルを追加した後に、そのデータセットをREFRESHしてSPICEを更新すると、新しいデータがデータセットに追加されます。また、Athenaをつかっても、上記が実現可能です。データ規模が大きい場合はAthenaの方がフィットするケースも多いと考えられます。 参考:マニフェストファイルの書き方 Q. ダッシュボードは外部サイトなどに埋め込んで閲覧させることはできますか A. ダッシュボードをサイトに埋め込むことはできません。また、ダッシュボードの閲覧にはかならずQuickSightへログインできる必要があるため、企業ホームページのような、だれもがアクセスする外部サイトに使う用途での利用は難しいといえます。 Q. 例えばオンプレではなく、複数契約のレンタルサーバーに格納されているDBのデータをAWSに集約して、QuickSightで分析したい場合、集約の方法としてどのような方法・手段で行うのが一番良いでしょうか。 A. 集約の方法としては、データソースがRDBであれば、AWSのDMS (Database Migration Service)を使うことでAWSへのレプリケーションを実現可能です。もしくはファイルとしてダンプして、S3に転送するという方法も考えられます。AWS上に集めたあとはS3に集約してAthenaで検索する、もしくはRedshift(DWH)に格納する等の方法でデータソースを作成することがかんがえられます。 以上です。 今後のWebinar情報 AWS Innovate Japan 2018 AWS Innovate は、AWS のラーニングを目的とした日本初開催の大規模オンラインカンファレンスです。お客様は時間や場所の制約にとらわれず、Machine Learning、IoT、コンテナ、IT基礎、ソリューションなどのセッションに自由に参加できます。AWS Innovate は 36 […]

Read More

Amazon Elasticsearch Service エラーログの表示

本日、Amazon Elasticsearch Service(Amazon ES)は、Amazon CloudWatch Logs へのエラーログ出力のサポートを発表しました。 この新機能は、エラーログをキャプチャする機能が提供され、サービスの運用中に発生したエラーや警告に関する情報にアクセスできます。 これらの詳細な情報はトラブルシューティングに役立ちます。 この情報を使用して、Amazon ES の利用者と協力してドメイン上のエラーまたは警告を引き起こすシナリオのパターンを特定できます。 この機能へのアクセスは、ドメインが作成されるとすぐに有効になります。 ログを自由にオン/オフすることができ、支払いは CloudWatch の利用した分のみの料金です。 ドメインのエラーログの配信を設定する アクティブなドメインのエラーログを有効にするには、AWS Management Console にサインインし [Elasticsearch Service ]を選択します。 Amazon ES コンソールで、一覧からドメイン名を選択しダッシュボードを開きます。 次に[Logs]タブを選択します。 このペインでは、検索のスローログ、インデックススローログ、およびエラーログを CloudWatch Logs のロググループに出力するように Amazon ES ドメインを設定します。 スローログの設定に関する詳細は、AWS データベースブログのブログ記事Viewing Amazon Elasticsearch Service Slow Logsを参照してください。 エラーログの設定で、[セットアップ]を選択します。 新しいロググループを作成するか既存のロググループを使用するかを選択できます。 次のようなパスとしてロググループの名前を付けることをお勧めします。 /aws/aes/domains/mydomain/application-logs/ このようなネーミングのスキームを使用すると、CloudWatch アクセスポリシーを簡単に適用できます。このポリシーでは次のような特定のパスのすべてのロググループに権限を付与できます。 /aws/aes/domains CloudWatch ロググループにログを配信するには、Amazon ES が CloudWatch Logs […]

Read More