Amazon Web Services ブログ

Category: Analytics

【開催報告】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

【開催報告】Digital Advertising Japan Seminar 2018 – Machine Learning 事例祭り –

こんにちは。AWS ソリューションアーキテクトの八木達也 ( @ygtxxxx ) です。 7月23日に、「Digital Advertising Japan Seminar 2018 – Machine Learning 事例祭り –」を開催いたしました。 AWSジャパン主催でデジタル広告業界の方向けのイベントを開催するのは2年ぶりでしたが、定員60人のところ55名の方にお集まりいただき、盛況となりました。             このイベントは「Digital Advertising、AdTech 領域における Machine Learningの実践知」を「互いに学び合う」ことができる場を作ることを目標としていたため、AWSメンバーによるプレゼンテーションだけではなく、お客様プレゼンテーションを中心としたAGENDAを構成しました。機会学習という領域における、テクノロジー視点でのお取組み、組織育成視点でのお取組み、それぞれの視点で最先端な活動をなさる方々よりご登壇を頂きました。 まずは主催者の唐木/八木よりオープニングセッションを行いました。 唐木より全体の説明を行い、八木より「Machine Learning for Digital Advertising」というタイトルでプレゼンテーションを行いました。 Machine Learning for Digital Advertising from Amazon Web Services Japan 次に、アナリティクス スペシャリスト ソリューションアーキテクトの志村より「AWS ML Services Update」というタイトルでプレゼンテーションを行いました。 AWS ML Update from Amazon […]

Read More

1億2500万人のゲーマーをオンラインでスムーズにプレーするにはどうすればいいでしょうか?Epic GamesがFortniteについて語ってくれました。

FortniteのクリエイターであるEpic Gamesは、2018年7月17日にニューヨークのJavits Centerで開催されたAWSサミットでAWSサービスへオールインを明らかにしました。 ゲーム上に1億2500万人のプレイヤーを想像してください。1億2500万人、それはニューヨークの人口の15倍になります。マルチプレイヤーゲームをプレイしているすべての人が、夢を実現するでしょう。 プレイヤー全員が素晴らしい時間を過ごすことを保証しなければなりません。どのようにしてこの大変多くの人々のすべてのデータを取り扱うのでしょう? Epic GamesのFortnite クリエイターが今年、自分自身でそれを見つました。Fortomiteのこの驚異的な成長により、Epic Gamesが毎月2ペタバイトのデータを扱わなければいけないことを意味します。2,000テラバイトのハードドライブが積み上がっていることを想像してください。どのようにゲームデベロッパーがその規模の情報量を処理するでしょうか?

Read More

Formula 1®、AWSクラウドによりイノベーションを加速、AWS機械学習サービスや映像サービスを導入

  Formula One Group(Formula 1、以下F1)がAWSと提携し、クラウド化プロジェクトを開始しました。 F1は、21か国で開催する国際自動車連盟 (FIA) 主催のF1世界選手権 (FIA Formula One World Championship) の推進を担っています。 F1はITインフラストラクチャの大部分をオンプレミスのデータセンターからAWSクラウドへ移行予定です。フルマネージドな機械学習サービスAmazon SageMaker、イベント駆動型サーバーレスのコンピューティングサービスAWS LambdaやAWS分析サービスなど、さまざまなAWSサービスを通じてレース戦略とデータ追跡システムを強化し、世界で5億人を超えるファンとレーシングチームに、より確実な統計と予測情報を提供します。 F1の放送システムに関しても、複数の施設に及ぶ膨大なコンテンツデータをAWSのクラウドストレージで管理し、AWS Elemental Media Servicesで映像処理を行うというクラウドによるワークフローへ移行しました。複数の国でレースを行うため、現地にIT運用センターを設営する必要がありますが、クラウドを利用することで現地に運び込む機材が少なくなるため、クラウドが提供する効率性に加えて実用性な面でも利点を得ることができます。 F1は、非常にデータドリブンな自動車レースです。各レースでは、各競技車両が実装する120個のセンサーが3 GBのデータを生成し、毎秒1,500データポイントが生成されます。 F1のデータ科学者は、過去65年間で蓄積されたレースデータを使って深度学習モデルをトレーニングします。例えば、適切なピットストップウインドウ(適正なピットのタイミング)の特定や、タイヤ交換のピットストップ作戦といった、レース中の予測を行うことが可能です。リアルタイムでデータ分析をして、ドライバーが限界点までパフォーマンスを出しているかどうかといった洞察を、視聴しているファンに提供します。Amazon Kinesisを使って、機械学習、分析に用いる動画をリアルタイムにAWSのワークフローに取り込み、旋回中の各競技車両の主要なパフォーマンスデータを高速処理し、 Amazon SageMaker を活用した機械学習の結果により、ドライバーのパフォーマンスを正確に把握することができます。 F1のイノベーションとデジタル技術のディレクター、ピート・サマラ氏(Pete Samara)は次のように述べています。「AWSは我々のニーズに対して、他のクラウド事業者に勝るスピード、スケーラビリティ、信頼性、グローバル展開、パートナーエコシステム、そして幅広いサービスを提供してくれます。Amazon SageMakerなどの機械学習サービスを活用することにより、強力な洞察と予測をリアルタイムでファンに提供することができます。 また、AWSのスケーラブルで高性能コンピューティングワークロードを、Formula 1 Motorsports部門が活用できていることも素晴らしいです。これにより、新車のデザインルールの開発時に、エアロダイナミクス(空力性能)チームが実行できるシミュレーションの数と品質が大幅に向上します。」 原文はFormula One Group Case Study https://aws.amazon.com/jp/solutions/case-studies/formula-one/ AWSでの機械学習について https://aws.amazon.com/jp/machine-learning/ AWS ビデオソリューションについて https://aws.amazon.com/jp/digital-media/aws-managed-video-services/   AWS Elemental Marketing 山下  

Read More

Amazon EMR のサイズ変更とオートスケーリングのベストプラクティス

Amazon EMR で利用可能な動的なスケーリング機能を利用することで、費用を節約することができます。 クラスタ内のノード数を即座に増やしたり減らしたりスケールする機能は、Amazon EMR を弾力的にする主要な機能の1つです。 EMR のスケーリング機能を使うことで,負荷がほとんどまたはまったくない時にクラスターのサイズを小さく変更することができます。 また、ジョブが非常に遅くなった場合に処理能力を追加するために、クラスターのサイズを大きくすることもできます。 これによりあなたのジョブを少し余裕を持たせた上でカバーするのに必要十分なコストを使うことが出来ます。 この機能の背後にある複雑なロジックを知ることで、クラスタのコストを節約することができます。この記事では、EMR クラスターのサイズをどのように変更するかを詳しく説明し、この機能を使用してあなたのクラスタのコストを削減し最大限のメリットを得るためのベストプラクティスを紹介します。 EMR スケーリングは、単にノードをクラスタに追加または削除するより複雑です。よくある誤解の1つは、Amazon EMR のスケーリングは Amazon EC2 のスケーリングとまったく同じように動くということです。 EC2 スケーリングを使用すると、ノードをほぼ即時に、かつ心配なく追加/削除できますが、EMR では複雑さが増します(特にクラスタを縮小する場合)。これは重要なデータがノード上にあったり,ジョブがノード上で実行していたりする可能性があるためです。 データロストを防ぐため、Amazon EMR スケーリングでは、実行中の Apache Hadoop タスクや、ノードを削除する前に失われる可能性のある一意のデータがノードに存在しないことが保証されます。 EMR クラスタのサイズ変更する際にはデコミッションの遅延を考慮する必要があります。このプロセスがどのように機能するかを理解することによって、遅いクラスタのサイズ変更や非効率なオートスケーリングのポリシーなど、他の人が悩まされていた問題を回避できます。 EMR クラスタが縮小されると、終了するノードで2つの異なるデコミッションプロセスがトリガされます。最初のプロセスは、Hadoop リソースマネージャである Hadoop YARN のデコミッションです。 Amazon EMR にサブミットされる Hadoop タスクは一般的に YARN を通じて実行されるため、EMR はノードを削除する前に実行中の YARN タスクが完了していることを保証する必要があります。何らかの理由で YARN タスクがスタックした場合、デコミッショニングを緩やかに終了することを確実にする設定可能なタイムアウトがあります。このタイムアウトが発生すると、YARN タスクは終了し、タスクが正常に完了できるように別のノードに再スケジュールされます。 2番目のデコミッションプロセスは、HDFS(Hadoop Distributed File System)のデコミッションプロセスです。 HDFSは、HDFSを実行している任意のノード上の EMR […]

Read More

Amazon QuickSightのプライベートVPC内のデータアクセスの設定方法について

はじめに 今回の記事では、先日一般公開された「Amazon QuickSightのプライベートVPC内のデータアクセス」の設定方法をご紹介します。この設定を行うことによって、Amazon QuckSight(以下、QuickSight)からプライベートサブネット内のAmazon RDS(以下、RDS)のデータベース、Amazon EC2内のデータベースへのアクセス、また AWS Direct Connect(以下、Direct Connect)を経由したオンプレミスのデータベースにアクセスして分析ダッシュボード、レポートを作成することが可能です。 なお本稿の情報は、2018年6月22日時点の以下のAWS公式ドキュメントをベースにしておりますが、最新の情報は設定前にご確認ください。 Amazon QuickSight: Amazon VPCを操作する 接続構成イメージ 以下で説明する手順を実行すると以下のようなイメージで構成されます。VPC内にあるプライベートサブネットの中にQuickSightアクセス用のセキュリティグループを定義することで、アタッチされるENI(Elastic Network Interface)経由でQuickSightが同一VPC内のデータベース(本例ではRDS)のあるプライベートサブネットに接続することが可能です。 図1. 構成イメージ(プライベートVPC内接続) また上記のように、QuickSightアクセス用のセキュリティグループを構成することで、オンプレミス環境にあるデータベースに対しても、Direct Connect経由でアクセス可能(オンプレミスデータベースへのルーティングが可能である前提)になります。 図2. 構成メージ(オンプレミスへの接続)   設定手順概要 1.QuickSight用のセキュリティグループ作成 AWSのマネージメントコンソールから「VPC → セキュリティグループ」を選択し、「セキュリティグループの作成」ボタンを押し、QuickSight用ENIのセキュリティグループを作成します。 図3. QuickSightアクセス用のセキュリティグループ作成   2.作成したQuickSightアクセス用のセキュリティグループのインバウンドルール設定 ここで前の手順で作成したQuickSightアクセス用のセキュリティグループの「インバウンドルール」を設定します。何故、インバウンドルールを設定するかというと以下のドキュメントの引用のように、QuickSight用のENI(ネットワークインターフェイス)にアタッチされているセキュリティグループの通信はステートフルではないため、本例のRDSからの戻りの通信に対する受信ルールを追加する必要があるのです。 引用:Amazon QuickSight: Amazon VPCを操作する 「ただし、Amazon QuickSight ネットワークインターフェイスにアタッチされているセキュリティグループはステートフルではありません。つまり、送信先ホストからの戻りトラフィックは自動的に許可されません。この場合、ネットワークインターフェイスセキュリティグループに Egress ルールを追加しても機能しません。したがって、明示的に承認するために、受信ルールをセキュリティグループに追加する必要があります。」 図4. QuickSightアクセス用のセキュリティグループ設定上のポイント よって、以下の様にQuickSight用のセキュリティグループのインバウンドルールを以下の様に設定します。 図5. QuickSightアクセス用のセキュリティグループのインバウンドルールの設定例   3.RDSのセキュリティグループの設定 次にRDSのセキュリティグループにQuickSightのセキュリティグループ経由のアクセスを許可する設定を行います。 AWSのマネージメントコンソールから「RDS → インスタンス」を選択し、該当のインスタンス名のリンクをクリックして、インスタンス詳細画面を表示します。 […]

Read More

[AWS Black Belt Online Seminar] データレイク入門: AWSで様々な規模のデータレイクを分析する効率的な方法 資料及び QA 公開

こんにちは、マーケティングの鬼形です。 先日 (2018/6/19) 開催しました AWS Black Belt Online Seminar「データレイク入門: AWSで様々な規模のデータレイクを分析する効率的な方法」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20180619 AWS Black Belt Online Seminar データレイク入門: AWSで様々な規模のデータレイクを分析する効率的な方法 from Amazon Web Services Japan PDF Q. RDSからGlueでData Catalogを作成する際、負荷などかかるのでしょうか?分析用にユーザ操作から切り離したほうが良いのか?気にしなくて良いのかを知りたいです。 A. RDS をクロールする際、スキーマ取得のため Connection を使用します。瞬間的な処理にはなりますが、Connection が使用される点に留意いただき、検証の実施と実行タイミングの検討をお願いいたします。 Q. ベストプラクティス 2/5, 3/5 で説明されていた Parquetを使用した場合のメトリクスはRedshift Spectrum ではなく、Athenaを使用している場合に同様の情報を知ることは可能でしょうか。 A. Athena では同様の情報を確認いただくことができません。 以上です。 今後の AWS Black Belt Online Seminar のスケジュール 直近で以下のオンラインセミナーを予定しています。各オンラインセミナーの詳細およびお申し込み先は下記URLからご確認いただけます。皆様のご参加をお待ちしております! […]

Read More

AWS Step FunctionsとAWS Lambdaを使って複数のETLジョブの統合を行う

抽出、変換、ロード(Extract, Transform, Load, ETL)操作は、現在のエンタープライズデータレイクのバックボーンにひとまとまりとして形成されています。rawデータを役に立つデータセットへ変換し、最終的には、洞察可能な状態に変換します。ETLジョブは通常1つまたは1つ以上のデータソースからデートを読み、様々な種類の変換を適用し、結果を利用準備できているターゲットに書き込みます。ETLジョブのソースとターゲットはリレーショナルデータベースであるAmazon RDS(Amazon Relational Database) もしくはオンプレミス、データウェアハウスとしてAmazon Redshift 、オブジェクトストレージとしてAmazon Simple Storage Service(Amazon S3) のバケットなどがあります。Amazon S3は、AWSでデータレイクを構築するという状況において特に一般的です。 AWSは、ETLジョブの作成とデプロイを支援するAWS Glueを提供しています。AWS Glueは抽出・変換・ロードを行うフルマネージドなサービスであり、お客様が簡単に自分のデータとして準備、ロードできるものとなります。他のAWSサービスでもETLジョブを実装、デプロイすることも可能です。 AWS Database Migration Service(AWS DMS)、Amazon EMR(ステップAPIの利用)、さらにAmazon Athenaも含まれます。   ETLジョブワークフロー統合へのチャレンジ 多様なETLテクノロジーを含むETLワークフローをどのように統合できるでしょうか? AWS Glue、AWS DMS、Amazon EMRなどのサービスは、Amazon CloudWatch Eventsをサポートしており、ETLジョブを連動させることができます。 Amazon S3は、中心に置かれたデータレークストアでもあり、CloudWatch Eventsをサポートしています。しかし、CloudWatchイベントのみに依存するということは、ETLワークフローの視覚的表現が1つもないことを意味します。また、全体的なETLワークフローの実行ステータスを追跡し、エラー・シナリオを処理することは困難になります。 本ブログでは、AWS Step FunctionsとAWS Lambdaを使用して、任意の複雑なETLワークフローでさまざまなテクノロジを含む複数のETLジョブを編成する方法を説明します。

Read More