Category: Analytics

先日 (2018/8/1) 開催しました AWS Black Belt Online Seminar「Amazon QuickSight アップデート：一般公開後に追加された特徴的な新機能」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20180801 AWS Black Belt Online Seminar Amazon QuickSight アップデート PDF Q. DynamoDBやESなどで溜め込んでいる注文情報などをS3などに定期的に吐き出していく（吐き出すたびに別ファイル）場合でも、今回の紹介された形で定期的にリフレッシュするなどして読み込めますか？それともRDSなどに一度入れないと行けないでしょうか？ A. QuickSight用のマニフェストファイルを作成し、 “URIPrefixes”で、バケットやプリフィックスを指定しておくと、その中にある複数のファイルをまとめて１つのデータセットとして扱うことが可能です。バケットにファイルを追加した後に、そのデータセットを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 のセッションからなり、初心者も上級者も AWS クラウドを活用してビジネスを構築し変革するのに必要な知識が包括的に学べるよう設計されています。8/28、9/4、9/11 に用意されたライブ開催では、AWS エキスパートによるQAも用意されています。 […]

本日、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 […]

こんにちは。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 forDigital Advertising 次に、アナリティクス スペシャリスト ソリューションアーキテクトの志村より「AWS ML Services Update」というタイトルでプレゼンテーションを行いました。 AWS ML Update ここから、お客様セッションに移りました。 まずは、SIGNATE inc. 代表取締役社長 CEO/CDO 齊藤 秀 様より「国内外AIコンペティションからみるAI技術者のキャリアパスの潮流およびAIコンペサイトSIGNATEにおけるAWS活用事例」というタイトルでプレゼンテーションを行って頂きました。 […]

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

お客様によると、データウェアハウスやビジネスインテリジェンスのユーザは、常に迅速な意思決定ができるように、非常に高速な応答時間を求めているということです。またユーザは、データが変わっていなくても、同じクエリを何度も繰り返すことがよくある、とも言います。クエリを繰り返すたびにコンピューティングリソースを消費するので、クエリ全体のパフォーマンスが低下します。 今回の記事では、Amazon Redshift のクエリ結果のキャッシュについて説明します。結果のキャッシュは、まさにその名前が示すことを実行します。つまり、クエリ結果をキャッシュに格納するのです。同じデータに対して同じクエリが行われると、同じクエリを再実行するのではなく、前の検索結果をキャッシュから読み取って即座に返します。結果のキャッシュによって、システムの使用が削減され、他のワークロードでより多くのリソースを利用できるようになります。これにより、ユーザーの応答時間が高速になり、クエリ全体のスループットが向上し、並行処理が増加します。

  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 山下  

Elasticsearch および Amazon Elasticsearch Service (Amazon ES) に関するこの導入シリーズへようこそ。今回および今後のブログ記事では、AWS で Elasticsearch の使用を開始するために必要な基本情報を紹介します。 概要 Amazon Elasticsearch Service ドメインを初めて起動するときには、インスタンスタイプとインスタンス数の設定、専用マスターを使用するかどうかの決定、ゾーン認識の有効化、およびストレージの設定が必要です。このシリーズでは、インスタンス数の決定のためにストレージをガイドラインとして使用することについて説明してきましたが、他のパラメータについては説明したことがありませんでした。本記事では、ログ分析ワークロードの T シャツサイズに基づいて推奨事項を提供します。 ログ分析およびストリーミングのワークロードの特性 ストリーミングワークロードに Amazon ES を使用する場合、1 つ以上のソースから Amazon ES にデータを送信します。Amazon ES は定義した 1 つまたは複数のインデックスにお客様のデータ (より正確には、お客様のデータのインデックス) を保存します。さらに、データのタイムスライスと保持期間を定義して、ドメインでのライフサイクルを管理します。 次の図では、データのストリームを生成するデータソースが 1 つあります。 そのデータのストリームを Amazon ES に送信する際に、Stream1_2018.05.21、Stream1_2018.05.22 などの名前の 1 日ごとのインデックスを作成します。Stream1_ をインデックスパターンと呼びます。この図では、これらの各インデックスに対して 3 つのプライマリシャードを表示しています。シャードは、各プライマリシャードに 1 つあるレプリカと共に、3 つの Amazon ES データインスタンスにデプロイされます。(分かりやすいように、図には示していませんが、プライマリとレプリカが別のインスタンスにあるようにシャードがデプロイされます。) Amazon Elasticsearch Service […]

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 […]

多くの企業は、クラウド セキュリティのポリシーを厳格に規制しています。機密データが処理される Amazon EMR の場合、これらのポリシーはより厳しくなる可能性があります。 EMR で提供されているセキュリティ構成を使用すると、Amazon S3 およびローカルの Amazon EBS ボリュームに保存されているデータの暗号化を設定できます。また、転送中のデータの暗号化用に Transport Layer Security (TLS) 証明書を設定することもできます。 転送時の暗号化を有効にした場合、EMR は次のコンポーネントをデフォルトでサポートします。 Hadoop MapReduce 暗号化シャッフル。 「プライバシー」に設定されている セキュア Hadoop RPC および SASL の使用。これは、保管時のデータの暗号化を有効にしたときに、EMR 内でアクティブになります。 「プライバシー」に設定されている セキュア Hadoop RPC および SASL の使用。これは、セキュリティ構成内で保存済みのデータの暗号化が有効な場合に、EMR 内でアクティブになります。 SSL/TLS を使用した、Presto のノード間の内部通信。これは、EMR バージョン 5.6.0 以降にのみ当てはまります。 TLS を使用する Tez Shuffle Handler。 Apache Spark 間の内部 RPC 通信 Spark […]

はじめに 今回の記事では、先日一般公開された「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. 構成メージ（オンプレミスへの接続）   設定手順概要 １．QuickSight用のセキュリティグループ作成 AWSのマネージメントコンソールから「VPC → セキュリティグループ」を選択し、「セキュリティグループの作成」ボタンを押し、QuickSight用ENIのセキュリティグループを作成します。 図3. QuickSightアクセス用のセキュリティグループ作成   ２．作成したQuickSightアクセス用のセキュリティグループのインバウンドルール設定 ここで前の手順で作成したQuickSightアクセス用のセキュリティグループの「インバウンドルール」を設定します。何故、インバウンドルールを設定するかというと以下のドキュメントの引用のように、QuickSight用のENI（ネットワークインターフェイス）にアタッチされているセキュリティグループの通信はステートフルではないため、本例のRDSからの戻りの通信に対する受信ルールを追加する必要があるのです。 引用：Amazon QuickSight: Amazon VPCを操作する 「ただし、Amazon QuickSight ネットワークインターフェイスにアタッチされているセキュリティグループはステートフルではありません。つまり、送信先ホストからの戻りトラフィックは自動的に許可されません。この場合、ネットワークインターフェイスセキュリティグループに Egress ルールを追加しても機能しません。したがって、明示的に承認するために、受信ルールをセキュリティグループに追加する必要があります。」 図4. QuickSightアクセス用のセキュリティグループ設定上のポイント よって、以下の様にQuickSight用のセキュリティグループのインバウンドルールを以下の様に設定します。 図5. QuickSightアクセス用のセキュリティグループのインバウンドルールの設定例   ３．RDSのセキュリティグループの設定 次にRDSのセキュリティグループにQuickSightのセキュリティグループ経由のアクセスを許可する設定を行います。 AWSのマネージメントコンソールから「RDS → インスタンス」を選択し、該当のインスタンス名のリンクをクリックして、インスタンス詳細画面を表示します。 […]