【エバンジェリスト・ボイス】AWSで遊んでみよう！～爆速Storage Gatewayは可能か！？ その2～

関連するソリューション

ID-Cross/クラウドサービス

サイバー・セキュリティ・ソリューション（CSS）部
エバンジェリスト　松岡　政之    

こんにちは。 CSS 部エバンジェリストの松岡です。

新型コロナウィルスの影響で緊急事態宣言も全国に広がり、ライブや各種イベントができない状況になりました。
私自身もリモートワークとなり、食事や最低限の買い物以外では全く外出しない日々が続いております。
ですが、こんな時こそ IT を活用して家にいながらでもいろいろなことをしていただければ、 IT 業界で働く身としては嬉しい限りです。
例えば、オンライン飲み会などは個人でも簡単にできますし、もっと規模の大きな話でいえばニコニコネット超会議やエアコミケなど今まで会場で行われていたイベントも形を変えてインターネット上で行われています。
皆様も出かけられなくて気分が沈んだりしているかもしれませんが、こういったオンラインでの新しい試みに参加したり企画したりして楽しく過ごせるとより良いですよね！

さて、本題に入ります。

前回の 【エバンジェリスト・ボイス】AWSで遊んでみよう！～爆速Storage Gatewayは可能か！？～ では、Storage Gatewayの機能の一つであるファイルゲートウェイでRAMディスクを使うことで高速に利用できないかという検証内容でお送りいたしましたが、結果的に思ったより速くならなかったことについて、SMBの限界なのではというお声をいただきましたので、今回はSMBを利用せずiSCSIで接続するキャッシュ型のボリュームゲートウェイで同様の検証を行ってみました。


ファイルゲートウェイとボリュームゲートウェイの違いは下記ドキュメントをご覧ください。

※外部サイト： AWS Storage Gateway の仕組み (アーキテクチャ)

というわけで、今回もサクッと RAM ディスクを作成します。

ボリュームゲートウェイではファイルゲートウェイでも設定したキャッシュディスクとは別にアップロードバッファというディスクが必要になります。
本当は各 150GB 以上割り当てるのが AWS の推奨なのですが、今回はメモリのリソースも限られるので各 10GB 割り当てるために 20GB+α ということで 21GB の RAM ディスクを作成しました。

RAM ディスクの作成直後に何も書き込んでいなくても下図の通りいくらか使用されているので、 20GB ちょうど作成すると 10GB の仮想ディスクを二つ作れないので注意が必要です。

続いて、 Storage Gateway を作成していきます。
今回はファイルゲートウェイではなくボリュームゲートウェイ、そしてキャッシュボリュームを選択します。ちなみに補完型ボリュームはファイルゲートウェイやボリュームゲートウェイとは異なりオンプレミス側が主、S3側がバックアップといった形になり、今回の趣旨から外れるため対象外としています。

そして前回と同様に、 Hyper-V 上にゲートウェイを作成します。

その際、前回とは異なり RAM ディスク上に 10GB の仮想ディスクを 2 つ作成します。

結果、ゲートウェイは以下のような仮想マシンとなります。

その後ゲートウェイで IP アドレスを設定し、 Web コンソール上から接続してキャッシュディスクとアップロードバッファを設定するとボリュームゲートウェイが作成されます。

続いて、容量等を指定してボリュームを作成します。この際、ファイルゲートウェイとは異なりボリュームゲートウェイではバケットを指定しません。ボリュームゲートウェイではS3の専用領域に保存され、保存されたデータにはボリュームゲートウェイ以外からはアクセスができません。

さて、ここからがファイルゲートウェイと手順が大きく異なりますが、接続元の端末で iSCSI イニシエータを起動します。詳細な接続手順は AWS のドキュメント にお任せしますが、接続が完了した様子を下記に示します。

今回は設定していませんが、CHAP認証を用いることで接続する端末を制限することもできます。

iSCSI 接続が完了すると、新しいディスクとして OS からは認識されるのでフォーマットしてドライブレターを割り当てて利用できるようにします。

さて、これで検証の準備は完了しました。
それでは早速ディスクのベンチマーク結果を見て見ましょう。

比較のために、前回行ったファイルゲートウェイの結果も見てみます。

結果としては、ファイルゲートウェイの場合と比べてシーケンシャルが伸びてランダムが落ち込んでいますが、おおむね同じような傾向でした。
今回、構成としては iSCSI のターゲットとなるゲートウェイの仮想マシンが、 iSCSI のイニシエータとなるホストマシン上にあり、物理的なネットワークを介さない（もちろん Hyper-V の仮想スイッチは介しますが）です。
iSCSI では規格上 1GB/s 以上出るため、今回シーケンシャルの向上が見られたのかと思います。
一方、ランダムについては iSCSI の処理のオーバーヘッドの影響か大きく性能が落ち込んでしまっています。 SMB よりさらに遅くなってしまうのは予想外でした。


さて、今回のまとめです。
前回と同様に Storage Gateway に RAM ディスクをローカルキャッシュとして利用することで高速化できるかどうかの検証でしたが、今回は SMB ではなく iSCSI で接続するボリュームゲートウェイで行ってみました。
結果としては、目を見張るほどの高速化は見込めなさそうなことがわかりましたが、このようにディスク側のオーバヘッドがない状態で検証をしてみることでそれぞれのゲートウェイの特性が見えてきて面白い部分もありました。
もちろん利用用途としては速度以外にも考慮すべき事項は多々ありますが、速度という点で着目した場合大きなファイルを読み書きする場合においてはボリュームゲートウェイの方が若干高速なことがわかりました。一方、小さなファイルについては並列して読み書きする場合（ RND4K Q32T16 ）はファイルゲートウェイと大差はありませんが、並列度が下がると（ RND4K Q1T1 ）特に書き込みにおいて非常に遅くなってしまうことがわかりました。
そのため、ボリュームゲートウェイは大きなデータをドカッと保存するような用途には向いていますが、普段ユーザがファイル置き場として利用するような用途には向いていないでしょう。

AWS には「似たような機能が使えるけどどっちを使うのがよりいいかわからない」といったサービスがほかにもいくつかあるかと思います。発端は RAM ディスクを使ってみたら … という全く別のところからでしたが、こういった機能比較も面白そうなので今後もやっていけたらと思います。

それではよいクラウドライフを！

当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。

エバンジェリストによるコラムやセミナー情報、
IDグループからのお知らせなどをメルマガでお届けしています。