目次
祝 大阪リージョン正式オープン！！
ついに Google Cloud (GCP) Platform Japan Blog での発表がありましたヽ(=´▽`=)ﾉ
リージョン名は asia-northeast2、ゾーンは a、b、c とあります。
プロダクトの詳細は プロダクト比較 をご覧ください。
そんなわけで、まずはネットワーク的距離について実験＆まとめてみました。
東京リージョン、大阪リージョンといくつかのリージョン間の転送速度とRTTを調べてみる
nuttcp server を大阪と東京リージョンに置き、他のゾーンのクライアントからアクセスします。
nuttcpするスクリプトは、GCSにアップしておいて、起動時に読み込んで実行するように設定し、その結果をGCSに保存して集計します。
1回では少ないと思うので、-r , -t オプションそれぞれ10回行ってみて平均を出します。
エラーが出た場合はデータを使いません（2回ありました）。
転送速度は時間帯によって違うので、参考程度に御覧ください。
インスタンスのスペックは
server側
OS Debian GNU/Linux 9 (stretch)
マシンタイプ n1-standard-8
client側
OS Debian GNU/Linux 9 (stretch)
マシンタイプ n1-standard-1
結果です。量が多いので画像にしました。
nuttcp -t (クライアント側が送信元）の場合
nuttcp -r (クライアント側が送信先）の場合
なんか transmitter 側が頭打ちしてるように見えますね。CPUパワーが足りなかったのでしょうか。
というわけで、東京リージョンと大阪リージョンの分だけ n1-standard-8 にしてやり直します。
nuttcp -t (クライアント側が送信元）の場合
nuttcp -r (クライアント側が送信先）の場合
近場のネットワークを検証したい場合は、スペックがそこそこあるインスタンスを使うべきでした。
とりあえず今日中に公開したかったので今日はこのへんで。。。
以下おまけです。
GSCバケットを東京リージョンと大阪リージョンに作ってファイル転送してみる
VMスペックは
OS Debian GNU/Linux 9 (stretch)
マシンタイプ n1-standard8
gsutil perfdiag
テスト用コマンドがあるので、まずはこれを使います。こんな感じで。
$ gsutil perfdiag -n 10 -s $((1024*1024*100)) -o osaka.output.json gs://osaka-test-osaka
-n はテスト回数
-s はスループットテストで使うファイルのサイズ(今回は100M。1Gにしたら時間がちょっとかかるのでやめた)
-o はテスト結果を書き出すファイル名
10回テストを行って平均を出します。
結果です。
ファイルの転送にかかった時間です（単位: sec）。
| zone (region) | GCS (region) | UPLOAD 1024byte | DOWNLOAD 1024byte | UPLOAD 1Mbyte | DOWNLOAD 1Mbyte |
|---|---|---|---|---|---|
| asia-east1-a (taiwan) | tokyo | 0.117 | 0.167 | 0.374 | 0.181 |
| asia-northeast1-a (tokyo) | tokyo | 0.091 | 0.037 | 0.156 | 0.054 |
| asia-northeast2-a (osaka) | tokyo | 0.110 | 0.113 | 0.216 | 0.125 |
| asia-east1-a (taiwan) | osaka | 0.119 | 0.192 | 0.684 | 0.297 |
| asia-northeast1-a (tokyo) | osaka | 0.109 | 0.113 | 0.247 | 0.227 |
| asia-northeast2-a (osaka) | osaka | 0.093 | 0.045 | 0.193 | 0.051 |
1秒あたりの転送速度です（単位: Mbyte)。
| zone | GCS (region) | write 転送速度 | read 転送速度 |
|---|---|---|---|
| asia-east1-a (taiwan) | tokyo | 76.541 | 273.260 |
| asia-northeast1-a (tokyo) | tokyo | 115.562 | 358.763 |
| asia-northeast2-a (osaka) | tokyo | 126.139 | 358.344 |
| asia-east1-a (taiwan) | osaka | 93.931 | 185.076 |
| asia-northeast1-a (tokyo) | osaka | 151.485 | 301.497 |
| asia-northeast2-a (osaka) | osaka | 149.026 | 451.079 |
mysql のレプリケーションを試してみる
master を 東京リージョン、slave を東京リージョンと大阪リージョンに作成してslaveに遅延がどのくらい出るのか試してみます。
お試しなので、apt-get でサクッとインストールします。設定もデフォルトのままで行きます。
# レプリケーションの構築方法については割愛します。
# Debian で mysql-server をインストールすると mariaDBになりますが、便宜上 mysql の表記のままで行きます。
計測には pt-heartbeat を利用しました。
OS Debian GNU/Linux 9 (stretch)
マシンタイプ n1-standard8
1行120byte程度のINSERT文を10000回投げてみたところ、pt-heartbeat では1秒以上の遅延は見られませんでした。
1行1Mbyte程度のINSERT文を10000回投げたところ、pt-heartbeat で1秒以上の遅延が何度か見られました。東京・大阪どちらのslaveでも同時に起こっているパターンが半分くらい。全体で5分程度かかっていいましたが、その中で遅延があったのは、東京側3回、大阪側5回でした。
もうちょっと差異が出るのかなと思っていたので何度もやってみたのですが、毎回こんな感じでした。
最後に
国内向けのサービスで、東京リージョンとマルチリージョンで運用したいなぁと思った時、台湾リージョン？うーん？？？となっていたのが解消されそうです。
はじめは東京と大阪と台湾間くらい計測すればいいかなと思ったのですが、やってるうちにあれもこれもとなって、結局現在動いているゾーンすべてに対して調べることにしてみました。
スクリプトを書いて実行するので手間は別にないのですが、nuttcp server に同時にアクセスしまくるとエラーが頻発したので、ちょっとずつアクセスするようにしました。 そのせいで、スクリプトの実行には4、5時間くらいはかかった気がします。
あと、nuttcp の結果表示がこんな感じなのですが
15706.9843 MB / 10.00 sec = 13173.7312 Mbps 51 %TX 47 %RX 0 retrans 0.31 msRTT
2341.7562 MB / 10.01 sec = 1962.0664 Mbps 7 %TX 13 %RX 0 retrans 0.35 msRTT
166.1592 MB / 10.26 sec = 135.8743 Mbps 0 %TX 0 %RX 0 retrans 157.53 msRTT
行頭にスペース入れるか入れないかはっきりして！（取っちゃえばいいんですけど）
ってなりました。
書いたスクリプトが間違っていないことをただ祈るのみです。
株式会社grasys(グラシス)は、技術が好きで一緒に夢中になれる仲間を募集しています。
grasysは、大規模・高負荷・高集積・高密度なシステムを多く扱っているITインフラの会社です。Google Cloud (GCP)、Amazon Web Services (AWS)、Microsoft Azureの最先端技術を活用してクラウドインフラやデータ分析基盤など、ITシステムの重要な基盤を設計・構築し、改善を続けながら運用しています。
お客様の課題解決をしながら技術を広げたい方、攻めのインフラ技術を習得したい方、とことん技術を追求したい方にとって素晴らしい環境が、grasysにはあります。
お気軽にご連絡ください。
