注意
この記事は2015年4月6日に更新されたもので、内容が古い可能性がありますのでご注意ください。
GCE（アジアリージョン）⇔S3（東京）で速度検証してみました。
やってみたのは、以下の2パターン
- 単純なddコマンドで作成した空ファイルのaws 3s sync コマンドでのコピー
- Cosbenchと言うツールによるもの
環境はn1-standard1 の10Gディスクasia-east1-aリージョンのノーマル作成Ubuntu14.1です。
1．単純ファイルコピー
まずは10M×10個のファイルを作成して試してみる。
コード
mkdir cptest
for i in {1..10} ; do dd if=/dev/zero of=cptest/tempfile$i bs=1M count=10; done
time aws s3 sync ./cptest s3://yoshidumi/cptest
sync 結果画面
結果：10M×10の100Mコピー（S3へのUp）に5.4秒程度、スループットで約18.5MB/Secなのでまぁまぁ十分と言える感じでしょうか。
次は逆にDLの方をやってみます。
コード
time aws s3 sync s3://yoshidumi/cptest ./cptestout
結果：10M×10の100Mコピー（S3からのDown）に2.7秒程度、スループットで37MB/Secなのでこちらもまぁまぁ上りの倍ありますので、十分と言える感じでしょうか。
2．Cosbenchと言うツールによるもの
cosbench については、こちらの記事をまるっきり参考にさせて頂きました。ありがとうございます。
バージョン等は最新のものを使いましたが、概ね同じです。
- AIMでユーザ・権限追加
cosbenchと言う名前でユーザ追加し、権限に「Amazon S3 Full Access」の権限を付ける。
ここで、バケットに誰でもフルアクセスにすりゃ認証無しで良いのでは？と思い、色々試しましたが、結果うまくいかなかったため、おとなしく権限を割り当てた方が無難です。 - Ubuntuを起動してcosbenchのインストール
14.1でも動きました。
これも上述の記事にあるようにAWS荒木さんの記事の通りですが。
GCEの場合はFWで18088と19088ポートを開ける必要がありますので、ご注意ください。 - 設定ファイルの修正
こちらも記事通りですが、accesskeyとsecretkeyを１で作成したものにして、endpointを以下のように東京リージョンに向けてやります。コード各configのcprefixは特にどうやら後ろに数字を付けて使われてないバケットを探してくれるようなので、特にデフォルトのままでも動きそうです。<storage type="s3" config="accesskey=ＸＤＦＡＤＦＳＤＦＳＤＦ;secretkey=dafdsafadsfasdfasdfasdfasd;endpoint=s3-ap-northeast-1.amazonaws.com" /> - Workloadの投入
以下のようなURL（当然IP部分はcosbenchをインストールしたGCEのインスタンス）にアクセスし、
http://107.167.ＸＸＸ.ＸＸＸ:19088/controller/index.html
「submit new workloads」から先ほど作成したコンフィグをUpすればOKです。 - 結果
以下のような結果が得られます。
最初に上げた稲葉氏のAWS間での結果と比べると概ね倍位は遅くなってる感じでしょうか。まぁ仕方ないですね。
残念ながらcosbenchはGCSには未だ対応してないので、GCE-GCS間では検証が出来ませんが、毎秒65回の読みであればまぁ悪く無いように思います。
ボトルネックがどこにあるのか、サーバのCPU等は全く問題なかったので、次回はコンフィグを弄り、もっと並列負荷を掛けてみてどの程度のスループットが出せるのか、確認してみたい所です。
