Dragon: A Distributed Object Storage at Yahoo! JAPAN (WebDB Forum 2017)

Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved .

2017/9/19 WebDB Forum 2017

1

後藤泰陽

Dragon: A Distributed Object Storage @Yahoo! JAPAN


About me

• 後藤泰陽 / Yasuharu Goto

• ヤフー株式会社 (2008年-)

• ソフトウェアエンジニア

• 主な分野：ストレージ、分散DB

• Twitter: @ono_matope

• 好きな言語: Go

2


Agenda

• Dragonについて

• Dragonのアーキテクチャ

• Dragonの課題と今後

3


Dragon


Object Storage

• Object Storageとは？

• データをファイルではなくオブジェクトとして管理する種類のストレージ

• ディレクトリ操作やロックなどの機能がないかわりに可用性とスケーラビリティが高い

• (一般的に)REST APIが提供され、アプリケーションから使いやすい

• 主なサービス

• AWS: Amazon S3

• GCP: Google Cloud Storage

• Azure: Azure Blob Storage

• モダンなサービス開発には不可欠

5


Dragon

• Yahoo! JAPAN で独自に開発している社内向け分散オブジェクトストレージ

• 目標：高パフォーマンス、高スケーラビリティ、高可用性、高コスト効率

• Written in Go

• 2016年1月リリース (1年8ヶ月の本番稼働実績)

• 規模

• 国内2DCで稼働中

• 合計オブジェクト数：200億オブジェクト

• 合計データ量：11ペタバイト

6


Use Cases

• ヤフー社内で250以上の利用

• 幅広い用途

• 画像・動画コンテンツ

• 各種データ、ログ

• Presto バックエンド(検証中)

7

• Yahoo!オークション (画像)

• Yahoo!ニュース・トピックス/個人 (画像)

• Yahoo!ディスプレイアドネットワーク (画像/動画)

• Yahoo!ブログ (画像)

• Yahoo!スマホきせかえ (画像)

• Yahoo!トラベル (画像)

• Yahoo!不動産 (画像)

• Yahoo!知恵袋 (画像)

• Yahoo!飲食店予約 (画像)

• Yahoo!みんなの政治 (画像)

• Yahoo!ゲーム (コンテンツ)

• Yahoo!ブックストア (コンテンツ)

• Yahoo!ボックス (データ)

• ネタりか (記事画像)

• etc...


S3 Compatible API

• S3互換APIを提供

• aws-sdk, aws-cli, CyberDuck...

• 実装済み

• S3の基本的なAPI (Service, Bucket, Object, ACL...)

• SSE (サーバサイド暗号化)

• 実装中

• Multipart Upload API (最大5TBのオブジェクトのアップロード)

• 今後もAPIを追加予定

8


Performance (with Riak CS/参考値)

• Dragon: API*1, Storage*3, Cassandra*3

• Riak CS: haproxy*1, stanchion*1, Riak (KV+CS)*3

• CassandraとStanchion以外は同一構成のHWを使用。

9

0

500

1000

1500

2000

2500

3000

3500

1 5 10 50 100 200 400

Re

qu

ests

/ s

ec

# of Threads

GET Object 10KB Throughput

Riak CS

Dragon

0

100

200

300

400

500

600

700

800

900

1000

1 5 10 50 100 200 400

Re

qu

ests

/ s

ec

# of Threads

PUT Object 10KB Throughput

Riak CS

Dragon


開発の経緯


Why we built a new Object Storage?

• Octagon (2011-2017)

• 最初の内製オブジェクトストレージ

• Yahoo!ボックス, 電子書籍, その他画像配信, etc...

• 最大7PB, 70億オブジェクト, 3000ノード

• 諸々の技術的課題から、全社基盤ストレージの地位を確立できず

• 「遅くて採用できない」

• 「不安定、よく止まる」

• 「コストが高い」

• 「運用がつらい」

• 代替を検討

11


Requirements

• 要件

• サービスが求める以上の高パフォーマンス

• 急激なデータ需要増に対応できる高スケーラビリティ

• 少人数で簡単に運用でき、高い可用性

• 高いコスト効率

• ミッション

• 使ってもらえる全社ストレージ基盤の確立

12


Alternatives

• 既存のオープンソース製品

• Riak CS: 一部サービスで導入するも、性能がサービス要件を満たさず

• OpenStack Swift: オブジェクト増加時の書き込み性能低下が懸念

• パブリッククラウド

• コスト面で不利

• ヤフーは自社DCでのサービス運用。データローカリティ的にも、自社DCでスケールするストレージが必要

13


Alternatives

• 既存のオープンソース製品

• Riak CS: 一部サービスで導入するも、性能がサービス要件を満たさず

• OpenStack Swift: オブジェクト増加時の書き込み性能低下が懸念

• パブリッククラウド

• コスト面で不利

• ヤフーは自社DCでのサービス運用。データローカリティ的にも、自社DCでスケールするストレージが必要

14

じゃあフルスクラッチで作ろう→ 開発スタート


Architecture


Architecture Overview

• Dragonは API Nodes, Storage Nodes, MetaDB の3コンポーネントで構成される

• API Node

• S3互換のHTTP APIを提供し、全てのユーザーリクエストを受け付ける

• Storage Node

• アップロードされたオブジェクトのBLOBをストアするHTTPファイルサーバ

• 3ノードで VolumeGroupを構成し、グループ内のBLOBは定期的に同期される

• MetaDB (Apache Cassandra cluster)

• BLOBの位置情報を含むアップロードされたオブジェクトのメタデータを保存する

16


Architecture

17

API Nodes

HTTP (S3 API)

BLOBMetadata

Storage Cluster

VolumeGroup: 01

StorageNode

1

HDD2

HDD1

StorageNode

2

HDD2

HDD1

StorageNode

3

HDD2

HDD1

VolumeGroup: 02

StorageNode

4

HDD2

HDD1

StorageNode

5

HDD2

HDD1

StorageNode

6

HDD2

HDD1

Meta DB


Architecture

18

API Nodes

HTTP (S3 API)

BLOBMetadata

Storage Cluster

API NodeとStorage NodeはGo言語による実装

18

VolumeGroup: 01

StorageNode

1

HDD2

HDD1

StorageNode

2

HDD2

HDD1

StorageNode

3

HDD2

HDD1

VolumeGroup: 02

StorageNode

4

HDD2

HDD1

StorageNode

5

HDD2

HDD1

StorageNode

6

HDD2

HDD1

Meta DB


Architecture

19

API Nodes

BLOBStorage Cluster

VolumeGroup: 01

StorageNode

1

HDD4

HDD3

StorageNode

2

HDD4

HDD3

StorageNode

3

HDD4

HDD3

VolumeGroup: 02

StorageNode

4

HDD4

HDD3

StorageNode

5

HDD4

HDD3

StorageNode

6

HDD4

HDD3

API NodeはMetaDBから定期的にVolumeGroupの構成情報を取得してキャッシュ

Meta DB

id hosts Volumes

01 node1,node2,node3 HDD1, HDD2


volumegroup 構成


Upload

20

API Nodes

Meta DB

VolumeGroup: 01

StorageNode

1

HDD2

HDD1

StorageNode

2

HDD2

HDD1

StorageNode

3

HDD2

HDD1

VolumeGroup: 02

StorageNode

4

HDD2

HDD1

StorageNode

5

HDD2

HDD1

StorageNode

6

HDD2

HDD1

1. ユーザーがアップロードを要求すると、APIはランダムに格納先VolumeGroupとHDDを決定し、BLOBをHTTP PUTで3ノードに並列アップロードする

2. アップロードに成功したら、BLOB位置情報を含むメタデータをMetaDBに書き込む

① HTTP PUT

key: bucket1/sample.jpg,

size: 1024bytes

blob: volumegroup01/hdd1/...,PUT bucket1/sample.jpg

② メタデータ


Download

21

API Nodes

Meta DB

VolumeGroup: 01

StorageNode

1

HDD2

HDD1

StorageNode

2

HDD2

HDD1

StorageNode

3

HDD2

HDD1

VolumeGroup: 02

StorageNode

4

HDD2

HDD1

StorageNode

5

HDD2

HDD1

StorageNode

6

HDD2

HDD1

② HTTP GET

key: bucket1/sample.jpg,

size: 1024bytes

blob: volumegroup01/hdd1/...,PUT bucket1/sample.jpg

① メタデータ

1. ダウンロード時、APIはまずMetaDBからオブジェクトのメタデータを取得2. メタデータをもとにBLOBを保持するStorageにHTTP GETをリクエストし、ユーザにレスンポンスする


Failure Recovery

22

API Nodes

Meta DB

VolumeGroup: 01

StorageNode

1

HDD2

HDD1

StorageNode

2

HDD2

HDD1

StorageNode

3

HDD2

HDD1

VolumeGroup: 02

StorageNode

4

HDD2

HDD1

StorageNode

5

HDD2

HDD1

StorageNode

6

HDD2

HDD1

VolumeGroupを構成するノードのHDDが障害を起こした場合…


Failure Recovery

23

API Nodes

Meta DB

VolumeGroup: 01

StorageNode

1

HDD2

StorageNode

2

HDD2

HDD1

StorageNode

3

HDD2

HDD1

VolumeGroup: 02

StorageNode

4

HDD2

HDD1

StorageNode

5

HDD2

HDD1

StorageNode

6

HDD2

HDD1

HDD交換後に、同一グループの他のノードのHDDからデータを転送し、復旧します

HDD1


Scaling out

24

API Nodes

Meta DB

ストレージのキャパシティをクラスタに追加する場合は…

24

VolumeGroup: 01

StorageNode

1

HDD2

HDD1

StorageNode

2

HDD2

HDD1

StorageNode

3

HDD2

HDD1

VolumeGroup: 02

StorageNode

4

HDD2

HDD1

StorageNode

5

HDD2

HDD1

StorageNode

6

HDD2

HDD1

id hosts Volumes



volumegroup 構成


Scaling out

API Nodes

Meta DB

新しいStorage NodeでVolumeGroupを構成し、MetaDBに登録するだけでキャパシティを追加可能

25

VolumeGroup: 01

StorageNode

1

HDD2

HDD1

StorageNode

2

HDD2

HDD1

StorageNode

3

HDD2

HDD1

VolumeGroup: 02

StorageNode

4

HDD2

HDD1

StorageNode

5

HDD2

HDD1

StorageNode

6

HDD2

HDD1

VolumeGroup: 03

StorageNode

7

HDD2

HDD1

StorageNode

8

HDD2

HDD1

StorageNode

9

HDD2

HDD1

id hosts Volumes




volumegroup 構成


Not Consistent Hash?

• DragonはメタDBによるマップ型の分散アーキテクチャ

• 検討：Consistent Hashによるデータ分散

• キーのハッシュ関数でオブジェクトの格納先を決定する

• メタDBが不要でデータが均一にバランスされる

26

引用: http://docs.basho.com/riak/kv/2.2.3/learn/concepts/clusters/


Not Consistent Hash?

• リバランス転送なしでスケールアウトできる

• ノードが大きい場合、リバランス転送するデータ量が問題になる

• 例) 720TB * 10ノードの時、1ノード追加するには655TBの転送が必要

• 655TB/2Gbps = 30日

27

655TB

(720TB*10Node)/11Node = 655TB


Other Pros/Cons

• メリット

• メタDBとBLOBストレージが独立してスケールアウトできる

• ストレージエンジンがプラガブル

• 将来的にストレージエンジンの変更や追加が可能

• デメリット

• メタDBが別途必要

• ストレージの負荷に偏りが生じる

• 定期的な再配置である程度対応

28


Storage Node


Storage 構成

• コスト効率のため、高密度のストレージサーバーを使用

• 高密度に耐えられる工夫が必要

30

https://www.supermicro.com/products/system/4U/6048/SSG-6048R-E1CR90L.cfm


Storage 構成

• RAIDでなく、各HDDを独立した論理ボリュームとして構成

• 理由1. ディスク故障時の復旧所要時間を短縮

31

VolumeGroup

StorageNode

HDD4

HDD3

HDD2

HDD1

StorageNode

HDD4

HDD3

HDD2

HDD1

StorageNode

HDD4

HDD3

HDD2

HDD1


Storage 構成

• 理由2. RAIDはランダムアクセスが遅い

32

構成 Requests per sec

非RAID 178.9

RAID 0 73.4

RAID 5 68.6

Nginxを用いて4HDDでファイルを配信し、ランダムにアクセスした際のスループットファイルサイズ:500KB

2.4x Faster

than RAID 0


File Persistent Strategy

• Storage Nodeはファイルシステムを使い、一つのBLOBを一つのファイルに永続化

• 枯れたファイルシステム (ext4)を利用して堅牢性向上

• 一般的にファイルシステムは大量のファイルをうまく扱えない

• OpenStack Swiftはファイル数が増えると書き込み性能が落ちる (参考1,2)

• Dragonではこの問題をカバーするテクニックを利用

33

参考1: “OpenStack Swiftによる画像ストレージの運用” http://labs.gree.jp/blog/2014/12/11746/

参考2 “画像システムの車窓から｜サイバーエージェント公式エンジニアブログ” http://ameblo.jp/principia-ca/entry-12140148643.html


File Persistent Strategy

• 一般的な手法：事前に作成した一定数のディレクトリに均等にファイルを書き込む (例:swift)

• ファイル数が増えると書き込みにシーク数が増加し、書き込みスループットが低下する

• ディレクトリ内のファイルが増えることでディレクトリの更新コストが上がる

34

(256dirs)

... 256 dirs01 02 03 fe ff

256ディレクトリにランダムに300万ファイルを書き込んだ時のシーク数とスループット。簡易HTTPサーバによる実装。計測にab, blktrace, seekwatcherを使用

photo2.jpgphoto1.jpg photo4.jpgphoto3.jpg

Hash関数


Dynamic Partitioning

• Dynamic Partitioning 手法

1. 連番のディレクトリ (parition) を作成する。APIは末尾番号のディレクトリにアップロードする

2. ディレクトリ内のファイル数が1000に達したら、次のディレクトリを作成し、そこにアップロードを要求する

• 随時ディレクトリを増やすことで、ディレクトリ内のファイル数を一定に保つ

35

ディレクトリのファイル数が1000に達すると、Dragonは新規ディレクトリを作り、そこにアップロードを始める

0 1 0 New

Dir!

11000

Files!

2


Dynamic Partitioning

36

• 書き込みスループットをハッシュ手法と比較

• ファイルが増えてもシーク数が増えず、スループットが安定

青：256ディレクトリにランダムに300万ファイルを書き込んだ時のシーク数とスループット緑：Dynamic Partitionで300万ファイルを書き込んだ時のシーク数とスループット


Microbenchmark

1HDDに対して1000万ファイルまで書き込み性能の維持を確認

37

1000万ファイルを書き込んだ時のスループット。(10万ファイル書き込みごとの平均rpsを採用。毎試行前にdirty pageのドロップ処理あり)


Eventual Consistency• 高可用性のため、Storage Nodeへの書き込みはQuorumによる結果整合性

• Storage Node3台のうち過半数に書き込み成功すればアップロードは成功

• 書き込み失敗したノードへはAnti Entropy Repairで定期的に同期

38

VolumeGroup: 01

StorageNode

1

HDD4

HDD3

HDD2

HDD1

StorageNode

2

HDD4

HDD3

HDD2

HDD1

StorageNode

3

HDD4

HDD3

HDD2

HDD1

API Nodes

OK


Anti Entropy Repair• Anti Entropy Repair

• ノード間のデータを比較し、同期が完了していないデータを検出し、一貫性を回復する処理

39

Node B Node C

file1

file2

file3

file4

Node A

file1

file2

file3

file4

file1

file2

file4

file3


Anti Entropy Repair• ストレージノードのパーティション単位で差分を検知し、修正する

• パーティション配下のファイル名リストからハッシュを計算する

• そのハッシュをノード間で比較し、一致しなかったらノード間不一致あり

• 不一致なパーティションはファイル名リストを比較し、足りないファイルがあれば相手に転送します。

• ハッシュはキャッシュされ、最大パーティション以外は更新が少ないので高I/O効率

40

HDD2

01 60b725f...

02 e8191b3...

03 97880df...

HDD2

01 60b725f...

02 e8191b3...

03 97880df...

HDD2

01 60b725f...

02 e8191b3...

03 10c9c85c...

node1 node2 node3

file1001.data

-----

file1003.data

file1001.data

file1002.data

file1003.data

file1001.data

file1002.data

file1003.data

file1002.data をnode1に転送


MetaDB


Cassandra

• Apache Cassandra?

• 可用性

• リニアに性能がスケールする

• 運用コストの低さ

• Eventual Consistency

• トランザクションに頼らないスキーマ設計が必要

42


Cassandra

• Tables

• VolumeGroup

• Account

• Bucket

• Object

• ObjectIndex

43


Object Table

• Object Table• オブジェクトのメタ情報を保持するテーブル

• サイズ、BLOB格納位置、ACL、Content-Typeなど

• (バケット名+キー名)のパーティションキーでCassandraクラスタに均一に分散

44

bucket key mtime status metadata...

b1 photo1.jpg uuid(t2) ACTIVE {size, location, acl...,}

b1 photo2.jpg uuid(t1) ACTIVE {size, location, acl....}


パーティションキー


PUT Object

• メタ情報更新

• 各パーティション内部では、メタデータが作成時刻のUUIDで降順にクラスタリングされる

• オブジェクトが上書きされると、パーティションの先頭に最新バージョンのメタデータが追加される

• 複数バージョンを保持するので、同時に更新されても矛盾が起きない

45

クラスタリングカラム


b1 photo2.jpg

uuid(t5) ACTIVE {size, location, acl...,}




PUT b1/photo2.jpg (時刻:t4)

PUT b1/photo2.jpg (時刻:t5)

t5の写真が最新バージョンとして整合性が取れる


GET Object

• メタデータ取得

• パーティションの先頭1行をSELECTクエリで取得

• 作成時刻でソートされているので、先頭1行は常にそのオブジェクトの現在の状態

46


b1 photo1.jpguuid(t5) ACTIVE {size, location, acl...}

uuid(t3) ACTIVE {size, location, acl....}


分散キークラスタリングカラム

SELECT * FROM bucket=‘b1’ AND key= ‘photo1.jpg’ LIMIT 1;

(時刻:t5)


DELETE Object

• オブジェクト削除要求

• 行を削除せず削除ステータスが有効な行をパーティション先頭に挿入

47




b1 photo2.jpguuid(t7) DELETED N/A



DELETE b1/photo1.jpg (時刻:t7)


GET Object (deleted)

• メタ情報取得（削除の場合）

• 取得した先頭行が削除ステータスの場合は、オブジェクトは論理的に削除済みとみなし、エラー

48




b1 photo2.jpguuid(t7) DELETED N/A



SELECT * FROM bucket=‘b1’ AND key= ‘photo2.jpg’ LIMIT 1;

(時刻:t7)


Object Garbage Collection

• Garbage Collection (GC)• 上書きや削除されたデータが残ってしまうので、定期的にメタとBLOBを削除する

• Objectテーブルをフルスキャン

• 各パーティションの2行目以降をゴミと判断、BLOBとメタ情報を削除

49




b1 photo2.jpg

uuid(t7) DELETED N/A




Garbage

Garbage

Garbage

フルテーブルスキャン

BLOBの削除は、ストレージに0バイトのtombstoneファイルをPUT (Swiftと同様)


Object Garbage Collection

• GC完了の状態

50


b1 photo1.jpg uuid(t5) ACTIVE {size, location, acl...}

b1 photo2.jpg uuid(t7) DELETED N/A


GC 完了

分散キーとUUIDによるクラスタリングを組み合わせることで、結果整合性DB上で同時実行制御を実現


Issues and Future Works


ObjectIndex Table• ObjectIndexテーブル

• オブジェクト一覧APIのためにバケット内のオブジェクトがキー名で昇順ソートされたテーブル

• パーティションが非常に大きくなるので、各バケットにつきハッシュで16パーティションに分割

52

bucket hash key metadata

bucket1 0

key0001 ...

key0003 ...

key0012 ...

key0024 ...

... ...

bucket1 1

key0004 ...

key0009 ...

key0011 ...

... ...

bucket1 2

key0002 ...

key0005 ...

... ...

... ... ... ...

key metadata

key0001 ...

key0002 ...

key0003 ...

key0004 ...

key0005 ...

key0006 ...

key0007 ...

key0008 ...

... ...

複数のパーティションをSELECTしてマージ

ObjectIndex Table



Issues

• ObjectIndex関連の問題

• APIクエリによってはリストの作成のために多くのクエリが必要で高負荷、高レイテンシ

• パーティションサイズ制約から、バケットあたりのオブジェクト数が320億に制限

• Indexを動的に水平分割する機構を導入し、オブジェクト数の制約を撤廃したい

53


Future Works

• ストレージエンジンの改善

• 高速な追記ファイル型ストレージの開発

• 高効率なErasure Coding対応

• サーバーレスアーキテクチャ提供

• Kafka / PulsarなどMessaging Queueへのイベント通知

• 分散システムとのインテグレーション

• Hadoop, Spark, Presto, etc...

54


まとめ

• ヤフーは大規模分散オブジェクトストレージ “Dragon” を開発・運用しています

• Dragonは運用しやすく、ハイスケーラブルなストレージ基盤です

• 新しいニーズに対応するため、今後も研究・開発を続けていきます

Dragon: A Distributed Object Storage at Yahoo! JAPAN (WebDB Forum 2017)

Technology

Transcript of Dragon: A Distributed Object Storage at Yahoo! JAPAN (WebDB Forum 2017)