WebDB Forum 2017で発表した、Yahoo! JAPAN内製の分散オブジェクトストレージ Dragon のアーキテクチャについての資料です。

1. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
2017/9/19 WebDB Forum 2017
1
後藤泰陽
Dragon: A Distributed Object Storage @Yahoo! JAPAN

2. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
About me
• 後藤泰陽 / Yasuharu Goto
• ヤフー株式会社 (2008年-)
• ソフトウェアエンジニア
• 主な分野：ストレージ、分散DB
• Twitter: @ono_matope
• 好きな言語: Go
2

3. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Agenda
• Dragonについて
• Dragonのアーキテクチャ
• Dragonの課題と今後
3

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

5. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Object Storage
• Object Storageとは？
• データをファイルではなくオブジェクトとして管理する種類のストレージ
• ディレクトリ操作やロックなどの機能がないかわりに可用性とスケーラビリティが高い
• (一般的に)REST APIが提供され、アプリケーションから使いやすい
• 主なサービス
• AWS: Amazon S3
• GCP: Google Cloud Storage
• Azure: Azure Blob Storage
• モダンなサービス開発には不可欠
5

6. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Dragon
• Yahoo! JAPAN で独自に開発している社内向け分散オブジェクトストレージ
• 目標：高パフォーマンス、高スケーラビリティ、高可用性、高コスト効率
• Written in Go
• 2016年1月リリース (1年8ヶ月の本番稼働実績)
• 規模
• 国内2DCで稼働中
• 合計オブジェクト数：200億オブジェクト
• 合計データ量：11ペタバイト
6

7. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Use Cases
• ヤフー社内で250以上の利用
• 幅広い用途
• 画像・動画コンテンツ
• 各種データ、ログ
• Presto バックエンド(検証中)
7
• Yahoo!オークション (画像)
• Yahoo!ニュース・トピックス/個人 (画像)
• Yahoo!ディスプレイアドネットワーク (画像/動画)
• Yahoo!ブログ (画像)
• Yahoo!スマホきせかえ (画像)
• Yahoo!トラベル (画像)
• Yahoo!不動産 (画像)
• Yahoo!知恵袋 (画像)
• Yahoo!飲食店予約 (画像)
• Yahoo!みんなの政治 (画像)
• Yahoo!ゲーム (コンテンツ)
• Yahoo!ブックストア (コンテンツ)
• Yahoo!ボックス (データ)
• ネタりか (記事画像)
• etc...

8. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
S3 Compatible API
• S3互換APIを提供
• aws-sdk, aws-cli, CyberDuck...
• 実装済み
• S3の基本的なAPI (Service, Bucket, Object, ACL...)
• SSE (サーバサイド暗号化)
• 実装中
• Multipart Upload API (最大5TBのオブジェクトのアップロード)
• 今後もAPIを追加予定
8

9. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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
Requests/sec
# 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
Requests/sec
# of Threads
PUT Object 10KB Throughput
Riak CS
Dragon

10. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
開発の経緯

11. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Why we built a new Object Storage?
• Octagon (2011-2017)
• 最初の内製オブジェクトストレージ
• Yahoo!ボックス, 電子書籍, その他画像配信, etc...
• 最大7PB, 70億オブジェクト, 3000ノード
• 諸々の技術的課題から、全社基盤ストレージの地位を確立できず
• 「遅くて採用できない」
• 「不安定、よく止まる」
• 「コストが高い」
• 「運用がつらい」
• 代替を検討
11

12. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Requirements
• 要件
• サービスが求める以上の高パフォーマンス
• 急激なデータ需要増に対応できる高スケーラビリティ
• 少人数で簡単に運用でき、高い可用性
• 高いコスト効率
• ミッション
• 使ってもらえる全社ストレージ基盤の確立
12

13. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Alternatives
• 既存のオープンソース製品
• Riak CS: 一部サービスで導入するも、性能がサービス要件を満たさず
• OpenStack Swift: オブジェクト増加時の書き込み性能低下が懸念
• パブリッククラウド
• コスト面で不利
• ヤフーは自社DCでのサービス運用。
データローカリティ的にも、自社DCでスケールするストレージが必要
13

14. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Alternatives
• 既存のオープンソース製品
• Riak CS: 一部サービスで導入するも、性能がサービス要件を満たさず
• OpenStack Swift: オブジェクト増加時の書き込み性能低下が懸念
• パブリッククラウド
• コスト面で不利
• ヤフーは自社DCでのサービス運用。
データローカリティ的にも、自社DCでスケールするストレージが必要
14
じゃあフルスクラッチで作ろう
→ 開発スタート

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

16. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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

17. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Architecture
17
API Nodes
HTTP (S3 API)
BLOB
Metadata
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

18. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Architecture
18
API Nodes
HTTP (S3 API)
BLOB
Metadata
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

19. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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
02 node4,node5,node6 HDD1, HDD2
volumegroup 構成

20. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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
② メタデータ

21. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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をリクエストし、ユーザにレスンポンスする

22. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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が障害を起こした場合…

23. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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

24. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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
01 node1,node2,node3 HDD1, HDD2
02 node4,node5,node6 HDD1, HDD2
volumegroup 構成

25. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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
01 node1,node2,node3 HDD1, HDD2
02 node4,node5,node6 HDD1, HDD2
03 node7,node8,node9 HDD1, HDD2
volumegroup 構成

26. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Not Consistent Hash?
• DragonはメタDBによるマップ型の分散アーキテクチャ
• 検討：Consistent Hashによるデータ分散
• キーのハッシュ関数でオブジェクトの格納先を決定する
• メタDBが不要でデータが均一にバランスされる
26
引用: http://docs.basho.com/riak/kv/2.2.3/learn/concepts/clusters/

27. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Not Consistent Hash?
• リバランス転送なしでスケールアウトできる
• ノードが大きい場合、リバランス転送するデータ量が問題になる
• 例) 720TB * 10ノードの時、1ノード追加するには655TBの転送が必要
• 655TB/2Gbps = 30日
27
655TB
(720TB*10Node)/11Node = 655TB

28. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Other Pros/Cons
• メリット
• メタDBとBLOBストレージが独立してスケールアウトできる
• ストレージエンジンがプラガブル
• 将来的にストレージエンジンの変更や追加が可能
• デメリット
• メタDBが別途必要
• ストレージの負荷に偏りが生じる
• 定期的な再配置である程度対応
28

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

30. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Storage 構成
• コスト効率のため、高密度のストレージサーバーを使用
• 高密度に耐えられる工夫が必要
30
https://www.supermicro.com/products/system/4U/6048/SSG-6048R-E1CR90L.cfm

31. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Storage 構成
• RAIDでなく、各HDDを独立した論理ボリュームとして構成
• 理由1. ディスク故障時の復旧所要時間を短縮
31
VolumeGroup
StorageNode
HDD4
HDD3
HDD2
HDD1
StorageNode
HDD4
HDD3
HDD2
HDD1
StorageNode
HDD4
HDD3
HDD2
HDD1

32. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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

33. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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

34. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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関数

35. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Dynamic Partitioning
• Dynamic Partitioning 手法
1. 連番のディレクトリ (parition) を作成する。APIは末尾番号のディレクトリにアップロードする
2. ディレクトリ内のファイル数が1000に達したら、次のディレクトリを作成し、そこにアップロードを要求する
• 随時ディレクトリを増やすことで、ディレクトリ内のファイル数を一定に保つ
35
ディレクトリのファイル数が1000に達すると、Dragonは新規ディレクトリを作り、そこにアップロードを始める
0 1 0 New
Dir!
1
1000
Files!
2

36. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Dynamic Partitioning
36
• 書き込みスループットをハッシュ手法と比較
• ファイルが増えてもシーク数が増えず、スループットが安定
青：256ディレクトリにランダムに300万ファイルを書き込んだ時のシーク数とスループット
緑：Dynamic Partitionで300万ファイルを書き込んだ時のシーク数とスループット

37. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Microbenchmark
1HDDに対して1000万ファイルまで書き
込み性能の維持を確認
37
1000万ファイルを書き込んだ時のスループット。
(10万ファイル書き込みごとの平均rpsを採用。毎試行前にdirty pageのドロップ処理あり)

38. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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

39. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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

40. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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に転送

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

42. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Cassandra
• Apache Cassandra?
• 可用性
• リニアに性能がスケールする
• 運用コストの低さ
• Eventual Consistency
• トランザクションに頼らないスキーマ設計が必要
42

43. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Cassandra
• Tables
• VolumeGroup
• Account
• Bucket
• Object
• ObjectIndex
43

44. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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....}
b3 photo1.jpg uuid(t3) ACTIVE {size, location, acl....}
パーティションキー

45. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
PUT Object
• メタ情報更新
• 各パーティション内部では、メタデータが作成時刻のUUIDで降順にクラスタリングされる
• オブジェクトが上書きされると、パーティションの先頭に最新バージョンのメタデータが追加される
• 複数バージョンを保持するので、同時に更新されても矛盾が起きない
45
クラスタリングカラム
bucket key mtime status metadata...
b1 photo2.jpg
uuid(t5) ACTIVE {size, location, acl...,}
uuid(t4) ACTIVE {size, location, acl...,}
uuid(t1) ACTIVE {size, location, acl...,}
b1 photo2.jpg uuid(t1) ACTIVE {size, location, acl....}
PUT b1/photo2.jpg (時刻:t4)
PUT b1/photo2.jpg (時刻:t5)
t5の写真が最新バージョンとして整合性が取れる

46. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
GET Object
• メタデータ取得
• パーティションの先頭1行をSELECTクエリで取得
• 作成時刻でソートされているので、先頭1行は常にそのオブジェクトの現在の状態
46
bucket key mtime status metadata...
b1 photo1.jpg
uuid(t5) ACTIVE {size, location, acl...}
uuid(t3) ACTIVE {size, location, acl....}
b1 photo2.jpg uuid(t1) ACTIVE {size, location, acl....}
分散キー クラスタリングカラム
SELECT * FROM bucket=‘b1’ AND key= ‘photo1.jpg’ LIMIT 1;
(時刻:t5)

47. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
DELETE Object
• オブジェクト削除要求
• 行を削除せず削除ステータスが有効な行をパーティション先頭に挿入
47
bucket key mtime status metadata...
b1 photo1.jpg
uuid(t5) ACTIVE {size, location, acl...}
uuid(t3) ACTIVE {size, location, acl....}
b1 photo2.jpg
uuid(t7) DELETED N/A
uuid(t1) ACTIVE {size, location, acl....}
分散キー クラスタリングカラム
DELETE b1/photo1.jpg (時刻:t7)

48. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
GET Object (deleted)
• メタ情報取得（削除の場合）
• 取得した先頭行が削除ステータスの場合は、オブジェクトは論理的に削除済みとみなし、
エラー
48
bucket key mtime status metadata...
b1 photo1.jpg
uuid(t5) ACTIVE {size, location, acl...}
uuid(t3) ACTIVE {size, location, acl....}
b1 photo2.jpg
uuid(t7) DELETED N/A
uuid(t1) ACTIVE {size, location, acl....}
分散キー クラスタリングカラム
SELECT * FROM bucket=‘b1’ AND key= ‘photo2.jpg’ LIMIT 1;
(時刻:t7)

49. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Object Garbage Collection
• Garbage Collection (GC)
• 上書きや削除されたデータが残ってしまうので、定期的にメタとBLOBを削除する
• Objectテーブルをフルスキャン
• 各パーティションの2行目以降をゴミと判断、BLOBとメタ情報を削除
49
bucket key mtime status metadata...
b1 photo1.jpg
uuid(t5) ACTIVE {size, location, acl...}
uuid(t3) ACTIVE {size, location, acl....}
b1 photo2.jpg
uuid(t7) DELETED N/A
uuid(t3) ACTIVE {size, location, acl...,}
uuid(t1) ACTIVE {size, location, acl....}
分散キー クラスタリングカラム
Garbage
Garbage
Garbage
フルテーブルスキャン
BLOBの削除は、ストレージに0バイトのtombstoneファイルをPUT (Swiftと同様)

50. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Object Garbage Collection
• GC完了の状態
50
bucket key mtime status metadata...
b1 photo1.jpg uuid(t5) ACTIVE {size, location, acl...}
b1 photo2.jpg uuid(t7) DELETED N/A
分散キー クラスタリングカラム
GC 完了
分散キーとUUIDによるクラスタリングを組み合わせることで、結果整合性DB上で同時実行制御を実現

51. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Issues and Future Works

52. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
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
分散キー クラスタリングカラム

53. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Issues
• ObjectIndex関連の問題
• APIクエリによってはリストの作成のために多くのクエリが必要で高負荷、高レイテンシ
• パーティションサイズ制約から、バケットあたりのオブジェクト数が320億に制限
• Indexを動的に水平分割する機構を導入し、オブジェクト数の制約を撤廃したい
53

54. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
Future Works
• ストレージエンジンの改善
• 高速な追記ファイル型ストレージの開発
• 高効率なErasure Coding対応
• サーバーレスアーキテクチャ提供
• Kafka / PulsarなどMessaging Queueへのイベント通知
• 分散システムとのインテグレーション
• Hadoop, Spark, Presto, etc...
54

55. Copyrig ht © 2017 Yahoo Japan Corporation. All Rig hts Reserved.
まとめ
• ヤフーは大規模分散オブジェクトストレージ “Dragon” を開発・運用しています
• Dragonは運用しやすく、ハイスケーラブルなストレージ基盤です
• 新しいニーズに対応するため、今後も研究・開発を続けていきます