Amazon Web Services ブログ

Category: Amazon EMR

RStudio を実行するために Amazon EMR のエッジノードを立ち上げる

RStudio Server は R およびデータサイエンティストの間で人気のツールにブラウザベースのインターフェイスを提供します。データサイエンティストは分散型トレーニングを実行するために、Amazon EMR 上で実行する Apache Spark クラスターを使用します。前回のブログ記事では、著者が Amazon EMR クラスターに RStudio Server をインストールする方法を紹介しました。しかし、特定のシナリオでは、スタンドアロンの Amazon EC2 インスタンスにインストールし、リモートの Amazon EMR クラスターに接続するケースも考えられます。EC2 上で RStudio を実行することの利点としては次のようなものが考えられます。 EC2 インスタンス上で RStudio Server を実行することにより、インスタンス上に科学的モデルとモデルアーティファクトをそのまま保存できます。アプリケーションの要件を満たすために、EMR クラスターの再起動が必要になることがあります。RStudio Server を別途実行することで、柔軟性が向上し、Amazon EMR クラスターにすべて依存する必要がなくなります。 Amazon EMR のマスターノード上に RStudio をインストールするには、同一ノード上で稼動しているアプリケーションとリソースを共有する必要があります。スタンドアロンの Amazon EC2 インスタンス上で RStudio を実行することで、他のアプリケーションとリソースを共有する必要なく、リソースを使用できるようになります。 ご使用の環境に複数の Amazon EMR クラスターをお持ちの方もおいでかと思います。エッジノードに RStudio を配置すると、ご使用の環境で任意の EMR クラスターに接続できるという柔軟性が得られます。 Amazon EMR […]

Read More

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

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

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 EMR で TLS カスタム証明書プロバイダーを使用して転送中のデータを暗号化する

多くの企業は、クラウド セキュリティのポリシーを厳格に規制しています。機密データが処理される 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 […]

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 Black Belt Online Seminar] AWS で構築するデータレイク基盤のアーキテクチャ 資料及び QA 公開

こんにちは、マーケティングの鬼形です。 先日(2018/4/24)開催しました AWS Black Belt Online Seminar「AWS で構築するデータレイク基盤のアーキテクチャ」の資料を公開致しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。

Read More

プロセッサの投機的実行 – オペレーティングシステムの更新

モダンコンピュータプロセッサ上で投機的実行によるサイドチャネル分析の調査が新しく公開されたのを受け、AWS は AWS Security Bulletin(セキュリティ情報)AWS-2018-013 を先日公開しました。このセキュリティ情報では、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 の3つのセキュリティ勧告に触れています。これらの勧告は Google Project Zero の調査に基づいたもので、Google Project Zero の発表はモダンコンピュータプロセッサ上でのサイドチャネル分析の新しい方法を発見したというものでした。これらの方法は、基礎的な技術、具体的には投機的実行に着目したもので、投機的実行は多くのベンダーのプロセッサに用いられています。そのため研究結果の対象となる範囲は幅広く、その範囲はハイパーバイザーからオペレーティングシステム、さらには Web ブラウザ、携帯電話からクラウドを構成するデータセンター内のサーバにまで及びます。   EC2 インスタンスの分離   Amazon EC2 のすべてのインスタンスは、上述の CVE に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 大多数の EC2 ワークロードに有意なパフォーマンスの影響は見られていません。   オペレーティングシステムへのパッチ   現代のオペレーティングシステムには、「ユーザー空間」プロセスからのカーネル分離、それぞれのプロセスの分離などの、いくつかのタイプのプロセス分離があります。影響を受けうるプロセッサ上でオペレーティングシステムが実行されている環境では、いかなる設定においても、公開された 3 つの問題すべてがプロセス分離に影響を与える可能性があります。ハイパーバイザで実装されている保護は、オペレーティングシステム内のプロセスレベルの分離にまで拡張されないため、リスクを軽減するためにオペレーティングシステムパッチが必要です。 準仮想化(PV)インスタンスでは、CVE-2017-5754 のプロセス間の問題に対処するためのオペレーティングシステムレベルの保護は無いことに注意してください。PV インスタンスは、前述のようにインスタンス間の問題について AWS ハイパーバイザーによって保護されます。しかしながら、PV インスタンスにおけるプロセスの分離(信頼できないデータ処理やコードの実行、ユーザのホスト)にご懸念をお持ちでしたら、長期的に見てセキュリティの恩恵を受けるため、HVM インスタンスタイプへの変更を強くお勧めします。PVとHVMの相違点(およびインスタンスアップグレードパスのドキュメント)の詳細については、以下の URL を参照してください。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html インスタンスのオペレーティングシステムにパッチを適用することで、同じインスタンス内で動作するソフトウェアを分離し、CVE-2017-5754 のプロセス間の問題を緩和することを強く推奨します。以下のオペレーティングシステムのパッチの詳細を記載します。 Amazon Linux & […]

Read More

プロセッサの投機的実行に関する調査の公開について

【日本語訳】日本時間 2018年02月14日19:30 関連する CVE: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 日本時間 2018年02月06日09:30 以下は本件に関するアップデートです。 Amazon Linux 用の更新されたカーネルは、Amazon Linux のリポジトリにて入手できます。2018年1月13日以降にデフォルトの Amazon Linux 設定で起動された EC2 インスタンスには自動的に最新のパッケージが含まれています。 最新のパッケージでは、 CVE-2017-5715 に対処するための安定版オープンソース Linux セキュリティの改善がカーネル内に組み込まれています。また 以前取り込まれた CVE-2017-5754 に対処するカーネルページテーブルアイソレーション(KPTI)にもとづいて作成されています。インスタンス内の CVE-2017-5715 のプロセスープロセス間の問題と CVE-2017-5754 のプロセスーカーネル間の問題を効果的に軽減するには、最新の Amazon Linux カーネルまたは AMI にアップグレードする必要があります。詳細は「プロセッサの投機的実行 – オペレーティングシステムの更新」を参照してください。 para-virtualized(PV)インスタンスについては、以下の「PV インスタンスガイダンス」の情報を参照してください。   Amazon EC2   Amazon EC2 のすべてのインスタンスは、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 […]

Read More

LLAPを使用してAmazon EMRでのApache Hiveクエリをターボチャージ!

Apache Hiveは、SQLを使用してHadoopクラスタに格納された大規模なデータセットを分析するための最も一般的なツールの1つです。データアナリストやデータサイエンティストは、大きなデータのクエリ、要約、探索、および分析にHiveを使用します。 Hive LLAP(Low Latency Analytical Processing)の導入により、Hiveが単なるバッチ処理ツールであるという考え方が変わりました。 LLAPは、インテリジェントなインメモリキャッシュを使用して長期実行デーモンを使用し、バッチ指向のレイテンシを覆し、1秒未満のクエリ応答時間を提供します。 この記事では、Hive LLAPのアーキテクチャと、クエリパフォーマンスを向上させるための一般的な使用例など、Hive LLAPの概要を示します。 Amazon EMRクラスタにHive LLAPをインストールして設定し、LLAPデーモンでクエリを実行する方法を学習します。

Read More

HBase on Amazon S3を使用してリードレプリカクラスタをセットアップする

多くのお客様は、低コスト、データ耐久性、スケーラビリティなど、Amazon S3をデータストレージとしてApache HBaseを実行することの利点を活用しています。 FINRAのような顧客は、HBase on S3アーキテクチャーに移行し、ストレージをコンピュートから切り離し、S3をストレージレイヤーとして使用するという多くの運用上の利点とともに、コストを60%削減しました。 HBase on S3を使用すると、クラスタを起動して、長いスナップショット復元プロセスを経る必要がなく、S3内のデータに対してすぐにクエリを開始することができます。 Amazon EMR 5.7.0の発表により、HBase on S3の高可用性と耐久性をクラスタレベルにさらに一歩進化させることができます。S3上の同じHBaseルートディレクトリに接続できる複数のHBase読み取り専用クラスタを開始できます。これにより、リードレプリカクラスタを介して常にデータにアクセスできることを保証し、複数のアベイラビリティゾーンにわたってクラスタを実行できます。 この記事では、HBase on S3を使用したリードレプリカクラスタの設定をご案内します。

Read More