AWS、ニフティ、IIJ GIOのストレージ速度を検証、比較してみた：どれを選ぶ？ パブリッククラウド比較【第3回】
Amazon Web Services（AWS）、ニフティクラウド、IIJ GIOのストレージサービスの処理速度を比較検証した。
今回は、IaaS（Infrastructure as a Service）について解説していきたいと思う。
「今さら聞けない！ 各種クラウドサービスの違い」にも書いたように、IaaSはPaaSよりさらに柔軟な運用が可能な形態、平たく言えば仮想サーバを借りてインターネット越しに利用するサービスだ。ホスティングサービス（専用サーバレンタルなど）と大きく異なる点としては、料金の支払い体系とサーバ構築の速さ、自由度が挙げられる。
AWS、ニフティクラウド、IIJ GIOのストレージを比較
今回筆者は、IaaSストレージサービスの1つである「ニフティクラウドストレージ」に触れる機会があった。ニフティクラウドストレージはこの分野のパイオニア的存在である「Amazon Simple Storage Service（Amazon S3）」との互換性の高さをうたう。ストレージに対してHTTPを用いたシンプルなRESTベースのAPIでアクセス可能な、分散型オブジェクトストレージだ。
せっかくの機会なので、本家的な存在であるAmazon S3、そして国内大手である「IIJ GIOストレージサービス」を同時に使い、簡単に比較を行った。ちなみにIIJ GIOサービスには、Windowsのファイル共有サービスを提供するプロトコルであるCIFSをサポートしたFS/S（CIFS）と、Amazon S3相当のHTTPS／RESTインタフェースをAPIとして提供するFV/Sがある。Amazon S3、ニフティクラウドストレージと合わせて、IIJ GIOでは後者のFV/Sを選択した。
主にコンシューマ向けのクラウドストレージでは、Google DocsやDropbox、Windows Live Sky Driveも有名だが、基本的にビジネス向けのサービスを選択した。最初に断っておくが、今回の試用はカーレースでいうところの「理想の条件下で最速ラップを1000分の1秒単位で計測する」といったような「最大パフォーマンスの計測」ではなく、ごく一般的な環境で実際に試してみたというレベルでの比較にすぎない。よって各サービスともこの試用結果がそのまま性能値といえるわけではないことをあらかじめお断りしておく。
試したクライアント環境は以下の通りだ。
| 項目 | 環境 |
|---|---|
| 場所 | 都内某所 |
| CPU | Intel Xeonプロセッサー X3440 @ 2.53GHz x2 |
| メモリ | 2Gバイト |
| OS | Debian GNU/Linux 6.0 |
| 回線 | UCOM 100Mbpsライン |
まさしく「手近にある環境でちょっと試してみた」というレベルの試用だが、同一の処理を10回繰り返して平均を取ることで、できるだけブレの少ない比較を試みた（※1）。結果については以下の表をご覧いただきたい。
※1 ベンチマークテストは、比較的空いている深夜の時間帯に実施した（追記：2012年3月9日17時30分）。
| Amazon S3（東京） | ニフティクラウドストレージ | IIJ GIOストレージサービス | |
|---|---|---|---|
| 512バイト シーケンシャルアクセス（PUT） | 5.862680991 QPS | 18.28045099 QPS | 4.029765622 QPS |
| 512バイト シーケンシャルアクセス（GET） | 7.062949655 QPS | 46.25614254 QPS | 13.80952078 QPS |
| 【Min】100Mバイト×5回 スループット(PUT） | 9.742660104 Mbps | 3.742924787 Mbps | 2.294348988 Mbps |
| 【Max】100Mバイト×5回 スループット（PUT) | 77.94128083 Mbps | 29.94339829 Mbps | 18.35479191 Mbps |
| 【Min】100Mバイト×5回 スループット（GET） | 11.61423999 Mbps | 3.972594785 Mbps | 10.2984832 Mbps |
| 【Max】100Mバイト×5回 スループット（GET) | 92.9139199 Mbps | 31.78075828 Mbps | 82.38786564 Mbps |
| s3fs mount（R／W） | OK | OK | NG |
| s3fs mount（List） | OK | NG | NG |
| ping | 2.38ms | ― | 11.5ms |
計測したのは512バイトという小さいファイルを外部からクラウドへPUT／GETした際の平均QPS（Query Per Second）と、100Mバイトのファイルを外部からクラウドへ5回PUT／GETした際のスループット（FTP測定値）だ。後者に関しては最低（Min）／最高（Max）の数値を記している。
その結果、まずシーケンシャルアクセスについてはPUT／GET共にニフティクラウドストレージが非常に高速だった。ここでいうシーケンシャルアクセスというのは、先頭から順番に読み書きするという意味ではなく、ドライブ内で連続した1つの領域に対する読み書きを指す。ファイルコピーや大きなデータファイルを開くなどの処理速度に大きく影響する。つまり、ニフティクラウドストレージはクラウド上でのファイル操作やコピーのような作業の場として利用するには、非常に適しているであろうことが想像できる。
一方で、比較的大きな100Mバイトのファイルについて5回連続PUT／GETのスループット（FTP測定値）を計測した平均数値は、Amazon S3の性能がかなり高かった。ちなみにスループットは処理能力の指標であり、高ければ高いほど高速といえるが、もう1つの要素であるレイテンシ（遅延）の値が小さくないと、一概にストレージ性能が高いとはいえない。スループットは処理の多重度を上げて向上することも可能だ。
試しにpingを打って応答速度を測ってみたのだが、Amazon S3はなかなかに優秀だった。Amazon S3に対しては以前使った際の記憶から、比較的レイテンシが大きいイメージを勝手に持っていたのだが、2011年3月に東京にできたデータセンターの効果だろうか、実際には思っていたよりはるかに良好な数値だった。またニフティクラウドについては80／443TCPポート以外のアクセスを拒否している仕様から、pingを打っても返ってこなかった。
ちなみに、今回は同一の条件下での比較に絞ったが、ニフティクラウドストレージはmultipartアップロードという独自の機能を持っており、これを利用することでスループットの高速化を図ることも可能だ。
Amazon EC2／S3に関する記事
IIJ GIOストレージサービスについては、どちらのテストでも平均的な成績を収め、特に強い／弱いといった特徴は見受けられなかった。言い方を換えればどの条件下でも安定した数値を見せており、テスト結果からは比較的用途やユーザーを選ばず利用できるサービスだと感じた。
ところで、Amazon S3をローカルストレージと同じように扱うことのできる「s3fs」というツールがある。利用した経験のある読者もいると思う。かなり意地悪なテストだが、Amazon S3互換／S3相当とうたっている他のサービスでこれがそのまま利用できるかどうかも試してみた。
最初からどれも恐らくNGだろうと予想して試したのだが、意外にもニフティクラウドストレージはマウントし、読み書きすることができた。もちろんAmazon S3と全く同じというわけではなく、利用できる機能などにも制限はある（※2）。だが、一応の互換性は確認できているため、現在Amazon S3を利用している人が併用したり移行したりするハードルは比較的低いといえるだろう。
※2 表中の「s3fs mount（List）」参照（追記：2012年3月9日17時30分）。
まとめ
今回紹介したサービスはどれも使いやすく、パフォーマンスや信頼性が高い最新の分散型オブジェクトストレージだ。オンプレミス同様、運用時のセキュリティを自前で管理する必要はあるのだが、これまで難しかったサーバや大容量ストレージの短期間利用やディザスタリカバリを、簡単かつリーズナブルな価格で実現できる最新のIaaSは素晴らしいと思う。
コラム：「オブジェクトストレージ」と「分散ストレージ」の違い
最近よく耳にするようになったキーワードに「オブジェクトストレージ」と「分散ストレージ」がある。この2つはどのような違いがあるのだろうか。まずオブジェクトストレージは、ファイル単位ではなくオブジェクト単位でデータを管理するストレージである。比較的アクセス回数や変更頻度が少ないデータを扱うアーカイブストレージに向いており、優れたスケーラビリティを備えている。
現在デジタルコンテンツの容量は爆発的に増大しており、かつ9割のデータはめったにアクセスしたり更新したりされないという調査結果も耳にする。こうしためったに触らないデータを保管するためには、処理能力よりもスケーラビリティとコストパフォーマンスの高さ、かつ改ざん防止や管理の容易さが要求される。オブジェクトストレージは、こうしたニーズに応える1つの完成形ともいえる。
ところで、スケールアウトという言葉は「柔軟に容量の増減が可能」というポジティブなキーワードとして用いられることが多い。確かにそういう側面はあるが、しかし一方で、使用機器の数が増えれば当然、故障というリスクが増大するというマイナスの要素も併せ持つ。単にアクセス速度が高ければ何でもいいなどと一概に言うことはできないのだ。例えば東日本大震災以来、急速に意識が高まっている「災害時のデータ消失対策（ディザスタリカバリ）」という点も極めて重要である（関連記事：パブリッククラウドは災害対策で役に立つのか？ AWSとGIOも検証））。加えてグローバル企業においては世界中どこにいても同様のアクセシビリティが得られることが望ましく、また出入国時の端末没収などへの対案も必要だ。単に容量を大きくし速度を高めるという点のみに注力するのではなく、オブジェクトを幾重にも冗長保存するような仕組みが望ましい。
こうした課題に対する解の1つが「分散ストレージ」と呼ばれるものである。これは、データを保存するストレージ（データセンター）を複数の場所に分散配置してデータをミラーリングし、それら個々のストレージを束ねて1つの長大なストレージプールとして管理するというものだ。複数地域に分散しておけば、その分だけ有事の際にもデータ消失のリスクは減少する。究極的には天災や戦争などによる被災、世界各地からのアクセシビリティなどを踏まえると世界中のあらゆる地域のデータセンターに分散して管理するシステムが理想だろう。
中山貴禎（なかやま たかよし）
ネットエージェント 取締役
主にコンシューマ市場を中心にさまざまな業界を渡り歩き、2008年ネットエージェント入社、2010年より現職。ジェネラリストとして各種企画および技術部門を統括。また、機密情報の外部流出対策製品のプロダクトマネジャーも兼務し、自ら知財も取得するなど活動範囲は広い。
執筆・講演活動では、広く一般の方々に向け、誰もがITや情報セキュリティなどの最も肝心な部分をきちんと理解でき、普段の生活に生かせるような解説方法を模索中。
Copyright © ITmedia, Inc. All Rights Reserved.