re:Invent 2024: Amazon EMRで実現する費用対効果の高いデータ処理
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Cost-effective data processing with Amazon EMR (ANT344)
この動画では、Amazon EMRにおける費用対効果の高いデータ処理について、スケーラビリティ、使いやすさ、価格性能の観点から詳しく解説しています。EMRの最適化ランタイムがオープンソース版と比べてSparkで3.9倍、Trinoで2.7倍の高速化を実現している点や、Advanced Scalingによる柔軟なリソース管理機能について説明しています。また、Robloxのプリンシパルエンジニアが、数百ペタバイトのデータレイクを持つ同社での実践例を共有し、Blue/Greenデプロイメントの実装やJob Auto-tuningによる30-35%のコスト削減を達成した具体的な手法を紹介しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Amazon EMRによる効率的なデータ処理：セッション概要
みなさん、こんにちは。本セッションにお越しいただき、ありがとうございます。re:Inventを楽しんでいただけていることと思います。本日が最終日ということで、最後までご参加いただき、大変ありがとうございます。幸いなことに、最高のセッションを最後に用意させていただきました。まず自己紹介させていただきます。私はMatthew Liemと申します。EMR、Athena、AWS Datazone、そしてSageMakerを含むデータ処理エンジニアリングチームの一員で、ソリューションエンジニアリングチームを率いています。本日は、RobloxのプリンシパルエンジニアであるAaron Fengと共に登壇させていただきます。今回は、Amazon EMRにおける費用対効果の高いデータ処理について、主にコストに焦点を当てながら、スケーラビリティや使いやすさ、そしてそれらがどのように関連しているかについてお話しさせていただきます。
こちらが本日のアジェンダです。まず、私からデータ処理・分析サービスの概要とEMRについて簡単にご説明させていただき、その後、スケール、使いやすさ、価格性能に関連する具体的なイノベーションと製品機能について詳しくお話しします。実践におけるイノベーションや、お客様の活用事例、そして考慮すべき点についても見ていきます。その後、AaronがRobloxにおける費用対効果の高いデータ処理への取り組みについてお話しします。
AWSのデータ処理・分析サービスとAmazon EMRの特徴
まずは、私たちのデータ処理・分析サービスの概要からご説明させていただきます。私たちのデータ処理・分析サービスは、オープンソースソフトウェア、クエリエンジン、そしてNotebook、ビジュアルETL、クエリエディタなどの開発ツールを使用して、包括的なデータアクセスを提供しています。Apache Spark、Ray、Pythonなどの一般的なフレームワークをサポートしており、あらゆる規模でデータの変換や準備が可能です。リアルタイムでのデータアクセスが必要な場合は、Apache FlinkやSpark Streamingなどのストリーミングフレームワークを提供しています。クエリ分析には、TrinoなどのSQLエンジンを使用できます。Managed Workflow for Apache Airflowを使用すれば、インフラストラクチャを管理することなく、これらの異なるツールやソフトウェアを全てオーケストレーションできます。さらに、Amazon Q developerとの統合により、データの準備やデータ統合、トラブルシューティングやデバッグ、コード生成まで、あらゆる面でサポートを受けることができます。
データ処理・分析サービスの重要な部分を担っているのがAmazon EMRです。Amazon EMRは、Apache SparkとTrinoのパフォーマンス最適化ランタイムを提供し、ビッグデータや分析において最高の価格性能比を実現します。デプロイメントオプションについても柔軟性があり、EMR on EC2、EMR on EKS、そしてサーバーレスでの実行が可能です。最近追加されたSparkにおけるネイティブな細粒度アクセス制御や、CV処理とTLSエンドポイントサポートの改善により、最高クラスのセキュリティを提供しています。また、オープンソースのリリースから30日以内にEMRで利用可能にすることを目指し、常に最新の状態を維持するよう努めています。
多くのお客様がEMRで成功を収めています。その中からいくつかご紹介させていただきます。Salesforceのユニファイドインテリジェンスプラットフォームは、ペタバイト規模のデータレイクを管理しており、コスト削減と効率性の向上に重点を置いていました。EMRの数百種類のインスタンスタイプの使用機能、Spotインテグレーション、そしてマネージドスケーリングを活用することで、データ処理量を2倍に増やしながら、月間100万ドルのコスト削減を実現しました。もう一つの素晴らしい例がAutodeskです。Autodeskは、顧客により良いソリューションと機能を提供するために、インサイトと分析を活用しています。既存のプラットフォームで信頼性の問題を抱えていたため、当社に相談がありました。データは彼らのビジネスの中核を担っているため、信頼性の要件を満たしながら、予想されるデータ成長に対応できるプラットフォームが必要でした。Amazon EMRに移行することで、セキュリティと信頼性を向上させながら、30パーセントのコスト削減を実現しました。Autodeskは99.8パーセントの可用性を達成し、移行以降、重大な障害やダウンタイムは発生していません。
これらの素晴らしいカスタマーサクセスストーリーを踏まえて、お客様がこのような成果を達成できた具体的なイノベーションと機能について、より詳しく見ていきましょう。あらゆるデータ処理において、3つの重要な柱となる基盤があります。
これらの柱とは、スケーラブルであること、パフォーマンスとコストのために目的に特化して構築されていること、そして使いやすいことです。これから、これらの各領域について時間をかけて見ていき、Amazon EMRがコスト効率の良いデータ処理に関してどのようなイノベーションを行っているかを確認していきます。
Amazon EMRのスケーラビリティ向上：プロビジョニングから運用まで
まず、スケーラビリティについてですが、お客様との対話から一般的に3つの課題が浮かび上がってきます。1つ目は、キャパシティの確保やクラスターをプロビジョニングするAvailability Zoneの選択、そしてそれらのAvailability ZoneにIPアドレスが十分にあることの確認など、プロビジョニングの難しさです。クラスターが実際に稼働し始めた後は、そのクラスターの運用と健全性の維持が次の課題となります。これには、すでに稼働中のワークロードに影響を与えないようにデプロイメントを行うことも含まれます。さらに、お客様からよく耳にする課題として、問題が発生した際に即座に通知を受け、迅速な原因特定のための適切なツールとログの可観測性を確保する、モニタリングとデバッグの必要性があります。
ここ数年、Amazon EMRは柔軟性を提供し、お客様に代わって判断を行うことで、これら3つの領域をより簡単にすることに注力してきました。プロビジョニングに関して、Amazon EMRはクラスタープロビジョニング時に最大30種類のインスタンスと複数の割り当て戦略を指定できる柔軟性を提供しています。つまり、Amazon EMRがプロビジョニングを行う際、指定された様々なインスタンスの中から、キャパシティとコストの両面で最適なインスタンスを選択します。また、非常に大規模なクラスターのサポートにも重点を置いており、現在では4000ノード以上のクラスターを実行でき、それらのノードには500種類のインスタンスから選択することができます。さらに、可視性の向上や、より優れたデバッグとモニタリングにも大きく注力してきました。
クラスターのプロビジョニング中、insufficient capacity errorやプロビジョニングまたはスケールアップに時間がかかりすぎる場合のタイムアウトなど、リアルタイムのプロビジョニング情報を提供します。インスタンスの選択は、特に数百のクラスターにわたって行う場合、お客様から多く聞かれる大きな課題です。数百から数千のノードにわたって実行される単一のクラスターでさえ、十分なIPアドレスがあることを確認する必要があり、これを適切に行わないと、insufficient capacity errorやプロビジョニングの失敗に遭遇することになります。これにより、ワークロードやパイプラインに遅延が生じることになります。
お客様との対話の中で、どのインスタンスタイプを使用したいか、どの購入オプションを選びたいかといった入力を提供し、あとはプラットフォームに任せたいというニーズがあることがわかりました。既存のAvailability Zoneとインスタンス選択機能により、これらの様々な判断の多くは対応できていましたが、まだ改善の余地がありました。例えば、Availability Zoneを選択する際、クラスター全体の容量ではなく、一部のみを考慮していました。また、SpotインスタンスとOn-Demandノードそれぞれに1つずつしかない等、割り当て戦略の選択肢も限られていました。さらに、一定時間後に失敗するという基本的なリトライ戦略しかありませんでした。
今年実装した改善の1つが、優先順位付き割り当て戦略です。これにより、お客様は異なるインスタンスタイプに優先順位レベルを設定できるようになりました。Amazon EMRは、ベストエフォートベースで優先順位の高いインスタンスを最初に試し、必要に応じて優先順位の低いものにフォールバックします。これは、最新世代のインスタンスを最初に試したい場合や、ワークロードのパフォーマンスが向上すると分かっているインスタンスタイプがある場合に特に有用です。この優先順位付き割り当て戦略と他の改善点により、新しいフローが実現しました。現在では、クラスター全体にわたってAvailability Zoneとキャパシティを選択します。ただし、お客様からの要望により、クラスターを起動してから後でスケールアップしたいというケースもあるため、必要不可欠なノード（PrimaryノードとCoreノード）へのフォールバックは維持しています。また、優先順位付き、多様化、最低価格、キャパシティ最適化など、複数の割り当て戦略をサポートしています。さらに、プロビジョニング中にOn-Demandに切り替える機能も備えており、Spotインスタンスでクラスターのプロビジョニングを試み、キャパシティがない場合はOn-Demandに切り替えることができます。
加えて、ユーザー定義の入力により、指定した回数までリトライを継続するか、素早く失敗するかを選択できる、より柔軟なリトライ戦略も実現しました。
クラスターのプロビジョニングが完了して稼働状態になったら、次は運用とヘルスの維持が必要です。これも、お客様からよく聞かれる課題の1つです。ハードウェア障害への対応や、正常・不正常なインスタンスの置き換えなど、様々なシナリオに対処する必要があります。また、既存のクラスターで実行中のものに影響を与えることなく、変更を加えたり新しいクラスターを立ち上げたりすることも課題としてよく耳にします。Amazon EMRは、これらの運用の多くを簡素化します。
特に強調したい機能の1つが、不健全なノードの自動置換です。大規模なクラスターを運用する際、不健全なノードは一般的な問題であり、様々な理由で発生する可能性があります。例えば、EC2のノードの障害、クラスター上で実行されているアプリケーションによるディスク容量の問題、インスタンスのネットワーク問題によるノードの応答停止などです。Amazon EMRは、ジョブが正常に実行されるよう、常にすべてのノードを監視しています。最悪のシナリオは、料金を支払い続けているにもかかわらず、実際の作業を行っていないインスタンスが存在する状況です。EMRが不健全なノードを検出すると、そのノードを適切にデコミッションし、目標容量を維持するために新しいインスタンスをプロビジョニングします。
このフローは、私たちがお客様に代わって行っている多くの異なる判断を反映しています。例えば、クラスター上で既に実行中のワークロードへの影響を最小限に抑えるため、一度に数台のノードのみを停止します。また、不健全なノードから残りの健全なノードへデータを転送する際には、残りのノードに十分なストレージ容量があることを確認し、データの移動によって他の問題が発生しないようにチェックとバランスを行っています。 リリース以来、すべてのリージョンで毎月110万以上のノードを置き換えてきました。これにより、タスクやジョブを再実行する必要がなくなるため、ワークロードへの影響が減少し、コストも削減されます。
クラスターが健全な状態で稼働し続けることが確保できたら、 次に注目したいのは、モニタリングとデバッグ、そしてクラスター上で何が起きているかについての十分な洞察を得ることです。モニタリングとデバッグに関して、この1年間の私たちのイノベーションと焦点は、クラスター上で何が起きているかをできるだけ早く把握できるよう、リアルタイムのアラートとイベントを提供することでした。さらに、既存のObservability、ロギング、モニタリングソリューションとの統合を容易にし、マネージド型のWebインターフェースと事前構築されたダッシュボードを提供することで、クラスターの状況を簡単に把握できるようにしています。
その具体例の一つが、Amazon CloudWatchのイベントとメトリクスの発行方法です。2024年には、可視性を向上させるため、 EMRはお客様のアクショナブルなインサイトの99%をカバーするようになりました。これには、キャパシティ不足エラー、各種リサイズタイムアウト、VCPリミットやインスタンスリミットなどの制限到達、Spotインスタンスの中断など、あらゆる情報が含まれています。これは、内部チームが機能を開発する際に独自のメトリクスを公開できる中央コントロールプレーンレイヤーを構築し、それらが自動的にお客様のEMRコンソールやEventBridgeに表示されるようにすることで実現しました。
イベント駆動型アーキテクチャを通じて自動化を構築したいお客様は、 イベントを取り込んで、例えばキャパシティ不足を検知し、並行して新しいクラスターをプロビジョニングしたり、下流のチームに遅延を通知してデータの処理が通常より時間がかかる可能性があることを知らせたりといったアクションを取ることができます。対話型の操作を好むお客様のために、同じイベントがAWSコンソールにも表示されます。
Amazon EMRの価格性能比最適化：自動チューニングとストレージ管理
大規模なデータ処理の実行は非常に重要ですが、それをコストとパフォーマンスの両面で効果的に行いたいものです。 コストパフォーマンスについてお客様と話すと、チューニングが難しいことやインフラストラクチャの選択が課題であるという声をよく耳にします。
ストレージの管理も大きな課題の一つです。EMRはこれらすべての領域において、最高の価格性能比を実現するために、最適な設定とコードを自動的に決定することに注力してきました。この実現を可能にした主要なイノベーションの一つが、Apache SparkとTrino向けの最適化ランタイムです。 最新リリースでは、3テラバイトのデータに対するTPC-DSベンチマークにおいて、EMR Sparkはオープンソース版と比べて3.9倍高速です。同様に、EMR Trinoもオープンソース版と比較して2.7倍高速を達成しています。どちらも100% API互換性があり、既存のSparkワークロードをコードや設定を変更することなくEMR上で実行できます。さらに、これらの最適化はデフォルトで有効化されており、実行中のワークロード、スキャンされるデータ、使用されるハードウェアやインフラに応じて適応的に調整されます。
具体例として、チューニングについて見てみましょう。 皆さんもご存じの通り、チューニングは難しいプロセスです。ワークロード用の設定セットを選択する必要がありますが、その設定は他のワークロードには適用できない可能性が高いのです。データは常に変化し進化しているため、今日選択した設定が1ヶ月後のワークロードに最適とは限りません。この課題に対応するため、EMR Sparkは最高の価格性能比を得られるよう、こうした設定の選択を自動的に処理する最適化を行っています。その一例が、シャッフルパーティションです。EMRは、ワークロードと、そのワークロードが現在実行されているインフラに基づいて、最適なシャッフルパーティションと並列度を自動的に決定しようとします。
もう一つの良い例が、アダプティブなジョイン選択です。Sparkアプリケーションの実行時には、ソートマージジョイン、シャッフルハッシュジョイン、ブロードキャストジョインなど、さまざまなタイプのジョインが発生する可能性があります。理想的には、結合されるテーブルとそのサイズなど、データに関するヒントを提供する必要がありますが、EMRは自動的にそれらの入力を取り込み、スキャンされるデータ、テーブル、結合キーを確認して、ワークロードが最高の価格性能比を得られるよう、最も効率的なジョインタイプを自動的に選択します。 インフラ面では、選択したハードウェアがインスタンスを最大限活用できているかを確認することが、よく耳にする課題です。これは特に、異なるインスタンスファミリーやサイズが混在する大規模クラスターでは難しい課題となります。この課題に対応するため、ワークロードが実行されているインスタンスに応じて変化する最適化されたデフォルトExecutorを用意しています。また、Executorのサイズを動的に変更する機能も備えており、使用するすべてのインスタンスタイプに対してExecutorのサイズを個別に設定する心配なく、最大限の利用率を得ることができます。
最後に、ストレージとの相互作用についてです。コンピュートが分離され、すべてのデータがAmazon S3に保存される環境では、S3とエンジン、アプリケーション間の相互作用が非常に重要です。S3のスロットリング、小さなファイル、アプリケーションとストレージ間のネットワークがボトルネックになることなどを考慮する必要があります。これらを踏まえ、私たちはS3との相互作用を減らすことに投資してきました。例えば、複数の操作を必要とするリネームの代わりに、可能な場合はS3に直接書き込みを行います。また、Sparkアプリケーションのステージでフィルターをより下層まで押し下げることでスキャンが必要なデータ量を減らし、実際に取り込む必要のあるデータについては可能な限り並列化を試みています。
その一例が、データプリフェッチです。データプリフェッチでは、Sparkタスクが実際に実行される前に、余剰のネットワーク帯域を使用して非同期的にすべてのデータをプリフェッチしようとします。これにより、ステージが開始される時点でデータがすでに用意されており、その時点でデータを取り込む必要がなくなります。これらは私たちが投資している領域のほんの一例です。ここでの私たちの焦点は、これらの最適化をすぐに使える形で提供し、設定の選択を自動化することです。これまで、スケール、価格性能比について説明してきましたが、使いやすさも重要な要素です。
Amazon EMRの使いやすさ向上：デプロイメントオプションとマネージドスケーリング
私たちのイノベーションは、データ処理に必要な差別化されていない重労働の処理に焦点を当ててきました。例えば、オーケストレーションシステムや監視システムとのネイティブ統合がシームレスに行えるようにすることです。Mattのキーノートでは、すべてのデータ処理、Gen AI、AI/MLのための統合スタジオについて説明しました。以前は異なるパーツを組み合わせる必要がありましたが、現在ではすべてのデータニーズを一か所で満たすことができます。また、私たちが重視しているもう一つの側面は、Amazon EMR on EC2、Amazon EMR on EKS、そしてサーバーレスなど、さまざまなデプロイメントオプションに対応できる柔軟性です。
今日のフォーカスは、マネージドスケーリングの改善についてです。EMRはマネージドスケーリングをサポートしており、これによりハンズオフのアプローチが可能になりました。最大値、最小値、コアノードとSpotノードの数を定義すれば、後はEMRが処理してくれます。お客様はこのシンプルさを高く評価してくださり、素晴らしい結果が得られました。一部のワークロードでは、この機能を有効にすることで最大60パーセントのコスト削減を達成したとの報告もありました。
以前の最適化は、特にSLAに敏感なワークロード向けに設計されていました。スケールアップの際は、パフォーマンスを重視し、ワークロードのボトルネックとならないよう、できるだけ早く十分なキャパシティを提供するように最適化していました。一方、スケールダウンについては、より慎重なアプローチを取り、ジョブが完全に完了するまで待ってからスケールダウンを判断していました。安全であることを確認できた時点で、積極的にスケールダウンを行っていました。
このアプローチは多くのワークロードでうまく機能しましたが、場合によってはリソースの未使用につながることがありました。例えば、短時間で実行されるタスクが急激に増加するスパイキーなワークロードの場合、スケールアップが完了する頃には、タスクの一部または全部が既に終了していて、プロビジョニングされたインスタンスが実際には必要なかったということがありました。同様に、スケールダウンについても、パイプラインに待機中のワークロードがあることを把握しているお客様から、積極的なスケールダウンではなく、ウォームプールとしてインスタンスを維持したいというフィードバックがありました。
これらのユースケースに対応するため、アドバンストスケーリングをリリースしました。アドバンストスケーリングでは、コストを最適化するか、パフォーマンスを最適化するかという意図を柔軟に定義できるようになりました。Amazon EMRは、指定された意図に基づいて自動的にアルゴリズムを調整します。例えば、コストの最適化を重視する場合、スケールアップはより慎重に行われ、一定の割合までスケールアップした後、さらなるスケールアップが必要かどうかを評価します。スケールダウンについては、リソースの使用率とコストの最適化を目指しているため、より積極的に行われます。
パフォーマンスの最適化を目指す場合、スケールアップは現在と同様に、できるだけ早く十分なキャパシティを確保することを目指します。一方、スケールダウンはより緩やかに行われます。これは、ワークロードに影響を与えたり、タスクやアプリケーションの再実行が必要になったりするのを避けるためです。Advanced Scalingはほんの一例ですが、全体的なテーマとしては、できる限り多くのことを自動化し、データ処理プラットフォームの運用負荷を軽減することを目指しています。
Amazon EMRの実践的活用：コスト最適化とSpotインスタンスの戦略
スケール、価格性能比、使いやすさに関するイノベーションについて説明してきました。ここからは、これらのイノベーションの実践的な活用方法と、お客様がどのように活用しているかについての考察を見ていきましょう。まず最初に、コストと使いやすさの観点から、最適なEMRデプロイメントモデルの選び方について説明したいと思います。これまで、Amazon EMR on EC2、Amazon EMR on EKS、そしてAmazon EMR Serverlessの使い方について説明してきました。
どのオプションが最もコスト効率が良いか理解するために、まず料金体系を見てみましょう。すべてのEMRデプロイメントモデルにおいて、EC2のコストとサービスコストが発生します。ストレージやネットワークのコストなども存在しますが、ここではこの2つに焦点を当てます。Amazon EMR on EC2とAmazon EMR on EKSはクラスターベースのデプロイメントモデルで、これらのEC2インスタンスはお客様のアカウントで実行されるため、インスタンスのサイズに応じた標準的な時間単位の料金が発生します。Spotインスタンスやサービスプランをご利用の場合は、それらが適用されます。
EMR Serverlessは完全に私たちのアカウントで実行されるため、EC2コストは発生しません。EMR on EC2のサービスコストについては、EC2と同様の料金体系で、インスタンスのサイズに応じた時間単位の料金が発生し、通常はEC2コストの約25%となります。EMR on EKSとEMR Serverlessでは、アプリケーションが使用する総vCPUとメモリに基づく従量課金モデルとなっています。
具体的なコスト例を見てみましょう。例えば、Sparkアプリケーションが25台のr5.4xlargeインスタンスを使用し、そのクラスターの利用率が80%で、3時間実行されるとします。EMR on EC2の場合、計算は単純です。インスタンス数（プライマリノード1台を含めて26台）に、実行時間とEC2およびEMRの時間単位料金を掛けます。これらを合計すると、約98ドルになります。Serverlessの場合、すべて私たちのアカウントで実行されるためEC2コストは発生しません。サービスコストについては、vCPUとメモリの総使用量を見る必要があります。3時間の80%の利用率で、クラスター全体のキャパシティに80%と3時間を掛けると、約960 vCPUと7,600ギガバイトのメモリとなります。これにvCPUとメモリの時間単位料金を掛けると、約95ドルになります。
ここでの重要なポイントは、時間単位の料金モデルと、EKSやServerlessのような消費量ベースのモデルを比較する際に、利用率が重要な要因となるということです。例えば、このワークロードが80%ではなく50%だった場合、EC2のコストは使用率に依存しないため変わりませんが、Serverlessのコストは60-70ドル程度まで大幅に下がります。 EMR on EC2とServerlessのコスト差を利用率の関数としてプロットすると、オンデマンドの公開価格を使用した場合、70%の利用率が損益分岐点であることがわかりました。EMR on EC2クラスターの利用率が70%を超える場合は一般的にEMR on EC2の方がコスト効率が良く、利用率が70%未満の場合は、EKSやServerlessのような消費量ベースのオプションの方がコストを抑えられます。
利用率がこれほど重要な要因であるため、利用率の計算に何が含まれるのかを理解することが大切です。これはワークロード自体以上のものが関係してきます。 インフラストラクチャの側面では、クラスターのスケールアップ時間が重要な考慮事項です。EMR on EC2では、セキュリティ要件を満たしたり、ジョブ実行に必要なアプリケーションライブラリを事前にパッケージ化したりするために、クラスターをブートストラップする柔軟性を提供しています。その代わりに、クラスターの起動時間が長くなり、EC2側で料金が発生するため、全体の利用率計算に含める必要があります。ワークロードの側面では、特定のワークロードタイプの方が一般的に利用率が高くなることがわかっています。ストリーミングアプリケーションを実行していて、常時10個や15個のExecutorが必要だとわかっているお客様の場合、それらのExecutorに完全にフィットするようにインスタンスのサイズを設定します。このような場合、利用率は非常に高くなり、EMR on EC2が最適なコストオプションとなる可能性が高いです。
最後に強調したいのは、EMRのデプロイメントオプションを比較する際、コストは一つの要因に過ぎないということです。クラスター管理対Serverlessといった運用オーバーヘッドなど、他の考慮すべき点もあります。EKSの場合は、EKSクラスターを管理するチームやその専門知識があるかどうかを考慮する必要があります。ただし、この例ではコストだけに着目しています。
次に取り上げたい実践的なイノベーションは、購入オプションとインスタンスの柔軟性のバランスです。これは、コスト効率の良いデータ処理を実現する上で最も重要な側面の一つです。最初の考慮事項は、異なる購入オプションの選択です。重要なワークロードやSLAに敏感なワークロードは、On-Demandインスタンスで実行することをお勧めします。開発テストや障害を許容できるジョブは、Spotインスタンスで実行できます。興味深い観察として、SpotはOn-Demandと比べて90%のコスト削減を実現できる場合もありますが、リトライ回数やSpotの中断により、ジョブが継続的に実行され、結果的にOn-Demandよりもコストが高くなるケースも見られます。
お客様が実装している戦略の一つは、同じクラスター上でOn-DemandとSpotインスタンスを組み合わせることです。 クラスターの一部をOn-Demandで実行して予測可能性を確保し、Spotインスタンスが利用できない場合でもSLA要件を満たせるようにしつつ、Spotインスタンスを追加して平均コストを下げた追加の計算能力を得ます。 例えば、On-Demandノードのみで10時間実行するクラスターのコストが100ドル（黄色の線で表示）だとします。このクラスターを完全にSpotに変換し、Spotのコストがon-Demandの50%だと仮定すると、コストは100ドルから50ドルに減少します。
On-DemandとSpotの両方のオプションを組み合わせて、それぞれ10ノードずつ使用すると、計算能力は2倍になります。線形的なパフォーマンスを想定すると、実行時間は10時間から5時間に短縮されます。また、On-Demandの時間単価とSpotレートがブレンドされることでコストも削減され、$100から$75に改善されます。コスト最適化においては、Spot Instancesの活用が非常に重要なのです。
Spot Instancesを効果的にコスト活用する上で最も重要な要素の1つが、異なるAvailability ZoneとInstanceタイプに対する柔軟性です。EMRとEC2では最大30種類のInstanceを指定でき、EMRはその中からSpotによる中断が最も起こりにくいものを選択します。Instance poolを多様化して拡大する際には、特定の順序があります。例えば、Rファミリーの2X largeが最適なInstanceタイプとサイズだと判断した場合、まず異なるAvailability Zoneへの分散を行い、次に4X、8X、16Xなど異なるサイズへの展開を行います。その後、AMDやIntelを含む異なる世代やバリアントを追加します。Instanceファミリーの多様化は最後に行います。これは、異なるInstanceファミリーではvCPUとメモリの比率が異なり、リソースの未使用につながる可能性があるためです。
インフラストラクチャ以外の考慮点として、ワークロード自体と障害に対する耐性があります。私たちはEMRクラスターでテストを実施し、5分ごとにノードの20%を削除してSpot中断をシミュレートしました。各アプリケーションのタスク実行時間が同じである数百の異なるSparkアプリケーションを実行したところ、タスク実行時間が120秒未満のSparkアプリケーションでは、ジョブの実行時間にほとんど影響がなく、On-Demand Instancesと同様のパフォーマンスを示しました。しかし、Sparkアプリケーションのタスクが120秒を超えると、ジョブの失敗や実行時間の延長が目立ち始めました。これは、Spot中断が発生した際、EC2が2分間の猶予期間を与えるためです。
この猶予期間があることで、EC2がInstanceを回収する前に実行中の処理を完了させることができます。つまり、Sparkタスクが120秒未満であれば、EC2に回収される前に完了する十分な時間があるということです。さらに、Amazon EMRには、Spotによってノードが回収されることが分かった時点で、そのノードへのタスク割り当てを停止する機能があります。これにより、失敗を防ぎ、再実行の必要性を排除できます。ここでの重要なポイントは、タスクの実行時間が短いほど、Spotの影響を受けにくいということです。データやアプリケーションの性質上、タスクの実行時間をコントロールできない場合もあることは承知していますが、そのような場合は、On-Demandで実行する方が良いかもしれません。
以上で私のパートは終わりです。スケールデータ処理と使いやすさにおけるイノベーションについてお時間を頂き、ありがとうございました。ここからは、Amazon EMRでの効果的なデータ処理へのRobloxの取り組みについて、Aaronにバトンタッチしたいと思います。
Robloxのデータ処理プラットフォーム：Amazon EMRの活用と進化
まず始めに、多くの方々が既に当社についてご存知かと思いますが、もしRobloxをご存じない方のために簡単にご説明させていただきます。私たちは3Dエクスペリエンスプラットフォームを提供しており、クライアントサイドでツールを提供すると同時に、サーバーサイドでこれらのエクスペリエンスをホスティングしています。つまり、3Dエクスペリエンスのための完全なエコシステムを提供しているわけです。現在、600万件のアクティブなエクスペリエンスが存在します。私たちの特徴を理解していただくために言えば、典型的なゲーム会社というよりも、すべてのコンテンツがユーザー生成コンテンツであるYouTubeに近い存在だと言えます。というのも、私たちは実際にエクスペリエンスを公開する立場ではないからです。
よく「ゲーム会社」と言われることがありますが、私たちは幅広い3Dエクスペリエンスを提供しているため、「3Dエクスペリエンス」という表現を使用しています。ゲームはその一側面に過ぎません。例えば、コミュニケーション、ショッピング、エンターテインメント、学習、そしてもちろんゲームプレイなどが含まれます。2024年第3四半期時点で、私たちは8,890万人のDaily Active Usersを抱えています。これだけの日々のユーザーで、約207億時間のエンゲージメント時間を記録しています。また、プラットフォーム上には290万人の開発者がいます。
本題に入る前に、簡単に本日のアジェンダをご紹介させていただきます。まず、私たちのデータプラットフォームの規模についてお話しし、次にAmazon EMRでどのように始まり、現在どのような状況にあるのかについて説明します。そして、バッチプラットフォームについて、非常にハイレベルなアーキテクチャの概要をお話しします。私はデータインフラストラクチャ側で働いているため、DevOpsやインフラ側の事柄について多く考えています。そして最後に、もちろんコストについても理解を深めたいと思います。皆様のコスト削減にも役立てていただければと思います。
残念ながら具体的な数字はお伝えできませんが、私たちの規模感をお伝えできればと思います。現在、Amazon S3上の私たちのデータレイクには数百ペタバイトのデータがあります。すべてのデータをS3に保存しており、毎月数十ペタバイトずつS3のストレージを増やしています。データセンター内の内部サービスは毎日数兆件のイベントを生成しており、数万件のアクティブなパイプラインが稼働しています。ある意味で、私たちのデータプラットフォームは社内の数百人や数千人だけでなく、プラットフォームを利用する何百万人もの開発者にまで影響を及ぼしています。
これは私たちのバッチ処理の非常にハイレベルな概要です。先ほど申し上げたように、データセンターから送信されるすべてのデータをS3に取り込んでいます。もちろん実際には2つ以上のデータセンターがありますが、画面に収めやすくするためにこのように表示しています。右側に見えるのは典型的なオープンソースプラットフォームです。すべてのパイプラインはApache Airflowを使用して書かれています。もちろんAmazon EMRを使用し、すべてのデータをS3に書き戻し、ダッシュボードやアドホッククエリにはApache Supersetを使用しています。1分未満の短時間のクエリについては、通常Trinoを使用しています。
私たちの歩みについてお話しさせていただきます。実は、Amazon EMRの利用は2016年から始まりました。私は2020年に入社したので、2016年当時の状況を知るために、その頃からいる社員の方々に当時のEMRのセットアップや経験について聞いてみました。私の理解では、2016年当時は2〜4台の共有クラスターを運用していて、ノード数は100台前後だったようです。その頃は、処理が必要な時にEMRクラスターを立ち上げ、終わったら停止するという運用をしていました。
2020年に私が入社した時も、まだ2〜4台の共有クラスター構成でしたが、その時点では数千台のノードを運用するようになっていました。私に与えられた課題は、数千台ものノードを抱えているにもかかわらず、今日のような数のパイプラインを実行できないという問題の解決でした。環境をどのようにスケールさせれば、すべてのパイプラインを実行できるようになるのか、それを見極める必要がありました。重要なポイントとして、一度Amazon EMRクラスターを起動すると、決して停止しないという運用をしています。すべてのパイプラインは24時間365日稼働しており、UTC 0時に最も負荷が高くなりますが、基本的に常に何かが実行されている状態です。
スケールアウトの方法はシンプルでした。共有クラスター構成をやめて、チームごとに分割することにしたのです。ここでの課題は、チームによってワークロードが異なる場合があることでした。Amazon EMRは異なるワークロードを混在させて実行できるように設定できますが、時にはワークロードがあまりにも異なるため、それが難しくなることがあります。そこで、ワークロードのタイプごとにスケールアウトを始めました。例えば、優先度の高いパイプラインやダッシュボードがあり、それらを迅速に実行する必要があるため、お互いをブロックしないようにしたいケースがあります。また、バックフィル処理を行いたい場合もありますが、もちろんバックフィルのパイプラインが優先度の高いパイプラインの邪魔をしてほしくありません。
課題は、2〜4台のクラスターから、30台、40台、50台、さらには80台ものAmazon EMRクラスターを管理することになったことです。少数のクラスターであれば、Amazon EMRは手動でも比較的簡単にプロビジョニングできますが、この規模になると複雑になります。コストも多少増加しましたが、私たちの主な焦点は、すべてのパイプラインをSLA内で実行できるようにすることでした。ここでDevOpsが重要になってきます。すべてのAmazon EMRクラスター間で設定の不一致が起きないようにするためのツールが必要だったのです。この目的のために社内ツールを開発し、社内ユーザーが場合によっては自分でAmazon EMRクラスターをプロビジョニングできるような独自の設定を用意しました。
私たちがAmazon EMRで行っている珍しい取り組みの一つが、Blue/Greenデプロイメントです。自動化されたソリューションを持っているため、Blue/Greenデプロイメントにも簡単に対応できます。Amazon EMRのデプロイは、マイクロサービスのデプロイと同じように考えています。Blue/Greenデプロイメントの簡略化した図を見ると、任意の時点で同じワークロードタイプのAmazon EMRクラスターが2つ存在する可能性があります。例えば、Greenクラスターから始めると、そのボックス内のすべてがEMRとみなされますが、追加のコンポーネントもあります。一部のユーザーは、現在アクセス権のない特定のバケットの読み書きが必要になる場合があるため、そのプロビジョニングも行います。場合によっては、プライベートVPCサブネットでルーティング不可能なIPで実行されているクラスターもあるため、EMRの前にELBを実装することもあります。また、Blue/Greenデプロイメント時のクラスター切り替えを容易にするためにRoute 53を使用しています。モニタリングについては、CloudWatchを通じてダッシュボード、メトリクス、ログ、アラートを処理しています。
設定変更が必要な場合、パイプラインの失敗やリスタートを避けるため、その場での変更は行いません。代わりに、新しいBlueクラスターをアウトオブバンドで作成します。Airflowから少量のトラフィックを新クラスターにリダイレクトし、セットアップを確認します。確認後、トラフィックの100%を新クラスターに切り替えます。パイプラインの実行には数時間かかることがあるため、Greenクラスターのすべてのパイプラインが完了するまで待ってから削除します。問題が発生した場合は、古いGreenクラスターに戻すことができます。 Amazon EMRをスケールアウトするためのツールが整備されたら、様々なレベルでのコストを理解することが重要になります。
Robloxのコスト最適化戦略：自動チューニングとマネージドスケーリングの実装
組織レベルでのコスト追跡は単純で、すべてのAmazonアカウントを合算して会社全体のコストを把握します。クラスターレベルでは、すべてのAmazon EMRクラスターにチーム名でタグ付けを行い、各チームが所有するクラスターとそのコストを簡単に把握できるようにしています。次の2つの側面は、私たちが社内で開発したより興味深い機能です：ジョブの見積もりと一元化されたポータルです。チームは多くの場合、クラスター上で複数のパイプラインを実行していますが、そのコストを理解していないため、高レベルのコスト情報を提供しています。また、ユーザーが複数のソースを検索する代わりに、1つの統合された場所で効率性メトリクスとパイプラインのコストを理解できるポータルを作成しました。
ジョブの見積もりについて、高レベルで説明させていただきます。これは正確な計算ではなく見積もりです。なぜなら、一部の要因は不明であるか、正確に判断する価値がないためです。私たちの見積もりは実際のコストにかなり近いものとなっています。考慮すべき重要な要素が2つあります。まず、主にメモリバウンドである全ジョブについて、そのメモリ消費量と実行時間を把握する必要があります。これはYARNリソースマネージャーから取得できます。特に注目するのはメモリ秒で、これは消費されたメモリ量（メガバイト）に実行時間（秒）を掛けたものです。これをインスタンスコストと組み合わせることで、費用を見積もることができます。様々なインスタンスタイプを実行しているため、最も一般的なインスタンスの平均値を使用しており、これが厳密な計算ではなく近似値となる理由です。ただし、この定数により、ユーザーは以前の実行とコストを比較できます。
社内チームの自動レポートでは、チームが効率性を最大化できるよう、2つの重要な側面を強調しています。詳細なデータ分析を必要とせずに素早く評価できるよう、高レベルの効率性スコアを提供しています。この効率性スコアを計算するために、ストレージとコンピュートの両方のコストを調べて無駄を特定します。ストレージコストについては、S3ログを分析してアクセスされていないデータセットを特定し、これを無駄とみなします。データセット分析を通じて、実行中のパイプラインを特定し、コンピュートの無駄を検出できます。すべてのジョブはAirflowでスケジュールされているため、成功するまでに複数回失敗するケースを特定し、これらの失敗を無駄としてカウントできます。このシステムにより、チームは支出と効率性のレベルを理解し、必要に応じてパイプラインが非効率である理由を調査できます。
コスト削減に関して、最初のいくつかのアプローチは単純ですが、最後の2つはより興味深いものです。データレイクがAmazon S3にあり、大量のデータを保持しているため、S3 Intelligent Tieringを有効にすることは有益です。この機能は90日後に適切なストレージ層を自動的に判断し、めったにアクセスされないデータをコールドストレージに移動します。EBSボリュームタイプについては、GP2からGP3への切り替えは大きな節約にはなりませんでしたが、新しいAmazonインスタンスタイプは通常より良い価格とパフォーマンスを提供するため、常に評価する価値があります。GP3の高いバーストレートは追加のメリットでした。Spotインスタンスと On-Demandインスタンスについては、長時間実行されるパイプラインにもかかわらず、Spotインスタンスの使用は実際にコストを増加させたため、On-Demandの使用の最適化に焦点を当てました。
多数の EMR クラスターに規模を拡大していく中で、ワークロードの需要がそれほど高くないチームもあることがわかりました。そのようなケースでは、より少数のクラスターに統合しました。毎月の最低限の計算リソース使用量が分かっている場合は、Amazon と Savings Plan について相談することをお勧めします。これにより、かなりのコスト削減が可能です。
社内で実施している興味深い取り組みが2つあります。それは Job Auto-tuning と Managed Autoscaling です。何万ものパイプラインを手作業でチューニングすることは不可能なため、リソースの無駄遣いを防ぐために Auto-tuning を実装しています。Matt が先ほど説明したように、Managed Autoscaling は非常にセンシティブになる可能性があるため、パイプラインの実行頻度を把握している私たちにとってより適切に動作するように改良しました。これら2つの実装により、Amazon EMR の全体的なコストを約30〜35%削減できています。
Job Auto-tuning について、概要をお話しましょう。 新しいパイプラインを作成すると、最初の3回は通常通り実行させます。Apache Spark ジョブが実行されるたびに、すべてのメトリクスを収集してデータベースに保存します。4回目の実行時に、設定が最適化されているかどうかを評価します。確認する項目は多岐にわたりますが、一般的なものとしては Executor メモリと Executor の数があります。多くの場合、ユーザーは他のジョブからコピー＆ペーストするため、Executor メモリを高く設定しすぎています。私たちは過去3回の実行を振り返り、全 Executor のメモリ割り当ての上位1%を取得し、それに1.5を掛けます（0.5はバッファとして）。下のグラフに示されているように、通常メモリは減少します。Auto-tuning は常に実行されているため、ジョブは時間とともに改善され、何か問題が発生した場合は、中断を避けるために以前の設定に戻します。
これは私が最も話したい内容です - Cluster Auto-tuning についてです。私たちが Managed Autoscaling を選んだ理由は、通常の Autoscaling が5分ごとにしかチェックしないのに対し、5〜10秒で応答できるからです。青い線はクラスターの最大容量を表しています。一般的に、Managed Autoscaling では最大容量を指定すると、通常はその容量まで拡張されます。他の2本の線は、利用可能なメモリと割り当てられたメモリを示しており、これらは近い値であるべきです。左上は頻繁なスケールアップとダウンを示しており、右側は Cluster Auto-tuner を有効にした後の改善を示しています。
下部のセクションでは、より最適化されたクラスターを見ることができます。可能な限りクラスターを維持し、その後、Managed の設定をその場で変更します。クラスターへのバックプレッシャーを生成するために、主に2つのメトリクス（Application Pending と Containers Pending）を監視します。これらのメトリクスが特定の値に達すると、新しい Managed Autoscale の設定を指定します。バックプレッシャーが不十分な場合は、設定をかなり低く変更します。これが、利用可能な容量が非常に高いレベルから非常に低いレベルまで変動する理由であり、これにより大幅なコスト削減が実現できています。Matt が説明した Managed Autoscaling の高度な機能を使用すれば、同様のことが実現できると思います。
そろそろ終わりに近づいてきました。本日、開発サイドについてお話しした3つのポイントをご紹介しました。自動化された再現可能なデプロイメントツールを使用することで、実際にコストを削減できます。なぜなら、ダウンタイムを発生させないBlue/Greenデプロイメントが可能になるからです。また、私たちには非常に多くのパイプラインがあり、手動でチューニングすることは不可能です。ジョブやクラスターを自動チューニングできることで、大幅なコスト削減が実現できています。自動化では検出できない特定の問題もあるため、各チームが使用しているコストや、適切な方法で作業を行っているかどうかを可視化することも重要です。
ここまでが私のパートで、ここからはMattにバトンタッチします。最後に、本日のトークの主要な学びとポイントを手短にまとめさせていただきます。常に最新のEMRリリースとバージョンを使用することをお勧めします。私たちは継続的にランタイムやエンジンのパフォーマンス向上に取り組んでおり、それらの改善は通常、最新バージョンのEMRに反映されます。Instance Fleetsを使用して、できるだけ多くの異なるインスタンスタイプに分散させることで、キャパシティとコストの両面で最適な結果が得られます。最新世代のインスタンスや、より効果的に動作すると分かっているインスタンスを使用したい場合は、優先度ベースの割り当て戦略が便利な機能です。
Advanced Managing Scalingは、EMRのデプロイメントオプションを検討する際に、コストとパフォーマンスの最適化、あるいはその中間のバランスを取りたい場合に検討すべき機能です。コストに基づいて判断を行う際は、利用率が重要な要素となります。Spotインスタンスを使用する場合は、同じクラスター内でOn-DemandインスタンスとSpotインスタンスを組み合わせることをお試しください。On-Demandで安定性を確保しながら、Spotで低コストの追加計算能力を得られる、いいとこ取りが可能です。タスクの実行時間が短いSparkアプリケーションは、一般的にSpotノードで効果的に動作します。一方で、長時間実行されるタスクや、タスクの再実行コストが高いSparkアプリケーションの場合、ほとんどの場合Spotでは上手く機能しません。
以上で終わりとなります。お時間をいただき、プレゼンテーションをお聞きいただき、ありがとうございました。re:Inventの残りの日程もお楽しみください。EMRや本プレゼンテーションの詳細について質問がございましたら、私たちはこの場に残っておりますので、お気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion