Amazon Web Services ブログ

Category: AWS Big Data

Amazon AppFlow と Amazon Athena を使用して Google Analytics データを分析する

Software as a Service (SaaS) アプリケーションの重要性は急速に高まってきています。このデータは、ビジネスの意思決定に影響を与える分析を実行するときに含めることが不可欠です。Amazon AppFlow は、SaaS データをデータレイクに安全に転送するのを助けるフルマネージド統合サービスです。データ転送フローは、オンデマンドで、スケジュールに従い、またはイベント発生後に実行できます。Amazon Athena を使用してこのデータをすばやく分析し、Amazon Simple Storage Service (Amazon S3) に既に保存されている多数のデータセットと結合できます。複数の SaaS データセットを結合し、さらに Athena 横串検索機能を使って、Amazon Relational Database Service (Amazon RDS) などの従来のデータベースにある運用データと結合できます。 この記事では、Amazon AppFlow を使用して Google Analytics データを抽出し、それを Amazon S3 に保存して、Athena でクエリできるようにする方法を説明します。 アーキテクチャの概要 次の図は、この記事で説明するフローを示しています。最初に Amazon AppFlow 内に新しいフローを作成して、Google Analytics データを Amazon S3 に転送します。転送するデータの形式は、Athena がサポートしていない複数行の JSON です。AWS Lambda 関数は、この JSON 形式のファイルを Apache […]

Read More

Amazon ES を使った Compass での住宅検索のシンプル化と最新化

 Amazon Elasticsearch Service (Amazon ES) は、AWS での Elasticsearch の大規模なデプロイメント、セキュア化、および運用を容易にする完全マネージド型サービスです。幅広い人気があるこのサービスは、さまざまなお客様が異なる検索ユースケースのためにアプリケーションに統合しておられます。 Compass は、その顧客に質の高い不動産物件検索と保存済み検索機能を提供するために、Amazon ES を含めた AWS のサービスを使ってその検索ソリューションを再設計しました。 この記事では、Compass の検索ソリューションがどのように進化したか、異なるアーキテクチャでどのような課題とメリットを見出したか、そして Amazon ES がどのように長期的かつスケーラブルなソリューションを提供しているかを見て行きます。また、Amazon Managed Streaming for Apache Kafka (Amazon MSK) が物件リスティングデータのイベント駆動型リアルタイムストリーミング機能の作成にどのように役立ったかについても説明します。このソリューションは、同様のユースケースに適用できます。 Amazon ES の概要 ログ分析、アプリケーションモニタリング、インタラクティブな検索、およびその他多くの機能のデプロイメント、運用、およびスケーリングを容易にする Amazon ES は、Elasticsearch の使い勝手のよい API とリアルタイム機能と共に、現実世界のアプリケーションが必要とする可用性、スケーラビリティ、およびセキュリティを提供する完全マネージド型サービスです。Amazon Kinesis、AWS Lambda、Amazon CloudWatch などの AWS のその他サービス、および Logstash や Kibana といったサードパーティーツールとのビルトイン統合も提供しているので、raw データを実用的なインサイトに素早く変化させることができます。 Amazon ES には以下のメリットもあります。 完全マネージド型 – […]

Read More

Amazon EMR Managed Scaling のご紹介 – クラスターを自動的にサイズ変更してコストを削減する

AWS は、Amazon EMR マネージドスケーリングをリリースすることを発表します。これは、可能な限り低いコストで最高のパフォーマンスを得るためにクラスターのサイズを自動的に変更する新機能です。EMR マネージドスケーリングにより、クラスターの最小および最大のコンピューティング制限を指定し、Amazon EMR はそれらを自動的にサイズ変更して、最高のパフォーマンスとリソース使用率を実現します。EMR マネージドスケーリングは、クラスターで実行されているワークロードに関連する主要なメトリクスを継続的にサンプリングしています。EMR マネージドスケーリングは、Amazon EMR バージョン 5.30.1 以降の Apache Spark、Apache Hive、YARN ベースのワークロードでサポートされています。* ユースケースとメリット EMR マネージドスケーリングがリリースされる前は、ワークロードパターンを事前に予測するか、アプリケーションフレームワーク (Apache Spark や Apache Hive など) の深い理解に依存するカスタム Auto Scaling ルールを作成する必要がありました。ワークロードを予測したり、カスタムルールを作成したりするのは難しく、エラーが発生しやすくなります。クラスターリソースの不適切なサイジングは、多くの場合、SLA の未達成または予測できないパフォーマンス、またはリソースの不十分な活用とコスト超過の原因となる可能性があります。 EMR マネージドスケーリングは、ワークロードに基づいてクラスターリソースのサイズを自動的に決定することでこの問題を解決し、最高のパフォーマンスと最小のコストを実現します。クラスターをスケーリングするために、ワークロードパターンを予測したり、カスタムロジックを記述したりする必要はありません。EMR マネージドスケーリングは、ワークロードに基づいて主要なメトリクスを常にモニタリングし、クラスターのサイズを最適化して、リソースの使用率を最適化します。Amazon EMR は、ピーク時にクラスターをスケールアップし、アイドル期間中に適切にクラスターをスケールダウンして、コストを削減し、クラスターの容量を最適化して最高のパフォーマンスを実現できます。数回クリックするだけで、クラスターのコンピューティング制限を設定でき、残りは Amazon EMR が管理します。EMR マネージドスケーリングを使用すると、Amazon EMR は 1 分の粒度で高解像度のメトリクスも生成します。これにより、Amazon EMR マネージドスケーリングが受信ワークロードにどのように反応するかを視覚化できます。詳細については、「マネージドスケーリングのメトリクスを理解する」を参照してください。 例を挙げて説明するため、EMR マネージドスケーリングを使用して EMR クラスターを設定し、1 ~ 20 の間のノードにスケーリングしました (ノードあたり 16 […]

Read More

Application Load Balancer を使用して、プライベートサブネット内で起動された Amazon EMR 上のインターフェイスにセキュアにアクセスする

Amazon EMR ウェブインターフェイスは、EMR クラスターのマスターノードにホストされています。EMR クラスターをプライベートサブネット内で起動した場合、EMR マスターノードはパブリック DNS レコードを保持しません。プライベートサブネット内にホストされたウェブインターフェースは、サブネット外には簡単にアクセスできません。Application Load Balancer (ALB) を HTTPS プロキシとして使用すると、Bastion ホストを介した SSH トンネリングを行うことなく、インターネット上の EMR ウェブインターフェイスにアクセスすることが可能です。このアプローチにより、 EMR ウェブインターフェイスへのアクセスが大いに簡素化されます。 この投稿では、EMR クラスターをプライベートサブネット内で起動した場合に、ALB を使用してどのようにインターネット上の EMR ウェブインターフェースへセキュアなアクセスをするのかを概説します。 ソリューションの概要 VPC サブネット内に起動されたノードは、以下のいずれかが存在しない限り、そのサブネットから外部への通信はできません。 VPC 内で、そのサブネットから他のサブネットへのネットワークルート VPC Peering による VPC サブネットへのルート AWS Direct Connect を介したサブネットへのルート インターネットゲートウェイへのルート VPN 接続からサブネットへのルート 最高レベルのセキュリティを EMR クラスターに求める場合は、クラスターへの最小数のルートを持つサブネットにクラスターを配置する必要があります。これにより、プライベートサブネット内で起動された EMR クラスターのマスターノード上で動作しているウェブインターフェースへのアクセスがさらに難しくなります。 このソリューションでは、 EMR マスターノード上のウェブインターフェースエンドポイントへの HTTPS プロキシとして機能するインターネット向けの ALB を使用しています。ALBは、HTTPSポートで着信ウェブインターフェイスアクセスリクエストをリッスンし、EMR […]

Read More

ADFS と AWS の間の信頼を確立し、Active Directory 認証情報を使用して ODBC ドライバーで Amazon Athena に接続する

 Amazon Athena はサーバーレスでインタラクティブなクエリサービスです。これにより、標準的な SQL を使用して、Amazon Simple Storage Service (Amazon S3) で未加工および処理済みのデータセットを簡単に分析できます。Athena が提供する JDBC および ODBC ドライバーを使用すると、データ分析ツール (Microsoft Power BI、Tableau、SQLWorkBench など) を Athena とシームレスに統合し、数分でデータに関する洞察を得ることができます。 2018 年 11 月までは、IAM ユーザーまたはロールの認証情報を使用して、ODBC または JDBC ドライバーで Athena に接続する必要がありました。けれども、Athena ODBC/JDBC ドライバーで、Microsoft Active Directory Federation Services (ADFS 3.0) と Security Assertion Markup Language (SAML 2.0) のサポートが 2018 年 11 月 20 […]

Read More

Drop が Apache Spark の Amazon EMR ランタイムを使用してコストを半分にし、結果取得までの速度を 5.4 倍にした方法

 これは、Drop のソフトウェアエンジニアである Michael Chau 氏と AWS ビッグデータスペシャリストソリューションアーキテクトの Leonardo Gomez 氏によるゲスト投稿です。彼らは、次のように述べています。「Drop には、一度に 1 回の報酬で、消費者の生活を向上させるという使命があります。パーソナライズされたコマースプラットフォームを通じて、適切なブランドを適切なタイミングでインテリジェントに表示し、会員の暮らしを以前よりも素晴らしいものにしています。機械学習を利用し、200 を超えるパートナーブランドと消費者をマッチングさせることで、2 つの主要な目標を実現しています。すなわち、購入からポイントを獲得し、そのポイントをすぐに特典と引き換えることができるようにすることです。トロントを本拠地としながら、グローバルな考え方をもって活動する Drop は、北米全体で 300 万人を超える会員のために、次世代のエクスペリエンスを構築しています。詳細については、www.joindrop.com をご覧ください」 概要 Drop では、データレイクインフラストラクチャが、製品とビジネスに関して、データに基づく意思決定を改善する上で不可欠な役割を果たしています。重要な機能は、膨大な量の生データを処理し、当社のデータレイクの標準化されたファイル形式とパーティション構造に準拠した調整済みデータセットを生成する機能です。当社のビジネスインテリジェンス、実験分析、機械学習 (ML) システムは、これらの変換されたデータセットを直接使用します。 この投稿では、Amazon EMR を使用するためにデータレイクのバッチ ETL パイプラインを設計および実装した方法と、Apache Spark ランタイムを数時間から数分に削減し、運用コストを 50% を超えて節約するためにアーキテクチャにおいて繰り返し実行したさまざまな方法について詳しく説明します。 パイプラインの構築 Drop のデータレイクは、ダウンストリームのビジネスインテリジェンス、実験分析、および ML システムが不可欠に依拠している会社のデータインフラストラクチャ全体における中心的かつ信頼できる情報源として機能します。当社のデータレイクの目標は、さまざまな情報源から膨大な量の生データを取り込み、ダウンストリームシステムが Amazon Simple Storage Service (Amazon S3) を介してアクセスできる信頼性の高い、調整されたデータセットを生成することです。これを実現するために、Lambda アーキテクチャ処理モデルに準拠するようにデータレイクのバッチ ETL パイプラインを構築し、Apache Spark と Amazon EMR の組み合わせを使用して、Amazon […]

Read More

Amazon EMR で Spark ストリーミングアプリケーションをモニタリングする

 アプリケーションをエンタープライズ対応にするには、本番環境に移行する前にアプリケーションの多くの側面を考慮し、アプリケーションの運用を可視化する必要があります。その可視性は、アプリケーションの正常性とパフォーマンスを測定し、アプリケーションダッシュボードとアラームをフィードするメトリクスを通じて得ることができます。 ストリーミングアプリケーションでは、さまざまなステージと各ステージ中のタスクをベンチマークする必要があります。Spark は、プローブをプラグインするためのインターフェイスを提供し、アプリケーションをリアルタイムでモニタリングおよび観察できるようにしています。SparkListeners は、スチーミングアプリケーションとバッチアプリケーションの両方に対応する柔軟で強力なツールです。これを Amazon CloudWatch メトリクス、ダッシュボード、およびアラームと組み合わせて、可視性を高め、問題が発生したときに通知を生成したり、クラスターやサービスを自動的にスケーリングしたりできます。 この記事では、シンプルな SparkListener を実装し、Spark ストリーミングアプリケーションをモニタリングおよび観察し、アラートを設定する方法を説明します。また、CloudWatch カスタムメトリクスに基づいて、アラートを使って Amazon EMR クラスターで Auto Scaling を設定する方法も示します。 Spark ストリーミングアプリケーションのモニタリング 本番環境のユースケースでは、Spark アプリケーションに必要なリソースの量を決定するために事前に計画する必要があります。多くの場合、リアルタイムアプリケーションには、各バッチの実行を安全に実行できる時間や各マイクロバッチの許容遅延時間など、満たす必要のある SLA があります。多くの場合、アプリケーションのライフサイクルの中で、入力ストリームのデータが突然増加することにより、流入するデータを処理して追いつくために、より多くのアプリケーションリソースが必要になります。 このようなユースケースでは、各マイクロバッチのレコード数、スケジュールされたマイクロバッチの実行の遅延、各バッチの実行にかかる時間などの一般的なメトリクスに興味を持たれるかもしれません。たとえば、Amazon Kinesis Data Streams では、IteratorAge メトリクスをモニタリングできます。Apache Kafka をストリーミングソースとして使用すると、最新のオフセットとコンシューマーオフセットの間のデルタなど、コンシューマーラグをモニタリングできます。Kafka には、この目的のためのさまざまなオープンソースツールがあります。 より多くのリソースをプロビジョニングするか、未使用のリソースを減らしてコストを最適化することにより、リアルタイムで対応したり、環境の変化に基づいてアラートを生成したりできます。 Spark ストリーミングアプリケーションをモニタリングするさまざまな方法が既にご利用いただけます。Spark の非常に効率的ですぐに使える機能は、Spark メトリクスシステムです。さらに、Spark は HTTP、JMX、CSV ファイルなど、さまざまなシンクにメトリクスを報告できます。 ログを出力することにより、アプリケーション内からアプリケーションメトリクスをモニタリングおよび記録することもできます。これには、count().print() の実行、マップ内のメトリクスの印刷、遅延の原因となる可能性のあるデータの読み取り、アプリケーションステージへの追加、または不要なシャッフルの実行が必要です。これは、テストには役立つ可能性はありますが、長期的なソリューションとしては高価であることがしばしば証明されています。 この記事では、別の方法について説明します。それは、SparkStreaming インターフェイスを使用する方法です。次のスクリーンショットは、Spark UI の [Streaming] タブで利用できるメトリクスを示しています。 Apache Spark リスナー Spark は内部的に、イベントベースの方法で行う内部コンポーネント間の通信を […]

Read More

気象庁の衛星”ひまわり”の収集データが、AWSと米国政府機関とのコラボにて公開されました

ひまわり 8 号からの画像。写真提供: アメリカ海洋大気庁。(他の画像も多数) 米政府機関とAWSの連携により、気象衛星「ひまわり」が収集したデータの公開に至りましたので、AWSジャパン・パブリックセクターよりお知らせします。 「アメリカ海洋大気庁 (NOAA)」 に属する「アメリカ環境衛星データ情報局 (NESDIS)」 は、宇宙衛星・船舶・基地局などの情報源から生成される地球観測データへのアクセスをセキュアかつタイムリーに提供し、国民の安全・環境・経済・生活の質を向上させることを使命としています。アメリカ環境衛星データ情報局は現在、「ひまわり 8 号」によって収集された主要な気象データセットを、 AWS を通じてPublic Datasetとして公開しており、同情報局は「ひまわり8号」から直接受信を行う米国内で唯一の機関となっています。ひまわり8号は、日本の気象庁(Japan Meteorological Agency) が開発した静止地球環境観測衛星です。この観測衛星は、日本及び東アジア・西太平洋域内の各国における天気予報、台風・集中豪雨、気候変動などの監視・予測、船舶や航空機の運航の安全確保、地球環境の監視を目的として2014年に打ち上げられました。 以下、アメリカ海洋大気庁とAWSがどのように連携し、重要な気象データへのアクセスを向上させているのか、その方法について紹介します。 重要な気象データへのアクセスを可能に AWS は2019年 12 月、アメリカ海洋大気庁とのコラボレーションの拡大を発表しました。アメリカ海洋大気庁 は日々、膨大な量のデータを生成しています。これらの大量のデータは “商用クラウド” 、つまりAWSの利用を宣言している同庁の「ビッグデータプログラム (BDP)」 を通じ、容易に分析・研究することができます。従来、こうした研究を行うためには、ユーザーは、自分の分析環境のために莫大なデータ量の ”コピー” を ”ダウンロード” して ”保存” する必要がありました。AWSを用いれば、これらの各工程は、全て過去の遺物となります。ユーザーはAWS を通じ、世界最高峰のデータ収集体制を持つ同庁の最新のデータセット、それも常に更新され続けるデータ群にアクセスできるようになるのです。 研究者や起業家は、クラウド上にオンデマンドベースでコンピューティングリソースを展開し、迅速かつ効率的に分析を、それもかつてないほどの低コストで実行することができます。 これまで多大な手間を要していたコピーもダウンロードも保存も必要なく、そしてそれらに要してきた時間もコストも人員も、圧倒的な効率化が可能です ──── つまりは、真にミッションクリティカルな研究課題や新ビジネスの創造にのみ、集中することができるのです。 このAWSとアメリカ海洋大気庁のコラボレーションを通じて現在利用できる最も重要なデータセットの 1 つが、気象庁 が運用するひまわり 8 号のもたらす衛星データセットです。このデータセットは、オープンデータの公開ライブラリーであるAWS の Registry of Open Data を通じて誰でもアクセスできます。(なお、公的機関向けにストレージ費用をAWSが負担する「AWS Public Dataset Program」の取り組みについては、日本の農水省との取り組みを紹介したこちらのブログもご参照ください。) AWSクラウドで、衛星データ情報局はミッションを達成 将来に渡る大規模なクラウド導入計画の一部として、アメリカ環境衛星データ情報局は、同機関の「共通クラウドフレームワーク (Common Cloud […]

Read More

Amazon Kinesis Data Firehose により、VPC のプライバシー内で Amazon Elasticsearch Service にストリーミングデータを取り込む

 今日、新しい Amazon Kinesis Data Firehose 機能を追加します。これにより、Kinesis Data Firehose から Amazon Elasticsearch Service ドメインへの VPC 配信をセットアップできます。Amazon Kinesis Data Streams でカスタムアプリケーションを管理してトラフィックを非公開にしている場合は、Kinesis Data Firehose を使用して、VPC 内の Amazon Elasticsearch Service エンドポイントにデータをロードすることができます。それを行うのに、取り込みと配信のインフラストラクチャに投資、運用、拡張する必要はありません。Kinesis Data Firehose コンソール、AWS CLI、および API からこの新機能の使用を開始するには、宛先として Amazon Elasticsearch Service、VPC がアクセスできる特定のドメインを選択し、サブネットとオプションのセキュリティグループで VPC を設定します。 この機能のご利用前に Amazon Elasticsearch Service ドメインは、パブリックまたはプライベートエンドポイントを持つことができます。パブリックエンドポイントは、パブリックインターネット上の IP アドレスでバックアップされています。プライベートエンドポイントは、VPC の IP スペース内の IP アドレスでバックアップされています。 Amazon Elasticsearch Service […]

Read More

AWS Systems Manager を使用して RStudio で Amazon EMR エッジノードをデプロイする

 RStudio は、統計計算とグラフィックスのための言語と環境である R の統合開発環境 (IDE) です。データサイエンティストとして、R と Spark (ビッグデータ処理フレームワーク) を統合して、大規模なデータセットを分析できます。sparklyr と呼ばれる R パッケージを使用して、大規模なデータセットのフィルタリングと集計を R スクリプトから Spark にオフロードし、R のネイティブの強度を使用して、Spark からの結果をさらに分析および視覚化できます。 RStudio で実行されている R スクリプトは、sparklyr を使用して Spark ジョブをクラスターに送信します。通常、R スクリプトは (sparklyr とともに)、Spark を実行する (Amazon EMR の) マシンのクラスターとは別のマシンにインストールされている RStudio 環境で実行されます。sparklyr が Spark ジョブを送信できるようにするには、RStudio マシンと Spark を実行しているクラスターの間にネットワーク接続を確立する必要があります。そのための 1 つの方法は、RStudio をエッジノードで実行することです。これは、クラスターのプライベートネットワークの一部であり、RStudio などのクライアントアプリケーションを実行するマシンです。エッジノードを使用すると、Hadoop のコアサービスを実行するノードとは別にクライアントアプリケーションを実行できます。エッジノードは、ローカルの Spark および Hive シェルへの便利なアクセスも提供します。 ただし、エッジノードのデプロイは簡単ではありません。それらのエッジノードには、Hadoop クラスターと同じバージョンの Hadoop、Spark、Java、およびその他のツールが必要であり、クラスター内のノードと同じ […]

Read More