Home
Explore
Submit Search
Upload
Login
Signup
Advertisement
Check these out next
Spring Cloud Data Flow の紹介 #streamctjp
Yahoo!デベロッパーネットワーク
Yahoo! JAPANのOracle構成-2017年版
Yahoo!デベロッパーネットワーク
プランニングツールにおけるインタラクティブな可視化を支えるバックエンド
Yahoo!デベロッパーネットワーク
Apache Big Data Miami 2017 - Hadoop Source Code Reading #23 #hadoopreading
Yahoo!デベロッパーネットワーク
Yahoo!プロモーション広告のビックデータ基盤を支える技術と今後の展望
Yahoo!デベロッパーネットワーク
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
広告における機械学習の適用例とシステムについて
Yahoo!デベロッパーネットワーク
Yahoo! JAPANのOSS Cassandra貢献の今までとこれから
Yahoo!デベロッパーネットワーク
1
of
55
Top clipped slide
Dragon: A Distributed Object Storage at Yahoo! JAPAN (WebDB Forum 2017)
Oct. 11, 2017
•
0 likes
1 likes
×
Be the first to like this
Show More
•
21,850 views
views
×
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download Now
Download to read offline
Report
Technology
WebDB Forum 2017で発表した、Yahoo! JAPAN内製の分散オブジェクトストレージ Dragon のアーキテクチャについての資料です。
Yahoo!デベロッパーネットワーク
Follow
Public Relations
Advertisement
Advertisement
Advertisement
Recommended
ヤフーのロギングSDKの挑戦〜データドリブン企業を目指して〜 #yjdsnight
Yahoo!デベロッパーネットワーク
1.9K views
•
48 slides
Design pattern in presto source code
Yahoo!デベロッパーネットワーク
1.6K views
•
51 slides
Dataworks Summit 2017 SanJose StreamProcessing - Hadoop Source Code Reading #...
Yahoo!デベロッパーネットワーク
705 views
•
34 slides
Yahoo! JAPANのサービス開発を10倍早くした社内PaaS構築の今とこれから
Yahoo!デベロッパーネットワーク
11.4K views
•
104 slides
Dataworks Summit SJ QueryEngine - Hadoop Source Code Reading #23 #hadoopreading
Yahoo!デベロッパーネットワーク
588 views
•
17 slides
僕とヤフーと時々Teradata #prestodb
Yahoo!デベロッパーネットワーク
2.3K views
•
47 slides
More Related Content
Slideshows for you
(20)
Spring Cloud Data Flow の紹介 #streamctjp
Yahoo!デベロッパーネットワーク
•
3.2K views
Yahoo! JAPANのOracle構成-2017年版
Yahoo!デベロッパーネットワーク
•
2.4K views
プランニングツールにおけるインタラクティブな可視化を支えるバックエンド
Yahoo!デベロッパーネットワーク
•
695 views
Apache Big Data Miami 2017 - Hadoop Source Code Reading #23 #hadoopreading
Yahoo!デベロッパーネットワーク
•
602 views
Yahoo!プロモーション広告のビックデータ基盤を支える技術と今後の展望
Yahoo!デベロッパーネットワーク
•
1.5K views
実運用して分かったRabbit MQの良いところ・気をつけること #jjug
Yahoo!デベロッパーネットワーク
•
23.5K views
広告における機械学習の適用例とシステムについて
Yahoo!デベロッパーネットワーク
•
2.5K views
Yahoo! JAPANのOSS Cassandra貢献の今までとこれから
Yahoo!デベロッパーネットワーク
•
2K views
Presto in Yahoo! JAPAN #yjdsnight
Yahoo!デベロッパーネットワーク
•
1.5K views
Storm の新機能について @HSCR #hadoopreading
Yahoo!デベロッパーネットワーク
•
836 views
AMPと広告とOpenRTBと #yjmu
Yahoo!デベロッパーネットワーク
•
1.5K views
データテクノロジースペシャル:Yahoo! JAPANにおけるメタデータ管理の試み
Yahoo!デベロッパーネットワーク
•
7.7K views
Kafka Summit NYCに見るストリーミングデータETLの話 #streamdatajp
Yahoo!デベロッパーネットワーク
•
3.6K views
大規模運用で見えるWebプロトコルの理想と現実、そして今後 #html5j #html5j_b
Yahoo!デベロッパーネットワーク
•
9K views
JSUG 2018/02/05 SpringOnePlatform2017参加報告 プラットフォーム関連のお話
Yahoo!デベロッパーネットワーク
•
766 views
データの見える化で進めるデータドリブンカンパニー #devsumiC
Yahoo!デベロッパーネットワーク
•
2.4K views
Spring Cloud Data Flow で構成される IIJ IoTサービス
Kenji Kondo
•
1.9K views
Apache NiFi の紹介 #streamctjp
Yahoo!デベロッパーネットワーク
•
3.2K views
Java Clientで入門する Apache Kafka #jjug_ccc #ccc_e2
Yahoo!デベロッパーネットワーク
•
8.3K views
Automation of Rolling Upgrade of Hadoop Cluster without Data Lost and Job Fai...
Yahoo!デベロッパーネットワーク
•
1.5K views
Viewers also liked
(20)
Dragon: A Distributed Object Storage at Yahoo! JAPAN (WebDB Forum 2017 / E...
Yahoo!デベロッパーネットワーク
•
21.7K views
深層学習と確率プログラミングを融合したEdwardについて
ryosuke-kojima
•
7.1K views
20171024NL研報告スライド
Masatoshi TSUCHIYA
•
1K views
[DL輪読会]Learning by Association - A versatile semi-supervised training method ...
Deep Learning JP
•
2.3K views
PoisoningAttackSVM (ICMLreading2012)
Hidekazu Oiwa
•
4K views
深層学習の判断根拠を理解するための 研究とその意義 @PRMU 2017熊本
Takahiro Kubo
•
14.8K views
[DLHacks LT] PytorchのDataLoader -torchtextのソースコードを読んでみた-
Deep Learning JP
•
35.9K views
もしその単語がなかったら
Hiroshi Nakagawa
•
6.6K views
協調フィルタリングを利用した推薦システム構築
Masayuki Ota
•
25.7K views
StanとRでベイズ統計モデリング読書会 Chapter 7(7.6-7.9) 回帰分析の悩みどころ ~統計の力で歌うまになりたい~
nocchi_airport
•
4.9K views
スキルチェックリスト 2017年版
The Japan DataScientist Society
•
38.8K views
多項式あてはめで眺めるベイズ推定~今日からきみもベイジアン~
tanutarou
•
11.8K views
新規事業・起業を妨げる「ビジネスモデル症候群」とは
Lean Startup Japan LLC
•
111K views
いまさら聞けない機械学習の評価指標
圭輔 大曽根
•
105K views
確率的プログラミングライブラリEdward
Yuta Kashino
•
19.3K views
AWS Black Belt - AWS Glue
Amazon Web Services Japan
•
49.4K views
すべてを自動化せよ! 〜生産性向上チームの挑戦〜
Jumpei Miyata
•
17.2K views
Tokyo webmining 2017-10-28
Kimikazu Kato
•
8.6K views
(DL hacks輪読)Bayesian Neural Network
Masahiro Suzuki
•
18K views
本当は恐ろしい分散システムの話
Kumazaki Hiroki
•
672.3K views
Advertisement
Similar to Dragon: A Distributed Object Storage at Yahoo! JAPAN (WebDB Forum 2017)
(20)
Apache Hadoop HDFSの最新機能の紹介(2018)#dbts2018
Yahoo!デベロッパーネットワーク
•
3K views
Yahoo! JAPANのOracle構成-2017年版
Makoto Sato
•
4.4K views
MongoDBを用いたソーシャルアプリのログ解析 〜解析基盤構築からフロントUIまで、MongoDBを最大限に活用する〜
Takahiro Inoue
•
43.2K views
今注目のSpark SQL、知っておきたいその性能とは 20151209 OSC Enterprise
YusukeKuramata
•
5.1K views
[db tech showcase Sapporo 2015] A12:DBAが知っておくべき最新テクノロジー: フラッシュ, ストレージ, クラウド b...
Insight Technology, Inc.
•
1.5K views
[OLD/STALE] Redis cluster (japanese)
Shunichi Shinohara
•
3.1K views
[db tech showcase Tokyo 2014] D15:日立ストレージと国産DBMS HiRDBで実現する『ワンランク上』のディザスタリカバリ...
Insight Technology, Inc.
•
2.2K views
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Cloudera Japan
•
3.2K views
Cloudera大阪セミナー 20130219
Cloudera Japan
•
1.1K views
sparksql-hive-bench-by-nec-hwx-at-hcj16
Yifeng Jiang
•
10.5K views
Elasticsearch 5.2とJava Clientで戯れる #elasticsearchjp
Yahoo!デベロッパーネットワーク
•
5.4K views
Goでヤフーの分散オブジェクトストレージを作った話 Go Conference 2017 Spring
Yahoo!デベロッパーネットワーク
•
22.7K views
Interop 2017 in huawei booth
Tomohiro Hirano
•
302 views
ML Ops NYC 19 & Strata Data Conference 2019 NewYork 注目セッションまとめ
Tetsutaro Watanabe
•
3.2K views
OSSとクラウドによるコンピューティングモデルの変化
Nobuyori Takahashi
•
2.6K views
性能問題を起こしにくい信頼されるクラウド RDB のつくりかた
Tomoyuki Oota
•
1.6K views
Red Hat ストレージ製品
Takuya Utsunomiya
•
628 views
Datadog monitoring with HashiCorp
Masatomo Ito
•
418 views
Yahoo! JAPANのコンテンツプラットフォームを支えるSpring Cloud Streamによるマイクロサービスアーキテクチャ #jsug #sf_52
Yahoo!デベロッパーネットワーク
•
11.1K views
ヤフーを支えるフラッシュストレージ
Yahoo!デベロッパーネットワーク
•
1.5K views
More from Yahoo!デベロッパーネットワーク
(20)
ゼロから始める転移学習
Yahoo!デベロッパーネットワーク
•
11.9K views
継続的なモデルモニタリングを実現するKubernetes Operator
Yahoo!デベロッパーネットワーク
•
3.4K views
ヤフーでは開発迅速性と品質のバランスをどう取ってるか
Yahoo!デベロッパーネットワーク
•
1.2K views
オンプレML基盤on Kubernetes パネルディスカッション
Yahoo!デベロッパーネットワーク
•
1.8K views
LakeTahoe
Yahoo!デベロッパーネットワーク
•
1.5K views
オンプレML基盤on Kubernetes 〜Yahoo! JAPAN AIPF〜
Yahoo!デベロッパーネットワーク
•
1.5K views
Persistent-memory-native Database High-availability Feature
Yahoo!デベロッパーネットワーク
•
5.7K views
データの価値を最大化させるためのデザイン~データビジュアライゼーションの方法~ #devsumi 17-E-2
Yahoo!デベロッパーネットワーク
•
7.3K views
eコマースと実店舗の相互利益を目指したデザイン #yjtc
Yahoo!デベロッパーネットワーク
•
2.2K views
ヤフーを支えるセキュリティ ~サイバー攻撃を防ぐエンジニアの仕事とは~ #yjtc
Yahoo!デベロッパーネットワーク
•
1.9K views
Yahoo! JAPANのIaaSを支えるKubernetesクラスタ、アップデート自動化への挑戦 #yjtc
Yahoo!デベロッパーネットワーク
•
2.1K views
ビッグデータから人々のムードを捉える #yjtc
Yahoo!デベロッパーネットワーク
•
1.8K views
サイエンス領域におけるMLOpsの取り組み #yjtc
Yahoo!デベロッパーネットワーク
•
2.1K views
ヤフーのAIプラットフォーム紹介 ~AIテックカンパニーを支えるデータ基盤~ #yjtc
Yahoo!デベロッパーネットワーク
•
2K views
Yahoo! JAPAN Tech Conference 2022 Day2 Keynote #yjtc
Yahoo!デベロッパーネットワーク
•
2.3K views
新技術を使った次世代の商品の見せ方 ~ヤフオク!のマルチビュー機能~ #yjtc
Yahoo!デベロッパーネットワーク
•
1.9K views
PC版Yahoo!メールリニューアル ~サービスのUI/UX統合と改善プロセス~ #yjtc
Yahoo!デベロッパーネットワーク
•
1.9K views
モブデザインによる多職種チームのコミュニケーション改善 #yjtc
Yahoo!デベロッパーネットワーク
•
1.9K views
「新しいおうち探し」のためのAIアシスト検索 #yjtc
Yahoo!デベロッパーネットワーク
•
2.1K views
ユーザーの地域を考慮した検索入力補助機能の改善の試み #yjtc
Yahoo!デベロッパーネットワーク
•
2K views
Advertisement
Recently uploaded
(20)
SoftwareControl.pdf
ssusercd9928
•
15 views
MC-800DMT intrusion detector manual
Vedard Security Alarm System Store
•
3 views
【DL輪読会】Egocentric Video Task Translation (CVPR 2023 Highlight)
Deep Learning JP
•
63 views
20230523_IoTLT_vol99_kitazaki_v1.pdf
Ayachika Kitazaki
•
112 views
JSAI2023_企画セッション(仕掛学)資料
Matsushita Laboratory
•
0 views
【DL輪読会】Poisoning Language Models During Instruction Tuning Instruction Tuning...
Deep Learning JP
•
85 views
Kubernetes超入門
Takashi Suzuki
•
5 views
【DL輪読会】DINOv2: Learning Robust Visual Features without Supervision
Deep Learning JP
•
41 views
JSONEncoderで詰まった話
とん とんぼ
•
143 views
通信プロトコルについて
iPride Co., Ltd.
•
7 views
Windows ChatGPT Bing AI.pptx
Atomu Hidaka
•
7 views
OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)
NTT DATA Technology & Innovation
•
31 views
ペンタエリスリトール市場.pdf
HinaMiyazu
•
3 views
モバイル・クラウド・コンピューティング-データを如何に格納し、組み合わせ、情報として引き出すか
Masahiko Funaki
•
2 views
ネットワークパケットブローカー市場.pdf
HinaMiyazu
•
7 views
Wandb LLM Webinar May 30 2023 (配布用).pdf
Yuya Yamamoto
•
3 views
Forguncy8 製品概要 202305.pptx
フォーガンシー
•
55 views
AIEXPO_CDLE名古屋紹介
KotaMiyano
•
3 views
SoftwareControl.pdf
ssusercd9928
•
7 views
触感に関わる共感覚的表現と基本6感情の対応関係の検証
Matsushita Laboratory
•
15 views
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
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. About me • 後藤泰陽 / Yasuharu Goto • ヤフー株式会社 (2008年-) • ソフトウェアエンジニア • 主な分野:ストレージ、分散DB • Twitter: @ono_matope • 好きな言語: Go 2
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Agenda • Dragonについて • Dragonのアーキテクチャ • Dragonの課題と今後 3
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Dragon
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
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Dragon • Yahoo! JAPAN で独自に開発している社内向け分散オブジェクトストレージ • 目標:高パフォーマンス、高スケーラビリティ、高可用性、高コスト効率 • Written in Go • 2016年1月リリース (1年8ヶ月の本番稼働実績) • 規模 • 国内2DCで稼働中 • 合計オブジェクト数:200億オブジェクト • 合計データ量:11ペタバイト 6
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...
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
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
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. 開発の経緯
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
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Requirements • 要件 • サービスが求める以上の高パフォーマンス • 急激なデータ需要増に対応できる高スケーラビリティ • 少人数で簡単に運用でき、高い可用性 • 高いコスト効率 • ミッション • 使ってもらえる全社ストレージ基盤の確立 12
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Alternatives • 既存のオープンソース製品 • Riak CS: 一部サービスで導入するも、性能がサービス要件を満たさず • OpenStack Swift: オブジェクト増加時の書き込み性能低下が懸念 • パブリッククラウド • コスト面で不利 • ヤフーは自社DCでのサービス運用。 データローカリティ的にも、自社DCでスケールするストレージが必要 13
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Alternatives • 既存のオープンソース製品 • Riak CS: 一部サービスで導入するも、性能がサービス要件を満たさず • OpenStack Swift: オブジェクト増加時の書き込み性能低下が懸念 • パブリッククラウド • コスト面で不利 • ヤフーは自社DCでのサービス運用。 データローカリティ的にも、自社DCでスケールするストレージが必要 14 じゃあフルスクラッチで作ろう → 開発スタート
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Architecture
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
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
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
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 構成
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 ② メタデータ
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をリクエストし、ユーザにレスンポンスする
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が障害を起こした場合…
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
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 構成
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 構成
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/
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
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Other Pros/Cons • メリット • メタDBとBLOBストレージが独立してスケールアウトできる • ストレージエンジンがプラガブル • 将来的にストレージエンジンの変更や追加が可能 • デメリット • メタDBが別途必要 • ストレージの負荷に偏りが生じる • 定期的な再配置である程度対応 28
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Storage Node
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Storage 構成 • コスト効率のため、高密度のストレージサーバーを使用 • 高密度に耐えられる工夫が必要 30 https://www.supermicro.com/products/system/4U/6048/SSG-6048R-E1CR90L.cfm
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
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
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
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関数
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
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Dynamic Partitioning 36 • 書き込みスループットをハッシュ手法と比較 • ファイルが増えてもシーク数が増えず、スループットが安定 青:256ディレクトリにランダムに300万ファイルを書き込んだ時のシーク数とスループット 緑:Dynamic Partitionで300万ファイルを書き込んだ時のシーク数とスループット
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Microbenchmark 1HDDに対して1000万ファイルまで書き 込み性能の維持を確認 37 1000万ファイルを書き込んだ時のスループット。 (10万ファイル書き込みごとの平均rpsを採用。毎試行前にdirty pageのドロップ処理あり)
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
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
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に転送
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. MetaDB
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Cassandra • Apache Cassandra? • 可用性 • リニアに性能がスケールする • 運用コストの低さ • Eventual Consistency • トランザクションに頼らないスキーマ設計が必要 42
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Cassandra • Tables • VolumeGroup • Account • Bucket • Object • ObjectIndex 43
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....} パーティションキー
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の写真が最新バージョンとして整合性が取れる
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)
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)
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)
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と同様)
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上で同時実行制御を実現
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Issues and Future Works
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 分散キー クラスタリングカラム
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Issues • ObjectIndex関連の問題 • APIクエリによってはリストの作成のために多くのクエリが必要で高負荷、高レイテンシ • パーティションサイズ制約から、バケットあたりのオブジェクト数が320億に制限 • Indexを動的に水平分割する機構を導入し、オブジェクト数の制約を撤廃したい 53
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. Future Works • ストレージエンジンの改善 • 高速な追記ファイル型ストレージの開発 • 高効率なErasure Coding対応 • サーバーレスアーキテクチャ提供 • Kafka / PulsarなどMessaging Queueへのイベント通知 • 分散システムとのインテグレーション • Hadoop, Spark, Presto, etc... 54
Copyrig ht ©
2017 Yahoo Japan Corporation. All Rig hts Reserved. まとめ • ヤフーは大規模分散オブジェクトストレージ “Dragon” を開発・運用しています • Dragonは運用しやすく、ハイスケーラブルなストレージ基盤です • 新しいニーズに対応するため、今後も研究・開発を続けていきます
Advertisement