学際大規模情報基盤共同利用・共同研究拠点 平成 27 年度共同研究 最終報告書 2016 年 5 月

課題番号 jh150028-MD01

計算資源の連携を目指した 将来のサイエンスビッグデータ共有機構の開発
松岡 聡 （東京工業大学）

概要 近年の各種センシング技術の発展により、科学技術分野で生成されるデータ量は飛躍的に増加し続けている。例えば、遺伝学研究所が管理する国際塩基配列データベースは現状で 1.5 PB 程度ではあるが、数年のうちに 5 PB に達すると試算されている。このように急激に成長続けるサイエンスビッグデータを、効率的に保存・活用する技術が求められている。加えて、生成データ量の増加により、それを解析するための計算量も増加し、既存のスーパコンピュータの計算資源が不足することが懸念されている。このことから、外部機関のスーパコンピュータや、クラウド DC などの計算資源と連携し、必要な計算資源量を確保する必要がある。本研究では増加し続けるサイエンスビッグデータを、保存・共有するためのシステム環境を構築し、遠隔の計算資源より高効率にアクセス可能にする技術を開発する。本年度は、実証実験基盤の整備と遠距離計算資源へのアクセス技術であるクラウドバーストバッファの拡張等を行った。

International nucleotide sequence database

1. 共同研究に関する情報

collaboration で管理されている国際塩基配列デ(1) 共同研究を実施した拠点名ータベースを例にすると、現状のデータベースサ



北海道大学

イズは 1.5PB 程度であるが、数年のうちに 5PB に



東京大学も達する見込みである。このような巨大なサイエ

東京工業大学

ンスビッグデータをより効率的に保存する技術が

九州大学必要である。国立遺伝学研究所（以下、「遺伝研」(2) 共同研究分野という）では、国際塩基配列データベースや生命

超大規模データ処理系応用分野系データベースを管理するとともに、このサイエ

超大容量ネットワーク技術分野

ンスビッグデータの解析用にスーパコンピュータ

超大規模情報システム関連研究分野を提供している。しかしながら、近年の生命系計(3) 参加研究者の役割分担

算科学の重要性から生命系研究者の必要計算量が

松岡 聡: 全体統括増加しており、スーパコンピュータの混雑が発生



小笠原 原理: 遺伝学研究所のデータ提供し、ジョブの実行までの待ち時間が長くなりつつ

三浦 信一: システムの設計・構築とデータあり、場合によっては外部のスーパコンピュータ保存技術の開発・評価、およびシステムの結やクラウドデータセンターなどとの連携も考慮す合る必要がでてきている。

大田 達郎: データベース連携

徐 天棋: 高速データアクセス手法の開発・ベースなどの生命系データベースは、遺伝研が運評価営するスーパコンピュータだけではなく、計算手

佐藤 賢斗: 高速データアクセス手法の検討

法や目的に応じて理化学研究所計算科学研究機構



一方で、遺伝研が管理する国際塩基配列データが運用する「京コンピュータ」や東京工業大学学

2. 研究の目的と意義

術国際情報センター（以下、「東工大」という）が近年の次世代シーケンサの普及に伴い生命系デ運用する「TSUBAME2.5」のような大型のスーパコータベースのデータ量は飛躍的に増大している。

ンピュータを用いた利用がなされている。しかし
1

学際大規模情報基盤共同利用・共同研究拠点 平成 27 年度共同研究 最終報告書 2016 年 5 月

ながら、これらの生命系データベース等は、手動ら、通信遅延時間の増大とともに個々のファイルのファイルコピーによってなされており、データアクセスに対する応答時間は長くなることは避けベース等の追加・更新がなされた場合は、再度デられない。ファイルキャッシュ機構を利用するこータのコピーなどが必要であるなど、一貫的なデとで解決することも可能であるが、単純なファイータ管理という意味では、望ましくない運用となルキャッシュ機構では複数のノード間でファイルっている。可能であるならば、全国の計算資源よの一貫性を維持することが難しい。本問題の解決

り直接アクセス可能な分散ファイルシステム（デのためには、複数のノード間でファイルの一貫性ータレポジトリ）を用意し、一貫した生命系デーを維持可能な何らかの新たな機構を追加する必要タの管理が望まれている。しかしながら、生命系がある。

データベースの一部、特にヒトゲノムデータ等は、以上を踏まえ、本研究では生命系データベース個人情報などが含まれているため、そのデータののような巨大なサイエンスビッグデータの保存・公開には厳しい公開条件が課せられている。その共有するためのシステム環境を構築し、サイエンため、サイエンスビッグデータを安心・安全に共スビッグデータを遠隔の計算資源より高効率でア有可能にするためのシステム基盤が必要になってクセス可能にする技術を開発することを目標とすいる。

る。現時点で本研究がターゲットとするサイエン

このような中で、革新的ハイパフォーマンスコ

スビッグデータは、遺伝研が管理する生命系デー

ンピューティングインフラストラクチャー（以下、タベースではあるが、開発する技術は気象データ「HPCI」という）では、HPCI 資源提供機関間のデや天文データなど、他分野のサイエンスビッグデータ共有システムとして、約 20 PB の HPCI 共用スータも想定し、成果を共有可能なものとする。

トレージが構築され運用されている。この HPCI 共3. 当拠点公募型共同研究として実施した意義

用ストレージによって、京コンピュータをはじめとする全国のスーパコンピュータ間で容易に計算本共同研究は遺伝研が運用管理する国際塩基配データの連携が可能になり、有効に活用されてい列データベースなどの実データの提供をうけ、大る。しかしながら、限りある資源の有効利用の観容量のサイエンスビッグデータを複数の拠点で効点から、利用には HPCI 課題として採択される必要率的に共有する方法を開発するものである。そのがあり、本研究提案が想定する恒常的なサイエンため、実際の評価などには、比較的距離が離れたスビッグデータの共有・公開用のデータストレー複数の計算資源を必要とし、拠点公募型共同研究

ジとしての利用が難しい。

により複数の資源を確保できることが必要である。

また、一般に遠隔に構築されたデータストレー同様の公募型研究として、HPCI による研究公募がジを有効に利用するためには、如何に広帯域なネ存在するが、本研究は異なる 2 分野の共同研究にットワークを有効活用するかが重要になる。実際

よるフレームワークの開発であることに加え、に HPCI 共有ストレージでは、SINET5 の広帯域なHPCI では計算することを主目的とすることから、ネットワークを有効に利用し、大きなデータセッJHPCN を選択した。

トの共有を効果的に行うことができる機構を有する。遠隔からのファイルアクセスでは、物理距離4. 前年度までに得られた研究成果の概要に合わせて増加する通信遅延時間が影響し、個々今年度初採択につき該当事項無し。のファイル操作の応答時間が長くなるが、HPCI 共用ストレージでは、多数のファイルを同時に扱う

5. 今年度の研究成果の詳細ことで通信遅延の影響を隠蔽し、広帯域ネットワ

5.1. 実証実験基盤の構築と効率的なデータ保存方法の開発・評価

ークを有効に活用することもできる。しかしなが2

学際大規模情報基盤共同利用・共同研究拠点 平成 27 年度共同研究 最終報告書 2016 年 5 月
JHPCNによる資源
JHPCN以外で整備する資源

RENKEI-VPE(東大)
RENKEI-VPE(九大)

RENKEI-VPE(東工大)

広域分散ファイルシステム(Gfarm)を使用した
塩基配列データベース (東工大、遺伝研)

データサイエンス
クラウドシステム(北大)

TSUBAME2.5(東工大)

図 1 システム基盤の構築
本研究の評価の基盤として、広域分散ファイル

る HDD に利用されていくことが期待されている。

システムを構築し、このファイルシステム上に実一方で SMR 技術を用いた HDD では、細かいデータ際の生命系データベースを構築する。具体的にはの read/write において、性能が得られないという

図 1 のように、Gfarm ファイルシステムを用い、特性をもっており、本 HDD を用いて RAID を構成し東工大と遺伝研に広域分散ファイルシステムを構た場合、性能が得られないという問題がある。実築し、遺伝研が有する国際塩基配列データベース

際、今回構築した Gfarm ファイルシステムでは、等を展開する。本環境を用いて、I/O スループット

1 台のファイルサーバあたり 24 台の SMR 型 HDD でなどの基本性能を計測するとともに、本データを成り立ち、RAID6 を用いて 1 つのデータスプール使用するアプリケーションを東工大設置のを構築した。この結果として、データスプールあTSUBAME や、各拠点に整備された RENKEI-VPE で評たり 50MB/sec 程度の性能しか得ることができず、価する。最も遠隔にある北大のデータサイエンスシステムの評価環境として全く適さないものとなクラウド環境を用いて、アクセス特性などを評価ってしまった。このことより、SMR 型の HDD を使する。これらの評価を通じて、既存の広域分散フう場合は、RAID 構成ではなく、HDD 単体をデータァイルシステムの問題を把握し、サイエンスビッスプールとして扱わなければならない。残念ながグデータ向けの広域分散ファイルシステムのありら、現在の Gfarm ファイルシステムの実装では、方を検討する。

データスプール 1 つに対して 1 つの IP アドレス

今年度は、本実験基盤の中核となる東工大、遺が必要になり、今回構築する数百台規模の HDD を伝研の 2 拠点にまたがる分散ファイルシステムを用いたデータスプール構成では、IP アドレスが枯構築した。
分散ファイルシステムとして、現在 HPCI渇しかねない。また、数千台規模の HDD 構成によで利用されている Gfarm ファイルシステムを用いるシステム構築も検討しており、現状の Gfarm フた。

ァイルシステムを用いたシステムでは HDD を RAID

今回 Gfarm ファイルシステムを構成するファイ構成にせざるを得ず、性能か得られない可能性がルサーバでは SMR: Shingled Magnetic Recordingある。

技術を用いた HDD を用いている。SMR 技術は今後以上の理由により、評価環境として、Gfarm ファの HDD の高密度化を実現する核となる技術である。 イルシステムを構築したが、基本となるデータス安価でありながら大容量を実現することが可能でプール自体の問題で必要となる性能が得られなかあるため、今後のファイルアーカイブに用いられったことから、本ファイルシステムを用いた詳細
3

学際大規模情報基盤共同利用・共同研究拠点 平成 27 年度共同研究 最終報告書 2016 年 5 月

図 2

Two-level storage hierarchy in CloudBB

図 3

Architecture of CloudBB

図 4 Sequential I/O Performance

図 5 File Create Performance

な性能評価を断念した。これらを踏まえて、IP ア

テムに近傍に配置することである。しかしながら、ドレスを最小限にしつつ数千のデータスプールをこのような CN の配置制限は、本来クラウド環境が扱うことが可能な Swift や Ceph などの分散オブ持つ柔軟な計算リソース確保に制約を与えるためジェクトストレージでシステムを再度構築するこ望ましいものではない。一般的なスーパコンピュととした。

ータと同様、クラウド環境下においても CN 上のローカルファイルシステムにデータステージングす5.2. 遠隔計算資源より広域ファイルシステムる手法は有効ではあるが、複数の CN 間でデータのに高速にアクセスする技術の開発

一貫性確保が難しく、複数の CN からある特定のフ

現在のクラウド環境で用いられている共有ファ

ァイルに read/write を繰り返すような、データイ

イルシステムは、HPC アプリケーションに求めらンテンシブアプリケーションには有効に機能しなれる I/O スループットに十分対応することができい。ていない。これは、クラウド上では実際にファイ本問題を解決するために、我々は遠隔のファイルを使用する計算ノード（以下「CN」という）と共ルシステムに各々の計算機資源から効率的に直接有ファイルシステム間の物理的なネットワーク性アクセス可能にする技術であるクラウドバースト

能が、HPC 計算の主力であるスーパコンピュータバッファ（以下、「CloudBB」という）を提案・実装のそれよりも、遅延時間で 10 倍以上 転送帯域でしている。CloudBB の概念を図 2 に示す。CloudBBは 10～100 分の 1 以下であることに起因する。一はオンデマンドのキャッシュ制御機構を有するフ

般的には、データの移動コストは非常に高いため、ァイルバッファ（第 1 階層）と既存ストレージ（第この問題を解決する最も単純かつ最善な方法は、2 階層）から成り立つ。クラウド上の各 CN が、共有ファイルシステムの位置を固定したうえで、CloudBB が提供する第 1 階層にあるファイルバッ使用する物理的な CN を実際の共有ファイルシス

ファを経由し、第 2 階層の実ファイルシステムが4

学際大規模情報基盤共同利用・共同研究拠点 平成 27 年度共同研究 最終報告書 2016 年 5 月

図 2 スーパコンピュータとクラウドリソースの連携有するファイルにアクセスすることで、データのCloudBB は、複数のサブクラウドバーストバッフ

一貫性を確保したまま、ファイル I/O を効率的にァ（以下、「SCBB」という）で構成される。各 SCBB行うことを可能にする。CloudBB は第 2 階層のスは、メタデータを管理するマスターノード（以下、トレージとして、Amazon S3 といったクラウドス「MN」という）1 台と、その管理下で実際のバッフトレージを主なターゲットとして開発したものでァとして機能する IO ノード(以下、「ION」という)あるが、一般的に Linux がマウント可能なファイ複数台から成り立つ。CN は、ファイルパスのハッルシステム（NFS、Lustre、GPFS、Gfarm 等）であシュ値を用いて SCBB を選択し、その SCCB に紐づれば使用できるとともに、TSUBAME2.5 のような一けられた MN と ION を用い、ファイル I/O を行う。

般的なスーパコンピュータでも利用できる。

このように CloudBB を拡張することで、データの既存の CloudBB の実装では、第 1 階層でのファ一貫性を維持しつつ、大量のメタデータ変更が必

イルの一貫性確保のために、一般的な並列ファイ要なファイル I/O が発生した場合においても、シルシステムと同様に、メタデータサーバを用いるステムを追従させることが可能になる。

マスタワーカ型の実装となっていた。しかしなが

評 価 には 実 際の クラ ウド 環 境と し て Amazon

ら、マスタワーカ型の実装はシステムの拡張性に

EC2/S3 の Asia Pacific(Tokyo)リージョンを用い乏しく、複数の CN が多量のファイル I/O を行う場た。CN、MN および ION の各仮想マシンのインスタ合に、メタデータの性能がシステム全体の性能のンスは M3.xlarge (spot instance)を選択した。

ネックとなる。このような拡張性の制限を取り除

各仮想マシンの構成は vCPU が 4 つとし、メモリーくためには、オブジェクトストレージなどで用いサイズは 15GB とした。また、Network 性能としてられている、Key-Value モデルを用いることが一High を選択している。
各 CN は FUSE 経由で CloudBB

般的であるが、Key-Value モデルはアプリケーシをマウントし、各 ION が Amazon S3 を s3fs 経由でョンによってはデータ一貫性の維持が難しいといマウントした各 ION 経由でファイル I/O を行った。

う問題がある。今年度の開発では、データの一貫

図 4 に MN を 1 台に設定した場合のシーケンシャ性を維持しつつ、性能向上を得るために、マスタ

ル I/O の評価結果を示す。s3fs 単体で用いる場合

ワーカモデルと Key-Value モデルのハイブリット

では、read 4.3GiB/sec、write 1.2GiB/sec の性能であるマルチマスタワーカ型へ CloudBB を拡張しが得られることに対して、CloudBB を用いる場合た。

では、それぞれ 12GiB/sec、11.7GiB/sec となり、マルチマスタワーカを実現する、CloudBB の構

CloudBB により高い I/O スループットが得ること成を図 3 に示す。マルチマスタワーカ型のが確認できた。メタデータ処理の性能評価として
5学際大規模情報基盤共同利用・共同研究拠点 平成 27 年度共同研究 最終報告書 2016 年 5 月

MN を 1,2,4 台にした場合のファイル作成の性能評て、北大のデータサイエンスクラウドを用いて評価結果を図 5 に示す。評価の結果では、16 台の CN

価を行う予定であったが、データサイエンスクラと 2 台の MN を用いた場合、CloudBB は s3fs を直ウド上の仮想マシンから、外部ネットワークへの接使う場合に対して約 518 倍高速にメタデータ操接続に対してデータ転送性能が得られないという作が可能であることが分かった。

問題も見られ、最終的に今年度は遠隔地からファ以上の評価結果により、CloudBB を用いることイルアクセスなどの評価は見送った。また 5.1 にで、遠隔のファイルシステムにクラウド上の計算示したように、当初評価に用いるために構築してリソースから、効率的なアクセスが可能になるこいた大容量分散ファイルシステムが、性能評価にとが示せた。

耐えうる性能が得られず、システムに合わせて再構築を必要とするなど、今年度は研究のインフラ5.3. 外部のスーパコンピュータやクラウド DC面の整備で大きな課題を残した。との連携技術の開発

他方ソフトウェア部の開発では、遠隔計算資源解析するべきデータはセンサーの性能向上と共より広域ファイルシステムに高速にアクセスするに増大し続けており、必要十分な計算資源を一拠ための基本システムであるクラウドバーストバッ点のみが提供することが難しくなっている。また、ファの性能向上と安定化を進めることができた。

Amazon web service 等パブリッククラウドの発展

これにより、今後の外部のスーパコンピュータとにより、クラウド資源を利用したデータ解析も有クラウド DC との連携に目処をつけることができ効な手段になりつつある。そこで、複数のスーパた。しかしながら、現状のクラウドバーストバッ

コンピュータ資源間での連携やスーパコンピューファの評価では、Amazon EC2 上での評価にとどまタとクラウド資源の連携について模索する。これり、本来の計画した、TSUBAME2.5 等のスーパコンらの研究は過去においてグリッド関係でなされてピュータと外部ストレージとの連携評価が行えてきているが、VM やコンテナ技術の発展で使用可能おらず、TSUBAME2.5 上でのクラウドバーストバッな技術が成熟しており、現在の技術を用いた最適ファの基本動作の確認にとどまった。

なシステムを構築する。まずはじめとして、スーこのように、今年度は個別の技術要素の整備とパコンピュータからクラウド資源へのジョブマイ技術開発に終始し、実システムへの適用、特に整グレーションなどを検討する。その際に各資源間備したストレージ環境とクラウドバースバッファでファイルをシームレスに共有する手段としてクを用いた性能評価などは、今後の課題として残っラウドバーストバッファのようなシステムの利用た。

を検討する（図 2）。

今後は個別の技術要素の一体化を進め、本課題

今年度は、5.2 節に示したクラウドバーストバの最終的な目標となる、 外部のスーパコンピューッファをスーパコンピュータである TSUBAME2.5

タやクラウド DC との連携技術の確立を進めていに適用し動作することを確認した。

く。

6. 今年度の進捗状況と今後の展望

7. 研究成果リスト

実証実験基盤の構築では、分散ファイルシステ(1) 学術論文

ムの一部を設置する遺伝研内部において、想定の該当事項なしネットワーク速度が得られないという問題が発生(2) 国際会議プロシーディングスした。調査の結果、接続したネットワーク装置が該当事項なし想定した性能を提供していないことが原因である(3) 国際会議発表
 Tianqi Xu, Kento Sato and Satoshi Matsuoka,

ことが判明した。また、遠隔の計算リソースとし6

学際大規模情報基盤共同利用・共同研究拠点 平成 27 年度共同研究 最終報告書 2016 年 5 月“Towards Cloud-based Burst Buffers for I/O
Intensive Computing in Cloud”, In HPC inAsia Workshop in conjunction with theInternational Supercomputing Conference(ISC’15), Frankfurt, Germany, July, 2015.
(Refereed Poster) Tianqi Xu, Kento Sato and Satoshi Matsuoka,“Design and Modelling of Cloud-based Burst
Buffers”, In Proceedings of the International
Conference on High Performance Computing,
Networking, Storage and Analysis 2015 (SC15),
Austin, USA, Nov, 2015. (Refereed Poster)(4) 国内会議発表
Tianqi Xu, Kento Sato and Satoshi Matsuoka,"Cloud-based
Burst
Buffersfor
I/O
Acceleration", IPSJ SIG Technical Reports
2015-HPC-150, Beppu, Japan, Aug, 2015.

(5) その他
該当事項なし7