【レポート】Deep Dive: ビッグデータワークロードをAWSに移行する #reinvent #ABD312

原題

ABD312 - Deep Dive: Migrating Big Data Workloads to AWS

概要

Customers are migrating their analytics, data processing (ETL), and data science workloads running on Apache Hadoop, Spark, and data warehouse appliances from on-premise deployments to AWS in order to save costs, increase availability, and improve performance. AWS offers a broad set of analytics services, including solutions for batch processing, stream processing, machine learning, data workflow orchestration, and data warehousing. This session will focus on identifying the components and workflows in your current environment; and providing the best practices to migrate these workloads to the right AWS data analytics product. We will cover services such as Amazon EMR, Amazon Athena, Amazon Redshift, Amazon Kinesis, and more. We will also feature Vanguard, an American investment management company based in Malvern, Pennsylvania with over $4.4 trillion in assets under management. Ritesh Shah, Sr. Program Manager for Cloud Analytics Program at Vanguard, will describe how they orchestrated their migration to AWS analytics services, including Hadoop and Spark workloads to Amazon EMR. Ritesh will highlight the technical challenges they faced and overcame along the way, as well as share common recommendations and tuning tips to accelerate the time to production.

お客様は、コストを削減し、可用性を高め、パフォーマンスを向上させるために、Apache Hadoop、Spark、およびデータウェアハウスアプライアンス上で実行されている分析、データ処理（ETL）、データサイエンスワークロードをオンプレミス展開からAWSに移行しています。 AWSは、バッチ処理、ストリーム処理、機械学習、データワークフローオーケストレーション、データウェアハウスなどの幅広い分析サービスを提供しています。このセッションでは、現在の環境でコンポーネントとワークフローを特定することに焦点を当てます。これらのワークロードを適切なAWSデータ分析製品に移行するためのベストプラクティスを提供します。 Amazon EMR、Amazon Athena、Amazon Redshift、Amazon Kinesisなどのサービスをカバーします。また、ペンシルベニア州マルヴァーンに本拠を置く米国の投資管理会社であるバンガードも、運用資産4兆4,000億ドル以上を予定しています。 VanguardのCloud Analytics Program担当プログラムマネージャであるRitesh Shah氏は、Amazon EMRのHadoopおよびSparkワークロードを含むAWS分析サービスへの移行をどのように調整したかを説明します。 Riteshは、彼らが直面した技術的課題を強調し、共通の推奨事項とチューニングのヒントを共有して、生産までの時間を短縮します。

登壇

• Bruno Faria - EMR Solutions Architect
• Ritesh Shah - Sr Program Manager, Vanguard

セッションレポート

アジェンダ

• 現在のビッグデータ環境を解体する
• オンプレミスまたは管理されていないアーキテクチャにおける課題の特定
• Amazon EMR と Amazon Web へのコンポーネントの移行
• サービス（AWS）分析サービス
  • ジョブに適したエンジンを選択する
  • コストとスケーラビリティの設計
• お顧客の移行事例
  • VanguardがビッグデータワークロードをAWSに移行する方法

現在のビッグデータ環境を解体する

クラスタは、通常12コア、32/64GB RAM、6〜8TBのHDD（3〜4Kドル）の1Uマシンで、ネットワークスイッチとラックで構成されています。 Hadoopは、オープンソースディストリビューションまたは固定ライセンス期間の商用ディストリビューションです。特徴的なのはHDFSで、ローカルディスクを使用し、3箇所でデータ複製用にサイズが決められています。

同じクラスタ上で実行されているワークロードタイプは、以下のとおりです。

• 大規模 ETL
• インタラクティブクエリ
• マシンラーニングとデータサイエンス
• NoSQL
• ストリーム処理
• 検索
• データウェアハウス

現状は、一日の中で利用が集中している時間帯（上記の左：Over-Utilized）とあまり利用していない時間（上記の右：Under-utilized）で偏りが生じているという課題があります。

オンプレミスのクラスタのビックデータ管理者の役割は、例えば、Hadoopやクラスタの管理（障害、ハードウェアの交換、サービスの再起動、クラスタの拡張）、構成管理、特定のジョブまたはハードウェアのチューニング、開発環境とテスト環境の管理、データのバックアップと災害復旧など様々です。

オンプレミスまたは管理されていないアーキテクチャにおける課題の特定

利用の集中と分散

オンプレミスは密結合したコンピューティングとストレージは余剰なキャパシティを購入する必要があります。ピーク時に過度に利用されあますが、他の時には利用されない傾向があり、コストが高く効率が低い課題があります。

システム管理の違い

分散アプリケーションと可用性の管理は容易ではありません。特にテラバイト〜ペタバイトデータに成長しても耐久性のあるストレージの災害復旧ができる必要があります。新しいフレームワークの追加とアップグレードの実施、複数の環境を管理しハードウェアを調達するには専属のチームが必要です。

Amazon EMR と Amazon Web へのコンポーネントの移行

主要な移行に関する決定事項

クラウド移行するにあたり、現行システムのCPU、メモリ、ディスクサイズ等を可能な限りそのまま移し替え（リフト）、変えた方が良い　部分はクラウドに合わせて変える（シフト）ことで移行を効率化するリフト＆シフト（Lift-and-shift）方式がありますが、AWSのEMRや他の分析サービスの強みを最大限に引き出すならば、リフト＆シフトせずに、ワークロードを見直し、ジョブに適切なツールを使用します。Amazon S3を採用して、ストレージとコンピュートを分離して、コストとスケーラビリティを考慮した設計とします。

サービス（AWS）分析サービス

ワークロードを分析の種類とフレームワークに分類します。

• Batch
  • 数時間から数時間
  • 例：日次/週次/月次レポート
  • Amazon EMR（MapReduce、Hive、Pig、Spark）、AWS Glue
• Interactive
  • 数秒
  • 例：セルフサービスダッシュボード
  • Amazon Redshift、Amazon Athena、Amazon EMR（Presto、Spark）
• Stream
  • ミリ秒で数秒
  • 例：ID盗難警告、1分メトリック
  • Amazon EMR（Spark Streaming、Flink）、Amazon Kinesis Analytics、KCL、Storm
• AI
  • ミリ秒で数分
  • 例：不正検出、需要予測、テキストから音声変換
  • Amazon AI (Amazon Lex, Amazon Polly, Amazon ML, Amazon Rekognition), Amazon EMR (Spark ML), AWS Deep Learning AMI

ユースケースに分類して、ユースケースに適切なAWSサービスは以下のとおりです。

• 低レイテンシSQL -> Amazon Athena、Presto、Amazon Redshift/Spectrum
• DWH/レポート -> Spark、Hive、AWS Glue、Amazon Redshift
• 管理と監視 -> Amazon CloudWatch、AWSコンソール、Ganglia
• HDFS -> Amazon S3
• ノートブック -> Zeppelin Notebook、Jupyter（ブートストラップ動作経由）
• クエリコンソール -> Amazon Athena、Hue
• セキュリティ -> Apache Ranger（CF template）、HiveServer2、AWS IAM roles

EMRはEMRFSを通してAmazon S3を利用していますが、分析サービスはAmazon Redshift、 Amazon DynamoDB、Amazon Kinesis等の様々なストレージ層を選択できます。永続的なデータストアとしてのAmazon S3は、ビッグデータフレームワーク（Spark、Hive、Prestoなど）によってネイティブにサポートされています。ストレージとコンピューティングを分離は重要な要素です。S3は、HDFSとは異なりストレージ用の計算クラスタを実行する必要はありません。Amazon EC2スポットインスタンスを使用して、一時的なAmazon EMRクラスタを実行できます。S3は複数の多目的の分析クラスタおよびサービスで同じデータを使用できます。S3は99.999999999％の耐久性のために設計されており、データは３箇所に自動複製します。低価格で安全なSSL、クライアント/サーバ側の暗号化をサポートしています。

ジョブに適したエンジンを選択する

HDFSとデータの保管は、非常に頻繁にアクセスされる（ホット）データにはHDFSに保存して、頻繁にアクセスするデータにはAmazon S3 Standardを使用します。アクセス頻度の低いデータにはAmazon S3 Standard-IAを使用し、更にコールドデータはアーカイブするためにAmazon Glacierを使用します。

パーティション、圧縮、ファイルフォーマットなど、Amazon S3 Tipsは以下のとおりです。

• 読取りパフォーマンスを向上させるためにデータを分割する
  • クエリが必要とする読み取り専用ファイル
  • スキャンしたデータの量を減らす
• ファイルサイズを最適化する
  • 小さすぎるファイルは避けてください（通常、128 MB未満のファイル）
• ブロックサイズに厳密に合致するファイルが少なくなりました
  • Amazon S3への呼び出しが少なくなりました（より速いリスティング）
  • 少数のネットワーク/ HDFS要求
• Amazon S3からAmazon EC2への帯域幅を最小限に抑えるためにデータセットを圧縮する
  • 分割可能な圧縮を使用するか、各ファイルをクラスタ上の並列化に最適なサイズにしてください
• Parquetのような列のファイル形式は、読み込みでパフォーマンスを向上させることができます

データパーティショニングの例：

• カラム名ありパーティションの例

ALTER TABLE app_logs ADD PARTITION (year='2015',month='01',day='01') 
LOCATION 's3://bucket_name/app/plaintext/year=2015/month=01/day=01/’;

• カラム名なしパーティションの例

ALTER TABLE elb_logs ADD PARTITION (year='2015',month='01',day='01')
LOCATION 's3://bucket_name/elb/plaintext/2015/01/01/’;

• パーティションの削除

ALTER TABLE orders DROP PARTITION (dt='2014-05-14’,country='IN'),
PARTITION (dt='2014-05-15’,country='IN');

• パーティション設定の変更（LOCATION）

ALTER TABLE customers PARTITION (zip='98040', state='WA') 
SET LOCATION 's3://bucket_name/new_customers/zip=98040/state=WA’;

• カラム名ありパーティションの自動設定

MSCK REPAIR TABLE table_name;

※ MSCK REPAIR TABLEは、Hive互換パーティション（カラム名ありパーティション）の場合のみ機能します。

ファイルフォーマット

分析に用いるデータファイルは、列指向、行指向、テキストの３種類に分類されます。

• 列指向（カラムナ） - ParquetとORC
  • 圧縮済み
  • 列ベースの読取り最適化
  • 統合されたインデックスと統計
• 行指向（Row）-Avro
  • 圧縮済み
  • 行ベースの読み込み最適化
  • 統合されたインデックスと統計
• テキスト-xSV、JSON
  • 圧縮済み・未圧縮のどちらでもよい
  • 最適化されない
  • 一般的で柔軟

CSVファイルとカラムナファイル（parquet）に対して、集計クエリを実行すると、カラムナフォーマットの方が応答時間が短く、スキャンデータサイズが少なく、コストが抑えられます。

SELECT count(*) as count FROM examples_csv
-- Run time: 36 seconds, Data scanned: 15.9GB

SELECT count(*) as count FROM examples_parquet
-- Run time: 5 seconds, Data scanned: 4.93GB

分析に用いる３種類のデータファイルフォーマットをスキャン、読み取りパフォーマンス、書き込みパフォーマンスで考察すると、

• スキャン
  • テキスト - xSVとJSONはファイル全体をスキャンする必要があります
  • Avro - 列のサブセットのみを選択する場合の列の最適化
  • ParquetとORC - 行のサブセットのすべての列を選択するときに最適な行
• 読み取りパフォーマンス
  • テキスト - 遅い
  • Avro - 最適（ユースケース固有）
  • ParquetとORC - 最適（ユースケース固有）
• 書き込みパフォーマンス
  • テキスト - 遅い
  • Avro - 良い
  • ParquetとORC - 良い（ビッグデータセットではオーバーヘッドがある）

外部 Hive metastore

永続メタストアまたは異なるクラスタ、サービス、およびアプリケーションによって共有されるメタストアが必要な場合は、外部メタストアを使用します。外部メタストアには2つのオプションがあります：

• Amazon Relational Database Service（Amazon RDS）/ Amazon Aurora
• AWSグルーデータカタログ（Amazon EMRバージョン5.8.0以降のみ）
  • 検索メタストア
  • クローラを利用して新しいデータ、スキーマ、パーティションを検出する
  • スキーマとバージョン管理

オンクラスタまたは自己管理Hiveメタストアを利用する代わりに、HiveおよびSparkの外部テーブルメタデータを格納するためにAWS Glue Data Catalogを使用することができます。これにより、外部テーブルのメタデータをクラスタ外のAmazon S3に簡単に格納できます。

AWS Glue Data CatalogをAmazon EMRコンソール、AWS Command Line Interface（CLI）、またはAWS SDKとAmazon EMR APIで使用するようにAmazon EMRクラスタを設定できます。

コストとスケーラビリティの設計

高度なスポットプロビジョニングのためのインスタンス群。

• SpotおよびOn-Demandを使用したインスタンス・タイプのリストからのプロビジョニング。
• 容量/価格に基づいて最適なAvailability Zoneを起動します。
• スポットブロックのサポート。

一時的または長時間のワークロードがあります。

この対策として、EMR上での操作：自動スケーリングでコストを削減します。

セキュリティ - ガバナンスと監査

• AWS IAM
• Amazon Cognito
• Amazon CloudWatch および AWS CloudTrail
• AWS KMS
• AWS Directory Service
• クラスタAmazon S3アクセスのためのAmazon S3アクセスのログ
• Amazon Macie
• YARNとアプリケーションログ
• Apache Ranger

Vanguardの移行事例

世界最大の投資会社である、Vanguardの移行事例をご紹介します。

VanguardがビッグデータワークロードをAWSに移行する方法

オンプレミスは、以下の課題がありAWSに移行するに至りました。

• 密結合されたコンピューティングとストレージ
• ピーク時に過度に利用され、他の時には利用されない
• 異なるタイプのワークロードからの複合的な影響
• DR(disaster recovery)環境が不足している
• クラスタを維持するための専用チームが必要
• ハードウェアの調達サイクルが長い
• ハードウェアのセットアップ時間が長い
• 複雑なアップグレード調整は不定期なアップグレードが必要になります
• 高い総保有コスト（TCO）
• LOB（基幹業務）に請求するのが難しい

EMR のワークロードをわかりやすく解析する

取り込みワークロード

• 一時的なEMRベースの取り込みクラスタ
• Amazon S3ベースのデータレイク
• KMSを使用した利用中および未使用のデータの暗号化
• IAMを使用したS3バケットアクセス制御ポリシー
• Oozieベースのワークフローを起動するためのステップAPI
• Sqoop、Snowball、CDC（Attunity）ベースのデータ取り込み
• Hive/TezとSparkベースのデータ処理
• CloudWatchとSplunkベースの監視

学んだ教訓

• インフラと取り込みコードの分離
• インスタンスの種類とクラスタのサイジング
• PII(個人を特定できる情報)データの難読化
• LOB（基幹業務）ルールに基づくデータの分離

分析ワークロード

• 永続的なEMRベースの分析クラスタ
• クエリエンジンとしてのHive/TezとPresto
• SparkとPythonベースの分散処理
• ユーザーインタラクティブツールとしてのHueとTableuau
• ZeppelinとJupyterベースのnotebookで、インタラクティブでコラボレートデータ探索が可能
• Amazon S3のHive SQL AuthおよびIAMバケットポリシーを使用した認証

学んだ教訓

• データガバナンス（メタデータ、系統など）
• データへのアクセスの監査
• インスタンスの種類とクラスタのサイジング
• クエリと処理エンジンとのユーザーツールの統合

最後に

今後、もっとも重要なことはデータ処理パイプラインを拡張して、リアルタイムデータ取り込み、可視化と分析することです。将来的にAIとMLの実験や多くのAWSサービスを活用することです。

感想

このセッションでは、オンプレミスのHadoopクラスタをAWSに移行するにあたり、フルマネージドサービスであるAmazon EMRを採用しています。運用コストを抑えて、可用性の高く伸縮自在なオートスケーリングを用いて一時的な処理の集中する課題を解決しています。HDFSからS3に変更して、ストレージとコンピューティングを分離した設計に見直している点がポイントになります。ハブストレージであるS3に移行することで、AWSが提供する様々なビッグデータ関連サービス（Redshift、Athena、kinesis、Glue）とシームレスに連携できるようになりました。安易なリフト＆シフトではなく、AWSがの強みを活かした拡張性のあるデータ分析基盤に刷新することで、将来的なリアルタイム分析の対応や、AWSが提供するAIやMLの関連サービスと連携できる拡張性が確保できました。