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

Dragon: A Distributed Object Storage @Yahoo! JAPAN 2017/9/19 WebDB Forum 2017 後藤泰陽 1 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

About me 2 • 後藤泰陽 / Yasuharu Goto • ヤフー株式会社 (2008年-) • ソフトウェアエンジニア • 主な分野：ストレージ、分散DB • Twitter: @ono_matope • 好きな言語: Go Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Agenda 3 • Dragonについて • Dragonのアーキテクチャ • Dragonの課題と今後 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Dragon Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

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

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

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

S3 Compatible API • S3互換APIを提供 • 8 aws-sdk, aws-cli, CyberDuck... • 実装済み • S3の基本的なAPI (Service, Bucket, Object, ACL...) • SSE (サーバサイド暗号化) • 実装中 • Multipart Upload API (最大5TBのオブジェクトのアップロード) • 今後もAPIを追加予定 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Performance (with Riak CS/参考値) GET Object 10KB Throughput PUT Object 10KB Throughput 3500 1000 900 800 2500 2000 Riak CS 1500 Dragon 1000 Requests / sec Requests / sec 3000 700 600 500 Dragon 300 200 500 100 0 0 1 9 Riak CS 400 5 10 50 100 # of Threads 200 400 1 • Dragon: API*1, Storage*3, Cassandra*3 • Riak CS: haproxy*1, stanchion*1, Riak (KV+CS)*3 • CassandraとStanchion以外は同一構成のHWを使用。 Co p yrig ht © 2 0 1 7 5 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved . 10 50 100 # of Threads 200 400

開発の経緯 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

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

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

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

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

Architecture Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Architecture Overview • Dragonは API Nodes, Storage Nodes, MetaDB の3コンポーネントで構成される • API Node • • Storage Node • • • アップロードされたオブジェクトのBLOBをストアするHTTPファイルサーバ 3ノードで VolumeGroupを構成し、グループ内のBLOBは定期的に同期される MetaDB (Apache Cassandra cluster) • 16 S3互換のHTTP APIを提供し、全てのユーザーリクエストを受け付ける BLOBの位置情報を含むアップロードされたオブジェクトのメタデータを保存する Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Architecture HTTP (S3 API) API Nodes Meta DB Metadata Storage Cluster BLOB VolumeGroup: 01 17 VolumeGroup: 02 StorageNode 1 StorageNode 2 StorageNode 3 StorageNode 4 StorageNode 5 StorageNode 6 HDD1 HDD1 HDD1 HDD1 HDD1 HDD1 HDD2 HDD2 HDD2 HDD2 HDD2 HDD2 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Architecture API NodeとStorage NodeはGo言語による実装 HTTP (S3 API) API Nodes Meta DB Metadata Storage Cluster BLOB VolumeGroup: 01 18 VolumeGroup: 02 StorageNode 1 StorageNode 2 StorageNode 3 StorageNode 4 StorageNode 5 StorageNode 6 HDD1 HDD1 HDD1 HDD1 HDD1 HDD1 HDD2 HDD2 HDD2 HDD2 HDD2 HDD2 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Architecture API NodeはMetaDBから定期的にVolumeGroupの構成情報を取得してキャッシュ volumegroup 構成 API Nodes id hosts Volumes 01 node1,node2,node3 HDD1, HDD2 02 node4,node5,node6 HDD1, HDD2 Meta DB Storage Cluster BLOB VolumeGroup: 01 19 VolumeGroup: 02 StorageNode 1 StorageNode 2 StorageNode 3 StorageNode 4 StorageNode 5 StorageNode 6 HDD3 HDD3 HDD3 HDD3 HDD3 HDD3 HDD4 HDD4 HDD4 HDD4 HDD4 HDD4 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Upload 1. 2. ユーザーがアップロードを要求すると、APIはランダムに格納先VolumeGroupとHDDを決定し、BLOBをHTTP PUTで3 ノードに並列アップロードする アップロードに成功したら、BLOB位置情報を含むメタデータをMetaDBに書き込む PUT bucket1/sample.jpg key: bucket1/sample.jpg, size: 1024bytes blob: volumegroup01/hdd1/..., API Nodes ② メタデータ Meta DB ① HTTP PUT VolumeGroup: 01 20 VolumeGroup: 02 StorageNode 1 StorageNode 2 StorageNode 3 StorageNode 4 StorageNode 5 StorageNode 6 HDD1 HDD1 HDD1 HDD1 HDD1 HDD1 HDD2 HDD2 HDD2 HDD2 HDD2 HDD2 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Download 1. 2. ダウンロード時、APIはまずMetaDBからオブジェクトのメタデータを取得 メタデータをもとにBLOBを保持するStorageにHTTP GETをリクエストし、ユーザにレスンポンスする PUT bucket1/sample.jpg key: bucket1/sample.jpg, size: 1024bytes blob: volumegroup01/hdd1/..., API Nodes ① メタデータ Meta DB ② HTTP GET VolumeGroup: 01 21 VolumeGroup: 02 StorageNode 1 StorageNode 2 StorageNode 3 StorageNode 4 StorageNode 5 StorageNode 6 HDD1 HDD1 HDD1 HDD1 HDD1 HDD1 HDD2 HDD2 HDD2 HDD2 HDD2 HDD2 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Failure Recovery VolumeGroupを構成するノードのHDDが障害を起こした場合… API Nodes Meta DB VolumeGroup: 01 22 VolumeGroup: 02 StorageNode 1 StorageNode 2 StorageNode 3 StorageNode 4 StorageNode 5 StorageNode 6 HDD1 HDD1 HDD1 HDD1 HDD1 HDD1 HDD2 HDD2 HDD2 HDD2 HDD2 HDD2 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Failure Recovery HDD交換後に、同一グループの他のノードのHDDからデータを転送し、復旧します API Nodes Meta DB VolumeGroup: 01 23 VolumeGroup: 02 StorageNode 1 StorageNode 2 StorageNode 3 StorageNode 4 StorageNode 5 StorageNode 6 HDD1 HDD1 HDD1 HDD1 HDD1 HDD1 HDD2 HDD2 HDD2 HDD2 HDD2 HDD2 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Scaling out ストレージのキャパシティをクラスタに追加する場合は… volumegroup 構成 id hosts Volumes 01 node1,node2,node3 HDD1, HDD2 02 node4,node5,node6 HDD1, HDD2 API Nodes Meta DB VolumeGroup: 01 VolumeGroup: 02 StorageNode 1 StorageNode 2 StorageNode 3 StorageNode 4 StorageNode 5 StorageNode 6 HDD1 HDD1 HDD1 HDD1 HDD1 HDD1 HDD2 HDD2 HDD2 HDD2 HDD2 HDD2 24 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Scaling out 新しいStorage NodeでVolumeGroupを構成し、MetaDBに登録するだけでキャパシティを追加可能 volumegroup 構成 API Nodes id hosts Volumes 01 node1,node2,node3 HDD1, HDD2 02 node4,node5,node6 HDD1, HDD2 03 node7,node8,node9 HDD1, HDD2 Meta DB VolumeGroup: 01 VolumeGroup: 02 VolumeGroup: 03 StorageNode 1 StorageNode 2 StorageNode 3 StorageNode 4 StorageNode 5 StorageNode 6 StorageNode 7 StorageNode 8 StorageNode 9 HDD1 HDD1 HDD1 HDD1 HDD1 HDD1 HDD1 HDD1 HDD1 HDD2 HDD2 HDD2 HDD2 HDD2 HDD2 HDD2 HDD2 HDD2 25 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

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

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

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

Storage Node Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Storage 構成 • コスト効率のため、高密度のストレージサーバーを使用 • 高密度に耐えられる工夫が必要 https://www.supermicro.com/products/system/4U/6048/SSG-6048R-E1CR90L.cfm 30 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

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

Storage 構成 • RAIDでなく、各HDDを独立した論理ボリュームとして構成 • 理由1. ディスク故障時の復旧所要時間を短縮 VolumeGroup 31 StorageNode StorageNode StorageNode HDD1 HDD1 HDD1 HDD2 HDD2 HDD2 HDD3 HDD3 HDD3 HDD4 HDD4 HDD4 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Storage 構成 • 理由2. RAIDはランダムアクセスが遅い 構成 Requests per sec 非RAID 178.9 RAID 0 73.4 RAID 5 68.6 Nginxを用いて4HDDでファイルを配信し、ランダムにアクセスした際のスループット ファイルサイズ:500KB 32 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved . 2.4x Faster than RAID 0

File Persistent Strategy • Storage Nodeはファイルシステムを使い、一つのBLOBを一つのファイルに永続化 • 枯れたファイルシステム (ext4)を利用して堅牢性向上 • 一般的にファイルシステムは大量のファイルをうまく扱えない • • OpenStack Swiftはファイル数が増えると書き込み性能が落ちる (参考1,2) Dragonではこの問題をカバーするテクニックを利用 参考1: “OpenStack Swiftによる画像ストレージの運用” http://labs.gree.jp/blog/2014/12/11746/ 参考2 “画像システムの車窓から｜サイバーエージェント 公式エンジニアブログ” http://ameblo.jp/principia-ca/entry-12140148643.html 33 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

File Persistent Strategy • 一般的な手法：事前に作成した一定数のディレクトリに均等にファイルを書き込む (例:swift) • • ファイル数が増えると書き込みにシーク数が増加し、書き込みスループットが低下する ディレクトリ内のファイルが増えることでディレクトリの更新コストが上がる photo1.jpg photo2.jpg photo3.jpg photo4.jpg Hash関数 01 02 03 ... fe ff 256 dirs (256dirs) 256ディレクトリにランダムに300万ファイルを書き込んだ時のシーク数とスループット。 簡易HTTPサーバによる実装。計測にab, blktrace, seekwatcherを使用 34 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

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

Dynamic Partitioning • 書き込みスループットをハッシュ手法と比較 • ファイルが増えてもシーク数が増えず、スループットが安定 青：256ディレクトリにランダムに300万ファイルを書き込んだ時のシーク数とスループット 緑：Dynamic Partitionで300万ファイルを書き込んだ時のシーク数とスループット 36 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Microbenchmark 1HDDに対して1000万ファイルまで書き 込み性能の維持を確認 1000万ファイルを書き込んだ時のスループット。 (10万ファイル書き込みごとの平均rpsを採用。毎試行前にdirty pageのドロップ処理あり) 37 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Eventual Consistency • 高可用性のため、Storage Nodeへの書き込みはQuorumによる結果整合性 • Storage Node3台のうち過半数に書き込み成功すればアップロードは成功 • 書き込み失敗したノードへはAnti Entropy Repairで定期的に同期 API Nodes OK VolumeGroup: 01 38 StorageNode 1 StorageNode 2 StorageNode 3 HDD1 HDD1 HDD1 HDD2 HDD2 HDD2 HDD3 HDD3 HDD3 HDD4 HDD4 HDD4 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Anti Entropy Repair • Anti Entropy Repair • ノード間のデータを比較し、同期が完了していないデータを検出し、一貫性を回復する処理 Node A file1 file2 file3 file4 file1 file2 file4 Node B Node C file3 39 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved . file1 file2 file3 file4

Anti Entropy Repair • • ストレージノードのパーティション単位で差分を検知し、修正する • パーティション配下のファイル名リストからハッシュを計算する • そのハッシュをノード間で比較し、一致しなかったらノード間不一致あり • 不一致なパーティションはファイル名リストを比較し、足りないファイルがあれば相手に転送します。 ハッシュはキャッシュされ、最大パーティション以外は更新が少ないので高I/O効率 node1 node2 node3 HDD2 HDD2 HDD2 01 60b725f... 01 60b725f... 01 60b725f... 02 e8191b3... 02 e8191b3... 02 e8191b3... 03 97880df... 03 97880df... 03 10c9c85c... file1001.data file1002.data file1003.data file1001.data file1002.data file1003.data file1001.data ----file1003.data file1002.data をnode1に転送 40 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

MetaDB Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Cassandra • Apache Cassandra? • • • • Eventual Consistency • 42 可用性 リニアに性能がスケールする 運用コストの低さ トランザクションに頼らないスキーマ設計が必要 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Cassandra • Tables • • • • • 43 VolumeGroup Account Bucket Object ObjectIndex Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Object Table • Object Table • オブジェクトのメタ情報を保持するテーブル • • サイズ、BLOB格納位置、ACL、Content-Typeなど (バケット名+キー名)のパーティションキーでCassandraクラスタに均一に分散 パーティションキー 44 Co p yrig ht © 2 0 1 7 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....} Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

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

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

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

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

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

Object Garbage Collection • GC完了の状態 分散キー クラスタリングカラム 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上で同時実行制御を実現 50 Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

Issues and Future Works Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

ObjectIndex Table • ObjectIndexテーブル • オブジェクト一覧APIのためにバケット内のオブジェクトがキー名で昇順ソートされたテーブル • パーティションが非常に大きくなるので、各バケットにつきハッシュで16パーティションに分割 クラスタリングカラム 分散キー bucket 複数のパーティションをSELECTしてマージ key metadata key0001 ... key0003 ... key0012 ... key metadata key0001 ... key0002 ... key0024 ... key0003 ... ... ... key0004 ... key0004 ... key0005 ... key0009 ... key0006 ... key0011 ... key0007 ... ... ... key0008 ... key0002 ... key0005 ... ... ... ... ... ... ... bucket1 bucket1 bucket1 ... 52 hash 0 1 2 ... ObjectIndex Table Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

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

Future Works • ストレージエンジンの改善 • • • サーバーレスアーキテクチャ提供 • • Kafka / PulsarなどMessaging Queueへのイベント通知 分散システムとのインテグレーション • 54 高速な追記ファイル型ストレージの開発 高効率なErasure Coding対応 Hadoop, Spark, Presto, etc... Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .

まとめ • ヤフーは大規模分散オブジェクトストレージ “Dragon” を開発・運用しています • Dragonは運用しやすく、ハイスケーラブルなストレージ基盤です • 新しいニーズに対応するため、今後も研究・開発を続けていきます Co p yrig ht © 2 0 1 7 Yaho o Jap an Co rp o ratio n. All Rig hts Reserved .