有名なS3マウントツール2つを比較してみた

# はじめに
この記事は[BeeX Advent Calendar 2020](https://qiita.com/advent-calendar/2020/beex)の12/5の記事です。

# やったこと
WindowsでS3をネットワークドライブとしてマウントすることが可能な以下の2つのツールについて比較してみました。

・CloudBerry Drive → https://www.msp360.com/drive.aspx
・JPCYBER S3 Drive → https://www.jpcyber.com/download

# なぜやったか
どちらとも一応使ったことはあるけどちゃんと比較したことはなく、何が違うのか確認したかったので。

# 検証環境
・AWS EC2(Windows Server 2019)

# ホームページ上から読み取れるデータで比較
MSP360のページの情報がJPCYBERに比べるとかなり少なかったので、比較要素は少なかったですが、まずはそれぞれの紹介ページの情報で比較してみます。

|-|CloudBerryDrive|JPCYBER|
|:-:|:-:|:-:|
|無料期間|15日間|30日間|
|料金|Windows Desktop：49.99ドル<br>Windows Server：119.99ドル|Drive Desktop：7980円<br>Drive Server：12800円<br>Drive Enterprise：19800円|
|ライセンス体系|買い切り型<br>(コンピュータ単位)|サブスクリプション型<br>(コンピュータ単位かつ1年間)|
|使用可能な主要クラウドサービス|AWS<br>Google Cloud<br>Azure<br>Alibaba等|AWS<br>Google Cloud<br>※Azure,Ailbabaは未掲載|
|Marketplaceでの購入|可能|不可|
|運営会社|MSP360<br>旧CloudBerry Drive|JPCYBER, Inc.|

料金とライセンス体系には明らかな違いがあり、CloudBerry Driveが買い切りで最大1万ちょいなところ、JPCYBERは年間サブスクリプション型で一番高額なEnterpriseは約2万と、CloudBerry Driveと比べると少しお高めです。

世界シェア的にはマウント可能なクラウドストレージサービスの多いCloudBerry Driveに軍配が上がりますが、日本の会社が運営しているので日本企業で導入するのであればサポートの面からJPCYBERはよさそうです。

# 実際の設定を比較
次にそれぞれ無料版をインストールして、その設定内容について比較していきます。
尚、無料版のインストール方法も異なります。

|CloudBerryDrive|JPCYBER|
|:-:|:-:|
|メールアドレスを入力してダウンロード<br>起動時にメールアドレスを入力|ページからダウンロード<br>起動時にページに記載のライセンスキーを入力|

## 設定画面
最初の設定画面はCloudBerry Driveに比べて、JPCYBERのほうがすっきりしています。
JPCYBERの無料版は特に機能制限がないらしいので、これがデフォルトのようです。

CloudBerry DriveはタブにProxy設定等がありますが、
JPCYBERは[ツール]→[オプションの設定]から画面を表示することでProxyの設定などができました。

### CloudBerry Drive
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/de428f53-9659-2936-197f-b1e611a35622.png)

### JPCYBER
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/54f63bc6-c93f-7f6f-1cb1-1540415145b0.png)

## アカウント設定
続いてアカウントを設定していきます。
CloudBerry Driveはマウント設定と別々に設定しますが、
JPCYBERはアカウント設定とマウント設定が一緒に設定する、という違いがあります。

ただし、その設定内容にはそこまで大きな違いはなさそうでした。
(CloudBerry Driveのほうがより細かな設定が可能です)

### CloudBerry Drive
CloudBerry Driveは[Storage Accounts]タブのAddボタンから設定画面を開くことができ、
そこから接続するストレージ種別やアクセス方法(アクセスキーかIAMロールか)を設定します。

このときSSLを使用するかや詳細設定からプライマリリージョンを指定できます。
マウントの設定はまた別タブになるため、この時点ではまだ設定できません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/49f93a99-bbe3-63b3-3ac6-2a2ccbdc69eb.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/24936257-c6d3-d0d9-5c3c-bba6cd0c3ea8.png)

### JPCYBER
一方JPCYBERはCloudBerry Driveに比べてシンプルで、接続するストレージ種別はS3かS3互換ストレージかの2種類のみです。

またアクセス方法がアクセスキーかIAMロールかという部分は同じですが、アクセスキーを設定しない場合は強制的にIAMロールでの接続になります。
こちらはアカウントの設定とマウントの設定が同一画面で行えるため、設定手順自体は少なくて済みます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/8501e086-2689-f438-54b3-e01499a42965.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/65782dc8-4baf-a253-0d78-d77bec26eba7.png)

## マウント設定
アカウント設定の後はマウント設定を行います。
こちらもアカウント設定時と同じく細かな設定はCloudBerry Driveのほうができます。

ただし正直なところ運用する上ではこれがないとダメ、という機能はあまり見当たらないです。

### CloudBerry Drive
マウントの設定は、[Mapped Drives]タブからAddボタンを押して画面を開きます。
Storage Accountで先ほど作成したアカウントを指定し、PathにマッピングS3の指定をするのですが、
ここではS3バケット名、またはバケット配下のパスでも指定可能です。
※test-bucket/test/test1等

このマッピング時に、マウント方式(ネットワークドライブマウントかリムーバブルディスクマウントか)やサーバサイド暗号化、Read-only accessの設定などが可能です。
オプションの設定ではキャッシュを使用するか、など細かく指定ができます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/5d1913ca-af8f-067d-43b2-fb38d5a826ae.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/1a79343d-1436-189c-d51f-6bf4e95249bc.png)

### JPCYBER
JPCYBERは先ほど言った通りアカウント設定時にまとめてマウントの設定もします。
アカウント設定画面でオプションを押下すると、マウント方式やサーバサイド暗号化などを指定できます。

わかりやすいCloudBerry Driveとは異なる点としては、S3バケット配下のパス単位ではマウントができない、という点です。
JPCYBERはS3バケット単位でのマウントになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/9ebc2bc4-4922-39d7-2210-f364e044c343.png)

## Windowsエクスプローラからの確認
マウント設定後Windowsエクスプローラから確認した図がこちらです。
CloudBerry Driveでマウントしたネットワークドライブは見えてますが、JPCYBERでマウントしたネットワークドライブは見えてません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/16a6a23e-290d-0fc1-bec7-e0898fe627a4.png)

JPCYBERの設定画面からダブルクリックでエクスプローラ表示されました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/409eac19-f244-b034-fce8-ba3135c7fbbe.png)

その状態でエクスプローラのコンピュータに移動すると確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/12515902-23d3-e14b-7a0a-7dad08798815.png)

~~どうやら表示の方法によってJPCYBERは表示される場合とされない場合がありそうです。~~
~~※上がドライブが見えている状態、下が見えていない状態~~
翌日再度ログインしてみたところ、何もせずともエクスプローラから確認できました。
設定に時間がかかるか、再起動したのが有効だったのかもしれません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/56d5064f-c2b8-5351-52f4-7a29fbca623b.png)

## ファイル操作
マウントができましたのでオブジェクトの作成、削除を試してみます。
※ネットワークが関係するのでそこまで大きく異なるとは思いませんが。

使用するファイルはこちらです。
約50MBのファイルを5ファイル、計250MBのオブジェクトが格納されたtestフォルダーを配置します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/801c4343-91d1-4e0b-e12a-8dbc18d56ac3.png)

実行はPowerShellから以下のコマンドを使用して行い、実行時間検証のためコピー→削除を5回実施します。

```
$ Measure-Command { Copy-Item C:\Users\Administrator\Desktop\test_cloudberrydrive D:\ -Recurse }
$ Measure-Command { Copy-Item C:\Users\Administrator\Desktop\test_jpcyber E:\ -Recurse }
$ Measure-Command { Remove-Item D:\test_cloudberrydrive -Recurse }
$ Measure-Command { Remove-Item E:\test_jpcyber -Recurse }
```

計測するのはコマンドの出力のMillisecondsです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/daa7aad5-4de5-4d29-1f4f-b07c5fe501c1.png)

実際に計測した結果はこちらです。

|回数|CloudBerryDrive|JPCYBER|
|:-:|:-:|:-:|
|1回目コピー|19304.0157msec|7711.4077msec|
|1回目削除|649.1382msec|418.1586msec|
|2回目コピー|19553.9255msec|6828.492msec|
|2回目削除|186.1073msec|428.1857msec|
|3回目コピー|18855.6787msec|6658.629msec|
|3回目削除|228.3489msec|342.8083msec|
|4回目コピー|19077.9088msec|5235.9187msec|
|4回目削除|353.5894msec|615.7427msec|
|5回目コピー|18817.1259msec|6587.5401msec|
|5回目削除|193.6256msec|395.691msec|

わかりづらいため小数点以下は切り捨てしていますが、思ったよりも差が出ました。

同じサーバ、同じネットワークを使用していますが、その時の状況によって少しは差が出るとは思っていましたが、コピー時の時間はかなり差が出ましたね。

CloudBerry DriveとJPCYBERでは、CloudBerry Driveのほうが約3倍程度時間がかかっているようです。
逆にJPCYBERのほうが削除には時間がかかっていました。

|回数|CloudBerryDrive|JPCYBER|
|:-:|:-:|:-:|
|コピー合計|95608msec|33021msec|
|コピー平均|19121msec|6604msec|
|削除合計|1610msec|2200msec|
|削除平均|322msec|440msec|

これはおそらくですが、CloudBerry Driveのフォルダキャッシュの保持期間が2秒なのに対しJPCYBERはデフォルトで120秒のため、2回目以降実行時にはキャッシュが使われていたのではないかと思います。

尚、JPCYBERで高速化キャッシュを有効化した場合、キャッシュ用の空き容量が必要になりますので、使用する際は空き容量に注意が必要です。

### CloudBerry Drive
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/be23deb4-92fb-1f58-7664-4095b5fee20d.png)

### JPCYBER
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/37655405-ee17-8cb9-079f-49e420875630.png)

## 気になった部分
設定や機能的には大枠は2つとも大きく異なる部分は少ないですが、CloudBerry Driveについていくつか気になるところがありました。

### エクスプローラで手動コピーしようとするとたまに失敗する
これは同じファイル、フォルダを何回か作成・削除した場合に起こった事象ですが、たまに以下のようにエラーが出て失敗するときがあります。
もちろんS3上には同一ファイルはないですし、コピー元のファイル・フォルダはちゃんと存在しています。
JPCYBERでは再現しなかったので、CloudBerry Drive固有の問題だと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/e119b649-39e4-b5b7-b8c7-9fe663b4f2bf.png)

このように同じファイル・フォルダ、同じ操作をJPCYBERで実施してもエラーは出ずに正常終了します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/f1a3d106-11d4-4487-5954-e2202853e012.png)

### フォルダごとアップロードしたはずが、ファイルとしてアップロードされる
マウントしたドライブにコマンドでフォルダごとコピーを行った際に、フォルダではなく1つのファイルとして保存されることがあります。
名前はフォルダの名前、ただサイズを見ると中に格納していたフォルダのサイズと一致する、という事象でした。
処理の途中でフォルダ名とファイルの紐づけか何かがおかしくなったのではないかと思いますが、これもCloudBerry Drive固有の問題っぽいです。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/440403/c05c84f6-6042-7006-322a-186dce4f78a4.png)

# 比較してみて
今回の検証手順だと、思ったよりもCloudBerry Driveの変な動作が発生してイマイチちゃんと比較しきれなかった部分がありますが、まぁJPCYBERがかなり安定していて使いやすかったです。
設定項目とかシェアや金額はCloudBerry Driveと比べると若干少ない・狭い・高い感じでしたが、挙動の安定性や日本企業がサポートしてくれそう、という点は評価ポイントでした。

機会があったら是非使ってみたいと思います。→JPCYBER