[レポート] Electronic ArtsがAmazon EMRを活用してデータプラットフォームをモダナイズした方法について学んできました #AWSreInvent #ANT320

福岡オフィスのyoshihitohです。今年はre:Invent2023に現地参加しています。

AWS re:Invent 2023 | Amazon Web Services

ゲーム好きにはおなじみのEA社がどのようにEMRを活用してデータプラットフォームをモダナイズしたか、という興味深いセッションがありました。過去にデータ分析・分析データ処理用途でAmazon EMRを利用する機会があったので、どのような違いがあるか気になり参加してみました。

セッション概要

タイトル

ANT320 | How Electronic Arts modernized its data platform with Amazon EMR

概要

Electronic Arts (EA) handles 30+ billion events daily to better understand their game titles, feature usage, and player behavior. That data is fed into a multi-petabyte native Apache Hadoop-/Hive-based data processing platform that delivers insights for the rest of EA. In this session, learn how EA modernized its data platform by migrating to Amazon EMR, including HDFS to Amazon S3 and 500+ ETL jobs to Apache Spark on Amazon EMR. They also adopted AWS Glue Data Catalog to replace the Hive Metastore. Discover how, as a result, EA improved data processing SLAs by hours, reduced TCO by ~20%, and scaled to handle 2x data volume with zero downtime.

※以降、意訳です

Electronic Arts (以降、EA)はゲームタイトルや機能の利用状況・プレイヤーの行動についてより深く理解するため、毎日300億件以上のイベントデータを処理しています。これらのデータはペタバイト規模のApache Hadoop/Hiveベースのデータプラットフォームにインサイト情報として送られます。このセッションではEAがAmazon EMRに移行することでどのようにデータプラットフォームをモダナイズしたかを学びます。この移行にはHDFSからAmazon S3への移行、500個以上のETLジョブをApache Spark on Amazon EMRに置き換えるといった変更を含みます。また、(セルフホストの)Hive Metastoreを置き換えるためにAWS Glue Data Catalogを採用しました。これらの結果として、EAはデータプラットフォームのSLAを数時間改善し、TCO(総保有コスト)を最大で20%削減しました。また、ダウンタイムを生じるさせることなく2倍のデータ量を処理できるようになりました。

スピーカー

• Alex Ignatius (Electronic Arts)
• Arturo Bayo
• Shivika Verma

セッション動画

セッション内容

セッションでは主に以下の内容が説明されていました。

• 最近のデータ事情とAmazon EMRについて
• EA社におけるデータプラットフォームの移行について

大規模なデータを移行しないといけないけど色々なロールの人たちがそれぞれデータプラットフォームを利用する必要があるため止めづらい、といったなんとも頭が痛くなりそうな制約がある中での移行だったようです。データがペタバイト規模とのことなので尚さら大変そうですね。。

最近のデータ事情とAmazon EMRについて

データの進化について、というタイトルで最近のデータ事情が紹介されていました。人々が想像する以上にデータは存在していて、システムが扱うデータの量はどんどん増え続けています。データは5年ごとに10倍ぐらい増えるけど、データプラットフォームは15年以上の運用に耐えうることが望ましいとのことでした。データが増え続けることで以下のような問題が起こりうると紹介されていました。

• コストが高くなる
• ストレージと計算リソースが不足する
• クラスタ管理の複雑さ
• インフラ構成がスケールしない
• デプロイサイクルが遅くなる
• (SaaSやツール利用の場合) 細かく制御できずロックインされる

Amazon EMRについては以下の内容で説明されていました

• Apache Hive・Spark・PrestoなどのOSSを活用したフルマネージドなビッグデータ分析・処理サービス
• OSSフレームワーク・API互換性が高く、ランタイム環境も最適化されている
• OSSの最新機能が90日以内に利用可能になるなど、常に進化し続けている

以前参画していたプロジェクトで取り扱うデータも同じぐらいのペースで増え続けていて非常に納得感のある数字でした。また、Amazon EMRの互換性や最新機能の取り込み方針は開発者にとって非常にありがたいものだと思います。

EA社におけるデータプラットフォームの移行

データチームと過去の構成について

EA社は世界中に複数のゲームスタジオがあり、それぞれにデータを処理・分析するデータチームがあるとのことでした。中心となる1つのデータプラットフォームがあり、このプラットフォームで個々のデータチームがデータ分析やデータ処理に取り組んでいます。データはAPIやBIツール、サマリ情報など様々な形式で、プロデューサーやデータアナリストなど様々なロールの人々が日々利用しているとのことでした。

データとデータパイプラインについては以下の内容で説明されていました。

• 数10TB/日 のデータを生成している
• 数1,000個のETL/ストリーミングパイプラインがある
• PB(ペタバイト)単位のデータが蓄積されている

既存のデータプラットフォームでは以下のような構成でデータを処理していました。

• 500ノード・3PBのHDFS構成
• S3やPerforceからデータを入力する
• Hadoop/HiveのMapReduceでデータを処理する
• Hive Metastore・S3・その他DBやAPIなど様々な場所・形式のデータを出力する

この構成には以下のような課題があり次世代のデータプラットフォームへの移行を検討したとのことです。

• 技術スタックが古くなりレガシーになった (修正が遅い、もしくは全く更新されないなど)
• 運用・オペレーションコストが高くなる(効率的なオートスケーリングや予測可能かつ一貫したSLAなどの欠如)
• 密結合なアーキテクチャ
• 取り巻く環境の変化

取り巻く環境の変化について、リアルタイム/ニアリアルタイムでより早くデータを分析・処理したいといったビジネス的な要件についても言及されていました。

ゲームは新機能や新キャラといった新しい取り組みをリリースするときにどういった反応があるのか、より早くデータを元に分析するために必要になるといった要件なのかなと推測しています。とはいえ現状で稼働しているデータ処理や分析との兼ね合いもあるのでデータ処理時間や計算リソースの都合で難しいそうだなと感じました。

次世代データプラットフォームの要件とEMRについて

次世代データプラットフォームの要件として以下を提示されていました。

• 既存のデータプラットフォームからシームレスに移行でき、自分たちでデータ処理・データ分析サービスを提供できること (※セッションではself-serviceと説明されていました)
• 様々なワークフローが混ざる場合でも効率的に処理でき、集中型のデータカタログを用意すること
• DevOpsを最適化する
• 予測可能かつ一貫したSLA・コスト構造となること

Amazon EMRであればこの要件を満たせるであろう、ということでAmazon EMRへの移行になったとのことでした。以下が要因として挙げられていました。

• フルマネージドなサービスで、多くのOSSをサポートしている (Apache Spark・Hive・Flink・Icebergなど)
• AWSサービス・製品と統合しやすい
• コストとSLAを最適化しやすい
  • ETLパイプラインごとのリソース分割、スポットインスタンスの活用やハードウェア選択の柔軟性が挙げられていました
• S3ベースのデータレイクを構築できる
• スケーラブルかつ自分たちでサービスを制御できる

次世代データプラットフォームのアーキテクチャは、既存のものに以下の変更を加えていました。セッション内容のスライドもしくは動画が配信されるとアーキテクチャ図を確認できるので、詳細についてはそちらでご確認ください。

• ETLパイプラインごとに一時的(transient)なクラスタを構築する (2,000clusters/day)
• S3とGitからデータを取得する (変更前はGitではなくPerforce)
  • CI・CD機構を活用して、データ変更のタイミングでETLパイプラインを起動する？
• データカタログを(セルフホストな)Hive MetastoreからAWS Glue Data Catalogに変更する
• データはS3・Redshift・Snowflakeに出力する
• その他、監視で PrometheusとGrafanaを利用するように変更

ETLパイプラインは常時起動が必要なものと、バッチ処理的に必要な場合に起動すれば良いものがあるようでした。Amazon EMRの活用によって後者は必要な場合に一時的なクラスタ構築で済むようになったことがコスト削減や処理の効率化に大きく繋がっていそうかなという印象を受けました。自社でHadoopクラスタを構築前提だと一時的なクラスタを組んで捨ててとするのは大変そうですもんね。

CI・CD契機でデータパイプラインを動かすというのも面白い仕組みだなと思いました。これはゲームアセットの変更を取り込む、もしくは静的な設定などを取り込んでいるのでしょうか。次の機会があれば英語力を上げてぜひスピーカーの方に質問してみたいですね。

移行の戦略と計画について

データプラットフォームの移行にあたって、以下の制約が紹介されていました。

• 数1,000個のジョブを蓄積できること (10年以上、かつ様々なETLエンジン)
• ダウンタイムなしで移行すること
• 後方互換性を確保すること
  • ビジネス継続のため、長期間のデータの変遷に耐えられるようにするため

データ変遷は data transitionと表現されていましたおそらく、時間経過とともにデータの項目が増減する、値域が変わるなどの変化が生じても問題なく処理できるようにする、という内容なのかなと推測しています。

データの移行戦略としては以下の内容が紹介されていました。

• アーキテクチャブループリント
  • ジョブとETLの分類
  • ワークフロー・ジョブごとの移行戦略
• 開発とデプロイ戦略
  • migration wave structureとその計画
• 移行中のオブザーバビリティ

本セッションで初めてmigration waveという考え方を知りました。段階的に移行していくことと、1回あたりの移行で変更と評価を繰り返すことでより安全に移行を進めらそうな印象でした。セッションの初めの方で説明されていた通りデータの寿命は長くなりがちなことを考えると、入念に検証を重ねるプロセスの重要性がよくわかりますね。

移行タイムラインについて

移行タイムラインについては以下の内容でした。

• 計画と設計
• 移行作業
• 移行完了

移行作業(migration execution)としては wave 1 〜 wave Nの流れとwave間に行うデータ同期の作業について説明されていました。こちらもセッション中の資料が非常にわかりやすかったので、スライドもしくは動画が配信されたらぜひご確認ください。

移行作業の詳細について

ジョブの分類とその結果に元にした移行後の設計について説明されていました。

• 一時的なEMRクラスタを構築する場合
  • ハードウェア構成のプリセットを用意して簡単に選択できるようにする (T-shirt sizes と説明されていました)
  • 必要に応じてconfigを変更し、利用者側で細かく制御できるようにする
• 高頻度/リアルタイムジョブのオーケストレーション
  • GitLabのCI・CD機構を活用してジョブを実行できるようにする

また、データとメタデータの移行についても紹介されていました。

• データの移行
  • distcpでLegacy HDFS → S3に移行する
• メタデータの移行
  • Hive MetastoreのListenerを活用して、 Hive Metastore → SQS → Lambda → Glue に移行する

メタデータの移行についてはそのまま移行するとGlueにおけるデータベース名を正しく移行できないため、ASTを構築してデータベース名を書き換えて、といった対応を行っていたようです。事前に思いつくことは難しい気がしますが、言われてみるとなるほどとなる対応で面白かったです。

上述したもの以外にも、UDFの互換性やデータの検証方法など様々な考慮点があったようです。

今後について

今後は監視データを活用、分析してEMRコストを最適化していくと説明がありました。

冒頭であったようにデータはどんどん増え続けていくので、時間の経過とともにセッションで紹介していただいた次世代データプラットフォームにも課題が出てくるものと思います。次回EA社のセッションで聞けると良いなと今から楽しみです！

終わりに

データパイプライン周りは実業務についてイメージしやすかったこともあり学びの多いセッションでした。過去に経験したのと似たような課題もあれば、巨大なチームならではの想像したこともなかった課題もあり新鮮でした。データパイプラインを構築するときにデータの規模感・チームの規模感の考え方について参考にしたいと思います。