Amazon Web Services ブログ

Category: Amazon EMR

Media Seminar Q1 Analytics

2021Q1メディア企業向けAnalytics & AI/MLセミナー : 大阪リージョン/分析基盤

2021年3月18日にメディア業界のお客様向けにAnalytics & AI/MLをテーマとしたセミナーを開催いたしました。テレビ・動画配信・新聞・雑誌などのメディア企業では、デジタル変革の中でデータを活用する重要性が高まっています。本セミナーではメディア企業はいかにデータを活用し、新たなビジネスを展開していくかに焦点をあて、DMP (データマネジメントプラットフォーム) / CDP (カスタマーデータプラットフォーム)のメリットと活用事例についてご紹介させていただきました。

Read More

【開催報告】AWS re:Invent Recap Analytics 〜新サービスアップデート&クイックデモ〜

こんにちは。アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクトの平間です。 2021年1月29日に、2020年 AWS re:Invent Recapシリーズのひとつとして、分析サービスのRecapセミナーを開催いたしました。2020年 AWS re:Invent では、AWSの分析サービスに関して、新しいサービスおよび多くのアップデートが発表されました。本セッションでは、新しく発表されたサービスやアップデートを中心に共有させていただくとともに、お客さまの課題や問題をどのように解決できるのか、クイックデモを交えてご紹介させていただきました。

Read More

新発表 — Amazon EMR on Amazon Elastic Kubernetes Service (EKS)

数万社のお客様が、Amazon EMR を使用して、Apache Spark、 Hive、HBase、Flink、Hudi、および Presto などのフレームワークでビッグデータ分析アプリケーションを大規模に実行しています。EMR は、これらのフレームワークのプロビジョニングとスケーリングを自動化し、さまざまな EC2 インスタンスタイプでパフォーマンスを最適化して、価格とパフォーマンスの要件を満たします。お客様は現在、Kubernetes を使用して組織全体でコンピューティングプールを統合しています。Amazon Elastic Kubernetes Service (EKS) で Apache Spark を管理しているお客様の一部には、EMR を使用して、フレームワークのインストールと管理、AWS のサービスとの統合などの手間のかかる作業を排除したいと考えているお客様もいらっしゃいます。さらに、EMR が提供するより高速なランタイムや開発およびデバッグのツールも活用したいと考えています。 本日、Amazon EMR on Amazon EKS の一般提供を発表いたします。これは、EMR の新しいデプロイオプションであり、EKS でのオープンソースのビッグデータフレームワークのプロビジョニングと管理を自動化できます。EKS で EMR を使用すると、同じ EKS クラスターで Spark アプリケーションを他のタイプのアプリケーションとともに実行し、リソース使用率を向上させ、インフラストラクチャ管理を簡素化することができます。 他のタイプのアプリケーションと同じ EKS クラスタに EMR アプリケーションをデプロイできるため、リソースを共有し、すべてのアプリケーションを運用および管理する単一のソリューションで標準化できます。最新のフレームワークへのアクセス、パフォーマンスが最適化されたランタイム、アプリケーション開発用の EMR Notebooks、デバッグ用の Spark ユーザーインターフェイスなど、現在 EC2 で使用しているのと同じ EMR 機能をすべて EKS で利用できます。 Amazon EMR は、アプリケーションをビッグデータフレームワークを使用してコンテナに自動的にパッケージ化し、他の […]

Read More

【開催報告】「秋のスポットインスタンス祭り」セミナー

EC2スポットインスタンススペシャリスト ソリューションアーキテクトの滝口です。2020年11月11日にオンラインで開催された「秋のスポットインスタンス祭り」セミナーでは、100名を超える聴衆の方々にご参加いただき、AWSのソリューションアーキテクトによる技術解説に加え、スポットインスタンスを効果的に活用されている2社のお客様の具体的な事例をご紹介いただきました。 本記事では、お客様のご登壇資料を含む当日資料をご紹介し、また参加者の皆様からいただいた当日のQ&Aの一部をご紹介します。 当日アジェンダと資料 13:00 ~ 13:45 自動スケールから始める EC2 スポットインスタンス 講師:滝口 開資(アマゾン ウェブ サービス ジャパン株式会社 ソリューション アーキテクト) 概要:みなさまのシステム、自動スケール機能はお使いでしょうか。クラウドに移行したものの、EC2インスタンスはずっと立ち上げっぱなし。負荷の高いタイミングでも台数固定。そしてEC2の費用は慢性的に高止まり。こんな課題を抱えていらっしゃるみなさまに向けて、まず前半ではスケールする大規模処理での例としてWebサービス、機械学習、データ分析のワークロードを取り上げ、活用できる技術スタックの選定方針を紹介しました。 そして後半では、EC2インスタンスの自動スケールの仕組み、そしてそこにスポットインスタンスを組み合わせてコスト最適化を狙う方法をわかりやすくお伝えしました。 自動スケールから始める EC2 スポットインスタンス 13:45 ~ 14:15 実例から学ぶAWS Batch x スポットインスタンスによる大規模バッチ処理 講師:宮本 大輔(アマゾン ウェブ サービス ジャパン株式会社 ソリューション アーキテクト) 概要:クラウドでは必要な時に必要な量の計算リソースを起動して処理を行うことができるため、HPC (High Performance Computing) やゲノム解析、大量の動画像の処理といった用途に適しています。そしてこのような大規模バッチ処理をコスト効率よく行うためにはスポットインスタンスの活用が重要なポイントとなります。本セッションでは、大規模バッチ処理に対してスポットインスタンスを適用する際に考慮しなければいけないことや、注意すべきポイントについて、AWS Batchを活用した実例を交えてご紹介いたしました。 実例から学ぶAWS Batch x スポットインスタンスによる大規模バッチ処理 14:15 ~ 14:45 スポットインスタンス/インスタンスフリートを活用した Amazon EMR のコスト最適化 講師:川村 誠(アマゾン ウェブ サービス ジャパン株式会社 ソリューション アーキテクト) 概要:Amazon EMR はスポットインスタンスとインスタンスフリートを活用することで、コストを最適化することができます。直近のサービスアップデートでそれらの活用がより簡単に運用可能となりました。本セッションでは […]

Read More

Amazon EMR を使用して Amazon DynamoDB の Time to Live (TTL) 属性をバックフィルする

データベースへの一括更新は混乱を招き、ダウンタイム、ビジネスプロセスのパフォーマンスへの影響や、コンピューティングリソースとストレージリソースの過剰プロビジョニングを引き起こす可能性があります。一括更新を実行する場合、迅速に実行でき、ビジネスを中断することなく運営でき、コストを最小限に抑えるプロセスを選択する必要があります。Amazon DynamoDB などの NoSQL データベースを使ってこれを実現する方法を見てみましょう。 DynamoDB は、テーブル内の項目中、どの項目にも存在しない属性を持てる項目を含められる柔軟なスキーマ構造を提供する NoSQL データベースです (リレーショナルデータベースでは、他の行から除外される一方、一部の行にしか存在できない列もあります)。DynamoDB は極端なスケールで実行するように構築されているため、ペタバイトものデータと数兆もの項目を持つテーブルを使用できます。そのため、このようなテーブル全体の変更を行うには、スケーラブルなクライアントが必要です。このようなユースケースでは、通常、Amazon EMR を使用します。DynamoDB は伸縮自在な容量を提供するため、不定期の一括操作に対応できるように、通常の操作の過程で過剰にプロビジョニングする必要はありません。一括操作中にテーブルに容量を追加し、完了したらその容量を削除するだけです。 DynamoDB は Time to Live (TTL) と呼ばれる機能をサポートしています。TTL を使用すると、期限切れの項目を追加コストなしでテーブルから自動的に削除できます。通常、項目を削除すると書き込み容量が消費されるため、TTL を使用すると、特定のユースケースでは大幅なコスト削減を実現できます。たとえば、TTL を使用して、長期間保持するために Amazon Simple Storage Service (Amazon S3) バケットにすでにアーカイブしたセッションデータまたは項目を削除できます。 TTL を使用するには、タイムスタンプ (Unix エポックからの秒数としてエンコード) を含む項目の属性を指定します。この時点で、DynamoDB は項目が期限切れであると見なします。項目の有効期限が切れると、DynamoDB は通常、有効期限から 48 時間以内に項目を削除します。TTL の詳細については、「Time to Live を使用した項目の期限切れ」を参照してください。 DynamoDB テーブルにデータを配置する前に TTL 属性を選択するのが理想ですが、DynamoDB ユーザーは、テーブルにデータを含めた後に TTL を使い始めることがよくあります。アプリケーションを変更してタイムスタンプ付きの属性を新しい項目または更新された項目に追加するのは簡単ですが、古い項目すべての TTL 属性をバックフィルする最良の方法は何でしょうか? 通常、DynamoDB テーブルの一括更新には […]

Read More

Amazon EMR の伸縮性と回復力を高めるための Spark の機能強化

お客様は Amazon EMR の伸縮性を利用して、ワークフローが完了したとき、またはより軽いジョブを実行するときにクラスターをスケールしてコストを節約しています。これは、低コストの Amazon EC2 スポットインスタンスでクラスターを起動する場合も同様です。 Amazon EMR の Automatic Scaling 機能により、お客様はクラスターの使用状況やその他のジョブ関連のメトリックスに基づいて、クラスターを動的にスケーリングできます。これらの機能は、リソースを効率的に使用するのに役立ちますが、実行中のジョブの途中で EC2 インスタンスがシャットダウンすることもあります。これにより、計算とデータが失われる可能性があり、それがジョブの安定性に影響を与えたり、再計算による重複作業を招いたりする可能性があります。 実行中のジョブに影響を与えずにノードを適切にシャットダウンするために、Amazon EMR は Apache Hadoop の廃止メカニズムを使用しています。このメカニズムは Amazon EMR チームが開発し、コミュニティに還元したものです。これはほとんどの Hadoop ワークロードではうまく機能しますが、Apache Spark ではそれほどうまくいきません。Spark は現在、ノードの損失に対処する際、さまざまな問題点に直面しています。これにより、失われたタスクやデータをリカバリおよび再計算しようとしてジョブが停滞したり、場合によってはジョブがクラッシュしたりすることもあります。Spark の未解決問題のいくつかについての詳細は、以下のリンクを参照してください。 フェッチのエラーに関連した問題 シャットダウン中のノードを追跡し、それらのノードに対するタスクのスケジューリングを回避する これらの問題のいくつかを回避し、お客様が Spark を使用して Amazon EMR の伸縮性機能を最大限に活用できるようにするために、Amazon EMR では、オープンソースの Spark をカスタマイズしてノードの損失に対する回復力を高めることができます。再計算は最小限に抑えられ、ジョブはノードのエラーおよび EC2 インスタンスの終了からより迅速にリカバリできます。これらの改善点は、Amazon EMR リリースバージョン 5.9.0 以降で反映されています。 このブログ記事では、問題に対処するためにオープンソースの Spark でノードの損失に対処する方法と、Amazon EMR の改善にまつわる問題点の概要について説明します。

Read More

Amazon EMR で Apache Atlas を使用して、メタデータの分類、系統および発見を行う

  今日の世界ではデータの役割が絶えず進化し、増大しているため、データガバナンスが効果的にデータを管理する上で重要な側面となっています。多くの組織は、データレイクを単一のリポジトリとして使用して、組織の事業体に属するデータをさまざまな形式で格納しています。メタデータ、カタログ化、およびデータ系統の使用は、データレイクを効果的に使用する上で鍵をにぎります。 この記事では、Amazon EMR にインストールされた Apache Atlas がこれを行う上でどのように機能するかについて説明します。この設定を使用すると、データを動的に分類し、さまざまなプロセスを経る際にデータの系統を表示できます。この一部として、Atlas のドメイン固有言語 (DSL) を使用してメタデータを検索できます。 Amazon EMR と Apache Atlas の紹介 Amazon EMR は、Apache Hadoop や Spark などのビッグデータフレームワークの実装を簡素化するマネージドサービスです。Amazon EMR を使用している場合、定義済みのアプリケーションセットから選択するか、リストから独自のものを選択できます。 Apache Atlas は、Hadoop のエンタープライズ規模のデータガバナンスおよびメタデータフレームワークです。Atlas は、組織がデータ資産のカタログを作成するためのオープンなメタデータ管理およびガバナンス機能を提供します。Atlas は、データがどのように進化したかを表す、ストレージ系統を含むデータ分類をサポートしています。また、重要な要素とそのビジネス定義を検索する機能も提供します。 Apache Atlas が提供するさまざまな機能の中でもとりわけこの記事で関心を寄せる中核的な機能は、Apache Hive のメタデータ管理とデータ系統です。Atlas のセットアップが成功したら、ネイティブツールを使用して Hive テーブルをインポートし、データを分析して直感的にエンドユーザーにデータ系統を提示します。Atlas とその機能の詳細については、Atlas のウェブサイトをご覧ください。 AWS Glue Data Catalog 対Apache Atlas AWS Glue Data Catalog は、さまざまなデータソースとデータ形式にわたる統一されたメタデータリポジトリを提供します。AWS Glue Data […]

Read More

Apache Spark および Hadoop を Amazon EMR に移行してコストを削減

Apache Spark および Hadoop は、分析用のデータ処理向けのフレームワークとして広く普及しています。レガシーアプローチと比較すれば、コストもほんのわずかな額で済みますが、それでもそのスケーリングとなると、依然として高くつくケースがあります。本記事では、TCO を削減し、かつ同時にスタッフの生産性を引き上げる方法について考察します。その実現を可能にするのは、オンプレミスのワークロードの Amazon EMR への移行、良いアーキテクチャの選択、リソースの消費量を削減するよう設計された機能の活用です。今回のアドバイスは、お客様との多数の事例から得た知見に基づいており、主な論点の多くは IDC の Carl Olofson および Harsh Singh が実施したビジネス価値の研究結果によっても検証されています。当該研究はアマゾン ウェブ サービス (AWS) が資金提供しており、IDC ホワイトペーパー「The Economic Benefits of Migrating Apache Spark and Hadoop to Amazon EMR」(2018 年 11 月) としてご覧いただけます。 それではまず、ヘッドラインとして統計データをいくつかご紹介して、Amazon EMR への移行が生むコスト面のプラスのインパクトをご説明します。IDC が調査した Amazon EMR のお客様 9 社では TCO が平均 57% 削減されました。同時に、5 年間の投資利益率の 342% 増しで、8 か月で投資を回収しました。この 9 […]

Read More

Amazon EMR を保護するベストプラクティス

どの業界でも、組織が機能する上で中心となるのは、データです。お客様とデータ戦略について話し合うとき、データの取り込み、保存、処理、分析、配布、最終的なデータを安全性について語ります。 Amazon EMR は、膨大な量のデータを処理するために使用するマネージド型 Hadoop フレームワークです。お客様が Amazon EMR を選ぶ理由の 1 つは、そのセキュリティ機能です。例えば、金融サービスなどの規制された業界や医療分野の FINRA のようなお客様は、データ戦略の一環として Amazon EMR を選びます。ペイメントカード業界データセキュリティ基準(PCI)や 医療保険の携行と責任に関する法律(HIPAA)など、エンティティからの厳しい規制要件に準拠するためのものです。 この記事では、Amazon EMR セキュリティの原則についていくつか説明します。また、Amazon EMR で使用できる機能についての説明は、ビジネスのセキュリティとコンプライアンスの目標を達成するのに役立ちます。使用している共通のセキュリティベストプラクティスについて取り上げます。また、開始するためのサンプル構成もいくつか示しています。詳しい情報については、「EMR管理ガイド」の「セキュリティ」を参照してください。

Read More

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

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

Read More