Middleware Deep Talks (2019.5.23) @AWSLoft で発表したスライドです。

1. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Noritaka Sekiyama
Senior Cloud Support Engineer, Amazon Web Services Japan
2019.05.23
S3 整合性モデルと Hadoop/Spark の話

2. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
関山 宜孝 (Noritaka Sekiyama)
Senior Cloud Support Engineer
- AWS サポートの中の人
- 専門は Big Data
(EMR, Glue, Athena, …)
- AWS Glue の専門家
- Apache Spark 好き
Who I am...
@moomindani

3. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
今日話すこと
• S3 整合性モデルの話
• Hadoop/Spark と S3 整合性モデルの関係と緩和方法
（Hadoop/Spark を使ったことのない方、あまり興味のない方にも、
ミドルウェアから S3 を活用する工夫の一例としてお聞きいただければ）
今日話さないこと
• Hadoop/Spark の仕組み、最新動向
アジェンダ

4. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
オブジェクトストレージサービス
• 高いスケーラビリティ、可用性、耐障害性 (99.999999999%)、セ
キュリティ、およびパフォーマンスを提供
• 単一オブジェクトの最大サイズ： 5TB
• オブジェクトはバケット配下のユニークなキー名で管理される
• ディレクトリは S3 コンソール上では疑似的に表現されるが、実態としては存
在しない
• ファイルシステムではない
従量課金
• 主に、保管されたデータサイズと、リクエストに対して課金
Amazon S3

5. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
新規オブジェクトの PUT: 書き込み後の読み込み整合性
存在しないオブジェクトの HEAD/GET: 結果整合性
PUT および DELETE の上書き: 結果整合性
オブジェクトの LIST: 結果整合性
https://docs.aws.amazon.com/AmazonS3/latest/dev/Introduction.html#ConsistencyModel
S3 整合性モデル

6. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
書き込み後の読み込み整合性
• PUT したオブジェクトを直後に GET すると一貫した結果が得られる
• 結果整合性ではない
新規オブジェクトの PUT
1. PUT
s3://middwaredeeptalks/path_to_objectA.txt
2. GET
s3://middwaredeeptalks/path_to_objectA.txt

7. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
結果整合性
• PUT 前のオブジェクトを存在確認のために HEAD/GET して、
その後にオブジェクトを PUT して GET すると結果整合性となる
存在しないオブジェクトの HEAD/GET
1. HEAD or GET
s3://middwaredeeptalks/path_to_objectB.txt
2. PUT
s3://middwaredeeptalks/path_to_objectB.txt
3. GET
s3://middwaredeeptalks/path_to_objectB.txt

8. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
結果整合性
• 既存オブジェクトを PUT して GET すると古いデータが返却される場
合がある
• 既存オブジェクトを DELETE して GET すると削除済データが返却さ
れる場合がある
PUT および DELETE の上書き
1. PUT/DELETE
s3://middwaredeeptalks/path_to_objectC.txt
2. GET
s3://middwaredeeptalks/path_to_objectC.txt

9. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
結果整合性
• 新規オブジェクトを PUT して直後に LIST すると、追加されたオブ
ジェクトがリストに含まれない場合がある
• 既存オブジェクトを DELETE して直後に LIST すると、削除済のオブ
ジェクトがリストに含まれる場合がある
特に LIST 結果整合性は、Hadoop/Spark に影響が大きい
オブジェクトの LIST
1. PUT
s3://middwaredeeptalks/path_to_objectD.txt
2. LIST
s3://middwaredeeptalks/

10. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
入力データの取得
• 引数にとった S3 の任意のパスのデータを分散処理のために取得
1. 対象のパスを LIST
2. LIST で返却されたキーに対して HEAD (存在確認)
3. LIST で返却されたキーに対して GET (オブジェクト取得)
• 複数のジョブを多段で構成してパイプラインを組む場合、前段の
ジョブの出力を後段のジョブの入力に使用することになる
⎼ 例：複数ステップの ETL データ処理パイプライン
– ステップ1: 入力の生データを整形、フォーマット変換
– ステップ2: 変換後のデータを入力として統計処理
Hadoop/Spark から S3 へのよくある操作その1

11. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
中間データの最終出力先への移動
• 中間出力先にデータを一時的に書きこみ、その後で対象のパスの
データを LIST して最終出力先に MV/RENAME
⎼ 中途半端な状態のデータを見えなくするため
• S3 には MV/RENAME の概念がないため、以下の手続きが必要
1. 中間出力先のパスを LIST
2. LIST で返却されたキーから最終出力先のキーへ COPY (オブ
ジェクトコピー)
3. LIST で返却されたキーに対して DELETE (元オブジェクト削
除)
（HDFS の MV/RENAME は非常に高速だが、S3 では時間がかかる）
Hadoop/Spark から S3 へのよくある操作その2

12. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
S3 Guard (S3A), EMRFS Consistent view (EMRFS)
• S3 の整合性 (特に LIST 整合性) をチェックする仕組み
• S3 オブジェクトのメタデータ管理に DynamoDB を使用
• S3 と DynamoDB が返却する結果を突合して最新のビューを提供
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-consistent-view.html
Hadoop/Spark における S3 整合性の影響緩和
Cluster
S3
HDFS
App
Temp
data
DynamoDB
Object PUT/GET
Metadata PUT/GET

13. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
S3A Committer, EMRFS S3-optimized committer
• S3 マルチパートアップロードの仕組みを活用
• ジョブ/タスクコミットフェーズ中に S3 への LIST/RENAME オペレー
ションを回避し、アプリケーションのパフォーマンスを向上
• ジョブ/タスクコミットフェーズで S3 結果整合性による問題を回避し、
タスク失敗時のジョブの正確性を向上
⎼ 中間出力先にデータを一時的に書きこむ代わりに、マルチパートアップロードを開始
（この時点ではファイルは見えない）
⎼ 書き込みが完了したら MV/RENAME する代わりに、マルチパートアップロードを終了
（LIST してコピーとかしなくていい）
https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-s3-optimized-committer.html
https://aws.amazon.com/blogs/big-data/improve-apache-spark-write-performance-on-apache-parquet-formats-with-the-emrfs-s3-optimized-
committer/
Hadoop/Spark における S3 整合性の影響緩和

14. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
マルチパートアップロードの開始
• 開始リクエストを送信してアップロードIDを取得
各パートのアップロード
• アップロードIDとパート番号を添えてアップロード
• 明示的に完了/中止しないとパートは残存し、ストレージ課金が継続
マルチパートアップロードの完了/中止
• パート番号に基づいて昇順に連結したオブジェクトを S3 上に生成
• 個々のパートは解放され、ストレージも解放される
参考：マルチパートアップロードの流れ
マルチパート
アップロード
の開始
各パートの
アップロード
マルチパート
アップロード
の完了/中止

15. © 2019, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
パフォーマンス比較
• EMR 5.19.0 (マスター m5d.2xlarge / コア m5d.2xlarge x 8台)
• 入力データ: 15 GB (100 Parquet ファイル)
参考: EMRFS S3-optimized committer の性能
EMRFS consistent view 無効 EMRFS consistent view 有効
INSERT OVERWRITE DIRECTORY ‘s3://${bucket}/perf-test/${trial_id}’
USING PARQUET SELECT * FROM range(0, ${rows}, 1, ${partitions});