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

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

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

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 じゃあフルスクラッチで作ろう → 開発スタート

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

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万ファイルを書き込んだ時のシーク数とスループット

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に転送

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上で同時実行制御を実現

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

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

Yahoo! JAPAN デベロッパーネットワーク

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