以前記事で紹介したことがある「S3+Storage Gatewayをwindowsにマウントする」という方法、エクスプローラーでローカルファイルのようにS3のファイルを操作できて便利なのですが、困ったことがあります。
それは、ローカルファイルと比較して動作が重いということです。
特に大量のファイルが存在するときなどに読み込みが遅く感じてストレスになってしまいます。
動作速度を改善すべくいろいろ試しましたが、結論としては「Storage Gatewayサーバーをインターネット越しに配置してはダメ」だとわかりました。
どのようにしてそのような結論に至ったのか、経緯など解説していきます。
インターネット越しStorage Gateway構成の説明
動作が重いと感じたのは以前記事で構築手順を紹介した以下のような構成です。
（クリックすると画像が拡大されます。）
クライアントPCとAWS環境はネットワーク的に分かれており、インターネット経由でAWS環境にアクセスする構成です。セキュリティ担保のためにVPNサーバーを経由してStorage Gatewayにアクセスするようにしています。
サーバーのスペックとしては、Storage Gatewayサーバーは「m4.xlarge」、VPNサーバーは「t3.midium」です。
こちらの構成で使い勝手を試していたところ、動作が遅くて困る場面がありました。
どれくらい遅いのか
それでは実際どれくらい遅いのでしょうか。ベンチマークソフト「CrystalDiskMark」を使用して読み取り速度と書き込み速度を計測します。
CrystalDiskMarkの見方
CrystalDiskMarkについて少し触れておくと、SEQ1Mという連続1MiBの連続データとRND4KiBという4KiBのランダムデータそれぞれの読み込み・書き込み速度を計測します。
連続したデータは読み書きするデータが断片化されてしまうとアクセス場所を探しながら読み書きするので遅くなりますが、デフラグすることで改善します。
今回は断片化は考慮せず、連続したデータ読み書き（ SEQ1M ）で比較していきます。
（クリックすると画像が拡大されます。）
ローカルとの速度比較
「ローカル」と「Storage Gateway経由のS3」をそれぞれ3回ずつ計測した結果、以下のようになりました。
（クリックすると画像が拡大されます。）
この結果によると、Storage Gateway経由のS3はローカルに比べて読み込み速度が1/10以下、書き込み速度が1/20以下となっていることがわかります。
どうりで遅く感じるわけです。。
では、なぜ遅いのか。ボトルネックになっている部分を見つけなければなりません。
ボトルネックになる箇所としては「VPNサーバー」、「Storage Gatewayサーバー」、「ネットワーク」が挙げられます。
ここからそれぞれボトルネックかどうか検証していきます。
VPNサーバーのスケールアップで改善しないのか
まずは「VPNサーバー」がボトルネックかどうか検証していきます。
VPNサーバーがボトルネックなのであれば、VPNサーバーの処理が追い付いていないことが原因として挙げられるので、VPNサーバーのスケールアップを試してみます。
VPNサーバーをt3.medium（2コア4メモリ）からm5.large（2コア8メモリ）に変更して比較してみました。
（クリックすると画像が拡大されます。）
結果としては、数値は変わりませんでした。。
それならいっそ、VPNサーバーを経由しない構成を作って比較してみます。
（クリックすると画像が拡大されます。）
結果としては、やはり数値は変わらず。
こうなってくるとVPNサーバーはボトルネックではなかったようです。
Storage Gatewayのスペックアップで改善しないのか
ボトルネックになる箇所としては「VPNサーバー」、「Storage Gatewayサーバー」、「ネットワーク」が挙げられますが、VPNサーバーはボトルネックではないとわかりました。
ということで残るは「Storage Gatewayサーバー」と「ネットワーク」です。
次は「Storage Gatewayサーバー」がボトルネックなのか検証していきます。
Storage Gatewayサーバーがボトルネックなのであれば、Storage Gatewayサーバーの処理が追い付いていないことが原因として挙げられるので、 Storage Gatewayサーバーのスケールアップを試してみます。
Storage Gatewayサーバーをm5.xlarge（4コア16メモリ）からm5.2xlarge（8コア32メモリ）に変更して比較してみました。ちなみにStorage Gatewayの推奨最低スペックはm5.xlargeです。
（クリックすると画像が拡大されます。）
結果としては、数値は変わりませんでした。。
倍のスペックにしてもベンチマークの数字に変化なし。むしろ下がっている。。ということでStorage Gatewayサーバーはボトルネックではなかったようです。
Storage Gatewayは使用するPCと同一ネットワークに配置する
となるとおそらく「ネットワーク」がボトルネック確定ですが、念のため検証していきます。
ネットワークがボトルネックなのであれば、AWS環境にEC2を構築してStorageGateway経由でS3にアクセスさせてみます。
今回はt3.midiumのwindowsインスタンスを構築してCrystalDiskMarkをインストールして検証します。
ちなみにEC2でローカルへの読み書き速度は以下のようでした。私のデスクトップと比べると少し遅いかなといった感じです。
（クリックすると画像が拡大されます。）
EC2からStorage Gateway経由で読み書きした結果はこちら。
（クリックすると画像が拡大されます。）
今まで検証してきたインターネット経由でStorage Gatewayにアクセスしたときと数字が大きく変わりました。
やはり、遅くなっていた原因はインターネット経由でStorage Gatewayにアクセスしていたからでした。
こちらを読むとAWSもインターネット越しにStorage Gatewayを配置するのはオススメしていないようですね。
余談ですが、デスクトップの通信速度を計ってみたところ70Mbpsってところでした。
（クリックすると画像が拡大されます。）
どんなにスムーズでも読み書き速度70MB/sが限界なのでローカルの半分程度の速度が上限値ですね。
実際はさらに通信によるリードタイムなどで読み書き速度がかなり悪くなっているようです。
Storage Gatewayを使わない別の選択肢
それにしても困りました。サーバーを減らすためにStorage Gateway+S3構成にしようと思ったわけですが、読み書きの遅延をなくすには同じネットワークにStorage Gatewayサーバーを立てる必要がありそうです。
サーバーは立てたくないが、S3のファイルはエクスプローラーから使いたい。。
と、ここで妙案が。それは「S3マウントソフト」です。
サードパーティソフトを使うことになりますが、サーバー構築するよりマシ。ということでサードパーティのS3マウントソフトを検討していこうと思います。
ただし、マウントソフトを使う場合は、ローカルとクラウド側で反映までのタイムラグがあることに注意が必要です。頻繁に大勢が使うようなファイルがある場合は使いにくいのではないかと思います。
S3マウントソフトについてはこちらの記事で紹介しているので興味があればご覧ください。
余談：Storage Gatewayサーバーをスケールアップすると早くなるのか
上記の結果ではStorage Gatewayサーバーをスケールアップしても読み書き速度が変わりませんでしたが、
ネットワークのボトルネックがない状態で計測して再度確認してみました。
（クリックすると画像が拡大されます。）
ネットワークのボトルネックがなくなると、Storage Gatewayサーバーのスケールアップの効果が数字としてはっきりわかるようになりました。
Storage Gatewayのスペックによる読み書きの速度についてはAWSにも掲載があるようです。
