1

ジャストプレイヤー株式会社代表取締役 CEO 兼 CTO

瀧　康史 /TAKI,Yasushi

Solarisだからできた1サーバあたり2000ユーザを越える

高収容ストレージクラウドの裏側

２０１5/12/09

2

JUSTPLAYER → すぐに遊べるソフトウェアの開発

When You Want Is When You Play → 欲しい時が、遊ぶ時

ジャストプレイヤー株式会社について

Usability

Contents Management

Server-SideProgram

Cloud Technology

事業内容 . クラウドインフラ賃貸事業、ホスティング賃貸事業 . クラウドコンサルティング業務 . クラウドソフトウェア制作事業

その他 . 電気通信事業者 C-18-1421 . 静岡県中小企業新事業活動促進法に基づく、経営革新計画の承認(WIKIP-LUS)

3

事業内容クラウドサービス

. SaaS? PaaS? . TeraCLOUD . 1TB/月額980円の高速・ストレージ・クラウド

. IaaS . Solaris SPARCプライベートクラウド . Solaris 11 x64 VPS/クラウド . Linux/Windows クラウド . ウェブ・ホスティング (Solaris / Redhat Enterprise Linux)

4

事業内容 /2 . ソフトウェア . WIKIPLUS Enterprise . 高速、高機能なEnterprise向けCMS . http://www.wikiplus.jp/ . オンプレミス販売、クラウドサービス . パートナー募集中

5

. ジャストプレイヤー株式会社 代表取締役CEO兼CTO . 出身地 . 静岡市（旧清水市） . 業務履歴 . ライター業（テクニカルライター） . S社’X紙’（S社のパソコン向け雑誌） . S社にてS社用ゲーム機のゲームソフト開発 . ゲームディレクター、アシスタントプロデューサ−、プランナー . 2001年、起業より、代表取締役社長 . 2014年12月、代表取締役CEO兼CTO . その他 . FINO(富士の国インターネット)：理事 . 日本OpenSolarisUsersGroup Leader

自己紹介 : 瀧　康史（@kohju）

やすし虫

6

基本的には”技術背景をお話しするセッション”です。

. TeraCLOUD(http://teracloud.jp)とは . なぜ生まれたか？ . どういうサービスか？

. ジャストプレイヤー株式会社(http://www.justplayer.ne.jp)の・・・・・・ . クラウド基盤の裏側、CPUノード、ストレージ . Solarisだからできること

. TeraCLOUDの構造 . ストレージ・クラウドの構造 . Solarisだからできること

. まとめ

Agenda

7

ストレージ・クラウド、TeraCLOUDの特徴 . 安価 . 1TB 月額980円/年額9,800円 . 大容量 . 無料10G、有料1TB、最大10TB . 高速 . Internet的、サーバ的な最適化 . 安全 . ZFSのトリプルパリティ。 . エンドポイント・データ保護 . オープンプロトコルで対応ソフトが多い . WebDAV over SSL

「ZFS over WebDAV+REST API」的な形

TeraCLOUD について

8

「僕の」個人的な希望から・・・・・・

. ファミリーのデータ(写真、ビデオ)を安全に保存したい。 . 古いものはデジカメのデータ(解像度Upでjpgのサイズも倍増している) . 5〜6年前からMovieも混じり始めた(スマホ、デジカム、動画対応デジカメ) . 8mm/DV/HDVなどをデータ化するサービスを利用し、過去のデータもデジタル化

「私は」自社のクラウドに置けないことはないが、データ量が大きすぎる(4TB〜)

周りの人に聞いてみると・・・・・・

. パソコンに保存していた写真が消えてしまい、子供の写真を紛失→家族問題

. 災害で家がなくなり、想い出の写真がない。

なぜ生まれたか？

9

他社のクラウドサービスはどうか？(TeraCLOUDのサービススタート当時)

. 容量が少ない(100GB程度が多かった) . 無制限は「個人的に」信用できない。 . 容量を上げると、コストが跳ねる。1ヶ月1TB1000円未満がいいなぁ。。。 . 海外物だとデータの権利が良く分からないのが多い。

. ネットワーク的に遠いので遅い。

個人的に「びびっ！」っと来るサービスが見つからないので、自社でやることを検討

時代背景

10

事業化の検討

. 技術セッションなので割愛・・・・・・。原価を下げるための努力があるレベルで。

技術的に可能か？

. ストレージサイドの技術 . 自社クラウドのSANストレージの技術があるので流用可能か？

. ネットワーク側の技術 . 自社でやっている大量配信の技術が応用可能か？

. アプリケーションサーバ側の技術 . 自社のサーバ構築技術と某オープンソースを利用して対応可能か？

なんとか、作れるんじゃないの？と考えた。

事業化の検討

11

しんどかった・・・・

12

. 複数の仮想化基盤が織り交ぜられている。

. ネットワークはtagVLANで分割。プロビジョニング系とはIP的に隔離。

. S A N ストレ ー ジ は i S C S I /iSER(IB)を利用。

. SSD系とハイブリッドストレージ。

. 2 つ の シャシー でFail Over。

. 異 拠 点 へ のAsync Mirror

当社クラウド基盤について

Controller Co

ntr

olle

r

Storage Server

HBA

iSCSI SAN Switch

Storage Server

iSCSI target

Storage Server

iSCSI target

SPARCLDOMs

x64Solaris 11

x64Xen Server

L.A. L.A.

L.A.L.A. L.A.

HBA

Storage Server

iSCSI SAN Switch

Storage Array Storage Array

Virtual Servers

SOME Volume

build by

RAID-60(SAS-HDD)

with L2ARC

with SLOG

L.A. L.A.

IPMP IPMP

Con

trol

ler

Storage Server

HBA

Storage Array

a-syncronous mirror

by zfs send & recv

to other far-DC

for DR and backup

VirtualServer

VirtualServer

VirtualServer

VirtualServer

VirtualServer

VirtualServer

VirtualServer

VirtualServer

Separated.un reachable by IP.

SOME Volume

build by

RAID-60(SAS-HDD)

with L2ARC

with SLOG

L2ARC(Read Cache) L2ARC(Read Cache)

HBAHBASSD RAID-Z SSD RAID-Z

stack

。。。。。。。

。。。。。。。

。。。。。。。

。。。。。。。

SOME Volume

build by

RAID-60(SAS-HDD)

with L2ARC

with SLOG

L2ARC(Read Cache)

13

4種類の仮想システム

. Solaris SPARC . Oracle VM for SPARC (LDOMs)

. Solaris x64 . Oracle Solaris Zones

. Linux/Windows . VMware ESXi . XenServer

それぞれ得手不得手がある。

dockerはこれから・・・・・・

Virtualization

SPARCLDOMs

x64Solaris 11

x64Xen Server

L.A.L.A. L.A.

Virtual Servers

VirtualServer

VirtualServer

VirtualServer

VirtualServer

VirtualServer

VirtualServer

VirtualServer

VirtualServer

Separated.un reachable by IP.

。。。。。

。。。。。

14

ZFSを用いたOracle Solaris 11ベースのストレージシステム

. 1セットあたりシャシー2系統のストレージ . 1系統が破損しても、もう1系統あり . 仮想化側がOracle VM for SPARC、Oracle Solaris Zonesの場合は、そちら側でミラーを行い、フェイルオーバー可。その他の場合は、非同期ミラーで手動切り替え。

. 地理的に離れた異拠点への非同期ミラー . zfs send & receive。

. マルチレイヤーのSnapshot

. マルチテナントによるIP隔離された仮想NAS。

専用機に比べて超安価、Linux/BSDベースのミドルウェアに比べても安価。

SAN Storage

Controller Co

ntr

olle

r

Storage Server

HBA

Storage Server

iSCSI target

Storage Server

iSCSI target

L.A. L.A.

HBA

Storage Server

Storage Array Storage Array

SOME Volume

build by

RAID-60(SAS-HDD)

with L2ARC

with SLOG

L.A. L.A.

IPMP IPMP

Con

trol

ler

Storage Server

HBA

Storage Array

a-syncronous mirror

by zfs send & recv

to other far-DC

for DR and backupSOME Volume

build by

RAID-60(SAS-HDD)

with L2ARC

with SLOG

L2ARC(Read Cache) L2ARC(Read Cache)

HBAHBASSD RAID-Z SSD RAID-Z

。。。。。。。

SOME Volume

build by

RAID-60(SAS-HDD)

with L2ARC

with SLOG

L2ARC(Read Cache)

15

このSolarisベースのSAN Storageは幾つかの問題を抱え、解決されてきた。

. ディスク無応答による切断問題 . SASにする方が良い

. Fail Overの失敗問題 . SAS、ドライバー、OSのアップデートなど

. 仮想化による弊害 . Rawデバイスによる仮想化を重ね、IO Request Amplified？が起きてる? . マトリョーシカ問題

. IOPS問題 . 期待値＝1/(平均アクセスタイム+60/RPM)。 . スケールアップか分散か？

SAN Storage の抱えた問題

16

高負荷時にディスクが切断されてしまい、RAIDがDegradeする。

壊れた時のFail Overがままならないときもある。

. SATAディスクはIDEのDMAプロトコルを踏襲したハンドシェイク。 . HostからRead Request→Deviceは転送準備 . HostはDeviceから送られるDMAポートを待つ→Deviceは送り始める。 . 何かの理由でここで応答しないと、上位層でTIMEOUTしかない→原因不明のDegrade。

. Expanderを使う場合：レーンを専有問題 . SATAディスクの応答が悪いとき、レーンを専有し続ける。 . その結果他のディスクの応答も悪くなり、連鎖ディスク切断→RAID崩壊

解決策： IO負荷をかけない or すべてSASにする。

ディスク切断と Fail Over 失敗

17

ストレージの仮想化が重ね合わされると様々な問題が起きる

. IO Request Amplified問題(僕の造語) . アプリケーション層の実際のIOリクエスト量にくらべ、明らかに多いIOがSAN Storage側に発生する。 . IOのリクエストラインが揃わないのではないか？ . window size, commit timing, etc..

. マトリョーシカ問題(僕の造語) . 外のボリュームが健全でも、中が崩れることがある。 . ZFS→zvol→vmfs→vmdk→NTFS→アプリケーション . どこか一つが壊れたら、データの救出ができない。

ストレージ仮想化の弊害

18

IOPSをあげる為には2つの方法がある

. スケールアップ . SSDにする。SSDのIOPSは10000を優に超えるので桁違い。 . ルートボリュームや、DB用にはこちらがいいかもしれない。

. データストアの場所分散 . データストアの場所をOSが入った箇所と別の場所にする。 . 分散オブジェクトストレージにしてアプリを作り替える。 . データベースアプライアンスに置く(ODAとかExadataとか) . ファイルサーバを別途用意する→マルチテナント型のNASを用意 . NFS . CIFS

スケールアップか？分散なのか？

19

TeraCLOUDのシステム要件

. 調達コストが安価でなくては継続事業にならない . AmazonS3とかを使うのはない

. 沢山のユーザが高速につなげなくてはならない。 . 1ユーザあたりのリソース消費量を極小化する必要がある

. 各サーバの独立性をあげたい→全ユーザインシデントを避けたい！ . ○○サーバが壊れたら→全ユーザインシデント。 . ○○の論理チェインが壊れた→全ユーザインシデント。 . つまり、N+p、NxM設計ではない、ノード指向アーキテクチャ。

TeraCLOUD では、どうするか？

20

要件を踏まえての構想

. 分散オブジェクト・ストレージは使わない . ハードウェア面で高くなりがち(安くできない) . 速度面で不利(レスポンス性の高さを売りにしたかったため)

. SAN Storageのような、rawボリュームの仮想化を使わない . IO Request Amplified?問題が怖い。 . マトリョーシカ問題は絶対に防ぎたい。

. 同時アクセス数を増やしたい . 1セッションインスタンスのメモリ利用量が少ないようにする

TeraCLOUD 設計前の初期構想

21

アプリケーション・サーバ経由でオブジェクトストレージに分散するケース

. リクエストのレスポンス単位が遅い

. 結局は、N+pに分散されたディスク毎に「CPUが着いている」とも考えられるので、高コストになりがち。

分散オブジェクトストレージの場合

ApplicationServer

ApplicationServer

User PC

User PC

クライアントがオブジェクトストレージに分散するケース

. リクエストのレスポンス単位はそこそこ。

. やはりN+pに分散されたディスク毎に「CPUが着いている」ので高コスト。

22

いわゆるRAID6などと違い、RAID Z構造ならば、こんな構造だと考えられる。

1つ1つにCPUが必要が無いので、分散オブジェクトストレージに比べると低コストになる。

IOPS的には不利だが、

Internet経由では少ないだろう。

よし、これでいこう！

RAID Z 構造

ApplicationServer

ApplicationServer

User PC

23

(右図)いわゆるSAN Storage的なアプローチでは、事実上のプロトコル変換がおき、IO Req.が多く増加し、Storage側のCacheが余り効かない。

(下図)一方、Storage Serverに相当するシステムで、WebServerを行えば、行うことが明確にな

り、Cacheの効果が大きく出る。

プロトコル変換をなるべく使わない

Web ServerCon

troller

HBA

Storage Array

RAID-Z3 (Triple Parity)

Separeted by Internet

Cache

SAN Storage TARGET

L2ARC(Read Cache)

Client PC

SAN Switch

Controller

HBA

Storage Array

RAID-Z3 (Triple Parity)

Separeted by Internet

Web Server

L2ARC(Read Cache)

vvererrerver

Client PC

24

理論上、1インスタンスのメモリ利用量を下げれば、コストは下がる。

(U)はUsed。(A)はAvailable。

Uで埋め尽くされると、次に来たユーザは接続不能になる。つまり「落ちた」ように見える。

. 上では4x7＝28のスロット

. 下では6x11＝66のスロット

同じ搭載メモリでも、1インスタンス毎のワークメモリが小さいければ、コストは下げられる。

一般に、Fork型よりもThread型、Event Drivenの方が低消費メモリ/ins。

並列性をあげるために……

U A U

A

U

A

U

A

U

AU A

U U

U

U U

U

U

U U UU U

U

A

U

U

U A U

A

U

A

U

A

U

AU A

U U

U

U U

U

U

U U UU U

U

A

U

U

A A

U

U

AU A

U U

UU

U U

U

A A

A

UU

U UU

U

U A

U

A

A

U

U

A A

U

U

U AU

U

25

システムセット

. アカウント系 . ユーザID、決済など。基本的にはTeraCLOUDの世界で1セットしかない。

. ストレージ系(Node Server) . ユーザ用ストレージデータが入る . アカウント系サーバがなくても独立して動き、完全にスケールアウトする . DCの場所を選ばない(実際、特定のプロバイダ向けのセットの構築も) . ZFSを使いたいので、どうしてもSolarisで作りたい。

. コンテンツ系 . Webコンテンツが入る。 . キャンペーンサイト、FAQ、マニュアルなど。 . 当社のEnterprise CMSシステム、WIKIPLUSを利用。 . 先日、10年の満を持してVer.4がでました。

第 1期設計 (2014 年1月 )

26

第 1期設計 (2014 年1月 )/HWハードウェア・OS

. アカウント系 . 弊社のIaaSインフラを流用。結局、Solaris。x64/SPARCのハイブリッド。

. ストレージ系 . SAN Storageのセットを流用。Solarisで動かすことが必須。 . StorageはRAID-Z3(SANと比べてIOが少ないだろうと想定) . ATO(Assemble To Order)で発注されたもの . 必要なスペックを決め、当社でSolaris11が動くことが確認できているCPU、M/B、HBA等の組み合わせ選び、適合するものをまとめて購入。

. コンテンツ系 . 弊社のIaaSインフラを流用。結局、Solaris。x64。

27

アプリケーション層のソフトウェア

. アカウント系・コンテンツ系 . 自社で作るしかない。決済なども含め。

. ストレージ系 . TeraCLOUDのサービススタート時には、ソフトウェア制作の工数が用意できない。 . リリース時期を優先する→結果的に良かった。 . オープンソース、他社のソフトなどを利用する。 . Windows、Mac、Web、iOS、Androidのアプリケーションがすでに存在してるソフトを優先。 . データがそのソフトと密依存だと、最悪、抽出が不可能になるので、そういうアーキテクチャは避ける。

結果、某OpenSourceを使うことになったが、AppServerがPHPとなった。

第 1期設計 (2014 年1月 )/App

28

基本的なダイアグラムは次の通り

. コンテンツ系(WebServer、WIKIPLUS)

. アカウント系(Account Server、DB)

. ストレージ系(Node Server)

基本、コンテンツ系は独立して動き、AccountからNodeへメッセージを送る

第 1期ダイアグラム

Account DB

Web Server

WebContents ServerWIKIPLUS

Node Server Node Server Node Server Node Server

……ノード・サーバ群( 実際のストレージサービス )

Account Server

※アカウントサーバからノードサーバへメッセージを送る

29

PHPである以上いくつか問題を抱えこむが、とりあえず、WIKIPLUSのノウハウをつぎ込んで無理矢理緩和させる。

. 速度 . コンパイルキャッシュ(opcache)などで緩和させる。

. サイズ . ある程度は、FastCGIなどを使えば緩和できる。

. 異常系処理 . アプリの設計の問題にも関わるので、どうにもならない。

どちらにせよ、本質的な解決方法はない。

第 1期 Node Server

30

. Apacheをworkerで動かすことで、size/insを小型化する。

. PHPはFastCGIで常駐させる。1つのインスタンスが大きいため、1つのマシンの割当には限界がある。

よし、これでスタートしよう！

第 1期 Node Server/PHP

U A U

A

U

A

U

A

U

AU A

U U

U

U U

U

U

U U UU U

U

A

U

U

A A

U

U

AU A

U U

UU

U U

U

A A

A

UU

U UU

U

U A

U

A

A

U

U

A A

U

U

U AU

U

U A U

A

U

A

U

A

U

AU A

U U

U

U U

U

U

U U UU U

U

A

U

U

A A

U

U

AU A

U U

UU

U U

U

A A

A

UU

U UU

U

U A

U

A

A

U

U

A A

U

U

U AU

U

U

A

U

U

AU

AU A

U U

U

U

U

A A

A

UU

U UU

A A

U

U

U AU

U

U A U

A

U

A

U

A

U

AU A

U U

U

U U

U

U

U U UU U

U

A

U

U

A

U

U

UU

U

U

U A

U

A

A

U

U

U A U

A

U

A

U

U

U A

U

U

U

U

U

U A

A U

U

U A

U

U

A

A

U U

U

A

APHPServPHPHUU PSerPSerUUPServ

Storage

.php

Apache

other

31

ミドルウェアが持っていた問題

. phpのメモリ枯渇問題。

. グラフィックライブラリのメモリ飽和問題。

. 想定外のライトIO問題 . HBA(RAIDカード)の負荷を越えてしまうレベル

第 1期で発生した問題

32

. 想定外のライトIO問題 . ミドルウェアが、想定を越える程のIOを発生させる。 . 並列度を高めたことで、同時セッションの数、並列ライトが走る。 . サーバ落ちそう！

. 解決方法 . 原因究明と平行で、全てのNodeServerのハードウェアを増強 . SANに近いクラスのハイスピードのSANストレージを流用。 . MySQL専用としてPCIのSSDを利用(原因の一つとわかっていたので)

正直、色んな意味で、

やばい、やっちまった・・・・・・と思いました

第 2 期 (2014 年 2 月 )

33

. phpのメモリ枯渇問題 . グラフィックライブラリのメモリ飽和問題。 . 想定外のIO問題 . RAIDカードが負荷を越えてしまうレベル . MySQLのDB問題 . ファイル容量制限 . Quotaの為に凄まじいリソースを要求 . Quotaの抜け道問題 . 1セッション当のメモリ利用の多さ . サムネイル問題 . WebDAVの書き込みSync問題 . phpで作られたWebDAV Stackの弊害 . あるクライアントのトランザクションの異常系で、ファイルロストがあり得る。

第 2 期時点のでの問題の整理

そもそもミドルウェアが、

沢山のユーザ向けのものではない

34

問題解決のために、

真実の原因究明と、

解決策探求が急務に・・・・・・

ハード高速化で乗り切れる時間はわずか。

我々に残された時間はほんのわずかだった。

第 3 期設計 (2014 年 4 月 )

35

DTraceやSolarisの解析ツールによる本番機の分析を続け、真実の探求をした。 . 容量計算問題 . MySQL DBに過剰な負荷がかかる . ファイルをアップロードする毎に、ファイルサイズをDBに入れる . 収容されるディレクトリ毎にDBに保存しておく。それ以外のファイルがあったらFSTATしてサイズをDBに入れる . これをリカーシブにすると、一番上ではサイズがわかる . ディスクに過剰なWrite IOを発生させる . WebDAVのファイルPUT時→容量計算の為のSELECT! . 部分アップロード→毎回SYNC . アップロード完了→ポスト処理にコピーや画像サムネイル作成、DBへのINSERT等

→高速な容量計算方法を考えるしかない！

第 3 期設計 (2014 年 4 月 )

36

解決策のために！ . ユーザ毎にZFSのdatasetを与える . DBのIOを軽減させるため . zfsだとdataset単位で容量がわかる . Quota問題の解決 . dataset単位で容量を制限できる . 移設には、zfsのShadow Migrationを利用 . ZFSのARCバッファ調整 . IOは、Write：95％：Read5％程度！ . データはキャッシュせずメタデータのみキャッシュする。primarycache=metadata . SSDが総データ量の割に相対的に少ない。加えてライトばかりだと、MRUがほとんど効果がない。MFUを上手く選別するヒント情報が少ない。 . それよりも、ユーザ毎にdatasetを渡しているので、確実にmeta情報をキャッシュしたい。

第 3 期設計 (2014 年 4 月 )/2

37

. Fast WebDAVをサポート . mod_davベースのwebdav。Apache製なのでソフトとの互換性も○。 . C言語で書かれ、Treadタイプなので、リソース利用量低い。そして高速。 . Sync量の大幅軽減→WriteのIO Requestを下げる . PHPベースのWebDAV Stackでは、リクエストを適度なサイズでファイルを分割しながら処理、コミット処理も多くなる。 . 本来、WebDAVはPUTにレジュームがないので、fsyncは最後で良い . Third Partyアプリユーザに対する新DAVのPATH誘導。 . phpのメモリリソース過剰利用を大幅に軽減。 . 独自クライアント . Fast WebDAVを使うWindows用の独自クライアントを用意 . 出来は今ひとつだが、ファイル・ロストが構造的に発生しない仕組みに……

負荷が軽減したので、RAID-Z3に戻す見通しが立った！

38

. phpのメモリ枯渇問題 . グラフィックライブラリのメモリ飽和問題。←コッソリ治す . 想定外のIO問題 . RAIDカードが負荷を越えてしまうレ

ベル . MySQLのDBの問題 . ファイル容量制限 . Quotaの為に凄まじいリソースを要求 . Quotaの抜け道問題 . WebDAVの書き込みSync問題 . phpで作られたWebDAV Stackの弊害 . トランザクションミスもありえる

第 3 期で解決したこと

負荷低減で高収容化！1nodeで2000user 突破！

※10k overも視野に・・・

39

. 1セッション当のメモリ利用の多さ . サムネイル問題

. WEBUIが重く、リソースを使う。

. アカウント系←→ストレージ系の情報連結が弱すぎる。 . キャンペーンや告知が難しい。 . アカウントサーバがディスク溢れなどを知らない。

. サーバ障害時の修正手段が不足

. 独自クライアントの機能不足

第 3 期で残る問題

40

アカウント系←→ストレージ系の情報連結を強化するための修正

. テラクラウドのサーバ群の間で共通のメッセージバスを用意 . メッセージの追加を容易に . ストレージ系(NodeServer)の独立性を高めたままにする

. REST APIの公開、第1弾

第 4 期設計 (2015 年 4 月 )

41

第4期TeraCLOUDダイアグラムの特徴

. TeraCLOUD Messaging BUSの導入 . 遅延があっても構わないバスアーキテクチャ

. Node Server群は単体でも動く . RTT的に遠いDCでも動作が可能

第 4 期ダイアグラム

Account Server

Account DB

Node Server

Batch Server

Web Server

WebContents ServerWIKIPLUS

Login ServerClient GatewayNode Server Node Server Node Server

……TeraCLOUD Messaging BUS

アカウンティング・情報系のサーバ群

ノード・サーバ群( 実際のストレージサービス )

キャンペーンや、アカウントサーバでの情報収集が可能に！

42

現時点の問題

. 1セッション当のメモリ利用の多さ . サムネイル問題

. WEBUIが重く、リソースを使う。

. サーバ障害時の修正手段が不足

. 独自クライアントの機能不足

第 4 期に残る問題点

43

. TeraCLOUD CLUSTER : a pair of node-servers . TeraCLOUDのためのクラスタ・アーキテクチャ . Native Zoneを使って、たすき掛けでノード情報を持ち合う

→ハードウェア障害時のダウンタイムが極小化できる！

. PHPミドルウェアの段階的な廃止 . AJAX dav client+Fast WebDAV＋REST API

→100,000+/node serverが視野内に！

. REST-APIの公開と強化

→3rd party アプリベンダとの関係強化

今後の TeraCLOUD について

44

TeraCLOUDはSolarisだから実現した機能が沢山あります。

. zfsだからできること . ストレージの管理のしやすさ . 豊富な機能

. 性能評価のしやすさ

. システム移設のしやすさ

. コストパフォーマンスの高さ

Solaris だから実現したこと

45