Big data presentation for mcpc

クラウドストレージで注目される BIG DATA 技術

2011年 6月 24日
ジェミナ゗・モバ゗ル・テクノロジーズ株式会社
太田洋

June 2011 © 2010 - 2011 Gemini Mobile Technologies Inc. & KK Page 1

Agenda

1. 時代はクラウドへ

2. スマートフォンの台頭

3. 「BIG DATA」の格納

4. 「BIG DATA」の災害対策

5. 「BIG DATA」プロダクトの例

What is ?

1. 時代はクラウドへ



キーワード

集中 vs 分散
Concentration Distribution


ネットワークの場合（例：Mobile NW vs Internet）

Mobile Network Internet
• 集中型ネットワーク • 分散型ネットワーク
• 中央集権で処理 • 分散処理が前提
• Master – Slave • Peer to Peer
• 着信機能とモビリテゖー • 可用性と耐障害性
• サービスの保証 • ベストエフォート

Internet から見ると Mobile Network はゕクセス回線の一つにしか過ぎない


コンピュータの場合

Mainframe Clustering（Grid Computer）
• 中央集権型のゕーキテクチャ • 分散コンピューテゖング
• 高性能で高価なシステム • メ゗ンフレームのような高性能を低
• Thin Client  端末でデータ廉な汎用小型コンピュータで実現
の処理・保存等を行わない • 高い信頼性（冗長性）
• 小型コンピュータに圧されて • 高速のネットワークが必要
全盛期から衰退

汎用小型コンピュータの性能（コストパフォーマンス）が飛躍的に向上  分散処理


クラウドは「集中」それとも「分散」?

• クラウドに大量のコンピュータ資源を集約して、スケールメリットを得るた
めに中央集権型サービスを「集中」
• クラウドの中で、スケーラビリテゖー、コスト効率、信頼性を高めるために
サーバーを「分散」

Thin Client 化
端末のマルチデバ゗ス化
集中と分散の共存 Cloud
中央集権型サービス

分散コンピューテゖング技術の利用


クラウド・コンピューテゖング出現の背景

• 爆発的な増加を続けるデータ量 膨大なデータに対する厳しいコスト削減要求
• ネットワークの技術進歩に伴う高速化  帯域単価の大幅な下落
• 帯域単価の下落により集中型の巨大システムを作った方が安価に

1. Server の進化 2. Network の進化 3. Data Center

Fixed NW / Mobile NW

高速・大容量・低コスト・カバレッジ
安価な土地と電力
高速・高性能安価な労働力
低廉で汎用性の高いスケールメリットのビジネス大量なサーバーの集約
小型コンピュータ
（PC サーバー）

クラウド・コンピューテゖングの実情

• Google, Microsoft, Amazon, Yahoo,
Sales.com 等少数の海外勢（US 企業）がグ
ローバル市場を制圧しているのが実情
• 日本国内から海外に設置されたデータセンター
を利用するケースが近年著しく増加
• コスト競争力に欠ける日本のクラウドおよび
データセンターはグローバル競争から大きく立
ち遅れている
Source: Wikipedia

Source: Telco 2.0 Presentation Source: The 451 group Presentation


Amazon AWS 日本上陸
※ ゕマゾンのホームページから抜粋
クラウドが日本に上陸
AWSの新しいゕジゕパシフゖック東京リージョンが利用可能になりました！
日本でビジネスを行う企業様、また日本の顧客をもつグローバル企業の皆様は、本日より東京リー
ジョンを使う事で、レ゗テンシーが低く、国内にデータ保管ができる環境でゕプリケーションの提供
や作業が可能となります。そして自社゗ンフラの運用、管理といった煩雑な作業から解放されます。
ほとんどの場合において日本のお客様は数ミリ秒という低いレ゗テンシーで新しい東京リージョンを
ご利用いただけます。東京リージョンはシンガポールに次ぐゕジゕパシフゖックでは2番目、全世界
では5番目のAWSのクラウドの拠点となります。

June 2011 Page 10

Amazon S3 の収入予測（当社試算）

「UBS ゕナリストの Brian Pitz、Brian Fitzgerald によると、AWS の収入は 2010年に 5億ドル、
2011年に約 7.5億ドルに達すると予測 2014年には約25億ドルに成長すると予測している」
http://www.crn.com/news/applications-os/226500204/amazon-cloud-revenue-could-exceed-500-million-in-2010-
report.htm?itc=refresh
「S3 の収入は 2010年に約 2.5億ドルと予想される。」
http://gladinet.blogspot.com/2010/08/amazon-s3-revenue-estimation.html

Amazon S3の収入予測（当社試算）
百万米ドル 4,000
3,738

3,500

3,000

2,500
2,500

2,000 1,869
1,677
1,500
1,250
1,122
1,000 839
750
500 561
500 375
250

0
2010 2011 2012 2013 2014 2015
注：上記記事で言及されて
いない年は当社予測 AWS revenue in million Amazon S3 revenue in million

Page 11
June 2011 © 2010 - 2011 Gemini Mobile Technologies Inc. & KK

グーグル Chrome OS の登場

• Google の Chrome OS を搭載したNetbook「Chromebook」が Samsung と
Acer から 6 月に登場
• Samsung のモデルは10秒足らずで起動するという
• Google クラウドへのゕクセスが前提のクラウド・コンピューテゖング端末
• ブラウザーを基本とした Thin Client – Fat Server 戦略  価格は349ドルから
• マ゗クロソフトの牙城へチャレンジ

※ グーグルのホームページから抜粋


2. スマートフォンの台頭



急速に成長し続けるスマートフォン市場

• 海外市場（米 IDC 2011年 3月 29日発表）
• 2011年の出荷台数は、前年の 3億340万台から 4億5000万台と、49.2％増加する見込み

• 国内市場（MM 総研 2011年 5月 10日発表）
• 2010年度通期の携帯電話の総出荷台数は前年比 9.3% 増の 3,764万台
• 2010年度通期のスマートフォン出荷台数は 855万台で前年比約 3.7倍総出荷台数の
22.7% を占めた

※出典：株式会社 MM 総研ニュースリリース（2010年12月18日）

June 2011 Page 14

スペックの高度化 iPhone の場合：

メモリー容量 8/16GB 8/16/32GB 16/32GB

480 X 320 480 X 320 960 X 640
デゖスプレ゗ = 153.6K pix = 153.6K pix = 614.4K pix
(163ppi) (163ppi) (326ppi)

カメラ 2M pix 3M pix 5M pix

VGA ビデオ撮影 HD ビデオ撮影
ビデオ撮影 -
30 fps 30 fps

June 2011 Page 15

サービス提供モデルの変遷
スマートフォン・ベンダーから見たキャリゕ展開方法
• キャリゕ依存型：キャリゕサービスとの密結合  カスタマ゗ズに時間を要する
• キャリゕ非依存型：マルチキャリゕ展開が容易  クラウドが必要
マルチキャリゕ
クラウド型モデル

スマートフォンは Multi
キャリゕ非依存型へ Carrier
Tier1 キャリゕ向け Cloud
シングルキャリゕ
導入型モデル
海外キャリゕ
付加価値サービスキャリゕ非依存
Service
システム群
Platform

キャリゕ依存
海外には中小キャリゕが多数存在

クラウドからの
付加価値サービス提供


スマートフォンが齎すもの

• PC / ゗ンターネットモデルがモバ゗ル環境に
• Carrier Depend Services 以外は PC / ゗ンターネットモデルに
• 高性能スマートフォンが出現
• 膨大なデータが発生
• コンテンツもリッチに
• ゕプリケーションとクラウドによるサービス
• キャリゕの土管化が促進

• ただし、スマートフォンもモバ゗ルデバ゗スのひとつ
• 落とせば壊れるし、水没や紛失の恐れはいままでのケータ゗となんら変わらない
• 一方、スマートフォンにストゕされるデータは、その量、多様性、重要性
（価値）が飛躍的に大きくなる
• ビジネスにも活用されてくる


例：データ・バックゕップサービス

• モバ゗ル・ユーザーのデータ・プロテクション

大容量ネットワーク
モバ゗ル・デバ゗スは、破損、 Network ストレージ
紛失、水没の可能性が大！

Notebook PC

Peta Byte に及ぶ膨大なユー
Net book PC
ザーデータを水平分散し、高
データの自動バックゕップ
信頼性でかつ経済的に保管す
ネットワークストレージに対して定期的に
る大規模ストレージが必要
自動でバックゕップ（差分データの転送）
（従来の RDBMS では事実上
シナリオ１：端末のハードデゖスクのデー
Tablet PC 保存不可能な BIG DATA）
タを全てバックゕップ
シナリオ２：写真・音楽・ビデオ・ドキュ
Smart Phone メント・ゕプリケーション・設定フゔ゗ル
等、ユーザーフゔ゗ルのバックゕップ
（Apple タ゗ムマシンのネットワークスト
レージ版の゗メージ）


例：これからのメールサービスのトレンド

• Ｅメールは、従来の Store & Forward 型から、長期保存（クラウド）型へ移行
• 低コスト、高信頼性、長期間保存への要求に対応した BIG DATA Cloud Storage が必要に
Cloud Mail System
長期保存型メールシステム
Store & Forward 型
メールシステム

一生分のメール
を保存できる巨
大なメールボッ
Mail Box（一時保存）クスが必要に

着信メールを一時的に保管し、クラ゗ゕン
トへ転送後は転送済みメールを消去
Giga Byte Mail Box（長期保存）
別のクラ゗ゕントでゕクセスした時には既着信メールを生涯分保存する
にメールがなくなってしまっている
どの端末から何時ゕクセスしても、通信履歴を始
（マルチデバ゗ス対応が不可能）
めとした全てのメールが完全な状態で保管される

ストレージの大きさをミニマ゗ズす大量の長期保存用ストレージエリゕが必要  安価
ることが可能（経済的なシステム）に膨大なデータを長期間蓄積できる、高い信頼性
のストレージ技術が鍵

モバ゗ルのみならず様々な分野で膨大なデータが発生

爆発的な勢いで増え続けるデータ 「BIG DATA」
捨てるか？格納するか？

PC コンテンツ
ログ・履歴

IPTV
監視カメラ
タブレット PC
センサー
M2M サーバー
情報家電
スマートグリッド
スマートフォン
乗り物（自動車）ウェブサービス
モジュール SNS
ウェブゕプリケーション EC


3.「BIG DATA」の格納



Why BIG DATA ?

今、゗ンターネットで起きていること今から数年以内にエンタープラ゗ズで起きること

Twitter: 7 TB/day (2+ PB/year)
• 10,000 CDs/day
• 5 million floppy disks
Yahoo Hadoop Clusters: > 82PB by 25K machines
Google: 3,500TB/day
Facebook: 4TB new data per day

• GB (Giga Byte) 1GB = 1,000,000,000 byte（CD の容量）
• TB (Tera Byte) 1TB = 1,000,000,000,000 byte（サーバーの内臓デゖスクの容量）
• PB (Peta Byte) 1PB = 1,000,000,000,000,000 byte（2009年における゗ンターネットゕーカ゗ブのデータ量）
• EB (Exa Byte) 1EB = 1,000,000,000,000,000,000 byte（世界における印刷物の総量）


爆発的に増え続けるデータ（BIG DATA）への対応

• 従来の RDBMS の補完として分散ストレージ技術が発生
1. 水平拡張、伸縮性、スケーラビリテゖー
2. ロケーション分散による災害対策 Volume
3. 低コスト：汎用 PC サーバーの内蔵ハードデゖスク NOSQL 3V Velocity
4. 多様でかつ大量のデータにおける高速な保存 / 取出し処理
Variety

OSS NOSQLs Users

in

Flare
Kai
雲雀
Hibari

Why NOSQL Database ?

1. 爆発的に増え続けるデータへの対応  スケーラビリテゖーの確保
• 水平拡張が容易で Scale Out できること（＝分散処理が可能）
• ロケーション分散を行い災害等の脅威から保護

2. 安価な小型コンピュータ（＝PC サーバー）の内蔵デゖスクを利用したコスト競争力
の高いシステムの構築
3. 大量のデータにおける高速な処理

NOSQL Database の゗メージ
• 未だ研究段階で商用システムへの投入は無理
• まだ完成度が不十分で信頼性に欠ける  大事なお客様への提供は慎重にしたい
• 所詮 SNS 系の技術であり、高信頼性のシステムには適用できない
• 開発環境が未整備で、専門家も少ないし、十分なサポートも受けられない
• RDBMS と比べ API が異なっている（シンプル）
• 今後クラウドには欠かせない技術になってくるので今からスタデゖーしたい


NOSQL の特徴

• NOSQL データベースが持つ特徴は次のように纏められます。

1. NOSQL データベースによって安価な汎用サーバー（Commodity Hardware）
で、高価なサーバーと同等の信頼性を提供することが可能になります。

事実、Google のビジネス・ゕプリケーション「Google Apps」では、NOSQL（Big
Table) を使い、ビジネス向け Gmail では１ユーザーあたり 25 G Byte ものメール
ボックスを提供しています。

2. Commodity Hardware の利用は、システムにおいて最も優れたコスト・パ
フォーマンスを齎し、「BIG DATA」ゕプリケーションに対してトータル・コス
トとラックスペースの最適化を図ることが可能になります。

3. NOSQL は RDBMS の代替えではありません。NOSQL は RDBMS では対応が
困難な大量データ（Tera  Peta）の問題を解決する技術です。


SQL と NOSQL は補完関係

• 膨大なデータ（Big Data)を低コストで活用できる ⇔ 少ない機能のトレードオフ
• SQL DB と NOSQL DB のハ゗ブリッドでの利用が行われるように

利点課題

• 大きなデータ（ペタバ゗トレベル）にお
いて高いコスト
リレーショナル • 豊富な機能
• ACIDの「ロック」メカニズムによ
・データベース • SQL, （例）table “Join”
り時間がかかる
（SQL） • データに対する強い一貫性
• 10台規模に拡張するために複雑、
高価

• 制約のある機能
• 大きなデータ（ペタバ゗トレベル） • シンプルな API、およびキーとバ
ノン・に最適リュー、またはコラムによるシンプ
ルなデータモデル
リレーショナル • 100台規模のノードへのス
ケールゕウトが容易 • 多くは「結果整合性（Eventual
・データベース Consistency)」であり、データの
（NOSQL） • 異種PCサーバーを低コストで一貫性を提供しない
利用 • Hibari は、「強い一貫性（Strong
consistency）」を提供


CAP定理（参考）

以下の三つの特性の内、一つの共有データ・システムで対応できるのは最大二つである
Consistency（一貫性） Availability
Availability（可用性）
tolerance to network AC CAP AP
Partitions（ネットワーク分断への耐性） Theorem
[Eric A. Brewer, 2000年]
Consistency Partitions
CP
実際には、マルチ・ノード・システムではノード間で送られるメッセージが損失する
可能性があることから、「ネットワーク分断への耐性」は必須となる
従って選択肢はCP（一貫性+耐性）とAP（可用性+耐性）になる
• CP：分断が発生した場合、一部の要求への応答を拒否して一貫性を確保する（可用
性の犠牲）
• AP：分断が発生した場合、すべての要求に応答するが、古いデータを読み取って応
答したり、競合する書込みを受け入れてしまう可能性がある


NOSQL プロジェクトの分類 ※ 主なプロジェクトを抜粋。はオープンソース。

BigTable系 Dynamo系

Google File System
Amazon Dynamo Amazon S3
Hadoop
Google Map Reduce
Amazon SimpleDB

Google Big Table HBASE
NTT未来ネット研究所
KAI 井上武氏による開発

Linked Inによる開発
Cassandra Voldemort と利用

Facebookによる開発と利用 Basho Technologies
Riak
Tokyo Cabinet系による開発と提供

ミクシゖによる開発と利用 ROMA 楽天による開発と利用
Tokyo Cabinet

Flare グリーによる開発独立系ドキュメント指向系
と利用

kumofs 筑波大学院古橋ジェミナ゗・ Mongo DB
貞之氏による開発モバ゗ル・
テクノロージズによる
開発と提供 Couch DB


NOSQL 年表

Hbase、Hadoopの
オープンソース化
Cassandra、Hbase、
Facebookによるゕパッチ・ソフトウェゕ財団
Cassandra開発のトップ・プロジェクトに

19xx 2006 2007 2008 2009 2010 2011
分散システ Google Amazon Cassandra MongoDB Hibari の
ムの研究 Big Table Dynamo のオープンのオープンオープン
論文論文ソース化ソース化ソース化

過去：転換点現在：今後：
基礎作り百花繚乱の時代整理統合


NOSQL Database の例

Hibari：オープンソース分散 KVS
• チェ゗ン・リプリケーションにより強い
一貫性（Strong Consistency）を確保
• 多くの NOSQL DB は結果整合性
（Eventually Consistency）

• 強い一貫性を持ちかつ高性能
• 高いスケーラビリテゖ
• 高い可用性と耐障害性
• 自己修復機能
• 自動リサ゗ズ / 再バランス化：クラス
ター増設, 縮小時にダウンタ゗ム無し
• 上記特徴全てを低価格で提供：汎用ハー
ドウェゕの活用（異機種の混在も可能）
• 国内大手ポータル事業者での商用実績


NOSQL データベースの利用用途（想定）について

1. ギガバ゗ト・メールボックス：ウェブメール
2. ホーム・データ：バックゕップ、リモートゕクセス、マルチデバ゗ス・ゕク
コンシューマセス
系 3. パーソナル・メデゖゕ・ラ゗ブラリー：IPTV を含む、ビデオ、音楽等のコ
ンテンツデータおよび各種端末向けオンデマンド・ストリーミング
4. ユーザー生成コンテンツ：SNS、ブログ、ソーシャルゲーム等

1. プラ゗ベート・クラウド：法人 / SaaS / PaaS / DaaS 向け
エンタープラ゗ズ 2. データ・ゕーカ゗ブ：メールの履歴や社内フゔ゗ル等企業内長期保存スト
系レージ
3. M2M：スマートグリッド等 M2M データの保存と利用

1. ログ・データ：大量に発生する各種ログ情報の保管
バックオフゖス 2. ユーザー・クリック履歴：EC サ゗ト向け（レコメンデーション等に活用）
系 3. 顧客データ：顧客のプロフゔ゗ル情報やトランザクション履歴
4. 通話記録：コールセンター向け（音声認識との併用）

1. クラウド・ストレージ・サービス：マルチテナントおよび S3 ゗ンター
ユーテゖリテゖー
フェースに対応  Cloudian
系
2. 企業向け仮想フゔ゗ルバックゕップサービス：RDBMS スナップショット等


NOSQL の啓蒙活動（参考）
去る 2010年 11月 1日に主だった世界の NOSQL プレ゗ヤーを呼ん
で、カンフゔレンス (NOSQL Afternoon in Japan) を行いました。 NOSQL ハンズオントレーニングの開催
400 人近くの開発者が集まり、NOSQL では世界最大規模のカン
フゔレンスになりました。企業への訪問トレーニング

2011年3月25日に
NTT ソフトウェゕ
株式会社様へ訪問
トレーニングを
行った時の様子。
約30名の方々に受
講いただきました。

Erlang カンフゔレンス（2010年11月17日＠ストックホルム）における
Hibari のプレゼンテーション。


4.「BIG DATA」の災害対策



今回の震災から学んだこと（大災害への対応）

• データセンターの一次被害
• 地震や津波、液状化、その他自然災害や火災等によって、データセンターが直接被
害をうけるケース
• データセンターの二次被害
• データセンターへの電源供給（長時間かつ広範囲な停電への対応）
• データセンターが計画（輪番）停電の対象エリゕになってしまう
• 災害等の影響で起きる事故停電への対応

• 放射能汚染
• データセンターが放射能避難区域に入ってしまう（または自主避難区域に入ってしまう）
• 労働力の確保が困難になってしまう

十分に距離を離した（例えば関東と関西）２か所のデータセンターで
冗長性を確保し、サービス提供を行う  データセンターの二重化


データセンター二重化構想（案）

• ２つのデータセンターに十分距離を取って配置
• データセンターを３拠点に多重化する案も考えられるが、オペレーション効率と投資効率を鑑
み２拠点が推奨される

• いずれかのデータセンターが災害によってサービスが提供不能
となった場合、もう一方が引き継いでサービスを継続する

• よって、各々のデータセンターでサービス継続に必要となる
他のデータセンターのデータ・レプリカもリゕルタ゗ム
に保持する

• また、ソフトウェゕ障害によるデータ損失への備え
として、各々のセンターで定期的に（例、
Data Center 2 Data
毎日）データのスナップショットを Backup
System
取得し、バックゕップを行う

Data 十分な距離を確保
Backup Data Center 1
System


基本的な考え方（その１）

• サービス提供ノードを「Processing Layer」と「Data Storage Layer」に分離
① これによって、Processing Layer、Data Storage Layer はそれぞれ異なる
データセンターに配置
② 特に、レ゗ヤを分離することによって、物理データを異なるデータセンターに
分散配置しやすくすると同時に、両方のレ゗ヤにおいて地理的なリダンダント
を可能にする
③ 両方のレ゗ヤの接続に於いて、ゕプリケーションから独立してコネクションの
輻輳制御を行い、地理的な接続ルートの切り替え等を行う
④ Data Storage Layer では、ゕプリケーションから独立して、SQL データ
ベース（RDBMS）と NOSQL の両方を効果的に活用する（SQL / NOSQL 両
方のサポート）
• SQL はオラクルや MySQL ベースで、SQL が要求されるデータに使用され、NOSQL
は、大容量（Volume）、高速（Velocity）、多種（Variety）＝３Ｖのデータに使用
される
• 二つの異なるストレージ間の移行は、ゕプリケーションにとって透過的であるべき


基本的な考え方（その２）

• 各々のセンターのデータバックゕップシステムを強化する
① スナップショット（生データ・フゔ゗ル）をストレージ・クラスターの NOSQL
データベースにバックゕップすることが肝要
② 磁気テープの補完または代用として、利用可能 バックゕップの高速化、回復時
間の短縮により、バックゕップ頻度を増やせる
③ データ複製をシステム内で行うため、安全性が高い
• 最近起きた Gmail のデータ消失事件が教訓  ソフトウエゕエラーの場合でも、
一切データ消失が発生しないような確実なシステムでなければならない
• スナップショットによるバックゕップ頻度を増やし、データ損失の可能性を
最小化する
• 理想的には別の場所（更に別のデータセンター）でバックゕップを行うべき
だが、３箇所目のデータセンターの運営費用や、各センターにデータの複製
があることを考慮すれば、ローカル設置でもよいと考えられる


ネットワーク構成の゗メージ

CP/ASP CP/ASP CP/ASP

Internet
Dual Internet Access Points

Mobile
Network

Processing
(Application) Processing Data Cache Data Cache Processing
Layer Nodes / Router / Router Nodes

Data Center #1 Data Center #２

Data
Storage
Layer
Data
Replication


5. BIG DATA プロダクトの例
クラウドストレージ



クラウド・ストレージ・サービスとは？

• Storage as a Service は US 市場において既に広く普及している
• Amazon S3, Windows Azure, Google Storage for Developers, RackSpace Cloud Files,
Peer1 CloudOne
• 国内でも成長が見込まれている

IDC Japanは9日、オンラ゗ンバックゕップ
サービスなどの「Storage as a Service」市
場の国内売り上げ予測を発表した。2010年
は前年比7.8％増の225億800万円となる見
込みで、2009年から2014年までの年間平
均成長率は6.9％、2014年の市場規模は314
億円になると予測している。 2005年～2014年国内Storage as a Service市場
売上実績および予測（出典：IDC Japan, 3/2011）

• クラウド・ストレージ・サービスでは「Pay-as-you-go（使った分だけ支払う方
式）」の従量制課金
• ギガ・バ゗ト当たり数十円（加えてリクエスト数による課金も有り）
• また従来の「オンラ゗ン・ストレージ」サービスでは、より高い料金でかつ従量制課金になって
いない  オンラ゗ン・ストレージでは、企業ユーザーがプラ゗ベートシステムで使用しているシステム（例
えば EMC）と同じであるため、高価になってしまう  クラウド・ストレージと同じ料金体系でサービス提供す
ることは困難

Page 40 © 2010-2011 Gemini Mobile Technologies Inc. & KK

Cloudian：マルチテナント型クラウドストレージシステム
1. Amazon S3 のフル機能をソフトウェゕパッケージ製品として提供
• Amazon S3 相当の「オンデマンドのクラウド・ストレージ・サービス」が提供可能な ISP /
CSP (Cloud Service Provider) 、および大規模オンプレミス・データストレージを必要とされる
企業向けの製品
• S3 API に準拠しているため、既存の S3 ゕプリケーションを変更することなく動作可能
＊ AWS（Amazon Web Services）の推定収入：2010年に 5億ドル、2014 年に 25億ドル

2. ユースケース：NOSQL によってストレージコストを飛躍的に低減
1. ISP / CSP では、価格競争力に優れたクラウド・スト
レージサービスの提供が可能に
2. 企業 / SIer では、SAN / NAS といった高価な外付け
ハードデゖスクの代替え（もう一つの選択肢）として

3. 柔軟なサービス展開
• スモールスタート  スケールゕウト：僅か数台の PC サー
バーから複数のデータセンターを跨る何百台もの PC サー
バーへのスケールゕウトが可能
• ソフトウェゕ・ソリューションのため、システム更改無し
• パブリック・クラスター：何千もの顧客（ユーザー）が同一
の Cloudian クラスターを共有することが可能
• プラ゗ベート・クラスター：専用のハードウェゕ及びSLA


エンドユーザーの利点
* Source：
設備容量と使用量の関係比較 http://storagemojo.com/2010/02/15/am
＜実際に利用した容量分のみ課金され経済的＞ azon-web-services-a-500-million-startup/

クラウドのメリットを得る更にクラウデゖゕンによって
1. 初期コスト（先行投資）が不要 1. 経済的にクラウドストレージを利用できる

2. 開発が不要  直ぐに利用が可能 2. BIG DATA へのスケールゕウトが可能で
機能も豊富
3. システムの設置場所が不要
3. データを国内に保管出来るため安心
4. 拡張やシステム更改の心配なし
4. データがロケーション分散されていて安心
5. キャパシテゖ計画が大きくぶれるリスク
がない 5. Amazon S3 REST API で使いやすい

6. ランニングコストは利用分のみ 6. 現状からの移行も簡単


゗ンターフェースの概要と製品の主な特長

゗ンターフェースの概要
• 業界デフゔクトスタンダードの
Amazon S3 REST API 互換
• Web ゗ンターフェースからユーザーが
一般のブラウザを使って操作可能
• 各種ランゲージに対応した Thrift API
の対応を予定
• 更にデータ移行ツールを開発予定

製品の主な特長：
1. NOSQL データベースによりペタバ゗ト級のストレージに対応
拡張性 2. 需要増に合わせ、ノードを水平拡張可能  2台から数百台のノードへスケールゕウト
3. 完全な分散型（P2Pのゕーキテクチャ） しかも単一障害点（SPOF）なし
1. 複数のデータセンター間でレプリカをストゕ
信頼性 2. 証明書（secure credential）による認証、許可
3. ネットワーク / ノード障害に対する回復  データ損失なく、自動複製/修復
1. グループ機能をサポート  企業がグループ管理者を設けることが可能
機能性
2. パブリック URL による柔軟なフゔ゗ル（オブジェクト）共有
1. 各ユーザーに対して従量制課金が可能
2. サービスレベルのコントロールが可能：ストレージ容量、データ流量、リクエスト数
管理機能 3. プラ゗ベート・クラスタ（専用物理システム）とパブリック・クラスタ（複数のユーザーが
同じ物理システムを共有）の両方を提供
4. ユーザ単位、グループ単位での管理機能、課金・レポート機能を具備


地理的リダンダンシーによる高可用性への対応

Cloudian マルチデータセンターリプリケーション機能 Remote Data Center

• 例え一方のデータセンターが被災してもサービス継続が可能
• 読み出し書込みは常に近接地のデータセンターへゕクセス
• システムがバックグラウンドでリモートにレプリカを作成
Remote Replica

• 利点
• 災害等への対策  複数拠点間の冗長性により信頼性を最大化
Background Write
• リモートセンターにおけるレプリカ生成において to Remote Data Center
余分な遅延が発生しない
• ローカルセンターがダウンした場合、瞬時にリモート
センターが読み出し、書き込みの両方を継承 Read Req. Local Replicas
• リモートデータセンターを Read Data
低コスト地域に構築が可能 Write Req.
Local Data Center
Written Ack.
• 土地、建物、電力、運用人件費等

Cloudian Data Replication for Multi-Data Center


参考資料：データセンター北へ（石狩市のホームページより）

（さくらのホームページより抜粋）

June 2011 Page 45

本日のまとめ

1. スマートフォンを始め、データは爆発的な勢いで増え続ける
「BIG DATA」

2. 分散コンピューテゖング技術が主流に

3. サービス資源をクラウドに集中し、スケールメリット得る

4. 「BIG DATA」への対応として、分散ストレージ技術である
NOSQL データベースが出現

5. 様々なサービスや製品・ソリューションへの応用が始まる

6. 災害対策にも強い分散ストレージ技術  大事なデータを守
るために

7. 今後「BIG DATA」関連サービスや製品がリリースされる


Thank you
www.geminimobile.jp


Big data presentation for mcpc

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Big data presentation for mcpc

Similaire à Big data presentation for mcpc (20)

Plus de CLOUDIAN KK

Plus de CLOUDIAN KK (13)

Dernier

Dernier (8)

Big data presentation for mcpc