クラウド時代のデータ共有技術ＷＧ
成果報告書

2019 年 4 月 30 日
サイエンティフィック・システム研究会
クラウド時代のデータ共有技術ＷＧ

サイエンティフィック・システム研究会 クラウド時代のデータ共有技術 WG

成果報告書

目 次
1.
はじめに(WG 活動概要) ······································································ 11.1. WG 発足の背景 ············································································· 11.2. 活動方針 ················································································· 1
1.3. 活動内容 ················································································· 2
1.4. 活動期間 ················································································· 2
1.5. WG メンバー ··············································································· 2
1.6. 活動実績 ················································································· 2
1.7.
参考文献 ·············································································· 3
2. クラウド時代のデータ共有技術の現状と問題 ······················································ 42.1. 昨今の要請と問題（概要説明）······························································ 42.2. クラウド技術の動向 ······································································· 42.2.1. クラウドのサービス～オンプレミスのサービス ············································ 52.3. 大規模データ・大量データを活用する分野における課題 ········································ 52.3.1. クラウドサービスおよびオンプレミスシステムそれぞれの利点と欠点 ························ 62.3.2. オンプレミスとクラウドサービスの違い～システム管理者的視点より～······················· 7
2.3.3. ユーザがクラウドサービス利用時に期待する点 ············································ 7
3.1. サービス動向 ············································································· 8
3.1.1. オンラインストレージ（ファイル保管・データ共有） ······································ 8
3.1.2. グループウェア（メール・ドキュメント共有・ファイル共有・スケジュール共有）············· 93.1.3. プロジェクトホスティングサービス ····················································· 10
3.1.4. 認証サービス ········································································ 10
3.2. ソフトウェア動向 ········································································ 10
3.2.1. ファイル共有 ········································································ 10
3.2.2. ファイルシステム····································································· 11
3.2.3. オブジェクトストレージ······························································· 12
3.2.4. ブロックチェーン····································································· 13
3.3. ハードウェア動向 ········································································ 13
3.3.1. ストレージ技術動向··································································· 13
3.3.2. 価格容量比率など····································································· 14
3.4. データ転送技術 ·········································································· 14
3.4.1. ストレージゲートウェイ······························································· 14
3.4.2. 高速データ転送 ······································································ 14
3.5. 現在までの大規模・大量データの共有方法と分析 ············································· 15
3.5.1. データを配布する側の事例 【A.1. 早戸委員】 ·········································· 15【東京大学 宇宙線研究所 神岡】 ····························································· 15
3.5.2. データを配布する側の事例 【A.2. 藤田委員】 ·········································· 15【宇宙航空研究開発機構 調布】 ······························································· 15
3.5.3. データを配布する側の事例 【A.3. 中村委員】 ·········································· 15【高エネルギー加速器研究機構】 ······························································ 15
3.5.4. データを配布する側の事例 【A.4. 白崎委員】 ·········································· 15【国立天文台】 ············································································· 15
3.5.5. データを受信する側の事例 【A.3. 中村委員】 ·········································· 15【高エネルギー加速器研究機構】 ······························································ 15
3.5.6. ポリシーやガバナンス事例 【A.5. 渡邉委員】 ·········································· 16【広島大学】 ··············································································· 16iサイエンティフィック・システム研究会 クラウド時代のデータ共有技術 WG

成果報告書

3.5.7. 各研究機関の分析····································································· 19
4. クラウド時代のデータ共有技術における課題(受容も含む) ········································· 22
4.1. データへのアクセス方法··································································· 22
4.1.1. 検討しておくべきデータアクセス性能に対する要請 ······································· 22
4.1.2. アクセス方法に対する要請····························································· 22
4.2. データ移動量（オンプレミス→クラウド、クラウド→オンプレミス）に対する要請················ 23
4.2.1. 課金システム（データ総容量、アクセス頻度、アクセス制限）について······················ 23
4.2.2. 調達フェーズと運用フェーズにおいて検討する必要のある事項 ····························· 23
4.3. データ共有にかかるリスク対応····························································· 24
4.3.1. ガバナンス・コンプライアンス・国際法律 ··············································· 25
4.3.2. 連携する両者のポリシー整合性 ························································· 25
4.3.3. 認証・証跡 ·········································································· 25
4.3.4. データ保護・アクセス権限・特権 ID ···················································· 25
4.4. データ共有時の利便性や管理の容易さを向上させる技術 ······································· 26
4.4.1. データへのタグ付け（LOD、データジャケット、メタデータ）、VPX ·························· 26
5. データ共有技術におけるオンプレミス・クラウド利用に向けたチェックリスト ······················· 27
5.1. 共有データ種別・目的・方法······························································· 27
5.1.1. データ種別 ·········································································· 27
5.1.2. データアクセス ······································································ 27
5.1.3. 総データ量 ·········································································· 28
5.1.4. データアクセス量····································································· 28
5.2. 可用性 ·················································································· 28
5.2.1. サービス時間（計画的、事前通知、サービス終了リスク） ································· 28
5.2.2. 稼働率・継続性 ······································································ 28
5.2.3. ディザスタリカバリ··································································· 28
5.3. システム管理・監視 ······································································ 28
5.3.1. リソース管理オペレーション··························································· 28
5.3.2. システム監視（ログへのアクセス） ····················································· 28
5.4. 性能 ···················································································· 29
5.4.1. スループット性能····································································· 29
5.4.2. レスポンス性能 ······································································ 29
5.4.3. 処理能力【件数】····································································· 29
5.5. データ管理 ·············································································· 29
5.5.1. データ移行方法 ······································································ 29
5.5.1. バックアップ（容量、バックアップ時間、保存期間） ····································· 29
5.5.2. データ消去（ポータビリティ/委託） ···················································· 30
5.5.3. 暗号化（データ漏えい対策、データ破損・改ざん検知） ··································· 30
5.6. セキュリティ ············································································ 30
5.6.1. ユーザ管理・認証····································································· 30
5.6.2. 証跡・データ保護····································································· 31
5.7. クラウド・オンプレミス検討の方向性 ······················································· 31
6. 結び ························································································ 33
A. 各委員のシステム紹介 ········································································ 34
A.1. 早戸委員 ················································································ 34
A.2. 藤田委員 ················································································ 47
A.2.1 概要 ··················································································· 47
A.2.2 JAXA のデジタルデータ運用 ······························································· 49
A.2.3 データ管理の課題 ······································································· 50
A.3. 中村委員 ················································································ 51
A.4. 白崎委員 ················································································ 69

iiサイエンティフィック・システム研究会 クラウド時代のデータ共有技術 WG

成果報告書

A.5. 渡邉委員 ················································································ 85
B. クラウド時代のデータ共有技術紹介····························································· 97
B.1. クラウドストレージ、ストレージソフトご紹介 ··············································· 97
B.2. データ配布時の高負荷対策································································ 105
B.3. クラウドストレージ紹介·································································· 110
B.4. クラウド時代のデータ共有技術···························································· 114
B.5. 「認証サービス」ご紹介·································································· 123
B.6. ブロックチェーンで実現するデータ流通・利活用 ············································ 133

表 目 次
表 1 一般的なクラウドの利点（AWS の場合）..................................................... 6
表 2 オンプレミスとクラウドの考慮点の比較 ................................................... 7
表 3 媒体の価格容量比率.................................................................... 14
表 4 法人文書重要度分類表.................................................................. 18
表 5 各研究機関のデータ分析 ................................................................ 20
表 6 各研究機関のツール分析 ................................................................ 21
表 7 クラウドに向かない状況一覧 ............................................................ 32
表 8 オンプレミスやハイブリッドクラウドの選定基準一覧 ...................................... 32

図 目 次
図 1 データ容量に対するコスト ............................................................... 9
図 2 データ転送量に対するコスト ............................................................. 9
図 3 Erasure Coding の仕組み .............................................................. 12
図 4 クラウドサービス利用基準 .............................................................. 19

商標、登録商標について
・PRIMERGY、ETERNUS、FEFS は、富士通株式会社の登録商標です。
・その他一般に、会社名、機関名、製品名は各社や各機関の商標または登録商標です。
・会社名、システム名、製品名などには必ずしも商標表示（TM, ®）を付記しておりません。

iiiサイエンティフィック・システム研究会 クラウド時代のデータ共有技術 WG

成果報告書

1. はじめに(WG 活動概要)
WG 発足の背景や活動方針について以下に示す。

1.1. WG 発足の背景
クラウドサービスは、利用者が手元のコンピュータで利用していたストレージやソフトウェアを、ネットワー
ク経由で、利用者に提供するものである。利用者側は、最低限の環境（PC や携帯情報端末などのクライアント、
その上で動く Web ブラウザーおよびインターネット接続環境など）を用意するだけで、どこからでも、また、どの端末からでも、さまざまなサービスを利用することができる。また、利用者は、クラウドサービス事業者が保有するコンピュータの処理能力を、柔軟に必要な分だけ利用することができる。
これまで、利用者はコンピュータのハードウェア、ソフトウェア、データなどを、自身で保有・管理し利用していた。しかしクラウドサービスを利用することで、機材の購入やシステムの構築、管理などに必要となるさま
ざまな手間や時間の削減が可能となり、業務の効率化やコストダウンを図ることができるようになる。
クラウドサービス（特に、以下の分類でいう IaaS）では、主に仮想化技術が使われている。仮想化技術とは、実際に存在する１台のコンピュータ上に、ソフトウェアの働きにより、何台もの仮想のコンピュータがあるかのような働きをさせることができる技術である。逆に複数台のコンピュータをあたかも 1 台であるかのように利用することもできる。この技術により、利用者から見て、インターネットの先にある自分が利用しているコンピュータの形態が実際にどうなっているのか見えづらいことを、図で雲のかたまりのように表現したことから、「cloud＝雲」という名称がついたと言われている。
クラウドサービスは、企業が情報資産を管理する手段として急速に普及している。また、個人が利用するインターネット上のさまざまなサービスも、利用者が意識するかどうかにかかわらず、クラウドサービス上で稼働するようになっている。
クラウドサービスを利用する場合には、データや認証情報がクラウドサービス事業者側のサーバに保管されること、また、データなどがインターネットを介してやりとりされることなどから、十分な情報セキュリティ対策が施されたクラウドサービスの選択が重要であるということを理解した上で利用することが大切である。
（出典：http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/service/13.html）

1.2. 活動方針
近年の共同研究は国際化が進み、大規模なデータを国内外で共有、相互利用している。これに伴い、大量のストレージやCPU資源が必要となったことから、中核となる研究機関のみで必要な計算機資源を保持し、ユーザに提供することは困難となり、複数の研究施設の持つ計算機資源を統合的に活用することが必要となってきた。このため、複数機関で大規模なデータの共有を効率的に行うことが一つの課題となっている。さらに近年では、公的資金を用いて行われる実験や研究などの成果を社会に還元することが必須となっており、一般公開する必要のあるデータも大規模となってきている。
これまでに、研究機関内など閉じた環境においてデータを共有する技術は確立されている。しかしながら、国内外に散らばる複数の研究機関が参画する場合のデータ共有に必要な技術（ソフトウェア等）は、未だ簡単に導入、運用できるものとはなっていない。近年特に問題となることが多いセキュリティ問題に対処することも必須であり、ネットワーク接続の制限やユーザの管理などにも配慮する必要がある。こういった様々な制約の中で、効率的かつ十分な性能を持ったデータ共有システムが求められている。
こういった現状を鑑み、本WGでは、いくつかの研究分野におけるデータ共有への要求を整理すると同時に、現在のデータ共有基盤技術を調査し、要求に適した技術を提示するとともに、既存技術における課題と必要となる技術開発の方向性について議論を行うことを目指す。

1

サイエンティフィック・システム研究会 クラウド時代のデータ共有技術 WG

成果報告書

1.3. 活動内容
WG前半では、様々な分野におけるデータ共有の具体的な事例と要求、ならびに課題を集め、これらを整理するとともに、現在のデータ共有に関連する技術・規格や将来動向を調査した。
WG後半では、調査したデータ共有技術と、整理された要求や課題との関連を把握し、各事例に利用可能なデー
タ共有技術を検討するとともに、開発が必要となる技術について検討することを通し、今後のデータ共有の在り方について報告書にまとめた。
本WGのまとめが、国や分野を超えたデータ共有に関する検討の一助となることを期待する。

1.4. 活動期間
2017年1月～2019年4月

1.5. WG メンバー
担当幹事
会員

推進委員

賛助会員
推進委員
(富士通)

井口
○早戸
藤田
中村
白崎
渡邉
○阿部
栄元
坂口
甲斐
宮本
篠原
鈴木
浅野
荒井

氏名
寧
良成
直行
智昭
裕治
英伸
孝之
雅彦
吉生
俊彦
巧輝
誠
康介
典志
亮太

機関/所属(2018 年 12 月 31 日現在)
北陸先端科学技術大学院大学
東京大学宇宙線研究所
宇宙航空研究開発機構
高エネルギー加速器研究機構
国立天文台
広島大学
富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)
富士通(株)(株)富士通研究所
オブザーバ 富士通(株)オブサーバ 富士通(株)○印：まとめ役

1.6. 活動実績■第1回会合 : 2017年2月1日(水) 富士通(株)本社
・WG活動計画(活動方針、活動の進め方/スケジュール感、成果)の確認
・各委員の課題意識の共有と意見交換、活動で取り上げる課題の検討■第2回会合 : 2017年6月9日(金) 富士通(株)本社
・各会員における運用や課題などの共有および議論
・データ共有に関するテクニカルなトレンドなどの紹介および議論■第3回会合 : 2017年10月6日(金) 富士通(株)本社・各機関におけるデータ分析・ツール分析の結果共有および議論
・WAN高速化技術の紹介および議論■第4回会合 : 2017年12月22日(金) 富士通(株)本社
・クラウドストレージゲートウェイ機能の紹介および議論
・クラウドサービス使用時に必要な対策(ユーザ認証・セキュリティ)の議論
2サイエンティフィック・システム研究会 クラウド時代のデータ共有技術 WG

成果報告書

・クラウドストレージの比較とデータ配布時の高負荷対策の議論
・各機関におけるデータ分析・ツール分析の結果確認と、まとめの方向性の検討■第5回会合 : 2018年4月3日(金) 富士通(株)本社
・ブロックチェーンを利用したデータ流通・利活用技術の紹介および議論
・成果報告書の作成方針、掲載項目、構成の検討■第6回会合 : 2018年7月17日(火) 東京大学宇宙線研究所(神岡)・クラウドサービスとオンプレの比較の紹介および議論
・クラウドストレージゲートウェイの動向の紹介および議論
・富士通クラウドにおける認証サービスの紹介および議論
・ストレージの動向の紹介および議論
・クラウドストレージBoxの紹介および議論
・成果報告書の目次、掲載内容、執筆分担の検討■第7回会合 : 2018年10月3日(水) 富士通(株)本社
・成果報告書の目次、詳細内容、執筆分担、スケジュールの検討、確定■第8回会合 : 2018年12月14日(金) 富士通(株)北陸支社
・成果報告書の目次、詳細内容検討、執筆進捗確認、スケジュールの確定

1.7.

参考文献

今後のデータ共有技術のありかたを検討するにあたり、クラウドサービスの利用の参考となる資料を以下に示す。
題目
更新
URL

： 大学・研究機関のためのクラウドスタートアップガイド： Ver.2.0 (2018/11/19)
国立情報学研究所クラウド支援室： https://cloud.gakunin.jp/dist/pdf/startupguide-v2.pdf

3

2. クラウド時代のデータ共有技術の現状と問題
近年、大規模な事業を手掛ける企業においては、大規模なデータを保持、活用する技術が必要である。例えば、7500 万件の契約を持つ携帯事業者が、各契約あたり 5GB 程度のデータを保持するなら、全体で約 400PB のデータを扱うこととなる。また、1 万人の社員を持つ企業において、社員一人当たりが 1TB の領域を利用すれば、全体では 10PB が必要となる。ここまで大規模でなくとも、企業で扱われるデータは日々増加しており、実際に PB 級のデータ領域を要求する調達も少なからずある。一方で、企業内で大規模なデータを管理・利活用する技術を持つことは容易でない。このことは、総務省の調査からも見て取ることができる。2017 年度にクラウドサービスを一部でも利用している企業の割合は 56.9％となり、前年の 46.9％から大幅に増加している。これは、企業が大量のデータ管理や、その利用を、クラウドサービスの導入によって達成しようとしていることを示している。
そこで本 WG では、まず研究機関や大学、企業が必要とする大容量のデータ管理において、一般に提供されているクラウドサービスを調査、利用可能なケース、不適切なケースを検討した。

2.1. 昨今の要請と問題（概要説明）
利用されているクラウドサービスの内訳をみると、「ファイル保管・データ共有」（51.2％）が最も多く、次いで「サーバ利用」（47.6％）、「電子メール」（46.3％）の順となっている。また、クラウドサービスを利用している
理由としては、「資産、保守体制を社内に持つ必要がないから」（45.2％）が最も多く、次いで「どこでもサービスを利用できるから」（34.8％）、「安定運用、可用性が高くなるから（アベイラビリティ）」（32.6％）が主なものとなっている。さらに、クラウドサービスを利用する企業のうち、「非常に効果があった」または「ある程度効果があった」として、効果を実感している企業の割合は 85.2％であり、多くの企業がクラウドサービスの利用による効果を実感している。中小企業庁が発表している『中小企業白書（2013 年版）』によると、企業がクラウドサー
ビスを利用する理由として、「初期コストが安い」「導入までの期間が短い」「技術的な専門知識がなくても導入できる」をあげている。
(出典: http://www.chusho.meti.go.jp/pamflet/hakusyo/H25/PDF/0EHakusyo_part2_chap1_web.pdf)
一方で導入後の評価をみると、従業員数の数によりそのポイントが分かれている。従業員数の少ない企業ほど「初期コストが安い」という評価が低い。これは「IT 専任者もしくは、部門やガバナンスが整備されているかど
うか」という点ではないかと推測される。 IT 専任者や部門が存在しない場合は「技術的な専門知識が不要(外部に委託)」という点がメリットになり得ると考えられる。逆にクラウドサービスを利用していない理由としては、「必要がない」（39.5％）が最も多く、次いで「情報漏えいなどセキュリティに不安がある」（38.1％）、「クラウドの導入に伴う既存システムの改修コストが大きい」（27.6％）が多くなっている。
(出典: http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h30/html/nd252140.html）
最近の国内や海外の状況はクラウドサービス利用をやめ、オンプレミスに戻すケースも見受けられている。シ
ステムをオンプレミスに戻す決定を行った理由について、セキュリティ、通信費用などのコストの問題、管理や信頼性に関する不満などが挙げられている。
データ共有という観点から興味深いのは、最もよく利用されているサービスがオンラインストレージであるということである。本サービスは、多くのクラウド業者が提供しており、主要なものとして Dropbox、Box、Google
Drive、OneDrive、iCloud Drive、MEGA、Amazon Cloud Drive、Tera クラウド、SpiderOak、MediaFire などがある。一方で、業者(サービス)ごとに想定利用形態が異なり、これに伴って仕様や価格も大きく異なるため、選定においては注意深い検討が必要である。また、データ共有時には漏えいや改ざんなどを防ぐこと、すなわちセキ
ュリティへの配慮は重要であり、この点での評価も必須となる。このように、組織の大きさにも影響されるクラウドサービスの利活用を見極めるためには、一般的なガイドラインの他にデータ共有技術におけるガイドラインも必要と考える。
このため本 WG ではデータ共有の観点でオンプレミス、クラウドの判断基準を議論し明らかにしたい。

2.2. クラウド技術の動向
一般的なクラウドサービスとオンプレミスサービスを列挙する。

4

2.2.1. クラウドのサービス～オンプレミスのサービス
クラウドサービスの分類としては、以下のカテゴリが存在しており、必要に応じてサービスに追加できる。比較対象も必要と考えオンプレミスにおいては、以下機能を必要に応じて追加できることを前提とした。
・SaaS(Software as a Service):クラウド内のサーバ上で実行されるアプリケ-ション (ソフトウェア)を提供
・PaaS(Platform as a Service）：クラウド内で動くアプリケーション（ソフトウェア）の実行環境を提供
・IaaS(Infrastructure as a Service):クラウド内の (多くの場合は仮想化された)計算機を提供
・DaaS(Desktop as a Service):ユーザが使用するデスクトップ画面を提供
・DSaaS(Data Storage as a Service) ストレージ容量およびアクセス・管理機能を提供
・DBaaS (DataBase as a Service):データベースのアクセスおよび管理機能をオンマンドに提供
・IDaaS(IDentity as a Service):アイデンティやそのアクセス権限管理の機能を提供
このように、多種多様なサービス形態がある中、サービス提供までの時間、Quality、価格（利用・管理コスト含む）の面と技術動向の面において情報が散見される状態である。
詳細なサービス一覧としては以下である。クラウドと異なり、オンプレミスは優先度の高いサービスを選定後にサービス提供する制約を前提とした。
・コンピューティング：仮想サーバ、コンテナ、Auto Scaling、ロードバランシング・ストレージと配信：オブジェクトストレージ、ブロックストレージ、アーカイブストレージ、コンテンツ配信
・データベース：RDB､NOSQL、キャッシュ、データウェアハウス
・ネットワーク：インタコネクト、仮想ネットワーク、専用線、ロードバランシング
・セキュリティ・認証：ID 管理、アクセスコントロール、キーの管理
・分析：Hadoop、リアルタイム、機械学習、データウェアハウス、Data Pipelines
・アプリケーションサービス：キューイング、ワークフロー、ストリーミング、メール、通知、検索、API・開発用ツール：ソースコード管理、デプロイ、継続的デリバー
・管理ツール：モニタリング、リソーステンプレート、使用量とリソースの監視、サービスカタログ

2.3. 大規模データ・大量データを活用する分野における課題
近年、スーパーコンピュータの演算性能の向上に伴って、高統計のシミュレーションデータの生成やデータ解析処理のスループットが向上したこと、ならびに、観測・測定機器の高精度化や多チャンネル化に伴ってデータの生成量は大幅に増加し、扱う必要のあるデータが大規模化した。一方で、利用する機器のコストは少数の組織や場合によっては一国でまかなえないものや国際的な共同研究が加速している状況から、大規模データ・多量データを有する研究機関は、組織を超えた共有がこれまで以上に重要となった。また、公的資金を用いた研究に対しては、そのコストを負担した社会への還元として、データの公開が求められるようになった。
一般社会においては、官公庁や企業がこれまで個別に収集・管理してきた様々なデータを統合的に扱うことで、生活の利便性向上なども含めた様々な問題の解決に役立つことが認知されるようになった。このため、様々な分野・領域でデータの集積と大規模化が急速に進んでいる。
これらは、計算機資源の共有・管理ならびに大規模データの保存・管理・共有において、クラウド技術の急速な発展が実現したことによって実現された。一方で、この過程において大規模なデータを取り扱うにあたっての様々な課題も認識されるようになった。特に大規模データの共有においては、データアクセスに求められる性能やア
クセスポリシーが業務や事業ごとに異なるため、用いるべき技術も異なってくる。そのため、ユーザ、管理者、
メーカ・ベンダ等の技術者が目的を共有し、それぞれの視点から課題を認識することで、初めて適切な技術選択
や、開発すべき技術課題の明確化、そして課題への対応を実現することができる。本 WG の議論を通して、大規模データを共有したい場合にクラウドサービスを利用することが適切なのか、オンプレミスのシステムを構築する必要があるのかを判断するためには、どのようなことを考慮すべきか、最低限の基本的な情報を得ることもなか
なか困難であるという共通認識となった。そこで、本まとめではクラウドサービスとオンプレミスそれぞれのもつ特性を整理し、技術、業務、調達などの観点から、クラウドとオンプレミスの選択に役立てることが可能となる資料とすることを目指すこととした。

5

2.3.1. クラウドサービスおよびオンプレミスシステムそれぞれの利点と欠点
ここでは、一般的なグラウドサービスとして AWS の利点をまとめた。
表 1 一般的なクラウドの利点（AWS の場合）

自社データセンター

AWS クラウド

初期コスト

必要

不要

利用コスト

余剰リソースにもコスト発生

実際の利用分のみのコスト負担

災害対策コスト高い（物理的に異なる場所のデータセンタ
ー向けにハードウェア発注、設定、運用を物理的に行う必要あり）

安い（稼働していない時間は無料）

インフラバージョンアップ
/システム更改時のコスト

必要

不要

インフラ調達期間

数週間～数か月

数時間

データセンターのロケーション変更

長時間必要

短期間で可能サーバスペック変更の容易性

時間とコストがかかる

余計なコストなしにすぐに対応
可能

自社ネットワーク内での利用可能(考慮不要)可能

専用線による自社内サーバとの接続

可能

可能

自身で取得

AWS 側で取得済（SOC 1/SSAE 16/ISAE 3402,
SOC 2, ISO 27001, PCI DSS レ
ベル 1, HIPAA, ITAR, FISMA
Moderate, FIPS 140-2, CSA）

第三者機関認証6

2.3.2. オンプレミスとクラウドサービスの違い～システム管理者的視点より～
オンプレミスとクラウドの考慮点の比較の結果を「表 2 オンプレミスとクラウドの考慮点の比較」に示す。
表 2 オンプレミスとクラウドの考慮点の比較
調達

調達物

設計・開発
主要な経費

維持・保守
費用
資産管理
セキュリティ
そのほか

オンプレミスハードウェア・ソフトウェア・サービス（メンテナンス）について仕様を策定する必要がある。

クラウドサービス
サービスに対しての仕様を策定すればよい。
（サービスとして提供されていない要請に対しては、別途開発等が必要なことはオンプレミスと同様である。
）

インフラストラクチャ（ハードウェア・ソフトウェア）を調達する。設置期間なども必要である。
要求仕様に応じて柔軟な設計が可能、一方で、相応のコストが必要になる場合もある。

必要に応じてネットワーク回線を調達し、サービスを契約すればよい。
提供されているサービスを要求仕様にあわせて利用するための設計・開発は個別に必要である。

インフラストラクチャ費用
サービス利用料（含データアクセスチャージ）
維持管理費用（電気、空調、ネットワーク回線、 ネットワーク回線費用
場所等）
電気代、設置費用（空調システムなど）、場所
サービス料金に含まれる。
利用料、保守費用などを別途計上しておく必要がある。
インフラストラクチャの資産管理は必要であ
インフラストラクチャ資産管理は不要である。
る。
開発、運用時に考慮や対策が必要である。
サービスに含まれるものと含まれないものがあるため、注意が必要である。
契約期間によるが、ハードウェア・ソフトウェ
アとも陳腐化しやすい。

細やかな要件やサービス事業者が保有するシステム性能を超えた要請には対応できない。
契約終了時に蓄積したデータをすべてとりだす場合は、必
要なアクセス時間やアクセスチャージを事前に評価しておく必要がある。
利用する組織の予算上限を超えた場合、データへのアクセ
スが不可能となる可能性がある。

2.3.3. ユーザがクラウドサービス利用時に期待する点
特に会員の視点でクラウドサービスを利用することで効果を期待する事項として、以下のようなものがあった。
・研究・業務に必要な情報のやりとりを場所や時間に関係なくできること
・プロジェクト（組織横断）で研究・業務を自由に設計できること
・リージョンの壁が少なくなり、情報や研究・業務の格差が狭小化できること
・労働時間や場所やデバイスの制約が少なくなり、多様なワークスタイルを実現できること
・現場の技術・運用ノウハウを容易に継承できること
・必要なリソース（人・資金除く）をオンデマンドで利用できること
・法令もしくはカバナンスの観点の対策コストを抑制できること
・Auto Scaling に対応した仕組みであること
・投資に対して保証（犯罪・コスト削減）があること
・クラウドサービス事業者の倒産リスクに対して、対策を講じられること7

3. 大規模・大量データの共有をささえる技術と事例
大規模・大量データの共有をささえる技術と事例について、以下に示す。

3.1. サービス動向
サービスの動向について、以下に示す。

3.1.1. オンラインストレージ（ファイル保管・データ共有）
近年オンラインストレージが急速に普及している。オンラインストレージとは、クラウド上に用意されたストレージを利用者に貸し出し、データのバックアップやファイル共有を行うサービスである。サービスの普及に伴い価格が下がったことで、サーバの運用コスト削減の目的や、台風や地震などの自然災害に対する BCP の施策として導入する個人や企業が増加している。
以下に、個人や企業で導入が進んでいるオンラインストレージの一例を紹介する。
(1) Dropbox
米 Dropbox 社によって運用されている世界最大級のオンラインストレージサービスで、全世界での利用者
数は 5 億人以上である。ブラウザー経由で利用以外にも専用のクライアントソフトを導入することでデスクトップからエクスプローラ等で直接ファイルを操作することも可能になっている。また専用のフォルダに保存したデータが自動でクラウド上に保存されるなど使用者が特別な知識が無くても容易に使えるようになっている。
(2) OneDrive
米 Microsoft 社が提供するオンラインストレージサービスで同社の Office 365 の機能の 1 つとして提供されている。Office のデータを保存先として OneDrive を直接指定することができ、作成したデータファイルを直接クラウド上で保存でき便利になっている。全世界での利用者数は 2 億 5000 万人以上である。
(3) Box
米 Box 社によって提供されている企業向けに特化したオンラインストレージサービスで、利用者数は 4,100万人以上ながら、導入企業数は 8 万 5000 社以上となっており、強固なセキュリティ面から Fortune 500 の約
7 割の企業が利用している。セキュリティ面以外の特長として SSO による外部サービス連携や 120 種類以上の拡張子に対応したプレビュー機能や各種 PC、モバイルデバイスから利用することができ Box とブラウザーがあればどこからでもファイルを閲覧可能になっている。
上記とは別に大手クラウド 4 社が提供しているクラウド上でのオンラインストレージのサービス料金をまとめてみた。サービスの料金は大きく、データ容量・データ転送量・リクエスト量から算出される。
(1) データ容量
データ保管量から算出される。料金は GB 単位で課金され、データが一定量を超えると単価が下がるタイプと固定のタイプがある。
(2) データ転送量
インターネットからクラウドへ送受信するデータ量から算出される。料金は GB 単位で課金され、データが一定量を超えると単価が下がっていく。
(3) リクエスト量
書き込みや読み込みなどストレージに対して行う操作回数から算出される。
一定操作回数（1,000 回、
10,000回）単位で課金される。大きく分けると更新系と参照系で料金が異なり、10,000 回単位での価格は更新系：$0.05、参照系：$0.004 が目安になる。

8

図 1 データ容量に対するコスト

図 2 データ転送量に対するコスト

3.1.2. グループウェア（メール・ドキュメント共有・ファイル共有・スケジュール共有）
グループウェアは組織内の情報共有のためのシステムソフトウェアである。ネットワークに接続されたユーザ間での情報交換や共有、スケジュール管理などの業務に利用され、業務の効率化を目指すもので、最近はクラウ
ドサービスとしての提供により導入・運用のハードルが下がってきている。
(1) Microsoft Office 365
Microsoft 社によって提供される SaaS 型クラウドサービスで、メールおよびスケジュール共有(Exchange
Online)、ファイル共有(SharePoint Online)、オンライン会議(Skype for Business Online)などからなる。
また、従来 PC で幅広く利用されてきた Microsoft Office アプリケーションのライセンスを月・年単位でのサブスクリプション契約ができる。
(2) G Suite
Google 社によって提供されるグループウェアで、メール(Gmail)、スケジュール共有(カレンダー)、ファイル共有(Google ドライブ)、オンライン会議(ハングアウト)からなる。スマートフォンなどから一般的に無償で個人利用されているサービスに対して機能や容量を拡張して提供している。
(3) Indico
CERN で開発された Web ベースの会議支援システムで、会議で使用する資料や参加者の管理、部屋の割り当てなど会議で必要なワークフローが整備されており、会議終了後にそのまま会議記録として保存して参照することができる。ソフトウェアは OSS として公開されており、100 箇所以上の研究機関に導入されている。
9

3.1.3. プロジェクトホスティングサービス
オープンソースソフトウェアの開発者向け機能を提供するホスティングサービスで、コードホスティングの他にソフトウェア開発に必要な、コードレビュー、障害管理システム、wiki 機能が備わっている。
(1) GitHub
GitHub 社が運営しているサービスで、存在するプロジェクトは 8000 万件以上。使用可能なバージョン管理
システムは Git。2018 年 6 月に Microsoft に買収された。
(2) SourceForge
Slashdot Media 社が運営しているサービスで、存在するプロジェクトは 18 万。使用可能なバージョン管理
システムは CVS や Subversion。
3.1.4. 認証サービス
オンプレミスのシステムとクラウドのサービスを併用する場合、利用者のアカウント情報の取り扱いが課題になる。システムやサービス毎に異なるアカウントを使用する場合、利用者視点で考えると別々のアカウントを使い分ける必要があり不便であるし、管理者視点で考えても別々にアカウント情報を管理する必要があり運用コストが増加する。認証サービスとは、認証統合の課題を解決し、利用者、管理者共に負担を軽減し、利便性を向上させるものである。
富士通では、Fujitsu Cloud Service for OSS の 1 機能として認証サービスを提供しており、その機能の特長は以下の通りである。
(1) 利便性の向上（シングルサインオン：SSO）
標準規約に従った認証方式(SAML、OpenID、Connect 1.0)の採用により、他のクラウドサービスと連携し、シングルサインオンシステムが構築できる。
(2) セキュリティリスクの軽減（多要素認証）
生体認証（手のひら静脈・指紋）の利用により、安全な認証システムの構築が可能になる。
(3) ID 管理連携（API を提供）
認証用の ID 情報に関して、ID 管理元からの API の利用により連携可能になる。
(4) 監査と認証のログ取得（API を提供）
セキュリティ監査に必要となるアクセスログ（追跡ログ）を API の利用により取得可能になる。

3.2. ソフトウェア動向
ソフトウェアの動向について、以下に示す。

3.2.1. ファイル共有
パブリッククラウドが提供するサービスに対するセキュリティなどのリスクを考慮して、プライベートクラウ
ドやオンプレミスのシステム上にもオンラインストレージを構築可能である。
(1) ownCloud
Linux, Windows など複数の OS 上でクライアントが動作するファイル共有のオープンソースである。オン
プレミスのサーバやクラウド上の仮想サーバで動作可能で、既存の Active Directory/LDAP と連携できるため、認証サーバで管理されている ID・パスワードで認証をかけることができる。また同期クライアントを利用することにより同期フォルダ内のファイルを自動で ownCloud 上にバックアップすることもできる。その他の機能としては、全文検索、ワークフロー、ファイル暗号化、監査ログなどが備わっている。
(2) Nextcloud
ownCloud の創始者 Frank Karlitscheck 氏と主要開発者が中心となって立ち上げた OSS で細かな違いはあるものの ownCloud の機能を追従して実装している。
(3) GitLab
Git ベースのソースコード管理機能、マージリクエスト、レビュー機能などを備えたオープンソースのソフ
トウェア開発支援環境で、「GitHub」のようなサービスをクローズ環境に独自構築できる。

10

3.2.2. ファイルシステム
本 WG の会員のシステムでは得られたデータを外部の利用者向けに公開している。このため、外部利用者からのダウンロード要求で発生する大量の read 要求を高速に処理できるファイルシステムが必要になる。単一サーバの場合、1 サーバのハードウェア性能（ディスク、ネットワーク、CPU、メモリなど）で限界となるため、複数サーバに要求を並列に分散させる並列ファイルシステムが必要である。更に、1 つのデータを複数のサーバに分散して格納することで、特定のサーバへのアクセス集中を回避することも必要である。代表的な並列ファイルシステ
ムにおいて大量の read 要求を分散処理するための機能を以下に挙げる。
(1) Google File System
システム内に在る Master ノードがファイルデータを記録する Chunk サーバを管理し、クライアントはMaster ノードに問い合わせ、自分がアクセスするファイルデータを記録している Chunk サーバを決める。ファイルデータは複数の Chunk サーバに複製されるため、クライアントはネットワーク上一番近い Chunk サー
バからデータを read することができる。
(2) GlustreFS「Replicated Volume」で構成された場合、複数のサーバの volume にファイルデータの複製を配置することができる。クライアントは DHT（Distributed Hash Table）を使ってどのサーバの volume に配置されているかが分かるため、サーバに問い合わせして早く応答が返ってきたサーバからファイルデータを read する。
(3) Lustre
Lustre 2.11 でサポートされた FLR1(File Level Replication phase 1)の機能でファイルデータの複製を
複数の volume に配置することができる。クライアントは MDS(Meta Data Server)に問い合わせ、ネットワー
ク上近いサーバからファイルデータを read することができる。
上記の他に分散ファイルシステムとして広く使われているソフトウェアを以下に紹介する。
(4) OneFS
Dell EMC 社製ストレージ Isilon 上で動作するファイルシステム。従来のファイルシステム、ボリューム管理、RAID の 3 層を統合し、複数のストレージノードによる単一ファイルシステムを実現している。
拡張性に優れ、運用中にストレージノードを増設することでシームレスに容量を拡張でき、追加後はデータのリバランスを自動的に行う。これによりハードウェア更新を無停止で行える。
(5) BeeGFS
独 Fraunhofer 社が開発したオープンソースの並列分散ファイルシステムで、かつては FhGFS として知られていた。複数のサービスを同一サーバ上で動作させることが可能であり、オンデマンドで動的にファイルシ
ステムを生成する BeeOND も提供している。
(6) SpectrumScale(旧 GPFS)
IBM 社によって提供される並列分散ファイルシステムで、Linux,AIX および Windows で使用することができる。高いスケラビリティを持つとともに、Hadoop や OpenStack への対応や拠点間の同期やキャッシングを行う Active File Management(AFM)機能などを持つ。
データアクセスを分散するためにデータを複製すると、ボリューム破壊等でデータが失われた場合でも正常なボリュームからデータを読み出すことができる。データの複製は冗長面では単純かつ強力な方法であるが、複製先のボリューム数を増やすと保管コストも単純に増える。このためデータを複製するのではなく、Erasure Codingを用いてデータに冗長を持たせているファイルシステムが広まってきている。
Erasure Coding では元のファイルから複数のデータブロックとパリティブロックを作成し、複数のボリュームに分散して格納する。実際にボリュームが故障した場合、残りの正常なデータブロックとパリティブロックから
元データを復元することができる。先に書いた OneFS は Erasure Coding を実装している代表的なファイルシステ
ムである。Erasure Coding は複製と比べて Write 時のコストが少ないのが特徴で、Write 性能を落とさずにシス
テムの可用性を高めることができる。

11

図3

Erasure Coding の仕組み

今後、HPDA（High Performance Data Analytics）分野や AI 分野への HPC 技術を適用し、膨大なデータ解析が今後進んでいくと考えられる。このためクラウドとオンプレミスの長所を活かしたハイブリッドクラウド化が進んでいくと予想され、ストレージ関連各社はハイブリッドクラウド向けの製品を発表している。ハイブリッドク
ラウド向けのファイルシステムの例として以下を挙げる。
(1)Elastifile Cloud File System
Elastifile 社が販売しているハイブリッドクラウド用のファイルシステムで、ベアメタルサーバ、コンテナ、VM のどれからでも同じファイルを参照できる。拠点間でデータ共有する場合、参照先のデータ管理元から拠点のファイルシステム上に動的にデータを転送することにより利用者は特にデータ転送を意識することなくデータを参照することができる。
(2)Weka IO
Weka.IO 社が販売しているファイルシステムでクラウドやオンプレミスの SDS(Software‐Defined Storage)上にあるデータをクライアントに近い SSD に自動転送して利用する。ファイルシステムは Linux コンテナ内で動作させ同一ノード内の他のプロセスから独立させている。VFS 用のドライバが利用でき、POSIX のインターフェイス
を使用することもできる。

3.2.3. オブジェクトストレージ
従来のファイルシステムはデータをディレクトリ構造で管理しているが、オブジェクトストレージはデータをフラットな空間にオブジェクトとして扱う。データは固有の ID を持ち API でアクセスされる。更新や上書きはできず、新規作成と削除となる。
スケラビリティに優れ PB 級に拡張可能で、無停止で可能である。主に Amazon S3 のようなオンラインストレージに利用されており、データ配信やアーカイブ、バックアップに適している。
(1) Ceph
オープンソースの分散オブジェクトストレージソフトウェアで、複数のアクセス方式に対応している。
RADOSGW はオブジェクト単位のアクセスを提供し、RBD はブロック単位、Ceph FS は POSIX 互換のファイル単位のアクセスを可能とする。
モニタと OSD の 2 種類の構成要素を持ち、モニタが Paxos アルゴリズムによりストレージノードへのオブ
ジェクト配置を管理し、OSD がストレージノード上でのデータの読み書きや冗長化を行う。
(2) Scality RING
Scality 社が開発しているオブジェクトストレージソフトウェアで、データを格納するサーバをリング状12に構成し、Chord アルコリズムに基づいて実装している。コネクタサーバを用意することで NFS や CIFS の接続にも対応している。
また、複数のクラウドに跨るデータオブジェクトを一括管理するマルチクラウドデータコントローラーをオープンソース Zenko として公開している(3) minio
米 Minio 社が開発するオープンソースのオブジェクトストレージソフトウェアで、Go 言語で実装されている。Docker コンテナを起動させるだけで Amazon S3 互換のサーバを簡単に構築することができる。
サーバは 1 台でも実行できるが、分散構成も取れるようになっていて、その場合オブジェクトは分散・複製されて保存される。Erasure Coding や Bit rot detection が実装されており、データ故障時にパリティを使ったデータの読出しや、データが読み出せなくなる前に他の場所へと書き込みなおすこともできる。

3.2.4. ブロックチェーン
近年、仮想通貨で使用されているブロックチェーンとは以下で定義されるものである。
(1) 「ビザンチン障害を含む不特定多数のノードを用い、時間の経過とともにその時点の合意が覆る確率が 0 へ収束するプロトコル、またはその実装をブロックチェーンと呼ぶ」(2) 「電子署名とハッシュポインタを使用し、改竄検出が容易なデータ構造を持ち、且つ、該当データをネットワーク上に分散する多数のノードに保持させることで、高可用性及びデータ同一性等を実現する技術を広義のブロックチェーンと呼ぶ」（出典：http://jba-web.jp）
ブロックチェーンは金融、医療、電力等様々な分野で適用されており、主にデータを安全に共有するという用途で多く使われている。データを安全に共有する技術が広まりデータ利活用が進むと、企業や団体が保有しているデータが有効活用され新たな価値が生み出されていくことに期待されている。
本 WG ではブロックチェーン技術を応用したデータ共有サービスとして富士通の Virtuora DX のサービスを取り上げた。
Virtuora DX は、ブロックチェーンの技術を拡張し、外部環境にデータを置くことなく企業間のデータ取引を可能にしている。データを共有したコンソーシアム内では、データの利用者はデータジャケットと言われるデー
タの内容、収集方法、共有条件といったデータの概要情報を参照してそのデータの利用価値を検索することができる。また、データジャケットをテキストマイニングすることにより人が認知できなかったデータのつながりを可視化する機能や、コンソーシアムのメンバー間でコミュニケーションが取れるトークルーム機能があり、メンバー間でのデータを活用した新たなサービスやビジネスの共創の促進への効果に期待している。
詳細は、【B.6. ブロックチェーンで実現するデータ流通・利活用】を参照されたい。

3.3. ハードウェア動向
ハードウェアの動向を以下に示す。

3.3.1. ストレージ技術動向
近年のストレージ技術の動向としては 2 つあり、SCM(Storage Class Memory)と NVMe(Non-Volatile Memory
Express)である。
SCM は、ノードのメインメモリとして使われている DRAM と、主流になりつつある SSD で使用されている NAND
Flash の中間に位置し、DRAM と NAND Flash の「応答性能」と「容量単価」のギャップを埋めるデバイスである。
Intel のコンシューマ向け製品「Intel Optane Memory」に採用された「3D XPoint」や、Everspin の ST-MRAM な
どの高速・大容量の不揮発性メモリデバイスが登場している。従来の 10 倍から 100 倍の応答性を有しており、リアルタイム性が強く求められるような用途で広まっていくと思われる。
また NVMe は Flash などの高速デバイスの性能を最大限に活かすためにマルチ I/O キュー採用や RDMA 対応を行
い、I/O 設計を最適化している。これにより IOPS 40 万（4K ランダムリード）、レイテンシ 100 マイクロ秒という高速な I/O 性能でデバイスにアクセス可能になっている。
詳細は、【B. クラウド時代のデータ共有技術紹介】を参照されたい。

13

3.3.2. 価格容量比率など
本 WG 開催時点での、主要な各記録媒体の特長は以下の通りである。
表 3 媒体の価格容量比率
SSD
HDD
光ディスク
媒体容量
30TB
12TB
3.6TB
最大転送速度>500 MB/s
200 MB/s
360 MB/s
ランダムアクセス〇〇△
マイグレーション周期
5年
5年
>50 年
データ保持期間<10 年
5～10 年
>50 年
消費電力
小
大
小
メディア管理用空調
要
要不要
TB 単価(※)
2.5 万円
4 千円
8 千円（※）調査時点

テープ
12TB(非圧縮)
360 MB/s
×
7～10 年
30 年
小
要
2 千円

3.4. データ転送技術
データ転送技術の詳細について、以下に示す。

3.4.1. ストレージゲートウェイ
クラウドの台頭に伴い、既設のオンプレミス環境とクラウドを繋ぐ技術として「クラウドストレージゲートウ
ェイ」が注目されている。オンプレミス側にクラウドストレージへの入り口を用意しオンプレミスからクラウド
もしくはその逆のデータ移動をシームレスに行うもので、アプライアンスサーバのようなハードウェアとソフト
ウェアが一体化したような製品や Web ブラウザー経由で利用できる製品などが存在する。現在の用途は「クラウドストレージへデータをバックアップする」、もしくは「クラウドストレージ上でデータを共有する」である。
富士通では既存のオンプレミス環境とクラウドとのデータ転送する製品として、Cloud Storage Gateway を販売している。製品の特長は以下の通り。
(1) 汎用的な NAS インターフェイス
クラウドへの接続インターフェイスとして汎用的な NAS インターフェース（NFS/SMB）でアクセスできるため、既存のバックアップソフトウェア等を継続して使うことができる。
(2) 重複排除および圧縮
バックアップ対象のデータ内で重複するデータを取り除き、データ量を削減する。さらに圧縮機能により、重複排除後のデータ自体を小さくする。
(3) データの暗号化及びセキュア通信
クラウドへ転送するデータは AES256 方式にて自動で暗号化してデータを保存する。またクラウドとの接続
は HTTPS によるセキュアな通信により第三者の覗き見を防止する。

3.4.2. 高速データ転送
企業 WAN の現状は以下のような理由で通信トラフィックが増加している。
(1) グローバル化に伴いファイル共有等で国内拠点と海外拠点間など長距離通信が増加(2) SaaS やクラウドサービスの利用に伴い、拠点外への通信トラフィックが増加(3) 災害対策として遠隔地のデータセンターに WAN 経由でのデータバックアップ
通信トラフィックが増加することで離れた拠点間でデータ転送に時間が掛かるようになり、高速にデータ転送を行う技術が注目されている。
富士通では拠点間、拠点-クラウド間の帯域を有効活用し、スループットを向上させる WAN 高速化製品 Smart
Communication Optimizer を販売している。製品の特長は以下の通り。
(1) 独自技術でデータ転送速度の大幅向上
富士通独自のトランスポート高速化技術（特許登録済）により、パケットロスやネットワーク遅延に強い。
(2) 簡単な導入
VMware や KVM といった仮想化基板向けの仮想アプライアンスとして提供し、既存の仮想基板上に VM イメ
14

ージファイルをインポートするだけで簡単に利用できる。
(3) 導入効果の可視化
業務ごとや拠点ごとの往復遅延時間、パケットロス率、スループットを表示でき、製品導入後の効果を確認することが出来る。

3.5. 現在までの大規模・大量データの共有方法と分析
現在までの大規模・多量データの共有方法と分析の実例として、【A. 各委員のシステム紹介】に各委員のシステ
ムや業務を紹介する。

3.5.1. データを配布する側の事例 【A.1. 早戸委員】【東京大学 宇宙線研究所 神岡】
・一般向けデータ公開（O(100GB)）、web base、データベース
・一般向けデータ公開（O(1PB)）、データファイル
・共同研究者向け大規模データ共有
3.5.2. データを配布する側の事例 【A.2. 藤田委員】【宇宙航空研究開発機構 調布】
・一般向けデータ公開（O(100KB)）、web や scp
・一般向けデータ公開（O(～100KB)）、ソースコード
3.5.3. データを配布する側の事例 【A.3. 中村委員】【高エネルギー加速器研究機構】
・一般向けデータ公開（O(100GB)）、解析環境、解析ソフトウェア、ドキュメント
・一般向けデータ公開（O(1PB)）、データファイル
・共同研究者向け大規模データ共有 (O(100 PB))、実験データ、処理済みデータ
3.5.4. データを配布する側の事例 【A.4. 白崎委員】【国立天文台】・一般向けデータ公開（O(1PB)）、観測データファイル
・一般向けデータ公開（O(10TB)）、カタログデータベース
・国立天文台内におけるデータ共有 (O(1PB))
3.5.5. データを受信する側の事例 【A.3. 中村委員】【高エネルギー加速器研究機構】
・共同研究者向け資料共有
・共同研究者向けコード共同開発
・今後の課題 (新しい認証・認可基盤の導入、データの恒久的な保存、データの一般公開)
限られた計算機資源により拡大する総データ量を処理していくために、既存のグリッドサイトだけでなく、HPC
計算センターや、クラウド計算機資源を積極的に利用できる環境が模索されている (eXtreme DataCloud [4])。
これらの計算機資源と分散されたデータを、データレイクなどの新興技術を用いて統一的に取り扱うためには、
現在グリッド基盤で用いられている X.509 証明書のみにもとづいた認証・認可基盤 (AAI) からの脱却が求められる。グリッド認証局の維持とユーザ管理はコストが高いだけでなく、エンドユーザーにとっては X.509 証明書の取り扱いの敷居が高いことも理由となっている。次世代の AAI としては、ユーザが所属する各組織の ID を連携させることによるシングルサインオンの実現 (Federated Identity Management for Research [5]) と、エンドユーザーの利便性を高めるための SAML 認証や OAuth を用いたトークンベースの AAI の採用が候補として検討されている (Authentication and Authorisation for Research and Collaboration [6])。
加速器実験で取得するデータ量は膨大なため、過去に行われた実験データの恒久的なアーカイブを続けるための様々な共同研究が、Data Preservation in High Energy Physics [7] の枠組みにより行われている。大型加速器の運転は電気料金などのコストが高く、同じ目的で再運転することは容易でないため、一度取得したデータを15

将来にわたって再利用できることが望ましい。また、計算機器とその利用技術の進歩や、データ解析手法や理論
物理の発展により、過去に取得したデータの再解析による新発見の可能性も期待されている。これらを実現する
ためには、大量データのアーカイブ技術だけでなく、バーチャルマシンやコンテナを用いたデータ読み出しのためのソフトウェアを含めた計算環境の保全なども必要となる。
加速器実験データの一般公開は、データ量の多さから、配布のために必要なネットワーク帯域幅と、データ処理のために必要な計算能力が膨大となるため、現在では新規参入の研究者をトレーニングする目的、学生の教育
目的、アウトリーチ活動の目的に留まっているのが現状である (CERN Open Data [8])。一方で昨今は、データ解析ソフトウェアなどの使い方を説明する文書を整備するだけでなく、Jupyter などのノートブックツールを用いて、データ解析環境と大量データへのアクセス方法を提供することにより、Web ベースの解析方法を通して、一般の人々が 1 PB 程度のデータにアクセスすることが可能となりつつある。今後は、その規模と簡便性を向上させていくことが課題となっている。

3.5.6. ポリシーやガバナンス事例 【A.5. 渡邉委員】【広島大学】
・共同研究者向け資料共有
・共同研究者向けコード共同開発
クラウドサービスを利用する場合は、クラウド事業者との間に外部委託契約を締結する。このため、クラウド事業者の選定、サービス内容の確認、責任体制の構築等を慎重に行う必要がある。一方、選定基準や確認事項などについては学術機関共通の指標があるわけではなく利用する側で定めておかなければならない。本項ではクラウドサービス利用におけるガイドラインやチェックリストを先行して提供している広島大学の事例を紹介する。
広島大学では、大学が保有している情報（法人文書）の保存先としてクラウドサービスを利用する場合を想定した「広島大学クラウドサービス利用ガイドライン」（以下、ガイドラインという）を策定している。クラウドサービスを利用する際に広島大学として確認すべき項目の解説がされており、チェックリス
トにより広島大学が定める法人文書の重要度の応じたクラウドサービスの利用可否を容易に確認できる資料となっている。クラウドサービスの利用者は導入前にチェックリストの項目を確認し、その結果を指定された部署に提出する。また、利用者は 1 年を超えない期間ごとにその時点で最新のチェックリストの項
目を再確認し提出する。これにより組織的なクラウドサービスの利用状況の把握することに加えて、情報
セキュリティ関連の要求要件とクラウドサービスのセキュリティ対策状況の対応を定期的に見直す方針となっている。
チェックリストでは準備、検討、運用の 3 つのフェーズで確認すべき項目が定められている。以下にチェック項目の一覧を示す。
【準備】

利用に向けた準備（必須確認項目）
 取り扱う情報の確認
 情報の格付け クラウドサービスの選択
 本学の組織・体制
 クラウドサービス利用責任者
 クラウドサービス利用担当者
 規則・契約
 規則との整合性
 契約の取り扱い

16

【検討】






利用範囲の明確化
 サービスの品質
 SLA
 メンテナンス 問い合わせ窓口・サポート体制
 サービスの継続性
 機能とコスト コンピューティング ストレージ ネットワーク 管理機能 ライセンス コスト
クラウド事業者の選定
 データセンター
 データセンターの場所
 堅牢性
 機密性
 クラウド事業者の信頼性
 経営状況の確認
 委託関係の確認
契約条件の確認
 責任範囲とペナルティ 責任範囲の明確化
 クラウド事業者のペナルティ データセンターの所有権、返却・消去
 データの所有権 データの返却
 データの消去
 準拠法と管轄裁判所
 準拠法
 管轄裁判所【運用】


運用体制の確認 システムの運用に関する項目
 セキュリティ対策
 ログの監視 データの管理に関する項目
 秘密鍵の管理
 バックアップ インシデントの管理に関する項目
 インシデントの記録

広島大学では利用に向けた準備の項目を必須確認項目としている。ここではガイドラインの特徴である
情報の格付けとクラウドサービスの選定ついて紹介する。詳細については、「広島大学クラウドサービス
利用ガイドライン」を参照されたい。
17



情報の格付けとクラウドサービスの選定

広島大学の法人文書は、大学の業務に与える影響の大きさに応じて 4 段階の重要度に分類され、重要度ごとに管理方法やアクセス権限が定めてある「表 4 法人文書重要度分類表」。また、ガイドラインでは
クラウドサービスの利用時に満たすべき要件とクラウドサービスの主な機能から 4 段階の信頼度を定義し4 段階の重要度と対応付けることで、法人文書の保存場所としてクラウドサービスの利用する際の基準を容易に確認できる工夫がされている「図 4 クラウドサービス利用基準」。
表 4 法人文書重要度分類表
重要度Ⅳ

重要度Ⅲ

重要度Ⅱ

重要度Ⅰ

区分
法人文書が流出(漏えい)，紛失，改ざん等した場合，本学の業務等に深刻かつ重大な影響を及ぼすもの
法人文書が流出(漏えい)，紛失，改ざん等した場合，本学の業務等に重大な影響を及ぼすもの

文書の種類
特定の関係者以外に対し厳重に機密を保持すべきもの

法人文書が流出(漏えい)，紛失，改ざん等した場合，本学の業務等に軽微な影響を及ぼすもの

公開を前提としていないもの

法人文書が流出(漏えい)，紛失，改ざん等した場合，本学の業務等にほとんど影響を及ぼさないもの

積極的な公開を前提としたもの特定の職制，グループ又は部局等以外に対して機密を保持す
べきもの

18

情報の類型（抜粋）○学籍簿，成績原簿に関する情報○指導要録の情報○医療に関する情報○学生指導に関する情報○卒業論文又は修士論文に関する情報○卒業後の就職・進路先情報
○住所
○氏名
○生年月日
○電話番号
○学術講演会に関する情報○後援名義に関する情報○入試の実施計画に関する情報○公開講座等に関する情報○大学案内や広報誌に掲載している情報○募集要項に掲載している情報クラウドサービスの信頼度
法人文書の重要度

本学におけるクラウドサービスの分類

物理的なハードウェア，

信頼度Ⅳ

信頼度Ⅲ

信頼度Ⅱ

信頼度Ⅰ

信頼度Ⅱ-1

信頼度Ⅰ-1

重要度Ⅳ
重要度Ⅲ
重要度Ⅱ
重要度Ⅰ
信頼度Ⅳ-2
信頼度Ⅳ-1

信頼度Ⅲ-1

信頼度Ⅳ-3

信頼度Ⅲ-2

広大で占用

仮想マシンレベルの独立性の有無

他機関と共用

要件①

広大で占用（1つの部局

独立性の高さや利用グループで占用）
ソフトウェア（ドメイン，Web，DB等）レベルの独立性の有無

広大で占用（複数部局等で共用）
他機関と共用要件

要件②
アクセス制御要件③
通信路の安全性

情報の保存場所への制限あり（F/W，認証等による）アクセス制限の有無

利用場所から情報の保存

制限なし

対策あり

場所までの経路の安全対
策の有無

対策なし

秘密分散
運
用 情報の暗号化
時

個々の情報に対する機密性保護の有無

に

暗号化なし

検
討

異なるDC等に複製ありす
る
要 情報の冗長化
件

暗号化あり

個々の情報の複製の有無と保管場所の選択

同一のDC等に複製あり

複製なし

図 4 クラウドサービス利用基準

このように、データの保管場所としてクラウドサービスを契約する際は、事前に各学術機関で定めているデータに関する管理規則、個人情報や機密情報の取り扱いに関する規則に沿ってクラウドサー
ビスを選定する必要がある。また、クラウドサービスの利用は業務の外部委託と同等と考えるべきであり、各学術機関で定めている業務請負に関する契約基準に準じていることが必要である。なお、クラウド事業者が個人情報等を別の委託先に渡すことがある場合は、取り扱いの承諾と基準を遵守する義務を委託先に負わせることも注意されたい。

3.5.7. 各研究機関の分析
当 WG では、現状を認知するために各研究機関のデータ分析とツール分析を実施した。
「表 5 各研究機関のデータ分析」では、各機関のデータの現状を、「表 6 各研究機関のツール分析」では現有技術を洗い出した。

19

20

広島大学

高エネルギー
加速器研究機構

国立天文台

宇宙航空
研究開発機構

東京大学
宇宙線研究所

北陸先端大

会員様プログラムバイナリ

発表資料（ppt/pdf）

共同研究者

共同研究者

1～100kB

0.1～2GB

1MB～数GB

ファイル(セット)

共同研究者

解析データ

ソフトウェア

共同研究者

生データ

共同研究者

共同研究者

データ

天文台内部

データ

世界中の天文研究者

データ

アプリケーションバイナリ

共同研究者

世界中の天文研究者

ソースコード

共同研究者

ファイルまたはデータセット

ファイル

観測データ

観測データ

テーブル形式データ

ファイル

ファイルセット

ファイル

関係する研究者（公開） 発表資料（ppt/pdf）

データ

0.1～1GB

パッケージ

関係する研究者（公開） 一般公開用バイナリ

O(10GB)

5MBから100MB

0.1～10GB

10MB～1TB

10MB～1TB

1kB～100GB？

～100KB?

100kB

0.1～100MB

1～100kB

関係する研究者（公開） 一般公開用プログラムソース ファイル

0.1～100MB

0.1～100MB

1～10MB

ファイル

ファイル

O(100TB)

O(10PB)

10PB～100PB

O(1PB)

O(1PB)

O(10TB)？

～100KB?

O(1PB)

O(１０TB)

O(０．１PB)

O(1TB)

O(０．１TB)

O(１TB)

O(１０TB)

O(０．１PB)

O(1TB)

O(1PB)

300GB

read only

Read/Write

Read Only

Read Only

Read Only

Write・Read

Read Only

Read/Write

共有単位当たりのサイズ 総ファイル容量 Write・Read か Read Only

パッケージ（VMイメージ？） 0.1～1GB

ファイル

ファイル

ファイル，フォルダ

単位

ファイル

関係する研究者（公開） 公表結果ファイル

研究ノート

プログラムソース

共同研究者

共同研究者

データファイル

共同研究者

共有したいもの

データ，プログラム等

共有したい相手

学内の他ユーザー
学外の共同研究者

http/ftp

rsync/ftp など

更新：ほぼ毎日
アクセス頻度：～1000回/月

更新：ほぼ毎日
アクセス頻度：～数回/日

随時

http

更新：年数回
アクセス頻度：～1000回/月

CVMFS, VM, コンテナ

gridftp, xrootd, httpgridftp, xrootd

リムーバブルメディア

Git

http、tar+scp

http

http

svn, git etc.

http

http

http

svn., git etc.

scp

NextCloud

現状の配布方法

毎年毎日～毎週不定期/季節変動あり

随時

更新・アクセス頻度

大規模実験で行われていることを列挙する。
* グローバルな名前空間とレプリカの所在を示すファイルカタログをグループごとに持っている。
（ファイルの完全性、チェックサム、定義済データセット内のファイルが特定のサイトに揃っているかどうか、転送中かどうかの情報）* ファイルとしてのメタデータだけでなく、ファイルの中身のサマリも付加(事象数など)し保存する。

国立天文台内の異なるプロジェクト間で利用可能な共通データ保存領域。
この保存領域にデータをコピーすることにより、そのデータを取得可能な URL が一意的に定義される。それをキーとして天文台外にデータを配信できる仕組み。（DropBoxに類似）

自由に拡張可能なファイルシステムが必要である。
ディスクを追加するとデータが均等に自動分散されることが理想である。
複数サーバーからの同時アクセスに対しても高いスループットを維持したい。

レコード数が膨大（＞１０億件）に推移した場合においても高速検索を実現したい。

ユーザー管理（輸出管理制限など）が課題である。

セキュリティ(アクセスコントロール)が課題である。

課題はファイルの選別と圧縮に要する人の手間である。
情報の共有者と提供者間のメタデータ（ファイルの位置）管理(共有手法)が課題である。

課題は、indicoは検索できないこと。 Docdbは会議には使いにくいことである。

完全公開であれば hepforgeサイトが存在する。

課題は、indicoは検索できないこと。 Docdbは会議には使いにくいことである。

情報の共有者と提供者間のメタデータ（ファイルの位置）管理(共有手法)が課題である。

課題

集中アクセス回避のために大規模なキャッシュが必要であること、データが大容量であるため転送中の同期の確認が必要であること、データサイズが大きくなると配布が難しくなっていくことが課題である。

課題として、ファイルはテープまたはディスクに存在する。 テープに存在するデータの制御はディスク
データセット単位O(1000) と異なりデータの取り出しに時間を要する。加えて、アクセス集中するとさらに時間を要する。
一方、全データは膨大なため、ディスクに保存できる期間は数か月程度が限界である。

データ取得期間は継続的に転送1MB～1TB

1MB～1TB

1kB～100GB

O(1)

O(10)

O(１００００）

O(1）

O(1)

１～１０００

O(1)

O(1)

O(1）

O(1)

１～１０００１～１０００

1MB～数GB

一回の転送量表 5 各研究機関のデータ分析

21

利用が可能と思われるツール

国立天文台で利用しているツール

加速器実験などで利用されているツール

JAXAのソリューション

会員様

ソフトウェア共有・開発サイト
ソフトウェア共有・開発サイト
一般公開
情報共有
ファイル共有ファイル配布(実行）ファイル共有
解析環境
計算環境
計算環境
計算環境
ソフトウェア管理
計算環境
計算データベース
データ検索インターフェイス
データ検索方法等の世界共通化
ユーザ認証
広域ファイルシステム
ファイル共有サービス
コンテンツ共有サービス
認証基盤

hepforge

githubwebsiteplone

gridftpxrootd

fuse

CVMFS

CERN VM

dockersingularity

gitlab

Vac, Vcycle

BOINC

PostgreSQLなどのリレーショナル DB

Tomcat などのWebコンテナとStruts などのWebアプリケーション
フレームワーク

Virtual Observatory
アクセスツール

OpenLDAP

Gfarm

owncloud/NexTCloud

SharePoint

学認

日本国内のみユーザ認証を行うためのデータベース

検索プロトコル、データフォーマット、ファイル共有方法の天文分野における世界標準

ユーザがデータを検索したり取得したりするための Web インターフェイスを提供

データ越境が課題である。

データ越境が課題である。

整合性判定（検出まで）が必要である。

データ自動修復が必要である。

データ越境が課題である。

シングルサインオンへの移行が必要である。

仕様が複雑かつ、曖昧な部分を含むため、仕様に合致していないサービスが多数存在する。

様々なフレームワークがあり、どれがベストか選択が困難である。

データベースの巨大化により検索時間が長くなる。
複雑な条件式の場合インデックスが利用できなく全件検索となることが課題である。

生成データの信頼性と管理が必要である。

ボランティアコンピューティング
大学等にある小規模クラスタを短い計算単位で利用

大規模研究所では用意している。
それらのアカウント管理、リモートアクセス管理が必要である。

発展途上でノウハウが蓄積されてない。
最新Linux環境でなければ問題がある(setuidなど)

セキュリティに問題

サイズが大きくなりがち。
private/publicクラウド双方とも、deploymentツールと環境が必要である。

完全に一般公開なので、アクセス制限は課題である。

アカウント管理はグローバルな名前空間を提供しない限りエンドユーザーは使えない。
欧米サイトは日本から距離があるため、転送せずにダイレクトにアクセスする方法は使い物にならないことである。

アカウント管理、システム管理の手間である。
ソフトウェアが古い(globusはサポートを中止、CERNは当面サポートする)ことが課題である。

アカウント管理、site管理の手間、セキュリティ、ソフトウェアの遅さが課題である。

site管理の手間、CMSの場合はセキュリティが課題である。

アカウント管理が課題である。

アカウント管理（グループアカウントを用いて利用している模様）

ファイルのコンテンツを検索できないことが課題である。

主にUKで使われている。

カタログデータの格納、観測データのメタデータを格納

課題

報告ではない、議論を行える臨場感の実現することが課題である。

I/O速度性能とのトレードオフであることが課題である。

VM

大規模研究所では用意しているコンテナ（USのHPC分野で発展）

コンテナ

ユーザ端末: Virtualbox, VMware, Hyper-V, Xen, KVM, VAGrant
クラウド: OpenStack, Amazon, MS Azure, Google

vmを一般公開して共有契約して実験グループとして利用することがある

ソフトウェアの完全公開には利用可能

ファイルを共有する

輸出規制

ファイル共有docdb

会議の議事に従って発表資料などをおくことができる

高速ファイル転送ソフト

会議支援ツール

indico

地球観測データや宇宙探査データを興味を持っている人(場合によっては不特定多数)に配布する

離れた場所同士で同じシミュレーション結果を共有しながら議論を行う

CPUの利用は行われている

データ配布

Web

詳細
Cloudコンピューティングのためのデータ共有ツールとして

AWS、Azure

ディスカッション

遠隔データ共有

目的

VR/AR/MR

ファイルシステム/レプリカ機能

テクノロジー

Push型配布技術

期待する技術・トレンド

表 6 各研究機関のツール分析

4. クラウド時代のデータ共有技術における課題(受容も含む)
本 WG の議論を通して、クラウド利用は、一般的にはコスト低減やインフラ調達期間の短縮などのメリットがあるという認識が得られた。一方で、特にセキュリティや事業者の継続性に関するリスク、ネットワーク帯域やア
クセスチャージなどの付帯コスト、既存システムとの連携や障害対応などにおいて十分留意する必要があることも明らかになった。特に、本 WG のメンバーが扱うような 100 億ファイルや 10PB を超えるような大規模なデータ共有については、一般的に提供されているサービスとしては想定されていない点もあり、クラウドサービス提供
者との綿密な調整が必要である。
また、現状のデータ共有の課題は二種類にわけられることがわかった。一つは、データへのアクセスに直接関係する課題、もう一つがデータへのアクセス許可など、認証やセキュリティに関連する課題である。以下では本WG で特に重要であると認識された課題について概説する。

4.1. データへのアクセス方法
クラウド利用を検討するにあたっては、まずデータへのアクセス単位やその方法と転送速度、反応速度などの性能をよく把握する必要がある。データファイルが大量数存在する場合や、ファイルが大量である場合、データ
ベースのような細かいアクセスがある場合においても、要求性能が満たされ、かつ、利用量の上限がある程度予想できるケースはクラウドサービスも十分利用可能であると考えられる。一般にクラウドサービスはスケーリン
グしやすさが利点とされるが、規模拡大はサービス利用料の増加にもつながるため、適用事例がスケーリング可能かどうかについても事前の検討が必要である。事例によっては、オンプレミスのシステムを用いる方が、コストと性能のバランスをとりやすい場合もあるように見受けられた。

4.1.1. 検討しておくべきデータアクセス性能に対する要請
データへのアクセス単位としては、おおまかに、データベースソフトウェアからのアクセス（検索など）と、通常のソフトウェアからのファイル単位のアクセスに二分できると考えられる。また、ファイル単位の場合は、シーケンシャルアクセスとランダムアクセスに大別される。
以下、いくつかのパターンについて、検討しておくべき性能への要請を列記する。
 DB のようなアクセスの場合：時間当たりに処理するリクエスト数を見極める必要がある
 大容量データファイル転送の場合：一回の要求に対し、「どの程度の時間が許容されるか」、「どの程度の転送速度が必要となるか」、「多重転送による高速化が必要か」、「帯域制限は必要か」、などを見極める必要がある。
 多数のファイル転送の場合：転送開始までにどの程度の時間が許容されるのか、一回の要求で転送が必要となるファイルサイズ、ファイル数、そして転送完了までの許容時間を見極める必要がある。
 ランダムアクセスの場合：データファイルが利用可能になるまでの許容時間、アクセスパターン（単一ファイルへのアクセスが続くのか、複数のファイルへのランダムなアクセスなのか）、データ要求からデータが実際に届くまでのレイテンシはどの程度まで許容されるのかを見極める必要がある。ファイルの中に複数のオブジェクトを有している場合（見た目ファイルであるが中身は DB のようなアクセス）について、アクセスパ
ターンが特殊である可能性があるので、注意が必要である、
4.1.2. アクセス方法に対する要請
・アクセスの手段（http/https/REST、Box、専用 API）
用いるアクセスの手段を把握しておく必要がある。クラウドでは http/https/REST などが主流である
 http/https/REST の場合：認証・セキュリティ、アクセス履歴（証跡）などの情報について、利用者がどの程度管理、把握できるか事前に確認する必要がある
 Box/専用 API（VO ツール）の場合：データに適切な ACL を付与するルールや運用(デフォルトの動作設定)などを検討する必要がある。
 オンプレミスでは、ファイルシステムの直接利用（マウント）やオブジェクトへの直接アクセス(オブジェク
トストレージ)が主流である。
 ファイルシステムの直接利用の場合：CIFS、Lustre、SMB、NFS などファイルアクセスとしてディレクトリ参照の重要性の確認が必要である
 オブジェクトの場合：ceph などのアクセス方法が必要か、上位にファイルシステムを介在させて利用するか
22

なども検討しておく必要がある。

4.2. データ移動量（オンプレミス→クラウド、クラウド→オンプレミス）に対する要請
予算の増加が許容される場合は、クラウドへの移動を検討することは比較的容易となる。年間の予算に上限が設定されているケースはデータ移動量を制御する仕組みも必要となるであろう。ローカル（オンプレミス）からクラウドへのデータ移動が安定していない場合にローカルのストレージがあふれてしまうような可能性についても考慮しておく必要があるだろう。

4.2.1. 課金システム（データ総容量、アクセス頻度、アクセス制限）について・クラウド業者側でのサーバ設置場所によって使用料金が異なるケースがある。
国外の場合、サーバ設置場所によって、データ転送速度、レイテンシが異なる可能性もあるため、留意が必要であろう。
（適用法令についても留意が必要。
）
・課金の種類 クラウドストレージのストレージ領域（データ保存領域）に対する課金
 ディレクトリ単位やユーザ単位で上限設定ができるかどうかについても必要性を考慮しておく必要があると考えられる。
 特にユーザにストレージ領域への書き込みを許可する場合、蓄積を承認する仕組みも必要であろう。
 重複するデータを排除する機構が必要となる可能性もある。
 クラウドストレージの入出力のためのデータ転送(データ通信容量)に対する課金
 データを蓄積するための課金はないことが多いが、確認が必要である。
 データアクセス（読み出し）に対する課金がある場合が多く、アクセス量の見積が必要である。
 データアクセス量などに対する制限が必要かどうか、検討が必要であろう。
 アクセス制限においては、ユーザ認証との連携が必要となる可能性もある。
 大規模な読み出しを制限するなどの対策も必要であろう。
 レイテンシ要求（ｍｓ）
 レイテンシ要請によりサービス価格が異なる場合があり、必要性能の事前検討が必要となる。
 アクセスコスト（高速回線代金）、ユーザ数、データ回収（システム移行）費用など
 クラウドベンダまでの回線経費
 クラウドベンダ内での接続について、接続速度によって料金が異なる場合があることに留意する。
 アカウント（利用者）数で課金されるサービスの場合、利用者数の見積も必要となる。
 契約終了時、他システムにデータをコピーする必要があるかどうか、検討しておく必要がある。
 契約終了時に必要となるデータ転送量を用いて、必要となる経費を事前に見積もる必要がある。
 契約終了時に必要となるデータ転送時間を見積る必要がある。
（必要な帯域の検討も必要であろう。
）
4.2.2. 調達フェーズと運用フェーズにおいて検討する必要のある事項
・調達フェーズ クラウドサービス採用の利点
 特にストレージと同時に CPU なども同一のクラウドサービスプロバイダから提供を受ける場合、突発的な需要増に対応が容易となるため、クラウドを利活用することには大きなメリットがある。
 期間が短いプロジェクトにおいては、ほぼオンデマンドで調達できるため、無駄な時間を費やす必
要がなくなる。
 小さい規模で開始し、将来的に規模を拡大する可能性があるプロジェクトにおいては、初期評価という観点でもクラウドサービスを用いて開始、クラウドサービスの利用を継続するか、オンプレミスに移行するかを検討する。このことが有用であろうと考えられる。
 既存のシステムからの移行の場合、各ベンダが提供しているサービス（ERP、CRM、勤怠など）も併用できる可能性があり、業務の統合が進む可能性がある。一方で、個人情報の保護などセキュリテ
ィ担保等の条件が満たされるかについては注意深い検討が必要である。また、それまでの業務プロ
セスに変更が必要となる可能性が高いため、これを受容できるかどうかについても検討が必要とな
る。
23



クラウドサービス採用の留意点
 業務プロセスやシステムにおいて、ハード・ソフト（ライセンス契約含む）の規模を随時スケールさせることを前提にしなければ、クラウド本来の利点を活かしきることができない。これは、利用状況に応じた、比較的頻繁なサイジング再設計が必要となる可能性もある。再設計を適宜実施しない場合には、利点の一つであるコストの最適化につながらない。
 クラウドストレージへのデータの入出力においては、とくに取り出しに課金がかかる場合があることに留意しておく必要がある。コールドストレージ（バックアップ）として利用する場合にはあまり問題にならないと思われるが、この場合でも、蓄積した全データを読み出す可能性がある場合には、読み出しに要する時間（ネットワーク帯域）と費用を見積もっておくことが重要である。
 クラウドストレージからのデータ読み出しが大量かつ頻繁となる場合には、性能的に要請を満たす
か、料金が想定を大幅に超えることがないかなどに留意する。また、想定外のアクセスがあった場合に追加負担が可能か、利用制限が可能かなどを事前に検討しておく必要がある。不必要、もしくは不正なアクセスによるコスト負担増加の可能性もあることにも留意が必要であろう。
 クラウドストレージとの通信は回線帯域や利用状況に依存するため、性能評価時にはこれを考慮に入れておく必要がある。
 オンプレミスシステム採用の利点
 オンプレミスシステムを採用する一番大きな利点はカスタマイズ性の高さであろう。データアクセ
スに特別な要請がある場合や、既設システムへの接続、稼働中のシステムからの継続性などにおいては、クラウドサービスへの移行は大きな負担となる可能性がある。
 たとえば一定規模以上のストレージの場合は、トータルコストがクラウドサービスを上回らない場
合も多いようである。
 一般的にデータ発生元、データ利用のリソースに近接してストレージを設置することができるため、レイテンシの短さが要請される場合や、高速アクセスが必要な用途に適している。
 性能改善のためシステム全体を通したチューニングなども可能である。
 データの入出力に対して課金されることは通常ないため、アクセスが予想よりも多かった場合などにもコストの増加を気にする必要がない。
 オンプレミスシステム採用時の留意点
 調達に期間を要し、また、導入した機器を一定期間は利用しなければならないため、必要なリソースを精査し、調達時にシステム設計を入念に行うことが必須となる。
 調達した機器は、利用完了時までには時代遅れとなっている可能性があること、新たに出現した機材を追加導入することも難しいことを理解しておく必要がある。
 ストレージの調達の場合、一定期間後に容量を追加する方がコストの削減になる場合もあるが、契約方法、期間によっては当初から一括で調達してもあまり変わらない場合もある。
 運用中の大幅なシステム構成の変更は現状では難しい。ただし、今後はプライベートクラウド環境をオンプレミスシステム上に構築することで、構成変更を容易にすることができるかもしれない。
・運用フェーズ クラウドサービス、オンプレミスシステムともに、稼働率や定常的な性能(通信・IOPS・ストリーム性能)の監視を行い、資産を十分に利活用する努力は必要である。特に、利用統計情報を適切に採取できない場合、無駄なコストが発生する可能性もあるため、注意が必要である。
 契約順守状況の確認は重要である。オンプレミスやクラウド事業者の変更時などに注意が必要である。 監査
手法の確立などの取り決めを事前に実施しない場合、オンプレミスやクラウド事業者が提供するサービスレ
ベルの妥当性について、調達者は判断することが困難となる。

4.3. データ共有にかかるリスク対応
法令に準拠した信頼できるコンピューティング環境を構築するには、「コンプライアンス」
「機密性」
「安全性」
「ガバナンス」「データのリスク管理」を少なくとも満たす必要があり、検討すべき項目を 4 点あげた。

24

4.3.1. ガバナンス・コンプライアンス・国際法律
・GDPR は遵守しないと罰金が科される可能性もある。データをクラウドサービスに移動することは、様々な地域へのレプリケーションの可能性があり、この GDPR の順守を考えなければならない。
・クラウドストレージに蓄えるデータがどのような種類のものか（個人情報などを含むのか、機密情報などを含むのか）、利用者の立場として貴重（失うことができないもの）か、再生成（再コピー）可能なものか、無期限で保存すべきものか、一定時間経過後に抹消すべきものか、管理責任があるものか、管理義務がないものか、など
について、すべてのデータについて、明確にラベリングすることが必要となる可能性もある。
・運用段階では、実際に提供されているサービスレベル品質や、事業者側のインシデント対応状況を利用者がモ
ニタリングすることが重要である。利用者のデータがクラウド上の複数のサーバ上に保存されているケースでインシデントが発生した場合に、クラウドサービス提供者がどこまで調査を実施するか、情報提供を行うかなど、
事前の確認が必須であろう。
4.3.2. 連携する両者のポリシー整合性
・データ提供元⇔データ活用先
 データがどこにあるのか、また、どのようにアクセスできるのか、という情報を共有することが必要となっている。ここには、アクセスへの許諾申請方法や具体的なアクセス方法などの情報が必要となる。また、検索機能を必要とする場合は、メタデータの生成も必要となる。
 特にクラウドサービスを利用してデータを公開する場合、必要リソースやアクセスコストの評価のために、データへのアクセス頻度、アクセス量などといった情報だけでなく、データがどのように活用されているか、
そのアクセスパターン（時期、時間帯）や用いられているアクセス方法などを把握しておく必要があり、これらを理解するための可視化も重要となっている。
・データ提供元⇔データ格納先
 技術的なセキュリティが保証されない部分に関しては、契約約款や SLA の内容をクラウド事業者と詰めておく必要があるが、事業者によっては約款や SLA の変更に応じないケースもあるため、注意が必要である。
 クラウドサービス導入が不可能である可能性もある。
 これらを踏まえ契約関連で利用者が留意すべき事項の事例(広島大)にも示した。
 利用状況は常時確認し、必要に応じて設定やリソースの契約を変更することが必須である。
 適切に行わない場合、データ提供元は予期しない金銭的負担を強いられる可能性がある。
 期間限定で公開をしていたサーバの利用終了手続きを怠ると、いつまでも課金される。
 リソース利用量に制限をかけない場合、想定額以上の資金が必要となる可能性もある。
4.3.3. 認証・証跡
・認証・証跡 直接アクセスするユーザ、直接アクセスしたユーザからデータを参照する（プロジェクトとしてアクセスするケース）グループを識別できる仕組みが必要となる。
 大学や研究機関のルールに即した使い方ができているか。調査して維持する仕組みの検討が必要である。
 内部統制において、クラウド特性を考慮した監査基準が確立されているか確認することが必須である。
 国際的なプロジェクトの場合、該否判定の書類審査などが存在する場合、本格利用までの準備期間が必要になることを念頭におく必要もある。
4.3.4. データ保護・アクセス権限・特権 ID
・データ保護 データを削除した際に、各地に保存されたすべてのデータが削除されないと、データの不正利用につながる恐れや保護法を守れない恐れがある。
 流出が問題となるデータの保存においては、クラウド上のデータが暗号化されているかどうかを確認する必要がある。
 Dropbox などは自動的に暗号化している。
 暗号化されていないサービスの場合、事前に暗号化するなどの対策を利用者側で行うことも検討する必要がある。
 利用者が暗号化する場合は、暗号化キーの管理が課題となるであろう。KMIP（Key Management
25





Interoperability Protocol）のような暗号鍵管理プロトコルを用いて暗号化システム間を接続する可能性なども検討に値するであろう。
保存時だけでなく、データ転送時のセキュリティについても考える必要がある。
 データ転送中のセキュリティは、クラウドサービスへの通信方法、ユーザの用意した回線、クラウド事業者のネットワークのセキュリティなどに依存する。
 保存中のデータ盗聴保護はデータの暗号化などによって実現することが可能となる。
保存したデータが正しく読み出せているか確認する仕組みが必要である。
 データが破損していないか、改ざんされていないかなどをチェックする機構は一般的なサービスは持たないので、利用者側で必要性や実現手法の検討が必要であろう。

・アクセス権限・特権 ID
 権限において、最重要データはオペレーションでも削除できない仕組みが必要（データ改ざん防止） 変更履歴の取得が可能であるかについても確認しておく必要がある。
 運用者へのアクセス権限において、運用者の転職などを考慮したルール策定が必要（データ改ざん防止）

4.4. データ共有時の利便性や管理の容易さを向上させる技術
データの管理や利活用にあたっては、データの種別わけが重要である。この情報がファイルに付随していることで、正しい保存場所、保存方法を選択することが可能となるだけばかりなく、クラウドサービス利用の可否や、サービス選定時に求められるセキュリティ要件などを検討するときに重要な情報となる。
データの種別わけ自体は利用者に依存してしまうが、この種別わけの結果をデータとあわせて管理する方法については複数あり、実装例を以下に示す。

4.4.1. データへのタグ付け（LOD、データジャケット、メタデータ）、VPX
・データのラベリングについて、これを実現する技術としては以下のようなものがある。
 LOD（Linked Object Data）
 データジャケット
 IVOA(天文分野)
 VPX（ブロックチェーン技術の応用）
 ハッシュタグ
・メタデータとして必要となる可能性のある情報としては以下のようなものがある。
 データの生成日時
 データの生成場所
 データの種類
 データを所有者(権利者)、これを保証(認証)する組織（もしくは人） データの公開範囲（無制限、関係者のみ）
 データの有効期間
 データの再利用可否
 データの加工の可否
 データの再配布の可否
 データのチェックサム（破損・改竄確認）
 データの正当性保証情報（電子署名など）

26

5. データ共有技術におけるオンプレミス・クラウド利用に向けたチェックリスト
本 WG においてシステム間の大規模な「データ共有」においてクラウドサービスの利用を検討するとき、各機関に共通して次のような懸念が存在することが確認された。
・第三者が提供するクラウドサービスに任せることやベンダロックインへの懸念
・実効帯域やストリーム性能やレスポンス性能への懸念
・不正アクセス・改ざん・情報漏えいなど情報セキュリティに関する懸念
・第三者のクラウドサービスのシステムや運用の可視化やポリシー定義などの責任分界点への懸念
これらの懸念はオンプレミスのシステムにおいても同様であり、事前に当事者間で基準について共通の認識を持つことが重要であるとの結論に至った。
また、クラウドサービスは個人から企業向けまで目的に応じたサービスが存在しており、利用を検討するときに留意すべき点を明確化しておく必要があるということも明らかになった。
一般的なクラウドサービスの導入にあたっては、国立情報学研究所が導入支援サービスを実施するにあたって作成した資料（https://cloud.gakunin.jp/ass/ で提供される）が大変有用である。一方で、データ共有という視点に限った場合には、この資料では若干使いにくいため、本 WG における議論を踏まえ、チェックリストを作ることとした。
以下に掲載するチェックリストは、「データ共有」というカテゴリにおいて、オンプレミス・クラウドの適応を判断する情報システム担当者が、効率的かつ網羅的に検討を行うことができることを目指して作成した。
実際の導入にあたっては、前述の国情研の資料なども参照の上、ここに掲載されていない項目についても確認しておく必要がある点に留意していただきたい。

5.1. 共有データ種別・目的・方法「データ共有」という観点から、比較的小さいサイズのデータを一般公開する場合、期間を設けて共有する場合、オフィス文書などを共有する場合は、クラウドサービスの利用が適している可能性が高い。一方で、特殊なアクセス方法等が必要な場合は、カスタマイズ性の観点からオンプレミスとせざるを得ないケースもある。さらに、
データ総容量が 1PB を超えるような場合、容量単価はオンプレミスシステムの方が安くなる可能性がある。また、
クラウド上のデータの移行に時間やコストがかかる可能性があることもあり、オンプレミスでシステムを構築する方が適している可能性が高い。

5.1.1. データ種別
・ドキュメントファイル（文書、画像など）の共有では、専用のクラウドサービスが提供されており、アクセス
手法（API）、アクセス制限、セキュリティなどについて要請を満たす場合は、クラウドサービスを用いたほうが利便性は高くなると考えられる。
 失うことができない貴重なデータについては、クラウドサービスのみにデータを置くことは大きな危険が伴う。逆に、データセットのレプリカを置く場所として利用するのであれば、検討に値する。
 サービス契約完了時に消去可能な場合は、クラウドサービスに置くことも検討に値する。
5.1.2. データアクセス
・インターフェイス ベンダが提供するサービスをそのまま利用可能なケース（http/https、REST API など）や、試験的に情報共有するケースにおいては、クラウドサービス利用が検討に値する。
ファイルシステムとしてマウントしたい場合、既存システムとの連携が必須となる場合などは、オンプレミ
スシステムの利用の方が適している可能性が高い。

27

5.1.3. 総データ量
・容量が大きい（数百 TB 以上）場合、オンプレミスシステムの方がコスト面で有利になる可能性が高い。
・ファイル数が多い（数億以上）場合などついても、オンプレミスシステムの方が有利になる可能性がある。
・契約期間内（５年程度）の容量増加と総容量が見通せる場合は、クラウドサービスの必要経費が正確に計算できるが、見通せない場合はオンプレミスとクラウドサービスのどちらが良いかの判断が難しくなる。
5.1.4. データアクセス量
・データへのアクセスに課金されないサービス（オフィス文書共有など）については、クラウドサービスを利用しやすいと考えられる。
・データへのアクセスに課金されるストレージサービスについては、アクセス量についても見積もりが必須となる。大量の読み出しアクセスが発生する可能性が高い場合は、オンプレミスシステムが無難であろう。

5.2. 可用性
データ共有を行うにあたり、可能な限り常時アクセスしたいという要望があると考えられる。また、運用シス
テムの稼働が困難になった場合、どの程度の期間でこれを再開できるか、という観点からの検討も必要であると考えられる。これらについて、３点の確認項目にまとめた。

5.2.1. サービス時間（計画的、事前通知、サービス終了リスク）
・計画されたサービスの定期保守頻度および総時間（１年あたり）を確認する。
・計画停止において、事前停止通知日（期間）を確認する。
・サービス終了の事前通知期間を確認する。
（サービス移行に要する時間の検討も別途必要である。
）
5.2.2. 稼働率・継続性・稼働率の定義と保証される条件を確認する。
稼働実績などは実稼働状況が確認できる無料オンラインサービス(CloudSquare Service Status)などを用いて調べることもできる。
・突然の停止時の措置（対応）を確認・検討する。
・重大障害時の代替方法を確認・検討する。
5.2.3. ディザスタリカバリ
・災害時のシステム復旧体制の有無と内容を確認する。
・別システムもしくはサービスに移行する必要が出た場合、運用ノウハウや資産を継承できるかを確認する。
・特に失うことのできないデータについては、多重化などが可能かについて確認する。

5.3. システム管理・監視
データ共有システムを利用するにあたって、クラウドサービスにおいては、一般的にサービス利用者が実施可
能なオペレーションやアクセス可能なログが制限される。必要なオペレーションやログ監視が可能かどうかについて、２つの確認項目にまとめた。

5.3.1. リソース管理オペレーション
・サーバ、ブロックストレージ、ネットワークのリソース制御の API(CLI,SDK,Console など)仕組みについて確認する。
5.3.2. システム監視（ログへのアクセス）
・以下のログにアクセスすることが可能か確認する (データ）アクセスログ、改変ログ
 ロードアベレージ、パフォーマンスログ
 システム警告・エラーログ
28

5.3.3. システム運用
・セキュリティ確保のため、情報レベルなどを細かく規定した運用を実施したい場合は注意深い検討が必要である。オンプレミスが最初の候補になると考えられるが、最近は比較的機密度の高い情報についてもクラウドサー
ビスを利用する広島大学などの事例もあり、不可能なわけではない。

5.4. 性能
近年、民間企業などにおいても、大容量、高スループットのストレージ・データ共有システムが必要となってきており、本 WG のメンバーが求めるシステムに近い規模・性能のシステムをクラウドサービス上に構築するケースも出てきている。たとえば、スマートフォンからの利用を想定した場合、1 ユーザあたり 5GB 程度の容量を 7500
万ユーザに提供すれば、総容量として 400PB が必要となる。帯域としては 10%のユーザが 0.5MB/s の帯域を同時にアクセスすると仮定すれば 4TB/s 程度の帯域が必要となる。これらを実現できるクラウドサービスは、十分検討に値すると考えられる。性能については以下に３つの確認項目としてまとめた。

5.4.1. スループット性能
・実効帯域
 回線帯域などを鑑みれば、10GB/s 以上が必要であるならば、オンプレミスとする必要があるであろう。
 逆に、100MB/s でよければ、クラウドサービスは十分検討に値すると思われる。
・更新増量
 回線・転送速度を鑑みるに、平均で数 TB/日で継続的にデータを蓄積する場合は、オンプレミスが適していると考えられる。
逆に 500GB/日程度以下であれば、クラウドサービスの利用が検討できると考えられる。
5.4.2. レスポンス性能
・RTT
 10ms 以下のレスポンスタイムが必須であるならば、オンプレミスを選択すべきと考えられる。
 これ以上であれば、クラウドサービスの利用が可能であろう。
NII学術情報基盤オープンフォーラム2015の資料によれば、１か月平均では 10～40ms とのことである。
5.4.3. 処理能力【件数】
・Query 数
 RTT とあわせて確認が必要である。
クラウドサービスにおいても利用サーバ数を増やすことなどで処理件数を増やすことは可能であると考えられるが、コストにも影響するため、注意が必要である。

5.5. データ管理
クラウドサービスを利用する場合、データの移行や取り出しについて留意が必要である。また、データを消失させない、漏えいさせないといった観点からの検討も必要となる。

5.5.1. データ移行方法
・データ移行手法 現有データを新システムに移行するために必用な帯域、時間、コストの見積りを行うことは必須である。ク
ラウドの場合、ネットワーク経由となるケースが多いが、テープやディスクなどの持ち込みなど、他の方法が提供されている場合もあるため、確認が必要である。
5.5.1. バックアップ（容量、バックアップ時間、保存期間）
・バックアップ方法
 オンプレミスシステムにマスターをおき、クラウドをバックアップとして利用するケース。
 クラウド上のシステムからオンプレミスに必要なバックアップをとるケース。こちらは、クラウド上の全フ29ァイルリスト取得が容易でない可能性などがあるため、事前の確認が重要。
 オンプレミスシステム内にスナップショット機能やテープ装置などバックアップ機能を持った機材を導入するケースは最も伝統的である。
・バックアップ時間
 数十 TB/月以下であれば、一般的なクラウドサービスでも転送速度的には問題ないと考えられる。
 バックアップデータ量が大量となる場合、読み出しコストがかかるクラウドサービスではコストが大きくな
りすぎる可能性があるため、注意が必要。
・保存期間
 ディスクストレージはハードウェアの寿命と世代交代を考えると５年程度での入れ替えが必要となる。オン
プレミスシステムでは、この程度以下の頻度で入れ替えが必要と考えられる。
クラウドサービスでは、容量単価・アクセス単価は今後下がってゆくと考えられるため、契約期間や契約単価を随時見直す必要があることに留意し、これを考慮に入れた契約とする必要がある。

5.5.2. データ消去（ポータビリティ/委託）
・データ消去(データを破壊する) データ格納機材の物理的な破壊や目視を併用した RAID 構成破壊など、完全なデータ消去が必要な場合、オン
プレミスとする方が無難であろう。
 データの完全消去が必要な場合、たとえば米国政府は National Industrial Security Program（NISP）の1995 年版のオペレーティングマニュアル DoD 5220.22-M などに記されており、「全てのマッピング可能なセ
クタに何らかの文字で上書きを行った後、その補数の文字で上書きを行い、さらにランダムな文字コードで上書き処理を行う」という手法の実施を推奨している。こういったレベルの対応が可能かどうかについて、
サービス提供者に確認する必要がある。
 データ消去を電子的に証明して、その証明書を電子的に発行する仕組みがある（日本では CSAJ など）ため、これを利用することができるかについても検討が必要であろう。
クラウドサービス提供者はデータ消去に関する規定を持っている場合が多い。一方で、この要件が必須となる場合は、これが順守されているかなどの精査も必要かと思われる。
5.5.3. 暗号化（データ漏えい対策、データ破損・改ざん検知）・暗号化
 記録時に暗号化を実施することで、漏えい対策になるほか、復号時にデータの破損や改ざん検知などを行うことも可能となる。
 オンプレミスで利用可能な技術は複数提供されているが、アクセス性能の劣化が許容範囲かどうかを確認する必要があるであろう。
 クラウドサービスで、クラウド上のストレージでデータを暗号化しているものもある。ただし、利用者はこれを認識しないで利用するものが大半である。
 クラウド上のストレージを利用する場合、データ転送時に暗号化、復号化を実施するストレージゲートウェ
イなどの機材の利用も検討する価値があるだろう。

5.6. セキュリティ
クラウドサービス提供者が提示するセキュリティの基準で要件が満たされる場合は、クラウドを優先的に検討してもよいであろう。一方で、セキュリティに対する要件が厳しい場合、複雑な場合は必然的にオンプレミスシ
ステムの採用とならざるを得ないケースも残ってしまう。

5.6.1. ユーザ管理・認証
生涯 ID、SSO、ID・パスワード自動再発行、プロジェクトをキーとした管理、LDAP 連携、Active Directory 連
携 、デバイス認証、二要素認証、フェデレーション認証、アプリケーションのアサイン、一定期間アクセスがない場合のロック、スタッフからの流出を防ぐ機能などが必要と考えられる。
・ユーザ管理 ローカルの認証に加え LDAP 連携など、従来の管理方法を継続したいケースでは、クラウドサービスとの連携
30

がとれない場合もあるため、オンプレミスシステム利用が必須となってしまう可能性がある。
クラウドサービスとの連携が可能な IDaaS(SKUID、１Password、RoboForm、Onelogin、CloudGate UNO、Azure
Active Directory)を利活用できるケースもある。ただし、アカウント単位の課金となる可能性もあり、ユー
ザ数、コスト負担を行うものの確定などが必要となる。

5.6.2. 証跡・データ保護
・証跡の必要性 詳細な証跡監視・管理が必要でない場合は、クラウドサービスを利用しやすいであろう。
 最近のクラウドサービスでは、多量、大規模な領域に対して「いつ、だれが（どこから、何をつかって）、だ
れと（どこから、何をつかって）、どのようなコンテンツ、何ＧＢまで」を共有したか長期間にわたり記録する仕組みを持つものもある。
 逆に、米国防総省が規定したセキュリティ基準 TCSEC（Trusted Computer System Evaluation Criteria）のセキュリティ要件を満たした OS やファイルシステムの機能が必要なケースについては、クラウドサービスの利用は困難な可能性が高い。通信回線などの安全性担保なども含めて注意深い検討が必要となる。
・データ保護 クラウドサービスにおいて予期しないデータ損失が発生した事例も過去に複数存在し、データのリカバリーはできていない。このため、データが失われる可能性を想定に入れた導入は重要であろう。
 クラウドサービスにおいて、レプリケーションのサービスを有している事業者も多いので、これらの併用検討は重要である。
 オンプレミスシステムにおいても、災害などでデータが失われてしまう可能性は十分にある。バックアップ
先として、ストレージが地理的にも離れているクラウドサービスを利用することは、安全性担保、事業継続性担保という観点から有用である。
 大規模ストレージシステムにおいては、いつのまにかデータの一部が破損する事故（Silent Data Corruption）の発生が問題となっている。オンプレミスシステムでは、ハードウェア機材の機能、OS（ファイルシステム）の機能で検出することも検討する必要があるだろう。クラウドサービスでは、どこまで保証されているか、
一般的には不明のため、これらが問題となる場合は記録データのチェックサム（ダイジェスト）の取得・記録・比較を行うことも検討すべきであろう。
・改ざん防止（誰かが書き換えていないか） 改ざん防止対策が必須である場合、オンプレミスシステムにおいて、データ生成直後に改ざん防止のコード(電子透かし)など埋め込むなど、独自のガイドラインを構築する必要があるであろう。
「Tripwire」や「AIDE」など改ざん防止手法を利用する方法、独自のデータフォーマットを用いてデータ改ざんを検出するなどの方法がある。
 クラウドサービスにおいては、経済産業省「クラウドサービス利用のための情報セキュリティマネジメント
ガイドライン」に準拠している WORM 機能を有するサービス（Amazon Glacier ボールトロックなど）を利用する必要がある。

5.7. クラウド・オンプレミス検討の方向性
データ共有というキーワードを主としてクラウド・オンプレミスの利点欠点などを議論した結果、用途や状況によって使い分けるハイブリッドも必要と考えた。各委員の業務の紹介や外的要因などを含めて議論する中で項目に対する重みも重要と認知された。選定の参考情報として以下に整理した。
選定するシステムにおいて内外の状況が【表 7 クラウドに向かない状況一覧】該当する場合は、ハイブリッ
ドクラウドやオンプレミスの適用を主とした検討をお勧めする。該当しない場合は、クラウドファーストを検討できると考えている。
オンプレミスやハイブリッドクラウドの選定の議論の結果は、【表 8 オンプレミスやハイブリッドクラウドの選定基準一覧】にまとめた。

31

表 7 クラウドに向かない状況一覧
セキュリティに関する事項
データ公開を主とする短期間のプロジェクトがない。
運用やアプリケーションを外部委託しない。または、できない。
国際・国内法令・クラウドベンダ倒産に迅速に対応できない。
秘匿性の高いデータ・情報（国防・特許・研究途中）が存在し分割できない。
情報に関して統制・管理・相談できる部署が存在しない。
業務特性における人材に関する事項
クラウドに精通した人材を確保できない。または、不足している。
クラウドベンダのロックインを避けたい。
リソースの変動に対して判断する仕組みがない。変動を予測できない。
現有の ID 管理を刷新されると業務継続が困難である。
構築・運用コストに関する事項
学術ネットワークや既存専用線などの利活用ができない。
月次、年次の費用をオンプレミスと比較して低価格が必達である。
クラウドの制限（認証種類の制限や運用停止）に合わせて業務を変更できない。
月次の費用において大幅な変動が許容されない。
データ共有に関する事項
共有すべきデータの重要度、保持期間などラベリングの十分性を検証できていない。
データ転送または、アクセスにおいて、継続できることが業務遂行に重要である。
総容量 10PB 以上や 10 億ファイル以上のデータを共有したい。
データを消失しても、現実的な期間でのデータ再作成のスキームが確立されていない。
表 8 オンプレミスやハイブリッドクラウドの選定基準一覧
セキュリティに関する事項
データのリスク分析や対応は検討済み
未検討または、今後の検討である
証跡が必要な業務であり、必要なデータを分類できている
分類できていない
秘匿性の高い業務（国防・特許・研究途中）と分割可能である
分割が難しい上記の場合、オンプレミスと一部データのクラウド展開を検討可能 上記の場合は、オンプレミスを推奨
業務特性における人材に関する事項
業務の変動を予測可能、または、傾向の変化が緩やかである
5 年前後でデータ移動が発生する
運用スキルを自組織に有したい
適切な判断のため、運用(ログ分析)のスキルを維持向上させたい
利用者が要望する検証環境が必要・存在（実験機連携など）する
現有の業務の踏襲が必須である
上記の場合、オンプレミスと一部データのクラウド展開を検討可能 上記の場合は、オンプレミスを推奨
構築・運用コストに関する事項
データ課金対策としてデータ共有量を制御できる
データ共有量を制御できない
帯域課金対策としてアクセス量（スパイクピーク）が予測可能である 予測が困難である
統計情報（利用率、分布、通信、要求数、故障率）は、一部でよい
運用改善、次期機種選定などの比較として独自に必要である上記の場合、オンプレミスと一部データのクラウド展開を検討可能 上記の場合は、オンプレミスを推奨
データ共有に関する事項
データアクセス数やアクセス量が右肩上がりの業務である
数年、増加の傾きが急である(業務に変化あり)
データ転送の継続性は業務継続に直結する。
（nnGB/秒の帯域が必須な データ生成・解析・共有までに大規模なデータ
どの要件が明確）
転送帯域が必要である
重要なデータは 2 重化以上など BCP 対策が確立(連携機関へのコピー 再現不可能や歴史的な非公開データが大量に存やデータ転送のための帯域確保、再計算で生成など)されている
在する可能性が大きい
上記の場合、オンプレミスと一部データのクラウド展開を検討可能 上記の場合は、オンプレミスを推奨

32

6. 結び近年、クラウドを用いたサービスは広く普及し、特に無料で利用可能なメールや動画配信サービス等は日常的に利用されるものとなった。また、ドキュメントやスプレッドシートの共有、共同作業ツールも非常に安価に利用できるようになり、オフィス系ソフトウェアや画像編集ソフトウェアについても、無期限に利用できるインス
トール型ソフトウェアの販売から、クラウドサービスの利用を含めたサブスクリプション型へと販売手法を変更している。これらのサービスは、ネットワークに接続され、ウェブブラウズが可能であれば、どこからでも利用可能であり、利便性が非常に高い。一方で、例えばメールサービスなどを組織が提供する場合、セキュリティ対策などが大きな負担となり、その運用コストも大きくなっているため、クラウドサービスと同様のレベルを維持することは大変難しくなっている。また、機能が不十分なサービスを提供したとしても、ユーザは利便性の高いクラウドサービスを独自に用いることもあり、管理ができない状況に陥ってしまう可能性も低くない。これらを勘案すると、サービスが一般的に提供されているメール、オフィスツール、比較的小さいドキュメントファイルの共有等については、適切なクラウドベンダ及びクラウドサービスを選択し、ユーザの利便性を高くすることが、
セキュリティレベルを高めるうえでも有効であろうということが本 WG の議論から明らかになった。しかしながら、導入時の契約条項などには多くの留意点があるだけでなく、不用意な情報漏洩を起こさないためにも、適切な初期設定やユーザ権限の設定を行うことに、これまで以上に注意を払う必要があることも明らかとなった。また、一般にクラウドサービスは高い稼働率を維持しているが、大手クラウドサービスにおいて、半日程度ファイ
ルへのアクセスが不可能になったという事例もあり、すべてを１社にゆだねることが適切かどうかも含め検討は必要であろう。ベンダ選定やサービス契約における留意点については、各種テンプレートの準備が進められており、これらを適宜利用することは有用である。推奨される各種設定などについての資料は充実していないが、今後徐々に整備されてゆくと予想される。
一方で、大規模なデータを幅広いユーザ間で共有する場合は、既存のクラウドサービスの適用が難しいケースがあることも認識された。数 PB を超えるような大規模なストレージを利用する場合、設置場所などに問題がなければコストメリットはあまり大きくない。また、データに頻繁にアクセスする場合は、通信における遅延など性能面でのオーバーヘッドがあるばかりでなく、データ読み出しに対する課金などにも考慮する必要がある。デー
タ読み出し量の細かい調整、データ暗号化、データ破損に対する対策、さらにはデータへのアクセス認証方法などについても課題は多く残されていることも、本 WG の調査によって明らかになった。また、クラウド契約を解除する場合のデータの取り出しや移行に要する時間的、金銭的コストも無視できないため、具体的な利用方法について事前によく検討したうえでの選択が必要になる。これらを踏まえた場合、オンプレミスが有利となるケースも少なくないことも明らかになった。５章に、クラウドを利用したシステムを設計する場合に確認しておくべきチェック項目をまとめた。実際にオンプレミスとクラウドを取捨選択する場合には、その都度利用可能なサービスと要件について、比較・検討を続けていく必要がある。
今回の WG の議論を通してユーザ管理が、オンプレミスとクラウドサービスどちらについても大きな課題の一つとなることも明らかになった。複数の組織をまたいだコラボレーションの場合、ユーザの実在性検証、登録、権限付与・変更、削除などが管理上の大きな負担となる。認証については様々な標準化が進められているが、これらをいかに取り入れ、ファイル共有システムとしてうまく利用して行くかが、今後の大きな課題の一つとして認識された。
本まとめがシステム導入の検討の一助になれば幸いである。

33

A. 各委員のシステム紹介
各委員のシステムや業務を紹介する。

A.1. 早戸委員【東京大学 宇宙線研究所 神岡】
データを配布する側の事例
・一般向けデータ公開（O(100GB)）、web base、データベース
・一般向けデータ公開（O(1PB)）、データファイル
・共同研究者向け大規模データ共有
検出器で取得した実験データを実際の物理解析に供するためには、まず一次処理（再構成）を行い、観測された粒子の生成(反応)位置、種別、運動量(エネルギー)などの情報に変換する。この変換されたデータについて、さらに解析したい物理事象の信号と、それ以外の事象（背景事象）をおおまかに区別することでさらにデータ量を減らし、実際にユーザが用いる解析用データファイル（DST）を生成する。 通常、DST は数百 GB～数 TB 程度となり、これを世界各国の研究者が利用する。これらのファイルは神岡にある 9PB に蓄積され、神岡施設での計算機資源に VPN でログインして直接扱うか、VPN 経由でファイルをコピー(scp)することで利用している。
検出器で観測されると期待される物理事象を、モンテカルロシミュレーションプログラムを用いて大量に生成する。モンテカルロシミュレーションプログラムは、検出器が生成するデータを模擬するものであり、これを実際の観測データと全く同じように処理することで、シミュレーションデータについても DST を生成する。統計の
ふらつきの問題を除くため、通常は実際のデータの数百倍程度の事象を生成する。例えば、大気ニュートリノ観
測であれば、約 20 年分の観測データを解析するために 2000 年分相当（およそ 2000 万事象）程度の生成、処理を行う。
大気ニュートリノ事象のシミュレーションについては、その生成と高速な事象再構成は１事象１分程度以内で終了するため、神岡施設でも数週間程度でその生成を完了することができる。 一方、高精度な事象再構成ソフ
トウェアは、１事象５分程度を要するため、神岡施設の計算機資源では処理することができず、海外の複数の研究機関の計算機資源を用いて生成する必要がある。ここで生成したシミュレーションデータファイルは、総容量で数 TB を超えるが、これを神岡施設に転送、保管する必要があり、効率的かつセキュアな生成や転送が課題となっている。
事象シミュレーションに用いるプログラムや、事象再構成に用いるプログラム、入力に必要なプログラムは実
験グループで開発したものとなり、すべてが一般公開されているわけではない。これを海外の研究機関やパブリ
ッククラウドで実行するとき、各計算ノードに配布、展開する必要があるが、その配布方法には認証などの課題がある。
既に述べたように、ソフトウェアは世界各国の研究者が共同開発しており、これを効率的に行うため、svn や
git などのソフトウェアレポジトリ（バージョン管理ソフトウェア）が用いられている。レポジトリそのものの管理だけでなく、ユーザの登録・削除、ならびにアクセス権の管理などが大きな課題となっている。
近年は、実験の結果だけでなく、そこで用いたデータなどもできるだけ一般に公開することが求められている。事象データそのものを公開することは、サイズ的な問題もさることながら、これを扱うには検出器の理解も必須となるため、あまり行われてはいない。
一方で、物理現象の解析に必要となるための解析済ファイルなどは公開されることが増えている。これらは通常数 GB～数百 GB となるが、その公開は機関の web サーバなどを用いて行われることが多い。読み出しについて
はだれでも可能とする。
これらのデータは十分な速度で転送できる環境を整える必要があるばかりでなく、データの信頼性担保のため、正当な物であることを示すための技術も必要となる。さらには、事故もしくは故意の書き換えが発生しないようにするための高い管理技術やセキュリティ体制も求められる。

34

研究にあたっては、グループ内外で数多くの会議が開催される。そこで用いられた発表資料や文書などを共有するためのソフトウェアも必要となる。
（indico、Docdb など）
論文やグループ内での報告書などを共同で編集することも必要となる。これも世界各国の研究者が効率的に作業できるような環境が必要となる（svn/Office365/GoogleDocs）。
コミュニケーションツールとして、従来はメールが用いられていたが、最近は Slack などのツールも利用されるようになっている。ここに蓄えられたコミュニケーションの記録などを適切に保管し、のちにアクセス可能な状態に保つことも重要となっている。

35

36

37

38

39

40

41

42

43

44

45

46

A.2. 藤田委員
【宇宙航空研究開発機構 調布】
データを配布する側の事例
・一般向けデータ公開（O(100KB)）、web や scp
・一般向けデータ公開（O(～100KB)）、ソースコード

A.2.1 概要
宇宙航空研究開発機構(JAXA)調布では、スーパーコンピュータの利用において歴史的に、数値シミュレーショ
ンデータを大規模・大量データとして蓄積・利用してきた。図 A.2-1 に JAXA スパコンの歴史を示すが、1980 年代の開拓の時代から、現在は実用の時代へとその役割を変化させている。この変化に伴い、大規模なファイルに対する高速なシーケンシャルアクセス性能だけでなく、ものづくりの際の設計に不可欠なパラメトリックスタディ
値計算でのデータアクセスパターンである小規模大量データへのアクセス性能も求められるようになった。2016
年の JSS2(JAXA Supercomputer System generation 2)の稼働を機に、衛星データの再処理も行うようになり(図A.2-2)、小規模大量データの処理能力とデータ共有機能がより一層求められる時代になっている。

図 A.2-1 JAXA スパコンの歴史

GOSAT（いぶき）（温室効果ガス観測技術衛星）

TANSO-FTS(*2)(温室効果ガス観測センサー)(*2)Thermal And Near infrared Sensor for carbon
Observation -Fourier Transform Spectrometer

TANSO-CAI(*1) (雲・エアロソルセンサー)(*1)Thermal And Near infrared Sensor for
carbon Observation Cloud and Aerosol Imager▲季節の移り変わりによる二酸化炭素の全球分布

図 A.2-2 衛星データの再処理
47図 A.2-3 に、JSS2 のシステム構成図を示す。この中で、「ファイルシステム部(SORA-FS)」が 7PB の容量を持つ
SRFS ファイルシステム、「アーカイバ部」が 60PB の容量をもつテープアーカイバであり、データ管理の中心的役割を担っている。

図 A.2-3 JSS2 システム構成図
2016 年から 2018 年にかけての、アーカイバに蓄積されているデータのファイルサイズと数を図 A.2-4 に、ファイルサイズ毎のデータ総量を図 A.2-5 に示す。年を追うごとにファイル数や総容量は大きくなってきているが、サイズ 16MB 前後のファイル数が多いこと、総ファイル量はファイルサイズ 64GB 程度のものが多くを占めている
ことは、傾向として変わっていない。
DISTRIBUTION OF FILE NUMBERS (2016-2018)
45000000
40000000

2018

2017

2016

35000000
1505196006

25000000

531

1276551390

192

20000000

815000000

1

10000000
5000000

FILE SIZE

図 A.2-4 アーカイバ内のファイルサイズと数
48

64 TB <=

< 64 T B< 16 T B< 4 TB< 1 TB< 2 5 6G B

< 6 4G B< 1 6G B

<4G B

<1G B

< 2 5 6M B

< 6 4M B< 1 6M B< 4M B< 1M B< 25 6 KB<6 4 KB<1 6 KB< 4 KB0< 1 KB# OF FILES

30000000DISTRIBUTION OF DATA AMOUNT (2016-2018)
4000
2018

3500

DATA AMOUNT (TB)

3000

2017

2016

181.7GB0.7GB

774.6GB

5.4GB

2500

6.2TB

47.7GB

2000

33.7TB

1500
1000
500

64 TB <=

< 64 T B< 16 T B< 4 TB< 1 TB< 2 5 6G B

< 6 4G B< 1 6G B

<4G B

<1G B

< 2 5 6M B

< 6 4M B< 1 6M B< 4M B< 1M B< 25 6 KB<6 4 KB<1 6 KB< 4 KB< 1 KB

0

FILE SIZE

図 A.2-5 ファイルサイズ毎のデータ総量

A.2.2 JAXA のデジタルデータ運用
前節では、スーパーコンピュータ(JSS2)でのデータ保管について紹介したが、本節では、JAXA 全体でのデジ
タルデータ運用に関して、その一部の活動を簡単に紹介しておく。
デジタルデータの保管場所（サーバ）は、データ種別毎には局所化しているが、JAXA 全体で見れば、多数の事業所にデータが分散して存在することになる。また、その総容量は PB のオーダーになっており、データ保持のための設備維持に多額の固定経費が必要である。例えば、次の通り。
数値シミュレーションデータ(7PB+60PB)・・・調布
衛星データ(5PB) ・・・・・・・・・・・・・筑波・鳩山
科学衛星データ(3.3PB) ・・・・・・・・・・相模原
また、データ種別単位に運用体制が存在し、データの健全な管理を行っているが、運用体制の集約による人的コスト集約(というか、そもそも人手不足の運用部門の立て直しの一手法としての集約)も、考える時期に来ている。
データにアクセスする研究者（クライアント）は、上記事業所だけでなく、図 A.2-6(や、場合によっては図A.2-7 ないしは、NASA,ESA 等の協力機関)の場所からデータにアクセスする。

図 A.2-6 JAXA 国内拠点

図 A.2-7 JAXA 海外拠点

49

A.2.3 データ管理の課題
ここからは、JAXA におけるデータ管理に関する課題を次の 4 つに分類し、順番に述べる。
(1)事業所を跨いだデータ管理(2)データ公開の仕組み(3)小サイズ大量ファイルの I/O 性能(4)ライフタイムの長いデータ管理ツール(1)事業所を跨いだデータ管理
A.2.2.で述べた通り、JAXA 全体を見渡した場合、多数の事業所にデータが保管され運用されている。これに起因する課題がいくつか存在する。
(1a)データ移動
データ処理に利用可能な計算機(CPU 資源)が複数の事業所に存在する場合、計算機(CPU 資源)の空き具合に応じて、処理させる計算機を切り替えることがある。この時、処理データをその計算機(CPU 資源)のある事業所に移動する必要があるが、これにコスト(回線費、転送時間)がかかる。
（そもそも、計算機／データの分散配置という設計が良くないのかもしれない。
）(1b)データ共有
データ移動は、基本的には人手を介して行われるが、これを自動化する意味で、データの事業所間での共有のニーズがある。過去に「SRFS on Ether」を制作し、事業所間を跨いだファイルシステムマウントの運用を行ったことがあるが、回線品質の悪さによる(と推測される)マウント切れが主たる理由で、現在では事業所間跨ぎのファイルシステムマウントの運用はしていない。
「SRFS on Ether」から 10 年が経っているので、再挑戦する価値はあるかもしれない。
(2)データ公開の仕組み
公開範囲(ACL)のきめ細かい設定、特別なツールを使わない高速ダウンロード、データ処理計算機からデー
タ公開用サーバへのデータ転送というオーバーヘッドの存在等がデータ公開の際に問題になっている。
(3)小サイズ大量ファイルの I/O 性能
データ共有に限った話ではないが、ファイルシステムは小サイズのファイル操作に対して性能を発揮できない。データ共有の仕組みでも同じことが言えるため、なにがしかの仕組みの導入により、高速に処理できるよ
うにすることが重要である。
(4)ライフタイムの長いデータ管理ツール
ファイルシステムやアーカイブシステムが換装されても、ユーザからみたインターフェイスは変わらない、というデータ管理ツール(Put/Get、Archive/Stage)が欲しい。
（ftp,scp が、ライフタイムが長いという意味で該当するのか。でも、速度面で不満がある、大量のファイルを管理するには工夫が必要なのも難点。
）
以上

50

A.3. 中村委員
【高エネルギー加速器研究機構】
・一般向けデータ公開（O(100GB)）、解析環境、解析ソフトウェア、ドキュメント
・一般向けデータ公開（O(1PB)）、データファイル
・共同研究者向け大規模データ共有 (O(100 PB))、実験データ、処理済みデータ
高エネルギー実験におけるデータ処理の現状
現代の大規模粒子加速器を用いた高エネルギー素粒子・原子核実験は、加速器の高輝度化に伴うデータ取得レ
ートの上昇と、測定器の大型化および検出器の高精度化によるビーム衝突事象ごとのデータサイズの増大により、取得する総データ量は拡大の一途を辿っている。実際に、欧州合同原子核研究機構 (CERN) に設置されている
Large Hadron Collider (LHC) 加速器を用いて行われる ATLAS 実験 [1] で取得する生データ量は、2018 年の時
点で年間 60 PB に達している。2026 年から LHC 加速器を増強して行われることが決定している High Luminosity
LHC (HL-LHC) 加速器による実験では、総データ量が現状の LHC 実験の 10 倍になることが見込まれている。また、2018 年から高エネルギー加速器研究機構 (KEK) で開始した、SuperKEKB 加速器を用いた Belle II 実験 [2] では、数年間で 100 PB 程度の生データを蓄積することを予定している。
取得された生データは、検出器直近に配備するフロントエンド・エレクトロニクスにより即座にデジタル化され、事象選別された後にビーム衝突事象ごとに結合され、物理的に興味のある対象を含む事象のみが抽出され記録される。記録された生データは通常、加速器が設置されている研究所の計算機設備内のテープ・ライブラリに恒久的にアーカイブされると同時に、災害時に計算機設備が被害を受けた場合のデータ喪失を防ぐために、世界各国の研究所に配備されている計算機設備内のテープ・ライブラリに、国際学術ネットワークを通じてレプリカ・
データが分散アーカイブされる。
生データへのアクセス頻度は高くはない。記録された生データは、テープ・ライブラリにアーカイブされる前に再構成し物理量に変換される。その後、対象とする物理解析に応じてデータを分離し、物理解析に使用するデータフォーマットへ圧縮と変換がなされる。生データへのアクセスは、検出器校正定数の更新や、再構成アルゴ
リズムに変更の必要性が生じた場合に限られる。一方で、物理解析用のデータは、世界各国の研究所と大学の計算機設備に分散され、繰り返し処理される。
物理解析用の実データは、検出器の構成が複雑であるため、実データと同じ統計量に相当するモンテカルロ・
シミュレーションデータを最低限生成し、比較と評価がなされる。このシミュレーションデータの生成は主に、加速器研究所の外部サイトの計算機設備を用いて行われる。これら多数のサイト間での実データおよびシミュレーションデータの共有と計算機資源の相互利用は、Interoperable Global Trust Federation [3] のポリシーに従うグリッド認証局が発行する証明書を用いた認証・認可にもとづいて行われている。

今後の課題 (新しい認証・認可基盤の導入、データの恒久的な保存、データの一般公開)
限られた計算機資源により拡大する総データ量を処理していくために、既存のグリッドサイトだけでなく、HPC
計算センターや、クラウド計算機資源を積極的に利用できる環境が模索されている (eXtreme DataCloud [4])。
これらの計算機資源と分散されたデータを、データレイクなどの新興技術を用いて統一的に取り扱うためには、
現在グリッド基盤で用いられている X.509 証明書のみにもとづいた認証・認可基盤 (AAI) からの脱却が求められる。グリッド認証局の維持とユーザ管理はコストが高いだけでなく、エンドユーザーにとっては X.509 証明書の取り扱いの敷居が高いことも理由となっている。次世代の AAI としては、ユーザが所属する各組織の ID を連携させることによるシングルサインオンの実現 (Federated Identity Management for Research [5]) と、エンドユーザーの利便性を高めるための SAML 認証や OAuth を用いたトークンベースの AAI の採用が候補として検討されている (Authentication and Authorisation for Research and Collaboration [6])。
加速器実験で取得するデータ量は膨大なため、過去に行われた実験データの恒久的なアーカイブを続けるための様々な共同研究が、Data Preservation in High Energy Physics [7] の枠組みにより行われている。大型加速器の運転は電気料金などのコストが高く、同じ目的で再運転することは容易でないため、一度取得したデータを将来にわたって再利用できることが望ましい。また、計算機器とその利用技術の進歩や、データ解析手法や理論
物理の発展により、過去に取得したデータの再解析による新発見の可能性も期待されている。これらを実現する
ためには、大量データのアーカイブ技術だけでなく、バーチャルマシンやコンテナを用いたデータ読み出しのためのソフトウェアを含めた計算環境の保全なども必要となる。
加速器実験データの一般公開は、データ量の多さから、配布のために必要なネットワーク帯域幅と、データ処理のために必要な計算能力が膨大となるため、現在では新規参入の研究者をトレーニングする目的、学生の教育
目的、アウトリーチ活動の目的に留まっているのが現状である (CERN Open Data [8])。一方で昨今は、データ解51析ソフトウェアなどの使い方を説明する文書を整備するだけでなく、Jupyter などのノートブックツールを用いて、データ解析環境と大量データへのアクセス方法を提供することにより、Web ベースの解析方法を通して、一般の人々が 1 PB 程度のデータにアクセスすることが可能となりつつある。今後は、その規模と簡便性を向上させていくことが課題となっている。
参考文献[1] ATLAS 実験, 素粒子の質量を生み出す起源とされる、ヒックス機構の証拠となるヒッグス粒子を発見した実験。この実験結果により、2013 年にヒッグス機構を理論的に提唱した、Fsrancois Englert 博士とPeter W. Higgs 博士がノーベル物理学賞を受賞した。
https://atlas.cern/[2] Belle II 実験, 粒子と反粒子の対称性 (CP 対称性) の破れを実験的に示した、KEKB-Belle 実験の測定
結果を、高統計のデータを用いて精密に検証するための実験。CP 対称性の破れの起源を理論的に予言した、小林誠博士と益川敏英博士は、2008 年にノーベル物理学賞を受賞した。
https://www.belle2.org/[3] Interoperable Global Trust Federation (IGTF)
https://www.igtf.net/[4] eXtreme DataCloud (XDC)
http://www.extreme-datacloud.eu/[5] Federated Identity Management for Research (FIM4R)
https://fim4r.org/about/[6] Authentication and Authorisation for Research and Collaboration (AARC)
https://aarc-project.eu/[7] Data Preservation in High Energy Physics (DPHEP)
http://hep-project-dphep-portal.web.cern.ch/[8] CERN Open Data
http://opendata.cern.ch/

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

A.4. 白崎委員
【国立天文台】・一般向けデータ公開（O(1PB)）、観測データファイル
・一般向けデータ公開（O(10TB)）、カタログデータベース
・国立天文台内におけるデータ共有 (O(1PB))
観測データ
国立天文台では、すばる望遠鏡、ALMA 望遠鏡、野辺山電波望遠鏡、水沢 VERA、太陽望遠鏡等による観測によって取得されたデータの保管とインターネット経由による配信を行っている。
すばる望遠鏡によって取得されたデータはすべて天文分野における共通のフォーマットである FITS 形式で保管されている。他の観測装置の場合にはそれぞれの装置に固有のフォーマットで保管されているものと、FITS 形式で保管されているものとが共存している。
観測データのファイルあたりの容量はすばる望遠鏡の場合数十 MB 程度である。一方、ALMA 望遠鏡の場合は観測によりデータサイズはまちまちであり、数 10KB から 数 TB まで様々である。現時点 (2018 年) における観測データの全容量は数 PB のオーダーである。
保管されているデータのメタデータはデータベース化されインターネット経由で検索可能であり、データ本体
もダウンロード可能である。検索インターフェイスは Web ブラウザベースのほか、最近はヴァーチャル天文台仕様により世界中の天文データベースが利用可能となるアプリケーションを利用した検索も可能となっている。
今後想定される懸念事項としていは、ALMA の１ファイルあたりのデータ量が大きいため、ユーザがインターネ
ット経由でダウンロードすることが困難な状況が増えていくであろうことである。また、従来使ってきた解析ソ
フトウェアの中にはそうした大容量データの解析には対応できていないものもあると考えられ、今後そうしたデータの解析にも耐えられるソフトウェアの開発が必要である。
カタログデータ
観測データから導き出される天体カタログデータの公開も行っている。
国立天文台が運用に関わる上記の望遠鏡以外にも、海外研究機関が運用している科学衛星 Gaia や JAXA の天
文衛星 AKARI のデータより作成されたカタログも検索システムを構築し公開している。これらの全データ容量
は数十 TB の規模である。
カタログデータは PostgreSQL 等のリレーショナルデータベースに入力され、テーブルあたりのカラム数は数十から数千個である。
Web ブラウザーを利用した検索が可能であり、CSV 形式の他、FITS 形式、VOTable 形式でダウロードできる。
VOTable 形式はカタログデータや観測データのメタデータを交換するために定義されたデータ形式であり、XMLで記述される。
観測データの場合と同様にヴァーチャル天文台に対応したアプリケーションによる検索も行われるようになってきている。また、単純にカタログファイル全体を Web ブラウザー等によりリンク先 URL からダウンロードすることも可能である。
カタログデータは観測データに比べて総容量は大きくないので、時間をかければダウンロードすることは可能である。しかしながら、データ公開開始直後は一度に大勢の研究者がデータダウンロードを行う傾向があり、ネットワーク回線への負荷がかかり過ぎることにより他のネットワークサービスへのアクセスもできない状況に陥ってしまうことが度々ある。こうした問題を回避できる仕組みが必要である。
国立天文台内におけるデータ共有
大量の観測データを利用者の計算機にコピーせずとも解析を行えるようにするため、また解析環境を研究者個人で用意するコストを抑えるため、共同利用計算機システムの運用を行っている。
すばる望遠鏡や ALMA などのデータを解析したい研究者は、国立天文台三鷹キャンパスの共同利用計算機室からこの計算機システムにログインし利用することができる。また、遠隔から VPN によりログインして利用することも可能である。
この計算機システム上には数 PB 規模のデータ保管領域が用意されており、解析済みのデータを一定期間保存しておくことができる。解析対象となる観測データは、台外向けのデータ公開インターフェイスを利用してこの計69

算機システム上にコピーしてから解析を行う。
共同利用者同士でのデータのやりとりにもこのデータ保管領域を利用することができる。もちろん、研究者個人の計算機に scp や rsync なででデータをエクスポートすることも可能である。
現在の課題としては、データ保管領域が多数のパーティションに分割されており、どのパーティションにデータを置くかは各利用者の判断に委ねられているため、特定のパーティションにデータが偏ってしまうことがあげられる。ほぼ 100%まで利用されてしまったパーティションがある一方で、ほとんど利用されていないパーティションも存在している。現在分割されてしまっているパーティションを一つにまとめた上で、データ転送の帯域幅も十分ある大きな一つの保管領域として利用可能な仕組みが必要である。

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

A.5. 渡邉委員
【広島大学】
・共同研究者向け資料共有
・共同研究者向けコード共同開発
ポリシーやガバナンス事例
クラウドサービスを利用する場合、クラウド事業者との間で外部委託契約を行うことになるため、クラウド事業者の選定、サービス内容の確認、責任体制の構築等を慎重に行う必要がある。一方、選定基準や確認事項などについては学術機関共通の指標があるわけではなく利用する側で定めておかなければならない。本項ではクラウドサービス利用におけるガイドラインやチェックリストを先行して提供している
広島大学の事例を紹介する。
広島大学では、大学が保有している情報（法人文書）の保存先としてクラウドサービスを利用する場合を想定した「広島大学クラウドサービス利用ガイドライン」（以下、ガイドラインという）を策定している。
クラウドサービスを利用する際に広島大学として確認すべき項目の解説がされており、チェックリストにより広島大学が定める法人文書の重要度の応じたクラウドサービスの利用可否を容易に確認できる資料となっている。クラウドサービスの利用者は導入前にチェックリストの項目を確認し、その結果を指定された部署に提出する。また、利用者は 1 年を超えない期間ごとにその時点で最新のチェックリストの項目を再確認し提出する。これにより組織的なクラウドサービスの利用状況の把握することに加えて、情報セキュリティ
関連の要求要件とクラウドサービスのセキュリティ対策状況の対応を定期的に見直す方針となっている。

85

86

87

88

89

90

91

92

93

94

95

96

B. クラウド時代のデータ共有技術紹介
富士通からのデータ共有技術紹介を以下に示す。

B.1. クラウドストレージ、ストレージソフトご紹介

97

98

99

100

101

102

103

104

B.2. データ配布時の高負荷対策

105

106

107

108

109

B.3. クラウドストレージ紹介

110

111

112

113

B.4. クラウド時代のデータ共有技術

114

115

116

117

118

119

120

121

122

B.5. 「認証サービス」ご紹介

123

124

125

126

127

128

129

130

131

132

B.6. ブロックチェーンで実現するデータ流通・利活用

133

134

135

136

137

138

139

【発行者】サイエンティフィック・システム研究会【編 集】サイエンティフィック・システム研究会
クラウド時代のデータ共有技術ＷＧ【発行日】2019 年 4 月 30 日
◆ ◆ ◆＜連絡先＞ サイエンティフィック・システム研究会 事務局〒105-7123 東京都港区東新橋 1-5-2 汐留シティセンター
E-mail：ssken-office@ml.css.fujitsu.com
http://www.ssken.gr.jp/MAINSITE/※著作権は各原稿の著者または所属機関に帰属します。無断転載を禁じます。

140